MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ共通規格¶

2026-10-28 更新約16分で読めます

最終確認: 2026-10-27（仕様は 2026-07-28 版）

30秒で復習¶

MCP（エムシーピー）＝AIアプリと、外部のツールやデータをつなぐための共通ルール（オープンな規格）。 2024年11月にAnthropicが公開し、2025年12月からはLinux Foundation傘下の Agentic AI Foundation（AAIF） で運営されている。
覚え方：「AIのためのUSB-C」。 一度MCPに対応した部品は、Claude・ChatGPT・Copilot・VS Codeなど、どのAIアプリからでも同じように使える。
登場人物は3つ：ホスト（Claudeなど、AIが動くアプリ）・クライアント（ホストの中の接続係）・サーバー（GitHubやGmailなどを、MCPで使えるようにする部品）。
サーバーがAIに渡すもの：ツール（操作する）・リソース（読む資料）・プロンプト（決まった指示のひな形）。
AIは「使えるツールの一覧」を見て、自分でどれを使うか選ぶ。ここが普通のAPI連携との大きな違い。
やり取りは JSON-RPC 2.0 のJSON。外側の項目（method・params・result など）は仕様で決まっていて、ツールの引数の中身はサーバーごとに決める（tools/list の inputSchema で公開）。
MCPサーバーは「AIに渡す合鍵」。権限は最小に、信頼できるサーバーだけを使い、書き込みや送信は人が承認する。

こんな場面で出会う¶

Claude や VS Code の設定で「MCP サーバーを追加」という項目を見かける
AI に「GitHub の Issue を見て」「社内のファイルを探して」と頼むと、実際に読みに行ってくれる

用語の正式名称と読み方¶

用語	意味	ひとことで
MCP	Model Context Protocol	AIと外部をつなぐ共通ルール
ホスト（Host）	AIが動くアプリ。Claude、ChatGPT、VS Code、Cursorなど	AIの本体側
クライアント（Client）	ホストの中で、1つのサーバーとの接続を受け持つ部分	接続係
サーバー（Server）	外部のサービスやデータを、MCPの形でAIに見せるプログラム	変換アダプター
ツール（Tools）	AIが呼び出せる操作。「リポジトリを作る」「メールを検索する」など	手足
リソース（Resources）	AIが読める資料。ファイル、DBの中身、ドキュメントなど	参考資料
プロンプト（Prompts）	サーバーが用意した指示のひな形	定型文
stdio	同じPCの中で動くサーバーと、標準入出力でやり取りする方式	ローカル接続
Streamable HTTP	クラウド上のサーバーと、HTTPでやり取りする方式	リモート接続
JSON-RPC	やり取りするメッセージの書式	共通の書類フォーマット
JSON Schema	JSONの形（項目名・型・必須かどうか）を書くための書き方	申請書の記入例

質問：MCPとは？¶

答え： AIアプリが外部のツールやデータを使うための共通の差し込み口。これまでは「AIアプリ × 外部サービス」の組み合わせごとに、専用の連携を作る必要があった。MCPという共通ルールに合わせておけば、サーバーを1つ作るだけで、MCPに対応したどのAIアプリからでも使える。

イメージ（たとえ話）¶

MCPがない世界＝機種ごとに違う充電ケーブル。スマホを替えるたびにケーブルも買い直す。
MCPがある世界＝USB-C。差し込み口の形が決まっているので、どのメーカーの機器でも同じケーブルが使える。
MCPサーバー＝変換アダプター。GitHubやGmailなど、それぞれ形の違うサービスを「USB-Cの形」に変えてAIにつなぐ。

質問：どんな仕組みで動く？¶

答え： ホスト（AIアプリ）の中に、つなぐサーバーの数だけクライアントがいて、それぞれが1つのサーバーとやり取りする。サーバーは、同じPCの中で動くもの（ローカル）と、クラウドで動くもの（リモート）がある。

サーバーがAIに渡すもの¶

種類	誰が使うか決める	例
ツール	AI（モデル）が、必要なときに自分で選ぶ	GitHubでリポジトリを作る、カレンダーに予定を入れる、DBを検索する
リソース	アプリや利用者が、読ませる資料を選ぶ	ファイルの中身、DBの表の構成、社内ドキュメント
プロンプト	利用者が、メニューやコマンドから選ぶ	「このPRをレビューして」のような定型の指示

実際の流れ（このサイトを作ったときの例）¶

このサイトを作るとき、Claudeに「新しいリポジトリを作って」と頼んだ。裏ではMCPがこう動いていた。

Claude（ホスト）は、GitHubのMCPサーバーから使えるツールの一覧（create_repository など）を受け取っておく
依頼の文章を読んで、AIがどのツールを、どんな引数で使うかを決める
ツールを実行する前に、必要なら利用者に承認を求める
MCPサーバーがGitHubのAPIを呼び出し、結果をAIに返す

このときは「403（権限がありません）」が返ってきて、リポジトリは作れなかった。MCPサーバーは、渡された権限（トークン）の範囲でしか動けない。AIが勝手に権限を広げることはできない、というのが分かる例。

質問：普通のAPI連携やプラグインと何が違う？¶

観点	API連携	アプリ専用のプラグイン	MCP
つなぎ方	サービスごとに書き方がバラバラ	そのアプリ専用の作り方	共通ルールに合わせて1回作る
使える場所	作ったプログラムの中だけ	そのアプリの中だけ	MCPに対応したどのAIアプリでも
何をするか決めるのは	プログラムを書いた人	アプリ	AIが一覧を見て選ぶ（人が承認する）
例	自作スクリプトからGitHub APIを呼ぶ	特定のチャットアプリ専用の拡張機能	GitHubのMCPサーバーを、ClaudeでもVS Codeでも使う

MCPサーバーの中身は、結局は各サービスのAPIを呼び出していることが多い。MCPはAPIの代わりではなく、APIをAIが使いやすい形に包む仕組み。

質問：具体的にどんな入出力をする？¶

答え： やり取りはすべて JSON-RPC 2.0 という形のJSON。種類は3つだけ。

種類	中身	例
リクエスト	`method`（何をしたいか）＋ `params`（引数）＋ `id`（受付番号）	「ツールを実行して」
レスポンス	同じ `id` ＋ `result`（成功）か `error`（失敗）のどちらか	実行結果
通知	`id` なし。返事はいらない	「ツールの一覧が変わったよ」

id は、どの質問への答えかを対応させるための番号。

全体ではこう変換されている¶

AI（モデル）自身はJSON-RPCを見ていない。 ホストが間で翻訳している。MCPが決めているのは、ホストとサーバーの間の書式だけ。

① 使えるツールの一覧をもらう（`tools/list`）¶

入力（ホスト → サーバー）

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }

出力（サーバー → ホスト）

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "create_repository",
        "description": "Create a new GitHub repository in your account",
        "inputSchema": {
          "type": "object",
          "properties": {
            "name":    { "type": "string",  "description": "Repository name" },
            "private": { "type": "boolean", "description": "Whether the repository should be private" }
          },
          "required": ["name"]
        }
      }
    ]
  }
}

inputSchema で「引数は何で、どの型で、どれが必須か」を伝えている。AIはこの description と inputSchema を読んで、どのツールをどう使うか判断する。

② ツールを実行する（`tools/call`）¶

入力

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "create_repository",
    "arguments": { "name": "notes", "private": false }
  }
}

出力（成功したとき）

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "Created repository pikuxy/notes" }],
    "isError": false
  }
}

出力（このサイトを作ったときの失敗）

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "failed to create repository: 403 Resource not accessible by integration" }],
    "isError": true
  }
}

※ 成功時の text は説明用の例。失敗時の文章は、実際に返ってきたエラーを短くしたもの。

エラーは2種類あり、返し方が違う¶

種類	返し方	例
ツールは動いたが、処理が失敗した	`result` の中で `"isError": true`	権限不足（403）、ファイルがない
リクエスト自体がおかしい	`result` ではなく `error` で返す	存在しないツール名、引数の形が違う

{ "jsonrpc": "2.0", "id": 3, "error": { "code": -32602, "message": "Unknown tool: create_repo" } }

isError のほうはエラーの文章がそのままAIに渡るので、AIは「権限が足りないみたい」と理解して次の手を考えられる。

どうやって運ぶ？¶

方式	運び方
stdio（同じPCの中）	サーバーを子プロセスとして起動し、標準入出力にJSONを1行ずつ流す
Streamable HTTP（クラウド）	HTTPのPOSTの本文にJSONを入れる。2026-07-28 版からは、ヘッダーにも `Mcp-Method: tools/call` と `Mcp-Name: create_repository` を付ける（中身を開かなくても振り分けられるように）

質問：JSONの項目（パラメータ・属性）は決まっている？¶

答え： 二段構え。外側の「型」は仕様で決まっていて、ツールの引数の中身はサーバーごとに決める。

たとえ：役所の申請書。氏名・住所・押印の欄は決まっている（仕様）。でも、何の申請で何を書くかは申請の種類ごとに違う（サーバーが決める）。
サーバーは、自分が決めた中身を tools/list の inputSchema で公開する。だからAIは、知らないサーバーでも一覧を読めば使える。

仕様で決まっている：JSON-RPC の共通項目¶

項目	必須？	意味
`jsonrpc`	必須	いつも `"2.0"`
`id`	リクエスト・レスポンスで必須	文字列か数値。通知には付けない
`method`	リクエストで必須	`tools/call` など、決められた名前
`params`	任意	メソッドごとに中身が決まっている
`result` / `error`	どちらか一方だけ	成功なら `result`、失敗なら `error`（`code`・`message`・`data`）

仕様で決まっている：主なメソッド名¶

メソッド	すること
`tools/list` / `tools/call`	ツールの一覧をもらう／実行する
`resources/list` / `resources/read`	資料の一覧をもらう／読む
`prompts/list` / `prompts/get`	指示のひな形の一覧をもらう／取り出す
`server/discover`	サーバーの機能を問い合わせる（2026-07-28 版で追加。使わなくてもよい）

仕様で決まっている：ツール定義の属性（`tools/list` の中身）¶

属性	必須？	意味
`name`	必須	ツールの名前（例：`create_repository`）
`title`	任意	人に見せる表示名
`description`	任意（実際はほぼ必須）	何をするツールか。AIはこれを読んで使うか決める
`inputSchema`	必須	引数の形。JSON Schema で `"type": "object"` として書く
`outputSchema`	任意	決まった形のデータを返すときの、返り値の形
`annotations`	任意	性質のヒント。`readOnlyHint`（読むだけ）、`destructiveHint`（消したり上書きしたりする）、`idempotentHint`（何度やっても同じ結果）、`openWorldHint`（外の世界とやり取りする）

仕様で決まっている：実行と結果（`tools/call`）¶

場所	属性	必須？	意味
入力 `params`	`name`	必須	実行するツール名
入力 `params`	`arguments`	ツール次第	`inputSchema` に合った引数
出力 `result`	`content`	必須	結果の配列（下の表の型のどれか）
出力 `result`	`structuredContent`	任意	`outputSchema` に合ったJSON
出力 `result`	`isError`	任意	処理が失敗したら `true`（省略は `false`）

`content` の `type`	一緒に入る属性	中身
`text`	`text`	文章（いちばんよく使う）
`image` / `audio`	`data`（base64）、`mimeType`	画像・音声
`resource_link`	`uri`、`name` など	ファイルなどへのリンク
`resource`	`resource`（`uri`、`text` か `blob`）	ファイルなどの中身そのもの

仕様で決まっている：エラー番号（`error.code`）¶

番号	意味
-32700	JSONとして読めない
-32600	リクエストの形が正しくない
-32601	そのメソッドはない
-32602	引数がおかしい（存在しないツール名など）
-32603	サーバー内部のエラー

サーバーが自由に決める項目¶

決めるもの	例	どこで公開する？
ツール名	`create_repository`、`search_threads`	`tools/list` の `name`
引数の項目名・型・必須かどうか	`name`（文字列・必須）、`private`（真偽値・任意）	`inputSchema`
説明文	「リポジトリを新しく作る」	`description`
返す文章や画像の中身	「作成しました」	`content`

同じ「リポジトリを作る」でも、サーバーによって引数の名前が違うことがある。だからAIは毎回 tools/list の説明を読む。
引数の中身は自由でも、書き方（JSON Schema の type・properties・required など）は決まっている。

annotations は自己申告

readOnlyHint（読むだけ）などは、サーバーが自分で書いたヒントにすぎない。仕様でも、信頼できないサーバーの annotations は信用しない扱いになっている。「読むだけと書いてあるから安全」とは考えず、セキュリティの対策と組み合わせる。

※ 表の項目は、2025-06-18 版から続く基本の項目。2026-07-28 版では、リクエストごとの _meta にプロトコルのバージョンなどを入れる形になり、一覧の結果にはキャッシュの期限（ttlMs）なども付く。細かい項目は公式の仕様で確認する。

質問：2026-07-28 の仕様で何が変わった？¶

答え： 「セッションなしのシンプルな作り」と「拡張機能の枠組み」が大きな変更。仕様の日付（YYYY-MM-DD）は、互換性がなくなる変更のときに新しくなる。

変更	内容	うれしいこと
最初のあいさつとセッションを廃止	接続時の握手（initialize）とセッションIDをやめ、1回のリクエストごとに完結する形に	サーバーを何台にも増やしやすい（負荷分散しやすい）
一覧結果のキャッシュ	ツールなどの一覧に、有効期限を付けられる	毎回一覧を取り直さなくてよい
認可（OAuth）の強化	発行元の確認を厳しくするなど	なりすましや設定ミスを防ぎやすい
拡張機能の枠組み	長時間の処理（Tasks）、画面を出すアプリ（MCP Apps）、企業向けの認可などを「拡張」として切り出す	中心の仕様を小さく保ちつつ、機能を足せる
古い機能の非推奨化	古い通信方式（HTTP+SSE）や、Roots・Sampling・Loggingなどを非推奨に	最低12か月は動くので、その間に移行する

細かい仕様は変わりやすいので、作る側に回るときは公式の仕様を確認する。

質問：セキュリティで気をつけることは？¶

答え： MCPサーバーは、AIに合鍵を渡すのと同じ。AIは便利だが、だまされることもある。「何を読ませるか」と「何をさせてよいか」を分けて考える。

リスク	起きること	対策
プロンプトインジェクション	メールやWebページに「このデータを外部に送って」と隠し指示があり、AIが従ってしまう	送信・削除・書き込みは人が承認する。読み込んだデータの中の指示を信用しない
権限が広すぎる	読むだけでよいのに、全リポジトリへの書き込み権限を渡している	最小権限。まず読み取り専用から始める
怪しいMCPサーバー	ツールの説明文に罠が仕込まれている（ツールポイズニング）、公式を名乗る偽物	提供元が信頼できるものだけ使う。会社では許可したサーバーだけに絞る
データの持ち出し	AI経由で、機密データが外部のサービスへ渡る	DLP・CASBの考え方で、どこへ何が出るかを見る
鍵（トークン）の扱い	APIキーを設定ファイルに平文で書いている	OAuthでログインする方式を選ぶ。キーはシークレット管理に入れる

これまでのノートとのつながり¶

リモートのMCPサーバーは、SaaSの一種として見られる。会社が許可していないMCPサーバーの利用は、CASBでいうシャドーITと同じ問題になる。
AIに渡す権限の考え方は、ZTNAの「必要なものだけ、毎回確認して」と同じ。マスターキーではなく、カードキーを渡す。
AIが読む社内データの範囲は、データガバナンスの「利用（誰が・何に使えるか）」のルールで決める。

具体例¶

やりたいこと	使うMCPサーバー	AIがすること
来週の空き時間に会議を入れる	Googleカレンダー	予定を検索し、空き時間を探して予定を作る
届いた請求書メールをまとめる	Gmail	メールを検索し、金額と期限を一覧にする
ノートを書いてサイトに公開する	GitHub	ファイルを書き換えて、コミット・プッシュする
社内DBの数字を集計する	データベース	表の構成を読み、SQLを作って実行する

確認したいこと¶

会社で、どのAIアプリからMCPサーバーを使ってよいか。許可するサーバーの一覧を作るか
MCPサーバーに渡すトークンの権限は、読み取りだけで足りるか
AIが送信・削除などをするとき、毎回承認する設定になっているか
社外のリモートMCPサーバーへの通信を、SASE（SWG・CASB）で見えるようにするか

MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ共通規格¶

30秒で復習¶

こんな場面で出会う¶

用語の正式名称と読み方¶

質問：MCPとは？¶

イメージ（たとえ話）¶

質問：どんな仕組みで動く？¶

サーバーがAIに渡すもの¶

実際の流れ（このサイトを作ったときの例）¶

質問：普通のAPI連携やプラグインと何が違う？¶

質問：具体的にどんな入出力をする？¶

全体ではこう変換されている¶

① 使えるツールの一覧をもらう（`tools/list`）¶

② ツールを実行する（`tools/call`）¶

エラーは2種類あり、返し方が違う¶

どうやって運ぶ？¶

質問：JSONの項目（パラメータ・属性）は決まっている？¶

仕様で決まっている：JSON-RPC の共通項目¶

仕様で決まっている：主なメソッド名¶

仕様で決まっている：ツール定義の属性（`tools/list` の中身）¶

仕様で決まっている：実行と結果（`tools/call`）¶

仕様で決まっている：エラー番号（`error.code`）¶

サーバーが自由に決める項目¶

質問：2026-07-28 の仕様で何が変わった？¶

質問：セキュリティで気をつけることは？¶

これまでのノートとのつながり¶

具体例¶

関連メモ¶

確認したいこと¶

参考資料¶

MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ共通規格¶

30秒で復習¶

こんな場面で出会う¶

用語の正式名称と読み方¶

質問：MCPとは？¶

イメージ（たとえ話）¶

質問：どんな仕組みで動く？¶

サーバーがAIに渡すもの¶

実際の流れ（このサイトを作ったときの例）¶

質問：普通のAPI連携やプラグインと何が違う？¶

質問：具体的にどんな入出力をする？¶

全体ではこう変換されている¶

① 使えるツールの一覧をもらう（tools/list）¶

② ツールを実行する（tools/call）¶

エラーは2種類あり、返し方が違う¶

どうやって運ぶ？¶

質問：JSONの項目（パラメータ・属性）は決まっている？¶

仕様で決まっている：JSON-RPC の共通項目¶

仕様で決まっている：主なメソッド名¶

仕様で決まっている：ツール定義の属性（tools/list の中身）¶

仕様で決まっている：実行と結果（tools/call）¶

仕様で決まっている：エラー番号（error.code）¶

サーバーが自由に決める項目¶

質問：2026-07-28 の仕様で何が変わった？¶

質問：セキュリティで気をつけることは？¶

これまでのノートとのつながり¶

具体例¶

関連メモ¶

確認したいこと¶

参考資料¶

① 使えるツールの一覧をもらう（`tools/list`）¶

② ツールを実行する（`tools/call`）¶

仕様で決まっている：ツール定義の属性（`tools/list` の中身）¶

仕様で決まっている：実行と結果（`tools/call`）¶

仕様で決まっている：エラー番号（`error.code`）¶