AIエージェントのためのAI検索：グラウンデッド検索 vs 従来のRAG — 本当に使えるのはどっち？

AIエージェントは優れた推論ができるのに、競合の最新価格を尋ねると途端に的外れな答えを返す。RAGが解決策にならない理由と、グラウンデッド検索がエージェントワークフローにもたらす変化を解説。

by AnyCap

こんな経験はないだろうか。コーディングエージェントが美しいリファクタリングをこなし、完璧なアーキテクチャ図を生成した。そこで「うちの競合トップは今いくらで提供してる？」と尋ねると——もっともらしい嘘をつくか、「学習データは半年前で切れてます」と返してくる。

これはモデルのせいではない。ClaudeもGPTもGeminiも、推論能力は驚くほど高い。しかし、どれも自力でライブのWebを見ることはできない。そこで開発者はGoogle APIキーやベクターデータベース、LLM呼び出しを継ぎ接ぎして、本来ならワンコマンドで済むはずのものを組み立てようとする。

この問題には名前がある。検索ギャップ——AIエージェントインフラにおける最大の欠落だ。そして、その解決策はRAGパイプラインの増設ではない。まったく別のアプローチだ。

RAGは社内文書向けに作られた。インターネット向けではない

Retrieval-Augmented Generation（RAG）は、データがベクターデータベースに格納され、四半期に一度しか変わらない場合に美しく機能する。社員ハンドブック、製品仕様書、過去データ。インデックス化し、クエリを投げれば完了だ。

問題は、インデックスに存在しない情報が必要になったときに始まる。

競合他社が新しい価格プランを発表した。規制が変わった。依存しているライブラリに重大なバグが見つかり、Hacker Newsで話題になっている。RAGパイプラインはそのどれも知らない。知りようがない——前回インデックスを再構築したときに取り込んだ情報しか見えないのだ。

チームがより頻繁なインデックス再構築でこれを解決しようとするのを見てきた。その後はハイブリッド検索に手を出す。さらに社内データと社外データで別々のパイプラインを構築する。層を重ねるごとにシステムは高機能になる——そしてより脆くなる。新しいデータソースはすなわち新しい統合であり、統合の数だけ午前2時に障害が起きる。

本当の問題はRAGが悪いということではない。RAGは「Xについて社内規定はどうなっているか」に答えるために設計されたのであり、「今、世界で何が起きているか」に答えるためではないのだ。

グラウンデッド検索が実際に行うこと

グラウンデッド検索は、あなたが質問した瞬間にWebからライブ情報を取得する。インデックスからでも、スナップショットからでもない。今この瞬間に公開されている情報から、すべての主張にソースURLが付与された形で。

これは、あなた自身がリサーチする方法に近い。検索し、いくつかの情報源を精査し、答えを統合し、各情報の出所を明示する。違うのは、エージェントが数分ではなく数秒でそれをやってのける点だ。

違いを具体的にするための簡易比較：

項目 従来のRAG グラウンデッド検索
データの出所 自社でインデックス化した文書 今現在のライブWeb
把握できる範囲 インデックス化した情報のみ 公開されているあらゆる情報
情報が古くなるタイミング ソースが変更された瞬間 古くならない——毎回新たに取得
セットアップ インデックスパイプライン、ベクターDB、チャンク分割 CLIコマンドひとつ

プライベートデータ——顧客レコード、社内財務情報、公開インターネットに触れさせるべきでないもの——については、RAGが今でも勝る。多くのチームが最終的にたどり着く実用的なアーキテクチャはこれだ。内部知識にはRAG、外部コンテキストにはグラウンデッド検索。エージェントは質問内容に応じてどちらを使うかを判断する。

エージェントが実際にどう使うか

CLIが意図的にシンプルなのは、エージェントがライブラリをインポートするのではなく、コマンドを実行するからだ。

anycap search "Acme Corp enterprise pricing Q2 2026" \
  --citations \
  --output acme-pricing.json

エージェントは引用付きの構造化された回答を受け取る。その回答をユーザーに渡すことも、ワークフローの次のステップに投入することも、後で使うために保存することもできる。APIキーの煩わしさも、Python SDKのラッパーも不要。エージェントが ls や git diff を呼び出すのと同じように呼び出せる単なるツールだ。

これを強力にしているのは検索単体ではない。検索が、エージェントが連鎖できる数あるツールのひとつになることだ。競合価格を検索する。市場環境を深掘り調査する。比較ビジュアルを生成する。すべてをレポートにまとめる。公開する。

ひとつのCLI。ひとつの認証。エージェントは各ステップにカスタム統合コードを書くことなく、複数の機能を横断できる。

このパターンは特に競合モニタリングで効果を発揮するのを見てきた。エージェントが毎週競合価格をチェックし、前週と比較し、変更点をフラグ付けし、Slackにサマリーを投稿する。cronジョブひとつ、ミドルウェアゼロで。

検索ツールを選ぶときに本当に重要なこと

機能比較表は一旦脇に置こう。私がグラウンデッド検索ツールを評価するなら、実際にテストするのはこれだ。

正しく引用できているか？ 正解がわかっているクエリを20件テストする。それぞれについて、引用をクリックして、ツールが主張した内容を実際に裏付けているか検証する。間違った引用で正しい答えを返すツールは、「わからない」と認めるツールより危険だ。私は検索ツールが引用したソースが実際には逆のことを言っている「事実」を追いかけて半日を無駄にしたことがある。

実際の速度は？ マーケティング上のレイテンシではなく、50のエージェントが同時に叩いたときのp99レイテンシだ。検索ステップごとに8秒待つエージェントパイプラインは、関係者全員を苛立たせる。

エッジケースを適切に処理するか？ 何かマイナーなものを尋ねてみる。最近のものを。情報源によって意見が割れているものを。優れたツールは対立を表面化させる。意見の不一致を平均化して無意味な答えにするツールはダメだ。

CLIかSDKか？ これは見かけ以上に重要だ。エージェントは from x import y をしない。コマンドを実行する。Pythonライブラリの背後にあるツールは、あなたがラッパーを書かない限りエージェントが使えないツールだ。

これが思った以上に重要な理由

検索ギャップは些細な不便ではない。エージェントが本格的なリサーチワークフローを処理できない最大の理由だ。推論はできても検索できないエージェントは、Stack Overflowがブロックされた開発者のようなものだ——能力はあるが、実際に必要な情報から遮断されている。

解決策は複雑ではない。ただ、ほとんどのチームが最初に手を伸ばすものではない。RAGは馴染み深く、検索ギャップはエージェントが信頼した相手に自信満々で間違った情報を届けたときに初めて明らかになるからだ。

あなたのエージェントがその壁にぶつかっているなら——内部データでは完璧に動くのに、外部の情報が必要になった瞬間に崩れるなら——それはおそらくモデルのせいでも、プロンプトのせいでもない。検索アーキテクチャが別の問題のために作られたのだ。

関連記事：