AIエージェント・プロトコル戦争：MCP、A2A、そしてエージェント型AIの未来を決める標準化争い

2026年2月17日、米国国立標準技術研究所（NIST）はAIエージェント標準化イニシアチブの設立を発表し、3つの柱——業界主導の標準、オープンソースプロトコル開発、エージェントセキュリティ研究——に焦点を当てた。^[1]その6日前の2月13日、Google Chrome 146 CanaryがWebMCPを内蔵して出荷され、世界中の数十億のウェブページがAIエージェントの構造化ツールとして直接機能できるようになった。^[2]さらに遡る2025年12月には、AnthropicがModel Context Protocol（MCP）をLinux Foundationの新設されたAgentic AI Foundation（AAIF）に寄贈し、OpenAI、Block等の主要プレイヤーと共同設立、プラチナメンバーにはAWS、Google、Microsoft、Bloomberg、Cloudflareが名を連ねた。^[3]MCPのPythonとTypeScript SDKは月間ダウンロード数9,700万を超え、GoogleのAgent-to-Agentプロトコル（A2A）は100社以上の支持を獲得した。^[4]これらの出来事は孤立して起きているのではない——総合すると、AIエージェントのエコシステムが1980年代のTCP/IP対OSI「プロトコル戦争」と構造的に類似した歴史的転換点を迎えていることを示している。あの初期の争いでは、草の根主導のTCP/IPが国際標準化機構の精緻に設計された7層OSIモデルを打ち負かし、今日のインターネットアーキテクチャの基盤を築いた。40年後の今、AIエージェントの通信標準を定める者がエージェント型AI時代のインフラを制御する。これは単なる技術的問題ではなく、地政学、産業戦略、ガバナンス哲学の多次元的な競争である。

一、プロトコルのブレトンウッズ・モーメント：NISTの歴史的宣言

NISTのAIエージェント標準化イニシアチブは通常の技術的発表ではない——米国連邦政府がAIエージェントの相互運用性標準の策定に国家レベルで介入した初の事例を示す。イニシアチブの憲章は、CAISI（NISTのAI標準調整機関）が「エージェント型AI技術のフロンティアにおけるアメリカのリーダーシップを確立する」ことを目指すと明示的に述べている。^[1]計画は3つの柱を設定する。第一に業界主導のオープンソースプロトコル標準の推進、第二にAIエージェントのセキュリティとアイデンティティ認証の研究アジェンダの確立、第三に省庁横断的な規制枠組みの調整である。具体的にはNISTは2つの緊急情報提供依頼（RFI）を発行した。エージェントセキュリティRFIの締め切りは2026年3月9日、エージェントアイデンティティの概念文書は4月2日に公開予定である。

この発表を歴史的文脈に位置づけると、その重要性がさらに明確になる。1944年のブレトンウッズ会議は戦後の国際金融秩序の基盤を築いた——米ドルが世界の基軸通貨となり、国際通貨基金と世界銀行が誕生した。NISTの発表はある意味で類似した役割を果たしている——AIエージェントの相互運用性に対して米国中心の秩序の枠組みを確立しようとしている。これは偶然ではない。Gartnerが2026年末までに企業アプリケーションの40%にAIエージェントが組み込まれると予測している中（2025年には5%未満）、AIエージェントの「基本的な配管」は戦略的インフラとなる——1990年代のHTTP/TCP/IPと同様に。^[5]

しかしブレトンウッズとは異なり、AIエージェントの標準策定は政府主導の閉じた会議室で行われているのではなく、オープンソースコミュニティ、テック大手、ベンチャーキャピタル、規制当局の間のマルチステークホルダーの競争の中で展開されている。Linux FoundationのAgentic AI Foundationはすでに主導権を握っている。その創設プラチナメンバーリストはシリコンバレーの「名鑑」のようだ——Anthropic、OpenAI、AWS、Google、Microsoft、Cloudflare、Block、Bloomberg、Intuit、Replit、Samsung、PayPal、Salesforce、SAP。^[3]初期プロジェクトにはMCP（Anthropicが寄贈）、A2A（Googleが寄贈）、AGENTS.md（OpenClawのSteinbergerが主導）、goose（Blockが提供）が含まれる。この顔ぶれはAIエージェントの標準化争いがゼロサムゲームではなく、「共競争」（co-opetition）のゲームであることを示している——競合企業が標準層で協力しつつ、アプリケーション層で競争するのだ。

二、TCP/IP対OSIの教訓：草の根標準はいかにして委員会設計を打ち負かしたか

現在のAIエージェント・プロトコル戦争の行方を理解するために、最も示唆に富む歴史的先例は1980〜90年代のTCP/IP対OSIの戦いである。^[7]

1978年、国際標準化機構（ISO）はOSI（開放型システム間相互接続）参照モデルの設計を開始した——エレガントな7層のネットワークアーキテクチャで、統一的なグローバル通信標準となることが意図されていた。OSIは政府に支持され、通信大手によって推進され、国際委員会によって設計され、当時最も権威ある制度的裏書きを持っていた。一方、TCP/IPはDARPA（国防高等研究計画局）の資金で大学の研究者が開発した「十分に機能する」4層プロトコルだった。OSIのエレガントな階層化も、委員会の綿密な設計も、国際機関の公式認証もなかった。しかしOSIにはない一つの決定的優位性を持っていた。動作するコードである。

TCP/IPの勝利は3つの構造的特徴に帰せられる。第一に、シンプルさ。TCP/IPの4層アーキテクチャはOSIの7層モデルよりも理解しやすく、実装しやすく、デバッグしやすかった。複雑さは標準採用の天敵である——抽象化の層が一つ増えるごとに、実装の障壁が一つ加わる。第二に、実行可能性。TCP/IPはIETFの「大まかな合意と動作するコード」の哲学に従った——RFC（Request for Comments）文書は理論から設計された仕様ではなく、すでに動作している実装の文書化された記述であった。対照的にOSIは何年もかけて仕様を設計し、その後に実装を試みたが、多くの設計が実際には非実用的であることを発見した。第三に、オープン性。誰でもRFCを提出し、プロトコルを実装し、議論に参加できた。OSIの標準策定プロセスは公式の委員会メンバーに限定され、遅く政治的であった。

この歴史がAIエージェント・プロトコル戦争に対する教訓は深遠である。MCPとA2AはTCP/IPのパターンを再現している——オープンソースで、コミュニティ主導で、実際のユースケースによって反復的に進化するプロトコルであり、委員会設計ではない。MCPの月間9,700万ダウンロードは政策的命令の結果ではなく、デベロッパーコミュニティが「足で投票した」結果だ。^[3]対照的に、EU AI法のAIエージェント相互運用性に関する規定は——善意に基づくものの——「AI時代のOSI」となるリスクがある。トップダウンで、精緻に設計されているが、実践から乖離する可能性がある。TechPolicy.Pressの分析はEU AI法第73条のガイドライン草案が「憂慮すべき準備不足を露呈している」と率直に述べる——マルチエージェントのインシデント対処、クロスシステムの責任帰属、エージェントの信頼チェーンのためのツールが不足している。^[8]

デジタル主権と国際技術ガバナンスに関する過去の研究において、一つのパターンを繰り返し観察してきた。技術標準の進化において、「最初にネットワーク効果を達成した標準」が勝利する傾向があり、「最もよく設計された標準」が勝利するわけではない。VHSがBetamaxを、WindowsがOS/2を、TCP/IPがOSIを打ち負かした——毎回、市場採用の速度が技術的優越性に勝った。MCPはこの競争で先行者優位をすでに獲得しているが、歴史はまた警告する。先行者優位は永続的優位ではない——AOLはかつてインターネットの代名詞であり、MySpaceはかつてソーシャルメディアの王者だった。鍵はプロトコルが初期設計に固定されることなく、新たな需要に対応して進化し続けられるかどうかである。

三、3層プロトコルアーキテクチャ：MCP、A2A、WebMCPの補完的エコシステム

2026年2月時点で、AIエージェントのプロトコルアーキテクチャは3つの補完的な層に結晶化しつつあり、それぞれが異なる通信ニーズに対応している。

第1層：MCP（Model Context Protocol）——エージェントとツール間の標準インターフェース。Anthropicは2024年11月にMCPを最初にリリースし、「AIのUSB-C」として位置づけた——AIエージェントがあらゆる外部ツール、データソース、サービスに接続するための標準化されたインターフェースだ。^[3]USB-Cがノートパソコンをモニター、ハードドライブ、充電器に異なるコネクタなしで接続できるように、MCPはAIエージェントがデータベースクエリ、API呼び出し、ファイル操作、ウェブブラウジングを各ツールごとにカスタム統合コードを書くことなく実行できるようにする。MCPのPythonとTypeScript SDKは月間ダウンロード数9,700万を超えた——この数字の重要性は、MCPが「一社のプロトコル」から「エコシステム全体のインフラ」へと進化したことにある。AnthropicがMCPをLinux Foundationに寄贈したのはまさにこの私的なものから公的なものへの移行を加速するためだ——GoogleがKubernetesをCNCF（Cloud Native Computing Foundation）に寄贈したように、寄贈は制御の放棄ではなく、排他性を手放すことでより大きなエコシステムの影響力を獲得することである。

第2層：A2A（Agent-to-Agentプロトコル）——エージェント間通信の標準。GoogleはMCPがカバーしない問題に対処するために2025年4月にA2Aをリリースした。複数のAIエージェントが協力する必要がある場合——例えばカスタマーサービスエージェントが技術的な問題をエンジニアリングサポートエージェントに引き継ぐ必要がある場合——どのように通信するのか？^[4]A2Aはエージェント間の能力発見、タスク委任、状態同期、認証の標準化されたプロセスを定義する。ローンチ時にはSalesforce、SAP、PayPal、ServiceNowを含む50社以上の支持があり、2026年2月までに支持企業は100社を超えた。独自にACP（Agent Communication Protocol）を開発していたIBMは2025年末にA2Aへの統合を発表し、エージェント間通信層でのA2Aの支配的地位をさらに強固にした。

第3層：WebMCP——ウェブへの構造化されたエージェントアクセス。これは最も新しく、また最も革命的な層である。2026年2月13日、Google Chrome 146 CanaryがWebMCPのEarly Preview Programを搭載して出荷された。^[2]WebMCPはブラウザにnavigator.modelContext APIを公開し、AIエージェントがウェブコンテンツに構造化された方法でアクセスできるようにする——以前のようにスクリーンショットやHTMLパースに頼るのではなく。Googleのデータによれば、WebMCPはスクリーンショットベースの方法と比較してトークン効率を89%改善する。この数字の含意は広範だ。AIエージェントのウェブページとの対話コストが劇的に低下し、大規模なウェブ自動化が経済的に実現可能になる。WebMCPはGoogleとMicrosoftが共同開発した——2大ブラウザエンジン（ChromiumとEdge）の協力は、この標準が主流ブラウザで普遍的にサポートされることを事実上保証している。

これら3つのプロトコル層の補完的関係は、企業シナリオを通じて説明できる。あるAIエージェントが幹部のために部門横断的な調達決定を処理するタスクを任されたとしよう。エージェントはMCPを使用してERPシステムに接続し在庫データを照会し、CRMでサプライヤーの履歴を確認し、財務システムで予算残高をチェックする。法務部門のコンプライアンスレビューが必要だと判明した場合、A2Aを使用してレビュータスクを法務部門のAIエージェントに委任し、タスクステータスをリアルタイムで同期する。サプライヤーの最新見積もり（サプライヤーのウェブサイトにのみ掲載）を確認する必要がある場合、WebMCPを使用して人間のブラウザ操作をシミュレートするのではなく構造化された方法でウェブコンテンツにアクセスする。3つのプロトコル層はそれぞれの機能を果たし、エージェント型AIの完全な通信インフラを形成する。

Deloitteの2026年企業AIレポートはこの3層アーキテクチャのガバナンス課題を特定している。現在23%の組織がエージェント型AIを中程度のレベルで使用しており、2年以内に74%に上昇すると予測される。^[9]しかし「エージェントのスプロール」——異なる部門が異なるプロトコル、異なるフレームワーク、異なるAIモデルのエージェントを使用すること——がCTOの最大の懸念となっている。統一されたプロトコル標準なしには、企業が直面する問題は「AIエージェントが少なすぎる」ことではなく「互換性のないAIエージェントが多すぎる」ことである——そしてこれがまさに標準化の経済的根拠である。

四、OpenClawのアーキテクチャの教訓：なぜ相互運用性がAIエージェントの成否を決めるか

OpenClawの爆発的成長——14万5千以上のGitHub Starと2万以上のFork——は単なるオープンソースプロジェクトの成功物語ではなく、なぜ相互運用性が重要かの生きたケーススタディである。^[10]

OpenClawのアーキテクチャ設計は多層プロトコル統合の範例である。最下層はMCPツール層——OpenClawは当初からMCPをネイティブにサポートし、エージェントがMCP標準に準拠するあらゆる外部ツールに接続できるようにした。中間層はチャネルアダプター——OpenClawはLINE、Slack、Discord、Telegramを含む複数のメッセージングプラットフォームをサポートし、それぞれに標準化されたアダプターを備える。最上層はゲートウェイ——ルーティング、認証、タスク割り当てを担当する統一的なエントリーポイントである。このアーキテクチャの成功は、OpenClawが各ツールやプラットフォームに対してカスタム統合を書く必要がないことにある——標準化されたプロトコル層に依存して異種性を処理する。

OpenClawの創設者Peter Steinbergerが主導するAGENTS.md仕様はAgentic AI Foundationの最初のプロジェクトの一つとなった。^[3]AGENTS.mdはAIエージェントがコードリポジトリ内で自身の能力、制約、相互作用ルールを宣言するための標準化された方法を定義する——robots.txtが検索エンジンクローラーにウェブサイトのインデックス方法を伝えるように、AGENTS.mdはAIエージェントにプロジェクトとの対話方法を伝える。この一見小さな標準化の取り組みは、実際にはコアな問題に対処している。マルチエージェントの世界で、エージェントは互いの能力をどう「理解」するか？

2026年2月15日、SteinbergerはOpenAIへの参画を発表すると同時に、OpenClawを独立した財団に移管した。^[10]この動きの戦略的意義は、オープンソースのAIエージェントエコシステムと商業AIプラットフォームが共有標準を通じて収斂していることを示す点にある。Steinbergerは「買収された」のではない——彼はオープンソースコミュニティの経験を世界最大のAI企業の一つに持ち込み、OpenClawは独立したオープンソースプロジェクトとして存続し続けた。このパターンはBrendan Eich（JavaScriptの作成者）がNetscapeからMozillaへ移った軌跡と構造的に類似している。個々の創作者が元のプロジェクトを去り、プロジェクトはコミュニティが統治する財団に移管され、創作者は新しい機関でその技術のより広範な採用を推進する。

しかし相互運用性の欠如はAIエージェントプロジェクト失敗の主因となりつつある。Gartnerは2027年末までにエージェント型AIプロジェクトの40%以上が中止されると予測する——理由にはコスト超過、不明確なビジネス価値、不十分なリスク管理が含まれる。^[6]これら3つの原因のうち、相互運用性の欠如は共通の基底要因だ。異なるエージェントが異なるプロトコル、異なるアイデンティティ認証メカニズム、異なるタスク記述フォーマットを使用する場合、統合コストは指数関数的に増大し、ビジネス価値は実現しにくくなり、セキュリティリスクはすべてのプロトコル境界で増幅される。Deloitteのレポートは「エージェントのスプロール」——企業内の異なる部門が独立に互換性のないAIエージェントを導入すること——をプロジェクト失敗を引き起こす最大の組織的要因として直接特定している。^[9]

Meta Intelligenceを率いて企業のAIシステム導入を支援する実務経験から、相互運用性の問題の深刻さはほとんどの技術レポートの記述をはるかに超えている。2026年の典型的な中大規模企業は、SalesforceのAgentforce（A2Aをネイティブサポート）、MicrosoftのCopilot Studio（MCP + 独自プロトコル）、GoogleのVertex AI Agent（A2Aをネイティブサポート）、内製のカスタムエージェント（LangChainなどのフレームワークを使用する可能性）を同時に使用している場合がある。これらのエージェントが互いに通信し、状態を共有し、タスクを調整することはエンジニアリングの課題であるだけでなく、ガバナンスの課題でもある。台湾のAIガバナンス枠組みの分析で強調したように、技術標準の不在は技術コストを増大させるだけでなくガバナンスの空白を生む——エージェントAがエージェントBに特定のデータベースへのアクセスを要求する権限を持っているかどうかを誰も知らないとき、セキュリティ監査は推測ゲームとなる。

五、プロトコルセキュリティの致命的盲点：東西トラフィックと新たな攻撃サーフェス

AIエージェントプロトコルの急速な採用は、従来のサイバーセキュリティアーキテクチャでは効果的に防御できない新たな攻撃サーフェスを生み出している。Security Boulevardは2026年2月の詳細分析でこれを「東西トラフィック問題」と名付けた。^[11]

従来の企業サイバーセキュリティは主に「南北」トラフィック——外部（インターネット）と内部（企業ネットワーク）間の通信——に関心を持つ。ファイアウォール、WAF（Webアプリケーションファイアウォール）、IDS/IPSなどのセキュリティツールはこの方向のトラフィックを監視・フィルタリングするために設計されている。しかしAIエージェント間の通信（A2Aプロトコル経由）は「東西」トラフィックを生成する——クラウドサービスXのエージェントAがクラウドサービスYのエージェントBの機能を呼び出す通信経路は、従来のセキュリティ境界を完全にバイパスする。それは企業のサイバーセキュリティツールの「盲点」で発生する——外部攻撃でも典型的な内部アクセスでもない、まったく新しい形態の自律的なクロスシステム通信である。

さらに懸念されるのは、プロトコル設計者自身の実装にさえ深刻なセキュリティ脆弱性が存在することだ。Solo.ioのセキュリティ研究チームはAnthropicのGit MCPサーバーに3つのリモートコード実行（RCE）脆弱性——CVE-2025-68143、CVE-2025-68144、CVE-2025-68145——を発見した。攻撃ベクトルはMCPツール呼び出しに埋め込まれたプロンプトインジェクションだった。^[12]この発見の皮肉は、MCPの設計者であるAnthropicが、そのプロトコルが防止するよう設計されたまさにそのタイプのセキュリティ問題を、自社のMCPサーバー実装に抱えていたことだ。これはAnthropicへの批判ではない——構造的な課題を明らかにしている。AIエージェントの世界では、セキュリティ境界はもはや「入力検証」ではなく「意図検証」である。従来のセキュリティツールはHTTPリクエストにSQLインジェクション構文が含まれているかをチェックできるが、一見正常なMCPツール呼び出しに悪意のあるプロンプトインジェクションが隠されているかどうかは容易に判断できない——プロンプトインジェクションはプログラミング構文の構造的脆弱性ではなく、自然言語の意味的曖昧性を悪用するからだ。

arXivの体系的なセキュリティ脅威モデリング研究は問題の深さをさらに明らかにしている。^[13]研究者たちは4つの主要AIエージェントプロトコル——MCP、A2A、Agora、ANP——のセキュリティ脅威モデルを比較し、いくつかの体系的なプロトコル横断的弱点を特定した。エージェントアイデンティティのなりすまし、能力宣言の偽造、タスクチェーンの汚染、信頼グラフ攻撃である。「信頼グラフ攻撃」は特に危険だ。マルチエージェント環境で、エージェントAがエージェントBを信頼し、エージェントBがエージェントCを信頼している場合、侵害されたエージェントCは信頼チェーンを通じてエージェントAを間接的に操作できる——エージェントAはプロセス全体を通じてエージェントCの存在をまったく認識しないまま。この種の「カスケード信頼障害」は分散システムではよく知られた課題だが、AIエージェントの文脈ではエージェントの意思決定が確定的ではなく確率的推論に基づくため増幅される——悪意のある行動の検出が極めて困難になる。

NISTがAIエージェント標準化イニシアチブにおいてエージェントセキュリティを最優先の研究課題として掲げ、RFIの締め切りを2026年3月9日——2週間弱後——に設定したこと自体が問題の緊急性を物語っている。^[1]一方、2026年8月からのEU AI法の全面施行後、その第73条のガイドライン草案はマルチエージェントインシデントの責任帰属について「憂慮すべき準備不足を露呈している」。^[8]米国のAWSに展開されたエージェントAがEUのAzureに展開されたエージェントBを呼び出してアジアの顧客データを含むタスクを処理し、このタスクチェーンのどこかで問題が発生してデータ漏洩に至った場合——どの管轄権の法律が適用されるのか？誰が責任を負うのか？現在、どのプロトコル標準も法的枠組みもこの問いに完全に答えることはできない。

越境データ流通立法に関する過去の研究において、越境ガバナンスの課題は技術進化のペースが立法のペースをはるかに上回ることにある。AIエージェントプロトコルのセキュリティ問題はこの構造的矛盾を再現している——プロトコルはすでに数千万の開発者に採用され数百の企業に導入されているが、セキュリティ標準はまだRFIの段階にある。これは規制の怠慢ではなく、エージェント型AI技術の指数関数的な発展速度と制度構築の線形的な速度の間の根本的な時間差を反映している。W3CはすでにAIエージェントプロトコルコミュニティグループを設立し、ウェブ標準レベルでセキュリティ仕様を構築しようとしているが、正式なウェブ標準の完成は2026〜2027年まで見込めない。^[15]それまでの間、AIエージェントのセキュリティは個々の開発者と企業の自主規制に大きく依存する——そしてOpenClawの73件のセキュリティ脆弱性が示すように、自主規制の有効性には限界がある。

この文脈において、AIエージェント・プロトコル戦争の真の賭けは「どのプロトコルが勝つか」だけではなく、「セキュリティ上の大惨事が発生する前に、プロトコル標準がシステミックリスクを防止できるほど成熟できるか」である。TCP/IPの歴史は警告的な教訓を提供する。TCP/IPが大規模に採用された後の数十年間、その元の設計では想定されていなかったセキュリティ問題が次々と浮上した——DDoS攻撃からBGPハイジャックまで——それぞれが事後的なパッチワーク修正を必要とした。AIエージェントプロトコルがこの歴史を繰り返した場合、結果ははるかに深刻になりうる。なぜならAIエージェントはデータを伝送するだけでなく判断を実行し、システムを接続するだけでなくビジネスプロセスを管理するからだ。プロトコル層のセキュリティ脆弱性はTCP/IP時代にはデータ漏洩を引き起こす可能性があったが、AIエージェント時代には自律的な判断が制御不能に陥る可能性がある——そしてそれらの判断が金融取引、医療診断、インフラ管理に関わる場合、その帰結はデータ漏洩の範囲をはるかに超える。Gartnerがエージェント型AIプロジェクトの40%が中止されると予測する中、プロトコルセキュリティの問題が採用の初期段階で体系的に対処されなければ、この中止率はさらに上昇する可能性がある——そしてすでに導入されたシステムが中止される前に取り返しのつかない損害を引き起こしている可能性がある。^[6]