Windowsタスクスケジューラで自動化を回すときの実務メモ

戻り値をエラーコードだと思い込んで時間を無駄にした

タスクスケジューラの「前回の実行結果」に見慣れない数字が出ると、まずエラーコードを検索したくなります。ですが、そこに出る値はエラーとは限りません。

267009 は「まだ実行中」

戻り値 267009 は SCHED_S_TASK_RUNNING です。つまりタスクがまだ走っている最中という状態表示で、エラーではありません。実行結果の欄を見た瞬間の状態がそのまま表示されているだけなので、長めに動く処理では普通に見えます。

ここを異常だと判断して手動でタスクを止めたり、設定を変えたりすると、原因のない箇所をいじることになります。私はここで一度、無駄に設定を見直しました。

267014 は「上限に達して強制終了された」

一方、戻り値 267014 は SCHED_S_TASK_TERMINATED です。これは実行時間の上限に達して、タスクが強制的に終了させられた状態を示します。

これは注意すべき値です。処理が途中で切られているので、やりたかった処理が完了していない可能性があります。267009と267014は数字が近く、どちらも「S_」で始まるので見分けがつきにくいのですが、意味はまったく違います。

PowerShellでタスクを触るときはTaskPathが必要

GUIではなくPowerShellからタスクを変更しようとしたとき、Set-ScheduledTask でタスクが見つからないという状況になりました。原因はタスクの置き場所（TaskPath）を指定していなかったことです。

Set-ScheduledTask は TaskPath を指定しないとタスクを見つけられません。タスク名だけ合っていても、置き場所が違えば対象にたどり着けないということです。フォルダを分けてタスクを整理している場合は特に、名前だけで呼び出せると思い込まないほうがよいです。

いちばん危なかったのは「戻り値0」でした

ここが本題です。267014のような分かりやすい異常値よりも、戻り値0のほうが危険でした。

0は「異常なく終わった」でしかない

実行結果が0でも、処理件数が0件のことがあります。スクリプトがエラーを出さずに最後まで到達すれば0になるので、「何もしなかった」も「ちゃんと処理した」も同じ0として並んでしまいます。

私は実際にこれで失敗しました。戻り値0のまま、3日連続で処理件数が0件でした。スケジューラの画面上は毎回きれいに0が並んでいたので、動いていると思い込んでいました。

気づけなかった理由はログでした

気づけなかった直接の原因は、ログに処理件数を数字で書いていなかったことです。「開始しました」「終了しました」があっても、何件処理したのかが数字で残っていなければ、0件と正常稼働を区別できません。

この経験から変えたこと

1. ログに処理件数を数字で出すようにしました。0件なら0とログに残るようにします。
2. 戻り値の確認だけで判断せず、件数の数字を見るようにしました。
3. 267009と267014を区別して見るようにしました。267014が出たら、処理が途中で切れた前提で中身を確認します。

まだ分かっていないこと

正直に書いておくと、3日連続で0件になった根本原因までは、この時点では特定できていません。分かったのは「戻り値0では0件に気づけない」という監視側の欠陥のほうです。

また、267014が出る条件について、私が確認できているのは「実行時間の上限に達して強制終了された状態を示す」という意味だけです。どういう処理でどのくらい時間がかかると上限に当たるのかは、環境ごとに実測しないと言えません。ここを一般論で埋めても役に立たないので、書きません。

戻り値の読み方の整理

戻り値	名前	意味
267009	SCHED_S_TASK_RUNNING	まだ実行中。エラーではない
267014	SCHED_S_TASK_TERMINATED	実行時間の上限に達して強制終了された
0	—	異常終了はしていない。ただし処理0件でも0になる

• 267009を異常と誤解しなくなった
• 267014を「途中で切れた」として扱えるようになった
• 処理件数を数字でログに残すようにした

• 3日連続0件になった根本原因の特定
• 267014が出るまでの具体的な時間の見積もり