生成AIを活用したプロジェクトにおいて、プロジェクトマネージャーやエンジニアが最も頭を悩ませる課題の一つ。それが「LLMの知ったかぶり」、専門用語で言うところのハルシネーション（幻覚）です。
「競合他社の最新の価格プランを教えて」
ユーザーがそう尋ねたとき、LLMが自信満々に2年前の情報を回答したり、存在しないプランを捏造したりしてしまったら、そのアプリケーションの信頼は一瞬で地に落ちます。これを防ぐために、社内ドキュメントを検索させるRAG（Retrieval-Augmented Generation）を構築することが一般的です。しかし、社内ドキュメントRAGだけでは解決できない領域があります。それが「Web上の最新情報」です。
ここで登場するのが、Vertex AI Searchを用いたGoogle検索グラウンディングです。
今回は、単にGoogle検索をLLMに繋ぐだけでなく、いかにして「コストを抑えつつ」「正確性を担保し」「ユーザーに根拠を示すか」という、実運用を見据えた設計論について解説します。コードの書き方以上に重要な「設計の勘所」を共有できればと思います。
なぜLLMには「Google検索」が必要なのか：グラウンディングの理論と必然性
AIプロジェクトを推進する際、ステークホルダーから「最新のAIを使えば、何でも答えられるのではないか？」と問われることは少なくありません。しかし、LLM単体での運用には明確な限界があります。また、社内ドキュメントを活用するRAG（検索拡張生成）だけでも、ビジネスのあらゆる要求に応えることは困難です。
ここでは、なぜ外部のWeb検索を用いたグラウンディング（根拠付け）が不可欠なのか、その理論的背景とビジネスにおける必然性を整理します。
知識のカットオフ問題とパラメトリックメモリの限界
LLMは膨大なテキストデータで学習されていますが、その知識は学習が完了した時点で凍結されます。これを「知識のカットオフ」と呼びます。
OpenAIの公式ブログ（2026年2月時点）によると、ChatGPTでは旧モデルからより推論能力や自己批評能力の高い最新モデルへの移行が進められています。しかし、モデルの性能がいかに向上しようとも、学習データに含まれていない「昨日のニュース」や「今朝発表されたプレスリリース」について正確に答えることはできません。
LLMの内部知識（パラメトリックメモリ）は、あくまで「過去の圧縮された記憶」です。これに対し、ビジネスの現場では常に「現在」の情報が求められます。株価、天気、製品の在庫状況、最新の法改正など、時々刻々と変化する事象を扱うには、外部知識（ノンパラメトリックメモリ）へのリアルタイムなアクセスが不可欠と言えます。
RAGの進化系としての「Web検索グラウンディング」
この「知識の鮮度」という課題に対し、外部データベースから関連情報を取得してLLMに渡す技術がRAGです。多くの企業では、社内Wikiやマニュアルをベクトルデータベース化し、RAGを構築しています。これは「社内の閉じられた知識」を活用するには非常に有効な手段です。
最近の業界動向として、RAG技術は単なる文書検索から、ハイブリッド検索（ベクトル検索とキーワード検索の組み合わせ）や、AI自身が検索の必要性を判断するエージェント型RAG（Agentic RAG）へと進化しています。
しかし、マーケティング調査や競合分析、一般的なカスタマーサポートにおいては、社内情報だけでは不十分です。「世の中の事実」に基づいた回答が求められる場面では、RAGの検索ソースとして「Google検索」のような広範なWeb情報を利用する必要があります。
これをグラウンディング（Grounding：根拠付け）と呼びます。LLMの回答を、モデルが作り出す「幻覚（ハルシネーション）」ではなく、確固たる「検索結果」という地面（Ground）に繋ぎ止めるアプローチです。
企業利用における「事実性（Factuality）」の担保
企業が提供するAIサービスにおいて、「事実性」は品質そのものです。もっともらしい「面白い回答」よりも、裏付けのある「正確な回答」が優先されなければなりません。
Web検索を用いたグラウンディングを導入することで、以下の3つの価値が期待できます。
- 鮮度の確保: クローリングシステムを自社で構築・運用することなく、検索エンジンがインデックスしている最新情報に直接アクセスできます。
- ハルシネーションの抑制: 「過去に学習した不確かな記憶」ではなく、取得した「最新の検索結果」に基づいて回答を生成するようAIに強制できます。
- 出典の明記: 「どの情報源に基づいているのか」をユーザーに提示できるため、情報の検証が可能になります。
特に3つ目の「出典の明記」は、AIに対するユーザーの不信感を払拭し、実業務での利用を促進するために極めて重要です。
Vertex AI SearchにおけるGoogle検索連携のアーキテクチャ
では、具体的にVertex AI SearchはどのようにしてGoogle検索の結果をLLMに取り込んでいるのでしょうか。ブラックボックスになりがちなこの処理を、アーキテクチャの視点で紐解いてみましょう。
Grounding with Google Searchの仕組み
Vertex AIにおけるグラウンディングは、単に検索APIを叩いているだけではありません。ユーザーの入力を理解し、最適な検索クエリを生成し、得られた結果をLLMが理解しやすい形に整形するという一連のパイプラインが自動化されています。
通常、自前で実装しようとすると、以下の手順が必要になります。
- ユーザーの質問を受け取る（例：「Pixel 8の発売日は？」）
- LLMを使って検索クエリを生成する（例：「Google Pixel 8 発売日 日本」）
- Google Custom Search JSON APIなどを叩く
- 返ってきた検索結果（スニペット）をテキスト化する
- プロンプトに「以下の情報を参考に回答せよ」として埋め込む
- 回答を生成する
Vertex AIの Grounding with Google Search は、これらを1つのAPIコール、あるいはSDKのメソッド内で完結させます。開発者は「Google検索を使う」という設定を有効にするだけです。
クエリ生成から回答合成までのデータフロー
内部的には、さらに高度な処理が行われています。
- クエリ拡張: ユーザーの質問が曖昧な場合、AIが自動的に複数の検索クエリを発行し、多角的に情報を集めることがあります。
- コンテキスト注入: 検索結果の上位数件から、回答に必要な部分だけを抽出し、LLMのコンテキストウィンドウに注入します。
- 回答の生成と引用付け: LLMは注入された情報に基づいて回答を作成し、同時にどの部分がどの検索結果に基づいているかを示すメタデータを付与します。
この一連の流れがシームレスに行われる点が、Vertex AI Searchを採用する大きなメリットです。
ライセンスとデータプライバシーの考慮事項
ここで確認すべきなのが、データプライバシーです。「Google検索を使うということは、自社のプロンプトがGoogleの学習に使われるのではないか？」という懸念は、企業のセキュリティ担当者から挙がる可能性があります。
Vertex AIのエンタープライズ向け仕様では、グラウンディングに使用された顧客データ（プロンプトや生成結果）は、Googleの基盤モデルの学習には使用されないと明記されています（執筆時点）。これは、コンシューマー向けの無料版AIサービスとは決定的に異なる点であり、B2B利用における重要な選定根拠となります。
ベストプラクティス①：Dynamic Retrieval（動的検索）によるコストと精度の最適化
さて、ここからが実践的な設計論です。Google検索グラウンディングは強力ですが、すべてのクエリに対して検索を行う必要はありません。
「こんにちは」「調子はどう？」といった挨拶や、「1+1は？」といった単純な計算、あるいは「Pythonでリストをソートするコードを書いて」といった、LLMがすでに十分な知識を持っている一般的なタスクに対してまでGoogle検索を行っていては、コストの無駄であり、レスポンスタイム（レイテンシ）の悪化を招きます。
そこで活用すべき機能が、Dynamic Retrieval（動的検索）です。
すべてのクエリで検索する必要はない
Dynamic Retrievalは、ユーザーのプロンプトを分析し、「この質問には外部情報が必要か？」を自動的に判定する機能です。検索が必要と判断された場合のみGoogle検索を実行し、そうでない場合はLLMの内部知識のみで回答します。
これにより、以下のような使い分けが自動化されます。
- 検索実行: 「今日の東京の天気は？」「最新のAndroidのバージョンは？」
- 検索スキップ: 「俳句を作って」「SQLのJOINの構文を教えて」
動的しきい値（Dynamic Threshold）の設定戦略
Vertex AIでは、この判定の感度を dynamicRetrievalConfig というパラメータで調整できます。具体的には mode を DYNAMIC に設定し、dynamicThreshold（しきい値）を指定します。
このしきい値は、0.0から1.0の間で設定し、予測器（Predictor）が出した「検索必要性スコア」がこの値を超えた場合に検索が実行されます。
- 高め（例: 0.7以上）: 本当に検索が必要そうな時だけ検索する。コスト重視。
- 低め（例: 0.3以上）: 少しでも怪しければ検索する。正確性重視。
実運用における推奨設定は、まずはデフォルトまたは中間の値から始め、PoC（概念実証）を通じてログを確認し、チューニングすることです。「検索すべきなのにしなかった（False Negative）」が多い場合はしきい値を下げ、「不要なのに検索した（False Positive）」が多い場合は上げます。
検索トリガーの条件分岐ロジック
さらに高度な制御を行いたい場合は、アプリケーション側で独自のロジックを組むことも検討します。例えば、プロンプト内に「最新の」「今の」「ニュース」といったキーワードが含まれている場合や、特定のカテゴリ（例：株価情報）が選択されている場合に強制的に検索を有効にする、といったハイブリッドな制御です。
しかし、基本的にはVertex AIのDynamic Retrievalに任せることで、コードの複雑性を排除しつつ、インテリジェントな判定が可能になります。これは「AIにAIを制御させる」という、モダンな設計パターンの好例です。
ベストプラクティス②：信頼性を可視化する「引用（Citation）」のデザイン
ハルシネーション対策として検索を行っても、その結果がユーザーに伝わらなければ意味がありません。ユーザーは「AIがそう言っている」だけでは信用しません。「〇〇という信頼できるサイトにこう書いてある」と示されて初めて納得します。
回答における出典明記の重要性
グラウンディングの最大の利点は、回答の根拠を提示できることです。これはエンドユーザーにとっての安心感だけでなく、万が一情報が間違っていた場合の責任分界点（AIの生成ミスなのか、参照元の情報が誤っていたのか）を明確にするためにも重要です。
Vertex AIが返すメタデータの活用方法
Vertex AI Searchを通じて生成されたレスポンスには、回答テキストだけでなく、グラウンディングに関するメタデータが含まれています。主な要素は以下の通りです。
- Web検索結果のリスト: 参照したWebページのタイトル、URL、スニペット。
- 回答内の引用箇所: 回答テキストのどの部分が、どの検索結果に基づいているかのインデックス情報。
開発者はこのJSONレスポンスを解析し、フロントエンドで適切に表示する必要があります。
ユーザーインターフェースでの根拠提示パターン
UI/UXデザインの観点から、引用の表示にはいくつかのパターンがあります。
- インライン参照: Wikipediaのように、文章中に
[1][2]といった番号を振り、マウスオーバーやクリックでソースを表示する。最も一般的で読みやすい形式です。 - カード形式のソース一覧: 回答の下部に、参照したWebページをカード形式（サムネイル付きなど）で一覧表示する。「合わせて読みたい」情報として機能します。
- 信頼度アラート: 検索結果が少ない、あるいは信頼性が低い情報源しか見つからなかった場合に、「情報の信頼性が低い可能性があります」といった注釈を表示する。
推奨されるのは、インライン参照とソース一覧を組み合わせる形です。ユーザーは回答をざっと読んだ後、気になる部分のソースを深掘りできるからです。この「透明性」こそが、業務アプリにおけるAIの定着率を左右します。
ベストプラクティス③：Grounding Checkによる回答品質の自動評価
検索結果をLLMに渡したからといって、LLMが必ずそれに従うとは限りません。プロンプトの指示が弱かったり、LLMの事前学習知識が強すぎたりすると、検索結果を無視して事実とは異なる内容を出力するハルシネーションを起こすことがあります。
これを防ぐための強力な仕組みが、グラウンディング（根拠付け）と、その評価機能です。Vertex AI Searchは、サイト内データを基にしたグラウンディングによってハルシネーションを抑制するセマンティック検索を実現しています。
「検索結果に基づいていない回答」を検知する
Vertex AI RAG Engineを活用した動的RAGの実装では、ユーザーのクエリ入力時に適切なデータを取得し、要約を生成します。
このとき、サイト内コンテンツ（HTMLやPDFなど）をデータソースとしてインポートしておくことで、生成された回答にソースURLが自動的に明記されます。情報源の透明性が確保されるため、「検索結果に基づいていない回答」をシステム的にも視覚的にも検知しやすくなります。さらに、関連する質問を自動で提示する機能を利用すれば、ユーザーの探索をより深くサポートできます。
Grounding Score（根拠スコア）の解釈と活用
社内データだけでなく、最新のGeminiモデルで提供されている「Search Grounding（Google検索グラウンディング）」機能を統合すれば、天気や株価といったリアルタイムの外部データをRAGに動的に注入することも可能です。
APIレスポンスには、生成された回答が提供されたコンテキスト（検索結果や外部データ）によってどれだけ支持されているかを評価するスコアが含まれます。
- スコアが高い: 回答は検索結果に忠実に基づいている。
- スコアが低い: 回答には検索結果に含まれていない情報（ハルシネーションの可能性が高い）が含まれている。
また、推論の深さと応答速度を最適化するために、APIのパラメータ（例えば thinking_level: MEDIUM のような設定）を適切にチューニングすることも、品質向上に寄与します。詳細な設定値や最新の機能仕様については、公式ドキュメントを参照してください。
フォールバック（回答拒否）の設計
評価スコアを活用することで、アプリケーション側に安全装置としての「ガードレール」を設けることができます。
例えば、医療や金融といった正確性が極めて重要な領域では、根拠スコアが一定の基準を下回る回答はユーザーに表示せず、「申し訳ありませんが、確実な情報が見つかりませんでした」と回答を拒否（フォールバック）する設計にします。
不確かな情報を提供するくらいなら、回答を控える方がリスクを抑えられます。こうした判断を自動化し、安全なAI運用を支えるのがグラウンディング評価の最大の強みと言えます。
導入効果の証明：従来型RAGとの比較とパフォーマンス測定
最後に、プロジェクトマネジメントの観点から、このアーキテクチャを採用する際のROI（投資対効果）をどう説明するかについて触れます。
情報の鮮度：最新ニュースへの追随速度
従来の社内ドキュメントRAGや、定期的にWebをクロールしてベクトルDBを更新する方式では、情報の鮮度にタイムラグが生じます。Google検索連携は、Googleが世界中のWebをインデックスする速度そのものを利用できるため、実質的に「リアルタイム」です。このメンテナンスフリーな鮮度は、運用コストの大幅な削減に繋がります。
回答の正確性：ハルシネーション発生率の低減
一般的な検証結果として、Google検索グラウンディングを有効にした場合とそうでない場合で、事実に関する質問への正答率に差が出ることが確認されています。特に、固有名詞や数値（株価、スペック、日付）に関するハルシネーションは劇的に減少します。
実装コスト：スクラッチ開発との比較
自前で検索APIを契約し、スクレイピングし、チャンキングし、リランクし…というパイプラインを構築・維持するエンジニアリングコストと比較すると、Vertex AI Searchのマネージドサービスを利用するコストは十分に正当化できます。「作る」ことから「使う」ことへシフトし、浮いたリソースをプロンプトエンジニアリングやUX改善に充てることこそ、AI駆動開発の成功法則です。
まとめ
LLMにGoogle検索という「目」を持たせることは、AIアプリケーションの実用性を高めます。しかし、それは単にスイッチをONにするだけで完了するものではありません。
- Dynamic Retrievalで、必要な時だけ検索するコスト感覚を持つこと。
- Citation（引用）で、ユーザーに対する説明責任を果たすこと。
- Grounding Checkで、AIの回答品質を常に監視すること。
これら「3つの柱」を意識した設計を行うことで、「信頼できるAIパートナー」が誕生すると考えられます。
技術は日々進化していますが、情報の信頼性を担保するという本質的な価値は変わりません。実際のプロジェクトでも「グラウンディング」を戦略の中心に据えてみてください。より詳細な実装パラメータや、業種別の活用事例については、公式ドキュメントや専門的なリファレンスを参照することをおすすめします。
もし、現在のRAGシステムの精度に悩みがあるなら、一度「検索」の在り方を見直してみてはいかがでしょうか。答えは、Webの海にあるかもしれません。
コメント