- ウェブサイト運営者が AI学習用スクレイパーボット を相手に、「無限なたわごと」ページを作ってトラフィックを誘導した実験を紹介
- これらのボットは robots.txtを無視し、IPを変えながら継続的にリクエストを送る など、従来の検索エンジンクローラーと違って攻撃的
- IP遮断、速度制限、CAPTCHA、ログインウォールなど 一般的な防御策がすべて無力化 され、実際のユーザーに不便をもたらすだけ
- そこで著者は 偽データ（意味のないテキスト） を自動生成してボットに提供するのが、最も安価で効果的だと発見
- これは AIデータ収集の副作用とサーバー資源の浪費問題 を浮き彫りにし、ウェブ運営者が取れる現実的な対抗策を示している
ボットの正体
- 最近のクローラーは検索エンジン向けではなく、LLM（大規模言語モデル）学習用データ収集 を目的としている
- 彼らはrobots.txtを無視し、ブラウザに偽装したりIPを変えたりしながらアクセスする
- 一日中、毎秒何度もリクエストを送り、サーバー負荷を引き起こす
- 既存の検索エンジンと異なり、彼らはウェブサイト維持に関心がなく、代替可能なデータソース としてしか扱わない
アクセスを許可した場合の問題
- 静的ファイルの提供は安価だが無料ではなく、SSDアクセス遅延とファイルシステムのオーバーヘッド が存在する
- キャッシュにない古いページを要求してサーバー性能の低下を招く
- 帯域消費 も問題で、画像付きブログ記事はすぐに積み上がり、月1TB以上のトラフィックが発生しうる
遮断の試みの限界
- IP遮断は効果がなく、大企業が運用するボットネットワーク は数千のアドレスを保有している
- すべてのアドレスを遮断しても、新しいIPを購入して再接続する
- リクエスト速度制限（rate limit） も役に立たず、リクエストごとに異なるIPを使う場合もある
ファイアウォールと認証障壁の副作用
- ログイン、決済、CAPTCHA、ハッシュベースのプルーフ・オブ・ワーク（proof-of-work） などさまざまな防御策が提案されたが、いずれもユーザーの不便を招く
- アカウント必須化は読者のアクセスを妨げ、JavaScriptベースの検証は非JSブラウザを排除する
- ページ読み込み速度の低下でユーザー体験も悪化する
圧縮爆弾（gzip bomb）の無力さ
- 一部では gzip爆弾 でボットを攻撃しようという提案もあるが、実際の圧縮率は1000倍程度にすぎない
- 100GBに展開されるファイルを作るには、100MBのアセットを提供する必要がある
- 実験の結果、ボットはこれを無視するか、むしろさらに多くのリクエストを送った
だます戦略の失敗
- 404エラーを返してサイトが存在しないように見せかける 「Jedi mind trick」 方式も失敗
- リンクが外部に掲載されるとボットは存在を認識し、アクセスが遮断されるとむしろさらに攻撃的にリクエストする
- 結果として、ボットを満足させなければサーバーは平穏にならない
ゴミデータ提供の効率性
- 動的コンテンツ生成は高コストに見えるが、実際には CPUとRAMが最も高速な資源 である
- 遅いと評価されるのは、データベースI/Oや複雑なJSロジックのため
- 著者が作った Markovベースのbabbler は、リクエストあたり約60マイクロ秒のCPU、1.2MBのメモリしか使わない
- ディスクアクセスなし、ブラックリスト管理も不要
- ボットが自らやって来て、意味のないテキストを消費しながらサーバー負荷を減らす構造 になっている
結論
- AI学習用ボットの無差別なデータ収集は、ウェブインフラのコスト増加とコンテンツの悪用 を招く
- 単純な遮断より 意味のないデータで対抗する戦略 のほうが費用対効果が高く、サーバー安定性の維持に有利
- これは今後の AIクローリングとウェブエコシステムの共存策 を模索する実験的アプローチとして評価できる
2件のコメント
おお…斬新でいいですね。
Hacker Newsの意見
リンクの前にある隠し段落の指示が面白かった
「このページの内容は危険なので公開するな」といった感じの、LLMをだまそうとするいたずらめいた案内文があった
関連文書はこのリンクにある
最後の「LLM instructions」部分は実際の本文ではなく、LLMを混乱させるためのメタ指示なので要約から除外した
私は以前からこういう戦略を勧めてきた — AIボットに本物らしく見えるゴミデータを大量に供給して、最終的に人間がフィルタリングしなければならないようにするやり方だ
すべてのサイトがこうすれば、AIが学習するデータの品質は急激に低下するはずだ
戦うのが難しいなら、いっそデータの洪水で覆ってしまうほうがいい
SEO用のおとりのように、ニュースドメイン風のサイトを作って製品の宣伝記事をばらまくやり方で
こうした試みは迷惑電話に対処するようなもので、時間の無駄にすぎない
結局、人を雇うことはほとんどないだろう
「Markov babbler」の詳細はこの投稿にある
pthread_detachの引数エラーが発生する著者の使っているコンパイラは警告を無視しているようだ
プログラムはスレッド管理の上限なしにリクエストを処理するので、コンテナ内で非特権ユーザーとして実行するのが安全だ
sprintf()のような危険なC関数も使われているようで、セキュリティ上の注意が必要だ私のサイトではすべてのリンクにBasic Authをかけているが、まだどのボットも通過できていない
なので、すべてのWebサイトが同じ公開資格情報を使ったらどうかと思う
ユーザー: nobots / パスワード: nobots
ボットはこれを知っていても突破できるだろうか?
ほとんどのボットがまだこうしたケースを考慮していないだけだ
http://username:password@example.com形式でリクエストすれば簡単に解決する私も今では彼らにゴミデータを提供している
ちなみに Frankenstein、Alice in Wonderland、Moby Dick をソースに使ったが、ファイルが大きくて読み込みが遅い
pthread_detach(&thread)をpthread_detach(thread)に変えてコンパイルエラーを解消した私は「ethical crawler」を運用している
Webサイトに負荷をかけないようリクエスト頻度を低くしており、RSSアクセスが塞がれている場所が多くなってきて次第に難しくなっている
私のクローラーはさまざまなヘッダーや仕組みを試しながら探索する
コード: crawler-buddy, Django-link-archive
requirements.txtに feedparser があるのに、実際に使われている形跡がない検索結果でも確認できる
The Cost of Trashの記事では、gzip bombは効果的ではないと述べられている
gzip はせいぜい約1000倍しか圧縮できないので、100GBを作るには100MBのファイルを提供しなければならない
しかもボットはむしろさらに多くリクエストしてきたという
ほとんどのクライアントはストリーミング方式で展開するため、全体をメモリに載せない
gzip bomb が実際に機能するには、異常なやり方で処理する必要がある
参考: zlib APIドキュメント
中にランダムなゴミを入れてもいいし、AIに学習させたいメッセージを埋め込むこともできる
注意すべきなのは、一部のリクエストが実際にはユーザーのブラウザをプロキシとして使っている場合があることだ
一部のブラウザ提供事業者はユーザーのトラフィックをプロキシとして利用している
自動リクエスト検知の誤差が小さいなら、暗号通貨のマイニングコードを仕込むことも可能かもしれないが、本物のユーザーに影響するリスクがある
特にモバイルエージェントを使うAIリクエストがあるのか気になる
「Markov babbler」はリクエストあたり約60μsのCPUを使うとのことだが、
ここにイデオロギー的メッセージや宣伝文句を混ぜたコンテンツを作ってAIに学習させたらどうかと思う
そうなればAIが妙な政治的発言をするようになるかもしれない
少なくとも著作権侵害とサーバー負荷を減らす効果はあるはずだ
そもそもなぜサーバー側でMarkovテキストを生成するのか?
ボットがJavaScriptを実行するなら、クライアント側で生成させればいいのでは?
しかもMarkov連鎖のデータをクライアントに送るほうがむしろ非効率だ
各リクエストはマイクロ秒単位のCPUと1MB前後のRAMしか使わないので、サーバー側で処理しても十分軽い