はじめに
PR作成時にAI（pr-agent）が自動でコードレビューする仕組みを導入した。
1ヶ月運用して760件のAI指摘を出し、全部スプレッドシートで集計した。結果、 採用率は8.2% だった。
この記事では、導入から「これは方向が違う」と判断するまでの全記録を書く。
環境
- Next.js 15 (App Router) / React 19 / TypeScript モノレポ（turborepo）
- Supabase（バックエンド）
- エンジニア8〜15人、全員がClaude Code / Cursor等のAIツールを日常使用
- 社内向けDXプロダクト
やったこと
pr-agentの導入
Qodo pr-agentをGitHub Actionsに導入した。PR作成のたびに自動でインラインコメントを投稿する構成。
-
/improve（インラインコメント形式）を採用 - Release/RC/環境間マージPRは自動除外
採用率の計測
「AIレビューは本当に役立っているのか」を数値で測りたかった。
ルールはシンプルにした：
- AI指摘を受け入れた → レビューイが「Resolve conversation」を押す
- 人間指摘を修正した → レビュアーが「Resolve conversation」を押す
- AI指摘を無視した → 放置でOK
「誰がResolveを押すか」のルール分離で、AI採用率を自動集計できるようにした。集計は週次でシェルスクリプト（gh CLI + jq）を実行し、スプレッドシートに記録した。
結果
| 期間 | AI指摘数 | AI採用数 | AI採用率 | 人間指摘数 | 人間採用数 | 人間採用率 |
|---|---|---|---|---|---|---|
| 導入前（2/20〜2/26） | 0 | 0 | - | 10 | 9 | 90% |
| 導入前（2/27〜3/5） | 0 | 0 | - | 10 | 9 | 90% |
| 3/6〜3/12 | 223 | 2 | 4% | 11 | 9 | 82% |
| 3/13〜3/19 | 137 | 22 | 16% | 5 | 4 | 80% |
| 3/20〜3/27 | 400 | 38 | 10% | 26 | 26 | 100% |
| 週平均 | 253.3 | 20.7 | 8.2% | 12.4 | 11.4 | 91.9% |
人間の指摘は週12件で採用率92%。AIは週253件出して採用率8%。
数だけは20倍出しているが、受け入れられているのは人間の2倍弱しかない。
なぜ8%だったのか
量は多いが重複が多い
AIはPR1件あたり約10件指摘する。人間は0.5件。
「型安全性」「エラーハンドリング」のような汎用的な指摘の繰り返しが多く、そのPR固有の文脈を踏まえた指摘は少ない。
有効な指摘でも無視される
集計データを見ると、内容としては有効な指摘でもResolveされていない（＝無視されている）ケースがあった。
大量の「微妙な指摘」の中に有効な指摘が埋もれてしまう。指摘が多すぎると、全部まとめて流される。割れ窓理論と同じだ。
全員がAIで実装している環境では付加価値が低い
うちのチームでは全エンジニアがAIツールを使って実装している。AIがある程度コード品質を担保した状態でPRが出てくる。
そこにさらにAIがレビューしても、新しい気づきが少ない。
GitHub Actions上のAIは事実確認ができない
pr-agentはPRのdiffだけを見て推測する。ローカルのClaude Codeならファイルを読んだりコマンドを実行したりできるが、GitHub Actions上では不可能。
初回テストで5件の指摘中3件が事実誤認だった。リリース済みのバージョンを「古い」と言い、動作確認済みのモデル名を「存在しない可能性がある」と言った。
そもそもの構造的問題
ここが本質だった。
AI導入によりコード生成量は 10倍 になった。一方、業界調査ではレビュー時間が +91% 増加し、AI生成コードのレビューには 3.6倍 の時間がかかるという報告がある。
つまり問題は「AIレビューの精度が低い」だけではない。人間のレビュー自体がAIの生成速度に追いつかない。
AIレビューの精度をいくらチューニングしても、この構造は変わらない。
同じことを言っている人たち
この問題はうちだけではなかった。
- Greptile CEO: 「AIコードレビュー市場はバブル。コメントを大量に出すツールは無効化される」
- 学術研究（22,000件のAIレビューコメント分析）: PRあたり10-20件出すツールのシグナル比率は20-30%
- Addy Osmani（Google）: 「AIが簡単なものをトリアージし、人間が難しいものに取り組む」モデルを提唱
- Riskified「LGTM 2.0」: 問題がなければ黙る「ゼロノイズ」レビューエージェントの設計
- LINEヤフー: AIがコードの90-95%を生成する環境ではボトルネックが「機能決定」に移行
共通しているのは「コードの行を見るレビューから、もっと上流へ」というメッセージだ。
じゃあどうするか
1ヶ月のデータから見えたのは、「AIの意見」で品質を守ろうとするアプローチの限界だった。
AIの指摘コメントは無視できる。しかしCIのpass/failは無視できない。
次にやろうとしていることは3つある。
テスト・静的解析のpass/failで品質を担保する
AIレビュアーの精度をチューニングすることに時間をかけるよりも、テストカバレッジと静的解析ルールの整備に投資する方が確実だと判断した。
設計合意を仕組み化する
PRレビューで初めて設計の問題が発覚するケースがあった。テーブル名とrepository名の不一致、ドメイン境界の認識ズレ。これはAIレビューでは検知できない。
実装の前に設計判断を記録し、共有する仕組みが必要だった。KAKEHASHIのDRDD（ディシジョンレコード駆動開発）が参考になる。
「記録にないパターン」を検知する
新しいテーブルや新しいAPIパターンがPRに含まれているのに、対応する設計判断の記録がない。そこを検知して「設計合意してから実装してください」と促す仕組み。これはまだ構想段階。
まとめ
採用率8%。ゼロではないが、760件出して62件しか反映されていない。
pr-agentは止めた。
AIがコードを書く時代に、人間がコードの行を1行ずつチェックするのは物理的に無理になりつつある。品質を守る手段を「コードレビュー」から「仕組み」に移す必要がある。
テスト、静的解析、設計合意。地味だけど、結局はこういうものが品質を支える。
参考
株式会社BACKSTAGEのTech Blogです。 BreakingDownをはじめとする興行や著名人などの公式アプリやライブ配信プラットフォームの開発などを行なっています。 backstage.inc
Discussion