AI駆動開発の反復を制御する停止条件とロールバック設計
POINT
- 固定回数で反復するのではなく、エラー信号から収束・停滞・発散を判定し、最良の出力へ戻す設計ができる。
- 複数エージェントは、指揮・実装・監視を分けることで、止まった作業や不適切な操作を早く見つけやすい。
- 小規模チームでも、停止条件、ロールバック、権限分離を先に決めれば、コストを抑えながら品質を守れる。
なぜ固定回数の反復では品質を守れないのか
AIコーディングエージェントに「20回まで修正させる」と指示しても、20回目の出力が最良とは限らない。改善が止まった後もAPI利用料だけが積み上がり、途中から出力が崩れることもある。
LoopGainは、各反復のエラー信号を観測し、最小エラーの出力をbest-so-farとして保存する。ベンチマークでは、max_iter=20のAPI支出が27.05ドルだったのに対し、LoopGain使用時は1.94ドルだった。試行あたりの中央値実時間も30.9秒から2.1秒へ短縮した。
ただし、収束は正しさの証明ではない。止め方を決める前に、何をエラーとして測るかを設計する必要がある。
停止とロールバックをどう組み込むか
評価はテスト成功数だけに寄せない。ビルド結果、静的解析、差分規模、レビュー指摘を作業単位で記録する。観測エラーが目標値以下ならTARGET_METで止め、停滞、振動、発散を検知したら次の修正を走らせない。
発散時は最後の回答を採用せず、保存済みの最小エラー出力へ戻す。これがロールバックの中核である。LoopGainはOSCILLATING、DIVERGING、STALLINGなどの状態を扱い、決定論的なモック軌跡1,000件でマクロ平均精度98.8%を報告している。
複数エージェントの役割はどう分けるべきか
小規模チームでは、全員に設計から実装、デプロイまで任せない。依頼を分解して担当を指示するDirector、コードを書くMember、停止を検知して通知するMonitorに分ける。cafleetはこの3種を定義し、Claude Code、Codex、OpenCodeをサポートする。
cafleetの解説によれば、CLIはtmuxとherdrを扱い、WebUIから作業状況を確認してチャットで介入できる。Monitorには修正権限を渡さず、異常の通知と再開確認に絞る。監視役が勝手に差分を広げないためだ。
Claude Codeには2026年2月5日、バージョン2.1.32で、複数のエージェントをチームとして動かすResearch PreviewのAgent Teams機能が追加された。チーム機能を使う場合も、役割と権限は運用側で明文化したい。
自動化の境界はどこに置くか
読み込んだ文書やWebページには、次のツール呼び出しを変えようとする悪意ある指示が混ざり得る。モデルの判断と、外部システムへ書き込む実行権限を同じ場所に置く設計は避けるべきだ。
The New Stackの記事が紹介したMateの実行分離層は、ツール呼び出しを送信前に検証し、実行範囲を設定して記録する。PR作成は許可し、本番デプロイは人間承認にする。このような境界を置けるなら導入を進めやすい。一方で、停止条件や承認者を決められない作業では、自動実行の範囲を広げないほうがよい。
まとめ
導入判断では、エージェント数より先に、測定できるエラー信号、停止条件、戻す地点、書き込み権限を決める。AI駆動開発では「何回回すか」ではなく、どの状態で止め、誰が次の操作を承認するかを設計することが、安全な自動化の出発点になる。