あらゆる種類の変更に使えるリリースノートの例文集

優れたリリースノートの例は、短く、誰に影響するかを明示し、次に何をすればいいかを伝えている。以下では、公開することになる変更の種類ごとに一つずつ例を示し、それが機能する理由を添える。形をそのまま真似て、自分の事実に差し替えてほしい。

例はすべて架空のもので、Tidepoolという架空の請求書アプリを題材にしている。

良いリリースノートの例に共通するものは何か

読者の言葉で、何が変わったか、そして何かすべきことがあればそれは何かを伝えている。変更の種類ごとに役割が違うので、種類によって形も変わる。

良い新機能のノートはどんな見た目か

良い機能のノートは、読者が今できることから書き始め、それを使えるプランや役割を名指しする。実装の話は省く。

お客様の言語で請求書を送れるようになりました。 顧客ごとに言語を選べるようになり、その顧客宛ての請求書、督促、支払いページが選んだ言語に従います。フランス語、ドイツ語、スペイン語、ポルトガル語がすべてのプランで使えます。設定は、顧客のページの「請求設定」で行います。

見出しは読者が口に出して言いそうな言い回しで、本文が範囲と場所を伝えている。太字の行だけを流し読みした読者も、何がリリースされたかを把握できる。より広い方法論はリリースノートの書き方にある。

良い改善のノートはどんな見た目か

改善のノートは、読者が体感できる変化を述べ、測定した数字があればそれを添える。数字がなければ、読者がもうしなくてよくなったことを書く。

請求書一覧の読み込みが約3倍速くなりました。 請求書が5,000件を超えるアカウントでは、一覧の表示に約9秒かかっていました。現在は約3秒で開きます。対応は不要です。

「パフォーマンスの改善」では読者は何も分からないが、9秒が3秒になったという主張なら、月曜の朝に自分で確かめられる。末尾の「対応は不要です」は、すべての読者が抱く問いに答えている。

良いバグ修正のノートはどんな見た目か

バグ修正のノートは、コード上の原因ではなく、ユーザーが見た症状を書き、やり直しが必要かどうかを伝える。誰も気づかなかった修正は、末尾のリストに入れてよい。

修正:支払期日に督促メールが2通届く問題。 請求書の支払期日が月末だった場合、一部のお客様に同じ督促が2通届くことがありました。これは修正されました。すでに送信された督促には影響がなく、再送の必要もありません。

見出しを「修正」で始めておくと、流し読みする人がひと目で分類できる。そして本当の条件(月末)がすぐ後に続く。

破壊的変更のリリースノートはどう書くか

破壊的変更のノートは、日付と影響を受けるグループから始め、同じエントリの中で移行方法を示す。読者が見逃してはならない唯一のエントリなので、リリースノートの最初に置く。

2026年12月1日からWebhookの署名が必須になります。 この日以降、Tidepoolは署名のないWebhookペイロードを送信しなくなります。Tidepool-Signature ヘッダーを確認せずにWebhookを受信している方が対象です。移行するには、「設定」の「開発者」にあるシークレットを使ってヘッダーを検証してください。すでに署名を検証している場合は、対応不要です。

日付が見出しにあるので、流し読みしても残る。影響を受けるグループは、その人たちが何をしているかで指定され、最後の一文はすでに問題のない人を解放するので、サポートの負担が減る。変更が該当するかどうかの判断は、破壊的変更のガイドで扱っている。

セキュリティ修正のノートはどんな見た目か

セキュリティのノートは、何が露出したか、誰かが悪用したか、誰が影響を受けるか、何をしなければならないかを述べる。事実だけを、落ち着いて書く。

セキュリティ:パスワードリセットのリンクが再利用できた問題。 2026年9月3日から17日の間、パスワードリセットのリンクが、一度使用した後も有効なままでした。悪用された形跡は確認されていません。すでに修正済みで、未使用のリセットリンクもすべて無効化しました。この期間中にリセットを依頼した方は、新しいリンクを依頼してください。

正確な期間によって、読者は自分が影響を受けたかを判断でき、悪用についての一文は、誰もが最初に尋ねる問いに答える。「潜在的な問題」という書き方は隠蔽のように読めるので、分かっていることを述べる。

非推奨の通知はどう書くか

非推奨の通知は、何が削除されるのかを示し、確定した終了日を伝え、代替手段を指し示す。

v1の請求書エンドポイントは非推奨となり、2027年3月1日に終了します。 GET /v1/invoices は2027年3月1日まで動作し、その後は 410 Gone を返します。同じフィールドに currency を加えて返す GET /v2/invoices をご利用ください。v1からのレスポンスには、終了日を示す Sunset ヘッダーが付くようになりました。新旧を並べた移行ガイドはドキュメントにあります。

影響を受ける人はエンドポイント名で検索するので、名前は見出しに入れ、代替手段は削除の隣に置く。Sunset ヘッダーは、どの呼び出しがまだ古いバージョンを使っているかを開発者に教える。詳しい説明はAPIの非推奨化にある。

アプリストアのリリースノートはどんな見た目か

アプリストアのノートは、平易な二、三文にする。ほとんどの人は最初の一行しか読まないからだ。ユーザーが気づく変更から始める。

紙のレシートをスキャンすると、Tidepoolが金額、日付、取引先を入力します。ダークモードがスマートフォンの設定に従うようになりました。通知から請求書を開くとクラッシュする問題も修正しました。

最も役立つ変更が最初に来て、修正はクラッシュした状況を名指ししている。バージョン番号も、「バグ修正と改善」もない。ストア固有のルールはモバイルアプリのリリースノートで扱っている。

社内向けのリリースノートには何を含めるべきか

社内向けのノートは、サポートと営業のためのバージョンだ。公開ノートが省いたもの、つまり何と言うべきか、何を約束してはいけないかを加える。

多言語の請求書を本日リリースしました(全プラン)。 サポート:顧客は「請求設定」で言語を設定します。既存の請求書は元の言語のままです。イタリア語はまだありません。営業:全プランで使えるので、アップグレードの特典として売り込まないでください。

読者ごとにラベル付きの行があり、顧客が尋ねる前に境界線(「イタリア語はまだありません」)を引いている。形式とチャネルは社内向けリリースノートの記事で扱っている。

悪いリリースノートを書き直すとどうなるか

悪いリリースノートは、読者が得るものではなく、チームがしたことを並べている。成果を先頭に移し、社内の用語を削除して直す。

前:

v3.8.1 督促スケジューラをリファクタリング。ReminderJob の競合状態を修正。bull を4.12に更新。その他の改善。

後:

督促メールが2通届かなくなりました。 請求書の支払期日が月末のお客様に、督促が2通届くことがありました。これは修正されており、すでに送信された督促を再送する必要はありません。対応は不要です。

3.8.1ではさらに:bull を4.12に更新。

依存関係の更新は末尾の一行に下がり、競合状態は顧客が思い当たる症状になった。

リリースごとにリリースノートの一貫性を保つには

変更がマージされたときに各エントリの下書きを作り、リリース前に人が承認する。

Changeloopはこの方式で動く。マージされたプルリクエストごとにAIでエントリの下書きを作り、人が承認するまで保留する。承認のステップが、編集者が上のルールを適用する場面だ。先に形式を決めるなら、リリースノートのテンプレートから始めるといい。完成したページの見た目はチェンジログの例を参照してほしい。

FAQ

新しいリリースノートとは何か? 製品の最新リリースと一緒に公開されるメッセージで、何が変わったか、ユーザーが何をする必要があるかを説明する。機能、改善、修正、破壊的変更を扱う。

リリースノートとチェンジログの違いは何か? チェンジログはすべてを残し、完全な履歴を求める人のためにある。リリースノートはそこから選ぶ。一つのリリースについて、自分に関係があるかを判断する読者に向けて書く。詳しい比較はチェンジログとリリースノートの違いにある。

リリースノートとはどういう意味か? リリースで何が変わったかをユーザーに伝えるものだ。この言葉は、アプリストアの「新機能」のテキストから、会社のWebサイトのページまで、何がリリースされたかを説明するもの全般を指す。

リリースノートの各エントリはどのくらいの長さにすべきか? ほとんどのエントリは二〜四文で足りる。成果、誰が影響を受けるか、何をすべきかだ。破壊的変更やセキュリティ修正は、日付や移行方法が必要なので、もっと長くなることがある。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： リリースノートのテンプレート, changelogの例