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

A2Aプロトコル（Agent2Agent Protocolの略）は、独立したAIエージェントシステム間の通信のためのオープンな規格です。

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

A2Aは異なる世界のために設計されています。エージェントは異なるチーム、フレームワーク、ベンダー、言語、または組織によって構築される可能性があります。1つのエージェントが別のエージェントを発見し、そのエージェントが何ができるかを理解し、作業を依頼し、メッセージを交換し、ファイルや構造化された出力を受け取り、タスクの完了まで追跡する必要があると仮定します。これにより、単なるツール呼び出しフォーマットではなく、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システムは、単一のアシスタントから、専門化されたエージェントのネットワークへと移行しつつあります。

企業には以下のようなエージェントが存在する可能性があります。

• サポートエージェント
• 請求処理エージェント
• 法的審査エージェント
• 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: Do AI Agents Really Need Both Protocols? を参照してください。

A2Aにおける主要な役割

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

クライアントは以下である可能性があります。

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

エージェントは以下である可能性があります。

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

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

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

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

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

エージェントカードは以下のようなものの組み合わせと考えることができます。

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

典型的なエージェントカードは以下のようなものを記述できます。

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

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

クライアントはカードを検査し、以下を決定できます。

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

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

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

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

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

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

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

「業務タスクを行います」といった曖昧なスキルは役に立ちません。

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

SaaS請求データ进行分析并生成月度支出摘要。
(注：原文为英文，此处翻译为日文语境下的描述)
SaaS請求データ进行分析し、月次支出サマリーを生成します。

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

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

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

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

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

シンプルなデプロイメントでは、発見は静的である可能性があります。クライアントは特定のエージェントのURLをすでに知っています。

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

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

重要な設計選択は、発見が公開、プライベート、または認可済みであるかどうかです。

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

タスク（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つのモード围绕して設計されるべきです。単純な作業のための即時的なレスポンス、インタラクティブな長時間実行作業のためのストリーミング、および単一の接続よりも長生きする可能性のある耐久性のあるバックグラウンド作業のための非同期。

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

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

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

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

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

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

• テキスト
• 画像
• 音声
• 動画
• PDF
• スプレッドシート
• 構造化されたJSON
• ログ
• コード
• ダイアグラム

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

例えば、視覚的なトラブルシューティングエージェントは、弱ったテキスト説明ではなく、画像を画像として受け取るべきです。財務エージェントは、コピーされた段落ではなく、構造化されたスプレッドシートデータを受け取るべきです。コードレビューエージェントは、曖昧なサマリーではなく、ソースファイルまたは差分を受け取るべきです。

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

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

A2Aは、エージェントを構築する方法を指示しません。

以下を定義しません。

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

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

A2AはAPIの代替ではない

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

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

例えば：

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

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

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

A2Aは、それが流行っているからといって使用すべきではありません。抽象化が実際に問題に適合する場合に使用してください。

AIシステムアーキテクチャにおけるA2Aの位置づけ

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

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

ユーザー
  |
  v
プライマリアシスタント
  |
  |-- A2A --> 調査エージェント
  |-- A2A --> コーディングエージェント
  |-- A2A --> 準拠確認エージェント
  |-- A2A --> ドキュメントエージェント

各専門エージェントは内部的にツールを使用する可能性があります。

調査エージェント
  |
  |-- MCP --> ウェブ検索
  |-- MCP --> ドキュメントストア
  |-- MCP --> ベクターデータベース

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

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

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

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

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

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

例：

プライマリアシスタント
  |
  |-- A2A --> 法的エージェント
  |-- A2A --> 財務エージェント
  |-- A2A --> 調査エージェント
  |-- A2A --> 書き込みエージェント

このパターンは理解しやすいです。オーケストレーターは全体的なワークフローを所有し、専門エージェントはドメイン固有の作業を所有します。欠点は、オーケストレーターがボトルネックになる可能性があり、効果的に委任するための堅牢なルーティング戦略が必要であることです。基礎となるモデル選択とオーケストレーションのトレードオフは、Multi-Model System Design: When One Model Isn’t Enough でカバーされています。それでも、ほとんどのチームにとって、これはより複雑なトポロジーを探索する前に到達すべき最初のマルチエージェントアーキテクチャです。

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

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

例えば：

調査エージェント --> データエージェント --> チャーティングエージェント --> 書き込みエージェント

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

以下のための強力なルールが必要です。

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

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

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

より生産的なパターンはA2Aゲートウェイです。

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

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

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

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

セキュリティ上の考慮事項

A2Aセキュリティは真剣な注意を払うべきです。

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

コアセキュリティの質問は以下です。

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

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

セキュリティは、エージェントネットワークが構築された後に追加されるべきではありません。それは最初からネットワークを形成するべきです。ライブエージェントトポロジー全体に認証と権限境界を後から取り付け直すことは、それらを最初から設計するよりもはるかに困難だからです。

可観測性に関する考慮事項

A2Aシステムは強力な可観測性が必要です。

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

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

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

例えば：

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

エンドツーエンドのトレースなしでは、マルチエージェントシステムは生産環境で信頼するのが非常に困難になります。システムが特定の出力を生成した理由を自信を持って答えられず、それがどこで間違えたかを特定することはできません。Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production は、この問題の計装およびツール側を深くカバーしています。

一般的なミステイク

ミステイク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の実際の生産的な牽引力—採用ティア、セキュリティ懸念、エンタープライズユースケース、および意思決定フレームワークを含む—の実用的な捉え方については、Google A2A Protocol in 2026: Adoption, Hype, and Reality を参照してください。

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

ソース

• A2A Protocol Specification: https://a2a-protocol.org/latest/specification/
• A2A Key Concepts: https://a2a-protocol.org/latest/topics/key-concepts/
• A2A Life of a Task: https://a2a-protocol.org/latest/topics/life-of-a-task/
• A2A Agent Discovery: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A Streaming and Async Operations: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A and MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/