ハクソク

世界を動かす技術を、日本語で。

AIスクレイパーのせいで、私たちは良いものを手に入れられない

132日前原文(blog.metabrainz.org)

概要

Anubis は、AI企業による ウェブサイトの過剰なスクレイピング からサーバーを守るための Proof-of-Work方式 の保護システム。 ユーザーには一時的な 負荷 がかかるが、 大量アクセス に対して効果的。 将来的には 正規ユーザーの判別精度 を高め、Proof-of-Workページの表示頻度を 減少予定。 JavaScriptの最新機能 が必要で、特定のプラグインは 無効化推奨。 システム導入の 背景や今後の展望 についても説明。

Anubisによるサーバー保護の仕組み

  • Anubis は、サイト管理者が AI企業のスクレイピング対策 として導入する保護システム
  • Proof-of-Work（PoW） 方式を採用し、アクセスごとに 計算負荷 を課す設計
  • Hashcash に着想を得た方式で、 メールスパム対策 にも使われてきた技術
  • 個人ユーザーには 無視できる程度の負荷 だが、大量アクセス時にはコストが増大
  • リソースの過剰消費防止 と 正規ユーザーのアクセス維持 を両立

今後の対応方針とユーザーへの影響

  • PoWページ は仮の対応策であり、将来的には ヘッドレスブラウザの判別技術 を強化予定
  • フォントレンダリング などの挙動から 正規ユーザーと自動化ツール の識別精度を向上
  • PoWページ表示頻度の削減 によるユーザー体験の改善方針
  • JShelter などのプラグインは 最新JavaScript機能を無効化 するため、 無効化推奨
  • 利用者にとっては一時的な アクセス遅延 が発生する可能性

Anubis導入の背景と今後の展望

  • AI企業によるWebリソースの大量取得 問題の深刻化
  • サーバーの ダウンタイム や リソース枯渇 への懸念
  • PoW方式 による応急処置と 恒久的な対策技術 の開発計画
  • 正規ユーザーの利便性維持 と 不正アクセス排除 の両立目標
  • Webセキュリティ と ユーザー体験 の最適化方針

Hackerたちの意見

Cloudflareは、AIスクレイパーを検出して、無限のAI生成のナンセンスページに送るサービスを今提供してるよ。

└

それに関するリンクある？

└

わお、AIスクレイパーからデータを守るためには、すべてのトラフィックを第三者の会社を通さなきゃいけないのか。それで誰が私のコンテンツを見るか決めるって、素晴らしいアイデアだね！

└

現代のスクレイパーはヘッドレスのChromiumを使ってるから、見えないリンクは見えないんだよね。だから、どれくらい効果があるのかは分からないな。

└

残念ながら、Cloudflareは共有接続やVPN、変わったブラウザを使ってるユーザーにとって、体験を台無しにすることが多いんだ。苦情が多すぎて、サイトから外さなきゃならなかったよ。

└

Cloudflareのサービスが必要ない方が、まだマシな体験だよね。

└

Cloudflareにお金を払って免除されるスクレイパー以外はね。

└

解決策は、いつも通り、ノイズだね。

└

Poison Fountain: https://news.ycombinator.com/item?id=46577464

└

cloudflareが、私の人間が運転しているブラウザをいつもブロックするんだよね。「JavaScriptとクッキーを有効にして続行してください」って、サポートされてないブラウザって。

└

"TLSがここで追加され、削除されました :)" というサービスがこの問題に対して正しいツールかどうかはわからないな。

時間が経つにつれて、みんなに共通のクローリングみたいなものを強制するのが解決策だとますます確信してる。バカなDFSスクレイパーがサーバーを100%にしてしまうのは嫌だけど、普通の人がウェブをスクレイピングできる状態に戻したい。クラウドフレアが登場する前のように、もっと簡単にスクレイピングできるように。もしかしたら、タイムスタンプ付きのデータダンプへのリンクを含む新しい/.well-known/パスを作ることで合意できるかもね。

└

それがMetaBrainzのやり方だね。彼らは全データベースを一つのtarボールダンプとして提供してる。Wikipediaと似たような感じ。ダウンロードに1時間くらいかかったし、MusicBrainzの検索が必要な時はローカルクエリを使うだけ。これがうまくいくためには、みんながデータベースダンプを実際に使う必要があるんだ。スクレイピングにデフォルトで頼るのはダメだよ。残念ながら、スクレイピングは簡単すぎるし、今はAIコードアシスタントが5〜10分で動くスクレイパーを作れるからね。

└

誰かがスクレイピングしたいなら、Googleのように完全なインターネットを対象にするんじゃなくて、ニッチなレベル（例えば、スクレイピングしたいフォーラムがある場合）でやりたいと思ってる。そういうのに関してTampermonkeyスクリプトを作るのが好きなんだ。これは、拡張機能を作るのがもっと軽量で簡単な方法だと思う。AIはあまり好きじゃないけど、スクレイピングについては何も知らなかったから、AIを使ってスクレイピングコードを生成してTampermonkeyに貼り付けて実行させた。最近、VPSサーバーとその価格のリストがあるウェブサイトをスクレイピングして、分析用のリストを作ったんだ。それに、似たようなウェブサイトでデータベースを探してたら、連絡したけど返事がなかった。サーバー価格のデータベースはプライベートで、最低価格しか表示されなかったから、他のウェブサイトを選んでやったよ。それに、LowEndTalkの全てのヘッドラインをリンク付きでスクレイピングして、アーカイブ目的とヘッドラインをスクレイピングしてLLMに解析させてVPSプロバイダーのリストを見つけるために使った。

└

それからYCが、他の誰もが持っている標準データを使わずに自分たちのスクレイピングをして競争をリードしようとするスタートアップに資金を提供するんだ。

└

いいアイデアだし、もしかしたら標準化されることで、デルタだけを取得したり、何らかのetagを使って「持ってるデータベースダンプの後にあるものを全部くれ」ってできるようになるかもね。

└

また夢のようなプランを提案するね。AIを考慮して著作権制度を完全に見直して、みんなにとってウィンウィンな形にすべきだと思う。これは、NISTの数字セットが機械ビジョンを学びたい人にとっての「ハローワールド」データセットみたいなもので、共通のデータセットがあるとすごく便利だっていう考えに基づいてる。数字は適当に思いついたものだから調整が必要だけど、基本的なアイデアはこうだ：1) 著作権をデフォルトで15〜20年に短縮。初回出版から2〜3年以内に「国家データセット」に作品を提出すれば、10〜15年の延長が可能。2) 国家データセットの内容はしっかり分類されて整理されてる。誰もが欲しい一番クリーンなデータセットだよ。データセットは公共モデルのトレーニングにも使われるし、自分のモデルをトレーニングしたい人にもライセンスされる。公共モデルとデータセットは名目上の料金でライセンスされる。3) 公共モデルやデータセットをAIシステムの一部として使う人は、これらのモデルによって生成されたコンテンツに関する著作権侵害の主張から免除される。ただし、故意の違反（例えば、本の内容をepubにすること）には例外がある。自分でデータをスクレイピングする人は、スクレイピングと使用に関する現行法に従う必要があるから、たくさん本を買う必要があるかも。4) データとモデルのライセンスから得られるライセンス料は、データセットに含まれる著作権保護されている作品の作者に、提出されたデータの量に比例して、データの年齢に反比例してロイヤリティとして分配される。無駄なデータで国家データセットを汚さないように、絶対的な上限も設ける。みんなが何かを得られる仕組みだよ。AIの人たちはクリーンなデータを手に入れられるし、著作権者はAIに使われた作品で報酬を得られるし、公共は自分たちのデータセットを作るためにリソースを使わずに済むし、サイトの運営者たちはボットやスクレイピングのトラフィックが減る。完璧ではないけど、こういうものの性質だと思う。

└

あなたが直面しているのは技術的な問題じゃない。お金の問題だよ。特に、隔離された富の大きなプールが、疑わしい技術分野で非常に悪い長期投資をしていることが原因。こうしたプロセスによって生まれる新しい現象は、他のコンピューティングにも同じように悪影響を及ぼす。ウェブサイトを破壊することには、果実をつかむ人たちが無視できないほどの市場価値がある。時間が経てば適応策が生まれるだろうけど、望まれている技術的未来は必ずしも避けられないわけじゃない。

└

ほんと、これが答えの一部だと思わざるを得ないよ。/llms.txtみたいなもので、.txtや.txt.gzファイルのリストが含まれてるとか？問題は、どのサイトも独自のデータダンプ形式を持ってるから、複雑なXMLやSQLとかになっちゃうことが多いんだよね。LLMはそのメタデータなんて必要ないし、例えばYelpみたいに競合にレストランリストをスクレイピングされたくないサイトもあるだろうけど、もし意図的に段落スタイルのテキストだけに制限して、URLやID、住所、電話番号とかを完全に削除したら、例えばYelpのページは料理のカテゴリーと各レストランのレビューだけになる。名前も都市も識別子も何もなし。そうすれば、LLMが必要な情報をもっと早く得られるし、サイトも負荷がかからないし、競合が簡単にコンテンツをコピーできる形式でもない。せいぜい、ページや商品、レストランなどの「メイン名詞」を表すマークアップを追加して、レストランのレビューやレビューへのコメント、さらにそのコメントへのコメントなどを再帰的に表現する感じかな。あとは、いくつかのタグを追加するくらいで、基本的には純粋なテキストがいい。できるだけシンプルにね。一番の問題は、多くのサイトがほとんどコンテンツのない「ダミー」llms.txtを作っちゃうこと。そんなの気にしないから、スクレイパーは結局スクレイピングしちゃうんだよね…。

Metabrainzは素晴らしいリソースだよ。数年前にここで彼らについて書いたことがある：https://www.eff.org/deeplinks/2021/06/organizing-public-inte... Metabrainzのような公共の利益は、AIボットが彼らのコンテンツを拾うのを許容するはずなんだ。ただ、彼らは非常に非効率的な方法でやってるだけ。これは調整の問題で、Metabrainzはボットに良い意図があると仮定していて、その信頼が破られるとロックダウンしなきゃいけない。ボットは別のモデルを持っていて、ウェブサイトが敵対的にコンテンツを「隠している」と仮定している。彼らは「見て、APIを叩くのをやめて、これを一気に取れるgzipped tarファイルがあるから」と言っても、ランダムなサイトを信じないんだ。もっと言うと、このトレントファイルを使えば、ボットがデータの共有性を一時的に向上させることになるかも。

└

「ランダムなサイトが『見て、APIを叩くのはやめて、これを一度に全部取得できるgzipped tarファイルがあるから』って言っても、信じないだろう。」サイトにはそれを実現するための仕組みがあるのかな？robots.txtの標準には優先順位を設定することについての記載は見当たらないけど、何か見落としてるかもしれない。

└

そうだね、AIスクレイパーが理由の一つで、私の公開ウェブサイト https://tvnfo.com を閉じて、寄付者用のサイトだけ残したよ。AIスクレイパーだけが理由じゃなくて、サイトをスクレイピングしようとする人たちに疲れちゃったんだ。この小さなプロジェクトにはリソースがあまりないからね。本当に悲しいことに、2016年から公開されてたのに。今は寄付者だけがアクセスできる状態。月60ドルで小さなプロジェクトを運営してるけど、これが趣味じゃなかったら、ずっと前に完全に閉じてたと思うよ :-) もし将来的にもっとサポートがあれば、Anubesのボット保護みたいなものを使って再度公開サイトを開くかもしれない。でも、私のような小さなサイトが大打撃を受けるのは自分だけだと思ってたけど、似たような問題を抱えてるところがたくさんあるみたい。もうすぐ、オンラインでオープンなものや役立つものは何もなくなるんじゃないかな。大規模にAIを推進している誰かの計画だったのかもね。

└

「見て、私たちのAPIを叩くのをやめて、これを一度に全部取れるgzipped tarファイルがあるから。」って言っても、ランダムなサイトは信じてくれないよね。これを示すメカニズムはあるのかな？Scorpionのクロールポリシーファイルの「a」コマンドはその目的のためにあるけど、WWWでは使えないんだ。（Scorpionのクロールポリシーファイルには他にも役立つコマンドがいくつかあるけど、これもWWWでは使えない。）また、どのくらいの間隔でアーカイブされてダウンロードできるかを知る必要もある。頻繁に変わるデータについては、毎回やるわけにはいかないし。この考慮はトレントにも当てはまる。新しいファイルのバージョンには新しいハッシュが必要だからね。

└

それよりも、ボットがデータの共有性を向上させるようなトレントファイルがあったらいいよね。それは素晴らしい考えだ。

その気持ち、わかるよ。倫理的でないスクレイパーを見つけるのは本当に難しい。彼らは住宅用IPプールを使って、IPを回転させて、正当なユーザーエージェントを提供してるからね。

└

最近のプロキシやスクレイピングサービスは、実際のブラウザを使ってCloudflareのキャプチャを自動で回避することができるようになってるんだよね。それに、実際のブラウザを使ったボットも見えないリンクをクリックすることはないから…どれくらいの間、これが効果を持つのかはちょっと疑問だな。

前回誰かに納得させられたんだけど[0]、これらは私たちが知っている有名なスクレイパーではなく、他のアクターなんだって。確かに、私たちには判断できないよね。スクレイパーが私のサイトをもっと上手に読み取れるように手助けしたいけど、彼らがそうしない理由も分かる。こういうための確立されたプロトコルがあればいいのに。例えば、$site/.well-known/machine-readable.jsonみたいなもので、いくつかの既存のソフトウェアについての指示を出したり、適切なダンプを指し示したりできるといいな。LLMsのためにそれを提供するのは喜んでやるよ。もちろん、AI企業が実際のサイトをナビゲートする方法を学ぶためにモデルを訓練しようとしているケースには解決策にならないのは理解してるけど、将来的には自分の知っているウェブのアーカイブを持ちたいと思ってるんだ（Internet Archiveは遅すぎて、レート制限も厳しいし）。ロボットに対するプロトコルサポートがこんなに少ないのには驚いた。robots.txtはかなりスカスカだよね。ボットを禁止することはできるけど、私が言いたいのは「このgitリポジトリから全部のデータを取得できるよ」とか「これが再現するためのダンプだよ」ってこと。要するに、ロボットとの協力が現在は十分に定義されてないんだ。理由は分かるけど、ほとんどのボットには協力するインセンティブがないから、ウェブマスターも試みないんだよね。でも、ロボットに適切に情報を伝えられるようになったらいいな。Metabrainzをアーカイブするには、ページを一つずつゆっくりブラウジングするしかない。代替手段を示す機械間通信の方法はないんだ。0: https://news.ycombinator.com/item?id=46352723

└

記事にもある通り、代替案は確実にあるよ。https://metabrainz.org/datasets ホームページから「datasets」としてリンクされてる。ただ、「機械が通信できる」という意味をAIのスクレイピングの文脈で広く解釈しすぎてるかもしれないけど。

└

Metabrainzをアーカイブするには、ページを一つずつゆっくり見るしかない。代替案を示すような機械が通信できる方法はない。なんで「機械が通信できる方法」が必要なんだろう？もし開発者たちがそんなことを気にしてるなら、このページを20秒くらい見ればいいのに。Googleで「metabrainz」を検索すると、まさに最初のリンクの一つだよ。https://metabrainz.org/datasets

AIスクレイパーだけじゃなくて、今はユーザーもリンクをClaudeチャットやChatGPTに入れて要約を頼むように訓練されてるんだよね。もちろん、それはウェブサイト側ではスクレイパーとして表示されることになる。実際、Firefoxは今、リンクをプレビューして重要なポイントを得ることができるようになってるんだよね。[1] [1] https://imgur.com/a/3E17Dts

└

実際、Firefoxは今やリンクをプレビューして、リンクに行かなくても重要なポイントを得られるようになったよ。[1] > [1] https://imgur.com/a/3E17Dts これは、llama.cppをWebAssembly（別名wllama）にコンパイルして、SmolLM2-360Mを動かしてるデバイス上で生成されたものだよ。[1] これは、ユーザーがリンクをクリックするのとどう違うの？結局、ローカルのFirefoxは要約するためにリンクを取得することになるから、リンクをたどってリーダーモードでドキュメントを読むのと同じだよ。 [1] https://blog.mozilla.org/en/mozilla/ai/ai-tech/ai-link-previ...

└

ユーザーは訓練されてないよ。HNでの支配的な信念とは逆に、みんなLLMを情報（ウェブ上でもそれ以外でも）とやり取りするために使ってるのは、ちゃんと機能するから。最新のLLMサービスはそれだけ優れてるんだよ。

└

問題は3つあるね：- AIショップがネットエチケットを無視してデータセットを更新するためにウェブをスクレイピングしてる（時にはスケールのせいで自動化できないこともある、皮肉なことに）。- 人々がエージェント（検索、要約、自律エージェントなど）を広範に使っていて、ウェブサイトから見るとスクレイパーボットと区別がつかない。- エージェントは人間よりも速いけど、効率が悪い（アクションごとのリクエストが多い）。

こんなの必要じゃなければいいのに。でも、次のステップはおそらくこうなるだろうね：a) IPごと、ネットブロックごとに「リクエスト予算」を保持するリバースプロキシを持つ。ただし、リクエストをブロックするのではなく、クライアントにIPをローテーションさせる代わりに、リクエストを制限/遅延させて、ドロップしないようにする。b) APIサーバーをもっと効率的な言語で書く。Githubによると、バックエンドはPerlとPythonで動いてるみたい。これらの技術はかなりの間「十分良い」ものだったけど、今の状況を考えると、より良い解決策が見つかるまで、もうそうではないかもしれないし、リクエストごとのパフォーマンスとCPUコストは今重要だよ。c) データベースクエリを最適化して、認証されていないGETリクエストハンドラーからできるだけ多くのコードを取り除いて、高コストなものには認証を要求する。

SQLiteチームも去年似たような問題に直面して、Richard Hipp（SQLiteの創始者）がほぼ同じコメントをしたんだ。「この攻撃の背後にいる悪党は、SQLiteのソースリポジトリ全体をクローンして、自分のマシンで内容をゆっくり検索することができる。でも、悪いことをするからには、他の人のためにそれを台無しにする必要がある。だから、いいものは手に入らないんだ…」 https://sqlite.org/forum/forumpost/7d3eb059f81ff694

└

このレトリックには本当に疲れる。悪い？本当に？ちょっと大げさじゃない？

└

この批判は面白くない。だって、全ウェブを何度もクロールするために作られた、資金は潤沢だけどコードがひどいウェブクローラーを擬人化しようとしてるだけだから。「リポジトリをクローンすればいいじゃん？」マジで？

残念だな。CDをリッピングしてたときによく使ってた。匿名性はウェブの大きな価値だよ（少なくとも匿名性の見かけはね）。信頼を伝えるだけの中央集権的な匿名システムがあればいいのに。だから、トークンを取得できるけど、その信頼は他のトークンと組み合わせるまでほぼゼロみたいな感じ。トークンを組み合わせることで、その信頼と結果が合わさる。もし一つのトークンが悪用されたら、その悪用は全体のトークンチェーンに反映される。トークンの接続は取り消せるけど、信頼を再構築するには時間がかかるから、トークンの信頼価値が上がるまでには時間がかかる。いわば「口コミ」効果を電子的に表現した感じ。『2345asdf334t324sdaを保証するよ。すごいユーザーエージェントだ！』ちょっと（かなり）複雑だけど、もしかしたらアイデアの始まりがあるかも。音楽関連のサービスで匿名性（またはその見かけ）を失いたくないけど、同時に信頼を得るためのメカニズムが必要だよね。今のところ、アイデンティティが付いていない良い方法は思いつかないな。

AIは、他のすべてと一緒に自由なインターネットを壊してる。先週、ウェブホストが突然の大量リクエストで私のウェブサイトアカウントを停止したんだ。要するに、ボットにスクレイピングされたことで罰を受けたってこと。新しいホストに移らなきゃいけなかったけど、小さい企業にはどんな希望があるの？GPUやRAMの価格と同じで、10倍、100倍、1000倍払ったところで、AI企業は無限のリソースを持ってるし、業界のナンバーワンになるためにどんなダメージを与えても気にしない。皮肉なことに、これは意図的だと思う。すべての無料サイトを壊して、彼らのAIモデルから情報を得るしかなくさせる。家庭ユーザーを高性能ハードウェアから排除して、大企業から機能をリースしなきゃいけなくするんだ。