これまでデータを取得するにはプログラマーが必要だったが、今は一言で済む。

かつて素人スクレイパーを阻んでいた技術的障壁は、たまたま大規模言語モデルが最も得意とする種類のタスクにそれぞれ対応している。長年防御に携わってきた人物がそれらを一つずつ分解し、どの壁がどこで崩れたのか、そして防御がなぜ形骸化している可能性があるのかを説明する。

日本語
コピー
题图:彩色代码行的虚化特写,像是抓取脚本与页面选择器的片段

私がこの問題で防御側に立ってきたのは、キャリアの大半にわたる。長年、ひとつの心地よい前提に頼ってきた。大規模にクライアントのデータを収集できる人間はごくわずかだ、という前提だ。防御が優れていたからではない。単純に面倒だったからだ。

その前提はもう成り立たない。理由は正確に述べておきたい。「AIがデータを取れるようになった」は見出しであって分析ではない。役に立つ版はずっと狭い。アマチュアを止めていた個々の技術的な壁が、ちょうど大規模言語モデルが特に得意とするタスクの種類に対応している、ということだ。どの壁がどこで崩れたのかを突き止めること——そこに、防御がまだ機能しているか、それとも気づかないうちに形骸化しているかの差がすべてかかっている。

エンジンを覗いてみよう。

クローラーは実際に何をしているのか

「スクレイピング」という言葉を剥がすと、残るのは4つのステップを繰り返す小さなプログラムだ。ページを要求し、受け取り、必要な部分を抜き出し、次のページへ移る。ブラウザがサイトを開くときも、最初の2つは同じことをしている。クローラーはそれを人間の手を借りず、一度に何千回もやるだけだ。

返ってくるのはHTML——ページの構造を記述した入れ子のタグの木だ。欲しい情報(価格、名前、メールアドレス)は、その木の中のどこかの住所にある。取り出すにはセレクタを書く。短いパターンで、「こういう形の要素を探せ」という意味だ。たとえば.product-card .priceは「各商品カードの中の、priceというタグが付いた要素」という意味になる。

仕組みはこれで全部だ。そして長年、これがそのまま壁でもあった。

# THE OLD WAY - BRITTLE BY DESIGN
# Target a fixed path inside the page's structure.

cards = page.select(".product-card")

for card in cards:
 name = card.select_one(".title").text
 price = card.select_one(".price").text
 save(name, price)

# One redesign later, ".price" is now ".amount".
# Nothing errors loudly. The data just stops. You debug.

3つの厄介な点が、見た目より難しくしている。どれも前より高いプログラミング技能を要求する。ページは読み込まれた後に自分自身を組み立てる。 多くの現代的なサイトは、データを最初のHTMLに詰め込んで送ってこない。ほぼ空のページを送り、JavaScriptを走らせて内部APIから本当の中身を取り出し、描画する。単純な方法でページを要求すると、手に入るのは空の殻だ。データを取るには、ヘッドレスブラウザ——ウィンドウのない本物のブラウザ——を動かしてJavaScriptを実行させるか、ページが呼び出している内部APIを見つけて直接読むか、どちらかになる。どちらの道も、この仕組みが存在することを知っていなければならない。

ページからページへ渡る。 本当のターゲットは1ページではなく、1万ページで、「次へ」ボタンや無限スクロール、さらにリンクを分岐させ続けるリンクの奥に隠れている。迷わず、かつサイトに気づかれない程度に、この構造を渡り歩くこと自体が小さな職人芸だ。

メンテナンス税。 これが静かな殺し屋だ。セレクタは脆い。サイトがクラス名を変えるかレイアウトを組み替えるだけで、クローラーは壊れる——たいていは音もなく——コードに戻る羽目になる。大規模なスクレイピングは一度きりの構築ではない。維持し続けるものだ。そして維持こそ、アマチュアの試みが死ぬ場所だ。

要するに、壁はここにある。 この3つの問題はすべて同じ前提を指している。コードを読み書きでき、HTMLを読め、しかもそれをずっと続けられること。ある巧妙な防御策ではなく、この前提こそが、大規模な収集を比較的少数の人間の手に留めてきた。

AIはこのパイプラインから何を取り除いたのか

真っ先に浮かぶ言い方は、AIが「スクレイピングを簡単にした」だ。間違いではないが、漠然としすぎている。正確に言えば、上に挙げた個々の詰まりどころが、ちょうどAIの得意分野であり、AIはそれらを一つずつ解消していった。

1. 普通の言葉がそのまま動くコードになる

言語モデルは膨大なコードと、膨大なHTMLを見て訓練されている。ページの断片を渡し、日常的な言葉で欲しいものを伝えれば、その内容を取得・解析するセレクタのコードを書いてくれる。操作する人間はDOMを見る必要も、セレクタが何かを知る必要も、コードを開く必要すらない。最初の壁——抽出ロジックを書くこと——は、ただの会話になった。

2. 構造ではなく意味で抽出する

こちらのほうが重要だが、言及されることは少ない。ある値がどこにあるかを指す脆いセレクタを書く代わりに、レンダリング後のページのテキストをモデルに渡し、意味でフィールドを要求する。

# THE NEW WAY - SURVIVES REDESIGNS
# No selectors. Describe the shape you want.

ask_model(
 "Return every product on this page as JSON.",
 "Fields: name, price. Nothing else."
)

# Back comes clean, structured data:
# [ {"name": "...", "price": "..."},
# {"name": "...", "price": "..."} ]

モデルは人間のようにページを読む。価格がどのタグに隠れているかではなく、価格が何であるかを理解する。クラス名が変わり、ブロックが移動し、レイアウト全体が作り直されても、意味は残る。だから抽出はそのまま動く。 これがメンテナンスコストという地雷を静かに解体する。歴史上、クローラーを一時的な職人芸から長期的な投資を要する技能へと変えてきた、あの地雷だ。以前なら数週間ごとに壊れていたクローラーが、今はたいてい肩をすくめて走り続ける。

古いクローラーは位置を指す。新しいクローラーはページを理解する。位置は変わるが、意味は変わらない。

3. 自分でナビゲートするAgent

モデルをループに入れ、ブラウザを与えれば、それはもうコード生成器ではなく操作者になる。ページを見て、何をするか決め、実行し、結果を見て、また繰り返す。知覚、推論、行動、観察。 本物のブラウザを動かしているので、以前は特別な対応が必要だったJavaScript中心のページもそのまま動く。見たものについて推論できるので、硬直したスクリプトならクラッシュしていた予期せぬ事態——突然のポップアップ、9ページ目だけ少し違うレイアウト——は、落ちる原因ではなく回避すべき問題になる。2つ目と3つ目の壁はこうして同時に削られていった。

4. 試行錯誤のコストがほぼゼロになる

これらすべてが今やチャット欄の向こうか、安いAPI呼び出し1回の向こうにある。始めるための技術的な壁はほぼゼロ。1レコード収集するコストは1セントの何分の一かにすぎない。技術的な壁と価格の壁が同時に下がれば、実際にやれる人間の数は小幅な増加ではなく、桁違いに膨らむ。

同じことの、以前と以後

ステップ以前必要だったこと現在
ページ構造の把握HTML と DOM が読めることモデルが代わりに読む
抽出ロジックの記述セレクタとパースコードを書くこと欲しいフィールドを一文で説明するだけ
JavaScript レンダリングページへの対応ヘッドレスブラウザ、または API のリバースエンジニアリングAgent が実ブラウザを直接操作
サイト改修への対応終わりのないデバッグの繰り返しセマンティックベースの抽出ならほぼ耐えられる
技術的ハードルコードが書けるプログラマタイピングして要件を伝えられれば十分
最初の結果が出るまでの時間数時間から数日数分

ゼロから始めるとどうなるか

一行もコードを書いたことがない人を想像してほしい。ある地域のとある業種の全店舗の連絡先を、公開ディレクトリから集めたいと考えている。数年前なら、この思いつきはその場で潰えていた。行動に移す手段が一切なかったからだ。

今なら、チャットツールに目標を説明し、ステップごとに案内してもらう——あるいは全部を agent に丸投げして、そのまま完了させる。そのディレクトリの一覧は実は JavaScript で読み込まれていて、素朴にスクレイピングすると空の殻しか返らない。だが agent は実ブラウザを動かしているので、その違いに気づくことすらない。途中で詳細ページのレイアウトが変わっても、セマンティックベースの抽出は変わらずクリーンなレコードを出力する。

最終的に手に入るのは、ごちゃごちゃしたコピーテキストの山ではなく、構造化された出力だ——そのまま表に放り込める、あるいは次の自動化フローに食わせられるフィールドの行。

この最後の点は吟味に値する。出力は_デフォルトでクリーンかつ構造化されている_。コピーしたテキストの山は厄介ごとでしかない。整ったラベル付きのレコード一万件はデータセットであり、データセットであるということは、別の自動化フローをつなぎ込めるということだ。

なぜ規模が本質なのか

ほとんどのスクレイピングは退屈で、完全に合法だ。価格比較、検索インデックス、学術研究——オープンウェブはそれで成り立っている。米国では、第9巡回区控訴裁判所が hiQ Labs 対 LinkedIn で、公開アクセス可能なデータの収集はコンピュータ不正利用法に違反しないと再確認した。(hiQ は最終的に敗訴した——2022年12月、50万ドルの判決と永久差止命令で和解したが、根拠は契約と不法行為であり、ハッキング関連の条項ではなかった。次に誰かがスクレイピングは「合法」だと言ったら、このことを思い出す価値がある。)

本当に懸念すべきは合法性ではなく、このハードルがもともと悪意しか持たない用途に対して消えたときに何が起きるかだ。

同じ手軽さが、あちこちの公開資料に散らばった個人情報を一掃し、これまで存在しなかった形の整ったデータベースに組み上げてしまう。この点は広く過小評価されている。あなたに関する個々の情報は、公開の場にあるだけなら通常は無害だ。害が生まれるのは結合においてだ。名前、勤務先、メールアドレスの命名規則、位置情報、写真——五つの無関係な場所から集め、同じ行に縫い合わせる。どれ一つとして秘密ではない。危険なのはその組み合わせであり、そして組み合わせこそがかつて最もコストのかかる工程だった。

鋭いのはここだ: 流出したメールアドレス一つは大したことではない。同じアドレスが十万件の中で——ソートされ、構造化され、検索可能な状態で——混ざっていれば、それは製品になる。しかもそれを構築するコストはほぼゼロに近づいている。クリーンで構造化された実在人物のリストと実情報は、フィッシングとソーシャルエンジニアリングの原材料の大部分だ。かつて攻撃者の足を引っ張っていた面倒な組み立て工程こそ、自動化された工程にほかならない。

何が依然として有効で、なぜか

ここからが希望の持てる部分であり、それは上の分析から直接導かれる。

AI は技術的シグナルを消し去ったが、行動的シグナルは消し去っていない。構築者の腕前ではなく、クライアント側の行動の規模と態様に依存する防御は、ほぼ無傷だ。本当に厳しくなっているのは、攻撃者の数が少なくレベルが高いことを前提とした防御だ。

レート制限とスロットリング

一万件のレコードを収集するには、依然として約一万回のリクエストを送る必要がある。AI はこの算術を変えられない。トークンバケット型のレートリミッタ——クライアントごとに安定したリクエストレートのみを許可し、バーストは一律拒否する——は、依然としてスクレイパーをカタツムリ並みに遅くするか、猛攻のなかで自らを露呈させるかのどちらかに追い込む。この層が狙うのはリクエスト量であり、背後に誰がいようとリクエスト量は隠せない。

依然として有効。 AI が言い逃れできない唯一のシグナルは、大量に問い合わせる必要があるという事実だ。

アドレスとネットワークのレピュテーション

リクエストは IP アドレスから来て、アドレスには履歴がある。既知のデータセンター網段からのトラフィックは家庭用ブロードバンドとは見え方が違い、同じ場所から大量のリクエストが湧き出ること自体がマーカーだ。本気の運用者はリクエストを大量のローテーションアドレスに分散させて群衆に紛れ込むため、防御側は個々のアドレスではなくネットワーク全体のパターンに注目するようになっている。あの几帳面な掃討作戦が、分散されただけのことだ。

部分的に無効。 安価な分散手段がアドレス単位のブロックの効果を削ぎ、その分だけ重みが行動シグナルに移っている。

クライアントフィンガープリントとボット検出

実ブラウザは、TLS 接続のネゴシエーション方法やリクエストの順序に一貫した特徴を残す。自動化クライアントは従来、こうした細部で微妙にしくじるか、普通のブラウザには決してない明白な綻びを抱えるかで正体を露呈してきた。これは長らくボット検出の主力手段であり——OWASP の自動化脅威分類では OAT-011 Scraping がそれにあたる——ほとんどの商用ボット管理製品がこれに大きく依存している。

圧力に晒されている。 実ブラウザを動かす agent ツールは、まさにそれ自体が実ブラウザであるという理由だけで、こうした綻びの多くを消し去ってしまう。だからこそ、フィンガープリントだけに頼るわけにはいかないのだ。

行動分析

人間はうろつく。どこかにたどり着いては引き返し、立ち止まり、読み、気まぐれに従う。クローラーは体系的だ。均等に覆い、均等なテンポで進み、狭めるべきところで広げ、実際のセッションにある細かな乱れが一切ない。セッションのをモデル化し、整いすぎたものを弾き出す——これが残された中で最も強力な手段の一つだ。狙っているのが標的そのもの(すべてを持ち去ること)であり、クローラーは自分の目的に反しない限りそれを隠せないからだ。

これは生き残る。 網羅性が破綻であり、そして網羅性こそが狙いだ。

ハニーポットと泥沼

人間が決して見ることもクリックすることもないリンクを仕込む——画面外に置くか、そもそも不可視にする。これを辿るものは自動化されたクローラーだと自ら晒すことになる。さらに、質の低いクライアントには極端に遅い速度で応答するエンドポイントを組み合わせれば、ほぼゼロコストで素朴なクローラー、半端に賢いクローラーを捕まえて潰せる。

今も安価で有効。 慎重な運用者には効かない。だが最近膨れ上がった大量の雑なクローラー群はふるい落とせる。

「公開」を「一括取得可能」とイコールにしない設計

これが構造的な修正であり、最も持続する。1件のレコードを見ることと、全レコードをダウンロードすることは、程度の差ではなく性質の違いであるべきだ。一括性を露呈するビューはログインの後ろに置く。1アカウントが引ける件数を制限する。連続的で推測可能な識別子を配って、数え上げるだけでデータベース全体を列挙できるようにしない。ログイン済みの人間が特定の連絡先を求めたときにだけ、それを表示する。 原則はこうだ。単件アクセスは容易に、一括アクセスは高価に。

投資する価値があるのはこれ。 技術力の高低にかかわらず、全員のコスト構造を変える。

インフラ層も動いている

業界の方向を見ておく価値がある。同じ方向を指しているからだ。 2025年7月、CloudflareはAIクローラーをデフォルトでブロックした最初の主要インフラプロバイダーとなり、新規ドメインへのAIアクセスをオプトアウトからオプトインへと反転させた。1年後、さらに踏み込む。2026年9月15日から、「混在用途」クローラー——1回のリクエストで検索インデックス、エージェント検索、モデル訓練を混ぜるボット——は、広告のあるページではデフォルトでブロックされる。新しいデフォルトは新規顧客、新規サイト、そしてすべての無料プランアカウントに適用される。Cloudflareの理由はこうだ。非人間トラフィックは今やインターネットトラフィックの過半を占める。 これが構造的に何を意味するかに注目してほしい。より優れたフィンガープリンティングではない。私のリストの最後の項目——アクセス設計——をCDN層で実装し、支払いチャネルを添えたものだ。スケールする防御とはコスト構造を変えるものであって、クライアントがどれだけ賢いかを推測しようとするものではない。 この礼儀正しい版であるRobots Exclusion Protocolは、慣習として28年存在した後、2022年にようやく正式なRFCとなった。それでもこれは要請であって制御ではない。意図のシグナルとして扱い、後続の強制措置に正当性を与えるために使う——防御として扱うのではない。

まとめると: 単一の制御手段が壁になることはなく、層状の防御が常に本題だった。新しい問題は、_どの_層を信頼するかだ。AIが「技術的障壁」というシグナルを平坦化した以上、それが平坦化できないシグナルに頼るしかない。純粋な規模、行動の形、そして設計上から一括収集を高価にするアクセス機構だ。法的な側面——利用規約、集約された個人データの保護義務——は、評判を失うものがある相手には現実的な抑止力になるが、それを柵として扱え、錠としてではなく。変えられるのはインセンティブであって、リクエストは止められない。

ウェブサイトを守っているわけではないなら

個人にとって、結論はそれほど大げさではないが、同じくらい確かだ。公開しているものはすべて、永久に、安価に収集され得るものとして扱え。これは技術的にはずっと前から成り立っていた。変わったのは、それをやれる人間の規模だ。かつての慰め——「公開されているのは確かだが、誰がそんな手間をかけるのか」——は静かに成立しなくなった。手間がコストでなくなったからだ。 実際の対処は退屈だが効果がある。共有する前に、それが寄せ集められたら困るかどうかを考える。そして必ず寄せ集められると前提する。

底にあるパターン

一つだけ覚えておいてほしい。その影響はクローラーのはるか先まで及ぶ。 ここにある要素で新しいものは何もない。クローラーは古い。モデルがコードを書くのも魔法ではない。新しいのは、これらの部品が誰にでも扱えるツールにまとめ上げられたことで、そのまとめ上げが、ずっと敷居を高く保ってきた唯一の要件——やり方を知っていること——を取り除いた。 あるタスクが難しさの_主たる_理由を、それが要求する技能に負っていて、あるツールがその技能を消し去るなら、そのタスクは単に簡単になるのではない。到達する人間の層がまったく別物になり、しかもはるかに大きくなる。相手の数が少なく技術が高いことを前提とした防御は、静かに現実とずれていく。行動と規模に目を向けた手段が、すべてを決める。 クローラーは、これから繰り返し出会うことになる転換の初期サンプルにすぎず、しかも異常にクリーンだ。ここでそれを読めるようになっておく価値がある——仕組みがまだ見えているうちに。

出典: HackerNoon← ホームへ戻る