AIエージェントに外部ツールを接続する仕組みとして、MCP（Model Context Protocol、AnthropicがLLMと外部ツールを繋ぐために策定したプロトコル）を導入する開発チームが増えています。すでにGlamaというカタログサイトでは約75000件、PulseMCPでは約22000件のMCPサーバーが登録されています。この記事は、複数のMCPサーバーを本番のエージェント基盤に組み込む際、個別接続方式にするか集約プロキシ方式にするかで迷っているインフラ担当・SREの方に向けた判断材料です。
判断が必要になる場面は明確です。エージェントに使わせたいツールが3個から5個程度なら悩む必要はありません。設定ファイルに書き込んで終わりです。問題は、業務が広がりPostgres接続・Slack通知・GitHub操作・社内API呼び出しなど、必要なツールが10個を超えたあたりから出てきます。
なぜこの選定で迷うのか
MCPサーバーを設定ファイルに1つ追加するたびに、そのサーバーが持つツールのスキーマ（入出力の型定義）がLLMへのリクエストに毎回含まれます。10個のサーバーがそれぞれ12個前後のツールを持っていれば、会話が始まる前に数千トークン分のコンテキストが消費される計算です。
これはクラウド移行でよく見る「サイドカー増殖問題」に似ています。マイクロサービスごとにログ収集エージェントやプロキシを1つずつ積んでいくと、個々は軽くても合計のリソース消費とネットワークホップ数が無視できなくなる現象です。MCPサーバーの多重接続も、個々は数KBのスキーマでも積算すると運用コストとレイテンシに跳ね返ります。
この課題への1つの解として、mcp-anythingという集約サーバー（メタサーバー）が公開されています。個別サーバーを直接設定する代わりに、search_mcp_servers・describe_mcp_server・list_mcp_tools・call_mcp_tool・sync_registryという5つのメタツールだけをエージェントに渡し、必要なサーバーを実行時に検索・接続する方式です。内部では公式MCPレジストリ、PulseMCP、npm、Glamaの4カタログを同期し、GitHubスター数やnpmダウンロード数でランキングしています。
判断軸1: 接続先の数と増加速度
最初の軸は、現時点および将来的に接続するMCPサーバーの数です。
3〜5個程度で今後も大きく増える見込みがないなら、個別設定方式のシンプルさが勝ります。障害時の切り分けも1対1対応なので追いやすいままです。
一方、10個を超え、かつ今後もチームや部門ごとに追加要望が出続けるなら、集約方式のメリットが効いてきます。コンテキスト消費が「サーバー数に比例」から「メタツール5個で一定」に変わる点が最大の違いです。
判断軸2: セキュリティ境界の設計コスト
2つ目の軸は、外部の公開カタログから未検証のサーバーを実行させるリスクをどう管理するかです。
公開カタログを検索対象にするということは、悪意あるサーバーがランキング上位に紛れ込む可能性をゼロにできないということです。mcp-anythingの実装では、SSRF対策（サーバー側の脆弱性を突いて内部ネットワークやクラウドのメタデータエンドポイントにアクセスさせる攻撃への対策）として、接続先がループバックアドレスやプライベートIP、169.254.169.254（クラウドのインスタンスメタデータAPIの既知アドレス）を指す場合は拒否する設計になっています。
また、npxやuvx経由でのコード実行はデフォルト無効で、有効化にはパッケージ単位・バージョン固定の許可リストが必要です。APIキーなどの認証情報はローカル設定にのみ保持し、インデックスやモデルへの応答には含めない設計も明記されています。
これらの防御があっても、ツール説明文やレスポンスに悪意あるコードや指示を混入させる「ツールポイズニング」への根本対策は存在しないという点も公開情報として明示されています。社内ポリシーで外部ツール接続に承認プロセスを敷いている組織なら、この監査ログをどう残すかを事前に決めておく必要があります。
判断軸3: 障害時の切り分けやすさ
3つ目の軸は、障害が起きたときにどこまで早く原因を特定できるかです。
個別設定方式では、どのサーバーの接続が落ちているかは設定ファイルとログを見れば一目瞭然です。監視もサーバーごとにヘルスチェックを立てるだけで済みます。
集約方式では、メタサーバー自体が単一障害点（SPOF）になり得ます。mcp-anythingはダウンストリームのMCPサーバーとのセッションをLRU（最近使われていないものから破棄する方式）でプール・再利用する実装のため、セッション管理層に不具合が出ると接続先すべてに影響が波及します。障害の根本原因分析をする際は、まず集約層のセッションプール状態を確認し、それから個別サーバー側の問題かを切り分ける、という2段階の手順を運用ドキュメントに落としておくことが必要です。
判断軸4: 運用コストとインフラの持ち方
最後の軸は、ホスティングと運用体制です。
mcp-anythingにはmcp-anything.onrender.comというホスト済みインスタンスが公開されていますが、これはcall_mcp_tool（実際にツールを実行する機能）を無効化した「discovery-only」モードに限定されています。理由は明快で、実行機能まで公開するとオープンプロキシとして誰でも任意のツールを実行できてしまうためです。Dockerfileもこの理由からdiscovery-onlyがデフォルトになっています。
本番でツール実行まで使う場合は、自前でコンテナをデプロイし、ネットワーク境界を自組織のVPC内に閉じる構成が前提になります。これはクラウド移行でよく行う「マネージドサービスをそのまま使うか、自前でホストするか」の判断と同じ構図です。運用工数を払ってでも実行権限のあるインスタンスを自社管理下に置くかどうかが分かれ目です。
選択肢の比較
| 観点 | 個別サーバー設定方式 | 集約プロキシ方式(mcp-anything型) |
|---|---|---|
| コンテキスト消費 | サーバー数に比例して増加 | メタツール5個で一定 |
| 障害切り分け | 1対1で追いやすい | 集約層の状態確認が先に必要 |
| セキュリティ境界 | 接続先を都度自分で精査 | SSRF対策等は組み込み済みだが公開カタログ由来のリスクは残る |
| 運用インフラ | クライアント設定のみ | 実行権限ありなら自前ホスティングが前提 |
ケース別の推奨
接続先が5個以下で今後も増えないなら、個別設定方式を選ぶのが妥当です。集約層を挟む複雑さに見合うメリットがありません。
接続先が10個を超え、かつ部門横断でツール追加要望が続くなら、集約方式の導入を検討する価値があります。ただし実行機能まで使う場合は必ず自前ホスティングにし、discovery-onlyの公開インスタンスをそのまま本番の実行経路に使わないことが前提です。
社内に未承認の外部ツールを実行させたくない厳格なセキュリティポリシーがあるなら、まずはsearch_mcp_serversとdescribe_mcp_serverによる検索・調査機能だけを試験導入し、call_mcp_toolの許可リストは監査プロセスを整えてから広げるという段階導入が現実的です。
あえて見送るべき条件
次のいずれかに当てはまるなら、集約方式の導入は見送るのが無難です。
- 接続先MCPサーバーが少数固定で、今後の追加予定がない
- 外部の公開カタログ由来のコードを実行することに対し社内承認が下りていない
- 障害対応チームが集約層特有のセッションプール障害に対応する余力がない
- 監査ログやツールポイズニング対策を独自に追加できる体制がない
導入前に確認すること
MCPサーバーの数が増えてきて設定管理が煩雑になってきたら、まずコンテキスト消費量を実測することから始めるのが確実です。
具体的には、現在接続しているサーバー数とツール数を数え、1リクエストあたりのトークン消費を確認します。そのうえで、集約方式を試す場合はclaude mcp add anything -- npx -y mcp-anything serveのようなコマンドでローカル検証環境を立て、discovery-onlyの範囲で検索精度とレイテンシを確かめてから、実行権限の付与を検討する順序が安全です。
SECURITY.mdのような公開ドキュメントがあるツールなら、導入前に必ず目を通し、自組織のセキュリティ基準と照らし合わせる作業も欠かせません。