← AIバイブコーディングTips 一覧へ Quality / Code Review

AIコードレビュー、現場は本当にどう感じているか

3万件超のプルリクエストを分析した実証研究によれば、AIレビューコメントの56.3%は却下される。それでも「レビューが最もレバレッジの効くスキルになった」という現場論もある。2つのソースを並べて、数字の裏側を読む。

この記事で手に入るもの

却下率56.3%・重複ゼロ93.4%という2つの実証データが示す同じ現象の読み解き方と、個人開発とチーム開発でレビュー戦略をどう変えるべきかの判断軸。

01 — 二つのソース

「効いている」と「現場は疲弊している」が同時に起きている

開発者・研究者のAddy Osmaniは自身のブログ「Agentic Code Review」で、AIによってコードを書くコストが激減した結果、ボトルネックが「書く」から「理解し検証する」へ移ったと指摘する。コードレビューは、今やソフトウェア開発で最もレバレッジの効くスキルだという主張だ。

その裏付けとして挙げられている数字が生々しい。GitClearの2025年の調査では、AI導入後に「生の出力量は4倍」になった一方で「実際に届いた価値は1割増」にとどまった。Faros AIが22,000人の開発者を対象に行った調査では、コード churn(書き直し量)が861%増加し、欠陥率は9%から54%へ跳ね上がった。レビューが追いつかず、ゼロレビューでマージされる件数も31.3%増えている。

一方、この「レビューが効くはず」という主張を、実際の開発者の反応データで検証した研究がある。arXivに投稿された実証研究は、AIレビューツールCodeRabbitのコメントに対して、開発者が実際にどう反応したかを大規模に集計したものだ。239個のGitHubリポジトリ・10,191件のプルリクエストから、31,073件のレビューコメントと開発者フィードバックのペアを分析している。


02 — 実証データの中身

却下率56.3%、そして「重複ゼロ」93.4%

2つの数字は、別々の調査から出てきたものだが、同じ現象の裏表になっている。

01

受理36.4%・議論7.3%・却下56.3%

arXivの実証研究による内訳は、受理36.4%、議論を呼んだもの7.3%、却下56.3%だった。半数以上のAIレビューコメントは、開発者に受け入れられていない。却下の主な理由は、誤検知(false positives)、冗長な指摘、スコープ外の指摘、そして開発者の意図やコーディング方針とのミスマッチ。特に「機能面の懸念」を指摘したコメントは、「将来の保守性(evolvability)」を指摘したコメントより無効判定になりやすい傾向も報告されている。

02

4つのAIレビュアーの指摘、93.4%が「1ツールのみ検出」

Osmaniの記事では別の実証データも紹介されている。CodeRabbit・Greptile・Anthropic自社のCode Reviewなど、AIレビューツールごとの精度・検出率は大きくばらつく(CodeRabbitは精度49%、Greptileはバグ検出率82%だが誤検知も多い、Anthropicの自社ツールは誤指摘1%未満で実質的なレビューコメントの割合を16%から54%まで改善させたという)。さらに4種類のAIレビュアーに同じ146件のプルリクエストを分析させたところ、指摘の93.4%が「4ツールのうち、たった1つだけが検出」——つまりツール間でほぼ重複していなかった。

ここが核心。1本のAIレビューツールに任せると見落としが多く(重複ゼロ93.4%が示すのはそういうことだ)、見落としを減らそうと複数のツールを重ねると、今度は却下されるノイズ側の指摘も増える。「量を増やせば精度が上がる」わけではないという、単純な足し算では解決しないジレンマが、この2つの数字にそのまま出ている。


03 — 開発規模で変わる戦略

個人開発とチーム開発では、必要なレビュー戦略が違う

Osmaniの記事が具体的なのは、この数字を「だからAIレビューは使えない」で終わらせず、開発の段階ごとに必要な戦略を分けている点だ。

01

ユーザーがまだいない個人開発

この段階では、レビューは軽くてよい。その代わり、しっかりしたテストと自動化に比重を置く。安全網なしで包括的なレビューを省くと、バグが後回しになるリスクはあるが、致命傷にはなりにくい規模だからだ。

02

ユーザーが増え始める移行期(一番危険)

バグ検出とナレッジ共有としてのレビューの役割が、急に重要になるタイミング。個人開発・小規模チームの習慣(軽いレビューのまま)を引きずりすぎると、この移行期にインシデントが起きやすいとOsmaniは指摘する。

03

成熟した大規模組織

すべてのリスク指標がフルで効いてくる段階。成熟したレビュープロセスを持っていても、AIが生み出すコード量そのものには追いつけない、というのがFaros AIの調査(欠陥率9%→54%)が示す現実だ。


04 — 実務への翻訳

個人開発者が、今日から変えられること

このブログでも以前、AIの「できました」を信じない検品文化暗黙知をガイドライン化したドメイン特化PRレビューを書いてきた。今回の2つの実証データは、その延長線上で「レビューをどこまでAIに任せ、どこから人間が持つか」の線引きに、具体的な数字を足してくれる。Osmaniが挙げる推奨のうち、個人開発者の運用にそのまま持ち込めるものを4つに絞ると、次のようになる。

変更の種類でレビューの深さを変える設定ファイルの変更と、課金や公開処理に関わる変更を同じ深さでレビューしない。危ない箇所だけ厚く見る。
PRを小さく保つAIが作るプルリクエストは平均51%大きくなる傾向があるという。レビューしやすさそのものを、実装時点の制約に含めておく。
テストの書き換えを疑うAIは「壊れた挙動に合わせてテストを直す」ことがある。テストが変わっているPRは、その変更が正しいか一段深く見る。
マージの最終判断は人間が持つAIレビューは「センサー」であって「判定」ではない。指摘の自信度の高さが、そのまま正しさを意味するとは限らない。

却下率56.3%という数字は、一見するとAIレビューへの不信感の根拠に見える。だが実証研究が本当に示しているのは、「AIの指摘を無条件に信じるレビュー運用」と「AIの指摘を全部無視するレビュー運用」の、どちらも同じくらい実務に向いていないという、身も蓋もない中間地点だ。