Agent-to-Agent／マルチエージェント編 — A2A v1.0、framework内引継ぎ/担当を分けたエージェント/複数工程の制御、MCPとの役割差を横断し、委譲・文脈・入力情報・主体の識別/認可・失敗伝播・人による確認・評価を別契約として整理する

台帳EA-006はA2A、MCP、各社agent frameworkを横断して、委譲、役割分離、失敗伝播、人間承認を研究する構想である。2026-03にA2A v1.0がstable/production-ready revisionとして公開され、2026-08にはAgentic AI FoundationのGrowth Stage projectへ移行した。一方、OpenAI Agents SDK、Microsoft Agent Framework、LangChain/LangGraph等は同じ「multi-agent」でもmanager-as-tools、handoff、parallel/sequential workflow、group chat、router、state graphなど異なる制御構造を提供する。したがって「複数agentが会話する」ことを単一パターンとして扱わず、interoperability protocolとorchestration topology、control ownership、authorization、context transfer、terminationを分離する必要がある。

Enterprise AI Core: delegation contract、control ownership、identity/authorization、context/data minimization、human approval、failure isolation、termination、distributed tracing。 Interoperability: A2A v1.0、MCPとの水平/垂直接続境界。 Implementation: OpenAI Agents SDK、Microsoft Agent Framework、Google ADK/A2A系、LangChain/LangGraph multi-agent patterns。 Governance: agent registry/Agent Card trust、delegation policy、approval、cross-org agent connection、version/change control。 Benchmark: multi-agent coordination、handoff、resource contention、task verification/termination。

Q1. A2Aはmulti-agent orchestratorか、それとも独立agent間のinteroperability protocolか。 Q2. framework内handoffとA2A remote delegationを同一の「委譲」とみなしてよいか。 Q3. agentへtaskを委譲することは、呼出元user/workloadの権限をそのまま委譲することを意味するか。 Q4. context/historyを多く渡すほどmulti-agent品質は上がるか。それともdata exposure/context bloat/misalignmentを増やし得るか。 Q5. human approvalはA2A/MCP/frameworkのどの層で成立し、approval requestとauthorization decisionをどう分離すべきか。 Q6. agent数増加・通信追加は単純に品質向上となるか。どのfailure modeを独立評価すべきか。

• source class: official protocol specification exact title: Agent2Agent (A2A) Protocol Specification org: A2A Project / Agentic AI Foundation canonical URL: https://a2a-protocol.org/latest/specification/ publication/update/access: latest specification accessed 2026-09-11 version/release: A2A 1.0.0 latest released version supporting locator: Introduction; layered protocol model; Authentication and Authorization; In-Task Authorization; Agent Discovery/Agent Card label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / boundary established: A2Aは異なるframework/vendorのopaque agent systemsがcapability discovery、modality negotiation、task collaborationを行うopen interoperability standardである。canonical data model、abstract operations、JSON-RPC/gRPC/HTTP REST等のprotocol bindingsを分離し、内部memory/tool実装の共有を要求しない。したがってA2Aそのものはmanager/router/workflow topologyを規定するorchestratorではない。

• source class: official stable-release announcement exact title: A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication org: A2A Project canonical URL: https://a2a-protocol.org/dev/blog/2026/03/12/a2a-protocol-ships-v10-production-ready-standard-for-agent-to-agent-communication/ publication/access: 2026-03-12 / accessed 2026-09-11 version: A2A v1.0 supporting locator: enterprise requirements; MCP relationship; migration label: SOURCE_REPORT + PRODUCT_VOLATILE relation: support / temporal / interoperability established: v1.0はstable/production-ready releaseとしてmulti-protocol bindings、version negotiation、multi-tenancy、signed Agent Cards等を導入/強化した。公式説明はMCPを個々のagentとtool/contextをつなぐ層、A2Aをagent間communication/coordination層と位置付け、併用可能としている。v0.3→v1.0にはbreaking interaction changesがあるためversion inventoryが必要。

• source class: official current protocol change guide exact title: What's New in A2A Protocol v1.0 org: A2A Project canonical URL: https://a2a-protocol.org/latest/whats-new-v1/ publication/access: current / accessed 2026-09-11 version: v1.0 vs v0.3.0 supporting locator: Protocol Maturity; Enterprise-Ready Features label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / migration / security established: normative sourceをa2a.protoへ一本化し、binding equivalence、versioning、error taxonomyを強化。JWS + JSON CanonicalizationによるAgent Card署名、mTLS security schemes、modern OAuth flows、PKCE、multi-tenancy等がv1.0のenterprise-oriented changeとして整理される。

• source class: official protocol specification — Agent Card signing/authentication exact title: Agent2Agent (A2A) Protocol Specification — Agent Card Signing / Authentication and Authorization org: A2A Project canonical URL: https://github.com/a2aproject/A2A/blob/main/docs/specification.md publication/access: main corresponding to current 1.0 line / accessed 2026-09-11 version: 1.0.0 supporting locator: §7 Authentication and Authorization; §8 Agent Discovery; §8.4 Agent Card Signing label: VERIFIED_SPEC relation: support / security limit established: Agent Cardはidentity/capability/skills/endpoints/security requirementsを自己記述し、JWS署名をMAYで利用できる。client authentication requirementはAgent CardのsecuritySchemesで発見しcredentialはout-of-band取得する。serverは各A2A operationでcaller authorization boundaryを実装する必要がある。 limit: Agent Card署名はcardのorigin/integrityを検証する仕組みであり、そのagentのtask quality、安全なtool implementation、組織による利用承認まで証明しない。署名がMAYである点も固定する。

• source class: official protocol specification — in-task authorization exact title: Agent2Agent (A2A) Protocol Specification — In-Task Authorization org: A2A Project canonical URL: https://github.com/a2aproject/A2A/blob/main/docs/specification.md publication/access: accessed 2026-09-11 version: 1.0.0 supporting locator: §7.6.1–7.6.4; TASK_STATE_AUTH_REQUIRED label: VERIFIED_SPEC relation: support / critical authorization boundary / failure envelope established: agentは追加authorizationが必要なtaskをTASK_STATE_AUTH_REQUIREDへ遷移させ、clientへ解決を委ねられる。clientがA2A agentならauthorization requestをさらに上流へdelegateできる。ただしprotocolは得られたauthorization/credentialのscope、representation、validity、revocation semanticsを定義せず、AUTH_REQUIRED state自体を特定operationのauthorizationとして扱ってはならない。credentialのin-band chain伝播は複数agentへsecretを露出し得るためout-of-band取得が推奨される。

• source class: official project governance/status exact title: A New Chapter for A2A: Joining the Agentic AI Foundation org: A2A Project / Agentic AI Foundation canonical URL: https://a2a-protocol.org/latest/blog/2026/08/27/a-new-chapter-for-a2a-joining-the-agentic-ai-foundation/ publication/access: 2026-08-27 / accessed 2026-09-11 version: Growth Stage AAIF project supporting locator: Horizontal Orchestration Layer label: SOURCE_REPORT + PRODUCT_VOLATILE relation: context / governance / interoperability established: A2AはAAIF Growth Stage projectとなり、agent discovery/delegation/collaborationのvendor-neutral horizontal protocolとして位置付けられる。MCPはvertical tool/data integration、A2Aはhorizontal peer collaborationという公式整理が継続している。

• source class: official framework documentation exact titles: Agent Orchestration; Handoffs; Agents org: OpenAI Agents SDK canonical URLs: https://openai.github.io/openai-agents-js/guides/multi-agent/ ; https://openai.github.io/openai-agents-js/guides/handoffs/ ; https://openai.github.io/openai-agents-js/guides/agents/ publication/access: current docs crawled 2026-09 / accessed 2026-09-11 version: current OpenAI Agents SDK JS/Python surface supporting locator: manager/agents-as-tools vs handoffs; handoff input/filter/isEnabled; authorization warning label: VERIFIED_SPEC + OSS_PRACTICE + PRODUCT_VOLATILE relation: support / implementation / counter established: framework内でもmanagerがspecialist agentをtoolとして呼びcontrolを保持するpatternと、specialistへconversation controlを移すhandoffは別物。handoff destinationはmodelがtoolとして選択でき、context/historyはinput filterで制御できる。authorizationがhandoff payload値に依存する場合、onHandoff開始時にside effect前の明示checkが必要で、tool input guardrailはhandoffへ自動適用されない。 limit: 「handoffが有効になっている＝そのpayload/operationがauthorized」は成立しない。

• source class: official framework documentation exact title: Workflow orchestrations in Agent Framework org: Microsoft canonical URL: https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/ publication/update/access: last updated 2026-08-25 / accessed 2026-09-11 version: current Microsoft Agent Framework supporting locator: Sequential / Concurrent / Handoff / Group Chat / Magentic; Human-in-the-Loop label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: support / topology / human approval established: Microsoft Agent Frameworkはsequential、concurrent、handoff、group chat、Magentic manager等を別orchestration patternとして提供し、approval-required toolやrequest-infoでworkflowをpauseしてhuman reviewできる。multi-agentは単一topologyではない。

• source class: official framework documentation exact title: Multi-agent / Handoffs / Custom workflow org: LangChain / LangGraph canonical URLs: https://docs.langchain.com/oss/python/langchain/multi-agent/index ; https://docs.langchain.com/oss/python/langchain/multi-agent/handoffs ; https://docs.langchain.com/oss/python/langchain/multi-agent/custom-workflow publication/access: current docs / accessed 2026-09-11 version: current LangChain/LangGraph docs supporting locator: subagents, handoffs, skills, router, custom workflow; context engineering label: OSS_PRACTICE + PRODUCT_VOLATILE relation: support / topology / context limit / cost established: subagent manager、handoff、router、custom deterministic+agentic graph等を別patternとして整理している。subgraph handoffでは何をcontextとして渡すかを明示設計しないとmalformed historyやcontext bloatを生むと記載。公開docsの例でもparallelizable subagent/routerとsequential handoffでmodel-call/token cost特性が異なる。 limit: docs内のtoken/call数は例示scenarioの値であり一般benchmarkとして固定しない。

• source class: official Google implementation/tooling documentation exact titles: agents-cli Use Cases; CLI org: Google Agents / ADK ecosystem canonical URLs: https://google.github.io/agents-cli/guide/use-cases/ ; https://google.github.io/agents-cli/cli/ publication/access: current docs / accessed 2026-09-11 version: current Agents CLI/ADK ecosystem supporting locator: A2A multi-agent systems; incident response/distributed migration; --mode a2a|adk label: VERIFIED_SPEC + PRODUCT_VOLATILE relation: implementation / interoperability / limit established: Google系toolingはA2A specialist agentsをserviceとして並べcoordinatorがorchestrateする例を提供し、remote queryでA2AとADK modeを分離している。A2A通信を使うこととcoordinator/orchestration logicを持つことは別実装責任である。 limit: use-case記述の「parallel investigation reduces time」は一般性能保証として採用せず、architecture exampleに限定する。

• source class: primary empirical research exact title: Why Do Multi-Agent LLM Systems Fail? authors: Mert Cemri et al. canonical URL: https://arxiv.org/abs/2503.13657 publication/access: 2025-03-17 / accessed 2026-09-11 version: study of five popular MAS frameworks, 150+ tasks, expert annotation supporting locator: abstract; failure taxonomy label: RESEARCH relation: counter / failure taxonomy established: 5 MAS frameworks・150超tasksの分析で14 failure modesを抽出し、(i) specification/system design、(ii) inter-agent misalignment、(iii) task verification/terminationの三群へ整理。role specificationやorchestration改善だけで簡単に解消できないfailureが残ると報告する。 limit: 2025時点のframework/model/task sampleであり、2026の全agent system failure rateへ数値を一般化しない。

• source class: primary benchmark research exact title: MultiAgentBench: Evaluating the Collaboration and Competition of LLM agents authors: Kunlun Zhu et al. canonical URL: https://arxiv.org/abs/2503.01935 publication/access: 2025-03-03 / accessed 2026-09-11 version: benchmark across interactive scenarios/topologies supporting locator: abstract; star/chain/tree/graph coordination and milestone KPI label: RESEARCH relation: benchmark / support / limit established: task completionだけでなくcollaboration/competitionのmilestone KPIを提案し、coordination topologyによって結果が変わることを示す。agent数や会話量ではなくtopologyとcoordination behaviorを評価対象にする根拠となる。 limit: 特定benchmarkでgraph等が優位だった結果を一般的な「graphが最良」として固定しない。

• source class: primary benchmark research exact title: DPBench: Large Language Models Struggle with Simultaneous Coordination authors: Najmul Hasan, Prashanth BusiReddyGari canonical URL: https://arxiv.org/abs/2602.13255 publication/access: 2026-02-02 / accessed 2026-09-11 version: coordination benchmark using resource contention / Dining Philosophers supporting locator: abstract; simultaneous vs sequential; communication condition label: RESEARCH relation: counter / concurrency failure envelope established: tested modelsはsequential settingよりsimultaneous resource contentionで大きく失敗し、一部条件でdeadlock率95%超。communication追加でも解消せず悪化する場合があり、external coordination mechanismの必要性を示す。 limit: Dining Philosophers由来のsynthetic coordination taskであり、全business multi-agent systemのdeadlock率へ外挿しない。

• source class: primary benchmark research exact title: CoCoBench: A Cooperative Coordination Benchmark for Embodied Multi-Agent Task Planning authors: Yang Chen et al. canonical URL: https://arxiv.org/abs/2608.28266 publication/access: 2026-08-28 / accessed 2026-09-11 version: 897 oracle-validated embodied coordination instances supporting locator: task allocation; sequential ordering; mutual exclusion; handoff coordination label: RESEARCH relation: benchmark / counter / construct-level evaluation established: overall task successだけでは重複作業、順序制約違反、resource contention、handoff desynchronization等が隠れるため、coordination construct単位の評価が必要とする。strong overall performanceが全coordination typeの均衡した能力を意味しない。 limit: embodied household tasks中心でありenterprise knowledge-work agentへ結果値を直接外挿しない。

EA-006の公開後章は「multi-agent製品一覧」ではなく、少なくとも次の八層へ分けると安全である。 A. Interoperability plane: A2A等。agent間でdiscovery、message/task/artifact、stream/push、version/bindingを共有する。orchestration policyそのものではない。 B. Orchestration topology plane: manager/subagent、handoff、sequential、parallel/concurrent、router、group chat、graph、Magentic型等。A2Aの有無とは独立。 C. Delegation/control plane: 誰が最終controlを保持するか。agents-as-toolsはmanager保持、handoffはreceiverへactive control移行、remote A2A delegationは別serviceへtaskを委ねるが上位workflow ownershipまで自動移転しない。 D. Identity/authorization plane: caller、user、workload、remote agent、downstream resourceのidentityと権限を分ける。task delegationとcredential delegationを同義にしない。AUTH_REQUIREDは「追加authorizationが必要」というstateでありpermission grantではない。 E. Context/data plane: raw history、summary、structured handoff payload、artifact/reference、retrieved dataを何まで渡すかを明示する。最小contextでtaskを遂行できるようdata minimizationを設計し、agent chainへのcredential/secret伝播を避ける。 F. Human/policy decision plane: model routing、policy authorization、human approvalを三分離する。high-impact actionはframework/tool/agent側でpause-and-approve可能なcontrol pointを設ける。 G. Failure/termination plane: timeout、partial failure、duplicate work、deadlock/resource contention、handoff loss/desync、misalignment、verification failure、non-termination、cancellation、rejection、input/auth requiredをstateとして扱う。child failureをparent successへ隠さない。 H. Observability/evaluation plane: distributed trace、parent-child task relation、agent/version/model/tool/policy、handoff input/output、approval actor、artifact、latency/cost、terminal reasonを相関する。task successだけでなくcoordination constructを評価する。

A2AとMCPは競合する一択ではない。2026年の公式整理ではA2Aはagent間のhorizontal interoperability、MCPはagentからtool/dataへのvertical integrationとして併用可能である。ただしこれは概念上の境界であり、bridge/gatewayで相互変換する実装が存在しても、A2A task semanticsとMCP tool semantics、identity、authorization、state ownershipが自動的に同一になるわけではない。

最重要の運用境界は「委譲は権限移譲ではない」である。A2A自身がAUTH_REQUIREDのscope/validity/revocationを定義しないことを明記し、OpenAI SDKもhandoff enablementとpayload-dependent authorizationを分離している。agent Aがagent Bへ仕事を渡したことから、user credential、Aのservice credential、downstream write authorityをBへコピーしてよいとは導けない。

• 「multi-agent=単一agentより高品質」は確立できない。failure taxonomy/benchmarksはcoordination cost・misalignment・termination・resource contention等を示す。
• agentを増やす、会話を増やす、全historyを共有することを改善策として一般化しない。context bloat、secret/data exposure、duplicate work、coordination overheadを増やし得る。
• A2A v1.0 conformantだから安全/高品質/authorizedなagentとは限らない。protocol conformance、Agent Card authenticity、organization approval、task quality、downstream authorizationを分離する。
• signed Agent Cardはmetadata authenticity/integrityの補助であり、skillの真実性・実装安全性・成果品質を証明しない。署名自体もMAY。
• AUTH_REQUIRED stateはauthorization grantではない。credential chain propagationはagent間secret exposureを増やし得る。
• frameworkのhandoffはprotocol A2A handoffと同義ではない。in-process state transition、conversation ownership transfer、remote task delegationは別contract。
• human-in-the-loopを「人間が最終責任者」の一語で済ませない。誰が、どのside effect前に、何を見て、どのscope/期限でapproveしたかを記録する。
• parent/managerがchild resultを要約すると、child error・uncertainty・provenanceが消える可能性がある。structured status/provenanceを別保持する。
• parallel/concurrent agentsではrace、duplicate side effect、resource contention、order violationを設計する。LLM同士の自然な会話だけをlock/transaction mechanismの代替にしない。
• benchmarkの勝者/topologyを全domainへ外挿しない。DPBench、CoCoBench、MultiAgentBenchは異なるcoordination constructを測る。

A2A: client/server protocol version、binding、Agent Card/interface、auth scheme、TLS/mTLS/OAuth/PKCE support、extension support、SDK compatibility、network/reachability、tenant routing。 Remote agent: organization allowlist、agent/card signature policy、owner/trust review、skill entitlement、caller identity、quota/rate limit、region/data residency。 Framework handoff: enabled destination、routing/tool visibility、context filter/state persistence、payload authorization、receiving agent/model/tool availability。 Workflow: sequential/concurrent topology、checkpoint/state store、retry/cancel semantics、human approval channel、idempotency/lock/resource coordination。 Data: artifact/file modality、sensitivity、cross-org sharing policy、retention/logging、secret handling。

A2A v1.0: stable released protocol as of 2026-09-11; AAIF Growth Stage governance。official SDK/TCK/Inspector ecosystem continues evolving, therefore implementation support remains PRODUCT_VOLATILE。 OpenAI Agents SDK: maintained framework with manager-as-tools and handoff patterns; handoff authorization/context semantics documented。 Microsoft Agent Framework: current framework exposes multiple orchestration patterns plus HITL approval; product/documentation surface is fast-moving in 2026。 LangChain/LangGraph: maintained OSS framework with subagents/handoffs/router/custom workflows and explicit context-engineering responsibilities。 Google ADK/Agents tooling: maintained ecosystem with A2A service/coordinator examples; exact ADK version/protocol support matrix should be rechecked at publication。

最低限、multi-agent評価を次の独立指標へ分解する。 1. End-to-end task success / artifact correctness。 2. Delegation accuracy: 適切なagent/skillへ渡したか、不要なhandoff/loop率。 3. Handoff integrity: required context/provenance/constraintsが欠落・改変なく渡ったか。 4. Coordination constructs: task allocation、ordering、mutual exclusion、resource contention、handoff synchronization。 5. Verification/termination: false completion、child failure suppression、non-termination、cancel/reject propagation。 6. Authorization correctness: unauthorized child/tool/data accessがないか、AUTH_REQUIRED/approvalのscope adherence。 7. Side-effect safety: duplicate write、race、partial commit、retry idempotency。 8. Observability completeness: parent-child task/trace、agent/version、approval、artifact/provenanceの再構成率。 9. Cost/latency: model calls、tokens、remote calls、parallelism、human wait、retryを含むend-to-end cost/p50/p95。 10. Robustness: unavailable agent、network partition、stale Agent Card、version mismatch、malformed result、slow childへのfallback。

Security: Agent Card/TLS identity、caller/workload identity、operation-level authorization、child/downstream credential separation、allowlist、side-effect approvalを多層化。delegation graphに沿ってcredentialをコピーしない。 Privacy: agent間で必要最小contextだけ共有し、raw conversation・retrieved source・artifact・credentialを別classとして扱う。cross-org A2Aでは各remote agentのretention/training/residencyを個別確認する。 Audit: traceId + parentTaskId/childTaskId + agent identity/version + model/tool + handoff reason/input summary + auth subject/scope + approval + artifact/provenance + terminal state/errorを相関可能にする。 Cost: 「agent数」ではなくmodel invocation、parallel fan-out、remote service、tool/API、context transfer、retry、human wait/approvalをend-to-end計測する。multi-agent overheadとquality gainを同じ表で比較する。 Operability: topology/state machineを明示し、timeout/retry/cancel/duplicate suppression/idempotency/checkpoint/fallbackをdeterministic controlとして実装する。LLM coordinationにtransaction/lockingを代行させない。

「マルチエージェントは、複数のAIを並べれば自動的に賢くなる仕組みではない。まず『どう接続するか』と『誰が仕事を割り振り、誰が最終判断を持つか』を分けて考える必要がある。A2Aは異なるエージェント同士が能力を発見し、taskやartifactを交換するための相互運用protocolであり、manager、handoff、parallel workflowなどのorchestration方式そのものを決めない。MCPも別の層で、主にagentとtool/dataを接続する。さらに、仕事を別agentへ委譲したことは、そのagentへ利用者の権限やcredentialをそのまま渡してよいことを意味しない。context、identity、authorization、human approval、失敗・終了状態、監査を別々の契約として設計する。複数agentでは、重複作業、handoff欠落、誤った終了判定、deadlockやresource contentionも起こり得るため、最終task成功率だけでなくcoordinationそのものを評価する。」

• EA-006は八層（interoperability / orchestration topology / delegation-control / identity-auth / context-data / human-policy / failure-termination / observability-eval）を章骨格候補にする。
• A2A節はv1.0をcurrent baselineとし、v0.3以前のAgent Card/task/auth例をversion付きhistorical扱いにする。公開直前にlatest spec、SDK six-language support、TCK/Inspector、AAIF project statusを再確認。
• EA-005 MCPとcrosswalkを作る。A2A=agent↔agent、MCP=agent↔tool/dataという公式説明を入口にするが、bridge時のtask/tool semantic mismatch、identity、state ownershipを別表にする。
• 「delegation != authorization」をCore原則候補としてEA-054 Agent Identity、EA-055 Multi-Agent Governance、EA-062 AI操作権限モデル、EA-162 OAuth/OIDC×Agentへ接続する。
• Agent Card trust表を作り、discovery source、owner、service endpoint、protocol/interface version、signature present/verified、security scheme、skills、organization approval、last reviewを分離する。signatureをapprovalにしない。
• framework crosswalkはOpenAI manager/handoff、Microsoft sequential/concurrent/handoff/group-chat/Magentic、LangGraph subagent/handoff/router/custom workflow、Google ADK/A2A coordinatorを「control owner / context passing / parallelism / state persistence / HITL / failure propagation / remote interoperability」で比較する。
• human approval modelをagent action単位で定義する。approval request、authorization credential、policy decision、human confirmation、side-effect executionをeventとして分離し、scope/expiry/actorを監査可能にする。
• TEST_PROFILE（未実施）: synthetic read-only/write mock agents 3体で manager-as-tools、handoff、parallel fan-out、A2A remote delegationを同一taskに実装し、context leakage、delegation accuracy、child failure、timeout、duplicate side effect、AUTH_REQUIRED、cancel propagation、trace completenessをfault injection付きで比較する。実tenant/課金/secretは使わない。
• benchmark appendixでWhy Do Multi-Agent LLM Systems Fail?、MultiAgentBench、DPBench、CoCoBenchを並べ、failure taxonomyとcoordination constructを採る。個別model/topologyの勝敗数値はgeneral guaranteeにしない。
• failure state machineを作り、submitted/working/input-required/auth-required/completed/failed/canceled/rejectedとframework固有stateをmappingする。parent/child stateを一つに潰さない。
• 公開時にはA2A Agent Card signatureのMAY/required-by-org差、OAuth/mTLS support、cross-tenant/cross-org operation、push/streaming、data retentionを再採集する。
• 次のEA-007ではconnector/iPaaS/automationを扱うため、agent-to-agent orchestrationとdeterministic workflow automationの境界を引き継ぐ。

/ STOP_CONDITION

• 2026-09-11時点のA2A official six SDKsそれぞれのexact v1.0 support version、TCK pass status、extension差分。
• Signed Agent Cardの主要enterprise product実装率、organization trust store/rotation/revocationの実運用。
• A2A cross-organization delegationでuser-delegated identityを安全に連鎖させる標準的scope/credential profile。core v1.0はAUTH_REQUIRED credential semanticsを意図的に定義しない。
• OpenAI/Microsoft/Google/LangGraph間で同一use caseを比較した独立production-scale reliability/cost evidence。
• human approval eventをframework横断で表現するstandard schemaとaudit interoperability。
• A2A agent discovery/registryのorganization-wide approved catalog standardization状況。
• remote agentが内部でMCP/tool/subagentsを使う場合のend-to-end provenance標準。
• parallel multi-agent workflowでtransactional side effectを跨ぐ一般的rollback/compensation標準。

EA-006の更新章に必要なA2A v1.0 current baseline、MCPとの層分離、framework topology差、delegationとauthorizationの非同一性、Agent Card trust境界、HITL、context passing、failure/termination、coordination benchmarkまで一次仕様・framework docs・primary researchで確立した。全SDK/version/product integration matrixまで固定するとPRODUCT_VOLATILEでありEA-054/055/162等とも重複するため、本RUNはEA-006でbounded closeする。次の未調査最小番号はEA-007「AI連携・自動化ツール大全」。

• A2A Protocol 1.0.0 remains the latest released version in the official specification.
• A2A v1.0 is a stable production-ready interoperability protocol for independent/opaque agent systems.
• The current specification carries an explicit protocol version and supports multiple protocol bindings; version and binding remain deployment contracts rather than labels inferred from an SDK.
• The official JavaScript SDK documents v1.0 support and an opt-in v0.3 compatibility layer, confirming staged migration/backward compatibility as an implementation concern.
• This does not collapse A2A, MCP, framework-internal delegation, identity/authorization, or human approval into one control plane.

• https://a2a-protocol.org/latest/specification/
• https://a2a-protocol.org/v1.0.0/
• https://a2a-protocol.org/dev/blog/2026/03/12/a2a-protocol-ships-v10-production-ready-standard-for-agent-to-agent-communication/
• https://github.com/a2aproject/A2A/blob/main/specification/a2a.proto
• https://github.com/a2aproject/a2a-js

• A2A interoperability is not authorization to perform a business side effect.
• An Agent Card/capability advertisement is not proof of trustworthiness, tenant policy, least privilege, or current runtime state.
• Protocol compatibility does not guarantee framework-internal handoff semantics, memory behavior, retry semantics, or evaluation parity.
• Multi-agent systems can amplify failure, duplicated actions, stale context, and authority confusion even when the wire protocol is valid.
• No production tenant, paid endpoint, or destructive multi-agent action was exercised in this rescue.

Use A2A for inter-agent interoperability contracts, MCP for tool/data connectivity contracts, and framework-specific delegation for internal orchestration; then separately define identity, authority, approval, retry/idempotency, context transfer, observability, and failure containment.

• host/framework-specific A2A v1.0 adoption and compatibility defaults;
• cross-product Agent Card trust/reapproval behavior;
• organization-specific authorization and delegated-authority mapping;
• empirical failure propagation under retries and partial multi-agent completion.

PASS_FOR_BOUNDED_BASE_REVISION.

• target: content/staging/EA-006.md
• base repository commit: 97d3d104ae0b16a95e7dffddc3a8cb327795a796
• path precondition: ABSENT
• candidate: V21-CANDIDATE-EA006-BASE-20261011-C1
• READY: NOT_CREATED
• AUDIT_PASS: NOT_CLAIMED
• GIT_WRITE: NOT_PERFORMED