MCPの真髄【シリーズ１】─もう“使ってるだけ”では差がつかない！
🎯 このシリーズのゴール🎯
「なぜ MCP が必要なの？」 この質問に自信を持って答えられるようになる。
**対象者：**MCPを何かしらのツールで使ったことがある方
取り扱わない内容：~のMCP使ってみたのような具体例
MCP初心者の方用のコンテンツは今後用意する予定です、、、
はじめにーまずは“問い”を掲げる
『そもそも、、、Web標準が進んだ世界でなぜMCPなのか？』
この問いに即答できれば、もはや本シリーズを読み進める必要はないかもしれません。LLM標準を掲げるMCPがなぜ必要なのか、どのような思想でどのような構造になっているのか、、、
一応公式ページでは以下のように説明があります。
モデルコンテキストプロトコル（MCP）は、LLMアプリケーションと外部データソースおよびツールとのシームレスな統合を可能にするオープンプロトコル
しかし多くの開発現場では、まだ "なんか便利そうだからとりあえず使っている" 段階――本記事ではそんな状態から一歩抜け出すための **MCP 構造理解 （ステップ1）**にフォーカスします。
本来であれば以下の順で説明します
- LLMを使う上でWeb標準では課題があった
- MCPを作ることで解決
ですが、このMCPシリーズでは以下の逆順のアプローチで進めます
- MCP の概要/構成 ← 本記事で扱う範囲
- まず全体地図を掴む （5 Capability と各層分離）
- MCP の詳細設計 ← 次回
- 各 Capability ？が具体的にどう通信／処理するか
- MCP の存在意義 ← 次々回
- 従来 Web 標準では解決しづらい課題と MCP の利点。1・2 を踏まえ
（シリーズはもう少し分割されたり増えたりするかもしれません、、、）
では**"使っているだけ"**から卒業ための基本構造の理解を進めましょう
基本概念
MCPの基本概念は以下のような構成になっています
ホスト: 接続を開始するLLMアプリケーション（Claude DesktopやIDE等） クライアント: ホストアプリケーション内でサーバーと1:1の接続を維持 サーバー: クライアントに「コンテキスト、ツール、プロンプト」を提供https://modelcontextprotocol.io/docs/concepts/architecture#overview
ホスト
Claudeから始まりCursorや他IDEなどのこと
2024年冬までとは違いClaude以外にも使えるアプリケーションが増えてきたためホストはイメージしやすくなったかと思います。最近であればCursorなどで使えるようになったことで少し話題になりました。
クライアント
Cursor や Claude アプリに内蔵された小さなプロセス／ライブラリ
Claude DesktopやCursorのHostでユーザーが「サーバーを接続」ボタンを押したりすると、裏で自動でHost が新しい Client を生成してその Server と 1 : 1 で繋げます（以下Cursorにおける登録例）
画像1Cursorにおいてはこの裏で自動で生成されているプロセスがClient
サーバー
LLM が必要とする**「データ・テンプレ・アクション」**を実装して渡す バックエンド
例：公式でもドキュメントで登場するweather-serverや公式がサーバーを公開しているgithub, LINE等々
画像1ではweatherがそれに当たります。(公式で紹介されている。https://www.weather.gov/のapiを使ったサーバー)
アーキテクチャ
図1は公式で紹介されているこれらを図示したのものです。
新しくホスト、クライアント、サーバー以外にトランスポートなるものが出てきています。
図1MCPのアーキテクチャhttps://modelcontextprotocol.io/docs/concepts/architecture#overviewより
これを少々詳しく書くと図2ようになります。
（点線は実線の上でやりとりされていることを表しています）
図2MCPアーキテクチャ図（点線は実線の上でやりとりされていることを表しています）
新たにホスト、クライアント、サーバー以外に3つ登場しています
- プロトコル
- トランスポート
- コンテキスト、ツール、プロンプト
大外の箱であるホスト、クライアント、サーバーはなんとなくわかったかと思いますので、これから上記の3つについて説明していきます。
プロトコル / トランスポート / Capability の詳細
ここからはMCPの基本概念の詳細（先ほど出てきた3つ）を個別に掘り下げていきます。
MCPの基本概念の詳細は以下のような構成になっています
- **プロトコル：**JSON‑RPC 2.0 の心臓部 — メッセージのフレーミングと ID マッチングを担当
- トランスポート： I/O の実線 — Stdio / HTTP+SSE / WebSocket など物理経路
- **キャパビリティ：**LLM が触れる 5 つのプリミティブ — Roots / Resources / Prompts / Tools / Sampling
これが全てです、といっても過言ではありません。
1. プロトコル
**Protocol Layer ― JSON‑RPC 2.0 の心臓部。メッセージのフレーミング、リクエスト／レスポンスの対応付け などの高レベル通信パターンを処理します。（つまり誰でも使えるようにメッセージを整形し、相手と正しくやり取りできるようにする役割）**MCP SDK では、この役割を Protocol クラスが担います。（詳細が気になる人→JSON-RPCの仕様スキーマ、MCPが着想をえた言語サーバープロトコル）
1.1 JSON‑RPC 2.0 とは？ （気になる人だけでOK）
JSON‑RPC 2.0 は 軽量なリモートプロシージャコール (RPC) プロトコル で、メッセージをすべて JSON オブジェクトで表現します。
- メッセージ型 … Request / Response (Result | Error) / Notification の 3 種。
- 必須フィールド
- Request … jsonrpc:"2.0", method, id は省略可（省略すると Notification 扱い）
- Response … jsonrpc:"2.0", id, result または error
- 双方向 … クライアント・サーバーどちらからでも request/notification を送信可。
- バッチ … 複数リクエストを配列で一括送信 → 並列処理が可能。
この仕様のおかげで 言語・トランスポート非依存 かつ実装がシンプルになり、MCP でも Stdio/HTTP/WebSocket すべてで共通フレーミングとして採用されています（詳細は https://www.jsonrpc.org/specification 参照）。
2. トランスポート
Transport Layer**： I/O 実装**（JSON でシリアライズされたパケット をバイト列として情報を運ぶ）
公式ドキュメントには以下の文言があります
All transports use JSON-RPC 2.0 to exchange messageshttps://modelcontextprotocol.io/docs/concepts/architecture#transport-layer
直訳すると以下のようになります
すべてのトランスポートはJSON-RPC 2.0を使用してメッセージを交換
ただ、Transport 層は “バイト列を運ぶだけ” が責務で、JSON‑RPC 2.0 を解釈しません。 ただし MCP の設計ポリシー として「Protocol 層が生成するメッセージは必ず JSON‑RPC 2.0 形式」と決められているため、
結果として どの Transport でも JSON‑RPC フレームが流れる
という前提があるだけです
とにもかくにも、トランスポート層は"情報が流れるものであればなんでも良い"わけです
ただし MCP では実装ガイドとして次の 2 方式を推奨しています。（互換ライブラリやドキュメントもこれらを前提に整備されています。）
- ローカル: Stdio — **“とりあえず手元で動かす”**ときに一番お手軽。標準入出力をつなぐだけなので設定ゼロで即起動します。
- リモート: HTTP + SSE — **“クラウドに常駐”**させたいときの定番。HTTPS が使えてプロキシ越えもしやすく、FaaS でもそのまま動きます。
3.キャパビリティ
（今回は簡素な説明で終わります。次回シリーズ2で詳細に説明予定）
**Capability ：**Server/Client がどんなことを できる(ability) かを自己申告する JSON スコープ宣言 。
サーバー ⇆ クライアント間で**LLM が触れる 5 つのプリミティブ（表1）**が存在します。5 つのプリミティブはそれぞれの以下のような役割を担います
| 種類 | 向き | ひと言 | 主エンドポイント | 代表ユースケース |
|---|---|---|---|---|
| Roots | Client ⇒ Server | 「ここだけ読めるよ」 | rootsChanged |
IDE がプロジェクトルートを宣言 |
| Resources | Server ⇒ Client | ファイル・DB 行など実データ | resources/list / resources/read |
コードとログを LLM に渡す |
| Prompts | Server ⇒ Client | 再利用プロンプトテンプレ | prompts/list / prompts/get |
/git-commit コマンドで diff 要約 |
| Tools | Server ⇒ Client | 外部 API／副作用アクション | tools/list / tools/call |
get_forecast で天気 API 呼び出し |
| Sampling | Client ⇒ Server | LLM への再帰質問許可 | sampling/createMessage |
ツールチェーン中に追加回答が必要 |
表1LLM が触れる 5 つのプリミティブと役割
- 3つ (Resources / Prompts / Tools) = Server Capability — バックエンドが実装
- 2つ (Roots / Sampling) = Client Capability — Host / Client が実装
もう少しCapabilityの構成の説明を追加すると以下のようになります
- 抽象化レイヤ … RPC メソッドを名前空間ごとに束ねた “機能モジュール”。
- 拡張ポイント … キーを 1 つ追加するだけで、新しい機能を非破壊でプラグイン可能。
- 相互運用の単位 … Client と Server が initialize ハンドシェイクで Capability 一覧を交換し、互いに未知のキーは無視できる設計。
これらを組み合わせることで 『どのデータを読み』『どのテンプレを使い』『どの外部アクションを自動実行し』『不足すればモデルに再質問する』 という一連のワークフローを安全・再利用可能に定義できます。
Tips： 以前は Server が提供するもの を「コンテキスト・ツール・プロンプト」の 3 語で説明していた気がします（2025年/4月時点での公式ドキュメントにも記載がある） 正規のCapability としては 5 分類（Roots / Resources / Prompts / Tools / Sampling）とされています。古いドキュメントや今のドキュメントに「Context」という語が存在していたら Roots と Resources を指すと考えていますが定かではありません。
Connection Lifecycle ─ 初期化から終了まで
これまでの内容が大まかにわかることでライフサイクルが理解できます。「Transport でバイト列が流れ、Protocol が JSON‑RPC 2.0 を整形し、Capability 一覧がそろった」
その直後に走る 実運用への“起動儀式” が Connection Lifecycle (図3)です。
図3initializaionのフローhttps://modelcontextprotocol.io/docs/concepts/architecture#1-initialization より
initialize request「条件提示」 Client が 自分のプロトコル・バージョン と Client‑side Capability を提示
initialize response「条件確認」 Server が 対応プロトコル・バージョン と Server‑side Capability を提示
initialized notification「合致宣言」 Handshake 成功を示す initialized 通知
3 メッセージは 「条件提示」→「条件確認」→「合致宣言」 という直列フローになっています。**すべて通過すると “Connection ready for use”**＝通常メッセージ交換フェーズへ遷移します。
まとめ
Host / Client / Server の基本三役で役割分担 **・**Host＝LLMアプリ本体｜Client＝1 : 1 アダプタ｜Server＝データ・テンプレ・アクション提供
Protocol：JSON‑RPC 2.0 の形に整形（フレーミング & ID マッチ）
Transport：情報が流す（推奨：ローカル＝Stdio、リモート＝HTTP+SSE）
**Capability：抽象化レイヤ・拡張ポイント・相互運用単位・LLM が触る 5 プリミティブ Roots / Resources / Prompts / Tools / SamplingConnection Lifecycle：3 メッセージで確認交換→通常運転・**initialize → initialized → Connection ready for use
次回予告
シリーズ②：MCP 詳細設計Roots / Resources / Prompts / Tools / Samplingとは？各 Capability のメソッド設計・サブスクリプション・ストリーミング制御 をコードも含め深掘りします