14コアがクローラのためだけに回る — 開かれたインフラの請求書は誰に届くのか
14コアがクローラのためだけに回る — 開かれたインフラの請求書は誰に届くのか
AI学習用クローラが公共のオープンソース基盤に押しつけるコストは誰が負担すべきか。そしてなぜクローラは、同じデータを取るのに常にいちばん高くつく経路を選ぶのか。
導入
2026年8月29日、kernel.org のインフラを運用する Konstantin Ryabitsev が、個人ブログに「Creepy crawlies」という記事を公開した。同種の告発文と決定的に違うのは冒頭の一文である。彼は「AIクローラについての私の愚痴は聞いたことがあるだろう」と切り出したうえで、今回は影響を示す「実際の数字」が手元にあると書く。感情ではなく計測結果を出す、という宣言である。
TL;DR にあたる二文が記事全体の重みを担っている。第一に、kernel.org はスクレイパのためにコミットを HTML へレンダリングする処理に、git clone を含む正当なアクセス全部を合計したよりも多くの CPU サイクルを費やしている。第二に、地理的に分散した5ノードにおいて、常時 14 個の CPU コアが git コミットを HTML として描画するだけの作業に占有されている。彼はこの状態を、システム負荷の恒常的な「バックグラウンド放射」と呼ぶ。負荷スパイクではなく、容量の一部が恒久的に削り取られた状態だという意味である。
この記事が Hacker News で 1384 ポイント、708 コメントを集めた理由もそこにある。クローラをめぐる議論の大半は著作権と倫理の語彙で進んできた。Ryabitsev の報告はそれを会計の語彙に置き換える。誰かが学習データを得ているあいだ、そのデータを無償で公開すると既に決めている組織が、自分の容量の五分の一を支払っている。問題はデータを渡すか否かではなく、渡し方のコストを誰が請求されるかである。
600万リクエストと14コア — kernel.org が実測したもの
数字から整理する。git.kernel.org は一日およそ 600 万件のリクエストを受け、その中身は任意のコミットを見せろという要求である。うち 66 パーセントは Anubis のチャレンジで即座に弾かれる。残る 33 パーセントは計算を実際に解いて本体サイトまで到達する。Ryabitsev はどちらがボットでどちらが人間かを確実には判別できないと断りつつ、「古いフォークの古いコミットを要求しているなら、それは仕事中の開発者ではない可能性が高い」と書く。彼が「かなり気前のよい仮定」を重ねて推定した正当なリクエストの割合は、全トラフィックの約 2 パーセントである。
この 2 パーセントを資源に換算するとこうなる。5ノードにまたがる合計 90 コアのうち、14 から 16 コアが常時スクレイパ向けのコミット描画だけを行っている。平均で 20 パーセント。ただし彼は、この平均値が実態のグラフを歪めると付け加える。クローラの群れは波として押し寄せるため、実際の曲線は 20 パーセントの水平線よりはるかに尖っている。
見過ごせない逆説がひとつある。kernel.org を実際に落とすのはスクレイパではない。彼はサイトが今なお軽快に応答するはずだと述べたうえで、サービスを本当に殺す犯人として設計の悪い CI システムを名指しする。20 ノードから同時に stable.git を浅いクローン(shallow clone)する類の行為である。「浅いクローンはひどい。そんなことをするなら自前のミラーを回せ」と彼は言い切る。スクレイパはシステムを落とさない。代わりに容量の五分の一を恒久的に占有する。この区別が重要である。障害ではなく常時課税であるがゆえに、アラートは鳴らず、対応の優先順位も後回しにされる。
なぜ kernel.org なのか。彼の説明はデータの品質に関わる。Linux の開発は公開の場で行われ、リポジトリは clone でき、議論アーカイブはリアルタイムで追える。大規模言語モデルにとってこれは学習データの金鉱だが、即座に利用できること以上に重要な性質がある。純度の高い「AI以前」のコンテンツであることを保証できる点だ。彼は LLM が生成した内容で LLM を訓練することを「デジタル・プリオン病」に喩え、コミット履歴全体のように LLM 汚染がないと保証されるソースは金の重さに値すると書く。
そして問題の核心である URL 空間が出てくる。執筆時点で linux.git は約 148 万コミットを持つ。git.kernel.org 上にはそのフォークが約 922 個ある。バックエンドではこれは極めて効率的である。オブジェクトの大半がすべてのフォークで共有されるからだ。しかしスクレイパにとってこれは数十億の有効な URL であり、その全部を舐めても手に入るのは同じ 148 万コミットの 922 部の複製にすぎない。ここに cgit が提供する付加機能 — パッチ、プレーン表示、任意の二コミット間の diff — が組み合わせ的に掛かる。彼はフォークひとつだけで「1.2 メトリック・バジリオン」個の有効 URL を生成できると誇張表現を使う。正確な数が問題なのではない。有限のリポジトリから事実上無限の URL 表面が派生するという性質が問題なのである。
防御の歴史もそのまま記録されている。最初は簡単だった。ボットが User-Agent で正体を親切に名乗ってくれたので、ログを見て fail2ban すれば済んだ。ボットが賢くなり普通のブラウザを詐称し始めると、IP 単位のブロックへ移った。8年前に放棄された Linux フォークの全コミットを巡回する IP が、Windows でリンクを狂ったようにクリックしている個人であるはずがない。ボットがサブネット全体へ散ると、ASN 単位のブロックへ上がった。Google Compute から来る IP が Firefox ユーザを自称するなら遮断は正当だという論理で、コミット内のリンク検査を自動化していた正当なインスタンスがたまに巻き添えになるのは受け入れた。
本当の悪化はその次だった。クローラが数百万の住宅用・モバイル IP から来るようになり、いずれも最新ブラウザを詐称した。そうした IP はリクエストを4〜5件投げて二度とログに現れない。ボットだと判別した時点で相手は用事を終えているので遮断する意味がなく、戻ってこない IP でファイアウォールのルールセットを膨らませる無駄だけが残る。彼はこの群れをイナゴに喩える。システムが倒れるまで速く強く叩き、次の標的へ移り、復旧すると戻ってくる。そしてこの供給網の名前を名指しする。「プロキシ SDK マネタイズ」である。大きなビジネスであり、「あなたのテレビもおそらくそれをやっている」。
HN の議論では、自分のブログ統計で同じ現象を観測したという報告も出た。以前は数か国から少数のアクセスがあるだけだったのが、ここ数か月は非常に小さな国々や、古く珍しいブラウザ・OS からの閲覧が計上され始めたという。彼はスクレイパが各国の VPN サービスにヘッダ匿名化ツールを重ね、端末の正体を隠しているのだろうと推測する (@initramfs)。送信元の分散は、もはや大手事業者だけの手口ではない。
最後の防衛線が Anubis だった。自分の IP とサーバが渡す秘密値を組み合わせ、SHA256 の先頭にゼロが4つ並ぶ文字列を探させる、捨てるための計算を強制する関門である。効果は即座に現れた。ボットはあっさり諦め、数か月の平穏が訪れた。数か月後にボットが難易度4を解き始めたので、難易度を5へ上げた。正当な利用者の負担が実測可能な大きさになったのはここからである。難易度5はモバイル端末で数秒かかり、そのあいだ端末は不快なほど熱くなる。それでさらに数か月を稼いだ。そしてボットは難易度5も解き始めた。現在の 33 パーセントはその結果である。
なぜ最も高くつく経路がクローラにとっては合理的なのか
Ryabitsev の問いは単純である。「人工知能」を名乗る何かなら、我々のデータを学習に使う最も効率的な方法を選ぶはずではないのか。リポジトリを clone し、全コミットを歩けば終わりである。kernel.org はほぼすべてを clone 可能にしてある。リポジトリもアーカイブもそうだ。LKML 全体を clone して好きに使えることを知っているか、と彼は問い返す。全部 git リポジトリなのである。ところがクローラは「考えうる最も愚かな方法」、すなわち全部をコミット単位の HTML として描画させ、それをパースする側を選ぶ。
これに対する最も説得力のある反論が HN から出た。この種のリポジトリがクロール対象の 10 パーセント以上を占めるなら clone 可能なリポジトリ用の特別経路を入れるのは賢い判断だが、ウェブ全体を舐めている立場なら、よりパースしやすい代替がある特殊ケースごとに効率化を仕込むことはしない、という指摘である (@lkbm)。同じ利用者は「なぜ単に git clone しないのか」という問いにもっと短く答えている。10 億のウェブページを舐めていて、そのうち git clone 可能なものはごく一部にすぎず、その一部のために特別処理を設定するのはクローラ側が払う価値のある手間ではない、と。
この説明が重要なのは、クローラを悪意で説明しないからである。悪意なら説得や規範で矯正する余地がある。だがこれは合理的な無関心である。効率的な経路はクローラのエンジニアリング時間を消費し、非効率な経路は他人の CPU を消費する。二つのコストが別々の帳簿に記録されるため、クローラの最適化計算に kernel.org の 14 コアはそもそも登場しない。これが外部性(externality)の教科書的な定義である。生産者が自分の決定の限界費用を負わないなら、節約する誘因も生まれない。HN のある利用者の問いはこの構造を正確に射抜いている。全員が自分の取り分を払っていたら、つまり実際に働いている人々に押しつけていなかったら、AI のアクセスコストはいくらだったのか (@Artoooooor)。
ここでもうひとつ興味深い非対称が見える。922 のフォークはバックエンドではほぼ無料である。オブジェクトが共有されるからだ。しかしスクレイパにとって各フォークは完全に新しい URL 名前空間である。保存効率はクロール効率に翻訳されない。サーバ側の最適化が優秀であるほど露出する URL 表面はむしろ広がり、その表面を描くコストはリクエストのたびに発生する。
キャッシュで解決するのではないか、という反応も多かった。git の性質上その HTML はほぼ不変なのだからキャッシュはよく効くはずで、cgit が毎回生成するよりはるかに安いだろう、というものである (@chuckadams)。リバースプロキシキャッシュを前段に置けば劇的に減るという意見も付いた (@Zariel)。これに対する反駁が問題の性質をよく要約している。cgit は旧来のサーバサイドレンダラであり、描画しうるページが組み合わせ的に爆発するため、現実的に保存できる量よりはるかに多いページが存在する、という指摘だ (@rcxdude)。キャッシュはリクエスト分布が狭い人気集合に集中するときに機能する。ここではリクエストが事実上無限の空間へ一様に広がる。ヒット率がゼロに収束するキャッシュはコストを移さず、層をひとつ増やすだけである。別の利用者が指摘したように、cgit は自らを「git リポジトリのための超高速ウェブフロントエンド」と名乗っている。ボットにとってはどんな速度も十分に速くはない (@kees99)。
では Anubis のようなプルーフ・オブ・ワーク関門には、なぜ賞味期限があったのか。この議論で最も鋭い分析は、プルーフ・オブ・ワークが成立する条件そのものを問題にする。スパム対策で PoW が働くのは報酬の非対称ゆえである。正当な利用者は一度のリクエストで報酬 V を得るが、濫用者は数百万回のリクエストで同じ定数の報酬 V を狙う。だからコストは濫用者側に数百万倍で偏る。スクレイパはそうではない。スクレイパのあらゆるリクエストはそれぞれ自分の分の報酬を生む。非対称はまったく存在せず、両者に固定費がひとつ加わるだけである。しかもデータセンター規模のスクレイピング事業者は、個人利用者よりも PoW 計算を負担する準備がはるかに整っている (@tptacek)。この予測は1年前に既に提起されており、kernel.org の 33 パーセントという数字がそれを実証した。正直な利用者が支払ったのは熱くなった端末と数秒の待ち時間であり、ボットが支払ったのは事業コストの端数である。
難易度を動的にする案も出た。一日 1000 ページ以上を要求する IP は難易度を 1 ずつ上げればよいのではないか、というものである (@nicman23)。方向は正しいが、この案がぶつかる壁こそ kernel.org が既に観測した適応である。難易度を IP でキーイングした瞬間、リクエストを4〜5件だけ投げて消える数百万の住宅用 IP の前で、その鍵は無意味になる。攻撃側は IP という識別子を無限に供給されているからだ。問題は難易度調整のアルゴリズムではなく、調整の基準となる持続的な同一性(identity)という原資が存在しないことにある。
そしてここで根本的な緊張が露わになる。公開インフラは匿名・無登録のアクセスを前提に設計された。ところがクローラへの有効な対策はすべて、その前提を少しずつ削る方向にしか存在しない。身元を要求するか、関門を立てるか、機能を減らすかである。HN のある利用者はこの流れを問いの形で要約した。これは匿名ブラウジングの終わりであり、すべてのリクエストに身元を紐づける時代の始まりなのか、それともコミュニティがホストする無料の情報サービスそのものの終わりなのか (@a-dub)。別の利用者はもっと淡々とまとめている。トラフィックの 99 パーセントが偽物のまま運用を続けるのは現実的ではないので、多くのシステムがログインや信頼 IP ベースへ移るのは避けがたく見える、と (@acedTrex)。
運用者が今つかめるカードと、それぞれの請求書
kernel.org 自身の答えから見るのが順序である。Ryabitsev は、クロール可能な URL の数を減らし、実行コストの高い操作に関門を設けるために機能を無効化していると明かす。匿名アクセス時に一部の機能が失われることを覚悟してほしい、自分たちも同じくらい嫌だが今や必要なのだ、と付け加える。同時に彼はひとつの約束を維持する。求める者には誰にでも全データをダウンロードで提供する、というものだ。ただし通す手続きは増えるかもしれない。
この組み合わせが示す原則は明快である。クローラを識別しようとするな、組み合わせ的に爆発する表面そのものを削れ。自社サイトや社内 git ホスティングを運用する立場で実際に取れるカードは以下であり、それぞれに請求書が付く。
第一に、URL 表面の縮小である。任意の二コミット間 diff のように組み合わせ的に無限なエンドポイントを匿名アクセスから外し、GET リンクで実装したソートや検索のパラメータに手を入れる。HN では、あるゲームサイトの運営者がまさにこの落とし穴を報告している。同時接続カウンタが 100〜200 人から数千人へ膨らんだ原因がすべてクローラのセッションで、実際の利用者はごく少数であり、ソートと検索を GET リンクで作ったことが事態を悪化させたという (@Demiurge)。副作用は明白だ。ディープリンクが壊れ、そのエンドポイントに依存していた正当なツールも巻き添えで死ぬ。
第二に、一括転送の経路を一級市民に格上げすることである。clone URL、tarball、ダンプを目立つ場所に公開し文書化する。コストは帯域であり、効果は行儀のよいクローラに安い道を用意することだ。ただし先の構造的説明はここにも当てはまる。この経路は、特殊ケースの最適化を入れる誘因のある相手にしか効かない。
第三に、キャッシュである。導入する前にリクエスト分布を測れ。ヒット率を測らずにリバースプロキシを前段に置くと、cgit 型の表面ではヒット率ほぼゼロのキャッシュ層をひとつ余計に運用することになる。
第四に、PoW 関門である。有効ではある。ただし賞味期限が年単位ではなく月単位だと理解したうえで配備すべきだ。そしてその期間、税を払うのはモバイル利用者である。ある利用者は複数のサイトで上がった Anubis の難易度がひどく煩わしいと不満を述べつつ、それでいてもう LLM ボットを止められていないのではないかと問い返した (@yellow_lead)。
第五に、CDN のボット管理機能である。問題を仲介者へ移し、新たな依存を作る。市場の三つの立場をすべて経験したという利用者の報告は慎重に読む価値がある。住宅用プロキシを使えば、ごく単純なリクエストでもブロックされるのは 15 パーセント程度で、それはプライバシー系ブラウザで正規に接続したときに受けるブロックより低いという。彼の結論は冷ややかだ。「Cloudflare はボットを止めない。人間を止める」 (@inigyou)。有料クロールを推す事業者がその取引から手数料を取るという指摘も併せて出ている (@timpera)。
第六に、毒とタールピットである。安価で即効性があるが、誤検知に引っかかった正当な利用者にも同じゴミを食わせることになり、単独では勝てない軍拡へ自分を押し込む。
第七に、認証である。最も効果的であり、公開インフラの存在理由に対して最も高くつく。
今後のシナリオは三つに分かれる。楽観は Ryabitsev 自身が開いた二つだ。AI バブルが弾けて学習データを欲しがる主体が減るか、クローラが賢くなって最も愚かな方法でのデータ消費をやめるか。彼はどちらも断定せず「不確実だ」とだけ書く。悲観は彼が最終段落で挙げた供給構造である。カスタム AI モデルを売る会社は毎日新しく生まれ、いずれも学習データに飢えている。アプリ制作者は利益の出し方を探し続け、家庭用の機器を攻撃ベクタへ変え続けるだろう。現実的なシナリオはその中間だ。表面が縮み、関門が広がり、仲介者を通した有料クロール層が定着する。ある利用者が整理したように、クライアントが資源を費やすだけでは足りず、サーバがリクエストを処理した対価に何かを受け取らねばならないのなら、残る道はクロール課金である (@Self-Perfection)。開かれたインフラは動き続ける。ただし扉の数を減らしたままで。
実務者に残る最も安い教訓は順序に関するものだ。緩和策を選ぶ前に、まず測れ。kernel.org の 2 パーセントという数字は、彼らが測ったから存在する。ほとんどの運用者は自分のサイトのその比率を知らないまま防御策を選んでいる。
結論
冒頭の問いに戻る。今コストを負担しているのはインフラを運用する側である。それは節約ではなく移転(transfer)だ。クローラが節約したエンジニアリング時間の分が kernel.org の 14 コアとして現れただけで、社会全体の計算量はむしろ増えている。同じ 148 万のコミットを 922 回重複して、しかも HTML レンダリングを経由して取っていくより浪費的なデータ移動の設計を考えるほうが難しい。
クローラが最も高くつく経路を選ぶ理由も、これで明らかである。愚かだからではなく、その経路のコストが自分の帳簿に載らないからだ。効率的な経路が自分のエンジニアリング時間を使い、非効率な経路が他人の CPU を使うのなら、ウェブ全体を舐める規模では後者を選ぶのが個別には合理的である。個別合理性の総和が共有資源を食い潰す、見慣れた形である。
だから実際に消耗しているのは 14 コアではない。公共の資源を関門なしに差し出せる、というその前提そのものである。kernel.org は今でも、求める者には誰にでも全データを渡すと約束している。ただしその手前に手続きが一つずつ増えていく。手続きが一つずつ増える過程は個別にはすべて合理的な判断であり、その総和は、我々が知っていた形の公開ウェブが少しずつ閉じていくことである。
残る問いはこれである。匿名アクセスを守りながらコストを内部化する方法は存在するのか。それとも我々は既に、何を諦めるかだけを選ぶ局面に入っているのか。
出典: