要約

  • terms.txt第00版は、署名、目的申告、利用者の委任、支払い証票をオリジンが配信前に検査し、成功時に受領記録を返す仕組みを提案する。
  • 署名が保証するのは申告者と改変の有無、受領記録が保証するのは一件の配信である。目的の真実性や配信後の使途は保証しない。
  • Daniel Kadeは、事前執行、事後監査、契約上の義務を混ぜない「アクセス義務台帳」を提案する。これは編集上の提言であり、IETFの要件ではない。

機械にも目的を申告させる案

RFC 9309のrobots.txtは、クローラーに対してURIへのアクセス方法を示す。しかし同RFCは、それがアクセス認可ではないとも明記する。どの運営者が検索、学習、リアルタイム応答のどれを目的としているかを認証し、サーバー側で課金条件を満たしたか判断する仕組みではない。

terms.txt第00版は、この受動的な慣行をオリジンでの判断に置き換えようとする。/.well-known/terms.txtをwell-known URIとして公開し、パスごと、目的ごとに許可、課金、拒否を定める。転載の程度に上限を付け、利用者からの委任を条件にすることもできる。

自動クライアントは、別のWeb Bot Auth作業部会草案に従って鍵を示し、HTTP Message SignaturesでAccess-Intentを保護する。条件次第で、利用者の委任トークンや一回限りの支払い証票も同じ署名対象に入る。

オリジンがその場で確認できる項目は多い。解決済みのエージェント識別子に載った鍵、署名の有効期間、nonceの再利用、完全な対象URI、目的申告の完全性、委任の対象と範囲、条件との一致、未使用の証票である。これらを満たさなければ、配信前に止められる。

403は違反判定ではない

草案は拒否時に403を使い、Problem Detailsで署名不正、リプレイ、目的拒否、利用上限超過、委任不足、支払い不足を区別する。HTTP Semanticsが予約した402に独自の意味を与えず、WWW-Authenticateを用意しない交換を401とも呼ばない。

ここでの403は、当該オリジンが当該要求を出さなかったという事実である。法的違反の確定、他サイトでの排除、エージェント運営者への一般的制裁ではない。共通のエラー形式と社会的な判断権限は別物だ。

識別についても同じ注意が要る。Web Bot Authは、公開鍵の保有者が要求に署名したことと、同じ識別子を次回も認識できることを支える。現実の企業名まで自動的に証明するわけではない。委任を出すIDプロバイダーをなぜ信頼するのか、支払い証票を出す決済サービスと誰がどの契約を持つのかもterms.txtの範囲外である。

配信を示す記録と、利用を示す証拠

草案の優れた点は、三つの証拠層を自ら区切っていることである。第一は配信前に執行できる検査。第二は配信後に監査できる申告と観察の照合。第三は契約上の利用条件である。

署名は「検索目的」と書かれた申告が途中で書き換えられていないことを示せる。後日、その運営者の公開サービスが記事を丸ごと再掲していたなら、申告は争いの出発点になる。しかし署名を検証した瞬間に、将来の行為が真実になったわけではない。

Access-Receiptも一件の要求に限定される。どの表現がどの条件で配信されたかは示せるが、学習、要約、再配布を追跡しない。この限定はキャッシュ設計に表れる。保存済み応答を別の要求に再利用すれば、添付された受領記録は最初の要求のままである。そのため草案は受領記録付き応答にCache-Control: no-storeを要求し、HTTPキャッシュの共有効率をあえて捨てる。

条件ファイル自体も管理対象になる。構文が壊れればファイル全体を無効とし、クライアントは条件が存在しないものとして扱う。バージョン管理、公開前検証、原子的な切り替え、外部からの到達確認がなければ、小さな編集ミスが対外的な方針状態を変えてしまう。

IETF標準になったというニュースではない

Datatrackerはterms.txtを個人Internet-Draftとして掲載し、ストリームも正式な標準化上の地位もないと示す。履歴では、2026年9月11日に第00版が手動掲載された。作業部会採用、担当Area Director、IESG承認、RFC化はいずれも起きていない。

文書ヘッダーの目標はStandards Trackだが、Datatrackerの予定RFCステータスは空欄である。目標と現在地を同一視してはならない。AI利用プリファレンス語彙と、そのHTTPへの関連付けは別の作業部会文書であり、その手続上の地位がこの個人草案に移ることもない。

参考実装の記述も限定的に読む必要がある。24件の検査と処理時間が報告される一方、v0.1は第00版より古く、対象URI、ステータスコード、トークン形式、識別子、受領記録の項目、証票、キャッシュ、リンク関係が本文と違う。動く試作は存在するが、第00版への適合や独立実装との相互運用はまだ示されていない。

アクセス義務台帳で三層を残す

Daniel Kadeが提案するアクセス義務台帳は、オリジンとパス、条件IDとダイジェスト、申告目的と利用レベル、エージェント識別子と本人性の限界、委任発行者と範囲、決済権限、事前判断、応答と内容のダイジェスト、受領記録ID、事後観察、契約義務、紛争担当、期限、取消し、後継条件を一行に結ぶ。

Heng LuのThe Policy Mirrorは、証拠がどこで意思決定に変わるかを可視化する。Minimum Initial Specificationは共通部分を小さく保ち、将来の選択を現場に残す。Why BTW Media Existsが求めるのは、提案の期待と現在の事実を分ける報道である。署名は境界までを明るくできる。境界の外まで見えたことにはできない。

情報源

  1. terms.txt Datatracker記録
  2. terms.txt文書履歴
  3. terms.txt第00版
  4. Web Bot Auth草案
  5. AI利用プリファレンス語彙草案
  6. AIプリファレンスHTTP関連付け草案
  7. RFC 9309 — Robots Exclusion Protocol
  8. RFC 9421 — HTTP Message Signatures
  9. RFC 9457 — Problem Details
  10. RFC 9110 — HTTP Semantics
  11. RFC 9111 — HTTP Caching
  12. RFC 8615 — Well-Known URIs
  13. RFC 8126 — IANA登録指針
  14. The Policy Mirror
  15. Minimum Initial Specification
  16. Why BTW Media Exists