毎日約600万回のリクエストが、Linuxカーネルの公式ソースコードリポジトリ（git.kernel.org）に猛烈な勢いで押し寄せている。最も楽観的な統計モデルにおいてさえ、これらのアクセスのうち真の正当な人間のリクエストはわずか2%を占めるに過ぎない。残りの98%は、コードの1行1行を飲み込んで大規模言語モデルの学習に利用しようとするAIクローラーである。
疲れを知らぬ計算量（コンピューティングパワー）の捕食者
5つの地理的に分散されたノード、90個のCPUコアで構成されるこの公式サイトのクラスターは、名状しがたい非対称な負荷に耐えている。そのうち14から16個のコアは常にフル稼働状態であり、それらの唯一のタスクはクローラーのためにコードのコミット（commit）ページをレンダリングすることである。これはシステム全体の計算容量の20%を直接食い潰しており、しかもクローラーは常に波状攻撃を仕掛けてくるため、実際の瞬間的なピークはさらに鋭いものとなる。
クローラーの強欲さは、通常のエンジニアリングの常識を超えている。Linuxカーネルには約148万回のコードコミット記録があり、公式サイトには約922のフォーク（fork）バージョンが存在するため、数十億もの有効なアクセス可能リンクが交錯している。AIクローラーはそれぞれのリンクを機械的に巡回し、全く同じ922件の重複コンテンツをそれぞれスクレイピングする。これは、今日のトレーニングデータの取得が、重複排除などのエンジニアリング的な最適化を捨て去り、最も粗暴な総当たり手法によってターゲットサーバーの計算力を圧倒する力技へと変貌したことを示している。
紙切れ同然の計算量防衛線
この際限のない暴力的なスクレイピングを阻止するため、Linuxカーネルの公式サイトはAnubisと呼ばれるスクレイピング対策システムをデプロイした。これはプルーフ・オブ・ワーク（PoW）に基づく暗号学的な数学の問題である：訪問者のデバイスに対し、与えられた文字列を自身のIPアドレスおよびサーバー側の動的キーと組み合わせ、そのSHA-256ハッシュ値の先頭N桁がすべてゼロになるまで計算し続けるよう要求する。
現在、Anubisは66%の低レベルなスキャンプログラムのブロックに成功しているが、依然として33%の高度なボットがこの数学の問題を解き明かし、メインサイトへスムーズに侵入している。
図：git.kernel.orgのリクエストファネル：66%がブロックされ、33%が通過し、正当なアクセスはわずか2%。出典：people.kernel.org
徐々に迫り来る33%の高度なクローラーに直面し、防御側の唯一の手段は、ハッシュ計算の難易度をレベル4からレベル5に引き上げることだった。しかし、この防衛線のコアメカニズムには致命的な弱点が存在する——それは、ブラウザ内のJavaScriptスクリプトを使用してマシンの計算量を消費することを要求している点である。高度なインタープリタ言語を使用して集中的なハッシュ計算を実行すること自体、非常に非効率的であり、防御側にとって極めて非対称な対抗手段である。
ハードウェア命令による「次元の違う攻撃」
この数学の問題は、真のAIクローラーにとって一体どれほどの障害となるのか？Hacker Newsの技術ディスカッションエリアで、semiquaverという名の開発者が破壊的な技術的実証を提示した。
彼はわずか10分でカスタマイズ版のSafariブラウザ拡張機能を記述した。ARMアーキテクチャ特有の SHA256H* ネイティブハードウェアアクセラレーション命令を呼び出し、コアとなる問題解決ロジックをC言語で書き直すことで、難易度6の数学の問題を解く速度を、iPhoneが本来必要とする180秒からミリ秒レベルへと直接圧縮したのである。これは、専用のハードウェア命令セットの前では、純粋なソフトウェアレベルの防御メカニズムがいかに無力であるかを示している。攻撃者が非効率的なブラウザのサンドボックスを回避し、基盤となるハードウェアの計算力を直接呼び出すことができる場合、防御側が綿密に設計した遅延メカニズムは瞬時に消え去る。
図：Anubisの段階的な難易度上昇とボットの追従による苦痛の曲線。出典：people.kernel.org
軍拡競争のシステム的な制御不能
同時に、攻撃側の戦術にも質的な変化が起きている。当初の正直に自分の正体を申告するリクエストヘッダ（UA）から、一般的な消費者向けブラウザに完全に偽装するものへと進化した。現在ではさらに、数百万の家庭用ブロードバンドやモバイルネットワークのIPを乗っ取ってローテーションさせる高度な戦術へと発展している。様々な隠蔽されたプロキシSDKの収益化ツールを通じて、多くの一般ユーザーのスマートテレビでさえ、知らず知らずのうちに他人のデータスクレイピングを支援するボットネットのノードになっているのである。
一部の開発者はディスカッションの中で、極端な難易度のチャレンジを使用しない限り、通常のデバイスのJavaScriptエンジンでも8秒あれば問題を解くことができると反論した。彼らは、180秒からミリ秒への巨大な隔たりは、単にJavaScriptエンジンとネイティブC言語の間の3桁の実行効率の違いによって引き起こされたものだと考えている。
しかし、これこそが防御側のジレンマである。クローラーはネイティブ言語、サーバークラスター、さらには基盤となるハードウェアを無遠慮に動員できるのに対し、真のユーザーはブラウザの遅々とした実行環境に閉じ込められている。長期的な優位性が自陣にあると、防御側はどうして仮定できるだろうか？
マシンに計算コストを払わせるスクレイピング対策の設計は、専用ハードウェアとネイティブコードの前では完全に無効化されてしまった。マシンが計算タスクを実行する速度は、常に人間が使用する一般的な端末よりも何桁も速い。LinuxカーネルのメンテナーであるKonstantin Ryabitsevは、現在簡単な技術的解決策はないと最終的に認め、一部の検索機能を無効にすることでスクレイピング可能なリンクを減らすしかないと諦観した。Anubisスクレイピング対策の敗北が意味するのは、AIクローラーとウェブサイト防御の計算力軍拡競争において、防御側がシステム的な崩壊に直面しているということである。「計算量の壁」がハードウェアによる「次元の違う攻撃」によって突破されたとき、複雑なCAPTCHAが唯一ブロックできるのは、静かにコードを読もうとしている生身の人間だけになってしまう。筆者は、このエスカレートし続ける軍拡競争に直面して、いかなる防御戦略も次の瞬間の計算力の突破によって崩壊する可能性があると考えており、今後の動向についての判断には依然として謙虚さを保つ必要があると考える。
参考リンク：
- people.kernel.org 原文記事
- HNコミュニティの技術ディスカッション
