要点
- 同じノートPCの定期実行で、動かずログも残らない状態と、動いても接続できない状態が発生した（出典: 自社の実測・2026-09-23）
- 接続失敗と拒否を示す記録を分け、復旧後の送信結果と合わせて原因を確認した（出典: 自社の実測・2026-09-23）
- 復帰時の接続確認と、最後に成功した時刻を外から確認できる記録を追加した（出典: 自社の実測・2026-09-23）
定期実行で続けたかったのは、配信内容の更新
ノートPC上で自動処理を定期的に動かし、配信する内容を更新する。その運用で確認したかったのは、予定した処理が動いているか、そして配信内容が古いままになっていないかという点だった。
今回、同じノートPCで使っていたのは、スリープ中に実行予定を過ぎた場合の扱いが異なる、ふたつの仕組みだ。片方は実行できなかった回を取り戻さない方式、もう片方は復帰時に取り戻す方式だった。
取り戻す方式とは、PCが寝ている間に実行されるはずだった回を、復帰した直後にまとめて1回実行する方式のことだ。
「mac スリープ cron」「mac cron 動かない」という言葉で調べる際にも、今回の記録で着目したいのは、この未実行分の扱いと、実行時に接続できたかという違いである。記録では、同じPC上の定期実行でも、処理が始まらない問題と、始まっても送信できない問題が分かれて現れた。
オフライン期間には、正反対の結果が残っていた
調べたのは、2026-09-14〜09-23の9日間、PCがネットにつながらない状態が続いた期間の記録だ。取り戻さない方式では一度も動かず、ログにも記録が残っていなかった。一方、取り戻す方式では毎日動いていたものの、本来の予定より数時間〜十数時間ずれた時刻に実行されていた。
以下は、記録にある結果と実害をそのまま写した表だ。
| 確認項目 | 取り戻さない方式 | 取り戻す方式 |
|---|---|---|
| 結果 | オフライン中は一度も動かない。ログに記録すら残らない | オフライン中も毎日動いた。ただし予定に無い時刻（本来の予定より数時間〜十数時間ずれた時刻）に動いていた |
| 実害 | 配信していた内容が9.6日間、古いまま止まっていた | 毎回ほぼ失敗。送信先への接続がすべて失敗していた |
出典: 自社の実測（2026-09-23）
取り戻さない方式では、スリープ中に実行されるはずだった回が捨てられていた。復帰しても取り戻さないため、実行されなかった回はログにも現れない。実際に配信内容は古いまま止まっていたが、その停止を失敗ログだけで捉えることはできなかった。
取り戻す方式には実行記録があった。しかし、その記録が示していたのは、更新の成功ではなく送信先への接続失敗だった。「毎日動いた」という確認だけでは、配信できていたかどうかまでは判断できない。この違いが、今回の調査の出発点になった。
接続できなかったのか、送信先に拒否されたのかを分ける
取り戻す方式の原因を調べる際には、失敗という結果をひとまとめにせず、エラーの種類を確認した。同じ実行の中に送信先が複数あり、そのすべてが同じ種類の接続失敗で落ちていたためだ。
今回の記録では、送信先側が意図的に拒否した場合には、接続失敗とは別の種類のエラー文字列が返ることを切り分けの基準にした。該当期間の全ログを確認すると、「拒否された」を示す記録は0件で、「接続できなかった」を示す記録だけが数百件あった。
さらに、復旧後に同じ送信先へ試しに送ると、正常に受理された。複数の送信先が同じ接続失敗になっていたことと、復旧後には同じ送信先が受理したことを合わせ、送信先側の問題ではなく、こちら側のネットワーク復帰の遅れが原因だと確認した。
実行時刻のずれも、この原因とつながっていた。取り戻す方式は復帰直後に動くが、その時点ではまだネットワーク接続が上がっていなかった。予定にない時刻に動いていた処理は、寝起きに実行され、外へ接続できないまま失敗していたのである。
ここで確認したのは、「送信に失敗した」という結果だけではない。いつ動き、どの種類のエラーが残り、復旧後に同じ送信先がどう応答したかまでを照合した。
出典: 自社の実測（2026-09-23）
接続確認と、最後の成功を確認する記録を追加した
修正は、原因を区別して記録することから始めた。失敗の理由を「接続できない」と「拒否された」に分け、後から同じ失敗として混ぜて扱わないようにした。今回の切り分けで使った区別を、以後の記録にも残すためだ。
次に、寝起きの実行へネットワーク接続の確認を追加した。接続が確認できるまで待ち、確認できなければ何もせず終了するようにした。復帰したという事実だけで送信を始めず、外へ接続できるかを処理の前に確認する形へ変えた。
そして、「最後に成功した時刻」を外部から確認できる場所に記録した。一定時間更新がなければ、気づけるようにするための修正だ。
この記録は、実行ログとは確認する対象が異なる。取り戻さない方式では、動かなかった回のログ自体が残らなかった。取り戻す方式では、動いた記録があっても送信は失敗していた。そこで、実行の有無に加えて、成功がいつから更新されていないかを確認できるようにした。
今回の記録で示されている修正は、この失敗理由の分類、接続確認、最後の成功時刻の記録である。修正後の成功率や、どの程度停止時間が減ったかという数値までは示されていない。
業務に置き換えると
ノートPC上の定期実行では、PCが寝ることを前提に、「動かなかった」と「動いたが外に出られなかった」の両方を点検対象にする。今回の記録を自分の業務に置き換えるなら、確認項目は次のようになる。
- スリープ中の実行予定をどう扱うか。 実行できなかった回を捨てるのか、復帰時に取り戻すのかを確認する。取り戻さない場合には、実行されなかった回がログにも残らない点を含めて点検する。
- 復帰直後に接続を確認しているか。 寝起きに処理が動く場合、送信を始める前にネットワーク接続を確かめ、確認できないときの終了方法まで確認する。
- 失敗の種類を区別しているか。 接続できなかった記録と、送信先に拒否された記録を分ける。失敗件数だけでなく、原因を切り分けられる記録になっているかを見る。
- 最後に成功した時刻を外から確認できるか。 動かなかった場合にも、動いたまま失敗し続けた場合にも、成功時刻の更新が止まったことに気づける仕組みがあるかを確認する。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。