CloudflareのAIクローラー既定ブロック、9月15日に本施行

要点: 2026年7月1日に予告されていたCloudflareのAIクローラー・デフォルト設定変更が、2026年9月15日に実際に施行された。広告表示ページでは、検索インデックス用の「Search」は既定で許可される一方、AIモデル学習用の「Training」とライブエージェント用の「Agent」は既定でブロックされる。対象は新規顧客・既存顧客の新規サイト・設定変更をしていなかった無料プランの既存サイトで、既に設定済みの有料プランサイトは対象外だ。

本メディアは7月4日(Pay Per Use発表時)、7月13日(Search/Agent/Training分類の解説)、8月10日(GooglebotがTrainingブロックに巻き添えで403を受ける不具合の警告)と、この一連の動きを3回にわたり報じてきた。今回は「予告されていた期限が実際に到来し、何が起きたか」という続報・総括にあたる。9月11日前後に専門メディアが指摘し始めたのは、Cloudflareダッシュボードの「失敗したリクエスト」表示が404・403・429を一括集計するため、実態以上にAIクローラーが大量にブロックされているように見える誤解を招く表示問題だ。あわせて、Pay Per Crawl(取得ごとの課金)からPay Per Use(AIが実際に回答内でコンテンツを利用した場合の課金)への移行事例も具体化しつつある。

aiseo-llmo.comの読者にとって重要なのは、「9月15日に何かが壊れた」という単純な話ではなく、「ダッシュボードの数字を鵜呑みにすると誤った判断をしかねない」という、より実務的な注意点が浮上している点だ。本記事では施行後に判明した論点と、今すぐ確認すべき具体的な手順を整理する。

最終更新日: 2026年9月22日

何が起きたのか

予告から本施行へ——7月1日の発表が現実になった

Cloudflareは2026年7月1日、ウェブサイト運営者がAIクローラーのトラフィックを「Search(検索インデックス用)」「Training(AIモデル学習データ収集用)」「Agent(ライブユーザーセッションの代理実行。AIアシスタントがリアルタイムで文書を取得する用途)」の3カテゴリに分けて個別に許可・ブロックできる機能を発表した。この時点でCloudflareは、9月15日をもってデフォルト設定そのものを変更する方針もあわせて予告していた。本メディアはこの発表を7月4日付・7月13日付の記事で詳報し、さらに8月10日付の記事では、この3分類の裏側にある「混合目的クローラー」という分類ロジックのせいで、GooglebotやBingbotがTrainingブロックの巻き添えを受けて403エラーを返すリスクがあることを報じた。

そして2026年9月15日、この予告されていたデフォルト設定変更が実際に施行された。広告を表示しているページにおいて、既定の挙動は次のように定まった。

• Search(検索インデックス用クローラー): 既定で許可
• Training(AIモデル学習データ収集用クローラー): 既定でブロック
• Agent(ライブエージェント用クローラー): 既定でブロック
• 用途を区別しない「混合目的クローラー」: 広告ページ全体で既定ブロック

この変更が適用されるのは、(1)新規にCloudflareを利用し始めた顧客、(2)既存顧客が新たに追加したサイト、(3)9月15日までに一度も関連設定を変更しなかった既存の無料(フリープラン)ユーザー、の3つに限られる。逆に言えば、既に有料プランでこの設定を明示的に構成済みだったサイトは対象外であり、意図的にオプトアウトしていたサイトの挙動が9月15日を境に強制的に上書きされるわけではない。この「対象範囲の線引き」は、7月時点の発表から一貫しており、今回の本施行でも変更されていない。

Cloudflareは自社が世界のウェブサイトのおよそ5分の1の手前に位置していると説明しており、この規模のインフラでデフォルト設定が変わることは、AIクローラーの巡回可能な範囲に無視できない影響を与える。Cloudflareが公表している統計によれば、自動化されたエージェント・ボットがWebリクエスト全体の50%以上を占めており、さらにAIクローラーのトラフィックの50%以上が「変更されていないページの再取得」に費やされているという。この「変更されていないページを何度も取得しに来る」という非効率性こそが、Cloudflareが一連の施策(3分類化・デフォルト変更・Pay Per Use)を進める動機の一つとして繰り返し語られてきた論点だ。

Matthew Prince CEOは今回の施行に際し、「ほとんどのサイト運営者はAIに発見されたい(most site owners want to be discoverable in AI)」という趣旨のコメントを寄せている。これは、Cloudflareの立場が「AIクローラーを一律に締め出す」ことではなく、「サイト運営者が用途ごとに選べるようにする」ことにあるという、これまでの発表と一貫したメッセージだ。一方でPrince氏は、一部のエージェント的タスクが、人間が行う1リクエストに対して約1000ページリクエストを生成するとも指摘しており、Agentカテゴリを既定ブロックにした背景には、こうした非対称な負荷への警戒があるとみられる。

Pay Per Useへの移行——実例が具体化し始めた

今回の本施行と並行して、Cloudflareが進めてきた「Pay Per Crawl(取得ごとに課金)」から「Pay Per Use(AIが実際に回答内でコンテンツを利用した場合に課金)」への移行も、実例を伴って進んでいる。7月1日に発表されたMonetization Gatewayは、x402プロトコルとステーブルコイン決済を用いた新しい決済基盤で、Webページだけでなくデータセット・API・MCPツールも課金対象に含められる点が特徴だ。

この移行の実例として、Ceramic.aiは検索結果への掲載に対して支払う方式を採用し、You.comはプレミアムコンテンツへのオンデマンド支払い方式を試験的に導入しているとされる。いずれも「クロールされた回数」ではなく「実際にAIの回答に使われたかどうか」を課金の起点にする発想であり、従来のPay Per Crawlが抱えていた「クロールされても引用されるとは限らない」という不透明さを解消しようとする狙いがあるとみられる。ただし、これらの事例は依然として試験段階のものが中心であり、Pay Per Useが業界標準として定着したと結論づけるのは時期尚早だ。パブリッシャー側にとっては、TrainingやAgentを一律ブロックするのではなく、条件付きで許可しつつ収益化する選択肢が現実味を帯びてきた、という段階として捉えるのが実態に近い。

ダッシュボードの「失敗したリクエスト」表示が誤解を招く

9月15日の本施行後、2026年9月11日前後からRemote Work Europe Newsをはじめとする専門メディアが指摘し始めたのが、Cloudflareダッシュボードの表示に関する問題だ。Cloudflareダッシュボードでは、AIクローラーの「失敗したリクエスト」件数が一つの指標として表示されるが、この集計はHTTPステータスコード404(存在しないページへのアクセス)・403(ブロックによる拒否)・429(レート制限)を区別せず一括して合算している。

この仕様は、9月15日のデフォルト変更後にサイト運営者がダッシュボードを確認する際、実態を見誤らせるリスクをはらんでいる。たとえば、あるサイトで「失敗したリクエスト」が急増していたとしても、その大部分が実は単に古いリンク・削除済みページへのアクセス(404)であり、Cloudflareの新しいデフォルト設定によるブロック(403)はごく一部に過ぎない、というケースが十分に起こり得る。しかし合算された数字だけを見ると、あたかも「大量のAIクローラーが新たにブロックされている」ように見えてしまう。逆に、実際にはAgentクローラーが大量にブロックされているのに、その影響がダッシュボードの一見穏やかな数字に埋もれて気づかれない、という逆方向の誤読も起こり得る。

Remote Work Europe Newsは、この問題への実務的な対処法として「各クローラーのユーザーエージェントを指定して直接リクエストを送り、返ってくるステータスコードを個別に確認する」という検証方法を推奨している。ダッシュボードの集計値という間接的な情報に頼るのではなく、GPTBotやClaudeBot、PerplexityBotといった個々のクローラーのユーザーエージェント文字列を使って対象URLに直接アクセスし、200(成功)が返るか403(拒否)が返るかを一件ずつ確認することで、初めて「本当にブロックされているのは何か」を正確に切り分けられる、という指摘だ。この検証方法の具体的な手順は後述する「今すぐできる対応策」で詳しく解説する。

「AIクローラーは単一の決定ではない」——一律ブロック/許可という発想の限界

同じくRemote Work Europe Newsが指摘しているもう一つの重要な論点は、「AIクローラー」とひとくくりにして許可・ブロックを決めること自体が、実態に即していないという点だ。たとえばOpenAI一社だけでも、目的の異なる複数のクローラーを別々に運用している。学習データ収集用のGPTBot、検索インデックス用のOAI-SearchBot、そしてChatGPTのユーザーがリアルタイムでページを参照する際に動くChatGPT-Userは、それぞれ技術的にも用途的にも別物だ。Cloudflareの3分類(Search/Training/Agent)は、まさにこうした「同じ企業のクローラーでも目的が違えば扱いを変えたい」というニーズに応えるために設計されたものだが、その前提となる「AIクローラーは単一の決定ではなく、企業ごと・目的ごとに複数存在する」という理解自体が、まだ多くのサイト運営者に浸透しきっていない可能性がある。

「AIを一律にブロックする」「AIを一律に許可する」という二択の発想でCloudflareの設定を眺めてしまうと、Search用クローラーまで意図せず巻き込んでしまったり、逆にTraining用クローラーを無自覚に許可し続けてしまったりする。今回の9月15日の本施行を機に、自社の設定がどのクローラー・どの目的カテゴリを対象にしているのかを、企業単位ではなく用途単位で棚卸しする必要性が、あらためて浮き彫りになったと言える。

Googlebot巻き添え問題との関係——今回のデフォルト変更で何が変わり、何が変わらないか

8月10日付の本メディアの記事で報じた通り、CloudflareはGooglebot・Bingbotを「Search + Training」の混合目的クローラーとして扱っており、Trainingブロックを有効にしていたサイトでGooglebot自体が403エラーを受け、検索インデックスから漏れるリスクが指摘されていた。この問題自体は2026年8月時点で既に報じられていたものであり、今回9月15日に本施行されたデフォルト変更とは、厳密には別の論点として区別しておく必要がある。

重要なのは、Cloudflareの公式発表によれば、9月15日のデフォルト変更は「これまで一度もAI Bot設定に手を加えたことがないサイト」に新たに適用されるものであり、既存サイトで何らかの設定変更を既に行っている場合、その設定が今回の一件によって強制的に上書きされ、Googlebotが新たにブロックされるようになるわけではないとされている点だ。言い換えれば、8月時点で報じられた「TrainingブロックによるGooglebot巻き添え」のリスクは、あくまで「Trainingブロックを能動的に選択した」サイト(あるいは今回新たにTrainingが既定ブロックになった新規サイト)に生じるものであり、「何もしていないから安全」という思い込みと、「9月15日を境に急に全サイトでGooglebotが締め出される」という誤解の、両方に注意が必要という状況だ。特に、既存の有料プランサイトで既に設定済みだったサイトの運営者が、この本施行のニュースを見て不必要な不安を感じているケースも一定数あるとみられ、まずは自社がそもそも「今回の変更の対象範囲」に含まれるかどうかを確認することが出発点になる。

専門家の見解の対立——Training/Agentをどう扱うべきかに正解はない

今回の本施行を受けて、専門家の間ではTraining・Agentクローラーの扱いをめぐる見解の対立も指摘されている。一方の立場は、AI引用がAI検索での発見の実質的な経路になりつつある中で、Trainingクローラーを許容することが、AI生成回答内での長期的な露出を維持する上で有利に働く可能性がある、というものだ。学習データに含まれなければ、そもそもAIモデルの回答の中で自社の情報が言及される機会自体が失われる、という発想に基づく。

もう一方の立場は、Agentクローラーをブロックすると、ユーザーの代理としてリアルタイムにページを取得するブラウジングエージェントが、そのサイトに全くたどり着けなくなってしまう、という懸念だ。AIアシスタント経由でユーザーが特定のページの内容を確認・要約させようとした際、Agentがブロックされていれば、そのリクエスト自体が失敗に終わる。

どちらの見解が「正解」というわけではなく、サイト運営者がAIリファラル経由の流入・直接訪問・従来型のロングテール検索経由の流入のどれを重視するかによって、最適なバランスは変わってくる。今回の本施行はあくまで「デフォルト値」を定めたものであり、個々のサイトが自社の集客構造に応じてこのデフォルトから意図的に外れる(あるいは維持する)判断を下すことが前提になっている制度設計だと理解しておきたい。

aiseo-llmo.com ユーザーへの影響

今回の本施行がaiseo-llmo.comの読者であるLLMO・GEO実務者にもたらす影響は、大きく3つの側面に整理できる。

第一に、Cloudflareを利用しているサイトでは、9月15日を境に自社の意図とは無関係に、AIクローラーへの露出状況が変化している可能性がある。特に、これまでAI Bot関連の設定を一度も触ったことがない無料プランのサイトは、今回のデフォルト変更の直接対象であり、Training・Agentが既定でブロックされる状態に自動的に切り替わっている。AI検索エンジンでの引用・言及を戦略的に狙っている事業者にとって、Trainingクローラーが既定でブロックされるという状態は、学習データへの取り込みという経路を自ら閉ざしていることを意味しかねない。自社のサイトがこの変更の対象範囲に含まれるかどうかを確認していない場合、意図せず機会損失を抱えている可能性がある。

第二に、前述のダッシュボード誤読リスクは、KPIレポーティングの信頼性に直結する問題だ。LLMO・GEO担当者がAI可視性・AIクローラーのアクセス状況を経営層やクライアントに報告する際、Cloudflareダッシュボードの「失敗したリクエスト」数を額面通りに「AIクローラーがブロックされた件数」として扱ってしまうと、実態(その多くが404による単なるリンク切れである可能性)を見誤ったまま報告してしまうリスクがある。これは、本メディアが前回(9月21日付)報じたGoogleのスクレイピング遮断強化に伴う「計測起因のノイズ」の問題と構造的に似ており、AI周辺の計測データ全般について、ダッシュボードの一次表示を鵜呑みにしない姿勢が求められる局面が続いている。

第三に、Pay Per Useへの移行が実例を伴って進み始めたことは、中長期的な収益機会の観点で無視できない。Ceramic.aiやYou.comの試験的な取り組みはまだ限定的ではあるものの、「クロールされること」自体ではなく「AIの回答に実際に使われること」に対して対価を得るモデルが技術的に実装可能な段階に入ったことを示している。広告収益に依存してきたメディア・パブリッシャー業態にとっては、Trainingクローラーを単純にブロックするか許可するかの二択ではなく、「条件付きで許可しつつ収益化する」という第三の選択肢を検討する材料が増えたと言える。

業種別に見ると、広告収益化ページを持つメディア・パブリッシャーは今回のデフォルト変更の直接対象になりやすく、影響も大きい。ECサイトでは商品ページのTraining/Agentへの露出方針が、AIショッピングアシスタント経由の流入に影響しうる。BtoB・SaaS事業者は、ホワイトペーパーや技術文書がAIの回答に引用されるかどうかが、リード獲得のロングテール経路に関わってくる。いずれの業態でも、「何もしなければどうなるか」を正確に把握した上で、能動的に設定を決める段階に来ている。

今すぐできる対応策

1. Cloudflareダッシュボードで自社サイトの現在設定を確認する

まず、対象ドメインが今回のデフォルト変更の対象範囲に含まれるかどうかを確認する。Cloudflareダッシュボードにログインし、対象ゾーンの「AI Crawlers & Scrapers」(あるいは同等のAIボット管理画面)を開き、Search/Training/Agentそれぞれの現在の許可・ブロック状態を確認する。既に有料プランで明示的に設定済みだったサイトは今回の変更の対象外だが、無料プランで一度も設定を触っていなかった場合は、Training・Agentが新たに既定ブロックへ切り替わっている可能性が高い。

2. 「失敗したリクエスト」の内訳をステータスコード別に確認する

ダッシュボード上の集計値だけで判断せず、可能であればCloudflareのログ(Logpush等)やアナリティクス機能を使い、失敗したリクエストの内訳を404・403・429のステータスコード別に分解して確認する。403の割合が高ければ、実際にブロックの影響を受けている可能性が高く、404が大半であれば単なるリンク切れが原因である可能性が高い。この切り分けを行わずに「失敗が増えた=ブロックが増えた」と即断しないことが重要だ。

3. 個別のユーザーエージェントで直接リクエストし、ステータスコードを確認する

Remote Work Europe Newsが推奨する検証方法にならい、確認したいクローラーのユーザーエージェント文字列を指定して対象URLに直接アクセスし、返ってくるステータスコードを個別に確認する。たとえばcurlコマンドを使う場合、以下のようなイメージで検証できる。

# GPTBot(OpenAIの学習用クローラー)として動作を確認する例
curl -A "Mozilla/5.0 (compatible; GPTBot/1.1; +https://openai.com/gptbot)" \
  -o /dev/null -s -w "%{http_code}\n" https://example.com/target-page

# OAI-SearchBot(OpenAIの検索用クローラー)として確認する例
curl -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  -o /dev/null -s -w "%{http_code}\n" https://example.com/target-page

# ChatGPT-User(エージェント/ライブセッション用)として確認する例
curl -A "Mozilla/5.0 (compatible; ChatGPT-User/1.0; +https://openai.com/bot)" \
  -o /dev/null -s -w "%{http_code}\n" https://example.com/target-page

200が返れば通過、403が返ればブロックされていることが分かる。同じ企業のクローラーでも用途(Training/Search/Agent)によって挙動が異なるため、1社につき複数のユーザーエージェントで検証することが望ましい。GPTBot・OAI-SearchBot・ChatGPT-Userのほか、ClaudeBot(Anthropic)、PerplexityBot、Google-Extended、Applebotなど、自社にとって重要なAIサービスのクローラーを優先的に確認するとよい。

4. Googlebot・Bingbotの状態をあらためて確認する

8月時点で報じられた「混合目的クローラーの巻き添えブロック」問題を踏まえ、Trainingブロックを能動的に有効化している、あるいは今回新たにTrainingが既定ブロックになった対象サイトについては、Google Search Consoleの「URL検査ツール」を使って主要ページ・サイトマップの取得結果が403になっていないかをあらためて確認しておきたい。前回記事で紹介した、GooglebotのIPレンジを使ったallowlistルールの作成も、有効な恒久対策として引き続き検討する価値がある。

5. 自社の集客構造に応じてTraining/Agentの方針を能動的に決める

デフォルト設定のまま放置するのではなく、自社がAIリファラル経由の流入・従来型の検索流入・直接訪問のどれを重視しているかを踏まえ、Training(学習データとしての長期的な露出)とAgent(ライブエージェントからのリアルタイムアクセス)をそれぞれ許可するかどうかを能動的に判断する。AI検索での言及・引用を積極的に狙う戦略を取っている場合、Trainingを許可する選択肢も検討に値する。

6. Pay Per Use関連の発表を継続的にウォッチする

Ceramic.aiやYou.comの事例はまだ試験段階だが、Monetization Gatewayを軸にしたPay Per Useの実装が今後広がる可能性がある。広告収益に代わる、あるいは補完する収益源として、自社の業態にとってPay Per Useが現実的な選択肢になり得るかどうか、Cloudflareの公式発表や導入事例を定期的に確認しておきたい。

Cloudflareに関する質問

Q1. 2026年9月15日に何が実際に起きたのですか。

Cloudflareが7月1日に予告していたAIクローラーのデフォルト設定変更が本施行されました。広告ページではSearchが既定許可、Training・Agentが既定ブロックになります。

対象は新規顧客・既存顧客の新規サイト・設定変更をしていなかった既存の無料プランサイトです。既に有料プランで設定済みだったサイトは対象外で、これまでの設定がそのまま維持されます。

Q2. 今回の記事は過去のCloudflare関連記事と何が違うのですか。

過去3本は「発表(7月4日)」「分類の仕組みの解説(7月13日)」「期限前の警告(8月10日)」でしたが、今回は「期限が実際に到来し、施行後に何が起きたか」という続報です。

特に、ダッシュボードの「失敗したリクエスト」表示が誤解を招くという新しい論点、Pay Per Useの具体的な移行事例、9月15日のデフォルト変更の実際の対象範囲の再確認といった、施行後にしか分からない情報を中心に扱っています。

Q3. 自社サイトは今回のデフォルト変更の対象になりますか。

Cloudflareを利用しており、かつ新規顧客・新規サイト・9月15日まで一度もAI Bot設定を変更していない無料プランのいずれかに該当する場合に対象になります。

既に有料プランで明示的に設定を構成していたサイトは対象外です。まずCloudflareダッシュボードで自社の現在の設定を確認し、対象範囲に含まれるかどうかを判断することが最初のステップです。

Q4. Cloudflareダッシュボードの「失敗したリクエスト」は何が問題なのですか。

404(存在しないページ)・403(ブロック)・429(レート制限)を区別せず一括集計しているため、実態以上にAIクローラーが大量にブロックされているように見える可能性があります。

Remote Work Europe Newsが2026年9月11日付の記事で指摘した論点で、単に古いリンクへのアクセスが大部分を占めていても、集計上は「失敗」として一括りにされてしまいます。個々のクローラーのユーザーエージェントで直接リクエストし、ステータスコードを確認することが推奨されています。

Q5. GooglebotがブロックされるというCloudflareのニュースは、今回の話と同じですか。

厳密には別の論点です。Googlebot巻き添え問題は2026年8月時点で既に報じられていたもので、Trainingブロックを能動的に有効化していたサイトで起きていました。

Cloudflareの公式発表では、9月15日のデフォルト変更は「これまで一度もAI Bot設定を触ったことがないサイト」に新たに適用されるものであり、既存サイトで何も設定変更していなければGooglebotが新たにブロックされることはないとされています。ただし、今回新たにTrainingが既定ブロックになった新規サイトについては、引き続き巻き添えのリスクに注意が必要です。

Q6. Pay Per Useとは何ですか。Pay Per Crawlとどう違いますか。

Pay Per Crawlは取得(クロール)ごとに課金する仕組み、Pay Per Useは実際にAIが回答内でコンテンツを利用した場合に課金する仕組みです。

Pay Per Crawlは「クロールされたら課金」なので、引用されるかどうかにかかわらず対価が発生する一方、Pay Per Useは「実際に回答に使われたら課金」という、より成果に近い課金モデルです。Ceramic.aiやYou.comが試験的にこの方式を導入し始めているとみられます。

Q7. 自社のサイトがどのクローラーにブロックされているか、どうやって調べればよいですか。

Cloudflareダッシュボードの集計値だけでなく、確認したいクローラーのユーザーエージェントを指定して対象URLに直接アクセスし、返ってくるステータスコードを個別に確認する方法が推奨されます。

curlコマンドなどでユーザーエージェントを指定してリクエストを送り、200なら通過、403ならブロックと判断できます。GPTBot・OAI-SearchBot・ChatGPT-Userのように、同じ企業でも用途別に複数のクローラーが存在するため、1社につき複数のユーザーエージェントで検証することが望ましいです。

Q8. Training・Agentは許可すべきですか、ブロックすべきですか。

専門家の間でも見解が分かれており、一律の正解はありません。自社がAIリファラル経由の流入と従来型の検索流入のどちらを重視するかによって判断が変わります。

Trainingを許可すればAI生成回答内での長期的な露出を維持できる可能性がある一方、Agentをブロックするとブラウジングエージェントがサイトに全くたどり着けなくなります。どちらを優先するかは、自社の集客構造・ビジネスモデルに応じて個別に判断する必要があります。

Q9. 「混合目的クローラー」とは何ですか。

検索とAI学習など、複数の目的でクロールデータを使っているとCloudflareがみなすクローラーのことです。GooglebotやBingbotがこれに該当します。

混合目的クローラーは、Search/Training/Agentのどの粒度で設定していても、最も制限の強いルール(ブロック)が優先的に適用される仕組みになっています。このため、Trainingだけをブロックしたつもりでも、検索クローラー自体が巻き添えでブロックされるリスクが生じます。

Q10. 今後もこの一連の動きは続きますか。

続く可能性が高いとみられます。Pay Per Useへの移行、Monetization Gatewayの普及、ダッシュボード表示の改善など、関連する動きが今後も断続的に報じられると予想されます。

本メディアはこれまで7月4日・7月13日・8月10日・そして今回の9月22日と、この一連の動きを継続的に追ってきました。今後も新しい局面が生じ次第、続報を出す方針です。

関連記事

• LLMO(大規模言語モデル最適化)完全ガイド
• AI検索最適化ガイド
• Cloudflare、AIクローラー課金を「クロール単位」から「引用単位」へ転換
• Cloudflare、AIクローラーを「Search/Agent/Training」の3分類で個別制御可能に
• Cloudflareの「AIボットブロック」設定でGooglebotも巻き添えに——9月15日デフォルト変更前に確認を
• クローラーとは
• robots.txtとは
• GEO(Generative Engine Optimization)とは
• LLMOとは
• AIO(AI Overview最適化)とは

</content>