Cloudflare、検索・学習・エージェントのクローラー制御を分離。ただしBingの学習拒否シグナルはまだ自動適用されず

Cloudflareは9月15日、AI Crawl Controlを刷新し、クローラーの動作をSearch、Training、Agentに明確に分離するとともに、「Disallow AI Training」を追加した。有効にすると、Bot Preference Syncが各事業者に対応する学習拒否ルールを`robots.txt`で公開する。信頼できる用途分離の仕組みを持たない学習用クローラーについては、相手の自主的な順守だけに期待するのではなく、Cloudflareがネットワーク層でブロックできる。Apple、Google、Microsoftは、複数用途のクローラーを運用する「Accountable」事業者に分類されている。その認定要件には、学習からのオプトアウト、AI要約からのオプトアウト、URL単位の透明性、そして学習を拒否しても従来の検索に影響しないことが含まれる。

技術上の要点は、設定を伝えるシグナルとアクセス制御が同一ではないことだ。Googleの`Google-Extended`は制御トークンにすぎず、実際のクロールには既存のGoogleユーザーエージェントが引き続き使用される。Googleのドキュメントでは、これを拒否しても検索へのインデックス登録やランキングには影響しない一方、コンテンツを将来のGeminiの学習や一部のgroundingに使用することが制限されると明記されている。Appleには別途`Applebot-Extended`がある。Bingは現時点で主に`NOARCHIVE`とウェブマスターツールに依存している。Cloudflareによれば、サイト単位でrobotsによる学習拒否に対応するのは2027年初頭になる見込みであり、現時点では新設定を有効にするだけで同じ設定がBingへ自動的に伝わるわけではない。

今回の変更には移行上のリスクもある。従来の「Block AI Bots」は廃止され、Trainingに対する既存のBlock設定はDisallow AI Trainingへ移行される。一方、新しいBlockは、複数用途の検索クローラーまで遮断する。運用チームは、生成された`robots.txt`、WAFイベント、検索インデックス、クローラーの識別判定を改めて確認すべきだ。なお、これは法的または暗号学的な保証ではない。身元を偽装するクローラー、robotsルールに従わないクローラー、ユーザーの指示で動作するブラウジングエージェントについては、いまだ統一されたポリシーが存在しない。IETFにおけるAI利用設定の標準も、なお策定途上にある。