10月16日、Stack Overflow Blogが「MCP standardized tools. Now we need the infrastructure around them.」と題した記事を公開した。コーディングエージェント向けホステッドMCPサービス「Hexum.dev」の開発者である著者が、自ら構築する中で気づいた「プロトコル標準化の後に残された問題」を論じている。実運用を通じた知見であるだけに、具体的な数字と課題の整理が際立つ内容だ。

MCPの普及は驚くほど速かった

MCP（Model Context Protocol）のSDKは現在、月間ダウンロード数が5億回に迫る勢いだ。Claude Code、Cursor、Codex、VS Codeといった主要クライアントが対応し、GitHub、Linear、Notionなどのベンダーがホストするエンドポイントも続々と登場している。

MCPが解決した問題は明確だ。それ以前は、AIアプリケーションがそれぞれ独自のツール呼び出し層を実装していた。MCPはその共通インターフェースを提供し、一度サーバーを作れば複数のエージェントがカスタムのグルーコードなしに利用できるようになった。

著者はその成果を認めつつも、実際に構築する中で気づいたことを率直に述べている。

「プロトコルは標準化が進んでいた。しかしその周辺インフラは、それに追いついていなかった。」

コンテキスト87.6%削減——実運用で浮かび上がった数字

記事のフックとして最も強力なのが、著者がHexum.devで実際に取り組んだコーディングエージェントへのリポジトリコンテキスト効率化の成果だ。公開ベンチマーク（MBPP・HumanEval使用）では、モデルに送るコンテキストを220,393トークンから27,352トークンへ、87.6%削減しながら全テストをパスしている。

この数字が示すのは「削れる」という事実だけでなく、削らなければどれほどのコストとレイテンシを垂れ流しているかという問題提起でもある。

コンテキストを最適化すると次にツール選択の問題が浮上する。全サーバーの全ツールスキーマを毎ターン読み込めば、コンテキストがスキーマで埋まり、モデルの選択精度が落ちる。エージェントに50〜100個以上のツールを与えると、むしろ有害になることもある。

MCPの公式クライアントベストプラクティスは現在、定義の遅延読み込みと検索スタイルのメタツール提供を推奨している。ツールを動的に検索・取得する「プログレッシブディスカバリー」だ。また最小権限の観点からも重要で、全ツールを見えるエージェントはプロンプトインジェクションで意図しないツールを呼ばされるリスクがある。

デモと本番環境の間にある深い溝

デモでの構成はシンプルだ。エージェント → MCPクライアント → MCPサーバー → API/DBという流れで動く。

本番環境はそうはいかない。複数エージェント・複数ユーザーが存在し、クレデンシャルの漏洩リスク、レート制限、ユーザーごとに異なる権限、障害・リトライ・ログ・スキーマの変更・コンテキスト制約が現実の問題として立ちはだかる。

特に深刻なのが部分失敗の問題だ。ドキュメントを読んで失敗するエージェントは単に不便なだけだが、クラウドリソースを作成したり、DBレコードを書いたり、プルリクエストを開いたりするエージェントが途中で失敗すれば、不整合な状態が残る。冪等性や補償トランザクションへの対応が必要になるが、プロトコル自体はそれを提供しない。

各チームが同じインフラを再発明している

記事が最も強調するのは「インフラの重複実装」という問題だ。認証、デプロイ、コネクション管理、リトライ、ロギング、シークレット管理、ヘルスチェック、アクセス制御、レジストリ、キャッシュ、レート制限——これらを各チームが個別のコードベースで繰り返し実装している。

著者はこの状況を過去のインフラ変遷になぞらえる。物理サーバーの管理が辛くなったからクラウド抽象化が成熟した。認証の再実装が辛くなったからIDプラットフォームが成熟した。MCPも同じ段階に入りつつあるという見立てだ。

ローカルサーバー（stdio経由）は実験には最適だったが、チーム規模になるとインストール・設定・バージョン管理・クレデンシャルの分散といった問題が露わになる。リモートサーバーはそれを解決するが、今度は認証・マルチテナンシー・レイテンシ・ベンダー依存という別の問題が生じる。

2026年7月の仕様変更でプロトコルレベルのセッションと初期化ハンドシェイクが廃止され、リモートサーバーが通常のHTTPサービスに近いスケールアウトが可能になった。これは前進だが、認証・認可・運用規律の必要性は消えていない。

セキュリティ：APIセキュリティとは別の問題

MCPのセキュリティは通常のAPIセキュリティと同一視できない。エージェントは信頼できないテキストを読み、それを命令として解釈し、ツールを呼び出して外部状態を変更する。プロンプトインジェクション、混乱した代理人問題（confused deputy）、過剰な権限、悪意あるツール説明、サプライチェーンリスクといった攻撃面が生まれる。

2026年の調査では、7,973件のリモートMCPサーバーのうち40.55%が認証なしでツールを公開していた。これはプロトコルの問題ではなくデプロイの問題だが、チームが実際にぶつかる問題だ。

オブザーバビリティの整備も始まった

自律エージェントは人間と違い、エラーに気づいても止まらないことがある。モデルが何を信じ、どのコンテキストを見て、どのツールを選び、何を引数として生成し、何が返ってきて、次に何をしたか——それを後から再構築できる必要がある。

標準的なテレメトリの整備も進みつつある。OpenTelemetryのGenAIセマンティック規約にMCP関連のスパンと属性が追加され、W3Cトレースコンテキストをメタデータに埋め込む仕様も検討中だ。公式PythonSDKはデフォルトでOpenTelemetryスパンを出力するようになった。

MCPは「プロトコル問題」から「インフラカテゴリ」へ

著者の結論はシンプルだ。HTTPが通信を標準化しても、その後にCDN・ロードバランサー・APIゲートウェイ・オブザーバビリティプラットフォーム・IDシステムが必要になったように、MCPも同じ道を歩む。

想定されるスタックはこうだ：モデル／エージェント → エージェントランタイム／MCPクライアント → インフラ層（ルーティング・認証・権限・コンテキスト管理・ツールディスカバリー・キャッシュ・オブザーバビリティ） → MCPサーバー群 → 実際のDB・API・SaaSシステム。

どの機能がモデルプロバイダーに取り込まれ、どれがクラウドプラットフォームやゲートウェイに落ち着くかはまだ定まっていない。だが方向性は明確で、整備はすでに動き始めている。

「インターフェースはもはや最難関ではない。その周囲のシステムがそうだ。」

詳細はMCP standardized tools. Now we need the infrastructure around them.を参照していただきたい。