Salesforce 個人情報・同意管理 ファンデータの項目設計とアクセス権限

Salesforce（セールスフォース）を活用してCRM（顧客関係管理）を高度化させる際、避けて通れないのが「個人情報の保護」と「同意管理（コンセントマネジメント）」の設計です。特にBtoCビジネスやファンビジネスにおいて、顧客の嗜好性（ファンデータ）を蓄積しながら法的コンプライアンスを遵守するには、単に項目を作るだけではない、多角的なアーキテクチャ設計が求められます。

本記事では、Salesforceにおける個人情報・同意管理の決定版として、実務に即した項目設計の手法から、セキュリティを担保するアクセス権限の設定、さらには外部ツールとの比較までを徹底的に解説します。

Salesforceにおける個人情報・同意管理の全体像

なぜCRMでの「同意管理」が企業の生命線になるのか

近年の改正個人情報保護法や、欧州のGDPR（一般データ保護規則）などの影響により、企業は顧客データの取得に対して「何のために」「どのチャネルで」利用するかの同意を得る義務があります。単に「利用規約に同意した」というバルクの合意ではなく、マーケティングメールの受取可否、サードパーティへのデータ提供、クッキーの利用など、細分化された粒度での管理が必要です。

この管理が杜撰な場合、配信停止を希望している顧客にメールを送り続けてしまうといった実務上のミスがブランド毀損に直結するだけでなく、制裁金や公表などの法的リスクを負うことになります。Salesforceは単なる住所録ではなく、この「同意の証明書」を保持するマスターデータベースとしての役割を担います。

個人情報保護法とSalesforce標準機能の対応関係

Salesforceには、プライバシー管理をサポートするための機能が標準で備わっています。例えば、リードや取引先責任者にある「メール送信除外」項目は最も基本的な同意管理の一つです。しかし、これだけでは不十分です。法的に求められるのは「いつ、誰が、どのバージョンの規約に、どのような手段で同意したか」という証跡です。これを実現するために、Salesforceでは「個人（Individual）」オブジェクトなどの標準機能やカスタム設計を組み合わせて対応します。

ファンデータの項目設計：同意と属性を分ける設計指針

標準オブジェクト（リード・取引先責任者）の拡張限界

多くの企業では、リード（見込み客）や取引先責任者のオブジェクトに直接「好きなタレント」「興味のあるジャンル」といったファンデータ用の項目を追加します。しかし、これには以下の限界があります。

• 同意の履歴が残らない：最新のステータスはわかっても、過去にいつ拒否に転じたかの履歴を追うのが困難。
• 多対多の管理ができない：一人の顧客が複数のブランドや複数のキャンペーンに対して異なる同意状況を持つ場合、単一オブジェクトの項目では管理が破綻します。

ここで重要になるのが、ID連携の視点です。Webサイトでの行動ログとSalesforce上の顧客IDを紐付ける設計については、WebトラッキングとID連携の実践ガイドでも詳しく解説されていますが、同意管理もこれと同様に、IDを基軸にしたデータ構造の整理が必要です。

「個人（Individual）」オブジェクトの活用メリットとデメリット

Salesforceには、データのプライバシー設定を一元管理するための「個人（Individual）」オブジェクトが存在します。リード、取引先責任者、個人取引先の各レコードから参照関係で紐付けることができます。

• メリット：一人の人間（Person）がリードとしても取引先責任者としても存在する場合、その両方にまたがるプライバシー設定（「わすれられる権利」の行使など）を一箇所で管理できる。
• デメリット：標準で提供されている項目が海外の法制度をベースにしているため、日本の実務に合わせるには結局カスタム項目の追加が必要になる。

ファンデータを深化させるカスタムオブジェクトの構成案

より深いファンエンゲージメントを追跡する場合、「ファン属性」と「同意状況」は分けて管理すべきです。以下のようなカスタムオブジェクト構成を推奨します。

実務で使える「同意ステータス」の項目定義一覧

必須で保持すべき5つのメタデータ

どのような設計にするにせよ、コンプライアンス上の証跡として以下の5点は必ず定義してください。

1. 同意のタイムスタンプ：UTCではなく日本時間(JST)で取得・保持。
2. 同意のソース：どのフォーム、どのアプリ、または対面での取得か。
3. 規約バージョン：同意した時点のプライバシーポリシーのバージョン番号。
4. 取得時のIPアドレス：Web経由の場合、本人の操作であることの補足証跡。
5. 目的の明示：マーケティング目的か、サービス運営上の重要通知か。

チャネル別同意（Email/SMS/DM/電話）のフラグ管理

「メールはいいが電話はNG」という顧客は少なくありません。これらを一つの「オプトアウト」項目で管理するのは実務上不可能です。Salesforceの標準項目に加え、以下のカスタムチェックボックス、または選択リストを用意します。

• メール配信同意 (Email_Consent__c)
• SMS配信同意 (SMS_Consent__c)
• 郵送DM送付同意 (Postal_Consent__c)
• サードパーティ提供同意 (Third_Party_Sharing_Consent__c)

これらの項目をMarketing CloudやAccount Engagement (Pardot) と連携させる際、同期の優先順位（どちらがマスターか）を明確にしておく必要があります。高度なデータ連携アーキテクチャについては、SFA・CRM・MA・Webの違いを解説した全体設計図を参照してください。

アクセス権限とセキュリティ：最小権限の原則を実装する

プロファイルと権限セットの使い分け

個人情報管理において、「誰でも全ての情報を見られる」状態は最大の脆弱性です。Salesforceでは「プロファイル」で大枠の権限を決め、「権限セット」で特定の個人やチームに必要な権限を付与する運用が標準的です。

例えば、一般の営業担当者には顧客の「購入履歴」は見せても、「マイナンバー」や「詳細な住所」は隠すといった制御が必要です。管理権限の自動化については、SaaSアカウント削除漏れを防ぐ自動化アーキテクチャの考え方が、Salesforce内部の権限管理にも応用できます。

項目レベルセキュリティ（FLS）によるPII（個人特定情報）の保護

項目レベルセキュリティを使用すると、特定のプロファイルに対して特定の項目を「非表示」または「参照のみ」に設定できます。設定手順は以下の通りです。

1. [設定] ＞ [オブジェクトマネージャ] ＞ 対象オブジェクトを選択。
2. [項目とリレーション] ＞ 対象の項目（例：電話番号）を選択。
3. [項目レベルセキュリティの設定] ボタンをクリック。
4. 各プロファイルに対し、「参照可能」または「参照のみ」のチェックを制御。

注意点：「非表示」に設定した項目は、レポートやリストビューにも表示されなくなります。業務上どうしても集計が必要な場合は、値をマスキングした数式項目を別途用意するか、集計専用の権限セットを作成します。

【比較】Salesforce標準管理 vs Consent Managementツール

Salesforceだけで管理を完結させるか、OneTrustのような外部の同意管理プラットフォーム（CMP）や、Salesforce公式の有償アドオン「Privacy Center」を導入するかの比較です。

大規模なグローバル展開や、数百万件規模のファンデータを抱える場合は、公式のPrivacy Centerや外部CMPを検討すべきです。中小規模や国内限定のサービスであれば、カスタムオブジェクトによる構築が最もコストパフォーマンスに優れます。

設定手順：同意管理アーキテクチャの構築ステップ

Step 1：個人オブジェクトの有効化と紐付け

まず、Salesforce組織で「個人」オブジェクトを有効にします。
[設定] ＞ [データ] ＞ [データプライバシー設定] ＞ 「データプライバシーレコードでのデータ保護の詳細の管理」を有効化。
これにより、リードや取引先責任者に「個人」項目の参照リレーションが追加されます。

Step 2：同意取得フォーム（Web-to-Lead/API）との連動設定

Webサイトのフォームからデータが入ってくる際、同意チェックボックスの値を直接リードに流し込むだけでなく、自動起動フロー（Autolaunched Flow）を使用して、対応する「個人」レコードを自動生成、または既存レコードを更新するロジックを組みます。

Step 3：データクリーンアップと重複排除のルール化

同意管理で最も恐ろしいのは、同一人物が別レコードで存在し、片方ではオプトアウト、もう片方ではオプトインになっている状態です。標準の「一致ルール」と「重複ルール」を厳格に設定し、メールアドレスをキーとした名寄せを自動化します。

よくあるエラーと運用上の落とし穴

同期ズレによる「送ってはいけない相手」へのメール送信

Marketing CloudやAccount Engagement（旧Pardot）を利用している場合、Salesforce側でオプトアウトした情報がMA側に反映されるまでにはタイムラグ（通常数分〜数十分）があります。この隙間に配信スケジュールが重なると事故が起きます。
対策：配信直前に必ず最新の同期ステータスを確認するクエリを挟むか、MA側の「マスター退会リスト」とSalesforceをリアルタイムAPIで同期させる設計にします。

sandbox環境への個人情報コピーによるセキュリティ事故

本番環境のデータをFull Sandboxにコピーする際、個人情報がそのまま入ってしまうことがあります。開発ベンダーが参照できる環境に生データがあるのは危険です。
対策：Sandbox更新時にデータを匿名化するスクリプトを実行するか、Salesforce Data Mask（有償）を使用して、開発環境のデータを安全に保つ必要があります。

まとめ：ファンとの信頼関係を築くデータ基盤へ

Salesforceにおける個人情報・同意管理は、単なる法規制への対応ではありません。顧客が「自分のデータをこの企業になら預けてもいい」と思える信頼の土台を作る作業です。適切な項目設計と厳格なアクセス権限の設定を通じて、ファン一人ひとりの嗜好性を尊重した、質の高いコミュニケーションを実現しましょう。

もし、既存のシステムからの移行や、より複雑なデータ連携を伴う再構築を検討されている場合は、API連携術を駆使した高度な可視化フェーズの考え方も、全体のアーキテクチャ設計の参考になるはずです。