レガシーCRMデータの長期アーカイブ: 何を残し、どう管理するか

著者: Calvin D. · 更新日: 2026年4月18日

ある企業が2021年にSalesforceから移行しました。移行は順調に完了し、新しいCRMも稼働を開始しました。しかし、旧Salesforce組織をどう扱うかについて、誰も決断を下しませんでした。

2年後、同社はまだSalesforceのライセンス料を支払い続けていました。20ライセンス、月額150ドルずつ、年間3万6,000ドルという費用を、過去6ヶ月間で3人しか参照しなかった過去データへの read-only アクセスのために支出していたのです。解約しなかった理由は「必要になるかもしれないデータが何か入っているかもしれない」という一言に尽きました。

2023年に発生したデータガバナンスの問題(全システムにわたって特定のレコードを検索・削除することを求めるGDPRの消去請求)が、ついに決断を迫りました。同社はSalesforce組織の監査に3週間を費やし、大半のデータが新しいCRMと重複していることを確認し、重複しない部分をエクスポートしてからSalesforceを解約しました。先延ばしの代償: 不要なライセンス料7万2,000ドル、IT対応に3週間、そして2日で済むはずのGDPR対応が14日かかったこと。

2021年に下すべきだったアーカイブの決断が、2023年になってようやく実行されたのです。このガイドは、その決断を適切なタイミングで行うためのものです。移行後データ監査の後、つまり72時間および30日後の監査で新しいCRMのデータが完全であることが確認できたら、ソースシステムの役割はロールバックの安全網から過去データのアーカイブへと移行します。

法的に保持が義務付けられているデータ

何をアーカイブするかを決める前に、法的な保持義務を把握しておく必要があります。答えは地域、業界、レコードの種類によって異なります。

GDPR(欧州連合および英国):

GDPRは、多くの企業が完全には解決できていない矛盾を生み出しています。消去権(個人はデータの削除を請求できる)と正当な保持義務(法的・契約上の理由から一部のデータを保持しなければならない場合がある)の矛盾です。WikipediaのGDPR記事では、消去権(第17条)と法的義務による保持の例外について解説しており、アーカイブしたCRMデータのうち消去請求に応じる必要があるものを判断する際の参考になります。

実務上、CRMデータについては次の点が重要です。

• 正当なビジネス上の利益(有効な顧客関係、契約上の義務)があればデータを保持できます
• 消去請求には限られた例外を除き対応しなければなりません
• 保持期間を定義する必要があり、「無期限に保持する」はGDPR準拠とはなりません
• アーカイブしたレガシーデータがデータマップに含まれていることを証明できなければなりません(誰かが消去請求を行った場合、アーカイブ内のレコードも検索して削除できることが求められます)

米国のデータ保持規制:

CRMデータに関する連邦レベルの統一的な法律は存在しませんが、業種ごとのルールが適用されます。

• 金融サービス(SEC Rule 17a-4): 一部のビジネス記録は消去不可能な形式で3〜7年間保持する義務があります
• 医療(HIPAA): CRMに患者の健康情報(PHI)が含まれる場合、保持規則は厳格で削除手順の文書化が必要です
• カリフォルニア州(CCPA): GDPRに類似した削除権が消費者に認められており、アーカイブはその削除請求に対応できる必要があります

NISTのデータ保持と廃棄に関するガイドラインは、業種固有の規制に関わらず利用できる、保持期間の定義と安全な削除手順のための技術中立的なフレームワークを提供しています。

一般的な商業記録:

契約関連データ(取引条件、署名済み契約書、契約交渉に関する顧客とのやり取り)は、一般的な商業記録の保持義務の対象となることが多く、米国とEUでは財務記録について通常7年間の保持が求められます。

この決定の責任者:

法務またはコンプライアンス部門が、ITとRevOpsの意見を踏まえて決定します。ITが単独で判断できる事項ではありません。アーカイブ作業を始める前に、レコードの種類ごとに保持期間を明示した覚書に法務またはコンプライアンス部門からの署名をもらってください。ここで保持を決定するレコードの種類は、過去の活動履歴、メモ、メールの取り扱いで定義したスコープと直接重なります。エクスポート時に移行するか、アーカイブするか、破棄するかを選択した内容が、今度は正式な保持対応が必要なカテゴリを決定することになります。

保持ポリシーの判断フレームワーク

法的な基準を理解したうえで、レコードの種類ごとに保持ポリシーを適用します。

保持ポリシーのテンプレート:

意思決定者:

保持期間は法務またはコンプライアンス部門が承認します。RevOpsがレコードの種類とビジネス上の根拠を提案し、ITが実装(形式、保存場所、アクセス方法)を担当します。

決定を正式に文書化してください。 保持ポリシーは50ページの文書である必要はありませんが、レビューと承認を受けた書面として存在する必要があります。2年後に規制当局からデータ保持の慣行について問い合わせを受けた際に、「会議で話し合いました」という回答は通用しません。

アーカイブ形式の選択

アーカイブ形式によって、後でそのデータに対してできることが変わります。重視する基準は、移植性(ソースシステムなしでも読み取れるか)、検索性(誰かが検索できるか)、そしてコストです。

オプションA: CSV + JSONエクスポート

すべてのオブジェクトをフラットなCSVファイル(オブジェクトごとに1ファイル)としてエクスポートし、関係データをJSONまたは別のジョインテーブルとして保存します。各列のフィールド名と型を記載したデータディクショナリを添付します。

メリット: どのツールでも読み取れます。ベンダーロックインがありません。消去請求の監査が容易です。Excel、Google Sheets、その他のデータツールで開けます。

デメリット: クエリにはデータベースへの読み込みかスプレッドシートツールが必要です。オブジェクト間の関係は手動でジョインする必要があります。

推奨対象: ほとんどのチーム。シンプルで、耐久性があり、移植性も高い選択肢です。

オプションB: データベースダンプ

ソースCRMの基盤データベースのフルバックアップ(ベンダーが提供している場合)。

メリット: 必要に応じて新しいインスタンスにリストアできます。すべての関係をネイティブに保持します。

デメリット: 形式がプロプライエタリまたはバージョン依存であることが多い。リストアには対応するインフラが必要です。ツールなしでは人間が読めません。

推奨対象: ソースシステムを一時的にリストアする選択肢を残しておきたい(大規模な法的ディスカバリー請求への対応など)IT能力を持つチーム。

オプションC: クラウドデータウェアハウス(BigQuery、Redshift、Snowflake)

CRMデータをSQLでクエリできる構造化クラウドウェアハウスにエクスポートします。

メリット: 完全にクエリ可能です。SQL DELETEで消去請求に対応できます。スケーラブルです。BIツールと連携できます。

デメリット: クラウドインフラの構築と継続的なメンテナンスが必要です。取引先担当者が10万件未満のほとんどのチームには過剰です。

推奨対象: すでにデータウェアハウスを使用しており、CRMの履歴をその一部にしたいチーム。

オプションD: SaaSからクラウドへのマネージドエクスポート(Salesforce Data Archive、HubSpotのアーカイブツール)

一部のベンダーは、古いデータをより安価なストレージ層に移動しながらプラットフォーム上でクエリできる状態を維持するネイティブのアーカイブ機能を提供しています。

メリット: 使い慣れたプラットフォームのインターフェイス内で完結します。移行作業が最小限です。

デメリット: ベンダーのライセンスが引き続き必要です。ソースシステムを実際には廃止できません。「使っていないシステムにお金を払い続けている」問題を解決しません。

推奨対象: 完全な廃止を計画しながら、短期的なアーカイブソリューションが必要な企業。

アーカイブ形式の比較:

ストレージオプションとコスト

アーカイブ形式を選択したら、保存場所を決定します。

コールドストレージ(AWS Glacier、Azure Archive、Google Coldline):

• コスト: 約0.004ドル/GB/月(AWS Glacier Deep Archive)
• 取得時間: 数時間〜数日
• 推奨対象: 法的・コンプライアンス上の理由で必要になる可能性はあるが、定期的なアクセスは想定しないデータ
• 取得コスト: 特急の場合0.02ドル/GB、標準は低め

10万件の取引先担当者を持つ5年分のCRMエクスポート(100GB相当)の場合、コールドストレージのコストは月額約0.40ドルです。5年間のアーカイブでも保存コストはおよそ24ドルです。これは誤りではありません。

標準クラウドストレージ(AWS S3、Azure Blob、Google Cloud Storage):

• コスト: 約0.023ドル/GB/月(AWS S3 Standard)
• 取得: 即時
• 推奨対象: 月次・四半期ごとなど時折アクセスするデータ
• コストとアクセス速度のバランスが取れた選択肢

クラウドデータウェアハウス(BigQuery、Redshift、Snowflake):

• ストレージコスト: 約0.02ドル/GB/月(BigQuery)
• クエリコスト: スキャンTBごとに追加料金
• 推奨対象: 週次でクエリするデータや、セルフサービスの検索をサポートする必要があるデータ

オンプレミス:

• コスト: ハードウェアの設備投資+ITメンテナンス
• アクセス: 即時
• 推奨対象: 既存のオンプレミスインフラを持ち、データ主権要件が厳しい組織
• デメリット: メンテナンス負担、ハードウェア障害リスク

中堅CRMから移行するほとんどの企業の場合:

2年以上前のデータにはコールドストレージが適切なデフォルトです。参照される可能性がある過去2年分のデータは標準クラウドストレージに保存します。クラウドウェアハウスは、すでに運用中であり追加コストが最小限の場合のみ検討します。

営業チームへのアクセス経路の構築

担当者は過去のレコードを求めてきます。最初の問い合わせが来る前にプロセスを整えておきましょう。

現実的なリクエスト件数:

移行後最初の30日間は、50人の担当者につき5〜15件のリクエストを想定してください。90日後には月1〜3件まで減少します。6ヶ月後には、ほぼゼロになります。初期は高い件数に対応し、その後は定常的な低件数処理に移行する計画を立ててください。

実用性の高い順にアクセスオプションを紹介します:

オプション1: 90日間はソースシステムを read-only で維持する

最もシンプルなアプローチです。すぐに廃止せず、90日間は旧CRMへの read-only アクセスを担当者に提供します。その後はリクエスト件数が十分に減少するため、手動の検索プロセスで対応できます。

コスト: ライセンス料の1四半期分。20ユーザー×月額75ドルの read-only プランで4,500ドルです。並行するアクセスシステムの構築を避けられることを考えれば、ほとんどのチームにとって投資対効果は十分です。この90日間の read-only 期間はロールバック計画を実行可能にするための条件でもあります。新しいCRMが完全に検証され、ロールバックの期限が過ぎるまでは廃止プロセスを開始しないでください。

オプション2: ITへの依頼フォーム

read-only 期間が終了した後は、「ITに依頼する」がアクセス経路になります。担当者が取引先担当者名と理由をOpsまたはITにメールで送信し、ITが24時間以内にアーカイブを検索して回答します。

月5件未満の低件数では機能しますが、リクエストが継続的に多い場合はスケールしません。

オプション3: セルフサービスのアーカイブ検索(技術的なチーム向け)

取引先担当者名やメールアドレスでアーカイブを検索できる軽量なWebUIまたはデータベースクエリツールです。セットアップに時間がかかりますが、スケールしてもIT負荷を軽減できます。

現実的な適用先: Tableau、Looker、MetabaseなどのBIツールをすでに使用しており、アーカイブをデータソースとして追加できるチーム。

ソースシステムのクリーンな廃止

廃止は最後のステップであり、急ぐと問題を引き起こします。

廃止チェックリスト:

• アーカイブエクスポートの検証完了(行数がソースと一致し、サンプルレコードが読み取れる)
• 保持ポリシーへの法務・コンプライアンス部門の署名取得
• ソースCRMを参照しているすべてのアクティブなインテグレーションを特定し、リダイレクトまたは廃止
• SSO/SAML設定の更新(IDプロバイダーから旧CRMを削除)
• 旧CRMに接続されているメールやカレンダーの同期を切断
• 旧CRMが発行したAPIキーとOAuthトークンを、接続されているシステム内で失効または更新
• ベンダーとの契約解約を正しい通知期間(通常30日)で申請
• 内部ドキュメントの更新(旧システムを参照するランブック、ITドキュメント)
• データマップから旧CRMを削除(GDPRコンプライアンス文書として特に重要)
• 解約当日に最終バックアップを取得(念のための最終確認)

解約のタイミング:

ほとんどのCRMベンダーは、請求期間終了の30日前までに書面での通知を求めています。契約内容を確認してください。解約ウィンドウを1日でも過ぎると、次の全請求サイクル分が発生する可能性があります。

インテグレーションは廃止で最も多く発生する失敗箇所です。 旧CRMへAPIコールを行う内部ツールは、廃止翌日からエラーを返し始めます。解約前にすべてのインテグレーションを監査してください。コードリポジトリ、Zapierのワークフロー、自動化ツール内で旧CRMのドメイン名を検索するだけで、誰も覚えていなかった接続が見つかることがよくあります。この監査では、レガシーシステムがオフラインになる前にメールとカレンダーの同期が新しいCRMに完全に切り替えられていることも確認します。

よくある落とし穴

ベンダーのツールでしか読めないプロプライエタリ形式でアーカイブする。 アーカイブがSalesforceのツールでしか解釈できない形式であれば、Salesforceへの支払いが永続することになります。オープン形式でアーカイブしてください。CSV、JSON、SQL、または標準的なデータベース形式が推奨です。PwCのデータガバナンスに関する調査では、長期データ保持においてベンダー中立のオープン形式を推奨しており、ベンダー関係に依存せずアーカイブデータへのアクセスと監査が可能であることを責任あるデータガバナンスの要件としています。

保持上の有用性がなくなっても、ソースシステムを継続稼働させる。 コストは静かに積み上がります。移行が完了する前に廃止日を設定してください。プロジェクト計画に組み込み、成果物として扱います。

アーカイブの場所とアクセス方法を文書化しない。 2年後には、移行を担当した人物がいなくなっている可能性があります。スタッフの入れ替わりを乗り越えられる場所に、アーカイブの保存場所、アクセス認証情報、クエリ手順を文書化しておいてください。

レガシーシステムに紐づいたAPIキーとインテグレーションを忘れる。 旧CRMに接続されていたすべてのツール(メール同期、マーケティングオートメーション、データエンリッチメント)は、廃止前に監査が必要です。新規取引先担当者に対して旧CRMのAPIを介して確認メールを送信するZapierのワークフローを1つ見落とすだけで、解約翌日から機能が壊れますが、何週間も気づかれないかもしれません。

次のステップ

移行後90日のマークより前に、保持ポリシー文書とアーカイブ形式の決定を完了させてください。「移行完了」から「廃止完了」までの期間は通常90〜180日です。その時間を有効に使いましょう。

アーカイブは過去の活動履歴、メモ、メールの取り扱いと直接つながっています。エクスポート時に移行ではなくアーカイブを選択したレコードは、担当者から問い合わせがあったときにアーカイブ内で見つけられる必要があります。

移行後データ監査は、アーカイブの決断を始める良いタイミングを示してくれます。72時間と30日後の監査で新しいCRMが完全であることが確認できたら、ソースシステムの役割は「ロールバック時のバックアップ」から「過去データのアーカイブ」へと移行します。廃止プロセスを開始するのはそのタイミングです。

ロールバック計画については、ソースシステムの廃止を開始した時点でロールバックはもはや選択肢ではなくなります。新しいCRMが完全に検証されるまで廃止プロセスを開始しないでください。

関連ガイド

• 移行後データ監査: 何を、いつ確認するか
• 過去の活動履歴、メモ、メールの取り扱い
• ロールバック計画: 使わずに済むことを願いながら
• 移行前にデータを準備する
• CRMワークフローオートメーション: データが整った後に構築するもの
• CAC回収とSaaSの存続: 移行コストの失敗を測る