すべての記事

分類広告サイトに来るAIクローラー、実際にどれを遮断すべきかを決めるもの

16 分で読めます

サーバーログに映るボットは、Googleだけではない

クラシファイドディレクトリのアクセスログを、たとえ一日分だけでも開いてみれば、訪問者のリストはもはや「人間の一覧」には見えなくなる。Googlebotやおなじみのブラウザに混じって、GPTBot、ClaudeBot、PerplexityBot、Bytespider、CCBotといった、調べてみるまで何の意味も持たない名前が十数個も並んでいるはずだ。これらは1時間前に更新されたページまで含め、すべての掲載ページにアクセスしており、しかも人間の訪問者なら絶対に辿らないようなスケジュールで動いている。

アダルト・クラシファイドディレクトリが他の多くのサイトよりもこの種のクロールの標的になりやすいのは、コンテンツがアダルトだからという理由ではない。掲載情報は絶えず更新され、都市とカテゴリーによる構造が個別ページの数を何倍にも増やし、そのひとつひとつに、クローラーが一度のアクセスで収集できる写真とテキストが載っている。訪問者にとってサイトを使いやすくしているのと同じ特徴が、スクレイピングする側にとっての効率の良さにもなっているのだ。

本来、これを取り決めるはずのファイルがrobots.txtだ。名前の付いた各クローラーに対して、何を取得してよいかをプレーンテキストで記したルールの一覧である。ドメインのルートに置かれ、どのクローラーも読むことができ、「ルールを尊重する」と公言している企業、OpenAI、Anthropic、Googleなどが作ったクローラーは、おおむねその通りに振る舞う。しかしこのファイルは、あくまで「お願い」であって「施錠」ではない。禁止されたページを取得することをプロトコル上止める仕組みは何もなく、運営者が別途何らかの対策を上乗せしない限り、サイト側にルールを強制する手段もない。

このギャップは、以前よりも重みを持つようになっている。なぜなら、そのログに現れるクローラーは、もはや一枚岩ではないからだ。あるものはそのページでモデルを訓練したいと考えている。あるものはいま目の前にある質問にそのページを使って答えたいと考えている。またあるものは、利用者本人のリクエストがAIアシスタント経由で届いているだけだ。この3種類を、すべて遮断するか、すべて通すかという形で一緒に扱ってしまうのは、運営者が本来選べるはずの選択肢を自ら放棄することに等しい。

学習、回答、「利用者からの質問」は、一つの名前をまとった三つの別の仕事だ

OpenAIは三つの独立したクローラーを運用しており、これらを一緒くたにしてしまうことが、急いで書かれたrobots.txtで最もよく見られる誤りだ。GPTBotは将来のモデル学習に使われる可能性のあるページを収集するもので、OpenAI自身のドキュメントも、これを拒否(disallow)すればそのサイトのコンテンツを学習データから外せると説明している。OAI-SearchBotは学習とは無関係で、ChatGPTの検索機能においてページが引用元として表示されるための仕組みであり、GPTBotとは別個に制御できるため、学習はブロックしつつ引用対象には残るという設定も可能だ。ChatGPT-Userはそのどちらでもない。実際の利用者がChatGPTに対してそのページについて直接質問したときに動くもので、OpenAIは、これはクロールではなく特定の人間からのリクエストへの応答であるため、robots.txtのルールが適用されない場合があると明言している。

Anthropicも、名前は違うが同じ三分類の線を引いている。ClaudeBotは学習目的でクロールを行い、Anthropicのサポート文書も、その点についてはボットがrobots.txtの指示に従うとしている。Claude-UserとClaude-SearchBotは、それぞれリアルタイムの質問対応と検索citation(引用)のケースを担っており、それぞれに個別のオプトアウト手段が用意されている。

Googleのやり方はもっと狭い範囲の話だが、逆に誤解しやすい。Google-Extendedはそもそもクローラーではなく、robots.txtに追加するトークンであり、Googlebotが既に取得したコンテンツをGeminiの学習や回答の裏付け(grounding)に使ってよいかどうかを制御するものだ。これを拒否しても、サイトのランキングや通常のGoogle検索への掲載には影響しない。Googlebot自体は以前と変わらずクロールを続けるからだ。検索結果が従来の「青いリンクの一覧」ではなくGoogleのAI Overviews内で直接回答されるようになったとき、クラシファイドディレクトリが表示される可能性がどう変わるかを左右するのは、Google-Extendedとは別の設定だ。AI Overviewsは通常のGooglebotクロールを基にしているため、Extendedトークンをブロックしても、Geminiの学習から外れるだけでAI Overviewsからは外れない。AI Overviewsと通常の検索スニペットの両方に同時に効くレバーは、nosnippet系タグだけであり、これは多くの運営者が実際に設定を切るまで気づいていないほど大きなトレードオフを伴う。

実務上の結論はこうだ。運営者は、名前の付いたすべての学習用クローラーを拒否しつつ、検索・引用用のクローラーには手を付けないrobots.txtを書くことができ、一方の結果だけを得て他方は失わないようにできる。この区別は、誰かが偶然作り上げるものではない。ボットごとに、一つひとつ手作業で書き込む必要がある。

Cloudflareの新ポリシーが加えるもの、そしてそれでもできないこと

robots.txtは、もともと一つの問いにしか答えるようには作られていない。「どのページを取得してよいか」という問いだ。「そのページを取得した後、何をしてよいか」という二つ目の問いに答える設計にはなっていなかった。2025年9月に導入されたCloudflareのContent Signals Policyは、まさにこの二層目を加えるものだ。サイトは今、任意のuser-agentグループの下にContent-Signal行を追加し、search、ai-input、ai-trainという三つの値それぞれにyesかnoを設定できるようになった。いずれかの値を書かなかった場合、それは「答えはno」ということではなく、運営者がその用途について意思表示をしていないことを意味する。

これが特に有用なのは、運営者が一か所で「検索のためにはインデックスしてよいが、モデルに入力するな、学習にも使うな」と言えるようになる点だ。これは、従来のrobots.txtの文法にはそもそも語彙が存在しなかった区別である。Cloudflareの管理型robots.txtサービスを利用する約380万のドメインには、search=yes、ai-train=noが自動的に追加された。それ以外の運営者は、自分で該当行を書き加えるか、contentsignals.orgで生成することができる。

正直な限界は、Cloudflare自身によるこのポリシーの説明の中にある。これらはあくまで「宣言された意思表示」であって技術的な障壁ではなく、これを無視することを選んだクローラーを止めるものは、ファイアウォールのルールやボット管理製品のように、サイト側が別途上乗せした対策以外には何もない。

この限界は、ポリシーが実際に導入される1か月前には、すでに理論上の話ではなくなっていた。2025年8月、Cloudflareは、Perplexityが「ステルスクローラー」と呼ぶべきものを運用していると非難するレポートを公表した。禁止設定を施したテスト用ドメインをクロールする前にrobots.txtを取得していなかったボットが、公式に名乗っているPerplexityBotがブロックされると、一般的なChrome風のブラウザの識別情報に切り替え、Perplexityが公表していないIPレンジを経由してアクセスしていたという内容だ。Cloudflareはこの調査結果を受けて、Perplexityを検証済みボット・プログラムから除外した。Perplexity側はこのレポートを「売名目的の策略」だと反論し、帰属の特定にも異議を唱えたが、個々のユーザーエージェントやIPに関する具体的な証拠そのものには、一点ずつ反論することはなかった。どちらの言い分がより正しいにせよ、このエピソードは、robots.txtであれContent-Signal行であれ、宣言されたルールは「それに従うと自ら決めたクローラー」しか縛らないということを示す、現時点で最も明快な実例である。

運営者が実際に負う二つのコスト

一つ目のコストは、請求書に現れるタイプのものだ。このカテゴリーの運営者の多くが実際に利用している、格安VPSや共有ホスティングプランで動くクラシファイドディレクトリは、無制限の帯域ではなく、月あたりのデータ転送量の上限が設定されているのが一般的で、クローラーによる転送量も、料金を払う訪問者とまったく同じようにこの上限に積み上がっていく。複数都市をカバーするディレクトリ上のすべての掲載情報と写真を、繰り返しのスケジュールで学習用クローラーが再取得していけば、サイトが本来サービスを提供すべき相手とは何の関係もない負荷が積み増されることになる。そして、ホストやCDNが通知一本でクラシファイド事業を終わらせてしまう、あのインフラの脆弱さと同じ構造が、ボットトラフィックによる使用量ベースの利用停止に引っかかったアカウントにも、まさにそうした突然のシャットダウンのリスクをもたらす。ボット管理ベンダーのImpervaは、2026年版の「Bad Bot Report」で、計測対象のウェブトラフィック全体のうち自動化トラフィックが半数をわずかに上回り、そのうちの約40パーセントが悪質なものに分類されたと報告している。この数字自体は、この問題に商業的な利害を持つ一社からのものではあるが、サイトの帯域コストのかなりの部分がそもそも人間のトラフィックではないという方向性については、どのディレクトリの生のアクセスログを見ても一致する傾向だ。

二つ目のコストは、請求書にはまったく現れない。ディレクトリ自身のデータベースに対する削除リクエストであれば、運営者は実際に対応できる。該当レコードを見つけ、削除し、消えたことを確認すればよい。だが、学習用クローラーがすでに収集し、モデルに一般的なパターンを学ばせるためのデータセットに取り込んでしまった写真やプロフィール文には、それに相当するリクエストの送り先がない。学習用コーパスにはサポート窓口も存在せず、特定の広告主の画像がサーバーを離れた後に保持され続けたのか、されなかったのかを確認する手段もない。これは、写真に付随する通常のメタデータによって、クラシファイドサイトが広告主について何を漏らしてしまうかという問題にすでに当てはまっている、コントロールの難しさの、さらに厳しいバージョンだ。コンテンツが一度外に出てしまえば、それがどこへ渡ったのかを運営者が説明できる度合いは急激に下がる。「私の掲載情報の写真は結局どこに行き着くのか」と尋ねる広告主には、運営者が保証できない安心材料ではなく、その限界についての正直な答えこそが必要とされる。

具体的に何をすべきか

まず、現在のrobots.txtの内容を思い込みではなく実際に読むことから始めよう。テンプレートから作られたクラシファイドサイトの驚くほど多くが、ファイル自体を一切持たず、すべてのクローラーに自分自身の制限を決めさせてしまっているか、あるいはステージング環境の名残として「User-agent: *, Disallow: /」という一括禁止の一行だけを残しており、これがGooglebotまで含めて何もかもブロックし、エラーメッセージも出ないまま、サイトのオーガニック検索チャネルを静かにゼロにしてしまっている。

最初に決めるべきは学習用クローラーの扱いだ。これは実際にはっきりした答えが出せる問いだからだ。少なくともGPTBot、ClaudeBot、Google-Extended、Bytespider、CCBotについては、明示的にdisallowのルールを書いておきたい。これらは、公開され文書化されたユーザーエージェント文字列を持つ主要な基盤モデルの学習用クローラーをカバーしている。これは、デフォルトのまま放置するのではなく、運営者が意図的に下せる決定である。

検索・引用用クローラーの扱いは、学習用とは別に、そしてきちんと自分で決めよう。学習用に書いたルールをそのまま流用するのではない。OAI-SearchBot、Claude-SearchBot、PerplexityBotは、ある掲載情報で答えられるような質問を誰かがAIアシスタントにしたとき、そのディレクトリが引用元になれるかどうかを左右する。これらをブロックすればその可視性を手放すことになり、許可すれば維持できる。そして、その答えが、一行上に書いたGPTBotやClaudeBotに対する答えと同じでなければならない理由は何もない。

サイトがCloudflare上で動いているなら、Content-Signal行が自動的に追加されているかどうか、そしてそのデフォルト設定が運営者本来の意向と一致しているかどうかを確認しておきたい。自動設定は妥当なものではあるが、あくまで汎用的なものであり、個々のサイトに合わせて調整されたものではないからだ。Cloudflareを使っていない場合は、該当の行を数分で手書きするか、contentsignals.orgで生成して貼り付ければよい。

最後に、robots.txtとContent-Signalのルールは、取り組みやすい「残り九割」のための対策だと位置づけ、残る一部のクローラー、つまりCloudflareがPerplexityに対して行ったと非難したようなことを平気でやるクローラーは、どれほど丁寧にテキストファイルを書いても止まらないという現実を受け入れておきたい。こうしたクローラーを見つけるには、公表されているボット名が、そのボットが公表しているIPレンジの外から届いていないかを見張る必要がある。予算が許せばCDNのボット管理機能が自動的にそれを検知してくれる場合もあるし、定期的にアクセスログを確認する運営者であれば手作業でも見つけられる。いずれにせよ、目指すべきは望まないクローラーをすべて排除することではない。それは実現不可能だ。目指すべきは、実際にルールに耳を傾けるつもりのあるクローラーに対して、三つの仕事のうちどれを許可するのかを、はっきりと伝えることなのだ。

DEMOを試す

エスコート情報サイトのシステム、すぐ使える