n8nでWebスクレイピングを極める：自動化ワークフロー完全ガイド

数か月前、あるユーザーから n8n のワークフローのスクリーンショットが送られてきました。14個のノード、6枚ほどの付箋、そして件名はひとこと「Help.」でした。その方は人気の n8n Webスクレイピングチュートリアルを参考にして、テストサイトでは見栄えのいい10行のデモを動かすことに成功していました。ところが、実際の競合価格を200ページの製品一覧から取得しようとした瞬間、ページネーションのループは崩れ、403エラーが出続け、さらに静かなスケジューラーは最初の火曜日以降まったく動かなくなっていたのです。

この「デモ」と「本番運用」のあいだにある大きな壁こそ、多くの n8n スクレイピング案件が失敗する原因です。私は の開発に長年携わり、オートメーションの現場でも多くの経験を積んできましたが、はっきり言えます。スクレイピングそのものは、たいてい一番むずかしい部分ではありません。むしろ、最初の1回の取得が成功した“あと”に待っている作業こそがやっかいなのです。ページネーション、スケジューリング、アンチボット対策、データ整形、出力、そして最大の難所である「サイトのレイアウトが今四半期で3回目の変更をしたときの保守」。このガイドでは、最初の 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 は を獲得し、アクティブユーザーは23万人超、コミュニティのワークフローテンプレートは9,166件以上、新しいマイナーリリースもおよそ毎週公開されています。さらに2025年3月には を調達しました。勢いはかなりあります。

ただし、あまり語られない“谷”があります。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スクレイピングは、開発者の趣味ではありません。ビジネスツールです。 は2025年時点でおよそ10億〜13億ドル規模にあり、2030年には20億〜23億ドルまで成長すると予測されています。ダイナミックプライシングだけでも、EC企業の約 が活用しており、 は代替データに依存しています。その多くはWebから取得したものです。McKinsey は、ダイナミックプライシング導入企業で と報告しています。

n8n の本当の強みはここにあります。単にデータを取ってくるだけではなく、その“次”までつなげられることです。n8n なら、スクレイピングのあとに CRM 更新、Slack通知、スプレッドシート出力、AI分析といった処理を、1つのワークフローで連結できます。

数字が示す通り、ROI は本物です。 が2025年にAI投資を増やす予定であり、自動化されたリード育成は9か月で という事例もあります。いまだに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 レンダリングが必要なサイトや強力なアンチボット対策があるサイトでは、コミュニティノードが必要になります。

なお、v2.15.1 時点の n8n には ネイティブのヘッドレスブラウザノードはありません。JavaScript レンダリングが必要なスクレイピングでは、コミュニティノードか外部APIが必須です。

Thunderbit についても少しだけ触れておきます。これは私たちのチームが作った AI 搭載の です。"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」に次を追加しましょう。

複数URLをスクレイピングする場合は、Batching を有効化し、リクエスト間隔を1〜3秒に設定します。これでレート制限に引っかかりにくくなります。

ノードを実行すると、出力パネルに生のHTMLが表示されるはずです。

ステップ3：HTML ノードでデータを解析する

HTTP Request の出力に HTML ノードを接続します。操作は Extract HTML Content を選びます。

適切な CSS セレクタを見つけるには、Chrome で対象ページを開き、取りたいデータ（たとえば商品タイトル）を右クリックして「Inspect」を選択します。Elements パネルでハイライトされたHTML要素を右クリックし、「Copy → Copy selector」を選びます。

抽出項目は次のように設定します。

ノードを実行すると、出力に商品名、価格、URL といった構造化データの表が表示されます。

ステップ4：Code ノードで整形・正規化する

生のスクレイピングデータはそのままだと汚れています。価格に余計な空白が入っていたり、URL が相対パスだったり、テキスト末尾に改行が付いていたりします。Code ノードを追加し、HTML ノードに接続しましょう。

以下は、データを整える簡単な JavaScript です。

1return items.map(item => {
2  const d = item.json;
3  return {
4    json: {
5      product_name: (d.product_name || '').trim(),
6      price: parseFloat((d.price || '').replace(/[^0-9.]/g, '')),
7      url: d.url && d.url.startsWith('http') ? d.url : `https://example.com${d.url}`
8    }
9  };
10});

この工程は、本番レベルのデータ品質には欠かせません。これを飛ばすと、スプレッドシートが "$ 29.99\n" のような値だらけになります。

ステップ5：Google Sheets、Airtable、CSV に出力する

Google Sheets ノード（または Airtable、もしくは CSV 用の Convert to File）を接続します。Google アカウントで認証し、スプレッドシートとシートを選択して、Code ノードの出力フィールドを列ヘッダーにマッピングします。

ワークフロー全体を実行すると、整った構造化データがスプレッドシートに入るはずです。

補足ですが、。ノードを一切設定せずにデータだけ欲しいなら、かなり便利な近道です。

どの n8n Webスクレイピングチュートリアルも省略する部分：完全なページネーション対応

ページネーションは、n8n スクレイピング記事の最大の抜け穴であり、n8n コミュニティフォーラムで最も多い不満の種でもあります。

主なページネーションパターンは2つです。

1. クリック式 / URL増分型 — ?page=1、?page=2 のようにページ番号が変わる形式
2. 無限スクロール — 下へスクロールするとコンテンツが読み込まれる形式（Twitter、Instagram、現代的な商品カタログなど）

n8n でのクリック式ページネーション（Loop ノードによるURL増分）

HTTP Request ノードの Options にある組み込み Pagination は、いかにも便利そうです。ですが実際には信頼性が高くありません。最も有名な n8n スクレイピングチュートリアルの著者（Lakshay Nasa 氏）も試し、「私の経験では安定して動かなかった」 と記しています。フォーラムでも、、、最終ページを正しく検出できない、といった報告が続いています。

より確実な方法は、Code ノードでURLリストを明示的に作り、Loop Over Items で順番に回すことです。

やり方は次の通りです。

1. Code ノードを追加して、ページURLを生成します。

1const base = 'https://example.com/products';
2const totalPages = 10; // もしくは動的に検出
3return Array.from({length: totalPages}, (_, i) => ({
4  json: { url: `${base}?page=${i + 1}` }
5}));

2. Loop Over Items ノードをつなぎ、リストを繰り返し処理します。
3. ループの中に HTTP Request ノード（URLは {{ $json.url }} に設定）と HTML ノードを置き、解析します。
4. Wait ノードを入れ、1〜3秒のランダム待機を挟んで 429 エラーを避けます。
5. ループ後に結果をまとめ、Google Sheets や CSV に出力します。

全体の流れは Code（URL生成） → Loop Over Items → HTTP Request → HTML → Wait →（ループに戻る）→ 集約 → 出力 です。

注意点として、Loop Over Items ノードには があり、ネストしたループでアイテムが静かにスキップされることがあります。ページネーションに加えてサブページを展開する場合は、丁寧にテストしてください。"done" の件数が入力件数と一致しないことがあります。

無限スクロールのページネーション：n8n 標準ノードが苦手な理由

無限スクロールのページは、スクロールに応じて JavaScript でコンテンツを読み込みます。HTTP Request ノードが取得できるのは最初のHTMLだけで、JavaScript の実行やスクロールイベントの発火はできません。選択肢は2つです。

• ヘッドレスブラウザ系のコミュニティノード（例: や ）を使って、ページをレンダリングし、スクロールを再現する。
• スクレイピングAPI（ScrapeNinja、Firecrawl、ZenRows など）を使い、JSレンダリングを有効にする。

どちらも構成の複雑さが大きく増します。サイトごとに 30〜60分以上のセットアップに加え、継続的な保守も必要です。

Thunderbit はページネーションを設定なしで処理する

少しひいき目はありますが、この差はかなり大きいです。

10件のページネーションされた一覧から200商品ページを取るようなケースなら、n8n では丸一日かかることもあります。Thunderbit なら2分ほどです。これは n8n を否定しているのではなく、用途が違うという話です。

設定したらあとは任せる：cron 起動の n8n Webスクレイピングパイプライン

単発のスクレイピングも便利ですが、n8n Webスクレイピングの真価は、繰り返し自動でデータを集め続けられることにあります。意外にも、n8n のスクレイピング解説で Schedule Trigger を取り上げているものはほとんどありません。にもかかわらず、コミュニティでは最も要望の多い機能のひとつです。

毎日の価格監視パイプラインを作る

Manual Trigger を Schedule Trigger ノードに置き換えます。n8n の UI で「Every day at 8:00 AM」と設定してもよいですし、cron 式（0 8 * * *）でも構いません。

ワークフローの全体構成は次の通りです。

1. Schedule Trigger（毎日8時）
2. Code ノード（ページネーション付きURLを生成）
3. Loop Over Items → HTTP Request → HTML → Wait（全ページを取得）
4. Code ノード（データ整形、価格の正規化）
5. Google Sheets（新規行を追記）
6. IF ノード（価格がしきい値を下回ったか？）
7. 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 によると、セレクタベースのパイプラインでは、毎年の継続保守に初期構築時間の を見込むべきだそうです。20サイトほど運用し始めると、この負担は本当に重くなります。

Thunderbit の Scheduled Scraper：ノーコードの代替案

Thunderbit の Scheduled Scraper では、「毎週月曜9時」のように自然な言葉で間隔を指定し、URLを入力して「Schedule」をクリックするだけです。クラウドで動作するため、ホスティングも cron 式も、静かな登録解除もありません。

特に重要なのは最後の行です。フォーラムでは、「サイトのレイアウトが変わるまでは、どれも問題ない」 という声がよくあります。Thunderbit の AI ベースのアプローチなら、固定の CSS セレクタに依存しないため、そのストレスを大きく減らせます。

n8n のスクレイパーがブロックされたとき：アンチボット対策のトラブルシューティング

ページネーションの次に多い悩みが、ブロックされることです。定番アドバイスの「User-Agent ヘッダーを追加しましょう」は、ハリケーンに網戸を当てるようなものです。

Imperva の 2025 Bad Bot Report によると、 を占め、そのうち は悪意のあるものです。Cloudflare、Akamai、DataDome、HUMAN、PerimeterX といったアンチボット事業者は、TLSフィンガープリント、JavaScriptチャレンジ、行動分析で対抗しています。n8n の HTTP Request ノードは内部で Axios ライブラリを使っており、ブラウザとは異なる、識別しやすい TLS フィンガープリントを出します。User-Agent を変えても意味はなく、 によって HTTP ヘッダーを読む前に見抜かれてしまいます。

アンチボット対策の判断フロー

単なる「User-Agent を入れる」ではなく、体系的に切り分けましょう。

リクエストがブロックされる？

• 403 Forbidden → User-Agent + Accept ヘッダーを追加（上のステップ2を参照） → まだブロックされる？
  • はい → レジデンシャルプロキシのローテーションを追加 → まだブロックされる？
    • はい → スクレイピングAPI（ScrapeNinja、Firecrawl、ZenRows）か、ヘッドレスブラウザ系コミュニティノードへ切り替え
    • いいえ → 続行
  • いいえ → 続行
• CAPTCHA が出る → CAPTCHA 解決機能付きのスクレイピングAPIを使う（例: ）
• 空のレスポンス（JSレンダリングサイト） → ヘッドレスブラウザ系コミュニティノード、またはJSレンダリング対応のスクレイピングAPIを使う
• レート制限（429エラー） → HTTP Request ノードでバッチ処理を有効化し、バッチ間隔を2〜5秒に設定し、同時実行数を下げる

もう1つの落とし穴として、n8n には があり、HTTP Request ノードが HTTP プロキシ経由で HTTPS を正しくトンネルできないことがあります。同じコンテナ内で curl は問題なくても、Axios が TLS ハンドシェイクで失敗します。プロキシを使っていて原因不明の接続エラーが出る場合、これが理由かもしれません。

Thunderbit が多くのアンチボット問題を回避できる理由

Thunderbit には2つのスクレイピングモードがあります。

• Browser Scraping: 実際の Chrome ブラウザ内で動作し、セッションCookie、ログイン状態、ブラウザフィンガープリントをそのまま継承します。サーバー側のリクエストをブロックする多くのアンチボット対策を回避できます。なぜなら、そのリクエスト自体が本物のブラウザだからです。
• Cloud Scraping: 公開サイト向けに、Thunderbit のクラウドがアンチボット対策を大規模に処理します。 まで対応可能です。

Cloudflare と戦う時間のほうが、データ分析より長くなっているなら、これはかなり現実的な選択肢です。

正直な見解：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 スクリプトの比較

結論はシンプルです。スクレイピングが複雑な自動化チェーンの一部なら 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 と を使えば、Google Sheets への無料出力付きで、同等の結果を数分で得られます。

ワークフロー2：営業リード獲得パイプライン

目的: 企業ディレクトリを毎週スクレイピングし、リードを整形・分類してCRMへ送る。

ノードチェーン: Schedule Trigger（毎週月曜9時） → HTTP Request（ディレクトリ一覧ページ） → HTML（氏名、電話、メール、住所を抽出） → Code（重複排除、書式整形） → OpenAI/Gemini ノード（業界分類） → HubSpot ノード（コンタクト作成）

注: n8n にはネイティブの があり、CRM 送信には便利です。ただし、スクレイピングと整形は依然として手動で CSS セレクタを扱う必要があります。

Thunderbit の近道: Thunderbit の無料 と電話番号抽出機能なら、ワークフローを組まずに1クリックで連絡先情報を取得できます。AI ラベル付けで、抽出中にリード分類も可能です。フルの自動化チェーンが不要なら、n8n の設定は丸ごと省略できます。

ワークフロー3：新着物件トラッカー

目的: Zillow や Realtor.com の新着物件を毎週チェックし、ダイジェストメールを送る。

ノードチェーン: Schedule Trigger（毎週） → HTTP Request（物件一覧ページ） → HTML（住所、価格、間取り、リンクを抽出） → Code（整形） → Google Sheets（追記） → Code（前週データと比較し、新着物件をフラグ） → IF（新着あり？） → Gmail/SendGrid（ダイジェスト送信）

注: Thunderbit には があり、CSSセレクタは不要です。取得→比較→通知までの完全な自動化を求めるなら n8n が有効で、物件データだけ欲しいなら Thunderbit が向いています。

さらに他のワークフロー例を見たい方は、n8n のコミュニティライブラリに 、、 といったテンプレートがあります。

n8n Webスクレイピングを安定運用するためのコツ

本番運用のスクレイピングは、構築が2割、保守が8割です。

バッチ処理と遅延でレート制限を避ける

HTTP Request ノードでバッチ処理を有効にし、バッチ間を1〜3秒空けましょう。同時リクエストは、最も早くIPブロックされる方法です。少し待つだけで、後の苦労がかなり減ります。

ワークフロー実行を監視し、静かな失敗を見逃さない

n8n の Executions タブで失敗実行を確認します。サイトのレイアウトが変わると、スクレイピング結果が空欄で返ってくることがあります。ワークフロー上は「成功」でも、スプレッドシートが空白だらけ、という状態です。

失敗時に Slack やメールへ通知する Error Trigger ワークフローを必ず作っておきましょう。本番では必須です。

CSSセレクタは外部管理して更新しやすくする

CSSセレクタは Google Sheets や n8n の環境変数に保存し、ワークフロー自体を編集せずに更新できるようにします。サイトのレイアウトが変わっても、1か所直せば済みます。

AI 搭載スクレイパーへ切り替えるタイミングを見極める

CSSセレクタの更新に追われたり、アンチボット対策に何度も悩まされたり、スクレイパーの保守に使う時間がデータ活用時間を上回っているなら、 のように、毎回サイトを新しく読み取り、自動で適応する AI 搭載ツールを検討しましょう。 も有効です。Thunderbit が壊れやすい抽出レイヤー（サイトが <div> を1つ変えるたびに壊れる部分）を担当し、Google Sheets や Airtable に出力。n8n がその新しい行を Sheets/Airtable のネイティブトリガーで受け取り、オーケストレーション — CRM 更新、通知、条件分岐、複数システムへの振り分け — を担う、という流れです。

まとめ：チームに合ったパイプラインを作ろう

n8n Webスクレイピングは、スクレイピングが大きな自動化ワークフローの1ステップとして必要なときに非常に強力です。ただし、技術的なセットアップ、継続保守、ページネーション・アンチボット・スケジューリング設定への粘り強さが求められます。このガイドでは、最初のワークフロー、どのチュートリアルも省きがちなページネーション、スケジューリング、アンチボット対策、n8n が適している場面の正直な評価、そしてそのまま使える実践例まで、全体をカバーしました。

私の考え方はこうです。

• n8n を使う: スクレイピングが、CRM 更新、Slack通知、AI補完、条件分岐といった複雑な多段自動化の一部であるとき。
• を使う: ワークフローを作らずに、すぐデータが欲しいとき。AI が項目提案、ページネーション、アンチボット、出力まで2クリックで処理します。
• Python を使う: 最大限の制御が必要で、開発リソースがあるとき。

正直なところ、多くのチームにとってのベスト構成は両方を組み合わせることです。抽出は Thunderbit、オーケストレーションは n8n。AI 搭載スクレイピングが n8n ワークフローとどう違うのか見てみたいなら、 で小規模に試せますし、 は数秒でインストールできます。動画での手順やワークフローのアイデアは、 も参考にしてください。

よくある質問

n8n で JavaScript が多用されたサイトをスクレイピングできますか？

標準の HTTP Request ノードだけではできません。HTTP Request ノードは生のHTMLを取得するだけで、JavaScript を実行できないからです。JSレンダリングされたサイトには、 のようなコミュニティノード、または 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 タブでエラーを確認してください。最も多い原因は、サイトのレイアウト変更で CSS セレクタが壊れたケースです。ワークフローは「成功」しているのに、空欄だけが返ってきます。Chrome の Inspect でセレクタを確認し、ワークフロー（または外部管理しているセレクタ表）を更新して再テストしてください。アンチボットに弾かれているなら、このガイドのトラブルシューティング手順に従いましょう。長期的な安定運用を考えるなら、レイアウト変更に自動で適応する Thunderbit のような AI 搭載スクレイパーも有力です。

さらに詳しく知る