【第487回】 Marketing Cloud Next ： ID 解決で注意すべきポイント

Marketing Cloud Next Growth & Advanced Edition を利用するには、ID 解決によって生成される Unified Individual の活用が前提となりますが、ID 解決には、初心者ユーザーが特に注意すべきポイント がいくつか存在します。

Marketing Cloud Next のデフォルトのクレジット設計を踏まえると、企業規模に関わらず、開発初期の段階で十分な設計を行わない場合、意図しないフル更新によってクレジット消費が急激に増加するリスクがあります。

特に、数万件規模のプロファイルデータを扱う場合には、これらの対策は必須と言えるでしょう。

本記事では、初級の Marketing Cloud Next ユーザーに向けて、事前に理解しておくべき重要なポイントを整理していきます。

1. ID 解決で処理された数を確認する方法

1 日のうちに処理されたレコード数は、以下の「処理履歴」タブで確認できます。1 日に数回処理が行われた場合は、日別で数が積み上げられます。

例えば、1 日に 2 回処理された場合、それが 100 レコードと 500 レコードのときは、合計の 600 レコードが表示されます。こちらは、ID 解決の処理が終わるとすぐに集計され、表示されます。

2. 処理されたクレジットを確認する方法

続いて、クレジットを確認する方法ですが、以下の手順になります。

1. 「消費カード」タブを選択して、View Consumption Insights by Tags をクリックします。

2. 一番下までスクロールして、Consumption by Usage Type のセクションから「DataCloud_BatchProfileUnification」をクリックします。

3. すると、ID 解決に絞られた形のレポートに遷移しますので、Event Time を降順にします。

4. 各 ID 解決のクレジット消費量が Unites Consumed に表示されます。

※ 100 万レコードあたり約 10 万クレジットが消費されます。

5. 上記の例ですと、11.3 クレジットが消費されているので、1  日で 113 レコードが処理されたことが分かります。これは、1 で説明したレコード処理数と一致することが分かりますね。

考慮事項

• このレポートは 24 時間のうちに 1 度更新されます。よって確認できるのは翌日になる場合があります。

• また、Event Time は、ID 解決が完了したタイミングの時間ではなく、開始したタイミングの時間が表示されています。

3. ID 解決の基本的な実行方法

基本的に、ID 解決は以下のいずれかの方法で実行されます。

• 60 分 ～ 24 時間間隔での自動実行（自動化設定を有効にした場合のみ）

• 手動で実行（「ルールセットを実行」ボタンから実行）

• フローや API をトリガーとした実行

なお、フローによるスケジュールトリガーフローの設定方法については、別記事で解説しています。

※ いずれの実行方法であっても、前回の ID 解決時と比較して、各ソースプロファイル（Contact、Lead など）のレコードにおいて項目値の変更が一切ない場合は、ID 解決は実行されずスキップされます。

4. フル更新が発生する代表的な原因

以下のような変更を行った場合、次回の ID 解決の実行時に、データスペース内のソースプロファイル（Contact、Lead など）の全レコードが再処理対象となります。

• マッチルールで使用している DMO への追加 / 削除

• DMO に接続されている項目のマッピング変更

例えば、ソースプロファイル（Contact、Lead など）から新しい項目を Individual DMO に新規マッピングした場合、全件の再処理が発生します。

これは一見すると当然の挙動です。マッピングを追加しただけでは、Unified Individual に項目は作成されても、値そのものは自動的に反映されません。実際に値を反映させるためには、ID 解決による再処理が必要になります。

※この中でも特に分かりづらいのが「マッチルールで使用している項目」の考え方ですね。実際には、「Contact Point Address」をマッチルールで直接利用していない場合でも、例えば、そこにマッピングされているリードの「Last Modified Date」を削除たりすると、結果としてリードの全レコードが更新対象となるケースがあります。

この挙動の理解は非常に重要ですが、影響範囲を完全に把握するのは容易ではありません。そのため、「関連する可能性のある項目はすべて影響する」と前提に置き、設計や変更はまとめて実施することがベストプラクティスです。

特に避けるべきなのは、項目を 1 つマッピングするたびに ID 解決を実行し、また別の項目を追加して再度実行する、といった小刻みな実装です。
このような進め方は、意図しないフル更新を繰り返し、クレジット消費の増加につながるため注意が必要です。

5. 差分更新の仕組み

ここまではフル更新について説明しましたが、次に差分更新の仕組みについて整理します。通常のデータ更新は、以下の流れで処理されます。

1. CRM 側でレコードの更新が発生する

2. 更新をトリガーに、DSO / DLO 側で差分更新が行われる

3. 更新されたレコードのみが ID 解決の対象となる

つまり、ここで重要なのは、大元である
「どのレコードが CRM 側で更新されたと判定されるか」 になります。

※ 更新の判定は、値の見た目の変化ではなく、最終更新日時が変更されたかどうか によって決まります。
※ より正確には、SystemModStamp の変更 が検知基準となります。

• LastModifiedDate：人が変更した日時

• SystemModStamp：人 or システムが変更した日時

考慮事項

例えば、「誕生日を迎えて年齢が +1 される」ケースを考えてみます。

一見すると誕生日当日に更新が発生するように想像できますが、
年齢項目が 数式（Formula）で計算されている場合 は注意が必要です。

• 数式フィールドはデータとして保存されているわけではなく、表示時に計算されるだけです。

• そのため、CRM 側のレコード自体は更新されません。

その結果、

• 最終更新日時は変更されない

• 差分更新の対象にならない

• ID 解決も実行されない

という挙動になります。

そして、我々が特に見ておくべき数字は、以下のレコード数です。この数が、DSO / DLO で更新され、ID 解決の対象となるレコード数になります。

注意事項

データストリームの「今すぐ更新」ボタンを使用すると、一括更新（フルリフレッシュ）を実行することができます。開発初期であれば問題になりにくいですが、ID 解決の自動化後にこれを実行すると注意が必要です。

この処理では、既存レコードを一度すべて削除し、新規に再取り込みする挙動となるため、結果としてソースの全レコードが更新対象となります。

つまり、

• 差分ではなく全件更新となる

• ID 解決も全レコード分が実行される

という状態になります。

処理量・クレジット消費ともにインパクトが大きいため、実行タイミングには十分注意が必要です。

6. マッピングと変更検知の制約

これは Data Cloud（Data 360）の仕様として知っておくべきですが、

• ID 解決の DLO の変更検知は
  → DMO にマッピングされている項目のみ対象です。

• つまり、マッピングされていない項目の変更
  → ID 解決の対象外となります。

それであれば、データキットで設定されたマッピングから、SystemModStamp と LastModifiedDate を解除すれば更新にならないのでは？ と考えるのは正しいです。

しかしながら、2026 年 4 月時点 の Marketing Cloud Next においては、
セットアップ時にデータキットを起点として構築した場合、

環境は 管理パッケージベースの構成 となります。

この構成では、標準で設定されているマッピングを解除することはできません。実際に解除を試みると、以下のようなエラーが発生します。

よって、

• 「最終更新日時（LastModifiedDate）」は必ずマッピングされてしまう

• CRM 側で何かしらの変更があれば、必ず差分更新として検知される

という仕様になっているため、注意が必要です。

ここから言えることは、CRM 側での無駄な更新は抑える必要 があります。

特に「毎日、取引先責任者を全件更新」といった処理は、毎日 ID 解決でフルリフレッシュを行っているのと同じ意味になります。このような設計は、非常に危険なため、CRM 側の設定の見直しが必要です。

すでに CRM を動かしている環境であれば、現状がどのような更新状態であるかを、事前に以下の処理済みレコードの履歴で確認しておきましょう。

7. データスペースの考え方

Markerting Cloud Next では、このデータスペースを効率良く使うことが成功の鍵になります。

データスペースは、ビジネスユニットと言い換えることができますが、どのデータをあなたが扱うかを自由にフィルタリングできるようになっています。

そして、最大のポイントは ID 解決の処理対象は、データスペース内のレコードのみ という点です。

よって 例えば、

• DSO / DLO の元データ：10,000件

• データスペース内：3,000件（データスペースフィルタで数を絞れます）

この状態で、

• DLO の元データで 1,000 件の更新が入り、

• そのうち 100 件がデータスペース内に含まれていたとすると

→ ID 解決の処理対象は 100 件のみに限定されます。
これは、非常に効率的ですね。

実はこのようなテクニックは、以下の Salesforce のヘルプドキュメントにも書いてあります。

ID 解決コストの削減例

• Sandbox で、少数の代表的なデータを使用して 新しいルールセットをテストします。Sandbox がなく、複数のデータスペースがある場合は、データ量が少ないデータスペースでテストすることを検討してください。

8. データスペースフィルターの理解

データスペースフィルターの設定方法については、以前に以下の記事で解説しました。

ここで注意しておくべきは、データスペースにフィルターを設定した際、

• それが対象人数を減らす処理だとしても、

• 「削除する処理」自体であっても、ID 解決の処理数としてはカウント対象になる点です。

例：
フィルターなしで 10,000 レコードを持つデータスペースが
→ データスペースフィルターを設定して、3,000 件に絞った場合、

7,000 件分の削除処理が ID 解決の処理数としてカウントされてしまいます。

このため、開発初期の段階においては、最初からデータスペースフィルターを設定しておくことが大事になります。

データスペースフィルターの条件変更も、差分更新のトリガーになることを覚えておいてください。まあ、これも良く考えれば納得です。

9. クレジット消費のインパクト

さて、フル更新が発生すると、クレジット消費は非常に大きくなります。

試算例：

• 50,000 レコードの処理 → 5,000 クレジットが消費されます

これを Marketing Cloud Next の各エディションのデフォルト値で、換算してみましょう。取引先責任者が 50,000 レコードあるとします。

• Marketing Cloud Next Growth Edition の場合
  → デフォルトで 250,000 クレジット ⇒ 50 回ですべて消費される

• Marketing Cloud Next Advanced Edition の場合
  → デフォルトで 500,000 クレジット ⇒ 100 回ですべて消費される

仮に 1 日 1 回 フル更新が回ってしまったら、Growth Edition であれば、50 日分しかクレジットが持たなくなってしまうわけですね。

これは、結構切実であることを直感的にご理解頂けたかと思います。

開発初期の段階では、開発している環境が、いつまでの期限で、どのくらいクレジットを購入しているかということを、しっかりと、把握することが大切です。

10. 想定される危険な操作手順

以下のような流れは、非常に危険です。

• まず何も考えず、連携された 50,000 件で ID 解決を実施
  ⇒ 5,000クレジット消費

• Individual DMO に新しい項目を追加して、とりあえず 再度 ID 解決を実施
  ⇒ 5,000クレジット消費

• ルールセットが適当だったので正しく修正して、再度 ID 解決を実施
  ⇒ 5,000クレジット消費

たった、これだけで 15,000 クレジットが消費されます。
これは厳しいですね・・・。

11. 初期構築で必ずやるべきこと

初期フェーズでは、以下を徹底してください。

必須チェック

• ID 解決の自動更新 = オフ

• データストリームの自動一括更新の間隔 = None（更新なし）

テスト方針

• データスペースフィルターで事前に対象を絞る

• 約 1,000 件程度で検証するなど（なるべく偏りのない条件で）
  例：「住所が 〇〇 県の人」など

ID 解決の本格化までにやること

• CRM から DSO への連携項目を完全に決定して、連携させる

• DLO から DMO へのマッピングをすべて完了させる

• ルールセット（マッチルールと調整ルール）を完全に確定する

いかがでしたでしょうか。

今回の内容は、冒頭でもお伝えしている通り、初級の Marketing Cloud Next ユーザーが最初に押さえておくべきポイントを整理したものです。

そのため、エンタープライズ環境における Data 360 の運用では、これとは異なる設計思想や考慮事項が求められる場合がありますので、あらかじめその点をご理解のうえ、ご参照ください。

最後に、家訓のような形でおすすめの原則をまとめておきます。

ID 解決 家訓

• 最初から ID 解決の自動更新をオンにしてはならない

• データスペースフィルターを効果的に使うべし

• 最終更新日時のマッピングは外せないため、受け入れるべし

• DSO への項目連携は最初にすべてやりきるべし

• DMO へのマッピングもすべてやりきるべし

• ルールセットは完全に確定させてから実行すべし

• 運用開始後に DSO のフルリフレッシュは原則行ってはならない

今回は以上です。

次の記事はこちら

前回の記事はこちら

私の note のトップページはこちら