3行まとめ
2025-11-25版の仕様では、serverがclientへLLM生成を依頼する `sampling/createMessage` が説明されています。
SEP-2577はSamplingを含む機能のdeprecated化を扱うため、長期の中核依存には慎重さが必要です。
MCP接続、モデル実行、context共有、tool実行、監査と課金を別々に設計します。
「仕様にあるか」だけでなく、将来変更と権限設計まで含めて判断します。
MCP Samplingは、MCPサーバーがクライアント経由でLLM生成を依頼するための仕組みで、2025-11-25版の公式仕様には sampling/createMessage として定義されています。
一方で、公式SEP-2577はRoots、Sampling、Loggingの廃止を扱うFinalの提案であり、Samplingを今から長期の中核機能として設計するなら慎重に読むべき段階です。
実務では、Samplingを「使えるか」だけで見ず、MCP接続の認可、モデル実行、プロンプト共有、tool実行、監査と課金を別々に承認できる設計にしておくのが安全です。
今からSamplingに依存してよいか
公開MCPサーバーや長期保証が必要な業務機能では、中核依存にしないほうが無難です。社内PoC、自社でclientとserverを両方管理できる検証、fallbackを持つ補助機能なら、feature flag付きで試す余地はあります。
「仕様に載っているから安定」とも、「SEPがFinalだから今日から使えない」とも言い切れません。2026年6月10日時点で見るべきポイントは、Samplingがまだ仕様上の機能であることと、将来の削除や低採用を見越した設計判断を求められていることです。
この記事で決めること
MCP Samplingを実装する前に、次の4点を判断できるようにします。
- Samplingが解く問題と、実装側が引き受ける責任
- SEP-1577とSEP-2577をどう読み分けるか
- Samplingに依存してよいケース、避けたいケース
- LLM呼び出し権限を5層に分ける実務設計
MCPのTools、Resources、Promptsの基本から確認したい場合は、先にMCP Registryからサーバーを選ぶ前に：OAuth・tool poisoning・allowlistの安全な見方を読むと、サーバー選定時の権限境界がつかみやすくなります。
この記事で扱わないこと
主題はSamplingの採用判断と権限設計です。TypeScript SDKやPython SDKの完全な実装チュートリアル、特定LLMプロバイダの料金比較、特定クライアントごとの対応表は扱いません。
また、X/Twitterは需要シグナルとして確認しましたが、指定アカウントの公開ページと検索では直近72時間の確認可能な関連投稿を取得できませんでした。本文の技術的な根拠は、MCP公式仕様、SEP、公式GitHubリポジトリに限定します。
この記事でわかること
Samplingが仕様上どう扱われ、SEP-2577が何を示しているかを確認できます。
server、client、userのどこでLLM呼び出しを承認するかを分けられます。
非対応client、拒否、停止、仕様変更に備えたfallbackを検討できます。
protocol、security、operationsの観点で採用前に試す項目を整理できます。
判断軸を先に持つと、SDKサンプルから始めても後戻りが少なくなります。
読み終えるころには、MCP Samplingを「便利そうだから入れる」のではなく、仕様状態、互換性、権限、失敗時の代替経路から判断できるようになります。
採用判断で見る軸
Samplingを検討するときは、まず「誰がLLMを呼ぶのか」を分けます。Samplingでは、MCPサーバーが直接LLM APIキーを持つのではなく、クライアントにLLM生成を依頼します。つまり、モデル選択、プロンプト確認、生成結果の返却、ユーザー承認の多くはクライアント側の責任になります。
ここを曖昧にしたまま実装すると、サーバー側は「LLMが必要な処理を依頼しただけ」、クライアント側は「サーバーから来た要求を通しただけ」になり、プロンプト漏えい、過剰なコンテキスト共有、課金上限超過、危険なtool実行の責任境界がぼやけます。
読者が持ち帰れるチェックリスト
本文では、次のような確認項目まで落とし込みます。
- clientが
samplingcapabilityを宣言していない場合のfallbackはあるか - tools付きSamplingで
sampling.toolscapabilityを確認しているか includeContextに依存しすぎていないか- ユーザーがpromptと生成結果を確認できるか
- tool loopの最大反復回数を決めているか
- MCP AuthorizationとLLM実行許可を混同していないか
- 監査ログにprompt、model、token、tool実行、承認者を残せるか
読む前に押さえたい用語
この記事では、MCPのhost、client、serverを次の意味で使います。
- host: Claude DesktopやIDEなど、ユーザーが触るアプリケーション
- client: hostの中で特定のMCP serverと通信する接続単位
- server: Tools、Resources、Promptsなどを公開する外部システム側
Samplingはserver featureではなく、clientがserverに提供するclient featureです。この向きが重要です。通常のTool呼び出しではLLMやhostがserverのtoolを呼びますが、SamplingではserverがclientにLLM生成を依頼します。
前提知識: SamplingはserverからclientへのLLM生成依頼
- 11. serverが依頼する
MCPサーバーが、要約や判断に使うpromptと条件をclientへ送ります。
- 22. clientが制御する
clientはモデル、token上限、context、ユーザー確認、拒否を扱います。
- 33. LLMが生成する
client側のモデルアクセスを使って、要求された内容を生成します。
- 44. 結果を確認する
必要に応じて、promptや生成結果をserverへ返す前にユーザーが確認します。
- 55. serverへ返す
承認された生成結果だけをserverへ返し、後続処理に使います。
SamplingはLLM補完APIのproxyではなく、client側の承認と制御を前提にした依頼です。
MCP Samplingは、MCPサーバーが「この情報をもとにLLMで判断、要約、生成してほしい」とクライアントへ依頼するための仕組みです。公式仕様では、サーバーが sampling/createMessage を使ってクライアント側のLLM生成を要求する流れとして説明されています。
何がうれしいのか
Samplingの魅力は、MCPサーバーがLLMプロバイダのAPIキーを持たなくても、AI依存の処理を実行できる点です。たとえば、社内ドキュメント検索MCPサーバーが検索結果の要約を作りたい場合、サーバー自身がOpenAIやAnthropicなどのAPIキーを持つのではなく、クライアント側のモデルアクセスを使って要約を依頼できます。
この設計では、モデル選択やユーザー承認をクライアント側に寄せられます。サーバー実装者にとっては、モデルAPIごとのSDK、課金、レート制限、APIキー管理を抱えずに済む可能性があります。
何が難しいのか
難しさは、Samplingが「LLM補完APIのproxy」ではないことです。サーバーがLLM生成を要求できるなら、クライアントは次を制御しなければなりません。
- そのSampling要求をユーザーに見せるか
- どのpromptをLLMへ送るか
- どのcontextを含めるか
- どのモデル、上限token、stop条件で実行するか
- 生成結果をそのままサーバーへ返してよいか
- tools付きSamplingでLLMが求めたtool実行を許可するか
公式のclient conceptsでも、Samplingはセキュリティとユーザー制御を保ちながらサーバーからLLM completionsを要求する仕組みとして整理されています。ここでの「制御」は抽象的な理念ではなく、UI、承認、ログ、レート制限、データ最小化に落ちる実装要件です。
ToolsやElicitationとの違い
通常のMCP Toolは、LLMやhostがserver側の関数を呼ぶ仕組みです。Elicitationは、serverがユーザーに追加情報や確認を求める仕組みです。Samplingはそのどちらとも違い、serverがclient側のLLM生成を求めます。
人間の確認が必要な入力を取りたいなら、SamplingよりもElicitationが合う場面があります。Elicitationのform、URL、OAuth、人間承認の分け方は、MCP ElicitationをAIエージェントに入れる前に：form・URL・OAuth・人間承認の分け方で整理しています。
なぜ今、MCP Samplingを読み直す必要があるか
- 2025-11-25仕様
`sampling/createMessage` が定義され、serverからclientへのLLM生成依頼が説明されています。
- SEP-1577
SamplingにtoolsとtoolChoiceを加え、tool useを含むloopを作れる方向を示します。
- SEP-2577
Roots、Sampling、Loggingのdeprecated化を扱い、新規投資への警告として読めます。
- 2026-06-10時点
即時削除ではなく、仕様状態と将来変更を見越した設計判断が必要です。
「使える」と「長期の中核にしてよい」は別の判断です。
2026年6月時点でSamplingを読み直す理由は、公式情報が一方向ではないからです。2025-11-25版の仕様にはSamplingが定義されています。一方で、SEP-2577はSamplingを含む複数機能の廃止を扱っています。
2025-11-25仕様には sampling/createMessage がある
2025-11-25版のSampling仕様では、MCPサーバーがクライアント経由でLLM samplingを要求する流れが説明されています。サーバーはテキスト、音声、画像を含むやりとりを要求でき、クライアントはモデルアクセス、モデル選択、権限を制御する側に残ります。
根拠
Sampling仕様では、セキュリティとtrust and safetyの観点から、Sampling要求を拒否できるhuman-in-the-loopを置くべきだと説明されています。アプリケーションは、Sampling要求を確認しやすいUI、送信前のprompt確認や編集、生成結果をサーバーへ返す前の確認を設計すべきです。
この時点で、Samplingは単なるバックエンドAPIではありません。hostやclientのUXに影響する機能です。
SEP-1577はtools付きSamplingを追加した
SEP-1577は、Samplingに tools と toolChoice を導入する提案です。これにより、サーバーはSampling要求の中でLLMにtool useを求め、tool resultを追加して再度Samplingするようなagentic loopを作れます。
ただし、これは便利さと同時に実装負荷を増やします。LLMがtoolを呼びたいと言ったとき、実際にtoolを実行するのはサーバー側です。サーバーは、tool useとtool resultの対応、最大反復回数、途中失敗、最終回答の生成を制御しなければなりません。
注意点
tools付きSamplingは、clientが sampling.tools capabilityを宣言していることを前提にします。clientが対応していないのにtools付き要求を投げる設計は、互換性の低い実装になります。
SEP-2577はSampling廃止を扱うFinalの提案
SEP-2577は、Roots、Sampling、Loggingを廃止対象にするFinalのStandards Track SEPです。Samplingについては、実装が複雑であること、client採用が低いこと、サーバーが直接LLM APIを呼ぶ代替があることが背景として挙げられています。
ここで大事なのは、SEP-2577を「もう動かない」という意味に読まないことです。SEP-2577は、廃止シグナルと移行期間を示す文書です。仕様に含まれる期間中は機能が残り、wire-levelの破壊的変更をすぐ入れる趣旨ではありません。
注意点
逆に、「まだ仕様にあるから長期安定」と読むのも危険です。新規プロダクトの中核機能にするなら、廃止シグナルが出ている機能に依存する理由、代替経路、停止手順を説明できる必要があります。
結果: 新規の中核依存にはしない、限定用途ならfallback付きで検証する
権限と監査を扱う機能では、単純な優劣ではなく運用条件で判断します。
この記事の実務結論は明確です。MCP Samplingは、今から公開プロダクトの中核機能に据えるにはリスクが高いです。ただし、社内やPoCで、自社がclientとserverを管理でき、失敗時の代替経路を持てるなら検証価値はあります。
依存してよい可能性があるケース
Samplingを試してよいのは、次の条件がそろう場合です。
- 自社管理のclientとserverで閉じている
- ユーザー承認UIを自分たちで設計できる
- client capabilityを明示的に確認できる
- 非対応clientでも通常フローが成立する
- feature flagで停止できる
- prompt、model、token、tool実行のログを残せる
たとえば、社内のナレッジ検索MCPサーバーで、検索結果を要約する補助機能としてSamplingを試すなら、限定機能として成立しやすいです。要約が失敗しても検索結果そのものを返せるなら、ユーザーの業務は止まりません。
条件
「対応clientならSampling、非対応clientなら何もしない」では弱いです。非対応clientでは、通常Toolで未要約の結果を返す、server-side LLMに切り替える、ユーザーへ手動要約を促すなど、明示的なfallbackを用意します。
避けたいケース
次のケースでは、Samplingを中核依存にしないほうがよいです。
- 不特定多数のMCP clientに接続される公開MCPサーバー
- 長期互換性を契約やSLAとして保証する機能
- 課金、承認、監査をSamplingの成否に強く依存する業務
- 生成結果が外部APIのwrite操作につながる機能
- client側の承認UIやログ仕様を管理できない環境
公開MCPサーバーでは、接続元clientのcapability、UI、承認設計、ログ保存方針をサーバー側で管理できません。そこでSamplingを前提にすると、動く環境と動かない環境の差がそのままユーザー体験の差になります。
注意点
「clientが対応していたら高機能になる」は、一見よい設計に見えます。しかし、機能差が権限差や監査差に直結するなら、運用上は危険です。高機能側だけ危険なwrite toolを呼べる、対応clientだけpromptを過剰共有する、といった差が出ないようにします。
Samplingを使わない代替パターン
Samplingを使わない場合の選択肢は複数あります。
| 代替 | 向いているケース | 注意点 |
|---|---|---|
| server-side LLM API | serverがモデル、料金、ログを管理したい | APIキー管理と利用規約確認が必要 |
| 通常MCP Toolに分解 | deterministicな処理や検索、変換 | LLM判断をserverに隠さない |
| Elicitation | ユーザー確認や追加入力が必要 | 秘密情報をformで集めすぎない |
| 外部ワークフロー | 承認、監査、非同期処理が必要 | 完了通知とリトライ設計が必要 |
| ジョブキュー | 長時間処理やコスト制御が必要 | 状態管理とキャンセルが必要 |
Samplingの魅力は「serverにLLM APIキーを持たせず、clientのモデルアクセスを使える」ことです。しかし、モデル実行の責任を自社で持つべき業務では、server-side LLM APIのほうが監査しやすい場合もあります。
SEP-2577をどう読むべきか
wire-level behaviorやcapability negotiationをすぐ壊す話としては読まないほうが安全です。
これから中核機能として依存するなら、将来の削除や代替設計を見込む必要があります。
clientとserverの両方を管理できるか、失敗を説明できるかが設計リスクになります。
tools付きSamplingの拡張と、Sampling廃止のシグナルを混同しないようにします。
SEPは採用可否の結論ではなく、依存度を下げる設計判断の材料です。
SEP-2577は、Sampling採用判断の中心になる一次情報です。ここを「廃止された」「まだ使える」の二択で読むと、実装判断を誤ります。
廃止は即時破壊ではなく、エコシステムへのシグナル
SEP-2577は、Roots、Sampling、Loggingをdeprecatedにする提案です。Samplingでは sampling/createMessage が対象に含まれます。文書上は、該当仕様版からdeprecatedとなり、一定期間は機能が残る前提で説明されています。
つまり、既存実装をすぐ壊す話ではありません。むしろ、clientやserverの実装者に「この機能へ新規投資するなら、将来の削除や代替設計を見込んでほしい」と伝えるシグナルです。
根拠
SEP-2577では、廃止期間中にwire-level protocol behaviorを変えないこと、型やcapability negotiationをすぐ削除しないことが説明されています。記事公開時点では、FinalのSEPとして扱い、対象機能と移行期間を再確認しました。
低採用と実装負荷は設計リスク
Samplingは発想としては強力です。サーバーがclient側LLMを使えるなら、モデル非依存のMCPサーバーを作りやすくなります。
しかし、正しく実装するには、human-in-the-loop、model selection、prompt確認、context制御、tools付きloop、拒否時エラー、監査ログまで必要です。client実装者にとっては重い機能です。SEP-2577が挙げる低採用や複雑性は、単なる仕様上の不満ではなく、実務の互換性リスクです。
評価基準
採用判断では、次の問いに答えます。
- 自社でclientもserverも管理できるか
- Sampling非対応clientでも成立するか
- tool loopの失敗をユーザーに説明できるか
- 将来の仕様変更時に機能停止できるか
- モデル実行とtool実行のログを同じ監査単位で残せるか
この5つに答えられないなら、Samplingは補助機能に留めるほうがよいです。
SEP-1577とSEP-2577を混同しない
SEP-1577はSampling with Toolsを扱い、SEP-2577はSamplingを含む機能の廃止を扱います。方向が違う情報に見えますが、時系列と目的が違います。
SEP-1577は、Samplingでagentic loopを作るために足りない要素を補う提案です。SEP-2577は、実装負荷や採用状況を踏まえて、コア仕様から外す方向を示す提案です。新規実装者は、SEP-1577で「何ができるか」を見たあと、SEP-2577で「それに長期依存してよいか」を判断する必要があります。
サーバー側LLM呼び出し権限は5層に分ける
- 11. MCPサーバーへの認可
どのserverへ接続してよいかを決めます。HTTP transportとstdio transportでは扱いが異なります。
- 22. モデル実行の許可
どのモデルを使うか、maxTokens、回数、コスト上限、自動承認の範囲を決めます。
- 33. promptとcontext公開
何をLLMへ送るか、どのcontextを含めるか、ユーザーに見せられる粒度にします。
- 44. tool実行の許可
read-onlyかwriteか、外部APIを呼ぶか、反復回数や停止条件を別に制御します。
- 55. 監査と課金
user、server、prompt要約、model、tool result、承認、token、コストを追えるようにします。
接続を許可したことは、LLM生成やtool実行を許可したこととは別です。
Samplingの本当の論点は、protocol methodの名前ではなく、LLM呼び出し権限をどこで承認するかです。実務では、少なくとも5層に分けて設計します。
1. MCPサーバーへの認可
まず、MCPサーバーへ接続してよいかを決めます。HTTP-based transportでは、MCP Authorization仕様がtransport levelの認可を扱います。stdio transportでは同じ認可フローをそのまま使うのではなく、環境変数など別の認証情報の扱いになります。
根拠
2025-11-25版のAuthorization仕様は、HTTP-based transportでの認可を定義し、Authorization自体はMCP実装においてoptionalとしています。対応する場合、HTTP transportは仕様に従うべきであり、stdio transportでは環境からcredentialsを取得する設計が示されています。
2. モデル実行の許可
MCPサーバーへの接続を許可したことは、LLM生成を許可したことと同じではありません。
Samplingでは、serverはmodelPreferencesやmaxTokensなどの要求を出せますが、最終的なモデルアクセスと選択はclient側の制御下にあります。したがって、client側では「このserverからのSamplingを許可するか」「どのモデルを使うか」「コスト上限をどうするか」を別に承認させる必要があります。
評価基準
モデル実行の許可では、次を分けます。
- モデル名や品質水準
- 最大token
- 1回あたりのコスト上限
- 1ユーザー、1server、1workspaceあたりの回数上限
- 自動承認してよい操作と、毎回確認する操作
3. プロンプトとコンテキスト公開の許可
SamplingでLLMに送るpromptには、serverが生成した指示、ユーザー入力、Resources由来の情報、別server由来の情報が混ざる可能性があります。ここを「LLMに送る情報」として一括許可すると、過剰共有が起きます。
includeContext を使えばserver由来のcontextを含められますが、SEP-1577では includeContext の "thisServer" と "allServers" がsoft-deprecatedとして扱われ、capabilityで囲う方向が示されています。新規実装では、includeContext に広く依存せず、送るcontextを明示的に組み立てるほうがレビューしやすいです。
注意点
allServers のような広いcontext共有は、とくに危険です。別のMCP serverから得た情報や、ユーザーが意図していないworkspace情報がLLM promptへ混ざると、情報漏えいとprompt injectionの両方が起きやすくなります。
4. ツール実行の許可
tools付きSamplingでは、LLMがtool useを返し、serverが実際にtoolを実行し、その結果を再びSamplingに戻す流れになります。これは、通常のMCP Tool実行許可と同等以上に慎重に扱う必要があります。
なぜなら、通常のTool実行ではhostやclientがtool呼び出しを直接見られる設計が多いのに対し、tools付きSamplingではserver内のagentic loopとしてtool実行が続く可能性があるためです。
確認項目
tools付きSamplingを使うなら、最低限次を決めます。
- toolはread-onlyかwriteか
- 外部APIを呼ぶか
- 取り消し可能か
- 同じtoolを何回まで呼べるか
- tool resultが欠けたときにどう止めるか
- tool descriptionを信頼できるserverだけに限定しているか
- 最終回答を強制する条件を持っているか
5. 監査と課金の許可
Samplingは、LLM呼び出しとtool実行が絡むため、監査ログが分散しやすい機能です。serverはSamplingを要求し、clientはLLMを呼び、場合によってserverがtool loopを回します。このままでは、あとから「誰が何を許可したか」を追いにくくなります。
ログには、少なくとも次を残します。
- userまたはworkspace
- server名とserver version
- Sampling要求の目的
- promptの要約またはhash
- model、maxTokens、stopReason
- tool useとtool resultの対応
- 承認、拒否、キャンセル
- tokenとコストの概算
秘密情報やprompt全文をログへ残すかは慎重に決めます。監査性のために全文保存すると、今度はログが機密情報の集積場所になります。prompt全文、hash、redacted summaryのどれを採用するかは、データ分類と監査要件で分けます。
Samplingを使うなら実装前に決めること
先に決めるほど、Samplingを小さく試して止められる設計になります。
Samplingを採用するなら、コードを書く前に決めることがあります。ここを決めずにSDKのサンプルから実装を始めると、あとで承認UI、fallback、監査ログを後付けすることになります。
capability negotiationとfallback
まず、clientがどのcapabilityを持つか確認します。
samplingsampling.toolssampling.context
clientが対応していない場合は、Sampling requestを投げる前に通常フローへ切り替えます。失敗してから握りつぶすのではなく、capability negotiationの時点で分岐するほうが、ユーザーにも運用にも親切です。
条件
fallbackは「低機能版」ではなく「安全な通常フロー」として設計します。たとえば、要約ができない場合は検索結果をそのまま返す、write操作の提案ができない場合は差分案だけ返す、LLM判断が必要なら人間に確認を返す、といった形です。
承認UIと拒否時の扱い
Sampling仕様は、human-in-the-loopを強く意識した設計です。実装では、ユーザーが次を確認できるようにします。
- どのserverがSamplingを要求しているか
- 何をLLMに送るか
- どのcontextを含めるか
- どのモデルを使うか
- 生成結果をserverへ返してよいか
- tools付きの場合、どのtool実行が起きるか
拒否は異常ではありません。ユーザーが拒否したら、監視上の障害ではなく、正常な権限制御として扱います。
注意点
「ユーザーが毎回承認するのは面倒だから自動承認する」という設計は、trusted server、read-only、低コスト、機密情報なし、回数上限ありの条件がそろう場合に限定します。write toolや外部API呼び出しを含むSamplingでは、自動承認を初期値にしないほうが安全です。
tool loopの上限
tools付きSamplingを使う場合は、server側のtool loopに上限を置きます。
- 最大反復回数
- 最大tool call数
- 1回のtool resultのサイズ
- mixed contentの扱い
- missing tool result時の終了条件
- 最終応答を要求するタイミング
SEP-1577ではtool useとtool resultを使ったloopが想定されますが、loopが長くなればなるほど、コスト、latency、失敗点、監査対象が増えます。実装者は「LLMが必要と言ったから続ける」のではなく、業務上許可した範囲だけ続ける設計にします。
採用前にテストする観点
Samplingは動くだけでは不十分で、拒否・停止・説明まで含めてテストします。
Samplingは、動けば便利な機能です。しかし、動作確認を正常系だけで終えると、実務導入後に権限と互換性で詰まります。採用前には、protocol、security、operationsの3種類でテストします。
protocol-level test
protocol-levelでは、仕様上の分岐を試します。
| テスト | 確認すること |
|---|---|
clientが sampling 非対応 | request前にfallbackするか |
clientが sampling.tools 非対応 | tools付き要求を投げないか |
| ユーザーが拒否 | 正常な拒否として扱うか |
| tool resultが欠ける | loopを止められるか |
| stopReasonが想定外 | 安全側に倒せるか |
| maxTokens超過 | 再試行せず説明できるか |
確認項目
エラーコードやstopReasonの扱いは、SDKやclient実装で差が出る可能性があります。サーバー側では、特定clientだけで通る挙動に依存しないようにします。
security test
securityでは、Samplingがprompt injectionやtool misuseの経路にならないかを確認します。
- tool descriptionに過剰な権限説明が混ざっても安全か
- Resources由来の文章に「別のserverへ送れ」という指示が含まれても無視できるか
includeContextで不要な情報が混ざらないか- 外部API credentialsをpromptへ含めないか
- 生成結果をserverへ返す前に確認できるか
MCP本体は、アプリケーション側のセキュリティ原則を自動で強制してくれる仕組みではありません。host、client、server、それぞれが境界を実装する必要があります。
注意点
「trusted serverだから大丈夫」という判断は、短期PoCでは通っても、チーム導入では弱いです。serverが正しくても、serverが読む外部データやドキュメントにprompt injectionが含まれる可能性があります。
operations test
operationsでは、運用に耐えるかを見ます。
- latencyが許容範囲か
- tokenとコスト上限を超えないか
- キャンセルできるか
- retryで二重tool実行が起きないか
- 監査ログから承認者と実行内容を追えるか
- SDK更新や仕様更新時に停止できるか
Samplingは、モデル実行とtool実行が連鎖するため、通常のAPI呼び出しよりも運用メトリクスが増えます。最低限、Sampling request数、拒否数、失敗数、平均latency、token概算、tool call数は分けて見ます。
失敗点: Samplingで起きやすい事故
MCPサーバーへの接続認可を、LLM生成やprompt送信の許可として扱ってしまいます。
必要以上のcontextが混ざり、別server由来の情報まで説明しにくくなります。
反復上限、tool result、拒否時処理、最終回答の条件がないと制御しにくくなります。
誰が、何を、どのモデルで、どのtool結果とともに承認したかを後から追えなくなります。
事故の多くは、Samplingそのものよりも周辺の許可と記録を曖昧にしたところから起きます。
Samplingの失敗は、単に生成品質が低いだけではありません。権限、情報共有、コスト、監査の失敗として現れます。
Samplingを認可の代わりにしてしまう
MCP Authorizationは、MCP clientが制限されたMCP serverへアクセスするためのtransport-levelの認可を扱います。これは、SamplingでLLMを呼んでよい、promptを送ってよい、toolを実行してよい、という許可とは別です。
ここを混ぜると、「MCPサーバーへの接続を許可したので、LLM生成も許可済み」という誤解が起きます。接続認可とモデル実行許可は分けます。
includeContext を広く使いすぎる
includeContext は便利に見えますが、広く使うほど過剰共有のリスクが上がります。とくに "allServers" 相当の発想は、別のserverから得た情報まで混ざる可能性があり、監査と説明が難しくなります。
新規実装では、必要なcontextをserver側で明示的に構成し、client側でもユーザーに見せられる粒度にします。
tool loopが止まらない
tools付きSamplingでは、LLMがtoolを要求し、serverがtoolを実行し、結果を戻して再度Samplingする流れができます。最大反復回数やtool resultサイズの上限がないと、latencyとtokenが膨らみます。
また、write系toolが含まれると、再試行で二重実行が起きるリスクがあります。write操作は冪等性、dry-run、preview、人間承認を前提にします。
監査ログに必要な情報が残らない
Samplingはclientとserverに処理が分かれるため、ログも分かれます。server側には「Samplingを要求した」ログがあり、client側には「LLMを呼んだ」ログがあり、tool実行はまた別、という状態になりがちです。
あとから事故調査をするには、共通のcorrelation idが必要です。Sampling request、model call、tool call、承認UI、ユーザー操作を1つの流れとして追えるようにします。
実務で使うなら
- read-only補助機能
検索結果の要約、分類、エラー説明、差分コメント下書きなどから始めます。
- 承認とpreview
write操作に広げる前に、preview、dry-run、人間承認、監査ログを整えます。
- 運用ルール化
AGENTS.mdやrunbookに、許可する用途、禁止する用途、停止手順を書きます。
- 仕様更新を追う
SEPやSDK更新を確認し、feature flagで停止できる状態を保ちます。
元データをユーザーが確認できる補助機能から始めると、リスクを抑えやすくなります。
Samplingを実務に入れるなら、最初から大きなagentic loopを作らず、小さく始めます。おすすめは、read-onlyで、失敗しても業務が止まらない補助機能です。
read-onlyの補助機能から始める
最初の候補は、検索結果の要約、ドキュメント候補の分類、エラー文の説明、差分コメントの下書きなどです。どれも、生成結果が間違っていても、元データをユーザーが確認できます。
逆に、チケット更新、請求、ユーザー権限変更、外部投稿、データ削除のようなwrite操作は、Samplingの初期導入には向きません。write操作を扱うなら、通常Toolのpreview、dry-run、人間承認、監査ログを先に整えます。
AGENTS.mdや運用ルールに書く文言
チームでMCP Samplingを使うなら、リポジトリや運用runbookに次のようなルールを入れます。
MCP Samplingを使う機能は、client capabilityを確認し、非対応時のfallbackを必ず用意する。
Sampling要求では、LLMへ送るprompt/context、model preference、maxTokens、生成結果のserver返却をユーザーが確認できるようにする。
tools付きSamplingでは、read-only toolから始め、write toolはpreview、dry-run、人間承認、監査ログを必須にする。
SEP-2577の廃止状況を四半期ごとに確認し、中核機能はSamplingなしでも成立する設計にする。こうしたルールは、AIエージェント全体の権限設計ともつながります。GitHub連携のread-only開始やtool allowlistの考え方は、TypeScriptでGitHub read-only MCPサーバーを作る：Fine-grained PATとtool allowlistの最小構成でも使えます。
仕様更新を追う運用にする
Samplingを使うなら、MCP specification、SEP-2577、SEP-1577、TypeScript SDK、利用中clientのrelease notesを追う必要があります。仕様更新の影響を短時間で見る運用は、MCP仕様・SDK更新時の実務影響チェック: 認証、破壊的変更、クライアント互換性のようなチェックリスト化が向いています。
チームで毎回すべての仕様文書を読むのは現実的ではありません。変更があったら、影響範囲、互換性、移行期限、client対応、security noteだけを先に拾う形にします。
セキュリティ・コスト注意
trusted serverであっても、serverが処理する入力や外部応答まで信頼できるわけではありません。
Samplingのリスクは、APIキーをserverに置かないことで消えるわけではありません。むしろ、LLM実行の権限がclient側へ移ることで、別の確認項目が増えます。
セキュリティ注意
最も重要なのは、Samplingを「trusted serverから来た便利な依頼」として自動承認しすぎないことです。
serverが信頼できても、serverが処理する入力、Resources、外部API応答、ユーザーが貼ったテキストは信頼できません。prompt injectionが混ざれば、LLMは本来送るべきでないcontextを要求したり、tool useを誘導されたりします。
最初は、次の制限を初期値にします。
- Samplingはread-only用途だけ
- contextは最小限
- promptと生成結果はユーザー確認あり
- tools付きSamplingは無効、またはread-only toolだけ
- write toolは通常Toolのpreviewと人間承認に戻す
- auto-approvalはtrusted serverかつ低リスク操作だけ
コスト注意
Samplingでは、server側ではなくclient側のモデルアクセスを使うため、コストの見え方が変わります。server運営者から見ると無料に見えても、ユーザーやworkspaceのモデル利用枠を消費している可能性があります。
tools付きSamplingでは、1つのユーザー操作が複数回のLLM callに分解されます。tool loopが3回続けば、token消費、latency、失敗確率は単純な1回生成より増えます。
コスト制御では、次を設定します。
- Sampling requestごとのmaxTokens
- 1操作あたりの最大LLM call数
- 1workspaceあたりの日次上限
- tools付きSamplingの最大反復回数
- 自動承認できるモデルの範囲
- 高コストmodelへ切り替える条件
法人導入で見るべきこと
法人導入では、Samplingを許可する前に、データ分類と監査要件を確認します。機密コード、顧客情報、個人情報、契約情報を含むcontextをLLMに送る可能性があるなら、モデルプロバイダのデータ利用ポリシー、保持期間、リージョン、管理者ログを別途確認します。
この記事では特定プロバイダの料金やデータ利用条件は比較しません。Sampling設計では、clientがどのモデルを使うかを最終的に決めるため、組織の利用規約と管理ポリシーに依存する部分が大きいからです。
FAQ
即時削除ではありません。ただし新規の長期中核機能なら、代替経路と停止手順が必要です。
モデル、課金、ログをserver側で管理したい場合は向きます。責任をどこに置くかで選びます。
tool loopは作れますが、最初はread-only toolの限定loopから始めるほうが安全です。
MCP Authorizationはserverアクセスの認可であり、LLM生成やtool実行の許可とは別に扱います。
FAQでも、結論は権限と監査の責任をどこに置くかに戻ります。
SEP-2577がFinalなら、Samplingはもう使えませんか
いいえ。SEP-2577は廃止提案であり、即時削除を意味するものではありません。2025-11-25版の仕様にはSamplingが定義されています。ただし、Finalの廃止シグナルが出ているため、新規の長期中核機能として依存するなら、代替経路と停止手順を持つべきです。
server-side LLM APIを使えばSamplingは不要ですか
必ずしもそうではありません。server-side LLM APIは、server運営者がモデル、課金、ログ、データ利用条件を管理したい場合に向きます。Samplingは、client側のモデルアクセスとユーザー承認を使いたい場合に向きます。どちらがよいかは、権限と監査の責任をどこに置くかで決まります。
tools付きSamplingはAgent実装に向いていますか
仕組みとしてはagentic loopを作れます。ただし、tool loop、反復上限、tool result、拒否時処理、監査ログまでserver側が設計する必要があります。最初からwrite toolを含むagentを作るより、read-only toolの限定loopから始めるほうが安全です。
MCP Authorizationを入れればSamplingも安全になりますか
なりません。MCP Authorizationは主にMCP serverへのアクセス認可を扱います。SamplingでLLMを呼ぶ許可、prompt/contextを送る許可、tools付きSamplingでtoolを実行する許可は、別の層として設計します。
次に読むなら
MCPやAI coding agentの仕様更新を追う場合は、ニュースレターでも更新情報を受け取れます。チームでMCP設計レビューやAIコーディング権限設計を見直したい場合は、お問い合わせから相談できます。
参照した主な情報源
- Model Context Protocol: Sampling specification 2025-11-25
https://modelcontextprotocol.io/specification/2025-11-25/client/sampling
- Model Context Protocol: Specification 2025-11-25
https://modelcontextprotocol.io/specification/2025-11-25
- Model Context Protocol: Understanding MCP clients
https://modelcontextprotocol.io/docs/learn/client-concepts
- Model Context Protocol: Architecture overview
https://modelcontextprotocol.io/docs/learn/architecture
- Model Context Protocol: Authorization specification 2025-11-25
https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- SEP-1577: Sampling With Tools
https://modelcontextprotocol.io/seps/1577–sampling-with-tools
- SEP-2577: Deprecate Roots, Sampling, and Logging
https://modelcontextprotocol.io/seps/2577-deprecate-roots-sampling-and-logging
- Model Context Protocol TypeScript SDK
https://github.com/modelcontextprotocol/typescript-sdk
更新履歴
- 2026-06-10 08:00 JST
2025-11-25版MCP仕様、Sampling仕様、Authorization仕様、SEP-1577、SEP-2577、TypeScript SDK READMEを確認しました。
- 需要シグナル確認
指定Xアカウントの公開ページと検索を確認しましたが、直近72時間の確認可能な関連投稿は取得できませんでした。
- 利益相反
スポンサー、アフィリエイト、無償提供、検証環境提供はありません。
記事の技術的根拠には、確認できた一次情報と仕様文書を使っています。
- 2026-06-10 08:00 JST: 2025-11-25版MCP仕様、Sampling仕様、Authorization仕様、SEP-1577、SEP-2577、TypeScript SDK READMEを確認しました。
- 2026-06-10 08:00 JST: 需要シグナルとして指定Xアカウントの公開ページと検索を確認しましたが、直近72時間の確認可能な関連投稿は取得できませんでした。本文の技術的根拠には使用していません。
- スポンサー、アフィリエイト、無償提供、検証環境提供はありません。