AIでGitHubのPR説明文を作るプロンプト｜差分・テスト・影響範囲をレビュー向けに整理
GitHubのプルリクエスト（PR）説明文をAIで作るなら、コード差分だけを渡すのではなく、変更の目的・主な差分・確認結果・影響範囲をセットで入力するのがポイントです。
このテンプレートは、PRを書く時間を短縮したい開発者や、レビューに必要な情報を漏れなく整理したいチーム向けです。出力は、そのままGitHubへ貼り付けやすいMarkdown形式に整えます。
この記事で分かることは次のとおりです。
- コピペして使えるPR説明文作成プロンプト
- AIへ渡す入力情報と、渡さない方がよい情報
- 曖昧で長い説明文を避ける改善方法
- バグ修正やリファクタリングへの応用方法
このプロンプトで作るPR説明文の完成イメージ
レビュー担当者が「なぜ変えたか」「どこを見ればよいか」「何を確認済みか」を短時間で把握できる説明文を目指します。
GitHubでは、PRのコミットや変更ファイル、baseブランチとcompareブランチの差分を確認できます。ただし、コードから読み取れるのは主に「何が変わったか」です。「なぜその変更が必要だったか」「どのケースを確認したか」までは、差分だけで十分に伝わらないことがあります。
そこで、AIには次の役割を任せます。
- 実装者が書いたメモをレビュー向けに整理する
- 差分から主要な変更点を抽出する
- テスト結果と未確認事項を分ける
- 推測できない内容を勝手に補わず、不足情報として示す
- リポジトリ所定の見出し順でMarkdownを出力する
ここがポイント: AIにPRの内容を推測させるのではなく、実装者が持つ背景情報とコード差分を、レビューしやすい順番に編集させます。
コピペ用：PR説明文を作るプロンプトテンプレート
以下のテンプレートでは、{}で囲んだ部分を案件に合わせて変更します。分からない項目は空欄にせず、不明または未確認と入力してください。
あなたはソフトウェア開発チームの編集担当です。
以下の情報をもとに、GitHubのプルリクエスト説明文を日本語で作成してください。
目的は、レビュー担当者が変更理由、主な差分、影響範囲、確認結果、レビュー上の注意点を短時間で把握できるようにすることです。
# 入力情報
## 変更の目的・背景
{解決したい問題、変更が必要になった理由}
## 関連Issue・資料
{Issue番号や関連URL。なければ「なし」}
## baseブランチ
{例: main}
## compareブランチ
{例: feature/add-export-filter}
## 変更ファイルの概要
{git diff --statなど、変更ファイルと変更量が分かる情報}
## コード差分または変更内容のメモ
{レビューに必要な範囲のdiff、コミット内容、実装メモ}
## 実行した確認
{実行したテスト、Lint、型チェック、手動確認と、その結果}
## 未実施の確認
{未実施のテストと理由。なければ「なし」}
## 影響範囲
{影響する画面、API、DB、設定、利用者、互換性など}
## レビューで特に見てほしい点
{設計判断、境界値、例外処理、性能、安全性など}
## 補足・制約
{デプロイ手順、既知の制約、対象外にした内容など}
# 作成ルール
- 入力にない事実、テスト結果、Issue番号、仕様、効果を作らない
- コード差分から断定できない目的や意図を推測しない
- 情報が不足している箇所は「要確認」と明記する
- ファイル名を並べるだけでなく、変更によって何が変わるかを説明する
- 実施済みの確認と未実施の確認を混ぜない
- 重要な変更を先に書き、細かな変更はまとめる
- レビュー担当者が確認すべきリスクを具体的に書く
- 冗長な挨拶、変更内容の重複、過度な称賛表現は入れない
- GitHubへそのまま貼れるMarkdownで出力する
# 出力形式
## 概要
{変更の目的と結果を2〜4文}
## 主な変更
- {主要な変更点}
## 影響範囲
- {影響する機能や利用者}
- {互換性やデータへの影響}
## 確認内容
- [x] {実施済みの確認}
- [ ] {未実施または追加確認が必要な項目}
## レビューしてほしい点
- {重点的に確認してほしい箇所と理由}
## 関連情報
- {Issue番号や資料}
## 補足
{既知の制約、デプロイ時の注意、対象外の変更。なければ「なし」}
最後に「入力情報の不足」として、説明文の正確性を上げるために追加で必要な情報を最大5件挙げてください。不足がなければ、この項目は出力しないでください。
入力時に変える部分
入力の質を左右するのは、diffの長さよりも目的と確認結果の具体性です。最低限、次の項目は実装者が埋めます。
必ず変更する項目
{変更の目的・背景}：誰のどの問題を解決するのか{変更ファイルの概要}：変更された範囲を把握できる情報{コード差分または変更内容のメモ}：実際の変更を裏付ける材料{実行した確認}：コマンド名、対象、成否{影響範囲}：画面、API、データ、設定などへの影響{レビューで特に見てほしい点}：判断に迷った箇所やリスク
たとえば、テスト結果は「テスト済み」ではなく、次のように入力します。
- pytest tests/test_export.py -q: 18件成功
- CSV出力画面で期間を指定し、UTF-8のファイルを手動確認
- Windows版Excelでの表示確認は未実施
これなら、AIは実施済みの確認と残作業を区別できます。「すべて問題なし」のような、根拠のない説明も避けやすくなります。
固定しておきたいルール
次の指示は案件ごとに消さず、プロンプトへ残すのがおすすめです。
- 入力にないテスト結果を作らない
- 目的や効果をdiffだけから推測しない
- 不足情報を「要確認」として分離する
- 実施済みと未実施の確認を分ける
- Markdownの見出し順を固定する
出力の形が毎回変わると、レビュー担当者は情報を探すところから始めなければなりません。チームで使う場合は、見出しをリポジトリのPRテンプレートに合わせて固定すると運用しやすくなります。
AIへ渡す前に差分を整理する方法
巨大なdiffを無条件で貼るより、比較対象を確認して必要な範囲を渡す方が安全で正確です。
GitHubのCompare画面では、baseを比較の起点、compareを変更後の地点として、コミットと変更ファイルを確認できます。ローカルで情報を用意する場合は、リポジトリの運用に合わせて次のようなコマンドを使えます。
git diff --stat main...HEAD
git log --oneline main..HEAD
git diff main...HEAD
AIへ渡す前に確認したい項目は次のとおりです。
- 比較元のブランチが正しいか
- 自動生成ファイルやロックファイルを含める必要があるか
- APIキー、個人情報、非公開URLなどの機密情報が混ざっていないか
- 変更量が大きい場合、機能単位に分けられないか
- リポジトリや組織のAI利用ルールに反していないか
すべてのソースコードを渡せない場合は、git diff --stat、変更した関数名、実装メモ、テスト結果を入力します。ただし、材料を省略した部分についてAIに断定させてはいけません。
よくあるNG例と改善例
NG例：差分だけを渡して丸投げする
このdiffから、分かりやすいPR説明文を書いてください。
この指示には、変更理由、関連Issue、テスト結果、影響範囲がありません。AIが自然な文章を作れても、実装者の意図や未実施の確認まで正確に復元することはできません。
改善例：目的と確認事実を追加する
次の差分をもとにPR説明文を作ってください。
目的:
CSV出力で終了日を含むデータが欠落する問題を修正する。
変更内容:
日付範囲の終了条件を「終了日未満」から「終了日の翌日未満」へ変更した。
関連テストに、終了日の23:59:59のレコードを追加した。
確認結果:
- 対象の自動テスト12件は成功
- タイムゾーンを変更した場合は未確認
出力:
「概要」「主な変更」「影響範囲」「確認内容」「レビューしてほしい点」の順に、GitHub用Markdownで書く。
入力にない事実は補わず、不足情報は「要確認」として示す。
差分:
{必要な範囲のdiff}
改善点は明確です。
- 修正対象となる不具合を一文で限定した
- 実装上の変更を具体的に示した
- 成功したテスト件数と未確認条件を分けた
- 出力する見出しを固定した
- AIによる推測を禁止した
出力を安定させる3つのコツ
安定したPR説明文には、長いプロンプトよりも明確な境界が必要です。
1. 事実と推測を分ける
「効果を説明して」とだけ指示すると、入力にない性能向上や安全性まで文章へ含まれる可能性があります。次のように、使ってよい材料を限定します。
効果は、入力された要件、差分、テスト結果から確認できる範囲だけを書く。
推測が必要な箇所は本文に混ぜず、「要確認」に分ける。
2. レビューの観点を指定する
「分かりやすく」だけでは、何を重視するかが決まりません。PRに応じて観点を追加します。
- API変更：後方互換性、エラー形式、認証・認可
- DB変更：既存データ、ロールバック、ロック時間
- UI変更：操作手順、空状態、エラー表示、画面幅
- バッチ変更：再実行、安全性、処理件数、失敗時の復旧
- 依存関係の更新：破壊的変更、既知の脆弱性、ビルド結果
3. 出力後に人が照合する
生成された文章は完成品ではなく、レビュー依頼前の下書きです。少なくとも次を確認します。
- 説明文と実際のdiffが一致しているか
- テスト名、件数、結果が入力どおりか
- 影響範囲を広く、または狭く書きすぎていないか
- 未確認事項が消えていないか
- 関連Issueやリンクが正しいか
AIが読みやすく整えた文章でも、最終的な事実確認はPR作成者が行います。
用途別の追加指示
基本テンプレートの末尾へ短い指示を足すと、変更の種類に合った説明文にできます。
バグ修正の場合
不具合の発生条件、原因、修正方法、再発防止のテストを分けて書く。
入力にない原因や再現条件は推測しない。
修正前後で利用者から見える挙動がどう変わるかを明記する。
リファクタリングの場合
外部仕様を変える変更と、内部構造だけを変える変更を区別する。
「動作は変わらない」と書けるのは、その根拠となる入力またはテスト結果がある場合だけにする。
削除、移動、責務分割の狙いを簡潔に整理する。
API・DB変更の場合
API契約、DBスキーマ、既存データ、移行手順、ロールバックへの影響を個別に整理する。
破壊的変更の有無を明示し、判断材料がなければ「要確認」とする。
デプロイ前後に必要な作業を時系列で書く。
小規模な変更の場合
PR説明文全体を300文字以内にする。
見出しは「概要」「変更内容」「確認」の3つだけにする。
重要な未確認事項がある場合は文字数より優先して記載する。
リポジトリのPRテンプレートと組み合わせる
AI用プロンプトとGitHub側のPRテンプレートは、どちらか一方を選ぶものではありません。 GitHub側で必要項目を固定し、AIにその形式へ文章を整えさせます。
GitHub公式ドキュメントによると、PRテンプレートをリポジトリへ追加すると、その内容がPR本文に自動表示されます。テンプレートはルート、docs、.githubなどの所定の場所へ配置でき、複数テンプレートも用意できます。
たとえば、リポジトリに次の見出しがあるなら、プロンプトの出力形式も同じ順番に変更します。
## 変更概要
## 関連Issue
## 動作確認
## 影響範囲
## レビューポイント
## チェックリスト
- [ ] テストを追加または更新した
- [ ] ドキュメントへの影響を確認した
- [ ] 破壊的変更の有無を記載した
チェックボックスは、実際に確認した状態だけを反映させます。AIにすべてを[x]へ変えさせる指示は避けてください。
使用前チェックリスト
最後に、プロンプトへ入力する内容と生成結果を確認します。
- [ ] 変更の目的を一文で説明できる
- [ ] baseとcompareの対象が正しい
- [ ] 主要な差分を機能単位で整理した
- [ ] 実施済みと未実施の確認を分けた
- [ ] 影響する画面、API、DB、設定を確認した
- [ ] レビューしてほしい箇所を指定した
- [ ] 機密情報を入力から除外した
- [ ] AIが作った事実やテスト結果が混ざっていない
- [ ] リポジトリのPRテンプレートに合わせた
PR説明文で最も重要なのは、文章の滑らかさではありません。レビュー判断に必要な事実が、差分と矛盾せず並んでいることです。
まずは「目的」「差分の概要」「テスト結果」「未確認事項」の4項目を入力してください。そのうえで、実際の変更と生成文を照合してからレビューを依頼する。この確認手順まで含めてテンプレート化すると、PRごとの説明品質をそろえやすくなります。