AIスクレイパーがもたらす「バックグラウンド放射線」

Linuxカーネルの開発リポジトリであるgit.kernel.orgでは、近年AIスクレイパーによるアクセスが急増し、システムの運用に大きな影響を与えています。

現在、地理的に分散した5つのノード全体で、常に14のCPUコアがGitコミットをHTMLとしてレンダリングする作業に費やされており、これは正規のアクセスによる負荷を上回っています。

運営担当者によると、Gitリポジトリへの正規のアクセス、例えばgit cloneによるクローン作業よりも、スクレイパーが引き起こすシステム負荷が大きくなっているというのです。これはまさに「バックグラウンド放射線」のようなもので、常に一定のシステムリソースがAIの学習データ生成のためだけに消費されている状況を示しています（出典）。

普段から個人プロダクトでクラウドサービスを利用している身としては、この「常時14コア占有」という数字はかなり衝撃的です。GCPのCloud RunやCompute Engineでコストを最適化しようと四苦八苦している開発者にとって、これだけのCPUリソースが意図しない用途で浪費されるというのは、想像を絶する事態ではないでしょうか。コスト面だけでなく、システムの安定性やスケーラビリティにも影響を与える可能性があります。

なぜLinuxカーネルのリポジトリが狙われるのか

AIスクレイパーがgit.kernel.orgを「金脈」と見なすのには明確な理由があります。

  • 高品質な学習データ: Linuxカーネルの開発履歴は、Gitリポジトリから誰もがアクセスでき、議論のアーカイブもリアルタイムで追うことができます。これはLLMにとって、膨大かつ「純粋な」学習データの宝庫です。特に、LLMが生成したコンテンツでLLMをトレーニングすると「デジタルプリオン病」のような悪影響があるため、LLMが生成していないことが保証されているカーネルのコミット履歴は非常に価値が高いとされています（出典）。
  • 非効率なスクレイピング方法: git.kernel.orgのデータはgit cloneコマンドを使えば簡単に全履歴を取得できるにもかかわらず、スクレイパーはあえて非効率な方法を選んでいます。つまり、1つ1つのコミットをHTMLとしてレンダリングし、それをパースするという「最も愚かな」方法でデータを収集しているのです。LinuxカーネルのGitリポジトリには約148万件のコミットがあり、さらに約922件のフォークが存在します。スクレイパーはこれらの膨大なURLを一つ一つ巡回し、重複するデータを取得している状況です。
スクレイピング方法 特徴 システム負荷 効率性
git clone 全履歴を一括取得 低 高
HTMLレンダリング コミットごとにHTMLとして取得しパース 高 低

AIを自作PCで動かしたり、Claude Codeでバイブコーディングを実践している身としては、「なぜgit cloneを使わないのか？」という疑問が真っ先に浮かびます。効率性を追求するはずのAIが、これほどまでに非効率な方法を選ぶ背景には、おそらく法的な制約や、スクレイピング対象のWebサイトの構造を理解する手間を省きたいといった思惑があるのかもしれません。しかし、これはリソースを著しく無駄にしており、本当にAIが賢いのか疑問に感じてしまいます。

スクレイパーとの攻防、そして新たな課題

運営側もこの問題に対して手をこまねいていたわけではありません。初期には以下の対策を講じていました。

  • ユーザーエージェントによるブロック: スクレイパーが自身の正体をユーザーエージェントで申告していた時期は、容易にブロックできました。
  • IPアドレスによるブロック: ユーザーエージェントを偽装し始めたスクレイパーに対しては、アクセスパターンからスクレイパーを特定し、IPアドレスをブロックしました。例えば、8年前の放棄されたLinuxフォークの全コミットを取得しようとするIPは、正規のユーザーではないと判断できます。
  • サブネット/ASNによるブロック: スクレイパーがIPアドレスを分散させると、サブネットやASN（自律システム番号）単位でのブロックに移行しました。これにより、Google Computeなどのクラウドサービスからアクセスしているスクレイパーを特定し、ブロックすることが可能になりました。

しかし、事態はさらに悪化します。現在では、数百万ものランダムな家庭用IPアドレスやモバイルIPアドレスからアクセスがあり、これらがすべて「ランダムな最新のブラウザ」を装っているというのです（出典）。

これは、一般的なユーザーのデバイスがマルウェアによってボットネットの一部として利用されている可能性を示唆しており、スクレイパー対策を極めて困難にしています。まさに「サイボーグゴキブリ」のように、どこからともなく湧いて出てくるような状況と言えるでしょう。

AI時代のオープンソースとインフラの未来

今回のgit.kernel.orgの事例は、AIの発展がオープンソースプロジェクトのインフラ運用に新たな、そして深刻な課題を突きつけていることを明確に示しています。良質なデータを提供したいというオープンソースの精神と、そのデータが過剰な負荷を生み出す現状との間で、運営側は非常に難しい舵取りを迫られていると感じます。

今後、オープンソースプロジェクトは、AIによるデータ利用に対して何らかの新しいポリシーや技術的な枠組みを設ける必要が出てくるかもしれません。例えば、特定のAPI経由でのデータ提供や、AI利用目的のアクセスに対する新たな認証・課金モデルなどが考えられます。そうでなければ、潤沢なリソースを持つ大規模なテック企業以外は、AIスクレイピングのコストに耐えられなくなるのではないでしょうか。

余談ですが、医療品輸送に使われるサイボーグゴキブリの研究も進んでいるようです。オーストラリアのクイーンズランド大学の研究者たちは、瓦礫の中に閉じ込められた被災者に薬物を注入できるデバイスを装着したサイボーグゴキブリを開発しています。

人間が到達できない場所での活用が期待されており、倫理的な議論は残るものの、テクノロジーの応用範囲の広がりを感じさせます（出典）。AIスクレイパーを「サイボーグゴキブリ」と表現した元記事は、ある意味的を射ているのかもしれません。