MCP 2026-07-28 仕様リリース候補 — ステートレス化とMCP Apps/Tasksで何が変わるか
MCPを使うエージェント実装の実践入門
ステートレス化と水平スケールの原理を学ぶ
開発から運用（LLMOps）まで通しで把握
当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。
MCPとリリース候補（RC）の位置づけ
Model Context Protocol（MCP）は、AIモデルとツールやデータソースをつなぐためのオープン標準です。Claude / Cursor / Windsurf / Zed などの主要AI製品がネイティブ対応しており、AIインテグレーションの事実上の標準になりつつあります。前提のおさらいはMCP 2026 ロードマップまとめを参照してください。
その次期仕様である2026-07-28版が、現在リリース候補（Release Candidate、RC）段階にあります。RC本文（公式ブログ）によれば、RCは2026年5月21日に公開され、正式版（normative specification）は2026年7月28日に公開予定です。RC公開から正式版までのあいだに10週間の検証ウィンドウが設けられており、SDKメンテナやクライアント実装者が実ワークロードに対して変更を検証する期間とされています。
WARNING
本記事執筆時点（2026年7月21日）で、この仕様はまだRC段階です。正式に確定した最終仕様ではありません。RC期間中に細部が変わる可能性があるため、実装判断の前に必ず一次情報（本文末尾のリンク）で最新状態を確認してください。
前版は2025-11-25版です。今回の2026-07-28版は、MCPが公開されて以来もっとも大きな改訂と公式に位置づけられており、2026ロードマップで掲げられた「通常のHTTPインフラでスケールするステートレスなコア」「拡張（Extensions）」「認可のOAuth/OpenID Connectへの整合」を具体化するものです。
なお正式版公開日（7月28日）は、あくまで「規範的な仕様テキストが公開される日」であり、現行プロトコルに依存する実装者にとっての「切り替え強制日」ではない、と公式は明言しています。既存実装が同日に動かなくなるわけではありません。
主な柱は次の6つです。
- プロトコルのステートレス化（セッションの廃止）
- Extensions フレームワーク（拡張が第一級市民に）
- MCP Apps（サンドボックスiframeで描画する対話的UI）
- Tasks 拡張（長時間実行の駆動）
- 認可（authorization）のハードニング
- 正式な非推奨（deprecation）ポリシー
以下、順に見ていきます。
なぜステートレス化するのか（従来のセッションの課題）
今回の目玉は、プロトコル層でMCPをステートレスにしたことです。
これまでのMCPは、接続の最初に initialize / initialized のハンドシェイクを行い、以後は Mcp-Session-Id ヘッダでセッションを識別する設計でした。この方式は単一プロセスでは素直ですが、水平スケール（サーバを複数インスタンスに増やす構成）では厄介でした。
- 同じセッションのリクエストを同じインスタンスに届けるスティッキールーティングが必要
- インスタンス間で状態を共有するセッションストア（共有キャッシュ等）が必要
- ロードバランサがヘッダを深く見て振り分ける必要があり、素の round-robin では回せない
つまり、プロトコルの都合がインフラ構成に強く漏れ出していました。この課題感は2026ロードマップでも水平スケールの論点として挙がっていたものです。
RC本文はこの点を次のように表現しています。任意のMCPリクエストが任意のサーバインスタンスに到達でき、水平デプロイがこれまで必要としていたスティッキールーティングと共有セッションストアはもう不要になる、という趣旨です。実運用上のメリットとしては、素の round-robin ロードバランサの背後でMCPサーバを動かせるようになります。振り分けはメソッドを示すヘッダ（RC本文では Mcp-Method ヘッダに言及）で行え、ペイロードのディープパケットインスペクションは不要になります。
具体的に何が削除・変更されたか
ステートレス化に伴う主な変更点を、before / after で整理します。
| 項目 | 従来（2025-11-25まで） | 2026-07-28 RC |
|---|---|---|
| 初期化 | initialize / initialized ハンドシェイク | 廃止 |
| セッション識別 | Mcp-Session-Id ヘッダ | 廃止 |
| ルーティング | スティッキー（同一インスタンスへ） | 任意リクエストが任意インスタンスへ |
| 能力・バージョン伝達 | 初期化時に一度交換 | 各リクエストの _meta で毎回運ぶ |
| 能力の事前取得 | ハンドシェイクに依存 | server/discover メソッドで取得 |
ポイントは、プロトコルバージョン・クライアント情報・ケイパビリティが、毎リクエストの _meta に載って運ばれるようになったことです。加えて、クライアントがサーバのケイパビリティをまとめて取得できる server/discover メソッドが追加されました。これにより、共有セッションストアなしに、コモディティなHTTPインフラ上でステートレスに動かせます。
擬似的なイメージとしては、従来は次のようにセッションIDをヘッダで引き回していました。
POST /mcp HTTP/1.1
Mcp-Session-Id: 6f1a...c3
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search"}}RCでは、セッションIDに頼らず、必要な文脈をリクエスト自身が持ちます（下記はあくまで概念を示す擬似例です。正確なフィールド構造はRC本文・SDKで確認してください）。
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"_meta": {
"protocolVersion": "2026-07-28",
"capabilities": { "extensions": {} }
}
}
}その他、ステートレス化と前後して、いくつかの技術的な整備も入っています。
- ツールのスキーマがJSON Schema 2020-12のフル機能をサポートし、
oneOf/anyOf/allOfなどの合成キーワード、条件分岐、参照が使えるようになりました。 - リソースが見つからない場合のエラーコードが、独自の
-32002からJSON-RPC標準の-32602へ変更されました。
Extensions フレームワーク
今回のもう一つの軸が、Extensions（拡張）を第一級市民に格上げしたことです。
拡張は逆DNS形式のID（reverse-DNSのID）を持ち、クライアントとサーバ双方のケイパビリティにある extensions マップを通じてネゴシエーションされます。拡張は仕様本体とは独立してバージョニングされるため、コア仕様のリリースサイクルに縛られずに機能を進化させられます。
この枠組みの上に、後述するMCP Apps（サーバ描画のUI）とTasks（長時間実行）が拡張として乗ります。従来コアに実験的に取り込まれていた機能を、拡張として切り出して独立に育てられる構造になったのが大きな変化です。
MCP Apps（サンドボックスiframeの対話的UI）
MCP Appsは、サーバがサンドボックス化されたiframe内に描画する、対話的なHTML UIを提供する拡張です。
仕組みの要点は次の通りです。
- ツールは、自身が使うUIテンプレートを事前に宣言します（プリフェッチとセキュリティレビューを可能にするため）。
- UIはサンドボックスiframe内で描画されます。
- UI上の操作は、すべて標準のJSON-RPCプロトコル経由でルーティングされます。
つまり、UIがサーバ側から供給されつつも、そのアクションは独自経路ではなく通常のMCPメッセージに落ちる、という設計です。事前宣言によってクライアント側がテンプレートを審査・キャッシュできる点は、任意HTMLをそのまま流し込む方式に比べてセキュリティ面の見通しが良くなります。とはいえUIを扱う以上、入力の扱いには注意が必要です。MCPまわりのセキュリティ観点はMCPのプロンプトインジェクション/RCEもあわせて押さえておくとよいでしょう。
ブラウザ側でエージェントにツールを供給する話題（WebMCP）とあわせて、「UIとツールの境界」がMCPの新しい論点になりつつあります。
Tasks 拡張（長時間実行の駆動）
Tasksは、時間のかかる処理を扱うための拡張です。2025-11-25版では実験的なコア機能でしたが、2026-07-28 RCで独立した拡張へ移動しました。ステートレス化に合わせてライフサイクルも再設計されています。
再設計後の駆動フローは次の通りです。
- サーバは
tools/callに対してタスクハンドルを返す - クライアントは
tasks/get/tasks/update/tasks/cancelで実行を駆動する
一方、セッションが無くなったことによるスコープの問題から、tasks/list は削除されました（セッションなしでは「誰のタスク一覧か」を安全にスコープしづらいため）。
擬似的なやり取りのイメージは次の通りです（フィールド名は概念を示す擬似例です）。
// 1. tools/call がタスクハンドルを返す
{
"jsonrpc": "2.0", "id": 1,
"result": { "task": { "id": "task_abc", "status": "working" } }
}
// 2. tasks/get で進捗を取りにいく
{
"jsonrpc": "2.0", "id": 2,
"method": "tasks/get",
"params": { "taskId": "task_abc" }
}NOTE
2025-11-25版の実験的Tasks APIを使っている実装は、更新が必要です。ハンドルベースのライフサイクルと tasks/list の削除を前提に、呼び出し側のポーリング処理を見直してください。
認可（authorization）のハードニング
認可まわりは、OAuthおよびOpenID Connectの実デプロイへの整合を強める方向で複数のSEP（仕様提案）により強化されました。主な内容は次の通りです。
- クライアントは、レスポンスをどの認可サーバが発行したかを
issパラメータで検証する（RFC 9207準拠）。認可サーバの移行には再登録が必要。 - クライアントは登録時に、OpenID Connectの
application_typeを宣言する（デスクトップ/CLIクライアントを既定で「web」と扱ってlocalhostリダイレクトを拒否する、といった設定ミスを解消するため）。 - 資格情報（credential）を、特定の認可サーバの
issuer値に束縛する。 - スコープの累積（step-up認可時）や、
.well-knownによるディスカバリの挙動を明確化。
RC本文と解説記事によれば、これらはOAuth 2.1のリソースサーバモデル（RFC 9728のProtected Resource Metadata、RFC 8707のResource Indicators等）への整合を進めるものです。
NOTE
SEPの正確な番号（SEP-xxxx）の対応づけは、解説ソース間で表記に揺れが見られました。個別のSEP番号を実装根拠にする場合は、GitHubのmodelcontextprotocol/specificationで一次確認することを推奨します（本記事では要確認扱いとします）。
MCPの認可設計は、AIエージェントの認証・認可という広いテーマにつながります。実際のセットアップ例としてはClaude CodeとGoogle Calendar MCPの連携のような、OAuthを伴う接続が参考になります。
正式な非推奨（deprecation）ポリシー
今回、正式な非推奨ポリシーが導入されました。これまで日付ベースのリリースで機能が入れ替わる際、互換性の扱いが明文化されていませんでしたが、今後は非推奨のライフサイクルが定められます。
RC本文では、次の3機能が新ポリシーのもとで非推奨に入るとされています。
| 非推奨になる機能 | 代替 |
|---|---|
| Roots | ツールのパラメータ、リソースURI、サーバ設定 |
| Sampling | LLMプロバイダAPIとの直接統合 |
| Logging | stderr または OpenTelemetry |
重要なのは、非推奨になっても即座には壊れない点です。RC本文は、これらのメソッド・型・ケイパビリティフラグは本リリースでも、そしてそれから1年以内に公開される各仕様版でも動作し続ける、という趣旨を述べています。移行のための猶予が明文で保証される形です。
開発者はいつ何をすべきか（移行と検証）
現時点（2026年7月21日）での実務的な優先順位を整理します。
- まずはRC本文を読む。ステートレス化・Extensions・MCP Apps・Tasks・認可・非推奨の6本柱を、自分の実装のどこに影響するかで棚卸しします。
- ベータSDKで検証する。公式ブログ（2026年6月29日付）によれば、Python / TypeScript / Go / C# のTier 1 SDKに、2026-07-28 RC対応のベータがすでに提供されています。Tier 1 SDKは検証ウィンドウ内での対応が期待されています。
- ステートレス前提でインフラを見直す。
Mcp-Session-Idに依存したスティッキー構成や共有セッションストアを、round-robin +_meta前提へ移せるか確認します。 - Tasksを使っている場合は書き換える。ハンドルベースのライフサイクルへ移行し、
tasks/list依存を外します。 - 認可を点検する。
iss検証、application_type宣言、issuer束縛に対応できているか確認します。 - 非推奨機能（Roots / Sampling / Logging）を使っているなら、代替への移行計画を立てます。1年以内は動作が保証される見込みですが、早めに動くほど安全です。
いずれも「7月28日に一斉切り替え」ではなく、猶予のなかで段階的に進める性質のものです。あわてて本番を差し替える必要はありませんが、RC段階のうちにベータSDKで手を動かしておくと、正式版公開後の移行がスムーズになります。
まとめ
- 2026-07-28版MCP仕様は、本記事時点でRC段階（RC公開2026年5月21日、正式版予定2026年7月28日、検証ウィンドウ10週間）。まだ確定ではありません。
- 最大の変更はプロトコルのステートレス化。
initializeハンドシェイクとMcp-Session-Idを廃し、_metaとserver/discoverで文脈を運ぶことで、素のround-robin背後でも動くようになります。 - Extensionsが第一級市民になり、その上にMCP Apps（サンドボックスiframeのUI）とTasks（ハンドルベースの長時間実行）が乗ります。
- 認可はOAuth/OpenID Connectへ整合を強め、非推奨ポリシーが明文化されました（Roots / Sampling / Logging が対象、1年以上の互換維持見込み）。
- 開発者はベータSDK（Python / TypeScript / Go / C#）で早めに検証し、ステートレス前提のインフラとTasks・認可の移行を進めるのが得策です。
一次情報が更新される領域なので、実装判断の前に必ず公式仕様とGitHubで最新状態を確認してください。
