「安いAIへ委譲しろ」の強制と、その委譲先の枠切れが同時に起きるとAIは何も書けなくなる

誰のための指示書か

コーディングAIに「実装は定額枠の別AIへ委譲しろ。自分で手打ちするな」という規律をフックで機械的に強制している人向け。 強制を warn（警告だけ）から block（実際に編集を拒否）へ上げた瞬間、委譲先が枠切れした日に開発が完全停止する。 その事故を、実際に踏んでから直した記録。

何が起きるか

前提として、こういう構成をとっていることが多い:

• 監督AI（設計・レビュー担当）は実装を手打ちしない。実装は定額枠のコーディングCLIへ委譲する
• 委譲率が下がったら PreToolUse フックが permissionDecision: "deny" を返し、監督AIの Write/Edit を止める

ここに委譲先の使用上限が重なると:

委譲先が枠切れ  →  委譲できない
       ＋
ハードブロック   →  自分でも書けない
       ＝
       1行も書けない

さらに悪いことに、委譲先アカウントをチーム共有の1本にしている場合、枠切れは全端末で同時に起きる。 1台で詰まるのではなく、チーム全員のAIが同時に止まる。

誤った直し方（最初にやってしまった方）

「委譲先が枠切れ中なら、ハードブロックを解除して監督AIの直接編集を許可する」

これは間違い。 多くの委譲ツールは枠切れを検出すると別の無料枠AIへ自動フォールバックする。 つまり枠切れ中でも委譲は動いており、デッドロックは起きていない。 にもかかわらずブロックを解除すると、本来まだ委譲できる場面で監督AIに実装させてしまう。

これはコスト面でも品質面でも損をする。監督AIの枠は設計・レビュー・検証に使う枠と同じなので、 実装で食い潰すと本来やるべき検証ができなくなる。

正しい解除条件

主経路とフォールバックの両方が使えないときだけ解除する。

状況	挙動
主経路が正常	DENY（従来どおり委譲を強制）
主経路が枠切れ・フォールバック生存	DENY を維持 ＋「委譲ツールはそのまま使える（自動でフォールバックする）」と案内文を足す
両方使用不可	解除して直接編集を許可

真ん中の行が肝心。ここで案内文を足しておかないと、AIは「枠切れなのに拒否された」と誤解して 無駄な再試行を繰り返す。「そのまま委譲ツールを呼べ、勝手にフォールバックする」と明示する。

実装の骨組み

1. クールダウンを記録する（委譲ツール側）

委譲ツールが枠切れを検出したら、共有の状態ファイルへ書く。

// state: { "<provider>": { until: <epoch ms>, reason: "usage_limit", at: <epoch ms> } }
export function writeCooldown(until, file, reason = 'usage_limit') {
  let state = {};
  try { state = JSON.parse(fs.readFileSync(file, 'utf8')); } catch {}
  if (!state || typeof state !== 'object' || Array.isArray(state)) state = {};
  state.<provider> = { until: Number(until), reason, at: Date.now() };
  fs.mkdirSync(path.dirname(file), { recursive: true });
  fs.writeFileSync(file, `${JSON.stringify(state, null, 2)}\n`, 'utf8');
}

他プロバイダのキーを消さないこと。 同じファイルをフォールバック連鎖側も読んでいることが多い。

2. 「フォールバックも死んだ」を別の理由コードで表す

枠切れを検出した時点では usage_limit で記録し、 フォールバックまで失敗して初めて usage_limit_no_fallback へ格上げする2段構えにする。 フォールバックを試さない設定（--no-fallback 相当）で終わった場合は格上げしない。

3. 解除判定を1関数に閉じる

// bypass = true にするのは次の両方を満たすときだけ
//   1. クールダウンが有効 (until > now)
//   2. かつ、フォールバックも使えない
//      (reason が usage_limit_no_fallback / またはフォールバックCLIがPATHに無い)
export function hardBlockBypass(now = Date.now(), file, opts = {}) { ... }

opts でフォールバックCLIの有無を注入できるようにすること。そうしないとテストが書けない。

落とし穴（実際に踏んだもの）

復帰時刻のパーサは「実際に出た文言」で検証する

相対時間（try again in 4h 12m）だけ想定していたら、実際のCLIが出したのは 月名つきの絶対日時 try again at Sep 7th, 2026 11:27 AM だった。 パーサは既定値（+60分）に落ち、4日続く枠切れを1時間と誤読していた。

block 運用下ではこれが致命的で、1時間後にブロックが復活してデッドロックが再発する。 時刻パーサを書いたら、必ず本物のエラーメッセージそのものを入力して確かめる。 実装すべきパターン: 相対時間 / 月名つき絶対日時（序数 st,nd,rd,th と AM/PM を含む）/ ISO8601 / resets at HH:MM。 年が明示されていて過去になる日時は「もう復帰済み」としてクールダウン0を返すのが安全。

状態ファイルの偽エントリは「静かに強制を無効化する」

このクールダウンファイルはブロックを解除する権限を持つ。 動作確認のつもりで打った一時コマンドが本物のファイルへ書き込むと、 存在しない枠切れを理由に強制が解除され続ける（実際に発生した）。

• 確認は必ず一時ディレクトリ＋ファイルパスを明示した引数で行う
• テストも同様（mkdtemp + 環境変数でホームを差し替える）
• 「強制の状態ファイル」は、消えても壊れても安全側（＝強制する側）に倒れるよう読み取り側を書く （JSONが壊れている・ファイルが無い・値が過去 → すべて「クールダウン無し」を返す）

委譲は必ず専用の作業ツリーで走らせる

共有チェックアウトで委譲AIを走らせ、途中で中断すると、 中途半端な編集が本番の実行パスに残る。実際に「存在しないモジュールを import するフック」が残り、 フックが起動のたびに壊れる状態になった。

• 委譲は使い捨ての作業ツリー（git worktree add）で行う
• 中断したら必ず作業ツリーの差分を確認して片付ける。中断＝無害ではない
• 特にフック・設定・CLIの実体そのものを編集させるときは、実行パスと編集パスを分ける

検証のしかた

テストだけでなく、フックを実際に叩いて挙動表を出す。

// 3ケースそれぞれで一時ホームを作り、cost-enforce.json と cooldown を仕込んで
// フックに stdin から tool_use を流し込み、permissionDecision を見る
const r = spawnSync(process.execPath, [hookPath], {
  input: JSON.stringify({ tool_name: 'Write', tool_input: { file_path: '...' } }),
  encoding: 'utf8',
  env: { ...process.env, <HOME_ENV>: tmpHome },
});

「クールダウン無し → DENY」「枠切れ・フォールバック生存 → DENY」「両方死亡 → 許可」の3行が そのまま出ることを目で確認してから完了とする。ユニットテストのpass数だけでは、 解除条件が緩すぎる設計ミスは見つからない（実際、テストは全部通ったまま設計が間違っていた）。

まとめ

• 「委譲しろ」の強制を block にする前に、委譲先が死んだ日に何が起きるかを必ず設計する
• 解除条件は「主経路が死んだ」ではなく「主経路とフォールバックの両方が死んだ」
• 復帰時刻のパーサは実際の文言で検証する。既定値に落ちていることに気づけない
• 強制を解除する権限を持つ状態ファイルは、テストや確認コマンドから絶対に隔離する