AIコードレビューで指摘される点と人が判断する点
AIコードレビューでは、どんな点が指摘され、どんな点は人が判断するべきなのか。この記事では、その線引きを整理します。
AIが得意な指摘と、事業の意図が絡むため人が決める判断を分けて考えます。新規事業のシステム開発で、発注側が確かめておきたい質問も紹介します。
AIコードレビューとは何か：人のレビューと何が違うのか
コードレビューとは、書かれたコードを書き手とは別の目で確認し、不具合や読みにくさ、設計上の問題を見つける工程です。開発では、変更内容を「プルリクエスト」という単位にまとめ、確認を依頼する流れがよく使われます。
AIコードレビューは、この確認の一部または大半をAIが担う方法です。AIが変更内容を読み、気になる箇所にコメントを返します。人が全行を読む場合と比べて、確認の待ち時間を短くしやすいのが特徴です。
AI駆動開発では「書く側」もAIになる
AI駆動開発では、コードを書くのもAIであることが珍しくありません。そのため、AIが書いたコードをAIが確認するという構図が生まれます。
この構図には注意点があります。同じ種類のAIが書いて同じ種類のAIが見ると、同じ思い込みを共有してしまい、見落としが重なる可能性があるからです。観点を分けた別の役割のAIに見させる、人が最終的に見る、といった工夫が欠かせません。AI駆動開発全体の役割分担は、AI駆動開発とは｜AIと人の役割分担と発注側の要点で整理しています。
レビュー機能そのものも各社から出ています。たとえばClaude Codeのレビューが一般提供、深さを選べるでは、レビューの深さを選べる機能を取り上げました。機能は増えていますが、何を機械的に確認し、何を人が決めるのかは、使う側が決めておく必要があります。
AIが指摘しやすい点：ルールや型がはっきりしている確認
AIが力を発揮しやすいのは、「正しい状態」を一般的なルールや過去の事例で説明できる確認です。代表的なものを挙げます。
書き方・規約・重複
変数名や関数名のつけ方がばらついている、同じ処理があちこちに書かれている、長すぎて読みにくい関数がある、といった点です。チームの書き方のルール（コーディング規約）が文章で示されていれば、それに沿っているかも確認できます。
人が毎回見るには地味で時間がかかる部分ですが、後から読む人の負担や、保守のしやすさに関わります。保守の観点はAI生成コードの保守は可能か｜引き継ぎと改修の確認点でも触れています。
よくあるバグのパターン
次のような、典型的な不具合の型は指摘されやすい部類です。
- 値が空（null）の場合を考えていない
- 配列の端や、ゼロ件・1件のときの扱いが抜けている
- エラーが起きたときの処理が書かれていない
- 後始末（接続を閉じるなど）が漏れている
- 条件分岐の書き間違い
こうしたパターンは広く知られているため、コードを読んで「この書き方は危ない」と指摘しやすい領域です。
セキュリティの定型的な見落とし
入力値をそのまま使っている、パスワードやキーがコードに直接書かれている、権限の確認が抜けている、といった定型的な見落としも指摘の対象になります。
ただし、指摘がなかったことは安全の証明ではありません。AIが生成したコードの安全性については、AI生成コードのセキュリティ｜確認点と人の役割で整理しています。また、LSCBench公開、AIのコードは安全と動作の両立が最良25%では、安全性と動作の両立が課題として示された評価の話を扱いました。レビューでAIに確認させつつ、人も見る前提で組むのが無理のない考え方です。
テストとの不整合
コードを変えたのに、関連するテストが更新されていない。テストが通るように書かれているだけで、確かめるべき内容を確かめていない。こうした点にも、AIは気づきやすい傾向があります。テストの任せ方は、AIのテスト自動生成｜任せる範囲と人が見る確認項目にまとめています。
人が判断する点：事業の意図や責任が絡む確認
一方で、コードだけを読んでも答えが出ない問いがあります。新規事業では、特にここが重要になります。
そもそも作るものが合っているか
コードが正しく動いていても、作るべきものと違っていれば意味がありません。「この機能は事業の仮説を確かめるのに必要か」「最初の利用者にとって何が大事か」は、コードの外にある判断です。
AIは渡された指示や資料の範囲で見ます。事業の意図が書かれていなければ、意図とのズレは指摘できません。仕様の伝え方はAI開発の仕様の伝え方｜作りたいものを言葉にする手順、要件の整理はAI要件定義で変わること｜AIが整理し人が決める範囲が参考になります。
書かれていない業務ルールや例外
「この顧客だけは請求日が違う」「この条件のときは担当者の承認を挟む」といった業務上の決まりは、資料に書かれていなければコードから読み取れません。AIは、書かれていない例外について、もっともらしい想定で動くコードを書いてしまうことがあります。コードとして整合していても、現場の運用とは合わないことがあるわけです。
このような点は、業務を知る人が実際の画面や動きを見て「ここは違う」と指摘するのが確実です。プロトタイプを触りながらすり合わせる進め方が有効なのは、この種のズレを早く見つけられるからです。
速度・保守・費用のどれを優先するか
レビューでは、よくある選択に出会います。
- 今は簡単な作りにして、後で直すか
- 最初から拡張しやすい作りにするか
- 画面の見た目を整えるか、動きの確認を優先するか
AIは選択肢と、それぞれの長所・短所を示せます。しかし、新規事業の段階や投資の考え方、検証したいことによって答えは変わります。どれを選ぶかは事業の判断であり、人が引き受ける部分です。
個人情報・権利・機密の扱い
個人情報の扱い、外部に送ってよい情報の範囲、生成されたコードの権利関係などは、法令や契約、社内の方針が絡みます。レビューで気づくきっかけをAIが与えることはあっても、許容してよいかの決定は人と、必要に応じて専門家が行います。関連する確認点は次の記事にまとめています。
指摘を採用するかどうか
AIの指摘がすべて正しいとは限りません。実際には問題にならない箇所への指摘（誤検知）もあれば、直すと別の機能に影響が出る提案もあります。指摘ごとに「直す」「直さない」「理由を残して見送る」を決めるのは人の役割です。
レビューの役割分担を決める：観点を分けて流れにする
ここまでの内容を、役割分担の表にまとめます。
| 確認の観点 | AIが担いやすい | 人が判断する |
|---|---|---|
| 書き方・規約・重複 | 指摘と修正案の提示 | 規約そのものの決定 |
| 典型的なバグ | 見つけて指摘 | 影響の大きさの判断 |
| セキュリティの定型的な見落とし | 一次確認 | 最終判断、重要箇所の確認 |
| テストとの整合 | 更新漏れの指摘 | 何を確かめるべきかの決定 |
| 作るものが合っているか | 資料との差異の指摘 | 事業の意図との整合 |
| 業務ルール・例外 | 書かれた範囲の確認 | 書かれていない例外の補足 |
| 優先順位・トレードオフ | 選択肢の整理 | どれを選ぶかの決定 |
流れの一例
役割分担を決めたら、レビューを工程として組み込みます。一例として、次の流れが考えられます。
- AIが実装したあと、AIが規約・典型的なバグ・テストの整合を確認する
- 指摘を修正し、修正した内容を再確認する
- 人が、仕様との合致と業務ルール、重要箇所（認証、決済、個人情報の扱いなど）を確認する
- 動く状態で、依頼側の担当者が実際に触って確かめる
最後の手順を入れておくと、コードの正しさと事業としての正しさの両方を確かめられます。工程を属人的なやり方にせず、手順として固定しておくことも大切です。担当者が変わっても確認の質が下がりにくくなるからです。
判断の記録を残す
「この指摘は、こういう理由で見送った」という記録は、後から効いてきます。見送った理由が分からないまま時間が経つと、同じ議論を繰り返したり、改修時に前提が分からなくなったりするためです。設計の意図を残す考え方は、AI設計書の自動生成は可能？後から困らない残し方も参考になります。
発注側が確かめたいこと：レビュー体制の質問
開発をお願いする側は、コードを読めなくても、レビューの進め方を確かめることはできます。次のような質問が目安になります。
- AIによるレビューと、人によるレビューをどう分けているか
- 書いたAIとは別の観点・別の役割でレビューしているか
- 認証や個人情報など、重要箇所は人が確認しているか
- 指摘を直す・見送るの判断を、誰がどの基準で行っているか
- 見送った指摘や判断の理由が記録として残るか
- 動く状態を、発注側が触って確認できる機会があるか
この中で特に大切なのは、最後の質問です。コードの中身は専門家でなければ判断しづらい一方、動く実物を触れば、業務や事業との食い違いに気づけます。納品時の確認についても、システム開発の検収とは｜納品時の確認項目と進め方で整理しています。
また、発注側にも担う役割があります。業務ルールや優先順位を判断する担当者がいないと、人が決めるべき点が宙に浮きます。その役割は、発注側のプロダクトオーナーとは｜役割と判断のしかたで解説しています。
AIの品質確認一般については、AI開発でも品質には人の確認が必要な理由も合わせてご覧ください。
まとめ
AIコードレビューは、書き方、典型的なバグ、テストとの整合、定型的なセキュリティの見落としなど、ルールや型がはっきりしている確認で力を発揮します。一方、作るものが事業の意図に合っているか、書かれていない業務ルール、優先順位の選択、個人情報や権利の扱い、指摘を採用するかどうかは、人が判断する領域です。
押さえたいのは、次の3点です。
- AIの指摘は、人が見る手間を減らすもので、判断を代わるものではない
- 書いたAIとは別の観点で確認し、重要箇所は人が見る
- 最後は動く実物で、事業との食い違いを確かめる
JustFitは、AIを活用した独自の開発基盤「LAF」を使って開発を進めています。LAFでは、要件定義・設計・DB設計・実装・テスト・レビューを専門のAIが分担し、人は「何を作るかを決めること」と「品質の最終判断」を担います。設計やレビューでも、LEGAREAの経験と品質基準にもとづいて提案とチェックを行います。AIと人の分担を整理しながら新規事業のシステムを考えたい場合は、JustFitのサービス紹介もご覧ください。