高可用性＝高コストの落とし穴：発注側が陥りやすい“ゼロダウン神話”

2025/05/07

みずほ銀行の障害に学ぶ、可用性神話の危うさ

「止まってはいけない」と思われがちな銀行の勘定系システム。しかし、2021年に相次いだみずほ銀行のシステム障害は、「止まらないシステムを目指しすぎた結果、相対的に止まったときの備えが不十分だった」ことが、障害の深刻化を招いた典型例といえるでしょう。

本来であれば、万一の障害を想定した復旧計画やフローの整備が求められるところですが、「決して止まってはならない」そして「徹底的に事前対処したから止まらないはず」という前提に立った考えのもと、障害発生時の初動対応が想定されておらず、十分な訓練や役割分担の準備もなされていませんでした。

実際に、システムが停止した現場では、マニュアルの所在すら不明で、誰が対応の指揮を執るのかも曖昧な状態に陥り、関係者間での連絡も錯綜しました。緊急時のフローが明文化されていなかったため、現場はパニック状態に。ATMは稼働停止し、預金者の不安が一気に広がったことで、社会的信用の失墜にまでつながりました。

結果的に、障害対応における準備不足が露呈し、「高可用性＝絶対に止まってはならない＝絶対に止まらない」と信じ込んだがゆえに、実際に止まった際の復旧に大きな遅れが生じました。このような“神話”に基づく設計方針は、リスク管理の観点から極めて危険であると言えます。

システムは止まるもの。だから備える

たとえ可用性99.99%（”フォーナイン”）の高可用構成であっても、年間約5分の停止は理論的に許容されている計算です。つまり、どんなにお金をかけても「絶対に止まらない」システムは存在しません。

それにもかかわらず、「止まってはならない」という発注側の心理が、「止められない構成」を求める結果となり、無駄な投資が膨らむケースが後を絶ちません。さらに厄介なのは、システムが止まった際の備えがないまま構築されることにより、障害時の対応が後手に回り、結果的に被害が拡大してしまう点です。

重要なのは、「止めることはある」という前提に立った設計と、止まったときの迅速な復旧体制、そして業務継続を支えるフローの整備です。高可用性を追うことと同じくらい、「止まるリスクへの備え」も設計段階で議論すべきです。

さらに、復旧フローは図や手順書だけでなく、実際の訓練やシナリオテストを通じて関係者全体に浸透させておくことが肝要です。いざという時、誰が判断を下すのか、どの順で処理を行うのかが現場で即座に理解されている状態が、被害を最小化する鍵となります。

“止まること”を想定することで、初めて”再び動かす力”が磨かれるのです。

可用性のランクとコストの関係

可用性の向上には、指数関数的なコストがかかります。

99.0%：シングル構成、年間約3.6日停止可能

99.9%：冗長化あり、年間8.7時間停止

99.95%：マルチAZ、年間約4.4時間

99.99%：地理的冗長構成、年間5分未満

たとえば、99.0%から99.9%へ上げるにはコストが2〜3倍、99.9%から99.99%ではさらに5〜10倍になることも珍しくありません。99.999%ともなると、コストは通常の10〜20倍以上にも膨れ上がります。

ここで重要なのは、「費用が高くなる＝安定性が高まる」という単純な図式に陥らないことです。可用性は業務影響額とセットで評価すべきです。たとえば、1時間のシステム停止によって数百万円の損失が生じる業務と、停止しても数時間後にバッチ処理で挽回できる業務では、求めるべき可用性レベルが異なって当然です。

実際に、金融系では“3拠点冗長”や“常駐オペレーション体制”が一般的ですが、行政系や公共系では「夜間はメンテナンス可」とすることで、必要な可用性を抑える設計も存在します。このように、業務特性に応じた適正な可用性の見極めが、コストを左右する重要なポイントです。

「止まっても困らない設計」という視点

すべての業務に99.99%の可用性が必要でしょうか？ たとえば、昼間の決済処理と、夜間の帳票出力は、同じレベルの可用性である必要はありません。

この業務ごとの重要度を見極めず、すべてを高可用で設計すると、初期コストだけでなく運用コストも膨大になります。加えて、複雑すぎるシステム構成は、かえって障害発生時の切り分けや復旧対応を難しくするリスクもあります。

理想は、業務別に求められる可用性の”地図”を描くことです。業務影響度、ユーザー数、タイミング、復旧猶予時間（RTO）などを基に、段階的にシステムを設計すれば、最小コストで最大の価値が得られます。

求めるべきは、“止まっても被害が最小限にとどまる設計”。つまり、「システムを止めないこと」ではなく、「止まっても業務が破綻しないこと」こそが本質なのです。システムの設計思想を、“常に動き続ける前提”から“止まっても許容できる設計”へと転換することで、無駄な投資と潜在的リスクの両方を回避できます。

RFPに可用性を正しく書く意味

多くのRFPでは、「高可用構成で」と一言書かれるのみで、可用性の数値すら示されていません。これでは、ベンダは無難に高額構成を提案せざるを得ず、結果として発注側にとっても無駄な支出となります。

「この業務は99.95%、この部分は99.0%でよい」など、業務ごとの可用性目標を明記すれば、ベンダはより現実的かつコスト効率の良い提案が可能になります。

また、可用性目標を明示することで、提案内容に対する評価もしやすくなり、RFP自体の品質向上にもつながります。発注側の責任として、可用性に関する判断基準を言語化し、設計や契約に落とし込むことが、プロジェクト全体の成功確率を高める要となるのです。

さらに、ベンダ側の創造性や工夫を引き出すためにも、「どうやって止めないか」ではなく、「どこまで止まってよいか」をRFPで明示する姿勢が、提案内容の質を大きく左右します。ベンダ任せではなく、発注側の意思として可用性レベルを示すことが、コストとリスクの両面での最適化を導きます。

まとめ：「止まるべきではない」から「止まっても慌てない」へ

システムは止まるものです。重要なのは、止まらないことではなく、止まったときの影響を最小限にし、早期復旧できる体制と設計を整えておくことです。

そのためには、可用性に対する正しい理解と、業務特性に応じた要件定義、そしてRFPでの適切な表現が不可欠です。

“止めたくない”という思いが、“止められない”構成を呼び、結果的にコスト肥大とリスク増大を招かないよう、今一度「止まる前提の設計」という視点を見直すべき時です。可用性の追求と同時に、障害発生時の対応設計・訓練・体制整備こそが、実は最もコストパフォーマンスの高い投資であるという認識を持つことが、今後の発注者に求められる姿勢です。

高可用性を志向すること自体は悪ではありませんが、それが過剰であったり、復旧設計とセットで語られていなかったりすれば、本来の目的を見失ってしまいます。今、IT投資の本質を問い直す必要があるのです。

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

関連記事