2026.04.02 コラム

• BigQuery
• テックコラム
• ベクトル検索
• 生成AI

【テックコラム】BigQueryのベクトル検索：VECTOR_SEARCH と AI.SEARCH の使い分けと vector index の活用ポイント

はじめに

こんにちは！ジョージです。

生成AIやRAGの活用が広がる中で、「ベクトル検索をどこで実装するか」は多くのチームが悩む論点です。専用のベクトルDBを最初から導入すべきか、それとも既存の分析基盤である BigQuery でどこまで実現できるのか。本記事では、BigQuery の検索関数である VECTOR_SEARCH と AI.SEARCH の違いを整理したうえで、それらを高速化する vector index の役割も含めて、実務でどう使い分けるべきかを整理します。

いきなり結論

BigQuery のベクトル検索は、すでにデータが BigQuery に集約されている環境であれば、社内文書検索、類似商品検索、レコメンド候補生成、RAG のPoC〜初期本番で十分に活用しやすい選択肢です。重要なのは、VECTOR_SEARCH と AI.SEARCH をどう使い分け、どのタイミングで vector index を組み合わせるかを整理することだと考えています。

一方で、vector index は ANN（Approximate Nearest Neighbor）による近似検索であり、速度と引き換えに厳密な全件比較とは性質が異なります。また、index 更新は非同期で、テーブルサイズやクエリ特性によって効果も変わります。したがって、まずは BigQuery を基準として評価し、厳しいリアルタイム要件がある場合には別サービスと比較してみると良いのではないでしょうか。

VECTOR_SEARCH と AI.SEARCH の違い、そして vector index の役割

VECTOR_SEARCH と AI.SEARCH は検索関数で、vector index はその検索を高速化するための仕組みです。

• VECTOR_SEARCH
  埋め込みベクトル列に対して類似検索を行う基本機能です。index がなければ brute force、index があれば ANN で高速化できます。

• AI.SEARCH
  自律型エンベディング生成が有効なテーブルに対する semantic search 用の table-valued function です。単一の文字列クエリを埋め込み化して、近い行を簡潔な構文で探せるのが特徴です。

• vector index
  VECTOR_SEARCH や AI.SEARCH を高速化するためのインデックスです。大規模データで特に効果が出やすい一方、近似検索である点は留意が必要です。

検索方法として AI.SEARCH と VECTOR_SEARCH を使い分け、そのうえで性能要件に応じて vector index を組み合わせる、という役割です。

BigQueryでベクトル検索するメリット

BigQuery でベクトル検索する最大のメリットは、分析基盤と検索基盤を分離せずに始められることです。すでに商品データ、文書データ、ログデータが BigQuery に集まっているなら、別基盤への同期や二重運用を増やさずに類似検索やRAGの土台を作ることができます。

また、自律型エンベディング生成により、ソース列の更新に応じた埋め込み管理を BigQuery 側に寄せやすくなっています。さらに、INFORMATION_SCHEMA.VECTOR_INDEXES で index の状態を確認できるため、作って終わりではなく運用監視まで SQL ベースで寄せられるのも利点です。

VECTOR_SEARCH が向いているケース

VECTOR_SEARCH が向いているのは、検索対象の埋め込みも、クエリ側の埋め込みも、自分で明示的に扱いたいケースです。たとえば、複数クエリをまとめて検索したい場合や、利用する埋め込みモデルや前処理を自前で制御したい場合に向いています。

SELECT *
FROM VECTOR_SEARCH(
  TABLE `my_project.my_dataset.product_embeddings`,
  'embedding',
  (
    SELECT query_embedding
    FROM `my_project.my_dataset.query_embeddings`
    WHERE query_id = 'q_001'
  ),
  top_k => 10
);

AI.SEARCH が向いているケース

AI.SEARCH は、簡単に自然言語検索を試したいときの第一候補です。自律型エンベディング生成が有効なテーブルに対して、単一の文字列クエリをその場で埋め込み化し、近い行を探せます。社内文書検索やFAQ検索のように、「意味ベースで近いものが返ってくるかを見たい」場面では特に有効です。

なお、AI.SEARCH の第2引数は embedding 列ではなく、自動生成された embedding の元になっている文字列列名を指定します。

SELECT *
FROM AI.SEARCH(
  TABLE `my_project.my_dataset.knowledge_base`,
  'content',
  "契約書レビューのベストプラクティスを知りたい"
);

検索クエリを大量に処理したい場合や、クエリ側埋め込みを自前制御したい場合は VECTOR_SEARCH が向いています。したがって、PoCの入口は AI.SEARCH、制御性や評価を重視する段階では VECTOR_SEARCH という使い分けがわかりやすいでしょう。

vector index を検討するタイミング

vector index は、VECTOR_SEARCH や AI.SEARCH を高速化するための仕組みです。特にベーステーブルが大きい場合、検索レイテンシと計算コストの改善が期待できます。

ただし、注意点もあります。1つ目は、検索結果が近似になること。多くのケースでは十分実用的ですが、厳密な比較が必要な場面では brute force との比較評価が必要です。2つ目は、小さいテーブルでは index の効果が見えにくいことがある点です。

BigQuery の vector index には IVF と TreeAH の2種類があります。公式では、小さめの query batch では IVF、大きめの query batch では TreeAH が推奨されています。特に TreeAH は、数百件以上の query vector を含む batch query に最適化されています。

CREATE VECTOR INDEX my_index
ON `my_project.my_dataset.product_embeddings`(embedding)
OPTIONS(index_type = 'IVF');

SELECT
  table_name,
  index_name,
  index_status,
  coverage_percentage
FROM `my_project.my_dataset`.INFORMATION_SCHEMA.VECTOR_INDEXES;

運用時は、有効になっているか、coverage が十分か を見ることが重要です。

活用時に注意したいケース

低いレイテンシが求められるケースや更新反映の即時性が厳しいケースでは要件を丁寧に見る必要があります。vector index は高速化に有効ですが、ANN かつ非同期更新という特性があるためです。

また、自律型エンベディング生成を使う場合、埋め込みが欠落している行は検索時にスキップされます。本番では、検索そのものだけでなく埋め込み生成の監視も品質管理の一部として検討すると良いでしょう。

まとめ

BigQuery のベクトル検索を検討するうえで重要なのは、VECTOR_SEARCH と AI.SEARCH の役割の違いを理解し、そのうえで性能要件に応じて vector index を組み合わせることです。分析基盤の延長で検索やRAGを実装したい場合、BigQuery は有力な選択肢になります。まずは自社の要件に照らして、どの関数を入口にし、どの段階で index を活用するかを整理してみてはいかがでしょうか。

参考ドキュメント

• BigQuery のベクトル検索概要
• VECTOR_SEARCH の概要
• AI.SEARCH の構文リファレンス
• Vector index の概要と IVF / TreeAH
• INFORMATION_SCHEMA.VECTOR_INDEXES
• Autonomous embedding generation
• BigQuery の search functions
• VECTOR_INDEX 関数リファレンス
• Semantic search と RAG のチュートリアル

最後に

自社に専門人材がいない、リソースが足りない等の課題をお持ちの方に、エンジニア領域の支援サービス（Data Engineer Hub）をご提供しています。 お困りごとございましたら是非お気軽にご相談ください。

本件に関するお問い合わせは下記にて承ります。
株式会社DataCurrent
info@datacurrent.co.jp