レビューのボトルネックとは、AI がコードの作成を加速させる一方で人間のレビュー能力が一定のままであるために、余剰となった作業が消えるのではなく下流に蓄積することで生じる滞留である。AI は人間がレビューできるより速く書く: ある企業の「2 倍」マンデートに関する縦断研究 はこれを、能力に制約のある導入が予測する帰結として説明し、直接報告している。調査期間中、プルリクエストの件数は 3.1 倍に増えたが、レビュアーを務める開発者の数は 1.5 倍にしか増えず、そのため需要がレビューの供給を上回り、レビュアー 1 人あたりの負荷はおよそ 2 倍になった。この論文のより広い枠組みは、AI マンデートは作業を取り除くのではなく下流へと移し替えるものであり、律速となる制約は人間の判断によってペースが決まる段階——それがどこであれ——へと移る、というものである。
用法
この論文が記録しているのは、単に膨らんだキューではなく、レビューとは 何か を変えることで対応した組織である。少なくとも 1 件の人間によるレビューを受けたプルリクエストの割合は 89% から 68% へと 21 ポイント低下した一方で、自動化された AI レビューを受けたものの割合はおよそ 19% からおよそ 84% へと上昇した——マンデートの直後に人間によるレビューを追い越しており、著者らはこれを、人間によるレビューと並行してではなく、その代わりとして自動レビューに依存する方向への段階的な移行だと説明している。
残った人間によるレビューも薄くなった。その実質的な部分——人間が書いたコメントを伴うレビュー——はプルリクエストのおよそ 39% からおよそ 21% に低下した一方で、コメントなしの承認はおよそ 50% でほぼ横ばいだった。中央値で見ると、レビュアー 1 人あたりのコメント付きレビューは月におよそ 3 件で横ばいだったのに対し、コメントなしの承認はおよそ 2 倍になった。著者らの解釈は、増えた負荷は実質的なレビューではなく、ただ承認するだけの行為にかかった、というものである。
個々の変更のレベルでは、コストは手戻りではなくレイテンシーとして現れた。作成者、月、変更の規模を統制すると、AI のラベルが付いたプルリクエストは、最初の人間によるレビューからマージまでにおよそ 20%、サイクルタイム全体ではおよそ 22% 長くかかった一方で、レビューのラウンド数と人間によるレビューのカバー率は横ばいで、変更 1 件あたりのコメントの上乗せも小さかった。著者らは、これによって競合する 2 つの説明がいずれも排除されると論じている——バグの多い変更が増えたのであればレビューのラウンドが増えるはずであり、より少ない精査でマージされた変更であればレビューも少なくなるはずである——残るのは、修正の増加を伴わないレビュアーの関与の増加である。
組織レベルでこれに対応するのは、全体のキューが実際には一度も解消されなかったということである。エンドツーエンドのサイクルタイムの 90 パーセンタイル値は 2025 年を通じて上昇し、66 時間近くでピークに達した後、2026 年には後退した。しかしレビューの深さで分解すると、実質的な人間によるレビューを受けたプルリクエストについての同じ値は、114 時間近くで独自のピークに達し、2026 年にも 73 時間前後にとどまっていて、導入拡大前の約 63 時間という水準を上回っていた。低下したのは、実質的なレビューに回される変更の 割合 であり、マンデート前のピークであるおよそ 48% からおよそ 21% になった。著者らは、この会社はより速くレビューすることによってではなく、作業を人間によるレビューを迂回させることによってペースを維持したと結論づけている。
大まかな品質の代理指標は動かなかった。マージ率は実質的に横ばいで、リバート率はむしろ低下した。論文はこれをどこまで言えるかについて慎重であり、マージとリバートは欠陥、インシデント、保守性を捉えられない短期的な指標であると指摘し、それらを健全さのお墨付きとしてではなく、急激な品質崩壊に反する証拠として読んでいる。そして、自らのデータでは見えないもの——機械のレビュアーが見落とすもの、そしてレビューが自分たちから離れていくにつれて開発者が学ばなくなるもの——を未解決の問題として挙げている。
同じ制約についての、別の視点からの実践者の報告が コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計 である。そこではコーディングエージェントを導入したチームのコミット数がおよそ 2 倍になり、その非対称性が率直に述べられている。エンジニアがレビューに費やす時間を同じように 2 倍にすることは難しく、したがってフローを変えなければ、コード品質の低下が続くというのがこの記事の主張である。さらにこの記事は、負荷が量から想像される以上に重い独自の理由を付け加えている——AI が生成したコードの欠陥は人間にとって見つけにくく、それがレビューの件数だけでなく 1 件あたりのコストも押し上げるというのである——そして、エージェントの導入目的であった生産性に対するボトルネックとして、レビュアーの負荷を挙げている。
この報告がこの研究を超えて寄与しているのは、測定ではなく対応策である。そのチームの答えは、比率の両方の項に取り組むことである。書面化したガイドラインと テスティング・スカイスクレイパー のテスト戦略によって、人間に届く前のプルリクエストの品質を高め、AI レビュアーと標準化されたエージェントスキルによって、残るレビューを高速化する。同記事は、バックエンドチームのテストコードと本体コードの行数比が 6 か月で 78.6% から 112.6% に上昇したと報告している。これは測定された比較ではなく 1 つのチームの経験であり、上記の研究と並べる際にはそのように読むべきである。ここで注目に値するのは主に、多数の組織を横断してではなく 1 つの組織の内側から、同じ診断に行き着いている点である。
3 つ目の報告は、個人の実践者がバイブコーディングについて書いた バイブコーディングのベストプラクティス：見逃してはいけないこと であり、同じ変化をボトルネックの所在の移動として捉えている。かつては実装が遅い工程だったが、エージェントがそれを数分で生み出せるようになると、制約は出てきたものの検証へと移る。しかもその量は、どのレビュアーも 1 行ずつ読むことはできないほどである。その対応策は、品質の防壁を自動化へと押し込むこと——ミューテーションテストで確認された高いテストカバレッジ、より厳しい静的解析の制限、重要なフローに対するリグレッションテストとエンドツーエンドテスト——そして、人間によるレビューをやめるのではなく、それが対象とするものを変えることである。すなわち、行単位ではなく判断単位でレビューし、境界、契約、認証、永続化、外部呼び出し、そしてエージェントが頼まれもせずに行った変更に注意を集中させる。著者はこれを測定された結果ではなく自身の実践として示しており、自身の経験では、パフォーマンスの問題のような一部の欠陥は依然として自動チェックをすり抜け、シニアエンジニアが読むことを必要としたと述べている。
関連用語
AI マンデート、コードレビューエージェント、検証負債、シグナル対ノイズ比（コードレビュー）、ランタイム監視としてのコードレビュー、最終ゲートキーパーとしての AI