プロダクトの更新履歴
ユーザーが読んで理解でき、今回の更新が自分にとって何を意味するか分かる
次の変更リストから更新履歴を書いてください。読者はすでにプロダクトを使っている一般ユーザーです。構成：1）今回の更新で最も注目すべき変化を一文で；2）「新機能／改善／修正」に分け、各項目に「何が変わったか＋あなたにとって何を意味するか」を書く。社内用語は使わない；3）ユーザー自身がやる必要のあること（再ログイン、設定変更など）を別に列挙する；4）既知の問題。「ユーザー体験を最適化しました」のような中身のない表現は書かないこと。 ［変更リストを貼り付けてください］
使い方
書き終えたら「あなたにとって何を意味するか」の欄を隠して読み返しましょう。通じなければ、まだ内側の視点で書いています。
向いている場面
- 今回のリリースには20件以上のコミットがあり、うち3件はユーザーの操作の仕方を変えます。公開前にそこを明確にしたいところです。
- サポートがこの更新履歴を読んで回答します。曖昧だと、担当者が自分で理由を作ってユーザーに伝えてしまいます。
向いていない場面
- 社内の技術振り返りです（エンジニア向け）。コミット参照と設計上のトレードオフが必要で、ユーザー視点の履歴はそれを消してしまいます。
- 価格や規約の変更を含むリリースです。更新履歴で扱える話ではないので、別途の通知と同意の手続きが要ります。
例
入力
fix: CSV出力の文字化け修正 / feat: スマホからアイコン変更 / breaking: ログイン有効期限を30日から7日へ
得られるもの
冒頭で「7日以上開いていないと再ログインが必要」と伝えます。新機能／改善／修正に分け、各項目に影響を一文添えます（「PCに戻らずスマホでアイコンを変えられる」）。「あなたがやること」を別枠で示し、「体験を最適化しました」のような空文は書きません。
よくある誤用
- コミット一覧をそのまま貼ることです。「refactor: useAuth hook を抽出」はユーザーに通じない文になるか、無理に褒め言葉に変換されます。
- 変更だけを書き、影響を書かないことです。有効期限が変わったことは伝わりますが、明日ログアウトされることが伝わらず、翌日に問い合わせが来ます。
こう変えると効く
- 「新機能／改善／修正に分ける」を「重要な3件だけ」に変えます。ドキュメントではなくアプリ内のモーダルに出すときに向いています。
- 「各項目に、何もしないとどうなるかを一言添える」を足します。設定や権限に触れるリリースのときに使えます。