A2A（Agent2Agent）プロトコル彻底解説：AIエージェント同士を繋ぐ新たな「HTTP」

LangGraphで作成したエージェントとCrewAIで作成したエージェントが協調動作する時、あるいはカスタマーサポートエージェントが請求に関する問題をサードパーティの財務エージェントに委託する時、それらの間で「どのように対話し、どのようにタスクを分担し、どのようにリアルタイムに進捗を同期するか」を決定する共通の規格はあるでしょうか？

Googleと50以上の企業・団体が2025年4月に発表した、この問いに対する標準化の回答が**「A2A (Agent2Agent) プロトコル」**です。

公開からわずか2か月でLinux Foundationに寄贈され、1周年を迎えた2026年4月にはGitHubスター数22,000を超え、150以上の企業やプロダクション組織で導入が進んでいます。本記事では、A2Aプロトコルの基本設計思想、3つの主要ロール、5つのコアデータ構造、そして企業向けシステムでの実装パターンについて体系的に解説します。

1. なぜA2Aが必要なのか：マルチエージェント協調における「バベルの塔」のジレンマ

2024年から2025年にかけて、LLM（大規模言語モデル）を駆使したAIエージェントは、単一の自律動作から「複数のエージェントによるクラスター型の協調動作」へと進化しました。しかし、開発者はすぐに**「異なるフレームワークやプラットフォームで構築されたエージェント同士が会話するための共通プロトコルが存在しない」**という壁に突き当たりました。

例えば、LangGraphで作成した「サポート窓口エージェント」が、CrewAIで動く「財務分析エージェント」を呼び出し、さらにサードパーティSaaSの提供する「CRMエージェント」と連携する状況を想定してみましょう。

A2Aが登場する前は、財務エージェントを無理やり「ツール」としてカプセル化し、サポートエージェントに提供するしかありませんでした。しかし、これではエージェントが単なる**「ステートレスな関数呼び出し」**に格下げされ、エージェント本来の強みである自律的な推論、マルチターンの交渉、長期的なタスク管理能力がすべて失われてしまいます。

この課題は「バベルの塔のジレンマ」と呼ばれています。

課題	具体的な現象
発見メカニズムの欠如	エージェントAは、エージェントBが何を実行できるか、どう呼び出せばよいかを知る方法がない。
プロトコルの断片化	LangChainベースのエージェントとAutoGenベースのエージェントがネイティブに通信できない。
セキュリティ境界の曖昧さ	組織をまたぐエージェント呼び出しにおいて、統一されたアイデンティティ認証や認可モデルがない。
状態管理の混乱	長時間実行されるタスク（Long-running tasks）の途中の状態を、標準化されたフォーマットで受け渡せない。
人機協調（Human-in-the-Loop）の欠如	エージェントが処理を一時停止し、人間の承認（確認）を待つべきタイミングを標準的に合意できない。

💡 核心的な洞察
これは2000年代初頭のWebサービスが混乱していた状況（SOAPやXML-RPCの群雄割拠）と非常によく似ています。後にHTTP + RESTが事実上の標準となり今日のインターネットが成立したように、**A2Aは「AIエージェント時代のHTTP」**を目指して設計されました。

2. 技術スタックにおける位置づけ：MCP（Model Context Protocol）との補完関係

「A2AとMCP（Model Context Protocol）はどう違うのか？どちらを選ぶべきか？」という疑問を持つ方は多いでしょう。
結論から言えば、**「両方とも採用すべきであり、これらは異なるレイヤーの課題を解决するもの」**です。

比較軸	A2A (Agent2Agent)	MCP (Model Context Protocol)
接続対象	エージェント ↔ エージェント	エージェント ↔ ツール / リソース（DB、ファイル等）
インタラクション	多ターン、有状態（Stateful）、協調・交渉型	単発呼び出し、無状態（Stateless）、構造化データ
典型的なシナリオ	カスタマーサポートエージェントが、決済エージェントに返金処理を委託する	エージェントがデータベースの注文履歴を検索する
設計思想	エージェントは自律的な「協調パートナー」である	ツールは呼び出されるだけの「能力の最小単位」である

要約すると、**MCPは「エージェントがツールやデータをどのように使うか」**を解決し、**A2Aは「エージェントが他のエージェントとどのように協調するか」**を解決します。一つのエージェントが、MCPを使ってローカルツールを叩きつつ、A2Aを使ってリモートのエージェントとチームを組むのが標準的なシステム構成です。

⚠️ 注意：アンチパターン
MCPの導入をスキップしてA2Aだけを導入しようとすると、「お互いに会話はできるが、背後にあるデータやツールに一切アクセスできないエージェントの群れ」が出来上がってしまいます。

3. コアロールモデル：3つの役割と1つの原則

A2Aアーキテクチャは非常にシンプルで、次の3つの役割で構成されます。

User（エンドユーザー：人間または自動化されたサービス）
│
▼ リクエスト発信
A2A Client（クライアントエージェント：ユーザーの代わりに通信を管理）
│
▼ A2Aプロトコル通信（HTTP / JSON-RPC 2.0）
A2A Server（リモートエージェント：A2A仕様のエンドポイントを実装）

ここで最も重要な原則が**「カプセル化（不透明性：Opaque）」です。
A2A Clientは、リモートのA2A Server（エージェント）の内部実装、プロンプトの構成、記憶状態、またはどのようなツールセットを持っているかを関知しませんし、知る必要もありません。Clientが知るべきなのは、「そのエージェントにどの仕事を任せられるか（能力）」と「どうやって呼び出すか」**だけです。

この設計の素晴らしい点は、エージェントプロバイダーの知的財産（エージェントの内部ロジック）を完全に保護しながら、C/S（クライアント/サーバー）型の安全なセキュリティ境界を確立できる点にあります。これは、REST APIで外部決済サービスを叩く際に、決済システム内部のデータベース設計を知る必要がないのと同じです。

4. 5つのコアコンポーネント：データ構造の把握

A2Aのすべての通信は、以下の5つのコアデータ構造を中心に構成されています。

4.1 Agent Card —— エージェントの「デジタル名刺」

A2Aに対応した各エージェントは、https://{domain}/.well-known/agent.json というパスにJSON形式の仕様書を公開する必要があります。クライアントはこのファイルを読み込み、「このエージェントに依頼すべきか」を判断します。

{
  "name": "財務分析エージェント",
  "description": "専門的な財務データ分析、決算書分析、リスク評価をサポート",
  "url": "https://finance-agent.example.com",
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": true
  },
  "skills": [
    {
      "id": "financial-report-analysis",
      "name": "財務諸表分析",
      "description": "アニュアルレポートや四半期決算書を分析し、主要指標を抽出",
      "tags": ["finance", "analysis"],
      "examples": [
        "2025年第4四半期決算書から収益性のトレンドを分析してください"
      ],
      "inputModes": ["text", "file"],
      "outputModes": ["text", "data"]
    }
  ],
  "authentication": {
    "schemes": ["Bearer"]
  }
}

⚠️ 設計のコツ
Agent Cardに記載するスキル（skills）は、**必要最小限に留める（最小スキル宣言の原則）**ことをお勧めします。何でもできるかのように書いてしまうと、クライアントエージェント側でのルーティング判断で誤コールが頻発する原因になります。

4.2 Task —— 状態を持つワークユニット

TaskはA2Aの核心コンセプトです。追跡が必要な一つの「仕事」を指し、ライフサイクル全体で厳密な状態遷移を持ちます。

状態の種類: PENDING -> RUNNING -> COMPLETED / FAILED / CANCELED
Taskの不変性（Immutability）: Taskがいったん終端状態（Completedなど）に入ると、再開することはできません。結果を変更したい場合は、同じセッション下で元のTask IDを参照した新しいTaskを作成します。

4.3 Message —— 通信の最小単位

エージェント間で行われる一連の対話は、すべてMessageとして管理されます。各Messageは、発信ロール（user または agent）、一意なID、および内容を表すPartsのリストで構成されます。

4.4 Part —— マルチモーダル対応のコンテンツコンテナ

A2Aが様々なメディア（テキスト、画像、コード）を処理できるのは、このPartというデータモデルのおかげです。

タイプ	説明	主なユースケース
`text`	プレーンテキスト	自然言語による対話
`file`	バイナリファイル（Base64 / URL）	PDFの決算資料、解析用画像など
`data`	構造化されたJSONオブジェクト	DBからの抽出データ、構造化レポートなど
`url`	外部リソースのURI	大容量ファイルや外部リンクの参照

{
  "role": "user",
  "parts": [
    {
      "type": "text",
      "text": "この決算資料の収益性を分析してください。"
    },
    {
      "type": "file",
      "mimeType": "application/pdf",
      "url": "https://example.com/files/Q4_2025.pdf",
      "name": "Q4_2025.pdf"
    }
  ]
}

4.5 Artifact —— タスクの「最終納品物」

MessageとArtifactの決定的な違いは、**Messageは「議論のプロセス」であり、Artifactは「正式な成果物」**である点です。エージェントがタスクを完了した際に生成される最終報告書、ソースコード、データシートなどは、すべてArtifactとして出力されます。

5. 3つのインタラクションパターン

タスクの特性に応じて、A2Aは3つの通信パターンを提供しています。

5.1 同期リクエスト / レスポンス（ポーリング）

最も単純な通信です。Clientが tasks/send を呼び出し、Serverが即座に応答します。時間のかかる処理の場合、Clientは tasks/getTask を定期的にポーリングしてステータスを確認します。

推奨: 処理時間が5秒未満の、即時完了するシンプルなタスク。

5.2 SSEによるストリーミング伝送（推奨）

Clientが tasks/sendSubscribe を叩くと、Serverは Server-Sent Events (SSE) を通じてリアルタイムに進捗をプッシュします。

5.3 Push（プッシュ通知）

数分から数時間に及ぶ超長期のタスク向けです。Clientはリクエスト時にWebhook URLを指定し、Serverはタスクのステータスが変わった際にそのURLへプッシュ送信します。

⚠️ セキュリティ上の注意
Push通知を設計する際、Server側は**SSRF（Server-Side Request Forgery）**を防ぐためにWebhook URL of Verificationを行う必要があります。一方、Client側はリクエストが本物のエージェントから来たかを検証するために、**JWT署名 + タイムスタンプ + Nonce（リプレイ攻撃防止）**を組み合わせた検証を必須とすべきです。

6. エージェント発見（ディスカバリ）の3つのアプローチ

システム要件に応じて、適切な発見方法を選択できます。

方式	パス・アプローチ	適用シナリオ
Well-Known URI	`https://domain/.well-known/agent.json`	パブリックなエージェント、ドメイン内での自律発見
レジストリ（カタログ）	中央集権的なCatalogサービス	企業内でのエージェントガバナンスと統制管理
ダイレクト構成	ハードコード / 環境変数	開発テスト段階、または特定の非公開エージェント

💡 本番運用の推奨構成
パブリックなエージェントには「Well-Known URIによる自律発見」を採用し、社内のプライベートエージェントには「中央カタログレジストリ」による一元管理を行うのが、現在主流のベストプラクティスです。

7. A2Aの重要なアーキテクチャ上の意思決定

設計において議論になりやすい、A2Aの特徴的な技術決定について紹介します。

意思決定①：Task IDをClient側で生成する
- 理由: ネットワークエラーによるリトライ時に、Server側で確実に冪等性（Idempotency）を担保するためです。同一のTask IDで再送信された場合、Serverはタスクを重複実行しません。その代わり、ClientはUUID v4などのグローバルでユニークなIDを発行する責務を負います。
意思決定②：ArtifactsとMessagesの分離
- 理由: 対話の履歴（Messages）と、生成された成果物（Artifacts）はライフサイクルが異なります。Messagesは人間向けに順次表示されるのに対し、Artifactsはシステム間での再利用やダウンロードの対象となります。分離することにより、Artifactだけの増量ストリーミング（lastChunk: false）などが容易になります。
意思決定③：RESTではなくJSON-RPC 2.0の採用
- 理由: RESTのHTTPメソッド（GET/POST/DELETE）のセマンティクスは、複雑なエージェントの挙動（タスクのキャンセルや一時停止など）を表現するには曖昧になりがちです。JSON-RPCであれば、メソッド名（cancelTask など）で明確に指示でき、id フィールドを用いた非同期のメッセージング処理が容易になります。

8. Python SDKを用いた実装コード例

A2Aは公式に Python/JavaScript/Java/Go/.NET のSDKを提供しています。以下はPython SDKを使った最もシンプルな構築例です。

8.1 自作エージェントをA2A Serverとして公開する

from google.adk.a2a import to_a2a
from your_agent_module import root_agent

# 自作のエージェントをA2A対応サービスへとラップ
a2a_app = to_a2a(root_agent, port=8001)

# a2a_appは自動的に `/.well-known/agent.json` を公開します

8.2 リモートのA2AエージェントをClientとして呼び出す

from google.adk.a2a import RemoteA2aAgent

# Agent CardのURLを指定して、リモートエージェントに接続
billing_agent = RemoteA2aAgent(
    name="billing_agent",
    description="請求・会計処理専門エージェント",
    agent_card="https://billing.example.com/.well-known/agent.json",
)

# あたかもローカルのエージェントであるかのように非同期で呼び出し
result = root_agent.invoke_async(
    "注文番号 #12345 の返金ステータスを確認して", billing_agent
)

9. エンタープライズ向けガバナンス機能

A2Aは最初からエンタープライズの商用環境を想定し、セキュリティや監視機能を仕様に組み込んでいます。

セキュアな通信: 本番環境ではHTTPS接続を強制（TLS 1.2以上推奨）。
認証スキーム: API Key、OAuth 2.0、OpenID Connect、mTLSに対応。
細粒度認可（Fine-grained AuthZ）: エージェントが持つ「スキル単位」でのアクセス制御が可能。
可観測性（Observability）: OpenTelemetryとシームレスに統合。すべてのタスクメッセージに taskId と contextId が付与され、システムを跨いだトレース追跡が可能です。

10. A2Aエコシステムの現在（2026年時点）

2025年4月にGoogleがGoogle Cloud Nextで最初に提案してから約1年、A2Aは爆発的な成長を遂げました。

2025年6月: Linux Foundationへの寄贈。AWS、Microsoft、Cisco、Salesforce、SAPなどが創設メンバーとして参画。
2026年3月: v1.0の安定版リリース。v1.2で「署名付きAgent Card」仕様が導入され、不正なエージェントのなりすましを防止。
現在: Microsoft Copilot Studio / Azure AI Foundry、AWS Bedrock AgentCoreなどの主要クラウドサービスでネイティブ対応。

さらにGoogleはA2Aの上位規格として、MastercardやPayPal、American Express等と提携した**「AP2 (Agent Payments Protocol)」**を展開しており、認可された予算範囲内でエージェント同士が自律的に決済を行うフェーズに入っています。

まとめ

A2Aプロトコルは、単なる新しい技術標準ではなく、「エージェント中心の新しいネットワーク社会」を構築するためのインフラです。

エージェントは「自律的なパートナー」であり、ツールではない。だからこそ有状態のTaskやMessage、Partsが設計されている。
疎結合な（不透明な）協調が、密結合な連携よりも優れている。内部実装を隠蔽し、Agent Cardを介して能力ベースで対話する。
エンタープライズ対応が標準で盛り込まれている。セキュリティやOpenTelemetryによる追跡が最初から実装されている。

これからマルチエージェントシステムの開発に取り組む場合は、まずMCPを使ってエージェントに社内データやツールを操作させ、次にA2Aを導入して他システムや他組織のエージェントとチームを組ませるアプローチを推奨します。社内にある独自API呼び出しや人手で中継しているエージェント間プロセスがあれば、それこそがA2A導入的第1候補です。

「HTTPが今日のインターネットを作ったように、A2Aがエージェントのインターネットを作るのか」——その未来に注目です。