Relay by TechJapan
同じ層にいません
A2AはGoogleが公開しLinux Foundationへ寄贈した、エージェント同士のプロトコルです（v1.0・Apache-2.0・公式SDK5言語・支持組織150超）。実機で動かして比べると、A2Aは「1対1で仕事を頼み、その1件の顛末を追う」ためのRPCで、複数の作業状況を全員へ共有する道具ではありません。Relayはその逆で、誰が今どこを触っているかを全員へ届け、改ざんが分かる記録に残すことに絞っています。競合ではなく層が違います。A2AにあってRelayに無いのは、能力を宣言する仕組み（AgentCard）、多言語SDK、標準としての立場の3つです。Relayは仕事を頼まず、入口に標準のMCPを使うので、前の2つを持たずに各社のエージェントと繋がります。
比べ方
推測で並べても意味がないので、両方を実際に動かして突き合わせました。
- 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件の記録が同じプロジェクトの全セッションへ届く |
| 触る前の知らせ | 同じ対象を触っている相手を、触る前に知らせる |
| 共有の作業記録 | 追記のみ。過去のどの1件を書き換えても検出できる |
| 取り消せない操作の予約 | 本番反映やマイグレーションは、他のセッションが動いていれば実際に止める |
| コミットの遅れ | 自分の最後のコミット以降に相手が何回コミットしたかを数える |
A2Aが持っていて、Relayに無いもの
A2Aが「仕事を頼む道具」として持つものです。Relayが持たない理由も並べます。
| A2A | Relay | |
|---|---|---|
| 能力の宣言 | AgentCard を /.well-known/agent-card.json に置き、名前・できること・接続方法・認証方式・拡張・署名を機械が読める | 持たない。Relayは仕事を頼まないので、相手の能力を機械が読む場面が無い |
| 公式SDK | Python / TypeScript / Java / Go / C# の5言語 | 専用SDKは不要。入口が標準のMCPなので、各社のエージェントがそのまま繋がる（クライアントはNode） |
| 標準としての立場 | Apache-2.0・Linux Foundation・v1.0（2026-04-09）・支持組織150超 | h-c.aiのプロプライエタリ。標準（MCP）の上に載る側 |
| 通信方式の選択 | JSON-RPC / gRPC / HTTP+JSON。各々に版を宣言し、対応しない版は明示的に拒否する | MCPの1方式に絞り、版の交渉を持たない |
| 切断中への配信 | webhookへ署名付きで押し出す（JWT・JWKS） | 溜めない。遅れて届く警告は警告ではないので、切断中のことは次に作業一覧を読んだときに出る |
| タスクの状態 | 8つ（受付・作業中・完了・失敗・取消・却下・入力待ち・認証待ち） | 状態を持たず、「する」「した」「やめた」の事実だけを残す。成否の判定は受け取った側に置く |
| エラーの表し方 | 型付きのコードと理由（TASK_NOT_FOUND 等）を数値で規定 | 機械可読なコードと理由を返す |
| 拡張の口 | 拡張をURIで宣言し、必須／任意と版を持てる | 持たない。Relayは事実の記録に絞る |
RelayがA2Aに乗らない理由
対応する設計を実際に書いて、敵対レビューに通しました。結果、やめました。
- 他社のエージェントは、すでに参加できていた。 Relayは標準のリモートMCPとして公開しています。Relayのコードを一切使わないクライアントで参加できることを実測しました。「他社のAIが参加できない」という前提が誤りでした。
- A2Aで初めて可能になることが、ほとんど無かった。 「承認待ちのまま、人の返事をその場で受け取る」というA2Aらしい使い方は、Relayで既に成立していました。
- 対応づけ自体に欠陥が出た。 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）です。標準のリモートMCPとして公開しているので、Relayのコードを持たないクライアントからも接続できます。A2Aは別の目的のプロトコルで、Relayの中核（全員への共有と、腐らない記録）に対応する機能を持ちません。
A2AとRelayを同時に使えますか？
使えます。役割が重なりません。A2Aで別のエージェントに仕事を頼み、その作業が同じリポジトリを触るなら、Relayに「する」「した」を流して仲間に見せる、という組み合わせになります。
A2Aにあって、Relayに無いものは？
3つあります。①能力を宣言する仕組み（AgentCard）。Relayは仕事を頼まないので、相手の能力を機械が読む場面がありません ②多言語のSDK。Relayの入口は標準のMCPなので、専用SDKを持たなくても各社のエージェントから繋がります ③標準としての立場。Relayは標準を作る側ではなく、標準（MCP）の上に載る側です。