BigQuery 入門 ── SQL ひとつで構造化・非構造化・ML・生成 AI まで届く統合分析基盤

BigQuery を「Google Cloud のデータウェアハウス」とだけ理解するのは、半分しか合っていません。本記事では、サービスの位置付け、SQL が届く範囲、東京リージョンのコスト感、入門段階の落とし穴を順に整理します。設計と料金の仕組みをセットで把握して、BigQuery を安心して使い始める判断材料を揃えましょう。

BigQuery の位置付け ── サーバーレスの「データプラットフォーム」とはなにか

BigQuery は Google Cloud が提供する、完全マネージドのサーバーレス分析基盤です。サーバーの起動・スケールアップ・パッチ適用はすべて Google Cloud 側が担い、利用者はクエリを実行するだけで済みます。

計算リソースは スロット という仮想計算単位で管理されます。スロットは CPU・メモリ・ネットワーク帯域をひとまとめにした、仮想的な計算能力の単位だと捉えてください。

オンデマンド料金で使い始める段階では、スロット数を意識する必要はありません。後述する Editions (予約型) を選択した場合に、確保するスロット数が料金に直結します。

内部は 4 層の分散システムとして設計されています。

• Dremel: クエリ実行エンジン。ツリー状に分散して大規模データを並列処理する
• Colossus: 分散ストレージ。列指向フォーマット (Capacitor) でデータを保持する
• Jupiter: Google のデータセンター内ネットワーク。ストレージとコンピュートを高速で結ぶ
• Borg: Google の分散クラスタ管理システム。Dremel ワーカーの配置を制御する

この 4 つの固有名詞を覚える必要はありません。「ストレージとコンピュートが別々の層で動いている」という事実だけ押さえれば、料金体系や機能の広がりを理解する土台になります。

この構成で重要なのは、Dremel (コンピュート) と Colossus (ストレージ) が 物理的に分離している 点です。BigQuery がサービスとしてローンチされた 2012 年から、この分離設計は組み込まれていました。コンピュートとストレージを独立してスケールできるため、データ量の増加とクエリ性能の確保を別々の判断として扱えます。

「BigQuery はデータウェアハウスだ」という理解が半分しか合っていない理由もここにあります。構造化データの蓄積・検索だけでなく、非構造化データ・機械学習・生成 AI までを SQL ひとつで扱える設計は、列指向ストレージと分離アーキテクチャから派生しています。

SQL が届く 4 つの領域 ── 構造化・非構造化・ML・生成 AI

構造化データ

BigQuery のクエリ言語は GoogleSQL で、ANSI SQL 準拠です。標準的な SELECT / JOIN / GROUP BY のほか、ウィンドウ関数・地理空間関数・JSON 操作関数なども利用できます。

パーティションとクラスタリングは、コスト管理の観点で把握しておきたい設計選択です。パーティションはテーブルを日付・整数・取り込み時刻などで分割する機能で、クエリ実行時に対象パーティションだけをスキャン対象にできます。

クラスタリングは指定列の値に基づいてデータを物理的に整列させる機能です。どちらも設計の選び方でスキャン量が変わるため、スキャン量課金の BigQuery ではコストに直結します。

非構造化データ

BigQuery は Cloud Storage 上に置いた画像・音声・動画・PDF などの非構造化データも、SQL の対象にできます。この仕組みを Object Tables と呼びます。

以下は Cloud Storage 上の画像ファイル群を Object Table として参照する例です。

-- Object Table から JPEG 画像のメタデータを取得する例
SELECT uri, content_type, size
FROM `my_project.my_dataset.my_image_table`
WHERE content_type = 'image/jpeg'
LIMIT 10;

また、Apache Iceberg・Delta Lake などの外部テーブルフォーマットを BigQuery から直接クエリできる機能として BigLake があります。

BigLake を使うと、データを BigQuery ネイティブストレージに移行しなくても、既存の外部データレイクを同一の SQL インターフェースで扱えます。

BigQuery ML

BigQuery ML は CREATE MODEL 構文だけで機械学習モデルの学習・評価・推論を BigQuery 内で完結させる機能です。Python や R の環境を別途用意する必要はありません。

対応している主なモデルタイプは次のとおりです。

• 線形回帰 (LINEAR_REG)
• ロジスティック回帰 (LOGISTIC_REG)
• k-means クラスタリング (KMEANS)
• 時系列予測 (ARIMA_PLUS)

以下は線形回帰モデルを作成する最小限の例です。

-- 線形回帰モデルを作成する例
CREATE OR REPLACE MODEL `my_project.my_dataset.my_model`
OPTIONS(model_type = 'LINEAR_REG',
        input_label_cols = ['label_column'])
AS
SELECT feature1, feature2, label_column
FROM `my_project.my_dataset.training_data`;

さらに、Vertex AI と連携することで AutoML・TensorFlow・PyTorch で学習した外部モデルも、同じ SQL インターフェースから呼び出せます。

生成 AI

BigQuery には、大規模言語モデルや生成 AI を SQL から直接扱うための関数群が用意されています。代表的なものを整理します。

• AI.GENERATE / AI.GENERATE_TEXT: テキスト生成・要約・変換
• AI.GENERATE_TABLE: 構造化データを生成して返す
• AI.FORECAST: 時系列予測 (TimesFM ベースのゼロショット予測) を実行
• AI.IF / AI.CLASSIFY: 条件判定・分類 (執筆時点で Public Preview)

VECTOR_SEARCH 関数とベクトルインデックスを組み合わせると、埋め込みベクトル同士の類似検索を SQL で実行できます。セマンティック検索 (意味的な近さで結果を返す検索) や推薦システムの基盤として使えます。

Object Tables と AI 関数を組み合わせると、Cloud Storage 上の画像や PDF をマルチモーダル LLM で直接分析できます。

BigQuery からは、Vertex AI 経由で多数の基盤モデルにアクセスできます。Gemini・Claude・Llama などを Vertex AI を介して SQL から呼び出す構成です。

以下は AI.GENERATE でレビュー文を要約する例です。connection_id には事前に作成した BigQuery 接続 (LOCATION.CONNECTION_ID 形式) を指定します。

-- AI.GENERATE でレビュー文を 1 文に要約する例
SELECT
  review_id,
  AI.GENERATE(
    CONCAT('次のレビューを 1 文で要約してください: ', review_text),
    connection_id => 'asia-northeast1.model_connection',
    endpoint => 'gemini-2.5-flash'
  ).result AS summary
FROM `my_project.my_dataset.reviews`
LIMIT 5;

この設計の根拠は、先に述べた列指向ストレージとストレージ・コンピュート分離にあります。スキャン量課金の仕組みを維持したまま、同じ SQL エンジンが ML・生成 AI のワークロードにも拡張されています。

その結果、「分析 SQL で作ったテーブルをそのまま ML・AI の入力にできる」という一貫性が生まれています。

料金モデルの全体像 ── 無料枠とオンデマンド・Editions の使い分け

BigQuery の料金体系は、ストレージ料金 と クエリ料金 の 2 軸で構成されます。

クエリ料金には 2 つのモデルがあります。オンデマンド はスキャンしたデータ量 (TiB 単位) に応じた従量課金で、まず使い始める段階の標準形です。Editions (Standard / Enterprise / Enterprise Plus) はスロット数を事前に確保する予約型で、大量クエリを定常的に実行する場合に向きます。

毎月の無料枠として、クエリ処理量 1 TiB とストレージ 10 GiB が提供されます。試験的な用途や小規模なデータ活用であれば、無料枠の範囲で動作確認まで進められます。

スキャン量課金は、列指向ストレージと直結しています。BigQuery は SELECT で参照した列のデータだけを読み込むため、SELECT * で全列を読むか、必要な列だけを指定するかでコストが大きく変わります。

東京リージョン (asia-northeast1) の具体的な単価感や、コストが膨らみがちな書き方の落とし穴については、姉妹記事「BigQuery のコストと仕組み 入門」で詳しく扱っています。本記事ではこのあと、AI 関数群の利用に固有のコスト要因だけ補足します。

実際の活用事例 ── 導入企業の用途と効果

BigQuery は単なるクエリエンジンではなく、分析・ML・生成 AI を 1 基盤に集約する用途で使われています。

SmartDaily (KNST CO., LTD.) は、BigQuery・Vertex AI・Gemini を組み合わせて CS 対応を効率化しました。1 件あたりの CS 処理時間が 15 分から 7 分に短縮されています。BigQuery 上でデータを整形し、そのまま ML・生成 AI の処理へ渡す構成です。

Gina Tricot (スウェーデンのファッション小売) は、BigQuery ML の回帰モデルを活用して販売予測と在庫予測を実装しました。SQL ベースの機械学習を段階的に導入した事例です。

IG Group (英国の金融サービス) は、データパイプラインのメダリオンアーキテクチャ全レイヤーを BigQuery に集約しました。Bronze / Silver / Gold の 3 層を 1 基盤内で完結させ、運用の複雑さを抑えています。

3 社に共通しているのは、「BigQuery 1 基盤に集約することで運用の対象システムを絞り、SQL で処理を完結させた」という点です。分析・ML・生成 AI を別々のツールに分散させずに済むため、データの受け渡しや権限管理のコストが下がっています。

ML・生成 AI を SQL で扱うときの注意点

ここでは、本記事の主軸である ML・生成 AI を SQL から呼び出す際の固有の注意点だけ取り上げます。SELECT * フルスキャンやパーティション設計など、構造化データのクエリに共通する落とし穴は姉妹記事「BigQuery のコストと仕組み 入門」で扱っています。

Vertex AI 側の課金が別途発生する

CREATE MODEL による学習や AI.GENERATE などの AI 関数の実行には、BigQuery のクエリ料金とは別に Vertex AI 側の課金が発生します。

トレーニングの規模や API 呼び出し回数 (= 入力レコード数) に応じて費用が積み上がるため、本番利用前にモデルごとの料金体系を確認しておくことを勧めます。

AI 関数は接続リソースが前提になる

AI.GENERATE をはじめとする AI 関数は、Vertex AI を呼び出すための BigQuery 接続 (CLOUD_RESOURCE 接続) をあらかじめ作成しておく必要があります。connection_id には LOCATION.CONNECTION_ID 形式で指定し、クエリを実行するロケーションと接続のロケーションを揃える点に注意してください。

Preview 機能はリリースノートで状況確認を

AI.IF / AI.CLASSIFY のように Public Preview の AI 関数は、構文や挙動が変更される可能性があります。本番投入前に BigQuery のリリースノート で GA 状況を確認するのが安全です。

まとめ

BigQuery の速さとコスト制御の仕組みは、列指向ストレージ・ストレージとコンピュートの分離・スキャン量課金 という 3 つの設計から派生しています。この根本的なアーキテクチャが、構造化データの高速集計だけでなく、非構造化データ・機械学習・生成 AI までを SQL ひとつで扱える統合分析基盤としての BigQuery を成立させています。

SQL が届く範囲は、GoogleSQL による構造化データ処理を起点に、Object Tables・BigLake・BigQuery ML・AI 関数群へと広がっています。SmartDaily・Gina Tricot・IG Group の 3 社はいずれも、この 1 基盤に集約して SQL で処理を完結させることで、別ツールへのデータ受け渡しや権限管理の負荷を下げています。

ML・生成 AI まで含めた構成では、BigQuery のクエリ料金に加えて Vertex AI 側の課金や接続リソースの設計が前提になります。まずは構造化データのクエリで無料枠 (クエリ 1 TiB/月 + ストレージ 10 GiB/月) から試し、AI 関数を呼ぶ段階で接続作成と料金体系を確認する、という順序が安全です。

次に読む

東京リージョンの単価感、SELECT * フルスキャン、パーティション設計、長期ストレージ移行など、コスト管理の落とし穴を実用レベルで深掘りする内容は姉妹記事にまとめています。

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

参考文献

• BigQuery 公式ドキュメント Introduction
• BigQuery Under the Hood (公式ブログ)
• Separation of storage and compute in BigQuery (公式ブログ)
• BigQuery スロット
• BigQuery 料金 (asia-northeast1 基準)
• Object Tables の概要
• BigLake の概要
• BigQuery ML の概要
• AI.GENERATE リファレンス
• AI.FORECAST リファレンス
• VECTOR_SEARCH の概要
• マルチモーダルデータ分析チュートリアル
• 事例: SmartDaily
• 事例: Gina Tricot
• 事例: IG Group

Author

tgeas

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

profile