MCP(Model Context Protocol)とは　

Last updated at 2025-12-25Posted at 2025-12-25

AIが抱える課題

現状のAI活用においては、以下のような課題があります。

AIモデルと外部システムの組み合わせごとに個別実装が必要
システムやAIモデルが増えるたびに、統合数が乗算的に増加する
AIモデルごとに接続方式やAPI仕様が異なり、互換性がない

例えば、
3つのAIモデル（ChatGPT、Claude、Gemini）を
5つのシステム（Slack、GitHub、Google Drive、PostgreSQL、Notion）に接続する場合、
3 × 5 = 15個の個別統合を実装・保守する必要があります。

このような構成では、開発・保守コストが高く、AIやシステムを追加するたびに実装負荷が急増してしまいます。

この課題を解決するために登場したのが MCP（Model Context Protocol）です!

MCPとは

¹MCP（Model Context Protocol）は、Claude などのLLM（大規模言語モデル）が外部システムと連携するための標準プロトコルです。

LLMが実用的に使われる場面では、
データベース、ファイルストレージ、社内ツール、各種APIなど
外部システムへのアクセスが不可欠になります。

MCPは、そうした外部システムとのやり取りを統一するための
**「LLMが外部と通信するための共通ルール（通信規約）」**を提供します。

¹²例えるなら、MCPはAIシステムにおけるUSB-Cのような存在です。
USB-Cが様々なデバイスを標準化して接続するように、MCPは様々なAIシステムを標準化して外部ツールに接続します。

なぜMCPが必要なのか

これまでLLMが外部のAPIやデータベースにアクセスする場合、接続先ごとに個別の設定や実装が必要でした。

外部システムはそれぞれ、

独自の認証方式
独自のリクエスト構造
独自のレスポンス形式

これらを持っており、LLMから利用するには、API・DBごとに専用のインターフェース実装を用意する必要がありました。

LLMごとに異なるツール呼び出し形式

さらに問題なのは、LLMベンダーごとにツール呼び出しの形式が異なる点です。

³例えば、同じ「天気情報を取得する」という処理でも、
モデルによって以下のように表現が異なります。

OpenAI（Function Calling）

{
  "type": "function",
  "id": "call_12345xyz",
  "function": {
    "name": "get_weather",
    "arguments": "{\"location\":\"Paris, France\"}"
  }
}

Anthropic（Tool Use）

{
  "type": "tool_use",
  "id": "toolu_01A091901w901q917835lq9",
  "name": "get_weather",
  "input": {
    "location": "San Francisco"
  }
}

このように、同じツール・同じ機能であっても、モデルごとに実装を分ける必要があるため、

LLMを切り替える
複数のLLMを併用する

といった構成が非常に扱いづらくなっていました。

MCPを使ったツール呼び出し

³MCPでは、これまでの課題を解決するために、
外部ツールやAPIの呼び出し仕様を共通の定義フォーマットで表現します。

例えば、ツール呼び出しは以下のような JSON-RPC 形式で記述されます。

MCP(Model Context Protocol)

{
  "jsonrpc": "2.0",
  "id": "2",
  "method": "tools/call",
  "parent": {
    "name": "get_weather",
    "arguments": {
      "location": "New York"
    }
  }
}

このようにツール呼び出しの形式が統一されることで、

LLMごとに異なるツール呼び出し仕様を意識する必要がなくなる
外部ツール側は、MCPの仕様だけを実装すればよくなる

という関係が成り立ちます。

その結果、外部ツールやAPIの仕様を共通のフォーマットで管理でき、
AIエージェントは複数の外部ツールを一貫した方法で利用できるようになります。

MCPのアーキテクチャ

⁴MCPは、生成AIアプリケーションと外部システムの間に、
役割を明確に分けたコンポーネント構成を持つアーキテクチャを採用しています。

MCPホスト
MCPクライアント
MCPサーバー

役割を分けて設計することで、LLMは外部ツールの実装を意識せずに利用できるようになります。

MCPホスト

MCPホストは、生成AIモデルを搭載したアプリケーション本体です。

例としては、Claude Desktop や Cursor などが挙げられます。
ホストは、MCPクライアントを生成・管理し、ユーザーからの入力をもとに
どのツールやサーバーを利用するかを判断します。

また、ホスト側では以下のような役割を担います。

MCPクライアントの生成・管理
ユーザー認証やアクセス権限のチェック
利用するスキルやMCPサーバーの選択

MCPクライアント

MCPクライアントは、MCPホストとMCPサーバーをつなぐ通信役です。

クライアントはサーバーとの接続を確立し、利用可能なツールやリソース、プロンプトといった機能を確認します。

その上で、ホストからの指示に従って、

ツール呼び出しやデータ取得のリクエストを送信
サーバーからのレスポンスを受け取り、ホストに返却

といった処理を行います。

MCPサーバー

MCPサーバーは、外部システムとの実際のやり取りを担うコンポーネントです。

APIやデータベース、ファイルシステムなどにアクセスし、取得した結果を JSON形式でMCPクライアントに返します。

全体の流れ

全体の処理の流れは以下のような流れで進みます。

1. ユーザー操作を受けて、MCPホストが処理を開始
2. MCPクライアントがMCPサーバーにリクエストを送信
3. MCPサーバーが外部ツールやデータソースにアクセス
4. 結果をJSON形式でクライアントに返却
5. クライアントが結果をホストに渡し、LLMの推論に利用

このようにMCPでは、
**「生成AIアプリケーション」「通信」「外部システム」**の責務を明確に分離することで、拡張性と再利用性の高いアーキテクチャを実現しています。

技術仕様

⁵JSON-RPC 2.0を採用
JSON形式でリクエスト＆レスポンスを行う

種類	向き	応答の有無	用途
Request	クライアント → サーバー	あり	データ取得や操作の依頼
Response	サーバー → クライアント	Requestへの応答	結果の返却
Notification	クライアント → サーバー / サーバー → クライアント	なし	状態変化やイベントの知らせ(セッションの終了など)

接続方式（Transports）

MCP では JSON‑RPC 2.0 を共通のメッセージ形式として採用するだけでなく、
複数の Transport（接続方式） が標準で規定されています。

接続方式	説明
stdio	標準入出力（stdin/stdout）を使ってクライアントとサーバー間で JSON‑RPC メッセージをやり取りする方式。ローカルプロセス間の高速通信に適する。
Streamable HTTP	HTTP POST/GET を使う通信方式。サーバーは単一の MCP エンドポイントを持ち、必要に応じて Server‑Sent Events（SSE）によるストリーミングも可能。

また、必要に応じて JSON‑RPC を保った カスタム Transport の実装 も許容されます。
MCPの仕様では標準的に上記のtransportをサポートすることが推奨されています。

MCPの3つの機能

⁶MCPでは、LLMが外部とやり取りするための機能をResources / Tools / Prompts の3つに整理しています。

それぞれ役割が異なり、用途に応じて使い分けます。

1.Resources（リソース）

Resources は、AIモデルが参照できるデータやコンテンツを提供する仕組みです。
主に、LLMが文脈として読み取る情報を扱います。

具体例（ローカルフォルダに資料を置く場合）
C:\project_docs（Windows）や/Users/username/project_docs（Mac）など任意の場所に作成しフォルダを作成し、Markdownやテキストファイルを置く。

project_docs/
 ├─ 業務仕様.md
 └─ API設計.md

MCPの管理画面でフォルダをResourceとして登録すると、LLMはそのフォルダ内のファイルを参照できるようになります。

LLMはこれらの情報を読み取り、回答生成や推論の材料として利用します。

2. Prompts（プロンプト）

Promptsは、LLMに与える指示文のテンプレートです。
LLMに「何をどう考えてほしいか」「どんな形式で出力してほしいか」をあらかじめ定義しておくことで、やり取りを安定させ、再利用することができます。

具体例（Markdown形式での要約生成）

下記のように、Promptsを設定しておくことで、毎回初心者向けの形式で要約を生成する事が出来ます。

"以下の文章を初心者向けにわかりやすく要約してください。
出力はMarkdown形式で、見出しと箇条書きを必ず含めてください。"

Prompts を共通化することで、LLMの振る舞いを一定に保ちやすくなります。

3.Tools（ツール）

Tools は、単純なテキスト生成だけでは対応できない処理を行うための機能です。
外部システムと実際にやり取りする必要がある場合に使用されます。

具体例（ファイルの更新・追記）
Resourceとして登録したproject_docs/業務仕様.mdの内容を参照し、LLMが要約を作成した後、その結果をToolsを使ってproject_docs/業務仕様_要約.mdに書き込むことが出来ます。

project_docs/
 ├─ 業務仕様.md
 ├─ 業務仕様_要約.md　　← Toolsで自動生成されたMarkdown
 └─ API設計.md

このように、Toolsは LLMが内部だけでは持っていない情報や機能にアクセスし、実際の処理を外部で実行する手段となります。

3つの機能まとめ

1. Resource：参照する情報を提供
例：Resourceとして登録したproject_docs/業務仕様.mdの内容を読み込む

2. Prompts：処理内容や出力形式をテンプレートとして定義
例：初心者向けに分かりやすいMarkdown形式で、見出しと箇条書きを含めて要約する指示を定義する

3. Tools：外部操作を実行
例：生成した要約を project_docs/業務仕様_要約.mdに書き込む

このように役割を分けることで、MCPは柔軟で拡張しやすい外部連携を実現しています。

まとめ

MCPは、LLMと外部システムをつなぐための共通プロトコルです。
これまでAPIやツールごとに分かれていた仕様や実装の違いを、統一された仕組みとして整理・共通化します。

その結果、開発者はLLMごとに異なるツール呼び出し形式や接続設定を意識する必要がなくなり、共通のインターフェースを通してツールやデータソースを扱えるようになるのです。

また、MCPでは Resources / Tools / Prompts という役割分担により、LLMの推論と外部連携の分担が明確になります。
これにより、AIアプリケーションの拡張や保守もしやすくなります。

今後、複数のLLMや多様な外部ツールを組み合わせて利用する場面が増える中で、
MCPはLLM連携の土台となるプロトコルとして重要な役割を担っていくと考えられています。

参考文献

本記事は以下の公式ドキュメントなどを情報源に執筆しています。

MCP (Model Context Protocol) 公式リソース

¹MCP (Model Context Protocol)とは何か
URL：https://modelcontextprotocol.io/docs/getting-started/intro

⁴アーキテクチャの概要
URL：https://modelcontextprotocol.io/docs/learn/architecture

⁵接続方式
URL：https://modelcontextprotocol.io/specification/2025-11-25/basic/transports

⁶サーバー機能/概要
URL：https://modelcontextprotocol.io/specification/2025-11-25/server

Zennの記事

³なぜ MCP がこれほどまでに革命的なのか？
URL：https://zenn.dev/zamis/articles/73fe4c6e9f289e

その他

²MCPのUSB-Cポートへの例え
URL：https://zhuanlan.zhihu.com/p/29301066811

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up