n8nで毎日決まった時刻に集計したいのに、予定した日本時間からずれて動くことがあります。Schedule Triggerの時刻だけを直す前に、ワークフローのタイムゾーンと公開状態を確認しましょう。手動で実行できることと、定時に自動実行されることは別です。
日本時間の設定、保存・公開、実行履歴の三つを順に照合します。この記事では、毎日二回の確認用集計を例に、設定から初回実行、予定の変更後までの確認を整理します。本記事の例は運用を説明するための案で、実測の成功事例ではありません。
タイムゾーンは表示する時計だけの設定ではない
n8n公式では、Schedule Triggerはワークフローに設定したタイムゾーンを使い、それがない場合はインスタンス側の設定を使うと説明されています。画面の時刻を日本時間だと思って入力するだけでは、意図した実行時刻になるとは限りません。
| 確認する場所 | 見る理由 |
|---|---|
| ワークフローのタイムゾーン | その予定で優先して使う時間の基準 |
| インスタンスのタイムゾーン | ワークフロー側で未設定の場合の基準 |
| 実行履歴の時刻 | 実際にいつ動いたかを照合する |
日本時間で毎日動かすなら、ワークフローの設定でAsia/Tokyoを確認する方針を考えます。現在の設定と予定時刻を記録し、ずれた結果を見て時刻の数値だけを足し引きしないようにします。後から基準を直したときに、さらにずれる原因になるかもしれません。
何を一回と数えるか決めておく
説明用に、毎日12時と19時に下書き件数を集計する作業を考えます。定時実行が二回なら、集計も一日二回の予定です。一方、集計の中で複数のデータを処理する場合、処理された件数と起動した回数は違います。
最初に、予定時刻、対象データ、処理する範囲、保存先を一枚のメモへまとめます。「毎日実行」だけでは、どの日付のデータを集計するかが曖昧です。前日分か、その時点の状態か、一定期間の差分かを分けてください。
同じデータを二回処理してよいかも決めます。確認用の記録なら実行時刻を付けて二つ保存する方針があります。外部へ登録する処理なら、対象日と識別子を使い、同じものを重ねない仕組みを別に考える必要があります。定時実行そのものが重複を防ぐ機能とは限りません。
最初は外部への送信を含めず試す
予定の確認をしたい段階では、いきなり顧客へのメール送信や公開操作をつなぐ必要はありません。時刻と対象を確認用の結果へ残す構成から試すと、予定設定の問題と後続処理の問題を分けやすくなります。
- ワークフローの設定で、使用するタイムゾーンを確認します。
- Schedule Triggerを追加し、必要な間隔を選びます。
- 毎日の予定なら、日単位のルールで時と分を指定します。
- 二回の予定が必要なら、それぞれの時刻を別ルールとして確認します。
- 後続の確認処理へ、実行時刻と対象を残す項目を用意します。
- 手動のテストで、対象データと結果の形式を確認します。
- 保存・公開し、予定時刻に動いた結果を実行履歴で確認します。
公式は、Schedule Triggerを使うワークフローを保存して公開する必要があると案内しています。以前の解説で有効化など別の表記が使われていても、現在の画面で実行する版がどれかを確認してください。保存した編集案と公開した版が異なる状態を見落とさないようにします。
日単位の予定と一定間隔を区別する
「毎日12時」と「24時間ごと」は、求める運用が同じとは限りません。決まった時刻に結果が必要なら、日単位で時刻を指定する方法を確認します。間隔を使う場合は、何を基準に動く予定なのかを利用版の説明で見ます。
また、二つのルールを追加したつもりでも、時刻が同じなら予定が重なっている可能性があります。12時と19時の例なら、両方の時と分を読み直し、不要な以前のルールが残っていないかを確認します。変更後は保存だけで済ませず、公開して実行する内容にも反映されたかを見ます。
実行履歴では開始と結果を分けて見る
| 履歴で見ること | 確認する意味 |
|---|---|
| 開始時刻 | 予定の基準時刻に起動したか |
| 起動の種類 | 手動テストと定時実行を混同していないか |
| 成功・失敗 | ワークフローの処理がどこまで進んだか |
| 出力した対象 | 予定した日付やデータを扱ったか |
| 保存先の結果 | 履歴の成功表示と実際の保存を照合できるか |
例えば予定時刻に起動していても、後続の認証エラーで集計が保存されていない場合があります。これは予定の設定だけを直しても解決しません。一方、手動で結果を保存できても定時実行の履歴がなければ、公開状態やトリガーを見直します。
時刻を比較する際は、履歴の表示がどのタイムゾーンかも確認します。UTCなど別の基準で表示されるデータを、日本時間と同じ数字で比べないようにします。判断に使った時間の基準を記録しておけば、担当者が変わっても照合できます。
動かないときの確認順
まず対象のワークフローが保存・公開されているかを確認します。次にSchedule Triggerのルール、ワークフローとインスタンスのタイムゾーンを見ます。予定時刻がすでに過ぎているなら、手動テストだけで過去の定時実行が成立したと扱わないようにします。
起動の履歴がある場合は、どのノードで止まったかを見ます。対象データが空だった、接続が切れた、登録先で重複が起きたなど、後続処理の問題を分けます。失敗を再実行する前に、途中まで書き込まれた結果がないかも確認してください。
予定変更と再実行で残す記録
実行時刻を変更したときは、旧時刻、新時刻、反映した版、次に確認する予定を残します。説明用なら「12時のみから12時・19時へ変更、公開版v03、次の19時で履歴と集計結果を照合」と書けます。これは実際の予約が完了した記録ではなく、管理例です。
失敗した実行をやり直す場合は、そのデータを通常の次回実行も扱うかを考えます。自動の予定と手動の再実行が同じ対象を登録すると、結果が二つになるかもしれません。対象の識別子、処理済み状態、記録先の結果を照合してから進めます。
自動化を広げる判断は確認後にする
定時に起動することを確認したら、必要な集計や通知を段階的に加えます。処理を増やすたびに、どの結果を確認して完了とするかを決めます。公開や送信を含む処理なら、宛先、内容、実行範囲を実際の運用に合わせて整えてください。
- 日本時間の基準が明確か。
- 保存・公開された版と予定ルールが一致するか。
- 手動テストではなく、定時実行の履歴を確認したか。
- 出力先の結果と重複の有無まで照合したか。
ツール選びはMakeとn8nの比較、サービスの契約前は申込み前の確認も参考にできます。時計の設定から、実際に残った結果までつながる状態を作りましょう。
確認日：2026年10月12日。参考：n8n公式Schedule Trigger。二回の集計例と確認表は当サイトの運用案です。環境とバージョンにより画面表示は異なります。
コメント