Cloudflare が Bot Preference Sync を発表 — robots.txt を AI ボット方針（Search / Agent / Training）と自動同期、全プラン対象

要約

Cloudflare は 2026-08-21、Bot Preference Sync を発表しました。ダッシュボードで設定した AI ボットの方針を、robots.txt の記述として自動的に生成・同期する機能です。Free から Enterprise まで全プランが対象で、提供開始は発表時点で「来週中」とされています。

解決しようとしているのは、「表明した方針」と「実際に強制しているルール」がずれるという問題です。多くのサイトで robots.txt は数年前に手で書かれた静的ファイルとして放置され、その一方で Cloudflare 側のボット制御設定だけが更新されていきます。この2層が食い違うと何が起きるか。公式の指摘は率直で、クローラー側は表明を無視するか、あるいは強制側の回避を試みる余地が生まれる、というものです。公式の言い方を借りれば、**「設定した preference が、そのまま publish される preference になる」**状態を作るのが狙いです。

仕組みはシンプルです。Cloudflare が生成したディレクティブを、既存の robots.txt の内容の前に付加します。既存の記述を消すのではなく、先頭に自動生成分を差し込む形です。方針は Search / Agent / Training の3カテゴリそれぞれについて、Allow、Block（広告ページは例外）、Block everywhere から選びます。選択内容が、対応する User-agent と Disallow のエントリへ自動的に反映されます。

Training についてはブロックの考え方が整理されました。 一律に遮断するのではなく、透明性を確保して協調するクローラーには Disallow を返して尊重を求めつつ、モデル学習への利用は防ぐ、という扱いです。そして Search と Training の両方を行う mixed-use のボットは、Training を不許可にした場合、透明性の要件を満たさないとブロック対象になります。検索インデックスのために来ているのか学習データ収集のために来ているのかを区別できないボットに対する、実務的な回答と言えます。

移行については、既存顧客のうちレガシーの managed robots.txt を使っているものは、切り替え時に方針の確認を求められます。新規顧客は既定で有効になります。

何が変わったか

• ダッシュボードの AI ボット方針から robots.txt を自動生成・同期。手書きの静的ファイルを維持する必要がなくなる
• 生成されたディレクティブは既存の robots.txt の内容の前に付加される
• 方針は Search / Agent / Training の3カテゴリごとに Allow / Block（広告ページは例外）/ Block everywhere を選択
• 選択内容が対応する User-agent と Disallow のエントリへ自動反映
• Training は「協調するクローラーには Disallow を返して尊重を求める」扱いに整理。透明性を確保したクローラーを一律遮断しない
• mixed-use ボット（Search と Training の両方を行う）は、Training 不許可時に透明性要件を満たさないとブロック対象
• 全プラン（Free 〜 Enterprise）で利用可能
• 提供開始は発表時点で「来週中」。新規顧客は既定で有効、レガシー managed robots.txt 利用者は移行時に確認あり

業務インパクト（一般企業向け）

「AI に学習させてよいか」という判断を、明文化して公開する作業が設定1回に縮みます。 多くの企業サイトでこの判断は、そもそも誰も決めていないか、法務が決めた方針が技術側に伝わっていないか、伝わったが robots.txt に反映されていないかのどれかです。今回の機能は3番目を構造的に解消しますが、1番目と2番目は解決しません。むしろ、設定画面で Search / Agent / Training の3択を迫られることで、決めていなかったことが可視化されます。導入時には、この3カテゴリについて自社の方針は何かを法務・広報と確認するところから始めるのが正しい順序です。

3カテゴリの区別は、方針として意味が違う点を押さえてください。Search は従来の検索インデックス目的で、ブロックすれば検索流入が減ります。Training はモデルの学習データ収集で、ブロックしても直接の流入には影響しません。Agent は AI エージェントがユーザーの代理でアクセスするケースで、ここをブロックすると**「AI 経由で自社サービスを使おうとした利用者」を締め出す**ことになります。「AI にはコンテンツを渡したくない」という漠然とした方針で3つとも塞ぐと、意図しない副作用が出ます。特に Agent の扱いは、今後の顧客接点として無視できない領域です。

mixed-use ボットの扱いは、判断が必要な論点です。 Search と Training を同じクローラーで行うベンダーに対し、Training を不許可にすると、透明性要件を満たさない限りブロックされます。つまり Search のトラフィックも一緒に失う可能性があるということです。検索流入を主要な集客経路にしている事業では、「学習は嫌だが検索には出たい」という要求が技術的に両立しない相手が存在する、という前提で判断する必要があります。導入前に、自社に来ているボットの内訳を確認しておくべきです。

情シス側の運用としては、robots.txt が手動管理から自動生成に変わることの記録を残してください。既存の記述は前に付加される形で残りますが、「なぜこの記述になっているか」を追う導線が Cloudflare のダッシュボードへ移ります。サイト移管やベンダー変更のときに、この経緯が引き継がれないと、意図せず方針が失われます。レガシー managed robots.txt を使っている場合は、移行時の確認プロンプトが唯一の意思決定ポイントになるので、担当者不在のまま既定で流さないことが重要です。

副業・個人活用視点

Free プランから使えるのが実務上いちばん大きい点です。個人ブログ、ポートフォリオサイト、小規模なメディアでも、AI 学習利用の可否を自分で決めて公開できます。これまで robots.txt に AI クローラーの User-agent を手で書き並べるのは、新しいクローラーが出るたびに追記が必要な作業でした。ベンダー名を追いかけ続ける前提の運用は個人には維持できません。カテゴリ単位で方針を選ぶ形になれば、その追跡が不要になります。

制作を受託している立場では、納品物のチェック項目に加える価値があります。 サイト制作の見積もりに「AI クローラー方針の設定」を1項目として入れる、という売り方が成立します。作業自体は設定画面の3択ですが、クライアントに Search / Agent / Training の違いを説明して意思決定させる部分に価値があります。技術作業ではなく、判断の整理を提供する仕事です。

コンテンツで収益を得ている個人にとっては、Training のブロックが**「学習に使われたくない」という意思表示の手段**になります。ただし期待値は正確に持つべきです。robots.txt は強制力のある仕組みではなく、協調するクローラーが尊重するものです。今回の設計も「透明性を確保して協調するクローラー」を前提にしています。協調しない相手には効きません。 そこは Cloudflare のボット制御側（強制する層）の仕事であり、Bot Preference Sync はその2層を食い違わせないための機能である、という整理が正確です。

Agent カテゴリの扱いは、個人の事業形態によって答えが変わります。AI 経由の流入を想定するなら Agent は開けておく判断がありえますし、自分のコンテンツを AI に要約されて読者が本文に来ないことを避けたいなら閉じる判断もあります。3択を「全部ブロックが安全」と処理せず、自分の集客がどこから来ているかを見てから決めることをおすすめします。