CloudflareのVerified Botsにおける継続的アカウンタビリティ、アイデンティティを継続的な検証へ

Cloudflareは10月16日、Verified bots向けの継続的アカウンタビリティを導入し、これまでアイデンティティを中心としていたプログラムに、継続的な行動テストを加えた。この変更は、クローラーが運営主体を証明できても、Webサイトのルールを無視する可能性があるという根本的な矛盾に対処するものだ。

新システムは、検証済みの自動化ツールが公開された方針を尊重し、サイトから減速を求められた際に応答するかを観察する。Cloudflareはその観察結果を、検証を恒久的な承認印として扱うのではなく、説明可能な信頼度の帯域へと変換する。

この区別は、Cloudflareが2025年にPerplexityをVerified Botsリストから削除した後では特に重要だ。Cloudflareは、Perplexityが制限されたコンテンツにアクセスし、ブロックされるとクロール手法を変更したと主張した。Perplexityはこの見方に異議を唱えた。この出来事は、Cloudflareが現在解決しようとしている弱点を浮き彫りにした。認証はボットを識別できるが、アイデンティティだけでは適切な行動を保証できない。

Verified Bots向け継続的アカウンタビリティが行動レイヤーを追加

Cloudflareは、検証を一度きりのアイデンティティ判定から、継続的な行動評価へと変えようとしている。

CloudflareのVerified Botsプログラムは歴史的に、Webサイトが認識済みの自動化ツールを、未知または悪意を持つ可能性のあるトラフィックから見分けるのを支援してきた。検索クローラー、監視サービス、アクセシビリティツール、ユーザー主導型エージェントはいずれも検証済みステータスを申請できる。

ボットは、承認された方式で自身を識別しなければならない。方式には、暗号署名、安定したユーザーエージェントと組み合わせた公開IPレンジ、逆引きDNSチェックが含まれる。

CloudflareのVerified bot policyは、非侵害的な行動も求めている。検証済みサービスはrobots.txtの指示に従い、妥当なリクエストレートを維持し、Webサイトの設定を回避しないことが求められる。

問題は時間的な側面にある。事業者は登録時には条件を満たしていても、その後、クローラーの挙動を変える更新を展開できる。設定ミスによっても、悪意がなくても有害なトラフィックが発生し得る。

Cloudflareの新システムはこの隔たりを監視する。クローラーが時間の経過とともにサイトの方針にどれほど一貫して従うかを測定し、評価の根拠となる行動を記録する。

その結果が、説明可能な信頼度の帯域だ。Cloudflareはこれを、企業や事業者に対する恒久的な判断ではなく、持続的な行動を反映する範囲だと説明している。

この枠組みは、リスクと信頼を分ける。リスクは特定のリクエストや時点に関連する潜在的な害を指す。信頼は、多数のやり取りにわたる反復的なパターンを反映する。

検証済みクローラーが偶発的に一度ポリシー違反を起こしても、即座に全面的に信頼できないものになるわけではない。逆に、制限を繰り返し無視するボットは、過去のアイデンティティチェックに合格したというだけで特別扱いを維持すべきではない。

Cloudflareによると、最初の評価シグナルは二つの問いを投げかける。ボットは公開された指示を尊重したか。そして、Webサイトからの直接的なフィードバックに応答したか。

これらのシグナルは、観測可能なネットワーク上の行動に焦点を当てる。Cloudflareがクローラー運営者の私的な意図を推測する必要はない。

この手法は、事業者に回復への道筋も与える。ボットが指示またはレート制限への応答を受けた後、一貫して行動を改めれば、信頼度の帯域は改善し得る。

Cloudflareはすでにこのシステムを社内で利用している。同社は、十分な行動履歴を蓄積し、ガイダンスを改善した後に、顧客へ評価を公開する予定だとしている。

顧客は最終的に、Verified Botトラフィックの処理に用いる信頼度のしきい値を選べるようになる。Cloudflareは一般提供日を発表しておらず、正確なスコアリング式も開示していない。

これらの未公表事項は重要だ。この発表は基本理念と初期シグナルを定義しているが、完全な製品仕様をまだ示してはいない。

それでも方向性は明確だ。検証済みステータスは今後、ボットが識別可能であり続け、受け入れられた境界内で行動し続けることを意味するようになる。

アイデンティティだけでは信頼判断全体を担えなくなった理由

暗号学的アイデンティティはリクエストの送信者を示すが、そのリクエストを受け入れるべきかどうかには答えない。

Cloudflareは数年にわたり、ボット識別を強化してきた。ユーザーエージェント文字列やIPアドレスといった従来のシグナルには、深刻な限界がある。

ユーザーエージェントは、HTTPリクエストとともに送られる単なるラベルだ。別のプログラムがコピーできる。IPレンジは変わる可能性があり、複数のシステムに使われたり、侵害されたりすることもある。

Web Bot Authは、このアイデンティティ層を改善する。HTTP Message Signaturesを使ってボットがリクエストに署名できるようにし、承認された事業者がリクエストを作成したことを暗号学的に証明する。

Cloudflareは署名を検証し、トラフィックをボットとエージェントの公開ディレクトリであるBotBaseのエントリーに関連付ける。これにより、なりすましが容易な識別子への依存を減らせる。

基盤となる署名形式は、Cloudflareだけの発明ではない。HTTP Message SignaturesはRFC 9421を通じて標準化されており、Web Bot Authの仕様も引き続きオープンに開発されている。

ただし、署名の検証が解決するのは認証だけだ。有効な署名は、リクエストが既知の事業者から発信されたことを証明できる。その事業者がパブリッシャーの制限を守ったことまでは証明できない。

たとえば、すべてのリクエストに正しく署名する監視ボットが、障害を含むデプロイ後にページを数百倍の頻度でリクエストし始める場合を考えてみよう。その行動が運用コストを生んでも、アイデンティティは有効なままだ。

同じ問題はAIクローラーにも当てはまる。クローラーは、自らを正確に識別しながら、サイトがその目的には利用不可と明示したコンテンツをリクエストできる。

自動化がより多くの役割を担うにつれて、この隔たりはさらに重大になる。Cloudflareは現在、検証済みシステムを検索、モデル学習、ユーザー主導型エージェント、取引、セキュリティテスト、データ収集などの活動に分類している。

一部のボットは仲介者としても機能する。インフラは一社に属するが、多くのユーザーがそのプラットフォームのエージェントを通じてアクションを開始できる。

これはCloudflareが推移的信頼と呼ぶ状況を生む。サイトはプラットフォーム事業者を信頼しても、そのプラットフォームのエージェントを指示するすべてのユーザーを信頼するとは限らない。

Verified bots向けの継続的アカウンタビリティは、この委任の問題を完全には解決しない。しかし、事業者のアイデンティティのみに全面的に依存するのではなく、その結果生じるトラフィックをCloudflareが評価する手段を提供する。

この変更は、ボット運営者に対し、コンプライアンスを本番システムに組み込むよう促すものでもある。適切な行動は、登録時に記録された約束のままではいられない。

運営者には、信頼性の高いrobots.txtの取得、ポリシーを考慮したURL選択、目的別のアイデンティティ、適応的なレート制御が必要だ。また、CDNが有害なパターンを記録する前に後退を検知する監視も必要となる。

これは、検証済み自動化に求められるエンジニアリングの水準を引き上げる。認証は参加条件となり、観測可能なコンプライアンスがその信頼が持続するかを決める。

Robots.txtとHTTP 429は提案ではなく証拠になる

Cloudflareの仕組みは、Webでよく使われる二つのシグナルを、クローラーの継続的な信頼度を示す証拠へと変える。

最初のシグナルはrobots.txtであり、Webサイトのトップレベルパスに置かれるテキストファイルだ。自動クローラー向けのアクセス指示を公開する。

このプロトコルはユーザーエージェントごとにルールを整理し、AllowまたはDisallowディレクティブでアクセス可能なパスを示す。RFC 9309では、ファイルを正常にダウンロードしたクローラーは解析可能なルールに従わなければならない。

robots.txtには実務上の限界がある。これは方針を伝えるものだが、認証ゲートやファイアウォールルールのように強制するものではない。

また、クローラーが特定のコンテンツを求める理由についてはほとんど示さない。一つの事業者が、検索、モデル学習、ユーザーリクエストによる取得のために別々のボットを使う場合もある。これらの目的を一つにまとめる場合もある。

Cloudflareは、観測されたトラフィックがサイトの公開ルールと一貫しているかを評価する。このシステムは、個々の不一致を決定的なものとして扱うのではなく、反復するパターンを重視する。

この区別により、一時的なエラーがボットの評価を自動的に失墜させる可能性が下がる。同時に、継続的な無視を異常として片付けることも難しくなる。

Cloudflareは、robots.txtが最低限の境界を示すものであり、禁止されていないあらゆる行為への包括的な許可ではないと注意を促している。Webサイトは、別のレスポンスを通じて継続的なアクセスが歓迎されないことを伝えられる。

HTTP 429は二つ目の初期シグナルだ。サーバーはこのステータスコードを使い、クライアントが一定期間に過剰な数のリクエストを送信したことを示す。

レスポンスには、クライアントに待機時間を伝えるRetry-Afterヘッダーを含められる。ただし、このガイダンスは任意だ。

関連するHTTP標準は、過剰なトラフィックの識別方法やリクエストの計数方法について、サーバーに柔軟性を残している。サーバーはリソース、認証情報、その他の基準に基づいて制限を適用できる。

Cloudflareは、その後にボットが何をするかを監視する。429レスポンスを繰り返し受け取った後に減速または停止するボットは、適応性を示す。同じレートで継続するボットは信頼を失う。

これにより、レート制限への対応は検証済みボットのアカウンタビリティの一部となる。また、クローラーは許可されたパス内に完全にとどまりながらもオリジンを圧迫できるため、重要な抜け穴を塞ぐことにもなる。

この組み合わせにより、行動に基づくフィードバックループが生まれる。パブリッシャーはアクセス方針を示し、オリジンはリアルタイムのフィードバックを提供し、Cloudflareはクローラーの応答を観察する。

Bot Preference Syncは、このループの公開側を支える。顧客が設定したAIトラフィックの方針を、対応するrobots.txtエントリーへ変換する。

CloudflareのBot Managementツールは、強制側を担う。顧客は認識済みのカテゴリやその他のシグナルを使い、トラフィックを許可、ブロック、チャレンジ、またはレート制限できる。

継続的評価は、これらのコンポーネントの間に位置する。既知のボットが、公開され強制されたポリシーに遭遇した後に、実際に期待どおり振る舞うかを問う。

したがって、このシステムは二つの異なる時間尺度でコンプライアンスを測定する。robots.txtは比較的持続的なサイトポリシーを反映し、HTTP 429は即時の負荷圧力を伝える。

信頼できるクローラーは、その両方に対応しなければならない。恒常的な制限を考慮してリクエストを計画し、現在の状況が変わった際には行動を調整すべきだ。

Perplexityが示すVerified Botアカウンタビリティの論争性

Perplexityを巡る論争は、行動証拠の価値と、一つのインフラ事業者に信頼の定義を委ねる危険性の両方を示している。

Cloudflareは、AIクローラーをブロックしようとしたサイト運営者から、Perplexityが引き続きサイトへアクセスしているとの報告を受け、調査を開始したと述べた。

同社は、新規でインデックス化されておらず、robots.txtの制限で保護されたテストドメインを作成した。その後、これらのドメインの情報を必要とするプロンプトをPerplexityに送信した。

Cloudflareによると、Perplexityはこうした制限にもかかわらず詳細な情報を取得した。Cloudflareはさらに、申告済みのエージェントがブロックに遭遇した際、クロールが未申告のインフラや一般的なブラウザーアイデンティティへ移行したとも主張した。

Cloudflareはこの行動をOpenAIを用いたテストと比較した。ChatGPTはrobots.txtがアクセスを禁止した場合に停止し、ネットワークブロックに遭遇した場合にも停止したと述べた。

Cloudflareはその後、Perplexityのボットを認証済みリストから削除した。また、問題とされるステルス型クローリングをブロックするための管理検出ルールも追加した。

Perplexityはこの非難を否定した。同社はCloudflareの説明を営業的な売り込みだとし、Cloudflareが特定したトラフィックはPerplexityのものではないと主張したと報じられている。

Cloudflareが現在トラストバンドを提供しているからといって、この対立がなくなったわけではない。行動に基づく評価は、依然として帰属、測定設計、ポリシー解釈に左右される。

AIサービスが複数の取得レイヤーを使用する場合、帰属の判断は特に難しい。回答は、申告済みのクローラー、第三者のインデックス、ユーザー主導のブラウザ、または別のプロバイダーが運用するインフラから情報を取得する可能性がある。

CDNは多数のウェブサイトにまたがるリクエストパターンを観測できるが、すべてのリクエストの背後にある事業上の関係やユーザーの意図を常に把握できるわけではない。

同様に、運用者はユーザー主導の取得を大規模な自律クローリングとは異なるものと見なす可能性がある。一方で、両者が同じアクセス制限ページを複製するなら、パブリッシャーはその区別を受け入れないかもしれない。

Cloudflareが提案するトラストバンドは、二値ラベルよりもこうした対立に適している。パターンを表現し、どの行動が評価に影響したかを示すことができる。

ただし、説明可能性は短いラベルにとどまるべきではない。運用者には、低評価につながったリクエスト、ポリシー、期間、是正手順を特定するのに十分な詳細が必要だ。

異議申し立てのプロセスも重要になる。誤った帰属により、正当なボットが多数のCloudflare保護サイトで顧客からブロックされ、損害を受けるおそれがある。

権限の集中も別の懸念を生む。Cloudflareは設定ツールを提供し、トラフィックを観測し、信頼評価を算出し、さらに執行製品も提供している。

この統合により、説明責任のループは実用的になる。その一方で、どの自動化サービスがウェブの大きな部分に到達できるかについて、Cloudflareに大きな影響力を与えることにもなる。

したがって同社は、曖昧なケース、複合目的のエージェント、共有インフラ、一時的な障害をどのように扱うかを開示すべきだ。手続き上の保護措置を欠くスコアは、不透明なレピュテーションシステムになりかねない。

認証済みボットの説明責任には、運用者側からの対称的な明確さも必要となる。企業は、ユーザーエージェント、目的、IPレンジ、署名鍵、サイト側の制限への対応を文書化すべきだ。

検索、学習、ユーザー主導の取得に別々の識別子を用意すれば、曖昧さを減らせる。これによりパブリッシャーは、有用な発見を許可しつつ、すべての自動化目的に同じアクセス権を与えずに済む。

Perplexityの事例は、普遍的な判決ではなく、警告として残っている。Cloudflareは技術的な観測結果を示した一方、Perplexityはトラフィックの帰属と解釈に異議を唱えた。

この未解決の対立こそ、新たなシステムに透明な証拠が必要な理由だ。継続的な測定が価値を持つのは、影響を受ける当事者がその結論を検証し、異議を申し立てられる場合に限られる。

トラストバンドには依然として重要な未解決の疑問が残る

Cloudflareは測定したい対象を説明しているが、そこから導かれる判断の仕組みについては十分に明らかにしていない。

同社は、robots.txt違反、無視された429レスポンス、その他の将来的なシグナルに対する重み付けルールを公開していない。トラストバンド間の境界も定義していない。

こうした詳細がなければ、顧客はクローラーの行動がどのように評価へ反映されるかを独自に予測できない。ボット運用者も、準拠のための完全な技術的基準を持てない。

Cloudflareは、単発の事象ではなく継続的なパターンを評価するとしている。これは妥当な保護策だが、「継続的」が何を意味するかには測定可能な期間が必要だ。

数百万件のリクエストを送るクローラーは、ごく低い比率でも偶発的な違反を多数発生させ得る。小規模なクローラーでも、単一のオリジンに対してはるかに少ないリクエストで深刻な損害を与えられる。

生の件数ではこうしたケースを歪める。割合も、一時的に脆弱なサイトを圧倒する深刻な急増を隠し得る。

信頼できるスコアリングモデルには文脈が必要だ。これには、リクエスト量、オリジンの処理能力、ポリシーの鮮度、Retry-Afterの指示、レスポンスの一貫性、クローラーがシグナルを受け取ったことを示す証拠が含まれる。

Robots.txtは別の曖昧さももたらす。ファイルが利用不能、設定ミス、矛盾状態、クロール中の変更、あるいは仲介者による改変を受けている場合がある。

CloudflareのBot Preference Syncは、ダッシュボード設定と公開済みの設定を整合させることで、一部の設定乖離を減らす。だが、カスタムルールやオリジンの挙動とのあらゆる競合を解消することはできない。

HTTP 429も同様に完全ではない。一部のウェブサイトは、広範なセキュリティ設定、共有インフラ、または誤認されたトラフィックを理由にこのレスポンスを生成する。

HTTP仕様は、高負荷時にサーバーが429を使用することを求めていない。サイトは接続を切断したり、別の制御手段を用いたりできるため、クローラーが得られる明示的なフィードバックは少なくなる。

したがってCloudflareには、すべての429を不正行為の証拠として扱わないための保護策が必要だ。重要な証拠は、シグナルの帰属と理解が可能な条件下で、適応に繰り返し失敗したことである。

顧客が選択する閾値は、さらに複雑さをもたらす。2つのウェブサイトが同じトラストバンドを異なる形で扱う可能性があり、これはローカルな制御を支える一方、運用者にとっての期待を複雑にする。

この設計は、おそらく一律の許可またはブロックの判断より望ましい。パブリッシャーには、それぞれ異なるビジネスモデル、インフラ上の制約、AIによる発見に対する姿勢がある。

小売事業者は、商品推薦を支援する頻繁なエージェント訪問を歓迎するかもしれない。広告収益型のパブリッシャーは、測定可能な送客をもたらす検索システムを許可しつつ、学習用クローラーを制限する可能性がある。

Cloudflareは、すべての行動を単一のグローバルな道徳的順位に圧縮するのではなく、こうした違いを維持すべきだ。目的別の信頼評価は、単一の混合スコアより有用な制御を提供する。

同社は回復についても説明する必要がある。ボット運用者は、修正された行動がどれほど早く評価を改善するのか、過去の事象が時間とともにどのように減衰するのかを知るべきだ。

そうでなければ、継続的な説明責任は別の名前の恒久的な処罰になり得る。それは、反復される行動を通じて構築されるものとしてCloudflareが説明する信頼の考え方と矛盾する。

決定的な試金石は公開報告だ。CloudflareはRadarを通じてスコアを共有する計画だとしているが、発表ではそこでの表示や利用可能な証拠は明示されていない。

信頼できる公開システムは、観測結果と結論を区別すべきだ。関連する期間、信頼度、測定シグナル、行動上の重要な変化を示す必要がある。

また、帰属に争いがある場合も明示すべきだ。Cloudflareの可視性は広範だが、可視性が不確実性をなくすわけではない。

ウェブサイト所有者とボット運用者が次に注視すべきこと

次の試金石は、Cloudflareが説明責任の原則を、透明で異議申し立て可能な運用システムへ転換できるかどうかだ。

最初に注視すべきシグナルは、Radarの公開リリースである。Cloudflareは信頼情報を公開し、スコアを社内システムの外からも見えるようにする計画だとしている。

重要なのは、Radarに新たなバッジが追加されるかどうかではない。各トラストバンドに具体的な行動、期間、変化を説明する十分な証拠が含まれているかを確認すべきだ。

詳細な報告は、Cloudflareの中心的な主張を強化する。単なるラベルでは、スコアリングの論理を示さないまま、市場に評価者を信頼するよう求めることになり、その主張を弱める。

2つ目のシグナルは、顧客への提供状況だ。Cloudflareは、認証済みボットのトラフィックをどう扱うかを決める閾値を顧客が選べるようにする計画だ。

このリリースにより、信頼が情報フィールド、ルール作成の入力、あるいは自動執行の仕組みのどれとして機能するのかが明らかになる。これらの選択肢には異なる運用リスクがある。

可視化されたフィールドは人によるレビューを支えるが、作業は増える。自動執行は拡張性に優れるものの、誤りによって検索インデックス、監視、アクセシビリティサービス、ユーザー主導のエージェントがブロックされる可能性がある。

顧客は、このシステムが既存の許可リストとどう相互作用するかも注視すべきだ。Cloudflareがすでに認識していたため、認証済みボットは従来、有利な扱いを受けてきた。

動的な信頼閾値は、行動が変化したときにその特権を狭めることができる。また、管理者が「認証済み」は依然として普遍的に安全を意味すると考える場合、ポリシー管理を難しくする可能性もある。

3つ目のシグナルは、運用者の対応だ。主要なクローラー提供者は、署名付きIDの採用、目的の分離、より明確なコンプライアンス慣行の公開によって、Cloudflareのモデルを検証できる。

技術的な証拠に基づいてモデルに異議を唱えることもできる。リクエストの帰属、robots.txtの解釈、レート制限への対応をめぐる対立は、手法の弱点を明らかにするだろう。

429レスポンス後のバックオフ動作を説明する文書に注目したい。検索、学習、ユーザー主導の取得を対象とする別々の識別子にも注目すべきだ。

こうした慣行は、説明責任ある自動化が共有ウェブ標準を通じて運用できるという主張を強める。曖昧さが続けば、より厳格なネットワークレベルの執行を求める主張が強まる。

ウェブサイト所有者にとって、認証済みボットに対する継続的な説明責任は、恒久的な認証より現実的な信頼モデルを提供する。これは、承認後にもソフトウェア変更や運用ミスが起こることを認めるものだ。

ただし、直接的な制御を置き換えるべきではない。パブリッシャーには引き続き、明確な設定、適切なレート制限、トラフィックログ、事業目標に沿った執行ルールが必要だ。

ボット開発者にとっても、メッセージは同様に直接的だ。暗号学的なIDは認知を得る助けになるが、その認知が有用であり続けるかは継続的な行動で決まる。

エージェントを構築するチームは、ウェブアクセスのポリシーを本番要件として扱うべきだ。robots.txtの解析をテストし、アクセス制限を尊重し、適応的なバックオフを実装し、デプロイメントをまたぐ変更を監視する必要がある。

開発者には、エージェントがリソースにアクセスした理由を説明する、長期にわたり維持可能な記録も必要だ。これは、プラットフォーム、パブリッシャー、仲介者の間でリクエストの目的について見解が分かれた場合に不可欠となる。

ナレッジワーカーも関連する問題に直面している。エージェント生成の回答は、ユーザーの視界の外で動作する取得システムへの依存を強めている。

より優れた説明責任レイヤーは、そうしたシステムがソースに透明な形でアクセスしているかをユーザーが理解する助けとなる。また、利便性がパブリッシャーが明示的に拒否した行動に依存している場合も明らかにできる。

現在のウェブには、ボット識別以上のものが必要だ。ID、宣言された目的、観測された行動、比例した結果を結び付ける方法が求められている。

Cloudflareはそのようなシステムを1つ提案したが、その正当性は証拠と適正手続きにかかっている。同社は、トラストバンドが正確で、理解可能で、訂正に開かれていることを示さなければならない。

今後数か月間は、公開スコア、顧客向け制御、クローラー運用者の対応に注目したい。それらを合わせれば、継続的な説明責任が共有標準になるのか、それとも別の民間ゲートキーピング層になるのかが分かるだろう。

ウェブサイト所有者は、執行を自動化する前に、Cloudflareの最終的な評価と自らのログを比較すべきだ。ボット運用者は、robots.txtとHTTP 429の両方に対する対応を今すぐ監査すべきである。

中心的な問いは、もはやボットがIDを証明できるかどうかではない。そのIDが、数千件のリクエスト、変化するポリシー、避けられないソフトウェア更新の後にも説明責任を保ち続けられるかどうかだ。