Benchmarkのメルマガ自動化が動かなかった2つの原因——アカウント停止とDOI仕様の誤認

Benchmark Emailのステップメールが3週間動きませんでした。原因は1つではなく、2つのレイヤーに分かれていました。

直接原因：アカウントが停止状態だった
設定以前の問題として、そもそも送信できる状態ではなかったんです。

再設計の原因：DOI（ダブルオプトイン）とPDF配布導線の相性
アカウントを復旧した後も、無料PDFをメールで渡す設計にDOI仕様が合っていませんでした。

この記事では、2つの原因の発見と、PDFをメールではなく認証後ページで渡す設計に切り替えた判断の記録を整理しています。前回の記事でCloudflareとMakeを使って「途中で止まった」状態の続きになります。

以前の記事（CloudflareとMakeで検証した前回の記録）でこう書きました。

「リスト登録はできた。しかしオートメーションが発火しなかった。原因を断定することはしない」

あの時点では本当に分からなかったんですよね。設定を疑い、ツールを変え、それでも同じ場所で止まってしまいました。

今回は、その正体が判明した記録です。

---

原因①：アカウント停止——メルマガ自動化以前の問題でした

何度やっても登録フォームが作れない

再挑戦を始めたとき、最初に詰まったのは意外な場所でした。

Benchmark Emailの無料プランでは、登録フォームを1つ作成できるはずです。それを使おうとしたんですが、フォームが作れない。何度試しても同じ状態が続きました。

設定の問題だと思って調べました。UIの問題かと思って別のブラウザでも試しました。それでも作れない。

「設定の外に原因があるのでは」と感じたのはこのタイミングです。

サポートへ連絡して判明したこと

フォームが作れない以上、アカウント自体に問題がある可能性があります。そう判断してサポートへメールしました。

返答は明確でした。アカウントが停止状態になっていたんです。

原因は長期間の未利用です。実は過去にも一度、同じ理由でアカウント停止を経験していました。今回もそれだったということです。

Benchmark Emailは長期間未利用が続くとアカウントが停止される場合があります。「設定が正しいはずなのに動かない」という状態が続くときは、アカウントの状態確認を最初に行う方がいいですよ。設定の問題を探し続けると、上位にある問題が見えなくなってしまいます。

停止解除をサポートに依頼し、アカウントが正常な状態に戻りました。これがすべての再出発点でした。

この経験から得た確認の順番

確認すること	タイミング
アカウントの状態（停止・制限）	ツールを使い始める最初に
無料プランの制限内容	機能を使う前に
サポートへの問い合わせ	「設定は合っているはずなのに動かない」が2回続いたとき

設定を疑う前に、アカウントと契約状態を確認する。これが今回の最初の学びです。

---

原因②：ダブルオプトイン仕様の誤認——ステップメールが発火しなかった理由

アカウント正常化後も続いた詰まり

アカウントが使えるようになり、改めてCloudflare WorkersでAPIを叩いてリスト登録の検証を再開しました。

リスト登録：成功。
ステップメール：発火しない。

同じ場所で止まってしまいました。

Benchmark EmailのDOI仕様を調べて分かったこと

ここでようやくBenchmark Emailの仕様を正確に調べました。

Benchmarkのヘルプを確認したところ、リストに追加された購読者に対するステップメールの配信は、DOI（ダブルオプトイン）の認証完了を必須条件としていないようです。DOIはリストの品質管理——有効なアドレスかどうかの確認——のための仕組みであり、ステップメールの配信トリガーとは別に設定できる構造になっていました。

つまり私は「認証しないとステップメールが届かない」と思い込んでいたんですが、それは誤りだったんですね。

私が今回の検証で確認した範囲では、Benchmark EmailのDOI（ダブルオプトイン）とステップメールの配信は独立して設定できます。「DOIを通過しないと配信されない」という思い込みが、3週間の詰まりの根本にありました。ただしアカウント設定や契約プランによって挙動が異なる可能性があるため、自分の環境で必ず確認してみてください。

DOIの本来の役割はこうです。

登録
↓
認証メール送信（DOI）
↓
読者がリンクをクリックして認証
↓
「有効な購読者」としてリストに確定

この認証プロセスは、リストに無効なアドレスや誤入力が混入するのを防ぐためのものです。到達率・開封率の維持が目的で、ステップメールの配信可否とは別の話でした。

誤認が判明したときの反応

正直に言うと、特に驚きも落胆もありませんでした。

「そういう仕様だったのか」と把握した瞬間、すぐ次の問いに切り替わりました。「では、この仕様を前提にどう設計するか」です。

感情よりも設計の問題として処理できたのは、たぶん前回の失敗を通じて「ツールの仕様を理解してから設計する」という順番の重要性を、すでに体感していたからだと思います。

---

DOIと無料PDF配布導線の相性問題

仕様を正確に理解した上で、改めて設計を見直しました。そこで浮き上がったのが2つの問題です。

問題①：認証メールと配信の遅延

DOIプロセスを経ると、認証メールの送信から読者のクリック・その後の処理まで、タイムラグが発生することがあります。私の環境では5〜10分程度の遅れが確認できました。

フォーム送信直後に「無料PDFをメールで受け取ろう」とした読者が、しばらく待っても届かない状態になりますよね。これはUXとして問題があります。

問題②：無料PDFをメールで渡す設計の脆弱さ

PDFのダウンロードリンクをステップメール1通目に入れる設計を当初は考えていました。しかしこれには構造的な問題があります。

メール配信は外部サービスに依存しています。遅延・迷惑メールフォルダへの振り分け・読者側のメール環境の違い——こうした変数はコントロールできません。

「無料PDFを渡せた」という確認を、メールの開封に依存させることは設計として不安定だと感じました。

  無料PDFをメールで渡す設計になっているか
→ NOなら対処不要。YESなら以下を確認してみてください

  メール遅延・迷惑メール振り分けを想定した代替手段があるか
→ NOなら「認証後ページ」での配布に切り替えることを検討してみましょう

  配布URLが第三者に共有されるリスクを許容できるか
→ NOなら有料コンテンツにはこの設計を使わない方がいいです（無料コンテンツであれば割り切る判断もあります）

---

設計転換の判断——無料PDFはメールではなくページで渡すことにしました

変更前の構想

LP
↓
CF7フォーム送信
↓
Benchmark Emailへ登録（API）
↓
認証メール（DOI）
↓
ステップメール1通目に無料PDFリンク

問題は、メール配信の遅延・到達の不確実性が、読者の最初の体験に直接影響してしまう点です。

変更後の設計

LP
↓
CF7フォーム送信
↓
仮サンクスページ（「メールを確認してください」）
↓
認証メールのリンクをクリック
↓
無料PDF受け取りページへ遷移
↓
ステップメール配信開始

漏洩リスクについての判断

ページで渡す設計にすると、URLを知っていれば誰でもアクセスできてしまいます。「ランダムにURLを当てられる」「他人にURLを共有される」というリスクは考えました。

ただし今回の対象は無料PDFです。漏洩しても実害はほぼありません。有料コンテンツであれば別の設計が必要になりますが、無料PDFについては割り切ることにしました。

「完璧な設計」より「動く設計を今作る」——これが今回の判断基準です。

---

この後どうなったか

設計転換後、CF7とBenchmark EmailのAPI連携、仮サンクスページとPDF受け取りページの実装を進めました。

実装過程ではさらに詰まりが発生しました。CF7のsuccessurlが機能しない問題、PHPとJSを混在させていたミスなど、複数の技術的な詰まりがありました。これらの解決と完成した全体構造については、次の記事（メルマガ自動化を完成させた導線設計記録）で記録しています。

現時点では、DOI認証後にPDF受け取りページへ遷移する設計は動いています。ステップメールの配信も稼働状態にあります。

---

ダブルオプトインを使わずにステップメールを配信することはできますか

Benchmark Emailにはシングルオプトイン（SOI）の設定もあります。今回の設計ではDOIを採用しましたが、「認証なしで即配信したい」場合はSOIを選ぶ判断もあります。ただしリストに無効アドレスや誤入力が混入しやすくなるため、到達率・開封率への影響を理解した上で選択してほしいですね。どちらが正解かではなく、自分の設計の目的に合わせて選ぶ問題だと思います。

無料PDFをページで渡す設計は、認証しなかった読者にはどう対応しますか

今回の設計では、認証しなかった読者はPDF受け取りページに遷移できません。ただし今回の設計ではステップメールが配信される構造のため、その中でPDFページのURLを案内する方法で対応できると考えています。認証を促す2回目の機会をステップメールで作る構造ですね。

---

まとめ

今回の実践から得た判断基準を整理します。

アカウント状態の確認を最初に行う
メルマガ自動化の設定を疑う前に、アカウントが使える状態かどうかを確認してください。サポートへの問い合わせは早い方がいいですよ。「設定は合っているはずなのに動かない」が2回続いたら、設定の外を疑ってみましょう。

仕様の誤認は設計の前に解消する
「DOIを通過しないとステップメールが届かない」という誤認が3週間の詰まりの根本でした。私が確認した範囲では、Benchmark Emailのダブルオプトイン仕様とステップメールの配信トリガーは独立して設定できます——この確認を最初にしていれば、遠回りしなかったと思います。

無料PDFの渡し方はメール依存を減らす方向で設計する
メール配信は遅延・未到達・迷惑メールフォルダという変数を持っています。読者の最初の体験に直結するPDF配布は、より確実性の高いページ遷移で設計する方が安定しますよ。

今日できる一歩
使っているメール配信ツールのアカウント状態とDOI設定を確認してみてください。「リスト登録」と「ステップメールの配信トリガー」が自分の認識通りに機能しているか、ツールのヘルプかサポートで一度確認してみましょう。

この記事の続き、CF7のJS問題からStripe連携まで完成した全体構造の記録はこちらの記事で公開しています。

関連記事

• 記事100本書いても成果ゼロだった理由【実践ログ】
• ブログで成果が出る人の特徴と出ない人との違い【判断設計】
• ロングテールキーワードの見つけ方｜成果に繋がる複合検索設計

この実践記録を読んで、自分が今どの段階にいるかを確認してみてほしいですね。