検索は、AIエージェントが利用できる最も重要な外部能力の一つとなっています。強力なモデルは優れた推論を行えますが、一度も検索したことのない事実を回復することはできず、証拠なしに最新情報と古い報道を区別することも、欠落した企業記録を確実に推測することもできません。AnySearch...
検索は、AIエージェントが利用可能な最も重要な外部機能の一つとなっている。強力なモデルは優れた推論が可能だが、一度も検索したことのない事実を復元することはできず、証拠に基づいて最新情報と古い報道を区別することも、欠落している企業記録を確実に推測することもできない。
AnySearchはこの問題を、ユーザー向けの検索ページではなく、エージェント向けのインフラストラクチャとして捉えている。単にリンク、タイトル、短い抜粋を返すのではなく、クエリを関連するウェブまたは垂直ソースにルーティングし、重複や低価値なコンテンツを除去し、有用な情報を抽出して、モデルの推論コンテキストに直接投入できる構造化されたレスポンスを提供する。
本製品は、2026年7月6日付でProduct Huntのデイリーおよびウィークリーランキングで首位を獲得した。発表時の紹介では、API、MCPサーバー、またはインストール可能なエージェントスキルを通じて、リアルタイムでフィルタリング、重複除去、構造化された情報を提供することが強調されている。
本稿では、このようなエージェント向け検索ワークフローが従来の検索APIとどのように異なるかを説明し、元のレポートで示されたサンプルを詳細に解説するとともに、実用的なインストールおよび評価ガイドを提供する。
ベンチマークに関する注記： 以下の精度およびレイテンシデータはすべて、ソース記事で再現されたAnySearchの比較結果に基づく。本バージョンでレビューした公開資料には、完全な評価コード、生の出力、評価プロンプト、または統計分析は含まれていない。これらのデータは、独立した再現ベンチマークではなく、ベンダー報告の結果として扱われたい。
人間は結果ページを閲覧し、広告を無視し、重複記事を認識し、どのリンクが注目に値するかを判断できる。
一方、エージェントは各結果をインプットとして受け取ることが多く、これには複数のコストが伴う：
問題は検索の精度だけでなく、返される情報の形態と密度にもある。
したがって、実用的なエージェント検索システムは、情報をモデルに渡す前に3つの質問に答えるべきである：
AnySearchはまさにこれらのステップを中心に設計されている。
AnySearchは2026年7月6日にProduct Huntのデイリーおよびウィークリーランキングで第1位を獲得した。Product Huntはこれを次のように説明している：
エージェントと開発者から信頼されるリアルタイム構造化検索。並列検索ソースからフィルタリングおよび重複除去された情報を取得する。
ソース記事ではまた、3つのベンチマークグループから構築された300問の評価セットが紹介されている：
記事では、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% |
FreshQAは、現在または変化する情報に依存する質問を評価する。WebWalkerQAは、複数のページにまたがってサイトを閲覧し、証拠を特定することに焦点を当てている。両方を組み合わせることは、単なる浅いリンクリスト以上のものを必要とするエージェントにとって非常に有用である。
FRAMESはソース記事の総合評価に含まれているが、記事で示されたベンチマーク別のグラフは、総合スコアに加えてFreshQAとWebWalkerQAのみを表示している。
レイテンシグラフは、平均比較とWebWalkerQAサブセットの両方の次元で、AnySearchの値が低いことを示している。
| 検索システム | 平均レイテンシ値 | WebWalkerQAレイテンシ値 |
|---|---|---|
| AnySearch | 48.0 | 76.5 |
| Brave Search | 68.9 | 133.0 |
| Parallel | 77.4 | 145.6 |
元の画像では単位が明示されていないため、表は報告された数値をそのまま保持し、秒やミリ秒に変換していない。
AnySearchは現在、3つの主要な統合方法をサポートしている：
公式GitHubリポジトリは、Apache-2.0ライセンスのスキルおよびMCPサーバーを提供している。両方とも、汎用ウェブ検索、垂直検索、並行バッチ検索、および全文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)
公式リポジトリでは、メインブランチから未公開の変更を直接取得するのではなく、固定バージョン（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 /.skills/anysearch
# 共有エージェントロケーション
mv anysearch-skill-2.1.0 ~/.agents/skills/anysearch
正確なディレクトリは、エージェントプラットフォームとその現在のスキル検出ルールに依存します。
公式スキルおよびMCPドキュメントによると、匿名アクセスにはレート制限が低く設定されています。APIキーは任意ですが、より安定した、あるいはより多くの利用量を得るために推奨されます。
APIキーをパブリックリポジトリにコミットしないでください。環境変数、キーマネージャー、または無視されるローカル設定ファイルに保存してください。
元記事の最初のテストでは、エージェントにチュートリアルではなく、実際の本番環境で使用されるGo製APIレート制限実装を探すよう要求しました。
プロンプトは以下の通りです：
現在、GoでAPIレート制限機能を実装するプロジェクトを構築しています。チュートリアルは必要ありません。実際のオープンソースプロジェクトから、本番環境で使えるコードを見つけてください。
専用の検索ワークフローがない場合、このエージェントは一般的なリンクや断片的なコードスニペットを返したと報告されています。このような結果は概念を説明するには役立つかもしれませんが、開発者が完全な実装コンテキストを必要とする場合には、有用性は限定的です。
AnySearch支援による実行では、より明確な呼び出しチェーンと実際のコードベースからの素材を含む、より構造化されたコード指向の結果が返されました。
この違いは非常に重要です。なぜなら、本番コードとは単なるアルゴリズム以上のものだからです。有用な検索結果は、エージェントが以下を確認するのに役立つはずです：
見た目は美しい関数を抽出しても、そのコンテキスト上の前提を見落とすようなコード検索は、実装エージェントを誤った方向に導く可能性があります。
どの検索プロバイダーを使用する場合でも、より明確なクエリによって結果が改善されます：
本番コードでAPIレート制限を実装している、現在もメンテナンスされているオープンソースのGoプロジェクトを探しています。
要件：
- リポジトリと正確なファイルパスを返すこと。
- 実際のサーバーやゲートウェイで使用されているコードを優先すること。
- 初期化とリクエストフローのコンテキストを含むこと。
- アルゴリズム、バックエンドストレージ、テスト、ライセンスを示すこと。
- チュートリアルコードベースやコピーされたコードスニペットを除外すること。
- 最近の関連コミットの日付を明記すること。
検索システムは証拠を提供する必要があります。コーディングエージェントはコードを適応させる前に、リポジトリ、ライセンス、テスト、セキュリティ上の前提、および現在のメンテナンス状況を確認する必要があります。
2つ目のテスト
同じ企業調査の要件について、AnySearchとExaを比較しました。
両レポートとも、基本的な公開企業情報の提示に関しては良好な結果を示しました。主な違いはリスクセクションに見られました。
報告によると、AnySearchは現地で公開されたコンプライアンス記録やプラットフォーム上の告知を発見しましたが、これらはExaが生成したレポートには含まれていませんでした。情報源はこの違いを、言語モデル自体ではなく、中国の垂直データソースへのアクセスに起因するとしています。
この例は、企業調査における一般的な限界を浮き彫りにしています。グローバルなウェブインデックスは、組織の公式ウェブサイト、国際的な報道、英語のデータベースをカバーするのには優れているかもしれませんが、地域の規制、裁判所、苦情、またはプラットフォーム記録を見落とす可能性があります。
デューデリジェンスエージェントは、以下のような複数のカテゴリを明示的に検索する必要があります：
重要なお知らせ： 検索支援によるデューデリジェンスは、専門家による法律、財務、またはコンプライアンスレビューに代わるものではありません。記録は不完全である可能性があり、名称が混同される可能性もあり、自動生成された要約が証拠を誤って解釈する可能性もあります。
3つ目のテストでは、AnySearchに以下の内容を含む世界のエネルギー市場レポートの作成を依頼しました：
情報源が示す出力結果には、地域別の在庫詳細、欧州の電力価格比較、排出データが含まれていました。このレポートでは、米国エネルギー情報局（EIA）が7月9日に発表したデータや、欧州の7月12日付けの日前電力価格など、最近の情報が引用されていました。
この図は文書内のテスト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検索ではなく、複数の独立したデータ経路が含まれていることを認識する必要があります。
信頼性の高い実装では、以下を達成すべきです：
現在のデータには常にタイムスタンプを含める必要があります。レポートが基礎となる測定の公開時期とそのカバー期間を説明していない場合、「最新」という言葉は無意味です。
中核となる設計の主張は、AnySearchがエージェントの動作に基づいて検索パイプラインを再構築するという点です。
ソースコードに示されるフローは5つの段階で構成されています：
システムはまず、クエリにどのような種類の証拠が必要かを識別します。
企業背景クエリには、登記記録、特許、法律データベース、苦情プラットフォームが必要な場合があります。コード関連の問題はコードリポジトリとドキュメントにルーティングすべきです。エネルギー市場クエリには、公式の在庫データや電力市場データが必要な場合があります。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
これは、すべてのリクエストを1つの汎用インデックスで処理する方法とは大きく異なります。
AnySearchは、一般検索に加えて、以下の分野を含む20以上の垂直カテゴリをサポートするとしています：
公開MCPインターフェースには領域ディレクトリメソッドが含まれています。エージェントは、サポートされていないフィルターを自ら作成するのではなく、有効な領域とパラメータスキーマを要求する必要があります。
複数の領域にまたがる質問は、複数の独立した検索を開始できます。MCPサーバーは1～5個のクエリオブジェクトのバッチ実行をサポートしており、あるブランチの失敗が他のブランチの実行をブロックすることはありません。
並列検索は総待機時間を短縮できますが、集約層が急速に出現する低品質の結果が、より遅い権威ある結果を押しのけるのを防ぐことができる場合に限ります。
証拠。
原文では3つのソートのアイデアが提案されています：
その目標は、コンテンツが言語モデルに入力される前により多くのフィルタリングを行うことです。
これは、大量の結果セットを返し、モデル自身に重複排除を行わせるパイプラインとは異なります。事前フィルタリングはトークンを節約できますが、別の責任を生み出します：ソートシステムは、少数のソースや重要な矛盾する記録を黙って削除してはなりません。
ソート後、AnySearchは主なコンテンツを抽出し、ページノイズを除去し、結果をMarkdown形式に変換します。
公式MCPサーバーはURL抽出操作も提供しており、ページコンテンツをMarkdown形式で返し、明確な切り捨て制限（50,000文字）があります。
構造化された出力は、モデルに必要な作業量を削減できます。特に結果に以下が含まれている場合に有効です：
なぜ重複排除がトークン浪費を減らすのか
あるエージェントが同じイベントに関する10件の結果を受け取ったと仮定する。そのうち7件が同じ元のレポートを書き直したものであれば、コンテキストには7件の独立した確認情報ではなく、重複した主張が含まれることになる。
これにより3つの問題が生じる：
ソースベースの重複排除は、単にランキングの高いページを残すのではなく、独自の証拠を保持することを目的としている。
実用的なエージェントの検索応答は、ソース情報を可視化する必要がある。開発者は、5件の結果が5つの独立したソース、同じソースからの5件の共同発表、あるいは一次証拠と二次証拠の混合を表しているのかを知る必要がある。
原文では、低いトークン消費をAnySearchの利点として説明しているが、一般的なトークン削減率は公表されていない。
これは妥当であり、節約量は以下に依存する：
公平な評価は、最初の検索応答だけでなくタスク全体を測定すべきである。
有用な指標には以下が含まれる：
| 指標 | 測定内容 |
|---|---|
| 検索入力トークン | 検索素材が消費するコンテキスト |
| エージェント総トークン | 検索、推論、後続操作、 |
│ 最終生成 │
│ 検索呼び出し回数（ラウンドごと） │ 弱い検索が重複検索を引き起こすかどうか │
│ 異なるソース数 │ 重複排除後の証拠の多様性 │
│ 引用精度 │ 引用されたソースが関連主張を裏付けているか │
│ 回答の完全性 │ 応答が必要な次元をカバーしているか │
│ エンドツーエンドのレイテンシ │ タスクが利用可能になるまでに必要な時間 │
│ タスク成功率 │ エージェントが期待される目標を達成するか │
重要な証拠を省略した短い回答は最適化戦略ではない。回答品質とトレーサビリティを維持して初めて、トークン数の削減に価値が生まれる。
実際のプロダクション環境で使用される検索コンポーネントは、プロダクトデモではほとんど発生しない障害問題に対処しなければならない。
リソースソースは以下の特性を強調している：
公開MCPドキュメントは以下の機能もサポートする：
プロダクションチームは独自の制御手段を追加すべきである：
検索出力は信頼されていない外部からの入力である。たとえクレンジングされたMarkdownテキストであっても、悪意のある命令、虚偽の記述、改ざんされたコンテンツを含む可能性がある。
従来の検索はユーザーがページを見つけるのを支援する。一方、エージェント向け検索は異なる目標を持つ：推論と実行のために機械が利用可能な証拠を提供することである。
これにより設計の優先順位が変わる。
| 人間向け検索 | エージェント向け検索 |
|---|---|
| 素早いブラウジング向けに最適化 | 機械による取り込み向けに最適化 |
| リンクと要約 | 構造化された証拠 |
| ユーザー自身で重複排除 | システムが重複を減らすべき |
| ユーザーが有効期限に注意 | 日付が明確に表示されるべき |
| ユーザーが誰を信頼するか決定 | ソースと品質シグナルが必要 |
| ブラウジングは探索的であり得る | 重複検索はトークンと時間を消費する |
| 視覚的レイアウトが重要 | 安定した構造とMarkdownが重要 |
モデルがエージェントの証拠を用いた推論能力を決定する。検索層は、最初にどの証拠が利用可能かを決定する。
モデルの能力が向上するにつれて、検索品質の重要性は増すばかりである。強力なモデルは、弱いコンテキストに基づいても非常に説得力のある回答を生成できる。そのため、ソースの選択、鮮度、トレーサビリティは、エージェントの安全性と信頼性システムの一部となる。
開発者は、一つの公開ベンチマークや印象的なセキュリティスイートだけで検索プロバイダーを選択すべきではない。
代わりに、実際のシナリオに基づいて評価セットを構築すべきである。
あなたのエージェントが実行するタスク。
簡単なケースと難しいケースの両方をカバーする：
各プロバイダーに対して同じモデル、プロンプト、ツール戦略、出力形式を使用する。
モデルが要約する前に、返されたソースを保存する。そうしなければ、エラーが検索プロセスに起因するのか推論プロセスに起因するのか判断できない。
レイテンシ、総トークン数、重複検索呼び出し回数、カバレッジ、引用サポート、鮮度、失敗率を測定する。
金融、法律、セキュリティ、医療、コンプライアンス業務には専門家によるレビューが必要です。検索APIは証拠収集を改善できますが、専門的責任を負うことはできません。
特定の情報源を無効化する、特定のルートを遅くする、不正な形式のコンテンツを返す、重複した結果を注入する。本番環境の信頼性は、検索が不完全な場合のシステムの動作に依存します。
AnySearchは、AIエージェントや開発者向けに設計されたリアルタイム検索インフラストラクチャサービスです。ウェブ検索、垂直分野検索、バッチ検索、構造化出力を伴う全文抽出機能を提供します。
ユーザーが検索を試せるウェブサイトはありますが、その主な位置付けはエージェント向けインフラストラクチャです。主要な統合方法は、API、MCP、インストール可能なスキルです。
公式のスキルとMCPドキュメントでは、匿名アクセスはレート制限とクォータが低くなるとされています。APIキーはオプションですが、通常の利用には推奨されます。
公開ドキュメントでは、金融、学術研究、セキュリティ、法律情報、コード、その他のカテゴリが挙げられています。エージェントは特定分野のパラメータを使用する前に、サポートされている分野のディレクトリを確認する必要があります。
検索前にクエリをルーティングし、重複ソースを減らし、情報密度の高い結果を優先し、ページノイズを除去し、構造化されたMarkdown形式で返します。実際のトークン節約効果は、クエリの内容やエージェントのワークフロー全体に依存します。
このスコアはAnySearchによって報告され、元の記事でも再現されています。検証プロセスで完全な公開評価パッケージは見つからなかったため、この結果はベンダー報告の比較データとして扱うべきです。
いいえ。企業、法律、財務、公共リスク情報の収集には役立ちますが、専門家による身元確認、情報源の権威性、完全性、管轄権、解釈の検証が必要です。
AnySearchスキルとMCPサーバーのコードベースは、Apache-2.0ライセンスで公開されています。ホスト型APIバックエンドは独立したサービスであり、これらのコードベースのライセンス範囲には含まれません。
AnySearchは、検索を人間が閲覧するためのページリストではなく、エージェントへの入力層として捉えます。汎用および垂直ソースにわたってクエリをルーティングし、複数のパスで検索し、証拠を並べ替えて重複排除し、ページノイズを除去し、API、MCP、またはスキル統合を介して構造化コンテンツを返します。
ソースコードの例は、この設計がプロダクションコードの発見、ローカル企業のデューデリジェンス、現在の複数市場データにとってなぜ重要なのかを示しています。いずれの場合も、エージェントは単なる関連リンクではなく、完全でタイムリーかつトレーサブルな証拠を必要とします。
Product Huntランキングとベンダー報告のベンチマーク結果により、AnySearchはテストに値しますが、チームはプロダクションの検索スタックを変更する前に、独自のクエリ、モデル、トークン計算、品質基準を使用して比較結果を再現する必要があります。
エージェントワークフローにおいて、モデルは証拠の処理方法を決定しますが、検索層は正しい証拠がモデルに届くかどうかを決定します。
