AI学習は断りたい。でもGoogle検索には出たい。Cloudflareの新設定を解説

Cloudflareに、検索用の巡回を残しながらAI学習を断る「Disallow AI Training」が加わりました。学習を止めたい場合でも、検索のために来るGooglebotなどを一律に遮断せずに済むようにする設定です。[1]

「自社の記事をAI学習に使わせたくない。でも、Google検索から来る人は減らしたくない」。Cloudflareを使うサイト運営者にとって、この二つを分けて選べるかは大切です。設定名の「Block」だけで判断すると、検索に必要なアクセスも止める可能性があります。

この記事は2026年9月18日に更新しました。9月15日のCloudflareの正式発表をもとに、以前の変更予告から説明を改めています。対象はCloudflareを導入済みで、サイトの設定を確認できる担当者です。どの設定を読み、変更後に何を確かめるかを順番に案内します。[1]

検索、AI学習、人に頼まれた訪問を分けて選ぶ

Cloudflareは、サイトへの通信を中継し、不要なアクセスを防ぐサービスです。自動でWebページを読みに来るプログラムを「クローラー」や「ボット」と呼びます。今回は、何のために読みに来るかで方針を選びます。

画面の名前	何のためのアクセスか	サイト運営者が考えること
Search	検索結果を作るためにページを集める	検索で見つけてもらうための巡回を許可するか
Training	AIの学習に内容を使う	記事などを学習用に使ってよいか
Agent	人に頼まれたAIがページを訪れる	AIによる閲覧や作業のための訪問を受け入れるか

一つのクローラーが、検索と学習の両方に関わる場合があります。そこで学習用として全て止めると、検索用のページ収集も止まってしまう、という問題がありました。[1]

新しいDisallow AI Trainingでは、対応する運営者へ「学習には使わないで」という方針を伝え、検索用の取得は残します。検索と学習を兼ねるクローラーの全てを無条件に通すのではなく、Cloudflareが対応する運営者として扱うものが対象です。他の学習用クローラーは遮断されます。[1]

ここでいう「方針を伝える」と「通信を止める」は、動作が異なります。店に来ること自体を拒否するのか、来店は認めたうえで資料の使い方を指定するのか、という違いに近いものです。方針を伝える部分は、相手側の対応も必要になります。

Disallow AI TrainingとBlockはどう違う？

AI学習の設定には、次の選択肢があります。正式な英語名も残しておくと、管理画面で見比べられます。[1]

設定	学習用の扱い	検索と兼用のクローラー
Allow	この項目では止めない	他の設定にも従う
Disallow AI Training	学習拒否の方針を伝え、対象外の学習用取得は遮断	対応するものは検索用に取得できる
Block on pages with ads	広告があると判定されたページで遮断	該当ページでは検索用取得にも影響する
Block	対象の取得を全ページで遮断	Googlebotなどの検索用取得も止まる

「学習は断りたいが検索には出たい」なら、新しいDisallow AI Trainingの説明を確認します。一方で、検索を含めて取得させたくない運営方針なら、Blockの意味が合う場合もあります。どちらも同じ「AI拒否」だと考えないことが大切です。

旧設定のBlock AI Botsを使っていた既存サイトには、新しい用途別設定への移行が案内されています。旧Blockがそのまま新Blockになるとは限りません。現在の値を管理画面で読み、移行した結果を確かめます。[1]

また、新しくCloudflareへ追加するサイトには、広告で収益を得るかによって異なる初期設定が示されます。既存サイトに、必ず新規サイト向けの値が入るわけではありません。過去の予告記事だけを根拠に、自社の設定を決めつけないようにします。

1．対象サイトの現在の設定を読む

最初の作業は、自社で何が選ばれているかを確認することです。まだ変更はせず、設定を変える前の値を残します。

1. Cloudflareの管理画面へログインし、対象のアカウントとドメインを選びます。ドメインは、サイトのアドレスに使われる名前です。
2. Security Settingsを開きます。日本語ではセキュリティ設定に当たる場所です。用途別の項目はConfigure AI bot policiesとして案内されています。[2]
3. Search、Training、Agentの値をそれぞれ読みます。「AIを拒否している」という一つのメモではなく、三項目を残します。
4. Bot Preference Syncの状態も確認します。これは、選んだ方針をrobots.txtへ反映する機能です。[3]

robots.txtは、クローラーへ読んでよい範囲などを知らせるファイルです。サイトの先頭に置かれ、例えば自社サイトのアドレスの後ろに /robots.txt を付けると内容を確認できます。説明のために他社のファイルを開くのではなく、自社の公開サイトのものを確認します。

Bot Preference Syncは、管理画面で選んだ方針とこのファイルの食い違いを減らすための機能です。複雑な個別ルールの内容まで、全て読み取って同期するわけではありません。[3] 独自のアクセス制限を使っているサイトは、それも別に点検します。

設定を操作する権限がない場合、選択肢が見つからない場合は、今の値を確認できたところまで残します。似た名前の別設定を変更して代用しないようにします。

2．自社の方針と設定を合わせる

例えば、会社の技術解説を公開しているサイトで「検索は許可するが学習は断る」と決めている場合を考えます。これは説明用の場面です。自社に同じ方針を一律に勧めるものではありません。

この場合、Searchは検索を許可する状態か、TrainingはDisallow AI Trainingかを確認します。Agentについては、人の指示でAIがページを読むことを認めるか、別に決めます。学習を断るために、Agentまで自動的に同じ扱いにする必要はありません。

変更する場合は、選んだ値が保存後も表示されることを確かめます。Cloudflareは新しい制御を全プラン向けに案内していますが、画面の表示言語や契約、権限で見え方は変わります。[1] 本記事では、実アカウントで設定を変更した結果までは検証していません。

続けて自社のrobots.txtを開き、学習拒否の指定が出ているかを見ます。Disallowは、後ろに書かれた範囲の取得を認めないという指示です。User-agentは、その指示をどのクローラーへ向けるかを表します。

ただし、全てのAIに共通する一行を足せば完了、という仕組みではありません。対象の名前と用途が違えば意味も変わります。現在のCloudflareの設定と、各運営者が受け付ける指定を照合します。Googlebot全体を拒否する設定は、学習だけを断るつもりのサイトでは目的と合いません。

Bingへの学習拒否には、まだ別の確認が必要

9月15日の発表では、Bingがrobots.txt経由の学習拒否に対応する時期は2027年初めが目標とされています。それまでは、CloudflareでDisallow AI Trainingを選んだだけで、Bingへその指定が自動で伝わるわけではありません。[1]

Bingは別の方法として、ページ内のNOARCHIVE指定によるコンテンツ利用の制御を案内しています。これは検索エンジンへページの扱いを伝える「metaタグ」という設定です。AIへの利用範囲にも関わるため、検索だけに関係する名前だと思って追加しないようにします。[4]

Bing向けにも学習やAI回答への利用を制御する必要がある場合は、Bingの公式説明で対象範囲を読み、サイトの方針と合わせます。[4] 本記事のCloudflare設定だけで、全サービスへの学習拒否が完了したとは扱えません。

検索の巡回を残すことと、AIの回答での利用を認めることにも、それぞれの設定があります。何に出したくて、何への利用を断りたいのかを先に決めると、必要な確認を絞れます。

3．設定名だけでなく、実際に読めるかを見る

次は、意図したクローラーがページを取得できているかを確認します。AI Crawl Controlは、Cloudflare上でAIクローラーのアクセスや拒否を調べる機能です。Cloudflareを通る対象サイトの通信を調べるため、サービスを導入していないサイトの全アクセスを見られるものではありません。[5]

管理画面で同じドメインを選び、AI Crawl Controlへ進みます。クローラーの一覧では、名称、運営者、取得要求、許可・拒否の設定を見比べます。取得が失敗した件数には、この機能による拒否以外のエラーも含まれるため、失敗件数だけで原因を断定しません。[5]

robots.txtの状態は、Directivesのタブでも確認できます。ここは、ファイルの状態や、その指定に反する取得要求などを見る場所です。[6]

例えば、設定では検索を許可しているのに、対象ページの取得が拒否されているなら、別のセキュリティルールが関わっていないかを見ます。逆に記録がない場合は、対象期間にその取得がなかった可能性もあります。「記録がないから正常」とも「全部止められた」とも判断できません。

ブラウザでページが開けることだけでは、Googleが同じページを取得できたかは分かりません。人が見るページと、自動取得に対する応答が違う場合があるためです。

取得が成功した件数を、同じページで比べる

Metricsの「All requests」は、拒否やエラーも含む取得要求の合計です。「Allowed requests」は、200〜299の応答を受けた取得を指します。応答とは、サイトがアクセスに返す結果のことです。成功した件数を確認したいときは、二つの数字を混同しないようにします。[8]

画面上部の絞り込みで、期間、クローラー、対象ページを合わせます。ページの指定に使う「Path」は、サイト名の後ろの部分です。例えば会社案内なら、自社のURLにある /company などを使います。特定ページの変化を調べるときに、サイト全体の数字だけを比べないためです。

比較用に残す場合は、Download CSVで表形式のデータを保存できます。出力には選択中の絞り込み条件が反映されます。変更後も同じ条件で取り出せるよう、保存したファイルとともに、対象ページと期間を残します。[8]

Googleでの取得は、URL検査でも確かめる

自社サイトの所有権を確認済みのSearch Consoleへ入り、調べたい公開ページのURLを上部の検査欄へ入れます。これは、Googleがそのページを登録・取得できる状態かを見る機能です。[7]

登録済みの情報を読むだけでなく、必要に応じて公開URLをテストし、今のページを取得できるかを確認します。ここでは記事名や検索語ではなく、自社ページのURLを入力します。アクセスを拒否された場合は、Cloudflare側の同じ時刻の記録と照らし合わせると、原因を絞る手掛かりになります。

公開URLのテストが成功しても、検索への登録や順位、AI回答への採用が保証されるわけではありません。[7] まず「Googleが現在のページを読める」という技術面を確認し、その後の掲載や訪問は別に追います。

変更後も、同じページを継続して見る

設定を変えたら、変更した日時、対象ドメイン、三つの用途の値を残します。そのうえで、同じページとクローラーについて、変更前後の取得の成否を比べます。

運用上は、次のように分けて確認できます。

観察するもの	問題があったときの確認先
保存された設定が運営方針と違う	Cloudflareの用途別設定
方針がファイルへ反映されていない	Bot Preference Syncと自社のrobots.txt
取得が拒否・失敗している	アクセス記録、他の拒否ルール、サイトの応答
ページは読めるが検索の訪問が減った	Search Consoleで対象ページ・検索語・期間を比べる

検索からの訪問が減った時期と設定変更が重なっても、それだけで原因が確定するわけではありません。取得の失敗が増えたのか、検索での表示が減ったのか、表示はあるがクリックされていないのかを分けて見ます。

学習用と検索用のクローラー名の違いは、AIクローラーの役割の解説でも確認できます。自社で検索からの訪問を大切にするなら、拒否を一律に解除するのではなく、運営方針に合う設定と、実際の取得結果の両方を確認していきます。