A2A(Agent2Agent)プロトコル

1. 概要

定義: A2A(Agent2Agent)とは、異なるベンダー・フレームワークで実装された自律AIエージェント同士が、相手の内部実装を公開することなく互いを発見し、作業を委任・協業できるよう標準化したオープンなアプリケーション層プロトコルであり、エージェントメタデータ(Agent Card)に基づく発見と、Task・Message・Artifactという共通オブジェクトモデルの上で動作する「エージェントのための相互運用標準」である。

生成AIが単純な質問応答を超え、複数の専門エージェントが協力して複合的な業務を遂行するマルチエージェント(Multi-Agent)体制へ進化するにつれ、最大の難題はモデルの推論能力ではなく異質なエージェントをいかに安全に接続するかへと移った。企業の現実では、CRM分析エージェントはA社のフレームワーク(LangGraph)で、日程調整エージェントはB社のソリューションで、社内決裁エージェントは自社開発で構築される、という具合にベンダー・ランタイム・言語がまちまちである。これらを協業させるにはエージェントの組ごとに専用アダプタを作る必要があり、これは過去のシステム統合で経験したN×Nのポイントツーポイント統合地獄をエージェントの世界で再現してしまった。

A2Aはこの問題をエージェント間通信の共通規約を立てることで解決する。エージェントが自らを記述する標準の名刺(Agent Card)を公開すると、他のエージェントがこれを読んで「何ができるか」を把握し、標準メッセージで作業を委任する。中核の哲学は不透明性(Opacity)であり、作業を委任された遠隔エージェントは自らの内部推論・プロンプト・使用ツールを公開せず、作業状態と成果物のみを交換する。これにより知的財産を保護しつつ協業が可能になり、エージェントが互いを交換可能な「サービス」のように消費するエージェント間ウェブ(Web of Agents)の基盤となる。

A2Aは2025年4月にGoogleが50社ほどのパートナーとともに公開し、2025年6月にLinux Foundationへ寄贈されて特定ベンダーに依存しない中立ガバナンスへ移管された。登場の背景は明確である。かつてウェブサービスがSOAP・RESTで、マイクロサービスがgRPCで標準化されたのと同様に、エージェントのエコシステムも相互運用標準なしにはサイロへ断片化するという危機意識である。A2Aの特徴は、第一に既存ウェブ標準の再利用(HTTP・JSON-RPC 2.0・SSE・OpenAPI認証スキーム)で導入障壁を下げること、第二にエンタープライズ級のセキュリティ・認証を第一級の要素として設計すること、第三に長時間実行・非同期作業(数日かかる作業も追跡可能)をネイティブに支援すること、第四にテキスト・画像・音声・構造化データを横断するモダリティ中立性を備えることである。

2. A2Aの全体構造と中核概念

A2Aは、作業を要求するクライアントエージェント(Client Agent)と、その要求を遂行する遠隔エージェント(Remote Agent, A2A Server)との相互作用で動作する。一つのエージェントは状況に応じてクライアントにもサーバーにもなる。全体の流れは「① 発見 → ② 交渉 → ③ 作業遂行・追跡 → ④ 結果受領」のライフサイクルを持つ。

graph TB
    subgraph User["ユーザー / オーケストレーター"]
        O["クライアントエージェント<br/>(Client Agent)"]
    end
    subgraph RemoteA["遠隔エージェントA (A2A Server)"]
        CardA["Agent Card<br/>(.well-known 公開)"]
        LogicA["内部推論・ツール<br/>(不透明・非公開)"]
    end
    subgraph RemoteB["遠隔エージェントB (A2A Server)"]
        CardB["Agent Card"]
        LogicB["内部ロジック"]
    end
    O -->|"1.発見: Agent Card 照会"| CardA
    O -->|"2.作業委任: Task 生成"| LogicA
    LogicA -->|"3.状態・結果: Task/Artifact"| O
    O -.->|"並列委任"| CardB
    O -.-> LogicB
    LogicA -->|"下位委任"| CardB

A. Agent Card(エージェント名刺) — Agent Cardは、A2Aサーバーが公開するJSON形式のメタデータ文書であり、通常は/.well-known/agent-card.jsonのパスに掲示される。ここにはエージェントの名称・バージョン・説明、サービスエンドポイントURL、保有スキル(skills)一覧、対応入出力モダリティ、要求する認証方式(OAuth 2.0・API Keyなど)、ストリーミング・プッシュの対応可否といった能力(capability)情報が含まれる。

名刺に宣言されるスキル(skill)は、エージェントが遂行可能な能力を自然言語の説明とともに構造化した項目であり、クライアント(またはオーケストレーターLLM)が「この要求をどのエージェントへ送るか」を意味に基づいてルーティングする根拠となる。すなわちAgent Cardは機械が読むAPI仕様であると同時に、LLMが推論によって適切な協業相手を選ぶのを助ける意味論的ディレクトリの役割も兼ねる。

Agent Cardは単なる紹介ではなく相互運用の出発点である点に本質がある。クライアントエージェントは、人が店の看板とメニューを見て入るか決めるように、名刺を読んで「このエージェントが自分の作業を処理できるか、どの認証が必要か」をランタイムに動的に判断する。これはサービスディレクトリ(UDDI)やOpenAPI仕様が担った役割をエージェントの世界へ移したものであり、事前にハードコードされた連携なしに疎結合(loose coupling)と動的発見を可能にする。たとえば旅行予約オーケストレーターが新規航空会社エージェントの名刺を登録するだけで、コード変更なしにそのエージェントを協業候補へ編入できる。

B. Task(作業) — Taskは、A2Aが追跡する作業の基本単位であり、固有IDを持ち、submitted → working → input-required → completed/failed/canceledのような明示的な状態機械(state machine)に従う。一つのTaskは複数回のメッセージ交換にわたって寿命を保つため、数秒で終わる照会から数日かかる審査・承認まで同一のモデルで扱える。

Taskを状態を持つ(stateful)第一級オブジェクトへ昇格させたことがA2A設計の核心的決定である。従来のREST呼び出しは要求-応答で終わるが、エージェント協業は本質的に長時間実行・非同期だからである。「競合の財務諸表を分析して報告書を作成せよ」という委任は数時間かかりうるし、途中で追加情報(input-required)を要求したり進捗を報告したりする必要がある。Taskの状態機械はこうした中断・再開・追跡を標準化し、クライアントがポーリングの代わりにSSE(Server-Sent Events)ストリーミングやプッシュ通知(Push Notification)で状態変化を受信するようにする。

C. MessageとPart(メッセージとパート) — Messageはクライアントとエージェントがやり取りする個々の発話(turn)であり、その内容はPart単位で収められる。PartはTextPart(テキスト)、FilePart(ファイル・バイナリ)、DataPart(JSONなど構造化データ)に区分され、一つのメッセージが複数のモダリティを混在させて伝達できる。

さらにMessageには役割(role)の区分があり、ユーザー発話とエージェント応答を区別し、複数のPartを一つのメッセージに束ねて「説明テキスト + 添付ファイル + 構造化パラメータ」を一度に伝達できる。これは人がメールに本文と添付を一緒に送るのに似ている。

Part抽象化が重要な理由はモダリティ交渉を可能にするからである。あるエージェントはテキストのみ、あるエージェントは画像・音声まで処理するため、送信側は受信エージェントのAgent Cardに宣言された対応モダリティに合わせてPartを構成する。これはコンテンツ形式をハードコードせず能力に基づいて交渉する設計であり、マルチモーダルエージェント間協業の柔軟性を確保する。

D. Artifact(成果物) — Artifactは、Taskが生産した最終成果物(報告書ファイル、生成された画像、構造化データなど)であり、会話用メッセージと分離して管理される。すなわち「進行過程の会話」(Message)と「確定した結果」(Artifact)を区別することで、クライアントは途中の雑談と無関係に引き渡し可能な成果物のみを明確に回収する。

この分離は冪等性・再利用の面で実務的含意が大きい。同一TaskのArtifactは識別子で参照・キャッシュ・バージョン管理でき、協業結果を監査(audit)したり後続エージェントの入力として再投入したりしやすい。たとえば「市場調査エージェント」が生産した分析報告書Artifactを「スライド生成エージェント」の入力へそのまま渡せば、途中の会話ログを再度パースする必要なく確定成果物のみが伝達され、エージェントパイプラインの結合度が下がる。これはデータエンジニアリングの「不変データセット(immutable dataset)」パターンをエージェント協業へ適用したのと同じである。

A2Aの中核オブジェクトを表に整理すると次のとおりである。ただし表は要約にすぎず、各オブジェクトがなぜ分離されたかは上記の段落の説明が本質である。

概念	役割	特徴	たとえ
Agent Card	エージェント能力・エンドポイント・認証の公開	動的発見、`.well-known`掲示	名刺・メニュー
Task	作業追跡単位(状態機械)	長時間・非同期、中断・再開	作業指示書
Message/Part	個々の発話とマルチモーダル内容	テキスト・ファイル・データの混在	会話の一ターン
Artifact	最終成果物	メッセージと分離、再利用	完成品・納品物

3. 通信手順と伝送層

A2Aの典型的な協業は以下の順序に従う。とりわけ発見と委任がランタイムに動的に起こる点が、事前連携方式との決定的な違いである。

sequenceDiagram
    participant C as クライアントエージェント
    participant S as 遠隔エージェント(A2A Server)
    C->>S: 1. GET /.well-known/agent-card.json (発見)
    S-->>C: Agent Card (スキル・認証・エンドポイント)
    C->>S: 2. 認証 (OAuth2/API Key)
    C->>S: 3. message/send (Task生成・作業委任)
    S-->>C: Task(status=working, id)
    loop ストリーミング進行
        S-->>C: 4. SSE: status-update (進捗/部分結果)
    end
    S-->>C: 5. input-required (追加情報要求)
    C->>S: 6. message/send (追加入力)
    S-->>C: 7. Task(status=completed) + Artifact

A. 発見(Discovery) — クライアントは既知のURLまたはレジストリからAgent Cardを照会し、相手の能力と認証要件を把握する。能力に適合しなければ別のエージェントを探す。発見がランタイムに起こる点は拡張性の面で決定的であり、新規エージェントを追加する際、既存エージェントのコードを修正せず名刺を登録するだけでよいため、O(N²)の連携負担がO(N)へ減る。大規模組織では社内エージェントカタログ(レジストリ)を設けて名刺を中央管理し、アクセスポリシーを適用するのが一般的なパターンである。

B. 認証・認可 — A2Aは独自の認証を新たに作らず、OpenAPIが用いる標準認証スキーム(OAuth 2.0、OpenID Connect、API Key、mTLSなど)を再利用する。企業の既存IAM・ゲートウェイ基盤に自然に載る点がエンタープライズ採用の核心的誘因である。車輪の再発明をしないこの設計のおかげで、セキュリティチームは既存の検証済みトークン発行・検証体系をそのまま再利用しつつ、エージェント協業のみに範囲を狭めたscoped tokenを発行できる。

C. 作業委任と追跡 — クライアントはmessage/send(またはストリーミング用message/stream)でTaskを生成する。短い作業は同期応答で、長い作業はSSEストリーミングで進行状況を、クライアントがオフラインでありうる超長時間作業はプッシュ通知(webhook)で完了を通知される。

伝送層においてA2A v1.0規格はデータモデルをProtocol Buffersで規範的に定義し、三つのバインディング(JSON-RPC 2.0、gRPC、HTTP+JSON/REST)を提供する。これは性能が重要な内部網はgRPCで、汎用の相互運用はJSON-RPC/RESTで選ぶようにする伝送の柔軟性設計である。Protocol Buffersを単一の真実の源(single source of truth)とすれば、異なる言語で実装されたエージェントが同一スキーマから生成されたコードを用いるため、フィールド不整合による統合エラーが構造的に減る。

実際の適用事例を見ると、GoogleはA2A発表当時、Salesforce・SAP・ServiceNow・PayPalなど50社ほどの企業とともに公開し、エンタープライズ業務エージェント間協業のシナリオ(例: 採用過程で応募者選別エージェントが日程調整・背景照会エージェントへ作業を委任)を提示した。このようにA2Aは特定モデルではなく企業業務自動化の結合組織(connective tissue)を志向する。

4. A2AとMCPの関係 — 競合ではなく補完

A2Aを理解する際に最もよくある誤解は、MCP(Model Context Protocol)との競合関係という捉え方である。実際には両者は異なる層を標準化する補完財である。MCPが「一つのエージェントが自らのツール・データにどう接続するか」(垂直的・エージェント対ツール)を標準化するなら、A2Aは「異なるエージェント同士がどう協業するか」(水平的・エージェント対エージェント)を標準化する。業界の略式表現どおり「ツールにはMCP、エージェントにはA2A」である。

graph TB
    subgraph AgentX["エージェントX"]
        LX["推論コア"]
        LX -->|"MCP"| T1["ツール/DB/API"]
    end
    subgraph AgentY["エージェントY"]
        LY["推論コア"]
        LY -->|"MCP"| T2["ツール/ファイル"]
    end
    LX <-->|"A2A (協業・委任)"| LY

両者の透明性モデルも対照的である。MCPのツール呼び出しは呼び出し側が引数・結果を透明に見るのに対し、A2Aは遠隔エージェントの内部を不透明に隠す。これは協業相手の知的財産とセキュリティ境界を守るための意図的な設計である。実際のプロダクションアーキテクチャは両標準を併用する。たとえばある組織の「出張精算エージェント」はMCPで自らの領収書OCRツール・会計DBへ接続し、同時にA2Aで外部の「航空券照会エージェント」・「為替エージェント」へ協業を委任する。以下の比較は差異が生じる根本理由を中心に整理したものである。

区分	A2A	MCP
標準化対象	エージェント↔エージェント協業(水平)	エージェント↔ツール・データ接続(垂直)
中核オブジェクト	Agent Card・Task・Artifact	Tool・Resource・Prompt
透明性	不透明(内部非公開)	透明(引数・結果公開)
相互作用	動的発見・長時間作業・委任	セッション内ツール呼び出し
主導・ガバナンス	Google→Linux Foundation	Anthropic→開放

5. 深化 — 標準化動向とセキュリティ課題

A2Aは公開から1年でエコシステムを急速に広げた。2025年6月のLinux Foundation寄贈で中立ガバナンスを確保し、2025年8月にはIBMのACP(Agent Communication Protocol)がA2Aへ統合され、競合標準が収束した。2025年12月、Linux Foundationはエージェント標準を集めるAAIF(Agentic AI Foundation)を発足させ、A2Aがそのホスティングプロジェクトとして合流した。v0.3.0(2025年半ば)を経て、v1.0安定規格が2026年前後に発表され、Protocol Buffersベースのデータモデルと3種のバインディングを確定した。ただし1.0公表の時期は資料ごとに差があるため、正確なバージョン・日付は公式規格(a2a-protocol.org)で確認する必要がある。

セキュリティの面でA2Aは新たな攻撃面を開く点が活発に研究されている。第一に、Agent Card信頼問題であり、名刺の能力・身元が偽変造されると悪意あるエージェントが正当な協業者を詐称しうるため、署名・検証とレジストリ信頼体系が求められる。第二に、委任連鎖(delegation chain)で権限が過度に伝播する混乱した代理人(confused deputy)のリスクであり、各委任段階に最小権限・範囲トークン(scoped token)を適用しなければならない。第三に、不透明性そのものが諸刃の剣であり、悪意あるエージェントの挙動を外部から監視しにくい。学界のA2Aセキュリティ分析(A2ABreakなど)は、認証・認可の回避、作業ハイジャック、プロンプトインジェクションの伝播などを体系的脅威として指摘する。したがって実務適用時にはゼロトラスト原則、エージェント別の身元(SPIFFE型のワークロードアイデンティティ)、全区間の監査ログを併行させなければならない。

6. 考慮事項および示唆点

技術士の観点からA2Aの導入は単なる技術選択ではなくエージェントアーキテクチャ・ガバナンス・セキュリティを横断する戦略課題であり、次を併せて考慮しなければならない。

適用戦略(漸進的導入): 全社マルチエージェントを一度に築くより、内部的にはまずMCPでツール層を標準化したうえで、組織・ベンダー境界を越える協業のみにA2Aを選択的に適用する二段階アプローチが現実的である。Agent Cardレジストリと名刺署名体系をガバナンスの先決課題とする。
トレードオフ(不透明性 vs 可観測性): A2Aの不透明性は知的財産保護と疎結合をもたらすが、デバッグ・監査・責任追跡を難しくする。作業ID基盤の分散トレーシング(OpenTelemetry連携)とArtifactのバージョン管理で可観測性を補完しなければならない。
セキュリティ・規制(責任の所在): 自律エージェントが外部エージェントへ委任して生じた結果の法的・契約的な責任帰属が曖昧である。委任範囲をトークン・ポリシーで制限し、金融・医療など規制産業では人間の承認(human-in-the-loop)チェックポイントをTaskの状態機械へ明示的に設計する。
標準成熟度リスク: A2Aはなお急速に進化中(バージョン変動・ガバナンス移管)であるため、特定バージョンへ強結合せず、バージョン交渉・下位互換を前提にアダプタ層を設けて移行コストを吸収する。
連携技術・展望: A2Aの価値はMCP(ツール)、LangGraph・AutoGenなどのオーケストレーションフレームワーク、ゼロトラスト・IAMと結合したときに最大化される。長期的にはエージェントがサービスのように取引・発見されるエージェント経済(Agent Economy)・エージェント間ウェブの下部プロトコルとして定着する見通しであり、企業は今からエージェント身元・名刺・委任ポリシーのガバナンス体系を先制的に準備しなければならない。

参考資料

A2A Protocol 公式サイト — https://a2a-protocol.org/
Wikipedia, "Agent2Agent" — https://en.wikipedia.org/wiki/Agent2Agent
Tyk, "A2A protocol: Architecture and technical specification" — https://tyk.io/learning-center/a2a-protocol-architecture-and-technical-specification/
Google Open Source Blog, "A year of open collaboration: Celebrating the anniversary of A2A" — https://opensource.googleblog.com/2026/04/a-year-of-open-collaboration-celebrating-the-anniversary-of-a2a.html
Palma.ai, "Agent2Agent (A2A) and MCP: What the Handover Means" — https://palma.ai/blog/A2A-linux-foundation-donation-comparison
A2ABreak: Systematic Security Analysis of the A2A Protocol (arXiv:2609.10871) — https://arxiv.org/pdf/2609.10871

一言まとめ: A2Aは、異質なAIエージェントがAgent Cardベースの動的発見とTask·Message·Artifactの共通モデルで内部を隠したまま作業を委任・協業できるようにするオープンな相互運用プロトコルであり、「ツールにはMCP、エージェントにはA2A」のようにMCPと補完関係をなし、成功的な導入は名刺信頼・委任権限・可観測性などセキュリティ・ガバナンスの設計にかかっている。