はじめに：ダンプサイトの丸暗記ではアーキテクトになれない
前編では、データの取り込みとアイデンティティ解決の基礎を解説しました。試験合格だけを目指してダンプサイトの解答を暗記しても、実プロジェクトで「なぜその設定が必要なのか？」をクライアントに説明できなければ意味がありません。
後編では、データ変換、高度なセグメンテーション、セキュリティ、パイプラインのライフサイクル管理まで、実務直結のアーキテクチャ設計の視点で深掘りします。
データの高度な変換とパイプライン設計
1. 複雑な集計データのパーソナライズへの活用
- 解決策: Data Transformで統計を集計し、Individualの直接属性にマッピングしてアクティベーションに含める。
- アーキテクトの視点: Marketing Cloud側でAMPスクリプト等で計算させるのは配信性能を落とすアンチパターン。Data Cloudで事前計算しフラットな属性で渡す。
2. S3コネクタにおける数式フィールドの更新タイミング
- 挙動: Full Refresh開始時に全レコードの数式を再計算。
- アーキテクトの視点: Upsertストリームでは数式変更が即座に過去データへ反映されない。変更時は意図的にフルリフレッシュをスケジュール。
3. データソース切断時の依存関係ブロック
- 解決策: 関連するデータストリームとセグメントを先に削除。
- アーキテクトの視点: 上流をいきなり消せない。ダウンストリームの成果物から整理するガバナンスが必要。
4. S3バケットの用途別分離アーキテクチャ
- 解決策: 用途別に専用S3データソースを複数構成。
- アーキテクトの視点: IAMロール・権限分離のため用途別にコネクタを分けるのが推奨。
5. DLO完全削除の罠
- 解決策: そのDLOがData Transformのソースになっていないか確認。
- アーキテクトの視点: リネージ（影響範囲）の調査が不可欠。
6. 主キーが存在しない場合の複合キー生成
- 解決策: CONCATで「地域＋識別子」等の複合キーを作成。
- アーキテクトの視点: Primary Keyは絶対条件。キー合成戦略を初期に定義。
7. 先頭のゼロ（Leading Zeros）の保持
- 解決策: フィールドタイプを「テキスト」に。
- アーキテクトの視点: 計算しない識別子はテキスト型が基本。
8. カスタムEmail項目の正しいマッピング先
- 解決策: Contact Point Emailにマッピング。
- アーキテクトの視点: Individualのテキスト項目に足すのは誤り。同意管理・ID解決の標準機能に乗せる。
9. 電話番号データの許容フォーマット
- 挙動: テキスト値が受け入れられる。
- アーキテクトの視点: 取り込み後にE.164等へ標準化するアプローチ。
10. 日次バッチ処理のデータストリーム設定（S3）
- 解決策: Upsert＋ファイル名にワイルドカード（*）。
- アーキテクトの視点: Full Refreshだと過去データが消える。増分蓄積は必ずUpsert。
プライバシー保護とアイデンティティ解決の深層
11. 忘れられる権利（データ削除要求）の処理
- 解決策: Consent API経由で提出。
- アーキテクトの視点: API経由で全体（ダウンストリーム含む）に削除を伝播させるコンプライアンス設計。
12. 調整ルールにおける「空の値を無視」の挙動
- 挙動: 優先ソースがNullなら次点ソースから補完。
- アーキテクトの視点: データの完全性（Completeness）が向上。
13. データ保護の基盤：暗号化アーキテクチャ
- 解決策: 保存時・転送中のデータを暗号化。
- アーキテクトの視点: Salesforce Shield等で金融・医療のコンプライアンスにも対応。
14. 医療業界でのPIIリスク回避（カスタムマッチング）
- 解決策: 患者IDに基づくParty Identificationでマッチング。
- アーキテクトの視点: 同姓同名・家族メール共有による誤検知を防ぐ厳格な名寄せ。
15. 機密データの収集倫理
- 解決策: 収集の必要性を慎重に再評価。
- アーキテクトの視点: Data Minimizationを徹底。
16. 重複データセットの安全な統合
- 解決策: 2つの別DLOに取り込み、それぞれIndividualとContact Point EmailのDMOへマッピング。
- アーキテクトの視点: 無理に1テーブルにマージせず、ID解決エンジンに重複排除を委ねる。
高度なセグメンテーションとアクティベーション
17. AND条件の落とし穴：同一コンテナの原則
- 解決策: 色とタイプを1つのコンテナ内にまとめて配置。
- アーキテクトの視点: 別コンテナのANDだと別々に買った人も合致。単一トランザクション評価はコンテナ内でスコープ化。
18. 「セグメントが複雑すぎます」エラーの解消
- 解決策: Calculated Insightsを事前に作成し、その結果をセグメント条件に使う。
- アーキテクトの視点: 複雑集計や深い階層をキャンバスでリアルタイムに回すとタイムアウト。バッチのインサイトで事前にフラグ化・スコア化して負荷をオフロード。
19. 複雑なビジネスルールの実現（預金額＋非利用者）
- 解決策: 預金合計のCalculated Insight＋サービス利用フラグのセグメントフィルターを組み合わせる。
- アーキテクトの視点: 計算はInsights、絞り込みはSegmentsの役割分担。
実務コラム：「Segment is too complex」を実際に踏んだ話
金融系の案件で「過去5年に25万ドル以上を預金し、かつアドバイザリー未利用」を、セグメント上で直接組んだところ、まさに“複雑すぎます”エラーで公開が失敗しました。預金合計をCalculated Insightsで事前集計し、セグメントはその結果＋利用フラグで絞る構成（No.18・No.19の定石）に変えたところ、タイムアウトが解消し公開時間も短縮。教訓は「重い計算はセグメントに持ち込まず、必ずインサイトへ逃がす」。前編のLTV事例と同じ発想です。
20. セグメント対象層の細かな調整要素
- 解決策: 直接属性・関連属性・人口フィルターの3要素。
- アーキテクトの視点: 個人属性×行動データ×ベースラインで精緻なターゲティング。
21. タイムゾーンが異なるチーム間のスケジュール表示
- 挙動: ログインユーザー自身のタイムゾーンで表示。
- アーキテクトの視点: Org固定だと時差ミスで誤配信リスク。ユーザーコンテキスト表示が運用ミスを防ぐ。
22. セグメントの一時停止と再利用（非アクティブ化）
- 解決策: Deactivate（非アクティブ化）。
- アーキテクトの視点: 削除するとロジックを失う。非アクティブ化で資産として保持。
システム運用、監視、パフォーマンスチューニング
23. 新規データの取り込みからセグメントまでの正しい順序
- 解決策: データストリーム更新 > ID解決 > 計算済みインサイト。
- アーキテクトの視点: 名寄せ前にインサイトを回すと古いプロファイルに計算が走る。依存順序は厳守。
24. アクティベーション用のS3メタデータファイル
- 解決策: .jsonファイル（CSVと共に生成）。
- アーキテクトの視点: 外部ETL/DWHはJSONを動的に読みスキーマを自動追従させる設計が推奨。
25. セグメント公開遅延トラブルの解消（同時実行制限）
- 解決策: Salesforceサポートへ同時実行制限（Concurrency Limit）引き上げを依頼。
- アーキテクトの視点: クエリ最適化＋リソース増強。スケーラビリティ確保もアーキテクトの仕事。
26. セグメント公開時間の可視化（運用ダッシュボード）
- 解決策: 標準のダッシュボード＆レポートを使用。
- アーキテクトの視点: 運用メタデータも標準オブジェクトでレポート化。オーバーエンジニアリングを避ける。
27. アクティベーション失敗のプロアクティブな検知
- 解決策: アクティベーションアラート機能を使用。
- アーキテクトの視点: 自動アラートでダウンタイムを最小化しSLAを遵守。
28. 迅速なインサイト取得（平均売上など）
- 解決策: Salesforceレポートを使用。
- アーキテクトの視点: 単純集計にLWC開発やQuery APIは過剰。標準レポートが最速・高保守。
29. CRMコネクタの強力な利点（リアルタイムストリーミング）
- 挙動: 標準フィールドの変更をリアルタイムでストリーミング。
- アーキテクトの視点: 「Closed Won」の瞬間にジャーニー開始など、イベントドリブンを実現。
実務コラム：解約の兆候を“その場で”拾うリアルタイム設計
サブスク事業で、エンゲージメントスコアをCalculated Insightsで日次算出し、閾値を割ったユーザーをData Action → Flow / Marketing Cloud Journeyでリアルタイムにリテンション施策へ流す設計を組みました。CRMコネクタのリアルタイムストリーミング（No.29）とアクティベーションアラート（No.27）を組み合わせると、「解約設定を触った瞬間」に引き止め導線を出せます。バッチのインサイトと、リアルタイムのData Actionを“役割分担”させるのがコツです。
30. クラウドファイルストレージの属性名リネーム（S3等）
- 解決策: アクティベーション時に「優先される属性名（Preferred Attribute Name）」で出力ヘッダーを上書き。
- アーキテクトの視点: 物理名やAPI名を変えると全体に影響。出力レイヤーで論理エイリアスをマッピングし疎結合を維持。
実務コラム：既存顧客への広告費を止める（Adsアクティベーション）
セグメントをAmazon Ads / Google / Metaへアクティベートし、購入済み顧客を広告から除外（サプレッション）、休眠層にはlookalikeを適用しました。ここで役立つのが属性名リネーム（No.30）で、各広告プラットフォームが要求するヘッダー命名にData Cloud側を合わせられます。CRM単体では難しい「オフラインCVを含む顧客状態」で広告を出し分けられるのがData Cloudの強みです。
おわりに：知識を実務の「知恵」に変えよう
前編・後編を通じて、Data Cloud（Data 360）がいかに精密に設計されたデータ基盤かをお伝えしました。「なぜこの設定を行うのか？」「どう組めばスケールするのか？」というアーキテクトの視点が、あなたを真のプロフェッショナルへ導きます。
▶ 前編はこちら：重要コンセプト30選（前編）
▶ 取得順序の全体像：Salesforce認定資格 完全ロードマップ
著者：ケイ（Kei）｜セールスフォース・ジャパン テクニカルアーキテクト
コメント