BigQueryのコスト削減で最初に見るべきはSQLではない

BigQueryの請求が増えても、最初からSQLやテーブルを直してはいけません。料金モデルと利用項目を特定しなければ、変更しても請求は下がらないからです。

請求レポートをSKUとプロジェクトで分け、増加項目と高額ジョブを結んでからSQLを直します。

BigQueryのコスト削減は、請求のSKUとプロジェクトの一致から始めます

BigQueryの計算料金には、処理バイト数で払うオンデマンド料金と、スロットの利用時間で払う容量料金があります。まずCloud BillingをSKUとプロジェクトで分け、増えた項目がオンデマンド分析、予約、ストレージなどのどれに当たるかを確認します。Google Cloudの公式調査手順も、SKUを特定してから対応するINFORMATION_SCHEMAビューを調べる順番を案内しています。

2026年8月12日時点のBigQuery公式料金表では、東京リージョンのオンデマンドクエリは、請求先アカウントあたり月間1TiBまでの処理データが無料で、超過分は1TiBあたり6.25米ドルです。容量料金とストレージ料金は対象外です。

請求総額だけでは、利用増加、クレジット、前払い契約の影響を分けられません。比較期間、プロジェクト、SKU、通貨を固定して確認します。BigQuery以外も含む場合は、Google Cloudのコスト削減で請求を分解する手順を先に確認します。

BigQueryのコスト削減では、「高いSQL」ではなく「高くついたジョブ」を探します

オンデマンド分析が増えたら、INFORMATION_SCHEMA.JOBS_BY_PROJECTでジョブを調べます。JOBSビューの公式仕様では、請求対象バイト数、スロット消費、実行者、SQL、ラベルを確認できます。

次の例は東京リージョンの直近30日が対象です。期間は請求レポートに合わせます。

SELECT
  user_email,
  job_id,
  creation_time,
  total_bytes_billed,
  total_slot_ms,
  labels,
  query
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
  AND statement_type != 'SCRIPT'
ORDER BY
  total_bytes_billed DESC;

一回の処理量だけでは、定期実行の影響を見落とします。SQLやラベルごとに回数と処理量を集計し、BI、定期処理、手動分析へ所有者を割り当てます。

JOBSビューにはSQL本文と実行者情報が含まれるため、閲覧ロールと共有先を限定します。改善候補は個人の能力ではなく、所有者、実行契機、承認者、停止条件の有無で評価します。

BigQueryのコスト削減は、オンデマンド課金と容量課金で方法が違います

同じ「クエリが高い」でも、オンデマンド（スキャン課金）とスロット課金（容量料金）では、減らすべき数字が違います。オンデマンドは読み取ったバイト数への課金なので、列の絞り込み、パーティション、クラスタリング、maximum bytes billed のような「読む量を減らす」対策がそのまま請求に効きます。

容量課金では、固定のベースライン・コミットメントと自動スケーリング分を分けます。BigQueryの公式料金は、容量料金をスロット時間で計測しています。クエリの負荷を下げると自動スケーリング分は減る可能性がありますが、固定分は自動では下がりません。

BigQueryの予約の公式仕様を基に、ベースライン、自動スケーリングの上限、割当先を見直します。total_slot_msを減らした後、固定容量を縮小できるか確認します。

料金モデルは処理量の安定度で選び、オンデマンド換算額とスロット時間を比べます。

BigQueryのコスト削減では、スキャン量がテーブル設計で大きく変わります

高額なジョブは、必要な列と行だけを読む形へ変えます。クエリ計算量の公式ガイドは、SELECT *を避けて必要な列を指定するよう勧めています。

時系列データは日付や時刻で分割します。パーティションテーブルの公式仕様によると、適格な条件を指定すると不要なパーティションを読み飛ばせます。

require_partition_filterは、除外に使える条件がないクエリをエラーにします。ビューにも要件が及ぶため、既存のBIやバッチを調べてから有効にします。

顧客IDやアカウントIDで頻繁に絞る場合はクラスタリングを検討します。クラスタリングテーブルの公式仕様では、条件に合わないストレージブロックを実行時に読み飛ばします。

効果は分布と条件式で変わります。変更前後の処理量、時間、失敗、影響を比べます。

SKUとジョブを結んでも変更順を決められない場合は、BigQueryコスト削減支援で、請求項目と実行履歴を一緒に確認できます。

上限と変更権限がなければ、請求はまた膨らみます

オンデマンド料金では、maximum bytes billedを設定できます。推定処理量が上限を超えると、クエリは課金なしで失敗します。

クラスタリングテーブルの推定値は実額より大きい場合があり、実際は上限内のクエリでも失敗する可能性があります。BIや締め処理を止めた場合の連絡先と上限を変更できる人も決めます。制約はBigQueryのコスト制御に関する公式ガイドで確認できます。

予算通知は調査開始の合図です。通知、所有者確認、上限変更、業務影響の承認を分担します。運用を委託している場合は、契約に請求レビュー、変更承認、実装、効果確認の担当が含まれるかを確認します。

ストレージと料金モデルにも削れる余地があります

クエリの次はストレージ料金を確認します。BigQueryのストレージ公式仕様では、データセット単位で論理バイト課金と物理バイト課金を選べます。

論理課金は非圧縮サイズを基にし、タイムトラベルとフェイルセーフを基本料金に含みます。物理課金は圧縮後のサイズを基にしますが、両保存領域が別途課金されます。保持方針を含めて見積もります。

2026年8月12日時点のBigQuery公式料金表では、テーブルまたはパーティションが連続90日間変更されない場合、保存単価は自動的に50%下がります。対象はBigQuery内の保存領域であり、外部データソースには適用されません。一時テーブルには有効期限を設定し、保存義務のあるデータは削除承認を先に決めます。

複数クラウドの費用を比較する場合は、AWSのコスト削減で請求と利用量を照合する手順と費用指標を揃えると、サービス名の違いに引っ張られにくくなります。

BigQueryのコスト削減は、請求とジョブ履歴が毎月つながる運用で続けます

新しいダッシュボードや定期処理が増えると、修正後の請求も変わります。月次レビューでは、財務担当者がSKU別の増減を確認し、データ基盤の担当者が増加したジョブとテーブルを特定します。業務担当者は必要性と停止条件を確認します。

修正後は、請求対象の処理量、ストレージ使用量、月次費用、実行時間、失敗、データ鮮度を確認します。ジョブには所有者、環境、用途、費用配賦先を示すラベルを付け、作成時に終了条件も記録します。

SQLを直す前に答える三つの質問

LIMITを付けるとBigQueryの料金は下がりますか？

非クラスタリングテーブルでは、LIMITで返却行数を減らしても読み取るデータ量は減りません。必要な列の指定とパーティション条件を先に見直します。クラスタリングテーブルでは処理量が減る場合があるため、実行結果の請求対象バイト数で確認します。

BigQueryの高額なクエリはどこで確認できますか？

Cloud Billingでオンデマンド分析のSKUとプロジェクトを特定した後、同じ地域のINFORMATION_SCHEMA.JOBS_BY_PROJECTを確認します。請求対象バイト数、実行回数、実行者、ラベル、SQLを並べます。容量料金を利用している場合は、予約とコミットメントの情報も合わせて確認します。

パーティションとクラスタリングは同時に使えますか？

併用できます。期間で大きく絞れる時系列データはパーティションを先に設計し、各パーティション内で頻繁に絞る列をクラスタリング候補にします。実際の条件式とデータ分布で効果が変わるため、変更前後を同じクエリで測ります。

明日は請求SKUと高額ジョブを一つ結び付けます

Cloud BillingでBigQueryのSKUを開き、増加額が大きいプロジェクトを一つ選んでください。オンデマンド分析なら、同じ期間のINFORMATION_SCHEMA.JOBS_BY_PROJECTを開きます。

請求対象バイト数の大きいジョブを一件選び、job_id、user_email、total_bytes_billed、用途を記録します。同じSQLやラベルの実行回数も集計します。容量料金なら、予約名、ベースライン、オートスケール上限、割当先を同じ期間で確認します。

明日はSQLを書き換えません。請求書の一項目と、費用を生んだジョブまたは予約を一組だけ結び付けることです。変更後も同じ組を見れば、削減額を説明できます。