デリヘル顧客データ移行の手順｜Excel・旧システムから安全に移す方法

顧客データ移行で難しいのは、ファイルを読み込む操作ではありません。どの情報を移すか、同じ顧客をどう判定するか、どの店舗へ所属させるか、誰が閲覧できるか、移行後に正しいとどう証明するかを決めることです。

デリヘルの顧客データには、電話番号、別番号、利用履歴、指名、NG、注意事項、スタッフやキャストのメモなど、取扱いを限定すべき情報が含まれ得ます。不要な列まで新システムへ複製すると、利便性より漏えい範囲を増やします。

安全な移行は「棚卸し→最小化→整形・対応表→dry-run→照合・切替→旧データ処理」の順で進めます。本番データを最初からアップロードせず、匿名化した数行で形式とルールを確定してから、承認された経路だけを使います。

作業を始める前に、次の境界を書面にします。

対象は「移せるもの」ではなく「新しい業務に必要なもの」から選びます。利用目的が説明できない自由記述、重複バックアップ、退会・削除対象、出所不明の情報は、移行対象から外す候補です。

Excel、CSV、紙、スマートフォン、旧システム、スタッフ個人のファイルなど、顧客情報が存在する場所を棚卸しします。実値ではなく、次の管理情報を一覧化します。

• 保管場所と形式
• 所有者、管理責任者、閲覧できる人
• 店舗、対象期間、概算件数
• 含まれる項目の名前
• 更新頻度と最終更新日
• 重複する別の正本
• バックアップと削除方法
• 移行可否の承認者

この段階で顧客名や電話番号をチャット、通常メール、共有文書へ貼り付ける必要はありません。列名、形式、件数、匿名化した例だけで対応表を設計できます。

電話番号は顧客照合に役立ちますが、単独で完全な本人識別子にはできません。番号変更、家族・共用番号、入力ミス、別番号、非通知、同じ番号の複数登録があり得ます。

移行時に確認する処理:

• ハイフン、空白、全角数字、国番号、先頭ゼロをどう正規化するか
• 主番号と別番号を同じ形式で比較するか
• 同一番号の候補を自動統合せず、確認待ちにできるか
• 電話番号がない顧客をどう扱うか
• 店舗をまたぐ同じ番号を一人へ統合するか、店舗別に保持するか
• 統合時に履歴、NG、メモの出所を失わないか

重複候補は、件数を減らすために自動統合しません。統合・分離・保留の判断、根拠、実行者を記録し、元IDから新IDへの対応を追跡できるようにします。

マルチテナントシステムでは、すべての業務データを正しい店舗へ所属させる必要があります。顧客だけ移しても、受注、メモ、NG、指名履歴が別店舗や別顧客を参照すれば移行は成立しません。

対応表で保持するもの:

• 移行元システムと店舗識別子
• 移行元レコードID
• 移行先店舗ID
• 移行先レコードID
• 変換ルールの版
• 取込み結果、除外理由、エラー分類

固定のstore_idやuser_idをSQLへ直接書き込まず、承認された店舗マッピングから解決します。すべての関連データで同じ対応表を使い、別店舗のIDを参照しようとした行は取込みを停止します。

顧客情報の中でも、用途と閲覧範囲を分けます。

• 基本連絡情報: 業務上必要な担当者に限定
• 利用履歴: 店舗境界と業務権限に限定
• NG・注意事項: 判断に必要な範囲と根拠を定義
• 自由記述メモ: 不要な表現や目的外情報を除去
• 本人確認資料: 必要性、保管場所、期限を個別判断

本人確認資料や画像を、通常の顧客CSVや公開Storageへ混ぜません。移行が必要な場合も、非公開領域、固定された保存経路、最小権限、期限付きアクセス、監査記録を別に設計します。

個人情報の利用目的と安全管理については、個人情報保護委員会のガイドラインも確認し、業務・契約に応じて専門家へ相談してください。

取込みスクリプトを書く前に、移行元の各列を次のどれかへ分類します。

• そのまま移す
• 形式を変換して移す
• 複数列を一つへまとめる
• 一列を複数項目へ分ける
• 確認待ちとして隔離する
• 移行しない

対応表には、移行元列、移行先項目、型、必須、変換、空値、最大長、許容値、重複、エラー時処理、具体例を記載します。自由記述を独自ルールで完全に正規化できると考えず、長さ超過や解釈不能な値は切り捨てず例外として返します。

日付はタイムゾーンと営業日、金額は単位と税込・税別、列挙値は旧値から新値への対応を明示します。電話番号やIDだけでなく、文字数、数値精度、NULLと空文字も検査します。

dry-runは、本番へ書き込まず変換結果とエラーを確認する試行です。匿名化サンプルの次に、承認された隔離環境で対象データの複製を使います。

• 読込み行数、取込み予定、除外、エラーの合計が一致する
• 店舗別、期間別、状態別の件数が一致する
• 主番号、別番号、重複候補、番号なしが分類される
• 顧客と受注、メモ、NG等の参照が切れていない
• 別店舗参照や存在しないIDが拒否される
• 最大長、型、列挙値、日付、金額の異常が一覧化される
• ログへ実値、電話番号、住所、自由記述を出さない
• 同じ入力を再実行しても二重登録されない

エラー件数だけでなく、どの規則で何件が変換・除外されたかを構造化して残します。実値を表示せず、移行元IDの安全な参照や件数で調査できる設計にします。

切替前に、更新を止める時刻、差分取込み、確認者、戻す条件を決めます。

1. 移行対象と対応表を凍結する 2. 旧システムの更新停止または差分取得を開始する 3. バックアップと復元手順を確認する 4. 本取込みを一度だけ実行する 5. 件数・関係・例外・権限を照合する 6. 代表的な業務フローをテストする 7. 承認後に新システムを正本とする 8. 問題時は二重更新せず、定めた正本へ戻す

ロールバックは「新システムの行を全部消す」だけではありません。切替後に作られた新規データを失わないよう、切替時点、書込み停止、復元対象、再実行可否を事前に設計します。

移行完了後も、エクスポートCSV、作業用コピー、共有リンク、担当者PC、バックアップが残れば、保管場所が増えたままです。

完了時に記録するもの:

• 移行対象、件数、除外、未解決例外
• 対応表と変換仕様の版
• 実行者、確認者、承認日時
• 一時ファイルの所在と削除確認
• 旧システムの参照期間と解約・削除予定
• バックアップの保管期限と復元責任者
• 移行後に見つかった誤りの修正経路

法令、契約、業務上必要な保管期間を確認し、不要になった作業コピーは安全に削除します。削除できないバックアップは、アクセス制限と期限を明記します。

移行相談の最初に必要なのは、顧客データ本体ではありません。次の情報だけで概算と論点を整理できます。

• 現在の管理方法とシステム名
• ファイル形式と列名
• 店舗数と店舗別の概算件数
• 移行したいデータの種類
• 重複、別番号、自由記述の有無
• 切替希望時期と更新を止められる時間
• 旧システムから出力できる範囲

個人情報を含む実ファイルは、契約、取扱目的、責任者、転送方法、保管場所、削除条件を確定してから扱います。通常メールやチャットへの添付を移行手順にしません。