GitHubの現在の仕様は、性善説です。
すなわち、プルリクを出すことができるユーザは、ある程度コードを理解しているという前提です。
開発者Collaboratorと、外部貢献者Contributerは、信頼モデルで結ばれていたのです。

逆にコードを理解していない人によるプルリクは一目で的外れとわかるので、開発者による認知負荷はそこまで高くありません。
従ってGitHubのプルリクにはアクセス制御の仕組みはなく、またプルリクを削除することもできません。
プルリクに対してレビューを必須にする・直接mergeを禁止するといったマージへの制御は可能でしたが、そもそもプルリク自体を制限するという発想はありませんでした。

このモデルは、数年前までは極めてうまく機能していました。

しかし、AIの発展がこれを全てぶち壊しました。

コードをほとんど理解していない、あるいは全く理解していないユーザによる、一見もっともらしく見える出鱈目なContributeを、極めて容易に量産できるようになってしまったのです。
これによってレビュアーの負荷が一気に激増してしまい、多くのプロジェクトが悲鳴を上げています。

この問題に対して『ユーザを啓蒙する』が一切の解決策にならないことは言うまでもありません。

そこで低品質なユーザによるContributeを拒否するツールVouchなどが発展してきました。

ここに至ってGitHubも重い腰を上げ、先日2026/02/13にようやく、本当にようやくプルリクへの制限を導入しました。

プルリクを出せるユーザを『全員』・『Collaboratorだけ』・『無効』から選択できるようになりました。

無効にすると単純にプルリクのタブが消えます。
ミラーリポジトリや今後更新の予定がないリポジトリなど、プルリクが不要な場合は禁止することができます。

たとえばLinuxのGitHubリポジトリは他所にある本体のミラーであり、ここへのプルリクエストは全てが無視されていました。
これまではプルリクを出すと『PRは受け付けてねーよ』みたいなBOTが反応していたのですが、今回の機能追加に伴い、さっそくプルリクのタブが消滅しています。
ちなみにここ、先日のロシア人開発者追放騒動以来MAINTAINERSを削除するプルリクで埋め尽くされていてちょっと面白かったのですが、見れなくなって少々残念です。

この機能は1月末あたりからGitHubコミュニティで検討され、実現となったものです。
アクセス制御の仕組みはプルリク制限で終わりではなく、今後もまだまだ機能追加は続く予定です。
ということで以下は該当のディスカッションスレッドExploring Solutions to Tackle Low-Quality Contributions on GitHubの紹介です。

Exploring Solutions to Tackle Low-Quality Contributions on GitHub

オープンソースコミュニティに影響を与えている重要な問題について最新情報をお届けします。
それは、低品質なContributeがメンテナーにとって大きな運用上の負荷になっていることです。

プロジェクトの品質基準を満たしていないContributeのレビューに、多くの時間を費やす羽目になっているという意見があります。
理由としては、プロジェクトガイドラインに違反している、提出後すぐに音信不通になる、そしてしばしばそれがAI生成であることです。
AIがソフトウェアのワークフローを変貌させ続けている中、我々はこの問題に切り込み、短期的および長期的なソリューションを開発しようとしていることをお知らせします。

What we're exploring

我々は、コミュニティメンバーのフィードバックを精査し、メンテナと直接やりとりを行い、様々な解決策を模索しました。
現在検討中のソリューションの概要は以下のとおりです。

■ 短期的ソリューション

プルリクエストの制御。
これは2016年のはるかな昔から要望されていたものであり、メンテナがプルリクエスト権限をカスタマイズするための第一歩となります。
リポジトリ所有者は、Contribute可能なユーザをCollaboratorだけに限定したり、ミラーリポジトリではPRを禁止したりと、PRアクセスを細かく制御できます。
これによって、多くのプロジェクトが独自で導入しているContribute管理なども不要になります。

プルリクエスト削除機能。
メンテナーは、低品質なPRやスパムを削除することができます。

■ 長期的な方向性

権限モデルの強化。
プルリクエスト権限をカスタマイズできるようなツールを提供します。
全ユーザをブロックしたりCollaboratorのみに制限するだけではなく、PRの作成とレビューを誰が行えるかをより細かく制御します。
またプルリクエストが満たすべき基準を定義します。

トリアージツールの改善。
Contributeをプロジェクトのガイドラインや標準に照らし合わせてAIで評価し、優先してレビューするに値するContributeを強調します。

AIによるContributeの明示。
PRライフサイクル内でAIツールを使用した際の、可視性と帰属をわかりやすくします。

Next Steps

これらはあくまでも出発点であり、我々は短期的・長期的両方の改善を模索し続けています。
フィードバック、質問、懸念事項などをお聞かせください。

コメント欄

200以上のコメントが集まっています。

Mossaka

こんにちは！
Azure Coreチームに所属しています。
このチームにはOSSのメンテナもたくさんいます。
社内でCopilotについて話し合うセッションを開催したところ、メンテナが求められているレビューの厳格さと、AI生成コードとの隔たりが広がりつつあり、ますます持続不可能になりつつあるという話がありました。

・PR提出者がきちんとソースコードを理解しているという信頼モデルが崩壊した。
・AI生成のPRは、構造的には一見問題なくとも、論理的に誤っていたり、安全でなかったりすることがある。
・レビュアーは行単位でのレビューを行っているが、AIによる大規模PRには対応しきれない。
・仕様を理解していない人によるPRのapproveには抵抗があるが、AIでは簡単にそういうことができる。
・レビュアーは、コードが適切であるかと、PR提出者がきちんとコードを理解できているかの両方を評価しなければならなくなった。

レビューの負担は、AI導入前より軽減されるどころか、ますます増加しています。

MuchuCAT

メンテナーとしての観点から言うと、この問題はAIそのものではなく、コストの非対称性にあります。
Contributeを提出するコストが非常に安くなっている一方、それに対してレビュー・トリアージ・コミュニケーションにかかるコストは全く軽減されていません。

iBug

mmistakes/minimal-mistakesのメンテナとして、大量のゴミPRが送られてくる状況に陥っています。
何らかの品質管理が入ってくれれば、大きな改善になるはずです。

このActionを使って無用なPRを自動でクローズしていますが、そもそもそのようなPRが送られないようにする解決策を求めています。

sirosen

新規CollaboratorはオープンなPRを1つだけしか作れないようにするとか。

あとPRを、明示的にabandonedとしてクローズできる機能がほしい。
これは却下ではないが、提出者に替わって不足の作業するつもりもない、というシグナルです。

xavidop

プロジェクトにルールやプロンプトを定義しておき、それらに基いてPRを評価するのはどうだろう。
ルールを満たさないPRはフラグがつけられるか、あるいは自動でクローズされる。

moraesc

xavidop、それは検討事項のひとつです。
たとえばCONTRIBUTING.mdをガイドラインとして活用するなどです。

duskwuff

リポジトリオーナーが、AI支援によるContributeをどう扱うか明示するポリシー機能がほしい。
ポリシーでCopilotが禁止されているリポジトリでは、自動的にCopilotが無効にされる。

ann4belle

ここに素晴らしいアイデアがあります。
AI生成によるPRやIssueは、許可を明示していないかぎり禁止するというものです。

sanny-io

GitHubはコミュニティに全ての負担を押し付けている一方で、低品質なPRはおろかSPAMについてすら何もしていません。
SPAMについて何度もサポートに連絡しましたが、毎回失望しています。

最新の連絡については、3週間後に回答が来ました。
このSPAMコメントは何ひとつ問題ないということでした。

rmacklin

途中からIssueを禁止にすると、これまでのIssueも全て閲覧できなくなるのは明確な欠点です。
ここを改善する予定はありませんか？

PraiseTechzw

懸念しているのは、これから新しくcontributeを始めようと考えている人に影響が大きいのではないかということです。
包括的に制限するのではなく、何らかの方法でプルリクをフィルタリングする方向性が有望ではないかと考えています。

moraesc

PraiseTechzw、たとえばプルリクの前にIssueを提出することを義務付けたり、CONTRIBUTING.mdのルールに従ってプルリクを検証するといったことを検討しています。

funnelfiasco

Ghosttyはディスカッションファーストというアプローチを採用しています。
このようにプルリクをIssueやディスカッションにリンクさせる方式はよいのでは。

weisdd

funnelfiasco、そのアプローチの問題点として、人気のあるプロジェクトはたくさんのIssueが放置されているので、そこから大量にプルリクをAI生成できてしまうということです。
先日そのようなアカウントを見たことがあり、Issueの整理に奔走する羽目になりました。

感想

でも君たち大量の懸念を無視してCopilot導入を強行したよね。
まあ方向転換ができただけでもよしとしましょうか。

現在は、短期的ソリューションの第一歩がようやく始まったというところです。
プルリクエストの提出者を制限するという最初のソリューションがようやく実装された段階であり、その次のプルリク削除もまだできません。
とはいえこれはまあ、さほど遠くないうちに対応されることでしょう。
うっかりパスワードをPRしてしまう問題もようやく完全解決しそうですね。

いっぽう長期的ビジョンはまだ始まってもいないところです。
たとえば今のところ『基本プルリク禁止だが、一部のユーザには個別にプルリク許可したい』という場合、プルリクだけのためにわざわざCollaboratorにしなければならないので、ちょっと権限が強すぎますね。
そのように細かい制御をしたい場合は、まだまだVouchのようなツールを手放すことができません。

それにしてもmmistakes/minimal-mistakesリポジトリへのプルリク、これは明らかにAIなのですが、しかしいったい何が目的なのかが全然わからない。
なんなんですかねこれ。