MCP仕様の改訂ライフサイクル — 仕様書と機能で分かれる状態遷移

仕様書のライフサイクルと機能のライフサイクルは別物

MCPには2つの独立した状態遷移があります。仕様書という「文書そのもの」がたどる段階と、その中に書かれた個々の「機能」がたどる段階です。この2つを混同すると、「非推奨になった機能があるのに、なぜ仕様のバージョンはまだ現行のままなのか」のような疑問が生まれます。答えは単純で、両者は別の軸だからです。この記事はMCPの公式ドキュメント「Versioning」ページが定義する範囲、つまり仕様書の改訂そのものの管理方法に焦点を当てます。

仕様書のライフサイクルは1つのリビジョン全体に対して1つの状態しか持ちません。一方、機能のライフサイクルはCurrentなリビジョンの中に、Activeな機能とDeprecatedな機能が同居する形で表れます。2026-07-28は仕様書としてはCurrentですが、その中のRootsとSamplingという機能はDeprecatedです。

仕様書自体の3つの状態(Draft・Current・Final)

リビジョンは常にこの3つのどれかです。

• Draft: 作業中の仕様。まだ利用を前提にしていません。modelcontextprotocol.io/specification/draftで先行公開されています
• Current: 今使うべきリビジョン。後方互換の範囲で今後も変更を受け付けます。2026-07-28がこれに当たります
• Final: 過去の完成した仕様。今後変更されません。2024-11-05から2025-11-25までの4リビジョンがこの状態です

Draftから次のCurrentへ切り替わる瞬間、それまでCurrentだったリビジョンはFinalへ移ります。1つのリビジョンが同時に2つの状態を持つことはありません。仕様書としてのDraftは、あくまで「まだ利用を前提にしていない」作業中の文書であり、Draftの内容が変更なしにそのままCurrentへ昇格する保証もありません。

機能単位の3状態(Active・Deprecated・Removed)と12ヶ月ルール

機能のほうは仕様書とは独立に、1つずつ状態を持ちます。

機能を非推奨にするにはSEP(Specification Enhancement Proposal)という提案プロセスを通す必要があり、そのSEPには移行先と「最短除去日」を明記しなければなりません。最短除去日は、その機能が最初にDeprecatedとなったリビジョンのリリースから数えて、最低12ヶ月後に設定するルールです。セキュリティ上の危険がある場合に限り、この期間は最短90日まで短縮できます(Expedited removal)。

12ヶ月という数字は最短ラインであって、実際の削除がそれより先に必ず起きるわけではありません。実務上の削除タイミングはCore Maintainersの裁量に委ねられており、Deprecatedのまま12ヶ月をはるかに超えて仕様に残り続ける機能もありえます。逆に言えば、「Deprecatedになった」という通知だけを見て慌てて移行作業を組む必要はなく、まず確認すべきは個別の機能に記載された最短除去日です。

非推奨提案が通る条件、そして元に戻る道もある

誰でも思いつきでSEPを出せば機能が非推奨になるわけではありません。ポリシーが挙げる正当な理由は次のいずれかです。

• 同じ用途をカバーする別の機能に置き換わった
• セキュリティやプライバシー、相互運用性のリスクがあり、仕様を変えずには軽減できない
• エコシステムの利用実態やSDKメンテナーの合意から見て、維持コストに見合う採用実績がない

SEPには、対象機能をschema.tsの定義と仕様文の両方で特定すること、上記いずれかの理由で正当化すること、移行先を明記するか「移行不要」と明言すること、そして最低12ヶ月の猶予期間を数値で指定することが求められます。移行先として別の機能を挙げる場合、その機能は非推奨が発効するリビジョンの時点でActiveでなければなりません。

一方向の廃止だけではなく、後戻りの手続きも用意されています。Deprecatedになった機能は、事情の変化を説明した上で元のSEPを上書きする新しいSEPが承認されれば、Activeへ復帰できます。復帰した機能が再び非推奨になった場合、12ヶ月のカウントは新しい非推奨が発効したリビジョンからやり直しです。過去の猶予期間の消化分は引き継がれません。

Currentが複数存在する瞬間 — バージョンネゴシエーションの実際

「Currentは常に1つ」という原則がありつつも、実装は複数のリビジョンに同時対応できます。クライアントとサーバーは、リクエストごとに使用するプロトコルバージョンを_metaフィールドで宣言し、サーバーは対応していないバージョンを次のようなエラーで突き返します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2026-07-28", "2025-11-25"],
      "requested": "1900-01-01"
    }
  }
}

supported配列を見れば、そのサーバーが今どのリビジョンまで対応しているかが一目で分かります。クライアントはここから互いに対応できるバージョンを選んで再送するだけでよく、事前にネゴシエーションのハンドシェイクを挟む必要はありません。仕様書のCurrentが1つに定まっていることと、個々の実装が複数のリビジョンをまたいで動くことは、矛盾せず両立する設計です。

実例で見る — Roots・Sampling・HTTP+SSEの状態遷移

2026-07-28時点でDeprecatedとして登録されている機能を、MCPの非推奨機能一覧から抜き出すと次のとおりです。

2026-07-28時点でRemoved状態の機能はまだ0件です。このレジストリは「今後何が消えるか」を1ページで確認できる唯一の一覧として設計されており、各リビジョンのChangelogに散らばった非推奨情報を毎回追いかけなくても済むようになっています。表のincludeContextの行が示すとおり、機能全体ではなくフィールドの特定の値だけがDeprecatedになるケースもあり、粒度は機能単位に限定されません。

Deprecatedでも動き続ける、SDKへの猶予

仕様からある機能がDeprecatedやRemovedになっても、それだけでSDKの実装まで即座に消えるわけではありません。仕様からの除去は、各言語SDKがその機能をリリースから落とすことを義務づけないというルールが明記されています。SDK側のサポート終了時期は、そのSDK自身のリビジョンサポートポリシーに従います。

一方でTier 1に分類されるSDKには義務があります。ある機能がDeprecatedになったリビジョンがCurrentとしてリリースされた次のリリースまでに、その言語のネイティブな仕組み(TypeScriptなら@deprecatedのJSDocタグ、PythonならDeprecationWarningなど)でDeprecatedである旨を表示しなければなりません。これを継続的に怠るTier 1 SDKは、Tierの格下げ対象になるという規定もあります。実装者から見れば、「仕様がDeprecatedにした機能は、動かなくなる日ではなく、警告が出るようになる日から数え始める」と捉えるのが実態に近い理解です。

誰が決めているのか — 提案から承認までの役割分担

非推奨化は誰か1人の判断では動きません。ポリシーは提案から承認までの役割を明確に分けています。非推奨・延長・復帰のいずれも、提案自体はコントリビューターなら誰でも出せますが、SEPにはMaintainerかCore Maintainerによるスポンサーが必要です。SEPの承認、実際に削除を実行する判断、延長や復帰の承認、そしてセキュリティ理由での期間短縮の承認は、いずれもCore Maintainersがガバナンスの意思決定プロセスに従って行います。Lead Maintainersはこれらすべての承認に対して拒否権を持つ、というのが最終的な歯止めです。

Deprecated Featuresレジストリ自体も、この手続きの副産物として存在します。ページの位置づけは「各リビジョンの非推奨通知やChangelogのエントリと整合させた派生ビュー」であって、それ自体が正典ではありません。正典はあくまで機能ごとの非推奨通知とChangelogのエントリ側にあり、レジストリはそれを1ページに集約した参照用の一覧です。実装者が知りたいのは大抵「今何が非推奨で、いつまでに移行すればいいか」なので、実務上はレジストリを見るだけで足りますが、根拠を遡るときは個別のSEPとChangelogに戻る必要があります。

まとめ

MCPのライフサイクルは、仕様書そのものの3状態(Draft・Current・Final)と、機能ごとの3状態(Active・Deprecated・Removed)という2つの独立した軸で動いています。機能を廃止するにはSEPと最低12ヶ月の猶予期間が必要で、削除は仕様から消えることであってSDKからの即時撤去ではありません。この2層構造を知っていれば、「Currentなのに一部が非推奨」という状態を矛盾と誤解せずに読めます。2026-07-28で何が変わったかの全体像はMCP仕様のバージョン履歴、非推奨になったRoots・Samplingが実際のクライアント接続でどう扱われるかはMCPクライアントの仕組みで確認できます。MCPの基礎からたどりたい場合はMCPとはを参照してください。次に非推奨の通知を見かけたときは、まず最短除去日と移行先の2点をレジストリで確認するところから始めるのが実務的です。