【第245回】 Marketing Cloud Next ： 同意データの管理と運用ガイド
Marketing Cloud Next Growth & Advanced Editions を利用するうえで、最も重要な仕組みの一つが 同意（Consent）管理 です。
Marketing Cloud Engagement では、基本的に購読者は配信可能な状態からスタートし、購読解除（オプトアウト）を管理するケースが一般的でした。一方、Marketing Cloud Next では考え方が大きく異なり、配信には事前の同意（オプトイン）が必要になります。
今回は、Marketing Cloud Next における同意管理の仕組みから設定方法、運用上の注意点、自動化まで、全体像を整理してご紹介します。
同意管理の仕組み
Marketing Cloud Next では、「コミュニケーション登録（Communication Subscription）」という仕組みを利用して同意を管理します。
対応しているチャネルは次のとおりです。
メール（標準）
SMS（追加ライセンス）
WhatsApp（追加ライセンス）
コミュニケーション登録は複数作成できます。
例えば、
製品アップデート
週刊ニュースレター
セミナー情報
のように、用途ごとに別々の登録を作成できます。
これは Marketing Cloud Engagement の「パブリケーションリスト」に近い考え方です。Marketing Cloud Next ではこの「コミュニケーション登録」を中心として同意が管理されます。
Marketing Cloud Engagement との違い
Marketing Cloud Engagement と Marketing Cloud Next では、配信可否の考え方が大きく異なります。
Marketing Cloud Engagement
基本的にすべての購読者が配信可能な状態で登録される
配信停止は独自のフラグや購読解除で管理するケースが多い
Marketing Cloud Next
CRM に登録しただけではメールは送信できない
同意（オプトイン）が作成されて初めて配信可能になる
同意が存在しない場合は配信対象にならない
この違いは、Marketing Cloud Next を設計するうえで最も重要なポイントの一つです。
同意データは Data Cloud で管理される
Marketing Cloud Next の同意データは、Data Cloud のデータモデルオブジェクト（DMO）で管理されます。
主に利用されるオブジェクトは次のとおりです。
Communication Subscription（DMO）
Engagement Channel Type（DMO）
Communication Subscription Channel Type（DMO）
Communication Subscription Consent（DMO）← 最も重要
また、変更履歴は
ConsentAuditTrail-ConsentAuditTrail（DLO）
で確認でき、オプトイン・オプトアウトがいつ行われたかを年月日時分単位で確認できるため、監査用途でも利用できます。
運用上の考慮事項
CRM の Email Opt Out とは別データ
Marketing Cloud Next の同意は、Data Cloud 上で管理されます。
そのため Salesforce CRM の
Email Opt Out
とは連動していません。
Marketing Cloud Next でオプトアウトしても CRM の Email Opt Out は更新されず、逆に CRM 側を変更しても Marketing Cloud Next の同意は自動では変更されません。
運用設計時には、この違いを理解しておくことが重要です。
メールアドレス単位で管理される
同意は個人 ID ではなく、
メールアドレス
電話番号
などの 連絡先単位で管理 されます。
そのためメールアドレスを変更した場合は、新しいメールアドレスに対して改めて同意レコードを作成する必要があります。
Data Cloud への反映にはタイムラグがある
同意を更新すると、バックエンドのデータは即座に更新されます。一方で、その内容が Data Cloud のデータモデルオブジェクト（DMO）に反映されるまでには、わずかな同期時間が必要です。
この挙動はヘルプドキュメントにも記載されており、私が検証した限りでは、DMO に反映されるまでに おおよそ 2 ～ 5 分程度かかりました。
そのため、同意を更新した直後に DMO を確認しても、最新の状態がまだ表示されていない場合があります。運用や検証を行う際は、この同期タイムラグを考慮しておくとよいでしょう。
コミュニケーション登録を削除する影響
コミュニケーション登録を削除すると、それに紐づく同意データも削除されます。
運用開始後は、できるだけ削除せず継続利用することをおすすめします。
コミュニケーション登録の設定
アプリランチャーから「マーケティング」を開きます。
「同意」タブから「プリファレンスページと登録」を選択します。
ここでは、
コミュニケーション登録の作成
プリファレンスセンターの編集
公開する登録の選択
などを行います。
プリファレンスセンター
標準のプリファレンスセンターでは、公開されているコミュニケーション登録が一覧表示されます。
利用者は各登録ごとに
オプトイン
オプトアウト
を自由に切り替えられます。
Spring '26 からは カスタムプリファレンスセンター が利用できるようになり、ブランドカラーや説明文なども自由に変更できるようになりました。
CRM から同意を管理する
プリファレンスセンター以外にも、CRM のレコード画面から同意を管理できます。
取引先責任者、リード、プロスペクトのページに
Privacy Consent Status
コンポーネントを追加すると、現在の同意状況を確認できます。
さらにメニューからオプトイン・オプトアウトを手動で変更することも可能です。
Spring '26 では個人取引先（Person Account）にも対応しました。
CSV による同意データのインポート
同意データは「同意」タブから CSV を利用して一括登録できます。
必要となる情報は
メールアドレス
日付
です。
日付は複数のフォーマットに対応しています。
yyyy-MM-dd HH:mm:ss.SSSZ
MM/dd/yyyy HH:mm:ss
MM/DD/YYYY
yyyy-MM-dd
M/DD/YYYY
例えば、
2026-07-08T00:00:00.000Z
でインポートすると、日本環境のデータエクスプローラーでは
2026/7/8 09:00
として 9 時間多く表示されます。
※ データエクスプローラーでは UTC から JST へ変換されるためです。
インポート時の注意点
メールと SMS は同時にインポートできません
オプトインとオプトアウトは同時にインポートできません
複数のコミュニケーション登録を同時にインポートできません
同じコミュニケーション登録の同じメールアドレスが既に存在する場合、現在登録されている日付より未来の日付でインポートした場合のみ更新され、それ以外は無視されます
また、以下のようなタイプのメールアドレスは、インポート時に取り込みエラーになります。エラー発生した場合は、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 文字超
テスト送信時の注意点
テスト送信では、実際のオプトアウト状態は考慮されません。
そのため、オプトアウト済みのユーザーをプレビューしていてもテスト送信は可能 です。
一方、テストメール内のプリファレンスセンターから購読解除を行うと、テスト送信先のメールアドレスのうち一番左側のメールアドレスに対して実際のオプトアウト処理が実行されます。
なお、「購読取り消し」リンクからの操作では実際のオプトアウトは行われません。
Communication Subscription Channel Type に「dummyCsctToken」が記録されるだけで、実際の顧客データには影響しません。
同意レコードの自動作成
現在はフローを利用して同意レコードを自動作成できます。
Summer '25 では Data Cloud Triggered Flow に対応し、Data Cloud のレコード更新を契機として同意を作成できるようになりました。
さらに Spring '26 では Event-Triggered Flow にも対応し、CRM レコードの更新を契機として同意レコードを作成できるようになりました。
実装方法については別記事で詳しく紹介しています。
いかがでしたでしょうか。
Marketing Cloud Next の同意管理は、メール配信の可否を決定する非常に重要な仕組みです。
特に理解しておきたいポイントは次の4点です。
同意は Salesforce CRM の Email Opt Out とは別に Data Cloud 上で管理される
同意は個人 ID ではなく、メールアドレスや電話番号単位で管理される
コミュニケーション登録を中心に運用する設計になっている
Event-Triggered Flow や Data Cloud Triggered Flow を利用して自動化することもできる
導入初期には、「どのコミュニケーション登録を作成するのか」「いつ同意を作成するのか」「CRM 側の同意情報とどのように連携するのか」をあらかじめ整理しておくことが、後々の運用を大きく左右します。
Marketing Cloud Engagement とは考え方が大きく異なる部分もありますが、仕組みを理解しておけば、より柔軟で適切な同意管理を実現できます。
今回は以上です。