AIを活用した開発で、みなさんはどこまでコードレビューしていますか？

良い問いだと思います。私も同じ構成（ChatGPT / Claude / Copilot）で開発しているので、運用している基準と実際にやらかした失敗を共有します。

レビューの強度を「壊れたときの被害」で分けています

全部を同じ熱量でレビューすると疲れて続かないので、私は壊れたときの被害の大きさで3段階に分けています。質問者さんの基準とかなり近いです。

• 必ず精読する：認証・認可、課金・決済、データの更新/削除、外部に出る入出力（メール送信やWebhookなど）。ここは1行ずつ追います。
• ロジックだけ確認する：ビジネスルールが絡む処理。実装の細部より「仕様通りか」を見ます。
• 流し読みでよい：見た目のスタイリング、定型的な型定義、ボイラープレート。ここは時間をかけません。

レビューを「省略」はしないが、やり方を変えている部分

完全に省略する部分はありませんが、目視を減らす代わりにテストや型で機械的に担保するようにしています。

• バリデーションは目視より、異常系のテストを書いて落ちることを確認する
• DB周りは型（schema）とマイグレーションのレビューを厚くして、個々のクエリは挙動で検証する

特にSQL・データ更新処理を必ず検証するという点、強く同意します。ここは私も一番神経を使う部分です。

実際に遭遇した失敗例

参考になればと思い、恥ずかしいものも含めて挙げます。

1. 認可の抜け：AIが生成したAPIが「ログイン済みかどうか」はチェックしていたのに、「その人がそのリソースの持ち主か」を確認していませんでした。他人のデータが取れる状態になっていて、レビューで気づきました。認証はOKでも認可が漏れる、という典型例です。

2. N+1クエリ：CRUDの一覧取得で、見た目は正しく動くのにループ内でクエリを投げていて、データが増えてから急に重くなりました。「動く」と「運用に耐える」は別だと痛感しました。

3. テストの共犯関係：実装とテストを同じAIに続けて生成させたら、間違った実装に合わせた間違ったテストが出てきて、両方グリーンで通ってしまいました。それ以来、テストケースの「観点出し」だけ先にAIにやらせて、期待値は自分で書くようにしています。

まとめると

AIで生成速度が上がった分、ボトルネックが「書く」から「読む・検証する」に移った感覚です。なので私の中では「レビューを減らす」より「レビューすべき所に集中できるよう、それ以外を自動化する」という方向に落ち着いています。

質問者さんの4つの基準はかなり堅実だと思うので、あとはN+1のような性能面と、実装とテストを別々の視点で作るあたりを足すと、さらに穴が減るかもしれません。

みなさんは AI が生成したコードをどの程度レビューしていますか？
レビューを省略している部分はありますか？
AI 開発で実際に遭遇したトラブルや失敗例はありますか？

基本的なこととして心に留めておくべきはことは、少なくとも現時点では AI に丸投げして完璧なコードができることはないということです。さらに、今後 AI がどのように進化しようと、AI が作った成果物に対して、AI が責任を負ってくれるいうことはあり得ないということも。

AI にコードを作ってもらう場合、AI が作ったコードはたたき台として形にしたものだとの認識を持って、そのたたき台をレビューし、理解し、検証し、最終成果物に対して、質問者さんが当事者意識を持った主体的な責任を持てるようにするという基本姿勢が重要だと思います。

AI にはペアプログラマーとしての役割を担ってもらい、力を合わせて開発を加速するという考え方を基本として、どのようにしたら効果的に AI に支援させられるかということを質問者さんが考えながら、「指示」⇒「応答」⇒「検証」⇒「改良」のループを回して開発を行い、成果物を完成させるという方向で考えるべきと思います。

なので「レビューを省略」などということはあり得ません。

上に述べた基本姿勢を守れば「AI 開発で実際に遭遇したトラブルや失敗例」はないはずです。