図解
はじめに
MCP サーバーを入れた。設定ファイルに書いて、再起動して、動いた。
そこで聞かれます。「で、何ができるようになったんですか」。
答えに詰まったことはないでしょうか。 ツールが増えた、とは言える。でもそれが何を意味するのかは、うまく言えない。
原因は、たぶん読む順番です。多くの解説は「何をつなげるか」から入ります。GitHub につなぐ、Slack につなぐ、データベースにつなぐ。
けれど 公式仕様 が構成要素を分けている軸は、そこではありません。誰が主導権を持つかです。
この記事では、公式が定める構成要素を数え上げ、その1本の軸で整理します。
この記事で扱うこと
- 登場人物 — 「サーバー」という言葉が作る誤解
- 公式が定める構成要素はいくつあるのか
- 選ぶ基準は「誰が主導権を持つか」
- Tools と Resources — いちばん間違えるところ
- 2026-07-28 で作り替えられたもの
- MCP が実際にやっていること
🧩 登場人物 — 「サーバー」が最初の壁
構成要素の前に、言葉を1つ片付けます。MCP の「サーバー」は、場所の話ではありません。
登場人物は3つです。
| 名前 | 役割 |
|---|---|
| MCP ホスト | Claude Code や VS Code などの AI アプリ本体 |
| MCP クライアント | 1つのサーバーとの接続を保つ部品。ホストが接続先ごとに1つ作る |
| MCP サーバー | クライアントに文脈を渡すプログラム |
この図で、ホストの中にクライアントが複数いるところが要点です。接続先が3つあれば、クライアントも3つ生まれます。
そして、公式はこう書いています。
Note that MCP server refers to the program that serves context data, regardless of where it runs.
（MCP サーバーとは文脈データを供給するプログラムを指す。どこで動いているかは問わない）
手元の PC で動く filesystem サーバーも、Sentry のクラウドで動くサーバーも、等しく「サーバー」です。
ここが腹に落ちると、あとの話が読みやすくなります。
🗺️ 何を渡せるのか — 公式が定める構成要素
本題です。MCP が定める構成要素（プリミティブ）を数え上げます。
サーバー側が公開できるものは3つです。
| 構成要素 | 中身 |
|---|---|
| Tools | AI が呼び出して実行する関数。ファイル操作、API 呼び出し、DB 更新 |
| Resources | 文脈として渡す読み取り専用のデータ。ファイル内容、スキーマ、記録 |
| Prompts | やりとりを組み立てる再利用可能なテンプレート |
クライアント側が公開できるものは1つです。
| 構成要素 | 中身 |
|---|---|
| Elicitation | サーバーが利用者へ追加入力や確認を求める仕組み |
この図の左右の分かれ目が、公開する側の違いです。サーバーだけが渡すのではなく、クライアント側も差し出しています。
ここで注意が要ります。日本語の解説でよく見る Roots・Sampling・Logging は、2026-07-28 版で非推奨になりました。
Deprecate the Roots, Sampling, and Logging features. These features remain fully functional during the deprecation window but new implementations should not add support for them.
（Roots・Sampling・Logging を非推奨とする。非推奨期間のあいだ機能は完全に動作し続けるが、新規の実装はこれらに対応を追加すべきではない）
いま数えるべきは、サーバー側3つとクライアント側1つ。合計4つです。
⚖️ 選ぶ基準は「誰が主導権を持つか」
ここがこの記事の中心です。3つをどう使い分けるのか。
公式ドキュメントには、そのものずばりの列があります。「Who controls it」です。
| 構成要素 | 主導権を持つのは |
|---|---|
| Tools | モデル |
| Resources | アプリケーション |
| Prompts | 利用者 |
この図の3本のレーンが、そのまま使い分けの答えです。何をつなぐかではなく、誰が引き金を引くかで分かれています。
それぞれ、公式の言葉で確認します。
Tools are model-controlled, meaning AI models can discover and invoke them automatically.
（Tools はモデルが主導する。つまり AI モデルが自分で見つけ、自動的に呼び出せる）
モデルが勝手に呼ぶ。だから Tools には、呼ばれて困ることを置けません。
Resources are application-driven, giving them flexibility in how they retrieve, process, and present available context.
（Resources はアプリが主導する。取得・加工・提示の方法をアプリ側が自由に決められる）
アプリが選んで渡す。全部渡すか、検索して一部だけ渡すかは、アプリの判断です。
They are user-controlled, requiring explicit invocation rather than automatic triggering.
（Prompts は利用者が主導する。自動的に起動するのではなく、明示的な呼び出しを必要とする）
人が選ぶまで動かない。スラッシュコマンドの一覧に並ぶのが、この層です。
つまり判断はこう進みます。モデルに任せてよいなら Tools。アプリが選んで渡すなら Resources。人が選ぶまで動かしたくないなら Prompts。
🔀 Tools と Resources — いちばん間違えるところ
3つのうち、実装で必ず迷うのがこの2つです。
迷いは、こういう形で現れます。「社内文書を読ませたい」。これは Tools でしょうか、Resources でしょうか。
読むだけなら Resources です。ところが実際には、読み取りしかしないサーバーの機能が、3つとも Tools で書かれていることがあります。
理由は単純で、Tools のほうが実装例が多く、動かすのが早いからです。
この図の上下で変わっているのは、引き金を誰が引くかだけです。それだけで、動く回数も、止められるかどうかも変わります。
Tools にすると、モデルが必要と判断したときに呼ばれます。呼ばれる回数も、渡す条件も、モデル側が決めます。
Resources にすると、アプリが選んで渡します。何を渡すかを人間側の仕組みで決められます。
読み取りだから安全、ではありません。読み取りでも、社外秘の文書をモデルが自分の判断で引き込めるなら、それは制御を手放したということです。
**「動くかどうか」ではなく「誰が引き金を引くか」で選ぶ。**この記事で持ち帰ってほしいのは、ここです。
🧨 2026-07-28 で、中身が作り替えられた
もう1つ、押さえておくべきことがあります。MCP の仕様は、直近で大きく変わりました。
2026-07-28 版の変更点は、細かい修正ではありません。土台の作りが変わっています。
| 変わったこと | 前 | 後 |
|---|---|---|
| 状態の持ち方 | セッションを張る | ステートレス。毎回のリクエストに版と能力を載せる |
| 接続の開始 |
initialize ハンドシェイク |
削除。server/discover で能力を問い合わせる |
| 通知 | GET エンドポイントと resources/subscribe
|
subscriptions/listen に一本化。オプトイン
|
| サーバー起点の要求 | サーバーから要求を送る | MRTR。結果に input_required を返して再試行させる |
この図の左から右への矢印が、この1年で起きたことです。状態を持たない方向へ寄せられています。
公式の言い方はこうです。
Make MCP stateless: remove the
initialize/notifications/initializedhandshake. Every request now carries its protocol version and client capabilities in_meta.（MCP をステートレスにする。
initializeとnotifications/initializedのハンドシェイクを削除し、すべてのリクエストがプロトコル版とクライアントの能力を_metaに載せて運ぶ）
ping も logging/setLevel も消えました。HTTP+SSE トランスポートも非推奨です。
日本語の解説記事を読むときは、どの版の話かを確かめてください。 initialize を前提に書かれているものは、いま作るサーバーには当てはまりません。
🪜 MCP は、道具を増やす仕組みではなかった
ここまでを並べ直すと、見えてくるものがあります。
Tools・Resources・Prompts は、機能の分類ではありません。主導権の分類です。
そして 2026-07-28 の変更も、同じ方向を向いています。セッションを捨て、通知をオプトインにし、サーバー起点の要求をやめる。サーバー側が勝手に持てる状態と、勝手に起こせる動きを減らしています。
この図の縦線が、MCP が引いている線です。つなぐための規格ではなく、つないだあとに誰が何を決めるかを固定するための規格だと読めます。
公式自身、範囲をはっきり区切っています。
MCP focuses solely on the protocol for context exchange—it does not dictate how AI applications use LLMs or manage the provided context.
（MCP は**文脈をやりとりするプロトコルだけに専念する。**AI アプリが LLM をどう使うか、渡された文脈をどう管理するかには立ち入らない）
だから「MCP を入れれば賢くなる」は、期待の方向が違います。MCP が決めるのは、境界の引き方だけです。
📝 まとめ
3つに絞ります。
1つ目。数えるべきは4つ。 サーバー側が Tools・Resources・Prompts、クライアント側が Elicitation。Roots・Sampling・Logging は 2026-07-28 で非推奨になりました。
2つ目。分けている軸は主導権。 Tools はモデル、Resources はアプリ、Prompts は利用者。公式ドキュメントに「Who controls it」としてそのまま書かれています。
3つ目。仕様は動いている。 2026-07-28 でステートレス化され、initialize が消え、通知はオプトインになりました。古い記事は前提から違います。
明日いちばん先に試すことを1つ挙げるなら、これをおすすめします。
いま使っている MCP サーバーの機能を並べて、それぞれ「誰が引き金を引くか」を書き出してみてください。
全部が Tools になっていたら、そのサーバーは制御をモデルに預けきっています。それが妥当かどうかは、そこで初めて判断できます。
つなぐことが目的になると、この問いは出てきません。境界を引くための規格だと読み替えると、出てきます。
📚 参考
一次資料
- Architecture overview — 登場人物・レイヤ・構成要素の全体像
- Understanding MCP servers — 「Who controls it」の表はここ
- Key Changes（2026-07-28） — この版の変更点。本記事の数字と引用はここから
- MCP Specification — 仕様本体
💡 この記事について
本記事は2026年9月2日時点の公式ドキュメントをもとにまとめています。対象はプロトコル版 2026-07-28 です。英文の引用はすべて原典と照合しています。日本語訳は筆者によるもので、公式訳ではありません。
MCP の仕様は更新が速く、この記事の内容も版が変わると当てはまらなくなります。実装の前に必ず 最新版 を確認してください。
非推奨とされた機能は、非推奨期間のあいだは動作します。既存の実装がすぐ壊れるわけではありません。
エンジニアがAIを活用して次のレベルへ。上流はさらに上へ、下流は上流へ。
そのために何をするかを書いていきます。