安いAIレーンが壊れたまま何週間も放置される問題を、ヘルス判定と応答ゲートで潰す

何が起きるか

Claude Code などの監督AIが、実装を安い実行者（Codex CLI・DeepSeek・Gemini など）へ委譲する構成にしていると、 実行者が環境要因（WSL ディストリ不在・CLI 未導入・未認証）で落ちたとき、監督は毎回「代替へフォールバック」して作業を続ける。 作業は止まらないので誰も困らず、故障は何週間も放置される。その間ずっと、いちばん高い監督AI本体が実装を抱え続ける。 実例: Codex が「WSL ディストリが見つかりません」で43日間・112回起動に失敗していたが、誰も直していなかった。修理は数分で終わった。

放置を生む3つの設計ミス（自分の仕組みを点検する）

1. ヘルス判定が環境故障を low にしている: 「コードでは直せない」「人の操作が要る」という理由で severity を low にし、修理タスク（fixTask）を付けていない。毎朝のレポートに出ても起票されない。
2. 失敗行の誤分類: 起動前に終了した行（終了コードが文字列の番兵など）を「起動前ゲートが意図的に止めた」と分類し、本物の起動失敗まで正常扱いにしている。
3. 応答ゲートの免除が軽い: 「全滅したので本体で実施」と1行書けば、失敗後に監督本体が作業しても通ってしまう。

対策1: ヘルス判定（日次）

• 環境故障（ランタイム不在・spawn 失敗・未認証）は high＋具体的な修理手順の fixTask にする。
• 全レーン共通で「集計窓内に3件以上、成功0件」の provider を lane_outage_unrepaired（high）として出す。成功の定義は既存の status 正規化関数に合わせる。
• 最後の失敗より後に成功が1件でもあれば出さない。直った故障に警報を出し続けると、警報そのものが無視されるようになる。
• 分類の順序: 「ランタイム不在」の stderr パターン判定を、「起動前ゲート」判定より先に行う。

対策2: 応答ゲート（Stop hook）

• そのターンの Bash/PowerShell の実行結果だけから失敗シグナルを拾う（Read で読んだメモやログ本文に残る過去の失敗語で誤検知しないため）。 シグナル例: usage limit、credits are depleted、HTTP 402/429、spawn X ENOENT、ランタイム不在メッセージ、委譲コマンドの command not found。
• 失敗シグナルがあるターンは、応答に次のどちらかの行が無ければ block する:
  • [LANE-REPAIR] <レーン>: 修復済み <内容>（空でない説明が必須）
  • [LANE-REPAIR] <レーン>: 修復不可 試行: <試した手段>（「試行:」の後ろが空でないこと）
• 従来の「フォールバック宣言」1行だけでは免除しない。修理報告と併記されたときだけ有効にする。
• user が明示した免除語（例 [LANE-OK]）は残す。

対策3: ルール文

「他AIが落ちたら、代替や本体へ逃げる前に原因を調べて修理し、1回実行して成功を実測する。アカウント追加や有料化は修理と実測のあとで検討する」を運用ルールに明記する。 ルール文だけでは守られないので、必ず対策1・2の機械検査とセットにする。

参考: Windows で Codex CLI の WSL 経路を復旧する手順（管理者権限・再起動なしで通った実測）

WSL 本体が入っていてディストリだけ無い場合（wsl --status は応答するが wsl -l -q が空）:

wsl --install -d Ubuntu --no-launch
wsl -d Ubuntu -u root -- bash -lc "apt-get update -qq && apt-get install -y -qq curl ca-certificates && curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && apt-get install -y -qq nodejs && npm i -g @openai/codex"
wsl -d Ubuntu -u root -- bash -lc "mkdir -p /root/.codex && cp /mnt/c/Users/<Windowsユーザー名>/.codex/auth.json /root/.codex/ && chmod 600 /root/.codex/auth.json && codex login status"

Logged in using ChatGPT が出たら、1ファイル作成の小さな指示を codex に実行させ、ファイルが実際にできることを確認する。 --no-launch で入れたディストリは既定ユーザーが root になり、ユーザー作成の対話は出ない。

検証の仕方

• 実際の委譲台帳でヘルス判定を走らせ、修理前の行だけなら high、修理後の成功行が入ると healthy になることを確認する。
• 応答ゲートは、失敗→「代わりにやります」/ フォールバック宣言のみ / 修理報告あり の3パターンの合成 transcript で、block・block・pass になることを確認する。