AIクローラー向けに罠を仕掛けるサイトが増加
2025年初頭、Nepenthesと呼ばれるツールが話題になりました。このツールは偽のWebページの無限の迷路を生成し、各ページからさらに別の偽ページへとリンクを貼ることで、クローラーを脱出不能なループに閉じ込めます。ページ内のテキストは、AIの学習データセットにゴミデータを混入させて汚染するように設計された、アルゴリズム生成の無意味な文字列です。
Nepenthesだけではありません。Locaineなどのプロジェクトをはじめ、オープンソースの「tarpit（タールピット）」がGitHub上に次々と登場しています。いずれも目的は共通しています。AI企業がrobots.txtを尊重しないなら、サイト管理者は毒をもって対抗するという姿勢です。
その動機は理解できます。arXivに掲載された学術調査によると、信頼性の高いサイトにおけるAIブロック率は、2023年9月の23%から2025年5月には約60%へと急増しました。BuzzStreamの分析では、主要ニュースサイトの79%がrobots.txt経由でAI学習ボットをブロックしていることが示されています。さらにCloudflare Radarのレポートでは、2025年半ばにおけるAI関連Webトラフィックの75%が、検索や推論ではなく学習目的で生成されたものであると報告されています。
しかし、tarpitは資格情報を確認しません。スクレイピングの理由を問うこともありません。自動化されているように見えるものはすべてトラップにかけられます。
実際に誰が罠にかかっているのか
本来の標的は明白です。GPTBot、ClaudeBot、学習データ収集のために公開Webを巡回するAI企業のクローラーです。問題は、tarpitがOpenAIのクローラーと開発者の価格監視スクリプトを区別できない点にあります。
tarpitは自動化されたリクエストパターンを検出します。スクレイパーが規則的にリンクを辿ったり、一定の間隔でページへアクセスしたり、JavaScriptの実行をスキップしたりすると（大半のAI学習クローラーの挙動）、標的とみなされます。競合他社の価格を追跡している10人規模のECチームであっても、トラップには関係ありません。ボット特有のトラフィックと判定されれば、偽ページの配信が始まります。
これは理論上の話にとどまりません。ラトガース大学とウォートン校の研究によると、AIクローラーをブロックしたサイトでは、総トラフィックが23.1%減少し、人間のトラフィックも13.9%減少しました。過度なブロック姿勢は、AIスクレイパーを止めるだけでなく、サイト自体の露出度も低下させます。
さらにtarpitは、クローラーの計算リソース、ストレージ、帯域幅を積極的に浪費させ、構築中のモデルやデータベースの精度を損なうデータを送り込みます。
エスカレーションの段階
robots.txtは以前から紳士協定に過ぎませんでした。全員がルールを守っていた間は機能していました。しかし、大手AI企業がそれを無視し始めたり、「検索向けクローリング」と「学習向けクローリング」の解釈を都合よく歪めたりしたことで、サイト管理者は対抗手段をエスカレートさせました。
その傾向は以下の通りです。
- Robots.txtによるブロック: 礼儀正しいリクエスト
- User-Agentフィルタリング: 既知のAIクローラーシグネチャのブロック
- 行動検知: リクエストパターンによる未知のクローラーの検出
- ターピット: リソースを浪費させデータを汚染する能動的な対抗策
各ステップはより多くの脅威を捉えますが、同時により多くの正規トラフィックも巻き込みます。ステップ4に至る頃には、すべての自動アクセスを敵対的なものとして扱うことになります。そのため、比較サービスのために公開されている商品価格を収集するスクレイパーも、無許可でデータを収集するGPTBotと同じトラップにかかることになります。
データチームが今すべきこと
ある程度の規模でデータ収集を行っている場合、ターピットによってルールが変わります。従来よりも重要度が増している点がいくつかあります。
常にrobots.txtを尊重すること。 基本的なことに思えますが、これはもはや前提条件です。サイトはrobots.txtを初期フィルタとして使用します。これを無視すると、ターピットによる対抗策を引き起こす原因となったAIトレーニングボットと同じカテゴリーに分類されてしまいます。
トレーニングクローラーのような挙動を避けること。 AIトレーニングクローラーには予測可能な特徴があります。すべてのリンクを辿り、ページを一括リクエストし、JavaScriptをスキップし、規則的な間隔を維持します。スクレイパーが同様の挙動をすると、行動検知によってフラグが立てられます。タイミングを変化させ、必要なものだけをロードし、サイトが必要とする場合はJavaScriptを実行してください。スクレイパーがブロックされる原因については、Webスクレイパーが破損し続ける理由で解説しています。
受信データを検証すること。 ターピットはもっともらしいゴミデータを返します。パイプライン内でレスポンスを検証していないと、マルコフ連鎖で生成されたテキストを本物の製品説明として保存してしまう可能性があります。検証は後付けではなく、コアステップとして構築してください。
リクエストインフラストラクチャに投資すること。 従来のやり方（IPのローテーション、失敗時のリトライ）だけでは不十分です。現代のボット検知システムは、TLSフィンガープリント、ブラウザの挙動、セッションパターンを分析します。スマートプロキシルーティングも有効ですが、本質的な変化はIPレベルから行動レベルの検知への移行です。JavaScriptを多用するサイトをスクレイピングする場合、ブラウザベースの収集がますます唯一の信頼できるアプローチになりつつあります。
広がるアクセス格差
Webは明確な二極化に向かっていると考えられます。一方には、有料アクセス契約、APIパートナーシップ、ライセンス供与されたクローリングを通じてデータを収益化するサイトがあります。もう一方には、すべての自動アクセスを脅威と見なし、次第に攻撃的な対抗策を展開するサイトがあります。
データチームにとって、これは収集コストが上昇し続けることを意味します。技術の構築が難しくなるからではなく、環境がより敵対的になるからです。責任ある透明性の高いスクレイピング手法に投資するチームはアクセスを維持できます。トレーニングボットのように見えるチームは、トラップに捕まり、データを汚染され、締め出されることになります。
Tarpit（ターピット）がなくなることはありません。チームが考えるべきは、それを警戒すべきかどうかではありません。データがデータベースに到達する前に、インフラストラクチャが実際のページとトラップの違いを識別できるかどうかです。