n8nで定期実行するワークフローを作る方法

n8nで定期実行するワークフローは、Schedule Triggerを先頭に置き、「いつ動かすか」と「その時間に何をするか」を分けて設計するのが基本です。

AIものさし編集部

n8nで定期実行するワークフローは、Schedule Triggerを先頭に置き、「いつ動かすか」と「その時間に何をするか」を分けて設計するのが基本です。

現在のSchedule Triggerでは、秒・分・時間・日・週・月に加えてCustom Cronを設定できます。複数のTrigger Ruleを1つのノードへ持たせることもできます。

先に結論:Schedule Triggerより前に運用条件を決める

表は横にスクロールできます

決めること例確認ポイント
頻度毎朝 / 毎週 / 30分ごと必要以上に細かくしない
Timezone日本時間Workflow / instance設定
実行内容集計→通知などScheduleと業務処理を分離
本番化PublishEditorで作っただけでは継続実行されない
取りこぼし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のauthorityworkflow 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日固定」ではなく、月初に前月分を処理するなど、欠落日がない運用へ設計し直す方が安全です。

保存・公開後の確認手順

  1. Workflow Settingsでtimezoneを確認し、Schedule Triggerの頻度・曜日・時刻を設定します。

  2. 下流Actionを一時的な通知先または安全な保存先へつなぎ、実行時刻に処理したい期間が正しいか確認します。

  3. 直近の実行予定と、業務上の締め時刻が一致するか検討します。遅延や停止中の扱いを確認する場合は、n8nのversionとscheduler構成を併せて確認します。

  4. Workflowを保存して公開します。Schedule Triggerを使うworkflowは公開が必要です。

  5. 次回の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(新しいタブで開く)

n8n:Schedule Trigger common issues(新しいタブで開く)

n8n:Build your first workflow(新しいタブで開く)