n8nのMergeでキーと件数を確かめて結合する

以下は、左3件・右4件の架空データで考える2入力の基本結合の説明です。数値は公開仕様から組み立てた期待値で、n8n上の実測結果ではありません。

追加・キー照合・位置結合から方式を選ぶ

Mergeの設定を開く前に、欲しい出力を小さな表で描くのが近道です。「データを一つにする」という言葉には、一覧の追加と属性の結合という異なる処理が含まれます。

AppendとCombineは、増やす方向が違う

Appendは入力のitemsを順に並べて追加するモードです。たとえば別々の受付から届いた同形式の依頼を、一つの処理経路へ流したい場面が該当します。

一方、Combineは二つの入力から行を組み合わせ、両側のフィールドを持つitemを作るためのモードです。注文と顧客情報のように、同じIDを手掛かりに別の情報を付けたいときはこちらを検討してください。

Appendは重複除去ではありません。同じ注文が左右に1件ずつあれば、追加しただけでは2件とも残ります。

また、複数itemsを1itemの配列にまとめる処理はAggregateの役割です。配列を別々のitemsへ展開するSplit Outとも区別してください。既存の値を一つの設定欄から参照したいだけならExpressionで足りる場合があり、結合ノードの追加が必須とは限りません。

Positionは、件数が同じでも安全とは限らない

Positionはキーの値を調べず、入力内の位置で組を決めます。両側に同じ件数があることと、同じ対象が同じ位置にあることは別の条件です。

左の行が「Aの1件目、Aの2件目、B」、右が「Aの1件目、Aの2件目、Aの3件目、C」という並びなら、最初の3組は位置だけで作られます。3組目では、左のBと右のAが結び付き、期待するID照合になりません。

同名のkeyが競合すると既定でInput 2の値が残るため、出力のkeyだけを見ても左のBを見落とします。左右の行IDを保持し、結合前の値までたどって照合してください。

片側だけでFilterやSortを使った場合も、元の対応は崩れ得ます。後段の表示が自然に見えても、各行の出所まで確認してください。

対象をIDで定義できるならMatching Fieldsを主経路にしましょう。All Possible Combinationsは左右のすべてを組み合わせる方式なので、通常のID照合の代用品にはなりません。

キー重複・型・未一致の扱いを決める

キーで結合するときは、フィールド名に加えて一意性と、残す行の範囲を決めます。この二つは、件数の増加が仕様どおりかどうかを見分ける手掛かりです。

同じキーが左右にあると、複数の組ができる

検証には、業務データの代わりに次の架空入力を使ってください。keyはすべて文字列で、行そのものを見分けるIDは左右で別名にします。

まず、Multiple MatchesをInclude All Matchesにしてください。この設定では、一致する相手ごとにitemが作られます。この例のAは左2件×右3件なので、Aだけで6組が期待される計算です。

照合する組はL1–R1、L1–R2、L1–R3、L2–R1、L2–R2、L2–R3の六つになります。keyが同じという理由で、自動的に1件へ集約されるわけではありません。

この表は仕様から計算した予測値です。AppendとEnrich Input 1はどちらも7件ですが、前者は追加、後者は結合と未一致保持で、内容は異なります。

「増えたから失敗」と決めず、まずキーごとの左件数×右件数を調べてください。顧客1件へ最新の属性1件だけを付けたいのに右側が3件あるなら、結合前に採用基準を決める必要があります。

Include First Match Onlyは最初の一致だけを残す設定です。これで件数が減っても、「最初の1件」が最新・有効・優先対象とは限らないため、更新日時や状態に基づく業務上の選択規則を先に固めましょう。

未一致は、目的に応じて残す側を選ぶ

一致した組だけ必要ならKeep Matches、左の一覧を基準として相手情報を補うならEnrich Input 1を選びます。左右どちらの未一致も調べたい場合は、Keep Everythingが候補です。

たとえば左を全注文、右を任意の付加情報とするなら、右に相手がないだけで注文そのものを落とすかどうかが判断点になります。未一致の存在を異常として検出したい段階では、欠けた側の行を識別できる出力を残してください。

キーのない行は、未一致の通常例と混ぜずに入力不備として切り分けるのが分かりやすい設計です。空文字やnullを共通キーとして扱う意図があるのかを決め、必要に応じて結合前に別経路へ出します。

型と同名フィールドを整え、出所を残す

数値の3と文字列の”3″は、型が違う値です。Fuzzy Compareはこの差を許容するためのオプションで、公式文書では既定が無効とされています。

有効化すればよい、と一律には判断できません。”003″のような先頭ゼロを持つ識別子を数値化すると、別のIDと区別できなくなるおそれがあるためです。

まず、キーを文字列として扱うのか数値として扱うのかを統一しましょう。文字列の前後空白や大文字・小文字も、同じ対象を指す条件に含めるかを入力側で決めてください。

同名フィールドにも注意が必要です。左右にstatusがある場合、既定の競合処理ではInput 2の値が優先されるため、左の値を知らないまま上書きされたように見えることがあります。

初回の検証は、左をleft_status、右をright_statusへ事前に分けておくと出所が明瞭です。行IDもleft_row_idとright_row_idで残し、照合キーだけを共通のkeyにします。

両入力の到達とバージョンを確かめる

正しい照合設定でも、相手の枝が実行されていなければ同じ条件で試せません。Mergeまで進まないときは、空データ・未実行・失敗を分けるところから始めます。

0件、未実行、エラーは別の状態

最初の主例は、同じManual Triggerから二つの検証用Codeノードへつなぎ、それぞれが非空の架空itemsを返す構成にしてください。CodeはどちらもRun Once for All Itemsを選び、Mergeの手前で入力が作られたことを確かめます。

左側のCodeには次のJavaScriptを入力してください。実データや認証情報は含めず、後段の送信・書込ノードも接続しない状態が前提です。

return [  { json: { left_row_id: 'L1', key: 'A' } },  { json: { left_row_id: 'L2', key: 'A' } },  { json: { left_row_id: 'L3', key: 'B' } }];

右側には次の4件を用意します。両方のCodeをMergeへ接続し、左をInput 1、右をInput 2として扱ってください。

return [  { json: { right_row_id: 'R1', key: 'A' } },  { json: { right_row_id: 'R2', key: 'A' } },  { json: { right_row_id: 'R3', key: 'A' } },  { json: { right_row_id: 'R4', key: 'C' } }];

この配線と入力は説明用の試験案です。利用環境でのノード実行は未実施なので、成功画面や実行済み結果としては扱いません。

最初から0件試験と型違いを同時に入れると、原因の区別が難しくなります。非空の主例が照合できた後、右を0件にする試験、右枝を未実行にする試験、右枝のエラー試験を別々に行ってください。

空入力でMergeに到達するか、何が出力されるかは、利用中のノード版と接続を含めた確認が必要です。見かけ上進ませるために空のダミーitemを無条件で足すと、本来ない行を後段へ渡してしまいます。

Choose Branchも、既に動いた側をすぐ拾う万能な代替ではありません。公式仕様では両入力のデータが利用可能になるのを待つため、片枝の未実行を解消する目的とは分けて考えましょう。

本体版・ノード版・実行順を分けて記録する

確認するのはn8n本体のバージョン、MergeのtypeVersion、workflowのexecution orderの三つです。本体を更新したことだけで、昔のworkflowまで同じ条件になったとは判断できません。

公式文書には、IFとMergeの組合せでIFの両枝が動く場合があるという説明もあります。ただし、これはv0（legacy）の実行順を使うworkflowに関する注意であり、現行のすべての環境へ広げる説明ではありません。

新規の検証用workflowでは実行順をv1として記録し、古いworkflowの設定を変えるときは複製上で試しましょう。利用者の実際の三つの値も、本記事の公式仕様確認とは別に記録してください。

期待する組を照合してから後段につなぐ

完了の条件は、件数・IDの組・未一致・競合値が、先に決めた規則と合うことです。出力件数だけの比較では、Positionによる取り違えや、同名フィールドの上書きを見逃します。

小さな入力から設定し、差を一つずつ確認する

1. コピーを作り、外部反映を切り離す

   未有効化の検証用workflowで、Mergeの後ろにSheets更新や通知がないことを確かめてください。既存のMode、照合欄、Optionsは変更前に記録しておきましょう。

2. 両入力へ架空データを用意する

   前節のCode例で左3件・右4件を作り、各ノードの出力で行IDとkeyを確認してください。両側の出力がそろってから結合設定へ進みます。

3. キー照合の条件を固定する

   ModeをCombine、Combine ByをMatching Fieldsとし、左右のFields to Matchへkeyを指定してください。Output TypeはKeep Matches、Multiple MatchesはInclude All Matches、Fuzzy Compareは無効という試験条件です。

4. workflow全体を手動実行し、6組を照合する

   出力のleft_row_idとright_row_idを使い、Aの6組がそろっているか見比べましょう。表示の行順が同じかより、必要なIDの組が欠けず重複せず存在するかが判断点になります。

5. 未一致保持と競合を個別に試す

   Output TypeだけをEnrich Input 1へ変え、次にKeep Everythingへ変えて期待表と比較してください。型違い・同名フィールドも、それぞれ別の試験対象です。設定変更と結果の対応を残しましょう。

結果が違ったときは、最初に「入力自体が変わっていないか」を確認します。入力が同じなら、モード、キー名、Multiple Matches、未一致保持、型、競合の順で差をたどると整理しやすい手順です。

やり直す場合は、元の設定へ戻すか、保存した検証用コピーへ差し戻してください。後段の書込を止めた状態なら、誤った組合せを外部へ反映せず比較を続けられます。

再実行しても同じ対象を処理できるか確かめる

基本例が合ったら、業務で必要なキーの一意性と欠損条件を含む小さな入力へ広げてください。結合の前提が変われば、期待する組と件数も再設計が必要です。

• 左右の入力件数と、キー別の件数を記録した
• 左右の行IDを出力へ残し、期待する組を照合した
• 未一致行を残す側と、欠けるフィールドを確認した
• 型違いと同名フィールドの扱いを決めた
• 空入力・未実行・エラーを分けて試す条件を用意した
• 同じ入力で再実行したときに必要な組が保たれることを確認する

Mergeの結果が正しくても、Google Sheetsの更新先の行を正しく選べるとは限りません。実際の書込では別途、安定した行キーと対象ファイルを確認し、書込後の再読で値を確かめる工程が必要です。

少量ずつ繰り返す必要がある場合は、Loop Over Itemsの設計へ進んでください。Mergeによる複数入力の結合と、バッチの反復を分けて確認するのは、どの段階で件数が変わったかを追うためです。

まとめ｜結合方式とキーを選び、IDの組で結果を確かめる

n8nのMergeは、縦の追加ならAppend、対象の照合ならMatching Fieldsという目的の区別から選びます。Positionを採るのは左右の順序が同じ対象に対応する場合だけで、重複キー・未一致・型・競合も結果を変える条件です。

まずは左3件・右4件の架空入力を用意し、期待する左右のIDの組を紙や表へ書いてください。外部への書込を切り離した検証用workflowで照合し、件数と内容の両方が合ってから実際の対象へ広げましょう。

結合の良し悪しは「何件になったか」よりも、「なぜその相手と組になったか」を説明できることにあると考えます。行の出所が分かる形を残しておくことが、位置ずれや上書きの誤りを調べるための足場です。

仕様確認：2026年10月31日。n8n公式Merge文書、公式文書の競合処理の補足、旧実行順の補足を参照。本文の操作名は英語表記を基準とし、利用環境の版・表示・実行結果は各環境で照合してください。