n8nのMergeノードでデータが取れない原因と直接参照で解決した方法

n8nでGoogle Driveから複数ファイルを並列取得してMergeノードで統合したのに、後続のCodeノードで $input.all() を使ってもデータが揃わない、という問題に何度もハマりました。最初はファイル取得の失敗やJSONのパースエラーを疑いましたが、原因はMergeノードのAppendモードでRunが複数に分かれていたことでした。

この記事でわかること：

• n8nのMergeノード（Appendモード）でRunが分割される仕組み
• $input.all() で全データが取れない理由
• $('ノード名').first() で直接参照して安定させる方法
• 直接参照が向いているケース・向いていないケース
• ノード名依存のリスクと命名ルールの考え方

MergeノードのあとにCodeノードでデータが揃わなかった

詰まった状況はこんな感じでした。

フロー1の記事生成前半で、Google Driveから複数の管理ファイルを取得していました。それぞれのノードが並列で動き、最後にMergeノード（Appendモード）でまとめてから、後続のCodeノードで各ファイルの内容を使って処理を進める設計でした。

ところが、Codeノードで $input.all() を使って全ファイルの内容を取ろうとすると、「あるはずのデータ」が取れなかったり、一部がnullになったりしました。

「ファイル取得に失敗しているのかな？」と思って各ノードの出力を確認すると、ファイル取得自体は成功しています。JSONも正しくパースされています。それなのに、Merge後のCodeノードでは揃わない。原因が分からず、しばらく迷子になりました。

今回の構成：並列4本でGoogle Driveを取得してMergeしていた

問題が起きた構成はこうでした。

記事自動生成フローの前半で、以下のファイルをGoogle Driveからそれぞれ別のノードで取得していました。

• internal_links.csv（内部リンク候補）
• title-rules（タイトルルール）
• _index.json（投稿済み記事のインデックス）
• keyword_done.csv（記事化完了キーワード）

これらは並列で動くノード構成で、それぞれが独立して取得処理を実行します。その結果をMergeノードのAppendモードで1つにまとめ、後続のCodeノードに渡す設計でした。

後続のCodeノードでは、これらの情報を使ってslug生成や記事設計の処理へ進む予定でした。ノードをつないだ段階では「Mergeで全部まとめれば大丈夫」と思っていました。

原因はAppendモードでRunが複数に分かれていたこと

原因に気づいたのは、MergeノードのOutput画面をよく見たときでした。

画面上部に「Run 1 of 2」や「Run 2 of 2」のような表示が出ていました。「Run？　2つある？」と思って調べて、ようやく仕組みが分かりました。

n8nでは、ノードの実行結果が「Run」という単位で分かれることがあります。少なくとも私の構成では、MergeノードのOutputが「Run 1 of 2」「Run 2 of 2」のように分かれていました。バージョンや構成によって挙動が変わる可能性もありますが、この記事では私の環境で起きた実践ログとして記録します。

Merge（Appendモード）の出力：
  Run 1 of 2 → internal_links.csv の内容
  Run 2 of 2 → _index.json の内容

そして、後続のCodeノードで $input.all() を使うと、「現在のRunに入っているアイテム」だけが対象になります。別のRunにあるデータは見えません。

つまり、$input.all() は「そのCodeノードに渡ってきている入力の全アイテム」であって、「そのワークフローの全ノードの全データ」ではありません。Mergeの結果がRunで分かれていると、1回の実行に全アイテムが揃っていない状態になります。

`$input.all()`で全データが取れると思っていた誤解

n8nのCodeノードを使い始めたとき、$input.all() を使えば前段の全アイテムを取れると思っていました。これは半分正解で半分誤解でした。

正確には、$input.all() は「現在の入力（current input）にある全アイテム」を返します。Mergeの出力が1つのRunにまとまっていれば全部取れますが、Runが分割されているとRunごとに見える範囲が異なります。

n8nでは「現在の入力」と「特定ノードの出力への参照」は別の概念です。

• $input.all() → 現在のCodeノードに渡ってきているアイテム（Run依存）
• $('ノード名').all() → 指定したノードの全実行結果（Run分割を超えて参照できる場合がある。ただし複数Run・複数アイテムを扱う場合の挙動は構成に依存するため注意が必要）
• $('ノード名').first() → 指定したノードの最初の実行結果（この記事では1ファイル1アイテムの管理ファイル取得に限定して使用）

この違いを理解してから、設計の考え方が変わりました。

解決策：`$('ノード名').first()`で必要なノードを直接参照する

解決策はシンプルでした。Merge結果に依存するのをやめて、必要なノードを名前で直接参照することにしました。

const internalLinks = $('internal_links.csv取得').first().json;
const titleRules = $('title-rules取得').first().json;
const index = $('_index.json取得').first().json;
const keywordDone = $('keyword_done.csv取得').first().json;

return [{
  json: {
    internalLinks,
    titleRules,
    index,
    keywordDone
  }
}];

$('ノード名').first() は、指定したノードの最初の実行結果を直接取りに行きます。MergeノードのOutputがRunで分かれていても、各取得ノードの結果は独立しているため、この参照方法であれば安定して取得できました。

「Mergeで全部まとめてからCodeで処理する」という発想から、「Codeノードで必要なノードを明示的に読む」という設計に切り替えた形です。

直接参照に変えて安定した理由

$('ノード名').first() を使うと、Mergeノードの出力状態に左右されなくなります。