料金モデルとコスト管理

二つのコンピュート課金モデル — オンデマンドと editions

BigQuery のコンピュート（クエリ実行）には 2 つの課金モデルがあります。オンデマンドは処理したバイト数に応じて課金され、BigQuery editions（キャパシティベース課金）はスロット時間で課金されます。どちらもいつでも切り替えられ、プロジェクト単位で両方を組織内に混在させることもできます。

オンデマンドは既定のモデルで、2026-08 時点で米国（US マルチリージョン）は 1 TiB あたり 6.25 米ドル、月間最初の 1 TiB は無料です。この無料枠は請求先アカウント単位で共有される点に注意してください（後述のつまずきポイント参照）。課金の丸めルールも押さえておく必要があります。処理バイト数は MB 単位に切り上げられ、クエリが参照するテーブル 1 つあたり最低 10 MB、クエリ全体でも最低 10 MB が課金対象になります。オンデマンドでは 1 プロジェクトあたり最大 2,000 スロットを他のクエリと共有する形でおおむね利用でき、小さいクエリを速く終わらせるために一時的にこの上限を超えてバーストすることもあります。

editions はスロット（仮想 CPU）を時間単位で買い切るモデルです。Standard・Enterprise・Enterprise Plus の 3 エディションがあり、US（マルチリージョン）の従量（Pay as you go）単価は次のとおりです。

スロットコミットメント（1 年・3 年）は Enterprise と Enterprise Plus だけが利用できます。Standard とオンデマンドにはコミットメントの購入枠自体がありません。コミットメントは 50 スロット単位・最低 50 スロットから購入し、リージョン単位の容量で、組織全体で共有できます。予約（reservation）は既定で 1 分単位の最低billing（秒課金・1 分未満は切り上げ）ですが、BigQuery fluid scaling にオプトインすると最低時間なしの秒単位課金になります。予約のベースラインを 0、最大スロット数だけを設定すれば、必要なときだけスロットが自動的にスケールする「オンデマンド的な使い方」も editions の中で実現できます。なお、既存の予約のエディションを変更したい場合は予約自体を削除して作り直す必要があります。

課金モデルの選び方をコスト制御の観点で整理すると、次のようになります。

ストレージ課金 — 論理 vs 物理、アクティブ vs 長期保存

BigQuery のストレージ課金は、データセット単位で論理（圧縮前）と物理（圧縮後）のどちらかを選べます。2026-08 時点の US（マルチリージョン）の単価は次のとおりです（最初の 10 GiB は毎月無料）。

物理ストレージ課金を選ぶと、データが圧縮されている分だけ単価は上がっても総量が小さくなるため、圧縮率の高いデータ（繰り返しの多い文字列の列など）では有利になります。逆に元々あまり圧縮できないデータでは論理課金の方が安くなることが多いです。どちらが得かは INFORMATION_SCHEMA.TABLE_STORAGE ビューの total_logical_bytes と total_physical_bytes を比べれば実測できます（ハンズオン 7-2 で行います）。物理ストレージ課金にはもう一つ注意点があり、タイムトラベルとフェイルセーフのストレージも課金対象になります（論理課金では無償）。既定のタイムトラベル期間は 7 日で、物理課金を使う場合はこの期間を短縮するとコストを抑えられます。

90 日以上変更されていないテーブル（またはパーティション）は自動的に長期保存の単価に切り替わります。ここで重要なのは「何がタイマーをリセットするか」です。テーブルへのロード・コピー先としての書き込み・クエリ結果の書き込み先としての利用・DML・CREATE OR REPLACE TABLE などの DDL・ストリーミング挿入はいずれもタイマーを 0 日にリセットします。一方、単にクエリで読む・ビューを作る・エクスポートする・別テーブルへコピーする（コピー元として）・テーブルのメタデータ（説明やラベル）を更新するだけではタイマーはリセットされません。

ストレージ課金モデルを切り替えるには、コンソールでデータセットの詳細から Storage billing model を変更するか、次のように操作します。

-- SQL（DDL）
ALTER SCHEMA `PROJECT_ID.handson_ch07`
SET OPTIONS(
  storage_billing_model = 'PHYSICAL');

-- bq コマンド
bq update -d --storage_billing_model=PHYSICAL PROJECT_ID:handson_ch07

BILLING_MODEL には LOGICAL か PHYSICAL を指定します。変更が反映されるまでには 24 時間かかり、一度変更すると次に変更できるまで 14 日間の待機期間があります（後述のつまずきポイント参照）。

コスト制御の道具箱と誤解の解体

コスト事故を防ぐ道具は、発動するタイミングの異なる 4 層に分けて考えると整理しやすくなります。

① dry run はクエリを実行せずに処理バイト数を見積もります。bq CLI では次のように使います。

bq query --use_legacy_sql=false --dry_run \
'SELECT word, corpus
 FROM `bigquery-public-data.samples.shakespeare`
 WHERE corpus = "hamlet"'

成功すると「Query successfully validated. Assuming the tables are not modified, running this query will process N bytes of data.」という応答が返ります。BigQuery Studio のクエリエディタでも、クエリを入力した時点で右上に同様の見積もりが自動表示されます。

② maximum bytes billed は、見積もりバイト数が指定した上限を超えた場合にクエリ自体を無課金で失敗させる仕組みです。

bq query --maximum_bytes_billed=1000000 --use_legacy_sql=false \
'SELECT word FROM `bigquery-public-data.samples.shakespeare`'

上限を超えると次のようなエラーになり、課金は発生しません。

Error: Query exceeded limit for bytes billed: 1000000. 10485760 or higher
required.

コンソールでは、クエリエディタの「編集」→「クエリの設定」→「詳細オプション」から Maximum bytes billed を設定します。ただしクラスタ化テーブルに対しては、この見積もりは実際の課金バイト数より大きめに出ることがあるため、実際には収まるはずのクエリが失敗することがあります（つまずきポイント参照）。

③ カスタムクォータは、オンデマンドの利用で 1 日あたりに処理できるデータ量そのものに上限をかけます。プロジェクト単位の QueryUsagePerDay（既定値 200 TiB/日）と、ユーザー単位の QueryUsagePerUserPerDay（既定値は無制限）の 2 種類があり、Google Cloud コンソールの「IAM と管理」→「割り当て」で BigQuery API を絞り込み、対象のクォータを編集して「無制限」のチェックを外し、TiB 単位の値を入力して申請します。上限に達すると、それ以降のクエリは「Custom quota exceeded: Your usage exceeded the custom quota for QueryUsagePerDay」（ユーザー単位なら QueryUsagePerUserPerDay）というエラーで実行そのものがブロックされます。maximum bytes billed と違い、クエリ個別ではなく日次の累計に対するハードキャップです。

④ 予算アラートは Cloud Billing の予算機能で、実績が設定したしきい値を超えるとメール通知が届きます。ここまでの 3 つと違い、予算アラートはクエリの実行を一切止めません。あくまで人間に気づかせるための通知です。

これらの土台の上に、よくある 2 つの誤解を解いておきます。

誤解 1: 「LIMIT を付ければ課金は減る」。非クラスタ化テーブルに対しては誤りです。BigQuery はカラムナ形式でデータを保持しているため、クエリで選択した列の総データ量に応じて課金され、LIMIT で結果行数を絞っても、選択した列は最後まで全行スキャンされてから絞り込まれます。クラスタ化テーブルに対しては話が変わります。クラスタ列へのフィルタと組み合わさっている場合、十分な結果が集まった時点でスキャンを打ち切れるため、実際にスキャンバイト数が減ることがあります。

誤解 2: 「SELECT * は無難な書き方」。カラムナストレージでは、選択した列のデータ型に基づくバイト数だけが課金対象になります。SELECT * は常に全列を読むため、必要な列だけを指定するクエリに比べて最悪のケースになりがちです。テーブルの中身を確認したいだけなら、クエリで探索するのではなく bq head コマンドやコンソールの Preview タブを使ってください。これらは無料です。

コストを追跡する側の道具として、INFORMATION_SCHEMA.JOBS ビューが役立ちます。region-us のようなリージョン修飾子を必ず付ける必要があり、直近 180 日分のジョブ履歴を保持します。参照には roles/bigquery.user と roles/bigquery.resourceViewer（権限としては bigquery.jobs.listAll と bigquery.jobs.create）が必要です。job_id・user_email・query・total_bytes_billed・total_slot_ms といった列から、誰がどのクエリでどれだけ課金されたかを追跡できます。請求データそのものを分析したい場合は、Cloud Billing のデータを BigQuery へエクスポートする機能も使えます。標準の使用コストデータ（SKU・プロジェクト・ラベル・ロケーション単位のコストと使用量）に加えて、仮想マシンやディスクなど個別リソース単位まで含む詳細使用コストデータ、SKU の価格設定情報そのものを含む価格設定データの 3 種類を個別に有効化できます。初回設定時は過去分のデータが出そろうまで最大 5 日かかる点に注意してください。

ハンズオン

bq query --use_legacy_sql=false --dry_run \
'SELECT word, corpus
 FROM `bigquery-public-data.samples.shakespeare`
 WHERE corpus = "hamlet"'

bq query --maximum_bytes_billed=1000000 --use_legacy_sql=false \
'SELECT word, corpus
 FROM `bigquery-public-data.samples.shakespeare`
 WHERE corpus = "hamlet"'

bq query --maximum_bytes_billed=10000000 --use_legacy_sql=false \
'SELECT word, corpus
 FROM `bigquery-public-data.samples.shakespeare`
 WHERE corpus = "hamlet"'

bq mk --location=US --dataset PROJECT_ID:handson_ch07

CREATE OR REPLACE TABLE `PROJECT_ID.handson_ch07.usa_names` AS
SELECT name, gender, year, state, number
FROM `bigquery-public-data.usa_names.usa_1910_current`;

-- 処理: メタデータの参照のみ（無料枠内）
SELECT
  table_name,
  total_logical_bytes,
  total_physical_bytes,
  ROUND(total_logical_bytes / total_physical_bytes, 2) AS compression_ratio
FROM `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE table_schema = 'handson_ch07'
  AND table_name = 'usa_names';

ALTER SCHEMA `PROJECT_ID.handson_ch07`
SET OPTIONS(
  storage_billing_model = 'PHYSICAL');

bq rm -r -f -d PROJECT_ID:handson_ch07

-- 処理: メタデータの参照のみ（無料枠内）
SELECT
  job_id,
  user_email,
  creation_time,
  total_bytes_billed,
  total_slot_ms,
  query
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE job_type = 'QUERY'
  AND state = 'DONE'
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY total_bytes_billed DESC
LIMIT 10;

つまずきポイント

理解度チェック

まとめと次章へ

• オンデマンド（$6.25/TiB、US）と BigQuery editions（Standard $0.04・Enterprise $0.06・Enterprise Plus $0.10、いずれも slot-時間、US 従量）はいつでも切り替えられ、混在もできる。損益分岐点は固定値ではなくワークロード次第
• ストレージ課金は論理（$0.02/GiB）と物理（$0.04/GiB、いずれも長期保存で 50% 引き）をデータセット単位で選べるが、オンデマンドのクエリ課金は常に論理バイト基準のまま変わらない
• コスト制御は dry run（見積もり）→ maximum bytes billed（クエリ単位のハードキャップ）→ カスタムクォータ（日次のハードキャップ）→ 予算アラート（月次の通知のみ）という異なる層で組み合わせる
• 「LIMIT は非クラスタ化テーブルでは効かない」「SELECT * は最悪手」は、カラムナストレージの課金の仕組みそのものから来る誤解
• INFORMATION_SCHEMA.JOBS / TABLE_STORAGE と請求データのエクスポートで、コストを事後にも継続的に可視化できる

• BigQuery の料金
• BigQuery editions の概要
• ワークロード管理の概要（予約）
• コスト管理のベストプラクティス
• カスタムクエリクォータの作成
• INFORMATION_SCHEMA.JOBS ビュー
• INFORMATION_SCHEMA.TABLE_STORAGE ビュー
• データセットの更新（ストレージ課金モデルの変更）
• Cloud Billing データの BigQuery へのエクスポート