Loading
システム管理者に対するフィッシング耐性MFA・全従業員ユーザーMFAの適用のお知らせ 続きを読む

Marketing Cloud Next - 同意管理:監査履歴

公開日: Jul 28, 2026
説明
注: この記事は、Consent Management: Frequently Asked Questionsの関連記事です。追加の詳細やその他のよくある質問についてはそちらもご確認ください。

Consent Audit Trail(同意監査履歴)とは何か、どこに保存されているか

 
Consent Audit Trail は Data Cloud 内のオブジェクトで、同意の変更ごとに1行のレコードを記録します。Communication Subscription Consent DMO(現在のステータスを保持し、上書き更新される)とは異なり、Audit Trail は追記専用(append-only)です。行は挿入されるのみで更新されることはなく、特定の Contact Point 値と Communication Subscription Channel Type に対するすべてのオプトイン/オプトアウトイベントの履歴記録として機能します。

監査履歴にはどのようなフィールドが含まれるか

 
Consent Audit Trail オブジェクトのフィールド一覧
 
 

項目

説明

Id

監査履歴レコードの一意なシステム識別子

TimeStamp

監査行が書き込まれた日時(システムに変更が記録された時刻)

ConsentCaptureSourceDateTime

実際に同意の決定がキャプチャされた日時(呼び出し元アプリケーションから提供)。同意を早めに収集し、後で同期した場合は TimeStamp と異なることがあります

ConsentStatus

変更後の結果的な同意ステータス(例:Opt In または Opt Out)

PassedConsentStatus

この更新のために呼び出し元アプリケーションから渡された同意ステータス

ConsentUpdateAction

更新を引き起こしたアクション(例:同意レコードに適用された作成または更新操作)

ContactPointValue

同意が適用される Contact Point(メールアドレスや電話番号など)

CommunicationSubscriptionChannelTypeId

同意レコードが紐づく Communication Subscription Channel Type の識別子

ChannelType

同意が適用されるチャネル(例:Email や SMS)

PartyId

同意レコードが属する個人(Party)の識別子

SenderId

同意レコードに関連付けられた送信者の識別子

ConsentCapturedSourceType

同意をキャプチャしたソースの種類(呼び出し元が指定する出所情報)

ConsentCapturedSourceName

同意をキャプチャしたソースの名前(フォーム、フロー、アプリケーション名など、呼び出し元が指定)

ConsentCapturedSourceDetails

同意をキャプチャしたソースに関する追加詳細(呼び出し元が指定)

 

 

監査履歴は変更を行った(どのユーザーが行ったか)を記録するか

 
専用の UserId/ActorId/ModifiedById フィールドはありません。これは現在のスキマの仕様上、意図された挙動です。最も近いフィールドは、呼び出し元が提供するソース属性情報(ConsentCapturedSourceType、ConsentCapturedSourceName、ConsentCapturedSourceDetails、SenderId)で、これらは呼び出し元アプリケーションがデータ取り込み時に設定した場合のみ入力されます。コンプライアンス上のアクターレベルの属性情報が必要な場合は、フロー、フォーム、または連携から取得可能な任意のアクター識別子を用いて ConsentCapturedSourceName と ConsentCapturedSourceDetails を設定してください。

監査履歴で PartyId が空欄になるのはなぜか

 
Marketing Cloud の同意は、意図的に PartyId を意識しない仕様になっています("Why is PartyID not used?"を参照)。同意は Contact Point 値と Communication Subscription Channel Type ID をキーとして管理されるため、アップストリームのレコードが Lead または Contact であっても PartyId は仕様上空欄で書き込まれます。レポーティングのために監査行を Lead や Contact に紐付けたい場合は、監査オブジェクトの ContactPointValue を ContactPointEmail または ContactPointPhone DMO に結合してください。これらは PartyId のマッピングを保持しています。

監査履歴を使って、Contact や Lead レコード上に個人単位の同意履歴ビューを表示できるか

 
現時点では標準機能では対応していません。Contact や Lead レコード上での個人単位の同意履歴コンポーネントは既知の要望であり、ロードマップに含まれています(確定したリリース日はありません)。

監査履歴の行を削除できるか(不正なインポートのクリーンアップや GDPR 対応など)

 
監査オブジェクトは insert/upsert 専用であり、個々の行を削除するセルフサービス機能はありません。

選択肢:

  1. GDPR の「忘れられる権利(Right to be Forgotten)」 — Individual に対して Consent API の「ShouldForget」エンドポイントを使用します。これにより個人にフラグが立てられ、非同期処理によって Individual DMO および関連オブジェクト全体にわたって削除が実行されます。削除には通常数時間かかり、完全なカバレッジのために30日、60日、90日後に再処理されます。削除は永続的です。参照: データ削除または忘れられる権利の要求およびConsent REST API reference
  2. 一括削除(例:誤った初回インポートの取り消しなど) — ユーザーインターフェース上で完了できる機能はありません。Salesforce サポートにお問い合わせください。
  3. Privacy Center の Right to Be Forgotten ポリシー — これは別のフレームワークです。ご利用のエディションに応じてどちらが適用されるかご確認ください。参照: RTBF Policies


監査履歴についてレポートやセグメンテーションを行えるか

 
レポーティングには対応しています。Data Cloud の Query Editor と Data Explorer を使って同意オブジェクトと監査オブジェクトを照会し、コンプライアンスおよび運用レポートを作成できます。同意ステータスによるセグメンテーションは現時点では標準機能では対応していません(代わりに Calculated Insight を使った回避策をご利用ください。Segmentation sectionを参照)。

監査履歴に拒否された(rejected)行が表示されるのはなぜか

 
拒否された行が発生する一般的な原因は以下のいずれかです。

  1. オブジェクトマッピングの誤り — 監査オブジェクトが誤ったターゲットにマッピングされ、実体のない(phantom)行が作成されている。データストリームのマッピングを再確認してください。
  2. 日付フォーマットの問題 — 同意キャプチャ日時に対応していないタイムスタンプ形式を使用すると、本来意図した書き込みがスキップされる一方で監査行は書き込まれることがあります。取り込み前にタイムスタンプ形式を検証してください。
  3. ステータスの大文字小文字の不一致 — 「OPT_IN」/「OPT_OUT」ではなく「OptIn」/「OptOut」を送信している。正しい形式の値を生成する Create Consent アクションを使用してください。


上記を確認しても問題が解決しない場合は、Salesforce サポートにお問い合わせください。
ナレッジ記事番号

005389884

 
読み込み中
Salesforce Help | Article