GitHub Changelog「Limit open pull requests for users without write access」の変更点・設定方法

2026年6月17日、GitHubは「Limit open pull requests for users without write access」を公開しました。これは、書き込み権限のないユーザーが、1つのパブリックリポジトリで同時に開けるPull Request（PR）数を制限する機能です。

上限に達したユーザーは、既存のPRを閉じるか、マージされるまで新しいPRを作成できません。一方、信頼できるコントリビューターはバイパスリストに登録できます。ドラフトPRは上限の計算に含まれません。(The GitHub Blog)

今回の発表では、追加料金、移行作業、対応期限は案内されていません。管理者が確認すべきなのは、対象リポジトリ、適切な上限値、バイパス対象者、ドラフトPRや自動生成PRへの対応です。

GitHub Changelog「Limit open pull requests for users without write access」の変更点

今回追加されたのは、ユーザー単位で同時オープンPR数を制限する、リポジトリのモデレーション機能です。

確認項目	内容
対象リポジトリ	パブリックリポジトリ
制限対象	対象リポジトリへの書き込み権限がないユーザー
カウント対象	オープン中かつドラフトではないPR
上限到達後	既存PRを閉じるかマージされるまで、新しいPRを作成できない
制限されないユーザー	Write以上の権限を持つユーザー
例外設定	指定ユーザーをバイパスリストへ追加可能
設定期間	管理者が変更するまで継続
設定可能数	公式画面では1～1000件
バイパスリスト	最大100ユーザー

GitHubには以前から一時的な「Interaction limits」がありましたが、そちらは一定期間、コメントやIssue作成などを含む操作全体を制限する機能です。今回のPR上限は、長期的にレビュー待ちPRの流入量を調整するための継続設定という違いがあります。(GitHub Docs)

既存のPRを削除する機能ではない

この設定は、上限を超えた既存PRを自動的に閉じたり削除したりする機能ではありません。

たとえば、あるユーザーがすでに5件の通常PRを開いている状態で上限を3件に設定した場合、そのユーザーは既存PRが3件未満になるまで、新しい通常PRを作成できないと考えられます。既存PRの整理は、マージまたはクローズによって行います。

誰に影響するのか

パブリックリポジトリの管理者・メンテナー

最も恩恵を受けるのは、多数の外部コントリビューションを受け付けているOSSプロジェクトです。

同じユーザーから大量のPRが短期間に送られると、次のような負担が発生します。

• レビュー待ち一覧から重要なPRを見つけにくくなる
• CIが繰り返し実行される
• 類似する修正の確認に時間を取られる
• メンテナーが対応できないPRが蓄積する

今回の機能を使えば、PRが作成された後にBotで閉じるのではなく、ユーザーが上限に達した時点で新規作成を抑制できます。GitHubも、レビューキューや不要なCI実行の負担を軽減する用途を挙げています。(The GitHub Blog)

書き込み権限を持たないコントリビューター

対象判定で重要なのは、Organizationへの所属ではなく、そのリポジトリにWrite権限があるかどうかです。

外部ユーザーだけでなく、Organizationメンバーであっても、対象リポジトリでReadまたはTriage相当の権限しか持たない場合は制限対象になり得ます。GitHubのリポジトリロールでは、TriageはPRやIssueの管理向けですが、コードへの書き込み権限は含みません。(GitHub Docs)

AIエージェントや自動化を利用するユーザー

GitHubの公式解説では、Copilotや他のAIエージェントが作成したPRも、ユーザーの上限にカウントされると説明されています。AIを使って複数の修正を並行作成している場合は、上限到達が早くなる可能性があります。(The GitHub Blog)

自動化アカウントを運用している管理者は、次の点を確認してください。

• PRの作成者として記録されるアカウント
• そのアカウントが持つリポジトリ権限
• バイパスリストへの登録が必要か
• 大量のPR作成を許可して問題ない自動化か

自動化だから無条件にバイパスするのではなく、作成頻度とレビュー体制を確認したうえで判断することが重要です。

PR上限を設定する手順

設定は、対象となるパブリックリポジトリごとに行います。

1. GitHubで対象リポジトリを開きます。
2. リポジトリの「Settings」を開きます。
3. サイドバーの「Moderation options」を選択します。
4. 「Interaction limits」を開きます。
5. 「Pull request limits」で、書き込み権限のないユーザーに許可する最大PR数を設定します。
6. 必要に応じて「Bypass list」へ信頼できるユーザーを追加します。
7. 設定を保存します。

公式の設定画面例では、「Limit open pull requests from users without write access」を有効にし、「Maximum open pull requests per user」へ1～1000の数値を入力する構成になっています。(The GitHub Blog)

「Settings」や対象項目が表示されない場合は、リポジトリの可視性と自分のAdmin権限を確認してください。

バイパスリストはWrite権限の代わりに使える

バイパスリストへ追加されたユーザーは、設定されたPR数を超えて新しいPRを作成できます。ただし、追加しただけでコードの書き込み権限やリポジトリ管理権限が付与されるわけではありません。

次のようなユーザーに適しています。

• 継続的に複数の修正を送る外部コントリビューター
• ドキュメントや翻訳を並行して更新する協力者
• 既に複数回のマージ実績がある信頼済みユーザー
• PR作成専用の自動化アカウント

バイパスリストはUIに加えてAPIでも管理でき、最大100ユーザーまで登録できます。GraphQL APIには、追加用のaddPullRequestCreationCapBypassUsersと、削除用のremovePullRequestCreationCapBypassUsersが用意されています。APIによる管理はリポジトリ管理者向けです。(GitHub Docs)

上限値をどう決めるべきか

GitHubが掲載している「5」は設定画面の例であり、すべてのリポジトリに適した推奨値として示されたものではありません。

最初の設定値は、普段のコントリビューション量とレビュー能力から決めます。

リポジトリの状況	開始時の目安	注意点
同一ユーザーから低品質なPRが連続する	1～2件	正当な複数修正も止めやすい
一般的なOSSリポジトリ	3～5件	制限効果と参加しやすさを両立しやすい
小規模な修正を並行して受け付ける	5～10件	CI負荷とレビュー滞留を監視する
外部の定期コントリビューターが多い	3～5件＋バイパス	信頼済みユーザーを個別に除外する

上表は運用開始時の実務的な目安であり、GitHub公式の推奨値ではありません。

設定前には、直近30日程度のPRを確認し、ユーザーごとの同時オープン数を調べると判断しやすくなります。

1. 通常のコントリビューターが同時に何件開いているかを確認する
2. 問題となった大量投稿の件数を確認する
3. 通常利用を妨げず、大量投稿を抑えられる値を設定する
4. 1～2週間試し、レビュー待ち件数や問い合わせを確認する
5. 必要に応じて上限値とバイパスリストを調整する

いきなり「1」にするより、3～5件程度から試し、運用データを見ながら下げる方がトラブルを減らせます。

一時的なInteraction limitsとの違い

似た設定ですが、目的と効果が異なります。

比較項目	今回のPR上限	一時的なInteraction limits
主な目的	継続的なPR流入量の管理	荒らしや急増時の一時対応
期間	変更するまで継続	24時間、3日、1週間、1か月、6か月
対象操作	新しい通常PRの作成	コメント、Issue、PR、リアクションなど
対象者	書き込み権限のないユーザー	新規ユーザー、過去の貢献者以外、コラボレーター以外など
例外対応	ユーザー単位のバイパスリスト	選択した制限方式に依存

PRが継続的に多すぎる場合は今回のPR上限、短期間の荒らしやスパムが発生した場合は一時的なInteraction limitsという使い分けが適しています。(GitHub Docs)

設定前に確認したい注意点

ドラフトPRはカウントされない

ドラフトPRは上限の計算対象外です。そのため、この機能だけではドラフトPRの大量作成を抑制できません。(The GitHub Blog)

ドラフトが増えた場合は、PR一覧でドラフトを除外してレビュー対象を確認するとともに、CONTRIBUTING.mdで利用ルールを案内する必要があります。

リポジトリ単位の制限である

今回の上限は、各リポジトリ内でのユーザーごとのPR数に適用されます。複数リポジトリを横断してPR総数を制限する機能ではありません。GitHubは、クロスリポジトリでの制御を今後の検討項目として挙げています。(The GitHub Blog)

多数のパブリックリポジトリを運用しているOrganizationでは、重要度やPR流入量に応じて、設定対象を優先順位付けしてください。

CI設定の代わりにはならない

PR数を制限しても、1件ごとのワークフロー実行条件や権限は変わりません。

CIコストやセキュリティが目的の場合は、次の設定も別途確認します。

• Forkからのワークフロー実行承認
• GITHUB_TOKENの権限
• 実行対象のパスやイベント
• 同時実行数やキャンセル設定
• 外部コントリビューター向けのレビュー手順

PR上限はレビューキューへの流入を抑える機能であり、GitHub Actionsのセキュリティ設定そのものではありません。

バイパスリストを放置しない

信頼関係や担当範囲が変わっても、バイパスリストから自動削除されるとは限りません。

定期的に次の点を確認してください。

• 現在も継続して活動しているユーザーか
• 複数PRを同時に開く必要があるか
• Write権限を付与済みで、バイパス登録が重複していないか
• 自動化アカウントが不要なPRを作成していないか

更新・移行・料金・期限で確認すべきこと

項目	2026年6月時点の確認結果
設定変更	対象リポジトリの管理画面から実施
アプリ更新	Git、GitHub CLI、GitHub Desktopなどの更新指示はない
データ移行	既存PRやリポジトリデータの移行は不要
ワークフロー変更	必須の設定ファイル変更はない
追加料金	Changelogとドキュメントに個別料金や有料アドオンの記載はない
対応期限	強制移行日や設定期限の案内はない
設定の有効期間	管理者が変更するまで継続
GitHub Enterprise Server	現時点のドキュメント対象に含まれていないため、利用中のバージョンで要確認

GitHub Docsの対象バージョンにはFree、Pro、Team、GitHub Enterprise Cloudが含まれています。一方、同ページのソースではGitHub Enterprise Serverが対象として記載されていません。オンプレミス環境では、GitHub.comと同様に利用できると決めつけず、利用中バージョンのリリースノートを確認してください。(GitHub)

また、今回の公式案内には追加料金や対応期限の記載がありません。ただし、プランや提供範囲は今後変わる可能性があるため、導入時には実際のリポジトリ設定画面も確認するのが確実です。(The GitHub Blog)

よくある疑問

上限に達すると既存PRは閉じられる？

既存PRを自動的に閉じる機能としては案内されていません。ユーザーは既存PRを閉じるかマージされ、オープン数が上限未満になった後に新しいPRを作成します。

ドラフトからReady for reviewに変更するとどうなる？

公式情報では、上限の判定対象はオープン中の非ドラフトPRです。そのため、ドラフトをReady for reviewへ変更する時点でも、上限との関係を考慮する必要があります。具体的な画面動作は変更される可能性があるため、厳しい上限を設定する場合はテスト用アカウントで確認してください。

バイパスするとWrite権限も付与される？

付与されません。バイパスリストはPR数の制限だけを除外し、それ以外のリポジトリ権限は変更しません。(GitHub Docs)

プライベートリポジトリでも使える？

公式ドキュメントは、パブリックリポジトリで利用できる機能として説明しています。プライベートまたは内部リポジトリでの利用を前提にせず、実際の設定画面と契約プランを確認してください。(GitHub Docs)

まず1つのリポジトリで試験導入する

「Limit open pull requests for users without write access」は、外部コントリビューションを閉ざさずに、レビュー可能な量へ調整できる機能です。

最初から全リポジトリへ同じ上限を設定するのではなく、PR流入量が多いパブリックリポジトリを1つ選び、3～5件程度から試すのが現実的です。信頼済みユーザーをバイパスリストへ追加し、CONTRIBUTING.mdにも上限と運用方針を記載します。

導入後は、レビュー待ちPR数、CI実行量、コントリビューターからの問い合わせを確認してください。通常の投稿を妨げている場合は上限を上げ、大量投稿を抑えられていない場合は上限を下げることで、リポジトリに合った設定へ調整できます。