MCP 2026-07-28仕様の変更点｜ステートレス化・Tasks・認証・移行ガイド

結論：大きな変更だが、全利用者が今日一斉移行する話ではない

MCP 2026-07-28は、statelessなプロトコルコア、MRTR、header-based routing、cacheable list results、Extensions、Tasks、MCP Apps、認証強化、正式なdeprecation policyをまとめた大きな改訂です。仕様の正式公開は完了しましたが、SDK・クライアント・接続先が同じ速度で対応するとは限りません。既存のMCP Serverが動いているなら、まず対応表と検証環境を作り、本番の接続方式を先に変えない判断も正解です。

stateless化は、アプリケーションの状態を消すことではない

公式説明でいうstatelessは、MCPのプロトコル層が接続sessionを管理しないという意味です。買い物かごやブラウザの状態が必要なアプリケーションは、ツールの引数として明示的なhandleを返し、次の呼び出しで渡す設計にできます。隠れたsessionに依存していた実装は、状態をどこで持ち、誰が渡し、期限や権限をどう確認するかをコードと監査ログに出す必要があります。

server/discover、Extensions、Tasks、MCP Appsを混同しない

認証強化は、APIキーを置き換えるだけの話ではない

正式仕様の認証変更には、authorization responseのiss検証、OIDCのapplication_type、issuerに結びついたcredential、refresh token、scopeの扱い、well-known discoveryの整理が含まれます。DCRは後方互換のため動作しますが、CIMDへの移行方針と将来の削除予定も明示されました。これは認証サーバーとクライアントの実装を確認する話であり、仕様名を設定ファイルへ貼り付ければ安全になる話ではありません。個人開発では、まずサーバーごとの認証方式、scope、tokenの保管場所、再認証、ログに残す情報を表にします。

移行前チェックリスト

• 実装対象の仕様version、URL、確認日、SDK・clientの対応範囲を記録する
• MCP client、server、SDKの対応versionと互換性を確認する
• initialize / initialized / Mcp-Session-Idを前提にした実装箇所を洗い出す
• sessionを外した後も必要な状態を、明示的なhandle・期限・権限で設計する
• server/discover、Mcp-Method、Mcp-Name、cacheの扱いをgatewayと一緒に検証する
• Tasksを使う場合は旧APIとの違い、cancel、途中入力、権限を確認する
• MCP Appsを使う場合はiframe、UI action、consent、監査ログを分けずに確認する
• OAuth/OIDCのissuer、iss、scope、refresh token、再認証をテストする
• conformance test、SDKのtier、既存の接続先を確認してから段階的に切り替える

今すぐ変更しない方がよいケース

対応SDKが2026-07-28をサポートしていない、接続先が2025-11-25前提、認証のテスト環境がない、本番のrollback手順がない場合は、仕様が正式公開されたからといってtransportを即変更しない方が安全です。新仕様を理解することと、本番を移行することは別の作業として扱います。