先に要点
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_docssearch_wikisearch_drivesearch_repo_notessearch_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は確信を持ちにくい
たとえば、同じ運用手順が
の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-toolssharedworkspaceops2
良い例:
git-repo-readticketing-writebilling-ledger-readprod-deploy-approval
AI にとって効くのは、おしゃれな抽象名より 何のための接続先か が一目で分かる名前です。
5. 追加前に「AIがどう迷うか」でレビューする
新しい MCPサーバー を足す前に、次を確認するとかなり事故を減らせます。
- 既存サーバーと役割が重複していないか
- 似た tool 名が増えないか
- 読み取りで足りるのに write を混ぜていないか
- 正本不明の資料を増やしていないか
- 人間でも
この依頼ならここと即答できるか
ここで人間が迷うなら、AI もたいてい迷います。
MCPを増やすときは「接続先数」ではなく「判断数」で考える
実務では MCPサーバーを何本まで と固定するより、その追加でAIの判断数がいくつ増えるか で見た方が役立ちます。
たとえば、同じ Git 関連でも
- 読み取り専用の参照
- PRコメント投稿
- main ブランチ反映
を同じ面に置くのと、分けるのとでは、AI が毎回比較する判断がかなり違います。
サーバーを1本増やすこと自体が悪いのではありません。
悪いのは、増やした結果として どこへ聞くか どこまでやってよいか が曖昧になること です。
MCPサーバー増加と混乱のよくある質問
Q. MCP は何本くらいまでが管理しやすい？
A. 3〜5本が目安。それ以上になると どの MCP で何ができるか が AI も人も把握しづらくなります。機能の重複 名前の似たツール で AI の判断ミスが起きやすくなります。
Q. 重複ツールがあると何が起きる？
A. AI が どちらを使えば良いか迷う 同じ情報を別 MCP から取って結果が違う、などの混乱。どちらかに統一 または 明確に役割分担 するのが解決策。
Q. MCP を分けるべき基準は？
A. 情報源(GitHub と Slack)、権限(読み取り vs 書き込み)、環境(dev / prod)、機能(検索 vs アクション)、で分けると混乱が減ります。
Q. AI が間違った MCP を呼ぶ時の対処は？
A. MCP 名と説明を改善、重複ツールを削減、プロンプトで明示、ツール許可リストで使えるものを限定、です。AI に正しく選ばせる 設計が最優先。
Q. MCP 設定はどこに置く？
A. Claude Code はユーザー/ローカルスコープが ~/.claude.json(プロジェクト固有は .mcp.json でリポジトリ管理)、Claude Desktop は ~/Library/Application Support/Claude/claude_desktop_config.json(Mac)。
Q. 商用 MCP サーバーで信頼性は？
A. ベンダー次第。公式 MCP (Anthropic 公開) は基本安定、サードパーティ MCP はメンテナンス状況を確認。本番依存は 自前 MCP または 安定実績のある公式 MCP 推奨。
Q. MCP セキュリティで気を付けることは？
A. 読み取り専用権限を優先、本番 DB 接続は厳格に管理、シークレット情報を MCP に渡さない、監査ログ、未使用 MCP は無効化、です。MCP は AI からの操作経路なので、慎重に。
まとめ
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