ソフトウェア開発者の Xe Iaso 氏は、今年初めに Amazon からの攻撃的な AI クローラー トラフィックが Git リポジトリ サービスを圧倒し、不安定性とダウンタイムを繰り返し引き起こしたため、限界点に達しました。robots.txt の調整、既知のクローラー ユーザー エージェントのブロック、疑わしいトラフィックのフィルタリングなど、標準的な防御策を講じたにもかかわらず、Iaso 氏は AI クローラーがユーザー エージェントを偽装し、プロキシとして住宅 IP アドレスを循環して、クローラーを阻止しようとするすべての試みを回避し続けていることに気付きました。
解決策を必死に探していた Iaso 氏は、最終的にサーバーを VPN の背後に移動し、「Anubis」を作成することに頼りました。これは、Web ブラウザーがサイトにアクセスする前に計算パズルを解くように強制する、カスタム ビルドの作業証明チャレンジ システムです。 「AIクローラーボットは嘘をつき、ユーザーエージェントを変更し、住宅のIPアドレスをプロキシとして使用するなど、さまざまなことをするため、ブロックしても無駄だ」と、Iaso氏は「必死の助けを求める叫び」と題したブログ投稿に記している。「Giteaサーバーを一般公開しないようにしたくはないが、必要ならそうする」
Iaso氏の話は、オープンソースコミュニティ全体に急速に広がっているより広範な危機を浮き彫りにしている。攻撃的なAIクローラーらしきものが、コミュニティが管理するインフラストラクチャにますます過負荷をかけ、重要な公共リソースに対する持続的な分散型サービス拒否（DDoS）攻撃を引き起こしているのだ。 LibreNews の 最近の包括的なレポート によると、一部のオープンソース プロジェクトでは、トラフィックの 97% が AI 企業のボットから発生しており、帯域幅コストが大幅に増加し、サービスが不安定になり、すでに手薄になっているメンテナーに負担がかかっています。
Fedora Pagure プロジェクトのシステム管理チームのメンバーである Kevin Fenzi 氏は、ブログ で、ボット トラフィックを軽減する試みが何度も失敗したため 、プロジェクトはブラジルからのすべてのトラフィックをブロックしなければならなかったと報告しています。GNOME GitLab は Iaso の「Anubis」システムを実装しており、ブラウザーはコンテンツにアクセスする前に計算パズルを解く必要があります。 GNOME システム管理者 Bart Piotrowski 氏は Mastodon で shared 、リクエストの約 3.2% (84,056 件中 2,690 件) しかチャレンジ システムを通過しなかったと報告しており、トラフィックの大部分が自動化されていることを示しています。LibreNews は KDE 開発チャットを引用して、KDE の GitLab インフラストラクチャが Alibaba IP 範囲から発信されたクローラー トラフィックによって一時的にオフラインになったと伝えています。
Anubis はボット トラフィックのフィルタリングに効果的であることが証明されていますが、正当なユーザーにとっては欠点もあります。GitLab リンクがチャット ルームで共有されている場合など、多くの人が同時に同じリンクにアクセスすると、サイト訪問者は大幅な遅延に直面する可能性があります。このニュース アウトレットによると、一部のモバイル ユーザーは、プルーフ オブ ワーク チャレンジが完了するまで最大 2 分待たされたと報告しています。
この状況はまったく新しいものではありません。 12月、Diasporaソーシャルネットワークのインフラを管理するDennis Schubert氏は、AI企業が自社のサービスへのウェブリクエストの70%を占めていることを発見した後、この状況を「文字通りインターネット全体へのDDoS」と表現した。
コストは技術的および金銭的である。Read the Docsプロジェクトは、AIクローラーをブロックするとトラフィックが即座に75%減少し、1日あたり800GBから200GBになったと報告している。ブログ記事「AIクローラーはもっと敬意を払う必要がある」によると、この変更により、プロジェクトは帯域幅コストを1か月あたり約1,500ドル節約できたという。
オープンソースへの不均衡な負担
この状況は、公共の協力に依存し、商業組織と比較して限られたリソースで運営されることが多いオープンソースプロジェクトにとって厳しい課題となっている。多くのメンテナーは、AI クローラーが意図的に標準的なブロック対策を回避し、robots.txt 指令を無視し、ユーザー エージェントを偽装し、検出を回避するために IP アドレスをローテーションしていると報告しています。
LibreNews が報じたように、Inkscape プロジェクトの Martin Owens は Mastodon で、問題は「昨年の通常の中国からの DDoS だけでなく、スパイダー コンフィグを無視し、ブラウザー情報を偽装し始めた多数の企業によるもの」であると 指摘 しました。Owens は、「私は今、膨大なブロック リストを持っています。AI を扱う大企業で働いている場合は、当社の Web サイトにアクセスできなくなる可能性があります」と付け加えました。
Hacker News では、先週の LibreNews に関する スレッドや 1 月の Iaso の戦いに関する スレッドのコメント投稿者が、AI 企業がオープンソース インフラストラクチャに対して略奪的な行動を取っていると見なし、深い不満を表明しました。これらのコ メントは公式声明ではなくフォーラム投稿からのものですが、開発者の間で共通の感情を表しています。
Hacker News の 1 人のユーザーが 述べた ように、AI 企業は「1,000 億ドルの資本」を保有しており、「善意は関係ない」という立場で事業を行っています。この議論は、影響を受けたプロジェクトと共同で作業してきた小規模な AI スタートアップと、オープンソース プロジェクトのメンテナーに数千ドルの帯域幅コストを強いているにもかかわらず対応していない大企業との間の争いを描いています。
帯域幅を消費するだけでなく、クローラーは git の Blame ページやログ ページなどの高価なエンドポイントを攻撃することが多く、すでに限られているリソースにさらなる負担をかけています。SourceHut の創設者である Drew DeVault 氏は、ブログ で、クローラーは「すべての git ログのすべてのページ、およびリポジトリ内のすべてのコミット」にアクセスするため、コード リポジトリにとって攻撃が特に負担になると報告しています。
問題はインフラストラクチャの負担だけにとどまりません。 LibreNews が指摘しているように、オープンソース プロジェクトの中には、2023 年 12 月という早い時期に AI 生成のバグ レポートを受け取り始めたものもあり、最初に 報告 したのは Curl プロジェクトの Daniel Stenberg 氏で、2024 年 1 月のブログ投稿でした。これらのレポートは一見正当なもののように見えますが、捏造された脆弱性が含まれており、開発者の貴重な時間を無駄にしています。
責任者は誰で、なぜこのようなことをしているのでしょうか?
AI 企業には、許可なく取得してきた歴史があります。2022 年に AI 画像ジェネレーターが主流になり、ChatGPT がその慣行に注目を集める前は、機械学習分野では所有権をほとんど考慮せずにデータセットを定期的にコンパイルしていました。
多くの AI 企業が Web クローリングを行っていますが、情報源によると、責任と影響のレベルはさまざまです。 Dennis Schubert による Diaspora のトラフィック ログの 分析 によると、Web トラフィックの約 4 分の 1 は OpenAI ユーザー エージェントのボットから来ており、Amazon は 15%、Anthropic は 4.3% を占めています。
クローラーの動作は、さまざまな動機を示唆しています。大規模な言語モデルを構築または改良するためにトレーニング データを収集しているクローラーもあれば、ユーザーが AI アシスタントに情報を尋ねたときにリアルタイム検索を実行しているクローラーもあります。
これらのクロール頻度は特に意味深いものです。Schubert は、AI クローラーは「ページを 1 回クロールして次に進むだけではありません。ああ、いや、6 時間ごとに戻ってきます。なぜなら、なぜそうしないのか」と観察しました。このパターンは、1 回限りのトレーニング演習ではなく、継続的なデータ収集を示唆しており、企業がモデルの知識を最新の状態に維持するためにこれらのクロールを使用している可能性を示しています。
一部の企業は他の企業よりも積極的に見えます。 KDE のシステム管理チームは、Alibaba の IP 範囲からのクローラーが GitLab を一時的にオフラインにした原因であると報告しました。一方、Iaso の問題は Amazon のクローラーから発生しました。KDE のシステム管理チームのメンバーは LibreNews に対し、OpenAI や Anthropic などの西洋の LLM オペレーターは少なくとも適切なユーザー エージェント文字列を設定している (これにより、理論的には Web サイトが それらをブロック できる) 一方で、一部の中国の AI 企業はより欺瞞的なアプローチを取っていると報告しています。
これらの企業がより協調的なアプローチを採用せず、少なくともデータ収集の実行をレート制限してソース Web サイトに負担をかけないようにしない理由は依然として不明です。Amazon、OpenAI、Anthropic、Meta はコメントの要請にすぐには応じませんでしたが、返答があった場合はこの記事を更新します。
タールピットと迷路: 増大する抵抗
これらの攻撃に対応して、望ましくない AI クローラーから Web サイトを保護するための新しい防御ツールが登場しました。Ars が 1 月に報告した ように、匿名の作成者「Aaron」が、偽コンテンツの無限の迷路にクローラーを閉じ込める「Nepenthes」というツールを設計しました。Aaron は、これを AI 企業のリソースを浪費し、トレーニング データを汚染する可能性のある「攻撃的なマルウェア」であると明確に説明しています。
「これらのクローラーのいずれかが私のタールピットからデータを取得するたびに、消費されたリソースであり、現金で支払わなければなりません」と Aaron は Ars に説明しました。 「実質的にコストが上昇する。そして、まだ利益を上げているところが一つもないのを見ると、彼らにとって大きな問題だ」
金曜日、Cloudflareは「AI Labyrinth」を発表した。これは類似しているが、より商業的に洗練されたアプローチだ。当時我々が報じたように、AI企業に対する攻撃的な武器として設計されたNepenthesとは異なり、Cloudflareは自社のツールを、ウェブサイト所有者を不正なスクレイピングから保護するための正当なセキュリティ機能として位置付けている。
「不正なクロールを検知した場合、リクエストをブロックするのではなく、クローラーがページをたどるのに十分な説得力のある一連のAI生成ページにリンクします」とCloudflareは発表の中で説明した。同社は、AI クローラーが毎日 500 億件を超えるリクエストを自社のネットワークに生成しており、処理するすべての Web トラフィックの約 1% を占めていると報告しています。
コミュニティでは、これらのクローラーから保護するための共同ツールも開発しています。「ai.robots.txt」プロジェクトでは、AI 企業に関連する Web クローラーのオープン リストが提供されており、Robots Exclusion Protocol を実装する既製の robots.txt ファイルと、AI クローラー リクエストを検出したときにエラー ページを返す .htaccess ファイルも提供されています。
現状では、オンライン スペースにおける AI 生成コンテンツの急速な増加 (圧倒的) と、AI 企業による積極的な Web クロール慣行の両方が、重要なオンライン リソースの持続可能性を脅かしています。一部の大手 AI 企業が現在採用しているアプローチは、明確な同意や補償なしにオープンソース プロジェクトから膨大な量のデータを抽出 することですが、これらの AI モデルが依存するデジタル エコシステムそのものに深刻なダメージを与えるリスクがあります。
AI 企業が影響を受けるコミュニティと直接協力すれば、責任あるデータ収集は実現できるかもしれません。しかし、業界の有力者は、より協力的な慣行を採用する動機をほとんど示していません。AI 企業による意味のある規制や自制がなければ、データに飢えたボットとオープンソース インフラストラクチャを守ろうとするボットの間の軍拡競争はさらにエスカレートし、現代のインターネットを支えるデジタル エコシステムの危機をさらに深める可能性があります。