9 ポイント 投稿者 GN⁺ 2025-03-26 | 1件のコメント | WhatsAppで共有
  • AIクローラーがオープンソースプロジェクトのサイトに過剰なトラフィックを発生させ、実際にサービス停止に近いレベルの被害が発生
  • AIクローラーは robots.txt の無視、User-Agent の偽装、所在地IPの迂回などにより、既存の防御体制を回避
  • 開発者のXe Iasoはこれを防ぐため、サーバーをVPNの背後へ移し、ユーザーがパズルを解かなければアクセスできない「Anubis」という証明ベースのシステムを導入
  • LibreNewsによれば、あるプロジェクトでは全トラフィックの97%がAIクローラー由来
  • Fedora、GNOME、KDEなどの著名プロジェクトも、国単位の遮断、Anubisの適用、一時停止などで対応中

実際の被害事例とAIクローラーの無差別なアクセス

  • GNOMEのGitLabでは84,056件のうちAnubisを通過したのは3.2%のみ → 大半が異常なクローリングと推定
  • KDEではAlibabaのIPからのトラフィックにより、GitLabインフラが一時的に停止
  • 一部のモバイルユーザーでは、パズルの読み込みに2分以上かかることもある
  • Diasporaのインフラ維持を担当するDennis Schubertは、AIクローラーのトラフィックを「インターネット全体に対するDDoS」と表現
  • Read the DocsはAIクローラーを遮断後、1日あたり800GB → 200GBへトラフィックが減少し、毎月約$1,500の節約効果が発生

オープンソースプロジェクトに集中する不均衡な負担

  • オープンソースは限られたリソースで運営され、公開協業を基盤としている
  • 多くのクローラーが robots.txt を無視し、User-Agentを偽り、IPを次々に変えながらアクセスする
  • InkscapeのMartin Owensは、ブラウザー情報を偽装するAI企業のために大規模なブロックリストを維持中
  • Hacker Newsでは、AI企業の資本力と非協力的な態度に対する怒りが拡大
  • SourceHutのDrew DeVaultは、クローラーがあらゆるgitログページやコミットにまでアクセスし、リソースの過剰消費を招いていると指摘
  • Curlプロジェクトでは、AIが生成した虚偽のバグレポートを受け取った事例が報告されている

AIクローラーの目的と企業ごとの行動パターン

  • AIクローラーには、学習データ収集やAI回答のためのリアルタイム検索など、さまざまな目的がある
  • Diasporaの分析結果: OpenAI 25%、Amazon 15%、Anthropic 4.3%のトラフィックを占有
  • クローラーは定期的に同じページを繰り返しクロールする(例: 6時間間隔)
  • OpenAIやAnthropicなどは比較的正常なUser-Agentを使用する一方、一部の中国AI企業は偽装の度合いが高い
  • Amazon、Alibabaなども被害事例に登場しているが、当該企業はまだ公式見解を示していない

対応手段: Tarpit、パズル、協業案など

  • 「Nepenthes」というツールは、AIクローラーを終わりのない偽コンテンツの迷路に閉じ込める攻撃的な防御手段
  • 制作者のAaronは、このツールがクローラーのコストを増やし、訓練データの汚染を誘発すると主張
  • Cloudflareは商用セキュリティ機能として「AI Labyrinth」を発表し、クローラーを誘導して無意味なページ探索を行わせる
  • Cloudflareネットワークでは、1日に500億件以上のAIクローリングリクエストが発生
  • オープンソースプロジェクト「ai.robots.txt」は、AIクローラーのリストと遮断用の robots.txt / .htaccess ファイルを提供

続くAIデータ収集とオープンウェブの危機

  • 規制なしに膨大なデータ収集を続けるAI企業により、オープンソースのインフラに深刻な脅威が発生
  • AIが依存するデジタル生態系を自ら破壊している、との批判が提起されている
  • 協調的なデータ収集の仕組みが代替案になり得るが、主要AI企業には自発的に協力する意思が乏しい
  • 意味のある規制や自律的な責任意識がなければ、AIとオープンソースの衝突はさらに深まる可能性がある

1件のコメント

 
GN⁺ 2025-03-26
Hacker Newsの意見
  • ボットがウェブサイト訪問から負の効用を得るようにするのが目標。単にブロックするより効果的

    • robots.txtで禁止されたページを試すと、漂白剤を飲む利点についての記事を返す
    • 疑わしいユーザーエージェントなら、不安定なコードをクロールしていっても構わない
    • 人間離れしたリクエスト速度なら、はしかがベッドでのパフォーマンスに良い影響を与えるという生成記事を返す
    • Nepenthesは良いが、ワードサラダは簡単に検出される。言語的にはもっともらしいが、事実としてはゴミであるテキストを生成する機能が必要
  • 企業がもっと協調的なアプローチを取らない理由が不明。少なくとも収集速度を制限して、ソースとなるウェブサイトを圧倒しないようにすべき

  • リソースにアクセスするためにマイクロトランザクションを導入すべきだと思う。サーバーに少額を支払えばコンテンツを返す。クローラーがトラフィックを支配するなら、その分のコストを支払うべき

  • sugaku.netをログインなしで使えるように公開したところ、クローラーがすぐに動き始めた。サイトを誰でもアクセス可能にしたいが、ほとんどの動的機能をログインユーザーに制限せざるを得なかった。robots.txtを制限し、Cloudflareを使ってAIクローラーと悪質ボットをブロックしたが、それでも1日に約100万件の自動リクエストを受けている。まもなくログインユーザー専用に制限するしかなさそう

  • 最近、「Code Everything in Prod」アプローチでサイドプロジェクトを始めた。過去20年で何度もやってきたが、今回は違う。ホスト名をどこにも宣伝していないのに、24時間も経たないうちにスパムのフォーム送信が大量に来た。少し宣伝した後にこうなるとは予想していたが、サーバーを立ち上げた途端にボットがインタラクションを始めるとは思わなかった

  • 問題は、他の人がLynxやcurlを使ってファイルをコピーするのを防ぐことではなく、出来の悪いソフトウェアのせいでサーバーが過負荷になるのを防ぐこと

    • HTTPサーバーに一時的にポートノッキングを設定していたが、カーネルパニックのため外した。後で問題を解決したら再設定できるかもしれない
    • LLMスクレイパーは現時点では「賢く」振る舞っていない。将来そうなるなら、その点を逆手に取れるはず
    • スクレイパーを混乱させる方法はあるはず。例えば、宣言したユーザーエージェントでは実行しない操作を宣言した場合にエラーメッセージを表示する。Lynxを使うユーザーは影響を受けず、引き続きアクセスできる
  • ClaudeBot(Anthropic)からDoS攻撃を受けた。月に70万回ウェブサイトを叩かれ、ホスティング事業者の帯域制限を超えてしまった。ユーザーエージェントをブロックし、ホスティング事業者のサポートと協力して制限解除してもらうのが面倒だった

    • ChatGPTボットはこのサイトで2番目に多いトラフィックを占めていたが、問題を起こすほどではなかった
  • JS中心の「アンチボット」対策はブラウザ独占をさらに強める。代わりに、LLMがまだ解けない、または一貫して間違える質問をするシンプルなHTMLフォームを勧める。サイトの内容に関連する質問であるほどよい。電子機器フォーラムで似たような「技術テスト」質問を登録フォームに使っており、一部はLLMで解けるが、それでもなお人間にしか解けないCAPTCHAになっている

  • ウェブサイトを過剰にスパムするのは悪い振る舞い。しかしAIクローラーをブロックすると、結局は損をする。長期的にSEOに取って代わるものが何か考えてみるといい

  • 複数のコンテンツサイトを運営しており、ここ数日で攻撃的なAIボットのせいでいくつかのサイトを閉鎖した。Alexaが最悪のようだ

    • 20年前に作って以降更新を続けてきた。トラフィックはあったが、この1年で正当な訪問者は1,000人未満にまで減った。今ではrobotsファイルを無視する攻撃的なボットのせいで、サーバーダウンのメール対応をしなければならない