リリースメールの書き方:読まれる六ブロックの型
リリースメールは六つのブロックとリンク一つでできています。コピーできる型、件名のテスト、送信前に確認する五項目をまとめました。

リリースメールは、すでに登録してくれた人に送る一通で、仕事は一つだけです。相手を一つのページへ連れていくこと。必要なのは六つのブロックです。件名、変わったことを述べる一文、証拠、行動、今日開く理由、人間の署名。それ以外は飾りか、迷惑メール判定の理由になります。
ここで扱うのは、報道向けのプレスリリースでも、社内に出回る「リリースしました」の連絡でもありません。読者はすでにメールアドレスを預けてくれています。難しいのは説得ではなく、自分が登録したあれが本当に動き出したと、最初の二行で気づいてもらうことです。
リリースメールが果たすべきこと
「知らせ」と「入口」が一つになったものと考えてください。カテゴリの説明も、会社の紹介も要りません。何が出たのか、それで何ができるようになったのか、どこを押すのか。この三つだけです。登録済みの相手に入門的なマーケティングをすると、自分の履歴を忘れたニュースレターに見えます。
| ブロック | 役割 | よくある失敗 |
|---|---|---|
| 件名 | 何が出たかを読者の言葉で言う | 名詞のない熱意(「重大なお知らせ」) |
| 書き出し | もう使えることを確認する | 会社紹介をやり直す |
| 証拠 | 読者が確かめられる事実を一つ | 数字の代わりに形容詞三つ |
| 行動 | リンク一つ、動詞一つ | 同じ重さのボタンが四つ |
| 理由 | 明日より今日の利点 | リセットされるカウントダウン |
| 署名 | 担当者名と返信先 | no-reply アドレス |
この表が論証のすべてです。一つ欠けてもメールは送信でき、見た目も完成しています。だからこの失敗は生き残ります。どこも壊れず、クリック率だけが静かにゼロに近づき、全員が件名のせいにします。
リリースメールの六ブロック・テンプレート
この骨組みをコピーして、角括弧を埋めてください。順番は変えません。スマートフォンで一度もスクロールせずに読み切れる長さにします。収まらないなら、ロードマップの説明段落を削ります。
件名:[製品名] が使えるようになりました:[それでできる一つのこと]
プレビュー:[読者にとって何が変わったか、10〜20字]
[名前] さん
[製品名] を本日リリースしました。[一文:旧版ではできなかった何ができるようになったか。]
[証拠:数字、日付、または読者が自分で確かめられる機能。]
[リンク一つ:「変更点を見る」→ 変更を示すページ]
[今の理由:先着100アカウント、ローンチ価格、または何も書かない。]
[あなたの名前]
[人が読む返信先アドレス]
「今の理由」は省略できます。今日開く本当の理由がないなら、期限を作らずにその行を消してください。リセットされるカウントダウンは、次の配信を無視することをリストに教える最短の方法です。
変えてはいけない点が二つあります。リンクは一つ。二つにするとクリックが割れ、結果が読めなくなります。返信先は実在の人間が読むアドレス。最初のリリースメールへの返信は、クリック数より価値があることが多いからです。
| 確認 | 合格条件 |
|---|---|
| 件名 | 製品名と変更の両方が入っている |
| プレビュー | 情報を足し、件名を繰り返さない |
| 長さ | 署名の前まで150語未満 |
| リンク | 行動の入口は一つだけ |
| 証拠 | 確かめられる事実一つ、変わるものは日付付き |
| テキスト版 | HTML を外しても同じ順で読める |
混んだ受信箱で残る件名の作り方
リリースの件名は、興奮ではなく変更を名指ししたときに効きます。「請求書の書き出しが使えるようになりました」は「きっと気に入ります」に勝ちます。読者は件名だけで自分に関係あるかを判断できるからです。興奮型は、何が起きたか知るために開くことを求めます。
- 製品名か機能名を最初の三語に入れる。
- 読者が使う名詞を使い、社内のコード名は使わない。
- 45文字前後に収め、スマートフォンで有用な半分が切られないようにする。
- 本当の返信でなければ「Re:」や「Fwd:」で始めない。Google の送信ガイドラインも、これを誤解を招くヘッダーとして挙げています。
- プレビューは件名の反響ではなく、二文目として書く。
45文字はレイアウトの目安で、法律ではありません。端末と差出人名によって変わります。譲れないのは、件名とプレビューだけで「何が変わったか」に答えていることです。「何かあった」だけでは、メールが自分に不利に働いています。
送信前の五つの確認
これは文案ではなく配信の確認です。送信ドメインを管理する人の仕事で、ローンチごとではなくキャンペーンごとに一度で足ります。
- ドメインを認証する。Google の「Email sender guidelines」(2026-10-31 確認)は、Gmail へ送るすべての送信者に SPF か DKIM の設定を求め、1日5,000通を超える場合は DMARC とワンクリック解除も求めています。適用は 2024-02-01 からです。出典:Gmail の送信ガイドライン。
- まずシードリストへ送る。別々のプロバイダーのアドレス二つ。リンクが開くか、画像が出るか、テキスト版が空でないかを確認します。
- 解除の経路を試す。ログインなしで動き、本文中に見えること。フッターの小さな文字だけでは足りません。
- 迷惑メール率を見る。Google は 0.10% 未満を推奨し、0.30% 以上は問題だと警告しています。前回がその線に近ければ、ローンチ配信を足す前にリストを直します。
- 自分が見ていられる時間に送る。午前2時に出てリンクが壊れたメールは、顧客が見つけます。
どれも文章を良くしません。文章が読まれる機会があるかどうかだけを決めます。認証のないドメインから出た完璧な文面は、文法の正しい迷惑メールです。
つまずきやすいところ
三つの失敗が繰り返され、どれも送信前に止められます。
- 製品ニュースだけを解除した人も含め、リスト全体に同じ文面を送る。セグメント分けは、告知と苦情の分かれ目です。
- 読者が開発を追いかけている前提で書く。追いかけていません。最初の一行だけで意味が通る必要があります。
- ウェイトリストの後ろにある機能を約束する。ボタンの先が「近日公開」なら、次の配信は雑音として読まれます。
- 製品ページが固まってからメールを書く。メールはページが実際に見せているものを説明します。
- パソコンより先にスマートフォンで確認する。リストの多くはスマートフォンで見ます。
このテンプレートが答えられないこと
メールが受信箱に届くかは分かりません。届く場所はドメインの評判と受信者の行動で決まり、どちらもこちらでは制御できません。ローンチが成功したかも分かりません。クリックは登録ではなく、登録は売上ではありません。別々の窓で測る別々の数字です。
もう一つ、最初にみんなが見る数字について書いておきます。Google の文書は、開封率を計測しておらず、開封率が低いことは配信性の問題を示す正確な指標とは限らないと明記しています。開封率のグラフでこのメールを判断するのは弱い証拠です。ページへのクリックと、そのページ自体の転換を見てください。
リリースメールは扉であって、看板ではありません。正しい人が一度通れば十分です。
よくある質問
リリースメールはどのくらいの長さがいいですか。
スマートフォンでスクロールせずに行動が見える長さです。実際には署名の前まで150語未満、製品をすでに知っているリストなら100語未満のことも多いです。
登録したけれど一度も開かない人にも送りますか。
最初の配信では通常送りません。活発なリストの中に冷えたセグメントを混ぜると、全員のエンゲージメント信号が下がります。まず活発な部分へ送り、残りは別の小さなメールで判断します。
リリースメールはプレスリリースと同じですか。
違います。プレスリリースは記者向けで日付を持ち、リリースメールは登録者向けでリンクを一つだけ持ちます。媒体向けが必要なら、変更履歴はrelease notes の書き方を参照し、二つの文面は分けてください。
メールのリンクはどこへ送ればいいですか。
変更を文脈ごと見せられるページです。新製品ならローンチページ、新機能ならその機能があるページ。プロダクトのランディングページの書き方がそのページを、Product launch checklist が周辺の素材を扱っています。
このメールが大きな取り組みの一部なら、文案よりチャネルの順番が重要です。配信の流れが順番を持ち、メールはその中の一つの扉です。
収録: QueryWinガイド · レベル2


