Google Cloud · Field note

BigQuery のコストと仕組み 入門 ── DWH の速さと料金を表裏で理解する

BigQuery の速さは無料ではありません。カラム型ストレージとスキャン量課金の関係、東京リージョンの単価、無料枠、SELECT * フルスキャンなどの落とし穴を、コスト視点で整理します。安心して使い始める判断材料を提供します。

Google Cloud BigQuery 入門
Published
Read
9 min
Author
tgeas
目次
  1. BigQuery の位置付け ── サーバーレス DWH とは
  2. 仕組みの核心 ── カラム型ストレージと分散実行エンジン
  3. 代表的なユースケース ── どんな場面で使われるか
  4. 請求書を見て驚かないために
  5. コスト感 ── 東京リージョンの料金と無料枠
  6. まとめ
  7. 次に読む
  8. 参考文献

BigQuery の速さは、無料ではありません。本記事では、なぜ高速なのかという設計の核心と、その設計が料金 (スキャン量課金) として現れる仕組み、東京リージョンでの単価感、コストが膨らむ書き方の落とし穴を順に整理します。設計と料金の関係を理解して、安心して BigQuery を使い始める判断材料を揃えましょう。

BigQuery の位置付け ── サーバーレス DWH とは

BigQuery は、Google Cloud が提供するフルマネージドのデータウェアハウス (DWH) サービスです。DWH とは、大量のデータを蓄積・分析するための専用データベース基盤のことを指します。

「フルマネージド」とは、サーバーの調達・設定・スケールアップをすべて Google 側が担う、という意味です。また「サーバーレス」とも呼ばれますが、実際にはサーバーが存在しないわけではなく、利用者がサーバーを意識しなくてよい設計になっています。

従来の DWH では、クラスター規模の見積もりや定期メンテナンスが必要でした。BigQuery ではそれらが不要で、SQL を記述するだけで大規模な分析を開始できます。

このフルマネージドな振る舞いは、内部の 「列指向ストレージ + ストレージとコンピュートの分離 + スキャン量課金」という設計選択 から来ています。後述する高速性もコスト制御も、同じ設計の表裏として現れます。

BigQuery と主要な類似サービスの位置付け

サービス提供クラウド管理形態主な特徴
BigQueryGoogle Cloudサーバーレス設定ゼロで即利用可。Google 全サービスと連携
RedshiftAWSクラスター型クラスター設計が必要。AWS エコシステム向け
Redshift ServerlessAWSサーバーレスRPU 単位で自動スケール。クラスター管理不要だが AWS エコシステム前提
AthenaAWSサーバーレスS3 上のデータに直接クエリ。設定は軽量
Snowflakeマルチクラウドサーバーレスクロスクラウド対応。データ共有機能が強力

BigQuery の最大の差別化点は、Google Analytics・Looker・Vertex AI などの Google Cloud サービスとネイティブに統合されている点です。Google Analytics 4 のデータを BigQuery に直接エクスポートして分析できるため、広告・マーケティング用途との親和性が高いサービスです。

仕組みの核心 ── カラム型ストレージと分散実行エンジン

BigQuery の高速性とコスト制御は、「カラム型ストレージ」「分散実行エンジン」「ストレージとコンピュートの分離」という 3 つの設計が組み合わさって生まれます。順に見ていきます。

カラム型ストレージとは

一般的なデータベースは行単位でデータを格納します。例えば「ユーザー ID、購入日、金額」という 3 列のテーブルがあれば、1 行分 (1 ユーザーの購入レコード) をひとかたまりとして保存します。これを行指向ストレージと呼びます。

BigQuery は異なるアプローチを採用しています。カラム型ストレージ (列単位でデータを格納する方式) では、「金額」列のデータはすべて一箇所にまとめて保存されます。

-- 行指向: [U001, 2026-04-01, ¥3,000] [U002, 2026-04-02, ¥1,500] ...
-- 列指向: [U001, U002, ...]  [2026-04-01, 2026-04-02, ...]  [¥3,000, ¥1,500, ...]

「先月の売上合計を出したい」というクエリでは「金額」列だけを読めば十分です。行指向では全列を読み込んでから集計しますが、列指向では必要な列だけを読み込むため、読み込むデータ量が大幅に減ります。これが BigQuery の高速性と低コストの源泉です。

分散実行エンジン

BigQuery は、1 つのクエリを受け取ると内部で処理を細かく分割し、多数のサーバーに並列で割り当てます。各サーバーが担当分を処理して結果を集約するため、数 TB のデータでも数秒〜数十秒で結果が返ります。

また、データの保管場所（ストレージ）とクエリを処理するコンピュートが独立した構造になっているため、クエリ実行量が増えてもデータの保管コストは変わりません。

この 3 つは独立した機能ではなく、「読み込むデータ量を最小化し、コンピュートとストレージを独立にスケールさせる」という同じ設計思想の派生です。次のセクションで見るスキャン量課金は、その自然な帰結として現れます。

代表的なユースケース ── どんな場面で使われるか

BigQuery は以下のようなシナリオで特に力を発揮します。

ユースケース概要
マーケティング分析Google Analytics 4 や広告データを集約し、施策効果を SQL で集計
売上・KPI レポート数百万行規模の注文データを集計し、BI ツールに接続してダッシュボード化
ログ分析アプリケーションのアクセスログやエラーログを蓄積して傾向を把握
機械学習の前処理Vertex AI や BigQuery ML と組み合わせ、特徴量生成や学習データ抽出
データ共有Analytics Hub を通じてデータセットを社内外と安全に共有

特に Google Analytics 4 のデータエクスポート連携は追加費用なく設定でき、BigQuery に生データを取り込めます。ページビューや購入イベントを SQL で集計・加工できるため、Google Analytics の標準レポートでは出せない分析が実現します（BigQuery 側のストレージ・クエリ料金は別途発生します）。

請求書を見て驚かないために

仕組みのセクションで見た列指向ストレージは速さの源泉ですが、スキャン量に比例した課金 とセットで動きます。BigQuery のコストが膨らむのは、この設計の利点を活かす書き方ができていない時です。クエリの課金単位は結果の行数や実行時間ではなく、スキャンしたデータ量である点に注意します。

1. SELECT * は使わない

全列を取得する SELECT * は、テーブルのすべての列を読み込みます。カラム型ストレージの利点を完全に無効化するため、コストが最大化します。必要な列だけを明示的に指定しましょう。

-- NG: テーブル全列をスキャン
SELECT * FROM `project.dataset.orders`

-- OK: 必要な列だけ指定
SELECT order_id, amount, created_at FROM `project.dataset.orders`

2. LIMIT は課金を減らさない

LIMIT 10 と書いても、スキャンするデータ量は変わりません。BigQuery は結果を返す前にテーブル全体 (またはパーティション全体) を読み込むためです。探索目的で動作確認したい場合は、コンソールの「クエリ検証」機能でスキャン量を事前に確認する習慣をつけましょう。

3. 大きなテーブルにはパーティションを検討する

パーティション (特定の列でデータを区切る機能) を設定すると、WHERE created_at >= '2026-04-01' のような日付絞り込みで該当期間だけを読み込めます。またクラスタリング (よく使うフィルタ列でデータを物理的にソートする機能) も合わせて設定するとさらに効果的です。

パーティションはテーブル作成後に付与するのが困難なため、日付列があるテーブルはデータ量の大小に関わらず作成時点で設定しておくのが定石です。スキャン量削減の効果はデータが増えるにつれて継続的に得られます。

コスト感 ── 東京リージョンの料金と無料枠

BigQuery の料金は大きく「クエリ料金」と「ストレージ料金」に分かれます。

東京リージョン (asia-northeast1) の主な料金

種別料金補足
オンデマンドクエリ$7.50 / TiBスキャンしたデータ量に応じた従量課金
アクティブ論理ストレージ$0.023 / GiB / 月過去 90 日以内に変更があったデータ
長期論理ストレージ$0.016 / GiB / 月90 日以上変更がないデータに自動適用

※ 米国リージョン (US) のクエリ料金は $6.25 / TiB。東京は約 20% 高い設定です。料金単位は公式表記に合わせて TiB (テビバイト = 約 1.1 TB) を採用しています。ストレージ料金は GiB (ギビバイト = 約 1.07 GB) 単位の課金で、GB 表記との換算差が生じる場合があります。最新値は 公式料金ページ で asia-northeast1 を選択して確認してください。

毎月の無料枠

種別無料枠
クエリ処理1 TiB / 月
ストレージ10 GiB / 月

Google Analytics 4 のエクスポートデータを少量集計する程度であれば、無料枠内に収まるケースがほとんどです。まずはコンソールの「クエリ検証」でスキャン量を確認しながら、使用感を把握する習慣をつけましょう。

まとめ

BigQuery のサーバーレス・高速性・コスト制御は、すべて同じ設計 ── 列指向ストレージ + ストレージとコンピュートの分離 + スキャン量課金 ── から派生しています。仕組みを理解すれば、利点 (なぜ速い・なぜ手間が要らない) もリスク (なぜ課金が膨らみうるか) も同じ思想の表裏として読めます。

Google Analytics・Looker・Vertex AI など Google Cloud サービスとのネイティブ統合は、この基盤の上に乗っているからこそ実現します。まずは毎月 1 TiB の無料枠と「クエリ検証」によるスキャン量確認を活用し、SELECT * を避けて必要な列だけを指定する習慣から始めましょう。

次に読む

BigQuery は DWH としての高速性とコスト管理だけでなく、SQL ひとつで非構造化データ・機械学習・生成 AI まで扱える設計を持っています。SQL がどこまで届くのか、Object Tables や AI 関数群を含めた世界観を概観したい場合は、続編記事をご覧ください。

参考文献

Author
tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。