MCP 2026-07-28 RC解説：ステートレス化がもたらすAIエージェント実装

Model Context Protocol (MCP) は、2024年11月の初版リリース以来、AIモデルと外部データ・機能を接続する標準プロトコルとして急速に進化してきました。
今回の2026-07-28 Release Candidate（以下、RC）は、単なる機能追加ではなく、プロトコルの実運用前提を大きく変える改訂です。

とくに注目すべきは、プロトコル層のステートレス化です。
セッション管理を外し、ロードバランシング・再試行・観測性・キャッシュ運用をHTTP標準に近い形へ寄せることで、エンタープライズ環境でも扱いやすい構成へ移行しようとしています。

本ページでは、この改訂内容を仕様差分と実装視点で、RCの要点、仕様の変遷、具体的な変更点という流れで説明します。

公式ブログ: The 2026-07-28 MCP Specification Release Candidate

今回のRCは「機能追加」より、「実運用前提の再設計」が主眼になります。
とくに、プロトコル層セッションを廃止してステートレスにシフトすることで、ロードバランシング、再試行、観測性、キャッシュ運用がHTTP標準の作法に近づきました。
さらに、Extensions（MCP Apps/Tasks）、認可強化、非推奨ライフサイクルが同時に導入され、仕様の進化プロセスも整備されています。

• 最大のBreaking Changeは、プロトコル層セッションを廃止し、ステートレスファーストへ移行
• Streamable HTTPは、自己完結リクエスト+必須ヘッダーへ移行
• サーバー起点の入力要求は、SSE維持型から InputRequiredResult+再送 のマルチラウンドトリップへ移行
• Dynamic Client RegistrationはClient ID Metadata Documentsへの移行が推奨される
• MCP AppsとTasksは、Extensionとして正式化
• 入出力スキーマがJSONスキーマ（2020-12）に準拠

timeline
  2024-11-05 初版リリース
    : コアアーキテクチャの定義 （Tools, Resources, Prompts）
    : 周辺機能の定義 （Roots, Sampling, Logging, HTTP+SSE）
  2025-03-26 通信と認証の強化
    : StreamableHTTP導入
    : OAuth2による認証整備
  2025-06-18 プロトコルの簡素化、構造化
    : JSON-RPCバッチ処理の廃止
    : 構造化出力 （structuredContent）対応
  2025-11-25 UXと大規模運用の布石
    : 段階的スコープ同意 （認証強化）
    : アイコン表示対応
    : Tasksの実験的サポート
  2026-07-28 ステートレスへの転換
    : ステートレス化
    : キャッシュ管理の導入
    : ルーティング最適化
    : 初期機能の非推奨化
    : MCP Apps
    : Tasksを拡張へ移動

• 2026-05-21: RC確定
• 2026-07-28: 最終仕様の公開予定
• 非推奨確定～最低12カ月以内: 非推奨機能の削除禁止期間

今回予定されている仕様変更は下記の通りです。
🚨はBreaking Changeを示します。

1. プロトコルのステートレス化: initialize/セッション依存を廃止し、自己完結リクエストへ移行
   • 🚨 リクエストモデルの変更: 必須ヘッダーと_metaを毎リクエストで送信
   • 🚨 レスポンスモデルの変更: resultTypeが必須化
   • 🚨 ハンドシェイクとセッションの廃止: initialize, initialized, Mcp-Session-Idを廃止
   • ステートレスプロトコルにおけるステートフルアプリケーション: Explicit Handle方式で状態を引き回す
   • 🚨 サーバーからクライアントへのリクエストを再構築: input_required, requestStateを用いた再送モデルへ
   • 🚨 ルーティング（必須HTTPヘッダーによるトラフィック制御）: ボディ解析なしでルーティング可能にし、検証を厳格化
   • キャッシング機構の導入: ttlMs, cacheScopeで鮮度と共有可否を明示
   • 観測性（W3C Trace Contextの伝搬を標準化）: traceparentなどで分散トレース相関を標準化
   • 🚨 変更通知の再編: subscriptions/listen中心に再編し、旧購読APIを整理
2. MCP Apps: サーバーレンダリングUIを公式Extensionとして扱う
3. 🚨 Tasks APIをエクステンションへ移行: コア実験機能からExtensionへ再設計
4. 認可の強化: OAuth2.0/OIDC運用に寄せた要件を強化
5. 🚨 機能の非推奨化: Roots、Sampling、LoggingをDeprecated化
6. 入出力スキーマがJSONスキーマ（2020-12）に準拠: 表現力を拡張し、バリデーション要件を明確化
7. ガバナンスの変更: Lifecycle、Extensions TrackおよびConformance連動を明文化

これまではStreamable HTTP通信において、まずinitializeリクエストでセッションを確立し、以降のリクエストにはMcp-Session-Idヘッダーを付与する必要がありました。
2026-07-28ではこの接続確立フロー全体がプロトコル層から除去されます。

リクエストモデルの変更

リクエストモデルに以下の変更が入ります。

• リクエストごとに_metaへプロトコルバージョンや機能宣言（capabilities）を内包します。

• ヘッダーおよび_metaで指定したプロトコルバージョンが一致していること。不一致の場合はHeaderMismatchError（-32020）で拒否されます。

• 要求したバージョン自体がサーバー非対応の場合はUnsupportedProtocolVersionError（-32022）が返されます。

• 2025-11-25仕様

  初回

  {
  "jsonrpc":"2.0","id":1,"method":"initialize",
  "params":{
      "protocolVersion":"2025-11-25",
      "capabilities":{},
      "clientInfo":{"name":"sample-client","version":"1.0.0"}
  }
  }
  

  2回目以降

  Mcp-Session-Id: 1a2b3c4d-5e6f-7g8h
  {
  "jsonrpc": "2.0","id": 2,"method": "tools/call",
  "params": {
      "name": "get_user",
      "arguments":{"user_id":"u123"}
  }
  }
  

• 2026-07-28仕様

  MCP-Protocol-Version: 2026-07-28
  Mcp-Method: tools/call
  Mcp-Name: get_user
  
  {
  "jsonrpc": "2.0","id": 1,"method": "tools/call",
  "params": {
      "name": "get_user",
      "arguments": { "user_id": "u123" },
      "_meta": {
      "io.modelcontextprotocol/protocolVersion":"2026-07-28",
      "io.modelcontextprotocol/clientInfo":{"name":"sample-client","version":"1.0.0"},
      "io.modelcontextprotocol/clientCapabilities":{}
      }
  }
  }
  

レスポンスモデルの変更

レスポンスモデルに以下の変更が入ります。

• resultTypeが必須化（取りうる値: complete, input_required）

  {
  "resultType": "input_required",
  "inputRequests": {
      "confirm": {
      "type": "elicitation",
      "message": "3ファイルを削除しますか？",
      "schema": { "type": "boolean" }
      }
  },
  "requestState": "1a2b3c4d5e6f7g8h9i0j..."
  }
  

ハンドシェイクとセッションの廃止

通信の開始と維持に使用していたセッション管理が変更されます。
これにより、スティッキールーティングやセッション管理が不要になるため、水平スケーリングが容易になります。

• 2025-11-25仕様

  sequenceDiagram
  actor c as MCP Client
  participant s as MCP Server
  
  c->>+s: initialize（セッション確立）
  s-->>-c: 
  c->>+s: tools/call(<br>Mcp-Session-Id, <br>name: get_user)
  s-->>-c:

• 2026-07-28仕様

  sequenceDiagram
  actor c as MCP Client
  participant s as MCP Server
  
  c->>+s: tools/call(<br>MCP-Protocol-Version: 2026-07-28, <br>Mcp-Method: tools/call, <br>Mcp-Name: get_user)
  s-->>-c:

ステートレスプロトコルにおけるステートフルアプリケーション

プロトコルがステートレスになっても、アプリケーションが状態を持つことはできます。

ステートレス化に伴い、状態管理の責任はトランスポート層からアプリケーション層（モデルとの対話）へと移動します。
セッションへ依存する替わりに、サーバーは明示的なハンドルをツールの戻り値として発行して、次回のツール呼び出し時に引き渡す設計が推奨されます。
これにより、状態がモデルの推論コンテキストに統合され、より柔軟な推論制御が可能になります。

sequenceDiagram
  autonumber

  actor client as Model
  participant server as MCP Server

  client ->> server: create_basket
  server -->> client: {"basket_id": "b001"}
  client ->> server: add_item("basket_id": "b001", arg0: xyz)

• 2のレスポンス: basket_idやcontext_tokenのような明示的なハンドル（Explicit Handle）をツールの戻り値として発行する必要があります。

サーバーからクライアントへのリクエストを再構築

サーバーが処理中にクライアントへ追加入力を求めるエリシエーションは、接続を維持する替わりにInputRequiredResultを返却し、それを再度リクエストで投げ直す仕組みに再設計されます。

sequenceDiagram
  autonumber

  actor client as MCP Client
  participant server as MCP Server

  client ->> server: tools/call
  server -->> client: 追加入力の要求（InputRequiredResult）
  client ->> server: 同じtools/callをinputResponses+requestStateで再送
  server -->> client: 最終的な結果

• サーバーからの入力要求は「アクティブなクライアント要求の処理中」に限定されます。「突然のプロンプト」は禁止され、すべてのエリシテーションはユーザーが開始したアクションに紐付く必要があります。
• 2のレスポンス

  {
  "resultType": "input_required",
  "inputRequests": {
      "confirm": {
      "type": "elicitation",
      "message": "3ファイルを削除しますか？",
      "schema": { "type": "boolean" }
      }
  },
  "requestState": "1a2b3c4d5e6f7g8h9i0j..."
  }
  

  • InputRequiredResultにはrequestStateが必要。

関連SEP

• マルチラウンドトリップ: SEP-2322 Multi Round-Trip Requests
• サーバー発の入力要求の制約: SEP-2260 Server-initiated requests constraints

ルーティング（必須HTTPヘッダーによるトラフィック制御）

Streamable HTTPで下記の3ヘッダーが必須になります。
これにより、ロードバランサー、ゲートウェイ、レートリミットがリクエストボディを解析（DPI）せずルーティングできるようになります。
ヘッダーとボディの内容が一致しない場合、サーバーはリクエストを拒否します。

関連SEP

• ルーティングヘッダー: SEP-2243

キャッシング機構の導入

リスト応答（tools/listなど）にキャッシュ機構が導入されます。
これにより、MCPクライアントはレスポンスの有効期間（ttlMs）とスコープ（cacheScope）を認知できます。
リストの変更を知る場合、これまではSSEストリームを維持して検知するのが唯一の手段でしたが、これに代替する手段として活用できます。

• ttlMs: ミリ秒単位の有効期間。
• cacheScope: public（共有可）またはprivate（個別ユーザー限定）。

関連SEP

• キャッシュ機構: SEP-2549

観測性（W3C Trace Contextの伝搬を標準化）

分散トレーシングをサポートするため、_metaフィールドにW3C Trace Context（traceparent, tracestate, baggage）の伝播が標準化されました。
これにより、OpenTelemetry互換のバックエンドで、ホストからサーバー、さらにその先のバックエンドまでを一貫したスパンツリーとして可視化できます。

関連SEP

• 観測性: SEP-414

変更通知の再編

変更通知もステートレス化に合わせて再編されています。
これまでの「接続やセッションに連なる通知」から、明示的なリクエストに紐づく通知へ再編されます。

主な変更点

• 変更通知はsubscriptions/listenのレスポンスストリームで受信する形に統一されます。
• 旧来の購読API（resources/subscribe, resources/unsubscribe）は整理されます。
• 旧来のGETベースのSSE受信および再開機構（Last-Event-ID）は対象外です。
• notifications/progressおよびnotifications/messageは、subscriptions/listenではなく「そのリクエスト自身のレスポンスストリーム」に流れます。
• クライアント実装は「変更通知ストリーム」と「個別リクエストの進捗通知」を分離して扱う必要があります。
• 接続断の復旧時は、過去ストリーム再開ではなく、必要なリクエストを再送する設計が前提になります。

サーバーがHTML UIテンプレートを提供し、クライアントがサンドボックス化されたiframe内で描画する機能です。
データの可視化や複雑なフォーム入力を可能にします。
UI内のアクションはすべてJSON-RPCプロトコルを通じて伝達されるため、監査ログや同意フローの対象として統合管理が可能です。

特徴

• 単なるテキスト応答ではなく、MCPサーバー主導のUI体験を組み込める
• ツール定義時にUIテンプレートを宣言する設計が必要
• セキュリティレビュー対象が「ツール実装 + UIテンプレート」に広がる

関連SEP

• MCP Apps: SEP-1865

2025-11-25でコア機能として実験的に導入されたTasksがエクステンションとして再設計されます。
2025-11-25のTasks APIを実装している場合は、移行が必要です。

関連SEP

• Tasks API: SEP-2663

認可仕様がOAuth2.0+OIDC(OpenID Connect)の実運用に即した形で強化されます。
とくに（RFC9207）issは、MCPの多サーバー接続構成で起きやすいmix-up系リスクへの対策として重要です。

• Authorization Responseのiss検証
  • 認可レスポンス（Authorization Response）に含まれるissパラメーターの検証が、MCPクライアント側で必須になります。
  • これにより、1つのクライアントが複数のサーバーと接続するMCP特有の構成において発生しやすい「ミックスアップ攻撃（認可コードを悪意あるサーバーにだまし取られる攻撃）」を低コストで対策できます。
• 動的クライアント登録（Dynamic Client Registration）時のapplication_type宣言
  • 動的クライアント登録する際、クライアントは適切なapplication_typeを宣言することが必須になります。
  • これにより、認可サーバーがデスクトップやCLIを誤ってWebアプリと判定し、セキュリティ上の理由からlocalhostのリダイレクトURIを拒否してしまうような、実装上の競合を回避します。
• クライアント資格情報（Credentials）の認可サーバー（issuer）の紐づけ強化
  • クライアント資格情報は、それを発行した認可サーバーに厳密に紐づけされなければなりません。他の認可サーバーへの使い回しは禁止され、リソースサーバーの認可サーバーが変更された場合は再登録を義務付けています。
• リフレッシュトークンを要求する方法の明文化
• ステップアップにおけるスコープ蓄積動作の定義
  • 権限の累積によって段階的に権限付与する動作（e.g. 最初にread権限を付与し、次いでwrite権限を追加。累積する形で権限を構成する）
• .well-known discovery suffixの定義

関連SEP

• Authorization Responseのiss検証: SEP-2468
• Dynamic Client Registrationのapplication_type宣言: SEP-837
• クライアント資格情報のissuer紐づけ: SEP-2352
• リフレッシュトークン要求: SEP-2207
• ステップアップのスコープ蓄積: SEP-2350
• .well-known discovery suffix: SEP-2351

3機能が非推奨（Deprecated）になります。
非推奨から削除までは12カ月間の猶予があるため、その間に移行が必要です。

関連SEP

• 機能の非推奨化: SEP-2577

ツールの入出力スキーマ（inputSchema, outputSchema）がJSON Schema（2020-12）に対応しました。
これにより、oneOf, anyOf, allOfおよび$refによる高度なスキーマ定義が可能になり、ツールの型安全性が向上します。

出力スキーマはオブジェクトだけでなく任意のJSON値を使用できます。

また、リソース未検出のエラーコードがMCPカスタム（-32002）から、JSON-RPC標準（-32602: 無効なパラメーター）に変更されます。

関連SEP

• JSON Schema 2020-12: SEP-2106
• リソース未検出エラーコード変更: SEP-2164

今後は同規模の破壊的変更を常態化しないための仕組みも同時に導入されています。

• 機能ライフサイクル（Feature Lifecycle）（Active/Deprecated/Removed）
  • 全機能にActive、DeprecatedおよびRemovedの状態を定義し、DeprecatedからRemovedまで最低12カ月の猶予を義務化します。
  • これにより、将来改訂での破壊的変更が予測可能になります。
• Extensions Trackの正式化
  • 新機能はまず拡張として提案および検証し、成熟したもののみコアへ取り込む運用に整理されました。
  • 公式拡張は独立リポジトリ（ext-*）で管理され、コア仕様と独立して進化できます。
• SEPとConformance Suiteの連動強化
  • 標準化トラックのSEPは、対応シナリオがConformance Suiteに入るまでFinalに到達できません。
  • 仕様策定と実装検証の乖離を抑え、SDK実装の相互運用性を高めます。

関連SEP

• Feature Lifecycle: SEP-2596
• Extensions Track: SEP-2133
• Conformance Suite連動: SEP-2484
• SDK tier system: SEP-1777

実装者向けに、確認したい項目を簡単に整理します。

• プロトコルのステートレス化: トランスポート層の移行
  • initialize, initialized前提コードの棚卸し
  • Mcp-Session-Id依存コードの洗い出し
  • リクエストヘッダーにMcp-Method, Mcp-Name, MCP-Protocol-Versionを設定
  • _metaに必須キー（protocolVersion, clientInfo, clientCapabilities）をリクエストごとに設定
  • HTTPヘッダーと_metaの一致検証失敗（-32020）および非対応バージョン（-32022）をハンドリング
  • server/discover呼び出しを実装し、対応バージョンとcapabilitiesを事前確認
  • レスポンスにresultTypeを設定
  • 変更通知の受信設計をsubscriptions/listen前提へ移行
• 認可の強化: 認可運用の見直し
  • Authorizationのiss検証対応を確認
  • Dynamic Client Registrationの移行方針を整理
  • トレースコンテキストの伝播確認とログ収集設計を見直す
• 拡張機能と非推奨機能の整理
  • MCP Appsの導入有無を判断
  • Tasks APIの旧API利用箇所を抽出
  • Roots, Sampling, Loggingの移行計画を策定
  • エラーコードの変更: -32002から-32602
• SDKの更新
  • 各言語のTier 1 SDKを最新版にアップデートし、ステートレス実装へ移行する

今回の改訂は、単なる仕様の更新ではなく、MCPを「ステートレスなHTTP基盤上で運用するプロトコル」へ再設計するものです。
ステートレス化によるスケーラビリティ、W3C Trace Contextなどによる運用ガバナンス強化は、エンタープライズ導入における技術的障壁を下げる効果が期待できます。