Model Context Protocol(MCP)を主導するプロジェクトチームが、新版「2026-07-28」を公開した。Anthropicも公式ブログで独立に「MCP史上もっとも重要な仕様更新の一つ」と追認しており、リモートMCPのローンチから1年余りで最大のアップデートだ。核心はプロトコルからセッション状態を丸ごと取り除いたこと——旧版のMCPサーバーは、特定のサーバーインスタンスへリクエストを固定するsticky routingや、複数インスタンス間で状態を共有するセッションストアが水平展開に必須だったが、新版ではその制約が消え、素のラウンドロビン負荷分散だけでどのリクエストもどのサーバーインスタンスに着地させても動くようになった。ツールサーバーを運用する開発者にとっては、MCPサーバーを常駐コンテナからサーバーレス・エッジ関数へそのまま置き換えられるようになったことを意味し、エージェントからの呼び出しが急増しても複雑なセッション管理を自前で組む手間なく素直に横展開できる。各社が競うエージェント・オーケストレーション層の商用化競争——大量のツール呼び出しをいかに安く確実に捌くか——にとって、その土台にあたる標準規格自体が負荷分散上の制約を取り払ったことは大きく、真の焦点はもはや「MCPに対応するかどうか」ではなく「そのサーバー実装をどこまで安く大量に運用できるか」に移りつつある。
何が起きたか
MCPプロジェクトは2026-07-28、新しいプロトコルバージョン「2026-07-28」をリリースした。MCP公式ブログは「リモートMCP初回ローンチ以来、もっとも重要なリリース」と位置づけ、Anthropic公式ブログも独立に「MCP史上もっとも重要な仕様更新の一つ」と述べており、両社の記述は一致する。今回の柱は大きく二つある。ひとつはプロトコルの完全なステートレス化、もうひとつはプロトコル拡張のための正式な手続きの新設だ。
仕組み・詳細
MCP公式・Anthropic公式ともに明記しているのは、サーバーがサーバーレス・エッジインフラ上にデプロイできるようになった点だ。従来のMCPは、クライアントとの間で確立したセッション状態をサーバー側に保持する設計だったため、あるクライアントの後続リクエストは同じサーバーインスタンスへ送り届けなければならず(sticky routing)、複数インスタンスで動かす場合は状態を共有するセッションストアが必要だった。新版はこの前提そのものを外し、共有ストレージなしに素のラウンドロビン負荷分散だけでどのリクエストもどのサーバーインスタンスに着地しても動く設計に切り替わった。旧版で水平展開に必要だったsticky routingと共有セッションストアは、もう不要になったと2本の公式ブログが揃って明記している。
もうひとつの柱は、プロトコル拡張の正式な手順の新設だ。新版では、Tasksが、MCP AppsやEnterprise Managed Authorization(EMA)といった既存の拡張と並ぶかたちで、正式な「拡張フレームワーク」に位置づけられた。あわせて、仕様の機能を「Active」「Deprecated」「Removed」の3状態で管理するライフサイクル・廃止ポリシーを採用し、seps/ディレクトリ配下のMarkdownファイルによるPRベースのSEP(仕様拡張提案)ワークフローも正式化された。場当たり的になりがちだった仕様変更のガバナンスに、明文化された手続きが加わったかたちだ。
変更点で見る
| 項目 | 旧版 | 新版(2026-07-28) |
|---|---|---|
| セッション状態 | サーバー側に保持(ステートフル) | 保持しない(ステートレス) |
| 水平スケール | sticky routing・共有セッションストアが必須 | 素のラウンドロビン負荷分散のみで可能 |
| デプロイ先 | 常駐サーバー前提 | サーバーレス・エッジインフラにも対応 |
| プロトコル拡張の手続き | 正式な枠組みなし | 拡張フレームワーク・機能ライフサイクル・SEPワークフローを正式化 |
背景
MCPは、AIエージェントが外部のツールやデータソースへ接続するための標準規格として、Claudeを含む複数のAIアシスタントやエージェント製品で採用されてきた。各社がエージェント型製品を相次いで投入し、エージェントが外部ツールを呼び出す回数そのものが増え続ける中、ツール呼び出しの受け口となるMCPサーバーが旧来のステートフルな常駐サーバー前提のままでは、開発者はスケールのたびにセッション管理のインフラを個別に設計し直す負担を負い続けることになる。今回のステートレス化は、その負担をプロトコルの設計変更によって取り除くものだ。
なぜ重要か
MCPの初版は、エージェントがツールを呼び出すための共通言語を作るという最初の一歩としては十分だったが、ステートフルな設計はサーバー側の運用コストという形で開発者に跳ね返っていた。今回の改定でその制約が外れたことは、エージェント連携をめぐる競争の重心が、プロトコルに対応するかどうかという入口の議論から、そのサーバー実装をどれだけ安く・大量に・確実に運用できるかという運用能力の勝負へ移りつつあることを示す。加えて、プロトコル拡張のための正式な手続き(拡張フレームワーク・機能ライフサイクル・SEPワークフロー)が同時に整備されたことは、MCPが一枚岩の仕様から、Tasks・MCP Apps・EMAのような個別拡張が複数並走できる基盤仕様へと役割を変えつつあることを意味する。標準規格自体が「土台を固定し、その上の拡張は複数の主体が並行して作る」運営モデルへ移行し始めた以上、次の競争軸は、どの拡張がデファクトスタンダードになるかという点に移っていく。