【第616回】 Journey Builder のメールアクティビティ内の重複送信防止機能
Marketing Cloud Engagement における Winter '27 新機能リリース で、Journey Message Deduplication という新機能が追加されました。
注意： この機能は、ローリング方式でリリース されており、私が利用している Stack 12 では、2026 年 10 月 20 日から利用可能になりました。
設定画面に機能が表示されていても、実際にはまだ有効化されていない場合があります。必ず重複除外が正しく動作することを確認してから、利用を開始してください。
この機能を利用すると、Journey Builder の特定のメールアクティビティにおいて、同じメールアドレスへの重複送信を、指定した期間内で抑制できる ようになります。← これが結論です。💡
例えば、異なる Contact Key に同じメールアドレスが登録されている場合や、24 時間以内に同じメールアクティビティに繰り返し到達する場合でも、同じメールアドレスへ複数回送信されることを防げるので、複数のメールアドレスが混ざるような組織の場合は、SQL などを用いずに、気軽に重複除外することができるようになりました。
送信されなかった場合は、ソフトエラー として表示され、ジャーニーから強制的に退出することはありません。次のパスにそのまま進みます。
また、Journey History においては、Status Detail「Duplicate Suppressed」で記録されます。
設定方法
設定方法はとてもシンプルです。
Journey Builder の設定（歯車）を開き、Journey Message Deduplication を有効化して、重複送信を防止する期間を指定するだけです。
設定後、ジャーニーを有効化することで機能が適用されます。
設定項目は以下の 2 つです。
Deduplicate emails： メールの重複除外機能を有効化します。
Lookback Period： 重複送信を防止する期間を 1 ～ 24 時間の範囲で指定します。
数千万単位のマス配信の場合や STO を利用した送信の場合、メール送信処理は数時間に亘り行われる場合があります。その場合は、Lookback Period でちょうど良い時間を設定してください。
例えば、Lookback Period を 3 時間に設定した場合、過去 3 時間以内に同じメールアクティビティから同じメールアドレスへ送信されていれば、重複するメール送信がスキップされます。
では、実際にどの範囲まで、この重複除外が適用されるのでしょうか。
検証結果
今回、私が最も確認したかったのは、Journey Message Deduplication がMarketing Cloud Engagement の組織内において、どこまでの範囲で重複を除外してくれるのか という点でした。
同じメールアクティビティ内での重複送信はもちろん、異なるメールアクティビティや異なるジャーニー間でも重複除外されるのでしょうか。
そこで、Lookback Period を 3 時間に設定し、同じメールアドレスに対する送信がどのように処理されるのか、以下の 5 つのパターンで検証しました。
テスト①： 同じメールアクティビティ内での重複送信
テスト②： 同じメールアクティビティを繰り返し実行した場合
テスト③： 同じジャーニーバージョンの異なるメールアクティビティ間
テスト④： 同じジャーニーの異なるバージョン間
テスト⑤： 異なるジャーニー間
① 同じメールアクティビティ内での重複送信
まず、同じメールアクティビティに、同一のメールアドレスを持つ複数の Contact Key が到達した場合の動作を確認しました。
今回使用したデータエクステンションには、同じメールアドレスを持つ 3 件のレコードを、以下の順番で格納しています。
JBS01
JBS02
JBS03
検証の結果、3 件のうち 1 件にのみメールが送信され、残りの 2 件は重複除外されました。
ほとんどが、JBS01 が送信として記録されましたが、JBS02 が送信として記録された回もあったため、データエクステンションの一番上にあるレコードが必ず送信対象になるとは言い切れません。
② 同じメールアクティビティを繰り返し実行した場合
次に、同じジャーニーバージョン内で、同じメールアクティビティを定期的に実行した場合の動作を確認しました。
テスト①では 1 回の実行での重複除外を確認しましたが、今回は時間を空けて再度実行した場合にも、重複除外の効果が維持されるのかを検証します。
まず、1 回目の実行では、テスト①と同様に 3 件のうち 1 件だけが送信され、残りの 2 件は除外されました。
続いて、1 時間後に同じメールアクティビティを再度実行しました。
すると、2 回目は 3 件すべてが重複除外され、メールは 1 通も送信されませんでした。
つまり、同じメールアクティビティであれば、実行タイミングが異なっても Lookback Period 内の送信履歴が参照されることが確認できました。
③ 同じジャーニーバージョン内の異なるメールアクティビティ間
続いて、同じジャーニーバージョン内に配置された、異なるメールアクティビティ間でも重複除外されるのかを確認しました。
今回は、メールアクティビティの配置方法を変えて、2 つのパターンで検証しています。
① ランダム分岐で異なるメールアクティビティに振り分けた場合
まず、ランダム分岐を利用し、同じジャーニー内の異なるメールアクティビティから、同一のメールアドレスへ送信する構成を試しました。
検証の結果、メールアクティビティをまたいだ重複除外は行われず、それぞれのメールアクティビティから送信されました。
このことから、重複除外はジャーニー全体ではなく、メールアクティビティごとに判定されていると考えられます。
② 異なるメールアクティビティを直列に配置した場合
次に、1 つのジャーニー内で、複数のメールアクティビティを直列に配置した場合も確認しました。
こちらも、それぞれのメールアクティビティから 1 通ずつメールが送信されました。
つまり、同じジャーニーバージョン内であっても、異なるメールアクティビティ間では送信履歴が共有されず、重複除外の対象にはならないことが分かりました。
④ 同じジャーニーの異なるバージョン間
次に、同じジャーニーで新しいバージョンを作成した場合の動作を確認しました。
まず、バージョン 1 からメールを送信し、その後、新しいバージョン 2 を作成して、Lookback Period の 3 時間以内に同じメールアドレスへ送信しました。
検証の結果、バージョン 2 からもメールが送信され、重複除外は行われませんでした。
つまり、同じジャーニーであっても、バージョンが変わると別のメールアクティビティとして扱われ、過去のバージョンでの送信は重複除外の対象にならないことが確認できました。
⑤ 異なるジャーニー間での重複送信
最後に、全く異なる 2 つのジャーニー間での動作を確認しました。
ジャーニー A からメールを送信した後、Lookback Period の 3 時間以内に、ジャーニー B から同じメールアドレスへ送信しました。
結果は予想通り、異なるジャーニー間では重複除外されず、それぞれからメールが送信されました。
テスト④では、同じジャーニーの異なるバージョン間でも重複除外されなかったため、想定通りの結果ではありますが、念のため確認しました。
これで Journey Message Deduplication の重複除外は、同じジャーニーバージョンの同じメールアクティビティに限定されることが確認できました。
いかがでしたでしょうか。
今回の検証結果から、Journey Message Deduplication は、アカウント全体のメール送信数を制御する機能ではなく、同じジャーニーバージョン内の同じメールアクティビティで発生する重複送信を抑制する機能と捉えるのが適切だと思います。
例えば、同じメールアドレスを持つ複数の Contact Key が存在する場合や、同じメールアクティビティに繰り返し到達するようなシナリオでは、Lookback Period 内の重複送信を抑制できます。
一方、アカウント全体で顧客へのメール送信数や頻度を管理する、いわゆる プレッシャーコントロール（Frequency Capping）とは異なる機能です。異なるジャーニーやメールアクティビティを横断して、メールの送信数を一元的に制御するものではありません。
そのため、通常のジャーニー設計であれば、必ずしもこの機能を有効にする必要はなく、重複送信が発生する可能性のある特定のシナリオで活用する機能という位置付けになるかと思います。
とはいえ、これまで個別のデータ処理や設計上の工夫で対応していた重複送信の抑制を、Journey Builder の設定だけで実現できるようになったことは、大きなメリットです。
必要なシナリオでは、ぜひ今回の Journey Message Deduplication を活用してみてください。
今回は以上です。
