MCP(Model Context Protocol)とは?AIアプリと外部ツールをつなぐ仕組みを役割別に整理

登場人物と情報の流れを一枚で見る(図解の文章版)

公式の構成図をもとに、役割が分かるよう独自に簡略化した図です。

ユーザー
  │ ①依頼
  ▼
┌─ ホスト(AIアプリ)────────────────────┐
│  モデル(LLM)                           │
│  MCPクライアントA ─専用接続─ サーバーA   │ ← 自分のPC上(stdio)
│  MCPクライアントB ─専用接続─ サーバーB   │ ← リモート(HTTP)
└──────────────────────────────────────┘

公式ドキュメントによると、ホストは接続するサーバーごとにクライアントを1つ作り、それぞれが専用の接続を持ちます(Architecture overview)。たとえばホストが2つのサーバーにつながっているなら、中にはクライアントが2つあります。

大事な点が一つあります。MCPが決めるのは「コンテキストをやり取りする方法」だけです。LLMをどう使うか、受け取った情報をどう扱うかは、同じページで「MCPが定めるものではない」と明記されています。つまり、どのツールを使うかを考えるのはモデルとホストの仕事で、MCPはそのための接続と形式を提供します。

ツールが呼ばれて結果が戻るまでの流れ

公式ドキュメントの例をもとに、人間の目線で並べ直します。

1. ユーザーが依頼する:「先月のエラーを調べて」のように、普通の文章でホストに頼みます。
2. クライアントがサーバーの能力を確認する:server/discoverというリクエストで、サーバーの対応バージョンや機能(ツール、リソースなど)を取得できます。このリクエストの送信は任意です。
3. ツールの一覧を取る:tools/listで、各ツールの名前、説明、入力の形(inputSchema)が返ります。ホストは複数サーバーのツールをまとめて、モデルが使える状態にします。
4. モデルがツールを選ぶ:一覧の説明を手がかりに、モデルが使うツールと引数を決めます。
5. ホストが呼び出す:該当するサーバーのクライアントがtools/callを送ります。
6. 結果が戻る:サーバーはcontent(テキストなど)を返し、ホストが会話の材料としてモデルに渡します。

この仕様バージョンでは、各リクエストが必要な情報(プロトコルのバージョンやクライアントの機能)を自分で持つ「ステートレス」な設計と説明されています。古い解説で別の手順が書かれていたら、どの仕様バージョンの話かを見比べてください。

サーバーが出すもの:ツール・リソース・プロンプト

サーバーが提供できる中心機能は3種類です(Architecture overview)。

• ツール、役割：AIが実行できる関数、例：ファイル操作、API呼び出し、DB検索
• リソース、役割：文脈になるデータ、例：ファイルの中身、DBのスキーマ
• プロンプト、役割：再利用できる指示テンプレート、例：システムプロンプト、few-shotの例

仕様ではツールがモデルの実行する機能、リソースはユーザーまたはモデルが使う文脈、プロンプトはユーザー向けのテンプレートという位置づけです。たとえばDB向けのサーバーなら、検索用のツール、スキーマのリソース、使い方例のプロンプトを一式で出せます。

つなぎ方の違い(トランスポート)

• stdio、動く場所：自分のPC上のプロセス、向く場面：ローカルのファイルなどを扱う
• Streamable HTTP、動く場所：リモートのサーバー、向く場面：クラウドのサービスに接続する

Streamable HTTPでは、認証にBearerトークンやAPIキーなどが使え、公式はOAuthの利用を推奨しています。

Claude Codeの場合、追加コマンドは次の形です(Claude Code MCPドキュメント)。

# リモート(HTTP)。名前とURLは説明用の例
claude mcp add --transport http example-service https://example.com/mcp

# ローカル(stdio)。「--」以降がサーバーを起動するコマンド
claude mcp add --transport stdio my-local-server -- npx -y some-mcp-server

同ドキュメントでは、HTTPが推奨でSSEは非推奨とされています。上のコマンドは説明用で、筆者が実行して確認したものではありません。実際に使うときは、サーバー提供元の手順に従ってください。

用語ミニ辞典

• MCP、一言で言うと：AIアプリと外部ツール・データをつなぐ共通ルール
• ホスト、一言で言うと：ユーザーが使うAIアプリ本体
• クライアント、一言で言うと：ホスト内の、サーバー1つ専用の接続係
• サーバー、一言で言うと：ツールやデータを提供するプログラム(場所は問わない)
• ツール、一言で言うと：AIが呼び出せる実行機能
• リソース、一言で言うと：AIに渡す文脈データ
• プロンプト、一言で言うと：再利用できる指示テンプレート
• tools/list / tools/call、一言で言うと：ツールの一覧取得 / 実行のリクエスト
• stdio、一言で言うと：同じPC内のプロセス間でやり取りする方式
• Streamable HTTP、一言で言うと：HTTPでリモートのサーバーとやり取りする方式
• Elicitation、一言で言うと：サーバーがユーザーに追加の入力や確認を求める仕組み
• JSON-RPC 2.0、一言で言うと：メッセージの書式。MCPの土台

サンプリング(サーバーがホストのモデルに生成を依頼する機能)は、仕様バージョン2026-07-28で非推奨とされています。古い解説に出てきても、新しく作る側は使わない前提で読めば足ります。

つなぐ前に人が確認すること

MCPで接続すると、AIがファイルやサービスを操作できるようになります。仕様は、ツールを任意コードの実行経路にあたるものとして扱い、ホストは呼び出し前にユーザーの同意を得るべきだとしています(MCP仕様)。ただしプロトコル自体はこれを強制できないため、確認画面などの実装はアプリ側の責任です。

リスクの代表例は、OWASPが説明する「ツールポイズニング」です。悪意あるサーバーのツール応答に隠れた命令が混ざり、モデルがそれを信頼して従ってしまう間接的なプロンプトインジェクションです(OWASP: MCP Tool Poisoning)。Claude Codeのドキュメントも、外部コンテンツを取得するサーバーはプロンプトインジェクションの危険があると警告しています。

接続前チェックリスト

• 提供元は公式か、自社の管理下か。
• 付与する権限は必要最小限か(読み取り専用で足りないか)。
• APIキーを共有設定のファイルに書いていないか。
• 削除や送信など取り消せない操作は、実行前に人の確認が入るか。
• 外部から取り込む文章(チケット、メッセージ)を、命令ではなくデータとして扱う運用か。

OWASPは対策として、承認済みサーバーに限定すること、高権限ツールの分離、重要操作の確認をLLMの文脈の外で取ることなどを挙げています。

依頼文の例(説明用)

新しいサーバーを入れる前に、AIに叩き台を作らせる依頼文です。サーバー名や機能は仮の例なので、自分の環境に置き換えてください。

次のMCPサーバーを社内で試したいです。
・サーバー名:example-tracker(説明用の仮名)
・提供機能:チケットの検索、コメント追加、チケット削除
・接続方式:Streamable HTTP

次の3点を表にしてください。
1. 3つのツールのうち、取り消せない操作はどれか
2. 最初に許可する範囲(読み取りだけで始める案)
3. 人が毎回確認すべき操作と、その理由
不明な点は推測せず「要確認」と書いてください。

AIの回答は叩き台です。最終的な権限設計は、実際のサーバー説明書と自社のルールを見て人が決めてください。

まとめ:迷ったらこの三点

• MCPは接続のルールで、何をするかを決めるのはホストとモデルです。
• ホスト1に対してクライアントはサーバーの数だけあり、サーバーはツール・リソース・プロンプトを出します。
• 便利さと引き換えに、ツールの応答も「信用しきれない入力」として扱い、重要な操作は人が確認する形にします。