第12章: MCP ─ プロトコルで外の世界とつながる
ある日のチームチャット。
「Claude Code から Gmail の下書きを書かせたい」 「Slack の特定チャンネルを Claude に読ませて要約 させたい」 「Chrome を Claude に操作させて、フォーム入力を自動化 したい」
要望は次々に出る。 全部を Claude Code 本体に組み込もうとすれば、本体は瞬く間に肥大化する。 しかも来年には Cursor や Cline でも同じことがやりたくなるはずだ。
ここで Anthropic が出した答えが、プロトコル だった。
12.1 そもそも、外の世界をどう繋ぐか
第2章で見たとおり、LLM はテキスト機械に過ぎず、外の世界に触るには 道具 (tool) が必要だ。 第1章では、Read / Write / Bash のような 本体に組み込まれた専用ツール で動くと書いた。
しかし、現実のエージェントが触りたい外の世界はあまりに広い。 Gmail、Slack、Notion、Google Drive、Chrome、社内 DB、freee、GitHub、Jira ── 数え始めるとキリがない。 これを 全部 Claude Code 本体に組み込む のは無理だし、組み込んでも他のエージェントでは使えない。
問題は「Claude Code にどう機能を足すか」ではない。 問題は「世界中のサービスと、世界中のエージェントを、どう繋ぐか」だ。
一対一で繋ごうとすると、エージェント × サービスの組み合わせ爆発が起きる。
ここで、ソフトウェア工学の古い知恵が顔を出す。 標準プロトコル だ。
12.2 プラグインではなく、プロトコルにする
ふつう「機能拡張」と聞くと、まず思い浮かぶのは プラグイン方式 だろう。 VSCode 拡張のように、ホストアプリが用意した API に合わせて、それぞれが拡張を書く。
これは一見便利だが、エージェント時代には致命的な弱点がある:
- Claude Code 用のプラグインは Cursor では動かない
- Cursor 用のプラグインは Cline では動かない
- 同じ Gmail 連携を、エージェントごとに何度も書き直す ことになる
そこで Anthropic が 2024 年末に公開したのが、MCP (Model Context Protocol) だ。
MCP (Model Context Protocol)Anthropic が 2024 年に公開した、エージェント ↔ 外部ツールの標準プロトコル。 一度サーバーを書けば、Claude Code / Cursor / Cline / その他対応エージェントから 共通の呼び出し方 で使える。
発想は HTTP と同じだ。 ブラウザを作る人、Web サーバを作る人、どちらも HTTP という共通の規約に従えば、任意のブラウザから任意のサーバに繋がる。 MCP は エージェント側の HTTP を目指したものと言っていい。
プラグインだと「Claude Code に Gmail を足す」になる。 プロトコルだと「Gmail を MCP サーバとして公開する」になる。
すると Claude Code も Cursor も Cline も、同じ Gmail サーバ に繋げる。 書く側も使う側も、組み合わせ爆発から解放される。これが標準化の威力だ。
12.3 MCP の登場人物 ── client と server
MCP の世界には、二人の登場人物がいる。
| 役者 | 役割 | 例 |
|---|---|---|
| MCP client | エージェント側。サーバを呼ぶ | Claude Code, Cursor, Cline |
| MCP server | 外部サービス側。機能を公開する | gmail-mcp, slack-mcp, chrome-devtools-mcp |
ユーザーから見ると、こうなる:
- MCP サーバを起動しておく（例:
gmail-mcpを立ち上げる） - Claude Code の設定ファイルに「この MCP サーバに繋いで」と書く
- Claude Code は起動時にサーバへ接続し、サーバが提供する機能の一覧 を受け取る
- その一覧を、LLM に「使える道具」として渡す
- 以降、LLM が「Gmail で下書きを作って」のような道具呼び出しを返すと、Claude Code が MCP サーバ経由で実際に Gmail を叩く
ポイントは、Claude Code 本体に Gmail のコードは 1 行も入っていない ことだ。
本体が知っているのは「MCP プロトコルの話し方」だけ。Gmail の知識は全部 gmail-mcp 側にある。
12.4 MCP server が提供できる三種 ── Tool / Resource / Prompt
MCP server は、client に対して三つの種類の「提供物」を公開できる。 この三種が MCP の表現力の核なので、ひとつずつ整理しよう。
Tool（関数呼び出し）
第2章の function calling とほぼ同じ仕組み。
「send_email(to, subject, body) という関数があります、引数はこういう形です」というスキーマを宣言し、LLM がそれを呼ぶ。
実行すると、サーバ側で本物の Gmail API が叩かれて、結果がテキストで返ってくる。 副作用のある操作 はここに入る。
Resource（読み取り専用データ）
URL のような識別子で参照できる、読み取り専用のスナップショット。
たとえば gmail://inbox/latest や drive://folder/abc123/files.json のような。
LLM が必要に応じて「このリソースをくれ」と要求すると、サーバが現在の中身を返す。 読むだけで、副作用がない情報 はここに入る。
Prompt（再利用可能なプロンプトテンプレート）
サーバ側が用意した、よく使うプロンプトの雛形。 たとえば freee MCP なら「先月の経費精算を集計して」のようなプロンプトを、引数つきで提供できる。
ユーザーが Claude Code 内でそのプロンプトを呼ぶと、雛形が展開されて LLM に渡る。 「使い方のテンプレート」をサーバが配る という発想だ。
Tool は「動詞」、Resource は「名詞」、Prompt は「定型句」。
サーバ作者は、提供したい機能を「これは副作用のある操作 (Tool)」「これは読むだけのデータ (Resource)」「これはよく使う呼び方 (Prompt)」と切り分けて公開する。
実装上は、Tool だけ提供する MCP server が圧倒的に多い。Resource と Prompt は、2026 年時点でも対応 client が限定的で、これから広がっていく領域だ。
12.5 接続方式 ── stdio / HTTP / SSE
MCP client と server は、3 つの方式で繋がる。
| 方式 | 特徴 | よく使われる場面 |
|---|---|---|
| stdio | 標準入出力で通信。client が server プロセスをサブプロセスとして起動 | ローカル開発、CLI ツール (chrome-devtools, playwright 等) |
| HTTP | 普通の HTTP リクエスト | リモートホストの MCP server に繋ぐ |
| SSE (Server-Sent Events) | HTTP の長期接続でサーバ側からイベントを push | 進捗通知や非同期処理 |
ローカルで MCP server を試すなら、まずは stdio 方式 が一番手軽だ。 コマンド 1 行で起動でき、Claude Code が必要なときに勝手にプロセスを立ち上げてくれる。
試しに、自分のマシンにインストール済みの MCP server 一覧を確認してみてほしい。
Claude Code で /mcp コマンドを打つと、現在繋がっているサーバの一覧が出る。
chrome-devtools, playwright, freee, gmail のような名前が並んでいるはずだ（第Ⅱ部のコマンド章 (グループ:「コマンド: 拡張機能」) で詳述）。
12.6 すでに豊かな MCP server エコシステム
MCP は 2024 年末に公開されてからまだ日が浅いが、すでに公式・有志合わせて数百のサーバが公開されている。 日常的によく見るものを並べると:
| MCP server | できること |
|---|---|
| chrome-devtools | Chrome の DevTools プロトコル経由で、ブラウザ操作・スクリーンショット・ネットワーク観察 |
| playwright | Playwright で本物のブラウザを動かして E2E テスト・スクレイピング |
| gmail / google-calendar / google-drive | Google サービスの読み書き |
| slack | Slack のチャンネル読み取り・メッセージ送信 |
| freee | 会計 SaaS の freee（会計 / 人事労務 / 請求書）API の呼び出し |
| github | issue / PR / release の読み書き |
| codex | OpenAI Codex CLI に作業を委譲（agent から agent を呼ぶ） |
これらを足すたびに、Claude Code の世界が一つずつ広がっていく。 自分で書くのもそう難しくない。Python や TypeScript の SDK が公開されており、関数を 1 個書いて MCP server として公開する だけのテンプレートが揃っている。
12.7 落とし穴 ── tool list 肥大化と context 圧迫
ここまで読むと、MCP server をたくさん足したくなるはずだ。 だが、ひとつ重要な落とし穴がある。
MCP server を増やすほど、LLM に渡す道具の一覧 (tool list) が膨らむ。 そして tool list は、第5章 (system prompt) で見たとおり、毎ターン system prompt の一部として LLM に送られる。
具体的に: 10 個の MCP server を有効にして、それぞれが平均 5 個の Tool を提供すると、tool list だけで 50 個の関数定義 が system prompt に乗る。 これは数千〜数万トークンを 毎ターン恒久的に占有する ことを意味し、第4章 (context window) の有限性を直撃する。
落とし穴MCP server は 「とりあえず全部入れる」より、必要なものだけ有効化する のが正解。 有効化したサーバは、たとえ一度も呼ばれなくても、起動中ずっと context を食い続けている。
/mcpコマンドで一覧を眺め、半年使ってないサーバは外す。これだけで体感速度が変わる。
12.8 MCP は「外の世界とつながる」だけの道具
最後に、本書全体の地図の中で MCP の位置づけを確認しておく。
MCP の役割は ひとつだけ だ ── エージェントを外部のサービスに接続する。 それ以上のことはしない。
逆に、次の章で扱う スキル / スラッシュコマンド は、外の世界に繋がる仕組みではなく、プロンプトと手順を再利用可能な部品にする ための仕組みだ。両者は補い合うが、解いている問題が違う。
MCP のすごさは、技術的なエレガンスより、標準化したことそのもの にある。 HTTP がなかったらブラウザは別々の独自プロトコルで Web サーバと喋っていただろうし、おそらく Web は今のようにスケールしなかった。
エージェント時代に MCP が同じ役割を果たせるかは、まだ歴史が決める。 だが少なくとも 2025〜2026 年の現時点では、MCP に対応しないエージェントは外の世界から切り離されたガラパゴス になりつつある ── それくらい標準として根付き始めている。
この章の振り返り
- MCP = Model Context Protocol。Anthropic が 2024 年に公開した、エージェント ↔ 外部ツールの標準プロトコル
- プラグインだと エージェント × サービス の組み合わせ爆発が起きるので、プロトコル化 で解決した
- 登場人物は MCP client (エージェント側) と MCP server (外部サービス側) の二者
- MCP server が提供する三種: Tool (副作用ある関数)、Resource (読み取り専用データ)、Prompt (テンプレート)
- 接続方式は stdio / HTTP / SSE の三種類。ローカル開発は stdio が手軽
- 既存サーバが豊富: chrome-devtools, playwright, gmail, slack, freee, github, codex …
- 落とし穴: サーバを増やすほど tool list が膨らみ、毎ターン system prompt を圧迫する
この章で読めるようになるツイート / ブログ
- 「Claude Code に Chrome 繋いだら開発体験が変わった」 → chrome-devtools MCP server を Claude Code に接続して、ブラウザ操作を LLM 経由で自動化した話と読める
- 「MCP server 入れすぎて context 食われてる、整理した」 → tool list 肥大化で system prompt が圧迫されていた問題に気づいて整理した、と即理解できる
- 「Cursor でも同じ MCP server がそのまま使えた、これがプロトコル化の威力」 → エージェント × サービスの組み合わせ爆発を、標準プロトコルで解決した、という MCP の核心が読める
次章は、MCP と対をなすもうひとつの拡張軸 ── スキルとスラッシュコマンド に踏み込む。 MCP が「外の世界とつなぐ」道具なら、スキルとコマンドは プロンプトと手順を部品にする 道具だ。