生成AIでコミットメッセージとPR説明文を作るプロンプトと差分の渡し方

生成AIにコミットメッセージやプルリクエスト（PR）の説明文を書かせるときは、差分（git diff の出力）に「変更の目的」を1行添えて渡すのが基本です。 差分には「何を変えたか」は写っていますが、「なぜ変えたか」は写っていません。目的を添えないと、AI は差分をなぞった文しか書けません。

この記事では、コミットメッセージ用と PR 説明文用のプロンプトテンプレート、目的別の git diff コマンド早見表、差分が大きいときの分け方、渡す前に鍵や接続情報を除く確認表、そして「チャットに貼る／コマンドラインのツールに渡す／エディタの生成機能を使う」の選び方をまとめました。コミットメッセージや PR の規約そのものの説明は省き、AI への渡し方とプロンプトに絞っています。

確認環境：Ubuntu 24.04、Git 2.43.0、Python 3.11.15（確認日 2026-10-05）。掲載した git コマンドとスクリプトの出力は、架空の備品予約アプリのリポジトリで実行した結果です（パスとユーザー名は一般的な名前に置き換えています）。各ツールの機能は、同日に開いた Git・Conventional Commits・GitHub Docs・Visual Studio Code・Claude Code の公式ドキュメントの記載に沿っています。この記事はテンプレート集で、AI の回答例は載せていません。

この記事の結論

• 差分＋目的1行を渡す。目的が無いと、本文の「理由」は推測になる
• コミット用は git diff --staged、PR 用は git diff main...HEAD（ドット3つ）と git log main..HEAD を渡す
• 書式はプロンプトで固定する（種類の一覧、件名の長さ、本文に理由、見出しの並び）
• ロックファイルや自動生成物は :(exclude) で外す。今回の例では 349 行の差分が 37 行になった
• 渡す前に、追加行に鍵・パスワード・接続情報が無いかを grep で確かめる

コミットメッセージとPR説明文を作る早見表

差分だけでは理由が書けない

次の差分は、備品予約アプリの重複チェックを1行直したものです。

     for s, e in existing:
-        if start <= e and s <= end:
+        if start < e and s < end:
             return False

ここから読み取れるのは「比較を『以下』から『未満』に変えた」ことだけです。「10:00 に終わる予約の直後、10:00 からの予約を入れられるようにしたかった」という理由は、どこにも書かれていません。

AI に任せるのは「差分を読んで文章の形に整える」部分で、理由と確認内容は人が渡す、という分担にすると、読み返して直す手間が減ります。

目的別 git diff コマンド早見表

下見：--stat で何が含まれているかを見る

git diff --staged --stat

 README.md                 |   4 +
 package-lock.json         | 303 +++++++++++++++++++++++++++++++++++++++++++++-
 src/reservation.py        |   2 +-
 tests/test_reservation.py |   5 +
 4 files changed, 312 insertions(+), 2 deletions(-)

312 行の追加のうち 302 行がロックファイルです。このまま渡すと、AI が読む量のほとんどが、説明文に関係しない行になります。

ロックファイルを外して渡す

git diff --staged | wc -lc
git diff --staged -- . ':(exclude)package-lock.json' | wc -lc

    349   15379
     37    1334

左が行数、右がバイト数です。ロックファイルを1つ外すだけで、349 行が 37 行になりました。 :(exclude) は Git のパス指定（pathspec）の書き方で、:! または :^ と短く書けます。外したファイルについては「package-lock.json は依存の更新に伴う自動生成」と、目的の欄に一言添えておくと説明文から抜けません。

PR 用：ドット3つとドット2つの違い

作業ブランチを切ったあとに main が進んでいると、ドットの数で結果が変わります。次は、main 側に LICENSE が追加されたあとで実行した結果です。

git diff main...HEAD --stat | tail -1
git diff main..HEAD --stat | tail -1
git diff main..HEAD --name-status

 5 files changed, 317 insertions(+), 2 deletions(-)
 6 files changed, 317 insertions(+), 3 deletions(-)
A   .gitignore
D   LICENSE
M   README.md
M   package-lock.json
M   src/reservation.py
M   tests/test_reservation.py

ドット2つでは、自分が触っていない LICENSE が「削除」として出ています。main に後から入った変更が、逆向きの差分として混ざるためです。これを AI に渡すと「LICENSE を削除」と説明文に書かれてしまいます。PR の説明文には、分岐した地点からの差分になるドット3つを使います。

コミットメッセージ用のプロンプトテンプレート

{ } の部分を書き換えて使います。差分を先に、指示を後ろに置いています（長い資料を先頭に、質問を末尾に置くと応答の質が上がる、という Anthropic の公式ガイドの記載に沿った並びです）。

<diff>
{git diff --staged の出力をここに貼る}
</diff>

<purpose>
{変更の目的を1行で。例：前の予約が終わる時刻ちょうどから、次の予約を入れられるようにする}
</purpose>

上の差分に対するコミットメッセージを1つ書いてください。

# 書式（Conventional Commits）
- 1行目：種類(範囲): 要約
- 種類は feat / fix / docs / style / refactor / perf / test / build / ci / chore から1つ選ぶ
- 範囲は変更の中心になったモジュール名。決めにくいときは省く
- 要約は日本語、全角25字以内、文末に句点を付けない。何をしたかを書く
- 2行目は空行
- 3行目から本文。purpose をもとに「なぜ変えたか」を2〜3行で書く。差分を見れば分かる手順の説明は書かない
- 互換性が変わる変更があれば、最後に「BREAKING CHANGE: 内容」を書く

# 守ること
- 差分と purpose に書かれていることだけを使う。読み取れない理由や効果は足さない
- purpose と差分が食い違って見えるときは、メッセージの後ろに「確認したい点：」として1行で書く
- 出力はコミットメッセージだけにする。前置きやコードブロックの記号は付けない

書式の指定がなぜ要るか

Conventional Commits 1.0.0 の仕様で決まっているのは「種類、任意の範囲、コロンと空白、説明」という1行目の形と、空行をはさんで本文・フッターを置くこと、BREAKING CHANGE: または種類の後ろの ! で互換性の変更を示すことです。仕様に名前が出てくる種類は feat と fix で、build・chore・ci・docs・style・refactor・perf・test は「使ってよいもの」として挙げられています。

受け取ったメッセージの形を機械的に確かめる

件名の長さや2行目の空行は、目で見るよりスクリプトで確かめるほうが確実です。

"""コミットメッセージの形を確かめる（Conventional Commits 1.0.0 の形＋件名の長さ）"""
import re
import sys
import unicodedata

TYPES = "feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert"
MAX_WIDTH = 50  # 件名の上限（半角換算）。チームの決まりに合わせて変える


def width(s: str) -> int:
    return sum(2 if unicodedata.east_asian_width(c) in "FWA" else 1 for c in s)


lines = open(sys.argv[1], encoding="utf-8").read().splitlines()
subject = lines[0] if lines else ""
problems = []
if not re.match(rf"^({TYPES})(\([^)]+\))?!?: \S", subject):
    problems.append("件名が「種類(範囲): 要約」の形になっていない")
if width(subject) > MAX_WIDTH:
    problems.append(f"件名が長い（半角換算 {width(subject)} > {MAX_WIDTH}）")
if subject.endswith(("。", ".")):
    problems.append("件名の末尾に句点がある")
if len(lines) > 1 and lines[1] != "":
    problems.append("2行目が空行になっていない")
if len([l for l in lines[2:] if l.strip()]) == 0:
    problems.append("本文（変更の理由）が無い")

print(f"件名: {subject}")
print(f"文字数: {len(subject)} / 半角換算: {width(subject)}")
print("OK" if not problems else "\n".join("NG: " + p for p in problems))
sys.exit(1 if problems else 0)

手で書いた2つのメッセージ（msg.txt）で試した結果です。

python3 check_msg.py msg.txt

件名: fix(reservation): 終了時刻と同じ開始時刻の予約を受け付ける
文字数: 38 / 半角換算: 58
NG: 件名が長い（半角換算 58 > 50）

件名: fix(reservation): 連続する時間帯の予約を受け付ける
文字数: 34 / 半角換算: 50
OK

日本語の件名は、文字数では 38 字でも半角換算では 58 になります。 「50字以内」とだけ指示すると、数え方が人と AI で食い違います。プロンプトには「要約は全角25字以内」のように、どの部分を・どの数え方で数えるかまで書くと、そろえやすくなります。

確かめたメッセージは、そのままコミットに使えます。

git commit -F msg.txt
git log --oneline -1

e5c1058 fix(reservation): 連続する時間帯の予約を受け付ける

PR説明文用のプロンプトテンプレート

PR はコミットより範囲が広いので、差分に加えてコミット一覧と、人が確かめたことを渡します。

<diff>
{git diff main...HEAD -- . ':(exclude)package-lock.json' の出力}
</diff>

<commits>
{git log --reverse --format='- %s' main..HEAD の出力}
</commits>

<context>
目的：{なぜこの変更が必要か。1〜2行}
確認したこと：{実行したテスト、手で試した操作と結果}
関連：{Issue 番号や関連する PR。無ければ「なし」}
差分から外したもの：{例：package-lock.json（依存の更新に伴う自動生成）}
</context>

上の内容をもとに、プルリクエストの説明文を Markdown で書いてください。

# 見出し（この順番、この名前で）
## 概要
目的と、変更で何ができるようになるかを2〜3文で。

## 変更点
ファイルやモジュールごとに箇条書き。1項目1行。

## 確認方法
レビューする人が手元で再現できる手順を番号つきで。context の「確認したこと」に書かれた内容だけを使う。

## 影響範囲
変更が及ぶ機能・画面・設定。差分から読み取れる範囲で書き、読み取れないときは「差分からは判断できない」と書く。

## レビューで見てほしい点
判断が分かれそうな箇所を、ファイル名と行の内容を添えて1〜3点。

# 守ること
- diff・commits・context に書かれていないことは足さない
- 確認していないテストを「実施済み」と書かない
- タイトル案を説明文の前に1行で付ける（種類: 要約 の形、全角30字以内）

コミット一覧は、次のコマンドでそのまま貼れる形になります。

git log --reverse --format='- %s' main..HEAD

- fix(reservation): 連続する時間帯の予約を受け付ける
- docs: テストの実行方法を追記

「確認方法」と「影響範囲」は、差分だけでは書けない欄です。context の「確認したこと」を空のまま渡すと、AI が書けるのは一般的な手順の案までになります。確認した内容は、渡す人が1行でも書くのが、説明文を信頼できるものにする近道です。

差分が大きいときの分け方

差分が長いと、貼り付けの上限に当たったり、後半の変更が説明文から抜けたりします。次の順で小さくします。

フォルダごとにファイルへ書き出す例です。

for d in src tests; do git diff main...HEAD --output=diff_$d.txt -- $d; done
git diff main...HEAD --output=diff_other.txt -- . ':(exclude)src' ':(exclude)tests' ':(exclude)package-lock.json'
wc -lc diff_*.txt

  23  519 diff_other.txt
  12  446 diff_src.txt
  13  574 diff_tests.txt
  48 1539 total

分けた差分は、2段階で説明文にします。

（1段階目：分けた差分ごとに送る）
<diff>
{diff_src.txt の中身}
</diff>

この差分の変更点を、ファイルごとに箇条書きで要約してください。
1項目1行。「何を変えたか」だけを書き、理由の推測は書かないでください。

（2段階目：要約を集めて送る）
<summaries>
{1段階目の出力を、フォルダ名を付けて並べる}
</summaries>

<context>
目的：{…}
確認したこと：{…}
</context>

上の要約と context をもとに、プルリクエストの説明文を書いてください。
（見出しと守ることは、PR 説明文用テンプレートと同じ）

1つのコミットに複数の目的が混ざっているときは、プロンプトを工夫するよりも、コミットを目的ごとに分けるほうがメッセージは書きやすくなります。「このステージ済みの差分に、目的の違う変更が混ざっていたら、分け方の案を出してください」と先に聞くのも有効です。

渡す前に鍵や接続情報を除く確認表

差分には、追加した行がそのまま載ります。外部のサービスに送る前に、次の点を確かめます。

追加行にそれらしい語が無いかを調べるコマンドです。

git diff --staged | grep -nEi '^\+.*(password|passwd|secret|api[_-]?key|token|BEGIN [A-Z ]*PRIVATE KEY)'
git diff --staged --name-only | grep -nEi '(\.env|\.pem|\.key|id_rsa|credentials|secret)'

設定ファイル（config.local.env）を誤ってステージした状態で実行した結果です（値は例示用の文字列です）。

20:+DB_PASSWORD=Example-Pass-1234
21:+API_KEY=sk_test_EXAMPLE0000000000

2:config.local.env

見つかったら、ステージから外して .gitignore に加えます。

git restore --staged config.local.env
echo 'config.local.env' >> .gitignore

この grep は語の一致を見るだけなので、変数名が違う鍵は見つけられません。grep で絞ってから、最後は --stat の一覧と差分を目で見る、という2段がまえにします。これは AI に渡す前の確認であると同時に、鍵をコミットしないための確認にもなります。

チャット・コマンドライン・エディタの生成機能の選び方

チャットに貼る

差分をファイルに書き出し、エディタで開いて貼るのが確実です。

git diff --staged --no-color --output=diff.txt -- . ':(exclude)package-lock.json'

書き出した diff.txt は git status に「未追跡のファイル」として出ます。リポジトリの外に書き出すか、使い終わったら消します。

コマンドラインのツールに渡す

標準入力を受け取れるツールなら、パイプでそのまま渡せます。Claude Code の公式 CLI リファレンスには、cat file | claude -p "query" の形（パイプで渡した内容を処理して終了する）が載っています。同じ形で差分を渡すと次のようになります。

git diff --staged -- . ':(exclude)package-lock.json' \
  | claude -p "目的：連続する時間帯の予約を入れられるようにする。この差分のコミットメッセージを Conventional Commits の形で1つ書いて。件名は日本語で全角25字以内、本文に理由を2〜3行。出力はメッセージだけ"

プロンプトが長くなるときは、書式の部分をファイルに置き、--append-system-prompt-file で読み込ませる方法が同じリファレンスにあります。

エディタの生成機能（GitHub Copilot）

VS Code のカスタム指示のページには、コミットメッセージ生成用の github.copilot.chat.commitMessageGeneration.instructions と、PR の説明生成用の github.copilot.chat.pullRequestDescriptionGeneration.instructions という設定が載っており、text（指示の文）か file（Markdown ファイルのパス）を持つオブジェクトの配列を受け取ります。

{
  "github.copilot.chat.commitMessageGeneration.instructions": [
    { "text": "Conventional Commits の形で書く。要約は日本語で全角25字以内。本文に変更の理由を書く。" }
  ],
  "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
    { "file": "docs/pr-description-rules.md" }
  ]
}

どれを選ぶか

どの方法でも、生成されたものは下書きです。理由が正しいか、試していないテストが「確認済み」と書かれていないかを読んでから、コミットや PR に使います。

確かめて分かったこと

• 新しく作ったファイルは、git add するまで git diff にも git diff --staged にも出ない。渡した差分に入っていないファイルは、説明文にも出てきません。先に git status --short で ?? の行が無いかを見ます
• ロックファイル1つで差分の9割近くを占めていた（349 行のうち 312 行）。--stat で下見してから外すと、渡す量が 37 行になりました
• ドット2つの差分には、自分が触っていないファイルが「削除」として混ざることがある。PR 用はドット3つを使います
• 日本語の件名は、文字数と半角換算で数が大きく変わる（38 字が半角換算 58）。上限は数え方と一緒に指定します
• --output=diff.txt でリポジトリの中に書き出すと、そのファイルが未追跡として残る。git add -A で一緒にコミットしないよう、外に書き出すか消します
• Conventional Commits 1.0.0 の仕様そのものには、件名の長さの決まりが無い。長さはチームで決めて、プロンプトに数字で書きます

よくある質問

Q. 生成AIにコミットメッセージを書かせるとき、何を渡せばよいですか？ A. git diff --staged の出力と、変更の目的1行、書式の指定の3つを渡します。差分だけだと「何を変えたか」しか書けず、本文の理由が推測になります。

Q. git diff と git diff --staged の違いは何ですか？ A. git diff はまだステージしていない変更、git diff --staged は git add 済みで次のコミットに入る変更を表示します。コミットメッセージを作るときは、コミットされる内容と一致する --staged を使います。

Q. 差分が長すぎて貼れないときはどうすればよいですか？ A. まず --stat で行数の多いファイルを見つけ、ロックファイルや自動生成物を :(exclude) で外します。それでも長いときは、フォルダごとに分けて要約させ、要約を集めて説明文にします。

Q. PR説明文をAIに作らせると、確認方法の欄が一般的な内容になります。どうすればよいですか？ A. 実行したテストや手で試した操作を、context の「確認したこと」に書いて渡します。差分には確認の内容が写らないため、渡さない限り AI は一般的な手順しか書けません。

Q. コミットメッセージは英語と日本語のどちらで生成させるのがよいですか？ A. リポジトリの既存の履歴に合わせます。プロンプトに「要約は日本語」「種類は英語の小文字」のように言語を書くと、そろいます。

まとめ

• AI に渡すのは差分＋変更の目的1行。理由と確認内容は人が添える
• コミット用は git diff --staged、PR 用は git diff main...HEAD（ドット3つ）とコミット一覧
• 書式はプロンプトで固定する。種類の一覧、件名の長さと数え方、本文に理由、PR の見出しの並び
• --stat で下見し、ロックファイルや自動生成物は :(exclude) で外す
• 渡す前に、追加行の鍵・パスワード・接続情報を grep と目で確かめる
• 方法は、たまに使うならチャット、決まった書式で繰り返すならコマンドライン、手早い下書きならエディタの生成機能
• 生成されたものは下書きとして読み、確かめてから使う

参考・出典

• Git「git-diff」 https://git-scm.com/docs/git-diff （2026年10月5日に閲覧）
• Git「gitglossary（pathspec）」 https://git-scm.com/docs/gitglossary （2026年10月5日に閲覧）
• Conventional Commits 1.0.0 https://www.conventionalcommits.org/en/v1.0.0/ （2026年10月5日に閲覧）
• GitHub Docs「Creating a pull request summary with GitHub Copilot」 https://docs.github.com/en/copilot/how-tos/use-copilot-for-common-tasks/create-a-pr-summary （2026年10月5日に閲覧）
• Visual Studio Code「Copilot smart actions」 https://code.visualstudio.com/docs/copilot/copilot-smart-actions （2026年10月5日に閲覧）
• Visual Studio Code「Use custom instructions」 https://code.visualstudio.com/docs/copilot/customization/custom-instructions （2026年10月5日に閲覧）
• Claude Code「CLI reference」 https://code.claude.com/docs/en/cli-reference （2026年10月5日に閲覧）
• Anthropic「Prompting best practices」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices （2026年10月5日に閲覧）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。