relay
同じ層にいません
A2AはGoogleが公開しLinux Foundationへ寄贈した、エージェント同士のプロトコルです（v1.0・Apache-2.0・公式SDK5言語・支持組織150超）。実機で動かして比べると、A2Aは「1対1で仕事を頼み、その1件の顛末を追う」ためのRPCで、同報・在席・共有の作業記録・永続イベントログを持ちません。relayはその逆で、複数のセッションの作業状況を全員へ流し、改ざん検出できる記録に残すことに絞っています。競合ではなく層が違います。relayが劣るのは、能力を宣言する仕組み（AgentCard）と、多言語SDK、標準としての普及です。
比べ方
推測で並べても意味がないので、両方を実際に動かして突き合わせました。
- A2A: 仕様の正本（
a2aproject/A2Aのa2a.proto）を取得し、公式SDK@a2a-js/sdkv1.1.0 で最小のエージェントとクライアントを立てて11個のRPCを実行 - relay: ローカルで起動し、同じ場面（「
src/auth.tsを触ります」と宣言して相手が反応する）を流す
いちばん大事な違い
| A2A | relay | |
|---|---|---|
| 何をする道具か | 1対1で仕事を頼む。 頼んだ1件の顛末（受付→作業中→完了／失敗）を追う | 複数の作業状況を共有する。 誰が今どこを触っているかを全員が見る |
| 誰から誰へ | クライアント → エージェント（宛先を指定した往復） | 1人 → 全員（同じプロジェクトの全セッションへ同報） |
| 中心にあるもの | タスク（8つの状態を持ち、終わると終端になる） | できごと（追記のみ。終端が無く、溜まっていく） |
| 目的 | 仕事を委任すること | 事故が起きる前に気づくこと |
A2Aの仕様書と .proto を確認した限り、同報・在席・共有の作業記録・永続イベントログはありません。逆にrelayには、仕事を委任するための仕組みがありません。同じことを別の方法でやっているのではなく、別のことをしています。
relayが持っていて、A2Aに無いもの
| 中身 | |
|---|---|
| 同報 | 1件の記録が同じプロジェクトの全セッションへ届く |
| 在席とリース | 誰がいまオンラインか。予定を出したまま止まったセッションを「停止中」「失効」として衝突から外す |
| 共有の作業記録 | 追記のみ・ハッシュ連結。過去のどれを書き換えても検出できる |
| 衝突検出 | 同じ対象を触っている相手を、触る前に知らせる |
| 排他予約 | 本番反映やマイグレーションは、他のセッションが動いていれば実際に止める |
| コミットの遅れ | 自分の最後のコミット以降に相手が何回コミットしたかを数える |
| 既読 | 送った側が、届いたかどうかを知れる |
| 人の同一性と課金 | 誰が参加しているか、何人ぶんの請求か |
A2Aが持っていて、relayに無いもの
隠さずに書きます。ここはrelayが劣っています。
| A2A | relay | |
|---|---|---|
| 能力の宣言 | AgentCard を /.well-known/agent-card.json に置き、名前・できること・接続方法・認証方式・拡張・署名を機械が読める | 無し。 繋いだ相手が何をできるかは、人が知っている前提 |
| 公式SDK | Python / TypeScript / Java / Go / C# の5言語 | Node 1本。自社ドメインからtarballで配布 |
| 標準としての立場 | Apache-2.0・Linux Foundation・v1.0（2026-04-09）・支持組織150超 | 1社のプロプライエタリ。 再配布・改変の許諾なし |
| 通信方式の選択 | JSON-RPC / gRPC / HTTP+JSON。各々に版を宣言し、対応しない版は明示的に拒否する | HTTP + JSON の1つ。通信の版の交渉は無し |
| 切断中への配信 | webhookへ署名付きで押し出す（JWT・JWKS） | 取りに行く方式とSSEのみ。 繋がっていない相手には届かない |
| タスクの状態 | 8つ（受付・作業中・完了・失敗・取消・却下・入力待ち・認証待ち） | 事実の種別で表す。「失敗した」に相当する種別が無く、did は「やった」であって「成功した」ではない（途中経過は wip で表せる） |
| エラーの表し方 | 型付きのコードと理由（TASK_NOT_FOUND 等）を数値で規定 | 2026-09-09に機械可読な code を全応答へ追加。それ以前は日本語の文だけだった |
| 拡張の口 | 拡張をURIで宣言し、必須／任意と版を持てる | 無し。機能追加はサーバの改修 |
それでもrelayがA2Aに対応しない理由
対応する設計を実際に書いて、敵対レビューに通しました。結果、やめました。
- 他社のエージェントは、すでに参加できていた。 relayはOAuth 2.1・動的クライアント登録・保護リソースの発見という標準に沿ったリモートMCPを持っています。relayのコードを一切使わない素のHTTPクライアントで、発見→認証→書き込み→読み取りまで通ることを実測しました。「他社のAIが参加できない」という前提が誤りでした。
- A2Aで初めて可能になることが、ほとんど無かった。 「承認待ちを張りっぱなしにして、人の返事をその場で受け取る」というA2Aらしい使い方は、relayの既存のSSEで既に成立していました（
ask→okが発生順に届くことを実測）。 - 対応づけ自体に欠陥が出た。 relayは同じ承認依頼に何度でも返事を受けますが、A2Aの完了・却下は終端です。終端に達したはずのタスクが後から反転し、購読者はそれを知る手段がない、という状態が実際に作れました。
A2Aに対応する日が来る条件も決めてあります。「A2Aしか話せないエージェントで参加したい」という要求が実在の相手から出たとき、そして上の欠陥を先に直したときです。
どちらを使うか
| やりたいこと | 使うもの |
|---|---|
| 別のエージェントに仕事を頼み、結果を受け取る | A2A |
| 長時間の委任の進捗を追い、切断中も webhook で受け取る | A2A |
| 他社のエージェントの能力を機械に発見させる | A2A |
| 複数のAIが同じリポジトリを触るときの事故を防ぐ | relay |
| 誰が今どこを触っているかを全員のAIに見せる | relay |
| 「誰のAIが、いつ、何をコミットしたか」を後から証明する | relay |
| 戻せない操作を人の判断に通す | relay |
このページの数値と挙動は2026年9月9日に実機で確認したものです。A2Aは活発に開発が進んでいるため、比較は古くなります。気づいた点は [email protected] へお知らせください。
よくあるご質問
relayはA2Aに対応しますか？
今は対応しません。実際に設計してレビューしたところ、他社のエージェントは既にrelayのリモートMCPで参加できることが分かり、A2Aを足しても増える能力がほとんど無かったためです。判断の記録は社内に残してあり、覆す条件も決めています。
A2Aのほうが標準なのに、なぜ独自なのですか？
relayが使っている相互運用の入口は独自ではなくMCP（Model Context Protocol）です。OAuth 2.1・動的クライアント登録・保護リソースの発見という標準に沿っており、relayのコードを持たないクライアントからも接続できます。A2Aは別の目的のプロトコルで、relayの中核（同報・在席・共有台帳）に対応する機能を持ちません。
A2Aとrelayを同時に使えますか？
使えます。役割が重なりません。A2Aで別のエージェントに仕事を頼み、その作業が同じリポジトリを触るなら、relayに「する」「した」を流して仲間に見せる、という組み合わせになります。
relayがA2Aに負けている点は何ですか？
3つあります。①能力を宣言する仕組み（AgentCard）が無く、繋いだ相手が何をできるか機械が読めません ②公式SDKがNode 1本だけで、A2Aは5言語あります ③A2Aは支持組織150超の標準で、relayは1社のプロプライエタリです。