Technical Guide

Google CloudでAI前提のデータ基盤を組む — BigQuery × Vertex AI 最小構成と設計判断

生成AIをプロダクトに組み込むなら、データ基盤の設計が9割を決める。ship が実装してきた Google Cloud ベースのAI前提アーキテクチャと、それぞれの設計判断の理由を整理した。

Google Cloud 上で構築する AI 前提データ基盤のイメージ

生成 AI をプロダクトに組み込むなら、データ基盤の設計が成果の 9 割を決めます。「どのモデルを使うか」よりも、「どのデータを、どの粒度で、どこに置いて、どう取り回すか」のほうが、長期的にはずっと重要です。

この記事では、ship が複数のプロダクト開発で実装してきた、Google Cloud をベースにした AI 前提データ基盤の最小構成と、各レイヤーの設計判断の理由を整理します。

最小構成の全体像

BigQuery と Vertex AI を中心としたデータ基盤のアーキテクチャ図

最小構成は次の 5 層です。

  • 入口層:Cloud Storage、Pub/Sub、外部 SaaS の Webhook
  • 蓄積層:BigQuery(生データ + 中間テーブル + 公開ビュー)
  • 処理層:Dataform、Cloud Run、Workflows
  • AI 層:Vertex AI(Embedding / 検索 / 推論 / Agent Builder)
  • 提供層:アプリケーション API(Cloud Run / GKE / Cloud Functions)

この 5 層を「データの流れの方向」で素直に並べるだけで、追加要件があってもアーキテクチャが破綻しにくくなります。

設計判断 1:なぜ BigQuery を中心に置くのか

BigQuery は単なるデータウェアハウスではなく、AI 前提アーキテクチャでは「データの単一ハブ」として機能します。

  • ストレージと計算が分離されているため、データ量が増えてもアプリ側に影響しない
  • BigQuery ML / Vertex AI 連携で、SQL から直接 Embedding 生成や推論呼び出しができる
  • 権限・監査ログ・暗号化が Google Cloud の標準に統合されている

PostgreSQL や MongoDB を中心に据えると、運用初期は軽快ですが、データ量が増えた段階で AI 連携・分析・監査の三方向すべてに歪みが出ます。最初から BigQuery に寄せておくと、将来の選択肢が増えます。

設計判断 2:なぜ Vertex AI を選ぶのか

Vertex AI を選ぶ最大の理由は、「Google Cloud の権限・ネットワーク設定をそのまま使える」点です。

外部の LLM API を直接叩く構成は確かに速く始められますが、本番投入を意識した瞬間に、API キー管理・ネットワーク境界・監査ログ・コスト分解の 4 つの課題が同時に重くなります。Vertex AI は最初からこれらに統合されており、社内ガバナンスや顧客監査に応えやすい構造になっています。

また、BigQuery → Vertex AI のデータ受け渡しが「同じプロジェクト内のサービス間呼び出し」で済むのも大きい。データを外に出さずに AI 処理が完結する点は、規制業界のプロダクトでは特に効きます。

設計判断 3:ストリーミング処理の扱い

「リアルタイム性が必要だから Streaming Pipeline を組む」という発想は、AI プロダクトの初期では多くの場合過剰です。

多くのユースケースは、Pub/Sub → BigQuery の Streaming Insert で十分。Vertex AI の Embedding 生成も、ユーザー操作のタイミングで都度叩くか、夜間バッチで主要データをまとめて Embedding する 2 系統で、ほぼすべての要件を満たせます。

Dataflow や Apache Beam を最初から導入すると、運用コストと学習コストの両方が跳ね上がります。本当に必要になってから足すこと。

設計判断 4:コスト設計の原則

データフローと各ステージのコスト発生ポイント

AI 前提データ基盤のコストは、「データ量」よりも「呼び出し回数」と「Embedding 生成回数」で爆発します。BigQuery のストレージは年々安くなっていますが、Vertex AI の Embedding 呼び出しは件数に比例します。

  • Embedding は「変更があったレコードのみ再計算」する設計にする
  • BigQuery 上に Embedding をキャッシュテーブルとして保持する
  • ユーザー検索は「キャッシュ済み Embedding を BigQuery で類似度検索」する

この 3 つを最初から組み込むだけで、コスト構造が劇的に安定します。

落とし穴

よくある落とし穴は、「Embedding の次元数とモデルを途中で変更してしまう」ことです。次元数が変わると、過去の Embedding はすべて互換性を失います。最初に選んだモデルとバージョンを、最低 1 年は固定する前提で運用設計してください。

まとめ:「データ基盤は事業の決断装置」

AI 前提の時代において、データ基盤は「裏方のインフラ」ではなく「事業の決断装置」になります。どのデータを、どの粒度で、どこに集めるかという設計が、AI の精度と事業の方向性を直接決めるからです。

ship の AI 時代のデータ活用基盤 では、Google Cloud をベースに、立ち上げから運用定着まで一気通貫で支援しています。プロダクトに AI を組み込みたい方は、ぜひ お問い合わせ からご相談ください。

Related Articles

関連記事