ウェブにアクセス層が追加される: llms.txt、署名済みエージェント、ペイ・パー・クロール

ウェブは、30年間単一の名誉システムファイルで運営されてきました。robots.txtは丁寧にお願いし、誰も特定せず、何も強制しませんでした。そして、その間のほとんどの時間はそれで十分でした。なぜなら、あなたのページを読むものはトラフィックを返してくれる検索エンジンだったからです。

その交換は崩壊し、現在、4つの別々の取り組みがそれを置き換えようとしています。それらは同じアイデアの競合バージョンではありません。彼らは、読むべきもの、尋ねているのは誰か、そしてそれが何を費やすかという3つの異なる質問に答えています。そして、そのうちの1つだけが完成した標準です。

実際に欠けている層はアイデンティティ

まず、robots.txtが何ができて何ができないかを考えてみましょう。ロボット排除プロトコル標準は、パブリッシャーがユーザーエージェント文字列ごとに好みを表現する方法を提供します。しかし、最後のフレーズに弱点があります：ユーザーエージェント文字列は主張であり、資格証明ではありません。誰でも任意の文字列を送信でき、インフラが移動するにつれてIPホワイトリストは劣化します。

したがって、2つのクローラーを異なる扱いをしたいパブリッシャーには、彼らを区別する信頼できる方法がありません。以下のすべての提案はそのギャップの下流にあります。ファイル自体の実際のメカニクス — 構文、ディレクティブ、および収集者がどのようにそれを読むべきか — は、ウェブスクレイピングのためのrobots.txtガイドで説明されています。

llms.txtが「何を読めばよいか？」に答える

llms.txt提案は、サイトの重要なページのクリーニングされたテキストバージョンへの要約とリンクを含むMarkdownファイルを/llms.txtに置きます。llms.txt提案は、2024年9月にJeremy Howardによって発表され、その問題点はコンテキストウィンドウです：モデルは全サイトを読み込むことができず、HTMLを使えるテキストに変換することはロスします。

その地位について正確であることが重要です。なぜなら、それはよく標準として説明されるからです。サイト自体は「標準化の提案」と呼んでいます。RFCは存在せず、作業グループもなく、誰かがそれを尊重する必要もありません。

本当に優れているのはキュレーションです。1つを書いたパブリッシャーは「ここに私のコンテンツの良いバージョンがあります」と言い、これは行儀の良い読者を助け、行儀の悪い読者には何のコストもかかりません。それは許可ではなく、好みを表現します — これはrobots.txtにも同じ制限があります。

Web Bot Authが「誰が尋ねているか？」に答える

これは実際にアイデンティティのギャップに対処する部分です。アプローチ：自動クライアントからのすべてのリクエストは、そのオペレーターに属する秘密鍵で作成された暗号署名を持つため、オリジンサーバーはヘッダーを信頼するのではなく、誰が呼びかけているかを検証できます。

現在の仕様は、Web Bot Auth HTTPメッセージ署名草案で、HTTPメッセージ署名に基づいたアクティブなインターネットドラフトです。IPホワイトリスティングとユーザーエージェント文字列は適切な識別手段ではないという枠組みです。

2つの注意点があります。この提案は作業グループの出力ではなく、個別の提出であり、同じ著者からの以前のアーキテクチャ草案はすでに期限切れになり、置き換えられています — 標準作業では通常のことですが、これは初期段階である兆候です。そして、署名はあなたが誰であるかを証明しますが、許可されているかを証明しません。それはパブリッシャーに意思決定のための情報を与えますが、決定を下すわけではありません。

ペイパークロールとRSLが「コストは何か？」に答える

2つの取り組みが、逆の方向から補償に対処しています。

Cloudflareのペイパークロールは、HTTPセマンティクス仕様で支払いのために予約され、数十年の間使用されてこなかったHTTP 402を使用しています。パブリッシャーはリクエストごとの価格を設定し、各クローラーを許可、請求、またはブロックします。クローラーは価格ヘッダーを通じて意図を示し、Web Bot Auth署名によって識別されます。これは2025年7月に発表され、現在もプライベートベータ版です — これは実験的であり、構築するためのインフラではありません。

RSLはライセンスルートを取ります。本当にシンプルなライセンス標準は、機械可読のライセンス条項 — 属性、ペイパークロール、ペイパー推論 — をXMLとして定義し、robots.txt、HTML、HTTPヘッダー、RSSフィード、またはメディアファイルから参照できます。RSL 1.0は2025年に、Akamai、Cloudflare、Creative Commons、Fastly、Reddit、O'Reilly Media、Vox Media、Yahoo、Ziff Davisの支持を受けて出荷されました。

4つの中で、RSLは命名された業界採用を持つ発表された仕様として最も進んでいます。しかし、それが決定的でもありません — ライセンス文法にはそれを強制する意思のある誰かがまだ必要であり、強制はあなたをアイデンティティに戻します。

それらが示唆するスタック

これらは並行して読むことで、代替品ではなく層になります：

• 好み — robots.txt と llms.txt は出版社が望むことを示しています。
• アイデンティティ — Web Bot Auth は、誰が尋ねているのかを暗号的に示します。
• 条件 — RSL は、コンテンツがどのように使われるか、そしてその価格を示します。
• 決済 — ペイパークロール方式の 402 フローは、お金がどのように動くのかを示します。

順序は重要です。アイデンティティなしの条件は強制できず、条件なしの決済は料金が表示されていない料金所です。アイデンティティは支えとなる層であり、最も未完成なものです。

ここでの限界

これに対する明白な異議：ここには参加しないことを選んだ誰にも縛るものはありません。llms.txtを無視し、署名を送信せず、RSLファイルを読みもしないクライアントは、常にクライアントが置かれていた状況にいます。これらのメカニズムは、識別可能でありたいと望むオペレーターに対して機能します。これは大規模で責任を持ったものの大半と、他のすべてではありません。

第二の問題は統合です。署名ベースのアイデンティティは、主要なインフラを運営し、自身のキーを認識させるのに十分な規模のオペレーターを優遇します。研究者、スタートアップ、公共利益のアーカイブは、置き換えられる名誉システムよりも新しいアクセス層に入るのが難しいと感じるかもしれません。それは実際のコストであり、クリーンなウェブの丸め誤差として扱うのではなく、名づける価値があります。

第三に、これらのいずれも、崩壊を引き起こした非対称性には対処していません。検索時代のクロールは、トラフィックのためにアクセスを取引しました。あなたのページを読み、その質問自体に答えるモデルは何も返さず、支払いレールは関係を回復させません — それはその不在に対して価格をつけます。

実際に何をすべきか

もしあなたが出版者なら：llms.txtを書いてください — それは安価で、あなたがコントロールするキュレーションを表現します。RSLに注目してください。なぜなら、機械可読ライセンスは将来の紛争が焦点を当てる遺物だからです。ペイパークロールを計画としてではなく、追随すべき実験として扱ってください。

もしデータを収集するなら：耐久性のある手段は、これらのシステムが対応するように設計されたクライアントの種類になることです。自分を正直に特定し、公共データに留まり、今日存在する指示を尊重し、ボリュームを比例させ、収集したものとその出所を記録してください。上述のすべての提案は、「あなたは誰で、何を取ったのか」に答えることができるオペレーターを報いるものです — そしてそれは、答えがまだ自発的である今行う価値があります。

名誉システムは終わりを迎えています。それを置き換えるものは未完成であり、便利な姿勢はそれを待つことでも無視することでもなく、今後の最終版で必要となるように行動することです。

Scrapelessの無料プランを開始して、Scrapeless AIエージェントが公共ウェブデータをどのように扱うかを確認し、収集プログラムを計画する際にはScrapelessの料金を確認してください。

FAQ

Q: llms.txtは公式な標準ですか？

いいえ。それは明示的に標準化の提案として提示されており、2024年9月に公開されました。RFCもなく、作業グループもなく、どのクライアントもこれを尊重する必要はありません。サイトは、キュレーションが良好に行動する読者に役立つから採用するのであって、何かに強制されるわけではありません。

Q: llms.txtはrobots.txtを置き換えますか？

いいえ — それぞれが異なる質問に答えます。robots.txtはRFC 9309で標準化され、クライアントが取得すべきでないパスを示します。llms.txtは、出版社が最も有用と考えるコンテンツを指し、それのクリーンなテキストバージョンを提供します。一方が制限し、もう一方がキュレーションを行い、どちらもクライアントを認証しません。

Q: Web Bot Authは実際にどの問題を解決しますか？

クローラーのアイデンティティを検証可能にします。現在、クライアントは誰もがコピーできるUser-Agent文字列で自身を識別しているため、出版社はクローラーを確実に区別できません。Web Bot Authは、HTTPメッセージ署名を使用してオペレーターの秘密鍵で各リクエストに署名し、発信元が誰が呼び出しているかを検証できるようにします。これはアクティブな個別のインターネットドラフトであり、完成した標準ではありません。

Q: 出版者は今日、AIクローラーに料金を請求できますか？

実験的にのみ。CloudflareのペイパークロールはHTTP 402を用いたリクエストごとの料金体系で、2025年7月に発表されましたが、まだプライベートベータの状態です。2025年にインフラ企業や出版者のグループの支持を得て発表されたRSLは、ペイパークロールやペイパーインフェレンスを含む機械可読なライセンス条件を定義していますが、ライセンスには依然として誰かがクライアントを特定し、取り締まる必要があります。

Q: データ収集チームは、これが決着するまで何をすべきですか？
アイデンティティと条件がすでに施行されているかのように行動してください。公共データのみを収集し、現在の指示を尊重し、リクエスト量はサイトが提供できるものに比例させ、収集したものとその出所を記録してください。テーブルの上にあるすべての提案は、その質問に答えられるオペレーターに報いるためのものであるため、どの提案が勝とうとも作業は無駄にはなりません。