個人情報を共有せずにクロスセル推進する設計｜非接触型運用の作り方

この記事でわかること

1. 個人情報の「共同利用」と「委託 vs 第三者提供」の境界: 個人情報保護法上の法的区分を整理し、グループ横断データ活用の合法ルートを確認できます
2. 個人名不要・企業名と役職レベルで動く設計の実装イメージ: クロスセル推進に本当に必要なデータ粒度を見極め、法的リスクを構造的に下げる設計方針を理解できます
3. ゾーニングと4ステップの実装手順: 競合データの混在を防ぐアクセス権限制御の設計パターンと、非接触型運用を始めるための具体的な手順を把握できます

基本情報

個人情報を共有しない非接触型クロスセルの設計全体像

なぜ「個人情報の共有」が最初の壁になるのか

グループ横断のクロスセルを推進しようとする組織の多くが、検討の初期段階で「子会社間で顧客情報を渡してよいのか」という懸念にぶつかります。法務部門から待ったがかかり、情報システム部門がリスク評価を終えるまで動けない状態が続く——このパターンは、収益シナジーの実現を遅らせる代表的な要因のひとつです。

PwC 2023 M&A Integration Surveyによれば、収益シナジーで好結果を報告した幹部はわずか13%にとどまります。その背景のひとつに、法的懸念を理由とした「情報共有の停滞」があります。

グループ会社は法律上「別会社」——データ共有の出発点

個人情報保護法において、グループ内の子会社であっても法人格が異なれば「別の個人情報取扱事業者」として扱われます。つまり、親会社から子会社へ顧客データを渡す行為は、原則として「第三者提供」に該当する可能性があります。この出発点を正確に理解していないと、「グループ内だから問題ない」という思い込みで進めてしまい、後から法務の承認を得られないという事態につながります。

よくある3つの誤解——「共有すると全部アウト」「同意を取り直さないと使えない」「AIに入れたら学習される」

グループ横断のデータ活用を検討する際、実務の現場では次の3つの誤解が散見されます。

• 誤解1「子会社間で共有すると全部アウト」: 個人情報保護法上の「共同利用」の要件を満たせば、別会社への提供であっても第三者提供に該当しない例外が認められています。
• 誤解2「既存顧客に同意を取り直さないと使えない」: 大企業グループでは既にプライバシーポリシーに共同利用の記載があるケースが多く、ゼロからの同意取得が不要な場合があります。
• 誤解3「AIベンダーにデータを渡したら勝手に学習に使われる」: AIの学習利用が「委託範囲内」に限定された契約になっていれば、第三者提供には該当しません。委託契約の文言が鍵になります。

個人情報保護法における「共同利用」と「委託 vs 第三者提供」の境界

委託と第三者提供の境界を示す個人情報フロー図

グループ横断のデータ活用には、主に3つの法的ルートがあります。どのルートを選ぶかによって、必要な手続きと許容されるデータ活用の範囲が大きく変わります。

「共同利用」とは——グループ横断データ活用の法的根拠

個人情報保護法上の「共同利用」とは、特定の者との間で個人データを共同で利用する場合に、一定の要件を満たすことで第三者提供の例外として認められる仕組みです。要件は、利用目的・データ項目・共同利用者の範囲・管理責任者をプライバシーポリシーまたは別途の方法で本人が知り得る状態に置くことです。グループ横断のクロスセルを正式に動かすには、この要件を最初に確認することが出発点になります。

「委託」と「第三者提供」の違い——AIの学習利用はどちらに当たるか

「委託」（個人情報保護法上の委託）とは、個人情報取扱事業者が自身の業務を外部に委託する関係を指します。受託者は委託の範囲内でのみデータを利用できます。一方「第三者提供」は、委託の範囲を超えた利用または別主体への提供であり、原則として本人の同意が必要です。

AIベンダーへのデータ提供はどちらに当たるのか——名寄せや候補抽出という特定業務の遂行に限定された学習利用であれば「委託」として合法です。一方、AIベンダーが汎用モデルの改善や他社サービスへの転用を目的としてデータを学習に使う場合、これは「目的外利用」として第三者提供に該当する可能性があります。

大企業のプライバシーポリシーには既に記載されているケースが多い

グループ全社のプライバシーポリシーを精査してみると、共同利用の記載が既に盛り込まれているケースが少なくありません。「グループ関連会社との間で共同利用する場合がある」という趣旨の記載があれば、ゼロからの同意取得は不要です。まずは既存のプライバシーポリシーの記載内容を確認するところから始めることが、実務上の最短経路になります。

法的論点の総論（下請法を含む）については、子会社間クロスセルの法的論点｜下請法と個人情報保護法の境界も合わせてご参照ください。

個人名を保持しない設計——「企業名＋役職レベル」で運用する

共同利用と委託の要件比較表

なぜ個人名が不要なのか——クロスセル推進に必要なデータの粒度

クロスセルの実行において、「誰にアプローチするか」を判断するために本当に必要なデータは何でしょうか。候補企業の選定・優先順位付け・提案内容の設計という3つのプロセスを分析すると、担当者の個人名が必要になる場面は実はほとんどありません。

必要なのは、企業名・部門名・役職レベル・取引実績・スコアという粒度のデータです。「A社の購買部門が既存のB製品を使っており、C製品のクロスセル候補としてスコアが高い」——この情報さえあれば、提案計画を立てることができます。担当者の個人名は、提案を実際に行う際の「連絡先確認」の段階で初めて必要になるものです。

企業名・役職レベルで動く設計の具体的な実装イメージ

このような設計思想を実装している例として、あるグループ企業向けのクロスセル推進基盤では、個人名を保持せず企業名・役職レベルのデータのみを横断的に整理する方式を採用しています。個人情報保護法上のリスクを構造的に下げながら、子会社間の共有に向けたハードルを実質的に取り除いた設計です。

具体的には、CRMに入っている個人名・連絡先等の個人情報は各事業会社の管理下に留め、横断基盤には「企業名・業種・規模・役職レベル・取引実績・スコア」のみを連携させます。この粒度であれば、個人情報保護法の適用範囲外で運用できる可能性が高まります。ただし、役職名と企業名の組み合わせが特定個人を識別できる状況では個人情報に該当する場合があるため、法務部門との確認が推奨されます。

顧客名寄せとは｜大企業グループでの実装手順と精度設計では、個人名なしでの名寄せ精度設計について詳しく解説しています。また、LLMで顧客名寄せ精度を引き上げる方法｜4層カスケード処理では、このデータ粒度での機械的な名寄せ手法を扱っています。

個人情報に該当しないデータの活用範囲——企業属性・取引実績・ワークフローログ

企業の取引実績・企業名・部門名・役職名（特定の個人と結びつかないもの）は、一般に個人情報には該当しません。また、社内のワークフローシステムに残る「提案書を閲覧した部門・件数・タイミング」といったログも、個人を識別しない集計レベルであれば活用できます。こうした「個人情報ではないデータ」の活用範囲を明確にすることが、設計の自由度を広げる重要な作業です。

スコアリングの実装論については、顧客スコアリングとは｜BtoBクロスセルでの確度予測の作り方が参考になります。

ゾーニングによるアクセス権限制御——競合データの混在を防ぐ設計

ゾーニングとは何か——誰が何を見られるかをコントロールする仕組み

ゾーニングとは、システム上のデータを役割・事業会社・データ種別によってアクセス可能な範囲を区分けする設計手法です。子会社横断のデータ基盤を構築する際、全てのデータを全員が閲覧できる状態にしてしまうと、事業会社間の競合懸念や社内規程への抵触リスクが生じます。ゾーニングは、このリスクを構造的に制御する仕組みです。

SINAJIでは、事業会社間のアクセス権限をゾーニングによって制御しており、ある事業会社が閲覧できるデータの範囲は事前に設定された許可リストに基づきます。子会社Aの担当者が子会社Bの個別顧客データを直接参照することなく、必要な集計情報のみを共有する設計が標準となっています。

競合企業のデータが意図せず閲覧される事態を防ぐアクセス権限設計

グループ横断の基盤に競合関係にある事業会社のデータが混在することへの懸念は、実務担当者から最も多く聞かれる懸念事項のひとつです。例えば、B社が扱っているC社の顧客データを、C社と競合関係にあるD社の担当者が参照できてしまう状態は、情報セキュリティポリシー上も問題になります。

アクセス権限を「自社の担当顧客に関連するデータのみ閲覧可能」に限定することで、この懸念を構造的に解消できます。ゾーニング設計の核心は「誰に何を見せないか」を先に定義することです。

直接閲覧不可・集計レベルでの共有——段階的な情報開示の設計パターン

実務上の標準的なパターンは、「個別データは直接閲覧不可、集計レベルでのみ共有」という設計です。具体的には、事業会社の担当営業は自社顧客の個別データのみ閲覧でき、他社の個別顧客レコードは参照できません。一方で、「グループ全体でのカテゴリ別クロスセル充足率」「優先度スコアの平均値」といった集計レポートは、WGリーダーや管理者レベルで共有できます。

後述の4ステップで設計するアクセス権限マトリクスが、このゾーニングの設計図になります。全社統合せずに横断展開する方法については、グループ各社のCRMを「全社統合」せずに横展する方法｜現実解の設計も参考になります。

非接触型クロスセル運用を動かす4ステップ

非接触型クロスセル運用4ステップの階層図

Step 1：共同利用の要件を確認する——プライバシーポリシーの記載範囲を整理する

グループ全社のプライバシーポリシーを収集し、共同利用に関する記載の有無と内容を確認します。確認すべき項目は、利用目的・共有するデータ項目・共同利用者の範囲・管理責任者の4点です。既に記載がある場合は、クロスセル推進という利用目的が含まれているかを確認します。記載がない場合は、改定の手続きと改定後に収集したデータから共同利用の対象とする旨を法務部門と合意する必要があります。所要目安は1〜2週間です。

Step 2：扱うデータの粒度を設計する——個人情報か否かの分類表を作る

横断基盤に連携するデータの一覧を洗い出し、「個人情報に該当するもの」「該当しないもの」「グレーゾーン」の3区分に分類します。具体的な成果物として、「担当者氏名・連絡先・生年月日＝個人情報」「企業名・役職・業種・取引実績・スコア＝原則として個人情報に非該当」という分類表を作成します。この分類表が、横断基盤のデータモデル設計の根拠になります。

データ粒度の設計に際しては、CRM統合とは｜M&A後によくある失敗と回避策で解説しているデータ定義の標準化も合わせて参照することを推奨します。所要目安は1〜2週間です。

Step 3：ゾーニングとアクセス権限マトリクスを設計する

役割（誰が）×データ種別（何を）の2軸でアクセス権限マトリクスを設計します。役割の軸では少なくとも「事業会社担当営業」「営業マネージャー」「WGリーダー」「システム管理者」の4層を設定します。データ種別の軸では「自社顧客個別データ」「他社顧客個別データ」「集計レポート」「クロスセル候補スコア」を分けて管理します。

このマトリクスが完成したら、情報システム部門と共有してシステム上の権限設定に落とし込みます。所要目安は2〜3週間です。

アクセス権限マトリクスのサンプル

Step 4：AIの学習利用ポリシーを委託範囲内に明示する

AIベンダーと締結する契約または利用規約において、「本契約に基づく業務目的以外への学習利用を禁止する」旨を明示します。特に確認が必要な条項は「モデルの汎用改善への顧客データの使用」「他社向けサービスへの転用」の2点です。既存の契約でこの点が曖昧な場合は、覚書や補足条項で明確化します。所要目安は1週間です。

よくある質問（FAQ）

Q1. 「共同利用」の記載がプライバシーポリシーにない場合、どう対応すればよいですか？

まずグループ全社のプライバシーポリシーに共同利用の記載があるかを確認します。大企業グループでは既に記載されているケースが多く、その場合はゼロからの同意取得は不要です。記載がない場合は、利用目的・データ項目・共同利用者の範囲・管理責任者を明示した形でプライバシーポリシーを改定し、改定後に収集したデータから共同利用の対象とするのが実務上の標準的な対応です。改定の手続きや施行タイミングは法務部門との確認が推奨されます。

Q2. 個人情報に該当しないデータとはどのようなものですか？企業の取引データは含まれますか？

個人情報保護法上、「個人情報」とは特定の個人を識別できる情報を指します。法人の取引実績・企業名・部門名・役職名（特定の個人と結びつかないもの）は、一般に個人情報には該当しません。クロスセル推進においては、担当者の個人名を保持せず企業名・役職レベル・取引金額・スコアという粒度でデータを整理することで、個人情報保護法の適用範囲外でグループ横断のデータ活用が可能になります。ただし、役職名と企業名の組み合わせによって特定個人が識別できる場合は個人情報に該当する可能性があるため、法務部門との確認が推奨されます。

Q3. AIが顧客データを学習に使うことは、個人情報保護法上どのような扱いになりますか？

個人情報保護法においてAIの学習利用は「委託」または「第三者提供」のどちらかに分類されます。委託の範囲内（例：名寄せや候補抽出という特定業務の遂行）に限定された学習利用であれば合法です。一方、AIベンダーが汎用モデルの改善や他社向けサービスへの転用を目的として顧客データを学習に使う場合は、目的外利用として第三者提供に該当し、本人同意が必要になります。契約段階でベンダーの利用規約を確認し、「委託目的以外への学習利用禁止」を明示的に契約に盛り込むことが重要です。

Q4. グループ横断でデータを扱う際に国内サーバーにこだわる理由は何ですか？

個人情報保護法は個人データを外国に移転する場合に追加の要件（本人同意または適切な体制の確保）を課しています。海外サーバーを使用すると越境データ移転の論点が生じ、場合によっては既存顧客全員への再同意取得が必要になります。大企業グループの顧客数を考えると再同意取得は事実上困難なケースも多く、国内サーバーでの処理によって越境移転の論点そのものを回避することが実務的に合理的な選択です。

Q5. ゾーニングを設計するとき、アクセス権限のマトリクスはどのような観点で設計すればよいですか？

アクセス権限マトリクスは「役割（誰が）」×「データ種別（何を）」の2軸で設計します。役割の軸では、事業会社の担当営業・営業マネージャー・WGリーダー・システム管理者といった粒度を設定します。データ種別の軸では、自社顧客の個別データ・他社顧客の個別データ・集計レポート・クロスセル候補スコアを分けて管理します。一般に、他社顧客の個別データは担当営業レベルでは非公開とし、集計レポートのみ閲覧可能にするゾーニングが競合データ混在のリスクを防ぐ標準設計です。

Q6. 子会社間で顧客情報を「渡さずに」クロスセルを実現するとはどういう意味ですか？

「渡さずに」とは、子会社Aの担当営業が子会社Bの顧客データを直接閲覧・ダウンロードできない設計を指します。具体的には、システムの中央基盤でデータを管理し、各事業会社には自社の担当顧客に紐づくスコアや推奨アクションのみを表示する方式です。個別の顧客レコードが事業会社間を移動することなく、クロスセル候補の特定と提案の調整が行えます。この設計によって、社内規程や情報セキュリティポリシーへの適合を維持しながら横断的な営業活動が可能になります。

Q7. C3-03の法的論点記事との違いは何ですか？下請法はこの記事でカバーされますか？

子会社間クロスセルの法的論点｜下請法と個人情報保護法の境界は下請法と個人情報保護法の法的論点を総論として解説しています。本記事（C5-12）は個人情報保護法の共同利用・委託要件に絞り、データ設計とゾーニングの実装論に特化しています。下請法に関する論点はC3-03をご参照ください。

まとめ

主要ポイント

1. 「共同利用」の要件整備が全ての出発点: 個人情報保護法上の共同利用の要件（利用目的・データ項目・共同利用者の範囲・管理責任者）を満たせば、グループ子会社間のデータ共有は合法ルートで実現できます
2. 個人名不要の設計が法的リスクと実装コストを同時に下げる: クロスセル推進に必要なのは企業名・役職レベルのデータであり、個人名を横断基盤に連携しない設計がリスクと摩擦の両方を減らします
3. ゾーニングが組織の承認コストを下げる: 情シスの承認・法務の同意・現場の参加という3つの障壁は、アクセス権限マトリクスによるゾーニング設計で構造的に解決できます

次のステップ

• グループ全社のプライバシーポリシーを確認し、共同利用の記載有無を整理する
• クロスセル推進に必要なデータ項目の洗い出しと個人情報非該当データの分類表を作成する
• 役割×データ種別のアクセス権限マトリクスを法務・情シスと合意する

関連記事

参考リソース

• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• McKinsey "Capturing cross-selling synergies in M&A"（2020年2月）
• PwC 2023 M&A Integration Survey
• Bain "Bringing Science to the Art of Revenue Synergies"（M&A Report 2022）