自動化の日時ズレ対策:タイムゾーン・スケジュール・祝日の注意点

まず設定の「優先順位」を確認する

公式ドキュメントで確認できた範囲では、定時実行の基準になるタイムゾーンはツールごとに置き場所が違います(確認日:2026年10月28日、プランによる差までは確認していません)。

• n8n、実行時刻の基準：ワークフロー設定のタイムゾーン。未設定ならインスタンスのタイムゾーン、見落としやすい点：Cloudの初期値は所有者の地域を検出し、できなければGMT。セルフホストの初期値はAmerica/New York
• Zapier、実行時刻の基準：Zapではなくアカウントのタイムゾーン、見落としやすい点：変更後はZapをオフ→オンにしないと反映されない
• Make、実行時刻の基準：組織のタイムゾーン、見落としやすい点：ユーザーのタイムゾーンは表示用で、実行時刻には影響しない

出典:n8n Schedule Trigger、n8n Cloudのタイムゾーン設定、Schedule by Zapier、Makeのタイムゾーン管理。

特にMakeは、自分のプロフィールを日本時間にしていても、組織側が別の地域のままだと、ログは日本時間で見えるのに実行は組織の時刻で動きます。組織の変更は、公式ドキュメント上はオーナーか管理者だけの操作です。Zapierもチームで使っている場合、Zap作成者ではなくアカウント側の設定が効く点に注意してください。

n8nのセルフホストは、環境変数GENERIC_TIMEZONEでグローバルな設定をします。初期値のまま使うと米国東部時間で動くので、日本向けなら最初に確認したい項目です。

「動かない」ときに見る順番

タイムゾーン以外にも、定時実行が動かない典型要因があります。公式に書かれている範囲で並べます。

• n8n:スケジュールを使うワークフローは保存して公開(有効化)されている必要があります。 変数をスケジュール値に使っている場合、その値は公開した時点で評価されます。値を変えたら再公開が必要です。
• n8n:間隔を変更した場合も再公開が必要です。 公式の Common issues では、スケジュールは公開した時点から始まると説明されています。
• Zapier:指定した分ちょうどの実行は保証されません。 数分以内に動く、という説明です。9:00ちょうどに依存する処理は、設計を見直したほうが安全です。
• Zapier:履歴の時刻はUTC表示です。 日本時間の9:00に動いていても、履歴では前日の0:00と見えます。「ズレている」と思い込む典型です。
• Make:ユーザー時刻の表示とシナリオの実行時刻は別物です。 上の表のとおりです。

夏時間(サマータイム)については、Zapierのコミュニティ投稿に「夏時間の切り替えで実行時刻が1時間動いた」という報告があります。ただ、これは公式ヘルプではなく利用者の投稿なので、本記事では確認済みの仕様としては扱いません。日本は夏時間がないため、関係するのは海外拠点のアカウントや、海外のカレンダー・APIと連携するときです。n8nとMakeの公式ページでは、夏時間の挙動に関する記述は確認できませんでした。

時刻まわりの確認項目リスト

トラブル時はこの順に確認してください。

1. 実行基準の設定(n8n:ワークフロー設定とインスタンス設定、Zapier:アカウント、Make:組織)がAsia/Tokyo(日本時間)になっているか
2. 設定を変えた後、必要な再操作(Zapierのオフ→オン、n8nの再公開)をしたか
3. 実行履歴の時刻が、UTC表示かユーザー表示かを確認したか
4. 実行されなかったのか、遅れたのか。実行履歴に記録があるか
5. 間隔指定(「9時間ごと」など)と時刻指定(「毎日9時」)を取り違えていないか
6. 土日や祝日をスケジュール側で除外していないか、逆に除外が必要なのに入れていないか
7. 期限の元データが、タイムゾーン付きの日時か、日付だけか
8. 月末・月初(31日が存在しない月など)の指定が意図どおりか
9. 連携先(カレンダー、フォーム、CRM)が返す時刻のタイムゾーンは何か
10. 通知文面に出す時刻は、表示用に日本時間へ変換しているか

6について補足します。Zapierの毎日実行には週末を除外する選択肢があることを確認できました。しかし、祝日を除外する設定は、今回読んだ公式ページでは確認できていません。祝日に動かしたくない場合は、「実行はするが、冒頭で祝日かどうかを判定して止める」構成を検討してください。祝日の一覧は年によって変わり得るため、手書きの固定リストではなく、公的機関が公表する一覧を元に更新する運用を前提にします。

期限通知を試すテスト例

本番の期限をそのまま待つと検証に何日もかかります。テスト用のデータを作り、実行時刻を数分後に設定する方法が現実的です。下の表は説明用の例で、私が実行した結果ではありません。基準日は2026年11月とし、通知は「期限の前営業日の9:00に送る」ルールだと仮定しています。

• A、期限(入力)：2026-11-10 17:00 +09:00(火)、期待する通知日時：11-09(月) 9:00、見たいポイント：通常の平日
• B、期限(入力)：2026-11-09 10:00 +09:00(月)、期待する通知日時：11-06(金) 9:00、見たいポイント：週末をまたぐか
• C、期限(入力)：2026-11-24 00:00 +09:00(火)、期待する通知日時：11-20(金) 9:00、見たいポイント：11-23が勤労感謝の日で休みになる前提で、前営業日がずれるか
• D、期限(入力)：2026-11-10T08:00:00Z、期待する通知日時：日本時間17:00の期限として扱う、見たいポイント：UTC表記を日本時間に直せているか
• E、期限(入力)：2026-11-10(日付のみ)、期待する通知日時：11-09(月) 9:00、見たいポイント：日付だけの値を何時扱いにしているか
• F、期限(入力)：2026-11-30 23:59 +09:00、期待する通知日時：11-27(金) 9:00、見たいポイント：月末・日付境界

Cの祝日扱いは、必ず公的な祝日一覧で当年のカレンダーを確認してから使ってください。Dは、UTCの8:00が日本時間の17:00になることを使った例です。

手順は次のとおりです。

1. テスト用の連携先(ダミーのシートやタスク)に、上の期限を入れる。実際の顧客名などは入れない。
2. 通知先を自分だけのテストチャンネルに変更する。
3. 本番の「毎朝9時」を、現在時刻の5〜10分後に一時変更して実行する。
4. 実行履歴の時刻(UTC表示かどうか)と、届いた通知の日時を表と照合する。
5. 合っていなければ、確認項目リストの1→7の順に戻る。
6. 検証後、スケジュールを本来の時刻に戻し、n8nなら再公開、Zapierならオフ→オンを行う。

AIに任せてよいことと、人が見ること

AIには、テストデータの作成と、期待値の下書きを任せられます。次の依頼文を使えます。

次のルールで、期限通知のテストケースを表にしてください。
ルール:期限の前営業日の9:00(Asia/Tokyo)に通知する。
営業日は月〜金で、祝日は除く。
入力形式:日本時間のオフセット付き日時、UTC表記、日付のみ。
条件:架空の日付だけを使い、2026年11月の範囲で、週末またぎ・祝日・月末を含める。
出力列:期限(入力)/期待する通知日時/確認観点
祝日は「要確認」と明記し、断定しないでください。

人が必ず確認するのは次の三点です。

• 祝日の判定:AIの出す祝日は誤ることがあるため、公的な一覧と照合する。
• 期待値の計算:前営業日の数え方が自社のルールと合っているか。
• 実機の結果:ツールの実行履歴と通知の実物。AIの予想は、実行結果の代わりになりません。

実際の顧客情報や社内の期限データをAIに渡す場合は、社内の取り扱いルールに従い、説明用のダミー値に置き換えてください。

設定を直しても再発しないために

設定を直したら、そのタイムゾーンをツールの説明欄やメモに残してください。「Asia/Tokyoで運用」「祝日は冒頭で判定」といった一行で十分です。担当者が変わったり、アカウントを作り直したりしたときに、初期値(GMTや米国東部時間)へ戻って再発することが多いためです。通知文面にも「2026-11-09 09:00 JST」のようにタイムゾーンを入れておくと、ズレが起きたときに原因を切り分けやすくなります。