BCPやDRという言葉を聞いたことがある方は多いでしょう。しかし、「BCPとDRはどう違うのか」「自社にはどちらが必要なのか」「何から手をつければよいのか」と迷っている方も多いのではないでしょうか。
近年、自然災害やサイバー攻撃、システム障害など、企業が直面するリスクは多様化しています。中小企業であっても、一度の障害で事業が長期停止すれば、顧客の信頼を失い、取引関係に深刻な影響を与える可能性があります。
本記事では、BCPとDRのそれぞれの意味と役割、両者の違い、そして重要指標（RTO・RPO）の設定方法から、中小企業でも実践できる具体的な対策まで解説します。「概念の理解」だけでなく、システム開発・クラウド移行・保守契約を外部へ発注する場面で「何を決め、何を確認すればよいか」を判断できる状態を目指して構成しています。
結論から言うと、BCPは事業全体を継続するための計画、DRはその中のITシステムを復旧する対策です。DRはBCPの一部であり、RTO（目標復旧時間）とRPO（目標復旧時点）の目標値が、ベンダーに依頼する構成・見積金額・保守契約の条件を左右します。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
BCP（事業継続計画）とは？定義と策定の基本
BCPの定義と目的
BCP（Business Continuity Plan）とは、自然災害・システム障害・感染症など、予期せぬ事態が発生した際でも、企業が重要な事業を継続または早期に再開できるよう、事前に対策を計画・準備しておくための体制や文書のことです。
BCPが対象とする範囲は非常に広く、次のような要素を含みます。
- 人員（従業員の安否確認・代替要員の確保）
- 設備・拠点（オフィス・工場・データセンター等の代替拠点確保）
- サプライチェーン（仕入先・取引先との連絡・代替調達先の確保）
- ITシステム（データ保護・システム復旧）
- 資金（緊急時の資金手当て）
これらを事前に整備しておくことで、緊急事態が起きても「いかに事業を継続するか」を組織全体で迅速に判断・行動できるようになります。
BCPに盛り込む基本項目
BCPは、立派な文書を作ること自体が目的ではありません。最低限、次の項目が決まっていれば「止まったときに誰が何をするか」を判断できます。
- 重要業務の特定: 止まると事業に大きな影響が出る業務（受注・出荷・請求など）を選び出す
- 被害想定: 地震・水害・サイバー攻撃・システム障害・感染症など、自社に起こりうる事態を整理する
- 目標の設定: 重要業務を「どのくらいの時間で」「どの水準まで」再開させるかを決める（ここでRTO・RPOが登場します）
- 対応体制と連絡網: 指揮を執る人、代行者、従業員・取引先・ベンダーへの連絡ルートを決める
- 訓練と見直し: 定期的に訓練し、事業やシステムの変化に合わせて更新する
BCPが必要な理由
内閣府の調査によると、自然災害や事故を経験した中小企業の多くが「事業継続計画がなかった」ために復旧が遅れたと回答しています。緊急事態はいつ起きるか分かりません。BCPは「万が一のときに備えた保険」ではなく、「事業継続のための経営インフラ」として位置づけることが重要です。
また、大企業から中小企業への発注条件にBCPの整備が含まれるケースも増えており、BCPの整備は取引継続の観点からも重要になっています。
DR（ディザスタリカバリ）とは？
DRの定義と目的
DR（Disaster Recovery）とは、直訳すると「災害復旧」です。特にITの文脈では、サーバやネットワーク、アプリケーション、データなど、ITシステムの障害・損失からの復旧を目的とした計画・手段を指します。
DRが対象とする範囲は、BCPとは異なりITインフラに限定されます。
- サーバ・ストレージ
- ネットワーク・通信設備
- アプリケーション・ソフトウェア
- データ・バックアップ
DRの目的は、障害発生後にできる限り早く・できる限り直前の状態に、ITシステムを復旧させることです。
BCPにおけるDRの位置づけ
BCPとDRの関係を一言で表すと、「DRはBCPの一部を構成するIT領域の対策」です。
現代の企業活動は、販売管理・会計・顧客管理・コミュニケーションなど、あらゆる業務がITシステムに依存しています。そのため、BCPの中でITシステムの継続・復旧（＝DR）は必要不可欠な要素となっています。
BCP（事業継続計画）の中に、ITシステムの継続・復旧（DR）、人員・拠点・資金の対策、サプライチェーンの対策が含まれています。BCPとDRは「どちらか一方」ではなく、「BCPという大枠の中にDRが含まれる」と理解してください。
BCPとDRの違いを整理する
BCPとDRの主な違いは、対象範囲と視点にあります。
項目 | BCP | DR |
|---|---|---|
対象範囲 | 事業全体（人・モノ・カネ・情報・プロセス） | ITシステム・データのみ |
目的 | 事業の継続・早期再開 | ITシステムの復旧 |
視点 | 経営・事業視点 | IT・技術視点 |
担当者 | 経営者・全部門 | IT部門・システム担当者 |
策定単位 | 会社全体・部門単位 | システム単位 |
対象範囲の違い
BCPは「事業を継続させるために何が必要か」を幅広く考えます。従業員が出社できない場合の在宅勤務体制、工場が被災した場合の代替生産拠点、取引先との緊急連絡ルートなど、IT以外の要素も含めて計画します。
一方、DRは「ITシステムをどう復旧させるか」に特化します。データのバックアップ方法、システム切り替えの手順、復旧に要する時間の目標値など、ITインフラに関する技術的な対策が中心です。
目的と視点の違い
BCPは経営者・事業責任者が主体となり、「事業の継続性」という観点から計画します。DRはIT部門・システム担当者が主体となり、「技術的な復旧可能性」という観点から設計します。
両者を結びつけるのが「事業への影響度」です。「このシステムが止まると、事業にどんな影響があるか」を評価することで、DR対策の優先順位をBCPの事業継続目標と連動させることができます。
BCP・DRの重要指標「RTO・RPO」を理解する
BCPやDRを実際に計画・実装する際に必ず登場するのが、RTO（目標復旧時間）とRPO（目標復旧時点）という2つの指標です。この2つを正しく理解することが、「何をどこまで対策するか」の判断軸になります。
RTO（目標復旧時間）とは
RTO（Recovery Time Objective）とは、システム障害や災害が発生してから、ITシステムが復旧するまでの目標時間です。
- 例: 「受注管理システムは障害発生から2時間以内に復旧させる」
- 例: 「基幹システムは24時間以内に復旧させる」
RTOが短いほど、より高度な冗長化や自動フェイルオーバーの仕組みが必要になります。当然、コストも高くなる傾向があります。
RPO（目標復旧時点）とは
RPO（Recovery Point Objective）とは、障害発生時に「どの時点のデータまで許容するか」の目標です。言い換えると、「最大どこまでデータを失っても許容できるか」の基準です。
- 例: 「RPO=1時間」 → 最大1時間前のデータまで失っても許容する
- 例: 「RPO=0（ゼロデータロス）」 → リアルタイムでデータを同期する必要がある
RPOが短いほど（=データ損失を少なくするほど）、頻繁なバックアップやリアルタイムレプリケーションが必要になり、コストが上昇します。
RTO・RPOの目標値の決め方
RTO・RPOの目標値は「できる限り短い方がよい」ではなく、「事業への影響度とコストのバランスで決める」のが正解です。
以下のステップで考えると整理しやすくなります。
ステップ1: システムの重要度を評価する
自社のシステムを「システムが止まると事業にどんな影響があるか」の観点で分類します。
- 重要度: 高 → 受注・決済・在庫管理など、止まると直接的に売上・顧客影響が出るシステム
- 重要度: 中 → 社内業務システム（勤怠・経費精算等）
- 重要度: 低 → 社内コミュニケーションツール等
ステップ2: 業種・ビジネス特性を考慮する
業種によってRTO・RPOの目安は大きく異なります。
業種・ビジネス | RTO目安 | RPO目安 |
|---|---|---|
EC・オンライン取引 | 1〜4時間 | 15分〜1時間 |
製造業（生産管理） | 4〜12時間 | 1〜4時間 |
一般業務システム | 12〜24時間 | 4〜24時間 |
社内補助ツール | 24〜72時間 | 24時間以内 |
※上記はあくまで一般的な目安であり、実際の目標値は事業の重要度・コストを考慮して設定してください。
ステップ3: コストとのバランスで決定する
RTO・RPOを短くするほど、システム構成・バックアップ頻度・クラウドインフラの費用が増大します。すべてのシステムを最高水準の対策にする必要はありません。重要度に応じて投資配分を決めることが現実的です。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
BCP・DRを発注判断につなげる：RTO・RPOが見積と保守契約を左右する
システム開発やクラウド移行、保守を外部に発注する場面では、BCP・DRの用語が見積書や提案書に登場します。用語を知っているだけでは、提案内容や金額が妥当かどうかを判断できません。ここでは、RTO・RPOの目標値が発注内容にどう影響するかを整理します。
RTO・RPOの目標値はベンダーへの依頼内容と費用を左右する
目標値が厳しいほど、必要な仕組みが増え、構築費用と月額の運用費用が上がる傾向があります。傾向を整理すると次のとおりです。
目標値の水準 | 必要になりやすい仕組み | 見積への影響 |
|---|---|---|
RTO・RPOとも長め（半日〜1日以上） | 定期バックアップと、障害後に再構築・復元する手順 | 比較的抑えやすい。復元作業は障害後に発生し、その費用は別途になることが多い |
RTO・RPOとも中程度（数時間〜1時間程度） | 頻度の高いバックアップ、クラウドの別リージョン・別拠点へのデータ複製、復旧手順の整備 | 構築費に加え、複製先の環境費用と運用費用が継続的にかかる |
RTO・RPOとも非常に短い（分単位〜ほぼゼロ） | 常時稼働の冗長構成、自動切り替え、リアルタイム同期 | 構成が複雑になり、構築費・運用費とも大きく増える |
具体的な金額は、システムの規模・構成・利用するクラウドによって大きく変わります。重要なのは、「RTO・RPOを決めずに見積を依頼すると、ベンダーごとに前提が異なり、金額を比較できない」という点です。
見積を依頼する前に決めておく項目
次の項目を事前に仮決めしておくと、ベンダーからの提案を同じ条件で比較できます。完璧でなくても構いません。「仮の値」を持って相談することが大切です。
- 対象システムと重要度: どのシステムが止まると、どの業務にどの程度の影響が出るか
- RTOの仮値: 止まってから何時間以内に使えるようにしたいか
- RPOの仮値: 最大でどのくらい前のデータまで失ってよいか
- 想定する障害: 機器故障、誤操作、ランサムウェア、拠点の被災のうち、どこまでを対象にするか
- 予算の上限と優先順位: 全システムを一律に守るのか、重要なシステムに絞るのか
決めきれない場合は、「重要度の高いシステムはこのくらいで復旧したい」と業務への影響を伝えたうえで、複数のRTO・RPOの水準で見積を出してもらう方法もあります。水準ごとの金額差が分かれば、費用対効果を踏まえて判断できます。
保守契約・SLAで確認すべきポイント
DR対策は、構築して終わりではありません。障害が起きたときに実際に復旧できるかどうかは、保守契約の内容で決まります。契約前に次の点を確認しましょう。
- 障害時の対応時間: 連絡してから何時間以内に着手するのか。対応は平日の日中のみか、夜間・休日も含むか
- 復旧の責任範囲: アプリケーション、サーバ、データベース、クラウド基盤のうち、どこまでをベンダーが対応するのか
- バックアップの範囲・頻度・保管場所: 何を、どのくらいの頻度で、どこに保管するのか。設定したRPOと合っているか
- 復元テストの実施: 復元できることを定期的に確認する作業が契約に含まれているか、費用はどうなるか
- 障害時の連絡体制: 緊急連絡先、報告の流れ、復旧後の原因報告の有無
- 目標値の位置づけ: RTO・RPOが「保証」なのか「努力目標」なのか。未達の場合の扱いはどうなるか
- 費用の範囲: 月額保守費に含まれる作業と、障害時に別途費用が発生する作業の線引き
特に「目標値が保証なのか努力目標なのか」は、契約書の表現によって意味が変わります。曖昧な場合は、見積や契約の段階で書面にて確認してください。
取引先からBCP・DRの対応を求められたときの考え方
取引先のチェックシートで「BCPを策定していますか」「復旧目標時間は定めていますか」と問われることがあります。その場合も、まずは重要業務と対象システムを特定し、RTO・RPOの仮値と現在の対策状況を整理することから始めます。現状とのギャップが分かれば、どこをベンダーに依頼して補うかが明確になります。
中小企業でも実践できるBCP・DR対策の具体例
ここでは、中小企業が現実的に取り組めるBCP・DR対策の具体例を紹介します。クラウド技術の普及により、以前は大企業でなければ難しかった対策が、中小企業でも手が届くようになっています。
クラウド活用による低コストDR実現
クラウドを活用することで、従来のオンプレミス環境では高コストだったDR環境を、比較的低コストで構築できます。
主なアプローチ
- バックアップのクラウド保存: AWS S3・Google Cloud Storage・Azure Blob Storageなどのオブジェクトストレージへの定期バックアップ。物理的な媒体管理が不要で、自動化も容易です
- クラウドDR（マルチリージョン構成）: AWS・GCPなどのクラウドサービスを利用し、異なるリージョン（地理的に離れたデータセンター）にデータ・システムを複製する。特定地域の大規模災害にも対応できます
- クラウドへのシステム移行: オンプレミスのシステムをクラウドに移行することで、クラウド事業者が提供する高可用性インフラを活用できます
クラウドを活用したシステム移行については、クラウド移行とは？メリット・手順・失敗しないポイントを解説も参考にしてください。
データバックアップ戦略（3-2-1ルール）
DR対策の基本はデータバックアップです。「3-2-1ルール」はデータ保護の業界標準として広く採用されています。
3-2-1ルールとは
- 3つのコピー: 元データを含め合計3つのコピーを保持する
- 2種類の媒体: HDDとクラウド、オンプレミスとクラウドなど、異なる種類の媒体に保存する
- 1つはオフサイト保管: 1つのコピーは物理的に離れた場所（別拠点またはクラウド）に保管する
これにより、機器故障・ランサムウェア被害・拠点災害のいずれが発生しても、最低1つのバックアップを確保できます。
バックアップ頻度の決め方
バックアップ頻度はRPOと連動します。RPO=1時間であれば、1時間ごとのバックアップが必要です。重要度の低いシステムはRPO=24時間として、日次バックアップで十分な場合もあります。
バックアップの定期テスト
バックアップを取得するだけでは不十分です。実際に復元できるかを定期的にテストすることが重要です。「バックアップはあるが、いざというときに復元できなかった」という事態を防ぐために、半年に1回程度は復元テストを実施することをお勧めします。
システム冗長化の基本
冗長化とは、システムの一部が故障しても、全体の機能が停止しないよう予備の構成要素を用意しておくことです。
単一障害点（SPOF）の排除
Single Point of Failure（SPOF）とは、そこが故障すると全体が停止してしまう箇所のことです。BCPの観点からは、重要なシステムのSPOFを特定し、冗長化することが基本的なアプローチです。
中小企業向けの段階的な冗長化アプローチ
- まずデータから: ストレージの冗長化（RAID構成）とクラウドバックアップ
- 次にサーバから: 重要なアプリケーションサーバを複数台構成にするか、クラウドへ移行
- 通信・ネットワークの冗長化: インターネット回線を2系統にする、または4G/5G回線をバックアップとして準備する
すべてを同時に実施する必要はありません。重要度の高いシステムから段階的に取り組むことが、限られた予算での現実的なアプローチです。
BCP・DR対策を始める際のポイントと注意点
BCPやDR対策を始める際、多くの企業が「何から手をつければよいか分からない」という状態に陥ります。以下のステップを参考に、スモールスタートで取り組んでみてください。
まずはリスクアセスメントから始める
最初のステップは「自社のリスクを把握する」ことです。
- 自社のビジネスにとって最も重大なリスクは何か（自然災害・火災・サイバー攻撃・人材喪失等）
- ITシステムが停止した場合、どの業務がどの程度影響を受けるか（売上・顧客対応・生産等）
- 現状のシステム構成にどのような弱点（SPOF）があるか
リスクの「特定→評価→優先順位付け」を行うことで、対策に必要なリソース（費用・人手・時間）を効率的に配分できます。
優先順位の決め方
すべてのシステムを同時に完璧に守ろうとすると、コストと時間が膨大になります。以下の基準で優先順位をつけましょう。
- 事業への影響が大きいシステムから着手: 受注・決済・在庫管理など、直接収益に関わるシステムを最優先
- RTO・RPOの目標が短いシステムを先に対策: 短時間での復旧が必要なシステムほど、対策の設計が複雑になるため早めに取り組む
- 現状で最も脆弱な箇所を優先: バックアップが全くない、冗長化されていない箇所から対応する
システム開発の優先順位付けや費用感については、システム開発の費用相場は？抑えるコツや開発会社を選ぶポイントも参考になります。
外部パートナー活用のメリット
BCP・DR対策を自社だけで設計・実装しようとすると、専門知識の不足や工数不足でつまずくことが多くあります。システム開発会社やクラウドのSIer（システムインテグレーター）と連携することで、次のメリットが得られます。
- 自社のシステム構成を評価し、リスクの高い箇所を特定してもらえる
- コストと効果のバランスが取れた対策プランを提案してもらえる
- 実装・テストまで一貫して支援してもらえる
特に中小企業では、IT専任担当者がいないケースも多いため、外部の専門家を頼ることが最も現実的な選択肢の一つです。BCP・DR対策の設計や実装を外部委託する際は、システム開発が失敗する原因と防止策も参考に、パートナー選びのポイントを確認しておくことをお勧めします。
まとめ
本記事では、BCP（事業継続計画）とDR（ディザスタリカバリ）の基本概念から、両者の違い、重要指標（RTO・RPO）の設定方法、中小企業でも実践できる具体的な対策まで解説しました。
本記事のポイントまとめ
- BCPは事業全体の継続を目的とした広範な計画。DRはBCPの一部であるITシステム復旧に特化した対策
- RTO（目標復旧時間）とRPO（目標復旧時点）は、対策の設計において最も重要な指標
- 目標値はコストと事業影響度のバランスで決定し、すべてのシステムを同水準にする必要はない
- クラウド活用・3-2-1バックアップルール・冗長化など、中小企業でも段階的に取り組める対策がある
- RTO・RPOの目標値は、ベンダーに依頼する構成・見積金額・保守契約の条件を左右する。発注前に仮値を決めておくと提案を比較しやすい
- 保守契約では、障害時の対応時間・復旧の責任範囲・バックアップと復元テスト・目標値が保証か努力目標かを確認する
- リスクアセスメント→優先順位決定→段階的実装→外部パートナー活用が成功の鍵
BCP・DR対策は「一度作れば終わり」ではなく、事業の変化・技術の進化に合わせて定期的に見直すことが重要です。まずは自社のリスクアセスメントから始め、最も影響の大きいシステムのRTO・RPOを仮決めしたうえで、発注先との相談に臨んでみてください。
システムの構成評価やBCP・DR対策の設計・実装についてお悩みの場合は、秋霜堂株式会社のTechBandにお気軽にご相談ください。中小企業のシステム開発・IT基盤整備を専門とするエンジニアが、現状の課題整理から具体的な対策提案まで、貴社の状況に合わせてご支援します。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- BCPとDR、自社で最初に着手すべきなのはどちらですか？
まずはBCPの観点でリスクアセスメントを行い、事業への影響が大きいシステムを特定してからDR対策に着手するのが現実的です。事業への影響度評価がDR対策の優先順位をBCPの事業継続目標と連動させる起点になるため、ITだけを先に固めても事業全体の優先順位とずれてしまいます。
- 自社に適したRTO・RPOの数値がわかりません。どう決めればいいですか？
業種目安を出発点にしつつ、まず重要度の高いシステムに仮の目標値を設定し、事業影響度とコストのバランスを見ながら段階的に精緻化する方法が現実的です。例えばEC・オンライン取引はRTO1〜4時間・RPO15分〜1時間が目安になりますが、最初から完璧な数値を出す必要はありません。
- IT専任担当者がいない中小企業でも、BCP・DR対策は進められますか？
はい、クラウドサービスの活用によって低コストで始められます。具体的にはAWS S3等のオブジェクトストレージへのバックアップ保存や、異なるリージョンにデータ・システムを複製するクラウドDRが代表的なアプローチです。自社での判断が難しい場合は、システム開発会社やSIerに現状評価と対策プランの提案を依頼するのが現実的な進め方です。
- BCP・DR対策にはどの程度の予算を見込むべきですか？
決まった相場はなく、重要度の高いシステムから段階的に投資するのが基本です。まずはクラウドバックアップなど低コストな対策から始め、効果を確認しながら冗長化などへ範囲を広げると予算をコントロールしやすくなります。
- 外部パートナーにBCP・DR対策を相談する際、事前に何を準備すればよいですか？
自社のシステム構成一覧と、想定される主なリスク（災害・サイバー攻撃・障害等）を簡単に整理しておくとスムーズです。加えてどのシステムが止まると事業にどの程度影響するかという重要度の目安も伝えられると、現状把握が進み的確な対策プランの提案を受けやすくなります。
