【完全ガイド】MCP（Model Context Protocol）とは｜AIエージェントの"USB-C規格"が97M installsを超えた理由

1. なぜ今、AIエージェントに「標準プロトコル」が必要だったのか

LLMが単体で動いていた時代は短かった。

実用に耐えるエージェントを作る瞬間に、誰もが同じ壁にぶつかる。

エージェントを賢くしたければ、外のツールやデータと繋がねばならない。

しかし接続コストが線形どころか乗算で増える。

項目	従来（プロトコル無し）	MCP導入後
統合の組み合わせ	N（モデル）× M（ツール）	N + M
ツール追加コスト	モデルごとに個別実装	Server1本でどのClientからも利用可
ベンダーロックイン	モデルに紐づく	LLM-agnostic
認証・権限管理	アプリ側で個別実装	プロトコル仕様に内包

AIネイティブな開発者なら誰でも一度は書いたことがあるはずだ。

OpenAI用のtool definition、Claude用のtool定義、Geminiのfunction declarations。

中身は同じ「Slackにメッセージを送る関数」なのに、JSONスキーマの書式が三者三様。

ここに割いた時間こそが、本来エージェントの賢さに使われるべき時間だった。

USB端子の歴史を思い出してほしい。

USB-A、Mini-B、Micro-B、Lightning、USB-C。

ケーブル一本のために何度買い替えたか。

USB-Cが共通規格として勝った瞬間、私たちは「ケーブルを選ぶ」という認知コストから解放された。

MCPがやろうとしているのは、AIエージェント領域のまさにそれである。

2. MCPとは何か — USB-Cアナロジーとアーキテクチャ図

MCPの一行定義はこうだ。

「AIアプリケーションが外部のツール・データソース・プロンプトを統一インタフェースで利用するためのオープンプロトコル」。

通信規格はJSON-RPC 2.0。

トランスポートはローカル用のstdioと、リモート用のHTTP + Server-Sent Events（SSE）の2系統が公式にサポートされる。

LLMには非依存。

Claudeでも、GPTでも、Geminiでも、ローカルLLMでも、Client側が対応していれば同じMCP Serverに接続できる。

3. Host / Client / Server の3層構造

MCPには3つの登場人物がいる。

層	役割	実例
Host	LLMを内蔵するアプリ本体。ユーザーと対話する	Claude Desktop, Cursor, Windsurf, Claude Code
Client	Host内に存在し、1つのServerと1対1で接続する通信層	Host SDK内部に実装
Server	ツールやデータを外部に公開する。1つのServerが複数のTool/Resourceを束ねる	GitHub Server, Slack Server, Postgres Server

ここで重要なのは、ClientとServerが必ず1対1で結ばれるという点だ。

Hostが3つのServer（GitHub, Slack, Postgres）を使いたい場合、Hostの中に3つのClientが立ち上がる。

これによりServerは他のServerの存在を知らずに済み、認証や権限の境界が綺麗に切れる。

セキュリティ設計の観点でこの「分離」が効いてくる。

4. 3つのプリミティブ — Tools / Resources / Prompts

MCP Serverが公開できるリソースは3種類に整理されている。

3者の本質的な違いは「誰が呼び出しを決めるか」にある。

Toolsはmodel-controlled。

LLMが文脈を見て自律的に呼び出す。

Resourcesはapplication-controlled。

Hostアプリ側が「この記事を読み込ませる」と判断して投入する。

Promptsはuser-controlled。

ユーザーが明示的にスラッシュコマンド等で選ぶ。

この区別が曖昧なまま実装すると、エージェントが暴走したり、逆に何も呼ばなくなったりする。

5. 競合プロトコルとの比較

MCPは唯一の選択肢ではない。

主要な競合との関係を整理しておこう。

プロトコル	提供元	スコープ	LLM中立性	双方向通信
MCP	Anthropic / Linux Foundation	エージェント↔ツール/データ標準	あり（仕様レベル）	あり（SSE）
OpenAI Function Calling	OpenAI	OpenAIモデル内のツール呼び出し	なし	なし
LangChain Tools	LangChain社	フレームワーク内ラッパー	あり（ライブラリ）	フレームワーク依存
Gemini Function Calling	Google	Geminiモデル専用	なし	なし
AGENTS.md	OpenAI	エージェントの設定記述形式	あり	プロトコルではない

OpenAIやGoogleの仕組みは「自社モデル前提のFunction Calling」で、別モデルから呼ぶには変換が必要だ。

LangChain Toolsは便利だが、そもそもライブラリであってプロトコルではない。

つまりMCPの差別化点は、ベンダー中立かつ仕様としてオープン、そしてリモート対応という3点にある。

6. 実装入門 — 公式SDKでMCP Serverを30行で書く

理屈はここまで。

手を動かそう。

公式SDKはPython・TypeScript・Go・C#・Java・Kotlin・Rust・Swiftで提供されている。

ここでは最も使われているPythonとTypeScriptで、天気を返すだけの最小Serverを書く。

# Python版 — pip install mcp
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-server")

@mcp.tool()
def get_weather(city: str) -> str:
    """指定都市の天気を返す（ダミー実装）"""
    return f"{city}の天気は晴れ、気温は18度です。"

@mcp.resource("weather://{city}")
def weather_resource(city: str) -> str:
    return f"{city}: sunny, 18C"

if __name__ == "__main__":
    mcp.run(transport="stdio")

TypeScriptでもほぼ同じ手数で書ける。

// TypeScript版 — npm i @modelcontextprotocol/sdk
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "weather-server", version: "1.0.0" });

server.tool(
  "get_weather",
  { city: z.string() },
  async ({ city }) => ({
    content: [{ type: "text", text: `${city}の天気は晴れ、気温は18度です。` }]
  })
);

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

Claude Desktopの設定ファイル（claude_desktop_config.json）にこのServerのコマンドパスを書けば、再起動するだけでチャット中に「東京の天気は？」と聞いてエージェントがget_weatherを呼ぶ。

ここまでの所要時間、慣れた人なら10分以下である。

7. エコシステム動向 — 97M installsを支えるOSS群

2026年3月時点でMCP Server側のOSSは数千リポジトリ規模に膨張した。

代表格を並べると勢力図が見える。

カテゴリ	代表的Server	提供元
開発ツール	github-mcp-server, gitlab-mcp	GitHub, GitLab公式
データベース	postgres-mcp, sqlite-mcp, supabase-mcp	コミュニティ・各社
コミュニケーション	slack-mcp, gmail-mcp, calendar-mcp	コミュニティ
クラウド	aws-mcp, vercel-mcp, cloudflare-mcp	各社公式
検索	brave-search-mcp, tavily-mcp	各社

採用クライアントもClaude Code、Cursor、Windsurf、Replit、Block（旧Square）のgoose、Sourcegraph Codyと主要IDE系を概ね押さえた。

97M installsという数字は、純粋な「DLされた回数」というよりは、レジストリ・パッケージマネージャ経由でClient/Serverが取得された総数だ。

プロトコルの普及度を示す代理変数として、この1年半の伸びは異常とすら言える。

8. 課題と未来 — 認証・分散・マルチエージェント協調

順風満帆に見えるMCPだが、足りないピースもある。

第一に、本格的な認証・認可の標準化。

OAuth 2.1ベースの仕様策定は2026年に入って加速したが、エンタープライズ要件（SSO、監査ログ、ロールベース権限）はServerごとの実装に委ねられている部分が大きい。

第二に、分散シナリオでの一貫性。

複数のMCP Serverを跨ぐトランザクションをどう扱うか、失敗時のロールバックは誰が責任を持つのか、という議論はまだ実装パターン任せだ。

第三に、マルチエージェント協調。

エージェント同士がMCPで通信する、いわゆる「A2A（Agent-to-Agent）」のレイヤは、Linux FoundationのAgentic AI Foundation配下で別仕様として議論が進んでいる。

これらが整った先に見えているのは、私たちが今のWebで当たり前に使っているHTTPと同じ景色だ。

誰がServerを立てたかを意識せずにエージェントが情報と能力を取りに行く世界。

そこに到達するための、最初のレイヤがMCPなのである。

9. FAQ

Q. MCPはClaude専用ですか？

いいえ。

仕様はLLM非依存で、Client側が対応していればGPT、Gemini、ローカルLLMからも利用できる。

実装上はClaude Desktopが最も先行しているが、Cursor・Windsurfなど他Hostでも採用済みだ。

Q. 既存のFunction Callingから移行すべき？

新規開発ならMCP優先で問題ない。

既存資産は無理に書き換えず、新しいツールから順次MCP Serverとして切り出していくのが現実的だ。

Q. リモートServerはセキュリティ的に大丈夫？

HTTP+SSEトランスポートではTLS必須、OAuth 2.1ベースの認証が推奨される。

ただし社外公開Serverを使う場合は提供元の監査体制を確認したほうがよい。

Q. 商用利用やライセンスは？

仕様はApache 2.0相当のオープンライセンス。

公式SDKもMITまたはApache 2.0で、商用利用に制約はほぼない。

Q. 学習リソースは何から？

公式サイト modelcontextprotocol.io のクイックスタートが最短ルート。

その後はGitHubのmodelcontextprotocol/serversリポジトリの実装を読むのが理解を深める早道だ。

---

USB-Cがケーブルの世界を統一したように、MCPはAIエージェントとツールの境界を溶かしつつある。

「どのモデルで動くか」ではなく「どのServerに繋ぐか」で設計する時代は、もう始まっている。

あなたのプロダクトは、Server側に回るのか、Host側に回るのか。

それとも両方を持つのか。

選択を先送りにする時間は、思っているより短いかもしれない。

出典・参考

• Model Context Protocol 公式仕様（modelcontextprotocol.io）
• Anthropic「Introducing the Model Context Protocol」発表記事（2025年11月）
• Linux Foundation「Agentic AI Foundation」設立リリース（2025年12月）
• GitHub modelcontextprotocol/servers リポジトリ
• Anthropic Engineering Blog「MCP at Scale」（2026年3月、97M installs公表）
• JSON-RPC 2.0 Specification（jsonrpc.org）