BigQueryの料金体系とコスト削減｜課金トラップと対策

BigQueryの請求書を初めて開いたとき、想定の3倍以上の金額が並んでいた。

Evastでもお客様の環境を引き継いだとき、この場面に何度も居合わせています。「サーバーレスだから安く済むと思っていた」という声とセットで、月の締めのタイミングで慌てて連絡をいただくのです。見覚えがある方は少なくないのではないでしょうか。

正直に言うと、BigQueryはとにかく使い始めのハードルが低いぶん、スキャン量（クエリが読み込んだデータの量）に課金されるという肝心のところが後回しになりがちです。ここを外したままダッシュボードや定期実行が積み上がると、あるとき請求書で足元をすくわれます。

現場で感じるのは、原因のほとんどが特殊な使い方ではなく、日常的なSQLとテーブル設計のクセに潜んでいる、ということ。この記事では、Evastが実運用で踏んできた課金トラップと、その具体的な直し方を、料金体系の要点から順にまとめています。

なお、これからBigQueryを導入する段階の方は、料金体系や無料枠を含む全体像をBigQuery導入ガイド｜手順・料金・無料枠・費用相場【2026年版】で先に押さえておくと、この記事の対策がそのまま設計に活かせます。

BigQueryの料金体系：なぜ「思ったより高い」が起きるのか

BigQueryの料金モデルは主に2つあります。オンデマンドはクエリのスキャン量（TB単位）に対して課金され、1TBあたり約$6.25です。Capacity（定額）は処理能力（スロット）を月次または年次で購入する方式で、クエリの実行回数に関係なく固定料金になります。

多くの企業が最初に選ぶオンデマンドの注意点は、クエリがスキャンしたデータ量に対して料金が発生するという点です。結果として返ってくる行数ではなく、クエリが読み込んだカラムのデータ量が課金の基準になります。

例えば、100GBのテーブルに対して SELECT * を実行した場合、WHERE句で1行しか返らなくても、100GB分のスキャン料金が発生します。これが多くの現場で「思ったより高い」が起きる根本的な原因です。

キャッシュと無料枠について

クエリ結果は24時間キャッシュされ、同一クエリの再実行はスキャン料金が発生しません。また、月あたり1TBまでは無料枠があります。ただし、テーブルの内容が更新されると同一クエリでもキャッシュが無効になるため、毎日更新されるデータに対しては期待しすぎないことが重要です。

Evastが実運用で踏んだ課金トラップ5選

トラップ1：SELECT * の乱用

何が起きたか： 分析用クエリをCloud Schedulerで定期実行していた際、開発時の SELECT * がそのまま本番に残り、月次コストが数十万円に膨らんでいました。

なぜ高くなったか： 対象テーブルは100以上のカラムを持つ横長な構造で、実際に使っていたのはそのうち8カラムでした。全カラムをスキャンすることで、本来の約12倍のデータを読み込んでいました。

どう直したか： SELECT * を必要なカラム名の列挙に変更しました。これだけでスキャン量が約1/10に削減され、そのクエリに限れば月次コストが90%近く下がりました。

トラップ2：パーティション未設定のテーブルへの全量スキャン

何が起きたか： ETLで毎日取り込んでいる約2年分のログデータ（全量500GB超）に対し、「昨日分だけ」のWHEREフィルターをかけたクエリが毎朝実行されていました。

なぜ高くなったか： テーブルに日付パーティション（日付などのキーでテーブルを内部的に分割し、必要な範囲だけをスキャンできるようにする仕組み）が設定されていなかったため、WHERE date = '2026-06-09' というフィルターがあっても、BigQueryは全テーブルをスキャンします。1日分のデータが1GBでも、スキャンは毎回500GB分です。

どう直したか： テーブルを作り直し、取り込み日時カラムで日付パーティションを設定しました。同じクエリのスキャン量が500GBから1GBに、月次コストが約40%削減されました。

トラップ3：開発中のアドホッククエリがそのまま本番で動き続ける

何が起きたか： 検証目的で書いたクエリをCloud Schedulerに登録したまま、プロジェクト終了後も1年以上動き続けていました。

なぜ高くなったか： 検証クエリは精度よりスピード優先で書かれており、不要なJOINや全量スキャンが含まれていました。利用実績がなかったため誰も気づかず、月数万円を無駄に消費していました。

どう直したか： INFORMATION_SCHEMAでCloud Schedulerから実行されているジョブ一覧と月次コストを確認し、不要なジョブを整理しました。「使っていないジョブは止める」という運用ルールも合わせて整備しました。

トラップ4：ETLで取り込んだ生データに直接集計クエリを投げ続ける

何が起きたか： Google Ads・GA4から毎日取り込んだ生データテーブルに、週次レポートのたびに集計クエリを直接投げていました。

なぜ高くなったか： 生データテーブルは数千万行規模で、集計のたびに全期間をスキャンするクエリが複数走ります。レポートを見るたびに同じスキャンを繰り返す構造になっていました。

どう直したか： dbtでマートテーブル（あらかじめ集計・加工しておき、レポートが直接参照する完成形のテーブル）を作成し、生データからの集計を日次バッチとして1回だけ実行する構成に変更しました。レポートはマートテーブルへの軽量なクエリのみになり、スキャン量が全体で約70%削減されました。

トラップ5：ストレージコストの見落とし

何が起きたか： 検証用テーブルや中間テーブルを削除せずに放置し、ストレージ料金が月次で数万円積み上がっていました。

なぜ高くなったか： BigQueryのストレージ料金は、アクティブストレージが$0.02/GB・月、90日以上アクセスのない長期保管ストレージが$0.01/GB・月です。数百GBの不要テーブルが積み重なると無視できない額になります。

どう直したか： INFORMATION_SCHEMAで最終アクセス日とテーブルサイズを一覧化し、90日以上使われていないテーブルを定期削除するルールを設けました。合わせて、中間テーブルには有効期限（テーブル有効期限設定）を付ける運用に変更しました。

コスト削減の設計原則3つ

必要なカラムだけ取る

SELECT * は開発の初動では便利ですが、本番クエリには使いません。カラムを明示的に指定するだけで、横長なテーブルでは10分の1以下にスキャン量を抑えられます。コードレビューの段階で SELECT * をチェックする運用ルールを設けると、この問題は構造的に防げます。

BigQueryでは SELECT句のカラム指定がそのままスキャンコストに直結します。特にネストされたARRAYカラムを含むテーブルでは、不要なカラムを除外する効果が顕著です。

パーティションとクラスタリングを必ず設定する

テーブルを新規作成する際は、日付・タイムスタンプカラムによるパーティション設定を必須にします。加えて、WHERE句でよく使うカラム（ユーザーIDやキャンペーンIDなど）でクラスタリング（指定したカラムの値が近いデータを物理的にまとめて並べておく仕組み）を設定すると、スキャン量をさらに絞り込めます。

パーティションとクラスタリングはテーブル作成後に追加できません（テーブルを再作成する必要があります）。設計段階で入れておくのが最も低コストです。ETLパイプラインの設計時に、パーティション設定を要件に含めてください。なお、パイプライン設計で押さえるべき全体像は、データパイプラインとは？ETLとの違いと仕組みを図解で解説で整理しています。

マートテーブルで集計済みデータを再利用する

同じ集計ロジックを毎回生データから走らせるのは、コストと時間の二重損失です。生データに対する集計は日次または週次の定期バッチで1回だけ実行し、結果をマートテーブルに保存します。レポートやダッシュボードはそのマートテーブルに対してクエリを投げる構成にします。

この設計は、dbtと組み合わせると管理しやすくなります。マートテーブルの定義をdbt Modelとして管理することで、集計ロジックのバージョン管理とデータ品質テストが実現できます。詳しくはdbtとは？BigQueryのデータ変換を効率化するツールを解説を参照してください。

クエリコストを事前に把握する方法

ドライランによるスキャン量の事前確認

BigQueryにはクエリを実際に実行せず、スキャン量だけを見積もるドライラン機能があります。bqコマンドラインツールでは --dry_run フラグで実行できます。

bq query --dry_run --use_legacy_sql=false \
  'SELECT user_id, revenue FROM `project.dataset.orders` WHERE date = "2026-06-09"'

出力されるバイト数からスキャン料金の目安を計算できます。本番に投入する前に確認する習慣をつけると、想定外の課金を防げます。

BigQuery UIのコスト見積もり

クエリエディタにSQLを入力すると、右上に処理されるデータ量が表示されます（例：「このクエリは実行時に 12.5 GB を処理します」）。実行ボタンを押す前にここを確認するだけで、日常的なコスト管理になります。

INFORMATION_SCHEMAによる課金分析

過去のクエリコストを一覧化する場合は、INFORMATION_SCHEMA.JOBS を使います。以下のクエリで、直近7日間のジョブ別スキャン量を確認できます。

SELECT
  user_email,
  job_id,
  ROUND(total_bytes_processed / POW(1024, 4), 4) AS tb_processed,
  ROUND(total_bytes_processed / POW(1024, 4) * 6.25, 2) AS estimated_usd,
  creation_time,
  query
FROM
  `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
ORDER BY
  total_bytes_processed DESC
LIMIT 20;

このクエリを定期実行してSlackに通知する仕組みを作ると、コストの異常値に早期に気づけます。

EvastのアドヨミAIで実践しているコスト管理

Evastが複数のクライアント向けに運用しているアドヨミAIは、Google Ads・GA4・Search Consoleのデータを毎日BigQueryに取り込み、dbtのマートテーブルに集約してからレポートを生成する構成です。

「生データに毎回集計クエリを投げない」が設計の中心にあります。ETLで取り込んだ生データはそのまま分析に使わず、dbtで定義したマートテーブル（キャンペーン単位の日次集計、ページ別のセッション集計など）を経由します。レポートクエリは集計済みのマートテーブルに対してのみ実行するため、1クエリあたりのスキャン量が生データ直撃の場合と比較して数十分の一になります。

このように「先にBigQueryへロードし、変換はDWH（データウェアハウス）内で行う」構成は、ELT（Extract・Load・Transform）と呼ばれる方式です。ETLとの違いやコスト構造への影響は、ETLとELTの違いとは？5つの比較軸とELTが主流になった理由で詳しく解説しています。

Cloud Schedulerのスケジュール設計も重要です。ETLの実行は業務時間外（深夜〜早朝）に限定し、不要な時間帯のジョブ起動を避けます。同じマートテーブルを参照するレポートが複数ある場合は、マート更新完了後に一括で参照する依存関係を持たせることで、マートの再計算を防ぎます。

ETLパイプライン設計の基本については、ETLとは？データ統合の基礎と選定ポイントを解説も参照してください。データ基盤全体の構成要素から押さえたい方は、データ基盤とは？企業が導入すべき3つの理由と構成要素を解説もあわせてご覧ください。

まとめ：コスト最適化は設計段階から

BigQueryのコストは「使い始めてから最適化する」より「設計時に組み込む」ほうが、直す手間が圧倒的に少なくなります。パーティション設定の後付けはテーブル再作成が必要で、大量データがある場合は数時間の作業になります。

コスト管理の核心は「何をどれだけスキャンしているかを把握すること」です。INFORMATION_SCHEMAを使った可視化とCloud Schedulerのジョブ棚卸しを月に一度行うだけで、無駄なコストの多くは防げます。BigQuery以外も含めたデータ基盤全体のランニングコストの下げ方はデータ基盤のランニングコスト削減｜4要素別の見直し方でまとめています。なお、同じクラウドDWHでも稼働時間で課金されるSnowflakeは最適化の勘所が異なり、Snowflakeの料金体系とコスト削減｜クレジット課金の落とし穴で解説しています。BigQuery・Snowflake・Redshiftを費用で比べたクラウドDWH費用比較もあわせてどうぞ。

データ基盤構築のご相談はEvastへ

Evastでは、BigQueryを活用したデータ基盤の設計・構築・コスト最適化を支援しています。スキャン量の可視化からパーティション設計の見直し、マートテーブルの構成まで、設計段階に踏み込んだ相談に対応します。

• 「BigQueryのコストが想定より高く、原因を特定したい」
• 「ETL設計を見直してコストを削減したい」
• 「dbt + BigQueryでマートテーブルの構成を整えたい」

現状診断から改善提案まで、ご相談ください。

→ データ基盤構築サービスを見る → 無料相談を申し込む