AIレビューを「合格するまでループ」させる開発フロー — Claude Code × Codexで指摘を潰し切る

単発のAIレビューが抱える「二次不整合」の罠

AIレビューを導入しても減らない手戻り

結論から述べると、AIコードレビューを単発で終わらせる運用では、かえって手戻りが増えるケースが少なくありません。昨今、GitHub Actionsなどを活用してPull Request作成時にAIエージェント（Claude CodeやCodeRabbitなど）からレビューコメントを自動でもらうフローを取り入れる開発現場が増えています。

確かにAIは、タイポや基本的な構文エラー、ベストプラクティスからの逸脱を瞬時に指摘してくれます。しかし、実務においてテックリードやEMが本当に悩まされるのは、「AIの指摘を修正した結果、別の箇所がおかしくなる」という現象です。レビュアーである人間がその修正を確認し、再度指摘を返し、また修正する……というキャッチボールが続けば、AIを導入したはずなのに人間の工数は一向に削減されません。

修正が別の不整合を生む「二次不整合（エンバグ）」の恐怖

AIによる単発のレビュー指示では、部分的な最適化に留まりがちです。たとえば、AIに「この関数の処理効率が悪いのでリファクタリングして」と指示し、AIが修正コードを提示したとします。開発者がそれをそのまま適用した場合、パフォーマンスは向上しても「エラーハンドリングの考慮が抜け落ちる」「特定の条件下でのみ発生する状態不整合を見落とす」といった二次不整合（エンバグ）が発生するリスクがあります。

人間のレビュアーであれば、修正内容がシステム全体に及ぼす影響を予測しながら確認しますが、単発で動作するAIエージェントは「その瞬間の差分」しか見ていません。この二次不整合を放置したまま本番環境にデプロイしてしまう恐怖こそが、AIレビューの本格導入を阻む最大の壁となっています。

実装エージェントとレビューエージェントを完全分離する理由

自己評価による「過大評価バイアス」の限界

こうした二次不整合を防ぐために、「AI自身に自分が書いたコードをレビューさせる」というアプローチを考えるかもしれません。しかし、同じAIモデル、同じコンテキスト（文脈）内で「修正」と「レビュー」を兼務させると、特有の問題が発生します。それは「過大評価バイアス」です。

大規模言語モデル（LLM）は、自身が出力した直後のロジックに対して非常に寛容になる傾向があります。「私が書いたコードなので完璧です」とばかりに、潜在的なバグやエッジケースを見逃してしまうのです。人間でも、自分が書いた直後のコードのバグには気づきにくいのと同じ理屈です。この状態では、どれだけAIに自己レビューを命じても、質の高い指摘は得られません。

実装（Claude Code）とレビュー（Codex）の役割分離

このバイアスを排除するための最適なアーキテクチャ設計が、「実装エージェント」と「レビューエージェント」の完全な分離です。これはAIエージェントの設計パターンにおいて「Evaluator-Optimizer（評価者と最適化者）」パターンとも呼ばれます。

たとえば、コードの修正や実装を行う「オプティマイザ」としてClaude Codeを利用し、その修正結果を客観的に評価する「エバリュエータ」としてOpenAIのCodex（または独立したプロンプトを持たせた別インスタンスのモデル）を配置します。

実装AIとレビューAIを分離するEvaluator-Optimizerパターンの図解

インスタンスやコンテキストを明確に分けることで、レビューエージェントは「誰が書いたコードか」という先入観を持たず、純粋な仕様とコードの差分だけを厳格に評価できるようになります。この役割分離こそが、精度の高いコードレビューを自動化するための土台となります。

「合格判定（Pass）」まで自動ループを回すワークフロー構築

終了条件を「合格（Pass）」フラグに固定する

エージェントを分離しただけでは、人間が「実装AIの修正」を「レビューAI」に渡し、その結果をまた「実装AI」に戻すという手間が残ります。ここで重要な結論として、レビューの終了条件を「レビューエージェントによる『合格（Pass）』判定が出るまで」と明確に定義し、その間は人間を介在させないワークフローを構築すべきです。

具体的には、プロンプト内で「レビューを行い、すべての指摘事項が解消され要件を満たしたと判断した場合のみ、最終出力として『PASS』という文字列を返してください」と定義します。この『PASS』フラグが立たない限り、システムは修正ループを抜け出せない仕組みを作ります。

人間を介さず自律的に回る「Evaluator-Optimizer」ループ

この仕組みをCI/CDパイプラインやローカルの開発スクリプトに組み込むことで、完全な自動ループが実現します。フローの動きとしては以下のようになります。

実装AIがコードを修正する。
レビューAIが差分を評価し、不整合があれば指摘事項（エラー内容や修正方針）を出力する。
システムがその指摘を読み取り、実装AIに「以下の指摘を受けて再修正してください」とフィードバックを投げる。
実装AIが再修正を行う。

このループを、レビューAIが「PASS」を出すまで繰り返します。人間は途中のやり取りを一切見る必要がなく、最終的に「二次不整合まで潰し切った状態のコード」だけを受け取ることができるのです。

ループ運用で実際に検出された高精度な指摘事例

この「合格ループ化」フローを実務で運用した結果、人間のレビュアーがうっかり見落としがちな、非常に精度の高い二次不整合の検出に成功しています。以下に具体的な検出例を3つ紹介します。

検出例1：Cookie削除ロジックの分岐抜け

ある認証周りのリファクタリングを実装AIに依頼した際、ログアウト時のセッション破棄は正しく実装されていましたが、特定の条件下で「クライアント側のCookieを明示的に削除する処理」が抜け落ちていました。単発の修正ではスルーされがちなポイントでしたが、レビューAIが「セキュリティ要件を満たすためには、条件Aの分岐内でもCookieを削除する必要があります。現状の実装では不整合が生じます」と的確に指摘。ループ内で自動的に修正され、実装漏れを防ぐことができました。

検出例2：定数時間比較の主張と実装の乖離

パスワードやトークンの検証処理において、実装AIはコメントに「タイミング攻撃を防ぐため定数時間で比較（Constant-time comparison）を行う」と書いていました。しかし実際のコードは、標準の == 演算子を使用した単純な文字列比較になっていました。レビューAIは即座に「コメントの主張と実際の実装が乖離しています。定数時間比較関数（例: crypto.timingSafeEqual）を使用してください」と指摘しました。これも自己評価バイアスがあれば見逃されていた可能性が高い事例です。

検出例3：エンドポイントの誤りとタイムアウト欠落

外部APIとの連携処理を追加したケースでは、実装AIが仕様書にない古いバージョンのエンドポイントURLを使用し、さらにネットワークリクエストにおけるタイムアウトの設定を忘れていました。レビューAIはドキュメント（コンテキストとして与えられた仕様）と実装の矛盾を検出し、「エンドポイントがv1ではなくv2であるべきです。また、フェイルセーフのために必ずタイムアウト（例: 5000ms）を設定してください」とフィードバックを返しました。結果として、システム障害の火種をマージ前に鎮火することができました。

AIレビューの限界（静的解析）と人間の介入ポイント

静的読解の限界と「コマンド未実行」の明示

ここまでAIエージェントのループによる成果を述べてきましたが、AIレビューには明確な限界があることを忘れてはいけません。結論として、AIはコードを「静的に読解」しているに過ぎず、実際に実行環境で動かしてテストしているわけではありません。

そのため、エージェントを設計する際は「自分はコードを読んで解釈しているだけであり、コマンドを実行して動作確認をしたわけではない」というスタンスを明示するようプロンプトで要求することが重要です。これにより、AIが「テスト済みの完璧なコードです」と過剰な自信を持ってしまうハルシネーション（もっともらしい嘘）を抑制できます。動的な振る舞いやパフォーマンステストについては、別途ユニットテストやE2Eテストの自動化でカバーする必要があります。

人間（Human-in-the-loop）が担うマージ判断という最終防衛線

自動ループが「PASS」を出したからといって、そのまま本番環境へデプロイして良いわけではありません。ここで人間（Human-in-the-loop）の出番となります。

AIが担保するのは「構文的な正しさ」「仕様書との一致」「既知のアンチパターンの排除」までです。最終的なビジネス要件（本当にこの仕様でユーザー体験は損なわれないか）や、アーキテクチャの長期的な妥当性を判断し、メインブランチへマージする責任は人間が担います。AIに「指摘を潰し切る」泥臭い作業を完全に任せることで、テックリードはより高度な「設計思想のレビュー」に集中できるようになります。