なぜ今、ツール検索が必要になってきたのか
MCPを使ったAIエージェント開発が広がるにつれて、ある問題が浮き彫りになってきました。エージェントが利用できるツールの数が増えれば増えるほど、「どのツールを使えばいいか」をモデルに判断させるためのコストが膨らんでいくのです。すべてのツール情報をプロンプトに詰め込むと、トークン消費が増え、処理が重くなり、最終的には精度にも影響が出てきます。
Nous Researchはこの課題に対して、BM25という情報検索の手法を組み合わせる形でTool Searchを設計しました。BM25はウェブ検索エンジンでも長年使われてきた古典的なアルゴリズムで、キーワードの出現頻度と文書の長さをもとに関連性をスコアリングします。シンプルながら実績があり、軽量に動く点が特徴です。
Tool Searchで何が変わるのか
これまでのエージェント設計では、利用可能なツールをすべてリストアップしてモデルに渡すのが一般的でした。ツールが10個程度なら問題になりませんが、MCPサーバーが増えて50個、100個と膨らんでくると話が変わります。全件を毎回渡し続ければ、トークン数が増加して推論コストが上がり、関係のない情報がノイズになって選択精度も落ちてきます。
Tool Searchはこの課題を、「使いそうなツールだけを絞り込んでから渡す」という発想で解決しようとしています。エージェントがタスクを受け取ると、まずBM25でツール候補を検索し、関連性の高いものだけをモデルに提示します。無関係なツールを省くことでトークンの無駄遣いが減り、モデルが迷う余地も少なくなるという仕組みです。
Anthropicが実施した評価では、Opus 4上での精度が49%〜74%向上したという結果が出ています。幅があるのはタスクの種類や環境によって効果が異なるためですが、それでも無視できない数字です。ツールの絞り込みという比較的シンプルな改善が、これほどの精度差を生み出すことは、ツール選択がいかにエージェントのボトルネックになっていたかを示しています。
具体的にどんな場面で効果を発揮するか
たとえば、クライアント業務の自動化のためにSlack、Notion、Google Calendar、GitHub、Stripe、SendGridなど複数のMCPサーバーを接続したエージェントを作ったとします。「今週の請求書を送って」というタスクが来たとき、エージェントがSlackやGitHubの情報を毎回処理していては効率的ではありません。Tool Searchがあれば、StripeとSendGrid周りのツールだけを先に絞り込んでから判断させることができます。
別の例として、調査系のエージェントを考えてみましょう。ウェブ検索、PDFリーダー、スプレッドシート操作、データベースクエリなど多様なツールを持たせている場合、「この論文の要点をまとめて」という指示に対して、PDFリーダー系のツールだけを候補として渡せれば、余計な選択肢で混乱することなくスムーズに動けます。ツール数が多いほど、この絞り込みの恩恵は大きくなります。
現時点での注意点
Tool Searchは現在Hermes Agentのオープンソース版に組み込まれていますが、価格情報や商用サポートの詳細は現時点で公開されていません。日本語対応や利用可能地域についても明記されていないため、実際に導入する前に最新のドキュメントを確認することをおすすめします。
また、BM25はあくまでキーワードベースの検索であるため、意味的に近いツールを見つける「セマンティック検索」ほどの柔軟性はありません。ツール名や説明文の書き方が検索精度に影響する可能性があるため、MCPサーバーの設計段階でツールの説明文をきちんと整えておくことが重要になりそうです。
フリーランスへの影響
今回のTool Searchは、MCPを使って複数のツールを連携させたAIエージェントを自分で構築しているフリーランスエンジニアや、LLMアプリを受託開発している方に特に関係のある話です。ツール選択の精度が上がれば、エージェントの完成度が高まり、クライアントへの納品品質にも直結します。
トークン消費の削減という観点では、APIコストに直接影響します。エージェントを長時間・高頻度で動かすほど、ツールの絞り込みによる節約効果は積み重なっていきます。大規模なエージェントシステムを扱う案件では、コスト見積もりの精度も上がるかもしれません。
一方で、MCPをまだ使っていない、あるいはツール数が少ないシンプルなエージェントを使っている方には、今すぐ大きな影響はないでしょう。AIエージェント開発に取り組み始めてから、ツールの増加に伴って必要性を感じてきたタイミングで検討するくらいの温度感が現実的です。
コメント