はじめに
RAG の登場により、LLM の一般的な回答から、より業務に特化した具体的な回答が得られるようになり、非常に便利に、実用的になってきました。一方で、RAG でも思ったような回答が得られなかったり、大量の情報を詰め込み過ぎてしまうと、精度があがらなくなるといった課題があることも明らかになってきました。そこで注目されるのが、複数の特化型エージェントが連携し、協調してタスクを遂行するマルチエージェントシステムです。今回は、Google社が提供する Agent Development Kit (ADK) を用いて、エージェント間の協調的な通信（A2A: Agent-to-Agent通信）を実装してみましたので共有します。
A2Aとは？MCPとの関係は？
A2A（Agent-to-Agent）通信は、エージェント間の「会話」を標準化するプロトコルです。MCPは、エージェントが外部のツールやデータ、コンテキスト情報を利用するための方法を標準化するプロトコルですが、それをさらに複数のエージェント間に広げることができる様になります。A2A の１つのエージェントとして MCP を利用することもできます。
Google ADKとは？
Google ADK（Agent Development Kit）は、A2A通信に対応した AIエージェントの開発とデプロイを加速させるためのフレームワークです。その特徴は以下の通りです。
・LLMとの統合
GeminiなどのLLMとの連携がシームレスに行え、エージェントの「思考」の核となります。
・ツール利用の抽象化
外部システムや他のエージェントとの連携を「ツール」として抽象化し、LLMが適切なツールを自律的に選択・実行できるメカニズムを提供します。
・A2A通信プロトコル
エージェント間でタスクを委譲し、結果を受け渡すための標準化されたプロトコルを定義しており、これがマルチエージェントシステムの肝となります。
・デプロイメントの容易性
Cloud Runなどのサーバーレス環境へのデプロイが考慮されており、スケーラブルなエージェントの運用を支援します。
今回のエージェント構成
今回の実験では、よくある社内稟議の決裁が誰の権限で、自分の部署では誰の決裁か必要となるかを確認したいとき、をイメージして、簡単な問い合わせへの対応ができるようにしました。以下の3つのエージェントが連携します。
①決裁情報エージェント (kessai-info-agent)
購買情報（金額情報、所属部署など）に基づいて、関連する決裁権者を特定する専門エージェントです。簡単に作成方法を記載します。
あらかじめ、決裁権限を登録したExcel表をPDFにして、（以下PDFの内容）
RAG情報として AI Applications の データストア に登録しておきます。
エージェント側では、RAGへの参照と、エージェントの動作（何を目的としたもので、どのように回答するか）を、プロンプトとして記述します。
また、A2A Server として、エージェントカード(Agent Card)を作成します。
Cloud Runとしてデプロイします。
ADK webという便利なツールがあり、これを使って単体の動作確認ができます。
②社員情報エージェント (syain-info-agent)
事業部、部署、役職などから、社員の名前やメールアドレスなどの情報を取得する専門エージェントです。簡単に作成方法を記載します。
あらかじめ、社員権限を登録したExcel表をPDFにして、RAG情報として AI Applications の データストア に登録しておきます。（以下PDFのデータ）
エージェント側では、RAGへの参照と、エージェントの動作（何を目的としたもので、どのように回答するか）を、プロンプトとして記述します。
また、A2A Server として、エージェントカード(Agent Card)を作成します。
Cloud Runとしてデプロイします。
こちらも同様に、ADK web ツールを使って単体の動作確認ができます。
２つのエージェントが登録できると、下記の様になります。
③オーケストレートエージェント (orchestrate-agent)
２つのエージェントが正しく登録できたら、全体調整をつかさどるオーケストレートエージェントを作成します。オーケストレートエージェントは、ユーザーからの初期リクエストを受け取るフロントエンドエージェントとしての役割を担います。LLM (Gemini 2.0 Flash) を中核とし、list_remote_agentsツールで利用可能な子エージェント（kessai-info-agentとsyain-info-agent）を動的に認識し、send_taskツールでタスクを適切に委譲します。
複雑な要求を複数のステップに分解し、子エージェントからの応答を統合して最終的なユーザー応答を構築します。主な内容は、どのようにエージェント間の通信をするのか、ユーザの依頼にどのように答えるのかを、プロンプトとして記述することです。
Vertex AI の Agent Engine としてデプロイします。
これで準備は完了です。（と簡単に書きましたが、ここに来るまでは結構いろいろありました^^;）
動作の確認
本来は Webアプリケーションとしてお出ししたいところですが、今回は ADK web を用いて行いました。
orchestrate を選択します。ADK web の画面は下記の様なイメージとなります。
orchestrate エージェントとの会話は下記の様になりました。
各エージェントは認識できているものの、エージェントをこちらで指示するなど、ちょっと残念な結果となりました。
そこで、orchestrate エージェントの send_task ツールにおいて、プロンプトに以下を追加しました。
kessai-info-agent: 決裁情報についての専門エージェントです。用途や決裁金額から決裁権者を返します。
syain-info-agent：社員情報についての専門エージェントです。部門情報や権限情報から、社員の氏名やメールアドレスを返します。また社員の名前やメールアドレスから部門情報や権限情報を返します。
この結果、再度実行してみると、動作が変わり、一回の質問で回答が得られるようになりました。
まだまだ洗練できるとは思いましたが、今回はここまでといたしました。
まとめ
今回は「Google ADKを使ってA2Aマルチエージェント通信を実験してみた」とのタイトルで、簡単ではありますが、サンプルデータとサンプルエージェントを作成して、実験を行ってみました。ただ、この仕組みを拡張するだけでも、社内業務や日常においても結構役に立つのではないかと思いました。
引き続き、A2A からの MCP の利用（データベースアクセスや外部ツールの利用）などについても確認していきたいと思います。