LLMクローラー対策で個人ブログがブロック、フィードバックダーに波及

個人ウェブサイト運営者が、LLM（大規模言語モデル）訓練用データ収集を目的とした高頻度クローラーの対策に頭を悩ませている。カナダのトロント大学でシステム管理者を務めるChris Siebenmann氏が運営するブログ「Wandering Thoughts」は、そうしたクローラー対策の実例として業界の注目を集めている。同ブログでは、古いブラウザのUser-Agentを持つアクセスをブロックする措置を導入した結果、一部のフィードバックダーにも影響が及んでいることが明らかになった。

クローラー問題の背景

Siebenmann氏は2025年初頭以降、LLM訓練用データ収集を目的とした高頻度クローラーの急増に直面している。これらのクローラーは、旧バージョンのChromeに代表される古いブラウザのUser-Agent文字列を偽装してアクセスしてくる。個人運営のブログにとって、こうしたクローラーがもたらすサーバー負荷は無視できないものとなっている。

対策として、同ブログはHTTPリクエストのUser-Agentを検査し、古いブラウザと判断されるものに対してアクセスを拒否する仕組みを導入した。しかし、この単純なブロック手法には意図しない副作用が伴った。

フィードバックダーへの影響

最も顕著な影響は、RSSフィードバックダーを利用する読者に現れた。InoreaderとFeedlyの両サービスで、同ブログのフィード内容が正常に取得できず、代わりにブロックページが表示される現象が発生している。

Siebenmann氏の調査によれば、これらのフィードバックダーは定期的にフィードを取得する際に、古いブラウザのUser-Agentを使用したHTTPリクエストを送信している。その結果、本来のフィードデータではなくブロックページをキャッシュし、ユーザーに表示してしまうという。

Feedlyについては、通常のフィード取得時とは異なるUser-Agentでアクセスしていることが確認された。Inoreaderも同様の問題を抱えており、同社のフィード取得エージェント自体はブロック対象ではないものの、異なるUser-Agentでのリクエストによってブロックを引き起こしている。

VivaldiブラウザのUser-Agent問題

この問題はフィードバックダーにとどまらない。ChromiumベースのブラウザVivaldiでは、デフォルト設定でUser-AgentがGoogle Chromeとして偽装される。Siebenmann氏は、現在進行中の攻撃への対処として、Vivaldiユーザーに対して設定から「User Agent Brand Masking」を変更し、本来のVivaldiとして識別されるようにすることを推奨している。

アーカイブサイトの厄介な課題

archive.today、archive.ph、archive.isといったいわゆる「archive.*」サイトも、今回のブロック措置の影響を強く受けている。これらのサイトはWebページのスナップショットを保存する目的で動作するが、そのクローリング方法が悪意あるアクターと区別できないという問題がある。

具体的には、archive.*のクローラーは古いChromeのUser-Agent値を使用し、IPアドレス帯も広範囲に分散しており、明確に特定できない。さらに一部のIPアドレスでは、逆DNSエントリがGooglebotのものであるかのように偽装されているケースもある。これは通常、悪質な攻撃者にしか見られない挙動だ。

Siebenmann氏は、より適切な振る舞いをするアーカイブクローラーとしてarchive.org（Wayback Machine）を推奨している。

個人サイト運営者のジレンマ

今回の事例は、個人または小規模なウェブサイト運営者が直面する普遍的なジレンマを浮き彫りにしている。LLM訓練データ収集を目的としたクローラーの増加は、サーバー負荷の面で無視できないコストを発生させる。しかし、User-Agentベースのブロックは粗い手法であり、正当なユーザーやサービスにまで影響を及ぼす。

特に、RSSフィードバックダーは古くから多くのユーザーに利用されているサービスであり、ブログ運営者にとって重要な読者層を失うリスクがある。FeedlyやInoreaderのようなサービスが、フィード取得時に使用するUser-Agentを適切に管理できていない点は、業界全体としての改善が求められる。

技術的対策の限界

User-Agentによるブロックは、実装が容易である反面、攻撃者側も容易に偽装できる。一方で、正当なサービスが偶然ブロックされるリスクを完全に排除するには、より高度なアクセス制御（IPレピュテーション、JavaScriptチャレンジ、CAPTCHAなど）が必要となるが、個人運営のサイトにそれらの導入コストを求めるのは現実的ではない。

Siebenmann氏はこの問題に対して、ブロックの緩和やホワイトリスト化といった対応を行っていない。負荷の問題とクローラーの悪質性を考慮すると、現状のブロック方針を維持せざるを得ないという判断だ。

編集部の見解

短期的には、個人ブログや小規模サイトでのUser-Agentブロックが増加すると予想される。LLM訓練データ収集を目的としたクローラーは今後も増加傾向にあり、運営者側の対策も強化されるだろう。ただし、今回のようにフィードバックダーへの影響が表面化したことで、フィードバックダー各社がUser-Agent管理を見直すきっかけになる可能性はある。特にFeedlyやInoreaderは、フィード取得専用のUser-Agentを固定するなどの対応を迫られるだろう。

長期的には、User-Agentに依存したブロック手法自体の有効性が低下すると見る。LLM訓練用クローラーは日々進化しており、現実的なブラウザのUser-Agentを使い、より人間らしい振る舞いを模倣するようになる。結果として、ウェブサイト側はコンテンツ配信ポリシーをより細かく設定できる仕組み（例：robots.txtの高度な活用、API経由でのアクセス制御、利用規約の強化）を導入する必要に迫られる。また、業界全体として、LLM訓練データの収集とウェブ公開者の権利を調和させるルール形成が不可欠となる。

編集部としては、今回の事例が単なる「個人ブログの苦労話」ではなく、インターネットの相互運用性とAI産業のデータ需要との間に存在する構造的な緊張関係を示していると捉える。フィードバックダーとブロックの衝突はその氷山の一角に過ぎない。AI企業がウェブ上のパブリックデータをどの程度まで利用する権利を持つのか、またサイト運営者がどのような対策を取るべきかについて、業界全体での議論がますます重要になる。この問題は、Apple Intelligence本格始動、iOS 27でSiri AI刷新へのような大規模AI展開が進む中で、データ収集の倫理的・技術的基盤を再考する契機とも言える。

参考

• Understanding Embark in GNU Emacs (a bit) and some ‘stupid’ Embark tricks（元記事。ただしアクセスブロックにより取得不可） — 2026-06-09公開
• Wandering Thoughtsブログ管理者によるコメント（元記事内）