n8nのスケジュールが13時間ずれる原因と直し方｜タイムゾーン設定

n8n 実務ノート公開 2026年9月13日更新 2026年9月15日

n8nのスケジュール（Schedule Trigger）が、設定した時刻より13時間遅れて動くことがあります。原因は、n8nのタイムゾーンが初期設定のままになっていることです。n8nは、何も設定しなければアメリカ東部時間（America/New_York）で時刻を数えます。

この記事では、弊社が本番で動かしているn8nで実際に起きたずれと、直し方、直ったことの確かめ方をまとめます。

この記事の結論

「毎朝10時」のスケジュールが夜11時に動いていたら、n8nのタイムゾーンが America/New_York のままになっていないかを確認します。
直し方は、環境変数 GENERIC_TIMEZONE を Asia/Tokyo にして、n8nを再起動することです。サーバー側の時刻も合わせるなら TZ も Asia/Tokyo にします。
直ったかどうかは、Schedule Trigger の出力に出る「Timezone」で確かめられます。

実際に起きたこと：お礼のLINEが夜11時に届いていた

2026年7月、弊社が本番で動かしているセルフホストのn8nで見つけました。来店の翌日にお客様へお礼のLINEを送るワークフローを、毎朝10時に動くように組んでいました。スケジュールの設定は cron で 0 10 * * * です。

ところが実行履歴を見ると、5日続けて23時に動いていました。お客様には、夜11時にお礼のメッセージが届いていたことになります。

同じサーバーのワークフローを調べると、31本が同じようにずれていました。正しい時刻に動いていたのは1本だけで、それはワークフロー個別の設定でタイムゾーンを Asia/Tokyo にしていたものでした。

原因：タイムゾーンの初期値が America/New_York になっている

n8nの公式ドキュメントでは、環境変数 GENERIC_TIMEZONE の初期値は America/New_York で、Schedule Trigger などのスケジュール系のノードはこのタイムゾーンで動く、と説明されています。

弊社のサーバーに入っていたn8n（2.19.2）のプログラムでも、設定の初期値は次のようになっていました。

this.timezone = 'America/New_York';

何も設定していないと、0 10 * * * は「ニューヨークの朝10時」という意味になります。日本時間に直すと次のとおりです。

時期	ニューヨークの時刻	「朝10時」が日本時間で動く時刻	ずれ
夏時間の期間（3月の第2日曜〜11月の第1日曜）	協定世界時より4時間遅い	その日の23時	13時間
それ以外の期間	協定世界時より5時間遅い	翌日の0時	14時間

夏時間があるので、ずれの幅は年に2回、何もしなくても変わります。「13時間ずらして書いておく」という直し方はできません。

タイムゾーンが決まる順番

n8nは、次の順番でタイムゾーンを決めます。

ワークフローの設定（Settings の Timezone）に指定があれば、それを使う
なければ、n8n全体の設定（環境変数 GENERIC_TIMEZONE）を使う
どちらもなければ America/New_York を使う

公式ドキュメントのワークフロー設定の説明にも、ワークフローとインスタンス（n8n全体）のどちらのタイムゾーンも設定しなければニューヨークの時間になる、と書かれています。弊社で1本だけ正しく動いていたのは、1のワークフロー設定を入れていたからでした。

直し方

1. 環境変数を2つ設定する

GENERIC_TIMEZONE はスケジュール系のノードの時刻を、TZ はサーバー側の時刻（date コマンドなどが返す時刻）を決めます。公式のDockerの手順でも、この2つを並べて設定しています。

GENERIC_TIMEZONE=Asia/Tokyo
TZ=Asia/Tokyo

Dockerで動かしている場合の例です。

docker run -it --rm \
 --name n8n \
 -p 5678:5678 \
 -e GENERIC_TIMEZONE="Asia/Tokyo" \
 -e TZ="Asia/Tokyo" \
 -v n8n_data:/home/node/.n8n \
 n8nio/n8n

docker compose の場合は、environment に同じ2行を足します。

services:
  n8n:
    image: n8nio/n8n
    environment:
      - GENERIC_TIMEZONE=Asia/Tokyo
      - TZ=Asia/Tokyo

npmで入れて常駐させている場合は、n8nを起動する仕組み（systemd、launchd、起動スクリプトなど）の中で、この2つを渡します。

2. n8nを再起動する

環境変数は、n8nが起動したときに読み込まれます。設定を書き換えただけでは反映されないので、必ず再起動します。

3. 必要なら、ワークフローごとにも指定する

特定のワークフローだけ別のタイムゾーンで動かしたい場合は、ワークフローの Settings にある Timezone で指定できます。こちらはn8n全体の設定より優先されます。

直ったかを確かめる

Schedule Trigger の出力を見る

Schedule Trigger は、動いたときの出力に、使ったタイムゾーンを書き出します。弊社の本番で朝7時に動いた実行の出力は、次のとおりでした（一部を省略しています）。

{
  "timestamp": "2026-09-12T07:00:00.963+09:00",
  "Readable time": "7:00:00 am",
  "Timezone": "Asia/Tokyo (UTC+09:00)"
}

ここが America/New_York になっていたら、設定がまだ効いていません。

数分後の時刻で試しに動かす

確実に確かめるには、数分後の時刻に動く使い捨てのワークフローを作り、その時刻ちょうどに動くかを見ます。弊社では9時43分に動く設定を入れて再起動し、9時43分00秒に動いたことを確かめてから、そのワークフローを消しました。

設定したのに直らないとき

環境変数を書いたのに直らない場合は、動いているn8nのプロセスに、その環境変数が本当に入っているかを見てください。弊社では、n8nを起動する仕組みが2つあり、実際に動いていたほうが別の設定ファイルを読んでいた、ということがありました。

# Linux
cat /proc/<n8nのプロセスID>/environ | tr '\0' '\n' | grep -E 'GENERIC_TIMEZONE|TZ'

# macOS
ps eww <n8nのプロセスID> | tr ' ' '\n' | grep -E 'GENERIC_TIMEZONE|TZ'

ここに表示されなければ、その設定はn8nに届いていません。