AIエージェント相互運用 · 2026-10-31
A2Aプロトコルとは？Agent2Agent仕様・安全性・決済・現状（2026）

A2Aはエージェント間の接続形式を標準化した。しかし「相手は誰か、何ができるのか、問題が起きたら誰が責任を負うのか」は、依然として各社が自分で補う必要がある。本記事は一次情報の仕様書、論文、政府文書をもとに、2026-10-31時点の現状を整理する。

A2Aプロトコルとは？Agent2Agent仕様・安全性・決済・現状（2026）

A2A（Agent2Agent）は、異なる企業・異なるフレームワークのAIエージェント同士が能力を発見し、タスクを委任し、結果を交換するためのオープンプロトコルであり、2026-10-31時点の現行版はv1.0.1（2026-05-26）である。接続形式は標準化したが、ID、認可、問題発生時の責任は各社の実装に委ねられており、企業名が明示され、企業をまたぎ、効果が計測された本番事例も現時点では見つからない。

A2Aは2025年4月にGoogleが発表し、2025-06-23にLinux Foundationへ移管され、2026年8月にはMCPと同じ財団であるAgentic AI Foundation（AAIF）に加わった。v1.0からはa2a.protoを唯一の規範ソースとし、JSON-RPC 2.0、gRPC、HTTP+JSON/RESTの3種類のバインディングに対応する。仕様上の未解決論点は形式から信頼へと移っている。v1.1の8テーマ、コメント数が最も多いエージェントIDの議論（約658件）、そして2026年8〜10月に出た最初の公式SDKのCVEは、いずれもID、委任、認可、プッシュ通知に集中している。実際に稼働しているのは、主に同一クラウドプラットフォーム内の相互運用（AWS、Microsoft、Google）である。一般企業や越境EC・物流事業者にとって、現段階でより堅実なのは、まずWebページの構造化データと、決定論型かつ読み取り専用のMCPツールを整備することであり、書き込み・注文・決済系の操作は、責任の枠組みが整うまで外部エージェントに開放しないことだ。

現行版 v1.0.1 TSC 9席 MCP 40,675 対 A2A 622 リポジトリ 実測で有効なカード 0枚
著者ウェン・チンホン 最終更新 次回見直し 参考資料 65

HowBridge AIリサーチチームが作成。一次情報の仕様書、GitHubの記録、学術論文、政府文書を引用し、すべての事実に出典を付している。情報源同士が矛盾する箇所は併記して説明し、推論とベンダーの主張は別途明示している。 本記事は3種類の記述を区別している。一次情報の仕様書、論文、公式文書の裏付けがあるものは事実として出典を付して記載し、プレスリリースやベンダーのブログのうち独自に検証できないものは「ベンダーの主張」、著者がエビデンスから導いた判断は「推論」と明記している。

要点

  1. A2A（Agent2Agent）の現行版はv1.0.1（2026-05-26）。v1.0からa2a.protoを唯一の規範ソースとし、JSON-RPC 2.0、gRPC、HTTP+JSON/RESTの3種類のバインディングに対応する。
  2. A2AとMCPの境界は推論ループを誰が持つかにある。MCPでは呼び出し側のLLMがツールを制御し、A2Aの相手は自ら推論する不透明なエージェントである。MCPのGitHubリポジトリ数はA2Aの約65倍（40,675対622）。
  3. A2Aの仕様は認可を実装に委ね、カード署名は任意である。2026年8〜10月には最初の公式SDKのCVEが出ており、a2a-javaはかつて既定で読み取り認可を行っていなかった（CVSS 7.5）。
  4. 2026-10-31時点で、企業名が明示され、企業をまたぎ、効果が計測されたA2Aの本番事例は見つからない。実際に動いているのは同一クラウドプラットフォーム内の相互運用である。
  5. AIエージェントの決済はチェックアウト、認可エビデンス、マシン間マイクロペイメントの3層に分かれる。AP2は紛争時の責任を割り当てず、x402の取引件数の多くは水増しである。
  6. 台湾の「人工知能基本法」は施行済みだがエージェントには触れていない。デジタル発展部のリスク枠組みは「AI自律エージェントの権限外行為」をリスクB6に挙げている。
  7. 越境EC・物流事業者が今まず取り組むべきは、Webページの構造化データと決定論型のMCPツールであり、注文・決済系の操作は当面外部エージェントに開放しない。

A2Aプロトコルとは何か？誰が管理しているのか？

A2A（Agent2Agent）プロトコルは、Googleが2025年4月に発表し、2025-06-23からLinux Foundationが管理するエージェント間のオープンプロトコルである。2026-10-31時点の現行版はv1.0.1（2026-05-26）で、異なる組織に属するAIエージェント同士が能力を発見し、タスクを委任し、結果を交換するために使われる。

A2A公式は自らとMCPの役割分担を「MCPは垂直で、単一エージェントを深める。A2Aは水平で、境界を越えてエージェントをつなぐ」と説明している。A2Aでは、呼び出される側は「不透明」なエージェントであり、自ら推論し自ら状態を保持する。呼び出し側はその内部でどのモデルやツールが使われているかを見ることができず、双方はタスク（Task）のライフサイクルを通じて複数回やり取りするだけである。台湾の公式文書もすでにA2Aに言及している。デジタル発展部の「公共部門人工知能活用リファレンスハンドブック」V1.0（文書記載の提供日は民国暦115-01-28）は14ページに「A2A：AIエージェント間の通信プロトコル」という小節を設け、A2Aが「クライアント‐リモート」間の通信に特化していると説明している。

A2Aのガバナンスは3段階に分かれる。2025-06-23にLinux Foundationが引き継ぎを発表し、創設メンバーはAWS、Cisco、Google、Microsoft、Salesforce、SAP、ServiceNowであった。2025-08-29には、IBMが主導していたACPがA2Aに統合され、開発を終了した。実際の意思決定権は9議席の技術運営委員会（TSC）にあり、1社1議席で、Google、Microsoft、Cisco、AWS、Salesforce、ServiceNow、SAP、IBM、Bloombergが名を連ねる。議案はTSC Reviewラベルの付いたGitHub issue上でgitvoteにより採決される。たとえば#1942は41件の論点をv1.1の8テーマに統合したもので、2026-06-25に賛成5票・反対0票で可決された（可決要件51%）。

2026年8月、A2AはGrowth StageプロジェクトとしてAgentic AI Foundation（AAIF）に加わり、MCPと同じ財団に属することになった。加入日は情報源によって一致しない。AAIFのブログとAxiosは2026-08-17、A2A公式ブログと仕様ページは2026-08-27と記し、Forbesの報道日は08-19である。08-17が財団側の対外発表、08-27がプロジェクト側の投稿という可能性はあるが、この解釈を裏付ける情報源はなく、本記事では二つの日付を併記し、どちらかを選ぶことはしない。DiginomicaはA2AをAAIFの5番目のホスト対象プロジェクトとし、先行する4つはMCP、goose、AGENTS.md、agentgatewayだとしている。また、今回は組織面の調整にすぎず、二つの仕様が統合されたわけではないと強調する二次情報もある。

A2Aのガバナンス文書には「設立から18か月後に安定期の構成を決める」と明記されている。2025年6月から数えると、およそ2026年12月に期限を迎えるが、AAIFの発表はTSCを再編するかどうかに触れていない。これは推論だが、TSCの構成が近く変わる可能性があり、注視に値する。

A2Aの6つの中核用語（v1.0仕様に基づき整理）
用語何かv1.0での注意点
Agent Cardエージェントの公開「名刺」。スキル、インターフェース、認証方式を宣言し、慣例として /.well-known/agent-card.json に置くsupportedInterfaces[] を中心とする構成に変更。カード署名は任意
Task1回の協働の作業単位で、独自の状態機械を持つtaskId は必ずサーバーが生成する。終了状態に入ったタスクは再開できない
Message双方がやり取りする1件のメッセージエージェントはTaskを作らずMessageだけを返すこともでき、クライアントは両方を処理できなければならない
Partメッセージや成果物に含まれるコンテンツ片text、raw、url、data の4つから1つを選ぶ平坦な構造に変更し、kind 判別フィールドを削除
Artifactタスクの成果物タスクの進行に合わせてストリーミングで送出できる
Extensionコアの外側に機能を追加する（例：決済）URIで識別し、コアのデータ構造を変更したりenum値を追加したりすることはできない

転送・通関 AIクイックアンサー集：AIと越境物流のQ&Aをもっと見る

出典 A2A Specification| A2A and MCP（A2A公式解説）| Linux Foundation：A2Aプロジェクト設立のプレスリリース（2025-06-23）| LF AI & Data：ACPのA2Aへの統合| A2A GOVERNANCE.md| A2A Issue #1942（v1.1テーマの採決）| AAIF：A2A joins AAIF| Axios（2026-08-17）| A2A公式発表（2026-08-27 AAIF加入）| Forbes（2026-08-19）| Diginomica| デジタル発展部「公共部門人工知能活用リファレンスハンドブック」V1.0

A2A v1.0では何が変わったのか？タスク、ストリーミング、プッシュ通知はどう動くのか？

A2A v1.0.0（CHANGELOGの記載では2026-03-12リリース）は、a2a.protoを唯一の規範ソースとし、同じprotoからJSON-RPC 2.0、gRPC、HTTP+JSON/RESTの3種類のバインディングを導出するようにしたうえで、メソッド名を一新し、Partのデータ構造を平坦化した。2026-05-26のv1.0.1は、1.0.0とワイヤー互換の修正版である。

A2A v1.0ではメソッド名がすべて変わった。message/send は SendMessage に、message/stream は SendStreamingMessage に、tasks/resubscribe は SubscribeToTask に改められ、さらに ListTasks が追加された。RESTパスはAIPスタイルとなり、たとえば POST /tasks/{id}:cancel のようになり、/v1 プレフィックスは外された。HTTPエラー形式はRFC 9457の application/problem+json から google.rpc.Status に置き換えられ、reason は大文字とアンダースコアの表記（例：TASK_NOT_FOUND）、domain は "a2a-protocol.org" に固定された。調査ノートは、今回の改版によってA2AがGoogle API設計ガイドのスタイルに作り替えられたと見ているが、これは推論である。

データモデルで最大の互換性を壊す変更はPartの平坦化である。従来の TextPart、FilePart、DataPart と kind 判別フィールドはすべて削除され、一つのPartに text、raw（bytes）、url、data のいずれか一つだけを入れる形になった。判定方法も kind を読む方式から、どのフィールドが存在するかを見る方式に変わった。mimeType は mediaType に、file.fileWithUri は url に改名された。コミュニティの報告によれば、多くのパーサーはいまだに part.kind を読んでおり、これが0.3と1.0の相互運用失敗の最も多い原因である。Agent Card は supportedInterfaces[] を中心とする構成に変わり、各インターフェースがそれぞれ url、protocolBinding、protocolVersion と任意の tenant を持つ。クライアントは配列の順序に従って選択し、フォールバックを実装することがSHOULDとされている。

バージョンネゴシエーションには、あまり知られていない既定動作がある。A2A-Version ヘッダーが空の場合は0.3として扱われる。クライアントはMajor.Minorだけを送り、サーバーが対応していない場合は −32009 VersionNotSupportedError を返す。同じエージェントが supportedInterfaces に異なる protocolVersion のインターフェースを列挙し、0.3と1.0を共存させることもできる。公式の移行手順は3段階で、まず両方の形式を解析できるようにし、次に1.0を出力しつつ0.3を読み、最後に1.0だけを残す。Atlassian ForgeとMuleSoftはいずれも0.3→1.0の移行ガイドを公開しており、互換性を壊す変更のコストを実際に負担している利用者がいることがわかる。

タスクのセマンティクスには、仕様を読み込まないと気づかない細部がいくつかある。taskId は必ずサーバーが生成する。contextId をクライアントが指定した場合、エージェントは受け入れるか拒否するかしかできず、別のものを生成することはできない。taskId と contextId が一致しない場合、エージェントは拒否しなければならない（MUST）。COMPLETED、FAILED、CANCELED、REJECTED の4つの終了状態にあるタスクへ再びメッセージを送ると UnsupportedOperationError が返る。続きを行うには同じcontext内で新しいタスクを開始し、referenceTaskIds で元のタスクに関連付ける。状態機械には二つの「中断」状態、TASK_STATE_INPUT_REQUIRED と TASK_STATE_AUTH_REQUIRED があり、ブロッキング型の SendMessage も中断状態に達すると戻る。

ストリーミングとプッシュ通知の保証は、多くの人が思っているより弱い。TaskStatusUpdateEvent の final フラグは1.0で削除され、「接続のクローズ」がストリーム終了を表すようになった。そのため、タスクの途中で接続が切れた場合とタスクが完了した場合はクライアントから見て区別がつかず、GetTask または SubscribeToTask を改めて呼ばなければ判別できない。仕様にはイベントIDによる再開の仕組みもなく、v1.1テーマ#1986に挙げられている。プッシュ通知は StreamResponse をHTTP POSTでクライアントのwebhookに送る方式で、Content-Type は application/a2a+json である。仕様がエージェントに求めるのは少なくとも1回送信を試みることだけで、タイムアウトは約10〜30秒がSHOULD、受信側は冪等に処理することがSHOULD、taskId の照合がMUSTとされている。言い換えれば、プッシュ通知は「少なくとも1回、順序保証なし、payloadに署名なし」であり、これは仕様から推論した結果である。冪等性も半分しか実現されていない。SendMessage は messageId による重複排除が「できる」が、必須ではない。

日付と数量については、情報源の食い違いが2か所ある。v1.0のリリース日について、CHANGELOGは2026-03-12、あるサーベイ論文（arXiv:2507.10644 v4）は2026年1月と記し、Linux Foundationの1周年プレスリリースはv1.0が最初の安定版だとするだけで日付を示していない。本記事は一次情報であるCHANGELOGを採用する。SDKの数については、Linux Foundationが2026-04に「production-ready」な言語が5種類あるとしているのに対し、A2A公式発表はPython、Go、Java、JS、.NET、Rustの計6種類を挙げている。ただし、詳しくテストされたRust SDKはコミュニティ版である。

A2Aのバージョンとガバナンスの変遷（2025-04〜2026-10）
日付バージョンまたは出来事要点エビデンスの等級
2025-04GoogleがA2Aを発表50社超のパートナー二次情報
2025-05-270.2.1referenceTaskIds と extended card のブール値を追加一次情報（CHANGELOG）
2025-06-090.2.2互換性を壊すJSON-RPCへの整合、gRPC／RESTの定義、extensions一次情報（CHANGELOG）
2025-06-23Linux Foundationが引き継ぎ創設メンバー7社一次情報（LFプレスリリース）
2025-06-300.2.5Agent Card で protocolVersion が必須に。1タスクに複数のプッシュ設定が可能に一次情報（CHANGELOG）
2025-07-300.3.0agent.json を agent-card.json に改名（互換性なし）、カード署名、mTLS、スキル単位のセキュリティ一次情報（CHANGELOG）
2025-08-29IBM ACPがA2Aに統合ACPは開発終了一次情報（LF AI & Data）
2026-03-121.0.0protoを規範化、Partの平坦化、メソッド改名、バージョンネゴシエーション、マルチテナント、ListTasks一次情報（CHANGELOG）。2026年1月とする論文もある
2026-05-261.0.11.0.0とワイヤー互換の修正。推奨メディアタイプは application/a2a+json一次情報（CHANGELOG）
2026-08-17 または 08-27AAIFに加入MCPと同じ財団情報源間で日付が矛盾
2026-10-01公式 a2a CLI をリリースコマンドラインツール一次情報（A2A発表）

出典 A2A Specification| What's new in A2A v1| A2A CHANGELOG| A2A公式発表| DEV Community：A2A tech update（2026-03-20）| Atlassian Forge：A2A 0.3→1.0 移行| MuleSoft：A2A Connector のアップグレード移行| Petrova et al., Web of Agents（arXiv:2507.10644 v4）| Linux Foundation：A2A 1周年プレスリリース| philippdubach：MCP vs A2A in 2026（2025-04 発表の背景）

A2AとMCPは何が違うのか？どちらを使うべきか？

A2AとMCPの本当の境界は、推論ループを誰が持つかにある。MCPでは呼び出し側のLLMが制御し、相手はschemaが透明なツールを提供するだけである。A2Aの相手は、自ら推論し自ら状態を保持する不透明なエージェントである。両者の採用規模には1〜2桁の差があり、mcp-server トピックの付いたGitHubリポジトリは40,675件、a2a-protocol トピックは622件である。

この1年、「MCPにTasksが加わったのでA2Aは不要になる」という声がよく聞かれたが、MCP 2026-07-28版の実際の方向性はむしろ逆である。MCP 2025-11-25版は確かに実験段階のTasks（SEP-1686）を導入した。これは長時間かかるリクエストの追跡、ポーリング、結果の後からの取得のためのもので、その状態（working、input_required、completed、failed、cancelled）はA2Aとほぼ一対一で対応する。しかし2026-07-28版では、sessionと initialize ハンドシェイクが削除されてMCPはステートレスになり（SEP-2567、SEP-2575）、Tasksはコアから外されて公式拡張 io.modelcontextprotocol/tasks（SEP-2663）となった。さらにサーバー発のリクエストはMRTR（InputRequiredResult と、再送時に添付する inputResponses の組み合わせ）に置き換えられ（SEP-2322）、Sampling、Roots、Logging は deprecated とされた（SEP-2577）。

これらの変更は、MCPのメンテナーが「サーバーが逆に呼び出し側のLLMの推論を借りる」というエージェント化の路線をあえて放棄したことを意味する。これは推論である。MCPサーバーが自ら推論するならモデルを自前で持つ必要があり、その時点で実質は不透明なエージェントであって、外見がツールのままというだけである。MCPのTaskが扱うのは「1回の長時間ツール呼び出しの結果を後から取得する」ことであり、A2AのTaskが扱うのは「双方が問いかける可能性のある複数ターンの協働」で、ほかにAgent Cardによる発見、スキル宣言、artifactのストリーミングがある。逆方向の失敗シナリオもある。価格照会や税率照会のような決定論型の照会にTask、Message、Artifactのライフサイクルを無理に当てはめると、レイテンシも実装コストも増え、呼び出し側のLLMは細かなツールschemaを得られなくなる。これも推論である。調査ノートには「MCPでエージェント間連携を行って失敗した」あるいは「A2Aでツールを包んで失敗した」という実際のインシデント記録は見つかっていない。

採用面では、GitHubのトピック数のほか、体系立っていないPyPIの比較によると、A2A SDKは約1,090万回、MCP SDKは約2.57億回ダウンロードされている。二次情報によれば、ShopifyのUCPエンドポイントはMCPをトランスポート層としており、主要なコマースエージェントが接続してくる際に使うのはMCPである。各クラウドでは、AWS AgentCore RuntimeがA2Aサーバーをデプロイでき（JSON-RPC、POST /、port 9000、OAuth 2.0 または SigV4）、Microsoft FoundryのA2A対応は2026年6月にpublic previewに入り、Google Agent Registryはwell-knownカードを読み取るが、自動発見は同一プロジェクト内に限られる。調査ノートで確認した主要モデルベンダーのうち、Anthropicは現時点でA2Aをネイティブにサポートしておらず、Claude Code関連のissue #104852は2026年10月下旬に起票されたばかりである。

実務上の選び方は単純である。AIアシスタントに自社の決定論型の機能（見積もり、税率照会、配送状況照会）を呼び出させたいならMCPを使い、それぞれ推論を行い異なる組織に属する二つのエージェントを複数ターンで協働させたい場合にのみA2Aが必要になる。HowBridgeの公開MCPは前者にあたり、接続方法はサイト内の転送サービスMCPチュートリアルを参照されたい。

A2AとMCPの対比イメージ図：左側では一つのエージェントがMCPを通じてデータベース、計算機、文書、検索などのツールを呼び出している。右側では住宅と物流倉庫という二つの組織に属するエージェントが、組織の境界を挟んでA2Aでタスクを交換している
AI生成のイメージ：MCPは「エージェントとツールをつなぐ」垂直の接続、A2Aは「エージェントとエージェントをつなぐ」、組織の境界を越えた水平の協働である。
A2AとMCPの比較（2026-10-31時点）
比較項目MCPA2A
接続対象エージェントとツール、リソースエージェントとエージェント
推論ループを誰が持つか呼び出し側のLLMリモートエージェント自身
相手の透明性ツールschemaが透明不透明で、Agent Card の宣言しか見えない
状態2026-07-28版でステートレスに変更、Tasksは公式拡張へ移行状態を持つTaskライフサイクル、複数ターンに対応
発見の仕組みMCP Registry（2025-09からプレビューのまま）/.well-known/agent-card.json。公式のレジストリは提供されない
適した場面価格照会や税率照会など決定論型の照会組織をまたぎ、複数ターンで、相手の判断を要する協働
GitHubリポジトリ数40,675（mcp-server topic）622（a2a-protocol topic）
財団AAIF2025-06からLinux Foundation。2026-08にAAIFへ加入

転送サービスMCPチュートリアル：ClaudeのディレクトリからHowBridgeに接続する ・ HowBridge開発者プラットフォーム：公開MCPと会員MCPの説明

出典 A2A and MCP（A2A公式解説）| MCP 2025-11-25 changelog| MCP 2026-07-28 changelog| WorkOS：MCP 2025-11-25 spec update| gravity.fast：MCP adoption statistics| Hacker News の関連議論（PyPIダウンロード比較）| Presta：UCPとAIショッピングエージェントのガイド| AWS：AgentCore Runtime A2A protocol contract| Microsoft 365 Message Center AZ563716| Google Cloud：Agent Registry automatic registration| anthropics/claude-code Issue #104852

A2Aは安全か？既知の脆弱性とCVEには何があるか？

A2Aの仕様が定めているのは認証情報を「どう宣言し、どう渡すか」だけで、認可は各社の実装に委ねられ、Agent Card の署名も任意である。2026年8〜10月には最初の公式SDKのCVEが出ており、そのうちa2a-javaのCVE-2026-111764は既定で読み取り認可を行わないことからHigh（CVSS 7.5）と評価された。

A2AのAgent Cardは securitySchemes で5種類の認証方式のいずれかを宣言する。API Key、HTTP Auth、OAuth2、OIDC、mTLSである。v1.0ではOAuthのimplicitフローとpasswordフローが削除され、Device Codeが追加され、すべてのクライアントにPKCEの使用が推奨された。仕様はサーバーに「MUST authenticate every incoming request」と求めているが、認可はimplementation-specificであり、認証情報の取得は帯域外（out-of-band）の経路で行う。タスクがAUTH_REQUIRED状態に入った際について、仕様は「Agents MUST NOT treat the state transition alone as authorization」とわざわざ明記している。第13節「セキュリティ上の考慮事項」はprompt injection、委任やtoken exchange、OpenTelemetryにまったく触れておらず、テナント分離に関する専用の要件もない。Semgrepはv0.3時代の論評で、A2Aは「supports but does not enforce Agent Card signing」であり、tokenの有効期間やscopeはプロトコルで拘束されず、さらに同じタスクに複数の並行ストリームを張れるため、盗まれたsession tokenで被害者のストリームを気づかれずに傍受できると指摘している。

Agent Card に署名しても、現時点ではSDKをまたいだ検証が保証されない。仕様の手順は、まずRFC 8785（JCS）でカードを正規化し（signatures フィールドを除く）、それからJWSを行うもので、protected header には alg と kid を含めなければならない（MUST）。Issue #2122（2026-08-10起票、2026-10-31時点で未クローズ）は実測での差異を記録している。a2a-python 1.1.2 と @a2a-js/sdk 1.0.1 では正規化後のバイト列が異なり、Pythonは非ASCII文字を \uXXXX にエスケープし、UTF-16単位ではなくcode pointで並べ替え、数値を 1e-06 と出力する一方、ECMAScriptは 0.000001 と出力する。仕様はREQUIREDフィールドを既定値であっても出現させるよう求めているが、proto3にはpresenceの概念がなく、description: "" や skills: [] は落とされてしまう。typ にも曖昧さがある。PR #2319で仕様の例は修正されたが、a2a-goの出力はなお異なる。もう一つの制約として、署名の検証に通っても証明できるのはカードが改ざんされていないことだけで、発行者のIDは証明されない。コミュニティは、カードを実際に呼び出しを行う実行環境に結び付ける仕組みが規範にまったくないことも指摘している。

仕様に完全に準拠していても成立する攻撃がある。A2ABreak（arXiv:2609.10871、v3 2026-10-24）はLLMを使って自然言語の仕様から37の状態、76の遷移、929の形式化された記述を抽出し、11件の新たな脆弱性を発見した。いずれも「実装上の欠陥をまったく必要とせず、規範に準拠した攻撃者が悪用できる」もので、たとえばcontext identifierが保護されていないことによるクライアント間のcontext注入、委任チェーンを何段も経た後のIDの喪失、エージェントによる未検証の能力の主張などがある。名前の衝突に関する研究（arXiv:2609.27624）は、規範が name を「human-readable metadata, not as a stable identity」と位置づけ、衝突時のルールを定義していないことを指摘する。著者が追跡した7つのオープンソース実装のうち、6つのクライアント型統合がリクエストを攻撃者の管理するエンドポイントに送ってしまい、著者はこれを汎用のプロトコルの脆弱性ではなく、繰り返し現れる実装上の脆弱性の類型と位置づけている。Palo Alto Networks傘下のUnit 42はGoogle ADKを用いたsession smugglingの概念実証で、悪意あるエージェントが「確認のための質問」を装ってシステム指示を聞き出し、クライアントに buy_stock を呼び出させて無許可で10株を購入させる様子を示した。Unit 42は、これはプロトコルの脆弱性ではなく、状態を持つ複数ターンのプロトコルであればどれも影響を受けうること、実環境での悪用は確認されていないことを明言している。コミュニティからは、悪意あるサーバーがAgent Card の description や skills フィールドに指示を潜ませ、ホスト側LLMがそれを指示として実行してしまうという報告もある。

エージェント間攻撃に関する学術界の実証も、「エージェント同士の信頼は前提にできない」ことを裏付けている。Triedmanら（COLM 2025）は、悪意あるWebコンテンツがマルチエージェントシステムの制御フローを乗っ取りうることを示し、GPT-4oの場合、任意コード実行が試行の58%〜90%で成功した。FerragらはICT Express（2026）の査読付きサーベイで、prompt injectionからプロトコル層の攻撃までを整理し、MCPとA2Aの両方を扱っている。

下表のCVE番号は調査ノートの記載をそのまま転記したものである。調査ノート自体が、これらの番号の数字が通常と異なること、一部の項目は単一のデータベースにしか見られないこと（たとえばCVE-2026-90790はa2a-pythonリポジトリに対応するGHSAがなく、OpenCVEにのみ掲載）を注記している。a2a-js、a2a-go、a2a-dotnetのリポジトリのadvisoriesを照会した結果は空だったが、これは権限不足の可能性があり、脆弱性がないとは限らない。この表からは三つの教訓を導けるが、以下は推論である。第一に、Agent Card は攻撃者が制御できる入力であり、ヘッダー名さえ相手が決められる場合がある。第二に、規範が「webhook URLを検証することがSHOULD」としか書いていないため、二つの言語のSDKでSSRFが発生した。第三に、規範が「認可は実装が決める」としているため、最も人気のあるJava SDKは既定で認可を行っておらず、その修正もAndroidプラットフォームの差異によって回避された。

A2A関連のSDKと実装で公開済みの脆弱性（2025〜2026、番号は調査ノートの原文どおり）
番号コンポーネント問題深刻度
GHSA-qw47-mcm5-934w／CVE-2026-111764a2a-java server-common < 1.3.0.FinalInMemoryTaskStore の引数なしコンストラクタが authorizationProvider を null に設定し、既定で読み取り認可を行わない（fail-open）High，CVSS 7.5
GHSA-9rhm-2h4x-jwmx／CVE-2026-111763a2a-java < 1.3.0.Final悪意あるAgentCardが APIKeySecurityScheme で独自のヘッダー名を指定してからredirectを返し、API keyが第三者に転送されるMedium
GHSA-4fpj-g9jf-9rgg／CVE-2026-111765a2a-java（Android）Androidの同期POSTが前項のredirect修正を回避High
GHSA-q78c-5jjq-57g8／CVE-2026-111761a2a-javaプッシュ通知のSSRFMedium
GHSA-x32g-jvvm-4725／CVE-2026-111762a2a-javaprotobufの解析に失敗した際、プッシュ通知の認証情報を平文でlogに書き込むMedium
CVE-2026-90790a2a-python ≤ 1.1.3_dispatch_notification で push_info.url を経由するSSRF。1.1.4で修正。リポジトリに対応するGHSAはなく、OpenCVEにのみ掲載CVSS 6.3
CVE-2026-115419／GHSA-4v6f-7vjh-6x4mStrands Agents A2Aサーバー異なる context_id の呼び出し元が会話履歴を共有してしまう。完全な回避策はなく、1テナントにつき1インスタンスが推奨されるHigh，CVSS 8.1
CVE-2025-6167非公式の python-a2a ≤ 0.5.5パストラバーサル（公式の a2a-sdk とは別パッケージ）未表示

出典 A2A Specification（§4.5、§7、§8.4、§13）| Semgrep：A security engineer's guide to the A2A protocol| A2A Issue #2122（署名の正規化の差異）| A2A Discussion #1677| levelup：Signed Agent Cards prove integrity, not identity| Lotfi et al., A2ABreak（arXiv:2609.10871）| Arun Kumar, Agent Name Collision Attacks（arXiv:2609.27624）| Unit 42：Agent session smuggling| langgraph-a2a-client Issue #8（カードのフィールドへのインジェクション報告）| Triedman et al., Multi-Agent Systems Execute Arbitrary Malicious Code（COLM 2025）| Ferrag et al., ICT Express 12（2026）| GitHub Advisory GHSA-qw47-mcm5-934w| GitHub Advisory GHSA-9rhm-2h4x-jwmx| a2a-java advisory GHSA-4fpj-g9jf-9rgg| a2a-java advisory GHSA-q78c-5jjq-57g8| a2a-java advisory GHSA-x32g-jvvm-4725| OpenCVE：a2a-python| GitLab Advisory：CVE-2026-115419| Vulners：python-a2a

AIエージェントのIDと認可はどう検証するのか？

2026-10-31時点で、AIエージェントのIDと委任には確定した共通標準がまだない。ワークロードIDはIETFのWIMSEワーキンググループが進めており、委任の多くはRFC 8693のtoken exchangeを応用している。外部から検証可能なIDについては、Cloudflare Web Bot AuthやANS v2ドラフトなどの方式が並存しており、A2A自体が関わるのは任意のAgent Card署名だけである。

エージェントIDの問題は、A2Aの外で三つの層に分かれつつある。第一の層はワークロードIDで、「これはどのプログラムか」に答える。draft-klrc-aiagent-auth の著者はAmazon、Zscaler、Ping Identity、OpenAIなどの企業に所属し、このドラフトはIETF WIMSEワーキンググループに採択されて draft-ietf-wimse-aims に置き換えられた。その方針は既存のWIMSEとOAuth 2.0ファミリーを応用し、「新しいプロトコルを発明しない」というものである。第二の層は認可と委任で、「誰の代理として、何ができるか」に答える。Ping Identityの例では、RFC 8693のtoken exchangeの act claim で委任経路全体を記録し、may_act で次のホップを限定している。ただしRFC 8693はもともと「同意がすでに成立した後」のサーバー間交換のために設計されたもので、ユーザーが特定のエージェントに与える同意をネイティブには扱わない。

第三の層は外部から検証可能なIDで、「見知らぬ相手がどうやってそれを信頼するか」に答える。Cloudflare Web Bot AuthはEd25519とRFC 9421でHTTPリクエストに署名するが、Cloudflareは現時点でnonceを検証しておらず、リプレイ対策は主に約1分という短い有効期間に頼っている。ANS v2ドラフトはACMEでドメインを検証し、Bronze、Silver（DANEを追加）、Gold（SCITT透明性ログを追加）の3段階に分ける。A2Aが関わるのはこの層のカード署名だけで、しかも署名は任意である。商用製品はすでに先行して提供が始まっている。Okta Agent SSOは2026-08-24に正式リリースされ、ID-JAGを使用する。Microsoft Entra Agent IDはID-JAGをネイティブにサポートしておらず、一般提供の開始日は情報源によって異なる（2026-04または2026-05）。したがって企業をまたいでA2Aを行う場合、双方がそれぞれの境界でトークン変換を行うことになる可能性が高い。これは推論である。

政府レベルでもこの空白を埋める動きがある。米国NISTのCAISIは2026-02-17にAI Agent Standards Initiativeを発表した。三つの柱は、業界主導の標準、コミュニティ主導のオープンソースプロトコル、エージェントのセキュリティとIDの研究であるが、イニシアチブのページは「interoperable agent protocols」といった総称を記すのみで、A2AやMCPの名は挙げていない。NIST NCCoEの「Software and AI Agent Identity and Authorization」プロジェクトは2026-09-29にコンセプトペーパーへの意見の概要を公表し、回答者は600を超える団体または個人にのぼった。NISTの2026-10-27のブログ〈Design Tenets for Agent Identity Management Systems〉は10条の設計原則を示している。エージェントに独立したIDを持たせること、発起者と結び付け、委任のたびに権限を段階を追って縮小すること、最小権限、短期かつ取り消し可能な認可、リスクに応じた人間の介入、署名されたmandateによる行動範囲の画定、改ざんできない記録の保持などである。位置づけはブログであり、正式な標準ではない。

学術研究の方向性もこれと一致する。Southらは、OAuth 2.0／OIDCを拡張してエージェント専用の認証情報を設け、監査可能な委任チェーンを構築することを提案しており、同じ研究のポジション版はICML 2025 Position Paper Trackに収録されている。ChanらはFAccT 2024で、エージェント識別子、リアルタイム監視、活動ログの3種類の措置によってエージェントの可視性を高めることを主張している。

AIエージェントのIDの3層構造と現状（2026-10-31）
層答える問い主な方式現状
ワークロードIDこれはどのプログラムかIETF WIMSE（draft-ietf-wimse-aims）ワーキンググループのドラフトで、まだRFCになっていない
認可と委任誰の代理として、何ができるかRFC 8693 token exchange（act、may_act）RFCにはなっているが、特定のエージェントに対するユーザーの同意は扱わない
外部から検証可能なID見知らぬ相手がどうやってそれを信頼するかCloudflare Web Bot Auth、ANS v2ドラフト、A2A Agent Card 署名各自で展開しており共通標準はない。A2Aの署名は任意
商用製品企業が今買えるものOkta Agent SSO（2026-08-24リリース、ID-JAG）、Microsoft Entra Agent ID相互の互換性は限られる

出典 IETF Datatracker：draft-klrc-aiagent-auth| Ping Identity：PingによるGemini Agent2Agentの認可| Identra：OAuth on-behalf-of| Cloudflare Docs：Web Bot Auth| IETF：draft-narajala-courtney-ansv2-01| Forkast：6社がエージェントID製品を投入| tech-insider：AIエージェントIDベンダーの比較| NIST：AI Agent Standards Initiative（2026-02-17）| NIST：Software and agentic AI identity コンセプトペーパーへの意見の概要（2026-09-29）| NIST：Design Tenets for Agent Identity Management Systems（2026-10-27）| South et al., Authenticated Delegation and Authorized AI Agents（arXiv:2501.09674）| Chan et al., Visibility into AI Agents（FAccT 2024）

AIエージェントはどう支払うのか？AP2、x402とA2Aはどんな関係か？

AIエージェントの決済は現在、チェックアウト、認可エビデンス、マシン間マイクロペイメントの3層のプロトコルに分かれており、A2Aは決済拡張を載せられる通信層にすぎない。そのうちAP2 v0.2.0（2026-04-28）はCheckout MandateとPayment Mandateに移行し、2026-04-29にGoogleからFIDO Allianceに寄贈されて同団体の管理下に入ったが、仕様は紛争処理を範囲外と明記しており、責任を割り当てていない。

AP2はもはや2025年に多くの人が知っていたバージョンではない。v0.2.0は仕組みをCheckout MandateとPayment Mandateに改め、それぞれをopenとclosedの2段階に分け、SD-JWTで実装し、open mandateは cnf claim にエージェントの公開鍵を格納する。新たな要点はHuman-Not-Presentフローである。ユーザーがまず信頼できるインターフェース上で自分の鍵を使ってopen mandateに署名し、制約条件を記しておく。エージェントは後からエージェントの鍵でclosed mandateに署名し、二つは sd_hash で結び付けられる。加盟店や認証情報プロバイダーは unresolved_constraint を返して、フローを「本人がその場にいる」状態に戻すことができる。仕様はまた、加盟店がCheckout JWTに署名する際は非決定論型の署名（ECDSA）を使い、Ed25519は使わないよう推奨しており、レインボーテーブル攻撃を防ぐためとしている。最も重要なのは、AP2の仕様が紛争処理、保存、閲覧請求をout of scopeとし、否認できない暗号学上の監査証跡を提供することだけを約束している点である。調査ノートはさらに、AP2仕様が推奨する拡張方式はUCPのextension pointsであり、A2Aは仕様本文でむしろ議論されていないことに注目している。AP2の位置づけは「A2Aの拡張」から「コマースプロトコル内のセキュリティ層」へと移りつつあり、これは推論である。

決済拡張をA2Aに載せる方法は、A2Aのextension機構そのものである。AgentCapabilities の中で AgentExtension（uri、description、required、params）として宣言し、クライアントは A2A-Extensions ヘッダーで有効化を求める。拡張はコアのデータ構造を変更できず、enum値を追加できず、metadataを通じてしか動作できない。互換性を壊す変更には新しいURIへの切り替えが必要で、対応していないバージョンに遭遇した場合は「MUST NOT fall back」とされる。a2a-x402（spec v0.1）はまさにこの種の拡張である。加盟店が payment-required を送り、クライアントが署名して payment-submitted を返し、加盟店はオンチェーンで決済した後に payment-completed を返す。

x402の取引件数は主に水増しによるものである。ChainalysisによればBaseチェーン上のx402取引は2026年第1四半期までに累計1億件を超えたが、2025年第4四半期の急増は「大半がmeme coin farmingによるもの」で、週次の継続率は87%から5%に落ち込んだ。Coinbaseは2026年4月末に約1.65億件、累計約5,000万ドルと主張しているが、これはベンダーの主張である。Artemisは95%超がプロトコルのシグナルまたはテストだとみており、実際のコマース取引額は1日あたり約2.8万ドルと推計するトラッキングサイトもある。

カードブランドとプラットフォームの実際のやり方は、「複数のプロトコルをすべて受け入れ、本人がその場にいる強力な認証を安全弁とする」というものである。OpenAIは2026年3月、ChatGPT内のInstant Checkoutを加盟店のAppsモデルに戻し、広報担当者は「Instant Checkout is moving to Apps」と述べた。Visaは2026-07-02、欧州ですでにエージェントが実際に購入を完了し、提携発行会社は30社を超え、取引はすべてPayment Passkeysで強力な顧客認証（SCA）を満たしていると発表した。責任の枠組みはなお空白である。Chargebacks911は、紛争と責任のインフラが「largely unaddressed」だと警告している。Taylor Wessingの分析によれば、EUの枠組みでは、顧客が設定した条件を超えたエージェントの購入は原則として無許可取引と認定される。Ant International、Visa、Mastercardは2026-09-10になってようやくKnow-Your-Agentの相互運用フレームワークの検討を始めた。EUのPSD3／PSRは、現時点で理事会が2026-10-29に第一読会の立場を採択した段階にとどまり、まだOfficial Journalに掲載されていない。理事会のPSRの理由書をキーワード検索しても、AIや自律エージェントに関する条項は見当たらない。米国CFPBにもエージェント決済に関するガイダンスはない。

学術研究は別の盲点も指摘している。Debiら（IEEE IMNS 2026）はAP2のショッピングエージェントにレッドチームテストを行い、間接・直接のprompt injectionによって商品の並び順を操作し、ユーザーの機微なデータを引き出せることを示した。これは、署名付きmandateでは署名より前の推論過程を守れないことを意味する。Jiangら（arXiv:2609.00060）はTamarinを用いてx402、MPP、ACP、AP2を形式手法で分析し、意図、委任権限、決済が複数の当事者に分散していることから生じるセキュリティ上の依存関係を指摘した。物流業界のエージェント化は現在MCPの路線を進んでいる。FlexportのMCPサーバーは、顧客のAIアシスタントが合意済みの料金でブッキングを行い、booking IDを取得できるようにしている。調査ノートでは、AP2やx402で運賃を決済した事例は一つも見つかっていない。

AIエージェント決済プロトコルの階層（2026-10-31時点）
層プロトコル主導者現状
チェックアウト層ACPOpenAI＋Stripe2026-03 にChatGPT Instant Checkoutは加盟店Appsへ移行、ACPは引き続き存続
チェックアウト層UCPGoogle＋Shopify二次情報によれば、ShopifyのUCPエンドポイントはMCPをトランスポート層としている
認可エビデンス層AP2 v0.2.0Googleが立ち上げ、2026-04-29 にFIDO Allianceへ寄贈紛争処理は仕様の範囲外
認可エビデンス層Verifiable IntentMastercard二次情報によれば 2026-03 にオープンソース化
マシン間マイクロペイメント層x402Coinbaseが立ち上げオンチェーンの件数は大半が水増し。実際のコマース取引額は1日あたり約2.8万ドルと推計
マシン間マイクロペイメント層MPPStripe＋Tempo二次情報によれば 2026-03 にTempoメインネットとともにローンチ

出典 AP2 v0.2 Specification| AP2 Flows| ap2-protocol.org| FIDO Alliance：GoogleによるAP2の寄贈| A2A Extensions| google-agentic-commerce/a2a-x402| Chainalysis：x402 agentic payments adoption| Forkast：x402の実際の取引量| presenc.ai：x402の採用状況トラッキング| Digital Commerce 360（2026-03-06）| Visa UK プレスリリース（2026-07-02）| The Paypers：Chargebacks911の警告| Taylor Wessing：Agentic AI in payments| TechNode（2026-09-10）| The Paypers：MPPのローンチ| Mastercard Developers：Agentic取引ガイド| EU理事会 PSR第一読会の立場に関する採決文書 ST 15154/26| Debi et al., Whispers of Wealth（IEEE IMNS 2026）| Jiang et al., A Formal Analysis of Agent Payment Protocols（arXiv:2609.00060）| SupplyChain247：FlexportのAIアシスタントによるブッキング

A2Aは今使われているのか？本番事例はあるのか？

2026-10-31時点で、調査ノートでは企業名が明示され、企業をまたぎ、計測結果のあるA2Aの本番事例は一つも見つかっていない。Linux Foundationは2026-04-09に150を超える支持組織と本番導入があると主張したが、利用者の名前は挙げていない。また、ある著者が2026-10-27に18の組織へ36件のリクエストを送ったところ、取得できた有効なAgent Card は0枚だった。

Linux Foundationの2026-04-09の1周年プレスリリースは、A2Aには150を超える支持組織があり、サプライチェーン、金融、保険、IT運用で本番導入されているとしているが、これはベンダーの主張である。プレスリリースは利用者を1社も名指ししておらず、プロセスや成果の指標も示していない。よく例として持ち出されるMicrosoft Agent Framework .NETの記事やGoogleの購買コンシェルジュcodelabは、いずれもサンプルコードであって導入報告ではない。Tyson FoodsはA2Aのサプライチェーン事例としてよく宣伝されるが、apis.ioによる同社のA2A Agent Card のスコアは0/8で、取引先に提供しているのは依然としてEDIとAPIである。

最も直接の反証は実測である。ある著者は2026年4月、公開レジストリからA2A対応をうたうエージェントを50件抽出したが、well-knownパスで有効なカードを提供していたのは約0〜2件にとどまり、taskに正しく応答したのは0件だった。同じ著者が2026-09-09に12の組織へ24件、2026-10-27に18の組織へ36件のリクエストを送った際も、取得できたカードはいずれも0枚だった。サンプルは著者が自ら選んだもので全数調査ではないが、方向性は一貫している。実際に動いているのは同一クラウドプラットフォーム内の相互運用で、AWS AgentCore、Microsoft Foundry、Google Agent Registryがそれにあたる。

マルチエージェントアーキテクチャそのものに関する実証も、組織をまたぐA2Aには不利である。MAST（NeurIPS 2025 Datasets & Benchmarks Track）は1,642件の実行トレースを分析し、14の失敗モードを、システム設計、エージェント間の不整合、タスク検証の3つの大分類にまとめた。論文中で7つの最先端オープンソースマルチエージェントシステムの失敗率は41%〜86.7%であった（著者は、異なるbenchmarkを直接比較することはできないと注意している）。Google ResearchやMITなどの著者による「Towards a Science of Scaling Agent Systems」はv1／v2とGoogleブログ版で180種類の構成をテストし、独立型マルチエージェントではエラーが17.2倍、中央調整型では4.4倍に増幅され、逐次推論タスクではすべてのマルチエージェント構成が39%〜70%性能を落とした。2026-04-08のv3は260種類の構成、6つのbenchmarkに拡張されたが、17.2倍と4.4倍という結論は維持されている。Anthropicのエンジニアリングブログ（査読付き論文ではない）は、同社のマルチエージェント研究システムがシングルエージェントのClaude Opus 4を90.2%上回る一方、token使用量は通常の会話の約15倍になると説明し、「すべてのエージェントが同じコンテキストを共有する必要がある、あるいはエージェント間の依存が多い」領域には向かないと明言している。組織をまたぐA2Aは、まさにこうした不利な条件をすべて備えている。双方はコンテキストを共有せず、共通の検証者もおらず、商取引のプロセス（価格照会→注文→決済→出荷）は逐次型である。これは推論である。

エンジニアリング面の空白は仕様面よりも多い。A2Aで次のエージェントに委任するとtraceが途切れる。Python SDKはローカルでspanを作るだけで、エージェント間でW3C Trace Contextを受け渡す標準の方法がない（Issue #2103）。コミュニティ版Rust SDKは7件のTCK失敗を報告したが、照合の結果、テストスイート自体の欠陥と判定された。同じ報告は、JS、Go、Java SDKが二つのバインディングでいずれも21/21合格だったとしている。消費者側のエージェントトラフィックもまだ小さい。HUMAN Securityの集計では、2025年のエージェントトラフィックは前年比7,851%増だったが、チェックアウトページで発生したのは2.3%にすぎない。二次情報が引用するCloudflare Radarの2026年8月のデータによれば、AIボットはHTMLリクエストの約7%を占め、そのうち「ユーザーに代わるリアルタイムの行動」は5.8%にとどまる。両者を掛け合わせると約0.4%になるが、この掛け算は推論であり、元データでは未確認である。Akamaiは、ECサイトが90%以上のAIボットを監視するだけにとどめている一方、詐欺型のエージェント活動が増えていると警告している。調査ノートでは、ChatGPT、Gemini、Claudeなどの個人向けエージェントがA2Aで一般企業のエージェントを呼び出している証拠は見つからなかったが、これは反証がないというだけで、公式に確認されたわけではない。

政府や国際機関によるヒアリングからは、需要が本物であることがうかがえる。OECD Artificial Intelligence Papers No. 65の16ページには、インタビューを受けた実務者がオープンなプロトコルを好み、A2Aなどのエージェント間通信プロトコルがマルチエージェント協調の重要な推進力になると述べる一方、単一ベンダーのエコシステムに囲い込まれることを懸念していると記録されている。

A2Aの実装状況：主張とエビデンスの対照（2026-10-31時点）
主張または事例実際に確認できたエビデンス評価
Linux Foundation：150超の組織、複数業界での本番導入プレスリリースは利用者を名指しせず、成果指標もないベンダーの主張
Tyson Foods のサプライチェーン事例apis.io の A2A Agent Card スコアは0/8。取引先には依然としてEDIとAPIを使用エビデンスが裏付けない
Microsoft Agent Framework、Google codelabサンプルコードであり、導入報告ではない本番事例ではない
公開レジストリでA2A対応をうたうエージェント50件（2026-04）有効なカードは約0〜2件、taskに正しく応答したのは0件第三者による実測
18組織・36リクエスト（2026-10-27）カード0枚（サンプルは自選）第三者による実測
同一クラウドプラットフォーム内の相互運用AWS AgentCore、Microsoft Foundry、Google Agent Registry が提供済み現在実際に稼働している形態

HowBridgeとは？ブランドとサービスのクイックアンサー

出典 Linux Foundation：A2A 1周年プレスリリース（2026-04-09）| Microsoft DevBlogs：A2A v1 in Agent Framework for .NET| Google Codelabs：A2A purchasing concierge| apis.io：Tyson Foods| heym.run：A2A vs MCP の実測| Cemri et al., Why Do Multi-Agent LLM Systems Fail?（NeurIPS 2025 D&B）| Kim et al., Towards a Science of Scaling Agent Systems（arXiv:2512.08296）| Google Research ブログ（2026-01-28）| Anthropic Engineering：How we built our multi-agent research system| A2A Issue #2103（traceの断絶）| a2a-rust PR #180（TCKの結果）| HUMAN Security：2026 State of AI Traffic| PaidHosting：AI agent traffic（Cloudflare Radarを引用）| Akamai プレスリリース| OECD Artificial Intelligence Papers No. 65

各国政府はAIエージェントをどう規制しているのか？A2Aに言及しているか？

2026-10-31時点で、台湾のデジタル発展部、シンガポールのIMDA、OECDの公式文書はすでにA2Aやマルチエージェントのリスクを名指しで取り上げているが、A2Aを対象に立法した国はない。台湾の「人工知能基本法」は民国暦115-01-14（2026-01-14）に公布・施行され、所管機関は国家科学及技術委員会（国科会）である。エージェントが誤った場合の責任分配は、第17条に基づく関連規範の整備を待つことになる。

台湾：「人工知能基本法」は全20条からなる。第3条は人工知能を「自律稼働の能力を備えたシステム」と定義しており、AIエージェントも含みうるが、条文に「エージェント（代理）」という語は現れない。第4条は人間の自律と監督、透明性と説明可能性、説明責任を含む七つの原則を掲げる。第16条はデジタル発展部が国際接続が可能なリスク分類の枠組みを推進すると定め、第17条は政府に高リスクAIの責任の帰属と帰責の条件を明確に定め、救済、補償または保険の仕組みを設けるよう求め、第18条は各機関に施行後2年以内に関連法規の調整を終えるよう求めている。デジタル発展部は第16条に基づき、民国暦115-07-07に「人工知能リスク分類フレームワーク」v1.0（数位策略字第1150015933号、即日発効）を公告した。そのリスク類型B6「AI自律エージェントの権限外行為」には、「マルチエージェントシステムでは、エージェント同士が相互に作動を引き起こすことで、開発者もユーザーも予期しない連鎖反応が生じ、人間が適時に介入して是正することが難しくなる可能性がより高い」と記されている。衛生福利部が民国暦115-05-29に通知した医療機関向け生成AIガイドラインは、AIエージェントシステムを「本ガイドラインの適用対象にはまだ含めない」と明記している。

台湾の既存の法律もエージェントの場面に適用される。「個人資料保護法」第4条は、委託を受けて個人データを収集、処理または利用する者は、同法の適用範囲内で委託した機関とみなすと定めており、個人データをエージェントに処理させても「AIがやったこと」を理由に責任を免れることはない。第21条は国際移転の制限を定めている。注意すべき点として、114-11-11に改正された複数の条文（第21条の新版と新設の第20-1条を含む）は公布済みだがまだ施行されておらず、施行日は行政院が定める。「電子署名法」はAIにもエージェントにも触れておらず、エージェントが代わって行った署名を本人の署名と推定できるかについては、法に明文の規定がなく、本記事でも確認できない。

中国：国家市場監督管理総局と国家標準化管理委員会は、2026年第22号国家標準公告により、2026-05-22にGB/Z 185.1～185.7-2026「人工知能 エージェント相互接続」シリーズ計7件の指導性技術文書（全体アーキテクチャ、ID コード、ID管理、エージェント記述、エージェント発見、エージェント間インタラクション、エージェントによるツール呼び出し）を承認・公布した。全国標準情報公共サービスプラットフォームでのステータスは「現行」と表示され、全文は2026-06-18に公開され、市場監督管理総局は2026-06-26にテーマ別の記者会見も開いた。公式文書が用いるプロトコル名はAIP（エージェント相互接続プロトコル）で、確認できた公式ページはいずれもA2AやMCPに言及しておらず、両者に互換性があるかどうかは確認されていない。2026-05-08に国家インターネット情報弁公室、国家発展改革委員会、工業情報化部が共同で発出した「エージェントの規範化応用とイノベーション発展に関する実施意見」は、AIPの普及、エージェント登録プラットフォーム、エージェントのデジタルIDを一体のものとして位置づけ、「エージェントが実行する操作はユーザーの認可範囲を超えてはならない」と求めている。この路線は、A2Aコミュニティの「公式のレジストリは提供しない」という方針とは異なる。

EU：AI Act（Regulation (EU) 2024/1689）は2024-08-01に発効し、汎用AIモデルの義務は2025-08-02から、一般適用と透明性の義務は2026-08-02から適用される。高リスクの義務は Regulation (EU) 2026/1744（2026-07-24 にOfficial Journalに掲載）によって延期され、附属書IIIは2027-12-02まで、附属書Iは2028-08-02まで延ばされた。PSD3とPSRは、理事会が2026-10-29に第一読会の立場を採択した段階で、欧州議会の第二読会を待っており、Official Journalには掲載されていない。

米国、シンガポール、英国：CISAとNSAなどファイブ・アイズの機関は2026-04-30／05-01に〈Careful Adoption of Agentic AI Services〉を公表し、アクセス権限を制限し、低リスクかつ機微でないユースケースから始めるよう推奨した。米国CFPBにはエージェント決済を対象とするガイダンスがなく、2025年の関連する解釈規則案は2025-05-15に撤回されている。シンガポールIMDAの「Model AI Governance Framework for Agentic AI」v1.5（2026-05-20公表、06-05更新）は第1.1.1節で、A2Aをエージェント間の通信に、MCPをエージェントとツールの通信に使うものとして名指しし、再帰型の委任と組織をまたぐIDが現在の欠落部分だと指摘している。英国CMAが2026-03-09に公表した（10-30更新）ガイダンスは「if an AI agent you use does something illegal, you are responsible」と明記しており、事業者は自ら使用するエージェントの違法行為について責任を負うことになる。英国ICOのエージェント型AIに関する意見募集は2026-11-20に締め切られる。

各地域の公式文書とA2A／AIエージェントの関係（原文を確認できたもののみ）
地域文書日付A2Aまたはエージェントとの関係
台湾「人工知能基本法」民国暦115-01-14 公布・施行第17条で高リスクAIの責任の帰属を明確化するよう要求。「エージェント」には言及なし
台湾デジタル発展部「人工知能リスク分類フレームワーク」v1.0115-07-07リスクB6「AI自律エージェントの権限外行為」
台湾デジタル発展部「公共部門人工知能活用リファレンスハンドブック」V1.0民国暦115-01-28（文書記載）14ページにA2Aの小節
中国GB/Z 185.1～185.7-2026「人工知能 エージェント相互接続」2026-05-22 承認・公布公式のプロトコル名はAIP。A2Aとの互換性は未確認
EURegulation (EU) 2026/17442026-07-24 掲載AI Act の高リスク義務を 2027-12-02／2028-08-02 まで延期
EUPSD3／PSR 理事会の第一読会の立場2026-10-29Official Journal に未掲載。PSRの理由書にエージェント関連条項は見当たらない
米国NIST〈Design Tenets for Agent Identity Management Systems〉2026-10-27エージェントIDに関する10条の設計原則（ブログ）
シンガポールIMDA エージェント型AIガバナンスフレームワーク v1.52026-05-20§1.1.1 でA2AとMCPを名指し
英国CMA 消費者法とAIエージェントに関するガイダンス2026-03-09事業者は使用するエージェントの違法行為に責任を負う
国際OECD AI Papers No. 652026-0916ページ：実務者はA2Aをマルチエージェント協調の推進力とみなす

出典 全国法規データベース：人工知能基本法| デジタル発展部の公告：人工知能リスク分類フレームワーク| デジタル発展部：人工知能リスク分類フレームワーク v1.0（PDF）| デジタル発展部：公共部門人工知能活用リファレンスハンドブック（PDF）| 衛生福利部：医療機関における生成AI活用ガイドライン| 全国法規データベース：個人資料保護法| 全国法規データベース：電子署名法| 国家標準化管理委員会：2026年第22号国家標準公告| 全国標準情報公共サービスプラットフォーム：GB/Z 185.1-2026| 全国標準情報公共サービスプラットフォーム：全文公開の通知| 国際科学技術イノベーションセンター：エージェント相互接続標準化の発表会| 国家市場監督管理総局：転載記事| 中国網信網：エージェントの規範化応用とイノベーション発展に関する実施意見| European Commission：AI Act regulatory framework| European Parliament：Digital Omnibus on AI| EU理事会 PSD3 採決文書 ST 15152/26| EU理事会 PSR 採決文書 ST 15154/26| CISA：Secure adoption of agentic AI| Federal Register 2025-08646（CFPBによる撤回）| IMDA：Model AI Governance Framework for Agentic AI v1.5| GOV.UK：CMA complying with consumer law when using AI agents| ICO：Agentic AI call for evidence| OECD Artificial Intelligence Papers No. 65

A2A v1.1では何が補われるのか？まだ答えの出ていない問題は何か？

A2A v1.1の8テーマは、2026-06-25にTSCで5対0の採決により可決された。ストリームの再開、冪等性、プッシュ設定、スキル選択、認証方式の発見、タスク履歴、複数ターンのやり取り、双方向ストリーミングを対象とするが、2026-10-31時点でリリース日は決まっていない。エージェントID、委任、課金など最も議論の盛んな論点はいまだ決着していない。

Issue #1942は41件の論点をv1.1の8テーマに統合したもので、タスクをまたぐエージェントの記憶（#893）は追跡対象に含まれていない。テーマ一覧以上に方向性を物語るのは、コメント数の多い論点である。#1672 Agent Card におけるエージェントIDの検証（コメント約658件）、#1829 Ed25519とRFC 9421によるメッセージ署名、#2028 actor-chain による委任、#2121 コストと予算の受け渡し、#1815 HTTP 402で「支払いが必要」を示す提案などである。これらはいずれも信頼と商取引の問題であり、新設されたextensionのガバナンスプロセスも踏まえ、調査ノートはこれらがコア仕様の変更ではなく拡張として登場する可能性が高いと判断している。これは推論である。

「個人向けエージェントが企業のエージェントをどう見つけるか」について、現時点で導入済みのオープンな答えはない。A2Aの公式ドキュメントは、キュレーション型のレジストリはA2Aの範囲外だと明言している。Discussion #741のAgent Registry提案は長く停滞しており、レビュー担当者は「提供者自身が登録項目を管理する」という前提に疑問を呈している。ドメインからエージェントを見つける方法について、IETFには互いに競合する個人ドラフトが4本ある。DNS-AID（SVCBレコードで /.well-known/agent-card.json を指す）、AID（_agent TXT レコードを参照）、ADP、DANで、いずれもワーキンググループには採択されていない。2026年7月のlandscapeドラフトも、名前空間の調整が必要だと指摘している。MCP側のMCP Registryは、2025年9月から現在までプレビュー版のままである。

組織をまたぐ監査と責任についても同様に枠組みがない。A2Aの仕様には、SHOULDレベルの認証失敗の記録とレート制限の要件しかなく、OpenTelemetry GenAIセマンティック規約の安定度については情報源ごとに見解が食い違う。現在のツールで保存できる最小の監査単位は、おおむね自分の側の taskId と contextId、相手の Agent Card 署名のフィンガープリント、相手が提示したtokenの act 委任チェーンであり、双方がそれぞれ保存して後で突き合わせることになる。これは推論である。調査ノートでは、「相手のLLM予算を使い果たさせる」ことを狙ったdenial-of-walletの実証研究も見つかっていない。

  • #1986 ストリームの再開：切断後に中断箇所から続行できる
  • #1987 冪等性：リクエストを再送しても重複して実行されない
  • #1988 プッシュ設定：webhookの設定と管理
  • #1989 スキル選択：呼び出し側が使うスキルをどう指定するか
  • #1990 認証方式の発見：どの認証方式を使うべきかを事前に知る
  • #1991 タスク履歴：過去のタスクの記録を照会する
  • #1992 複数ターンのやり取り：双方が問いかけ合う際のセマンティクス
  • #1995 双方向ストリーミング：双方が同時にデータをストリーミングする

出典 A2A Issue #1942（v1.1テーマ）| A2A issues（コメント数順）| A2A：Agent discovery| A2A Discussion #741| IETF：DNS-AID ドラフト| IETF：DAWN discovery landscape ドラフト| MCP Registry preview（2025-09-08）| A2A Specification §13.4| GreptimeDB：OpenTelemetry GenAI semantic conventions

企業は今A2Aを導入すべきか？

2026-10-31時点のエビデンスに基づけば、企業のA2A導入は「まず読み取り専用、まず同一プラットフォーム、企業をまたぐ書き込みは見送り」とするのが妥当である。同一クラウドプラットフォーム内のエージェント相互運用は試してよいが、企業をまたぐ注文・決済系のA2Aは、ID、委任、責任の枠組みが固まるまで開放は勧められない。逐次型タスクではすべてのマルチエージェント構成が39%〜70%性能を落とすためである（arXiv:2512.08296 v1／v2のデータ）。

A2Aの現状は初期のHTTPによく似ている。形式は標準化されたが、信頼の層はそれぞれが補わなければならない。違いは、今回は呼び出される側が自ら推論し、しかも相手に説得されうることである。そのためボトルネックは技術ではなく「エージェントの行為に誰が責任を負うのか」にあり、この問題は現在IETF（ID）、FIDO Alliance（支払いの意図）、カードブランド（紛争）、各国の規制当局に分散していて、A2AのTSCの手には負えない。ここから推論すると、今後数年で企業間のエージェント相互運用として最もありうる形は「A2Aの外殻で、決定論型のツール呼び出しを包む」ものである。呼び出される側は表向きエージェントだが、中身は実はAPIで、本当の推論は自社の信頼境界の内側でのみ行われる。

政府のガイダンスもこの方向と一致している。CISAとNSAなどファイブ・アイズの機関は、低リスクかつ機微でないユースケースから始め、アクセス権限を制限するよう推奨している。シンガポールIMDAのフレームワークは「人が実質を伴う責任を負うこと」と技術による統制を中核の観点に据えている。台湾のデジタル発展部はマルチエージェントが互いに作動を引き起こす連鎖反応をリスクB6に挙げ、英国CMAは事業者が自ら使用するエージェントの違法行為に責任を負うと明言している。

下表は、一般企業の導入の選択肢をエビデンスの強さに応じて分類したものである。表中の「実施」は現在のエビデンスのもとでリスクが低く見返りが明確なもの、「実施可」はコストは低いが計測された事例がないものを指す。「見送り」と「実施しない」にはいずれも理由を付しており、トリガー条件が現れた時点で改めて評価する。

企業のA2A導入推奨の分類（2026-10-31）
推奨アクション理由
実施認可を自前で実装し、既定で拒否する。SDKの既定値に依存しない規範は認可を実装が決めるとしている。a2a-javaはかつて既定で読み取り認可を行っていなかった（CVE-2026-111764）
実施Agent Card のフィールドとプッシュ通知URLはすべて信頼できない入力として扱い、プッシュ通知URLではプライベートIPを拒否するカードはヘッダー名を指定できる。a2a-javaとa2a-pythonはいずれもプッシュ通知のSSRFを出している
実施taskId、contextId、呼び出し元のID、traceparent を記録するエージェントをまたぐとtraceが途切れ（Issue #2103）、事後の突き合わせは双方それぞれの記録に頼るしかない
実施SDKのバージョンを固定し、セキュリティアドバイザリを購読する2026年8〜10月に公式SDKのCVEが複数出ており、修正がプラットフォームの差異で回避されたこともある
実施可同一クラウドプラットフォーム内のエージェント相互運用（AWS AgentCore、Microsoft Foundry、Google Agent Registry）現在実際に稼働している形態で、双方の信頼境界が同じ
見送りSDKをまたいだ Agent Card 署名の検証に依存するIssue #2122 で正規化が一致しない。署名が証明するのは完全性だけで、IDは証明しない
実施しない外部エージェントに顧客の代わりの注文、データ変更、支払いをさせるAP2は責任を割り当てず、カードブランドにはエージェント専用の紛争ルールがなく、PSRにエージェント関連条項は見当たらない
実施しないA2Aのために組織をまたぐマルチエージェントのバックエンドを自前で構築する独立型マルチエージェントではエラーが17.2倍に増幅。逐次タスクでは39%〜70%性能が低下

AIクイックアンサーをもっと見る：転送サービス、関税分類、越境ECのQ&A

出典 Kim et al., Towards a Science of Scaling Agent Systems（arXiv:2512.08296）| CISA：Secure adoption of agentic AI| IMDA：Model AI Governance Framework for Agentic AI v1.5| デジタル発展部：人工知能リスク分類フレームワーク v1.0（PDF）| GOV.UK：CMA complying with consumer law when using AI agents| GitHub Advisory GHSA-qw47-mcm5-934w| A2A Issue #2103| A2A Issue #2122| AP2 v0.2 Specification

越境EC・物流事業者は今A2Aにどう備えるべきか？

2026年に越境EC・物流事業者が最も投資すべきなのはA2Aエンドポイントではなく、Webページの構造化データと、決定論型かつ読み取り専用のMCPツールである。二次情報が引用するCloudflare Radarの2026年8月のデータでは、AIボットはHTMLリクエストの約7%を占め、そのうちユーザーに代わるリアルタイムの行動は5.8%にすぎない。また、Flexportが顧客のAIアシスタントにブッキングさせる仕組みもMCPを使っている。

越境EC・物流の中核となる照会――運賃はいくらか、税金はいくらか、この商品の関税分類番号と輸入規制は何か――は、もともと決定論型の計算であり、外部エージェントが最も必要とし、かつ最も誤りにくい種類のサービスである。Anthropicのエンジニアリングブログによれば、ツールの説明文を書き直しただけで、その後のエージェントのタスク完了時間が40%短縮された。OpenAIがInstant Checkoutを加盟店Appsに戻した経験は、取引が最後には加盟店自身のフローに戻ることを示している。したがって事業者の準備の順序は、まずWebページと構造化データを読み取れるようにし、次に決定論型のツールをMCP化し、ツールの応答に続行用URLを付けて取引を自社のフローに戻し、最後にA2Aのプレースホルダーを検討する、となる。

A2Aのプレースホルダーカードとは、/.well-known/agent-card.json にカードを公開し、skills を既存の見積もり、税金、手続きなどの決定論型ツールに対応させ、裏側ではLLMを動かさずプログラムを直接呼び出すものである。この方法は低コストで「オプション価値」に属するが、これによって中小企業がトラフィックや売上を得たという計測事例は現時点でなく、推論にとどまる。本当にA2Aエンドポイントを開放するなら、少なくとも次のことを実施する必要がある。読み取り専用のスキルだけを開放する、相手のカードのいかなるフィールドも信頼しない、プッシュ通知URLではプライベートIPを拒否する、taskId、contextId、呼び出し元のID、traceparent を記録する。

HowBridgeの現在の取り組み（以下はいずれもHowBridgeの開発者ページで確認できる）：HowBridgeはAPIキー不要・OAuth不要の公開MCP（https://0523.tw/mcp/public）を提供しており、読み取り専用かつ冪等な8つのツールを備える。対象は、HowBridgeのブランドとサービスの紹介、中国→台湾の転送サービス運賃試算（海上エクスプレス／航空便）、台湾の輸入税試算、商品名からのCCC関税分類候補の検索、CCC関税分類の税率と輸入規制、台湾国内配送のサイズ超過料金、転送サービスの手続きと簡易申告の規定である。上限はIPごとに毎分120回で、公式MCP Registryにも登録済み（名称 tw.0523/lucky-public）。運賃試算の応答には続行用URL（continue_url）が付いており、ユーザーを公式サイトに戻して手続きを続けられる。会員MCP（https://0523.tw/mcp）はOAuth 2.1で認可し、読み取り専用の6つのツールを提供する。読み取れるのは認可した会員本人の請求書、荷物、事前登録、税額通知書、輸入申告書のみで、既定の上限は毎分60回、毎日5,000回である。HowBridgeの開発者ページに現在掲載されている入口は会員データAPI、会員MCP、公開MCPで、A2Aエンドポイントはない。本記事はHowBridgeがA2Aに対応済みであることを意味するものではない。

AIアシスタントに中国から台湾へ送る際のコストを見積もらせたい場合は、Web版の転送サービス運賃試算、輸入関税計算ツール、関税分類検索をそのまま使える。これらのツールと公開MCPは同じ計算ロジックを使用している。試算は参考値であり、運賃は倉庫入庫時の計測後の請求書、税額は税関の査定が基準となる。

越境EC・物流事業者のA2A準備の分類（2026-10-31）
優先順位アクション推奨理由
1Webページのコンテンツと schema.org 構造化データを継続して強化する実施エージェントがWebサイトに接する主な方法は依然として閲覧とクロールであり、ユーザーに代わるリアルタイムの行動のトラフィック比率はごく小さい
2見積もり、税金、関税分類などの機能を決定論型かつ読み取り専用のMCPツールにし、ツールの説明文を磨き込む実施ツールの説明文の書き直しでエージェントの完了時間が40%短縮。物流業界のエージェントによるブッキングはMCP経由
3ツールの応答に続行用URLを付け、取引を自社のフローに戻す実施Instant Checkout はすでに加盟店Appsに戻り、取引は加盟店自身のページに戻っている
4会員データのインターフェースはOAuthを維持し、クライアントごとのレート制限と監査ログを加える実施規範は認可を実装に委ねている。Akamaiは詐欺型エージェントの増加を警告
5/.well-known/agent-card.json にプレースホルダーカードを公開し、裏側は決定論型のプログラムだけにつなぎ、LLMは動かさない実施可（優先度低）低コストでオプション価値に属する。計測事例はまだない（推論）
6A2Aエンドポイントを開放する条件付きで実施読み取り専用のみ開放。カードのフィールドを信頼しない。プッシュ通知URLではプライベートIPを拒否。完全に記録する（公開済みのSSRFとfail-openのCVEに対応）
7Agent Card に署名する見送り、または単一のSDKのみ使用Issue #2122 でSDK間の正規化が一致しない
8外部エージェントに注文、住所変更、支払いを開放する実施しない責任の枠組みが未確定。逐次型タスクではマルチエージェントが39%〜70%性能低下
9A2Aのためにマルチエージェントのバックエンドを自前で構築する、またはAP2／x402に接続して運賃を受け取る実施しないx402の実際のコマース取引量はごく小さい。運賃決済の事例は見当たらない

HowBridge開発者プラットフォーム：公開MCPと会員MCP ・ 転送サービスMCPチュートリアル：ClaudeやChatGPTで運賃と税金を調べる ・ 転送サービス運賃試算：中国から台湾への海上エクスプレス・航空便の料金 ・ 輸入関税計算ツール：関税、営業税、貨物税の試算 ・ 関税分類検索：中国語の品名からCCCコードと税率を調べる

出典 PaidHosting：AI agent traffic（Cloudflare Radarを引用）| HUMAN Security：2026 State of AI Traffic| SupplyChain247：FlexportのAIアシスタントによるブッキング| Anthropic Engineering：How we built our multi-agent research system| Digital Commerce 360（2026-03-06）| Akamai プレスリリース| A2A Specification| HowBridge開発者プラットフォーム（公開MCP・会員MCPの説明）

越境EC・物流事業者がAIエージェント相互運用に備える5つのステップ

1まずWebページを読み取れるようにする

価格、所要日数、ルールなどの重要な事実をサーバーが直接出力するHTMLに記載し、schema.org の構造化データを補う。エージェントがWebサイトに接する主な方法は依然として閲覧とクロールである。

2決定論型の機能をMCPツールにする

見積もり、税金、関税分類などの照会を読み取り専用かつ冪等なMCPツールにし、ツールの説明文には入力の単位と制約を明記し、応答には続行用URLを付けてユーザーを自社のフローに戻す。

3会員データはOAuth経由とし、レート制限をかける

個人データに関わるインターフェースはOAuthによる認可のみとし、本人のデータだけを返し、クライアントごとのレート制限と監査ログを加える。

4A2Aのプレースホルダーカードを検討する

様子を見たい場合は、決定論型ツールにだけ対応し裏側でLLMを動かさないカードを /.well-known/agent-card.json に公開し、公開前にプッシュ通知URLとカードのフィールドの入力検証を確認する。

5四半期ごとに再テストし、トリガー条件を待つ

四半期ごとに同業者やプラットフォーム10〜20件にwell-knownリクエストを送る。名指しのパートナーからの書面による要請、v1.1の確定、責任の枠組みの登場のいずれかがあるまでは、注文と決済は開放しない。

用語解説

A2A（Agent2Agent）
異なる組織・異なるフレームワークに属するAIエージェント同士が能力を発見し、タスクを委任し、結果を交換するためのオープンプロトコル。2025-06からLinux Foundationが管理している。
MCP（Model Context Protocol）
AIアシスタントが外部のツールやリソースを呼び出すためのオープンプロトコル。推論は呼び出し側のLLMが制御し、ツールschemaは呼び出し側に対して透明である。
Agent Card
A2Aエージェントの公開記述ファイル。スキル、インターフェース、認証方式を宣言し、慣例として /.well-known/agent-card.json に置く。署名は任意。
Task（タスク）
A2Aにおける1回の協働の作業単位。taskId はサーバーが生成し、提出、処理中、入力が必要、認可が必要、完了、失敗などの状態を持つ。
Extension（拡張）
A2Aのコアの外側に機能を追加する仕組み。URIで識別し、クライアントは A2A-Extensions ヘッダーで有効化する。コアのデータ構造は変更できない。
AP2（Agent Payments Protocol）
SD-JWT mandate によって、ユーザーがエージェントに与えた支払いの認可を記録するプロトコル。v0.2.0は2026-04-28にリリースされ、2026-04-29にFIDO Allianceへ移管された。
x402
HTTP 402「支払いが必要」ステータスコードを基盤とするマシン間マイクロペイメントプロトコル。主にBaseチェーン上で決済される。
RFC 8693 token exchange
OAuth 2.0のトークン交換の標準。act claim で委任経路を記録し、may_act で次のホップを限定できる。
SSRF（サーバーサイドリクエストフォージェリ）
サーバーに攻撃者が指定したアドレスへリクエストを送らせる脆弱性。A2Aのプッシュ通知webhook URLはよくある侵入口である。
TSC（技術運営委員会）
A2Aの意思決定機関。9議席で1社1議席、議案はGitHub issue上でgitvoteにより採決される。
AIP（エージェント相互接続プロトコル）
中国のGB/Z 185-2026シリーズ国家標準文書で使われているエージェント相互接続プロトコルの名称。A2Aと互換性があるかどうかは確認されていない。

よくある質問

A2Aプロトコルは誰が開発したのか？

A2Aは2025年4月にGoogleが発表し、2025-06-23にLinux Foundationへ移管された。創設メンバーにはAWS、Cisco、Microsoftなど7社が含まれる。現在は9議席の技術運営委員会が意思決定を行い、2026年8月にはMCPと同じ財団であるAAIFに加わった。

A2Aの最新バージョンは？

2026-10-31時点で、A2Aの現行版はv1.0.1で、2026-05-26にリリースされ、2026-03-12のv1.0.0とワイヤー互換である。v1.1は8テーマが可決されたが、リリース日はまだ決まっていない。

A2AとMCPは併用できるのか？

できる。A2A公式の例では、エージェント同士はA2Aで協働し、各エージェントはMCPで自分のツールを操作する。両者はそれぞれエージェント間とエージェント‐ツール間を担っており、互いに排他ではない。

A2Aにはどんな既知のセキュリティ脆弱性があるのか？

2026年8〜10月に最初の公式SDKのCVEが出ており、a2a-javaが既定で読み取り認可を行わない問題（CVE-2026-111764、CVSS 7.5）、a2a-pythonのプッシュ通知SSRF（CVE-2026-90790）などがある。さらに学術研究では、規範に準拠していても悪用できるプロトコル層の脆弱性が11件見つかっている。

AIエージェントは自分でカード決済できるのか？

技術上はできる。Visaは2026-07-02、欧州ですでにエージェントが購入を完了したと発表したが、取引では依然としてPayment Passkeysでカード会員本人が強力な認証を行っている。AP2の仕様は紛争時の責任を割り当てておらず、EUのPSRもまだOfficial Journalに掲載されていない。

台湾にはAIエージェントを規制する法律があるのか？

台湾の「人工知能基本法」は2026-01-14に公布・施行されたが、「エージェント」には触れていない。デジタル発展部のリスク分類フレームワークv1.0は「AI自律エージェントの権限外行為」をリスクB6に挙げており、責任の帰属は第17条に基づく関連規範を待つことになる。

HowBridgeはA2Aに対応しているのか？

HowBridgeの開発者ページに現在掲載されているのは会員データAPI、会員MCP、APIキー不要の公開MCPで、A2Aエンドポイントはない。公開MCPでは運賃、輸入税、CCC関税分類などの読み取り専用の試算ツールを提供している。

中国のエージェント相互接続国家標準はA2Aと同じなのか？

断定はできない。GB/Z 185.1～185.7-2026の計7件は2026-05-22に承認・公布され、公式のプロトコル名はAIPである。確認できた公式ページはA2AにもMCPにも言及しておらず、両者に互換性があるかどうかは確認されていない。

主要データ

A2Aの現行版 v1.0.1 2026-05-26 リリース（A2A CHANGELOG）
TSCの議席数 9議席 1社1議席（A2A GOVERNANCE.md）
GitHubリポジトリ数：MCP 対 A2A 40,675 対 622 mcp-server と a2a-protocol トピック（gravity.fast）
実測で取得できた有効な Agent Card 0枚 2026-10-27 に18組織へ36リクエスト（heym.run、サンプルは自選）
a2a-java CVE-2026-111764 CVSS 7.5 既定で読み取り認可を行わない（GitHub Advisory）
A2ABreak が発見した新たな脆弱性 11件 規範に準拠したまま悪用可能（arXiv:2609.10871）
逐次タスクでのマルチエージェントの性能低下 39%–70% arXiv:2512.08296 v1／v2 と Google ブログ（180種類の構成）
中国のエージェント相互接続国家標準文書 7件 GB/Z 185.1～185.7-2026、2026-05-22 承認・公布

A2Aの主な出来事

  1. GoogleがA2Aを発表、パートナーは50社超（二次情報）
  2. A2A 0.2.2：互換性を壊すJSON-RPCへの整合、extensionsを追加
  3. Linux FoundationがA2Aプロジェクトの引き継ぎを発表
  4. A2A 0.3.0：agent.json を agent-card.json に改名、カード署名とmTLSを追加
  5. IBM ACPがA2Aに統合され、ACPは開発終了
  6. 台湾の「人工知能基本法」が公布・施行
  7. A2A v1.0.0 リリース（2026年1月とする論文もある）
  8. AP2 v0.2.0 リリース。翌日GoogleがAP2をFIDO Allianceに寄贈
  9. 中国 GB/Z 185.1～185.7-2026 エージェント相互接続シリーズ7件が承認・公布
  10. A2A v1.0.1 リリース
  11. TSCが5対0でv1.1の8テーマを可決
  12. デジタル発展部が「人工知能リスク分類フレームワーク」v1.0を公告、リスクB6を記載
  13. MCP 2026-07-28版がステートレスに変更、Tasksは公式拡張へ移行
  14. AAIFとAxiosが記すA2AのAAIF加入日
  15. A2A公式ブログが記すAAIF加入日（08-17と併記）
  16. 公式 a2a CLI をリリース
  17. NISTがエージェントID管理システムの10条の設計原則に関するブログを公表
  18. EU理事会がPSD3／PSRの第一読会の立場を採択（Official Journalには未掲載）

継続して追跡しているシグナル

  • 名指しのB2Bパートナー（ECプラットフォーム、運送会社、倉庫事業者、通関業者）が書面でA2A連携を要請すること。2026-10-31時点で組織をまたぐA2Aに名指しの事例はまだなく、これが最も強いシグナルとなる。
  • ChatGPT、Gemini、Claudeが、A2Aで第三者の加盟店エージェントを呼び出すと公式に発表すること。現時点で3社ともそうしておらず、Anthropicもまだネイティブ対応していない。
  • A2A v1.1が正式リリースされ、認証方式の発見（#1990）と冪等性（#1987）を含むこと、またはエージェントID・委任関連の拡張が正式に確定すること。
  • Issue #2122 がクローズされ、TCKの署名テストベクターがPython、JS、Goの3つのSDKすべてで合格すること。
  • カードブランドがエージェント専用のchargeback理由コードを公表すること、またはEUのPSD3／PSRが欧州議会の第二読会を経てOfficial Journalに掲載され、エージェント関連条項が盛り込まれること（2026-10-31時点では理事会が第一読会の立場を採択したのみで、PSRの理由書にエージェント関連条項は見当たらない）。
  • Google Agent Registry、Microsoft Agent 365、MCP Registry が組織をまたぐ公開登録を開放すること、またはDNS-AIDなどのドラフトがIETFのワーキンググループに採択されること。
  • 中国のGB/Z 185シリーズ（AIP）とA2Aの互換性や実装が公開されること、またはエージェント登録プラットフォームが稼働し、中台間の越境協業先が採用を始めること。
  • 台湾が「人工知能基本法」第17条に基づいて高リスクAIの責任の帰属に関する規範を定めること、または「個人資料保護法」の114-11-11改正条文の施行日が行政院によって定められること。
  • A2AのTSCがガバナンス文書に従い、設立から18か月（およそ2026年12月）後に構成を変更すること。
  • 四半期ごとにwell-knownリクエストで同業者やプラットフォーム10〜20件を再テストする。取得できる有効な Agent Card が0枚のままである限り、追加投資する理由はない。

本記事で言及した組織と標準

参考資料

政府・公共機関の文書

学術論文

仕様・業界の情報源

最終更新 初版公開

本記事は技術調査のまとめであり、法律、セキュリティ、投資に関する助言ではない。仕様と法規は各機関・各プロジェクトの最新の発表に従うこと。

転送を始めませんか？

HowBridge の会員に無料登録して、海外の倉庫住所と14言語サポートをすぐにご利用ください。

無料で登録

📦 人気のルートガイド

🛒 マーケットプレイス購入ガイド

📋 税関・規制

🏛️ 公的機関の情報源

🔎 人気商品の関税

🚚 転送サービスと送料比較

🧮 通関の流れと税金計算

⚠️ 禁制品と検査規制

💳 支払い・営業税・正式通関

L
HowBridge Logistics の税関および配送の専門家
HowBridge（好運器資訊有限公司）（台湾統一編号 57151105、2017年8月設立）は、中国大陸から台湾への越境集運（混載輸送）サービスを提供しています。通関手続きは AEO 認定を受けた提携通関業者と連携して行います。14言語のカスタマーサポート、関務署の CCC 関税データとの同期、受取人の EZWay 実名認証の支援にも対応しています。 当社の独自集計（2026-08-01～2026-09-30）：海上輸送の通関申告 692 件のうち 97.8% が24時間以内に税関の許可を取得。中国発・台湾着の海上クイック便 774 件（配送業者の受領サイン完了分）では、中央値は 6 日、90% が 9 日以内でした。内容は編集部が財政部関務署の公告および現行法令をもとに整理したものです。 チームについて→