n8nのCode node後に前のデータを参照できないときの確認

n8nのCode node後に前のノードを .item で参照できなくなった場合は、出力itemと入力itemの対応を確認します。エラーを消すためだけに .first() へ置き換えると、別の顧客行や注文行を参照するおそれがあります。

エラーを二つに分ける

n8nの公式資料は、対応情報が欠ける場合と、対応先が複数ある場合を分けています。参照先が別ブランチにある場合も確認対象です。エラー全文、参照式、n8nのバージョン、Code nodeの実行モード、入力・出力item数を記録します。n8n：Item linking errors（新しいタブで開く）

表は横にスクロールできます

症状	確認すること
対応情報が欠ける	どのノードから入力由来を追えなくなったか
複数のitemが一致する	集約や結合で複数入力を一つにしたか
別ブランチの参照	現在itemからそのノードへ対応を追える構造か

item数が同じでも順序が変われば、出力の0番目が入力の0番目とは限りません。Code node直前と直後だけでなく、参照先までの経路を確認します。

少数の架空itemで対応を書く

検証用に、顧客IDが異なる三行を用意します。各出力について「どの入力から作ったか」を表にして、並べ替え、絞り込み、分割、集約の有無を記します。業務IDは確認用に残し、n8n内部の対応情報と同一視しません。

表は横にスクロールできます

出力	元の入力index	業務ID	変換
0	2	C003	並べ替え
1	0	C001	並べ替え
2	1	C002	並べ替え

この場合、出力indexをそのまま対応先として付け直すと誤ります。元の入力indexを変換前から保持する設計が必要です。

一対一の変換でpairedItemを保つ例

次は、All Itemsをまとめて処理するJavaScriptのCode nodeを想定した説明用例です。入力順序を変えずに一行ずつ新しいitemを返します。実際のn8n環境では未実行です。

const input = $input.all();
return input.map((item, inputIndex) => ({
  json: {
    customerId: item.json.customerId,
    reviewed: false,
  },
  pairedItem: inputIndex,
}));

公式資料は、新しいitemを返す際などに pairedItem を明示する方法を説明しています。この例のindexは、Code nodeへの入力配列の位置です。絞り込み後のindexや、顧客IDを代入する値ではありません。n8n：Preserving linking in the Code node（新しいタブで開く）

このコードをそのまま既存処理へ貼ると、元のJSON列やbinaryなどが失われる可能性があります。自分の処理で必要な出力を保持し、どの入力由来かを正しく付ける部分を見直してください。

複数入力を一つにした場合

集約した売上合計など、一つの出力が複数の入力からできる場合、前の顧客一件を .item で求める設計自体が曖昧です。必要なのが顧客ごとの値か、全件集計かを決め、集約前に必要列を持たせる、必要なitem集合を明示的に扱うなどの設計へ戻します。

位置指定で一件を取る方法は、対象の位置が意図として決まっている場合に限って検討します。「先頭に取れたから正しい」という確認では、顧客の取り違えを防げません。

修正後に確かめること

まず外部送信や更新ノードを実行しない検証用の流れで、入力IDと参照結果のIDを全行照合します。三行の順序変更、途中行の除外、一対多の分割、複数行の集約を、自分の処理に必要な範囲で試します。欠損や曖昧な対応がある場合に、別行で埋めず停止することも確認します。

AIものさしの判断

エラーが消えることより、参照先のレコードが正しいことを完了条件にします。この記事は公式仕様と架空例に基づく手順です。利用中のn8nの版と実行モードで検証し、成功を確認するまで実データの送信・更新へ進めないでください。