「SLA 99.99%」の裏にあるコストと仕組み─「競馬と年金は同じにできない」システム設計のリアル

2025/05/09

はじめに:「99.9%で十分」という誤解

ITシステムの刷新やクラウド移行、RFP(提案依頼書)の作成時に、要件定義としてしばしば挙げられるのが「可用性」です。そして現場ではよく「99.9%くらいで十分です」といった言葉を耳にします。しかし、この“99.9%”という数字に対して、本当にどれだけの人が正確な意味とその代償を理解しているでしょうか?

この「可用性」は、単なる技術的指標ではなく、ビジネスインパクトを左右する経営判断事項でもあります。数字の大小ではなく、“業務がどれだけ止まると困るか”という視点で設計されるべきものです。可用性の設計を誤ることは、過剰投資による無駄遣いにも、逆にリスク放置による信用失墜にもつながります。

本稿では、まず可用性の数字の意味を整理し、次に可用性を高めることによるコストの増加曲線を可視化したうえで、業種ごとに求められる実態を掘り下げます。そのうえで、経営やシステム部門がどのように“妥当な可用性”を定義すべきかを考察します。

可用性とは何か?数字で見るダウンタイムの現実

可用性(Availability)は、1年間を通してそのシステムが正しく稼働している割合を示す指標です。言い換えれば、「止まっていても許される時間」の長さとも言えます。以下の表を見てください。

可用性 (%) 年間ダウンタイムの目安
99.0%

約3.65日(8,760分)

99.9% 約8.76時間(526分)
99.95% 約4.38時間(263分)
99.99% 約52.6分
99.999% 約5.3分

たとえば「99.9%」とは、「年に約9時間弱であればシステムが止まっていても許容される」という意味です。日常業務で言えば、例えば月曜日の始業時間にネットバンキングが半日止まっていたり、ECサイトが年末のセール期間中に1時間停止しても“問題ない”という設計になります。これが本当に許容されるのかは、業務内容や顧客層によって大きく異なります。

コスト曲線に見る“その先”の世界

可用性の向上は、技術的に“積み上げる”設計です。つまり、ある一定の構成を越えると、その上位の可用性を実現するためには飛躍的にコストが増大します。

可用性 構成の例 コスト増加(相対)
99.0% 単一サーバ、手動復旧 1x
99.9% 冗長化インフラ、監視システム 2〜3x
99.95% 自動フェイルオーバー+SLA付き運用 4〜6x
99.99%以上 地理冗長、DRサイト、多重構成 10x以上

ITシステムの可用性を高めるには、冗長化、監視、フェールオーバー、迅速な障害復旧などの仕組みが必要になります。これに伴い、可用性を1桁あげるごとにコストは非線形(指数関数的)に増加するのが一般的です。

特に99.95%を超える領域になると、ハードウェアだけでなくネットワーク冗長化、地理的に離れたDRサイトの維持運用、24時間365日体制の監視・即応チームの確保など、「ヒトとプロセス」にまで設計とコストが及びます。つまり可用性向上のカーブはリニアではなく、ある閾値を超えると“跳ね上がる”性質があるのです。
※DRサイトとは…災害やシステム障害で主要なシステム拠点が利用できなくなった際に、事業や業務を継続するための代替拠点。災害復旧(Disaster Recovery)のための設備や施設を指す。

【業種別比較】可用性要件の背景を知る

業種によって求められる可用性はまるで違います。以下の3つの業種を例に見ていきましょう。

金融機関(特に勘定系システム)

銀行や証券などの金融機関にとって、勘定系や決済システムの停止は致命的です。1時間の停止でも、数千〜数万件の取引に影響が及び、預金者の信頼が失墜するだけでなく、場合によっては行政処分や報道による企業イメージの悪化を招きます。

さらに日本では「全銀ネット」など他行との接続基盤が存在するため、停止が波及するリスクも考慮せねばなりません。そのため、Five 9’s(99.999%)に近い水準が求められるケースも多く、実際に地理的冗長構成やDRサイトを常設している大手金融機関が少なくありません。

• 求められる可用性:99.99%以上(Five 9’s = 年間ダウンタイム5分程度)

• 背景:
― 預金・送金・決済など、止まれば社会的信用が損なわれる
― 銀行間接続(全銀システム等)やATMネットワークが連動している
― 業務停止=法令違反・顧客離反につながるため、可用性最優先

• 対策:
― 地理的冗長構成(本番・待機・遠隔地DRサイト)
― 無停止ソフトウェア更新、フェイルオーバー機能
― 時間帯により構成を切り替える「業務日跨ぎ対応」なども

行政(例:年金管理、住民基本台帳、税務など)

行政機関が扱うシステム、例えば住民基本台帳や年金情報システムは、高い可用性が求められる一方で、制度的に「夜間のメンテナンス時間」が確保されているという事情があります。

したがって、99.95%前後の可用性が標準であり、可用性の絶対水準よりも“セキュリティや法改正への柔軟対応”といった別軸の非機能要件が重視されるケースも多いのです。

• 求められる可用性:99.95〜99.99%程度

• 背景:
― 公的サービスとして、長時間ダウンは国民生活に直結する
― ただし夜間などに保守時間が取られるケースもあるため、Five 9’s までは要求されないことも

• 対策:
― 二重化されたデータセンター(BCP・DR含む)
― 法改正・制度変更に合わせた定期停止があるため、可用性要件はやや緩めでも許容されることがある
― セキュリティ(堅牢性)も同等に重要

公営ギャンブル(例:JRA、地方競馬、totoなど)

JRA(日本中央競馬会)やtotoなどの公営ギャンブル系システムでは、週末やGIレースなどに数百万人規模のアクセスが集中します。その時間帯に1分でもシステムが止まれば、投票ができず、数億円単位の機会損失が発生します。

このような性質から、短時間でも停止が許されない、いわゆる“ゼロダウンタイム”構成が求められます。マルチリージョンのリアルタイムDB、CDNによる負荷分散、フェイルオーバー訓練など、高可用性を支える高度なアーキテクチャが必須です。

• 求められる可用性:99.99%〜99.999%(場合により“ゼロダウン”要求)

• 背景:
― ピーク時に1時間あたり400~500万コールが集中(例:GIレース)
― 1分間の停止が売上・信用に直結、リアルタイム決済・払戻もある

• 対策:
― リアルタイムデータ処理+高負荷対応のアーキテクチャ(マルチリージョン、CDN、分散DB)
― 負荷分散・自動拡張(オートスケール)・無停止バッチ
― テスト環境も本番並みに構築し、障害対応訓練も高頻度で実施

可用性要件とシステム構成の実態

ここで一度、これまでのポイントを整理しておきましょう。

・社会インフラ性が高い業務ほど可用性は「99.99%以上」が求められる傾向にある
・ただし「夜間の停止が許容されるかどうか」など、止まっても支障がない時間帯の有無で必要な可用性は大きく変わる
・可用性を高めるほど、設計・運用・人材にかかるコストが飛躍的に増加する

このように可用性が変われば、システム構成もまったく異なります。たとえば99.0%であれば単一の物理サーバで手動復旧でも構いませんが、99.95%以上になると、冗長化、自動切替、異地バックアップ、24時間体制のオペレーションなど、構成・体制ともに別次元になります。

加えて、インフラだけでなくアプリケーション側でも工夫が必要になります。トランザクションの整合性担保、障害時の再送設計、セッション管理やキャッシュ設計まで含めて「全体で可用性を設計する」という視点が求められます。

判断軸としての「業務影響額」

可用性の“正解”は、最終的には「業務に与える影響を金額でどう見積もるか」に尽きます。たとえば、「システムが1時間止まると100万円の損失が出る」と明確に言えるのであれば、その損失回避のために高可用性へ投資する合理性が見えてきます。

一方で、「止まってもFAXで代替できる」「翌日対応でも問題ない」といった業務であれば、過剰な可用性の追求は単なるコストの無駄になります。この判断を数値として見積もり、関係者全員で合意しておくことが、可用性設計の出発点です。

象徴的な例として、「金融」と「ギャンブル」には共通点があります。どちらも「リアルタイム性」「高頻度な取引」「金銭の直接的な関与」という要素を持ち、ほんの一瞬の停止が致命傷となり得ます。

  • 金融
     送金処理が止まれば → 利用者の生活資金が凍結され、場合によっては法的責任に発展
     ATMが使えなくなれば → 社会的信用が低下し、SNSなどでの炎上リスクも

  • ギャンブル(例:競馬、toto)
     投票受付が一時停止すれば → 数億円単位の売上機会が一瞬で失われる
     払戻ミスが発生すれば → 不正疑惑が噴出し、信用の回復が極めて困難に

このように、業務影響額を的確に見積もることで、どこまで可用性に投資すべきかが自ずと明確になります。

経営者・情報システム部門が共有すべき視点

可用性の議論は、技術部門だけの問題ではありません。どこまでの可用性を業務として求めるのか──その判断は、経営層が明確に示すべき領域です。そして、その要件に基づいて情報システム部門やベンダーが構成・運用を設計していく。これが本来あるべきプロセスです。

このとき、可用性を検討するための判断軸として、以下の3点をフレームワークとして共有しておくことが重要です。

  1. 業務の中に「絶対に止められない時間帯」はあるか?

  2. 停止によって生じる金銭的・非金銭的な損失はどれくらいか?

  3. その損失を回避するために、どこまでの投資が合理的か?

ここで、先述の3業種──金融・公営ギャンブル・行政──を改めて振り返ってみましょう。

  • 金融機関:社会インフラとして、信頼性と継続性が強く求められる

  • 公営ギャンブル:一瞬の停止が直接的な損失に直結するため、極めて高いリアルタイム性が求められる

  • 行政(例:住民票、年金):高可用性は求められるが、夜間や休日など“止めてよい時間帯”が存在する

このように、可用性の設計は「業務の重要度 × 時間的な制約 × 社会的責任」の三要素を軸に判断すべきです。「高ければ良い」のではなく、「業務にとって適切かどうか」が問われる時代になっています。

つまり、可用性は単なる技術的な選択肢ではありません。企業の信頼性を支える基盤であり、その水準は企業価値そのものに直結します。一度失われた信頼を取り戻すには、年単位の時間がかかることもあれば、場合によっては回復が不可能になることもあるのです。

おわりに

「可用性は99.9%で十分」──この考え方は、多くの業務において確かに妥当なラインとして受け入れられるかもしれません。
しかし、これを“思考停止の免罪符”として扱ってしまうと、ビジネスにとって致命的なリスクを見落とすことになりかねません。

可用性の設計は、単なる技術的な判断ではなく、「業務に与えるインパクト」と「その回避にかけるコスト」とのバランスを見極める、れっきとした経営判断です。数字だけを追うのではなく、“どれだけ止まると本当に困るのか”という業務視点から設計すべきものです。

誤った可用性設計は、過剰投資によるコストの無駄遣いにも、逆にリスク放置による信用失墜にもつながります。

だからこそ、最初にすべきは「業務として、どこまで止めることが許容されるか」を正確に見積もることです。そこから逆算して、“必要十分な可用性”を見極めることが、IT戦略としても経営としても、最も合理的なアプローチなのです。

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

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

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