6月24日、Leela Kumiliが「AI Is Moving up the Software Lifecycle: From Code Review to PRD Governance」と題した記事を公開した。Uber・DoorDash・CloudflareがAIをコード生成にとどまらず、PRD（製品要件文書）レビューやコードレビューなど開発ライフサイクルの上流工程にまで拡張している動向を取り上げている。
AIはコード生成の次のフェーズへ
コーディング支援AIは既に多くの開発現場に浸透しているが、大手テクノロジー企業はその適用範囲をさらに広げている。コードを書く段階ではなく、要件定義・設計・コードレビューという開発上流でAIをガバナンス層として機能させる取り組みが、実際の本番ワークフローに組み込まれ始めた。
この動きの背景には、LLMの推論能力の急速な向上がある。従来のAIは構文補完や定型コード生成には有効だったが、要件の曖昧さを検出したり、複数のシステム間の依存関係を踏まえたリスク評価を行ったりする能力は限定的だった。それが変わりつつある。加えて、AIエージェントの実用化によって「単一のチャットボットに相談する」から「複数の専門エージェントが並列でドキュメントやコードを評価する」構成が現実的になってきた。
開発コストの観点からも、上流ガバナンスへの注目は合理的だ。バグの修正コストは発見が遅れるほど指数的に増大するという原則は古くから知られており、要件定義段階の曖昧さがコードレビュー段階まで持ち越されると、手戻りコストは格段に高くなる。AIを上流に差し込むことで、このコストを構造的に圧縮しようとするのが、3社に共通する発想だ。
UberのPRDファーストパスレビュー
最も先進的な事例がUberの「First Pass PRD」アプローチだ。AIがエンジニアチームにPRD（Product Requirements Document：製品要件文書）が届く前に、その内容をレビューする仕組みである。
具体的には、AIが以下の観点でPRDを評価する。
- 明確さ（Clarity）：要件の記述が曖昧でないか
- 完全性（Completeness）：抜け漏れがないか
- 実行リスク（Execution Risk）：依存関係の欠落や矛盾した前提がないか
Uberのエンジニアリング担当者はこの取り組みについて、次のように述べている。
AIによるPM支援の素晴らしいユースケースだ。多くの人はAIと一緒にPRDを共同作成することに価値を見出しているが、より大きな価値は、問題を深く考えるための適切なコンテキストを追加し、自分では気づいていなかった社内の関連プロジェクトやリソースを引き込んでくることにある。
このモデルでは、エンジニアが最終的な判断権限を持ち、AIはあくまでPRDの初期フィルタリング層として機能する。コーディングアシスタントとしてではなく、「プロダクトドキュメントの構造化レビュー機構」としてAIを位置づけている点が特徴的だ。従来のPRDレビューは、エンジニアがドキュメントを受け取って初めて問題に気づくという事後的なプロセスだったが、このアプローチはその構造を根本から変える。
DoorDashの「信頼を稼ぐ」AIコードレビュアー
DoorDashは、エンジニアが実際にフィードバックを取り入れる社内AIコードレビューシステムを構築した。
多くの自動レビューツールが抱える問題は「ノイズが多すぎる」ことだ。的外れなコメントが大量に出力されると、エンジニアはすぐに無視するようになる。これは単なる使い勝手の問題にとどまらない。信頼を失ったツールはワークフローから排除され、投資対効果がゼロになる。DoorDashはこの課題に正面から向き合い、設計方針として「コメント数を減らし、有用なフィードバックに絞ること」を掲げた。
DoorDashのエンジニアはこう説明している。
チームは信頼を得るよう設計した。ノイズを生み出すのではなく、コメント数を減らし、より有用なフィードバックを出し、コードがリリースされる前に実際の行動変容を引き起こすことを目指した。
このシステムは、既存のレビューワークフローに直接統合されており、別ツールとして立ち上げる必要がない。レビューの遅延を減らしながら、最終判断はエンジニアに委ねる設計で、スループット向上とノイズ抑制を両立させている。「エンジニアが実際に聞く」という結果は、ツールの精度だけでなく、ワークフローへの統合度と信頼設計の賜物だといえる。
Cloudflareのマルチエージェント構成
Cloudflareはさらに踏み込んだマルチエージェントによるコードレビューを導入した。セキュリティ分析・パフォーマンス評価・正確性チェックそれぞれに専門のAIエージェントを割り当て、その出力をコーディネーション層で集約する構成だ。
Cloudflareのエンジニアリングチームはこの設計について次のように述べている。
各エージェントの責任範囲を厳密に絞ることで、汎用の単一レビュアーより専門エージェントの方が高いパフォーマンスを発揮する。
また、Cloudflareは「何をフラグとして上げるか」と同様に「何を上げないか」の定義が重要だと強調している。高シグナルなレビューを維持し、開発者ワークフローのノイズを減らすためだ。このマルチエージェント設計は、単一モデルに全てを委ねるアーキテクチャの限界を意識した上での選択であり、責任分離によって各エージェントの出力品質と説明可能性を高める狙いがある。
3社に共通するパターン
Uber・DoorDash・Cloudflareの取り組みに共通するのは、AIを開発ライフサイクル全体にわたるファーストパス評価層として機能させるモデルだ。PRD・設計・コードレビューのそれぞれの段階に自動分析のチェックポイントを設けつつ、最終判断は人間が担う構造になっている。
3社とも「AIに置き換える」ではなく「AIが先に見て、人間が判断する」という設計思想を採用している点も注目に値する。これは現時点でのLLMの信頼性限界を踏まえた現実的な落とし所であり、同時に開発者の抵抗感を下げて実際の採用率を高める効果もある。
コーディング支援にとどまっていたAI活用が、要件定義からリリースまでの継続的バリデーションへと進化しつつある。この潮流が広がれば、ソフトウェア開発プロセスそのものの設計が問い直される局面が来るかもしれない。
詳細はAI Is Moving up the Software Lifecycle: From Code Review to PRD Governanceを参照していただきたい。
