Strands AgentsのA2AでHTTPベースのエージェント間通信を試してみた
こんにちは。サービス開発室の武田です。
前回の記事ではWorkflowパターンについて紹介しました。今回は A2A（Agent-to-Agent） パターンを試してみます。
A2Aとは
A2Aは、エージェントをHTTPサーバーとして公開し、異なるシステム間で連携させるためのオープンプロトコル です。
A2A Protocol公式サイトでは次のように定義されています。
The Agent2Agent (A2A) Protocol is an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems.
「独立した、潜在的に不透明なAIエージェントシステム間の通信と相互運用性を促進するためのオープン標準」ということですね。これまで紹介してきたパターン（Agents as Tools、Graph、Swarm、Workflow）はすべて 同一プロセス内 での協調でした。A2Aは プロセスやプラットフォームをまたいだ エージェント間通信を実現します。
なぜこのパターンを使うのか
公式ドキュメントでは、A2Aの主要なユースケースとして次の点が挙げられています。
| ユースケース | 説明 |
|---|---|
| Multi-Agent Workflows | 複数の専門エージェントの連鎖実行 |
| Agent Marketplaces | 異なるプロバイダーのエージェント発見と利用 |
| Cross-Platform Integration | Strands以外のA2A対応システムとの接続 |
| Distributed AI Systems | スケーラブルな分散エージェント構造の構築 |
特に マイクロサービスアーキテクチャ との親和性が高いですね。既存のマイクロサービスをエージェントとして公開したり、異なるチームが開発したエージェントを統合したりするケースで使えそうです。
他のパターンとの位置付け
これまでのパターンとA2Aの違いを整理します。
| パターン | 通信方式 | スコープ |
|---|---|---|
| Agents as Tools | 関数呼び出し | 同一プロセス |
| Graph | 関数呼び出し | 同一プロセス |
| Swarm | 関数呼び出し | 同一プロセス |
| Workflow | 関数呼び出し | 同一プロセス |
| A2A | HTTP | プロセス間/プラットフォーム間 |
A2Aは唯一、プロセスの境界を越える ことができるパターンです。
基本的なしくみ
A2Aの構造を図で示すとこうなります。
A2Aは「サーバー」と「クライアント」に分かれます。サーバーはエージェントをHTTPエンドポイントとして公開し、クライアントはそのエンドポイントに接続してメッセージを送受信します。
エージェントカード
A2Aでは、サーバーが「エージェントカード」を公開します。これはエージェントの名前、説明、利用可能なスキルなどのメタ情報を含むJSONドキュメントです。クライアントはこのカードを取得することで、接続先のエージェントが何をできるかを事前に把握できます。
追加インストール
A2Aを使用するには、追加の依存関係をインストールします。
# pipの場合
pip install strands-agents[a2a]
# uvの場合
uv sync --extra a2a
実装例: サーバーとクライアント
サーバー側
エージェントをA2Aサーバーとして公開します。まずはツールの定義です。
計算と挨拶ができるシンプルなツールを定義しています。
続いてA2Aサーバーの作成と起動です。
A2AServerにエージェントを渡してserve()を呼び出すだけです。エージェントのnameとdescriptionは、クライアントがエージェントを発見する際に使用される「エージェントカード」として公開されます。
クライアント側
次に、A2Aサーバーに接続するクライアントを実装します。
クライアントの実装はこんな流れです。
A2ACardResolverでエージェントカードを取得ClientFactoryでクライアントを作成Messageを作成してsend_message()で送信（async forでレスポンスを処理）
統合デモ
サーバーとクライアントを別々のターミナルで実行する代わりに、単一スクリプトで動作を確認できるデモも用意しています。
サーバーをバックグラウンドスレッドで起動し、その後クライアントから接続しています。
ポイント
- A2Aクライアントは 非同期（async/await） を使用
asyncio.run()でイベントループを管理- エージェントカードにより、クライアントはサーバーの機能を事前に把握できる
A2Aの活用シーン
マイクロサービス連携
既存のマイクロサービスをA2Aエージェントとして公開することで、AIエージェントから利用可能になります。
たとえば、既存の決済サービスや在庫管理システムをA2Aでラップすることで、AIエージェントが自然言語で「在庫を確認して」と言えば、適切なAPIを呼び出せます。
クロスプラットフォーム
A2Aはオープンプロトコルですので、Strands Agents以外のフレームワークとも連携できます。
- Python ↔ TypeScript
- クラウド ↔ オンプレミス
- 社内システム ↔ 外部サービス
エージェントマーケットプレイス
将来的には、A2A対応エージェントを公開・発見・利用するマーケットプレイスも期待されています。公式サイト（https://a2a-protocol.org/）でプロトコルの詳細が公開されています。
A2AClientToolProvider
Strands Agentsでは、A2Aエージェントを ツールとして 組み込むことも可能です。
from strands import Agent
from strands_tools.a2a_client import A2AClientToolProvider
# A2Aエージェントをツールとして取得
provider = A2AClientToolProvider(
known_agent_urls=["http://127.0.0.1:9000"]
)
# 通常のツールと同様にエージェントに渡す
agent = Agent(tools=provider.tools)
これにより、リモートのA2Aエージェントをローカルのツールと同じ感覚で使えます。Agents as Toolsパターンとの組み合わせですね。
このパターンが向いているケース
| 向いているケース | 向いていないケース |
|---|---|
| マイクロサービス連携 | 同一プロセス内の単純な連携 |
| 異なるプラットフォーム間の通信 | レイテンシーが重要な場合 |
| 分散システムの構築 | シンプルな単一エージェント |
| 外部チームが開発したエージェントとの統合 | ネットワーク接続がない環境 |
同一プロセス内であれば Agents as Tools や Graph で十分ですが、システム境界を越える 必要がある場合にA2Aが活躍します。
注意点
ネットワーク依存
A2AはHTTP通信を使用するため、ネットワークの状態に依存します。タイムアウトやリトライの設定は適切に行いましょう。
セキュリティ
サンプルコードでは省略していますが、本番環境ではTLS、APIキー、OAuth等の認証・認可を忘れずに。
非同期処理
A2Aクライアントは非同期APIを使用します。既存の同期コードと統合する場合は、asyncio.run()やasync/await周りを押さえておきましょう。
まとめ
A2Aは、Strands Agentsで HTTPプロトコルによるエージェント間通信 を実現するパターンです。
これまでのパターン（Agents as Tools、Graph、Swarm、Workflow）はすべて同一プロセス内での協調でしたが、A2Aはプロセスやプラットフォームの境界を越えることができます。マイクロサービスアーキテクチャとの親和性が高く、異なるチームが開発したエージェントを統合するようなケースで活躍しそうですね。
次回は最終回として、これまで紹介した複数のパターンを 組み合わせた複合パターン について紹介します。どなたかの参考になれば幸いです。
