AIコードレビューのやり方｜7つの確認点

生成AIにコードレビューを頼んだら、指摘が20件返ってきた。ところが、よく読むと命名やコメントの話ばかり。業務ルールの抜けや権限の不備には触れていない。そんな経験はないだろうか。

AIによるコードレビューは、差分を読む速度が速い。人が見落としやすい境界値も候補として挙げられる。ただし、コードだけを渡して「問題を探して」と頼むと、AIは仕様を推測する。もっともらしい指摘は増えるが、採用すべき指摘かどうかを人が判定できない。

AIによるコードレビューのやり方は、良いプロンプトを一つ用意して終わりではない。仕様、変更意図、テスト結果、禁止条件を差分と一緒に渡し、7つの確認点で判定する。レビュー結果は参考意見として扱い、最終承認は人が持つ。この形なら、速さと品質を両立しやすい。

AIによるコードレビューは「差分」と「判断基準」をセットにする

GitHub Copilotの公式手順では、Copilotをレビュー担当に指定し、返されたコメントを人が確認できる。ただし、Copilotのレビューは承認や変更要求にはならず、必須レビューの承認としても数えられない。これは大事な境界である。AIは指摘を作れても、組織の承認責任までは引き受けない。

GitLab Duo Code Reviewの公式文書を見ると、レビューには変更差分だけでなく、変更前のファイル、マージリクエストの説明、カスタム指示なども使われる。大きな変更では文脈が収まりきらず、変更前の内容を外して再試行する場合もある。つまり、差分が大きいほどAIが理解できる範囲は狭くなり得る。

実務では、次の5点を一つのレビュー単位にまとめたい。

• 変更の目的と対象ユーザー
• 要件ID、受け入れ条件、禁止条件
• 変更したファイルと差分
• 実行したテストと結果
• 人に確認してほしい未決事項

7つの確認点を先に並べると、レビューの順番は次のようになる。

たとえば「申請の代理承認を追加した」だけでは足りない。「10万円未満、申請から48時間経過、登録済み代理者のみ。申請者本人への割り当ては禁止」と渡す。AIはコードと条件を照合できる。レビュー担当者も、どの指摘を採用するか判断しやすい。

確認点1：変更が受け入れ条件を満たしているか

最初に見るのは、コードの美しさではない。変更が受け入れ条件を満たすかである。

レビュー依頼には、要件を自然文だけでなく、判定できる形で添える。

• 条件：申請額が10万円未満である
• 操作：承認者が48時間操作しない
• 期待結果：登録済み代理者へ割り当てる
• 禁止結果：申請者本人へは割り当てない
• 証跡：割り当て前後の担当者を監査ログへ残す

AIには「差分の各処理を条件、操作、期待結果、禁止結果へ対応づけ、未実装または確認不能な項目だけを示す」と頼む。一般的な改善案より、仕様との不一致を先に出させる。

受け入れ条件がない場合は、レビューを始める前に止める判断も必要だ。AIに仕様を作らせて、その推測した仕様で同じAIがレビューすると、誤った前提を見抜けない。要件を構造化する考え方は、AIが読める仕様書の書き方でも詳しく整理している。

確認点2：変更範囲の外へ影響が漏れていないか

一つの修正が、別の画面やバッチ処理を壊すことはある。AIに対象ファイルだけを渡すと、この影響を見つけにくい。

変更前に、入力元、呼び出し先、保存先、通知先を短く書く。データベースの列を変えるなら、読み書きするAPI、バッチ、管理画面、集計処理を列挙する。共通部品を変えるなら、利用箇所も添える。

ここでAIへ確認させる問いは具体的にする。

• 関数の引数や戻り値を使う箇所に不整合はないか
• データ型や既定値の変更が既存データを壊さないか
• 非同期処理の再試行で二重登録が起きないか
• 画面だけ直してAPIやバッチが旧条件のままではないか
• 削除した項目をログ、集計、通知が参照していないか

変更を小さく分けることも効く。GitLabの公式文書が示すように、大きな変更では文脈を減らして再試行する場合がある。目的ごとの小さなプルリクエストへ分ければ、AIも人も判断材料を追いやすい。

確認点3：正常系だけでなく境界値と例外を試したか

AIに正常系の見本だけを渡すと、その条件に合う実装へ寄りやすい。そこで見落としたくないのが境界値だ。

金額なら9万9999円、10万円、10万1円を試す。日時なら締め日の前後、月末、タイムゾーン、夏時間を確認する。文字列なら空、最大長、多言語、絵文字を入れる。外部APIなら遅延、タイムアウト、重複応答、部分失敗を作る。

AIへ「境界値を挙げて」と頼むだけでは、候補が広がりすぎる。入力項目ごとに、許容範囲、禁止値、失敗時の処理を渡し、テストがあるかを差分から確認させる。指摘には再現手順と期待結果を付けさせる。

GitHubの責任ある利用に関する説明も、生成されたコードを特に重要・機密な用途で慎重にレビューし、テストするよう案内している。AIの指摘があること自体を品質保証にせず、実行できるテストへ落とす。

確認点4：権限と機密情報の境界を越えていないか

コードが動いても、見えてはいけない情報が見えたら不合格である。セキュリティの確認は、一般的な脆弱性一覧と業務固有の権限表を分ける。

一般的な確認では、入力検証、認証、認可、秘密情報の埋め込み、ログ漏えい、SQLインジェクション、パストラバーサルなどを見る。業務固有の確認では、「営業担当は自分の顧客だけ」「経理担当は請求情報を見られるが契約書を変更できない」のような権限表と照合する。

AIへ実データや秘密情報を渡さないことも前提だ。顧客名、メールアドレス、アクセストークン、接続文字列は伏せる。必要なら型とダミー値だけを渡す。利用するサービスが、入力したコードやレビュー文脈をどう扱うかも管理者が確認する。

セキュリティ指摘は重大度、成立条件、影響範囲、修正案をセットにする。「危険かもしれない」だけでは優先順位を決められない。逆に、重大度が高い指摘をAIの一意見として流してはいけない。人が再現し、必要なら専門レビューへ回す。

確認点5：失敗時に止まり、戻せるか

正常に完了する処理だけを見ると、本番運用で困る。外部サービスが落ちたとき、途中まで保存されたとき、通知だけ失敗したときの挙動を確認する。

見るべき点は4つある。

1. 停止条件：処理を続けず人へ渡す条件があるか
2. 再試行条件：何回、どの間隔で再試行するか
3. 重複防止：同じ処理を繰り返しても二重課金や二重送信にならないか
4. 復旧手順：途中状態を検知し、安全に戻せるか

AIには、例外を握りつぶす処理、広すぎる例外捕捉、失敗を成功として返す分岐を探させる。加えて、利用者へ表示するエラーと運用者のログが分かれているかを見る。

「エラーを捕まえているから安全」ではない。失敗後の状態が分からなければ、次の操作でデータを壊す。停止条件の考え方は、AIエージェントの停止条件にも通じる。

確認点6：指摘の根拠と再現手順が残っているか

AIレビューで厄介なのは、正しそうな誤指摘だ。採用する前に、根拠を確認できる形式へ変える。

指摘には、対象ファイルと行、問題が成立する入力、期待結果、実際に起こる結果、確信度を求める。可能なら失敗するテストも提案させる。人はテストを実行し、再現できた指摘だけを修正対象にする。

レビュー記録は「採用」「保留」「却下」に分け、理由を一行残す。却下が多い観点は指示を直す。採用された指摘でも、同じ問題が繰り返されるならコーディング規約や静的解析へ移す。毎回AIに考えさせるより、機械的に検出できるルールへ変えた方が安定する。

Googleのコードレビュー自動化ラボでは、生成AIレビューをCI/CDへ組み込む流れが示されている。自動化するなら、レビューコメントを増やすことではなく、再現可能な指摘を早く届けることを目標にしたい。

確認点7：誰が最終承認するか決まっているか

最後は人の責任分界である。AIによるコードレビューを通過したことと、本番へ出してよいことは同じではない。

実装担当は差分とテストを説明する。業務責任者は業務ルールと受け入れ条件を見る。技術責任者は設計と影響範囲を確認する。金額、個人情報、外部送信、権限変更が絡む変更は、実装者だけで閉じない。詳しい責任分担は、バイブコーディングをチームで使う前に決めるレビュー責任で整理している。

AIは一次レビューに向いている。人の前に差分を読み、疑わしい箇所を絞る。人は業務意図と残存リスクを判断する。この順番なら、人のレビュー時間を単純作業ではなく、責任ある判断へ使える。

すぐ使えるAIによるコードレビュー依頼の型

実務では、次の型をプルリクエストへ添えるとよい。

• 変更目的：誰のどの課題を解決するか
• 対象範囲：変更する機能、変更しない機能
• 受け入れ条件：入力、操作、期待結果
• 禁止条件：起きてはいけない結果
• 影響範囲：API、データ、画面、バッチ、通知
• 実行済みテスト：コマンド、件数、結果
• 重点レビュー：仕様、境界値、権限、性能など
• 未決事項：人が判断する必要がある点

AIへの依頼は「重大度の高い順に、根拠、成立条件、再現手順、修正案を示す。確認できない場合は推測と明記する」と締める。これだけでも、一般論の指摘を減らせる。

ただし、型を埋めるだけで仕様が良くなるわけではない。受け入れ条件や禁止条件が曖昧なら、コードレビューの前に要件へ戻る。Kakusillは、要件定義・設計ドキュメントをAIが理解できる構造に正規化し、仕様の品質とスピードを同時に引き上げる。レビュー可能な仕様を先に整えれば、AIも人も同じ判断基準で差分を確認できる。

AIによるコードレビューを導入しても、指摘の採否や承認が属人化しているなら、株式会社Atsumellへ相談してほしい。要件、受け入れ条件、レビュー観点、証跡のつなぎ方から一緒に設計する。

関連記事

• バイブコーディングをチームで使う前に決めるレビュー責任
• バイブコーディングで作ったコードは誰がテストするのか
• 仕様駆動開発（SDD）とは？