MCP仕様がステートレスに刷新|セッション廃止で何が変わるか【2026年7月】
代表取締役 上坂大地郎
結論: Model Context Protocol(MCP)の2026-07-28仕様が本日リリースされました。プロトコルレベルのセッション管理が完全に撤廃され、ステートレスなアーキテクチャへ移行しています。MCPローンチ以来最大の改定であり、AIコーディングツールの裏側で動くツール連携の基盤が根本から変わります。ただし既存機能の廃止には12ヶ月の猶予期間が設けられており、SDK経由の利用者は段階的な移行が可能です。
この記事の要点:
- MCPがステートレス化。
Mcp-Session-Idヘッダーとinitializeハンドシェイクが廃止され、MCPサーバーが通常のラウンドロビンロードバランサーの背後で稼働できるようになった(MCP公式ブログ、2026年5月21日RC公開・7月28日正式版) - 新たに「MCP Apps」(サーバーがクライアント内にインタラクティブHTML UIを描画)と「Tasks拡張」(長時間非同期ワーク対応)が正式拡張として導入された
- Roots・Sampling・Loggingの3機能が非推奨化。OAuth 2.1/OpenID Connect準拠の認証強化も同時に実施
対象読者: Claude Code・Cursor・GitHub CopilotなどAIコーディングツールを使っている開発者、MCP対応サーバーを自作・運用しているエンジニア、AIツール連携の動向を追っている方
読了後にできること: MCP新仕様で何が変わり何が壊れるかの全体像が把握でき、自分の環境で移行が必要かどうかを判断できます
2026年7月28日、Model Context Protocol(MCP)の新しい仕様が正式にリリースされました。MCPの生みの親であるAnthropicのDavid Soria Parra氏は「ローンチ以来最大の改定」と位置づけています。
私自身、Claude Codeを全社導入していて、freee会計・Googleカレンダー・microCMSなど複数のMCPサーバーを繋いで日常業務を回しています。今回の仕様変更は、こうしたMCP接続の根っこの部分に関わる話です。
この記事では、今回の仕様改定で何が変わったかを技術的な詳細まで整理したうえで、エンジニアの現場で何を確認すべきかまで解説します。
何が起きたのか — 時系列で整理
時期 | できごと |
|---|---|
2024年11月 | Anthropicが MCP を公開。Claude Desktopに統合 |
2025年3月 | Streamable HTTP トランスポート導入(従来のSSEトランスポートを置き換え) |
2025年11月25日 | 前回の仕様版(2025-11-25)リリース。セッション管理・Sampling・Roots等を含む |
2026年5月21日 | 2026-07-28仕様のリリース候補(RC)を公開。「最大の改定」と発表 |
2026年5月〜7月 | SDK開発者・サーバー実装者向けに10週間のバリデーション期間 |
2026年7月28日 | 本日、正式版リリース |
ポイントは、RCから正式版まで約10週間の猶予が設けられていたことです。すでにBeta SDKが公開されており、主要なSDKは対応を進めています。
ステートレス化 — 今回の改定の核心
今回の変更の中で最もインパクトが大きいのが、プロトコルレベルのセッション管理の完全撤廃です。
何が変わったのか
前の仕様(2025-11-25)では、クライアントとサーバーの間に「セッション」の概念がありました。接続の最初にinitialize/initializedのハンドシェイクを行い、サーバーがMcp-Session-Idヘッダーを返し、以降のリクエストはそのセッションIDに紐づく、という流れです。
新しい仕様ではこの仕組みが丸ごとなくなりました。具体的には以下が廃止・変更されています。
廃止されたもの | 代替 |
|---|---|
| リクエストの |
| 不要。状態が必要なら |
スティッキーセッションルーティング |
|
サーバー能力の初回ネゴシエーション |
|
生活のたとえで言うと
旧MCPは「担当者制の窓口」でした。初回に名乗って担当者が決まり、以降はその人としか話せない。担当者が休んだら詰む。新MCPは「番号札のない銀行窓口」。どの窓口に行っても同じ処理ができる。引き継ぎメモ(_meta)を毎回自分で持っていくので、誰が対応しても話が通じます。
なぜステートレスにしたのか
StacklokのCEO Craig McLuckie氏はThe Registerの取材で「MCPのステートフルな性質は、そのオリジン(=ローカルで動くデスクトップアプリとの連携)の副産物だった」と指摘しています(The Register、2026年7月23日)。
MCPが広まるにつれて、クラウド環境で複数インスタンスのMCPサーバーを動かしたいユースケースが増えました。しかしセッション管理があるとスティッキールーティングが必須で、ロードバランサーの設定が複雑になり、スケーラビリティのボトルネックになっていたわけです。
MCP Apps — サーバーがUIを描画する
新しい仕様で導入された「MCP Apps」(SEP-1865)は、MCPサーバーがクライアント内にインタラクティブなHTML UIを描画できる仕組みです。
技術的には、サンドボックス化されたiframe内にサーバーがレンダリングしたHTMLを表示します。UI上のアクション(ボタンクリックなど)は、ツール呼び出しと同じJSON-RPCプロトコル経由でサーバーに送られます。つまり、監査やユーザー同意の仕組みを壊さずにリッチなUIが実現できるという設計です。
たとえばデータベース管理ツールのMCPサーバーが、テーブル構造をグラフィカルに表示して、カラムの変更をUI上で操作させる、といった使い方が考えられます。
Tasks拡張 — 長時間処理への対応
前の仕様では実験的機能として含まれていた「Tasks」が、正式な拡張(extension)に昇格しました(SEP-2663)。
主な変更点は以下の通りです。
2025-11-25(実験版) | 2026-07-28(正式拡張) |
|---|---|
|
|
コア仕様の一部 | 独立した拡張として分離 |
|
|
長時間かかるコード生成やデータ処理を非同期で実行し、進捗を確認しながら結果を受け取る、というワークフローが標準的にサポートされるようになります。
Extensions Framework — 拡張の正式な仕組み
MCP Appsとtasksを含む、拡張の枠組み自体が今回初めて正式化されました(SEP-2133)。
- 拡張は逆DNS識別子(例:
io.modelcontextprotocol.tasks)で管理 - メイン仕様から独立したバージョニング
- クライアントとサーバーが
capabilities内のextensionsマップで対応する拡張をネゴシエーション - SEPプロセスに「Extensions Track」を新設(実験的 → 公式への昇格パス)
将来的に新機能はまず拡張として導入され、安定したらコア仕様に取り込む(あるいは拡張のまま維持する)という方針が明確になりました。
認証・認可の強化 — OAuth 2.1準拠へ
6本のSEPにまたがる認証強化が行われています。主な変更点を整理します。
変更内容 | SEP番号 | 実務上の意味 |
|---|---|---|
OAuth 2.1 Resource Server必須化 | — | サーバーは |
Resource Indicators(RFC 8707)対応 | — | トークンの対象サーバーを明示。「トークンAをサーバーBに流用する」攻撃を防止 |
発行者(issuer)検証の必須化 | SEP-2468 | 複数MCPサーバーを使うクライアントでのmix-up攻撃を防ぐ |
Client ID Metadata Documents(CIMD) | — | Dynamic Client Registrationに代わる推奨登録方式 |
| SEP-837 | デスクトップ/CLIクライアントが誤って「web」型として扱われることを防ぐ |
リフレッシュトークン処理の明文化 | SEP-2207 | ステップアップ認可時のトークンライフサイクルを標準化 |
エンタープライズ環境でMCPサーバーを本番運用する際のセキュリティ基盤が固まった形です。
非推奨化された3機能
以下の3つの機能が非推奨(deprecated)になりました。ただし、初の正式な非推奨ポリシー(SEP-2596)も同時に導入され、最低12ヶ月の猶予期間が保証されています。すぐに壊れるわけではありません。
非推奨化された機能 | 理由 | 代替手段 |
|---|---|---|
Roots(クライアントがファイルシステムの場所をサーバーに伝える) | 「ニッチすぎる」とSoria Parra氏。ツール引数やリソースURIで十分 | ツールパラメータ、リソースURI |
Sampling(サーバーがクライアントのモデルに補完を依頼) | セマンティクスが混乱を招いていた | LLMプロバイダーAPIの直接利用 |
Logging | 標準的なオブザーバビリティツールに委ねるべき |
|
どこまで確認されているのか — 検証状況
確認済みの事実:
- MCP公式ブログでRC公開(2026年5月21日)と正式リリース(2026年7月28日)が発表されている
- Beta SDKが公開されており、10週間のバリデーション期間が設けられた
- 非推奨機能の猶予期間は最低12ヶ月と明文化されている
- Soria Parra氏のThe Registerインタビュー(2026年7月23日)で技術的な意図が説明されている
当事者の主張段階:
- 「ローンチ以来最大の改定」はMCP側の自己評価。外部の独立した比較分析は執筆時点で見当たりません
- SDKの対応状況について「Tier 1 SDKは10週間以内に対応」とされていますが、全SDKの完了報告は確認できていません
楽観論と慎重論 — 受け止め方は分かれている
楽観的な見方: StacklokのCEO Craig McLuckie氏は「ステートレス設計への移行は、プラットフォームチームの期待に合致する」と評価し、企業が統一的なコントロールポイントで「エージェント対応ポリシー」を適用できるようになると述べています。Microsoftもmcp-for-beginnersリポジトリに解説を追加し、Azure App Serviceでの活用ガイドを公開するなど、積極的に対応を進めています。
慎重な見方: 一方でSoria Parra氏自身が「カスタム実装を作った人にとっては、正しく移行するためのリフトワークがかなりある」と認めています。特にSDKを使わず独自にMCPプロトコルを実装しているケースでは、セッション管理の撤廃に伴う大幅な書き換えが必要です。また、Roots・Sampling・Loggingを利用している既存サーバーは、12ヶ月以内に代替手段への移行を完了する必要があります。
デュスクとしての見立て: Claude CodeやCursorなどの主要AIツール経由でMCPを使っている多くのエンジニアにとっては、SDK側が対応すればツールのアップデートで自然に移行が完了するはずです。注意が必要なのは、自社やチームでカスタムMCPサーバーを運用しているケースです。ステートレス化の恩恵(スケーラビリティ・運用の簡素化)は明確ですが、移行コストは実装の深さによってかなり差が出そうです。
エンジニア・SES現場への示唆
ここからが本題です。今回の仕様変更が現場のエンジニアにとって何を意味するか、3つの観点で整理します。
1. AIツール利用者としての影響(大多数のケース)
Claude Code・Cursor・GitHub Copilotなどを通じてMCPサーバーに接続している場合、ツール側のアップデートで自動的に対応される見込みです。ただしツールのバージョンが古いと新仕様のMCPサーバーと通信できなくなる可能性があるため、定期的なアップデートはしておくのが無難です。
2. MCPサーバーの自作・運用者としての影響
社内ツールやSaaS連携のためにMCPサーバーを自作している場合は、移行作業が発生します。特にinitializeハンドシェイクへの依存、Mcp-Session-Idを使ったルーティング、Roots・Sampling・Loggingの利用がある場合は、コード修正が必要です。
3. 常駐先での影響
SES現場では、顧客企業がMCPサーバーをインフラとして運用しているケースが増えています。今回の仕様変更について質問を受ける場面が出てくるかもしれません。「ステートレス化でスケーラビリティが改善される」「既存機能の廃止には12ヶ月の猶予がある」「SDK利用者は比較的スムーズに移行できる」という3点を把握しておけば、会話についていけるはずです。
今すぐ確認・検討すべきこと
- 今日確認すること: 自分が使っているAIツール(Claude Code・Cursor等)のバージョンを確認する。MCPサーバーを自作している場合は、Roots・Sampling・Loggingの利用有無をコード内で検索する
- 今週中にやること: MCPサーバーを運用している場合は、公式のchangelog(2025-11-25からの差分)を読み、影響範囲を特定する。Beta SDKへのアップデートを検証環境で試す
- 今月中に検討すること: カスタムMCPサーバーの移行計画を立てる。特にOAuth 2.1の
/.well-known/oauth-protected-resourceエンドポイント実装と、ステートレス対応(セッション依存の除去)の2つが大きなタスクになる
よくある質問
Q1: Claude CodeやCursorを使っているだけなら、何かする必要がありますか? 基本的にはツールのアップデートだけで対応できる見込みです。ただし古いバージョンのまま放置すると、新仕様のMCPサーバーと互換性がなくなる可能性があります。
Q2: 今動いているMCPサーバーがすぐに壊れますか? いいえ。非推奨化された機能(Roots・Sampling・Logging)も最低12ヶ月は動作が保証されています。ただし新仕様対応のクライアントと旧仕様のサーバー(またはその逆)の組み合わせでは互換性の問題が出る可能性があります。
Q3: MCP Appsとは何ですか? MCPサーバーがクライアント(Claude CodeやIDEなど)の中にHTMLベースのインタラクティブUIを描画できる仕組みです。ツール呼び出しと同じプロトコルで通信するため、セキュリティの監査パスが維持されます。
Q4: なぜSamplingが非推奨になったのですか? SamplingはMCPサーバーがクライアント側のLLMに「追加の推論」を依頼する機能でしたが、セマンティクスが混乱を招いていたとされています。代替として、LLMプロバイダーのAPIを直接利用する方式が推奨されています。
Q5: ステートレス化で何か失われるものはありますか? プロトコルレベルでの状態管理は失われますが、アプリケーションレベルの状態管理は引き続き可能です。basket_idやbrowser_idのような明示的なハンドルをツール引数として渡す方式に変わります。状態が「見えない場所」から「見える場所」に移っただけ、というのが仕様設計者の意図です。
まとめ
MCP 2026-07-28仕様は、セッション管理の完全撤廃というプロトコルの根幹に関わる変更です。背景には、MCPがローカルツールからクラウド規模のインフラへと使われ方が広がったという現実があります。
MCP Apps・Tasks拡張・Extensions Frameworkの導入は、MCPが「ツール呼び出しの薄い橋渡し」から「AIエージェントのためのプラットフォーム基盤」に進化しようとしていることを示しています。
一方で、カスタム実装の移行コストは無視できません。12ヶ月の猶予期間があるとはいえ、影響範囲の確認は早めに始めておいたほうがいいでしょう。SDK経由の利用者は比較的スムーズに移行できるはずですが、自分の環境を一度点検しておいて損はないでしょう。
参考・出典
- The 2026-07-28 MCP Specification Release Candidate(https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/) — MCP公式ブログ(参照日: 2026-07-28)。仕様変更の全項目・SEP番号・タイムラインの一次情報
- Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here(https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/) — MCP公式ブログ(参照日: 2026-07-28)。SDK対応状況の一次情報
- Model Context Protocol prepares to break with its stateful past(https://www.theregister.com/devops/2026/07/23/model_context_protocol_prepares_to_break_with_its_stateful_past/5276722) — The Register(参照日: 2026-07-28)。David Soria Parra氏の発言、Craig McLuckie氏のコメントの出典
- The biggest MCP spec update ships July 28: What changes for AI agent authentication(https://workos.com/blog/mcp-2026-spec-agent-authentication) — WorkOS(参照日: 2026-07-28)。認証・認可変更の技術的詳細
- MCP 2026-07-28 spec: what changed, what breaks(https://stacktr.ee/blog/mcp-2026-spec-changes) — Stacktree(参照日: 2026-07-28)。移行チェックリスト・破壊的変更の整理
- AI Tool Protocol Drops Sessions Tomorrow: MCP's Largest Spec Change Since Launch(https://www.techtimes.com/articles/321671/20260727/ai-tool-protocol-drops-sessions-tomorrow-mcps-largest-spec-change-since-launch.htm) — TechTimes(参照日: 2026-07-28)
- MCP Just Went Stateless — What the 2026 Spec Changes About Scaling on App Service(https://techcommunity.microsoft.com/blog/appsonazureblog/mcp-just-went-stateless-/4530222) — Microsoft Tech Community(参照日: 2026-07-28)

