BigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断

BigQueryは、Google Cloudが提供するデータウェアハウスです。サーバーの台数もディスクの増設も指定せず、SQLを投げるだけでテラバイト級のスキャンが返ってきます。その速さと引き換えに、課金の起点は「読んだバイト数」になり、単一行の更新やミリ秒応答は不得手なまま。この記事では、ストレージ層とコンピュート層を分けた構造、料金の数え方、公式ドキュメントで確認できる固定上限、採用条件と見送るべき場面を実装者の視点で整理します。金額と上限値は2026年8月13日時点の公式料金ページと割り当てページの値です。

まとめ：BigQueryを採用してよい条件と見送るべき条件

先に結論を示します。BigQueryが向くのは、追記が中心の大量データに対して、不定形の集計を何度も投げる用途です。数百GiBから数十TiBのログやトランザクション履歴を貯め、日次の集計と探索的な分析を回すなら、他の選択肢より運用の手数が少なく済みます。逆に向かないのは、画面から1件ずつ参照して1件ずつ更新する業務システムの主データベースとして使う構成。ここは条件を分けません、採用しないでください。

料金の考え方は2系統です。既定のオンデマンドはスキャンしたデータ1TiBあたり6.25ドルで、毎月1TiBは無料枠に収まります。もう一方のEditionsはスロット時間で課金し、Standardが1時間あたり0.04ドル、Enterpriseが0.06ドル、Enterprise Plusが0.10ドルです。

制約も先に。クエリの実行時間は6時間で打ち切られ、パーティション分割テーブルは10,000パーティションまで、1つのジョブで触れるパーティションは4,000までです。

BigQueryのサーバーレス構造とスキャン課金が結びつく仕組み

「サーバーレスのデータウェアハウス」という説明だけでは、設計判断の材料になりません。公式ドキュメントが示す2層構造が課金にどう跳ね返るかまで踏み込みます。

ストレージ層とコンピュート層を分離したことで消える運用作業の範囲

公式ドキュメントは、BigQueryを「データを取り込み、保存するストレージレイヤ」と「分析機能を提供するコンピューティングレイヤ」の2層で構成し、両者はペタビット規模のネットワークにより相互に独立して動作すると説明しています。この「独立して動作する」が運用作業の量を決めました。

従来のDWH製品は、ノードを増やすとストレージも一緒に増える構成が一般的でした。ディスクが逼迫すればノードを足し、CPUが足りなくてもノードを足す。BigQueryでは両者が分かれているため、10TiBのデータを置いたまま計算資源をゼロにしても、ストレージ料金だけが発生する状態を保てます。インスタンスサイズの選定やインデックス再構築といった保守作業もありません。

列指向ストレージとスキャン量課金が直結することの設計上の意味

BigQueryは、公式ドキュメントの表現では「分析クエリに向けたカラム型ストレージ形式」でデータを保持します。行ではなく列単位で格納されるため、100列あるテーブルから3列だけ読むクエリは、単純計算で3列ぶんのバイト数しか読みません。

オンデマンド料金は、処理された（読まれた）バイト数に対して1TiBあたり6.25ドルで課金されます。つまり SELECT * は、そのまま請求額の増加を意味しました。50列のうち必要なのが3列なら、列を明示するだけで支払いは十数分の一になる計算です。行数を絞る条件句は、パーティション列やクラスタリング列に効いていなければスキャン量を減らしません。テーブル作成時に日付列でのパーティション分割を入れ、よく絞り込む列でクラスタリングを設定しておく。この2つの有無で請求額が桁で変わります。

サーバーレスでも消えない設計判断とロケーション選択の不可逆性

サーバー管理が不要でも、人が決める項目は残ります。最初に決めるのはデータセットのロケーションです。BigQueryはデータセット単位でリージョンまたはマルチリージョンを指定し、作成後にロケーションを変更できません。異なるロケーションのテーブル同士は同一クエリで結合できないため、後から東京リージョンと米国マルチリージョンに分かれるとコピージョブを挟む運用が固定化します。

次に決めるのがタイムトラベル期間。既定は過去7日間で、2〜7日の範囲でデータセットまたはプロジェクト単位に設定できます。短くすれば保持コストが下がり、長くすれば誤削除からの復旧余地が残ります。

従来のRDBMSと自前分散基盤に対するBigQueryの設計上の違い

近道は、手元のMySQLやPostgreSQLとの差分を言語化することです。SQLが書ける点は同じでも、前提となる処理モデルが違います。

インデックス前提のRDBMSとスキャン前提のBigQueryの差

RDBMSは、B-treeインデックスで目的の行に到達する設計です。1件の主キー検索は数ミリ秒で返り、行数が増えても対数的にしか劣化しません。BigQueryにはこの意味での汎用インデックスがなく、パーティションとクラスタリングで読む範囲を狭めたうえで、残りを並列にスキャンします。1件取得はRDBMSが圧勝、10億行の集計はBigQueryが圧勝という逆向きの特性です。

オンデマンド料金ではプロジェクトあたり最大2,000スロットが同時に動くため、数十億行の走査でも数十秒に収まります。DWHという分類そのものから検討している場合は、データウェアハウス（DWH）の仕組みと製品の選び方が入口です。

行の更新・削除の扱いとタイムトラベル7日を前提にした復旧モデル

BigQueryでも UPDATE と DELETE は書けます。ただし内部の動きが違いました。公式ドキュメントの説明では、データを更新するときに既存のストレージブロックをその場で書き換えるのではなく、更新後のデータを含む新しいバージョンのブロックを作り、以前のバージョンをタイムトラベル用に保持します。

帰結は2つ。ひとつは、1セルの変更でもブロック単位のデータが複製されるため、小さな更新を大量に流すと保持データ量が膨らむこと。もうひとつは、既定7日のタイムトラベル期間内なら、誤って消したテーブルを任意時点の状態で読み戻せることです。7日を超える保全が要るなら、テーブルスナップショットを別途スケジュールしてください。

自前のHadoop基盤やRDBMSとの比較で見える運用負荷の差

3つを同じ観点で並べます。

差が最も出るのは、拡張の操作の行です。自前でHadoopやSparkのクラスタを持つと、ノード追加のたびにデータの再配置とジョブの再調整が発生します。BigQueryではこの作業自体が存在しません。

取り込みから機械学習・BI接続までBigQueryでできることの範囲

機能名の羅列は判断材料になりません。取り込み・分析・出力の3工程に分けて見ていきます。

バッチ読み込みとStorage Write APIによる取り込み経路の選択

取り込みは大きく2経路です。Cloud Storage上のCSV・JSON・Avro・Parquet・ORCを読む「読み込みジョブ」は料金がかからない代わりに、1テーブルあたり1日1,500ジョブという上限があります。5分間隔でファイルを流すと1日288回なので余裕がありますが、1分間隔にすると1,440回で上限に接近しました。

もう一方が BigQuery Storage Write API による逐次書き込みで、1GiBあたり0.025ドル、毎月2TiBまでは無料枠です。旧来のストリーミング挿入は200MiBあたり0.01ドルで、GiB換算では約5倍になります。

SQLだけで完結するBigQuery MLとベクトル検索の使いどころ

公式ドキュメントには、BigQuery ML、BigQuery Studio、ベクトル検索、BigLake外部テーブル、Apache Iceberg対応、継続的クエリ、Gemini in BigQueryが機能として記載されています。価値は、これらがSQLで呼び出せる点にありました。

BigQuery MLでは、CREATE MODEL 文で回帰やクラスタリングのモデルを作り、予測もSQLで実行します。データを外部へ持ち出してPythonの環境を組む工程が消えるため、需要予測や解約予測を試すまでの時間が短くなりました。ベクトル検索も同じ発想で、検索対象のテキストが既にBigQuery上にあるなら専用のベクトルデータベースを別途立てずに済む場合があります。

Looker StudioとGA4連携で分析結果を配る際の接続経路

集計結果は、SQLを書ける人以外にも届いて初めて業務に効きます。主要なBIツールから接続でき、無料のLooker Studioとの組み合わせが最も手数の少ない構成です。機能範囲と料金、企業導入時の判断はLooker Studioの機能・料金とBigQuery連携の判断にまとめました。

データの流し込み側では、GA4のBigQueryエクスポートがよく使われる経路です。管理画面から連携を有効にすると、イベント単位の生データが日次または逐次で書き出され、標準レポートでは触れない粒度の分析ができるようになります。設定の具体的な手順と日次上限、そこから先のダッシュボード接続はGA4のデータをBigQueryへ書き出してダッシュボードにつなぐ手順で扱っています。

オンデマンドとEditionsの料金構造と切り替えの損益分岐点

費用はコンピュート（クエリ）とストレージの2本立てです。金額が読めないという不安の大半は、前者の課金モデルを選び切れていないことに起因します。

オンデマンド1TiBあたり6.25ドルの数え方と無料枠の範囲

既定のオンデマンド料金は、クエリで処理されたバイト数に対して1TiBあたり6.25ドルです。毎月1TiBまでは無料枠に収まります。100GiBのテーブルに対して全列を読む集計を1日10回投げると月におよそ30TiB、金額にして180ドル前後という見積もりになりました。

見落としやすいのは、結果行数ではなく読んだ列のバイト数で決まる点。LIMIT 10 を付けてもスキャン量は減りません。ストレージ側の無料枠は毎月10GiBです。

Editionsのスロット時間単価と3つのエディションの選び分け

請求額が振れるようになったら、容量ベースのEditionsが選択肢に入ります。

単位はいずれも1スロット時間あたり。Standardは基本的な分析用途、Enterpriseは組織横断のガバナンスを要する場合、Enterprise Plusはさらに厳しい規制要件がある場合という位置づけです。自動スケーリング付きの従量課金から始め、消費が安定してからコミットメントを買ってください。

スロット時間換算で見たオンデマンドと容量モデルの損益分岐点の目安

切り替えの判断は実測で行えます。BigQueryはジョブごとの消費スロット時間をメタデータビューで参照できるためです。

試算は単純です。オンデマンドの月額は「月間スキャンTiB × 6.25ドル」、Enterpriseに寄せた場合は「必要な同時スロット数 × 稼働時間 × 0.06ドル」。100スロットを1日8時間だけ動かす構成は月におよそ1,460ドルで、これは月間234TiBのスキャンに相当します。この水準を継続的に超えているなら移行の検討に入る段階でしょう。

論理ストレージと物理ストレージのどちらで課金するかを選ぶ基準

ストレージの課金モデルも2種類から選べます。us-central1の例では、アクティブな論理ストレージが1GiB時あたり0.000031507ドル、1TiBを1か月保存した場合の支払いは23.552ドル。物理ストレージは単価が論理の約1.7倍ですが、論理が非圧縮のバイト数で数えるのに対し、物理は圧縮後のバイト数で数えます。値の重複が多いテーブルほど圧縮が効くため、圧縮率が2倍を超えるなら物理のほうが安く済む計算です。ただし論理ではタイムトラベルとフェイルセーフのぶんが課金されない一方、物理では課金対象になります。

クォータと固定上限から見たBigQueryに向かない処理の見分け方

採用可否を分けるのは、できることの多さではなく越えられない線の位置です。

単一行の参照や更新が中心の処理でBigQueryを避ける理由

BigQueryは主キー検索に数ミリ秒で応答する製品ではありません。クエリごとにジョブが起動し、分散実行の準備が入るため、ごく小さなクエリでも応答は秒のオーダー。Webアプリケーションの画面表示のたびに問い合わせる構成は成立しません。

更新側の制約はさらに明確です。列パーティション分割テーブルのパーティション変更は1日30,000回までで、UPDATE や DELETE といったDMLもこの回数にカウントされます。行単位の更新が主体なら、Cloud SQLやSpannerのようなトランザクション向けのデータベースを前段に置き、BigQueryへは変更履歴を流す構成にしてください。

クエリ実行6時間・SQL1,024,000文字・1万列の固定上限

引き上げできない固定上限のうち、設計に効くものは次の4つです。

• クエリの実行時間は6時間で打ち切り（試行は3回まで）
• SQLクエリの最大長は1,024,000文字（コメントと空白を含む）
• テーブルとクエリ結果の最大列数は10,000（ネスト列と繰り返し列を含む）
• オンデマンド料金の同時実行スロットはプロジェクトあたり最大2,000

6時間の壁に当たるのは、数年分のデータをひとつのクエリで一括変換しようとする移行時です。列数の上限は、イベントの属性を列として横に増やし続ける設計で効いてきました。属性が可変ならJSON型やネスト構造で持つほうが安全でしょう。

パーティション1万件と1ジョブ4,000件が効いてくる設計場面

パーティション分割テーブルは最大10,000パーティションまでです。日付単位で分割すると約27年ぶんなので通常は問題になりませんが、時間単位で分割すると約416日で上限に達しました。この場合は古いパーティションの失効設定を同時に入れてください。

もうひとつが、1つのジョブで変更できるパーティション数は最大4,000という制限で、これを超えるジョブは拒否されます。全期間を一括で埋め直すバックフィルは、日付範囲を年単位に区切れば日次パーティションで1回365件に収まる計算。なお1日あたりのクエリ使用量にはプロジェクトあたり200TiBという既定の上限もあり、カスタムクォータで変更できます。

採用してよい条件と見送るべき場面を分ける4つの判断軸と費用の歯止め

玉虫色の結論にはしません。条件を示して言い切ります。

採用してよい条件は、データ規模と参照パターンの2点で判断する

採用してよいのは、次の2つを同時に満たす場合です。第一に、対象データが追記中心で、100GiBを超えて増え続けていること。第二に、分析の問いが事前に確定しておらず、切り口を変えた集計を繰り返す使い方であること。事前にインデックスを設計できない状況ほど、スキャン型の強みが出ます。

逆に、データが数GiB程度で、集計軸も月次レポートの数種類に固定されているなら、既存のRDBMSにリードレプリカを1台足すほうが安く早く済むでしょう。3つ目の補助線は分析する人数です。1〜2名が業務システムのデータベースへ直接クエリを投げて支障がないなら、まだDWHを分ける段階ではありません。部門をまたいで10名以上が同じデータを見る時点が実務的な区切りになります。

見送るべき場面は業務システムの主データベース化と小規模な集計

見送るべき場面は2つあります。ひとつは業務システムの主データベースとして使う構成。画面の1操作ごとに参照と更新が走る処理は、応答時間の面でもDMLの回数上限の面でも成立しません。ここは条件付きの話ではなく、採用しないと判断してください。

もうひとつが、月数十GiB程度のデータに対する定型集計だけの用途です。無料枠の範囲で動くため費用の失敗はしませんが、ロケーションの決定、権限設計、パーティション設計、取り込みパイプラインの構築といった初期の手数が、得られる速度改善に見合いません。

費用が読めないという不安に効くカスタムクォータと課金バイト上限

スキャン課金への抵抗感は、上限を機械的に設定すれば大部分が解消します。使える歯止めは3層です。

1. プロジェクト単位のカスタムクォータで1日あたりのクエリ使用量に上限を設ける（既定は200TiB）
2. ユーザー単位のカスタムクォータで、1人が1日に処理できるTiB数に上限を設ける
3. クエリ単位で maximum_bytes_billed を設定し、上限を超えるクエリを実行前に失敗させる

実務では3層目が最も効きます。上限を超えたクエリは課金されずに失敗するため、書き間違いによる高額請求そのものが発生しません。組織の共通設定として既定値を入れておいてください。

導入判断の材料になる他社の事例と外部に委託する場合の見極め方

自社に当てはめる段階では、同じ規模・同じ業務でどう使われたかを見てください。成果が出た構成と出なかった構成の分かれ目は、BigQuery導入事例の4類型と成果が出た条件で類型ごとに整理しました。自社がどの類型に近いかを先に決めると、必要な初期投資の見積もりが具体化します。

外部に委託するかどうかは、社内に「SQLを書ける人」ではなく「データの流れを設計できる人」がいるかで決まります。難所は、どのテーブルを、どの粒度で、どの頻度で運び、誰にどこまで見せるかを決める部分です。進め方の全体像はBigQuery導入の手順と体制をまとめた記事で扱っています。一創では、取り込みパイプラインの設計からテーブル設計、権限とコストの歯止めまでを含めたデータ分析基盤構築・MLOps構築支援を提供しています。

よくある質問

検討時によく挙がる質問に、公式ドキュメントの数値をもとに答えます。

BigQueryは無料で使えますか？

無料枠の範囲であれば費用は発生しません。クエリは毎月1TiBまで、ストレージは毎月10GiBまでが無料枠です。数GiB程度の検証用データセットに日常的な集計を投げる程度なら、この範囲に収まるでしょう。無料枠を超えた分は、オンデマンドなら1TiBあたり6.25ドルの従量課金になります。なお、Google Cloud全体の無料トライアルとは別枠のため、トライアル終了後も無料枠は継続します。

BigQueryとCloud SQLはどう使い分けますか？

処理の性質で分けます。Cloud SQLはMySQLやPostgreSQLのマネージドサービスで、1件単位の参照と更新に向く製品。BigQueryは大量データの集計に向き、1件単位の更新には回数の上限があります。一般的な構成は、業務システムのデータベースをCloud SQLに置き、その変更履歴や日次スナップショットをBigQueryへ流して分析するというものです。

クエリ料金が想定外に膨らむのを防ぐ方法はありますか？

クエリ単位の課金バイト上限とカスタムクォータで機械的に止めるのが基本ですが、運用側でもう1つ効くのがドライランです。実行前に処理予定のバイト数を確認する習慣を付ければ、条件の書き間違いによる大量スキャンにその場で気づけます。テーブル側でも、日付列でのパーティション分割とクラスタリングを入れておけば、絞り込みがそのままスキャン量の削減として効くようになります。

BigQueryはリアルタイムの分析に使えますか？

秒単位の鮮度なら実現できます。BigQuery Storage Write APIで書き込んだデータは、バッチの読み込みジョブを待たずにクエリ対象になるためです。ただし、応答時間そのものはミリ秒になりません。ダッシュボードの更新間隔が数十秒以上なら十分に成立しますが、画面表示のたびに問い合わせる用途には向かないでしょう。

オンデマンドとEditionsはどちらを選ぶべきですか？

導入初期はオンデマンドで問題ありません。月間のスキャン量が安定して増え、請求額の振れ幅が許容できなくなった時点でEditionsへの切り替えを検討してください。判断は感覚ではなく、直近1か月のスキャン量と消費スロット時間をメタデータビューで実測して比べる形になります。

関連記事

• BigQueryの事例4類型｜成果が出た条件と自社導入の判断軸：自社に近い使われ方から効果を見積もる。
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：基盤全体の設計手順。
• データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説：DWHという分類そのものの選び方。
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：貯める層と分析する層の役割分担。
• Looker Studioとは｜無料BIツールの機能・料金・BigQuery連携と企業導入の判断【2026年最新】：集計結果を関係者へ配る側の選択肢。