GitHub の draft PR 制限：エージェント作業を積む前に入口を決める

エージェントがコードを速く作るほどレビュー待ちも増えます。draft PR は未準備の状態を示しますが、リポジトリの仕事から消えるわけではありません。GitHub の変更を入口の見直しに使いましょう。

10月8日の変更

GitHub は2026年10月8日、PR 制限に draft も含める設定を発表しました。以前はユーザーの制限に数えられませんでした。全リポジトリの設定が自動変更されたとは解釈できません。

公式発表は低品質の投稿やスパムによる混雑、通知、CI 実行の負担を減らす目的を説明します。万人向けの推奨数値はありません。実際の設定と対象を確認してください。

draft は準備状況、制限は入ってくる仕事量の方針です。未完成でも保守容量は使います。一方、すべての draft が高価な CI を実行するわけでもありません。トリガーと履歴を確認します。

同じ issue の三つの案を draft にすると比較しやすい反面、三つの branch と diff を保ちます。三つのリリース確約ではなく実験です。可能なら issue で案を比較し、レビュー可能な目的のある PR を開きます。

開いている draft と通常 PR の数、担当者と目的、最後の意味ある更新を記録します。その後 CI、待ち時間、重複を見ます。通知が多い印象だけで制限すると有用な貢献まで止めかねません。

エージェントにリポジトリ、issue、既存 PR の対応を持たせます。作成失敗の直後に別名で新規 PR を開かず、既存作業を確認して更新します。これは運用提案であり GitHub の新しい自動機能ではありません。

既存作業の続け方、レビュー準備の基準、相談先を示します。通常 PR への変換で方針を回避できるとは案内しません。閉じる・アーカイブする前に担当と有用な内容を確認します。

依存する複数 PR は数だけで低品質とは言えません。小さな diff の積み重ねと同じ投稿の反復は異なります。制限は入口を守り、レビューやテスト、配信判断を代替しません。

一つのリポジトリで方針と例外を文書化し、実設定を確認します。同期間で draft 増加、既存 PR 再利用、待ち時間、有用な貢献の阻害を比べます。件数減少だけでは品質向上を証明できません。

頻度を上げる前に同じ仕事が同じ PR に戻る経路を作ります。GitHub は設定経験のフィードバック先を示しています。未確認の利用者反応や改善効果は作っていません。

2026年10月9日確認。製品機能と運用提案を区別してください。