AIコードレビューを信じる前に測ったこと ― 差分だけだと重大指摘の半分が誤りだった

「AIにコードレビューをやらせています」という話は、もう珍しくありません。ただ、そこでほとんど語られないのが その指摘は当たっているのか です。もっともらしい文章は、間違っていても平気で出てきます。指摘が正しいか分からないまま導入すると、レビューが楽になるどころか「AIの指摘が正しいか確かめる作業」が増えるだけです。

そこで、自社プロダクトの実際のPR 20本にAIレビューを掛け、出てきた指摘を人が1件ずつ判定するところまでを作って測りました。結論から言うと、精度を分けたのは「AIの性能」ではなく AIに何を見せるか でした。差分だけを渡すと、重大と判定された指摘の半分が誤り。変更ファイルの全文も渡すと、その誤りは0件になりました。この記事は作り方・計測・ハマりどころを技術者向けにまとめたものです。決済者向けの要約は 実績ページの事例（AIコードレビューを、信じられる形にする） にあります。

先に断っておくと、これは 指摘の妥当性を測る検証であって、CI に組み込んだ運用ではありません。対象リポジトリには一切手を入れておらず、PRへのコメント投稿もしていません。差分を読み取り、指摘を出させ、それを別環境で採点しただけです。

なぜ「AIに何を見せるか」を変えて測ったのか

コードレビューをAIに投げる実装の多くは、gh pr diff 相当の 差分だけ をコンテキストに載せます。トークンが少なく安いからです。ただ差分は、変更行とその前後数行しか含みません。関数の定義がその外にあれば、AIには 見えていない。人間なら「この変数どこで定義されてたっけ」とファイルを開きますが、差分しか渡していないAIはそれができません。

ここが仮説でした。「見えない＝存在しない」と誤認して、それらしい誤指摘を量産しているのではないか。だとすれば、モデルを変えなくても、渡す情報を増やすだけで精度は変わるはずです。これを確かめるために、モデル（claude-opus-5）もプロンプトも固定し、渡す情報だけ を変えて同じ20本を2回レビューしました。

プロンプトで「それらしい指摘」を禁じる

AIレビューは放っておくと、当たり障りのない指摘を量産します。指摘件数は稼げますが、読む側の負荷が上がるだけです。プロンプトでは、次の3つを明示的に禁じました。

• 差分に無い箇所への指摘 ― 読んでいないコードを想像で語らせない。
• 好みの問題 ― 命名の趣味や整形の指摘をさせない。
• 再現条件の無い指摘 ― 「〜かもしれません」で終わる指摘を出させない。

構成は Laravel 13 / PHP 8.3 / SQLite の小さな検証環境です。差分は gh CLI 経由で取得し、GitHub トークンはこのアプリに持たせていません。全コールのトークンと円を記録し、月次3,000円で自動停止する上限を付けています。

結果 ― 差分だけだと、重大な指摘の半分が誤り

渡した情報	指摘	重大(high)	highの誤検知	1本あたり費用	平均時間
差分だけ	95件	4件	2件（50%）	23円	55.5秒
差分＋変更ファイル全文	86件	8件	0件（0%）	46円	61.3秒

読み方に条件があります。ここで検証したのは high（マージを止めるべきと判定された指摘）だけ です。両条件を合わせて12件、これは 全数を人が検証 しました。サンプリングではありません。medium 84件・low 91件は件数だけを事実として残し、正しさは検証していません。全187件のうち1本は指摘0件（文言修正のみのPR）でした。

差分だけを渡した条件では、highの4件中2件が誤り。典型例が「この変数はどこにも定義されていない」という指摘で、実際には同じファイルの少し上で定義されていました。差分しか見えていないので「見えない＝存在しない」と判断していたわけです。仮説どおりでした。

面白いのは、ファイル全文を渡すと 誤りが消えただけでなく、本物のhighが4件→8件に増えた ことです。誤検知が減ると同時に、見落としも減りました。文脈を持って初めて「これは本当にまずい」と判断できる指摘が、差分だけだと拾えていなかったということです。指摘の総数は95→86件とむしろ減っています。「それらしい指摘」が減り、中身のある指摘が増えた という、件数だけ見ていると読み違える動き方をしています。

代償ははっきりコストです。読ませる量が増えるので、1本あたり23円→46円に倍増しました。品質と費用はトレードオフで、「AIだから安い」で片づけず両方を測る必要があります。ちなみに全187件の種別内訳は bug 48.1% / readability 23.5% / test 13.4% / convention 12.3% / security 2.7% でした。

最初の計測は「採用率100%」だった ― 測り方を疑う

ここが今回いちばんの学びです。最初の計測では、判定した40件が すべて「妥当」 になりました。採用率100%。数字だけ見れば「AIレビュー優秀」で終われます。でもこれは 計測の作りが間違っていた 結果でした。

原因は、採点画面に AIの主張しか表示していなかった こと。人はAIの説明を読み、筋が通っていれば「妥当」と押します。もっともらしい文章は、間違っていても筋は通って見える。だから通ってしまう。実際、あとから同じ指摘をコードで確かめると、highの中に明確な誤りが混ざっていました。

作り直したのはこの3点です。

• 採点画面に一次情報（実コード）を並べる。AIの主張の下に該当コードを表示し、AIの説明ではなくコードで判断させる。
• 既定値を廃止する。「妥当」が初期選択だと、そのまま押される。未選択から始める。
• 盲検にする。差分だけ／全文ありのどちらの条件の指摘かを伏せて判定する。作った本人が測るときほど、これが効きます。

AIの「自信度」は足切りに使えなかった

AIは判定ごとに自信度（0〜100）を返します。「自信が高い指摘は人が見なくていい」という運用ができれば楽です。実際に相関を見ました。正解した42件は平均94、誤った8件は平均77。差はあります。ただ 誤りの中に92・92・95が混ざっていました。自信満々で間違えるということです。

自信度でしきって「高いものは人が見ない」とすると、自信95の誤指摘がそのまま素通りする。テキスト系のタスクでは、自信度は採否の判断材料に使えない。

この点はタスクによって挙動が変わります。別に検証した画像判定（サイト外観のAIチェック）では、逆に自信度が正誤をきれいに分けてくれました。自信度が使えるかどうかは、タスクごとに実測しないと分かりません。「自信度で足切り」という設計は、そのタスクで自信度と正誤が相関して初めて成立します。今回のコードレビューでは成立しなかった、というのが答えです。

テストが0件のモジュールに、テストを生成する

同じ仕組みで、テストが1件も無かった純粋ロジック（1,012行・1モジュール） にテストを生成しました。プロダクト全体ではなく、Before/After がはっきり出る1モジュールに絞っています。生成テストは対象リポジトリに入れず、独立した vitest 環境で走らせて計測しました。

	Before	After
テスト	0件	106件（全通過・失敗0）
文カバレッジ	0%	87.1%（203/233）
関数カバレッジ	0%	100%（27/27）
分岐カバレッジ	0%	86.5%

ここで重要なのは「生成した」ではなく「実際に走らせて全通過を確認した」ことです。AIが吐いたテストは、そのままでは通らないものも混ざります。走らせて初めて数字になります。

もう1つ、設計上こだわった挙動があります。AIに「書けない」と言わせることです。型定義のみで実行時コードを持たないモジュール（ruleSet.ts）に対して、AIは「振る舞いテストは書けない」と申告してきました。無理にそれらしいテストをでっち上げず、分からないものを分からないと言う。この一言が出せるかどうかは、信用できる自動化かどうかの分かれ目だと思っています。

測っていないので、書かないこと

数字を出すからには、測っていないことも並べておきます。

• レビュー工数が何%減ったか ― 人がレビューに使う時間を測っていません。
• 不具合の流出が減ったか ― 導入前後の障害件数を比べていません。
• AIレビュー全体の精度 ― 検証したのはhigh 12件のみ。medium 84件・low 91件の妥当性は出していません。
• CIに組み込んだ効果 ― CI連携は実装しておらず、ローカル実行のみです。
• 生成テストが将来のバグを捕まえるか ― 生成直後で実績がありません。

他の案件に持っていける設計

• 精度を上げる前に、入力の設計を疑う。モデルを変える前に「AIに何を見せているか」を変えて効果を測る。今回はそれだけで重大な誤検知が半分→0件になりました。
• 人の判定は、判断に効く層だけに絞る。全187件を人が見るのは続きません。マージ可否に直結するhighだけを全数、それ以外は件数だけを残す。
• 採点画面に一次情報を並べる。AIの主張だけを見せると、もっともらしさで通ってしまう。実コードを併記し、既定値を廃し、盲検で測る。
• 自信度は、使う前にそのタスクで相関を測る。使えるタスクと使えないタスクがあります。

「AIレビューを入れました」で止めると、指摘が正しいか分からないまま確認の手間だけが増えます。今回いちばん効いたのは、モデルの選定でも凝ったプロンプトでもなく、指摘が当たっているかを人が検証する仕組みを先に作ったことでした。そこがあって初めて「差分だけだと半分外す」という、運用を左右する事実にたどり着けました。

事例の要約（非エンジニア・決済者向け）は 実績ページ に、AI活用の他の事例は AI活用ページ にまとめています。レビュー負荷が高いチーム、テストが薄いまま育ったコード、品質を落とさず開発速度を上げたい案件へのご相談は お問い合わせ から。