BigQueryの料金が高くなる原因と削減方法｜クエリとテーブル設計の見直しポイント
BigQueryは、サーバーの管理をせずに大量のデータを集計できるデータウェアハウスとして、多くの企業で使われています。使い始めのうちは無料枠の範囲に収まることも多い一方で、データ量や利用者が増えるにつれて、ある月から請求額が急に増えたという相談は少なくありません。
BigQueryの料金が高くなる原因の多くは、製品の単価そのものよりも、クエリの書き方、テーブルの設計、ダッシュボードや定期処理の設定にあります。同じデータ、同じ集計結果でも、読み込むデータ量が10倍違えば、オンデマンド料金では費用もほぼ比例して変わります。
逆にいえば、料金の仕組みを理解して、費用がどこで発生しているかを特定できれば、機能を削らずに費用を下げられる余地は大きいということです。闇雲に利用を制限するより、原因の大きいところから順に手を打つほうが効果的です。
この記事では、BigQueryの料金の仕組み（2026年10月時点の公式情報にもとづく）、費用が膨らむ典型的な原因、クエリとテーブル設計の見直しポイント、料金モデルと上限設定による管理の方法を、発注側・管理側の視点で解説します。
BigQueryの料金の仕組み
BigQueryの費用は、大きく「コンピューティング（クエリの実行）」と「ストレージ（データの保管）」に分かれます。ここでは、Google Cloudの公式料金ページで2026年10月時点に確認できた内容を整理します。料金は改定されることがあり、リージョンによっても単価が異なるため、実際の契約前には必ず公式ページで最新の金額を確認してください。
| 項目 | 主な内容（米国アイオワリージョンの例） |
|---|---|
| オンデマンドのクエリ料金 | クエリが処理したデータ量に応じた課金。1TiBあたり6.25ドルで、毎月最初の1TiBは無料 |
| 容量ベースのクエリ料金 | スロット（仮想CPU）の利用時間に応じた課金。Standard、Enterprise、Enterprise Plusの3つのエディションがあり、従量課金ではStandardが1スロット時間あたり0.04ドル、Enterpriseが0.06ドル |
| アクティブストレージ | 直近90日以内に変更されたテーブルやパーティションのデータ。毎月最初の10GiBは無料 |
| 長期保存ストレージ | 90日連続で変更されていないテーブルやパーティションは、自動的に単価が約50%下がる。性能や可用性は変わらない |
| データの取り込み | 共有スロットを使うバッチ読み込みは無料。ストリーミングでの取り込みは有料 |
オンデマンド料金で押さえておきたいのは、課金の対象が「結果の行数」ではなく「処理したデータ量」である点です。BigQueryは列単位でデータを保持しているため、選択した列の全データが課金対象になります。公式ドキュメントでも、結果にLIMITを指定しても、クラスタ化されていないテーブルでは読み込むデータ量は減らないと説明されています。
また、課金は1MB単位で切り上げられ、クエリが参照するテーブルごと、クエリごとに最低10MBが計上されます。エラーになったクエリや、キャッシュから結果を返したクエリには課金されません。
BigQueryの料金が高くなる典型的な原因
請求額が増えたときに確認すべき原因は、ある程度パターンが決まっています。自社の使い方に当てはまるものがないか、次の表で確認してみてください。
| 原因 | 起きていること | 起きやすい状況 |
|---|---|---|
| SELECT *の多用 | 不要な列まで読み込み、処理量が増える | 分析者がデータの中身を確認するために全列を取得している |
| パーティションを使っていない | 直近1日分だけ見たいのに、全期間のデータを毎回読み込む | ログや取引履歴など、日付とともに増え続けるテーブル |
| ダッシュボードの頻繁な更新 | 閲覧やフィルタ操作のたびに、大きなテーブルへのクエリが発行される | BIツールから元の大きなテーブルを直接参照している |
| 定期処理の重複 | 同じ集計を複数の担当者やツールが別々に実行している | 部署ごとにスケジュールクエリを作り、全体を誰も把握していない |
| 全件洗い替えの処理 | 毎日、全期間のデータを削除して入れ直している | 差分だけを処理する設計になっていないデータ連携 |
| 不要なデータの保管 | 使われていない中間テーブルや古いコピーがストレージを占める | 試行錯誤の途中で作ったテーブルが削除されずに残っている |
費用の大部分がクエリ料金なのかストレージ料金なのかで、優先すべき対策は変わります。まずはCloud Billingのレポートで、BigQueryの費用をSKU（料金の項目）ごとに分けて確認します。クエリ料金が大半であれば、どのユーザーやサービスアカウントが、どのクエリでデータを多く処理しているかを、INFORMATION_SCHEMAのジョブ履歴から調べるのが次の一手です。処理量の多い上位数件のクエリが費用の大半を占めていることはよくあり、その数件を直すだけで全体の費用が大きく下がる場合があります。
費用の内訳を調べる手順
原因の調査は、次の順番で進めると無駄がありません。社内に担当者がいない場合も、この順番で開発会社に調査を依頼すれば、見積もりや報告の内容を確認しやすくなります。
- Cloud Billingのレポートで、BigQueryの費用をクエリ、ストレージ、取り込みの項目に分けて、月ごとの推移を見る
- 費用が増え始めた月を特定し、その時期に追加したダッシュボードや定期処理、データ連携がないかを確認する
- ジョブ履歴から、処理したデータ量の多い順にクエリを並べ、実行したユーザーやサービスアカウントを確認する
- 上位のクエリが、人の手で実行されたものか、BIツールや定期処理から自動で実行されたものかを分ける
人の手で実行したクエリが上位なら、書き方の周知とルールづくりが効きます。BIツールや定期処理が上位なら、参照するテーブルや実行頻度という仕組みの側を直す必要があります。どちらのタイプかによって、相談すべき相手と対策が変わります。
クエリの見直しポイント
オンデマンド料金で使っている場合、クエリの見直しは最も即効性のある対策です。公式のベストプラクティスとして挙げられているものも含め、確認したい点は次のとおりです。
- 必要な列だけを指定し、SELECT *を使わない
- データの中身を確認したいときは、クエリではなくテーブルのプレビュー機能を使う（プレビューは課金されない）
- パーティション列（日付など）で必ず絞り込み、読み込む期間を限定する
- 実行前にクエリ検証の表示やドライランで、処理されるデータ量の見積もりを確認する
- 同じ集計を繰り返す場合は、中間結果を小さなテーブルに書き出して再利用する
このうち、プレビュー機能の利用とSELECT *の禁止は、分析者への周知だけで始められます。特に、データの中身を確かめるためにSELECT * … LIMIT 10のようなクエリを実行する習慣は、テーブルが大きいほど費用がかかるため、早めに改めたいところです。
ダッシュボードからのクエリについては、BIツールが元の大きなテーブルを直接参照していないかを確認します。日次で集計した小さなテーブル（データマート）を用意し、ダッシュボードはそちらを参照するようにすれば、閲覧のたびに読み込むデータ量を大幅に減らせます。BIツール側のデータ更新頻度も、実際に必要な鮮度に合わせて見直します。毎朝の会議で見るだけのダッシュボードなら、数分おきに更新する必要はありません。
テーブル設計の見直しポイント
クエリの書き方を徹底しても、テーブルの設計が読み込み量を減らせない形になっていると効果は限られます。設計面で見直したいのは、主に次の4点です。
パーティション分割
日付やタイムスタンプでテーブルをパーティション分割しておくと、WHERE句で期間を絞ったときに、該当するパーティションだけが読み込まれます。ログや取引履歴のように時間とともに増えるテーブルでは、最初に検討すべき設定です。パーティションの絞り込みを必須にする設定を有効にすれば、期間の指定を忘れたクエリそのものを実行できなくすることもできます。
クラスタリング
顧客IDや店舗コードなど、よく絞り込みに使う列でクラスタリングしておくと、条件に合うデータのブロックだけを読み込むようになり、処理量を減らせます。パーティションと組み合わせて使うのが一般的です。
集計済みテーブルとマテリアライズドビュー
多くの利用者が同じ切り口で集計するなら、元データから毎回計算するのではなく、集計済みのテーブルやマテリアライズドビューを用意します。読み込むテーブルが小さくなるほど、クエリ料金は下がります。
保存期間と差分処理
一時的な分析用のテーブルには有効期限を設定し、不要になったデータが自動で削除されるようにします。また、毎日全期間を洗い替える処理は、新しく増えた分や変更された分だけを処理する差分方式に変えることで、クエリ料金と同時にストレージの単価も抑えられます。変更されていないパーティションは長期保存ストレージとして安い単価が適用されるためです。
ストレージの課金方式
ストレージの費用が大きい場合は、課金方式も確認します。BigQueryのストレージには、圧縮前のデータ量で課金する論理ストレージと、圧縮後のデータ量で課金する物理ストレージの2つの方式があります。公式の料金表では、物理ストレージのほうが1GiBあたりの単価は高く設定されていますが、圧縮が効くデータであれば課金対象の量が減るため、総額が下がる場合があります。ただし、物理ストレージではタイムトラベルやフェイルセーフのためのストレージにも料金がかかります。どちらが安くなるかはデータの圧縮率と更新の頻度によって変わるため、データセットごとに両方の方式で試算してから切り替えるのが安全です。
当社が関わった不動産販売業者向けの物件データ収集基盤では、データの持ち方とクエリを見直し、機械学習で処理対象を事前に絞り込むことで、データ処理コストを80%削減しつつ、抽出できる物件数を2倍にしました。費用削減と機能の向上は両立できることが多く、その鍵は「何を読み込まずに済ませるか」を設計することにあります。
参考：パーティション分割テーブルに対するクエリ／Google Cloud
料金モデルと上限設定で費用を管理する
クエリとテーブルを見直したうえで、料金モデルの選択と上限設定によって、費用の振れ幅を抑えます。
| 状況 | 向いている料金モデル |
|---|---|
| 処理量が少なく、無料枠の1TiB前後で収まる。利用が不定期 | オンデマンド。上限設定と組み合わせて使う |
| 処理量が多く、毎月の費用を予測可能にしたい | エディション（容量ベース）。自動スケーリングの上限を決めて使う |
| 一年を通じて安定して大量の処理がある | エディションの1年または3年のコミットメント（EnterpriseとEnterprise Plusで利用可能） |
どちらが安いかは、処理量と処理の時間帯の偏りによって変わります。オンデマンドで多くのデータを処理していても、処理が短時間に集中しているなら容量ベースのほうが安くなることがあり、その逆もあります。過去数か月のジョブ履歴から、処理量とスロットの使用時間の両方を集計し、両方のモデルで試算してから切り替えるのが確実です。
あわせて、次のような上限と通知の設定をしておくと、想定外の高額請求を防ぎやすくなります。
- クエリごとに課金される最大バイト数を設定する（見積もりが上限を超えると、課金されずにクエリが失敗する）
- プロジェクトやユーザー単位で、1日あたりのクエリ処理量の上限を設定する
- Cloud Billingで予算と通知を設定し、一定の割合を超えたら担当者に知らせる
なお、予算の通知を設定しただけでは利用は止まりません。通知を受けたら誰が何を確認するのかまで決めておくことが大切です。
参考：カスタムクエリの割り当てを作成する／Google Cloud
参考：予算と予算アラートの作成、編集、削除／Google Cloud
まとめ
BigQueryの料金が高くなる原因の多くは、読み込むデータ量の多さにあります。オンデマンド料金では処理したデータ量に応じて課金され、LIMITでは処理量が減らないため、必要な列だけを選ぶこと、パーティションとクラスタリングで読み込む範囲を絞ること、ダッシュボードには集計済みの小さなテーブルを参照させることが基本の対策になります。
明日からできることとしては、まずCloud BillingでBigQueryの費用をクエリとストレージに分けて確認し、クエリが中心ならジョブ履歴から処理量の多い上位のクエリを洗い出してください。上位数件の原因が、全列の取得なのか、期間の絞り込み漏れなのか、ダッシュボードの更新頻度なのかが分かれば、打つべき手は自然に決まります。あわせて、最大課金バイト数と予算通知を設定しておけば、見直しが終わるまでの間も急な費用増に備えられます。