A2Aプロトコルとは？導入前に決める5項目
目次
はじめに
営業AIが顧客を調べ、法務AIが契約条件を確認する。役割ごとのAIエージェントがそろうと、次に欲しくなるのは横の連携だ。
ところが、実装を始めると会話が急に技術寄りになる。デモは動いても、業務は終わらない。法務AIが依頼を拒否したら誰が引き取るのか。返されたファイルを誰が正本と認めるのか。
A2Aプロトコルは通信の共通言語を提供する。しかし、委任する仕事の責任までは決めてくれない。企業導入では、接続設定より先に5つの業務仕様を合意したい。
A2Aプロトコルはエージェント間の業務委任を標準化する
A2Aの公式仕様は、異なる実装のAIエージェントがメッセージを送り、タスクを追跡し、成果物を受け渡すための標準を定めている。内部のモデルやツールを相手へ公開せず、「何を頼めるか」と「結果をどう返すか」を契約にできる点が特徴だ。
中心になる要素は次の4つである。
- Agent Card：エージェントの名前、接続先、能力、認証方式などを示す
- Message：依頼、追加情報、回答をやり取りする
- Task：長時間の仕事にIDと状態を持たせる
- Artifact：文書、表、画像、構造化データなどの成果物を返す
たとえば営業AIが法務AIへ契約リスクの確認を頼む。法務AIは処理状態を返し、情報不足なら追加資料を求め、完了時に成果物を返す。
MCPとは接続する相手が違う
MCPとA2Aの違いは役割にある。MCPはデータやツールへの接続、A2Aは独立したエージェント同士の連携を担う。A2A公式の比較資料でも、両者は補完関係とされる。
法務AIが契約書ストレージを読む部分はMCP、営業AIから法務AIへ審査を 委任する部分はA2A、という組み合わせがあり得る。MCPとは何かもあわせて読んでほしい。
A2Aを採用する前に確認したい境界
すべての連携にA2Aが要るわけではない。入出力が固定された短い処理なら、通常のAPIやジョブキューのほうが簡単だ。
A2Aが効きやすいのは、次の条件が重なる場面だ。
- 異なるベンダーやフレームワークのエージェントをつなぐ
- 相手の内部実装を知らずに仕事を委任したい
- 処理が長く、途中状態や追加質問を扱う
- 将来、接続先のエージェントを差し替える可能性がある
同じ基盤で作る小さな処理なら、まず内部APIで価値を確かめればよい。「独立した担当者として境界を保ちたいか」が判断軸になる。
項目1：Agent Cardと社内レジストリを分ける
Agent Cardは、エージェントを発見するための標準情報だ。公式のAgent Discovery解説では、接続先、対応するインターフェース、能力、セキュリティ方式などを表現する。ここへ社内の 受付ルールをすべて押し込む必要はない。
標準項目と業務メタデータを分ける。
| 管理場所 | 主な情報 |
|---|---|
| Agent Card | 接続先、対応版、能力、入出力モード、認証方式 |
| 認証済み拡張カード | 限定公開する能力、追加インターフェース |
| 社内レジストリ | 責任部署、SLA、利用申請、データ分類、廃止予定日 |
たとえば`契約レビュー`というAgentSkillには、説明、タグ、入力例、出力例を持たせられる。一方、「法務部の承認が必要」「翌営業日まで」といった運用条件は社内レジストリで管理する。標準と独自情報の境界が分かれば、別ベンダーへ接続先を替えても社内統制を引き継げる。
公開カードと認証後の拡張カードも分けたい。機密性の高い能力を匿名利用者へ見せないためだ。署名、キャッシュ期限、版の更新方法も決める。
項目2：Message、Task、Artifactの役割を固定する
A2Aでは、会話の一往復と長時間の仕事を同じものとして扱わない。依頼や追加情報はMessage、追跡が必要な仕事はTask、生成物はArtifactへ分ける。この対応を業務仕様へ落とす。
契約レビューなら、依頼文とPDFの参照はMessageに載せる。審査にはTask IDを付ける。指摘一覧と根拠表はArtifactとして返す。進捗メッセージへ最終成果物を埋め込むと、依頼側が正本を判定できない。
A2AのTaskライフサイクルを見ながら、状態も対応づける。
| A2Aの状態 | 業務上の意味 | 次に動く人・エージェント |
|---|---|---|
| working | 審査中 | 法務AI |
| input-required | 契約種別が不足 | 営業担当 |
| auth-required | 追加権限が必要 | 情シスまたは依頼者 |
| completed | 必須Artifactが完成 | 営業AI |
| failed / rejected | 再実行不可または受付外 | 運用担当 |
HTTP 200でも、必須Artifactがなければ業務は未完了である。通信結果と受け入れ条件を分けておく。
項目3：対応版、バインディング、拡張を合意する
「A2A対応」だけでは接続試験の条件にならない。公式仕様にはJSON-RPC、gRPC、HTTP+JSON/RESTなどのバインディングがあり、クライアントとサーバーは対応するインターフェースを選ぶ。採用する版、バインディング、ストリーミング、拡張を組み合わせで記録する。
決めるのは4点だ。
- 対応するA2Aの版と更新方針
- 優先するバインディングと代替経路
- ストリーミングまたはPush通知の要否
- 必須拡張と、未対応時の拒否方法
拡張のURI、必須か任意か、未対応時の挙動を決める。版更新時は、古いクライアントが明確なエラーを受け取れるかも試す。
項目4：SecuritySchemeと実行権限を接続する
A2AのAgent CardではAPIキー、HTTP認証、OAuth 2.0、OpenID Connect、相互TLSなどのSecuritySchemeを表現できる。ただし、カードが示すのは認証の入口であり、業務権限そのものではない。
設計では3層を分ける。
- 接続の認証：正しいクライアントエージェントか
- 能力の認可：このAgentSkillを呼べるか
- 対象データの認可：この顧客・案件を扱えるか
営業AIが法務AIを呼べても、別部門の未公開資料を渡せるとは限らない。依頼元ユーザー、テナント、案件、データ分類を受信側でも判定する。追加認可が必要なら`auth-required`へ遷移させ、認証情報そのものはMessageへ書かない。
AWSのエージェントAIに関す る規範ガイダンスも、入出力の検証、TLS、データ最小化、監査を挙げる。権限の一般設計はAIエージェントのセキュリティで決める5つの境界へ譲り、A2Aの設計書にはSecuritySchemeと各能力の権限対応を残す。
項目5：適合試験を業務の受け入れ条件にする
SDK同士がつながっただけでは、相互運用できたとは言いにくい。A社のクライアントからB社のエージェントへ、同じMessageを送り、Task状態とArtifactを解釈できて初めて意味がある。
適合試験では次を固定する。
- Agent Cardを取得し、対応版と能力を選べる
- 未対応の版や必須拡張を明確に拒否できる
- `input-required`から追加Messageで再開できる
- 同じMessage IDの再送で二重実行しない
- ストリーミング切断後もTask IDから状態を復元できる
- ArtifactのMIME typeと構造化データを検証できる
一般的な停止や再試行の考え方は、AIエージェントのオーケストレーションで必要な5つの制御にまとめている。A2A固有の試験では、それらが標準オブジェクトと別実装の間でも同じ意味を保つかを見る。
PoCでは正常系より拒否と復旧を試す
PoCのデモは、営業AIから法務AIへ依頼が届き、きれいな回答が返れば成功に見える。だが、本番で差が出るのは境界条件だ。次の5ケースを同じテストセットに入れたい。
| テスト | 合格条件 |
|---|---|
| 必須入力がない | 追加情報待ちになり、不足項目を返す |
| 権限がない | 実行せず、拒否理由を記録する |
| 同じ依頼を再送 | 二重実行せず、既存taskを返す |
| 処理中にキャンセル | 副作用を止め、途中成果物を区別する |
| 相手が応答しない | 規定回数で止まり、人間へ引き継ぐ |
さ らに、接続先を別実装へ差し替えて同じテストを通す。相互運用性をうたうなら、SDKが動くことではなく、業務の受け入れ条件が変わらないことを確かめたい。
A2A導入の設計表を一枚にする
5項目は別々の資料に散らさず、一枚の設計表へまとめる。
| 項目 | 主な決定 | 責任者 |
|---|---|---|
| 能力と入力 | 対象業務、必須入力、対象外 | 業務責任者 |
| 委任契約 | 状態、完了条件、期限 | PM |
| 権限とデータ | 認証、認可、データ分類 | 情シス・セキュリティ |
| 再試行と停止 | 重複防止、承認、人への移管 | 運用責任者 |
| 成果物と監査 | 正本、証跡、保存期限 | 業務責任者・監査担当 |
A2Aプロトコルを入れる価値は、AIが会話しているように見えることではない。異なるエージェントへ仕事を渡しても、責任と状態を見失わないことにある。
株式会社Atsumellでは、AIエージェント間の役割分担から、権限、停止条件、受け入れテストまでを一緒に設計している。複数エージェントのPoCを「つながった」で終わらせたくない場合は、お問い合わせから相談してほしい。
