Webクローラーは本来、検索エンジンがページを発見・理解するための「インフラ」でした。ところが2024〜2025年にかけて、AIが検索画面上で回答を完結させる流れが加速し、「クロールされても読者が来ない」「それでもクロールは増える」というねじれが顕在化しています。結果として、クローラーは“必要悪”ではなく“コストとリスクを生む存在”として嫌われる局面が増えました。 今クローラーが嫌われる最大の理由は、「クロールの対価＝送客（トラフィック）」という暗黙の交換条件が崩れたためです。AI回答（要約・オーバービュー）が検索結果上で完結するほど、サイト側は「帯域・サーバー負荷・コンテンツ流用リスク」だけを負担しやすくなります。 加えて、robots.txtを無視する・目的（検索/学習/推論）が不透明・アクセス量が過大といった“悪い実装”が増え、技術者・運用者の現場感として「全部まとめてブロックしたい」に傾きやすいのが実情です。 従来のWebエコシステムは、ざっくり言えば次の交換で回っていました。 しかしAI回答が普及すると、検索結果ページ内でユーザーが満足してしまい、クリックが発生しにくくなります。実際、Pew Research Centerの分析では、AI要約が表示される検索では外部サイトへのクリック率が低下し、要約内の「引用元リンク」のクリックはごく一部にとどまる傾向が示されています。なぜ今、クローラーは嫌われるのか──送客モデル崩壊とAI回答の衝撃
結論
送客モデルの崩壊
この状況でサイト側が感じるのは、「検索に出るためにクロールを許可してきたのに、検索が“答え”を持っていき、訪問は増えない」という不満です。ここが、クローラー全般への拒否反応を強める土台になります。 AI回答は、単に「クリックが減る」だけではありません。運用・収益・リスクの観点で、次の変化を同時に起こします。 ユーザーがSERP（検索結果）上で離脱するほど、メディア・EC・B2B問わず、コンテンツ投資の回収が難しくなります。ニュース業界では「AI要約がCTRを大きく落とす」という調査・報道も出ており、送客の前提が揺らいでいます。 AI要約が引用元リンクを付けても、ユーザーが「答え」をその場で得る限り、リンクは補助情報にとどまりがちです。クリックが起きるとしても一部サイト（例：Wikipedia等）に偏る可能性があり、ロングテールの発信者ほど不利になります。 SEOは「順位」だけでなく「AIに要約されるか」「引用されるか」「引用されてもクリックされるか」に分岐します。つまり、クローラー対策は“流入最適化”から“露出と権利の設計”へテーマが移りました。 現場がクローラーを嫌う理由は、感情論だけではありません。インフラ運用の観点で、明確なコスト要因があります。 クローラーは同一リソースを大量に取りに来ます。動的ページや画像最適化、認証前提の画面、API同等の高負荷ページが混ざると、瞬間的にサーバーコストが跳ねます。 robots.txtは「守る前提」で成り立つ“紳士協定”です。検索エンジンの代表例であるGoogleは、robots.txtの解釈やHTTPステータスに対する扱いを明確に文書化していますが、全クローラーが同様に従う保証はありません。 公式ドキュメントによると、Googleはrobots.txt取得時のHTTPステータス（4xx/5xx等）に応じて「制限なし」とみなすケースがあります。意図せずクロール制限が外れる運用事故が起き得る点は押さえておきたいところです。 この挙動を理解せずに「403で弾けばOK」などをやると、想定と逆の結果になり得ます。 近年は「検索用」「学習用」「ユーザー操作でのアクセス用」など、同じ事業者でも複数のUser-Agentを持ちます。OpenAIは、OAI-SearchBot（検索）とGPTBot（学習）を分け、さらにユーザー起点のアクセス（ChatGPT-User）も区別して説明しています。 サイト側は「何のためのクロールか」が分からないほど、まとめて遮断しやすくなります。 「嫌う」だけでは終わらず、実際にブロックや課金の動きが出ています。代表例がCDN/WAFを提供するCloudflareの取り組みです。 CloudflareはAIボット遮断を強化し、AIクローラーをデフォルトでブロックする方向性が報じられています。また、同社ブログでも「ワンクリックでAIボットをまとめてブロック」できる機能を紹介しています。 注意：ブロックを強めるほど、正規の検索クローラーや有益なクローラーまで巻き込むリスクが増えます。特にB2Bのリード獲得や採用など、検索露出が生命線のサイトは段階的に適用してください。 こうした“遮断がデフォルト”に近い状態は、クローラー側から見ると「クロールできるのが当たり前」ではなくなったことを意味します。 「送客の対価」が機能しにくいなら、アクセス自体を課金対象にする発想が出てきます。CloudflareのPay Per Crawlは、その文脈で語られることが多い施策です。AI回答のインパクト
ゼロクリックの増加
「引用」でも救われない
競争条件が変わる
嫌われる技術的理由
帯域・CPUの負担
robots.txtの限界
目的が不透明なUA
事業者が取る対抗策
AIボットの遮断が標準化
ペイ・パー・クロール
実務での判断軸
「クローラー＝悪」と決めつけると、検索流入・提携・露出の機会を失います。一方で、無制限に許可するとコストとリスクが積み上がります。現実的には、次の軸で整理するのが安全です。
目的別に許可する
可能なら「検索用は許可」「学習用は拒否」など、目的で分けます。OpenAIのように用途別User-Agentを明示している事業者は、分離制御がしやすい部類です。
技術的な防御を重ねる
| 対策 | 狙い | 弱点 |
|---|---|---|
| robots.txt | 善良なクローラーの制御 | 無視される可能性 |
| レート制限 | 過剰アクセス抑制 | チューニングが必要 |
| WAF/ボット管理 | 検知・遮断を自動化 | 誤検知と運用コスト |
| キャッシュ最適化 | 同一取得の負荷低減 | 動的ページは難しい |
robots.txtの例
以下は「検索用クローラーは許可しつつ、学習用は拒否する」設計のイメージです（実際のUser-Agentは各社ドキュメントに合わせてください）。
User-agent: GPTBot
Disallow: /
User-agent: OAI-SearchBot
Allow: /
OpenAIは、検索用（OAI-SearchBot）と学習用（GPTBot）を分けて案内しています。サイトの方針に合わせ、段階的にルールを調整するのが現実解です。
スクレイパー側の作法
ここまで「嫌われる理由」を書いてきましたが、スクレイピング/クローリングを業務で行う側にも守るべき作法があります。結局のところ、嫌われるのは“クローラー”という技術ではなく、“無遠慮な実装”です。
同意と透明性
- User-Agentに連絡先や目的を入れる
- robots.txtとサイト規約を尊重する
- 必要なら事前に許諾を取る（API提供があれば優先）
負荷の最小化
- レート制限（秒間/分間の上限）
- 条件付きリクエスト（ETag/If-Modified-Since）
- キャッシュと差分取得
「取れるから取る」運用は、IPブロックや法的トラブルだけでなく、業界全体の締め付け（CAPTCHA強化、WAFデフォルト遮断）を招きやすくなります。中長期の安定運用を優先してください。
クローリングの設計、丸投げしませんか？
「嫌われない」クローラーの構築には、レート設計・UA管理・robots.txt準拠など細かなノウハウが必要です。要件定義から安定運用まで、スクイピングのスペシャリストが対応します。
まとめ
- クローラーが嫌われる背景には「クロールの対価＝送客」の崩れがある
- AI回答でゼロクリックが増え、サイト側はコストとリスクだけを負いやすい
- 現実解は「目的別許可」＋「WAF/レート制限等の多層防御」
