はじめに

タスクスケジューラに登録した。前回の実行結果は0、つまり正常終了。それなのに、朝になっても成果物のファイルができていない。ログを開くと途中で終わっているか、1行もない。

Claude Code のヘッドレス実行（claude -p）と Codex（codex exec）を、Windowsのタスクスケジューラで毎日動かすようになってから、私は何度もこの状態になりました。3日間、成果物が0本だったジョブがあります。2週間、一度も動いていなかった監視タスクもあります。作ってから一度も動いていなかったbatまでありました。どの場合も、エラーの知らせは来ていません。

この資料は、そういう落とし穴を11件、1件ずつ書いたものです。各節は、起きたこと、原因、直し方、確かめ方の順に並べています。

範囲と時点

作業した時期は2026年7月から10月です。環境はWindows 11のデスクトップPC1台。ノートPCやサーバー用のWindowsでは確かめていません。
使った道具は、タスクスケジューラ、cmd（bat）、Windows PowerShell 5.1（powershell.exe）、Python、Claude Code のCLI、Codex のCLIです。2026年10月10日に入っていた版は、Claude Code 2.1.295、Python 3.13.1、codex-cli 0.162.0-alpha.2 でした。それぞれの件を踏んだときの版は、落とし穴3の Codex（0.151.0-alpha.7.2）を除いて、記録に残していません。
どの道具も仕様が変わります。落とし穴3は、Codexの更新で、それまで動いていた書き方が黙って動かなくなった件です。ここに書いたことも、同じように古くなる可能性があります。日付を添えた件は、その日の記録です。いまの版で同じことが起きるかを確かめていない件は、その節にそう書きました。
載せたコードは、私が動かしているものから写しました。パス、ジョブ名、タスク名、環境変数名、ログの目印の名前は、一般的な形に置き換えています。作業フォルダは D:\work\ と書きました。長いものは抜粋で、省いた所は ... で示しています。
この資料のとおりにしても、同じ結果になること、ジョブが止まらなくなることは保証しません。環境と時期によって結果は変わります。自動化する中身の選び方、プロンプトの書き方、費用の比較は扱いません。スクリプト一式の配布も含みません。

目次

Claude Code・Codex編 1. claude -p にプロンプトのファイルパスを渡すと、聞き返して正常終了する 2. 書き込みツールを持たせたら、成果物が「書き出しました」の報告で上書きされた 3. Codexが1ファイルも読めないまま、毎朝レポートを出していた 4. npx で登録したMCPサーバーが、毎回タイムアウトする

bat・ps1編 5. batとps1に日本語のコメントを書くと、起動しなくなる 6. 常駐プロセスを起こした行から後ろが、実行されない 7. 同じログファイルに2本が同時に書くと、後から来たほうは何もせずに終わる

タスクスケジューラ・電源編 8. スリープ中に予定時刻を過ぎたタスクが、起きたあとも実行されない 9. 「3時間おき」の繰り返しが、登録した日にしか動かない 10. 深夜のジョブがスリープで止まり、「負の秒数」のタイムアウトで落ちる 11. 実行のたびに黒い窓が前面に出て、フォーカスを奪う

補足: --model を書いておく（踏む前に塞いだもの）

登録前後の点検リスト

落とし穴1　`claude -p` にプロンプトのファイルパスを渡すと、聞き返して正常終了する

何が起きたか

毎朝のメール仕分けジョブを、batから claude -p で動かしていました。プロンプトは長いので、Markdownのファイルに書いて、そのパスを引数に渡す形です。

claude -p "%PROMPT_FILE%" ^

これが、仕事をしないまま終わることがありました。出力されていたのは、このファイルをどうしますか、という趣旨の質問です。Claude Code はその質問を出して、終了コード0で終わっていました。

終了コードが0なので、タスクスケジューラの上では成功です。失敗の印はどこにも付きません。原因まで確かめたのは、2026年7月6日です。

原因

引数に渡したのはプロンプトの本文ではなく、ファイルの場所です。モデルはそのファイルを読みます。読んだうえで、「ファイルは渡されたが、指示が添えられていない」と受け取ることがある。そうなると、作業に入らず、質問を返します。

軽いモデルだから起きる、という話ではありませんでした。haiku でも sonnet でも起きています。毎回起きるわけでもありません。

これは2026年7月6日の記録です。いまの版（2.1.295）で同じ聞き返しが起きるかは、確かめていません。

直し方

直した点は2つです。

1つ目。プロンプトは、ファイルの中身を標準入力から流し込みます。type でファイルを読み、パイプで claude -p に渡します。

2つ目。終了コードを信用しません。プロンプトに、作業が済んだら決まった1行（私の場合は [MAIL-TRIAGE] OK total= で始まる行）を出すよう書いておきます。bat側は、ログにその1行があるかを findstr で調べ、無ければ失敗として扱います。

type "%PROMPT_FILE%" | claude -p ^
    --model sonnet ^
    --allowedTools "Bash,Read,Write" ^
    --max-turns 15 ^
    >> "%LOG_FILE%" 2>&1

set EXIT_CODE=%ERRORLEVEL%

findstr /c:"[MAIL-TRIAGE] OK" "%LOG_FILE%" >nul 2>&1
if errorlevel 1 (
    echo [MAIL-TRIAGE] MARKER MISSING - treating as failure >> "%LOG_FILE%" 2>&1
    set EXIT_CODE=2
)

（コメント行を省いています）

batの最終行は exit /b %EXIT_CODE% です。目印が無ければ、タスクスケジューラには終了コード2が返ります。

--model sonnet は、使うモデルを明示する指定です。書いておく理由は、補足に回します。
--allowedTools と --max-turns は、このジョブに使わせる道具と、やり取りの回数の上限です。値はジョブによって違います。
ログは、ファイル名に日時（分まで）を入れて、1回の実行ごとに別のファイルにしています。findstr が前の回の目印を拾うことはありません。

目印の名前は、ジョブごとに変えます。OK だけにすると、別の行に偶然当たります。

確かめ方

登録したら、予定時刻を待たずに Start-ScheduledTask で1回動かします。そのあとで見るのは3つです。

ログに目印の行（[MAIL-TRIAGE] OK）がある
タスクスケジューラ上の結果が0
成果物が実際にある（このジョブなら、メールにラベルが付いている）

3つが揃うまでは、「動いている」と言わないことにしています。配線しただけでは、何の担保にもなりませんでした。

ここから先は有料です。残りの10件と、--model についての補足、登録前後の点検リストを載せています。