AIクローラーのコスト: git.kernel.orgからの教訓

AIスクレイパーがgit.kernel.orgのCPU容量の20%を消費

AIクローラーは、git.kernel.orgにおいて、大規模言語モデル（LLM）のトレーニングにのみ使用されるデータを生成するために、膨大なコンピューティングリソースを恒常的に占有し、システム負荷の「背景放射」のような状態を作り出しています。現在、合計90コアを持つ5つの地理分散ノードにおいて、約14〜16コアがスクレイパーのためにgitコミットをHTMLとしてレンダリングすることだけに費やされています。これは、サイトの総容量の約20%に相当します。

HTMLスクレイピング vs. Gitクローンの非効率性

データ取得のための非常に効率的な方法が利用可能であるにもかかわらず、AIクローラーは最もリソースを消費するアプローチを選択しています。Linuxカーネルの全履歴とLKMLアーカイブはgit cloneを通じて利用可能であり、スクレイパーは一度履歴全体をダウンロードしてローカルで処理することができますが、ボットは代わりにすべてのコミットをHTMLとしてレンダリングし、その結果生成されたページを解析しています。

この非効率性は、利用可能なURLの組み合わせ爆発によってさらに悪化しています。linux.gitには約148万件のコミットと922のフォークがあり、コミット、パッチ、プレーンレンダリング、およびdiffの有効なURLの数は数十億に達します。スクレイパーは、放棄されたフォークに含まれるものを含め、これら数十億のURLを頻繁にターゲットにしますが、これは独自のデータを提供することなく、大規模なサーバー負荷を発生させます。

ボット対策戦略の進化

ボットが巧妙化するにつれて、これらのクローラーをブロックするための取り組みは、いくつかの段階を経て進化してきました。

User-AgentおよびIPブロック: ボットが標準的なウェブブラウザを装い始めたため、自己申告のUser-Agentや明らかなデータセンターのIP範囲（例: Google Compute Engine）に基づいてボットをブロックしようとする初期の試みは、すぐに回避されました。
レジデンシャルプロキシネットワーク: クローラーは、数百万のレジデンシャルIPおよびモバイルIPを使用するように移行しました。これらは多くの場合、「プロキシSDKマネタイズ」スキームを通じて、家電製品（Smart TVなど）がプロキシとして使用されるルートを経由します。これにより、各IPが消える前に数回のリクエストのみを行うため、IPベースの禁止は効果がなくなっています。
Proof-of-Work (PoW) チャレンジ: スクレイピングの経済的コストを逆転させるため、git.kernel.orgはAnubisを導入しました。これは、クライアントがコンテンツにアクセスする前に数学的課題（SHA-256）を解くことを要求するProof-of-Workシステムです。

Proof-of-Workによる恒久的な解決策としての失敗

Anubisは当初効果的でしたが、現在は軍拡競争の状態になっています。現在、システムはランダムなコミットに対する約600万件のデイリーリクエストを処理していますが、そのうち66%はチャレンジによってブロックされていますが、33%は数学的課題を解いてサイトに進んでいます。

コミュニティによる技術的な分析によれば、PoWは持続不可能な戦略です。なぜなら、計算コストが非対称であるためです。高性能なスクレイパーは、モバイルデバイス上の正当なユーザーよりもはるかに効率的にこれらの課題を解くことができます。例えば、iPhoneユーザーは高難易度の課題に数秒かかり、デバイスが熱くなるのを感じるかもしれませんが、ボットは最適化されたCカーネルや専用ハードウェアを使用して、同じ課題をミリ秒単位で解くことができます。

コミュニティの洞察と代替案の提案

開発者やサイト管理者の間の議論は、これがLinuxカーネルだけでなく、多くの公開リソースに影響を与えるシステム的な問題であることを明らかにしています。

観察されたパターン

ターゲット型 vs. 一般的なクローリング: 一部の意見では、ボットはgitホストを具体的にターゲットにしているのではなく、単に一般的なウェブクローリングにおいて利用可能なすべてのリンクを辿っているだけであり、それがgitウェブインターフェースの組み合わせ的な性質によって作成された「クローラー・トラップ」に陥っているのだと主張されています。
合成データのリスク: 著者は、LLMを含まないデータ（カーネルのコミットなど）に対して非常に高い価値があることに言及しています。これは、LLMが生成したコンテンツでLLMをトレーニングすることは、「デジタル・プリオン病」（モデル崩壊）を引き起こす可能性があるためです。

提案された技術的緩和策

クライアントサイド・レンダリング: HTMLレンダリングのロジックをユーザーのブラウザ上でJavaScriptを使用して実行させることで、サーバーをフラットファイルとdiffの単純なオブジェクトストアへと変更する。
ゲート付きアクセス: git cloneは制限なしのまま、HTMLビューに対しては認証を要求するか、あるいは認証されていないリクエストに対して強力なレート制限を適用する。
Tarpitting (ターピッティング): 検知されたボットットに対して、偽のデータや極端に遅いレスポンスを返すことで、リソースを浪費させる「ioicaine-style」のトラップを実装する。
マネタイズ: Proof-of-Workからマイクロペイメント（例: L402）へ移行し、使用されるサーバーリソースの実際のコストをカバーする。

現在の状況と今後の展望

git.kernel.orgは現在、負荷を軽減するために匿名ユーザー向けの機能を制限し、高コストな機能のオフラインにしています。管理側は、すべてのデータはダウンロード可能であるものの、ユーザーはアクセスするためにさらなる「ハードル」に直面する可能性があると強調しています。トレーニングデータの需要が成長し続け、レジデンシャルプロキシネットワークが拡大し続ける中で、長期的な解決策は依然として不明確です。