データ処理・分析種別：マネージドサービス成熟度安定学習コスト中

BigQuery

サーバーレスで TB 級のデータを SQL で集計する、Google Cloud のデータウェアハウス

分野「データ処理・分析」：溜まったデータを集計・変換・可視化する。分野の役割とつながりは分野の解説へ。

別名：BQ、Google BigQuery、Google Cloud BigQuery

できること

大量データを集計・分析する：GB〜TB級のログを集計したい
データを可視化・ダッシュボード化する：グラフで見たい・共有したい
関係を持つデータを保存し問い合わせる：表と表を結合して集計したい
定期的に処理を実行する：毎日／毎時この処理を自動で回したい

BigQuery ができないこと

行単位の高頻度な更新・削除を受けるアプリのバックエンド（OLTP）。DML の同時実行はテーブル単位で制限され、1行の更新でもスキャン量で課金される
ミリ秒単位の応答が必要な画面の直接のデータ源（クエリは秒単位。結果はキャッシュや別 DB に置く）
スキャン量の読めないアドホッククエリを無制限に許すこと（SELECT * が請求に直結する。カスタムクォータで上限を切る）
オンプレミスやローカル環境での実行（マネージド専用。手元で同じ SQL を動かすなら DuckDB 等）

制約

先頭の行が、このツールで最も先に当たる制約。値はすべて出典の一次情報で確認したもの。

項目	値	影響	出典	検証日
オンデマンド課金の単価と最低課金（主要制約）	処理（スキャン）量 1 TiB あたり $6.25（料金ページの既定表示リージョン。リージョンで異なる）。毎月最初の 1 TiB は無料。1クエリあたり、および参照テーブルごとに最低 10 MB を課金。エラーになったクエリとキャッシュヒットは無課金	費用は「行数」ではなく「読んだ列のバイト数」で決まる。パーティション・クラスタリングと列の絞り込みなしに大テーブルへ繰り返し問い合わせると、無料枠 1 TiB は数回で消える。1日のスキャン量はプロジェクト単位のカスタムクォータで上限を切れる（既定 200 TiB / 日）	cloud.google.com	2026-09-13
クエリ実行時間の上限	6 時間 / クエリ（マルチステートメントクエリも同じ）	6 時間で失敗するため、巨大な変換は中間テーブルに分割する。通常の集計は数秒〜数分で終わるので、ここに当たるのは設計の問題である	docs.cloud.google.com	2026-09-13
オンデマンドの同時スロット数	2,000 スロット / プロジェクト、20,000 スロット / 組織	同時に多数のクエリを流すと互いにスロットを取り合い、個々のクエリが遅くなる。安定した性能が必要なら Editions（スロット時間課金）で容量を確保する	docs.cloud.google.com	2026-09-13
テーブル変更回数と INSERT DML の同時実行	1,500 変更 / テーブル / 日（ロード・コピー・追記／上書きクエリが各1回）。INSERT DML はテーブルあたり 1,500 文まで即時実行、超えると同時実行が 10 に制限される	1分ごとに小さなロードジョブで追記する設計は1日で上限に当たる。バッチをまとめるか、Storage Write API によるストリーミングに切り替える（別料金）	docs.cloud.google.com	2026-09-13
クエリ応答サイズの上限	10 GB（圧縮時）。宛先テーブルへ書き出す場合は無制限	大きな結果を API で直接受け取ることはできない。結果はテーブルに書き、エクスポートか Storage Read API で取り出す	docs.cloud.google.com	2026-09-13
ストレージ料金と無料枠	アクティブ論理ストレージ $0.000031507 / GiB・時（月換算で約 $0.023 / GiB）、90 日変更なしの長期ストレージ $0.000021918 / GiB・時。毎月最初の 10 GiB は無料。バッチロードは無料、ストリーミング挿入（Storage Write API REST）は $0.01 / 200 MiB	保存自体は安価で、費用の中心はクエリのスキャン量になる。ただし高頻度の小さな書き込みをストリーミングにすると、保存より書き込み料金が先に効く	cloud.google.com	2026-09-13

典型的な落とし穴

LIMIT を付けても課金は減らない。読む列と読むパーティションを絞ることだけがスキャン量を減らす
パーティション列で絞らない WHERE（関数で加工した日付など）はフルスキャンになる。パーティションフィルタ必須の設定を有効にする
ダッシュボードの自動更新やスケジュールクエリが裏で毎回フルスキャンし、月末に請求で気づく。プロジェクト単位のカスタムクォータと請求アラートを先に設定する
テーブルの結果を BI ツールから直接毎回叩くと遅くて高い。集計済みの小さなテーブルを作り、BI はそこを見る

コスト

課金モデル: 無料枠あり
跳ねる条件: 毎月 1 TiB のクエリと 10 GiB のストレージまで無料。跳ねるのはスキャン量で、パーティションのない大テーブルへの繰り返しクエリと、BI ツールの自動更新が典型。書き込みはバッチロード無料、ストリーミングは別料金
出典: cloud.google.com 　検証 2026-09-13

代替手段と差分

代替	何が違うか
DuckDB	DuckDB は手元の1台で無料に動き、ローカルや S3 上のファイルを直接読めるが、1台の CPU・メモリ・ディスクが上限で複数人での共有に弱い。BigQuery はサーバーレスで TB〜PB 級を扱い、チームで共有し権限管理できるが、スキャン量課金と Google Cloud への取り込みが前提。1台に収まる規模なら DuckDB
PostgreSQL	PostgreSQL は行単位の更新・トランザクション・低遅延の問い合わせに強く、アプリのバックエンドになれる。BigQuery は更新に弱く応答は秒単位だが、数十億行の集計を分散実行する。業務データの正本は PostgreSQL、そこから複製した履歴の分析は BigQuery という分担が典型
pandas	pandas は Python 上で細かい加工と可視化ができるがメモリが上限。BigQuery で粗く集計した数万行を pandas に落として加工・描画する組み合わせが実務の標準

このツールを代替として挙げているページ： DuckDB 、pandas

選定判断

数百 GB〜TB 級のログ・イベント・履歴データを SQL で集計し、チームで共有・可視化する用途では第一候補で、無料枠だけで検証を始められる。行単位の更新が多いデータ、ミリ秒応答が要る画面のデータ源、1台に収まる規模でスキャン課金を避けたい場合は避け、PostgreSQL や DuckDB へ

Google Cloud のサーバーレスなデータウェアハウスで、サーバーやインデックスの管理をせずに SQL を投げると、数十億行でも分散実行で数秒〜数分で返る。ストレージと計算が分離しており、保存は安価で、計算はスキャン量（オンデマンド）かスロット時間（Editions）で課金される。スケジュールクエリで定期集計を回し、Looker Studio 等の BI から直接参照する構成が典型である。

利用者が最初に当たる制約は性能ではなく課金の仕組みである。費用は「読んだ列のバイト数」で決まり、行数や LIMIT では減らない。無料枠 1 TiB / 月は検証には十分だが、パーティションのない大テーブルを BI ツールが自動更新で繰り返し叩くと数日で消える。カスタムクォータと請求アラートを最初に設定してから使い始めるのが前提である。