「実装はまだ途中だけれど、方向性だけ先に見てほしい」。そんなとき、通常のPull Requestを開くとレビュー開始の合図だと受け取られそうで迷いますよね。
GitHubのDraft Pull Requestを使えば、差分と説明を共有しながら、正式なレビュー依頼は後のタイミングに回せます。
作成の手順と、レビュー可能な状態への切り替え方、Draftへ戻す方法までまとめました。
Draft Pull Requestは作業途中を共有するための状態
Pull Requestは、変更差分を見せながらコメントやレビューを受け、取り込むかどうかを決めるための場所です。
とはいえ、実装や文章が完成する前に、方向性だけ先に共有したい場面もありますよね。
Draft Pull Requestは、そうした作業途中の変更を共有するための状態です。Draftの間はマージできず、コードオーナーへのレビュー依頼も自動では届きません。
コードオーナーとは、CODEOWNERSというファイルで「このファイルはこの人が見る」と決めておくレビュー担当者のことです。
一方で、差分や説明欄、コメント欄は通常のPull Requestと同じように使えます。「共有はしたいけれど、まだ承認を求める段階ではない」という状態を、Pull Request自体に示せるのがDraftの利点です。
| 項目 | Draft Pull Request | 通常のPull Request |
|---|---|---|
| マージ | できない | 条件を満たせばできる |
| コードオーナーへのレビュー依頼 | 自動では届かない | 作成時に自動で届く |
| 差分・説明・コメント | 使える | 使える |
| 向いている段階 | 方向性の相談、途中経過の共有 | マージに向けた正式なレビュー |
完成前に相談したいときはDraftから始める
次のような相談をしたいなら、通常のPull RequestよりDraftから始めた方が意図が伝わります。
- 実装方針が合っているか、早い段階で確認したい
- 画面や文章の一部だけ、先に見てもらいたい
- CIを動かしながら、残りの修正を進めたい
- 大きな変更を、小さな単位に分けて見せたい
- 作業内容と未完了項目を、Issueとは別に差分付きで共有したい
逆に、変更も確認も済んでいて、レビューを通ればそのままマージできる状態なら、最初から通常のPull Requestで構いません。
Draftを必ず経由しなければならない決まりはないんです。
迷ったら、いま欲しいのが「方向性への相談」なのか「マージに向けた正式なレビュー」なのかで考えると分かりやすいでしょう。前者ならDraft、後者なら通常のPull Requestです。
個人開発でもDraftは役立ちます。別の作業へ移る前に途中経過をPull Requestへまとめておけば、CIの結果と残作業を一か所で見返せるのが便利なところですね。
ただ、未完成のブランチを残しておきたいだけなら、リモートへpushするだけで足ります。差分の説明や相談の履歴まで残したいかどうかで選びましょう。
GitHubの画面からDraft Pull Requestを作る手順
Web画面での作り方は、通常のPull Requestとほとんど変わりません。違うのは最後に押すボタンだけなので、ブランチの確認と説明欄の書き方に時間をかけるのがポイントです。
1. 作業ブランチをpushして比較画面を開く
変更を作業ブランチへコミットし、GitHubへpushします。
リポジトリのページでそのブランチを選ぶと、ファイル一覧の上にCompare & pull requestのボタンが出るので、そこから作成画面を開きましょう。
作成画面では、取り込み先のbaseブランチと、変更を含むcompareブランチを確かめてください。ここを取り違えると、意図しない差分が並んでしまいます。
表示されたコミットと変更ファイルの一覧に、関係のないファイルや秘密情報が混ざっていたら、作成は止めてブランチ側を直すのが先です。
2. タイトルと説明を書く
Draftだからといって、タイトルと説明を後回しにするのはおすすめしません。見る側は、説明欄を読んで初めて「どこまでコメントしてよいか」を判断できるからです。
最低限、次の内容を短く書いておきましょう。
- 何を、なぜ変更しているのか
- 現時点で確認できていること
- まだ終わっていない作業
- いま相談したいこと
- Ready for reviewへ切り替える条件
たとえば「画面レイアウトは見てほしいが、エラー処理とテストは未完了」と一言あるだけで、レビューする側の迷いはかなり減ります。
3. Create Draft Pull Requestを選ぶ
説明を書き終えたら、作成ボタン横のドロップダウンを開いてCreate Draft Pull Requestを選び、続けてDraft Pull Requestを押します。
そのままCreate Pull Requestを押すと通常のPull Requestになるので、ここだけは気をつけてください。
作成後は、Pull RequestがDraft表示になっているかを確認します。
URLを共有するときに「方向性だけ見てほしい」「正式なレビュー依頼は後で送る」と一言添えておけば、相手も反応しやすいでしょう。
組織のリポジトリでDraftを選べない場合は、組織オーナーにDraft Pull Requestの利用を申請する必要があるかもしれません。設定は組織ごとに異なるので、推測で判断せず管理者に確認してみてください。
GitHub CLIからDraftを作る方法
GitHub CLIを使っているなら、作業リポジトリのディレクトリで次のコマンドを実行します。
gh pr create --draft--draftを付けるとDraftとして作成され、あとはタイトルや本文の入力へ進みます。取り込み先のブランチは--base、変更を含むブランチは--headで明示することも可能です。
タイトルと本文もコマンドで渡すなら、次のように書けます。
gh pr create --draft \
--title "設定画面の入力チェックを追加" \
--body "エラーメッセージとテストは未完了。入力条件の方向性を見てほしいです。"これはあくまで最小限の例です。リポジトリにPull Requestテンプレートや運用ルールがあれば、本文はそちらに合わせましょう。
スクリプトに組み込む場合も、対象のリポジトリとブランチが意図どおりかを実行前に確かめる点は、Web画面と同じです。
Ready for reviewへ切り替える前の確認
変更がレビューできる状態になったら、Pull Request下部のマージ欄にあるReady for reviewを押します。切り替えた時点で、該当するコードオーナーへレビューが依頼される仕組みです。
CODEOWNERSを設定していないリポジトリなら自動で依頼される相手はいないので、必要に応じてReviewers欄からレビュアーを指定しましょう。
つまり、Ready for reviewへの切り替えは、表示の変更ではなく「正式なレビューを始めてよい」という合図です。押す前に、次の点を見直しておくと安心です。
- 目的と変更範囲、見てほしい箇所が説明欄に書かれている
- 未完了項目が片付いているか、残る項目が明記されている
- 変更と関係のないファイルが混ざっていない
- 必要なテストや手動確認の結果が書かれている
- 秘密情報や個人情報が、差分・ログ・添付に含まれていない
すべてを完璧に終えてからでないと切り替えられない、というわけではありません。大事なのは、チームで決めた「レビュー開始の条件」を満たしているかどうか。
残課題があるなら説明欄に書き、どの範囲をレビューしてほしいかをはっきりさせておけば十分でしょう。
GitHub CLIならgh pr readyで切り替えられ、引数を付けなければ現在のブランチに対応するPull Requestが対象になります。
どちらの方法でも、切り替えたあとはレビュー依頼先と状態の表示を一度確認してください。
通常のPull RequestをDraftへ戻す方法
通常のPull Requestとして作ったあとでも、Draftへはいつでも戻せます。うっかり通常の形で作ってしまったときや、レビューを受けて追加の修正が必要になったときに使う機能です。
状態を変更できるのは、Pull Requestの作成者と、リポジトリへのwrite権限を持つ人です。
Web画面では、対象のPull Requestを開き、右側のReviewers欄にあるConvert to draftをクリック。確認画面でもう一度Convert to draftを押せば完了です。
CLIからはgh pr ready --undoで同じ操作ができます。
Draftへ戻したPull Requestは、再びReady for reviewにするまで誰もマージできません。
気をつけたいのは、Draftへ戻しても、すでに通知を購読している人の購読は解除されない点です。状態を戻しただけでは、関係者の期待までリセットされるわけではありません。なぜDraftへ戻したのか、何を直してから再レビューを頼むのかを、コメントや説明欄に残しておきましょう。
Draft運用で混乱を減らす書き方
Draftという表示だけでは、作業がどこまで進んでいるかまでは伝わりません。説明欄に短いチェックリストを置き、作業に合わせて更新していくのが実務的です。
たとえば、次のような形です。
## 現在の状態
- [x] 基本画面を作成
- [x] 正常系の動作を確認
- [ ] エラー表示を追加
- [ ] 自動テストを追加
## いま確認してほしい点
- 入力条件の分け方が妥当か
- 画面内の用語が既存機能と一致しているか
## Ready for reviewへ切り替える条件
- エラー表示とテストを追加する
- 関係のない差分がないことを再確認する未完了の作業と「レビューで見てほしいこと」を、別の見出しに分けるのがポイントです。
途中でコメントをもらったら、対応したあとにどこを直したかを返信しておきます。Draftの期間が長くなるほど、タイトルや説明、チェック項目は実態とずれていきます。
Ready for reviewへ切り替える前に、本文全体を一度読み直すのがおすすめです。
注意点と向いている場面
Draftは早めの共有に便利ですが、できるのは「いまはレビュー前の段階です」と示すところまでです。閲覧範囲の制御やマージ条件の管理は、別の仕組みが担っています。
Draftはアクセス制御ではない
Draftにしても、誰がリポジトリやPull Requestを閲覧できるかは変わりません。
公開リポジトリなら、作業途中の説明や差分も誰でも見られる状態です。機密情報や個人情報は、Draftであっても書かないでください。
Draftはブランチ保護やCIの代わりではない
Draftの間はマージできませんが、Ready for reviewへ切り替えたあとの承認数やステータスチェック、対象ブランチへの変更条件は別の設定で決まります。
マージ条件を管理したいならRulesetsやブランチ保護、テストを自動で回したいならGitHub ActionsなどのCIを組み合わせましょう。
早すぎる共有は説明不足になりやすい
差分がほとんどなく、目的も書かれていないDraftを渡されても、受け手は何を見ればよいのか分かりません。
方向性を見てほしいなら、最小限の差分と変更理由、相談したいことがそろってからURLを共有するのがおすすめです。
小さな修正なら通常のPull Requestで十分
Draftが特に力を発揮するのは、方向性を早めに確かめたい作業や、複数の段階に分かれる実装、差分が大きくなる前にレビューの観点をそろえておきたい作業です。
一方、誤字の修正や設定値の小さな変更のように、完成条件がはっきりしていてすぐ終わる作業までDraftにする必要はありません。
切り替えの手間が増えるだけなので、最初から通常のPull Requestで出した方がシンプルです。
まとめ
Draft Pull Requestを使うと、作業途中の差分と説明を共有しながら、正式なレビューの開始を後ろへずらせます。
Draftの間はマージできず、コードオーナーへの自動レビュー依頼もありません。
運用で大切なのは、Draftという表示だけに頼らないことです。何が未完了で、いま何を相談したいのか、どの条件でレビュー可能になるのかを説明欄に書いておきましょう。
レビューできる状態になったら、説明を更新してReady for reviewへ。切り替えたあとに追加の修正が必要になっても、Draftへ戻して理由を共有すれば大丈夫です。
まずは方向性を見てほしい変更を1件選んで、短いチェックリスト付きのDraftから試してみてください。
