要注意！Webクローラーが引き起こす厄介な問題と対策

「Creepy Crawlies」というタイトルで投稿された本件は、Webサイトのインデックス生成やデータ収集を行うボット（クローラー）が引き起こす、予期せぬ負荷やセキュリティ上の懸念についての議論を指していると思われます。これらは時にサイトパフォーマンスを低下させたり、意図しないクロールによってサーバーリソースを枯渇させたりするため、robots.txtの設定やレート制限といった適切な制御が不可欠です。

かつて人気があったゲームサイトを運営しているんだけど、以前は毎秒数百件もの正当なリクエストがあったんだ。特に人気のイベント期間中は負荷が跳ね上がるから、ずっと専用サーバーで運用してきた。そこには「オンラインユーザー数」を表示するカウンタもあって、認証なしでもセッションを維持している実際のユーザー（コメント投稿やフィルタ設定などができる人たち）を数えるようにしていたんだ。Googleボットはカウント対象外だった。

ここ数年で、このカウンタの数値が100〜200人から数千人に激増した。長年ほとんど放置して、最小限のアップグレードとバックアップだけしていたんだけど、サイトがかなり重くなっていて、明らかにこれらのセッションが影響しているようだった。それでようやくクローラーを調査してみたら、案の定、完全に人工的なトラフィックが異常な量になっていた。実際のユーザーはほんの一握りで、残りの数千ものクロール用セッションが、クリックできるボタンを片っ端から押しまくっていたんだ。検索や並び替え機能がGETリンクで実装されていたことも、状況を悪化させた一因だろうね。

カウンタを修正してクローラーを除外できるようにしたんだけど、ちょっとしたジレンマがある。クローラーが全てのコンテンツを基に知識を更新するのを完全に止めたくはないんだよね。

今のところベストな解決策は、CloudFlareの新しい機能で、クローラーにリクエストごとに課金するか、そうでなければブロックするというものだと思っている。インターネット全体にとって素晴らしいアイデアだと思うよ。ベータ版の利用を申し込んだけど、その後連絡がない。ただ、これにCloudFlareのような仲介者が必要なのは残念なことだ。

全体として、LLMはインターネットの経済性や開放性を本当に追い詰めているように見える。かつてはメールスパムが最悪だったけれど、インターネット全体を吸い上げている巨大テック企業の研究所の動きをよりうまく先回りして阻止できなければ、何かが壊れてしまうだろうね。

著作権や公共のインターネットシステムが十分に対応できていないのは残念だ。それに、この競争がこれほどまでの猛スピードで進まなければならない理由はどこにもないと思うんだ。

Tavis Ormandyがちょうど1年前にAnubisについて指摘していたね：
https://news.ycombinator.com/item?id=44962529

結局のところ、決定的な解決策にはならなかった。高性能なスクレイパーはエンドユーザーよりもはるかに効率的にProof-of-Work（PoW）の課題を処理できてしまうからね。PoWが機能するのはパスワードハッシュのような場合で、パスワードを推測してもその一回一回にはほとんど利益がないからだ。でも、スクレイパーにとっては、リクエストの一つ一つが利益を生む仕事なんだよ。

この記事の文体、すごくよかったよ。

「User-Agentの偽装」から「IPアドレスの変更」、そしてプロバイダーによるサブネットやASN単位でのブロッキングを経て、「プロキシSDK収益化」という手法に気づくまでのボットの進化過程は、LLMが登場する前の脅威アクターの進化とそっくりだね。

我々が提供するものが、Anubisの課題を計算するために膨大なCPUサイクルを費やす価値があるからという理由で

この主張には、Anubisの根底にある誤解が含まれている。実際には「膨大な」サイクルなんて必要ないんだ。ボットには面倒だがモバイル端末の人間には使える、といった難易度設定なんて存在しないよ。

先日、lists.ffmpeg.orgがAnubisの難易度レベル6に移行したのを見たんだけど、僕のiPhone 17で解こうとすると約100KH/sで180秒もかかって、サイトが使い物にならなくなった。だから10分くらいで遊び半分にSafari拡張機能を作ったんだ。ARM SHA256H命令を使った最適化済みC言語カーネルをネイティブブリッジで動かすものなんだけど、同じデバイスで200+ MH/sが出せる。これでAnubis難易度レベル6を数ミリ秒で突破できるようになった。

使われている数値と能力（5,000ドルのASICマイナー単体で200TH/s出る。iPhoneで動かす最適化済みカーネルの100万倍のハッシュレートだ）を考えると、ユーザー体験を損なわずにボットを排除する持続可能な戦略としてPoWが機能するとは思えない。これは勝てない軍拡競争だよ。

追記：ぜひ自分で試してみてほしい。このタスクを一撃で解決するためのプロンプトのサンプルを置いておくよ：

[サンプルプロンプトの内容省略]

ここ数日、自分のウェブサイトの一つに罠を仕掛けていて、皮肉なことにLLMを使ってやっているんだけど、すごく楽しんでいるよ。

AnubisのようなPoWシステムではなく、僕は「iocaine」的な手法をアプリケーション自体に実装したんだ。Elixirで構築しているから、サーバーリソースをほとんど消費せずにスクレイパーを困らせるのが本当に面白くてね。

今は、美味しいデータがあるように見せかけて、悪いスクレイパーを偽の無限ブラックホール経路に誘い込み、15分かけて1バイトずつ画像を配信したり（ヘッダーはすぐに送る）、レスポンスを膨らませてトークンを無駄遣いさせたり、セクシーなトースターのAI生成画像をランダムに返したりしている。管理者ダッシュボードには、どれだけ手ひどくやられたかを競う小さなリーダーボードがあって、秋の冷え込む夜にこれを見るのがささやかな楽しみなんだ。

なぜ git.kernel.org がクローラーにとって「興味深い」のか

この投稿は、ボット運営者がいかに深く考えず、努力もしていないかを過小評価していると思う。私ももっとずっとつまらないプロジェクトを載せたcgitインスタンスを運営しているけれど、それでもHTTPリクエストの洪水からは逃れられていないよ。

考えられる理由は、どれだけ意味があるか、あるいは負荷がかかるかを無視して、あらゆるリンクをクロールしようとしているからだろう。cgitである以上、パラメータやハッシュの組み合わせ次第で数十億ものリンクが存在することになるしね。そうでなければ、意図的なDDoS攻撃のどちらかだろうね。

私も公開cgitインスタンスを運営していて、毎日100万ヒット以上受けている。趣味のプロジェクトだし、Linuxカーネルのような規模や影響力とは比較にならないんだけどね。結局、diff、blame、snapshot、歴史的コミットへのcgitエンドポイントを（nginx設定で）ブロックするしかなかった。それ以外は何も効かないからね。今は402（Payment Required）を返している。これは自分の中では完全なる敗北だし、心の中では泣いているんだけど、どうしようもないね。

彼らほどの規模ではないけれど、コンシューマー向けアプリを運営していて、ユーザーのほとんどはモバイルアプリからで、ウェブアプリの利用者はモバイルアクティブユーザーの10〜15%程度なんだ。

それなのに、毎日毎日、深い階層のページへのリクエストで爆撃されている。セッション時間に基づくDAUが100倍に増えたときはかなり焦ったよ。結果的に、そのすべてがボットだとわかったんだけどね。

私も最初は、User-Agentのブロック（Metaはありがたいことに身元を明かしてくれるが、1日5万リクエストを送りつけてくるのは勘弁してほしい）や、クラウドプロバイダーのIP範囲、怪しいトラフィックに関連するブラウザのフィンガープリントをブロックすることで対処しようとした。

でも、すべてのコンテンツを認証の裏側に隠すのはやりたくないし、現状この戦いに勝つのは難しそうだ。50万ページほどのユーザー生成コンテンツがあるし、それらは公開しておきたいんだよ。

スクレイパーのいずれかにデータを提供してもいいと思っているし、403レスポンスを返すときにはいつでも連絡をくれとメッセージを追加しているけれど、誰からも連絡がこない。

他にも、公開されているプライベートな変数を探そうとして、何百もの設定ファイルパスを毎日チェックするような攻撃も続いている。これはもう404を返すだけだけど、ブロックしているよ。

結局、ローテーションする住宅用IPへの対策は見つかっていないし、今後も一生見つからない気がする。

今のやり方は、Codexを使って全リクエストを24時間スキャンし、本物の人間に影響を与えない範囲で、IPレンジやブラウザのフィンガープリントをNext.jsのプロキシに追記し続けるというものだ。

誰か、このクローラーやスクレイパーの猛攻を止める方法を見つけた人はいないだろうか？

皮肉なことに、「隠蔽による防御」こそが正解かもしれない。

Anubisをフォークして、ハッシュ関数を少しだけ改造するんだ。そしてデプロイする。フォークを広めようとせず、公開すらしない。これでASICも、Anubis専用に最適化されたクローラー（現時点では全てそうだけど）も完全に無力化できる。もし多くの人がこれをやれば、彼らは本物の人間のようにJSを動かすか、あるいはホストごとにGPUカーネルをAIエージェントにコンパイルさせるような、とんでもないパイプラインを構築するしかなくなるだろうね。

深夜3時の本番環境トラブルシューティングを思い出したよ。どちらも心臓が飛び出るほどびっくりするからね。