MCP コンセプト : サンプリング

サンプリングはサーバがクライアント経由で LLM の生成結果をリクエストできるようにする強力な MCP 機能で、セキュリティとプライバシーを維持しながら、洗練されたエージェント型動作を可能にします。

Model Context Protocol (MCP) : コンセプト : サンプリング

作成 : クラスキャット・セールスインフォメーション
作成日時 : 05/29/2025

* 本記事は github modelcontextprotocol の以下のページを独自に翻訳した上でまとめ直し、補足説明を加えています :

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

クラスキャット 人工知能 研究開発支援サービス ⭐️ リニューアルしました 😉

クラスキャット は人工知能に関する各種サービスを提供しています。お気軽にご相談ください :

  • 人工知能導入個別相談会(無償)実施中! [詳細]

  • 人工知能研究開発支援 [詳細]
    1. 自社特有情報を含むチャットボット構築支援
    2. 画像認識 (医療系含む) / 画像生成

  • PoC(概念実証)を失敗させないための支援 [詳細]

お問合せ : 下記までお願いします。

  • クラスキャット セールス・インフォメーション
  • sales-info@classcat.com
  • ClassCatJP

 

 

Model Context Protocol (MCP) : コンセプト : サンプリング

サーバが LLM からの生成結果をリクエストできるようにします

サンプリングはサーバがクライアント経由で LLM の生成結果をリクエストできるようにする強力な MCP 機能で、セキュリティとプライバシーを維持しながら、洗練されたエージェント型動作を可能にします。

Note : This feature of MCP is not yet supported in the Claude Desktop client.

 

How sampling works

サンプリング・フローは以下のステップに従います :

  1. サーバは sampling/createMessage リクエストをクライアントに送信します。

  2. クライアントはリクエストをレビューしてそれを変更することができます。

  3. クライアントは LLM からサンプリングします。

  4. クライアントは生成結果 (completion) をレビューします。

  5. クライアントは結果をサーバに返します。

  6. このユーザ参加型デザインは、LLM が見て生成するものをユーザが制御を維持することを確実にします。

 

メッセージ形式

サンプリング・リクエストは標準メッセージ形式を使用します :

{
  messages: [
    {
      role: "user" | "assistant",
      content: {
        type: "text" | "image",

        // For text:
        text?: string,

        // For images:
        data?: string,             // base64 encoded
        mimeType?: string
      }
    }
  ],
  modelPreferences?: {
    hints?: [{
      name?: string                // Suggested model name/family
    }],
    costPriority?: number,         // 0-1, importance of minimizing cost
    speedPriority?: number,        // 0-1, importance of low latency
    intelligencePriority?: number  // 0-1, importance of capabilities
  },
  systemPrompt?: string,
  includeContext?: "none" | "thisServer" | "allServers",
  temperature?: number,
  maxTokens: number,
  stopSequences?: string[],
  metadata?: Record
}

 

リクエスト・パラメータ

メッセージ

メッセージ配列は LLM に送信する会話履歴を含みます。各メッセージは以下を持ちます :

  • role : “user” または “assistant” のいずれか

  • content : メッセージコンテンツ、それは以下のいずれかです :
    • text フィールドを含むテキスト・コンテンツ
    • data (base64) と mimeType フィールドを含む画像コンテンツ

 

モデル優先設定

modelPreferences オブジェクトはサーバがモデル選択の優先設定を指定することを可能にします :

  • hints: クライアントが適切なモデルを選択するために使用できるモデル名の候補の配列 :
    • name: モデル名の全体か一部に一致する文字列 (e.g. “claude-3”, “sonnet”)
    • クライアントは hints を様々なプロバイダーの等価なモデルにマップ可能です。
    • 複数の hints は優先順位で評価されます。

  • 優先度の値 (0-1 に正規化) :
    • costPriority: コスト最小化の重要性
    • speedPriority: 低レイテンシー応答の重要性
    • intelligencePriority: 高度なモデル機能の重要性

クライアントは、これらの優先設定と利用可能なモデルに基づいて最終的なモデル選択を行います。

 

システム・プロンプト

オプションの systemPrompt フィールドはサーバが特定のシステムプロンプトを要求することを可能にします。クライアントはこれを変更したり無視して構いません。

 

コンテキストの包含 (inclusion)

includeContext パラメータは含むべき MCP コンテキストを指定します :

  • “none”: 追加コンテキストなし
  • “thisServer”: リクエストしているサーバからのコンテキストを含む
  • “allServers”: すべての接続中の MCP サーバからのコンテキストを含む

クライアントはどのコンテキストが実際に含まれるか制御します。

 

サンプリング・パラメータ

LLM サンプリングを以下を使用して微調整します :

  • temperature: ランダムネスの制御 (0.0 to 1.0)
  • maxTokens: 生成する最大トークン数
  • stopSequences: 生成を停止するシークエンスの配列
  • metadata: 追加のプロバイダー固有パラメータ

 

レスポンス形式

クライアントは生成結果 (completion result) を返します :

{
  model: string,  // Name of the model used
  stopReason?: "endTurn" | "stopSequence" | "maxTokens" | string,
  role: "user" | "assistant",
  content: {
    type: "text" | "image",
    text?: string,
    data?: string,
    mimeType?: string
  }
}

 

リクエスト例

クライアントからのサンプリングをリクエストする例が以下です :

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "What files are in the current directory?"
        }
      }
    ],
    "systemPrompt": "You are a helpful file system assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

 

ベスト・プラクティス

サンプリングを実装する場合 :

  1. 常に明確な、上手く構造化されたプロンプトを提供する

  2. テキストと画像コンテンツの両方を適切に処理する

  3. 妥当なトークン制限を設定する

  4. includeContext を通して関連コンテキストを含める

  5. レスポンスを使用する前に検証する

  6. エラーを適切に処理する

  7. サンプリング・リクエストのレート制限を考慮する

  8. 想定されるサンプリング動作を文書化する

  9. 様々なモデルパラメータを使用してテストする

  10. サンプリング・コストを監視する

 

人間介在型の制御

サンプリングは人間により監視 (oversight) を念頭において設計されています :

 

プロンプトについて

  • クライアントはユーザに提案されたプロンプトを示す必要があります

  • ユーザはプロンプトを変更または拒否できる必要があります

  • システムプロンプトはフィルタリングまたは変更できます

  • コンテキスト包含はクライアントにより制御されます

 

生成補完結果について

  • クライアントはユーザに生成結果 (completion) を示す必要があります

  • ユーザは生成結果を変更または拒否できる必要があります

  • クライアントは生成結果をフィルタリングまたは変更できます

  • ユーザはどのモデルを使用するか制御できます

 

以上