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

GitHubプルリクエストの書き方をAIに任せてみた

GitHubプルリクエストの書き方をAIに任せてみた

PRのタイトルと説明文、毎回何を書くか迷っていませんか？

GitHubプルリクエストの書き方、特にタイトルと説明文の書き方で毎回手が止まっていませんか。コードを書き終えた後、地味に時間を取られるのがここです。

「何を変更したか」は自分がいちばんわかっているはずなのに、いざ文章にしようとすると手が止まる。結局「修正」「対応」のような素っ気ないタイトルで出してしまい、後からレビュアーに「これ何のPRでしたっけ」と聞かれる——という経験がある方も多いのではないでしょうか。

この記事では、GitHubプルリクエストの書き方をClaude Codeに任せる方法を、実際に使えるプロンプトつきで紹介します。

結論：変更内容とコミット履歴を渡せば下書きができる

一言で言えば、変更したファイルとコミットメッセージをClaude Codeに渡すだけで、PRのタイトルと本文（変更の概要・影響範囲・テスト方法）の下書きを作ってもらえます。

Claude CodeはGitHub CLI（`gh`）を呼び出せるため、`git diff`や`git log`の内容を分析してタイトル案を提示し、本文には変更の概要・レビュアーが確認すべき影響範囲・動作確認の方法を整理して書き出してくれます。そのまま`gh pr create`を実行してPRを作成するところまで一続きで進められるのも大きな利点です。

なぜAIに任せて良いのか

複数の解説記事や実践レポートを調べたところ、共通していたポイントは次の3つでした（2026年9月時点の情報です）。

1. `gh pr create`には`–title`と`–body`のほか、コミットメッセージから自動でタイトル・本文を埋める`–fill`オプションが用意されている（GitHub CLI公式仕様）

2. Claude Codeは変更差分とコミット履歴を材料に、タイトル・概要・影響範囲・テスト方法をまとめた本文案を生成できるという実践例が複数の技術ブログで紹介されている

3. CLAUDE.mdにPRテンプレートの指示を書いておくと、生成される説明文のフォーマットを自分のチームのルールに合わせてカスタマイズできる

以前の記事「GitのコミットをAIに任せたら迷わなくなった話」ではコミットメッセージの自動化を扱いましたが、今回はその一歩先、PRの本文そのものをどう組み立てるかにフォーカスします。

実践：GitHubプルリクエストの書き方をClaude Codeに任せるプロンプト

実際にこの形で使うことを想定して作ったプロンプト例です。そのままチャット欄に貼って使ってください（gh CLIのインストールと`gh auth login`でのログインが事前に必要です）。


現在のブランチでの変更内容をもとに、GitHubプルリクエストのタイトルと本文を作成してください。

対象範囲：現在のブランチとmain（またはbaseブランチ）との差分すべて
確認事項：
- 本文には「概要」「変更内容」「影響範囲」「動作確認方法」の見出しを入れてください
- タイトルは日本語で簡潔に、変更内容が一目でわかる表現にしてください
- コミットメッセージだけでは意図が読み取れない変更があれば、実装した本人（私）に質問してください。推測で埋めないでください

実行前確認：
- git push、gh pr create の実行前に、変更差分の要約・pushするブランチ名・コミット件数・作成するPRのタイトルと本文を提示し、私が確認してから実行してください
- 不明点があれば推測せず、確認事項として列挙してください

このプロンプトのポイントは、push・PR作成という「一度実行すると他の人にも見える」操作の前に、必ず内容を提示させて確認するステップを入れていることです。タイトルと本文の下書きは任せつつ、実行の最終判断は自分に残す形にしています。

使ってみて感じたこと・まだ試せていない部分

コミットメッセージの自動化はこれまでも日常的に使ってきたので、その延長でPR本文もある程度うまく整理してくれる感触はあります。特に、複数のコミットにまたがる変更をまとめて「概要」として言語化してくれる部分は、自分で書くより早そうだと感じています。

一方で、次の点はまだ検証しきれていません。

チームのPRテンプレート（Issueへのリンク必須、レビュアー指定必須など）にどこまで柔軟に対応できるか
大規模な差分（ファイル数が多い、リファクタリングを含む）のときに、影響範囲の説明が的確かどうか

このあたりは実際に自分のリポジトリでいくつかパターンを試しながら、追って別記事で報告したいと思っています。

すでにPR作成の一連の流れ（Issue作成からclone、実装、テスト、commit・push、PR作成、レビュー、マージ）を8回にわたって解説した連載記事もあるので、全体の流れを知りたい方はそちらも参考にしてください。

[【連載⑥】Pull Requestを怖がらず作る](https://maahsachi.com/2026/09/13/claude-code-pull-request/)

この記事はその連載の「PR文章づくり」だけを切り出して深掘りした補足編という位置づけです。

気をつけたいこと

PRの本文は「レビュアーが読む前提」で書かれるものです。AIが作った文章でも、内容に誤りがないか一度は自分の目で確認してから提出しましょう
`–fill`や自動生成に頼りきると、コミットメッセージ自体が雑なままPRの説明も薄くなりがちです。コミット単位を整えることも合わせて意識すると効果が出やすいと感じています
チームで運用する場合は、CLAUDE.mdにPRテンプレートのルールを書いておくと、毎回同じフォーマットで出力されるようになり便利です