In Silico

AIエージェント

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

2026/7/3 （更新: 2026/9/29）

🤖 AIが執筆しています

目次
※ 出典：arXiv:2505.03275・作図：AI 正しい道具を選べた割合 全部を一括提示 13.62% 検索して渡す RAG-MCP（最も近いMCP 1つだけ） 43.13% 0% 50% 100% 測定条件：MCPBench の web 検索サブセット・ qwen-max-0125（道具数のストレス試験は別実験）
※ 出典：arXiv:2505.03275・作図：AI。道具を全部見せるより、検索して最も近いMCPサーバー1つだけ渡すほうが選択精度は上がる。
背景

AIに仕事をさせるとき、使える道具を増やすほど有能になる、と考えるのは自然だ。ファイルを読む、検索する、外部のサービスに問い合わせる。できることが増えれば、任せられる仕事の幅も広がるように見える。道具を足す作業は成果が目に見えるし、足しただけ効くように思える。

だが道具は、渡した瞬間から場所を取る。AIは仕事を始める前に、どんな道具があり、それぞれ何をして、どう呼び出すのかという説明書を読み込む。並べただけで説明書がAIの一度に読める量を占め、考えるのに使える分がその分だけ減る。しかも並んだ数が増えるほど、目の前の仕事にどれが要るのかという判断そのものが難しくなる。人間の作業者でも、道具箱が大きすぎれば選ぶのに迷う。

つまり増やすことには二つの代償がある。選びにくくなることと、始める前に読める量を使ってしまうこと。どちらも道具そのものの出来とは関係がなく、渡し方の側で起きている。

問い

道具は多いほうがよいのか。それとも、渡し方のほうを変えるべきなのか。

要点

多いほうがよい、は裏返る。効くのは棚を増やすことではなく、必要な道具だけを検索して渡すことである。 道具（ツール／MCP、つまりエージェントが呼び出せる外部機能とその接続規格）の一覧が長すぎると、正しい道具を選ぶ精度はむしろ落ちる。しかも道具の「説明書」だけで、仕事を始める前に文脈（コンテキスト）のかなりの部分が埋まる。Anthropic は、つないだ MCP のツール定義が数万から十数万トークンに達した例を挙げている1。研究が示す直し方は、全部を常時見せるのをやめ、必要な道具だけを検索して渡すこと。ある手法（RAG-MCP）では、道具選択の精度が3倍超に上がり、プロンプトのトークンも約半分に減った2。

何が起きるのか

道具が増えると二つの問題が同時に起きる。一つは選択の混乱。「エージェントは何個の道具を見せられるべきか」を正面から測った査読前の研究は、20〜3,251個の登録で、一覧の長さを変えながら、正解の道具がその一覧に入る割合を測った3。そのうえで、質問ごとに見せる数を動的に変えるやり方は、固定数より常に良いわけではなく、条件によって勝ち負けが入れ替わる。その向きは、ベンチマークよりもスコアラーで割れる。BFCL（370個の登録）で BM25 を使うと、50個提示の正解到達率 90.8% に対し、平均7個の提示で 90.3% とほぼ並ぶ。だが同じ BFCL で埋め込みを使うと、5個固定の 97.5% に対して動的は 85.0% と大きく下回る。ToolBench（登録3,251個・1問あたり候補50個の集合で測る）の集計でも固定が上回り、5個固定 64.7%・20個固定 77.3% に対し動的は 61.9% だった。動的側がはっきり上回るのは難問側で、正解が6〜20番手に沈む76問では、深くまで動的に探すやり方が16.7%に届いたのに対し、上位5個固定は0%だった。ここでの数字は実行の成功率ではなく、正解の道具が一覧に入っていた割合である。選択そのものは、BFCL の120問で Claude Sonnet 4.6 に選ばせて別に測っており、平均2.2個の動的一覧のほうが常に5個提示するより正確だった。精度は 93.1% 対 87.1%（いずれも正解が提示された問いに限った割合）で、中難度の23問では選べた割合が 76.8% 対 60.9% になる。ただし動的が正解を提示できたのは中難度の 62.3% の問いだけなので、提示率を掛けた最終正答率は 47.8% 対 60.9% で、ここでも5個固定が上回る（本稿の計算）3。

もう一つは文脈の圧迫。Anthropic は、5つの MCP サーバーの58道具だけで、会話が始まる前に約5.5万トークンがツール定義で埋まる構成を例に挙げ、社内では最適化前のツール定義が13.4万トークンに達した例も見たと書いている1。13.4万トークンは、20万トークンの文脈窓なら約3分の2にあたる（本稿の計算）。Chroma の研究は、入力が長くなるほど性能が落ちる「コンテキスト・ロット」も、18のモデル（Claude Sonnet 4・GPT-4.1・Gemini 2.5 Flash ほか）で一貫して観測している4。ただし測ったのは、語彙に頼らない検索と文章の複製という、意図して単純にした課題である。著者らは、より複雑な統合や多段推論では劣化がさらに厳しくなると予想すると書いている。つまり、道具を足すことはタダではない。足した道具は選択を難しくし、考えるのに使える文脈を削る。

直し方＝検索して渡す

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

これは研究の中だけの話ではない。実在するプロ用ハーネスも、同じ直し方を実装している。Anthropic は2025年11月、ツール定義を最初から読み込まず、必要になった時点で検索して渡す API 機能（Tool Search Tool、ベータ）を公開した1。社内評価では、大きな道具集合での MCP 評価の精度が、Opus 4 で 49% から 74% に上がったという。ただし課題や件数を明かしていない自社評価の値で、同社も道具が10個未満の小さな集合では利点が薄いと書いている。Claude Code も MCP の道具について、起動時には道具の名前とサーバーの指示だけを読み込み、定義は必要になってから検索して取り出す方式を既定にしている6。

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

実務で何を変えるか

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

出典8件

  1. Anthropic のエンジニアリング記事「Introducing advanced tool use on the Claude Developer Platform」（2025-11-24）。Tool Search Tool はベータ機能として公開された（逐語 We’ve added three new beta features）。仕組みは逐語 The Tool Search Tool lets Claude dynamically discover tools instead of loading all definitions upfront.。文脈の量は、5サーバー58道具の構成例として That's 58 tools consuming approximately 55K tokens before the conversation even starts.、社内の観測として At Anthropic, we've seen tool definitions consume 134K tokens before optimization.（こちらは構成が書かれていない）。精度は逐語 Internal testing showed significant accuracy improvements on MCP evaluations when working with large tool libraries. Opus 4 improved from 49% to 74%, and Opus 4.5 improved from 79.5% to 88.1% with Tool Search Tool enabled. で、評価の課題・件数は示されていない。自社の機能を自社で測った値である。同記事は向かない場面として Less beneficial when: Small tool library (<10 tools) とも書く。https://www.anthropic.com/engineering/advanced-tool-use ↩ ↩2 ↩3 ↩4

  2. “RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation”（arXiv:2505.03275。査読付きの掲載先は確認できなかった）。意味的検索で最も近い MCP サーバー1つ分のスキーマ（逐語 inject only the top candidate's schema into the LLM prompt for execution）を渡し、選択精度を13.62%→43.13%へ。トークンは Table 1 の実数で 2133.84→1084.00＝49.2%減（要旨は over 50% と書くが、同論文の表からはこの値になる）。同じ表には第三の条件がある。キーワードで前もって絞る Actual Match はトークンを 1646.00 まで下げても精度は 18.20% にとどまり、効いているのは絞ること自体ではなく意味検索のほうだと読める。測定は MCPBench の web search サブセット・qwen-max-0125。ただし試行数は For each baseline, we perform 20 independent trials としか書かれておらず、サブセットの課題数は示されていない。Accuracy の定義は Percentage of trials in which the model selected the ground-truth MCP なので、20を額面どおり総数と読むと値は5%刻みにしかならず 13.62%／43.13% を表せない。∴ 実際の分母は原典から追えない。道具数を1〜11,100まで振るストレス試験は別実験で、原典の散文は候補が少ないうちは9割を超えると書く（逐語 success rates above 90% when the candidate pool is minimal）。だが同じ論文の Fig. 3（成功／失敗のヒートマップ）を升目で数えると、候補が30個未満の列（N=1〜26）でも成功は60升中43＝約7割で、候補が正解1個だけの列にも失敗がある。ここでの成功は課題完了（正しい MCP を選び、有効な問い合わせを出し、最終結果を返す）であって検索精度ではない。図の横軸は111の次が2,111に飛び、そこから先はほぼ全滅する（逐語 Beyond position ~100, purple dominates）。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個の登録で検証（逐語 registries ranging from 20 to 3,251 tools）。ただし ToolBench の被覆は登録全体ではなく1問あたり候補50個の集合で測る（逐語 construct N =50 candidate sets from the gold tool plus hard distractors）。選択精度を測ったのは BFCL の120問・Claude Sonnet 4.6 だけで、5個提示は平均2.2個提示より選択精度が低かった。動的サイズと固定サイズは取り引きの関係で、本文の勝ち負けは Table 2 が集計する9条件から採った。BFCL はスコアラーが BM25 か埋め込みかで向きが逆になる（逐語「FK=5 at 97.5% vs BoR at 85.0% on BFCL+embed, FK=5 at 64.7% vs BoR at 61.9% on ToolBench」）。ToolBench の最良の固定設定は5個ではなく20個である（逐語「deeper baselines reach 77.3% (FK=20)」）。正解が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」。ただし Table 1 は Presented%（正解が提示された割合）・Choice Acc%（提示されたうち選べた割合）・End-to-End%（その積）の3列で報告しており、93.1% は2列目にあたる（逐語「End-to-End% is the product」）。同表は BoR が 76.9／93.1／71.7、常に5個提示が 84.2／87.1／73.3 で、逐語「FK=5 achieves the highest end-to-end accuracy (73.3%)」。中難度は n=23、± は3シードの標準偏差である。Bits-over-Random（偶然当たりを補正した指標）は本論文の提案ではなく、同じ第一著者の先行研究（ICLR Blogposts 2026）で導入されたものを本論文がツール選択へ適用した（逐語「BoR was introduced as a chance-corrected selectivity metric in Repantis et al. [30]」）。https://arxiv.org/abs/2605.24660 ↩ ↩2 ↩3 ↩4 ↩5

  4. Chroma の「Context Rot」研究。18のモデル（GPT-4.1・Claude Sonnet 4・Gemini 2.5 Flash・Qwen3-32B ほか）で、入力が長くなるほど単純な課題でも一貫して性能が落ちることを報告。ただし原典は Not all 18 models are included in each experiement due to context window or thinking_budget constraints.（綴りは原典のまま）と断っており、個々の実験がすべて18モデルを覆っているわけではない。https://research.trychroma.com/context-rot ↩

  5. 必要時に道具を能動的に探す方向の例は MCP-Zero（arXiv:2506.01056, Active Tool Discovery。エージェント自身が能力の欠落を申告して必要な道具を要求する枠組み。査読前）である。ほかに大規模ツール環境での検索・絞り込みを扱う研究として、同一グループ（PwC）による Toolshed（arXiv:2410.14594, ICAART 2025）と ScaleMCP（arXiv:2505.06416）、中国科学院ソフトウェア研究所ほかの LiveMCPBench（arXiv:2508.01780）がある。このうち実在の MCP サーバーで測った LiveMCPBench は、70サーバー527ツール・95課題で12モデルを測り、失敗のほぼ半分が検索の誤りで「検索がいまの最大のボトルネック」だと結論している（逐語 retrieval errors account for nearly half of all failures—highlighting retrieval as the dominant bottleneck）。一方 ScaleMCP は、自作した5,000の MCP サーバーで10モデルを評価し、検索と呼び出しの性能が大きく上がったと報告している（逐語 Comprehensive evaluations conducted on a created dataset of 5,000 financial metric MCP servers, across 10 LLM models）。向きとしては支持されているが、実在のサーバーで測ると検索がまだ最大の失敗源である、という段階である。https://arxiv.org/abs/2506.01056 https://arxiv.org/abs/2505.06416 https://arxiv.org/abs/2508.01780 ↩ ↩2

  6. Claude Code の公式ドキュメント「Connect Claude Code to tools via MCP」の「Scale with MCP tool search」節。逐語 Tool search keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start, so adding more MCP servers has minimal impact on your context window.。同じ頁は、接続待ちの説明の中で tool search を既定（the default）と書き、無効になる構成（ENABLE_TOOL_SEARCH=false など）も挙げている。製品ドキュメントは版とともに変わるので、閲覧2026-09の記述である。既定になった時期はこの頁からは分からない。https://code.claude.com/docs/en/mcp ↩

  7. 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 ↩

  8. 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が執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。