3行まとめ

2026年7月28日にリリースされたMCP（Model Context Protocol）新仕様の最大の変更は、initializeハンドシェイクとMcp-Session-Idの廃止。プロトコルがステートフルからステートレスなリクエスト/レスポンス方式に変わり、リモートMCPサーバーがスティッキーセッションなしで普通のロードバランサの後ろに置けるようになった
サーバー起動の割り込みリクエスト（roots/listやsampling/createMessageなど）は**MRTR（Multi Round-Trip Requests）**という新パターンに統一。接続を張りっぱなしにせず、input_requiredを返してクライアントが同じリクエストをリトライする方式になった
OAuth 2.0/OIDC周りも実運用に近づける方向で強化。issパラメータの検証必須化（RFC 9207）、クライアント認証情報のissuer単位管理、Dynamic Client Registrationに代わるClient ID Metadata Documentsの導入などが入った。RootsとSampling、Loggingはコア機能から非推奨になった

2026年7月28日、MCP（Model Context Protocol）の新しい仕様がリリースされた。5月のリリース候補版から10週間の検証期間を経ての正式版で、公式が「プロトコル発足以来最大の改訂」と呼ぶ内容になっている。

Claude Code・Claude Desktop・各種エージェントフレームワークがMCPサーバーを前提に組まれている以上、この改訂はMCPサーバーを書いている・書く予定がある開発者に直接影響する。変更点は多岐にわたるが、実装上インパクトが大きいものから順に整理する。

何が変わったか — ヘッドラインは「セッションの廃止」

これまでのMCPは、接続確立時にinitialize/notifications/initializedのハンドシェイクを行い、以降のやり取りはMcp-Session-Idヘッダーで紐づいたセッション状態を前提にしていた。ノートPC上で1プロセス動かす分には問題なかったが、リモートMCPサーバーを複数インスタンスでスケールさせようとした瞬間に破綻する設計だった。すべてのリクエストが同じインスタンスに届く必要があるからだ。

新仕様ではこの前提を丸ごと外した。

Streamable HTTPトランスポートからプロトコルレベルのセッションとMcp-Session-Idヘッダーを削除。tools/list・resources/list・prompts/listなどのリスト系エンドポイントも、接続ごとに内容が変わらなくなった
initialize/notifications/initializedハンドシェイクを廃止。プロトコルバージョンやクライアント機能は、接続時に一度だけ交換するのではなく**_metaフィールドに載せて毎リクエスト送る**方式に変わった

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "mcp stateless" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "my-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

サーバーはserver/discoverというRPCの実装が必須になり、対応プロトコルバージョン・機能・アイデンティティを事前に問い合わせられるようになった
接続をまたぐ状態が必要な場合は、トランスポート任せのセッションではなくサーバーが発行するハンドルを通常のツール引数として渡す方式（SEP-2567）に変更

実務上のメリットは明確で、これまでスティッキーセッション・共有セッションストア・ゲートウェイでのディープパケットインスペクションが必要だったリモートMCPサーバーが、素のラウンドロビン・ロードバランサの後ろで動くようになる。Cloudflare Agents SDKやAmazon Bedrock AgentCoreは公開初日から新仕様に対応しており、インフラ側の後押しも早い。

MRTR — サーバー起動リクエストの置き換え

これまでroots/list・sampling/createMessage・elicitation/createのような「サーバーからクライアントへの割り込みリクエスト」は、接続を張りっぱなしにする前提で設計されていた。ステートレス化に伴い、これらは**MRTR（Multi Round-Trip Requests）**という新パターンに統一された。

サーバーは追加情報が必要な場合、resultType: "input_required"を持つInputRequiredResultを返す
クライアントはinputRequestsに応じた回答をinputResponsesに詰めて、同じリクエストをリトライする

1回目: サーバーが追加入力を要求する。

{
  "jsonrpc": "2.0",
  "id": 5,
  "result": {
    "resultType": "input_required",
    "inputRequests": [{ "type": "elicitation", "message": "確認: このディレクトリを削除しますか？" }]
  }
}

2回目: 同じリクエストIDでリトライし、回答を添える。

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "tools/call",
  "params": {
    "name": "delete_dir",
    "arguments": { "path": "/tmp/work" },
    "_meta": {
      "inputResponses": [{ "type": "elicitation", "value": "yes" }]
    }
  }
}

すべての結果にresultTypeフィールドが必須になり（通常は"complete"、追加入力待ちなら"input_required"）、旧バージョンのサーバーが返すresultTypeなしの結果は"complete"として扱う後方互換ルールも定義されている。接続を持ちっぱなしにする代わりに「リクエストをやり直す」という発想への転換は、ステートレス化の一貫した思想がよく表れている部分。

OAuth 2.0まわりの強化

認可周りは複数のSEPにまたがる強化が入り、実際のOAuth 2.0/OIDC運用に近づける方向で仕様が厳格化された。OAuth 2.0 Protected Resource Metadata（RFC 9728）自体は以前の仕様から実装必須の要件だが、今回はそれに加えて以下が新たに入っている。

認可レスポンスに**issパラメータを含めることを推奨**（RFC 9207）し、クライアントは認可コードを引き換える前に記録済みのissuerと一致するか検証しなければならない（RFC 9207対応、SEP-2468）
クライアント認証情報は発行した認可サーバーのissuer identifierをキーに管理し、別の認可サーバーで使い回すことを禁止。認可サーバーが変わったら再登録が必須に（SEP-2352）
Dynamic Client Registration Protocol（RFC 7591）は非推奨となり、後継のClient ID Metadata Documentsへの移行が推奨される（既存の認可サーバーとの後方互換のためRFC 7591自体は当面残る）
OpenID Connectのリダイレクト URI衝突を避けるため、Dynamic Client Registration時に適切なapplication_typeの指定が必須に

複数の認可サーバーを相手にするMCPクライアント・ゲートウェイを実装している場合、issuer単位でのトークン管理を徹底しないと今回の仕様変更で弾かれる可能性がある。

Tasksが拡張機能に切り出された

2025-11-25仕様で実験的コア機能として入っていたTasksは、本番運用で得られた知見をもとに再設計され、コアからの切り出しという形になった。長時間実行されるエージェント処理をブロッキングせずに追跡する仕組みとして重要な機能だが、位置づけが変わった。

ブロッキングだったtasks/resultを廃止し、tasks/getによるポーリング方式に変更
クライアントからサーバーへの入力を送るtasks/updateを新設
セッションなしでは安全にスコープできないという理由で**tasks/listを削除**
サーバーはオプトインなしでタスクハンドルを返せるようになった

AWSがコントリビュートした拡張として、Amazon Bedrock AgentCoreがいち早く対応している。2025-11-25の実験版Tasks APIに乗っていた実装は、この新しいライフサイクルへの移行が必要になる。

廃止された機能（Roots / Sampling / Logging）

コア機能からの非推奨化（Deprecated）が3つ発表された。仕様のライフサイクルポリシーにより最低12ヶ月の非推奨期間が設けられ、この間は動作し続けるが新規実装での採用は非推奨。

機能	移行先
Roots	ツール引数・リソースURI・サーバー設定でディレクトリ/ファイルを渡す
Sampling	LLMプロバイダのAPIに直接統合する
Logging	stdio利用時は`stderr`へ、それ以外はOpenTelemetryを使う

あわせて、2025-03-26から非推奨扱いだったHTTP+SSEトランスポートも正式に「Deprecated」ステータスへ格上げされ、Streamable HTTPへの移行が明確に求められるようになった。

個人開発者・MCPサーバー実装者が気をつけること

セッションに依存した状態管理をしている実装は書き直しが必要。接続維持ではなく、ハンドルをツール引数として受け渡す設計に変える
roots/listやsampling/createMessageをポーリングや接続維持で実装している場合はMRTRへの移行が必要。resultTypeフィールドのハンドリングも新規追加
複数の認可サーバーを相手にするクライアント/ゲートウェイはissuerごとのトークン管理を見直す。使い回しは仕様違反になる
2025-11-25の実験的Tasks APIに乗っていた場合は、拡張版のライフサイクル（tasks/get/tasks/update）への移行が必要

まとめ

MCP 2026-07-28仕様の本丸はセッション廃止によるステートレス化。initializeハンドシェイクとMcp-Session-Idが消え、状態はサーバー発行のハンドルで管理する方式に変わった
サーバー起動の割り込みはMRTRに統一。接続を張りっぱなしにせず、input_requiredとリトライで表現する
OAuth 2.0/OIDCまわりが大幅に厳格化され、issuer単位のトークン管理やClient ID Metadata Documentsへの移行が求められるように。TasksはコアからExtensionへ、Roots/Sampling/Loggingは非推奨に

10週間の検証期間を経ての正式版とはいえ、セッション前提で組んだMCPサーバー実装は軒並み手を入れる必要がある規模の改訂。移行は12ヶ月の猶予があるとはいえ、新規に書くMCPサーバーは最初からステートレス前提で設計しておくのが無難。

ぱんだツールズ では PDF・画像・CSV・テキスト処理などの開発者向けツールを 90 個以上公開中。全部無料・登録不要・ブラウザ完結で使える。Claude Code で開発した個人開発プロダクトの実例として、よかったら覗いていって。
https://sakutto-panda.com

この記事は Zenn にも同じ内容を投稿しています。