RateLimit で止まる前提で、開発プロセスを設計する

なぜ書いたか

AIを中核に据えた開発フローを組むと、ある日突然「実装はできているのにレビューが回らない」状態になります。原因はだいたいRateLimitです。コードのバグではなく 運用上の正確さ が崩れる、という新しい種類の詰まりが発生する、というのが今回の気づきでした。

やったこと

「止まらないようにする」のは諦めて、止まったときの所作を事前に決めました。

1. 実装とビルドが終わったらReviewer Sub Agentを回す
2. RateLimitに当たったら、別SubAgentに切り替えて再試行
3. それも止まったら、その日はクローズしない（close decision: no をログに残す）
4. 翌日、Sub Agentが復活したら再開ポイントから再開する

ログで状態を外に出す仕組み

この運用を支えているのが、各スライスに1つ作る task log です。

私の場合、スライスを切るたびにタスクログファイルを1つ作り、実装の過程で判断したことをその場で書き残すルールにしています。構成はシンプルで、「何を触るか（Evidence）」「何をしたか（実装ログ）」「今の状態（ステータス）」の3ブロックだけです。

RateLimit対応の観点で重要なのは3つ目のステータスブロックです。ここを AIの記憶ではなくファイルに持たせる ことで、翌日別のAgentが再開しても状態がわかります。

## status
build: ok
unit test: ok
manual scenario: ok
review status: pending (rate-limit)
close decision: no
resume from: reviewer sub-agent / 観点（削除範囲、権限制御、呼び出し整合性）

「機能は動いている」と「タスクとして完了している」を分けて書くのがポイントです。review status: pending と close decision: no を明示的に残すことで、翌日の再開コストがかなり下がりました。

ログはOrchestrator側のルールに組み込んであり、スライスを閉じる前に status ブロックを埋めることをDoD（Definition of Done）の1つにしています。「止まる前提」で運用するとは、つまり 止まったときに状態がファイルに残っている状態を常に保つ ということです。

具体的なログの書き方

止まった日は、statusブロックを中途半端に書かず、「何が完了していて、何が残っているか」を分けて書きます。

特に resume from には「次のセッションでどこから再開するか」を1行で具体的に書くのが重要です。曖昧に「レビュー待ち」とだけ書くと、翌日どの観点からレビューを再開すればよいかが消えてしまいます。ここが具体的であるほど、翌日の立ち上がりが速くなります。

わかったこと

• AI駆動開発で最初にぶつかるのは、コードの難しさではなく 運用の正確さ です。止まる前提で書ける運用が必要
• 「機能は完了」と「タスクは完了」を分けて扱うと、曖昧クローズが激減します
• ステータスをふわっと書かず、close decision: no のような 動詞ではなく状態 で書くと、翌日の自分にも他の人にも伝わる

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

• 別SubAgentへの自動切り替えはまだ手動。fallback reviewer のチェーンをOrchestrator側に組めるか試したい
• RateLimitのリセット時刻を見越して着手のリズムをずらす運用を考えたい（毎日同じ時間に集中しがち）