社内に数十のMCPサーバーとクライアントが散らばる環境で、仕様の一部が「非推奨」になった。どのチームがどの機能に依存しているのか、いつまでに直せばよいのか、答えられる状態にあるでしょうか。
MCP 2026-07-28は、機能単位のライフサイクルとデプリケーション方針を初めて明文化した。プロトコルの全体変更はステートレス化の移行ガイドで扱った。本稿は、非推奨機能への依存を棚卸しして移行を計画する運用設計に絞る。
MCPの機能ライフサイクルとは何か
MCPの機能は3状態で管理され、非推奨から撤去対象になるまで最短12か月の猶予が置かれます。
SEP-2596で採択された方針は、仕様上の機能を3状態で管理する。
| 状態 | 意味 | 実装者への期待 |
|---|---|---|
| Active | 現行リビジョンに含まれる | 規範的要件どおりに実装 |
| Deprecated | 仕様に残るが撤去予定。移行先が明記される | 新規採用は避け、撤去前に移行 |
| Removed | draft から削除済み。直近の Final リビジョンには文書が残る | 次の Current が依存しない |
猶予は、機能が初めて Deprecated になったリビジョンのリリース日から数える。撤去の実行は、猶予が過ぎた後にコアメンテナーが判断する。非推奨のまま長期間残る機能もある、と方針自体が明記している。
例外もある。公開済みのセキュリティ勧告があり、緩和策のない脆弱性を持つ機能は短縮撤去の対象になる。その場合でも非推奨化から撤去まで最低90日は確保される。
いま非推奨の機能と撤去目安は何か
公式レジストリの6件のうち4件は、2027年7月28日以降の最初のリビジョンが最短の撤去時期です。
非推奨機能は公式のDeprecated Features レジストリに一覧化されている。2026-07-28時点の内容は次のとおり。
| 機能 | 移行先 | 最短の撤去 |
|---|---|---|
| Roots | ツール引数・リソースURI・サーバー設定でパスを渡す | 2027-07-28以降の最初のリビジョン |
| Sampling | LLMプロバイダーAPIを直接利用 | 同上 |
| Logging | stdioは stderr、それ以外は OpenTelemetry | 同上 |
| Dynamic Client Registration | Client ID Metadata Documents | 同上 |
includeContext の thisServer / allServers | 省略するか none | Sampling の撤去に連動 |
| HTTP+SSE トランスポート | Streamable HTTP | SEP-2596 が Final になってから3か月後 |
「最短」は撤去の資格を得る時期であり、実際の撤去日ではない。ただし HTTP+SSE は猶予が短い。優先度は HTTP+SSE を先に、次に4件の本命と置くのが現実的だ。
非推奨への依存はどう棚卸しするか
依存の洗い出しは、宣言された capability、実際に発行されたリクエスト、認可サーバーの設定の3層で行います。
宣言だけでは実使用が分からないため、次の順で調べる。
- capability の宣言: クライアントが
roots・samplingを宣言しているか、サーバーがloggingを宣言しているかを、server/discoverの応答と各リクエストの_metaから集計する。 - 実リクエストの計測: ゲートウェイ層で
sampling/createMessage・roots/listなどのメソッド名をカウントする。2026-07-28ではMcp-Methodヘッダーが必須になったため、本文を開かずにメソッド別集計ができる。 - 認可サーバーの設定: 認可サーバーのメタデータに
registration_endpointだけがありclient_id_metadata_document_supportedがない構成は、DCR 依存の目印になる。 - トランスポート: 旧
/sseエンドポイントへのアクセスログを確認する。
結果は「機能 × 依存システム × 担当チーム × 移行先 × 期限」の台帳に落とす。台帳の期限は、レジストリの最短撤去日から逆算して四半期単位で置く。
移行先ごとの設計判断は何か
最も重いのはSamplingで、LLM呼び出しの責任がサーバー側へ移り、鍵管理とコスト計上の再設計が要ります。
機能ごとに作業量が違う。
- Roots → ツール引数: ファイル境界を引数やサーバー設定で明示する。Roots と Completion の設計で定義した境界を、パス検証のロジックとして実装側へ移す。
- Sampling → 直接API呼び出し: クライアント側のLLMに補完を委ねる構造をやめる。サーバーが自前でLLMを呼ぶので、APIキーの保管、レート制限、コスト配賦を設計し直す。Samplingの設計で置いた承認ゲートは、サーバー側の予算上限と監査ログに置き換える。
- Logging → OpenTelemetry: 仕様は
_metaのtraceparent・tracestate・baggageの伝播規約を文書化した。ログ出力は OTel パイプラインへ集約する。 - DCR → Client ID Metadata Documents: クライアントが HTTPS URL を
client_idに使い、認可サーバーが URL から JSON を取得して検証する。client_idとURLの完全一致、redirect_urisの照合が必須だ。詳細はOAuth 2.1認可設計を参照。信頼するドメインの許可リストは認可サーバー側のポリシーとして別途設計する。
クライアントの登録方法には優先順位がある。事前登録済みの情報、CIMD、DCR、ユーザー入力の順だ。DCR は認可サーバーが CIMD に未対応の間だけ残る後方互換の経路と位置づけられる。
SDKとCIにどう組み込むか
Tier 1 SDKは非推奨APIに注記を付ける義務があり、CIの警告検知につなぐと移行漏れを防げます。
Tier 1 SDK は、非推奨が Current になった後の次回リリースで、該当 API に言語ごとの仕組み（TypeScript の @deprecated、Java の @Deprecated など）で印を付けなければならない。ランタイム警告の発行は推奨されている。SDK 自体の機能削除は、各 SDK の対応リビジョン方針で決まり、仕様の撤去と同時とは限らない。
社内では次の3点を標準にしたい。
- ビルド時の deprecation 警告をエラー扱いにするのは移行期限の直前からにし、それまでは警告件数を台帳に自動反映する。
- SDK のアップグレード PR で、警告件数が増えていないことを自動確認する。
- 新規サーバー・クライアントの雛形から、Roots・Sampling・Logging・DCR・HTTP+SSE を除外する。
規模の大きい組織では、レジストリの更新を購読する担当を決めておく。新リビジョンのたびに、台帳との差分を確認する運用に組み込む。
参考
- Feature Lifecycle and Deprecation Policy — Model Context Protocol
- Deprecated Features — MCP Specification 2026-07-28
- Key Changes — MCP Specification 2026-07-28
- Client Registration — MCP Specification 2026-07-28
まとめ
MCPは機能ごとに Active・Deprecated・Removed を管理し、非推奨から撤去対象になるまで最短12か月を置くようになった。現時点の移行対象は、Roots・Sampling・Logging・DCR・HTTP+SSE・includeContext の6件だ。宣言、実リクエスト、認可設定の3層で依存を洗い出し、台帳に期限を持たせて四半期ごとに消化する。
複数チームにまたがるMCP資産の棚卸しと移行計画づくりは、KuuのRDE（AI変革プログラム）でご支援しています。お気軽にご相談ください。