n8nのExpressionとEdit Fieldsでデータを整える

ExpressionとEdit Fieldsは何を担当する？

Expressionは、ノードの設定欄へ入れる値を入力データなどから決める式です。Edit Fieldsは、その式や固定値を使い、出力のフィールドを追加・上書きします。

「値を読む」と「後続へ渡す形を作る」を分けると、設定の役割が見えやすくなるでしょう。この記事では、次の2件を同じ設定で整える例を使います。

上の値は説明用の仮データで、n8nを実行して得た結果ではありません。まず期待する出力を決め、その形になるかを手元で確かめるための例です。

JSONの項目とitemの件数を分けて見る

n8nのノード間では、複数のitemが受け渡され、通常のデータは各itemのjson内に入ります。今回のarticle_idやviewsは、それぞれのitemが持つ項目です。

ここで区別したいのが、複数のitemsと1つのitem内にある配列。次の二つは、外見に角括弧があるからといって同じ処理単位にはなりません。

標準のEdit Fieldsは、入力された各itemへ設定を適用します。配列内の2要素を別々のitemにするなら、Split Outなどで処理単位を変えてください。

Edit Fields (Set)の名前と使いどころ

「n8n Set」で探している場合は、公式ドキュメントのEdit Fields (Set)が到達先です。旧名の検索語と現行の説明を結び付けておけば、別の製品や別機能と考えずに済みます。

固定値のdraftは、どのitemにも同じ文字列を付けたいときの設定です。一方、IDは入力ごとに変わるため、A101を固定欄へ貼らず、入力のIDを読むExpressionにしてください。

対象はCloud・self-hostedの標準ノードです。実利用のn8n本体版やEdit Fieldsのノード版によって、項目名や表示の組合せには差があり得ます。

Expressionで必要な値を参照する

参照式を選ぶ基準は、必要な値が「今の入力」「前ノードの対応するitem」「指定ノードの先頭」のどこにあるかです。式を短くする前に、どの1件を読もうとしているかを決めておきましょう。

今処理しているitemは$jsonで参照する

$jsonは現在の入力itemのJSONデータです。直下のarticle_idを読むなら、値の欄をExpressionにして次の式を使います。

{{ $json.article_id }}

今回の2itemなら、1件目にはA101、2件目にはA102が対応する設計です。authorの内側にあるnameは、{{ $json.author.name }}のように階層をたどります。

値が出ないときは、入力のJSON表示でキー名と階層を見てください。article_idとarticleIdは別の名前で、body.article_idに入っている値も直下の式では参照できません。

入力からドラッグしてマッピングすると、通常はそのパスを読む式が作られます。表示中の1件の値をコピーして固定する操作とは役割が違うため、作成後に式の中身を見るのが確実です。

前ノードは名前と対応するitemを指定する

途中のノードで項目を落としたため、今の入力にはIDがなく、前段には残っている場合もあります。そのようなときに使うのが、名前付きノードの対応itemを読む式です。

{{ $('InputDemo').item.json.article_id }}

InputDemoは説明用のノード名なので、手元の名前に合わせてください。ここでの.itemは、現在のitemを生んだ前ノードのitemへ対応付けをたどる指定です。

画面上の同じ行番号を無条件に読む仕組みではありません。途中のCodeや集約などで対応情報が失われたり、候補が複数になったりすると、参照先を一意に決められなくなります。

別の枝から来たitemを参照する場合も、対応がない可能性を考えてください。必要な値が現在のitemに含まれる構造へ整えるのか、キーで入力を結合するのかを先に判断します。

.first()を使うのは先頭の値を使いたいとき

.first()は、指定ノードの先頭itemを取り出す指定です。全件共通の設定を先頭の1件に置いたなど、先頭を使う意図が明確なときに選びます。

今回のInputDemoがA101・A102の順に出力するなら、{{ $('InputDemo').first().json.article_id }}は先頭のA101を参照する式です。各記事のIDを渡す欄へ使うと、2件目もA101になる設計なので不適切でしょう。

エラーを消すためだけの.first()への置換は避けてください。実行が通っても、異なる記事へ同じIDを渡す問題は残ります。

全件が必要なら.all()という選択肢もありますが、返るのはitemsの一覧です。そこから何をまとめるかは別の設計で、各itemの1項目を読む式と同じ結果にはなりません。

Edit Fieldsで出力項目を作り、残す項目を決める

初めて設定するなら、Manual Mappingで出力名・型・値を1項目ずつ対応させる方法が追いやすいでしょう。項目を作った後は、元データをどこまで出力へ残すかも明示します。

項目名・値・型を対応させる

まず、元のワークフローの複製か検証用ワークフローでEdit Fieldsを追加し、入力に今回の2itemが届くようにしてください。外部サービスへ書き込むノードや自動トリガーは接続しない構成から始めます。

1. ModeでManual Mappingを選ぶ

   Fields to Setには、後続で使う名前ごとに項目を追加してください。以下の名前は固定で、値を参照する式とは別の設定です。

2. 型とFixed／Expressionを設定する

   IDと表示名はString、閲覧数はNumberを選び、固定状態のreview_stateだけをFixedにします。入力からの値はExpressionに切り替えてください。

3. 入力に合わせて値を入れる

   次表の4項目を設定します。authorが欠ける場合の式は、後の空値の節で意味を説明する表示用の例です。

数字だけに見えるIDも、計算に使わない識別子なら文字列のまま保持してください。たとえば"0012"を数値へ変えると先頭の0を保持できず、後続の照合条件が変わってしまいます。

型の指定は、入力が正しいことの証明にはなりません。数値を期待する欄に空文字や想定外の文字が来るケースは、通常の数値入力とは分けて確かめてください。

元のフィールドを残す範囲を明示する

今回は、設定した4項目だけを出力し、internal_noteと元のauthorは後続へ渡さない設計です。出力名をauthor_nameにしただけでは、元のauthorまで除外されたとは限りません。

公式ドキュメントには、設定済み項目だけを残すKeep Only Set Fieldsと、入力項目の出力範囲を選ぶInclude in Outputが記載されています。手元のノードにある設定に合わせ、前者なら有効化し、後者なら入力の元項目を含めない範囲を選ぶ手順です。

Include Other Input Fieldsという切り替えが表示される版なら、今回はオフにしてください。確認した公式実装ではノード版3.3以降がこの方式で、オンにするとInput Fields to Includeから元項目の範囲を選ぶ構成です。

これらの設定が必ず同じ画面に並ぶ前提で、操作を重ねる必要はありません。使用中のノード版と表示名を照合し、結果のJSONに4項目だけが残るかを最終的な判断材料にします。

この除外は、Edit Fieldsから次のノードへ渡す出力の制御です。上流ノードのデータや既に保存された実行履歴から、内部メモを削除する操作ではありません。

ファイルや画像のbinaryも、JSONの4項目とは別に出力を確認してください。公式docsのInclude Binary Dataに相当する設定は、ノード版によってInclude Binary FileやStrip Binary Dataなどの表示になります。

確認した公式実装のノード版3.4以降では、元項目を含める場合にStrip Binary Dataでbinaryを除外する構成です。今回は添付を必要としないため、元項目を含めない設定に加え、出力のbinaryやファイル項目にも不要な添付がないか確かめます。

JSON Outputとドットを含む項目名の注意点

JSON Outputは、複数の項目や入れ子構造をまとめて書く方法です。今回の仮データを同じ4項目へ整えるなら、次のような式を含む入力例で比較できます。

{{ ({  article_id: $json.article_id,  views: $json.views,  author_name: $json.author?.name ?? '未設定',  review_state: 'draft'}) }}

JSON Outputの値全体をExpressionへ切り替え、上のようにオブジェクトを返す式を設定してください。これは静的JSONではなく、入力ごとの値を持つオブジェクトを作るJavaScriptの式です。

表示名を引用符付きのJSON文字列へ直接差し込まず、プロパティの値として渡すため、名前に引用符や改行があっても文字列の内容を保てます。今回の入力はIDが文字列、viewsが数値という前提であり、この式自体が型検査や数値変換を追加するわけではありません。

元項目の出力範囲は、Manual Mappingの例と同じく設定項目だけにしてください。設定後は通常の2itemに加え、表示名に引用符を含む入力でも、4項目の値と型を出力で照合します。

もう一つ、出力名のauthor.nameと、文字としてドットを含むキー"author.name"は別物です。Edit Fieldsは既定でドット記法に対応し、前者を入れ子の{"author":{"name":"編集A"}}として扱います。

ドットをキー名そのものへ含めたい場合は、Support Dot Notationの設定を無効にする選択です。そのキーを読む式も、{{ $json['author.name'] }}のようにキー全体を指定します。

型・空値・複数itemの違いを残したまま整える

整形で大切なのは、見た目をそろえることだけではありません。値の意味を変えず、欠損と有効な0を区別したまま、後続が必要とする型へ渡します。

null、未定義、空文字、0を分ける

nullは明示的に値がない状態、未定義のundefinedはキーが存在しないときの参照結果などです。空文字""や数値0とは、同じ「空っぽ」に見えても意味が異なります。

??が右側の既定値を使うのは、左側がnullかundefinedのときです。||は0や空文字、falseでも右側を使うため、有効な0を残したいときに無条件で置き換えないでください。

たとえば{{ $json.views || 100 }}では、0件の入力が100へ変わります。??に変えれば0は残りますが、「未計測」の値へ0を入れてよいかは別の判断です。

未計測を閲覧数0として保存すると、計測済み0件と区別できなくなります。既定値はエラーを消す道具として足すのではなく、その項目の意味に合う場合だけ使いましょう。

ネストが欠ける入力は参照経路を確かめる

item 2のようにauthor:nullなら、$json.author.nameのまま親の内側を読み進めることはできません。任意の表示名なら、次の式で親の欠損に備え、表示用の既定値を決められます。

{{ $json.author?.name ?? '未設定' }}

?.は、authorがnullかundefinedなら、nameを読み進めずundefinedを返す記法です。その結果を??が受け、今回の表示では「未設定」を使います。

ただし、name:""なら空文字のままです。空文字も未設定表示にしたい要件なら、空文字との比較条件を追加するなど、置き換える範囲を明示してください。

表示名を補う場合と違い、IDが欠けるとどの記事を更新するかを決められません。同じ既定値の考え方を両方へ当てはめず、必須項目の欠損は条件分岐などで別扱いにします。

2件目以降も別々の値になっているかを見る

入力が2itemであれば、同じExpressionの適用先はそれぞれのitemです。先頭だけを見て終えると、全件がA101になったような取り違えを見逃しかねません。

全件が同じ値になったときは、まずFixed欄へ1件目の値を貼っていないか、式に.first()がないかを見てください。次に、本当に複数itemsなのか、1item内の配列なのかを入力一覧で確かめます。

名前付きノードの.itemで問題が出る場合は、途中でitem数や対応付けが変わった場所も調べてください。複数入力をキーで合わせる必要があるならMergeの設計で扱い、式だけで別々のレコードが結合されたとは考えないことが大切です。

入力と出力を照合して設定を完了する

整形の仕上げでは、式のプレビューだけで完了にしないようにしてください。2件の通常例を比べた後、空値や型違いを加え、後続へ渡してよい状態か判断します。

安全なテスト入力と期待出力を用意する

準備するのは、次の二つのitemです。各コードは1itemのjson部分だけを示しており、二つを1つのarticles配列フィールドへ入れる意味ではありません。

item 1のjson部分

{  "article_id": "A101",  "views": 0,  "author": { "name": "編集A" },  "internal_note": "demo"}

item 2のjson部分

{  "article_id": "A102",  "views": 12,  "author": null,  "internal_note": "demo"}

検証用の入力ノードでデータを用意するほか、JSONデータを持つノードの出力を編集・ピン留めして試す方法もあります。手元の版で利用できる方法を選び、Edit FieldsのINPUTに2 itemsが届いていることから確認してください。

ピン留めは開発時の再試験に使う機能です。本番実行で同じデータが固定される仕組みではなく、binaryを含む出力のピン留めにも対応していません。

1. 環境と試験範囲を控える

   n8n本体版、Cloud／self-hosted、Edit Fieldsのノード版、OS・ブラウザ、編集・手動実行権限を記録します。自動トリガーや外部書込を外した複製で進めるのが出発点です。

2. 入力2件を確認してから実行する

   article_idがA101・A102に分かれ、viewsが数値0・12であるかをJSON表示で確かめてください。Edit Fieldsの設定がそろったら、検証対象を手動実行します。

3. 同じ実行の出力を期待表と照合する

   出力を次表と比べ、件数だけでなく値や型、残した項目も確かめてください。以前の実行結果やピン留めしたEdit Fields自身の古い出力を見ていないかも確認が必要です。

4. 境界値を別ケースで足す

   viewsのnull・空文字・文字列0、必須ID欠損、空itemsをそれぞれ試してください。不一致があれば後続へつながず、1か所ずつ直して通常2件も再確認します。

この表は実測結果ではなく、通常例が満たすべき設計上の期待です。空itemsでは整形対象自体がないため、「有効な2件が整った」という完了条件を満たしたことにはなりません。

本例のviewsが正常経路で受け取るのは、入力時点からの数値です。nullや空文字を未計測として認める運用なら、必須数値の正常経路から分け、未計測を扱える出力先へ渡してください。

文字列の"0"をNumberとして出す方針か、型違いとして差し戻す方針かは、後続の仕様に合わせて決めます。Ignore Type Conversion Errorsを有効にして通すだけでは、期待する型を確かめたことにならないでしょう。

設定と出力が対応し、後続が求める必須項目がそろったところで整形テストは完了です。失敗した場合は複製上で変更箇所を戻し、実データへの書込や本番への反映はその後の別確認として扱います。

値が出ない・全件同じときの確認順

式を何か所も直す前に、入力側から順番に切り分けるのが基本です。各段階で期待と違う点が見つかったら、そこを1か所だけ修正してください。

1. 対象の実行に入力があるかを確認する。入力なしなら、先に前段の実行・接続・ピン留め状態を調べる
2. JSON内のキー名と階層を読む。直下の項目か、bodyなどの内側かを合わせる
3. 値の欄がFixedかExpressionかを確認する。固定文字列として式を書いていないかも見る
4. 現在itemを読む式か、先頭固定か、名前付きノードの対応itemかを区別する
5. 名前付きノードが該当実行でデータを出したか、途中で対応情報が失われたり複数一致になったりしていないかを調べる

原因がEdit Fieldsの入力や式でなく、認証・API応答・前段の構造にあるなら、そちらの故障診断へ進む段階です。参照問題を.first()や型エラー抑制で隠してから外部更新を再開しないでください。

Codeや別のデータ変換ノードへ進む目安

一つの設定欄で値を読み、表示名を補い、簡単な計算をするならExpressionが候補です。後続へ渡す項目の構成をそろえたいなら、Edit Fieldsを使うと設定をまとまった場所で確認できます。

選ぶ基準は、式の文字数ではなく、入力と出力の関係を後から追えるかです。2itemへ異なるIDを渡すだけなら、不要なループや複雑なCodeを足す前に、現在itemの参照を確かめましょう。

整えた出力をGoogle Sheetsなどへ書く際には、認証、更新する行の識別、書込後の読み戻しも別途必要です。今回のarticle_idや表示名の例に、APIキーやOAuthトークンなどの認証値は混ぜず、Credentialsで管理してください。

まとめ｜Expressionで参照し、Edit Fieldsの出力を確かめる

Expressionでは参照するitemと項目を決め、Edit Fieldsでは出力名・値・型・元項目の保持範囲を整えます。現在itemの$json、対応itemの.item、先頭を選ぶ.first()を区別し、0や欠損の意味を保つことが要点です。

まずはA101・A102の仮の2itemを使い、期待する4項目を書き出してから入力と出力を比べてください。IDが別々で数値0が残り、任意の表示名だけが補われ、内部メモが除外されたかまで確認します。

式を短くまとめること以上に、どのitemの何を、どの型で次へ渡すかが追える設計を優先したいところです。その関係が見えるだけで、Codeや結合処理へ進む必要があるかも判断しやすくなるでしょう。