MCP の tools 以外の3つの能力を使い分ける：resources・prompts・sampling の設計

prompts：定型ワークフローをサーバーに蓄積する

prompt は、再利用可能なメッセージのテンプレートをサーバー側に登録する仕組みです。引数を受け取り、組み立て済みのメッセージ列を返します。クライアントでは多くの場合スラッシュコマンドのように一覧表示され、ユーザーが選んで起動できます。

先ほどの review_metadata tool が本来やりたかったのは、これです。tool から prompt へ移すと、レビュー手順そのものがサーバーの資産になり、呼び出し側でプロンプトを書き直す必要がなくなります。

server.prompt(
  "review_for_store",
  { id: z.string(), locale: z.string().default("ja") },
  async ({ id, locale }) => {
    const meta = await db.meta(id);
    return {
      messages: [
        {
          role: "user",
          content: {
            type: "text",
            text: [
              `次の壁紙メタデータを ${locale} の App Store / Google Play 向けにレビューしてください。`,
              "観点: タイトルの訴求力、説明文の長さ制限、禁止表現の有無、カテゴリの妥当性。",
              "改善案は箇条書きではなく、修正後の文面そのものを提示してください。",
              "",
              JSON.stringify(meta, null, 2),
            ].join("\n"),
          },
        },
      ],
    };
  }
);

prompt にしておく利点は、手順を一度きちんと書けば、6本のアプリすべてで同じ品質のレビューが回せることです。私の場合、ストア審査でリジェクトされやすい表現（誇大な「最高」「No.1」など）のチェック観点をこの prompt に集約しました。以前は tool 経由で毎回プロンプトを手書きしていたため、アプリごとに観点がぶれていましたが、prompt に固定したことでぶれが消えました。

prompt と tool の違いを一言でいうと、prompt は「ユーザーが起点になる定型の依頼」、tool は「モデルが必要に応じて呼ぶ操作」です。レビュー・要約・命名規則のチェックのように、人間が「これをやって」と起動する種類の作業は prompt が向いています。

sampling：サーバーからクライアントの推論を借りる

sampling は、3つのなかで最も誤解されやすい能力です。これはサーバーが「クライアント側の LLM に推論をお願いする」ための仕組みです。つまりサーバーが自前で API キーを持って Claude を呼ぶのではなく、sampling/createMessage というリクエストをクライアントに送り、クライアントが（ユーザーの承認を経て）手元のモデルで生成し、結果をサーバーに返します。

これが効くのは、サーバー処理の途中で軽い自然言語生成を挟みたい場面です。私のケースでは、新しい壁紙を取り込んだときにファイル名や色情報から人間向けのキャプション案を作りたい、という要件がありました。サーバーが課金主体にならずにこれを実現できるのが sampling の価値です。

server.tool(
  "ingest_wallpaper",
  { id: z.string(), filename: z.string() },
  async ({ id, filename }) => {
    const palette = await analyzePalette(id); // 既存の色解析
 
    // クライアントの LLM にキャプション案を生成してもらう
    const result = await server.server.createMessage({
      messages: [{
        role: "user",
        content: {
          type: "text",
          text: `ファイル名「${filename}」と主要色 ${palette.join(", ")} から、` +
                `壁紙アプリ向けの日本語キャプションを3案、各20文字以内で出してください。`,
        },
      }],
      maxTokens: 200,
    });
 
    const caption = result.content.type === "text" ? result.content.text : "";
    await db.saveCaptionDraft(id, caption);
    return { content: [{ type: "text", text: `キャプション案を保存しました:\n${caption}` }] };
  }
);

ここで重要なのは、server.server.createMessage() の呼び出しが成功するかどうかは、つないでいるクライアントが sampling 機能に対応しているかに完全に依存する、という点です。対応していないクライアントに送るとエラーになります。次の節で、この現実的な制約への対処を扱います。

3つをどう使い分けるか

ここまでを判断基準としてまとめます。私が設計時に自問する順番は決まっています。

第一に、それは状態を変える操作か、それとも読み取りか。読み取りなら resource、状態を変えるなら tool を検討します。第二に、それは人間が起点になる定型の依頼か。レビューや要約のように「これをやって」と起動する作業なら prompt にします。第三に、サーバー処理の途中で自然言語生成を挟みたいか。挟みたいなら sampling を検討し、ただしクライアント対応を必ず確認します。

具体的な対応づけを書き出すと、次のようになります。

1. 壁紙一覧・個別メタデータの取得 → resource（副作用なし、参照素材）
2. 分類の再実行・サムネイル再生成・公開フラグの更新 → tool（状態を変える）
3. ストア向けメタデータレビュー・命名規則チェック → prompt（人間起点の定型依頼）
4. 取り込み時のキャプション案生成 → tool の内部で sampling を併用

この整理を当てはめた結果、14個あった tool は「再分類」「サムネイル再生成」「公開フラグ更新」「取り込み」「タグ一括置換」の5個まで減りました。読み取り系の8個は resource へ、レビュー系は prompt へ移り、サーバーの責務がはっきり分かれました。Claude の tool 取り違えはこのリファクタ以降ほぼゼロになっています。

壁紙アプリのアセット管理サーバーで実際にどう組み直したか

実際の移行は一度に全部やろうとすると壊すので、私は段階を踏みました。最初に resource を追加し、tool 版の読み取り系と並走させます。Claude が resource を正しく読めることを会話で確認してから、tool 版を削除します。この並走期間を置くことで、resource にしたら Claude が参照しなくなった、という落とし穴に早く気づけます。

次に prompt への移行です。レビュー系の tool を prompt に書き換えるとき、引数のデフォルト値を丁寧に設計しました。locale を ja 既定にしておくと、英語ストア向けのときだけ en を渡せばよく、日常作業の摩擦が減ります。個人開発では、こうした小さな摩擦の削減が積み重なって効きます。

sampling の併用はいちばん慎重に進めました。キャプション生成はあくまで「案」であり、最終決定は私が行う前提にしています。AdMob の収益に直結するストア掲載文を完全自動で書き換えるような設計は、品質のばらつきが怖くて採用しませんでした。生成はドラフトとして保存し、私が確認して採用する運用です。ここは個人開発のリスク許容度に合わせた判断で、正解はひとつではありません。

色解析やサムネイル生成のような重い処理は、これまで通りサーバー側のネイティブ実装に残しました。sampling はあくまで自然言語の軽い生成に限定し、画像処理を LLM に投げるような使い方はしていません。primitive を増やすこと自体が目的化すると複雑性が膨らむので、「この処理に本当に推論が要るか」を毎回問い直すようにしています。

クライアント対応状況という現実的な制約

設計が美しくても、つなぐクライアントが対応していなければ動きません。これは sampling で特に顕在化します。tool と resource はほとんどのクライアントが対応していますが、prompt と sampling は対応状況にばらつきがあります。本番でいきなり sampling に依存すると、クライアントを変えた途端に取り込み機能が丸ごと落ちる、という事故が起こり得ます。

私が採用しているのは、sampling が使えない場合に静かに縮退するフォールバックです。createMessage の呼び出しを try/catch で囲み、失敗したらキャプション生成だけスキップして取り込み自体は完了させます。

async function tryGenerateCaption(filename: string, palette: string[]): Promise<string | null> {
  try {
    const result = await server.server.createMessage({
      messages: [{
        role: "user",
        content: { type: "text", text: `「${filename}」と色 ${palette.join(", ")} からキャプションを1案、20文字以内で。` },
      }],
      maxTokens: 100,
    });
    return result.content.type === "text" ? result.content.text : null;
  } catch {
    // sampling 非対応クライアント、またはユーザーが拒否した場合
    return null; // 取り込み本体は止めない
  }
}

この設計にしてから、Claude Desktop でも Claude Code でも、対応の差を意識せずに同じサーバーをつなげるようになりました。「使える環境では便利機能が効き、使えない環境でも壊れない」という縮退の発想は、個人開発で複数の環境を行き来する人ほど効いてくると感じています。

もうひとつの現実的な注意点は、sampling はユーザー承認を挟む設計になっていることです。クライアントによっては毎回確認ダイアログが出るため、バッチ的に大量の壁紙を一度に取り込むワークフローには向きません。私は取り込みを1枚ずつ手で確認する運用にしているので問題になりませんでしたが、無人での一括処理を狙うなら、sampling ではなくサーバー側の独立した API 呼び出しを選ぶべき場面もあります。ここでもやはり「自動化の範囲をどこまで広げるか」という運用判断が先に来ます。

次に試すなら、手元の MCP サーバーの tool 一覧を一度書き出し、それぞれが「読み取りか・操作か・定型依頼か・推論か」のどれに当たるかを分類してみてください。読み取り系がいくつ tool に紛れているかが見えると、最初に動かすべきリファクタがはっきりします。同じように tool が増えすぎて見通しが悪くなっている方の参考になれば嬉しいです。