MCPのTools・Resources・Promptsの違い｜何をどのprimitiveで公開するか

MCPのTools・Resources・Promptsは、どれもAIへ機能を提供しますが、役割と選び方が異なります。処理を実行するならTool、読み取る情報ならResource、利用者が始める再利用手順ならPromptが基本です。

同じ「顧客情報を扱う」機能でも、顧客一覧を読む処理と、顧客を更新する処理ではprimitiveを分けます。副作用、選択主体、入力、出力、権限を基準に判断します。

この記事では、3primitiveの違い、曖昧なケース、10ユースケース分類表、設計チェックリストを解説します。

情報確認日：2026年7月17日（日本時間）

結論：動詞・名詞・手順で分ける

primitive	考え方	主な制御	例
Tools	動詞：実行する	model-controlled	issue作成、検索、計算
Resources	名詞：読み取る	application-controlled	README、schema、文書
Prompts	手順：始める	user-controlled	review、要約、調査template

これはMCP公式ドキュメントの基本分類です。HostのUIや実装で選択方法は変わりますが、Server設計時に「誰が、いつ、何を選ぶか」を考える出発点になります。

Tools：処理と副作用を公開する

Toolは名前、説明、入力schemaを持つ実行可能な処理です。モデルが利用候補から選ぶため、説明とschemaは曖昧にせず、コード側で引数を検証します。

検索、計算、変換
ファイル・issue・下書きの作成
データ更新、通知、外部API呼び出し

「何でも実行するshell」のような広いToolより、search_docs、create_issue_draftのように目的と権限を小さく分けます。削除、送信、公開などはHostで承認を求めます。

Resources：URIで参照情報を公開する

ResourceはURIで識別できる読み取り用のデータです。text、JSON、画像などのMIME typeと内容を返し、アプリや利用者がモデルのcontextへ追加できます。

file:///project/README.md
schema://database/orders
docs://handbook/expenses
repo://current/diff

URIを知っているだけで読める設計にせず、利用者、tenant、project、文書ごとの権限を検査します。大きなResourceは一覧と個別読み取りを分け、必要な範囲だけ返します。

Prompts：利用者が選ぶ手順を公開する

Promptは、引数を受け取り、再利用可能なmessage templateを返します。「PRをレビューする」「障害報告を整理する」など、利用者がメニューやcommandから開始する定型作業に向きます。

Prompt: review-pull-request
Arguments:
- focus: security | correctness | performance
- severity: blocker | high | all

Result:
- roleと指示
- 対象diffを確認する手順
- 出力形式

Promptは処理そのものを実行しません。Promptから始まった会話でResourceを読み、モデルがToolの利用を提案する組み合わせができます。

10ユースケースの分類表

用途	primitive	理由	注意
1．READMEを読む	Resource	既存情報の読み取り	project範囲
2．DB schemaを見る	Resource	構造化された参照情報	機密列を除外
3．issueを作る	Tool	外部状態を変更	下書きと作成を分離
4．注文を検索する	Tool	queryを実行し結果を返す	tenantと件数制限
5．現在のdiffを取得	Resource	読み取り時点のcontext	秘密fileを除外
6．PRレビューを開始	Prompt	利用者が選ぶ定型手順	対象Resourceを明示
7．価格を計算する	Tool	入力から決定的処理	通貨・丸めを固定
8．社内規程を提示	Resource	正本を参照	版と権限
9．障害報告を作成	Prompt＋Tool	template後に下書き保存	外部送信は承認
10．顧客調査workflow	Prompt＋Resource＋Tool	手順、資料、検索を組合せ	個人情報と監査

曖昧なケースの判断方法

検索結果はResourceですか、Toolですか？

固定された既知URIの文書を読むならResourceが自然です。利用者のquery、filter、pageを受け、毎回検索処理を実行するならToolが自然です。検索結果の各文書をResource URIで返す組み合わせもできます。

「現在時刻」はどちらですか？

引数なしの取得でも、呼び出すたびに計算する機能としてToolにできます。現在状態のsnapshotをResourceとして表す設計も可能です。更新頻度、購読、選択主体で決めます。

テンプレートから実行まで一気にできますか？

Promptはmessageを用意し、Toolは処理を実行します。実行まで必要なら分けて公開し、Hostの承認を経てToolを呼びます。

設計の判断フロー

外部状態を変更するか → Tool
引数付きで検索・計算するか → Tool候補
URIで識別する既存情報か → Resource
利用者が明示的に開始する定型手順か → Prompt
複数の役割があるか → primitiveを組み合わせる

Tool設計チェックリスト

名前が具体的な動詞になっている
説明に利用条件と副作用がある
入力schemaが型・必須・許可値を制限する
利用者・tenant・対象の認可をコードで確認する
timeout、rate limit、idempotencyがある
高影響操作を承認なしで実行しない

Resource・Prompt設計チェックリスト

Resource URIが安定し、MIME typeが正しい
一覧と読み取りの両方で権限を確認する
大きすぎる内容を無制限に返さない
Prompt名と引数が利用者に理解できる
Prompt内で外部データを命令として扱わない
更新、廃止、versionの方針がある

MCP全体のHost・Client・Server構成はFlutter向けMCP Serverの例、モデルがToolを選ぶ一般的な仕組みはTool Callingとはも参考になります。

まとめ

MCPでは、処理を実行するならTool、URIで読む情報ならResource、利用者が開始する定型手順ならPromptが基本です。誰が選ぶか、副作用があるか、入力と出力をどう制御するかで判断します。

複雑な業務は、Promptで開始し、Resourceで根拠を読み、Toolで処理するように分けると、権限と承認を設計しやすくなります。