n8nの重複除去｜比較キーと履歴の使い分け

この記事は、現行の公式文書と、n8n 2.45.5・Remove Duplicatesのノードバージョン2の公式ソースを基にした説明です。古いノードとは操作や挙動が異なる場合があるため、利用中の本体版・ノード版を確認してから設定してください。

重複を除く前に、同じとみなす単位と範囲を決める

重複とは、見た目が似ているデータではなく、目的に照らして同じ処理とみなすデータです。先に「残すべき一件は何か」を言葉にすると、比較キーを選びやすくなります。

Switchから複数の条件に一致する経路へ送った行や、Split Outで親データから展開した明細も、意図された複数件かを先に確かめましょう。同じ親IDが繰り返されること自体は、誤った重複の証拠ではありません。

関連記事：n8nのIF・Switch・Filterの違いと条件分岐の作り方

複数経路への出力が仕様どおりかを整理し、除去すべき重複なのか、残すべき分岐なのかを判断する助けになります。親と明細の単位に迷う場合は、「n8nのAggregateとSplit Outでitemをまとめる・分ける」で、itemと配列の変換、残す親キーを確かめてください。

Current InputとPrevious Executionsは、比べる相手が違う

Current Inputは、その回に受け取ったitems同士を比較します。Previous Executionsは、今回の入力と保存済みの履歴を比べる操作です。

履歴が空で、今回のキーがA・A・Bという仮例を考えてください。Previous Executionsだけなら、Aに対応する2件も含め、A・A・Bが新規候補として残ります。

先にCurrent Inputで同じキーをまとめれば、その後で履歴へ渡す候補はA・Bです。これは、入力内の整理と履歴比較を二段階にする理由となります。

ここでいう除去は、次へ渡すitemsを選ぶことです。元のデータベースやRSS、受信元のレコードを削除する操作と混同しないでください。

入力内の比較項目と、残すレコードを設定する

完全に同じ内容だけをまとめるならAll Fields、業務上のIDで比べるならSelected Fieldsを使います。取得時刻など特定の項目だけを無視したい場合はAll Fields Exceptという選択です。

次の2行は、同じIDに古い内容と新しい内容を持つ、説明用の仮データとして読んでください。実行結果や、実際の記事データを示したものではありません。

All Fieldsでは、titleとupdated_atが違うため、この2行は別の内容として残ります。Selected Fieldsでidだけを比べると、同じAとして代表を一つ選ぶことになるのが違いです。

All Fields Exceptでupdated_atだけを除外しても、titleが違うこの例は同じ行にはなりません。「何か一つの項目を無視した」と「IDだけで比べた」は分けて考えてください。

同じIDなら、最新版を自動で残すわけではない

確認した固定版のCurrent Inputでは、比較値が同じ正常な行は入力順の先頭が残る仕組みです。上の順序でidだけを比べると、残す候補は10時の旧内容になります。

更新日時が欠けている行や、日付として読めない値は、並べ替える前に要確認の経路へ分けてください。タイムゾーンも同じ基準へそろえ、表示されている文字列の見た目だけで新旧を決めないことが大切です。

入力順の先頭を代表にするのか、最新を代表にするのか、内容が違えば人が確認するのかを先に選びます。複雑な優先順位や複数行の集約を、Remove Duplicatesだけに任せる場面ではありません。

1. 隔離した試験用workflowを用意する

   元の入力と設定を保存し、仮のIDを持つ数件のitemsを使ってください。通知・投稿などの外部送信は接続せず、比較結果だけを確認できる構成にします。

2. 入力内の操作と比較項目を指定する

   OperationでCurrent Inputの操作を選び、ID比較ならCompareをSelected Fields、Fields To Compareをidに設定しましょう。全項目比較や除外項目を使う場合も、何が一致したら同じと扱うかを書き出すことが必要です。

3. 残す行の優先順を前段で整える

   最新版を残すなら、有効な更新日時の降順と同順位の規則を先に用意します。最初に届いた行を残す用途なら、その入力順を代表の根拠として記録してください。

4. 出力の件数・ID・必要項目を照合する

   試験用のExecute stepで確認し、残ったIDと内容が期待どおりかを見ましょう。少なくなった件数だけで判断せず、後続に必要なURLや親IDも残ることが完了条件です。

欠損・空値・型と、複合キーの境界をそろえる

必須キーが欠ける行は、正常な重複判定へ入れる前に理由付きで分けて残しましょう。すべてを0や空文字に置き換えると、本来別々の行を同じキーへ集める原因になります。

• 文字列の「1」と数値の1は、型をそろえるか、別物として残すかを決める
• null・未定義・空文字を、正常な識別子として流さない
• 大文字と小文字に意味があるIDを、勝手に小文字化しない
• 元のIDと元値を残し、正規化した値から元のレコードをたどれるようにする

項目の欠損や型の不一致は、固定版の入力内比較でエラーになる原因の一つです。一方、履歴比較のValue Is Newは値を文字列化するため、数値1と文字列の「1」、欠損と空文字を安全に区別してくれるとは考えないでください。

複合キーも、単純な文字列連結では境界が曖昧になります。たとえば「ab＋c」と「a＋bc」がどちらもabcになる作り方は避け、元の二項目を区別できる構造や、衝突しないエンコードの規則を決めることが必要です。

関連記事：n8nのExpressionとEdit Fieldsでデータを整える

現在のitemからIDを参照し、型や出力へ残す項目をそろえるところまで確認できます。より複雑な優先規則を組む場合は、次に確認したいこと：Codeで複数itemを加工するという内容へ進み、式だけでは難しい再構成を整理してください。

過去実行との比較は、未見の値と最大値を使い分ける

任意のIDが過去に登場したかを調べるなら、Value Is Newを使います。番号や日付の最大値を超えたものだけを通す方式は、遅れて届く古い値を落としてよい用途に限る選択です。

たとえば最大IDが100の状態で、初めてID99が届く仮例を考えてみましょう。ID99が保存済み集合にないValue Is Newなら候補になりますが、最大値を超える方式では通りません。

番号の欠番や順不同がある業務で「数字だから最大値」と決めないでください。日時を使う場合も、有効なISO形式とタイムゾーンをそろえ、同値・直前・直後の値がどうなるかを試験します。

Value Is Newの最小構成は、次の順序です。

1. OperationでRemove Items Processed in Previous Executionsを選ぶ
2. Keep Items WhereでValue Is Newを選ぶ
3. Value to Dedupe Onに、今回のitemから比較する値を指定する

前段でdedupe_keyを用意したなら、Value to Dedupe Onを式として入力し、現在のitemを参照する「{{ $json.dedupe_key }}」などを指定してください。

過去実行との比較では、残す候補はKept、履歴によって除外された候補はDiscardedで確認できます。後続へ進める対象をKept側で照合し、除外したitemsを同じ通知・投稿の処理へ戻していないかも確認してください。

Scopeと履歴サイズを確認し、初回と再回の入力を分けて試しましょう。入力内にも重複があるなら、ここへ渡す前にCurrent Inputで整理する順序を保ってください。

関連記事：n8nのRSS取得｜更新通知と重複の扱い

RSSを扱う人は、記事ID・公開日時・取得した位置と、通知済みの状態を分けて確認できます。古い記事の遅延到着や、日付が変わらない改稿を取りこぼしたくないときに読む内容です。

履歴の保存範囲・容量・消去の影響を確認する

履歴をほかのノードと共有する必要がなければ、基本はNode scopeと考えてください。同じworkflow内で共有したい場合だけWorkflow scopeを選び、比較キーの意味もそろえます。

別々のフィードに記事番号Aがあるなら、Workflow scopeでAだけを共有すると、異なる記事を同じものとみなす恐れがあります。フィードIDと記事IDの組など、共有しても意味が衝突しないキーを先に設計することが必要です。

固定版ではworkflow IDとnode IDに対応して履歴を管理します。ノードの名前を変えることと、複製・作り直しでnode IDが変わることを、同じ履歴移行として扱わないでください。

History Sizeは永久記憶の保証ではない

Value Is NewのHistory Sizeは、既定が10,000件です。覚えられる範囲を無制限にする設定ではなく、上限に近付いた場合の挙動も利用版で確認してください。

確認したn8n 2.45.5・ノード版2には、保存済み件数と今回の入力item数の合計が上限を超えると、履歴比較の処理前にエラーにする分岐があります。新しいIDの種類が少なければ必ず通る、古い履歴が自動で循環するので常に止まらない、といった説明はできません。

容量の異常が出た場合は、外部送信を止め、導入版・Scope・現在の件数・入力件数・設定値を調べてください。上限を変える場合も、必要な記憶期間と運用負荷を確かめ、履歴全消去をいつもの解決策にはしないことが大切です。

手動テストとClear Historyは、履歴を変える操作として扱う

同じ本番workflow・同じノードでExecute stepを押しても、手動専用の独立した履歴になるとは考えないでください。固定版の履歴管理はworkflowとnodeを基準にし、手動/本番の実行モード別の分離を提供していません。

履歴を持つテストは別workflow・仮のキー・外部送信なしで行い、初回A・B、再回A・B・Cを試し、再回はCだけが新規候補になるかを確認します。

Node scopeで消す場合も、別のClearノードを新設すれば元ノードの履歴を消せる、という意味にはなりません。どのnode IDを対象にしているかを照合し、Workflow scopeなら共有する相手への影響も確認してください。

Clear Historyは外部の元データを削除する操作ではありませんが、消した履歴を自動で元どおりにするUndoも保証されていません。設定を元へ戻すことと、保存履歴を復元することは別です。

誤って履歴を消したら、まず下流への送信を止めましょう。送信先と成功済みの記録を照合し、再処理してよいIDが分かるまで、一括で流し直さないようにします。

履歴で見た値と、下流で成功した処理を分ける

Remove Duplicatesの履歴は、その値をこのノードで見た記録です。外部の通知やWordPress投稿が成功したことを示す台帳として、そのまま使わないでください。

反対に、送信先では成功したのに応答だけ途絶えた場合もあります。この状態を失敗と決めて再送する前に、送信先の結果IDや業務キーで実際の結果を照会することが必要です。

これらは処理状態を分けるための設計例で、Remove Duplicatesに同名の成功管理機能があるという説明ではありません。状態や結果IDを持つ記録先にはData Tableなどを使えますが、保存先を足すだけで厳密な一度だけ処理が完成するわけではない点も押さえてください。

外部処理より前に成功扱いにすると、実際には失敗した処理が欠落します。一方、外部処理の成功後、台帳へ記録する前に停止すれば、次回に同じ処理を送ってしまう余地があるのです。

並行実行がある場合も、単純な「記録がないか確認→送信→記録」だけで、ほかの実行を排除できるとは限りません。重要な書込みでは、送信先が用意する冪等キー、一意制約、処理する権利を先に確保する仕組みなどを、対象システムに合わせて検討します。

成功確認済みは再送しない、失敗が確定したものは対象IDだけ再処理、結果不明は送信先の照会を先に行う、という分岐を決めましょう。履歴全消去や無条件リトライで、失敗と不明をまとめて片付けないことが大切です。

失敗が確定しており再処理を許可したIDは、元の入力と成功記録を照合したうえで、再処理専用の分岐へ渡す設計にします。同じ履歴ノードを先頭から通すだけでは再び落ちることがあるため、通常の新規判定と、確認済みの再処理対象の選別を分けてください。

次に確認したいこと：WordPressの投稿IDを照合して下書きを更新する

WordPressへ保存する人が、既存投稿を探して更新するか、新規作成するかを整理するための案内です。Remove Duplicatesの既見判定だけで再投稿を防ごうとせず、保存先の投稿IDと実際の状態を確認する手順へ進めます。

導入前は、残すIDと失敗後の動きを試験する

試験では、何件消えたかより、残すべきIDと内容が一致するかを確認してください。次の表は隔離したworkflowで使う試験計画であり、この記事で実行した結果ではありません。

• 比較キーの意味と型、残す優先順を説明できる
• 必要なID・親子関係・本文・URLを出力から落としていない
• 入力内と過去履歴の、どちらで除外されたかを分けて確認できる
• Scope・履歴サイズ・テスト対象が本番と混ざっていない
• 失敗確定と結果不明の再処理ルール、送信先の照会方法がある
• 元の入力と設定を保存し、履歴の復旧とは分けて戻し方を決めている

不一致が出たら外部送信を止め、保存した入力と設定から読み取り結果を再確認しましょう。設定前の出力へ戻しても、既に記録された履歴や送信済みの通知まで取り消せるとは考えず、変更した状態ごとに復旧を判断します。

費用や基盤も別に見直す場合は、次に確認したいこと：n8nの継続費用と運用方式、または次に確認したいこと：VPSの費用と管理範囲という案内も参考に、重複除去の設定とは分けて継続費用と管理範囲を整理してください。

まとめ｜残すIDと成功結果を確かめてから重複除去を使う

Remove Duplicatesは、キーと残す行を決め、入力内か過去実行かを選んで使います。両方が必要なら入力内の整理を先にし、履歴に見た値と下流の成功結果は分ける設計です。

まず仮のID数件で、初回・再回・内容差・空キー・失敗後の動きを隔離試験し、残すIDと必要項目を照合してください。一致した範囲から導入し、履歴を消す操作や本番ノードの手動試験は、状態を変える作業として扱います。

重複除去で重視したいのは、出力件数を最小にすることより、なぜそのIDを残したか説明できることです。比較と成功確認を分けておくと、必要な行の消失と、誤った再送の両方に気付きやすくなるでしょう。