AIモデルが外部のツールやサービスを呼び出すための共通規格MCP（Model Context Protocol）に、大きな設計変更が入ります。新仕様「2026-07-28」では、接続開始時に必要だったセッション管理の仕組みがまるごと廃止され、通信のたびに情報を完結させる「ステートレス」な設計に切り替わります。あわせてTasksやMCP Appsといった機能が拡張機能として整理され、認可まわりの仕様も強化されました。MCPサーバーを自作・運用している開発者は移行対応が必要になります。
背景と文脈
MCPは、AIモデルが外部のツールやデータソースを呼び出す際のやり取りを統一する規格として広まりました。クライアントとサーバーの間で「どんな機能を使えるか」をやり取りしてから本番の通信に入る仕組みが基本で、これまでは接続時に一度だけinitialize/initializedという手続き（ハンドシェイク）を交わし、発行されたMcp-Session-Idで特定のサーバーインスタンスに紐付く形が一般的でした。
この方式は、サーバー側が同じインスタンスにリクエストを送り続けてもらう前提の「スティッキーセッション」が必要になり、単純なラウンドロビン型の負荷分散を使いにくいという課題がありました。特定のサーバーが落ちればそのセッションに紐づくやり取りは失われてしまいますし、セッション情報を複数インスタンス間で共有する仕組みを別途用意する運用コストもかかります。企業がMCPサーバーを大規模に運用しようとするほど、この制約が重荷になっていたのです。
技術/ビジネス面
新仕様の目玉は、このinitialize/initializedハンドシェイクとMcp-Session-Idの廃止です。接続時に一度だけ交換していたプロトコルバージョンやクライアント情報、対応機能といった情報は、すべてのリクエストの_metaフィールドに載せて毎回送るようになります。どのリクエストも単独で完結するため、サーバー側は単純なラウンドロビン型の負荷分散にそのまま乗せられるようになり、セッション情報を共有する仕組みを別途用意する必要もなくなります。
機能面では、これまで実験的なコア機能だった「Tasks（非同期処理を扱う仕組み）」が独立した拡張機能に格上げされ、ライフサイクルも再設計されました。またサーバー側がサンドボックス化されたiframe内にHTML形式のインターフェースを描画できる「MCP Apps」も追加されています。拡張機能は「Specification Enhancement Proposals（SEP）」という正式な提案プロセスを経て、コア仕様とは別のバージョンで管理されるようになり、新機能がコア仕様全体を不安定にせずに進化できる体制が整いました。認可まわりもOAuth 2.0やOpenID Connectとの整合性を高める6件のSEPが盛り込まれ、発行元を示すissパラメータの検証義務化や、認証情報を発行元の認可サーバーに紐付ける仕組みなど、企業導入を意識した強化が図られています。
これからどうなるか
旧仕様「2025-11-25」を対象に作られた既存のMCPサーバー・クライアントは、セッション初期化ロジックの削除やTasks実装の移行、エラーコードの変更対応など、複数の修正が必要になります。仕様策定チームは2026年5月21日からおよそ10週間の検証期間を設けており、7月28日の正式公開に合わせて主要なSDK（Software Development Kit、開発者向けの部品一式）が対応版を用意する見通しです。Roots・Sampling・Loggingの3機能は正式に非推奨となりましたが、注釈上の扱いにとどまり、発行から少なくとも12カ月は動作し続けるとされています。自前でMCPサーバーを立てている開発者は、慌てて全面書き換えする必要はないものの、利用しているSDKの更新情報を確認し、計画的に移行時期を見極めておくとよいでしょう。特にセッションIDに依存した独自のキャッシュ処理や認証まわりを組み込んでいる場合は、ステートレス化にあわせて設計を見直す必要が出てきます。
まとめ
MCPの新仕様2026-07-28は、セッション管理を廃止してステートレスな設計に切り替え、Tasksなどの機能を拡張機能として整理しました。負荷分散のしやすさや企業向け認可の強化が進む一方、既存実装には移行対応が求められます。
参考リンク
アイキャッチ画像: Photo by Jantine Doornbos on Unsplash
