AIクローラーの「背景放射」に立ち向かう：git.kernel.org が直面する負荷の正体

2026年9月7日 H.Ueda

カーネルメンテナーである Konstantin Ryabitsev 氏のブログ記事 Konstantin Ryabitsev を読み、AI 開発の裏側で起きているインフラへの深刻な影響について、実務者としての苦労がひしひしと伝わってきたので、こちらで内容を整理してみたいと思います。

これ問題だなぁと思うけど、良い解決策が見当たらないですね。AIクローラー向けのキャッシュサイトとかあると良いのかしらん。紳士協定だと駄目かなぁ。

現在、多くのエンジニアが AI（大規模言語モデル：LLM）の恩恵を受けていますが、その学習データを収集する「クローラー」たちが、公開リポジトリのインフラに対して無視できない負荷を与えているようです。

要点：正当なアクセスを上回る「スクレイピング」の負荷

結論から申し上げますと、Linux カーネルのソースコードを管理する git.kernel.org では、現在、開発者が行う git clone などの正当なアクセスよりも、AI 学習用と思われるスクレイパー向けの処理に多くのリソースを割かざるを得ない状況にあります。

具体的な状況は以下の通りです。

CPUリソースの占有: 地理的に分散された5つのノード全体で、常に14個の CPU コアが「git コミットを HTML としてレンダリングするためだけ」に稼働し続けています。
背景放射のような負荷: もはや一時的なものではなく、システムの背景ノイズ（背景放射）のように、常に一定のリソースがこれらによって拘束されています。

なぜ git.kernel.org が狙われるのか

AI モデルの学習において、Linux カーネルのコードやその開発プロセス（ディスカッション）は「宝の山」とされています。その理由は、データの質が非常に高いことに加え、「AI が生成したコンテンツが含まれていないこと」が保証されているからです。

AI が生成したデータで AI を学習させることは、専門家の言葉を借りれば「デジタル・プリオン病」のような品質劣化を招くリスクがあります。そのため、AI 普及以前からの純粋な人間の思考記録であるカーネルのコミット履歴は、トレーニングデータとして極めて価値が高いといえます。

最も非効率な方法でのデータ収集

データを収集すること自体は、オープンソースの性質上、拒否されるものではありません。しかし、問題はその「やり方」にあります。

本来、git のリポジトリを丸ごと取得するのであれば、git clone を一回実行するのが最も効率的です。しかし、多くのクローラーは、ウェブブラウザで人間が見るための HTML 画面（cgit など）を一つずつ巡回してパースするという、非常に効率の悪い方法を採っています。

以下の図は、効率的なデータ取得と、現在のスクレイパーによる非効率なアクセスの違いをイメージしたものです。

flowchart TD
    subgraph Efficient ["推奨される方法 (効率的)"]
        A["git リポジトリ"] --> B["git clone / fetch"]
        B --> C["ローカルで解析・学習"]
    end

    subgraph Inefficient ["クローラーの現状 (非効率)"]
        D["git リポジトリ"] --> E["HTML レンダリング (CPU 消費)"]
        E --> F["HTTP レスポンス (帯域消費)"]
        F --> G["HTML パース"]
        G --> H["次のコミット URL へ"]
        H --> E
    end

たとえば、linux.git には約148万件のコミットがあり、900以上のフォーク（複製）が存在します。サーバー側ではオブジェクトを共有して効率化していますが、スクレイパーが HTML 経由でこれらを巡回すると、重複したデータを何度もレンダリングさせることになり、膨大な計算資源が浪費されます。

無限に広がる URL 空間

さらに深刻なのが、生成可能な URL の数です。cgit のようなツールでは、特定のコミットの表示だけでなく、パッチ形式での出力や、任意のコミット間での差分（diff）表示などが可能です。

人間が利用する分には便利な機能ですが、クローラーにとっては、一つのリポジトリから「1.2 垓（10の20乗）」という、事実上無限に近い数の有効な URL を生成できてしまいます。これが、インフラを管理する側にとって大きな脅威となっています。

項目	開発者による `git clone`	クローラーによるスクレイピング
主なプロトコル	git / https (smart-http)	https (HTML)
サーバー負荷	低（圧縮データの転送が主）	極めて高い（HTML の逐次生成）
データの重複	なし（差分のみ取得可能）	膨大（フォークごとに再取得）
効率性	非常に高い	非常に低い

防衛策の限界：家庭用機器のプロキシ化

当初、管理者側は怪しい IP アドレスを特定し、fail2ban などでブロックすることで対処していました。しかし、クローラー側も次第に巧妙になっていきました。

初期: ユーザーエージェントで正体を明かしていたため、遮断は容易でした。
中期: 一般的なブラウザのふり（偽装）をし始めましたが、特定のデータセンター（Google Compute など）からのアクセスだったため、ASN ごとのブロックで対処できました。
現在: 数百万ものランダムな家庭用 IP やモバイル IP から、数回ずつリクエストが送られてくるようになりました。

この背後には「住宅用プロキシ（Residential Proxy）SDK」というビジネスがあるようです。たとえば、一部のスマート TV アプリなどに組み込まれた SDK を通じて、一般家庭のネットワークがクローラーの踏み台として利用されています。こうなると、正当なユーザーとの区別がつかず、単純な IP ブロックは事実上不可能です。

まとめ

オープンなデータを公開し続けることは、コミュニティにとって重要な価値ですが、現在の AI クローラーによる無秩序なアクセスは、そのインフラを支える善意とリソースを限界まで削っています。

「API や git プロトコルを使わずに、なぜあえて重い HTML を叩くのか」という問いに対し、クローラー側が効率を求める気配は今のところなさそうです。私たち開発者も、公開されているリソースを自動で収集する際には、その裏側にあるインフラへの敬意を忘れないようにしたいものですね。

参照記事

Konstantin Ryabitsev

MicroArchitectures

H.Ueda

Programmer

ブログ