OpenAI内部の連絡先を持つ人なら誰でも、スパイダー問題の解決を要請

OpenAI GPTBotのWebサイトクロール問題

• 著者のWebサイト web.sp.am では、OpenAIのGPTBotが訪問して過剰にページをクロールする問題が発生している

  • 1日に約300万ページをリクエストし、そのうち180万件は robots.txt へのリクエストだった
  • 著者のサイトはContent Farmの形態で、68億5900万のWebサイトがそれぞれ1つのページを持つ構造になっている
  • すべてのページはほぼ同一に見え、同じIP、同じワイルドカードSSL証明書を使用しているため、クローラーが状況を把握するのは難しくない状態である

• 1〜2か月前にはAmazonのクローラーも同様の問題を起こしたが、連絡を取ってクロールを停止させることができた

• 著者はOpenAIにも連絡できる人がいるか尋ねている

• 著者は、自分のWebサイトのデータがGPT-5の学習に使われているようだと冗談を言っている

GN⁺の見解

• クローラーが robots.txt を正しく解釈できず過剰なリクエストを送ることは、悪意がなくても相手の立場ではサービスに被害を与えうる深刻な問題である。OpenAIも早急にクローラーロジックを改善する必要がありそうだ
• 特にContent Farmのように多数のドメインを運用する環境では、それぞれのサイトを個別にクロールしないよう、IPベースのフィルタリングなどの対策を検討する必要がある
• クロールボットの動作を監視し、異常兆候を検知して迅速に対応できるプロセスとシステムが必要に見える
• クロール対象サイトの管理者と緊密にコミュニケーションを取りながら、被害を最小限に抑えられるようにすべきである。無条件にデータ収集だけへ注力するのではなく、共存共栄の観点が重要だ

[GN⁺]

Hacker Newsの意見

• GPT-2/3/J は、ユーザーが無限大まで増分した数字を投稿する r/counting というサブレディットを見て、SolidGoldMagikarp のようなユーザー名をインターネット上で一般的な文字列だと見なし、トークナイゼーション時に最上位トークンとして扱った。

• GPT-3 の語彙は 50,257 個の固有トークンに制限されていた。このサブレディット利用者のニッチな趣味による電力コスト増加と、実際のテキストでよく現れる部分文字列にスロットを割り当てて平均入力トークン数を減らすこととの間には線形関係ではないにせよ、測定可能な影響があったのではないかと推測される。

• ウェブサイトのサブタイトルである "IECC ChurnWare 0.3" が GPT-5 のトークンになったら面白いだろう。

• ウェブサイト所有者が robots.txt を正しく書いておらず、実際にはクロールを許可する部分をコメントアウトしていた。

• コンテンツファームの目的について疑問が呈されている。無意味に見えるが、奇妙な経済的インセンティブがあるのではないかと疑われている。アフィリエイトリンクはあるが、どれほど収益になるのかは疑問だ。

• 一部では、OpenAI のサーバーファームに本物のクモがいて、別のラックに移ってくれることを期待していた。

• ネットワークセキュリティではこれを tarpit と呼ぶ。攻撃、スキャン、自動化を遅延させ、攻撃者の時間とエネルギーを浪費させることで、防御側が時間を稼げる。

• OpenAI も robots.txt に従うなら、ボット遮断とデータ収集の問題がある。上位 10 万のウェブサイトのうち 11% がすでにクローラーをブロックしており、競合他社より多い。

• ウェブサイトの運営者は数百万ページの検索をそれほど気にしていないようなので、OpenAI に好きにさせておくのがよさそうだ。

• 結局、OpenAI などは主に AI が生成した、しばしば少し不正確なコンテンツでモデルを学習させることになり、それが AI の応答品質低下につながる可能性がある。今はまだ大半が人間の書いたコンテンツだが、5 年後にはそうではないだろう。AI 業界が早急に解決すべき問題の 1 つだ。

• そもそもこの種のウェブサイトの目的自体がスパイダーの時間やリソースを浪費させることなのに、なぜ OpenAI に対してはそうしないのだろうか？

• この種のハニーポットは、LLM 学習を汚染する興味深い方法に見える。