n8nのSchedule Triggerで定期実行を設定する

次に確認したいこと：自動化する工程と人が確認する範囲。ブログ制作全体へ組み込む場合は、開始時刻を決める前に、どの段階で人が内容を確認するかも整理できます。

時刻指定と一定間隔のどちらかを選ぶ

最初に「いつ始めたいか」を一文で決めてください。「毎日、日本時間の09:00」と「公開した時点から5分おき」では、基準となる時計が違います。

一つのSchedule Triggerに複数のTrigger Rulesを置くことも可能です。ただし初回は一つに絞り、どのルールで始まったかを説明できる状態から進めてください。

秒・分間隔はschedulerの版と起点を見る

n8n 2.45.0以降の既定のdurable schedulerでは、SecondsとMinutesは公開時を起点とする一定間隔です。たとえば09:02:07に公開して5分間隔を指定した場合、設計上の次の基準は09:07:07となり、毎時00/05分の境界と同じではありません。

時計の5分境界へそろえるなら、Cronの「*/5 * * * *」を選びます。この違いを見ずに「5分おきなのに分がずれている」と判断すると、正常な間隔動作を不具合と取り違えるでしょう。

newは公開からの等間隔、legacyとin-memoryは時計境界に基づく方式です。Custom (Cron)は、このnew/legacy切り替えによる秒・分間隔の差とは分けて扱います。

方式をまだ確認できない場合は、主例の毎日09:00をDaysか明示的なCronで設定し、次の予定と実開始を照合してください。環境設定を推測して直すより、目的の時刻を先に固定するほうが比較しやすくなります。

次に確認したいこと：WordPressの投稿予約と自動化する範囲。n8nの開始予定と、投稿の予約日時を分けて設計したいときに、手動予約・外部下書き保存・人の確認の役割を整理するための案内です。

ワークフローのタイムゾーンとCronをそろえる

日本時間の09:00を狙うなら、ワークフロー側でTimezoneをAsia/Tokyoに指定します。パソコンの時計や画面上の時刻だけを合わせても、Schedule Triggerの開始基準が同じとは限りません。

1. ワークフローのSettingsを開く

   試験用ワークフローを開き、右上のWorkflow menuからSettingsへ進んでください。公開・編集できる権限と、外部送信のない試験用であることを先に確認します。

2. TimezoneをAsia/Tokyoにする

   TimezoneでAsia/Tokyoを選び、設定を保存してください。ワークフローのタイムゾーンが指定されていれば、インスタンスの既定値より優先されます。

3. Schedule Triggerに一つのルールを置く

   Daysを選ぶ例なら、Days Between Triggersが1、Trigger at Hourが09、Trigger at Minuteが00という組み合わせです。複数ルールを追加せず、まず毎日09:00の一つだけで確かめてください。

セルフホストのGENERIC_TIMEZONEはn8nの既定タイムゾーンに関係し、OSのTZと同じ設定項目ではありません。Cloudの検出した既定値へ任せず、この作例ではワークフローのAsia/Tokyoを明示します。

Cronを使う場合は、Custom (Cron)のExpressionへ「0 9 * * *」を入れると毎日09:00です。秒欄を含む6欄なら「0 0 9 * * *」となるため、先頭の数字が何の単位かを確認してください。

秒欄と暦の条件を取り違えない

5欄では左から分・時・日・月・曜日、6欄ではその前に秒欄を置きます。星の数を一つ増やすだけで同じ頻度になるわけではありません。

先頭が分か秒かで、15分が15秒に変わります。これは欄の違いを知るための比較なので、実際の試験は主例の毎日09:00から始めてください。

毎月31日を指定しても、31日がない月にはその日付の実行はありません。「毎月31日」と「毎月末」は別の条件です。

同じように、月の日の欄へ*/Nを置くことを、月をまたぐ厳密なN日周期と説明するのも避けてください。日付の条件と経過時間の周期を区別するのが基本です。

海外のタイムゾーンで夏時間がある場合は、同じ現地時刻でもUTCとの差が季節で変わります。存在しない時刻や重なる時刻の境界は、利用している版の予定と実行を確認し、常に必ず1回という保証を置かないでください。

Invalid cron expressionが出た場合は、まず欄数と数字の範囲を見直します。式が受理されても、目的のタイムゾーンで次の日時が合っているかを確かめてください。

保存した設定を公開版へ反映する

Schedule Triggerの自動開始には、設定が本番で使う公開版へ反映されていることが必要です。下書きの保存やExecuteだけで、その予定が登録されたと判断しないでください。

現行のn8nでは編集内容を自動保存し、本番実行は公開された版を使います。画面で新しいルールが見えていても、公開版が古ければ、そのまま新しい時刻で動くとは限りません。

公開操作を行った後は、処理の完了状態を確認してください。現行仕様では公開は非同期で、Publishingの間は登録の結果を待っている状態です。

Published, partialでは新しい版が公開されても、一部のトリガーが有効化に失敗しています。動き始めたトリガーもあるため、「全て動いた」「全て止まっている」のどちらにも決めつけないでください。

Failed to publishは、トリガーが一つも有効化できず、ワークフローが動いていない状態を示します。公開版の指定は残るため、失敗した登録先を調べ、外部への副作用を止めた試験用で再公開と確認を行ってください。

ルール・変数・タイムゾーン変更後の有効版を確認する

Cronに使う変数の値は、公開時に評価されます。公開後に変数だけを変えても、登録済みのCronが同じように変わるとは限りません。

Schedule Triggerのcommon issuesは、変数や間隔の変更を反映するため、公開解除後の再公開を案内しています。一方、現行のSave and publish資料で、ワークフロー設定だけの変更を自動で再公開するとされる点は、別の条件です。

そのため、全変更で必ず手動再公開が必要とも、保存すれば全て即反映とも判断しないでください。変更したのがルール・変数・ワークフロー設定のどれかを記録し、公開状態と版、次の予定を確かめます。

旧版でActiveやActivateという表示を使う環境では、その版に対応する有効化操作と状態を確認します。この記事のPublishという画面名を、全ての版に同じ表示があるという意味で読まないでください。

手動試験と次の予定時刻の試験を分ける

手動試験は後段の処理を確かめ、自動試験は公開した予定から開始するかを確かめます。定刻開始を確認したいのに、Executeを押して終えると、この二つが混ざってしまうでしょう。

確認したn8n 2.45.5のSchedule Trigger実装では、手動実行時は最初のルールを確認して即時にデータを出します。09:00の予定時刻まで待って動いたという試験ではありません。

また、手動のpinデータはproductionでは無視されます。手動で固定した値が出ても、本番の入力や処理が同じだという証拠にはなりません。

1. 安全な後段を手動で1回確かめる

   入力と出力を照合し、処理内容そのものが意図どおりかを確認してください。この成功は後段の確認として記録し、定期開始の成功とは分けます。

2. 公開した版と期待する2回を書き出す

   ワークフロー名またはID、公開版、ルール、Asia/Tokyo、期待する日時が記録する項目です。次の予定がいつかを曖昧にせず、日付とUTCとの差までそろえてください。

3. 予定時刻のproduction実行を照合する

   公開処理が完了した後に、次の2回の予定と実行ID、mode、開始時刻を比べます。開始後のエラーや後段の結果も別に確認し、止める必要があれば新規開始を停止してください。

実行履歴の時刻・ID・mode・結果を照合する

Asia/Tokyoの09:00は、UTCでは同日の00:00です。たとえば次の表は、11月1日より前に公開を完了したと仮定した、毎日09:00の説明用期待表になります。

実際の照合では、期待日時、実開始時刻、実行ID、manual/productionのmode、終了結果を別欄にしてください。ノード出力のtimestampが予定時刻なのか、実際にデータを出した時刻なのかも、使う版のキーと意味を確かめます。

確認した2.45.5の実装の出力timestampは、その場の時刻から作る値です。予定時刻と同一の記録だと決めつけず、遅延の確認には期待値と実開始の記録を使ってください。

Executions一覧に見つからない場合は、成功・失敗・手動の履歴保存設定や閲覧権限も確認します。一覧にないことだけでは、絶対に実行されなかったとは断定できません。

確認を終える前のチェック

• 意図したタイムゾーンとルールが公開版に反映された
• 少なくとも次の2回を期待日時・実開始・ID・modeで照合した
• 開始後のエラーと、安全な後段の結果を確認した
• 履歴保存と権限による見落としを確認した
• 不具合時の新規開始停止と戻し方を用意した

後段の条件判定で止まるなら、「n8nのIF・Switch・Filterの違いと条件分岐の作り方」で、条件と未一致の経路を見直せます。認証の失敗が分かった場合は、「n8nの認証情報を設定・管理する方法とOAuth2」が、接続資格情報と共有範囲を分けて確認するための読み先です。

停止中の回をどう扱うか決める

インスタンスが止まっていた間の予定が、再開時に全て実行されるとは限りません。まず、durable schedulerで保持された有効な予定の遅延と、公開解除・削除で予定自体を止めた状態を分けて考えてください。

durableでは、grace period内の遅れは遅延して開始し得ます。その猶予を超えてmissedと扱われる予定は、別のmissed policyによって補完するかが変わる仕組みです。

Schedule TriggerノードのSettingsで、If Execution Is MissedとMissed Execution Grace Period (Seconds)を確認してください。graceの0は猶予をなくす指定ではなく、インスタンスの設定を使うという意味です。下限未満の指定はインスタンス由来の最小値へ引き上げられ、上限は30日に制限されます。短い猶予を入れたつもりでも、入力値だけで実際の猶予を判断しないでください。

Schedule TriggerのIf Execution Is Missedには、次の選択肢があります。いずれも、滞留した予定を一つずつ全件再生する機能ではありません。

ルールごとの補完では、複数ルールがあれば各ルールの最新が対象になります。だからこそ、最初は一つのルールで、補完に渡る対象期間を説明できる状態にしておきましょう。

これらの設定は、対応する本体とSchedule Triggerノード版、durable方式がそろって初めて有効です。確認した2.45.5ではノード1〜1.4が併存し、missed設定は1.4以降に表示する実装なので、本体更新だけで既存ノードも1.4になったとは判断しないでください。

in-memory schedulerは取り逃した予定を補完しません。また、既定のskipでもgrace内の遅延開始は起こり得るため、「既定では遅れた実行は全部拒否される」という意味ではない点に注意が必要です。

再開前に、補完が必要な対象期間、実行済みの対象、処理を許容する期限を確認してください。取り逃した分を手動で補うなら、すでに処理済みの対象をもう一度書き込まないかも照合します。

重なった実行と外部への二重書き込みを分けて守る

開始予定が一つでも、外部への書き込みが必ず一度だけになる保証とは別です。同じ時刻の複数ルール、複製したワークフロー、長時間実行の重なり、障害後の再試行や手動再実行を確認してください。

公式実装には予定時刻を使う重複判定キーがありますが、それを全ての外部API・通知・保存処理の一度だけの実行保証へ広げることはできません。schedulerの開始管理、同時実行制限、業務データの重複照合はそれぞれ別の役割です。

たとえば保存先の照合キーを「対象日＋処理対象ID」にする案なら、何日の何を処理済みかを区別できます。これはキー設計の説明例で、台帳を置くだけで書き込みと記録が必ず一体になるという保証ではありません。

処理を何件ずつ繰り返すかが課題なら、「n8nのLoop Over Itemsで分割して処理する方法」でバッチ数・戻り先・終了条件を確認してください。次に確認したいこと：処理途中で待つWaitの設計では、開始予定とは別に、実行途中の待機をどこへ置くかを整理できます。

止め方・戻し方・実行量を用意する

不具合があるときは、新しい定期開始を止めることと、実行中の処理・済んだ外部更新を確かめることを分けるのが基本です。公開解除だけで、すでに送った通知や保存結果まで取り消されるわけではありません。

1. 新しい定期開始を止める

   対象ワークフローを公開解除し、新しい開始予定が止まる状態を確認してください。実行中のIDを控え、ほかの同等ワークフローも動いていないかを確かめます。

2. 実行中と保存先の結果を確認する

   動作中の処理に停止が必要なら、その実行を別に扱ってください。すでに更新された対象や外部への送信結果を読み戻し、重複や途中状態の有無を調べます。

3. 既知の版と予定へ戻す

   安全に動くと分かっている版と設定を選び、対象の予定・timezone・missed方針を確かめてください。履歴版の復元だけで本番は切り替わらないため、必要な公開操作と完了確認を行います。

4. 低い頻度で再開して照合する

   公開版、次の予定、補完される対象を記録し、実開始と結果を再確認してください。再試行や手動補完にも、処理済みキーの照合が必要です。

頻度を上げると、実行回数や接続先APIへの要求も増えます。正確な料金や実行枠は契約で確認し、試験のためだけに秒間隔の本番処理へ変える必要はありません。

次に確認したいこと：n8nの費用と実行回数の見積もり。定期実行の頻度を運用予算と合わせたい場合に、実行量と費用を別の判断として整理するための案内です。

次に確認したいこと：n8n CloudとVPSの運用基盤の選び方。停止・復旧や保守を誰が受け持つかまで決めたい場合に、設置方式と担当範囲を比較できます。

n8nが開始しているのにWordPressの予約記事だけ出ない場合は、「WordPressの予約投稿が公開されないときの確認順」で、投稿状態・サイト時刻・WP-Cron側の失敗を調べてください。開始条件が成功したことを、その先の予約公開成功と同じにしません。

まとめ｜時刻・公開版・実行記録をそろえて定期実行を確かめる

Schedule Triggerは、目的に合う間隔かCronを選び、ワークフローのタイムゾーンと公開版をそろえて使います。手動成功と予定時刻の自動開始、grace内の遅延と取り逃した回の補完は、別々に確認する項目です。

まずは外部送信のない一つのルールで、Asia/Tokyoの毎日09:00など、期待する次の2回を書いてください。公開処理の完了を確認し、実開始・実行ID・modeと後段結果まで照合しましょう。

時刻の表示だけでなく、どの公開版がどの記録で動いたかをそろえると、設定違いと遅延を追いやすくなります。最初の一回を急いで本番につなぐより、止め方と処理済みの確認まで準備することが、定期運用を続けるうえで大切です。