- すべての料金プランの顧客が自動化トラフィックを Search・Agent・Training に分けて許可またはブロックできるようになり、従来の一括的なAIボット遮断よりも細かなポリシー設定が可能に
- AIであるかどうかではなく、サイト上で行う 行動とコンテンツ用途 を分類基準とし、多目的クローラーには関連するルールをすべて適用し、目的別クローラーの分離を推奨
- 2026年9月15日 から、新規ドメインの広告表示ページでは Training と Agent がデフォルトでブロックされ、Search は許可される。Googlebot・Applebot・BingBot のような多目的クローラーには最も制限の厳しいルールが適用される
- Enterprise Bot Management 向けの BotBase で、既知のボットやエージェントの分類・検知IDを検索でき、
immediate・reference・full のコンテンツ使用レベルと robots.txt の use シグナルも導入
- Verified はもはや自動許可を意味せず、RFC 7239 の
Forwarded ヘッダーを活用した 推移的信頼 により、運営者とコンテンツ利用方法を仲介レイヤーの先まで伝達しようとしている
AIトラフィックを用途別に制御すべき理由
- 過去のWebクローリングは、サイトのコンテンツを収集する代わりに 検索流入 を返す関係だったが、AI学習はコンテンツを持ち去りながらサイト所有者に価値を返さないという問題があった
- Cloudflare は1年前にワンクリックの Block AI Bots オプションと Pay-Per-Crawl marketplace をリリース
- コンテンツ所有者は原本を保護し、対価を得たいと望んでいるが、すべての自動化を一括でブロックする方式だけではこうした要求を満たしにくい
- 小規模サイトは検索露出を得るためにAI学習まで許可するか、学習を防ぐ代わりに発見可能性を失うかの選択を迫られることがある
- 検索と学習に同じボットを使う既存検索事業者に有利な構造である
- 格差を縮めようとする新規事業者には、検知を回避しようとする誘因が生まれる
- Google検索のように結果ページで直接回答を提供するサービスが登場する中、ボットがAIかどうかよりも、何を行い、何を保存し、どう再配布するか がより重要な基準になっている
Search・Agent・Training の分類
- すべての顧客が管理できるAI中心のユースケースを3つに区分
- Search: コンテンツを事前収集またはインデックス化し、後で質問に応答する。サイト所有者は送客トラフィックやそれに相当する対価を期待できる
- Agent: 人の代わりにリアルタイムの作業を実行する。ChatGPT-User のようなチャット収集ボットや、Gemini・Claude が Chrome を操作するブラウザーエージェントが含まれる
- Training: コンテンツを取得してモデルを学習またはファインチューニングする。データがAIベースの構造に恒久的に吸収され、性能改善に使われる
- 1つのクローラーが複数の目的を持つことがあるため、該当するすべての分類 をあわせて追跡する
- 検索インデックス構築、エージェント作業、モデル学習をすべて行う事業者には、目的別にクローラーを3つへ分離し、訪問目的とアクセス権限を明確に示すよう推奨
- 広告検証、フィード収集、エージェント取引のような自動化行動も別分類とするが、Search・Agent・Training にはすべてのサイト所有者が直接管理できる機能を提供
すべての料金プランに提供される制御と新しいデフォルト値
- 既存の Block AI Bots プリセットは主にモデル学習用の単一目的ボットを遮断していたが、新設定では Search・Agent・Training ごとの制御 を Free プランまで提供
- 2026年9月15日 から Cloudflare に新規登録されるドメインの広告表示ページに、次のデフォルト値を適用
- Training と Agent はデフォルトでブロック
- Search はデフォルトで許可
- 広告は人がページを訪れて確認するよう設計された収益化シグナルであるため、人の注意を妨げうる Training と Agent をブロックする
- Search は訪問者をサイトへ導く行動に最も近いため、デフォルトで許可する
- Search と Training を同時に行う多目的クローラーには、最も制限の厳しいルール が優先される
- Training のブロックを選んだ顧客には Googlebot・Applebot・BingBot もブロックされる
- 新しい AIトラフィック管理オプション と既存の Block AI Bots サービスの両方に適用される
- 既存顧客は9月15日までに Security settings で変更の拒否を表示することで、Search も行う Training クローラーに対して既存設定を維持できる
BotBase が提供するボット可視性と行動分類
- Enterprise Bot Management に追加された BotBase は、Verified ボットとエージェントを含む既知の自動化トラフィックの検索可能なデータベース
- Cloudflare ダッシュボードで Verified ボット・エージェントの全一覧と新しい分類を確認できる
- 初期段階では 可視性 に注力し、2026年後半にはサイトの既知の自動化コンテンツを直接制御する管理センターへ拡張する計画
- BotBase は、ボットがサイト上で実行できる行動に応じて1つ以上のカテゴリを付与する
- Search: 検索結果表示のためのクローリング
- Agent: 人の指示に従ってページを訪問するエージェント
- Training: モデル学習またはファインチューニング用クローリング
- Transact: ユーザーに代わる決済処理
- Data Collection: 価格収集、競合情報収集、サードパーティ分析
- Security Testing: 脆弱性スキャンとペネトレーションテスト
- SEO: SEOクローリング、サイト監査、アクセシビリティ検査
- Ads Verification: 広告配置の検証と広告不正の検知
- Social / Link Preview: ソーシャルプラットフォームやメッセージングアプリのリンクプレビュー
- Feed Fetching: RSSリーダー、ポッドキャスト収集ツール、ニュースフィードボット
- Monitoring & Operations: 稼働監視、Webhook、ステータスチェック
コンテンツ使用レベルと robots.txt シグナル
- ボットが収集したコンテンツを保存・再利用する方法を コンテンツ使用（content use） レベルとして管理する機能を開発中
immediate: 対話のみ行い、保存や再利用をしないreference: インデックス化して一部を引用し、原文へリンクするデフォルト値full: 要約や再現が可能
- ボット分類とコンテンツ使用レベルを組み合わせることで、「Search・SEO・Ads Verification は許可するが
reference までに限定」といったポリシーを作成できる
- 個別ボットごとにルールを書かずに、行動グループ単位 でアクセス可否を決定できる
- Content Signals を拡張する
use シグナルを robots.txt で試験中
use=immediateuse=referenceuse=full
- robots.txt のコンテンツ使用値は直接ブロックを執行せず、サイト所有者の 希望 を伝える
- 既存の管理型 robots.txt で
search=yes,ai-train=no を使っていた顧客には use=reference が追加される
User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /
- BotBase は各ボットのコンテンツ使用方法も追跡し、シグナルを悪用したボットは Verified ステータスを失って許可されなくなる
- コンテンツを完全に再現するボットは現在 Verified ステータス を取得できない
Verified の変わった意味
- 過去にはすべての Verified ボットをデフォルトで許可しており、この基準は Bot Fight Mode と Enterprise Bot Management のルールテンプレートにも反映されていた
- 今後も未検証ボットは引き続きデフォルトでブロックされるが、Verified ボットも自動的には許可されない
- Verified は関連カテゴリで許可可能なボットであることを意味し、実際のアクセス可否は Search など該当カテゴリが許可されているかで決まる
- ボット運営者が Verified ステータスを得るには、次の2条件を満たす必要がある
- 自らの正体を誠実に表示すること
- その誠実性によって得たアクセス権を悪用しないこと
- Cloudflare の分類に運営者情報が正確に反映されているかを管理できる ボット運営者向けツール も開発中
仲介プラットフォームを通過する推移的信頼
- 自動化やエージェントは、それを作った企業が直接運用しているとは限らず、1つの開発プラットフォームが企業から個人開発者まで何千もの運営者のリクエストを代行実行することがある
- サイト所有者→ボット所有企業→最終ユーザーへと続く関係を 推移的信頼（transitive trust） と定義
- RFC 7239 の
Forwarded ヘッダーを使い、プロキシ過程で失われる運営者情報をリクエストに含める方式を提案
Forwarded: for="openai"
Forwarded: for="openai";use="reference"
- サイトが特定の運営者を許可すれば、信頼された複数の仲介レイヤーを経由して届くリクエストにも同じポリシーを維持でき、詳細な形式は Webボット認証ドキュメント で確認できる
- Cloudflare 配下のWebドメインが20%を超えるため、信頼状態の喪失は運営者にとって実効的な抑止手段になりうる
- ボットと人間のトラフィックが混在する場合、身元を明かす余地のあるユーザーにのみ推移的信頼が適用される可能性がある
適用状況と運用原則
- 新しいAIトラフィックオプションは現在すべての既存顧客に提供されており、zone Settings で設定できる
- 新しいデフォルト値と分類体系は、サイト所有者が 誰がコンテンツをどう使うか を決められ、自動化運営者が目的を透明に示すほど、より多くのアクセスを得られる構造を目指している
- Webと自動化トラフィックの変化に合わせて詳細ポリシーは継続的に調整するが、コンテンツ制作者の選択と信頼を中心に置く原則は維持する
1件のコメント
Hacker News のコメント
Googlebot は検索インデックスと Gemini の学習に同じクローラー基盤を使っているため、9月15日から Cloudflare の「学習ブロック」ポリシーに引っかかることになる
最も制限の厳しいルールが優先適用されるため、学習をブロックした顧客サイトでは Googlebot、Applebot、BingBot のような多目的クローラーもブロックされる
検索独占企業のこうした行為を止めることこそ反トラスト法の役割なので、せめて EU 規制当局に動いてほしいし、アクセスログ上のすべての Googlebot クロール記録が損害賠償の根拠になり得る
Google にコンテンツをこのように使わないでほしいと 正しく拒否する方法すら検索で見つけにくく、もどかしかった
新規ドメインでは広告が表示されるページの 学習およびエージェントのクロールをデフォルトでブロックしつつ検索は許可するという Cloudflare の姿勢は、軍拡競争の両側に足をかけているようで疲れる
一方でエージェントや AI 製品を作る技術を提供しながら、他方でこうしたポリシーを進める会社を気軽に使うのは難しい
Web ドメインの20%以上を基盤に「信頼ステータス」を付与したり剥奪したりできるという権力を、肯定的に打ち出している様子にも驚く
Cloudflare の機能ではなく、Anubis のような Proof of Work（PoW） の導入を検討してほしい
Cloudflare で保護されたサイトで、CAPTCHA すらなく完全にブロックされることが増えており、個別のサイトは重要でなくても、こうした選択がインターネットの根幹を侵食していく過程は暗い気持ちになる
完全にブロックされたなら、Cloudflare 自体というより、すべての VPN や特定国以外のユーザーをブロックするよう設定したサイト側の判断である可能性が高い
誰がサイトにアクセスできるかを、ますます支配的になっている一企業に自発的に任せるのは不安だ
「ボット」と「AI」を反射的にブロックすると、実際には ユーザーの代わりに作業する AI エージェントまでアクセスできなくなるため、ポリシーの前提も間違っている
Cloudflare と Web が最終的に何を望んでいるのか分からない。Anthropic、DeepMind、OpenAI、Google がクロール費用を支払うとは思えず、Reddit のような主要な議論の供給源と非公開契約を結ぶ可能性のほうが高い
新しい情報をコンテキストとして取り込む機能は続くだろうが、それは無差別なスクレイピングとは違う
Google が質問に直接答え、元サイトへ送るユーザーがほとんどいなくなる方向で成功すれば、Web にコンテンツを公開する経済的価値は広範に消える。そのままなら Google は技術的・法的にブロックされてコンテンツを得られず、全員が損をすることになる
誰もが無償で働き、Google と AI エンジンだけが価値を得る世界や、コンテンツ制作が完全に止まる世界は持続可能ではないが、最終的にほぼすべてのコンテンツが有料化される可能性は残る
ただし マイクロペイメントはこれまで徹底的に失敗しており、摩擦を十分に下げる方法がなければ、価値あるコンテンツの大半が閉じられ、発見とアクセスのコストが増え、コンテンツ産業全体が急激に縮小しかねない。大きな単位での支払いだけが残るなら、商業 Web ははるかに小さくなり品質は上がるかもしれないが、代償はかなり大きいだろう
先導することとは別に、こうした決定にはすべての利害関係者を考慮できるよう IETF が直接関与すべきで、そうでなければインターネットが断片化しかねない
既存の大企業はこれを負担しつつ、新規参入者に巨大な財務的障壁を築けるため、むしろ歓迎する可能性が高い
Cloudflare の顧客も、無料または安価なサービスを通じて分け前を得ている限り、同社が主要 AI 企業をどう扱うかを気にしない可能性が高い
Google、OpenAI、Grok、Claude、Perplexity だけを許可し、残りのボットをブロックする設定が可能なのか気になる
現時点で実際に訪問者を送ってくれているのは Google だけだが、他の主要 AI サービスも今後は送れるかもしれない
「匿名ボットのブロック」も代替案になり得る。AI ボットが増えた後、実在の人間を装う家庭用 IP からの膨大なリクエストで大きな被害を受けており、このトラフィックは収益を生まずコストだけを発生させる
Amazon CloudFront にこれを支援する機能があるのかも気になる
Cloudflare は、Web サイトが AI とどう関係を結ぶかを選べて、AI トラフィックを 収益化する方法まで提供する数少ないプラットフォームなのでありがたいと思う
クロールごとの課金プログラムについて何か新しい情報があるのか気になる
AI 学習をブロックしてみたところ、Google 検索ボットまで遮断されてトラフィックが半減したので勧めたくない
実際にこの機能を使っている人がいるのか気になる。スクレイパーが金を払うのかも疑問だし、払うとしても 採算が合うだけ支払うのか懐疑的だ