BigQueryでデータ統合基盤を構築する費用｜毎月の料金は何で決まり、どこで下げられるか

BigQuery でデータ統合基盤を作る費用は、最初に作る費用と、作った後に毎月払い続ける費用に分かれます。最初の費用は外注先ごとの見積もり（人の工数）で決まるので、この記事では相場の金額は扱いません。代わりに、毎月の料金のうち何が使った分で増え、何が定額かを書きます。毎月の費用は、データを運ぶツール、BigQuery、見せるツール、保守の人手の4つです。このうち BigQuery の処理の料金は、同じデータでもクエリの書き方と表の作り方で桁が変わります。

当社は BigQuery を中心にしたデータ基盤の設計・構築と、データポータル（英語名 Data Studio、旧 Looker Studio）などでの可視化を支援している会社です。料金の仕組みは公式のページに書かれていますが、自分の表でどれだけ効くかは、実際にクエリを実行してみないと分かりません。そこで、設計で差が出る処理の料金は、当社の検証用の Google Cloud プロジェクトでクエリを実行して確かめました。単価は、読んだ量で払うオンデマンド料金の東京リージョン（asia-northeast1）の値です。容量課金（Editions）の試算と、構築の見積もりの金額は扱いません。

データを BigQuery のようなデータベースに置くか、Excel のままでよいかの分かれ目は、当社の動画で話しています。

毎月の費用は4つに分かれ、料金が増えるものが違う

出典：TROCCO 料金プラン、Fivetran Pricing、Airbyte Pricing、dbt Pricing、Google Cloud「データポータル」。これらの料金は、構築を外注しても払い続けます。運ぶツールは料金の数え方が違うので、比べるときはデータ源ごとの行数と更新の頻度を先にそろえます。つなぎたいデータ源に、使うツールのコネクタがあるかも先に見ます。無ければカスタム開発になり、その分は構築の工数に入ります。外注と内製の分け方はETLパイプライン構築の費用で書いています。

BigQuery の料金は「保存」と「処理」

BigQuery には使う前に用意するサーバーがなく、料金はデータを置く保存の料金と、クエリでデータを読む処理の料金が中心です。東京リージョンの単価は次のとおりです。

出典：Google Cloud「BigQuery の料金」。料金と無料枠は、プロジェクトにつないだ請求先アカウントにかかります。米ドル以外の通貨で払う場合は、Cloud Platform SKU に載っているその通貨の料金が使われます。リアルタイムの更新が要らないなら、共有のスロットを使う一括の読み込みにしておけば、取り込みは無料です。ストリーミングにすると、取り込みにも料金がかかります（gRPC の Storage Write API は毎月 2 TiB まで無料）。

保存の料金は表の量で読めます。読みにくいのは処理の料金で、同じ集計でも書き方で読む量が変わります。ここからは1つの表で確かめます。

600万行の架空の受注明細で試した

当社の検証用の Google Cloud プロジェクトのデータセット blog_demo に、SQL で架空の受注明細を作りました（2026年10月13〜14日、東京リージョン、オンデマンド）。お客様のデータではありません。

表を作るクエリは既存の表を読まないので、処理も課金も 0 バイトでした。処理量は主に「ドライラン」で見ました。クエリを実行せずに読む量だけを見積もる機能で、料金はかかりません（Google Cloud「クエリを実行する」）。一部は実行して、課金された量も確かめました。

読む列を減らすと処理量が減る。LIMIT では減らない

SELECT * FROM blog_demo.sales_flat LIMIT 10;   -- 全部の列を10行だけ
SELECT order_date, amount FROM blog_demo.sales_flat;   -- 2列だけ

10行しか返さない SELECT * … LIMIT 10 が、表全体の 873,331,772 バイトを読む見積もりでした。2列に絞ると 96,000,000 バイトで約9分の1、そこに LIMIT 10 を付けても同じです。BigQuery は列ごとにデータを持ち、オンデマンドは選んだ列の量で課金されます。LIMIT を付けても、課金される量は変わりません（料金ページ）。クラスタ化した表に限り、必要なブロックを読んだところで止まるので LIMIT で減ることがあります（Google Cloud「費用を管理するためのベストプラクティス」）。

中身を眺めるだけなら、コンソールの表の［プレビュー］タブか bq head が無料です（同じページ）。

期間で絞るならパーティション。ただし日付を関数で包むと全期間を読む

SELECT store_id, SUM(amount) AS sales FROM blog_demo.sales_part
WHERE order_date BETWEEN '2026-09-01' AND '2026-09-30'   -- 日付の範囲で絞る
GROUP BY store_id;
-- WHERE FORMAT_DATE('%Y-%m', order_date) = '2026-09'   -- 関数で包んで絞る

パーティションの表では9月の30日分だけを読み、3,934,062 バイトで、分けていない表の約34分の1でした。ところが同じ表でも、日付を FORMAT_DATE で年月の文字列に変えてから絞ると、全期間の 132,000,000 バイトに戻りました。Google は、パーティションを読み飛ばす（プルーニング）には絞り込みに定数の式を使い、パーティションの列を計算に入れずに書くよう勧めています（Google Cloud「パーティション分割テーブルに対してクエリを実行する」）。月で絞るときも、日付の範囲で書きます。

ただし Google は、パーティション1つが約10 GB 未満と小さくなるなら、パーティションよりクラスタ化を検討するよう書いています。小さなパーティションが多いと表のメタデータが増えるためです（Google Cloud「パーティション分割テーブルの概要」）。今回の表は1日あたり1 MB に満たず、この目安よりずっと小さい表です。月単位のパーティションや、クラスタだけの表は試していません。

クラスタは見積もりに出ず、この表ではほとんど効かなかった

1か月に加えて1店舗（S007）に絞った日別の集計を、キャッシュを使わずに実行しました。

クラスタ化した表は実行したときだけ処理量が減り、それも約1%でした。Google の説明では、クラスタ化した表の費用は実行の後にしか分かりません。また、クラスタ化でメリットが得られる可能性があるのは 64 MB を超える表やパーティションで、それより小さいと性能の向上は通常ごくわずかです（Google Cloud「クラスタ化テーブルの概要」）。ドライランの見積もりは上限の値です（費用を管理するためのベストプラクティス）。1日分が1 MB に満たない今回の表では、処理量もほとんど減りませんでした。効きは実行後の処理量で比べます。

小さなクエリは、最低 10 MB で課金される

上の実行で読んだのは約3.9 MB でしたが、課金はどちらも 10 MiB でした。オンデマンドは MB 単位で切り上げ、参照する表ごとに最低 10 MB、クエリごとにも最低 10 MB かかります（料金ページ）。公式の表記は 10 MB ですが、今回実際に課金されたのは 10,485,760 バイト（10 MiB）でした。計算の例として、1つの表を読む小さなクエリを1,000回実行すれば、読んだ量に関係なく、少なくとも約9.8 GiB（10 MiB×1,000回）分が課金されます。同じ集計を何度も実行するなら、次のキャッシュか、集計済みの小さな表で回数を減らせます。

読みすぎるクエリは、実行前に止める

誰かが分けていない大きな表に SELECT * を書けば、表全体を読みます。そうしたクエリを実行前に失敗させる設定を2つ試しました。

課金される最大バイト数

上限を 10 MiB にして SELECT * FROM sales_flat LIMIT 10 を実行すると、実行前に次のエラーで止まり、課金は 0 でした。

Query exceeded limit for bytes billed: 10485760. 873463808 or higher required.

コンソールではクエリエディタの［展開］→［クエリ設定］→［詳細オプション］の［課金される最大バイト数］、bq コマンドでは --maximum_bytes_billed、API では maximumBytesBilled で設定します。クラスタ化した表は見積もりが上限の値なので、実際の課金が上限に収まる場合でも失敗することがあります（費用を管理するためのベストプラクティス）。

パーティションの絞り込みを必須にする

パーティションの表 sales_part に、パーティションの列で絞らないクエリを受け付けない設定（require_partition_filter）を入れました。当社は API（tables.patch）で設定しました。SQL で入れるなら次のとおりです。

ALTER TABLE blog_demo.sales_part
SET OPTIONS (require_partition_filter = TRUE);

設定を入れた表に、WHERE を付けずに集計をかけると、ドライランの段階で次のエラーになりました（プロジェクト名は伏せています）。order_date の範囲を付けると通り、見積もりは 3,934,062 バイトでした。

Cannot query over table ‘<project>.blog_demo.sales_part’ without a filter over column(s) ‘order_date’ that can be used for partition elimination

作った後の表には、コンソールの表の編集画面からはこの設定を入れられません。クエリエディタで ALTER TABLE を実行するか、bq update --require_partition_filter か API（tables.patch）を使います（Google Cloud「パーティション分割テーブルを管理する」）。試していませんが、1日に読める量の上限（カスタムの割り当て）も、プロジェクト全体と、利用者1人あたり（全員に同じ値）で決められます。プロジェクトの既定は1日 200 TiB です。割り当ては厳密な上限ではなく、超えて処理されることがあります（Google Cloud「カスタム費用管理を作成する」）。

同じクエリの2回目は、キャッシュで課金されなかった

1店舗×1か月の集計を、キャッシュを使う設定で2回続けて実行すると、1回目は 10 MiB の課金、2回目はキャッシュに当たって処理も課金も 0 でした。BigQuery は結果を通常24時間ほど一時的な表に残し、まったく同じクエリにはそこから結果を返します。その分は課金しません。ただし、クエリの文字が空白1つでも違う、参照する表が変更された、CURRENT_DATE のように実行のたびに値が変わる関数を使っている、行レベルのセキュリティがかかった表を読む、といった場合は使われません（Google Cloud「キャッシュに保存されたクエリ結果を使用する」）。

表が変わるたびにキャッシュは使えなくなるので、取り込みの頻度は BigQuery の処理の料金にも響きます。キャッシュを使わない実行は、コンソールの［キャッシュの設定］で［キャッシュに保存された結果を使用］をオフにします。

このデモ全体で課金されたのは 30 MiB だった

試したクエリにラベルを付け、INFORMATION_SCHEMA.JOBS_BY_USER（自分のジョブの記録）で集計しました。処理した量は 11,703,230 バイト、課金は 30 MiB で、どちらも1店舗×1か月の集計を実行した3回分（キャッシュなしの2回と、キャッシュを使う設定の1回目）の合計と一致します。上限で止まったクエリと、キャッシュに当たったクエリは課金 0 でした。ドライランは実行されないので、この集計には入っていません。東京の単価で換算すると約0.0002米ドルです。これは無料枠を差し引く前の値です。請求は請求先アカウント全体で決まるため、このデモだけの請求額は確かめていません。

同じ見方は自社の基盤でも使えます。INFORMATION_SCHEMA.JOBS には過去180日分のジョブが残り、total_bytes_billed（課金された量）と total_slot_ms（使ったスロットの時間）を見られます（Google Cloud「JOBS ビュー」）。課金量の多いクエリを並べれば、直すと効く所が分かります。オンデマンドのままか容量課金に移るかも、目安として、月の total_bytes_billed×TiB の単価と、total_slot_ms から出したスロット時間×容量課金の単価を比べます。分かれ目はクエリの量と実行のされ方で変わるので、金額は書きません（容量課金は試していません）。

処理の料金は、ツールの月額と比べてどれくらいか

このデモの処理の料金は約0.0002米ドルでした。毎月の費用の中でどれくらいの大きさかを見るために、本文に出したツールの月額を、東京のオンデマンドの単価（1 TiB あたり 7.50 米ドル）で処理の量に直しました（当社の計算）。

今回くらいの大きさの表なら、処理の料金は毎月の無料枠の 1 TiB に収まりやすく、毎月の費用で大きいのは、有料のプランを選んだ運ぶ・整える・見せるツールの月額のほうです。処理の料金が効いてくるのは、読む量が月に TiB の単位になるとき、つまり表が大きいか、大きな表を丸ごと読むクエリを何度も実行するときです。表の分け方は、パーティションとクラスタで分けて考えます。パーティションは、1日1 MB に満たない小さな表でも読む量を約34分の1に減らせました。ただし公式は、パーティション1つが約10 GB 未満になるなら、メタデータが増えるのでクラスタ化も検討するよう書いています。クラスタは、公式の目安の 64 MB より小さい今回の表では約1%しか減りませんでした。どちらにしても、読む量が月に TiB に届かないうちは、金額の差は小さいままです（今回の表を丸ごと読んでも1回約0.006米ドル）。その間に入れておく意味が大きいのは、「読みすぎるクエリは、実行前に止める」の節の上限や必須化のように、大きな表を誤って丸ごと読むクエリを止める設定です。

保存の料金を抑える仕組み（今回は試していない）

出典：Google Cloud「BigQuery の料金」、「クラスタ化テーブルの概要」、「データセットのプロパティを更新する」、「パーティション分割テーブルを管理する」、「費用を管理するためのベストプラクティス」。アクティブの単価だけで比べると、物理の課金が得になるのは、圧縮後の量が論理の量の約44%（0.023÷0.052）を下回るときです（当社の計算。タイムトラベルなどの分は含まない）。

発注の前に、見積もりの前提として確かめること

構築の工数の見積もりは外注先ごとに違うので、金額は扱いません。ここでは、毎月の料金が何で動くか（使った分で増えるのか、定額か）という点から、見積もりの前提として確かめておきたい項目を並べます。

変換の層の費用はdbt × BigQuery の変換基盤の構築費用、見せる層はデータポータル（旧 Looker Studio）の設定・外注費用、遅いクエリの直し方はBigQuery のクエリの最適化に書いています。

まず、今あるクエリの処理量を見る

すでに BigQuery を使っているなら、よく実行されているクエリをドライランにかけて読む量を見て、INFORMATION_SCHEMA.JOBS で課金量の多いクエリを並べてください。SELECT *、日付を関数で包んだ絞り込み、パーティションの無い大きな表への期間の絞り込みが見つかれば、そこが直す候補です。これから作るなら、見積もりの前提に上の表の項目が入っているかを確かめてください。表の分け方や上限の設定を含めた基盤の設計は、当社のデータ分析・BI支援でご相談いただけます。

単価と仕様は、2026年10月14日に Google Cloud の料金ページ・ドキュメントと各社の料金ページで確かめたものです。デモの数字は当社の検証用プロジェクトの、この表・この条件での値で、ほかの表で同じ比率になるとは限りません。