メルマガのダブルオプトインとは。入れたあとに見落としやすい3つの穴

ダブルオプトインは、登録フォームの送信だけでは購読を有効にせず、確認メールのリンクを開いた時点で初めて購読を有効にする方式です。フォーム送信だけで有効になるシングルオプトインに比べて、配信リストの質が上がり、誤登録による苦情を減らせます。代わりに、確認メールを開かない人は登録の途中で止まります。

一般的な解説はここまでで足ります。実際に運用して困るのは、仕組みが「動いているように見える」状態で起きる問題です。relmea で起きたのは次の3つでした。

  • 確認リンクが本人以外にも開かれ、ステップメールが二重に配信された
  • 連絡先の作成場所を誤り、一斉配信だけが送れなかった
  • 確認完了ページへの到達が少なく、配線の故障を疑ったが正常だった

前提となる登録の流れ

以降の話は、次の流れが前提です。

  • 登録フォームの送信で、配信停止状態の連絡先を仮登録として作る
  • 署名付きトークンのリンクを入れた確認メールを送る（有効期間は48時間）
  • 期限が切れたリンクは「有効期限が切れています」のページに進み、再登録へ案内する
  • リンクを開くと購読が有効になり、「確認完了」という出来事（イベント）が発生する
  • そのイベントを起点に、ステップメール（自動配信）が始まる

フォームには、ボット避けの隠し項目も置いています。値が入っていたら、何もせず静かに終了します。再登録の扱いも決めてあります。確認済みの人には確認メールを送らず「確認済み」を返し、未確認の人には連絡先を新しく作らず確認メールだけを再送します。

事故1：確認リンクの先読みで、ステップメールが二重に配信された

最初に見つかったのは、同じ人にステップメールが重複して届いていた問題です。

何が起きたか

確認リンクは、開いた瞬間に処理が走る方式（GET）でした。メールソフトやセキュリティスキャナは、本人がクリックするより先にリンクを開くことがあります。本人が後日、もう一度同じリンクを開くこともあります。

以前の実装は、リンクが開かれるたびに無条件で「確認完了」のイベントを発火していました。その結果、17通のステップメールが人数分ではなく「リンクが開かれた回数」だけ並行して走り、以後の配信が二重に届きました。

実測した内容

2026年8月1日から8月15日までの送信72通を調べ、次のことを確認しました。

  • 2名が14〜15通を受信していた
  • そのうち半分が重複だった
  • 片方は同じ分に2通、もう片方は14時間の差で2通届いていた

登録フォームも確認メールも正常に動いたまま起きており、エラーは1件も出ていません。人ごとの受信数を数えて、初めて見えた問題です。

2026年8月15日に入れた対策

購読を有効にする前に、連絡先の現在の状態を読むようにしました。すでに購読中なら、状態を何も変えず、イベントも発火せず、通常と同じ完了ページへ進めます。利用者には成功として見せます。

2回目以降のアクセスをエラーにしないのは、本人が正当にもう一度開いただけの場合もあるからです。失敗画面を見せる理由がありません。

残っている限界と、未判断の恒久策

この対策には限界があります。消費済みのトークンを記録する置き場が無いため、ほぼ同時刻に届いた二重のリクエストまでは防げません。状態を読んでから書き込むまでの間に、もう一方のリクエストが入る余地があるためです。

恒久策の候補は、確認を「ワンクリックのボタン（POST）」にして先読みを無効にすることです。リンクを開くだけでは何も起きず、画面のボタンを押して初めて確認が完了します。ただし、この方式にするかどうかはまだ判断していません。

自社で同じ仕組みを持つなら、確認リンクを開いただけで処理が走っていないか、確認完了の発火が1人1回に制限されているかを、まず確かめてください。

事故2：一斉配信だけが、静かに送れない状態になっていた

2つ目は、ステップメールが動いている裏で、一斉配信だけが止まっていた問題です。

何が起きたか

連絡先を、メール配信サービスの「口座直下」に作っていました。一斉配信の宛先は、配信リスト（オーディエンス）です。口座直下の連絡先は、このリストに紐付いていませんでした。

そのため一斉配信は、「宛先に連絡先がない」という理由で送れない状態が続きました。ステップメールはイベントを起点に動くので、リストの紐付けとは関係なく正常に動いていました。ページもAPIも正常に見えるまま、一斉配信だけが送れない穴になっていたということです。

実測した内容

2026年9月5日に件数を数えました。

  • 口座直下の連絡先：9件
  • 配信リスト配下の連絡先：0件

購読中の8件は、同日に手作業で配信リストへ紐付けて復旧しました。

対策

連絡先を作るURL（宛先）をコード上の1か所に集約し、配信リスト配下で作るようにしました。作る場所が複数に散らばっていると、1か所だけ直しても漏れが残るためです。

直したあとは、捨てアドレスで往復して各操作の挙動を実測しました。

  • 作成：201
  • 取得：200
  • 更新：200
  • 削除：200

ただし、配信リストから消しても、口座直下の連絡先は残りました。テスト用のアドレスを片付けるときは、この挙動を前提にする必要があります。

自社で同じ仕組みを持つなら、「ステップメールが届いている」ことと「一斉配信の宛先に連絡先が入っている」ことは、別々に確かめてください。一斉配信は、送る日が来て初めて問題に気づくことが多いからです。

事故ではなかった例：ダブルオプトインの完了率が低いとき、配線か行動かを切り分ける

3つ目は事故ではなく、事故を疑った例です。切り分けの手順として載せます。

疑った理由

2026年8月のある期間、メール登録ページへの着地は13でした。内訳はAI向けが7、EC向けが6です。一方、確認完了ページへの到達は3でした。前の期間は、着地11に対して完了8でした。

数字だけを見ると、完了が大きく落ちています。確認リンクが壊れている、確認メールが届いていない、といった配線の故障を疑う状況でした。

実アドレスで1往復して確かめた

2026年8月19日に、実アドレスで登録から完了まで1往復しました。結果は次のとおりです。

  • 登録の送信は200で成功した
  • 確認メールはすぐに着信した
  • 確認リンクから完了ページに着地できた
  • 同じアドレスで再登録すると「確認済み」が返った
  • ウェルカムの1通目も配信済みだった

全工程が正常でした。仕組みの故障ではなく、確認メールを開かない人がいるという行動側の問題だと判断しました。なお、完了3件と8件という母数では率を比べる意味は薄く、参考値にとどめています。

同じ数字では配線を再調査しない

この確認には運用上の意味があります。以後、同じような数字が出ても配線は再調査せず、打ち手を確認メールの件名と文面、登録直後のページの案内に絞ります。原因の候補を先に1つ消しておくと、次から迷う時間が減ります。

切り分けの手順と、確認メール側の工夫

ここまでの3件から、切り分けの順番をまとめます。完了率が低い、あるいは配信がおかしいと感じたときは、次の順に見ます。

配線の確認

  • 実アドレスで、登録から完了まで1往復する
  • 各段階の応答（送信が成功したか、確認メールが着いたか、完了ページに着地したか）を記録する
  • 再登録の挙動（確認済みなら確認メールを送らないか）を確かめる
  • 確認後に、1通目の自動配信が届くかを見る
  • テスト用アドレスは、配信リストから必ず消す（送信ログは消さなくてよい）

数字の読み方

  • 1往復が全部通れば、配線ではなく行動側の問題と見る
  • 完了3件と8件のように母数が小さい数字は、率で比べず参考値にとどめる
  • 重複配信が疑われるときは、送信ログを人ごとに数える

いまの確認メールに入れていること

  • 確認後に届く1通目の中身を、本文で予告している
  • 登録直後のページから、特典はすでに読めることを書いている（確認前でも読めます）
  • 発行者情報（特定電子メール法に基づく表示）へのリンクを置いている
  • 件名は「【relmea】メール登録の確認」とし、有効期限（48時間以内）をリンクの直前に書いている

「確認すると何が届くのか」と「確認しなくても特典は読める」を同時に伝え、確認する動機と不安の両方に先回りする狙いです。

自動化してよい範囲と、人が判断する範囲

最後に、運用の線引きをまとめます。3つの経験から、機械に任せてよい仕事と人が決める仕事ははっきり分かれます。

自動化してよいもの

  • 購読を有効にする前に現在の状態を読み、購読中なら何も書かない処理
  • 連絡先を作る宛先を1か所に集約して、作る場所の揺れをなくすこと
  • 捨てアドレスで、作成・取得・更新・削除を往復して挙動を実測するテスト
  • 実アドレスでの、登録から完了までの往復確認
  • 人ごとの受信数を数えて、重複配信を見つける集計

これらは手順が決まっていて、結果を応答や件数で判定できます。繰り返すほど価値が出るので、スクリプト化に向いています。

人が判断するもの

  • 完了率が低いときに、件名・文面・登録直後のページのどれを直すか
  • 確認をワンクリックのボタン（POST）にして先読みを無効にするかどうか。登録の手数が1回増える代わりに先読みの影響を消せるため、その兼ね合いを決める必要があります
  • 少ない母数の数字を、どこまで信じて打ち手に反映するか

ダブルオプトインは入れて終わりではなく、入れたあとの「静かな不具合」を見つける運用までが仕組みです。自社で同じ構成にするなら、まず次の3点を確かめてください。

  • 確認リンクが複数回開かれても、確認完了のイベントが1回しか発火しないか
  • 連絡先が、一斉配信の宛先になる配信リストの配下に作られているか
  • 完了率が低いとき、実アドレスの1往復で配線を先に確かめられるか