Windowsで動画の自動生成パイプラインを毎日動かしています。ある日、生成されるはずの動画が出ていないことに気づきました。ログを見ると、タスクは確かに起動している。でも成果物がない。

この「起動したのに完走していない」問題の原因特定に3週間かかりました。結論から書くと、犯人はスクリプトのバグでもメモリ不足でもなく、Task Schedulerに最初から入っている設定でした。同じ構成で運用している方は5分で確認できる話なので、先に確認方法から書きます。

■まず結論: ExecutionTimeLimitが「2時間」になっていないか確認する

Task Schedulerのタスクには「実行時間の上限」(ExecutionTimeLimit)という設定があり、これを超えるとタスクは強制終了されます。PowerShellでの確認は1行です。

(Get-ScheduledTask -TaskName "タスク名").Settings.ExecutionTimeLimit

ここが「PT2H」(2時間)になっていて、ジョブの実行時間が2時間を超えると、途中で殺されます。エラーダイアログも出ません。イベントログに残るのは Result 267014 という数字だけです。

267014 = 0x41306 = 「タスクは、ユーザーによる終了要求または実行時間の超過により停止されました」。この数字を知らないと、ログを見ても「なんかの終了コード」で流してしまいます。私は流しました。

■裏取り: イベントログにはすべて残っている

「本当に時間切れで殺されたのか」はイベントログで裏が取れます。イベントビューアーの「アプリケーションとサービスログ > Microsoft > Windows > TaskScheduler > Operational」に、タスクの開始・終了・強制終了の記録が並んでいます。PowerShellで読むなら次の1行です。

Get-WinEvent -LogName Microsoft-Windows-TaskScheduler/Operational -MaxEvents 50

私のケースでは、開始イベントのちょうど2時間後に「タスクの終了」イベントが毎回並んでいました。「毎回、開始からきっかり同じ時間で死んでいる」— この規則性が見えた瞬間に、原因がリソースや処理内容ではなく「時間で切る何か」だと確定します。不定期に落ちるならリソースや入力データを疑い、定刻で落ちるならタイマーを疑う。切り分けの基本ですが、渦中にいると意外と気づけません。

なお、このOperationalログは環境によっては既定で無効です。無効だった場合はイベントビューアーで該当ログを右クリック→「ログの有効化」をしてから、次の実行を待つ必要があります。

■ついでに覚えておきたい: Resultコードの早見表

Task Schedulerの「前回の実行結果」に出る数字は、知っていれば一目で状況が分かります。よく遭遇するものだけ並べます。

・0x0 — 正常終了

・0x1 — スクリプトが終了コード1を返した(スクリプト内部のエラー)

・0x41301 — 現在実行中

・0x41303 — まだ一度も実行されていない

・0x41306 — 終了要求または実行時間超過で停止(今回の犯人)

・0x8004131F — 同じタスクのインスタンスが既に実行中のため、新規起動がスキップされた

特に 0x41306 と 0x8004131F は「エラーらしいエラーを出さず、成果物だけが無い」という形になりやすい2大巨頭です。どちらも「タスク自体は正常に管理された」という扱いなので、通知も出ません。

■なぜ3週間気づけなかったのか: 「起動したか」だけを監視していた

言い訳をすると、監視はしていたんです。ただし「タスクが定刻に起動したか」だけを。

起動は毎回成功しています。TTS生成も画像生成も途中までは動く。ログも途中までは正常に流れる。そして2時間ちょうどで、ログが「ぷつっ」と途切れる。エラーメッセージはありません。強制終了なので、スクリプト側のtry/catchも最後のログ出力も走らないまま消えます。

失敗の形が「エラーが出る」ではなく「静かに途切れる」だと、既存の監視はぜんぶ素通りします。

■効いた対策: 「ログの最終行が終端マーカーか」を毎日見る

原因特定のきっかけは、監視の観点を変えたことでした。パイプラインの最後に必ず出る行(成功なら「DONE」、失敗なら「FAILED rc=」)を終端マーカーと決めて、日次チェックに1項目足しました。

・最新のログファイルの最終行に終端マーカーがあるか

・マーカーが無いまま、ファイルの更新が3時間止まっていないか

この2条件で「起動したが完走していない」だけを正確に拾えます。実装はログファイルを読んで文字列を見るだけなので、どの言語でも20行程度です。

このチェックを入れた初回の実行で、その朝の無言死を検知しました。ログの途切れた時刻を見ると、開始からちょうど2時間0分。ここまで来れば「2時間で殺す何か」を探すだけで、ExecutionTimeLimitに数分でたどり着きました。3週間分の謎が、監視1項目で1日で解けた形です。

■監視を設計するときの3つの指針

同じ仕組みを入れる方のために、実際にハマった点も含めて設計の指針を残します。

1つ目。終端マーカーは「成功」と「失敗」の両方に必ず出すこと。成功時だけDONEを出す設計だと、失敗のたびに監視が「実行中かもしれない」と迷い続けます。失敗パスでも必ずFAILEDを出力してから終了する。これだけで判定が二値になります。

2つ目。停止とみなす閾値は「想定実行時間の1.5〜2倍」にすること。短すぎると長めの正常実行を誤検知し、長すぎると発見が遅れます。私は実測2時間のジョブに3時間で設定しました。

3つ目。ログの文字コードに注意。PowerShellのリダイレクトはUTF-16で書き出すことがあり、UTF-8前提で読むとマーカー検索が空振りします(これも実際に踏みました)。ファイル先頭のBOM(FF FE)を見て読み分けるのが確実です。

■修正と、もうひとつの罠

修正自体は数行です。

$t = Get-ScheduledTask -TaskName "タスク名"

$s = $t.Settings

$s.ExecutionTimeLimit = "PT5H"

Set-ScheduledTask -TaskName "タスク名" -Settings $s

上限を撤廃(PT0S)にする選択肢もありますが、本当に暴走したときに止まらなくなるので、想定実行時間の2倍程度の値を入れるのが無難だと思います。

もうひとつの罠は、GUIの新規作成では既定が「3日」なのに、既存タスクのXMLをエクスポートして流用したり、一部のツールで登録したりすると「1時間」や「2時間」が入っていることがある点です。XMLの中の ExecutionTimeLimit 要素はコピーの際にそのまま引き継がれます。私のタスクも過去の自分がテンプレ流用で作ったもので、2時間制限が入っていることを本人が知りませんでした。

■まとめ: 「静かな失敗」には「完走の定義」で対抗する

・Result 267014 (0x41306) を見たら実行時間制限を疑う

・確認は (Get-ScheduledTask).Settings.ExecutionTimeLimit の1行

・裏取りはTaskSchedulerのOperationalイベントログ。定刻死は「時間で切る何か」の証拠

・監視は「起動したか」ではなく「終端マーカーまで到達したか」

・失敗がエラーを出してくれると期待しない。「正常に途切れる」失敗がいちばん長生きする

本文はここまでで完結です。この先は付録として、私が毎朝実際に回している完走チェックスクリプトの全文(PowerShell・コピペで動く形)と、Task Schedulerへの登録コマンド、閾値の調整方法を置いています。本文の内容だけで仕組みは再現できますので、実装の手間を省きたい方向けです。