LLM による diff レビューを「指摘ゼロまで反復」する運用では、総時間を決めるのは1巡の単価より巡回数になりやすい。レビューは非決定的で、2巡目に1巡目より多い新規指摘が出る（単調収束しない）ことがあり、実測では指摘件数が 3→4→1→0 と推移して4巡を要した。

判断基準

レビュー起動時の重点観点に、実装中に仕様・設計が揺れた箇所（計画への追補として記録された実装中の仕様変更、手戻りが起きた箇所、環境差で実装を差し替えた箇所）を必ず含める。思いついた観点を任意で渡すのではなく、追補の存在を機械的なトリガーにする。

なぜ

実装中に設計が揺れた箇所は、計画時の検討が浅かったことが証明されている場所で、後の巡で新規指摘が湧く出どころになりやすい。実測でも2巡目の新規指摘は実装中に仕様変更した領域（流量制御の上限周り）から出た。1巡目で拾えればフルサイクル1巡分（レビュー実行＋差し戻し＋修正＋再テストで数十分規模）が浮く。

適用条件・限界

• 前提として、実装中の仕様変更を計画側に追補として記録する運用があること（記録がなければトリガーにできない）。
• レビューの非決定性自体は消せないので、巡回数ゼロ保証ではなく期待値の削減策として扱う。終了条件（指摘ゼロまで回す等）は別のレバーとして独立に設計する。

検証

レビューラウンドごとの指摘件数の推移を記録し、2巡目以降の新規指摘が「追補・揺れ箇所由来か」を分類する。揺れ箇所由来の後巡指摘が減り、平均巡回数が下がれば効いている。