データ分析

BigQuery の仕組み: Google がエンべディングを分析に導入した方法

2025年11月18日

Andong Li

Software Engineer

Joe Malone

Product Manager, Google

Try Gemini 3

Our most intelligent model is now available on Vertex AI and Gemini Enterprise

Try now

※この投稿は米国時間 2025 年 11 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

エンべディングは、データと AI が交差する場所にある重要なコンポーネントであり、データ構造として、それらが表すデータの固有の意味をエンコードします。その重要性は互いに比較すると明らかになります。ベクトル検索は、共有スペース内のエンベディング間の距離を評価することで、それらの相対的な意味を明らかにする手法です。

2024 年初頭、Google は BigQuery データプラットフォームでベクトル検索をリリースし、その高度な機能をすべての BigQuery ユーザーが利用できるようにしました。これにより、専用のデータベースや複雑な AI ワークフローが効率的に除外されました。Google はベクトル検索を普及させるための継続的な取り組みを通じて、BigQuery のユーザーが期待するスケーリング、簡素性、費用対効果を実現する独自のアプローチを開発しました。この記事ではこの 2 年間を振り返りながら、プロダクト開発とお客様とのやり取りから得られた知見をご紹介します。

過去: 困難なベクトル検索の構築

BigQuery でベクトル検索がネイティブにサポートされる前、スケーラブルなベクトル検索ソリューションを構築するには、複雑な多段階のプロセスが必要でした。データ担当者は次の作業を行う必要がありました。

データウェアハウスからデータを抽出する
特殊な ML インフラストラクチャを使用してエンベディングを生成する
エンベディングを専用のベクトルデータベースに読み込む
サーバーのプロビジョニング、スケーリング、インデックス管理など、追加のインフラストラクチャを維持する
ベクトル検索の結果を中核となるビジネスデータに結合するためのカスタムパイプラインを開発する
インデックスの再構築中のダウンタイムに対処する（本番環境システムにとって重大な課題）

このアーキテクチャはまとまりがなく高額でメンテナンスも大変なため、多くのチームにとって導入の障壁となっていました。

始まり: 簡素性を重視

Google は、市場で最もシンプルなベクトルデータベースを作るという目標を掲げて BigQuery ベクトル検索をスタートさせました。この時点での主要な設計要件は次のとおりです。

完全にサーバーレスであること: Google は早い段階から、ベクトル検索をすべての BigQuery ユーザーに提供する最善の方法がサーバーレスにすることであるとわかっていました。そこでまず、クラスタリングとインデックス登録の利点を組み合わせた IVF インデックスを BigQuery 内に構築しました。こうすると、BigQuery でベクトル検索を使用するために新しいサーバーをプロビジョニングする必要は一切ありません。つまり、ベクトルデータベースの基盤となるインフラストラクチャを管理する必要がないため、チームは最も重要なもの、つまりデータに集中できます。BigQuery は、スケーリング、メンテナンス、信頼性に自動的に対処します。数十億のエンべディングを処理するように簡単にスケールできるため、ビジネスの成長に合わせてソリューションを拡大できます。
インデックスのメンテナンスができる限りシンプルであること: BigQuery のベクトルインデックスは、この簡素性を実現する重要な要素です。インデックスは、簡単な CREATE VECTOR INDEX SQL ステートメントで作成でき、残りは BigQuery が処理します。新しいデータが取り込まれると、インデックスは自動的かつ非同期的に更新されて変更が反映されます。また、取り込んだデータによってデータセットのデータ分布が変化し、検索精度が低下した場合でも、モデルの再構築機能を使用すれば、インデックスのダウンタイムなしで 1 つの SQL ステートメントだけでインデックスを完全に再構築できます。
GoogleSQL と Python に統合されること: 簡単な VECTOR_SEARCH 関数を使用して、既存の SQL ワークフロー内で直接、ベクトル検索を実行できます。そのため、セマンティック検索を従来のクエリや結合と簡単に組み合わせることができます。データサイエンティストにとって、LangChain や BigQuery DataFrames などのツールや Python との統合は、高度な ML アプリケーションを構築するうえで自然な選択肢となります。
整合性が保証されること: 新しいデータは、取り込み直後に VECTOR_SEARCH 関数で検索可能になり、検索結果の精度と整合性が確保されます。
使用した分だけを支払うこと: BigQuery ベクトル検索の料金モデルは、柔軟性を重視して設計されています。この「従量課金制」モデルは、アドホック分析と費用対効果の高いバッチクエリの両方に最適です。このモデルでは、多額の初期投資なしで機能を簡単に試せることが重視されています。
セキュリティが確保されていること: BigQuery のセキュリティインフラストラクチャでは、行レベルのセキュリティ（RLS）と列レベルのセキュリティ（CLS）を通じて、堅牢なデータアクセス制御が可能です。この多層アプローチにより、ユーザーは承認されたデータにのみアクセス可能になり、それによって保護が強化され、コンプライアンスが確保されます。

黎明期: お客様とともに成長

お客様は初期のプロジェクトで成果を挙げ、より多くのデータを BigQuery に移行する中で、新しいエンベディングベースのアプローチを使用するために「更新」している多くのデータサイエンスワークフローについて教えてくださいました。ベクトル検索で強化できるさまざまなアプリケーションの例をいくつかご紹介します。

検索拡張生成（RAG）を使用した大規模言語モデル（LLM）アプリケーション: 関連するビジネスデータを提供することで、ベクトル検索は LLM から正確で根拠のある回答を得るのに役立ちます。
ビジネスデータのセマンティック検索: 内部ユーザーと外部ユーザーの両方に対して、高度な自然言語検索機能が提供されます。たとえば、マーケティングチームは「ジェーンと似た購入履歴を持つ顧客」を検索して、意味的に類似する顧客プロファイルのリストを受け取ることができます。
Customer 360 と重複除去: 名前や住所などの詳細が多少異なる場合でも、エンべディングを使用して類似する顧客レコードを特定できます。これは、データをクリーンアップして統合し、顧客の単一ビューをより正確にするための効果的な方法です。
ログ分析と異常検出: ログデータをエンべディングとして取り込み、テキストが完全に一致しない場合でも、ベクトル検索を使用して類似するログエントリをすばやく見つけることができます。これは、セキュリティチームが潜在的な脅威や異常を非常に迅速に特定するのに役立ちます。
商品レコメンデーションの強化: 視覚的またはテキスト的に類似した商品（衣料品など）や、意味的に関連する補完的な商品が提案されます。

現在: スケーリングと費用対効果の向上

お客様による使用が増えるにつれて、RAG や生成 AI のワークロード以外にもバッチ処理に対する大きな需要があることがわかり、Google はサービスを強化しました。従来のベクトルデータベースとは異なり、BigQuery の改良されたバッチベクトル検索は、大規模なデータセットに対する高スループットの分析類似検索に優れています。これにより、データサイエンティストは既存のデータ環境内で数十億件のレコードを同時に分析し、これまで不可能だった次のようなタスク行えるようになりました。

大規模なクラスタリング: 行動エンべディングに基づいてデータベース内のすべての顧客をグループ化します。
包括的な異常検出: 金融台帳のすべてのアカウントで最も異常な取引を検出します。
アイテムの一括分類: 数百万のテキストドキュメントや商品画像を同時に分類します。

Google は開発の第 2 フェーズにおいて、ベクトル検索のエクスペリエンスをさらに向上させるために多くの新機能をリリースしました。

ScaNN インデックスを使用して構築された TreeAH は、価格とパフォーマンスにおいて大きな差別化要因となります。お客様のデータサイエンスチームは、レコメンデーション、クラスタリング、データパイプラインの多くをベクトル検索を使用するように移行していきました。TreeAH を使用したことで、大きな改善が見られました。
トレーニングとインデックス登録のパフォーマンスおよびユーザビリティの向上に役立つさまざまな内部改善を行いました。たとえば、非同期インデックストレーニングを追加しましたが、これにより大規模なインデックストレーニングジョブがバックグラウンドに移動されるため、ユーザビリティとスケーラビリティが向上しました。また、インデックス登録のパフォーマンスを向上させ、レイテンシを短縮するために、ユーザーに対する追加費用を発生させることなく、さまざまな内部最適化も実施しました。
保存された列は、ベクトル検索のパフォーマンスを向上させるのに役立ちます。

ユーザーは、ベクトル検索クエリで保存された列に事前フィルタを適用して、検索精度を損なうことなく検索パフォーマンスを大幅に最適化できます。
ユーザーがベクトル検索クエリで保存された列のみをクエリする場合、ベーステーブルとの高額な結合を回避することで、検索パフォーマンスをさらに向上させることができます。

パーティション分割されたインデックスでは、無関係なパーティションをスキップして I/O コストを大幅に削減し、クエリのパフォーマンスを向上させることができます。これは、日付や地域などのパーティショニング列で頻繁にフィルタを使用する場合に特に効果的です。
インデックスモデルの再構築は、ベクトル検索の結果が時間の経過とともに正確かつ関連性を維持できるようにするのに役立ちます。ベースデータが進化するにつれて、モデルドリフトをプロアクティブに修正できるようになり、インデックスのダウンタイムなしでベクトル検索アプリケーションの優れたパフォーマンスを維持できます。

今後: あらゆるものをインデックスに登録

企業がエージェント AI を検討する中、データプラットフォームの重要性はかつてないほど高まっています。Google は、すべての企業が生産性向上のための独自の AI モードを確保し、関連データの取得が生産性の中心となる世界を想像しています。これには、AI と分析を自動化するためのすべての関連する企業データ（構造化データおよび非構造化データ）のインテリジェントなインデックス登録が含まれます。インデックス登録と検索は Google の中核です。今後も、関連する技術革新について皆様にお伝えしてまいります。

-ソフトウェアエンジニア、Andong Li

-プロダクトマネージャー、Joe Malone

投稿先