AIエージェントが作った Windows 自動化が「静かに死んでいる」のを見抜いて直す

AIエージェント（ブラウザ操作型のBot、コーディングAI、自分自身）に 「毎晩フォルダを整理しておいて」のような常駐タスクを作らせると、 作った直後の1回だけ成功し、以後スケジュール実行は毎回失敗し続けるという壊れ方をする。

エージェントは「毎晩の掃除も入れました」と報告して終わるが、その報告に動作確認は含まれていない。 タスクスケジューラは失敗しても画面に何も出さないので、数週間気づかない。

この手順書は、(1) 生きているように見えるタスクが実は死んでいることの判定、 (2) 最頻出の原因である文字コード事故の特定、(3) 二度と壊れない直し方、を扱う。

対象: Windows + タスクスケジューラ + PowerShell。所要 5〜10分。

---

1. 「動いているつもり」を3つの数字で否定する

タスクが登録されていること（State=Ready）は動いている証拠にならない。次の3つを必ず突き合わせる。

Get-ScheduledTaskInfo -TaskName '<タスク名>' |
  Select-Object LastRunTime, LastTaskResult, NextRunTime, NumberOfMissedRuns

• LastTaskResult が 0 以外なら失敗。1 は「実行したプログラムが異常終了した」で、原因は別途特定が要る。
• LastRunTime が今日でも、失敗して即終了しているだけのことがある。時刻だけ見て安心しない。

そして必ず成果物の実体も見る。ここが決定打になる。

# 移動先に「初日以降のファイルが1件も無い」なら、初回手動実行しか成功していない
Get-ChildItem '<出力先フォルダ>' -Force |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 5 Name, LastWriteTime

判定パターン: 出力先の最新ファイルの日付が「エージェントが作業した日」で止まっている → その日の手動実行だけが成功し、以後のスケジュール実行は全滅している。

---

2. 原因の第一候補: スクリプトが BOM なし UTF-8 で保存されている

AIエージェントが書いたスクリプトファイルは、BOM なしの UTF-8 になっていることが非常に多い。 Windows PowerShell 5.1（powershell.exe。OS標準で、タスクスケジューラの既定はこちら）は BOM が無いファイルをレガシーANSI（日本語環境では CP932）として読む。

その結果:

• スクリプト中の日本語リテラル（パス名・フォルダ名・比較文字列）が化ける
• 化けた結果クォートの対応が崩れ、実行以前に構文解析で失敗する
• powershell.exe は終了コード 1 を返すだけ。処理は1行も走らない

PowerShell 7（pwsh）は BOM なしを UTF-8 と解釈するので、手元の pwsh では再現せず、 タスクスケジューラ経由でだけ壊れる。これが発見を遅らせる。

2-1. 先頭バイトを見る（1秒で判定できる）

$b = [System.IO.File]::ReadAllBytes('<スクリプトのパス>')
($b[0..2] | ForEach-Object { $_.ToString('X2') }) -join ' '

• EF BB BF → BOM 付き UTF-8。この問題ではない
• それ以外（例 24 45 72 = $Er…）→ BOM なし。日本語を含むなら真っ黒

2-2. 実行せずに構文だけ検証する

ファイルを走らせずに、PowerShell 5.1 がどう解釈するかだけを確かめられる。 副作用ゼロで断定できるので、直す前に必ずこれを通す。

powershell.exe -NoProfile -ExecutionPolicy Bypass -Command @"
`$e = `$null
[void][System.Management.Automation.Language.Parser]::ParseFile('<スクリプトのパス>', [ref]`$null, [ref]`$e)
if (`$e) { `$e[0].Message } else { 'PARSE OK' }
"@

The string is missing the terminator: '. が出たら文字コード事故で確定。

---

3. 二度と壊れない直し方

3-1. BOM 付き UTF-8 で書き戻す

Set-Content -Encoding UTF8 は PowerShell のバージョンで挙動が変わる（7 では BOM なし）。 バージョンに依存しない .NET の API を使う。

$enc = New-Object System.Text.UTF8Encoding($true)   # $true = BOM を付ける
[System.IO.File]::WriteAllText('<スクリプトのパス>', $script, $enc)

3-2. 日本語リテラルをコードポイントで組む（本命の対策）

BOM は、あとで誰か（や別のAI）がエディタで保存し直すと簡単に失われる。 そもそも非ASCII文字をソースに置かないのが恒久対策になる。

# 'D:\ダウンロード' を ASCII だけで組み立てる
$dl = 'D:\' + [char]0x30C0 + [char]0x30A6 + [char]0x30F3 + [char]0x30ED + [char]0x30FC + [char]0x30C9
# '旧'
$kyu = [string][char]0x65E7
$dest = Join-Path $dl $kyu

コードポイントは任意の言語で取れる（例: JavaScript なら '旧'.codePointAt(0).toString(16) → 65e7）。 可読性は落ちるので、各行の末尾に元の文字列をコメントで残す。

3-3. 終了コードを明示する

スクリプト末尾に exit 0 を書く。途中で握りつぶした非致命的エラーが LastTaskResult を汚して「失敗しているように見える」のを防げる。 逆に本当に失敗した時だけ 0 以外を返すようにしておくと、以後は §1 の1行で健全性を判定できる。

---

4. 直ったことの確認（ここを省かない）

登録しただけ・書き直しただけで報告しない。実際に走らせて 0 を確認する。

Start-ScheduledTask -TaskName '<タスク名>'
Start-Sleep -Seconds 25
Get-ScheduledTaskInfo -TaskName '<タスク名>' | Select-Object LastRunTime, LastTaskResult

LastTaskResult : 0 と、成果物側の件数・最新日時が動いたことの両方を見る。 片方だけでは「何もせず正常終了した」と区別がつかない。

---

5. AIエージェントに常駐タスクを作らせる時の受け入れ条件

この事故は「エージェントが嘘をついた」のではなく、 エージェントの完了報告に検証が含まれていないことから起きる。指示の時点で条件を付ける。

1. 作ったスクリプトの先頭3バイトを表示して、BOM 付きであることを示すこと
2. Parser::ParseFile で PARSE OK を示すこと
3. Start-ScheduledTask で1回走らせ、LastTaskResult=0 を示すこと
4. 成果物の実体（移動件数・出力ファイルの最新日時など）を数字で示すこと

「入れておきました」だけの報告は受け取らない。 そして作らせた側が後日 §1 を1回実行する（初回成功だけして翌日から死ぬ壊れ方があるため、 作った翌日にもう一度見るのが最も費用対効果が高い）。

---

付録: 他の原因（BOM でなかった場合）

LastTaskResult が 0 以外で、構文は PARSE OK だった時の切り分け順。

値	意味	見るところ
1	プログラムが異常終了	スクリプトを手動実行してエラー本文を見る
0x41301	まだ実行中	前回が終わっていない。MultipleInstancesPolicy
0x2	ファイルが見つからない	-File のパス、作業ディレクトリ
0x41303	一度も実行されていない	トリガーの StartBoundary が未来

加えて、タスクの LogonType を確認する。InteractiveToken はユーザーがログオンしていないと 走らない。無人運転させたいなら「ユーザーがログオンしているかどうかにかかわらず実行する」に変える （ただし資格情報の保存が必要になるので、要否は運用者が判断する）。

Export-ScheduledTask -TaskName '<タスク名>'   # 定義XMLを丸ごと見るのが速い