はじめに：なぜ「ダンプサイト」での暗記は危険なのか？
Salesforce Data Cloud（現 Data 360）は、企業内に散在する膨大な顧客データを統合し、リアルタイムでパーソナライズされた体験を提供するための次世代プラットフォームです。認定コンサルタント試験に合格するには、過去問の答えを暗記するだけでは全く通用しません。
実際のプロジェクト現場で「なぜそのデータモデルを組むのか？」「なぜそのデータストリーム設定が必要なのか？」というアーキテクチャの根拠（Why）を説明できなければ、コンサルタントとして失格です。
本記事（前編）では、取り込み・ID解決・計算済みインサイトの基礎から、重要な30のコンセプトを、公式ドキュメントと現役TAの実務視点で解説します。
第1章：データインジェスト（取り込み）とストリーム設計の極意
1. Marketing Cloudとのネイティブ連携：スターターデータバンドル
- 対象データ: Email、MobileConnect、Mobile Pushの3つが事前定義。
- アーキテクトの視点: エンゲージメントイベントを自動マッピングでき実装期間を短縮。PersonalizationやLoyalty Managementは別プロダクトで含まれない点に注意。
2. Salesforce CRMコネクタ：隠れた権限の罠
- 解決策: Salesforce Integration User（統合ユーザー）に該当カスタム項目への参照権限（FLS）が付与されているか確認。
- アーキテクトの視点: FLS設定漏れはデータ欠損の最大の原因。
3. SFTPを介したレガシーデータの取り込み
- 解決策: SFTPコネクタを使用。
- アーキテクトの視点: Cloud Storage（S3等）とSFTPは別物。SFTPしかエクスポートできない要件ではSFTP経由でDLO化。
4. B2C Commerce Order Bundleの歴史データの罠
- 仕様: 履歴データは取り込まず、設定時点以降の新規注文のみ。
- アーキテクトの視点: 過去データが必要ならCSVでの初期ロード戦略を別途立案。
5. フィールドデータ型の挙動：日付（Date）の切り捨て
- 挙動: Date型は日付のみ保持、時刻は切り捨て（エラーやnullにはならない）。
- アーキテクトの視点: タイムスタンプが必要ならDateTime型で受ける設計を。
6. 電話番号フォーマットの標準化（E.164形式）
- 解決策: フィールドタイプに「Phone Number」を割り当てる。
- アーキテクトの視点: 自動でE.164へ変換。数式で手動補正するより圧倒的に効率的。
第2章：データモデリングとアイデンティティ解決（Identity Resolution）
7. ID解決のための正しいオブジェクトマッピング
- 解決策: 個人情報はIndividual、メールはContact Point Emailへマッピング。
- アーキテクトの視点: すべてをCustomerに詰め込むのはアンチパターン。人と連絡手段を分離するのが高精度マッチングの前提。
8. セグメンテーションの前提条件：ID解決の実行
- 必須プロセス: Identity Resolution。
- アーキテクトの視点: 統合プロファイルを生成して初めて正確なセグメントが可能。
9. ソースシーケンス（Source Sequence）調整ルール
- 機能: データソースに優先順位を設定。
- アーキテクトの視点: 「氏名はCRMを正、空ならMarketing Cloud」等、データガバナンスの根幹。
10. 空の値を無視（Ignore Empty Value）オプション
- 機能: 優先ソースがNullなら、優先度が低くても値を持つソースを採用。
11. カスタム識別子での完全一致（Party Identification）
- 解決策: Party Identificationオブジェクトを使用。
- アーキテクトの視点: ロイヤルティID・免許証・会員番号など業界特有のカスタムマッチングを実現。
12. 誤ったIDマッチングのトラブルシューティング
- 解決策: 既存ルールを直接変更せず、より厳格な新ルールセットを作成→比較検証→移行。
- アーキテクトの視点: 既存ルール直接変更は統合プロファイルへ破壊的影響。新旧並行稼働で検証を。
実務コラム：EC・店舗・アプリがバラバラだった顧客データの統合
あるD2Cブランドでは、EC会員・店舗POS・アプリ・CRMで同じ顧客が“別人”として扱われ、クーポンの重複配信と機会損失が起きていました。Web SDKでサイト行動、POSはS3経由、CRMはネイティブコネクタで取り込み、Identity Resolutionでメール＋電話＋会員IDの一致ルール（第2章の考え方そのもの）を設計して統合プロファイル化。結果、世帯・個人単位の名寄せで重複配信が減り、「オンラインで見たが店舗で未購入」という横断セグメントが作れるようになりました。ここでも“まずContact PointとParty Identificationを正しく分離する”という原則（No.7・No.11）が効いています。
第3章：データ変換と計算済みインサイト（Calculated Insights）
13. Metrics on Metrics（メトリクス上のメトリクス）
- 解決策: Metrics on Metrics機能を使用。
- アーキテクトの視点: 既存メトリクスをベースにチャネル等で分解。複雑なSQLなしで多次元分析。
14. DMO結合シーケンスの定石（LTV算出）
- 正しい順序: Unified Individual > Unified Link Individual > Sales Order。
- アーキテクトの視点: 注文データは直接Unified Individualに結びつかない。必ずUnified Link Individualを経由する。
15. Customer Lifetime Value (CLV) セグメント構築のステップ
- 解決策: Ingest > Map > Create Calculated Insight > Use in Segmentation。
- アーキテクトの視点: インサイトはDMOに対して実行。DLO→DMOマッピング完了が前提。
16. バッチ変換（Batch Transform）によるデータの分割
- 解決策: Batch Transformで2番目のDLOを作成。
- アーキテクトの視点: ソース構造を変えずにData Cloud側でETL。条件分岐で別DLOに格納しモデリングをクリーンに。
実務コラム：チャネル別LTVからVIPセグメントを作る
小売クライアントで「オンライン／店舗／アプリ別の収益内訳つきLTV」を出したいという要望がありました。Metrics on Metrics（No.13）で既存の売上メトリクスをチャネル軸で分解し、Calculated Insightで統合LTVを算出（結合順序はNo.14の定石通りUnified Link Individual経由）。その結果を使って「LTV上位×店舗来店あり」のVIPセグメントを構築しました。ポイントは、生データを直接セグメントに使わず、一度インサイトで“指標”に変換してから絞り込むこと。これは後編で触れる「重いセグメントの回避」にも直結します。
第4章：セグメンテーションとアクティベーションの高度な活用
17. アクティベーション数の減少（Contact Pointの必須化）
- 理由: Marketing Cloud向けアクティベーションはContact Point（有効なメール等）の存在を強制。関連付けのない個人は除外される。
18. コンテナブロック（Container Block）による再利用
- 解決策: 共通の除外基準を再利用可能なコンテナブロック化。
- アーキテクトの視点: 一元管理でヒューマンエラーを排除しガバナンス向上。
19. ネストされたセグメント（Nested Segments）
- 解決策: ベースオーディエンスを親セグメント化し、子でInclude/Exclude。
- アーキテクトの視点: ルール変更の影響範囲を親の修正のみに限定できる。
20. AND条件とコンテナの論理関係
- 1コンテナに配置: 「黒い靴」という単一製品を買った人を抽出。
- 2コンテナをAND: 「黒いシャツ」と「赤い靴」を別々に買った人も含まれる。
- アーキテクトの視点: コンテナは「イベントのスコープ」。同一アイテムの複数条件は同じコンテナ内で。
21. 購入日フィルターの適用箇所
- 解決策: セグメントだけでなくアクティベーション構成側でも購入日フィルターを適用。
- アーキテクトの視点: 「人の絞り込み」と「送信データ（ペイロード）の絞り込み」は別設定。
22. カスタムDMOがセグメンテーションに表示されない
- 原因: DMOのカテゴリが「Profile」になっていない。
- アーキテクトの視点: セグメントの起点は必ず「人（Profile）」DMO。Engagement等は関連属性としてのみ使用可。
23. Cloud File Storage（S3など）の属性名の変更
- 解決策: アクティベーション構成で「優先される属性名（Preferred Attribute Name）」を設定。
第5章：ライフサイクル、ガバナンスとセキュリティ
24. プロジェクト初期フェーズでの必須アクション
- 解決策: ビジネスユースケースを特定し、必要なデータソースとデータ品質を定義。
- アーキテクトの視点: 「とりあえず全部入れる」は失敗の典型。目標から逆算する。
25. データソース切断時の依存関係ブロック
- 解決策: 関連する「データストリーム」と「セグメント」を先に削除。
26. センシティブなデータの取り扱い倫理
- 解決策: 必要性を慎重に検討し、プライバシー規制を遵守。
- アーキテクトの視点: Data Minimization（データ最小化）の原則を常に推奨。
27. S3バケットの分離アーキテクチャ
- 解決策: 取り込み用とアクティベーション用で専用S3データソースを別々に構成。
- アーキテクトの視点: IAMロール・アクセス権限・ログ監視を分離し、エンタープライズ要件を満たす。
第6章：高度な設定とユースケース
28. セグメントでの「値の提案（Value Suggestion）」の有効化
- 解決策: マッピング完了DMOのレコードホームから該当フィールドの「値の提案」を有効化。
29. 自動車ディーラー向けユースケース
- 解決策: Web・サービス予約・試乗履歴など複数タッチポイントを取り込み、調和（Harmonize）して分析用データモデルを構築。
30. Sales Order（販売注文）サブジェクト領域の活用
- 解決策: Sales Orderサブジェクト領域を使用。
- アーキテクトの視点: Sales Order Line ItemとRevenue DMOを組み合わせ、製品ファミリー単位の売上分析・セグメントを実現。
【2026トレンド】Data 360とZero Copy：取り込まない統合へ
実務コラム：DWHを二重に取り込まない — Zero Copy（データフェデレーション）
「Data Cloud」から「Data 360」への進化で象徴的なのが Zero Copy。Snowflake・BigQuery・Databricksに既にある大量データを、物理的に取り込まずに参照して活用できます。実際、DWHを単一ソースとして保ちたい大企業では、全量をIngestするのではなくZero Copyで参照し、Data Cloud側でセグメント・アクティベーションに使う構成が増えています。ストレージ増とパイプライン二重管理の悩みが大きく減るのが利点です。試験対策としても、従来の「Ingest前提」だけでなくこの選択肢を押さえておくと、実務での提案力が一段上がります。
おわりに
Data Cloudは「データの流れ（Ingest → Map → Resolve → Insight → Segment → Activate）」を正しく理解し、全体最適でアーキテクチャを描く力が問われます。前編では取り込み〜ID解決〜インサイトの基礎を扱いました。
▶ 続きはこちら：重要コンセプト30選（後編）
▶ 取得順序の全体像：Salesforce認定資格 完全ロードマップ
著者：ケイ（Kei）｜セールスフォース・ジャパン テクニカルアーキテクト
コメント