AI レビューのループは「重大度で足切り」と「振り子の固定」で止める

どんな時に使う？

• Codex 系のレビューが「実際には起きないエッジケース」「過剰な後方互換」まで指摘し、修正ループが終わらない
• レビュー役のモデルが細かく突き、修正役のモデルがすぐ折れて全部直してしまう（@izutorishima の例: GPT-6.0 Astra が細かく指摘し、Opus 5.5 が折れる）
• 指摘ゼロを終了条件にしたら、いつまでもゼロにならない

手順

1. 影響度で並べさせる: 指摘ごとに「直さないと何が起きるか」で CRITICAL / IMPORTANT / LOW に分け、LOW は捨てる。プロンプトは短く「致命的な問題だけ挙げて。細かい好みの指摘は不要」でもかなり効く（@MLBear2）
2. 範囲外を捨てる: 今回の差分で触っていない既存コードへの指摘は対象外にする
3. 振り子を検出して固定する: 反復ごとのコミット差分を見て A→B→A を見つけたら、両案を比べて良い方を「directive（方針）」として固定し、修正役はそれに従う義務を持たせる
4. 修正後に別セッションで検証: 「根本原因に対処しているか、その場しのぎ（バンドエイド）になっていないか」を別のモデル／セッションに確かめさせる
5. 回数の上限を決める: Akatsuki の例は最大6回で、たいてい2〜3回で収束する

判断基準はプロンプトに直書きせず、チームのコーディングガイドラインのファイルを参照させると、基準を変えてもワークフロー本体を触らずに済む。

Akatsuki の構成例（2026年3月時点の記事）

• レビュー: Codex の review モード（構造化された findings を返すので件数を機械的に数えられる）
• トリアージ・検証: Composer 2（速く広く読む役）
• 修正: Codex
• 手順は Rigg（YAML でエージェント CLI をつなぐ自作ツール）で .rigg/ に置いて Git 管理し、問題が起きるたびにステップを足して育てた

注意点

• 足切りは「方向性の決まった後のコード品質」に限る。何を作るかの判断は人がやる
• 関連: AIコーディング: claude -p を直列に呼んで「重大指摘が0件になるまで」レビューと修正を繰り返す、CI の AI コードレビューは「専門レビュアー＋取りまとめ役」に分け、差分の大きさで人数を変える、Claude Code の Agent Teams で、各工程を Opus と Codex に二重レビューさせる

出典

• @suna_gaku · 2026-10-28 （引用元 @izutorishima · 2026-10-28 ）
• X の投稿より: @MLBear2 · 2026-03-25 、@gorilla0513 · 2026-03-25 、@azu_re · 2026-03-29
• 記事「ハーネスエンジニアリングで人間のコードレビューをやめる」（Akatsuki, Zenn）: zenn.dev