ジムM&Aで個人情報を安全に引き継ぐための結論は、会員データを最初から一括で渡さず、交渉の進み具合に応じて「匿名・集計情報」「限定された検証情報」「成約後に移行する実データ」の三層に分けることです。秘密保持契約を締結しただけで、氏名、連絡先、健康申告、入退館履歴まで自由に共有できるわけではありません。譲渡企業と譲受候補企業は、利用目的、閲覧者、保存場所、持ち出し制限、事故時の連絡、交渉不成立時の消去を契約と運用の両面で定める必要があります。
ジム事業には、一般的な顧客名簿だけでなく、月会費、休会・退会、予約、入退館、身体測定、健康申告、トレーニング履歴、防犯カメラ映像、決済情報など、多種類のデータが蓄積されます。これらは売上の継続性や運営品質を確認するうえで重要ですが、必要性を超えて開示すれば、会員の信頼を損ない、情報漏えいの範囲も広げます。本記事では、ジムM&Aにおける個人情報の実務を、契約前のデューデリジェンス（以下「DD」）、株式譲渡・事業譲渡、システム移行、事故対応まで一続きの手順として解説します。
なお、本記事は、既存のジム売却前のDD資料の整え方や、匿名で譲受候補企業を探す方法とは役割が異なります。既存記事が資料準備や案件情報の秘密保持を広く扱うのに対し、本記事は「会員・利用者・従業員に関するデータを、誰が、いつ、どこまで閲覧し、どのように移行・消去するか」に焦点を絞っています。
ジムM&Aにおける個人情報引き継ぎの要点
| 判断項目 | 基本方針 | 避けたい対応 |
|---|---|---|
| 初期検討 | 会員数、退会率、ARPU（会員一人当たり売上高）などを集計値で示す | 会員名簿や予約表をそのまま送る |
| 契約前DD | 目的・閲覧者・取扱方法・事故時対応・不成立時措置を契約化する | 秘密保持契約だけで全データを開放する |
| 健康・身体情報 | 必要性を個別に判断し、匿名化・範囲限定を優先する | 病歴や健康申告を初期段階から共有する |
| 決済 | トークンや決済代行会社の承継可否を確認する | カード番号を表計算ファイルへ複製する |
| 事業承継後 | 承継前の利用目的の範囲を確認し、変更時は法的手続を検討する | M&Aを理由に用途を無制限に広げる |
| システム移行 | 項目対応表、テスト、件数照合、権限棚卸し、旧環境消去まで計画する | 本番データを使って場当たり的に移行する |
| 交渉不成立 | 返還・復元不能な消去・バックアップ取扱いを確認する | 譲受候補企業の端末やメールに残したままにする |
重要なのは「法律上提供できる可能性があるか」と「今この時点で、この粒度の情報を渡す必要があるか」を分けて考えることです。法令上の要件を満たす場合でも、DDの目的が集計値で達成できるなら、個人を特定できるデータを提供しない方が安全です。データ最小化は、会員保護だけでなく、譲渡企業、譲受候補企業、M&A支援機関の事故対応負担を小さくします。
なぜジムの会員データは慎重な設計が必要なのか
ジムは「継続課金」「予約」「施設入館」「身体に関するサービス」が一つの事業に集まる業態です。会員管理システムだけを見ても、氏名、住所、連絡先、契約コース、入会日、支払状況、休会履歴、退会理由が関連付けられています。パーソナルジムやヨガ・ピラティスでは、担当トレーナー、予約履歴、目標、体重・体脂肪率、既往歴に関する申告などが別の予約・カルテシステムに保存される場合もあります。
一方、24時間ジムでは、会員アプリ、スマートロック、顔認証、監視カメラ、決済代行、問い合わせ管理が別々のクラウドサービスで動いていることがあります。M&A時には「会員管理SaaS（クラウド型業務システム）だけ移せば終わり」ではありません。どのシステムに、誰の、どのデータがあり、どの契約主体が管理し、国外を含むどこで処理される可能性があるかをデータマップに落とす必要があります。
ジムで棚卸しすべきデータ
| データ群 | 主な項目 | M&Aでの確認目的 | 初期開示の考え方 |
|---|---|---|---|
| 会員基本情報 | 氏名、住所、電話番号、メール、生年月日、緊急連絡先 | 契約承継、連絡、本人確認 | 原則として件数・属性分布に集計する |
| 在籍・退会・休会 | 入会日、在籍期間、休会理由、退会日、退会理由 | 継続率、離脱要因、将来売上 | 月別・コース別の集計値を優先する |
| 料金・ARPU | 月会費、オプション、割引、回数券、未収金、前受金 | 収益性、債務、価格改定余地 | 会員IDを置換した明細または集計値 |
| 入退館 | 日時、店舗、ゲート、認証結果、同伴記録 | 利用率、混雑、安全管理 | 時間帯・曜日別集計を優先する |
| 予約・受講 | 予約日時、クラス、担当者、キャンセル、無断欠席 | 稼働率、講師依存、枠設計 | 氏名を除き、枠別・担当別に集計する |
| 身体・健康申告 | 体重、体脂肪率、目標、病歴、服薬、けが、医師の指示 | 安全なサービス継続 | 原則として個票を初期開示しない |
| 映像・認証 | 防犯カメラ映像、顔画像、顔認証用データ、静止画 | 防犯、入館認証、事故確認 | 保存期間・台数・運用方法を文書で確認する |
| 決済 | 決済ID、トークン、口座振替情報、請求結果、返金 | 継続課金の移管、未収・返金 | カード番号等を複製せず承継方式を確認する |
| 講師・トレーナー | 雇用・委託区分、報酬、評価、資格、シフト、担当会員 | 人材承継、属人性、労務リスク | 初期は人数・契約形態・報酬帯に集計する |
| 問い合わせ・事故 | 苦情、けが、ハラスメント相談、返金、対応履歴 | 偶発債務、再発防止、対応品質 | 内容を類型化し、必要時のみ限定閲覧する |
| SaaS・ログ | アカウント、権限、操作ログ、API、連携先、バックアップ | 移行可能性、セキュリティ、運営継続 | 構成図・契約条件・権限一覧を先に示す |
病歴や医師等による健康診断等の結果は、個人情報保護法上の要配慮個人情報に該当します。一方、体重やトレーニング目標などの法的区分は、内容や取得経緯によって異なり得ますが、本人にとってプライバシー性の高い情報であることに変わりはありません。法的な分類だけで開示範囲を決めず、「漏れた場合に会員へどのような不利益や不安が生じるか」という観点を加えることが大切です。
個人情報保護法と事業承継の基本整理
個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」は、合併、分社化、事業譲渡などによる事業承継に伴って個人データが提供される場合、一定の枠組みの下で提供先を第三者に該当しないものとして扱う考え方を示しています。また、承継後は、承継前の利用目的の達成に必要な範囲内で取り扱うことが基本です。
ここから「事業譲渡なら、会員データは無条件で全部渡せる」と結論づけるのは適切ではありません。第一に、譲渡対象事業に関係するデータである必要があります。第二に、承継前の利用目的を確認しなければなりません。第三に、承継後に広告配信、他事業との横断分析、グループ会社での利用などへ用途を広げる場合は、利用目的の変更可能範囲や本人の同意の要否を個別に検討する必要があります。
契約締結前のDDでも必要な契約がある
通則編は、事業承継の契約を締結する前の交渉段階で、相手会社の調査を受けるために個人データを提供する場面にも言及しています。要件を満たす場合、あらかじめ本人の同意や第三者提供におけるオプトアウト手続を行わずに提供できるとしつつ、相手会社に安全管理措置を守らせるため、必要な契約を締結しなければならないとしています。
- 提供するデータの利用目的
- 閲覧、複製、加工、持ち出しを含む取扱方法
- 漏えい等が起きた場合の連絡、調査、証拠保全、費用負担
- 交渉が成立しなかった場合の返還、消去、バックアップの処理
- 再委託先、外部専門家、クラウドデータルームを利用する場合の条件
したがって、一般的な秘密保持条項だけで済ませず、個人データの取扱いに関する条項または別紙を設けることが実務的です。目的を「本件M&Aの検討」とだけ書くのではなく、財務・法務・事業DDのどの検証に使うか、閲覧者を誰に限定するか、どの期間保存できるかまで具体化します。
「匿名化」と「氏名を消すだけ」は同じではない
会員番号や氏名を削除しても、予約日時、店舗、年齢、担当トレーナー、特殊な受講履歴などを組み合わせれば、関係者が本人を推測できる場合があります。記事内でいう「匿名化」は、厳密な法的概念として一律に断定するものではなく、DDで本人を特定する必要を減らす実務上の処理を広く指します。実際には、仮IDへの置換、年齢の年代化、日付の月単位化、少数カテゴリの統合、自由記述の削除などを組み合わせます。
特に自由記述欄には、「勤務先」「病院名」「家族構成」「事故の経緯」など、想定外の個人情報が含まれやすい点に注意が必要です。表計算ファイルを出力した後、列名だけを見て安全と判断せず、自由記述のサンプルを権限者が確認し、原則として初期DDから除外します。
段階別に設計する会員データ開示
安全なDDは、情報を出すか出さないかの二択ではありません。案件の確度と検証目的に合わせて、情報の粒度を少しずつ上げます。次の六段階を基本にすると、過剰開示を避けながら、譲受候補企業に必要な判断材料を届けやすくなります。
第0段階：譲渡企業内でデータマップを作る
外部へ何かを出す前に、データの所在と責任者を把握します。会員管理、予約、スマートロック、決済、カメラ、問い合わせ、メール配信、スタッフ管理について、サービス名、契約名義、管理者、保存項目、保存期間、出力方法、API連携（システム間でデータを連携する仕組み）、委託先、国外処理の可能性を一覧にします。退職者の個人アカウントや、店舗端末に残るダウンロード済みCSV（表形式のデータファイル）も対象です。
この段階で、すでに利用目的や保存期間を超えて保有しているデータ、共有アカウント、退職者権限、保護されていないUSBメモリ（持ち運び可能な記録媒体）などが見つかることがあります。M&Aのために隠すのではなく、事実と改善状況を記録します。問題の存在そのものより、把握していないことや説明が変わることの方が、信頼を大きく損ねます。
第1段階：匿名概要書は集計値だけで構成する
初期打診では、実名の会員データは通常必要ありません。総会員数、稼働会員数、休会率、月次退会率、月会費帯、ARPU、入会経路、曜日・時間帯別利用率、予約枠稼働率、未収率などを集計して示します。小規模な店舗では、特定の属性が一人しかいない場合に個人が推測されるため、年代やコースをまとめ、少数セルを非表示にします。
なお、ARPUは「月間の会員関連売上 ÷ 対象会員数」など、分子と分母の定義を併記します。休会者を分母に含むか、入会金や物販売上を含むかによって値が変わるためです。定義の異なる数字を並べると、後のDDで説明が食い違います。
第2段階：秘密保持契約後も必要最小限にする
譲受候補企業が絞られた後は、店舗別・コース別・月別の推移を追加します。ここでも氏名や連絡先は外し、会員をランダムな仮IDに置き換えます。退会理由は選択肢別に集計し、自由記述は除外します。決済については成功・失敗・再請求・未収の状態を示し、カード番号、口座番号、セキュリティコード等を提供しません。
データルームでは、閲覧者を案件担当者と必要な専門家に限定し、多要素認証、アクセスログ、期限、透かし、ダウンロード制限を設定します。譲受候補企業内での共有先を「役職者なら誰でも」とせず、氏名または担当機能で特定します。
第3段階：詳細DDは検証目的ごとに分ける
基本合意後など、成約可能性が高まった段階では、サンプル検証や例外取引の確認が必要になることがあります。それでも、全会員の完全データを一括開示するのではなく、検証目的ごとにデータセットを分けます。
- 売上検証：仮ID、契約コース、請求額、決済状態、入退会年月を使用する
- 前受金検証：未消化回数、残高、利用期限を使用し、氏名は原則除く
- 稼働率検証：予約枠、担当者仮ID、予約・キャンセル状態を使用する
- 事故・苦情検証：事案の種類、発生日、対応、残存リスクを要約し、必要な案件のみ別室で閲覧する
- システム検証：データ項目、件数、権限、連携、出力仕様を確認し、本番資格情報は渡さない
どうしても本人単位の照合が必要な場合は、閲覧場所を限定し、画面共有または閲覧専用環境で確認する方法があります。目的を達成したらアクセスを閉じ、ダウンロード履歴など、サービス上で取得できるログを確認します。端末の画面撮影機能まで記録できるとは限らないため、サービス側の制御機能と契約上の禁止措置を併用します。
第4段階：最終契約からクロージング前まで
最終契約では、承継対象となるデータ、除外データ、利用目的、管理責任、事故時の協力、会員への案内、移行費用、データ品質、消去証明を具体化します。クロージング前に実データを先行移行する場合は、法的根拠、必要性、アクセス開始時期を専門家と確認します。譲受候補企業が営業利用を開始できる時点と、技術担当者が移行テストのために扱える時点を区別してください。
第5段階：成約後の本番移行と旧環境の整理
クロージング後は、契約で定めた対象だけを移行し、件数、金額、状態を照合します。移行が終わっても、旧SaaS、バックアップ、店舗端末、共有フォルダ、メール添付、外部委託先に複製が残ることがあります。法令、会計、紛争対応等のため保存が必要なデータと、業務上不要になったデータを分け、保持する場合は目的、期間、権限を定めます。
株式譲渡と事業譲渡で何が違うのか
株式譲渡では、原則として法人そのものが存続し、会員との契約主体やSaaSの契約名義が直ちには変わらない場合があります。ただし、支配株主や役員、社内権限、グループ連携が変わるため、「会社が同じだから何もしなくてよい」とは限りません。プライバシーポリシー、利用目的、委託先、共同利用、管理責任者、アカウント権限を確認します。
事業譲渡は、譲渡対象となる資産・契約・権利義務を個別に特定する取引です。会員契約、賃貸借、決済代行、予約SaaS、スマートロック、メール配信、ドメインなどについて、承継や再契約の可否を確認します。データを移せても、契約上アカウントを譲渡できない、決済トークンを別加盟店へ移せない、API連携を新規に設定し直す必要があるといったケースが考えられます。
| 項目 | 株式譲渡 | 事業譲渡 |
|---|---|---|
| 事業主体 | 法人は原則として存続する | 対象事業を別の主体が承継する |
| 会員契約 | 契約主体が同一でも支配・運用変更を確認 | 契約承継の方法、規約、案内を確認 |
| SaaS | 契約名義は同じでも管理者・権限を変更 | 譲渡可否、再契約、データ出力・取込を確認 |
| データ移行 | 環境を維持する場合でも権限棚卸しが必要 | 新環境への移行範囲と消去を明確化 |
| 利用目的 | 新たな用途やグループ利用の有無を確認 | 承継前の利用目的の範囲を基準に確認 |
| 従業員 | 雇用主が同一でも体制・規程変更を確認 | 労働契約承継には個別承諾等の検討が必要 |
従業員・トレーナーの情報は、会員情報とは別の権利利益に関わります。厚生労働省「事業譲渡又は合併を行うに当たって会社等が留意すべき事項に関する指針」では、事業譲渡で労働契約を承継させる場合、承継予定労働者から個別の承諾を得る必要があることなどが示されています。担当会員や評価だけを先に開示して本人が推測されることもあるため、初期DDでは人数、契約形態、資格構成、報酬帯、勤続分布などから始めます。
取引手法の全体像は、ジムM&Aの準備から成約後までの流れもあわせてご覧ください。個別の法務・労務・税務判断は、契約と事実関係によって異なるため、弁護士、社会保険労務士、税理士等への確認が必要です。
DDで実装したい安全管理措置
IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」は、経営者が認識すべき指針と、社内で対策を実践する手順を示しています。M&Aのデータルームも日常業務と切り離された例外ではありません。重要情報の棚卸し、リスクの把握、ルール、教育、事故対応を、案件責任者だけでなく経営課題として扱います。
アクセス権限は「必要な人に、必要な期間だけ」
- 案件ごとに専用データルームを設け、個人メールや無料ファイル転送を使わない
- 多要素認証を有効にし、共有IDを禁止する
- フォルダ単位で財務、法務、人事、システムの閲覧者を分ける
- 閲覧期限を設定し、担当変更・辞退・交渉終了時に即時無効化する
- 閲覧、ダウンロード、削除、権限変更のログを保存する
- 機密度の高い資料は画面閲覧のみとし、透かしに閲覧者と日時を表示する
ファイルを作る前に開示目的を記録する
「相手から求められたから」だけでは開示理由として不十分です。依頼項目ごとに、確認したいリスク、必要な項目、代替できる集計値、承認者、提供日、保存期限を記録します。例えば退会率の検証には、氏名や電話番号は通常不要です。月別の入退会年月と仮IDがあれば、コホート別の継続率を再計算できます。
外部専門家とSaaSも取扱範囲に含める
譲受候補企業だけでなく、弁護士、公認会計士、税理士、IT調査会社、データルーム事業者、移行ベンダーがデータを扱うことがあります。誰が再委託先を選び、どの国・地域でデータが処理され、事故時に何時間以内に連絡されるかを確認します。クラウド利用や国外処理に関する法的評価は、契約形態と実際のアクセス方法により異なるため、サービス名だけで判断しません。
交渉不成立時は消去証明まで確認する
データルームの権限を閉じても、ダウンロードファイル、メール、チャット、端末キャッシュ、バックアップに複製が残る可能性があります。交渉終了時に、返還・消去の対象、方法、期限、バックアップからの削除時期、法令上保持が必要な例外を確認し、責任者による完了報告を受けます。譲受候補企業が作成した分析表に仮ID単位の情報が残る場合も対象に含めます。
ジム固有データの引き継ぎ実務
会員・退会・休会データ
会員数は「登録された全件」ではなく、稼働、休会、未収、退会手続中、無料体験、法人会員などの状態を分けます。退会率は、月初会員数を分母にするか、平均会員数を分母にするかを統一します。退会理由の自由記述には、健康、家庭、勤務先、人間関係に関する記載が含まれ得るため、初期DDではカテゴリ別件数に変換します。
月会費・ARPU・回数券・未収金
料金データでは、通常月会費、キャンペーン価格、家族・法人割引、オプション、物販、パーソナル指導料を分けます。ARPUだけでは、割引終了後の価格、休会費、未収、返金が見えません。会員単位の検証が必要な場合も、氏名を仮IDへ置換し、決済手段は「カード」「口座振替」等の区分にとどめます。
未消化回数券や前受会費は、引き継ぎ後の役務提供義務や返金対応に関係します。詳しくは回数券・チケット未消化分の整理方法も参照してください。
入退館・顔認証・防犯カメラ映像
入退館ログは利用頻度やピーク時間の分析に役立ちますが、個人の行動履歴でもあります。初期DDは曜日・時間帯別の集計で足ります。顔画像や顔認証用データは、通常の会員名簿より慎重な取扱いが必要です。認証方式、保存場所、復元可能性、委託先、退会後の削除、代替認証手段を確認し、画像データそのものをDD資料へ複製しない設計を優先します。
防犯カメラは、事故・不正入館の確認に必要な一方、日常の利用状況を広範囲に記録します。譲受候補企業へ映像を一括提供するのではなく、カメラ台数、撮影範囲、保存日数、閲覧権限、事故件数を文書で確認し、個別事案は必要性が認められる場合に限定閲覧します。
予約・トレーニング・身体情報
予約データからは、枠稼働率、キャンセル率、担当者依存、リピート率を算出できます。これらの検証に氏名は不要です。身体測定、食事記録、けが、服薬、病歴、医師の指示などは、サービス継続上必要であっても、M&Aの価格検討で全件閲覧する必要性は通常高くありません。件数や管理方法を確認し、実データは成約後の安全な移行対象として分離します。
講師・トレーナー情報
パーソナルジムでは、担当トレーナーと会員の組合せが継続率に影響します。しかし、初期から氏名別売上や評価を出すと、店舗規模によっては本人と会員の双方が推測されます。まずは担当者仮ID、雇用・業務委託区分、資格、報酬方式、月間担当枠、継続率、退職予定の有無を整理します。個別面談や実名開示の時期は、秘密保持、案件確度、労働契約・業務委託契約、本人への説明を踏まえて決めます。
SaaS・API・決済代行
システム台帳には、管理画面URL、契約者、管理者、権限、認証方式、保存データ、API連携、請求、契約期間、解約予告、データ出力形式を記載します。パスワードやAPIキーは台帳に直接書かず、認証情報管理ツールで別管理します。M&A成立時は、既存アカウントの名義変更が可能か、新規契約とデータ移行が必要かをベンダーへ確認します。
決済データは、会員管理SaaSの画面上では一つに見えても、実際のカード情報を決済代行会社が保持している場合があります。トークンを新しい加盟店契約へ引き継げるかは、決済会社の契約・審査・仕様によります。安易にカード情報をCSVへ出力せず、ベンダー間移行、会員による再登録、旧契約の並行稼働などの選択肢を比較します。
失敗しにくいシステム移行の手順
1．移行対象と除外対象を確定する
現行システムの全項目を新環境へ移す必要はありません。現役会員、休会者、退会者、体験者、問い合わせのみの方を分け、契約・法令・利用目的・業務上の必要性から移行範囲を決めます。古い自由記述、重複アカウント、期限を過ぎた本人確認書類などは、移行前に整理する方が安全です。ただし、紛争や会計上の保存が必要な情報まで機械的に削除しないよう、専門家と確認します。
2．項目対応表と変換ルールを作る
旧システムの「会員状態」と新システムの「契約状態」が同じ意味とは限りません。休会、退会予定、未収停止、法人利用、家族会員など、値の定義を確認します。日付形式、文字コード、電話番号、住所、重複判定、同意履歴、担当者ID、店舗コード、税込・税抜の扱いも項目対応表に記録します。
3．本番データを使わないテストから始める
最初のテストには、構造だけを再現した架空データまたは十分に加工したデータを使います。その後、必要最小限の本番サンプルで、権限を限定した受入テストを行います。移行担当者が個人端末へファイルを保存しないよう、作業環境、暗号化、ログ、作業後の消去を定めます。
4．カットオーバー時点を固定する
予約、入退館、決済は日々更新されます。移行基準時点を決め、基準後の差分をどう反映するか設計します。月会費請求直前に決済環境を切り替えると、二重請求や請求漏れの影響が大きくなります。締日、休館日、予約の少ない時間帯を踏まえ、旧環境の書込み停止、差分取得、新環境の開始、障害時の切戻し条件を決めます。
5．件数だけでなく金額と状態も照合する
「1万件移った」だけでは移行成功とはいえません。在籍・休会・退会の件数、月会費合計、未収額、回数券残高、予約件数、店舗別会員数を旧新で照合します。無作為抽出した仮IDについて、契約状態、料金、利用期限、担当者、同意履歴が一致するか確認します。不一致は修正内容と承認者を記録します。
6．旧環境と移行用ファイルを片付ける
新環境が動いた後、旧SaaSの管理者、店舗端末、移行ベンダー、共有フォルダ、バックアップに残るデータを確認します。保持が必要な場合は読み取り専用にし、閲覧者と期限を限定します。移行用CSVは便利である反面、保護機能の弱いコピーになりやすいため、作業完了後に復元不能な方法で消去し、完了記録を残します。
漏えい等が疑われたときの初動
DDや移行中に、誤送信、公開設定、端末紛失、不正アクセス、委託先事故が起きる可能性があります。発見者が隠さず直ちに連絡できるよう、譲渡企業、譲受候補企業、支援機関、データルーム事業者の連絡先と責任分担を事前に定めます。
- 共有リンクの停止、アカウント無効化、端末隔離など被害拡大を防ぐ
- いつ、誰が、何を、どこへ送ったかを確認し、ログを保全する
- 対象データの種類、人数、要配慮個人情報や財産的被害の可能性を整理する
- 原因、影響範囲、再発防止を調査する
- 個人情報保護委員会への報告と本人通知の要否・期限を確認する
- 関係者間で説明内容を統一し、推測や未確認情報を広げない
個人情報保護委員会「漏えい等の対応とお役立ち資料」では、報告方法、記入例、報告フォームが案内されています。同委員会は、要配慮個人情報を含む事態、財産的被害のおそれがある事態、不正目的による漏えい等、1,000人を超える漏えい等など、法令上の報告・本人通知の対象となる類型を示しています。具体的な事案では、情報の性質、暗号化、第三者が閲覧した可能性等を踏まえ、速やかに専門家と確認してください。
会員情報引き継ぎチェックリスト
準備段階
- 会員管理、予約、入退館、決済、映像、問い合わせ、スタッフ、SaaSのデータマップを作成した
- 各データの利用目的、保存期間、管理責任者を確認した
- 退職者アカウント、共有ID、不要なCSV、USBメモリを棚卸しした
- プライバシーポリシー、会員規約、同意画面の版と改定履歴を保存した
- 事故・苦情・開示等請求の履歴を整理した
- 集計値の定義を統一し、元データとの照合方法を決めた
初期打診・DD段階
- 匿名概要書に氏名、連絡先、自由記述を含めていない
- 少数の属性から本人が推測されないよう集計区分を調整した
- 開示依頼ごとに目的と必要項目を記録した
- 秘密保持に加え、個人データの利用目的・取扱方法・事故時・不成立時の措置を契約化した
- データルームで多要素認証、期限、ログ、ダウンロード制限を設定した
- 閲覧者と外部専門家を特定した
- 仮IDの対応表をDD資料と別管理した
- 身体・健康申告、映像、決済情報を通常フォルダから分離した
- DD回答書に社内用の注記、コメント、不要な個人名が残っていないか確認した
最終契約・移行段階
- 株式譲渡・事業譲渡の手法に応じて契約主体と承継対象を確認した
- 会員契約、SaaS、決済、スマートロックの承継・再契約条件を確認した
- 承継前の利用目的と、承継後に予定する利用を比較した
- 会員への案内内容、時期、問い合わせ窓口を決めた
- 旧新システムの項目対応表と変換ルールを作った
- 架空データでテストし、本番サンプルの閲覧権限を限定した
- カットオーバー、差分移行、切戻し条件を決めた
- 件数、金額、状態、回数券残高、予約を照合した
- 旧環境、端末、移行ファイル、バックアップの処理を確認した
- 移行完了と消去完了を記録し、責任者が承認した
契約書で確認したい条項
個人データの取扱いは、DD契約、最終契約、業務委託契約、移行ベンダー契約で整合させます。条項名だけでなく、実際の運用で守れる内容かを確認してください。
- 対象データと除外データの定義
- 利用目的、閲覧者、再委託、国外取扱いの条件
- 複製、加工、ダウンロード、目的外利用の制限
- 技術的・組織的安全管理措置
- 漏えい等の連絡期限、調査協力、ログ保全、本人対応
- 交渉不成立・契約解除時の返還、消去、消去証明
- データ品質、重複、欠損、最新性に関する確認方法
- クロージング前後の管理責任とアクセス開始時点
- 会員からの開示、訂正、利用停止、苦情への対応分担
- 移行完了後の旧環境、バックアップ、法定保存データの扱い
中小企業庁「中小M&Aガイドライン（第3版）」は、中小M&Aの手続、支援機関との契約、DD、最終契約等を整理しています。会員データだけを独立したIT課題とせず、取引全体の情報管理、契約履行、説明責任の中に位置付けることが大切です。
よくある質問
Q1．秘密保持契約を結べば、会員名簿を渡してもよいですか？
秘密保持契約だけで、どのデータも無条件に提供できるわけではありません。契約前DDでは、利用目的、取扱方法、漏えい等が起きた場合の措置、交渉不成立時の措置などを定め、安全管理措置を守らせる必要があります。まず集計値や仮IDで目的を達成できないか検討してください。
Q2．事業譲渡では会員本人の同意が必ず必要ですか？
個人情報保護法の通則編は、事業承継に伴う個人データの提供について一定の枠組みを示していますが、個別案件で必要な手続は、譲渡対象、利用目的、提供時期、契約内容によって異なります。「必ず必要」「一切不要」と一律に判断せず、弁護士等へ確認してください。承継後に利用目的を広げる場合も別途検討が必要です。
Q3．株式譲渡なら会員への案内は不要ですか？
法人が存続しても、経営体制、管理責任者、委託先、サービス、問い合わせ窓口、利用目的が変わることがあります。法的義務の有無だけでなく、会員が安心して利用を続けるために何をいつ説明するかを検討します。変更がない事項と、変更する事項を分けて伝えることが有効です。
Q4．氏名を削除すれば安全ですか？
氏名を消しても、店舗、日時、年齢、担当者、特殊な利用履歴の組合せから本人が推測される場合があります。仮ID、年代化、月単位化、少数カテゴリの統合、自由記述の削除を組み合わせ、仮ID対応表は別管理します。
Q5．健康申告や身体測定値はDDで開示すべきですか？
初期の価格検討で個票を開示する必要性は通常高くありません。保存件数、項目、利用目的、権限、事故件数、保存期間を説明し、実データは成約後の安全な移行対象として分離する方法が考えられます。病歴等を含む場合は特に慎重な検討が必要です。
Q6．カード情報はどう引き継ぎますか？
カード番号を表計算ファイルへ出力して渡す方法は避けます。決済代行会社が保持するトークンの承継可否、新加盟店契約、会員による再登録、旧新環境の並行稼働を、決済会社と確認します。口座振替も収納代行契約とデータ仕様を確認してください。
Q7．防犯カメラ映像も譲渡対象になりますか？
対象範囲は取引契約、保存目的、保存期間等によって異なります。全映像をDDへ複製するのではなく、設備・運用・保存日数・閲覧権限を確認し、特定の事故映像は必要性を判断して限定閲覧します。旧機器を引き継ぐ場合は、管理者パスワードと遠隔アクセス権限も変更します。
Q8．交渉が不成立になったら何をすべきですか？
データルームを閉鎖し、ダウンロード、メール添付、端末、分析ファイル、バックアップを含む返還・消去を確認します。法令上保持する必要がある資料があれば、目的、権限、期間を限定します。完了報告または消去証明を受け、譲渡企業側でも記録を残します。
Q9．小規模ジムでも多要素認証やデータルームは必要ですか？
会員数が少なくても、一人当たりの情報が詳細であれば影響は小さくありません。無料メールへの添付や共有IDは避け、閲覧者、期限、ログを管理できる環境を選びます。すべてを高価な仕組みにするのではなく、情報の機密度に応じて閲覧専用、ダウンロード制限、仮ID化を組み合わせます。
Q10．会員への案内はいつ行うべきですか？
早すぎる案内は未確定情報による混乱を招き、遅すぎる案内は不信につながります。取引手法、契約条件、会費・サービス・スタッフへの影響、システム切替、法的手続を踏まえて時期を決めます。案内では、運営主体、効力発生日、変わる点・変わらない点、個人情報の利用目的、問い合わせ窓口を明確にします。
まとめ：情報を多く渡すことより、必要な情報を安全に渡すことが重要
ジムM&Aで会員情報を安全に引き継ぐには、データの棚卸し、段階的開示、契約、アクセス制御、仮ID化、移行テスト、件数・金額照合、旧環境消去を一つの計画として管理します。初期検討は集計値で進め、詳細DDでも検証目的に必要な項目だけを開示します。健康申告、映像、決済、自由記述は、通常の会員属性と分離して扱うことが重要です。
事業承継に伴う提供や契約前DDには、個人情報保護法上の考え方がありますが、M&Aだから何でも共有できるわけではありません。承継前の利用目的、取引手法、クラウドや委託先、会員規約、実際の運用を確認し、法務・情報セキュリティ・労務の専門家と連携してください。
会員情報を守りながらジムの譲渡準備を進めたい方へ
ジムM&A総合センターでは、匿名相談の段階から、開示資料の粒度、譲受候補企業への情報提供、会員・スタッフへの説明時期を整理します。譲渡企業様は、成功報酬を含め各種手数料0円です。店舗名や会員名簿を初期段階で公開せずにご相談いただけます。
参考にした一次資料
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
- 個人情報保護委員会「漏えい等の対応とお役立ち資料」
- IPA「中小企業の情報セキュリティ対策ガイドライン第4.0版」
- 中小企業庁「中小M&Aガイドライン（第3版）」
- 厚生労働省「事業譲渡又は合併を行うに当たって会社等が留意すべき事項に関する指針」
免責事項：本記事は2026年8月8日時点の公表資料を基にした一般的な情報であり、個別案件への法律・労務・税務・情報セキュリティ上の助言ではありません。個人情報の該当性、本人の同意、第三者提供、国外取扱い、労働契約承継、会員への通知等は、取引手法、契約、データ内容、利用目的、システム構成によって判断が異なります。実行前に弁護士、社会保険労務士、税理士、情報セキュリティ専門家および各SaaS・決済事業者へ確認してください。
