9月23日、Google Developer Expert（アカウント名：gde）が「Production RAG on the Lakehouse with BigQuery Vector Search and Apache Iceberg」と題した記事をdev.toに公開した。BigQuery Vector SearchとApache IcebergをGoogle Cloud上で組み合わせ、データレイクハウスを単一の基盤として本番RAGシステムを構築する手法を詳説した内容で、外部ベクトルDBとの同期パイプライン維持に頭を悩ませているチームには刺さる一本だ。

データスタックとAIスタックの分断が招く問題

多くの組織がRAG（Retrieval-Augmented Generation）システムを構築する際に陥る罠がある。ソースデータはデータレイクハウスに置いたまま、ベクトル検索用のデータだけをPineconeやMilvus、Weaviateといった外部ベクトルデータベースに別途コピーするアーキテクチャだ。

一見シンプルに見えるこの構成には、本番運用で致命的になる問題が二つある。

メタデータドリフトとセキュリティの断片化だ。

メタデータドリフトとは、元のデータソースが更新されても、ベクトルDBへの同期が遅延・失敗することで生じるズレを指す。たとえば商品カタログで「リコール済み」に更新された商品が、RAGチャットボットからは古い情報のまま回答され続けるケースがこれにあたる。ユーザーへの誤情報提供は技術的な問題に留まらず、ビジネスリスクに直結する。同期パイプラインの監視・リカバリのコストも看過できない。

セキュリティの断片化も深刻だ。企業のデータレイクハウスにはIAMロール、行レベルアクセス制御、列レベルセキュリティといった精緻なガバナンスモデルが整備されている。データを外部ベクトルDBにコピーした瞬間、そのセキュリティモデルをゼロから再実装しなければならない。退職した社員のアクセスをレイクハウス側で削除しても、ベクトルDB側では残り続ける——こうした運用ミスが監査上のリスクになる。二重管理のオーバーヘッドは、システムが大きくなるほど指数的に膨らむ。

解決策：ベクトル検索をレイクハウスに統合する

記事が提示するアプローチは「データをAIシステムに移すのではなく、AI機能をデータのそばに持ち込む」という発想の転換だ。

具体的には、ベクトル埋め込みを外部DBに送り出すのをやめ、Apache IcebergテーブルのカラムとしてそのままGCS上に格納する。カラムの型はARRAY<FLOAT64>だ。BigQueryはBigLake機能を通じてGCS上のIcebergテーブルを直接クエリでき、さらにBigQuery Vector Searchによってそのカラムに対してANNインデックスを構築できる。

この構成がもたらすメリットは明確だ：

• データの重複なし：ETLパイプラインも同期処理も不要
• ゼロドリフト：IcebergのACIDトランザクションにより、テキスト・メタデータ・ベクトルが1トランザクションで原子的に更新される
• 統一されたセキュリティ：既存のIAMポリシーと行・列レベルのアクセス制御がベクトル検索にも自動的に適用される

実装パイプラインの全体像

記事ではGoogle Cloud上での具体的な構成を次のように示している。

コンポーネントの役割分担：

インデックス構築の流れ：

1. GCSバケットに新規ドキュメントをアップロード
2. Cloud FunctionやDataflowジョブがトリガーされ、テキストのパース・チャンキングを実行
3. 各チャンクをVertex AI Embedding APIに送り、ベクトルを取得
4. テキスト・ベクトル・メタデータ（ソースファイル名、ページ番号等）をIcebergテーブルに一括書き込み
5. BigQueryのDDL文でVECTOR_INDEXを作成・更新

ベクトルインデックスの作成はBigQuery側が自動でバックグラウンド処理する。なお、BigQuery公式ドキュメントによれば、VECTOR_INDEXの作成にはテーブルが一定のサイズ（デフォルト設定では10MB以上）に達している必要があり、小規模なテーブルではフルスキャンにフォールバックする点に注意が必要だ。インデックスのアルゴリズムとしてはSCANN（Scalable Approximate Nearest Neighbor）ベースのANN実装が採用されており、大規模コーパスでも高い検索スループットを維持できる。

Icebergを選ぶ理由

Apache Icebergが本構成で重要な役割を担うのは、単なるファイルフォーマット以上の機能を持つからだ。同時書き込み時のデータ破損を防ぐトランザクション保証、メタデータフィールド追加時のスキーマ進化、パーティション最適化によるクエリ高速化に加え、SparkやFlinkといった他エンジンからもアクセスできるオープン標準であることがベンダーロックインを防ぐ。

BigQueryはIcebergテーブルをBigLake経由で直接読み書きできるため、データを変換・移動させることなくSQLで操作できる。また、Icebergのタイムトラベル機能を活用すれば、ベクトル埋め込みの過去バージョンへのロールバックも容易であり、埋め込みモデルの切り替えやデータ品質問題への対応にも強い構成といえる。

まとめ

この構成の核心は「ベクトルDBという新しいサイロを作らない」という一点に集約される。BigQuery Vector SearchとApache Icebergの組み合わせにより、既存のデータガバナンスとセキュリティモデルをそのままにRAGを本番投入できる。外部ベクトルDBとの同期パイプライン維持に悩んでいるチームはもちろん、データガバナンスや監査要件が厳しい企業環境でRAGを展開したいチームにとっても、まず試す価値のある選択肢だ。BigQuery Vector SearchのQuickstartと合わせて、実際に手を動かしてみることをすすめる。

詳細はProduction RAG on the Lakehouse with BigQuery Vector Search and Apache Icebergを参照していただきたい。