Engineering · 連携

MCP 2026-07-28 仕様 — ステートレス化がエンタープライズ接続を変える

MCP 2026-07-28 仕様はプロトコルをセッション型からステートレス型へ転換しました。initialize ハンドシェイクと Mcp-Session-Id を廃止し、各リクエストが _meta で自己完結することで、任意のサーバーインスタンスが処理できる標準 HTTP ベースのスケーラブルな接続基盤が実現します。

要点

  • MCP 2026-07-28 仕様(Agentic AI Foundation 公開)は initialize ハンドシェイクと Mcp-Session-Id を廃止(SEP-2575 / SEP-2567)。各リクエストが _meta で自己完結する。
  • ステートレス化により任意のサーバーインスタンスがリクエストを処理できる。セッション粘着が不要になり、標準 HTTP インフラ上での水平スケールアウトが容易になった(MCP blog、2026-07-28)。
  • 双方向ストリームなしで確認フローを実現する Multi Round-Trip Requests(MRTR)を導入(SEP-2322)。
  • OAuth/OIDC が本番水準に強化(SEP-2468、RFC 9207 準拠の iss パラメータ検証)。エンタープライズ IAM との接続設計がシンプルになった。
  • 拡張フレームワーク(SEP-2133)が正式化。MCP Apps(SEP-1865)と Tasks 拡張(SEP-2663)がコアとは独立してバージョン管理される。
  • Roots・Sampling・Logging が廃止予定(SEP-2577)。12 ヶ月の移行期間で代替手段への移行が求められる。

セッション型から、ステートレス型へ

MCP(Model Context Protocol)の 2026-07-28 仕様は、プロトコルの根幹的な設計を変えました。Agentic AI Foundation が公開したこの仕様は「MCP はステートフルな双方向プロトコルからリクエスト/レスポンス型のステートレスプロトコルへ転換する」と明記しています(blog.modelcontextprotocol.io、2026-07-28)。

旧仕様では、クライアントが最初に initialize ハンドシェイクを行い Mcp-Session-Id を取得してからリクエストを送る仕組みでした。セッション ID は特定のサーバーインスタンスに紐づくため、ロードバランサーはセッション粘着を維持する必要があり、スケールアウトの障壁になっていました。

新仕様ではハンドシェイク(SEP-2575)とセッション ID(SEP-2567)が廃止され、各リクエストが _meta フィールドにプロトコルバージョン・クライアント識別情報・クライアントケイパビリティを含めて自己完結します。任意のサーバーインスタンスがリクエストを処理できるようになり、Agentic AI Foundation はこれを「標準の HTTP インフラ上でスケールするステートレスコア」と表現しています(MCP release candidate blog、2026-07-28)。

ステートレス化が解消するスケールの壁

旧仕様(セッション型)クライアント① initialize ハンドシェイクMcp-Session-Id 発行・保持Server(特定インスタンス)セッション状態を常時保持② Request(Session-Id で固定)同一インスタンスへの粘着スケールアウト困難(セッション粘着)新仕様(2026-07-28 ステートレス)クライアントリクエスト(自己完結)_meta に version · identity を含むSrv 1Srv 2Srv 3任意のインスタンスが処理可能
旧仕様(左)は Mcp-Session-Id で特定インスタンスに固定される。新仕様(右)は _meta で自己完結したリクエストを任意のインスタンスが処理でき、水平スケールが容易になる。

双方向ストリームなしで確認フローを実現する MRTR

ステートレス化に伴い、旧仕様でサーバーからクライアントへ送っていたリクエスト(サーバー起点の通信)の扱いが再設計されました。新仕様では、サーバーはアクティブなクライアントリクエストを処理している最中にのみクライアントへの要求を返せます(SEP-2260)。

その上で導入されたのが Multi Round-Trip Requests(MRTR)です(SEP-2322)。ツール実行の途中でユーザーへの確認やパラメータ追加入力が必要な場合、サーバーは resultType: "input_required" を返し、クライアントが inputResponses で応答します。双方向の永続ストリームなしで確認フローが実現できるため、ステートレスな HTTP 上でも人間の承認を組み込みやすくなります。

また Mcp-MethodMcp-Name の HTTP ヘッダーが必須化されました(SEP-2243)。ゲートウェイやロードバランサーが JSON ボディを解析せずにリクエストをルーティングできるため、MCP ゲートウェイの実装が軽量になります。

OAuth/OIDC が本番水準に強化

(B)認可の設計も大きく進化しました。SEP-2468 は RFC 9207 に準拠した iss パラメータ検証を義務化します。認可サーバーのレスポンスに iss が含まれることでミックスアップ攻撃を防ぎ、エンタープライズ IAM(Entra ID・Okta 等)との接続が迂回策なしで安定します。

OpenID Connect の application_type 宣言(SEP-837)と認可サーバー再登録要件(SEP-2352)も加わりました。動的クライアント登録(DCR)は廃止予定となり、クライアント認証情報の発行者へのバインディングを明示する設計に移行します(MCP release candidate blog、2026-07-28)。

コアを守りながら能力を拡張するフレームワーク

拡張フレームワーク:コア仕様を小さく保ちながら新機能を追加するMCP Appsサーバー描画UI(SEP-1865)Tasks 拡張長時間タスク管理(SEP-2663)将来の拡張コア非破壊で追加Extensions Framework(SEP-2133)reverse-DNS ID で識別 ・ 独立バージョン管理(ext-* リポジトリ)コア MCP プロトコル(ステートレス)Streamable HTTPMRTROAuth/OIDC 強化JSON Schema 2020-12廃止予定(SEP-2577・12ヶ月移行期間): Roots / Sampling / Logging → 代替手段へ移行
コア MCP(ステートレス・OAuth/OIDC 強化)の上に Extensions Framework(SEP-2133)が載り、MCP Apps・Tasks 拡張など新機能がコアへの影響なく独立して追加される。

拡張フレームワークの正式化と廃止機能

新仕様で正式化された拡張フレームワーク(SEP-2133)は、コアプロトコルを小さく安定に保ちながら新機能を追加するための仕組みです。各拡張は reverse-DNS 形式の ID(例: io.modelcontextprotocol/tasks)で識別され、ext-* リポジトリで独立してバージョン管理されます。コアへの変更なしに新機能をシップできるため、仕様の安定性とエコシステムの拡張性が両立します。

最初の公式拡張として MCP Apps(SEP-1865)と Tasks 拡張(SEP-2663)が定義されました。MCP Apps はサンドボックス iFrame 内でサーバー描画の UI を提供する機能です。Tasks 拡張は従来コアの実験的機能だった長時間タスク管理を正式な拡張として独立させたもので、ツール呼び出しがタスクハンドルを返す新しいライフサイクルを定義します(MCP blog、2026-07-28)。

同時に3つの機能が廃止予定になりました(SEP-2577、12 ヶ月の移行期間)。Roots はツールパラメータ・リソース URI・サーバー設定への移行が推奨、Sampling は LLM プロバイダ API への直接統合が代替、Logging は stdio では stderr へ、構造化ログには OpenTelemetry への移行が求められます。

(A)agens の MCP 接続と新仕様

(A)agens は MCP のクライアント(外部ツールへの接続)とサーバー(agens 自身の公開)の両方に対応しています。接続はタスクごとの使い捨てサンドボックス越しに行い、OAuth/OIDC 認証を通して最小権限で絞ります。(B)MCP 2026-07-28 仕様のステートレス設計と拡張フレームワークは業界プロトコルとして全 MCP 実装に影響する変更です。接続先の基礎概念は「MCP とは」(homula.jp/learn)に詳しくあります。

🛡 既存の MCP 接続への影響

廃止予定(SEP-2577)の機能(Roots・Sampling・Logging)には 12 ヶ月の移行期間が設けられています。MCP 2026-07-28 仕様以前のサーバー・クライアント実装は移行期間中は引き続き動作する見込みです。詳しくは Agentic AI Foundation の公式マイグレーションガイドをご参照ください(blog.modelcontextprotocol.io、2026-07-28)。

よくある質問

MCP のステートレス化で何が変わりますか?
各リクエストが自己完結するため、任意のサーバーインスタンスがリクエストを処理できます。セッション粘着が不要になり、標準の HTTP ロードバランサーで水平スケールアウトできます。プロトコルの複雑さも下がり、サーバー実装の負荷が軽減されます(MCP blog、2026-07-28)。
既存の MCP サーバー実装は壊れますか?
廃止予定(SEP-2577)の機能には 12 ヶ月の移行期間があります。旧仕様の initialize ハンドシェイクやセッション ID を使っている実装は変更が必要ですが、移行期間中は互換モードが維持される見込みです(MCP release candidate blog、2026-07-28)。
MRTR(Multi Round-Trip Requests)は何のためにありますか?
双方向の永続ストリームなしで、ツール実行中のユーザー確認やパラメータ追加入力を実現するためです。ステートレスな HTTP 上でも人間の承認を組み込んだ AI エージェントフローが設計しやすくなります(SEP-2322)。
MCP Apps とは何ですか?
SEP-1865 で定義された公式拡張で、MCP サーバーがサンドボックス iFrame 内でユーザー向けの UI を描画できます。拡張フレームワーク(SEP-2133)の下でコアとは独立してバージョン管理されます。

最終更新: 2026-08