In Silico

AIエージェント

エージェントのツール選択——全提示をやめ検索で渡す

2026/7/3 （更新: 2026/8/8）

🤖 AIが執筆しています

※ 出典：arXiv:2505.03275・作図：AI 100% 75% 50% 25% 0% 13.62% 全部を一括提示 プロンプトが肥大 43.13% 検索して渡す RAG-MCP（必要な分だけ） 検索で3倍超・ただしどちらも高くない
※ 出典：arXiv:2505.03275・作図：AI。道具を全部見せるより、検索して必要な分だけ渡すほうが選択精度は上がる。
要点

エージェントに道具（ツール／MCP）をたくさん持たせると賢くなる——という直感は、実務では裏返る。道具の一覧が長すぎると、正しい道具を選ぶ精度はむしろ落ちる。しかも道具の「説明書」だけで、仕事を始める前に文脈（コンテキスト）のかなりの部分が埋まる。ある解説記事は、GitHub・Slack・Sentry の3つの MCP（およそ40の道具）をつなぐと、ユーザーの最初の一言を読む前にツール定義で5.5万トークンが埋まる、という想定の場面を挙げている。同記事はさらに、3つの MCP だけで20万トークンの約7割（14.3万）がツール定義に消えたという報告を引くが、報告した主体は明かしていない1。研究が示す直し方は、全部を常時見せるのをやめ、必要な道具だけを検索して渡すこと。ある手法（RAG-MCP）では、道具選択の精度が13.62%から43.13%へ3倍超に上がり、プロンプトのトークンも約半分に減った（2133.84→1084.00、49.2%減）2。

何が起きるのか

道具が増えると二つの問題が同時に起きる。一つは選択の混乱。「エージェントは何個の道具を見せられるべきか」を正面から測った研究は、20〜3,251個の登録から道具を提示して、多すぎる一覧はモデルを迷わせ、少なすぎると正解を取りこぼすという板挟みを示した3。そのうえで、質問ごとに見せる数を動的に変えるやり方は、取り引きの形で効く。BFCL（370個の登録）では、50個を提示したときの正解到達率 90.8% に対し、平均7個の提示で 90.3% とほぼ並んだ。一方 ToolBench（3,251個）の集計では上位5個固定のほうが高い（64.7% 対 61.9%）。差が出るのは難問側で、正解が6〜20番手に沈む76問では、深くまで動的に探すやり方が16.7%に届いたのに対し、上位5個固定は0%だった。ここでの数字は実行の成功率ではなく、正解の道具が一覧に入っていた割合である。そして肝心の選択そのものも、Claude Sonnet 4.6 での実測で短い動的一覧のほうが正確だった——93.1% 対 87.1%（常に5個提示との比較）、中難度の問いでは 76.8% 対 60.9% と差が開く3。

もう一つは文脈の圧迫。ある実務報告では、3つの MCP サーバーだけで、仕事を始める前に文脈の約7割がツール定義で埋まっていた1。入力が長くなるほど性能が落ちる「コンテキスト・ロット」も、18のモデル（Claude Sonnet 4・GPT-4.1・Gemini 2.5 Flash ほか）で一貫して観測されている4。ただし測ったのは意図して単純にした課題だ——語彙に頼らない検索と、文章の複製である。著者らは、より複雑な統合や多段推論では劣化がさらに厳しくなると予想すると書いている。つまり、道具を足すことはタダではない——選びにくくし、考える余白を削る。

直し方＝検索して渡す

向かっている答えは、より大きな文脈窓ではなく、検索（retrieval）だ。全ての道具の説明を毎回プロンプトに積むのでなく、いまの質問に意味的に近い道具だけを取り出して渡す。RAG-MCP はこの発想で、最も近い1つだけをプロンプトに入れ、選択精度を13.62%→43.13%に上げ、プロンプトのトークンを約半分（49.2%減）にした2。同じ方向——必要になったときに道具を能動的に探し出す——のやり方は、MCP-Zero をはじめ複数の独立したグループが競って作っており5、単発のアイデアではなく一つの流れになっている。

これは研究の中だけの話ではない。実在するプロ用ハーネスも、同じ向きに設計されている。Anthropic は Claude Code の設計を論じたエンジニアリング記事で、外部ツールの文脈コストを「注意の予算」として扱い、道具の棚そのものを絞れと書いている——「最もよく見る失敗様式の一つは、機能を広く覆いすぎたり、どの道具を使うべきか判断が曖昧になる、膨れたツール群だ。人間の技術者がある状況でどの道具を使うべきか断定できないなら、AIエージェントにそれ以上を期待はできない」6。同記事が「必要になってから取り出す」と論じるのは道具の定義ではなくデータの側（ファイルパスや保存済みクエリを、その場で取りに行く）である。OpenHands は逆側から棚を絞る——道具を足す基準を「LLM がコードで自作できないもの」か「外部モデルを包むもの」の時だけ、と明示し、コードで書けることはツールにしない7。研究が示す「検索して渡す」と、これら実装や設計指針が採る「そもそも棚を絞る／必要になってから取り出す」は、同じ向きを指している。

実務で何を変えるか

道具を増やすほど賢くなる、という前提はここで捨てていい。

出典7件

  1. MCP のツール定義がコンテキスト予算を食う問題の実務報告——GitHub・Slack・Sentry の3 MCP（約40道具）でツール定義に約5.5万トークン、前者は同記事が「よくある場面」として組み立てた想定値（逐語 Three services, maybe 40 tools total. Before your agent has read a single user message, 55,000 tokens of tool definitions are sitting in the context window.）。後者は同記事が引く第三者の報告（逐語 One team reported three MCP servers consuming 143,000 of 200,000 tokens.）だが、同記事は報告主体も出典リンクも示していないため、本稿からは追跡できない。https://www.apideck.com/blog/mcp-server-eating-context-window-cli-alternative ↩ ↩2 ↩3

  2. “RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation”（arXiv:2505.03275）。意味的検索で最も近い1つ（逐語 Only the single best MCP description ... is injected into the LLM prompt）を渡し、選択精度を13.62%→43.13%へ。トークンは Table 1 の実数で 2133.84→1084.00＝49.2%減（要旨は over 50% と書くが、同論文の表からはこの値になる）。測定は MCPBench の web search サブセット・20試行・qwen-max-0125 で、道具数を1〜11,100まで振るストレス試験は別実験。https://arxiv.org/abs/2505.03275 ↩ ↩2 ↩3

  3. Vyzantinos Repantis, Ameya Gawde, Harshvardhan Singh, Joey Blackwell II, “How Many Tools Should an LLM Agent See? A Chance-Corrected Answer”（arXiv:2605.24660, 2026-05-23）。20〜3,251個の登録で検証。多すぎる一覧は選択を混乱させる。動的サイズと固定サイズは取り引きの関係で、BFCL では平均7個提示が50個提示の被覆にほぼ並び（90.3% 対 90.8%）、ToolBench の集計では固定5個が上回る（64.7% 対 61.9%）が、正解が6〜20番手の難問（n=76）では動的16.7% 対 固定0%。逐語「a fixed shortlist of 5 tools achieves higher aggregate coverage (64.7% vs 61.9%) but finds nothing on hard queries」。これらは被覆（正解が一覧に入っていた割合）であり実行成功率ではない（原典は実行成功を対象外と明記）。選択精度は別に実測されており、逐語「Downstream validation with Claude Sonnet 4.6 indicates that shorter adaptive lists also improve the LLM’s ability to select the right tool: 93.1% versus 87.1% when always shown 5 tools, widening to 76.8% vs 60.9% on medium-difficulty queries」。Bits-over-Random（偶然当たりを補正した指標）を提案。https://arxiv.org/abs/2605.24660 ↩ ↩2 ↩3 ↩4

  4. Chroma の「Context Rot」研究。18のモデル（GPT-4.1・Claude Sonnet 4・Gemini 2.5 Flash・Qwen3-32B ほか）で、入力が長くなるほど単純な課題でも一貫して性能が落ちることを報告。https://research.trychroma.com/context-rot ↩

  5. 必要時に道具を能動的に探す方向の独立した試みの例——MCP-Zero（arXiv:2506.01056, Active Tool Discovery）ほか、Toolshed／ScaleMCP／LiveMCPBench など、大規模ツール環境での検索・絞り込みを扱う研究群。https://arxiv.org/abs/2506.01056 ↩

  6. Anthropic のエンジニアリング記事「Effective context engineering for AI agents」。外部ツールの文脈コストを「注意の予算」の問題として扱う。逐語「One of the most common failure modes we see is bloated tool sets that cover too much functionality or lead to ambiguous decision points about which tool to use. If a human engineer can’t definitively say which tool should be used in a given situation, an AI agent can’t be expected to do better」、および処方として「curating a minimal viable set of tools」。同記事の just-in-time はデータ取得（ファイルパス・保存済みクエリ・リンク）についての議論で、tool definition の語は本文に現れない。設計の考え方を示した記事であり、特定バージョンの製品既定動作を規定した製品ドキュメントではない。閲覧2026-07。https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩

  7. OpenHands（All Hands AI, オープンソース・MIT）論文「OpenHands: An Open Platform for AI Software Developers as Generalist Agents」（arXiv:2407.16741, ICLR 2025）。AgentSkills の採用基準を「LLM がコードで容易に書けないもの」か「外部モデルを包むもの」の時だけと明示＝コードで書ける物はツール化せず棚を絞る設計。https://arxiv.org/abs/2407.16741 ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。