CloudflareのDisallow AI Training、検索での可視性とモデル学習を分離

Cloudflareは、同一クローラーによるモデル学習を拒否しつつ、検索インデックスへの登録を維持するための新しいコントロール「Disallow AI Training」を開始した。これまで、複数用途のボットに対してパブリッシャーが選べる手段は大まかなものだった。両方の用途を受け入れるか、クローラーを完全にブロックするかである。

この変更は、Cloudflareが複数用途クローラーと分類するApplebot、Googlebot、Bingbotを対象とする。各クローラーは検索とAI関連の用途を支援しうるためだ。Cloudflareは現在、運営事業者がコントロール、レポーティング、そして学習オプトアウトによって従来の検索可視性が低下しないという保証を提供する場合、これらのボットを「Accountable」と呼んでいる。

この分類は、Cloudflare、Apple、Google、Microsoftの間で共通の運用モデルを確立する。しかし、拘束力のある技術標準を生み出すものではない。新システムは、ダッシュボード上のコントロール、robots.txtの指示、各社のコミットメント、そして他の学習クローラーに対するCloudflareの執行を組み合わせている。

ここに重要なトレードオフがある。パブリッシャーは検索結果から姿を消すことなく同意の意思をより簡単に示せるようになる一方、保護の多くは依然としてクローラー運営者がその選択を尊重することに依存している。

CloudflareのDisallow AI Trainingがデフォルトの選択肢を変える

Cloudflareは、一つに過積載だったブロック判断を、検索、学習、ユーザー主導エージェント向けの個別の選択肢へと分けている。

CloudflareのAIクローラー制御は、AI関連のリクエストをすべて同一視するのではなく、挙動によって自動化アクティビティを分類する。検索クローラーはインデックスを構築し、学習クローラーはモデル開発用の素材を収集し、エージェントはユーザーに代わってページを取得する。

これらの分類が重要なのは、経済的な影響が異なるためだ。検索エンジンは通常、ユーザーを元のウェブサイトへ送る可能性があるリンクを表示する。学習プロセスは、即時の訪問を生むことなく情報を取り込める。エージェントはページを取得してその内容を提供するため、ユーザーがページを開かない場合もある。

クローラーは複数の分類にまたがることがある。Googlebot、Applebot、Bingbotは、検索機能を持つためパブリッシャーにとってブロックしにくい重要な例だ。これらへのアクセスを取り除くと、最終的にはインデックス登録、更新性、発見可能性に影響するおそれがある。

Cloudflareの従来のコントロールは、一部の学習ブロックから複数用途クローラーを除外することでこの問題に対応していた。これにより検索での可視性は保護されたが、パブリッシャーには同じ設定を通じて学習部分を直接拒否する手段が残されなかった。

新しいcrawler control modelは、中間的な選択肢としてDisallow AI Trainingを導入する。robots.txtを通じて学習拒否の意向を公開し、Accountableな複数用途クローラーには検索用アクセスを維持しつつ、学習に関連する他のクローラーをブロックする。

Cloudflareによると、Amazon、Anthropic、Meta、OpenAIが運用する学習専用クローラーは、それぞれ別の検索クローラーに影響を与えずにブロックできる。これらの企業は用途ごとに異なるボットを利用しているため、ネットワークレベルでの執行はより直接的になる。

Cloudflareは、より強い設定の意味も変更している。「Block」と「Block on pages with ads」は現在、Googlebot、Applebot、Bingbotを含む複数用途クローラーにも適用される。したがって、いずれかのオプションを選択すると、学習だけでなく検索にも影響しうる。

この違いにより、設定の影響はより大きくなる。Disallow AI Trainingは、検索アクセスを維持しながら限定的な意向を伝える。Blockは、特定のリクエストが検索を支援するものか学習を支援するものかにかかわらず、クローラーそのものを拒否する。

既存の設定は、新しいコントロールへ移行されている。以前に一般的なAIブロックのオプションを使用していたドメインは、通常、検索アクセスを維持したまま学習設定をDisallow AI Trainingへ移行する。既存の詳細なポリシーを持つドメインでも、実質的な選択内容が引き継がれる。

広告付きの新規ドメインについて、Cloudflareは検索を許可し、学習を拒否し、広告が表示されるページではエージェントをブロックすることを推奨している。広告のない新規ドメインには、3つの分類すべてを許可する、より制限の少ない推奨設定が適用される。

これらのプリセットは恒久的なルールではなく、推奨にすぎない。サイト所有者はオンボーディング中または後からSecurity Settingsで変更できる。コントロールはCloudflareのすべてのプランで利用可能で、ドメインレベルで機能する。

その結果、判断の分岐はより明確になる。パブリッシャーは通常のインデックス登録を許可し、学習を拒否し、エージェントには別のポリシーを選択できる。この構造は、自動化システムが現在ウェブサイトとどのように関わるかをより適切に反映している。

また、誤った設定も診断しやすくなる。パブリッシャーがBlockを選択した後にクローラーのアクセスを失った場合、その結果は選択した設定から直接生じたものだ。Disallow AI Trainingは、検索を維持しつつモデル開発での利用を拒否するという、より限定的な目的のために設計されている。

これは単にボットの切り替え設定を改称したものではない。制御の単位を、クローラーの識別情報だけから、識別情報、開示された目的、運営者の挙動の組み合わせへと変えるものだ。

複数用途クローラーがパブリッシャーに圧力をかける理由

価値ある検索トラフィックをもたらすクローラーが、まったく異なる商業目的のために素材を収集することもあるため、この対立が生じる。

オープンウェブにおける従来の交換関係は、比較的理解しやすいものだった。パブリッシャーは検索エンジンによるページのクロールを許可し、検索エンジンはリンク、抜粋、潜在的な訪問者を返した。広告、サブスクリプション、販売、読者との関係は、その一部のユーザーがサイトに到達することに依存していた。

生成AIはこの交換関係を複雑にする。モデルは学習中に収集した素材を利用できる一方、AIによる回答は、読者が引用元を訪問する前にクエリを満たしてしまう可能性がある。そのため、検索、モデル開発、回答生成は、それぞれ異なる形の価値を生み出す。

Cloudflare自身の測定結果は、パブリッシャーが懸念する理由を示している。同社は、12か月間に分類されたAIクロールの80％が学習目的だったと報告した。その後の6か月間の分析では、学習の割合は82％へ上昇し、検索は15％、ユーザーアクションは3％だった。

これらの数値は、ウェブ全体ではなく、Cloudflareが観測・分類したトラフィックを示している。それでも、コンテンツ提供者に到達する自動化された需要の大半を学習アクティビティが占めうることを示している。

パブリッシャーが学習専用クローラーをブロックする場合、計算は管理しやすい。大規模な検索インデクサーを排除せずに、不要な収集を止められる。GPTBotやOAI-SearchBotのような別個のボットがあれば、用途をより容易に分離できる。

複数用途クローラーは、より難しい問題を生む。同じクローラーが検索と学習を支援する場合、インフラレベルのブロックでは、コンテンツが運営者に届いた後に何が起きるかを判断できない。アクセスをブロックすれば素材は保護されるが、検索機能も失われる。

アクセスを許可すれば発見可能性は維持されるが、その一方で下流での利用を制限する別の仕組みが必要になる。CloudflareのDisallow AI Training設定は、その隔たりを埋めようとするものだ。

Cloudflareは、robots.txtに記載する提案語彙であるContent Signalsにより、この隔たりへの対応を始めた。content signal policyは、search、ai-input、ai-trainという3つの宣言された用途を区別する。

searchシグナルは、インデックス登録と従来型の検索結果を対象とする。AI生成の要約は含まれない。ai-inputシグナルは、取得やグラウンディングを含む、AIシステムによるリアルタイム利用に関するものだ。ai-trainシグナルは、モデルの学習とファインチューニングを対象とする。

したがって、サイトはsearch=yesとai-train=noを公開できる。所有者が生成AIによる回答でコンテンツをどう使うべきか決めていない場合、ai-inputを指定しないままにすることもできる。

この分離は重要だ。意向が記載されていないことを、許可または拒否と解釈すべきではない。Cloudflareのポリシーでは、パブリッシャーの意図を推測するのではなく、省略されたシグナルを中立として扱う。

ただし、Content Signalsは意向の表明である。スクレイパーによるページのダウンロードを物理的に防ぐ障壁ではない。Cloudflareは以前、技術的な執行が必要な場合、こうしたシグナルをボットコントロールまたはファイアウォールルールと組み合わせるようパブリッシャーに助言している。

新しいAccountable分類は、これらの層を橋渡ししようとするものだ。Cloudflareが、具体的なコントロールと透明性を提供している、または提供を約束しているとするクローラー運営者を識別する。要件には、学習のオプトアウト、AI要約のオプトアウト、URLレベルの可視性、従来型検索ランキングの保護が含まれる。

Apple、Google、Microsoftは、現在の機能と期限付きコミットメントをそれぞれ異なる形で組み合わせ、この基準を満たしている。この分類は、各社の実装が同一であることを意味しない。Cloudflareが、それぞれの運営者が同じ基本的な責任を受け入れたと考えていることを意味する。

これにより、他のクローラー運営者にも圧力がかかる。広範なアクセスを求める企業は、同意、検査、検索中立性に関する公開済みの基準と比較されるようになった。ボットの識別情報を分離することは依然としてその基準を満たす一つの方法だが、唯一の手段ではなくなった。

パブリッシャーにも新たな運用上の責任が生じる。検索での可視性、AI学習、回答生成、エージェントのアクセスには、現在ではそれぞれ別のポリシーが必要だ。一つの「AIをブロックする」という判断では、もはやビジネス上のトレードオフを捉えきれない。

ページビューで運営されるニュースサイトは、広告ページで学習とエージェントアクセスの両方を拒否するかもしれない。小売業者は、量が少なくても質の高いAI経由の紹介を重視する可能性がある。ドキュメントサイトは、リアルタイムのAI取得を歓迎しながら、長期的なモデル学習を拒否するかもしれない。

問われるべきなのは、AIボットが良いか悪いかではない。どの利用がアクセスを正当化するのか、どのような価値がパブリッシャーに還元されるのか、そしてその利用を検証できるのかである。

Apple、Google、Microsoftはモデルを共有するが、実装は一つではない

3社は同じ原則を支持しているが、コントロールには依然として技術的なばらつきがあり、導入時期も異なる。

Appleはすでに、Applebot-Extendedを通じてパブリッシャーが学習に対応できるようにしている。サイト所有者は、Applebotの通常の検索機能を許可したまま、robots.txtでそのユーザーエージェントを拒否できる。

Appleのドキュメントによると、Applebot-Extendedの設定は、サイトが検索結果に表示される方法に影響しない。また、nosnippetやペイウォール素材向けのラベルなど、生成出力に関するページレベルの仕組みもサポートしている。

これらのツールは、CloudflareのAccountableフレームワークのすべての要素をまだ提供しているわけではない。Cloudflareによると、Appleにはこの目的のためのURLレベルの検査機能がない。Appleは、来年の提供が見込まれる開発中のソリューションについて詳細を共有したと報じられている。

現在のApplebot controlsは、検索と学習を機能的に分離している一方、アクセス後に何が起きたかについての可視性は不完全だ。Cloudflareは、その隔たりを埋めるというコミットメントを受け入れている。

Googleも同様の拡張モデルを使っている。パブリッシャーは、GooglebotをブロックせずにGoogle-Extendedをブロックできる。Google-Extendedは、常に独自のリクエストを送る別個のクローラーではなく、特定の生成AI用途を制御するためのトークンだ。

この違いは重要だ。Googlebotは検索のためにコンテンツを取得し続ける可能性がある一方、GoogleはGoogle-Extendedの設定を用いて、その素材を対象となるAIシステムで利用できるかどうかを判断する。パブリッシャーは、別個のネットワーク識別情報ではなく、ポリシーを通じて下流での利用を制御する。

Googleによると、Google-Extended を通じたオプトアウトは、Google 検索への掲載やランキングに影響しない。同社のトレーニングのオプトアウトに関するガイダンスでは、Googlebot と Google-Extended の関係が説明されている。

Google はまた、生成型検索体験に関連する検索パフォーマンスのレポートと管理機能も提供している。Cloudflare によると、Google は Google-Extended に関連する追加の URL レベルの透明性機能に取り組んでおり、数週間以内の公開が見込まれている。

この特定の仕組みにおいて、3社の中で最も対応が不十分なのは Microsoft だ。Bing は細かなウェブマスター向け管理機能をサポートしており、パブリッシャーは NOARCHIVE メタタグを使用して、キャッシュまたは表示されたコンテンツの特定の利用を制限できる。

Microsoft は、NOARCHIVE が検索ランキングからページを除外するものではないとしている。サイト所有者は Bing Webmaster Tools を利用して、コンテンツの削除や URL 管理も行える。

ただし、Bingbot はまだ robots.txt を通じた Cloudflare のドメインレベルのトレーニング拒否設定を自動的には尊重していない。Cloudflare によると、Microsoft は 2027 年初頭に向けてその機能を開発中だという。

それまでは、Disallow AI Training を選択しても、新しいワークフローを通じて Bing に意図した制限が自動的に伝達されるわけではない。直ちに Bing での制限を求めるパブリッシャーは、引き続き Microsoft の既存ツールとページレベルのメタデータを使用する必要がある。

Microsoft は、そのAI 制御オプションを、検索での発見性を維持しながら、生成型体験におけるコンテンツの表示方法を制限する手段として説明している。しかし、Cloudflare の統合スイッチは現在、それらの制御機能と完全には接続されていない。

この実装上の隔たりが、今回のローンチにおける最も重要な注意点である。Cloudflare は Applebot、Googlebot、Bingbot を単一の Accountable ラベルの下に位置付けているが、トレーニング設定のための特定の拡張ユーザーエージェント経路を現時点で公開しているのは Apple と Google だけだ。

Microsoft の参加は、部分的には過去のコミットメントに基づいている。協調的な標準を確立するうえでは妥当かもしれないが、パブリッシャーは利用可能な執行機能と将来の互換性に関する約束の違いを理解すべきだ。

この共通モデルは、各事業者による「トレーニング」の解釈にも依存する。新規モデルの事前学習、既存システムのファインチューニング、ライブ回答へのグラウンディング、検索要約の生成は、それぞれ別の活動である。「トレーニング禁止」の選択が、AI を介したすべての利用を拒否するとは限らない。

Cloudflare は、AI への入力と AI 要約を明確に別の問題として扱っている。これにより、1つの設定が無関係な利用まで暗黙に対象とすることを防げるが、新しい制御機能がシンプルなダッシュボード上のラベルから想起されるよりも限定的であることも意味する。

パブリッシャーは、AI 生成の検索要約の対象であり続けながら、モデルのトレーニングを拒否できる。別のパブリッシャーは、トレーニングを許可しつつ、事業者固有の要約制御を利用できる。こうした選択は、トラフィックや帰属に異なる結果をもたらし得る。

したがって、Accountable フレームワークは最低限の契約として理解するのが最適だ。これは事業者に対し、目的を分離し、設定を尊重し、検証手段を提供し、従来の検索においてトレーニング拒否を不利益に扱わないことを求める。

これは Apple、Google、Microsoft を技術的に互換な存在にするものではない。また、それらの企業が提供するすべての AI 機能が同じオプトアウトの対象になることも保証しない。

当面の価値は統合にある。Cloudflare の顧客は共通の設定を表明する場所を1つ得られ、各事業者はその設定を既存または今後導入される管理機能に対応付ける。

長期的な価値は、その対応付けが、パブリッシャーが URL レベルで監査できるほど透明になるかどうかにかかっている。

この設定は同意シグナルであり、コンプライアンスの証明ではない

Cloudflare は指示を簡素化したが、サイトがその指示を公開しただけで、すべての下流利用が停止したことを証明できるわけではない。

この制約は robots.txt から始まる。このファイルはアクセス制御システムではなく、自主的なクローラー向けプロトコルとして設計された。準拠するクローラーはこれを読み、挙動を調整する。これを無視する事業者でも、別の制御によってトラフィックが遮断されない限り、公開ページをリクエストできる。

Cloudflare は、クローラーを認識できる場合、そのネットワークエッジで決定を強制できる。これにより、ブロックは設定シグナルより強力になる。しかし、執行は信頼できる識別に依存しており、ユーザーエージェント文字列は無関係なボットによってコピーされる可能性がある。

検証済みボットプログラムは、リクエスト元を事業者提供の情報と照合することで、このリスクを低減する。暗号学的認証はより強い証明を提供し得るが、クローラー市場全体での導入は依然として不完全だ。

検証済みのリクエストでさえ、ページを取得した主体は示せても、その内容の後続利用すべてを必ずしも明らかにしない。クローラー運営者は、検索インデックス、モデルのトレーニング、回答生成、その他の処理の間に内部的な分離を維持する必要がある。

Cloudflare の Accountable 要件は、レポートとコミットメントを通じてこの信頼の隔たりに対処する。URL レベルの可視性は、どのページがトレーニングに利用可能になったか、コンテンツが検索でどのように表示されたかを、パブリッシャーが確認する助けとなるはずだ。

重要なのは「はずだ」という点である。Apple の検証システムはまだ開発中であり、Google の追加ツールは今後提供される予定で、Microsoft のドメインレベル robots.txt サポートは 2027 年初頭を目標としている。

したがって、この指定は現在の機能と将来の約束を組み合わせたものだ。Cloudflare は、4つの要件すべてが現時点で同一の本番実装を備えていると主張しているわけではない。

パブリッシャーはまた、「Disallow AI Training」を普遍的な法的解決策と解釈すべきではない。著作権の例外、契約条件、法域ごとの差異、過去の収集は別個の問題である。新たな設定によって、既存モデルから素材を遡及的に除去することはできない。

この設定は、参加事業者と Cloudflare が実装する今後のクローラー挙動を規定するものである。以前に収集されたコピーが削除されたことを確認するものではない。また、学習済みモデルが情報をどのように保持または再現し得るかを定めるものでもない。

もう1つの不確実性は分類に関するものだ。Cloudflare は、事業者による開示やその他の観測情報に一部基づき、Search、Training、Agent の挙動を割り当てている。クローラーが表明する目的は変わる可能性があり、1つのサービスが複数の製品を支えることもある。

分類が製品変更に追随できない場合、ポリシーはパブリッシャーが想定する以上の活動を許可するおそれがある。透明性のある変更履歴と独立した監視は、初期のダッシュボード設計と同じくらい重要になる。

AI 要約は、さらに大きな隔たりを露呈させる。トレーニングは、コンテンツがモデル開発に寄与するかを決める。要約は、現在のコンテンツが訪問の必要性を減らし得る回答へと変換されるかを決める。

Cloudflare は、AI 要約がすでに検索行動で一般的になっていることを示す調査を引用している。検索行動に関する調査では、AI 要約が表示された際、ユーザーが検索結果のリンクをクリックする可能性が低くなることが判明した。

これはトレーニングと同じ問題ではない。パブリッシャーはトレーニングを拒否することに成功しても、検索製品が新たにインデックスされた素材を要約することで訪問を失う可能性がある。

Cloudflare によると、Accountable 事業者は AI 要約のオプトアウトを直接提供し、最終的には Cloudflare 経由でも提供する必要があるという。次の目標は、要約に含められるコンテンツ量をより細かく制御することだ。

この計画は、二者択一の同意が持つ弱点を認識している。明確なリンクを伴う短い引用を許可することと、ソースの代替となる詳細な回答を許可することは異なる。どちらも技術的には要約利用と見なされる可能性がある。

ビジネスモデルによっても、許容できる均衡は変化する。広告型パブリッシャーは、インプレッションが収益を支えるため訪問数を必要とする。小売事業者は、AI 経由の紹介が購買を増やすなら、訪問数の減少を受け入れるかもしれない。サブスクリプション型パブリッシャーは、生のクリック数よりも帰属表示と読者認知を重視する可能性がある。

Cloudflare は、AI 経由の紹介が従来の検索経由の紹介より高いコンバージョン率を示し得るという第三者推計を引用している。これらの数値はデータセットや手法によって異なるため、失われたトラフィックを普遍的に相殺するものとして扱うべきではない。

真の測定課題は因果関係にある。パブリッシャーは、どのクローラーが URL にアクセスし、どの製品がそれを使い、要約が表示されたか、どの程度のコンテンツが表示されたか、そのインタラクションが訪問を生んだかを把握しなければならない。

現在、ほとんどの組織はこの完全な連鎖を把握できていない。サーバーログはリクエストを明らかにし、検索コンソールはインプレッションとクリックを明らかにする。しかし、どちら単独でも、コンテンツが AI 製品を通じてどのように流れたかは確立できない。

新たな制御機能は、完全な説明責任を実現する前に、主体性を改善する。これによりパブリッシャーは、より限定的なポリシーを宣言し、Accountable の例外に該当しないクローラーにはより強いブロックを適用できる。

これらは監視の必要性をなくすものではない。パブリッシャーは設定変更後、検索カバレッジ、クローラーログ、紹介パターン、主要 AI 製品の公開出力を確認すべきだ。

調査、ドキュメント、または組織の記憶を維持するチームにとって、クローラーポリシーは情報ガバナンスの一層にすぎない。検索可能なナレッジベースは、外部プラットフォームが公開版を要約する場合でも、ソースの文脈を内部で保持できる。

懐疑的な結論は明快だ。Cloudflare は信頼できる制御基盤を構築したが、コンプライアンスは依然として技術的執行、自主的標準、事業者ポリシー、将来の透明性から成るシステムである。

クローラーを Accountable と呼ぶことは、期待される基準を引き上げる。根底にある信頼の問題を消し去るものではない。

新モデルが機能するかを示す3つのシグナル

次の試験は、より多くの企業がその表現を支持するかではなく、Cloudflare の共通ポリシーが測定可能な行動を生むかどうかである。

第1のシグナルは、robots.txt におけるドメインレベルのトレーニング拒否設定に対する Microsoft の約束されたサポートだ。Cloudflare によると、この機能は 2027 年初頭を目標としている。

実用的な実装が実現すれば、混合用途のクローラー事業者3社の間にある最大の現在の隔たりは埋まる。同じ Cloudflare 設定を使って、別個の NOARCHIVE 展開や削除ワークフローを必要とせずに、Bing にトレーニング拒否を伝えられるようになる。

遅延すれば、最も重要な参加者の1社が依然として手動またはページレベルの代替策に依存するため、Accountable 指定は弱まる。この実装では、どの Microsoft の AI 利用が「トレーニング」に含まれ、どれが別個の管理機能に引き続き委ねられるかも明確にすべきだ。

第2のシグナルは、Apple と Google による URL レベルのレポートだ。パブリッシャーに必要なのは、ドメイン設定が存在するという確認以上のものだ。どのページにアクセスされ、どの利用が許可され、設定が後続処理を変更したかを知る必要がある。

Google-Extended に関連する Google の追加予定機能は早期の試験となる。Apple が計画する検証機能は、より長期的な試験となる。有用なレポートは、クローラーアクセスを検索パフォーマンスや AI 上の可視性と比較できる程度に具体的であるべきだ。

一般的なダッシュボード上の件数は、限定的な説明責任しか提供しない。ページレベルの記録、理解しやすい目的ラベル、安定した履歴データは、パブリッシャーが情報に基づく意思決定を行えるという Cloudflare の主張を強化する。

第3のシグナルは、AI 要約制御に関する Cloudflare の取り組みだ。トレーニングのオプトアウトは、パブリッシャーをめぐる対立の一部しか解決しない。検索によって生成された回答は、モデル学習の許可が存在しない場合でもトラフィックに影響し得る。

要約に表示されるコンテンツ量に関する Cloudflare の計画中の制御機能は、単純なオプトアウトより野心的だ。これは事業者に共通の設定を一貫して解釈させ、パブリッシャーが結果を評価できるだけの十分なデータを公開させることを必要とする。

成功すれば、Cloudflare Disallow AI Trainingの背後にあるより広範な原則――アクセスは目的別で、測定可能であり、コンテンツ所有者が変更できるべきだという考え方――が強化される。失敗すれば、出版社は検索・AIプロバイダーごとに異なる制御を管理し続けることになる。

現時点での実務的な対応は、この機能の提供開始を「一度設定すれば終わり」の保証ではなく、ポリシーのアップグレードとして扱うことだ。サイト所有者は、各ドメインで移行後の設定を確認すべきである。特に以前、広範なAIブロック設定を有効にしていた場合は重要だ。

検索アクセスが引き続き許可されているか、またTrainingの表示がBlockではなくDisallow AI Trainingになっているかを確認する必要がある。Blockを選ぶとApplebot、Googlebot、Bingbotが停止する可能性があり、これは学習拒否の意向を示すこととは異なる結果をもたらす。

チームはまた、各カテゴリを許可または拒否する理由を文書化すべきだ。検索、学習、エージェントはそれぞれ異なる目的を担うため、ポリシーはサイトの収益モデルや読者との関係性を反映する必要がある。

変更後は、クローラーの応答とインデックス状況を監視する。検索での掲載範囲が低下した場合、誤った設定が選択されたか、別のファイアウォールルールがその設定を上書きしている可能性がある。

同様の確認は、重要なサブドメインにも適用すべきだ。ドキュメント、サポートセンター、ブログ、アプリケーションページは、親ブランドを共有していても異なる設定の背後に置かれている場合がある。

Cloudflareの今回の提供開始が重要なのは、人為的な二者択一を、より現実的な選択肢へ置き換えるからだ。従来の検索インデックスで可視性を維持するためだけに、サイトがモデル開発向けの素材を提供する必要はない。

ただし、この仕組みの信頼性は検証可能な成果によって決まる。Microsoftは統合を完了させる必要があり、AppleとGoogleは有用な確認手段を提供し、Cloudflareは概括的な制御を出版社が測定できるものへと変えなければならない。

現時点で、Cloudflare Disallow AI Trainingはウェブサイト所有者に、より明確な指示と安全な中間的選択肢を提供している。次の焦点は、最大手のクローラー運営者が、その指示を信頼できるほど可視化するかどうかだ。

ドメインの3つのクローラーポリシーを確認し、意図する結果を記録したうえで、変更後の検索掲載範囲を監視する。トラフィックが安定したまま学習アクセスが減少すれば、この共有モデルは最初の実践的な試験を通過したことになる。