BigQueryの料金が高い原因と下げ方｜クエリと保存の見直し手順

広告・GA4・CRMのデータをBigQueryに集めて分析を始めたところ、請求額が想定より増えていた。マーケティングや事業部門でBigQueryを使い始めると、よく起きることです。

BigQueryの費用の多くは、クエリが読み込んだデータの量で決まります。そのため、どのクエリが、どれだけのデータを、何回読んでいるかが分かれば、下げる方法も見えてきます。

本記事では、まずBigQueryの料金の仕組みと、料金が高くなる典型的な原因を解説します。

そのうえで、どこで費用が出ているかを調べるSQLと、その結果から分かることをデモ用のデータで紹介し、クエリと保存の費用を下げる方法を説明します。ClaudeなどのAIからBigQueryを使うときの注意点もあわせて解説します。

BigQueryの料金の仕組み

BigQueryの費用は、大きく分けて、クエリを実行する費用（コンピューティング）と、データを保存する費用（ストレージ）の2つです。

単価はリージョンによって異なります。

本記事では、日本の企業が使うことの多い東京リージョン（asia-northeast1）の、2026年10月時点の単価を記載します（BigQueryの料金（別タブで開く））。

同じページで、アイオワ（us-central1）のオンデマンド料金は1TiBあたり $6.25 です。データセットを米国のリージョンに作っている場合は、そのリージョンの単価を確認してください。

米ドル以外の通貨で支払う場合は、Cloud Platform SKU に記載されている、その通貨の料金が適用されます。

クエリの料金：オンデマンド料金とEditions

標準の料金体系は、クエリが処理したデータ量（バイト数）に応じて課金される「オンデマンド料金」です。毎月1TiBまでは無料です。

オンデマンド料金では、次の点が費用に影響します（BigQueryの料金（別タブで開く））。

• 選んだ列のデータ量で課金される：BigQueryは列ごとにデータを保存しているため、読む列が多いほど処理量が増える
• LIMITを付けても減らない：結果の行数を絞っても、選んだ列のデータはすべて処理したものとして課金される
• 最小の処理量がある：クエリが参照するテーブルごとに10MB、クエリごとに10MBが最小になる
• キャッシュから返った結果とエラーになったクエリは無料：同じ結果がキャッシュにあれば、料金はかからない

もう1つの料金体系が「Editions」（容量料金）です。処理量ではなく、クエリの実行に使った計算資源（スロット）の時間に応じて課金されます。

Standard・Enterprise・Enterprise Plus の3つのエディションがあり、使う量に合わせて自動でスロットを増減でき、1分を最小単位として課金されます。

マーケティング部門の分析のように、クエリの量が少なく、時間帯によって偏る使い方では、まずオンデマンド料金のまま、処理量を減らす見直しから始めるのが一般的です。本記事も、オンデマンド料金を前提に説明します。

ストレージの料金：アクティブと長期、論理と物理

保存の料金は、テーブルやパーティションが最近変更されたかどうかで変わります。

90日間連続して変更されていないテーブル、またはパーティションは「長期ストレージ」となり、料金が自動的に約50％割り引かれます。性能や耐久性は変わりません。

また、データの量を圧縮前の大きさ（論理）で数えるか、圧縮後の大きさ（物理）で数えるかを、データセットごとに選べます。初期値は論理です。

物理の単価は論理より高いものの、圧縮が効くデータでは、物理の方が安くなることがあります。比べ方は後述します。

BigQueryの料金が高くなる典型的な原因

マーケティング・事業部門での使い方で、費用が増える原因の多くは次のいずれかです。

1回あたりの処理量は小さくても、ダッシュボードや定期実行のクエリは回数が多いため、月の合計では大きくなります。

逆に、担当者が手で実行するクエリは、1回の処理量が大きくても回数が少なく、全体に占める割合は小さいことが多いです。

どこで費用が出ているかを調べると分かること

費用を下げる前に、どのクエリに費用がかかっているかを調べます。

BigQueryには、実行されたクエリの記録（ジョブの履歴）を参照できる「INFORMATION_SCHEMA.JOBS」というビューがあります。誰が、いつ、どのクエリを実行し、何バイトを処理したかを、SQLで集計できます。

次の画面は、中小企業のマーケティング部門を想定したデモ用のデータで、東京リージョンのBigQueryの1か月分（2026年9月）のジョブの履歴を集計したものです。

Claudeで作成した、クエリの種類別・アカウント別の処理量と費用（デモ用のデータ）

この例では、1か月に6,368件のクエリが実行され、処理量は38.2TiB、無料枠の1TiBを引いた後の推定費用は279ドルです。

種類別に見ると、Looker Studioのダッシュボードの更新が47％、スケジュールクエリが32％を占めます。担当者が手で実行したクエリは8％にすぎません。

アカウント別では、tanakaさんのアカウントの処理量が最も多くなっています。ただし、その98％はLooker Studioのダッシュボードの更新で、本人が手で実行したクエリではありません。

ユーザー別に集計するだけでは「誰が使いすぎているか」という話になりがちです。クエリの種類で分けると、ダッシュボードやスケジュールクエリのような、仕組みの側の問題が見えます。

また、9月10日にClaudeを接続してからは、AIからのクエリ（緑）が増え、1日の処理量の平均は、9月1〜9日の1.19TiBから、9月24〜30日には1.34TiBに増えています。

次に、似たクエリをまとめて、処理量の多い順に並べます。

Claudeで作成した、処理量の多いクエリの一覧（デモ用のデータ）

上位6件のクエリで、全体の処理量の94％を占めています。

最も大きいのは、GA4のデータを使ったLooker Studioのレポートです。1回あたりの処理量は9.3GiBですが、1か月に1,855回更新され、16.9TiB（127ドル）になっています。

テーブルが日付で分割されていないため、表示期間を絞っても毎回全期間を読んでいます。

2番目は、毎時実行されているセッションの集計です。2025年に作られ、出力先のテーブルはどこからも使われていませんが、1か月に720回実行され、8.6TiB（65ドル）を処理しています。

この例では、上位のクエリに直し方を当てはめると、月間の処理量は38.2TiBから5.0TiB、推定費用は279ドルから30ドルになる試算です。費用が少数のクエリに集中しているため、全体を少しずつ削るより、上位から順に直す方が効果的です。

費用の出どころを調べる手順

ここからは、自社のBigQueryで同じ集計をする手順です。

手順1：必要な権限を確認する

INFORMATION_SCHEMA.JOBS で、プロジェクト内のすべてのユーザーのクエリを参照するには、プロジェクトに対する「BigQuery ユーザー」（roles/bigquery.user）と「BigQuery リソース閲覧者」（roles/bigquery.resourceViewer）の2つのロールが必要です。前者はクエリを実行するため、後者はすべてのユーザーのジョブを参照するためのものです（JOBS ビュー（別タブで開く））。

2026年10月時点で、このビューで参照できるのは、実行中のジョブと過去180日間のジョブです。

また、クエリには region-asia-northeast1 のように、データセットがあるリージョンを指定します。米国のマルチリージョンであれば region-us です。

手順2：クエリの種類別に処理量を集計する

次のSQLは、直近30日のクエリを、ダッシュボードの更新・AIからのクエリ・サービスアカウント・手動の4つに分けて、処理量と推定費用を集計します。

-- 直近30日のクエリの処理量と推定費用を、種類別に集計する
SELECT
  CASE
    WHEN EXISTS (SELECT 1 FROM UNNEST(labels) AS l
                 WHERE l.key = 'requestor' AND l.value = 'looker_studio')
      THEN 'ダッシュボードの更新'
    WHEN EXISTS (SELECT 1 FROM UNNEST(labels) AS l
                 WHERE l.key = 'goog-mcp-server')
      THEN 'AIからのクエリ'
    WHEN user_email LIKE '%gserviceaccount.com'
      THEN 'サービスアカウント（スケジュールクエリなど）'
    ELSE '手動のクエリ'
  END AS kind,
  COUNT(*) AS jobs,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_billed,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 7.5, 1) AS usd_estimate
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
GROUP BY kind
ORDER BY tib_billed DESC

種類は、次の情報で判定しています。

• ダッシュボードの更新：Looker Studioから実行されたクエリには、requestor が looker_studio のラベルが付く（Looker Studio で BigQuery データを分析する（別タブで開く））
• AIからのクエリ：BigQuery リモート MCP サーバーから実行されたクエリには、goog-mcp-server のラベルが付く（BigQuery MCP reference（別タブで開く））
• サービスアカウント：スケジュールクエリやデータ連携のツールを、サービスアカウントで動かしている場合

スケジュールクエリは、サービスアカウントを指定しなければ、作成したユーザーの権限で動きます。その場合、このSQLでは「手動のクエリ」に入るため、同じクエリが決まった時刻に繰り返し実行されていないかも確認します。

total_bytes_billed は、オンデマンド料金で課金されたバイト数です。

statement_type != 'SCRIPT' は、複数の文をまとめて実行したジョブ（スクリプト）の親を除き、同じ処理量を2回数えないための条件です（JOBS ビュー（別タブで開く））。

推定費用は、単価（ここでは東京リージョンの7.5ドル）をかけた値で、無料枠を引く前の金額です。

日別に見る場合は、DATE(creation_time, 'Asia/Tokyo') を GROUP BY に加えます。アカウント別に見る場合は、kind の代わりに user_email で集計します。

手順3：処理量の多いクエリを特定する

次に、似たクエリをまとめ、処理量の多い順に並べます。

-- 直近30日に処理量の多かったクエリ（似たクエリをまとめる）
SELECT
  query_info.query_hashes.normalized_literals AS query_hash,
  ANY_VALUE(user_email) AS user_email,
  ANY_VALUE(LEFT(query, 300)) AS sample_query,
  COUNT(*) AS runs,
  ROUND(AVG(total_bytes_billed) / POW(1024, 3), 1) AS gib_per_run,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_billed,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 7.5, 1) AS usd_estimate
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND statement_type != 'SCRIPT'
  AND query_info.query_hashes.normalized_literals IS NOT NULL
GROUP BY query_hash
ORDER BY tib_billed DESC
LIMIT 20

query_info.query_hashes.normalized_literals は、コメントや日付などの値を無視したクエリのハッシュ値です。条件の値だけが違う同じ形のクエリを、1つにまとめて数えられます。

なお、この値が入るのは、キャッシュから返らずに成功したクエリだけです（JOBS ビュー（別タブで開く））。

結果の runs（回数）と gib_per_run（1回あたりの処理量）を見ると、直し方が決まります。回数が多いならダッシュボードや定期実行の見直し、1回あたりが大きいならテーブルの分割や読む列の見直しです。

手順4：ストレージの内訳を確認する

保存の費用は、INFORMATION_SCHEMA.TABLE_STORAGE で、テーブルごとに確認できます（TABLE_STORAGE ビュー（別タブで開く））。

参照には「BigQuery メタデータ閲覧者」（roles/bigquery.metadataViewer）のロールが必要です。

-- テーブルごとの保存量（GiB）。論理と物理を比べる
SELECT
  table_schema AS dataset,
  table_name,
  ROUND(active_logical_bytes / POW(1024, 3), 1) AS active_logical_gib,
  ROUND(long_term_logical_bytes / POW(1024, 3), 1) AS long_term_logical_gib,
  ROUND(active_physical_bytes / POW(1024, 3), 1) AS active_physical_gib,
  ROUND(long_term_physical_bytes / POW(1024, 3), 1) AS long_term_physical_gib,
  ROUND(time_travel_physical_bytes / POW(1024, 3), 1) AS time_travel_gib,
  ROUND(fail_safe_physical_bytes / POW(1024, 3), 1) AS fail_safe_gib
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.TABLE_STORAGE
ORDER BY active_logical_bytes + long_term_logical_bytes DESC
LIMIT 20

論理と物理のそれぞれの保存量に単価をかけて比べると、どちらの料金モデルが安いかが分かります。物理の active_physical_bytes には、変更・削除したデータを一定期間残す「タイムトラベル」の分が含まれます。

物理の料金モデルでは、タイムトラベルの期間が過ぎた後に7日間保持される「フェイルセーフ」の分にも、アクティブ物理の単価で料金がかかります。

物理の費用は「（active_physical_bytes ＋ fail_safe_physical_bytes）× アクティブ物理の単価 ＋ long_term_physical_bytes × 長期物理の単価」で見積もります。フェイルセーフの分を除いて比べると、物理を安く見積もってしまいます（TABLE_STORAGE ビュー（別タブで開く））。

Claudeに集計を任せる

BigQueryをClaudeに接続していれば、ここまでの集計を日本語で依頼できます。接続の手順は「ClaudeとBigQueryを連携する方法｜MCPの接続手順と分析例（別タブで開く）」で解説しています。

プロンプト例
region-asia-northeast1 の INFORMATION_SCHEMA.JOBS から、直近30日のクエリを、Looker Studio（ラベル requestor=looker_studio）、MCP（ラベル goog-mcp-server）、サービスアカウント、手動の4つに分けて、件数・処理量（TiB）・推定費用を集計してください。単価は1TiBあたり7.5ドルです。statement_type が SCRIPT のジョブは除いてください。

プロンプト例
処理量の多いクエリを、query_info.query_hashes.normalized_literals でまとめて上位20件を出してください。それぞれ、実行したアカウント、回数、1回あたりの処理量、クエリの冒頭を示し、処理量を減らす方法を提案してください。

ジョブの履歴には、クエリの本文や実行したアカウントのメールアドレスが含まれます。接続に使うアカウントに、どこまでの権限を与えるかは社内で決めておきます。

BigQueryの料金を下げる方法

調べた結果に合わせて、次の方法で費用を下げます。効果が大きく、すぐにできるものから並べています。

使われていないスケジュールクエリを止める

処理量の多いクエリの中に、出力先のテーブルがどこからも参照されていない定期実行があれば、止めるだけで費用が下がります。止める前に、作成した担当者と、出力先を使っているダッシュボードや集計がないかを確認します。

あわせて、全期間を毎回集計し直している定期実行は、前日分だけを集計して追記する形に変えられないかを検討します。

当社が支援した株式会社YOUTRUST様でも、BigQueryを使う部門が増えるなかで、不要なクエリや放置された定期実行のジョブが費用を押し上げていました。利用状況と費用を細かく分析してそれらを特定し、コストの構造を見直したうえで、不要なスキャンを継続的に管理できる体制を整えています（「データ基盤のコスト削減・権限管理・ガバナンスを同時に実現（別タブで開く）」）。

必要な列だけを読む

SELECT * をやめ、使う列だけを指定します。BigQueryは選んだ列のデータ量で課金されるため、列を絞るだけで処理量が下がります。

前述のとおり、LIMIT を付けても読むデータ量は変わりません。例外はクラスタリングしたテーブルで、この場合は LIMIT で読む量が減ることがあります（費用を管理するためのベスト プラクティス（別タブで開く））。

中身を確かめるだけなら、Google Cloud コンソールのテーブルの「プレビュー」タブを使えば、無料でデータを表示できます（費用を管理するためのベスト プラクティス（別タブで開く））。

日付でパーティション分割する

広告やGA4の日別データのように、日付で絞って使うテーブルは、日付の列でパーティション分割します。パーティション分割したテーブルは、WHERE句で期間を絞ると、その期間のデータだけを読みます。

ダッシュボードの表示期間を「直近28日」などにしておくと、更新のたびに読むデータ量が抑えられます。

テーブルの作成時に「パーティション フィルタを要求」をオンにすると、期間を絞らないクエリを実行できなくなります（パーティション分割テーブルの作成（別タブで開く））。

パーティション分割は、保存の費用にも効きます。長期ストレージの割引はパーティションごとに適用されます。

そのため、更新されない古い日付のパーティションは、90日後に自動的に安くなります（BigQueryの料金（別タブで開く））。

一方で、毎日テーブル全体を上書きしていると、全体が「最近変更された」扱いになり、長期ストレージの割引が受けられません。

よく絞り込む列でクラスタリングする

キャンペーンIDや顧客IDのように、よく絞り込みに使う列で、テーブルをクラスタリングします。絞り込みに一致するブロックだけを読むため、処理量が減ります。

クラスタリングの列は4つまで指定できます（クラスタ化テーブルの概要（別タブで開く））。

なお、クラスタリングしたテーブルでは、実行前に表示される処理量の見積もりは上限の値で、実際の処理量はそれより少なくなることがあります。

集計テーブルやマテリアライズドビューを用意する

ダッシュボードやAIが、明細のテーブルを毎回集計していると、処理量が大きくなります。「日付 × キャンペーン」のように、よく使う単位で集計したテーブルを作り、ダッシュボードはそちらを読むようにします。

集計を自動で最新に保ちたい場合は、マテリアライズドビューも使えます。

元のテーブルの変更分だけを反映して更新され、元のテーブルへのクエリでも、使える場合はBigQueryが自動でマテリアライズドビューを読むように書き換えます（マテリアライズド ビューの概要（別タブで開く））。

マテリアライズドビュー自体の保存と更新にも費用がかかる点には注意します。

広告データのように、データ連携のツールでBigQueryに取り込むテーブルは、取り込み後に集計用のテーブルを作る構成が一般的です。

広告データの集め方は「Fivetranとは？広告データ統合でできること・料金・始め方（別タブで開く）」で解説しています。

ダッシュボードを、集計済みのデータだけを読む形で作る方法は「Claude Codeでダッシュボードを作成する方法｜自動更新と社内共有（別タブで開く）」で紹介しています。

1日あたりの処理量に上限を設定する

想定外のクエリで費用が膨らむのを防ぐには、カスタム割り当てで、1日に処理できるデータ量に上限を設定します（カスタムのクエリ割り当てを作成する（別タブで開く））。

Google Cloud コンソールの「IAM と管理」→「割り当てとシステム上限」で、BigQuery API の次の2つを設定します。

ユーザーごとの上限は、プロジェクト内のすべてのユーザーとサービスアカウントに同じ値が適用され、特定のユーザーだけに別の値を設定することはできません。また、この割り当てはオンデマンド料金にだけ適用されます。

上限に達すると、その日はクエリを実行できなくなります。ダッシュボードや定期実行が止まらないよう、手順2で調べた1日の処理量の実績に余裕を持たせた値にします。

1つのクエリごとに上限を設けるには、「課金される最大バイト数」を設定します。

クエリの処理量の見積もりが上限を超えると、実行前にエラーになり、料金はかかりません。

コンソールでは、クエリエディタの「展開」→「クエリ設定」→「詳細オプション」で設定します（費用を管理するためのベスト プラクティス（別タブで開く））。

ストレージの料金モデルを見直す

手順4で論理と物理の保存量を比べ、物理の方が安くなるデータセットは、ストレージの課金モデルを「物理」に変えます。

データセットの「詳細を編集」→「詳細オプション」→「ストレージの課金モデル」で変更できます（データセット プロパティの更新（別タブで開く））。

2026年10月時点で、変更が反映されるまでに24時間かかり、一度変えると14日間は再び変更できません。物理を選ぶ場合は、タイムトラベルの期間（2〜7日で設定）も保存量に影響します。

不要になった中間テーブルや、検証用に複製したテーブルが残っていれば、削除するか、テーブルの有効期限を設定しておきます。

ClaudeなどのAIからBigQueryを使うときの注意

ClaudeからBigQueryを使えるようにすると、担当者がSQLを書かなくても分析できるようになる一方で、クエリの回数が増えます。

AIは、テーブルの中身を確かめるために SELECT * を実行したり、期間を絞らずに集計したりすることがあります。デモ用のデータでも、ClaudeによるGA4のイベントの探索は、1回あたり39.1GiBを読んでいました。

費用を抑えるために、次の点を設定しておきます。

• 処理量を確かめてから実行させる：BigQueryの「ドライラン」は、クエリを実行せずに処理量を見積もる機能で、料金はかかりません（ドライランの実行（別タブで開く））。Claude Codeから bq コマンドを使う場合は、bq query --dry_run で処理量を確かめてから実行するよう指示します
• 上限を設定する：前述のカスタム割り当てで、1日の処理量に上限を設けます。2026年10月時点で、BigQuery リモート MCP サーバーのツールにドライラン専用のものはないため、MCPで接続する場合は割り当てで上限を設けておくのが確実です
• 読むテーブルと期間を決めておく：Claudeに渡す前提のファイルに「集計済みのテーブルを使う」「期間の指定がなければ直近28日に絞る」「SELECT * を使わない」と書いておきます
• AIのクエリを分けて見る：BigQuery リモート MCP サーバーから実行したクエリには goog-mcp-server のラベルが付くため、手順2のSQLでAIの処理量だけを追えます。ほかのMCPサーバーや、Claude Codeから bq コマンドで実行したクエリには付かないため、接続に使うアカウントで分けて見ます

接続に使う権限は「ClaudeとBigQueryを連携する方法（別タブで開く）」の「必要なものと権限」と「手順2」で、前提のファイルの書き方は同じ記事の「手順5」で解説しています。

まとめ

• BigQueryの費用は、クエリの処理量（オンデマンド料金）と保存量で決まる。2026年10月時点で、東京リージョンのオンデマンド料金は1TiBあたり7.50ドル、毎月1TiBまで無料
• 費用が増える原因の多くは、SELECT *、パーティションのないテーブル、ダッシュボードの更新、定期実行・放置されたスケジュールクエリ、AIからのクエリ
• INFORMATION_SCHEMA.JOBS をクエリの種類別・クエリ別に集計すると、費用が少数のクエリに集中していることが多い。上位から直すのが効果的
• 下げ方は、不要な定期実行の停止、列の絞り込み、パーティション分割とクラスタリング、集計テーブル、割り当ての上限、ストレージの課金モデルの見直し
• AIから使う場合は、ドライランと割り当てで処理量を管理し、読むテーブルと期間を前提として渡しておく

株式会社INVOXは、データ基盤の構築、データ分析の支援、AIエージェントの開発を行っています。BigQueryの利用状況を可視化し、費用の出どころの特定から、テーブルの設計、権限の整理までを支援しています。

支援の内容は「マーケティング分析（別タブで開く）」で、BigQueryのコストと権限を見直した事例は「データ基盤のコスト削減・権限管理・ガバナンスを同時に実現（別タブで開く）」で紹介しています。

「BigQueryの請求額が増えているが、原因が分からない」「AIから使い始める前に、費用の上限を決めておきたい」といった課題をお持ちでしたら、お問い合わせください。