URLに『これはAIエージェントです』の意味を持たせる──agent://プロトコルのIETFドラフトを読む

Agent2Agent（A2A）やMCPは、エージェント同士が何をどうやり取りするかという「通信の中身」を定義するプロトコルだ。だが「このURLの先には人間向けのWebページがあるのか、それとも呼び出し可能なAIエージェントがいるのか」を機械的に区別する共通の手段は、これまで存在しなかった。IETF個人ドラフト「The agent:// Protocol」（著者Y. Narvaneni氏、S. P. Ravi氏、rev03は2026年4月18日更新）の本文を確認すると、この「アドレッシングと発見」の層を、既存のエージェント通信プロトコル群を置き換えるのではなく補完する形で提案していることが分かる。

3行まとめ

• agent://は、自律・半自律ソフトウェアエージェントを識別・発見・呼び出すためのURIベースのアドレッシングスキーム。「A2A・MCP・ACPが欠いているアドレッシングと発見の層を提供することでこれらを補完する」とドラフトは位置づけている
• 導入コストの異なる4段階の「適合レベル」（Level 0〜3）を定義。Level 0は既存インフラを一切変えずに使えるagent+https://という直接呼び出しスキーム、Level 3は認証・バージョニング・機能合成まで含むフルの記述子ベース発見
• 執筆時点（2026年8月28日）でrev03まで改訂が進んでおり、直近の更新は2026年4月18日。失効予定は2026年10月20日で、この記事の一次ソースの範囲では、まだアクティブなドラフトとして継続している

4段階の適合レベル——インフラを変えずに始められるLevel 0

ドラフトが強調するのが、既存インフラを変更せずに導入できる最小構成から始められる設計だ。

This document defines four conformance levels [...] to support incremental adoption: Level 0: Use agent+https:// as a direct invocation scheme (zero infrastructure) [...] Level 1: Publish /.well-known/agents.json for discovery [...] Level 2: Support resolution, caching, and multiple transports [...] Level 3: Full capability descriptors with authentication, versioning, and composition

（本文書は段階的な導入を支援するため4つの適合レベルを定義する。Level 0：agent+https://を直接呼び出しスキームとして使う（インフラ不要）。Level 1：発見のために/.well-known/agents.jsonを公開する。Level 2：解決・キャッシュ・複数トランスポートに対応する。Level 3：認証・バージョニング・合成を含むフルの機能記述子）

Level 0の例はこうだ。

agent+https://example.com/my-agent?message=hello

ドラフトによれば、これはhttps://example.com/my-agent?message=helloへのHTTPSリクエストと意味的に等価だが、宛先がエージェントであることを識別できる、という最小の変更で導入できる形になっている。

ドラフト第6章を読むと、実はagent+https://以外にも5つのトランスポート束縛が定義されていた。

特にagent+local://は、ブラウザ上のWebアプリからローカルにインストールされたエージェント(ファイルシステムアクセスやデスクトップ操作など、より強い権限を持つ処理)を呼び出す想定で設計されており、ドラフトは「実装は初回呼び出し前にユーザーへ同意を求めなければならない(MUST)」と明記している。ここだけ、他の5スキームより一段階厳格なセキュリティ要件が課されている。

Level 1——ドメインに置く1つのJSONファイルで発見可能にする

Level 1になると、ドメインのルートに発見用のレジストリファイルを置く。

/.well-known/agents.json
{
  "agents": {
    "my-agent": "https://example.com/my-agent/agent.json"
  }
}

ドラフトは「クライアントはこのレジストリを取得し、記述子URLをたどることでagent://example.com/my-agentを解決できるようになる」と説明している。ここで使われる/.well-known/という配置場所は、robots.txtやセキュリティ連絡先情報（security.txt）などと同じ、IANAが管理する既存の慣習に沿ったものだ。

A2A・MCP・ACPとの関係——「置き換え」ではなく「補完」

ドラフトの要約はこの位置づけを明確にしている。

The protocol complements existing agent communication protocols such as Agent2Agent (A2A), Model Context Protocol (MCP), and Agent Communication Protocol (ACP) by providing the addressing and discovery layer they lack.

（このプロトコルは、Agent2Agent（A2A）、Model Context Protocol（MCP）、Agent Communication Protocol（ACP）といった既存のエージェント通信プロトコルを、それらが欠いているアドレッシングと発見の層を提供することで補完する）

ドラフトが示すプロトコルスタック図では、A2A・MCP・FIPA-ACLといった「通信プロトコル」層の下に、HTTPS・WebSocket・gRPCといった「トランスポート」層があり、agent://はこれらとは別に「エージェントを名指しして見つける」ためのアドレッシング層として位置づけられている。つまりagent://自体はエージェント同士が何を話すかには関与せず、「どのURLの先にどんなエージェントがいるか」を示す道路標識のような役割を担う設計だ。

Delegation Chain——タスクの委任連鎖をJWTで表す

ドラフトの用語定義には「Delegation Chain（委任連鎖）」という概念も含まれている。

Delegation Chain: An ordered list of agent identifiers representing the chain of agents that have delegated a task, expressed as signed JWT claims.

（委任連鎖：タスクを委任してきたエージェントの連鎖を表す、エージェント識別子の順序付きリスト。署名済みJWTクレームとして表現される）

複数のエージェントが連鎖してタスクを委任しあう状況を、署名付きJWTで追跡できるようにする、という設計意図がここから読み取れる。ドラフト第10.2節「Delegation」を確認すると、この仕組み自体は新規発明ではなく、既存のRFC 8693(OAuth 2.0 Token Exchange)にある「入れ子のact（actor）クレーム」を使う設計だとされている。1つの署名済みトークンの中に、委任してきた各エージェントがact クレームとして入れ子状に積み重なる形だ。iss・sub・aud・iat・exp・nbf・jtiといった標準クレームはRFC 7519(JWT)の意味論に従い、トークンはAuthorizationヘッダーのBearerスキームで運ばれる（専用の「Delegation-Chainヘッダー」は定義されていない）。

ドラフトが追加で要求しているのは「単調なスコープ縮小(monotonic scope narrowing)」という原則だ。委任の連鎖を下流にたどるほど、各エージェントの権限スコープは上流のエージェントのスコープの部分集合でなければならない、と定めている。検証側は、下流のエージェントが上流より広いスコープを持っているように見えるトークンを拒否すべき(SHOULD)だとされる。ただしドラフト自身も「スコープの比較方法はデプロイ側の定義に委ねられており、空白区切りの集合として比較する実装もあれば、billing.read.*のような階層構造を使う実装、比較不能な不透明な識別子を使う実装もある」と認めており、この部分の相互運用性は完全には保証されていない。

Level 2・3の詳細、IANA登録は「Provisional」、参照実装はまだ小規模

このドラフトは全体で40ページを超える分量があり、この記事ではLevel 2・Level 3の詳細な要件（Appendix E）や、認証・キャッシュ制御の具体的な仕様までは扱っていない。

ドラフト第12章「IANA Considerations」を確認したところ、URIスキームagent・Well-Known URIagents.json・メディアタイプapplication/agent+jsonなどの登録を「requests」する内容で、スキームのStatusは明示的に「Provisional（暫定）」と記載されていた。つまりこの文書はIANAに登録を申請する体裁を取っているが、これは個人ドラフト(Internet-Draft)の中の記述であり、実際にIANAが登録を完了・承認したことを示すものではない。IETFの正式な標準化プロセス（ワーキンググループでの採択やRFC化）を経ているかどうかまでは、本記事では確認できていない。

実際にIANAのWell-Known URIレジストリ本体（iana.org/assignments/well-known-uris）を直接確認すると、この記事の確認時点でagents.jsonという項目は見当たらなかった。一方、隣接する概念であるagent-card.jsonはレジストリに実在し、Statusは「permanent」、登録組織は「Linux Foundation」、参照仕様はa2a-protocol.org、登録日は2025-08-01と明記されている。つまり同じ「エージェントの存在をWell-Known URIで示す」というアイデアのうち、A2A側のagent-card.jsonは既に正式登録を終えているのに対し、このドラフトが要求するagents.jsonはまだレジストリに載っていない。ドラフト内の「Provisional」という自己申告と、IANA公式レジストリの実際の収録状況が一致していることを確認できた。

参照実装として言及されているagent-uri/agent-uri(GitHub)も実際に開いて確認した。PythonのPoetryベースで構築されたリポジトリで、URI解析・記述子処理・解決フレームワーク・トランスポート実装(README記載時点でHTTPS・WebSocket・Localの3種)・クライアント/サーバSDKなどを含む。ただし本記事の確認時点で、スター数2・フォーク数1・コミット55件という規模であり、ドラフトが定義する6種類のトランスポート束縛のうち、READMEが明記するのはHTTPS・WebSocket・Localの3種にとどまる（gRPC・MQTT・Unixドメインソケットの実装状況はREADMEの一覧からは確認できなかった）。仕様のボリュームに対して、実装はまだ初期段階と見るのが妥当だろう。日本語ではZenn・Qiitaともに、agent://単体を扱った記事は検索時点で見当たらなかった。

改訂履歴：rev00からrev03まで、約1年でどう変わったか

IETF Datatrackerの改訂履歴ページ（/history/）を確認すると、この個人ドラフトの改訂は次のように進んでいた。

初版（rev00）の公開から最新版（rev03）まで約1年、直近の改訂（rev02→rev03）だけでも半年の間隔が空いている。個人ドラフトとしては改訂が続いている部類だが、更新頻度自体は緩やかで、IETFワーキンググループの正式な文書のような密な改訂サイクルには乗っていないことがうかがえる。

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

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