この記事はMCPの仕組みを理解するための解説です。特定のAI製品やMCPサーバーの安全性を保証したり、特定実装の導入を推奨したりするものではありません。
AIに「カレンダーを確認して予定を入れて」「社内文書を探して要点をまとめて」と頼むとき、言語モデルだけでは仕事は完了しない。カレンダー、ファイル、データベース、検索、業務システムへ接続し、必要な操作を呼び出す経路がいる。
MCP（Model Context Protocol）は、その接続方法を共通化するためのオープンなプロトコルである。AIそのものを賢くする技術というより、AIアプリケーションと外部のデータ・ツールの間に、共通の接続面をつくる仕組みと考えると分かりやすい。
01 MCPは「AI用のAPI」ではなく、接続の共通ルール
APIは、サービスごとに使い方が違う。認証方法、エンドポイント、入力形式、返り値、エラー処理も異なる。AIアプリケーションが10種類のサービスを使うなら、それぞれに専用の接続コードを書くこともできる。
MCPが狙うのは、各サービスのAPIを消すことではない。既存のAPIやデータソースの手前にAIアプリケーションから見た共通の接続面を置くことだ。
公式TypeScript SDKは、MCPを「AIアプリケーションを、データやツールが存在するシステムへ接続するオープン標準」と説明している。MCPサーバーは、代表的には次のようなものを公開する。
| MCPの要素 | 役割 | 例 |
|---|---|---|
| Tools | AIが呼び出せる操作 | 検索、予定作成、ファイル更新 |
| Resources | 参照できるデータや内容 | 文書、設定、履歴 |
| Prompts | 再利用できる指示やテンプレート | 定型分析、作業手順 |
重要なのは、MCPが「AIに何でも許可する規格」ではないことだ。何を公開するか、どの操作に認証が必要か、実行前に人の確認を置くかは、サーバーやホスト側の設計として残る。
02 MCPを使うと、何が変わるのか
MCPがない世界では、AIアプリケーションAからサービスXへ接続するコードと、AIアプリケーションBから同じサービスXへ接続するコードを別々に作ることになりやすい。
個別接続
AI A ──専用実装── Service X
AI A ──専用実装── Service Y
AI B ──別実装──── Service X
MCP
AI A ─┐
AI B ─┼─ MCP ── Server X ── Service X
AI C ─┘ └─ Server Y ── Service Yもちろん、現実の実装はこれほど単純ではない。それでも「AI側とツール側の組み合わせごとに接着剤を書く」問題を減らすことが、標準化の大きな価値になる。
[AIエージェントをモデルではなく行動の境界として整理した記事](/articles/ai-agent-definition-and-boundaries/)で見たように、エージェントが実際に仕事を進めるにはツールが必要になる。MCPは、そのツール接続をエージェントごとの固有機能に閉じ込めないための一つの方法である。
03 2026年のMCPは、初期の「ローカルツール接続」から広がっている
MCPは更新の速い仕様である。2026年7月28日に公開された仕様では、特に大きな変更としてプロトコルの中核がステートレスな要求・応答モデルへ移った。
公式の2026-07-28仕様は、主な変更として次を挙げている。
- プロトコル中核のステートレス化
- ヘッダーを使ったルーティング
- ツール等の一覧結果のキャッシュ
- 認可フローの強化
- 拡張機能を扱う正式なExtensions framework
- 長時間処理を扱うTasks extension
- 非推奨機能を少なくとも12か月維持する方針
これは、MCPが単にデスクトップ上のローカルAIからファイルを読む仕組みではなく、サーバー、ゲートウェイ、認証基盤を含む実運用へ広がっていることを示している。
一方で、仕様が更新されるということは「MCP対応」と書いてあれば全部同じという意味でもない。クライアントとサーバーがどの仕様バージョンを話すのか、利用するSDKがどの版へ対応しているのかは確認する必要がある。
次の仕様更新に向けた公式ロードマップも、2026年8月22日に公開された。そこでは、エージェントの長時間処理とサーバー発イベント、HTTP転送の統一・強化、エージェントの識別と企業向けセキュリティ、ツール結果と段階的な機能発見、SDKの開発体験という五領域が優先課題に挙がる。これは今後の仕様作業の方向を示すロードマップで、すでに公開された必須機能の一覧ではない。導入時には公式ロードマップと、公開済み仕様、使うSDKの対応状況を分けて確認する。
04 MCPとRAGの違い——接続方法と検索・生成の設計は別
MCPとRAGは、どちらもAIへ外部情報を渡す文脈で登場するため混同されやすい。
違いを短く整理するとこうなる。
MCP : AIアプリケーションと外部ツール・データをどう接続するか
RAG : 外部情報を検索し、回答生成へどう利用するかRAGは検索拡張生成という設計パターンであり、文書を検索して関連情報をモデルへ渡す。[RAGの仕組みを整理した記事](/articles/rag-retrieval-augmented-generation/)で扱った検索、取得、生成という流れが中心になる。
MCPは、その検索システム自体をAIから呼び出す経路として使うことができる。例えば社内検索をMCPのToolとして公開し、そのToolが裏側でベクトル検索やRAGを使う構成はあり得る。
つまり、MCPかRAGかという二択ではない。
05 MCPとA2Aの違い——ツール接続とエージェント間協働
2026年にはMCP以外にも複数のエージェント向けプロトコルが存在する。中でもA2A（Agent2Agent）との違いは検索されやすい。
GoogleはA2Aを、異なるAIエージェント同士が情報を交換し、タスクを調整するためのプロトコルとして説明し、MCPとは補完関係にあるとしている。
| MCP | A2A | |
|---|---|---|
| 主な接続 | AIアプリ／エージェント ↔ ツール・データ | エージェント ↔ エージェント |
| 主な目的 | 外部能力や文脈を共通形式で利用する | 別のエージェントへ依頼・協働する |
| 例 | GitHub操作、DB検索、カレンダー | 購買エージェントと物流エージェントが連携 |
一つのシステムが両方を使うこともできる。エージェントAがA2AでエージェントBへ作業を依頼し、エージェントBがMCP経由で在庫データや業務ツールを使う、といった構成だ。
名前の似たプロトコルを競合規格として一列に並べるより、「何と何を接続する規格なのか」を見る方が理解しやすい。
06 接続できることと、許可されていることは違う
MCPで最も重要な設計問題の一つが権限である。
カレンダーを「読む」Toolと「予定を削除する」Toolでは影響が違う。ファイル検索とファイル削除も同じではない。MCPの2026-07-28仕様では認可周辺も強化され、OAuth等を使う実運用を意識した変更が入っている。
しかし、標準に認可の仕組みがあることと、安全な権限設計が自動的に完成することは別だ。
最低限、次を分けておきたい。
- 読み取りだけでよい操作
- 元に戻せる書き込み
- 外部送信や公開
- 削除、購入、支払いなど影響の大きい操作
- 機密データを扱う操作
高リスク操作では、[AIエージェントの人間監督を扱った記事](/articles/ai-agent-definition-and-boundaries/)と同じく、実行直前に何が起きるのかを見せ、人が止められる境界が必要になる。
MCPサーバーを追加することは、単に「便利なプラグインを増やす」ことではない。AIが触れられる世界を広げることでもある。
07 MCPを使う意味がある場合、ない場合
標準だから常に使うべき、ということでもない。
MCPが向きやすい
- 複数のAIクライアントから同じツールを使いたい
- 同じ連携を複数製品で再利用したい
- ツールの発見や呼び出し形式を揃えたい
- AIエージェントの接続先が増えている
- 認証やガバナンスを接続単位で整理したい
個別APIでも十分な場合
- 一つのアプリと一つの内部APIだけを固定接続する
- AIから動的にツールを発見する必要がない
- 既存の統合が単純で、標準化の追加コストの方が大きい
MCPの価値は、APIを書かなくてよくなることではない。接続先が増えたときに、AIから見た境界を共通化できることにある。
08 MCPが変えるのは、モデルより「周辺の構造」
生成AIの進化はモデルサイズやベンチマークで語られやすい。しかしAIエージェントが日常の仕事へ入るほど、重要になるのはモデルの外側だ。
どのデータへ届くのか。どのツールを呼べるのか。認証は誰の権限で行うのか。実行履歴は残るのか。別のAIへ作業を渡せるのか。
MCPは、その周辺構造を標準化しようとする一つの試みである。
だからMCPを理解する入口は「対応AIはどれか」だけではない。AIが現実のシステムへ触れる接点を、どのような共通ルールで管理するかを見ることだ。
AIエージェントの未来は、モデルが単独で万能になることだけでは進まない。ツール、権限、人間、別のエージェントをどうつなぐか。その接続面が、次のインターフェースになる。