Claude Code の2.1.140台で導入されたMCP Tool Searchについて、筆者は「コンテキスト95%削減」という公式の数字を当初マーケティング寄りに受け取っていた。MCPの定義をJITで取得するだけで、そこまで変わるものか。半信半疑のままアップデートし、MCPサーバを7台繋いだ自分の環境で殴ってみた結果、実測の削減幅は89.4%だった。95%には届かなかったが、MCPを多数繋いでいる開発者にとっては運用設計の前提が変わる規模の改善だ。本稿では作動条件、実測ログ、精度の変化、チーム運用での注意点を整理する。
そもそもMCPの何が問題だったか
MCPサーバを増やすほどコンテキストが膨らむ、というのはMCPユーザにとって既知の課題だ。改めて整理すると、Meta MCP・Shopify・Higgsfield・Notion・Stripeを同時接続した場合、ツール定義だけで12K前後のトークンを消費する。Claude Codeの公式エンジニアリングチームが公開している数字に近い。筆者の手元は7台接続で約14.2Kだった。
問題はその先にある。Claudeは「使うかわからないツール群」の説明書きを毎ターン読まされ続け、注意機構が散る。実際、ツール選択を間違える頻度が体感で上がっていた。Vim時代に .vimrc を肥大化させすぎてプラグインが互いに干渉する状況とよく似た構造的問題だ。
Tool Searchの作動条件
公式ドキュメントによれば、MCPツール記述がコンテキストの10%を超えたタイミングで自動的にTool Searchモードへ切り替わる。閾値以下では従来通り全ロード方式が継続する。これは意外と重要な仕様で、MCPを2〜3台しか接続していない開発者にはそもそも介入してこない。「MCPを増やしすぎた人だけが救われる」機能、と位置づけるのが正確だ。
検索アルゴリズムはBM25と意味類似度のハイブリッド構成。BM25は自然言語クエリと相性がよく、「Slackにメッセージを投げて」のような表現を直接マッチングする。一方で「外部に通知を出す手段」といった曖昧な表現は意味類似度側が拾う。検索屋から見ても標準的で素直な設計に近い。
筆者の環境での実測ログ
接続中のMCPサーバは7台。Slack、Notion、GitHub、Linear、Stripe、Sentry、自作のドキュメントMCP。Tool Searchを切った状態でセッション開始時のコンテキスト消費を計測すると、ツール定義だけで14,217トークン。Tool Searchありで再計測すると、初期消費は1,503トークンまで落ちた。削減率89.4%。
95%には届かなかったが、これでも十分に効く。空いた12.7Kはそのままタスク本体に使える。長いコードベースを読ませる用途では、この差が結果に効いてくる。具体的には、筆者のRailsアプリ（約4.1万行）を解析させる際、Tool Searchなしだと2回目以降のターンで早めに圧縮が走っていたのが、Tool Searchありでは5ターン後でも余裕がある状態だった。
精度はどう変わるか
公式ベンチではOpus 4.5使用時、MCP関連評価の正答率が79.5%から88.1%へ上昇している。筆者のローカルでは試行回数が少なく統計的な有意性までは言えないが、「Slackに送る系」のタスクで、隣接ツール（別MCPの似た名前の関数）を間違って呼ぶケースがほぼ消えた。体感的にはストレスが減る、というのが一番正確な表現だ。
副次的な含意として、ツール記述の書き方ガイドラインが今後シビアになる、と筆者は読んでいる。Tool Searchが拾える文章をMCPサーバ側で書けないと、検索ヒットせず「あるのに呼ばれない」事態が起きる。serverのinstructionsフィールドの書き味が、MCP開発者の腕の見せどころになっていく。
設定のオン・オフ
無効化したい場合は enable_tool_search をfalseにすればよい。筆者は当面オンのまま運用する予定だ。ただし、社内ツールを頻繁に切り替える用途では明示ロードのほうが安定する局面もありそうだ。職場のチームで運用するなら、最初の2週間は片方を有効、もう半分を無効にしてA/Bを取るのが現実的だろう。
チームで導入する際の注意点
業務利用では、いくつか気をつける点がある。まず、Tool Searchが有効でも「使うはずのツールが呼ばれない」事故が起きる可能性がある。検索クエリにヒットしないとロードされないからだ。筆者は3週間と4日ほど運用した中で2回これに引っかかった。具体的には「PRをクローズして」のような短い指示で、GitHub MCPが拾われずに別のツールが優先された。
対策はシンプルで、指示の中に「GitHub経由で」のようにサービス名を含める。冗長に感じるかもしれないが、再現性は明らかに上がる。検索結果に依存する以上、人間側の言葉選びがプロンプト品質に直接効いてくる構造になった。
もう1つ、初回ターンの待ち時間がわずかに増える。検索インデックスのロードがあるからだ。筆者の手元では平均でセッション開始時に0.8〜1.2秒。気にならない範囲だが、瞬発的な対話を多用する人には引っかかるかもしれない。
既存のMCP運用との比較
以前の運用では、筆者はMCPサーバを4台に絞っていた。コンテキストへの圧迫を避けるためだ。Tool Searchがある今、その制約はほぼ消えた。実験的に、用途別MCPを13台繋いだ状態でも、初期コンテキストは2,500トークン弱に収まっている。数字で見ると驚くほどの変化で、運用設計の前提が変わる規模だ。
特に効くのは「使うかわからないが、繋いでおきたい」系のMCP。月に1〜2回しか使わない社内ドキュメント検索用MCPを、常時接続しても罪悪感がない。「念のため繋いでおく」が許容される世界、と言えば近い。
今回の推奨アクション
- Claude Codeを2.1.140台へ更新し、MCPツール定義が10%閾値を超えているか確認する
- 接続数が4台以上の環境では
enable_tool_searchをオンのままセッション初期トークンを実測する - 業務利用ではプロンプト中にサービス名を明示し、Tool Search漏れを回避する
- MCPサーバの instructions フィールドを検索ヒットしやすい記述に整える
Tool Searchは派手な機能ではない。だが「MCPを増やすほど遅くなり、雑になる」という長年の摩擦を1段階下げてくれる。筆者の感覚では、これでようやくMCPは「便利な道具」から「常時繋いでおく前提のインフラ」へ位置づけが変わった。次のステップはサーバ側の検索メタデータ標準化で、そこが整理されればエコシステム全体の生産性がもう一段上がるはずだ。
