AIでコードレビューをする方法｜見るべきポイント

AIでコードレビューを補助するときは、レビュー対象のdiff、変更目的、関連仕様、影響範囲を揃え、確認してほしい観点を具体的にします。AIの指摘数を増やすことが目的ではありません。指摘を実際のコードと仕様へ照合し、再現できる問題、誤検知、判断が必要な懸念を分けて、人が修正・リリース判断を行います。GitHubはCopilot code reviewについて、全ての問題を見つける保証はなく、提案を人が検証すべきと説明しています。

Review前に、変更の意図と範囲を定義する

diffを渡す前に、何を変えるのか、なぜ変えるのか、どの利用者・route・APIに影響するのかをまとめます。関連Issue、受け入れ条件、データschema、security ruleがあれば一緒に用意します。repository全体を渡すだけでは、今回の変更で守るべき仕様が分からないことがあります。secret、顧客データ、不要なファイルを含めず、変更に必要な文脈だけを使います。

reviewの完了条件を先に決めます。例えば「認証なしでは更新されない」「入力の境界値で落ちない」「既存API responseを維持」のように、仕様に紐づく確認項目にします。「問題を全部見つけて」は保証できない依頼です。AIへ対象外の範囲や、判断を人に残す領域も伝えます。

Review briefで観点と出力形式を揃える

一般的な指摘を繰り返すより、コードの責務に合う観点を選びます。入力処理ならvalidation、authorization、error handling、出力ならescaping、画面ならloading・empty・keyboard、SQLなら件数やtransactionなどです。変更のない領域の見た目の好みを指摘させないよう、範囲を指定します。

依頼例：

「このdiffを関連仕様と照合してください。対象は注文一覧のfilterです。優先して、1)検索条件の境界とNULL、2)権限、3)大量行時の負荷、4)mobile・keyboard、5)既存URL queryの互換性を確認。確実に再現できる指摘だけを、file/line、前提、再現手順、期待と実際、影響、確信度で一覧にしてください。仕様を読んでも判断できないものは質問に分け、style好みと未変更コードは指摘しないでください。指摘がなければ、確認した範囲と未確認範囲を報告してください。」

この依頼の観点は例です。実際の仕様やriskに合わせて毎回調整し、AIが未読の文書やテストを確認済みと誤認していないかを確かめます。

Finding候補を事実・推測・提案に分ける

指摘ごとに、該当コード、前提、再現手順、実際の動作、期待する動作、影響範囲を照合します。AIが「潜在的な問題」と書いても、対象データや呼出し条件が成立しなければbugとは限りません。逆に、発生条件が限定されても、権限回避やdata lossのような重大影響なら優先して確認します。

表は横にスクロールできます

分類	意味	次の対応
Confirmed	仕様と再現結果で問題を確認	最小修正とregression test
Needs context	外部契約や業務条件が不明	ownerへ質問し保留
False positive	前提・呼出し経路が異なる	理由を記録し閉じる
Improvement	正しさより保守性の提案	価値と範囲を判断
Duplicate	既存findingと同じ原因	一つにまとめて追跡

severityはimpactと再現可能性に基づけ、AIのラベルだけで決めません。Low/Medium/Highなどを使う場合も、チームの定義に合わせます。小さな見た目の懸念とsecurity脆弱性を同じ優先度で並べないでください。

仕様とdiffを往復して検証する

指摘があれば、diffの該当行と仕様の根拠を開きます。AIが古いAPIや存在しないfile path、想定外の入力例を出していないか確認します。再現できる指摘は、最小のテスト、既存test、ローカル実行で条件を確かめます。実行環境がない場合は、確定bugではなく未検証候補として区別します。

変更範囲の外に問題が見つかっても、無関係な広範囲修正へ広げる前に、今回の変更がその問題を誘発したか判断します。新規コードが既存の問題を露呈した場合は、影響と別作業が必要か記録します。大きなdata migration、security設計、public API変更が必要なら、局所的な修正と同時に黙って実行せず、別Gateを置きます。

Security reviewは具体的な境界に沿って行う

securityを確認するときは、どこから入力が来て、どの権限で処理し、どこへ出力・保存・送信するかを追います。認証と認可、入力validation、出力encoding、SQL・command、path操作、secret、外部通信、log、error responseを分けて見ます。検索語に「security」と入れるだけでは十分ではありません。

例えば、client側でボタンを隠していてもserver endpointの権限確認がなければ保護になりません。入力をsanitizeしても、出力contextに合うescapeが必要な場合があります。AIの修正案も同じ境界を再確認し、新たなsecret exposureや権限変更を持ち込んでいないか見ます。指摘の根拠はコードと現行仕様から示し、一般的なチェックリストをそのまま脆弱性認定に使いません。

Test coverageとfailure pathを確認する

AI reviewは変更diffの読解に加え、テストの抜けを探す補助にも使えます。成功ケースだけでなく、失敗応答、空、境界値、並行操作、権限不足、タイムアウトなど、変更のriskに応じたケースを列挙させます。testがある場合は、期待値が仕様と一致するか、意図的に壊したとき失敗するかを確認します。testの数やcoverage率だけで品質を判断しません。

表は横にスクロールできます

変更の種類	重点ケース
入力・検索	空、境界、特殊文字、不正形式
認証・権限	未認証、権限不足、期限切れ
非同期処理	timeout、重複送信、遅延応答
保存処理	部分失敗、重複key、復旧
UI	loading、empty、error、keyboard
互換性	既存route、API、保存データ

テストで再現しないことは、ただちに問題が存在しない証明にはなりません。必要な検証手段が使えなかった場合は、何を実行できなかったか残します。AIが生成したtestは実装をなぞるだけでなく、外部から見える振る舞いを確認しているかを見ます。

AI指摘と人の判断を分離する

Copilotや他のreview agentは、コード上の候補を示す役割として使い、仕様適合、risk受容、mergeの判断は人が担います。人のreviewを不要にする根拠にはしません。指摘を一括適用せず、各修正の理由、影響、テストを確かめます。AIが「問題なし」と返しても、完了条件にあるテスト・security check・browser QAを省略しません。

レビュー記録には、対象commit、使用した仕様、確認したdiff、実行したtest、採用・却下した重大finding、未確認事項を残します。機密コードを外部サービスへ渡してよいかは契約・組織設定で確認します。AI reviewの利用自体が許可されていないrepositoryでは、送信しない方法でレビューを行います。

Architecture・互換性の影響を確認する

指摘が正しくても、提案された修正が既存APIや他の呼び出し元を壊す場合があります。変更箇所の上流・下流、互換性、data migration、error contractを確認し、直近のdiffだけで判断しないようにします。PRに必要な背景情報が足りないなら、AIに断定させず、依存する仕様や呼び出し元を確認する質問として残します。複数の指摘を一度に自動修正するとreview理由が見えにくくなるため、一件ごとに修正とtestを対応させます。

AIものさしの判断

AIコードレビューは、人間の判断を置き換えるより、一定の観点を素早く照らし、見落とし候補を絞る用途に向いています。diffと仕様が揃い、指摘を再現・検証できる場合は有効です。再現条件が曖昧、security境界が分からない、権限・API・data semanticsの変更を伴う場合は、指摘を確定事項にせず、担当者の確認へつなぎます。

一件ずつ再現し、重複指摘をまとめる

複数のfindingが同じ根本原因を指す場合は、類似表現のまま別issueへ増やさず、共通する条件と影響をまとめます。再現手順は、必要な権限、入力、実行順、環境を含め、他の担当者が追試できる粒度にします。意図した仕様か不明ならfalse positiveと即断せず、仕様ownerへ質問します。

表は横にスクロールできます

検証結果	記録する内容	完了条件
再現	commit、環境、入力、操作	同じ結果を再現できる
非再現	試した条件、前提との差	別条件の要否を判断
仕様不明	該当契約、決定者、期限	回答まで判断を保留
修正済み	diff、test、影響	regressionを確認
却下	false positive等の根拠	後から再確認できる記録

重大な指摘ほど、修正案を受け入れる前に独立した検証を行います。指摘を急いで閉じるために確認条件を弱めたり、警告やtestを無効化したりしません。

レビュー完了後は、未解決のfindingと担当者をPRやtrackerに残し、再レビューが必要な変更を明らかにします。