MCPでもA2Aでも──『エージェントを見つける』だけに徹する軽量プロトコルARDPを読む

MCPやA2Aといったプロトコルの乱立を見てきたこの一連の記事の中で、意図的に「やらないこと」を最初に宣言している珍しいドラフトがある。IETF個人ドラフト「Agent Registration and Discovery Protocol（ARDP）」（著者R. Pioli氏、rev01は2026年2月更新）は、分散・連合環境で自律エージェントを登録・発見・到達させる「コントロールプレーンだけ」に徹する、軽量な仕様であることが本文から読み取れる。

3行まとめ

• ARDPは、安定したエージェント識別子（AID）・動的なエンドポイント解決・能力の広告（MCP/A2A/HTTP/gRPCから選択）・最小限のプレゼンス（生存）信号・セキュリティ最優先の発見コントロールプレーンを提供する軽量プロトコル。「エージェント同士のやり取りの中身」はMCPやA2Aのような相互作用プロトコルに委ね、意図的に扱わない
• エージェント識別子（AID）はagent:local-id@authorityという文法（ABNF、RFC 5234準拠）を持つ。登録はソフトステートで、TTLが切れる前に再登録（refresh）する必要がある
• rev01は「Expires: 28 August 2026」と明記されており、2026年8月31日にIETF Datatrackerを再確認したところ実際に「Expired Internet-Draft」「Expired & archived」となっていた。改訂版（rev02）も未公開（URLは404）

「やらないこと」を先に7つ挙げる設計

ドラフトの3章「Non-Goals」は、意図的に狭いスコープであることをこう説明している。

ARDP is intentionally narrow in scope. The following are explicitly out of scope for this specification: 1. Agent-to-agent interaction, session management, task execution, and tool invocation protocols. These are addressed by interaction protocols such as MCP and A2A. [...] 5. Billing, accounting, reputation, benchmarking, and other business frameworks.

（ARDPは意図的に狭いスコープを持つ。以下は本仕様の対象外として明示的に除外される。1. エージェント間のやり取り、セッション管理、タスク実行、ツール呼び出しのプロトコル。これらはMCPやA2Aのような相互作用プロトコルが扱う。〔中略〕5. 課金、会計、評判、ベンチマーク、その他のビジネスフレームワーク）

除外項目は全部で7つあり、身元ガバナンス・実行時の認可トークン形式・実行後の監査証跡・中央集権化の要求まで、この記事でこれまで扱ってきた他のドラフト（DAAPの監査証跡や予算管理、AgentDNSの統一課金など）が扱う領域を、ARDPは明示的に自分の対象外だと宣言している。この設計思想の違い自体が、IETFに乱立するエージェント関連ドラフト群のスコープの取り方の幅を示している。

エージェント識別子の文法——agent:local-id@authority

ARDPが定義する識別子（AID）の文法はこうだ。

aid              = "agent:" local-id "@" authority
local-id         = 1*( ALPHA / DIGIT / "_" / "-" / "." / "/" )
authority        = dns-name / internal-name / opaque-authority

権限（authority）部分にはDNS名、内部名、またはtenant-から始まる不透明な権限名のいずれかを使える。ドラフトは登録の仕組みについても具体的で、「REGISTER（AID・エンドポイント・能力文書・TTL・暗号学的証明を含む）」「DEREGISTER」を定義し、「クライアントはttlの0.5倍以下のタイミングでランダムなジッターを加えて再登録すべき（SHOULD）」という運用上の具体的な推奨まで書き込んでいる。

能力の広告——MCP・A2A・HTTP・gRPCから選ぶ

発見された後にエージェントが「何ができるか」をどう伝えるかについても、ARDPは中立的な立場を取る。

Capability documents MAY include supported protocols (MCP, A2A, HTTP, gRPC), transport bindings, authentication mechanisms, modalities, rate or cost hints, and protocol-specific metadata. Capabilities are declarative and do not imply authorization.

（能力文書には、対応プロトコル（MCP・A2A・HTTP・gRPC）、トランスポートのバインディング、認証機構、モダリティ、レートやコストのヒント、プロトコル固有のメタデータを含めてよい（MAY）。能力は宣言的なものであり、認可を意味しない）

つまりARDPは、A2Aで話すエージェントもMCPで話すエージェントも同じ発見の仕組みで見つけられるようにする「共通の電話帳」のような役割を担う設計であり、特定の通信プロトコルを推奨も否定もしていない。

「Proof of Control」——登録時に要求される署名の中身

12.1節「Proof of Control」は、エージェントが自分のAIDを実際に制御している証拠をどう提出するかを定義している。REGISTERと再登録（refresh）にはこの証明が必須（REQUIRED）だが、RESOLVE・QUERYには不要で、代わりにスコープによる認可が使われる、という切り分けだ。

出典: draft-pioli-agent-discovery-01.txt §12.1

登録の仕組み自体は/.well-known/ardp/metaというメタデータリソースに集約されており、ドラフト本文にはTTL上限・対応プロトコル・認証方式を返すJSONレスポンス例（min_ttl: 30・max_ttl: 3600・default_ttl: 300など）も具体的に示されている。エラーモデルも規定されており、invalid_aid・unauthorized・forbidden・conflict・not_found・expiredという6種の必須エラーコードが定義されている。

このドラフトは、記事公開日と同じ日に本当に失効していた

このドラフトのヘッダーには、一貫して「Expires: 28 August 2026」と記載されている。この記事の元になった調査時点（2026年8月28日）ではIETF Datatracker上でまだ「Active Internet-Draft」として扱われていたが、2026年8月31日に改めてDatatrackerを確認したところ、ステータスは「Expired Internet-Draft (individual)」「Expired & archived」に変わっており、「This Internet-Draft is no longer active.」と明記されていた。改訂版（rev02）が出ているかもdraft-pioli-agent-discovery-02.txtのURLを直接叩いて確認したが、404で存在しなかった。つまり、rev01が公開から半年で失効し、後継版も今のところ出ていない、という状態にある。

GitHubミラーへのリンクは見つからなかった

ドラフト17章「Capability Schema v0」には「能力文書のための最小限のJSONスキーマは、GitHubミラー上のコンパニオン成果物として提供される」という記述があるが、本文中にそのGitHubリポジトリの具体的なURLは記載されておらず、この記事では実際のスキーマファイルを確認できていない。この記事を書いている自分自身は、分散システムでの発見プロトコルを実装した経験がなく、ARDPが実際にどのプロジェクトで採用される見込みかについても検証していない。日本語では「日刊IETF」という日次ダイジェスト記事シリーズで一覧的に触れられている例はZenn・Qiitaともに見つかったが、ARDP単体を掘り下げた解説記事は見当たらなかった。

関連記事: MCP（Model Context Protocol）とは / AIエージェントとは

感想・指摘はコメント欄へ。