ステートレス化するMCP：新仕様「2026-07-28」が解決するスケーラビリティの壁

📖 この記事は、前回の記事「MCP (Model Context Protocol) の内部仕様を深掘り：JSON-RPC 2.0とStreamable HTTPを用いたClient-Server通信の実践」の続編です。
前回の内容をさらに深掘り・発展させてお届けします。まだお読みでない方は、先に前回の記事 MCP (Model Context Protocol) の内部仕様を深掘り：JSON-RPC 2.0とStreamable HTTPを用いたClient-Server通信の実践 からご覧いただくのがおすすめです。

【現状の課題提示】セッション維持の限界と業界標準への脱皮

前回、MCPの通信レイヤーにおける「Streamable HTTP」や「SSEによる常時接続」の設計思想について解説しました。当時は、セッションID（Mcp-Session-Id）を用いてクライアントとサーバー間のセッションを張り、初期化ハンドシェイクを行うステートフルな通信が基本とされていました。

しかし、この「接続を維持し続ける」アプローチは、本番環境のスケールアウトにおいて重大な課題を露呈することになります。

具体的には、AWS LambdaやCloudflare Workersに代表される「サーバーレス（FaaS）環境」やエッジコンピューティングにおいて、常時接続の維持はサーバーリソースを無駄に消費し続けます。また、ロードバランサーの配下で複数インスタンスを稼働させる場合、特定のクライアントからの通信を常に同じサーバーに固定する「Sticky Routing」が不可欠となり、クラウドインフラが本来持つべき柔軟なスケーリングを大きく妨げる要因になっていました。

さらに、MCPは特定の企業が主導する規格から、多くのベンダーが安心して採用できる「中立な業界標準」へと進化する必要もありました。

【解決策の提示】「MCP 2.0」における徹底したステートレス化

これらの課題を根本から解決するため、MCPは2025年末から2026年にかけて、アーキテクチャの根幹に関わる大規模なアップデートへと踏み切りました。

最大の転換点は、2025年12月におけるガバナンスの**「Agentic AI Foundation (AAIF)」**への移行です。AnthropicはMCPをLinux Foundation傘下のAAIFに寄贈しました。これに伴い、OpenAI、Google、Microsoft、AWSなどが参画し、中立な業界標準として管理される体制になりました。これにより、ChatGPT、Claude、Gemini、Cursorなどの主要製品がMCPをネイティブ採用し、実質的な業界デファクトスタンダードとしての地位を確立しました。

この組織体制の変化と並行して進められた技術的解決策が、通称**「MCP 2.0」と呼ばれる「徹底したステートレス化」です。RCがフリーズされ、2026年7月28日に確定予定とされる「2026-07-28仕様」**において、従来のセッション管理の仕組みは完全に刷新されました。

具体的には、以下の破壊的変更が行われています。

1. initialize ハンドシェイクの廃止 (SEP-2575):
   従来は通信開始時にお互いのバージョンや機能をすり合わせるために3往復のやり取りが必要でしたが、これが完全に廃止されました。
2. セッションID（Mcp-Session-Id）の廃止 (SEP-2567):
   プロトコルレベルでのセッション管理を削除し、クライアントとサーバー間の密結合を排除しました。

これにより、クライアントは接続の手続きをスキップし、**「1通目のリクエストからいきなり tools/call などの本リクエストを送信できる」**ようになりました。バージョン情報や機能宣言は、すべてのリクエストに付与される _meta フィールド（io.modelcontextprotocol/ から始まるオブジェクト）に同梱されます。

サーバー側でクライアントの状態を維持する必要が一切なくなったため、サーバーレス環境であっても、単なる「軽量なHTTPエンドポイント」としてシンプルにスケールアウトさせることが可能になります。インフラの維持コストや、運用の複雑性を極限まで削減できる点が、このステートレス化における最大のビジネス的・技術的メリットです。

【セキュリティと洗練されたUI/UX】実用化フェーズの強化策

普及が加速する一方で、2026年1月には機能証明（アテステーション）の欠如やプロンプトインジェクションの脆弱性を指摘する初のセキュリティ分析論文が発表されました。これを受け、本番環境の運用に耐えうるセキュリティとUXの強化策が仕様に統合されました。

• 段階的な権限同意（Incremental scope consent）:
  WWW-Authenticate ヘッダーを用いて、初回の認可ですべての権限を要求するのではなく、特定の重い処理が必要になった段階で必要なスコープ（権限）のみをユーザーに要求する「最小権限の原則」を実装します。
• OIDC Discovery 1.0のサポート:
  従来のOAuth 2.0メタデータに加え、新たに openid-configuration に対応し、認可サーバー情報の取得手段を拡張しました。

また、UI/UXの観点でも以下のアップデートが開発体験を大きく向上させています。

• ツールのキャッシュ機能 (ttlMs):
  tools/list などのAPIレスポンスに有効期限（TTL）情報を持たせることで、不要な再リクエストを防ぎ、クライアント側で結果を効率よくキャッシュできるようになりました。
• アイコン（メタデータ）のサポート (SEP-973):
  サーバーが提供するツールやリソースにアイコン情報を付与することで、CursorやClaude Desktopなどの画面上で直感的にツールを識別できるようになりました。

【具体的なステップ（ロードマップ）】マルチエージェントインフラへの展望

ステートレス化と強固なセキュリティを手に入れたMCPは、2026年下半期以降、さらなる「自律連携インフラ」へと進化を遂げるロードマップを掲げています。

1. AI同士の「自律連携（マルチエージェント）」インフラへの昇華:
   従来の「AIモデル ⇔ 外部ツール」の接続から一歩進み、自律したAIエージェント同士が、お互いの得意な機能やコンテキストをMCP経由で共有し合うエコシステムを構築します。
2. トリガーとイベント駆動型（Webhooks）の標準化:
   常時接続のSSEに頼ることなく、サーバー側の状態変化をプロアクティブにクライアントへ通知するためのWebhooks（コールバック）仕様の策定が進んでいます。
3. データ送信のストリーミング化と参照化 (Reference-based Results):
   画像や音声、巨大なファイルなどの重いレスポンスをそのまま返却してコンテキストを汚染するのを防ぐため、データの「参照（Reference）」のみを返し、必要に応じて後から段階的に取得するアプローチが検討されています。