- Published on
スクレイパーは今や数百万の家庭用IPからやってくる — residential proxyとオープンソース基盤の消耗戦
- Authors
- Name
- Youngju Kim
- @fjvbn20031
はじめに — IPが身元でなくなった日
2026年7月10日、LWNのJonathan Corbet氏が スクレイパー状況のアップデート を公開しました。2025年初頭の記事の続報ですが、その淡々とした結論こそが重いのです — 問題は解決されるどころか拡大を続け、LWNは最近 観測史上もっとも激しいスクレイパー攻撃 を受けました。
公開インフラを少しでも運用したことがある人なら、これは他人事ではありません。gitサーバーも、wikiも、ドキュメントサイトも、個人ブログも、今はすべて標的です。そして私たちが十年使ってきた防御の定石 — IPでレート制限し、悪いuser-agentを弾き、地域でふるいにかける — が、ほとんど効かなくなりました。二つの要因が重なったからです。residential proxy が「IP = 身元」という前提を壊し、AIクローラーのゴールドラッシュがその需要を満たしました。この記事は、なぜブロックが構造的に失敗するのか、そして机上のあらゆる防御が開かれたウェブに税を課すという正直な事実を辿ります。
residential proxyはなぜブロックできないのか
まず攻撃の形を見ましょう。Corbet氏が報告した最近の攻撃はこういう形です。
一度の攻撃で観測されたもの (LWNの報告, 2026-07-10)
- 数時間のあいだに数百万の異なるIPアドレス
- 各IPはサイトを多くて二〜三回しか叩かない
- ボットは通常、画像やCSSを取得しない (人間ではない兆候)
- しかしそれに気づく頃には、そのIPは二度と現れない
要点は、それらのIPが一つひとつ本物の家庭回線だということです。residential proxy とは、ごく普通の人々の機器 — スマートフォン、セットトップボックス、ルーター — にインストールされたソフトウェアで、中央の制御ノードから命令を受け、代わりにページを取得し、結果を返します。機器の持ち主はたいていそれを知りません。
供給源は大きく二つです。一つは犯罪的なボットネットで、マルウェアに感染した機器であり、メディアストリーミング装置が主要な媒介として名指しされています。もう一つは「準合法」の事業者です。Corbet氏はもっとも目立つ例として Bright Data を挙げます — アクセス制御やトラフィック制限を回避する能力を堂々と宣伝し、「無料」のVPNを提供する見返りに、ユーザーの機器を通じてトラフィックを流す権利を得ます。名前の出ていない別の事業者は、アプリ開発者にSDKを渡し、ユーザーのネットワーク接続を再販する対価として金銭を支払います。
だからブロックが効かないのです。どの要求も、もっともらしく偽装された user-agent をまとって本物の家のアドレスから来ます。ボットだと指紋を取った頃には、そのIPはすでに引退しています。IP評価、レート制限、地域ブロックはすべて「IPの身元は安定している」という前提の上に立っており、その前提が崩れました。摘発は一時的には役立ちます — Googleは年初に IPIDEA を、7月2日にはFBIらと連携して NetNut を潰し、そのたびにLWNのトラフィックは一時的に減りました。しかし数か月後、攻撃は戻ってきました。もぐら叩きです。
AIクローラーはオープンソース基盤を真っ先に叩いた
一つ、正直に述べておきます。LWNの記事の本文は、おおむねLWN自身の運用経験です。ただ、この波を最初に、そしてもっとも強く受けたのはオープンソース基盤であり、もっとも知られた防御ツールもまさにそこで生まれました。
そのツールが Anubis です。Xe Iaso 氏が2025年初頭、Amazonのクローラーが robots.txt を無視して自分のgitサーバーを踏み荒らしたのを受けて作りました。MITライセンスのリバースプロキシで、訪問者のブラウザが SHA-256 の作業証明パズルを解いて初めてページを渡す門番です。以後、Linuxカーネルのメーリングリストアーカイブ、SourceHut、FFmpeg、Wine、GNOMEのGitLabといったgitフォージやFOSSプロジェクトが次々に採用しました。
なぜ他でもなくgitフォージだったのか。blame、diff、コミットごとのblobといった動的エンドポイントは要求あたりの計算が高くつきます。すべてのファイルのすべてのコミットを辿るクローラーは、それ自体が病的な負荷です。しかも自前ホストのオープンソースプロジェクトには Cloudflare Enterprise を買う予算がありません。ですから軽量な作業証明の壁は合理的な選択でした。
問題は、これが軍拡競争だということです。Codebergは2025年半ばの時点で、すでに多くのボットがAnubisのチャレンジを解く術を学習したと報告しました。LWNの記事に付いたある読者コメントも同じことを言います — AIクローラーがgitエンドポイントを叩きながらAnubisの検査をそのまま通過しており、少なくとも一部は実際のフルブラウザを使っているようだ、と。作業証明は安価なボットのコストを上げますが、資金の潤沢なクローラーは単に本物のブラウザを走らせるだけです。
防御手段とその代償
Corbet氏がざっと挙げる防御手段を整理すると、こうなります。どれも無料ではありません。
| 防御 | 仕組み | 代償 |
|---|---|---|
| 作業証明 (Anubis) | ブラウザがSHA-256パズルを解いて初めてページ提供 | 正規ユーザーも遅延、フルブラウザのクローラーは回避 |
| CAPTCHA | 人間であることの証明 (信号機探し、歌を口ずさむ) | 人間への負担が増え続ける |
| ログイン・ペイウォール | 匿名アクセスを遮断 | 公開ウェブの開放性を自ら手放す |
| データ汚染 (iocaine) | スクレイパーに壊れたデータを食わせる | 保守負担、誤検知のリスク |
| 最適化・レート制限 | 高価な処理を減らし匿名とログインを分離 | 根本的な遮断ではなく、直し続ける必要 |
CAPTCHA側のエスカレーションはやりきれません。Corbet氏は、信号機探し、パズルのピース合わせ、さらにはスペースバーを押しながら歌を口ずさめという生体チャレンジまで列挙します。ボットが賢くなるほど、人間に課される負担は重くなるということです。当のLWNは Anubis を使わないと決めました。Corbet氏の理由は二つで、正規の訪問者に煩わしい遅延を与えること、そしてスクレイパーが結局は回避策を見つけるのが「必然」に見えることです。代わりにLWNはサイトを積極的に最適化し、高価な処理を減らし、匿名ユーザーとログインユーザーを別扱いにします。正直で皮肉な結果が一つ — 攻撃を受けている最中の応答時間が、平穏なときよりむしろ速いことが多いそうです。
しかし根本的な代償は、三層になって残ります。第一に、全員に課される税です。運用者はこの仕掛けを組み上げて保守しなければならず、ユーザーは摩擦に耐えなければなりません。第二に、巻き添え被害です。防御を強くするほど、正規の検索エンジンや Internet Archive まで引っかかります。かといって支配的な検索エンジンだけを許可リストに入れれば、Corbet氏の言葉どおり、すでに私たちにろくに奉仕していないその独占をさらに固めるだけです。第三に、あらゆる防御は一時的です。今日は効いても、効かなくなった日のことを今から考えておかねばなりません。
おわりに
ここに、きれいな勝利はありません。residential proxy は「IPは身元だ」という古い前提を打ち砕き、AIのゴールドラッシュはその上に無限の需要を積み上げ、あらゆる対抗策は開かれたウェブの一部を堀に変える取引です。だからCorbet氏の懸念は誇張ではありません — インターネット全体が「防御壁の裏」へ退いてしまう危険は、現実のものです。
公開インフラを運用する人に残る実践的な教訓はこうです。IPベースの防御は死んだと仮定してください。摩擦のコストを予算に入れてください。そしてこれは解決すべき問題ではなく、回し続ける軍拡競争だと受け入れてください。正直な対応は、魔法の壁に頼ることではなく、優雅に劣化するように設計すること — 安価なエンドポイント、キャッシュ、匿名とログインのきれいな分離です。壁はいずれ破られます。破られても立っていられるように建てるほうが賢明です。