プルリクエストへの死亡宣告は増え続けています。
Burak Dedeは記事を「The Pull Request is Dead: Surviving the AI Code Avalanche.」と題しました。Andy G.は「Pull requests are dead, long live pull requests」と書き、コードレビューは以前とは違うものでなければならないと論じています。
Bill Eastonは「Pull Requests Are Dead. Long Live Context,」を発表し、AIが一度きりの「ドライブバイ」型プルリクエストを終わらせたと主張しました。The Pragmatic Engineerは「I ship code I don’t read」という見出しでエージェント中心のワークフローを紹介し、この変化を「プルリクエストは終わった。『プロンプトリクエスト』万歳」とまとめています。
彼らが見ていたのは、変化のそれぞれ異なる側面です。Dedeは検証作業の滞留に、Andyは意思決定の理由を残すことに、Eastonはオープンソースへのドライブバイ型の貢献に注目しました。The Pragmatic Engineerが取り上げたのは、Peter SteinbergerのOpenClawワークフローです。Steinbergerはプルリクエストを「プロンプトリクエスト」と捉え、計画、アーキテクチャ、エージェントが検証した結果にレビューの重点を置いています。
死因についての見解は一致していません。それでも全員が同じ問いを投げかけています。AIがより多くのコードを生成する時代に、プルリクエストはどのような役割を果たすのでしょうか。
データが示すもの
AIエージェントや自動化システムが開発者とともにコードを書き、変更を提案するようになり、プルリクエストの数は増加しています。
エージェントは課題、チケット、インシデントを直接コード変更に変え、自動化システムは依存関係の更新や日常的なメンテナンスのためにプルリクエストを作成します。それらはすべて同じレビューキューに届きます。GitHubの数字は、そのキューがどれほど急速に拡大しているかを示しています。
マージされたプルリクエストは、2023年1月の月間2,500万件から現在の月間9,000万件へ増えました。コミットはさらに急激な変化を示しています。GitHubが2025年の1年間に記録したコミットは10億件でしたが、現在は週に2億7,500万件がプッシュされ、このペースなら今年は140億件を超える見込みです。
CodeRabbitでは、2025年11月から2026年7月までに、1人あたりのプルリクエスト数が平均59%増加しました。リポジトリあたりのプルリクエスト数も、同じ期間に平均33%増加しています。
GitHubもプラットフォーム全体でこの成長を実感しています。同社はスケーリングへの取り組みや障害をエージェント型開発の加速と結び付け、プルリクエスト、API利用、自動化、大規模リポジトリのワークロードが急増していると説明しています。1つのプルリクエストにも、Gitストレージ、マージ可能性の確認、Actions、検索、権限、Webhook、API、キャッシュ、データベースが関わります。GitHubは2026年8月17日の障害について、米国中部リージョンのロードバランサーで発生した「ネットワークの飽和」が原因だとしています。
コーディングエージェントが登場する以前から、開発者はプルリクエストが遅く、官僚的で、人間によるボトルネックに依存していると不満を抱いていました。AIコーディングエージェントは、まさにその不満を和らげるために作られたように見えました。コメント、承認、議論による足止めなしに、必要なときにコードが現れる開発プロセスを約束したのです。
このビジョンは「ジャストインタイム・ソフトウェア」と呼ばれることがあります。その名称は、事前ではなくプログラムの実行中にコードをコンパイルするジャストインタイム・コンパイルになぞらえたものです。AIに当てはめると、オンデマンドでのコンパイルからオンデマンドでのソフトウェア作成へと意味が移ります。ユーザーが必要なものを説明すると、エージェントがその場で動作するソフトウェアに変えるのです。
オンデマンドのソフトウェアは、プルリクエストの終焉をもっともらしく見せます。作成が瞬時に感じられると、レビューは遅い開発プロセスの遺物のように思えるからです。
その約束は、プルリクエストの終焉をもっともらしく見せます。作成が瞬時に感じられると、レビューは遅いプロセスの遺物のように見え、その議論はコードが本番環境で動く段階までは成立します。生成されたコードを信頼できるソフトウェアにするには、今もテスト、セキュリティチェック、そして結果に責任を負う人間が必要です。
CodeRabbitでは、提案から本番環境までソフトウェア変更を管理する仕組みをAgentic Change Managementと呼んでいます。提案された変更に独立した検証、明確な優先順位、レビュー担当者が理解できる説明を与えます。同じコンテキストはマージ後も変更に引き継がれ、チームがリスクを監視し、進化するコードベースを統制可能な状態に保つのに役立ちます。
何が変わったのか
Agentic Change Managementは独立したレビューと検証から始まり、人間の注意をどこに向けるべきかをチームが決めるのを支援します。提案される変更が増えても、レビューに使える時間は増えません。到着順が示すのは、どのプルリクエストが先に来たかだけであり、どれを先にレビューすべきかではありません。
CodeRabbit Triageは、到着順ではなく影響の大きさに基づいてプルリクエストに優先順位を付けます。重要度の高い作業は判断に必要な知識を持つ人へ送り、日常的でリスクの低い変更は自動化された経路を進みます。
Triageは最初に開くべきプルリクエストを決めますが、開いた後に何をするかまでは決めません。従来のdiffが示すのはコードが変わった場所だけで、各部分がどうつながり、システムにとって何を意味するのかはレビュー担当者が組み立て直さなければなりません。エージェントが生成するプルリクエストの規模と範囲が広がるほど、その作業がレビューに占める割合も大きくなります。
CodeRabbitのChange Stackは、プルリクエストをガイド付きの流れに再構成します。関連する変更を意味のあるレイヤーにまとめ、論理的な順序で提示し、それぞれの説明をdiffの該当行に結び付けます。図が挙動の理解に役立つ場合は、その視覚情報をコードの隣に配置します。
リポジトリとプルリクエストのワークフローはそのままです。Triageが最も重要な作業を示し、Change Stackが作成者のコンテキストに乏しい大規模な変更の理解を助けます。出荷するかどうかを決めるのは、その結果を引き受ける人たちです。
今、プルリクエストが担うもの
従来のプルリクエストは人から人への依頼であり、開発者が変更を提案し、その背後にある判断をレビュー担当者に説明するものでした。エージェントが変更を生成すると、プルリクエストを開いた人がコードを生み出した思考過程を説明できない場合があります。だからこそ、プルリクエスト自体がそのコンテキストを担わなければなりません。
実際には、作業を始めたプロンプトから出荷を決める承認まで、変更の全体像を伝える必要があります。課題は作業が存在する理由を、エージェントの活動はコードが形作られた過程を示します。テストやセキュリティの検出結果は、感覚だけに頼らず判断するための根拠になります。レビューコメントはチームが議論した内容を残し、承認は誰が出荷に同意し、本番環境でその結果に責任を負うのかを記録します。
メンテナーはルールを変え始めている
オープンソースのメンテナーは、自分のコードについて質問に答えられない貢献者からのプルリクエストを通じて、コンテキスト不足を真っ先に目にします。GitHubは6月、書き込み権限を持たない貢献者が同時に開いておけるプルリクエスト数に上限を設定できるようにすると発表し、急増への対応としてほかの変更も予告しました。
「メンテナーはオープンソースの信頼を支える層です」と、GitHubのオープンソース担当ディレクターAshley WolfはCodeRabbitに語りました。「AIによって貢献を生成しやすくなる中、メンテナーが作業を受け取り、レビューする方法について、より多くの選択肢を持てるようにしたいと考えています。
「プルリクエストは決して終わっていません。単なるコード提出から、コンテキスト、レビュー、説明責任を備えた豊かなチェックポイントへと進化しています。私たちの役割は、その進化が加速する中でメンテナーが必要なコントロールを確実に持てるようにすることです」
GitHubはその年の初めにも、プルリクエストに関する2つのアクセス制御を提供しました。メンテナーはプルリクエストを無効にしたり、作成できる人をコラボレーターに限定したりできます。これらの設定により、プロジェクトは貢献を受け入れる方法をより細かく管理できます。
GitHubより先に動いたプロジェクトもあります。Tldrawは低品質なAI投稿が急増したことを受け、外部貢献者からのプルリクエストを自動的に閉じるようになりました。Kubernetesは所有責任に一線を引き、人間の貢献者が変更を理解し、レビューで説明できる限りAIによる支援を認めています。CurlのメンテナーDaniel Stenbergは、AIが生成したセキュリティレポートに埋もれる状況について書いています。それらはプルリクエストではありませんが、メンテナーなら問題を理解できるでしょう。誰かが数分でレポートを送り、Stenbergはそれが誤りだと証明するために午後を費やすのです。
Eastonのドライブバイ型に関する議論も、同じ計算に行き着きます。コード生成が安価で、プロジェクトの理解が難しいなら、外部の人が提供できる最も有用なものは、再現方法を含む質の高いバグレポートかもしれません。そこからメンテナーは問題をエージェントに渡し、プロジェクトの慣習に従った変更を受け取り、ほかのプルリクエストと同じようにレビューできます。
プルリクエストの役割はさらに大きくなった
死亡宣告が投げかけた問いには答えがあります。それは葬儀ではありません。AIがより多くのコードを生成するにつれて、プルリクエストの役割は大きくなります。
書き手たちは負荷については正しかったものの、患者の予後については間違っていました。業界はプルリクエストを廃止するのではなく、強化することで応えています。GitHubはメンテナー向けの制御を追加し、Kubernetesは所有責任のルールを定め、CodeRabbitはTriageとガイド付きレビューをワークフローに組み込みました。いずれも、一行ずつ読み切れないほど多くの変更を人が評価できるようにするためです。
コードを書いた本人が説明できた時代なら、承認は短い「LGTM」で済んだかもしれません。しかし、エージェントは何に対しても責任を負えません。これからの承認は、人が変更を理解し、根拠を検討し、その後に起きることを引き受けると合意したことを意味しなければなりません。
