無人の AI 委譲が「毎日成功」の裏で全滅する3つの穴と塞ぎ方

AI コーディング CLI（Codex 等）へ無人ジョブから作業を委譲している環境で、「通知は毎日届くのに成果が 1 件も出ない」状態を 10 日間見逃した実例から、原因と恒久対策をそのまま再現できる形にした指示書。

症状の見分け方

• 委譲ログに「失敗」と「実行中」が同数ずつ溜まり、「成功」は通知だけ。
• 委譲先の出力ログを読むと、作業自体は終わっているのに「指定の保存先は書き込み許可範囲外のため別の場所に保存した」と書いてある。
• 委譲先の stderr に usage limit と復帰時刻（例 try again at <日時>）が出ているのに、翌日も同じ時刻帯に同じ失敗が並ぶ。

穴 1: 受け取りファイルを委譲先が書けない場所に指定している

委譲先はサンドボックス（WSL や別ユーザー）で動くことが多く、呼び出し側のホームディレクトリは書き込み許可範囲外になりがち。呼び出し側は指定先しか見ないので、委譲先が代替場所に保存しても毎回「ファイル無し」で失敗扱いになる。

対策:

1. 受け取りファイルは委譲先の作業ディレクトリ配下（例 <cwd>/.delegation/<id>.result.json）に置く。
2. プロンプトに埋めるパスは委譲先の環境で有効な表記にする（Windows から WSL へ渡すなら C:\... ではなく /mnt/c/...）。
3. 保険として、指定先に無ければ委譲先の stdout から .result.json で終わる絶対パスを拾って読む。
4. 受け取り JSON に completed: false を許し、「調べた結果、対応不要」を失敗と区別する。

穴 2: 上限エラーを失敗として記録し、次の項目でも同じ失敗を繰り返す

対策:

1. stderr の usage limit と復帰時刻を解析し、<home>/<provider>-cooldown.json に { until, reason } を書く。解析できなければ 24 時間後。
2. 起動前にそのファイルを読み、until が未来なら起動せずに deferred（終了コード 75）を返す。台帳にも deferred で記録する。
3. 呼び出し元は deferred を失敗率から除外し、until まで同じ項目を再試行しない。
4. 無人ジョブには --origin unattended を付け、1 日の呼び出し上限（例 8 回）を <home>/executor-budget.json で持つ。上限到達も deferred。人の対話的な依頼は制限しない。

穴 3: 実行環境が要らない作業まで高額・有限枠の委譲先に送っている

14 日分の台帳を集計すると、委譲 287 回のうち出力トークン中央値 149、出力ゼロ 48 回だった。「調べて一言返す」仕事に実装用の枠を使っていた。

対策:

1. プロンプト本文から種類を判定する純関数を置く: implement（実装・修正・commit・PR）、verify（テスト実行・再現）、investigate（調査・比較・原因特定）、classify、summarize。迷ったら implement。
2. investigate / classify / summarize はコマンド実行の要らない API モデル（Gemini → DeepSeek → Groq の順）へ回し、implement / verify だけ実行環境付きの委譲先へ送る。
3. 無人ループは項目自身の文面で判定する。既定の案内文（例「残作業を確認して再開」）を判定に含めると全件が調査扱いになる。
4. 監督役の AI への案内文も「調査・分類・要約は安いモデル、実装・検証だけ Codex」に揃える。

完了の定義（これを守らないと再発する）

テストが通った・隔離環境で commit できた、は完了ではない。実環境で --apply --max 1 を流し、台帳に 成功 または 未完了 が記録されたことだけを完了とする。無人処理は失敗しても誰も見ないので、この 1 件の実証を省くと「毎日成功の通知」の裏で全滅が続く。

検証コマンドの型

node <sweeper> --dry-run            # 検出のみ
node <sweeper> --apply --max 1      # 実環境で 1 件
tail -3 <home>/<sweeper>-log.jsonl  # 成功 / 未完了 / 保留 / 失敗 を確認
node <delegator> --budget           # 当日の無人割当の残り