MCP 2026-07-28 仕様RC — 史上最大の改訂。ステートレス化・MCP Apps・Tasks で自作サーバは何が変わるか

Model Context Protocol（MCP）の新仕様が、2026年7月28日に確定するリリース候補として公開された。ローンチ以来最大の改訂で、プロトコルからセッションを取り除く「ステートレス・コア」、サーバがUIを返す「MCP Apps」、長時間ジョブを扱う「Tasks」が同時に入る。筆者は複数のAIエージェントを1つに束ねるデスクトップツールに自作MCPサーバを組み込んで運用しており、この改訂で自分のコードのどこを書き換えるかを実装者の視点で追った。

2026-07-28 版で確定する3本の柱
ステートレス・コア：消えるもの、増えるもの
MCP Apps：サーバがUIを返す
Tasks：長時間ジョブがハンドル方式へ
認可：OAuth 2.1 リソースサーバとして扱う
SDKベータで最小サーバを動かす
1. 実際に入れて、最小サーバを動かした
2. initialize は消えていなかった
自作サーバの移行チェックリスト
FAQ
参考

2026-07-28 版で確定する3本の柱

公式ブログ「The 2026-07-28 MCP Specification Release Candidate」が告知した通り、今回はプロトコルの土台そのものを組み直す改訂だ。派手な新機能の追加というより、本番環境で無理なく動かすための地ならしに近い。柱は次の3つに整理できる。

ステートレス・コア：initialize ハンドシェイクとプロトコルレベルのセッションを廃止し、普通のHTTPインフラでスケールする。
拡張フレームワーク：サーバがサンドボックス化したUIを返す「MCP Apps」、長時間ジョブをハンドルで扱う「Tasks」を拡張として定義。
認可の刷新：6本のSEPでMCPサーバを OAuth 2.1 のリソースサーバとして正式に位置づける。

スケジュールも押さえておきたい。リリース候補は2026年5月21日にロックされ、最終仕様が7月28日に公開される。SDKメンテナが実ワークロードで検証するための約10週間の窓が設けられており、この期間は挙動を確認するための窓で、本番投入には使わないのが安全だ。

非推奨から削除までの猶予も明文化された。機能ライフサイクル（SEP-2577）は各機能を Active / Deprecated / Removed の3段階で管理し、非推奨化から最短の削除まで最低12か月を空ける。慌てて全面移行しなくてよい設計になっている。

ステートレス・コア：消えるもの、増えるもの

従来の MCP サーバは、接続時の initialize／initialized で能力を交換し、Mcp-Session-Id ヘッダでその後のリクエストを同じインスタンスへ紐付けていた。この前提が消える。

変更点	従来	RCでどう変わる	自作サーバへの影響
initialize ハンドシェイク	接続時に initialize/initialized で能力交換	廃止（SEP-2575）。能力とクライアント情報は各リクエストの `_meta` に載る	ハンドシェイク前提の初期化コードを分解し、リクエスト単位で読む形へ
Mcp-Session-Id ヘッダ	セッションIDで状態を紐付け	廃止（SEP-2567）。版は `MCP-Protocol-Version` ヘッダで伝える	共有セッションストアとスティッキー設定が不要になる
サーバ→クライアント要求	SSE ストリームで折り返し	`InputRequiredResult`（`inputRequests`／`requestState`）による多段往復（SEP-2260/2322）	常時接続の SSE を張る実装を見直す
ルーティング／キャッシュ	ボディを解析して振り分け	必須ヘッダ `Mcp-Method`／`Mcp-Name`、結果に `ttlMs`／`cacheScope`（SEP-2243/2549）	ゲートウェイがヘッダだけで振り分け・キャッシュできる

セッションが消える意味は、リクエストがどのインスタンスに着地してもよくなることだ。スティッキーセッションや深いパケット検査なしで、ただのラウンドロビンなロードバランサの背後に置ける。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_documents
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search_documents","arguments":{"q":"invoice"},
           "_meta":{"client":{"name":"my-agent","version":"0.4.0"}}}}

個人開発でサーバレスや小さなコンテナに MCP サーバを載せている人には、運用の難所が一つ減る。筆者のデスクトップツールでも、複数エージェントが同じサーバを叩くときのセッション管理が悩みの種だった。ここが素直なHTTPになるのは実装コードを減らす方向に効く。

MCP Apps：サーバがUIを返す

MCP Apps（SEP-1865）は、サーバがインタラクティブな HTML を返し、ホストがサンドボックス化した iframe の中で描画する仕組みだ。ツールは自分のUIテンプレートを事前に宣言するため、ホストは実行前にプリフェッチ・キャッシュ・セキュリティ審査を済ませられる。

描画されたUIがホストと話すときも、MCP のどこでも使う JSON-RPC の基底プロトコルを経由する。UI発の操作が、直接のツール呼び出しと同じ監査・同意の経路を通る点は実装者として安心材料になる。ツールの結果に生HTMLを詰めて独自レンダリングする回避策を組んでいたなら、この標準へ寄せていく判断ができる。

Tasks：長時間ジョブがハンドル方式へ

実験的なコア機能だった Tasks が、ステートレス前提の拡張として整理し直された（SEP-2663）。長時間かかる処理は、tools/call がタスクハンドルを返し、クライアントが tasks/get／tasks/update／tasks/cancel でそのハンドルを操作して進める。セッションに縛られた tasks/list は削除された。

// 1. tools/call がタスクハンドルを返す
{"jsonrpc":"2.0","id":1,"result":{"task":{"handle":"tsk_9f2a","status":"working"}}}

// 2. クライアントはハンドルで進捗を取りに行く
{"jsonrpc":"2.0","id":2,"method":"tasks/get","params":{"handle":"tsk_9f2a"}}

タスクとして走らせるかどうかは、クライアントが能力を広告し、サーバ側が判断する。例えば数十秒かかる動画変換や大きなファイルのインデックス作成を、応答を待たせずハンドルで返す設計にできる。状態を持たないので、進捗確認のリクエストがどのインスタンスに来ても処理できる。

認可：OAuth 2.1 リソースサーバとして扱う

認可は6本のSEPでOAuth 2.0／OpenID Connect の実運用に寄せられた。iss パラメータの検証（SEP-2468、RFC 9207）、動的クライアント登録での application_type 宣言（SEP-837）、資格情報を発行者に束縛する変更（SEP-2352）、リフレッシュトークンの扱いの明文化（SEP-2207）、スコープ蓄積と .well-known ディスカバリ（SEP-2350/2351）が含まれる。

自作の認証フローを持っているなら、この棚卸しは早めに着手したい。手製トークン検証を書いていた部分は、標準のリソースサーバ像に合わせて見直す対象になる。

SDKベータで最小サーバを動かす

Tier 1 の4SDK（Python・TypeScript・Go・C#）に RC 対応ベータが同時公開された。頭で差分を追うより、最小構成を動かして体で確かめるのが近道だ。

# Python（mcp v2.0.0b1）
uv add "mcp[cli]==2.0.0b1"
# もしくは
pip install "mcp[cli]==2.0.0b1"

# TypeScript（v2 で server/client のパッケージが分割）
npm install @modelcontextprotocol/server@beta
npm install @modelcontextprotocol/client@beta

# Go（v1.7.0-pre.1）
go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1

# C#（v2.0.0-preview.1）
dotnet add package ModelContextProtocol --prerelease

公式の移行ガイダンスは、ベータのバージョンを正確にピン留めし、ハッピーパスだけでなく実ワークロードで試すことを勧めている。HTTP配備ではステートレスモードを明示的に検証する（TypeScript は createMcpHandler、Go は StreamableHTTPOptions.Stateless = true）。後方互換も保たれており、新しいクライアントは古いサーバに対して従来の initialize ハンドシェイクへフォールバックする。バージョン表記や対応状況はRC段階で変わりうるため、正確な指定は公式のSDKベータ告知で確認してほしい。

実際に入れて、最小サーバを動かした

2026年7月31日に隔離した venv へ入れた。指定は 2.0.0b1 にしていない。PyPI を見たら 2.0.0 が安定版として出ていたので、そちらを入れた。

uv venv --python 3.12 .venv
uv pip install "mcp==2.0.0"

最初に確かめたのは改名だ。

from mcp.server import MCPServer        # -> あり
from mcp.server.fastmcp import FastMCP  # -> ModuleNotFoundError

mcp.server.fastmcp はモジュールごと消えていた。互換の別名も残っていない。1系のサーバをそのまま更新すると、import の時点で落ちる。

最小サーバは、上に書いた形のまま動いた。

from mcp.server import MCPServer

app = MCPServer("minimal-check")

@app.tool()
def get_forecast(city: str) -> str:
    """都市名を受け取って天気を返す。"""
    return f"{city} は晴れ"

if __name__ == "__main__":
    app.run()

initialize は消えていなかった

この最小サーバへ stdio で initialize を投げた。protocolVersion は 2026-07-28 を要求している。

{"protocolVersion":"2025-11-25",
 "serverInfo":{"name":"minimal-check","version":""},
 "capabilities":{"experimental":{},"prompts":{"listChanged":false},
   "resources":{"listChanged":false,"subscribe":false},
   "tools":{"listChanged":false}}}

ハンドシェイクは成立し、2025-11-25 へネゴシエートされた。続けて server/discover を投げた。

{"error":{"code":-32601,"message":"Method not found","data":"server/discover"}}

実装されていない。SDK のソースを server/discover で全文検索しても、MCP のメソッドとしての定義は出てこなかった（ヒットするのは OAuth のメタデータ discovery だけ）。

ここは上に書いた説明と食い違う。Python SDK 2.0.0 の stdio サーバでは initialize が生きていて、capabilities は従来どおりその応答に入って返る。

SDK 内で 2026-07-28 がどう扱われているかを見に行った。

shared/peer.py          : sampling capability is deprecated as of 2026-07-28 (SEP-2577)
shared/peer.py          : roots capability is deprecated as of 2026-07-28 (SEP-2577)
shared/subscriptions.py : subscriptions/listen (2026-07-28, SEP-2575)
shared/dispatcher.py    : Supports protocol version 2025-11-25 and earlier

実装に落ちている 2026-07-28 の変更は、sampling と roots の非推奨化と subscriptions/listen の新設だった。ステートレス化は HTTP 配備の話で、stdio で動かすサーバの見え方は変わっていない。

ローカルで stdio のサーバだけを持っているなら、この更新で今すぐ壊れるのは FastMCP の改名1点になる。未検証: HTTP のステートレスモードは動かしていない。subscriptions/listen の挙動も確かめていない。

細かい差分も1つ出た。serverInfo.version が空文字で返る。1.28.1 では SDK の版がそのまま入っていた箇所で、ここを見て分岐しているクライアントは値が変わる。

自作サーバの移行チェックリスト

筆者が自分のMCPサーバを見直すときに使っている順番を、そのまま並べておく。

セッション依存を洗い出す：initialize や Mcp-Session-Id を前提にした状態保持コードを列挙し、リクエスト単位で完結する形へ分解する。
SSE 折り返しを点検：サーバからの問い返しを SSE で実装しているなら、InputRequiredResult ベースの多段往復に置き換えられるか確認する。
認可を棚卸し：手製トークン検証を OAuth 2.1 リソースサーバの像に合わせ、iss 検証やディスカバリを埋める。
長時間処理を Tasks へ：ブロッキングで返していたジョブをハンドル方式に寄せ、tasks/list 依存を外す。
非推奨機能の代替を確認：Roots・Sampling・Logging は非推奨化された。ツールパラメータ・LLMプロバイダAPI直結・stderr／OpenTelemetry への移し替えを検討する。
SDK安定を待って本移行：主要SDKは10週間の窓で対応が入る。個人開発の本番反映は安定版を待ってからでも遅くない。