sprinklz.io が Hacker News 投稿後に AI ボットの洪水に見舞われる：何が起きたか、そして開発者はどうサイトを守るか

ある小さなフィードリーダープロジェクトに関する Hacker News の投稿は、約 100 の upvote を集めた後、サイトをボットトラフィックで埋没させました。全リクエストのほぼ半数が単一の AI ニュースレタースクレイパーによるものでした。この出来事はサイト作者によって記録され、174 人のコメント投稿者によって議論され、HN での公開露出が、今や人間のオーディエンスよりも大きいことが多い自動化トラフィックの波を確実に引き起こすことを示しています。

要旨

Sammy Straus 氏は、LLM などのトピックを優先順位下げできるカスタマイズ可能なフィードリーダー sprinklz.io を Hacker News に投稿しました。その投稿は「100 程度の upvote」を得ました。数日後、サイトはまだ遅く、さらに遅くなっていました。実際にアクティブでログインしているユーザーはほんの一握りしかいないにもかかわらずです。

「私のウェブサイトが遅くなりました。本当に、耐えられないほど遅く。最初は、突然人気が出た投稿による余分な注目のせいだと思いました... しかし奇妙なことに、遅さは続き、私の投稿が公開されてから 数日後 にはさらに悪化し始めました。そして私が記録していたメトリクスも意味を成しませんでした。」

原因は HN のオーディエンスではありませんでした。それは自動化トラフィックであり、1 つの犯人がその大部分を占めていました。

診断の手がかり：ほとんどのリクエストが JavaScript を実行しなかった

sprinklz.io はシングルページアプリケーションであるため、実際のページビューにはブラウザが JavaScript を取得して実行する必要があります。作者がすべてのエンドポイントにトップレベルのロギングを追加したとき、そのパターンは明白でした。ほとんどのリクエストはニュース記事の取得をまったく試みていませんでした。

「リクエストの大半は、ページをレンダリングするために必要な JavaScript すら実行していませんでした (!)。」

その単一のシグナルが、人間の訪問者とスクレイパーを区別します。ページを読み込むブラウザは、ドキュメント、次に CSS、JavaScript、favicon アセットをリクエストします。テキストだけを欲しいスクレイパーは、ドキュメントだけをリクエストし、他は何もリクエストしないことがよくあります。コメント投稿者の dhosek 氏は、まさにこのヒューリスティックを使っていると説明しました：

「本当に便利だったのは、リクエストパターンによって『ステルス』ボットトラフィックを特定できることです（例：ページ読み込み時に CSS/JS/favicon をリクエストしない）。」

トラフィックのほぼ半数が 1 つの AI ニュースレタースクレイパーからのもの

NGINX ログを集計して悪用者を特定したところ、作者は全トラフィックのほぼ半数が単一のソースからのものであることを発見しました。それはウェブサイトの変更を監視し、AI 生成のニュースレターに要約するサービスでした。それはサイトに毎分数回クエリを送っていました。作者はそれをブロックしましたが、名前を明かすことを拒否しました。

コメント投稿者はその抑制に反発しました。Havoc 氏は次のように書きました：

「その種の行動は、名前を公表して非難するに値すると思います。無頓着でひどいサービスは、その名前を守るような丁寧さを受けるに値しません。」

andai 氏はスクレイパー自身のロジックを疑問視しました：「毎秒多数のリクエストを送っていたように聞こえるので、それが理由であるはずがない」と、新鮮なコンテンツを求めることに関して。

名前付きクローラーと脆弱性スキャナーが残りを占めた

残りのトラフィックは、特定可能なクローラーと攻撃者の混在でした。作者は ClaudeBot、OpenAI のボット、Google の検索インデクサー、「その他いくつか」を挙げ、さらに /wp-content/phpinfo.php などのパスを調べる脆弱性スキャナーも挙げました。これは WordPress ではないサイトです。

drnick1 氏は、このノイズが日常的であると確認しました：「これは普通です。私は毎日ログで何百、いや何千ものこれらを見ています。」

switz 氏はクラウド ASN 全体（AWS、Google Cloud、Azure、Alibaba Cloud、Oracle）をブロックしたと述べ、2 年前の Alibaba Cloud の禁止が今でも 1 つのドメインに対して 1 日あたり約 100 万リクエストを生成し、そのすべてが 4xx 応答を返したと報告しました。同じコメント投稿者は、Apple が「過去数ヶ月で積極的にスクレイピングを強化しているが、ありがたいことに robots.txt を尊重している」と指摘し、一部の AI スクレイパーは検出を回避するために現在住宅用 IP ボットネットを経由していると述べました。

作者が適用した緩和策

作者の対応は、アクセス制御とパフォーマンス作業を組み合わせたものでした：

ほとんどの AI スキャナーを阻害しつつ、Googlebot やその他の検索関連トラフィックを許可する robots.txt を追加。
合理的なレート制限を追加。
Claude を使用して脆弱性パスをクエリし、スキャナーを模倣して、何も漏れていないことを確認。
サイトが高いクエリ毎秒負荷を処理できるように、大規模なインフラストラクチャの改善を開始。

「しかし最も重要な教訓は、私のウェブサイトをより速くする時が来たということです。私は、実際のトラフィックの XXX QPS を処理 できる ウェブサイトになりたいのです。」

HN での露出は、upvote がなくてもボットを引き寄せる

複数のコメント投稿者が、フロントページに達しなかった投稿からの同じ洪水を報告しました。Twiin 氏は、「文字通りゼロの upvote とゼロのコメント」の投稿が「狂ったようなボットトラフィックに見舞われた」と書き、リンクが投稿されたのは HN だけだったと述べました。

Jaxan 氏は引き金となる条件を簡潔に要約しました：「ああ、サブドメインに TLS を追加するとすぐに、ボットが来ます。即座です。」 nubinetwork 氏は、ウェブコンテンツがまったくないドメインで LLM のようなトラフィックを受信したと報告しました：「最近は、ただ存在するだけでスキャンされます。」

firefoxd 氏は逆の効果を説明しました。つまり、ボット防御技術（zipbombs）について公に書くことが問題を悪化させたのです：「それはウェブ上でメガバイラルになり、後悔しています。私のサーバーはボットトラフィックで完全に圧倒されました。」

ボットトラフィックは実際の請求書と障害を生む

複数のコメント投稿者がコストを定量化しました。QueensGambit 氏は、ClaudeBot に起因する Google Cloud の請求書が 1 か月で 10,000 ドルになったと報告し、ユーザーがコーディングエージェントとブラウザプラグインを使用して自分のソフトウェアを複製しようとしていると推測しました。pampas 氏は、Wikipedia をミラーリングするゲーム redactle.net が、ボットがあらゆるページを叩きキャッシュヒット率を下げたため、大きなクラウド egress 請求書を生成したと述べました。trinsic2 氏は、自分のサイトが「トラフィックのせいでしばらくシャットダウンされた」と述べました。

layerv-ai 氏は複合的なリスクを指摘しました：HN や Twitter でプロジェクトをマーケティングすると、Vercel の請求書が「CF のボット保護があっても、ボットがサイトを粉々にスクレイピングして、屋根を突き抜ける」可能性があります。

開発者が実際に実行している防御策

コメント投稿者は、幅広い対策を説明しましたが、コンセンサスはありませんでした：

チャレンジページ。 8by3 氏は Anubis の Elixir 版である Sphinx を構築し、「正規のクローラーをホワイトリストに登録しても、トラフィックの 80% 以上がチャレンジに失敗するボットです」と報告しました。paaloeye 氏は Cloudflare Turnstile を提案しました。
ターピット。 robotmay 氏は、クライアントがパケットを受け入れるのと同じくらい遅くリクエストを提供するカスタム L7 プロキシを構築し、2 つの小さな Hetzner VM で約 3,000 の同時クローラーを閉じ込めました。「リクエストを拒否しただけでは、彼らはさらに激しく私のサーバーを叩きました。」
ブロックリスト。 pmlnr 氏は abuseipdb ブロックリストを推奨しました。minimaxa 氏は、チームが IP 範囲全体をブロックし、無料ツール Vorwatch をリリースしたと述べました。
ベーシック認証。 goodthink 氏はホームページ以外のすべてをロックダウンし、そこに認証情報を置くことで、アセットスクレイピングを止めました。
ブロックよりもレート制限。 mboyd1 氏は、Lightpanda ユーザーエージェントのみをハードブロックし、それ以外はレート制限を好むと述べました。なぜなら、エージェンティックトラフィックはプレミアム API アップセルに変換できるからです。
諦めて最適化。 timpera 氏は Cloudflare、Anubis、fail2ban を試した後、次のように結論付けました：「この軍拡競争に勝つことはできません。だから私はサーバーのパフォーマンス改善に頼り、すべてのリクエストに応答することにしました。」

すべてのボットトラフィックが無価値なわけではない

議論には、全面ブロックへの明確な反論が含まれていました。beybol 氏は、インデックス作成クローラーとユーザー起動のフェッチを区別しました：

「OAI-SearchBot/GPTBot/ClaudeBot は単なるインデックス作成ですが、ChatGPT-User/Claude-User などは、ユーザーと LLM の会話によって生成された価値あるトラフィックかもしれません。したがって、すべてをブロックするのではなく、どれをブロックするかを選ぶ価値があります。」

mboyd1 氏もビジネス観点から同じ主張をし、エージェントに「私のアプリケーションを有用なリソースとして見てもらい、より大きなレート制限を望むエージェンティック開発者へのプレミアム API アップセルを促進する」ことを好みました。

アーキテクチャの教訓：SPA とキャッシュ可能性

最も繰り返された技術的批判は、ボットではなくサイトのアーキテクチャに向けられました。est 氏は簡潔に書きました：「私のウェブサイトはシングルページアプリケーションとして構築されています。それで終わりです。やめてください。ページをできるだけキャッシュ可能にしてください。」 mediumsmart 氏は、Google Lighthouse と PageSpeed Insights を同じ結論の出発点として指摘しました。

静的なキャッシュ可能なページは、リクエストごとに JavaScript を実行しなければならない SPA よりもはるかに安価にボットの洪水を吸収します。作者自身の結論（サイトが高い QPS を処理する必要がある）は、別の方向から見た同じ修正です。

実践的な教訓

エンドポイントごとのリクエスト数をログに記録する。 この事件で最も有用なシグナルは、ほとんどのリクエストが実際のユーザーが取得するコンテンツを取得しなかったことです。
クライアントが CSS、JavaScript、favicon をリクエストするか確認する。 これらをスキップするスクレイパーは、ほぼ確実にブラウザではありません。
トラフィックスパイクが人間によるものと想定する前に、ソースごとにログを集計する。 このサイトの負荷のほぼ半数は 1 つのサービスからのものでした。
ブロックする前に、インデックス作成クローラーとユーザー起動のフェッチを区別する。 検索ボットとユーザーに代わって行動するエージェントは異なる価値を持ちます。
エンゲージメントがゼロでも、公開リンクからのトラフィックを想定する。 複数のコメント投稿者が、upvote がなかった投稿からの洪水を報告しました。
帯域幅だけでなく、egress とコンピュートの予算を組む。 ボットの洪水は、小規模プロジェクトに 4 桁から 5 桁のクラウド請求書をもたらしました。
キャッシュ可能で静的に配信されるページを好む。 スクレイパーの洪水に対する最も安価な防御は、提供コストがほぼゼロのページです。