MCP Roots・Sampling・Logging：2026-07-28 での非推奨化に伴う移行先

概要

2026年10月25日時点の情報である。リビジョン 2026-07-28 では Roots、Sampling、Logging が非推奨となる。互換性コードを削除する前に、各機能の告知、非推奨機能一覧、ライフサイクルポリシーを再確認する。一覧では、削除可能な最も早い時期を 2027-07-28 以降に公開される最初のリビジョンとしている。これは将来の仕様変更で削除できる時期であり、自動的に機能が停止する日ではない。

非推奨の機能も仕様には残る。新規実装では採用を避け、既存実装では移行を進めるべきである。SDK からの削除スケジュールは別に定められる。また、一般ポリシーでは、条件に該当するセキュリティリスクに対して文書化された迅速な手続きも認めている。そのため、通常の12か月の猶予があらゆる状況で無条件に保証されるわけではない。

重要な理由

3つの機能は目的が異なる。Roots は関連するファイルシステム上の場所を伝え、Sampling はモデルへのリクエストをクライアントに委譲し、Logging はプロトコルのログ通知を届ける。代替手段への移行により、クライアント、サーバー、運用者の間で責任の所在が変わることがある。機能フラグを削除するだけでは、必要な処理が未実装のまま残り得る。

Roots は情報提供に限られることが明記されており、MCP はファイルシステムへのアクセス範囲を強制的に制限しない。現在の Sampling はモデルへのアクセスと権限をクライアントが制御する仕組みである。プロトコルの Logging はサーバーの運用ログとは異なる。代替手段を選ぶ際にも、この区別を維持する。

適用方法

• Roots を明示的なコンテキストに置き換える。 文書で示されている選択肢は、ツールのパラメーター、リソース URI、ディレクトリやファイルを記述するサーバー設定である。実際にアクセスするコンポーネントでパスと権限を検証する。ユーザーの同意と適切なアクセス制御を維持する。ディレクトリが指定されたことは、呼び出し元に読み取り権限がある証明にはならない。このリビジョンで Roots を維持する間は、各リクエストで機能を宣言し、入力リクエストの仕組みを通じて roots/list をやり取りする。
• Sampling をプロバイダーとの直接連携に置き換える。 仕様は言語モデルプロバイダーの API と直接連携することを推奨している。これは単なる名称変更ではなく、責任の所在が変わるものとして扱う。どのコンポーネントがモデルへのアクセスを取得し、どのデータを送るのかを文書化する。従来の Sampling インターフェースはクライアント側の制御を提供し、人による確認を推奨していた。アプリケーションが必要とする場合は同等の確認を維持し、拒否された場合の処理もテストする。移行中はリクエストごとに Sampling の機能を宣言し、非推奨となったサーバー間コンテキストのオプションを避ける。
• 運用ログを適切な出力先に移す。 文書で示されている方法は、stdio トランスポートでは stderr、構造化された可観測性では OpenTelemetry である。ログメッセージに秘密情報や個人情報を含めず、収集したログへのアクセスを制御する。互換性のために引き続きプロトコルの Logging が必要な場合、サーバーは logging を宣言し、クライアントは _meta の io.modelcontextprotocol/logLevel でレベルを要求する。
• リクエスト単位のログ出力をテストする。 そのリクエストにログレベルが指定されていなければ、サーバーは notifications/message を出力してはならない。許可されたメッセージの送信先は、そのリクエストの応答ストリームであり、サブスクリプションストリームではない。あるクライアントのログ詳細度の指定が、別のクライアントのリクエストに影響しないことを確認する。
• 依存関係を個別に廃止する。 展開手順の提案として、利用側を洗い出し、代替手段を導入し、同じ許可済みワークフローを検証してから、非推奨機能の宣言をやめる。どのクライアントがまだその機能を必要としているのか、根拠を残す。

落とし穴

モデルとの直接連携にしても、以前のクライアントの同意取得画面が自動的に引き継がれるわけではない。ログ出力先を変えても、機密情報のマスキングが自動的に維持されるわけではない。パスのパラメーターだけではサンドボックスは作れない。非推奨化は、これらの変更を慎重に計画する理由であり、制御を弱めてよいという意味ではない。