AIコードレビュー時代に人間が見るべきポイント

コードレビューの風景が変わった

AIがコードを書く時代になった。そしてAIがコードをレビューする時代にもなった。GitHub CopilotのレビューBot、Claude Codeによる自動修正、PR要約ツール。「AIが書いてAIがレビューして人間がマージボタンを押す」——そんなワークフローが現実になりつつある。

でも、ちょっと待ってほしい。人間がマージボタンを押すというその行為、本当に意味のあるレビューになっているだろうか？

AIが得意なレビュー、苦手なレビュー

✅ AIが得意なこと

• 構文チェック — タイポ、未使用変数、型の不一致。これはもう人間がやる必要はない
• パターンマッチ — 「このライブラリのこのメソッドは非推奨」「SQLインジェクションの可能性」
• スタイル統一 — コーディング規約に沿っているか。linterの延長線上
• テストカバレッジの指摘 — 「このブランチにテストがない」は機械的に判断できる

❌ AIが苦手なこと

• ビジネスロジックの妥当性 — 「この割引計算、本当にこれで合ってる？」
• アーキテクチャの方向性 — 「この変更、3ヶ月後に技術的負債になるよ」
• チームの文脈 — 「この実装、先週○○さんが別PRで同じことやろうとしてたよ」
• 「なぜこの方法を選んだか」の評価 — 代替案との比較検討はコードだけでは見えない

僕の実体験：GLMとのコードレビュー

僕は毎日GLM（Claude Code）にコーディングを任せている。で、そのコードをレビューするのが僕の仕事の一つ。

正直、GLMのコードは表面的にはきれいだ。変数名は適切、関数は分割されてる、エラーハンドリングもある。でも時々「技術的には正しいけど、方向性が違う」コードが出てくる。

例えば：

• パフォーマンスは良いけど、可読性を犠牲にしすぎている
• 完璧に動くけど、既存のユーティリティ関数を使わず車輪の再発明をしている
• テストは通るけど、エッジケースの「意味」を理解していない

これらは文脈を知っている人間にしか指摘できない。

人間のレビューはここに集中すべき

1. 「Why」のレビュー — なぜこの変更が必要か、なぜこのアプローチか。コードの「What」はAIに任せて、人間は「Why」に集中する
2. 将来の影響 — この変更が他のチームメンバー、他のサービス、将来の機能にどう影響するか
3. ユーザー視点 — コードは動くけど、UXとして正しいか？エラーメッセージは人間に優しいか？
4. セキュリティの「意図」 — AIはパターンでセキュリティホールを見つけるが、「このデータが漏れたらどれくらいヤバいか」は人間の判断

レビューの階層化

僕が最近考えているのは、レビューの階層化だ：

Layer 1と2がしっかりしていれば、人間はLayer 3に100%の集中力を使える。これが理想的な分業だと思う。

まとめ

AIがレビューしてくれるからといって、人間のレビューが不要になったわけじゃない。むしろ、人間にしかできないレビューの価値が上がった。

表面的なチェックから解放された分、「この変更は正しい方向に向かっているか？」という本質的な問いに向き合える。それってけっこう良い変化だと思う。

少なくとも僕は、GLMのコードを見るたびに「技術的に正しい≠プロジェクトにとって正しい」を実感している。