【第245回】 Marketing Cloud Next ： 同意データの管理と運用ガイド
Marketing Cloud Next Growth & Advanced Editions を利用するうえで、最も重要な仕組みの一つが 同意（Consent）管理 です。
Marketing Cloud Engagement では、基本的に購読者は配信可能な状態からスタートし、購読解除（オプトアウト）を管理するケースが一般的でした。
一方、Marketing Cloud Next では考え方が大きく異なり、配信には事前の同意（オプトイン）が必要になります。
CRM に顧客データが登録されているだけではメールを送信できず、対象となるチャネルや用途に対して同意が存在している必要があります。
今回は、Marketing Cloud Next における同意管理の基本的な考え方から、Communication Subscription、Data Cloud 上の同意データ、プリファレンスセンター、CSV インポート、Flow による自動化、さらに運用時の注意点まで、全体像を整理してご紹介します。
Marketing Cloud Next の同意管理とは
Marketing Cloud Next では、メールや SMS などを送信するために、対象者から事前に同意を取得しておく必要があります。
Marketing Cloud Engagement と Marketing Cloud Next では、この配信可否の考え方が大きく異なります。
Marketing Cloud Engagement
基本的に購読者は配信可能な状態で登録される
配信停止は購読解除や独自のフラグなどで管理するケースが多い
Marketing Cloud Next
CRM に顧客を登録しただけでは送信できない
同意（オプトイン）が作成されて初めて配信可能になる
同意が存在しない場合は配信対象にならない
この違いは、Marketing Cloud Next を設計するうえで非常に重要です。
そして、この同意を管理する中心的な仕組みが Communication Subscription（コミュニケーション登録） です。
Communication Subscription で同意を管理
Marketing Cloud Next では、「Communication Subscription（コミュニケーション登録）」を利用して同意を管理します。
対応している主なチャネルは次のとおりです。
メール（標準）
SMS（追加ライセンス）
WhatsApp（追加ライセンス）
Communication Subscription は複数作成できます。
例えば、
製品アップデート
週刊ニュースレター
セミナー情報
のように、用途ごとに別々の Communication Subscription を作成できます。
これは Marketing Cloud Engagement における Publication List（パブリケーションリスト） に近い考え方です。
つまり、単純に「この顧客はメールを受け取るか、受け取らないか」という一つの状態だけを管理するのではなく、
どの種類のコミュニケーションに対して同意しているのか
を Communication Subscription ごとに管理できます。
そのため、Marketing Cloud Next を導入する際は、
どのような Communication Subscription を作成するのか
どの用途ごとに同意を分けるのか
を最初に整理しておくことが重要です。
同意データは Data Cloud で管理される
では、Communication Subscription に対する同意情報は、実際にはどこに保存されているのでしょうか。
Marketing Cloud Next の同意データは、Data Cloud のデータモデルオブジェクト（DMO）を中心に管理されます。
主に利用されるオブジェクトは次のとおりです。
Communication Subscription（DMO）
Engagement Channel Type（DMO）
Communication Subscription Channel Type（DMO）
Communication Subscription Consent（DMO）
この中でも特に重要なのが Communication Subscription Consent です。
ここに、対象のメールアドレスや電話番号が Communication Subscription に対してオプトインしているか、オプトアウトしているかといった同意状態が記録されます。
また、同意の変更履歴については、
ConsentAuditTrail-ConsentAuditTrail（DLO）
で確認できます。
オプトインやオプトアウトがいつ行われたのかを年月日時分単位で確認できるため、監査用途でも利用できます。
同意はメールアドレス・電話番号単位で管理
Marketing Cloud Next の同意管理でもう一つ重要なのが、同意の管理単位です。
同意は単純に Contact ID や Lead ID といった個人 ID だけで管理されるのではなく、
メールアドレス
電話番号
などの 連絡先単位で管理 されます。
そのため、例えば同じ顧客であってもメールアドレスを変更した場合、新しいメールアドレスに対して必要な同意を改めて作成する必要があります。
CRM 上では同一人物であっても、
旧メールアドレス
と
新メールアドレス
では、同意の対象となる連絡先が異なる点に注意が必要です。
CRM の Email Opt Out とは別の仕組み
Marketing Cloud Next の同意データは Data Cloud 上で管理されるため、Salesforce CRM の
Email Opt Out
とは別の仕組みです。
Marketing Cloud Next 側でオプトアウトしても、CRM の Email Opt Out が自動的に更新されるわけではありません。
逆に、CRM 側で Email Opt Out を変更した場合も、Marketing Cloud Next の同意状態が自動的に変更されるわけではありません。
そのため、CRM 側でも独自に同意情報を管理している場合は、
どちらを正とするのか
どのタイミングで連携するのか
必要に応じてどのように同期するのか
をあらかじめ整理しておく必要があります。
Communication Subscription を設定する
ここまでが Marketing Cloud Next における同意管理の基本的な仕組みです。
ここからは、実際に Communication Subscription を設定し、同意を管理する方法を確認していきます。
まず、アプリランチャーから「マーケティング」を開きます。
「同意」タブから「プリファレンスページと登録」を選択します。
ここでは、以下のような設定を行います。
Communication Subscription の作成
プリファレンスセンターの編集
プリファレンスセンターに公開する登録の選択
Communication Subscription を作成したら、実際の顧客の同意状態をいくつかの方法で管理できます。
代表的なのが、
プリファレンスセンター
CRM
CSV インポート
Flow
です。
順番に確認していきます。
プリファレンスセンターから同意を管理する
顧客自身が同意状態を変更する代表的な方法が プリファレンスセンター です。
利用者は各 Communication Subscription ごとに、
オプトイン
オプトアウト
を自由に切り替えることができます。
例えば、
製品アップデートは受け取りたい
セミナー情報は受け取りたくない
週刊ニュースレターは受け取りたい
といった形で、用途ごとに同意を分けて管理できます。
Spring '26 からは カスタムプリファレンスセンター も利用できるようになり、ブランドカラーや説明文などをより柔軟に変更できるようになりました。
メールから購読を解除する
プリファレンスセンター以外にも、メール内の 購読取り消しリンク からオプトアウトさせることができます。
Marketing Cloud Next では「$link.EmailAddressOptOutUrl」を利用して購読取り消しリンクを設定できます。
受信者が本番メールのリンクから購読を解除すると、そのメール送信に使用された特定の Communication Subscription に対する同意がオプトアウトに更新されます。
そのため、複数の Communication Subscription が存在する場合でも、他の Communication Subscription まで一括してオプトアウトされるわけではありません。
List-Unsubscribe ヘッダー について
また、Promotional メールには List-Unsubscribe ヘッダーも付与されます。
Gmail などのメールサービスでは、この情報を利用して受信トレイ上に「購読解除」などの操作が表示される場合があります。
List-Unsubscribe から実行された購読解除は Email Engagement DMO にも記録され、Source には「CLIENT_HEADER」が記録されます。
なお、List-Unsubscribe ヘッダーが存在していても、メールクライアント上に購読解除ボタンが必ず表示されるわけではありません。表示の有無は各メールサービス側で判断されます。
CRM から同意を管理する
顧客自身がプリファレンスセンターから変更するだけでなく、Salesforce CRM のレコード画面から同意状態を確認・変更することもできます。
取引先責任者、リード、プロスペクトなどのページに
Privacy Consent Status
コンポーネントを追加すると、現在の同意状況を確認できます。
さらに、メニューからオプトイン・オプトアウトを手動で変更することも可能です。
Spring '26 では個人取引先（Person Account）にも対応しました。
少数の顧客の同意状態を営業担当者やマーケティング担当者が個別に変更する場合は、この方法が便利です。
CSV で同意データを一括登録する
少数のレコードであれば CRM から手動で登録できますが、既存の顧客データをまとめて Marketing Cloud Next に移行する場合などは、一件ずつ登録するのは現実的ではありません。
その場合は、CSV を利用して同意データを一括登録できます。
「同意」タブから CSV を利用してインポートします。
必要となる主な情報は、
メールアドレス
日付
です。
日付は複数のフォーマットに対応しています。
yyyy-MM-dd HH:mm.SSSZ
MM/dd/yyyy HH:mm
MM/DD/YYYY
yyyy-MM-dd
M/DD/YYYY
例えば、
2026-07-08T00:00:00.000Z
でインポートすると、日本環境のデータエクスプローラーでは、
2026/7/8 09:00
として表示されます。
これは、データエクスプローラー上で UTC から JST に変換されて表示されるためです。
CSV インポート時の注意点
CSV インポートには、いくつか制約があります。
一度でインポートできるのは 50,000 レコードまで です。
⇒ それを超える大量インポートを行うときは Data Cloud トリガーフローが推奨されていますが、何度も手動インポートを繰り返すのものありです手動インポートは 50,000 レコードを約 2 分以内に登録します
検証エラーを含むインポートは、いつまでも「処理中」のままになることがあり、エラーのある行をスキップするオプションはありません。クリーンなファイルが必要です。
メールと SMS は同時にインポートできません
オプトインとオプトアウトは同時にインポートできません
複数の Communication Subscription を同時にインポートできません
同じ Communication Subscription の同じメールアドレスが既に存在する場合、現在登録されている日付より未来の日付でインポートした場合のみ更新され、それ以外は無視されます
つまり、
チャネル × Communication Subscription × 同意状態
ごとに CSV を分けて処理する必要があります。
メールアドレス形式の注意点
CSV インポート時には、メールアドレス形式のチェックも行われます。
エラーが発生した場合は、どのレコードが取り込めなかったのかを CSV 形式で確認できます。
例えば、以下のようなメールアドレスはエラーになります。
@ がない：abc999.gmail.com
@ が複数：abc999@@gmail.com
@ より前が空：@gmail.com
ドメインが空：abc999@
ローカル部の先頭がピリオド：.abc999@gmail.com
ローカル部の末尾がピリオド：abc999.@gmail.com
ピリオドが連続：abc..999@gmail.com
ドメインの先頭・末尾がピリオド：abc999@.gmail.com
ドメイン内でピリオドが連続：abc999@dd..com
ドメイン名の先頭・末尾がハイフン：abc999@-gmail.com
半角スペースを含む：abc 999@gmail.com
前後に空白がある： abc999@gmail.com
改行・タブなどの制御文字を含む：abc999↵@gmail.com
全角の ＠ を使用：abc999＠gmail.com
ドメイン部分がない：abc999@localhost
使用できない記号を含む：abc999,abc@gmail.com
ローカル部が長すぎる：@ より前が 64 文字超
アドレス全体が長すぎる：全体が 254 文字超
既存システムから大量の同意データを移行する場合は、事前にメールアドレス形式をチェックしておくとスムーズです。
Flow で同意管理を自動化する
CSV は初期移行や一括登録には便利ですが、日々発生する同意情報の更新を毎回 CSV で処理するのは現実的ではありません。
継続的な運用では、Flow を利用して同意レコードを自動作成・更新できます。
現在は、以下の 4 つのフローが対応しています。
Summer '25 で Data Cloud Triggered Flow に対応
Spring '26 で Event-Triggered Flow にも対応
Summer '26 で On-Demand Flow にも対応
Winter '27 で Record-Triggered Flow にも対応
例えば、Data Cloud Triggered Flow を利用すれば、Data Cloud 上のレコード更新を契機として同意を作成できます。
また Event-Triggered Flow を利用すれば、CRM レコードなどの更新を契機として同意レコードを作成できます。
Web フォームでメール配信に同意した
CRM 上の同意フラグが変更された
外部システムから同意情報が連携された
といったタイミングで、Communication Subscription Consent を自動的に更新するような運用が可能です。
実装方法については別記事で詳しく紹介しています。
運用・検証時に知っておきたい注意点
ここまで、同意の仕組みと代表的な管理方法を確認しました。
最後に、実際に Marketing Cloud Next の同意管理を運用・検証する際に知っておきたい挙動をいくつか紹介します。
Data Cloud への反映にはタイムラグがある
同意を更新すると、バックエンド側のデータは更新されます。
一方で、その内容が Data Cloud のデータモデルオブジェクト（DMO）に反映されるまでには、わずかな同期時間が必要です。
この挙動はヘルプドキュメントにも記載されており、私が検証した限りでは、DMO に反映されるまでに おおよそ 2 ～ 5 分程度かかりました。
そのため、同意を更新した直後に DMO を確認しても、最新の状態がまだ表示されていない場合があります。
運用や検証を行う際は、この同期タイムラグを考慮しておくとよいでしょう。
Communication Subscription を削除すると同意データも削除される
Communication Subscription を削除すると、それに紐づく同意データも削除されます。
そのため、本番運用を開始した Communication Subscription は、安易に削除しない方がよいでしょう。
名称や運用方法を含め、できるだけ事前に設計したうえで長期的に利用することをおすすめします。
テスト送信時は実際の同意状態が考慮されない
テスト送信では、実際のオプトアウト状態は考慮されません。そのため、オプトアウト済みのユーザーをプレビューしている場合でもテスト送信は可能 です。
一方、テストメール内のプリファレンスセンターから購読解除を行うと、テスト送信先として指定したメールアドレスのうち、一番左側のメールアドレスに対して実際のオプトアウト処理が実行されます。
また、テストメールの購読取り消しリンク（$link.EmailAddressOptOutUrl）をクリックした場合は、実際の顧客に対するオプトアウトは行われません。
Communication Subscription Channel Type に「dummyCsctToken」が記録されるだけで、実際の顧客データには影響しません。
いかがでしたでしょうか。
Marketing Cloud Next の同意管理は、単純な「配信停止フラグ」ではなく、Communication Subscription ごとに、どの連絡先がどのコミュニケーションを受け取ることに同意しているのかを管理する仕組みになっています。
特に理解しておきたいポイントは次のとおりです。
Marketing Cloud Next では、配信前に同意が必要
Communication Subscription ごとに同意を分けて管理できる
同意データは Data Cloud 上で管理される
同意はメールアドレスや電話番号などの連絡先単位で管理される
Salesforce CRM の Email Opt Out とは別の仕組み
プリファレンスセンター、CRM、CSV、Flow など複数の方法で同意を管理できる
継続的な運用では Flow を利用して同意管理を自動化できる
Marketing Cloud Next の導入時には「どのコミュニケーション登録を作成するのか」「いつ同意を作成するのか」「CRM 側の同意情報とどのように連携するのか」をあらかじめ整理しておくことが、後々の運用を大きく左右します。
Marketing Cloud Engagement とは考え方が大きく異なる部分もありますが、仕組みを理解しておけば、より柔軟で適切な同意管理を実現できます。
今回は以上です。
