個人開発者のローンチメールが素通りされる 3 つの理由
リリースした。何ヶ月か温めていた機能を、ようやく形にした。サイトを更新し、X に投稿し、購読者リストにローンチメールを送る。配信ツールのダッシュボードを開くと、開封率はそれなりの数字が並んでいる。けれど、サインアップの数字はほとんど動かない。Pro への切り替えに至っては、ゼロのままだ。
「開いてはくれた。なのに、その先で何も起きていない」── この感触は、個人開発者なら一度は通る場所だと思います。原因は、文面の細部ではありません。ローンチメールが素通りされるとき、たいていほぼ同じ 3 つの理由が、毎回同じ順序で重なっています。
理由 1：件名が「お知らせ」になっている
最初の関門は、本文ではなく件名です。受信箱に並んだ件名を見て、読者は 0.5 秒で「開けるかどうか」を決めています。ここで素通りされたら、本文の出来は関係なくなる。
それでも、ローンチメールの件名は判で押したように似た形になります。
「〇〇 v2.0 リリースのお知らせ」 「【新機能】△△に対応しました」 「アップデートのご案内」
書いた本人にとっては、内容を正確に表した、誠実な件名です。何が起きたかを過不足なく伝えている。
ただし、受信箱の側から見ると、この件名はすべて 「送り手視点の宣言」 に揃っています。「v2.0 をリリースした」「新機能に対応した」「アップデートがある」── 主語は全部、書き手の側のプロダクトです。読者の状況は、件名のどこにも映っていません。
人は受信箱で、件名を「自分宛か／自分宛じゃないか」で振り分けます。判定材料は、ほぼ「件名の主語が自分の関心に重なるか」だけです。「お知らせ」「ご案内」「リリース」が主語のメールは、その判定で他人宛の側に倒れます。開かないわけではなく、後で見ようと思って、結果として開かれない。
件名で問うべきは「何をリリースしたか」ではなく、**「読者が今日かかえている、どの不満が、このメールで一歩前に進むのか」**です。「v2.0 リリース」ではなく「これまで〇〇で詰まっていた人へ」、「新機能のお知らせ」ではなく「△△の手動コピペが、要らなくなりました」── 主語を読者側に移すだけで、件名は「自分宛」の側に動きます。
件名は本文の前置きではありません。本文を読むかどうかを決める、本文そのものの最初の一文です。
理由 2：冒頭の数行に、機能スペックが並ぶ
件名を突破して、読者がメールを開いた。ここからが本文の仕事です。けれど、ローンチメールの本文は、開いた瞬間にもう一度素通りされます。理由は冒頭の数行にあります。
典型的な書き出しは、こうなります。
「いつもご利用いただきありがとうございます。 このたび、〇〇 v2.0 をリリースしました。 主な変更点は以下のとおりです： ・△△に対応 ・□□を高速化 ・✕✕ UI を刷新」
書き手の側からは、要点を素早く伝えるための、効率的な構成に見えます。挨拶があって、リリース宣言があって、変更点が箇条書きで並ぶ。
ただ、開いた読者の脳内では、別のことが起きています。「これは、私の何を解決するメールなんだろう？」 という問いを抱えながら、最初の数行を読んでいる。その問いに、冒頭の数行が答えていないと、読者は「自分宛じゃないかもしれない」と判定を保留したまま、次のメールに流れていきます。
機能スペックは、その問いに答えません。「△△に対応」と書かれていても、それが自分の今日の作業のどこに刺さるのかは、読者の頭の中で翻訳されないと見えない。翻訳のコストは、読者ではなく書き手が払うべきものです。けれど、ローンチメールの 9 割は、その翻訳を読者に丸投げしている。
冒頭でやるべきことは、機能の列挙ではなく、読者の関心の場所に、一行で着地することです。「これまで〇〇のたびに、手で △△ を貼り直していたと思います。今日からそれは要りません」── これだけで、読者の頭の中の「自分の今日の作業」と、メールの内容が、最初の一行で接続します。
関心 → 信用 → 行動、という順序があります。冒頭の数行は、その最初の 関心 だけを担当する場所です。信用も行動も、まだ早い。スペックの一覧は、関心が立った後に、補強として配置するもので、入口に置くものではありません。
理由 3：CTA が「ぜひお試しください」で散らかっている
3 つ目は、メールの末尾です。ここでも、ほぼ全員が同じ場所で転びます。
ローンチメールの締めは、よくこうなります。
「ぜひ一度お試しください。 詳しい使い方はサイトをご覧ください。 フィードバックもお待ちしております。」
書き手としては、選択肢を渡している感覚があります。「試したい人は試して、知りたい人はサイトを見て、感想がある人は送ってきて」── 親切のつもりで、行動の選択肢を 3 つ並べる。
ですが、選択肢を渡された読者は、何も選びません。
これは個人開発者には少し直感に反するところで、丁寧に作ったメールほどここで詰まります。人が読み終わったときに行動するかどうかは、「選択肢の多さ」ではなく「次の一歩の明確さ」で決まります。次に押すボタンが 1 個なら押せる。3 個並んでいると、「どれが正解か分からない」と感じて、結局どれも押さない。
メール 1 通には、行動を 1 つだけ載せる。これがローンチメールの一番の規律です。「サイトを見て」と「サインアップして」と「フィードバックして」が並んでいたら、メインは 1 つに絞る。残りはおまけとして、視覚的にも明確に小さくする ── あるいは思い切って、別の機会のメールに回す。
そして、その「1 つの行動」も、抽象語にしない。「ぜひお試しください」は、行動の指示ではなく、書き手の願望の表明です。読者は何をすればいいのか、依然として分からない。「下のボタンから、新しい △△ を開いてみてください」と書けば、押すボタンと、押した後の場所が、文面の中で確定します。
行動を 1 つに絞り、抽象を具体に置き換える。たったこれだけで、同じ開封数のメールが、まったく違う数字を返してきます。
3 つの理由は、別々の問題ではない
ここまで、件名・冒頭・CTA を別々に解いてきました。けれど、よく見ると 3 つは別々の問題ではなく、ひとつの順序の話を、別の場所で繰り返していることに気づきます。
その順序が、関心 → 信用 → 行動です。
件名は 関心 の入口です。読者の状況を主語にしないと、入口で素通りされる。冒頭の数行は、関心を 信用 に橋渡しする場所です。「これは私の今日の作業の話だ」と読者の中で輪郭ができないと、橋が落ちる。末尾の CTA は 行動 の蛇口です。蛇口を 3 つ並べたら、読者はどれもひねらない。
ローンチメールが素通りされるとき、たいていこの 3 箇所のうち少なくとも 2 箇所で、順序の同じ場所が抜け落ちています。だから、片方だけ直してもメールは動かない。3 つを同じ順序で並び替えると、開封率は変わらなくても、その先の数字が初めて動き始めます。
まとめ：直すのは、書き方ではなく順序
ローンチメールがうまくいかないとき、書き手はまず「もっと熱意を込めた文章を書こう」「もっと丁寧に説明しよう」「もっと魅力的な機能名にしよう」と考えがちです。けれど、文章の熱量も、説明の丁寧さも、機能名の響きも、関心 → 信用 → 行動の順序が崩れた場所では、ほとんど効きません。
直すのは、書き方ではなく、順序です。見えれば、直せる。次にローンチメールを書くときは、件名を書く前に一度手を止めて、3 つの場所を順に見直してみてください。
- 件名は、読者の状況が主語になっているか
- 冒頭の数行は、読者の関心の場所に一行で着地しているか
- 末尾の CTA は、行動が 1 つに絞られ、具体になっているか
このチェックを通った時点で、ローンチメールは 9 割の同種メールから抜け出します。送る側の手数は、ほとんど増えません。
姉妹記事として、同じ「関心 → 信用 → 行動」の順序を別の戦場で扱った記事を書いています。LP のファーストビュー戦場は 個人開発者の LP のファーストビューが素通りされる 3 つの理由、Twitter 戦場は 個人開発者の Twitter 告知が素通りされる 3 つの理由、動画概要欄戦場は 個人開発の動画の概要欄が素通りされる 3 つの理由、GitHub README 戦場は 個人開発者の GitHub README が素通りされる 3 つの理由、Product Hunt 戦場は 個人開発者の Product Hunt ローンチが素通りされる 3 つの理由 にまとめています。サービスのトップページで素通りされる構造そのものは 個人開発者のサービスが「素通り」される、たったひとつの構造的な理由、価格ページの手前で詰まる構造は 「無料で十分」と消えていくユーザーをめぐる、3 つの誤算、学ぶ側の入口は コピーライティングを学んでも売れない人の 3 つの誤解 にあります。並べて読むと、ローンチメールで起きていることは、戦場が違うだけで同じ構造であることが見えてきます。
ちなみに、配信に使うツール（Beehiiv / Kit / Substack など）は、この 3 つの理由とは独立した話です。どのツールでも、件名・冒頭・CTA の順序を直さない限り、数字は動きません。逆に言えば、順序さえ整っていれば、ツールは何でもかまわない。
WHY を順に腑に落とし、そのあと AI を相棒にして HOW を回せるところまでを 1 冊にまとめたのが、下記の本です。個人開発者・インディー Web 作者・動画作者向けに、LP・短文・メールの戦場別の書き方と、Claude を実際に使ったプロンプト連鎖の実演を含めて統合しています。