GitHubで新しいPull Request（PR）を作成できない場合は、対象Organizationに設定された「Pull request limits」を確認してください。GitHubでは2026年8月6日から、Write権限のないユーザーが同時に開けるPR数を、Organizationの設定画面から一括管理できるようになりました。上限に達したユーザーは、既存のPRをCloseするか、Write権限を持つユーザーにMergeしてもらうまで、新しいPRを作成できません。(The GitHub Blog)
設定場所は、Organizationの「Settings」から「Moderation」または「Moderation tools」を開き、「Interaction limits」の下部にある「Pull request limits」です。なお、Draft Pull Requestは上限数に含まれません。まずは対象リポジトリで、自分が開いているDraft以外のPRを確認することが解決への近道です。(GitHub Docs)
GitHubで新しいPRを作れないときの結論
組織単位のPull Request数制限が原因の場合、利用者と管理者では確認する場所が異なります。
| 立場 | 最初に確認すること | 主な対応 |
|---|---|---|
| PRを作成するユーザー | 対象リポジトリで自分が開いているPR数 | 不要なPRをCloseする |
| PRを作成するユーザー | Merge待ちのPRが残っていないか | MaintainerにレビューやMergeを依頼する |
| Organization管理者 | Organization SettingsのPull request limits | 上限値と有効状態を確認する |
| リポジトリ管理者 | リポジトリ固有の設定や例外 | 上限値、上書き設定、バイパス対象を確認する |
重要なのは、単に時間が経過するのを待つだけでは、原則として解決しない点です。上限の対象になっているOpen PRがCloseまたはMergeされ、件数が上限未満になる必要があります。(GitHub Docs)
組織単位のPull Request数制限とは
組織単位のPull Request数制限は、Organizationが所有するパブリックリポジトリについて、Write権限のないユーザーが同時に開けるPR数を制御する機能です。
従来はリポジトリごとに設定する必要がありましたが、Organizationの設定画面から共通ポリシーとして管理できるようになりました。多数のOSSリポジトリを運営しているOrganizationでは、レビュー待ちPRの急増や、不要なCI実行を抑えるために利用できます。(The GitHub Blog)
制限の対象になるユーザー
Pull request limitsは、リポジトリに対するWrite権限を持たないユーザーに適用されます。
| ユーザーの権限・状態 | 制限の対象 |
|---|---|
| リポジトリへの明示的なアクセス権がない外部ユーザー | 対象 |
| Read権限 | 対象になり得る |
| Triage権限 | 対象になり得る |
| Write権限 | 対象外 |
| Maintain権限 | 対象外 |
| Admin権限 | 対象外 |
GitHubのOrganizationリポジトリでは、Read、Triage、Write、Maintain、Adminという権限レベルが用意されています。Pull request limitsは、そのうちWrite権限以上を持たないユーザーに関係する設定です。(GitHub Docs)
Organizationのメンバーであっても、対象リポジトリへの権限がReadやTriageにとどまっている場合は、Write権限を持っているとは限りません。「Organizationに所属しているから制限されない」とは考えず、対象リポジトリでの実際の権限を確認してください。
上限にカウントされるPR
公式ドキュメントでは、上限判定の対象を次のように説明しています。(GitHub Docs)
| PRの状態 | 上限へのカウント |
|---|---|
| OpenかつDraftではないPR | カウントされる |
| Draft PR | カウントされない |
| Closed PR | カウントされない |
| Merged PR | カウントされない |
たとえば、上限が3件に設定されているリポジトリで、あるユーザーがDraftではないOpen PRを3件持っている場合、そのユーザーは4件目のPRを作成できません。
一方、Open PRが3件あっても、すべてDraftであれば上限のカウント対象外です。ただし、制限を回避することだけを目的にDraftへ変更するのではなく、実際に作業途中のPRをDraftとして管理する運用が適切です。
公式ドキュメント上の対象はパブリックリポジトリ
OrganizationのPull request limitsは、公式ドキュメント上では、Organizationが所有するパブリックリポジトリを対象とする機能として案内されています。プライベートリポジトリでPRを作成できない場合は、この設定だけでなく、リポジトリへのアクセス権、ブランチの状態、OrganizationやEnterpriseのポリシーも確認してください。(GitHub Docs)
「組織単位」と「組織全体の合計」は同じではない
この機能を理解するうえで注意したいのが、「設定する単位」と「PR数を数える単位」の違いです。
現行のOrganization向け設定ガイドでは、Organizationから全パブリックリポジトリへ同じ上限を設定できる一方、PR数の上限はリポジトリごとに個別判定されると説明されています。Organization全体のすべてのリポジトリを合算して、1つの上限を共有するという説明ではありません。(GitHub Docs)
たとえば上限が3件の場合、現行の設定ガイドに従えば、次のように判定されます。
| リポジトリ | ユーザーが開いているPR | 新規PR |
|---|---|---|
| repository-a | 3件 | 作成できない |
| repository-b | 1件 | 作成できる |
| repository-c | 0件 | 作成できる |
つまり「組織単位の設定」とは、Organization管理者が複数リポジトリへ共通設定を適用できるという意味です。
REST APIリファレンスとの記述差に注意
2026年9月3日時点では、Organizationの設定ガイドとREST APIリファレンスで、上限を数える範囲の説明が一致していません。
Organizationの設定ガイドには「リポジトリごとに適用される」とありますが、REST APIリファレンスには「Organization内の全パブリックリポジトリにあるOpen PRの合計を制限する」と読める記述があります。(GitHub Docs)
大規模なOrganizationで厳密な制御が必要な場合は、ドキュメントの表現だけで判断せず、次の方法で実際の動作を確認するのが安全です。
- Write権限を持たない検証用ユーザーを用意する
- 複数のパブリックリポジトリでPRを作成する
- 各リポジトリの上限到達時の動作を確認する
- Web画面とREST APIの返却値を記録する
- Organization内の運用ルールに判定単位を明記する
GitHub側のドキュメントが更新される可能性もあるため、APIによる自動管理を実装するときは、利用時点の公式仕様を再確認してください。
Pull Request上限が原因か確認する方法
対象リポジトリで自分のOpen PRを検索する
対象リポジトリの「Pull requests」タブを開き、検索欄に次の条件を入力します。
state:open is:pr author:YOUR-USER -is:draftYOUR-USERは自分のGitHubユーザー名に置き換えてください。
この検索条件では、次のPRを抽出できます。
- 状態がOpen
- 種類がPull Request
- 自分が作成者
- Draftではない
GitHubのIssue・PR検索では、author:で作成者を指定でき、is:draftでDraft PRを抽出できます。また、検索条件の先頭に-を付けることで、その条件を除外できます。(GitHub Docs)
Organization全体から自分のPRを調べる場合は、次のようにorg:を追加します。
org:ORGANIZATION state:open is:pr author:YOUR-USER -is:draftただし、上限がリポジトリ単位で判定される場合は、検索結果をリポジトリごとに分けて確認する必要があります。
不要なPRをCloseする
すでに対応不要になっているPRや、別のPRへ作業を引き継いだPRが残っている場合は、Closeを検討します。
Closeする前に、PRのコメント欄へ理由を記録しておくと、後から経緯を確認しやすくなります。
この変更は #456 に統合したため、重複を避ける目的でCloseします。レビュー中のPRや、今後再開する可能性があるPRを、上限を空けるためだけに安易にCloseするのは避けてください。Maintainerと相談し、作業の扱いを決めることが重要です。
Merge可能なPRはMaintainerへ連絡する
Write権限のないユーザーは、自分だけではPRをMergeできないことがあります。その場合は、レビュー担当者やMaintainerに次の情報を伝えます。
新しいPull Requestを作成しようとしましたが、PR数の上限に達している可能性があります。
次のPRはレビュー対応済みです。Merge可能か確認をお願いします。
対象PR：#123
対象リポジトリ：example/repository既存PRがMergeされれば、そのPRはOpen状態ではなくなるため、新しいPRを作成できる可能性があります。
上限未満なのに作成できない場合
検索結果が上限未満に見えるにもかかわらずPRを作成できない場合は、Organization管理者へ次の情報を渡してください。
| 管理者へ伝える情報 | 具体例 |
|---|---|
| Organization名 | example-org |
| リポジトリ名 | example-org/example-repo |
| GitHubユーザー名 | octocat |
| Open PR数 | Draft以外2件 |
| 発生日時 | 2026年9月3日 10時30分ごろ |
| 操作内容 | Compare画面からPRを作成 |
| 表示された内容 | エラー画面のスクリーンショット |
| 他のリポジトリでの結果 | 別リポジトリでは作成可能 |
特に「対象リポジトリだけで発生するのか」「同じOrganizationのすべてのリポジトリで発生するのか」を伝えると、リポジトリ固有設定とOrganization設定を切り分けやすくなります。
組織管理者がPull Request上限を確認する手順
Organizationの管理権限を持つユーザーは、次の手順でPull request limitsを確認します。
- GitHub右上のプロフィール画像をクリックする
- 「Your organizations」を開く
- 対象Organizationを選択する
- Organization名の下にある「Settings」を開く
- 左側の「Moderation」または「Moderation tools」を開く
- 「Interaction limits」を選択する
- ページ下部の「Pull request limits」を確認する
- Write権限のないユーザーに許可する同時Open PR数を選択する
GitHubのChangelogでは「Moderation tools → Interaction limits」、現行ドキュメントでは「Moderation → Interaction limits」と案内されています。画面の言語やUI更新によって表記が多少異なる可能性があります。(The GitHub Blog)
設定を変更した後は、管理者アカウントだけで確認を終えず、Write権限のない検証用アカウントで動作を確認してください。管理者は上限の対象外になるため、管理者自身のアカウントでは利用者側の挙動を再現できません。
Organization設定とリポジトリ設定の優先関係
GitHubでは、Organization単位だけでなく、リポジトリ単位でもPull Request上限を設定できます。
現行ドキュメントでは、Organizationレベルの制限が基本的に優先される一方、Organization設定の後にリポジトリ固有のPull Request制限を設定すると、リポジトリ側の設定がOrganization設定を上書きすると説明されています。(GitHub Docs)
このため、Organizationの上限を変更したのに特定のリポジトリだけ動作が違う場合は、そのリポジトリの設定も確認してください。
リポジトリ側の確認場所は次の通りです。
Repository
→ Settings
→ Moderation options
→ Interaction limits
→ Pull request limits信頼できるコントリビューターはバイパスリストを利用する
リポジトリ単位の設定では、信頼できるコントリビューターをバイパスリストへ追加できます。バイパス対象のユーザーは、Write権限を付与しなくても、設定されたPR数の上限を超えてPRを作成できます。
GitHubの公式ドキュメントでは、リポジトリのバイパスリストへ最大100ユーザーを登録できると説明されています。(GitHub Docs)
Write権限はコードのPushを可能にする強い権限です。PR数制限を回避する目的だけでWrite権限を与えるのではなく、次の順序で対応を検討してください。
- 不要なOpen PRを整理する
- 適切なOrganization上限へ調整する
- リポジトリ固有の上限を設定する
- 信頼できるユーザーをバイパスリストへ追加する
- 業務上必要な場合に限りWrite権限を付与する
一時的なInteraction limitsとの違い
Pull request limitsは、「Interaction limits」という設定画面にあります。しかし、同じ画面にある一時的なインタラクション制限とは、目的と解除条件が異なります。
| 比較項目 | Pull request limits | 一時的なInteraction limits |
|---|---|---|
| 制限方法 | 同時に開けるPR数を制限 | 特定ユーザー層の操作を一時制限 |
| 主な対象 | Write権限のないユーザー | 新規ユーザー、過去の貢献がないユーザーなど |
| 対象操作 | 新しいPRの作成 | コメント、Issue作成、PR作成、リアクションなど |
| 解除条件 | PRをClose・Mergeする、または設定を変更する | 指定期間が終了する |
| 期間設定 | PR数による制御 | 24時間、3日、1週間、1か月、6か月 |
一時的なInteraction limitsは、荒らしや急激な投稿増加への対応に向いています。Pull request limitsは、通常運用の中で同時Open PR数を継続的に管理するための設定です。(GitHub Docs)
同じ設定画面にあるため、管理者は「Temporary interaction limits」だけを確認して終わらないようにしてください。PR数の上限は、ページ下部にある別の「Pull request limits」で確認します。
REST APIでOrganizationの設定を確認する方法
多数のOrganizationを管理している場合や、設定監査を自動化したい場合は、REST APIでもPull Request上限を確認できます。
Organizationの設定を取得するエンドポイントは次の通りです。
GET /orgs/{org}/interaction-limits/pulls/creation-cap実行例は次の通りです。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/ORG/interaction-limits/pulls/creation-cap"上限が有効な場合は、次のような結果が返されます。
{
"enabled": true,
"max_open_pull_requests": 1
}enabledが有効状態、max_open_pull_requestsが同時Open PR数の上限です。APIでOrganizationの設定を取得・変更するには、OrganizationのAdministration権限が必要です。公式ドキュメントの例では、Fine-grained personal access tokenなどにOrganization AdministrationのWrite権限を求めています。(GitHub Docs)
設定を変更するエンドポイントは次の通りです。
PATCH /orgs/{org}/interaction-limits/pulls/creation-cap次は上限を1件として有効化する例です。数値の1はAPIの使い方を示すサンプルであり、すべてのOrganizationに推奨する値ではありません。
curl -L \
-X PATCH \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $GITHUB_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/ORG/interaction-limits/pulls/creation-cap" \
-d '{"enabled":true,"max_open_pull_requests":1}'APIで設定を変更する場合は、いきなり本番Organizationへ適用せず、検証用Organizationで動作を確認してください。また、APIバージョンの指定値は将来変更される可能性があるため、実装時点の公式ドキュメントを確認する必要があります。
Pull Request上限を設定するときの判断基準
上限を必要以上に低くすると、正常な外部コントリビューターまで作業を止めてしまいます。反対に高すぎると、レビュー待ちPRやCI実行の増加を十分に抑えられません。
レビュー可能な並行数を基準にする
上限は、レビュー担当者が無理なく処理できる並行PR数を基準に決めます。
たとえば、1人のコントリビューターから複数の機能追加、ドキュメント修正、不具合修正が同時に届く運用であれば、1件だけに制限すると開発を妨げる可能性があります。
一方、通常は1件ずつレビューする小規模プロジェクトで、大量の自動生成PRやスパム的なPRが問題になっている場合は、低めの上限が有効です。
Organization全体へ適用する前に実績を確認する
設定前に、過去のPR運用を確認します。
| 確認項目 | 判断に使う内容 |
|---|---|
| 外部ユーザー1人あたりの通常Open PR数 | 正常な利用者を止めない上限 |
| PRの平均レビュー期間 | Open PRが蓄積しやすいか |
| Closeされず放置されるPR数 | 整理ルールが必要か |
| CIの実行時間と費用 | 不要なPRによる負荷 |
| 高頻度コントリビューター | バイパス設定が必要か |
| リポジトリごとの運用差 | 個別上書きが必要か |
Organization内に性質の異なるリポジトリが混在する場合は、すべてを同じ上限に固定するより、Organization設定を基本値とし、必要なリポジトリだけ個別調整する方が運用しやすくなります。
CONTRIBUTING.mdにもルールを記載する
外部コントリビューターが多いリポジトリでは、CONTRIBUTING.mdに次の内容を記載しておくと混乱を減らせます。
同時にOpenできるPull Request数には上限があります。
新しいPull Requestを作成できない場合は、既存のOpen PRを確認してください。
不要になったPRはCloseし、レビュー完了済みのPRについてはMaintainerへ連絡してください。
作業途中の変更はDraft Pull Requestとして作成してください。GitHubの設定だけで制限するのではなく、制限の目的と解除方法を利用者へ説明することが重要です。
運用で起こりやすい失敗
Organizationの設定だけを確認する
特定リポジトリに後から個別設定が追加されていると、Organizationの設定と異なる動作になる可能性があります。Organization設定を変更した後は、主要リポジトリのInteraction limitsも確認してください。
Draft PRまで数えてしまう
Draft PRは上限にカウントされません。利用者から「Open PRは上限以上あるのに、新しいPRを作成できた」と問い合わせがあった場合は、それぞれがDraftかどうかを確認します。
待てば自動解除されると案内する
Pull request limitsは、一時的なInteraction limitsとは異なります。Open PRが減らない限り、時間の経過だけでは状況が変わらない可能性があります。
制限回避のためにWrite権限を付与する
Write権限を付与すると、対象リポジトリへコードをPushできるようになります。PR上限を回避するだけの目的で権限を引き上げるのは適切ではありません。リポジトリ固有の設定やバイパスリストを先に検討してください。
上限値だけ決めて既存PRを整理しない
PRが長期間Openのまま放置される運用では、上限を設定しても利用者が頻繁にブロックされます。一定期間更新がないPRへの確認、Close条件、再開方法なども合わせて決めておく必要があります。
新しいPRを作れないときはOpen PR数とInteraction limitsを確認する
GitHubで新しいPRを作れない場合は、対象リポジトリで自分が開いているDraft以外のPRを確認してください。Write権限のないユーザーが設定上限に達している場合、不要なPRをCloseするか、Maintainerに既存PRをMergeしてもらう必要があります。
Organization管理者は、次の場所で設定を確認します。
Organization Settings
→ ModerationまたはModeration tools
→ Interaction limits
→ Pull request limitsOrganization単位の設定は、複数のパブリックリポジトリへ共通ポリシーを適用できる便利な機能です。ただし、リポジトリ固有の上書き設定、Draft PRの扱い、公式ドキュメント間の適用範囲の記述差には注意が必要です。
まずはWrite権限のない検証用ユーザーで動作を確認し、正常なコントリビューターを妨げず、レビュー負荷とCI実行を抑えられる上限を設定してください。
コメント