検索エンジンにはサイトを読んでほしい。
でも、AIの学習には使ってほしくない。AIエージェントが人間の代わりにコンテンツを取得することも、同じように許可すべきなのか。
ウェブサイトを訪れる「ロボット」をひとまとめに扱ってきた時代が、終わろうとしている。
インターネットインフラ大手のCloudflareは9月15日、AIなどによる自動アクセスを用途によって分類し、異なるルールを適用する新たなデフォルト設定を導入する。
分類は大きく3つ。
Search（検索）、Agent（AIエージェント）、Training（AI学習）だ。
新しくCloudflareを利用するドメインでは、広告が表示されるページについてTrainingとAgentをデフォルトでブロックする一方、Searchは許可する。
なぜ広告のあるページなのか。
そこには、Cloudflareが考える「ウェブの経済」がかなり露骨に表れている。
広告があるなら「人間に来てほしい」ページ
Cloudflareは、広告が掲載されていること自体を、サイト運営者が「人間にそのページを訪れてほしい」と考えているシグナルとして捉える。
広告モデルのウェブサイトでは、人間がページを訪れ、広告を見ることが収益につながる。
検索エンジンは、サイトの情報を収集する代わりに、検索結果から人間をサイトへ送り返す。
一方、AIの学習用クローラーはコンテンツを取得しても、人間をサイトへ送り返すとは限らない。
AIエージェントも、人間の代わりに情報を取得して回答や処理を完結させれば、ユーザー本人が元サイトを訪れない可能性がある。
だからCloudflareは、広告のあるページではSearchを通し、TrainingとAgentを原則として止める。
これは単なるセキュリティ設定ではない。
「そのロボットは、サイトのビジネスに何を返すのか」
という経済的な違いによって、アクセスを分類し始めたのである。
Search、Agent、Trainingを別々に扱う
Cloudflareの分類では、Searchはコンテンツを収集・インデックスし、後からユーザーの質問などに利用するクローラーを指す。
Agentは、人間の指示を受けてリアルタイムにウェブへアクセスするものだ。チャットサービスがページを取得するケースや、ブラウザーを操作するAIエージェントなどが含まれる。
Trainingは、AIモデルの学習やファインチューニングのためにコンテンツを取得するクローラーである。
サイト運営者は、それぞれについて「すべてのページでブロック」「広告のあるページだけブロック」「ブロックしない」といった判断ができる。
重要なのは、「AI bot」という一つのカテゴリーを拒否する仕組みから、AIがコンテンツを何のために使うのかによって判断する仕組みへ変わっていることだ。
AIを許可するか、拒否するか。
二択ではなくなりつつある。
厄介なのは「一つのロボットが複数の仕事をする」場合
ここで問題になるのが、mixed-use crawler（多目的クローラー）だ。
一つのクローラーが検索のための収集だけでなく、AI学習など複数の用途を兼ねているケースである。
Cloudflareは7月の発表で、こうしたクローラーがサイト運営者の選択を難しくしていると問題提起した。
検索には載りたい。
しかしAI学習には使わせたくない。
それなのに同じクローラーが両方を担当していれば、サイト側は「全部許可するか、全部止めるか」という選択を迫られかねない。
Cloudflareは具体的な多目的クローラーの例として、Googlebot、Applebot、BingBotを挙げている。
特にGoogleについてCloudflareは、検索による発見とAIによる利用を一つのクローラーに重ねることが、サイト運営者による用途別の判断を難しくしていると批判してきた。
Cloudflareもルールを修正した
ただし、この問題はそれほど単純ではなかった。
検索とAI学習を兼ねるクローラーを一律にブロックすれば、「AI学習は拒否したいが検索には載りたい」というサイトまで検索上の不利益を受ける可能性がある。
そこでCloudflareは8月、新たに「Bot Preference Sync」という仕組みを発表した。
サイト運営者がAI学習を拒否する意思を設定すると、その意思をrobots.txtにも反映する。
そして一定の透明性要件を満たし、robots.txtに示された利用条件を尊重する多目的クローラーについては、AI学習を拒否しながら検索目的のアクセスを維持できる方向へ仕組みを調整した。
つまりCloudflare自身も、
「検索とAIを分けろ」
と要求するだけでは問題を解決できず、
「同じロボットでも、何のために来たのかを区別できる仕組み」
へ一歩踏み込んだことになる。
Googleも「検索」と「AI」を分け始めた
この動きは、Google自身の変化とも重なる。
Googleは8月31日、通常のGoogle検索への掲載を維持したまま、AI OverviewsやAI Modeなど生成AI検索へのコンテンツ利用を拒否できる新たなコントロールを世界展開した。
メディア天文台でも前回の記事で取り上げた。
Google側がサービスとして「検索」と「生成AI」を切り分け始めた一方で、Cloudflareはインターネットのインフラ側から、クローラーの目的そのものをSearch、Agent、Trainingに分解しようとしている。
両者は別々の動きだ。
しかし向かっている方向はよく似ている。
「ウェブに公開したのだから、ロボットが何に使っても同じ」
という考え方が成立しにくくなっているのである。
「ウェブに公開する」の意味が細分化される
かつてウェブサイトにとって、検索エンジンのクローラーは比較的分かりやすい存在だった。
ページを読ませる。
検索結果に載る。
そこから人間がやって来る。
もちろん実際の関係はもっと複雑だが、ウェブの広告ビジネスはこの循環によって大きく成長してきた。
生成AIとAIエージェントは、その関係を崩し始めている。
人間には自由に読ませる。
検索エンジンにも読ませる。
AI検索で引用されることは許す。
モデルの学習には使わせない。
AIエージェントには条件付きでアクセスさせる。
場合によっては、利用の対価を求める。
「公開」と「非公開」の間に、いくつもの権利が生まれ始めている。
Cloudflareによると、2026年6月時点で同社が観測するクローラーリクエストの52％はAI学習目的となり、検索・エージェント・学習などを混在させた多目的クローラーも36％を超えた。
もはやウェブを読んでいる機械の目的を、ひとくくりにはできない。
9月15日に変わるのはCloudflareの設定項目だけではない。
ウェブサイトを「誰に」「何の目的で」「どんな条件で」読ませるのか。
生成AIの登場によって、そのアクセス権そのものが再設計され始めている。
参照情報
- Cloudflare「Your site, your rules: new AI traffic options for all customers」
- Cloudflare「Say it once: introducing Bot Preference Sync」
- Cloudflare「Content Independence Day, one year on — building the business model for the agentic Internet」
- Google「New opportunities, control and insights for website owners」
