結論：beehiivの失敗は、機能不足より「複数の変更を同日に行う」ことで起きます。 配信、フォーム、DNS、契約を一つずつ検証します。
公開前の10項目
- 本番リストを先に全件入れる
- 同意状態を一つのactiveへまとめる
- カスタム項目を自由記述だらけにする
- 外部埋め込みでもsignup flowが同じと思う
- 既存ルートドメインを上書きする
- Cloudflareの対象レコードをproxiedのままにする
- DMARCを後回しにする
- 進行中購読者を見ず自動化を編集する
- Quick exportだけで退出できると思う
- ダウングレードとアカウント削除を混同する
影響が大きい順に直す
DNSと送信者認証、同意状態、自動化、データ退避、デザインの順です。見た目は後から直せますが、既存サイト停止や誤配信、同意記録の欠損は回復が難しくなります。
変更台帳を残す
変更前後の設定、担当者、時刻、戻し方、確認結果を一行ずつ記録します。公式仕様が変わるため、公開直前に料金とドメイン、自動化のページを再確認します。
次にすること
beehiivの始め方をチェックリストとして実行し、退出手順は解約前チェックまで先に読んでおきます。
Sources
- Add and configure custom domains（確認日：2026-08-17）
- beehiiv automations（確認日：2026-08-17）
- Exporting post or subscriber data（確認日：2026-08-17）
- Change beehiiv plan（確認日：2026-08-17）