定期実行・自動化 2026年9月13日 5分で読めます

【連載⑥】Pull Requestを怖がらず作る

【連載⑥】Pull Requestを怖がらず作る

> 連載「Claude Code × GitHub 運用フロー」（全8回）

Claude CodeでコードをGitHubにpushしたあと、次に出てくる「Pull Request（プルリクエスト）」という言葉で、また手が止まりました。

「タイトルは何て書けばいいの」「説明文って何を書くもの？」「CIって赤くなったらどうすればいいの」——調べれば調べるほど不安が増える、あの感じです。

この記事を読むと、Pull Requestを作ってからマージ待ちの状態にするまでの流れが、実際にわたしがClaude Codeと一緒にやった記録つきでわかります。タイトルと説明文の作り方、CIチェックとの付き合い方まで、一通り整理しました。

一言で言うと：PRは「レビューをお願いする手紙」

先に結論です。

Pull Request（PR）とは、「この変更をmainブランチに取り込んでいいですか？」とお願いする手紙のようなものです。手紙なので、相手（レビューする人）が読んで判断しやすいように書く必要があります。

逆に言えば、コード自体はもうpush済みで完成しています。PRは「それを取り込んでもらうための説明」を添える作業。ここを勘違いしていた最初のわたしは、PRを作ること自体が新しい技術的な操作だと思って身構えていました。実際はほぼ「文章を書く」作業です。

Claude CodeでPull Requestを作る手順

わたしがやったときは、Claude CodeにGitHub CLI（`gh`）経由でお願いしました。


今回の変更をPull Requestにして。
push済みの内容から、タイトルと説明文を考えて提案して。
内容を確認してから作成してほしい。

Claude Codeは、mainブランチから分岐した後のコミット履歴を分析して、タイトル案と説明文の下書きを提示してくれました。ここで大事なのは「提案して」とお願いすること。いきなり作成されると、内容を見ないまま公開されることになるので、必ず一度提示してもらってから進めるようにしています。

なお、この操作にはGitHub CLI（`gh`コマンド）がPCにインストールされている必要があります。未インストールの場合はエラーになりますが、そのときはClaude Codeに「GitHub CLIをインストールして」と伝えれば、OS（macOS／Windows）に応じた手順を案内してくれます。

調査ベースの話になりますが（2026年9月時点）、GitHub CLIを使う場合は事前に `gh auth login` でログインしておく必要があるようです。わたしの環境ではすでにログイン済みだったので、この手順自体は今回試せていません。初めて`gh`を使う方は、認証まわりで一度つまずく可能性がある点は正直に書いておきます。

PRのタイトル・説明文の作り方

ここがいちばん悩んだところです。調べてみると、良いPRの説明文には共通して次の4つが含まれていました。

**何を変更したか**（例：ログイン画面のバリデーション処理を修正）
**なぜ変更したか**（背景・きっかけ）
**影響範囲**（他の機能に影響しないか）
**テスト方法**（どう動作確認したか）

タイトルは「Fix: ○○を修正」のように、変更内容が一目でわかる形にするのが定石のようです。Claude Codeにお願いするときも、この4項目を意識して指示すると、説明文の質が安定しました。


PRの説明文に、次の4つを含めて書いて。
1. 何を変更したか
2. なぜ変更したか
3. 影響範囲
4. 動作確認の方法

自分で一から考えるより、Claude Codeにたたき台を出してもらって、そこから「ここは違う」と直していくほうが圧倒的に早いと感じています。

CIチェックが赤くなったときの心構え

PRを作ると、自動テスト（CI）が走ります。最初は、ここで赤い×印が出るたびに心臓が縮む思いでした。

調べて分かったのは、CIが失敗しても、それ自体は「悪いこと」ではないということです。マージする前に問題を見つけてくれる仕組みなので、むしろ「先に気づけてよかった」と捉えるものだと理解しました。

わたしが実際にやっている対処は、Claude Codeにこう聞くことです。


CIのチェックが失敗しています。
失敗しているログの内容を確認して、原因と対処法を教えて。

これまで数回、CIが赤くなる場面に遭遇しましたが、ログをClaudeに読んでもらうと原因がすぐ特定できることが多く、思っていたよりも怖いものではありませんでした。ただ、複雑な依存関係が絡むエラーは、まだ自分一人では判断しきれない部分もあり、そこは正直「試行中」です。

また、PRは小さい単位で出すほどレビューしやすいという情報もよく見かけました。1つのPRに複数の変更を詰め込みすぎず、機能ごとに分けるのが基本のようです。わたしもこれを意識してから、レビュー待ちの時間が短くなった実感があります。

読者がそのまま貼れるプロンプト

PR作成からCI確認までを一気に頼みたいときは、こう伝えています。


push済みの変更をPull Requestにしたいです。
タイトルと説明文（変更内容・理由・影響範囲・確認方法を含む）を提案してください。
PRを作成する前に、対象ブランチと変更差分を表示してください。
私が内容を確認してから作成してください。
作成後にCIのチェック結果も確認して、失敗していたら原因を教えてください。
不明点があれば推測せず、確認事項として列挙してください。

「提案 → 確認 → 実行」の順番を指示に入れておくと、内容を見ないまま公開される心配がなく安心です。