国ごとにCDPが分断されている—— 多言語顧客データ統合の落とし穴

実務ガイド

先に実務1点——統合のゴールは「1 ID」ではなく「停止と同意の同期」

多言語CDP統合の第一目標は、全世界で同一人物を1レコードにすることではありません。まず配信停止（オプトアウト）・同意（コンセント）・削除要求が、国別インスタンス間で矛盾しない状態を作ります。例えば、ドイツ向けメールで配信停止した顧客に、日本語インスタンスから同じメールアドレスへ再送するのは、GDPR上の問題になり得ます。

実務では、次の3列の表から始めます。「国／CRM・CDPインスタンス／同意の法的根拠／オプトアウト同期の有無／最終同期日」。同期列が「無」の行が1つでもあれば、統合プロジェクトより先に同期ルールを書きます。

同一メールアドレスのグローバルIDは、その次の段階です。ID統合を先に進めると、同意のない国からデータを寄せてしまうリスクが上がります。

分断が起きる典型——国別インスタンスと言語別フォーム

分断の入口は、だいたい次の4パターンです。①国別CRM——日本本社がHubSpot、欧州が別テナント、米国がSalesforce、という構成。②言語別ランディングページ——`/de/`と`/jp/`で別フォーム・別リストに入る。③広告プラットフォームの国別アカウント——Meta・Googleの広告アカウントが国ごとに分かれ、オーディエンスが共有されない。④ECモールの店舗アカウント——Amazon.deとAmazon.co.jpで購買履歴が別。

顧客体験では、ドイツ語サイトで資料請求し、後日日本語メールが届く、という矛盾が起きます。社内では「両方リードになった」とカウントされ、営業が二重にフォローします。マーケティングはCPL（リード獲得単価）が良く見えても、商談化率は下がります。

歴史的には、各国の代理店や現地法人が独自にツールを契約した結果、インスタンスが増殖します。直近は、GDPR対応でEUデータをEU内に置くため、わざと分断するケースも増えています。分断は「失敗」だけでなく、意図的な設計であることもあります。

顧客体験が途切れる——具体例3つ

例1：配信停止の非同期——顧客が英語メールのフッターから配信停止したが、日本語インスタンスには反映されず、翌週日本語キャンペーンが届く。クレームと監督当局への通報リスク。

例2：広告の重複——同一人物がドイツ語リターゲティング広告と日本語認知広告の両方に入り、社内では2人分のインプレッションコストがかかる。頻度上限（フリークエンシーキャップ）もインスタンスごとに効くため、ユーザー側では広告だらけに見える。

例3：商談履歴の断絶——現地展示会で名刺交換した担当者が欧州CRMにのみ登録され、本社の日本語インスタンスに商談が見えない。フォローが遅れ、競合に取られる。

いずれも、製品やサービスの品質ではなく、データの所在と同期ルールの問題です。修正は、マスターデータではなく同期イベント（オプトアウト・同意更新・削除）から入ります。

GDPRと越境移転——統合の障壁になるケース

EU一般データ保護規則（GDPR）は、個人データの処理に法的根拠（同意・契約履行・正当利益等）を要求し、EU域外への移転には十分性認定、標準契約条項（SCC）、拘束的企業準則（BCR）等の仕組みが必要です。2020年のSchrems II判決以降、米国等への移転は、移転先の実効的な保護水準を評価する必要があります。

2023年7月に発効したEU・米国データプライバシーフレームワーク（Data Privacy Framework）は、米国側の参加企業への移転経路を再整備しましたが、①参加企業かどうか、②移転するデータカテゴリ、③第三者提供の有無は、案件ごとに確認が必要です（⚠️法改正・判決で変わり得る。公開前にEDPB・各国DPAの最新ガイドを確認）。

CDP統合でよく止まるのは、「日本のマスターCDPにEU顧客を全部寄せる」案です。EU顧客のイベントログ・行動履歴を日本サーバーに置くと、移転影響評価（TIA）と追加措置の説明が必要になります。逆に、EU内にCDPを置き、日本から参照だけする設計も、接続権限とログ監査の整備が要ります。

削除権（忘れられる権利）も、国別インスタンスがあると「どこから消すか」が複雑です。削除要求を1チケットで受け、全インスタンスに伝播するワークフローが無いと、片方に残存データが残ります。DPA（データ処理者）が国ごとに違う場合、削除の完了証明（証跡）もインスタンスごとに取る必要があり、顧客への回答期限（通常30日以内）に間に合わないことがあります。

段階的統合の優先順位——4段階の順番

いきなりグローバル1 CDPは現実的ではありません。次の順番が現場で回りやすいです。

第1段階：停止・同意の同期——メールアドレス（またはハッシュ化ID）をキーに、オプトアウト・同意の更新を全インスタンスへリアルタイムまたは日次で反映。Webhook・iPaaS（Integration Platform as a Service）で足りることが多い。

第2段階：重複リードの可視化——同一メール・同一ドメインの重複をダッシュボードで見える化。マージはまだしない。営業の二重フォローを止める。

第3段階：識別子の統一——グローバルな匿名ID（first-party cookie・ログインID）を言語サイト間で共有。ログイン基盤（SSO）があるB2Bはここが効く。

第4段階：プロファイルの部分統合——契約・商談ステージ・LTV（顧客生涯価値）など、営業が必要な属性だけをマスターに寄せる。行動ログの全集約は最後でよい。

国によっては第4段階まで進めず、EUはEU内CDP、日本は日本CDPのまま、第1段階だけ共有する、という「意図的分断」が正解です。

ツール選定——1ベンダーに寄せる前に確認すること

Salesforce Data Cloud、Adobe Real-Time CDP、Segment、Bloomreach等、CDP製品は「グローバル統合」を謳いますが、データレジデンシー（保存地域）と処理地域は製品・契約プランで異なります。選定前に、次を書面で確認します。

①EU顧客データをEUリージョンのみで処理できるか。②日本からEUデータをクエリできるか（越境アクセスも移転に該当し得る）。③オプトアウトイベントを他リージョンへ伝播するAPIがあるか。④削除要求を全リージョンに一括適用できるか。

既存のHubSpot・Pardot・Marketoを国別に持っている場合、CDPを新規導入せず、まずマーケティングオートメーション間の同期（例：双方向オプトアウト）から始める方が、コストとリスクが小さいことが多いです。新規CDP導入は、同期ルールが文書化され、法務・情報セキュリティが越境移転の線引きを承認したあとに検討する順番が安全です。

多言語フォームと属性——言語タグだけでは足りない

言語別フォームで「言語＝de」とタグ付けしても、顧客の居住国・契約主体・データ処理の法的根拠までは分かりません。最低限、フォームに国（居住国またはサービス提供国）・言語・同意チェックボックスの版IDを持たせます。版IDは、同意文が変わったときに追跡できる識別子です。

B2Bでは、メールドメインから国を推測する運用が残りますが、`.com`ドメインの多国籍企業では誤判定します。国は自己申告を優先し、推測は補助にします。誤った国ラベルで越境移転してしまうより、未入力のまま別インスタンスに入れない方が安全です。

運用チェック——週次で見る5項目

統合プロジェクト中も、運用の週次レビューに次を入れます。①新規オプトアウトの同期失敗件数。②重複リードの新規発生件数（トップ10ドメイン）。③削除要求の完了までの日数。④広告オーディエンスの重複率（可能なら）。⑤越境移転に関する社内エスカレーション件数。

失敗件数がゼロでない週は、新規キャンペーンより同期バグの修正を優先します。キャンペーンを止めなくても、問題国への新規リスト追加だけ止める、という段階的制御が効きます。

今週の一手——国×インスタンス×同期の1行表

今週中に、稼働中のCRM・MA・CDPインスタンスを列挙し、先頭10行について「オプトアウト同期：有／無／不明」を埋めます。不明は無と同じ扱いで、その国への新規メール配信を止めます。

表が埋まったら、第1段階の同期だけを小さく実装します。グローバルIDやAIによるプロファイル統合は、その後で十分です。将来、規制がさらに地域細分化された場合でも、停止と同意の同期は残る共通インフラになります。