📋 目次

01 · はじめに：HTTP から MCP へ

1990 年代、各 Web サイトは独自の転送フォーマットを持ち、ブラウザとサーバー間に共通言語がありませんでした。HTTP の登場により「リクエスト—レスポンス」が標準化され、N 個のクライアントと M 個のバックエンドが同一プロトコル上で HTML や JSON を交換できるようになり、Web が爆発的に普及しました。今日の AI 分野も同様の局面にあります。N 個の AI アプリ（Host）がM 個の外部ツール（データベース、GitHub、Slack、ローカルファイル）に接続したいとき、各社が独自の関数呼び出し形式を定義すれば、統合コストは N×M で爆発します。

Model Context Protocol（MCP）は Anthropic が 2024 年末に提唱し、2025〜2026 年に Linux Foundation 傘下の Agentic AI Foundation へ寄贈される過程で、業界共通の「AI ツールバス」として位置づけられました。MCP は LLM そのものを置き換えるものではなく、モデルとツールの間に標準化されたコンテキストとツール発見プロトコルを挿入します。HTTP が TCP を置き換えなかったのと同様、MCP も下位トランスポートを置き換えず、アプリ開発者がサイトごとに Socket プロトコルを書く必要をなくします。

02 · 統合の三つの課題

MCP 普及前、MacDate が支援する開発チームで最も多い三つの課題は次のとおりです。

課題 1：AI ツールごとに別実装。 Cursor には @docs と拡張、Claude Desktop には Connectors、Copilot には Extensions——同じ GitHub API でも三セットの設定と OAuth フローが必要になり、監査コストが線形〜指数的に増えます。
課題 2：ツール能力の「発見」がない。 OpenAPI ドキュメントがどれほど充実しても、モデルは自動的に endpoint を知りません。Function Calling schema を手書きし、API 変更のたびに Prompt を同期する必要があり、Discovery の欠如が根本原因です。
課題 3：ローカルとクラウドの境界が曖昧。 Agent は ~/Projects のソース、クラウド Jira、社内 SQL を同時に触ります。本番 Mac に正式 API キーとテスト MCP Server を混在させると、背景 cron で Token を燃やす事故が起きやすく、隔離環境がなければ新 Server を試せません。

MCP はフォーマット統一・能力発見・監査可能なトランスポートを一度に解決するよう設計されています。

03 · N×M 問題と USB-C アナロジー

5 つの AI Host（Cursor、Claude Desktop、VS Code、Windsurf、自社 Agent）と20 の常用ツール（GitHub、Notion、PostgreSQL、Redis、Slack 等）がある場合、最悪 5×20＝100 組のカスタムコネクタが必要です。Host かツールを 1 つ追加するたびに +N または +M のコストがかかる——これが N×M 統合問題です。

ハードウェアの USB-C に例えると分かりやすいです。以前は Micro-USB、Lightning 等が乱立し、N デバイス×M 充電器の組み合わせが地獄でした。USB-C は転送ロジック自体を発明したわけではなく、物理インターフェースを統一して N×M を N+M に下げました。MCP も同様に、Host は MCP Client を、ツールは MCP Server を実装すれば、対話の意味が固定され N×M が N+M になります。

統合コストモデル
├─ MCP なし：N Host × M ツール＝ N×M カスタム
├─ MCP あり：N Client ＋ M Server ＝ N+M
└─ 新ツール追加：Server 1 個で全 Host が自動発見

04 · Host／Client／Server 三層

役割	典型例	責務
Host	Cursor、Claude Desktop、VS Code Copilot	ユーザーが直接触る AI アプリ。対話・モデルルーティング・承認
Client	Host 内蔵 MCP モジュール	Server との接続、JSON-RPC、リソース購読
Server	filesystem-mcp、postgres-mcp、自社 Server	Tools／Resources／Prompts を公開

典型フロー：ユーザーが Host に「先週 #dev のデプロイ議論を Slack から要約して」と入力 → LLM が Slack MCP Server を選択 → Client が tools/call を送信 → Server が Slack API を呼び結果を返す → Host がコンテキストに注入。Host は Slack REST の全 endpoint を知る必要がなく、tools/list で発見できる Tools だけ知れば足ります。

macOS 開発者にとって、多くの MCP Server は Node.js や Python で stdio または localhost SSE 上で動きます。Apple Silicon のユニファイドメモリでは複数 Server と IDE がメモリ帯域を共有し、長時間 Agent タスクが x86 VM より省電力です。Keychain や TCC 保護ディレクトリに触る Server は、隔離レンタルノードで試すのが安全です。

05 · JSON-RPC トランスポート機構

MCP は JSON-RPC 2.0 を採用します。JSON は可読性が高く、各言語のライブラリが成熟しており、HTTP／WebSocket／stdio と相性が良いからです。主要メッセージは次のとおりです。

initialize：握手と能力交換
tools/list・tools/call：ツール発見と実行
resources/list・resources/read：ファイルや DB スナップショット
prompts/list：再利用 Prompt テンプレート

                        // tools/call リクエスト例（簡略）

{ "jsonrpc":"2.0", "id":1, "method":"tools/call",

  "params":{ "name":"query_db",

    "arguments":{ "sql":"SELECT count(*) FROM orders" } } }

ローカル開発は stdio が最も簡単です。チーム PoC やリモート Host では SSE over HTTP を使い、レンタル Mac 上で SSH トンネル経由の検証が可能です。

06 · MCP vs REST 対照表

「MCP は REST を置き換えるのか？」——2026 年の勉強会で最頻出の質問です。答えはいいえです。REST はリソース指向 HTTP API で、人間のエンジニアと従来マイクロサービス向け。MCP は AI Agent 向けのツール発見とコンテキスト注入プロトコルで、Server 内部では依然 REST を呼びます。

観点	REST	MCP
利用者	エンジニア、フロント／バック	Host 内 LLM／Agent
発見	OpenAPI（人間が読む）	tools/list（モデルが読む）
セッション	基本ステートレス	長接続・購読・コンテキストストリーム
転送	HTTP + JSON/XML	JSON-RPC 2.0（stdio／SSE）
用途	CRUD、サービス境界	Agent ツールチェーン、RAG、filesystem

実務では Slack MCP Server が内部で Slack REST を呼ぶ構造が典型です。対外 B2B は REST／GraphQL、社内 Agent 層に MCP アダプタ——共存が正解です。

07 · 2026 年四社の参入

Anthropic：プロトコル創設者。Claude Desktop ネイティブ Client。
OpenAI：ChatGPT Desktop と Responses API エコシステムが MCP に整合。
Google：Gemini CLI、Antigravity、Cloud Agent が MCP 統合。並行して A2A を推進。
Microsoft：VS Code Copilot Agent、GitHub 拡張。Entra ID と承認ゲートウェイを強調。

今 MCP Server アダプタに投資することは、特定 IDE 私有形式よりベンダーロックインに強い選択です。PostgreSQL 用 Server は Host を替えても動きます。

08 · 1 万超 Server エコシステム

2026 年 6 月時点で、コミュニティと npm／PyPI 上の MCP Server 実装は10,000 超です。GitHub、PostgreSQL、Slack、AWS、Kubernetes、Confluence 等をカバーします。数量爆発は品質ばらつき・悪意 Server・過剰権限も連れてきます。2026 年のベストプラクティスは：公式または Foundation 維持 Server のみ、Host 側ツール承認、最小 OAuth scope、未知 Server は隔離 macOS で試行です。

09 · MCP と A2A の補完

Google の Agent-to-Agent（A2A）は MCP の競合ではなく補完です。

プロトコル	接続	類比
MCP	Agent（Host）↔ ツール／データ	HTTP：ブラウザ ↔ Web サーバー
A2A	Agent ↔ Agent	メール：クライアント ↔ クライアント

コードレビュー Agent が MCP で PR を読み、デプロイ Agent が MCP で K8s を操作し、両 Agent が A2A で「マージ可否」を交渉する——この分業が 2026 年の企業 Agent アーキテクチャの標準像です。

10 · Mac レンタル隔離 5 ステップ

隔離 macOS をレンタル：Mac mini M4 から SSH。本番 Keychain・OAuth と完全分離。ベアメタル macOS 料金参照。
Host と候補 Server を配置：Cursor または Claude Desktop を入れ、npx／uvx で filesystem・postgres・Slack 等を起動。テスト OAuth を使用。
固定ベンチマーク：ファイル grep、DB SELECT、API GET の 3 種を同一 Prompt で実行し、成功率と JSON-RPC レイテンシを記録します。
権限・監査：承認ダイアログ頻度、scope 過剰、SSE 安定性、メモリ使用量を記録します。
ADR 出力と返却：選定結論を文書化し、キー失効・OAuth ログアウト・ディスクワイプ。日次 Mac FAQ、OpenClaw MCP ガイド参照。

11 · よくある質問

Q：MCP は OpenClaw プラグインを置き換えますか？ 完全置換ではありません。OpenClaw は Gateway と独自承認モデルを持ち、MCP Server 接続もサポートします。

Q：小規模チームは Server を自作すべきですか？ GitHub と filesystem だけならコミュニティ Server で十分です。社内 API がある場合は thin MCP アダプタが OpenAPI 直読みより信頼性が高いです。

Q：stdio と SSE の選び方は？ ローカル単独なら stdio。チーム PoC やリモート検証は SSE + SSH トンネルが適しています。

Q：1 万件超からどう選ぶ？ 公式・Foundation 実装優先。ダウンロード数、直近 commit、最小 scope を確認。未知 Server は隔離ノード限定です。

12 · まとめ：本番 Mac に未知 MCP を混ぜない

MCP は N×M を N+M に下げますが、プロトコル標準化＝Server 信頼ではありません。1 万件超のコミュニティ Server には、広すぎる filesystem 権限やハードコード API キーも存在します。本番 Mac で npx @someone/random-mcp を実行することは、Keychain と ~/Projects を未知プロセスに開放することと同義です。

Cursor と Claude Desktop と Copilot Agent で同一 MCP Server の対照実測が必要で、Xcode と同サイクルで検証したい場合、独立 macOS レンタルノードで 1〜3 日試行してから本番接続する方が安全です。MCP は AI 時代の HTTP——検証環境も staging サーバーと同様に本番から隔離すべきです。