Cloudflare、AIクローラーを「Search/Agent/Training」の3分類で個別制御可能に

Cloudflare、AIクローラーを「Search/Agent/Training」の3分類で個別制御可能に――9月15日にデフォルトも変更

要点: Cloudflareは2026年7月1日、AIトラフィックを「Search（検索）」「Agent（エージェント）」「Training（学習）」の3つの振る舞いで分類し、それぞれ個別に許可/ブロックできる新機能を全プラン（Free〜Enterprise）で提供開始した。従来の「AIボットを一括ブロック」という単一トグルから、目的別のきめ細かい制御へと進化した。さらに2026年9月15日以降、新規にオンボードするドメインではデフォルト設定が変更され、広告収益化ページではTrainingとAgentが既定でブロック、Searchは許可のままとなる。既存顧客は期日前に設定を変更してオプトアウトできる。

最終更新日: 2026年07月13日

何が起きたのか

2026年7月1日、Cloudflareはブログ記事「Your site, your rules: new AI traffic options for all customers」を公開し、AIトラフィックの制御方法を大きく刷新すると発表した。翌7月2日にはHelp Net Securityなどのセキュリティ専門メディアが報道し、Web運営者・パブリッシャーの間で広く共有された。

「一括ブロック」から「3分類の個別制御」へ

これまでCloudflareが提供していたAIボット対策は、実質的に「Block AI bots（AIボットをブロックする）」という単一のトグルスイッチだった。オンにすればAI関連のクローラーを一律で遮断し、オフにすれば通す――という二者択一に近い仕組みで、「どのAIアクセスは歓迎し、どれは拒否するか」という細やかな判断ができなかった。

今回の新機能では、AIクローラーをその**振る舞い（behavior）**に着目して次の3つに分類し、それぞれを個別に許可/ブロックできるようになった。

• Search（検索）: コンテンツを収集・インデックスし、後からユーザーの質問に答えるために使うボット。従来の検索エンジンのクロールに近い性質を持ち、AI検索結果からの被リンク流入や、コンテンツ利用への対価を運営者が期待できる領域である。
• Agent（エージェント）: ユーザーの代理としてリアルタイムに行動する自動化トラフィック。チャットアシスタントがユーザーの求めに応じてページをfetch（取得）するケースや、ブラウザ操作を自動化するエージェントによるアクセスなどが該当する。
• Training（学習）: AIモデルの事前学習やファインチューニング（追加学習）を目的として、コンテンツを大量に取得するクローラー。取得されたコンテンツはモデルの内部知識に取り込まれるが、個別ページへの誘導や引用が直接発生するとは限らない。

この3分類により、たとえば「Search は許可して露出と流入を狙いつつ、Training はブロックして無断学習を防ぐ」「Agent は自社サービスの性質に応じて選別する」といった、目的に応じた意思決定が可能になった。

全プランで利用可能、ダッシュボードのSecurity設定から

注目すべきは、この機能がEnterpriseなどの上位プラン限定ではなく、Freeプランを含む全プランで利用可能である点だ。CloudflareのダッシュボードでゾーンのSecurity（セキュリティ）設定を開けば、3分類それぞれの許可/ブロックを個別に切り替えられる。世界のWebドメインの20%超がCloudflare経由でトラフィックを処理していると同社は説明しており、この変更が及ぼす影響範囲は非常に広い。

2026年9月15日からデフォルトが変わる

もう一つの重要ポイントが、デフォルト設定の変更である。2026年9月15日以降、新規にCloudflareへオンボード（初期設定）するドメインでは、既定の挙動が次のように変わる。

• 広告で収益化しているページでは、TrainingとAgentをデフォルトでブロックする。
• Searchは引き続き許可のまま。

つまり「何も設定しなければ、学習目的とエージェント目的のAIアクセスは自動的に遮断され、検索目的のアクセスだけが通る」という初期状態になる。これはCloudflareが、コンテンツ運営者の権利と収益を守る方向にデフォルトを寄せた、という明確な意思表示だ。既存顧客についても同じ方針が適用されるが、期日前に設定を変更すればオプトアウトできるため、「Trainingも許可したい」「Agentは通したい」というサイトは事前に自分で設定を上書きしておく必要がある。

Enterprise向けにBotBaseも提供

あわせてCloudflareは、Enterprise Bot Management向けにBotBaseを提供する。これは既知のボットを検索できるデータベースで、各ボットの分類や挙動を一元的に閲覧でき、検出に使う識別子（検出ID）を取得できる。大規模サイトの運用チームが「どのボットが何の目的で来ているのか」を把握し、ポリシー設計に活かすための土台となる仕組みだ。

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

この発表は、単なるインフラ設定の話にとどまらない。LLMO（大規模言語モデル最適化）やGEO（生成エンジン最適化）に取り組むマーケター・SEO担当者にとって、「AIにコンテンツをどう使わせるか」を目的別に設計するフェーズが本格的に到来したことを意味する。

「Search は許可、Training・Agent は選別」という基本設計

LLMOの観点から見れば、今回の3分類は意思決定の軸をきれいに整理してくれる。原則として次のように考えるとよい。

Search クローラーは、原則として許可すべきである。 LLMOやGEOの目的は、ChatGPT SearchやPerplexity、Google AI Overviewといった生成AI検索・回答面において、自社コンテンツが引用・参照され、そこから認知やトラフィックを獲得することにある。Searchボットを遮断してしまうと、そもそもAI検索のインデックスに載らず、引用候補にすらならない。これはSEOでGooglebotをブロックするのと同じで、LLMO戦略の根幹を自ら壊す行為になりかねない。露出・引用・流入を狙うなら、Searchは通すのが基本方針だ。

Training クローラーは、事業方針に応じて選別する。 学習目的のクロールは、モデルの内部知識にコンテンツを取り込む一方で、個別ページへの誘導や明示的な引用が保証されない。「自社の一次情報やノウハウを無断でモデルに吸収されたくない」「対価なく学習素材として使われたくない」という判断があるなら、Trainingをブロックする選択は合理的だ。逆に、ブランド名や独自概念をモデルの知識として広く定着させたい（いわゆる"モデルへの刷り込み"を狙う）戦略なら、あえてTrainingを許可する判断もありうる。ここは事業のスタンス次第であり、一律の正解はない。

Agent トラフィックは、サイトの性質で判断する。 ユーザーの代理でリアルタイムに動くエージェントは、今後の「エージェント経由の来訪・購買」を左右する。ECサイトや予約・比較系のサービスであれば、エージェントがユーザーに代わって商品情報を取得し、そのまま購入・予約につながる導線は将来の売上機会になりうる。むやみにブロックすると、そうしたエージェント経由のコンバージョン機会を逃す恐れがある。一方、有料会員コンテンツやAPI濫用のリスクが高いサイトでは、Agentを厳しく制御したい場面も出てくる。

「意図せぬブロック」を避けるための注意

最も注意すべきは、9月15日のデフォルト変更によって、意図せずAIアクセスを遮断してしまうケースだ。特に広告で収益化しているメディアが新規にCloudflareへオンボードした場合、デフォルトではTrainingとAgentがブロックされる。「Searchは許可のまま」なのでAI検索経由の引用そのものは残るが、エージェント経由の来訪を将来の資産と考えている場合、無自覚にその入口を閉じてしまう可能性がある。

既存顧客であっても、この機会に自社の設定を棚卸しし、「今どの分類が許可され、どれがブロックされているのか」を必ず確認しておきたい。設定を放置したまま「AI検索に載らなくなった」「エージェント経由の流入が消えた」と後から気づくのが、最悪のパターンだ。

今すぐできる対応策

ここでは、aiseo-llmo.comの読者が実際にとれる具体的なアクションを、優先順位順に整理する。

ステップ1: 現状の設定を確認する

まず、自社サイトがCloudflareを利用しているかを確認する。利用している場合、Cloudflareダッシュボードにログインし、対象ドメイン（ゾーン）を選択したうえで、以下を確認する。

1. ダッシュボードで対象ゾーンを開く
2. 左メニューの Security（セキュリティ） 設定に移動する
3. AIトラフィックに関する項目で、Search / Agent / Training の3分類それぞれの許可・ブロック状態を確認する
4. 現状が「意図した設定」になっているかを照合する

特に、過去に「Block AI bots」を一括でオンにしていたサイトは、今回の3分類移行に伴って挙動が変わっている可能性があるため、Searchまで巻き込んでブロックしていないかを重点的にチェックする。

ステップ2: LLMO方針に沿って分類を設定する

前章の基本設計に沿って、次のように設定するのが標準的な出発点となる。

• Search: 許可 ―― AI検索・回答面での引用と流入を確保する
• Training: 事業方針で判断 ―― 無断学習を避けたいならブロック、モデルへの定着を狙うなら許可
• Agent: サイト性質で判断 ―― EC・比較・予約系は許可寄り、会員制・濫用リスク高は制御寄り

ステップ3: robots.txt / llms.txt と併用して多層防御・多層宣言する

Cloudflare側の制御は「ネットワークレベルでの許可/ブロック」だが、これはrobots.txt や llms.txt による「宣言レベルの意思表示」と役割が異なる。両者は排他ではなく、併用することでAIクローラーへの意思表示がより明確になる。

robots.txtの記述例（Trainingを主目的とする代表的クローラーを拒否しつつ、検索系は許可する例）:

# 検索・回答用クローラーは許可（AI検索での引用を狙う）
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# 学習目的のクローラーは拒否（無断学習を避けたい場合）
User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

# サイトマップ
Sitemap: https://example.com/sitemap.xml

llms.txtの記述例（AIに「どのコンテンツをどう扱ってほしいか」を伝えるための宣言ファイル。ルート直下に配置）:

# Example Company

> 当サイトはLLMO/AI検索最適化に関する一次情報を提供するメディアです。

## 利用方針
- 検索・回答での引用は歓迎します（出典明記のうえ利用可）
- モデル学習目的での大量取得はご遠慮ください

## 主要コンテンツ
- [LLMO完全ガイド](https://example.com/articles/llmo-complete-guide): LLMOの基礎から実践まで
- [AI検索最適化ガイド](https://example.com/articles/ai-search-optimization-guide): AI検索での可視化手法

注意点として、robots.txtやllms.txtはあくまで「宣言」であり、ルールを守らないクローラーには強制力がない。 これに対しCloudflareのネットワークレベル制御は、実際のリクエストを遮断できる。したがって「宣言（robots.txt / llms.txt）で意思を明示しつつ、強制（Cloudflare）で実効性を担保する」という多層構成が、最も堅牢なアプローチになる。robots.txtの詳しい書き方は、当メディアの完全ガイドも参照してほしい。

ステップ4: 9月15日のデフォルト変更に備える

2026年9月15日以降、新規オンボードドメインではデフォルトが変わる。今後Cloudflareへ新しいドメインを追加する予定がある場合、オンボード直後に必ず設定を確認し、自社のLLMO方針と齟齬がないかをチェックする運用を、社内フローに組み込んでおくとよい。既存顧客も、期日前にオプトアウト（設定上書き）が必要かどうかを判断しておく。

ステップ5: 効果測定の仕組みを用意する

設定を変えたら、その影響を測れるようにしておくことが重要だ。GA4などでエージェント/AI経由のトラフィックをセグメント化して可視化しておけば、「Agentを許可した/ブロックした結果、来訪や成果がどう変わったか」を後から検証できる。設定変更は一度きりではなく、データを見ながら調整していくものと捉えたい。

背景と経緯――「コンテンツ独立」への流れ

今回の3分類制御は、突然出てきた施策ではない。Cloudflareがこの1年ほど推し進めてきた、AIとコンテンツ運営者の関係を再設計する一連の取り組みの延長線上にある。

同社は「AIクローラーがコンテンツを取得するだけ取得し、運営者には流入も対価も還元されない」という構造的な不均衡を問題視してきた。この文脈で登場したのが、AIクローラーのアクセスに課金する pay-per-crawl（クロール課金） の考え方であり、さらに直近では「クロールごと」ではなく「AIの回答に実際に使われたときだけ支払う」という Pay Per Use への転換も打ち出されている。今回の7月1日発表は、Cloudflareが「Content Independence Day（コンテンツ独立記念日）」と位置づけるタイミングで公開されており、同じブログ記事のなかで、この3分類制御と9月15日のデフォルト変更が示された。

大きな流れとして整理すると、次のような段階を踏んでいる。

1. 一括ブロックの提供 ―― まず「AIボットを止められる」手段を全ユーザーに配布した
2. 課金モデルの模索 ―― pay-per-crawl、そしてPay Per Useへと、取得に対価を求める仕組みを整備
3. 目的別の細分化 ―― 今回、Search/Agent/Trainingの3分類で「歓迎するアクセス」と「拒否するアクセス」を運営者が選べるようにした
4. デフォルトの転換 ―― 9月15日以降、初期状態そのものを「運営者保護寄り」に変える

この一連の流れは、Web全体で「コンテンツ運営者が、自分のコンテンツをAIにどう使わせるかを主体的にコントロールする」方向へ舵を切っていることを示している。前回のpay-per-use/既定ブロックに関する動きは、当メディアの速報記事でも詳しく取り上げている。

国内外の反応

海外では、Help Net Securityなどのセキュリティ・技術メディアが「Cloudflare changes AI crawler access rules（CloudflareがAIクローラーのアクセスルールを変更）」として速報し、Web運営者・パブリッシャーの権利保護の観点から注目を集めた。全世界のWebドメインの20%超がCloudflareを経由しているという事実は、この変更が「一社の機能追加」を超えて、AIクローラーとWebの関係のデファクト標準に影響しうることを意味する。デフォルトが変われば、それは事実上の業界基準として機能するからだ。

国内のマーケター・SEO担当者にとっての受け止め方は、立場によって分かれる。AI検索での露出を最優先するLLMO推進派は「Searchが許可のまま維持される」点を歓迎する一方で、コンテンツ資産の防衛を重視する事業者は「TrainingとAgentを既定でブロックしてくれる」方向性を前向きに評価している。いずれにせよ、「AIアクセスは一括で通す/止めるものではなく、目的別に設計するもの」という認識が広がるきっかけになりそうだ。

業種別の実務インパクト

3分類制御の意味合いは、業種によって大きく異なる。代表的な4業種で整理する。

メディア・パブリッシャー

最も直接的な影響を受ける。広告で収益化しているページは、9月15日以降のデフォルトでTrainingとAgentがブロックされる対象になりうる。記事コンテンツを無断学習から守りたいメディアにとっては追い風だが、同時に「Searchは許可のまま」なので、AI検索での引用による認知・流入は維持できる。「学習では守り、検索では露出する」という二正面戦略が、デフォルトとしてほぼそのまま実現される形だ。ただし、エージェント経由の来訪を将来の読者接点と考えるなら、Agentのブロックが機会損失にならないか検討が必要になる。

EC・通販

エージェント経由のショッピングが今後拡大すると見込むなら、Agentの扱いが売上を左右する。ユーザーの代理でエージェントが商品情報を取得し、比較し、購入までを代行する世界では、Agentをブロックすると「エージェント経由の購入導線」を自ら閉ざすことになる。一方で、商品データや価格情報が無断学習に使われることへの懸念があればTrainingは制御したい。EC事業者は「Agent許可・Search許可・Trainingは要検討」というバランスを取るケースが多くなりそうだ。

BtoB SaaS

ホワイトペーパーや技術ドキュメント、導入事例など、専門性の高いコンテンツを持つBtoB SaaSにとっては、「モデルに自社概念を定着させたいか」がTraining判断の分かれ目になる。製品名・独自機能・カテゴリ概念をLLMの知識に広く根付かせたいなら、あえてTrainingを許可して露出を取りにいく戦略もある。逆に、有償ドキュメントやログイン後コンテンツは厳格に守りたい。Searchは、AI検索で「◯◯の課題を解決するツールは?」と問われたときに指名される機会を作るため、原則許可が望ましい。

ローカルビジネス

店舗・クリニック・士業などのローカルビジネスは、Searchの許可が集客の生命線になる。ユーザーがAIアシスタントに「近くの◯◯」「◯◯の相談ができる事務所」と尋ねたとき、自社情報が引用・提示されることが来店・問い合わせにつながる。Searchを止める理由はほぼなく、むしろ営業時間・所在地・サービス内容といった基本情報を構造化して確実にインデックスさせるべきだ。TrainingやAgentの優先度は業種として相対的に低いが、予約をエージェントに任せる導線が広がれば、Agentの許可も検討対象になる。

今後の見通し

Cloudflareの一連の動きは、Web全体の潮流を先取りしている可能性が高い。今後、次のような展開が予想される（以下は一次情報にもとづく事実ではなく、あくまで実務上の見通しである）。

第一に、目的別制御の「粒度」はさらに細かくなる方向に進む可能性がある。 現状はSearch/Agent/Trainingの3分類だが、エージェント一つとっても「情報取得だけのエージェント」「決済まで行うエージェント」など性質が多様化していけば、より細かい分類や条件付き許可のニーズが高まるだろう。

第二に、対価の仕組みとの統合が進む。 pay-per-crawlやPay Per Useといった課金の枠組みと、3分類制御が組み合わされば、「Trainingは有償なら許可」「Searchは無償で許可」といった条件付きの運用が現実味を帯びる。運営者が自分のコンテンツの"値付け"を目的別に設定する時代が近づいている。

第三に、LLMO実務は「作って終わり」から「アクセス設計まで含めた運用」へと広がる。 これまでLLMOといえば「AIに引用されやすいコンテンツを作る」ことが中心だった。今後はそれに加えて、「どのAIアクセスを通し、どれを止めるか」というインフラ層の設計が、LLMO担当者の守備範囲に入ってくる。コンテンツ制作チームとインフラ・情シスチームの連携が、これまで以上に重要になる。

いずれにせよ、まず読者が今すべきことは明快だ。自社のCloudflare設定を確認し、Searchが確実に許可されているかをチェックし、TrainingとAgentを事業方針に沿って意図的に設定する。 そして9月15日のデフォルト変更を、"意図せぬ遮断"の事故ではなく、"アクセス設計を見直す好機"として活用することである。

よくある質問

Q1. Search・Agent・Trainingの3分類は、それぞれ何が違うのですか?

Searchは収集・インデックスして後で質問に答えるボット、Agentはユーザーの代理でリアルタイムに動く自動化、Trainingはモデル学習目的の取得です。振る舞い（目的）で分けています。

Cloudflareは「クローラーが何をしようとしているか」という振る舞いに着目して3分類しています。Searchは従来の検索エンジン的な使われ方で被リンク流入や対価が期待でき、Agentはチャットのfetchやブラウザ操作など即時的な行動、Trainingは事前学習・ファインチューニング用の大量取得です。この3つを個別に許可/ブロックできる点が今回の新機能の核心です。

Q2. この機能はどのプランで使えますか? 有料プラン限定ですか?

Freeプランを含む全プラン（Free〜Enterprise）で利用可能です。ダッシュボードのゾーンSecurity設定から誰でも個別制御できます。

上位プラン限定ではないため、無料でCloudflareを使っている個人サイトや中小メディアでも、今日から3分類の制御を設定できます。ただし、既知ボットを検索できるデータベース「BotBase」は、Enterprise Bot Management向けの提供です。まずは全プラン共通のSecurity設定から、Search/Agent/Trainingの状態を確認するのがよいでしょう。

Q3. 2026年9月15日から何が変わるのですか?

新規にCloudflareへオンボードするドメインで、デフォルト設定が変わります。広告収益化ページではTrainingとAgentが既定ブロック、Searchは許可のままです。

つまり「何も設定しなければ学習・エージェント目的は自動遮断、検索目的だけ通る」という初期状態になります。既存顧客にも方針は適用されますが、期日前に設定を変更すればオプトアウト（自分の意図した設定に上書き）できます。今後ドメインを新規追加する予定があるなら、オンボード直後の設定確認を運用フローに入れておくと安全です。

Q4. LLMOの観点では、どの分類を許可すべきですか?

原則としてSearchは許可すべきです。AI検索での引用・流入の入口だからです。TrainingとAgentは事業方針とサイトの性質に応じて選別します。

Searchを止めるのはSEOでGooglebotを止めるのに近く、AI検索の引用候補から外れてしまいます。露出を狙うなら通しましょう。Trainingは「無断学習を避けたいならブロック、モデルへの定着を狙うなら許可」、Agentは「EC・比較・予約系は許可寄り、会員制・濫用リスク高は制御寄り」が判断の目安です。

Q5. robots.txtやllms.txtがあれば、Cloudflareの設定は不要ですか?

いいえ、併用を推奨します。robots.txtやllms.txtは「宣言」で強制力がなく、ルールを守らないクローラーには効きません。Cloudflareはネットワークレベルで実際に遮断できます。

役割が異なるため、両方を組み合わせる多層構成が最も堅牢です。robots.txt/llms.txtで「どう扱ってほしいか」を明示的に宣言しつつ、Cloudflareで実効性を担保する、という考え方です。宣言だけ、あるいは遮断だけでは、意図の明示と実行力のどちらかが欠けてしまいます。

Q6. Trainingをブロックすると、AI検索に載らなくなりますか?

いいえ。TrainingとSearchは別分類です。Trainingをブロックしても、Searchを許可していればAI検索でのインデックス・引用は維持されます。

ここは誤解しやすいポイントです。「AI学習を拒否したらAI検索からも消えるのでは」と心配する必要はありません。学習目的のクロールを止めつつ、検索・回答目的のクロールは通す、という使い分けができるのが3分類制御の利点です。9月15日以降のデフォルトも「Trainingブロック・Search許可」であり、まさにこの考え方に沿っています。

Q7. Agentをブロックすると、どんな影響がありますか?

ユーザーの代理で動くエージェント経由の来訪や、将来的なエージェント経由のコンバージョン機会を逃す可能性があります。EC・予約・比較系サイトでは特に慎重に判断すべきです。

エージェントがユーザーに代わって商品情報を取得し、そのまま購入・予約につなげる導線が広がると、Agentをブロックすることはその入口を閉じることになります。一方、有料会員コンテンツやAPI濫用リスクが高いサイトでは、Agentを制御したい場面もあります。自社にとってエージェント経由の来訪が「機会」か「リスク」か、サイトの性質で見極めましょう。

Q8. 既存のCloudflare顧客は、今すぐ何をすればよいですか?

ダッシュボードのゾーンSecurity設定を開き、Search/Agent/Trainingの現在の許可・ブロック状態を確認し、自社のLLMO方針と合っているかを照合してください。

特に、過去に「Block AI bots」を一括オンにしていたサイトは、Searchまで巻き込んで遮断していないかを重点チェックします。そのうえで、9月15日のデフォルト変更を見据え、オプトアウト（設定上書き）が必要かを判断します。設定を放置したまま「引用されなくなった」「流入が消えた」と後から気づくのが最悪のパターンです。

Q9. BotBaseとは何ですか? 誰が使えますか?

BotBaseは既知ボットを検索できるデータベースで、分類・挙動の一元閲覧や検出ID取得ができます。Enterprise Bot Management向けの提供です。

大規模サイトの運用チームが「どのボットが何の目的で来ているか」を把握し、ポリシー設計に活かすための土台です。各ボットの分類や振る舞いを一箇所で確認でき、検出に使う識別子も取得できます。Enterprise以外のプランでは利用できませんが、まずは全プラン共通のSecurity設定でSearch/Agent/Trainingを制御することから始めれば十分です。

関連記事

• Cloudflare、AIクローラー課金を「クロール単位」から「引用単位」へ転換 ―― 今回の3分類制御と同じ「Content Independence Day」で発表されたPay Per Useと既定ブロックの詳報。
• エージェント経由トラフィックをGA4でセグメント化して可視化する ―― Agent許可/ブロックの効果を測るための計測設計。
• AIエージェントがSEO・LLMOに与える影響 ―― Agentトラフィックの本質と、これからの最適化の考え方。
• AI Overviewで引用されるための条件 ―― Searchを許可した先で、実際に引用されるための要件。
• robots.txt完全ガイド ―― 宣言レベルでのクローラー制御の基礎と記述例。
• LLMO完全ガイド ―― LLMOの全体像を体系的に学ぶ。
• AI検索最適化ガイド ―― AI検索での可視化を高める実践手法。
• AI引用25,337件の大規模調査——業界ごとに「引用フィンガープリント」が全く違うことが判明
• GEO対策「45件のレビューで判明」実は効果不明？批判的サーベイ論文を解説

用語の詳細は、LLMO、GEO、クローラー、robots.txt、llms.txt、ゼロクリック の各用語解説もあわせて参照してください。