開発したコードをレビューに出して、返ってきた指摘は10件。Critical 1件、High 5件、Medium 2件、Low 2件——差し戻し。
今回の実装は、AI（Claude Code）が書いたものでした。実装スピードは明らかに速い。でもレビューを通らなければ、速さに意味はありません。指摘内容を見返すと、テストの抜け、セキュリティ対策の非対称性、設計書との不整合——どれも「出す前に気づけたはずのもの」ばかりでした。
ここで浮かんだのが、「AIが書いたコードを、別のAIにレビューさせたらどうなるか」というシンプルな疑問です。
実装はClaude、レビューはCodex
私が試したのは、下記のパイプラインです。
Claude Code（Fable 5）で実装 → ChatGPT Codex でセルフレビュー → 人間がレビュー
Claude Codeは、指示を与えるとコードだけでなくテストや設計ドキュメントまで一気に生成してくれます。4本のAPI実装、83件のテストケース、8件以上の設計ドキュメント——従来なら1〜2週間かかる作業が、約2人日で形になりました。
ただし、前述のとおり「形になる」と「レビューを通る」は別の話です。
そこでCodexの出番でした。Claude Codeが生成した成果物一式——ソースコード、テスト、設計書——をCodexに渡し、「このPRをレビューしてください」と依頼しました。
Codexが返してきたもの
Codexのレビュー結果は、大きく2つに分かれていました。
1つ目は、人間レビュアーの既存指摘8件に対する解消判定。
7件を「解消」、1件を「部分的」と判定しました。人間レビュアーが出した指摘に対して「ちゃんと直っているか」を第三者視点で検証してくれたことになります。
2つ目が、人間レビュアーも見つけていなかった新規の問題を8件発見したこと。
内訳はCritical 1件、High 1件、Medium 2件、Low 4件です。
中でもCriticalの1件は深刻でした。機密情報をAPI経由で隠す設計にしていたものの、フレームワークが自動生成する別の経路からデータベースに直接アクセスすれば、その制限を迂回できる状態だったのです。
アプリケーション層のコードだけでなく、インフラ層の認可設定まで含めて見ないと発見できない類の脆弱性——実装したClaude Codeも、人間レビュアーの初回レビューも見落としていた穴でした。
他にも、異なるデータ間の整合性チェックの欠如、不正なマスタデータでUIとバックエンドの判定が矛盾するケース、負数の入力で意図しない件数を返すバグなど、実運用で問題になり得る指摘が並んでいました。
数字で見る、ビフォーアフター
レビュー差し戻し：10件 → 0件
Codexセルフレビューを挟まなかった初回提出では、人間レビュアーから10件の指摘を受けて差し戻されました。
Codexセルフレビューで見つかった問題を修正してからの再提出では、ソース実装に対する指摘はゼロ。人間レビュアーのコメントは、ドキュメントの参照パスや更新日といった軽微な修正のみ。ソースコードは一発でOKが出ました。
テスト：83件 → 96件（＋13件）
Codexのレビューを受ける前のテストは83件。Codexの指摘を反映して境界値テストやセキュリティ検証を追加した結果、最終的に96件になりました。テストカバレッジは行カバレッジ100%を達成・維持しています。
追加された13件には、不正アクセス防止（他ユーザーのデータへの横断アクセス防止）の検証、入力値の境界テスト、エラーハンドリングの網羅など、セキュリティ品質に直結するものが含まれています。
ドキュメント生成：8件以上を自動作成
今回のスコープで、AIが生成または更新したドキュメントは以下のとおりです。
- 要件定義書の機能追加（2件の要件追記）
- アーキテクチャ決定記録（ADR）の新規作成
- API仕様書・Contract定義の更新
- 動作確認記録の作成（証跡付き）
- PR説明文の作成
- テスト仕様書の作成
- 引き継ぎ資料の作成
いずれも、人間の作業は「確認して必要な修正を入れる」だけ。ゼロから書くのと確認するのでは、必要な時間が桁違いです。
工数削減：推定70〜80%
合算すると、従来7〜12人日かかっていた工程が約2人日に短縮。約70〜80%の工数削減となりました。
なぜ「別のAI」なのか
「Claude Codeにセルフレビューもやらせればいいのでは」と思われるかもしれません。
実際、試しました。しかし自分が書いたコードを自分でレビューする構造的な限界は、人間でもAIでも同じです。生成時の前提やバイアスを引きずったまま、自分の出力を評価してしまう。
別のモデル（Codex）に渡すことで、その前提がリセットされます。実装時に「こう書くべき」と判断した理由を知らない第三者が、純粋にコードの品質だけを見る。実装と検証の関心を分離するという、ソフトウェア開発では当たり前の原則を、AIのパイプラインにも適用した形です。
事実として、Codexが新規に発見した8件のうち、Critical判定のセキュリティ脆弱性はClaude Codeが実装時にまったく考慮していなかった観点でした。他ユーザーのデータへの横断アクセス防止——同じツールでは同じ死角を持つことの証左であり、異なるAIを組み合わせる意義がここに表れています。
リードタイムへの影響
工数削減だけではなく、開発サイクル全体のリードタイム短縮にも効果がありました。
レビューの差し戻しが1回発生すると、修正・再提出・再レビューで2〜3営業日のロスが生まれます。今回、Codexセルフレビューによってこの差し戻しがゼロになったことで、機能リリースまでのリードタイムが約40%短縮されました。
「レビュー指摘がゼロだった」は、単に手間が減ったという話ではありません。開発者がレビュー待ちで手が止まる時間、レビュアーが同じコードを二度見る時間——その両方がなくなるということです。
AIは道具ではなく、パイプラインになる
今回の試みで見えたのは、「AIを使う」のフェーズはもう終わっていて、「AIをどう組み合わせるか」のフェーズに入っているということです。
単体のAIに「すごい出力」を期待するのではなく、実装・レビュー・ドキュメント生成というパイプラインの中に、それぞれ得意なAIを配置する。人間は最終判断と方向修正に集中する。
実装AI → レビューAI → 人間レビュー → リリース
このパイプラインが回り始めたとき、開発の現場は「AIを使っている」から「AIで回っている」に変わります。
私たちはまだこの仕組みを1つのプロジェクトで検証した段階です。でも、10件の差し戻しがゼロになり、工数が7割減り、人間レビュアーが本来見るべきアーキテクチャや設計判断にだけ集中できるようになった——この手応えは、次のプロジェクトでも再現できると確信しています。
