n8nのRSS取得｜更新通知と重複の扱い

RSS ReadとRSS Feed Triggerを目的で選ぶ

最初の確認にはManual TriggerとRSS Read、単純な新規候補の監視にはRSS Feed Triggerが使えます。取得範囲と既済台帳を自分で管理したい場合は、Schedule TriggerとRSS Readを組み合わせる方法です。

ノードの画面項目は、公式のRSS ReadとRSS Feed Triggerの説明で確認できます。

RSS Readには、このノードで前に読んだ記事を自動的に除く機能がある、とは考えないでください。同じフィードを再度読むと、現在残っている同じ項目を再取得することがあります。

一方、RSS Feed Triggerは日時を境界に対象を選ぶトリガーです。GUIDの既読集合を持ち、すべての記事の新規・改稿を見分けるノードではありません。

定期確認はpollと呼ばれ、配信元から即時に押し込まれる通知とは異なります。間隔は配信元の利用条件と更新頻度に合わせ、短くすれば取りこぼしが必ずなくなるとは考えないようにしましょう。

次に読む：n8nのSchedule Triggerで定期実行を設定する
Schedule TriggerとReadを組み合わせる場合に、開始時刻・タイムゾーン・公開状態をそろえるための案内です。停止中の実行をどう扱うかも、RSS側の保持範囲と分けて確認できます。

フィードURLと、記事ID・URL・日時の出力を確認する

入力するのは、配信元が示すRSSのURLです。通常のトップページや記事ページのURLを、そのままフィードとして読み込めるとは限りません。

1. 通知先をつながず、フィードを1本選ぶ

   編集・実行権限のある検証用ワークフローで、Manual Triggerの後にRSS Readを置きましょう。本番の通知先や第三者宛の送信先を外し、まず読取りと項目確認に絞ります。

2. RSS ReadのURLへ公開フィードを指定する

   配信元が案内するRSS URLを入力してください。https://example.com/feed/ はURL構造を示す架空例で、そのまま利用できる実フィードとして示してはいません。

3. 出力itemと必要な項目を確認する

   実行して項目が得られたら、title、link、guid、isoDate等が実際に存在するかを調べます。ここで挙げた名前が、すべてのフィードに必ずそろうわけではありません。

4. 元の値と取得日時を候補記録へ残す

   配信元の識別子、記事ID候補、URL、タイトル、日時、取得日時を必要範囲で記録しましょう。情報が欠けた項目は空のまま自動通知へ流さず、要確認として分ける方法です。

RSS 2.0の仕様ではGUIDや記事の日付は任意要素なので、欠損する場合も設計に含める必要があります。フィード全体の更新時刻と、各記事の日時も分けて扱ってください。

個人専用やトークン付きのフィードURLは秘密として管理しましょう。公開の作例、画面写真、共有ログへそのまま載せないことが大切です。

次に読む：n8nのExpressionとEdit Fieldsでデータを整える
取得したGUID・URL・日時を保存用の項目へそろえる際に、式と項目編集の役割を確認できます。元のIDやURLを残したまま整える手順を確認してください。

取得エラーと「新規の対象なし」を分ける

エラーになった場合と、Triggerが新しい対象を返さない場合は、別の状態です。URLや接続の問題なのか、取得できた項目が日時条件を満たさないのかを分けて調べます。

HTTPで接続できたこと、RSSとして読めたこと、通知対象があったことは同じ完了条件ではありません。取得失敗を「新規0件」という実績に置き換えないようにしましょう。

特殊な取得が必要なら：n8nのHTTP RequestでAPIを呼ぶには
認証付きの取得など、RSSノードだけで満たせない要求の組み立てと応答の確認に役立ちます。

認証の管理を確認する：n8nの認証情報を設定・管理する方法とOAuth2
必要な秘密値を通常のデータへ直書きせず、Credentialsとして扱う範囲を整理するための案内です。

初回取り込みと本番pollの対象範囲を決める

初回に過去記事を残したいなら、RSS Readで現在フィードにある分を先に確認しましょう。RSS Feed Triggerを初めて公開すれば、過去の全記事が届くと考えてはいけません。

RSS Feed Triggerを使うと決めたら、通知先を外した検証用ワークフローで、次の順に設定します。

1. RSS Feed Triggerを置き、Feed URLへ確認済みのフィードURLを入力する
2. Poll TimesのModeで確認間隔を選び、表示された必要項目を設定する
3. 手動テストでURLと出力項目を確かめ、意図したワークフロー版を公開して本番pollの対象を別に確認する

定期監視には公開状態の確認が必要です。時刻を指定する設定ではタイムゾーンもそろえ、下の手動テストと本番の違いを読んでから対象範囲を判断してください。

同固定版では、保存された記事時刻、なければ前回確認時刻、それもなければ実行時刻を境界にします。比較は「同時刻以降」ではなく、境界より厳密に後という条件です。

説明用に、同じ日・同じタイムゾーンの境界を10:00とすると、記事時刻が10:00の項目は対象外、10:01の項目は日時条件を満たす候補になります。これは固定版の比較条件を当てはめた仮例で、実フィードを取得した結果ではありません。

このため、初回から残したい記事がある場合と、導入後の新しい候補だけを見たい場合では、先に決めることが変わります。どちらの方法でも、本番通知先を外した検証用ワークフローで対象を確認してください。

本番で項目が出ないときは、isoDate、境界、公開中のワークフロー版を照合しましょう。手動テストだけを繰り返しても、本番の日時判定を検証したことにはなりません。

取得範囲を記事ID台帳と突き合わせて決めたいなら、Schedule Trigger＋RSS Read方式が候補です。定期開始する設定と、記事を新規と判定する処理は別々に作ります。

取得間隔は、フィードの保持範囲と停止時間も見て決める

RSSから読めるのは、配信元がその時点でフィードに残している項目です。長く停止している間に一覧から消えた記事を、再開時のReadが必ず回収できるわけではありません。

確認するのは、配信元の保持件数や期間、更新頻度、自分の取得間隔、停止し得る長さです。フィードに明記がない部分は配信元の案内や取得記録で確かめ、不足期間を「新規なし」と埋めないようにしましょう。

保持範囲の中なら、同じ記事キーで再取得して台帳と照合します。すでに外れた期間は、必要に応じて配信元の公式アーカイブやAPIで補えるかを調べてください。

Schedule Triggerの停止中実行の補完、RSSの保持範囲、既済台帳の保持は別の条件です。定期実行を補完できても、フィードから消えた記事まで復元できるとは限りません。

次に読む：n8nのSchedule Triggerで定期実行を設定する
停止後の再開を考える際に、利用版・公開状態・タイムゾーンと、取り逃した実行の扱いを確認できます。RSS側の不足期間は別に記録しておきましょう。

記事の識別子と更新方針を決めて、重複を管理する

安定したGUIDがある場合は、フィード識別子とGUIDを組にして記事を照合します。GUIDがないときは安定した記事URLなどを検討しますが、欠損や変動がある項目まで同じ方法で自動処理しないでください。

タイトルは改題されることがあり、日時だけでは別の記事が同じ値になる場合もあります。「何の記事か」と「いつの記事か」を分けることが、通知の重複を判断する出発点です。

URLをそろえる際も、内容の識別に必要なパラメータを勝手に削らないようにしましょう。元URLを残しておけば、違う記事を一つにまとめていないかを後から確認できます。

新規記事だけを通知するなら記事キーを基本にし、改稿も知らせたいなら、何を更新版と見なすかを別に決めておきましょう。同じGUIDの本文が変わったことを、そのまま別の新規記事と呼ぶ必要はありません。

また、「取得済み」が示すのはフィードから得たという状態です。通知候補にした状態も含め、通知の成功や人が読んだことの確認とは区別してください。

次に読む：n8nの重複除去｜比較キーと履歴の使い分け
Remove Duplicatesで何を比較し、どの履歴を使うかを整理するための案内です。RSS側の記事キーと、汎用の重複除去の範囲をそろえられます。

条件を分けるなら：n8nのIF・Switch・Filterの違いと条件分岐の作り方
キー欠損を要確認へ残し、通知候補と既済を別の経路に分けたいときの案内です。

日時だけでは拾えない新規と更新を知っておく

RSS Feed Triggerの日時境界は、記事IDの新規性そのものを判定する仕組みではありません。次の表はn8n 2.45.5・Triggerノード版1の比較条件に基づく説明で、実フィードでの取得結果を示したものではない点に注意しましょう。

未見の記事が古い時刻で配信される一方、すでに見た記事の日時だけが変わる場合もあります。配信元の日時が公開と更新のどちらを示すかを確かめ、ID台帳の判断と合わせてください。

完全な改稿検知が必要な場合は、配信元が更新版をどう表すかの確認が先です。RSSにその情報がなければ、トリガーの設定だけで補えるとは考えないようにしましょう。

通知失敗は、取得状態と送信結果を分けて再処理する

RSSから記事を得た後に通知が失敗しても、次のpollで同じ記事が必ず出るとは限りません。取得の境界と、通知成功の台帳は別として設計しましょう。

n8n 2.45.5ではpoll状態の保存経路に版・機能設定による分岐がありますが、いずれも通知先の成功を見届けた既送記録ではありません。内部の保存方式を操作するより、記事キーと状態、確認できる実行IDや通知先の結果IDを対応させて残しましょう。

処理前の既済記録には通知漏れ、処理後の記録には二重処理の余地があるため、この改善例も厳密に一度だけ送る保証ではありません。

Data Tableなどは、記事キーや状態、結果IDを実行間で保持する候補になります。ただし表を追加しただけで、並列処理の排他や、送信と記録を一体にした処理が保証されるわけではありません。

同じ先へ複数の実行から送る場合は、宛先と記事キーに対して、通知先が重複要求をどう扱うかも確認してください。いわゆる冪等性や処理権の管理が必要になる範囲なので、単純な履歴除去と分けて検討します。

検証と再開は、通知を止めた小さな流れで確かめる

運用前には、正常な新規取得だけでなく、同じ記事の再取得や送信結果が不明な場合まで確認しましょう。手動で動くことと、公開版のpoll・通知・再開が意図どおりであることは別です。

1. 検証用の範囲を分ける

   別ワークフローでフィードを最小数にし、自分用かダミーの出力先だけを使ってください。手動実行でも送信ノードを実行し得るため、本番通知先につないだまま試さないことが大切です。

2. 記事の変化と状態を照合する

   初回、同じitemの再取得、新規ID、同一IDの改稿、同時刻追加、日付なしを確認しましょう。各ケースが新規・既済・更新・要確認のどれになるべきかを先に決めてください。

3. 通知先の失敗と不明を分ける

   拒否が確定した対象、成功済み、結果不明を分け、対象だけを再処理できるかを確かめます。通知先が受理した可能性がある場合は、繰り返し送る前に結果を調べてください。

4. 再開時の範囲と戻し方を残す

   停止後はフィードの保持範囲と台帳を照合し、不足期間を記録しましょう。不具合があれば通知側を止めて変更前の設定へ戻し、取得状態と外部の送信結果は別に扱います。

ワークフローの設定を戻しても、送った通知や既済台帳が自動で巻き戻るわけではありません。履歴全消去や取得cursorの初期化を、通常の再送手順にはしないでください。

• ReadとTriggerのどちらを、何のために選んだかを説明できる
• フィードID・記事キー・元URL・日時の欠損を確認した
• 初回・改稿・再取得・停止後の判定方針が決まっている
• 通知成功、失敗確定、結果不明を分けて残せる
• 実行版・ノード版・公開状態と、必要な権限を確認した
• 通知停止と設定復帰、台帳の照合を分けて行える

この確認ができたら、必要な通知先だけへ後工程で接続する順序です。キーや結果の照合が不足する間は、候補の記録までで止めて人が確認しましょう。

次に確認したいこと：ブログ自動化の工程と、人が判断する箇所
RSSから集めた候補を記事制作へつなぐ場合に、どこまで機械に任せ、どこで原典や内容を人が確かめるかを整理するための案内です。

次に確認したいこと：n8nの運用費用とCloud・VPSの選び方
費用や設置基盤の判断が別に必要になった場合に、運用費の条件と自分で管理する範囲を確認できます。RSSを読めたことだけで、新しい契約が必要になるわけではありません。

まとめ｜記事の識別と通知結果を分け、小さく確認する

n8nのRSS取得は、現在の項目を読むならRSS Read、定期監視を始めるならRSS Feed Triggerを選びます。初回の過去取り込み、日時での対象判定、同じ記事の改稿は、それぞれ別に方針を決めてください。

まずは公式フィード1本を読み、タイトル・リンク・記事ID・日時を候補として記録しましょう。安定したキーと欠損を確認し、同じ記事の再取得と失敗ケースを照合してから、必要な通知先へ進む順序です。

取得済みと通知成功を分けておく設計は、停止後や失敗後に何を再処理するかの判断を助けます。届け終えたことまで確認できる小さな流れを優先し、RSSにない情報や結果不明の通知を、推測で成功にしないことが大切です。