Google: Agent2Agent Protocol (A2A)：AIエージェント間の相互運用性を実現する新たなオープンプロトコル

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/214013/df908b10-349d-4f98-8078-eed6a701a4c5.png)
[Announcing the Agent2Agent Protocol (A2A) より](URL "https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/")

## 目次
- [はじめに](#はじめに)
- [Part 1: A2Aプロトコルの背景と概要](#part-1-a2aプロトコルの背景と概要)
  - [現在のAIエージェントの課題](#現在のaiエージェントの課題)
  - [A2Aプロトコルとは](#a2aプロトコルとは)
  - [A2Aの設計原則](#a2aの設計原則)
- [Part 2: A2Aの技術詳細](#part-2-a2aの技術詳細)
  - [A2Aの基本アーキテクチャ](#a2aの基本アーキテクチャ)
  - [主要コンポーネント](#主要コンポーネント)
  - [通信フロー](#通信フロー)
  - [プッシュ通知メカニズム](#プッシュ通知メカニズム)
- [Part 3: A2AとMCPの関係](#part-3-a2aとmcpの関係)
  - [MCPとは何か](#mcpとは何か)
  - [A2AとMCPの違いと補完関係](#a2aとmcpの違いと補完関係)
  - [実世界での例：自動車修理店の例](#実世界での例自動車修理店の例)
- [Part 4: 実世界での応用例](#part-4-実世界での応用例)
  - [候補者採用プロセス](#候補者採用プロセス)
  - [カスタマーサポート](#カスタマーサポート)
  - [財務レポート作成](#財務レポート作成)
- [Part 5: A2Aの実装方法](#part-5-a2aの実装方法)
  - [実装の基本ステップ](#実装の基本ステップ)
  - [サンプル実装（Python）](#サンプル実装python)
- [Part 6: 現状と今後の展望](#part-6-現状と今後の展望)
  - [現在の開発状況](#現在の開発状況)
  - [今後のロードマップ](#今後のロードマップ)
  - [業界への影響](#業界への影響)
- [まとめ](#まとめ)
- [学習確認クイズ](#学習確認クイズ)
- [参考リソース](#参考リソース)

## はじめに

AIエージェントは、日常的なタスクや複雑な問題を自律的に処理することで、人々の生産性を向上させる大きな可能性を秘めています。しかし、異なるベンダーやフレームワークで構築されたエージェント同士が効果的に連携できないという課題が存在していました。

Googleが最近発表した「Agent2Agent Protocol (A2A)」は、このエージェント間の相互運用性の問題に対処するための革新的なオープンプロトコルです。Atlassian、Box、Cohere、Intuit、Langchain、MongoDB、PayPal、Salesforce、SAP、ServiceNowなど50社以上のテクノロジーパートナーの支援と貢献を受けて開発されたA2Aは、AIエージェントが相互に通信し、情報を安全に交換し、様々な企業プラットフォームやアプリケーション上でアクションを調整できるようにします。

本記事では、A2Aプロトコルの概要、仕組み、実装方法、そして企業や開発者にとっての意義について詳しく解説します。🤖🔄🤖

## Part 1: A2Aプロトコルの背景と概要

### 現在のAIエージェントの課題

現在、企業は様々なビジネスプロセスを自動化・拡張するためにAIエージェントを導入しています。例えば、新しいラップトップの注文から、カスタマーサービス担当者のサポート、サプライチェーン計画の支援まで、幅広い用途でエージェントが活用されています。

しかし、これらのエージェントが最大限の効果を発揮するためには、異なるベンダーやフレームワークで構築されたエージェント同士が連携できることが不可欠です。現状では、エージェント間の標準化された通信プロトコルがないため：

1. **サイロ化された運用**：各エージェントが独自のエコシステム内でのみ機能
2. **重複する機能開発**：同じ機能を異なるエージェントシステムごとに再実装する必要性
3. **複雑な統合作業**：異なるエージェントを連携させるためのカスタム開発の負担
4. **一貫性のないユーザー体験**：エージェント間での異なる対話モデルやデータ形式

こうした課題を解決するため、GoogleはA2Aプロトコルを開発しました。これにより、異なるエージェントが標準化された方法で通信し、連携できるようになります。

### A2Aプロトコルとは

A2A（Agent2Agent）プロトコルは、異なるフレームワークやベンダーによって構築されたAIエージェント間の通信と協力を可能にするオープンスタンダードです。A2Aは、エージェントがメモリ、ツール、コンテキストを共有していなくても、自然な形式で協力できるようにします。

A2Aは特に以下のような機能を提供します：

- **機能発見**: エージェントが自分の機能を公開し、他のエージェントがそれを発見できる仕組み
- **タスク管理**: エージェント間でタスクの作成、実行、状態追跡を行うための標準化されたプロセス
- **協力的作業**: エージェントがコンテキスト、返信、成果物、ユーザー指示を交換するための方法
- **ユーザー体験の交渉**: エージェント間で適切なコンテンツ形式とUIの機能を交渉する機能

### A2Aの設計原則

A2Aプロトコルは、以下の5つの主要原則に基づいて設計されています：

1. **エージェントの能力を活かす** 🧠: A2Aは、エージェントがメモリー、ツール、コンテキストを共有していなくても、自然な形式で協力できるようにします。これにより、エージェントを単なる「ツール」に制限することなく、真のマルチエージェントシナリオを実現します。

2. **既存の標準を活用** 🏗️: このプロトコルは、HTTP、SSE、JSON-RPCなどの一般的な既存標準の上に構築されています。これにより、企業が日常的に使用している既存のITスタックとの統合が容易になります。

3. **デフォルトでセキュア** 🔒: A2Aは、エンタープライズグレードの認証と認可をサポートするように設計されており、OpenAPIの認証スキームと同等のセキュリティを提供します。

4. **長時間実行タスクのサポート** ⏱️: A2Aは柔軟に設計されており、迅速なタスクから数時間または数日かかる深い調査まで、様々なシナリオをサポートします。このプロセス全体を通じて、リアルタイムのフィードバック、通知、状態更新をユーザーに提供できます。

5. **モダリティに依存しない** 📊: エージェントの世界はテキストだけに限定されないため、A2Aはオーディオやビデオストリーミングを含む様々なモダリティをサポートするように設計されています。

これらの原則により、A2Aはエンタープライズ環境で実用的かつ柔軟なプロトコルとなっています。

### Part 1まとめ

A2Aプロトコルは、異なるAIエージェント間の相互運用性を実現するためのオープンな標準です。従来、異なるベンダーやフレームワークで構築されたエージェントは連携が困難でしたが、A2Aはこの課題を解決します。エージェントの能力を最大限に活かし、既存の標準を活用し、セキュリティを重視した設計により、エンタープライズ環境での実用性を高めています。

## Part 2: A2Aの技術詳細

### A2Aの基本アーキテクチャ

A2Aプロトコルは、「クライアント」エージェントと「リモート」エージェント間の通信を容易にします。クライアントエージェントはタスクを設定して伝達する役割を担い、リモートエージェントはそれらのタスクに対応し、正確な情報を提供またはアクションを実行する役割を担います。

A2Aでは以下の3つの主要なアクターが存在します：

1. **ユーザー**: タスクを達成するためにエージェントシステムを使用するエンドユーザー（人間またはサービス）
2. **クライアント**: ユーザーに代わってリモートエージェントにアクションを要求するエンティティ（サービス、エージェント、アプリケーション）
3. **リモートエージェント（サーバー）**: 「ブラックボックス」として機能するA2Aサーバー

プロトコルはHTTPをトランスポートとして使用し、クライアントとリモートエージェントの間でJSON-RPC 2.0をデータ交換形式として活用します。

### 主要コンポーネント

A2Aプロトコルの主要コンポーネントは以下の通りです：

#### 1. Agent Card（エージェントカード）

JSON形式で記述されたメタデータファイルで、エージェントの機能、スキル、エンドポイントURL、認証要件などを記述します。クライアントはこれを使用してエージェントを発見します。通常は `/.well-known/agent.json` パスで公開されます。

エージェントカードの例：

```json
{
  "name": "Google Maps Agent",
  "description": "Plan routes, remember places, and generate directions",
  "url": "https://maps-agent.google.com",
  "provider": {
    "organization": "Google",
    "url": "https://google.com"
  },
  "version": "1.0.0",
  "authentication": {
    "schemes": "OAuth2"
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/html"],
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "route-planner",
      "name": "Route planning",
      "description": "Helps plan routing between two locations",
      "tags": ["maps", "routing", "navigation"],
      "examples": [
        "plan my route from Sunnyvale to Mountain View",
        "what's the commute time from Sunnyvale to San Francisco at 9AM"
      ],
      "outputModes": ["application/html", "video/mp4"]
    }
  ]
}
```

#### 2. Task（タスク）

クライアントとリモートエージェント間の通信の中心単位です。タスクは一意のIDを持ち、様々な状態（submitted、working、input-required、completed、failed、canceled）を通過します。

```json
{
  "id": "de38c76d-d54c-436c-8b9f-4c2703648d64",
  "sessionId": "c295ea44-7543-4f78-b524-7a38915ad6e4",
  "status": {
    "state": "working",
    "message": {
      "role": "agent",
      "parts": [{
        "type":"text",
        "text":"処理中です、お待ちください"
      }]
    }
  },
  "artifacts": [],
  "metadata": {}
}
```

#### 3. Message（メッセージ）

クライアント（role: "user"）とエージェント（role: "agent"）間のコミュニケーションターンを表します。メッセージには複数のPartが含まれます。

```json
{
  "role": "user",
  "parts": [{
    "type": "text",
    "text": "東京から大阪への最短ルートを教えてください"
  }]
}
```

#### 4. Part（パート）

MessageまたはArtifact内の基本的なコンテンツ単位です。以下のタイプがあります：

- **TextPart**: テキストコンテンツ
- **FilePart**: ファイルコンテンツ（インラインバイトまたはURI付き）
- **DataPart**: 構造化JSONデータ

```json
{
  "type": "text",
  "text": "東京から大阪への最短ルートは新幹線で約2時間30分です。"
}
```

#### 5. Artifact（アーティファクト）

タスク実行中にエージェントによって生成される出力を表します（例：生成されたファイル、最終的な構造化データ）。

```json
{
  "name": "route-info",
  "parts": [{
    "type": "text",
    "text": "東京から大阪への最短ルートは新幹線で約2時間30分です。"
  }],
  "metadata": {
    "distance": "553km",
    "time": "2h30m"
  }
}
```

### 通信フロー

A2Aにおける基本的な通信フローは以下の通りです：

```plantuml
@startuml
actor "User" as User
participant "Client Agent" as Client
participant "Remote Agent" as Remote

User -> Client: リクエスト
Client -> Remote: tasks/send または tasks/sendSubscribe
Remote -> Remote: タスク処理
alt ストリーミングあり
    Remote --> Client: SSEイベント（状態更新）
    Remote --> Client: SSEイベント（アーティファクト）
else ストリーミングなし
    Remote --> Client: 最終的なTaskオブジェクト
end
alt 入力が必要な場合
    Remote --> Client: 状態: input-required
    Client -> User: 追加情報を要求
    User -> Client: 追加情報を提供
    Client -> Remote: tasks/send（追加情報）
    Remote -> Remote: 処理を継続
end
Remote --> Client: 状態: completed/failed/canceled
Client -> User: 結果を表示
@enduml
```

1. **発見（Discovery）**：クライアントがサーバーの既知のURLからAgent Cardを取得します。

2. **開始（Initiation）**：クライアントが初期ユーザーメッセージと一意のタスクIDを含む`tasks/send`または`tasks/sendSubscribe`リクエストを送信します。

3. **処理（Processing）**：
   - **ストリーミング**：サーバーはタスクの進行に合わせてSSEイベント（ステータス更新、アーティファクト）を送信します。
   - **非ストリーミング**：サーバーはタスクを同期的に処理し、レスポンスで最終的なTaskオブジェクトを返します。

4. **インタラクション（オプション）**：タスクがinput-required状態になった場合、クライアントは同じタスクIDを使用してtasks/sendまたはtasks/sendSubscribeで後続のメッセージを送信します。

5. **完了（Completion）**：タスクは最終的に終了状態（completed、failed、canceled）に達します。

### プッシュ通知メカニズム

長時間実行されるタスクでは、クライアントとリモートエージェントが接続を維持できない場合があります。A2Aでは、タスクの状態が変化したときにエージェントがクライアントに通知する方法として、プッシュ通知メカニズムをサポートしています。

```plantuml
@startuml
actor "User" as User
participant "Client Agent" as Client
participant "Remote Agent" as Remote
participant "Notification Service" as Notify

User -> Client: リクエスト
Client -> Remote: タスク + 通知URL設定
Remote -> Remote: タスク処理（長時間）
Client -x Remote: 接続切断
Remote -> Remote: タスク完了
Remote -> Notify: プッシュ通知
Notify -> Client: 通知転送
Client -> User: タスク完了通知
User -> Client: 結果確認要求
Client -> Remote: tasks/get
Remote --> Client: 完了したタスク情報
Client -> User: 結果を表示
@enduml
```

プッシュ通知の設定は以下のようなJSON形式で行います：

```json
{
  "url": "https://example.com/callback",
  "token": "unique-token-for-this-task",
  "authentication": {
    "schemes": ["bearer"]
  }
}
```

### Part 2まとめ

A2Aプロトコルは、Agent Card、Task、Message、Part、Artifactという主要コンポーネントを使用して、クライアントエージェントとリモートエージェント間の通信を構造化します。HTTP/JSON-RPCを基盤とし、同期・非同期の通信、マルチターン会話、ストリーミング、プッシュ通知など、様々なコミュニケーションパターンをサポートします。この柔軟な設計により、短時間のタスクから長時間の複雑なタスクまで、様々なシナリオに対応可能です。

## Part 3: A2AとMCPの関係

### MCPとは何か

Model Context Protocol (MCP)は、LLM（大規模言語モデル）をツール、API、リソースに接続するための標準プロトコルです。MCPは異なるモデルとフレームワーク間での「関数呼び出し」を標準化し、ツールサービスプロバイダーのエコシステムを作り出し、エージェントとツールやデータを接続する複雑さを大幅に低減します。

MCPの主な特徴：
- ツールやリソースとLLMを構造化された入出力で接続
- Google ADKはMCPツールをサポート
- 幅広いMCPサーバーをエージェントで利用可能

### A2AとMCPの違いと補完関係

A2AとMCPは異なる目的を持ちながらも、一緒に機能することでAIエージェントのエコシステムを強化します。

#### 違い

| 特性 | A2A | MCP |
|------|-----|-----|
| 主な目的 | エージェント間の通信と協力 | エージェントとツール/リソースの接続 |
| 通信の形式 | 自然な対話、非構造化 | 構造化された入出力、関数呼び出し |
| 焦点 | メモリ・リソース・ツールを共有せずにエージェント間の連携 | エージェントが外部ツールやAPIを利用するための標準 |
| 使用例 | エージェント間の協調タスク | エージェントによる特定機能の呼び出し |

簡単に言えば：
- **MCP**: エージェントとツール/リソースの接続
- **A2A**: エージェント同士の連携

```plantuml
@startuml
rectangle "アプリケーション" {
  component "エージェント" as Agent
}

cloud "外部システム" {
  component "ツール/API" as Tools
  component "他のエージェント" as OtherAgents
}

Agent -- Tools : MCP
Agent -- OtherAgents : A2A

note bottom of Tools
  構造化された入出力
  関数呼び出し
end note

note bottom of OtherAgents
  非構造化対話
  動的なタスク管理
  マルチモーダル通信
end note
@enduml
```

#### 補完関係

A2AとMCPは競合するものではなく、相互に補完し合う関係にあります。実際のアプリケーションでは、A2AエージェントをMCPリソース（AgentCardで表現）としてモデル化することが推奨されています。これにより、フレームワークはA2Aを使用してユーザー、リモートエージェント、その他のエージェントと通信でき、MCPを使ってツールやリソースにアクセスできます。

この組み合わせにより：
1. エージェントはMCPを通じて様々なツールや外部リソースにアクセス
2. エージェント同士はA2Aを通じて自然な形で連携
3. エンドユーザーは、単一のインターフェースで複数のエージェントが連携する恩恵を受ける

### 実世界での例：自動車修理店の例

A2AとMCPの違いと補完関係を自動車修理店の例で考えてみましょう：

自動車修理店では、自律的な作業員（エージェント）が特殊な目的のツール（車両ジャック、マルチメーター、ソケットレンチなど）を使用して問題を診断・修理します。作業員は以前に見たことのない問題を診断・修理することもあり、修理プロセスには顧客との広範な会話、調査、部品サプライヤーとの協力が必要な場合があります。

この修理店の従業員をAIエージェントとしてモデル化すると：

- **MCPは**、これらのエージェントと構造化されたツール（例：プラットフォームを2メートル上げる、レンチを右に4mm回す）を接続するプロトコルです。

- **A2Aは**、エンドユーザーや他のエージェントが修理店の従業員と協力するためのプロトコル（「私の車がガタガタ音を立てています」）です。A2Aは継続的な双方向コミュニケーションと、結果を達成するための進化するプランを可能にします（「左の車輪の写真を送ってください」、「液体が漏れているようですね。それはいつから起こっていますか？」）。A2Aはまた、自動車修理店の従業員が部品サプライヤーなどの他のエージェントと協力するのにも役立ちます。

### Part 3まとめ

A2AとMCPは、異なる目的を持ちながらも相互に補完し合うプロトコルです。MCPはエージェントとツール/リソースの接続に焦点を当て、A2Aはエージェント同士の協力を可能にします。両プロトコルを組み合わせることで、エージェントは構造化されたツールを使用しながら、他のエージェントと自然な方法で協力できるようになります。自動車修理店の例が示すように、実世界のシナリオでは両方のプロトコルが重要な役割を果たします。

## Part 4: 実世界での応用例

A2Aプロトコルは、様々な業界や用途でAIエージェントの連携を可能にします。以下に、A2Aがどのように実世界の問題を解決できるかの具体例を示します。

### 候補者採用プロセス

ソフトウェアエンジニアの採用プロセスは、A2Aプロトコルが複数のエージェントの連携をどのように改善できるかを示す良い例です。

```plantuml
@startuml
actor "採用マネージャー" as Manager
participant "主要エージェント" as MainAgent
participant "候補者検索エージェント" as SearchAgent
participant "スケジューリングエージェント" as ScheduleAgent
participant "バックグラウンドチェックエージェント" as BGAgent

Manager -> MainAgent: ソフトウェアエンジニアの\n候補者を探して
MainAgent -> SearchAgent: 職種、場所、スキルセットを指定して\n候補者を検索
SearchAgent --> MainAgent: 候補者リストを返す
MainAgent --> Manager: 候補者の提案を表示
Manager -> MainAgent: この候補者との面接を\nスケジュールして
MainAgent -> ScheduleAgent: 面接のスケジューリングを依頼
ScheduleAgent --> MainAgent: スケジュールされた面接の詳細
MainAgent --> Manager: 面接のスケジュールを通知
note right: 面接プロセス完了後
Manager -> MainAgent: バックグラウンドチェックを実施して
MainAgent -> BGAgent: バックグラウンドチェックを依頼
BGAgent --> MainAgent: チェック結果
MainAgent --> Manager: バックグラウンドチェックの結果を提示
@enduml
```

このシナリオでは、採用マネージャーは統一されたインターフェース（例：Agentspace）を通じて、自分のエージェントにジョブリスティング、場所、スキルセットに一致する候補者を探すよう依頼できます。エージェントは他の専門エージェントと連携して潜在的な候補者を見つけ出します。ユーザーはこれらの提案を受け取り、さらに面接のスケジュールを依頼できます。面接プロセス完了後、別のエージェントがバックグラウンドチェックを実施するために関与できます。

このように、AIエージェントはシステム間で連携して適格な候補者を見つけるプロセスを大幅に簡素化します。

### カスタマーサポート

顧客の問い合わせに対応するシナリオでも、A2Aは複数のシステムにまたがるエージェントの連携を可能にします。

```plantuml
@startuml
actor "顧客" as Customer
participant "サポートエージェント" as SupportAgent
participant "注文システムエージェント" as OrderAgent
participant "配送追跡エージェント" as ShippingAgent
participant "返品処理エージェント" as ReturnAgent

Customer -> SupportAgent: 注文した商品がまだ届きません
SupportAgent -> OrderAgent: 注文情報を取得
OrderAgent --> SupportAgent: 注文詳細を返す
SupportAgent -> ShippingAgent: 配送状況を確認
ShippingAgent --> SupportAgent: 配送遅延情報
SupportAgent --> Customer: 配送状況と遅延理由を説明
Customer -> SupportAgent: 返品したいです
SupportAgent -> ReturnAgent: 返品プロセスを開始
ReturnAgent --> SupportAgent: 返品ラベルと手順
SupportAgent --> Customer: 返品手順を提供
@enduml
```

このシナリオでは、サポートエージェントが顧客の問い合わせに対応するために、注文システム、配送追跡、返品処理の各エージェントと通信しています。A2Aプロトコルにより、これらのエージェントが異なるシステムで動作していても、シームレスに連携できます。

例えば：
1. 顧客が「注文した商品がまだ届かない」と問い合わせる
2. サポートエージェントが注文システムエージェントから注文情報を取得
3. 配送追跡エージェントと連携して配送状況を確認
4. 顧客に現在の状況と遅延理由を説明
5. 顧客が返品を希望した場合、返品処理エージェントと連携して返品手続きを案内

従来であれば、サポート担当者が複数のシステムにアクセスして情報を集める必要がありましたが、A2Aを活用すれば、エージェント間の連携により自動化できます。

### 財務レポート作成

財務レポートの作成プロセスも、A2Aプロトコルの活用例として挙げられます。

```plantuml
@startuml
actor "財務マネージャー" as Manager
participant "財務アシスタントエージェント" as FinanceAgent
participant "データ分析エージェント" as AnalysisAgent
participant "会計システムエージェント" as AccountingAgent
participant "レポート生成エージェント" as ReportAgent

Manager -> FinanceAgent: Q1の財務レポートを作成して
FinanceAgent -> AccountingAgent: Q1の財務データを取得
AccountingAgent --> FinanceAgent: 生データを返す
FinanceAgent -> AnalysisAgent: データ分析を依頼
AnalysisAgent --> FinanceAgent: 分析結果とインサイト
FinanceAgent -> ReportAgent: レポート生成を依頼
ReportAgent --> FinanceAgent: 完成したレポート
FinanceAgent --> Manager: 財務レポートを提示
Manager -> FinanceAgent: 特定のセクションについて詳細を教えて
FinanceAgent -> AnalysisAgent: 特定データの詳細分析を依頼
AnalysisAgent --> FinanceAgent: 詳細分析結果
FinanceAgent --> Manager: 詳細な説明と追加インサイト
@enduml
```

このシナリオでは、財務アシスタントエージェントが会計システム、データ分析、レポート生成の各エージェントと連携して、総合的な財務レポートを作成しています。各エージェントは特定の専門分野に特化しており、A2Aプロトコルによりこれらが連携して複雑なタスクを完了できます。

プロセスの流れ：
1. 財務マネージャーがQ1財務レポートの作成を依頼
2. 財務アシスタントが会計システムからデータを取得
3. データ分析エージェントがデータを分析してインサイトを提供
4. レポート生成エージェントが実際のレポートを作成
5. 財務マネージャーが特定セクションの詳細を依頼すると、財務アシスタントが再びデータ分析エージェントと連携

これにより、財務マネージャーは複数のシステムやツールを操作することなく、一貫したインターフェースを通じて複雑な財務分析を実行できます。

### Part 4まとめ

A2Aプロトコルは、様々な業界と用途で複雑なワークフローを自動化する可能性を秘めています。候補者採用、カスタマーサポート、財務レポート作成の例が示すように、A2Aを活用すれば、異なるシステムやドメインにまたがるエージェントが連携して、より効率的かつ効果的にタスクを完了できます。これにより、ユーザーは複数のシステムやツールを切り替える負担から解放され、より戦略的な作業に集中できるようになります。

## Part 5: A2Aの実装方法

### 実装の基本ステップ

A2Aプロトコルの実装を始めるためのステップを説明します。プロトコルはまだ開発中であり、コミュニティからのフィードバックを取り入れながら進化していますが、以下のステップで始めることができます。

```plantuml
@startuml
start
:Agent Cardの定義;
note right: エージェントの機能、スキル、認証方法を定義
:Agent Cardをホスティング;
note right: 通常は /.well-known/agent.json パスで公開
:クライアントまたはサーバーの実装を選択;
if (実装タイプ) then (クライアント)
  :A2Aクライアントの実装;
  :他のエージェントのAgent Cardを発見;
  :タスクを送信して結果を受信;
else (サーバー)
  :A2Aサーバーの実装;
  :リクエストを受け付けるエンドポイントを設定;
  :タスク処理ロジックを実装;
  :結果をクライアントに返送;
endif
:必要に応じてストリーミングとプッシュ通知を実装;
:セキュリティと認証を設定;
stop
@enduml
```

#### 1. 仕様の理解

まずはA2Aプロトコルの仕様を理解することが重要です。プロトコルの核となる部分は以下です：

- **エージェントカード**：エージェントの機能と認証要件を定義
- **タスク管理**：タスクの作成、更新、ステータス追跡
- **メッセージング**：エージェント間通信
- **認証**：セキュアな通信の確保

#### 2. サンプルコードの活用

Googleが提供するサンプルコードを参考にして、A2Aクライアントやサーバーの実装方法を学ぶことができます：

- **サンプルA2Aクライアントとサーバーのコード** (Python, JavaScript)
- **マルチエージェントWebアプリ**のサンプル
- **コマンドラインインターフェース** (CLI) (Python, JavaScript)

#### 3. エージェントフレームワークとの統合

A2Aは以下のようなエージェントフレームワークと統合できます：

- **Google Agent Developer Kit (ADK)**
- **CrewAI**
- **LangGraph**
- **Genkit**

各フレームワークへの統合方法のサンプルコードも提供されています。

### サンプル実装（Python）

以下は、A2Aクライアントとサーバーの基本的な実装例です：

**A2Aサーバー（エージェント）の例：**

```python
from flask import Flask, request, jsonify
import json

app = Flask(__name__)

@app.route('/.well-known/agent.json')
def agent_card():
    # Agent Cardを返す
    return jsonify({
        "name": "Example Agent",
        "description": "A simple A2A protocol example agent",
        "url": "https://example.com/agent",
        "version": "1.0.0",
        "authentication": {
            "schemes": ["none"]
        },
        "defaultInputModes": ["text/plain"],
        "defaultOutputModes": ["text/plain"],
        "capabilities": {
            "streaming": False,
            "pushNotifications": False
        },
        "skills": [{
            "id": "answer-questions",
            "name": "Answer questions",
            "description": "Answers general questions",
            "tags": ["general", "qa"],
            "examples": ["What is the weather today?"]
        }]
    })

@app.route('/api', methods=['POST'])
def handle_request():
    data = request.json
    
    # JSON-RPCリクエストの処理
    if data.get('method') == 'tasks/send':
        task_id = data['params']['id']
        message = data['params']['message']
        
        # メッセージテキストの取得
        text = next((part['text'] for part in message['parts'] if part['type'] == 'text'), "")
        
        # タスク処理（ここでは簡単な返答）
        response_text = f"You said: {text}. This is a response from the agent."
        
        return jsonify({
            "jsonrpc": "2.0",
            "id": data.get('id'),
            "result": {
                "id": task_id,
                "sessionId": "session-1",
                "status": {
                    "state": "completed"
                },
                "artifacts": [{
                    "parts": [{
                        "type": "text",
                        "text": response_text
                    }]
                }]
            }
        })
    
    return jsonify({"error": "Method not supported"})

if __name__ == '__main__':
    app.run(debug=True, port=5000)
```

**A2Aクライアントの例：**

```python
import requests
import json
import uuid

def discover_agent(url):
    """Agent Cardを取得"""
    response = requests.get(f"{url}/.well-known/agent.json")
    return response.json()

def send_task(agent_url, message_text):
    """タスクを送信"""
    task_id = str(uuid.uuid4())
    
    payload = {
        "jsonrpc": "2.0",
        "id": 1,
        "method": "tasks/send",
        "params": {
            "id": task_id,
            "message": {
                "role": "user",
                "parts": [{
                    "type": "text",
                    "text": message_text
                }]
            }
        }
    }
    
    response = requests.post(f"{agent_url}/api", json=payload)
    return response.json()

# 使用例
agent_url = "http://localhost:5000"
agent_card = discover_agent(agent_url)
print(f"Found agent: {agent_card['name']}")

response = send_task(agent_url, "Hello A2A agent!")
print("Response:")
print(json.dumps(response, indent=2))
```

これは非常に基本的な実装例ですが、A2Aプロトコルの基本的な概念と使い方を示しています。実際の実装では、認証、エラー処理、ストリーミング、プッシュ通知などの機能を追加する必要があります。

#### 実装時の注意点

1. **認証とセキュリティ**: 実際の環境では、OAuth、API Key、JWTなどの認証メカニズムを実装する必要があります。

2. **エラー処理**: ネットワークエラー、タイムアウト、認証失敗などのエラー状況に適切に対応するコードを実装します。

3. **長時間タスクの処理**: 長時間実行タスクの場合、ストリーミングまたはプッシュ通知を実装して、クライアントに進捗状況を通知します。

4. **マルチモーダル対応**: テキスト以外のデータ（画像、ファイル、構造化データなど）の送受信をサポートする実装を検討します。

### Part 5まとめ

A2Aプロトコルの実装は、エージェントカードの定義から始まり、クライアントまたはサーバーの実装、そして必要に応じてストリーミングやプッシュ通知の実装へと進みます。提供されたサンプルコードは基本的な実装を示していますが、実際のアプリケーションでは認証、エラー処理、マルチモーダル対応などの機能を追加する必要があります。Google Agent Developer Kit (ADK)、CrewAI、LangGraphなどのフレームワークとの統合も可能で、これらを活用することで実装を加速できます。

## Part 6: 現状と今後の展望

### 現在の開発状況

A2Aプロトコルは、現在オープンソースとして公開されており、コミュニティからのフィードバックを取り入れながら開発が進められています。現時点でのA2Aは：

- プロトコルの仕様書ドラフトが公開
- 基本的なサンプルコードと実装例が利用可能
- 50社以上のテクノロジーパートナーが貢献
- 本番環境向けのバージョンは2025年後半にリリース予定

Google、Atlassian、Salesforce、SAP、ServiceNowなどの大手テクノロジー企業や、Accenture、BCG、Deloitte、KPMG、McKinseyなどの主要なサービスプロバイダーからの支援を受けています。

### 今後のロードマップ

A2Aプロトコルの今後の開発計画は以下の通りです：

1. **プロトコル自体の改善**：
   - **エージェント発見**：AgentCard内の認可スキームとオプションの認証情報の直接含有を正式化
   - **エージェント協力**：サポートされていないまたは予期しないスキルを動的に確認するQuerySkill()メソッドの調査
   - **タスクライフサイクルとUX**：タスク内で動的なUXネゴシエーションをサポート（例：会話の途中でエージェントがオーディオ/ビデオを追加）
   - **クライアントメソッドとトランスポート**：クライアント起動メソッドのサポート拡張
   - ストリーミングの信頼性とプッシュ通知メカニズムの改善

2. **サンプルとドキュメントの強化**：
   - "Hello World"の例の簡素化
   - 異なるフレームワークで統合されたエージェントや特定のA2A機能を示す追加例
   - 共通クライアント/サーバーライブラリのより包括的なドキュメント
   - JSONスキーマからの人間が読めるHTMLドキュメントの生成

### 業界への影響

A2Aプロトコルが広く採用されれば、以下のような影響が期待されます：

1. **エージェントエコシステムの拡大** 🌱: 異なるベンダーやフレームワークのエージェントが協力できるようになり、より複雑なタスクが可能に

2. **開発の効率化** ⚡: エージェント間連携のための標準インターフェースにより、開発者は個々のエージェントの専門性に集中できる

3. **ユーザー体験の向上** 🎯: 複数のエージェントによるシームレスな連携が、よりスムーズで一貫性のあるユーザー体験を実現

4. **イノベーションの加速** 🚀: オープンな標準により、新しいタイプのエージェントやサービスが登場しやすくなる

5. **企業のAI導入促進** 💼: 既存のITスタックとの統合が容易になり、企業のAIエージェント採用が加速

```plantuml
@startuml
skinparam backgroundColor white
skinparam defaultFontName SansSerif

rectangle "現在の状況" as Now {
  [仕様書ドラフト] as Spec
  [サンプルコード] as Sample
  [基本的な実装例] as Impl
  [業界パートナーの支援] as Partner
}

rectangle "今後の展望" as Future {
  [プロトコル改善] as Protocol
  [ドキュメント強化] as Doc
  [多様なフレームワーク統合] as Framework
  [業界標準化] as Standard
}

Now --> Future

rectangle "期待される影響" as Impact {
  [エージェントエコシステム拡大] as Ecosystem
  [開発効率化] as Efficiency
  [ユーザー体験向上] as UX
  [イノベーション加速] as Innovation
  [企業AI導入促進] as Adoption
}

Future --> Impact
@enduml
```

### Part 6まとめ

A2Aプロトコルは、AIエージェント間の相互運用性を実現するための重要な取り組みとして、業界全体から注目と支援を受けています。現在は仕様書ドラフトとサンプル実装の段階ですが、今後のロードマップには様々な改善と強化が含まれており、2025年後半には本番環境向けのリリースが予定されています。このプロトコルが広く採用されれば、エージェントエコシステムの拡大、開発効率の向上、ユーザー体験の改善、イノベーションの加速、企業のAI導入促進など、多くの分野に影響を与えることが期待されます。

## まとめ

A2A（Agent2Agent）プロトコルは、AIエージェント間の相互運用性に関する重要な進展を表しています。様々なベンダーやフレームワークで構築されたエージェントが連携できるようにすることで、A2Aはエンタープライズ環境におけるAIエージェントの実用性と効果を大幅に向上させる可能性を秘めています。

### 主要なポイント

1. **オープンで協調的** 🤝: GoogleとともにAtlassian、Salesforce、SAPなど50社以上のパートナーが参加する業界全体の取り組み

2. **既存標準の上に構築** 🏗️: HTTP、SSE、JSON-RPCなどの一般的な標準を活用し、既存システムとの統合を容易に

3. **セキュリティを重視** 🔒: 企業グレードの認証と認可をサポート

4. **実用的な設計** ⚙️: 短時間のタスクから長時間実行される複雑なワークフローまでサポート

5. **マルチモーダル** 📊: テキスト、オーディオ、ビデオなど様々な形式の通信をサポート

6. **MCPとの補完関係** 🧩: MCPがエージェントとツールの接続に焦点を当てる一方、A2Aはエージェント間の協力に重点

### 企業にとっての意義

A2Aプロトコルは、特に以下の点で企業に大きな価値をもたらします：

1. **シームレスな統合**: 異なるシステムやプラットフォームにまたがるAIエージェントの連携

2. **コスト削減**: エージェント間連携のためのカスタム開発の必要性を減少

3. **スケーラビリティの向上**: 標準化されたプロトコルにより、新しいエージェントやサービスの追加が容易に

4. **より複雑なタスクの自動化**: 複数のエージェントが協力することで、より高度な業務プロセスの自動化が可能に

### 開発者にとっての意義

開発者の視点からは、A2Aは以下のメリットを提供します：

1. **標準化されたインターフェース**: 異なるエージェントフレームワークとの通信方法が統一

2. **柔軟な実装オプション**: 様々な言語やフレームワークでの実装が可能

3. **コミュニティの支援**: オープンソースの取り組みとして、継続的な改善と拡張が期待できる

4. **エコシステムへの参加**: 自分のエージェントをより大きなエコシステムの一部として提供できる

A2Aプロトコルはまだ初期段階にありますが、AIエージェント間の相互運用性の標準となる可能性を持っています。今後の発展により、エージェント間の通信がさらに強化され、より複雑で高度なエージェントエコシステムの構築が可能になるでしょう。

企業や開発者は、A2Aプロトコルの動向に注目し、このオープンな標準の発展に貢献することで、次世代のAIエージェントエコシステムの形成に参加することができます。

## 学習確認クイズ

A2Aプロトコルの理解を確認するために、以下のクイズに挑戦してみましょう：

1. A2Aプロトコルの主な目的は何ですか？
   - A) LLMの訓練データを標準化する
   - B) 異なるベンダーやフレームワークで構築されたAIエージェント間の通信を可能にする
   - C) クラウドプラットフォーム間のデータ転送を標準化する
   - D) AIモデルのパラメータを共有する

2. A2AとMCPの関係について正しい説明はどれですか？
   - A) A2AはMCPの代替プロトコルである
   - B) A2AとMCPは競合するプロトコルである
   - C) A2AはMCPを補完し、エージェント間の通信に焦点を当てている
   - D) A2AはMCPのサブセットである

3. A2Aプロトコルの核となるコンポーネントはどれですか？（複数選択可）
   - A) Agent Card
   - B) Task
   - C) Message
   - D) Neural Network
   - E) Artifact

4. A2Aプロトコルにおける「タスク」の状態として正しくないものはどれですか？
   - A) submitted
   - B) working
   - C) paused
   - D) completed
   - E) failed

5. A2Aプロトコルが構築されている既存の標準として正しいものはどれですか？（複数選択可）
   - A) HTTP
   - B) GraphQL
   - C) SSE
   - D) JSON-RPC
   - E) WebSocket

<details>
<summary>正解を見る</summary>

1. B
2. C
3. A, B, C, E
4. C (正しい状態は submitted, working, input-required, completed, failed, canceled)
5. A, C, D
</details>

## 参考リソース

A2Aプロトコルについてさらに学ぶための参考リソース：

- [A2A公式ウェブサイト](https://a2a.google/)
- [A2A GitHubリポジトリ](https://github.com/google/A2A)
- [A2Aサンプルコード](https://github.com/google/A2A/tree/main/samples)
- [A2A仕様書](https://github.com/google/A2A/tree/main/specification/json)
- [Google開発者ブログの発表記事](https://developers.googleblog.com/2025/04/announcing-agent2agent-protocol-a2a.html)

---

A2A（Agent2Agent）プロトコルは、AIエージェントの相互運用性を実現するための重要な一歩です。このオープンな標準が成熟し、広く採用されることで、より強力で協調的なAIエージェントエコシステムが実現し、企業と個人のためのAIの価値を最大化することが期待されます。🚀