GitHubは2026年10月8日付の発表で、ユーザー単位のPR上限にドラフトPRも算入するよう設定できる変更を知らせました。従来は上限を設定していても、ドラフトPRを無制限に作成できました。PRの量を管理している会社は、ドラフトの扱いも含めて運用を確認する必要があります。
ドラフトも上限の対象にできる
PR(プルリクエスト)は、コードの変更を提案し、確認を求めるためのものです。ドラフトPRは、作業途中の提案として扱うPRを指します。
今回の変更は、ユーザー単位で設定するPR上限に、ドラフトPRも含められるようにするものです。従来はドラフトが算入されなかったため、上限設定だけではドラフトの作成数を抑えられませんでした。GitHubは、今回の変更でその抜け穴を抑えると説明しています。
ただし、「算入するよう設定できる」という発表です。すべての利用者に既定で適用される変更とは読み分ける必要があります。既存設定が自動で変わるか、上限の具体的な値、設定画面の場所、対象プランや版は、発表には書かれていません。
日本での提供は発表には書かれていません。日本の利用者が設定できるかを、今回の発表だけで断定することはできません。
狙いは通知とCI実行を伴うスパムの抑制
GitHubによると、保守担当者は低品質な貢献の増加に直面しています。ドラフトを上限に含めることで、スパムによるリポジトリの混雑を減らし、それに伴う通知やCI実行も減らすのに役立つとしています。リポジトリはコードなどの保管場所、CIはコードの変更に応じて自動で検証などを行う仕組みです。
会社で確認したいのは、上限設定の有無だけではありません。ドラフトを作業途中の共有に使っているか、不要な提案への対応が保守担当者の負担になっているかも、判断材料になります。
ドラフトを含める設定を検討する場合は、スパム対策と普段の開発手順を分けて確認するとよいでしょう。GitHubの説明は通知やCI実行の削減に役立つというものです。削減量や、会社ごとの費用への効果は示されていません。
影響する会社・しない会社
- 影響する: GitHubでユーザー単位のPR上限を設定し、ドラフトPRも利用している会社です。ドラフトを含める設定にするかが、運用上の確認事項になります。
- 影響する: スパムによるPRの混雑や通知、CI実行への対応に負担を感じている保守担当者がいる会社です。今回の設定変更を対策候補として検討できます。
- 影響しない: GitHubのPRを業務で使っていない会社は、今回の変更に伴うPR運用の見直しは対象になりません。
- 影響しない: 対象外となるプラン・版・地域の条件は、発表には書かれていません。契約名や所在地だけで影響なしとは判断できません。
情シスが今日やること
- 今日、開発責任者やリポジトリの保守担当者に、ユーザー単位のPR上限を設定しているか確認します。発表には管理画面の具体的な場所がないため、担当者と実際の設定画面を確認し、ドラフトを含める項目が表示されるかを記録してください。表示されない場合は、利用可否を未確認として扱います。
- 設定を変える前に、担当者へドラフトPRの利用目的を聞きます。作業途中の共有に使っているものと、対応不要と判断しているものを分け、通知やCI実行で困っている点をまとめます。PRの多さだけでスパムと決めつけないことが重要です。
- ドラフトを算入するかは、保守担当者と開発責任者で決めます。決定前に、現在の上限と、ドラフトも含めた場合の作業手順を確認してください。発表には推奨の上限値がないため、記事の情報だけで一律の値を決めないようにします。
- 設定を変更する場合は、その前に開発者へ対象と変更内容を知らせます。変更後は、保守担当者と通知やCI実行、ドラフトを使う作業への影響を確認してください。発表には必須の対応期限は書かれていないため、社内で確認日と担当者を決めて進めます。
