『robots.txtより厳格な』新ポリシーファイルAGENTS.TXTのIETFドラフト、参考文献が架空だった

AGENTS.mdでもrobots.txtでもない、自動化クライアント・ボット・クローラー向けの「厳格なプレーンテキストポリシーファイル」を提案するIETF個人ドラフトがある。「AGENTS.TXT: Strict Policy File for Automated Clients」（著者S. Dutta氏、2025年10月7日提出）の本文を確認すると、SHA-256ハッシュによる改ざん検知や、不正な形式のファイルは全拒否として扱うという設計は具体的に書かれている。だが、この記事を書くために参考文献セクションを1件ずつIETF Datatrackerの実物と突き合わせたところ、看過できない問題が見つかった。

3行まとめ

• AGENTS.TXTは、/agents.txtという固定パスに置く厳格なポリシーファイル形式。robots.txt同様/path ALLOWや/path DISALLOWのディレクティブを書くが、ファイル冒頭にSHA-256ハッシュ行を必須とし、ハッシュ不一致やディレクティブの構文エラーがあれば「サイト全体をアクセス禁止として扱う」という厳格さが特徴
• このドラフトは2025年10月7日提出のrev00のみで、IETF Datatrackerでは「Expired Internet-Draft」「Expired & archived」（失効・アーカイブ済み）となっている
• 参考文献セクションにはRFC9件とFIPS規格1件が挙げられており、RFC9件のうち4件（RFC 8309・RFC 8792・RFC 8899・RFC 9309）で、著者名とタイトルが実際のRFCと一致しないことを、IETF Datatrackerの当該RFCページと直接突き合わせて確認した

仕様自体は具体的——ハッシュ行と「全拒否」原則

ドラフトが定義するファイル形式はこうだ。

The first non-comment, non-empty line MUST be the hash line, starting with '*' followed by the lowercase SHA-256 hex digest of the file excluding the hash line and comments [...].

（コメントでも空行でもない最初の行は、ハッシュ行でなければならない（MUST）。この行は*で始まり、ハッシュ行自身とコメントを除いたファイル内容のSHA-256ハッシュ値（小文字16進表記）が続く）

そしてディレクティブは<path> <action> [params...]という形式で、actionはALLOWまたはDISALLOW。ドラフトが示す例はこうなっている。

/status ALLOW
/dashboard ALLOW limit=50
/admin DISALLOW

不正な形式のファイルへの対応も明確に規定されている。

Any hash missing, hash mismatch, or directive syntax error MUST result in treating the entire site as restricted [...]. Cached copies MUST be invalidated.

（ハッシュの欠落・ハッシュの不一致・ディレクティブの構文エラーのいずれかがあれば、サイト全体をアクセス制限扱いとしなければならない（MUST）。キャッシュされたコピーは無効化しなければならない（MUST））

ここまでは、仕様の説明として筋が通っている。

参考文献をIETF Datatrackerで1件ずつ突き合わせた結果

このドラフトの参考文献セクションには、次のような記載がある。

[RFC9309]  McCarthy, A., "Robots.txt: History, Use, and
           Standardization", 2022
[RFC8309]  Pahl, C., "Bot Traffic and Management Best Practices", 2018
[RFC8792]  Smith, J., "HTTP Client Best Practices for Automated
           Agents", 2020
[RFC8899]  Tan, L., "Guidelines for Secure API Crawlers", 2021

この記事を書くにあたり、これら4件のRFC番号をIETF Datatrackerで個別に確認した。結果は次の通りだ。

4件すべてで、著者名・タイトルのいずれも実際のRFCと一致しない。RFC番号自体は実在するが、そこに紐づけられた著者・タイトルは、この記事で確認した範囲では架空のものだった。一方で、同じ参考文献セクションにあるRFC 2119（key words for RFCs）、RFC 3174（SHA-1）、RFC 3986（URI構文）、RFC 7231（HTTP/1.1セマンティクス）、RFC 7525（TLS推奨事項）は、著者・タイトルとも実際のRFCと一致することを確認した。

ドラフト本体のもう一つの引っかかり——サンプルのハッシュ値

ドラフト第9節「Example agents.txt File」には、実際に動く例として次の値が示されている。

# version: 1.0
*e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
#sample. may not be accurate.
/status ALLOW
/dashboard ALLOW limit=50
/admin DISALLOW

このハッシュ値e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855を、手元でshasum -a 256にかけて確かめた。空文字列（何も入力しない状態）のSHA-256ハッシュと完全に一致した。つまりこの例で示されているハッシュは、直後に続く3行のディレクティブから計算した値ではなく、「何も入力していない状態」の定数値をそのまま貼り付けたものだった。ドラフト自身も同じ行の直後に#sample. may not be accurate.（サンプルであり正確とは限らない）という注記を置いており、著者自身がこの例の正確性を保証していない、とも読める。第7節が定義する計算手順（ハッシュ行・コメント・空行を除いた残りの行を\nで連結してSHA-256を取る）どおりに実際に計算すると、当然この定数値にはならない。

著者情報について確認できたこと

IETF Datatrackerおよびドラフト本文の「Authors' Addresses」欄で著者情報を確認すると、著者はSrijal Dutta氏、所属欄は"Independent"（無所属）で、連絡先は組織のドメインメールではなくsrijaldutta.official+agentstxt@gmail.comという個人のGmailアドレス（"+agentstxt"というプラス記法のサブアドレス）だった。ドラフトの有効期限は本文ヘッダーに"Expires: 10 April 2026"と明記されており、2025年10月7日の提出から6か月後に自動失効する、IETF Internet-Draftの標準的な失効ルールどおりの日付になっている。

もう一点、本文1ページ目には"Intended status: Standards Track"という記載がある。ワーキンググループの後ろ盾のない個人提出のドラフトが、自らStandards Trackを名乗っている点は目を引く。一方IETF Datatrackerのドキュメント情報ページを見ると、「Intended RFC status」欄は「(None)」と表示されており、ドラフト本文の自己申告とDatatracker側の扱いは一致していない。

さらにDatatrackerの「Referenced by」ページ（このドラフトを引用している他のIETF文書の一覧）を確認したところ、2026年8月31日時点で1件がヒットした。「draft-car-agents-txt-wellknown」（"AGENTS.TXT: Capability Declarations for Web Agents"、informatively references扱い）で、こちらはExpiredではなく現在も"Active Internet-Draft"（個人提出）のステータスで、Datatracker記載のLast updatedは2026年6月12日だった。つまり、参考文献に架空の著者名・タイトルを含むこの失効ドラフトとほぼ同名・同テーマの別ドラフトが、現時点でも生きたまま存在し、しかも失効した側を参照している。

これをどう受け止めるべきか

正確に何が起きたのかは、この記事では確定できない。著者が実在しないRFCの著者名・タイトルを手作業ででっち上げた可能性、ツール（AIを含む）による下書き生成時に生じた誤りをそのまま提出した可能性、あるいは別の経緯があった可能性のいずれも、この記事の一次ソース調査だけでは区別できない。ただし、RFC番号だけは正しく、著者名とタイトルだけが実際の内容とかけ離れているという一致しない組み合わせ方（RFC 8792は「長い行の扱い」という編集規則の文書だが、番号だけ借りて「HTTPクライアントのベストプラクティス」という、もっともらしいが無関係なタイトルが付けられている、など）は、生成AIが根拠のない引用を作り出す際によく見られるパターンと外形的には似ている、と指摘はできる。

IETFの個人ドラフトは、査読を経て掲載されるものではなく「誰でも提出できる」文書だ。参考文献の正確性を含め、内容の検証は読み手の側の責任になる、という個人ドラフトという枠組みの性質そのものを、この一件は示している。

架空の経緯そのものは特定できていない

RFC 8309・8792・8899・9309以外の3件（RFC 2119・3174・3986・7231・7525）についても全件確認したが、これらは一致していた。また、このドラフトに改訂版（-01）が出ていないかもIETF Archiveで確認したが、draft-srijal-agents-policy-01.txtは存在せず（404）、2025年10月7日提出のrev00のまま失効している。この記事を書いている自分自身は、著者S. Dutta氏に事実関係を確認する手段を持たず、なぜこの食い違いが生じたのかについての説明は得られていない。ドラフト本文のうちファイル形式・ディレクティブ構文といった技術的な中身自体が妥当かどうかの専門的評価も、この記事では行っていない。日本語ではZenn・Qiitaともに、AGENTS.TXT単体を扱った記事は検索時点で見当たらなかった。

関連記事: AIエージェントとは / 生成AIのセキュリティリスク──企業が押さえるべき6つの脅威と対策

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