AIクローラがOSSインフラを潰し始めた — Gentoo Bugzilla停止に見る「防ぎようがない負荷」の正体

はじめに

2026年8月8日、Gentoo Linux の開発者である Michał Górny 氏が、Gentoo の Bugzilla を自らの手で停止した。理由は攻撃を受けたからでも、ハードウェアが壊れたからでもない。LLM 学習用スクレイパーのアクセスですでに使い物にならなくなっていたからだ。

この手の話は2025年から繰り返し報じられてきたので、「またか」と流してしまいそうになる。だが今回の投稿には、これまでの「AI クローラ迷惑」報道と決定的に違う一文が含まれている。**「数千の異なる IPv4 アドレスを使っていて、私に見える範囲では明確なパターンがない」**という部分だ。

これは負荷の量の話ではなく、防御手段の有効性が構造的に失われたという話である。本記事では、Gentoo で何が起きたのか、なぜ既存の対策スタックが順に無力化されてきたのか、そして自分が依存している OSS の情報基盤が落ちたとき何が困るのかを整理する。

何が起きたのか — 「対処する気力がない」という停止理由

Górny 氏の投稿は短い。

I’ve taken #Gentoo Bugzilla down, because it was unusable anyway. No point in feeding the #LLM scrapers that are using thousands of different IPv4 addresses, with no obvious patterns I can see.

（拙訳：Gentoo Bugzilla を落とした。どのみち使える状態ではなかったからだ。数千もの異なる IPv4 アドレスを使い、私に見える限り明確なパターンのない LLM スクレイパーに餌をやり続ける意味はない）

Hacker News では 112ポイントを集める議論に発展し、Cloudflare のロードバランサでボット専用サーバに振り分けろ、Basic 認証をかけろ（Hedgewars はこれで成功したという報告がある）、静的ダンプを配って 429 を返せ、といった技術的アドバイスが並んだ。

しかし本質はそこではない。Górny 氏は数時間後に投稿を編集し、こう追記している。

I’m not looking for hints. I’m not a sysadmin, and I don’t have time to deal with this shit. I’m just trying to get some useful job done. I’m not supposed to have to be dealing with this.

（拙訳：ヒントが欲しいわけじゃない。私はシステム管理者ではないし、こんなことに割く時間はない。有用な仕事をしようとしているだけだ。そもそも私がこれに対処すべきではない）

ここが今回の記事の核心だと考えている。コストは帯域やサーバ費用ではなく、ボランティア開発者の可処分時間で支払われている。 そして支払っているのは、フルタイムの SRE を雇えるプロジェクトではなく、片手間でインフラを維持しているプロジェクトのほうだ。

なお、執筆時点で bugs.gentoo.org はアクセス可能な状態に戻っており、トップページには「スパイダー/ボット/自動処理を動かしているなら Bot Policy を読んでほしい」という告知が掲示されている。停止は恒久的なものではなかったが、「いつでも落ちうる」という前例が残った。

技術的背景 — 防御スタックが下から順に無効化されてきた

AI クローラ対策は、この2年ほどで4段階の防御が試され、そのすべてが部分的に破られてきた。順に見ていくと、今回の「数千 IP・パターンなし」が何段目の敗北なのかがわかる。

第1層：robots.txt。 最も安価で、最も早く破られた。Anubis の作者 Xe Iaso 氏がそもそもこのツールを書いたきっかけが、Amazon のクローラが自分の Git サーバを過負荷にし、かつ robots.txt を尊重せず制限を回避してきたことだった。紳士協定は、守らない側に罰則がない時点で機能しない。

第2層：User-Agent による遮断。 名乗ってくれるクローラにしか効かない。GPTBot のように素直に名乗るものは CDN 側でブロックできるが、名乗らないもの・偽装するものには無力だ。

第3層：ASN / IP レンジ単位のレート制限。 データセンター由来の IP をまとめて弾く手法で、Cloudflare・DataDome・Akamai はいずれもデータセンター ASN をデフォルトでフラグ付けする。これが効いた結果として起きたのが、スクレイパー側の住宅用 IP（レジデンシャルプロキシ）への移行である。2026年時点の観測では、データセンター IP からの単純な GET はもはや通らなくなりつつある一方、住宅用・モバイル回線経由のリクエストは高い成功率を維持している。

Górny 氏が見た「数千の IPv4、パターンなし」は、まさにこの第3層が破られた状態の見え方だ。アクセス元が実在する家庭用回線に分散していると、IP でもサブネットでも ASN でも切れない。 切ろうとすれば正規ユーザを巻き込む。

第4層：Proof of Work（Anubis）。 そこで登場したのが、リクエストの前にブラウザへ計算パズルを解かせる Anubis だ。Go で書かれたリバースプロキシで、ブラウザらしきクライアントに SHA-256 のプルーフオブワークを要求してからバックエンドに通す。1997年の Hashcash と同じ発想で、「1リクエストあたりのコストを人間には無視できるが大規模クローラには痛い水準に引き上げる」ことを狙う。UNESCO、GNOME の GitLab、Linux カーネルの ML アーカイブと Git サーバ、Wine、FFmpeg、SourceHut など、採用先は錚々たる顔ぶれになっている。

Anubis は現状で最も現実的な防御だが、万能ではない。Hacker News の議論でも、計算負荷を強いる方式は低スペック端末のユーザを排除しうるという指摘が出ていた。そして何より、Górny 氏のようにフルタイムの sysadmin がいないプロジェクトにとっては、新しいコンポーネントを導入して運用し続けること自体がコストである。

エンジニアへの影響 — 「issue tracker が落ちる」という新種の依存リスク

これを他人事として読める人は少ないはずだ。実務への影響は2方向ある。

1. 依存 OSS の「情報基盤」への依存を棚卸しする。 私たちはライブラリのバージョンやライセンスを依存として管理しているが、その OSS の issue tracker・メーリングリストアーカイブ・wiki が読めることも暗黙の依存になっている。本番で踏んだ不可解な挙動の答えが、GitHub Issues ではなく Bugzilla のコメント欄や ML の10年前のスレッドにしかない、という経験は珍しくない。それが「今日は落ちている」状態になりうる、というのが今回の教訓だ。

現実的な対策は地味なものになる。重要な issue やスレッドは URL だけでなく本文を手元に控える、Bugzilla のように公開ダンプを提供しているプロジェクトはそれを使う（Gentoo の Bot Policy も、DB に直接クエリを投げる代わりに2時間ごとに更新される静的なバグ一覧ファイルを使うよう案内している）、といったところだ。

2. 自分が公開サービスを運用する側なら、UA 遮断で満足しない。 社内ツールでも OSS のドキュメントサイトでも、公開されている以上は同じ波を受ける。GPTBot を robots.txt で弾いて対策完了としているなら、それは第1層と第2層しか塞いでいない。認証をかけられる範囲は認証をかけ、公開が必要なものは Anubis なり CDN のチャレンジなりを一枚挟む、という判断が必要になる。

そしてもう一つ。同じ8月上旬に、Palo Alto Networks が生成 AI を用いた解析システム NOVA で 3,915 の OSS プロジェクトを検査し、14,090件の脆弱性を検出、うち99.4%が公開報告されていなかったとする調査が報じられている（CVSS v3.1 で「高」4,030件、「極度」5,600件）。AI が OSS の脆弱性を大量に掘り起こしている一方で、その報告を受け止める issue tracker が AI クローラの負荷で落ちている。片方の AI が仕事を増やし、もう片方の AI が受け皿を削っているという構図になっている。

まとめ

Gentoo の Bugzilla は攻撃ではなく LLM スクレイパーの負荷で「使い物にならなくなり」、開発者自身の判断で一時停止された（現在は復旧）
決定的なのは「数千の IPv4、パターンなし」という点で、IP / サブネット / ASN 単位の遮断という第3層の防御が構造的に破られたことを意味する
robots.txt → UA 遮断 → ASN 制限 → Proof of Work と防御は進化してきたが、最前線の Anubis も導入・運用コストを払えるプロジェクトにしか使えない
支払われているコストは帯域ではなくボランティア開発者の時間であり、体力のないプロジェクトほど先に落ちる
依存 OSS の issue tracker や ML アーカイブが読めることは、これまで意識してこなかった種類の依存である

「AI クローラが迷惑」という話は、そろそろマナーの問題から可用性設計の問題に移りつつある。自分のプロダクトが依存している OSS のうち、答えが公式ドキュメントではなく issue tracker にしかないものはどれか——それを一度洗い出しておくだけでも、次に同じことが起きたときの動き方が変わる。

今日のその他のニュース

x86 CPU のハードウェアバックドア「rosenbridge」が再浮上（HN 283pt） — 一部の x86 CPU に隠しコプロセッサ経由の権限昇格経路が存在するという調査が Hacker News で283ポイントを集めた。ハードウェアに埋め込まれた信頼境界の破れは、ソフトウェア側の対策では原理的に塞げないという点で、上のクローラ問題と同じ「レイヤの外から殴られる」構造を持つ。

DynamoDB のリアルタイムベクトル検索対応 — DynamoDB がベクトル検索に対応したことで、小〜中規模の RAG 構成なら専用ベクトル DB を別途立てずに済むケースが出てきた。同日にエンベディング戦略の検討記事も公開されており、設計のベストプラクティスはまだ固まっていない段階。運用対象を1つ減らせる可能性がある一方、移行判断は次の四半期まで様子見でよさそうだ。

ドメインの「売出中」を DNS で表明する仕様（HN 231pt） — WHOIS でも Web ページでもなく DNS レコードでドメインの売却意思を示す新仕様が提案された。ドメイン取得の交渉フローが機械可読になる、という地味だが実用的な提案。