BCP対策はクラウドとオンプレミスどちらに置くか｜責任分界とSLAで決める判断基準

BCP対策としてクラウドを検討するとき、判断を迷わせるのは「クラウドに載せれば災害に強くなる」という説明の粒度が粗いことです。事業者が管理する範囲はIaaS・PaaS・SaaSで異なります。利用者にはデータの保護要件や設定を管理する責任が残りますが、契約上の責任範囲は各サービスの契約条件で確認します。稼働率の保証も、単一インスタンスなら月間99.5%というのがAmazon EC2のSLAに書かれている水準です。この記事では、責任分界の線とSLAの実数値という2つの確認できる事実から、自社のサーバーやファイルサーバーをどこに置くかを決める手順を整理します。

まとめ：クラウドBCPの判断に必要な4つの事実

先に結論を示します。クラウドは「BCPの完成品」ではなく、復旧用設備を自社で調達・設置する負担を減らす手段です。ただし、復旧先で必要な計算資源を確保できるかは別途確認します。判断に効く事実は次の4点に集約されます。

• データの責任は移らない：Microsoftの共有責任モデルでは、顧客データ・構成と設定・IDとユーザーの3領域が、オンプレミス／IaaS／PaaS／SaaSのすべての列で「カスタマー」と定義されています。SaaSに預けてもバックアップの設計責任は利用者に残ります。
• 単一構成のSLAは思ったより低い：Amazon EC2の単一インスタンスに適用される月間稼働率は99.5%です。30日換算で3時間36分の停止までは、SLA違反にすらなりません。
• 止まらなくするのは配置：同一リージョン内の2つ以上のアベイラビリティーゾーンに分散して初めて、EC2のリージョンレベルSLAである99.99%が適用されます。クラウドを使うこと自体ではなく、どう置くかが稼働率を決めます。
• SLAの補償は事業損失を埋めない：稼働率を下回ったときに返ってくるのはサービスクレジット、つまり利用料の一部です。停止中の逸失利益は対象外なので、BCPの目標値はSLAではなく自社のRTO・RPOから決める必要があります。

この4点を踏まえると、検討の順序は「クラウドかオンプレミスか」ではありません。先に業務ごとのRTO・RPOを決め、その目標を満たす構成を選び、結果としてどちらに置くかが決まります。

オンプレミス構成のBCPで詰まる箇所とクラウドで外せる制約

オンプレミス環境そのものがBCPに不向きなわけではありません。問題になるのは、サーバーとバックアップが同じ建物にある構成と、副系を自前で持とうとしたときのコスト構造です。ここでは、クラウドで改善できる制約のうち、この2点を取り上げます。

サーバーとバックアップが同一拠点に同居する構成の失敗条件

自社サーバールームにバックアップ装置を併設している構成は、平時のリストアでは問題なく機能します。建物単位の被害では、本番とバックアップを同時に失うおそれがあります。つまりこの構成の弱点は「バックアップを取っていない」ことではなく、本番とバックアップが同じ災害事象の影響範囲に入っていることにあります。

内閣府の事業継続ガイドラインは、想定すべきリスクを地震や水害といった原因事象ではなく、「拠点が使えない」「システムが止まる」といった結果事象で捉えるよう求めています。この視点で自社の構成を見ると、確認すべきは災害の種類ではなく次の3条件です。バックアップの保管先が本番と同じ建物にあるか、取得したバックアップからのリストアを実際に通したことがあるか、そして本番を操作する権限でバックアップも消せる状態になっていないか。3つ目はランサムウェアで顕在化する条件で、地理的分散だけでは防げません。

遠隔地に副系を自前で持つときに残るコストと運用負荷

同一拠点集中を避ける正攻法は、遠隔地に副系を置くことです。オンプレミスでこれを行う場合、副系のサーバー費用だけでなく、設置場所の賃料、拠点間の回線、空調と電力、そして平時にほとんど使わない設備の保守契約が継続的に発生します。復旧時にしか使わない資産を、常時ラックに置いて課金され続ける構造です。

クラウドが外せるのはここです。待機系を停止状態のマシンイメージとストレージだけで持ち、必要になった時点で起動する構成が取れるため、平時の費用は保管しているデータ量に寄ります。常時稼働の待機系では計算資源の料金も継続して発生するため、設備費・保守費・回線費を含めた総費用で比較します。コスト比較では、自社の更新周期に合わせて設備・保守・運用・回線・復旧訓練の総費用を揃えたうえで、待機系を「止めて置けるかどうか」で比べるほうが判断を誤りません。オンプレミスとクラウドの費用構造そのものの違いは、オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説で整理しています。

クラウドへ移しても利用者に残る責任の範囲

BCP対策としてクラウドを評価するとき、最も見落とされるのが責任分界です。クラウド事業者のドキュメントは、どこまでを自社が引き受けるかを明示しています。そしてその線は、IaaSでもSaaSでも同じ位置にある項目があります。

IaaS・PaaS・SaaSで変わる境界と、どの形態でも顧客に残るもの

Microsoftは共有責任モデルの責任マトリックスとして、スタックの各領域をデプロイ形態別に分類しています。物理データセンター・物理ネットワーク・物理ホストはIaaS以降でMicrosoft側に移り、オペレーティングシステムはPaaS以降で移ります。一方で上位3領域は動きません。

出典はMicrosoft Learnのクラウドでの共同責任で、同文書は「すべてのクラウド デプロイの種類について、データと ID を所有します」と述べ、デプロイ形態に関係なく常に負う責任としてデータ・エンドポイント・アカウント・アクセス管理の4項目を挙げています。BCPの文脈に置き換えると、クラウドへの移行で削れるのは物理資産の調達と維持であって、データを失わない設計と、消えたときに戻す手段の確保は移行後も自社の仕事として残る、ということです。

AWSも同じ線を引いています。オンプレミスアプリケーションのAWSへの災害復旧を扱うホワイトペーパーは責任共有モデルの節で、「You are responsible for managing resiliency of your data and workloads, whether on AWS or outside of it, including disaster recovery, high availability, backup」と記しています。ここで顧客の責任として名指しされているのは、データの所在がAWS上かどうかを問わず、災害復旧・高可用性・バックアップを管理することです。事業者を替えても、この項目が事業者側へ移ることはありません。

Microsoft 365などSaaSのデータを保護対象から外せない理由

SaaSは責任範囲が最も狭く見えるため、「Microsoft 365を使っているからBCP対策済み」と整理されがちです。しかし上の表が示すとおり、顧客データの責任はSaaSの列でも顧客側にあります。標準の保持・復元機能と、別途設定・契約するバックアップサービスは区別して確認します。MicrosoftにはMicrosoft 365 Backupもあります。

具体例として、Microsoft Entra IDからユーザーアカウントを削除した場合のOneDriveの扱いがあります。Microsoft Learnによると、削除したユーザーのOneDriveは既定で30日間保持され、その保持期間の終了後にサイトコレクションのごみ箱へ移されて93日間保持されます。ただし、削除後の保持期間は変更でき、Microsoft 365の保持ポリシーや保持ラベル、電子情報開示のホールドによって通常の削除処理が変わります。退職者のファイルを1年後に参照する必要が生じる業務や、誤削除の発覚までに数か月かかる帳票類では、この保持期間は保護策として足りていません。

SaaSをBCPの保護対象に含めるかどうかは、次の条件で判断できます。そのデータを失ったときに事業が止まるか。止まるなら、事業者の保持期間が自社の必要保持期間を上回っているか。必要な期間を満たさなければ、保持設定の変更、バックアップサービス、テナント外への書き出しなどから、復元要件を満たす方法を選びます。グループウェアやメールは「クラウドだから安全」と扱われやすい領域ですが、判断すべき論点はオンプレミスのファイルサーバーと変わりません。

クラウドのSLAが保証する稼働率と「クラウドなら止まらない」の誤り

クラウドの可用性は、事業者がSLAとして数値で公開しています。BCPの目標値を立てるときは、この実数値を先に見るべきです。感覚的に想定される水準より低いことが多く、しかも構成によって桁が変わります。

単一インスタンス99.5%とマルチAZ99.99%が意味する停止許容時間

Amazon EC2のSLAは、リージョンレベルとインスタンスレベルの2本立てです。リージョンレベルの停止は対象の全稼働インスタンスが同時に外部接続を失った状態を指し、業務アプリケーションの停止とは一致しません。以下の時間は月間稼働率を30日で単純換算した値で、停止時間の上限保証ではありません。インスタンスレベルのSLAは個々のEC2インスタンスに適用され、月間稼働率99.5%以上を対象とします。リージョンレベルのSLAは、同一リージョン内の2つ以上のアベイラビリティーゾーンに同時展開している場合に適用され、こちらは99.99%以上です。同じ区分の仕方は他社にもあります。Google Compute EngineはPremium Tierのメキシコ・ストックホルム以外のリージョンで複数ゾーンに配置したインスタンスを99.99%、単一インスタンスをメモリ最適化ファミリー以外で99.9%としています。Azure Virtual Machinesについても、Microsoft Learnは同一リージョン内の2つ以上の可用性ゾーンに2台以上を配置した場合に99.99%、同一可用性セット内に2台以上を配置した場合に99.95%と記載しています。

注目すべきは単一構成と分散構成の差です。EC2では99.5%と99.99%の間に、30日あたり3時間半ほどの開きがあります。オンプレミスのサーバーをそのままクラウドの1台へ移しただけの構成は、事業者が約束している水準としては月3時間36分の停止を許容するものになります。ただし、月間の累積停止時間と、障害発生から復旧までの目標時間であるRTOは別の指標です。数十分のRTOを満たせるかは、検知・切替・復元にかかる時間を訓練で確認します。可用性を上げているのはクラウドという選択ではなく、ゾーンをまたぐ配置のほうです。AWS上で具体的に構成を組む手順は、AWS環境でBCP対策を始める企業が最初に押さえるべき基本要件と設計思想で解説しています。

SLAの補償範囲と自社の復旧目標の決定基準

SLAを事業継続の担保として読むのは避けるべきです。EC2のSLAは、稼働率が基準を下回った場合に利用者が受け取れるものをサービスクレジットと定めており、その割合は稼働率の低下幅に応じて10%・30%・100%と段階的に設定されています。返ってくるのは当該サービスの利用料に対するクレジットであり、停止によって生じた受注機会の損失や納期遅延の違約金は対象になりません。

したがって、SLAの数値は「事業者がどこまでを設計上の前提としているか」を読み取る材料として使い、BCPの目標値は自社の業務側から決めます。順序としては、業務停止による影響が許容限界に達するまでの時間を把握し、それより短いRTOを設定したうえで、復旧手順と構成が目標を満たすか検証します。目標復旧時間と目標復旧レベルの決め方そのものは、BCPとは？事業継続計画の意味と防災計画との違い、RTO・RLOの決め方で扱っています。

サーバー・ファイルサーバー・業務システムの置き場所を決める判断軸

ここまでの2点を踏まえると、配置の判断は目標値からの逆算になります。システム単位ではなく業務単位で目標を置くのが実務上の分かれ目です。

RTO・RPOの目標値から構成を逆算する順序

最初に行うのは業務影響度の把握です。受注、出荷、請求、生産指示といった業務を並べ、それぞれが停止したときの影響を時系列で評価し、影響が許容限界に達するまでの時間を把握します。RTOはその限界より短く設定し、どの時点までのデータを失うと業務をやり直せなくなるかがRPOの上限になります。

この2つが決まってから構成を選びます。RPOを24時間まで許容できる業務なら日次バックアップを候補にできますが、転送時間や取得失敗も含め、復元可能な時点が24時間以内に収まることを確認します。一方、RPOを分単位に抑える必要があるならレプリケーションを組む構成になります。RTOについても同様で、翌営業日までに戻ればよい業務と、数十分で戻す必要がある業務では、待機系を停止状態で持てるかどうかが変わります。業務の側から目標を出さずに構成の比較から入ると、全業務を最上位の構成に合わせるか、逆に全業務を最低限の構成に落とすかの二択になり、費用と保護水準のどちらかが崩れます。

構成のパターンごとに実現できるRPO・RTOの目安は、DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方で数値とともに整理しています。本記事では配置の判断軸に絞ります。

オンプレミス・クラウド・ハイブリッドの適否が分かれる条件

3つの配置は優劣ではなく適用条件で分かれます。判断を分けるのは、データの持ち出し制約、復旧時の操作主体、そして待機系を止めて置けるかどうかの3点です。

本番をオンプレミスに残す場合は、退避先をクラウドに置くハイブリッド構成が候補になります。AWSの災害復旧ホワイトペーパーでも、オンプレミスのアプリケーションをAWSへ復旧する方式が扱われています。ファイルサーバーのデータをクラウドストレージへ日次で複製する構成がこれにあたり、遠隔地に設備を持たずに同一拠点集中を解消できます。ただしこの構成は、複製が止まっていても業務が続くため異常に気づきにくいという弱点があります。複製ジョブの成否を監視し、失敗時に通知が飛ぶようにしておかないと、被災して初めて数か月分が欠けていたことに気づく事態になります。

逆に、クラウド単独を選ぶべきでない場面もはっきりしています。拠点の回線が1本しかなく、その回線が切れると全業務が止まる構成のまま基幹システムをクラウドへ移すと、単一障害点をサーバー室から回線へ移し替えただけになります。この場合は回線の冗長化を先に行うか、手元に縮退運用できる仕組みを残す判断が要ります。

クラウドBCPの導入前に契約と運用で確認する項目

構成が決まったあとに残るのは、契約条件の確認と、復旧手順が実際に動くかの検証です。この2つを飛ばすと、机上では成立している計画が被災時に機能しません。

データの保管リージョンと同時被災を避ける配置条件

クラウドを使う場合でも、データが物理的にどこにあるかは確認が要ります。国内リージョンを選んでいても、バックアップの複製先が同一リージョン内のゾーンにとどまっていれば、広域災害では本番と同時に影響を受ける可能性が残ります。例えばAzureは東日本リージョンを東京・埼玉、西日本リージョンを大阪に置いているため、広域の同時被災まで想定するなら、複製先をリージョンをまたいで設定する必要があります。

契約面では、退避したデータを取り出す手段と条件を事前に確認しておきます。サービスを解約する局面や、事業者側の障害が長引いた局面で、自社のデータをどの形式で、どの程度の時間で取り出せるかは、BCPの復旧手順に直結します。取り出しに要する時間を見積もっていないと、RTOの計算に大きな抜けが生じます。

復旧手順を実際に動かして確かめる訓練の位置づけ

BCPで最も形骸化しやすいのが、文書に書いた復旧手順と実際の構成の乖離です。クラウドの場合も、復旧に関係する設定を変更した際は、手順書との整合を確認します。インスタンスの種類を変えた、ストレージの構成を変えた、認証をシングルサインオンに寄せた。いずれも平時の運用としては正しい変更ですが、復旧手順書がそのままなら、被災時に手順どおりに操作しても戻りません。

検証すべきはバックアップの取得成功ではなく、リストアの成功です。取得ジョブが正常終了していても、リストアしたデータでシステムが起動するかは別の話になります。本記事では、少なくとも年1回を訓練計画の目安とし、本番とは別の環境へのリストアと業務再開の確認を推奨します。復旧に関わる構成変更後にも確認します。内閣府の事業継続ガイドラインも、点検と経営者による見直しをそれぞれ年1回以上行うことを求めています。

なお、内閣府が令和8年3月に公表した令和7年度の事業継続に関する実態調査では、BCPを策定済みと回答した割合は大企業で75.8%、中堅企業で54.8%、その他企業で52.1%となっています。策定済みであっても、手順が現行の構成に追随しているかは別の論点です。策定そのものにこれから着手する場合の進め方は、中小企業が最低限押さえるべきBCP対策の基本と策定前の前提条件にまとめています。

よくある質問

BCP対策にクラウドを使えば、自社でのバックアップは不要になりますか？

不要にはなりません。Microsoftの共有責任モデルでは、顧客データの責任はオンプレミス・IaaS・PaaS・SaaSのすべての形態で顧客側に置かれています。クラウド事業者が引き受けるのは物理インフラとその上のレイヤーの一部で、データを失わない設計と復元手段の確保は利用者の責任として残ります。

オンプレミスのままでもBCP対策はできますか？

可能です。問題になるのはオンプレミスであること自体ではなく、本番とバックアップが同一拠点にある構成です。遠隔地に副系を持つか、バックアップを本番と同時被災しない場所へ複製すれば、同一拠点集中を避けられます。内閣府の事業継続ガイドライン4.2.3「情報及び情報システムの維持」も、重要な情報について「バックアップを確保し、同じ発生事象（インシデント）で同時に被災しない場所に保存することが必要である」としています。ただし自前で遠隔拠点を維持する場合、平時にほとんど使わない設備の費用と保守が継続的に発生します。

ファイルサーバーをクラウドストレージに移せば、BCP対策になりますか？

同一拠点集中は解消できますが、それだけでは不十分です。確認するのは、削除・上書きから遡って復元できる範囲と、複製失敗の監視・通知です。AWSの責任共有モデルでも、バックアップ・バージョニング・複製戦略の管理は利用者の責任に含まれます。複製が止まっていても日常業務は続くため、監視と通知がないまま運用すると、被災時に欠損が判明します。

Microsoft 365を使っていれば、BCP対策済みと言えますか？

言えません。SaaSの標準の保持・復元機能だけで自社の要件を満たせるか確認し、不足する場合はMicrosoft 365 Backupなどの追加の保護手段を検討します。Microsoft Learnのドキュメントによれば、Entra IDから削除したユーザーのOneDriveは既定で30日間保持され、その後ごみ箱で93日間保持されますが、保持期間の変更や保持ポリシー等の適用によって扱いが変わります。自社の保持・復元要件を満たさない場合は、保持設定の変更やバックアップサービス、テナント外への書き出しを比較して保護手段を決めます。

クラウドのSLAが99.99%なら、事業は止まらないと考えてよいですか？

その数値が適用される構成かどうかを確認してください。Amazon EC2の99.99%は同一リージョン内の2つ以上のアベイラビリティーゾーンに展開している場合のリージョンレベルSLAで、単一インスタンスに適用されるのは99.5%です。またSLAを下回った際の補償はサービスクレジットであり、停止による事業損失は対象外です。

関連記事

• DR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方
• BCPとは？事業継続計画の意味と防災計画との違い、RTO・RLOの決め方
• オンプレミスとクラウドの違いとは？コスト・セキュリティ・拡張性で比較し選び方まで解説
• AWS環境でBCP対策を始める企業が最初に押さえるべき基本要件と設計思想
• 中小企業が最低限押さえるべきBCP対策の基本と策定前の前提条件