SubAgent が落ちた日のための、止まらない代替運用

なぜ書いたか

AIレビュー用のSub Agentをフローに組み込むと、ある日RateLimitで動かなくなります。レガシー移行の現場では「レビューが回せないから手を止める」だと進捗が崩れる一方、「自分でOK出して進める」だと品質が崩れます。今回は、Sub Agentが落ちた日のための代替フローを事前に決めておいた話です。

やったこと

代替運用は3つだけです。

1. rate-limit fallback: Reviewer Sub Agentが落ちたら、別のSubAgent（粒度の粗いもの）に切り替える
2. manual review checklist: それも落ちたら、固定観点のチェックリスト（手動レビュー用）を回す
3. non-close policy: いずれも難しいときは、機能は動いているが タスクをクローズしない。close decision: no をログに明記して翌日に持ち越す

ポイントは3番目です。ビルドが通って手で動かしてもOKっぽいなら、つい「実質完了」にしたくなります。でも「レビューが終わっていない」ことを明示的に状態として残しておかないと、後日「これって終わってたっけ？」が必ず発生します。

具体的な運用

私の場合、Reviewer Sub AgentがRateLimitで動かないとわかった時点で、その日のスライスのtask logにこう書きます。

review status: pending (rate-limit)
close decision: no
resume point: review-1 観点で削除範囲・権限制御・関数呼び出しを再確認すること

翌日、Sub Agentが復活したらこの resume point を渡してレビューさせます。これだけで「停止していた間の認知コスト」がほぼゼロになりました。

わかったこと

• 「止まらない設計」より、「止まったときに何が起きるか」を事前に決めておくほう がはるかに効きます。AIに依存するワークフローでは、止まる頻度がそれなりに高いので
• 暫定でクローズしないルール（close decision: no）は、思った以上に効きました。曖昧に閉じる事故が減ります
• 手動チェックリストは、実はSub Agentの指摘観点をそのまま転記しただけのものです。Sub Agentが普段見ている観点を「人間にも見られるようにする」だけで充分でした

次にやること / 未解決の問題

• フォールバック先のSub Agent自体もRateLimitに当たる日があるので、本当の意味で「人間が回す」モードがどこまで耐えられるかは継続観察します
• task logのテンプレに review status を組み込めば、書き忘れがなくなる気がしているのでそのうち追加します