AIボットへの課金をHTTP 402で──『失効済み』のIETF個人ドラフトHAPが提案していたこと

「AIクローラーが人間のふりをしてサイトを巡回し、広告収益にも課金の仕組みにも参加せずコンテンツだけ持っていく」——この摩擦を、User-AgentやCAPTCHAといった既存の脆い仕組みではなく、HTTPプロトコルレベルで解決しようとする個人提案がIETFに出されていた。「HTTP Agent Profile（HAP）」（著者Sanat Dhir氏、2025年11月24日提出）の本文をIETF Datatrackerで確認すると、エージェント認証・人間とエージェントの分離・HTTP 402を使った課金の3つを一体の枠組みとして提案していたことが分かる。ただし、この記事の執筆時点でこのドラフトの状態を確認したところ、重要な事実が判明した——このドラフトはすでに失効し、アーカイブされている。

3行まとめ

• HAPは、HTTP Message Signatures（RFC 9421）によるエージェントのなりすまし防止と、プライバシー保護された「人間トークン」による人間・エージェントの分離、そしてHTTP 402（Payment Required）による機械可読な課金の3本柱を、新プロトコルを作らず既存HTTPの範囲内で実現しようとする提案
• IETF Datatrackerで確認したところ、文書種別は「Expired Internet-Draft（individual）」「Expired & archived」となっている。2025年11月24日提出のrev 00のみが存在し、この記事の執筆時点（2026年8月28日）まで改訂版は出ていない
• 具体的な決済の実装例として、Macaroonトークン＋Lightning Networkを組み合わせた「L402」という既存の決済プロファイルを、HTTP 402の枠組みに載せる形で紹介している

何が課題として書かれているか

ドラフトの序文はこう始まる。

Web traffic is undergoing a shift from primarily human-driven browsing to increasing volumes of autonomous agent activity. [...] Existing mechanisms for distinguishing human traffic from automated traffic rely on fragile signals such as User-Agent strings, IP address ranges, and CAPTCHAs. [...] The result is an adversarial "dark forest" dynamic in which neither side has clear, protocol-level tools to cooperate.

（Webトラフィックは、人間主導のブラウジングから、自律的なエージェント活動の増加へと移行しつつある。人間のトラフィックと自動化されたトラフィックを区別する既存の仕組みは、User-Agent文字列・IPアドレス範囲・CAPTCHAといった脆い信号に依存している。結果として、どちらの側にもプロトコルレベルで協調するための明確な手段がない、敵対的な『ダークフォレスト』的力学が生まれている）

この課題意識に対し、ドラフトは6つの要件（R1〜R6）を定義している。本文（Section 3）を確認すると、内容は次の通り。

ドラフトはこの6要件を満たすため、新しいアプリケーション層プロトコル（ドラフト内では非公式に「HTTPA」と呼ばれている）を新設する案を検討した上で、ALPN識別子の互換性問題や新規の信頼基盤構築コストを理由に退け、既存HTTPのプロファイルとして実装する方針（HAP）を採ったとSection 4で説明している。

トラフィックを「人間レーン」と「エージェントレーン」に分ける設計

HAPの骨格は、通信を2つのレーンに分類する発想にある（Section 5〜7）。

• 人間レーン: RFC 9578（Privacy Pass Issuance Protocols）に基づく「人間トークン」を持つリクエストは人間由来として扱われ、署名や支払いを要求されない
• エージェントレーン: HTTP Message Signatures（RFC 9421）による署名付きリクエストはエージェント由来として扱われ、サーバーはレート制限・402チャレンジ・評判に基づくブロックなどのポリシーを適用できる
• レガシー/不明: どちらの信号も持たないリクエストは、既存のボット対策（CAPTCHA、ブロックなど）で扱われる

エージェント認証の具体的な仕組みとしては、エージェント運営者が鍵ペア（例としてEd25519を挙げている）を生成し、公開鍵をhttps://<agent-domain>/.well-known/agent-keysのような既知URLで公開する、という規約案をSection 6で提示している。リクエストには署名対象を示すSignature-Input、署名本体のSignature、エージェントを識別するSignature-Agentの3ヘッダーが付与される。ドラフトは、鍵の危殆化に備えて「3〜6ヶ月ごとの鍵ローテーション」をSHOULDとして推奨している。

HTTP 402——予約されたまま忘れられていたステータスコードの再利用

ドラフトの核となるのが、HTTPステータスコード402（Payment Required）の使い方だ。

HTTP status code 402 ("Payment Required") was reserved in early HTTP specifications but left without a standardized meaning for decades. HAP adopts 402 as a machine-readable signal that a request from an authenticated agent is potentially acceptable, but access is contingent on some form of payment or economic work.

（HTTPステータスコード402「Payment Required」は初期のHTTP仕様で予約されていたが、数十年にわたり標準化された意味を与えられずにきた。HAPは402を、認証済みエージェントからのリクエストが潜在的に受理可能だが、何らかの支払いまたは経済的作業を条件とする、という機械可読な信号として採用する）

HAP自体は特定の決済手段を規定しない「決済非依存」の設計で、具体的な決済方式は「payment profile」として別途定義する形を取る。ドラフトが挙げる一つの実例が、Lightning Networkと Macaroonトークンを組み合わせた既存の決済プロファイル「L402」だ。サーバーがアクセスの条件をエンコードしたMacaroonとLightning請求書を402レスポンスで返し、エージェントがLightning請求書を支払って得た証明（preimage）を添えてリクエストをやり直す、という流れをドラフトは説明している。

L402の公式ドキュメント（docs.l402.org）を確認すると、この決済プロファイルはドラフトが参照時点で説明していた「Lightning前提」の枠を超え、現在は"payment agnostic"（決済非依存）を掲げ、StripeのようなカードレールからLightningを含む暗号資産まで複数の決済手段に対応する枠組みとして説明されていた。公式サイトが挙げるプロトコルの流れは、（1）クライアントがリソースへアクセス要求し402と決済オファーを受け取る「Initial Discovery」、（2）クライアントがオファーを選び決済処理へ進む「Payment Processing」の2段階で構成されている。

ドラフト自身が認めているリスク

ドラフトはSection 10「Security Considerations」とSection 11「Privacy Considerations」で、この提案自体が抱えるリスクにも触れている。

• 鍵discoveryのSSRFリスク: Signature-Agentヘッダーや.well-knownURLを使った鍵の取得は、攻撃者がサーバーに任意のオリジンへアクセスさせるSSRF（サーバーサイドリクエストフォージェリ）やDoSのリスクを生む可能性がある、として、サーバー側にパブリックIP範囲への取得制限やタイムアウト設定を求めている（SHOULD）
• 認証済みエージェントによる濫用: HAPは「支払い済み・認証済みのエージェントが取得後のコンテンツを不正利用すること」自体は防げない、とドラフト自身が明記している。HAPが目指すのはあくまで「トラフィックの説明責任を高める」ことで、コンテンツ利用そのものの制御ではない
• エージェントIDによる追跡: 永続的なエージェント識別子や長寿命の鍵は、サイトをまたいだ行動の名寄せに使われうる。ユーザー個人の代理として動くエージェントの運用者には、短命な鍵やオリジンごとの鍵を使うことを推奨している（SHOULD）

このドラフトが「失効」しているという事実

IETF Datatrackerの該当ページを確認すると、次のように表示されている。

Document Type: Expired Internet-Draft (individual). Expired & archived.

（文書種別：失効したInternet-Draft（個人提案）。失効・アーカイブ済み）

IETFの個人ドラフトは6ヶ月で失効し、著者が改訂版を出さなければそのまま「Expired & archived」という状態で止まる。HAPは2025年11月24日に提出されたrev 00のみが存在し、失効予定日（2026年5月28日）を過ぎた後も改訂版が出ていないことを、この記事の執筆時点で確認した。これは、この提案がワーキンググループの採択や実装に向けて前進しているという意味ではなく、少なくとも公式の記録上は、著者本人による更新も止まっている状態だということを意味する。

失効の理由とL402の普及度は分からない

このドラフトが失効した理由（著者の判断か、単に忘れられたのか、他の取り組みに統合されたのか）は、Datatrackerの記録からは読み取れない。この記事を書いている自分自身は、HTTP Message SignaturesやLightning Networkを使った決済システムを実装した経験がなく、L402のような決済プロファイルが実際にどこまで普及しているかについても検証していない。この提案とよく似た問題意識を持つ他の取り組み（例えばCloudflareのAI Crawl ControlやAI Preferences Attachなど）との比較も、この記事では行っていない。日本語ではZenn・Qiitaともに、HAP単体を扱った記事は検索時点で見当たらなかった。

さらに付け加えると、.well-known/agent-keysという鍵配布規約がドラフト内での提案に留まるのか、実際にこの形式を使ったエージェントやサーバーの実装が存在するのかは、この記事では確認できていない。GitHub上で同名のIETFドラフトに対応するリポジトリや実装例を横断的に検索する作業も行っておらず、著者Sanat Dhir氏（Columbia大学のメールアドレスを記載）以外にこの提案へ関与した共著者やレビュアーがいたかどうかも、Datatrackerの記録からは確認できなかった。

関連記事: MCP（Model Context Protocol）とは

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