【ITニュース解説】Finally, Release Notes That Don't Suck: Automating with LLMs and GitHub Actions

ソフトウェア開発において、新しい機能や修正点をユーザーに伝えるリリースノートの作成は欠かせない工程だ。しかし、この作業は開発者にとって大きな負担となることが多い。手作業でリリースノートを作成する場合、過去の変更履歴を一つ一つ確認し、それぞれの変更内容や意図を把握する必要がある。これには多大な時間と労力がかかり、単調でミスも起こりやすい。特に個人開発者にとっては、管理作業に時間を割くことが、本来の機能開発時間を奪う大きな負担となる。

このような状況を改善するため、大規模言語モデル（LLM）の活用が試みられた。最初のシンプルなアプローチは、GitのコミットメッセージをそのままLLMに与えて要約させるというものだった。LLMはテキストの要約に長けているため、この方法で質の高いリリースノートが生成されると期待された。しかし、結果は期待外れだった。生成されたリリースノートは汎用的な内容に留まるか、コミットメッセージを言い換えただけの冗長な文章になりがちだった。また、「レイアウトを修正」のような簡潔なコミットメッセージでは、LLMはどのレイアウトがどのように修正されたのか、ユーザーにとって重要な背景情報を理解できなかった。さらに、開発者向けの内部的な変更と、ユーザーに影響のある変更の区別もつかなかった。これは、LLMが、リリースノート作成に不可欠な「なぜその変更が行われたのか」という文脈情報を持っていなかったことが原因だった。

この失敗から、LLMに単に生のコミットメッセージを与えるだけでは不十分であり、より構造化された意味のあるデータ、つまり変更の背景にある「なぜ」という情報を提供することの重要性が明らかになった。そこで、課題管理システムであるJiraの情報を統合することで、この問題を解決する新しいパイプラインが構築された。

この自動化されたパイプラインは、以下の四つの主要なステップで構成されている。

まず、リリース対象となる期間のGitコミットメッセージを取得し、そこからJiraのチケットIDを抽出する。多くの開発プロジェクトでは、「Conventional Commits」という規約に従ってコミットメッセージを作成する。例えば、「feat: PROJECT-123 ユーザープロファイルを追加」のように、変更の種類、関連するJiraチケットID、そして具体的な内容を記述する。この規約を利用することで、Gitのログから前回のリリースから現在までのコミットメッセージを簡単に取得でき、さらに正規表現というパターンマッチングの手法を使って、コミットメッセージに含まれる「PROJECT-123」のようなJiraのチケットIDを効率的に抽出できる。これにより、今回のリリースに関連するJiraチケットのユニークなリストが手に入る。

次に、抽出した各JiraチケットIDを使って、JiraのAPI（Application Programming Interface）にアクセスし、そのチケットの詳細情報を取得する。APIはプログラムが外部サービスと通信するためのインターフェースのようなもので、Jira APIを使うことで、チケットのサマリー（概要）、タイプ（バグ、ストーリー、タスクなど）、現在のステータスといった重要な情報を自動的に取得できる。これらの情報は、それぞれの変更が何であり、なぜ行われたのかという、LLMがリリースノートを生成する上で必要とする具体的な文脈を提供する。GitHub Actionsという、GitHub上で自動化されたタスクを実行する機能内でJira APIを呼び出す際には、認証情報（JiraのAPIトークンなど）を安全に扱うため、GitHubの「シークレット」という機能で秘匿情報を管理する。

三番目のステップが、LLMに与えるプロンプトの作成とリリースノートの生成だ。この段階では、取得したGitのコミットメッセージとJiraの詳細情報を組み合わせて、LLMが理解しやすい形式で入力データを作成する。例えば、「最近のGitコミットメッセージはこれらです」としてコミットのリストを示し、「関連するJiraチケットの詳細はこれらです」として各チケットのID、タイプ、概要を示す。そして、「簡潔で、ユーザー向けのリリースノートを3〜5つの箇条書きで生成してください。新機能、バグ修正、パフォーマンス改善に焦点を当て、内部的な変更は含めないでください。類似する項目はグループ化してください」といった具体的な指示（プロンプト）をLLMに与える。これにより、LLMは単なるコミットメッセージの羅列ではなく、Jiraチケットから得られた文脈を活用し、ユーザーにとって分かりやすく、かつ正確なリリースノートを生成できる。OpenAIのgpt-3.5-turbo-16kのようなモデルが、処理能力とコストのバランスが良く、多くの情報量を扱えるためこの用途に適している。

最後のステップは、これら一連のプロセスをGitHub Actionsで自動化することだ。上記のステップ1から3を実行するPythonスクリプトを作成し、そのスクリプトをGitHub Actionsのワークフローに組み込む。ワークフローは、一連の自動化されたタスクのことで、特定のアクション（例えば、新しいタグがGitリポジトリにプッシュされた時や、開発者が手動で実行を指示した時）をトリガーとして起動するように設定できる。このワークフローは、まずリポジトリのコードをチェックアウトし、Python環境をセットアップし、必要なライブラリをインストールする。その後、Pythonスクリプトを実行し、生成されたリリースノートをファイルに出力するとともに、GitHub Actionsの出力としても提供する。この出力は、続けて実行される他のステップ（例えば、生成されたノートを使ってGitHubのリリースドラフトを自動的に作成するアクション）で利用できる。これにより、開発者が新しいバージョンを示すタグをプッシュするだけで、GitHub上にユーザー向けの適切なリリースノートが自動的に記載されたドラフトが作成されるようになる。

この自動化された仕組みを一度構築してしまえば、リリースノート作成にかかる時間と労力は劇的に削減される。手動での作業で生じるエラーのリスクも減少し、常に一貫性のある高品質なリリースノートを生成できるようになる。これは、開発者が管理作業に煩わされることなく、本当に価値のある「ものづくり」に集中できる環境をもたらす。最終的には、開発の効率が向上し、ユーザーはより明確で役立つ情報を受け取れるようになるという、双方にとって大きなメリットが生まれる。初期設定には手間や学習が必要だが、その投資は長期的に見れば大きな利益をもたらすことが期待される。