プルリクエスト不要論を語る記事は増え続けています。
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はプルリクエストをプロンプトリクエストと捉え、計画、アーキテクチャ、エージェントが検証した結果にレビューの重点を置いています。
PR不要論に関する見解は一致していません。それでも、全員同じ問いを投げかけています。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は今すぐ見るべきプルリクエストを決めますが、その後に何をするかまでは決めません。従来の差分が示すのはコードが変わった場所だけで、各部分がどうつながり、システムにとって何を意味するのかはレビュー担当者が組み立て直さなければなりません。AIエージェントが生成するプルリクエストの規模と範囲が広がるほど、その作業がレビューに占める割合も大きくなります。
CodeRabbitのChange Stackは、プルリクエストをガイド付きの流れに再構成します。関連する変更を意味のあるレイヤーにまとめ、論理的な順序で提示し、それぞれの説明を差分の該当行に結び付けます。図が挙動の理解に役立つ場合は、その視覚情報をコードの隣に配置します。
リポジトリとプルリクエストのワークフローはそのままです。Triageが最も重要な作業を示し、Change Stackが作成者のコンテキストに乏しい大規模な変更の理解を助けます。リリースするかどうかを決めるのは、その結果を引き受ける人たちです。
今、プルリクエストが担うもの
従来のプルリクエストは人から人への依頼であり、開発者が変更を提案し、その背後にある判断をレビュー担当者に説明するものでした。AIエージェントが変更を生成すると、プルリクエストを作成した人が、そのコードを作った思考過程を説明できない場合があります。だからこそ、プルリクエスト自体がそのコンテキストを担わなければなりません。
実際には、作業を始めたプロンプトからリリースを決める承認まで、変更の全体像を伝える必要があります。課題は作業が存在する理由を、エージェントの活動はコードが形作られた過程を示します。テストやセキュリティの検出結果は、感覚だけに頼らず判断するための根拠になります。レビューコメントはチームが議論した内容を残し、承認は誰がリリースに同意し、本番環境でその結果に責任を負うのかを記録します。
メンテナーがルールを変え始めている
オープンソースのメンテナーは、自分のコードについて質問に答えられない貢献者からのプルリクエストを受け取るようになっており、コンテキスト不足を真っ先に感じています。GitHubは6月、書き込み権限を持たない貢献者が同時に開いておけるプルリクエスト数に上限を設定できるようにすると発表し、急増への対応としてほかの変更も予告しました。
GitHubのオープンソース担当ディレクターAshley Wolfは、CodeRabbitに対して以下のように語りました。
「メンテナーは、オープンソースの信頼を支える層です。AIによってコントリビュートしやすくなる中、メンテナーが作業を受け取りレビューする方法について、より多くの選択肢を持てるようにしたいと考えています。
プルリクエストは決して終わっていません。単なるコード提出だったものから、コンテキストやレビュー、説明責任を備えた豊かなチェックポイントへと進化しています。私たちの役割は、その進化が加速する中でメンテナーが必要なコントロールを確実に持てるようにすることです」
GitHubは2026年の初めにも、プルリクエストに関する2つのアクセス制御を提供しました。メンテナーはプルリクエストを無効にしたり、作成できる人をコラボレーターに限定したりできます。これらの設定により、プロジェクトは貢献を受け入れる方法をより細かく管理できます。
GitHubより先に動いたプロジェクトもあります。Tldrawは低品質なAI投稿が急増したことを受け、外部貢献者からのプルリクエストを自動的に閉じるようになりました。Kubernetesは所有責任に一線を引き、人間の貢献者が変更を理解してレビューで説明できる場合に限り、AIによる支援を認めています。CurlのメンテナーDaniel Stenbergは、AIが生成したセキュリティレポートに埋もれる状況について書いています。それらはプルリクエストではありませんが、メンテナーなら誰しも思い当たる問題でしょう。誰かが数分でレポートを送り、Stenbergはそれが誤りだと証明するために何時間も費やすことになるのです。
Eastonの一見さん的な貢献者に関する議論も、同じ計算に行き着きます。コード生成が安価でプロジェクトの理解が難しいなら、外部の人が提供できる最も有用なものは、再現方法を含む質の高いバグレポートかもしれません。そうすれば、メンテナーは問題をAIエージェントに渡し、プロジェクトの慣習に従った変更を受け取り、ほかのプルリクエストと同じようにレビューできます。
プルリクエストの役割はさらに大きくなった
PR不要論が投げかけた問いには答えがあります。ただし、それはPRが不要になったという結論ではありません。AIがより多くのコードを生成するにつれて、プルリクエストの役割は大きくなっているのです。
書き手たちは負荷については正しかったものの、その後については間違っていました。業界はプルリクエストを廃止するのではなく、強化する傾向にあります。GitHubはメンテナー向けの制御を追加し、Kubernetesは所有責任のルールを定め、CodeRabbitはTriageとガイド付きレビューをワークフローに組み込みました。いずれも、一行ずつ読み切れないほど多くの変更を人が評価できるようにするためです。
コードを書いた本人が説明できた時代なら、承認は短い「LGTM」で済んだかもしれません。しかし、AIエージェントは何に対しても責任を負えません。これからの承認は、人が変更を理解して根拠を検討し、その後に起きることを引き受けると合意したことを意味しなければなりません。
