Claude CodeでPRを作成する手順 — gh pr createまでの自動化フロー

Claude Codeに「PRを作って」と一言頼むだけでも動きますが、変更内容の要約からgh pr createでの生成、説明文の推敲、作成後のセッションの呼び戻しまでを手順として分けると、レビューしやすいPRが安定して出てきます。本稿ではその一連の流れをまとめます。

Claude CodeでPRを作成するとはどういう作業か

Claude CodeはGitHubのgh CLIを介してPRを作成します。実体はClaude Codeがgit差分とコミット履歴を読み、gh pr createをBashツールで実行する、という組み合わせです。仕組みそのものは単純ですが、いきなり「PRを作って」と頼むと、変更の意図が要約に反映されないことがあります。先に変更内容を言語化させ、その要約をもとにPRを生成させると、説明文の質が安定します。

この作業が向いているのは、複数のコミットにまたがる変更を1本のPRにまとめて説明する場面です。差分そのものは読めばわかりますが、「なぜその変更をしたか」という意図は差分だけでは読み取れません。Claude Codeは会話の履歴やコミットメッセージから意図を拾い、それをPRの説明文に反映します。逆に、意図をひと言も伝えていない状態でPRだけ作らせると、変更点の機械的な列挙で終わりやすくなります。

始める前に確認すること

必要なのは3点です。gh CLIがインストールされ認証済みであること、対象の変更がコミットされていること、そしてリモートリポジトリへのpush権限があることです。どれか1つでも欠けていると、手順の途中でエラーになり最初からやり直すことになります。認証はローカルのgh設定に依存するため、Claude Code側での追加設定は不要です。

gh pr createはリポジトリへの書き込みを伴うコマンドのため、初回実行時は許可ダイアログが挟まります。PR作成を何度も行うワークフローなら、Bash(gh pr create:*)のようにコマンドを絞って許可リストに追加しておくと、以降は確認なしで実行できます。対象を絞らずにBash(gh:*)のように広く許可するとgh repo deleteのような破壊的な操作まで許可してしまうため、コマンドを絞る書き方を選びます。許可リストの書き方全体はClaude Code settings.json完全ガイドにまとめています。

手順1: 変更内容をClaudeに要約させる

まず、これまでの変更をひとまとまりの言葉にさせます。ここで生成される要約が、後続のPR説明文の土台になります。

認証モジュールに加えた変更を要約して

複数のコミットにまたがる変更でも、Claude Codeはgitの履歴を読んで一連の意図として要約します。要約に抜けや誤りがあれば、この段階で指摘して直させておくと、次の手順の精度が上がります。特に、複数の関心事が1つのブランチに混ざっている場合は、この時点で気づけると後段の分割判断がしやすくなります。

手順2: gh pr createでPRを生成する

要約を踏まえてPRを作らせます。指示は「PRを作って」の一言でも動きますが、直前に要約させたやり取りがあるため、説明文にはその内容が反映されます。

PRを作って

タイトル・本文・ベースブランチはClaude Codeが変更内容から組み立てるため、社内テンプレートに沿った書式が必要な場合は、テンプレートの場所か書式を事前に伝えておきます。

リポジトリに.github/pull_request_template.mdが置かれている場合は、テンプレートの項目に沿って本文を書くよう指示に含めておくと、Claude Codeが各項目に対応する内容を変更差分から埋めてくれるため、空欄のまま提出されにくくなります。ただしテンプレートの意図と違う場所に情報が入ることもあるため、提出前の確認は省略しません。テンプレートの有無や書式は指示する側が把握しておく必要があり、Claude Code側が自動で読み取って合わせてくれるとは限らない点も覚えておきます。

手順3: PR説明文を推敲させる

生成された説明文が薄い、あるいは背景の説明が足りないと感じたら、そのまま直させます。セキュリティ上の考慮点やレビュー観点を追加で書かせておくと、レビュアーが確認すべき箇所を先回りして示せます。

セキュリティ改善に関する背景をもっと詳しくPRの説明に加えて

PRを提出する前に、生成された説明文を自分の目で確認します。Claude Codeに潜在的なリスクや考慮点を指摘させるひと手間を挟んでおくと、レビュー段階での手戻りを減らせます。破壊的変更や設定ファイルの互換性に関わる変更では、この指摘を求める一手間が特に効きます。

手順4: 作成後のセッションをPRに紐づけて呼び戻す

gh pr createでPRを作成すると、そのセッションは作成されたPRに自動でリンクされます。あとからレビューコメントに対応するとき、このリンクを使えば同じ文脈のまま作業を再開できます。この紐づけはClaude Code v2.1.27で整備されたPR起点ワークフローの一部です。

claude --from-pr 1234

自分のPR番号に置き換えて実行すると、そのPRにひも付いたセッションだけに絞り込んだ選択画面が開きます。PR番号を覚えていない場合は、セッション内で/resumeを実行し、選択画面の検索欄にPRのURLを貼り付けても同じセッションにたどり着けます。この検索欄がPRのURLを受け付ける挙動はClaude Code v2.1.122で加わりました。

よくあるつまずき

gh CLIが未インストール、または未認証だとPR作成が失敗する。Claude Code側にはこの状態を解決する手段が無いため、gh auth statusで認証状態を確認してから作業を始めます。組織のSSO設定によっては、認証済みでも対象リポジトリへのアクセス権限が別途必要になることがあります。

コミットしていない変更はPRに含まれない。Claude Codeに変更を要約させても、ワーキングツリーの未コミット分はgit履歴に現れないため要約から漏れます。PRを作らせる前に、対象の変更がコミット済みかを確認します。git statusで未追跡ファイルが残っていないかを見る一手間が、この漏れを防ぎます。

「PRを作って」だけで済ませると、説明文が変更点の列挙で終わりやすい。背景や設計判断の理由まで書かせたいときは、手順1で要約させる段階か、手順3の推敲段階で明示的に指示します。生成後に読み直さずそのまま提出すると、レビュアーに意図が伝わらないPRになりがちです。

大きな差分をまとめて1つのPRにすると、Claude Code自身の要約もレビュアーの負荷も上がる。変更が複数の関心事にまたがるなら、コミット単位かディレクトリ単位でPRを分けたほうが、要約もレビューも軽くなります。

ベースブランチを確認せずに作成すると、意図しない相手にPRが向いてしまう。フィーチャーブランチから派生したブランチで作業していると、Claude Codeが差分元と誤ったブランチをベースに選ぶことがあります。作成後に表示されるベースブランチ名は必ず確認します。

よくある質問

コミットメッセージも一緒に書かせられますか

書かせられます。「変更をコミットして」と頼めば、Claude Codeは差分を読んでコミットメッセージを生成し、コミットまで実行します。PR作成の前段としてこの指示を挟んでおくと、要約の材料がコミット履歴として残り、後続のPR説明文にも反映されやすくなります。

複数人がレビューするPRでも同じ手順で問題ありませんか

問題ありません。ただしレビュアーが複数いる場合は、手順3の推敲でレビュー観点を明示的に書かせておくと、確認漏れが減ります。「この変更で特に注意して見てほしい箇所は」のように聞くと、Claude Code自身がリスクの高い変更点を先に指摘してくれます。

ドラフトPRとして作成することはできますか

gh pr createは--draftオプションでドラフトPRを作成できるため、「ドラフトPRとして作って」のように指示すれば同じフラグ付きで実行させられます。レビュー準備が整うまでレビュアー通知を出したくない場合に使えます。

PR作成後にレビューコメントへ対応する流れも任せられますか

任せられます。claude --from-prまたは/resumeでPRに紐づいたセッションを呼び戻したあと、「レビューコメントに対応して」と頼めば、Claude CodeはGitHub上のコメントを読み取り、該当箇所を修正してから再度コミットします。修正内容がコメントの指摘と食い違っていないか、最後は自分の目で確認します。

GitLabやBitbucketでも同じ手順が使えますか

gh pr create自体はGitHub専用のコマンドです。GitLabではマージリクエストを作成する別のCLI操作が必要になり、コマンド名も異なります。ホストによって使うコマンドが変わる点だけ意識しておけば、要約させてから生成させるという手順の骨格自体は同じように使えます。

まとめ

Claude CodeでのPR作成は、変更内容の要約→gh pr createでの生成→説明文の推敲→セッションの呼び戻し、という4手順に分けると、レビューしやすいPRが安定して出てきます。ghの認証とコミット漏れの確認だけ先に済ませておけば、あとの手順は指示を出すだけで完結します。手順1で要約を挟んでおけば、最後の生成指示自体は「PRを作って」の一言に短縮しても内容は引き継がれます。