AIでコミットメッセージを作るなら、commit予定の差分、変更理由、チームの書式を渡し、複数候補を生成します。AIが差分にない変更を付け足していないか確認してから採用します。
この記事では、git diff --cachedを使った差分確認、Conventional Commits形式のプロンプト、よい例・悪い例、安全な半自動化を解説します。
情報確認日：2026年7月18日（日本時間）
結論：差分だけでなく変更意図を一文添える
- 無関係な変更を別commitへ分ける
- staged差分に秘密や生成物がないか確認する
- 変更理由と書式をAIへ渡す
- 2〜3候補を作り、diffと照合する
- 人が選択・編集し、commit操作は分ける
コミットメッセージに必要な情報
差分から「何を変えたか」は分かっても、「なぜ変えたか」は分からないことがあります。次の4点を揃えます。
- 変更内容：stagedされた差分
- 変更理由：障害、要件、保守性など
- 影響範囲：機能、module、利用者
- 書式：言語、type、scope、件名の長さ
1．commit予定の差分を安全に確認する
git status --short
git diff --cached --stat
git diff --cachedgit diff --cachedはindexとHEADを比較し、次のcommitに含まれる内容を確認するために使えます。まだstageしていない変更だけを見るgit diffと区別してください。
送信前確認：diffにAPI key、token、個人情報、顧客データ、非公開URLがないか確認します。外部AIを使えるかは組織のルールに従い、許可されないコードは送信しません。
依存更新とUI修正のように目的が違う変更が混ざっている場合は、先にcommit単位を分けます。巨大なdiffを短文へ押し込むより、1つの目的へ揃える方が正確な履歴になります。
2．Conventional Commits形式を指定する
チームがConventional Commitsを採用している場合、基本形は次のとおりです。
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]| 要素 | 例 | 役割 |
|---|---|---|
| type | feat、fix |
変更の種類 |
| scope | auth、checkout |
影響範囲 |
| description | reject expired refresh tokens | 短い要約 |
| body | 理由や以前との違い | 件名で足りない背景 |
| footer | BREAKING CHANGE: |
破壊的変更やissue参照 |
この形式はGitの必須機能ではありません。チーム独自のprefixや日本語書式があるなら、既存履歴を優先します。
3．候補を3つ作るプロンプト
次のstaged diffからコミットメッセージ候補を3つ作ってください。
変更理由:
期限切れrefresh tokenが再利用される不具合を防ぐため。
書式:
- Conventional Commits 1.0.0
- 英語
- typeとscopeを含める
- subjectは命令形で簡潔に
- diffにない変更は書かない
- breaking changeとissue番号は、根拠がある場合だけ書く
各候補の後に、選んだtypeとscopeの理由を1行で説明してください。
staged diff:
{{diff}}候補を1つだけ求めるより、typeやscopeの違いを比較できます。最終メッセージへ理由説明は含めず、レビュー用の補助として使います。
よい例・悪い例10組
| 悪い例 | 改善例 |
|---|---|
update |
fix(auth): reject expired refresh tokens |
bug fix |
fix(cart): preserve quantity after price refresh |
CSS修正 |
fix(header): prevent mobile menu overflow |
refactor |
refactor(invoice): extract tax calculation |
test追加 |
test(shipping): cover free-delivery boundary |
docs |
docs(setup): add local database restore steps |
package update |
chore(deps): update eslint to approved version |
API変更 |
feat(profile): add avatar removal endpoint |
高速化 |
perf(search): cache category counts |
いろいろ修正 |
目的別にcommitを分割して個別に命名 |
改善例は書式の見本です。実際のdiffに書かれていない動作、性能効果、原因を推測して使わないでください。
4．生成結果をdiffと照合する
- typeは実際の変更種類と合うか
- scopeは変更ファイルの責務と合うか
- 件名が「何をしたか」を具体的に表すか
- 変更していない機能を含めていないか
- 理由を結果として誇張していないか
- 破壊的変更やissue番号を創作していないか
- 既存履歴の言語・時制・長さと合うか
特に「高速化した」「安全にした」は、計測や仕様の根拠がないと断定できません。diffが実装した事実だけを要約します。
生成とcommitを分離して半自動化する
安全な流れ
1. staged diffを取得
2. 許可されたAIへ要約依頼
3. 候補をterminalへ表示
4. 人が選択・編集
5. git diff --cachedを再確認
6. 人がcommitを実行
避ける流れ
AIが差分取得 → メッセージ生成 → commit → pushまで無確認で実行メッセージ生成と状態変更を分けると、誤った差分や文面を止められます。AIツールへ与える権限と安全な入力はAIを安全に使う方法も参照してください。
よくある質問
変更理由がdiffにない場合はどうしますか？
issue、要件、作業者の説明から一文を追加します。分からない場合はAIに推測させず、変更内容だけを表すか担当者へ確認します。
日本語メッセージでもよいですか？
問題ありません。チームの既存履歴と規約を優先します。プロジェクト固有指示の整理はCLAUDE.mdの書き方も参考になります。
AIへcommitまで任せるべきですか？
メッセージ候補作成とcommitは分ける方が安全です。少なくともstaged diffと最終文面を人が確認してから状態を変更します。
まとめ
AIでコミットメッセージを作るときは、git diff --cached、変更理由、チーム書式を渡し、複数候補を比較します。差分にない内容、破壊的変更、issue番号をAIが補っていないか確認してください。
まずcommitの目的を1つへ揃えることが、よい要約への近道です。AIコーディング環境の比較はAIコーディングツール比較を参照してください。