AIに commit messageを生成してもらったり、AIが git commit することが多くなりました。prefix の意味を知っていると、AI が生成した commit messageの意味を汲み取りやすくなり、要注意のコミットなのか、斜め読みでいいのかを判断しやすくなります。また手作業でgit commit するときに、chore 以外の候補を選ぶことができます。
Conventional Commits 標準プリフィックス
| Prefix | 意味（日本語） | 具体的な作業例 |
|---|---|---|
| feat | 新機能 | 新しい画面の移行完了、新しい共通関数の追加。 |
| fix | 不具合修正 | 「一部のPCで出るJSエラー」の修正、タイポ修正。 |
| build | ビルド・依存関係 | pnpm update、Vite設定変更、ファイルのリネーム。 |
| ci | 自動化・CI/CD | GitHub Actionsの編集、Dockerfileの修正。 |
| refactor | リファクタリング | ロジックの整理、TS化（機能を変えないコード改善）。 |
| perf | パフォーマンス | ビルド速度の改善、レンダリング速度の向上。 |
| test | テスト | PlaywrightやVitestのテスト追加・修正。 |
| docs | ドキュメント | README.md の更新、PHPDocの記述追加。 |
| style | スタイル・書式 | Prettier実行、セミコロン忘れ、空行の調整。 |
| chore | その他・雑用 | .gitignore の編集、ライセンス表記の更新など。 |
| revert | 打ち消し | 以前のコミットを取り消す（「やっぱり戻す」とき）。 |
| BREAKING CHANGE | 破壊的変更 | prefixではなく、本文最後に書いてもよい |
プリフィックスと組み合わせる「動詞」の使い分け
標準プリフィックス（refactor: など）の後ろに続く動詞を使い分けると、変更の意図がより明確になります。
| 動詞 | ニュアンス | 使い分けのポイント |
|---|---|---|
| improve | 質の向上 | refactor: improve readability（ロジックは変えず読みやすくした） |
| change | 転換・交換 | refactor: change loop strategy（設計思想ややり方を変えた） |
| update | 更新（微調整） | build: update vite（中身の役割は変えず、最新に合わせた） |
| upgrade | 更新（昇進・向上） | build: upgrade PHP to 8.3（大きな進化。破壊的変更の可能性あり） |
| remove/delete | 不要な機能やファイルの廃止 | build: delete legacy fuga.mjs（使わなくなった古い fuga.mjs の削除） |
| cleanup | 見栄えや可読性の向上 | refactor: cleanup debug logs（console.log の一括削除） |
地雷を知らせる「！」マーク
最も重要なのが、**破壊的変更（Breaking Change）**の可視化です。
build!: ... や refactor!: ... のように、prefix の直後に ! を付けるだけで、「このコミットを境に仕様が変わった（地雷があるかもしれない）」という強烈な警告になります。
使い分けに迷ったとき
buildvsci:build: 成果物（dist/）の中身や作り方が変わるもの。ci: GitHub Actions の「回し方」やコンテナ環境が変わるもの。
refactorvsstyle:refactor: ロジックの書き方を変える（関数の抽出など）。style: ロジックに一切触れない（インデントやスペースの調整）。
fixvsfeat:fix: 「本来あるべき姿」に戻す。feat: 「今までできなかったこと」をできるようにする。
refactor、perf、improve の使い分け
| Prefix | 主な目的 | コードの挙動（ロジック） | 作業例 |
refactor | 構造の整理 | 変えない（等価交換） | 巨大な関数を「複雑度 5」に分割する。 |
perf | 速度・効率 | 変えない（が、内部は変わる） | forEach を for に変えてループを高速化。 |
improve | 質の向上 | 少し変わる（改良） | エラーメッセージを分かりやすく書き換える。 |
例えば、「共通の計算ロジックを別ファイルに切り出し、ついでに処理を高速化した」場合：
- ファイルの切り出しのみ
refactor: extract calculation logic to helper.mjs
- アルゴリズムの改善（高速化）
perf: optimize loop in calculation logic
- 変数の命名などをより分かりやすく修正
refactor: improve variable naming for clarity
update/upgrade、change の使い分け
update/upgrade は「最新化・追従」であり、change は「性質・挙動の切り替え」です。
「これはただの update（最新化）ですよ」 と言うのか、「あえて change（変更）しましたよ」 と言うのかで、相手（将来の自分や担当者）の警戒レベルが変わります。
| 単語 | イメージ | 状態の変化 | 影響範囲のニュアンス |
update | 微調整 | v1.2.1 → v1.2.2 | バグ修正や最新化。基本は「壊れない」。 |
upgrade | 昇進・向上 | v1.2.1 → v2.0.0 | メジャー版アップ。機能向上だが「注意が必要」。 |
change | 転換・交換 | A 方式 → B 方式 | 仕様や仕組みの変更。コードの「意味」が変わる。 |
- update: (最新の状態にする)
- 「古いものを新しくする」「内容を現状に合わせる」ときに使います。
- 「中身は変わるが、役割や場所は変わらない」 イメージです。
build: update vite to v8.1（バージョンを上げた）docs: update README with new setup steps（古くなった記述を最新に直した）ci: update node version in Dockerfile（環境を最新に合わせた）
- upgrade: (最新の状態にする、ただし破壊的変更あるので注意してね！)
- updateとほぼ同じ意味ですが、破壊的変更（!）を伴うときは updateではなく upgrade。
build: upgrade Vite from 7 to 8
- change: (性質を切り替える)
- 「エンジニアが意図的に設計を変えた」「A だったものを B にする」「仕組みそのものを変える」ときに使います。
refactor: change loop from forEach to for...of（ループの回し方を変えた）feat!: change authentication from Basic to Digest（認証方式を切り替えた）build: change output directory to /dist/assets（出力先を別の場所へ変えた）
delete/remove、cleanup の使い分け
cleanup は「整理整頓（中身は残る）」、delete/remove は「撤去（存在が消える）」です。
| 項目 | cleanup (整理) | delete / remove (除去) |
| 主な目的 | 見栄えや可読性の向上。 | 不要な機能やファイルの廃止。 |
| コードの残り方 | 中身は洗練されて残る。 | コードやファイルが消滅する。 |
| 具体的な作業 | デバッグログ削除、コメント修正。 | 使わなくなった古い .mjs の削除。 |
| 作業例 | console.log の一括削除。 | 移行済みの fuga.mjs を消す。 |
例えば、「新ファイルに移行し、旧ファイルを消し、デバッグ用のログを掃除する」 という一連の流れ：
- 古いファイルを消す
build: delete legacy fuga.mjs- （「消したぞ！」という明確な意思表示）
- 新しいファイル内の試行錯誤の跡（ログ）を消す
refactor: cleanup debug logs- （「コードが製品レベルに整ったぞ」という合図）
テストを修正・リファクタリングした場合は？
テストそのものの変更は、「アプリケーションコードではない」を強調するために「test:」を使います。
| Prefix | 使うタイミング | 具体的な作業例 |
test: | テストそのもの の追加・変更 | 新しい it(...) の追加、期待値（Expect）の修正。 |
ci: | テスト実行環境 の設定変更 | GitHub Actions の jobs 修正、Node バージョン変更。 |
build: | テスト基盤・依存関係 の変更 | vitest.config.ts の編集、テスト用ライブラリの pnpm update。 |
「テストを修正した」と言っても、その理由は様々です。メッセージの冒頭（Subject）に以下の動詞を組み合わせると、後から「地雷」を探す手間が省けます。
- 新しくテストを書いたとき
test: add E2E test for 110 screen migrationtest: create unit test for sales calculation helper
- アプリの仕様変更に合わせてテストを直したとき（「修正」）
test: update expected value for digest authtest: fix failing test due to path change
- テストコード自体を綺麗にしたとき（「掃除」）
test: refactor setup process in Playwrighttest: cleanup unused mock data
参考
Conventional Commits
人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様
www.conventionalcommits.org
【Git】コミットメッセージの先頭につけた方が良い単語リスト- prefix集 - - Qiita
コミットメッセージで、先頭に接頭辞(prefix)を使うことで、コミットメッセージに含める情報を明確にすることができます。私は、初学者のため、このリストを忘れることが多いので、すぐに振り返ることができるように、記しておく。 表 接頭辞 .....
qiita.com
