数か月前、あるユーザーから、14個のノード、6枚ほどの付箋、そして件名がたった一言「Help」とだけ書かれた n8n のワークフローのスクリーンショットが届きました。人気の n8n Webスクレイピングチュートリアルを見ながら、テストサイトでは10行だけのきれいなデモを動かすことに成功したものの、実際の競合価格を200件の製品ページから取ろうとした瞬間、ページネーションのループは崩れ、403エラーの壁にぶつかり、しかも最初の火曜日以降は一度も動かないスケジューラーまで出てきたのです。
この「デモ」と「実運用パイプライン」のあいだにあるギャップこそ、多くの n8n スクレイピング案件が止まってしまう場所です。私は長年 を作りながら自動化にも関わってきましたが、はっきり言えます。スクレイピングそのものは、実はそれほど難しくありません。本当に人をつまずかせるのは、最初の取得がうまくいった“あと”に続くすべてです。ページネーション、スケジューリング、ボット対策、データ整形、エクスポート、そしていちばん厄介な、サイトのレイアウトが今四半期で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 は公開されましたが、著者自身の結論はこうでした。「HTTP Request ノードの Options にあるデフォルトの Pagination Mode は便利そうに見えるものの、私の経験では典型的な Web スクレイピング用途で安定して動作しませんでした。」 その結果、ページネーションは有料の外部APIに逃がすことになったのです。一方、n8n フォーラムでは今も「ページネーション、スロットリング、ログイン」が、n8n スクレイピングが「簡単に複雑化する」ポイントとして挙げられています。このガイドは、そのギャップを埋めるためのものです。
なぜ n8n Webスクレイピングは営業・業務運用・ECチームに重要なのか
n8n Webスクレイピングは、開発者の趣味ではありません。ビジネスのためのツールです。 は2025年時点で約10〜13億ドル規模で、2030年には20〜23億ドルに達すると予測されています。動的価格設定だけでも、約 が利用しており、 は今や代替データに依存しています。その多くはWebから取得されたものです。McKinsey によると、動的価格設定は導入企業に をもたらします。
n8n の真価が発揮されるのはここです。単にデータを取るだけではありません。その「次」に何をするかが本質です。n8n なら、スクレイピングを CRM 更新、Slack通知、スプレッドシート出力、AI分析などの下流処理と1本のワークフローにまとめられます。
| ユースケース | 恩恵を受ける人 | 取得するデータ | ビジネス成果 |
|---|---|---|---|
| リード獲得 | 営業チーム | 企業ディレクトリ、問い合わせページ | 有望リードをCRMに蓄積 |
| 競合価格モニタリング | EC運用チーム | 商品一覧ページ | 価格をリアルタイムで調整 |
| 不動産物件の追跡 | 不動産エージェント | Zillow、Realtor、地域MLSサイト | 競合より早く新着物件を把握 |
| 市場調査 | マーケティングチーム | レビューサイト、フォーラム、ニュース | トレンドや顧客の声を把握 |
| 仕入先/SKU在庫監視 | サプライチェーン運用 | 仕入先の商品ページ | 欠品を防ぎ、購買を最適化 |
データが示すROIは確かです。 が2025年にAI投資を増やす計画であり、自動化されたリード育成は9か月で したとされています。まだWebサイトからスプレッドシートへ手作業でコピペしているなら、機会損失を出しているかもしれません。
n8n Webスクレイピングの基本セット:主要ノードと使える選択肢
何かを作り始める前に、まず道具箱の中身を知っておく必要があります。Webスクレイピングで重要な n8n ノードは次のとおりです。
- HTTP Request node: 任意のURLから生のHTMLを取得します。ブラウザがページを開くような動きですが、レンダリング結果ではなくコードを返します。GET/POST、ヘッダー、バッチ処理、そして理論上は内蔵ページネーションにも対応しています。
- HTML node(旧「HTML Extract」): CSSセレクタでHTMLを解析し、タイトル、価格、リンク、画像など必要なデータだけを抜き出します。
- Code node: データ整形、URLの正規化、重複排除、独自ロジックのための JavaScript を書けます。
- Edit Fields (Set) node: データ項目の再構成や名称変更を行います。
- Split Out node: 配列を個別アイテムに分解して処理します。
- Convert to File node: 構造化データをCSVやJSONなどに書き出します。
- Loop Over Items node: リストを順番に回します(ページネーションで重要。後述します)。
- Schedule Trigger: cron スケジュールでワークフローを起動します。
- Error Trigger: ワークフロー失敗時に通知します(本番運用では必須)。
JavaScript のレンダリングが必要なサイトや、強いボット対策があるサイトでは、コミュニティノードが必要になります。
| アプローチ | 向いている用途 | 必要スキル | JSレンダリング対応 | ボット対策対応 |
|---|---|---|---|---|
| n8n HTTP Request + HTMLノード | 静的サイト、API | 初級〜中級 | いいえ | 手動(ヘッダー、プロキシ) |
| n8n + ScrapeNinja/Firecrawl コミュニティノード | 動的サイト/保護されたサイト | 中級 | はい | 標準搭載(プロキシローテーション、CAPTCHA) |
| n8n + Headless Browser(Puppeteer) | 複雑なJS操作 | 上級 | はい | 一部対応(構成次第) |
| Thunderbit(AI Web Scraper) | あらゆるサイト、非技術ユーザー | 初級 | はい(ブラウザモードまたはクラウドモード) | 標準搭載(ブラウザセッション継承またはクラウド処理) |
2026年時点でも、n8n に標準搭載のヘッドレスブラウザノードはありません。JSレンダリングが必要なスクレイピングでは、コミュニティノードか外部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」に次を追加してください。
| ヘッダー名 | 値 |
|---|---|
| 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を取得する場合は、「Options」で Batching を有効にし、リクエスト間隔を1〜3秒に設定します。これでレート制限を踏みにくくなります。
ノードを実行すると、出力パネルに生のHTMLが表示されるはずです。
ステップ3: HTML ノードでデータを解析する
HTML ノードを HTTP Request の出力に接続します。操作は 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 は次の通りです。
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 コミュニティフォーラムで最も多い悩みの1つです。
主なページネーションパターンは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を生成します。
1const base = 'https://example.com/products';
2const totalPages = 10; // または動的に検出
3return Array.from({length: totalPages}, (_, i) => ({
4 json: { url: `${base}?page=${i + 1}` }
5}));
- Loop Over Items ノードをつなぎ、リストを順に回します。
- ループの中に HTTP Request ノード(URLを
{{ $json.url }}に設定)を入れ、その後に解析用の HTML ノードを置きます。 - 429 のレート制限を避けるため、ループ内に Wait ノード(1〜3秒、ランダム推奨)を追加します。
- ループ後に結果を集約し、Google Sheets または CSV に出力します。
全体の流れは、Code(URL生成)→ Loop Over Items → HTTP Request → HTML → Wait →(ループに戻る)→ 集約 → 出力 です。
注意点が1つあります。Loop Over Items ノードには、 があります。ページネーションしながらサブページも展開する場合は、必ず丁寧にテストしてください。「完了件数」が入力件数と一致しないことがあります。
無限スクロールのページネーション:なぜ n8n 標準ノードでは厳しいのか
無限スクロールのページは、スクロールに応じて JavaScript で内容を読み込みます。HTTP Request ノードが取得できるのは初期HTMLだけで、JavaScript の実行もスクロールイベントの発火もできません。選択肢は2つです。
- headless browser のコミュニティノード(例: や )を使ってページを描画し、スクロールをシミュレートする。
- スクレイピングAPI(ScrapeNinja、Firecrawl、ZenRows など)で JS レンダリングを有効にする。
どちらもかなり複雑になります。サイト1つあたり30〜60分以上のセットアップに加え、継続的な保守も必要です。
Thunderbit は設定なしでページネーションをどう処理するか
少し贔屓目ですが、違いはかなり明確です。
| 機能 | n8n(DIYワークフロー) | Thunderbit |
|---|---|---|
| クリック型ページネーション | 手動でループノード設定、URL増分を構築 | 自動検出してページネーションを追従 |
| 無限スクロールページ | headless browser + コミュニティノードが必要 | 標準対応、設定不要 |
| セットアップ工数 | 1サイトあたり30〜60分 | 2クリック |
| 1回の処理ページ数 | 直列処理(1件ずつ) | 50ページ同時処理(Cloud Scraping) |
10個の一覧ページで合計200件の商品ページを取るなら、n8n では丸一日かかることがあります。Thunderbit ならおよそ2分です。これは n8n を否定しているわけではなく、用途が違うだけです。
一度組んで放置:cron トリガーで動く n8n Webスクレイピングパイプライン
単発のスクレイピングも便利ですが、n8n Webスクレイピングの真価は、定期的で自動化されたデータ収集にあります。意外なことに、ほとんどの n8n スクレイピングチュートリアルは、スクレイピング用途での Schedule Trigger を扱っていません。コミュニティでも要望の多い機能なのに、です。
毎日の価格監視パイプラインを作る
Manual Trigger を Schedule Trigger ノードに置き換えます。n8n のUIで「毎日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 は、セレクタベースのパイプラインでは、初期構築時間の を年間保守に見込むべきだと見積もっています。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が最新のページを読み取る |
最後の行こそ重要です。フォーラムではよくこう言われます。「ほとんどのサイトは、レイアウトが変わるまでは問題ない。」 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)または headless browser のコミュニティノードに切り替える
- いいえ → 続行
- いいえ → 続行
- はい → 住宅用プロキシのローテーションを追加 → まだダメ?
- CAPTCHA が出る → CAPTCHA 解決機能付きのスクレイピングAPIを使う(例: )
- 空の応答(JSレンダリング内容) → headless browser のコミュニティノード、または 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工程としてスクレイピングがあるケース — 取得 → enrich → フィルタ → CRM送信、のような流れ。
- CSSセレクタやノードベースのロジックに慣れている技術者。
- スクレイピング後に独自のデータ変換が必要な場面。
n8n Webスクレイピングがつらくなりやすい領域
- すぐにデータだけ欲しい非技術ユーザー。ノード設定、CSSセレクタの発見、デバッグのループは、ビジネスユーザーにはかなりハードです。
- 強いボット対策があるサイト。プロキシやAPIの追加でコストと複雑さが増します。
- サイトレイアウト変更への保守。CSSセレクタが壊れ、ワークフローが静かに失敗します。
- 多数の異なるサイトを一括でスクレイピングする場合。サイトごとにセレクタ設定が必要です。
- サブページの情報補完。n8n で別サブワークフローを作る必要があります。
n8n vs Thunderbit vs Python スクリプト
| 比較項目 | n8n DIYスクレイピング | Thunderbit | Pythonスクリプト |
|---|---|---|---|
| 必要な技術レベル | 中級(ノード + CSSセレクタ) | 不要(AIが項目提案) | 高い(コーディング) |
| 新しいサイト1件あたりの設定時間 | 30〜90分 | 約2分 | 1〜4時間 |
| ボット対策への対応 | 手動(ヘッダー、プロキシ、API) | 標準搭載(ブラウザ/クラウドモード) | 手動(ライブラリ) |
| サイト変更時の保守 | セレクタを手動更新 | ほぼ不要 — 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 と を使えば、Google Sheets への無料出力付きで、同等の結果を数分で得られます。
ワークフロー2:営業リード獲得パイプライン
目的: 企業ディレクトリを毎週スクレイピングし、リードを整形・分類してCRMに送る。
ノード構成: Schedule Trigger(毎週月曜9時)→ HTTP Request(ディレクトリ一覧ページ)→ HTML(会社名、電話、メール、住所を抽出)→ Code(重複排除、書式整形)→ OpenAI/Gemini ノード(業種で分類)→ HubSpot ノード(コンタクト作成)
補足: n8n にはネイティブの があります。CRMへの送信には便利です。ただし、スクレイピングと整形は依然として手動でCSSセレクタを扱う必要があります。
Thunderbit の近道: Thunderbit の無料 と Phone Number Extractor なら、ワークフローを作らずに1クリックで連絡先情報を取得できます。AIによるラベル付けで、取得中にリードを分類することも可能です。フルの自動化チェーンが不要な人は、n8n の設定自体を省略できます。
ワークフロー3:不動産の新着物件トラッカー
目的: Zillow や Realtor.com の新着物件を毎週見つけ、要約メールを送る。
ノード構成: Schedule Trigger(毎週)→ HTTP Request(物件一覧ページ)→ HTML(住所、価格、間取り、リンクを抽出)→ Code(整形)→ Google Sheets(行追加)→ Code(前週データと比較し、新着をフラグ)→ IF(新着あり?)→ Gmail/SendGrid(要約送信)
補足: Thunderbit には Zillow のようなサイト向けの があり、CSSセレクタは不要です。取得→比較→通知までのフル自動化が必要なら n8n が向いています。物件データだけ欲しいなら Thunderbit で十分です。
さらに他の例が欲しいなら、n8n のコミュニティライブラリには 、、 などのテンプレートがあります。
n8n Webスクレイピングパイプラインを安定運用するコツ
本番スクレイピングは、構築が2割、保守が8割です。
バッチ処理と待機でレート制限を避ける
HTTP Request ノードでバッチ処理を有効にし、バッチ間の待機時間を1〜3秒に設定します。並列リクエストは、IPブロックされる最短ルートです。少し待つだけで、後々の痛みが大きく減ります。
ワークフロー実行を監視し、静かな失敗を見逃さない
n8n の Executions タブで失敗実行を確認しましょう。サイトのレイアウト変更で取得結果が空になっても、ワークフロー上は「成功」してしまうことがあります。スプレッドシートが空欄だらけになるのです。
Error Trigger ワークフローを組み、失敗時には Slack またはメールでアラートを送るようにしてください。本番パイプラインでは必須です。
CSSセレクタは外部管理して更新しやすくする
CSSセレクタは Google Sheets や n8n の環境変数に保存しておくと、ワークフロー本体を編集せずに更新できます。サイトのレイアウトが変わっても、1か所だけ直せば済みます。
AI搭載スクレイパーへ切り替えるタイミングを見極める
CSSセレクタを頻繁に更新していたり、ボット対策と戦い続けていたり、スクレイパーの保守に使う時間のほうがデータ活用より長くなっているなら、 のように毎回ページを読み直して自動適応するAI搭載ツールを検討しましょう。 はかなり相性が良いです。Thunderbit が壊れやすい抽出層(サイトが <div> を少し変えるたびに壊れる部分)を担当し、Google Sheets や Airtable に出力。n8n はそれを Sheets/Airtable のネイティブトリガーで受け取り、オーケストレーション — CRM更新、通知、条件分岐、多システム展開 — を担います。
まとめ:チームに合ったパイプラインを作ろう
n8n Webスクレイピングは、スクレイピングが大きな自動化ワークフローの一部であるときに強力です。ただし、技術的なセットアップ、継続的な保守、ページネーション・ボット対策・スケジューリング設定への粘り強さが必要になります。このガイドでは、最初のワークフロー、ページネーション(どのチュートリアルも省きがちな部分)、スケジューリング、ボット対策のトラブルシューティング、n8n が向く場面の正直な整理、そして実際にコピーできるワークフローまで、パイプライン全体を解説しました。
私の考え方はこうです。
- n8n を使う: スクレイピングが複雑な多段階自動化の一部であるとき。CRM更新、Slack通知、AIでの補完、条件分岐ルーティングなど。
- を使う: ワークフローを組まずに素早くデータが必要なとき。AI が項目提案、ページネーション、ボット対策、エクスポートまで2クリックで処理します。
- Python を使う: 最大限の制御が必要で、開発リソースがあるとき。
正直に言うと、多くのチームにとって一番いい構成は両方を使うことです。抽出は Thunderbit、オーケストレーションは n8n。AI搭載スクレイピングがあなたの n8n ワークフローとどう違うのか見てみたいなら、 で小規模に試せますし、 も数秒で導入できます。動画での使い方やワークフローのアイデアは、 をご覧ください。
FAQ
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)やスクレイピングAPI(月49〜200ドル超、利用量次第)が必要になることもあります。
n8n Webスクレイピングと Thunderbit の違いは?
n8n は、スクレイピングが大きなワークフローの一部である多段階自動化に向いています(例: 取得 → enrich → フィルタ → CRM送信 → Slack通知)。Thunderbit は、AIによる項目検出、自動ページネーション、サイト変更時の保守ゼロで、素早くノーコードのデータ取得をしたいときに向いています。多くのチームは両方を併用しています。抽出は Thunderbit、オーケストレーションは n8n です。
ログインが必要なサイトのデータを n8n で取得できますか?
はい。ただし、HTTP Request ノードに Cookie やセッショントークンを設定する必要があり、保守はやや大変です。Thunderbit の Browser Scraping モードなら、ログイン済みの Chrome セッションを自動で引き継ぎます。ログインして見えている内容なら、そのまま取得できます。
n8n のスクレイパーが突然データを返さなくなったら、どうすればいいですか?
まず n8n の Executions タブでエラーを確認してください。最も多い原因は、サイトのレイアウト変更で CSSセレクタが壊れたケースです。ワークフロー自体は「成功」しているのに、結果が空になることがあります。Chrome の Inspect ツールでセレクタを確認し、ワークフロー内(または外部のセレクタ管理表)を更新して再テストしてください。ボット対策で止められているなら、このガイドの判断フローに従ってください。長期的な安定性を重視するなら、レイアウト変更に自動適応する Thunderbit のようなAI搭載スクレイパーも検討してください。
さらに詳しく