結論から
MCP（Model Context Protocol、モデル・コンテキスト・プロトコル）は、AI を「外の世界」につなぐための、共通の差込口（さしこみぐち）です。AI は、そのままでは学習した知識と、あなたが会話に貼り付けた文章しか見えません（→ RAG の記事）。でも、Gmail を読む・Notion を更新する・データベースに問い合わせる、といった「今そこにあるシステムを実際に操作する」には、AI をそのシステムにつなぐ必要があります。MCP は、そのつなぎ方を世界共通の形に決めた約束事です。Anthropic が2024年11月に公開し、その後 OpenAI・Google・Microsoft も採用しました。
この記事で伝えたいのは、この一点だけです。MCP は「USB-C の差込口」のようなもの。サービス側が MCP で1回つなぎ口を作れば、どの AI からでもそのサービスを使える。AI ごとに専用ケーブルを作らなくていい。 「Claude に Slack をつなぐ」「Cursor に GitHub をつなぐ」——最近こういう連携が急に増えたのは、MCP のおかげです。
- AI は普段、外のシステムを直接は触れない。触るには「つなぐ」必要がある
- MCP が無かった頃：AI が3種類 × サービスが4種類 なら、専用の接続を 3×4＝12個 作る必要があった
- MCP：サービス側が「MCP サーバー」を1つ作れば、対応するどの AI からも使える。作るのは1回だけ
- 何ができるか：AI が、ファイルを読む・関数を実行する・DB に問い合わせる、を「あなたの代わりに」やれるようになる。だから、渡す権限には注意（→ AIエージェントの記事）
動画版（約2分半）は本文の上に埋め込んであります。
① なぜ必要か：AIは、外のシステムを直接は触れない
RAG の記事で、「AI は自分のデータを知らないから、質問と一緒に資料を渡す」という話をしました。あれは、AI に読ませる話でした。MCP は、その一歩先です。AI に、外のシステムを操作させる話です。
たとえば「今週の未対応の問い合わせを Slack に投げて」と AI に頼むには、AI が①あなたの問い合わせデータベースを見て、②Slack に投稿する、という2つの操作を、外のサービスに対して実行できないといけません。AI は、そのままではこれができません。データベースにも Slack にも、つながっていないからです。
だから、AI と外のサービスの間に「つなぎ口」を作ります。ここで問題になるのが、種類の多さです。AI は Claude も ChatGPT も Gemini もある。サービスは Slack も Notion も GitHub も Google ドライブもある。MCP が無かった頃は、「Claude ↔ Slack」「Claude ↔ Notion」「ChatGPT ↔ Slack」……と、組み合わせの数だけ専用の接続を作る必要がありました。AI が3種類、サービスが4種類なら、3×4で12個。これが増えるほど、誰も追いつけなくなります。
② 仕組み：共通の差込口を、1回だけ作る
MCP の考え方は、パソコンの USB-C と同じです。昔は、機器ごとに専用のケーブルがありました。今は、USB-C という共通の形に決めたので、その差込口が付いていれば、どのメーカーの機器にもつながります。ケーブルを機器の組み合わせごとに作る必要がなくなりました。
MCP は、AI とサービスの間に、この「USB-C」を決めたものです。サービス側（Slack や Notion）が、MCP という決まった形で「つなぎ口」——これを MCP サーバー と呼びます——を1つ作っておく。すると、MCP に対応した AI（Claude、ChatGPT、Cursor など）は、どれもそのつなぎ口に差し込むだけで、そのサービスを使えます。サービス側は1回作れば済み、AI 側は1回対応すれば、すべての MCP サーバーが使える。 さっきの「3×4で12個」が、「3＋4で7個」の手間に変わる、というのがミソです。
この標準は、急速に広まりました。Anthropic が2024年11月に公開したあと、2025年3月には OpenAI が採用を表明し、Google（Gemini）や Microsoft（Copilot）も続きました。2025年のうちに、公開されている MCP サーバーは1万を超えたと報告されています。「最近、いろんな AI にいろんなサービスをつなげるようになった」という実感の裏には、この共通化があります。
MCP サーバーが AI に提供するものは、大きく2つです。道具（ツール）——「Slack に投稿する」「ファイルを検索する」のような、実行できる操作。そしてデータ——「この顧客の情報」「このファイルの中身」のような、読める情報。AI は、つないだ MCP サーバーが差し出す道具とデータを見て、「じゃあ、この道具を使おう」と判断して、実行します。
③ 何ができて、何に注意するか
MCP をつなぐと、AI は「あなたの代わりに、外のサービスを操作する」ようになります。ここが、RAG（読むだけ）との決定的な違いです。
- 「先月の請求書を全部 PDF にして、経理フォルダに保存して」——会計サービスとドライブを MCP でつなげば、AI が一気にやる
- 「このバグ報告を GitHub の Issue にして、担当者にアサインして」——GitHub を MCP でつなげば、AI が起票する
- 「今日の予約を確認して、キャンセルがあれば顧客にメールして」——予約 DB とメールを MCP でつなげば、AI が送る
便利です。でも、便利さの正体は「AI に、実際に操作する権限を渡した」ことです。ここが、そのまま注意点になります。AI が判断を誤ったり、だまされたり（→ プロンプトインジェクションの記事）したとき、渡した権限の分だけ、被害が出ます。MCP でメール送信をつないでいれば、AI が誤って大量送信することもありえます。削除をつないでいれば、消すこともありえます。
だから、MCP をつなぐときの原則は、AI エージェントの記事と同じです。「頼んだ仕事に必要な最小限」だけをつなぐ。読み取り専用で済むなら、読み取り専用に。取り消せない操作（送信・削除・決済）は、人が確認してから。 実際、2025年には、AI に接続した MCP を経由して、外部から仕込まれた指示で機密データが持ち出される例も報告されました。つなぐこと自体より、何を・どこまでつなぐかを決めるのが、あなたの仕事です。
よくある質問
RAG と MCP は、どう違うのですか。
RAG は「AI に資料を読ませる」（→ RAG の記事）。MCP は「AI を外のシステムにつないで、操作させる」。読むだけなら RAG、操作もするなら MCP、と分けると分かりやすいです。実際には、MCP を通して RAG 用のデータを取ってくる、のように組み合わせることもあります。
MCP は、自分でも使えますか。
はい。Claude Desktop や Cursor などは、設定ファイルに MCP サーバーを追加するだけで使えます。公開されている MCP サーバー（GitHub、Slack、各種 DB など）を差し込む形が多いです。自分のサービス用に MCP サーバーを作ることもできますが、まずは「既にあるものをつなぐ」から始めるのが現実的です。
あやしい MCP サーバーをつないでも大丈夫ですか。
注意が必要です。MCP サーバーは、AI に道具と情報を差し出す側なので、悪意ある MCP サーバーは、AI に不正な指示を混ぜたり、渡した情報を盗んだりできます。出どころの分かる、信頼できる MCP サーバーだけをつなぐのが原則です。会社で使うなら、誰がどの MCP をつないでいいか、ルールを決めてください。
この記事が分かれば、MCP を安全に使えますか。
「何をする仕組みか」と「権限に注意」までは分かります。実際に業務で使うときは、AI に渡す権限の絞り方（→ AIエージェントの権限過剰の記事）と、つなぐ相手の信頼性を、合わせて確認してください。次回は、AI に「できること」を足すもう1つの方法、スキルとツールを扱います。
