A2Aの概要¶
より複雑なエージェントシステムを構築するにつれて、単一のエージェントでは不十分であることが多いことに気付くでしょう。問題を解決するために連携できる特殊なエージェントを作成したくなるでしょう。Agent2Agent(A2A)プロトコルは、これらのエージェントが相互に通信できるようにするための標準です。
A2Aとローカルサブエージェントの使い分け¶
-
ローカルサブエージェント: これらは、メインエージェントと同じアプリケーションプロセス内で実行されるエージェントです。これらは、コードを論理的で再利用可能なコンポーネントに整理するために使用される内部モジュールやライブラリのようなものです。メインエージェントとそのローカルサブエージェント間の通信は、ネットワークのオーバーヘッドなしでメモリ内で直接行われるため、非常に高速です。
-
リモートエージェント(A2A): これらは、ネットワークを介して通信する個別のサービスとして実行される独立したエージェントです。A2Aは、この通信の標準プロトコルを定義します。
次のような場合は、A2Aの使用を検討してください。
- 対話する必要のあるエージェントが個別のスタンドアロンサービスである場合(例:専門の金融モデリングエージェント)。
- エージェントが別のチームまたは組織によって維持されている場合。
- 異なるプログラミング言語またはエージェントフレームワークで記述されたエージェントを接続する必要がある場合。
- システムのコンポーネント間に強力で正式な契約(A2Aプロトコル)を適用したい場合。
A2Aを使用する場合の具体例¶
- サードパーティサービスとの統合: メインエージェントは、外部の金融データプロバイダーからリアルタイムの株価を取得する必要があります。このプロバイダーは、A2A互換エージェントを介してデータを提供します。
- マイクロサービスアーキテクチャ: 注文処理エージェント、在庫管理エージェント、配送エージェントなど、より小さく独立したサービスに分割された大規模なシステムがあります。A2Aは、これらのサービスがネットワーク境界を越えて相互に通信するのに最適です。
- クロス言語通信: コアビジネスロジックはPythonエージェントにありますが、エージェントとして統合したいJavaで記述されたレガシーシステムまたは特殊なコンポーネントがあります。A2Aは、標準化された通信レイヤーを提供します。
- 正式なAPIの適用: さまざまなチームがエージェントを提供するプラットフォームを構築しており、互換性と安定性を確保するために、これらのエージェントがどのように相互作用するかについて厳密な契約が必要です。
A2Aを使用しない場合の具体例(ローカルサブエージェントを推奨)¶
- 内部コードの整理: 単一のエージェント内の複雑なタスクを、処理前に入力データをクリーンアップする
DataValidatorサブエージェントなど、より小さく管理しやすい関数またはモジュールに分割しています。これらは、パフォーマンスとシンプルさのためにローカルサブエージェントとして処理するのが最適です。 - パフォーマンスが重要な内部操作: サブエージェントは、メインエージェントの実行と密接に結合された高頻度、低遅延の操作を担当します(例:同じアプリケーション内でデータストリームを処理する
RealTimeAnalyticsサブエージェント)。 - 共有メモリ/コンテキスト: サブエージェントが効率のためにメインエージェントの内部状態または共有メモリに直接アクセスする必要がある場合、A2Aのネットワークオーバーヘッドとシリアル化/逆シリアル化は非生産的です。
- 単純なヘルパー関数: 独立した展開や複雑な状態管理を必要としない、再利用可能な小さなロジックの場合、同じエージェント内の単純な関数またはクラスが、別のA2Aエージェントよりも適切です。
ADKにおけるA2Aワークフロー:簡略図¶
Agent Development Kit(ADK)は、A2Aプロトコルを使用してエージェントを構築および接続するプロセスを簡素化します。その仕組みを簡単に説明します。
-
エージェントをアクセス可能にする(公開): 他のエージェントが対話できるようにしたい既存のADKエージェントから始めます。ADKは、このエージェントを「公開」してA2AServerに変換する簡単な方法を提供します。このサーバーはパブリックインターフェイスとして機能し、他のエージェントがネットワーク経由でエージェントにリクエストを送信できるようにします。エージェント用のWebサーバーをセットアップするようなものだと考えてください。
-
アクセス可能なエージェントへの接続(消費): 別のエージェント(同じマシンまたは別のマシンで実行されている可能性があります)で、
RemoteA2aAgentと呼ばれる特別なADKコンポーネントを使用します。このRemoteA2aAgentは、以前に公開したA2AServerと通信する方法を知っているクライアントとして機能します。ネットワーク通信、認証、データフォーマットのすべての複雑さをバックグラウンドで処理します。
開発者の観点からは、この接続をセットアップすると、リモートエージェントとの対話は、ローカルツールまたは関数との対話とまったく同じように感じられます。ADKはネットワーク層を抽象化し、分散エージェントシステムをローカルシステムと同じくらい簡単に扱えるようにします。
A2Aワークフローの視覚化¶
A2Aワークフローをさらに明確にするために、エージェントの公開と消費の両方の「前後」と、結合されたシステムを見てみましょう。
エージェントの公開¶
公開前: エージェントコードはスタンドアロンコンポーネントとして実行されますが、このシナリオでは、他のリモートエージェントがエージェントと対話できるように公開したいと考えています。
公開後:
エージェントコードはA2AServer(ADKコンポーネント)と統合され、他のリモートエージェントがネットワーク経由でアクセスできるようになります。
+-----------------+
| A2Aサーバー |
| (ADKコンポーネント) |<--------+
+-----------------+ |
| |
v |
+-------------------+ |
| エージェントコード | |
| (アクセス可能) | |
+-------------------+ |
|
| (ネットワーク通信)
v
+-----------------------------+
| リモートエージェント |
| (通信可能) |
+-----------------------------+
エージェントの消費¶
消費前: このコンテキストでは「ルートエージェント」と呼ばれるエージェントは、リモートエージェントと対話する必要がある開発中のアプリケーションです。消費する前は、直接的なメカニズムがありません。
+----------------------+ +-------------------------------------------------------------+
| ルートエージェント | | リモートエージェント |
| (既存のコード) | | (ルートエージェントが対話したい外部サービス) |
+----------------------+ +-------------------------------------------------------------+
消費後:
ルートエージェントは、RemoteA2aAgent(リモートエージェントのクライアント側プロキシとして機能するADKコンポーネント)を使用して、リモートエージェントとの通信を確立します。
+----------------------+ +-----------------------------------+
| ルートエージェント | | RemoteA2aAgent |
| (既存のコード) |<------->| (ADKクライアントプロキシ) |
+----------------------+ | |
| +-----------------------------+ |
| | リモートエージェント | |
| | (外部サービス) | |
| +-----------------------------+ |
+-----------------------------------+
(RemoteA2aAgent経由でリモートエージェントと対話)
最終的なシステム(結合ビュー)¶
この図は、消費側と公開側がどのように接続して完全なA2Aシステムを形成するかを示しています。
消費側:
+----------------------+ +-----------------------------------+
| ルートエージェント | | RemoteA2aAgent |
| (既存のコード) |<------->| (ADKクライアントプロキシ) |
+----------------------+ | |
| +-----------------------------+ |
| | リモートエージェント | |
| | (外部サービス) | |
| +-----------------------------+ |
+-----------------------------------+
|
| (ネットワーク通信)
v
公開側:
+-----------------+
| A2Aサーバー |
| (ADKコンポーネント) |
+-----------------+
|
v
+-------------------+
| エージェントコード |
| (公開サービス) |
+-------------------+
具体的なユースケース:カスタマーサービスと製品カタログエージェント¶
別の製品カタログエージェントから製品情報を取得する必要があるカスタマーサービスエージェントという実用的な例を考えてみましょう。
A2A以前¶
当初、カスタマーサービスエージェントは、特にそれが別のサービスであるか、別のチームによって管理されている場合、製品カタログエージェントを照会するための直接的で標準化された方法がない場合があります。
+-------------------------+ +--------------------------+
| カスタマーサービスエージェント | | 製品カタログエージェント |
| (製品情報が必要) | | (製品データを含む) |
+-------------------------+ +--------------------------+
(直接的で標準化された通信なし)
A2A以降¶
A2Aプロトコルを使用することにより、製品カタログエージェントは、その機能をA2Aサービスとして公開できます。その後、カスタマーサービスエージェントは、ADKのRemoteA2aAgentを使用してこのサービスを簡単に利用できます。
+-------------------------+ +-----------------------------------+
| カスタマーサービスエージェント | | RemoteA2aAgent |
| (ルートエージェント) |<------->| (ADKクライアントプロキシ) |
+-------------------------+ | |
| +-----------------------------+ |
| | 製品カタログエージェント | |
| | (外部サービス) | |
| +-----------------------------+ |
+-----------------------------------+
|
| (ネットワーク通信)
v
+-----------------+
| A2Aサーバー |
| (ADKコンポーネント) |
+-----------------+
|
v
+------------------------+
| 製品カタログエージェント |
| (公開サービス) |
+------------------------+
この設定では、まず、製品カタログエージェントをA2Aサーバー経由で公開する必要があります。次に、カスタマーサービスエージェントは、RemoteA2aAgentのメソッドをツールであるかのように呼び出すだけで、ADKが製品カタログエージェントへのすべての基盤となる通信を処理します。これにより、懸念事項の明確な分離と特殊なエージェントの簡単な統合が可能になります。
次のステップ¶
A2Aの「なぜ」を理解したところで、「どのように」を掘り下げてみましょう。
- 次のガイドに進む: クイックスタート:エージェントの公開