「納品して3か月後、サイトのHTMLが変わってスクレイパーが全部止まった」——受託でデータ収集を扱っていると、誰もが一度は通る道です。近年はAIがページを解釈して構造化データを返してくれるサービスが相次いで登場し、この保守地獄から解放されるのではという期待が高まっています。本記事では代表的なAIスクレイピングツールを、精度・速度・コスト・案件適合性という実務基準で検証し、どこまで実戦投入できるのかを整理します。

従来型スクレイピングの何が「壊れる」のか

まず、AIツールが解こうとしている課題を正確に押さえておきます。従来のスクレイピングはCSSセレクタやXPathでHTML構造を指し示す方式です。これは高速で決定的、しかも実行コストがほぼゼロという圧倒的な利点があります。問題は、指し示している構造が他人の資産だという一点に尽きます。

近年これが特に脆くなった理由は3つあります。1つ目はクラス名の機械生成です。TailwindやCSS Modules、各種フレームワークのビルドによってcss-1x4kt2pのようなハッシュ値がクラス名になり、デプロイのたびに変わります。人間が読んで意味のあるクラス名を前提にした設計が成立しなくなりました。2つ目はA/Bテストとパーソナライズです。同じURLでもユーザーやセッションによってDOMが違い、「ローカルでは動くのに本番で3割失敗する」という再現困難な障害を生みます。3つ目はSPA化で、初期HTMLがほぼ空でありJavaScript実行後にしかデータが存在しないケースが標準になりました。

受託の観点で怖いのは、これらが「開発工数」ではなく「納品後の保守工数」に効いてくることです。10サイトから収集するツールを納品すれば、10サイト分の改修リスクを抱え続けることになります。保守契約の単価が実際の対応工数に見合わなくなった瞬間、その案件は赤字化します。AIスクレイピングツールが本当に評価されるべきなのは、収集できるかどうかではなく、この保守コストを下げられるかどうかです。

API型（Firecrawlなど）の実力と適用範囲

いま最も実用段階にあるのが、URLを投げるとレンダリング済みのMarkdownやJSONが返ってくるAPI型のサービスです。Firecrawlが代表格で、単一ページ取得、サイト全体のクロール、そしてJSONスキーマを指定してLLMに値を抜き出させる抽出機能を持ちます。ヘッドレスブラウザの管理、JavaScript実行、リトライ、レート制御といった「自前で作ると地味に重い」部分がまるごとAPIの内側に隠れているのが最大の価値です。

実務で使って明確に強いと感じるのは次のケースです。第一に、構造がバラバラな多数のサイトから同種の情報を集める案件。100社のコーポレートサイトから会社概要を抜くような仕事は、従来なら100本のパーサが必要でしたが、スキーマを1つ書けば済みます。第二に、RAGや社内ナレッジ基盤の前処理。ノイズを除去したMarkdownが返るため、そのままチャンク分割に流せる品質があります。第三に、PoCや初期見積もりのフェーズ。1日で動くものを見せられる速度は営業上の武器になります。

一方で、導入前に必ず握っておくべき制約もあります。最も重要なのはLLM抽出は非決定的であるという性質です。同じページを2回処理しても、価格が「1,280円」と「1280」で揺れる、単位が勝手に正規化される、複数候補があるときに違う方を選ぶ、といった差異が現実に発生します。文章の収集なら許容できますが、金額・在庫数・IDなど厳密性が要求されるデータでは、後段にPydantic等での型・範囲バリデーションを必ず挟む前提で設計すべきです。次にコストで、多くのサービスがページ単位のクレジット課金であり、抽出機能を使うとさらに上乗せされます（料金体系は変動が激しいため、必ず公式で最新を確認してください）。数千ページ規模なら人件費より安いですが、毎日数万ページを回す常時稼働型では、従来型コードのほうが桁で安くなる領域に入ります。さらに、対象データが外部サービスを経由するという事実は、NDAや個人情報を含む案件では提案段階での確認事項になります。

エージェント型（browser-use / Playwright MCP）はどこまで使えるか

もう一段新しいのが、LLM自身がブラウザを操作するエージェント型です。browser-useのようなライブラリや、Claude等のAIアシスタントにブラウザ操作権限を与えるPlaywright MCPがこれにあたります。仕組みとしては、アクセシビリティツリーやスクリーンショットをLLMに渡し、「次にどの要素をクリックするか」をLLMが判断してPlaywrightに実行させるループです。

強みは、手順が必要なサイトに対応できることです。ログインし、検索条件を入れ、ページネーションを辿り、詳細ページに入る——こうした一連の操作を、セレクタではなく「〇〇で検索して結果一覧を取得して」という指示レベルで書けます。従来なら仕様調査に半日かかっていたサイトの構造把握が、数分で終わることもあります。

ただし、本番の定常バッチにそのまま載せるのは現時点では推奨しません。理由は3つです。速度面では、1操作ごとにLLM往復が発生するため、コードなら数秒の処理が数分かかります。コスト面では、スクリーンショットを含むマルチモーダル入力が積み上がり、1タスクあたりの単価がコード実行とは比較にならない水準になります。そして安定性の面では、途中で誤った要素を選んでループから抜けられなくなる、いわゆる「迷子」が一定確率で起きます。深夜3時に無人で回るジョブとしては、この確率的な失敗が運用負荷に直結します。

したがって実務での正しい置き場所は、本番実行ではなく調査・設計フェーズです。エージェントに一度サイトを踏破させ、どのURLにどんなデータがあるかを把握し、その結果をもとに決定的なコードを書く。この使い方であれば、調査工数を大幅に削減しつつ、本番の安定性は従来どおり確保できます。

受託の現実解：AIは「実行時」ではなく「開発時」と「異常時」に使う

ここまでの検証を踏まえた結論は明快です。AIを毎回のデータ取得に使うのではなく、コードを作る瞬間と、コードが壊れた瞬間に使う。これが現時点で最もコストと安定性のバランスが良い構成です。具体的には次の3層で組みます。

第一に、パーサの自動生成です。AIにHTMLを読ませてセレクタとパース関数を出力させ、それをコードとしてリポジトリに固定します。以後の実行はAIを一切呼ばないため、決定的で高速、追加コストもゼロです。AIの非決定性は生成時の1回に閉じ込められ、人間のレビューを通過した時点で消えます。

第二に、自己修復パイプラインです。収集結果をPydanticでスキーマ検証し、必須項目のnull率が閾値を超えたらアラートを上げます。そこで初めてAIを起動し、保存しておいた過去のHTMLと現在のHTMLの差分、および失敗したセレクタを渡して修正案を生成させ、Pull Requestとして提出させます。人間はレビューとマージだけを行います。従来「サイト改修のたびに調査から着手」だった保守が「PRを確認する」作業に変わり、これが保守契約の採算を守ります。

第三に、フォールバック抽出です。定型ページはコードで処理し、パースに失敗した例外ページだけをAPI型のAI抽出に回します。全体の数%だけがAI経由になるため、コストを抑えつつ取得率を99%台に維持できます。取得率をKPIとして提示できる形になるので、クライアントへの説明もしやすくなります。

最後に、技術以前の前提を1つ。AIツールを使っても、対象サイトの利用規約、robots.txt、著作権法や個人情報保護法上の扱い、そしてアクセス頻度による相手サーバーへの負荷配慮といった責任は、すべて実装者と発注者の側に残ります。ここは自動化できない領域であり、受託者として最初の要件定義で必ず握るべき部分です。

📚 この記事に関連するおすすめ書籍

さらに深く学びたい方に、参考になる書籍をご紹介します。

※ 本サイトはAmazonアソシエイト・プログラムの参加者です。紹介リンクを経由してご購入いただいた場合、手数料を受け取ることがあります。

まとめ

AIスクレイピングツールは、期待されていた「保守が完全に不要になる魔法」ではありませんでしたが、実務を確実に変える道具にはなっています。API型は多サイト横断やRAG前処理といった構造がバラバラな案件で強く、エージェント型は調査フェーズの工数を劇的に削ります。そして最も費用対効果が高いのは、AIを毎回の実行に使うのではなく、パーサ生成・破損検知・自動修復という開発時と異常時に限定して組み込む構成です。決定的なコードの速度と安定性を保ったまま、受託で最も重い保守コストだけをAIに肩代わりさせる。この設計ができるかどうかが、これからのデータ収集案件の採算を分けます。ツール選定の際は、精度だけでなく「壊れたときに誰が何分で直すか」まで含めて評価してください。

AIを活用した業務自動化を導入したい方はnashiまでお問い合わせください。https://nashi-portfolio.netlify.app