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状態の定義は次のとおりです。

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

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

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

4つ目の項目があるとおり、限定列挙ではなく最終的な裁量の余地を残す書き方になっています。非推奨化は仕様変更にあたるため、SEPガイドラインに沿ったSEPが必要です。SEPには対象機能の特定・根拠・移行先(または移行先が不要という明記)・最低12ヶ月の猶予期間、の4点を文書化しなければなりません。

3つ目の「採用率の低さ」は印象論では認められず、エコシステムのテレメトリやSDKメンテナーの合意という形で、維持コストに見合う採用実績が無いことを示す必要があります。猶予期間の起点にも決まりがあります。移行先の機能がある場合、その代替機能は非推奨化が発効するリビジョンの時点でActiveでなければならず、代替機能と非推奨化そのものが同じリビジョンで同時に導入されることも認められています。12ヶ月は「機能が最初にDeprecatedとマークされたリビジョンのリリース」から数え、SEPがFinalに達した日からではありません。

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

非推奨化SEPがFinalに達し、対応するリビジョンがリリースされると、機能そのものが動かなくなる前に、まず記録の側が動きます。同時に書き換わるのは次の3箇所です。

• schema.tsの該当箇所に、非推奨化SEPと発効リビジョンを参照する@deprecatedのJSDocタグが付く
• 仕様の地の文にも、同じ内容の非推奨の告知が加わる
• そのリビジョンのchangelog.mdxに「Deprecated」という見出しでエントリが追加される

「Deprecated」と「Removed」は、既存のMajor/Minor/Otherという分類と並ぶ、changelogの正式な見出し区分として扱われます。これらが揃って初めて、その機能はレジストリにも追加されます。ある機能が非推奨かどうかを疑ったときはレジストリを見るのが最短です。根拠を遡って確認したいときは、この3箇所(schema.ts・仕様の地の文・changelog)が一次情報になります。

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

SDK開発者に課される義務

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

• MUST: 次のリリースまでに、その言語のネイティブな仕組み(TypeScriptの@deprecated JSDoc、Javaの@Deprecated、.NETの[Obsolete]、GoのDeprecated:規約など)でAPI表面をマークする
• SHOULD: Deprecatedな機能が実際に使われたときにランタイム警告を出す(PythonのDeprecationWarning、Node.jsのprocess.emitWarningなど)

/**
 * @deprecated SEP-2577により非推奨。Sampling機能はLLMプロバイダーAPIとの直接統合に置き換える
 */

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

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

このポリシーが解決しているのは、非推奨化の情報が各リビジョンのchangelogに散らばっていて、実装者が「結局いつまでに何を直せばいいのか」を再構成しなければならなかった状態です。HTTP+SSEトランスポートは2025-03-26リビジョンの時点で事実上の非推奨として案内されていましたが、統一された猶予期間のルールも、SDK側の対応義務も存在しませんでした。SEP-2596はこの状態を、最低12ヶ月という数字と、Tier 1 SDKの具体的な対応義務という形で制度化しています。

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

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

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

提案自体はコミュニティの誰にでも開かれていますが、承認権限はCore Maintainerに集約されています。さらにLead Maintainerは、これらすべての承認に対して拒否権を持つと定められています。1つのSEPが通っても、Lead Maintainerの段階で覆る余地が制度上残っている、ということです。この二段構えのおかげで、単独のメンテナーや外部からの働きかけだけで非推奨化のスケジュールが動くことはありません。

猶予期間そのものに手を加える操作は3種類あり、どれも新しいSEPを要求します。

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

いずれも当初の非推奨化SEPやexpedited removal専用のSEPを通す必要があり、Core Maintainerの一存で日付だけを書き換えることはできません。

このポリシーを最初にチェックすべき人は誰か

MCPサーバーやクライアントのSDKを自分で保守している開発者は要注意です。Tier 1 SDKの義務(deprecatedマークとランタイム警告)が、自分たちのリリースサイクルに乗っているかを確認する必要があります。MCPサーバーを自作している場合は、依存しているSDKがこの義務を守れているかどうかも品質の判断材料になります。個別の機能が今どの状態にあるかを一覧で確認したいだけなら、公式の非推奨機能レジストリを直接見るほうが早いでしょう。こちらのポリシー文書は「なぜそのスケジュールになっているのか、誰がそれを決めているのか」を理解したいときに読むものだと考えてください。MCPの設計思想がコード実行ベースの統合のように大きく動くタイミングでは、機能単位の非推奨化も動きやすくなります。両方を定点観測しておくと、変化を追いやすくなります。