この手順で完成するもの
このワークフローを終えると、あなたの Cloudflare ゾーンには、AI ボットのトラフィック3分類——検索（Search）、エージェント（Agent）、学習（Training）——それぞれに対する、明示的で意図的なポリシーが設定されています。ドメインに適用されていたデフォルトをそのまま引き継いだ状態ではありません。どのクローラーを許可し、どれをブロックし、それがどのページに適用されるのかを正確に把握でき、robots.txt とエッジでの強制ルールが実際に整合した状態になります。
対象読者： Cloudflare 経由で配信している Web サイトの運営者——メディア、SaaS のマーケティングサイト、EC ストア、ブログなど——で、AI システムによる学習・要約・エージェント経由の閲覧を許可するかどうかを、プラットフォームのデフォルト任せではなく自分で決めたい方。
前提条件：
- Cloudflare を経由しているドメイン（プランは問いません。Free でも可。以下の一部の手順は有料プラン限定で、その旨を明記しています）
- 少なくともドメインレベルのセキュリティ設定権限を持つダッシュボードアクセス
- 監査と設定に20〜30分。その後は日次〜週次で数分のモニタリング
完了の定義： ゾーンのセキュリティ設定で、検索・エージェント・学習のそれぞれに（デフォルトではなく）意図した選択が入っており、公開中の /robots.txt がその選択を反映しており、AI Crawl Control でブロックしたかったボットが実際にブロックされていることを確認できている状態。
なぜ今これが重要なのか：9月15日に変わったこと
Cloudflare は、2025年9月の robots.txt への Content Signals Policy 追加と、2026年7月1日の「Content Independence Day」を起点に、AI トラフィックの制御を段階的に作り上げてきました。後者では、それまでの「AI か AI でないか」という雑な一つのトグルが、名前を持った3つのカテゴリに初めて分割されました。
- 検索（Search） — 検索インデックスを構築し、後からリンクや短い抜粋を返すためのクロール。Cloudflare の説明では、これはあなたに参照トラフィックをもたらすべきトラフィックです。
- エージェント（Agent） — 今この瞬間、人の代わりに動いているリアルタイムの自動アクティビティ。たとえばチャットアシスタントがページを取得する、ブラウザ操作エージェントがタスクを完了する、といったものです。
- 学習（Training） — モデルの学習やファインチューニングのためのクロール。あなたのコンテンツはリンクで返ってくるのではなく、恒久的にモデルの重みに吸収されます。
2026年9月15日、Cloudflare は自動的に適用される内容を変更しました。この日以降に新規で Cloudflare にオンボーディングするドメインで、広告収益型と判定されたサイトのデフォルト設定は次のようになります。
カテゴリ | 広告掲載ページでのデフォルト |
|---|---|
検索（Search） | 許可 |
エージェント（Agent） | 広告のあるページではブロック |
学習（Training） | AI 学習を不許可（Disallow AI Training） |
広告を出していない新規ドメインは、3カテゴリとも「許可」がデフォルトです。既存顧客が黙って切り替えられたわけではありません。Cloudflare は15日までの間に、ダッシュボードからオプトアウトするための猶予期間を設けており、実際のドメイン単位の移行ルールは単一の新しいデフォルトよりも細かいものでした（後述します）。
広告を配信するページにより厳しいデフォルトが適用される理由は、ページ上の広告が「そこに人間が見ることを想定していた」というシグナルだからです。Cloudflare 自身の数字によると、2026年6月時点で、検索インデックス・エージェントの取得・学習を単一のユーザーエージェントの背後で混在させる「兼用クローラー（mixed-use crawler）」が、検証済みクローラートラフィックの 36% 超 を占め、最大の区分になっていました。また、Cloudflare ネットワーク上の全クローラーリクエストに占める AI 学習の割合は、2025年春の約22%から2026年6月には52% へと増加しています。今回の変更が狙っているのは、まさにこのトラフィックです。
はじめる前に：カテゴリについて理解しておくべき3つのこと
1. 一部のクローラーは「兼用」であり、ブロックと AI 学習の不許可で挙動が変わる。 Googlebot、Bingbot、Applebot はそれぞれ二役を担っており、一つのユーザーエージェントで検索のためにも学習のためにもクロールします。Cloudflare は Apple、Google、Microsoft を「Accountable（説明責任を果たす）」オペレーターと呼んでいます。彼らは4つの条件を満たしているからです。すなわち、学習に関する robots.txt の設定を尊重すること、AI 要約からのオプトアウト手段を提供すること、学習に何が使われたかを URL 単位で可視化すること、そして学習をオプトアウトしても検索での表示に悪影響がないことを示せること、です。
2.「AI 学習を不許可」と「ブロック」は同じ設定ではなく、その違いこそが要点です。 AI 学習を不許可にすると、Google-Extended や Applebot-Extended のような学習専用のユーザーエージェントに向けた Disallow の意思表示が robots.txt に公開されます。Accountable な兼用クローラーはその意思表示を読み取り、学習だけをスキップして検索のためのクロールを自発的に続けます。つまり検索での露出は維持されます。Accountable ではないその他の学習クローラーは、エッジで完全にブロックされますが、そうしたオペレーターは学習専用のボットを別に動かしているため検索には影響しません。これに対して単なるブロックは、9月15日以降、Googlebot、Bingbot、Applebot 自体も遮断するようになりました。つまり、それらの検索結果からあなたのコンテンツも消えます。学習は止めたいが検索は残したいなら、選ぶべきはブロックではなく「AI 学習を不許可」です。
3. Bing はまだ robots.txt の学習設定を尊重していません。 Applebot と Googlebot は現在、学習専用の Disallow 指示を尊重します。Microsoft は Bingbot 向けに同等の仕組みを構築中で、2027年前半を目標としていますと述べています。それまでの間、「AI 学習を不許可」を選ぶと robots.txt にその意思表示は書き込まれますが、Bing の学習目的のクロール挙動がそのシグナルだけで変わることはありません。Bing 経由の学習露出が特に気になる場合は、Bing 自身の NOARCHIVE メタタグや Content Removal ツールが暫定的な手段になります。
ステップ1：自分のサイトが実際どうなっているかを確認する
自分の現在の設定を把握しているつもりで進めないでください。必ず確認します。
操作： Cloudflare ダッシュボードでドメインを開き、Security → Settings に進み、AI ボットポリシーの制御項目を探します（新しい3カテゴリの UI が旧来の単一の「Block AI Bots」トグルを置き換えていますが、移行が済んでいないアカウントでは旧トグルがまだ表示されることがあります）。別途、ブラウザまたは curl https://yourdomain.com/robots.txt で公開中の robots.txt を取得し、Cloudflare 管理のコメントマーカーで始まるブロックがあるか確認します。現在のルールが AI クローラーからどう読めるかは、Auspia の Robots.txt AI クローラーチェッカー で突き合わせることもできます。
期待される結果： 検索・エージェント・学習それぞれに1つずつ、計3つの設定があり、各々が「許可 / 広告のあるページではブロック / ブロック」のいずれかに設定されています（「AI 学習を不許可」は学習にのみ用意された4つ目の選択肢です）。Bot Preference Sync または管理対象 robots.txt が有効であれば、公開中の robots.txt に Cloudflare 管理のセクションがあり、具体的なボットのユーザーエージェントと Disallow / Content-Signal の行が並んでいるはずです。
品質チェック： 3つの設定が、移行が勝手に決めた内容ではなく、あなたが本当に意図する内容と一致しているか確認します。既存顧客に対する Cloudflare 公表の移行ロジックは次のとおりです。以前に旧来の「Block AI」トグルを有効にしていた場合、学習＝AI 学習を不許可、検索＝許可のまま、エージェント＝広告のあるページではブロック、へと移行されました。以前に学習そのものを「ブロック」または「広告のあるページではブロック」に設定していた場合も、AI 学習を不許可へ移行されました。どちらの移行経路も「検索は維持したいはず」という前提に立っています。もし兼用クローラーを（検索からも含めて）完全に排除したかったのであれば、今の設定はそうなっていません。明示的に「ブロック」を選ぶ必要があります。
復旧手順： セキュリティ設定に旧来の単一の「Block AI Bots」トグルしかなく、3カテゴリの内訳が表示されない場合、そのアカウントはまだ新しい制御項目へ移行していません。別の新しい設定画面である「Configure AI bot policies」を探してください。移行期間中は旧トグルと並んで、今後はそこが詳細な制御の置き場所になります。
ステップ2：カテゴリごとにポリシーを決める（一括の答えにしない）
ここが実際の意思決定ステップです。カテゴリごとに個別に検討します。
検索。 これをブロックする人はほとんどいません。Cloudflare によれば、検索ボットをブロックすることを選ぶサイトは1%未満です。検索での可視性を失う価値は通常ないからです。検索インデックスから外すべき明確な理由（ステージング環境、ペイウォール内のアーカイブなど）がない限り、許可をデフォルトにしてください。
エージェント。 これらは、今まさにあなたのサイトで何かをしようとしている人のために、リアルタイムで動いているボットです。価格を確認する、予約を完了する、チャットの回答に事実を一つ取り込む、といった行為です。収益化しているページや広告ページでエージェントのトラフィックをブロックすることが新しいデフォルトの根拠になっているのは、エージェントの訪問が人間の訪問のような広告インプレッションを生まないからです。その人間の注意そのものがビジネスモデルである場合（メディア、ディスプレイ広告を載せるコンテンツサイト）は、広告のあるページではブロックが妥当です。逆に、広告ページであってもエージェントにタスクを完了してほしい場合——たとえばエージェント経由のトラフィックが自分のところではコンバージョンする場合——は許可を選びます。
学習。 本当の意思決定はここにあり、用語が人を混乱させるところでもあります。
- コンテンツがモデルの学習に使われるのは止めたいが、Google、Bing、Apple の検索プロダクトでの露出は維持したいなら、AI 学習を不許可を選びます（Bing の現状の遅れを踏まえると、「現時点で Google と Apple については維持、Bing は保留」と理解してください）。これは Cloudflare が推奨する中庸の道であり、検索と学習のトレードオフのために特別に作られた設定です。
- Googlebot、Bingbot、Applebot による検索クロールを完全に失うことを、それらの学習モードの挙動もブロックする代償として受け入れられる場合に限り、ブロックを選びます。これが現在の厳格な選択肢です。9月15日以降、ブロックは兼用クローラーにも適用されるようになり、以前はそうではありませんでした。
- 自分のコンテンツが AI モデルの学習に使われて構わない場合、たとえば AI 回答での引用露出を最大化したく、学習されることをその対価として受け入れる場合は、許可を選びます。
操作： Security → Settings → Configure AI bot policies で、3つのドロップダウンそれぞれを決めた内容に設定します。
期待される結果： ダッシュボードがカテゴリごとの明示的な選択を反映し、（Bot Preference Sync が有効なら）それに一致する robots.txt のブロックを自動で公開し始めます。手作業でのファイル編集は不要です。
品質チェック： 学習についての選択を、次の一文に照らして読み返してください。「検索での可視性を維持したいのか、そうではないのか」。維持したいなら、それはブロックではなく AI 学習を不許可です。「ブロック」という言葉が AI 学習を止めるためにどれほど魅力的に響いても、です。
復旧手順： ある設定を選んだ後に検索トラフィックが落ちた場合は、AI 学習を不許可ではなく誤ってブロックを選んでいないか確認します。これはこの設定で最もよく起きる自滅的なミスです。名前のせいで「ブロック」のほうが「より多くを行う」選択肢に聞こえますが、学習に関しては、望まないかもしれないこと（検索も失う）を実際に行います。
ステップ3：Bot Preference Sync を有効にして robots.txt を設定に一致させる
ダッシュボードの設定と robots.txt ファイルは別々のシステムであり、両者が食い違うと、一部のクローラーはその不一致を口実にあなたの意思表示を無視します。Cloudflare の Bot Preference Sync は、セキュリティ設定の選択内容から robots.txt を直接生成することで、このずれを埋めます。
操作： 同じ AI ボットポリシーの設定エリアで、Bot Preference Sync を有効にします（新規顧客ではデフォルトで有効です。旧来の管理対象 robots.txt 機能を使っていた既存顧客は、移行時に確認と承認を求められます）。
期待される結果： Cloudflare が robots.txt の先頭に管理ブロックを追加します。# BEGIN Cloudflare Bot Preference Sync / # END のコメントで囲まれ、影響を受ける具体的なユーザーエージェントとその Disallow ルールが列挙されます。あなた自身の robots.txt に元からあったカスタムルールは削除されず、管理ブロックの下にそのまま残ります。
品質チェック： 有効化後に /robots.txt を再度取得し、管理ブロックが現れ、ステップ2の選択と一致していることを確認します。たとえば学習を AI 学習を不許可に設定したなら、学習専用のユーザーエージェント（Google-Extended、Applebot-Extended など）に Disallow ルールが付き、汎用の Googlebot / Applebot / Bingbot のユーザーエージェントは検索のためにブロックされていない、という状態が見えるはずです。
復旧手順： 特定のクローラーオペレーターと個別の特別な取り決めがあり（たとえば有償のコンテンツライセンス契約）、カテゴリ単位のポリシーではそれが壊れる場合は、Bot Preference Sync をオフにして自分の robots.txt を手で編集します。カテゴリのトグルはゾーン全体のポリシー向けに作られており、オペレーター単位の例外向けではありません。
ステップ4：ポリシーが「要求」ではなく実際に「強制」されているか確認する
robots.txt はあくまでお願いです。技術的にクローラーがそれを無視することを止めるものではありません。ここが飛ばされがちなステップであり、ステップ2の判断が現実のものか机上のものかを教えてくれるステップです。
操作： ゾーンの AI Crawl Control を開きます（Free を含む全プランで利用可能です。検出精度は Bot Management のあるプランのほうが高くなりますが、可視化機能はどこでも動きます）。Crawlers タブを確認します。ここにはサイトに到達したすべてのボットが、Robots.txt violations 列とともに一覧されます。
期待される結果： ボットごとのリクエスト数と違反数を含む表が表示されます。不許可またはブロックに設定したボットで違反数がゼロでない場合、そのボットは現在あなたの robots.txt を無視しています。
品質チェック： 違反が表示されているボットについて、「Most popular paths」で実際に何にアクセスしているか（フラグの立ったパスに絞り込んで）を確認し、本当に守りたいコンテンツに触れているかどうかを見ます。
復旧手順： ボットが宣言した設定を無視している場合、robots.txt だけでは止められません。AI Crawl Control の「Enforce robots.txt rules」アクション（内部名で Robotcop と呼ばれることもあります）を使い、宣言したルールを実際の WAF ルールに変換します。これにより、非準拠のボットはオリジンに到達する前に Cloudflare のエッジでブロックされます。「準拠をお願いする」状態から「準拠を強制する」状態へ移行できます。この手順は WAF を使うため、利用可否はプランの WAF アクセスに従います。
ステップ5：単にブロックするのではなく収益化するかを決める
学習についての判断が「学習アクセスは認めない」だった場合、一律ブロック以外にもう一つの選択肢があります。課金するのです。
操作： 関心があれば、Cloudflare の Pay Per Crawl プライベートベータに登録します（Cloudflare の登録ページから、または Enterprise のお客様は担当営業経由で）。アカウントレベルで有効化した後（Manage Account → Settings → Pay Per Crawl → ドメインの Visibility を Visible に設定）、ゾーン全体に単一の定額従量価格を設定し、クローラーごとに「許可（無料）」「課金（自分の価格で請求）」「ブロック」を選べます。
期待される結果： Web Bot Auth（クローラーを識別する Ed25519 署名付きリクエスト）で認証するクローラーが、課金に設定したページを要求すると、crawler-price ヘッダーを伴う HTTP 402 Payment Required を受け取ります。支払いに同意して再試行するか、自分の価格をカバーする crawler-max-price ヘッダーを最初から付けていれば、課金済み金額を確認する crawler-charged ヘッダーとともにコンテンツを受け取ります。Cloudflare が merchant of record として決済を処理します。
品質チェック： これは Cloudflare に支払い情報を登録し、402 のフローに対応しているクローラーに対してのみ機能します。すべてのボットに対する万能のトグルではありません。それ以外の相手にとっては、課金設定は実質的にブロックと同じように振る舞います。Cloudflare は、それでも将来の有償関係に前向きであるというシグナルとして機能しうると注記しています。
復旧手順： この機能はプライベートベータです。受け入れられない、あるいは待ちたくない場合、同じクローラーに対して今日利用できる選択肢は AI 学習を不許可かブロックのままです。
例外への対応：特定の AI 事業者からアクセスを求められたら
ゾーン全体のポリシーにもかかわらず、AI 企業から明示的なアクセスを求める打診——提携、引用の契約、ライセンスの相談——が届くことがあります。
カテゴリ全体を開き直さずに限定的な例外を与える方法は2つあります。
- Manage AI crawlers でのクローラー単位の上書き： その特定のボットの行をブロック／課金から許可に切り替えます。カテゴリ全体の学習・エージェント設定とは独立して行えます。
- robots.txt を直接手で編集： Bot Preference Sync をオフにしている（あるいは例外を管理ブロックの外に置く）場合、Cloudflare の管理セクションの下に、その1つのユーザーエージェント向けの限定的な Allow を追加できます。
いずれの場合も、ゾーン全体のカテゴリポリシーをデフォルトのままにし、名前を挙げた例外は記録に残す意図的な判断として扱ってください。逆ではありません。
完成した結果を検証する
設定が反映されたら、このチェックリストを一通り実行します。
- [ ] セキュリティ設定に、検索・エージェント・学習それぞれの明示的で意図的な値が入っている（見直していないデフォルトではない）
- [ ] 公開中のドメインの
/robots.txtに、それらの設定と一致する Cloudflare 管理のブロックがある - [ ] AI Crawl Control の Crawlers タブに、想定どおりのボットが表示され、ブロック／不許可に設定したものの違反がゼロまたはほぼゼロである
- [ ] AI 学習を不許可を選んだ場合、Googlebot / Applebot による検索クロールが通常どおり続いていることを（Search Console / Bing Webmaster Tools、あるいはオーガニックトラフィックを眺めるだけでも）確認した
- [ ] robots.txt の強制（Robotcop）を有効にした場合、生成された WAF ルールが下書きのままではなくデプロイされ有効になっている
- [ ] どの設定をなぜ選んだかを記録してある。次回の見直しがゼロから始まらないようにするため
結果を維持する
これは一度設定したら忘れていい類の設定ではありません。軽い頻度で見直します。
- 毎月： AI Crawl Control の Metrics タブで、ポリシーを決めていない新しいボットがいないか確認し、違反数も再確認します。
- Bing が Bingbot 向けの学習設定対応を出荷したとき（Microsoft によれば2027年前半目標）：その時点で Bing が Google と Apple の現在の挙動に追いつくため、現在の設定が意図した「検索は維持・学習はブロック」という結果をまだもたらしているかを再評価します。
- 広告収益の状態が変わったときはいつでも：ディスプレイ広告を追加または削除すると、ページが従うデフォルトの系統が変わります。明示した設定がそれに対して依然として妥当かを再確認する価値があります。
FAQ
学習クローラーをブロックすると SEO の順位は下がりますか？ブロックではなく AI 学習を不許可を使うなら下がりません。AI 学習を不許可は、Accountable な兼用クローラー（Google、Apple、そして将来的には Bing）が学習をスキップしつつ検索のためにクロールを続けるよう、専用に作られています。一方、単なるブロックは9月15日以降、同じクローラーの検索挙動も遮断するため、それらの検索プロダクトでの可視性が損なわれます。
9月15日より前にすでに「Block AI Bots」を有効にしていました。設定はどうなりましたか？ Cloudflare が自動で移行しました。旧来の Block AI Bots は、学習＝AI 学習を不許可、検索＝許可、エージェント＝広告のあるページではブロック、になりました。移行が意図どおりだったと決めつけず、上のステップ1で実際にそうなっているか確認してください。
これは Free プランでも使えますか？使えます。AI Crawl Control、検索／エージェント／学習のカテゴリ設定、Bot Preference Sync はいずれも Free を含む全プランで利用できます。一部の強制の詳細はプランによって異なります。たとえば robots.txt の強制は WAF を通り、Free プランのボット検出はより高度な Bot Management の検出 ID ではなくユーザーエージェント文字列に依存します。
AI Crawl Control と AI ボットのセキュリティ設定は何が違うのですか？セキュリティ設定はポリシーを決める場所です（カテゴリごとに、許可／広告ページでブロック／ブロック／AI 学習を不許可）。AI Crawl Control は実際に何が起きているかを監査する場所です。ボットごとのリクエスト数、robots.txt の違反、パス単位の詳細が見られ、宣言した robots.txt ポリシーを強制される WAF ルールに変換できます。
これらの設定を行った後、robots.txt を手で編集する必要はありますか？ Bot Preference Sync が有効なら不要です。ダッシュボードの設定に基づいて適切な robots.txt ブロックを書いて維持してくれます。手動での編集が必要になるのは、管理対象のカテゴリの外側にあるオペレーター単位の例外を作る場合だけです。
著者：Julian Mercer、Auspia のテクニカル SEO 実務家（14年）。クロール可能性、スキーマ、レンダリング、AI が読めるコンテンツの技術的基盤について執筆しています。
