ガイド
ChatGPT や Claude でリリースノートを書く方法
ChatGPT や Claude は、作った人ではなく使う人に向けて書かせれば、マージした変更の一覧を、利用者が読むリリースノートにできます。マージした変更のタイトルかチケットの要約を貼り、新機能・改善・修正の 3 つに分けた利用者向けの文を頼み、どの行も利用者にできるようになったことから、プロダクトの画面やボタンの名前で、短く書かせます。修正は利用者が見た症状で書き、内部の作り直し、依存関係の更新、テストのような見えない変更は、チケット番号つきの社内の変更履歴だけに入れます。チケットからわからないことは推測させず、確認の印をつけさせます。
要点
- 新機能・改善・修正。利用者に見えないものは入れない。
- どの行も利用者にできることから。
- 修正は原因ではなく症状で。
- 残りは社内の変更履歴へ、チケット番号つきで。
そのまま使える頼み方
リリースノートの頼み方
「[日付] にリリースする [版] のリリースノートを書いてください。
利用者向け:利用者に見えないもの(内部の作り直し、依存関係の更新、テスト、CI、ログ)は外す。残りを、新機能(前はできなかった)、改善(速く、わかりやすく、広く)、修正(壊れていて、直った)に分ける。1 行に 1 つ、50 字以内で、利用者にできるようになったことから、画面とボタンの名前で書く。修正は利用者が気づいた症状で書く。グループの中ではよく使われる変更を先に。利用者にとって 1 つの変更なら、チケットが複数でも 1 行にまとめる。
社内の変更履歴:Keep a Changelog の種類(Added、Changed、Deprecated、Removed、Fixed、Security)で、チケット番号つき。見えない作業は「Internal」に。動きが変わるものは、サポート向けに 1 行。チケットがわかりにくければ Internal に入れて [確認:利用者にとって何が変わった?] とつける。
マージした変更:[貼る]」
例
架空の例です。美容室向けの予約アプリが、11 月 10 日に 4.8 を出します。チケットは 6 つです。BK-311 予約の画面で毎週のくり返し予約。BK-322 予約を変えるとリマインダーの SMS が 2 回届く。BK-325 フロントエンドのフレームワークの更新。BK-327 お客さまの検索を作り直し、ふだんの応答が 1.8 秒から 0.4 秒に。BK-330 支払いの失敗のログを増やす。BK-333「オンボーディングを調整」。リリースノート:
4.8 の新しいところ
新機能:予約の画面から、選んだ日まで毎週同じ予約をくり返せます。
改善:お客さまの画面での検索が 4 倍以上速くなりました。
修正:予約を変えたあと、お客さまにリマインダーの SMS が 2 回届かなくなりました。
社内向け(4.8.0、2026-11-10):Added:毎週のくり返し予約(BK-311)。Changed:お客さまの検索を作り直し(BK-327)。Fixed:予約の変更でリマインダーの SMS が重複(BK-322)。Internal:フレームワークの更新(BK-325)、支払いの失敗のログ(BK-330)、オンボーディングの変更(BK-333)[確認:利用者にとって何が変わった?]。サポート向け:今日より前に変えた予約では、すでに 2 回送られている場合がある。
プロダクトマネージャーが BK-333 を確かめると、オンボーディングの手順が 1 つ移っていました。ヘルプセンターの画面写真を直してから、次のリリースノートに 1 行入れます。
チームに残ること
- どの行もチケットと照らす。AI はチケットに書いてあることしか知らない。
- 画面に出る名前を使う。コードの名前は使わない。
- 利用者が出会わなかった不具合の修正は載せない。
- 設定の要る新機能にはヘルプ記事のリンクを。
- 動きが変わるものは、先にサポートへ伝える。
次の一歩:頼み方を毎回貼らない
リリースは 1〜2 週ごとに来るので、頼み方はチーム全員が見つけられる場所に置きます。ChatGPT のプロンプトを保存して毎回貼るのをやめるで、保存する場所を紹介しています。
このテーマに使えるスキル
- プロダクトマージ済みの変更からリリースノートマージ済みの PR やチケットから、新機能・改善・修正に分けて利点から書く顧客向けリリースノートと、社内用の変更履歴を書く。
- カスタマーサクセスサポートチケットからバグ報告を書く顧客の不満を、再現手順、期待する動作と実際の動作、環境、影響、証拠、顧客への質問がそろった、開発がすぐ着手できるバグ報告にする。
- プロダクト受け入れ条件つきのユーザーストーリー機能をユーザーストーリーに分け、Given/When/Then の受け入れ条件、エッジケース、対象外のメモ、ストーリーごとの INVEST のチェックをつける。
- 業務管理・総務社内の変更のお知らせ社内の変更を知らせるメールや Slack の投稿を、結論を先に、変わること、理由、時期、対象者、やること、窓口の順に書く。
よくある質問
AI でリリースノートは書ける?
変更の一覧から書けます。マージした変更のタイトルかチケットの要約を貼り、新機能・改善・修正の 3 つに分けた利用者向けの文と、別の社内の変更履歴を頼みます。どの行も利用者にできるようになったことから書かせ、チケットからわからないことは推測させずに確認の印をつけさせます。
リリースノートには何を書く?
利用者に見えることだけです。新しくできること、速く・わかりやすくなったこと、利用者が出会った不具合の修正を、画面やボタンの名前で書きます。内部の作り直し、依存関係の更新、テストは社内の変更履歴へ入れます。Keep a Changelog は、それを Added、Changed、Deprecated、Removed、Fixed、Security に分け、新しい版から日付つきで並べます。
不具合の修正はどう書く?
原因ではなく、利用者が気づいた症状で書きます。「予約を変えると、お客さまにリマインダーの SMS が 2 回届く問題を直しました」のように書き、「SMS ジョブの重複を修正」とは書きません。だれかのせいにしたり謝りすぎたりせず、利用者に届かなかった不具合の修正は載せません。
AI スキル
AI に、お客さまに読まれるリリースノートを書かせる
このスキルを AI Skill Pod に入れれば、チーム全員が自分の Claude、Cursor、ChatGPT(Pro・Business・Enterprise)で使えます。招待リンク 1 つで共有でき、無料で始められます。「マージ済みの変更からリリースノート」スキルで、AI がマージした変更から 2 つの記録を作ります。新機能・改善・修正に分け、どの行も利用者にできることから始まる利用者向けのリリースノートと、Keep a Changelog の種類で分け、チケット番号とサポートに伝えることを書いた社内の変更履歴です。
14日間無料・カード不要
出典
- Keep a Changelog 1.1.0(日本語版) — 変更履歴は人のためのもの。最新の版を先に、リリースの日付つきで。変更は Added、Changed、Deprecated、Removed、Fixed、Security に分ける (閲覧 2026-11-05)
- ProductPlan:Release notes best practices — 平易な言葉で、専門用語を入れず、短く (閲覧 2026-11-05)