【第404回】 データエクステンションのデータ保持ポリシーまとめ
Marketing Cloud Engagement において、2025 年 11 月頃からデフォルトで有効化が選択されるようになった データ保持ポリシー に関しては、
「いつデータが消えるの？」
「Retention は設定したほうがいい？」
「データは過去分全部残しておくべき？」
と言った多くの疑問があると思います。
今回の記事では、データ保持ポリシーの基本仕様、注意点、運用のベストプラクティスをできるだけ分かりやすく整理します。
データ保持ポリシーとは
データエクステンションに保存されたデータを、Marketing Cloud 側が自動的に削除するための設定です。
設定すると以下のように動きます。
一定期間が過ぎた レコード を自動削除（全件・一部）
一定期間が過ぎた データエクステンション を レコード を含め自動削除
時間ベース（日単位）で管理
オートメーション設定不要で自動維持が可能
データ保持ポリシー を設定しない場合は、データは永続的に残ります。
データ保持ポリシーの設定方法
Email Studio / Contact Builder でのデータエクステンション作成時や、
Contact Builder のデータエクステンション編集画面で設定できます。
※ Email Studio のデータエクステンション編集画面では、データ保持ポリシーの設定はできません。Email Studio は作成時のみに限定されます。
また、作成済みのデータエクステンションにデータ保持ポリシーを追加して、「個別のレコードだけ削除」を選択できるのは、データエクステンションのレコード数が 10 億レコード未満の場合のみです。
設定内容は大きく以下の 2 つです。
削除対象の種類
① 個別のレコードごと削除
② DE 本体ごと、すべてのレコードを削除
③ すべてのレコードを削除
データの保持期間
「〇 日間保持」など日数・週数・月数・年数ベースで指定
削除する日をカレンダーで指定する（すべてのレコード削除の時のみ）
削除対象の種類として、
② DE 本体ごと、すべてのレコードを削除
③ すべてのレコードを削除
上記のオプションを選択した場合は、Contact Builder のデータエクステンションのプロパティに「削除予定日」（Next Scheduled Deprecation）が表示されますので、その日付以降に、すべてのレコードの削除されるものと思ってください。この日付は、データ保持ポリシーを「オン」にした日から起算した将来の日付が入る仕組みになっています。
削除スケジュールの仕組み
データ保持ポリシーによる削除は、設定した期間を過ぎた瞬間に「即時削除」されるわけではありません。
期間の経過後、最大 24 時間以内に Salesforce 側で非公開のスケジュールに基づき削除プロセスが開始されます。
この削除プロセスは、Salesforce のシステム負荷、サービス全体のパフォーマンス状況、削除対象データの総量などを考慮した上で順次実行されるため、処理開始のタイミングは一定ではありません。
基本的には 24 時間以内で削除されますが、プロセスがすべて完了しない場合は、次回の実行時に中断したところから削除が開始されます。
また、このタイムラグは、たとえば、データ保持ポリシーを設定した瞬間に該当データが即削除されてしまうのを防ぐための「調整用バッファ」とも言えます。そのため、削除は「一定の猶予期間を設けた上で、安全に実行される」仕組みだと理解すると分かりやすいでしょう。
データ保持ポリシーが必要な理由
① データ容量の節約（課金対策）
Marketing Cloud Engagement にも ストレージ使用量の限度があります。
最近リリースされた「Data Extension Storage」ダッシュボードでは、データエクステンションの容量などがレポートされ、さらにアカウントにおける保持ポリシーの設定数なども確認できます。
私の環境では、現時点で 3 GB が利用されているということになります。
② オートメーションの高速化・安定化
大きなデータエクステンションを参照するとクエリの速度が落ちます。
データ保持ポリシーによりデータエクステンションを適切サイズで維持することは、パフォーマンス上とても重要です。
データ保持ポリシー設定のベストプラクティス
① データエクステンションの役割ごとにポリシーを決める
マスタ：データ保持ポリシーなし
使い捨てのワークテーブル：7 〜 30日
配信結果：90 〜 180日（組織要件による）
② 非表示フィールド _CreatedDate の理解
個々のレコードが削除対象となる起算日については、非表示フィールドである _CreatedDate（個々のレコード作成日）を Query Studio で確認することができます。
SELECT
Id,
Email,
DATEADD(HOUR, 15, _CreatedDate) AS CreatedDate,
DATEDIFF(DAY, DATEADD(HOUR, 15, _CreatedDate), DATEADD(HOUR, 15, GETDATE())) AS Period
FROM
[Data Extension Name]
「_CreatedDate」の考慮事項
「_CrteatedDate」の日時は CST タイムゾーンで記録されるため、必要に応じてタイムゾーンの調整が必要になります。
「_CreatedDate」を利用する場合は、必ず別名（AS）が必要です。
レコードの値を「更新」（インポート、SQL クエリ）した場合は「_CreatedDate」はそのまま維持されますが、「上書き」（フィルター、インポート、SQL クエリ）した場合は「_CreatedDate」が 0 にリセット されます。
これは、上書き処理が内部的には一度レコードを削除し、その後、まったく別の新規レコードとして再作成する仕組みになっているためです。
③ 重いデータエクステンションは意図的に縮小（クエリ高速化）
古いレコードを保持する必要がなければ、積極的にデータ保持ポリシー設定してください。
④ 必要に応じてバックアップも取得
どうしても消したくないデータは、以下にバックアップも持ってください。
独自の SFTP
クラウドストレージ
Data Cloud
いかがでしたでしょうか。
データ保持ポリシーは、データを安全に・効率的に・コストに優しく運用するための重要な設定です。
特に、データエクステンションを大量に扱うプロジェクトでは
適切な保持期間
マスタ類とそれ以外のデータの区別
データエクステンション内の将来的なレコード数の予想
バックアップルールの整備
辺りを考えることが重要になります。
但し、個人的には中小規模の会社にとってはそこまで意識して設定する必要はないと思います。これまでも、そのような会社でデータ保持ポリシーをすべてオフにしていて、大きな問題になったというケースは聞きません。
デフォルトがオンになったからと言って、惑わされることなく、ぜひ自社のスタイルに合わせた運用を構築してくださいというのが私の結論です。
今回は以上です。