Model Context Protocol (MCP) とは？AI ツールの「USB-C ポート」をアーキテクチャ・主要プリミティブ・Sales Claw 視点で徹底入門

「Model Context Protocol (MCP) って、Claude / ChatGPT / Cursor / VS Code / Gemini CLI 全部で名前を見かけるけど、結局これは何で、なぜ業界標準になったのか? そして AI 営業自動化に組み込むとしたら、どう設計すればいいのか?」—— 本記事ではこの根本的な疑問に対し、MCP 公式仕様 (2025-11-25 版) と Anthropic / OpenAI / Google の一次ドキュメントを参照しながら、Sales Claw 開発者視点でアーキテクチャ・主要プリミティブ・実装イメージ・運用リスクを通しで解説します。

2024 年 11 月 25 日に Anthropic が発表した Model Context Protocol (MCP) は、それから 1 年半が経った 2026 年 5 月時点で、Claude Code・ChatGPT (Apps)・Codex・Gemini CLI・Cursor・VS Code・Zed・Replit といった主要 AI 開発ツールすべてに採用される、事実上の業界標準になっています。公式サイトは MCP を 「AI アプリケーションのための USB-C ポート」 と表現していますが、これは比喩としての分かりやすさを優先した説明にすぎず、その裏には JSON-RPC 2.0 ベースの状態付きセッションプロトコルと Host / Client / Server の 3 層分離という、Language Server Protocol (LSP) を強く意識した堅実な設計があります。

本記事は modelcontextprotocol.io 公式仕様 (2025-11-25 版)・modelcontextprotocol/specification GitHub リポジトリ・modelcontextprotocol/servers GitHub リポジトリ・Anthropic Newsroom (2024-11-25 MCP 発表)・Claude Code MCP Docs (code.claude.com)・OpenAI MCP Docs (developers.openai.com/api/docs/mcp)・Gemini CLI MCP Docs (geminicli.com) を一次情報として参照しています。前日リリース速報の claude agents × codex remote-control 並列運用記事 や、Claude Code 個別のツール解説である Claude Code スラッシュコマンド 81 コマンド整理記事 を読まれた方は、本記事を「その下にある共通プロトコル層」として読むと立体的に理解できます。Sales Claw の クイックスタートガイド も併読しておくと、後半の実装イメージが腹落ちしやすくなります。

1. MCP (Model Context Protocol) とは何か——「AI 用 USB-C ポート」の比喩を超えて

Model Context Protocol (以下 MCP) の公式定義は modelcontextprotocol.io によれば次の通りです。

この一文を分解すると、「(a) AI アプリケーション側」と「(b) 外部システム側」のあいだに、「(c) オープンな標準プロトコル」を 1 層挟む、という構造が見えます。USB-C の比喩は、ハードウェア接続が 「メーカー独自端子の組み合わせ爆発 → USB-C 一本で済む」という歴史を踏んだのと同じ問題を、AI とツールの組み合わせで解決しに来ている、という意味で正確です。

ただし、ここで止まると MCP の真の設計判断を見落とします。仕様書 (modelcontextprotocol.io/specification) は明確に、MCP がLanguage Server Protocol (LSP) からインスピレーションを受けたと書いています。

LSP は 2016 年に Microsoft が VS Code のために設計したもので、それまで「エディタ × 言語」のフラグメンテーション (N × M 問題) を、「エディタ ← LSP → 言語サーバ」という 1 層プロトコル抽象化で解決しました。MCP はこの構図を「LLM アプリ × データソース/ツール」のフラグメンテーションにそのまま当てはめた、と理解するのが正確です。

この「LSP の AI 版」という見方は、後で出てくる capability negotiation (機能ネゴシエーション) や stateful session (状態付きセッション) の設計判断を腹落ちさせる鍵になります。Claude の独自仕様・OpenAI の独自仕様・Google の独自仕様で別々に作るのではなく、Anthropic 主導で「皆で同じプロトコルを使えるようにしよう」と提案したのが MCP です。

2. 公式情報で確認できる MCP の歴史と現行仕様 (2024-11-25 → 2025-11-25)

MCP の歴史的な流れを公式情報で押さえておきます。

2024-11-25: Anthropic による MCP 発表

2024 年 11 月 25 日、Anthropic は公式 Newsroom で「Introducing the Model Context Protocol」を発表しました。発表時点の主要ポイントを公式記事から拾います。

• 創設者: MCP は Anthropic の David Soria Parra と Justin Spahr-Summers が中心となって設計
• 動機: AI モデルが「情報サイロやレガシーシステムの裏側」に閉じ込められた知識へアクセスできない問題を解決する
• 発表時の支持者: 早期採用企業として Block、Apollo、開発ツール企業として Zed、Replit、Codeium、Sourcegraph
• 同時公開: Google Drive、Slack、GitHub、PostgreSQL などの主要システム向けの「pre-built MCP server」も同時公開

2024-11 → 2025-11: 仕様改訂 1 年の歩み

modelcontextprotocol/specification リポジトリの schema フォルダにはバージョン別の TypeScript schema が積まれており、おおよその系譜は以下のとおりです (リポジトリ上の schema フォルダの命名規則に基づく整理)。

2026 年 5 月時点で参照すべき仕様は 2025-11-25 版です。公式仕様ページ (modelcontextprotocol.io/specification) も同バージョンを基準に記述されており、Architecture / Base Protocol / Server / Client / Contributing の 5 セクション構成になっています。

公式リファレンスサーバ 7 種とエコシステム

modelcontextprotocol/servers リポジトリには 公式リファレンス実装が 7 種あります。これらは「MCP がどう振る舞うべきか」のお手本であり、自社で MCP サーバを書く際にもっとも参考にすべき実装です。

サードパーティのコミュニティ実装は 150 を優に超える数がリポジトリ README からリンクされており、Anthropic Directory (claude.ai/directory) には公式レビュー済みのリモート MCP サーバが並んでいます。Slack、Notion、Linear、Figma、Google Drive、PostgreSQL、Sentry、Datadog、Sentry、Statsig、Cloudflare……主要 SaaS のほぼすべてに「公式または準公式の MCP サーバ」が用意されている状態です。

3. アーキテクチャ——Host / Client / Server の 3 層と JSON-RPC 2.0

MCP 仕様 (modelcontextprotocol.io/specification/2025-11-25/architecture) のアーキテクチャ定義を要約すると、次のような 3 層構造になっています。

Host (ホスト)

• 定義: LLM アプリケーションのプロセス全体を司るコンテナ兼コーディネータ
• 具体例: Claude Desktop、Claude Code、ChatGPT、Cursor、VS Code、Zed、Gemini CLI など
• 責務: 複数 Client インスタンスの生成と管理 / ユーザ同意の取得 / セキュリティポリシーの執行 / LLM サンプリングの統括 / 複数 Server からのコンテキスト集約

Client (クライアント)

• 定義: Host が生成し、特定の Server と 1:1 のセッションを保持するコネクタ
• 責務: 状態付きセッションの確立 / プロトコルネゴシエーション / メッセージの双方向ルーティング / サブスクリプションと通知の管理 / Server 間のセキュリティ境界の維持

Server (サーバ)

• 定義: 専門的なコンテキストや機能を提供する独立プロセスまたはリモートサービス
• 具体例: Filesystem サーバ、Git サーバ、Slack サーバ、Postgres サーバ、Sentry サーバ……そして将来的には Sales Claw サーバ
• 責務: Resources / Tools / Prompts を公開する / sampling を Client 経由で要求する / セキュリティ制約に従う

JSON-RPC 2.0 とトランスポート

メッセージング層は JSON-RPC 2.0 で、Client-Server 間で双方向の request / response / notification をやり取りします。トランスポートは以下の 3 種類が標準化されています:

セッションライフサイクル: 初期化 → ネゴシエーション → セッション → 終了

MCP セッションは「initialize」リクエストで始まります。Client が自身の能力 (capabilities) を申告し、Server が応答として自身の能力を返す——いわゆる capability negotiation です。これが「Server は tools を持っているか」「Client は sampling をサポートするか」を セッション開始時点で確定させる仕組みになっています。

// Client → Server: initialize
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "sampling": {},
      "roots": { "listChanged": true }
    },
    "clientInfo": { "name": "Claude Code", "version": "2.1.142" }
  }
}

// Server → Client: initialize result
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true },
      "prompts": {}
    },
    "serverInfo": { "name": "salesclaw-mcp", "version": "0.1.0" }
  }
}

その後、Client は tools/list、resources/list、prompts/list 等を発行し、LLM が必要に応じて tools/call でツールを呼びます。Server から Client への request も発行でき、典型例は sampling/createMessage (Server が「この続きを LLM に書かせてほしい」と頼む) や roots/list (Server が「どのディレクトリで動いていいか教えて」と聞く) です。

Sales Claw は MCP サーバ化を見据えた、ポリシー制御付き自律運用フレームワーク。

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub

4. プリミティブ——サーバ機能 3 種 + クライアント機能 3 種

MCP の機能はすべてこの 6 つのプリミティブに分解されます。仕様書のサーバ機能一覧表 (modelcontextprotocol.io/specification/2025-11-25/server) は次のように 「誰が制御するか」 で 3 種を分けています。

サーバ機能 3 種 (Server Features)

この 3 種は 誰が呼ぶかで根本的に違います。Resources は「Host アプリが UI で選んで添付する」、Prompts は「ユーザがスラッシュコマンドや menu で明示的に発火する」、Tools は「LLM が自分の判断で発火する」——同じ「Server が公開する機能」でも、安全性のレイヤーが大きく異なります。たとえば「ファイルを削除する Tool」を作ると、LLM の判断で発火するため、ユーザの明示同意が常に問われます。逆に「ファイル一覧を Resources として公開」しておけば、ユーザが UI で選んだときだけ Host が読みに行きます。

クライアント機能 3 種 (Client Features)

反対方向 (Server → Client) の機能は次の 3 つです。これらは Client が能力として宣言したときだけ、Server から呼び出せます。

Elicitation は 2025-06-18 仕様で追加された比較的新しいプリミティブで、Server 側に「ユーザに確認を取る道」が初めて開かれました。それまでは「足りない情報はサーバが推測 or エラー」しかなかったため、設計のクリーンさが大きく上がっています。

5. 主要 AI ツールの MCP 対応状況と Sales Claw 実装イメージ

Host 別 MCP 対応マトリクス

重要なのは 「設定方法は違っても、向こう側で動く MCP サーバは同じバイナリでよい」 という点です。これが MCP のオープンプロトコルとしての価値です。Claude Code 用に書いた MCP サーバを、Gemini CLI からも Cursor からも同じように呼べます。

Claude Code への MCP サーバ追加例

# stdio サーバ (ローカルプロセス) を追加
claude mcp add salesclaw -- npx -y @salesclaw/mcp-server

# Streamable HTTP サーバ (リモート) を追加
claude mcp add --transport http salesclaw https://mcp.salesclaw.site

# .mcp.json でプロジェクト共有 (チーム全員で同じ MCP サーバ構成)
cat > .mcp.json <<EOF
{
  "mcpServers": {
    "salesclaw": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@salesclaw/mcp-server"],
      "env": { "SALESCLAW_API_KEY": "${SALESCLAW_API_KEY}" }
    }
  }
}
EOF

Gemini CLI への MCP サーバ追加例

# ~/.gemini/settings.json (ユーザ設定) に MCP サーバを追加
cat >> ~/.gemini/settings.json <<EOF
{
  "mcpServers": {
    "salesclaw": {
      "command": "npx",
      "args": ["-y", "@salesclaw/mcp-server"],
      "env": {
        "SALESCLAW_API_KEY": "$SALESCLAW_API_KEY"
      }
    }
  }
}
EOF

Sales Claw を MCP サーバ化する実装イメージ

Sales Claw は、ポリシー制御・送信前自動検査・営業 NG 検出・CAPTCHA 検出時停止・送信頻度制限・監査ログ保存・自動停止条件によって、誤送信と規約違反リスクを下げる設計の OSS ツールです。これを MCP サーバ化すると、Claude / ChatGPT / Cursor / VS Code / Gemini CLI 等から「同じインターフェースで」呼び出せるようになります。

Sales Claw MCP サーバが公開する Primitive のたたき台は次のようになります (設計案、実装は段階的に進めます)。

この設計の肝は preflight_check と submit_form を 意図的に分割している点です。LLM (Claude / ChatGPT) が submit_form を直接呼ぼうとしても、Sales Claw サーバ側で「事前に preflight_check が pass している状態」しか受理しないよう実装することで、Host 側の --permission-mode 設定とは独立した 第 2 防御層を作れます。Tools 仕様の 「任意コード実行と等価」 前提への、設計レベルの応答です。

Sales Claw 社内検証 (約 300 件の問い合わせフォーム自動送信を 自律ループ + 並列バッチ + Hooks 経由の event-loop 監視で運用観察した結果) からは、MCP サーバ化した場合でも、(1) goal / 件数上限 / 経過時間上限の AND 終了条件、(2) CAPTCHA 検出時の awaiting_approval 状態保持、(3) Compliance Footer の自動付与、(4) 監査ログによる subagent 単位の追跡、(5) 営業 NG 検出時の即停止——これら 5 つの検証条件はすべて Server 側で組む必要がある、というのが現時点の運用観察です。エンタープライズ向けに展開する場合はさらに、テナント ID 単位の Resources 分離が必須になります。

# MCP Inspector でローカル開発しながらデバッグする例
npx -y @modelcontextprotocol/inspector npx -y @salesclaw/mcp-server

# Claude Code から呼ぶ
claude mcp add salesclaw -- npx -y @salesclaw/mcp-server
# Claude Code 内で: 「@salesclaw preflight_check してから @salesclaw submit_form してください」

MCP サーバを自作する開発コスト試算

変動幅は ±30〜50% を見込んでください。とくに「セキュリティレビュー」と「Tool 単位の権限設計」は組織の成熟度によって 2〜3 倍ぶれます。

6. MCP の安全性とリスク——Tool Safety / Sampling Consent / データ越境

MCP は「任意コード実行と等価のツールを Host と Server の間で扱う」プロトコルです。仕様書のセキュリティ章は、MCP 自身が プロトコルレベルでこれを強制できない ことを明言し、実装側 (Host / Server 両方) に責任を委ねています。Sales Claw を MCP サーバ化する場合も、Sales Claw 単独で運用する場合も、以下のリスクを自動検査で下げる設計を採用します。

ツール安全性 (Tool Safety)

• Tool description を信用しない: 仕様書は明確に「Tool description annotations should be considered untrusted」と述べる。LLM がツール名と説明だけ見て呼ぶ実装は危険
• ユーザ同意を取る: 副作用のあるツール (送信・書込・削除) は、Host が必ずユーザに確認を取る (Claude Code の --permission-mode default / ask 等)
• Server 側の二段防御: Host で「許可された」だけでは不十分。Sales Claw のように preflight_check → submit_form の順序強制を Server 側 で実装する

サンプリング同意 (Sampling Consent)

• Server による暴走を防ぐ: Sampling は Server が「LLM にこの続きを書かせて」と Client に要求する機能。仕様書は「ユーザは明示的に承認する必要がある」と義務化
• Server に見えるプロンプトを制御: 仕様書は「protocol intentionally limits server visibility into prompts」と述べ、Server が会話全体を見れない設計に

データ越境とプライバシー

• 明示同意なしのデータ転送禁止: 仕様書は「Hosts must not transmit resource data elsewhere without user consent」と義務化
• Server 間のサイロ化: Client は 1:1 で Server とセッションを張るため、Server A の情報が Server B に漏れない (Host が明示的に渡さない限り)
• 監査ログ: Sales Claw のように送信ログを Resources として残し、後追いの監査を可能にする

MCP 導入で残るリスク

プロトコル設計と Server 実装の両方で配慮しても、以下は構造的に残ります:

• 悪意ある第三者 MCP サーバ: Cursor や Claude Desktop でユーザが任意の MCP サーバを追加できる → 「画像生成サーバを装ったキーロガー」が技術的に可能。Anthropic Directory のような審査付きディレクトリ経由を強く推奨
• Tool description prompt injection: Server 側の Tool description に細工して LLM の挙動を誘導する攻撃。Host で description を表示しユーザに確認を求める実装が防御策
• Streamable HTTP の認可不備: リモート MCP サーバの認可を OAuth 2.0 で組まずに API key を URL に埋め込むなどの実装ミス
• Sampling 経由のコスト爆発: Server が再帰的に sampling を要求すると、ユーザの API 利用料が予想外に膨らむ。Host 側のレート制限が必須

7. 実運用前チェックリスト

MCP サーバを自作して本番に投入する前、または信頼性が不明な MCP サーバを Host に追加する前のチェック項目です。

8. まとめ——AI コーディング拡張の「土台技術」として MCP から何を学ぶか

MCP は 「AI 用 USB-C ポート」という分かりやすい比喩で語られますが、その本質は Language Server Protocol の AI 版として、LLM アプリと外部システムの N × M フラグメンテーションを 1:N に整理しなおすプロトコル抽象化です。Host / Client / Server の 3 層、JSON-RPC 2.0、Resources / Tools / Prompts / Sampling / Roots / Elicitation の 6 プリミティブ、そして「Tool 実行は任意コード実行と等価」という強い前提——これらは 2025-11-25 版仕様で安定しています。

Sales Claw 開発者の視点からは、MCP は「Sales Claw が呼び出される側 (Server) にも、呼び出す側 (Host 内 Client) にもなれる」という意味で、AI 営業自動化のアーキテクチャを根本から拡張する技術です。送信前自動検査をプロトコルレベルで強制する設計を MCP の Tool 順序制御で実装すれば、Claude / ChatGPT / Cursor のどの Host から呼ばれても、Sales Claw の安全設計は同じように働きます。

次のアクション: 自社で MCP サーバを 1 つ作るなら、まず modelcontextprotocol/servers リポジトリの Everything サーバを読んでください。Resources / Prompts / Tools の最小実装が一つに収まっており、SDK の使い方も同時に学べます。Sales Claw の運用設計に組み込むなら、 クイックスタートガイド から始めて、まず preflight_check の自動検査ロジックを理解するところから入るのが最短です。

MCP は土台技術。動かしてみないと身につかない。

無料・MIT ライセンス。インストールせずにライブデモも試せます。

無料でダウンロードライブデモを試すGitHub