MCP最大の改訂「2026-07-28」仕様が来週確定 - ステートレス化・MCP Apps・Tasksで何が変わるか

AIモデルと外部ツールをつなぐ標準プロトコルMCP（Model Context Protocol）の新仕様「2026-07-28」が、その名の通り2026年7月28日に確定します¹²。2026年5月21日にリリース候補（RC）が発表された時点で「プロトコル開始以来最大の改訂」とされており¹、確定を1週間後に控えた今、TechCrunchが「AIで最も重要なプロトコルが少し使いやすくなる」と報じるなど注目が集まっています³。

MCPがそもそも何かについては用語解説「MCPとは？」で紹介していますが、一言でいえば、AIアシスタントがカレンダー・データベース・社内ツールといった外部リソースに安全にアクセスするための共通規格です。TechCrunchはこれを「チャットボットが外部に手を伸ばすための配管」と表現しています³。この記事では、今回の改訂で何が変わるのか、既存の実装にどう影響するのかを整理します。

最大の変更: プロトコルコアのステートレス化

今回の改訂の柱は、プロトコルコアのステートレス化です。従来のMCPでは接続開始時の初期化ハンドシェイクとセッションベースのルーティングが前提でしたが、新仕様ではこれが廃止されます。サーバーはスティッキーセッションや共有セッションストアを持つ必要がなくなり、単純なラウンドロビンのロードバランサーの背後に置けるようになります¹。公式ブログは「どのMCPリクエストが、どのサーバーインスタンスに着地してもよい」設計になると説明しています¹。

これが重要なのは、企業インフラでの運用のしやすさに直結するからです。MCP実装を手がけるArcadeの創業者Nate Barbettini氏はTechCrunchに対し、従来の仕組みの課題を「今では、それらのマシンのすべてが、どこか別のマシンが発行したセッションIDを知らなければならない。不可能ではないが、深刻な悩みの種だ」と説明しています³。ステートレス化により、MCPサーバーを通常のWebサービスと同じ感覚でスケールさせられるようになります。TechCrunchのRussell Brandom氏は今回の改訂を、エージェント型AIへの期待に比してMCPの企業導入が広がりきらなかった障壁を取り除くインフラ整備と位置づけています³。

MCP AppsとTasks: 「ツール呼び出し」を超える2つの拡張

新仕様では公式拡張（extension）の枠組みが整理され、2つの拡張が目玉になります。

MCP Apps は、サーバー側からインタラクティブなHTML UIを配信できる拡張です。UIはサンドボックス化されたiframe内で描画され、UI上の操作は直接のツール呼び出しと同じ監査・同意のメカニズムを通ります¹。これまでテキストのやり取りが中心だったMCPに、画面を伴う操作が公式に加わることになります。

Tasks は長時間実行の処理を扱う拡張で、これまで実験的機能だったものが公式拡張に昇格します。ステートレスモデルに合わせてライフサイクルが再設計され、クライアント側が専用メソッドで処理の進行を管理します¹。AIエージェントに数分〜数時間かかる仕事を任せる用途の土台となる仕組みです。

認可の強化と「壊さないための」Deprecationポリシー

セキュリティ面では、OAuth 2.0とOpenID Connect標準への整合を強める6つの提案が盛り込まれます。発行者（issuer）の検証やアプリケーションタイプの宣言などが含まれ、企業の既存の認証基盤とMCPを組み合わせやすくなる方向です¹。

もうひとつ注目すべきは、公式のDeprecation（廃止）ポリシーの導入です。機能はActive（有効）→Deprecated（非推奨）→Removed（削除）の段階を踏み、非推奨化から削除まで最低12カ月が確保されます¹。今回の改訂自体は破壊的変更ですが、公式ブログは、今後はdeprecation期間と拡張を標準の手段とすることで、2026-07-28対応の実装者が大きな書き直しなしに将来の改訂を採用できるようにする、との方針を示しています¹。

SDK v2の変更点: FastMCP改名・パッケージ分割

新仕様に対応したSDKのベータ版は、2026年6月29日にPython・TypeScript・Go・C#の4言語（Tier 1 SDK）で公開済みです²。開発チームに影響する主な変更は次の通りです。

SDK	バージョン	主な変更
Python	v2（`mcp[cli]==2.0.0b1`）	FastMCPを MCPServer に改名。デコレーターパターンのAPIは維持²
TypeScript	v2	`@modelcontextprotocol/server` / `@modelcontextprotocol/client` に分割。ツール検証にStandard Schemaを採用。ESMのみ・Node.js 20以上²
Go	v1.7.0-pre.1	既存APIを維持。`StreamableHTTPOptions.Stateless = true` でステートレス対応²
C#	v2.0.0-preview.1	安定版v1.x APIは引き続き動作。破壊的変更は非推奨機能（roots・sampling・logging）に限定²

なお、仕様が7月28日に確定しても、既存のMCPサーバーが止まるわけではありません。公式ブログは、既存サーバーは仕様公開後も動き続けると明言しています²。

移行は「いつやるか」を決める段階に

MCPは、Function Callingの仕組みを土台に、AIと外部ツールの接続を標準化してきました。MCPツールのエコシステムが広がった今、プロトコル本体が「試行錯誤の段階」から「企業インフラとして運用する段階」へ移る節目が今回の改訂だと言えます。

MCPサーバーを開発・運用しているチームは、(1)7月28日の確定仕様と自分たちの実装の差分確認、(2)SDK v2ベータでの動作検証、(3)ステートレス化を前提としたデプロイ構成の見直し、の3点を検討する時期です。既存実装がすぐ壊れるわけではないため慌てる必要はありませんが、Deprecationポリシーにより移行の時間軸（最低12カ月）が明示された以上、「いつ移行するか」を計画に載せておく価値があります。AIエージェントの社内導入を検討している非開発部門にとっても、接続基盤の標準が安定期に入ることは、導入判断の不確実性がひとつ減ることを意味します。