A2AとMCPが同じAAIFへ——それでも残るプロトコル間の継ぎ目

AIエージェントを複数のベンダーやツールにまたがって動かそうとすると、多くの場合、接続の規格が課題になります。

どのプロトコルを使えば、自社のエージェントは他社のエージェントやツールと相互運用できるのか。

そして、その接続に必要な認証・認可・監査の仕組みを、どこまで共通化できるのか。

接続方式だけでなく、その規格を誰が管理し、どのような手続きで変更するのかも、長期的な依存関係を左右します。

A2AがAAIFのホストプロジェクトとして加わった

2026年8月17日、Linux Foundation傘下の中立組織Agentic AI Foundation（以下AAIF）が、エージェント間通信の標準であるA2Aを、ホストプロジェクトとして迎え入れたと公式ブログで発表しました。

これにより、エージェントとツールの接続を標準化するMCPと、エージェント同士の連携を標準化するA2Aが、同じAAIFのプロジェクト群に並んだことになります。

本稿で扱いたいのは、この並びが何を共通化し、何を共通化しないのかという線引きです。

そしてもう一つ、同じ財団に入ってもなお残る、2つのプロトコルの「継ぎ目」の話をします。

何が起きたか——時系列を正確に置く

まず事実関係を整理します。

AAIFは2025年12月9日、Linux Foundationが設立を発表した組織です。

設立時の発表では、AnthropicがMCPを、BlockがローカルファーストのAIエージェント基盤「goose」を、OpenAIがAIコーディングエージェント向けの指示形式「AGENTS.md」を、それぞれ創設プロジェクトとしてAAIFへ提供したことが説明されています。

A2Aの経緯は、これとは別の時系列を持ちます。

AAIF公式ブログによれば、GoogleはA2Aを2025年4月に公開し、AWS・Cisco・Google・Microsoft・Salesforce・SAP・ServiceNowといった創設組織とともに、Linux Foundationへ寄贈しました。

Linux Foundationが「Agent2Agent Protocol Project」の発足を発表したのは2025年6月23日です。

つまりA2Aは、今回より前から既にGoogle単独の管理を離れ、Linux Foundationの下でベンダー中立に運営されていたプロトコルです。

その上で2026年8月17日、A2AはAAIFのホストプロジェクトとして迎え入れられました。

今回起きたのは所有主体の移転ではなく、MCPなどと同じAAIFのプロジェクト群に加わったということです。

会員数についても、公式に確認できる数字を置いておきます。

AAIFの設立発表に掲載されていた参加組織は49でした。

その後も会員は段階的に増えており、Linux Foundationは2026年8月13日、直近3か月で57組織が加わって会員総数が247組織になったと発表しています。

設立からおよそ8か月での推移です。

この増加は、オープンで相互運用可能なエージェント基盤への関心と、仕様形成に共同で参加しようとする組織の広がりを示しています。

ただし会員数は、各社がA2AやMCPを本番環境で採用したことまでを示す数字ではありません。

同じ財団に入ったが、技術統治は別々のまま

ここで混同されやすいのが、「同じ財団に入ること」と「統治が一つに統合されること」の違いです。

今回共通化されたのは、AAIFという中立なホスト、財団レベルの会員制度、資金や戦略面の意思決定、そしてプロジェクト間で協調する場です。

MCP側の公式発表では、AAIFのGoverning Boardが戦略的投資・予算配分・会員募集・新規プロジェクトの承認を担う一方、各プロジェクトは技術的方向と日常運営について完全な自律性を保つと説明されています。

Linux Foundationは中立な家とインフラを提供するのであって、MCPの技術的方向を指示することはない、とも明記されています。

実際、仕様変更や技術的方向を決める仕組みは、2つのプロトコルで別々のままです。

A2Aは、AWS・Cisco・Google・IBM Research・Microsoft・Salesforce・SAP・ServiceNowの代表者で構成されるTechnical Steering Committeeが技術面を統治しています。

MCPは、Maintainer・Core Maintainer・Lead MaintainerからなるMCP Steering Groupが技術的方向を決め、仕様変更はSEP（Specification Enhancement Proposal）という提案プロセスを通ります。

MCPの統治文書には、技術統治への参加資格は企業ではなく個人に属し、特定企業のための席は用意されていないと書かれています。

同じ屋根の下に入ったことと、規格が一つに融合することは別だという点は、押さえておく価値があります。

標準は「接続の形式」だけを決めているわけではない

ここも誤解されやすい部分なので、正確に書きます。

A2AやMCPの仕様は、単なるメッセージ形式の取り決めにとどまりません。

A2Aの仕様には、Agent Cardで宣言する認証方式、認証済みIDに基づく認可スコープの設定、OAuth2のスコープ、タスクの取消しといった項目が含まれています。

MCPの仕様にも、ツール呼び出しに対して人間が拒否できる余地を常に持たせるべきだという指針、機微な操作での確認画面、サーバー側のアクセス制御と入力検証、クライアント側のタイムアウト、そして監査目的でのツール利用ログの記録が挙げられています。

AAIF自身も、Identity & Trust（委任・ドメイン横断のアイデンティティ・エージェント間の権限移動）、Observability & Traceability（実行追跡・システム横断の相関・監査とフォレンジック）、Security & Privacy（セキュアな運用・標準的なベストプラクティス・敵対的テスト）、Accuracy & Reliability（障害管理・復旧プロトコル）、Governance, Risk & Regulatory Alignment（リスク分類・規制との対応）といったワーキンググループを設けています。

つまり、権限・監査・停止といった領域は、標準や財団の関心の外にあるわけではありません。

ここを「標準は接続形式しか決めない」と説明してしまうと、標準側の価値を過小評価することになります。

一方で、A2Aの仕様は、認可のスコープを設けることは求めつつ、どのような権限が存在し、それを誰にどう与えるかという実際の認可ルールは各エージェントの認可モデルに委ねると位置づけています。

仕組みは共通化できても、その仕組みに何を入れるかは各社が決めることになります。

継ぎ目を一つの処理で追う

抽象的な線引きだけでは、実務で何を確認すべきかが見えにくいので、一つの処理を最後まで追ってみます。

次のような、ごく普通のマルチエージェント処理を考えます。

1. エージェントAが、MCP経由で顧客管理ツールから顧客情報を取得する
2. エージェントAが、A2A経由でエージェントBへ調査タスクを委任する
3. エージェントBが、別のMCPサーバーを使って外部の処理を実行する
4. エージェントBが、結果をA2A経由でエージェントAへ返す
5. エージェントAが、MCP経由で顧客管理ツールへ更新を書き込む

この流れは、MCPとA2Aを交互に使い、両者の境界を4回横断しています。

そして問題が起きやすいのは、それぞれのプロトコルの内側ではなく、両者が接する継ぎ目です。

AAIFが公開したMCP開発者サミットの報告でも、「MCPが終わりA2Aが始まる場所」を扱ったセッションが取り上げられ、トレースの可視性、トークンの委任、スキーマの対応づけ、取消しの意味論といった論点がこの境界に集中すると整理されています。

同セッションは、この継ぎ目こそがシステムそのものだと表現しています。

先ほどの5ステップに対して、実務で確認したい問いは次のようなものになります。

• ステップ2でタスクを委任するとき、最初に処理を始めた利用者のIDは、エージェントBまでどう引き継がれるのか
• ステップ3で、エージェントBに元のMCP権限をそのまま再利用させてよいのか、それとも別の資格情報に絞るのか
• ステップ5の書き込みは、誰の権限で行われたことになるのか
• ステップ2のA2Aタスクを途中で取り消したとき、ステップ3で走っている下流のMCPツール実行も止まるのか
• ステップ1からステップ5までのログを、後から「一つの処理」として関連付けられるか

私たちが重要だと考えているのは、これらの問いの答えが、どちらのプロトコルに準拠しているかだけでは決まらないという点です。

A2Aは委任の伝え方を、MCPはツール呼び出しの作法を、それぞれ規定しています。

しかし「A2Aで委任したときに、下流のMCP権限をどう縮小するか」は、両者の仕様のどちらにも属さない、接続する側の設計判断として残ります。

取消しの伝播も同じです。

A2Aにはタスクの取消しがあり、MCPにもエラーやタイムアウトの扱いがあります。

その2つを繋いで「上流を止めたら下流も止まる」状態にするのは、実装する側の仕事です。

共通機構と自社の判断を分ける（叩き台）

継ぎ目を意識しながら、どこまでが標準側の共通機構で、どこからが自社の判断かを整理すると、次のようになります。

ここに挙げる粒度はあくまで一例で、具体的な範囲や運用の厳しさは、業務内容・リスク許容度・規制環境に合わせて各社が決めるものです。

論点	標準・財団が提供し得るもの	各社が決めて実装するもの
相互運用	メッセージ形式、能力の発見、タスク委任、ツール接続	どの製品・相手先との接続を許可するか
認証・認可	認証方式、OAuthスコープ、Agent Card、認可スコープの設定	誰・どのエージェントに、どのデータと操作を許可するか
承認	人間の確認を差し込む仕組みと推奨事項	どの操作を自動化し、金額・重要度のどこから承認必須にするか
監査	ツール呼び出しやタスク状態を記録する共通要素	保存期間、改変防止、閲覧権限、複数システムのログ相関、確認責任者
停止・失効	タスク取消し、エラーと状態遷移の共通機構	誰が停止できるか、停止の範囲、ロールバック、フェイルセーフ
継ぎ目の可視化	共通の観測方式やプロジェクト横断の議論の場	A2AとMCPをまたぐ処理に一意のIDを振り、追跡できる状態にすること
準拠性	仕様、SDK、相互運用要件	採用製品が仕様どおりかを誰が検証し、更新時にどう再評価するか

左の列が広がるほど、右の列の作業が楽になるのは確かです。

ただし右の列が消えることはありません。

標準化が進むと、何が楽になり、何が残るか

規格が整うことで、接続先ごとに専用の統合コードを作る負担は下がり得ます。

ただし、技術課題がなくなるわけではありません。

複数プロトコルをまたぐ認証、トレース、状態管理、取消しといった実装課題は残り、そこに加えて、自社として何をどこまで任せるかという組織上の判断が、より明確に表面化します。

技術課題が組織課題に置き換わるのではなく、両方が残ると考えたほうが実態に近いはずです。

同じ財団の下に複数のプロジェクトが集まることで、セキュリティ、アイデンティティ、監査、相互運用について、プロジェクト横断で議論する場は作りやすくなります。

前述のとおり、AAIFはそのためのワーキンググループを設けています。

ただし、この組織構造によってセキュリティ対応が実際に速くなったことや、各ベンダーの実装が安全になったことを示す実績は、現時点では確認できません。

これは今後期待される効果であって、既に実証された成果ではありません。

まとめ——共通の土台が広がった先に問われること

AAIFや各プロトコルは、認証・認可・監査・取消しなどに使える共通機構や指針を整えることができます。

実際、A2AとMCPの仕様は、接続形式だけでなくこれらの領域にも踏み込んでいます。

しかし、その仕組みを使って誰に何を許し、どこで人の承認を求め、どの条件で処理を停止するかという各社固有のポリシーを、財団が代わりに決めたり運用したりするわけではありません。

そして本稿で見たとおり、A2AとMCPが同じ財団に入っても、両者の継ぎ目でIDや権限や取消しをどう繋ぐかという設計は、接続する側に残ります。

A2AとMCPが同じAAIFへ集まったことで、共通の土台は広がりました。

次に問われるのは、その土台の上で、各社がどのような運用境界を置くかです。

情報確認について

本記事は2026年8月確認時点で、AAIF、Linux Foundation、A2AおよびMCPの公式発表・仕様・ガバナンス文書を主要な参照元として作成しています。

A2AがAAIFのホストプロジェクトとして参加した公式発表日は2026年8月17日です。

A2Aはそれ以前の2025年6月からLinux Foundation傘下で運営されており、今回初めてLinux Foundationへ寄贈されたものではありません。

A2AとMCPは同じAAIFの傘下にありますが、A2AはTechnical Steering Committee、MCPはMCP Steering Groupによる個別の技術統治を維持しています。

会員数247組織は、Linux Foundationが2026年8月に公表した新規会員に関する発表に基づいています。

MCPとA2Aの継ぎ目に関する整理は、AAIFが公開したMCP開発者サミット（ベンガルール）の報告に基づいています。

会員数・ガバナンス構造・各プロジェクトの運営体制・仕様の内容は、今後変更される可能性があります。

本稿における「財団レベルの統治」「プロトコル仕様・技術統治」「各社のポリシーと運用」という区分、および継ぎ目で確認すべき問いの整理は、公開資料をもとにしたMIFの分析です。