『相手の内部を知らなくていい』——A2AとManaged Agentsが辿り着いた同じ答え

グラレコ

GitHub上のスター数が23,200を超えている。v1.0.0のリリースは2026年3月。AWS、Microsoft、Bloomberg、Cloudflare、Googleがプラチナメンバーとして名を連ね、Anthropic・Block・OpenAIが創設に関わったAAIF（Agentic AI Foundation）という団体まで設立されている。

Agent2Agent Protocol（A2A）の規模感を並べてみると、これが単なる「新しいAPI仕様」の話ではないことが伝わると思う。主要プレイヤー全員が同じテーブルについたのはなぜか。そしてAnthropicのManaged Agentsと並べて読むと、ひとつの「収束」が見えてくる。

A2Aとは何か、そして何ではないか

2025年4月にGoogleが発表したA2Aは、AIエージェント同士の発見・通信・タスク委譲を標準化するオープンプロトコルだ。技術的な土台はHTTP、SSE、JSON-RPC 2.0という既存の標準仕様で、わざわざ新しいトランスポート層を発明していない点が面白い。

設計原則のひとつに「Opaque Agents（不透明なエージェント）」という概念がある。エージェントは内部メモリ・使用ツール・実装詳細を他のエージェントに共有しない、という考え方だ。通信相手が何のLLMを使っているか、どんなツールを持っているか、知らなくていい。

この原則がA2Aの核心だと思う。

同時期に発表されたManaged Agentsのエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」で説明されている設計思想も、同じ地点に向かっている。Handsは execute(name, input) → string というシンプルなインターフェースだけを外部に見せ、内部のコンテナ実装はサンドボックスの中に隠れている。BrainはHandsの内部を知る必要がない。

一方はオープンプロトコル、他方は内部アーキテクチャという全く異なる文脈で、同じ結論が出た。

プロトコルの仕組みを追う

A2Aの通信モデルは「Client（依頼する側）」と「Remote Agent（実行する側）」に分かれる。この分け方はManaged AgentsのBrain/Hands分離とほぼ対応している。考える側と動く側の分離という構造は同じだ。

エージェントの発見には「Agent Card」と呼ばれるJSONドキュメントが使われる。/.well-known/agent.json に配置され、エージェントの能力・スキル・エンドポイント・認証方式を記述する。HTTPの robots.txt や security.txt に近い発想だ。相手のエージェントが何者かを、会話を始める前に確認できる。

タスクの状態遷移は WORKING → INPUT_REQUIRED → COMPLETED / FAILED / CANCELED / REJECTED というライフサイクルで管理される。Managed Agentsでは外部の永続イベントログ（Session）がアペンドオンリーで記録されるが、A2AもSSEとWebhookによる非同期通知でタスクの進行状況を追跡できる。数秒から数日に及ぶ長時間タスクを想定しているのも共通している。

認証面ではOAuth 2.0、APIキー、mTLSを標準でサポートする。エンタープライズ環境での実運用を意識した設計で、「相手の内部を知らなくていい」ことの裏返しとして、「認証だけはきちんと確立する」という姿勢が見える。

MCPとの棲み分けという整理

A2Aが登場すると必ず出てくる疑問がある。「MCPと何が違うのか」という問いだ。

整理するなら、MCPはエージェントとツール（外部リソースや機能）を縦に繋ぐ。A2Aはエージェントとエージェントを横に繋ぐ。2025年12月に発足したAAIFのもとで、両者は補完的な標準として並立している。

実際の構成では、あるエージェントがMCPで複数のツールを操作しながら、A2Aで別のエージェントにサブタスクを委譲するという組み合わせが想定される。この組み合わせが上手く機能するかどうかは、まだ実運用事例が少ないため判断しきれないが、設計上の一貫性はある。

Managed Agentsとの比較でも同じような棲み分けが見えてくる。Managed Agentsはプラットフォーム内部の垂直統合として耐障害性とレイテンシを解いた。A2Aは組織をまたいだ水平連携として相互運用性と発見可能性を解こうとしている。解こうとしている問題のスコープが違う、という整理が妥当だと思う。

なぜ主要プレイヤーが揃ったか

2026年4月時点でA2AのGitHubには23,200を超えるスターがついていて、Python・Go・JavaScript・Java・.NETのSDKが整備されている。Atlassian、Box、Cohere、Salesforce、SAP、ServiceNowといった企業がパートナーに名を連ねている。

Googleが発表した翌年に、競合であるAnthropicとOpenAIが創設に参加したAAIFという組織に移管されたことは、A2Aが単なるGoogle製品ではなく業界標準として扱われていることを示している。Linux Foundationへの移管（2025年6月）も同じ文脈だ。

なぜ各社が乗るのかというと、エージェントが単一ベンダーのエコシステム内に留まる限り、実際に価値を生み出せる作業の範囲が狭すぎるからだと思う。顧客データはSalesforceに、プロジェクト管理はAtlassianに、財務はSAPにある。これらを横断するエージェントを作ろうとすれば、ベンダー固有の連携をそれぞれ実装するか、共通の通信プロトコルを使うかという選択になる。

まだ見えていないこと

A2AとManaged Agentsが同じ設計哲学に行き着いたとしても、残る問いはいくつかある。

Opaque Agentsの原則は「内部を知らなくていい」を保証するが、「内部が正しく動いているか」を確認する手段はどこにあるのか。A2Aの仕様では、エラーレスポンスやタスクの失敗状態は定義されているが、エージェントのデバッグや挙動の検証は依然として各実装者に委ねられている。

もうひとつは信頼の問題だ。Agent Cardで能力を宣言したエージェントが実際に宣言通りに動くことをどう保証するか、という点はプロトコル仕様の外にある。OAuth認証はアイデンティティを証明するが、行動を保証しない。

エージェントが増えれば増えるほど、この問いは重くなる。A2A v1.0.0に書かれていない部分が、次のバージョンでどう埋められるかを見ていきたい。