見出し画像

「ITニュース」｜MCP次期仕様がセッションIDを廃止——AIエージェントの裏側が"普通のWeb"に近づく日

まるしょー｜ITニュース分析配信

はじめに

2026年5月21日、AIエージェントが外部ツールやデータへ安全にアクセスするための標準プロトコル「MCP（Model Context Protocol）」の次期仕様（2026-07-28版）が、リリース候補（RC）として仕様凍結されました。TechCrunchが2026年7月20日にこの変更内容を報じています。

この記事の読みどころは2つです。1つは、これまで必須だったサーバー側のセッションID管理が完全に廃止され、各リクエストが単独で完結する「ステートレス」方式に変わる技術的な意味。もう1つは、この変更がMCPサーバーの運用コストや可用性にどう影響しうるかという実務的な視点です。

※ 本件は技術仕様の解説であり、投資・法務等の専門判断を要する内容ではありません。

この記事での用語


1. 何が起きたのか（結論）

  • 2026年5月21日、MCPの次期仕様（2026-07-28版）がリリース候補（RC）としてロック（仕様凍結）されました。

  • 変更前（2025-11-25仕様）は、`initialize`ハンドシェイクで`Mcp-Session-Id`ヘッダーを発行し、以降の全リクエストに同ヘッダーを付与して特定のサーバーインスタンスに固定する「スティッキーセッション」が必須でした。

  • 変更後（2026-07-28 RC）は、`Mcp-Session-Id`ヘッダー・`initialize`ハンドシェイク・スティッキールーティングが完全に撤廃されます。クライアント情報は各リクエストの`_meta`に格納され、リクエスト単体で完結する設計になります。

  • 状態が必要な場合は、サーバーが明示的な「ハンドル」（例：`basket_id`）を発行し、モデルが後続の呼び出しでそれを引数として明示的に渡す「explicit-handle pattern」で対応します。

  • 2026年7月20日、TechCrunchが本変更を報道しました。2026年7月28日に正式仕様が公開される予定で、以降10週間はSDK保守者・クライアント実装者による実運用検証期間が設けられます。

忙しい方向けに一言でいうと、
「AIエージェントの"会話の記憶"は、実はサーバー側のインフラ的な制約だった」——ステートレス化によって、MCPサーバーの裏側の運用が普通のWebサービスに近づく、という技術的な変化です。

2. なぜこの変更が必要とされたのか

MCPはLinux Foundation傘下のオープンなプロトコルプロジェクトとして運営されています。公式ブログの技術解説からは、リモートMCPサーバーの実運用者にとって「スティッキーセッション必須」という制約が、スケーリング・可用性・インフラコストの負担になっていたという課題認識が、今回の仕様変更の背景にあると読み取れます。

従来の仕様では、特定のクライアントのリクエストを常に同じサーバーインスタンスへ振り分ける必要があり、ゲートウェイでのペイロード解析や共有セッションストアの構築が求められていました。これは、単純なロードバランサだけでは運用できないことを意味し、MCPサーバーを提供する側にとってインフラ構築の負担が大きい要因になっていました。

中核となる提案は、SEP-2567（Sessionless MCP via Explicit State Handles）とSEP-2575（Make MCP Stateless）です。なお、Anthropic・OpenAI・Googleのうちどの企業がこの変更を主導したかについては、公式ブログ・報道とも明記がなく、Lead Maintainer個人名（David Soria Parra氏、Den Delimarsky氏）のみが判明しています。特定企業が主導したと断定はできません。

3. ステートレス化がもたらす運用面の変化

新仕様では、`Mcp-Method`ヘッダーによるルーティングが導入され、`tools/list`などのレスポンスは`ttlMs`（生存時間）や`cacheScope`によるキャッシュに対応します。これにより、リモートMCPサーバーはシンプルなロードバランサ構成のもとでも運用可能になるとされています。

なお、この設計変更にはレビューの過程で指摘された未解決の課題も残っています。1つは、並列で送られた初回リクエストをどのサーバーインスタンスへ決定論的にルーティングするかという「ブートストラップ問題」。もう1つは、発行されたハンドルが漏洩した場合に、異なる権限を持つ別のユーザーによって不正に再利用されうるというセキュリティ上の懸念です。これらは別提案（SEP-2822）に持ち越されています。

こうしたAIエージェント連携の基盤における安全設計の論点は、過去にもMCP関連の脆弱性報道で取り上げられてきました。関連する既存記事もあわせてご参照ください。

4. 短期・中期・長期の整理

時間軸定義:

  • 短期: 0〜3か月

  • 中期: 3か月〜1年

  • 長期: 1年以上

4-1. 短期（0〜3か月）

  • 予想される動き: 2026年7月28日の正式仕様公開後、SDK保守者や主要クライアント実装者が対応を進めます。既存のセッション前提実装は改修が必要になります。

  • 不確実性: Claude・ChatGPT・Cursor等の具体的な対応時期は、公式ブログ・報道とも明言されておらず不明です。

  • 効果が出にくい条件: 主要クライアントの対応が想定より遅れた場合、実運用でのメリットが体感されるまでの期間が延びます。

4-2. 中期（3か月〜1年）

  • 予想される動き: リモートMCPサーバーの運用がシンプルなロードバランサ構成で可能になることで、スケーリング・可用性・運用コストが改善し、MCPサーバーを提供する事業者・OSSプロジェクトが増える可能性があります。

  • 不確実性: ブートストラップ問題（並列初回リクエストの決定論的ルーティング欠如）や、ハンドル漏洩時のセキュリティ懸念は、レビューで指摘されつつ未解決のまま別提案に持ち越されています。

  • 効果が出にくい条件: セキュリティ上の懸念が解消されないまま普及が進んだ場合、運用者が独自の追加対策を講じる必要が生じ、期待されたコスト削減効果が薄れる可能性があります。

4-3. 長期（1年以上）

  • 予想される動き: MCPがAIエージェントの相互運用における事実上の標準としての定着を強めれば、今回の設計変更が今後のAIツール連携インフラの前提になる可能性があります。

  • 不確実性: MCP自体が今後も業界標準として優位性を保つか（競合プロトコルの台頭有無）は未知数です。

  • 効果が出ない条件: 主要クライアント（Claude、ChatGPT等）の対応が遅れたり、既存のスティッキーセッション実装からの移行が進まない場合、実運用上のメリットが顕在化するまでに時間がかかります。

5. 混同しやすい点

まとめ

MCPの次期仕様は、サーバー側のセッションID管理を廃止し、各リクエストが単独で完結するステートレス設計へ移行します。これによりリモートMCPサーバーの運用がシンプルになる一方、ブートストラップ問題やハンドル漏洩時のセキュリティ懸念は未解決のまま残っています。自社でMCPサーバーを運用している、あるいは今後運用を検討している場合は、正式仕様公開（2026年7月28日）以降の実装動向を継続的に確認することをおすすめします。

主な参照

関連記事

免責

本記事は執筆時点でのMCP公式ブログ・報道情報をもとにした技術仕様の解説です。正式仕様は2026年7月28日公開予定であり、細部が変更される可能性があります。自社システムへの適用にあたっては、公式仕様書・SDKのドキュメントを直接ご確認ください。

【PR】
私も転職エージェントを利用して転職しました。

いいなと思ったら応援しよう！