AIは一次レビュー役
AIコードレビューは、人間が見る前の一次レビューへ置くと使いやすくなります。構文や典型的な不具合、変更箇所の説明不足を先に洗い出し、人は仕様、認可、事業ルール、運用影響へ時間を使う役割分担です。
| 担当 | 向いている確認 | 残る弱点 |
|---|---|---|
| 静的解析 | 構文、型、既知のルール違反 | 事業固有の認可や状態遷移を理解しにくい |
| AIレビュー | 差分の意味、複数箇所の関係、修正案 | 誤検知、見逃し、文脈不足がある |
| 人間 | 仕様、権限、運用、受け入れるリスク | 時間と担当者の知識に左右される |
GitHubの公式ドキュメントでも、Copilotのレビューは「Approve」や「Request changes」ではなく「Comment」として投稿され、必須承認には数えられません。製品側も、AIの指摘をマージ承認と分けています。
AIにレビューを依頼した事実ではなく、指摘を誰が検証し、最終判断を誰が持つかが導入設計の中心です。
製品ごとの違い
GitHub CopilotとGitLab Duoは、どちらもプルリクエストやマージリクエストへAIレビューを組み込めます。ただし、利用条件、渡す文脈、課金単位は同じではありません。
GitHubのプルリクエストやレビュー操作に慣れていない場合は、先にGitHubの基本的な使い方を確認すると、以下の設定項目を追いやすくなります。
| 観点 | GitHub Copilot code review | GitLab Duo Code Review |
|---|---|---|
| 主な対象 | Pull Request、IDE上の変更 | Merge Request |
| 依頼方法 | ReviewerからCopilotへ依頼、自動レビュー設定 | @GitLabDuoをReviewerへ割り当て、自動レビュー設定 |
| 文脈 | 差分とリポジトリ文脈。カスタム指示や対応設定も利用 | MRのタイトル、説明、変更前ファイル、差分、ファイル名、カスタム指示 |
| 大きな変更 | 文脈取得やツール利用を伴う | 入力が大きい場合、元ファイルを外して再試行することがある |
| 費用確認 | AI creditsとGitHub Actions minutes | 契約アドオン、Credits、設定で変わる |
GitHubでは、レビュー1回にモデル処理のAI creditsと、エージェント機能が使うGitHub Actions minutesの2要素があります。自動レビューを全PRへ付ける前に、月間PR数と再レビュー回数を見積もる必要があります。GitLabの公式説明は、大きなMRで元ファイルを外して再試行する場合があり、そのとき指摘の具体性が下がり得ると明記しています。
製品名だけで選ぶより、差分へどこまで文脈が渡るか、除外設定を持てるか、費用と監査ログを追えるかを比べるほうが実務的です。
導入前の4条件
最初のレビューを依頼する前に、対象、権限、データ、承認を決めます。この4点が曖昧なまま自動レビューを有効にすると、コメント数だけが増え、誰も検証しない状態になりがちです。
| 条件 | 最初に決めること | 小規模導入の例 |
|---|---|---|
| 対象 | どのリポジトリ、言語、PRを読むか | 1チームの非機密リポジトリだけ |
| 権限 | 読取、コメント、修正、外部ツール利用 | コメントまで。自動マージは禁止 |
| データ | 外部モデルへ渡せないファイル、秘密情報 | 認証情報、顧客データ、生成物を除外 |
| 承認 | 誰が指摘を検証し、誰がマージするか | コード所有者1人の承認を必須化 |
リポジトリ内の指示ファイルも確認対象です。GitHub Copilot code reviewは、.github/copilot-instructions.mdなどのカスタム指示をレビューへ反映できます。レビュー基準をそろえやすい一方、変更ブランチ側の指示が読まれるため、指示ファイル自体もレビュー対象に含める必要があります。
秘密情報をプロンプトへ書かないだけでは足りません。生成ファイル、ログ、テスト用データ、過去の設定ファイルまで、AIが取得できる経路を棚卸しします。
同じ差分で試した
TechCreateでは、認可欠落、パストラバーサル、例外の握りつぶしを埋め込んだ18行のJavaScriptを用意しました。正常な通貨コード整形も入れ、既定のESLint、Codexによる1回のレビュー、OWASP観点の人手チェックで同じ差分を確認しました。
| 手法 | 認可欠落 | パス検証 | 例外処理 | 正常コードの誤検知 |
|---|---|---|---|---|
| ESLint | 0 | 0 | 0 | 0 |
| Codexレビュー | 1 | 1 | 1 | 0 |
| 人手チェック | 1 | 1 | 1 | 0 |
ESLintはexit 0で、3件を指摘しませんでした。既定ルールでは、利用者と請求書所有者の関係や、失敗後に成功応答を返す事業上の矛盾までは扱えなかったためです。Codexは3件を指摘しましたが、短い模擬差分を作成者が採点した非ブラインドの1回評価です。実案件の検出率や製品間の優劣を示す結果ではありません。
検証から持ち帰れるのは、AIが静的解析を置き換えるという結論ではありません。静的解析、AI、人手は見ている層が違います。OWASP Secure Code Review Cheat Sheetも、自動ツールを手動レビューの補助と位置づけ、認可、事業ロジック、状態遷移などへ人の判断を残しています。
人のレビューにも思い込みは残ります。コードレビューと確証バイアスの関係で扱ったように、AIを追加する目的は判断者を置き換えることではなく、異なる見方を重ねることにあります。
最小導入の手順
全PRへの自動レビューから始める必要はありません。2週間程度の試行で、指摘の質と運用負荷を測ってから広げます。
- 代表的な小さなリポジトリを1つ選ぶ
- コメント権限だけを与え、自動修正と自動マージを切る
- セキュリティ、テスト、互換性など、見てほしい観点を5項目以内で指示する
- 10〜20件のPRで手動依頼し、指摘を記録する
- 正しい指摘、誤検知、見逃し、重複、修正時間へ分類する
- 人の承認時間が減ったか、重要な見逃しが増えていないかを確認する
- 合格したリポジトリだけ自動レビューへ進める
AIコメント
↓
根拠と該当行を確認
↓
テストまたは再現手順で検証
↓
人間が採用・却下
↓
必須レビュアーがマージ判断
AIコメントへ反射的に修正を当てると、別の不具合を作ることがあります。修正案ではなく、指摘の再現条件から確認します。
人が残す確認
AIが多くの指摘を返しても、次の項目は人が担当します。とくに「コードとして正しいが、事業ルールとして誤っている」変更は、差分だけでは判断できません。
| 確認項目 | 人が問うこと |
|---|---|
| 仕様 | 変更は利用者の要求を満たすか |
| 認証・認可 | 誰が、どの対象へ、どの条件でアクセスできるか |
| データ | 個人情報、秘密情報、保存期間、越境の条件は守られるか |
| 依存関係 | 新しいパッケージ、ライセンス、供給網リスクは妥当か |
| 障害時 | 再試行、重複実行、ロールバック、監視が成立するか |
| 運用 | デプロイ順、移行、互換性、問い合わせ対応へ影響しないか |
レビューを速くする目的は、人の確認をなくすことではありません。人が見なくてもよい表層指摘を先に処理し、仕様とリスクへ集中できる時間を戻すことです。
継続を数字で決める
AIレビューは、コメント数が多いほど成功とは限りません。正しい指摘が少なく、誤検知の確認に時間がかかれば、レビュー全体は遅くなります。
| 指標 | 計算例 | 見る意味 |
|---|---|---|
| 有効指摘率 | 採用した指摘 ÷ 全指摘 | ノイズの多さ |
| 重要見逃し | 人が後から見つけた高リスク不具合 | AIへ任せすぎていないか |
| 確認時間 | AI指摘の検証に使った分数 | 本当に時間を減らしたか |
| 重複率 | 既存lintや人の指摘との重複 | 役割分担ができているか |
| 修正後不具合 | AI提案を採用して生じた不具合 | 提案の安全性 |
最初の合格条件は、万能な数値ではなくチームごとに決めます。たとえば、重大な見逃しを増やさず、中央値のレビュー待ち時間を短くできたら対象を広げる、といった条件です。
まとめ
- AIコードレビューは最終承認ではなく一次レビューへ置くと、表層確認を先に処理し、人が仕様や認可へ集中しやすくなります
- 小規模検証ではAIがESLintの拾わない3件を指摘しましたが、1回の模擬評価です。静的解析、AI、人手を重ねる根拠として使うのが適切です
- 導入効果はコメント数ではなく、有効指摘率、重要な見逃し、確認時間、修正後不具合で判断すると、速さと安全性を同時に見られます
