MCP仕様のバージョン履歴 — 2024年11月から5回の改訂を一覧する

MCPの現行仕様は2026-07-28、5回の改訂を経てここまで来た

MCP(Model Context Protocol)の仕様はYYYY-MM-DD形式のバージョン識別子を使い、後方互換性のない変更を加えた最後の日付を表します。互換性を保つ変更なら、バージョン番号は上がりません。これまでに5つのリビジョンが存在し、現行(Current)は2026-07-28です。

過去のリビジョンは2024-11-05、2025-03-26、2025-06-18、2025-11-25の4つで、いずれも変更のない「Final」として固定されています。つまり過去のリビジョンを参照する実装が、ある日突然仕様の中身が変わって壊れる心配はありません。変わるのは常に新しいリビジョンの側です。古いリビジョンを対象に書かれたクライアントやサーバーの実装コードも、その意味では未来永劫壊れない参照先を持っていることになります。

バージョン番号の読み方 — セマンティックバージョニングではない

2.1.5のような番号を使うライブラリに慣れていると誤解しやすい点ですが、MCPのバージョン番号はリリース連番ではなく日付そのものです。番号の大小比較に意味はあっても、「メジャー・マイナー・パッチ」のような粒度の区別はありません。後方互換の変更は同じバージョン番号のまま追加され、互換性を壊す変更があった日だけ新しい日付が刻まれます。

このため「2025-06-18から2025-11-25までの間に何か変わったのか」を知るには、そのリビジョンのChangelogを見るしかありません。バージョン番号の差分自体は、変更の量や重さを教えてくれない設計です。各Changelogの末尾にはGitHub上の該当リビジョン間の差分リンクも用意されており、Changelogの要約だけでは足りない実装者は、そこから実際のスキーマ差分まで遡れます。

改訂タイムライン — 5つのリビジョンで何が変わったか

2024-11-05 — 土台になった最初のリビジョン

ツール・リソース・プロンプトという、今もMCPの中核をなす3つの概念と、当時唯一のリモートトランスポートだったHTTP+SSEを定義したのがこのリビジョンです。コンテンツ形式はテキストと画像の2種類に限られ、ツールの挙動を説明する仕組み(読み取り専用か、破壊的操作かなど)もまだありませんでした。この時点の仕様書が、以降すべての改訂の比較対象になっています。

2025-03-26 — 認可とトランスポートの入れ替え

OAuth 2.1をベースにした認可フレームワークが加わり、MCPサーバーを保護されたリソースとして扱う土台ができました。同時にHTTP+SSEはStreamable HTTPに置き換えられ、JSON-RPCのバッチ処理サポートとツールアノテーション(読み取り専用・破壊的操作などの性質表示)も追加されています。コンテンツ形式には音声が加わり、テキスト・画像・音声の3種類になりました。

2025-06-18 — 追加したバッチ処理をその場で撤回

このリビジョンの目玉はElicitationの追加と、構造化ツール出力・リソースリンクのサポートです。MCPサーバーはOAuthのリソースサーバーとして明確に位置づけられ、認可周りの安全性要件も強化されました。同時に、前のリビジョンで加えたばかりのJSON-RPCバッチ処理を削除しています。1つ前の改訂で追加した機能を、次の改訂でもう取り消した数少ない例です。

2025-11-25 — メタデータと実験的機能の拡充

OpenID Connect Discoveryへの対応、ツールやリソースへのアイコン付与、WWW-Authenticateを使った段階的なスコープ同意など、細部の使い勝手を底上げする変更が並びます。ElicitationにはURLモードが加わり、Samplingはツール呼び出しに対応しました。実験的機能としてTasksが初めて登場したのもこのリビジョンです。

2026-07-28 — 接続モデルの土台を丸ごと入れ替え

initializeハンドシェイクを廃止してステートレス化し、サーバーの対応バージョンを尋ねるserver/discoverを新設しました。Streamable HTTPからはプロトコルレベルのセッションとMcp-Session-Idヘッダーが消え、resources/subscribeはsubscriptions/listenという単一の長時間ストリームに統合されています。Roots・Sampling・Loggingの3機能とDynamic Client Registrationが非推奨に回り、実験的機能だったTasksは拡張機能(io.modelcontextprotocol/tasks)として、コアプロトコルの外に切り出されました。

追加から1回の改訂で消えた機能もある

改訂の系譜を並べると、一直線に機能が増えているわけではないことが見えてきます。象徴的なのがJSON-RPCバッチ処理です。2025-03-26で追加されたこの機能は、次の2025-06-18で早くも削除されました。仕様に載った期間はわずか1リビジョン分です。

トランスポート層の入れ替わりも同じパターンをたどっています。初版の2024-11-05はHTTP+SSEトランスポートを定義していましたが、2025-03-26でStreamable HTTPに置き換えられました。HTTP+SSE自体は2026-07-28で正式に「非推奨」の状態に分類されるまで仕様書に残り続けましたが、実質的な現役の座は2025-03-26の時点で失っています。

最も大きな転換は接続モデルそのものです。2024-11-05から2025-11-25までの4リビジョンは一貫して、initialize/notifications/initializedというハンドシェイクで接続ごとの状態を確立するモデルを採用していました。2026-07-28はこのモデルを丸ごと廃止し、すべてのリクエストが_metaフィールドにプロトコルバージョンとクライアント情報を載せて送られるステートレスな設計に切り替えています。これは4回の改訂を経て積み上げてきた前提を、5回目の改訂で覆した変更です。

1本のテーマを追うと見える連続性 — 認可まわりの4回連続の手直し

改訂を機能単位で縦に追うと、初版にはなかった認可(認証・認可)の仕組みが、4回のリビジョンにわたって連続的に手直しされてきたことが分かります。

2025-03-26でOAuth 2.1ベースの認可フレームワークが初めて入り、MCPサーバーは保護されたリソースとして扱われるようになりました。2025-06-18ではさらに一歩進んで、MCPサーバーをOAuthのリソースサーバーとして正式に分類し、悪意あるサーバーがアクセストークンを不正取得できないようResource Indicators(RFC 8707)の実装を必須にしています。2025-11-25では認可サーバー側の発見をOpenID Connect Discoveryに対応させ、スコープ同意をWWW-Authenticateヘッダーで段階的に求められるようにし、クライアント登録の推奨手段としてOAuth Client ID Metadata Documentsが加わりました。そして2026-07-28では、2025-11-25で「推奨」に格上げされたばかりのClient ID Metadata Documentsが正式な移行先となり、それまでの主要な登録手段だったOAuth 2.0 Dynamic Client Registrationが非推奨に回っています。

1つのリビジョンだけを見ていると単発の改善に見える変更も、こうして機能単位で串刺しにすると、認可まわりが「一度作って終わり」ではなく、改訂のたびに前のリビジョンの穴を埋め続けている領域だと分かります。

改訂の間隔は一定ではなく、じわじわ伸びている

5つのリビジョンの日付を並べて間隔を数えると、もう1つの傾向が見えます。2024-11-05から2025-03-26までは約4.6ヶ月、2025-03-26から2025-06-18までは約2.8ヶ月、2025-06-18から2025-11-25までは約5.3ヶ月、そして2025-11-25から2026-07-28までは約8ヶ月です。最初の3回は3〜5ヶ月台に収まっていたのに対し、直近の間隔はほぼ倍に伸びています。

2026-07-28で扱われた変更が、接続モデルの前提を丸ごと入れ替えるレベルのものだったことを踏まえると、この間隔の伸びは変更の重さと無関係ではなさそうです。実装を追いかける側にとっては、「次の改訂もすぐ来る」と決め打ちせず、リリースされたリビジョンのChangelogを都度確認する姿勢のほうが実態に合っています。特定のリビジョンに実装を固定して運用しているなら、次の改訂を待つ間隔が伸びている今のうちに、非推奨レジストリを確認して移行の下調べを済ませておく余裕が生まれます。

まとめ — 各リビジョンをどこから深掘りするか

MCPの仕様は5つのリビジョンを経て、ハンドシェイク型からステートレス型へと接続モデルの根本を変えました。追加された機能がそのまま生き残るとは限らず、JSON-RPCバッチ処理のように1リビジョンで役目を終えた機能もあります。

最新リビジョンでの接続の実務(ローカル/リモート)はMCPクライアントの仕組み、機能が非推奨から削除に至るまでの手続きはMCP仕様の改訂ライフサイクルで扱っています。MCP全体の基礎からたどりたい場合はMCPとはを先に読むと文脈がつかみやすくなります。どのリビジョンを対象に実装するかを決める前に、まずこの1本の時系列を頭に入れておくと、個別のドキュメントを読む速度が上がります。