Google Cloud · Field note

Vector Search 2.0 が変えた設計思想 ── Agent Search とDB組込み型ベクトル検索の使い分け

Vertex AI Vector Search 2.0 (2026 年 3 月 GA) と Agent Search の使い分けを軸に、AlloyDB・Cloud SQL・Spanner・BigQuery・Firestore への同居構成と、ANN / KNN の課金体系を整理します。

Google Cloud 中級 Vertex AI Vector Search Agent Search RAG Embeddings AlloyDB Cloud SQL Spanner BigQuery Firestore
Published
Read
22 min
Author
tgeas
目次
  1. インデックス管理からコレクション管理へ ── Vector Search 1.0 と 2.0 の設計転換
  2. GA で揃った 4 つの柱 ── コレクション・自動埋め込み・ハイブリッド検索・ネットワークセキュリティ
  3. Vector Search 2.0 と Agent Search ── build と all-in-one の使い分け
  4. プライマリ DB に同居させる選択肢 ── OLTP / OLAP / NoSQL の場合
  5. 東京リージョンで試算する ── ANN と KNN の月額コスト感
  6. GA 後の運用で意識しておきたい設計ポイント ── 次元数・Streaming Update・SLA
  7. まとめ ── build と all-in-one の使い分けと、同居型の引き出し
  8. 参考文献

本記事では、2026 年 3 月に GA となった Vertex AI Vector Search 2.0 と、Google Cloud 内外のベクトル検索サービスの使い分けを整理します。

1.0 からの設計上の変化、GA で揃った 4 つの柱、Vector Search 2.0 と Agent Search の階層関係、プライマリ DB への同居構成 (AlloyDB / Cloud SQL / Spanner / BigQuery / Firestore)、ANN と KNN それぞれの料金感、運用設計で意識する項目を順に確認します。

ここで整理した判断材料をもとに、RAG や類似検索の構成選定に役立ててください。

インデックス管理からコレクション管理へ ── Vector Search 1.0 と 2.0 の設計転換

Vertex AI Vector Search の前身は 2021 年に登場した Matching Engine です。2023 年 11 月に Vertex AI Vector Search へリブランドされました。

その次の世代にあたる 2.0 が 2026 年 3 月 5 日に GA (リリースノート) となりました。

1.0 の設計では、インデックスがプライマリリソースでした。ベクトルデータをアップロードする前に、インデックスを作成して Endpoint にデプロイし、VM ノードのタイプ (e2-standard-2 など) とレプリカ数を明示的に設定する必要があります。

2.0 の設計では、操作単位が変わります。Collection というリソースが中心となり、その中に JSON 形式の Data Object を直接格納します。リレーショナルデータベースのテーブルとレコードの関係に近く、ベクトルデータを「インデックスへ流し込むもの」ではなく「コレクションに格納するドキュメント」として扱う設計です。

インフラ設定をほとんど意識せずにベクトルデータを扱えるという点で、AI ネイティブ検索エンジンとしての操作モデルが整った転換点です。

GA 時点で 9 リージョン (asia-northeast1 = 東京 を含む) に展開されており、Private Service Connect (PSC) / Private Google Access (PGA) / VPC Service Controls などのネットワークセキュリティもサポート対象になっています。

eBay が Vertex AI Vector Search (1.0) を採用した事例では、1.9 億件のリスティングデータを対象に P95 レイテンシ 4ms を実現しています。

内部で使われているアルゴリズムは Google が開発した ScaNN (Scalable Nearest Neighbors) で、Google 検索・YouTube・Google Maps のような大規模サービスで実績があります。2.0 もこの ScaNN ベースの検索エンジンを継承しています。

GA で揃った 4 つの柱 ── コレクション・自動埋め込み・ハイブリッド検索・ネットワークセキュリティ

リリースノートが GA 時点での重点機能として挙げているのは次の 4 つです。

コレクションが最初の柱です。1.0 では埋め込みベクトルと ID、メタデータを別々に管理する必要がありました。2.0 では JSON Data Object をそのままコレクションに格納できます。埋め込みベクトルを事前に生成しておく必要はなく、テキストや画像などの生データを格納してから埋め込みを生成することもできます。

Auto-Embeddings が 2 つ目の柱です。Vertex AI の埋め込みモデルをネイティブに統合しており、gemini-embedding-001 (最大 3,072 次元、Matryoshka 表現学習で次元削減可) と text-embedding-005 (768 次元) をそのまま利用できます。

自前で埋め込みを生成して格納する BYOE (Bring Your Own Embeddings) も引き続き対応しています。既存パイプラインで埋め込みを生成している場合は、そのまま 2.0 のコレクションに投入できます。

RAG Engine や Agent Builder など Vertex AI エコシステムとの連携を前提とするシステムでは、Auto-Embeddings との親和性が判断材料になります。埋め込みモデルを切り替える際の API 変更やパイプライン改修を最小化したい場合に効いてきます。

ハイブリッド検索とランキングが 3 つ目の柱です。リリースノートでは、ベクトル検索・全文検索・組み込みのセマンティック再ランキングを単一の並列クエリで統合できるとされています。1.0 でもハイブリッド検索 (sparse + dense) は GA でしたが、2.0 ではセマンティック再ランキングまでが標準ワークフローに組み込まれています。

ネットワークセキュリティ が 4 つ目の柱です。Private Service Connect (PSC) / Private Google Access (PGA) / VPC Service Controls がサポート対象に含まれており、社内ネットワーク要件の厳しい環境でも本番運用に乗せやすくなっています。

GA に合わせて料金体系も整理されました。ANN インデックスを使うか、ANN を使わずに正確な KNN 検索を直接実行するかで課金軸が分かれます。ANN は Capacity Unit (CU) を時間単位でプロビジョニングする課金 (パフォーマンス最適化 CU $0.065/時間、ストレージ最適化 CU $2.30/時間)、KNN はペイロードデータベースに対する操作単位の従量課金 (読み取り $0.06 / 100,000 件、書き込み $0.18 / 100,000 件、保存 $0.000410959/GiB/時間) という構造です。

Vector Search 2.0 用の Python SDK は google-cloud-vectorsearch パッケージとして独立しており、google.cloud.vectorsearch_v1beta から VectorSearchServiceClient (コレクション操作)・DataObjectServiceClient (Data Object 操作)・DataObjectSearchServiceClient (検索操作) を import します。以下は 公式ドキュメントの Python サンプル を抜粋した Data Object 作成の例です。

from google.cloud import vectorsearch_v1beta

data_object_service_client = vectorsearch_v1beta.DataObjectServiceClient()

data_object = vectorsearch_v1beta.DataObject(
    data={
        "title": "The Shawshank Redemption",
        "genre": "Drama",
        "year": 1994,
        "director": "Frank Darabont",
    },
    vectors={
        "plot_embedding": {"dense": {"values": [0.1, 0.2, 0.3]}},
        "sparse_embedding": {"sparse": {"values": [1.0, 2.0], "indices": [10, 20]}},
    },
)

request = vectorsearch_v1beta.CreateDataObjectRequest(
    parent="projects/PROJECT_ID/locations/LOCATION/collections/COLLECTION_ID",
    data_object_id="DATA_OBJECT_ID",
    data_object=data_object,
)

response = data_object_service_client.create_data_object(request=request)

vectors フィールドに自分で生成した埋め込みを渡す BYOE のパターンです。Auto-Embeddings を有効にしたコレクションでは、対応するフィールドの vectors 指定を省略すると、組み込みモデルが自動的にベクトルを生成して埋めてくれます。

Vector Search 2.0 と Agent Search ── build と all-in-one の使い分け

Agent Search (旧 Vertex AI Search) は Vector Search 2.0 の競合サービスではなく、抽象度が一段上のマネージド検索です。

Agent Search は、データの取り込みから OCR・チャンク化・埋め込み生成・インデックス構築・ランキング・要約までを一つのサービスとして提供します。Vector Search 2.0 は、Google Research が開発した ScaNN エンジンを直接操作できる低レイヤーの構成要素 (building block) で、Agent Search が提供するパイプラインを自分で組み立てたい場合の選択肢です。

この関係を踏まえると、判断軸は「どちらが優れているか」ではなく「どこから自分で組み立てるか」になります。

判断軸 1: 立ち上げ速度。Agent Search はデータソースへのコネクタ接続だけで数時間以内に検索機能を用意できます。Vector Search 2.0 は取り込みパイプラインを自前で実装するため、実用水準に達するまで数日以上かかります。

判断軸 2: 東京リージョン対応。Vector Search 2.0 は GA 時点で asia-northeast1 (東京) に対応しています。Agent Search は global / us / eu のみの対応で、asia-northeast1 は現時点で利用できません。データ所在地に東京リージョン要件がある場合は、この差が致命的な制約になります。

判断軸 3: カスタマイズの深度。Agent Search はデータソース設定と Boost ルールの範囲でランキングを調整できます。Vector Search 2.0 は埋め込みモデルの選択・ANN パラメータ・フィルタ条件・crowding (結果の多様性制御) まで自分で設定できます。

軸Vector Search 2.0Agent Search
抽象度低 (building block)高 (all-in-one)
立ち上げ速度数日〜 (パイプライン自前実装)数時間 (コネクタ接続のみ)
東京 (asia-northeast1)GA 対応非対応 (global / us / eu のみ)
課金モデルANN: CU 時間 / KNN: 操作単位 (読み取り・書き込み count)per-query + per-GiB (サーバーレス)
内蔵 ingest パイプラインなし (OCR / チャンク / 埋め込みは自前実装)あり (Cloud Storage / BigQuery / Drive / SharePoint コネクタ直結)
カスタマイズ深度高 (埋め込み・ANN・フィルタ自由)中 (Boost ルール + データソース設定)
マルチモーダルBYOE で任意モーダルに対応主にテキスト文書 (非構造化画像も対応)
マルチテナントコレクション + フィルタで設計しやすいデータソースアクセス制御 (プレビュー)

料金の構造も異なります。Agent Search は Standard $1.50 / 1,000 クエリ、Enterprise $4.00 / 1,000 クエリという従量課金で、毎月最初の 10,000 クエリ (高度な生成回答は除く) とインデックスストレージ 10 GiB が無料枠です。10 GiB を超えたストレージは $5 / GiB / 月で課金されます。

Vector Search 2.0 は ANN インデックスをサービングする場合に CU を時間単位で課金し (パフォーマンス最適化 CU で 1 CU 月 $46.8 ≒ 7,488 円)、ANN を使わずペイロードデータベースに対して KNN 検索を直接実行する場合は操作単位 ($0.06 / 100,000 読み取り) で課金します。低 QPS なら KNN の操作単位が割安、継続稼働の大規模インデックスなら ANN の CU 課金が安定する、という使い分けです。Agent Search の per-query は OCR・チャンク・ランキング・要約まで内包した価格である点が、Vector Search 2.0 の素の課金単価と直接比較しづらい要因です。

判断をまとめると次のようになります。Cloud Storage / Drive / BigQuery にあるドキュメントを最短で検索したい、かつ東京リージョン要件がない場合は Agent Search が素直な出発点です。

カスタム埋め込みや画像・動画などのマルチモーダル検索、ランカーのチューニング、東京リージョン必須の要件がある場合は Vector Search 2.0 を選びます。

Agent Search で立ち上げて、要件が深くなったタイミングで Vector Search 2.0 に移行するという経路も現実的です。両者ともに ScaNN ベースの低レイヤを共有しているため、検索品質の連続性は確保しやすい構成です。

プライマリ DB に同居させる選択肢 ── OLTP / OLAP / NoSQL の場合

ベクトル検索の置き場所は、検索特化サービスに限りません。プライマリデータが既に他の DB にある場合、そこにベクトル列を追加する構成が Google Cloud には揃っています。

OLTP 系の選択肢は 3 つあります。

AlloyDB pgvector + ScaNN は大規模 OLTP との同居に向いています。Google の公式ブログでは、ScaNN インデックスは HNSW と比較して検索速度が約 4 倍、メモリ使用量が 3〜4 分の 1 という計測値が示されています。

google_ml_integration 拡張を有効にすると、データ挿入時に自動で埋め込みを生成できます。

Cloud SQL for PostgreSQL (pgvector) は HNSW インデックスに対応しています (Vector Assist 経由で IVFFlat も利用可)。AlloyDB ほどのスケールは必要なく、OLTP データとベクトル検索を同居させたい中小規模のワークロードに向きます。なおチューニング支援機能の Vector Assist は 2026-05-05 時点でプレビュー提供かつ一時無効化中のため、本格利用は再開後に再評価が必要です。

Spanner ベクトル検索 (ANN) は GA 済みで、APPROX_COSINE_DISTANCE などの SQL 関数として利用できます。Enterprise / Enterprise Plus エディションのみで使用可能です。グローバル分散トランザクションにベクトル検索を同居させる必要がある場合の選択肢です。

OLAP 系では BigQuery VECTOR_SEARCH があります。GA 済みで、IVF インデックスと TreeAH インデックス (2026 年 4 月に GA) に対応しています。インデックス構築は一定の条件を満たす場合に無料です。バッチ処理や既存の分析クエリとの組み合わせで強みを発揮します。

NoSQL 系では Firestore ベクトル検索 が GA 済みです。find_nearest() で KNN 検索を実行でき、最大 2,048 次元に対応しています。埋め込みの生成は Vertex AI などの外部サービスで行う必要があります。Firebase エコシステムに乗ったモバイル・Web バックエンドで自然に組み合わせられます。

判断の基本は「プライマリデータが既にある DB → そこにベクトル列を追加するのが第一候補」です。新規に検索専用の構成を組む場合や、専用サービスのスケール・機能が必要な場合に Vector Search 2.0 か Agent Search の選択に戻ります。

東京リージョンで試算する ── ANN と KNN の月額コスト感

以下の試算は 2026-05-05 確認時点の公式料金ページに基づき、東京リージョン (asia-northeast1) で利用する前提、1 USD = 160 円換算で算出しています。

Vector Search 2.0: ANN インデックスをサービングする場合

ANN インデックスは Capacity Unit (CU) 時間単位で課金されます。CU 単価は全リージョン共通です。

  • パフォーマンス最適化 CU ($0.065/時間、2 GB RAM、小〜中規模向け): $0.065 × 24 × 30 = 約 $46.8 / 月 (約 7,488 円)
  • ストレージ最適化 CU ($2.30/時間、1 TB SSD 含む、大規模向け): $2.30 × 24 × 30 = 約 $1,656 / 月 (約 264,960 円)

加えてインデックスへのデータ書き込みは $0.45/GiB の従量課金です。レプリカ数を増やすと CU 数も比例して増えるため、SLA 要件に合わせた冗長構成を組む際は CU 数の見積もりが効いてきます。

Vector Search 2.0: ANN を作らず KNN を直接実行する場合

ペイロードデータベースに対して正確な K 近傍法で直接クエリを投げる場合の課金です。

  • 保存データ: $0.000410959 / GiB / 時間 (例: 10 GiB を 1 か月保持で約 $3 / 月 ≒ 480 円)
  • 読み取りオペレーション: $0.06 / 100,000 件 (検索クエリ + ドキュメント取得のオペレーション数)
  • 書き込み・更新・削除: $0.18 / 100,000 件

検索クエリ 1 回あたりの読み取り数は「インデックススキャンの費用 (100 オブジェクトごとに 1 回)」+「結果ドキュメント数」で算出されるため、データ規模が大きいほど 1 クエリあたりの操作数が増える点に注意が必要です。低 QPS で常時稼働の CU を持ちたくない構成に向きます。

Vector Search 1.0 (継続提供)

旧来の per-VM-node-hour SKU は GA 後も利用可能です。東京リージョンの e2-standard-2 は $0.1203/時間 で、1 ノード月額は 約 $87 (約 13,920 円)、SLA 99.9% に必要な minReplicaCount ≥ 2 の構成で 約 $174 (約 27,840 円) になります。インデックス構築 $3.00/GiB、ストリーミング更新 $0.45/GiB が別途加算されます。東京は us-central1 比 約 28% 高い単価設定ですが、Vector Search 2.0 の CU 単価は全リージョン共通のため、東京要件があるワークロードは 2.0 に移すことで地域差分を吸収できる場合もあります。

Agent Search

per-query 課金で、月 100 万クエリの想定では Standard $1.50 × 1,000 = $1,500 (約 240,000 円)、Enterprise $4.00 × 1,000 = $4,000 (約 640,000 円) です。インデックスストレージは 10 GiB まで無料枠、超過分は $5 / GiB / 月。毎月最初の 10,000 クエリは無料枠の範囲で立ち上げられます (高度な生成回答は除く)。なお Agent Search は asia-northeast1 に対応していないため、東京リージョンを要件とする構成では Vector Search 2.0 が実質的な選択肢になります。

2024 年 10 月 1 日以降に Vertex AI API を新規登録したアカウントには、Vector Search で使用できる $1,000 分の無料トライアルクレジットが 1 年間付与されます。パフォーマンス最適化 CU 1 基の構成 (月 $46.8) に当てはめると約 21 か月分の稼働費用に相当し、PoC や検証には十分な余裕があります。

GA 後の運用で意識しておきたい設計ポイント ── 次元数・Streaming Update・SLA

GA で機能と料金体系は安定しましたが、設計時に意識しておきたい運用上の注意点はいくつか残ります。

次元数の固定は見落としやすいポイントです。インデックス (1.0) またはコレクション (2.0) の作成後に埋め込みモデルを変更すると、次元数が変わった場合にインデックスの再構築が必要になります。

gemini-embedding-001 から text-embedding-005 へ切り替えると 3,072 次元から 768 次元への変更になるため、設計段階でモデルを固定しておくことが重要です。Auto-Embeddings を利用する場合はモデルのバージョンアップに伴う次元変更にも注意が必要です。

Streaming Update のコンパクションにも注意が必要です。リアルタイムに近い頻度でベクトルを追加・更新する用途を想定して使うと、5 日ごとに自動コンパクションが実行され、$0.45/GiB の費用が発生します。日次・週次など更新頻度が低いデータセットでは、バッチ更新の方がコスト効率が高くなる場合があります。

ストレージ最適化 CU を採用すると、書き込みユニット ($0.45/GiB) は同じですがコンパクションは CU 料金に内包される設計です。

SLA 99.9% に必要な minReplicaCount ≥ 2 の制約は、Vector Search 1.0 の per-VM-node-hour 構成や Vector Search 2.0 の CU プロビジョニングで本番運用する場合に効いてきます。1 ノード (1 CU) 構成の試算で SLA 対象になる前提で見積もりを進めると、本番直前で月額が倍になります。SLA を要件に含めるかどうかは、ワークロード設計の初期段階で確定しておくのが安全です。

東京リージョンの単価差は Vector Search 1.0 の per-VM-node-hour で約 28% 高くなります。Vector Search 2.0 の CU 単価は全リージョン共通のため、東京要件があるワークロードでは 2.0 への移行で地域差分を相殺できる構成も組めます。

まとめ ── build と all-in-one の使い分けと、同居型の引き出し

Vector Search 2.0 と Agent Search は階層関係にあるため「どちらが優れているか」ではなく「どこから自分で組み立てるか」で選び、プライマリデータが既にある DB ならそこに同居させる構成も第一候補に入ります。

判断の軸は次のとおりです。

  • 立ち上げ速度とコネクタ統合を優先し、東京リージョン要件がない場合 → Agent Search が出発点
  • カスタム埋め込み・マルチモーダル・ランカーチューニング・東京リージョンが必要な場合 → Vector Search 2.0
  • 大規模インデックスを継続稼働させたい場合は ANN (CU 課金)、低 QPS で索引を持ちたくない場合は KNN (操作単位課金) を選ぶ
  • プライマリ DB が AlloyDB / Cloud SQL / Spanner / BigQuery / Firestore にある場合 → 同居型 (ベクトル列を追加するのが第一候補)

次のアクションとしては、$1,000 の無料クレジットと Agent Search の月 1 万クエリ無料枠を使って両方を試してから決めるのが、無駄の少ない進め方です。Agent Search でコネクタ接続を確認し、Vector Search 2.0 で小さなコレクションを作って Auto-Embeddings の挙動を比べると、本番ワークロードの設計判断に必要な情報が揃います。

参考文献

Author
tgeas

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