コミットメッセージの書き方｜ルール・例文・プレフィックス一覧

コミットメッセージは、「1行目に変更の要約」「2行目は空行」「3行目以降に、なぜ変更したか」を書くのが基本です。1行目の先頭に feat:（機能追加）や fix:（バグ修正）といったプレフィックスを付けて、変更の種類をひと目でわかるようにする書き方も広く使われています。

コミットメッセージは、半年後の自分やチームのメンバーが「なぜこのコードはこうなっているのか」を知るための記録です。この記事では、基本の形とルール、プレフィックスの一覧と使い分け、日本語での例文、チームで統一する仕組み、書き間違えたときの直し方までを解説します。

コミットメッセージの基本の形

fix: ログイン後に元のページへ戻らない問題を修正

ログイン画面へ遷移する際に、遷移元のURLを保持していなかったため、
ログイン後は常にトップページに戻っていた。
クエリパラメータ redirect_to に遷移元を保持し、ログイン後に戻すようにした。

Closes #123

本文には「何を変えたか」より「なぜ変えたか」を書くのがポイントです。何を変えたかは差分（diff）を見ればわかりますが、なぜそうしたのかは、コードからは読み取れないからです。

よいコミットメッセージの7つのルール

英語圏で広く知られている「7つのルール」を、日本語で書く場合の目安とあわせて整理します。

件名を短くするのは、git log --oneline やGitHubの画面で、1行目だけが一覧表示されるからです。長すぎる件名は途中で切れて表示されます。

プレフィックス一覧（Conventional Commits）

1行目の先頭に変更の種類を付ける書き方は、Conventional Commitsという仕様として整理されています。

<種類>(<範囲>): <要約>

迷いやすい使い分け

• style と refactor — 見た目だけの変更（空白・改行・フォーマッターの適用）はstyle、変数名の変更やメソッドの分割など、コードの構造に手を入れるものはrefactor
• fix と refactor — 利用者から見た動作が変わる（誤りが直る）ならfix、変わらないならrefactor
• feat と perf — できることが増えるならfeat、同じことが速くなるだけならperf
• build と chore — 依存ライブラリやビルドの設定はbuild、それ以外の雑務はchore

1つのコミットに複数の種類が混ざって迷うときは、コミットを分けるサインです。「機能追加」と「ついでのリファクタリング」は、別のコミットにしておくと、レビューも取り消しもしやすくなります。

範囲（スコープ）

変更した機能やモジュールを、括弧で付け加えることもできます。

feat(auth): パスワードリセットのメール送信を追加
fix(order): 在庫0の商品が注文できる問題を修正

範囲の名前は、チームで一覧を決めておくと揃います。

破壊的変更の書き方

既存の利用者に影響がある変更（APIの仕様変更、設定項目の削除など）は、種類の後ろに ! を付けるか、フッターに BREAKING CHANGE: を書きます。

feat(api)!: 注文APIのレスポンスから旧項目 total_price を削除

BREAKING CHANGE: total_price は廃止しました。amount を使用してください。

Conventional Commitsの形式で書いておくと、semantic-releaseやrelease-pleaseなどのツールで、変更履歴（CHANGELOG）の作成やバージョン番号の決定を自動化できます。feat はマイナーバージョン、fix はパッチバージョン、破壊的変更はメジャーバージョンを上げる、という対応です。

日本語の例文：よい例と、改善したい例

「レビュー指摘対応」「修正」のような、後から読んで何もわからない件名は、最もよく見かける改善ポイントです。「半年後に git log だけを見て、何をしたか思い出せるか」を基準にすると判断しやすくなります。

本文に書くとよいこと

• 変更の理由：なぜこの変更が必要だったか（不具合の原因、仕様の変更など）
• 検討した別の方法：なぜ他の方法を選ばなかったか
• 影響範囲：他の機能への影響、移行作業の必要性
• 注意点：一時的な対応である、後で見直す必要がある、など

フッターの便利な書き方

Issueの自動クローズ

GitHubでは、コミットメッセージやプルリクエストに次のキーワードとIssue番号を書くと、デフォルトブランチにマージされたときに、Issueが自動でクローズされます。

Closes #123
Fixes #456
Resolves #789

クローズせず関連を示すだけなら、Refs #123 や #123 のように書きます。

共同作業者の記録

ペアプログラミングなどで一緒に作業した人を、次の形式で記録できます。GitHubでは、共同作業者としてコミットに表示されます。

Co-authored-by: 山田太郎 <yamada@example.com>

チームで統一する仕組み

ルールを決めても、人の注意だけで守り続けるのは大変です。仕組みで揃えるのが確実です。

コミットテンプレート

git config --global commit.template ~/.gitmessage

# ~/.gitmessage の例（#で始まる行はコミットメッセージに含まれない）
# <種類>(<範囲>): <要約>  ← 全角35文字以内
# 種類: feat fix docs style refactor perf test build ci chore revert
#
# なぜ変更したか:
#
# Closes #

git commit を実行すると、エディタにこのテンプレートが表示され、書き方を毎回確認できます。

commitlintで自動チェック

commitlintは、コミットメッセージがルールに沿っているかを検査するツールです。Gitのフック（huskyなどで設定）に組み込むと、ルールに合わないコミットをその場で止められます。CIで、プルリクエストのコミットをまとめて検査することもできます。

スカッシュマージの場合

プルリクエストを「Squash and merge」で取り込む運用では、プルリクエストのタイトルが、main ブランチのコミットメッセージになります。この場合は、個々のコミットよりも、プルリクエストのタイトルにルールを適用するのが効果的です。

書き間違えたときの直し方

直前のコミットメッセージを直す

git commit --amend

過去のコミットに修正をまとめる（fixup）

git commit --fixup=<直したいコミットのID>
git rebase -i --autosquash main

「レビュー指摘対応」のような小さな修正コミットを、元のコミットに統合できます。作業途中のコミットを整理してからプルリクエストを出すと、履歴が読みやすくなります。

注意：--amend や rebase は履歴を書き換えます。すでにpushして、他の人も使っているブランチでは行わないのが原則です。自分だけの作業ブランチで、pushする前に整えましょう。

AIにコミットメッセージを書かせるときのコツ

エディタやAIのコーディング支援で、差分からコミットメッセージを自動生成できるようになりました。便利ですが、次の点に注意すると質が上がります。

• AIは差分から「何を変えたか」は書けるが、「なぜ変えたか」はわからない。理由は自分で1行加える
• プロジェクトのルール（プレフィックス、日本語か英語か、文字数）を指示に含める。リポジトリのルールファイルに書いておくと、毎回指示しなくて済む
• 1つのコミットに複数の目的が混ざっていると、要約がぼやける。AIの要約が長くなるときは、コミットを分けるサイン

よくある質問

Q. コミットメッセージは日本語と英語のどちらで書くべきですか？ A. チームで統一されていればどちらでも構いません。海外のメンバーがいる、OSSとして公開する場合は英語、国内のチームで細かなニュアンスを残したい場合は日本語、という選び方が一般的です。プレフィックス（feat・fixなど）だけ英語にし、要約は日本語で書く形もよく使われます。

Q. コミットはどのくらいの単位で分けるべきですか？ A. 「1つのコミットで1つの目的」が目安です。取り消したいときに、そのコミットだけを取り消せる単位にしておくと扱いやすくなります。

Q. 絵文字のプレフィックス（gitmoji）は使ってもいいですか？ A. チームで合意していれば使えます。視覚的にわかりやすい一方、ツールでの自動処理や検索のしやすさでは、文字のプレフィックスの方が扱いやすい場合があります。

Q. プレフィックスに当てはまらない変更はどうすればいいですか？ A. chore を使うのが一般的です。ただし、chore が多すぎる場合は、チームの実態に合った種類を追加するか、コミットの分け方を見直すきっかけにします。

まとめ

• 1行目に要約、2行目は空行、3行目以降に理由が基本の形
• 本文には「何を」より「なぜ」を書く。何を変えたかは差分でわかる
• 件名は短く（日本語なら全角35文字程度まで）、句点を付けない
• プレフィックスは feat・fix・docs・style・refactor・perf・test・build・ci・chore・revert。迷ったらコミットを分ける
• 破壊的変更は ! か BREAKING CHANGE:。形式を揃えると変更履歴を自動生成できる
• テンプレート・commitlintで仕組みとして揃え、スカッシュマージならPRのタイトルを整える
• 直すなら --amend・--fixup。ただしpush済みの共有ブランチでは行わない

株式会社RJCでは、コミットメッセージのような日々の小さな習慣も、チームで気持ちよく開発するための大切な技術だと考えています。こうした知識を仲間と共有しながら、一緒に成長を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。