Cloudflare、「検索掲載は維持しAI学習は拒否」を可能に

サイト運営者にとって、AIクローラー対策は「拒否すれば検索流入まで失うかもしれない」という二者択一になりがちだった。Cloudflareが2026年9月15日に導入した Disallow AI Training は、この問題に対し、検索には載せ続けつつ、同じクローラーによるコンテンツのAI学習利用は拒否できるようにする設定だ。

併せて導入された Accountable（アカウンタブル） の指定は、こうしたサイト側の意思を尊重できる、または尊重する具体的な対応を表明したボット運営者を示す。Cloudflareによると、Apple、Google、Microsoftは、この設定をすでに尊重しているか、同社が定めた時期までに尊重すると約束している。5

最大の変更点は「ボット名」ではなく「利用目的」で分けること

Cloudflareの制御は、クローラーのアクセスを次の3つの目的として個別に管理する。

• Search（検索）：検索結果へページを登録するためのクロール
• Training（学習）：AIモデルの訓練やファインチューニングにコンテンツを使うためのクロール
• Agent（エージェント）：ユーザーが依頼した操作をAIが実行する際に、コンテンツを取得するためのアクセス 10

重要なのは、ひとつのクローラー基盤が複数の目的に使われ得る点だ。従来、AI用途のあるクローラーを一括で止めれば、通常の検索インデックスまで損なわれる可能性があった。Disallow AI Trainingでは、検索は許可し、学習利用だけを拒否する、より狭い範囲の指定を目指している。5

「Accountable」とは何か

Accountableは、検索インデックスと学習利用を分離し、サイト運営者の指定を尊重できるボット運営者に対するCloudflareの区分だ。Apple、Google、Microsoftは、この設定を尊重済み、または所定の期間内に尊重することを約束した事業者として挙げられている。5

出版社やメディア運営者にとっての意味は大きい。運営会社がAI学習も手がけているという理由だけで、検索に役立つクローラーまで全面ブロックする必要を減らす狙いがある。要件を満たす混合用途の運営者であれば、サイトが学習を拒否した後も、検索目的でページをインデックスできる。5

ただし、公開されている発表だけでは、各社の実装日、個々のクローラーの挙動、技術上の約束の全容までは確認できない。設定が各事業者で完全に同じ結果をもたらすと考えず、自社のボット設定とクロール状況を確認する必要がある。

残せるアクセスと、止められるアクセス

この設定は、Accountableに該当する混合用途の運営者について、検索インデックスを維持しながら学習利用を拒否するためのものだ。Cloudflareは、同じクローラーによる検索インデックスを許可したまま、AI学習を拒否できる機能として明示している。5

提供資料から読み取れる実務上のポイントは、次の通りである。

• 条件を満たすAccountable運営者は、学習を禁止しても検索アクセスを維持できる。5
• TrainingとAgentは、Searchとは別々にブロックできる。10
• 「すべてのAIボットをブロック」は、検討時間を確保したい場合や一律で制限したい場合の広い選択肢として残る。ただし、目的別の制御より粗い。7

とりわけ自然検索からの集客に依存するサイトにとって、この更新は、学習拒否と検索露出のどちらかを選ばなければならない状況を緩和するものとなる。

広告表示ページと9月の既定値

Cloudflareは以前、新たにCloudflareへ導入されるドメインについて、2026年9月15日から、広告を表示するページでは Training と Agent のクローラーを既定でブロックすると発表していた。10

この方針の背景には、広告で収益化されるコンテンツは、AI用途に対してより慎重な既定値を設けるべきだという考え方がある。一方、クローラーが複数目的を持つ場合、目的カテゴリ単位の厳しいブロックが検索クロールにも影響し得るという問題があった。Disallow AI TrainingとAccountableは、この衝突を解くための仕組みであり、広告付きコンテンツを学習から守りつつ、対応可能な運営者には検索インデックスを認める設計だ。5

既存ドメインがどのように移行されたか、すべてのアカウント種別にどの既定値が適用されたかは、提供資料だけでは網羅的に確認できない。既存ドメインの所有者は、新規ドメイン向けの既定値から自社設定を推測せず、実際のポリシーを確認したほうがよい。

Google-Extendedなどの個別指定との関係

目的別の制御は、「検索とAI利用を分けたい」という出版社側の要望に応えるものだ。これまでにも、事業者別の指示で同じ課題を解こうとする仕組みはあった。

CloudflareはGoogle独自のオプトアウト手段として Google-Extended や nosnippet に触れつつ、出版社からは、望まない利用をすべて防げてはいないとの声が寄せられたとしている。22 今回の資料だけでは、Google-Extended、Applebot-Extended、Bingの NOARCHIVE 指示について、現在の正確な適用範囲や動作を独立して確認することはできない。

ただし、全体像は明確だ。専用のオプトアウト、またはAccountableとしての対応により、「検索には登録してよいが、学習には使わないでほしい」という指示を成立させられる。単純にクローラーを遮断する方法では、この区別を安定して実現しにくい。

なぜ細かな制御が必要なのか

Cloudflareの分析では、過去12か月のAIクローリングのうち 80％ は学習目的で、検索目的は 18％、ユーザー操作目的は 2％ だった。同社は、分類には運営者の開示情報と業界資料を用いたとしている。16

この比率は、AIを一律に許可・拒否するだけでは不十分な理由を示す。サイト運営者は、検索インデックスは受け入れる一方、コンテンツがモデルに恒久的に取り込まれる学習利用は拒否し、リアルタイムのエージェントアクセスについては別に判断したいかもしれない。

Cloudflareは2025年、管理型のrobots.txt機能またはAIクローラー遮断ルールにより、AI学習を完全に拒否することを選んだウェブサイトが 250万超 に達したと報告している。13 今回の設定は、検索での発見性も重視するこうしたサイトに、より細かな選択肢を与える。

次の焦点はAI生成要約の制御

Cloudflareは、2027年初頭にAI生成要約について、出版社向けのより詳細な制御を提供する方針を示している。2 ただし、最終的な製品設計、強制方法、具体的な選択肢は現時点の発表からは分からない。

現段階での実務的な結論はシンプルだ。Search、Training、Agentを別々の判断として見直すことである。自然検索が重要なら、AI利用の制限が必ず検索制限も意味するとは考えないほうがよい。特にクローラー運営者がAccountableに指定されている場合は、その区別が今回の仕組みの要点となる。5