BigQueryの料金：オンデマンドとEditionsの分岐点・ストレージ課金・コスト監視

BigQueryの請求額が読めないという相談は、たいてい「どの費目が効いているのか分解できていない」ところで止まっています。クエリのスキャン量なのか、保存しているデータ量なのか、ストリーミング取り込みなのか。ここを切り分けないまま単価だけ眺めても、下げるべき箇所は見つかりません。この記事では2026年8月17日時点のGoogle Cloud公式料金表とドキュメントの実測値をもとに、費目への分解、オンデマンドとEditionsの切り替え計算、スキャン量と保存方式の圧縮、INFORMATION_SCHEMAでの監視と歯止めまでを実装の解像度で整理します。仕組みと採用可否の総論はBigQueryの仕組みとできないことをまとめた解説に譲り、ここでは費用の実務に絞ります。

まとめ：請求額はスキャン量と保存方式で決まり、切り替えはスロット時間で計算できる

結論を先に示します。BigQueryの請求額は、コンピュート（クエリ）、ストレージ（保存）、取り込み、読み出しと転送の四つの費目に分かれ、多くの現場で支配的になるのは最初の二つです。そしてコンピュートの課金方式は、スキャンしたバイト数で払うオンデマンドと、確保したスロット時間で払うEditionsの二択になります。

この二択は感覚で決める必要がありません。オンデマンドは1TiBあたり6.25ドル、Editionsは1スロット時間あたり0.04ドルから0.10ドルなので、両者が釣り合う点は「1スロット時間あたり何GiBをスキャンできているか」という一つの指標に落ちます。Enterpriseの0.06ドルなら約9.8GiB。実測でこれを上回ればEditionsが安く、下回ればオンデマンドのままが安い。

ストレージは論理と物理、アクティブと長期の組み合わせで四区分あり、単価は最大で二倍近く開きます。設計で効くのはパーティション分割とクラスタリング、課金の歯止めとしてはカスタム割り当てと最大課金バイト数。ここまでを最初に組んでおけば、費用が読めないという状態からは抜けられます。

BigQueryの請求書をコンピュートとストレージと取り込みの費目に分解する

まず、請求書に並ぶSKUを頭の中で四つに束ねます。公式の料金構成は大きくコンピュート料金とストレージ料金の二本柱で、そこにデータの取り込み、Storage Read APIやネットワーク転送といった読み出し側が加わる形です。費目をまたいだ節約策は効きませんから、最初にどこが太っているのかを見極めてください。

オンデマンドは月1TiBまで無料で超過分が1TiBあたり6.25ドル

既定の課金方式はオンデマンドです。各クエリで処理されたバイト数に対して課金され、毎月1TiBまでは無料。超過分はus-central1で1TiBあたり6.25ドルとなっています。ここで数えられるのは「読んだ列のデータ量」で、行数でも結果件数でもありません。列指向のため、SELECTに書いた列だけが課金対象です。

もう一つ押さえておきたいのが同時実行の制約です。オンデマンドでは単一プロジェクトのすべてのクエリで共有される同時実行スロットが通常最大2,000で、小さなクエリを速く返すために一時的にこれを超えてバーストする場合もあります。つまり「安い代わりに遅い」のではなく「性能の保証がない」方式で、夜間バッチが集中して詰まる現象はこの上限に当たっています。

ストレージ料金は論理と物理の四区分で単価が二倍近く開いている

ストレージは、課金対象を非圧縮のバイト数で数える論理と、圧縮後の実バイト数で数える物理のどちらかをデータセット単位で選びます。さらにアクティブと長期の区分が掛かるため、単価は四通りです。us-central1の公式表示は次のとおりで、各区分とも毎月10GiBまで無料枠があります。

公式の換算例では、us-central1のアクティブ論理で1TiBを1か月保存すると23.552ドルです。物理は単価が高いぶん数えるバイト数が圧縮後になるため、圧縮が効くデータほど有利に傾きます。

取り込みと読み出しの費用はクエリのスキャン課金とは別に積み上がる

見落とされやすいのが取り込み側です。Cloud Storageやローカルファイルからのバッチ読み込みは、default-pipelineという共有スロットプールを使う限り無料でした。一方でストリーミングは有料で、Storage Write API（REST）によるストリーミング挿入は200MiBあたり0.01ドル、しかも成功した行が1行あたり最小1KBとして計算されます。小さなイベントを1行ずつ流す設計では、実データ量よりはるかに多く課金されます。

gRPC版のStorage Write APIは1GiBあたり0.025ドルで、毎月2TiBまでの無料枠が付きます。読み出し側のStorage Read APIには請求先アカウントごとに毎月300TiBの読み取り無料枠があり、ここを超えてから従量課金です。そしてEditionsのスロットは、ストレージ費用、BI Engine、ストリーミング挿入、Storage APIには適用されません。

オンデマンドとEditionsの分岐点をスロット時間あたりのスキャン量で計算する

1スロット時間あたり何GiB読めているかが切り替えの判定式になる

同じクエリ群を両方式で処理したときの金額を並べます。スキャン量をXテビバイト、消費したスロット時間をS時間、スロット単価をPドルとすると、オンデマンドは6.25X、EditionsはPSです。Editionsのほうが安くなる条件はPSが6.25Xより小さいときで、これを整理すると「X÷SがP÷6.25より大きい」となります。左辺は1スロット時間あたりのスキャン量です。

単価を入れると分岐点は次のようになります。Standardの0.04ドルなら1スロット時間あたり約6.6GiB、Enterpriseの0.06ドルなら約9.8GiB、Enterprise Plusの0.10ドルなら約16.4GiB。この値を上回るワークロード、つまり「巨大なテーブルを浅く読む」タイプならEditionsが有利です。逆に、少量のデータに対して複雑なウィンドウ関数やJOINを回して長時間スロットを占有するタイプは、オンデマンドのままのほうが安く済みます。

実測のスキャン量とスロット時間をジョブ履歴のビューから取り出す

判定に使う二つの値は、リージョン修飾したINFORMATION_SCHEMA.JOBSから直接取れます。過去180日ぶんのジョブ履歴が保持されているため、季節性がある構成でも判断材料は足ります。

SELECT
  SUM(total_bytes_billed) / POW(1024, 3) AS billed_gib,
  SUM(total_slot_ms) / 1000 / 3600       AS slot_hours,
  SAFE_DIVIDE(SUM(total_bytes_billed) / POW(1024, 3),
              SUM(total_slot_ms) / 1000 / 3600) AS gib_per_slot_hour
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
  AND creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)

SCRIPTを除外しているのは、マルチステートメントの親ジョブが子ジョブの合計を持つため、total_slot_msが二重に数えられてしまうからです。もう一点、total_bytes_billedはオンデマンドのプロジェクトでは実際の課金バイトですが、定額のプロジェクトでは参考値にすぎません。Editionsへ移った環境で「戻したらいくらか」を試算する用途なら使えますが、請求額そのものとは読み替えないでください。

三つのエディションの単価差と一年三年のコミットメントの選び分け

us-central1の従量課金はStandardが0.04ドル、Enterpriseが0.06ドル、Enterprise Plusが0.10ドル。1年・3年のコミットメントで単価は下がり、Enterpriseなら0.054ドルと0.048ドル、Enterprise Plusなら0.09ドルと0.08ドルになります。ただしコミットメントを購入できるのはEnterpriseとEnterprise Plusだけで、Standardには用意されていません。

コミットメントは最小50スロットから50スロット単位、購入したリージョン内でのみ使え、組織全体で共有できます。期間終了時に解約を設定していなければ自動更新される点も運用上の落とし穴です。課金の粒度は既定で1分を最小単位とした秒課金で、Fluidスケーリングをオプトインすると最小課金時間なしになります。短時間のクエリが散発する構成では、この最小1分が実効単価を押し上げます。

スキャン量を減らす設計はパーティション分割とクラスタリングで決まる

パーティション分割と必須フィルタの設定でスキャン事故を止める

時系列データなら、取り込み時刻または日付列でのパーティション分割が第一手です。WHERE句でパーティション列を絞ると、対象外のパーティションは読まれず課金対象から外れます。3年ぶんのログテーブルに対して直近7日だけを見るクエリなら、スキャン量は百分の一以下になります。

ただし、絞り忘れたクエリが1本混じるだけで全期間を読んでしまいます。これを防ぐのがテーブル定義側の必須フィルタ設定で、パーティション列の条件を書かないクエリをエラーで弾けます。共有データセットのファクトテーブルには原則として付けておきましょう。

クラスタリングは絞り込みに使う列の並び順で効き方が大きく変わる

クラスタリングは、指定した列の値でデータを並べ替えて格納し、絞り込み時に読むブロックを減らす仕組みです。パーティションより粒度が細かく、顧客IDや商品コードのようなカーディナリティの高い列に効きます。日付でパーティションを切ってから顧客IDでクラスタ化する併用が定番です。

注意点は列の並び順で、指定した順に効きます。第一列で絞らないクエリでは効果がほとんど出ないため、WHERE句に最も頻繁に現れる列を先頭に置いてください。またクラスタ化テーブルは実行前の見積もりバイト数が実際より大きく出ることがあり、コンソールの表示だけで「効いていない」と判断しないよう気をつけましょう。

列の選び方とプレビュー操作でスキャン量を数十分の一まで落とす

列指向である以上、全列を読む書き方はそのまま課金額に跳ね返ります。数十列あるテーブルから3列だけ使うなら、スキャン量も概ねその比率まで落ちるでしょう。中間結果を何度も参照するなら、都度計算するよりマテリアライズドビューに固定したほうが安くつく場合があります。

データを目視したいだけの場面では、クエリを投げずにテーブルのプレビュー機能を使ってください。無料の操作で、スキーマの確認やサンプル行の把握はこれで足ります。同一クエリの結果もキャッシュから返る限り課金されません。分析基盤全体としての層構成やETLの組み方は5層アーキテクチャでのデータ分析基盤の構築手順で扱っています。

ストレージ課金を論理と物理のどちらで受けるかを圧縮率から選び直す

データの圧縮率が論理と物理のどちらで請求を受けるかの分岐を決める

単価は物理が論理の約1.74倍です。したがって圧縮率が1.74倍を超えていれば物理のほうが安くなります。繰り返しの多い文字列や低カーディナリティの列が多いテーブルでは圧縮が3倍から10倍に達することも珍しくありません。逆に、すでに圧縮済みのバイナリが主体のテーブルでは差が出ません。

判断材料は推測ではなく実測から取ります。INFORMATION_SCHEMA.TABLE_STORAGEには論理バイト数と物理バイト数の両方が入っているため、データセット単位で比率を出せばそのまま切り替え判断になります。ただし物理ストレージではタイムトラベルとフェイルセーフのぶんも課金対象です。論理ではこれらが無課金なので、更新頻度が高いテーブルでは圧縮率が1.74倍を超えていても物理が得にならない場合があります。

九十日の長期保存タイマーがリセットされる操作を先に把握しておく

90日連続で変更されていないテーブルまたはパーティションは、自動で長期保存の単価に切り替わり約50%引きになります。性能・耐久性・可用性はまったく同じで、申請も設定も要りません。放置しているだけで安くなる、数少ない仕組みです。

問題は、この90日カウンタがリセットされる操作です。テーブルへの読み込み、コピージョブでの書き込み、クエリ結果の書き込み、DML文での変更、CREATE OR REPLACE TABLEでの置換、Storage Write API（REST）でのストリーミングが該当します。日次で全期間を洗い替えるバッチを組んでいると、古いデータもずっとアクティブ単価のままです。一方、クエリ、ビューの作成、エクスポート、別テーブルへのコピー元、テーブルリソースのパッチはリセットしません。読むだけなら安全だと覚えておけば設計を誤りません。

パーティション単位の長期保存とテーブル有効期限を組み合わせる

長期保存の判定はパーティションごとに独立して行われます。つまり日付でパーティションを切っておけば、直近ぶんだけがアクティブ単価で、90日を過ぎた過去ぶんは順次割引に落ちていくわけです。全期間を1テーブルに詰め込んで洗い替える構成と比べると、保存費用の差は年単位で大きく開きます。

そのうえで、保持期間が決まっているデータにはパーティションの有効期限を設定してください。監査ログのように「3年で消してよい」データを無期限に持ち続ける理由はありません。中間テーブルにはテーブル自体の有効期限を付け、消し忘れを仕組みで防ぎましょう。

INFORMATION_SCHEMAでのコスト監視と課金に歯止めをかける三段構え

日次の請求額をジョブ履歴から再現するクエリの書き方と落とし穴

公式ドキュメントが示す集計の型に沿うと、ジョブ履歴から日次のオンデマンド費用を再現できます。押さえるべき条件は三つあります。ジョブの請求日はジョブが動いたリージョンに関係なくend_timeのPST8PDT基準で決まること、SCRIPTを除外すること、そしてCREATE_MODELは単価が50倍になることです。学習ジョブの費用構造とモデル種別ごとの課金差はBigQuery MLをSQLで実装する手順で扱っています。

SELECT
  EXTRACT(DATE FROM end_time AT TIME ZONE 'PST8PDT') AS billing_date,
  SUM(total_bytes_billed) / POW(1024, 4) *
    IF(statement_type = 'CREATE_MODEL', 50 * 6.25, 6.25) AS usd
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
  AND end_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
GROUP BY billing_date
ORDER BY billing_date DESC

無料枠の1TiBはアカウント単位で効くため、この式は超過ぶんだけを見たいときには実際よりやや大きく出ます。厳密な突き合わせが要るなら請求データのエクスポートを併用してください。日次の推移と跳ねた日の特定という用途なら、こちらのほうが手軽で反応も速いはずです。

費用を押し上げているクエリと利用者をジョブ単位で特定する手順

跳ねた日が見つかったら、同じビューをuser_emailとquery単位に落として上位を並べます。よく出てくるのは、BIツールのスケジュール更新がフィルタなしで全期間を読んでいる、検証用のノートブックが本番テーブルを繰り返し走査している、といったパターンです。ジョブにラベルを付けておくと切り分けが楽になります。

カスタム割り当てと最大課金バイト数と予算アラートを重ねて使う

事前の歯止めは三段で組みます。第一にカスタム割り当てで、QueryUsagePerDayがプロジェクト全体の日次処理量、QueryUsagePerUserPerDayが利用者ごとの日次処理量を制限します。プロジェクト既定は1日200TiB、利用者別は既定で無制限。IAMと管理の割り当て画面から設定し、太平洋時間の深夜にリセットされます。超過するとusageQuotaExceededで実行前に拒否されるため、走らせてから気づく事態を防げます。適用されるのはオンデマンドのみで、予約ベースには効きません。

第二にクエリ単位の最大課金バイト数です。設定値を超えると見積もり段階でクエリが失敗するため、探索的な分析を開放する環境ではこれを既定値として配っておくと安全でしょう。第三はCloud Billingの予算とアラートで、金額ベースのしきい値を通知します。三つは役割が違い、日次の総量、単発の暴発、月次の着地をそれぞれ受け持ちます。どれか一つでは穴が残るため、重ねて使ってください。

費用の面から見た採用してよい条件と別の構成へ切り替えるべき場面

ここまでの数字を踏まえて、費用という観点から判断を言い切ります。機能面を含めた総合的な採用可否はBigQueryの採用条件と見送り場面を整理した記事にまとめてあります。

採用してよい条件はスキャン量と参照の集中度という二点で決まる

費用面で採用してよいのは、扱うデータが数百GiBから数十TiB規模にあり、参照が特定期間や特定キーに集中している場合です。この条件ならパーティション分割とクラスタリングが素直に効き、月あたりのスキャン量は保有データ量よりはるかに小さく収まります。無料枠の範囲で検証が完結することも多く、初期投資なしで判断材料が集まる点も利点です。

Editionsへの切り替えを検討してよいのは、実測の1スロット時間あたりスキャン量が先の分岐点を安定して上回り、かつ月次の変動が小さいときに限ります。変動が大きい構成でオートスケーラーの上限を高く置くと、ピークに引きずられて平均単価が跳ねます。まずはオンデマンドで数か月ぶんの実測を取ってから移りましょう。

別の構成へ切り替えるべきは小規模の集計と行単位の更新が中心の場面

見送るべき場面もはっきりしています。数GiB程度のデータに対する定型集計だけなら、既存のRDBMSやCloud SQLで足りるはずです。スキャン課金の利点が出るのは読むデータが大きいときであり、小さいデータでは運用の手間だけが増えます。行単位の参照や更新が中心の処理も向きません。DMLで頻繁に書き換える設計は長期保存の割引を打ち消し、タイムトラベル領域も膨らませます。業務システムの主データベースとして使う構成は、費用の面でも整合性の面でも別の選択肢を検討してください。マルチクラウド前提でAWS側に寄せる要件があるなら、課金モデルの異なるAmazon Redshift Serverlessの料金と移行判断と並べて比較する価値があります。

外部に任せる場合は見積書のどこを読めば費用の歯止めが分かるか

構築を外部に委託するなら、見積書で確認すべき箇所は決まっています。パーティション分割とクラスタリングの設計方針、必須フィルタ設定の有無、カスタム割り当てと最大課金バイト数の初期値を誰が決めるか、INFORMATION_SCHEMAベースの監視クエリが納品物に含まれるか。この四点が明示されていない見積書は、運用開始後にコストが読めなくなるリスクを抱えています。

逆にこれらが設計書に落ちていれば、内製へ引き継ぐときの引き渡しもきれいに進みます。データ分析基盤構築・MLOps構築支援では、費用の歯止めを含めた設計から運用移管までを前提に構成を組んでいます。構築ステップや体制の組み方はPoCから本番移行までの導入手順を、業種ごとの効果が出た条件はBigQueryの事例4類型を参照してください。

よくある質問

BigQueryは無料枠だけで運用を続けられますか？

検証段階なら現実的です。クエリは毎月1TiBまで、ストレージは各区分で毎月10GiBまでが無料枠にあたります。数GiBのデータを日次で集計する程度なら、この範囲に収まる場合が多いでしょう。ただし本番でBIツールから頻繁に参照する構成になると、1TiBはすぐに超えます。

オンデマンドとEditionsはどちらを選ぶべきですか？

最初はオンデマンドで始めてください。切り替えの判定は「1スロット時間あたりのスキャン量」がEnterpriseなら約9.8GiBを安定して上回るかどうかで、この値は数か月ぶんの実測がないと出ません。加えて、スロットを確保してもストレージやストリーミング挿入の費用は別建てで請求され続けます。下がるのはクエリ費用だけだと理解しておきましょう。

クエリ料金が想定外に膨らむのを事前に防げますか？

三段で防げます。プロジェクトと利用者に対するカスタム割り当て、クエリ単位の最大課金バイト数、そしてCloud Billingの予算アラートです。前二つは実行前に止める仕組みなので、走らせてから気づく事態を避けられます。

長期保存の割引は自分で申請する必要がありますか？

申請も設定も要りません。90日連続で変更がないテーブルまたはパーティションが自動で長期保存の単価に移り、約50%引きになります。性能や可用性が落ちることもありません。気をつけるべきは、洗い替えバッチやDMLでカウンタがゼロに戻る点だけです。

論理ストレージと物理ストレージはどちらが安いですか？

データの圧縮率しだいです。物理の単価は論理の約1.74倍なので、圧縮率がこれを超えれば物理が有利になります。ただし物理ではタイムトラベルとフェイルセーフのぶんも課金されるため、更新が頻繁なテーブルでは差が縮まります。INFORMATION_SCHEMA.TABLE_STORAGEで論理バイト数と物理バイト数の比率を実測してから決めてください。

関連記事

• BigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断：前提となる仕組みと採用可否の総論です。
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：層構成と実装手順をまとめています。
• Amazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説：課金モデルの異なるAWS側との比較材料です。
• BigQuery導入の手順と体制｜PoCから本番移行までと外注の判断：棚卸しから本番移行までの進め方を扱います。
• BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸：業種横断の導入パターンを整理した判断ハブです。