メルマガの配信許諾と停止状態をどう管理するか
メールマガジンの「配信許諾」と「配信停止」は、設定後も状態が変わり続けるため、継続して管理する必要がある。受信者は許諾した後に停止を申し出ることがあり、停止した後に再び登録を望むこともあり、さらに「配信は止めてほしいが会員資格は維持したい」といった、部分的な意思表示をする受信者も存在する。さらに多くの企業では、メール配信ツール・LINE公式アカウント・自社CRMという複数のシステムに顧客接点が分散しており、どこかで停止を受け付けても、別のシステムには反映されないまま古い状態が残ることが起こる。本稿は、許諾・停止・撤回・再登録という4つの状態をどう定義し、複数システム間でどう同期させるかを、法的な位置づけと実務設計の両面から整理する。既存のCRM関連記事とテーマが重複しないよう設計した内容であり、配信許諾そのものの取得方法や、チャネル間の冗長化という別テーマとは切り分けている。各見出しの直後に結論を一文で示す構成にしたので、必要な部分だけを拾い読みすることもできる。
この記事の結論
- 許諾・停止・撤回・再登録は別々の状態であり、同じ「オフ」として一括りにしない。
- 受信拒否の通知を受け取ってから反映までの間は、タイムラグそのものを運用上の前提として扱う。
- 配信システム・LINE・CRMはそれぞれ別の停止記録を持ち、自動連携されない場合がある。
- 配信停止請求（特定電子メール法）と利用停止請求（個人情報保護法）は対象も要件も異なる別の請求権である。
- 複数システムの同期は、マスターの所在・反映頻度・反映ラグ・検知の仕組みを先に決めてから運用する。
許諾・停止・撤回・再登録という4つの状態
結論として、顧客の配信に関する状態は「許諾」「停止」「撤回」「再登録」の4つに分けて管理する必要がある。許諾から再登録までの状態を顧客ごとに追跡する設計を前提にしたうえで、それぞれの状態がどう違うのかを以下で確認する。
許諾（オプトイン）と停止（オプトアウト）の違い
許諾（オプトイン）は、受信者が自らの意思で配信に同意した状態を指す。フォーム入力時のチェックボックスや、購入時の同意確認などがこれに当たる。一方、停止（オプトアウト）は、受信者の意思表示により配信を止めた状態であり、同意そのものを取り消すわけではない。多くの配信ツールでは、停止済みの宛先に対して自動的に配信リストから除外する機能を持っているが、この除外はあくまで「送らない」という制御であり、同意の記録自体を書き換えるものではない点を区別しておく必要がある。
この区別が曖昧だと、停止した顧客に別のキャンペーンから再度配信してしまう、いわゆるリスト間の漏れが起きやすくなる。配信システム内で「停止」を扱う場合は、どのリスト・どのセグメントに対して有効なのかを合わせて記録することが前提になる。
実務上は、許諾と停止を1つのフラグで管理せず、「現在の状態」と「その状態になった日時・経路」をセットで持たせておくと、後から経緯を追いやすい。例えばフォーム経由で許諾を得た顧客が、メール内の配信停止リンクから停止した場合、「許諾：2026年6月1日・フォーム」「停止：2026年9月1日・配信停止リンク」という2つの時点情報を別々のレコードとして残す。1つのフラグだけを上書きしてしまうと、いつ・どの経路で状態が変わったのかが分からなくなり、後述する再登録時の確認作業にも支障が出る。
撤回と再登録は「停止」とは別の状態である
撤回は、同意そのものを取り消し、記録上の扱いを変更する状態である。撤回は、「過去に同意した」という事実自体を無効化する点で停止と異なる。再登録は、新たな同意を得て配信を再開する状態であり、別の同意として扱うべきものである。この4状態を区別せずに「配信するかしないか」の二値だけで管理すると、過去の経緯を追跡できず、後述する再登録時の判断や、行政からの説明要求に対応できなくなる。
この4状態をシステム上どう持たせるかは、配信ツール・LINE・CRMのいずれにマスターを置くかによって設計が変わる。重要なのは、それぞれの状態がいつ・どの経路で発生したかという履歴情報を、4つの状態のラベルと併せて保持することである。履歴がなければ、次章で述べる法的な停止確定の判断や、後述する再登録時の確認作業そのものが成立しない。
法的な「停止」が確定するまでの流れ
結論として、受信拒否の通知を受け取ってからシステムに反映されるまでの間には、避けられないタイムラグが生じる。そのラグを前提に運用を組む必要がある。
受信拒否の通知を受け取る
特定電子メール法は、受信者が配信の拒否を通知した場合、送信者がその意思に反して広告・宣伝メールを送信することを禁止している。総務省の解説では、受信拒否の通知方法として、メール本文に明記された配信停止用のリンクや返信アドレスを用いる方法が示されている。まず確認すべきは、その通知が法令が定める方法でのものかどうかであり、SNSのコメントやカスタマーサポートへの口頭での申し出など、通常の配信停止経路以外から意思表示があった場合も、実務上は同様に扱うのが安全である。
通知の受付経路が複数ある場合（メール内リンク、問い合わせフォーム、電話、SNSなど）は、どの経路から受け付けても同じ記録先に集約される状態にしておく必要がある。経路ごとに別の担当者・別のスプレッドシートで管理していると、ある経路で受け付けた停止が別の経路の担当者には伝わらず、結果として一部の経路だけ反映が漏れる。受付経路を増やす場合は、記録先を1つに統一することをセットで検討する。
システムへ反映し、反映後は送信しない
通知を受け取った後は、配信システムやリストへ反映する作業が発生する。反映には処理のタイムラグが生じうる点を前提にしておく必要がある。手動でリストを更新している場合、担当者の確認待ちの間に次の配信が走ってしまう事故が起きやすい。反映が完了した後は、意思に反した送信は法律上禁止されるため、例外的な配信（キャンペーンの都合など）であっても対象から除外しなければならない。この「反映待ちの時間帯に送信しない」というルールを、担当者の裁量に委ねず、配信前のチェック手順として明文化しておくことが実務上の最低線になる。
反映作業を複数人で分担している場合は、誰が最終反映を確認したかを記録しておくことも重要である。反映担当者が変わるたびに確認手順が省略されると、同じ事故が形を変えて繰り返される。配信直前のチェックリストに「本日分の停止反映は完了しているか」を明記し、配信実行者自身がその項目を確認してから送信ボタンを押す、という単純な運用ルールだけでも、事故の多くは防げる。
3つのシステムがそれぞれ別の停止記録を持つ
結論として、配信システム・LINE公式アカウント・自社CRMは、それぞれ独立した停止記録を持っており、一方で停止してももう一方には反映されないことがある。届かない原因を一つに決めつけず、複数の要因を切り分けて記述したうえで、3つのシステムの関係を整理する。
| システム | 停止記録の実態 | 他システムへの連携 |
|---|---|---|
| 配信システム（メール配信ツール） | 停止処理はツール内のリストに反映される | 他システムへ自動連携されない場合がある |
| LINE公式アカウント | ブロック操作は友だちリストから個別に除外される | メール側の停止とは連動しない |
| 自社CRM・顧客DB | 担当者が個別に記録しない限り反映されない | どちらの停止も反映されず古い状態のまま残る |
なぜ自動連携されないのか
メール配信ツールとLINE公式アカウント、CRMは、それぞれ別のベンダーが提供する別のサービスであり、標準で相互に通信する仕組みを持たないことが多い。API連携を別途構築していない限り、ある顧客がメールを停止しても、LINEの配信対象からは自動的に外れない。
逆に、LINEをブロックした顧客に対して、メール配信は続いてしまう。この分断は、どちらかのベンダーの不備ではなく、システムが別々に設計されている以上、当然起こる構造的な前提として扱う必要がある。
API連携を構築する場合でも、全項目を双方向でリアルタイム同期する必要はない。まずは「停止」という1つの状態だけを一方向（配信システム→CRM、またはCRM→配信システム）で連携する範囲から始め、同期対象を広げるのは運用が安定してからでよい。最初から全システム・全項目を対象にした連携を設計しようとすると、要件が膨らみ、どこから着手すべきか判断できなくなりやすい。
CRM側の記録が古いまま残る理由
自社CRM・顧客DBは、配信ツールやLINEの停止操作を自動で検知する機能を持たないことが多く、担当者が個別に記録しない限り、どちらの停止も反映されず古い状態のまま残る。営業担当がCRM上の顧客ステータスを見て連絡してしまい、すでに停止済みの顧客に再度アプローチしてしまう、という事故は、この記録の分断がそのまま原因になっている。
この分断に対して、まず現状把握から始めるのが現実的な進め方である。3つのシステムそれぞれで「停止」として扱われている顧客数を一度書き出し、重複や矛盾がどの程度あるかを目視で確認するだけでも、どの経路の連携が特に弱いかが見えてくる。全件突合を一度に行う必要はなく、直近数か月分のサンプルで傾向をつかむところから始めれば十分である。
配信停止請求と利用停止請求は別の請求権
結論として、配信停止請求と利用停止請求は、対象となるデータも、請求の要件も異なる別の権利である。この違いを理解していないと、どちらか一方への対応で済ませてしまい、もう一方の請求に対応できなくなる。
| 請求の種類 | 根拠法 | 対象 | 要件 |
|---|---|---|---|
| 配信停止請求 | 特定電子メール法 | メルマガ送信のみ | 意思表示があれば送信を禁止 |
| 利用停止・第三者提供停止請求 | 個人情報保護法第35条 | 保有個人データ全般 | 違法取得・利用等の要件を満たす場合に請求可能 |
配信停止請求（特定電子メール法）の範囲
配信停止請求の対象はメルマガ送信のみであり、意思に反した送信を禁止する規定である。総務省の解説ページでは、受信拒否の通知を受けた送信者が、その後も広告・宣伝のメールを送信した場合に法令違反となる構成が説明されている。この請求は、個人情報の取得経路や利用目的の適法性そのものを問うものではなく、「配信を止めてほしい」という意思表示に対する直接的な対応義務である。配信停止請求は意思表示のみで成立するため、窓口担当者が個人情報保護法上の要件を判断する必要はなく、受け付けた時点で速やかに停止処理へ進めることができる。この「判断不要・即時対応」という性質こそが、次に述べる利用停止請求との最大の違いである。
利用停止・第三者提供停止請求（個人情報保護法第35条）の範囲
個人情報保護法第35条に基づく利用停止・第三者提供停止請求は、対象が保有個人データ全般に及ぶ点で配信停止請求より広い。この請求は、違法取得・利用等を要件に請求できるものであり、単に「メールを止めてほしい」という意思表示だけでは成立しない。顧客から「情報を消してほしい」「第三者に渡さないでほしい」という申し出があった場合は、配信停止の手続きとは別に、個人情報保護法上の要件を確認したうえで対応する必要がある。両者を同じ窓口・同じ手順で処理してしまうと、本来は個人情報保護法の要件確認が必要な請求を、単純な配信停止操作だけで済ませてしまう誤りが生じやすい。
窓口担当者が両者の違いを即座に判断できない場合は、まず配信停止として即時対応したうえで、利用停止請求に該当する可能性がある申し出かどうかを法務担当や代表に確認する、という二段階の運用にしておくと安全である。配信停止の即時対応を怠らないことと、個人情報保護法上の要件確認を省略しないことは、どちらも欠かせない。
この二段階運用を機能させるには、一次受付の窓口担当者に「配信停止はすぐに処理してよいが、情報の削除や第三者提供の停止に関する申し出は必ず上位者に確認する」という判断基準を、研修やマニュアルの形で明示しておく必要がある。基準が担当者の個人的な判断に委ねられていると、繁忙期に確認が後回しになり、対応漏れにつながりやすい。
再登録を扱うときの判断基準
結論として、再登録は、別の同意として記録する必要がある。停止した経緯を消さずに残したうえで、再登録を扱う基準を以下に整理する。
- 停止履歴を削除せず保持する：過去の経緯を残したまま新しい同意を記録する。
- 再登録時点を新しい同意として記録する：再登録を、別の新しい同意として扱う。
- 過去の停止理由が解消されたかを確認する：理由を確認せずに再登録だけ受け付けない。
- 再登録後も一定期間フォローする：再発防止のため配信状況を見ておく。
停止履歴を消さずに新しい同意を記録する理由
再登録の際に過去の停止履歴を削除してしまうと、同じ顧客が将来再び停止を申し出たときに、過去の経緯との整合性が取れなくなる。停止履歴を削除せず保持することで、再登録時点を新しい同意として記録し、別の同意として扱う、という前提を維持できる。これは、後から「いつ、どういう経緯で同意したか」を説明できる状態を保つという意味でも重要である。
記録の形式は、停止と再登録を1つの履行テーブルに時系列で並べる方式が分かりやすい。「2026年6月1日：許諾（フォーム）」「2026年9月1日：停止（配信停止リンク）」「2026年11月1日：再登録（キャンペーン参加フォーム）」というように、状態・日付・経路の3項目を並べておけば、担当者が変わっても同じ基準で経緯を追える。既存のCRMに専用の履歴機能がない場合は、顧客レコードに紐づく自由記述欄やメモ機能を使って代替することもできる。
停止理由が解消されたかを確認する運用
停止の理由が「配信頻度が多すぎる」「内容が合わない」といったものであれば、再登録を受け付けても同じ理由で再び停止される可能性が高い。過去の停止理由が解消されたかを確認する手順を設けず、再登録フォームだけを用意して受け付けてしまうと、同じ問題が繰り返される。再登録後も一定期間フォローし、配信状況を見ておくことで、再発を早期に検知できる。
確認の方法は大掛かりな仕組みでなくてよい。再登録フォームに「以前の配信を停止した理由に心当たりがあれば教えてください」という任意項目を設けるだけでも、担当者が再発防止のための手がかりを得られる。確認した内容は、停止履歴と同じ記録に残しておき、次に同じ顧客が再び停止を申し出た際に参照できる状態にしておくことが望ましい。
複数システム間の停止状態を同期する実務設計
結論として、複数システム間の同期は、マスターリストの所在・反映頻度・反映ラグ・検知の仕組みの4点を先に決めてから運用に乗せる必要がある。
- マスターリストの置き場所を1つに決める：どのシステムを正とするかを先に決める。
- 各システムからマスターへの反映頻度を決める：反映の間隔を関係者で明文化する。
- マスターから各システムへの反映頻度を決める：逆方向の反映も同じ基準で決める。
- 反映ラグが生じる時間帯を明文化する：ラグ中に送信しない運用を決めておく。
- 同期エラー時の検知・通知の仕組みを用意する：ズレに気づく仕組みを先に用意する。
マスターリストをどこに置くか
複数システムを同期する際にまず決めるべきは、マスターリストの置き場所を1つに決めることである。どのシステムを正とするかを先に決めておかないと、配信システムとCRMのどちらの状態を信用すべきか、現場で判断が割れる。多くの場合、CRM・顧客DBをマスターとし、配信システムやLINE公式アカウント側の状態をそこに集約する設計が運用しやすいが、どちらを選ぶかは既存の業務フローに依存するため、一律の正解はない。
マスターを決める際の判断材料としては、どのシステムが最も頻繁に更新されるか、どの部署が停止対応の一次受付を担っているか、という2点を確認するとよい。配信停止の申し出を主にカスタマーサポートが受けており、サポート部署がCRMを日常的に使っているなら、CRMをマスターにするのが自然である。逆に配信システム側で停止処理を直接受け付ける運用になっているなら、配信システムをマスターにしたほうが反映の手間が少ない。
反映頻度とラグを明文化する
各システムからマスターへの反映頻度、マスターから各システムへの反映頻度は、それぞれ別の基準で決める必要がある。反映ラグが生じる時間帯を明文化することで、ラグ中に送信しない運用を決めておくことができる。さらに、同期エラー時の検知・通知の仕組みを用意しておけば、ズレに気づく仕組みを先に用意することになり、各システムの停止記録に食い違いが生じたまま長期間放置される事態を防げる。これらは一度決めて終わりではなく、配信システムやCRMを乗り換えるたびに見直す必要がある運用ルールである。
運用を始めた直後は、月1回程度の頻度で3システムの停止件数を突合し、想定外のズレが生じていないかを確認するとよい。問題がなければ確認頻度を落としてよいが、配信システムやCRMの乗り換え、担当者の異動といった変化があったタイミングでは、その都度突合の頻度を一時的に戻すことを運用ルールに含めておくと、変化点での事故を防ぎやすい。
突合の作業自体は、3システムからそれぞれ「停止」としてマークされている顧客のメールアドレス一覧を書き出し、表計算ソフト上でVLOOKUPなどの関数を使って一致・不一致を確認する、という簡易な方法で十分に始められる。専用の統合ツールを導入してからでないと着手できないわけではなく、まずは手作業での突合で分断の実態を把握し、ズレの規模が大きいと分かった段階で自動化の投資を検討するという順序のほうが、過剰な初期投資を避けられる。
まとめ
許諾・停止・撤回・再登録という4つの状態を区別し、受信拒否から反映までのタイムラグを運用に組み込み、配信システム・LINE・CRMという3つのシステムがそれぞれ別の停止記録を持つことを前提に同期設計を行う。配信停止請求と利用停止請求は別の請求権であることを理解し、再登録時には過去の履歴を消さずに新しい同意として記録する。これらを一つの状態遷移の設計として整理しておくことで、法令対応と顧客対応の両方を安定して進められる。
どの企業も最初から完璧な同期の仕組みを持っているわけではない。まずは自社の配信システム・LINE・CRMの3つで、停止として扱われている顧客の数と最終更新日を書き出し、どこにどれだけのズレがあるかを把握することから始めればよい。状態の定義とマスターの所在を決めるという最初の一歩から、法令対応と顧客体験の両方を安定して進められるようになる。
自社の配信許諾・停止の管理フローを見直したい場合や、複数システム間の同期設計について相談したい場合は、お問い合わせはこちらからご連絡いただきたい。問い合わせへの入り口は本文中に一箇所だけ置いた構成にしている。
よくある質問
Q. 配信停止と退会（会員解除）は同じ扱いでよいですか。
A. 同じではない。配信停止はメルマガの送信を止める意思表示であり、会員資格や保有個人データの扱いには直接影響しない。退会・会員解除は別の手続きとして扱い、必要に応じて利用停止請求の枠組みで対応する。
Q. LINEをブロックされた顧客には、メール配信も止めるべきですか。
A. 法律上は、メールの配信停止とLINEのブロックは別々の意思表示として扱われるため、自動的に連動させる義務はない。ただし、顧客体験としてはちぐはぐな印象を与えるため、社内ルールとしてLINEブロックをメール配信の見直しシグナルとして扱う運用は検討に値する。
Q. 停止済みの顧客が別のキャンペーンに新規登録した場合、過去の停止は無効になりますか。
A. 無効にはならない。再登録時点を新しい同意として記録しつつ、過去の停止履歴は保持する。別キャンペーンへの新規登録であっても、過去に同じ経路で停止した経緯がある場合は、その理由が解消されているかを確認したうえで配信を再開するのが安全である。
Q. 反映のタイムラグ中に誤って配信してしまった場合、どう扱われますか。
A. 受信拒否の意思表示があった後に送信した事実自体が問題になり得るため、タイムラグを理由に免責されるとは限らない。反映ラグが生じる時間帯を明文化し、ラグ中は該当リストへの配信を止める運用ルールを事前に決めておくことが、事故を防ぐ実務上の対応になる。
Q. 停止記録を複数システムで同期する場合、どのシステムをマスターにすべきですか。
A. 一律の正解はない。配信頻度や運用体制によって、CRMをマスターにする場合もあれば、配信システムをマスターにする場合もある。重要なのは、マスターリストの置き場所を1つに決め、反映頻度とラグを関係者間で明文化しておくことである。
Q. 複数システムの同期を一度にすべて整備する余裕がない場合、どこから着手すべきですか。
A. まずは3つのシステムそれぞれの停止件数を書き出し、ズレの大きさを把握するところから始めるのが現実的である。ズレが最も大きい連携（多くの場合、配信システムとCRMの間）から優先的に反映ルールを明文化し、残りは段階的に整備していく進め方でよい。一度に完璧な仕組みを作るよりも、現状把握と優先順位付けを先に行うほうが、実務上は着手しやすい。
Q. 停止の履歴は、いつまで・どの程度残しておけばよいですか。
A. 一律の保存期間が法令で定められているわけではないが、再登録時の確認や、将来の問い合わせ対応に備えて、少なくとも数年単位で履歴を残しておくのが実務上安全である。履歴を削除する場合は、削除の基準（例えば「退会から5年経過」など）を社内規程として明文化し、場当たり的に古いレコードを消さないようにしておくことが望ましい。
Q. 配信システム・LINE・CRMのうち、どれを先に導入している企業が多いですか。
A. 企業の規模や業種によって異なるが、まずメール配信ツールを導入し、その後に顧客対応チャネルとしてLINE公式アカウントを追加し、最後に顧客情報を一元管理するためにCRMを導入する、という順序をたどる中小企業が多い。この順序で導入すると、CRM導入時点で既に配信システムとLINEにそれぞれ停止記録が蓄積されているため、CRM導入のタイミングこそが、3システム間の同期設計を見直す好機になる。
参考資料
- 総務省「特定電子メール法」解説（総務省）：受信拒否の通知と、その後の送信禁止の構成を確認。2026年10月4日閲覧。
- 個人情報の保護に関する法律（個人情報保護法）第35条（日本法令外国語訳データベースシステム）：利用停止・第三者提供停止請求の対象と要件を確認。2026年10月4日閲覧。
- LINEヤフー for Business「配信停止・ブロック」関連情報（LY Corporation）：LINE公式アカウントの配信停止・ブロックの仕組みが、メール配信とは別個の管理になっていることを確認。2026年10月4日閲覧。
- CF支援者データの同意範囲をどう管理するか（当サイト関連記事）：クラウドファンディング支援者データの同意範囲という、取得経路に着目した別テーマを扱っている。
- LINE・メールのチャネル冗長化をどう設計するか（当サイト関連記事）：配信チャネルの冗長化という、本稿とは異なる観点からCRM運用を扱っている。本稿で扱う停止状態の同期設計と合わせて読むことで、チャネル構成全体の設計を検討しやすくなる。
