Agent2Agent（A2A）は、異なる環境で動くAIエージェント同士が、能力を確認し、仕事を依頼して、進行状況や成果物を受け渡すためのプロトコルです。単に文章を送り合う仕組みではなく、誰に何を頼めるか、依頼がどの状態にあるか、結果をどのような形で返すかを共通化します。
この記事では、A2Aが必要とされる理由から、基本要素、MCPとの役割分担、導入時に確認したい点までを順に説明します。AIエージェント自体の基礎を先に確認したい場合は、AIエージェントの仕組みと安全な運用も参考になります。
A2Aが共通化するもの
Googleは2025年4月、異なるベンダーや開発基盤で作られたAIエージェントの相互運用を目的としてA2Aを発表しました。ここでいう相互運用とは、内部のモデルや実装が異なっていても、共通の手順で相手の能力を確認し、依頼と結果を交換できることです。
A2Aは、異なるAIモデルそのものを同じものに変える仕組みではありません。各エージェントの内部構造を相手に公開することも前提にせず、エージェントを一つのサービスとして扱い、その外側のやり取りをそろえます。
A2Aの基本要素
A2Aの流れを理解するには、次の四つの要素を押さえると整理しやすくなります。
| 要素 | 役割 | 平易な言い換え |
|---|---|---|
| Agent Card | エージェントの能力、接続先、対応形式、認証要件などを示す | エージェントの案内票 |
| Message | 依頼、回答、追加情報など、一回のやり取りを表す | 会話の一通 |
| Task | 状態を持つ仕事の単位として、進行中、完了、失敗などを追跡する | 受付番号が付いた仕事 |
| Artifact | 文書、ファイル、構造化データなど、仕事の結果を表す | 納品物 |
たとえば、顧客対応エージェントが請求処理を担当できるエージェントを探す場面を考えます。依頼側はAgent Cardで相手の能力と接続条件を確認し、Messageで問い合わせを送ります。時間がかかる処理ならTaskとして状態を追跡し、完了後に回答文や明細データをArtifactとして受け取ります。
短い処理には即時の応答を使い、時間がかかる処理には状態確認、ストリーミング、通知などを使い分けられます。ただし、どの方式に対応するかはエージェントの実装と公開された能力によって異なります。
A2Aが解きほぐす連携上の課題
従来の個別連携では、相手の機能を見つける方法、依頼の形式、進行状態、成果物の形式を組み合わせごとに決める必要がありました。連携先が増えるほど、接続部分の設計と保守も増えます。
A2Aは、この接続部分に共通の考え方を持ち込みます。
- 能力の確認：依頼前に、相手が何をできるか、どの形式を扱えるかを確認する。
- 仕事の委任：単発の応答だけでなく、状態を持つ仕事として依頼する。
- 進行状況の共有：処理中、入力待ち、完了、失敗などを区別して扱う。
- 成果物の受け渡し：文章だけでなく、ファイルや構造化データも結果として扱う。
共通仕様があることで接続方法をそろえやすくなりますが、すべてのエージェントが無条件に連携できるわけではありません。対応する仕様の範囲、データ形式、権限、業務上の意味を双方で合わせる必要があります。
セキュリティは実装と運用まで含めて考える
A2Aは、認証要件をAgent Cardで示し、Webで使われてきた認証方式やHTTPSを利用できるように設計されています。しかし、「A2Aに対応すれば安全になる」を意味しません。プロトコルは連携の枠組みを定めますが、誰に何を許可するか、受け取ったデータをどう検証するか、操作をどこまで記録するかは各システムが実装します。
業務で使う場合は、少なくとも次の点を決めておく必要があります。
- 利用者とエージェントをどの方法で認証するか。
- エージェントごとに、参照と更新のどこまでを許可するか。
- 依頼内容と成果物に機密情報を含めてよいか。
- 入力値、ファイル、外部から返る結果をどう検証するか。
- 失敗、再試行、取消し、人による承認をどの段階に置くか。
- 監査に必要な依頼者、処理内容、結果をどこまで記録するか。
利用例で見るエージェントの分担
顧客サポートと請求確認
顧客サポートエージェントが質問を受け、請求に関する確認だけを専門エージェントへ委任する例です。専門エージェントは許可された範囲で情報を確認し、結果を返します。顧客サポート側はその結果を会話の文脈に戻して案内します。
この構成では、顧客との対話と請求処理の責任範囲を分けられます。一方で、顧客情報を渡す条件、専門エージェントが実行できる操作、人へ引き継ぐ基準を先に決める必要があります。
会議記録と文書整理
会議記録を扱うエージェントが要点を整理し、文書管理を担当する別のエージェントへ保存を依頼する例です。依頼側は文書の題名、保存先、公開範囲を伝え、保存側は処理結果をArtifactとして返します。
A2Aが受け持つのはエージェント間の依頼と結果の交換です。音声認識の精度、要約内容の正しさ、保存先の権限設定まで自動的に保証するものではありません。
A2AとMCPの違い
Model Context Protocol（MCP）は、AIアプリケーションをデータ、ツール、外部システムにつなぐためのプロトコルです。A2Aは、独立して仕事を進めるエージェント同士の連携を主な対象にします。
| 比較項目 | A2A | MCP |
|---|---|---|
| 主な接続相手 | 別のAIエージェント | データ、ツール、外部システム |
| 主な目的 | 能力の発見、仕事の委任、状態追跡、成果物の交換 | 利用できるデータや機能の提示と呼び出し |
| やり取りの例 | 顧客対応エージェントが請求エージェントへ調査を依頼する | 請求エージェントが顧客データベースを検索する |
両者は競合するとは限りません。一つの構成で、エージェント間の委任にA2Aを使い、各エージェントが必要なデータやツールへ接続する部分にMCPを使えます。MCP側の構成と安全設計は、MCPサーバーの仕組みと導入手順で詳しく説明しています。
導入前に整理したい設計項目
A2Aの採用可否は、「複数のエージェントをつなぎたい」という理由だけでは決められません。まず、委任する仕事と責任の境界を明確にします。
- 委任する仕事を定義する：入力、期待する結果、完了条件、人へ戻す条件を決める。
- 能力の公開範囲を決める：Agent Cardに示す機能と接続情報を必要な範囲に絞る。
- データ形式を合わせる：MessageとArtifactの項目、必須値、サイズ、機密区分を決める。
- 権限を最小化する：参照、作成、更新、削除を分け、仕事に必要な権限だけを与える。
- 異常時の流れを設計する：タイムアウト、重複実行、取消し、部分的な失敗を扱う。
- 人の確認を残す：支払い、公開、削除など影響の大きい操作には承認点を置く。
小さな業務と限定したデータから試すと、仕様への対応だけでなく、結果の品質、待ち時間、運用負荷、監査のしやすさも確認できます。
A2Aを理解するための要点
- A2Aは、異なるAIエージェント間で能力、依頼、状態、成果物を交換するためのプロトコルである。
- Agent Card、Message、Task、Artifactを押さえると、連携の流れを具体的に理解できる。
- MCPは主にデータやツールとの接続、A2Aは主にエージェント同士の連携を担う。
- 相互運用性は接続の共通化であり、回答の正しさ、業務上の安全性、権限管理を自動的に保証しない。
- 導入時は、委任範囲、データ形式、認証と認可、異常処理、人の承認を一つの運用として設計する。
公式情報
- Google Developers Blog「Announcing the Agent2Agent Protocol (A2A)」
- A2A Protocol「Core Concepts」
- A2A Protocol「Enterprise Features」
- Model Context Protocol公式ドキュメント「What is MCP?」