AI コードレビュー：コメント数より、役立つ指摘を測る

最近の記事から考える問い

Michelle Zhou と Alejandro Carderera de Diego は、2026-10-05 に GitHub の ReviewBench 記事 ↗を公開しました。実際のプルリクエストと検証された指摘を使って AI レビュアーを評価する取り組みです。学ぶべき問いは、「どのコメントが不具合を防ぐ役に立つか」です。

以下は独自に考えた練習であり、このベンチマークの再現や特定モデルのスコアの報告ではありません。大きな本番リポジトリではなく、小さなコマンドラインツールで試せます。

指摘に証拠をつける

日付、金額、分類を受け取る CSV 支出パーサーを想定します。AI にレビューを頼む前に、期待する動作を自分で書きます。金額の不正な書式を拒否すること、正当なマイナス調整を保持すること、解析できなかった行番号を報告することです。要件を自分で決めれば、回答を独立して判断できます。

各コメントについて、該当箇所、問題を起こす入力、期待する動作、実際の動作を確認します。「失敗するかもしれない」は仮説です。誤った結果を示す最小入力が証拠になります。リファクタリングの提案なら、どの保守上の問題を解決するのかを尋ね、好みを確認済みの不具合として数えないようにします。

調査中は元の差分を残します。先に提案をすべて適用すると、役立ったコメントと新たな問題を生んだコメントを区別しにくくなります。レビュアーの自信は、再現手順の代わりにはなりません。

三つの結果を分けて記録する

意図的に不具合を入れた三つの版を用意します。正当な負の値を拒否する版、入力行番号を失う版、空の金額を誤解釈する版です。要件に従う変更なしの対照版も用意します。これは独自の例であり、攻撃手法やベンダーのテストケースではありません。

確認できた指摘、見逃された既知の問題、誤りや無関係なコメントを記録します。大量のコメントを書いても、最も重要な動作を見逃すことがあります。コメントが少ない場合も、有益な警告を絞ったのか、不具合を見逃したのかは別です。コメント数だけで勝者を決めず、これらを分けて扱います。

同じ差分と設定で、レビューを二度繰り返します。どの指摘が再現可能なまま残るかを記録しましょう。これだけで広い範囲の信頼性は証明できませんが、大きな変更を任せる前に、表現やランダム性への敏感さに気づけます。

製品のレビューが何を意味するか

GitHub の現在の利用文書 ↗は、Copilot にレビューや再レビューを依頼する方法を説明しています。コメント形式のレビューは、既定では承認に数えられません。任意の承認機能は別の設定です。これは 2026-10-11 に確認した更新される文書であり、新しいブログ記事として扱っていません。

練習では、問題の再現後、修正を受け入れる前に人が判断します。修正後のパーサーで例を再実行し、差分も確認します。三つの例に合格しても、示せるのはその例に関わる動作だけで、無関係な動作は未検証です。

確認できる成果物を作る

一枚の表に、各コメントの場所、再現入力、判定、重大度、次の対応を記します。コメントがつかなかった仕込み済みの不具合にも一行を追加してください。最後に、そのレビュアーを使い続ける理由と、追加確認が必要な場面を一つずつ書きます。公開ランキングを再現したと主張せず、具体的なレビュー習慣を作る練習です。