# 無人の AI 委譲が「毎日成功」の裏で全滅する3つの穴と塞ぎ方 AI コーディング CLI（Codex 等）へ無人ジョブから作業を委譲している環境で、「通知は毎日届くのに成果が 1 件も出ない」状態を 10 日間見逃した実例から、原因と恒久対策をそのまま再現できる形にした指示書。 ## 症状の見分け方 - 委譲ログに「失敗」と「実行中」が同数ずつ溜まり、「成功」は通知だけ。 - 委譲先の出力ログを読むと、作業自体は終わっているのに「指定の保存先は書き込み許可範囲外のため別の場所に保存した」と書いてある。 - 委譲先の stderr に `usage limit` と復帰時刻（例 `try again at <日時>`）が出ているのに、翌日も同じ時刻帯に同じ失敗が並ぶ。 ## 穴 1: 受け取りファイルを委譲先が書けない場所に指定している 委譲先はサンドボックス（WSL や別ユーザー）で動くことが多く、呼び出し側のホームディレクトリは書き込み許可範囲外になりがち。呼び出し側は指定先しか見ないので、委譲先が代替場所に保存しても毎回「ファイル無し」で失敗扱いになる。 対策: 1. 受け取りファイルは**委譲先の作業ディレクトリ配下**（例 `/.delegation/.result.json`）に置く。 2. プロンプトに埋めるパスは**委譲先の環境で有効な表記**にする（Windows から WSL へ渡すなら `C:\...` ではなく `/mnt/c/...`）。 3. 保険として、指定先に無ければ委譲先の stdout から `.result.json` で終わる絶対パスを拾って読む。 4. 受け取り JSON に `completed: false` を許し、「調べた結果、対応不要」を失敗と区別する。 ## 穴 2: 上限エラーを失敗として記録し、次の項目でも同じ失敗を繰り返す 対策: 1. stderr の `usage limit` と復帰時刻を解析し、`/-cooldown.json` に `{ until, reason }` を書く。解析できなければ 24 時間後。 2. 起動前にそのファイルを読み、`until` が未来なら**起動せずに** `deferred`（終了コード 75）を返す。台帳にも `deferred` で記録する。 3. 呼び出し元は `deferred` を失敗率から除外し、`until` まで同じ項目を再試行しない。 4. 無人ジョブには `--origin unattended` を付け、1 日の呼び出し上限（例 8 回）を `/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 --dry-run # 検出のみ node --apply --max 1 # 実環境で 1 件 tail -3 /-log.jsonl # 成功 / 未完了 / 保留 / 失敗 を確認 node --budget # 当日の無人割当の残り ``` ---