毎朝9時に記事を1本公開するタスクが、ある月に4日分だけ抜け落ちた。スクリプトは正しく、エラーも出ていない。そもそも起動していなかった。原因はPCがスリープしていたことと、電池駆動のときは動かない設定だったこと。個人のPCで自動化を回すときに点検すべき「実行の前提条件」をまとめる。
スケジューラが「動かなかった日」を生む2つの設定と、コードを疑う前に確認する切り分けの順番。自分の自動化を点検する5つの問い。
私の運用では、Windowsのタスクスケジューラが毎朝9時に予約投稿のスクリプトを呼び出している。ある月、公開されるはずの日に記事が出ていない日が4日あった。
調べてみると、スクリプトの中身に問題は無かった。ログにはエラーも残っていない。残っていないのは当然で、その日はスクリプトが一度も起動していなかったからだ。失敗ログが無い失敗は、気づくのがいちばん遅れる。
日付ごとにPCの状態を突き合わせると、4日のうち3日は9時にPCがスリープ中、残る1日はノートPCが電池駆動だったと推定できた。そしてタスクの設定は次の2つになっていた。
この設定が無効だと、予定時刻にPCが起動していなかった場合、あとで起動しても取り戻さず、その回を飛ばす。9時にスリープしていた日は、起きた時点で実行されるべきだったのに、そのまま欠落した。
「AC電源のときだけ実行する」が既定になっていることがある。充電器を外して使っていた日は、条件を満たさず静かに見送られる。画面には何も出ない。
ポイント。スクリプトのバグではなく、実行環境の条件で止まっていた。コードをいくら読み返しても原因には辿り着けない。
自動化が動かなかったとき、つい直近に触ったコードを疑ってしまう。しかし、ログに何も無い欠落は、次の順番で見るほうが早い。
対処は、StartWhenAvailableを有効にして「逃した回は起動後すぐ実行」にすること、電池駆動でも実行を許可することの2つ。ところが私の環境では、タスク設定を変える操作が権限の都合でブロックされ、自動では直せなかった。やることリストに「ユーザーが手動で変更する」と残す形になった。
ここは正直に書いておきたい。自動化を任せている相手にも、できないことは「できなかった」と残してもらうのが大事だ。直ったことにして閉じるより、未解決の項目として見える状態で残すほうが、次に気づく人が動ける。
# 呼び出し側の .bat に、起動の事実だけ残す最小の例
echo %date% %time% start >> run.log
powershell -File publish_next.ps1 >> run.log 2>&1
echo %date% %time% end >> run.logこのログがあれば、「起動していない日」は開始行が無い日として一目で分かる。欠落の検知は自動化は黙って死ぬ——AI同士に見張らせる番犬設計の発想とつながる。
クラウドで動く処理と違い、手元のPCで回す自動化は、PCの電源状態を前提にしている。次の5つを一度確認しておくと、静かな欠落をかなり防げる。
本記事は筆者自身の運用記録に基づく。設定項目の名称や既定値はOSや環境によって異なる。