AIにコードレビューさせたら精度がすごかった
最近、コードレビューの一次チェックをAIに任せている。使っているのはCodex。結論から言うと、精度がかなり高い。
きっかけ
PRのレビューが溜まる。チームメンバーのコードを見る時間が足りない。でもレビューを雑にすると後で問題になる。
この状況を改善するために、AIに一次チェックを任せることにした。人間は二次レビューで設計意図と運用影響を見る、という分担。
最初は「AIにレビューなんて」と半信半疑だったが、実際に数週間運用してみて考えが変わった。機械的に検出できる問題は、人間よりAIの方が確実に拾う。
実際の精度
驚いたのは、セキュリティ系の指摘が的確なこと。
CSPヘッダーの設定漏れ、OGPメタデータの不整合、Cookie同意バナーのNPA復帰処理の欠如。このサイトのレビューでも、人間が気づかないポイントをAIが拾ってきた。
特に印象的だったのは、Consent Mode v2の実装で「同意を拒否してから承認に戻した時に、非パーソナライズ広告フラグがリセットされない」という指摘。これは実際にバグだった。
他にもいくつか具体例がある。Terraformのセキュリティグループ定義で、0.0.0.0/0からの全ポート許可が残っていた件。差分が大きいPRだと、こういう1行の見落としが起きやすい。AIは差分の大きさに関係なく同じ精度でチェックするから、こういうケースに強い。
もう一つ。Next.jsのAPIルートで、ユーザー入力をそのままSQLクエリに埋め込んでいた箇所。プレースホルダーを使うべきところをテンプレートリテラルで直接展開していた。レビュアーの目視では、前後の正常なコードに紛れて見落としやすいパターンだった。
AIが得意なレビュー
AIが得意なのは以下の観点。
網羅的なチェック。人間は疲れると見落とすが、AIは全行を同じ精度で見る。アクセシビリティのaria属性漏れ、メタデータの欠落、型の不整合など、機械的にチェックできる項目は圧倒的にAIが強い。金曜の夕方でも月曜の朝でも同じ品質で見てくれる。
ベストプラクティスとの照合。「AdSense審査に必要な要件」「GDPR対応のチェックリスト」みたいな知識ベースの照合は、AIの方が正確で速い。人間がドキュメントを引っ張り出して確認する時間を丸ごと省ける。
一貫性のチェック。ファイル間でスタイルが統一されているか、命名規則が守られているかを横断的に見る作業もAI向き。100ファイルを横断して命名の揺れを検出するのは、人間には現実的に無理だ。
パフォーマンス系の指摘。N+1クエリ、不要な再レンダリング、メモ化の欠如。こうしたパターンマッチで検出できるパフォーマンス問題は、AIが安定して見つけてくる。特にReactコンポーネントでuseEffectの依存配列に過不足がある指摘は、実際に何度か助けられた。
AIが苦手なレビュー
逆にAIが苦手なのは、設計判断の妥当性。
「この設計で将来の拡張に耐えられるか」「チームの運用体制を考えるとこの方式は現実的か」みたいな判断は、文脈を深く理解していないと難しい。ここは人間の仕事。
あと、ビジネスロジックの正しさ。仕様書と照合して「この分岐条件は要件を満たしているか」を判断するのは、まだ人間の方が信頼できる。
具体的に苦手なケースをもう少し挙げると:
トレードオフを伴う判断。「ここはパフォーマンスを犠牲にしてでも可読性を優先すべき」みたいな判断は、チームの技術レベルやコードベースの特性に依存する。AIはパフォーマンス最適化を機械的に提案しがちだが、それが本当に必要かはチームの事情次第。
暗黙的な前提への理解。例えば「このAPIは将来廃止予定だから、新しいコードでは使わない方針」みたいなチーム固有のルール。AIはコード上に書いてある情報しか見えないから、こういう暗黙知は拾えない。
過剰指摘の問題。AIは可能性のある問題をすべて列挙しがちで、実運用では問題にならない指摘が混じることがある。ノイズが多いとレビュー自体の信頼性が下がるから、この点は注意が必要。
運用のコツ
レビュー観点を明確にする
「コードを見て」だけだと、AIの出力がぼやける。「AdSense審査の観点で」「セキュリティの観点で」「アクセシビリティの観点で」と観点を絞ると、精度が上がる。
自分の場合、レビュー依頼のテンプレートを作っている。「セキュリティ」「パフォーマンス」「アクセシビリティ」「コーディング規約」の4観点を順番にチェックさせる。一度に全部やらせるより、観点ごとに分けた方が指摘の質が高い。
指摘の重要度を分類させる
「高・中・低」で分類させると、優先順位がつけやすい。全部同じ重みで指摘されると、重要な問題が埋もれる。
さらに「必須修正」と「推奨修正」を区別させると、PRをマージするかどうかの判断がしやすくなる。セキュリティ系の指摘は必須、コーディングスタイルの指摘は推奨、みたいに分けさせている。
反復レビュー
修正したら再レビュー。指摘がゼロになるまで繰り返す。この反復が効く。人間相手だと何度もレビュー依頼するのは気が引けるけど、AIなら遠慮なく回せる。
3回くらい回すと指摘がほぼゼロになる。この段階で人間のレビューに回すと、設計面の議論に集中できて効率的。
コンテキストを渡す
レビュー対象のコードだけでなく、関連するファイルや設定も一緒に渡す。例えばフロントエンドのコンポーネントをレビューするなら、呼び出し元のページコンポーネントやAPIの型定義も含める。文脈が広がるほど、指摘の質が上がる。
人間レビューとの使い分け戦略
不要ではない。AIレビューは「機械的に検出できる問題」を潰すためのもの。設計の妥当性、運用の現実性、チームの文脈を考慮した判断は人間にしかできない。
具体的な分担としては、こう整理している:
AIが担当する領域: セキュリティパターンの検出、コーディング規約の遵守、型の整合性、依存関係の問題、アクセシビリティの基本チェック、パフォーマンスのアンチパターン検出。
人間が担当する領域: アーキテクチャの妥当性、ビジネスロジックの正しさ、命名の適切さ（ドメイン知識が必要な場合）、チーム方針との整合性、運用負荷の評価。
この分担で運用して1ヶ月ほど経つが、レビューの品質が上がって、かつ人間の負荷が減った。特に「レビュー待ち」の時間が大幅に短縮されたのが大きい。AIは即座にレビューを返してくれるから、PRがキューに溜まる問題がなくなった。
人間のレビュアーは、AIが潰しきった後のコードを見ることになるから、細かい指摘に時間を取られず、設計レベルの議論に集中できる。レビューの質も上がるし、レビュアー側のストレスも減る。
AIレビューを導入して一番変わったのは、レビューに対する心理的ハードルが下がったこと。「まずAIに見てもらう」が当たり前になると、PRを出す前に自分でも品質を意識するようになる。結果として、チーム全体のコード品質が底上げされた実感がある。
関連記事
他の記事
ブラウザ横スクロールアクションゲーム開発記｜TypeScript×Canvasで作るネオンランナー
HTML5 CanvasとTypeScriptで横スクロールアクションゲーム「ネオンランナー」を自作した。物理エンジン、衝突判定、操作性の工夫を解説する。
ブラウザで遊べるテトリス風パズルをTypeScriptで作った話
HTML5 CanvasとTypeScriptでテトリス風ブロックパズルを実装した。エンジンとUIを分離するSnapshotパターンや、ネオン演出のこだわりを解説する。
ゲーム実況のサムネイル作りで学んだデザインの基本
非デザイナーがゲーム配信のサムネイルを自作し続けて気づいた、視認性・配色・構図の基本ルール。試行錯誤の記録。
配信のコメント欄が動いた瞬間の話。ゼロからイチの体験
ゲーム配信でコメントがゼロの日々を超えて、初めてリアルタイムでコメントが来た瞬間の話。ゼロからイチの体験がモチベーションを変えた。