# MCP非推奨ポリシーの運用設計——12か月で棚卸しする

> MCP 2026-07-28はRoots・Sampling・Logging・DCRを非推奨にし、最短12か月の撤去猶予を定めた。依存の棚卸しと移行計画の立て方を仕様原文から整理する。

- Canonical: https://kuucorp.com/blog/mcp-feature-lifecycle-deprecation-inventory-design/
- Date: 2026-10-17
- Last modified: 2026-10-17
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
社内に数十のMCPサーバーとクライアントが散らばる環境で、仕様の一部が「非推奨」になった。どのチームがどの機能に依存しているのか、いつまでに直せばよいのか、答えられる状態にあるでしょうか。

MCP 2026-07-28は、機能単位のライフサイクルとデプリケーション方針を初めて明文化した。プロトコルの全体変更は[ステートレス化の移行ガイド](/blog/mcp-2026-stateless-spec-migration-guide/)で扱った。本稿は、非推奨機能への依存を棚卸しして移行を計画する運用設計に絞る。

## MCPの機能ライフサイクルとは何か

> MCPの機能は3状態で管理され、非推奨から撤去対象になるまで最短12か月の猶予が置かれます。

SEP-2596で採択された方針は、仕様上の機能を3状態で管理する。

| 状態 | 意味 | 実装者への期待 |
|---|---|---|
| Active | 現行リビジョンに含まれる | 規範的要件どおりに実装 |
| Deprecated | 仕様に残るが撤去予定。移行先が明記される | 新規採用は避け、撤去前に移行 |
| Removed | draft から削除済み。直近の Final リビジョンには文書が残る | 次の Current が依存しない |

猶予は、機能が初めて Deprecated になったリビジョンのリリース日から数える。撤去の実行は、猶予が過ぎた後にコアメンテナーが判断する。非推奨のまま長期間残る機能もある、と方針自体が明記している。

例外もある。公開済みのセキュリティ勧告があり、緩和策のない脆弱性を持つ機能は短縮撤去の対象になる。その場合でも非推奨化から撤去まで最低90日は確保される。

## いま非推奨の機能と撤去目安は何か

> 公式レジストリの6件のうち4件は、2027年7月28日以降の最初のリビジョンが最短の撤去時期です。

非推奨機能は公式の[Deprecated Features レジストリ](https://modelcontextprotocol.io/specification/2026-07-28/deprecated)に一覧化されている。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層で行います。

宣言だけでは実使用が分からないため、次の順で調べる。

1. **capability の宣言**: クライアントが `roots`・`sampling` を宣言しているか、サーバーが `logging` を宣言しているかを、`server/discover` の応答と各リクエストの `_meta` から集計する。
2. **実リクエストの計測**: ゲートウェイ層で `sampling/createMessage`・`roots/list` などのメソッド名をカウントする。2026-07-28では `Mcp-Method` ヘッダーが必須になったため、本文を開かずにメソッド別集計ができる。
3. **認可サーバーの設定**: 認可サーバーのメタデータに `registration_endpoint` だけがあり `client_id_metadata_document_supported` がない構成は、DCR 依存の目印になる。
4. **トランスポート**: 旧 `/sse` エンドポイントへのアクセスログを確認する。

結果は「機能 × 依存システム × 担当チーム × 移行先 × 期限」の台帳に落とす。台帳の期限は、レジストリの最短撤去日から逆算して四半期単位で置く。

## 移行先ごとの設計判断は何か

> 最も重いのはSamplingで、LLM呼び出しの責任がサーバー側へ移り、鍵管理とコスト計上の再設計が要ります。

機能ごとに作業量が違う。

- **Roots → ツール引数**: ファイル境界を引数やサーバー設定で明示する。[Roots と Completion の設計](/blog/mcp-roots-completion-server-design/)で定義した境界を、パス検証のロジックとして実装側へ移す。
- **Sampling → 直接API呼び出し**: クライアント側のLLMに補完を委ねる構造をやめる。サーバーが自前でLLMを呼ぶので、APIキーの保管、レート制限、コスト配賦を設計し直す。[Samplingの設計](/blog/mcp-sampling-server-llm-request-design/)で置いた承認ゲートは、サーバー側の予算上限と監査ログに置き換える。
- **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認可設計](/blog/mcp-security-oauth-scope-design/)を参照。信頼するドメインの許可リストは認可サーバー側のポリシーとして別途設計する。

クライアントの登録方法には優先順位がある。事前登録済みの情報、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](https://modelcontextprotocol.io/community/feature-lifecycle)
- [Deprecated Features — MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/deprecated)
- [Key Changes — MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
- [Client Registration — MCP Specification 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration)

## まとめ

MCPは機能ごとに Active・Deprecated・Removed を管理し、非推奨から撤去対象になるまで最短12か月を置くようになった。現時点の移行対象は、Roots・Sampling・Logging・DCR・HTTP+SSE・`includeContext` の6件だ。宣言、実リクエスト、認可設定の3層で依存を洗い出し、台帳に期限を持たせて四半期ごとに消化する。

複数チームにまたがるMCP資産の棚卸しと移行計画づくりは、[KuuのRDE（AI変革プログラム）](/services/rde/)でご支援しています。お気軽にご相談ください。