MCPを増やすほどAIが迷いやすくなるのはなぜか？

先に要点

MCPサーバーを増やすほど AI が迷いやすくなるのは、`できることが増える` 以上に `どこへ聞くべきか判断する仕事` が増えるからです。
特に迷いやすいのは、似た MCPツールが複数サーバーに分散しているとき、同じ情報が複数の MCPリソースに重複しているとき、MCPプロンプトの役割が曖昧なときです。
対策は、MCPサーバーを増やす前に `責任範囲` `読み取りか書き込みか` `誰のデータか` `どの場面で選ばせるか` を分けることです。
`つなげば強くなる` ではなく、`AIが選び分けやすい面で増やす` と考えた方が実務では安定します。

MCP を使い始めると、社内ドキュメント、チケット、Git、ファイル、データベース、クラウド操作など、いろいろな接続先を足したくなります。
実際、MCPサーバーを増やすと AI が触れられる範囲は広がります。

ただ、ここで起きやすいのが サーバーを増やしたのに賢くなるどころか、むしろ迷いやすくなった という現象です。
検索系が複数あって使い分けがぶれたり、同じような read ツールが並んで余計な探索が増えたり、書き込み先の選択を間違えたりします。

この記事では、2026年4月28日時点で Model Context Protocol 公式 specification の Tools / Resources / Prompts、OpenAI Responses API の tools と prompt cache、Anthropic の tool use pricing を確認しながら、なぜ MCPサーバーを増やすほど AI が迷いやすくなるのかを整理します。
まず MCP 自体の基本から押さえたい場合は、MCPとは？仕組み・できること・便利な理由を初心者向けにわかりやすく解説を先にどうぞ。
そもそもツールを増やしすぎると何が起きるのか を広めに見たい場合は、AIエージェントにツールを渡しすぎると何が起きる？選択ミス・コスト・権限リスクを整理もつながります。

まず結論: MCPが増えると「能力」より先に「選択面」が肥大化する

MCPサーバーは、AI にとって 使える入口 を増やす仕組みです。
でも入口が増えるということは、毎回 どの入口を使うべきか を判断する必要も増えるということです。

特に AI が実際にやっているのは、単にツール名を見ることではありません。

いまの依頼にどの接続先が近いか考える
そのサーバーにどんな MCPツールがあるか推測する
必要なら MCPリソースや MCPプロンプトも候補に入れる
読み取りで足りるか、書き込みが必要かを分ける
実行してよい権限境界かを文脈から判断する

つまり、MCPサーバーが増えるほど、AI の仕事は 実行 より前の 候補比較 に時間を使いやすくなります。
この比較面が人間から見ても曖昧なら、AI が迷うのはかなり自然です。

なぜ迷いやすくなるのか

1. 似たツールが複数サーバーに並ぶ

一番よくあるのはこれです。

search_docs
search_wiki
search_drive
search_repo_notes
search_tickets

のような検索系が、別々の MCPサーバーから出てくる状態です。

人間なら 社内手順は wiki、実装断片は repo、運用履歴は tickets と経験で切り分けられても、AI から見ると説明文が似ていればかなり近い候補に見えます。
MCP の Tools 仕様でも、サーバーは tool 名、説明、schema を返し、クライアントはその一覧を前提に選びます。
つまり、似た説明のツールを増やすほど、AI にとっては識別問題が重くなる ということです。

2. サーバー単位の責任範囲が曖昧だと、接続先判断がぶれる

たとえば、

チーム単位でサーバーを分けた
データ種別単位でも分けた
読み取りと書き込みは分けていない
古いサーバーも新しいサーバーも残っている

という構成だと、何を基準にそのサーバーを選ぶのか が曖昧になります。

AI にとって大事なのは、サーバー数そのものより 分け方に一貫性があるか です。
人事データの読み取り Git リポジトリの参照 経費申請の起票 のように責任範囲が素直なら選びやすいですが、社内共通1 共通運用 legacy-tools のような分け方だと迷いやすくなります。

3. ToolsだけでなくResourcesとPromptsも増えて、探索面が広がる

MCP は tool call だけではありません。
公式仕様では、MCPリソースは読み取り対象、MCPプロンプトはユーザー主導で呼ぶテンプレートとして扱えます。

ここで、

ツールで検索できる
リソース一覧にも同じ資料がある
プロンプトでも同じ業務テンプレートを呼べる

という状態になると、AI から見た選択面はさらに広がります。
便利そうに見えても、何をどの順で使うのが正解か が曖昧なら、探索コストだけが増えます。

特に Resources 仕様では annotation の priority や audience で優先度ヒントを出せます。
このヒントがないまま大量リソースを並べると、全部読めそうで全部は読めない 状態になりやすいです。

4. 同じ情報が複数経路から見えると、AIは確信を持ちにくい

たとえば、同じ運用手順が

wiki検索MCP
drive参照MCP
repo内docs参照MCP

の3経路で見えるとします。

このとき AI は 複数見つかったから安心 ではなく、むしろ どれが正本か を追加で判断しないといけません。
内容が少しでも違えば、古い版なのか、要約版なのか、運用差分なのかを推測する必要が出ます。

人間でも迷う構造は、AI ならなおさら迷います。
情報源を増やす ことと 正答しやすくする ことは同じではありません。

5. 書き込み系が混ざると、権限判断まで同時に必要になる

読み取りだけなら まず読んでみる で済みやすいです。
でも、MCPサーバーが増えると、その中に

チケット起票
コメント投稿
変更申請
データ更新
クラウド操作

のような書き込み系が混ざりやすくなります。

すると AI は 情報を取りに行く だけでなく、この接続先へ今書いてよいのか まで同時に判断しないといけません。
しかも、サーバー名や tool 名から危険度が直感しにくいと、迷いはさらに増えます。

これは単なる選択ミスだけでなく、最小権限やガードレール設計の問題でもあります。
読み取り用と書き込み用の面を混ぜるほど、AI の判断コストは上がります。

6. サーバーを足すほど、説明文とschemaのコストも増える

ツール利用では、AI はゼロ知識で呼ぶのではなく、tool 定義、description、schema などを手掛かりに選びます。
つまり、MCPサーバーが増えるほど、読んで比較すべき説明文も増えます。

Anthropic の tool use docs でも、tool 定義自体が入力トークンに含まれることが案内されています。
OpenAI の Responses API でも、tool choice や prompt cache を含め、ツール込みの文脈をどう持つかが設計対象です。

ここで起きるのは、単純な課金増だけではありません。

毎回読む定義が増える
類似schemaの比較が増える
使わないツール説明まで抱える
セッションが長いほど重要情報が埋もれやすい

という形で、判断の鈍りにつながります。

MCPが増えて迷っている状態のサイン

次のような症状があるなら、MCPサーバーを増やしすぎたか、分け方が曖昧な可能性があります。

症状	起きていそうなこと
毎回いくつもの検索ツールを試す	検索面の責任分界が曖昧
同じ質問で選ぶサーバーが毎回ぶれる	説明文や分け方に一貫性がない
読めば足りるのに書き込み系まで候補に出る	読み取りと書き込みが混在している
資料は見つかるのに正本が分からない	同じ情報源が複数サーバーへ重複している
接続先追加のたびに応答が重くなる	tool定義と探索面が肥大化している
失敗時に、どのMCPが悪かったのか追いにくい	サーバー境界と責任範囲が曖昧

どう分けると迷いにくいか

1. サーバーの分け方を「責任」で揃える

おすすめなのは、次のような一貫した基準です。

データ領域で分ける例: hr-read, finance-read, repo-read
操作権限で分ける例: tickets-read と tickets-write
ライフサイクルで分ける例: prod-ops と staging-ops

逆に、チーム都合、歴史的経緯、接続方式、担当者名の混在で分けると、AI から見た基準が崩れやすいです。

2. 読み取り面と書き込み面を分ける

これはかなり効きます。

まずは read 系サーバーだけ公開する
write 系は別サーバーか別agentで扱う
危険操作は承認つきにする

この形にすると、AI は まず調べる と 何かを変える を分離しやすくなります。
結果として、余計な書き込み候補を抱えずに済みます。

3. 正本を決めて、重複公開を減らす

同じ文書が複数の MCPリソース経路から見えるなら、少なくとも次は決めた方が安定します。

正本はどこか
ミラーは何か
どれを優先して読ませるか
古い版をどう隠すか

Resources の annotation を使えるなら、priority や lastModified を丁寧に付けるだけでも、クライアント側の扱いは改善しやすくなります。

4. 名前で役割が分かるようにする

悪い例:

common-tools
shared
workspace
ops2

良い例:

git-repo-read
ticketing-write
billing-ledger-read
prod-deploy-approval

AI にとって効くのは、おしゃれな抽象名より 何のための接続先か が一目で分かる名前です。

5. 追加前に「AIがどう迷うか」でレビューする

新しい MCPサーバーを足す前に、次を確認するとかなり事故を減らせます。

既存サーバーと役割が重複していないか
似た tool 名が増えないか
読み取りで足りるのに write を混ぜていないか
正本不明の資料を増やしていないか
人間でも この依頼ならここ と即答できるか

ここで人間が迷うなら、AI もたいてい迷います。

MCPを増やすときは「接続先数」ではなく「判断数」で考える

実務では MCPサーバーを何本まで と固定するより、その追加でAIの判断数がいくつ増えるか で見た方が役立ちます。

たとえば、同じ Git 関連でも

読み取り専用の参照
PRコメント投稿
main ブランチ反映

を同じ面に置くのと、分けるのとでは、AI が毎回比較する判断がかなり違います。

サーバーを1本増やすこと自体が悪いのではありません。
悪いのは、増やした結果として どこへ聞くか どこまでやってよいか が曖昧になること です。

まとめ

MCPサーバーを増やすほど AI が迷いやすくなるのは、単に接続先が増えるからではありません。
ツール、リソース、プロンプト、権限、正本、説明文の比較対象が一気に増え、AI の前処理としての選択面が肥大化する からです。

特に効きやすい対策は次の5つです。

サーバーの分け方を責任範囲で揃える
読み取りと書き込みを分ける
正本を決めて重複公開を減らす
名前と説明で役割を明確にする
追加前に AIがどう迷うか を人間目線で点検する

MCPを増やす = 賢くなる ではなく、AIが選び分けやすい構造で増やす と捉えると、かなり崩れにくくなります。
最初に何を実装題材にすると失敗しにくいかを見たい場合は、最初に作るMCPサーバーは何がよい？実務で使いやすい実装例を整理も続けてどうぞ。

参考リンク

Model Context Protocol: Specification - Tools
Model Context Protocol: Specification - Resources
Model Context Protocol: Specification - Prompts
OpenAI API Reference: Responses
Anthropic Docs: Tool use overview

MCPを増やすほどAIが迷いやすくなるのはなぜか？接続先判断と設計の崩れ方を整理