A2Aプロトコルとは何か？エージェントカードとタスクの解説

Agent2Agentプロトコルの略称であるA2Aプロトコルは、独立したAIエージェントシステム間の通信のためのオープン標準です。

この一文はシンプルに聞こえますが、大多数のAIエージェントデモが完全に省略していることを示唆しています。多くのデモでは、依然として1つのアシスタント、1つのランタイム、1つのツールループ、1つの所有者を前提としています。エージェントは検索を行い、ツールを呼び出し、コードを書き、APIをクエリし、MCPサーバーを使用し、最終的に回答を返すことができます。

A2Aは、エージェントが異なるチーム、フレームワーク、ベンダー、言語、または組織によって構築される世界のために設計されています。あるエージェントが別のエージェントを発見し、その機能を理解し、作業を依頼し、メッセージを交換し、ファイルや構造化された出力を受け取り、タスクの完了まで追跡する必要があると想定しています。これにより、単なるツール呼び出しフォーマットではなく、AIエージェントを対等な存在として相互運用可能にする真の試みとなっています。

主要な概念は以下の通りです：

• エージェントカード（Agent Cards）
• エージェントとクライアント
• タスク（Tasks）
• メッセージ（Messages）
• パーツ（Parts）
• アーティファクト（Artifacts）
• タスクの状態（Task states）
• ストリーミングと非同期アップデート

この記事では、これらの概念を平易なエンジニアリング用語で説明し、A2Aが実際のマルチエージェントシステムにおいてどのような位置づけにあるかを理解するのに十分な詳細を提供します。

簡潔な定義

A2Aは、エージェント間通信のためのプロトコルです。

これは、1つのエージェントまたはクライアントが共通のモデルを通じて別のエージェントと通信することを可能にします。受信側のエージェントは、その機能を記述し、作業を受け入れ、その作業のライフサイクルを管理し、追加の入力を求め、進行状況をストリーミングし、具体的な出力を返すことができます。

その目的は、エージェントが内部的にどう考えるかを標準化することではありません。エージェントが境界線でどのように会話するかを標準化することです。

A2Aエージェントは内部的に以下を使用するかもしれません：

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• カスタムコード
• MCPサーバー
• プライベートAPI
• ベクターデータベース
• ワークフローエンジン

呼び出し側（コールラー）はこれらを知る必要はありません。呼び出し側に必要なのは以下の情報です：

• このエージェントは何ができるか？
• どうやって会話すればよいか？
• どんな入力を受け付けるか？
• どんな出力を生成できるか？
• 作業をどう追跡するか？
• 結果をどう受け取るか？

この6つの質問が、独立して動作するエージェント間に確立しようとするA2Aのプロトコル境界を定義しています。

なぜA2Aが存在するのか

AIシステムは、単一のアシスタントから専門家のエージェントネットワークへと移行しつつあります。

企業は以下のようなエージェントを保有しているかもしれません：

• サポートエージェント
• 請求（Billing）エージェント
• 法的審査エージェント
• DevOpsエージェント
• データ分析エージェント
• 研究エージェント
• ドキュメント作成エージェント
• コードレビューエージェント

各エージェントには、独自のツール、権限、ドメイン知識、プロンプト、メモリ、検索システム、監査ルールがあるかもしれません。

共有プロトコルがない場合、すべての統合はカスタムなものになります。サポートエージェントは請求エージェントに特注の配線が必要になり、請求エージェントは法的エージェントに独自の接続が必要になり、研究エージェントはドキュメントエージェントにまた別の接続が必要になります。この組み合わせのオーバーヘッドは、エージェントネットワークが成長するにつれてうまくスケールしません。

A2Aは、これらのエージェントに相互作用のための共通の方法を提供し、N×Mの統合問題を単一の共有契約に削減します。その約束は魔法のような自律性ではなく、相互運用性です。

A2AはMCPではない

A2AはMCPと比較されることがよくありますが、それらは異なる問題を解決しています。

MCP（Model Context Protocol）は主に、AIアプリまたはエージェントをツール、リソース、プロンプトに接続することに関するものであり、A2Aは主にエージェントを他のエージェントに接続することに関するものです。

有用なメンタルモデルは以下の通りです：

MCP: エージェントからツールへ
A2A: エージェントからエージェントへ

例えば、エージェントはMCPを使用して以下にアクセスするかもしれません：

• GitHub
• ファイルシステム
• データベース
• Slack
• ドキュメント検索システム
• クラウドAPI

それらのMCPサーバーを構築するための実践的なガイドは、Go および Python 用にあります。

同じエージェントは、A2Aを使用して作業を以下に委任するかもしれません：

• セキュリティレビューエージェント
• 研究エージェント
• プランニングエージェント
• コンプライアンスエージェント
• コーディングエージェント

この2つのプロトコルは、共に取り組むことができ、実際によくそうします。クリーンなアーキテクチャはしばしば以下のようになります：

エージェントの境界の外側でA2A。
エージェントの境界の内側でMCP。

つまり、他のエージェントはA2Aを使用してあなたのエージェントと通信し、あなたのエージェントは内部的にMCPを使用してツールにアクセスします。これは、内部で何が変わっても外部インターフェースを安定させたままにする、懸念事項の明確な分離です。2つのプロトコルがアーキテクチャ上の責任をどのように分担し、実際に両者が必要となる時期の詳細な比較については、A2A vs MCP: AIエージェントは本当に両方のプロトコルを必要とするのか？ を参照してください。

A2Aにおけるコアな役割

A2Aは、機能を提供するエージェントと、それらを使用したいクライアントという2つの当事者围绕する単純な役割モデルを使用します。

クライアントは以下のいずれかかもしれません：

• 別のエージェント
• オルケストレーター（調整役）
• アシスタントアプリケーション
• ワークフローシステム
• ゲートウェイ
• テストハーネス
• 人間向けのアプリ

エージェントは以下のいずれかかもしれません：

• 専門のAIサービス
• ドメイン特化アシスタント
• ワークフローを所有するエージェント
• 外部ベンダーのエージェント
• 内部エンタープライズエージェント

重要なのは、エージェントが単なる関数ではないということです。エージェントはある機能を所有し、エージェントインターフェースを通じてそれを公開します。

エージェントカード（Agent Cards）

エージェントカードはA2Aにおける最も重要な概念の一つです。

エージェントカードはエージェントを記述します。それは、エージェントが何であり、何ができるか、どのように通信するか、どのような制約があるかをクライアントに伝える発見（ディスカバリー）ドキュメントです。

エージェントカードは以下の混合体と考えることができます：

• サービスメタデータ
• 機能宣言
• API発見ドキュメント
• エージェントプロフィール
• 契約の表面（Contract surface）

典型的なエージェントカードは、以下のようなものを記述することができます：

• エージェント名
• 説明
• サービスエンドポイント
• サポートされるプロトコル機能
• サポートされる入力および出力モード
• 利用可能なスキル
• 認証要件
• プロバイダー情報
• バージョン情報
• ドキュメントリンク
• オプションのメタデータ

エージェントカードは重要です。なぜなら、エージェントは他のすべてのエージェントについてハードコードされた知識を必要とすべきではないからです。

クライアントはカードを検査し、以下を決定することができます：

• これがその仕事に適したエージェントか？
• 必要なコンテンツタイプをサポートしているか？
• ストリーミングをサポートしているか？
• 認証が必要か？
• どのようなスキルを宣伝しているか？
• 必要な種類のアーティファクトを返すことができるか？

実践的なシステムでは、エージェントカードはエージェントレジストリ、開発者ポータル、および内部エージェントカタログの基盤となります。これは、統合にコミットする前に利用可能なものをクライアントが検索できるサービスディレクトリの機械可読版です。

エージェントカードは機能境界である

エージェントカードはマーケティングテキストとして扱うべきではありません。それは、他のシステムがランタイム時に依存する機能境界です。

エージェントカードがエージェントが金融分析を実行できると言っている場合、クライアントは金融分析の作業をそれに委任し始めるかもしれません。エージェントがファイルを受け付けると言っている場合、クライアントはファイルを送信するかもしれません。エージェントがストリーミングをサポートすると言っている場合、クライアントは進行イベントを期待するかもしれません。

悪いエージェントカードは悪いシステムを生みます。なぜなら、ルーティング決定と機能の仮定がエージェントネットワーク全体に波及するためです。有用なエージェントカードは以下であるべきです：

• 具体的である
• 正確である
• 安定している
• バージョン管理されている
• セキュリティを意識している
• 制限事項について正直である

「ビジネスタスクを行う」といった曖昧なスキルは有用ではありません。

より良いスキルは以下のようなものです：

SaaS請求データ进行分析し、月次支出サマリーを生成する。

さらに良いのは、期待される入力と出力モードを含めることです。

入力: CSVまたはJSONの請求レコード。
出力: Markdownサマリーおよび構造化されたJSON合計。

エージェントカードが正確であればあるほど、他のエージェントがタスクを正しくルーティングしやすくなります。

エージェントの発見（Agent Discovery）

エージェントの発見は、エージェントカードを見つけるプロセスです。

シンプルなデプロイメントでは、発見は静的かもしれません。クライアントは特定のエージェントのURLをすでに知っています。

大規模なデプロイメントでは、発見には以下を含む可能性があります：

• レジストリ
• 開発者ポータル
• 内部カタログ
• DNSベースの発見
• 構成管理
• 環境固有のルーティング
• テナント対応ゲートウェイ

重要な設計上の選択は、発見が公開されるか、プライベートか、または認可済み（permissioned）かということです。

すべてのエージェントが全員によって発見可能であるべきではありません。内部給与計算エージェントは同じエージェントカードをすべての呼び出し側に公開すべきではなく、パートナーエージェントはパートナーに安全なスキルのみを表示するかもしれません。エージェントの発見は単なる便利機能ではありません。それはあなたのセキュリティおよびガバナンスモデルの一部であり、可視性のスコーピングは第一級の設計決定です。

タスク（Tasks）

タスクは、エージェントによって実行されている作業を表します。

ここがA2Aが単純なリクエストとレスポンスAPIよりも興味深いところになります。

いくつかのエージェント相互作用は迅速です。クライアントがメッセージを送信し、エージェントが直接のレスポンスを返します。

しかし、多くの実用的なエージェントワークフローは即時ではありません。

タスクは以下を含むかもしれません：

• 複数のソースの検索
• 明確化の要求
• ツールの呼び出し
• 作業の委任
• 承認の待機
• レポートの生成
• ファイルの生成
• 進行状況のストリーミング
• リトライの処理
• 複数のアーティファクトの返却

A2Aは、この種の作業をタスクとしてモデル化します。作業にアイデンティティとライフサイクルを与えることで、長時間実行されるエージェント作業を追跡、検査、および潜在的にキャンセルまたはリトライする必要があるため、これが重要となります。

タスクのライフサイクル

タスクは異なる状態を通過することができます。

正確な状態モデルはプロトコルバージョンおよび実装に依存しますが、基本的な考えは単純です：

• 送信済み（submitted）
• 作業中（working）
• 入力が必要（input required）
• 完了（completed）
• 失敗（failed）
• キャンセル済み（canceled）
• 拒否（rejected）

重要な点は、タスクが単なるレスポンスペイロードではないということです。それは、クライアントがいつでもクエリできる独自の状態を持つ進行中の作業単位です。クライアントはタスク状態を使用して、何が起こっているかを理解することができます：

• エージェントはタスクを受け入れましたか？
• まだ作業中ですか？
• 追加の入力が必要ですか？
• 正常に完了しましたか？
• 失敗しましたか？
• キャンセルされましたか？
• アーティファクトは利用可能ですか？

これは、秒、分、またはそれ以上かかるワークフローにとって特に有用です。

例えば、研究エージェントはタスクをすぐに返し、バックグラウンドで作業を続けながら進行状況イベントをストリーミングするか、後で結果を利用可能にすることができます。

ステートレスなメッセージまたはステートフルなタスク

A2Aは単純な相互作用と複雑な相互作用の両方をサポートします。

単純な相互作用の場合、エージェントは直接のメッセージを返すかもしれません。複雑な相互作用の場合、タスクを返すかもしれません。この区別は重要です。なぜなら、すべてのものがタスク追跡を必要とするわけではなく、短い相互作用を完全なタスクワークフローにオーバエンジニアリングすると不要なオーバーヘッドが生じるからです。

クライアントが以下を尋ねた場合：

この1段落を要約してください。

直接のレスポンスで十分かもしれません。

クライアントが以下を尋ねた場合：

トップ5のオープンソースベクターデータベースを調査し、それらを比較し、移行推奨事項を作成してください。

タスクの方が適切です。

実践的なルールは単純です。単純で即時的な相互作用には直接メッセージを使用し、長時間実行される、ステートフルな、監査可能な、またはアーティファクトを生成する作業にはタスクを使用します。

メッセージ（Messages）

メッセージは、クライアントとエージェント間で交換される通信単位です。

メッセージは1つ以上のパートを含むことができます。

メッセージは以下を表すかもしれません：

• ユーザーリクエスト
• エージェントレスポンス
• 明確化のための質問
• 追加の入力
• タスク関連の通信
• 進行状況のコンテキスト
• 構造化された指示

メッセージは単なる文字列ではありません。エージェント通信は多くの場合、プレーンテキストよりもはるかに多くの情報を運ぶ必要があり、メッセージ構造はそのことを考慮して設計されています。

メッセージは以下を含み得ます：

• テキスト
• ファイル
• 構造化されたJSON
• 画像
• 参照
• メタデータ

メッセージは封筒であり、パートはそれの中にある実際の型付けされたコンテンツです。

パーツ（Parts）

パートは、メッセージまたはアーティファクト内のコンテンツの断片です。

これは、A2Aがマルチモーダルおよび構造化された通信をサポートする方法です。

パートは以下の異なるコンテンツタイプを含み得ます：

• テキスト
• ファイルデータ
• 構造化されたデータ
• 参照によるバイナリコンテンツ
• JSONのようなデータ

パートは以下のメタデータも含み得ます：

• メディアタイプ
• ファイル名
• 追加のコンテキスト

メディアタイプは、受信エージェントがコンテンツをどのように解釈するかを伝えるため、重要です。

例えば：

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

これはA2Aの過小評価されている部分の一つです。エージェント通信はすべてをプレーンテキストに押し付けるべきではありません。ダウンストリームエージェントにスプレッドシート、画像、JSONペイロード、ログファイル、またはPDFが必要であれば、プロトコルはそのコンテンツを段落に変換するのではなく、コンテンツとして保持すべきです。良いエージェントシステムは、各パートがその自然なメディアタイプをコンシューマーまでそのまま運ぶことで、これらの不要なテキストボトルネックを回避します。

アーティファクト（Artifacts）

アーティファクトは、エージェントがタスク処理中に生成する具体的な出力です。

これは一般的なメッセージとは異なります。メッセージはエージェント間の通信ですが、アーティファクトはタスクが生成した具体的な成果物です。

アーティファクトの例には以下が含まれます：

• Markdownレポート
• JSON分析結果
• CSVエクスポート
• 生成された画像
• PDFドキュメント
• コードパッチ
• テスト結果ファイル
• デプロイメントプラン
• 図
• データ抽出

この区別は実践的に有用です。研究エージェントが「答えを見つけました」と言う場合、それはメッセージです。market-analysis.md、sources.json、および risk-summary.csv を返す場合、それらはアーティファクトです。タスクの作業を検査可能、再利用可能、および合成可能にする具体的な出力です。1つのエージェントのアーティファクトは、構造の損失なしに別のエージェントの入力となります。

メッセージとアーティファクト

それを考える簡単な方法：

メッセージは会話です。
アーティファクトは出力です。

メッセージはエージェントの調整を助け、アーティファクトはタスクが実際に生成したものです。

例えば、ソフトウェア開発ワークフローでは：

• クライアントはバグ修正を依頼するメッセージを送信します。
• コーディングエージェントは明確化のための質問を含むメッセージを送信します。
• コーディングエージェントはタスクに取り組みます。
• エージェントはパッチファイル、テスト出力、および説明などのアーティファクトを返します。

この分離は有用です。なぜなら、タスクの調整と成果物を混同するのを避け、ログの記録、監査、および出力をダウンストリームコンシューマーに渡すことがはるかに容易になるからです。

実践的な例

プライマリーアシスタントがドキュメントエージェントの助けを必要としていると想像してください。

ユーザーは以下を尋ねます：

新しい請求Webhook APIの開発者ドキュメントを作成してください。

プライマリーアシスタントはエージェントレジストリをチェックし、ドキュメントエージェントを見つけます。

ドキュメントエージェントには、以下ができることを示すエージェントカードがあります：

• APIドキュメントの作成
• OpenAPI仕様の受け付け
• Markdownスタイルガイドの受け付け
• Markdownドキュメントの生成
• PythonおよびJavaScriptでの例の生成
• 長時間実行タスクのサポート
• アーティファクトの返却

プライマリーアシスタントは以下を含むメッセージを送信します：

• 短い指示
• OpenAPIファイル
• スタイルガイド
• 対象読者に関するメタデータ

ドキュメントエージェントはタスクを作成します。

タスクは作業中状態に入ります。

ドキュメントエージェントは以下のようなメッセージを送信するかもしれません：

エンドポイントの説明を抽出しています。

そして：

認証の例について明確化が必要です。

プライマリーアシスタントは不足している入力を提供します。

タスクは続行されます。

最後に、ドキュメントエージェントはアーティファクトを返します：

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

これがA2Aモデルの実践です。「この関数を呼び出す」だけでなく、「このタスクを別のエージェントに委任し、必要に応じて通信し、完了まで結果を追跡する」ことです。

なぜタスクが実際のシステムにとって重要なのか

タスクは、A2Aを本格的なワークフローに適したものにするものです。

通常のHTTP API呼び出しは、エージェント作業にはしばしば薄すぎます。エージェントタスクは、不確実性、複数のステップ、中間結果、およびフォローアップの質問を含む可能性があります。

タスクは以下を添付する場所を提供します：

• 状態
• 履歴
• メッセージ
• アーティファクト
• エラー
• メタデータ
• 進行状況
• キャンセル
• 監査情報

これは以下に有用です：

• 研究ワークフロー
• コード生成
• データ分析
• コンプライアンスレビュー
• ドキュメント作成
• インシデント調査
• マルチステッププランニング
• 人間の承認ワークフロー

タスクモデルなしでは、開発者は通常、カスタムジョブID、キュー、ステータスエンドポイント、およびWebhookコールバックを使用してこのロジックを再構築します。A2Aは、そのパターンを標準化し、新しいエージェント統合ごとに再発明する必要がないように試みます。

ストリーミングと非同期作業

A2Aは、エージェント作業がストリーミングまたは非同期であるという考えをサポートします。

ストリーミングは、クライアントがライブアップデートを望む場合に有用です。

例えば：

• 進行状況イベント
• 部分的な結果
• 中間ステータス
• 生成されたテキスト
• ステップアップデート

非同期ワークフローは、タスクに時間がかかる場合、またはクライアントが開いている接続を保持できない場合に有用です。

例えば：

• バックグラウンド研究
• 大規模なドキュメント生成
• マルチエージェントレビュー
• データ処理
• 人間の承認
• バッチ分析

実践的には、堅牢なA2Aシステムは以下の3つのモードを中心に設計されるべきです。単純な作業には即座のレスポンス、インタラクティブな長時間実行作業にはストリーミング、および単一の接続を超えて存続する可能性のある耐久性のあるバックグラウンド作業には非同期。SSE、プッシュWebhook、再購読、input required 経由のHITL（Human-in-the-Loop）、障害処理、および本番チェックリストについては、A2Aストリーミングと長時間実行エージェントワークフローのための非同期タスク を参照してください。

エージェントカードとストリーミングサポート

エージェントカードは、エージェントがストリーミングをサポートするかどうかを宣伝することができます。

これは重要です。なぜなら、クライアントはすべてのエージェントがストリーミングをサポートすると仮定できないからです。いくつかのエージェントは単純なリクエストとレスポンスのみをサポートし、いくつかはタスクポーリングをサポートし、他はプッシュ通知またはサーバー送信イベント（SSE）をサポートするかもしれません。良いクライアントは、相互作用パターンを選択する前にエージェントカードを検査します。これが、エージェントカードが単なるドキュメントではない理由です。それらは直接ランタイム動作を形成します。

A2Aとマルチモーダルエージェント

A2Aは、プレーンテキストよりも多くのものをサポートするように設計されています。

これは重要です。なぜなら、実用的なエージェントシステムはますます混合された入力と出力を処理しているからです：

• テキスト
• 画像
• オーディオ
• ビデオ
• PDF
• スプレッドシート
• 構造化されたJSON
• ログ
• コード
• 図

すべてのエージェント境界がすべてをテキストに変換する場合、重要な情報が失われる可能性があります。

例えば、視覚的なトラブルシューティングエージェントは、弱いテキスト説明ではなく、画像を画像として受信すべきです。金融エージェントは、コピーされた段落ではなく、構造化されたスプレッドシートデータを接收すべきです。コードレビューエージェントは、曖昧な要約ではなく、ソースファイルまたは差分を接收すべきです。

パートとメディアタイプは、A2Aがエージェント境界を超えて豊かなコンテンツを保持する方法です。これは、プロトコルが最初に思われるよりも重要な場所の一つです。なぜなら、境界での情報損失はマルチエージェントチェーンのすべてのホップで累積するためです。

A2Aはエージェントフレームワークではない

A2Aは、エージェントを構築する方法を教えていません。

A2Aは以下を定義しません：

• 推論戦略
• プランニングアルゴリズム
• メモリシステム
• ベクターデータベース
• プロンプトテンプレート
• モデルプロバイダー
• ツールフレームワーク
• オルケストレーションランタイム
• 評価方法

それはバグではなく、機能です。A2Aは、異なるエージェント実装が同じ内部アーキテクチャを共有する必要なく通信できるようにする境界プロトコルです。HTTPがどのようにWebアプリケーションを構築するかを教えていないのと同じように、システムがどのように通信するかのみを定義します。A2Aも同様に理解されるべきです。

A2AはAPIの代替ではない

A2Aはまた、すべてのAPIを代替するものではありません。

安定したリクエストとレスポンス契約を持つ決定論的なサービスがある場合、通常のAPIの方が良いかもしれません。

例えば：

• 通貨変換
• アドレス検証
• 請求書検索
• 画像のリサイズ
• 検索エンドポイント
• 機能フラグ検索
• 内部CRUDサービス

これらは、AIシステムによって呼び出されるからといって、自動的にエージェントになるわけではありません。A2Aは、リモートシステムが実際にエージェントのように動作する場合に意味を成します：

• タスクを所有している
• 追加の入力を求める可能性がある
• 内部的にツールを使用する可能性がある
• 時間がかかる可能性がある
• アーティファクトを生成する可能性がある
• 発見する価値のある機能を持っている
• 更大なワークフロー内の対等者として動作できる

A2Aは、それが流行っているからという理由だけで使用しないでください。抽象化が実際に問題に適合する場合にのみ使用してください。

A2AがAIシステムアーキテクチャに fitting する場所

A2Aは、独立してデプロイ可能なエージェント間の境界で最もよく fitting します。

有用なアーキテクチャは以下のように見えるかもしれません：

ユーザー
  |
  v
プライマリーアシスタント
  |
  |-- A2A --> 研究エージェント
  |-- A2A --> コーディングエージェント
  |-- A2A --> コンプライアンスエージェント
  |-- A2A --> ドキュメントエージェント

各専門エージェントは内部的にツールを使用するかもしれません：

研究エージェント
  |
  |-- MCP --> Web検索
  |-- MCP --> ドキュメントストア
  |-- MCP --> ベクターデータベース

これにより、以下の別々のレイヤーが得られます：

ユーザーインターフェースレイヤー
エージェント調整レイヤー
ツール統合レイヤー
データおよび実行レイヤー

A2Aはエージェント調整レイヤーに存在し、MCPはしばしばツール統合レイヤーに存在し、通常のAPI、キュー、データベース、およびストレージシステムはそれらより下に存在します。各レイヤーは独自の抽象化と独自の障害モードを持っています。LLM推論、メモリ、ルーティング、ツール、および可観測性が本番アシスタント内でどのように組み合わされるのかの横断的なマップについては、AIアシスタントアーキテクチャ: LLM、メモリ、ツール、ルーティング、可観測性 を参照してください。

アーキテクチャパターン: オルケストレーターと専門家

最も一般的なA2Aパターンは、おそらくオルケストレーターと専門家です。

このパターンでは、1つのプライマリーエージェントがユーザーリクエストを受け取り、作業の一部を専門エージェントに委任します。

例：

プライマリーアシスタント
  |
  |-- A2A --> 法的エージェント
  |-- A2A --> 金融エージェント
  |-- A2A --> 研究エージェント
  |-- A2A --> 執筆エージェント

このパターンは理解しやすいです。オルケストレーターが全体のワークフローを所有し、専門エージェントがドメイン固有の作業を所有します。欠点は、オルケストレーターがボトルネックになり得ること、および効果的に委任するには堅牢なルーティング戦略が必要であることです。基礎となるモデル選択およびオーケストレーションのトレードオフは、マルチモデルシステム設計: 1つのモデルでは不十分な場合 でカバーされています。それでも、大多数のチームにとって、これはより複雑なトポロジーを探索する前に到達するべき最初のマルチエージェントアーキテクチャです。

アーキテクチャパターン: ピアエージェント

ピアツーピアパターンでは、エージェントは互いにより直接に通信することができます。

例えば：

研究エージェント --> データエージェント --> チャーティングエージェント --> 執筆エージェント

これは強力ですが、制御するのは困難です。

以下のための強いルールが必要です：

• 誰が誰を呼び出せるか
• どのようなコンテキストが共有できるか
• ループをどのように防止するか
• 最終出力を誰が所有するか
• コストをどのように制御するか
• 委任をどのように監査するか

ピアエージェントネットワークはエレガントに聞こえますが、すぐに混沌と化する可能性があります。グラフのすべてのエッジに対する強いガバナンスルールおよび明確な所有権がある場合にのみ使用してください。

アーキテクチャパターン: A2Aゲートウェイ

より本番に優しいパターンはA2Aゲートウェイです。

各エージェントが直接他のエージェントを呼び出すのではなく、トラフィックはゲートウェイを通過します。

ゲートウェイは以下を処理できます：

• 認証
• 認可
• ルーティング
• テナントマッピング
• ロギング
• レート制限
• ポリシーチェック
• プロトコルバージョン処理
• 可観測性
• 監査証跡

これは、ゲートウェイがエージェント通信の制御プレーンとなり、各エージェントで再実装するのではなく1つの場所でポリシーを強制するエンタープライズ環境において特に有用です。小さなシステムでは過剰かもしれませんが、複数のチームとベンダーを持つ大規模なシステムでは、予想されるより早く必要になることがよくあります。

セキュリティの考慮事項

A2Aのセキュリティは真剣な注意が必要です。

エージェント間通信は、機微なコンテキストを境界を超えて移動させる可能性があります。また、独自のツールと権限を持つシステムに作業を委任する可能性があります。

コアなセキュリティの質問は以下の通りです：

• どのエージェントがこのエージェントを発見することを許可されているか？
• どのエージェントがタスクを送信することを許可されているか？
• どのような認証が必要か？
• 呼び出し側にどのような権限が付随しているか？
• 1つのエージェントがユーザー権限を別のエージェントに委任できるか？
• メッセージにどのようなデータを含めることができるか？
• どのようなアーティファクトを返すことができるか？
• タスクはどのように監査されるか？
• 受信エージェントはツールまたは他のエージェントを呼び出せるか？
• シークレットはどのように保護されるか？

エージェントカードには静的なシークレットを含めるべきではなく、機微なエージェントカードは公開されるのではなく、認証の背後で保護されるべきです。異なるクライアントは同じエージェントの異なるビューを必要とします。内部呼び出し側は外部パートナーよりも多くのスキルを見えるかもしれませんが、公開クライアントは安全な機能の限られたセットのみを表示するかもしれません。

セキュリティはエージェントネットワークが構築された後に追加されるべきではありません。それは最初からネットワークを形成すべきです。なぜなら、ライブエージェントトポロジー全体に認証と権限境界を後から組み込むことは、それらを設計に組み込むよりもはるかに困難だからです。脅威モデル、アイデンティティレイヤー、ゲートウェイ制御プレーン、委任スコープ、および監査証跡の完全な解説については、A2AおよびMCPエージェントセキュリティ: アイデンティティ、委任、および監査証跡 を参照してください。

可観測性の考慮事項

A2Aシステムは強い可観測性を必要とします。

タスクがエージェント境界を横断する場合、デバッグははるかに困難になります。なぜなら、単一のシステムが完全な画像を保持していないからです。以下を知る必要があります：

• どのエージェントがタスクを作成したか
• どのエージェントがそれを受け入れたか
• どのようなメッセージが交換されたか
• どのような状態変化が発生したか
• どのようなアーティファクトが生成されたか
• どのようなエラーが発生したか
• 各ステップにどれほど時間がかかったか
• 内部的にどのようなツールが使用されたか
• 別のエージェントが呼び出されたか
• 誰がリスクのあるアクションを承認したか

有用なトレースは、作業を完全なチェーンに沿って追跡すべきです。

例えば：

ユーザーリクエスト
  -> プライマリーアシスタントタスク
  -> 研究エージェントタスク
  -> ドキュメント検索ツール呼び出し
  -> 要約アーティファクト
  -> 最終レスポンス

エンドツーエンドのトレースなしでは、マルチエージェントシステムは本番環境で信頼するのが非常に困難になります。システムが特定の出力を生成した理由を確信を持って答えることができず、それがどこで間違えたかを特定することはさらに困難です。LLMシステムの可観測性: メトリクス、トレース、ログ、および本番環境でのテスト は、この問題の計装およびツール側を詳細にカバーしています。

一般的な間違い

間違い1: すべてのツールをエージェントと呼ぶ

すべてのツールがエージェントであるわけではありません。

電卓はツールです。ファイルリーダーはツールです。データベースクエリエンドポイントはツールです。

タスクを所有せず、入力を求めず、アーティファクトを生成せず、独立した対等者として動作しない場合、それはおそらくA2Aを必要としません。

間違い2: エージェントカードを曖昧にする

エージェントカードは以下を言うべきではありません：

このエージェントはビジネスタスクを支援します。

それは、作業をインテリジェントにルーティングしようとするエージェントにとって無意味です。良いカードは、エージェントが実際に何をするか、何を受理するか、何を返すか、およびどのような制約が適用されるかを言うべきです。

間違い3: タスク状態を無視する

A2Aを使用しながら、すべての相互作用をリクエストとレスポンスとして扱う場合、あなたは価値の大部分を見逃しています。

タスクモデルは、通常のAPIではなくA2Aを使用する主な理由の一つです。それをスキップすることは、すべての統合で同じライフサイクル追跡ロジックを再構築することを意味します。

間違い4: すべてをテキストとして返す

A2Aは構造化およびマルチモーダルコンテンツをサポートしています。それを使用してください。

出力がレポートである場合、レポートアーティファクトを返してください。

出力がJSONである場合、構造化されたデータを返してください。

出力がファイルである場合、ファイルを返してください。

プレーンテキストが正しい出力である場合を除き、すべてを平坦にしないでください。

間違い5: 権限モデルがない

権限境界のないエージェントネットワークは危険です。

すべてのエージェントがすべての種類のデータを使用して他のすべてのエージェントを呼び出すことを許可されるべきではありません。エージェントネットワーク全体で最小権限の原則を強制するために、認証、認可、および監査証跡を使用してください。

いつA2Aを使用すべきか？

実際のエージェント境界がある場合にA2Aを使用してください。

良い理由は以下を含みます：

• エージェントは異なるチームによって所有されている
• エージェントは別々のサービスとしてデプロイされている
• エージェントは異なるフレームワークで構築されている
• エージェントは互いを見つけ合う必要がある
• エージェントはタスクを委任する必要がある
• タスクは長時間実行される可能性がある
• 結果はアーティファクトを含む可能性がある
• クライアントは内部ツールを知る必要がない
• エージェント機能メタデータが重要である

弱い理由は以下を含みます：

• 現代に聞こえる
• 1つの関数を呼び出したい
• 単一エージェントアプリを持っている
• 通常のAPIで機能する
• MCPがすでにツール統合問題を解決している

A2Aは、システムが実際にマルチエージェントである場合に強力です。システムがそうではない場合、それは不要な儀式であり、その儀式のコスト — 追加された概念、インフラストラクチャ、デバッグ表面、およびセキュリティ要件 — は現実的なものです。

最小のメンタルモデル

1つのものだけを覚えるなら、これを覚えてください：

エージェントカード: エージェントが何ができるか。
メッセージ: エージェントが互いに何を言うか。
パート: メッセージまたはアーティファクト内の型付けされたコンテンツ。
タスク: エージェントが所有する作業。
アーティファクト: タスクが生成した出力。

これがA2Aのコアです。残りは、主にこれらの5つの概念を実際の本番システムで使用するために、信頼性が高く、可観測可能で、十分に安全にすることに関するものです。

最終的な思考

A2Aは単なるAI略語ではありません。それは、孤立したアシスタントから相互運用可能なエージェントシステムへのより大きなシフトの一部です。そのシフトはすべての場所で一度に起こるわけではなく、多くのアプリケーションは、MCPおよび通常のAPIが完全に十分である、良いツールアクセスを持つ単一エージェントシステムのままです。

しかし、エージェントが別々にデプロイされた対等者になる場合、より強い境界を必要とします。発見、タスク所有、テキスト以上のものを運ぶメッセージ、アーティファクトを第一級の出力として、およびエージェント境界をまたぐセキュリティ、状態、および可観測性。A2Aが占めようとしている空間はこれであり、それはMCPが解決するツール統合の問題とは真に異なる問題です。

2026年におけるA2Aの実際の生産的な牽引力 — 採用ティア、セキュリティ懸念、エンタープライズユースケース、および意思決定フレームワークを含む — に関する実践的な視点については、2026年のGoogle A2Aプロトコル: 採用、過熱、および現実 を参照してください。

私の意見：小さなプロジェクトでA2Aから始めないでください。有用なエージェント、良いツール、および明確なアーキテクチャから始めてください。AIシステムクラスター は、より広い文脈が欲しい場合、セルフホストされたアシスタント、MCPサーバー、およびエージェントメモリを接続されたセットとしてカバーしています。しかし、「ツール」が独自のタスクライフサイクルを持つ別の自律的な専門家のように見え始めたら、それはもはや単なるツールではないかもしれません。その時がA2Aが興味深くなる時です。

ソース

• A2Aプロトコル仕様: https://a2a-protocol.org/latest/specification/
• A2Aの主要な概念: https://a2a-protocol.org/latest/topics/key-concepts/
• A2Aのタスクのライフ: https://a2a-protocol.org/latest/topics/life-of-a-task/
• A2Aエージェント発見: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2Aストリーミングおよび非同期操作: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2AおよびMCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/