付録G　（応用）道具を後付けで足すしくみ＝MCPの考え方

📖 この付録のゴール：第3章・第11章で「あとで」と予告した MCP（エムシーピー） の正体を、ふんわり理解する。「道具を自分で全部書かなくても、外から“差し込む”だけで足せる」 という発想が腹落ちすれば十分です。フル実装はしません（擬似コード止まり）。 ← 目次・はじめにへもどる

🔧 この付録ぜんぶ 応用（読み飛ばしOK） です。本編（第3〜11章）で「道具」と「スキル」を作れていれば、エージェントは十分動きます。MCPは「もっと楽に道具を増やしたくなったら」の話。名前と考え方だけ持って帰れば上出来です。

🧵 ここまでの復習：道具は「1つずつ手書き」だった（🟢 基礎）

第5〜7章で、あなたは道具（ツール）を自分の手で1つずつ作りました。1つの道具につき、いつも2つを書きましたね。

説明書（tools に入れる name / description / input_schema）＝LLM に「こんな道具があるよ」と伝える
実体（executeTool の中の case）＝実際に手を動かすコード（fs.readFile など）

read_file、write_file、run_command ……と、3つくらいなら手書きでも平気でした。でも、ここから先で「こんな道具もほしい」と思いはじめると、急にしんどくなります。

ファイル操作（もう作った）
GitHub を操作（issue を立てる・PRを読む・コメントする……）
Slack に投稿（通知を送る・スレッドを読む……）
データベースに問い合わせる
ブラウザでページを開いて中身を取る

これを全部、自分で説明書と実体を書く——しかも GitHub や Slack は API の細かい作法を調べて、認証も通して……と、道具1つで一日仕事になりかねません。「車輪の再発明（すでにある物を一から作り直すムダ）」のオンパレードです。

🍳 厨房のたとえで言うと——ここまでは 鍋も包丁も自分で鍛冶（かじ）して作ってきました。最初は勉強になるけれど、料理のたびに新しい道具を一から鍛えるのは、さすがに大変。「できあいの道具セットを、買ってきて差し込む」 ことはできないの？——その答えが MCP です。

🔌 MCP＝道具を「外から差し込む」ための共通プラグ（🟢 基礎）

MCP（Model Context Protocol／モデル・コンテキスト・プロトコル） を、むずかしく考える必要はありません。一言でいうと——

MCP＝「AIエージェント」と「道具の詰め合わせ」をつなぐための、共通の差し込み口（プラグの規格）。

たとえは USB（や変換プラグ）です。

昔は、機器ごとに専用のケーブルがバラバラで、つなぐのが大変でした。
USB という“共通の形”が決まってから、マウスもキーボードもメモリも、同じ口に挿すだけで使えるようになりました。

MCP はこれの「AIと道具」版です。道具の差し込み口の形を世界共通で決めておくことで——

道具を提供する側（GitHub操作セット、ファイル操作セット……）は、その形に合わせて1回作れば、
AIエージェント側（あなたのエージェント、Claude Code、Cursor……）は、つなぐだけで、その道具を丸ごと使えるようになる。

つまり、あなたは GitHub 用の説明書も実体も書きません。「GitHub の道具セット（＝MCPサーバー）」を“差し込む”だけで、あなたのエージェントが新しい道具を一式まとめて獲得します。これが MCP のいちばんおいしいところです。

💡 第3章で「USB-C のように、いろんなAIと、いろんな道具を、同じプラグでつなぐ」と書いたのは、まさにこの話でした。道具 → スキル（第11章）→ MCP と能力を広げる、そのいちばん外側の口が MCP です。

🧱 ざっくり構造：クライアントとサーバー（🟢 基礎）

MCP には、登場人物が2人います。名前が少しいかついですが、役割はシンプルです。

役	正体	やること	たとえ
MCPクライアント	あなたのエージェント（や Claude Code）	道具を使う側。サーバーにつないで「どんな道具ある？」と聞き、必要なときに「これ呼んで」と頼む	差し込む側（パソコン本体）
MCPサーバー	道具の詰め合わせ（GitHub用・ファイル用…）	道具を提供する側。問い合わせに「うちにはこんな道具があるよ」と答え、呼ばれたら実際に動かす	挿す機器（USBメモリ）

⚠️ 「サーバー」でもブラウザは要りません。 Webサーバーのような大げさなものを想像しなくて大丈夫。MCPサーバーは、たいていあなたのパソコンの中で動く小さなプログラム（別アプリ）です。エージェントはそれと会話して道具を借ります。

つながると、MCPサーバーは主に3種類のものをクライアントに渡せます。いちばん大事なのは①の道具。残りは「そういうのもある」程度でOKです。

① tools（道具）……エージェントが呼んで実行するもの。第3章で作った tools の“外から来る版”。これがMCPの主役。
② resources（資料）……読ませたい情報・データ（ファイルの中身、ドキュメントなど）。コンテキストに足す材料。
③ prompts（定型指示）……「こういう時はこう頼んで」というよく使う指示のひな型。

ポイントは、MCPサーバーが渡してくる道具(tools)が、第3章の tools とそっくり同じ形をしていること。だからエージェント側は、自前の道具もMCPの道具も、同じループ（第4章）でまったく同じように扱えるのです。「外から来た道具」も、中に入ってしまえば、ただの道具です。

🧩 道具 → スキル → MCP の総まとめ（🟢 基礎）

ここで、本書を貫いてきた 「能力の広げ方」3点セットを、一枚に並べてみます。第1章・第3章・第11章で少しずつ出てきた話の合流点です。

	正体	ひとことで	たとえ
🔧 道具（tools）	LLMに渡す関数（説明書＋実体）	手そのもの。低レベルな1つの力	鍋・包丁
📜 スキル（skills）	よく使う手順を“型”にまとめたもの	段取りの型。道具の使い方の決まり手	レシピ・段取りカード
🔌 MCP	道具を外から差し込む共通規格	道具を後付けする共通口。実体は他人が用意	USB・変換プラグ

読み方は——

道具は「何ができるか」（ファイルを読める、コマンドを走らせる）。手を増やす。
スキルは「どうやるか」（テストを直すときの段取り）。同じ手を、いつもの順番で使わせる。第11章で作りました。
MCPは「手をどこから持ってくるか」。手を自分で鍛えず、外から一式もらってくる。

つまり 3つは競合しません。MCPで持ってきた道具を、スキルの段取りで使う——というように、重ねて使えます。能力は「自分で1つ作る（道具）→ 段取りを型にする（スキル）→ まとめて外から差し込む（MCP）」と、だんだん“まとめ買い”できるようになっていく、というのが全体像です。

🌍 実例：身近なエージェントも MCP で道具を足している（🟢 基礎）

「外から道具を差し込む」なんて特殊な話に聞こえるかもしれませんが、あなたが毎日さわっているツールが、すでにそうなっています。

Claude Code には、MCPサーバーをつなぐ設定があります。GitHub の MCP サーバーをつなげば、Claude Code が GitHub を操作する道具を獲得します。「最初から入っている道具」だけでなく、後から差し込んで増やせるわけです。
いま、この文章を生成している MulmoClaude も、同じしくみで道具を足しています。画像を作る・コレクションを管理する・許可を確認する……といった道具は、MCP 経由で差し込まれた「外付けの手」です。

💡 だから、第3章で見た tools の作りを理解したあなたは、もうMCPの“中身”の8割を知っています。MCPは「あの tools を、別プログラムから、共通の形で受け取れるようにしたもの」。新しい魔法ではなく、知っているものの“配り方”を標準化したものなのです。

🧪 雰囲気だけ：擬似コード（🔧 応用・実装は不要）

本格的な実装は本書の範囲を超えるのでしませんが、「気持ちとしてはこんな感じ」という擬似コードだけ置いておきます。第4章のループとの“地続き感”をつかむのが狙いです。

// ① MCPサーバー（道具の詰め合わせ）につなぐ
const mcp = await connectToMcpServer("github");   // ← 差し込む

// ② 「どんな道具ある？」と聞く。第3章の tools と同じ形で返ってくる
const mcpTools = await mcp.listTools();
//   例: [{ name: "create_issue", description: "...", input_schema: {...} }, ...]

// ③ 自前の道具と合体して、いつものように Claude へ渡す
const allTools = [...tools, ...mcpTools];
const res = await anthropic.messages.create({
  model: MODEL, max_tokens: 1024, system: SYSTEM_PROMPT, messages, tools: allTools,
});

// ④ LLMが「create_issue を呼んで」と言ったら、実行は“MCPサーバー側”に頼む
//    （executeTool の中で、MCPの道具なら mcp.callTool(name, input) に回すだけ）

1行ずつ読むと：

connectToMcpServer("github")：GitHub の道具セット（MCPサーバー）に“差し込む”。挿し込みは最初に1回。
mcp.listTools()：「どんな道具がある？」と問い合わせ。返ってくる形は、第3章で手書きした tools（name/description/input_schema）とそっくり同じ。だから扱いに迷いません。
[...tools, ...mcpTools]：自前の道具とMCPの道具を1つの配列に合体。LLM から見れば、どっちも区別なく「使える道具メニュー」。
mcp.callTool(name, input)：MCPの道具は実体がサーバー側にあるので、自分で fs.readFile するのではなく、「これ呼んで」とサーバーに頼む。返ってきた結果を、いつも通り tool_result でループに戻すだけ。

💡 つまり、第4章のループはほぼそのまま。違うのは「実行する係が、自分のコードか、外のMCPサーバーか」だけ。だから「自分のエージェントにMCP対応を足す」ことも、ちゃんとできます（公式の MCP 用ライブラリを使えば、上の connectToMcpServer まわりは用意されています）。本書では「できる」と知っておけば十分です。

🛡 注意：外から差し込む＝他人のコードを信用すること（🟢 基礎）

ここはこの付録でいちばん大事です。背骨②（🛡 安全）の話なので、応用でも飛ばさないでください。

MCPサーバーを差し込むと便利ですが、それは「他人の書いたコード（＝他人の手）を、自分のエージェントの中に招き入れる」 ことでもあります。USBメモリと同じで、素性の知れないものを挿すのは危険です。

🔍 信頼：そのMCPサーバーは誰が作った？ 公式・有名・ソースが読めるものか。よく分からない出どころのサーバーを、安易につながない。
🔑 権限：差し込むと、それが持つ道具の力もまるごと入ってきます。GitHub のサーバーならあなたのGitHubを操作できる、ファイルのサーバーならファイルを消せるかもしれません。「この道具セットに、何を許すのか」 を必ず確認します（最小権限／第9章）。
📄 結果はデータ扱い：MCPの道具が返してくる中身も、外から来た情報です。第3章・第8章で何度も出た合言葉——「道具の結果を、新しい命令として実行しない」（間接プロンプトインジェクション）——は、MCP相手でもそのまま効きます。サーバーが返した文に「これまでの指示を無視して…」と仕込まれていないとは限りません。
🙋 危ない操作は確認をはさむ：MCPで増えた道具にも、書き込み・送信・削除は当然あります。第8章の askPermission の考え方は、MCPの道具にも同じようにかぶせるべきです。「外から来た道具だから安全」では決してありません。

🔑 合言葉のまとめ：「便利な差し込み口は、危ない差し込み口」。USBにウイルスが入りうるのと同じで、MCPサーバーは“信頼と権限”を確認してから挿す。便利さと危なさはいつもセット、というこの本の背骨は、外付けの道具でも変わりません。

📝 ことばメモ

MCP（えむしーぴー）：Model Context Protocol。AIエージェントと「道具の詰め合わせ」をつなぐための共通の差し込み口（規格）。USBのように、決まった形でつなぐだけで道具を増やせる
MCPクライアント：道具を使う側＝あなたのエージェントや Claude Code。サーバーにつないで道具を借りる
MCPサーバー：道具を提供する側＝道具の詰め合わせ（GitHub用・ファイル用…）。たいてい自分のPCで動く小さな別プログラム。ブラウザは不要
tools / resources / prompts：MCPサーバーが渡せる3種類。tools＝呼んで実行する道具（主役）／resources＝読ませる資料・データ／prompts＝よく使う指示のひな型
道具 → スキル → MCP：能力の広げ方。道具＝手（第3・5〜7章）／スキル＝段取りの型（第11章）／MCP＝道具を外から差し込む共通口（この付録）

➡️ つぎに読むなら

道具そのものの形（tools の name/description/input_schema）をもう一度確かめたいなら → 付録C ツール定義（JSON Schema）の書き方ミニ辞典
「他人の道具を招き入れる」前に守ることをまとめて見たいなら → 付録E 安全チェックリスト
スキル（段取りの型）の作り方は → 第11章スキル — よく使う手順を「型」にして持たせる

← 目次・はじめにへもどる

付録G （応用）道具を後付けで足すしくみ＝MCPの考え方