こんにちは。ＳＣＳＫの池田です。
今回は、多くの企業で「対策済み」と思われがちなBCPにおけるIT基盤のリスク——特にDR（災害復旧）とHA（高可用性）の違いについて解説していきます。「DRさえあれば大丈夫」という安易な判断が、実は事業継続の重大な死角となっていることを、具体的なケースを交えながらご説明します。
はじめに：BCP策定の「当たり前」が招くリスク
企業の事業継続計画（BCP）策定が義務化され、多くの組織で計画が整備されるようになった今もなお、IT基盤の停止というリスクは「対策済み」と安易に判断されがちです。特に「DR（Disaster Recovery：災害復旧）対策はしているから安心」という思いこみが、実は重大なBCPの死角となっているケースが少なくありません。
本稿では、DRとHA（High Availability：高可用性）の本質的な違いを解き明かし、両者を適切に組み合わせることで「止まらないIT基盤」を実現するためのリスク管理のフレームワークを提示します。
第1章：「DRで十分」という誤解の構造
1.1 DRの本質は「復旧」、HAの本質は「継続」
多くの経営層やIT責任者がDRとHAを混同する根本原因は、両者とも「システム停止に備える対策」という大枠で語られることが多いことにあります。しかし、技術的なアプローチと目指す成果には決定的な違いがあります。
DR（災害復旧）は、あくまで「災害などでシステムが停止した後、どれだけの時間で復旧できるか」を重視した設計です。目標復旧時間（RTO：Recovery Time Objective）と目標復旧時点（RPO：Recovery Point Objective）が主要な指標となり、バックアップデータの遠隔保管や代替サイトでの復旧手順が中核をなします。つまり、「一度止まってから、何とか戻す」というアプローチです。
一方、HA（高可用性）は、「止まらないようにする」ことを目的とします。単一の障害点（SPOF）を排除し、システム構成要素の冗長化と自動フェイルオーバメカニズムにより、サービス継続性を担保します。ユーザーがほぼ気づかないようなレベルで代替系に切り替わり、事実上「停止が発生しない」状態を目指します。
この違いは、ビジネスインパクトの面で決定的です。DRのみに依存した場合、システム停止から復旧完了までの間、事業活動は完全に停止します。一方、HAが機能していれば、事業継続に実質的な影響は出ません。
1.2 「DRで十分」が生む3つの重大リスク
リスク1：停止時間の経済損失の過小評価
DR対策の計画策定時、RTOを「4時間」と設定するケースは少なくありません。しかし、実際の災害時には、障害認識〜代替サイト決定〜復旧作業開始までの判断プロセスだけで1時間以上を要することがあります。さらに、復旧後のデータ整合性確認や業務検証を含めると、実質的な停止時間はRTOの数倍に広がることも珍しくありません。
金融機関での調査では、システム停止1時間あたりの損失が数千万円から数億円に達するケースも報告されています。DR頼みの「4時間停止」が許容できると判断した企業でも、実際の損失額を再計算するとBCPの前提が崩れるという事例は枚挙にいとまがありません。
リスク2：「計画的な停止」という盲点
DR対策は、災害などの「予測不能な事象」を想定した設計です。しかし、実際の業務現場では、計画的なシステム停止がビジネス損失を招く場面が少なくありません。定期的なメンテナンス、アプリケーションバージョンアップ、ハードウェア更新など、予定された停止であっても、顧客向けサービスの24時間運用が求められる時代に「計画停止」を許容できる企業は少なくなっています。
HAなしのDR対策だけでは、この「計画的な停止」に対する回答はありません。結果として、いざという時の災害対策は整っていても、日常的な運用上の制約がビジネス機会損失を生むという逆説的な状況が生まれます。
リスク3：復旧後の「信頼回復コスト」の見落とし
DRによる復旧後、即座に通常業務に戻れるかというと、必ずしもそうではありません。特に顧客向けサービスでは、停止事実自体が信用失墜につながり、復旧後も顧客流出が継続するケースがあります。SNS時代には、数分の停止でも即座に社会に拡散され、ブランド価値に傷がつくことも珍しくありません。
HAによる「事実上の停止なし」であれば、この信頼回復コスト自体が発生しません。DR対策のコスト計算に「復旧後の信頼回復費用」を含めた企業は少なく、これがBCPの重大な見落としとなっています。
第2章：DRとHAの適切な組み合わせ方
2.1 「HA+DR」という二層防御の構造
理想的なBCPにおけるIT基盤の防御は、HAによる「止まらない」第一層と、DRによる「万が一に備える」第二層の組み合わせです。
| 層 | 目的 | 対象リスク | 主要指標 |
| 第1層：HA | サービス継続 | 単一障害、計画停止、部分的災害 | 可用性99.99%以上、RTO≒0 |
| 第2層：DR | 事業復旧 | 広域災害、データ破壊、人的ミス | RTO：数時間〜数日、RPO：数分〜数時間 |
この二層構造の重要なポイントは、HAがDRの「頻度」を大幅に減らすことです。日常的な障害はHAで吸収され、DRの出番は広域災害などの限定的な事象に限定されます。結果として、DR対策の投資効率も向上し、トータルコスト最適化が実現します。
2.2 システム特性別の最適構成
すべてのシステムに最高レベルのHAとDRを適用することは、コスト面から現実的ではありません。ビジネスクリティカル度と復旧要求度に応じた段階的アプローチが求められます。
ティア1：ミッションクリティカルシステム（コア業務系）
例：オンライン取引システム、決済基盤、生産管理システム
HA：アクティブ-アクティブ構成による完全冗長化、自動フェイルオーバ（秒単位）
DR：遠距離のスタンバイサイトへの非同期レプリケーション、RTO：1時間以内
特徴：停止許容時間がほぼゼロ、データ消失許容もゼロに近い
ティア2：重要業務システム（支援系・顧客接点系）
例：顧客管理システム、サポーターポータル、内部業務アプリ
HA：アクティブ-スタンバイ構成、自動フェイルオーバ（分単位）
DR：バックアップサイトによる復旧、RTO：4時間以内
特徴：停止は許容されるが影響が大きい、計画停止はHAで回避
ティア3：一般業務システム（補助系）
例：文書管理、社内コミュニケーション、開発環境
HA：限定的またはなし（定期的なメンテナンス停止を許容）
DR：クラウドバックアップによる復旧、RTO：1日以内
特徴：停止のビジネスインパクトは限定的、コスト優先
2.3 クラウド移行後の「HA錯覚」に注意
多くの企業がクラウド移行を進める中で、新たなリスクが生まれています。「クラウドなので自動的に冗長化されている」という誤解です。
実際には、AWSやAzureなどのパブリッククラウドでも、単一のEC2インスタンスや仮想マシンを利用している限り、可用性は有限です。AZ（Availability Zone）レベルの冗長化をHAソフトウェアで実現しない限り、インスタンス障害時には停止が発生します。さらに、クラウド特有の「停止しにくいが停止時の影響が大きい」という特性は、HA設計の重要性をむしろ高めています。
クラウド移行後に「インフラは安心」と油断し、HAレイヤーの設計を後回しにする企業が後を絶ちません。これが「クラウド時代のBCP死角」といえます。
第3章：SCSKが選ぶ高可用性の実装アプローチ
3.1 製品選定の3基準
SCSKがLifeKeeperを高可用性ソリューションの中核として選定するにあたり、以下の3基準を重視しています。
基準1：実績による信頼性
HAソフトウェアは「動作するまで信じられない」性質を持ちます。LifeKeeperは国内30年以上の導入実績を持ち、金融、製造、流通、公共などあらゆる業界で「事実上停止なし」の運用が継続されています。実績が信頼性を担保する領域において、これに比肩する製品は少ないと考えています。
基準2：柔軟な適用範囲
オンプレミスからクラウド、物理サーバーから仮想環境、WindowsからLinuxまで、同一のHAフレームワークを適用できる点が重要です。企業のIT環境がハイブリッド化・多様化する中で、統一的なHA設計・運用が実現できます。
基準3：導入後の継続的価値
HAは導入が終わりではなく、運用が本番です。SCSKはLifeKeeperの導入支援にとどまらず、継続的なサポート、アップデート支援、知見蓄積によるフォローを提供することで、長期的な可用性担保を実現しています。
3.2 「使えるHA」と「使いこなせるHA」の差
HA製品の選定において技術仕様の比較だけで判断すると陥りやすいのが、「機能はあるが現場で使いこなせない」という事態です。画面の複雑さ、設定の煩雑さ、障害時の対応不透明さなどが、結果として運用現場での形骸化運用や無効化につながります。
SCSKは、LifeKeeperの導入時に現場運用者への徹底した教育を行います。これにより現場運用者は、日々の監視業務、定期的な切り替え試験までを含めた「動くHA」を実現します。この「使いこなせるHA」こそが、BCPの目的である「有事における事業継続」を実現します。
3.3 「活躍しない」からこそ価値がある——可用性投資の本質
LifeKeeperを含むHAソリューションには、一見して逆説的な特性があります。システムが本番稼働を開始し、終了するまでの間に、HAが明白に「活躍する」場面——つまり障害発生による自動フェイルオーバが実行される機会——が全くなかったとしても、それはHAが成功裏に機能した証左です。
そして忘れてはいけないのは、本番稼働後、システム終結までに障害が発生せずLifeKeeperが活躍する場面がなかったからといって、次のシステムリプレース時に不要と判断することには少し立ち止まって頂きたいと考えます。それはたまたま運が良かっただけであり、リプレース後のシステムでも可用性の要否を真剣に検討する必要があります。可用性担保という性質上、HAは「成果が見えにくい」投資ですが、だからこそ組織的な意思決定プロセスで「活躍しなかった」ことを「不要だった」と誤認しないことが重要です。
歴史的に見ても、HAが導入されたシステムでも数年〜十数年にわたり障害によるフェイルオーバが発生しない期間が続くことは珍しくありません。しかし、それはシステムが「壊れにくい」ことを意味しません。複雑化するIT基盤において、単一障害点は常に存在し、いつ顕在化するか予測できないリスクが潜んでいます。HAの価値は、毎秒毎秒、停止リスクに対する継続的なガードを提供し続けることにこそあります。
この認識を持ってこそ、企業はリプレース時にも可用性への投資を継続し、「止まらないIT基盤」を長期的に維持することができます。
おわりに：「止まらない」を当たり前にする
BCPの本質は「有事に備える」ことではなく、「有事でも事業を継続できること」にあります。DR対策はその一部であって、全体ではありません。
デジタル化が進み、IT基盤が事業のあらゆる側面に深く組み込まれた今、「システム停止」を許容するビジネスは少なくなっています。顧客は24時間サービスを期待し、競争はグローバルで瞬時に行われ、規制当局は信頼性を厳格に求めます。
HAとDRの適切な組み合わせによる「止まらないIT基盤」は、もはや「高級志向」ではなく「標準装備」へと移行しています。SCSKは、LifeKeeperを中核とした高可用性ソリューションにより、企業のBCPを「紙の計画」から「動く基盤」へと進化させるお手伝いをしています。
そして最も重要なのは、HAの価値は「活躍する場面」ではなく「活躍が不要な状態」を継続的に維持することにあるという認識です。リプレース時にこの本質を見失わず、長期的な視点で可用性投資を継続することが、真のリスク管理につながります。
「DRで十分」という思いこみを一度見直し、本当に必要な可用性を設計し直すきっかけとして、本稿が役立つことを願っています。
詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
