A2Aは「つながる」だけでは相互運用にならない
記事状態: 公開 · 最終確認: 2026-10-11
要点
A2A 1.0 は、エージェント間のディスカバリー、メッセージ、タスク、成果物、ストリーミング/プッシュを共通化するプロトコル契約である。ただし「A2A対応」だけでは相互運用の十分条件ではない。インターフェースごとのプロトコルバージョン/バインディング、エージェントカードの信頼性、リクエストの認可、組織の利用環境（組織の利用環境）の分離、タスク/成果物のセマンティクス、および失敗/リトライを分離して検証する。
現在の判断
A2A 1.0 は、エージェント間のディスカバリー、メッセージ、タスク、成果物、ストリーミング/プッシュを共通化するプロトコル契約である。ただし「A2A対応」だけでは相互運用の十分条件ではない。インターフェースごとのプロトコルバージョン/バインディング、エージェントカードの信頼性、リクエストの認可、組織の利用環境（組織の利用環境）の分離、タスク/成果物のセマンティクス、および失敗/リトライを分離して検証する。
どこまで当てはまるか
A2Aは「つながる」だけでは相互運用にならない
詳しく理解する
結論・何が分かったか
A2A 1.0はagent-to-agent通信の共通契約を提供するが、endpointへ到達できること、Agent Cardを読めること、Taskを受理されたことだけでは相互運用成立とは判定できない。実運用では、少なくとも protocol バージョン、protocol 対応付け、Agent Card、認証・認可、組織の利用環境 処理先の振り分け、Task/成果物 semantics、streaming/push、署名・鍵trust、error/cancel/再試行 を分離して確認する必要がある。
確認できた記述・判断
記述・判断 1 — A2A 1.0ではバージョンと対応付けをinterface単位で扱う
現行仕様では AgentInterface が endpoint URL、protocolBinding、protocolVersion を持つ。標準対応付けは JSON-RPC、gRPC、HTTP+JSON であり、Agent Cardは利用可能なinterfaceを順序付きで宣言する。
記述・判断 2 — 複数対応付けは意味的等価性を要求される
複数protocolを提供するagentは、core 操作内容、behavior、error mapping、authenticationを機能的に等価に保つことを要求される。JSON-RPCだけの疎通成功をgRPC/HTTP+JSONの成功へ一般化してはならない。
記述・判断 3 — Agent Cardはdiscovery 条件・契約であり能力の真実性証明ではない
Agent Cardは主体の識別、capabilities、skills、supported interfaces、security requirements等を宣言する。A2A 1.0ではJWS署名とJCS canonicalizationを利用できるが、署名はCardの真正性・完全性を強化するだけで、利用可能な機能 truthやrequest 認可、business outcomeを証明しない。
記述・判断 4 — 組織の利用環境 処理先の振り分けもprotocol 条件・契約の一部である
AgentInterfaceは組織の利用環境 処理先の振り分け値を持ち得る。endpoint共有型では、接続成功だけで組織の利用環境 isolationを判定せず、cross-tenant task/list/cancel/成果物 accessをnegative testする必要がある。
記述・判断 5 — タスクの受理は、完了・ロールバック・exactly-once（同じ要求の再送で処理を重複させない仕組み）を意味しない
A2Aはmessage、Task、成果物、streaming/push等を定義するが、外部business APIの既実行外部への変更・送信 以前の状態へ戻す操作、duplicate delivery完全排除、業務結果の正しさまではprotocol単体で保証しない。
失敗経路・反証・例外
- Agent Card取得成功をremote agent能力の証拠にする。
- 署名済みエージェントカード（Signed Agent Card）を、認可の成立と同一視する。
- JSON-RPC成功をgRPC/HTTP+JSONへ一般化する。
- protocolVersionを確認せずv0.3とv1.0を暗黙互換とみなす。
- Task 受け入れ確認を業務完了とみなす。
- CancelTask成功を既実行外部への変更・送信の以前の状態へ戻す操作とみなす。
- push callbackを通常requestと同じtrust 適用限界で扱う。
利用できる条件
- Agent Card取得元と情報の鮮度。
- supportedInterfaces のURL・対応付け・protocolVersion。
- clientが実際に選んだ対応付け/バージョン。
- authentication schemeとrequest 認可。
- Signed Agent Cardのtrust store、kid/jku、rotation/revocation。
- 組織の利用環境 処理先の振り分けとcross-tenant resource isolation。
- Task 状態、cancel/再試行、duplicate、重複実行を防ぐ性質。
- 成果物 出典・来歴/integrity。
- streaming/push callbackのauthentication、replay、SSRF境界。
- 提供元/SDK/region/org policyによる利用可能性。
実務チェックポイント
接続前にAgent Cardを保存し、インターフェースごとのバインディング／バージョン／セキュリティ要件を固定する。各バインディングへ同一の固定テスト用データ（fixture）を流し、成功／エラー／認証の等価性を確認する。タスク／成果物／リスト／キャンセルを、組織の利用環境・実行者・範囲の違いでネガティブテストする。Cardの署名検証と能力の実測を分離し、切断、重複プッシュ、リトライ、キャンセル／コミットの競合状態を障害試験する。
証拠・更新情報
根拠 as of: 2026-10-11 JST.
Primary / author-maintained: - A2A プロトコル仕様 — 最新リリース版 1.0.0。 - specification/a2a.proto — AgentInterface / AgentCard / AgentCardSignature. - A2A specification sections for 対応付け 相互運用性 and Agent Card signing. - A2Aカスタムプロトコル・バインディングのガイダンス。 - Existing EA-158 正式な research/監査 packet.
GX 出典・来歴: - GX01_RUN_20260928_1113_A3. GX 実行番号は出典・来歴であり公開記事主体の識別ではない。
よくある失敗・反証
Agent Card取得成功をremote agent能力の証拠にする。
署名済みエージェントカード（Signed Agent Card）を、認可の成立と同一視する。
JSON-RPC成功をgRPC/HTTP+JSONへ一般化する。
protocolVersionを確認せずv0.3とv1.0を暗黙互換とみなす。
Task 受け入れ確認を業務完了とみなす。
CancelTask成功を既実行外部への変更・送信の以前の状態へ戻す操作とみなす。
push callbackを通常requestと同じtrust 適用限界で扱う。
実務での使い方
Agent Card取得元と情報の鮮度。
supportedInterfaces のURL・対応付け・protocolVersion。
clientが実際に選んだ対応付け/バージョン。
authentication schemeとrequest 認可。
Signed Agent Cardのtrust store、kid/jku、rotation/revocation。
組織の利用環境 処理先の振り分けとcross-tenant resource isolation。
Task 状態、cancel/再試行、duplicate、重複実行を防ぐ性質。
成果物 出典・来歴/integrity。
streaming/push callbackのauthentication、replay、SSRF境界。
提供元/SDK/region/org policyによる利用可能性。
まだ確認できていないこと
- EA-158-UNKNOWN-01
- 提供元横断のA2A 1.0 形式への適合実測。
- JSON-RPC/gRPC/HTTP+JSON 間の意味的な同等性。
- エージェントカードの鮮度/レジストリミラー/緊急失効に関する共通の運用。
- delegated 認可/token propagation。
- Task 再試行/cancel/重複実行を防ぐ性質のSDK間差異。
- 成果物 checksum/出典・来歴。
- push delivery 再試行/dedup/replay。
- managed gatewayの組織の利用環境 isolation。
- cross-organization incident 検索対象の文書群。
根拠資料
この記事には、直接開ける外部出典が登録されていません。出典IDや検証情報は末尾で確認できます。
更新履歴
EA-158-GX-REFRESH-20261011-R1: 正式な 監査/publication 対応付け
出典ID・検証情報・機械可読データ
根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。
- 記事ID
- EA-158
- 最終確認日
- 2026-10-11
- 提供元・モデル・プラン・利用環境
- —
- 対象地域
- —
元資料の全文と収録照合記録
結論・何が分かったか
A2A 1.0はagent-to-agent通信の共通契約を提供するが、endpointへ到達できること、Agent Cardを読めること、Taskを受理されたことだけでは相互運用成立とは判定できない。実運用では、少なくとも protocol version、protocol binding、Agent Card、認証・認可、tenant routing、Task/Artifact semantics、streaming/push、署名・鍵trust、error/cancel/retry を分離して確認する必要がある。
確認できたclaim
Claim 1 — A2A 1.0ではversionとbindingをinterface単位で扱う
現行仕様では AgentInterface が endpoint URL、protocolBinding、protocolVersion を持つ。標準bindingは JSON-RPC、gRPC、HTTP+JSON であり、Agent Cardは利用可能なinterfaceを順序付きで宣言する。
Claim 2 — 複数bindingは意味的等価性を要求される
複数protocolを提供するagentは、core operation、behavior、error mapping、authenticationを機能的に等価に保つことを要求される。JSON-RPCだけの疎通成功をgRPC/HTTP+JSONの成功へ一般化してはならない。
Claim 3 — Agent Cardはdiscovery contractであり能力の真実性証明ではない
Agent Cardはidentity、capabilities、skills、supported interfaces、security requirements等を宣言する。A2A 1.0ではJWS署名とJCS canonicalizationを利用できるが、署名はCardの真正性・完全性を強化するだけで、capability truthやrequest authorization、business outcomeを証明しない。
Claim 4 — tenant routingもprotocol contractの一部である
AgentInterfaceはtenant routing値を持ち得る。endpoint共有型では、接続成功だけでtenant isolationを判定せず、cross-tenant task/list/cancel/artifact accessをnegative testする必要がある。
Claim 5 — Task受理は完了・rollback・exactly-onceを意味しない
A2Aはmessage、Task、Artifact、streaming/push等を定義するが、外部business APIの既実行side effect rollback、duplicate delivery完全排除、業務結果の正しさまではprotocol単体で保証しない。
失敗経路・反証・例外
- Agent Card取得成功をremote agent能力の証拠にする。
- Signed Agent Cardをrequest authorization成立と同一視する。
- JSON-RPC成功をgRPC/HTTP+JSONへ一般化する。
- protocolVersionを確認せずv0.3とv1.0を暗黙互換とみなす。
- Task acceptanceを業務完了とみなす。
- CancelTask成功を既実行side effectのrollbackとみなす。
- push callbackを通常requestと同じtrust boundaryで扱う。
Availability Gate
- Agent Card取得元とfreshness。
- supportedInterfaces のURL・binding・protocolVersion。
- clientが実際に選んだbinding/version。
- authentication schemeとrequest authorization。
- Signed Agent Cardのtrust store、kid/jku、rotation/revocation。
- tenant routingとcross-tenant resource isolation。
- Task state、cancel/retry、duplicate、idempotency。
- Artifact provenance/integrity。
- streaming/push callbackのauthentication、replay、SSRF境界。
- provider/SDK/region/org policyによるavailability。
OPEN_UNKNOWN
- provider横断のA2A 1.0 conformance実測。
- JSON-RPC/gRPC/HTTP+JSON間のsemantic parity。
- Agent Card freshness/registry mirror/緊急失効の共通運用。
- delegated authorization/token propagation。
- Task retry/cancel/idempotencyのSDK間差異。
- Artifact checksum/provenance。
- push delivery retry/dedup/replay。
- managed gatewayのtenant isolation。
- cross-organization incident corpus。
実務チェックポイント
接続前にAgent Cardを保存し、interfaceごとのbinding/version/security requirementを固定する。各bindingへ同一fixtureを流し、success/error/authenticationの等価性を確認する。task/artifact/list/cancelをtenant・actor・scope違いでnegative testする。Card署名検証と能力実測を分離し、disconnect、duplicate push、retry、cancel/commit raceを障害試験する。
証拠・更新情報
Evidence as of: 2026-10-11 JST.
Primary / author-maintained: - A2A Protocol Specification — latest released version 1.0.0. - specification/a2a.proto — AgentInterface / AgentCard / AgentCardSignature. - A2A specification sections for binding interoperability and Agent Card signing. - A2A custom protocol bindings guidance. - Existing EA-158 canonical research/audit packet.
GX provenance: - GX01_RUN_20260928_1113_A3. GX RUN番号はprovenanceであり公開記事identityではない。
SAFE_WORDING
A2A 1.0はagent間のdiscovery、message、Task、Artifact、streaming/pushを共通化するprotocol contractである。ただし「A2A対応」だけでは相互運用の十分条件ではない。interfaceごとのprotocol version/binding、Agent Card trust、request authorization、tenant isolation、Task/Artifact semantics、failure/retryを分離して検証する。
EA-158-CURRENT-APPROVAL研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKET現行本文の監査・revision対応
- 裏付ける内容
- 現行台帳のAUDIT_PASSと候補・revision・本文ハッシュの対応を確認しています。
- 確認日
- —
- 出典・実験ID
- GXART-EA158-20261011-R1
- 検証箇所
- 1KqhJtiSb2S84rWmeYVwKcT_76dBwZ_B0ZZuAWQqH0rQ · EA_REVISION_LEDGER!A381:U381 · EA-158-GX-REFRESH-20261011-R1
- 適用範囲
- —
- 出典・来歴
- CURRENT_CANONICAL_APPROVAL_READBACK
- 限界
- 監査状態と来歴の記録です。外部根拠の最新性や本文の全主張を追加保証しません。
EA-158-CURRENT-BODY-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACK現行本文の収録照合
- 裏付ける内容
- 公開生成入力の本文SHA-256が、監査済み候補に結び付いたハッシュと一致しています。
- 確認日
- 2026-10-12
- 出典・実験ID
- BODY-SHA256:49580675d3a03bc68c8bb1c166f1ec05e3a8d612633baf9771078180c2fd701a
- 検証箇所
- content/staging/EA-158.md · 49580675d3a03bc68c8bb1c166f1ec05e3a8d612633baf9771078180c2fd701a · EA-158-GX-REFRESH-20261011-R1
- 適用範囲
- —
- 出典・来歴
- CURRENT_APPROVED_BODY_HASH_MATCH
- 限界
- 本文の同一性の検査です。外部システムの挙動や全主張の真偽を実証したものではありません。
- 出典ID
- GXART-EA158-20261011-R1, BODY-SHA256:49580675d3a03bc68c8bb1c166f1ec05e3a8d612633baf9771078180c2fd701a
- 追跡中のUNKNOWN ID
- EA-158-UNKNOWN-01
- 再確認のきっかけ
- 正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合
機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。
同じ記事IDの機械可読データです。