AI生成コードのレビュー・チェックリスト

AI生成コードは、見た目が自然かどうかではなく、再現できる証拠でレビューします。まず自動チェックを動かし、要求との一致、差分、セキュリティ、依存関係、運用への影響を追います。最後に、人が残るリスクを確認して承認します。

コーディング支援AIが作ったプルリクエストをレビューする開発者やテックリード向けです。変更の要件、リポジトリのテストコマンド、承認者が分かっていることを前提にしています。特定のスキャナーだけで安全性を保証する方法や、すべての変更に一律の侵入テストを課す方法は扱いません。

マージ前チェックリスト

[ ] ビルドまたはコンパイルが成功する
[ ] 既存テストと追加テストが成功する
[ ] 警告、lint（コード規約の自動チェック）、静的解析を確認した
[ ] 変更が要件と受入条件に一致する
[ ] 依頼外の変更、テストの削除、権限の緩和がない
[ ] 新しい依存関係の実在性、出所、ライセンスを確認した
[ ] マニフェストとロックファイルの差分を確認した
[ ] 秘密情報、個人情報、ログ出力を確認した
[ ] 失敗、タイムアウト、再試行、同時実行を確認した
[ ] デプロイ、移行、切り戻し、監視への影響を確認した
[ ] 人の承認者と残るリスクを記録した

1. まず自動チェックを再実行する

GitHubによるAI生成コードのレビューガイドは、最初に自動テストと静的解析を実行し、コンパイル結果、テスト結果、警告、エラーを確認するよう案内しています。

AIが「テスト済み」と報告していても、自分の環境またはCIで再実行します。

npm test
npm run lint
npm run build

リポジトリに用意されたコマンドを使い、テストしたコミット、実行環境、結果をプルリクエストへ残します。テストの通過は入口であり、正しい問題を解いた証明ではありません。

2. 要求と意図を確認する

同じGitHubガイドでは、生成コードが要求や設計パターン、既存の設計に合っているかを人が確認するよう説明しています。

次の観点で、変更と要求を突き合わせます。

この変更が解く問題は何か
どの受入条件を満たすか
誰がどの権限で使うか
既存の似た実装を再利用できないか
対象外のファイルや機能に触れていないか
失敗したとき、利用者には何が見えるか

要件が曖昧なら、コードを推測で直す前に要件定義テンプレートへ戻ります。

3. 差分を処理の流れに沿って読む

ファイル名の一覧だけでなく、データの流れを追います。

外部入力はどこから入るか
どこで検証し、権限を確認するか
何を保存し、どこへ送るか
エラー時に何を返すか
ログに何を残すか
削除や切り戻しをどう進めるか

AI生成コードでは、存在しないAPI、無視された制約、一見もっともらしいが誤った処理、失敗するテストの削除や無効化を探します。変更を小さく保つGit手順はAIコーディングのGit入門で確認できます。

4. リスクに合わせてセキュリティを確認する

NIST SSDF v1.1は、コードレビューや静的解析で見つかった問題を記録して優先順位を付け、実行可能コードをテストする実践項目を示しています。テスト計画では、本番で使うインフラストラクチャや技術スタックも考慮します。AI専用ではなく、任意で使う安全な開発の枠組みです。

変更	追加する確認
認証・権限	権限なし、別テナント、失効済みセッション
外部入力	長さ、形式、文字コード、インジェクション
ファイル操作	パストラバーサル、容量、ファイル形式
データベース	パラメータ化、トランザクション、移行
API・Webhook	署名、再試行、重複、呼び出し回数の制限
個人データ	最小化、マスキング、保持、削除、監査記録
LLMツール	最小権限、承認、出力検証

すべての変更に全種類のテストを課すのではなく、失敗したときの被害と元に戻せるかどうかに応じて確認範囲を決めます。

5. 依存関係は名前だけで判断しない

GitHub Dependency Reviewが扱う範囲に加え、本記事ではAIが提案したパッケージについて次も個別に確認します。

パッケージが実在するか
公式レジストリ上の名前とリポジトリが一致するか
メンテナンス担当者と更新状況
ライセンスに互換性があるか
どの間接依存関係が追加されるか
インストール時に動くスクリプト
既知の脆弱性
既存機能で代替できないか

GitHub Dependency Reviewでは、マニフェストとロックファイルの変更から、直接・間接依存関係と既知の脆弱性を確認できます。検出できる範囲は、対応するエコシステムと設定、既知の脆弱性情報に限られるため、確認の通過を安全性の証明にはしません。

6. テストそのものをレビューする

AIが実装とテストを同時に生成した場合は、テストの期待値まで実装に合わせていないかを確認します。失敗するテストが無効化されている可能性もあります。

変更前なら失敗し、変更後なら成功するか
正常例だけでなく、境界例や異常例があるか
モックが実際の契約と一致するか
認可やデータ分離を検証しているか
スナップショットの大量更新で差分を隠していないか

LLM機能のように出力が一定しない機能を測る場合は、LLM機能の評価設計も使います。

7. 運用と戻し方を確認する

コードそのものが正しくても、リリース手順に問題があれば障害につながります。

デプロイ手順:
データベース移行:
旧バージョンとの互換性:
機能フラグ:
監視する指標とログ:
アラート担当者:
切り戻しまたは前進修正:
データ復旧:

移行が元に戻せないなら、「変更を取り消せば戻る」とは書けません。互換期間、バックアップ、変換スクリプト、停止手順までレビューします。

8. AIによるレビューと人の承認を分ける

AIによるレビュー支援は、見落としの候補を増やすための補助です。変更を承認する責任者、必要な専門担当者のレビュー、残るリスク、例外の理由は人が記録します。プロンプトインジェクションを受ける可能性がある外部コンテンツやツールを扱う場合は、LLMのプロンプトインジェクション対策も確認対象になります。

プルリクエストへ残す最小限の記録

- 要件・受入条件:
- 変更対象:
- 実行したテスト:
- 静的解析・セキュリティの指摘:
- 依存関係の確認:
- 未解決のリスク:
- デプロイ・切り戻し:
- 人の承認者:

レビューの目的はAIだけを疑うことではありません。誰が書いたコードでも、同じ合格条件と証拠で判断できる状態を作ることが大切です。