AIクローラーがgit.kernel.orgを圧迫 — 1日600万リクエスト、Anubisの検証を33%が突破しCPUの20%を占有（kernel.org管理者が報告）

LinuxカーネルのGitホスティングサービス git.kernel.org が、AI学習用の大規模クローリング（自動収集）によって持続的な負荷を受けている。Linux FoundationでITインフラとカーネル施設を統括するKonstantin Ryabitsev氏が2026年8月29日に公開した記事「Creepy crawlies」で、実測に基づく現状を報告した。記事はLinux Foundationの公式方針ではなく、管理者個人の観測として示されたものだ。

1日600万件、33%が検証を突破

Ryabitsev氏によると、git.kernel.orgは現在、1日約600万件のランダムなコミット閲覧リクエストを受けている。サイト前面に導入された Anubis（訪問者の端末に少量の計算を課すプルーフ・オブ・ワーク検証）の検証によって、66%は直ちに遮断される。だが33%は計算を完了して本サイトへ到達しているという。

同氏は、寛大な仮定を置いても正規の利用は全体の約2%程度にとどまり、残りはスクレイパー（収集プログラム）によるものと推定している。管理者の説明では、古いフォークに含まれる古いコミットを片端から要求するようなアクセスは、実際の開発者が業務で必要とする動きではない。

CPUの20%が常時、HTMLレンダリングに占有される

負荷の深刻さはCPU占有率に表れている。Ryabitsev氏は次のように述べている。

「スクレイパー向けにコミットをレンダリングするために費やすCPUサイクルは、git cloneを含む他のすべての正規アクセスを合わせたよりも多い」

5つの地理分散ノードで合計90コアを運用する環境で、常時14〜16コアがコミットをHTMLとしてレンダリングする処理だけに占有されている。平均で**容量の約20%**が失われており、カーネル側が公開するグラフでは、群れのように波状に押し寄せるアクセスによって負荷がさらに跳ね上がる瞬間もあるという。

なぜgit.kernel.orgが狙われるのか — 非効率なHTML収集

Linuxの開発は公開が原則だ。Gitリポジトリは誰でもクローンでき、メーリングリストもリアルタイムで追跡できる。大規模言語モデル（LLM）にとって、AI生成テキストが混入していない「純粋でクリーンな」学習データとして、カーネルの全履歴は価値が高い。Ryabitsev氏は、LLMがLLM生成コンテンツで学習すると「デジタル・プリオン病」のような品質劣化を招くため、AI以前から蓄積されたカーネルの記録は「金と同じ重さの価値がある」と表現している。

本来なら**「git clone」一回で全履歴を取得**できる。しかし一部のクローラーは、cgitが生成するHTMLをコミットごとに1件ずつ取得して解析するという、最も非効率な方法を選んでいる。

執筆時点でlinux.gitは約148万コミット、git.kernel.orgには約922のフォークがある。バックエンドでは大半のオブジェクトが共有されるため効率的だが、スクレイパーにとっては数十億（several BILLION）通りの有効なURLが生まれ、922のフォークで同じ148万コミットを重複して収集することになる。さらにパッチ表示や差分表示など、cgitが提供する高コストな表示機能も大量のURLを生み出す。

住宅用プロキシとAnubis突破 — 対策の限界

当初、クローラーはUser-Agentで正体を明かしたり、クラウドの固定IPに集中したりしたため、fail2banやIP/ASN単位のブロックが有効だった。やがてクローラーは一般的なブラウザに偽装し、固定IPでのブロックをすり抜け始めた。

現在は住宅用・モバイル回線のプロキシ経由で、1つのIPが4〜5回リクエストしただけで姿を消す。ブロックが追いつかない。Ryabitsev氏は、この背景にプロキシSDKのマネタイズ網があると指摘する。テレビ（SamsungやLG）などに組み込まれた多数のアプリがプロキシSDKを内包し、利用者のネットワークを中継点として貸し出す仕組みが確認されているという。

対抗策として導入したAnubisは、当初は効果的だった。難易度4の計算（IPと秘密値を組み合わせてSHA256の先頭が0で始まる文字列を探す作業）をクローラーは諦め、平穏が数カ月続いた。だが数カ月後に難易度4を突破され、難易度5へ引き上げると今度はスマートフォンなど正規利用者の端末で数秒の待ち時間と発熱が生じるようになった。数カ月後、難易度5も突破され、現在は66%遮断・33%突破という状況に至っている。難易度をさらに上げれば正規利用者への負担が増すため、際限なく強化できない。

今後の対応 — 機能制限と正規の取得手段

Ryabitsev氏は、現時点ではインフラが完全に逼迫しているわけではないと説明する。git.kernel.orgへアクセスすれば通常は軽快に応答する。むしろシステムを停止させるのは、20拠点から同時にstable.gitをshallow cloneするような設計不良のCIだという。

一方で、対策としてクロール可能なURL数の削減、高コスト機能の無効化、匿名アクセスへの制限強化を準備していると明かした。利用者にとっては一部機能が使えなくなる犠牲を伴うが「今は必要だ」と述べている。データ自体は引き続き誰でも取得できるように提供するが、取得までに追加の手順が必要になる可能性がある。

同氏は、AIバブルが弾けて学習データの需要が落ち着くか、クローラーが「最も愚かな方法」をやめてgit cloneなど効率的な手段へ切り替えることを期待しつつ、短期的にはアプリ側が家電を中継点化する動きも続くため「簡単な解決策はない」と結論づけている。

日本の開発者・企業が取るべき対応

Ryabitsev氏が推奨する正規の取得手段は、分散したオープンソースの原則に沿ったものだ。

• HTMLのスクレイピングではなく、git cloneやアーカイブのミラーを使う — git.kernel.orgが提供するクローン可能なリポジトリやアーカイブを直接取得すれば、サーバ側のレンダリング負荷を生まない
• CIや自動取得の設計を見直す — 20拠点からの同時shallow cloneなど、短時間に高負荷な操作を集中させない。自前ミラーを用意する
• 匿名アクセスの制限強化に備える — 今後、未認証での高コストなcgit操作が制限される可能性があるため、必要なデータは事前に正規手順で取得・保持する

出典: Konstantin Ryabitsev, “Creepy crawlies”, people.kernel.org, 2026年8月29日. https://people.kernel.org/monsieuricon/creepy-crawlies