AIが一つの変更に十件のコメントを付けた。そのレビューは有用だったのでしょうか。本物の不具合を見つけたのか、同じ指摘を繰り返したのか、人が確認する仕事を増やしたのかで評価は変わります。
指摘の量、見つけた不具合、確認にかかった時間を別々に測るのが出発点です。AIコードレビューの設計を踏まえ、この記事では自分のリポジトリで比較するための実験と記録表を作ります。
先に「何を見つけてほしいか」を決める
対象は、実行時の不具合、権限の誤り、仕様漏れ、保守性、表記などに分けます。書式の指摘を多く出すツールと、重大な不具合を見つけるツールを、同じ件数で比べないためです。
不具合には、根拠となる仕様、再現条件、期待する動作を用意します。「好みではない書き方」を誤りとするなら、そのチーム規約を入力条件にも含めます。仕様が不明な指摘は、直ちに正誤へ押し込まず「判定保留」にします。
GitHubの公式資料も、Copilot code reviewが存在しない問題を指摘する可能性を説明しています。提供者の説明は、自社の誤検知率や見逃し率を示すものではありません。自分たちのコードと規約で確かめる必要があります。GitHubの用途と制約
比較用の変更セットを作る
過去に修正した不具合を使う場合は、修正前の状態と差分を取り出し、原因を説明したPRコメント、修正後のコード、正解のテスト結果をレビュー入力に混ぜません。ただし公開済みのコードはモデルが学習済みである可能性を排除できないため、その制約を記録します。
合成した変更なら答えを管理しやすい一方、現実より単純になることがあります。実際の変更を、社内の許可された環境で人とAIに並行して読ませる方法もありますが、本当の不具合が全て分かっているわけではありません。
最初は、正解を用意した変更と実案件の観察を分けます。既知の不具合セットで測る「見逃し」と、実案件で後日発見された問題を同じ母数にしません。
指摘は、正誤と重複を二段階で分類する
まず同じ原因への指摘をまとめて一件にし、重複数を別記します。その後、独立した指摘を以下へ分けます。
横に長い表は、左右にスクロールして確認できます。
| 分類 | 判断の根拠 | 記録すること |
|---|---|---|
| 有効な指摘 | 仕様違反や不具合を再現できる | 対応する不具合ID、重要度、確認方法 |
| 誤検知 | 条件を満たしても問題が起きない、仕様を誤読 | 誤りと判断した根拠、確認時間 |
| 改善提案 | バグではないが、チームが価値を認める | 採否と理由。バグ検出数には混ぜない |
| 判定保留 | 仕様や再現条件が不足 | 調べる人・期限。正解扱いしない |
見逃しはコメントからは数えられません。正解セットにある不具合と、有効な指摘の対応を取り、対応がない不具合を数えます。AIが別の本当の問題を見つけたら、新発見として記録し、人が確認してから正解セットの版を更新します。
架空例：コメント12件でも、検出した不具合は6件
次は計算用の架空例です。既知の不具合が10件あり、判定保留や改善提案はないものとします。
| 記録 | 件数 |
|---|---|
| コメント総数 | 12 |
| 同じ原因の重複コメント | 2 |
| 独立した指摘 | 10 |
| 有効な指摘（それぞれ別の既知不具合に対応） | 6 |
| 誤検知 | 4 |
| 既知不具合の見逃し | 4 |
この例の適合率は6÷10＝60％、既知不具合の再現率は6÷10＝60％です。前者の分母は判定済みの独立した指摘、後者は正解セットの不具合です。偶然同じ値になっていますが、別の指標です。
判定保留がある実験では、保留数を必ず併記します。重大な不具合を見逃した場合は、全体の再現率だけで採用を決めません。権限やデータ破壊など、影響の大きい区分を別に確認します。
人の確認時間を含めて比べる
AIの実行が速くても、コメントの調査に時間がかかる場合があります。人だけのレビューとAI併用を、同じ品質・完了条件で比べます。人だけの結果も完全な正解とはせず、別途用意した正解セットと照合してください。
| 測る時間 | 含める作業 |
|---|---|
| 準備 | 差分や関連仕様をそろえ、利用可能な環境へ渡す |
| 指摘確認 | 再現、仕様確認、重複整理、誤検知の却下 |
| 修正・再確認 | 採用した指摘の修正、テスト、再レビュー |
| 運用 | 誤通知への対応、ルール・設定の保守 |
修正件数が少ないから速かった場合、見逃しの多さが理由かもしれません。時間と検出品質を並べ、単独で「何分削減」と宣言しないようにします。担当者・難易度・実施順のそろえ方は、AI導入の比較条件シートを使えます。
AIコードレビュー比較シート
変更ID／対象コミット／言語・変更規模：
正解セットの版／既知不具合IDと重要度：
渡した差分・関連仕様／意図的に伏せた情報：
ツール・モデル表示・設定・実施日：
指摘ID／重複元ID／分類／対応する不具合ID：
判定の根拠／判定者／保留理由：
指摘確認・修正・再確認にかかった時間：
見逃した不具合／後日見つかった問題：
採用する範囲／任せない判断／再評価条件：
採用は、用途を限定して判断する
定型的な不具合の検出に役立つなら、人のレビュー前の補助として採用できます。仕様の読取りで誤検知が多いなら、入力する仕様を整えるか、その指摘を通知対象から外して再評価します。確認負担が大きく、対象とする問題も見つけられないなら採用を見送れます。
「指摘なし」は「不具合なし」と同義ではありません。テスト、静的解析、人による設計・業務の確認を残し、AIがどこを補うかを決めます。公開先や学習利用の条件が許可されていない環境へ、社内コードを評価目的で持ち出さないことも前提です。
モデルや設定、リポジトリの構成が変わったら、同じ変更セットで再比較します。受入テスト仕様書の証跡欄を共用すれば、採用した理由を後から確かめられます。
資料確認日：2026年10月7日。評価方法・数値例・記録表は本稿独自の提案です。
WRITTEN BY
コメント