MCPがAI統合のUSB-Cになった経緯 — 技術的ディープダイブ
Engineering Team
N x M統合問題
Model Context Protocolが存在する前、AIモデルを外部ツールに接続することは組み合わせ爆発の作業でした。すべてのAIアプリケーション（Claude、GPT、Gemini、Copilot）は、すべてのツール（Slack、Jira、GitHub、データベース、API）に対してカスタム統合が必要でした。M個のAIアプリケーションとN個のツールでは、業界はM x N個のカスタムアダプタが必要でした。それぞれに独自の認証フロー、データフォーマット、エラー処理、メンテナンスの負担がありました。
規模を考えてみてください。2025年までに、約20の主要なAIアプリケーションプラットフォームと数百のエンタープライズツールが存在しました。この計算は持続不可能でした。新しいAIプラットフォームはすべて、統合をゼロから構築する必要がありました。新しいツールはすべて、すべてのAIプラットフォーム向けにアダプタを書く必要がありました。これは、USB以前にハードウェア業界が直面したのと同じ問題です。すべてのデバイスが独自のコネクタを持ち、すべてのコンピュータが異なるポートを必要としていました。
MCPは、USB-Cがコネクタの問題を解決したのと同じ方法でこれを解決します：インターフェースの標準化。MCPでは、すべてのAIアプリケーションが1つのMCP clientを実装し、すべてのツールが1つのMCP serverを実装します。M x N問題がM + Nになります。1つのプロトコル、ユニバーサルな互換性。
プロトコルアーキテクチャ：JSON-RPC、Capabilities、3つのプリミティブ
MCPはJSON-RPC 2.0の上に構築されています。これは、すべての最新コードエディタを動かすLanguage Server Protocol（LSP）と同じ軽量RPCプロトコルです。これは意図的な設計選択でした。JSON-RPCはシンプルで、よく理解されており、言語に依存せず、実戦でテスト済みです。
機能ネゴシエーション
MCPの接続はinitializeハンドシェイクから始まり、clientとserverが相互に機能を宣言します。これにより、プロトコルのグレースフルな進化が可能になります。新しい機能は新しいcapabilityフラグとして追加でき、古いclientやserverは不明なcapabilityを無視できます。
3つのプリミティブ
MCPは3つのコアプリミティブを定義しています：
-
Tools：AIモデルが呼び出す関数。tools/listで発見し、tools/callで実行します。各ツールにはJSON Schemaで定義された名前、説明、入力スキーマがあります。
-
Resources：AIモデルが読み取るデータ。URIで識別され、resources/readで取得します。ファイル、データベースレコード、API応答などを含みます。
-
Prompts：サーバーが提供する再利用可能なプロンプトテンプレート。prompts/listで発見し、prompts/getで取得します。AIがサーバーのドメイン固有タスクに効果的にアプローチする方法を標準化します。
Function CallingおよびOpenAPIとの比較
MCPの位置づけを理解するために、2つの主要な代替手段と比較しましょう。
MCP vs Function Calling
Function calling（OpenAI、Anthropicなどが使用）は、各APIリクエストにインラインでツール定義を埋め込みます。開発者はJSON Schemaとしてツールを記述し、LLMが呼び出すツールとパラメータを選択します。
| 側面 | Function Calling | MCP |
|---|---|---|
| ツール定義 | APIリクエストにインライン | 外部サーバーで定義 |
| 発見 | なし（開発者が提供） | 動的（tools/listで発見） |
| 状態 | ステートレス（リクエストごと） | ステートフル（セッションベース） |
| トランスポート | HTTPS API呼び出し | stdio、SSE、Streamable HTTP |
| 標準化 | ベンダー固有 | オープンスタンダード |
| 複数ツール | 手動オーケストレーション | プロトコルネイティブ |
MCP vs OpenAPI
OpenAPI（旧Swagger）はREST APIを記述する仕様です。AIが直接OpenAPI仕様を読み、API呼び出しを生成することも可能ですが、いくつかの重要な違いがあります。
| 側面 | OpenAPI | MCP |
|---|---|---|
| 目的 | REST API文書化 | AI-ツール通信 |
| AI最適化 | なし（汎用） | AI相互作用向けに設計 |
| セッション管理 | なし | 組み込み |
| 型安全性 | JSON Schema | JSON Schema + 実行時検証 |
| リソースモデル | URL + HTTPメソッド | URI + リソースタイプ |
採用タイムライン
MCPの進化を追ってみましょう：
- 2024年11月：AnthropicがMCPをオープンソースとしてリリース。初期バージョンはstdioトランスポートのみ。
- 2025年Q1：Claude Desktop、Cursor、WindsurfがMCPサポートを統合。開発者コミュニティが急速に拡大。
- 2025年Q2：SSEトランスポートが追加。リモートMCPサーバーが実用化。
- 2025年Q3：OpenAIがMCPサポートを発表。Google DeepMindがGeminiにMCP clientを統合。
- 2025年Q4：Streamable HTTPトランスポートがリリース。エンタープライズ採用が加速。
- 2026年Q1：MicrosoftがCopilotプラットフォームにMCPを採用。MCP Registry（公式サーバーカタログ）がローンチ。
- 2026年Q2：MCPが事実上のAIツール通信標準に。1,000以上の公式サーバーがRegistryに登録。
エージェント間通信の未来
MCPの次の進化は、エージェント間（A2A）通信です。現在のMCPはAIアプリケーション（host）と外部ツール（server）間の通信を定義していますが、AIエージェント同士が直接通信する機能はまだ初期段階です。
将来のビジョン：
- エージェントがMCPサーバーを公開：各AIエージェントが独自のMCPサーバーを持ち、他のエージェントが利用可能なツールとして発見・呼び出し可能
- マルチエージェントオーケストレーション：MCPゲートウェイが複数のエージェント間のタスク委任とデータフローを管理
- 標準化された委任プロトコル：エージェントが複雑なタスクをサブタスクに分解し、専門化されたエージェントに委任する標準的な方法
FAQ
Q：MCPはLSP（Language Server Protocol）と関係がありますか？ A：はい。MCPはLSPからインスピレーションを受けています。両方ともJSON-RPC 2.0を使用し、capability negotiationパターンを使用し、client-serverアーキテクチャに従います。LSPがコードエディタをプログラミング言語サポートから分離したように、MCPはAIアプリケーションをツール統合から分離します。
Q：MCPサーバーを公開する際のセキュリティリスクは？ A：主なリスクには、認証バイパス、ツールの不正使用、データ漏洩、サービス拒否があります。OAuth 2.0認証の使用、入力バリデーション、レート制限、ツールレベルの認可、すべてのツール呼び出しの監査ログが対策として不可欠です。
Q：既存のREST APIをMCPサーバーに変換できますか？ A：はい。各APIエンドポイントをMCPツールとしてラップするのが一般的なパターンです。OpenAPI仕様からMCPサーバーを自動生成するツールも利用可能です。
Q：MCPのパフォーマンスオーバーヘッドはどの程度ですか？ A：JSON-RPCプロトコルのオーバーヘッドは最小限です。stdioトランスポートではマイクロ秒、HTTPトランスポートでは通常のHTTPリクエストと同等です。ボトルネックは通常、ツールの実行自体（データベースクエリ、API呼び出し）にあります。
Q：MCPメッセージにサイズ制限はありますか？ A：プロトコル自体にサイズ制限はありません。実際の制限はトランスポートとインフラストラクチャに依存します。本番デプロイメントでは、個々のツールレスポンスを10 MB以下に保ち、大きなデータセットにはページネーションまたはストリーミングを使用してください。