Claude CodeでGitHub Releaseをバックデートするワークフロー構築事例

プロジェクトの初期段階では、機能開発のスピードが優先され、リリースノートの作成が後回しになることは少なくありません。私たちのプロジェクトも例外ではなく、気づけば数ヶ月分のGitHub Releaseが存在しない状態に陥っていました。

この課題を解決するため、Claude Codeを活用し、過去の　Pull Request　マージ履歴からリリースノートを遡って作成する半自動ワークフローを構築しました。本記事では、その具体的な手法と、導入によって得られた効果についてご紹介します。

抱えていた課題

日々、開発を続けているものの、プロジェクトがアクティブであることがGitHub repositoryの情報から分かりづらいという課題を感じていました。しかし、手動で過去の履歴を遡ってリリースノートを作成するのは、あまりにも非効率で現実的ではありません。

解決策: Claude Codeによる半自動リリースワークフロー

そこで私たちは、gitコマンド、gh CLI、そしてClaude Codeを組み合わせた半自動ワークフローを構築しました。このワークフローの目的は、特定の日付範囲のマージコミットからリリース情報を抽出し、対話形式で確認しながらバックデート付きのGitHub Releaseを作成することです。

今回は私が都度確認しながら進めるスタイルを採用しましたが、オートパイロットさせて完全自動化することも可能です。

ワークフロー概要

ワークフローは以下のステップで構成されています。

日付ごとのマージ履歴の確認: 特定の日にmainブランチへマージされたPRを抽出します。
PR詳細の取得: 抽出したPR番号からタイトルや作者情報を取得します。
Claudeによるバージョン判定: PRの内容をClaude Codeが分析し、セマンティックバージョニングに基づいたバージョンのインクリメント（パッチ/マイナー）を推奨します。
バックデート付きタグの作成: ユーザーの承認後、過去の日付でGitタグを作成します。
GitHub Releaseの作成: 生成された変更履歴とタグを使って、GitHub Releaseを作成します。

ステップ1: 日付ごとのマージ確認

まず、git log を使って、指定した1日分のマージコミットをリストアップします。--first-parent オプションが重要で、これによりmainブランチへの直接的なマージ（PRのマージコミット）のみに絞り込むことができます。

git log --oneline --since="2025-05-01T00:00:00" --until="2025-05-02T00:00:00" --first-parent main --format="%h %s"

ステップ2: PR詳細の取得

次に、gh pr view コマンドで各PRの詳細情報を取得します。複数のPRがある場合は、forループを使って並列で効率的に処理します。

# 複数のPR情報を一括で取得
for pr in 1001 1002 1003; do
  gh pr view $pr --json title,author --jq "{pr: $pr, title: .title, author: .author.login}"
done

ステップ3: Claudeによるバージョン判定と対話

ここがこのワークフローの心臓部です。取得したPR情報をClaude Codeに渡し、リリースノートのドラフトと推奨バージョンを生成させます。

実際の対話フロー例:

Claude: ## 2025-05-01 のマージ内容
 
| PR   | タイトル            | 作者        |
|------|---------------------|-------------|
| #123 | Add new feature X   | @developer1 |
| #124 | Fix bug in Y        | @developer2 |
 
**推奨**: 新機能追加のため **v0.38.0**（マイナー）
 
**v0.38.0** として作成してよいですか？ (ok/パッチ/マイナー)
 
User: ok
 
Claude: ✅ **v0.38.0** 作成完了
---
## 2025-05-02 のマージ確認
...

ClaudeがPRタイトルから変更内容（新機能、バグ修正など）を読み取り、バージョニングポリシーに基づいてバージョンを提案します。開発者はokと入力するだけで承認でき、必要であればパッチやマイナーと入力して上書きすることも可能です。この「人間による最終確認」のステップが、完全自動化にはない柔軟性と安心感をもたらします。

ステップ4: バックデート付きタグ作成

リリース日を過去の日付に設定するため、GIT_COMMITTER_DATE環境変数を使ってgit tagコマンドを実行します。これにより、タグの作成日を過去の日付に設定できます。

GIT_COMMITTER_DATE="2025-05-01T23:59:00Z" git tag -a v0.38.0 <commit_hash> -m "v0.38.0"

ステップ5: GitHub Release作成

最後にgh release createでリリースを作成します。GitHubのUI上で表示されるPublished日付は変更できないため、リリースノートの本文冒頭に Originally released: YYYY-MM-DD という一文を追記することで、本来のリリース日を明記しています。

gh release create v0.38.0 --title "v0.38.0" --notes "Originally released: 2025-05-01
 
## What's Changed
* Feature A by @user1 in https://github.com/org/repo/pull/123
* Fix B by @user2 in https://github.com/org/repo/pull/124
 
**Full Changelog**: https://github.com/org/repo/compare/v0.37.0...v0.38.0"

カスタマイズのポイント

このワークフローは、プロジェクトの特性に合わせて柔軟にカスタマイズできます。

バージョニングポリシーの調整: Claudeへのプロンプトにプロジェクト固有のルール（例:「フィーチャーフラグ付きの新機能はパッチアップデートとする」）を伝えることで、判定精度を向上させられます。
エラー時のリカバリ: もし間違ったバージョンでリリースを作成してしまっても、以下のコマンドで簡単にロールバックできます。
```
# リモートのリリースとタグを削除
gh release delete v0.12.0 --yes
git push origin --delete v0.12.0
# ローカルのタグを削除
git tag -d v0.12.0
```
その後、正しいバージョンで再作成すれば問題ありません。

導入のメリットと成果

このワークフローを導入したことで、以下のメリットが得られました。

一貫性: 全てのリリースノートが統一されたフォーマットで記述され、可読性が向上しました。
効率性: 1日分のリリース作成が、確認作業を含めても約30秒で完了します。
正確性: PR番号、タイトル、作者といった情報が自動で正確に取得され、手作業によるミスがなくなりました。
柔軟性: Claudeの提案を元に、最終的な判断は人間が下せるため、機械的な判断ミスを防げます。

結果として、v0.7.0からv0.38.0まで、約7ヶ月分の溜まっていたリリースノートを、わずか数時間で作成することができました。

実例 Giselle Release

まとめ

リリースノートの整備は、健全なプロジェクト運営に不可欠です。Claude Codeと各種CLIツールを組み合わせることで、面倒で後回しにされがちなこの作業を、効率的かつ正確に行う仕組みを構築できました。過去の技術的負債を解消しただけでなく、今後はこのワークフローを活用して、継続的に質の高いリリースノートを作成していく体制が整いました。

同様の課題を抱えている開発者の方にとって、本記事が少しでも参考になれば幸いです。

以上、Giselle ReleasesをClaude Codeでバックデートした、現場からお送りしました。