.png)
November 4, 2026
|
5 min read
MCP 2026-07-28リリース：ローンチ以来最大のプロトコル改訂におけるアプリ、タスク、ゲートウェイガバナンスの再考
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
7月下旬、私たちは以下の分析記事を公開しました。 ゲートウェイにおけるMCPアプリとタスクのガバナンス — そして、このプロトコルはすぐに続編の期限を突きつけました。2026年7月28日、Model Context Protocolの最終仕様である2026-07-28版が予定通りリリースされました。メンテナーによるリリース候補の記述（私たちが一度だけ引用した8つの単語）では、これを「ローンチ以来最大のプロトコル改訂」と呼んでいます（公式のRC発表）。その規模は、この呼称に値するものです。中核となる変更点は ステートレス化です。プロトコルセッションとMcp-Session-Idヘッダーは廃止され、初期化ハンドシェイクは削除されました。リクエストはMcp-MethodおよびMcp-Nameヘッダーに基づいてルーティングされ、リストおよびリソース読み取りの結果にはキャッシュヒントが含まれるようになります。呼び出し間で状態を保持する必要があるアプリケーションは、明示的なハンドル（basket_idやticket_idなど）を発行できるようになりました。これはツールから返され、通常の引数として渡されます。メンテナーは、モデルがハンドルを認識してツール間で受け渡せるため、トランスポート層に隠蔽された状態管理よりもこのパターンを推奨しています（リリースノート）。正式な 拡張フレームワーク が登場しました。これには逆DNS識別子と独立してバージョン管理されるリポジトリが含まれます。7月の記事で分析した2つの機能も、その最初の公式コンポーネントとして採用されています。MCPアプリ（ホスト側でサンドボックス化されたサーバーレンダリングのインタラクティブUI。アプリが開始するツール呼び出しは通常のtools/callパスを経由します）と、実験的なコアから移行したタスクです。 io.modelcontextprotocol/tasks これには、再設計されたポーリングベースのライフサイクル（tasks/get、tasks/update、協調的なtasks/cancel）が導入されました。これは、2025-11-25の実験的APIに基づいて実装していた開発者にとっては、明確な破壊的変更となります（WorkOSによる移行分析; BOVOによる破壊的変更の注記）。認可機能は、6つのSEP（MCP拡張提案）を通じて、デプロイ済みのOAuth/OIDCの実践に沿う形で強化されました。動的クライアント登録（DCR）はCIMDを優先して非推奨となり、プロトコルには正式な非推奨ライフサイクルが導入されました。Roots、Sampling、Logging、DCRは、2027年7月28日以降にリリースされる改訂版で削除対象となる可能性があります。一方、2025年から非推奨となっているレガシーのHTTP+SSEトランスポートは、ライフサイクルポリシーの別途公開された移行スケジュールに従います（非推奨機能レジストリ）。初日から広く採用されており、4つの主要なTier 1 SDKすべてがリリース時点で新仕様に対応しています。AWS、Google Cloud、Microsoft、Cloudflareがローンチを支持し、ClaudeおよびClaude DesktopはすでにMCPアプリをレンダリング可能なホストとなっています（リリースに関する投稿; アプリのドキュメント）。7月の投稿で述べた「アプリとタスクはそれぞれ、ゲートウェイが閉じるべきガバナンスの領域を広げる」という主張は、今回の改訂後もそのまま有効です。しかし、最終仕様には当時なかったニュアンスが追加されており、そのうち3点は、企業が今四半期に自社のMCP環境をどのように評価すべきかに影響を与えます。本稿は、以前の投稿の前提となった仕様と今回リリースされた仕様の間で何が変わったのか、その変更前後の比較図、そして各変更によって新たに生じるガバナンス上の課題について解説する、約束していたフォローアップ記事です。
1. 変更前と変更後：実際に何が変わったのか
7月の投稿は、2025年11月25日時点の状況に基づいて執筆されました。当時は、ステートフルなプロトコル（スティッキーセッション、初期化ハンドシェイク、ゲートウェイが追跡する必要のあるセッションIDヘッダー）、実験的なコア機能としてのタスク、非公式な拡張プロセス下で個別に進化するMCPアプリ、レガシーなHTTP GETストリーム経由の通知、そして動的クライアント登録（DCR）を中心とした認証という構成でした。2026年7月28日の最終仕様は、これらすべての柱を刷新しました。その結果、本番環境のトポロジーに即座に影響が及びます。スティッキーセッションと共有セッションストアを必要としていたリモートMCPサーバーは、今やキャッシュ可能なツールリストを備えた単純なラウンドロビン・ロードバランサーの背後で実行できるようになりました。プロトコルは一般的なHTTPインフラストラクチャ向けに再設計されており、これこそがトランスポート層における「エンタープライズグレード」の真の意味です（RC版の発表）。以下の図と表で変更点を一目で確認できます。特に注意が必要な3つの項目を強調しました。タスクの拡張機能への移行は 破壊的 であり、投稿で解説した2025年11月25日版の実験的APIは引き継がれないため、それに基づいて構築された内部サーバーは今すぐ監査が必要です。非推奨化は段階的かつ期限付きで行われます。新しい「アクティブ→非推奨→削除」のライフサイクルに基づき、Roots、Sampling、Logging、DCRは少なくとも12ヶ月間は動作し続け、2027年7月28日以降にリリースされるリビジョンまで削除対象にはなりません。一方、2025年から非推奨となっているレガシーなHTTP+SSEトランスポートは、ライフサイクルポリシーの移行ルールに従い、別途公開されている削除スケジュールに基づいて管理する必要があります（非推奨機能の標準レジストリ）。また、認証の強化は一部 クライアント 側で行われます。セキュリティ分析で優先されている「ミックスアップ攻撃」への防御（SEP-2468）はクライアント側の作業であり、企業内で誰がこれを実装するかが重要になります。この点については第3セクションで改めて触れます。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
Built for Speed: ~10ms Latency, Even Under Load
Try now.
Start free
How Can You Prevent GenAI Costs From Spiraling at Scale?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Discover More
No items found.
.png)
.webp)
.webp)
No items found.
Recent Blogs
.png)
.png)
.png)
.png)
.webp)
.webp)
.png)
.png)
.png)
