BCP/DR設計の鉄則 ― RPO・RTO・3-2-1ルール ― 生成AI時代のアーキテクチャ超入門

大規模障害は数年に一度、必ずどこかで起きます。2011年の東日本大震災、2021年のAWS東京リージョン障害、2024年のCrowdStrike世界規模障害。「想定外」は、日常的に発生します。ここで備えがないと「数日間サービス停止」という事態に直結し、顧客の信頼失墜・売上損失・契約違反が降りかかります。

BCPは「念のため」ではなく「いざという時の備え」です。「うちは小さいから」「今までも大丈夫だったから」という楽観は、一度でも大障害を食らえば吹き飛びます。特にSaaS事業では、1回の長時間停止で顧客が競合に流れ、二度と戻ってこないという事例を何度も見ます。

BCPは顧客信頼と直結する備えです。

RPOとRTO

BCP設計の中心概念は、RPOとRTOという2つの目標値です。この2つをまず業務部門と合意することがBCP設計の出発点です。

指標	意味
RPO（Recovery Point Objective）	何時点のデータまで戻せるか（データ損失の許容量）
RTO(Recovery Time Objective)	何分/何時間で復旧するか（停止時間の許容量）

要求レベル	RPO	RTO	例
ミッションクリティカル	ゼロ	数秒〜数分	金融取引・決済
業務重要	数分	1時間以内	ECサイト・社内基幹
通常業務	24時間	数日	社内ツール

要求が厳しいほどコストは指数関数的に増えます。RPO/RTOを無闇に厳しくすると、本来不要な莫大なインフラ投資が発生する地雷です。「どこまで止まっても許容できるか」を業務部門と冷静に合意するのが先決です。

RPO/RTOは業務部門との合意が最優先。技術先行で決めません。

可用性の階段

可用性レベルごとに、投資額が桁違いに変わります。「99.9%」と「99.99%」では年間停止時間が8.76時間→52.6分に縮まりますが、コストは数倍になります。

可用性	年間停止時間	構成	コスト感
99.0%	3.65日	単一サーバー	◎ 最安
99.9%	8.76時間	冗長化・マルチAZ	○ 中
99.99%	52.6分	マルチリージョン	△ 高
99.999%	5.26分	マルチクラウド・Active/Active	× 極高

マルチAZ（99.9〜99.95%）が現実的な標準ラインです。それ以上の可用性は金融・医療・通信など特別な要件がある場合に限り、それ以外は過剰投資になるケースが大半です。

マルチAZが標準ライン。それ以上は要件を冷静に見極めます。

DR戦略の4パターン

AWS Well-Architected Framework で整理されるDR戦略の4パターンです。左から右に進むほどRTOは短くなりますが、コストは跳ね上がります。

flowchart LR
    BR["Backup & Restore<br/>RTO: 数時間〜1日<br/>コスト: 最安"]
    PL["Pilot Light<br/>RTO: 数十分〜1時間<br/>コスト: 中"]
    WS["Warm Standby<br/>RTO: 数分<br/>コスト: 高"]
    AA["Multi-site<br/>Active/Active<br/>RTO: 0〜数秒<br/>コスト: 最高"]
    BR --> PL --> WS --> AA
    BR -.- L1[スタートアップ<br/>中小規模]
    PL -.- L2[事業基幹]
    WS -.- L3[顧客影響系]
    AA -.- L4[金融・決済<br/>ゼロダウン要求]
    classDef cheap fill:#dcfce7,stroke:#16a34a;
    classDef mid fill:#fef3c7,stroke:#d97706;
    classDef high fill:#fee2e2,stroke:#dc2626;
    class BR cheap;
    class PL,WS mid;
    class AA high;

戦略	仕組み	RTO	コスト
Backup & Restore	バックアップから復元	数時間〜1日	最安
Pilot Light	DBだけ常時稼働、APは停止	数十分〜1時間	中
Warm Standby	縮小規模で常時稼働	数分	高
Multi-site Active/Active	両サイト完全稼働	ゼロ〜数秒	最高

スタートアップや中小規模はBackup & Restoreで十分です。事業基幹や顧客影響のある系はPilot LightやWarm Standbyが現実的で、金融・決済・通信などのゼロダウンタイム要求がある場合のみActive/Activeを検討します。

Pilot LightとWarm Standby

Pilot LightとWarm Standbyはよく比較される構成です。両者の違いを理解すると、予算と復旧速度のバランスが取りやすくなります。

Pilot Light（パイロットランプ）は、消えかけの種火を常に灯しておくイメージです。セカンダリ環境にはDBだけを同期複製しており、アプリサーバーは停止状態。災害発生時にアプリを起動・スケールアウトして復旧します。

Warm Standby は、セカンダリ環境を常時稼働させるが本番より小さな規模で動かす構成です。障害時はスケールアップするだけで済むため、Pilot Lightより復旧が速い。

観点	Pilot Light	Warm Standby
セカンダリ稼働	DBのみ	縮小規模で全て稼働
切替時間	数十分〜	数分
月額コスト	中（DB+ストレージ）	高（常時フルスタック）
向くケース	1時間停止許容	数分停止許容

RPO/RTO要件で選びます。オーバースペックは無駄です。

マルチサイト Active/Active

Multi-site Active/Active は、両リージョンが常に稼働し、通常時から負荷を分散する最高峰の構成です。RTOはゼロ〜数秒ですが、実装難易度とコストが桁違いに高いです。

必要要素	内容
グローバルDNS	Route 53 / Global Accelerator で振り分け
双方向DBレプリケーション	Aurora Global / DynamoDB Global Tables
セッション共有	両リージョンで同じセッションを扱える設計
データ整合性の工夫	結果整合性（Eventual Consistency）を許容

難易度が高いのはデータ整合性の問題です。両リージョンで同時に書き込みが起きた時の競合処理、結果整合性を許容するアプリケーションアーキテクチャ、どちらが正本かの管理などを真剣に考える必要があります。「真に必要な場合のみ採用」が鉄則で、過剰採用で複雑性の沼に沈む案件が後を絶ちません。

Active/Activeは設計難度が段違い。本当に必要か何度も問います。

バックアップの3-2-1ルール

3-2-1ルールは、バックアップの世界的な標準指針です。これを守れば、災害・ランサムウェア・人的ミスのどの脅威にも対応できます。

ルール	内容
3つのコピー	オリジナル+2つのバックアップ
2種類のメディア	異なるストレージ種別で保管
1つはオフサイト	地理的に離れた場所・別クラウド

クラウドでの実装例は以下の通りです。

S3 Cross-Region Replication で別リージョンに自動複製
AWS Backup で複数サービスを統合バックアップ
別AWSアカウントへの保管で誤削除・攻撃対策
オフラインストレージ（Glacier Deep Archive等）にコールドコピー

単に「バックアップを取る」だけでは不十分で、どこに・何世代・いつまで保管するかを明確に設計する必要があります。

ランサムウェア対策

現在最大級の脅威がランサムウェアです。バックアップも暗号化されてしまうと身代金を払うしかなくなるので、バックアップを守る設計が不可欠です。

対策	内容
Object Lock / WORM（Write Once Read Many、一度書いたら読むだけで変更不可）	書き込み後一定期間変更不可にする
別アカウントへの隔離	本番アカウントの権限侵害でも触られない
オフライン/コールドストレージ	ネットワーク接続なしで保管
監査ログの改竄防止	CloudTrail → S3 + Object Lock
MFA Delete	S3オブジェクト削除にMFA（多要素認証）必須化

原則は「管理者権限を奪われてもバックアップだけは消せない設計」です。本番と同じAWSアカウント内のS3にバックアップを置くだけでは、アカウント侵害時に全て消される可能性があります。別アカウント・別組織・オフラインへの多層保管が必要です。

冗長化のパターンと訓練

システム内の冗長化には、いくつかの典型パターンがあります。用途ごとに使い分けます。

構成	仕組み	用途
Active-Active	両方稼働・負荷分散	Webアプリ・APIサーバー
Active-Standby	片方は待機・切替時起動	DBマスタ・ファイルサーバー
N+1	N台必要+予備1台	ワーカー系
N+M	N台+予備複数	大規模クラスタ

Webアプリは Active-Active（ロードバランサーで均等配分）、DBは Active-Standby（データ整合性確保のため単一書き込み）が一般的です。Aurora や Cloud SQL はマネージドでこれを自動実現します。

障害訓練（Chaos Engineering）

冗長化しただけでは不十分で、「本当に切り替わるか」を定期的に訓練しないと、いざという時に動きません。これが Chaos Engineering（カオスエンジニアリング）の考え方です。

手法	内容
Game Day	計画的な障害演習・チーム総動員
Chaos Monkey	ランダムにインスタンスを停止（Netflix発祥）
Failoverテスト	本番相当環境での切替演習
DR訓練	リージョン切替を実施

「訓練しない冗長化は機能しない」が厳しい真実です。Netflixは本番環境でランダムにサーバーを落とすChaos Monkeyを実践し、障害に強い文化を作り上げました。日本企業でも四半期に1回のフェイルオーバー訓練が推奨されます。

冗長化は訓練で初めて価値を持つ。帳簿上の冗長化だけでは無力です。

BCP・DR運用の鬼門・禁じ手

BCPは帳簿上の装備ではなく、「動くことを毎回確認する運用」で初めて価値を持ちます。ここで事故る典型パターンです。

禁じ手	なぜダメか
バックアップを取るがリストア訓練をしない	GitLab 2017年1月31日の事件のように、本番障害時に「5種類のバックアップ全てが機能しない」が発覚する
バックアップを本番と同じAWSアカウントに保管	アカウント侵害・ランサムウェア時に暗号化・削除される。別アカウント + Object Lock が鉄則
DR構成を年1回の人間訓練のみで検証	1年の間にインフラ・権限・ネットワークが変わり、いざ発動で動かない
RPO / RTOを業務部門と合意せず技術先行で設計	過剰投資 or 過小投資が発生。「どこまで停止を許容できるか」を先に合意
マルチリージョン / Active-Activeを人員不足で採用	平時から構成管理が追いつかず、障害時には壊れた状態で待ち構えている
Object Lock / WORMを使わずバックアップ	ランサムウェアで本番バックアップごと暗号化される
フェイルオーバー先の容量を見積もらず切り替え	本番負荷が切替先に乗った瞬間に過負荷で二次障害
クラウドリージョン全停止の前提を入れない設計	2021年9月 AWS東京リージョン障害・2024年7月 CrowdStrike更新障害のように、リージョン単位の全停止は実在する

CrowdStrike 2024年障害（更新検証プロセス欠落で世界850万台のWindowsがブルースクリーン、空港・銀行・病院が停止）は、自分のクラウドが正常でもサプライチェーンの一部が止まるだけで全体が止まるという現代BCPの前提を突きつけました（詳細は付録「重大インシデント事例集」）。

冗長化は訓練しなければ無価値。四半期に1回はフェイルオーバー実戦投入します。

AI時代の視点

AI駆動開発が前提になると、BCP・DR設計は「全てIaCで宣言・訓練もスクリプト化」できることが絶対条件になります。

手順書（Runbook）がWord文書として紙の書棚に眠っている、という運用は時代遅れです。障害対応手順をLambdaやStep Functionsのコードとして残すのが現代流。AIがインシデント発生時にRunbookを解釈・実行し、人間は判断と承認に集中する構図が広がります。

AI時代に有利	AI時代に不利
DR構成のIaC化（Terraform・CDK）	手作業のフェイルオーバー手順
Chaos Engineeringの自動化スクリプト	年1回の人間による訓練のみ
Runbookを実行可能なコードとして保管	Word・PDF文書の手順書
復旧手順をAIが読めるMarkdown化	属人化した口頭伝承

RPO/RTOのビジネス要件との合意はAI時代でも人間の仕事です。AIがインフラを復旧させても、「どれくらいの損失までなら許容するか」を決めるのは経営判断であり続けます。

AI時代のBCPは「コード化+AI実行可能」紙のRunbookは負債になります。

よくある勘違い

バックアップを取っていれば安全 → 本当はこう：「戻せるか」は別問題です。リストア訓練をしないバックアップは、取っていないのと同じ。定期的に実戻ししてRTO実測するところまでが運用
可用性は高いほど偉い → 本当はこう：99.9%と99.99%でコストは数倍です。要件とコストの釣り合いを見ずに「高いほど良い」と決めるのは典型的な甘い選択
マルチリージョンを組めば万全 → 本当はこう：マルチリージョン構成は運用難度が跳ね上がります。人員とスキルが伴わないと、平時から壊れていて障害時に機能しない地雷
オンプレのほうが災害に強い → 本当はこう：自社DCは物理被害と人員制約を同時に受けます。大手クラウドのマルチリージョンの方が、地理冗長性と自動復旧で実質的に強い

GitLabの「5種類全滅」事件（業界事例）

2017年1月31日、GitLabの運用者が本番DBを誤って削除し、用意されていた5種類のバックアップがどれも機能しないことが発覚した有名な事件があります（事件詳細は付録「重大インシデント事例集」）。本記事のBCP視点で重要なのは、バックアップを取っている≠戻せるという残酷な事実です。

教訓として、3-2-1ルールを守るだけでなく、最低でも四半期に1回は実リストア訓練をしないと、いざという時に全滅します。

バックアップの仕組みは壊れるし、権限は変わるし、ログは流れます。動くことを毎回確認する運用まで含めて、はじめて「備えている」と言えます。

取っている数ではなく、「戻せた回数」で評価します。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

機能別のRPO / RTO（業務と合意）
DR戦略（Backup / Pilot / Warm / Active）
バックアップ保管期間と世代数
バックアップの地理的分散
フェイルオーバー手順と責任者
ランサムウェア対策（Object Lock・別アカウント）
障害訓練の頻度（半期・四半期等）
連絡・エスカレーションフロー

よくある失敗

RPO/RTOを要件定義せず実装先行 ― 後で「これでは不十分」と作り直し
バックアップはあるがリストア未検証 ― 本番障害時に「実は戻せない」ことが判明。GitLab 2017年1月31日の事故では、5種類のバックアップ全てが機能しなかったことが発覚し、復旧プロセスをYouTubeで生中継する異例の事態になった
バックアップを本番と同じAWSアカウントに保管 ― アカウント侵害で全滅
フェイルオーバー訓練なしで本番導入 ― いざ発動したら手順書通り動かず数時間停止
マルチリージョンを採用したがコストで運用停止 ― 要件と予算の乖離

最終的な判断の仕方

BCP設計で最も危険なのは、「コストも考えずに厳しいRPO/RTOを掲げる」ことです。可用性は 99.9% → 99.99% で年間停止時間が10倍改善しますが、コストは数倍に跳ね上がります。

出発点は技術ではなく、業務部門との合意形成。「どこまで止まっても許容できるか」を冷静に見積もり、過剰投資と過小投資の両方を避けるのが核になります。

現実解は「マルチAZ + 3-2-1バックアップ」が標準ラインで、これ以上はミッションクリティカルな業種（金融・医療・決済）だけが選ぶ贅沢です。さらに重要なのは「冗長化は訓練しなければ無価値」という前提で、バックアップのリストア訓練・フェイルオーバー訓練を定期実施する仕組みを最初から組み込むこと。

紙のRunbookは実質動かず、AI時代ではコード化されたRunbookでないと機能しません。

選定の優先順位をまとめると次の通りです。

業務部門とRPO/RTOを合意してから技術を選ぶ（逆にしない）
マルチAZ + 3-2-1バックアップをベースラインに
ランサムウェア対策（Object Lock・別アカウント保管）を最初から組み込む
訓練計画を運用に組み込む（Chaos Engineering・DR訓練）

「訓練しない冗長化は無意味」BCPは帳簿上の装備ではなく、動かせる状態で初めて価値を持ちます。

まとめ

本記事はBCP・DR設計について、RPO/RTO・可用性の階段・DR戦略・3-2-1バックアップ・ランサムウェア対策まで含めて解説しました。如何だったでしょうか。

業務部門とRPO/RTOを合意してから技術を選ぶ。マルチAZ + 3-2-1バックアップが標準ライン。冗長化は訓練しなければ無価値。この3点を外さなければBCP設計の核は押さえられます。

次回はシステムアーキテクチャカテゴリの最終記事、「コスト管理（FinOps）」について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。