Claude Media
MCP Samplingが非推奨に — 移行先と2027年までの猶予期間
MCPClaude Code解説

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

MCPのSampling機能が2026-07-28リビジョンで非推奨になりました。廃止までの猶予期間、移行先、Claude Code利用者への実際の影響を解説します。

読了目安 約12分

MCP Samplingが非推奨になった

MCP(Model Context Protocol)のSampling機能が、2026-07-28のプロトコルリビジョンで非推奨になりました。SEP-2577という提案に基づく変更です。仕様書は、新規の実装はSamplingを採用せず、既存の実装はLLMプロバイダーのAPIと直接統合する形へ移行することを求めています(どちらも SHOULD 水準)。MCPの基本から確認したい場合は、先にMCPとはが役立ちます。

Samplingは、MCPサーバーがクライアント経由でLLMに生成(補完・生成)を依頼できる仕組みです。サーバーがAPIキーを持たなくても、クライアント側のモデルアクセスを借りてエージェント的な振る舞いを組めるのが売りでした。仕様書は「サーバーのAPIキーが不要」と書いています。

非推奨は即時削除ではなく、12か月以上の猶予をつけて畳む手続きです。

廃止はいつか

2026-07-28のリビジョンで、MCPは「機能ライフサイクルポリシー」(SEP-2596)を新設しました。機能をActive・Deprecated・Removedの3状態で管理し、Deprecatedの機能は最低12か月、削除の対象にならないと定めています。猶予は、非推奨にしたリビジョンのリリースから数えます。

Samplingは2026-07-28に非推奨になったので、削除の対象になりうるのは2027-07-28以降に出る最初のリビジョンです。非推奨の一覧ページでは、この点が「Earliest removal: First revision released on or after 2027-07-28」と表になっています。ここで言う「最短」は削除が可能になる時点で、その日に消えるわけではありません。実際に削除するかどうかは、リリース準備の段階でコアメンテナーが決めます。

日程

Samplingまわりの非推奨の経過

  1. 2025-03-26HTTP+SSEトランスポートが非推奨に

    のちにSEP-2596で、ライフサイクルポリシー上のDeprecatedへ分類し直されました。移行先はStreamable HTTPです。

  2. 2025-11-25includeContextの2値がsoft-deprecated

    "thisServer" と "allServers" が対象です。

  3. 2026-07-28Sampling・Roots・Loggingが非推奨に

    SEP-2577による変更です。同じリビジョンで、includeContext の2値も正式にDeprecatedへ格上げされました。

  4. 2027-07-28以降削除が可能になる最初のリビジョン

    includeContext の2値は、削除されるとしてもSampling本体より後にはなりません(同時か、それ以前です)。

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

提案(SEP-2577)の動機欄は、この3機能を「実装の複雑さに対して採用が少ない」ものとして挙げています。Samplingについての理由は「実装が複雑(人による承認・モデル選択・セキュリティ)で、クライアント側の採用が少ない」です。コアコントリビューターの会合で洗い出された、という経緯も書かれています。同じ提案には、ワイヤ上のプロトコルは変えず、非推奨は予告に過ぎないという説明もあります。

複雑さの中身は、仕様書のセキュリティ節を読むと具体的に見えます。クライアントとサーバーに求められる項目は次のとおりです(いずれも SHOULD か MUST)。

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

ツール付きのSamplingでは、さらに2点が加わります。ツール使用(toolUse)への応答はすべて、対応する toolUseId を持つ結果で返さなければなりません(MUST)。ツールループには反復回数の上限を設けることが推奨されます。

3機能が同時に整理された理由は、提案文で見ると三者三様です。Rootsは「意味づけがあいまいで、ツール引数やサーバー設定と重なる」、Loggingは「標準エラー出力やOpenTelemetryと重なる」とされています。Samplingだけが、実装の重さと採用の少なさを理由にしています。

MCPのセキュリティ設計全般はMCPセキュリティガイドに別立てでまとめています。

3機能の移行先は別々

移行先

2026-07-28で非推奨になった3機能の移行先

  • Sampling

    LLMプロバイダーのAPIを、サーバーが直接呼びます。

  • Roots

    ディレクトリやファイルを、ツールのパラメーター、リソースURI、サーバー設定のいずれかで渡します。

  • Logging

    stdioトランスポートでは標準エラー出力へ書き、監視にはOpenTelemetryを使います。

同じリビジョンでは、OAuthのDynamic Client Registration(RFC 7591)も非推奨になりました。置き換え先はClient ID Metadata Documentsです。こちらはSEP-2577ではなく、別のPR(#2858)による変更で、後方互換のため認可サーバー側が未対応のときは使い続けられます。

Samplingの呼び出しを置き換えると何が変わるか

くらべる

Samplingと、サーバーによる直接のAPI呼び出し

クライアントが生成する

Sampling(非推奨)

サーバーは sampling/createMessage をクライアントに頼みます。モデルの選択は modelPreferences のヒントを手がかりにクライアントが決め、APIキーもクライアント側のものが使われます。生成の前後で、ユーザーが内容を確認する場面を挟めます。

サーバーが生成する

直接統合(移行先)

サーバーが自分のAPIキーでプロバイダーのAPIを呼びます。モデルは、サーバーが名前を指定して決めます。承認の手順が必要なら、サーバー実装の側で組みます。

置き換えの難所は、コードの書き換えより安全策のほうです。仕様書はSamplingについて、拒否できる人間をつねに挟むことを SHOULD として求めており、プロンプトの確認・編集と、返ってきた生成結果の確認をその具体策に挙げています。サーバーが直接APIを呼ぶ形では、この確認はクライアントの画面に現れません。要否も含め、サーバー実装側が設計し直す部分です。

もう一つ、生成コストがサーバー運営者の請求に乗る点も変わります。

2026-07-28版のSampling要求は、どんな形をしているか

2026-07-28のリビジョンでは、サーバーはツール呼び出しの途中で、InputRequiredResult に入れた sampling/createMessage をクライアントへ返します。クライアントはユーザーの承認を挟んで生成し、再試行されたリクエストの inputResponses に結果を載せて返します。仕様書の例は次のとおりです。

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      { "role": "user", "content": { "type": "text", "text": "What is the capital of France?" } }
    ],
    "modelPreferences": {
      "hints": [{ "name": "claude-3-sonnet" }],
      "costPriority": 0.3,
      "intelligencePriority": 0.8,
      "speedPriority": 0.5
    },
    "temperature": 0.1,
    "systemPrompt": "You are a helpful assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

ここで棚卸しの目印になるのが includeContext です。"thisServer" と "allServers" はSampling本体より先に非推奨扱いだった値で、移行時はフィールドごと省くか "none" にします。省略時の既定値が "none" なので、省くだけで足ります。仕様書は、クライアントが sampling.context 機能を宣言していない限り、これらの値を使うべきでないとも書いています。

ツール付きの場合の流れは次のとおりです。仕様書の図を、手順に直しました。

流れ

ツール付きSamplingの往復

  1. 1

    サーバーが生成を頼む

    messages と tools を添えた sampling/createMessage を、InputRequiredResult に入れて返します。tools の定義は、その要求の中だけで有効です。登録済みのツールと一致している必要はありません。

  2. 2

    クライアントがユーザーに確認する

    承認や修正を受けたうえで、LLMに要求を転送します。モデルがツールを呼ぶと、stopReason は "toolUse" になります。

  3. 3

    サーバーがツールを実行する

    クライアントはツール呼び出しの内容もユーザーに見せ、承認を得てから、tool_use を含む応答をサーバーへ返します。サーバーはそれを受けて get_weather("Paris") のようなツールを実行します。

  4. 4

    結果を添えて再び頼む

    ツールの結果を含む履歴で、もう一度生成を頼みます。この往復を、モデルが最終テキスト("endTurn")を返すまで繰り返します。最後の周回で toolChoice: {mode: "none"} を渡し、最終結果を強制する使い方も、仕様書に挙がっています。

Claude Codeを使うだけなら影響は小さい

Claude CodeはMCPのクライアントです。Samplingを受けるクライアントは、sampling 機能を宣言しなければなりません。Claude Codeの公式ドキュメントが、2026-07-28のリビジョンの接続で宣言すると明記している機能は elicitation: {form: {}, url: {}} です。

非推奨は予告にとどまり、ワイヤ上のプロトコルは変わらず、猶予期間中は機能も動き続けます。Claude Codeで既存のMCPサーバーに接続しているだけなら、今の設定や操作を変える必要はありません。サーバーがSamplingを必要とするかどうかは、サーバー側の作りの問題です。

Claude Code自体は、2026-07-28のリビジョンに対応する接続方式(v2ランタイム、MCP TypeScript SDK 2.0ベース)を持っています。使われる条件は、公式ドキュメントでは次のとおりです。

  • フィーチャーフラグを取得するセッション: v2.1.232以降でv2
  • 取得しないセッション(Bedrockなどのクラウド経由、テレメトリー無効など): v2.1.274以降でv2が既定
  • 自分で選ぶ場合: 環境変数 MCP_SDK_GENERATION に v1 か v2 を指定

v2ではHTTPサーバーに新しいリビジョンへの対応を問い合わせます。stdioサーバーへ問い合わせるには、MCP_PROTOCOL_NEGOTIATION を auto にします。手元のv2.1.287で claude mcp --help を見ると、サブコマンドは add / add-json / add-from-claude-desktop / get / list / remove などで、サーバーの追加と管理が中心です。

影響が出るのは、Samplingを使うMCPサーバーを自作している側です。次のリビジョンサイクルまでは動き続けますが、新規に作るなら最初からLLMプロバイダーAPIへの直接統合を選ぶと、将来の書き換えを避けられます。自作の手順はMCPサーバー自作ガイドで扱っています。

運用中のMCPサーバーを点検する

Samplingを使うサーバーは、いますぐ動かなくなるわけではありません。ただし、12か月の猶予があっても、放置してよい長さではありません。

次のコマンドで、依存箇所の洗い出しから始められます。

grep -rn "sampling/createMessage\|includeContext\|sampling.tools\|sampling.context" src/

見つかった箇所は、次の4つに分けて考えると決めやすくなります。

  • 移行方針: サーバー自身がAPIキーを持って直接統合するか、その機能自体を縮小するか
  • 承認の設計: Samplingが担っていたユーザー確認を、移行後にどこで担保するか
  • 新規実装: これから作るサーバーでは、最初からSamplingを使わない
  • 利用者への告知: READMEやセットアップ手順にSampling機能への言及があれば、非推奨であることと目安の時期を書く

まとめ

Samplingを使うサーバーを持っているなら、移行で一番手間がかかるのはAPI呼び出しの置き換えよりも、クライアント画面で担っていた承認をどこへ移すかの設計です。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →