AIにコミットメッセージとPR説明を書かせる｜レビューが楽になる型
実装は終わった。テストも通った。あとはコミットして、PR（プルリクエスト）を出すだけ。 ——なのに、コミットメッセージの入力欄で手が止まる。「えーと、何て書けばいいんだっけ」。PRの説明欄も真っ白なまま、カーソルが点滅している。
その気持ち、すごく分かります。コードを書いているときは頭が動いているのに、いざ「日本語で説明する」となると急に面倒になる。しかも急いでいると、つい fix とか 修正 とかの一言だけで済ませてしまう。あとでレビュアーや未来の自分が「これ何の修正だっけ」と困る、あのパターンです。
ここは、AIが本当に得意な所です。差分（diff＝変更前後の違い）を渡せば、何を変えたかは正確に読み取って、きれいな文章にしてくれます。ただ、丸投げすると「何をしたか」だけの当たり障りない説明になりがち。この記事では、AIに下書きさせて、人は「なぜ」と「見てほしい所」だけ足す——レビュアーが楽になる頼み方と、出す前の確認の型を、コピペできるプロンプトつきで整理します。責める話ではないので、気楽にどうぞ。
結論：コミットメッセージとPR説明は、AIに下書きさせて、人が2つだけ足すのが一番速くて質も出ます。手順は3つ。①差分をそのままAIに渡す（git diff の中身を貼る）。②「1行の要約＋箇条書きの変更点」の形で下書きさせる。③AIが知らない「なぜこう変えたか（背景・意図）」と「レビューでここを見てほしい」の2点だけ人が書き足す。AIは差分からWhat（何を変えたか）は読めますが、Why（なぜ）とレビューの勘所は書いた本人にしか分かりません。ここだけ人が担う。出す前に、事実と違う説明が混じっていないか（AIが差分にない事を書き足すことがある）を一度だけ見れば十分です。
一度に完璧を目指さなくて大丈夫です。 まずは「次のコミット1件だけ、差分を貼って下書きさせてみる」。ここから始めましょう。
何が起きているのか——「書くのが面倒」は、あなたのせいじゃない
まず、なぜコミットメッセージやPR説明を書くのが面倒に感じるのか、共有させてください。あなたの文章力の問題ではありません。実装で頭を使い切ったあとに、もう一度「言語化」という別の作業を求められる——ここに負荷があります。しかも、いい説明を書こうとすると「何を変えたか」を差分から思い出して、順番に並べて、要約して……と、地味に手間がかかる。だから、つい一言で済ませてしまう。
でも、この「What（何を変えたか）を差分から拾って整理する」作業こそ、AIがいちばん正確にこなせる所なんです。差分には答えが全部書いてあるので、AIは推測せずに事実を読み取れる。翻訳でも要約でもなく、目の前にある変更を言葉にするだけなので、ハルシネーション（もっともらしい嘘）も起きにくい領域です。
一方で、AIが書けないものもあります。それがWhy（なぜそう変えたか）とレビューの勘所です。
- Why（背景・意図）：たとえば「タイムアウトを10秒から30秒に変えた」という変更。差分を見ればWhatは分かりますが、「本番で外部APIが遅くて落ちていたから」という理由は、差分のどこにも書いていません。これはあなたの頭の中にしかない。
- レビューの勘所：「ここ、影響範囲が広いので念入りに見てほしい」「命名に自信がないので意見がほしい」——こういうレビュアーへのお願いも、実装した本人にしか分かりません。
つまり、コミットメッセージやPR説明は、AIが得意なWhatと、人しか書けないWhyの合わせ技。全部を人が書く必要も、全部をAIに丸投げする必要もない。ここを分けて考えると、急に軽くなります。
① 差分をそのまま渡す——AIに「読ませてから」書かせる
いちばん大事なのは、差分を渡してから書かせることです。差分なしで「コミットメッセージ書いて」と頼むと、AIは何を変えたか知らないので、当たり障りのない一般論を返してきます。逆に差分を渡せば、事実に基づいた具体的な下書きが出ます。
やり方はシンプルです。
git diffの中身をそのまま貼る：コミット前ならgit diff（ステージ済みならgit diff --staged）で変更内容が出ます。これをコピーしてAIに渡す。ファイル名も含めて丸ごとで大丈夫です。- 量が多いときは要点のファイルだけ：差分が何百行もあるときは、主要な変更のあるファイルだけに絞って渡しても十分です。全部渡せないときは「主要な変更はこのファイル」と一言添える。
- AIコーディングツールを使っているなら、その場で頼める：エディタ上でAIに実装させている場合は、「今の変更のコミットメッセージを書いて」と続けて頼めば、変更内容を把握したまま書いてくれます。
なぜ差分が要るのか：AIは「あなたが何をしたか」を差分でしか知りません。差分を渡さずに書かせた説明は、事実に基づいていないので、あとで直す手間のほうが大きくなります。読ませてから書かせる——この順番だけ守れば、下書きの質がぐっと上がります。
渡す前提のそろえ方はAIにコードを書かせる前に渡す前提と制約の伝え方、既存コードに馴染ませる文脈の渡し方は既存コードベースにAIを馴染ませる文脈の渡し方も、同じ「情報を渡してから頼む」という下敷きです。
② 「1行要約＋箇条書き」の形で下書きさせる
差分を渡したら、出力の形も指定します。形を決めておくと、レビュアーが読みやすく、あなたの手直しも減ります。おすすめは、コミットもPRも共通で「1行の要約＋箇条書きの変更点」の形です。
コミットメッセージ用のプロンプト例（差分を貼ったあとに続ける）：
上の差分から、コミットメッセージの下書きを作ってください。
・1行目：50字くらいで「何をしたか」の要約（体言止めか、動詞で始める）
・空行のあと：主な変更点を箇条書きで3〜5個
・推測や、差分にない事は書かない。分からない背景は書かないPR説明用のプロンプト例：
上の差分から、プルリクエストの説明の下書きを作ってください。
・「概要」：この変更で何が変わるかを2〜3行で
・「変更点」：主な変更を箇条書きで
・「動作確認」：差分から読み取れる範囲で、確認すべき項目を箇条書きで
・差分にない事実（背景・理由）は空欄にして、[要記入]と置いてくださいポイントは、最後の一文——「差分にない事は書かない」「分からない所は[要記入]と置く」を必ず入れることです。こうしておくと、AIが勝手に「パフォーマンス改善のため」などともっともらしい理由をでっち上げるのを防げます。空欄が残っていれば、そこが「人が足す番」だと一目で分かる。
チームでコミットメッセージの書式（規約）が決まっているなら、それも渡します。「先頭に feat: fix: などの種別を付けて」のように一言添えるだけで、規約に沿った形で返ってきます。規約をAIに守らせるコツは、指示とチェックの両輪です。
③ 「なぜ」と「見てほしい所」だけ、人が足す
ここが、この記事で一番伝えたい所です。AIの下書きはWhatは埋まっているが、Whyは空いている。その空きを、あなたが2つだけ埋めます。
- なぜこう変えたか（背景・意図）：「本番で〇〇が落ちていたので」「〇〇さんから要望があって」「前の実装が△△で困っていたので」。一言でいい。この一言があるかないかで、レビュアーの理解速度がまるで変わります。半年後の自分が
git logを追うときにも、いちばん助かるのがこの一行です。 - レビューでここを見てほしい：「影響範囲が広いので、呼び出し元も見てほしい」「この命名、しっくり来ていないので意見がほしい」「テストはあとで足す予定」。レビュアーの目線を、見てほしい所へ誘導する一言です。これがあると、レビューが速くなり、的外れな指摘も減ります。
この2つは、差分を100回読んでもAIには書けません。あなたの頭の中にしかない情報だからです。逆に言えば、ここだけ書けば、あとはAIの下書きで完成します。
迷ったら、AIに「なぜ」を聞かれる形にしてもらう：下書きの最後に「この変更の背景・理由を1行で教えてください」とAIから質問させるプロンプトにしておくと、書き足しを忘れにくくなります。埋める場所が用意されていると、人は書きやすい。
AIレビューの指摘をどう取捨選択するかはAIレビューの指摘を取捨選択する判断軸、レビューの一次チェックをAIにどこまで任せるかはコードレビューの一次チェックをAIに任せる範囲と注意点に整理しています。書くのを楽にする話と、見るのを楽にする話は、地続きです。
出す前の確認——事実と違う説明が混じっていないか
AIの下書きは便利ですが、そのまま出す前に一度だけ目を通します。見るのは1点、「差分にない事を書いていないか」です。
AIは、差分に書いていないことを「補って」しまうことがあります。たとえば、実際にはリファクタリングしただけなのに「パフォーマンスを改善しました」と書いたり、変えていない機能を「対応しました」と書いたり。もっともらしいので、読み飛ばすと嘘の説明のままレビューに出てしまいます。レビュアーはその説明を信じて読むので、事実とズレていると混乱の元になります。
確認は難しくありません。下書きを読みながら、「この一文、実際にやった？」を自分に問うだけです。
- 「〇〇を改善」と書いてあるが、本当に改善した？（測った？）→ 測っていないなら「〇〇を変更」に直す
- 「〇〇に対応」と書いてあるが、その機能、この差分で触った？→ 触っていないなら消す
- 動作確認の項目が、実際にやったことと合っているか
ここは、AI生成物を人が確認するという、どの場面でも共通の一手です。生成コードそのものの確認はAI生成コードのレビュー・検証チェックリスト、差分の追い方はリファクタリングをAIに任せるときの差分の確認方法も合わせてどうぞ。
明日からやること（次のコミット1件から）
大きな仕組みは要りません。まずこの3つだけ。
- 次のコミットで、
git diffを貼って下書きさせる：「差分にない事は書かないで」を添えて頼む。出てきた1行要約＋箇条書きを、そのまま使う。 - 「なぜ」を1行だけ足す：この変更をした理由を、コミット本文かPR説明に一言。ここが一番効きます。
- 出す前に「実際にやった？」を1回だけ確認：改善・対応など、事実と違う説明が混じっていないか目を通す。
この3つは、慣れれば合わせて1〜2分です。手が止まっていた入力欄が、下書きから始められる。それだけで、コミットとPRの心理的なハードルがぐっと下がります。
AIにコミット・PRを書かせるときのチェックリスト
出す前に、さっと確認します。全部に○が要るわけではなく、気になる所だけで十分です。
下書きさせるとき
- 差分（
git diffの中身）を渡してから書かせたか - 「1行要約＋箇条書き」など、出力の形を指定したか
- 「差分にない事は書かない／分からない所は[要記入]」を添えたか
- チームの書式（規約）があれば渡したか
人が足すとき
- なぜこう変えたか（背景・意図）を1行入れたか
- レビューで見てほしい所を一言添えたか
出す前
- 「改善」「対応」など、実際にやった事実と合っているか
- 差分にない機能・効果を書いていないか
- 動作確認の項目が、実際にやったことと合っているか
この記事のまとめ
コミットメッセージやPR説明で手が止まるのは、あなたの文章力のせいではありません。実装で頭を使ったあとに、もう一度「言語化」を求められる——その負荷を、AIに肩代わりさせていい所です。
コツは、AIが得意なWhat（何をしたか）は下書きさせ、人しか書けないWhy（なぜ）と見てほしい所だけ足すこと。差分を渡してから書かせて、事実と違う説明が混じっていないかだけ一度見る。全部を自分で書く必要も、全部を丸投げする必要もありません。まずは次のコミット1件、差分を貼ってみる——その一手からで十分です。
コミットメッセージは、未来の誰か——多くは半年後の自分——への手紙です。その手紙を、AIと二人がかりで書けるようになれば、記録はぐっと読みやすくなります。今日、次の1コミットだけ試せたなら、それはもう小さな前進です。レビューを楽にする話はAIレビューの指摘を取捨選択する判断軸、コードレビューの一次チェックをAIに任せる範囲と注意点も、必要なときにのぞいてみてください。