MCPが2026-07-28でステートレスな仕様に変わった：OAuth/OIDC強化とApps/Tasksが拡張機能に切り出された話

普段MCPサーバーは npx @playwright/mcp@latest のようにコマンド一発で立ち上げて、あとは黙って動いてくれるものだと思っていました。ところが2026年7月28日付でMCP（Model Context Protocol）の仕様そのものが大きく更新されていて、コアの通信方式がステートレスに変わり、認可（Authorization）周りがOAuth/OIDCの実運用に寄せて厳格化され、Apps・Tasksという拡張機能がバージョン管理される仕組みに切り出されていました。普段は「使う側」として記事を書いてきましたが、今回はプロトコル自体がどう進化しているかを公式仕様で追ってみます。

参照したのは公式の 2026-07-28 changelog と公式ブログ、それに拡張の仕組みを説明した Extensions Overview です。一次情報にあたって初めて知った変更点が多く、正直かなり読み込みに時間がかかりました。

そもそも何が変わったのか、一言でいうと
ハンドシェイクも消えた：毎リクエストが自己完結する
OAuth/OIDCがより厳格に、実運用寄りになった
AppsとTasksが「コア」から「バージョン付き拡張」に切り出された
1年目エンジニアが今日から気にすべきこと
正直に書いておきたいこと

そもそも何が変わったのか、一言でいうと

これまでのMCPは、クライアントとサーバーが最初に initialize/notifications/initialized でハンドシェイクをして、その接続の間だけ有効な「セッション」を張るプロトコルでした。Streamable HTTPトランスポートには Mcp-Session-Id ヘッダーがあり、同じセッション内なら tools/list の結果もそのセッション専用に変わったりします。

2026-07-28の仕様は、このセッションという概念そのものを丸ごと削除しました。公式changelogにははっきりこう書かれています。

Remove protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport. List endpoints (tools/list, resources/list, prompts/list) no longer vary per-connection. Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments.

つまりリクエストはそれぞれ独立していて、状態を維持したいならサーバー側が「ハンドル」を発行してツールの引数として渡す、という素朴な方式に寄せています。公式ブログの言い方を借りると、これで「ロードバランサーの背後にある任意のサーバーインスタンスが、共有ストレージ無しでリクエストを処理できる」ようになるとのことです。サーバーレスや複数インスタンスの水平スケーリングを見据えた設計変更ですね。

ハンドシェイクも消えた：毎リクエストが自己完結する

セッションだけでなく、接続の最初にやっていた initialize ハンドシェイクも無くなりました。代わりに、すべてのリクエストが自分の _meta にプロトコルバージョンとクライアントの機能情報を積んで送られてきます。

"_meta": {
  "io.modelcontextprotocol/protocolVersion": "2026-07-28",
  "io.modelcontextprotocol/clientCapabilities": { ... },
  "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" }
}

バージョンが合わなければ UnsupportedProtocolVersionError が返ってくる仕組みです。さらに新しく server/discover というRPCが追加され、サーバーは対応バージョンや機能を事前に問い合わせられるようになりました。「最初に握手してからやり取りする」から「毎回名乗りながらやり取りする」への発想転換だと理解しています。地味な変更に見えますが、影響範囲は結構広いです。

ちなみに ping や logging/setLevel も削除されていて、ログレベルはリクエストごとに _meta で指定する方式に変わっています。全部を「毎リクエスト完結」に統一する一貫した設計だと感じました。

OAuth/OIDCがより厳格に、実運用寄りになった

認可周りの変更は地味ですが実務では効いてきそうです。公式changelogから3点ほど拾います。

issパラメータの検証必須化: 認可サーバーはRFC 9207に沿って認可レスポンスにissを含めるべきで、クライアントは認可コードを引き換える前に記録済みのissuerと突き合わせて検証しなければならなくなりました。認可サーバーのなりすまし（mix-up）を防ぐための変更です。
application_typeの明示: Dynamic Client Registrationの際にapplication_typeを指定する必要があります。デスクトップアプリやCLIが使うlocalhostリダイレクトと、Webアプリのリダイレクトが衝突しないようにするためです。
クレデンシャルの発行元バインド: クライアントの認証情報は発行した認可サーバーに紐づけて保存しなければならず、別の認可サーバーで使い回すことは禁止されました。認可サーバーが変わったら再登録が必要です。

加えて、Dynamic Client Registration（RFC7591）自体もClient ID Metadata Documentsという新方式に取って代わられる形で非推奨になりました（後方互換のため当面は残るとのことです）。全体として、企業のEntraやOktaのようなIDプロバイダとMCPをつなぐ場面を強く意識した仕様強化に見えます。個人でnpxコマンドを叩くだけの用途では体感しにくい変更ですが、業務でMCPサーバーを社内配布する側になったら避けて通れなさそうです。

AppsとTasksが「コア」から「バージョン付き拡張」に切り出された

今回の変更でいちばん構造として面白かったのがこれです。TasksはこれまでMCPの実験的な機能としてコアプロトコルの中に置かれていましたが、2026-07-28でio.modelcontextprotocol/tasksという独立した拡張に切り出されました。ブロッキングだったtasks/resultを廃止し、ポーリング用のtasks/getと、クライアントからの追加入力を受け付けるtasks/updateに置き換えたそうです。長時間かかる処理をタスクハンドルとして扱う設計は変わりませんが、ポーリング前提に作り直された格好です。

MCP Appsも同様に、対話中にチャートやフォーム、動画プレイヤーのようなインタラクティブなUIをインラインで表示するための拡張として、公式のmodelcontextprotocol/ext-appsリポジトリに切り出されています。

「拡張」という言葉が指す仕組みも公式ドキュメントで定義されていて、拡張はそれぞれ{vendor-prefix}/{extension-name}という識別子を持ち（公式拡張はio.modelcontextprotocolプレフィックス）、クライアントとサーバーは自分の対応状況をclientCapabilitiesやserver/discoverのレスポンスで宣言し合います。破壊的変更が必要なときは同じ識別子のまま変えるのではなく-v2のような新しい識別子を切る、というバージョニングのルールも明記されていました。コア仕様を頻繁に変えずに、UIやタスクのような「あると便利だけど全員には要らない機能」を独立して進化させるための器を作った、という理解です。

1年目エンジニアが今日から気にすべきこと

正直に言うと、普段npxでMCPサーバーを立ち上げているだけなら、明日から何かが壊れるという話ではありません。server/discoverによるバージョンネゴシエーションのおかげで、古いサーバーと新しいクライアントが混在してもある程度は吸収される設計になっています。ただし、この記事のMCPサーバー一覧の記事で見たように、MCPのエコシステムは仕様変更のスピードが速く、参照実装がアーカイブされたり生まれ変わったりを繰り返しています。今使っているサーバーがいつの間にか新仕様前提に切り替わっていた、ということは今後も起きるはずです。

特に長時間かかる処理を伴うMCPサーバー（テスト実行やスクレイピングのように時間のかかるツール）を自作・カスタマイズする人にとっては、Tasksがコアから拡張に切り出されたことで「対応するかどうかを選べる」ようになった点は覚えておいて損はありません。Playwright MCPが本体同梱になった話で書いたように、周辺ツールのMCP対応も日々アップデートされ続けています。仕様が変わったからといって既存のサーバーがすぐ動かなくなるわけではないですが、「MCPサーバーって結局何のプロトコルの上で動いているのか」を一度公式仕様で確認しておくと、今後のアップデート記事を読むときの解像度が上がると思います。

正直に書いておきたいこと

今回は執筆時点（2026年9月）で、実際に2026-07-28仕様に対応したMCPサーバー・クライアントを自分のマシンでビルドして動作確認するところまではできていません。あくまで公式のchangelogとブログ、Extensions Overviewを読み込んで一次情報として裏取りした内容です。またAnthropicの公式ブログでは「Claude製品への対応は順次ロールアウトする」とだけ書かれていて、Claude Codeでいつから新仕様のMCPサーバーがフルに使えるようになるのか、具体的な時期は明言されていませんでした。バージョン移行の実運用がどうなるかは、もう少し様子を見てから追いかけ直したいと思います。

MCPをこれから触り始める人は、まずMCP入門の記事で「AIにブラウザを触らせる」体験から入るのがおすすめです。プロトコルの中身がどう進化しているかは、使い込んでから気になったタイミングで追いかければ十分だと思います。