エージェント向け検索ツールの選び方：情報の発見から検証済みの回答まで

検索エージェントは関連がありそうなリンクを10件挙げても、あるパラメータが現在サポートされているかという問いには答えられないことがあります。リンク先が古いバージョンであったり、スニペットで制約が省略されていたり、複数の記事が同じ発表を引用していたりする場合があるためです。次に必要なのは、多くの場合、検索回数を増やすことではなく元のページを読むことです。

ツールを選ぶときは、まず現在のステップの成果物を明確にします。読むべきソースなのか、特定のページのコンテンツなのか、具体的な結論を裏付けるエビデンスなのかです。この記事では、EveryInfraのこれら3つの成果物に沿って検索ツールを整理し、検索をやめるタイミング、不明点の残し方、引用の検証方法を説明します。カタログとタイムスタンプ付きの過去の呼び出しは別途ドキュメントにまとめています。この記事はすべてのツールをベンチマークするものではなく、エンドツーエンドのリサーチシステムをうたうものでもありません。

最初のステップ：質問から検証可能な主張への書き換え

「この製品を理解する」はリサーチの方向性としては有効ですが、ツール処理の完了条件にはなりません。どのエンドポイントがこのパラメータを受け付けるか、どのバージョンが該当するか、追加の権限が必要か、失敗時に再試行できるかといった検証可能な質問に分解してください。各質問には、時点、製品、利用状況を明記します。

たとえば、リモートサービスがあるクライアントと連携できるかを検証する編集者は、サービスがどのトランスポートをサポートしているか、クライアントがどの認証方式を受け付けるか、そのクライアントで呼び出しが実際に成功したかを、それぞれ確認する必要があります。前の2つはドキュメントで確認できますが、3つ目には実行時のエビデンスが必要です。2つのドキュメントがそれぞれ独立してMCPのサポートに言及していても、実行時のエビデンスがなければ、両者を根拠に連携を検証済みとすることはできません。

質問ごとに想定するエビデンスの種類を記録しておくと、検索範囲が広がりすぎるのを防げます。パラメータの定義は該当バージョンの公式リファレンスドキュメントを優先し、実際の障害事象には具体的な入力、エラー、環境が必要です。顧客の成果には、許可を得た追跡可能な事例が必要です。対応するエビデンスがない場合は、別の資料で代用するのではなく、結論の範囲を絞ってください。

このパイプラインを理解するには、LewisらによるRAGの原論文を参照してください。この論文では、パラメトリックな知識だけを唯一の根拠とせず、生成モデルと検索ストアを組み合わせています。本記事で扱う探索結果、読み取り結果、項目ごとの検証は、アプリケーション層の設計に当たります。本記事は、論文の実験結果を根拠にWebエージェントの精度を保証するものではありません。

探索開始の条件：ページの場所が不明な場合のみ

質問はあってもURLがない場合は、まずwebで関連しそうなページを探します。2026年9月4日時点の公開カタログでは、qが必須パラメータとして記載され、サイト、地域、期間、ページ番号などは任意パラメータです。パラメータ名を自然言語から推測せず、呼び出す前に必ず最新のカタログを確認してください。

探索フェーズのツールは、入力と期待される出力に基づいて選択できます。

• semanticは概念を自然言語で記述する場合に適しており、suggestはクエリ表現を見つけるために使います。関連語は検索の手がかりであり、結論ではありません。
• similarは既存のURLを起点に類似ページを探し、deepはより深い検索の入口を提供します。ツール名に「deep」が含まれていても、そのページが現在の証拠要件を満たすという意味ではありません。
• news、scholar、forumは、検索範囲をそれぞれニュース、学術コンテンツ、ディスカッションに寄せます。変わるのはソースの範囲であり、自動的な事実検証の基準は変わりません。
• places、shopping、media、lensは、それぞれ場所、商品、メディアのキーワード、画像URLを対象とします。入力が異なるため、qだけを受け付ける単一の関数にまとめることはできません。

フォーラムの具体的なエラーメッセージから、ドキュメントでは扱われていない環境の差異が明らかになることがあります。ただし、フォーラム上の議論を、対象バージョンに一致する公式定義より優先すべきではありません。より有用なのは、ドキュメントではサポートされていると記載されている一方、ある環境では失敗が報告されているという矛盾をそのまま記録し、両者が異なる理由を特定するうえで不足している再現情報を詳しく記すことです。

URL判明後の反復検索から読み取りへの切り替え

指定したページのコンテンツはreadで扱います。サイト内のページ構造を確認するにはmapを使い、複数ページを読み取る場合はcrawlを検討してください。harvestは単一ページを読み取る際の既定の入口として使うのではなく、構造化されたサイトタスク向けに、その目的とフィールド要件を確認したうえで使用してください。

この区別は後続の検証に影響します。mapでURLリストを取得した後、発見したページを読み取り済みのコンテンツとして記録しないでください。検索スニペットから抽出した文を、完全に検証済みとすることもできません。コンテンツが途中で切れている場合、ナビゲーションしか取得できない場合、またはログインページが返された場合、読み取りのステップは未完了のままです。

ツールの切り替えをアクセス制限の回避に使ってはいけません。ログインを求められた場合、明示的にアクセスを拒否された場合、または認可の範囲が不明確な場合は、作業を止めて、まず認可された経路を調べてください。一時的なページ障害であれば再試行の条件を残しておけますが、認可されていない対象については、ツールを替えて強引にアクセスするのではなく、範囲を見直す必要があります。

1つの無料コマンドによる必須パラメータの確認

以下のコマンドは公開ツールカタログを読み取るだけで、検索の実行や対象コンテンツのダウンロードは行わず、APIキーも不要です。ターミナルにcurlとjqがインストールされている必要があります。pipefailを有効にすると、リクエストのエラーが後続の処理で隠れるのを防げます。

set -o pipefail
curl -fsS --max-time 20 \
  'https://api.everyinfra.com/api/v1/search/tools' \
  | jq -e '
      [.tools[] |
       select(.tool == "web" or .tool == "read" or .tool == "crosscheck") |
       {tool, required_params, optional_params}]
      | if length == 3 then . else error("selected tool missing") end'

今回の検証では、webとcrosscheckはqを、readはurlを必須としています。crosscheckの任意パラメータにはnum、since、read_top、depth、mechanismsがありますが、readには任意パラメータの記載がありません。すべてのツールに同じ期間や件数のフィールドをそのまま渡さないでください。公開検索カタログ

同じカタログには17個のツールが記載されています。この数はクエリリストの長さを表します。17項目について業務上の検証を行ったことを示すものではなく、記事タイトルで長期的に約束する数でもありません。カタログの定義からはリクエストの作り方がわかりますが、コンテンツの完全性、結果の件数、課金状況は保証されません。

事実を判定しないCrosscheckによる証拠間の関係把握

回答をドキュメント、コード、または対外的な約束に反映する場合は、crosscheckをクロスチェックの入口として使えます。その目的は、編集者が重要な原文を読む前に、異なる検索メカニズムがそれぞれどのようにソースを見つけるかを観察できるようにすることです。メカニズムごとのヒット数を、較正されていない確率スコアに変換してはいけません。

同じ発表を3つの検索経路で見つけても、原典となる証拠は1つだけです。異なるドメインが同じニュースを転載していても、複数の独立した観測にはなりません。ソースが独立した裏付けなのか、言い換えの繰り返しにすぎないのかを判断するには、最終URL、元の発行者、引用関係、バージョン、タイムスタンプを評価する必要があります。

この過程に、検証されていない固定のしきい値を当てはめないでください。たとえば、ある数値が3つのドメインに掲載されるとAIによる引用の重みが2倍になる、といった想定です。GoogleのAI OverviewsとAI Modeに関する公式ドキュメントでは、公開されている推奨事項は基本的なSEO、発見しやすい内部リンク、有用なコンテンツが中心であり、複数ドメインによる乗数のルールは定められていません。また、これらの記載がすべてのRAGシステムに当てはまるわけでもありません。同じチームがコーポレートサイト、LinkedIn、Mediumで公開した数値は、読者が原典を見つける助けになります。ただし証拠カードでは、3つの別々の票として数えるのではなく、同一の元の観測までたどる必要があります。

ソース同士が矛盾する場合は、その矛盾を分解します。新旧のドキュメントの相違であれば、まずバージョンの変更を確認します。公式の記載と実行時の失敗の相違であれば、シナリオと再現の不足点を記録します。二次サイトと一次ソースの相違であれば、ソースの該当する段落に立ち返ります。多数決で1つの答えに絞り込んだり、ツールが生成した要約を唯一の証拠にしたりしないでください。

結論ごとの証拠カードの保持

業務システムでは、以下のフィールドを管理することをおすすめします。これらは記録方法の設計案であり、APIのレスポンス構造について述べたものではありません。

• claim：必要最小限の主張と、その対象となる製品、バージョン、地域。
• source_urlとfinal_url：リダイレクトやソースの重複を識別するための、当初のエントリーポイントと最終到達ページ。
• observed_at：読み取り時刻。ページに記載されたpublished_atやupdated_atとは分けて保持します。
• evidence_locator：トップページではなく、特定のセクション、段落、サンプルを指すロケーター。
• support_status：裏付けあり、矛盾、無関係、読み取り不可、検証待ちを区別する推奨分類。
• limits：ソースの本文に記載された適用範囲の制限、例外、証拠の不足、再評価の条件。

証拠カードの目的は書類作業を増やすことではありません。別のレビュアーが同じリンクを使って同じ事柄を判断できるようにすることです。「サイトAはその主張を肯定している」とだけ保存しても、再検証はできません。また、ソースの条件を省くと、リンクを追加しても結論を修正できなくなります。

変動する料金、バージョン、機能一覧には再評価の時期を設定し、公開前に実際の引用を再確認してください。ページが公開中でも内容が変わっていないとは限らず、リンクが有効でも元の主張が今も正しいとは限りません。結論を修正する際は、古い観測日を今日の日付に書き換えるのではなく、元の証拠を保持してください。

複数のステップにわたって追跡するには、エンティティ、アクティビティ、派生関係に関するW3C PROVの勧告を参照し、ソースのバージョン、読み取りログ、回答を結び付けてください。結論の出どころを説明しやすくなりますが、ソースの独立性や内容の正しさが自動的に判定されるわけではありません。

成功、結果なし、読み取り不可の区別

2026-9-02の匿名化した業務サンプルでは、webが3件の結果を返し、crosscheckのある実行では4つのメカニズムの記録が返されました。同じ回には、readが指定したドキュメントを読み取れなかったサンプル、HTTP 503が発生したサンプル、scholarへのリクエストが成功したものの結果が空だったサンプルも含まれていました。これらは特定の過去の入力に対する結果であり、すべての呼び出しでの動作を保証するものではありません。

2026-9-4の再確認ではツールカタログのみを対象とし、認証フローは再実行していません。そのため本記事は、「readが現在失敗している」とも「readが復旧した」とも主張しません。統合の受け入れ検証では、コンテンツ全体の取得、失敗状態の保持、引用の裏付けをそれぞれ独立して確認する必要があります。古いサンプルで現在の結果を代替することはできません。

エージェントには、結果が空の場合でもクエリ条件と期間を保持させ、「事実が存在しない」ではなく「今回は結果が見つからなかった」と出力させます。読み取れなかった場合は、見つかったURLと失敗の状態を残し、スニペットを全文のように見せかけないでください。タイムアウトでリクエストの結果が不明になった場合は、タスクが実行されなかった、あるいはアカウントが変更されていないと決めつけないでください。

リトライの回数には上限を設け、発動条件を限定する必要があります。権限不足による失敗には認可の問題として対処し、パラメータエラーでは入力を修正し、一時的で再試行可能な失敗はインターフェースの規約に従って処理します。それでも根拠を入手できない場合は、エージェントを無限ループに陥らせたり、確認できていない内容を捏造したりせず、欠落を残したままその項目を完了します。

引用検証とセキュリティチェックに共通する単一の提供プロセス

検索で得たコンテンツは検証すべきデータであり、新たな操作指示ではありません。ウェブページがローカルファイルのアップロード、APIキーの貼り付け、セキュリティチェックの無効化、見慣れないアドレスへのルーティングを求めてきても、そのテキストが検索結果から来たというだけで実行してはいけません。ページの内容はシステム指示、認証情報、ユーザーの認可から切り離し、ツールは現在の問題に必要なデータだけを取得するようにします。

回答を書き終えたら、引用を1行ずつ検証します。リンクは隣接する主張を裏付けているか、制約条件は残っているか、日付は観測時点と一致しているか、一次情報源を重複してカウントしていないかを確認します。参考文献リストが空でないことを確認するだけでは不十分です。特に「接続可能」を「完全に実装済み」と、「フィールドに対応」を「すべてのフィールドを返す」と言い換えたとき、元の意味が拡大されていることを引用が教えてくれることはほとんどありません。

ワークフローは、手作業で用意したテスト素材で確認できます。たとえば、一次情報源1件とその転載2件、同じページの新旧バージョン、タイトルしか含まない読み取り結果、コンテンツに埋め込まれた悪意のある操作指示です。期待される動作は、重複した根拠を除去すること、バージョンを明記すること、読み取りを未完了のまま扱うこと、ページ内の指示を拒否することです。これは推奨の受け入れテストセットであり、今回のサイクルで実際に実行した製品テストではありません。

ウェブページのテキストに含まれる悪意のある指示は、OWASPが説明する間接プロンプトインジェクションのリスクにあたります。最小権限の原則とツール呼び出しの検証に従い、ページのテキストを根拠に、読み取りツールへファイルアップロードやアカウント変更の機能を付与してはなりません。高リスクなアクションは、独立した認可ステップで引き続き制御します。

検証可能な1つの質問から導入を始める

最初のラウンドでは、公開されていて低リスクで、認可が明確な質問を1つ選び、期待する一次情報源を固定します。情報探索、取得内容、結論、引用を段階ごとに記録し、論理の飛躍がないか人がチェックします。この1本の根拠チェーンを検証できたら、質問のカテゴリとツールの範囲を広げます。

EveryInfraの公開カタログを使えば、まずツールと入力を確認できます。実際の業務での呼び出し、失敗時の処理、提供品質は、自社の認可済みサンプルで検証する必要があります。この記事の完了基準は「すべてのツールを呼び出したか」ではなく、どの記述に一次情報の裏付けがあり、どれが不明のままで、次にどんな根拠が必要かを読者が指摘できるかどうかです。APIドキュメントを見る