n8nで日付を扱うと、「今日の日付を出したいだけなのにUTCになる」「Google SheetsからNotionへ渡したらInvalid dateになる」「Schedule Triggerの実行日とデータ取得日がズレる」といった問題が起きやすいです。特に日本時間で業務フローを作っている場合、JSTとUTCのズレ、日付フォーマットの違い、連携先が求める形式の違いが重なり、原因が見えにくくなります。

この記事では、n8nの日付操作について、Date & Timeノード、Expression、Codeノード、Luxon、タイムゾーン設定、Google Sheets・Notion・GA4・kintone連携での注意点まで、徹底的に調査してどこよりもわかりやすくまとめました。初めてn8nを触る人でも、「どの場面でどの方法を使えばいいか」が判断できるように、実務で迷いやすいポイントを中心に整理しています。

この記事のポイント
✅ n8nで日付がズレる主な原因がわかる
✅ Date & TimeノードとLuxonの使い分けがわかる
✅ JST変換・昨日の日付・ISO形式の作り方がわかる
✅ NotionやGoogle Sheets連携でInvalid dateを避ける考え方がわかる
今日のセールをまとめてチェック！
本日のセール・タイムセールをまとめてチェックできます。
＼最大7.5%ポイントアップ！／
Amazon
楽天市場
Yahooショッピング
メルカリ

n8nの日付でまず押さえるべき基本

n8nの日付でまず押さえるべき基本
  1. n8n 日付への答えはLuxonかDate & Timeノードで形式とタイムゾーンをそろえること
  2. 9時間ズレる原因はUTCとJSTの扱いが混ざること
  3. Date & Timeノードは画面操作で日付加工したいときに向いていること
  4. Expressionのワンライナーは今日・昨日・明日の日付取得に向いていること
  5. Notion連携ではISO 8601形式に整えることが重要であること
  6. n8n アプリとして使うなら日付処理は最初に共通ルール化すること

n8n 日付への答えはLuxonかDate & Timeノードで形式とタイムゾーンをそろえること

【AI】【業務効率化】【職場】n8n 日付への答えはLuxonかDate & Timeノードで形式とタイムゾーンをそろえること

n8nで日付を扱うときの結論はシンプルです。日付の「値」「形式」「タイムゾーン」をバラバラに扱わないことが重要です。たとえば「2026-05-19」という日付だけを使いたいのか、「2026-05-19 09:00:00」のように時刻も必要なのか、さらにそれが日本時間なのかUTCなのかを、ワークフロー内で明確にしておく必要があります。

n8n公式ドキュメントでは、Date & Timeノードで日付の加算、減算、整形、現在日時の取得、日付差分の計算などができると説明されています。さらに、CodeノードやExpressionではLuxonを利用して日付を扱えるとされています。つまり、n8nでは大きく分けてノードで操作する方法と式で操作する方法の2つが用意されている、という理解で問題ありません。

参考：n8n公式 Date & Timeノード
https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.datetime/

初心者の場合は、まずDate & Timeノードを使うほうがわかりやすいです。画面上で「Format a Date」「Add to a Date」「Subtract From a Date」などの操作を選べるため、何をしているかを視覚的に確認できます。一方で、慣れてきたらExpressionで$now.toFormat('yyyy-MM-dd')のように書いたほうが、ノード数を減らせる場面もあります。

n8nの日付でよくある失敗は、「日付を作る場所」と「使う場所」で前提がズレることです。たとえばGoogle Sheetsでは2026/05/19、Notionでは2026-05-19、CodeノードではISO文字列、Schedule TriggerではAsia/Tokyoというように、各ノードや連携先で期待される形式が異なります。ここを意識せずに接続すると、エラーや日付ズレが起きやすくなります。

🔎 n8nの日付処理の基本整理

処理したいこと 向いている方法 例
今日の日付を出す Expression / Date & Timeノード $now.toFormat('yyyy-MM-dd')
JSTに変換する Luxon $now.setZone('Asia/Tokyo')
表示形式を変える Date & Timeノード / Luxon yyyy-MM-dd HH:mm
Notionへ日付を渡す ISO形式に整える 2026-05-19
日付差分を計算する Date & Timeノード Get Time Between Dates

最初に決めておきたいのは、ワークフロー内の標準日付形式です。日本の業務で使うなら、表示用はyyyy-MM-ddまたはyyyy-MM-dd HH:mm、APIやNotion連携ではISO 8601形式を基本にすると扱いやすいです。ただし、連携先ごとに要求形式が違う可能性があるため、実際のエラー表示や公式ドキュメントは確認したほうがよいでしょう。

✅ 最初に決めるべき日付ルール

決める項目 おすすめの考え方
タイムゾーン 日本向けならAsia/Tokyoを明示
日付だけ yyyy-MM-ddを基本にする
日時あり yyyy-MM-dd HH:mm:ssなどに統一
API連携 ISO 8601形式を優先
表示用と保存用 できれば分けて考える

要するに、n8nの日付処理では「その場でなんとなく変換する」のではなく、入口で受け取った日付を一度整え、出口で連携先に合わせるのが安定しやすいです。これだけで、9時間ズレ、Invalid date、検索条件の不一致といったトラブルをかなり減らせます。

9時間ズレる原因はUTCとJSTの扱いが混ざること

【AI】【業務効率化】【職場】9時間ズレる原因はUTCとJSTの扱いが混ざること

n8nの日付で特に多いのが、9時間ズレる問題です。これは日本時間のJSTがUTCより9時間進んでいるために起きます。たとえばUTCで2026-05-18 15:00は、日本時間では2026-05-19 00:00です。日付の境目に近い処理では、この差が「昨日のはずが今日」「今日のはずが昨日」というズレにつながります。

Qiitaの記事でも、n8nやJavaScriptでnew Date()を使うとUTC基準のタイムスタンプとして扱われることがあり、日本時間として表示したい場合はLuxonのsetZone('Asia/Tokyo')を使う方法が紹介されています。提供された調査情報の範囲では、n8n内なら$now.setZone('Asia/Tokyo')を使うのがわかりやすい解決策として整理できます。

参考：Qiita「n8n/JS Date型で9時間ズレる問題」
https://qiita.com/YushiYamamoto/items/e8b7a80bfb4d6bfd7311

ここで大事なのは、単純に「9時間足せばいい」と考えないことです。固定で9時間足す方法は一見わかりやすいですが、タイムゾーンの扱いや表示形式が増えるほど管理が難しくなります。日本時間だけを扱う小さなワークフローなら動くかもしれませんが、長期運用ではsetZone('Asia/Tokyo')のように意味が明確な書き方にしたほうが保守しやすいです。

n8n公式ドキュメントでも、Date & Timeノードはワークフローのタイムゾーン設定、またはインスタンスのタイムゾーン設定に依存すると説明されています。セルフホスト環境ではデフォルトがAmerica/New Yorkになる場合があるとされているため、日本で使う場合はインスタンスやワークフローのタイムゾーンも確認しておくべきです。

🕘 UTCとJSTのズレのイメージ

UTC JST 起きやすい問題
2026-05-18 15:00 2026-05-19 00:00 日付が1日進んで見える
2026-05-19 00:00 2026-05-19 09:00 時刻だけ9時間ズレる
2026-05-19 23:00 2026-05-20 08:00 翌日扱いになる

特に注意したいのは、日次処理です。毎日0時や深夜に実行するワークフローでは、タイムゾーンがズレると取得対象の日付までズレます。GA4、Google Sheets、kintone、Notionなどと連携する場合、n8n側だけでなく、連携先のデータがどのタイムゾーンで保存されているかも確認したほうがよいでしょう。

✅ 9時間ズレを避けるチェックリスト

チェック項目 確認内容
ワークフロー設定 タイムゾーンがAsia/Tokyoか
n8nインスタンス セルフホストなら環境変数を確認
Codeノード new Date()だけに頼っていないか
Expression $now.setZone('Asia/Tokyo')を使っているか
連携先 Notionやkintone側の日付形式に合っているか

日付ズレは、エラーとして止まらないことも多いです。つまり、ワークフローは成功しているのに、保存された日付だけがズレるという形で発覚します。これは業務データではかなり厄介です。日付をキーにした集計やリマインドでは、実行成功よりも保存された日付が正しいかを必ず見るようにしてください。

Date & Timeノードは画面操作で日付加工したいときに向いていること

【AI】【業務効率化】【職場】Date & Timeノードは画面操作で日付加工したいときに向いていること

Date & Timeノードは、n8nで日付を扱うための標準的なノードです。公式ドキュメントによると、日付の加算、減算、整形、現在日時の取得、日付差分の計算、丸め処理などに対応しています。コードを書かずに設定できるため、ワークフローを見た人が処理内容を追いやすいのがメリットです。

このノードが特に向いているのは、日付操作を視覚的に残したい場面です。たとえば、Google Sheetsから受け取った日付をNotionに渡す前にYYYY-MM-DDへ変換する、現在日付を取得してフィールドに追加する、開始日と終了日の差分を日数で出す、といった処理です。

一方で、Date & Timeノードを多用しすぎると、ワークフローが横に長くなりやすいです。小さな日付変換のためだけにSetノード、Date & Timeノード、さらに別のSetノードを置いていると、あとから見たときに「どこで何を変換しているのか」がわかりにくくなることもあります。

🧭 Date & Timeノードの主な操作

操作 内容 使いどころ
Add to a Date 日付に時間を足す 期限日を作る
Subtract From a Date 日付から時間を引く 昨日・先週を作る
Format a Date 日付形式を変える NotionやSheets連携前
Get Current Date 現在日付を取得 実行日を記録
Get Time Between Dates 日付差分を計算 経過日数や期間計算
Round a Date 日付を丸める 月初・日単位の処理

Date & Timeノードの「Format a Date」では、プリセット形式やカスタム形式を使って出力できます。公式ドキュメントでは、YYYY-MM-DDやMM/DD/YYYYなどの例が紹介されています。ただし、Luxonのトークンは大文字・小文字の違いに意味があるため、カスタム形式を使うときは書き方に注意が必要です。

たとえば、NotionやAPIに渡す日付では2026-05-19のような形式が扱いやすいです。反対に、日本人向けに表示するだけなら2026/05/19や2026年5月19日のほうが読みやすいかもしれません。保存用と表示用を分けると、後続の処理が安定しやすくなります。

🛠️ Date & Timeノードが向くケース・向かないケース

判断軸 向いている 向かない場合がある
操作の見やすさ 画面で処理を確認したい 式1行で済む単純処理
チーム運用 非エンジニアも見る ノード数が増えすぎる
複雑な分岐 ノード単位で分けたい Codeノードのほうが整理しやすい
保守性 処理を明示したい 大量の日付変換がある

初心者はまずDate & Timeノードで理解し、慣れたらExpressionやCodeノードに置き換えるとよいです。特に、業務フローを他の人に見せる場合は、あえてノードとして残すことで説明しやすくなる場面もあります。効率だけでなく、誰が保守するワークフローなのかで選ぶのが現実的です。

Expressionのワンライナーは今日・昨日・明日の日付取得に向いていること

【AI】【業務効率化】【職場】Expressionのワンライナーは今日・昨日・明日の日付取得に向いていること

n8nでは、各ノードの入力欄でExpressionを使えます。Expressionとは、値の欄に直接コードのような式を書いて、実行時に値を作る仕組みです。日付処理では、$nowというLuxonのDateTimeオブジェクトを使うことで、現在時刻や日付の加減算ができます。

調査したQiita記事では、Date & Timeノードを置かなくても、Expressionで$now.toFormat('yyyy-MM-dd')のように書けば今日の日付を取得できると紹介されています。ノードを増やさずに済むため、シンプルな日付生成ではとても便利です。

参考：Qiita「n8n 日付操作でハマらないためのLuxonワンライナー」
https://qiita.com/YushiYamamoto/items/9541bb97a73508022047

たとえば、Google Sheetsの検索条件に今日の日付を入れたい場合、事前にSetノードでtodayを作らなくても、検索条件のValue欄に直接{{ $now.toFormat('yyyy-MM-dd') }}と書ける場合があります。これにより、日付を作るためだけのノードを減らせます。

⚡ よく使うLuxonワンライナー

やりたいこと Expression例
今日の日付 {{ $now.toFormat('yyyy-MM-dd') }}
明日の日付 {{ $now.plus({ days: 1 }).toFormat('yyyy-MM-dd') }}
昨日の日付 {{ $now.plus({ days: -1 }).toFormat('yyyy-MM-dd') }}
1週間後 {{ $now.plus({ weeks: 1 }).toFormat('yyyy-MM-dd') }}
JSTの日時 {{ $now.setZone('Asia/Tokyo').toFormat('yyyy-MM-dd HH:mm') }}

ただし、Expressionを使いすぎると、ノードの設定欄を開かないと処理が見えなくなります。小さな処理なら便利ですが、複雑な日付変換や複数フィールドの整形をExpressionに詰め込むと、後から保守しづらくなるかもしれません。

そのため、Expressionは短い・明確・再利用しない処理に向いています。たとえば「今日の日付をファイル名に入れる」「昨日の日付でAPI検索する」「Slack通知に現在日時を入れる」といった処理です。逆に、Google Sheetsから来た複数形式の日付を判定して変換するような処理は、CodeノードやDate & Timeノードに分けたほうが読みやすいでしょう。

📌 Expressionで済ませるかの判断表

条件 Expressionでよい ノード化したほうがよい
処理の長さ 1行で読める 複数条件がある
使う場所 1か所だけ 複数ノードで使う
読む人 自分だけ・小規模 チームで見る
エラー時の調査 簡単 途中結果を見たい

Expressionは、n8nの日付処理を軽くする強力な方法です。ただし、便利だから全部Expressionにするのではなく、見える化したい処理はノードに残すというバランスが大切です。

Notion連携ではISO 8601形式に整えることが重要であること

【AI】【業務効率化】【職場】Notion連携ではISO 8601形式に整えることが重要であること

n8nでNotionに日付を送るときは、日付形式に注意が必要です。調査したn8n Communityの投稿では、Google Sheetsから取得した日付をNotionに渡した際に、Notion側で「valid ISO 8601 date stringではない」という趣旨のエラーが出ていました。つまり、Notionが受け取れる形式に整っていないと、n8n上では途中まで成功していても、最後の登録で失敗することがあります。

参考：n8n Community「Notion date invalid」
https://community.n8n.io/t/notion-date-invalid-from-google/17785

このケースで重要なのは、「元データの形式」と「変換設定」を混同しないことです。Google Sheets側の日付が16-09-2022なら、From Date Formatには値そのものではなく、元の形式であるDD-MM-YYYYのようなパターンを指定する必要があります。調査元のやり取りでも、From Formatは現在のデータ形式を入れる場所だと説明されています。

Notionに渡すなら、一般的にはyyyy-MM-ddのようなISOに近い形式へ整えると扱いやすいです。ただし、Notion側のフィールド設定やn8nのノードバージョンによって細部が異なる可能性はあるため、エラー文を見ながら確認するのが安全です。

🧩 Google SheetsからNotionへ日付を渡す流れ

ステップ 内容 注意点
1 Google Sheetsから日付を取得 表示形式がdd/mm/yyyyなどの場合がある
2 Date & Timeノードで読み取り From Date Formatに元形式を指定
3 出力形式を変換 yyyy-MM-ddなどに整える
4 Notionの日付フィールドへ送信 ISO 8601形式を意識する

Notion連携でありがちなミスは、列名と値を取り違えることです。Google Sheetsノードの出力では、列名をキーとして値を参照します。たとえば列名がdateなら{{$json["date"]}}のような形になります。列名自体が日付になっているようなシート構成だと、式がわかりにくくなるため、業務用のシートでは列名を英数字で整えておくと保守しやすいです。

また、Notionの日付フィールドには日付だけでなく時刻を含める設定もあります。日付だけでよいなら、余計な時刻を入れないほうがトラブルを避けやすいです。時刻つきで登録する場合は、タイムゾーンの扱いがさらに重要になります。

🚫 Notion連携で避けたい設定例

避けたい状態 なぜ危ないか
From Formatに実際の日付値を入れる 形式ではなく値なので変換に失敗しやすい
dd/mm/yyyyのままNotionへ渡す ISO形式を求められると失敗しやすい
列名が日付そのもの 参照式がわかりにくくなる
JST変換なしで日時を送る 表示日がズレる可能性がある

Notion連携では、Notionに渡す直前で日付を整えるのがわかりやすいです。Google Sheets側の入力形式を完全に統一できない場合でも、n8n側で一度標準形式へ変換すれば、後続の処理が安定しやすくなります。

n8n アプリとして使うなら日付処理は最初に共通ルール化すること

【AI】【業務効率化】【職場】n8n アプリとして使うなら日付処理は最初に共通ルール化すること

「n8n アプリ」と検索する人は、n8nを単なる個人用自動化ツールではなく、業務アプリや社内連携の基盤として使いたい可能性があります。その場合、日付処理は最初に共通ルール化しておくべきです。なぜなら、日付はほぼすべての業務データに関係するからです。

たとえば、経費精算、問い合わせ管理、売上レポート、SNS投稿、GA4集計、Notion蓄積、kintone登録など、どのアプリ的なワークフローにも「いつ発生したか」「いつ処理するか」「いつ集計するか」が登場します。ここがワークフローごとに違う形式だと、後から連携や集計でつまずきやすくなります。

n8nをアプリのように使う場合、日付ルールはドキュメント化しておくとよいです。たとえば、「保存用はyyyy-MM-dd」「日時は必ずAsia/Tokyoへ変換」「外部APIに送る前にISO形式へ整える」「表示用は最後に変換する」などです。これだけでも、別の人がワークフローを編集するときの迷いが減ります。

🧱 n8nを業務アプリ化するときの日付ルール例

項目 ルール例
標準タイムゾーン Asia/Tokyo
保存用日付 yyyy-MM-dd
保存用日時 yyyy-MM-dd HH:mm:ss
API送信用 連携先のISO形式に合わせる
表示用 Slackやメール送信直前に整形

特にkintoneやNotionのようなデータベース型ツールと連携する場合、フィールド型と日付形式を合わせることが大切です。kintoneなら日付フィールド、数値フィールド、文字列フィールドなどがあります。NotionでもDateプロパティがあります。文字列で無理やり入れると見た目は入るかもしれませんが、後からフィルターやグラフで扱いにくくなる可能性があります。

「n8n アプリ」として運用するなら、日付処理はワークフローごとの小技ではなく、データ設計の一部です。最初にルール化しておけば、後からAI要約、集計、通知、ダッシュボード化を追加するときにも拡張しやすくなります。

📘 日付ルールを決めるメリット

メリット 内容
エラー削減 Invalid dateや日付ズレを減らせる
集計しやすい 日次・月次集計が安定しやすい
保守しやすい 他の人がワークフローを読める
拡張しやすい Notion、kintone、GA4などに広げやすい
AI活用しやすい 時系列データとして渡しやすい

n8nはノーコード寄りに使える一方で、実務ではデータ整形の考え方がかなり重要です。日付はその代表例です。アプリとして運用するなら、最初に日付の共通ルールを決めてから各ノードを組むと、あとからの修正コストを抑えやすくなります。

【AI】【業務効率化】【職場】n8n アプリとして使うなら日付処理は最初に共通ルール化すること
忘れる前に！【ふるさと納税】今年もお得に！
ふるさと納税のポイント付与は2025年10月に廃止になりました。
＼最大7.5%ポイントアップ！／
Amazon
楽天市場
Yahooショッピング
メルカリ

n8nの日付を実務で安定させる運用設計

【AI】【業務効率化】【職場】n8n アプリとして使うなら日付処理は最初に共通ルール化すること
  1. n8n のインストール方法を教えてくださいという人はタイムゾーン設定も同時に確認すること
  2. Docker運用ではGENERIC_TIMEZONEとTZを確認すること
  3. Codeノードではnew Dateだけに頼らずLuxonで明示すること
  4. GA4やkintone連携では取得対象日をJST基準で固定すること
  5. Google Sheetsの日付は列名・表示形式・値の型を分けて考えること
  6. ワークフローが増えるほど日付の保存用と表示用を分けること
  7. 総括：n8n 日付のまとめ

n8n のインストール方法を教えてくださいという人はタイムゾーン設定も同時に確認すること

【AI】【業務効率化】【職場】n8n のインストール方法を教えてくださいという人はタイムゾーン設定も同時に確認すること

「n8n のインストール方法を教えてください」と調べている段階では、ノードの使い方や画面操作に目が向きがちです。しかし、日付処理を日本時間で使うなら、インストール時点でタイムゾーン設定も確認しておくべきです。あとから直すこともできますが、ワークフローを作った後にズレに気づくと、どのデータからズレていたのか確認する手間が増えます。

n8n公式ドキュメントによると、Date & Timeノードはワークフローのタイムゾーン設定を使い、ワークフロー側で未設定ならインスタンスのタイムゾーン設定を使うとされています。セルフホスト環境ではデフォルトがAmerica/New Yorkになる場合があるという記載もあります。日本で使う場合は、この初期値のままだと意図しない日付になる可能性があります。

インストール直後に確認したいのは、n8n本体のタイムゾーン、ワークフローごとのタイムゾーン、そしてSchedule Triggerのタイムゾーンです。特にSchedule Triggerで「毎朝9時」や「毎日3時」に実行する場合、タイムゾーンが違うと実行時刻そのものがズレます。

⚙️ n8n導入時の日付関連チェック

確認場所 確認内容
n8nインスタンス デフォルトタイムゾーン
ワークフロー設定 Workflow timezone
Schedule Trigger 実行時刻のタイムゾーン
Codeノード new Date()の扱い
外部連携先 保存される日付形式

クラウド版とセルフホスト版では、タイムゾーンの扱いが少し異なる可能性があります。公式ドキュメントでは、n8n Cloudは登録時にオーナーのタイムゾーンを検出しようとし、できない場合はGMTにフォールバックすると説明されています。セルフホストの場合は環境変数で変える形になります。

ここで重要なのは、「画面の表示時刻が合っているから大丈夫」と判断しないことです。表示はJSTでも、Codeノードや外部APIに渡している値がUTCのままということもありえます。特にnew Date().toISOString()のような出力はUTCを示すZが付くため、そのまま人間向けの日本時間として扱うとズレて見えます。

✅ インストール直後に試す簡単テスト

テスト 見るポイント
Get Current Dateを実行 JSTで期待通りか
Expressionで$nowを表示 タイムゾーンが意図通りか
Codeノードでnew Date()を表示 UTC表示との違いを確認
Schedule Triggerをテスト 実行時刻が日本時間か
NotionやSheetsへ保存 保存後の表示日付が正しいか

n8nのインストール方法を調べている人ほど、最初に日付とタイムゾーンを確認しておくとよいです。ワークフロー作成後に修正するより、最初に基準をそろえたほうが、後々のトラブルを減らしやすくなります。

Docker運用ではGENERIC_TIMEZONEとTZを確認すること

【AI】【業務効率化】【職場】Docker運用ではGENERIC_TIMEZONEとTZを確認すること

n8nをDockerでセルフホストする場合、タイムゾーン設定は特に重要です。調査したQiita記事では、Docker環境でGENERIC_TIMEZONE=Asia/TokyoとTZ=Asia/Tokyoを設定する方法が紹介されています。これにより、n8nのスケジュール実行や環境側の時刻設定を日本時間に寄せられる可能性があります。

ただし、環境変数を設定したからといって、すべてのCodeノードの日付処理が自動的に期待通りになるとは限りません。記事内でも、new Date()の結果はUTCやコンテナのシステム時刻として扱われる場合があるため、コード内ではLuxonで明示的にタイムゾーンを指定するのが安全だとされています。

Docker運用で怖いのは、サーバー、コンテナ、n8n、ワークフロー、連携先のタイムゾーンがそれぞれ違う状態です。この状態でもワークフロー自体は動くことがあります。しかし、日次集計や予約投稿のような処理では、ズレたまま実行される可能性があります。

🐳 Docker運用で見るべきタイムゾーン層

層 例 確認内容
ホストOS VPSや社内サーバー OSのタイムゾーン
Dockerコンテナ n8nコンテナ TZの設定
n8n本体 環境変数 GENERIC_TIMEZONE
ワークフロー Workflow settings Asia/Tokyoか
Code/Expression Luxon setZoneしているか

docker-compose.ymlで設定する場合、調査情報では以下のような環境変数が紹介されていました。

environment:
  - GENERIC_TIMEZONE=Asia/Tokyo
  - TZ=Asia/Tokyo

この設定は、日本時間でSchedule Triggerを動かしたい場合に役立つ可能性があります。ただし、実際の環境によっては、n8nのバージョンや構成、リバースプロキシ、ホストOSの設定なども関係するかもしれません。設定後は、必ず実際にワークフローを実行して、出力される日付を確認してください。

🧪 Docker設定後の確認項目

確認するもの 期待する状態
Schedule Trigger 日本時間で実行される
Date & Timeノード JST基準で現在日付が出る
$now.setZone('Asia/Tokyo') 意図したJST表示になる
外部DBへの保存 日付が1日ズレていない
ログ表示 監視しやすい時刻になっている

Docker運用では、日付の問題が「n8nの問題」なのか「コンテナの問題」なのか「コードの問題」なのか切り分けにくいです。だからこそ、環境変数で土台を整え、ワークフロー内ではLuxonで明示する、という二段構えにするとよいでしょう。

Codeノードではnew Dateだけに頼らずLuxonで明示すること

【AI】【業務効率化】【職場】Codeノードではnew Dateだけに頼らずLuxonで明示すること

n8nのCodeノードは、JavaScriptやPythonで柔軟に処理を書ける強力なノードです。調査したFuture Spiritsの記事では、Codeノードを使って記事データを整形し、公開日をDateオブジェクトに変換してソートする例が紹介されています。データの重複排除、日付変換、並び替えなどをまとめて処理できる点がCodeノードの強みです。

参考：Future Spirits「初めての本格的n8nワークフロー ③」
https://blog.future.ad.jp/n8n-hands-on-06-03

ただし、日付処理でnew Date()だけに頼ると、タイムゾーンの扱いで迷いやすくなります。new Date()はJavaScript標準のDateオブジェクトで、ISO文字列やローカルタイムの表示に変換できますが、n8nの実行環境や出力方法によって見え方が変わることがあります。

n8nではLuxonが利用できるため、日付を扱う意図が明確な場合はLuxonを使うほうが読みやすいです。たとえば、現在の日本時間を作るなら$now.setZone('Asia/Tokyo')、昨日の日付なら$now.minus({ days: 1 })または$now.plus({ days: -1 })のように書けます。

💻 Codeノードでの日付処理の考え方

方法 特徴 向いている場面
new Date() JS標準で使える 単純な日時取得
toISOString() UTCのISO文字列になりやすい API送信用
$now n8nのLuxon DateTime 現在時刻の扱い
setZone() タイムゾーン明示 JST変換
toFormat() 表示形式を指定 Sheetsや通知用

Codeノードでは、入力データをまとめて処理する場合が多いです。たとえば、複数行のGoogle Sheetsデータを受け取り、日付で並び替え、古いものを除外し、最新の数件だけを返すといった処理です。この場合、日付のパースに失敗したデータが混じると、並び替え結果が壊れることがあります。

そのため、Codeノードで日付を扱うなら、元データの形式をそろえるか、形式が違う可能性を考慮して処理するのが望ましいです。提供データの範囲では詳細な例まではありませんが、一般的には、空欄や不正な日付が入る可能性がある業務データでは、変換前に値の有無をチェックしたほうがよいでしょう。

🧯 Codeノードで避けたい日付処理

避けたい書き方・状態 理由
new Date()の出力をそのまま表示用に使う UTC/JSTのズレに気づきにくい
元形式不明の文字列を直接Date化 Invalid Dateになりやすい
日付空欄を考慮しない ソートや比較が壊れやすい
表示用と保存用を混ぜる 後続連携で形式が合わなくなる

Codeノードは便利ですが、自由度が高いぶん、日付処理の責任も自分で持つ必要があります。小さな変換はExpression、視覚的に残したい処理はDate & Timeノード、複雑な整形や並び替えはCodeノードというように分けると、n8n全体のワークフローが読みやすくなります。

GA4やkintone連携では取得対象日をJST基準で固定すること

【AI】【業務効率化】【職場】GA4やkintone連携では取得対象日をJST基準で固定すること

GA4やkintoneとn8nを連携する場合、日付処理は単なる表示の問題ではなく、データの信頼性に直結します。調査したアディエムの記事では、GA4のアクセスデータをn8nで取得し、kintoneに送信してダッシュボード化する流れが紹介されています。その中で、GA4・n8n・kintoneのタイムゾーンがズレると、取得対象日がズレるリスクがあると説明されています。

参考：株式会社アディエム「Google Analytics × n8nで、Webサイトのアクセスデータをkintoneに自動表示してみた」
https://adiem.jp/blog/ga4-kintone-n8n/

GA4のようなアクセス解析では、「昨日のセッション数」を取得するつもりでも、タイムゾーンがズレると一昨日や今日の一部データを取得してしまう可能性があります。kintoneに保存されたあとで数字が合わないと言われると、原因調査に時間がかかります。

記事では、安定運用を優先するならGA4の反映タイムラグを考慮して「2日前のデータ」を取得する設定も紹介されています。これは、速報性より正確性を重視する現場では有効な考え方です。ただし、実際の反映時間や必要な速報性はサイトや運用目的によって異なるため、要件に合わせて判断する必要があります。

📊 GA4→n8n→kintoneで日付が重要な理由

場面 日付がズレた場合の影響
GA4データ取得 対象日のデータが変わる
kintone保存 グラフの日付軸がズレる
月次レポート 集計期間が合わない
AI要約 間違った期間を分析する
Slack通知 現場が誤った数字を見る

kintone側では、日付フィールド、数値フィールドなどの型を適切に設定することも重要です。日付を文字列で入れると、とりあえず表示はできるかもしれませんが、グラフ化や日付フィルターで扱いにくくなる可能性があります。GA4のセッション数やCV数は数値として、日付は日付型として保存するのが自然です。

n8n側では、取得対象日をExpressionで作ると管理しやすいです。たとえば、JST基準の2日前を使うなら、$now.setZone('Asia/Tokyo').plus({ days: -2 }).toFormat('yyyy-MM-dd')のような考え方になります。実際のノード設定では、GA4ノードが受け付ける形式に合わせて調整してください。

🧮 取得対象日の考え方

運用目的 取得対象日 理由
速報確認 昨日 早く見たい場合
正確性重視 2日前 GA4反映待ちを考慮
月次集計 前月 レポート用途
異常検知 当日または昨日 速報性が必要
定例会議 会議前日まで 説明しやすい期間にする

GA4やkintone連携では、ワークフローが動くだけでは不十分です。保存された数字が、現場が見ているGA4画面や会議資料と同じ意味を持っているかが重要です。そのため、日付処理は最初にテストデータで照合し、ズレがないかを確認してから本番化したほうがよいでしょう。

Google Sheetsの日付は列名・表示形式・値の型を分けて考えること

【AI】【業務効率化】【職場】Google Sheetsの日付は列名・表示形式・値の型を分けて考えること

n8nでGoogle Sheetsから日付を取得する場合、見た目どおりの値がそのまま扱えるとは限りません。Google Sheetsでは、セルの表示形式と内部の値が違うことがあります。たとえば、画面では2026/05/19に見えていても、n8n側では別の形式やシリアル値に近い形で扱われる可能性があります。

調査したNotion連携のn8n Community投稿でも、Google Sheetsから取得した日付をNotionに渡す過程で、From Formatの指定が問題になっていました。ここからわかるのは、Sheets側の見た目に合わせて処理するのではなく、n8nの実行結果で実際にどの値が出ているかを見る必要があるということです。

Google Sheets連携では、まず出力データを確認しましょう。n8nの実行結果で、日付列がどのキー名で、どの値として入っているかを確認します。列名が日本語でも動く場合はありますが、後続のExpressionで参照しやすくするなら、dateやpublished_atのような英数字の列名にしておくと扱いやすいです。

📄 Google Sheetsの日付で分けて見るべき要素

要素 例 注意点
列名 date Expressionで参照するキーになる
表示形式 2026/05/19 見た目だけの可能性がある
実際の値 2026-05-19など n8nの出力で確認する
変換形式 yyyy-MM-dd 後続ノードに合わせる
送信先形式 Notionやkintoneの要求 最終的にここへ合わせる

Sheetsの日付をNotionやkintoneへ送る場合、Sheetsの形式をそのまま信じるより、n8n内で一度整形したほうが安定しやすいです。たとえば、Sheetsから来たdd/mm/yyyyをDate & Timeノードで読み取り、yyyy-MM-ddに変換してから送信する、という流れです。

また、Google Sheetsの列名に日付そのものを使うと、n8nで参照するときに混乱しやすくなります。調査元のCommunity投稿でも、列名なのか値なのかがわかりにくい部分がありました。業務フローでは、列名は意味を表す名前にし、値として日付を入れるのが管理しやすいです。

🧹 Google Sheets側で整えておきたいこと

整える項目 おすすめ
列名 英数字で固定する
日付列 1列に統一する
表示形式 できればyyyy-MM-dd
空欄 n8n側で処理を分ける
入力ルール 手入力なら形式をそろえる

Google Sheetsは手軽ですが、人が手入力するぶん、日付の揺れが起きやすいです。n8nで自動化するなら、Sheetsをデータベースの入口として使う意識を持ち、列名と日付形式を整えておくと後続の処理が安定します。

ワークフローが増えるほど日付の保存用と表示用を分けること

【AI】【業務効率化】【職場】ワークフローが増えるほど日付の保存用と表示用を分けること

n8nのワークフローが1つだけなら、日付形式が多少雑でも動くかもしれません。しかし、ワークフローが増えてNotion、Google Sheets、kintone、Slack、GA4、メールなどにつながり始めると、日付形式の混在が大きな問題になります。そこで大事なのが、保存用の日付と表示用の日付を分ける考え方です。

保存用の日付は、後から検索・集計・連携しやすい形式にします。たとえばyyyy-MM-ddやISO 8601形式です。一方、表示用の日付は、人が読みやすい形式にします。たとえば2026年5月19日や5/19 09:00などです。これを混ぜると、見た目は親切でも、後続処理で扱いにくくなることがあります。

たとえばSlack通知では「2026年5月19日 9時」と表示したいかもしれません。しかし、kintoneやNotionへ保存する値も同じ表示文字列にしてしまうと、日付フィルターやグラフで使いにくくなる可能性があります。通知直前だけ表示用に変換するほうが、データとしては扱いやすいです。

🗂️ 保存用と表示用の違い

種類 形式例 主な用途
保存用日付 2026-05-19 DB保存、検索、集計
保存用日時 ISO形式やyyyy-MM-dd HH:mm:ss API連携、履歴管理
表示用日付 2026年5月19日 メール、Slack、画面表示
ファイル名用 20260519 レポート名、CSV名
検索条件用 連携先指定形式 SheetsやAPI検索

日付処理を安定させるには、ワークフローの途中では保存用形式を維持し、最後の出力先に応じて表示用へ変換するのがわかりやすいです。たとえば、GA4から取得した日付をkintoneへ保存するときはyyyy-MM-dd、Slack通知ではyyyy/MM/ddにする、といった分け方です。

この考え方は、AI要約にも役立ちます。kintoneに蓄積したGA4データをAIに渡して「先月の傾向」を要約する場合、日付が標準形式でそろっているほうが、期間指定や並び替えがしやすくなります。表示用文字列ばかりだと、AIに渡す前の整形が増えるかもしれません。

🧭 出力先ごとの日付形式の考え方

出力先 おすすめの考え方
Notion Dateプロパティに合うISO形式
kintone 日付フィールドに合う形式
Google Sheets 検索しやすい形式に統一
Slack 人が読みやすい表示用
ファイル名 記号を少なくする
API 公式ドキュメントの形式に合わせる

ワークフローが増えるほど、日付処理は個別対応ではなく設計になります。保存用と表示用を分けるだけで、n8nの自動化はかなり運用しやすくなります。

総括：n8n 日付のまとめ

【AI】【業務効率化】【職場】総括：n8n 日付のまとめ

最後に記事のポイントをまとめます。

  1. n8n 日付の基本は値・形式・タイムゾーンをそろえることである。
  2. 日本時間で使うならAsia/Tokyoを明示することが重要である。
  3. 9時間ズレの主因はUTCとJSTの扱いが混ざることである。
  4. Date & Timeノードは画面で日付操作を見せたい場合に向いている。
  5. ExpressionのLuxonワンライナーは今日・昨日・明日の日付取得に便利である。
  6. Codeノードではnew Date()だけに頼らずLuxonで意図を明示するべきである。
  7. Notion連携ではISO 8601形式を意識して日付を整える必要がある。
  8. Google Sheetsの日付は列名・表示形式・実際の値を分けて確認するべきである。
  9. Docker運用ではGENERIC_TIMEZONEとTZを確認することが重要である。
  10. GA4やkintone連携では取得対象日をJST基準で固定する設計が必要である。
  11. n8nを業務アプリのように使うなら日付処理は共通ルール化するべきである。
  12. 保存用の日付と表示用の日付は分けて扱うほうが運用しやすい。
  13. ワークフローが成功しても保存された日付が正しいとは限らないため、実データで確認する必要がある。
  14. 日付処理は小さな設定に見えるが、集計・通知・連携の信頼性を左右する重要な設計要素である。

関連記事

✓codex error loading configuration failed to load your workspace-managed configで詰んだ人へ、まず見るべき原因と直し方
✓エス・エム・エスの決算がヤバい理由を数字で整理！増収なのに最終赤字の正体
✓引越し屋は「底辺」なのか？そう言われる6つの理由を解説します。
✓職場でお土産を置いておくメモはこれでOK！迷わない例文と失礼にならない置き方
✓丸投げ上司の末路。無能な丸投げ上司を潰すには？具体的対処法を公開
✓フォワーダーは「底辺」なのか？そう言われる6つの理由を解説します。
✓国家公務員で年収1000万は本当に狙える？総合職・一般職のリアルな到達ライン
✓石田さんちお父さんの年収がすごい？ロレアル時代・退職金・現在の仕事まで丸わかり
✓丸紅の決算は何時に出る？11時発表の傾向と次回チェック術をサクッと整理
✓zapier tohaとは何のこと？検索で迷子になった人向けにZapier・Toha・自動化をまるっと整理
記事作成にあたり参考にさせて頂いたサイト

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

AI 業務効率化 職場
ABOUT ME
カシワギ
『エグゼクティブワーク』編集長のカシワギです。 普段はITベンチャーで執行役員の40代男です。 元コンサルタントですが、今はテクノロジー企業で日々奮闘中。 仕事では厳しい顔をしていますが、家では小学生の子供2人のやんちゃなパパ。 休日はゴルフに行ったり、妻とワインを楽しんだり。
BLOG：https://min-biz.net/
当サイトについて
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。