一、あなたのコミット履歴、"裸"のままになっていませんか？
こんなコミット履歴を見たことはありませんか？
* バグ修正
* 更新
* asdasd
* ちょっと機能追加
* また修正
一見「まあ動いてるからいいか」と思うかもしれません。でも、こういう履歴には実はたくさんの問題が潜んでいます。
- 問題を追いにくい：「バグ修正」ってどのバグ？いつのどの変更が原因なのか、履歴を見ても全然わからない。
- 変更履歴（CHANGELOG）を自動化できない：リリースノートを作ろうとしても、機械的に整理できる情報がゼロ。
- チーム開発でつらい：他の人が見たときに「この人、結局何をしたの？」が一目でわからず、コミュニケーションのコストが増える。
数ヶ月後の自分がこの履歴を見返したとき、きっと頭を抱えるでしょう。
そこで登場するのが、今回紹介する 約定式コミット（Conventional Commits） です。これは「コミットメッセージに一定のルールを持たせる」ためのシンプルな取り決め。この記事では、
- 約定式コミットとは何か（概念）
- どういう形式で書くのか（文法）
- 「こんなときはどの接頭辞を使えばいい？」（シーン別の実例）
を、専門用語をなるべく避けて説明していきます。読み終わるころには、あなたも今日からきれいなコミットが書けるようになっているはずです。
二、約定式コミットって何？（概念のおはなし）
2.1 一言で言うと
約定式コミットとは、コミットメッセージの書き方にルールを決める軽量な取り決めのことです。ひとことで言えば、「毎回のコミットを"人間の言葉で"かつ"規則的に"書こう」というルールブックです。
難しい仕組みではありません。「メッセージの先頭に、その変更の種類を表すラベルを付ける」——基本はこれだけです。
2.2 なぜわざわざルールを決めるの？
「別に自由に書けばいいじゃん」と思うかもしれません。でも、ルールを守ると次のようなメリットがあります。
メリット1：履歴が一目瞭然になる
先頭のラベルを見るだけで、「これは新機能」「これはバグ修正」とすぐわかります。チームの誰が見ても、何をした変更なのかが伝わります。
メリット2：変更履歴（CHANGELOG）を自動生成できる
規則的なメッセージになっていると、ツールが自動的に「今回のリリースではこんな機能が増えて、こんなバグが直りました」という一覧を作ってくれます。もう手書きでリリースノートを作る必要はありません。
メリット3：バージョン番号を自動で判断できる
約定式コミットは「セマンティックバージョニング（SemVer）」という考え方と相性が良いです。新機能の追加、バグ修正、互換性を壊す変更などをメッセージで表現しておくと、次に上げるべきバージョン番号（大きな更新か、小さな更新か）を自動的に決められます。
イメージしやすい例え
メールを送るときに、件名に「【業務】」「【至急】」「【私用】」といった分類を付けると、受け取った側がすぐ内容を把握できますよね。約定式コミットも、これと同じ「分類ラベル」をコミットメッセージに付ける仕組みだと考えるとわかりやすいです。
三、約定式コミットの基本フォーマット（文法の解説）
3.1 標準的な形はこうなっている
約定式コミットの基本フォーマットは次の通りです。
<型>[任意 スコープ]: <説明>
[任意 本文]
[任意 フッター]
一見ちょっと複雑に見えますが、実際に必須なのは「型」と「説明」の2つだけ。まずはここだけ押さえればOKです。
3.2 パーツごとに分解してみよう
- 型（必須）：その変更が「どういう性質のものか」を一語で表します。例：
feat（新機能）、fix（バグ修正）。型のあとには半角コロン（:）と半角スペースを付けます。 - スコープ（任意）：変更が影響する範囲・モジュールを、丸括弧で囲んで示します。例：
feat(login)なら「ログイン機能まわりの新機能」という意味。付けなくても構いません。 - 説明（必須）：「何をしたのか」を短くまとめた一文。型（とスコープ）のあとのコロン＋スペースに続けて書きます。
3.3 完成形を1つ分解してみる
例として、次のメッセージを見てみましょう。
feat(login): 電話番号によるSMS認証ログイン機能を追加
これを分解すると——
feat→ 型：新機能を追加した(login)→ スコープ：ログイン機能に関する変更:→ 区切りのコロン＋スペース電話番号によるSMS認証ログイン機能を追加→ 説明：具体的に何をしたか
こうして見ると、「ログイン機能に、電話番号のSMS認証ログインという新機能を追加したんだな」ということが、メッセージを見るだけで完璧に伝わりますね。
四、【重要】よく使うコミット型 ＋ シーン別の実例
ここがこの記事のいちばん大事なパートです。「こんなときは、どの接頭辞（型）を使えばいいの？」という疑問を、具体的なシーンで解消していきましょう。
4.1 まず覚えるべき2つ：feat と fix
feat —— 新機能を追加した
使う場面：これまでになかった、まったく新しい機能のコードを書いたとき。
- 例1：Webサイトに「ユーザーログイン」機能を追加した
→
feat: ユーザーログイン機能を追加 - 例2：カートに「一括削除」ボタンを付けた
→
feat(cart): カートの一括削除機能を追加
fix —— バグを修正した
使う場面：すでに存在する問題やエラーを解決したとき。
- 例1：カートの精算ボタンを押しても反応しなかったのを直した
→
fix(cart): カートで精算できない不具合を修正 - 例2：ログインページがスマホで表示崩れしていたのを調整した
→
fix(login): モバイル版ログインページの表示崩れを修正
💡 ワンポイント：
featとfixは、日常の開発の99%をカバーする2大接頭辞です。まずはこの2つさえ覚えておけば、ほとんどの場面を乗り切れます。
4.2 混同しやすい型（ここでしっかり見分けよう）
docs —— ドキュメントだけを変更
使う場面：README、コメント、説明資料などだけを変更し、実際のコードロジックには一切触れていないとき。
- 例：プロジェクトにインストール手順を追記した
→
docs: プロジェクトのインストール手順を追記
見分けのヒント：コードの中に「このロジックは○○のため」という説明コメントを追加しただけの場合も、docs に含まれます。
style —— 見た目（フォーマット）だけの調整
使う場面：インデントや空白、セミコロンなどを整えただけで、コードのロジックはまったく変わっていないとき。純粋に「見た目をきれいにした」だけの変更です。
- 例：Prettierでコードをフォーマットし直した
→
style: コードのインデントを統一
見分けのヒント：後述の refactor との違いは、こちらは「ロジックの変更を一切含まない」という点です。
refactor —— コードのリファクタリング
使う場面：コードの構造や書き方を変えたけれど、機能としての動きは以前とまったく同じ（新機能でもバグ修正でもない）とき。
- 例：重複していた3か所のコードを1つの共通関数にまとめた
→
refactor: 重複するフォーム検証ロジックを共通関数に抽出
見分けのヒント：判断基準は「この変更でユーザーが体感する変化がまったくない、かつ単なる見た目の整形ではない」なら refactor です。
test —— テストに関する変更
使う場面：テストコードを新しく追加したり、修正したりしたとき。
- 例：ログインAPIにユニットテストを追加した
→
test: ログインAPIのユニットテストを追加
chore —— 雑務・環境まわりの作業
使う場面：上のどれにも当てはまらない「雑用」的な作業。たとえば依存ライブラリのバージョンアップや、設定ファイルの変更など。
- 例：プロジェクト内のlodashのバージョンを上げた
→
chore: lodashを最新版にアップデート
4.3 発展的な型（知っておく程度でOK、必要なときに使う）
| 型 | 使う場面 | 例 |
|---|---|---|
build |
ビルドツールの設定を変更 | build: webpackのビルド設定を更新 |
ci |
CI/CDパイプラインの設定を変更 | ci: GitHub Actionsのワークフローを修正 |
perf |
パフォーマンス改善 | perf: トップページの画像読み込み速度を改善 |
4.4 一目でわかる：どの接頭辞を使えばいい？
迷ったときは、次の順番で自分に問いかけてみてください。上から順にチェックしていけば、たいていの場合は正しい型にたどり着けます。
新しい機能を追加した？ → はい → feat
バグを直した？ → はい → fix
ドキュメントだけを変更した？ → はい → docs
見た目の整形だけ（ロジック変更なし）？ → はい → style
リファクタリングした（動きは同じ）？ → はい → refactor
テストコードの変更？ → はい → test
依存や設定などの雑務？ → はい → chore
五、発展：互換性を壊す変更はどう表す？（選択学習）
ここは少し発展的な内容です。慣れてきたら読んでみてください。
5.1 「破壊的変更」とは？
破壊的変更（Breaking Change）とは、この変更によって、これまでの使い方が通用しなくなる／互換性がなくなる変更のことです。ライブラリやAPIを使っている人にとっては、対応が必要になる重要な変更です。
5.2 2つの表し方
破壊的変更は、次のどちらかの方法で明示します。
方法1：フッターに BREAKING CHANGE: と書く
feat: ユーザー情報APIのレスポンス形式を変更
BREAKING CHANGE: レスポンスのフィールド名 userName を username に変更しました
方法2：型（またはスコープ）のあとに ! を付ける
feat(api)!: ユーザー情報APIのレスポンス形式を変更
具体的なシーン：APIが返すフィールド名を userName から username に変えたとします。すると、これまで userName を参照していた古いコードはエラーになります。こういうときこそ、破壊的変更として明示しておくべきです。この目印があることで、バージョン番号の大きな更新（メジャーアップデート）が必要だと自動的に判断できます。
六、ルールを自動で守らせる：おすすめツール
「ルールはわかったけど、毎回意識するのは大変そう…」——そう感じたあなたに朗報です。実は、ルールを守っているかどうかを自動でチェックしてくれるツールがあります。
- commitlint：あなたのコミットメッセージが約定式コミットのルールに沿っているかを自動でチェックしてくれるツールです。
- husky：
git commitを実行したタイミングでチェックを発動させる仕組みです。ルールに違反していると、そのままコミットをブロックしてくれます。
この2つを組み合わせて使うと、チームの全員が「いやおうなく」ルールを守るようになります。個人の自覚だけに頼らなくて済むので、ルールが形骸化しにくくなるのが大きなメリットです。
七、まとめ：今日から「意味のある」コミットを書こう
長くなりましたが、要点はとてもシンプルです。
- まずは
featとfixの2つだけ覚えればOK。残りは使いながら少しずつ慣れていきましょう。 - 規範を守るコミットは「形式主義」ではありません。数ヶ月後の自分、そしてチームメンバーが、必ず「あのとき丁寧に書いておいてよかった」と感謝することになります。
- 次にコードをコミットするとき、まず1回だけ試してみてください。きれいに整った履歴を見れば、その気持ちよさをすぐ実感できるはずです。
もっと深く学びたくなったら、公式サイト（conventionalcommits.org）をのぞいてみるのもおすすめです。今日から、あなたのコミット履歴を「裸」から卒業させましょう。
