「MCPは増やすほど賢くなる」は誤解。Microsoftが示した3つの劣化メカニズム

「MCP（Model Context Protocol、AIに外部ツールを橋渡しする規格）を増やすほどAIが賢くなる」と感じる瞬間があります。新しいMCPを入れて、Claude Codeが昨日までできなかったことをやってのけたとき、これは正しい設計の方向だと信じてしまう。

私もそうでした。Claude Codeを本格的に使い始めて2ヶ月、MCPは15個を超えていた。やれることが増えていく感覚は、確かに気持ちよかったんですよ。

ところが先週、Claude Codeが「動作確認のためにブラウザを開きます」と宣言したまま、2分間止まりました。最後に返ってきたのは「使うべきツールを判断できませんでした」の一行。MCPが多すぎて、何を呼ぶか決めきれなかったわけです。

2026年6月14日、ITmediaがMicrosoftの公式解説をもとに記事を掲載しました。「MCPを増やすほど賢くなるは誤解」という趣旨で、私の体感と一次解説がようやく一致した瞬間でした。

この記事を読み終わったあとに、今週末やる3つのことが決まります

• 自分のMCPを15分で棚卸しできる手順を手に入れる
• 削除判定の3問を、Claude Codeの設定ファイルに当てはめられる
• アンチパターン3つを踏まないチェックリストが手元に残る

なぜ「MCPは増やすほど賢くなる」と錯覚してしまうのか

新しいMCPを入れたら、新しいことができるようになる。この事実は確かに正しいです。問題は、その「事実」をそのまま「賢くなった」と受け取ってしまう感覚の方にあります。

2ヶ月前の私のMCP環境を書き出すと、こうなっていた。GitHub・Slack・Notion の3個だけ。これで仕事の8割は回っていたんですよ。Claude Codeとの会話も軽快で、応答速度に不満は一切なかった。

1ヶ月前、Playwright・Stripe・SendGrid・Cloudflare KV・Vercel を追加して8個に。新機能を使ったタスクが片付くたび、「入れてよかった」が積み上がる体験でした。

2週間前には15個を超えていた。Supabase・Linear・Figma・Anthropic Workbench・Cloudflare R2・自作の日報MCP。新着MCPを試しては「とりあえず置いておく」運用が常態化していたわけです。

ここまでは確かに「やれることが増えた」状態でした。理由はシンプルで、追加した直後の数日は、新しくできるタスクが目に入りやすいから。手元の検証範囲では、MCP追加直後は明確に「賢くなった感」がありました。

落とし穴は、感覚の地点が「直後の数日」で止まってしまうところにあります。長期で測ると、別のグラフが立ち上がってくる。MCPの数が一定を超えてから、Claude Code の応答が遅くなり、判定ミスが目立ち始めたんです。

「とりあえず動かす」が信条の私ですら、この罠にはきれいにハマりました。これは個人の運用センスというより、MCPという仕組みが構造的に抱えている性質に近いと感じています。

参考までに、私が「賢くなくなった」と気づいた最初のサインを書いておくと、こうでした。Claude Codeに「テスト失敗の原因を調べて」と頼む。以前は3〜4ターンで原因特定まで届いたのに、6〜7ターンに延びていた。一つひとつの判断は正しいんですが、ターン数が増えた分だけ私の集中力が削られていく。「あれ、最近遅いな」がMCP過多のサインだと、後になって理解しました。

Microsoftが指摘した3つの劣化メカニズム

ITmedia経由でMicrosoftの公式解説に触れた。MCPツールを増やすことで起きる劣化は、3つに整理されていたようです。一次URLが私の手元で取れていないため、ここでは「報じられた事実」フレームで紹介します。本筋の妥当性は手元検証と一致しました。

1つ目: コンテキスト圧迫

LLM（大規模言語モデル）はMCPツールの「名前・説明文・引数仕様」を、システムプロンプト内で受け取ります。MCP1個につき、数百から数千トークンを消費する設計です。15個入れると、本題に入る前にコンテキストの相当部分が、ツール定義だけで埋まってしまう。

手元で測った範囲では、MCP15個入りのClaude Codeはコンテキスト残量が3割を切ることがありました。会話が長引くと、肝心の作業履歴が押し出される現象も起きていた。これは記憶喪失ではなく、ツール定義に席を奪われたという話です。

2つ目: 意味的衝突

似た目的のMCPが複数あると、LLMは「どれを呼ぶべきか」を判定しきれなくなります。NotionとGoogle Docs両方を入れた直後から、貼り先の確認が毎回入るようになった。

決め打ちで動いていたフローが、選択肢過多で迷い始めた瞬間でした。「やってみますね」が「どちらに貼りますか」に変わると、対話の摩擦が一気に増えるわけです。

3つ目: 誤選択誘発

ツール数が一定を超えると、LLMの選択精度が落ちる傾向があるとされています。Microsoftの解説では、「ツール定義が長いほどLLMは末尾を見落とす」という趣旨が示されていたようです。

私の体験で言うと、15個入れたMCPの13番目に登録した便利ツールが、肝心なときに呼ばれない現象を実際に経験した。「使えるはずなのに使われない」のは、機能の欠陥ではなく、配置の順番が悪い場合があるんですね。

これら3つは、それぞれ別個に動くのではなく、足し算で効いてきます。コンテキスト圧迫が選択精度を下げ、意味的衝突がさらに迷いを呼び込む。連鎖を切るには、入口で数を絞るのが一番早い。

MCPを15個から5個に減らしたら、Claude Codeが1.5倍速くなった

「とりあえず動くもん作りましょう」は今も私の信条です。MCPに関してだけは、「とりあえず入れる」が裏目に出ました。15個から5個へ減らした過程を、具体的に共有します。

最初にやったのは、自宅環境のMCP全部を紙に書き出す作業です。書き出してみると、こんな顔ぶれでした。

GitHub・Slack・Notion・Google Docs・Playwright・Stripe・SendGrid・Cloudflare KV・Cloudflare R2・Vercel・Supabase・Linear・Figma・Anthropic Workbench・自作の日報MCP。並べてみると、入れすぎだなと我ながら呆れた瞬間でした。

次に、過去1ヶ月で実際に呼ばれたMCPを Claude Code の履歴で集計します。結果は5個だった。GitHub・Slack・Playwright・自作の日報MCP・Linear。残りの10個は、登録した記憶はあるのに、1回も呼ばれていなかったんです。

「いつか使うかもしれない」と思って残していた10個が、毎日コンテキストを食い、毎回の判定に紛れ込んでいた。これが現実だったわけですよ。

5個に絞った結果、Claude Codeの応答速度は体感で1.5倍速くなりました。判断ミスの頻度（「どのツールを呼ぶか確認させてください」と聞いてくる回数）は3分の1に減少。コンテキスト残量も、会話の中盤で6割を切ることがなくなった。

これは私のローカル環境での測定値で、皆さんの環境でそのまま再現するとは限りません。ただ、削減効果の方向は同じになると思っています。私の体感だけで判断せず、まず手元で1週間試してほしいです。

副次効果として、設定ファイルが軽くなった気持ちよさもあった。バージョン追従や認証情報更新など、15個分のメンテ作業から解放されて、コードを書く時間が増えたんですよ。

削減から1週間経った時点で、私は意外な変化にも気づきました。Claude Code の応答が「最近、何かを試そうとして失敗する」パターンが激減したんです。15個入っていた頃は、「とりあえずこのMCPを使ってみますね」と宣言して空振りすることが週に3〜4回あった。5個に絞ったあとは、ほぼゼロです。

選択肢が少ない方が、AIの動きは丁寧になります。これは私の体感ベースの観察に過ぎないため、断言は避けたいです。MCPを増やすことが「AIに自由度を渡す」ではなく「AIに迷い道を増やす」結果になっている可能性は、検証してみる価値があると思っています。

MCP削減を見極める3つの問い——週末30分の棚卸し手順

ここからが実用パートです。週末30分で MCP の棚卸しを終わらせる手順を、3つの問いに圧縮しました。

問1: このMCPは過去2週間で何回呼ばれたか

Claude Code の場合、/cost コマンドやログから呼び出し回数を確認できます。過去2週間でゼロ回なら、削除候補です。「いつか使うかもしれない」は罠で、本当に必要になったときに再インストールすれば済む話だと割り切ること。

呼び出し回数を数える作業自体が「自分の業務の輪郭」を可視化してくれます。意外と使っていないMCPが多いことに気づくはずです。

問2: 同じ目的の別ツールで代替できないか

たとえば Cloudflare KV MCP は便利ですが、私の業務では curl と wrangler コマンドで十分足りました。シェルスクリプトや組み込みのBashで代替できるなら、MCPに頼らない方がコンテキスト圧迫が減ります。

ここで大事なのは「MCPでないと絶対できない」操作だけを残す視点です。便利だけど必須ではないツールは、思い切って外して問題ないんですよ。

問3: 説明文のトークン消費に対して呼び出し頻度が見合うか

Stripe MCPのように説明文が長いツールで、月数回しか呼ばないなら、コストパフォーマンスが合いません。月10回以下なら、その都度ドキュメントを開く運用に切り替えた方が、長期的にコンテキストが軽くなる。

3つの問いは順番に通すと判定が速いです。問1で「ゼロ回」が出たら即削除、問2と問3はグレーゾーンを切り分ける道具として使ってください。

30分の内訳（具体的な時間配分）

• 10分: 設定ファイルから現在のMCPリストを書き出し、紙かテキストに並べる
• 10分: 3問で削除候補を選別し、削除リストを確定する
• 5分: 設定ファイルから該当エントリを削除し、Claude Codeを再起動する
• 5分: 主要なタスク（普段使う3〜5つ）で動作確認する

5分のバッファ込みで30分。週末の朝、コーヒー1杯分の時間で終わります。

私が前回書いたバイブコーディング ツール選び、入口と本番で違う3条件では、ツールの選定軸を整理しました。MCPの棚卸しも、同じく「本番で毎日使う1個に絞る」原則の延長で考えると、判断がぶれにくくなります。

やってはいけない3つのアンチパターン

私が15個から5個への削減過程でハマった、3つのアンチパターンを共有します。先に知っておけば、3時間溶かす場面が0時間で済むはずです。

アンチパターン1: 新着MCPを「試しに」入れる

新しいMCPが出るたびに「とりあえず試す」運用は、棚卸ししないと半年で20個を超えます。私が15個まで膨れたのも、これが原因でした。

試すのが悪いわけではないんですよ。問題は、試したまま忘れる構造の方にある。試すなら「来週末までに本採用判断する」と期限を切り、カレンダーに削除日を入れてしまうのがコツです。

アンチパターン2: 削除を後回しにする

「1個くらい残しても無害だろう」という錯覚に騙されないでください。MCPは累積で効いてくるので、1個ずつ削除しているとコンテキスト圧迫の改善が体感できません。

私の経験では、一度に5個まとめて削除した方が、効果が明確に見えました。「劇的に変わった」と認識できるからこそ、削減のモチベーションが続くんですよ。

アンチパターン3: 複数LLMで同じMCPセットを使い回す

Claude Code・Codex・Cursor で同じMCPセットを共有すると、LLMごとの得意不得意が無視されます。Claude Code は構造化されたツール定義に強く、Cursor はファイル操作系に強い、という得意領域の違いを使い分けないと、最適化の余地が消える。

私の今の運用では、Claude Code に「設計と実装系のMCP」、Cursor に「ファイル操作とリファクタ系のMCP」と役割分担しています。これだけでも、それぞれの応答品質が上がりました。

ナギの記事Claude Code できること8用途、非エンジニア向けで整理されている用途マップは、MCP選定の指針としても使えます。「自分はどの用途にClaude Codeを使うか」が決まれば、必要なMCPの輪郭も自然に絞れる構造です。

まとめ、MCPの本質は「数」ではなく「設計」だ

「とりあえず動くもん作りましょう」は今も私の根本信条ですが、MCPに関しては「とりあえず削るもん作りましょう」を追加しました。

挫折組のエンジニアとして言わせてもらうと、コード設計の世界でも「あれば便利」を全部入れていくと、保守できなくなる現実があります。MCPは同じ構造の罠を持っているんですよ。差分は、MCPの場合「動かなくなる」のではなく「賢くなくなる」という静かな劣化で訪れる点です。

今日の話を3行でまとめると、こうなります。

• MCPは「数」ではなく「設計」で勝負する道具。15個より5個の方が速くて賢い場面が多い
• Microsoftの解説が示した3つの劣化メカニズム（コンテキスト圧迫・意味的衝突・誤選択誘発）は、手元で再現確認できる
• 今週末30分の3問判定で、Claude Code は静かに速くなる。再起動後の応答を、ぜひ自分の手で測ってほしい

MCPを削るのは「機能を捨てる」ことではありません。「Claude Codeに集中してもらう」という設計の話です。そう捉え直すと、削減の心理的なハードルが下がります。多すぎるツールに迷っているのは、AI側ではなく、AIに渡す情報を設計している私たちの方なんですよ。

凄腕エンジニアが自分の手に宿る感覚を、私はMCPを5個に絞ったあと、改めて取り戻しました。15個入っていた頃のClaude Codeは、「便利そう」を無自覚に盛り続けた結果、判断の輪郭が滲んでいたんですよ。減らした瞬間に、AIの応答が私の業務にフィットする手触りが戻ってきた。

皆さんも、ぜひ今週末に試してみてください。30分の棚卸しが、来週からの開発体験を静かに底上げしてくれるはずです。「動かなくなる」のではなく「賢くなくなる」という劣化の方向は、見落としやすい分だけ、気づいたときの効果が大きい。