AIのコードを、別のAIにレビューさせる運用

当社のプロダクトは、実装をClaude Code、レビューを別のAI（Codex）に任せています。書いたAIと、疑うAIを分ける。この運用を数ヶ月続けて、いくつか線引きがはっきりしました。

どのPRをレビューに回すか。どう頼むか。そして、何巡で止めるか。実際の運用ルールを開示します。

三層に分けている

まず全体の構造です。当社では、AIを役割ごとに3つに分けて使っています。

設計判断はチャット（claude.ai）。何を作るか、どの方式を選ぶか、どこまでを今回のスコープにするかを、ここで決めます。コードは書かせません。

実装はClaude Code。リポジトリを直接触り、ブランチを切り、PRまで作ります。

セキュリティ上重要なPRのレビューはCodex。実装したAIとは別のAIに、敵対的な立場で読ませます。

分けている理由は単純で、書いた本人（AIでも人間でも）は自分のコードの穴が見えにくいからです。正常に動く経路を辿ってしまう。別の立場で読ませると、そこが出てきます。

全部のPRをレビューには回さない

ここが最初の線引きです。すべてのPRをCodexに回すのは、時間の無駄になります。1回のレビューに数分から十数分かかるので、色の変更やコピーの修正まで回していると、開発が止まります。

当社が回しているのは、次のどれかに当たるPRだけです。①公開エンドポイントを新設・変更するもの（認証やリダイレクトの穴が致命的になる）。②DBへ書き込むもの（権限とバリデーションの設計ミスが後から効いてくる）。③外部サービスと連携するもの（キーの扱い、失敗時の挙動）。

逆に、CSSの色替え、文言修正、静的画像の差し替えは回しません。壊れても本番で見て直せる範囲かどうか、が実質的な判断基準です。

「確認して」ではなく「壊れる場所を探せ」

頼み方も決まっています。「問題がないか確認して」ではなく、「どこが壊れるかを探せ」と頼む。前者だと「問題ありません」で返ってくることが増えますが、後者だと具体的な破壊シナリオが出てきます。

さらに、その回に見てほしい観点を先に指定します。たとえば公開エンドポイントを追加したPRなら、「オープンリダイレクトの余地がないか」「cookieの属性」「認証比較がtiming-safeか」「エラー経路で状態が変わらないか」「公開ページのキャッシュ挙動が退行していないか」といった具合です。観点を出すのはこちらの仕事で、それを検証するのがAIの仕事、という分担になります。

実際、直近のプレビュー機能の実装では、この頼み方で「編集者が確認していない内容を、確認済みと誤認する」という質の高い指摘が出ました。コードは正しく動くのに、運用上は致命的という類のバグです。

どこで止めるか

そして、いちばん書かれていないのがこれです。AIレビューは、回せば回すほど指摘が出続けます。2巡目には2巡目の指摘があり、3巡目にも何かしら見つかる。基準を決めておかないと、永遠に終わりません。

当社は、指摘が出たときに3つの問いで裁いています。①外部から悪用できるか。②公開中のサービスが壊れるか。③ユーザーに、別の内容が黙って表示されるか。このどれかに当たるなら直す。どれにも当たらないなら、課題として起票して先へ進みます。

先ほどのプレビュー実装では、最終的に3件の指摘が残りました。うち1件は③に当たったので修正。1件は「異常なクライアントでのみリダイレクトが循環しうる」というもので、頻度は低いものの、症状が分かりにくいので修正。残る1件は、同時操作で片方のセッションが中断されるというもので、誤表示はなく再操作で復旧するため起票して打ち切りました。恒久対応にはアーキテクチャの変更が要り、そのPRでやる話ではなかったからです。

修正案が「別のAPIを使った厳密な検証」のように大きくなったら、それは別のPRの話です。レビューの指摘に引きずられてスコープが膨らむと、かえってリスクが増えます。

AIレビューでは届かない場所

最後に、この運用の限界も書いておきます。

Codexが見ていたのは、あくまでコードの中の整合性でした。一方、同じ実装で最後にバグを見つけたのは、こちらが出した1つの指示です——「未公開の新規下書きだけでなく、すでに公開済みの記事を編集した下書きでも試して」。実際の運用では後者のほうが多いからですが、テストがそちらに寄っていなかった。そして、そこで公開済み記事のプレビューが全滅していることが分かりました。

「この機能は実際にどう使われるか」を持ち込むのは、まだこちら側の仕事だと感じています。裏を返せば、その一言さえ出せれば、実装もレビューもAIに任せられるということでもあります。

（このとき何が起きたかは、LOG_002に現場の視点で書いています。）