AI スクレイパーに git サーバを溶かされる側の話 — kernel.org の cgit / Anubis / fail2ban を運用者目線で読む

AI スクレイパーが git サーバを溶かす、その一番非効率なやり方

git.kernel.org は今、正規アクセスよりも多くの CPU を「AI 学習用スクレイパーへの HTML レンダリング」に奪われています。kernel.org のインフラを管理する Konstantin Ryabitsev が公開した運用記録によれば、地理分散した 5 ノードの合計 CPU の 20%、コア数にして 14〜16 個が、常時スクレイパー向けの commit 描画に張り付いているそうです（Konstantin Ryabitsev "Creepy crawlies"）。git clone すれば全履歴が一度で取れるのに、スクレイパーはわざわざ cgit（git リポジトリを HTML で見せるビューア）の commit ページを 1 個ずつ舐めていきます。

なぜそんな非効率なことをするのか。理由はデータの質にあります。Linux カーネルのソースは「AI が書いていないと保証できる」希少な学習データで、しかも完全に公開されている。linux.git だけで 148 万コミット、フォークを含めると約 922 リポジトリぶんの履歴があり、commit と diff の組み合わせは事実上無限の URL を生みます。スクレイパーから見れば、そこは掘っても掘っても尽きない鉱脈に見えるのでしょう。

その結果が「正規トラフィックは全リクエストの約 2%」という数字です。1 日あたり約 600 万リクエストのうち、人間や git clone のための正規アクセスはごくわずかで、残りはほぼ全部スクレイパー。サーバは自分を使ってくれる相手のためではなく、奪っていく相手のために燃えている。この一文に、いまの公開インフラが置かれた状況が凝縮されています。

Anubis の proof-of-work — 「計算させて足止めする」防御

kernel.org が取った主対策は Anubis という proof-of-work（アクセス前に計算を課して足止めする仕組み）ゲートです。訪問者のブラウザに対して「あなたの IP とこちらが渡す秘密の値を組み合わせて、SHA256 ハッシュの先頭が 4 桁ゼロになる文字列を探せ」という宿題を出し、解けた相手だけを通します（Anubis）。

この仕組みの狙いは、正規のブラウザには一瞬（数百ミリ秒）で終わる程度の負荷でも、何百万ページも舐めたいスクレイパーには「1 ページごとに計算コストが積み上がって割に合わなくなる」点にあります。人間 1 人の 1 回のアクセスは軽い。けれど大群で舐める側には、ボディブローのようにじわじわ効く。攻撃者を弾くのではなく、攻撃を非経済的にするという発想です。

導入からおよそ 1 年、効果は数字にも表れています。1 日 600 万リクエストのうち約 66% は Anubis のチャレンジ段階で弾かれ、チャレンジを解いて中に入るのは約 33%。かつて正規が全体の 2% しかなかったことを思えば、ゲートは確かに機能しています。ただ、この「33% は解いて入ってくる」という部分が、次の問題につながります。

スクレイパーは適応する — user-agent から residential proxy まで

防御を一段上げるたびに、スクレイパーはさらに一段上の偽装で応じてきました。最終的には住宅用 IP の大群と、Anubis の難易度突破にまで到達しています。これは「防いだら終わり」ではなく、いたちごっこが今も続いている構図です。

最初、怪しいアクセスは user-agent 文字列（ブラウザの自己申告）で見分けられました。そこを塞ぐと、スクレイパーは正規ブラウザになりすまして user-agent を詐称。次に IP でまとめて弾こうとすると、今度は residential proxy（一般家庭の回線を経由させる串）や携帯回線の IP を大量に使い始めます。厄介なのは、その多くが proxy SDK monetization — スマート TV アプリなどに仕込まれた串化 SDK 経由で、末端ユーザーの気づかないうちに彼らの回線が貸し出されている点です。悪意ある少数の攻撃者ではなく、無数の善良な家庭の回線が串にされている。

fail2ban（短時間に不審なアクセスを繰り返す IP を自動 ban するツール）も投入されましたが、これも決定打にはなりませんでした。理由は単純で、住宅用 IP の大群は「1 つの IP から 1 回だけ、ぱらぱらとリクエストする」ため、fail2ban が閾値で捕まえる『同じ IP の連打』というパターンにそもそも当てはまらないからです。そして一部のスクレイパーは、Anubis の難易度レベル 4 や 5 の計算まで解いて突破するようになりました。宿題のコストを織り込んでもなお、舐める価値があると判断されている。

運用者として何を学ぶか — 「正規と悪意の区別」が壊れた世界

この事例のいちばん重い教訓は、「正規アクセスと悪意あるアクセスを技術的に区別する」という前提そのものが崩れかけている、という点です。IP でも user-agent でも proof-of-work でも、決定的な線はもう引けません。

正直に言うと、私が運用している小さなサイトのトラフィックは kernel.org の足元にも及びません。1 日 600 万リクエストどころか、access log を眺めているとむしろ寂しくなる規模です。それでも、このサイトも AI が下書きを書き、私が公開前に確認して出す仕組みで回しているので、スクレイパー側の事情も防がれる側の苦労も、まるきり他人事ではありません。launchd で自動化を 24 時間回していると、ログの中に見慣れない串経由のアクセスがぽつぽつ混じるのを見かけます（launchd で自動化を 24/7 回すと踏む罠）。

一次情報を出す側としてできることは、たぶん 2 つに寄っていきます。1 つは「効率的な取り方（git clone や API、エージェントに Markdown を返す口）をちゃんと用意して、非効率な HTML 舐めに誘導しない」こと。もう 1 つは「学習データとして舐められること自体を前提に、自分のコンテンツが重みの中でどう扱われるかを織り込んで運用する」ことです。壁を高くする軍拡だけでは、いずれ住宅用 IP の海に沈みます。

まとめ — 壁を高くするより、正規の道を広くする

kernel.org の一件は、公開インフラを持つ全員に効いてくる話です。cgit のような重い動的レンダリングを無防備に晒すと、それは正規ユーザーではなくスクレイパーのための計算資源になってしまいます。

Anubis の proof-of-work は時間を稼ぐ有効な一手でしたが、万能ではありませんでした。相手が住宅用 IP の大群と難易度突破で応じてくる以上、防御は「弾く」だけでなく「そもそも重い経路を作らない」「効率的な取得口へ誘導する」方向へ設計を寄せる必要があります。壁を高くする競争より、正規の道を広くしておくほうが、長い目で見れば自分の CPU を守ってくれるはずです。