MCPの機能ライフサイクルポリシー — 3状態と非推奨の12ヶ月ルール

MCP仕様の個々の機能は、Active・Deprecated・Removedの3状態のどれか1つに属します。この状態管理を定めたのがSEP-2596で採択された機能ライフサイクルポリシーです。非推奨化には最低12ヶ月の猶予期間を義務づけ、SDK側が何をいつまでにやるべきかまで規定しています。RootsやSamplingがいきなり消えるのではなく、決まった手順とタイムラインを踏んで消えていく理由はこのポリシーにあります。

MCPの機能ライフサイクルポリシーとは何を定めた文書か

このポリシーが対象にするのは「機能」であって「仕様書そのもの」ではありません。プロトコルメッセージやcapability、トランスポート、スキーマ型、規範的な振る舞い要件といった個々の機能単位の状態管理がスコープです。仕様書自体がDraft・Current・Finalのどの段階にあるかは、別に定義されているバージョニングガイドの管轄で、両者は混同しないよう明確に切り分けられています。

MCPのプロトコル自体の仕組みとClaude Codeでの使い方は基礎として押さえたうえで、仕様が今後どう変化していくかを継続的に追いたい実装者もいるはずです。そうした読者にとって、このポリシーは「次に何が非推奨になりそうか」を予測する手がかりになります。

機能は3つの状態のどれかにある

3状態の定義は次のとおりです。

Removedになった機能も、最後に載っていたFinalリビジョンの仕様書には文書として残ります。過去のリビジョンを対象にした実装の根拠が消えることはありません。

Deprecatedな機能は、非推奨化SEPを覆す新しいSEPによってActiveへ復帰することもあり得ます。復帰後に再び非推奨化される場合、12ヶ月の猶予期間は新しい非推奨化が発効したリビジョンから改めて数え直されます。「一度Deprecatedになったら一直線に消える」という単純な図式ではありません。

機能の非推奨化を提案できる条件は、次のいずれかに該当する場合です。

• 代替機能が同じユースケースをカバーしている
• セキュリティ・プライバシー・相互運用性のリスクがその場では緩和できない
• エコシステムのテレメトリやSDKメンテナーの合意が、維持コストに対して採用率が極めて低いことを示している
• Core Maintainerが適切と判断するその他の理由

4つ目の項目があるとおり、限定列挙ではなく最終的な裁量の余地を残す書き方になっています。非推奨化は仕様変更にあたるため、SEPガイドラインに沿ったSEPプロセスが必要です。SEPには次の4点を書かなければなりません。

• 対象機能の名前と、schema.ts・仕様本文での定義へのリンク
• 上の条件に照らした根拠
• 移行先(または移行先が不要という明記)
• 最低12ヶ月の猶予期間(最小非推奨期間)

移行先の機能がある場合、その代替機能は非推奨化が発効するリビジョンの時点でActiveでなければなりません。代替機能と非推奨化そのものが同じリビジョンで同時に導入されることも認められています。12ヶ月は「機能が最初にDeprecatedとマークされたリビジョンのリリース」から数え、SEPがFinalに達した日からではありません。

非推奨化が発効すると仕様側の4箇所が書き換わる

非推奨化SEPがFinalに達した時点で、非推奨化は「予定」の扱いになります。機能がDeprecatedになるのは、次の変更を載せたリビジョンがリリースされ、新しいCurrentになったときです。機能そのものが動かなくなる前に、まず記録の側が動きます。

「Deprecated」と「Removed」は、既存のMajor/Minor/Otherという分類と並ぶ、changelogの標準の見出し区分として扱われます。ある機能が非推奨かどうかを疑ったときはレジストリを見るのが最短です。根拠を遡って確認したいときは、schema.ts・仕様の地の文・changelogが一次情報になります。

削除そのものにも手順があります。最低猶予期間が過ぎたあと、実際に削除を実行するかどうかはリリース準備の中でCore Maintainerの裁量に委ねられます。削除が決まった場合はchangelog.mdxとレジストリの両方に記録されます。当初の非推奨化SEPや削除SEPの内容そのものに手を加える変更(タイムラインの延長・短縮、Activeへの復帰)には、それぞれ別のSEPが必要です。Core Maintainerが個別の判断だけで日付を動かせる仕組みにはなっていません。

非推奨レジストリには今6つの機能が載っている

レジストリは、非推奨またはRemovedになった全機能を1ページに集めた表です。ポリシーはこれを「何がいつまでに消えようとしているか」の正本と位置づけ、リビジョンごとのchangelogに散らばる非推奨の記述を読み集めなくて済むようにしています。2026-07-28リビジョンのレジストリでは、Deprecatedの行が6つあります。

Removedの欄は、この表の時点では空です。削除が実行された機能は、changelogの該当エントリへのリンクとともにその欄へ移ります。

行ごとに「いつから非推奨か」と「いつ削除の対象になりうるか」がずれている点が、読み方の勘所です。

猶予の扱いも行ごとに違います。HTTP+SSEの最短削除はSEP-2596がFinalに達してから3か月後で、includeContextの2つの値はSamplingの削除に追随します。Dynamic Client Registrationは、Client ID Metadata Documentsに対応していない認可サーバーとの後方互換のために引き続き使えます。

SDK開発者に課される義務

このポリシーが独自なのは、SDKメンテナーへの義務まで踏み込んでいる点です。ある機能がDeprecatedになったリビジョンがCurrentとしてリリースされたあと、Tier 1 SDKには強さの違う2つの対応が求められます。

TypeScript SDKでRootsをマークするなら、JSDocはたとえば次の形になります。以下は書式を示すための例で、実際のSDKのコメントそのものではありません。

/**
 * @deprecated SEP-2577により非推奨(2026-07-28リビジョン)。
 * 最短削除は2027-07-28以降の最初のリビジョン。
 * 代わりにツールのパラメーターやリソースURIでパスを渡す。
 */

この義務を継続的に果たせないTier 1 SDKは、Tier降格プロセスの対象になります。仕様から機能を削除しても、SDKがその機能をリリースから外すことまでは強制されません。それはSDK自身のリビジョンサポート方針が決める話で、仕様の削除とSDKの削除は別のタイムラインで動きます。

なぜ「非推奨から即削除」ではなく12ヶ月ルールなのか

このポリシーが解決しているのは、非推奨化の情報が各リビジョンのchangelogに散らばっていて、実装者が「結局いつまでに何を直せばいいのか」を再構成しなければならなかった状態です。SEP-2596はこの状態を、最低12ヶ月という数字と、Tier 1 SDKの具体的な対応義務という形で制度化しています。

もう1つ重要なのが、削除の裁量です。最低12ヶ月の猶予期間が過ぎても、削除が自動的に実行されるわけではありません。実際の削除はリリース準備の中でCore Maintainerが判断する裁量事項で、機能は最低猶予期間よりずっと長くDeprecatedのまま残ることもあります。唯一の例外は、公開済みのセキュリティアドバイザリがある、または実際に悪用が観測されている、緩和策のないセキュリティリスクの場合です。この場合はCore Maintainerの承認を経て猶予期間を短縮できますが、それでもDeprecatedになってから最短90日は確保しなければなりません。

誰が非推奨化を決めているのか

非推奨化は特定のメンテナー個人の一存では決まりません。役割ごとに次のように分かれています。

提案自体はコミュニティの誰にでも開かれていますが、承認権限はCore Maintainerに集約されています。さらにLead Maintainerは、これらすべての承認に対して拒否権を持つと定められています。1つのSEPが通っても、Lead Maintainerの段階で覆る余地が制度上残っている、ということです。非推奨化の承認にはCore Maintainerの決定プロセスを通す必要があり、そのうえでLead Maintainerが拒否権を持つ、という構造です。

猶予期間そのものに手を加える操作は2種類あります。

• 猶予期間を延長・短縮する(短縮はセキュリティリスクに限るexpedited removalで、最短90日まで)
• Deprecatedな機能をActiveへ復帰させる

延長と復帰は新しいSEPで行います。セキュリティリスクで短縮する場合、承認は当初の非推奨化SEPに記録します。非推奨化SEPがすでにFinalになっていて、その後にリスクが出たときだけ、それを参照する短い専用のSEPを通します。

自分の実装は、どの行に当てはまるか

レジストリを自分の構成に当てはめると、次のように分かれます。

• HTTP+SSEでサーバーを公開している: 移行先はStreamable HTTPです。レジストリ上、最短削除の起点はSEP-2596のFinal到達から3か月後です。
• Roots・Sampling・Loggingを使っている: 2026-07-28リビジョンから非推奨で、最短削除は2027-07-28以降の最初のリビジョンです。SamplingでincludeContextの"thisServer"や"allServers"を指定しているなら、この2つの値はSamplingの削除より後まで残りません。省くか"none"にしておきます。
• Dynamic Client Registrationで認可している: Client ID Metadata Documentsが移行先です。非対応の認可サーバーとの後方互換のため、DCRは残されています。
• SDKを保守している: Deprecatedを載せたリビジョンがCurrentになったら、次のリリースでAPIをネイティブの仕組みでマークするところまでがMUSTです。

MCPサーバーやクライアントのSDKを自分で保守している開発者は、Tier 1 SDKの義務が自分たちのリリースサイクルに乗っているかを見ておくことになります。MCPサーバーを自作している場合は、依存しているSDKがこの義務を守れているかどうかも品質の判断材料になります。

レジストリを読むときは、非推奨になったリビジョンと最短削除の日付が行ごとに違う点に気をつけます。同じ非推奨でも、削除の対象になりうる時期は機能によって変わります。MCPサーバーの組み方ではコード実行ベースの統合のような設計も話題になっており、機能の非推奨化と合わせて比べる材料になります。