n8nのHTMLノードで抽出する方法｜旧HTML Extract

ノードやワークフローの意味から整理したい場合は、先に「n8nとは？できることと導入前に知りたい負担」を読むと、抽出を自動化全体のどこへ置くかを考えやすくなります。できることに加え、導入や運用で引き受ける負担も確認できる関連記事です。

関連記事

n8nとは？できることと導入前に知りたい負担

PR：この記事にはアフィリエイト広告が含まれます。n8nとは、開始条件と処理を「ノード」でつなぎ、サービス間の繰り返し作業を自動化する道具です。ブログ運営なら、情報の転記、原稿の保存、確認担当者への通知などを一つの流れにまと[…]

旧HTML Extractは、現行HTMLの抽出操作を選ぶ

HTMLノードには、抽出・生成・表への変換という異なる操作があります。まず目的に合う操作を選ぶことが、設定項目を迷わず読むための近道です。

三つの操作は「何を入力し、何へ変えるか」で見分ける

すでにあるHTMLから値を読むのか、データをHTMLにするのかで選びましょう。同じノードでも、Operationが違うと表示される設定も変わります。

たとえば、記事一覧のリンク先だけが必要ならExtract HTML Contentです。この記事では抽出を中心に扱い、テンプレートや表の見た目を作り込む手順とは分けて説明します。

古い画面と項目が違うときは、ノードの版も確認する

公式Docsにある、HTMLノードがHTML Extractを置き換えた時点はn8n 0.213.0です。そのため、旧名の記事と現行ノードの画面が同じとは限りません。

検証用フローを閲覧・編集・手動実行できる担当者が、使っているn8n本体の版、ノード名、操作、可能ならノードのtypeVersionを控えてください。本体の版と、ワークフロー内に保存されているノードの版は別の確認項目です。

URLではなく、HTMLが入ったフィールドを渡す

HTMLノードへ渡すのは、HTML文字列またはHTMLファイルのbinaryデータです。Webページを取得する工程と、そのHTMLから抽出する工程を分けて組みます。

HTTP Requestの応答は、文字列の場所を先に見る

HTTP Requestで取得する場合は、Response FormatをTextにし、通常の本文出力ではPut Output in Fieldを例としてhtmlに指定しましょう。次のHTMLノードではSource DataをJSON、JSON Propertyを同じhtmlに合わせます。

重要なのは、設定名を覚えることより、HTMLノードの実際の入力に目的の文字列があるかです。ステータスやヘッダーも含む応答形式では本文がbody側に入るなど構造が変わるため、出力を見てパスを合わせてください。

URL文字列だけをhtmlへ入れても、そのページをHTMLノードが代わりに取得するわけではありません。また、2xxだけでは目的のHTMLを取得したと判断できないため、ログイン画面やエラー案内、別形式のデータでないかを確かめてください。

応答本文に目的の見出しやクラス名があるか、Content-Typeや最終的な取得先が想定と合うかを確かめましょう。認証・URL・応答形式の設定が先に必要なら、取得工程を整えてから抽出へ進みます。

HTMLファイルならbinaryの欄を指定する

前ノードがHTMLファイルをbinaryとして出している場合は、Source DataでBinaryを選んでください。Input Binary Fieldに指定するのは、ファイルが実際に入っているbinaryフィールド名です。

たとえばbinary側のdataと、JSON側のhtmlは別の入力として扱ってください。JSONの欄に名前が見えていても、それだけでbinaryファイルを渡せていることにはなりません。

Extract From FileにもExtract From HTMLという操作があります。ファイル形式をJSONへ変換する別経路の候補で、本記事の主経路はHTMLノードの抽出設定です。

まず自作HTMLで、取得と抽出の問題を切り離す

最初の確認には、次の短い自作HTMLを使えます。これは説明用の仮データであり、n8nで抽出を実行した結果や、実サイトから転載したHTMLではありません。

<title>資料一覧</title><section id="resources">  <article class="card"> <h2 data-id="r1">導入ガイド</h2> <a class="detail" href="/guide/a">詳細</a>  </article>  <article class="card"> <h2 data-id="r2">設定ガイド</h2> <a class="detail"href="https://example.org/guide/b">詳細</a> <span class="badge">更新</span>  </article></section>

検証用ワークフローで、手動トリガーの後ろにEdit Fieldsなどを置き、htmlというStringフィールドへこのHTMLを固定値として入れましょう。入力は1 itemとし、説明用のsource_idをfixture_01、base_urlをhttps://example.org/resources/として別フィールドに持たせます。

この方法の利点は、ネットワーク接続を変えずに、入力フィールドとセレクターだけを確認できることです。本番の自動トリガーや投稿・送信・DB更新は接続せず、元データを残した複製で試してください。

セレクターと戻り値を、欲しい情報に合わせる

Extraction Valuesでは、出力名のKey、対象を選ぶCSS Selector、取り出し方のReturn Valueを一組で設定します。リンクの表示文字とリンク先のURLは、同じ要素から取っても別の情報として区別してください。

見出しならText、リンク先ならAttributeを使う

CSSセレクターは、HTMLの中から対象の要素を選ぶ指定です。たとえばtitleはタグ、.detailはclass、#resourcesはidを手掛かりに選べます。

#resources .detailはresources内のdetailクラス、#resources > .cardはその直下のcardを対象に選ぶ書き方です。ページ全体のaのような広い指定より、対象範囲を絞る方が無関係なリンクを取り込みにくいでしょう。

リンク先が欲しいのにTextを選ぶと、URLではなく「詳細」が得られる設定です。Keyをlinks、CSS Selectorを#resources .detail、Return ValueをAttribute、Attributeをhrefにすると、欲しい情報と設定が対応します。

Keyは出力の項目名なので、HTML側に同名のclassが必要なわけではありません。あとで見たときに内容が分かる名前を付けましょう。

複数の値はReturn Arrayで残し、item数と区別する

複数の一致要素を別々の値として扱いたいときは、Return ArrayをONにします。ただし、配列の長さと、n8nのitem数は別です。

Return ArrayをOFFにした場合も、すべての戻り値・すべての版で「必ず先頭要素だけ」とは決めつけないでください。Textなどの処理には版による差があり、単一値にまとまる扱いは利用中のノードで確認する必要があります。

複数のHTML文字列を配列で入力する経路もあるため、ここでは1 itemのhtmlに単一文字列を入れる条件へそろえましょう。比較条件を固定すると、内側の配列と外側のitemを取り違えずに確認できます。

空白調整と除外は、必要なときだけ加える

Trim Valuesは前後の空白や改行、Clean Up Textは改行や連続空白などの整形に使う設定です。まず元の抽出値を見て、用途に必要な調整だけを加えます。

改行を意味のある区切りとして扱う場合は、整形で消してよいかを先に判断しましょう。一度落とした情報を、後の設定で自動的に復元できるわけではありません。

現行DocsのText抽出には、不要な子要素を除くSkip Selectorsも案内されています。ただし旧ノード版まで同じ項目があるとは限らないため、見当たらなければノード版を照合してください。

期待値と比べ、記事ごとの対応を保つ

抽出ノードが成功表示でも、必須のリンクが空、別記事の値が混在、余分な要素を取得しているなら修正が必要です。同じHTMLに対する期待値を先に決めて、実際の入力と出力を対で照合します。

仮HTMLで、件数・型・値を確認する

次は、先ほどの自作HTMLに対して設計した期待値です。HTMLノードをExtract HTML Content、Source DataをJSON、JSON Propertyをhtmlにして、必要なExtraction Valuesを追加しましょう。

この表は実測ログではなく、マークアップと公開仕様から組んだ比較基準です。実行時は、各フィールドの型と件数を確認し、上の値がどの要素から来たのかもたどります。

titlesが2件、linksが2件、badgesが1件でも、直ちに抽出失敗ではありません。仮HTMLでは、更新ラベルを持つのが2件目だけだからです。

別々の配列を、位置だけで結合しない

ここで最も見落としたくないのは、配列の位置だけで記事情報を組にしない点にあります。任意項目が欠けると、別々に取った配列の同じ位置が、同じ記事を表すとは限らないためです。

最小の接続は、cardsの抽出、Split Outでの展開、断片ごとのHTML抽出です。大切なのはノードを増やすことではなく、一記事分の情報が混ざらない単位を残すことにあります。

1. 記事ごとの内部HTMLを配列にする

   最初のHTMLでcardsを作り、HTML／Return Array ONを指定しましょう。.cardの外側タグそのものではなく、中のh2やaなどが各断片に残る設定です。

2. cardsを断片ごとのitemへ分ける

   Split OutのField to Split Outにcards、Destination Field Nameにcardを指定してください。この仮例では2要素の配列から、cardを一つずつ持つ2 itemsにする設計です。

3. 各cardから必要な項目を抽出する

   次のHTMLでSource DataをJSON、JSON Propertyをcardにし、h2のdata-id、h2のText、.detailのhref、任意の.badgeを取り出しましょう。r1とr2の必須値がそれぞれ一組で残り、任意ラベルの欠落が他記事へずれないことを確認します。

配列の展開で親IDやURLをどう残すかを詳しく確認したい場合は、「n8nのAggregateとSplit Outでitemをまとめる・分ける」が次に役立つ内容です。分割フィールドと残す親キーを一組で考えると、後続で元ページを見失いにくくなります。

元ページのIDとURLは、自動で残ると考えない

HTML抽出後のJSONに、入力のsource_idやbase_urlが自動的にコピーされるとは限りません。後続で使う項目は、対応する入力から明示的に引き継いでください。

この例なら、最初の抽出後にEdit Fieldsなどでsource_idとbase_urlを元の入力から補い、cardsも残します。Split OutではIncludeをSelected Other Fields、Fields to Includeをsource_id,base_urlにする設定が一案です。2回目のHTML抽出後も、対応する入力から必要な元項目を補い直してください。

n8nの入力とのひも付けと、JSONに項目の値が実際に残ることは別の仕組みとして扱いましょう。複数ページを処理するとき、先頭itemへの参照で全件を補うと、異なるページを同じsource_idにしてしまうおそれがあります。

式で項目を引き継ぐ方法は、「n8nのExpressionとEdit Fieldsでデータを整える」で、現在itemと前ノードの参照を整理するのが有効です。入力との対応が一意に決まらない場合は、先頭固定で隠さず、照合キーを使った結合の設計へ戻ってください。

空値と相対URLは、後続へ渡す前に処理する

入力フィールド自体がない場合、セレクターに一致しない場合、要素はあってもhrefがない場合は、それぞれ別の不備です。必須のIDやリンク先が欠けていたら、後続の取得・投稿へ進めず、要確認として分けます。

現行masterの実装では、Return Array ONで一致要素がなければ空配列を作る処理です。ただし、単一値の未一致・属性欠損の型まで、すべての旧版で同じとは決めずに確認してください。

また、相対hrefは、そのまま完全なURLではありません。仮例の/guide/aは、基準URLがhttps://example.org/resources/ならhttps://example.org/guide/aへ解決されます。

HTMLノードが自動でこの変換をするという意味ではないため、取得後の最終URLや有効なbaseを確認しましょう。相対URLの解決は文字列の単純連結と異なり、先頭の/や../などで解釈が変わります。

URLを解決したら、許可するschemeとhostを確認し、javascript:などを取り出せたという理由だけで次のHTTP処理へ渡さないでください。

• 必須のID・見出し・hrefが、同じレコード内でそろう
• 任意項目の欠落を、別レコードの値や0で埋めていない
• 配列長と外側のitem数を別々に照合した
• source_id・base_urlなど、後で必要な元情報を明示的に残した
• 相対URLの基準と、解決後のscheme・hostを確認した

値が取れないときは、取得HTMLから順に切り分ける

最初に見るのは、受け取ったHTMLに目的の要素があるかどうかです。入力パス、セレクター、戻り値、配列、ノード版の順に、一つずつ条件を比べます。

ブラウザで見える内容が、HTML文字列にもあるとは限らない

HTMLノードは、ブラウザのようにページを描画して情報を集めるノードではありません。公式実装で使われるCheerioはHTMLを解析しますが、JavaScriptを実行して後から内容を表示する仕組みとは異なります。

JavaScriptが生成する一覧が応答HTMLに入っていなければ、CSSセレクターを何度変えても、その一覧自体は現れないのです。ブラウザ上の見た目だけで判断せず、実際に渡したHTML文字列を確かめてください。

提供元に利用可能なAPIやRSSがあり、それで必要な情報を得られるなら、取得経路を選び直します。アクセス制限の回避や、ページ全文の自動転載へ用途を広げる解決にはしません。

「空」「取りすぎ」「文字化け」で確認先を分ける

同じ空出力でも、原因候補は一つではないため、次の表で最初の確認先を選びましょう。変更後は同じ自作HTMLへ戻り、期待値が保たれているかを比べます。

HTTP接続や認証から組み直す必要がある場合は、「n8nのHTTP RequestでAPIを呼ぶには」でURL・応答形式・取得内容を先に整理するのが有効です。抽出側だけを変更し続けず、取得したデータが目的の内容かを確認できます。

修正で悪化したときは、検証用フローを停止し、変えたセレクターやオプションだけを元へ戻しましょう。不明な欠落を既定値で上書きせず、元のHTMLと変更前の設定を残します。

抽出成功と、安全に外へ出せる状態を分ける

外部へ渡す前には、使用権限、必要範囲、個人情報の有無、取得頻度、出力先を確認してください。小さな自作HTMLで検証してから、扱える資料の必要項目へ広げる順が適切です。

実際に投稿や送信をした後は、設定を戻す操作と、すでに外へ出た内容を取り消す操作は別です。本番の出力先をつなぐ前に、必須欠落で止める経路と、正常なデータだけを進める条件を決めましょう。

まとめ｜HTMLの入力と抽出結果を対で確かめる

n8nの現行HTMLでは、Extract HTML Contentを選び、HTMLのフィールド、CSSセレクター、戻り値、Return Arrayを設定します。ブラウザが後から描画する内容は、入力HTMLに存在しなければ抽出だけでは得られない点が重要です。

まず自作HTMLで件数と必須値の期待表を作り、レコードの対応、欠落、相対URLを確認しましょう。配列をitemへ展開する場合も、元ページのIDやURLを明示的に残してから実データへ進めます。

セレクターを短く書くことより、一レコードの範囲と欠落の扱いを先に決める方が、別記事の値を取り違える問題を見つけるうえで有効です。入力と出力を並べて確かめる習慣が、抽出後の通知や記録も組みやすくします。