Vertex_AI_Searchを使いこなす実践テクニック

Google Cloud Community Tech Surge 2026 presented by Jagu'e'r
https://2026.gcts.jp/ にて発表をさせていただいた資料になります

Transcript

1. Vertex AI Searchを使いこなす実践テクニック Google Cloud Community Tech Surge 2026 presented by Jagu'e'r 株式会社スリーシェイク Sreake事業部 ソリューション4部 佐藤慧太 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 佐藤 慧太@SatohJohn • 2023/1 株式会社スリーシェイク入社 • Google Cloud Partner Top Engineer ’24、’25、’26 選出 • お客様の労苦 <Toil>を減らす • 娘のお世話を精一杯やっています • AI 周りだけじゃなくアプリケーション モダナイゼーションもやります
3. 会社紹介 3 会社名 株式会社スリーシェイク 設立日 2015/1/15 Mission: インフラをシンプルにして イノベーションが起こりやすい世界を作る Vision: 労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける 2015 2016 2017 2018 2019 2020 2021 2022 0 50 100 従業員: 200名over Engineer 60% 所在地 東京都中央区銀座8丁目21番1号 住友不動産汐留浜離宮ビル7F　 代表者 代表取締役社長　吉田 拓真 Google Cloud×SRE / GenAIにおいて、スリーシェイクは国内トップパートナー Googleクラウド・AWSの両方のエンジニアリングに強みを持つ （2024年8月に国内2例目の、GoogleCloudのDevOpsスペシャライゼーションを取得） 日本のSREをリードする インフラ・アプリ・データ・セキュリティ・AI 全方位で顧客の内製化を推進する伴走支援 あらゆるサービスを 連携するハブになる 「いいエンジニア」を あなたのチームに 事業者が抱える セキュリティリスクをゼロに あらゆるSaaSをノーコードで連携する クラウド型ETL/データパイプラインSaaS セキュリティ対策をワンストップで 実現する脆弱性診断SaaS ハイスキル人材の紹介とHR戦略支援の両輪で エンジニア組織の課題に併走 会社・事業部説明資料（SpeakerDeck）
4. 弊社の Vertex AI Search を使った例 https://sreake.com/case/nttpc/ https://sreake.com/case/hikarisystem/ 【株式会社ヒカリシステム様】 接客教育を変革する、リアルタイム音声対応 AI サービス開発とハンズオン支援による内製化を実現 【NTTPCコミュニケーションズ株式会社様】 社内情報検索の課題を解決し、 イノベーションを加速する全社検索サービスを構築
5. ターゲットオーディエンス • 社内検索基盤のアーキテクチャを考えているエンジニア • RAG における回答品質の向上に悩んでいるエンジニア • 検索基盤の ROI を最大化したいマネジメント層
6. 本セッションのゴール • 検索基盤として Vertex AI Search(VAIS) への移行判断基準を得る • メタデータとパイプラインの具体的な実装イメージを持つ • VAIS における評価駆動開発(EDD)による品質改善の手法を理解する
7. 話さないこと • ベクトル DB の仕組みなどの基本的な技術部分 • VAIS のカスタム検索以外 ◦ Web search、メディア向け、Recommendation、医療 • Static な API ◦ Check Grounding、Ranking API • 金額 ◦ サブスク、従量課金の違い
8. 「AIの幻滅期」について考える 1. 想定した回答が返ってこない a. 簡単に使えるツールを試すが、検索品質が低く使い物にならない RAG においても同様 2. システムの構成が複雑で運用が難しく ROI を超えない a. ベクトル DB の運用、スケーリング、コスト管理 b. Embedding モデルの選定と再インデックスの無限ループ c. チャンク分割の試行錯誤（セマンティック・チャンキングの難しさ）
9. RAG における課題の殆どが「検索ができていない」 1. データの質が悪い、LLM に組み込みたいデータ以外が多すぎる 2. データがどういう構成かを把握できていない、画像や表を読み込めない 3. 参照させたい部分が引っ張ってこれない、意味検索では検索しにくい 4. 似通った単語や社内用語があり、そのユースケースに対応できていない など
10. RAG における課題の殆どが「検索ができていない」 1. データの質が悪い、LLM に組み込みたいデータ以外が多すぎる 2. データがどういう構成かを把握できていない、画像や表を読み込めない 3. 参照させたい部分が引っ張ってこれない、意味検索では検索しにくい 4. 似通った単語や社内用語があり、そのユースケースに対応できていない など 正確に検索できるシステムが必要
11. RAG における課題の殆どが「検索ができていない」 1. データの質が悪い、LLM に組み込みたいデータ以外が多すぎる → Pipeline を構成して省く 2. データがどういう構成かを把握できていない、画像や表を読み込めない → どういうデータかを確認、Parser の設定見直し 3. 参照させたい部分が引っ張ってこれない、意味検索では検索しにくい → メタデータのチューニング 4. 似通った単語や社内用語があり、そのユースケースに対応できていない → 検索チューニングや同義語の登録
12. 「検索ができていない」に対する Google Cloud のサービス Vertex AI Search
13. Vertex AI Search とは 01 Copyright © 3-shake, Inc. All Rights Reserved.
14. Vertex AI Search 概要 1. 検索システムに特化したマネージドなサービス a. ファイルを入れるだけで簡単に構築ができる b. KeyWord 検索、セマンティック検索を同時に実施する c. VAIS の JaveScript を埋め込むことで、簡単に UI を構築でき利用可能 2. Gemini Enterprise でも同じデータソースを利用できる 3. Engine と Data Store で 1 : 多 (ブレンド検索) a. 1:1 のパターンのほうができることが多い b. ブレンド検索は一度設定すると変えられない
15. Vertex AI Search 概略図 https://docs.cloud.google.com/generative-ai-app-builder/images/generic-search-overview.svg?hl=ja
16. Data Store の種類と選択基準 自由にカスタムでパイプラインを作りたい チューニングを深くやりたい 1. GCS 非構造化データでACLつき 2. BigQuery 構造化データでACLつき テーブル管理できるのが強み 3. Cloud SQL や Firestore 構造化データですでにデータが有る
17. Data Store の種類と選択基準 Google Cloud が作ったパイプラインを使いたい 閲覧権限周りの制御も自動で行ってほしい 4. 3rd party Ingestion 内部にデータを貯めて、検索品質を上げたい 5. 3rd party Federation 検索品質はおいて、検索をしたい
18. 他の Google Cloud でのサービスとの違い 1. Vector Search a. VAIS のベースの機能になっている b. めっちゃチューニングしたい場合に使う 2. Gemini Enterprise a. VAIS の機能をベースとした SaaS により近いサービス b. チューニングはそんなできない 3. RAG Engine a. Spanner をベースとした RAG 用のサービス https://zenn.dev/google_cloud_jp/articles/vector-search-2-0-intro Vector Search 2.0 はさわれていません ☹
19. 構築の進め方 https://docs.cloud.google.com/generative-ai-app-builder/docs/generic-search-checklist?hl=ja
20. Vertex AI Search Deep Dive 02 Copyright © 3-shake, Inc. All Rights Reserved.
21. Topics • Parser、チャンキング • メタデータ • コントロール(フィルタ、ブースト、同義語) • 閲覧権限(Access Control) • ユーザイベントの記録
22. Topics • Parser、チャンキング • メタデータ • コントロール(フィルタ、ブースト、同義語) • 閲覧権限(Access Control) • ユーザイベントの記録
23. Parser の違い 料金
 利用できる File Type 
 注意事項
 Digital parser 
 かからない 
 html,pdf(デジタルテキス ト),docx,pptx,txt,xlsx,xlsm 
 表、リスト、見出しなどのドキュメント要素は読まない 
 Layout parser 
 Document AI の値 段
 html,pdf(デジタルテキスト),docx,pptx,xlsx,xlsm 
 段落、表、リストなどを検出する 
 OCR parser 
 Document AI の値 段
 画像を含んでいるPDFやスキャンしたPDFに利 用
 1ファイル500ページまで 

24. おすすめの Parser File Type 
 パーサ
 理由
 PDF
 Layout Parser
 (Image,Table, Gemini Annotation)
 OCR の手もあるが、画像データ以外に構造化したいデジタルデータが入ってい る場合もあるため
 手書きのファイルというのがわかっている場合は OCR で良い
 TXT
 Digital Parser
 他のパーサーがうまく利用できないため、Digital Parser を使う
 マークダウンに関しては前もって html などの構造にしておき、Layout Parserに 任せるような形で構造化するなどのパイプライン
 ソレ以外
 Layout Parser
 基本的には段落などを検出するほうが良い検索結果になりやすい
 https://docs.cloud.google.com/generative-ai-app-builder/docs/parse-chunk-documents#bring-chunks ※自作 Parser は Private Preview で利用可能
25. Parser のチャンク結果を見る 1. どうチャンクされたかを確認して、データの構成を見直す a. ドキュメントの高度なチャンク構成が有効になっていないとエラーになる i. 一度、設定し忘れると作り直しが必要 ii. ただし、RAG に向いたチャンク取得の構成になり、ファイル検索には 若干向いていない構成になるので注意 curl -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://discoveryengine.googleapis.com/v1alpha/projects/$PROJECT_ID/locations/global/co llections/default_collection/dataStores/$DATA_STORE_ID/branches/0/documents/$DOCUMENT_ID /chunks"
26. Topics • Parser、チャンキング • メタデータ • コントロール(フィルタ、ブースト、同義語) • 閲覧権限(Access Control) • ユーザイベントの記録
27. メタデータ構築：なぜ必要か？ 1. 本文に入っていないワードやドキュメントの更新日などの時間等 a. フィルタ b. ブースト、ベリー 2. UI 補助 a. API レスポンス b. AutoComplete https://docs.cloud.google.com/generative-ai-app-builder/docs/configure-field-settings
28. メタデータスキーマの具体例 種類
 つけられる型 
 用途
 制約
 Indexable(インデック ス)
 string, integer, number, datetime 
 フィルタ、boost で利用される 
 種類、データが多すぎると登録や追加に時間 がかかる様になる 
 Searchable 
 string 
 全文検索として利用される 
 フィールドが多すぎると検索精度に影響を与え る(無関係な結果が返りやすくなる) 
 Retrievable 
 すべて
 レスポンスに含めることで、VAIS の UI 表 示のカスタマイズに使う 
 フィールドが多すぎるとレスポンスのサイズが 多いのでレスポンスが遅くなる 
 Completable 
 string 
 AutoComplete を実装する際に利用する 
 検索結果には影響がない 
 Dynamic facetable 
 (Indexable にチェックがつ いている)string 
 VAIS の UI 上で、検索時に使われる 
 検索結果には影響がない 
 
 ※AutoComplete は Document などにも対応しています
29. Topics • Parser、チャンキング • メタデータ • コントロール(フィルタ、ブースト、同義語) • 閲覧権限(Access Control) • ユーザイベントの記録
30. 検索を制御する「フィルタ」と「ブースト」 1. 条件によって件数を絞る = フィルタ a. 10000件から100件を抽出する 2. 条件によって並び替えを行う = ブースト、ベリー a. 10000件を条件順に並べる
31. 検索を制御する「フィルタ」 検索時にフィルタ構文を書いてメタデータでフィルタする https://docs.cloud.google.com/generative-ai-app-builder/docs/filter-search-metadata?hl=ja フィルタ構文 category: ANY("persona_A") テキスト フィールド category が persona_A である score: IN(*, 100.0e) 数値フィールド score が負の無限大より大きく 100.0 より小さい non-smoking = "true" ブール値 non-smoking が true である manufactured_date >= "2024-04-16" manufactured_date が 2024 年 4 月 16 日以降である
32. 検索を制御する「フィルタ」 1. 検索時にドキュメントの関連度フィルタを指定する a. キーワード検索に基づいて b. 埋め込みのキーワードに基づいて https://docs.cloud.google.com/generative-ai-app-builder/docs/filter-by-relevance#about-filter-relevance "relevanceFilterSpec": { "keywordSearchThreshold": { "relevanceThreshold": "LOW" }, "semanticSearchThreshold": { "semanticRelevanceThreshold": 0.871 } }
33. 検索を制御する「ブースト」 1. 検索時にドキュメントの関連度フィルタを指定する a. フィルタに似た形でメタデータに対して設定する b. どのぐらいブーストする、またはベリーするかを決める = -1.0~1.0 https://docs.cloud.google.com/generative-ai-app-builder/docs/boost-search-results https://docs.cloud.google.com/generative-ai-app-builder/docs/custom-ranking { "boostSpec": { "conditionBoostSpecs": { "condition": "star_rating>=3.0", "boost": 0.7 } } }
34. 自然言語でのフィルタの実装 https://docs.cloud.google.com/generative-ai-app-builder/docs/natural-language-queries 1. ユーザのクエリから自動でフィルタと検索文章を組み立てる 2. Data Store に対して設定する。24時間後に反映 3. 検索時にフィルター(hard)かブースト(soft)にするかを決める "naturalLanguageQueryUnderstandingConfig": { "mode": "ENABLED" } "naturalLanguageQueryUnderstandingSpec": { "filterExtractionCondition": "ENABLED", "extractedFilterBehavior": "SOFT_BOOST" }
35. 自然言語でのフィルタの実装 https://docs.cloud.google.com/generative-ai-app-builder/docs/natural-language-queries 1. メタデータのフィールドを参照して勝手に組み立てる a. 検索文字が同じでも若干変わることがあるので、評価観点で扱いが少し難しい b. 自分で組み立てを考える必要がないので、単純なパターンで検索品質は上がる 2. できないこと a. 構造化 Data Store でしか使えない b. ブレンドモードでは使えない
36. 同義語登録 1. 特定の社内用語を認識させる a. たとえば 「ランニング シューズ」の検索結果に 「スポーツ シューズ」も表示したいに利用 b. Engine に登録をする c. 同義語として、特定の意味のものと紐づける d. 検索結果に含まれやすくなる
37. 検索のチューニング 1. ユースケース a. 社内用語などを新しく覚えさせる b. 検索結果の傾向を変更したい、特定の用語、文脈で引っかけたい 2. チューニングに必要なもの a. 非構造化での Data Store にて実施 b. クエリファイル: クエリリスト、最低100個 c. コーパスファイル: スニペットリスト、クエリごとに最低1個 d. スコア: 0~10の評価値 e. トレーニングラベルファイルでスコアとともに紐づける https://docs.cloud.google.com/generative-ai-app-builder/docs/tune-search
38. 検索のチューニング 1. 料金は”おそらく” Recommendation と同じく1ノードの時間単位 a. ドキュメントに記載がないので確かではない 2. チューニングしたモデルに対してテストデータでの NDCG での 評価値を見ることができる a. 本データでの評価は Evaluation の機能を利用する 3. 個人的見解 a. 数日かかることもザラにある b. コストがかかり、データを作るのも大変なため、同義語でできないかを考える https://colab.research.google.com/github/GoogleCloudPlatform/generative-ai/blob/main/search/tuning/ vertexai-search-tuning.ipynb?hl=ja
39. Topics • Parser、チャンキング • メタデータ • コントロール(フィルタ、ブースト、同義語) • 閲覧権限(Access Control) • ユーザイベントの記録
40. 閲覧権限の実装 1. Google Identity or Workforce Identity による閲覧権限 a. AutoComplete 時にも advanced を利用することで ACL を考慮できる https://docs.cloud.google.com/generative-ai-app-builder/docs/data-source-access-control?hl=ja https://speakerdeck.com/satohjohn/srett-13 { "id": "id", "structData": "<JSON string>", "content": { "mimeType": "<application/pdf or text/html>", "uri": "gs://<your-gcs-bucket>/directory/filename.pdf" }, "acl_info": { "readers": [ { "principals": [ { "group_id": "group_1" },{ "user_id": "user_1" } ] } ] } }
41. Topics • Parser、チャンキング • メタデータ • コントロール(フィルタ、ブースト、同義語) • 閲覧権限(Access Control) • ユーザイベントの記録
42. ユーザイベントの記録 1. ユースケース a. 記録されたデータを使い、ユーザごとに検索結果がチューニングされる b. 利用状況を VAIS 上で確認することができる 2. userPseudoIdとuser_idにユーザを識別するIDを入れる a. IDは匿名化して入力をする https://docs.cloud.google.com/generative-ai-app-builder/docs/record-user-events?hl=ja request = discoveryengine.WriteUserEventRequest( user_event=discoveryengine.UserEvent( event_type=event_name, attribution_token=attribution_token, user_pseudo_id=visitor_id, user_id=user_id, data_store=client.data_store_path(PROJECT_ID, LOCATION, DATASTORE_ID), session_id=session_id, ), )
43. ユーザイベントから分析できる指標 https://docs.cloud.google.com/generative-ai-app-builder/docs/view-analytics?hl=ja 指標名 指標の定義 注 検索回数 検索イベントの数 検索ログに基づく。 結果なし率 結果のない検索イベント数 ÷ 検索回数 検索ログに基づきます。 検索あたりのクリッ ク率（CTR） 検索クリック数 ÷ 検索回数 検索クリックは、前の検索イベントに起因するアイテム表示イベントです。ユーザー イベントに基づく。 フィードバックの高評 価と低評価の数 高評価と低評価の数 アプリのユーザーから送信された高評価/低評価のフィードバック レスポンスの記録。 フィードバックの低評 価の理由の内訳 低評価の理由の割合 生成された回答にユーザーが低評価を付けた場合は、低評価の理由を複数選択できます。パーセン テージは、各理由が選択された頻度を示します。
44. ユーザイベントから分析できる指標 https://docs.cloud.google.com/generative-ai-app-builder/docs/view-analytics?hl=ja 指標名 指標の定義 注 検索セッション数 検索セッションの数 検索セッションとは、少なくとも 1 つの検索イベントを含むユーザー セッションです。ユーザー セッショ ン（訪問とも呼ばれます）は、ユーザー イベントの連続したセットです。30 分間操作がないと、セッショ ンは終了します。検索ログに基づく。 検索アクセスあたり のページビュー 検索セッションでのアイテ ム表示イベントの数 ÷ 検 索セッション数 この指標には、Vertex AI Search に起因するものかどうかにかかわらず、検索アクセスのすべての ページビューが含まれます。ユーザー イベントに基づく。 直帰率 検索セッションでの直帰数 ÷ 検索セッション数 検索セッションの直帰とは、1 回の検索によるセッションとして定義されます。ここでユーザーは 1 回 の検索を行った後に離れます。ユーザー イベントに基づく。
45. ユーザイベントから分析できる指標 https://docs.cloud.google.com/generative-ai-app-builder/docs/view-analytics?hl=ja
46. パイプライン作成 03 Copyright © 3-shake, Inc. All Rights Reserved.
47. パイプラインの目的 1. Parser にとって読みやすいデータを作る、整形する 2. メタデータを組み立てる 3. 上げてはいけないデータがないかをチェックする 4. ドキュメントに対する ACL 用のデータを作成する
48. パイプラインでやる処理例 Markdown to PDF or HTML Notion からデータを取ってくるパイプライン実装 Markdown だと Digital Parser を使うことになるので HTML にして構造化 const n2m = new NotionToMarkdown({ notionClient: _notionClient, config: { convertImagesToBase64: true, parseChildPages: true } }) const mdBody = await n2m.blocksToMarkdown(response.results) const data = n2m.toMarkdownString(mdBody) const html = marked.parse(data);
49. パイプラインでやる処理例 動画検索分析 動画自体は VAIS で検索できないのでメタデータなどを抜き出し AI Agent に投げて メタデータを抽出 class Clazz(typing.TypedDict): time: str transcript: list[str] root_agent = Agent( name="xxxxx", model="gemini-2.5-flash", instruction=""" """, generate_content_config=types.GenerateContentConfig( response_schema=Clazz, ) )
50. セキュリティチェック 1. Security Command Center(Data Loss Prevention) + PubSub a. ドキュメントに見えてはいけないものがあった場合に検知、防御する i. お客様情報(電話番号、住所)、token など b. タイミング i. なるべくコストを減らすため、パイプラインを走らせる前に検査 ii. 検査に引っかかった場合に秘匿するか、そのまま破棄するかを決定 https://docs.cloud.google.com/sensitive-data-protection/docs/concepts-actions?hl=ja
51. セキュリティチェック もう少し詳しい話は 以前の私の資料を見ていただければ https://speakerdeck.com/satohjohn/srett-13
52. 評価 04 Copyright © 3-shake, Inc. All Rights Reserved.
53. EDD 評価駆動 https://eugeneyan.com/writing/eval-process/ https://sreake.com/blog/evaluation-driven-development-with-adk/
54. EDD 評価駆動 RAG システムの場合 1. きちんと検索結果として返ってくるか a. 検索システム (VAIS) のチューニング 2. AI が読み取って正しく回答するか a. プロンプトのチューニングなど https://docs.cloud.google.com/generative-ai-app-builder/docs/evaluate-search-quality
55. VAIS の評価 • 検索エンジンのパフォーマンスを総合的に評価する • クエリレベルでパターンを特定し、ランキングアルゴリズムの潜在的な バイアスや欠陥を理解する • 過去の評価結果を比較して、検索設定の変更による影響を理解する https://docs.cloud.google.com/generative-ai-app-builder/docs/evaluate-search-quality チューニングにおける結果の評価を客観的、自動的に実施する
56. EDD 評価駆動 VAIS の評価の流れ 1. 評価データを作成する 2. 評価データを VAIS に取り込む 3. 評価を実施する 4. 評価結果の値を見て傾向を把握する 5. 設定を修正(フィルタ、ブーストなど)して、再度3から評価を回す
57. VAIS の評価観点
58. Gemini Enterprise 05 Copyright © 3-shake, Inc. All Rights Reserved.
59. Gemini Enterprise 1. GCS などの Data Store は今までの説明通りのチューニングができる a. ただし 3rd Party などのコネクタのものは、パイプラインに ついてブラックボックスとなっているため、制御ができない b. 更に Federation Connector になれば API 通信なので余計に何もできない 2. できるのは以下の変更だけ a. ブーストやフィルタの値 b. スキーマの設定値
60. Gemini Enterprise
61. Gemini Enterprise 1. 検索品質評価は VAIS と同じ評価方法を使うことができる 2. AI Agent の結果は返却される結果などを最終結果として評価する a. Gen AI evaluation service API https://docs.cloud.google.com/gemini/enterprise/docs/evaluate-search-quality https://docs.cloud.google.com/vertex-ai/generative-ai/docs/model-reference/evaluation?hl=ja#syntax 指標名 (一部掲載) 評価内容 exact_match_input 予測が参照と完全に一致しているかどうかを評価する bleu_input 予測と参照を比較して BLEU スコアを算出する rouge_input 予測と参照を比較して rouge スコアを計算する
62. まとめ 06 Copyright © 3-shake, Inc. All Rights Reserved.
63. まとめ 1. 検索基盤として Vertex AI Search(VAIS) への移行判断基準を得る → DeepDive によるチューニング方法、運用方法の説明 2. メタデータとパイプラインの具体的な実装イメージを持つ → パイプラインの紹介とセキュリティのチェックの簡単な紹介 3. VAIS における評価駆動開発(EDD) による品質改善の手法を理解する → 流れと評価観点について説明
64. まとめ Have a great time with Vertex AI Search!
65. fin Copyright © 3-shake, Inc. All Rights Reserved.