0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@lumichy

A2Aプロトコル徹底解説：エージェント間通信の標準規格がもたらす「AIエージェントのインターネット」

0
Posted at

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) を通じてリアルタイムに進捗をプッシュします。

SSE Streaming Sequence Diagram

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

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

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?