import { NavigationBlock } from "@/components/blog/NavigationBlock";
コミットメッセージの型（最小ルール）｜履歴が読める・戻せる書き方
コミットメッセージに迷うのは、「何を書けばいいか」の型がないからです。
型がないと、人によって「修正」「更新」「変更」ばかりになり、後から見ても何をしたか・なぜしたかが分かりません。その結果、バグ調査や差し戻しのときに判断材料を失います。
この記事が想定する読者：Web制作・開発の現場で、技術選定や改善の判断軸を持ちたい方。情報収集で止まらず、前提・優先順位・次の一手まで整理したい担当者。
判断を誤るとどうなるか：一般論の理解だけで終えると、自社の制約（スタック・工数・運用体制）とずれて選定や実装が空回りしやすい。前提・撤退線・次の一手まで言語化してから進めると判断がぶれにくくなります。
この記事では、最小の型（いつ切るか／何を書くか／何を書かないか）をルールとして提示します。深い理解のため、「なぜその型が効くか」と「型を崩したときに起きる失敗」もセットで整理します。
この記事を読む前に
コミットの「何を記録するか」の基礎は、コミットとは？で押さえておくと理解が深まります。コミットをどの単位でまとめるかは、ブランチ戦略の超入門と合わせて読むと、運用全体の判断がしやすくなります。
なぜ「型」が必要か：履歴は判断のログである
コミット履歴は、後から「いつ・何を・なぜ変えたか」を再現するためのログです。
メッセージが「修正」「更新」だけだと、次のような判断ができなくなります。
- バグ調査：「この不具合はどのコミットで入ったか」を追えない
- 差し戻し：「どのコミットまで戻すか」を選べない
- レビュー：「この変更の意図は何か」を説明できない
- 合流：マージする側が「何が入るか」を把握しづらい
失敗像：型がないまま運用を続けると、履歴がノイズになり、いざ問題が起きたときに「誰が・いつ・何をしたか」が分からず、手戻りが増えます。
この記事の仮説：「いつ切るか」「何を書くか」「何を書かないか」の3つを型として決めると、履歴が読め・戻せ・判断できる状態になる。
型1：いつ切るか（コミットの単位）
「1つのコミットに何を含めるか」を揃えると、履歴の粒度が揃います。
推奨：1つの論点＝1コミット
- 1つの機能追加 → 1コミット
- 1つのバグ修正 → 1コミット
- 1つのリファクタ → 1コミット（機能変更と分ける）
理由：後から「この機能を外したい」「この修正だけ戻したい」という判断がしやすくなります。複数の論点を1つにまとめると、部分的に戻せず、全体を戻すか否かだけの判断になります。
避けたい単位
- 1日分をまとめて1コミット：何をしたかが分からなくなる
- 複数機能・複数修正を1コミット：差し戻しの単位が粗くなる
- 「とりあえず保存」の連打：ノイズが増え、本当に重要な変更が埋もれる
判断の目安
「このコミットを revert したとき、何が消えるか」を一言で言えるか。言えれば1つの論点に収まっている可能性が高いです。
型2：何を書くか（メッセージの構成）
メッセージは「何をしたか」が一言で分かるように書きます。
推奨：動詞で始める・具体的に
| 良い例 | 悪い例 | 理由 |
|---|---|---|
| ユーザー登録フォームを追加 | フォーム追加 | 「何の」フォームか分かる |
| ログイン画面のデザインを修正 | 修正 | どこを修正したか分かる |
| 検索が遅い問題を修正（インデックス追加） | バグ修正 | 何の不具合か・どう直したか分かる |
| パフォーマンス改善のため画像を最適化 | 画像最適化 | 目的が分かる（理由が必要なとき） |
理由：動詞で始めると「何をしたか」が文の先頭に来て、git log --oneline で一覧を見たときにも意図が伝わります。抽象的だと、開かないと内容が分かりません。
言語：日本語 or 英語をチームで統一
どちらでもよいですが、プロジェクト内で統一すると読みやすくなります。混在すると、誰が何を書いたかで文体が変わり、履歴のトーンがバラけます。
長さの目安
- 1行目（タイトル）：50字以内が目安。多くのツールは1行目だけ表示するため、ここに要点を書く。
- 2行目以降（本文）：理由・背景を書く場合は空行を挟んで追記。必須ではない。
型3：何を書かないか（禁止事項）
以下を書かないだけで、履歴の質が上がります。
禁止に近い表現
- 「修正」「更新」「変更」だけ：何を修正したか分からない
- 「諸々」「いろいろ」「その他」：論点が複数混ざっているサイン。分割する
- 「WIP」「作業中」を共有ブランチに残す：未完のままマージされると事故の元。push 前には「何が完了していて何が未完か」に書き換えるか、完了してからコミットする
理由
「修正」だけのコミットが並ぶと、履歴が差分の羅列になり、判断の履歴ではなくなります。後から見た人が「この変更はなぜ必要だったか」を説明できず、安心して revert やマージができません。
チームで揃えるときの最小セット
ルールを増やしすぎると守られにくくなります。まずは次の3つで十分です。
- いつ切るか：「1論点＝1コミット」を原則にする。例外（例：大規模リファクタを分割しきれない）は事前に合意する。
- 何を書くか：1行目は動詞で始め、具体的に「何をしたか」が分かるようにする。日本語 or 英語を統一する。
- 何を書かないか：「修正」「更新」「変更」だけは書かない。「諸々」「WIP」を共有ブランチに残さない。
この3つをチームのREADMEや開発ルールに明文化し、レビューで「メッセージが型に沿っているか」を軽く見るだけで、履歴の質が持続します。
よくある質問
既存の「修正」ばかりの履歴は直すべき？
過去の履歴を書き換える（rebase 等）は、すでに共有されているブランチでは事故になりやすいです。これからのコミットから型を適用し、過去分は触らない方が安全です。必要なら「今後のコミットからルールを適用する」旨をチームで共有します。
英語と日本語、どちらがよい？
どちらでもよいです。チームで統一しているかが重要です。OSSや海外協力が多いなら英語、国内チームで日本語が主なら日本語で揃えると読みやすくなります。
理由はいつ書くか？
「なぜこの変更をしたか」がコードや差分からは分かりにくいときに書きます。バグ修正の原因、仕様変更の背景、パフォーマンス対策の根拠など。必須ではありませんが、後から見た人が判断しやすくなります。
型に合わない変更（大規模リファクタ等）は？
「1論点＝1コミット」にしにくい場合は、コミットメッセージの1行目で「何の作業か」を明示し、2行目以降で「どの範囲をどう変えたか」を短く書くと、後から追いやすくなります。型は「迷ったときの基準」であり、例外を禁止するものではありません。
コミットメッセージの型と判断のログ
- コミットメッセージに型があると、履歴が「判断のログ」として読め・戻せ・説明できる。
- いつ切るか：1論点＝1コミットを原則にする。
- 何を書くか：1行目は動詞で始め、具体的に。言語はチームで統一する。
- 何を書かないか：「修正」「更新」「変更」だけ、「諸々」「WIP」を共有ブランチに残さない。
- チームでは最小3ルールを明文化し、レビューで軽く見るだけで質が持続する。
関連記事
- コミットとは？：コミットの基礎と「何を記録するか」
- ブランチ戦略の超入門：コミットをどのブランチでまとめるか
- マージとは？：ブランチを統合するときの考え方
- プル（pull）とは？：リモートとの同期とPR
nextInCategory={[ { title: "ブランチ戦略の超入門｜main / feature / release の役割と最小ルール", url: "/blog/web/branch-strategy-beginners-guide" }, { title: "ブランチとは？超初心者向け完全ガイド", url: "/blog/web/what-is-branch-beginners-guide" }, { title: "Gitのコミットとは？実務で迷わない\"コミットメッセージの型\"と最低限のルール", url: "/blog/web/what-is-commit-beginners-guide" }, { title: "Gitとは？超初心者向け完全ガイド", url: "/blog/web/what-is-git-beginners-guide" }, ]} philosophyLink={true} />