毎朝9時の自動処理がずれる：タイムゾーンと対象日の決め方

終了を「23:59:59まで」とすると細かい時刻精度で境界を取りこぼすことがあります。開始以上・次の開始未満の区間を使う例なら、連続する日付の二重集計も確認しやすくなります。

UTCの同じ時刻に毎日動かす仕事と、現地の午前9時に動かす仕事では、夏時間がある地域で結果が異なります。地域名を指定しただけで、時計が戻る日の二回実行や進む日の欠落が安全になるとは限りません。使うスケジューラの挙動を試験してください。

自分のPCの表示が日本時間でも、実行環境やワークフローの設定まで同じとは限りません。n8n Schedule Triggerではワークフローのタイムゾーンが優先され、未指定ならインスタンス設定が使われます。既定値に頼らず、画面の設定と実行ログのUTC時刻を両方保存します。

• 一回の遅延で済むのか、各対象日を一度ずつ処理する必要があるのか。
• 期限を過ぎた通知は送るのか、集計だけ保存して通知を省くのか。
• 停止中に三日分たまった場合、順序と同時実行数をどう制限するのか。
• 再開したジョブの対象日は現在時刻から再計算せず、記録した予定対象日を使えるか。

タイムゾーン、予定時刻、実開始時刻、対象期間、同一期間の処理キーを記録します。予定時刻どおりに始まったことと、期限までに成果が完成したことも別々に判定します。

合成入力を日付境界の直前と直後に置き、どちらの日に一度だけ入るか確認します。さらに月末、PC停止後の再開、対象地域の夏時間切替を試します。サービスごとの遅延・再実行仕様は異なるため、この表は設定手順の代わりにはなりません。VPSの契約前に、予定と対象期間を固定できるかを確認するための判断表です。

本文の受入条件を決めた仕事をClaude Codeで進める場合、次は入力に届く場所とPCの稼働時間から実行場所を選べます。

診断はClaude Codeの実行場所を選ぶためのものです。容量計算やn8n・Codexの設定は扱いません。VPS結果には広告 / PRがあり、不要なら契約しません。