MCPサーバーを複数つないでみたら、なぜか動きが重くなってきた。
そんな経験はないでしょうか。
海外のコミュニティで、この現象が議論されていました。
テーマは、コンテキストウィンドウがツール定義に食い尽くされてしまう問題です。
本記事では、そこで挙がっていた解決アプローチを整理して紹介します。
なぜMCPでコンテキストが膨らむのか
MCPは便利な仕組みです。
サーバーを1つか2つつなぐぶんには、何の問題もありません。
ところが、接続を増やしていくと状況が変わります。
GitHub、Notion、Slack、Gmail、Linear。
こうしたサーバーを次々と追加していくと、モデルが目にする情報が一気に膨れ上がります。
具体的には、以下の情報です。
- ツール一覧
- スキーマ定義
- 説明文
- パラメータ
- エッジケースの記述
その結果、何が起きるか。本来のタスク処理に使うべき領域が、ツール定義に圧迫されてしまうのです。
どんな悪影響が出るのか
ツール定義にコンテキストを取られると、いろいろな問題が顔を出します。
- ツール選択に時間がかかる
- LLM呼び出しのコストが膨らむ
- モデルが間違ったツールを選ぶ確率が上がる
- 単純な作業が長いツール呼び出しループに化ける
特に厄介なのは3つ目です。
選択肢が多すぎると、AIはむしろ判断を誤りやすくなります。
人間と似ていますね。
既存の回避策：CLIに任せる
実は、すでに多くの開発者がこの問題と向き合っています。
よく取られている対策は、CLIへの委譲です。
GitHubの操作を考えてみましょう。
わざわざ50種類ものツールをモデルに渡す必要はありません。
ghコマンドを使えるようにしておけば十分です。
クラウド操作も同じ発想で扱えます。
vercel、supabase、kubectl、awsといったCLIを与えるだけで、操作の幅は大きく広がります。
なぜこれで上手くいくのか。
理由はシンプルです。
モデルにとって、すべての操作を独立したツールとして渡される必要はありません。
プログラマブルな小さなインターフェースさえあれば、あとは組み合わせで対応できるのです。
発見型パターンの登場
議論の中で、新しい方向性が見えてきました。
ツールを最初から全部ロードしない設計です。
必要なときに発見する仕組みと言い換えてもいいでしょう。
具体的には、次のようなメタツールを少数だけ用意します。
- 利用可能なサーバーを検索する
- 特定サーバーのツール一覧を取得する
- ツールのスキーマを確認する
- 選んだツールを呼び出す
- 複数のツールを連鎖させるスクリプトを実行する
モデルから見えるのは、この数個だけです。
実体は裏に隠れています。
実装の例
このパターンを採用している実装も出てきています。
ひとつはFastMCPです。
プロキシ機能やツール変換、メタデータの取り扱いに対応しています。
発想としては、ツール一覧をフラットな塊として扱わない、というものです。
あいだに層を挟み、そこでフィルタリングや再ルーティングを行います。
もうひとつ興味深かったのは、Antigravityのアプローチです。
接続したMCPサーバーが、ファイルシステムのように見えるそうです。
たとえばExaを接続すると、exaというディレクトリができます。
その中に、ツール名がファイルとして並ぶイメージです。
モデルは巨大なグローバルリストから直接ツールを呼びません。
代わりに、専用のルーティングツール越しに実体へアクセスします。
呼び方は違っても、根っこの思想は同じです。
ツールを「常時ロード」ではなく「発見可能」にすること。
これに尽きます。
動き方の比較
旧来の流れは、こう
モデルに500個のツールが見える → 1つ選ぶ → 呼ぶ → また選ぶ → 呼ぶ → 繰り返す
これに対して、発見型のアプローチはこうなります。
必要な機能を探す → 詳細を確認する → 実行する → 結果を得る
ステップ数だけ見れば似ています。
しかし中身は違います。
後者では、モデルが最初から500個を見比べる必要がありません。
そのぶん、判断の負荷が大きく減ります。
効果が大きい場面
このパターンが特に効くのは、次のようなタスクです。
- 3つ以上のツール呼び出しが連鎖する多段処理。たとえば、GitHubのIssueを探して、関連PRを確認し、Slackで報告するような流れ
- ツール結果のフィルタリング、ソート、変換が中心となる作業
- 途中の結果を細かく確認しなくても完結する処理
逆のケースも考えておくと良いでしょう。
1回のツール呼び出しで終わる単発タスクなら、無理に発見型を導入する必要はありません。
コミュニティから出ていた追加意見
議論のスレッドには、さらに踏み込んだ意見もありました。
ある開発者は、Cursorのルールファイルにシンプルなノートをひとつだけ書いていると話していました。
「MCPツールよりCLIを優先せよ」という指示です。
たったそれだけ。
それでも、コンテキストの節約効果は十分得られているとのことでした。
別のコメントでは、DockerのMCP Gatewayが話題に上がっていました。
これも動的ロードに対応しています。
思想としては同じ方向を向いていると言えるでしょう。
実装の細部を見ると、違いも見えます。
Dockerはローカルでコンテナとして動かす方式です。
一方、リモートで動かす方式もあります。
どちらにせよ、ゲートウェイを挟んで発見型にする発想は共通しています。
もうひとつ印象的な指摘がありました。
サーバー側とエージェント側の役割分担についての話です。
考え方はこうです。
MCPサーバーは「能力」を提供する層に徹する。
そして、いつどう使うかを説明する「スキル」はエージェント側に持たせる。
この構成だと、SKILLS.mdのようなファイルにルーティング知識を書いておけます。
すると、モデルが状況に応じた適切な選択をしやすくなる、というわけです。
まとめ
MCPのコンテキスト肥大化問題は、サーバーを増やせば誰もが直面する課題です。
解決の方向性は、シンプルに表現できます。
ツールを全部見せるのをやめること。
発見・選択・実行という流れに分解することです。
実践のポイントを整理すると、こんな感じでしょうか。
- CLIに任せられる部分は任せる
- それ以外はメタツール経由で発見させる
- SKILLS.mdのような指示書でルーティング知識を補う
こうした組み合わせで、コンテキストを本来のタスクに振り向けられるようになります。
筆者としても、自分のセットアップで小さく試してみたい話題でした。
MCPを多数つないでいる方は、まずツール定義がどれくらいコンテキストを占めているかを確認してみると良いかもしれません。
意外と多くを食っていることに気付くはずです。
