顧客一覧と注文一覧をn8nで結合したら、別の人の注文が同じ行に入ってしまった。件数が合い、エラーも出ていないと、この間違いは見逃しやすくなります。Mergeでは、二つの入力をどの関係で合わせるのかを先に決める必要があります。
同じ順番に並んでいるという理由だけで結合せず、共通のIDで対応を確かめましょう。この記事では顧客IDを使う仮定例を通して、Matching Fields、Position、結合できないデータの扱いを整理します。
追加と結合は、似ていても結果が違う
MergeのAppendは、複数の入力のアイテムを順につなげて出すためのモードです。片方に名前、もう片方に注文金額があっても、同じ顧客の情報を自動で一行へまとめる操作とは違います。単純に一覧を長くしたいときと、項目を付け足したいときを区別してください。
一つの顧客レコードへ注文情報を加えたい場合は、Combineの設定を検討します。その中でも、項目の値で合わせるMatching Fieldsと、入力内の順番で合わせるPositionでは、同じデータから異なる結果になります。
例えば顧客一覧がA、Bの順で、注文一覧がB、Aの順だったとします。順番で結合すると、先頭同士でAとBが合わさります。二件が二件として出力されても内容は誤りです。このように、件数が合うことだけでは結合の正しさを判断できません。
対応するIDを決め、型も確認する
Matching Fieldsでは、両方の入力で対応させたい項目を指定します。顧客側が「customer_id」、注文側が「buyer_id」という名前でも、意味として同じIDかを確認して選びます。項目名が似ているだけで、注文番号と顧客番号を合わせないよう注意してください。
表示上は同じ数字でも、数値か文字列かで比較結果が変わる場合があります。公式には型の違いを許容する比較設定もありますが、原因を見ずに有効にすればよいわけではありません。「001」のような識別番号は、先頭ゼロを失ってよいかを入力元の仕様で判断します。
前後の空白や、大文字と小文字、別システムのID体系も確認します。表記をそろえる前処理をするなら、変換前の値も残しておくと調査が楽になります。AIに似た名前から同一人物を推測させた結果を、確定したIDの代わりとして使わないでください。
一致しなかったデータをどこへ残すか
一致したものだけを残す設定では、対応相手が見つからないアイテムは結果から外れます。必要な注文が少なく見えたときは、取り込みの失敗だけでなく、結合条件に一致しなかった可能性も見ます。元の件数と結合後の件数を比較してください。
顧客一覧を全件残し、一致した注文だけを付け足したいなら、Input 1を残すEnrich Input 1のような出力方法を検討します。一方、注文側を全件残したいなら入力の置き方と出力の選択が変わります。「どちらの一覧を基準にするか」を説明できる構成にしましょう。
Keep Everythingのように不一致も含める方法を選んだ場合は、必要な項目が欠けた結果が後続へ流れることを想定します。顧客名のない注文を、そのまま宛名付きのメール生成へ渡さないようにします。不一致を確認用に分けるか、後続を止める条件を決めておく必要があります。
一致しなかった理由を、すぐ「存在しない顧客」と決めつけるのも早計です。片方の取得範囲が狭い、ページの続きが取れていない、IDが別形式になっている可能性もあります。削除や新規作成へ進む前に、入力側の不足を調べてください。
同じIDが複数ある場合は件数が増える
顧客一人が複数の注文を持つことは自然です。したがって、同じ顧客IDが注文一覧に二件あるだけで異常とは限りません。一人につき一行の一覧にしたいのか、注文ごとに一行残したいのかで、結合前後の設計が変わります。
Mergeには複数の一致を扱う設定があります。すべての一致を出す場合と最初の一致だけを使う場合では、結果が違います。最初の一件だけにすれば見た目の件数は減りますが、必要な注文を捨てることにならないか確認してください。
一人ごとの注文合計が欲しいなら、単に最初の注文を選ぶのではなく、集計の工程が必要です。逆に注文の明細を確認したいなら、複数行のまま残した方が用途に合います。結合機能の設定で、集計やデータ品質の問題まで隠さないようにしましょう。
同じ名前の項目が上書きされないか見る
両方に「status」や「name」がある場合は、その意味を比べます。顧客側のstatusが会員状態、注文側のstatusが配送状態なら、同名でも別の情報です。一つの項目へまとめる前に、customer_status、order_statusのように区別する考え方が有効です。
公式では、同名項目が競合したときの扱いをClash Handlingで設定できます。既定の優先順位に任せる場合も、何が残るかを確認します。片方の値が消えてから「入力に入っていなかった」と誤解しないよう、両入力と出力を並べて見る段階を設けてください。
入れ子になったデータは、どの階層まで統合するかも結果に関わります。住所の一部を付け足すつもりが、住所全体の扱いを変えてしまわないか注意します。複雑なデータを最初から全部渡すより、必要な項目に絞った小さな例で挙動を確かめましょう。
並べ替えと欠損を入れてテストする
試験用の入力には、同じ順番の二つの一覧だけを使わないでください。片方を逆順にし、一致しないID、同じIDが複数ある行も加えます。それでも期待した対応ができれば、順番に偶然助けられていた構成を見つけやすくなります。
テスト前に、期待する出力を手で作っておきます。顧客Aへ注文Aが付き、顧客Bの未注文状態が残り、未登録顧客の注文は確認用に出る、といった形です。実行結果を見てから正解を変えるのではなく、先に決めた用途と照らし合わせます。
最後に、結合後のデータを使う処理も一件試します。表への登録ができることと、必要な情報が正しく対応していることは別です。顧客ID、注文ID、元の参照先を残しておけば、問い合わせが来たときにも元データまで戻って説明できます。
引き継ぎには、入力の役割、対応項目、不一致と複数一致の扱い、同名項目の優先順位を書きます。Mergeという名前だけでは、残すべきデータの判断は伝わりません。どの行がなぜ残るかを説明できることが、結合を運用する土台になります。
確認日：2026年10月16日。設定の役割はn8n公式 Mergeを確認。顧客・注文の例は説明用の架空データです。版によって利用できる項目が異なります。
コメント