CRMバックアップの方法｜顧客データ・設定・添付ファイルを安全に保存する手順

CRMには、顧客名や連絡先だけでなく、商談、問い合わせ、契約、活動履歴、添付ファイル、営業担当者のメモなど、事業活動を継続するために重要な情報が保存されています。誤操作、大量更新の失敗、連携アプリの不具合、権限の悪用、ランサムウェアなどによってデータが変更または削除されると、営業や顧客対応が停止する可能性があります。

クラウド型CRMを利用している場合でも、自社でバックアップ計画を用意する必要があります。CRM事業者がシステム障害に備えて実施する基盤側のバックアップと、利用者の誤操作によって失われた個別データを元に戻す業務用バックアップは、目的が異なるからです。Salesforceも、基盤障害に備えたバックアップが、利用者の誤操作などによる業務データの復元を必ずしも代替するものではないと案内しています。

CRMバックアップでは、データを書き出すだけでなく、何を、どの頻度で、どの期間保存し、どの順番で復元するかを決める必要があります。本記事では、CRMバックアップの設計、手動エクスポート、APIによる自動化、設定情報の保存、復元テスト、主要CRM製品ごとの方法を詳しく解説します。

1. CRMバックアップとは

CRMバックアップとは、CRM内に保存された顧客情報、商談、問い合わせ、活動、ファイル、設定などを、障害や誤操作が発生した際に復元できる形で複製・保存することです。単なる一覧表の出力ではなく、復元可能性まで考えて設計します。

1.1 CRMバックアップの定義

CRMバックアップは、特定時点のCRMデータや設定を別の保存先へ複製し、データ消失、破損、誤更新、サイバー攻撃などが起きた際に回復できるようにする取り組みです。対象には顧客レコードだけでなく、レコード同士の関連、添付ファイル、項目定義、業務自動化も含まれます。

バックアップファイルが存在していても、CRMへ正しく戻せなければ十分ではありません。データ形式、元のレコードID、関連情報、文字コード、復元順序を記録し、定期的に復元テストを行います。

1.2 CRMバックアップが必要な理由

CRMでは、一人の管理者による誤った一括更新が、数万件の顧客データへ影響する場合があります。連携アプリやワークフローの設定ミスによって、正しい値が短時間で上書きされる可能性もあります。

ごみ箱が用意されていても、削除以外の変更には対応できない場合があります。住所や商談金額を誤って上書きした場合、削除済みレコードの復元機能だけでは元の値へ戻せません。

1.3 エクスポートとバックアップの違い

エクスポートは、現在のデータをCSVなどの形式で外部へ書き出す操作です。分析、共有、移行にも利用されるため、必ずしも復元を目的としていません。

バックアップは、復元を前提にデータ、関連情報、設定、履歴を保存します。エクスポートファイルもバックアップの一部として利用できますが、関連や添付ファイルが含まれているか、再取り込みできる形式かを確認する必要があります。

1.4 CRM事業者側の保護との違い

クラウド型CRMの事業者は、サービス継続や基盤障害に備えた冗長化やバックアップを実施しています。しかし、利用者が正常な権限で実行した誤削除や、連携アプリによる誤更新まで、任意の時点へ個別復元できるとは限りません。

Microsoft Power Platformでは環境のシステムバックアップが自動作成されますが、復元先、保持期間、環境種別などに条件があります。また、データベースバックアップをオフライン用として直接ダウンロードする機能は提供されていません。

1.5 CRMバックアップの目的

CRMバックアップの目的は、データを永久保存することではなく、事業に必要な時間内で正常な状態へ戻すことです。どの程度のデータ損失を許容できるか、どの程度の時間で業務を再開すべきかを決めます。

営業活動、顧客対応、請求処理など、停止時の影響が大きい業務から優先します。重要度の低いテストデータまで同じ頻度と費用で保存する必要はありません。

2. CRMでバックアップすべきデータ

CRMバックアップでは、連絡先だけを保存しても十分ではありません。商談、問い合わせ、活動、添付ファイル、関連、設定など、CRM内で業務を再現するために必要な情報を洗い出します。

2.1 顧客・企業・見込み顧客データ

氏名、会社名、メールアドレス、電話番号、住所、顧客分類などは、CRMの中心となるデータです。独自項目を使用している場合は、項目名と内部識別子も保存します。

個人情報が含まれるため、バックアップ先にもCRM本体と同等以上のアクセス制御が必要です。利用目的を終えたデータを無期限に保存せず、社内規定や法的要件に沿った削除方針を定めます。

2.2 商談・契約・問い合わせデータ

商談金額、受注予定日、営業段階、契約状況、問い合わせ内容などは、売上予測や顧客対応を再開するために必要です。

顧客レコードと商談レコードを別々に保存する場合は、両者を結ぶIDを保持します。表示名だけで関連付けると、同名企業や名称変更によって誤ったレコードへ結び付く可能性があります。

2.3 活動履歴・メモ・タスク

電話、メール、会議、営業メモ、タスクなどの活動履歴は、顧客とのやり取りを把握するために重要です。顧客レコードだけを復元しても、過去の対応内容がなければ営業やサポートを継続できません。

製品の標準バックアップが活動情報を含むとは限りません。HubSpotのCRMデータバックアップには、連絡先、会社、商談などの主要オブジェクトが含まれますが、関連情報と活動データは含まれないと案内されています。

2.4 添付ファイルと画像

契約書、見積書、問い合わせ添付、顧客提供資料などのファイルは、レコード本体とは別の保存領域にある場合があります。CSVを書き出しただけでは、ファイル本体を取得できないことがあります。

ファイル名だけでなく、元のレコードID、ファイルID、版、作成日時、作成者を記録します。復元時にどのレコードへ接続すべきかを判断できる状態にします。

2.5 設定・監査・連携情報

独自項目、画面構成、権限、承認処理、業務自動化、レポートなどもバックアップ対象です。データが残っていても、設定が失われると業務を同じ状態で再開できません。

監査ログ、連携アプリ一覧、API設定、定期処理の一覧も保存します。ただし、パスワードやAPI秘密情報を設定ファイルへ平文で記録してはいけません。

3. CRMバックアップの主な方法

CRMバックアップには、手動エクスポート、定期エクスポート、API連携、CRM標準のバックアップ機能、外部製品を利用する方法があります。必要な復旧時間と予算に応じて組み合わせます。

3.1 手動エクスポート

手動エクスポートは、管理画面から必要なデータをCSVや表計算形式で書き出す方法です。導入が容易で、設定変更や大量更新の前に保存する方法として適しています。

一方、担当者が操作を忘れる可能性があり、頻度を高めにくい点が課題です。取得範囲やファイル名が毎回異なると、復元時に混乱するため、手順書を用意します。

3.2 定期エクスポート

定期エクスポートでは、CRMの標準機能を使い、毎週または毎月などの周期でデータを書き出します。担当者の操作忘れを減らせます。

製品や契約プランによって実行頻度が異なります。SalesforceのData Export Serviceでは、契約版に応じて週次または月次のエクスポートが利用できます。

3.3 APIによる自動バックアップ

APIを利用すると、毎日または数時間ごとに変更データを取得し、自社のクラウドストレージやデータベースへ保存できます。

柔軟性が高い一方、認証、ページ分割、API利用上限、削除検知、エラー再実行などを設計しなければなりません。開発後もAPI仕様変更への対応が必要です。

3.4 CRM標準のバックアップ機能

一部のCRMには、特定時点のデータを保存し、管理画面から変更や削除を元に戻す機能があります。単なるCSV出力より復元操作が簡単になる場合があります。

ただし、対象オブジェクト、保存期間、復元可能な変更、契約プランを確認します。標準バックアップがあっても、外部保存や長期保存が別途必要になる場合があります。

3.5 外部バックアップ製品

CRM専用の外部バックアップ製品では、定期保存、差分検出、項目単位の復元、監査、長期保存などを利用できる場合があります。

導入時は、保存場所、暗号化、データ所在、復元方法、サービス終了時のデータ取得方法を確認します。CRM管理者だけで契約せず、情報システム、法務、情報セキュリティ担当者も確認します。

4. RPO・RTOと保存期間の決め方

バックアップ頻度は「毎日で十分」と一律に決めるものではありません。失ってよいデータ量と、業務を再開するまでの時間から逆算します。

4.1 RPOを決める

RPOは、障害発生時にどの時点までのデータ損失を許容するかを示す目標です。RPOが24時間なら、最悪の場合は直近24時間分の変更が失われる可能性を受け入れます。

一日に数件しか変更がないCRMと、数分ごとに受注や問い合わせが追加されるCRMでは、必要な頻度が異なります。変更件数と業務影響を確認します。

4.2 RTOを決める

RTOは、障害発生後にCRM業務を再開するまでの目標時間です。バックアップがあっても、復元に数日かかる構成では、短いRTOを達成できません。

復元手順の複雑さ、担当者の連絡体制、データ量、CRMの取込み速度を考慮します。営業や問い合わせ対応が停止した場合の損失から、現実的な目標を設定します。

4.3 バックアップ頻度を決める

毎日の変更件数が多いCRMでは、日次バックアップだけでは不足する可能性があります。APIを利用した数時間ごとの差分保存や、標準機能の短期間復元を組み合わせます。

設定変更やデータ移行の直前には、通常周期とは別に手動バックアップを作成します。大量処理の前後を比較できるようにします。

4.4 保存期間を決める

誤りがすぐに発見されるとは限りません。誤った自動更新が数週間後に判明する可能性を考え、日次、週次、月次の版を組み合わせて保存します。

個人情報を含むバックアップを無期限に保持すると、安全上の負担が増えます。顧客データの保存方針、契約、法的要件に合わせて削除時期を決めます。

4.5 データの重要度で分ける

すべてのデータに同じRPOとRTOを適用すると、費用が大きくなる可能性があります。受注や問い合わせは高頻度、古い参考資料は低頻度など、分類します。

重要度の判定では、売上、顧客対応、法的義務、再作成の難しさを確認します。単にデータ件数が多いという理由だけで優先度を決めません。

5. バックアップ前の権限と安全対策

CRMバックアップには大量の顧客情報が含まれます。バックアップを作成することで、新しい情報漏えい経路を作らないようにします。

5.1 最小権限で実行する

バックアップ専用アカウントには、取得に必要な参照権限だけを付与します。設定変更やレコード削除の権限を不用意に与えません。

一部の標準バックアップ機能は管理者権限を必要とします。その場合も、日常作業用アカウントと分離し、利用時だけ厳格に管理します。

5.2 多要素認証を設定する

バックアップファイルへアクセスできる管理者やクラウドストレージには、多要素認証を設定します。

バックアップ用APIの認証情報が盗まれると、CRMデータ全体を取得される可能性があります。利用元IP、実行環境、接続時間を制限できる場合は設定します。

5.3 バックアップを暗号化する

バックアップは保存時と転送時の両方で暗号化します。CRMから取得したZIPやCSVを、個人のパソコンや共有フォルダーへ平文で放置してはいけません。

CISAは、重要データのバックアップを暗号化し、オフラインでも保管し、復元可能性と完全性を定期的に検証することを推奨しています。

5.4 暗号鍵を分離する

暗号化されたバックアップと復号鍵を同じ場所へ保存すると、攻撃者に同時取得される可能性があります。鍵管理サービスや、アクセス権の異なる保管場所を使用します。

担当者が退職した場合でも復号できるようにしつつ、一人の担当者だけで自由に持ち出せない構成にします。鍵の更新と失効手順も決めます。

5.5 操作履歴を保存する

誰が、いつ、どのCRMから、どの範囲を取得し、誰がダウンロードしたかを記録します。

保存先のアクセスログも有効にし、大量ダウンロードや通常と異なる地域からの接続を検知します。バックアップの作成者と検証者を分ける方法もあります。

6. 標準エクスポートでバックアップする方法

標準エクスポートは、CRMバックアップを始める際の現実的な方法です。ただし、取得範囲と復元方法を確認せずにCSVを保存するだけでは不十分です。

6.1 対象データを選択する

最初に、顧客、企業、商談、問い合わせ、商品、活動、独自オブジェクトなど、必要な対象を一覧化します。

「すべてのデータ」という選択肢でも、添付ファイル、メール本文、監査履歴、削除済みデータなどが含まれない場合があります。製品の説明を確認します。

6.2 出力形式を選択する

CSVは多くのCRMで利用でき、長期的に読み取りやすい形式です。文字コード、改行、区切り文字、日時、複数選択項目の表現を確認します。

表計算ソフトでCSVを開くと、先頭のゼロが消えたり、長い番号が指数表記に変わったりする場合があります。元ファイルを直接編集せず、作業用の複製を使用します。

6.3 レコードIDと関連IDを保存する

復元では、顧客と商談、企業と問い合わせなどの関連を再構築する必要があります。CRM内部の一意なIDを必ず保存します。

表示名だけで復元しようとすると、同名レコードを区別できません。親ID、所有者ID、作成者ID、関連付けIDも可能な範囲で取得します。

6.4 ファイル名と目録を統一する

バックアップファイル名には、製品、環境、取得日時、対象、完全・差分の区別を含めます。

ファイル名の例

crm-production-2026-07-17T020000Z-contacts-full.csv crm-production-2026-07-17T020000Z-deals-full.csv crm-production-2026-07-17T020000Z-manifest.json

目録ファイルには、取得日時、対象オブジェクト、件数、ファイルサイズ、ハッシュ値、実行結果を記録します。

6.5 出力結果を検証する

エクスポート完了の通知だけで成功と判断せず、ファイル数、レコード数、容量、文字化け、空ファイルを確認します。

前回のバックアップと比較し、件数が急にゼロになった、容量が極端に減ったなどの異常を検知します。定期的に一部のレコードを実際に読み込み、必要な項目が含まれているか確認します。

7. APIで自動バックアップする方法

APIによるバックアップは、頻度や保存先を柔軟に設定できます。一方で、取りこぼしや重複を防ぐ設計が必要です。

7.1 完全バックアップと差分バックアップを組み合わせる

完全バックアップは全レコードを取得するため復元しやすい反面、時間とAPI利用量が増えます。差分バックアップは変更されたレコードだけを取得するため効率的です。

一般的には、週次または月次の完全バックアップと、日次または数時間ごとの差分バックアップを組み合わせます。削除されたレコードを検知する方法も用意します。

7.2 ページ分割を処理する

多くのCRM APIは、一回の応答で取得できるレコード数を制限しています。次ページ用の識別子やURLがなくなるまで繰り返します。

途中で失敗した場合に最初からやり直すのではなく、最後に完了したページや時刻を記録します。ただし、取得中にデータが更新される場合の一貫性も考慮します。

7.3 API利用上限を守る

API呼び出し回数や同時接続数には上限があります。通常業務の連携処理を妨げない時間帯と速度で実行します。

上限エラーが返された場合は、一定時間待って再試行します。無制限に即時再試行すると、障害を長引かせる可能性があります。

7.4 自動保存処理を実装する

以下は、ページ分割されたCRM APIからデータを取得し、圧縮JSONとハッシュ値を保存する構成例です。実際のURL、認証、項目名は利用中のCRMに合わせます。

Pythonコード例

from __future__ import annotations import gzip import hashlib import json import os from datetime import datetime, timezone from pathlib import Path from typing import Any import requests API_BASE_URL = os.environ["CRM_API_BASE_URL"] ACCESS_TOKEN = os.environ["CRM_ACCESS_TOKEN"] BACKUP_DIR = Path(os.environ.get("CRM_BACKUP_DIR", "./crm-backups")) BACKUP_DIR.mkdir(parents=True, exist_ok=True) def fetch_all_records(object_name: str) -> list[dict[str, Any]]:    records: list[dict[str, Any]] = []    next_url: str | None = f"{API_BASE_URL}/{object_name}"    headers = {        "Authorization": f"Bearer {ACCESS_TOKEN}",        "Accept": "application/json",    }    while next_url:        response = requests.get(            next_url,            headers=headers,            timeout=60,        )        response.raise_for_status()        payload = response.json()        records.extend(payload.get("results", []))        next_url = payload.get("next")    return records def save_backup(    object_name: str,    records: list[dict[str, Any]], ) -> dict[str, Any]:    timestamp = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ")    filename = f"{object_name}-{timestamp}.json.gz"    path = BACKUP_DIR / filename    raw_data = json.dumps(        records,        ensure_ascii=False,        separators=(",", ":"),    ).encode("utf-8")    with gzip.open(path, "wb") as backup_file:        backup_file.write(raw_data)    digest = hashlib.sha256(path.read_bytes()).hexdigest()    return {        "object": object_name,        "filename": filename,        "record_count": len(records),        "sha256": digest,        "created_at": timestamp,    } def main() -> None:    manifest: list[dict[str, Any]] = []    for object_name in ["contacts", "companies", "deals"]:        records = fetch_all_records(object_name)        manifest.append(save_backup(object_name, records))    manifest_path = BACKUP_DIR / "manifest.json"    manifest_path.write_text(        json.dumps(manifest, ensure_ascii=False, indent=2),        encoding="utf-8",    ) if __name__ == "__main__":    main()

アクセストークンはコードへ直接書かず、秘密情報管理機能や環境変数から取得します。保存後は、暗号化された外部ストレージへ転送します。

7.5 実行失敗を監視する

定期処理が起動しなかった、認証が切れた、項目権限が変わったなどの失敗を検知します。成功通知だけでなく、失敗通知と未実行通知を用意します。

取得件数、API応答時間、再試行回数、ファイル容量を監視します。前回との差が一定以上になった場合は、管理者へ通知します。

8. 設定・メタデータをバックアップする方法

CRMのデータだけを保存しても、項目、画面、権限、業務自動化が失われると同じ環境を再現できません。設定情報も版管理します。

8.1 メタデータの重要性

メタデータとは、CRMの項目、オブジェクト、画面構成、権限、入力規則、業務自動化など、データの構造や動作を決める情報です。

項目が削除された状態でレコードだけを戻しても、その項目の値を正しく取り込めない可能性があります。復元では、設定を先に戻してからデータを取り込みます。

8.2 項目と画面構成を保存する

標準項目と独自項目の内部名、データ型、選択肢、必須条件を一覧化します。画面レイアウトや利用者ごとの表示条件も保存します。

項目の表示名は変更されることがあるため、内部識別子を基準に管理します。項目削除前には、利用中のレポート、自動化、API連携も確認します。

8.3 ワークフローと自動化を保存する

承認処理、通知、担当者割当、項目更新などの自動化は、データを大量に変更する可能性があります。設定内容と公開版を記録します。

変更前にバックアップを作成し、検証環境で動作を確認します。誤った処理が公開された場合に、前の版へ戻せるようにします。

8.4 連携設定を記録する

CRMと会計、メール、広告、問い合わせシステムなどの連携について、接続先、同期方向、対象項目、実行周期を記録します。

API秘密情報そのものは設計書へ書かず、秘密情報管理機能の参照名だけを記載します。復元後に認証情報を再発行する手順も準備します。

8.5 バージョン管理を利用する

設定をファイルとして取得できるCRMでは、Gitなどのバージョン管理システムへ保存します。誰が何を変更したかを比較できます。

メタデータ目録の例

crm:  product: example-crm  environment: production  exported_at: 2026-07-17T02:00:00Z metadata:  objects:    - contacts    - companies    - deals  workflows:    - lead-assignment    - renewal-reminder  permission_sets:    - sales-user    - sales-manager    - crm-admin restore_order:  - objects  - fields  - permissions  - workflows  - reports  - data  - files

秘密情報、顧客データ、個人情報をソースコード管理へ含めないようにします。メタデータと実データの保存先を分けます。

9. 添付ファイル・活動履歴・関連情報を守る方法

CRMバックアップで見落とされやすいのが、レコード以外の情報です。添付ファイルや活動履歴がなければ、顧客対応を完全には再現できません。

9.1 添付ファイルを保存する

添付ファイルを個別に取得し、元のレコードIDとファイルIDを目録へ記録します。ファイル名だけでは同名ファイルを区別できません。

容量が大きい場合は、レコードバックアップとファイルバックアップを別の周期で実行できます。ただし、同じ基準時点を判断できるようにします。

9.2 活動履歴を保存する

電話、会議、タスク、メモ、メール履歴は、製品によって別オブジェクトや別機能として管理されています。

標準の「全データバックアップ」が活動を含むか確認します。含まれない場合は、活動用API、個別エクスポート、メール保存機能を利用します。

9.3 レコード間の関連を保存する

顧客と企業、企業と商談、問い合わせと商品などの関連情報は、別の関連テーブルやIDとして保存される場合があります。

関連情報が失われると、レコード自体は存在していてもCRM上でつながりません。親子関係、多対多関係、担当者の所有関係を確認します。

9.4 メールデータを確認する

CRM画面に表示されるメールが、CRM本体へ保存されているとは限りません。外部メールサービスから都度表示されている場合があります。

Zoho CRMのデータバックアップでは、IMAP設定を使ったメールはバックアップ対象外とされています。メールを業務記録として保持する場合は、メールサービス側の保存・復元も確認します。

9.5 監査ログを保存する

誰が、いつ、どのデータを変更したかを示す監査ログは、誤操作の調査と復元範囲の特定に役立ちます。

監査ログの標準保持期間が短い場合は、定期的に外部へ保存します。ログ自体が変更・削除されないよう、一般利用者とは異なる保存先と権限を使用します。

10. CRMデータを復元する方法

復元時に慌ててCSVを取り込むと、正常なデータまで上書きする可能性があります。影響範囲を特定し、検証環境で確認してから本番へ適用します。

10.1 障害の種類を特定する

誤削除、誤更新、設定変更、連携障害、環境全体の破損では、適切な復元方法が異なります。

一部項目だけが誤更新された場合は、環境全体を戻す必要はありません。影響したオブジェクト、項目、利用者、時間帯を確認します。

10.2 復元時点を選択する

問題発生の直前で、かつ正常であることが確認できるバックアップを選びます。最も新しいバックアップが、必ずしも正常とは限りません。

誤った自動処理が数日前から動いていた場合は、その開始前へ戻す必要があります。監査ログとバックアップの版を照合します。

10.3 検証環境で試す

可能であれば、別の検証環境やサンドボックスへ復元します。レコード数、項目値、関連、ファイルを確認します。

本番環境へ直接取り込む場合は、影響範囲を限定し、処理前の最新バックアップも作成します。復元による二次被害を防ぎます。

10.4 復元順序を守る

一般的には、設定、利用者、親レコード、子レコード、関連、添付ファイルの順で復元します。

復元順序の例

1. 独自オブジェクトと項目 2. 利用者・権限・所有者 3. 企業・顧客などの親レコード 4. 商談・問い合わせなどの子レコード 5. 多対多の関連情報 6. 活動履歴 7. 添付ファイル 8. ワークフローと連携の再有効化

復元中は通知、ワークフロー、外部同期を一時停止する場合があります。停止しないと、復元レコードを契機にメール送信や外部更新が発生する可能性があります。

10.5 復元結果を検証する

復元後は、レコード件数だけでなく、関連、所有者、選択値、日時、金額、添付ファイルを確認します。

業務担当者にも画面を確認してもらいます。技術的に取込みが成功していても、営業段階や担当者が誤っていれば業務を再開できません。

11. Salesforceのバックアップ方法

Salesforceでは、Data Export Service、Salesforce Backup、データ取込みツール、メタデータ取得などを組み合わせます。

11.1 Data Export Serviceを利用する

設定画面のData Exportから、SalesforceデータをCSV形式で書き出せます。契約版に応じて、週次または月次の定期エクスポートを設定できます。

週次エクスポートはEnterprise、Performance、Unlimitedで利用でき、月次エクスポートはDatabase.comを除く各版で利用できます。手動出力にも、週次では7日、月次では29日という実行間隔があります。

11.2 Salesforce Backupを利用する

Salesforce Backupでは、データとファイルを定期的に保存し、条件を指定してレコードを復元できます。

復元対象は、変更種類、更新時期、レコードID、変更者などで絞り込めます。バックアップからデータを書き出し、Data Loaderなどを使って復元する方法もあります。

11.3 メタデータを保存する

オブジェクト、項目、権限、自動化、画面構成などをメタデータとして取得し、バージョン管理します。

データだけでは、独自項目やワークフローを再構築できません。変更前後のメタデータを比較できる状態にします。

11.4 ファイルを含める

Salesforceの設定画面から行うData Exportでは、CSVに加えて画像、文書、添付ファイルを含める選択肢があります。Data Loaderの通常出力だけではファイル本体を取得できない点に注意します。

ファイルを復元する場合は、ContentVersionやContentDocumentLinkなど、Salesforceのファイル構造に沿った処理が必要になる場合があります。

11.5 Salesforceへ復元する

一部レコードの復元にはSalesforce Backup、CSVからの復元にはData Import WizardやData Loaderを利用できます。

復元時は親レコードを先に取り込み、新旧IDの対応表を作成します。ワークフロー、フロー、通知を必要に応じて停止し、意図しない自動処理を防ぎます。

12. Microsoft Dynamics 365のバックアップ方法

Dynamics 365の顧客管理アプリは、Microsoft DataverseとPower Platformの環境バックアップを利用します。環境全体の復元と、個別データの外部保存を分けて考えます。

12.1 システムバックアップを確認する

Dataverseデータベースを持つ環境では、システムバックアップが自動的に作成されます。試用環境を除き、対象環境から利用可能な復元時点を選べます。

既定の保持期間は、本番環境と非本番環境で7日です。管理対象の本番環境では、保持期間を最大28日へ延長できます。

12.2 手動バックアップを作成する

大規模な設定変更、ソリューション導入、版更新の前には、管理画面から手動バックアップを作成します。

手動バックアップは、本番、サンドボックス、Teams、開発環境で作成できますが、既定環境では作成できません。既定では本番とサンドボックスの手動バックアップは最大7日間保持され、管理対象本番環境では最大28日に延長できます。

12.3 復元先の制限を確認する

本番環境やサンドボックスのバックアップは、原則としてサンドボックス環境へ復元します。既定環境のバックアップは開発環境へ復元します。

復元元と復元先は同じ地域にあり、両方にDataverseが必要です。管理対象環境や暗号鍵、企業ポリシーにも条件があります。

12.4 オフライン保存との違い

Power Platformのシステムバックアップは環境復元用であり、データベースバックアップをオフライン用途で直接ダウンロードすることはできません。

外部保管や長期保存が必要な場合は、DataverseのデータをAPI、データ連携、エクスポート機能などで別途取得します。

12.5 復元テストを行う

本番環境のバックアップをサンドボックスへ復元し、アプリ、フロー、連携、権限を確認します。

復元後は、キャンバスアプリの識別子が変わる場合があります。また、復元には1GB以上の空き容量が必要で、大規模環境では処理に一日以上かかる可能性があります。

13. HubSpotのバックアップ方法

HubSpotでは、2026年時点でCRMデータのバックアップ・復元機能が提供されています。契約プランにより作成頻度と自動化の可否が異なります。

13.1 CRMデータバックアップを作成する

設定画面の「Data management」にある「Backup & Restore」から、手動バックアップを作成します。

StarterまたはProfessionalでは週に一度、Enterpriseでは24時間に一度、バックアップを作成できます。実行にはスーパー管理者権限が必要です。

13.2 含まれるデータと含まれないデータを確認する

バックアップには、連絡先、会社、商談、チケット、独自オブジェクト、商品、通話、会話、タスクなどが含まれます。

一方、関連情報と活動データは含まれません。機密データ用のプロパティ値はバックアップへ含まれるため、ダウンロードファイルを安全な場所へ保存する必要があります。

13.3 定期バックアップを設定する

Enterpriseでは、自動バックアップを毎週または隔週で設定できます。設定前に、少なくとも一回のバックアップ作成が必要です。

完成したバックアップは14日以内にダウンロードします。ZIP内には、対象オブジェクトごとのCSVファイルが含まれます。

13.4 CRM変更を元に戻す

HubSpotでは、手動変更、インポート、ワークフローなどによるCRMの変更を、最大14日前の状態へ戻せる機能があります。

復元対象と時点を慎重に選びます。正常な変更まで巻き戻さないよう、対象オブジェクト、項目、変更者を絞り込みます。

13.5 削除済みレコードを復元する

HubSpotで削除された主要なCRMレコードは、削除後90日以内であれば復元機能から戻せます。

完全削除や個人情報保護対応による削除は、通常の復元対象になりません。また、一度に画面表示・復元できる件数にも上限があります。

14. Zoho CRMのバックアップ方法

Zoho CRMでは、管理画面から即時または定期的なデータバックアップを作成できます。取得頻度、ダウンロード期限、メールデータの対象範囲を確認します。

14.1 データバックアップを設定する

管理者でログインし、「Setup」「Data Administration」「Data Backup」から実行時期を選択します。

月2回、月1回、毎週、即時ダウンロードの選択肢があります。毎週のバックアップは有料の追加機能となる場合があります。

14.2 バックアップをダウンロードする

バックアップが作成されると、管理者がデータ管理画面からダウンロードできます。

ダウンロードリンクの有効期間は作成日から最大7日です。通知を見逃さず、期限内に自社の安全な保存先へ移動します。

14.3 データと添付ファイルを保存する

Zoho CRMのバックアップでは、CRMデータと添付ファイルが別々のZIPフォルダーとして用意されます。

ファイルアップロード項目と画像アップロード項目も対象に含まれます。ただし、IMAP設定によるメールはバックアップ対象外です。

14.4 ごみ箱から復元する

削除したレコードは、Zoho CRMのごみ箱から復元できます。削除されたレコードは、手動で完全削除しない限り60日間保持されます。

APIを利用したごみ箱レコードの復元にも対応しています。親レコードを復元すると、関連するメモや添付が同時に復元される場合があります。

14.5 完全復元の手順を準備する

Zoho CRMのバックアップファイルは、ワンクリックでCRM全体を過去時点へ戻す環境スナップショットとは異なります。復元では、移行機能やモジュールごとのインポートを利用する構成になります。

親子関係、所有者、選択項目、添付ファイルを再構築する手順を事前に検証します。バックアップを取得しただけで、完全復元が保証されるわけではありません。

15. CRMバックアップを継続運用する方法

バックアップは、一度設定して終わりではありません。担当者、CRM構成、データ量、連携システムの変化に合わせて見直します。

15.1 バックアップ予定表を作成する

日次差分、週次完全、月次長期保存など、周期ごとの処理を予定表へ記載します。

大量更新、製品版更新、ワークフロー変更、データ移行の前には、通常周期とは別にバックアップを取得します。

15.2 復元訓練を行う

バックアップファイルを作成できても、復元に必要な権限、ツール、担当者がそろわなければ業務を再開できません。

CISAは、バックアップの可用性と完全性を災害復旧の状況で定期的にテストすることを推奨しています。少なくとも重要なCRMについて、定期的な復元訓練を実施します。

15.3 CRM変更管理と連動する

独自項目の削除、ワークフローの公開、API連携変更などを行う際は、変更申請にバックアップ確認を含めます。

変更前バックアップの場所、復元担当者、元へ戻す条件を記録します。問題が起きてから復元方法を調べる運用は避けます。

15.4 バックアップ指標を監視する

成功率、処理時間、取得件数、ファイル容量、保存期間、復元時間を定期的に確認します。

「処理成功」と表示されていても、権限変更によって一部オブジェクトが空になっている可能性があります。前回値との比較を自動化します。

15.5 障害対応手順書を用意する

障害発見、連携停止、影響調査、バックアップ選択、検証復元、本番復元、利用者通知までを手順書へ記載します。

担当者名だけでなく、代替担当者、連絡先、必要な権限、保存場所を記録します。CRMへアクセスできない状況でも読める場所へ保管します。

おわりに

CRMバックアップでは、顧客や商談のCSVを定期的に保存するだけでなく、レコード間の関連、活動履歴、添付ファイル、独自項目、権限、業務自動化まで保護する必要があります。どの情報が標準バックアップへ含まれ、どの情報を別途取得する必要があるかを確認することが重要です。

バックアップ方法は、手動エクスポート、定期エクスポート、API自動化、CRM標準の復元機能、外部バックアップ製品を組み合わせます。重要なデータは暗号化し、CRM本体とは異なる保存先やオフライン環境にも保管します。

最も重要なのは、バックアップファイルの存在ではなく、必要な時間内に正しく復元できることです。復元順序、担当者、検証環境、連携停止、確認項目を手順書へまとめ、定期的な復元テストを行うことで、誤操作や障害が起きた際にもCRM業務を継続しやすくなります。