6月26日、Addy Osmani（GoogleのChrome DevRelリード。『Learning Chrome DevTools』などの著者としても知られる）が「Agentic Code Review」と題した記事を公開した。AIエージェントが生成するコードの急増によってコードレビューが工学上の最重要スキルとなった現状と、その実践的な対処法について詳しく論じている。
「4倍のコード、1割増しの価値」という現実
エンジニアリングの難所が「コードを書くこと」から「そのコードを信頼してよいか判断すること」に移った、というのがこの記事の核心だ。
GitClearの2025年データによると、AIを日常的に使う開発者は非使用者の約4倍の生コード量を生み出す。しかし自分自身の1年前と比較した実質的な生産性向上は**約12%**にとどまる。つまり「4倍のコードを書いて、1割ちょっと多く価値を届けている」という状況だ。その差分はすべてレビュー工数として積み上がっている。
この問題を数値で最も鮮明に示したのが、Faros AIの調査だ。4,000チーム・2万2,000人の開発者を対象にしたもので、AIの採用度が上がるにつれて以下の変化が観測された。
- コードチャーン（書き直し・削除）：861%増
- インシデント対PR比率：242.7%増
- 開発者一人あたりの欠陥率：9%→54%
- レビュー所要時間の中央値：441.5%増
- レビューゼロでマージされたPR：31.3%増
Osmaniが特に重視するのが最後の数字だ。「誰もレビューをやめようと決めたわけではない。レビュアーが物量に追いつけなくなり、コードが未読のままマージされることが当たり前になった」と指摘する。成熟したエンジニアリングプロセスを持つチームも同様の打撃を受けており、「良いプロセスが守ってくれるわけではなかった」と述べている。
※編集部の考察：「誰かが手を抜いた結果」ではなく「物量が正常な判断力を上回った結果」という視点は重要だ。プロセスや文化の問題に帰責するだけでは、構造的な解決策にたどり着けない。
「誰が使うか」で正解は変わる
記事が強調するのは、「コードレビューの正解はチームの状況によって根本的に異なる」という点だ。Osmaniは判断軸として以下の3変数を挙げる。
- ブラスト半径：壊れたときの影響範囲は？（無風か、PII流出・金銭的損失か）
- コードの寿命：来週捨てるプロトタイプか、5年以上維持するシステムか
- 理解する必要がある人数：自分一人か、チームで共有するか
ソロ開発者が「テストが通ればシップ」という運用をするのは合理的だ。ただし「ユーザーがいないことはレビューを省略する許可だが、検証を省く許可ではない」とも釘を刺す。
逆に、大規模・長寿命のコードベースに同じ運用を適用すれば「緑のチェックマークが付いたインシデント生成機」になる、とOsmaniは表現している。この3変数の整理は、「うちのチームはどこに位置するか」を問い直す実践的な出発点として機能する。ツールや運用の選択より先に、この問いに答えておくことが重要だというのがOsmaniの立場だ。
エージェントのPRが抱える構造的問題
ここが記事でもっとも鋭い指摘だ。
人間がコードを書く場合、意図は自然に伴ってくる。なぜそう実装したか、何を却下したかが著者の頭の中にあり、レビューはその推論を検証する作業だった。
現代のエージェントも推論はする。思考トレースを残し、選択肢を比較し、説明もする。しかしその推論はdiffが生成された瞬間に捨てられる。PRには添付されず、「何のための変更か」という人間の判断も含まれていない。
arXivに掲載された2026年の論文「AI Slop and the Software Commons」では、RedditおよびHacker Newsの計15スレッドから収集した1,154件の開発者の投稿・コメントを分析している。その中にある開発者の言葉が印象的だ。
エージェントのPRをレビューすると、「このコードを初めて目にする人間」が自分だと気づく。
意図・文脈・却下した選択肢のすべてが失われた状態で、レビュアーはコードの正しさだけでなく「そもそもこの変更をすべきだったか」まで一から判断しなければならない。これはレビューというより、見知らぬコードの監査に近い作業だ。
Osmaniの処方箋はシンプルだ。エージェントに「何をしようとして、何を却下したか」を明示させ、それを決定ログとしてPRに残す。これはツールの問題であり、ツールの問題は解決できる、と述べている。
AIレビューツールは「1つ選ぶ」より「2つ並列で走らせる」
AIレビューツールについては、実測データが示す結論が面白い。
あるエンジニアがCodeRabbit、Sentry Seer、Greptile、Cursor BugBotの4ツールを146件のPRに対して並列実行した結果（679件の指摘）：
617カ所の指摘のうち、93.4%はいずれか1ツールだけが検出。2ツールが同時に検出したのは6%。4ツールすべてが同じ行を指摘したケースはゼロ。
各ツールはアーキテクチャが異なり、得意な欠陥パターンが重ならない。Osmaniの結論は「最善の1ツールを選ぶのではなく、異なる設計の2ツールを並列で走らせる」だ。
なおAnthropicの事例では、AIレビュー導入後に「実質的なレビューを受けるPRの割合」が**16%から54%**に上昇した。大多数の変更が「ちらっと見てApprove」で終わっていた現実が浮き彫りになる数字だ。
※編集部の考察：93.4%が単独検出という数字は、「どのツールが優れているか」という問い自体が間違っている可能性を示唆している。ツール選定のベンチマーク記事が多数存在するが、並列運用という発想はまだ普及していない。コストとノイズの増加をどう管理するかが次の実務的課題になるだろう。
本質的な結論
Osmaniの立場はAI否定ではない。自身もClaude CodeやCodexを使ってオープンソースプロジェクトのPRキューをトリアージしていると明かしている。
ただし「AIがAIをレビューすれば十分」とも言わない。「このコードを作るべきだったか」という判断は人間が担うべきであり、それが今もっとも価値のある仕事だ、というのが記事の結論だ。コード生成が自動化された時代において、エンジニアに残された最も重要な能力は「何を作るべきか」を判断し、「それが正しく作られたか」を検証することだ——という主張は、AIツールの活用論として現時点でも有効な指針となる。
詳細はAgentic Code Reviewを参照していただきたい。
