n8nでWebスクレイピングを本番運用すると、テストでは動いたワークフローが、ページネーション、アクセス制限、スケジュール実行、サイト変更への対応で止まることがあります。数か月前、あるユーザーから送られてきた n8n のワークフローのスクリーンショットには、14個のノードと6枚ほどの付箋が並び、件名はひとこと「Help.」でした。その方は人気の n8n Webスクレイピングチュートリアルを参考にして、テストサイトで10行のデモを動かすことには成功していました。しかし、実際の競合価格を200ページの製品一覧から取得しようとすると、ページネーションのループが崩れ、403エラーが続き、スケジューラーも最初の火曜日以降は動かなくなっていました。
この事例が示すように、単発の取得と継続運用では、必要な設計が異なります。私は Thunderbit の開発に長年携わり、オートメーションの現場でも多くの経験を積んできましたが、スクレイピングでは最初の取得よりも、その後の運用設計が難しくなるケースを多く見てきました。ページネーション、スケジューリング、アンチボット対策、データ整形、出力に加え、サイトのレイアウト変更を検知して修正する仕組みも必要です。このガイドでは、最初の HTTP Request ノードから、定期実行できる本番向けの n8n Webスクレイピングワークフローまでを順番に解説します。さらに、n8n の DIY アプローチが複雑になった場合に、Thunderbit のような AI 搭載ツールをどのように使い分けられるかも紹介します。
n8n Webスクレイピングの基本構成と本番運用の課題
n8n はオープンソースのローコード型ワークフロー自動化プラットフォームです。たとえば、各ノードが「Webページを取得する」「HTMLを解析する」「Slackに通知する」「Google Sheetsに書き込む」といった役割を持ち、それらをつないで自動処理の流れを作る、視覚的なキャンバスだと考えるとわかりやすいでしょう。重いコーディングは不要ですが、必要な場面では JavaScript を差し込むこともできます。
「n8n Webスクレイピング」とは、n8n の標準機能である HTTP Request ノードと HTML ノード（加えてコミュニティノード）を使って、Webサイトのデータを取得・解析・処理することを指します。基本は2段階です。まず 取得（HTTP Request ノードがURLから生のHTMLを取得）し、次に 解析（HTML ノードがCSSセレクタを使って、商品名、価格、メールアドレスなど必要な項目を抽出）します。
利用規模とコミュニティは拡大しています。2026年4月時点で、n8n は GitHubスター約184k を獲得し、アクティブユーザーは23万人超、コミュニティのワークフローテンプレートは9,166件以上、新しいマイナーリリースもおよそ毎週公開されています。さらに2025年3月には €55M の Series B を調達しました。
一方、本番運用では取得と解析だけでは不十分です。dev.to で最も読まれている n8n のスクレイピングチュートリアル（Lakshay Nasa 氏、"Extract by Zyte" 組織名で公開）は、「Part 2」でページネーションを扱うと予告していました。実際に Part 2 は公開されたものの、著者自身の結論はこうでした。「n8n には HTTP Request ノードの Options にデフォルトの Pagination Mode があるが、少なくとも私の経験では、一般的な Webスクレイピング用途で安定して動作しなかった。」 結局、その方はページネーション処理を有料の外部 API に回しました。一方で、n8n フォーラムでは今も「pagination, throttling, login」が、n8n スクレイピングが“すぐ複雑になる”ポイントとして繰り返し挙げられています。このガイドでは、こうした本番運用上の課題まで扱います。
なぜ n8n Webスクレイピングは営業・業務運用・ECチームに重要なのか
n8n Webスクレイピングは、営業、EC運用、市場調査などの業務データを収集し、その後の処理まで自動化するために使えます。 世界のWebスクレイピング市場 は2025年時点でおよそ10億〜13億ドル規模にあり、2030年には20億〜23億ドルまで成長すると予測されています。ダイナミックプライシングだけでも、EC企業の約 30% が活用しており、ヘッジファンドの65% は代替データに依存しています。その多くはWebから取得したものです。McKinsey は、ダイナミックプライシング導入企業で 売上が2〜5%増加し、利益率が5〜10%改善する と報告しています。
n8n の強みは、データ取得の後工程まで同じワークフローでつなげられる点です。スクレイピングのあとに CRM 更新、Slack通知、スプレッドシート出力、AI分析といった処理を連結できます。
| ユースケース | 恩恵を受ける人 | 取得するデータ | ビジネス成果 |
|---|---|---|---|
| リード獲得 | 営業チーム | 企業ディレクトリ、問い合わせページ | 有望リードをCRMに投入 |
| 競合価格の監視 | EC運用チーム | 商品一覧ページ | 価格をリアルタイムで調整 |
| 不動産物件の追跡 | 不動産エージェント | Zillow、Realtor、地域MLSサイト | 競合より先に新着物件を発見 |
| 市場調査 | マーケティングチーム | レビューサイト、フォーラム、ニュース | トレンドと顧客感情を把握 |
| 仕入先 / SKU の在庫監視 | サプライチェーン運用 | 仕入先の商品ページ | 欠品を回避し、仕入れを最適化 |
第三者サイトからデータを取得する場合は、対象サイトの利用規約、著作権、個人情報の取り扱い、アクセス頻度とサーバー負荷を運用設計に含めます。取得対象と利用目的を決め、必要以上の同時アクセスを避け、業務で使う前にデータの正確性を検証することが重要です。
外部調査や事例からは、適切な用途で自動化を取り入れる効果が示されています。営業組織の92% が2025年にAI投資を増やす予定であり、自動化されたリード育成は9か月で パイプラインを61%成長させた という事例もあります。Webサイトからスプレッドシートへ手作業で転記している場合は、工数とデータ品質を比較したうえで、自動化の対象にできるか検討する価値があります。
n8n Webスクレイピングのツールボックス：主要ノードと選択肢
ワークフローを作る前に、各ノードの役割と適用範囲を整理しておきましょう。Webスクレイピングで重要な n8n ノードは次の通りです。
- HTTP Request ノード: 任意のURLから生のHTMLを取得します。ブラウザがページを開くのに似ていますが、レンダリングはせずコードを返します。GET/POST、ヘッダー、バッチ処理、そして理論上は組み込みのページネーションもサポートします。
- HTML ノード（旧 "HTML Extract"）: CSSセレクタでHTMLを解析し、タイトル、価格、リンク、画像など必要な情報を抽出します。
- Code ノード: データの整形、URLの正規化、重複排除、独自ロジックの実装に JavaScript を書けます。
- Edit Fields（Set）ノード: 後続ノード向けにデータ項目を並べ替えたり、名前を変更したりします。
- Split Out ノード: 配列を個別のアイテムに分解します。
- Convert to File ノード: 構造化データを CSV、JSON などに出力します。
- Loop Over Items ノード: リストを順番に処理します（ページネーションでは重要。後ほど詳しく説明します）。
- Schedule Trigger: cron スケジュールでワークフローを起動します。
- Error Trigger: ワークフロー失敗時に通知します。本番運用では、監視要件に応じて設定します。
JavaScript レンダリングが必要なサイトや強力なアンチボット対策があるサイトでは、コミュニティノードや外部サービスを組み合わせる場合があります。
| アプローチ | 向いている用途 | 必要なスキル | JSレンダリング対応 | アンチボット対策 |
|---|---|---|---|---|
| n8n HTTP Request + HTML ノード | 静的サイト、API | 初級〜中級 | いいえ | 手動（ヘッダー、プロキシ） |
| n8n + ScrapeNinja / Firecrawl のコミュニティノード | 動的サイト、保護されたサイト | 中級 | はい | 利用するサービス・設定による（プロキシローテーション、CAPTCHA） |
| n8n + ヘッドレスブラウザ（Puppeteer） | 複雑なJS操作 | 上級 | はい | 一部対応（構成次第） |
| Thunderbit（AI Web Scraper） | 静的・動的ページをノーコードで扱いたい場面 | 初級 | はい（ブラウザ / クラウド） | Browser / Cloud モードで対応（対象サイト・設定による） |
なお、v2.31.4 時点の n8n には ネイティブのヘッドレスブラウザノードはありません。JavaScript レンダリングが必要なスクレイピングでは、コミュニティノードか外部APIが必要になります。
Thunderbit は私たちのチームが作った AI 搭載の Chrome拡張機能 です。"AI Suggest Fields" をクリックし、次に "Scrape" を押すと、抽出項目の候補を使って構造化データを取得できます。CSSセレクタやノード設定の手間を減らしたい非技術ユーザーに向いていますが、対象サイトの構造やログイン状態、アクセス制限によっては設定の見直しが必要です。このガイドでは、Thunderbit が向く場面と、複雑な後工程を組める n8n が向く場面を分けて紹介します。
ステップバイステップ：最初の n8n Webスクレイピングワークフローを作る
ツールボックスを確認したところで、ゼロから動く n8n スクレイパーを作ってみましょう。例として商品一覧ページを使います。価格監視や競合調査で実際によく使うパターンです。
始める前に:
- 難易度: 初級〜中級
- 所要時間: 約20〜30分
- 必要なもの: n8n（セルフホストまたは Cloud）、対象URL、Chromeブラウザ（CSSセレクタの確認用）
ステップ1：新しいワークフローを作成し、Manual Trigger を追加する
n8n を開き、「New Workflow」をクリックし、「Competitor Price Scraper」のようなわかりやすい名前を付けます。そこに Manual Trigger ノードをドラッグします。（後でスケジュール実行に変更します。）
キャンバス上に1つノードが表示され、「Test Workflow」を押すと実行できる状態になります。
ステップ2：HTTP Request ノードでページを取得する
HTTP Request ノードを追加し、Manual Trigger に接続します。メソッドは GET に設定し、対象URLを入力します（例: https://example.com/products）。
ここが、多くのチュートリアルで省かれる重要ポイントです。本物らしい User-Agent ヘッダーを追加してください。 デフォルトでは n8n は axios/xx を User-Agent として送るため、ボットだとすぐに見抜かれます。「Headers」に次を追加しましょう。
| ヘッダー名 | 値 |
|---|---|
| User-Agent | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 |
| Accept | text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 |
複数URLをスクレイピングする場合は、Batching を有効化し、リクエスト間隔を1〜3秒に設定します。これでレート制限に引っかかりにくくなります。
ノードを実行すると、出力パネルに生のHTMLが表示されるはずです。
ステップ3：HTML ノードでデータを解析する
HTTP Request の出力に HTML ノードを接続します。操作は Extract HTML Content を選びます。
適切な CSS セレクタを見つけるには、Chrome で対象ページを開き、取りたいデータ（たとえば商品タイトル）を右クリックして「Inspect」を選択します。Elements パネルでハイライトされたHTML要素を右クリックし、「Copy → Copy selector」を選びます。
抽出項目は次のように設定します。
| キー | CSSセレクタ | 返す値 |
|---|---|---|
| product_name | .product-title | テキスト |
| price | .price-current | テキスト |
| url | .product-link | 属性: href |
ノードを実行すると、出力に商品名、価格、URL といった構造化データの表が表示されます。
ステップ4：Code ノードで整形・正規化する
生のスクレイピングデータはそのままだと汚れています。価格に余計な空白が入っていたり、URL が相対パスだったり、テキスト末尾に改行が付いていたりします。Code ノードを追加し、HTML ノードに接続しましょう。
以下は、データを整える簡単な JavaScript です。
return items.map(item => {
const d = item.json;
return {
json: {
product_name: (d.product_name || '').trim(),
price: parseFloat((d.price || '').replace(/[^0-9.]/g, '')),
url: d.url && d.url.startsWith('http') ? d.url : `https://example.com${d.url}`
}
};
});
この工程は、本番レベルのデータ品質には欠かせません。これを飛ばすと、スプレッドシートが "$ 29.99\n" のような値だらけになります。
ステップ5：Google Sheets、Airtable、CSV に出力する
Google Sheets ノード（または Airtable、もしくは CSV 用の Convert to File）を接続します。Google アカウントで認証し、スプレッドシートとシートを選択して、Code ノードの出力フィールドを列ヘッダーにマッピングします。
ワークフロー全体を実行すると、整った構造化データがスプレッドシートに入るはずです。
補足ですが、Thunderbit なら無料でデータを Google Sheets、Airtable、Notion、Excel に出力できます。ノードを一切設定せずにデータだけ欲しいなら、かなり便利な近道です。
ページネーションの設計：クリック式と無限スクロール
ページネーションは、単発のデモから複数ページの本番取得へ移る際に、設計が複雑になりやすい工程です。n8n コミュニティフォーラムでも、設定やループ処理に関する相談が見られます。
主なページネーションパターンは2つです。
- クリック式 / URL増分型 —
?page=1、?page=2のようにページ番号が変わる形式 - 無限スクロール — 下へスクロールするとコンテンツが読み込まれる形式（Twitter、Instagram、現代的な商品カタログなど）
n8n でのクリック式ページネーション（Loop ノードによるURL増分）
HTTP Request ノードの Options にある組み込み Pagination は、いかにも便利そうです。ですが実際には信頼性が高くありません。最も有名な n8n スクレイピングチュートリアルの著者（Lakshay Nasa 氏）も試し、「私の経験では安定して動かなかった」 と記しています。フォーラムでも、同じページを繰り返し返す、無限ループになる、最終ページを正しく検出できない、といった報告が続いています。
より確実な方法は、Code ノードでURLリストを明示的に作り、Loop Over Items で順番に回すことです。
やり方は次の通りです。
- Code ノードを追加して、ページURLを生成します。
const base = 'https://example.com/products';
const totalPages = 10; // もしくは動的に検出
return Array.from({length: totalPages}, (_, i) => ({
json: { url: `${base}?page=${i + 1}` }
}));
- Loop Over Items ノードをつなぎ、リストを繰り返し処理します。
- ループの中に HTTP Request ノード（URLは
{{ $json.url }}に設定）と HTML ノードを置き、解析します。 - Wait ノードを入れ、1〜3秒のランダム待機を挟んで 429 エラーを避けます。
- ループ後に結果をまとめ、Google Sheets や CSV に出力します。
全体の流れは Code（URL生成） → Loop Over Items → HTTP Request → HTML → Wait →（ループに戻る）→ 集約 → 出力 です。
注意点として、Loop Over Items ノードには 既知のバグ があり、ネストしたループでアイテムが静かにスキップされることがあります。ページネーションに加えてサブページを展開する場合は、丁寧にテストしてください。"done" の件数が入力件数と一致しないことがあります。
無限スクロールのページネーション：n8n 標準ノードが苦手な理由
無限スクロールのページは、スクロールに応じて JavaScript でコンテンツを読み込みます。HTTP Request ノードが取得できるのは最初のHTMLだけで、JavaScript の実行やスクロールイベントの発火はできません。選択肢は2つです。
- ヘッドレスブラウザ系のコミュニティノード（例: n8n-nodes-puppeteer や n8n-playwright）を使って、ページをレンダリングし、スクロールを再現する。
- スクレイピングAPI（ScrapeNinja、Firecrawl、ZenRows など）を使い、JSレンダリングを有効にする。
どちらも構成の複雑さが大きく増します。サイトごとに 30〜60分以上のセットアップに加え、継続的な保守も必要です。
Thunderbitでページネーション設定を簡略化する
Thunderbitでは、n8nのDIYワークフローとは異なる方法でページネーションを処理します。対象サイトの構造や実行モードによって対応範囲が異なるため、次の表は用途を比較する目安です。
| 機能 | n8n（DIYワークフロー） | Thunderbit |
|---|---|---|
| クリック式ページネーション | 手動でループノードを設定し、URLを増分 | 自動 — ページネーションを検出して追従（対象ページの構造・設定による） |
| 無限スクロールページ | ヘッドレスブラウザ + コミュニティノードが必要 | Browser / Cloud モードで対応（対象サイトによる） |
| セットアップ工数 | 1サイトあたり30〜60分 | 2クリック |
| 1バッチあたりのページ数 | 逐次処理（1ページずつ） | 同時に50ページ（Cloud Scraping。プラン・対象サイトによる） |
10件のページネーションされた一覧から200商品ページを取るようなケースでは、対象サイトや設定によって所要時間が変わります。n8nでは丸一日かかることがある一方、Thunderbitでは2分ほどで処理できるケースがあります。どちらかを一律に優先するのではなく、後工程の複雑さ、対象サイトとの相性、保守方法を基準に選びます。
cronで定期実行するn8n Webスクレイピングパイプライン
単発の取得に加えて、n8nではスケジュールに沿ってデータ収集を繰り返すワークフローを構成できます。ここでは Schedule Trigger を使い、取得、整形、出力、エラー通知までを定期実行する方法を説明します。
毎日の価格監視パイプラインを作る
Manual Trigger を Schedule Trigger ノードに置き換えます。n8n の UI で「Every day at 8:00 AM」と設定してもよいですし、cron 式（0 8 * * *）でも構いません。
ワークフローの全体構成は次の通りです。
- Schedule Trigger（毎日8時）
- Code ノード（ページネーション付きURLを生成）
- Loop Over Items → HTTP Request → HTML → Wait（全ページを取得）
- Code ノード（データ整形、価格の正規化）
- Google Sheets（新規行を追記）
- IF ノード（価格がしきい値を下回ったか？）
- Slack（該当時にアラート送信）
さらに、失敗時に Slack へ通知する Error Trigger ワークフローも並行して作っておきましょう。そうしないと、セレクタが壊れたとき（実際にはよく壊れます）、気づくのは3週間後、レポートが空っぽになったときです。
見落とされがちな注意点が2つあります。
- n8n は24時間365日稼働している必要があります。 ノートPC上のセルフホストでは、フタを閉じると動きません。サーバー、Docker、または n8n Cloud を使いましょう。
- ワークフローを編集したら、一度オフにしてから再度オンにしてください。 n8n Cloud には 既知の問題 があり、編集後にスケジューラーの登録が静かに外れてしまうことがあります。エラー通知はありません。
週次のリード抽出パイプラインを作る
考え方は同じで、対象だけ変えます。Schedule Trigger（毎週月曜9時） → HTTP Request（企業ディレクトリ） → HTML（氏名、電話番号、メールを抽出） → Code（重複排除、書式整形） → Airtable または HubSpot に送信。
見落とされがちなのは、保守コストです。ディレクトリサイトのレイアウトが変わると CSS セレクタが壊れ、ワークフローは静かに失敗します。HasData によると、セレクタベースのパイプラインでは、毎年の継続保守に初期構築時間の 30〜60% を見込むべきだそうです。20サイトほど運用し始めると、この負担は本当に重くなります。
Thunderbit の Scheduled Scraper：ノーコードの代替案
Thunderbit の Scheduled Scraper では、「毎週月曜9時」のように自然な言葉で間隔を指定し、URLを入力して「Schedule」をクリックして定期実行を設定します。クラウドで動作するため、利用者側でサーバーや cron 式を管理する手間を減らせます。実行条件や利用可能な頻度は、プランと対象サイトによって異なります。
| 項目 | n8n の定期実行ワークフロー | Thunderbit Scheduled Scraper |
|---|---|---|
| スケジュール設定 | cron 式または n8n のUI | 自然言語で指定（対応する間隔はプラン・設定による） |
| データ整形 | 手動の Code ノードが必要 | AI による整形・ラベル付け・翻訳を利用可能（対応範囲は設定による） |
| 出力先 | 統合ノードが必要 | Google Sheets、Airtable、Notion、Excel（利用条件はプランによる） |
| ホスティング要件 | セルフホストまたは n8n Cloud | 利用者側のホスティングは不要 — クラウドで実行 |
| サイト変更時の保守 | セレクタが壊れ、手動修正が必要 | AI がページ構造の読み取りを支援（変更内容により再設定が必要な場合がある） |
固定の CSS セレクタに依存しない構成では、レイアウト変更に伴う修正負担を減らせる場合があります。ただし、すべての変更を自動で処理できるとは限らないため、定期実行では取得件数や必須項目を記録し、前回結果との差分を検証します。
n8n のスクレイパーがブロックされたとき：アンチボット対策のトラブルシューティング
ページネーションの次に切り分けが必要になるのが、リクエストのブロックです。User-Agent ヘッダーの変更だけで解決できるケースもありますが、TLSフィンガープリントやJavaScriptチャレンジ、行動分析が使われているサイトでは、それだけでは不十分です。
Imperva の 2025 Bad Bot Report によると、ボットは現在インターネットトラフィック全体の51% を占め、そのうち 37% は悪意のあるものです。Cloudflare、Akamai、DataDome、HUMAN、PerimeterX といったアンチボット事業者は、TLSフィンガープリント、JavaScriptチャレンジ、行動分析で対抗しています。n8n の HTTP Request ノードは内部で Axios ライブラリを使っており、ブラウザとは異なる TLS フィンガープリントとして識別される場合があります。User-Agent を変えても解決しないときは、JA3/JA4 ハッシュ など、HTTP ヘッダー以外の判定要素も切り分ける必要があります。
アンチボット対策の判断フロー
単なる「User-Agent を入れる」ではなく、体系的に切り分けましょう。
リクエストがブロックされる？
- 403 Forbidden → User-Agent + Accept ヘッダーを追加（上のステップ2を参照） → まだブロックされる？
- はい → レジデンシャルプロキシのローテーションを追加 → まだブロックされる？
- はい → スクレイピングAPI（ScrapeNinja、Firecrawl、ZenRows）か、ヘッドレスブラウザ系コミュニティノードへ切り替え
- いいえ → 続行
- いいえ → 続行
- はい → レジデンシャルプロキシのローテーションを追加 → まだブロックされる？
- CAPTCHA が出る → CAPTCHA 解決機能付きのスクレイピングAPIを使う（例: n8n の Cloudflare Turnstile 回避ワークフロー）
- 空のレスポンス（JSレンダリングサイト） → ヘッドレスブラウザ系コミュニティノード、またはJSレンダリング対応のスクレイピングAPIを使う
- レート制限（429エラー） → HTTP Request ノードでバッチ処理を有効化し、バッチ間隔を2〜5秒に設定し、同時実行数を下げる
もう1つの落とし穴として、n8n には 既知の HTTPS プロキシバグ があり、HTTP Request ノードが HTTP プロキシ経由で HTTPS を正しくトンネルできないことがあります。同じコンテナ内で curl は問題なくても、Axios が TLS ハンドシェイクで失敗します。プロキシを使っていて原因不明の接続エラーが出る場合、これが理由かもしれません。
Thunderbit がアンチボット環境に対応しやすい理由
Thunderbit には2つのスクレイピングモードがあり、対象ページの公開状態やログイン要件に応じて使い分けます。
- Browser Scraping: Chrome ブラウザ内で動作し、利用中のセッションCookie、ログイン状態、ブラウザ環境を使ってページへアクセスします。サーバー側リクエストとは異なる条件で取得できますが、対象サイトの制限を必ず回避できるわけではありません。
- Cloud Scraping: 公開サイト向けに、Thunderbit のクラウド環境で取得を実行します。一度に50ページ まで対応可能です。利用できる同時実行数や対象サイトは、プランとページの状態によって異なります。
アンチボット対策への対応工数がデータ分析の時間を上回る場合は、対象サイトとの相性、必要な認証、運用コストを比べたうえで選択肢にできます。
n8n Webスクレイピングが向く場面と、別の手段を検討する場面
n8n は、スクレイピング後の処理まで含めてワークフローを構築できるプラットフォームです。一方、対象サイト、必要な保守、担当者の技術スキルによっては、別の手段が適する場合があります。フォーラムでも、「n8n で Webスクレイパーを作るのはどれくらい難しいですか？」 や 「n8n と相性のいいスクレイピングツールはどれですか？」 といった質問が見られます。ここでは、作業内容を基準に使い分けを整理します。
n8n Webスクレイピングが特に強い場面
- 複数ステップのワークフロー で、スクレイピングの後に CRM 更新、Slack通知、AI分析、DB書き込みなどを行う場合。これが n8n の本領です。
- スクレイピングが大きな自動化チェーンの1工程にすぎないケース。例: 取得 → 補完 → フィルタ → CRM 送信。
- CSSセレクタやノードベースのロジックに慣れている技術ユーザー。
- 取得後に独自のデータ変換が必要な場面。
n8n Webスクレイピングがつらくなりやすい場面
- とにかく早くデータが欲しい非技術ユーザー。ノード設定、CSSセレクタの発見、デバッグの流れは、ビジネスユーザーにはかなりハードです。
- 強力なアンチボット対策があるサイト。プロキシやAPIの追加で、コストも複雑さも増えます。
- サイトのレイアウト変更が多いケース。CSSセレクタが壊れ、ワークフローが静かに失敗します。
- いろいろな種類のサイトを大量にスクレイピングする場合。サイトごとに個別のセレクタ設定が必要です。
- サブページの補完処理。n8n 内で別のサブワークフローを組む必要があります。
n8n vs. Thunderbit vs. Python スクリプトの比較
次の表は、対象サイト、後工程、担当者の技術スキルを基準に3つの方法を比較したものです。時間や保守負担はサイト構造と運用条件によって変わります。
| 比較項目 | n8n のDIYスクレイピング | Thunderbit | Pythonスクリプト |
|---|---|---|---|
| 必要な技術レベル | 中級（ノード + CSSセレクタ） | 初級（AI が項目を提案） | 高い（コーディング） |
| 新しいサイトごとのセットアップ時間 | 30〜90分（構成による） | 約2分（対象サイト・項目数による） | 1〜4時間（実装要件による） |
| アンチボット対応 | 手動（ヘッダー、プロキシ、API） | Browser / Cloud モードで対応（対象サイトによる） | 手動（ライブラリ） |
| サイト変更時の保守 | セレクタを手動更新 | AI が構造認識を支援（変更内容により再設定が必要） | 手動でコード修正 |
| 複数ステップのワークフロー対応 | とても強い（本領） | Sheets/Airtable/Notion へ出力 | カスタムコードが必要 |
| 大規模運用時のコスト | n8nホスティング + プロキシ/API費 | クレジット制（1行あたり約1クレジット。プラン・機能により異なる） | サーバー + プロキシ費 |
| サブページ補完 | 手動 — 別サブワークフローを作成 | 1クリックでサブページ取得（対象ページ・設定による） | カスタム実装 |
使い分けの基準は、スクレイピング後の処理と必要な制御範囲です。スクレイピングが複雑な自動化チェーンの一部なら n8n を使う。 ワークフローを組まずにデータ取得を短時間で試したい場合は Thunderbit、最大限の制御が必要で開発リソースがある場合は Python が候補になります。競合ではなく、補完関係です。
実際にコピーできる n8n Webスクレイピングワークフロー例
フォーラムではよく、「これらを複数ステップのワークフローにつないだ人はいますか？」 という質問が出ます。ここでは、今日から組める実例を3つ紹介します。
ワークフロー1：EC競合価格モニター
目的: 競合価格を毎日追跡し、値下げがあれば通知する。
ノードチェーン: Schedule Trigger（日次、8時） → Code（ページネーション付きURL生成） → Loop Over Items → HTTP Request → HTML（商品名、価格、在庫状況を抽出） → Wait（2秒） →（ループへ戻る）→ Code（整形、価格の正規化） → Google Sheets（行を追記） → IF（価格がしきい値未満か？） → Slack（通知送信）
複雑さ: 8〜10ノード、競合サイト1件あたり30〜60分のセットアップ。
Thunderbit の近道: Thunderbit の Scheduled Scraper と 人気ECサイト向けの即利用テンプレート は、対象サイトがテンプレートや機能の対応範囲に入る場合、同様の価格データ取得を短時間で試す選択肢になります。Google Sheetsへの出力条件は利用プランによって異なります。
ワークフロー2：営業リード獲得パイプライン
目的: 企業ディレクトリを毎週スクレイピングし、リードを整形・分類してCRMへ送る。
ノードチェーン: Schedule Trigger（毎週月曜9時） → HTTP Request（ディレクトリ一覧ページ） → HTML（氏名、電話、メール、住所を抽出） → Code（重複排除、書式整形） → OpenAI/Gemini ノード（業界分類） → HubSpot ノード（コンタクト作成）
注: n8n にはネイティブの HubSpot ノード があり、CRM 送信には便利です。ただし、スクレイピングと整形は依然として手動で CSS セレクタを扱う必要があります。
Thunderbit の近道: Thunderbit の無料 2026年に評価した25のメールエクストラクター：本当に使えるツールだけ と電話番号抽出機能は、対応する公開ページから連絡先項目を取得したい場合に利用できます。AI ラベル付けも、抽出対象や設定によってリード分類に使えます。フルの自動化チェーンが不要な場合は、n8n と比較する候補になります。連絡先データを扱う際は、取得元の規約、利用目的、個人情報の取り扱いを事前に整理します。
ワークフロー3：新着物件トラッカー
目的: Zillow や Realtor.com の新着物件を毎週チェックし、ダイジェストメールを送る。
ノードチェーン: Schedule Trigger（毎週） → HTTP Request（物件一覧ページ） → HTML（住所、価格、間取り、リンクを抽出） → Code（整形） → Google Sheets（追記） → Code（前週データと比較し、新着物件をフラグ） → IF（新着あり？） → Gmail/SendGrid（ダイジェスト送信）
注: Thunderbit には Zillow など向けの即利用スクレイパーテンプレート があり、テンプレートの対応範囲ではCSSセレクタの設定を減らせます。取得→比較→通知までの完全な自動化を求めるなら n8n が有効で、対応する物件データの抽出を先に試したい場合は Thunderbit が候補になります。
さらに他のワークフロー例を見たい方は、n8n のコミュニティライブラリに AI + アラート付きの価格監視、Google Sheets と連携した不動産スクレイピング、ScrapeNinja + AI で任意のWebページを構造化JSONにする といったテンプレートがあります。
n8n Webスクレイピングを安定運用するためのコツ
本番運用では、初期構築だけでなく、取得結果の監視、サイト変更への対応、セレクタの更新、エラー通知を継続業務として設計する必要があります。
バッチ処理と遅延でレート制限を避ける
HTTP Request ノードでバッチ処理を有効にし、バッチ間を1〜3秒空けます。同時リクエスト数が多いと、429エラーやIP単位の制限が発生しやすくなります。対象サイトの応答と利用条件を見ながら、間隔と同時実行数を調整し、サーバーへ過度な負荷をかけない設定にします。
ワークフロー実行を監視し、静かな失敗を見逃さない
n8n の Executions タブで失敗実行を確認します。サイトのレイアウトが変わると、スクレイピング結果が空欄で返ってくることがあります。ワークフロー上は「成功」でも、スプレッドシートが空白だらけ、という状態です。
本番運用では、失敗時に Slack やメールへ通知する Error Trigger ワークフローを用意します。さらに、実行成功だけでなく、取得件数が0件になっていないか、価格やURLなどの必須項目が空欄になっていないかも判定条件に含めると、データ上の失敗を検知しやすくなります。
CSSセレクタは外部管理して更新しやすくする
CSSセレクタは Google Sheets や n8n の環境変数に保存し、ワークフロー自体を編集せずに更新できるようにします。サイトのレイアウトが変わっても、1か所直せば済みます。
AI 搭載スクレイパーへ切り替えるタイミングを見極める
CSSセレクタの更新やアンチボット対策にかかる時間が、取得データを活用する時間を上回る場合は、Thunderbit のような AI 搭載ツールを比較対象にできます。AIによるページ構造の読み取りは保守負担を減らせる場合がありますが、サイト変更の内容や取得項目によっては設定の見直しが必要です。
補完的なスタック構成 も選択肢です。Thunderbit が抽出レイヤーを担当して Google Sheets や Airtable に出力し、n8n がその新しい行を Sheets/Airtable のネイティブトリガーで受け取ります。その後、n8n が CRM 更新、通知、条件分岐、複数システムへの振り分けを担う構成です。役割を分けることで、抽出部分と後工程を別々に検証・保守できます。
まとめ：チームに合ったパイプラインを作ろう
n8n Webスクレイピングは、スクレイピングをCRM更新、Slack通知、AI補完、条件分岐などにつなげたい場合に向いています。一方で、技術的なセットアップに加え、ページネーション、アンチボット対策、スケジュール実行、サイト変更への継続的な対応が必要です。このガイドでは、最初のワークフローから、ページネーション、定期実行、トラブルシューティング、用途別の選び方、実践例までを説明しました。
選択の目安は次の通りです。
- n8n を使う: スクレイピングが、CRM 更新、Slack通知、AI補完、条件分岐といった複雑な多段自動化の一部であるとき。
- Thunderbit を使う: ワークフローを組まずにデータ抽出を始めたいとき。AI が項目提案、ページネーション、アンチボット、出力まで2クリックで処理します。対象サイトや実行モードによって対応範囲は異なります。
- Python を使う: 最大限の制御が必要で、開発リソースがあるとき。
抽出と後工程の両方が必要なチームでは、抽出を Thunderbit、オーケストレーションを n8n に分ける構成も候補になります。まず対象URLと必要な項目を限定し、取得件数、必須項目、出力形式を検証すると、どの構成が運用に合うか判断しやすくなります。Thunderbit の無料プラン と Chrome拡張機能 を利用する場合も、現在のプラン条件と対象サイトへの適合性を比較してから定期運用へ広げてください。動画での手順やワークフローのアイデアは、Thunderbit の YouTube チャンネル も参考にしてください。
AI Webスクレイピングに Thunderbit を試す Get Started Free
よくある質問
n8n で JavaScript が多用されたサイトをスクレイピングできますか？
標準の HTTP Request ノードだけでは、JavaScriptの実行後に表示される内容を取得できません。HTTP Request ノードは生のHTMLを取得するためです。JSレンダリングされたサイトには、n8n-nodes-puppeteer のようなコミュニティノード、または JavaScript をサーバー側でレンダリングするスクレイピングAPI連携（ScrapeNinja、Firecrawl など）が必要です。Thunderbit では Browser / Cloud の各モードでJSを使うページに対応できますが、取得できる内容は対象サイト、ログイン状態、実行モードによって異なります。
n8n の Webスクレイピングは無料ですか？
n8n のセルフホスト版は無料でオープンソースです。n8n Cloud は以前無料枠がありましたが、2026年4月時点では 14日間のトライアルのみで、その後は月額24ドルから（2,500 executions）です。保護されたサイトをスクレイピングする場合、レジデンシャルプロキシ（5〜15ドル/GB）や、利用量に応じて月額49〜200ドル超のスクレイピングAPIなど、追加コストがかかることもあります。
n8n の Webスクレイピングは Thunderbit とどう違いますか？
n8n は、スクレイピングが大きなワークフローの一部になっている多段自動化に向いています（例: 取得 → 補完 → フィルタ → CRM送信 → Slack通知）。Thunderbit は、AI による項目検出、ページネーション処理、ページ構造の読み取り支援などを使い、ノーコードで抽出を始めたい場合に向いています。サイト変更時の調整が軽くなる場合がありますが、対象ページや変更内容によっては設定の見直しが必要です。抽出を Thunderbit、オーケストレーションを n8n に分ける構成も選択肢になります。
ログインが必要なサイトも n8n でスクレイピングできますか？
はい。ただし、HTTP Request ノードで Cookie やセッショントークンを設定する必要があり、認証方式の変更に応じた保守が必要です。Thunderbit の Browser Scraping モードでは、ログイン済みの Chrome セッションを利用して、ブラウザ上で閲覧できるページを取得できる場合があります。対応範囲は対象サイトの認証方式、権限、ページ構造によって異なります。
n8n のスクレイパーが突然データを返さなくなったら、どうすればいいですか？
まず n8n の Executions タブで、HTTPステータス、エラー内容、取得件数を確認します。よくある原因の1つは、サイトのレイアウト変更で CSS セレクタが合わなくなることです。ワークフローは「成功」していても、必要な項目が空欄で返る場合があります。Chrome の Inspect で対象要素とセレクタを照合し、ワークフロー（または外部管理しているセレクタ表）を更新して再テストします。アンチボット対策によるブロックが疑われる場合は、ステータスコードとレスポンス内容を記録し、このガイドのトラブルシューティング手順で切り分けます。レイアウト変更への対応工数が大きい場合は、ページ構造の読み取りをAIが支援する Thunderbit のようなスクレイパーも比較対象になります。ただし、変更内容によっては抽出設定の見直しが必要です。
さらに詳しく知る
