「プルリクエスト（PR）は死につつある」という話が回っています。Cognition、OpenAI、AI Twitterの半分――みんなが同意しているようです。つまり「コードエージェントの時代にはPRは生き残れない」と。
私は、彼らが引用している研究を読みました。データは本物です。しかし結論は違います。
ボトルネックは本物だ
Faros AIは、1,255のエンジニアリングチームと10,000人超の開発者を分析しました。数字は反論しにくいです。AIコーディングツールを使っているチームはPRを98%多くマージできている一方、コードレビューにかかる時間は91%増えています。PRのサイズも154%増加。バグ率は9%上がっています。
つまり、はい――もしあなたのチームがCopilotやCursorやCodexを導入し、その結果としてすべてのエンジニアが出力を2倍にしてしまったら、レビュー担当者は溺れます。そこは事実です。
しかし「レビュー担当者が溺れている」と「PRが死にゆく」は、まったく別の主張です。
実際に壊れているもの
問題は「プルリクエスト」が概念としてダメなのではありません。ほとんどのチームが、可変スループットを扱えるようにレビュー手順を作っていないことです。
考えてみてください。AIツールがなかった頃、チームにはおそらく暗黙のリズムがありました――たぶん開発者1人あたり1日2〜3件のPRで、それぞれ数百行です。インプットの発生率がほぼ一定だったので、レビュー担当者は追いつけました。誰かがそれを設計したわけではなく、自然なペースに落ち着いていただけです。
AIはそのペースを壊しました。今では、1人の開発者が1日に5〜8件のPRを出せます。その中には500行超のものもあります。レビュー手順は変わっていないので、破綻してしまうのです。
ですがそれは「フォーマットの問題」ではなく「プロセスの問題」です。メールが多すぎて困ったからといって、メールという形式を捨てますか？ フィルタやラベル、優先順位を作りますよね。ここでも同じです。
「PRは死んだ」陣営が間違えている3つのこと
1. すべてのチームがこの問題を抱えていると思い込んでいる。
Farosは、高いAI導入率のチーム――エージェント駆動開発に最も強く取り組んでいるチームを調べました。2026年の大多数のエンジニアリングチームは、まだそこには到達していません。何百行ものコードを、監督なしで生成する自律型コーディングエージェントを使っているわけではなく、オートコンプリートやチャットを使っています。彼らにとってはPRは問題なく機能します。ボトルネックは存在しません。
「PRは死んだ」という物語は、フロンティアの問題を取り上げて、それを業界全体に投影しています。
2. コンプライアンスを無視している。
フィンテック、医療、国防、そしてSOC 2 / ISO 27001 / HIPAAといった要件があるあらゆる業界では、人間によるコードレビューは任意ではありません。規制上のチェックボックスです。速くすることやAIで補強することはできますが、排除はできません。AIエージェントが別のAIエージェントのコードを承認しても、監査対応としては満たしません。
「PRを殺そう」陣営の誰も、この点を口にしません。おそらく、彼らの多くがAIスタートアップで働いていて、コンプライアンスとは設定画面にチェックボックスを追加することだと捉えられているからでしょう。
3. 代替案のコストを過小評価している。
Devinは1席あたり月額$500です。Managed Agentの実行は$0.08/hrに加えてトークンコストです。OpenAIのSymphonyにはElixirのインフラと、エージェントのオーケストレーションを理解しているチームが必要です。BDDによる仕様駆動開発は、計画プロセスを丸ごと書き換える必要があります。
これらはどれも無料のアップグレードではありません。5人規模のスタートアップや20人規模の代理店にとっては、「Devin ReviewとSymphonyを導入すればいい」は「PRのレビューに時間がかかりすぎる」という問いへの現実的な答えにはなりません。
実際に機能するもの
私は、ドロップシッピングの自動化を扱うオープンソースのMCPサーバーを運用しています。具体的には、商品の仕入れ、取り込み、仕入れ先の差し替え、Shopifyへの反映です。よく定義されたツール呼び出しから、構造化され決定論的な出力を生成します。私のAIエージェントがdsers_replace_mappingを呼ぶと、結果はJSONペイロードになり、信頼度スコア、バリアントの一致状況、ブロック理由が含まれます。レビュー担当者はそれを30秒でスキャンできます。
これを、400行の業務ロジックを書き換えるコーディングエージェントと比べてください。レビュー負荷はまったく別物です。
レビューのボトルネックがないチームで、私が繰り返し見ているパターンは次のとおりです。
より小さなPR。 方針のためではなく、ツールが焦点の当たったスコープ付きの変更を出力するからです。MCPツール、うまく構造化されたエージェントのタスク設計、単一責務のオペレーション。もしあなたのエージェントが500行のPRを生成しているなら、問題はタスク分解であって、レビュー手順ではありません。
機械で検証できる制約。 リンターや型システムにあるアーキテクチャルール、そしてCIのチェックで、人間が差分（diff）を見る前に構造的な問題を検知します。Bolukは、編集フォーマットを変えるだけで15のLLMが5〜14ポイント改善することを示しました。適切なハーネスは、どんなレビュー・ツールよりもレビュー負荷を減らします。
構文ではなく意図のための人間レビュー。 OpenAI Harness Engineeringの実験がまさにこれを正しく捉えています――エンジニアは計画、仕様、受け入れ基準をレビューします。コードは機械によって検証されます。ですが、だからといってPRがなくなるわけではありません。PRには仕様＋テスト結果＋diffが含まれ、人間は最初の2つをレビューする、ということになります。
実際の未来
PRは進化します。より豊かなメタデータ――エージェントの信頼度スコア、テストカバレッジの差分、アーキテクチャへの影響の要約――を運ぶようになります。diffは、より大きなレビュー成果物の一セクションになるだけで、全体ではなくなるでしょう。
あるチームは、マージ後検証付きのトランクベース開発へ移行します。あるチームは、低リスク変更はモニタリング付きで自動マージされる「段階的レビュー」を導入します。あるチームは、自社のドメインがそれを必要とするため従来のPRレビューを維持します。
起きないことは「普遍的な置き換え」です。「プルリクエストの後に何が来るか」という枠組みは、単一の後継者がいることを前提にしています。しかしそれはありません。レビュー戦略には幅があり、チームはリスク許容度、コンプライアンス要件、そしてチーム規模に基づいて選びます。
Kevlin Henneyの引用が繰り返し持ち出されます――「プログラムを曖昧さのない詳細で記述するのはプログラミングである」。これは本当であり、だからこそ仕様駆動開発がコードレビューに取って代わることはないのです。完璧な仕様を書くのは、完璧なコードを書くのと同じくらい難しい。抽象化のあらゆるレベルでレビューが必要で、ただ使うツールが異なるだけになります。
もしあなたのレビュー手順が溺れているなら、レビュー手順を直してください。PRをより小さく分解しましょう。機械チェックを追加します。意図のレビューを上流へ移動させます。しかし仕組みそのものを捨てないでください。それは、ソフトウェアエンジニアリングの中でも、すべてのチーム規模と業界にわたって規模に応じて本当に機能する数少ないものの一つだからです。
PRはウォーターフォールを生き延び、アジャイルを生き延び、マイクロサービスを生き延びました。AIエージェントの時代も生き延びます。ただし、墓場ではなく、PRの周りのツールをもっと良くする必要があるだけです。
あなたのチームではどうですか――実際にレビューのボトルネックに直面していますか？ それとも、これはまだあなたにとっては理論上の問題のままですか？
