robots.txtは「技術チームが手で保守する文書」ではなくなった
8月21日、CloudflareがBot Preference Syncを公開した。仕組みはひどく単純で、ダッシュボードで設定したAIボットの方針を、そのままrobots.txtとして書き出すだけだ。無料プランからEnterpriseまで全プランで使え、既存のrobots.txtがある場合は生成分を先頭に追記する。BEGIN Cloudflare Bot Preference SyncとENDのコメントで囲まれるため、既存のDisallow行は消えない。
地味な機能に見えるが、Cloudflareが潰しにきているのは業界が長年放置してきたねじれだ。サイトの意思表示は二層に分かれている。robots.txtという「お願い」と、ファイアウォールやボット管理という「実力行使」だ。この二つは矛盾したまま動いてしまう。robots.txtには拒否と書きながら、エッジのルールは同じクローラーを通している、という状態が普通に存在する。
Cloudflareはこの不一致を、クローラー側ではなくサイト側のリスクだと言い切った。同社ブログ（Jin-Hee Lee氏）は、宣言と実際のルールが食い違う場合、一部のクローラーはそれを「宣言を無視してよい根拠」あるいは「エッジのルールを回避する口実」として扱う、と書いている。だから「一度言えば済む（Say it once）」ようにする、というのが今回の設計思想だ。
「学習させない」と「検索から消える」を切り離す交渉
より重要なのは、Trainingの扱いが変わった点だ。
Cloudflareは7月1日に、AIボットの分類を従来の二分法から三つの行動類型へ組み替えている。Search（後で答えるためにコンテンツを収集・索引化する）、Agent（人の代理でリアルタイムに動く）、Training（モデルの学習・微調整のために収集する）だ。SearchとAgentには「許可」「広告のあるページでブロック」「全面ブロック」の三択が用意された。
今回変わったのはTrainingの「Disallow」の意味だ。学習拒否をrobots.txtに書き込みつつ、SearchとTrainingを兼ねるクローラーは検索インデックス目的でのアクセスを続けられる形にした。ただし無条件ではない。ボット認証（Verification）の観点で、両方を兼ねる事業者には四つの開示要件が課される。
- 何らかの仕組みで、robots.txtの「学習しない」意思を尊重すること
- サイト側にAI要約からのオプトアウト手段を提供すること
- どのページが学習に供されたかをURL単位で可視化し、あわせて検索側の指標も提供すること
- 学習を拒否しても通常の検索結果が悪化しないことを、公に示せること
満たさない事業者は、学習拒否を設定したサイトから単純にブロックされる。Cloudflareはこれを「透明性を入場料にする」と表現した。
この四条件は抽象論ではない。二番目と四番目は、パブリッシャーがこの二年間、最大手の検索事業者に要求し続けてきた内容そのものだ。本誌が先に報じたGoogleが「読者に指名させるボタン」をサイト側へ配った件も、同じ圧力の産物として読める。三番目——学習に使ったページのURL単位レポート——にいたっては、現時点で相当する仕組みを持つ大手事業者は確認されていない。
広告で食っているサイトは、既定値が反転する
もうひとつ、実務に効く変更がある。新規ドメインのオンボーディング時に「広告を掲載したページで収益化している」を選ぶと、Trainingの既定値がDisallowになる。それ以外の新規顧客には何も適用されず、ブロックも拒否も追加されない。
Cloudflareの理屈は明快だ。広告が載っているページは「人間に見せるために作られた」という宣言である、と。PPC Landの報道によれば、同社は8週間で二度この線を引いている。7月1日には、新規参加ドメインの広告掲載ページでTrainingとAgentのクローラーを既定ブロックする日付として9月15日を設定した。今回はオンボーディングの質問そのものを変えた。
数字が示す非対称
なぜここまでやるのか。背景の数値は公開されている。PPC Landがまとめたところでは、2026年6月初旬時点でCloudflareネットワーク上のHTMLコンテンツへのトラフィックの57.4%がボットで、うち学習系クローラーが50.6%、検索クローラーが10.7%。クロール数に対する送客の比率は、良い方で118クロールに1送客、悪い方は5万クロールに1送客に迫るという。
一方で、拒否には代償がある。RutgersとWhartonの研究として報じられているのは、robots.txtでAIクローラーをブロックしたニュースパブリッシャーが6週間で週次トラフィックの約7%を失った、という結果だ。プロトコルが任意である以上、失うものだけが確定して、守られるものは確定しない。TollBitの測定では、欧州のAIページフェッチャーの15%が拒否済みURLに到達していた。
今回のDisallow再定義は、この非対称を壊す試みとして読むのが正しい。「学習を断ると検索からも消える」という暗黙の取引を、契約条件の側から分解しにいっている。
日本のサイト運営者が今週やるべきこと
まず、自社のrobots.txtとエッジのルールが食い違っていないかを見る。Cloudflareを使っていなくても、この監査は今週やる価値がある。宣言と実装のズレは、今後「無視してよい根拠」として使われうるからだ。
次に、自社がどちらの funnel にいるかを決める。Cloudflare自身が例に挙げているとおり、ECは逆側にいる。「小さな部屋に合うソファ」と尋ねられたときに自社商品が出てくるためには、むしろ全部クロールさせ、学習もさせたい。広告収益で回るメディアは反対側だ。同じ「AIボット対策」という言葉で、正反対の設定が正解になる。この判断を技術部門に丸投げしている企業は、まず事業側で線を引き直す必要がある。
そして、カテゴリ単位で意思表示する運用に慣れておくこと。Bot Preference SyncはBotBaseに登録された新しいクローラーを自動で対象に含める。個別に交渉した相手だけ例外にしたい場合は、同期をオフにして手で書くしかない。自動追随と個別最適はトレードオフになる。
最後に留保も書いておく。これは一社の製品仕様であって、標準ではない。Cloudflareはウェブの2割強の前段に立つが、残り8割には及ばない。四条件を満たす事業者が本当に現れるのか、それとも「Cloudflare配下のサイトだけ挙動が変わる」という部分最適で終わるのかは、まだ誰にもわからない。それでも、robots.txtが「お願い」から「監査対象の出力」へ変わりつつあることは、そろそろ前提として扱ったほうがいい。