A2A とは

リモート上のエージェント同士がホストとの会話を通じて連携し、それぞれの“専門的な機能”を組み合わせてタスクを進める仕組みのことです。

前提として、ADK のベストプラクティスには「エージェントへ専門性を持たせる」という設計思想があります。
ホストはリモートエージェントのメタデータを読み取り、それぞれが持つ専門機能を判断した上で、ユーザの要望に沿うように処理を適切に分担させます。
※リモートエージェントのメタデータの詳細は、後述する「A2A の構成」へ記載します。

また、各コンポーネントは疎結合な設計となっており、使用したいリモートエージェントの増減は、ホストへのアドレスの追加・削除によって柔軟に行え、エージェントが異なる言語・バージョン・モデル（AI）の種類で作られていても、A2A を通じて組み合わせて利用することができます。

参考資料

◆公開リソース

Google が公開している A2A プロトコルの公式リポジトリ
https://github.com/a2aproject/a2a-samples

◆環境作成手順

環境作成の詳細は、こちらのブログ記事を参考にしました。
10分くらいでできるA2Aのはじめ方
※上記のブログ記事が作成された時期と、本記事を作成した時期（2025年12月）とでフォルダ構成が異なっております。
作業時のフォルダ構成に読み替えて環境作成を行ってください。

A2A は異なる専門性を持ったエージェント同士を連携させてタスクを行いたい場合に便利です。

似たような概念として「マルチエージェント」がありますが、こちらは１つの専門的タスクを実施したい場合に向いています。

A2A とマルチエージェントを組み合わせて１つのエージェントシステムを構築します。

例：

• ユーザが「総合窓口エージェント」へ問い合わせを行うと、独立したエージェントである「会計処理エージェント」「備品管理エージェント」に適切に連携し、タスクを実施します。（A2A による連携）
• 「会計処理エージェント」は会計処理用のサブエージェントである「仕分けエージェント」「確認エージェント」と連携し、「会計処理タスク」を実施します。（マルチエージェントによる連携）

◆メリット

• エージェントの拡張性
  A2A は拡張性に優れています。A2A プロトコルでエージェント間の連携を行うことで、標準化されたやり取りにより異なる言語や異なるフレームワークで構築されたエージェント間の連携をスムーズに行うことが出来ます。また各エージェントのエンドポイントで自由に追加、削除が出来るため、既存のエージェントシステムに別の専門性を持ったエージェントを簡単に追加することも出来ます。
• 将来性
  A2A は標準化されたエージェント間連携のためのプロトコルであるため、A2A に則ったエージェントを開発することで、今後の AI 環境への対応にもなります。開発したエージェントを自社の別システムや他社向けに展開したり、公開されているエージェントとの連携も可能です。また Gemini Enterprise などサービス上で Agent Engine にデプロイした A2A エージェントを追加することの出来る環境もあるため、今後ますます多様なエージェント連携が可能になると考えられます。

◆デメリット

• クライアントの通信
  A2A を利用したシステムでは各エージェントが独立しており、クライアント側はリモートエージェントと通信を行わなければタスク完了を確認することが出来ません。クライアントからタスクの完了を把握するため、参考とした A2A のデモで採用されているポーリングや SSE(Server-Sent Events)、プッシュ通知などを用いる必要があります。

サンプルコードから確認したアプリケーション構成

A2A を用いたアプリケーションは、大きく分けて UI、会話サーバ、エージェント管理の 3 つの要素に分けられます。
実際の業務で A2A を利用する場合は、Google が提供している公開リソースを土台として、必要に応じてカスタマイズするケースが多いと考えられます。

◆イメージ

本記事では構成の理解を深めるため、公式サンプルコード「demo\ui\main.py」を中心に処理内容を確認しました。

UI：mesop

画面の表示と描画を行います。
mesop とは Google が開発した「Python だけで Web UI を構築できるフレームワーク」です。
HTML や JavaScript を直接書かずに画面を作成できます。

A2A と mesop の相性が良い理由は次のとおりです。

• コードが Python のため統一しやすい
  A2A（エージェントロジック）も mesop（UI）も Pythonで書けるため、言語を跨がずに UI とバックエンドを自然に接続できます。
• UI の状態を自動で保持
  mesop は me.state() という仕組みで、画面上の情報を自動で記憶します。
  記憶する情報はユーザの入力、会話ログ、設定値、選択されているエージェント、などです。
  エージェントが返したデータも mesop の state に入れることで UI が記憶します。
• 状態に変化があると UI が自動で再描画
  mesop は差分レンダリングを持っているため、UI 状態が変わると自動的に必要な部分だけ描き直します。
  例：
  ・会話ログが増える
  ・タスク一覧が更新される
  ・入力内容が変わる
  ※ mesop は“変わった状態を画面に反映する”だけで、“更新の判定”は A2A／バックエンド側が行います。

▼mesop の詳細にご興味がある方は、こちらの公式ドキュメントもご参照ください。
Rapidly build AI apps in Python

会話サーバ：ConversationServer

UI とエージェントの中継役です。
mesop から受け取ったユーザ入力をもとに、適切なエージェントに処理を依頼し、結果を UI に返します。
サンプルコードでは ConversationServer クラスを使って制御を行っていました。

役割の詳細は以下です。

• UI（mesop）からの入力を受け取る
  mesop は、ユーザからの入力を会話 ID／ユーザ ID／入力テキストなどを含む JSON に変換し、ConversationServer に渡します。

• ホストエージェントを介して委譲先を決定
  ConversationServer は受け取った入力をもとに、ホストエージェントへ問い合わせを行い、登録済みのリモートエージェントのメタデータを取得します。
  取得した情報をもとに、どのリモートエージェントへ処理を委譲するかを決定します。

• リモートエージェントへ処理を依頼
  選択されたエージェントに、変換済みデータ（JSON）を送信し、返却されるイベントやレスポンスを受け取ります。

• 結果を mesop へ返し、UI に描画
  リモートエージェントの応答はホストエージェントおよび、ConversationServer 経由で mesop に渡され、最終的に UI に描画されます。

エージェント管理：ホストエージェント／リモートエージェント

• ホストエージェント
  複数のリモートエージェントを登録・管理し、ConversationServer からの問い合わせに対して利用可能なエージェントのメタデータを提供します。
  自身は業務ロジックをほとんど持たず、エージェント群の管理・仲介役として機能します。

• リモートエージェント
  ADK の知識がある方がイメージされる「エージェントを定義する部分」です。
  各エージェントのプロンプト、ツール、実行ロジックなどを持ち、実際のタスク処理を担当します。

リモートエージェントのメタデータ

ConversationServer が「どのリモートエージェントに処理を委譲するべきか」を判定するため、エージェントごとにメタデータが定義されています。

メタデータは以下の３つで構成されます。

• AgentCapabilities
  リモートエージェントの技術的機能を定義します。
  定義できる項目は以下です。
  • ストリーミング応答の可否
  • プッシュ通知のサポート可否
  • タスク状態の公開の可否
  • 拡張機能のサポートの可否
• AgentSkill
  エージェントが「どんな専門的スキルを提供するか」を定義します。
• AgentCard
  エージェントの外部公開情報（メタデータ）をまとめたものです。
  AgentCapabilities や AgentSkill もここに含まれます。

例：サンプルコード「Content Planner Agent」のメタデータ定義内容

A2A はエージェント間連携の拡張性に優れた技術です。本章ではA2Aを活かす上でのベストプラクティスと避けるべきワーストプラクティスについて説明します。

◆ベストプラクティス

• エージェントの独立性を保つ
  エージェントには１つの専門性を持たせ、独立して動作させる。
• A2A での連携を活用する
  Agent Card による能力把握など、A2A の機能を用いることで直接的な連携は避ける。

◆ワーストプラクティス

• ホストエージェントにサブエージェントを持たせる
  エージェントの自由な追加・削除が難しくなり、システムの柔軟性が低下します。
• リモートエージェントについてプロンプト内やコード内にハードコーディングする
  エージェントの削除や追加に伴って、プロンプトやコードの追加修正が発生します。
• エージェントの動作が別エージェントの構成や振る舞いを知っていることを前提に構成する
  １エージェントの変更が別エージェントに影響したり、障害が別エージェントに波及したりします。

上のプラクティスを意識し設計することで A2A の拡張性を活かした設計となり、エージェントの機能拡張や保守が楽になります。

今回の検証や検討を通して、A2Aに対して、いくつかのポイントを整理できました。

• A2A はエージェント同士の連携で、それぞれの専門機能を組み合わせてタスクを実行する仕組みを仲介するプロトコル。
• A2A を用いたアプリケーションは、UI、会話サーバ、エージェントの3つの主要な構成要素からなり、各要素が疎結合で連携します。
• 各エージェントは疎結合、AgentCardで連携するのがベストプラクティス。

A2A や、今回取り上げなかったMCP(Model Context Protocol)という技術は、今後ますます発展／拡張が期待されている分野です。

今後も、こうした注目技術に関する旬な情報をお届けしていきます。
最後までお読みいただき、ありがとうございました。