なぜMCPはリリース1年半で全AIベンダーが採用する業界標準になったのか

2024年11月26日、Anthropicは短いブログ記事を1本公開した。タイトルは「Introducing the Model Context Protocol」。当時、技術コミュニティの一部がざわめいたものの、多くの人にとってはAI企業が定期的に出す仕様発表の一つに過ぎなかった。

それから16ヶ月後の2026年3月——このプロトコルのSDK月間ダウンロード数は9,700万件に達し、10,000以上のサーバーが世界中で稼働している。OpenAI、Google、Microsoft、Amazonという競合4社が全て採用し、Claude・ChatGPT・Gemini・Microsoft Copilot・Visual Studio Codeといった主要AIクライアントが標準対応している。

Anthropicが独自プロトコルを公開し、競合他社がそれを採用する——この展開は、歴史的な技術標準化の文脈で見ても異例の速さだ。一体何が起きたのか。

AIとツールの「接続爆発」問題

MCPが登場する前のAI開発現場では、ある構造的な問題が深刻化していた。「M×N問題」と呼ばれるものだ。

AIモデル（M個）と外部ツール（N個）を連携させるとき、それぞれのペアに専用のコードが必要になる。例えば10種類のAIと20種類のツールを組み合わせるだけで200本のアダプターが必要になる。開発コストは組み合わせ数に比例して指数的に膨張する。

MCPはこの構造を根本から変えた。AIとツールが一度MCPというインターフェースに準拠すれば、あとは接続するだけだ。接続数は「M×N」から「M+N」に圧縮される。同じ10×20の例であれば、必要な実装は200本から30本に激減する。

比喩として頻繁に使われるのがUSB-Cだ。かつてのデバイスには独自充電ポートがあり、メーカーごとにケーブルが異なっていた。USB-Cという統一規格が登場したことで、「どのデバイスにどのケーブルが使えるか」を考える必要がなくなった。MCPはAIの世界のUSB-Cを狙った設計である。

競合他社がなぜ他社のプロトコルを採用したのか

テクノロジー産業の歴史を見ると、競合他社が同一企業のプロトコルを採用する事例は珍しい。通常、各社は自社の標準を広めようとし、競合の技術を「無視」か「対抗規格」で潰そうとする。

2025年3月、OpenAIのCEOサム・アルトマンはXでこう投稿した。「People love MCP and we are excited to add support across our products.」そして同月、OpenAI SDK、ChatGPTデスクトップアプリ、Response APIへのMCP対応を発表した。GoogleはGeminiとGoogle CloudへのMCP対応を発表し、Microsoftは2025年5月のBuild 2025カンファレンスでGitHubとWindowsへの統合を公表した。

なぜ競合他社がこの判断を下したのか。The New Stackが報じた分析によれば、「独自の統合エコシステムを維持するコスト」が理由だ。MCPを拒否して独自プロトコルを維持するということは、世界中の開発者に対して「うちのAIを使いたければ、うちの独自仕様も学べ」と要求し続けることを意味する。エコシステムの分断はユーザー離れを招く。MCPという共通規格を採用する方が、長期的には自社製品の普及に有利だという計算が働いたのだ。

Linux Foundation傘下への移管が生んだ「中立性」

2025年12月、Anthropicは予想外の動きに出た。自社が生み出したMCPをLinux Foundation傘下の新組織「Agentic AI Foundation（AAIF）」に寄贈したのだ。共同創設者はAnthropicのほか、Block（旧Square）とOpenAI——つまり競合他社が同じテーブルに座る形となった。

この寄贈は技術コミュニティに大きなシグナルを送った。「MCPはAnthropicの製品ではなく、業界のインフラだ」というメッセージだ。

Linux Foundationは、LinuxカーネルやKubernetesを管理してきた実績ある中立的組織だ。その傘下に置かれることで、MCPは「特定企業が突然仕様変更したり、使用料を取り始めるリスク」から免れた。企業のAIシステムの根幹に組み込むプロトコルとして、これは決定的な安心材料となった。

NTTデータや富士通など日本の大手IT企業が相次いでMCP関連の技術検討を公開しているのも、この中立性担保が背景にある。企業の情報システム部門が最も警戒するのは「ベンダーロックイン」だ。Linux Foundation管理のプロトコルはその不安を払拭する。

開発者コミュニティが作ったエコシステムの自己増殖

2024年11月のMCP公開当初、対応サーバーは約100個だった。2026年2月には8,600以上に急増し、2026年3月には10,000の大台を突破している。この成長はAnthropicが主導したものではない。

低い参入障壁が鍵だ。MCPサーバーの実装は、JSONの入出力を処理できるエンドポイントを用意するだけで始められる。GitHubやSlack、Notion、GoogleカレンダーへのMCPサーバーを開発者が自発的に作り、オープンソースとして公開した。誰かが作ったサーバーを使った開発者が「他のツールにも欲しい」と次のサーバーを作る——この連鎖が自己増殖するエコシステムを形成した。

Dockerの初期普及と構造が重なる。Dockerも登場当初は「Linuxコンテナの標準化ツール」として小規模なコミュニティに使われていた。しかし、一度「コンテナを作って配布する」という体験が普及すると、DockerHubに登録されるイメージ数が指数関数的に増え、使わない選択肢がなくなるほど生態系が充実した。MCPはその速度をさらに上回っている。

セキュリティ問題との向き合い方が信頼を作った

普及の途上で、MCPは深刻な批判にも晒された。2025年4月、研究者らが「ツール中毒攻撃（Tool Poisoning Attack）」と呼ぶ脆弱性を公表した。悪意あるMCPサーバーがAIに不正な指示を注入できる可能性を示したもので、プロジェクトの信頼性を揺るがしかねない事態だった。

MCPチームの対応は迅速だった。脆弱性を隠蔽することなく、コミュニティと協力して仕様の修正と認証フレームワークの強化に取り組んだ。2025年3月には、Streamable HTTPトランスポートとOAuth 2.1ベースの認可フレームワークを導入し、「URLを一つ渡すだけで安全に統合できる」状態を実現した。

この公開的な脆弱性対応は、OAuth 2.0やTLSが批判と改善を経て業界標準になった経緯と重なる。重要なのは問題の有無ではなく、問題への向き合い方だ。透明な対応が開発者・企業システム担当者の長期的な信頼を醸成した。

2026年「エンタープライズMCP元年」が意味すること

Salesforce、Cloudflare、New Relicがガバナンスと可観測性ツールの整備を進め、2025年夏には「実験的プロトコル」から「本番環境対応」への転換が完了した。2026年Q3-Q4にはエンタープライズ向けに、監査ログ・コンプライアンス対応、SSO統合認証、ゲートウェイ・ポリシー管理が計画されている。

日本市場でも変化は着実に始まっている。NTTデータが公表したマルチエージェントアーキテクチャではMCP/A2Aプロトコルを中核に据え、富士通はUvanceブランドのAI開発プラットフォームへの統合を進めている。

一つのプロトコルが業界標準になるとき、対応が遅れた企業には大きな摩擦が生まれる。HTTPが普及した1990年代後半、Webに対応しなかった企業がユーザーを失っていったように——MCPへの対応遅れは、AIエコシステムへのアクセスを制限するリスクをはらんでいる。

標準化競争は「誰が勝つか」ではなく「いつ始まるか」だった

振り返ると、MCPの普及は偶然の産物ではない。「M×N問題」という業界共通の痛点に対して、「M+N」というシンプルな解法を提示したこと。オープンソース化とLinux Foundation傘下への移管による中立性の確保。低い参入障壁が生んだコミュニティ主導のエコシステム拡大。そして透明な脆弱性対応が築いた信頼——これらが重層的に絡み合った結果が、9,700万ダウンロードという数字だ。

TCP/IPがインターネットを、HTTPがWebを可能にしたように、MCPはAIエージェントの時代における「つなぐ」行為の標準形になろうとしている。その標準化が完了するとき、MCPを「使うかどうか」は選択肢ではなく、AIを使う際の前提条件となる。