会社情報
採用情報
お問い合わせ
Article

BCP（事業継続計画）とIT災害対策の作り方

高田晃太郎
BCP（事業継続計画）とIT災害対策の作り方

統計によると、国内でBCP（事業継続計画）を文書化し定期演習まで回している企業は依然として多数派とは言い難いのが現実です。中小企業庁の2024年版中小企業白書では、2023年の策定率は大企業で約35.5%、中小企業で約15.3%と報告されています[1]。一方で停止や情報漏えいがもたらす損失は増加傾向にあり、IBMのCost of a Data Breachレポートでは、2023年の平均被害額が約445万米ドルとされ、直近の版でも上昇傾向が続いています[2,11]。つまり「止めない設計」はスローガンではなく、数値から逆算して作るエンジニアリングの営みです。本稿では、CTO・エンジニアリーダーが業務改善とシステムの効率化を両立させながら、実戦的な継続計画とIT災害対策（以下、DR）を構築するための要点を、公開情報と現場のベストプラクティスに基づいて整理します。

BCPの骨格：BIAからRTO/RPOへ、事業要件を技術言語に翻訳する

計画は「紙の計画」ではなく、事業の重要成果を守るための設計制約を明示する文書です。最初に取り組むべきは事業影響分析（BIA: Business Impact Analysis）であり、売上・法令順守・ブランド毀損といった影響軸を金額や時間の単位に落とし込み、最大許容停止時間（MTD）、目標復旧時間（RTO）、目標復旧時点（RPO）を定義します[4,5]。ここで重要なのは、RTO/RPOがSLO（Service Level Objective）の一種であり、以後のアーキテクチャや運用設計を縛る非機能要件だと明確に位置づけることです。たとえば注文処理のRTOを1時間、RPOを15分と決めた瞬間、ストレージの複製方式、フェイルオーバーの形態、バックアップの頻度、監視（SLI: Service Level Indicator）の粒度は自動的に絞り込まれます。

可用性と停止時間の換算も、技術判断を助けます。年換算の停止時間は「（1 − 可用性）× 365日 × 24時間」で評価でき、99.95%は約4.38時間、99.99%なら約52分です[6]。カート放棄率やコンバージョンの弾性から時間当たりの逸失利益を推計し、1時間あたりの停止コストが1,000万円規模であるなら、RTOを8時間から1時間に短縮する投資は単一インシデントで7,000万円の回避効果をもたらす可能性があります。定量モデルを先に作ることで、過剰投資を避けつつも必要な冗長化に迷いがなくなります。

事業影響分析（BIA）をエンジニアリング作業に落とし込む

BIAは会議体の合意で終わりがちですが、本質はシステムとデータの単位に分解し、依存関係の有向グラフ（依存マップ）へ写像する作業です。注文から決済、在庫、配送、会計までの業務シーケンスを描き、各ノードに対してMTD/RTO/RPOを割り当てます。データについては分類と棚卸しを並行して進め、トランザクションデータ、参照データ、ログ・監査証跡といった種類ごとに許容損失と復旧優先度を明示します。各種実務ガイドでも、バックアップは保管よりも復元の再現性（実際に戻せること）の検証を重視すべきだとされています[4,10]。よってBIAの成果物は、復旧順序のランブック、データ整合性の検証ステップ、そして切り戻し条件を含んだ具体的な運用ドキュメントに接続されなければ意味がありません。

重要業務の階層化と依存関係の可視化

全業務を同じRTO/RPOで守るのは非効率です。Tier 0にアイデンティティ基盤やKMS（鍵管理）、Tier 1に注文・決済、Tier 2にレポーティングや社内ポータルといったように階層化し、各Tierで冗長化レベルを変えます。依存関係の可視化にはCMDB（構成管理DB）やサービスカタログを活用し、インフラ、プラットフォーム、アプリ、外部SaaSの結合点を洗い出します。とくにSaaSは可用性が高い一方で、テナントの論理削除や設定ミスに起因するデータ損失が無視できません。責任分界（どこまでがユーザー責任か）を明確にし、後述のSaaSバックアップ戦略と整合させます。業務改善の観点では、この依存マップ自体がボトルネックの発見装置として機能し、システムの効率化や権限設計の見直しに波及効果を生みます。

技術設計の原則：冗長化、バックアップ、分離でRTO/RPOを満たす

RTO/RPOを満たす設計は、冗長化・バックアップ・分離（コンテインメント）の三本柱で考えると整理しやすくなります。冗長化は可用性を高め、バックアップは時間軸の巻き戻しを可能にし、分離は障害や侵害の波及を食い止めます。求める結果が明確なら手段の選択は自ずと収束します。

RPOを満たすデータ保護：スナップショット、ログ、変更データ取得

RPOは「どこまで巻き戻せるか」です。ブロックやファイルのスナップショットは高速かつ一貫した時点復旧を提供しますが、細粒度の目標にはトランザクションログやWALの整備が不可欠です。変更データキャプチャ（CDC）を採用すれば、非本番への検証リストアや監査目的の差分抽出が容易になります。クラウドストレージではオブジェクトロック（WORM: 書き換え不可）やバージョニングを有効化し、ランサムウェアに対する改ざん不能な保管を実現します[7]。バックアップは3-2-1-1-0ルール（3世代、2種類のメディア、1つはオフサイト、1つは不変ストレージ、検証エラー0）を目安に設計し[8,9,10]、復旧テストをスケジュールに組み込みます。バックアップ成功率だけでなく、実測の復旧時間と整合性検証の合格率をSLOとして運用に組み入れることが、業務改善とシステム効率化の両面で効きます。

参考までに、オブジェクトストレージの不変化設定は次のように自動化できます（例: AWS CLI）。実環境ではリージョンや規制要件に応じて保持期間・権限を調整してください。

# バケット作成時にオブジェクトロックを有効化
aws s3api create-bucket \
  --bucket my-backup-bucket \
  --object-lock-enabled-for-bucket

# バージョニング有効化
aws s3api put-bucket-versioning \
  --bucket my-backup-bucket \
  --versioning-configuration Status=Enabled

# 既定の保持ポリシー（例: コンPLIANCEモードで90日）を設定
aws s3api put-object-lock-configuration \
  --bucket my-backup-bucket \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {
      "DefaultRetention": {"Mode": "COMPLIANCE", "Days": 90}
    }
  }'

なおSaaSのデータは、サービス提供者の可用性SLAとユーザ責任の間にギャップが存在します。誤削除や設定誤り、内部不正に備えるには、専用のSaaSバックアップを用いて独立した保管域にエクスポートし、復旧手順をプロダクト横断で標準化します。SaaSバックアップの設計ポイントは、APIレート制限下でのRPO達成、メタデータ・権限の復元精度、法規制に合致した保管場所の選択です。詳細は社内標準に落とし込み、浸透が早まります。

RTOを満たすフェイルオーバー：アクティブ/アクティブとウォームスタンバイ

RTOは「どれくらいで立ち上がるか」です。ゾーン障害に対しては同一リージョンのマルチAZ（複数アベイラビリティゾーン）でアクティブ/アクティブ構成を取り、レプリケーションは同期を前提にレイテンシ許容値と相談して決定します。レプリケーション遅延がユーザ体験を損なう場合、書き込みのシャーディングやリージョンごとのデータオーナーシップを検討します。リージョン障害に対してはウォームスタンバイが現実解であり、インフラは常時起動を最小限に抑えつつ、IaC（Infrastructure as Code）で短時間にキャパシティを拡張できるようにしておきます。DNSやトラフィックマネージャによるヘルスチェックと重み付きルーティングは、RTOを分単位に収めるうえで有効です。復旧の最長経路を短縮するため、コンテナイメージの署名・キャッシュ、ベースAMIの定期更新、シークレットの複製ポリシーを日常運用に組み込み、演習で現実の数字を取ります。

侵害の広がりを抑える分離の設計も欠かせません。ネットワークセグメント、プロジェクト/アカウント境界、権限境界を一致させ、特権はブレイクグラス方式（緊急時のみ短時間付与・多要素・監査付き）で限定します。ゼロトラストの原則は災害時にも効きます。たとえば侵害時の横移動を防ぐマイクロセグメンテーションは、部分復旧の安全な同時進行を可能にします。

運用で仕上げる：演習、可観測性、コミュニケーション

計画は演習でしか成熟しません。テーブルトップ演習で意思決定の流れを確認し、ゲームデイで計画停電やリージョン障害のシナリオを実地に再現します。観測面では、SLO/SLIを事業の価値に結びつけ、MTTD（検知時間）とMTTR（復旧時間）を継続的に短縮します。ステークホルダーコミュニケーションは定型化し、社内外ステータスページとメッセージテンプレートを準備します。サードパーティとの窓口と緊急連絡網は、実地の電話・ビデオ会議まで検証しておきます。これらは業務改善の文脈でも効力を発揮し、障害のみならず計画停止の短縮や変更管理の精度向上として効率化に跳ね返ります。

演習設計と指標：合否ではなく学習速度を測る

演習は「合格するため」ではなく「速く学ぶため」に設計します。準備段階で明確な仮説（例：ウォームスタンバイのスケールアウト完了が15分以内）を置き、演習で計測した実測値と差分を振り返ります。復旧時間、データの整合性、コミュニケーション遅延、エスカレーションの正確性、意思決定の根拠といった観点でポストモーテムを作成し、アクションは責任者・期限・期待効果をセットで管理します。重要なのは、演習の頻度と改善の速度をKPIとすることです。四半期ごとにRTO/RPOに関わるSLOを最低一つは改善し、翌期の予算や人員計画とリンクさせると、継続計画は持続的な業務改善のプログラムに昇華します。関連する実務の進め方は参考になります。

コミュニケーション：役割の単純化と情報の一元化

災害時に最も高コストなのは情報の断片化です。インシデント指揮、技術対応、広報・法務、経営判断の役割を単純化し、一本の情報チャンネルに集約します。意思決定権限は事前に委譲しておき、代行基準や再開基準（リ・オープンの条件）を明記します。監査ログや変更管理の一時緩和は、後日の追跡可能性とトレードオフになりがちなので、緩和できる範囲・期間・承認手順を計画に書き込みます。社外向けの発表は、顧客影響・暫定対策・次報予定時刻を最初の30分で示す方針にしておくと、信頼の毀損を最小限に抑えられます。

費用対効果を作る：投資の段階設計とFinOps

継続計画やDRはコストセンターだと誤解されがちですが、停止コストと比較した投資判断に立てば、明確なROIを持つプロダクト能力です。定量モデルはシンプルで構いません。平均取引単価、同時接続、コンバージョン、ペナルティや機会損失を掛け合わせ、時間当たりの停止コストを推定します。そこに発生頻度の仮説を置けば、期待損失に基づく妥当な投資上限が得られます。例えば年1回のメジャー障害で平均停止6時間、1時間あたり1,000万円の損失なら、RTO短縮で3時間削減できる施策には年間3,000万円までが投資上限の目安となります。クラウドのクロスリージョンを常時アクティブにするとランニングが跳ね上がる場合、ウォームスタンバイとスポット・予約の組み合わせ、ストレージの階層化、データ圧縮・ライフサイクル管理でTCOを抑制します。コスト最適化の考え方はFinOpsの原則と親和性が高く、災害対策と効率化を同じ枠組みで意思決定できます。

段階的な導入も重要です。初期段階ではバックアップの不変化と復旧演習の自動化に集中し、次にマルチAZ化とパイプラインの冪等性を高め、最後にクロスリージョンのウォームスタンバイへ拡張します。各段階でRTO/RPOと実コスト、運用負荷の三点を毎月レビューし、費用対効果が鈍化したら設計を見直します。設計原則は一つで、RTO/RPOという事業制約に対して最短の経路を選び続けることです。

ケーススタディ：EC企業の90日プログラム（仮想事例）

国内EC企業の一般的なケースを想定します。平均注文数の季節変動が大きく、停止1時間当たりの損失は約1,200万円と試算されていました。初期状態は単一リージョン、バックアップは日次、演習は年1回という状況です。BIAの再定義で注文処理をTier 1と定め、RTO1時間・RPO15分を目標に据えました。データ保護はスナップショットの短周期化とトランザクションログの外部保管を組み合わせ、オブジェクトロックを導入。アプリはステートレス化を進め、セッションは分散キャッシュに寄せました。クロスAZのアクティブ/アクティブ化とDNSヘルスチェックを実装し、ウォームスタンバイ用のテンプレートをIaCで整備。演習は月次ゲームデイへ移行し、3回目でフェイルオーバー完了が18分、完全復旧が46分を達成しました。TCOは月+18%に留まりましたが、単一インシデントの回避効果だけで費用を相殺できる見通しとなり、恒常運用の意思決定につながります。結果として、平時のデプロイ時間短縮や権限棚卸しの効率化も副次効果として現れ、業務改善のKPIも同時に前進しました。

まとめ：計画は数字から逆算し、演習で磨き上げる

継続計画とDRは、恐れや慣習で作るものではありません。事業の影響を数字で捉え、RTO/RPOという制約に翻訳し、冗長化・バックアップ・分離の設計で満たし、演習と可観測性で検証し続ける営みです。そのプロセスは同時に業務改善のプログラムでもあり、システムの効率化やチームの意思決定を確実に強くします。今日できる第一歩として、BIAの前提を1時間で再点検し、最重要サービスのRTO/RPOに仮説を置き、次回のゲームデイに組み込んでみてください。次に、不変バックアップと復旧検証の自動化状況を棚卸しし、最長経路のボトルネックを一つだけ削るコミットメントを掲げましょう。小さく着手し、測定し、学習する。この繰り返しが、止めないプロダクトを現実にします。

参考文献

  1. 中小企業庁. 2024年版中小企業白書 第9節 事業継続計画（BCP策定率）。https://www.chusho.meti.go.jp/pamflet/hakusyo/2024/chusho/b1_3_9.html#:~:text=match%20at%20L8%20%E3%81%AE%E4%BC%81%E6%A5%AD%E8%A6%8F%E6%A8%A1%E3%81%AB%E3%81%8A%E3%81%84%E3%81%A6%E3%82%82%E3%80%81BCP%E7%AD%96%E5%AE%9A%E7%8E%87%E3%81%AF%E4%B8%8A%E6%98%87%E5%82%BE%E5%90%91%E3%81%A7%E6%8E%A8%E7%A7%BB%E3%81%97%E3%81%A6%E3%81%8A%E3%82%8A%E3%80%812023%E5%B9%B4%E3%81%AE%E5%A4%A7%E4%BC%81%E6%A5%AD%E3%81%AEBCP%E7%AD%96%E5%AE%9A%E7%8E%87%E3%81%AF35
  2. IBM Newsroom. IBM Report: Half of Breached Organizations Unwilling to Increase Security Spend Despite Soaring Breach Costs (Cost of a Data Breach Report 2023)。https://newsroom.ibm.com/2023-07-24-IBM-Report-Half-of-Breached-Organizations-Unwilling-to-Increase-Security-Spend-Despite-Soaring-Breach-Costs?3F%3F%3Futm_source=%28SOCIAL_NETWORK%29#:~:text=Breach%20Report%2C,portion%20of%20breach%20costs%2C%20and
  3. Better Stack Community. Availability table: downtime per availability percentage。https://betterstack.com/community/guides/incident-management/availability-table/#:~:text=99.95,0.36%20seconds
  4. IBM Japan. ディザスタリカバリー（DR）戦略の基礎。https://www.ibm.com/jp-ja/think/insights/disaster-recovery-strategy#:~:text=,%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC%E3%81%AB%E7%B6%99%E7%B6%9A%E7%9A%84%E3%81%AB%E3%82%B3%E3%83%94%E3%83%BC%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82%E3%81%BE%E3%81%9F%E3%80%81%E8%A8%B1%E5%AE%B9%E5%8F%AF%E8%83%BD%E3%81%AARPO%E3%82%92%E6%95%B0%E5%88%86%EF%BC%88%E3%81%BE%E3%81%9F%E3%81%AF%E6%95%B0%E6%99%82%E9%96%93%EF%BC%89%E3%81%AB%E8%A8%AD%E5%AE%9A%E3%81%97%E3%80%81%E3%81%9D%E3%81%AE%E9%96%93%E3%81%AB%E5%A4%B1%E3%82%8F%E3%82%8C%E3%81%9F%E3%82%82%E3%81%AE%E3%81%8C%E4%BD%95%E3%81%A7%E3%81%82%E3%82%8C%E5%BE%A9%E6%97%A7%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E3%82%8F%E3%81%8B%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E4%BC%81%E6%A5%AD%E3%82%82%E3%81%82%E3%82%8A
  5. ISC2 Japanブログ. 事業継続計画（BCP）の基礎とMTD/MTPoD・RTO・RPO。https://japan.isc2.org/blog2021/business-continuity.html#:~:text=%EF%BC%89%E3%82%92%E5%AE%9F%E6%96%BD%E3%81%99%E3%82%8B%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82%E5%88%86%E6%9E%90%E3%81%A7%E3%81%AF%E3%80%81%E5%90%84%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E6%A9%9F%E8%83%BD%E3%81%AB%E9%87%8D%E8%A6%81%E5%BA%A6%E3%83%AC%E3%83%99%E3%83%AB%E3%82%92%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%80%81%E6%9C%80%E5%A4%A7%E8%A8%B1%E5%AE%B9%E5%81%9C%E6%AD%A2%E6%99%82%E9%96%93%EF%BC%88MTD%EF%BC%9AMaximum%20Tolerable%20Downtime%EF%BC%89%E3%81%A8%E6%9C%80%E5%A4%A7%E8%A8%B1%E5%AE%B9%E4%B8%AD%E6%96%AD%E6%9C%9F%E9%96%93%EF%BC%88MTPoD%EF%BC%9AMaximum%20Tolerable%20Period,%E3%82%92%E7%A4%BA%E3%81%97%E3%81%BE%E3%81%99%E3%80%82%E3%81%93%E3%81%AE2%E3%81%A4%E3%81%AF%E3%80%81%E7%9B%AE%E6%A8%99%E5%BE%A9%E6%97%A7%E6%99%82%E9%96%93%EF%BC%88RTO%EF%BC%9ARecovery%20Time%20Objective%EF%BC%89%E3%81%A8%E7%9B%AE%E6%A8%99%E5%BE%A9%E6%97%A7%E5%9C%B0%E7%82%B9%EF%BC%88RPO%EF%BC%9ARecovery%20Point%20Objective%EF%BC%89%E3%81%AE%E3%82%A2%E3%83%97%E3%83%AD%E3%83%BC%E3%83%81%E3%81%AB%E7%9B%B4%E6%8E%A5%E3%81%A4%E3%81%AA%E3%81%8C%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82
  6. HostDean. Uptime Calculator（可用性と年間停止時間の換算）。https://hostdean.com/tools/uptime-calculator/99.95/#:~:text=99.9,1.8%20seconds
  7. AWS. Amazon S3 Object Lock（WORM/イミュータブルストレージ）。https://aws.amazon.com/vi/s3/features/object-lock/#:~:text=retention,user%20in%20your%20AWS%20account
  8. TechTarget SearchDataBackup. How the 3-2-1-1-0 backup rule reflects modern needs（ルールの概要）。https://www.techtarget.com/searchdatabackup/tip/How-the-3%20-2-1-1-0-backup-rule-reflects-modern-needs#:~:text=The%203%20in%20the%203,addition%20to%20the%20original%20data
  9. TechTarget SearchDataBackup. 同上（不変ストレージの要件）。https://www.techtarget.com/searchdatabackup/tip/How-the-3%20-2-1-1-0-backup-rule-reflects-modern-needs#:~:text=The%20second%201%20in%20the,is%20critical%20to%20have%20at
  10. TechTarget SearchDataBackup. 同上（検証とエラーゼロの原則）。https://www.techtarget.com/searchdatabackup/tip/How-the-3%20-2-1-1-0-backup-rule-reflects-modern-needs#:~:text=The%200%20in%20the%203,out%20and%20resolve%20errors%20early
  11. IBM Security. Cost of a Data Breach Report（最新版）。https://www.ibm.com/reports/data-breach