powered by TechFeed
表示モード
Deep Dive

AIがコードを書く速度は人間レビューの6倍 — PRボトルネックがSDLC全体を詰まらせている

6月26日、Michael Websterが「AI Works, Pull Requests Don't: How AI Is Breaking the SDLC and What To Do About It」と題した講演動画をInfoQで公開した。CircleCIのPrincipal Engineerである同氏は、AIによるコード生成の加速がSDLC(ソフトウェア開発ライフサイクル)のどこに、なぜ詰まりを生むのかをデータと数学的枠組みで示し、「AIを使えば速くなる」という直感が一時的な幻想に過ぎない可能性を突きつけている。なお、元リンク先はスライドと講演動画が一体となったプレゼンテーション形式のページであり、記事本文ではなく動画視聴が主体となる点を事前に確認しておくとよい。

6月26日、Michael Websterが「AI Works, Pull Requests Don't: How AI Is Breaking the SDLC and What To Do About It」と題した講演動画をInfoQで公開した。CircleCIのPrincipal Engineerである同氏は、AIによるコード生成の加速がSDLC(ソフトウェア開発ライフサイクル)のどこに、なぜ詰まりを生むのかをデータと数学的枠組みで示し、「AIを使えば速くなる」という直感が一時的な幻想に過ぎない可能性を突きつけている。なお、元リンク先はスライドと講演動画が一体となったプレゼンテーション形式のページであり、記事本文ではなく動画視聴が主体となる点を事前に確認しておくとよい。


AIはコードを書ける。でもPRは詰まる

AIがコードを書く速度と、人間がそれをレビューできる速度には、根本的なギャップがある。

Websterが突きつける数字は明快だ。Claudeを使えば1,500行のコードが10分(丁寧にやっても30分)で生成できる。一方、人間がPRを1時間でレビューできる上限は約500行というのが業界の経験則だ。つまりAIは、人間がレビューできる速度の6倍でコードを吐き出す。

PRのマージ待ち時間の中央値は14時間。シニアエンジニアが自分でマージを強行すれば3時間まで縮められるが、それはレビューを形骸化させているだけだ。

さらに「5行のPRには50コメント、10行には5コメント、500行にはLGTM」という現象も指摘されている。レビュアーは大きな変更を前にすると思考停止する。AIが大量生成したPRは、まさにこの罠にはまる。


ヘッドレスエージェントが静かに変えていること

問題はIDE上のコーディング支援にとどまらない。WebsterはGitHub Archiveのデータ(BigQueryでSQLクエリ可能な公開アーカイブ)を分析し、ヘッドレスエージェント(スケジュール実行やWebhookトリガーで自律的に動くAIエージェント)の台頭を定量的に示した。

エージェントが登場した当初、GitHubでの主な活動はPRレビューやIssueのトリアージだった。ところが2025年5月前後からpushイベントが急増し始め、現在はAIが「レビューを助ける」だけでなく「コードをリポジトリに直接プッシュする」フェーズに入っている。週単位でのAIのGitHub活動は数十万件規模に達している。

CircleCI内部の利用データでも同様のトレンドが確認されており、しかもこれは「READMEを更新しているだけ」ではない。パイプラインを設定して本番プロジェクトに適用している実際の顧客による利用だ。


「一時的な速度向上」という罠

では、AIは開発を速くしているのか。最新のDORAレポートはこう答えている。ベロシティは上がる。だが不安定性も上がる(障害率・変更失敗率の増加)。

さらに決定的な研究が紹介されている。数千のオープンソースプロジェクトを数カ月にわたって追跡した調査では、Cursor導入後に1ヶ月間だけベロシティが向上し、その後ベースラインに戻ったことが示された。原因として研究者が挙げたのは次の一文だ。

"We observe persistent technical debt accumulation in the changes from the AI assistants."
(AIアシスタントによる変更に、持続的な技術的負債の蓄積が観察される)

直感的に感じていた人は多いはずだが、これは因果関係としてベロシティ低下と結びつけた研究だ。


キューイング理論が示す「詰まりの数学」

Websterはここでソフトウェア工学の古典的概念、キューイング理論(仕事の到着速度と処理速度の関係を扱う数学的枠組み)を持ち出す。

講演内のシミュレーションが想定する前提は「コードを書く速度の2倍の速度でデプロイできる組織」だ。そこにAIによるスループット増加を段階的に加えていくと、シミュレーション上では75%のスループット増加を超えたあたりでPR待ち時間が理論上無限大に発散するという結果が示されている。この数値はシミュレーションの前提条件に依存するものであり、あらゆる組織に一律に当てはまるわけではないが、傾向として示唆するものは重い。

AIツールの採用率は増加し続けており、インプット速度はすでに75%増を超えている可能性が高い。しかしデリバリー速度はそれに追いついていない。結果として、AIが生み出した速度向上の恩恵は、パイプライン内の遅延にすべて吸収されてしまう。


対策として有効だったこと

CircleCIが実際に手応えを感じているのは以下の取り組みだ。

  • パイプラインの最適化:遅いスクリプトの書き直し、テストの並列化によってデリバリー側のキャパシティを底上げする
  • レビューボット:慣れないコードベースで作業する開発者向けに、スタイルガイドやルールを自動チェックする内部ツール。「ルールを決定論的に適用する」ことで、非専門家がReactリポジトリで作業する際の基本的な指摘を自動化できた。人間のレビュアーが本質的な設計判断に集中できるよう、機械的なフィードバックをボットに委譲する発想だ
  • 非エンジニアとAIのペアリング:CircleCIのダークモード実装プロジェクトでは、デザインチームがドメイン知識を持ち込み、AIが機械的な変換作業を担った。エンジニアの補助は最低限で済んだ。専門知識の持ち主がAIと直接組むことで、レビューキューを経由しなくても成果が出せることを示す事例だ

一方でWebsterは、PRの問題には解決策がまだ見えていないとも明言している。PRそのものの構造的な非効率——非同期性、サイズに関わらず必須とされる慣習——を変えない限り、AIのスループットを上げるだけでは詰まりが増すだけだ。上記の対策はあくまで現行のプロセスの中での緩和策であり、PRという仕組み自体の再設計が次の問いとして浮かび上がる。


詳細はAI Works, Pull Requests Don't: How AI Is Breaking the SDLC and What To Do About Itを参照していただきたい。