17
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

GitHub Issues からリリースノートをAIで自動生成する方法

17
Posted at

これまで、Exploratoryのリリースノートの作成には 毎回30〜60分 ほど(多いときには数時間)かかっていたのですが、最近AI 関数を使った自動化の仕組みにしたことで、今では数分で終わるようになりました。

もともと、新しいバージョンをリリースするたびに、このバージョンで入ったGitHubに登録されている全てのIssueを確認し、

  • バグ修正
  • 機能強化
  • 新機能
  • ドキュメント

などといったグループに分け、ユーザーにとって分かりやすい文章にしたリリースノートを作成していました。

しかし、この作業には意外と時間がかかってました。

というのも、それぞれのIssueに対して、

  1. そのタイトルと内容を読む
  2. Issueのタイプ(バグ修正 / 機能追加 / ドキュメント)に分類する
  3. 機能カテゴリ(データ加工、チャート、アナリティクス、ダッシュボード、など)に分類する
  4. ユーザーに分かりやすいタイトルに書き直す

といった作業が必要だったからです。

1回のリリースで 50〜100件の Issue がある場合、この作業にはけっこう時間がかかるものです

しかし、現在はこの作業はほぼ全て、ExploratoryのAI関数とAIノート・エディターを使って自動化しています。

今回は私たちが実際にどうやってこの自動化の仕組みを作ったのか、その方法を紹介したいと思います。

同じように テキストデータの処理を自動化したり、それを元に自動でレポートを生成したい方の参考になればと思います。


AI 関数とは?

ExploratoryのAI 関数とは、プロンプトを書くだけで AI(LLM)を使った処理をデータの各行に適用できる機能です。

image.png

例えば次のような処理ができます。

  • テキスト分析
  • 分類
  • 要約
  • テキスト生成
  • データ変換

例えば顧客コメントのデータがあれば、

この文章をいくつかのカテゴリに分類してください

と書くだけで、AIが各行を分類してくれます。

image.png

AI 関数 の詳細はこちらの記事をご覧ください。

https://blog.exploratory.io/data-science-2-0-a-new-era-of-text-data-analysis-b6430baadba7

私自身、この AI 関数をほぼ毎日使っています。というのも、普段の仕事には、「思っていた以上に多くのテキストデータが存在している」からです。

例えば、

  • Issueログ
  • 顧客フィードバック
  • ミーティングメモ
  • サポート問い合わせ
  • タスク管理

などです。

これらはとても価値のあるデータですが、 適切なツールがないと分析や自動化が難しいのが現実です。

しかし、AI 関数が使えるようになったことで、そういったデータを活用し毎日の仕事の生産性を高めることができるようになりました。

今回はその中でも、私たちが定期的に行うGithubのIssueログデータを元にしたリリースノートの作成に、どのようにAI関数を使っているのかを紹介したいと思います。


リリースノート作成の自動化

Exploratory の開発では GitHub Issues を使ってタスクの管理をしています。

image.png

Issue には次のようなものがあります。

  • バグ(プロダクトの問題)
  • 既存機能の強化
  • 新機能
  • 内部タスク
  • 開発オペレーションの改善
  • ドキュメント更新

そして、Exploratoryの新バージョンのリリース時には、該当するマイルストーンのすでにクローズしたIssueを集め、それらを元にリリースノートを作成して公開します。

しかし Issue のタイトルは内部向けに書かれていることが多いため、そのままではリリースノートとして出せません。

そのため、次の処理を行うことになります。

  1. Issue を機能カテゴリに分類
  2. バグ修正か機能追加か、それとも新機能かを判定
  3. ユーザーにとって理解しやすいようなタイトルに編集する

以前はこれを手作業でやっていましたが、今はAI 関数を使ってほぼ自動化しています。

ここからは、具体的にどうやっているかの話をします。


Step1 GitHub Issuesのデータを取り込む

まず GitHub Issueのデータを ExploratoryのUI越しに取り込みます。GithubからIssueデータの取得についてはこちらをご参照ください。

そのさい、例えば「 14.5」といったように該当のマイルストーンを指定します。

image.png

その中からあとで必要となる列を選びます。次のような列があれば十分です。

  • Title
  • Body
  • Labels
  • Status
  • Milestone

image.png


Step2 機能カテゴリの分類

次に、各Issueを機能カテゴリごとに分類します。ここでAI 関数を使います。

AI関数には次のプロンプトを書くだけです。

’title'と'body'列のテキストを元に、それぞれのイシューを次のどれかのグループに分類してください。

AI 関数
AI プロンプト
サマリ・ビュー
テーブル・ビュー
データソース
データ加工
チャート
アナリティクス
ノート
ダッシュボード
パラメーター
プロジェクト
パブリッシュ
インストール
ドキュメント
その他

AIに自由にカテゴリーを作らせるのではなく、 事前に自分たちで定義したカテゴリのリストを指定することで安定した結果になります。

AIが適切に機能カテゴリを判定できるよう、各Issueの’title' と'body'の情報をAIに渡します。

image.png

'title'列と'body'列のテキストはGithubのIssueページでは以下のようになっています。

image.png

AI関数を実行すると、AIがそれぞれのIssueを分析し、適切なカテゴリを返してくれます。

image.png


Step3 Issueタイプを判定

次にIssueのタイプを判定します。タイプには以下のようなものがあります。

  • 問題の修正
  • 機能強化
  • 新機能
  • ドキュメント
  • その他

これも先ほどといっしょで、事前に自分たちで定義しているタイプがあるので、それらを以下のようにプロンプトに指定します。

各イシューを次のうちのどれかに分類してください

- 問題の修正
- 機能強化
- 新機能
- ドキュメント
- その他

AI関数のUIは以下のようになります。

image.png

追加された列の値のサマリ情報を見ると、各Issueはそれぞれのグループに分類されているのが確認できます。

image.png


Step4 Issueタイトルを書き直す

GitHub Issue のタイトルは内部向けの短いタイトルで、さらに英語です。

例えば:

Number: Allow Partial Style Customization for Suffix/Prefix Text in Number Chart

これは直接日本語に直すと以下のようなものです。

ナンバー: 接頭辞・接尾辞テキストのスタイルの一部のカスタマイズできるようにする

しかし直接翻訳しただけでは、私たちExploratory内部の人間にとっては意味が通じますが、Exploratoryのユーザーの方にとっては分かりにくいものです。

そこで AI 関数を使ってユーザー向けの説明文に日本語で書き直します。

プロンプトは以下のようなものです。

'title'列と'body'列の情報を元に、問題であれば、過去形でユーザーにとって何が問題だったのか、機能強化に対しては、ユーザーがどのようなことができるようになったのかが、明確にわかるように、1行か2行に収まる要約として書いてください。

これについても、AIに'title'列と'body'列の両方のデータを元に判断するよう指定しています。

image.png

その結果は例えば、以下のようなものです。

オリジナル:

ナンバー: 接頭辞・接尾辞テキストのスタイルの一部のカスタマイズできるようにする

修正後:

ナンバーチャートにおいて、接頭辞や接尾辞の文字サイズや色を個別にカスタマイズできるようになりました。

だいぶわかりやすいものに、さらに日本語に翻訳されています。

これがすべてのIssue に対して自動で実行されます。

image.png

ここまでのステップで、AI関数を使って

  • 機能カテゴリ
  • Issueタイプ
  • 改善された説明

のデータが揃ったので、以下のように集計テーブルを使ってグループごとに見ることができます。

image.png


AI ノートエディターでリリースノートを生成

必要なデータが揃ったので、あとは最終的なリリースノートを生成するだけです。

そして、これもExploratoryの中で「AI ノートエディター」を使って自動化しています。

先ほど作った集計テーブルをノートに落とし、AI ノートエディターの「カスタムプロンプト」機能を使います。

image.png

以下のような比較的シンプルなプロンプトを使っています。

提供されたデータを元にリリースノートを生成してください。

- 'Type of Issues'(例:機能強化、問題の修正)ごとにH2ヘッダーを作る。
- 各イシューを'category'ごとにまとめ、要約されたタイトルをそのまま使い、カテゴリごとに並べてリストする。

以下は例です。

## 機能強化

### ダッシュボード

* ダッシュボード全体の背景色やチャートのボーダーの色を自由に変更できるようになりました。
* 日本語UI使用時に、PDF印刷ダイアログも日本語で表示されるようになりました。

### チャート

* Y軸メニューのマーカー設定にショートカットメニューが追加されました。
* エリアチャートを色で分割した際、値を積み上げずに0から開始して可視化できるようになりました。
* 表示するデータがない場合、エクスポートボタンが無効化されるようになりました。

すると、AIがプロンプトの指示に従って、表からリリースノートの形式に変換してくれます。

image.png

AIノートエディターの詳細については、こちらのブログ記事をご参照ください。

Exploratoryのノートは見かけは普通のテキストエディターですが、中身はマークダウンです。そのため、全ての文字列をコピペして、私たちが持っているリリースノートを管理しているドキュメントシステムにマークダウンとして貼り付けると、後は自動でコミットが入り、プロダクションにシンクされます。

image.png


再現性(Reproducibility)

こうして、Exploratoryの中でAI関数とAIノートエディターを使って、リリースノートを作成るワークフローを自動化したわけですが、その最大のメリットは 再現性です。

今回は省きましたが、AI関数での処理の前に必要のないIssueを除いたり、余計な文字列を削除したりと言ったデータ加工も行っています。

そうした処理も含め、AI 関数を使った「データ加工」のワークフローを一度作ってしまえば、 次回のリリースでも同じ処理を再現することができます。

やることは

  1. データソースのダイアログを開いて、マイルストーンを指定
  2. 再インポートのボタンをクリック
  3. データ加工の再実行のボタンをクリック

これだけです。

あとは、同じデータ加工のワークフローが、新しいデータに対して自動で適用されます。

image.png

毎回手作業でプロンプトを書く必要もなければ、書き直す必要もありません。


ChatGPTにコピペすればよいのでは?

ここで疑問が出るかもしれません。

「IssueをChatGPTやClaudeに貼れば同じことができるのでは?」

確かにできます。

私たちも元々は、ClaudeのAPIを使って自動生成する仕組みを作っていました。

しかし実際の運用では問題がありました。出力結果が思ったように落ち着かないことがよくあり、そのたびに手元のClaude環境で検証、改善を繰り返し、それをシステムに反映させるということを行っていました。実はこれが毎回めんどくさい作業となっていました。

この記事で紹介したAI 関数の強みは AIがデータ加工のワークフローの一部になることです。これによって以下のようなメリットがあります。

1. 視覚的、反復的に改善のループを回せる

ChatGPTなどを使ってる人は経験があると思いますが、最初からいきなり自分が欲しい結果を得られるわけではありません。そのためには、何回も対話し、そのたびにうまくいってるかどうかを検証し、反復的に改善していくことが必要となります。

  • プロンプトを書いて実行
  • 結果を表(テーブル)やチャートを使って検証
  • プロンプトを修正し、再実行

そして、実行するたびにチャートや集計テーブルなどを使って、その結果を視覚的に素早く確認し、検証できることが重要です。

image.png

AI 関数が通常のデータ加工作業のプロセスの一部となっていることで、反復的に改善しやすくなります。

2. 出力をコントロールできる

ExploratoryのAI関数であれば、例えば100行あったら、100行に対する結果として出力させることができるため、各行に対してうまくいってるかどうかを確認しやすいです。

ここに関しては、確実に答えが帰ってきてもらわないと困ります。途中からいい加減な答えになっていたり、一部のデータが結果に含まれていなかったり、というのは困ります。

3. 統合されたデータ加工のワークフロー

他の処理と合わせたデータ加工のワークフローを作っていくことができます。今回は触れませんでした、実はAI関数を使う前の前処理として、いくつかのデータ加工処理を行っています。例えば、リリースノートには入れる必要のないIssueを除いたり、AIにそのまま渡すと混乱させてしまう文字列を除いたり、といったことをしています。

こうしたデータの加工処理を行ったうえで、AIにわたすべきデータを整理しておくことで、AIによる出力のクオリティをよりコントロールしやすくなります。

image.png

4. 結果のクオリティを改善しやすい

上記の例でも合ったように、私達は、最後のAIノートエディターを使ったリリースノートを生成する段階では、各Issueのタイトルテキスト自体に対しては余計な編集をさせていません。

このようにデータの加工処理(AI関数)とリリースノートのフォーマットの生成(AI ノートエディター)を切り離すことで、最終的な成果物のクオリティを改善、そして管理しやすくなります。

このような理由で現在はAI関数とAIノートエディターを使った運用に切り替えています。


まとめ

ここまで読んでいただきありがとうございます。

今回の例は、Exploratory のリリースノート作成の自動化でしたが、 本質はもっと大きな話です。

実は、多くの仕事の中には 大量のテキストデータ が存在しています。

例えば:

  • GitHub Issues
  • サポート問い合わせ
  • 顧客コメント
  • ミーティングメモ
  • タスク管理

これらはこれまで、 人が読んで手作業で処理するしかありませんでした。

しかし、今回見てきたように **AI **関数を使うことで、

  • 分類
  • 要約
  • 変換
  • 構造化

といった処理ができるようになり、さらにそれを データワークフローとして自動化することができます。

その結果、これまで手作業で行っていた多くの作業が自動化され、 より価値の高い業務に時間を使えるようになります。

しかし、重要なのはそれだけではありません。

テキストデータを「使えるデータ」に変えるコストがほぼゼロになることで、 これまで活用されてこなかったデータが、日常的に蓄積されていきます。

そして、そのデータを使うことで、

  • より良い意思決定ができるようになる
  • より正確に現状を把握できるようになる
  • 顧客に対してより適切な対応ができるようになる

といった変化が生まれます。

これまで「データを活用したいが、使えるデータが限られている」と感じていた方も多いと思います。

しかし AI 関数を使うことで、 これまで扱えなかったテキストデータが、新たなデータ資産として加わるようになります。

そして一度この視点を持つと、

これは自動化できるのでは? このテキストもデータとして使えるのでは?

と、日々の仕事の中に新しい可能性が見えてきます。

それこそが、AI 関数の本当の価値だと考えています。


AI 関数 を試してみる

もし次のようなデータを扱っているなら

  • Issueログ
  • サポートチケット
  • 顧客フィードバック
  • アンケートデータ(自由記述)
  • 名寄せが必要な文字列データ
  • 住所

ぜひ、AI 関数を試してみてください。

初めて使う場合、プロンプトに何を書けばいいかわからない、と言ったこともあるかと思います。その場合は、AI 関数のメニューにあるサンプルから簡単に始めることができます!

image.png

AI 関数 は Exploratory の最新バージョンで利用できます。

https://exploratory.io/download

まだアカウントを持っていない方は こちらから無料トライアルできます。

https://exploratory.io


以上となります。

最後まで読んでいただきありがとうございます!

西田 勘一郎

CEO / Exploratory

17
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
17
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?