AIコードレビューは何周で止める？

計画書のレビューは4回目でようやくGOが出た。終わらないループと、途中で切ってはいけないループの見分け方を、実例とCLIの罠で書く。

別系統のモデルにコードレビューを任せると、「何周で止めるか」が毎回の悩みになります。止めるのが早すぎると穴が残ります。遅すぎると、理想論の指摘が延々と続きます。打ち切りの基本の考え方は「コーディングエージェントの選び方」に書きました。この記事では、そこに書かなかった実例と、レビュー CLI の罠をまとめます。実装の前、設計の段階で別のAIに反論させる手順は「別のAIに設計を反論させる」にまとめました。

CLI は、編集部の検証環境に入れた Codex CLI（@openai/codex、codex-cli 0.163.0、2026-10-16）で確かめました。

1回で GO にならないもの

計画書：ある計画書は、v1 から v4.1 まで4回レビューを通しました。反映した指摘は、累計で Critical 9件、Important 12件です。「互換性を完全に維持」と書いた箇所は、毎回、レスポンスの形が少しずつ違っていて壊れていました。互換性は、文章ではなく、実際のレスポンス body を並べて確かめます。

失敗しても本処理を止めない実装：通知が失敗しても本処理は続ける（fail-open）実装では、P2 が5ラウンド続けて積み上がりました。中身は、ステップ単位の結果の扱い、set -e の下で黙って落ちる処理、引数からの URL の漏れ、--fail-with-body の付け忘れでした。「secret が未設定」「payload の失敗」「HTTP の失敗」「通信の失敗」を、一段ずつたどってレビューしてもらうと収束しました。

修正のコミットもレビューする

指摘を直したコミットを、もう一度レビューに出すと、修正から派生した P2 が出てきます。「push の失敗は全部リトライする」と直したら、恒久的な 4xx のエラーまでリトライの列に積まれ、無限にたまる作りになっていました。直したあとは、直した差分だけでも1周回します。

指摘をそのまま直しに行かない

会話の履歴を持たないレビュアーは、合意済みの論点を蒸し返します。 設計の段階で決着した点が、Critical として返ってきます。受け取ったら、合意文書の該当する節と照合します。既に合意していれば、節の番号を根拠に却下します。

既存の実装を「欠陥」と呼ぶ前に、決定ログとコミットの本文を読みます。ある相談では、返ってきた3つの指摘が、どれも既に決めた事項の蒸し返しでした。別のモデルに費用を払って、既に決めたことを追認させただけでした。既決と分かったら、「前提が変わったか」だけを尋ねます。

重い結論には、互いを見せないレビュアーを

取り返しのつかない結論は、主張ごとに複数の観点のレビュアーを当てます。レビュアーどうしには互いの結果を見せません。ある分析では、9つの主張のうち生き残ったのは1つだけでした。

敵対的レビューで誤削除が見つかった例は「緑のテストは何も証明しない」にあります。

CLI の罠

レビューを自動で回すときに踏んだものです。

• stdin 待ちで固まる：バックグラウンドで codex exec を回すと、標準入力を待って止まります。プロンプトは - < file で渡すか、< /dev/null を付けます。codex exec --help にも「プロンプトが引数に無い（または -）なら stdin から読む」と書かれています（v0.163.0）。
• 終了コード 0 は「本文が届いた」ではない：出力ファイルに本文が届くのが、数分から数十分遅れたことがあります。4ラウンドのうち3ラウンドで、最初に見たときは本文が空でした。「基盤の問題」と誤認しかけましたが、待つと全部に中身があり、P1 と P2 が計11件届きました。完了は行頭のマーカーで判定し、最大で15〜20分待ちます。
• マーカーがプロンプトのエコーに一致する：codex exec - < PROMPT.md は、出力の先頭にプロンプトの全文をエコーします。「最後に DONE と出力せよ」と書いた指示文そのものに、マーカーの検索が一致しました。行頭アンカー（^DONE$）で判定します。
• --base とプロンプトは併用できない：手元で試すと、引数の解析の段階で拒否されました。

$ codex review --base main "check"
error: the argument '--base <BRANCH>' cannot be used with '[PROMPT]'

--help の Usage には codex review --base <BRANCH> [PROMPT] と出るので、併用できそうに見えます。編集部は、プロンプトを codex exec に stdin で渡し、本文の1行目に「git diff main...HEAD をレビューして」と書く形にしています。

• base はローカルの ref で解決される：fetch しただけで、ローカルのブランチを進めていないと、古い ref と比べてしまいます。
• 競合マーカーが偽の P1 になる：作業ツリーに merge conflict のマーカーが残っていると、「コンパイルできない」という偽の P1 が返ります。
• 出力は短く指定する：レビューの出力を /tmp に6回分ためたら数MBになり、シェルの道具全体が重くなりました。いまは「1000字以内・結論から」と指定し、wc -c で大きさを見てから末尾だけを読みます。

製品ごとのレビューの出し方は「AIコーディング3製品を運用で比較」に書きました。

まとめ

• 計画書と fail-open の実装は、1周では終わらない前提で予定を組む。
• 修正のコミットも、直した差分だけでもう1周回す。
• 合意済みの論点の蒸し返しは、合意文書の節番号で却下する。
• CLI は、stdin、遅れて届く本文、エコーされるマーカーの3つを先に塞ぐ。