【第532回】 Marketing Cloud Next ： MC Engagement との同意マッピング
Marketing Cloud Next Growth & Advanced Editions の Summer '26 新機能リリース では、Marketing Cloud Engagement の標準リストやパブリケーションリストの同意情報を Marketing Cloud Next の「コミュニケーション購読」に同期できるようになりました。
Marketing Cloud Engagement の標準リストやパブリケーションリストをマッピングすると、購読者が同意を更新するたびに、相互でステータスが自動的に同期されます。
今回、標準リストも利用できますが、私の方でそれを利用していくイメージが湧かないので、パブリケーションリストの利用を例にしています。
設定方法
1. 通常、Marketing Cloud Next 導入時には、Marketing Cloud Engagement の組織をすでに運用中である場合が多く、下記のようにパブリケーションリストを運用している場合があります。
Marketing Cloud Engagement にパブリケーションリストが存在していない場合は、Marketing Cloud Engagement 内に「All Subscribers (Publication Lists)」のような ジェネラル な パブリケーションリスト を 1 つ作成して、それを活用していくような形がよろしいかと思います。
2. データとしては、購読者キー（Subscriber Key）ベースで、メールアドレスとステータスが管理されています。
3. Summer '26 の新機能リリースにより、「同意」タブに Consent Mapping が表示されるようになりました。Map Consent ボタンより同意マッピングされているコミュニケーション購読の作成を開始できます。
4. Marketing Cloud Engagement における標準リストやパブリケーションリストを選択します。ここで、すべての購読者リストは選択できません。
5. Marketing Cloud Next 側で作成される新しいコミュニケーション購読の名前を決めたら、Map Consent をクリックして、作成を開始します。
※ コミュニケーション購読の名前は後からでも変更可能です。
6. マッピングが開始されて Syncing のステータスになります。
7. 10 分～ 20 分待つと、Active のステータスになるので利用開始ができます。
考慮事項
一見すると単純な同期機能に見えますが、実際に検証してみると、両製品の設計思想の違いから理解しておくべき重要な仕様が数多く存在しました。
今回は、実際に検証した内容をまとめます。
既存のコミュニケーション購読は使えない
まず確認したかったのは、既存のコミュニケーション購読と標準リストやパブリケーションリストを紐付けられるのかという点です。
結論から言うと、これはできません。
同期を有効化すると、標準リストやパブリケーションリストごとに、新しい「コミュニケーション購読」が自動的に作成されます。
この仕様は一見不便に見えますが、実は合理的です。
もし既存のコミュニケーション購読にマッピングされてしまうと、
これまでのリスト側の購読状態を正とするのか、
これまでのコミュニケーション購読側の購読状態を正とするのか、
という問題が発生します。
この競合を避けるため、新しいコミュニケーション購読を作成する設計を採用しているものと思われます。
よって、すでに何らかのコミュニケーション購読を運用を開始している環境では、何らかの工夫が必要です。
同期は非常に高速
同期自体は API ベースで行われています。
標準リストやパブリケーションリストの状態が変更されると、数秒で Marketing Cloud Next 側へ反映されました。
ただし、Communication Subscription Consent DMO の反映には時間差があり、実際に確認できるようになるまで 5～10 分程度待つ必要があります。
データストリーム連携などは関係ない
この検証前は、「データストリームの同期を待つ必要があるのではないか」などと余計な考えていましたが、実際には違いました。
メールアドレスや購読のステータスは API によって直接参照されており、
データストリーム
その後の DLO / DMO
などには依存していません。
初回同期時の挙動
同期完了後に Communication Subscription Consent DMO を確認すると興味深い挙動が見られました。
標準リストやパブリケーションリスト上で Active・Bounced・Held のステータスの購読者のみが Communication Subscription Consent に OPT_IN のレコードが作成され、Unsubscribed の購読者についてはレコードが作成されませんでした。
これは Marketing Cloud Next が推定オプトアウト（Implicit Opt-Out）の考え方を採用しているためと思われます。
つまり、「初回分は、同意している人だけを保持し、同意していない人のために不要なレコードは作らない」という考え方です。
パブリケーションリストの更新の挙動
Marketing Cloud Next 側で Communication Subscription の状態を変更した場合、Marketing Cloud Engagement 側にも反映されます。
例えば、OPT_OUT から OPT_IN に変更すると、
未登録であれば、パブリケーションリストに追加され、
既に存在する場合は、パブリケーションリストの状態が更新されます。
つまり、Marketing Cloud Next 側の同意状態が Marketing Cloud Engagement 側にも同期されます。
注意：すべての購読者でメールアドレスが見つからない場合は、自動的にメールアドレスを購読者キーとした購読者が作成されます。よって、すべての購読者へのデータインポートの前に、Marketing Cloud Next 側で先に同意をインポートしてしまうと、不要な課金対象連絡先が登録されてしまいますので、処理の順番をしっかりと考慮する必要がありそうです。
重要な前提：MCE と MCN は識別子が違う
この機能を理解する上で最も重要なポイントです。
Marketing Cloud Engagement は「購読者キー」ベースで管理であり、
一方で、Marketing Cloud Next は「メールアドレス」ベースで管理です。
つまり、同期時には必ず両者を変換する処理が発生します。
この設計の違いが、後述する挙動の原因になっています。
MCN → MCE の同期で起きること
Marketing Cloud Next はメールアドレス単位で同意を管理します。
そのため、コミュニケーション購読を更新すると、そのメールアドレスを持つ購読者がパブリケーションリストに反映されます。
ここで問題になるのが、同じメールアドレスを持つ Subscriber Key が複数存在するケースです。
結果から言うと、どれか 1 名分だけが追加・更新の対象になります。
どの購読者が更新対象になるのか調べましたが、挙動を見る限りでは、
パブリケーションリストに最後に追加された購読者のみ
が採用されているようにも見えますが、公式な情報はありません。
したがって、Marketing Cloud Engagement 内で、同じメールアドレスを複数の Subscriber Key で管理している環境では十分な検証が必要です。
MCE → MCN の同期で起きること
MCE → MCN の同期では、購読者キーは利用されず、メールアドレスのみが利用されます。
パブリケーションリストに変更が起こると、その購読者が保持するメールアドレスベースで、Marketing Cloud Next に反映しに行きます。
こちらでも似たような問題は発生します。
こちらの場合は、該当のメールアドレスを利用されている方、すべてが送信できなくなりますので、注意が必要です。
すべての購読者が最優先される
Marketing Cloud Engagement ではパブリケーションリストよりも、すべての購読者のステータスが優先される仕様があります。
そのため、Marketing Cloud Next で OPT_OUT から OPT_IN に変更して、パブリケーションリストを Active にするよう連携されてきたとしても、すべての購読者リストで Unsubscribed であれば、処理されません。
最も危険な挙動
今回の検証で最も驚いたのがここでした。
すべての購読者の状態を Active から Unsubscribed に変更するとどうなるのか。
結果として、そのメールアドレスに紐付く Marketing Cloud Next 上のコミュニケーション購読がすべて OPT_OUT になりました。
ここまでは理解できます。
しかしさらに確認すると、
パブリケーションリスト同期によって作成されたコミュニケーション購読だけではなく、Marketing Cloud Engagement と同期していないコミュニケーション購読まで OPT_OUT になっていました。
つまり、MCE 側で実施したユニバーサル購読取り消しが、MCN 側のすべてのコミュニケーション購読に影響を与える可能性があります。
これは非常に重要なポイントです。
この機能を有効化した時点で、MCE と直接関係のないコミュニケーション購読にまで影響が及ぶ可能性があります。
運用設計時には必ず考慮する必要があります。
なぜそうなるのか
おそらく、これは不具合ではありません。
すべての購読者の Active → Unsubscribed は、ユニバーサル購読取り消し（Universal Unsubscribe）を意味します。
つまり、
「このメールアドレスに対しては今後メールを送信しない」
という意思表示です。
そのため Marketing Cloud Next 側でも、すべてのコミュニケーション購読が OPT_OUT になるのは理屈としては、正しい動作です。
逆方向は復元されない
では、すべての購読者のステータスを
Unsubscribed → Active に戻したらどうなるのでしょうか。
こちらも検証しましたが、結果として何も起きません。
コミュニケーション購読は自動的に OPT_IN に戻りません。
パブリケーションリストのステータスも Active にはなりません。
これは Salesforce の考え方として、
ユニバーサル購読取り消し機能は存在するが、
ユニバーサル再購読機能という概念は存在しない
ためです。
すべての購読者のステータスを Active に戻しただけでは、
「再びメールを受信することに同意した」とはみなされません。
パブリケーションリストの再アクティブ化は別途行う必要があります。
注意：パブリケーションリストの仕組み上、パブリケーションリストの再アクティブ化をするには、すべての購読者のステータスを「購読取り消し」から「アクティブ」に変更しておく必要があります。
いかがでしたでしょうか。
この同意同期機能は、多くのユーザーから待ち望まれていた機能であることは間違いありません。設定自体は非常にシンプルですが、実際に検証してみると、その後の運用には想像以上に考慮すべきポイントがあることが分かりました。
特に、同じメールアドレスを複数の購読者キーで管理している環境では注意が必要です。Marketing Cloud Next と Marketing Cloud Engagement では識別子の考え方が異なるため、期待どおりに同期されない可能性があります。該当する環境では、事前に十分な検証を行うことをお勧めします。
また、今回の検証で特に重要だと感じたのは、すべての購読者のステータス変更の影響範囲です。ユニバーサル購読取り消しとして扱われるため、Marketing Cloud Engagement と直接同期していないコミュニケーション購読まで影響を受ける可能性があります。
とは言え、Marketing Cloud Next と Marketing Cloud Engagement 間で同意を統合できる価値は非常に大きく、今後の標準的な運用の一つになっていくでしょう。
同意管理の一元化を検討されている方は、まずは検証環境で挙動を十分に確認したうえで、ぜひ活用してみてください。
今回は以上です。
