🤖

Terraform Provider for TROCCOのCHANGELOG更新をClaude Codeで自動化してみた

に公開
Terraform
automation
DevOps
changelog
Claude
tech

はじめに

この記事は、primeNumber AI Native Summer Calendarの記事です。 今回は、Claude Codeのslash command を活用して、Terraform Providerの開発における定型作業を自動化した事例をご紹介します。

TROCCOではETLやワークフロー機能などのデータ基盤を支援するSaaSとして提供していますが、 関連ツールとしてTROCCOの設定情報をTerraformで管理するためのTerraform Custom Provider として Terraform Provider for TROCCO をβ版として開発し、継続的な機能追加を行っています。

https://qiita.com/SoySoySoyB/items/c07ecf7bf199d5730bf2

しかし、従来の手動でのCHANGELOG.md更新作業は、Pull Requestの内容確認からバージョン番号の決定、 フォーマットに沿った記述まで、多くの手作業を伴う煩雑なプロセスでした。
この記事では、Claude Codeのslash command機能を活用して、この作業を自動化した取り組みについて紹介します。

実装したコマンドの詳細は、こちらのリポジトリで確認できます：

https://github.com/trocco-io/terraform-provider-trocco/blob/main/.claude/commands/update-changelog.md

※CHANGELOG自動化の初期フェーズではClineを利用していたため、 .clinerules/workflows で運用していましたが、 開発チームでのClaude Code採用に伴い .claude/commands に移行しました。

従来の運用フロー

TROCCO Terraform Providerでは、週次でのリリースサイクルを目指しています。 従来の運用フローは以下のような手順で進められていました。

週次リリース作業の詳細

  1. Pull Requestの調査と分析
    前週にマージされた全PRの変更内容（新機能、バグ修正、破壊的変更など）を確認し、影響範囲を把握します。

  2. バージョン番号の決定
    PR(Pull Request)の内容を基に、開発段階の0.x.y形式でバージョン番号を決定します。新機能追加や破壊的変更であればマイナーバージョンアップ（0.15.x → 0.16.0）、
    バグ修正や軽微な改善であればパッチバージョンアップ（0.15.2 → 0.15.3）という判断を人力で行っていました。

  3. CHANGELOG.mdの手動更新
    決定したバージョン情報と各PRの内容を整理し、既存のフォーマットに合わせてCHANGELOG.mdファイルを更新します。
    この作業では、技術的な変更内容をユーザーにとって分かりやすい表現に変換することも重要でした。

  4. チームレビューとマージ
    作成したCHANGELOG.mdの更新内容についてチームメンバーからレビューを受け、承認後にメインブランチにマージします。

  5. リリースタグの発行
    マージ完了後、GitHub上でrelease notesを作成し、対応するバージョンタグを発行します。
    このタグ発行をトリガーとして、Terraform Registry（Terraformモジュールの公式リポジトリ）への自動リリースプロセスが開始される仕組みになっています。

この一連の作業は、PRの数やボリュームにもよりますが、毎週約1時間程度の工数を要していました。

Claude Code slash commandによる自動化

従来の手動作業の課題を解決するため、Claude Codeのslash command機能を活用した/update-changelogコマンドを実装しました。

/update-changelogコマンドの機能

このコマンドは以下の処理を自動化しています：

  • Git履歴の自動解析: 前回のリリースタグから現在までのコードdiff (latest_tag...main) を自動的に解析
  • 変更内容の分類: 各PRの内容を解析し、機能追加・バグ修正・破壊的変更などに自動分類
  • バージョン番号の自動決定: 開発段階における0.x.y形式のルールに基づいて適切なバージョン番号を算出
  • CHANGELOG形式での出力: 既存のCHANGELOG.mdのフォーマットに準拠した形式で変更履歴を生成

新しい運用フロー

Claude Code導入後の運用プロセスは大幅に簡素化されました：

  1. コマンド実行
    claude code /update-changelog を実行するだけで、CHANGELOG.mdが自動更新されます。

  2. 内容確認とコミット
    作業者が生成されたCHANGELOG.mdの内容を確認し、問題がなければcommitを実行します。公開リポジトリのため、pushは次のレビュー工程後に行います。

  3. チームレビュー
    従来通り、チームメンバーからのレビューを受けます。ただし、フォーマットや内容の整合性については既に自動化されているため、レビューの焦点はより本質的な内容に絞られます。

  4. マージとリリース
    承認後のマージとリリースタグ発行プロセスは従来と同様です。

この自動化により、週次リリース作業の工数は従来の1時間から約15分程度まで大幅に短縮されました。
さらに、Claude Codeがバックグラウンドで作業を進めている間、作業者は他のタスクに集中できるため、実質的な効率化効果はそれ以上です。

導入効果と実感

/update-changelog コマンドの導入により、期待以上の効果を実感しています。

具体的な改善効果

作業時間の大幅短縮
週次リリース作業が1時間から15分程度に短縮されました。これにより、開発メンバーはより本質的な開発作業に集中できるようになりました。

バージョン決定の自動化
0.x.y形式のバージョン決定が自動化され、人的ミスや議論が不要になりました。具体的には以下のロジックで処理されています：

  • Major Version (0): 開発段階では0で固定
  • Minor Version: 新機能追加、API変更、後方互換性に影響する変更の場合にインクリメント
  • Patch Version: バグ修正、非破壊的な改善、ドキュメント更新、内部変更の場合にインクリメント

複数のPRが混在する場合でも、最も影響の大きい変更に基づいて一貫したロジックで判定されるため、信頼性が向上しています。

例えば、バグ修正とドキュメント更新のみの週であれば 0.15.2 → 0.15.3 のパッチバージョンアップ、新機能追加や破壊的変更が含まれる週であれば 0.15.2 → 0.16.0 のマイナーバージョンアップが自動的に選択されます。

フォーマット統一の徹底
過去のCHANGELOG.mdのフォーマットを学習し、一貫した形式で出力されることで、ドキュメントの品質が安定しました。手動作業では避けられなかった記述の揺れや形式の不統一が解消され、ユーザーにとって読みやすいCHANGELOGを維持できています。

残された課題と今後の展望

自動化により大きな改善を実現した一方で、運用を通じて新たな課題も見えてきました。

現在直面している課題

大量の変更への対応
週次リリースの中で特に多くのPRがマージされた場合、コードの変更diffが非常に大きくなることがあります。
これにより、Claude Codeのコンテキストウィンドウ（一度に処理可能な情報量）の制限で全ての変更を一度に処理できない場合や、情報量の多さから変更の分類精度が低下する問題が発生しています。

この問題に対しては、Conventional Commits（後述）など Claude Codeが理解できる形で情報を精査する仕組みを作る必要があります。

一方で、diffが大きくなりすぎる根本的な原因として、PRの粒度が適切でない場合もあります。
機能追加や変更を適切な単位で分割し、レビューしやすい粒度でPRを作成することで、自動化ツールの処理精度向上と人間によるレビューの質の両方を向上させることができると考えています。

分類精度の課題
現在のカテゴリ分け（FEATURES、CHORE、BUG FIXESなど）は、PRのdiffから自動判定していますが、時として人間の判断と異なる分類が行われることがあります。

例えば、GitHub Actionsのタスク追加のようなCI/CD改善は本来CHOREに分類されるべきですが、FEATURESに誤分類されることがありました。

このように、Terraform Provider本体の機能とは関係ない開発環境の改善が、プロバイダーの新機能として扱われてしまうケースがありました。
この改善も、Conventional CommitsやCIに関する専用のGitHub labelを付けるなどの方法が考えられそうです。

今後の改善計画

分類精度の向上
現在のカテゴリ分類をより適切に行うため、開発メンバーと共に適切な分類カテゴリの策定を検討中です。加えて、Conventional Commitsのような標準化されたコミットメッセージ規約の導入も検討しています。

Conventional Commitsは、コミットメッセージに構造化された規約を設けることで、変更の種類を明確に示す仕組みです。例えば：

  • feat: add data source for trocco_bigquery_connection → FEATURES（新機能）
  • fix: correct validation for connection parameters → BUG FIXES（バグ修正）
  • chore: update GitHub Actions workflow → CHORE（開発環境の改善）

このような規約を導入することで、以下の効果が期待できます：

  1. 自動分類の精度向上: 接頭辞による明確な判定が可能になり、誤分類が大幅に減少
  2. 開発者間の認識統一: チーム全体で変更内容の分類基準が明確化
  3. CHANGELOG生成の品質向上: より正確で一貫性のある変更履歴の自動生成
  4. セマンティックバージョニングとの親和性: バージョン番号の自動決定ロジックとの相性も良好

実装アイデアとしては、Claude Codeの/update-changelogコマンドがコミットメッセージの接頭辞を解析することで、現在よりも格段に精度の高い自動分類が実現できると考えています。

AI活用のさらなる展開
AI活用の一環として、本体コード実装やレビューの自動化に加え、カオステスト（システムに意図的に障害を発生させて耐性を検証する手法）による既存バグの発見を模索しています。

まとめ

Claude Codeの/update-changelogコマンドにより、TROCCO Terraform Providerの週次リリース作業が1時間から15分程度まで大幅に短縮されました。
バージョン決定の自動化とフォーマット統一により、開発チームはより本質的な作業に集中できるようになっています。

今回のCHANGELOG自動化は一例に過ぎませんが、AIツールを他の開発プロセスにも組み込むことで、より本質的な課題解決に集中できそうです。
Terraform Provider for TROCCO については今後も開発を効率化し、より使いやすいTROCCOインフラの管理ツールの実現を目指していきます。

AI支援ツールを活用した開発プロセス改善の一例として参考になれば幸いです。

Discussion