MCP（Model Context Protocol）を実装している人にとって、2026年は「作り直し」の年になる可能性が高い。現行の確定仕様2025-11-25はいまもステートフル（initializeハンドシェイク＋MCP-Session-Id前提）だが、次期仕様のリリース候補2026-07-28 RCでは、その前提を外す「ステートレスコア」が目玉として提案されている。本記事は、二次情報ではなくMCP公式の変更履歴・公式ブログ・GitHub上のSEP（Spec Enhancement Proposal）を1件ずつ照合し、「いま確定していること」と「RC段階の提案にすぎないこと」を明確に分けて整理する。サーバー/クライアントを書いている人が、今から何を準備すべきかが分かるように書いた。
この記事の前提（重要）
RC（Release Candidate）は確定仕様ではない。SEP番号・メソッド名・ヘッダ名はRC段階で変わりうる。本記事では確定済み（2025-11-25 GA）を「確定」、RC/提案段階を「提案」と明記する。実装に落とす前に必ず公式仕様で最新状態を確認してほしい。
いま何が起きているのか — 2025-11-25確定とRCの位置関係
まず時系列で整理する。MCPの仕様は日付バージョン（例: 2025-06-18）で管理されており、現在の最新確定（GA）仕様は2025-11-25だ。そして次の仕様に向けたリリース候補が2026-07-28 RCとして公開されている。
| マイルストーン | 日付 | ステータス | 中心テーマ |
|---|---|---|---|
| 2025-06-18 仕様 | 2025-06-18 | 旧確定 | 認可・elicitation等 |
| 2025-11-25 仕様 | 2025-11-25 | 現行確定（GA） | Tasks（実験的）導入・SSEポーリング・認可強化 |
| Transport Working Group ブログ | 2025-12-19 | 方向性の共有 | 「プロトコルはステートレスでよい」という構想 |
| 2026-07-28 RC | RC確定: 2026-05-21 / 最終予定: 2026-07-28 | リリース候補（提案） | ステートレスコア・Tasks拡張化・MCP Apps公式化 |
つまり本記事執筆時点（2026年6月）では、RCは公開済みだが、最終版2026-07-28はまだ先（数週間後）という状態だ。Tier 1 SDKはこの期間に対応を出すと公式に告知されている。ここを誤解すると「もうステートレスが確定した」と勘違いして本番を壊しかねない。順を追って、確定済みの足元から見ていく。
確定済み（2025-11-25）— 現行コアはまだステートフル
「MCPはステートレスに移行した」という言い方をたまに見るが、現行の確定仕様2025-11-25のコアはステートフルのままだ。公式の基本仕様（Base Protocol）には今も明確に “Stateful connections” と書かれている。Streamable HTTPトランスポートのセッション管理は次の建て付けになっている（いずれも公式仕様の文言ベース）。
- サーバーは初期化時に
MCP-Session-IdヘッダをInitializeResultのHTTPレスポンスで付与してよい（MAY） MCP-Session-Idが返ってきたら、クライアントは以降の全リクエストにこのヘッダを付与しなければならない（MUST）- セッションを必須とするサーバーは、初期化以外で
MCP-Session-Idなしのリクエストに HTTP 400 を返してよい - サーバーがセッションを破棄したら、そのIDのリクエストには HTTP 404 を返す。クライアントは404を受けたら新しい
InitializeRequestを投げ直す
つまり今の「正しいMCPサーバー」は、初期化ハンドシェイク（initialize / initialized）を経て、必要ならセッションIDで状態を紐付ける設計だ。複数インスタンスにロードバランスする場合は、セッションのスティッキー化か共有ストア（Redis等）が事実上必要になる。Streamable HTTPの具体的なクライアント/サーバー実装はこの前提で組まれている。
ただし「長時間接続を持たない」流れは既に始まっている
見落としがちだが、2025-11-25のSSE仕様には既に「長寿命接続を避ける」方向の規定が入っている（SEP-1699）。具体的には次のとおり。
- サーバーはSSEストリーム開始時、イベントIDと空の
dataを即座に送る（クライアントがLast-Event-IDで再接続できるよう「プライミング」する） - イベントIDを送った後、サーバーは長寿命接続を抱えないために、いつでも接続を閉じてよい（SSEストリーム自体は終了せずに）
- クライアントは再接続して「ポーリング」する。
retryフィールドが来たらその時間だけ待つ
これは「ステートレス化」そのものではないが、HTTP標準インフラ（CDN・LB・タイムアウト）と相性の悪い長寿命SSEへの依存を減らす布石になっている。RCのステートレスコアは、この延長線上にある（Transport Working Groupの構想を参照）。
確定済み（2025-11-25）— Tasks（実験的）という新プリミティブ
2025-11-25で最も実装に影響する新要素が Tasks だ。公式仕様には “currently considered experimental”（現在は実験的とみなす）と明記されており、確定仕様に入っているが安定保証はないという微妙な位置づけ（SEP-1686）。設計が将来変わりうる前提で扱う必要がある。
Tasksは「重い処理・バッチ・人間の承認待ち」のような長時間リクエストを、接続を握りっぱなしにせずに扱うための仕組みだ。リクエストを「タスクで拡張」し、受信側が生成した taskId でポーリングする。重要なのは、2025-11-25版では新メソッド tasks/create は存在しない点。タスク化はリクエストのparamsに task フィールドを足すことで行う。
// 確定版（2025-11-25）: paramsに task を足してタスク化
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": { "city": "New York" },
"task": { "ttl": 60000 }
}
}
// レスポンスは結果ではなく CreateTaskResult（taskId入り）が返る
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"task": {
"taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
"status": "working",
"createdAt": "2025-11-25T10:30:00Z",
"lastUpdatedAt": "2025-11-25T10:40:00Z",
"ttl": 60000,
"pollInterval": 5000
}
}
}確定版2025-11-25のTasksで、実装者が押さえるべき要点（すべて公式仕様の文言ベース）。
| 要素 | 確定版2025-11-25の仕様 |
|---|---|
| メソッド | tasks/get（ポーリング）, tasks/result（結果取得）, tasks/list, tasks/cancel |
| タスク化の方法 | リクエストparamsに task フィールド（tasks/create メソッドは無い） |
| 結果の取得 | 完了後に tasks/result で取得（CreateTaskResult とは別） |
| ステータス | working / input_required / completed / failed / cancelled |
| ケイパビリティ宣言 | 初期化時に tasks ケイパビリティ（tasks.requests.tools.call 等） |
| ツール単位の制御 | tools/list の execution.taskSupport が "required" / "optional" / "forbidden" |
| 途中入力 | input_required に遷移 → 要求側は tasks/result を呼びelicitation等を受ける |
| 関連付け | 全メッセージの _meta に io.modelcontextprotocol/related-task |
ステータス遷移は厳密に定義されている。working から開始し、input_required を経由しうるが、completed / failed / cancelled は終端状態でそれ以上遷移しない。タスクIDは受信側が生成し、認可コンテキストがあるならタスクをそのコンテキストに束縛しなければならない（MUST）。認可がない環境では「タスクIDを推測できる第三者に結果が漏れうる」と仕様自身が警告しており、MCPのセキュリティ設計と合わせて、タスクIDの十分なエントロピーと短いTTLが推奨される。
提案（RC 2026-07-28）— ステートレスコアという目玉
ここからはRC段階の提案。確定ではない。公式ブログのRC要約によると、2026-07-28 RCのヘッドラインは「Stateless Protocol Core（ステートレスコア）」だ。具体的には次の方向で再設計される（SEP-2567 / SEP-2575が関連として挙げられている）。
initialize/initializedハンドシェイクを廃止（必須の初期化往復をなくす）MCP-Session-Idヘッダを廃止（スティッキーセッション・共有セッションストアを前提にしない）- 結果として、プロトコルが「任意のサーバーインスタンス」で動くことを狙う
この思想の源流は、ドラフト段階のSEP-1442「Make MCP Stateless (by default)」にある。SEP-1442は「必須の初期化ハンドシェイクを任意にし、ステートレスを既定にする」「プロトコル複雑性と状態のpay as you goモデル」を掲げ、server/discover RPCで任意のケイパビリティ交渉を行う形を提案している（2026年6月時点でDraft / in-review）。さらに2025-12-19のTransport Working Groupブログは「エージェント・アプリケーションはステートフルでよいが、プロトコル自体はそうである必要はない」という設計哲学を明言している。
なぜステートレスが効くのか
ステートレスにできると、サーバー側はLB配下に水平スケールしやすくなり、サーバーレス（Lambda等）にも載せやすい。「状態が必要なアプリは、アプリ層やデータモデル層で明示的に状態を持つ」分業に変わる。ステートフルが必要なら依然サポートされるが、既定がステートレスになるのが転換点だ。
提案（RC 2026-07-28）— Tasksは「コア実験機能」から「拡張」へ降りる
ここが実装者にとって最大の注意点であり、同じ「Tasks」でも確定版とRC/拡張版でメソッドと形が違う。混同してコードを書くと動かない。RCではTasksが実験的コア機能から拡張（Extension）に格下げ・再設計される（SEP-2663）。再設計版は experimental-ext-tasks リポジトリで仕様化されており、要点はこうだ。
| 観点 | 確定版（2025-11-25 コア） | 提案版（RC/拡張 ext-tasks） |
|---|---|---|
| 位置づけ | 実験的だがコア仕様内 | 公式Extension（コア外） |
| 結果取得 | tasks/result という別メソッド |
tasks/get のレスポンスに result がインラインで入る |
| 結果の型識別 | CreateTaskResult（task入りresult） |
resultType: "task" で判別 |
| 途中入力の返し方 | tasks/result 経由でelicitationを受ける |
tasks/get の inputRequests → tasks/update で応答 |
| ポーリング間隔 | pollInterval（ms） |
pollIntervalMs |
| TTL | ttl |
ttlMs |
| ケイパビリティ | tasks ケイパビリティ |
extensions 内の io.modelcontextprotocol/tasks |
// 提案版（RC/拡張 ext-tasks）: tasks/update で途中入力を返す
// クライアントは per-request capabilities で拡張をオプトイン
{
"params": {
"_meta": {
"io.modelcontextprotocol/clientCapabilities": {
"extensions": {
"io.modelcontextprotocol/tasks": {}
}
}
}
}
}共通している思想は「長寿命接続を持たず、durableなハンドル（taskId）でクラッシュ後も再開する」点で、これはステートレスコアと完全に同じ方向を向いている。だからこそRCでTasksが「拡張」として切り出され、ステートレスモデルに合わせて作り直された、と理解すると筋が通る。FastMCP等のフレームワークでサーバーを書いている場合、ライブラリがどちらのTasks設計を実装しているかで挙動が変わるため、SDKのバージョンとExtension対応状況を必ず確認したい。
提案／確定が混在 — MCP AppsとExtensionsフレームワーク
Extensionsフレームワーク（SEP-2133）
RCでは、コア仕様の外に機能を追加するためのExtensions（拡張）フレームワークが正式化される（SEP-2133）。これは「モジュール的な機能（認証など）」「特定領域向け」「実験的に育てる機能」をコア本体から切り離す仕組みだ。要点（公式の拡張概要ベース）。
- 拡張は
{ベンダープレフィックス}/{拡張名}形式の識別子（公式拡張はio.modelcontextprotocolプレフィックス。例:io.modelcontextprotocol/oauth-client-credentials） - クライアント/サーバーは初期化時に
extensionsケイパビリティで対応を宣言する - 拡張は既定で無効。開発者の明示的オプトインが必要
- 公式拡張は
ext-、実験的拡張はexperimental-ext-プレフィックスのリポジトリに置かれる - SEP（Extensions Track）でレビューされ、最低1つの公式SDKでの参照実装が必須
MCP Apps（SEP-1865）
MCP Appsは「チャット内にインタラクティブなHTML UI（グラフ・フォーム・ダッシュボード・動画プレイヤー）をレンダリングする」拡張だ。注意点として、MCP Appsはコア仕様ではなくExtensionであり、独自仕様は ext-apps リポジトリ（仕様日付 2026-01-26）にある。RCで公式拡張として整理される（SEP-1865）。技術的な核は次のとおり（公式のMCP Apps概要ベース）。
- ツールが説明（description）の中で
_meta.ui.resourceUriとしてui://リソースを参照する - ホストはそのUIリソース（HTML/JS/CSS）を取得し、サンドボックス化されたiframeでレンダリングする
- アプリとホストは
postMessage上のJSON-RPC方言で双方向通信（ui/initializeなどui/プレフィックスのメソッド） - アプリはサンドボックスから親ページのDOM・Cookie・localStorageにアクセスできない（セキュリティ保証）
- 外部読み込みは
_meta.ui.csp、追加権限（カメラ等）は_meta.ui.permissionsで制御 - パッケージ
@modelcontextprotocol/ext-appsのAppクラスは便利ラッパーで必須ではない
現時点でMCP Appsに対応するホストは、Claude / Claude Desktop / VS Code GitHub Copilot / Goose / Postman 等（公式のクライアントマトリクス参照）。ホストごとに対応状況が異なるため、配布前に対応クライアントを確認する必要がある。
提案（RC 2026-07-28）— その他の主要変更
RCにはステートレス化に付随する変更が多数含まれる。実装に効くものを公式ブログ要約ベースで挙げる（いずれもSEP番号付きの提案であり確定ではない）。
| 変更 | SEP | 実装への影響 |
|---|---|---|
ルーティング用ヘッダ必須化（Mcp-Method / Mcp-Name） |
SEP-2243 | LB/プロキシがHTTPヘッダだけでRPC種別・ツール名を判別できる＝ステートレス運用の要 |
| サーバー→クライアントrequest の再設計 | SEP-2260 / SEP-2322 | ステートレス前提でのサーバー起点通信の組み直し |
キャッシュ対応（ttlMs / cacheScope） |
SEP-2549 | レスポンスのキャッシュ可能化 |
| ツールのJSON Schema 2020-12 フル対応 | SEP-2106 | ツール入出力スキーマの表現力向上（2025-11-25では既定方言が2020-12に） |
| トレースコンテキスト標準化 | SEP-414 | 分散トレーシングの相互運用 |
| Roots / Sampling / Logging の非推奨化 | SEP-2577 | これらに依存している実装は移行検討が必要 |
特に最後の Roots / Sampling / Logging の非推奨化（SEP-2577）は、既存サーバーに直接効く。これらの機能を使っている場合、RC段階で代替を確認しておきたい（ただしRCなので最終版で扱いが変わる可能性は残る）。
開発者は今から何に備えるべきか
「RCが確定ではない」を踏まえたうえで、今やっておくと損しない準備を、確実性の高い順に挙げる。
- セッション前提のハードコードを剥がせるようにしておく（確実性: 高）。
MCP-Session-Id必須・initialize往復必須を前提にロジックを密結合させていると、ステートレス化で書き直しになる。セッション管理を1箇所に隔離しておく。 - 長時間処理はTasks化を見据える（確実性: 高）。長寿命接続で結果を待つ設計は、確定版でも既にSSEポーリングで否定されつつある。ただし確定版の
tasks/result形とRC/拡張版のtasks/get+tasks/update形は別物なので、どちらに賭けるかはSDK対応を見て決める。 - 使っているSDKのTier・Extension対応を確認（確実性: 中）。公式は「Tier 1 SDKはRC期間内に対応を出す」としている。自分のSDKがTasks/Apps/Extensionsのどれを、どの設計で実装しているかが移行コストを左右する。
- Roots / Sampling / Logging 依存を棚卸し（確実性: 中）。SEP-2577で非推奨提案が出ている。今すぐ捨てる必要はないが、依存箇所を把握しておく。
- RCに対して実ワークロードで検証する（確実性: 公式推奨）。公式は「実際の負荷でRCを検証し、ドラフト仕様とchangelogをレビューし、問題があれば仕様リポジトリにissueを立てる」よう求めている。RCの段階で声を上げれば最終版に反映されうる。
まとめ — 「確定」と「提案」を取り違えないこと
本記事の結論を一文で言えば「現行コア（2025-11-25）はまだステートフル。だが次期仕様のRC（2026-07-28）はステートレスコアを目玉に、Tasksの拡張化・MCP Apps/Extensionsの正式化へ大きく舵を切る」だ。
- 確定（GA, 2025-11-25）: コアはステートフル（
MCP-Session-Id）／Tasksは実験的に導入（taskフィールド＋tasks/result）／SSEは既にポーリング志向 - 提案（RC, 2026-07-28・最終予定）: ステートレスコア（
initialize/MCP-Session-Id廃止, SEP-2567/2575）／Tasksは拡張へ再設計（tasks/get+tasks/update, SEP-2663）／MCP Apps公式化（SEP-1865）／Extensionsフレームワーク（SEP-2133）／Roots・Sampling・Logging非推奨（SEP-2577）
技術記事として強調したいのは、RCのメソッド名や形をそのまま「確定」として実装に落とさないこと。RCは最終版2026-07-28までに変わりうる。一次情報（公式仕様・公式ブログ・GitHubのSEP）で最新状態を確認し、自分のSDKの対応を見てから判断するのが、結局いちばん速い。
