AIクローラーを「AIかどうか」で分類する時代は終わりました
昨年Cloudflareが「Block AI Bots」のワンクリックオプションを提供した時点では、業界の関心は「学習用ボットか否か」に集中していました。しかし1年が経過し、状況は大きく変わりました。Google検索はAIによる並べ替えを超え、結果ページ上で直接回答を返すAnswer Engineへと進化しました。ChatGPTやGeminiといったエージェントがユーザーの代わりにブラウザを操作するケースも一般化しています。
問題は、これらすべてが「ボット」という単一のラベルで括られている点です。サイト運営者にとっては以下のジレンマがあります。
- 検索には露出したいが、学習まで一緒に許可するのは納得できない
- エージェントトラフィックはリアルタイムのユーザーリクエストなのに、学習クローラーと同様に遮断するとサービスが壊れる
- かといって全許可すると、コンテンツが一方的に持ち出される
Cloudflareがこのジレンマに対して提示したのが**実用的な分類体系(pragmatic taxonomy)です。核心は「このボットはAIか」ではなく、「このボットは自分のサイトで何をしているのか」**という問いにあります。詳細な背景は根拠資料で確認できます。
Search / Agent / Training — 3つの軸で管理する
Cloudflareが全顧客(無料プラン含む)に提供する3つの管理軸は以下の通りです。
1. Search(検索)
コンテンツを収集・インデックスし、後から質問に答えるためのDBを構築する行為です。重要なのは、このクローラーが将来的にreferral trafficを返すという期待がある点です。そのためデフォルトは**許可(Allow)**です。
2. Agent(エージェント)
人間の代わりにリアルタイムで処理を実行する自動化です。ChatGPT-Userのようなチャットfetchボット、GeminiやClaudeがChromeを操作するブラウザエージェントが該当します。多くの場合、反対側に人間が待っています。
3. Training(学習)
コンテンツを取得し、モデルの学習やファインチューニングに永続的に取り込むクローラーです。データがAIアーキテクチャに組み込まれ、取り戻せない点が核心です。
robots.txtへの新シグナル追加
# 既存のCloudflare管理robots.txt
User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /
# 新しいcontent-useシグナルを追加したバージョン
User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /
useフィールドは3段階に分かれます。
use=immediate— 相互作用はするが、保存・再利用は禁止use=reference(デフォルト) — インデックス・抜粋・リンクバックまで許可use=full— 要約および全体の再現を許可
これらの値をボット分類と組み合わせることで、「Search、SEO、Ads Verification用途のボットはすべて許可するが、referenceレベルまで」といった細かいルールを表現できます。ボット単位で個別管理する必要がなくなります。
2026年9月15日、デフォルト値が変更されます
最も重要な変更はデフォルト値の変更です。この日以降、Cloudflareに新規オンボーディングするドメインでは以下の通りになります。
| 区分 | 広告表示ページ | 非広告ページ |
|---|---|---|
| Search | 許可 | 許可 |
| Agent | 遮断 | 許可 |
| Training | 遮断 | 遮断(既存ポリシー維持) |
広告が貼られたページは「人間が見て初めて収益になる」ページであるため、人間の注意を奪うAgent・Trainingボットをデフォルトで遮断するという論理です。
マルチパーパスボットの落とし穴
ここで本当に注意すべき点があります。Googlebot、Applebot、BingBotなどはSearchとTrainingを同時に実行します。Cloudflareは「最も制限的なルールが適用される」という原則を採用しているため、Trainingを遮断した顧客はこれらのマルチパーパスボット全体が遮断されます。つまり、検索露出まで一緒に失う可能性があるということです。
検索は生かしつつ学習のみを遮断したい場合は、9月15日より前にSecurity設定で明示的にオプトアウトする必要があります。これを知らずにいると、検索トラフィックが突然途絶える事故が実際に起こり得ます。
BotBase — エンタープライズ向け可視化レイヤー
Enterprise Bot Management顧客にはBotBaseという新しいダッシュボードが提供されます。Cloudflareが追跡するすべてのボット(Verifiedボット+エージェント)を検索可能なDBとして表示し、各ボットがどの分類に属するか、detection IDは何かを即座に確認できます。ボット分類は以下の10種類です。
- Search — 検索結果表示用のスキャン
- Agent — 人間の代わりに訪問するエージェント
- Training — モデル学習・ファインチューニング用
- Transact — ユーザーの代わりに決済
- Data Collection — 価格スクレイピング、競合分析
- Security Testing — 脆弱性スキャン、ペネトレーションテスト
- SEO — サイト監査、アクセシビリティチェック
- Ads Verification — 広告配置検証、不正クリック検知
- Social / Link Preview — SNS・メッセージアプリのリンクプレビュー
- Feed Fetching — RSS、ポッドキャスト、ニュースフィード
- Monitoring & Operations — アップタイム監視、Webhook、ヘルスチェック
日本開発コミュニティにおける適用文脈
日本のWeb開発現場では、この変更は特に重要です。QiitaやZennなど技術コミュニティでも議論が活発ですが、実務的にはECサイトの価格スクレイピング対策とメディアサイトの広告収益保護が主要な関心事となります。特に自社でrobots.txtを手動管理している場合、Content-Signal: use=referenceの一行追加を忘れると、AIクローラーに対する保護が事実上機能しません。9月15日以降の新規デフォルト適用前に、必ず自社ドメインのSecurity設定を確認することを推奨します。
まとめ — 今すぐやるべき3つのこと
- Cloudflareダッシュボードで新しいAIトラフィックオプションを確認 — 無料プランでも利用可能です。Search/Agent/Trainingそれぞれの許可・遮断状態を今すぐ点検してください。
- robots.txtに
use=referenceを追加 — Cloudflare管理のrobots.txtを利用していれば自動反映されますが、手動管理の場合は自分で追記が必要です。 - 9月15日より前にマルチパーパスボットの方針を決定 — Googlebotを遮断するのか、検索は生かすのかを事前に決めないと、検索トラフィックが途絶えます。
この技術の限界と注意点
正直に言えば、このシステムはCloudflareネットワーク内のサイトにのみ適用されます。世界のWebドメインの約20%がCloudflare配下にあるため、残り80%は依然としてボット運営者の善意に依存せざるを得ません。また、Content-Signalはあくまで**「選好の表明」**であり、強制遮断ではありません。ボットがこれを無視すればVerifiedステータスを失うというペナルティはありますが、そもそもVerified申請をしていないボットには何の意味もありません。
次のステップ学習方向
- Content Signals仕様の原典を読み、自社のrobots.txtポリシーにどう組み込むか検討してください。
- エージェントトラフィックが増加する環境で、rate limitingと認証レイヤーをどう設計するかを学んでおくと良いでしょう。
- 併せて読みたい記事: Spotifyアプリリリースの裏側 — ダッシュボード設計と自動化の教訓では、大規模デプロイ自動化の観点から類似の教訓が得られます。またNVIDIA Cosmos 3 Edge ロボット制御向けオンデバイスワールドモデルチュートリアルは、エージェント系技術が実際どこまで進んでいるかを把握するのに役立ちます。