はじめに
この記事では、コミットメッセージ規約 Conventional Commits の内容について要約しつつ、各項目の内容や例をまとめています。
※この記事の内容は要約が主なものとなります。元となる情報やその詳細については以下ページをご参照ください。
運用上のメリット
コミットメッセージの形式を明確に定めておくことには、以下のような運用上のメリットがあります。
- 自動リリースノート生成（Conventional Commits → semantic-release 連携）
- CI/CD パイプラインでの自動バージョニング（major/minor/patch 自動判定）
- 履歴の検索性向上（
git log --grep=featで機能追加だけ見れる） - タグ管理と整合性（
v1.2.3タグとコミット内容が一貫する）
コミットメッセージのフォーマット
Conventional Commits で提示されているコミットメッセージのフォーマットは以下です。
<type> ([optional scope]) : <description>
[optional body]
[optional footer(s)]日本語訳：
<型> ([任意 スコープ]) : <タイトル>
[任意 本文]
[任意 フッター]任意(optional)の項目と必須の項目があり、必須だけの構成とする場合は、以下のようになります。
<type> : <description>各項目の内容について、以下にまとめます。
必須の項目
まずは必須項目である型とタイトルについて確認しておきましょう。
型（type）
型（type）は必須項目で、コミット（≒変更内容）の種類を記載します。
型の種類は開発メンバーで合意が取れていれば自由ですが、例として以下のようなものが挙げられます。
（以下の用法はあくまで一例のため、参考程度にご参照ください）
| 型の種類 | 用途 | メッセージ例 |
|---|---|---|
| feat | 新機能の追加 | feat(auth): add JWT login API |
| fix | バグ修正 | fix(ui): correct header alignment |
| hotfix | 緊急修正 (リリース後、本番環境に直接適用する修正) | hotfix(payment): fix critical bug |
| docs | ドキュメント修正 | docs(readme): update setup guide |
| style | コードの整形（動作は変更なし） →インデントや改行など、コードの”見た目”変更 | style: format with prettier |
| refactor | リファクタリング（動作は変更なし） →関数の分割や命名変更など、構造の改善 | refactor(order): simplify order calc logic |
| perf | パフォーマンス改善 | perf(cache): reduce DB calls by 50% |
| test | テスト追加や修正 | test(api): add unit tests for login |
| chore | 開発環境や周辺設定の維持管理に関わる変更 （ビルド関連、CI/CD設定、依存関係更新） | chore(deps): update lodash to v4.17.21 |
タイトル（description）
タイトル（description）は必須項目で、1行で「何をしたか」の要約文を記載します。
- 英語の場合は 動詞の原形で開始（add, fix, update, remove…）
- 末尾にピリオド
.を付けない - 簡潔に（大体50文字以内が推奨）
任意の項目
続けて、任意で追加する項目についてまとめていきます。
スコープ（scope）
スコープ（scope）は任意の項目で、括弧括りで変更の対象モジュールや機能名を明示します。
ここでの名称は英単語のケバブケース（例: auth, payment-api, ui）で記述することが多いようです。
例:
feat(auth): add refresh token logic
fix(payment-api): correct transaction rollback本文（body）
本文（body）は任意の項目で、変更理由や詳細を記述します。
「何を、なぜ行ったか」の記述で、「どうやったか」など、コードで表現される部分は冗長に書かないのがポイントです。
フッター（footer）
フッター（footer）は任意の項目で、主に issue番号 や BREAKING CHANGEの明示、関連情報などを記述します。
Issue 追跡
チケット管理を行っている場合はIssueの追跡情報として番号や状態を記述します。
例：
Refs: #123→ 関連Fixes: #123orCloses: #123→ マージ時に自動クローズ
Breaking Change
後方互換性が壊れる変更の場合は、その旨をフッターに明記します。
例:
BREAKING CHANGE: The login API now requires JWT instead of session cookies.【補足】BREAKING CHANGE (後方互換性を破壊する変更)
BREAKING CHANGE とは“後方互換性を破壊する変更（Breaking Changes）が含まれている”ことを明示するための特別な記述です。
ライブラリ・API・サービスなどで、これまでのコードが動かなくなる/互換性が崩れる 可能性があるときに使用するもので、開発者や利用者への注意の目的があります。
記述方法として、主に以下２種類が使われます。
① フッターに「BREAKING CHANGE: XXXXXXXX」と内容を記載
➁ 方の記述の後に「!」 をつける （ feat!: remove deprecated login API ）
例として、以下のような変更の場合は「後方互換性破壊」になることが多いため注意が必要です。
- APIの仕様変更
- データ構造（JSON仕様やDBスキーマ変更など）の変更
- システム要件の変更
- 設定ファイルのフォーマット変更
実例まとめ
最後にコミットメッセージの実例を以下にまとめておきます。
任意の項目も含めているやや長めの形式にはなるため、あくまで一例としてご参照いただけますと幸いです。
新機能追加
feat(auth): add JWT login API
Implement JWT-based authentication with access and refresh tokens.
This replaces the old session-based login system.
Closes: #101バグ修正
fix(timezone): correct UTC+9 conversion in scheduler
Jobs were running twice on the DST switch date due to miscalculation.
Fixed by using moment-timezone library.
Refs: #234緊急 Hotfix
hotfix(payment): fix critical bug in payment API
Production transactions were failing due to null pointer in order service.
Applied immediate fix and patched endpoint.
Fixes: #789Breaking Change を含むリファクタ
refactor(user): migrate ID from int to UUID
Changed primary key of users table to UUID for better scalability.
BREAKING CHANGE: User IDs are now UUIDs instead of integers.
Clients must update their schema.
Closes: #567