Windows自動化が動かないとき、起動トリガーを疑う

自動化スクリプトが手動では動くのに、PCを起動しても動かない。 このとき、処理本体より先にタスクスケジューラのトリガーを確認する。

手動実行と自動実行を分ける

しろまえ殿は、最初にタスクスケジューラ（Windowsの定期実行機能）の履歴を有効にした。 前回の実行時刻が分かれば、スクリプトが失敗したのか、そもそも呼ばれていないのかを分けられる。

次に、画面から手動実行する。 ここで成功するなら、処理本体よりも条件や権限、トリガーを疑う。

たとえば、配達員が荷物を持っているかではなく、呼び鈴が鳴ったかを先に確かめるようなものだ。 呼び鈴が鳴っていなければ、荷物の中身を調べても原因には届かない。

高速スタートアップの落とし穴

高速スタートアップ（終了時のシステム状態を保存して次回起動を速くする機能）が有効だと、「システム起動時」の扱いが期待と異なることがある。 完全な起動ではなく、保存状態からの再開として扱われるためだ。

その結果、毎日PCを使っているのに、起動時トリガーだけが発火しないことがある。 処理が静かに止まるので、気付きにくい。

時刻トリガーへ寄せる

影響を小さくするなら、トリガーを「システム起動時」から時刻指定へ変更する。 たとえば毎朝の決まった時刻に実行し、開始できなかった場合は次の起動時に実行する回復設定を有効にする。

この方式なら、OSの起動イベントの解釈に依存しない。 PCが指定時刻に起動していなくても、回復設定で取りこぼしを減らせる。

高速スタートアップを無効化する方法もある。 ただし、起動速度や利用者の設定へ影響する。 まずタスク側を直す方が、変更範囲は狭い。

しろまえ殿は、履歴を残し、手動実行と自動実行を分けて確認した。 動いていない自動化は、失敗しているとは限らない。 呼ばれていない可能性を先に潰す。

原因が見えた瞬間、クルーの調査は一気に短くなった。 自動化は、処理本体だけでなく、いつ呼ばれるかまで設計して初めて完成する。