n8nのデータ変換Nodesを理解する｜Codeを書かずにJSONを整形する基本

2026-09-21

n8nでは、外部からrequestが届くのを待つだけでなく、決めた間隔や時刻にWorkflowを自動実行できます。その入口になるのがSchedule Trigger nodeです。

指定時刻になる
→ Schedule Triggerが起動
→ Workflowを実行
→ 結果をExecutionsへ記録

毎朝の集計、週次レポート、一定間隔のAPI確認などに使えます。ただし、画面で「9:00」と設定しても、timezoneが想定と違えば別の時刻に動きます。

Schedule Triggerでは、scheduleとtimezoneを一組として設計することが重要です。

今日の到達点

Schedule Triggerの役割を説明できる
interval指定とCustom Cronを使い分けられる
WorkflowのPublishが必要な理由を理解できる
Workflow timezoneとinstance timezoneの優先関係を説明できる
時刻ずれ、二重実行、実行漏れを確認する方法を理解できる

Schedule Triggerとは何か

Schedule Triggerは、固定された間隔または時刻を条件にWorkflowを開始するTrigger nodeです。

時間というイベント
→ Schedule Trigger
→ データ取得
→ 加工・判定
→ 通知・保存

Schedule Triggerが出力するのは、業務データそのものではありません。定刻になったことを合図に後続nodeを起動し、後続のHTTP Requestやサービスnodeなどが必要なデータを取得します。

Manual Triggerとの違いは、開始操作を人が行うか、schedulerが行うかです。

Trigger	開始方法	主な用途
Manual Trigger	人が実行する	構築・試験
Schedule Trigger	設定時刻に自動起動	継続運用

Publishしないと本番scheduleは動かない

Schedule Triggerを設定してeditorから手動実行できても、それだけでは定期実行されません。

現在のn8n公式ドキュメントでは、Schedule Triggerを本番で動かすにはWorkflowを保存してPublishする必要があります。

Scheduleを設定
→ 手動でnodeを確認
→ WorkflowをPublish
→ scheduleが登録される
→ 設定時刻にproduction execution

古い記事や環境では、Active toggleをONにすると説明される場合があります。現在のUIではPublish／Publishedが中心です。使用環境にActive表記がある場合も、「本番triggerが自動起動できる状態か」という観点で確認します。

Published後にDraftのscheduleを変更しただけでは、本番scheduleへ反映されません。変更を反映するには新しいversionをPublishします。

Trigger Intervalの種類

Schedule TriggerではTrigger Rulesを追加し、実行条件を設定します。現在の公式仕様では、次のintervalを選択できます。

Seconds
Minutes
Hours
Days
Weeks
Months
Custom（Cron）

複数のTrigger Rulesを追加し、同じWorkflowを異なるscheduleで起動することもできます。

SecondsとMinutes

短い間隔で繰り返す設定です。

Every 30 seconds
Every 5 minutes

実習では動作を観察しやすい一方、本番で短い間隔にするとexecution数、API rate limit、重複処理、課金へ影響します。

Hours

何時間ごとに実行するかに加え、何分に起動するかを指定します。

Hours Between Triggers: 6
Trigger at Minute: 30

この例は6時間ごとの30分に実行されます。

DaysとWeeks

Daysでは、何日ごとか、何時何分に実行するかを指定します。

Weeksでは、週の間隔、曜日、時刻を設定できます。平日の決まった曜日にレポートを作る場合などに向いています。

Months

月の間隔、日、時刻を指定します。

「毎月31日」と設定した場合、31日が存在しない月には実行されません。月末処理では、固定日を指定するだけで要件を満たすか確認が必要です。

intervalはPublish時点を基準にする場合がある

「毎日9:00」のような時刻指定と、「2時間ごと」のような経過間隔は考え方が異なります。

現在の公式ドキュメントでは、scheduleの変更をPublishすると、新しいintervalはPublishした時点から始まると説明されています。

たとえば2時間間隔のversionを11:30にPublishした場合、次回が13:30になる可能性があります。

固定時刻：毎日 09:00
経過間隔：Publishから2時間ごと

「時刻に合わせたいのか」「前回から一定時間ごとに動かしたいのか」を先に決めます。

Custom Cronの基本

標準のintervalで表しにくいscheduleにはCustom（Cron）を使います。

代表例は次のとおりです。

Cron expression	意味
`/5 * * *`	5分ごと
`0 6 * * *`	毎日6:00
`0 9 * * 1-5`	平日の9:00
`0 12 * * 1`	毎週月曜12:00
`0 0 1 * *`	毎月1日0:00

n8nのCron expressionは、一般的な5fieldに加え、先頭へ秒を指定した6fieldも利用できます。

(second) minute hour day-of-month month day-of-week

10秒ごとの例です。

*/10 * * * * *

秒fieldは省略できます。外部のCron生成ツールを使う場合は、n8nが受け付けるfield数とsyntaxに合っているか確認してください。

Cron内でvariablesを使う場合、その値はWorkflowをPublishした時点で評価されます。後からvariableだけを変更してもscheduleは更新されないため、Unpublishして新しいversionをPublishします。

現在のintervalとCron仕様は、n8n公式のSchedule Trigger nodeで確認できます。

Timezoneの優先関係

Schedule Triggerが使うtimezoneには優先順位があります。

Workflow timezoneが設定済み
→ Workflow timezoneを使用

Workflow timezoneが未設定
→ n8n instance timezoneを使用

Workflow固有のtimezoneは、canvas右上のメニューからWorkflow settingsを開いて設定します。個別設定がない場合はinstance timezoneが使われます。

n8n Cloud

Cloudでは、instanceのTimezoneを管理画面から変更できます。

公式ドキュメントでは、登録時にownerのtimezoneを検出し、検出できない場合はGMTへfallbackすると説明されています。

self-hosted

self-hostedでは、GENERIC_TIMEZONE環境変数でinstance timezoneを設定できます。公式ドキュメント上のdefaultはAmerica/New_Yorkです。

日本時間で運用する例は次のとおりです。

GENERIC_TIMEZONE=Asia/Tokyo

OSやcontainerのtimezoneを日本へ変更しただけで、n8nのscheduleも必ず日本時間になるとは判断しません。n8nのWorkflow settingsとinstance設定を直接確認します。

詳細はn8n公式のTimezone and localizationで確認できます。

UTC+9とAsia/Tokyoの違い

日本は現在、夏時間を採用していないため、Asia/Tokyoは年間を通してUTC+9として扱われます。

一方、America/New_Yorkなどの地域timezoneはDST、つまり夏時間によってUTCとの差が変わります。現地時刻9:00を維持したい場合は、固定offsetではなく地域timezoneを指定する設計が基本です。

海外拠点を扱う場合は、次を明確にします。

どの地域の「朝9時」か
DST切り替え日に同じ時刻が存在しない、または重複する可能性を許容するか
記録時刻をlocal timeとUTCのどちらで保存するか

日本国内だけのWorkflowでも、instance defaultがNew Yorkのままなら時刻がずれます。「日本にはDSTがないから安全」ではなく、timezone設定そのものを確認してください。

時刻ずれを調べる順番

Schedule Triggerが想定時刻に動かない場合は、次の順番で確認します。

WorkflowがPublishedか
→ Workflow timezoneは何か
→ instance timezoneは何か
→ Trigger Ruleの時刻と曜日
→ Cronのfield数とsyntax
→ 変更後のversionをPublishしたか
→ Executionsの開始時刻

予定時刻と実行時刻は、感覚ではなく具体的な値で記録します。

workflow_timezone: Asia/Tokyo
instance_timezone: Asia/Tokyo
scheduled_local_time: "2026-09-20 20:05:00"
actual_execution_time: "実習で確認"
offset_seconds: "実習で計算"

Workflow固有のtimezone設定は、n8n公式のWorkflow settingsで確認できます。

二重実行を防ぐ

Schedule Triggerに複数のTrigger Rulesを設定すると、同じ時刻に条件が重なる可能性があります。

また、複数Workflowへ同じ業務処理を設定した場合も、処理が二重になります。

確認項目は次のとおりです。

Trigger Rulesが同じ時刻に重複していないか
古いWorkflowもPublishedのまま残っていないか
executionが2件あるのか、1 execution内で2 itemsを処理したのか
再実行しても同じデータを二重登録しないか
日付や一意IDで処理済みを判定できるか

重要な登録や通知では、「scheduleは一度しか発火しないはず」と仮定するのではなく、同じ処理が再度呼ばれても結果を壊さない設計を検討します。

実行漏れと停止時間

instance停止中に予定時刻を過ぎた場合、通常のin-memory schedulerでは停止中のexecutionが後からすべて自動実行されるわけではありません。

現在の公式ドキュメントには、durable scheduler使用時のIf Execution Is Missedやgrace periodも記載されています。

ただし、この機能はn8n 2.36以降に追加されたSchedule Triggerとdurable schedulerが対象です。環境やn8n versionによって表示されない場合があります。

初心者の段階では、次を先に決めます。

停止中の処理を捨ててよいか
復旧後に最新1件だけ実行する必要があるか
実行漏れを別の監視で検知するか

最小Workflowで確認する

実習では、外部サービスへ書き込まずにexecution時刻だけを観察します。

Schedule Trigger
→ Edit Fields

Edit Fieldsで次のような確認用fieldを追加します。

{{ $now.toISO() }}

field name: observed_at
type: String

短いintervalを設定し、Workflow timezoneを確認してPublishします。Executionsに記録された開始時刻とobserved_atを比較してください。

確認後は、短い試験scheduleをそのままPublishedにしないよう、Unpublishするか本来の間隔へ変更して再Publishします。

よくある失敗

Draftでscheduleを変更しただけ

Published versionは以前のscheduleで動き続けます。変更後のversionをPublishしたか確認します。

instance timezoneを想定だけで判断した

PCの時計やbrowser表示が日本時間でも、n8nのinstance timezoneが同じとは限りません。

Workflow settingsとCloud管理画面、またはGENERIC_TIMEZONEを確認します。

月末を31日指定だけで表現した

31日がない月にはtriggerされません。「月末」という業務要件なら、別の条件判定を組み合わせる設計を検討します。

短い試験intervalを戻し忘れた

数秒・数分ごとの試験設定を放置すると、execution、API call、通知が増え続けます。実習後の停止または再設定をチェックリストへ含めます。

Cronの5fieldと6fieldを混同した

先頭の秒fieldを含むかを確認し、n8n公式の例と照合します。

外部ツールで検証するときは、秒fieldを除いた形での確認が必要な場合があります。Cron errorや時刻ずれの確認方法は、n8n公式のSchedule Trigger common issuesにもまとめられています。

実務での考え方

定期実行は「何時に動くか」だけでなく、運用契約として整理します。

schedule:
  expression: "0 9 * * 1-5"
  timezone: "Asia/Tokyo"
  expected: "平日09:00 JST"

operation:
  duplicate_safe: true
  missed_execution_policy: "alert"
  owner: "workflow operator"

schedule、timezone、重複時の扱い、停止時の扱い、監視方法をセットで残すと、環境移行や担当変更後も意図を復元できます。

今日の実習で確認すること

Schedule Triggerで検証しやすい短いintervalを設定する
Workflow timezoneとinstance timezoneを確認する
WorkflowをPublishしてproduction executionを待つ
予定時刻とExecutionsの実行時刻を比較する
同一時刻に二重executionが発生していないか確認する
schedule変更後に再Publishが必要なことを確認する
実習後に短いscheduleを停止または変更する

まとめ

Schedule Triggerは、指定したintervalまたは時刻でWorkflowを自動起動するTrigger nodeです。

scheduleを定義
→ timezoneを明示
→ WorkflowをPublish
→ Executionsで実時刻を確認
→ 重複・漏れを監視

Workflow timezoneが設定されていればそれを優先し、未設定ならinstance timezoneを使います。Draftのschedule変更は本番へ自動反映されないため、新しいversionのPublishが必要です。

正確な定期実行は、Cron expressionだけでは完成しません。timezone、Publish状態、重複防止、停止時の扱いまで確認して、運用できるscheduleにします。

参考資料

今日の実習への接続

実習で確認する内容：短いSchedule TriggerをPublishし、実際にproduction executionが作成されることを確認する
記事で理解済みであるべき内容：Trigger Interval、Custom Cron、Publish、Workflow／instance timezoneの優先関係
実際にn8nで確認すべき内容：設定timezone、予定時刻、実行時刻、ずれ、二重execution、schedule変更後の再Publish
実習終了時に記録すべきResult：Trigger Rule、Cronまたはinterval、両timezone、予定時刻、実行時刻、ずれ、execution件数、UI差分
実習後の処理：短い試験scheduleをUnpublishするか、本来の間隔へ変更して再Publishする

Notion更新結果

作業票：既存使用
記事作業票更新：成功
記事生成・品質確認チェックリスト：完了
学習連携チェックリスト：実習前のため未チェックで維持
記事作業票完了判定：完了
対応練習タスク：確認済み・未完了のまま維持
Next Action：対応するn8n練習 Day 9を実行し、短いscheduleをPublishして予定時刻と実execution時刻を照合し、Workflow／instance timezoneと二重起動の有無をResultへ記録する

n8n-day09-schedule-trigger-timezone.mdドキュメントファイルを開く

今日 4:07n8n予習記事 Day 2–14

実行結果

実行日：2026-09-21
Day番号：Day 10
今日のテーマ：データ変換Nodes
使用したNotion記事作業票：n8n学習記事 Day 10｜データ変換Nodes
対応するn8n練習作業票：n8n練習 Day 10：データ変換Nodes
Notion取得状態：既存作業票を確認
n8n公式情報確認状態：2026-09-21時点の公式ドキュメントで確認完了
ekplabz.com重複確認状態：n8n記事一覧で同一テーマなし
記事生成状態：成功
後続実習への接続状態：実行可能
完成稿：n8n-day10-data-transformation-nodes.md

タイトル

n8nのデータ変換Nodesを理解する｜Codeを書かずにJSONを整形する基本

スラッグ

n8n-data-transformation-nodes

メタディスクリプション

n8nのEdit Fields、Filter、Sort、Aggregate、Split Outを使い、Codeを書かずにfield追加・削除・rename、絞り込み、集約を行う基本を解説。INPUT／OUTPUTとitem数の確認方法も整理します。

本文

n8nで外部APIやフォームから取得したデータは、そのまま次のサービスへ渡せるとは限りません。field名が接続先と合わない、不要なfieldが多い、条件に合うitemsだけを残したい、複数itemsを配列へまとめたい、といった変換が必要になります。

このとき、すぐにCode nodeでJavaScriptを書く必要はありません。n8nには、よくあるデータ変換を画面上で設定できる標準nodeが用意されています。

入力データ
→ fieldを整える
→ itemsを絞る・並べる
→ 必要なら集約・分割する
→ 接続先が必要とする形で出力する

この記事では、Edit Fields、Filter、Sort、Aggregate、Split Outを中心に、Code nodeへ進む前に確認したいデータ整形の考え方を整理します。

今日の到達点

fieldの追加・上書き・削除・renameをEdit Fieldsで設計できる
FilterとSortがitemsへ与える変化を説明できる
AggregateとSplit Outによる「itemsと配列」の変換を区別できる
nodeごとのINPUT／OUTPUTとitem数を確認できる
標準node、Expression、Code nodeの使い分けを判断できる

データ変換は「次のnodeとの契約」を作る処理

n8nの各nodeは、前のnodeからitemsを受け取り、処理結果をitemsとして次へ渡します。データ変換の目的は、見た目をきれいにすることではありません。次のnodeが必要とするfield名、型、items数、配列構造へ合わせることです。

たとえば、APIの出力が次の形だとします。

{
  "machine_name": "Pump A",
  "pressure_mpa": 12,
  "status": "running",
  "internal_note": "temporary value"
}

後続の通知nodeが必要とする形が次なら、変換内容を先に言葉で定義できます。

{
  "machine": "Pump A",
  "pressure_kpa": 12000,
  "status": "running"
}

必要な処理は次の3つです。

machine_nameをmachineとして出力する
MPaをkPaへ換算したfieldを追加する
internal_noteを出力から除外する

期待するOUTPUTを先に決めると、「どのnodeを使うか」を選びやすくなります。

Edit Fieldsでfieldを整える

Edit Fields (Set) nodeは、新しいfieldの追加と既存fieldの上書きに使う中心的な変換nodeです。Manual Mappingでは画面上でfield名と値を設定でき、JSON Outputでは出力へ加えるJSONを記述できます。

fieldを追加する

固定ラベルを追加する例です。

Name: source
Value: sensor-api
Type: String

入力itemごとに同じsourceが追加されます。

Expressionを使えば、既存fieldから新しい値を作れます。

{{ $json.pressure_mpa * 1000 }}

この値をNumber型のpressure_kpaへ設定すれば、各itemの圧力を変換できます。

fieldを上書きする

既存と同じfield名をFields to Setへ指定すると、その値を上書きできます。

{{ $json.status.toLowerCase() }}

元の値がRUNNINGなら、出力のstatusをrunningへ統一できます。ただし、元データを後で調査する必要がある場合は、上書きせずnormalized_statusのような別fieldを作る方が安全です。

fieldをrenameする

renameは「新しい名前のfieldへ元の値を割り当て、古いfieldを出力へ残さない」と考えます。

Name: machine
Value: {{ $json.machine_name }}

次に、Include in Outputで必要な入力fieldだけを含めるか、設定したfieldだけを出力するようにします。これでmachine_nameを除き、machineを残せます。

環境やn8nバージョンにより、出力fieldを限定する設定がKeep Only Set Fieldsなどの表記になっている場合があります。名称ではなく、「未指定の入力fieldを出力へ残すか」という動作を確認してください。

不要なfieldを削除する

Edit Fieldsでは、Include in Outputを使って出力へ残す入力fieldを選べます。個人情報や巨大なresponseを後続で使わない場合は、早い段階で必要fieldへ絞るとWorkflowを読みやすくできます。

ただし、削除後のnodeからはそのfieldを参照できません。後続で必要になるfieldを確認してから除外します。

現在の設定項目はn8n公式のEdit Fields (Set)ドキュメントで確認できます。

Filterで必要なitemsだけを残す

Filter nodeは、条件を満たしたitemsだけをoutputへ渡し、一致しないitemsを出力から除外します。

5 input items
→ pressure_kpa >= 10000
→ 3 output items

たとえば次の条件をNumberとして設定します。

Value 1: {{ $json.pressure_kpa }}
Operation: is greater than or equal to
Value 2: 10000

複数条件ではANDまたはORを選べます。現在の公式仕様では、同じFilter node内でANDとORを混在させることはできません。複雑な条件は、Filterを段階的に分けるか、前段で判定用fieldを作ると追跡しやすくなります。

FilterとIFは似ていますが、目的が違います。

node	主な目的	一致しないitems
Filter	必要なitemsだけを残す	outputから除外
IF	true／falseで処理経路を分ける	false側へ出力

除外したitemsにも別の処理が必要ならIF、以後の処理対象から外すだけならFilterが分かりやすい選択です。

利用できる比較条件はn8n公式のFilterドキュメントで確認できます。

Sortでitemsの順序を変える

Sort nodeは、itemsを指定fieldの昇順または降順へ並べ替えます。圧力の高い順に並べるなら、pressure_kpaをDescendingにします。

入力: 10000, 14000, 12000
出力: 14000, 12000, 10000

Simpleでは複数fieldを並べ替え条件にできます。Randomでは順序をランダム化できます。SortにはCode typeもありますが、単純なfieldの並べ替えならSimpleを優先します。

文字列と数値を取り違えると、期待した順序になりません。INPUTのJSONで"100"と100の違いを確認し、必要ならEdit Fieldsで型を整えてからSortします。

現在のTypeと設定方法はn8n公式のSortドキュメントで確認できます。

Aggregateで複数itemsをまとめる

Aggregate nodeは、複数のitemsまたは各itemの一部を、1つ以上のitemへまとめます。

All Item Dataを使い、Put Output in Fieldをalertsにすると、3 itemsを1 item内の配列へまとめられます。

{
  "alerts": [
    {
      "machine": "Valve B",
      "pressure_kpa": 14000
    },
    {
      "machine": "Pump C",
      "pressure_kpa": 12000
    },
    {
      "machine": "Pump A",
      "pressure_kpa": 10000
    }
  ]
}

3 input items
→ Aggregate
→ 1 output item（alerts配列に3件）

Individual Fieldsでは、特定fieldの値を配列として集められます。複数の通知対象を1回のrequest bodyへ入れる、複数レコードをまとめて送る、といった用途に向きます。

Aggregateは合計値を計算するnodeとは限りません。複数itemsを配列へまとめる役割が中心です。合計、平均、件数、最大値などを求めたい場合はSummarize nodeが適しています。

詳しい集約方式はn8n公式のAggregateドキュメントで確認できます。

Split Outで配列を複数itemsへ展開する

Split Out nodeは、1 item内の配列を複数itemsへ分けます。Aggregateと逆方向の変換です。

先ほどのalertsをField to Split Outへ指定すると、配列要素ごとのitemsへ戻せます。

1 input item（alerts配列に3件）
→ Split Out
→ 3 output items

Includeでは、元itemのほかのfieldを各itemへ引き継ぐか選べます。共通のreport_dateを各要素へ持たせたい場合はAll Other FieldsまたはSelected Other Fieldsを使います。

API responseにresultsやordersの配列が1つのitemとして入っている場合、後続nodeで要素ごとに処理する前にSplit Outを使います。

現在の設定項目はn8n公式のSplit Outドキュメントで確認できます。

そのほかの代表的な変換node

Summarize

複数itemsに対し、Sum、Average、Count、Count Unique、Min、Maxなどを計算します。Fields to Split Byを使うと、categoryや担当者ごとの集計もできます。表計算のpivot tableに近い用途です。

Remove Duplicates

現在の入力内にある重複itemsを削除できます。また、過去executionで処理済みの値と比較するoperationもあります。後者は履歴を持つため、現在の入力だけを重複排除する処理とは分けて設計します。

Limit

指定した最大数を超えるitemsを除外します。上位10件だけを次へ渡す場合は、Sortの後にLimitを置くと意図が明確です。

これらは、n8n公式のExpressions versus data nodesで代表的なdata transformation nodesとして整理されています。

最小Workflowでitem数を追う

実習では、5 itemsを次の順番で変換します。

Manual Trigger
→ Edit Fields（records配列を作る）
→ Split Out（5 itemsへ展開）
→ Edit Fields（rename・追加・削除）
→ Filter（圧力10MPa以上）
→ Sort（圧力の降順）
→ Aggregate（alerts配列へまとめる）

最初のEdit FieldsをJSON Outputモードにし、records fieldへ次の配列を設定します。その後、Split OutのField to Split Outへrecordsを指定すると、Code nodeを使わず5 itemsを用意できます。実環境ではWebhookやHTTP Requestの取得結果を使って構いません。

{
  "records": [
    {
      "id": 1,
      "machine_name": "Pump A",
      "pressure_mpa": 10,
      "status": "RUNNING",
      "internal_note": "a"
    },
    {
      "id": 2,
      "machine_name": "Valve B",
      "pressure_mpa": 14,
      "status": "RUNNING",
      "internal_note": "b"
    },
    {
      "id": 3,
      "machine_name": "Cylinder C",
      "pressure_mpa": 7,
      "status": "STOPPED",
      "internal_note": "c"
    },
    {
      "id": 4,
      "machine_name": "Pump C",
      "pressure_mpa": 12,
      "status": "RUNNING",
      "internal_note": "d"
    },
    {
      "id": 5,
      "machine_name": "Valve D",
      "pressure_mpa": 6,
      "status": "STOPPED",
      "internal_note": "e"
    }
  ]
}

各段階の期待するitem数は次のとおりです。

段階	item数	主な変化
Manual Trigger後	1	起動用item
最初のEdit Fields後	1	`records`配列に5件
Split Out後	5	配列要素を5 itemsへ展開
Edit Fields後	5	rename、追加、削除
Filter後	3	10MPa未満を除外
Sort後	3	降順へ変更
Aggregate後	1	3件を`alerts`配列へ格納

実習では期待値をそのまま結果として記録せず、各nodeを実行して実際のINPUT／OUTPUTとitem数を確認してください。

INPUT／OUTPUTを確認する順番

データ変換が崩れたときは、最後のnodeだけを見ても原因を特定できません。左から1 nodeずつ確認します。

INPUTのitem数
→ JSONのfield名と型
→ node設定
→ OUTPUTのitem数
→ JSONのfield名・型・配列階層

特に次を確認します。

Table表示だけでなくJSON表示でも構造を見る
objectの{}とarrayの[]を区別する
Expressionが参照するpathと実データを合わせる
number、string、booleanの型を確認する
AggregateやSplit Outの前後でitem数を記録する
不要fieldを除外した時点を把握する

node名は処理内容が分かるようにすると、後から追跡しやすくなります。

Edit Fields - Normalize Machine Data
Filter - Pressure 10MPa or Higher
Sort - Pressure Descending
Aggregate - Build Alerts Array

よくある失敗

fieldを削除するのが早すぎる

Edit Fieldsで出力を限定した後、Filterが参照するfieldまで消してしまうことがあります。各後続nodeが必要とするfieldを確認してから削除します。

Filterで型が合っていない

数値条件に文字列が入ると、型エラーや意図しない比較になることがあります。Less Strict Type Validationへ頼る前に、データ生成元とEdit Fieldsで型を明示できないか確認します。

Aggregate後も複数itemsだと思っている

All Item Dataでまとめると、複数itemsが1 item内の配列へ変わります。後続で$json.machineを参照しても存在せず、$json.alertsの配列を扱う必要があります。

Split Outするfieldが配列ではない

Field to Split Outにはlistを含むfieldを指定します。objectとarrayをJSON表示で見分け、実際のpathを設定します。

変換を1つの巨大なExpressionへ詰め込む

短いExpressionは便利ですが、絞り込み、並べ替え、集約まで1か所へ埋め込むと、途中結果を確認しにくくなります。意味の異なる変換はnodeへ分けます。

Code nodeへ進む前の判断基準

現在のn8n公式ドキュメントでは、既存値をparameterへ入れる軽い処理にはExpression、一般的な変換には専用のdata transformation node、複雑な独自処理にはCode nodeという使い分けが示されています。

まず次を確認します。

field追加・上書き・出力限定：Edit Fields
条件に合うitemsだけを残す：Filter
itemsを並べる：Sort
itemsを配列へまとめる：Aggregate
配列をitemsへ分ける：Split Out
合計・平均・件数を求める：Summarize
重複を除く：Remove Duplicates
件数を制限する：Limit

専用nodeの目的と一致するなら、標準nodeを優先するとINPUT／OUTPUTを画面で追跡しやすくなります。

Code nodeが適するのは、複雑な入れ子構造の再構成、独自アルゴリズム、標準nodeを多数つないでも意図を表せない処理などです。「Codeの方が短い」だけでなく、保守する人、テスト方法、失敗時の調査まで含めて判断します。

実務での考え方

データ変換は、Workflowの途中にある一時作業ではなく、外部サービス間の境界を安定させる層です。

外部サービス固有のresponse
→ 標準nodeで業務用の共通形へ正規化
→ 判定・集計
→ 接続先固有のrequest形へ整形

早い段階でfield名と型を統一すると、後続の分岐や通知が単純になります。一方、元データを完全に消すと調査が難しくなるため、必要なら正規化前の値を別fieldへ残すか、executionで追える設計にします。

今日の実習で確認すること

5件程度のitemsを用意する
Edit Fieldsでfieldのrename、追加、削除を行う
Filterで一部itemsを除外する
Sortで残ったitemsを並べ替える
AggregateまたはSplit Outを最低1回使う
各nodeのINPUT／OUTPUT、item数、JSON構造を記録する
変換にCode nodeが不要だった理由を言葉にする

まとめ

n8nの標準的なデータ変換nodeを使うと、fieldの整形、itemsの絞り込み、並べ替え、集約、配列の展開を画面上で構成できます。

期待するOUTPUTを決める
→ 目的に合う標準nodeを選ぶ
→ 1段階ずつ変換する
→ INPUT／OUTPUTとitem数を確認する
→ 標準nodeで表せない場合だけCodeを検討する

重要なのは、Codeを書かなかったことではありません。どのnodeで、items数とJSON構造がどう変化したかを説明できることです。小さな標準nodeを組み合わせ、後続のnodeが安心して使えるデータを作りましょう。

参考資料

参考になったらシェアしてください

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

ekplabz

機械設計・油圧・CAD・Python・AIなど、ものづくりに関わる技術を扱っています。工学知識を整理・構造化し、設計や自動化に再利用できる形へ変えていくことを目指しています。

n8nのデータ変換Nodesを理解する｜Codeを書かずにJSONを整形する基本

今日の到達点

Schedule Triggerとは何か

Publishしないと本番scheduleは動かない

Trigger Intervalの種類

SecondsとMinutes

Hours

DaysとWeeks

Months

intervalはPublish時点を基準にする場合がある

Custom Cronの基本

Timezoneの優先関係

n8n Cloud

self-hosted

UTC+9とAsia/Tokyoの違い

時刻ずれを調べる順番

二重実行を防ぐ

実行漏れと停止時間

最小Workflowで確認する

よくある失敗

Draftでscheduleを変更しただけ

instance timezoneを想定だけで判断した

月末を31日指定だけで表現した

短い試験intervalを戻し忘れた

Cronの5fieldと6fieldを混同した

実務での考え方

今日の実習で確認すること

まとめ

参考資料

今日の実習への接続

Notion更新結果

実行結果

タイトル

n8nのデータ変換Nodesを理解する｜Codeを書かずにJSONを整形する基本

スラッグ

メタディスクリプション

本文

今日の到達点

データ変換は「次のnodeとの契約」を作る処理

Edit Fieldsでfieldを整える

fieldを追加する

fieldを上書きする

fieldをrenameする

不要なfieldを削除する

Filterで必要なitemsだけを残す

Sortでitemsの順序を変える

Aggregateで複数itemsをまとめる

Split Outで配列を複数itemsへ展開する

そのほかの代表的な変換node

Summarize

Remove Duplicates

Limit

最小Workflowでitem数を追う

INPUT／OUTPUTを確認する順番

よくある失敗

fieldを削除するのが早すぎる

Filterで型が合っていない

Aggregate後も複数itemsだと思っている

Split Outするfieldが配列ではない

変換を1つの巨大なExpressionへ詰め込む

Code nodeへ進む前の判断基準

実務での考え方

今日の実習で確認すること

まとめ

参考資料

この記事を書いた人

関連記事