Diff → Conventional Commit ヘルパー

git diff を貼ると、変更ファイルから type/scope を自動推測してコミットメッセージのテンプレートを生成。Conventional Commits 準拠、subject 50文字チェック、BREAKING CHANGE 検出、AI に投げる用のプロンプトも生成。

完全無料登録不要ブラウザ完結 5 言語対応ダークモード

AI に投げる用のプロンプトテンプレ (PR 説明 / コードレビュー等) は 📚 Prompt Library →

git diff

📋 diff の取り方

# 全変更
git diff

# stage 済み
git diff --cached

# 特定コミット
git show abc123

# ファイル名だけ (大きすぎる時)
git diff --stat

変更ファイル

追加 / 削除

+0 / -0

推測 type

推測 scope

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

0 文字 (subject 行) — 50 推奨 / 72 上限

AI 用プロンプト (改善案を出してもらう)

📖 つまずきやすいポイント

git diff の出力を貼ると、変更ファイルと増減行から type と scope を推測し、Conventional Commits 形式のコミットメッセージの雛形と、AI に渡すためのプロンプトを組み立てます。処理はブラウザ内で完結します。推測できるのは「何を変えたか」までで、「なぜ変えたか」は diff のどこにも書かれていません — そして、あとから読み返す人が知りたいのは常に後者のほうです。

ケース	何が起きるか	どうする
推測された type が実際とずれる	type はファイルのパスと拡張子から推測しているので、同じ場所への変更でも意図が違えば当たりません。テストファイルを直せば `test` と出ますが、それがバグ修正に伴う期待値の更新なら `fix` が正しい場合があります。`docs` と `chore`、`refactor` と `fix` の境界も、diff からは判別できません。	推測は出発点として使い、必ず自分で上書きしてください。迷ったときの基準は「利用者から見て振る舞いが変わったか」です。変わったなら `feat` か `fix`、変わっていないなら `refactor` / `chore` / `test` / `docs`。この基準は、リリースノートを自動生成するときにそのまま効いてきます — 利用者に見せるべき変更だけが上の 2 つに入るので、後から手で選別する必要がなくなります。
1 コミットに複数の変更が混ざる	推測された scope が `()` や複数になるときは、コミットの粒度が大きすぎるという合図です。バグ修正とリファクタリングと依存更新が 1 つに入っていると、後から `git revert` したくても戻したくない部分まで戻ります*。`git bisect` で原因を絞り込むときも、当たったコミットが大きいほど絞り込めません。	`git add -p` でハンク単位に分けてステージし、意味ごとにコミットしてください。すでに混ぜて書いてしまった作業ツリーからでも、この方法で分割できます。目安は「1 コミットを 1 文で説明できるか」で、説明に「〜と〜」が入るなら分けたほうがよい合図です。分けたコミットの diff をこの画面に個別に貼れば、それぞれの雛形が得られます。
AI に diff を渡したら要約しか返ってこない	diff だけを渡すと、モデルにはコードの変化しか見えていません。結果として「〜を追加しました」「〜を修正しました」という、diff を読めば分かることを言い換えただけのメッセージが返ります。コミットメッセージの価値は、diff を読んでも分からないことを書く点にあるので、これでは書く意味がありません。	生成されたプロンプトに、この変更をした理由を 1〜2 行、自分の言葉で書き足してから渡してください。「タイムアウトの報告が月 3 件あったため」「仕様変更で税率が変わったため」といった外部の事実が入るだけで、返ってくる本文の質が変わります。加えて、関連する Issue 番号を書いておくと、半年後に読む人が経緯まで辿れます。テンプレートの参考にはプロンプトライブラリも使えます。

Conventional Commits に従う実利は、コミットメッセージから CHANGELOG とバージョン番号を自動生成できる点にあります。fix はパッチ、feat はマイナー、BREAKING CHANGE を含むものはメジャーへ、と semantic-release などが機械的に決めてくれます。逆に言えば、規約を守っていないコミットが 1 つ混ざるだけで、そのリリースの自動化は信頼できなくなります。導入するなら commitlint を pre-commit フックに入れて、書式を機械に守らせてください — 人の意志だけで揃い続けた規約は、見たことがありません。

📖 使い方

1

git diff コピー

ターミナルで `git diff` または `git diff --cached` の出力をコピー
2

貼って自動推測

変更ファイル / +- 行数 / type / scope を自動推測
3

コピーしてコミット

テンプレを微調整 → コピー → `git commit -m`

❓ よくある質問

type の判定は？

変更ファイル拡張子・パス・パターンから推測。.test.* → test、docs/ → docs、新規ファイル多 → feat、削除多 → refactor 等

AI に投げないとダメ？

不要。テンプレだけで commit できるレベル。AI プロンプトは「もっと上手いメッセージが欲しい」場合のオプション

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。

Diff → Conventional Commit ヘルパー

📖 つまずきやすいポイント

📖 使い方

❓ よくある質問

ご報告ありがとうございます！