Model Context Protocol (MCP) 完全ガイド — Claude からツールと外部データを接続する標準

社内の Jira からチケットを引っ張ってきて、Postgres の在庫テーブルを読んで、GitHub に issue を切る — こうした雑用を Claude や Cursor に任せたくなった瞬間、エンジニアは必ず同じ壁にぶつかります。外の世界への接続をどう組むか、です。

Function calling でも対応できますが、ツールごとにプロンプトやスキーマを書き直し、エージェントごとに別の実装を書くことになります。新しいツールを足すたびに全エージェントを更新する、というコストが積み上がります。

MCP（Model Context Protocol） は、この層を標準化するために Anthropic が 2024 年 11 月に発表したプロトコルです。「AI エージェントが外部のツール・データ・プロンプトを使うときの共通言語」と考えると分かりやすいです。

本稿では MCP とは何か、なぜ必要か、どう動くか、どう自作するかを、Claude Code や MulmoTerminal との連携まで含めて 1 ページで整理します。

課題：AI エージェントに外の世界を触らせるのが毎回ゼロから

Function calling は便利だが、横展開しない

GPT や Claude の function calling / tool use は、エージェントに外部処理を呼ばせる仕組みとして広く使われています。JSON Schema でツールの仕様を宣言し、エージェントがそれを選んで引数を埋め、プラットフォームが実行する — というループです。

これで一通り動きます。でも、

同じツール（例：GitHub からの issue 取得）を、Claude 用・Codex 用・自作 CLI 用 — 3 回実装することになる
プロンプト定義、スキーマ定義、エラーハンドリング、認証 — すべてが各エージェント・各フレームワークに紐づいて散らばる
新しいツール（例：社内 Datadog）を追加したいとき、全エージェントに手を入れる

実際にチームで AI エージェントを運用し始めると、「ツールの実装・配布・権限管理」のオーバーヘッドが本題より重くなります。

MCP が解きたいのはそこ

MCP は、ツール側（MCP サーバー）と AI エージェント側（MCP クライアント）を分離します。

ツールの作者は MCP サーバーを 1 つ書けば、Claude / Cursor / Windsurf / Zed などすべてから使ってもらえる
エージェントの作者は MCP クライアント実装を 1 つ持てば、世の中の MCP サーバーすべてを取り込める

USB-C がデバイスとホストの関係を標準化したように、MCP が AI エージェントと外部処理の関係を標準化する、というのが Anthropic の主張です（公式ドキュメントでも USB-C の比喩が使われます）。

MCP の仕組み — 3 概念と 1 プロトコル

MCP は、JSON-RPC 2.0 の上に乗った軽量なプロトコルです。クライアント（AI エージェント側）とサーバー（ツール側）の間でメッセージが往復します。

3 つの主要な概念

概念	役割
Tools	エージェントが呼び出す関数。副作用あり。例: `send_message`, `create_issue`
Resources	エージェントが読み取るデータ。副作用なし。例: ファイル、API のレスポンス
Prompts	事前に用意されたテンプレート。ユーザーが選んで実行する再利用可能プロンプト

Function calling と比較すると、Tools はおおむね対応します。追加されたのが Resources（読み取り専用データの標準化）と Prompts（再利用プロンプトの共有）です。

伝送（Transport）

MCP サーバーとクライアントは、以下のいずれかの経路で通信します。

STDIO はサーバーをサブプロセスとして起動し、標準入出力で JSON-RPC をやり取りする方式で、ローカル実行の定番
SSE（Server-Sent Events）は HTTP の長期接続を使う方式で、リモートサーバー向け
Streamable HTTP（2025 年追加）は普通の HTTP リクエストを基本に、必要に応じて SSE に昇格する方式で、HTTP ベースの新しい定番

サーバーが提供するもの

MCP サーバーは起動すると、クライアントに対して「私はこういう Tools を提供する、こういう Resources を公開する、こういう Prompts を持っている」と宣言します。クライアント（Claude 等）はその一覧を見て、必要なものを LLM の文脈に含めたり、ユーザーに提示したりします。

既にある MCP サーバー 10 選

MCP が普及した大きな理由は、最初から使える既製サーバーが豊富だったことです。公式リポジトリと周辺コミュニティで、2026 年時点では数百のサーバーが公開されています。よく使われるものを 10 本:

サーバー	用途
`filesystem`	指定ディレクトリ配下のファイル読み書き
`git`	git リポジトリの操作
`github`	PR、issue、ワークフロー実行
`postgres` / `sqlite`	SQL 実行
`brave-search` / `tavily`	Web 検索
`playwright` / `puppeteer`	ブラウザ操作
`slack`	メッセージ送信・読み取り
`gmail` / `google-calendar`	メール・カレンダー
`linear` / `jira`	タスク管理
`memory` / `qdrant`	長期記憶・ベクトル検索

Claude Code のユーザーはすでにこれを使っている可能性があります。~/.config/claude/claude_desktop_config.json や ~/.claude/mcp.json に書き込むだけで、ターミナルの Claude が GitHub や Postgres を直接触れます。

自分で MCP サーバーを書いてみる — 最小例

公式 SDK は TypeScript / Python / Rust / Kotlin / C# など複数言語で提供されています。TypeScript 版が機能的には最先端です。

最小構成

// server.ts
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { CallToolRequestSchema, ListToolsRequestSchema } from "@modelcontextprotocol/sdk/types.js";

const server = new Server(
  { name: "hello-mcp", version: "0.1.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "greet",
      description: "Greet a person by name",
      inputSchema: {
        type: "object",
        properties: { name: { type: "string" } },
        required: ["name"],
      },
    },
  ],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === "greet") {
    const name = request.params.arguments?.name ?? "world";
    return { content: [{ type: "text", text: `Hello, ${name}!` }] };
  }
  throw new Error(`Unknown tool: ${request.params.name}`);
});

const transport = new StdioServerTransport();
await server.connect(transport);

これを node server.js で起動できる状態にして、Claude Code の設定に:

// ~/.claude/mcp.json
{
  "mcpServers": {
    "hello": {
      "command": "node",
      "args": ["/path/to/server.js"]
    }
  }
}

を書けば、Claude のセッションで greet ツールが使えるようになります。

実用的なサーバーに必要なもの

最小例を実用まで持っていくには、追加で次が必要です:

認証: サーバーが外部 API を叩くときの認証情報。環境変数で渡すのが現在の慣例
エラーハンドリング: ツール呼び出しの失敗を LLM に理解できる形で返す
ログ: console.error に書けば Claude 側のログに流れる（stdout は MCP メッセージ専用なので使ってはいけない）
型定義: inputSchema を厳格に書くと、LLM が引数を間違えにくくなる
権限の最小化: ファイルパスやリポジトリ URL をハードコードせず、クライアントが指定した範囲で動くようにする

Claude Code / MulmoTerminal との統合

Claude Code

Claude Code は MCP のリファレンス実装の一つで、~/.claude/mcp.json に書いたサーバーをセッション開始時にすべて起動し、ツール一覧をコンテキストに含めます。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://..."]
    }
  }
}

Claude のプロンプトから mcp__github__create_issue のようなツール名で呼び出せます。

MulmoTerminal

MulmoTerminal は Claude Code をブラウザから並列実行するコックピットです。Claude Code の MCP 設定をそのまま継承するので、追加設定なしに各セルで同じ MCP サーバーが使えます。

9 セル並列で全部が GitHub MCP を使うこともできます。ただ、GitHub の API レート制限に当たりやすくなります。サーバー側に書き込みが行くタイプのツール（issue 作成、PR マージなど）は人間の承認を挟む運用がおすすめです。MulmoTerminal の 琥珀色（あなた待ち）セルは、まさにそのための仕組みです。

Cursor / Windsurf / Zed

これらのエディタも 2025 年前半に MCP 対応を追加しました。設定の場所と書式はエディタごとに違いますが、サーバー側は同じものを使い回せます。

MCP の落とし穴

実際に使い始めるとぶつかる 3 つの罠:

1. ツールが多すぎると LLM が選べなくなる

30 以上のツールを一度にコンテキストに入れると、LLM が「どれを使えばいいか」で迷い始めます。特に性能の低いモデルで顕著。

対策:

プロジェクトごとに必要な MCP サーバーだけを有効化する
Resources で代替できるものは Resources に寄せる（Tools は副作用、Resources は読み取りで、LLM の負荷が違う）
プロンプトで誘導し、GitHub の操作は mcp__github__ のツールを使って のように明示する

2. 認証情報の管理

MCP サーバーに環境変数で API キーを渡すのが現在の慣例ですが、~/.claude/mcp.json を間違って commit するとキーが漏れます。

対策:

mcp.json は gitignore しておく
代わりに mcp.json.example を repo に置く
OS のキーチェーン連携や、1Password CLI (op run) との統合も使われ始めている

3. STDIO サーバーのプロセス管理

Claude Code は MCP サーバーをサブプロセスで起動し、セッション終了時に kill します。でも、サーバー側で TCP ポートを listen していると、プロセスは死んでもポートが TIME_WAIT で残り、次の起動で EADDRINUSE に当たります。

対策:

STDIO サーバーは標準入出力だけ使う。追加のポートを開かない
どうしても必要なら、ポートを 0 指定で OS に選ばせる

導入を検討する目安

AI エージェントの運用が 1 人から 1 チームに広がり、同じ外部ツールを複数のエージェントから呼び始めるタイミングで、MCP を検討する価値が出てきます。「ツールを 1 回書いて、全エージェントから使える」効用は、やってみるとすぐに体感できます。既製の filesystem / github / postgres などから試し、頻度の高いツールだけを自作に移していくのが現実的な導入順です。