クラウドのスケジューラを使わず、ローカルPCのWindowsタスクスケジューラで個人の自動化基盤を運用している。追加コストゼロで手軽に始められるのが魅力だが、いくつか地味にはまりやすい落とし穴がある。本業でクラウド上のジョブスケジューリング設計に関わる機会もあるので、その経験から整理しておく。
落とし穴1：スリープ設定との干渉
毎日決まった時刻に実行するタスクを設定しても、PCがスリープ状態だとタスクが起動しない・遅延するケースがある。
対策は2通り：
- コントロールパネル → 電源オプション → スリープ状態にする → なし に設定
- タスクの「条件」タブ → 「スリープを解除してタスクを実行する」 にチェック
ノートPCの場合は、電源プランで「電源接続時のみスリープを無効化・バッテリー駆動時は通常通り」と使い分けると、バッテリーと安定性を両立できる。
落とし穴2：実行環境がログイン時と違う
タスクスケジューラ経由（特に「ユーザーがログオンしているかどうかに関わらず実行する」設定時）では、PATH環境変数や作業ディレクトリがログイン時と異なる。「手動実行は成功するのに、自動実行では失敗する」の大半はここが原因。
よくある症状と対策：
:: BAD: 環境変数に依存した相対パス指定
node my-script.mjs
:: GOOD: フルパス + カレントディレクトリを明示
C:\Program Files\nodejs\node.exe C:\projects\my-script.mjs
「開始（オプション）」欄には必ず作業ディレクトリを絶対パスで指定する。指定しないとカレントディレクトリが C:\Windows\System32 になり、相対パスが全部ずれる。
:: run-task.bat
cd /d C:\projects\my-project
npx node my-script.mjs >> logs\output.log 2>&1
batファイルの中でコマンドを書く形にするのが一番シンプル。タスクスケジューラには「batファイルのパスだけ」渡す設計にすると、環境変数の問題を回避しやすい。
CLAUDE.mdより（実際のプロジェクトで踏んだ落とし穴）：
wsl.exe -d Ubuntu -- bash -lc "..."のように、Windowsタスクスケジューラの引数欄に直接$変数展開を含むコマンドを書くと、変数が常に空文字列になる。ループ処理が必要な場合は.shファイルに書いてそのファイルを呼び出す形にすること。
落とし穴3：止まっても誰も気づかない
タスクスケジューラは「失敗しても通知しない」がデフォルト。静かに失敗し続ける。
最低限の監視として：
-
ログファイルに出力を必ず書く（
>> logs\output.log 2>&1） - タスクマネージャー → タスクスケジューラライブラリ → 対象タスク → 「履歴」タブで直近の実行結果を確認する習慣を持つ
- 失敗時のプッシュ通知が必要なら ntfy.sh が無料・登録不要で使いやすい
// node.js から ntfy に通知する例
await fetch('https://ntfy.sh/your-topic', {
method: 'POST',
body: 'タスク失敗: ' + new Date().toISOString()
});
どこまでタスクスケジューラで粘るか
個人的に使っている判断基準：
| 条件 | ローカルで粘る | クラウドに移す |
|---|---|---|
| PCの電源を落とす予定 | なし | あり（旅行・出張など） |
| 処理時間 | 数秒〜数分 | 数十分以上 |
| 止まった場合の影響 | 自分だけ | 外部の読者・ユーザーに影響 |
この3点を判断軸にすれば、「費用対効果が高い範囲でローカルPCを使い倒す」と「本当にクラウドが必要な箇所だけ移す」の使い分けがしやすくなる。
まとめ
Windowsタスクスケジューラは「無料で手軽」という利点の裏に、スリープ・実行環境・監視という3つの落とし穴がある。逆にこの3点を押さえておけば、個人の自動化基盤として十分に実用的。クラウドサービスに移行するタイミングの判断基準も合わせて持っておくと、無駄なコストをかけずに済む。
個人の自動化スクリプト設計について、noteにもう少し踏み込んだ内容を書いています:
Claude Codeで自動化スクリプトを書く時の向き不向き
技術的な相談（Copilot・AIエージェント構築、60分のビデオチャット）も受け付けています。ご相談の際は「Qiitaを見た」とお書きください：https://coconala.com/services/4209036