リリースノートの実践

読まれるプロダクトアップデートメールのテンプレート

1分で読めます 更新

読まれるプロダクトアップデートメールとは、それがまさに求めていたことを告げるものとして、それを求めた本人に送られたものである。それ以外のすべては受信箱の残り全体と関心を奪い合う競争をしており、リリースの告知はほとんどの週でその競争に負ける。この一つの事実こそが、どんな文言よりも先に、メールの形を決めるべきだ。誰がそれを受け取るのか、そしてその人物がリストに載るために何をしたのか。

プロダクトアップデートメールとは何か

これは、既存のユーザーに対して、すでに使っている製品で何が変わったかを伝えるメッセージだ。四つの異なる種類があり、それらを一つのリストとして扱うことが、開封率が低下する理由である。それぞれ異なるトリガー、異なる読者層、異なる許容される頻度を持つ。

種類トリガー読者層頻度
ターゲット通知誰かの具体的な要求がリリースされた一人起きるたびに
破壊的変更の通知読者に作業を強いる変更影響を受けるアカウントのみ起きるたびに
ダイジェスト時間の経過オプトインしたユーザー最大でも月一回
ローンチの告知中断する価値のあるローンチセグメントまたは全員稀であり、稀に感じられるべき

多くのチームは三番目だけを構築し、全員に送り、そしてプロダクトアップデートメールは機能しないと結論づける。最初の二つがほとんどすべての価値を運んでいる。読者にはすでに関心を持つ先行する理由があり、メッセージはその理由がまだ生きているうちに届くからだ。

ここに並んだ四つの行はすべて顧客向けに書かれている。営業、サポート、カスタマーサクセスも何がリリースされたかを知る必要があり、それは通常この四つとは異なる形になる。社内向けリリースノートが、その文書が何を言うべきか、そしてなぜ顧客向けのノートより先に出なければならないかを扱っている。

メールは、ローンチの告知が使える複数のチャネルの一つに過ぎず、唯一のものではない。新機能の発表方法が他のチャネルと、機能の実際の大きさに応じてどう選ぶかを扱っている。

テンプレートには何が含まれるべきか

この順序で六つのブロックがある。最初のものは通常欠けているものであり、実際の仕事をこなすものだ。

件名:  <何が変わったか、読者の言葉で>

1. なぜこれを受け取っているのか
   「あなたは3月にCSVエクスポートを要求しました。」または
   「あなたの統合は1月15日に変更される /v1/invoices を呼び出しています。」

2. 何が変わったか
   一文で。今何が可能になったか、あるいは今何が壊れるか。

3. あなたが何をすべきか
   多くの場合「何もない」。暗黙のままにせず、明示的に述べること。

4. どこで見られるか
   ホームページではなく、チェンジログのエントリへのリンク。

5. いつ
   リリースされた日付、あるいはいつから適用されるか。

6. どう配信停止するか
   ワンクリックで、即座に尊重される。

ブロック1は、メッセージと一斉配信の違いを分けるものだ。最初の一文で、これは自分が個人的に求めたことの解決であると告げられた読者は、残りを読む。それがなければ、ブロック2から5は、どれほどよく書かれていてもニュースレターにすぎない。

全体を約150語以下に保つこと。メールはチェンジログのエントリへのポインタであり、詳細が属するのはそちらである。エントリ全体を再現するメールは、読者にクリックする理由を与えず、誰かが気にかけたかどうかのシグナルもあなたに与えない。

どんな件名が機能するか

リリースではなく変更を名指しすること。「CSVエクスポートがライブになりました」は「9月のアップデート」に勝る。前者は読者が評価できる事実であり、後者は入れ物にすぎないからだ。件名内のバージョン番号は、あるAPIの呼び出し側には有用だが、他のすべての人にとってはノイズであり、読者層を分ける別の理由である。

読者が同意していない利益を主張することは避けること。「あなたのレポートは今より速くなりました」は読者の体験について何かを主張している。「10,000行を超えるレポートは今、1秒未満で読み込まれます」は変更を報告し、それが重要かどうかを読者に判断させる。

いつ、誰に送るべきか

その物がリリースされた瞬間に、それを求めた人々に、個別にターゲット通知を送ること。日付が確定次第、そして再びその直前に、リスト全体ではなく実際に影響を受けるアカウントに破壊的変更の通知を送ること。読者がそうでなければ何かを見逃すほど十分な変更がある場合にのみダイジェストを送り、人々が別々に登録できるようにすること。

ほぼ絶対に使うべきでないリストは「全ユーザー」だ。それは具体的なメッセージを一般的なものに変え、配信停止を訓練してしまう。すでに保存している行動でセグメント化すること。誰がそれを求めたか、誰がこのエンドポイントを使っているか、誰がこのプランにいるか。

それを送るのに同意は必要か

既存の顧客にとって、すでに使っているサービスについてのアップデートは、通常、見込み客へのマーケティングとは異なる法的な問題であり、答えは彼らがどこにいるか、そして登録時に何を伝えたかに依存する。EUでは、関連する問いはGDPR第6条のどの法的根拠が適用されるかであり、米国では商業的メッセージはFTCのCAN-SPAMコンプライアンスガイドに定められた具体的な要件を伴う。どちらも実際には同じことを求めている。自分が誰であるかを述べ、目的を明確にし、人々が止められるようにすること。

根拠が何であれ、トランザクションとマーケティングの流れは配信レベルで分離しておくこと。プロモーションダイジェストとリストを共有していたために顧客が配信停止した破壊的変更の通知は、その日付を待っているサポートインシデントだ。

実際に記入するとどう見えるか

ターゲット通知、最も価値の高いプロダクトアップデートメールであり、多くのチームが決して構築しないもの。

件名: CSVエクスポートがライブになりました

Danaさん、

あなたは3月にCSVエクスポートを要求しました。

今朝ライブになりました。レポートには現在、フィルタを含む
現在のビューのCSVを生成するエクスポートボタンがあります。

あなたの側で何もする必要はありません。すでにあなたの
アカウントで有効になっています。

  詳細: example.com/changelog#csv-export
  リリース日: 2026年9月2日

これはあなたが要求したために届いています。要求の
アップデートから配信停止する: <リンク>

90語で、読者は最初の一文でなぜこれが届いたのかを知る。これを、月次ダイジェストの中の九項目のうちの一つとして現れる同じ変更と比較してみてほしい。Danaには自分自身の要求が出たことに気づく理由がない。

何を測定すべきか

開封率だけではない。ターゲット通知については、問いは要求した本人が戻ってきてその物を使ったかどうかであり、したがって追跡すべき数字はエントリへのクリックと、そのアカウントが一週間以内にその機能を使うかどうかである。破壊的変更の通知については、カバレッジだ。影響を受けたアカウントのうち何パーセントが日付前に開いたか、そして誰と個別にフォローアップしたか。

ダイジェストは、四つのうち開封率が多くを意味する唯一のものであり、そこでさえ業界のベンチマークに対してよりも、自分自身の履歴に対するトレンドとしての方が有用だ。プロダクトアップデートメールの異なる種類は異なる仕事を持っており、したがってすべてを平均した数字は、行動できる何も表していない。

リリースノートとどう違うのか

リリースノートは利用可能であり続ける文書だ。メールは一度だけ起きる配信の仕組みである。同じ変更が両方を生み出し、メールはそれが指し示すエントリよりも短くあるべきだ。リリースノートのベストプラクティスは文書を扱い、チェンジログ対リリースノートはどちらを書いているのかを扱う。

正しく理解する価値のある関係とはこうだ。チェンジログのエントリが正典のテキストであり、メールはそれを引用する。この二つが乖離すると、クリックした読者は異なる変更の説明を見つけ、両方への信頼を失う。エントリを先に公開し、そこからメールを生成することは、構造によってそのずれを取り除く。changeloopも自分の側では同じように動く。エントリは一度レビューされ、ページ、フィード、ウィジェットに公開され、ウィジェットを通じてそれを求めた人物は、そのフィードバックから作られたGitHub issue上と、ウィジェットそのものの中で通知される。changeloopはメールを送らない。あなたのメールツールが公開されたエントリを引用する。

FAQ

プロダクトアップデートメールはどのくらいの頻度で送るべきか? 受け手が知りたい具体的な何かがあるたびであり、ターゲット通知の場合はその要求がリリースされるたびを意味し、ダイジェストの場合は最大でも月一回を意味する。

メールにはチェンジログのエントリ全体を含めるべきか? いいえ。一文とリンクだけでよい。エントリが正典バージョンであり、メール内の完全なコピーは、整合性を保つべき二つのテキストがあることを意味する。

どのくらいの開封率を期待すべきか? それぞれの種類をベンチマークではなく、それ自体と比較すること。ターゲット通知と月次ダイジェストは異なる製品であり、それらを平均すると、追跡する価値のある唯一の数字が隠れてしまう。

破壊的変更のために別のリストが必要か? 必要だ。そしてそれは、結果を理解しないまま人々が不用意に配信停止できないリストであるべきだ。それが彼らに障害をもたらすリストだからである。


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

changeloopの関連ページ: changelogの例, 開発者向けドキュメント

changeloop
ループを閉じるchangelogを作っているチームです。ユーザーが何かを求め、あなたのチームがそれを届け、求めた人がそれを知る。