MCP Samplingが非推奨に — 移行先と2027年までの猶予期間

MCP Samplingが非推奨になった

MCP(Model Context Protocol)の基本的な仕組み自体をまだ押さえていない場合は、先にMCPとはを確認しておくと、この記事の以降の説明が読みやすくなります。

MCP(Model Context Protocol)のSampling機能が、2026-07-28のプロトコルリビジョンで非推奨になりました。SEP-2577という提案に基づく変更です。新規の実装はSamplingの採用を避け、既存の実装もLLMプロバイダーのAPIへ直接統合する形への移行が推奨されています。

Samplingは、MCPサーバーがクライアント経由でLLMに生成(補完・生成)を依頼できる仕組みでした。サーバー自身がAPIキーを持たなくても、クライアント側のモデルアクセスを借りてエージェント的な振る舞いを実装できる点が売りでした。非推奨化はこの仕組みそのものを否定するものではなく、「12か月の猶予期間を置いて緩やかに畳む」という位置づけです。

たとえば、天気を調べるツールを持つMCPサーバーが、複数都市の問い合わせを1回の会話でさばきたいとします。Samplingを使えば、サーバーはクライアントに「この結果をふまえてもう一度生成してほしい」と頼み返し、クライアント側のLLMがツール呼び出しを重ねながら会話を完結させることができました。サーバー自身は生成コストも認証も持たずに、こうした多段のやり取りを実現できていたわけです。

廃止されるのはいつか

MCPは2026-07-28のリビジョンで「機能ライフサイクルポリシー」という仕組みを新設しました。Active・Deprecated・Removedの3状態を定義し、Deprecatedになった機能は最低12か月間、削除の対象にならないことを保証します。

Samplingが非推奨になったのは2026-07-28です。ここに12か月を足すと、削除が可能になるのは2027-07-28以降にリリースされる次のリビジョン以降ということになります。「削除可能になる」であって「その日に消える」ではない点に注意が必要です。実際の削除は、コアメンテナーがリリース準備のタイミングで判断する裁量事項とされています。

同じ2026-07-28リビジョンでは、RootsとLoggingという2つの機能も同時に非推奨になりました。3つとも同じSEP-2577に基づく変更で、猶予期間もそろって2027-07-28以降です。Samplingだけが単独で狙い撃ちされたわけではなく、クライアント主導の補助的な機能群をまとめて整理する動きの一部だと分かります。

なぜSamplingは非推奨になったのか

公式の移行先の説明は簡潔です。Samplingが担っていた「サーバーがLLMを呼ぶ」という役割を、サーバー自身がLLMプロバイダーのAPIに直接統合する形に置き換える、というものです。Roots(ファイルパスをツール引数やリソースURIで渡す形へ)、Logging(標準エラー出力かOpenTelemetryへ)も、同じ発想でクライアント経由の間接的な仕組みを手放しています。

Samplingには、ツール呼び出しを伴う多段のやり取りを1つのリクエストの中でこなす仕組みも用意されていました。サーバーがツール定義と選択方式(toolChoice)を添えて生成を依頼し、クライアント側のLLMがツールを呼び出し、その結果をサーバーに返してまた生成を依頼する、というループです。設計としては凝っていますが、この複雑さ自体が、各社のLLM APIを直接呼ぶ実装に比べて回り道になっていた面があります。

includeContext パラメータの thisServer / allServers という値も、Samplingより一足早く2025-11-25の時点で非推奨(soft-deprecated)になっていました。2026-07-28でこの2値は正式にDeprecated状態へ格上げされ、Sampling本体と歩調をそろえて猶予期間を消化していきます。

仕様書はSamplingについて、セキュリティ上の注意点を独立した節で列挙しています。

• 人による承認の仕組みを用意すること
• メッセージの内容を両者で検証すること
• モデルの優先度ヒントに従うこと
• レート制限を設けること
• 機微な情報を適切に扱うこと

ツールを使ったSamplingではさらに、ツール呼び出しと結果の対応を厳密に一致させることと、ツールループに反復回数の上限を設けることが加わります。これだけの注意点を並べる必要がある機能を、各社のLLM APIをサーバーが直接呼ぶ設計に置き換えれば、注意点の多くはプロバイダー側のSDKやAPIの責務に移せます。非推奨化の裏には、こうした複雑さの削減という狙いも透けて見えます。

MCPのセキュリティ設計全般(承認フローや機微情報の扱い)を体系的に確認したい場合は、MCPセキュリティガイドにまとめています。

移行先はどう変わるか

表からも分かるとおり、移行はコードの書き換えだけでは済みません。Samplingが担っていた「クライアント側でユーザーが生成内容を確認できる」という安全策も、サーバーが自前でLLMを呼ぶ形に変えると失われます。仕様書自身も、Samplingには常に人間による承認の余地を残すことを明記していました。移行後にこの安全策をどう再現するかは、サーバー実装者側の設計課題として残ります。

Claude Codeユーザーへの実害はほぼない

Claude CodeはMCPのクライアントとして動作しますが、公式ドキュメントにSampling機能への言及は見当たりません。ツールの権限モデルやMCPサーバー接続の詳細を解説したドキュメントの中に、sampling capabilityへの対応を示す記述は確認できませんでした。

これは「Claude CodeがSamplingに対応していないと断定できる」という意味ではありません。ドキュメントに書かれていないことは、実装が無いこととイコールではないためです。ただし実務上の結論ははっきりしています。Claude Codeを使ってMCPサーバーに接続しているだけの読者にとって、この非推奨化が既存の使い方を壊すことはまず考えられません。Samplingは「サーバーがクライアントのモデルを借りる」ための仕組みであり、Claude Code側がそもそもこの経路を前面に出していない以上、利用者が意識する場面自体が少ないからです。

Claude Codeは2026-07-28のプロトコルリビジョン自体には、MCP TypeScript SDK 2.0を使う新しい接続方式(v2ランタイム)で対応を進めています。ただしこのv2ランタイムのドキュメントが説明しているのは、list_changed 通知の受信方法やOAuthの発行者検証といった、クライアント側の接続まわりの挙動が中心です。サーバーからの生成依頼を受け付けるSampling capabilityの宣言については、v1・v2いずれのランタイムの説明にも登場しません。プロトコルバージョンへの追随と、個別機能への対応は別の話だと分けて考える必要があります。

影響が出るとすれば、Samplingを使う設計でMCPサーバーを自作している開発者側です。次のリビジョンサイクルまでは動き続けますが、新規に着手するなら最初からLLMプロバイダーAPIへの直接統合を選んだほうが、将来の書き換えを避けられます。MCPサーバーを自作する具体的な手順はMCPサーバー自作ガイドで解説しています。

実装者の対応チェックリスト

Samplingを使ったMCPサーバーをすでに運用している場合、いますぐ動かなくなるわけではありません。ただし12か月という猶予期間は、書き換えの計画を立てるには十分な一方、放置してよいほど長くもありません。

• 依存箇所の棚卸し: sampling/createMessage を呼んでいる箇所と、includeContext に thisServer / allServers を渡している箇所を洗い出す(例: grep -rn "sampling/createMessage\|includeContext" src/)
• 移行方針の決定: サーバー自身がAPIキーを保持してLLMプロバイダーへ直接統合するか、機能自体を縮小するかを決める
• 承認フローの再設計: Samplingが担っていた「人による確認」を、移行後の設計でどう担保するかを決めておく
• 新規実装での回避: これから作るMCPサーバーでは、最初からSamplingを使わない設計にする
• ドキュメントの更新: READMEやセットアップ手順にSampling capabilityへの言及がある場合、非推奨であることと移行の目安時期を明記しておく

猶予期間の12か月は、書き換えを急がせるためではなく、依存関係を整理する時間として与えられています。移行を急ぐより、まず依存箇所の棚卸しを先に済ませておくほうが、後になって手戻りの少ない移行になります。

まとめ

MCP SamplingはSEP-2577に基づき2026-07-28で非推奨になり、削除が可能になるのは2027-07-28以降です。Roots・Loggingという2つの機能も同時に非推奨化されており、クライアント経由の補助的な仕組みをLLMプロバイダーAPIへの直接統合に寄せる、という一貫した方針の一部です。

Claude Codeを使ってMCPサーバーに接続しているだけの読者への実害はほぼありません。影響を受けるのは、Samplingでエージェント的な機能を組んでいるMCPサーバーの実装者です。12か月の猶予がある間に、移行方針と承認フローの再設計を済ませておく価値があります。