TL

Cloud Service

Vertex AI Search

自社サイトやドキュメントに、Google 品質の検索と生成 AI による要約をすぐ組み込める。RAG の検索基盤を自前構築せず使える Vertex AI Search。AWS の Kendra / Bedrock Knowledge Bases に相当。

中級運用上の優秀性パフォーマンス効率セキュリティ
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.自社データを取り込み、Google 品質の検索と生成 AI 要約を備えた検索体験を構築できる。
  • 2.RAG のための検索・ベクトル化・根拠付けをマネージドで提供し、自前構築を省ける。
  • 3.AWS の Kendra（企業内検索）や Bedrock Knowledge Bases（RAG）に相当する位置づけ。

解決する課題

  • 自社サイトや社内ドキュメントの検索精度が低く、利用者が目的の情報にたどり着けない
  • RAG（検索拡張生成）のために、検索・ベクトル化・根拠付けの基盤を自前で構築する負担が大きい
  • 大量の PDF・HTML・データベースのレコードを横断して、自然文の質問に要約付きで答えたい
  • 商品カタログやメディアに対し、意味を捉えた検索やレコメンドを素早く導入したい
  • 生成 AI の回答に出典（引用）を付け、ハルシネーションを抑えた信頼できる回答を返したい

主要概念と用語

  • Vertex AI Search: 自社データを取り込み、Google 品質の検索と生成 AI による要約・回答を提供するマネージドサービス。RAG の検索基盤として使える。AWS の Kendra / Bedrock Knowledge Bases に相当する
  • Vertex AI Agent Builder: Vertex AI Search を含む、検索・会話エージェント・RAG を構築するための上位の枠組み。Search はその中核機能の一つ
  • データストア (Data Store): 検索対象データを取り込んで保持する入れ物。Web サイト・非構造化ドキュメント・構造化データなど、種類ごとに作成する
  • アプリ (App / Engine): データストアを束ね、検索や会話などのユースケースに対応した検索体験を提供する単位。フロントエンドはこのアプリの API を呼び出す
  • インデックス作成（インジェスト）: 取り込んだ文書を解析・チャンク分割し、検索可能な形にする処理。テキストと**埋め込み（ベクトル）**の両方を生成する
  • セマンティック検索 / ベクトル検索: キーワード一致だけでなく、意味の近さで関連文書を見つける検索方式
  • 生成的な要約・回答（要約 / 回答生成）: 検索でヒットした文書を根拠に、生成 AI が自然文の回答と引用を返す機能。RAG の出力にあたる
  • グラウンディング（根拠付け）: 生成結果を取り込んだ自社データに根拠付けし、出典を示してハルシネーションを抑える仕組み
  • コネクタ (Connector): BigQuery・Cloud Storage・サードパーティの SaaS などからデータを取り込む接続口
  • 業種別エディション: 一般用途のほか、小売（検索・レコメンド）やメディア向けなど、ユースケースに特化した構成が用意される

仕様・制限・クォータ

  • 取り込めるデータは大きく Web サイト・非構造化（PDF・HTML・テキストなど）・構造化（BigQuery やレコード） に分かれ、種類ごとにデータストアを作る
  • データの取り込みは Cloud Storage・BigQuery・各種コネクタ経由が一般的。更新は手動再取り込みや定期同期で反映する
  • 1 つのアプリに紐づけられるデータストア数や、取り込めるドキュメント数・サイズには上限がある。具体値は変動するため公式ドキュメントとコンソールのクォータ画面で確認する
  • 生成 AI による要約・回答には入力に使える文書数やトークンの上限があり、プロジェクト単位のリクエスト/分などのレート制限がかかる。これらは定性的に「上限がある」と捉える
  • 対応リージョン・対応言語・利用できる業種別機能はサービス更新で増減するため、最新は公式情報を参照する
データの所在地と更新反映

データストアのロケーション（マルチリージョンやリージョン）は作成時に決まり、後から変えにくい点に注意してください。データ所在地の要件は最初に確認します。また、元データを更新しても検索結果へ反映されるには再取り込みや同期が必要なため、鮮度要件に合わせて更新の頻度を設計してください。

内部の仕組み

Vertex AI Search はまず、取り込んだ文書を解析してチャンク（小さな単位）に分割し、各チャンクに対してテキストインデックスと**埋め込み（ベクトル）を生成します。検索時には、キーワード一致による検索と、意味の近さで関連を測るセマンティック検索（ベクトル検索）**を組み合わせ、関連度の高い文書を取り出します。

生成 AI の要約・回答を有効にすると、検索でヒットした文書を根拠（コンテキスト）として基盤モデルに渡し、自然文の回答と引用（出典）を生成します。これが RAG（検索拡張生成）の流れで、回答は取り込んだ自社データにグラウンディングされるため、モデル単体よりハルシネーションを抑えられます。検索・ベクトル化・根拠付けの各段階を Google がマネージドで提供するため、利用者はこれらの基盤を自前で構築・運用する必要がありません。

まず検索品質、次に生成

最初から生成回答を作り込むより、検索（リトリーバル）の関連度を整えるのが近道です。取り込み対象の絞り込みやメタデータ付与で検索品質を上げると、後段の生成要約の質も安定します。

設計パターン / ベストプラクティス

  • 取り込み = Cloud Storage / BigQuery、検索 = Vertex AI Search、UI = 自社フロントの三段構成が基本。フロントはアプリの検索 API を呼び出す
  • 更新をイベント駆動にする。元データの追加を Eventarc / Cloud Functions で受け、再取り込みや同期を起動して鮮度を保つ
  • **メタデータで絞り込み（フィルタ）**を設計する。部署・公開範囲・言語などの属性を付与し、検索時にスコープを限定する
  • 回答には必ず引用を出す。生成要約をそのまま見せず、出典リンクを併記して利用者が検証できるようにする
  • アクセス制御は取り込み時点から考える。閲覧してよいユーザーだけに結果が返るよう、データの分離やフィルタ設計を初期から組み込む
  • RAG を自作する前に評価する。Vertex AI Search で要件を満たせるなら、ベクトル DB やチャンク処理の自前実装を避けて運用負荷を下げる

運用・監視

  • Cloud Monitoring / Cloud Logging で検索 API のリクエスト数・レイテンシ・エラー率を監視する
  • 検索品質を継続的に評価する。代表的な質問セットでヒット率や上位結果の妥当性を確認し、取り込み設定やメタデータを改善する
  • 元データの更新が検索に反映されているかを、再取り込み・同期のジョブ結果で確認する。失敗分は再実行する
  • 生成要約を使う場合は引用の妥当性や不適切回答をサンプリングで点検し、必要に応じて対象データやプロンプトを調整する
  • レート制限への到達状況を監視し、必要に応じてクォータ増枠やリトライ設計を行う

コスト

  • 課金は主に取り込んだデータ量（インデックスの保持）と検索/回答のクエリ数に応じる。生成 AI 要約を使うと、その分の処理コストが上乗せされる
  • 不要なドキュメントまで取り込まず、検索対象を必要な範囲に絞るとインデックス保持コストを抑えられる
  • 生成要約を全クエリで使わず、必要な画面・用途に限定するとクエリあたりのコストを下げられる
  • 業種別エディションや機能の有無で単価が変わるため、見積もりは公式の料金ページで確認する。具体的な単価は変動する
機微データの取り込みに注意

社内ドキュメントには個人情報や機密情報が含まれます。誰でも検索できるアプリに無制限に取り込むと、本来見せてはいけない情報が要約・引用として露出する恐れがあります。取り込み対象の選定とアクセス制御を取り込み前に設計してください。

セキュリティ

  • IAM でデータストア・アプリ・検索 API へのアクセスを最小権限に分離する（AWS の IAM ロール相当）
  • ワークロードにはサービスアカウントを割り当て、認証情報のハードコードを避ける
  • 検索結果のアクセス制御を設計し、ユーザーの閲覧権限に応じて返す結果を絞る。全員に全データを返さない
  • 保存データは Google 管理鍵で既定暗号化され、要件に応じて CMEK（顧客管理鍵、Cloud KMS） を適用できる
  • VPC Service Controls でデータ境界を作り、取り込みデータや検索結果の外部流出を防ぐ

関連サービス・比較

関連として、汎用の AI 基盤である Vertex AI と比較します。Vertex AI Search は「検索と RAG をマネージドで提供する完成品」、Vertex AI は「モデルの学習・配信・生成 AI 全般を扱う基盤」という位置づけの違いがあります。

観点Vertex AI SearchVertex AI（汎用基盤）
主な役割検索と RAG の完成サービスML 学習・配信・生成 AI の基盤
RAG 構築取り込みと検索を内包部品を組み合わせて自作
検索・ベクトル化マネージドで自動自前で設計・実装
導入の速さ速い（データ取り込みで開始）柔軟だが構築が必要
AWS の相当Kendra / Bedrock Knowledge BasesSageMaker / Bedrock

ハンズオン / CLI例

# 1) Discovery Engine（Vertex AI Search）API を有効化
gcloud services enable discoveryengine.googleapis.com

# 2) 非構造化ドキュメント用のデータストアを作成
#    （Cloud Storage 上の PDF などを取り込む想定）
gcloud alpha discovery-engine data-stores create my-datastore \
  --location=global \
  --industry-vertical=GENERIC \
  --solution-type=SOLUTION_TYPE_SEARCH \
  --content-config=CONTENT_REQUIRED

# 3) 作成済みのデータストアを一覧で確認
gcloud alpha discovery-engine data-stores list --location=global

# 4) REST API で検索を実行（簡易例）
#    DATA_STORE_ID は手順 2 で作成したデータストアの ID
curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://discoveryengine.googleapis.com/v1/projects/MY_PROJECT/locations/global/collections/default_collection/dataStores/DATA_STORE_ID/servingConfigs/default_search:search" \
  -d '{"query":"返品ポリシーは","pageSize":5}'

Google Cloud Service

Vertex AI Searchを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

AI / 機械学習

比較で見る軸

クラウド: Google Cloud / カテゴリ: AI / 機械学習 / 難易度: intermediate

導入後に効く点

RAG のための検索・ベクトル化・根拠付けをマネージドで提供し、自前構築を省ける。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
AI / 機械学習
難易度
intermediate
関連資格
—
設計柱
operational / performance / security

判断チェックリスト

  • 自社の用途が「AI / 機械学習 / operational」に近いか確認する。
  • 強みである「自社データを取り込み、Google 品質の検索と生成 AI 要約を備えた検索体験を構築できる。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

AI / 機械学習operationalperformancesecurity
参考: 公式ドキュメント