Conventional Commits とリリース管理
概要
コミットメッセージは 機械可読なインターフェース であり、単なる散文ではありません。自動バージョン管理とチェンジログ生成はこれを解析します。不正な形式のメッセージは、誤った公開バージョンや壊れたリリースを引き起こします。小さな規律（適切に整形された1つのメッセージ）が、大きな正確性（正確なチェンジログ、正しいバージョンアップ）を無償で生み出します。
形式
<type>(<scope>): <description>
| 型 | 効果 / 用途 |
|---|---|
feat | 新機能 — minor バンプ |
fix | バグ修正 — patch バンプ |
docs | ドキュメントのみ |
chore | メンテナンス、依存関係、設定 |
refactor | 動作を変えないコード変更 |
test | テストのみ |
ci / build | パイプライン / ビルドシステムの変更 |
- 命令形: 「add X」であって、「added X」や「adds X」ではない。
- 破壊的変更:
feat!:またはフッターにBREAKING CHANGE:— major バンプをトリガー。 - Scope（スコープ） は任意だが推奨:
feat(auth):、fix(db):。
重要な詳細
- 型とバージョンの関係：
featとfixを間違えると、誤ったバージョンがリリースされる。 型は意図的に選ぶ。「add」＝新機能、「update」＝既存機能の強化、「fix」＝バグ。 - スカッシュマージ：PR タイトルが、実際に出荷されるコミットになる。 それ自体が有効な Conventional Commit でなければ、リリースが間違ってしまう。
- 人間が作成した文章。 AI・アシスタントの帰属表示、
Co-authored-byトレーラー、生成元フッターは禁止。コミットは人間が書いたように読めるべき。
よくある言い訳
| 言い訳 | 現実 |
|---|---|
| 「メッセージは本当は重要じゃない」 | チェンジログとバージョン番号を決定する。機械的に重要です。 |
「この機能には chore で十分だろう」 | chore ではバージョンが上がらない。ユーザーはリリースでその機能を受け取れない。正しい型を使うこと。 |
| 「後で PR タイトルを直すよ」 | スカッシュマージでは、マージ時にタイトルが確定する。マージ前に修正すること。 |
「Co-authored-by トレーラーは問題ない」 | プロジェクトルールで AI の帰属表示を禁止している。例外はない。 |
レッドフラグ — 即 STOP
- 型プレフィックスのないコミットメッセージ
- ユーザー向けの動作を追加・修正する変更に
chore/docsを使う - 有効な Conventional Commit になっていないスカッシュマージの PR タイトル
- AI の帰属表示や
Co-authored-by行
強制ルール:
- PR タイトル — CI で検証、ブロッキング（
amannn/action-semantic-pull-requestを使用）。 スカッシュマージではタイトルが出荷されるコミットになるため、これが最も重要なゲート。 - AI 帰属表示 — Claude/Anthropic を指定する
Co-authored-byトレーラーやGenerated with [Claude…]フッターを、ブランチコミットと PR 本文（本文はスカッシュコミットの本文になる）の両方で拒否する「No AI Attribution」ジョブ（ブロッキング）。 人間によるCo-authored-byトレーラーには影響しない。 - ブランチコミットの本文 — あえて lint 非対象。スカッシュマージでは破棄されるため、チェンジログに到達することはない。マージコミットに移行する場合は、commitlint を追加すること。
既知のギャップ: コミットがエージェントアカウントによって 作成 された場合、GitHub はスカッシュ時に Co-authored-by トレーラーを自動生成する — これは PR チェックが実行された後である。上記のゲートではこれを検出できない。エージェントの ID でコミットしてはならない。
完全な根拠: 「エンジニアリング憲法」第 III 条（engineering-constitution/references/engineering-constitution.md に同梱）。