n8nのRemove Duplicates｜今回の入力と過去の実行を分けて重複を除く

n8nで重複を除いたはずなのに、翌日に同じデータがまた登録された。逆に、再実行したら必要なデータまで消えた。Remove Duplicatesを使うときは、何を同じとみなすかに加えて、どの範囲と比べているかを見る必要があります。

一回の入力の中で重なるものを除く操作と、過去の実行で見たものを除く操作は別です。目的に合わせて選ばないと、ノードは設定どおり動いていても、期待した重複防止にはなりません。この記事では、比較する値、履歴、再実行の関係を整理します。

重複の範囲を先に決める

まず「同じもの」の定義を決める

同じ人から二件の申し込みがあっても、受付番号が違い、別の商品なら二件とも必要かもしれません。メールアドレスが同じという理由だけで一件を除くと、正当な注文まで落とします。名前、受付ID、注文IDのどれで判断するかを、データの意味から決めましょう。

AIで文章を要約する前処理でも同じです。見出しが同じ記事でもURLや改訂日が違えば、別の資料として扱いたい場合があります。反対に、取得時刻だけが違う同じ資料なら、全文一致では重複と判定できないことがあります。

比較対象は「何の重複を減らすのか」に合わせます。資料の同一性を見たいのか、同じ処理を繰り返したくないのか、最新版だけを残したいのか。一つのキーで全部を解決しようとせず、必要なルールを短い文章で書いてから設定してください。

一回の入力内と、過去の実行を分ける

Remove Items Repeated Within Current Inputは、今回入ってきたアイテムの中で重複を探すための操作です。今回の入力に同じ受付IDが二件あれば、それらを整理する用途に使います。過去の実行ですでに処理したかまで、自動的に同じ範囲へ含めるわけではありません。

Remove Items Processed in Previous Executionsは、過去の実行で見た値と比較する操作です。例えば、定期的に同じ一覧を取り込んで、新しく出てきたIDだけを次へ渡したい場合に検討します。今回の入力内の重複も含めて整理したいなら、それぞれの役割を分けて構成します。

公式の例でも、現在の入力と過去の実行の両方を扱う場合は、二つのRemove Duplicatesを順につなぐ方法が示されています。ただし、つなげば外部サービスへの二重登録を永久に防げるという意味ではありません。後段の処理が成功したかをどう管理するかは別の設計です。

比較項目を絞り、元の情報を残す

今回の入力内で比較するときは、全項目を比べる方法と、指定した項目で比べる方法を選べます。全項目を選んだ場合、取得時刻や補足メモが少し違うだけで、別のアイテムとして残ることがあります。逆に項目を絞りすぎると、残すべき別データを同一視します。

例えば受付IDを使うなら、IDが本当に空欄ではないか、発行元が変わって同じ番号が再利用されないかを見ます。複数サービスの受付を混ぜるなら、サービス名とIDを組み合わせて区別する考え方もあります。これは入力元の仕様を確認して決めるものです。

比較に使わない項目まで出力から取り除く設定にも注意します。重複判定に不要でも、その後の処理には顧客区分や元URLが必要かもしれません。重複を減らした結果、後続の処理に渡す資料が欠けていないか、出力の中身まで見てください。

過去の履歴は、永続的な受付台帳とは違う

過去の実行と比較する操作には、保存する履歴の範囲や量に関する設定があります。ノードごとに独立させるか、ワークフロー内の対象ノード間で共有するかによっても影響範囲が違います。一つのノードで履歴を消すつもりが、別の判定にまで影響しないか確認してください。

履歴に件数の上限があることも踏まえます。いったん見たIDが、どれだけ時間がたっても必ず除かれると考えるのは避けましょう。業務上、過去の注文を長期にわたり再登録してはいけないなら、登録先の一意制約や専用の処理台帳も含めて設計します。

また、「見たことがある」と「最後まで処理できた」は同じではありません。重複判定の後で書き込みが失敗した場合、再実行時にどこから復旧するかを決めておかないと、必要な一件を流せなくなる可能性があります。後段の成功を自動保証する機能として扱わないでください。

小さな入力で残る件数と内容を比べる

テストには、同じIDを二件、別のIDを一件用意します。まず一回の入力だけを整理したときに、何件残り、どの内容が出るかを見ます。次に同じデータをもう一度入れ、過去の履歴と比較する操作で結果がどう変わるか確かめます。

さらに、同じIDで金額や更新日を変えたデータも用意します。今回の目的が「新しいIDだけ通す」ことなら除かれるのが正しいかもしれませんが、「更新内容を反映する」ことが目的なら、別の比較や更新処理が必要です。残った件数だけでは正誤を決められません。

空欄のID、前後に空白があるID、数字に見える文字列も試します。表計算から取り込んだ「001」と、数値の1を同じものにしたいかは運用次第です。先頭ゼロが意味を持つ番号は、安易に数値化してそろえないようにします。

試すときは本番の登録先を使わず、元データと結果を照合できる場所へ出します。「三件が二件になった」という数字に加えて、落ちた一件が何だったのかを追えるようにしておくと、ルールの間違いを具体的に直せます。

履歴を消す前に復旧の対象を決める

Clear Deduplication Historyは、過去の実行と比較するための記憶を消す操作です。過去に作られた外部サービスのレコードを消す操作ではありません。履歴を消して同じ一覧を流すと、すでに登録済みのものまで再び通る可能性があることを踏まえてください。

失敗した一件だけをやり直したいなら、先に登録先の状態と元IDを確認します。すべての履歴を消して解決しようとせず、その一件が未登録なのか、一部だけ処理済みなのかを切り分ける方が、二重処理を防ぎやすくなります。

引き継ぎには、比較キー、現在入力か過去実行か、履歴の範囲、消去してよい条件を残します。ノード名も「重複除去」だけでなく「受付IDで新規を抽出」のように目的を含めましょう。あとから設定を触る人が、消してはいけない判断材料を見分けられます。

確認日：2026年10月16日。仕様はn8n公式 Remove Duplicatesと同ページの公式例を確認。入力例・受付台帳の設計は説明用の提案です。旧版のノードでは設定が異なります。