n8nで定期実行するワークフローは、Schedule Triggerを先頭に置き、「いつ動かすか」と「その時間に何をするか」を分けて設計するのが基本です。
現在のSchedule Triggerでは、秒・分・時間・日・週・月に加えてCustom Cronを設定できます。複数のTrigger Ruleを1つのノードへ持たせることもできます。
目次
先に結論:Schedule Triggerより前に運用条件を決める
表は横にスクロールできます
| 決めること | 例 | 確認ポイント |
|---|---|---|
| 頻度 | 毎朝 / 毎週 / 30分ごと | 必要以上に細かくしない |
| Timezone | 日本時間 | Workflow / instance設定 |
| 実行内容 | 集計→通知など | Scheduleと業務処理を分離 |
| 本番化 | Publish | Editorで作っただけでは継続実行されない |
| 取りこぼし | Missed execution | 運用要件に応じて扱いを決める |
「毎朝9時に動かす」だけでなく、停止や失敗が起きた場合まで含めて定期実行を設計します。
最小構成を作る
まず実行頻度を決める
「毎朝9時」「毎週月曜」「30分ごと」など、業務上必要な頻度を先に決めます。細かく回すほどAPI callや実行回数も増えるため、必要以上に高頻度にしません。
Schedule Triggerを先頭に置く
ワークフローのトリガーとしてSchedule Triggerを追加します。固定intervalで十分ならDays / Weeksなどを使い、複雑な時刻条件が必要な場合だけCustom Cronを使います。
Timezoneを確認する
時刻指定ではワークフロー timezoneまたはinstance timezoneが使われます。日本時間で動かしたいのに別timezoneのままだと、実行時刻がずれます。
Trigger Ruleを設定する
毎週月曜9時、毎月1日など、必要なruleを設定します。Schedule Triggerは複数ruleも持てるため、同じ処理を複数時刻で動かす場合にも使えます。
本番につなぐ
後続処理をつなぐ
Google Sheets取得、API call、集計、Slack通知など、scheduled execution後に行うアクションをつなぎます。定期実行のノードと業務処理を分けて考えると変更しやすくなります。
Test executionで処理内容を確認する
scheduleを待つ前にmanual executionで後続ノードのデータ flowを確認します。日時条件以外のロジックは先にテストしておきます。
Publishして本番実行する
Schedule Triggerを本番で動かすにはワークフローを公開する必要があります。editorで作っただけでは継続実行されません。
Missed executionの扱いも確認する
現行n8nでは対応環境・versionのSchedule Triggerに、instance停止などで予定時刻を逃した場合の扱いを設定できるoptionsがあります。運用要件に応じて「捨てる」「直近分をcatch upする」などを確認します。
AIものさしの判断
定期実行ワークフローは、cron式を書くことより「業務上いつ動けば十分か」を決める方が重要です。
frequency→timezone→schedule rule→アクション→テスト→公開→monitorの順にすると、時間起点の自動化を運用しやすくなります。
AIものさしでは、指定時刻に1回動いたことではなく、正しいtimezone・頻度で継続実行され、失敗時にも追える状態をこのワークフローの完了条件にします。
まず「何時に動くか」を日本時間で固定する
Schedule Triggerの時刻は、ノードの画面に入力した数字だけでは確定しません。n8nはworkflow timezoneが設定されていればそれを使い、未設定ならinstance timezoneを使います。セルフホストの既定値はAmerica/New_York、n8n Cloudは登録時のowner timezoneを検出し、検出できない場合はGMTを使うと公式Docsにあります。東京の午前9時に動かすつもりなのにinstanceが別timezoneなら、実行時刻がずれるため、最初にWorkflow Settingsとinstance側のtimezoneを確認します。
たとえば毎営業日の日本時間9時に集計するなら、次を埋めてからSchedule Triggerを設定します。
表は横にスクロールできます
| 運用条件 | 決める値 |
|---|---|
| 期待する時刻 | 09:00 JST |
| timezoneのauthority | workflow timezoneを指定するか、instance設定を使うか |
| 対象日 | 平日のみか、祝日も含むか |
| 入力元 | 集計対象の期間・締め時刻 |
| 二重実行時 | 同じ日付の処理済み記録を確認する |
| 成功の定義 | 集計結果が保存され、通知先へ届いた状態 |
曜日や祝日をCronだけで表せない業務なら、Triggerを実行した後に日付・営業日条件を別ノードで確認します。Schedule Triggerは時刻を作る役割で、対象レコードの重複や休業日を自動で解決する業務ルールではありません。
Trigger Ruleを選ぶ
n8nには秒、分、時間、日、週、月、Custom CronのTrigger Intervalがあり、複数ruleも設定できます。日次なら画面のDays interval、平日指定が必要ならWeeks intervalで曜日を選ぶ方法を先に検討すると、後から式を読み解く負担が減ります。Custom Cronを使うのは、画面の選択肢で表せない場合です。たとえばn8n公式Docsの例では、毎日午前6時は 0 6 * * *、平日の午前9時は 0 9 * * 1-5 です。Cron式は環境や利用するCron表記の桁数に注意し、保存後の次回実行時刻表示を確認してください。
秒フィールドを含む6桁式では、先頭の桁が秒です。5桁の式と混ぜると意図と違う時刻に動く可能性があります。毎月30日に設定すると、その日がない月は実行されない例も公式Docsに示されています。月末処理なら「30日固定」ではなく、月初に前月分を処理するなど、欠落日がない運用へ設計し直す方が安全です。
保存・公開後の確認手順
-
Workflow Settingsでtimezoneを確認し、Schedule Triggerの頻度・曜日・時刻を設定します。
-
下流Actionを一時的な通知先または安全な保存先へつなぎ、実行時刻に処理したい期間が正しいか確認します。
-
直近の実行予定と、業務上の締め時刻が一致するか検討します。遅延や停止中の扱いを確認する場合は、n8nのversionとscheduler構成を併せて確認します。
-
Workflowを保存して公開します。Schedule Triggerを使うworkflowは公開が必要です。
-
次回のExecutionsを確認し、開始時刻、対象レコード、最終Action、失敗通知まで追います。
Schedule TriggerのCron変数を使う場合、公式Docsではその値はworkflow公開時に評価され、公開後に設定値を変えてもscheduleへ反映されないため、再評価にはunpublishして再publishする必要があるとされています。変数を使った時刻変更後に「保存したのに動かない」と感じたら、公開状態と評価タイミングを先に確認します。
停止中・欠落実行をどう扱うか
「n8nが停止した時間の実行を後から全部実行する」とは限りません。Schedule Triggerの現行Docsには、missed executionを破棄する既定の動作や、直近分を1回だけcatch-upする選択肢が記載されています。ただしこの設定はn8n 2.36以降で追加されたSchedule Trigger nodeが対象で、durable schedulerを実行している場合に限って有効です。既定のin-memory schedulerはmissed executionを実行しません。したがって設定項目が見当たらない環境で同じ動作を期待せず、利用中のversionとschedulerを管理者へ確認してください。
在庫同期や日次レポートのように実行漏れが許容されない場合、Triggerのcatch-up設定だけに頼らず、処理開始時に「最後に完了した対象日時」を読む方式を検討します。再起動後に前回完了時点から埋めるなら、処理済みの範囲を記録し、再実行で同じ請求・通知を作らない仕組みが必要です。反対に、古い集計を再送すると混乱する通知なら、missed runを捨てて最新の状態だけを送る方が適する場合もあります。
表は横にスクロールできます
| 目的 | 遅延分を処理する判断 |
|---|---|
| 履歴を欠かさないデータ同期 | 対象期間を保存し、再処理を重複排除できる場合にcatch-upを検討 |
| 毎朝の最新状況通知 | 古い通知をまとめて送らないよう、最新状態で一回だけ処理する |
| 決済・請求処理 | 既処理IDと冪等性を確認できるまで自動catch-upしない |
| 重要な締め処理 | 欠落を通知し、担当者が対象期間と件数を照合してから再実行 |
この選択は「正しいschedule」の一部です。時刻どおりに起動することだけでなく、停止・遅延後に何が起きるかまで決めてから公開してください。
更新確認日:2026-10-10
追加確認:n8n公式「Schedule Trigger」https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger(新しいタブで開く)
引用・データ出典
公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。
確認日:2026-09-28
n8n:Schedule Trigger node(新しいタブで開く)
