先に要点
最近、生成AIやAIエージェントの話を見ていると、MCP という言葉をかなり見かけるようになりました。
ただ、名前だけ見ると難しそうですし、結局プラグインと何が違うのか 何が便利なのか が分かりにくいままになりやすいです。
この記事では、2026年4月19日時点で Model Context Protocol の公式 FAQ、Architecture overview、最新仕様ページ、Anthropic の MCP ドキュメントを確認しながら、MCP の基本、できること、便利な理由、初心者が最初に押さえたい注意点を整理します。
AI を社内で安全に使う観点も気になるなら、生成AIを社内で使うときのセキュリティ対策は？入力ルール・権限・運用設計を解説 もあわせて読むとつながりやすいです。
AI にコードを書かせるときの確認ポイントから見たい場合は、AIにコードを書かせるときの注意点は？そのまま使わないための確認ポイントを解説 も続けて読むと整理しやすいです。
サーバー側は実際に何をするのか をもう一段具体的に見たい場合は、サーバー側の役割をまとめた記事 もあわせてどうぞ。
普通に AI API を組み込むのと何が違うのか という判断軸から見たい場合は、API直結との比較記事 も続けて読むと整理しやすいです。
では実際に何を実装対象にすると役立ちやすいのか を具体例から見たい場合は、実装例をまとめた記事 もつながります。
なぜ最近よく見るのか
MCP が最近よく出てくるのは、単に新しい略語だからではありません。
Claude Code、Claude Desktop、社内AIチャット、各種エージェント開発、AIコードエディタ文脈で、AI に外部ツールやデータをどうつなぐか が現実の課題になってきたからです。
たとえば、AI に次のようなことをさせたい場面が増えています。
- ローカルファイルを読む
- GitHub やチケット管理ツールを触る
- 社内 API やドキュメント検索を使う
- ブラウザ操作や業務フローの一部を実行する
ここで毎回アプリごとに独自連携を作ると、実装も運用もばらけます。
そのため、AI向けの共通接続ルール として MCP が注目されやすくなっています。
Anthropic の公式ドキュメントでも、MCP は AI アプリにとっての USB-C のような標準口として説明されています。
比喩っぽく見えますが、実務では 接続先を部品として増やしやすい という意味でかなり本質的です。
MCPとは何か
MCP は Model Context Protocol の略で、AIアプリと外部のデータ・ツールをつなぐための標準化された仕組みです。
公式FAQでは、AIアプリやエージェントがデータソースやツールと連携するための standard way と説明されています。
ざっくり言うと、AIに何を見せるか と AIに何を実行させるか を、毎回独自方式でつなぐのではなく、共通の口でつなぎやすくするためのルールです。
USB-C のような共通口にたとえて説明されることがありますが、感覚としてはかなり近いです。
この説明だけだと少し抽象的なので、実際のイメージに直すとこうです。
- AIアプリが、社内ドキュメントを読めるようにしたい
- GitHub や Slack や Google Drive の情報も読ませたい
- ファイル検索やチケット作成のような操作もさせたい
- ただし、接続方法は毎回バラバラにしたくない
このとき、接続の共通ルールとして使えるのが MCP です。
どういう参加者で動くのか
公式の Architecture overview では、MCP は host / client / server の形で整理されています。
初心者向けには、次のように理解すると分かりやすいです。
- ホスト
生成AIアプリ本体です。たとえばエディタ、デスクトップアプリ、社内のAIチャット基盤などがここに当たります。 - クライアント
ホストの中で、MCP サーバーへ接続する役です。接続先ごとに 1 つずつ持つイメージです。 - MCPサーバー
データやツールを提供する側です。ファイル、データベース、SaaS、社内API、ブラウザ操作などを提供します。
大事なのは、AIアプリが直接すべてを知っているわけではない ことです。
AIアプリは、必要に応じて MCP サーバーへ問い合わせたり、実行依頼を出したりして、外の情報や機能を使います。
何ができるのか
MCP の中で特に大事なのは、サーバーが公開できる3つの基本要素です。
公式では tools / resources / prompts がコアプリミティブとして整理されています。
| 要素 | 役割 | 例 |
|---|---|---|
| ツール | AIが呼び出して実行する機能 | ファイル検索、API呼び出し、チケット作成 |
| リソース | AIに見せるためのデータ | ファイル内容、DBスキーマ、設定情報 |
| プロンプト | やり取りの型やテンプレート | 業務フォーマット、定型指示の部品化 |
ツール
MCPツール は、AI が呼び出して実行できる機能です。
たとえば、ファイル検索、API 呼び出し、DB クエリ、チケット作成、ブラウザ操作などがここに入ります。
AI が何かをする 側の入口だと思うと分かりやすいです。
リソース
MCPリソース は、AI に見せるためのデータです。
ファイルの中身、DB スキーマ、設定情報、API レスポンス、社内ナレッジなどがここに入ります。
AI が読むもの 側の入口だと思うと整理しやすいです。
プロンプト
MCPプロンプト は、やり取りの型やテンプレートです。
このツールを使うときはこう聞く この業務ならこのフォーマットで整理する のような再利用しやすい型を持たせられます。
AI への指示の型 を部品化するイメージに近いです。
仕組みをざっくり言うと
MCP の通信は、公式仕様では JSON-RPC を土台にしています。
その上で、接続やメッセージの流れとしては次のように進みます。
- ホスト側のクライアントが MCP サーバーへ接続する
initializeで対応バージョンや機能を確認する- サーバーが
tools / resources / promptsを公開する - クライアントが一覧を取り、必要に応じて読み取りや実行を行う
- 必要なら通知やログ、追加入力のやり取りも行う
ここで大事なのは、最初に 何ができるか を握ることです。
最初から何でも勝手に実行するのではなく、対応機能や公開されている要素を見てから使う形になっています。
接続方法は何があるのか
2026年4月4日時点で公式仕様を見ると、標準の接続方法としては stdio と Streamable HTTP の2つが整理されています。
公式仕様では、古い HTTP+SSE ベースの方式から、現在は Streamable HTTP へ整理が進んでいます。
古い記事やサンプルを見るときは 今の公式は何を推しているか を確認した方が安全です。
何が便利なのか
MCP が便利だと言われる理由は、単に AIから外部ツールが使える からではありません。
本当に効くのは、接続の作り方をそろえやすい ことです。
接続を使い回せる
AIアプリごとに毎回独自連携を作らず、MCPサーバーを部品化して再利用できます。
読むと実行を分離
リソース（読み取り）とツール（実行）を分けて整理でき、権限管理がしやすいです。
拡張しやすい
社内チャットやエディタなどの拡張ポイントとして、保守の考え方をそろえやすいです。
AIごとに毎回つなぎ直さなくてよい
従来は、AIアプリA と GitHub をつなぐ方法、AIアプリB と GitHub をつなぐ方法、AIアプリC と GitHub をつなぐ方法を、それぞれ別で作ることが多くなりがちでした。
MCP では、接続先側をサーバーとして部品化できるので、対応クライアントから再利用しやすくなります。
「読む」と「実行する」を分けて整理しやすい
MCPリソース と MCPツール を分けて考えられるので、何を見せるか と 何を実行させるか を整理しやすいです。
社内利用では、この切り分けがかなり大事です。
生成AIアプリの拡張ポイントとして考えやすい
社内チャット、エディタ、デスクトップアプリ、社内エージェントなどで、外部につなぐ入口 を考えるとき、MCP を1つの拡張レイヤーとして見やすくなります。
全部を独自API連携で作るより、保守の考え方をそろえやすいです。
実務ではどんな場面で役立つのか
初心者向けに言うと、MCP は AI に社内データや業務ツールを安全に渡したいとき に相性がよいです。
たとえば次のような場面です。
- 社内ドキュメントを読ませて、要約や検索補助をしたい
- GitHub や issue 管理ツールとつないで、開発補助をしたい
- DB スキーマやログを読ませて、調査補助をしたい
- 社内API やワークフローを呼んで、決まった作業を補助したい
特に、社内チャットAIに何を見せ、何を実行させるか を整理したい場面では、MCP の考え方はかなり使いやすいです。
社内運用のルール設計は、生成AIを社内で使うときのセキュリティ対策は？入力ルール・権限・運用設計を解説 と一緒に見るとつながりやすいです。
便利そうに見えても気をつけたいこと
ここはかなり大事です。
MCP は便利ですが、つないだら全部よくなる ものではありません。
権限を広くしすぎると危ない
AI に便利なツールを渡すほど、できることは増えます。
でも逆に言うと、間違った実行や広すぎる参照範囲も増えやすいです。
そのため、実務では少なくとも次を見たいです。
- 読み取り専用で足りるか
- 書き込みや削除まで必要か
- どのデータを見せるか
- 認証や承認をどう挟むか
リモート接続では認証と通信設計が大事
公式仕様でも、HTTP ベースの接続では認証と認可の整理があり、Authorization の章では HTTP transport では認可仕様へ従うことが案内されています。
また Transport の章でも、Origin ヘッダー確認や localhost バインドなどの注意が出ています。
つまり、リモートで公開する場合は HTTP でつながるから簡単 ではなく、普通のサーバー公開と同じくらい気を遣う 方が安全です。
必要に応じて OAuth 2.0 系の考え方も関わってきます。
古い記事や古い実装例はそのまま信じない
MCP は変化が早めです。
実際、HTTP+SSE の扱いは新しい仕様で Streamable HTTP に整理されています。
そのため、検索上位で見た記事 より、今の公式仕様が何を標準としているかを先に見る方が安全です。
初心者はどこから触るとよいか
これから触るなら、次の4ステップが分かりやすいです。最初からリモート公開や認可仕様まで理解しようとすると重いので、ローカル接続から段階的に。
まずは AIアプリとローカルツールをつなぐ共通ルール としてイメージをつかむと入りやすいです。
MCP に関するよくある質問
MCP はプラグインやアドオンと何が違う？
プラグインは 特定のホストアプリ向けの拡張 であることが多く、ホストごとに作り直す必要があります。MCP は AI アプリ全般が共通に使う標準接続ルール なので、1つの MCP サーバーを書けば、対応する複数のホスト（Claude Code、Claude Desktop、IDE、社内 AI チャットなど）から再利用できます。
MCP は OpenAI の関数呼び出し（function calling）と競合する？
別レイヤーの仕組みです。function calling はモデルが構造化された関数呼び出しを生成する機能、MCP は AI アプリと外部サービスをつなぐ接続規約。実装としては、MCP サーバーが提供するツールを、内部的に function calling として OpenAI モデルに渡すこともできます。むしろ補完関係です。
MCP サーバーを自作する必要がある？
公式や OSS で提供されている既存の MCP サーバー（GitHub、Slack、Postgres、ファイルシステムなど）が増えているので、まずは既存を試すのが速いです。社内固有のデータや業務 API につなぎたいときに自作を検討します。
セキュリティ的に何が一番怖い？
AI に強力なツールを広い権限で渡すこと です。たとえばファイル削除・本番 DB 書き込み・外部 API 課金などのツールを無制限に渡すと、AI の判断ミスが現実の事故になります。読み取り専用から始め、書き込み系は承認フローを挟むのが安全です。
Streamable HTTP と SSE は何が違う？
過去には HTTP + SSE（Server-Sent Events）ベースの方式が使われていましたが、現在の公式仕様では Streamable HTTP に整理されています。実装としては HTTP リクエストでメッセージを送り、必要に応じてストリーミング応答を返す形。古い記事の HTTP+SSE 実装は最新仕様では推奨されません。
MCP は今後も標準として残る？
2026年4月時点では Anthropic、OpenAI、各種 IDE、社内 AI 基盤などで採用が広がっています。仕様自体は活発に更新されており、どの時点の仕様 を実装したかで挙動が違うので、公式ドキュメントで最新仕様を確認する習慣が大事です。
まとめ
MCP は、生成AIアプリと外部ツール・データをつなぐための共通ルールです。
仕組みとしては ホスト / クライアント / サーバー で動き、基本要素として MCPツール、MCPリソース、MCPプロンプト があり、通信の土台として JSON-RPC、接続方法として stdio と Streamable HTTP が整理されています。
便利なのは、AI と外部サービスのつなぎ方をそろえやすくなることです。
一方で、権限、認証、公開範囲、古い仕様との差分を考えずに使うと、便利さより先に事故が来やすいです。
初心者のうちは、MCP はAIのための共通接続ルールなんだな と押さえたうえで、まずはローカル接続例から見るとかなり理解しやすいです。
参考情報
- Model Context Protocol: FAQs
- Model Context Protocol: Architecture overview
- Model Context Protocol: Architecture
- Model Context Protocol: Specification Overview
- Model Context Protocol: Transports
- Model Context Protocol: Authorization
- Anthropic Docs: Model Context Protocol (MCP)