AnySearch for AI Agents:構造化検索でトークン消費を削減し、より優れたリアルタイムコンテキストを提供

検索は、AIエージェントが利用できる最も重要な外部能力の一つとなっています。強力なモデルは優れた推論を行えますが、一度も検索したことのない事実を回復することはできず、証拠なしに最新情報と古い報道を区別することも、欠落した企業記録を確実に推測することもできません。AnySearchは、この問題を人間向けの検索ページではなく、エージェントのインフラストラクチャとして捉えます。リンク、タイトル、短い要約を返すだけに留まらず、クエリを関連するウェブページにルーティングすることに重点を置いています。

发布于 2026年7月15日generalGEO 评分: 013 次阅读
AnySearch for AI Agents:構造化検索でトークン消費を削減し、より優れたリアルタイムコンテキストを提供 のカバー画像

AnySearch for AI Agents:構造化検索でトークン消費を削減し、より優れたリアルタイムコンテキストを提供

はじめに

検索は、AIエージェントが利用可能な最も重要な外部機能の一つとなっている。強力なモデルは優れた推論が可能だが、一度も検索したことのない事実を復元することはできず、証拠に基づいて最新情報と古い報道を区別することも、欠落している企業記録を確実に推測することもできない。

AnySearchはこの問題を、ユーザー向けの検索ページではなく、エージェント向けのインフラストラクチャとして捉えている。単にリンク、タイトル、短い抜粋を返すのではなく、クエリを関連するウェブまたは垂直ソースにルーティングし、重複や低価値なコンテンツを除去し、有用な情報を抽出して、モデルの推論コンテキストに直接投入できる構造化されたレスポンスを提供する。

本製品は、2026年7月6日付でProduct Huntのデイリーおよびウィークリーランキングで首位を獲得した。発表時の紹介では、API、MCPサーバー、またはインストール可能なエージェントスキルを通じて、リアルタイムでフィルタリング、重複除去、構造化された情報を提供することが強調されている。

画像は、Product Huntサイトにおける先週のトッププロダクトのランキングを示している。AnySearchは126件のレビュー、882回のシェアで第1位となり、「エージェントと開発者から信頼されるリアルタイム構造化検索」と説明されている。この画像は、ドキュメント内のAnySearch紹介コンテンツに関連しており、Product Huntにおける人気度を視覚的に示し、エージェント指向の検索ワークフローとしての特徴を強調している。

本稿では、このようなエージェント向け検索ワークフローが従来の検索APIとどのように異なるかを説明し、元のレポートで示されたサンプルを詳細に解説するとともに、実用的なインストールおよび評価ガイドを提供する。

ベンチマークに関する注記: 以下の精度およびレイテンシデータはすべて、ソース記事で再現されたAnySearchの比較結果に基づく。本バージョンでレビューした公開資料には、完全な評価コード、生の出力、評価プロンプト、または統計分析は含まれていない。これらのデータは、独立した再現ベンチマークではなく、ベンダー報告の結果として扱われたい。

なぜ通常の検索結果はエージェントにとってコストが高いのか

人間は結果ページを閲覧し、広告を無視し、重複記事を認識し、どのリンクが注目に値するかを判断できる。

一方、エージェントは各結果をインプットとして受け取ることが多く、これには複数のコストが伴う:

  • 重複記事がコンテキストスペースを占有する。
  • 長いページにはナビゲーション、広告、無関係なテキストが含まれる。
  • 質の低い結果は追加の検索ラウンドを引き起こす可能性がある。
  • 古い情報が現在の事実と誤認される可能性がある。
  • 検索スニペットには確実な結論に必要な証拠が欠けている場合がある。
  • モデルは推論前にトークンを費やしてクリーニングを行う必要がある。

問題は検索の精度だけでなく、返される情報の形態と密度にもある。

したがって、実用的なエージェント検索システムは、情報をモデルに渡す前に3つの質問に答えるべきである:

  1. このクエリに最も適したソースタイプはどれか?
  2. どの結果が独自の信頼できる証拠を提供するか?
  3. ウェブノイズを含まずに結果をどう提供するか?

AnySearchはまさにこれらのステップを中心に設計されている。

Product Huntでの発表と公開ベンチマーク結果

AnySearchは2026年7月6日にProduct Huntのデイリーおよびウィークリーランキングで第1位を獲得した。Product Huntはこれを次のように説明している:

エージェントと開発者から信頼されるリアルタイム構造化検索。並列検索ソースからフィルタリングおよび重複除去された情報を取得する。

ソース記事ではまた、3つのベンチマークグループから構築された300問の評価セットが紹介されている:

  • FRAMES
  • FreshQA
  • WebWalkerQA

記事では、AnySearch、Brave Search、Parallelは同じ言語モデルを使用しているため、検索レイヤー(モデル選択ではなく)が主要な変数であると指摘されている。

報告された精度

検索システム 全体精度 FreshQA WebWalkerQA
AnySearch 76.4% 80.0% 65.2%
Brave Search 64.0% 74.0% 46.8%
Parallel 72.2% 78.0% 61.0%

画像は棒グラフで、AnySearch、Brave Search、Parallelの3つの検索システムについて、総合精度、FreshQA、WebWalkerQAの3つの観点でのパフォーマンスを示している。グラフ内で、黒色の棒は総合精度、灰色の棒はFreshQA、濃い灰色の棒はWebWalkerQAを表す。データによると、AnySearchの総合精度は76.4%、FreshQAは80%、WebWalkerQAは65.2%;Brave Searchの総合精度は64%、FreshQAは74%、WebWalkerQAは46.8%;Parallelの総合精度は72.2%、FreshQAは78%、WebWalkerQAは61%となっている。このグラフは文脈と密接に関連しており、3つの検索システムの異なる側面における精度の状況を視覚的に示している。

FreshQAは、現在または変化する情報に依存する質問を評価する。WebWalkerQAは、複数のページにまたがってサイトを閲覧し、証拠を特定することに焦点を当てている。両方を組み合わせることは、単なる浅いリンクリスト以上のものを必要とするエージェントにとって非常に有用である。

FRAMESはソース記事の総合評価に含まれているが、記事で示されたベンチマーク別のグラフは、総合スコアに加えてFreshQAとWebWalkerQAのみを表示している。

報告されたレイテンシ

レイテンシグラフは、平均比較とWebWalkerQAサブセットの両方の次元で、AnySearchの値が低いことを示している。

検索システム 平均レイテンシ値 WebWalkerQAレイテンシ値
AnySearch 48.0 76.5
Brave Search 68.9 133.0
Parallel 77.4 145.6

この画像は、2つの検索システムの平均レイテンシとWebWalkerQAの2つの指標におけるレイテンシ比較を示す円グラフで、ドキュメント内の比較表の内容と対応している。左の円グラフには「平均レイテンシ」と表示され、AnySearchを表す青色のセクションの値は48、Brave Searchの灰色のセクションの値は68.9、Parallelの濃い灰色のセクションの値は77.4;右の円グラフには「WebWalkerQA」と表示され、対応するセクションの値はそれぞれ76.5、133、145.6であり、両グラフの凡例は青色がAnySearch、薄灰色がBrave Search、濃い灰色がParallelを表している。

元の画像では単位が明示されていないため、表は報告された数値をそのまま保持し、秒やミリ秒に変換していない。

AnySearchをエージェントに接続する

AnySearchは現在、3つの主要な統合方法をサポートしている:

  • API
  • MCP
  • エージェントスキル(Agent Skill)

公式GitHubリポジトリは、Apache-2.0ライセンスのスキルおよびMCPサーバーを提供している。両方とも、汎用ウェブ検索、垂直検索、並行バッチ検索、および全文URL抽出をサポートしている。

画像はAnySearchの関連情報を示している。上部には歯車アイコンがあり、横に「anysearch」とテキストがあり、右側にはゴミ箱アイコンと青色のスイッチがある。下部のテキストでは、リアルタイム検索エンジンであり、ウェブ検索、垂直検索、並行バッチ検索、URLコンテンツ...などをサポートすると説明されている。

当該画像は、ドキュメント内でAnySearchの内容を紹介する部分に関連しており、AnySearchの機能や特徴を視覚的に示すことで、読者が同サービスがサポートする検索タイプなどの情報をより明確に理解できるようにするものです。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/80912d0a-73aa-4f80-bbab-eb6f0779cd63-e96fb0d4-000e-4288-ae1b-bf3c078c578f.png)

AnySearchスキルのインストール

公式リポジトリでは、メインブランチから未公開の変更を直接取得するのではなく、固定バージョン(pinned release)のダウンロードを推奨しています。

ブランチ。

# 指定バージョンの AnySearch Skill リリースをダウンロードします。
# リリースページを確認し、より新しい安定版がリリースされた場合は v2.1.0 を適宜置き換えてください。
curl -L -o anysearch-skill.zip \
  https://github.com/anysearch-ai/anysearch-skill/archive/refs/tags/v2.1.0.zip

# リリースを解凍します。
unzip anysearch-skill.zip

解凍したディレクトリを、お使いのエージェントが使用する適切な場所に移動します:

# Claude Code
mv anysearch-skill-2.1.0 ~/.claude/skills/anysearch

# OpenCode
mv anysearch-skill-2.1.0 ~/.config/opencode/skills/anysearch

# Cursor または Windsurf プロジェクト
mv anysearch-skill-2.1.0 <project>/.skills/anysearch

# 共有エージェントロケーション
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch

正確なディレクトリは、エージェントプラットフォームとその現在のスキル検出ルールに依存します。

APIキーと匿名アクセス

公式スキルおよびMCPドキュメントによると、匿名アクセスにはレート制限が低く設定されています。APIキーは任意ですが、より安定した、あるいはより多くの利用量を得るために推奨されます。

APIキーをパブリックリポジトリにコミットしないでください。環境変数、キーマネージャー、または無視されるローカル設定ファイルに保存してください。

テスト1:本番環境向けGoコードの検索

元記事の最初のテストでは、エージェントにチュートリアルではなく、実際の本番環境で使用されるGo製APIレート制限実装を探すよう要求しました。

プロンプトは以下の通りです:

現在、GoでAPIレート制限機能を実装するプロジェクトを構築しています。チュートリアルは必要ありません。実際のオープンソースプロジェクトから、本番環境で使えるコードを見つけてください。

専用の検索ワークフローがない場合、このエージェントは一般的なリンクや断片的なコードスニペットを返したと報告されています。このような結果は概念を説明するには役立つかもしれませんが、開発者が完全な実装コンテキストを必要とする場合には、有用性は限定的です。

AnySearch支援による実行では、より明確な呼び出しチェーンと実際のコードベースからの素材を含む、より構造化されたコード指向の結果が返されました。

この違いは非常に重要です。なぜなら、本番コードとは単なるアルゴリズム以上のものだからです。有用な検索結果は、エージェントが以下を確認するのに役立つはずです:

  • パッケージ構造
  • 初期化
  • 設定
  • ストレージまたは分散状態の依存関係
  • ミドルウェア統合
  • エラーハンドリング
  • テスト
  • ライセンス
  • プロジェクトの活発さ
  • コードとリポジトリの他の部分との関係

見た目は美しい関数を抽出しても、そのコンテキスト上の前提を見落とすようなコード検索は、実装エージェントを誤った方向に導く可能性があります。

より良い本番コードの検索クエリ

どの検索プロバイダーを使用する場合でも、より明確なクエリによって結果が改善されます:

本番コードでAPIレート制限を実装している、現在もメンテナンスされているオープンソースのGoプロジェクトを探しています。

要件:
- リポジトリと正確なファイルパスを返すこと。
- 実際のサーバーやゲートウェイで使用されているコードを優先すること。
- 初期化とリクエストフローのコンテキストを含むこと。
- アルゴリズム、バックエンドストレージ、テスト、ライセンスを示すこと。
- チュートリアルコードベースやコピーされたコードスニペットを除外すること。
- 最近の関連コミットの日付を明記すること。

検索システムは証拠を提供する必要があります。コーディングエージェントはコードを適応させる前に、リポジトリ、ライセンス、テスト、セキュリティ上の前提、および現在のメンテナンス状況を確認する必要があります。

テスト2:企業デューデリジェンス

2つ目のテスト

同じ企業調査の要件について、AnySearchとExaを比較しました。

両レポートとも、基本的な公開企業情報の提示に関しては良好な結果を示しました。主な違いはリスクセクションに見られました。

報告によると、AnySearchは現地で公開されたコンプライアンス記録やプラットフォーム上の告知を発見しましたが、これらはExaが生成したレポートには含まれていませんでした。情報源はこの違いを、言語モデル自体ではなく、中国の垂直データソースへのアクセスに起因するとしています。

画像は、AnySearchとExaの企業基本情報に関する比較を示しています。左側がAnySearch、右側がExaで、いずれも会社の正式名称、英語名、設立日、上場日、上場場所、株式コード、登記上の住所、所属業界、支配株主、実質的支配者、創業者、現在の会長/総経理、取締役会秘書などの項目を含んでいます。両者の会社の正式名称、英語名、設立日などの情報は一致していますが、Exaは株式コード、所属業界、支配株主、実質的支配者、創業者、現在の会長/総経理などで異なっており、例えばExaの株式コードは「002002.SZ」であるのに対し、AnySearchでは表示されていません。この図は、両レポートが企業基本情報では類似したパフォーマンスを示したが、リスクセクションに違いがあったという文脈に対応しています。

画像は、ある企業のリスク分析に関するAnySearchとExaの比較を示しています。左側のAnySearch部分では、リスクイベントが2026年であり、影響、進捗、対応策などの情報が詳しく記載されています。右側のExa部分では、リスク要因としてAIによる破壊的リスク、需要縮小リスクなどが挙げられています。この図は文脈と密接に関連しており、両レポートのリスク分析セクションに差異があったことが言及され、AnySearchがリスクイベントに関してより詳細な情報を提供している一方、Exaはリスク要因の分類に重点を置いていることを示しています。

この例は、企業調査における一般的な限界を浮き彫りにしています。グローバルなウェブインデックスは、組織の公式ウェブサイト、国際的な報道、英語のデータベースをカバーするのには優れているかもしれませんが、地域の規制、裁判所、苦情、またはプラットフォーム記録を見落とす可能性があります。

デューデリジェンスエージェントは、以下のような複数のカテゴリを明示的に検索する必要があります:

  1. 会社登記と受益者情報
  2. 資金調達と株主異動
  3. 訴訟と執行記録
  4. 規制当局の通知
  5. 製品クレームとプラットフォーム制裁
  6. 特許と商標
  7. サイバーセキュリティとデータインシデント
  8. 経営陣の変動
  9. 財務および運営上の警告サイン
  10. 企業の自国市場における最新ニュース

重要なお知らせ: 検索支援によるデューデリジェンスは、専門家による法律、財務、またはコンプライアンスレビューに代わるものではありません。記録は不完全である可能性があり、名称が混同される可能性もあり、自動生成された要約が証拠を誤って解釈する可能性もあります。

テスト3:リアルタイムグローバルエネルギーレポート

3つ目のテストでは、AnySearchに以下の内容を含む世界のエネルギー市場レポートの作成を依頼しました:

  • 米国の天然ガス在庫の変化
  • 欧州各国の日前電力価格
  • オーストラリアの送電網炭素強度

情報源が示す出力結果には、地域別の在庫詳細、欧州の電力価格比較、排出データが含まれていました。このレポートでは、米国エネルギー情報局(EIA)が7月9日に発表したデータや、欧州の7月12日付けの日前電力価格など、最近の情報が引用されていました。

この画像は、AIツール「AnySearch」の操作インターフェースにおける機能デモを示しています。上部にはユーザーの要求として「世界エネルギー市場レポートの作成:米国の天然ガス在庫変動、欧州各国の日前電力価格動向、オーストラリア電力網の炭素排出データ」が明示されており、画面にはツールがレポート生成過程で呼び出した異なるツールと対応する操作記録(ツール名や具体的なコマンドライン内容)が表示されています。下部にはDeepSeek V6 Proとの連携入り口が見られ、本ツールが多分野の世界エネルギー調査タスクを実行する過程を視覚的に示しており、文書内のAnySearchが複数の独立したデータ経路のクエリを処理できるという説明に対応しています。

画像は欧州各国の日前電力価格動向を示しており、タイトルは「最新日前電力価格 7月12日」です。表にはドイツ、フランス、スペインなど11か国・入札エリアの電力価格(€/MWh)と前日比が記載されています。例えば、ドイツの電力価格は75.23 €/MWhで前日比20%減、フランスは75.21 €/MWhで前日比18%減、オランダは73.41 €/MWhで前日比22%減などです。

この図は文書内のテスト3の内容に関連しており、欧州多国の日前電力価格データを示し、AnySearchが生成した世界エネルギー市場レポートの一部です。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/3f5432f8-0641-4e6e-b8aa-62b6a50e7d18-f18fcac7-52c7-4efa-a066-9c9722c9cea9.jpeg)

これは多分野クエリの典型的な例であり、システムが1回のリクエストに単一の通常Web検索ではなく、複数の独立したデータ経路が含まれていることを認識する必要があります。

信頼性の高い実装では、以下を達成すべきです:

  1. リクエストをサブクエリに分割する。
  2. 各サブクエリを適切なデータソースにルーティングする。
  3. 公開日および観測日を記録する。
  4. 単位と地域定義を保持する。
  5. 予測値と実測値を区別する。
  6. ソースURLまたは識別子を返す。
  7. 最終出力時に正規化処理を行い、データ間の矛盾を隠さない。

現在のデータには常にタイムスタンプを含める必要があります。レポートが基礎となる測定の公開時期とそのカバー期間を説明していない場合、「最新」という言葉は無意味です。

AnySearchがクエリをルーティングする方法

中核となる設計の主張は、AnySearchがエージェントの動作に基づいて検索パイプラインを再構築するという点です。

ソースコードに示されるフローは5つの段階で構成されています:

  1. クエリ受信
  2. 意図理解
  3. ルーティングオーケストレーション
  4. 並列検索
  5. 結果集約とエージェントへの引き渡し

この画像は、AnySearchのAIエージェント向け検索フローを示しており、5つの中核ステップ(クエリ受付、クエリ理解、ルーティングオーケストレーション、並列検索、結果統合)で構成され、最終的にエージェント引き渡しが行われます。各ステップには対応する中核動作が記されています:クエリ理解は意図モデリングと領域判定、ルーティングオーケストレーションは情報フィルタリングと経路計画、並列検索はマルチソースからの呼び出し、結果統合は正規化、再ランク付け、構造化を含みます。このフローは文書内で言及されるAnySearchが検索パイプラインを再構築する5段階に対応し、システムがインテリジェントエージェントの動作に基づいて設計された構造化検索ロジックを明確に示しています。

1. 意図理解

システムはまず、クエリにどのような種類の証拠が必要かを識別します。

企業背景クエリには、登記記録、特許、法律データベース、苦情プラットフォームが必要な場合があります。コード関連の問題はコードリポジトリとドキュメントにルーティングすべきです。エネルギー市場クエリには、公式の在庫データや電力市場データが必要な場合があります。

これは、すべてのリクエストを1つの汎用インデックスで処理する方法とは大きく異なります。

2. 領域とソースのルーティング

AnySearchは、一般検索に加えて、以下の分野を含む20以上の垂直カテゴリをサポートするとしています:

  • コード
  • 金融
  • 学術研究
  • セキュリティ
  • 法情報
  • 企業・ビジネスデータ
  • 一般Webコンテンツ

この画像はAnySearchの「全スペクトルカバレッジ」能力を示しており、左側のテキストは専門的な深さから日常的な幅広さまで、エージェントの多様なニーズに対応できることを説明し、右側は地球の図案とともに4つの中核能力モジュール(多分野カバレッジ、拡張可能ネットワーク、日常ニーズ、個人の関心)を配置しています。これは文書内で言及されるAnySearchが一般検索と20以上の垂直分野をサポートし、コード、金融、学術研究など異なるタイプのシナリオをカバーできることに対応し、エージェントの多様なニーズをカバーするという設計特性を視覚的に示しています。

公開MCPインターフェースには領域ディレクトリメソッドが含まれています。エージェントは、サポートされていないフィルターを自ら作成するのではなく、有効な領域とパラメータスキーマを要求する必要があります。

3. 並列検索

複数の領域にまたがる質問は、複数の独立した検索を開始できます。MCPサーバーは1~5個のクエリオブジェクトのバッチ実行をサポートしており、あるブランチの失敗が他のブランチの実行をブロックすることはありません。

並列検索は総待機時間を短縮できますが、集約層が急速に出現する低品質の結果が、より遅い権威ある結果を押しのけるのを防ぐことができる場合に限ります。

証拠。

4. モデル前のソート

原文では3つのソートのアイデアが提案されています:

  • 同一ソース減衰:同一サイトからの重複結果の重みを減らす。
  • 情報密度調停:より多くのユニークで有用な証拠を提供する結果を優先する。
  • ハイブリッドソート:セマンティック関連性とタイムリーさを組み合わせる。

その目標は、コンテンツが言語モデルに入力される前により多くのフィルタリングを行うことです。

これは、大量の結果セットを返し、モデル自身に重複排除を行わせるパイプラインとは異なります。事前フィルタリングはトークンを節約できますが、別の責任を生み出します:ソートシステムは、少数のソースや重要な矛盾する記録を黙って削除してはなりません。

5. 構造化された引き渡し

ソート後、AnySearchは主なコンテンツを抽出し、ページノイズを除去し、結果をMarkdown形式に変換します。

公式MCPサーバーはURL抽出操作も提供しており、ページコンテンツをMarkdown形式で返し、明確な切り捨て制限(50,000文字)があります。

画像はAnySearchのAgent-Native Designを示しており、AIエージェント向けに設計され、構造化出力によりトークンの無駄を大幅に削減し、組み込みAPI、MCP、Skillをサポートすることを強調しています。左側はAIエージェント、右側には3つのボックス(MCP / Skill / API、Structured Markdown、Quality Scoring)があります。この図は文脈と密接に関連しており、文脈ではAnySearchのAIエージェントにおける応用、ランク付けや構造化された引き渡しなどの段階が紹介されており、この図はその設計特性とAIエージェントとの相互作用の方法を視覚的に示しています。

構造化された出力は、モデルに必要な作業量を削減できます。特に結果に以下が含まれている場合に有効です:

  • 明確なタイトル
  • ソースメタデータ
  • 日付
  • 異なる証拠ブロック
  • ファイルパス付きのコード
  • 標準化された単位
  • 検証用のURL

なぜ重複排除がトークン浪費を減らすのか

あるエージェントが同じイベントに関する10件の結果を受け取ったと仮定する。そのうち7件が同じ元のレポートを書き直したものであれば、コンテキストには7件の独立した確認情報ではなく、重複した主張が含まれることになる。

これにより3つの問題が生じる:

  1. 重複した素材がコンテキストスペースを消費する。
  2. モデルが重複を独立した裏付けとして誤って解釈する可能性がある。
  3. あまり知られていないが権威ある証拠が排除される可能性がある。

ソースベースの重複排除は、単にランキングの高いページを残すのではなく、独自の証拠を保持することを目的としている。

実用的なエージェントの検索応答は、ソース情報を可視化する必要がある。開発者は、5件の結果が5つの独立したソース、同じソースからの5件の共同発表、あるいは一次証拠と二次証拠の混合を表しているのかを知る必要がある。

トークン節約はパイプラインの結果であり、固定パーセンテージではない

原文では、低いトークン消費をAnySearchの利点として説明しているが、一般的なトークン削減率は公表されていない。

これは妥当であり、節約量は以下に依存する:

  • 元の結果数
  • ページの長さ
  • 重複率
  • 抽出品質
  • モデルのトークナイザー
  • 最大コンテキストサイズ
  • エージェントが再度検索するかどうか
  • 必要な引用深度
  • 保持される構造化メタデータの量

公平な評価は、最初の検索応答だけでなくタスク全体を測定すべきである。

有用な指標には以下が含まれる:

指標 測定内容
検索入力トークン 検索素材が消費するコンテキスト
エージェント総トークン 検索、推論、後続操作、

│ 最終生成 │
│ 検索呼び出し回数(ラウンドごと) │ 弱い検索が重複検索を引き起こすかどうか │
│ 異なるソース数 │ 重複排除後の証拠の多様性 │
│ 引用精度 │ 引用されたソースが関連主張を裏付けているか │
│ 回答の完全性 │ 応答が必要な次元をカバーしているか │
│ エンドツーエンドのレイテンシ │ タスクが利用可能になるまでに必要な時間 │
│ タスク成功率 │ エージェントが期待される目標を達成するか │

重要な証拠を省略した短い回答は最適化戦略ではない。回答品質とトレーサビリティを維持して初めて、トークン数の削減に価値が生まれる。

エージェント向けネイティブエンジニアリング特性

実際のプロダクション環境で使用される検索コンポーネントは、プロダクトデモではほとんど発生しない障害問題に対処しなければならない。

リソースソースは以下の特性を強調している:

  • タイムアウト処理
  • 自動フォールバック
  • マルチソースルーティング
  • APIアクセス
  • MCPサポート
  • スキルサポート
  • 構造化Markdown出力

公開MCPドキュメントは以下の機能もサポートする:

  • 汎用ウェブ検索
  • 垂直検索
  • 並列一括検索
  • ページ全体抽出
  • 匿名アクセス
  • オプションのAPIキー認証

この図は、エージェントと開発者向けの信頼性の高いリアルタイム構造化検索ツールAnySearchを紹介している。このツールはOpenClaw、Cursorなど既存のさまざまなエージェントに接続でき、セキュリティアラート、論文、証券データ、ウェブコンテンツ、法務テキスト、文書などの多様なソースにもアクセス可能で、独自のポリシーに基づいて最適な情報を選択する。このツールはエージェントに信頼できるリアルタイム構造化検索機能を提供し、開発者の既存エージェントの使用ニーズに適合するとともに、エージェントの運用を支えるために複数のソースからの情報を統合できる。

プロダクションチームは独自の制御手段を追加すべきである:

  • ソースごとのタイムアウト予算
  • バックオフ付きのリトライ機構
  • リクエストとコストの追跡
  • ソースのホワイトリストとブラックリスト
  • プロンプトインジェクションスキャン
  • PII(個人識別情報)と秘密情報のフィルタリング
  • 結果サイズ制限
  • キャッシュポリシー
  • 監査ログ
  • 高リスク判断に対する人間によるレビュー

検索出力は信頼されていない外部からの入力である。たとえクレンジングされたMarkdownテキストであっても、悪意のある命令、虚偽の記述、改ざんされたコンテンツを含む可能性がある。

検索はエージェントインフラストラクチャになりつつある

従来の検索はユーザーがページを見つけるのを支援する。一方、エージェント向け検索は異なる目標を持つ:推論と実行のために機械が利用可能な証拠を提供することである。

これにより設計の優先順位が変わる。

人間向け検索 エージェント向け検索
素早いブラウジング向けに最適化 機械による取り込み向けに最適化
リンクと要約 構造化された証拠
ユーザー自身で重複排除 システムが重複を減らすべき
ユーザーが有効期限に注意 日付が明確に表示されるべき
ユーザーが誰を信頼するか決定 ソースと品質シグナルが必要
ブラウジングは探索的であり得る 重複検索はトークンと時間を消費する
視覚的レイアウトが重要 安定した構造とMarkdownが重要

モデルがエージェントの証拠を用いた推論能力を決定する。検索層は、最初にどの証拠が利用可能かを決定する。

モデルの能力が向上するにつれて、検索品質の重要性は増すばかりである。強力なモデルは、弱いコンテキストに基づいても非常に説得力のある回答を生成できる。そのため、ソースの選択、鮮度、トレーサビリティは、エージェントの安全性と信頼性システムの一部となる。

自身のワークフローでAnySearchを評価する方法

開発者は、一つの公開ベンチマークや印象的なセキュリティスイートだけで検索プロバイダーを選択すべきではない。

代わりに、実際のシナリオに基づいて評価セットを構築すべきである。

あなたのエージェントが実行するタスク。

ステップ1:代表的なクエリを定義する

簡単なケースと難しいケースの両方をカバーする:

  • 現在のニュース
  • リポジトリコード
  • 地域のビジネスレコード
  • 学術論文
  • 規制情報
  • 多国籍データ
  • 相反するソースが存在する問題
  • 複数のサブ分野を必要とするクエリ

ステップ2:モデルを変更しない

各プロバイダーに対して同じモデル、プロンプト、ツール戦略、出力形式を使用する。

ステップ3:元の証拠をキャプチャする

モデルが要約する前に、返されたソースを保存する。そうしなければ、エラーが検索プロセスに起因するのか推論プロセスに起因するのか判断できない。

ステップ4:正確さだけでなく、より多くの次元を評価する

レイテンシ、総トークン数、重複検索呼び出し回数、カバレッジ、引用サポート、鮮度、失敗率を測定する。

ステップ5:高リスクの結果を人間がレビューする

金融、法律、セキュリティ、医療、コンプライアンス業務には専門家によるレビューが必要です。検索APIは証拠収集を改善できますが、専門的責任を負うことはできません。

ステップ6:障害動作のテスト

特定の情報源を無効化する、特定のルートを遅くする、不正な形式のコンテンツを返す、重複した結果を注入する。本番環境の信頼性は、検索が不完全な場合のシステムの動作に依存します。

よくある質問

AnySearchとは何ですか?

AnySearchは、AIエージェントや開発者向けに設計されたリアルタイム検索インフラストラクチャサービスです。ウェブ検索、垂直分野検索、バッチ検索、構造化出力を伴う全文抽出機能を提供します。

AnySearchは消費者向け検索エンジンですか?

ユーザーが検索を試せるウェブサイトはありますが、その主な位置付けはエージェント向けインフラストラクチャです。主要な統合方法は、API、MCP、インストール可能なスキルです。

AnySearchはAPIキーなしでも動作しますか?

公式のスキルとMCPドキュメントでは、匿名アクセスはレート制限とクォータが低くなるとされています。APIキーはオプションですが、通常の利用には推奨されます。

AnySearchはどのような垂直分野をサポートしていますか?

公開ドキュメントでは、金融、学術研究、セキュリティ、法律情報、コード、その他のカテゴリが挙げられています。エージェントは特定分野のパラメータを使用する前に、サポートされている分野のディレクトリを確認する必要があります。

AnySearchはトークン使用量をどのように削減しますか?

検索前にクエリをルーティングし、重複ソースを減らし、情報密度の高い結果を優先し、ページノイズを除去し、構造化されたMarkdown形式で返します。実際のトークン節約効果は、クエリの内容やエージェントのワークフロー全体に依存します。

76.4%のベンチマーク結果は独立検証済みですか?

このスコアはAnySearchによって報告され、元の記事でも再現されています。検証プロセスで完全な公開評価パッケージは見つからなかったため、この結果はベンダー報告の比較データとして扱うべきです。

AnySearchは専門的なデューデリジェンスの代わりになりますか?

いいえ。企業、法律、財務、公共リスク情報の収集には役立ちますが、専門家による身元確認、情報源の権威性、完全性、管轄権、解釈の検証が必要です。

AnySearchはオープンソースですか?

AnySearchスキルとMCPサーバーのコードベースは、Apache-2.0ライセンスで公開されています。ホスト型APIバックエンドは独立したサービスであり、これらのコードベースのライセンス範囲には含まれません。

関連ツール

  • AnySearch:AIエージェント向けのリアルタイム構造化検索インフラストラクチャ。
  • AnySearchスキル:ウェブ、垂直検索、バッチ検索、URLコンテンツ検索をサポートするインストール可能なエージェントスキル。
  • AnySearch MCPサーバー:AnySearchツールを互換性のあるエージェントに公開するMCP統合ソリューション。
  • Exa:AIアプリケーション向けに構築された検索、コンテンツ取得、クローリング、リサーチAPI。
  • Tavily:エージェントとRAGワークフロー向けのリアルタイム検索・抽出API。
  • Brave Search API:アプリケーションとAIシステム向けの独立型ウェブ検索API。
  • Model Context Protocol:AIアプリケーションを外部ツールやデータに接続するためのオープンプロトコル。

関連リンク

まとめ

AnySearchは、検索を人間が閲覧するためのページリストではなく、エージェントへの入力層として捉えます。汎用および垂直ソースにわたってクエリをルーティングし、複数のパスで検索し、証拠を並べ替えて重複排除し、ページノイズを除去し、API、MCP、またはスキル統合を介して構造化コンテンツを返します。

ソースコードの例は、この設計がプロダクションコードの発見、ローカル企業のデューデリジェンス、現在の複数市場データにとってなぜ重要なのかを示しています。いずれの場合も、エージェントは単なる関連リンクではなく、完全でタイムリーかつトレーサブルな証拠を必要とします。

Product Huntランキングとベンダー報告のベンチマーク結果により、AnySearchはテストに値しますが、チームはプロダクションの検索スタックを変更する前に、独自のクエリ、モデル、トークン計算、品質基準を使用して比較結果を再現する必要があります。

エージェントワークフローにおいて、モデルは証拠の処理方法を決定しますが、検索層は正しい証拠がモデルに届くかどうかを決定します。