Salesforceのダウンタイムに対する事業継続計画の構築方法

Salesforceが利用不能になった場合、最大の運用リスクはエラーメッセージそのものではありません。本当の問題は、営業、サービス、受注、マーケティング、バックオフィスといった各チームが、作業記録の記録場所、顧客対応の方法、あるいはどの決定を後回しにしても問題ないのかが分からなくなることです。したがって、有効な事業継続計画とは、「Salesforce Trustを確認して待機する」とだけ書かれた文書ではありません。サービスが正常に復旧するまで、最も重要な業務プロセスを許容できるレベルで維持する必要があります。

計画の質は結果によって判断できます。業務中断時には、人々は何をすべきか、一時的な作業の記録場所、意思決定者、顧客への情報提供方法、復旧後の一時記録の照合方法を把握しておく必要があります。また、計画では、業務継続が安全でなくなる箇所を明確に定めるべきです。一部のプロセスは手動で何時間も実行できますが、重複取引、規制上のミス、データの不整合などが待機よりも大きな損害をもたらす可能性があるため、一時停止すべきプロセスもあります。

休憩時間中に達成したい成果から始めましょう

事業継続計画は、技術ではなく事業への影響から始めるべきです。NIST（米国国立標準技術研究所）の連邦情報システム向け緊急時対応計画ガイドでは、事業影響分析を通じて緊急時対応の要件と優先順位を決定することを推奨しています。このガイドは連邦情報システム向けに書かれていますが、その根底にある考え方は広く応用可能です。すなわち、重要な機能を特定し、障害の影響を理解し、復旧の優先順位を定義し、テスト済みの緊急時対応手順を維持することです。

Salesforceにとって、それはプラットフォームが利用できない場合でも継続しなければならない業務活動は何かを検討することを意味します。営業チームは、緊急の見込み客のコミットメントを記録する必要があるかもしれません。サポート部門は、重大な顧客インシデントを受信して​​優先順位付けする必要があるかもしれません。現場チームは、顧客または資産の詳細情報の一部にアクセスする必要があるかもしれません。財務部門は、Salesforceと接続されたシステムが安定するまで、一部の取引を完全に停止する必要があると判断するかもしれません。

強力な継続性目標は、テスト可能なほど具体的であるべきです。例えば、「顧客サポートは引き続き稼働しなければならない」は曖昧です。「優先度1の顧客インシデントは、Salesforceの4時間の障害発生時でも、リクエストの損失なく、引き続き受信、割り当て、確認、追跡できる」であれば、測定可能です。

許容できる劣化の定義を明確にし、正常な運用を約束する非現実的な約束はしない。

継続性とは、完全な機能維持とは異なります。通常、目標は、主要システムが復旧するまで、最低限必要な業務サービスを維持することです。Salesforceに依存する重要なプロセスごとに、「障害発生時に十分な状態」とはどういうことかを定義してください。

停止条件は重要です。どんな犠牲を払ってでも作業を続けるよう指示する継続計画は、重複した注文、矛盾するケース更新、承認漏れ、承認されていないツールに機密情報が保存されるなど、二次的な問題を引き起こす可能性があります。

Salesforceがインシデントをどのように伝達するかを知る

計画では、信頼できるステータス情報源を定義する必要があります。Salesforce では、サービスの可用性とパフォーマンス情報の情報源として、信頼ステータスサイトをドキュメント化しています。また、Salesforce は、サービスの問題、メンテナンス、製品リリースに関する信頼通知を電子メールまたは SMS で送信します。最新の概要については、Salesforce ヘルプの「信頼ステータス」を参照してください。

Salesforceのインシデント信頼コミュニケーションに関する記事では、同社は信頼サイト、信頼通知、情報メッセージ、ヘルプバナー、インシデントアラートメール、ライブウェビナーなどを利用して、重大な予期せぬインシデントとその修復の進捗状況を伝えることができると説明している。

優れた事業継続計画では、すべての従業員にステータスページを個別に解釈することを求めません。インシデント担当者または小規模なインシデントチームを割り当て、影響を受けるインスタンスまたはサービスを確認し、既知の情報を要約し、定められた頻度で社内向けの最新情報を公開します。

プランをインスタンスごとにカスタマイズする

Salesforce のステータスは、単一のグローバルなバイナリ状態ではありません。組織は、どの Salesforce インスタンスまたはサービス識別子が重要かを把握しておく必要があります。Salesforce のガイダンス「Salesforce 組織のインスタンス情報の表示」（2026 年 8 月 4 日更新）では、設定の「会社情報」または Salesforce ステータス サイトを使用してインスタンスを見つける方法について説明しています。

Salesforceは、同社のTrustサイトでは、影響を受けるインスタンスとサービスごとにインシデントとメンテナンスイベントが報告されると述べています。進行中のインシデントまたはメンテナンスの確認に関するガイダンスによると、イベントレコードには、影響を受けるインスタンスとサービス、ステータス、およびタイミング情報が含まれます。

したがって、継続性ランブックには、本番組織の関連ドメインとインスタンスの詳細に加え、運用に重要なMarketing CloudやCommerceサービスなど、個別に監視しているSalesforce製品をすべて記録する必要があります。

制御されたデータ取得に関するフォールバックワークフローを設計する

最も現実的な代替策は、必ずしもCRMシステムの代替となるものではありません。緊急業務を継続するために必要な最小限の情報を保持するための、管理された方法こそが重要なのです。それは、承認済みのスプレッドシート、サービスデスクのキュー、社内フォーム、コラボレーションチャネル、電話対応プロセス、あるいは組織のセキュリティおよびデータ保持ポリシーで既に規定されているその他のシステムなどが考えられます。

フォールバックメソッドは以下を定義する必要があります。

• どの項目が必須ですか？
• 一時記録を作成または変更できる者。
• 各レコードが一意の一時識別子を受け取る方法。
• Salesforceの外部にコピーしてはならない機密データとは何か。
• 時間、顧客の身元、所有者、および行動履歴がどのように記録されるか。
• データがSalesforceに再入力される前に、重複データがどのように検出されるか。

この計画のこの部分がうまくいっていることを示す最良の兆候は、復旧チームが後日、「Salesforceが利用できなかった間に何が変わったのか？」という問いに、記憶やチャット履歴、複数のチームに散らばった手書きのメモに頼ることなく答えられるようになることです。

バックアップは復旧をサポートするが、継続性の代わりにはならない。

Salesforceは、データ管理とセキュリティの一環として、定期的なバックアップ戦略を推奨しています。2026年4月2日に公開されたガイダンス「Salesforceデータのバックアップに関するベストプラクティス」では、レコードやファイルなどのビジネスデータと、カスタムフィールド、レイアウト、レポート、ダッシュボード、Apex、Visualforceなどのメタデータを区別しています。

Salesforceは、Salesforceバックアップ、データエクスポートサービス、データローダーエクスポート、レポートエクスポートなど、ネイティブのバックアップ方法を提示しています。Salesforceの「Salesforceからのバックアップデータのエクスポート」ドキュメントには、標準のデータエクスポートでは、エディションに応じて週単位または月単位でCSV形式のバックアップを生成できると記載されています。

ただし、バックアップは復旧対策であり、システム停止時の運用モードではありません。バックアップによってSalesforceの代替となる稼働中のシステムが自動的に提供されるわけではありません。また、大量のエクスポートデータは、古すぎたり、範囲が広すぎたり、機密性が高すぎたり、あるいは安全に利用するのが困難であったりして、最前線の業務継続に支障をきたす可能性があります。システム停止時にエクスポートされたデータが本当に必要かどうかを事前に判断し、それに応じて保護してください。

復旧目標と事業継続目標を分けて設定する

事業継続目標とは、Salesforceが利用できない状況下でビジネスがどのように運営されるかを示すものです。復旧目標とは、通常の業務がどのように復旧され、一時的な作業がどのように調整されるかを示すものです。

各プロセスについて、少なくとも3つの具体的な目標を文書化してください。

• 許容可能な最大中断時間：業務への影響が許容範囲を超える前に、プロセスが利用できなくなることが許容される時間。
• 暫定的な運用目標：その期間中に継続しなければならない最低限のサービス水準。
• 調整目標：サービス復旧後、一時レコードを検証し、Salesforceに入力するまでの迅速性。

これらの目標は、一般的なIT部門の想定ではなく、事業責任者から提示されるべきです。2時間の許容範囲は、ある部門にとっては妥当でも、別の部門にとっては受け入れられない場合もあります。

停電前に意思決定権限を割り当てる

タスクの内容は分かっていても、誰が権限を持っているのかが不明確な場合、計画の実行は遅れます。インシデントの宣言、フォールバックの有効化、顧客とのコミュニケーション、セキュリティ例外、ベンダーへのエスカレーション、復旧の検証、そして通常処理への復帰に関する最終決定について、それぞれ役割名または役割に基づく所有権を明確に定義してください。

最低限、1人は継続モードを起動でき、別の1人は通常サービスへの復帰を承認できる必要があります。影響の大きいプロセスについては、1人の担当者だけが操作できる状態にすることは避け、重要な役割にはバックアップ担当者を指定してください。

文書が読まれたかどうかだけでなく、ビジネス成果を検証する。

NIST SP 800-34 Rev. 1では、テスト、トレーニング、演習、および計画の維持管理を、緊急時対応計画の中核要素として挙げています。したがって、Salesforceの継続性テストでは、重大なアクセス喪失をシミュレートし、実際のパフォーマンスを測定する必要があります。

有用なテスト基準には以下が含まれます。

• インシデントの所有者は、適切なSalesforceインスタンスまたはサービスを特定します。
• 重要なチームは、目標時間内に起動メッセージを受信する。
• ユーザーは、IT部門に個別に問い合わせることなく、承認済みの代替プロセスを特定できます。
• 一時レコードには、必須項目と所有者情報が含まれています。
• 承認されていない機密データは、代替システムにコピーされません。
• 一時レコードのサンプルを重複なくSalesforceに統合することができます。
• チームは、復旧完了を宣言する権限を持つのは誰かを説明できる。

机上演習で参加者がプランを開けることを確認するだけでは、継続性は証明されません。より優れた演習は、人々がワークフローを実行し、スムーズに復旧できることを証明します。

計画変更が必要な時期を把握する

実際にシステム障害が発生してから計画が時代遅れだと気づくような事態は避けましょう。Salesforceのアーキテクチャ、重要な統合、ビジネスプロセス、コンプライアンス要件、チームの責任範囲、バックアップ戦略、コンタクトセンターのルーティング、顧客コミュニケーションチャネルなどに大幅な変更があった場合は、必ず計画を見直してください。

テスト結果で繰り返し弱点が明らかになった場合は、アプローチを変更してください。例えば、公式の代替手段があるにもかかわらず、従業員が管理されていないスプレッドシートを作成してしまう、一時レコードに固有の識別子がないために復旧に時間がかかりすぎる、あるいはビジネスチームが宣言した継続性目標が実際の顧客需要に対して不十分であることを発見する、といったケースが挙げられます。

有効な計画には、バージョン管理とレビューのトリガーが盛り込まれているべきです。「年1回レビューする」というだけでも何もないよりはましですが、「年1回、かつSalesforce、統合、所有権、またはプロセスに大きな変更があった後にレビューする」という方がより確実です。

この計画では保証できないこと

Salesforceのあらゆる障害発生時に、業務の中断を完全に防ぐことができる継続性計画は存在しません。障害によっては、接続されたシステム、IDプロバイダー、ネットワーク、通信ツール、パブリッククラウドサービスなどが同時に影響を受ける可能性があります。また、深刻な障害や長期にわたる障害は、手動による代替手順では対応しきれない場合もあります。

セキュリティとデータ品質にも限界があります。機密性の高いSalesforceデータを緊急ツールに移行すると、ポリシーや規制に違反する可能性があります。オフラインで作業すると、古い決定事項、矛盾する記録、重複したトランザクションが発生する可能性があります。リスクの高いプロセスの中には、手動で継続するのではなく、制御された一時停止を行う方が安全な継続方法となる場合があります。

そのため、成熟した計画では、想定される運用期間とエスカレーションの閾値の両方が明記されています。障害が予想以上に長引いたり、代替キューが大きくなりすぎたり、データの整合性が維持できなくなったりした場合は、経営陣は日常的な継続性手順から、より広範な危機管理の意思決定へと移行する必要があります。

Salesforceの継続性計画が準備できているかどうかを確認する方法

現実的な演習で次の4つのことが実証できれば、計画は良好な状態にあると言える。すなわち、企業が重要な事項を特定できること、合意された最低限のレベルで必要不可欠な業務を継続できること、信頼できる一時的な記録を保持できること、そして重要な活動を失ったり重複させたりすることなくSalesforceに戻れることである。

最終準備チェックを実施してください。

• Salesforceに依存する重要なプロセスはすべて、担当者と障害許容範囲が設定されています。
• 本番環境のインスタンスと公式のSalesforceステータスソースは文書化されています。
• 代替ツールは、承認されており、アクセスしやすく、ユーザーに理解されている必要があります。
• 一時データには、定義されたスキーマ、識別子、アクセス ポリシー、および調整方法があります。
• インシデント発生時および顧客とのコミュニケーションに関する責任は明確に定められている。
• バックアップは復旧対策として扱われ、運用上のフォールバックとは別にテストされます。
• チームは計画を実行に移し、測定可能なギャップを記録した。
• 手動での対応を中止し、エスカレーションすべきタイミングについては、明確なルールが存在する。

Salesforceの事業継続計画が成功するのは、文書上で包括的だからではなく、プレッシャーのかかる状況下でも予測可能な挙動を示すからである。最も有用な計画とは、実行可能な規模でありながら、危険な即興対応を防ぐのに十分な詳細さを持ち、実際の障害が発生する前に組織の限界を把握できるほど十分にテストされているものである。