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

最終確認: 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連携との大きな違い。
MCPサーバーは「AIに渡す合鍵」。権限は最小に、信頼できるサーバーだけを使い、書き込みや送信は人が承認する。

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

用語	意味	ひとことで
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	やり取りするメッセージの書式	共通の書類フォーマット

質問：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が使いやすい形に包む仕組み。

質問：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）で見えるようにするか