複数のAIエージェントに役割を分担させ、互いに通信しながら一つのタスクを完結させる仕組みをPythonで実装できる時代になりました。

この記事でわかること：

  • Google ADKとA2Aプロトコルの基本的な仕組み
  • 5エージェントで動くコース生成パイプラインの構成
  • ローカル開発からAzure Container Instancesへのデプロイ手順
  • Gemini CLIをADK開発に活用する方法

Google ADKとは

https://github.com/google/adk-python

Google Agent Development Kit（ADK）は、GoogleがOSSとして公開したPython製のマルチエージェント構築フレームワークです。単一のLLMでは対処しにくい複雑なタスクを、役割が異なる複数のエージェントに分割して処理させる設計を提供します。Geminiモデルに最適化されていますが、モデル非依存・デプロイ先非依存の設計になっており、他のLLMやクラウドでも動作します。

エージェント同士の通信には、GoogleのA2A（Agent-to-Agent）プロトコルを使います。A2Aは、異なるサービスや異なるデプロイ先に置かれたエージェント間の通信を標準化するオープンな規格です。HTTPベースのAPIを通じて、エージェントが互いの「エージェントカード」を参照し、タスクを委譲できます。

5エージェントで構成されたコース生成システム

今回取り上げるのは、ADKとA2Aを組み合わせてAzure Container Instances（ACI）上に動かしたオンラインコース生成パイプラインです。

https://github.com/xbill9/gemini-cli-azure

ユーザーがトピックを入力すると、次の5エージェントが連携してコース教材を生成します。

  • Researcher：Google検索でトピック関連の情報を収集する
  • Judge：リサーチ内容の品質を評価し承認または差し戻す
  • Orchestrator：全エージェントの処理順序と状態を管理する
  • Content Builder：承認済みリサーチをもとにテキストコンテンツを生成する
  • Course Builder：コンテンツを組み立て、最終的なコース構成を出力する

「インターネットの歴史」をトピックに入力すると、OrchestratorがResearcherに調査を依頼し、Judgeが品質を判断し、Content BuilderとCourse Builderが教材を完成させます。各エージェントはA2Aプロトコルで通信するため、それぞれ独立したエンドポイントとして動いています。

Gemini CLIをADK開発に使う

開発支援にはGemini CLIを使います。npmでインストールし、Googleアカウントで認証するだけで使い始められます。

npm install -g @google/gemini-cli

Gemini CLIにはADK専用のスキルとMCPサーバーが組み込まれており、/skills listでスキル一覧を確認できます。主なスキルは以下のとおりです。

  • adk-cheatsheet：ADKのPython APIリファレンス
  • adk-scaffold：新規エージェントプロジェクトの雛形生成
  • adk-deploy-guide：Cloud Run・GKE・CI/CDへのデプロイ手順
  • adk-observability-guide：Cloud Trace・BigQueryによるログ分析

/mcp listでMCPサーバーの状態を確認でき、ADKのドキュメントをリアルタイムに参照しながら開発を進められます。ローカル環境のエージェントログをGemini CLIから直接参照してデバッグするワークフローも機能します。

ローカル環境でのセットアップ

リポジトリをクローンし、初期化スクリプトを実行します。

git clone https://github.com/xbill9/gemini-cli-azure
cd gemini-cli-azure/multi-aci
source init2.sh
make install

make runを実行すると全エージェントとフロントエンドが一括起動します。ブラウザからはhttp://localhost:5173でUIに、http://localhost:8000でバックエンドにアクセスできます。ADKのWeb UIはadk web --host 0.0.0.0で起動でき、エージェントごとの動作を個別に確認できます。

各エージェントは独立したA2Aエンドポイントを持ち、ローカルでは以下のようなURLで動きます。

http://localhost:8003/a2a/content_builder/.well-known/agent-card.json

エージェントカードはA2A規格に従い、エージェントの能力とインターフェースを記述するJSONドキュメントです。OrchestratorはこのURLを参照して他エージェントを動的に発見します。

Azure Container Instancesへのデプロイ

デプロイ先のACI（Azure Container Instances）は、VMを管理せずDockerコンテナを実行できるサーバーレスサービスです。秒単位の課金と高速起動が特徴で、マルチエージェントのような複数コンテナをコンテナグループとしてまとめてデプロイできます。

Azureにログインしてデプロイコマンドを実行します。

az login
make deploy-aci

内部では、5つのエージェントイメージをビルドしてAzure Container Registryにプッシュしたあと、aci-container-group.yamlをもとにコンテナグループを作成します。Log Analyticsワークスペースが自動で連携されるため、各エージェントのログをAzure Monitor上で確認できます。

デプロイ後はmake endpointで公開URLを取得できます。

http://course-creator-group-penguin.westus2.azurecontainer.io:8080/

Gemini CLIからデプロイ済みエンドポイントのログを参照しながらE2Eテストを実行でき、最終的なコードレビューも同じツールで完結します。

A2Aサポートの現状と注意点

ADKのA2A関連コンポーネント（RemoteA2aAgent、A2aAgentExecutorなど）は現時点でexperimental扱いです。A2Aプロトコル自体は安定していますが、ADK側の実装は今後のバージョンで変更される可能性があります。本番導入する際は変更履歴を追いながら設計する必要があります。

ADKはおよそ2週間ごとにリリースされており、最新の安定版はpip install google-adkで入手できます。

最後に

ADKとA2Aを組み合わせると、エージェントを独立したサービスとして設計し、標準プロトコルで連携させる構成をPythonで書けます。GeminiモデルやGoogle Cloudに縛られない設計のため、AzureチームもAWSチームも導入の障壁は低めです。Gemini CLIが開発・デバッグ・デプロイ・コードレビューを一貫して支援する点も、チームでの開発に向いています。リポジトリはすぐに動かせる状態で公開されており、マルチエージェント構築の出発点として試す価値があります。