GitHub、AIによるプルリクエスト急増にメンテナーが歯止めをかけられる仕組みを提供

GitHub gives maintainers a throttle for the AI pull request surgeの意訳です。

「プルリクエストはもう終わった」という声をよそに、プルリクエストはむしろ元気いっぱいで、騒がしく、それをレビューする人間の体制が追いつかないほどのスピードで増え続けています。

そんな現実をはっきり映し出しているのが、今回のGitHubの発表です。外部の貢献者が同時に開いておけるプルリクエストの数に、メンテナー自身が上限を設けられるようになりました。

GitHubでオープンソース部門のディレクターを務めるAshley Wolf氏は、今回の新機能についてこう語ります。

「メンテナーはオープンソースにおける信頼の担い手です。AIで貢献を生み出すことが簡単になった今、その成果をどう受け取り、どうレビューするか、メンテナーがもっと自由に選べるようにしたいのです。プルリクエストは死んでなどいません。単なるコードの提出から、文脈・レビュー・責任の所在を確かめる、より中身の濃いチェックポイントへと進化しています。その進化が加速するなかで、メンテナーに必要な操作手段をきちんと用意するのが私たちの役目です」

設定はリポジトリの設定画面から直接行えます。メンテナーは、書き込み権限を持たないユーザーが開けるプルリクエストの上限数を決められます。貢献者がその数に達すると、既存のものがクローズまたはマージされるまで、次のプルリクエストは順番待ちになります。信頼できる相手は、コラボレーター権限をまるごと与えなくても、例外リストに加えて制限を外せます。

仕組み自体はシンプルですが、その意味は小さくありません。AI(スロップ)のスピードで回り続ける貢献の流れに、GitHubはメンテナーの手で握れる「調整弁」を持たせたのです。

GitHubでMaintainer Winsを担当するプロジェクトマネージャーのCamilla Moraes氏によれば、今回の対応が狙うのは「大規模に押し寄せるAIスロップ」という問題で、GitHubはメンテナーを楽にする方法を彼らと一緒に探ってきたといいます。

「今年の初め、メンテナーを苦しめているある傾向について議論の場を設けました。既存のツールやワークフローでは捌ききれない、低品質な貢献の洪水です」と、彼女はGitHub上で書いています。

つまるところ、安く大量に生まれるコードと、数の限られた人間のレビュー。その両者がぶつかるAI時代に、プルリクエストの待ち行列が悲鳴を上げている。だからこそGitHubはこの設定を追加したのです。

本記事のために共有されたGitHubのデータによると、サイト全体でマージされたプルリクエストは、2023年1月の月間2,500万件から2026年3月には月間9,000万件へと3.6倍に増えました。コミット数も月間3億8,900万件から14億件へと、同じくおよそ3.6倍です。GitHubはこの話のインフラ面を4月に明かしています。2025年10月に処理能力を10倍に引き上げる計画を始め、2026年2月には現在の30倍の規模を見据える段階に入ったといいます。背景にあるのはエージェント型の開発の広がりで、リポジトリ作成、プルリクエスト、API利用、自動化、大規模リポジトリの処理が軒並み急増しているとのことです。

画像出典: GitHub

社会的な面に目を向けると、話はいっそう切実です。その熱を真っ先に浴びるのがメンテナーだからです。

Wolf氏はこの状況を、オープンソースの「永遠の9月(Eternal September)」と呼びました。生成AIによってコードもIssueもセキュリティレポートも大量に作れるようになった、と同社は述べ、問題の本質をひと言で言い切っています。

「作るコストは下がったのに、レビューするコストは下がっていない」

このひと言こそが、今回の上限機能の存在理由を物語っています。

メンテナーに新しい「第三の選択肢」を

GitHubは2月の時点で、土台となる2つの設定をすでにリリースしていました。プルリクエストを完全に止めるか、作成をコラボレーターだけに限るかです。これらは、ミラーや読み取り専用のコードベース、あるいは「コードは公開したいが外部からの貢献の受付はしたくない」プロジェクトに向いた設定でした。

今回の上限機能は、そこにもっと細やかで柔軟な選択肢を加えます。狙うのは特定の困った行動パターン、つまり少数のユーザーが短期間に同じリポジトリへ大量のプルリクエストを投げつける、という状況です。Moraes氏はこの上限を「すぐに出せるなかで最もシンプルで、最も効果が大きい設定のひとつ」と評しています。全開でも、コラボレーター限定でもない、現実的な中間地点を作り出すからです。

この「中間」が大事なのです。オープンソースは、境界が緩やかであってこそ栄えます。同時にメンテナーには、静かな作業場と、整った待ち行列と、信頼できる手応えも欠かせません。

上限を設ければ、メンテナーは新しい貢献者を歓迎しつつ、レビューの導線を洪水から守れます。例外リストがあれば、信頼する相手はそのまま動き続けられます。こうして生まれるのは、もっと陰影のある信頼のかたちです。コミュニティを迎え入れる温かさと、規模に耐える堅さを、両方そなえています。

これはコミュニティが望んでいたこと

メンテナーや貢献者がプルリクエストの制御をもっと求める声は、AIコーディングの波が来るずっと前から上がっていました。

2021年のGitHubコミュニティの議論「要望: プルリクエストをオフにする機能を」では、あるユーザーが、メンテナーには「ただコードを共有したいだけで、保守やIssue・プルリクエストの仕分けまで抱え込みたくない」ときがある、と書いています。Issueを無効にできるのと同じように、プルリクエストも無効にできると便利だ、という要望でした。

AI時代は、その要望を一段と切実なものに変えました。低品質な貢献をめぐる2026年のGitHubコミュニティの議論では、「リポジトリのオーナーが貢献者からのプルリクエストを『レート制限』できるのは、たぶん良い案だ」というコメントが寄せられています。別のコメントは、怪しいパターンをずばりこう言い当てました。「これまで一度も貢献していなかった人が、急に30件もプルリクエストを送ってくる」、これは普通の人間のふるまいとはとても思えない、と。

これらの例は、ほかの多くの声と同じく、ひとつのまぶしくて居心地の悪い事実を指しています。作るほうはあり余り、レビューするほうは足りない、ということです。

GitHubはメンテナーの「操縦席」を作り直している

今回の上限機能は、メンテナー向けのより大きなプロダクト強化の一環です。

GitHubのMaintainer Month「Ships for Maintainers」のページには、オープンソースのメンテナーのために作られた機能・改善が40件挙げられています。内訳はプルリクエスト関連が8件、Issueが6件、通知が4件、モデレーションが3件です。

このうちいくつかは、プルリクエストの急増にはっきり対応したものです。

まず、全体を見渡せるプルリクエストのダッシュボードが、オプトアウト方式のパブリックプレビューに移りました。組織やリポジトリでの絞り込み、保存したビュー、ドラフトやレビュー待ちをまとめた受信トレイ、未読の印、一覧から見えるステータスチェックを備え、プルリクエストを一か所で管理できます。

次に、公開リポジトリのプルリクエスト一覧に、First-time contributor、Contributor、Memberといったメンバーの役割ラベルが直接表示されるようになりました。貢献の履歴がひと目で分かるので、仕分けが速くなる、というわけです。

さらに、プルリクエストのFiles changedページが刷新され、パネルを固定できるようになりました。概要・コメント・マージ状況・アラートを、差分と並べて開いたままにできます。アラートのパネルには、コードレビューのすぐ横にコードスキャンの警告が出ます。

加えて、プルリクエスト内からマージ状況にすぐアクセスできるようになり、ブロッカーや足りない承認、マージの準備状況を素早く把握できます。

モデレーションも鋭くなりました。Issue・ディスカッション・プルリクエスト・コミットのコメントを隠すメニューに「Low Quality(低品質)」が加わりました。「スパム」「悪用」といった従来の分類では、増え続ける役に立たないコメントを捉えきれなかったためです。

通知もすっきりしました。古い順に並べ替えられるようになり、溜まった通知を順番に片付けられます。スパム的なリポジトリやユーザーが発端の通知の扱いも改善されました。

ロードマップはまだ続きます。GitHubによると、近くプルリクエストのアーカイブ機能が登場し、低品質やスパム的なものを履歴を残したままメイン一覧から外せるようになります。さらに、Issueの上限設定、コラボレーター限定のIssue制限、より細かいインタラクション制限、そして多数のリポジトリにわたって活動をばらまくユーザーへのグローバルなレート制限なども検討中だといいます。

これらをまとめると、フィルターと手応え、そして歯止めが増え、より落ち着いて作業できる、新しいメンテナーの「操縦席」が形になりつつあります。

プルリクエストは生きている

プルリクエストは、昔から単なる差分以上のものでした。コードと信頼が出会う場所です。

AIは、その信頼のやり取りをいっそう騒々しく、要求の厳しいものにします。AIが書いたプルリクエストは、見た目こそ洗練されていてテストも通るのに、プロジェクトの設計思想や好み、これまでの経緯や意図をすっかり外していることがあります。そのツケを認知の負担として払うのは、やはり人間のメンテナーです。レビューのたびに、文脈を切り替えるじわじわとした消耗、リスクのひりつく感覚、そして「自分が責任を負う」という静かな重みがついて回ります。

GitHubの新しい上限機能は、その現実を気持ちよいほど率直に認めています。あふれる貢献への答えは、より上手な流量の調整です。オープンソースには、招き入れることも、育てることも、開かれていることも要ります。それと同時に、作業を担う人を守れるだけの、しっかりした境界も必要なのです。

この未来のいちばん良いかたちは、扉を開けたまま、その取っ手をメンテナーの手に委ねることでしょう。

プルリクエストは生きています。GitHubは今、それをそれなりに健やかに保つための調整弁を、メンテナーの手に渡したのです。