本番デプロイのリリース作業を自動化した話 — Conventional Commits × セマンティックバージョニング × git-cliff

2026/6/2

代表

開発ツール DevOps

弊社コーポレートサイトでは、本番環境へデプロイするたびに「Git のタグを打つ」「リリースノート（変更履歴）を書く」という作業が発生していました。手作業は地味に手間がかかるうえ、書き忘れやバージョンの付け間違いも起こりがちです。

そこで今回、本番デプロイ後に「タグ打ち」と「リリースノートのドラフト生成」を自動化しました。この記事では、その土台となった次の3つの仕組みを、用語の簡単な解説と実際の設定サンプルとあわせて紹介します。

Conventional Commits の導入（Dependabot のコミットにも適用）
セマンティックバージョニング によるバージョン付け
git-cliff による変更履歴（Change log）の自動生成

1. Conventional Commits — コミットメッセージに「型」を持たせる

どんなもの？

Conventional Commits は、コミットメッセージの先頭に 型: 概要 という決まった形式を付ける規約です。代表的な型は次のとおりです。

feat: … 新機能の追加
fix: … バグ修正
docs: … ドキュメントの変更
refactor: … リファクタリング
build: / ci: … ビルドや CI の変更

feat: 顧客管理機能を追加
fix: 問い合わせ送信時のエラーを修正
feat!: API のレスポンス形式を変更   # 型のあとの「!」は破壊的変更を表す

ポイントは、コミットメッセージが「人間向けの記録」であると同時に「機械が解釈できるデータ」になることです。後述するバージョン判定や変更履歴の自動生成は、この型を読み取って動きます。

導入にあたっては、プロジェクトの開発ルール（CLAUDE.md）に一文を追加し、今後のコミットはこの規約に従うこととしました。

Dependabot のコミットにも適用する

依存ライブラリを自動更新してくれる Dependabot のコミットは、既定では Bump puma from 7.2.0 to 8.0.2 のような規約に従わないメッセージになります。このままだと自動化の仕組みが「変更」として認識してくれません。

そこで .github/dependabot.yml に commit-message を設定し、Dependabot のコミットも Conventional Commits 形式に揃えました。

version: 2
updates:
  - package-ecosystem: bundler
    directory: "/"
    schedule:
      interval: weekly
    commit-message:
      prefix: build      # 先頭に付ける型
      include: scope     # スコープを含める

これで Dependabot のコミットは次のようになります。

build(deps): bump puma from 7.2.0 to 8.0.2

依存更新もきちんと変更履歴に載り、バージョンにも反映されるようになりました。

2. セマンティックバージョニング — バージョン番号にルールを

どんなもの？

セマンティックバージョニング（Semantic Versioning, SemVer）は、バージョン番号を MAJOR.MINOR.PATCH（例: 1.2.3）の3つの数字で表し、それぞれを以下のルールで上げる規約です。

MAJOR（例: 1.x.x → 2.0.0）… 後方互換性のない変更
MINOR（例: 1.2.x → 1.3.0）… 後方互換を保った機能追加
PATCH（例: 1.2.3 → 1.2.4）… 後方互換を保ったバグ修正

「数字を見ればアップデートの影響度がわかる」のが利点です。

Conventional Commits と組み合わせる

今回の肝は、前回リリースからのコミットの「型」を見て、上げるべき番号を自動で決める点です。Conventional Commits とセマンティックバージョニングは、次のように自然に対応します。

コミットの型	バージョンの上がり方
`feat:`	MINOR
`fix:` / `refactor:` / `build:` など	PATCH
`!` 付き / `BREAKING CHANGE:`	MAJOR

つまり「どのバージョンにするか」を人が判断する必要がなくなり、コミットの書き方そのものがバージョンを決定します。

3. git-cliff — 変更履歴を自動生成する

どんなもの？

git-cliff は、Conventional Commits 形式のコミット履歴から 変更履歴（Change log）を自動生成するツールです。さらに、コミットの型から 次に上げるべきバージョン番号を算出する機能も持っています。まさに上の1・2を実行に移すためのツールです。

設定（cliff.toml）

挙動は cliff.toml で定義します。今回は「型ごとにカテゴリ分けして見出しを付ける」「型に応じてバージョンを上げる」よう設定しました（抜粋）。

[git]
# Conventional Commits として解釈する
conventional_commits = true
# 規約に従わないコミット（マージコミット等）は変更履歴から除外する
filter_unconventional = true
# 型ごとの見出し
commit_parsers = [
  { message = "^feat",         group = "✨ 新機能" },
  { message = "^fix",          group = "🐛 バグ修正" },
  { message = "^(build|ci)",   group = "🔧 ビルド・CI" },
]

[bump]
# feat は MINOR、破壊的変更は MAJOR、それ以外は PATCH
features_always_bump_minor = true
breaking_always_bump_major = true

使い方

実際のコマンドはとてもシンプルです。

# 次に上げるべきバージョンを算出する（例: v1.2.0 → v1.2.1）
git cliff --bumped-version

# 未リリース分の変更履歴を生成する
git cliff --bump --unreleased

git cliff --bump --unreleased を実行すると、次のような変更履歴が出力されます。

### ✨ 新機能
- 顧客管理機能を追加

### 🐛 バグ修正
- 問い合わせ送信時のエラーを修正

### 🔧 ビルド・CI
- bump puma from 7.2.0 to 8.0.2

カテゴリごとに整理された、そのまま読めるリリースノートができあがります。

全体の流れ

最後に、これらをデプロイのワークフロー（GitHub Actions）に組み込みました。本番デプロイが成功すると、以下が自動で実行されます。

git cliff --bumped-version で次バージョンを決定（Conventional Commits → セマンティックバージョニング）
git cliff で変更履歴を生成
Git タグを打ち、その内容で GitHub Release のドラフトを作成

デプロイのたびに発生していた手作業が、コミットの書き方を整えるだけでまるごと自動化されました。

おわりに

今回の自動化は、特別なツールを大量に導入したわけではなく、「コミットメッセージに規約を持たせる（Conventional Commits）」という小さな習慣を起点に、セマンティックバージョニングと git-cliff を組み合わせただけのシンプルな構成です。

それでも効果は大きく、「バージョンの付け間違い」「リリースノートの書き忘れ」といったヒューマンエラーがなくなり、リリース作業そのものを意識せずに済むようになりました。同じように手作業のリリースに悩んでいる方の参考になれば幸いです。