Cloudflare 9/15 クローラ3分割が本開始：検索エンジン、AIエージェント、トレーニングクローラがついに分離管理

ここ数年、ウェブサイト所有者がAIクローラに対処できる道具は一つしかありませんでした：すべてのボットをブロックするか、すべてを通すか。この白黒付けのアプローチに、2026年7月に実質的な変化が起こりました。

Cloudflareは今年7月1日、すべての顧客（無料プラン含む）に対して3つの独立したAIトラフィックスイッチを提供しました：Search（検索エンジンクローラ）、Agent（リアルタイムAIエージェント）、Training（モデルトレーニングクローラ）。9月15日からはデフォルト値が反転し、広告を表示するページは自動的にTrainingとAgentタイプのボットをブロックします。

「一元的」から「段階管理」へ：なぜ重要なのか？

旧世界では、robots.txtだけが意志表明の手段でしたが、大半のAIクローラ是无視していました。Googleボットは検索インデックスとGeminiモデルトレーニングの両方で同時にコンテンツをスクレイピングし、AnthropicのClaudeBotは1回のリファラルクリックを生むまでに11,000ページ以上をクロールします（Cloudflare Radar 2026年中盤データ）。OpenAIの数値も857:1と厳しい状況です。

一方で、従来のGoogleボットは5ページクロールごとに1回のクリックをもたらします。メッセージは明確です：あなたはAIトレーニング企業のために大量のサーバーリソースを無料で運用していますが、代わりに実際の訪問者はほとんど得ていません。これらの無効トラフィックはあなたのCDN帯域幅と請求額度を直接消費しています。

Cloudflareの3分割はついにウェブサイト所有者に、「価値ある検索エンジン」と「与えることなく取るトレーニングクローラ」に対して個別の指令を出せるようになり、「全開く」か「全閉じる」かの二者択一から解放されました。

最大の論争：Googleボットもブロックされる

このポリシーで最も議論を呼ぶ部分は、Trainingボットのブロックではなく、Googleボットが「多目的クローラ」に分類されたことです。Googleは検索インデックスとGeminiモデルトレーニングの両方に同じクローラインフラを使用しています。そのため、Trainingトラフィックをブロックすると、広告ページ上のGoogleボットも一緒にブロックされます。

Hacker Newsでの議論はとても激しかったです。多くの開発者は、これこそがGoogleにすべきことだと言いました：「OpenAIですでにGPTBot、OAI-SearchBot、ChatGPT-Userを3つの個別IDに分割しているのに、Googleはまだ検索とトレーニングの両方に同じクローラを使用している—問題は明白です。」

Cloudflareはオプトアウトも提供しています—セキュリティ設定で「Training+Search」ハイブリッドクローラのホワイトリストを設定できます。但这个选择本身就反映了更深的產業矛盾：ウェブサイト所有者がGoogle検索トラフィックを維持するために、無料でトレーニングデータを继续供給せざるを得ない。

異なる規模のウェブサイト、完全に異なる戦略

「この3つのスイッチをどう設定すべきか？」という答えは、収益モデルとトラフィックソースによって異なります：

• Google検索トラフィックに依存する中小型サイト：Searchは全開、Trainingはブロック（ただしGoogleボットに例外を設定）、Agentは状況に応じて切り替え。
• 広告収入を主とするニュース/コンテンツサイト：TrainingとAgentの両方をブロックするのがCDN予算を守る最も直接的な方法です。あなたは検索可視性の数セントのためにトレーニング企業が広告ページをクロールする必要はありません。
• 技術文書/APIプロバイダ：Agentが最も価値のあるトラフィックタイプかもしれません（開発者がAIエージェントで文書を照会）。ただし、悪用を防ぐためにレート制限と組み合わせる必要があります。
• 広告やSEOに依存しない独立プラットフォーム：すべてをブロックするのが最もクリーンなアプローチです—ボットトラフィックは全く必要ないので、ブロックすることでインフラコストが節約できます。

robots.txtだけではもう十分ではありません

IETFは最近、robots.txtに「Content Signal」の拡張（search=yes,ai-train=no,use=reference）を推進していますが、この宣言的フォーマットは自主的に遵守する企業にしか有効ではありません。Cloudflareのダッシュボード設定こそがエッジ層で実際にファイアウォールルールを実行するものです。

実務的には、最も効果的な方法は両方を並行して実行することです：robots.txtはあなたの意図を表明し、準拠するクローラが自動的に遵守します。Cloudflareのパネルは底线防衛であり、すべての非準拠トラフィックをブロックします。これはWAF運用ロジックに直接対応しています—宣言型ポリシー＋強制実行情報。

運用チームへの実際の影響

どんな種類のサイトでも、Cloudflareの大改革は同じ結論を指しています：ボットトラフィック管理は「やるかどうか」の問題ではなく、「自分を害せずにどうやるか」の問題になった。

第一、誰が何をクロールしているかを知る必要があります。 ログ分析ツールがまだ人間とボットの区別しかできない場合、ClaudeBotが今日何ギガバイト消費したか、どのエージェントが合法的にアクセスしているか、どれが悪用しているかなど全く見えません。見えないものは管理できません—これはすべての自動防御の前提条件です。

第二、エッジでの高速意思決定が必要です。 クローラリクエストがバックエンドサーバーに到達してから判断しても遅すぎます—トラフィックコストは「このボットに価値があるかどうか」ではなく、リクエストごとと帯域幅で計算されます。あなたの防御はCDN/WAFエッジで分類・ブロックして、データがサーバーに到達する前に対応する必要があります。

第三、「設定したら終わり」は機能しません。 クローラの行動は変化します（Googleボットは明日に2つの個別UAに分割されるかもしれません）、新しいボットが登場し、あなたのサイトの目的も進化します。良いボット管理は定期的な見直しと調整が必要で、一度の設定ではありません。