In Silico

AI・信頼性・評価

Cloudflareで検索は許可・AI学習は拒否、新設定の仕組みと限界

2026/9/26 （更新: 2026/10/13）

🤖 AIを使用して執筆

  • Cloudflare
  • クローラー
  • 生成AI
  • Disallow AI Training
  • Accountable
  • robots.txt
  • Google-Extended
  • Applebot-Extended
  • Content Signals Policy
  • RFC 9309
  • aipref
  • 混用クローラー
  • 学習拒否
  • 管理 robots.txt
  • Radar
  • Bot Preference Sync
  • 透明性
  • オプトアウト
  • AI 要約
  • ユーザーエージェント
  • Googlebot
  • Applebot
  • Bingbot
  • IETF
  • nosnippet
  • NOARCHIVE
目次
背景・問い・要点
背景

自分のサイトを検索の結果には出したまま、生成AIの学習には使わせたくないと考える運営者は多い。しかし一本のクローラーが検索の索引作りと学習用の文章集めの両方を運んでいるとき、そのクローラーを迎えるか拒むかという経路の側の選択では、二つの用途を区別できない。

クローラーを迎え入れれば、サイトの文章は学習の材料にもなる。拒めば、サイトは検索の結果からも消える。経路の側だけで見れば、運営者に見える選択肢は迎えるか拒むかの二つになる。どちらを選んでも、もう一方の目的を手放すことになる。

この不便は、クローラーが行儀よく振る舞うかどうかとは関係なく生じる。一本の経路が複数の用途を同時に運んでいる限り、経路を制御する側には、用途だけを選んで扱う手段が無い。運営者が求める使い分けは、経路の外からは実現できない。本稿は、Cloudflare が2026年9月15日に出した Disallow AI Training を例に取る。

問い

クローラーの制御は、経路を遮断する設計から、何を手がかりに検索と学習を分ける設計へ移りつつあるのか。

要点

Cloudflare が2026年9月15日に出した Disallow AI Training は、学習の拒否を検索と分けて扱うと約束した混用クローラーだけを検索用に残す。Disallow AI Training は、それ以外の学習クローラー（Amazon・Anthropic・Meta・OpenAI の学習専用クローラーを含む）を遮断する1。 用途ごとの意思を robots.txt で公開する仕組みは、2023年9月の Google-Extended から在る2。Cloudflare が運営者に代わってそれを公開する仕組みも、2025年7月の管理 robots.txt と同年9月の Content Signals Policy（robots.txt に search=yes, ai-train=no と書く）で先に始まっていた34。9月15日の変更は、Block を混用クローラーにも及ぼし、要件を満たすか満たすと約束したクローラー運営者を Accountable と指定して、その制御を Radar で公開して追うとした1。一本の経路が検索と学習の二つの用途を運ぶ混用クローラーに対して、外からの遮断は経路にしか効かない。用途を分けられるのは運ぶ側だけである。

モデル・例示

一本のクローラーが二つの用途を運ぶと、検索だけを残す組み合わせが経路の側から作れない

運営者の望みを、検索の結果に出すか（可・不可）と、学習に使わせるか（可・不可）の二つで書くと、組み合わせは四つある。検索は可・学習は不可が、多くの運営者が求める組み合わせである。

検索用と学習用を別々のクローラーが運ぶとき、運営者は経路ごとに迎えるか拒むかを選べる。二本の経路にそれぞれ二通りの選択があるので、四つの組み合わせはすべて経路の側から作れる。学習用の経路だけを拒めば、検索は可・学習は不可になる。

一本のクローラーが二つの用途を運ぶとき、経路の側の選択は迎えるか拒むかの二通りしかない。迎えれば検索も学習も可になり、拒めば検索も学習も不可になる。作れるのは四つのうち二つで、検索は可・学習は不可はそこに入らない。

この組み合わせを作る手がかりは、経路の側には無い。運ぶ側が用途ごとの意思を読み、取得した内容を用途で分けて扱う場合に限って、残りの組み合わせが作れる。

変更の中身：学習拒否の公開は以前からあり、変わったのは遮断の範囲と約束

Cloudflare は CDN とセキュリティの事業者で、Disallow AI Training を Bot Management と AI Crawl Control の設定として出す。robots.txt は1994年に始まった慣行で、IETF は2022年にこれを RFC 9309 として標準化した5。Google-Extended は Google の robots.txt 用トークンで、独立したユーザーエージェントを持たない。既存の Google のクローラーが取得した内容を Gemini の学習と grounding に使うかどうかを制御する6。Applebot-Extended は Apple の同種のトークンで、Applebot が取得した内容を Apple の基盤モデルの学習に使うかどうかを制御する7。

2025年7月1日、Cloudflare は管理 robots.txt を出した。サイトに代わって robots.txt を作成し学習拒否の記載を作る仕組みで、広告で収益化している部分だけ AI ボットを遮断する設定も置いた3。この時点で管理 robots.txt は、Google-Extended・Applebot-Extended などに向けて検索を保ったまま学習拒否を伝えていた。先頭には、IETF の AI preferences 提案が定義するとおりに、データ利用の意思を全ボットに示す一般ヘッダも付けていた3。遮断側の設定は Block on pages with Ads と Block Everywhere の二択だった3。同年9月には Content Signals Policy が管理 robots.txt に Content-Signal: search=yes, ai-train=no を配信し、検索は可・学習は不可という用途ごとの意思の公開が380万ドメインに広がった4。

2026年9月15日、Cloudflare はこの構成を作り直した。検索・学習・エージェントの三つの挙動別の制御は以前から在り、学習の側に Disallow AI Training を加えた。この名は公開する robots.txt の Disallow: 指示に由来する1。Block と広告ページのみの遮断は、Applebot や Bingbot、Googlebot のような混用クローラーにも及ぶようになった。以前は検索の発見可能性への影響を理由に対象外だった1。「Block AI Bots」と管理 robots.txt は、より細かい Search・Training・Agent の制御と Bot Preference Sync に道を譲り廃止予定に入った1。新たに Accountable という指定が加わり、広告収益で成り立つサイト向けに推奨の初期設定が用意された。既存の設定は Cloudflare が自動で移し、Training を Block にしていた運営者の設定は Disallow AI Training になる1。

混用クローラーという構造に対し、Cloudflareはネットワークの側で解くことを選んだ

Cloudflare は混用クローラーを「検索と AI 学習の両方に仕える一つのクローラー。片方を断れば、もう片方も断ることになる」と定義する1。この構造がある限り、経路を遮断する設計は用途を分けられない。

robots.txt にも限界がある。RFC 9309 は「これらの規則はアクセス認可の形式ではない」と規定し5、Cloudflare は robots.txt だけでは誰がクロールしているかを識別できず、理由も判定できず、無視するクローラーを止められないと書く1。

Cloudflare は解決をネットワークの側に置いた。方針は次の一文にある。「ネットワークなら解決できる。我々は意思を公開し、誰がクロールしているかを識別し、なぜクロールしているかを分類し、無視する者を遮断し、各クローラー運営者が実際に何をしたかを Radar で報告する」1。

ネットワークの側で解くという設計には反転がある。遮断はクローラーを取り除くだけで振る舞いを変えないと Cloudflare は書き、より良い結果は選択を迫らないクローラー運営者だとする1。Cloudflare はクローラー運営者と直接話し、ほとんどが、サイト運営者は内容の使われ方を制御でき透明性を持つべきだと同意したと書く。そのことをサイト運営者に分かるようにする指定として置いたのが Accountable である1。Accountable は、学習のオプトアウト機構、要約のオプトアウト機構、URL単位の可視化、学習拒否が従来の検索結果に影響しない保証の四つを、満たすか満たすと約束したクローラー運営者に与えられる1。

クローラー運営者の側の機構も、混用クローラー自体は一本のまま、用途だけをトークンで分ける。Google-Extended は「独立した HTTP ユーザーエージェント文字列を持たない。クロールは既存の Google のユーザーエージェント文字列で行われ、robots.txt のトークンは制御の役割で使われる」6。Applebot-Extended も同じ形を取る。Apple は「Applebot-Extended はウェブページをクロールしない」「Applebot-Extended は、Applebot ユーザーエージェントが取得したデータをどう使うかを決めるためだけに使われる」と書く。Applebot-Extended のサイト規則は検索の順位付けでは考慮されない、とも明記する7。

分離の需要の実在を、Cloudflare は数で示す。Cloudflare 上のサイトのうち検索ボットを遮断するものは1%未満にとどまる一方、学習を遮断する機構を有効にするものは17%に上り1、Cloudflare はこの差を一律の Block AI ではなく細かい制御が要る理由として書く1。強みは、検索を保ったまま学習だけを止めたいという需要に応える選択肢が増えたことにある。弱みは、この選択肢の実効性がクローラー運営者の約束に依存する点にある。

実効性はクローラー運営者の約束に依存し続ける

制御の重心は、経路を迎えるか拒むかの判断から、意思の公開とクローラー運営者の約束へ移る。代償として、分離の実効性はクローラー運営者の約束と透明性に依存する。Microsoft は robots.txt による学習拒否への対応を2027年初頭を目標に構築中で、それまで Disallow AI Training を選んでも Bing へ学習拒否の意思は robots.txt 経由で伝わらない1。それまでの Bing への学習拒否には、原典は NOARCHIVE タグに加えて Bing の Block URLs などのツールを案内する1。Apple の URL 単位の点検ツールも、Cloudflare の記述では来年の提供を予定する段階にある1。Google の Google-Extended に関する URL 単位の透明性ツールも、Cloudflare の記述では数週間以内の提供予定である1。

遮断が効くのは、Accountable な混用クローラー以外の学習クローラーに対してである。Accountable な混用クローラーに公開できるのは robots.txt の Disallow という意思の表明にとどまり、RFC 9309 が定めるとおりこれはアクセスを認可する仕組みではない5。この場面での検証手段は、遮断ではなく Radar による透明性である1。Amazon・Anthropic・Meta・OpenAI は検索用と学習用のクローラーを分けており、学習用を遮断しても検索には響かない。原典はこれらも Accountable に分類している1。

意思として表現しきれない範囲も残る。広告ページだけを学習から外したいという意思は、対象一覧が大きく頻繁に変わるため robots.txt に列挙できず1、エージェント向けにも確立した指示がまだ無いという理由で Disallow の設定は置かれていない1。

次の結合も残る。Google は robots.txt 指示を検索クロールの制御と位置づけ、検索内の表示を制限するには nosnippet などを、他システムでの学習と grounding を制限するには Google-Extended を使うと分ける8。Google の文書のこの区分に従えば、学習拒否は検索に組み込まれた AI 要約には触れない。Cloudflare 自身も、サイト全体で要約の可否を選ぶ仕組みを鈍い道具と書き、来年初頭までに含める分量を制御できるようにすることを目標に置く1。

この限界は、クローラーが混用である間続く。ネットワークの側が担えるのは、クローラー運営者に約束を公開させ結果を報告することまでで、用途そのものを分けることではない。

意思の標準化と、強制の分業

標準化が向かう先は意思の表現である。IETF の AI Preferences (aipref) ワーキンググループは、「AI モデルの開発・展開・利用のために内容がどう収集・処理されるかについての意思を表現する構成要素を標準化する」と憲章に書き、語彙と robots.txt や HTTP ヘッダへの付加方法を標準化の対象に置く9。同じ憲章は「意思の技術的な強制」「クライアントやクローラーの認証・認可」に加え、「AI 学習の監査その他の透明性措置」も範囲外と明記する9。意思の表現は標準化へ進み、強制は Cloudflare のようなネットワーク事業者とクローラー運営者が担うという分業である。ただし表現の側でも、Cloudflare は自社の Content Signals の語彙を先に配り、クローラーが取得後に残して再利用してよい範囲を表す欄も試している4。Cloudflare は、エージェント向けの Disallow を今は置かず、ai-prefs のような標準が成熟したら見直すと書く1。要約の分量制御についても、上の目標の実現には ai-prefs のような公開標準が重要な一部になると書く1。

出典9件

  1. Cloudflare Blog「Have it both ways: stay discoverable in search while disallowing AI training」2026年9月15日. https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/ — Disallow AI Training と Accountable 指定の発表。各社の対応予定も書く。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25

  2. Google「An update on web publisher controls」2023年9月28日. https://blog.google/technology/ai/an-update-on-web-publisher-controls/ — Google-Extended を robots.txt の新しい制御として告知した記事。 ↩

  3. Cloudflare Blog「Control content use for AI training with Cloudflare’s managed robots.txt and blocking for monetized content」2025年7月1日. https://blog.cloudflare.com/control-content-use-for-ai-training/ — 変更前の管理 robots.txt の発表。 ↩ ↩2 ↩3 ↩4

  4. Cloudflare Blog「Giving users choice with Cloudflare’s new Content Signals Policy」2025年9月24日. https://blog.cloudflare.com/content-signals-policy/ — 管理 robots.txt に search=yes, ai-train=no を加えると書く。380万超のドメインが対象。配信例 https://developers.cloudflare.com/bots/additional-configurations/managed-robots-txt/ ↩ ↩2 ↩3

  5. IETF「RFC 9309: Robots Exclusion Protocol」2022年9月. https://www.rfc-editor.org/rfc/rfc9309.txt — robots.txt を標準化し、その規則はアクセス認可の形式ではないと規定する。 ↩ ↩2 ↩3

  6. Google Search Central「Google’s common crawlers」（2026年9月18日取得）. https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers — Google-Extended は独立したユーザーエージェントを持たず、Gemini の学習と grounding への利用を制御し、検索の掲載と順位に影響しないと書く。 ↩ ↩2

  7. Apple Support「About Applebot」（2026年9月18日取得）. https://support.apple.com/en-us/119829 — Applebot-Extended はクロールせず Applebot の取得内容を学習に使うかだけを決め、検索の順位付けでは考慮されないと書く。 ↩ ↩2

  8. Google Search Central「AI features and your website」（2026年9月18日取得）. https://developers.google.com/search/docs/appearance/ai-features — 検索内の表示は nosnippet などで、他システムでの学習と grounding は Google-Extended で制限すると分ける。 ↩

  9. IETF「AI Preferences (aipref) Working Group charter」（2026年9月18日取得）. https://datatracker.ietf.org/wg/aipref/about/ — AI 向けの意思表現を標準化の対象とし、意思の技術的強制、認証・認可、登録簿、学習の監査と透明性措置を範囲外とする。 ↩ ↩2

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。