CloudflareでAIの巡回を確認・制限する方法

CloudflareのAI Crawl Controlを使うと、自社サイトを読みに来るAIの巡回を確認し、AIごとに許可・拒否を選べます。「受け入れたいAIは残し、利用方針に合わないAIだけを止めたい」というサイト・EC運営担当者に役立つ機能です。[1][2]

対象ドメインの通信がすでにCloudflareを経由していれば、管理画面で巡回の確認から個別設定へ進めます。この記事では、マグカップの商品ページ /products/mug を例に、アクセスを調べ、Allow／Blockを選び、変更後の結果を確認する流れを説明します。許可はAIの回答への引用や送客を保証するものではありません。

1. 利用条件とプラン差

利用には、Cloudflareアカウント、対象ドメインの接続、Cloudflare経由の通信が必要です。アカウントがあるだけでは使い始められないため、まず対象ドメインの接続状態を確認してください。[1]

項目	条件・違い
個別の許可・拒否	全プランにAllow／Blockの操作が案内されています
無料プランの検出	User-Agentという通信時の名乗りで、既知のAIを識別します
無料プランのMetrics	過去24時間の分析を表示します
Enterprise＋Bot Management	detection IDによる高度な検出と、分析期間の設定が比較表に示されています
拒否時の応答変更	有料プラン向けです。少なくとも一つのAIをBlockにする必要があります
Pay per crawl	巡回への課金機能で、参照資料では閉じたベータ提供です

プランを比較するときは、検出方法、分析期間、応答変更を分けて確認しましょう。開始ガイドの比較表は「All plans」と「Enterprise plans with Bot Management」を並べており、有料契約ならすべて同じ機能になるという意味ではありません。[1][2]

未接続のサイトは、公式の開始ガイドから接続条件を確認してください。ドメインの新規接続やDNS変更は本稿の対象外です。

2. 商品ページへの巡回を見る

最初は設定を変えず、対象サイトにどのAIが来ているかを調べます。操作前に対象ドメイン、確認したい期間、商品ページのパスを用意しましょう。

1. Cloudflareダッシュボードにログインし、対象のアカウントとドメインを選びます。
2. AI Crawl Controlを開きます。
3. Overviewで、AIの巡回の概要を確認します。
4. 日付、AI、運営元、ホスト名、パスのフィルターで調べる範囲を絞ります。[1][2]

マグカップの商品ページなら、パスを /products/mug に絞り、どのAIのアクセスが記録されているかを見ます。設定変更の前後を比べられるよう、確認期間、対象AI、パス、件数を控えておくと役立ちます。

全体の流れは「巡回を見る → 対象AIを選ぶ → Allow／Blockを設定する → 変更後の通信を見る」です。

一覧に表示がなくても、AIが一度も来ていないとは断定できません。期間やパスの絞り込みに加え、検出方法の限界もあるためです。特に無料プランは、既知のAIが自ら名乗るUser-Agentを使って識別します。[1]

3. AI一覧と操作欄を探す

次に、AIの名前、運営元、Requests、Actionが並ぶ一覧を探します。公式資料にはSecurityとCrawlersの表記差があるため、実際の画面に表示される一覧と操作欄を基準にしてください。[1][2]

公式ページ	タブの案内
Get started（2026年4月23日更新）	Crawlersで一覧を確認
Manage AI crawlers（2026年7月28日更新）	冒頭の操作案内はSecurity、続く一覧説明はCrawlers

一覧では、NameでAI名、Operatorで運営元、Categoryで用途の分類を絞れます。同じ会社が運営するAIでも用途が異なることがあるため、会社名だけでまとめず、対象AIの名前と分類を確認しましょう。[2]

Requestsには、許可されたアクセスと失敗したアクセスの件数が含まれます。失敗にはAI Crawl Control以外のルールや応答エラーによるものも含まれるため、「失敗件数＝この機能で拒否した件数」ではありません。[2]

対象の一覧や操作欄が見つからない場合は、別の設定を推測で変更しないでください。表記差の理由と実画面での確認範囲は、記事末尾にまとめています。

4. Allow／Blockを選ぶ

対象AIの行にあるAction／Actions欄で、許可するならAllow、拒否するならBlockを選びます。マグカップの例では、引用・送客や既存契約のために受け入れたいAIと、自社のコンテンツ利用方針に合わないAIを分けて判断します。[2]

変更前には、対象ドメイン、AI名、運営元、現在のAction、変更理由を控えます。Enforce robots.txtの設定が表示されている場合は、その状態も記録しておきましょう。

1. 許可する場合：対象AIの操作欄でAllowを選びます。公式資料では、AllowでもEnforce robots.txtを併用できると案内されていますが、本稿ではこの設定の変更は扱いません。[2]
2. 拒否する場合：対象AIの操作欄でBlockを選びます。Cloudflareは拒否を実行するため、対象ドメインのWAFカスタムルールを作成または更新します。WAFは、通信を条件に応じて制限する仕組みです。[2]
3. 設定を確認する場合：対象AIの行が意図した選択になっているかを確認し、変更時刻を記録します。

ここで重要なのは、分析のパスフィルターは、拒否範囲を指定する設定ではないことです。/products/mug だけを表示してからBlockを選んでも、「その商品ページだけを拒否する操作」とは扱えません。パス別の例外はWAF側の高度な設定にあたります。[1][2]

設定後は、次のMetricsで対象AIの通信結果を確認します。

5. 変更後の結果を調べる

Metricsを開くと、期間、AI、運営元、ステータスコード、ホスト名、パスで通信の内訳を確認できます。ステータスコードは、通信に対して返された結果を示す番号です。無料プランでは過去24時間が表示対象なので、変更後の確認を先延ばしにしないようにしましょう。[1]

マグカップの例では、設定したAIと /products/mug に絞り、変更後の時間帯を見ます。対象AIが再訪していなければ、設定は確認できても、実際の通信結果はまだ確認できません。

確認した状態	次に見ること
Allow後に成功した通信がある	対象AI・パス・時間帯が変更内容と一致しているか
Allow後も失敗が続く	別のWAFルール、Bot対策、サイト側の応答エラーの可能性
Block後に失敗がある	今回のBlockによるものか、既存設定や応答エラーによるものか
変更後のアクセスがない	対象AIの再訪後に確認

Allowは、ほかの制限をすべて解除する設定ではありません。 AI Crawl ControlのBlockはWAFカスタムルールで実行され、その処理はCloudflareのBot対策より先に行われます。Allowを選んでも、別のルールやBot対策が通信に影響する可能性があります。[2][4]

失敗の原因を調べるときは、対象AI、パス、変更時刻、選択したAction、変更後の応答結果をそろえて、既存のセキュリティ設定と照合します。これは担当者間で共有する記録項目であり、管理画面の入力欄ではありません。

Metricsの失敗件数だけでは、適用されたルールまで特定できません。原因が分からないままBot対策をまとめて無効にせず、該当する通信とルールを管理担当者と確認してください。

6. robots.txtの表示を読む

Directivesでは、AIに巡回の条件を伝えるrobots.txtの状態と、指示に合わないアクセスを確認できます。robots.txtに指示を書くことと、CloudflareのBlockで通信を拒否することは別の操作です。[2][3]

対象ドメインのAI Crawl ControlでDirectivesを開きます。上部の状態表示では、Cloudflareがrobots.txtを管理しているかを確認できます。有効な場合は、一般的な学習用AIを拒否する指示とContent Signals Policyが含まれると説明されています。[3]

RequestsとStatusは別の情報

Robots.txt availabilityでは、ホスト名ごとのrobots.txtへのアクセスを確認します。Requestsは選択期間内のアクセスの集計で、400未満の応答は転送も含めて成功、400以上は失敗として数えられます。[3]

一方、Statusはrobots.txtへの確認アクセスで得た応答コードであり、過去の各アクセスの結果とは別です。Requestsの成功件数が多くても、ファイルの内容まで正しいとは判断できません。[3]

Statusが404なら、確認アクセスではファイルが見つからなかった状態です。ファイルを置いていない場合は作成を検討し、すでに置いている場合はWAFなどのセキュリティ設定がアクセスを妨げていないかも確認します。マグカップを掲載するホスト名で、商品ページとは別にrobots.txtが読めるかを見ましょう。[3]

違反表示は現在の指示との照合

Robots.txt violationsは、現在のrobots.txtと過去のアクセスを照合した結果です。アクセス当時の指示違反をリアルタイムで記録した一覧ではありません。[3]

例えば、今日から /products/mug を拒否するDisallowを追加すると、変更前には許可していたアクセスも、現在の指示に照らして違反と表示され得ます。違反件数だけで「変更後も指示を無視している」と判断せず、指示の変更時刻とアクセスの期間を確認してください。[3]

7. 必要なら拒否時の応答を変える

有料プランでは、Block時に返す応答コードと本文を変更できます。少なくとも一つのAIをBlockにしていることが条件で、単に巡回を止めるだけなら必須の追加操作ではありません。[2]

1. AI Crawl ControlのSettingsを開きます。
2. Block response → Editへ進みます。
3. 応答コードを選び、Response bodyに平文のメッセージを入力します。
4. Saveを選び、設定値を確認します。[2]

選択肢は、アクセスを拒否する意思を示す403 Forbiddenと、支払いが必要と示す402 Payment Requiredです。WAF側で403・402以外の応答コードを手動設定している場合、ここで選んだコードを適用できず、選択欄が空になることがあります。[2]

402を選ぶだけでは、巡回への課金は始まりません。 Pay per crawlは参照資料ではclosed beta／private betaであり、通常のAllow／Blockや拒否時の応答変更とは分けて扱う必要があります。[2]

8. 最後のチェック

操作後は、次の項目を確認してください。設定内容と通信結果を対応させて記録すると、担当者が変わっても判断の経緯を追いやすくなります。

• 対象ドメイン、AI名、運営元が正しい。
• 選んだActionと変更時刻を記録した。
• 変更後のMetricsで対象AI・パス・応答を確認した。再訪がなければ確認待ちとした。
• 失敗の原因が不明な通信は、調査対象として残した。
• robots.txtも変えた場合は、指示の変更時刻を記録した。

まず一つのAIについて、この流れで自社方針に沿った設定と結果を確認しましょう。許可されたアクセス数は、AIの回答への引用数や購入数ではありません。巡回の制御と、その後の集客・売上の評価は分けて扱います。

このガイドの確認範囲

本稿は2026年9月10日時点の公式資料に基づく基礎ガイドで、管理画面での実操作・通信試験は行っていません。Security／Crawlersの表記差の理由や、Allow／Block選択後に追加の保存操作が必要かは、取得した公式ページ本文の範囲では確認できません。

新規接続、パス別の例外作成、Enforce robots.txtの詳細設定、個々の通信に適用されたルールを特定する操作は対象外です。これらを変更する場合は、現在の画面と該当する公式手順を確認してから進めてください。