「業務が止まると困るので、止まらない構成にしてほしい」。基幹システムのリプレイスを任された担当者が、経営層や事業部門からよく受け取る要望です。ところがベンダーから提案書が届くと、そこには「ホットスタンバイ構成」と「コールドスタンバイでの代替案」が併記され、価格に大きな差がついています。どちらを選べばよいのか、そしてその差額に見合う価値があるのかを、自分の言葉で説明できずに手が止まってしまう。これは珍しいことではありません。
用語そのものを調べても、この悩みはなかなか解消しません。多くの解説は「ホットスタンバイは予備機を常に動かしておく方式」「コールドスタンバイは予備機を止めておく方式」という定義で終わり、費用がなぜ違うのか、自社はどちらを選ぶべきかまでは踏み込んでいないからです。稟議で問われるのは定義ではなく、「なぜその金額が必要なのか」「安いほうを選ぶと何が起きるのか」という判断の根拠です。
この判断は、実は「どちらが優れているか」ではなく「どれだけ止まってよいか」と「どれだけデータを失ってよいか」から逆算すると整理できます。停止許容時間（RTO）とデータ損失許容量（RPO）という 2 つの数字を業務単位で決めれば、方式は自動的に絞り込まれます。そして費用は「常時動かしているものの量」に比例するため、内訳に分解すれば見積の妥当性も検証できるようになります。
本記事では、ホットスタンバイ・コールドスタンバイ・ウォームスタンバイの 3 方式の違いを 5 つの軸で比較したうえで、費用の内訳、RTO・RPO から方式を決める 4 つの判断ステップ、選定後につまずきやすい落とし穴、そして発注前にベンダーへ確認すべきチェックリストまでを順に整理します。読み終えたときに、社内稟議とベンダー折衝の両方で使える判断材料が手元に残る構成にしています。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
ホットスタンバイ・コールドスタンバイとは？障害対策における待機方式の基本
システムを止めないための考え方の土台にあるのが「冗長化」です。冗長化とは、同じ役割を果たせる設備をあらかじめ二重に用意しておき、片方が壊れてももう片方で業務を継続できるようにする設計を指します。サーバー本体、ストレージ、ネットワーク回線、電源など、あらゆる階層で行われます。
このとき論点になるのが、「予備の設備をどの状態で待たせておくか」です。常に電源を入れて本番と同じデータを持たせておくのか、それとも電源を切って倉庫に置いておくのか。この「温度差」を表す言葉が、ホットスタンバイ・ウォームスタンバイ・コールドスタンバイという 3 つの方式です。温度が高いほど切替は速くなり、そのぶん維持費が上がります。
3 方式は、次の 3 点で整理すると比較しやすくなります。この 3 点は、以降のすべての比較・費用分解の共通軸になります。
- 予備機の稼働状態: 電源が入っているか、アプリケーションまで起動しているか
- データ同期の有無と頻度: 本番のデータが常時複製されているか、定期バックアップのみか
- 切替の方法: 障害を検知して自動で切り替わるか、人が判断して手動で切り替えるか
ホットスタンバイとは？予備機を動かしたまま待機させる方式
ホットスタンバイとは、予備機（待機系）を本番機（現用系）とほぼ同じ構成で起動させたまま待機させ、本番機に障害が発生した瞬間に処理を引き継がせる方式です。データは常時複製されており、切替は監視ソフトウェアやクラスタソフトが自動で行うのが一般的です。切替にかかる時間は構成によりますが、数秒から数分程度に収まる設計が可能です。
ホットスタンバイには、大きく 2 つの構成パターンがあります。ひとつはアクティブ/スタンバイ構成で、待機系は起動しているものの実際の業務処理は行わず、切替が発生したときだけ本番として動き出します。もうひとつがアクティブ/アクティブ構成で、両系が常時業務処理を分担し、片方が停止しても残った側が全処理を引き受けます。
両者の違いは、平常時に待機系が仕事をしているかどうかです。アクティブ/アクティブ構成は平常時の処理能力も向上する一方、両系がデータを同時に更新するため整合性の設計が難しく、片系だけで全負荷を処理できる余力を持たせる必要があります。ベンダー提案書に「冗長化構成」とだけ書かれている場合、どちらを指しているかで費用も難易度も変わるため、必ず確認しておきたい点です。
コールドスタンバイとは？予備機を止めて待機させる方式
コールドスタンバイとは、予備機を停止した状態（あるいは機器だけ確保して未構築の状態）で待機させ、障害が起きてから起動・構成・データ復元を行って業務を再開する方式です。切替は原則として手動で、システムの規模にもよりますが、復旧までに数時間から数日を要します。
この方式で最も注意すべきなのは、障害発生時点の処理中データを引き継げないという点です。データはバックアップから復元するため、最後にバックアップを取得した時点以降の更新内容は失われます。1 日 1 回の夜間バックアップ運用であれば、最悪の場合その日の営業時間中に入力されたデータがすべて消えることになります。「復旧はできるが、その日の受注入力はやり直し」という状況が許容できるかどうかが分かれ目です。
一方で、構成がシンプルで維持費が抑えられるという明確な利点があります。待機系の電源が入っていないため電力・クラウド利用料がかからず、同期の仕組みも不要なので、設計・構築・運用のすべてが軽くなります。停止しても業務影響が限定的なシステムであれば、コールドスタンバイは合理的な選択です。
ウォームスタンバイという中間の選択肢
ホットとコールドの二択で悩んでいる場合、間にあるウォームスタンバイが最適解になることが少なくありません。ウォームスタンバイは、予備機の OS やミドルウェアまでは起動しておき、データも定期的または非同期で同期させておく方式です。切替は一部自動化されることもありますが、最終的な切替判断は人が行う構成が多く、復旧時間は数分から数時間程度になります。
ホットスタンバイほどの即時性は得られない代わりに、待機系を縮小構成で動かせるため費用を抑えられます。「数分の停止は許容できるが、当日のデータが消えるのは困る」という業務要件は実務上とても多く、この場合ウォームスタンバイが要件と費用の交点になります。ホットスタンバイの見積が予算を超えたときは、まずウォームスタンバイでの代替案を提示してもらう価値があります。
ホットスタンバイとコールドスタンバイの違いを5つの軸で比較する
3 方式の違いは、「切替時間（RTO）」「データ保全（RPO）」「費用」「運用負荷」「構成の複雑さ」の 5 軸で整理すると、そのまま社内説明の資料に転用できます。ここで重要なのは、ホットスタンバイが常に優れているわけではないという点です。切替時間を短くするほど、費用と運用負荷と構成の複雑さがすべて増えるという交換関係になっています。
比較表｜3方式の切替時間・データ保全・費用・運用負荷
比較軸 | ホットスタンバイ | ウォームスタンバイ | コールドスタンバイ |
|---|---|---|---|
予備機の状態 | 本番と同等構成で起動・稼働 | OS・ミドルウェアまで起動（縮小構成） | 停止、または機器のみ確保 |
データ同期 | 常時同期（同期／準同期レプリケーション） | 定期または非同期レプリケーション | バックアップからの復元 |
切替方法 | 自動フェイルオーバーが中心 | 一部自動＋手動判断 | 手動 |
切替時間の目安（RTO） | 数秒〜数分 | 数分〜数時間 | 数時間〜数日 |
データ損失の目安（RPO） | ほぼゼロ〜数秒 | 数分〜数時間 | 前回バックアップ時点（数時間〜1日） |
追加費用の目安（本番系を100とした場合） | 80〜100 | 30〜60 | 10〜30 |
運用負荷 | 高い（同期監視・定期的な切替訓練が必須） | 中（同期確認・手順書整備） | 低い（バックアップ運用が中心） |
構成の複雑さ | 高い | 中 | 低い |
上表の切替時間・データ損失・費用の数値は、一般的な構成における目安として示したものです。実際の値は、データ量、同期方式（同期／非同期）、拠点間の回線帯域、使用するミドルウェアやクラスタ製品によって大きく変動します。提案を受ける際は、この表の各行に対してベンダー側の想定値を書き込んでもらうと、方式名だけでは見えない差が可視化されます。
差が生まれる理由｜「常時動かしているもの」の量が費用と切替時間を決める
なぜこれほど差が出るのかを一言でまとめると、平常時に動かしているものの量が、そのまま費用と切替時間を決めているからです。
ホットスタンバイでは、待機系のサーバーが常時起動し、ストレージが本番と同じデータを保持し、両系の間でデータ複製が絶えず流れています。障害時に「起動する」「データを戻す」という作業が残っていないため切替が速い一方、その状態を 24 時間 365 日維持するための費用が発生し続けます。稼働している資源が多いほど、監視対象も増え、運用の手間も増えます。
コールドスタンバイはこの逆です。平常時にはほとんど何も動いていないので維持費は最小限ですが、障害が起きてから「機器を起動する」「OS とアプリケーションを構成する」「バックアップからデータを復元する」「動作確認する」という工程をすべて実施することになり、その所要時間が復旧時間になります。
したがって、方式の選定とは「これらの工程のうち、どこまでを平常時に前倒しで済ませておくか」を決める作業だと言い換えられます。前倒しする範囲が広いほど復旧は速くなり、費用は上がります。この理解があると、次に見る費用の内訳も納得しやすくなります。
切替方式ごとの費用感｜何にいくらかかるのかを分解する
「ホットスタンバイは高い」という説明だけでは稟議は通りません。何にいくらかかるのかを項目に分解して初めて、見積の妥当性を検証でき、削れる項目と削れない項目の判断ができるようになります。ここでは費用を初期費用とランニングコストに分け、見落とされやすい項目を含めて整理します。
初期費用の内訳｜設計・構築とリソース調達
初期費用は、大きく次の 3 つに分かれます。
- 設計費: 可用性要件の整理、切替シナリオの設計、データ同期方式の選定、切替手順書の作成。ホットスタンバイでは自動切替の判定条件や切戻し手順まで設計するため、この工程が最も膨らみます
- 構築費: 待機系サーバーやストレージの構築、クラスタソフトウェアの導入・設定、同期設定、監視設定、そして切替テストの実施。切替テストは工数が読みにくいため見積から漏れやすい項目です
- 機器・クラウドリソースの調達費: オンプレミスでは待機系のサーバー・ストレージ・ネットワーク機器。クラウドでは待機系インスタンスやレプリカ用のストレージ
- ソフトウェアライセンス費: OS、データベース、ミドルウェア、クラスタ製品、監視・バックアップ製品。待機系にも本番と同じライセンスが必要になるかどうかは製品ごとに条件が異なります
コールドスタンバイであれば設計・構築工数は大幅に軽くなりますが、その代わりに「復旧手順書の整備」と「復旧訓練」が必須になります。手順が整備されていないコールドスタンバイは、実質的に「復旧できるかどうか分からない状態」と変わりません。
ランニングコストの内訳｜待機系を維持し続ける費用
見積の比較でより差が開くのは、実はランニングコストのほうです。次の項目は、方式によって大きく増減します。
- 待機系の稼働費: クラウドではインスタンスの稼働料金とストレージ料金。オンプレミスでは電力・空調・ラック費用。ホットスタンバイでは本番系とほぼ同額が上乗せされます
- データ同期の通信費: 拠点間・リージョン間でデータを複製する際のネットワーク費用。更新量の多いシステムでは無視できない金額になります
- 保守契約費: 待機系の機器・ソフトウェアにも保守契約が必要です。台数が増えれば保守費もほぼ比例して増えます
- 運用工数: 同期状態の監視、アラート対応、待機系へのパッチ適用、構成変更の反映。待機系は「置いておけばよい」ものではなく、本番と同じ手入れが必要です
- 切替訓練の工数: 年 1 回でも実施すれば、計画・実施・検証・報告で相応の工数がかかります。この費用を見積に含めるかどうかで、総額の見え方は変わります
運用と保守にかかる工数の考え方をあらためて整理したい場合は、運用と保守の違いもあわせて確認しておくと、待機系の維持に必要な体制を見積もりやすくなります。保守費用そのものの相場観については、システム保守費用の相場で費目ごとの目安を整理しています。
クラウド前提での費用イメージとDR戦略4パターンとの対応
クラウド移行を伴うリプレイスでは、社内で使ってきた「ホット／コールド」という用語と、クラウドベンダーが使う用語が食い違い、話がかみ合わなくなることがあります。AWS の場合、ディザスタリカバリ（DR）の構成は「バックアップ＆リストア」「パイロットライト」「ウォームスタンバイ」「マルチサイト アクティブ/アクティブ」の 4 つに整理されており、低コストで単純なものから、複数リージョンを常時稼働させる複雑なものまで段階的に並んでいます（AWS ワークロードのディザスタリカバリ｜クラウド内での災害対策オプション）。
従来用語との対応関係は、おおむね次のように整理できます。
従来の呼び方 | AWS の DR 戦略 | 平常時に動かしているもの |
|---|---|---|
コールドスタンバイ | バックアップ＆リストア | データのバックアップのみ（環境は障害後に構築） |
コールド〜ウォームの中間 | パイロットライト | データは常時複製、中核以外のリソースは停止状態で待機 |
ウォームスタンバイ | ウォームスタンバイ | 縮小構成で常時稼働、切替後にスケールアウト |
ホットスタンバイ | マルチサイト アクティブ/アクティブ | 両系が本番トラフィックを処理 |
AWS の公式解説では、パイロットライトとウォームスタンバイはデータの複製方式が同じためデータ損失の水準（RPO）は同等であり、ウォームスタンバイのほうが縮小構成をそのまま拡張できるぶん復旧時間（RTO）が短くなると説明されています。またマルチサイト アクティブ/アクティブは復旧時間をほぼゼロに近づけられる一方で、最も複雑でコストのかかる方式と位置づけられています（AWS のディザスタリカバリアーキテクチャ Part III）。
クラウドの費用面での利点は、待機系を縮小構成で置いておき、必要なときだけ拡張できる点にあります。パイロットライトのようにデータ複製だけを常時行い、計算リソースは最小限にしておけば、ホットスタンバイに近いデータ保全水準を保ちながら費用を抑えられます。ベンダー提案が「ホットスタンバイ一択」になっている場合は、この中間案を検討したかを確認してみてください。
RTO・RPOから切替方式を決める4つの判断ステップ
ここまでで方式の違いと費用構造を整理しました。次は、自社がどれを選ぶべきかを決める手順です。ポイントは、方式から入らず、業務要件を数字にすることから始める点にあります。
ステップ1｜RTO・RPOを業務単位で言語化する
最初に決めるのは、次の 2 つの数字です。
- RTO（目標復旧時間）: 障害発生から業務を再開できるまでに許容できる時間。「何時間止まってよいか」
- RPO（目標復旧時点）: 障害によって失ってもよいデータの時間幅。「いつの時点まで戻ってよいか」
この 2 つは混同されがちですが、指しているものが異なります。RTO は時間の長さ、RPO は遡る時点です。たとえば「RTO 4 時間・RPO 1 時間」であれば、障害から 4 時間以内に業務を再開でき、失われるデータは直近 1 時間分までに収まる、という要件になります。RTO を短くするには待機系を温めておく必要があり、RPO を短くするにはデータ同期の頻度を上げる必要があるため、対策の打ち手も別々です。
事業継続の観点では、まず「これ以上止まると事業が立ち行かなくなる限界の時間」を把握し、そこから余裕を持たせて RTO を設定するのが基本的な考え方とされています。中小企業庁の中小企業BCP策定運用指針でも、事業の性質・顧客との契約条件・取引先との関係によって復旧目標は変わるものとして整理されています。BCP と DR の関係を先に押さえておきたい場合は、BCPとDRの違いを確認すると、可用性設計がどの計画の一部にあたるのかが整理できます。
現場から「止まらないでほしい」としか返ってこない場合は、質問の仕方を変えてみてください。「何時間止まってよいですか」ではなく、「1 時間止まったら何が起きますか」「半日止まったら何が起きますか」「1 日止まったら何が起きますか」と段階で聞くと、業務側は具体的な支障を答えやすくなり、そこから許容時間が見えてきます。
ステップ2｜停止1時間あたりの影響額を概算する
RTO・RPO を決めるうえで説得力を持たせるのが、停止による損失額の概算です。厳密な数字である必要はなく、桁が分かれば判断はできます。次の 4 項目を足し合わせると概算できます。
- 売上機会の損失: 1 時間あたりの売上 × 停止によって失われる割合（後から回復できる分は除く）
- 業務停止による人件費の損失: 停止によって作業できなくなる人数 × 平均時給 × 停止時間
- 復旧作業のコスト: 復旧対応にあたる社内・社外要員の工数、時間外対応費
- 信用・契約上の損失: 納期遅延による違約金、取引先対応、顧客対応にかかるコスト
この概算値と、方式ごとの追加費用を並べると、判断は一気に容易になります。停止 1 時間あたりの損失が数百万円規模なら、年間数百万円の追加投資でホットスタンバイを選ぶ判断は合理的です。逆に損失が数万円規模であれば、同じ投資は過剰と判断できます。稟議で問われる「なぜこの金額が必要か」に対して、この比較こそが最も直接的な回答になります。
ステップ3｜RTO・RPOのレンジから方式をマッピングする
数字が出たら、方式に当てはめます。おおまかな対応は次のとおりです。
RTO（停止許容時間） | RPO（データ損失許容） | 適した方式 |
|---|---|---|
数分以内 | ほぼゼロ | ホットスタンバイ（アクティブ/スタンバイ、またはアクティブ/アクティブ） |
数十分〜1時間 | 数分以内 | ウォームスタンバイ（クラウドではパイロットライト〜ウォームスタンバイ） |
半日〜1日 | 数時間 | コールドスタンバイ（バックアップからの復元） |
数日 | 1日 | 待機系を持たず、バックアップ運用のみ |
注意したいのは、RTO と RPO の要求水準が一致しないケースです。「復旧は半日かかってもよいが、データは 1 件も失えない」という要件はよくあります。この場合、待機系は温めずにデータ複製だけを常時行う構成、つまりパイロットライトに近い形が適します。RTO と RPO を分けて考えることで、こうした中間解にたどり着けます。
ステップ4｜全社一律にせず重要業務から段階的に適用する
最後の落とし穴が、全システムに同じ方式を適用してしまうことです。受発注や生産指示のように止まると即座に事業が止まる業務と、社内の申請ワークフローのように翌日復旧でも支障が小さい業務では、必要な水準がまったく異なります。全社一律でホットスタンバイを適用すれば費用は跳ね上がり、逆に一律でコールドスタンバイにすれば重要業務でリスクを抱えることになります。
現実的な進め方は、業務を「止まると即座に事業が止まるもの」「半日以内に復旧すればよいもの」「翌営業日でよいもの」の 3 段階に分類し、最上位の業務にだけ手厚い方式を適用することです。段階導入であれば初期投資も分散でき、稟議も通しやすくなります。まずは最重要業務 1 つに絞ってホットスタンバイまたはウォームスタンバイを導入し、運用が安定してから対象を広げる進め方が、費用と運用負荷の両面で無理がありません。
切替方式の選定でつまずきやすい落とし穴と回避策
方式を決めた後に顕在化する問題があります。ここを見落とすと、「高い方式を選んだのに結局止まった」という最悪の結果になりかねません。発注前に確認しておきたい 4 つの論点を、症状・原因・回避策の順に整理します。
落とし穴1｜切替が動くことを一度も検証していない
症状: 障害が発生したのに待機系へ切り替わらない、あるいは切り替わった後にアプリケーションが正常に動かない。
原因: フェイルオーバーは「監視 → 障害判定 → 切替実行 → 業務再開」という複数の段階で成り立っています。監視ソフトがサーバーの応答やサービスの生死を定期的に確認し、あらかじめ決めた条件を満たしたときに障害と判定して、待機系を本番へ昇格させます。この連鎖のどこか一箇所でも設定が誤っていれば、切替は成立しません。よくあるのは、監視対象がサーバーの死活だけでアプリケーションの異常を検知できない、切替スクリプトが古い構成のままになっている、といったケースです。
もうひとつ検証で確認しておきたいのが、両系が同時に「自分が本番だ」と認識してしまう状態（スプリットブレイン）です。ネットワークの分断によって互いの生死を確認できなくなると、両系がそれぞれデータを更新してしまい、復旧後に整合性を取れなくなる恐れがあります。自動切替を採用する構成では、この状態を防ぐ仕組みが設計に含まれているかを必ず確認してください。
回避策: 構築時の一度きりではなく、定期的な切替テストを運用に組み込むことです。確認すべきは「切り替わったか」だけでなく、切替後に業務が最後まで通るか、そして本番系の復旧後に元へ戻す（切戻し）手順まで動くかどうかです。契約段階で「年 1 回の切替訓練を保守契約に含める」と明記しておくと、実施が形骸化しにくくなります。
落とし穴2｜待機系だけ構成が古くなる
症状: いざ切り替えたら、待機系のアプリケーションのバージョンが古く、本番データを読み込めない。設定ファイルの差分で外部連携が失敗する。
原因: 運用が始まると、パッチ適用や設定変更は本番系を優先して行われ、待機系への反映が後回しになります。この状態が積み重なると、両系の構成が少しずつ食い違っていきます（構成ドリフト）。担当者の交代が挟まると、そもそも待機系にどんな設定が入っているのかを誰も把握していない状態になりがちです。
回避策: 変更管理の手順に「待機系への反映」を必須工程として組み込み、構成情報をコード化して両系に同じ手順で適用する運用に寄せることが有効です。また、待機系の構成を棚卸しする機会を定期点検として確保しておくと、ドリフトの早期発見につながります。秋霜堂株式会社でも、前任者が不在でドキュメントも残っていない既存システムについて、初期調査から改善対応までを継続的に実施した実績がありますが、こうした案件では本来の改善作業に着手する前に初期調査の期間を確保する必要があります（出典: 秋霜堂の開発事例、アパレル品質管理システムの大規模改善）。待機系の情報が失われると、同じ工数が復旧の直前に発生することになります。
落とし穴3｜切替時間がRTOに収まらない
症状: 待機系への切替自体は数秒で完了したのに、利用者が使えるようになるまで 30 分以上かかった。
原因: 切替時間は、サーバーの切替時間だけでは決まりません。DNS で接続先を切り替える構成では、キャッシュの有効期間（TTL）が切れるまで利用者は旧系にアクセスし続けます。ログインセッションを本番系のメモリだけで保持していた場合、切替と同時に全利用者がログアウトされ、再ログインが必要になります。バッチ処理が途中で中断していれば、データの整合性を確認してから再実行する時間も必要です。
回避策: RTO は「サーバーが切り替わるまで」ではなく「業務が再開できるまで」で定義し、DNS の TTL 設定、セッション情報の外部保存、処理中データの扱いを設計段階で確認しておくことです。提案書に記載された切替時間がどの範囲を指しているのかは、必ず言葉で確認しておきたい点です。
落とし穴4｜待機系のライセンス・監視費が見積に入っていない
症状: 構築後になって、待機系のデータベースライセンスや監視エージェントの追加費用が判明し、想定していた総額を超えてしまう。
原因: ソフトウェアライセンスは、待機系の扱いが製品ごとに大きく異なります。たとえば Microsoft の SQL Server では、ソフトウェアアシュアランスを付与している場合にディザスタリカバリ用のパッシブインスタンスを追加ライセンスなしで利用できる特典が用意されていますが、これは対象製品・条件を満たす場合に限られます（ソフトウェア アシュアランス特典｜マイクロソフト ボリューム ライセンス）。逆に、待機系でも本番と同数のライセンスが必要になる製品もあります。監視ツールやバックアップ製品もサーバー台数で課金されるものが多く、台数増加がそのまま費用増加につながります。
回避策: 見積を受け取った時点で、待機系分のライセンスが含まれているか、含まれている場合は本数と条件、含まれていない場合は自社調達が必要かを製品ごとに確認することです。監視・バックアップ・資産管理といった周辺ツールも同じ観点で棚卸しすると、後からの追加費用を防げます。
発注前にベンダーへ確認すべきチェックリスト
ここまでの内容を、提案書を受け取ったときにそのまま使える形にまとめます。方式名だけを比べても判断はできません。次の項目に対する回答が揃って初めて、2 つの提案を同じ土俵で比較できるようになります。
見積・提案書で確認する8項目
- 方式の正確な名称と構成: ホットスタンバイなのかウォームスタンバイなのか。ホットスタンバイの場合はアクティブ/スタンバイか、アクティブ/アクティブか
- 想定 RTO・RPO の数値: 「業務が再開できるまで」で何分・何時間か。データ損失は最大どれくらいか
- 切替は自動か手動か: 自動の場合、何を検知して切り替えるのか。手動の場合、判断者と手順書は誰が用意するのか
- 切替訓練の扱い: 実施頻度、実施主体、費用が保守契約に含まれるか
- 待機系のライセンスと監視の扱い: 待機系分のソフトウェアライセンス・監視エージェントの費用が見積に含まれているか
- データ同期の方式と遅延: 同期・非同期のどちらか。非同期の場合の遅延時間の想定と、遅延が拡大したときの検知方法
- 年間ランニング総額: 待機系の稼働費・通信費・保守費・運用工数を含む年額。初期費用と分けて提示してもらう
- 保守契約・SLA との関係: 提示された稼働率が何を対象とした数値か。障害時の一次対応時間と復旧責任の範囲
これらは「答えにくい質問」ではなく、設計時に必ず決めているはずの事項です。回答が曖昧なまま進む提案は、後から追加費用や想定外の停止が発生しやすいと考えて差し支えありません。
稟議で聞かれる質問と回答の組み立て方
社内稟議で最も多く問われるのは、「なぜこの金額が必要なのか」です。ここで方式の説明から入ると話が技術論に流れてしまいます。順序を逆にして、「この業務は 1 時間止まると約 ◯ 万円の損失が出る」「経営として許容できる停止時間を 4 時間と定めた」「その水準を満たす方式は △ で、追加費用は年間 □ 万円」という順に組み立てると、投資判断として議論できます。
次に多いのが、「もっと安くできないのか」という問いです。これには、方式を落とすことで何が変わるのかを数字で答えます。「コールドスタンバイにすれば年間 □ 万円下がるが、復旧に半日かかり、当日入力分のデータは失われる」と示せば、判断の材料は揃います。安い案を選ぶこと自体は問題ではなく、失われるものを合意しないまま選ぶことが問題です。
三つ目は、「本当に切り替わるのか」という問いです。これに答えるためには、切替訓練の計画を提案段階から見積に含めておく必要があります。訓練費用を最初から総額に入れておけば、後から「訓練の予算が取れず一度も試していない」という状態を避けられます。
まとめ｜停止許容時間と費用のバランスで方式を決める
ホットスタンバイとコールドスタンバイの違いは、突き詰めれば「復旧のためにやるべき作業を、どこまで平常時に前倒しで済ませておくか」の差です。前倒しの範囲が広いホットスタンバイは切替が速く費用が高く、範囲が狭いコールドスタンバイは費用が安く復旧に時間がかかります。その中間にウォームスタンバイがあり、実務ではここが要件と費用の交点になることが少なくありません。
方式を決めるときの結論は 2 つです。ひとつは、方式ありきではなく RTO・RPO ありきで決めること。停止許容時間とデータ損失許容量を業務単位で数字にすれば、選ぶべき方式は自ずと絞られ、稟議でも投資判断として説明できます。もうひとつは、検証と訓練までを含めて費用と見なすこと。切替が動くことを確認できていない冗長化構成は、費用をかけた分の効果を得られません。
次に着手すべきことは明確です。自社の業務を洗い出し、それぞれについて「何時間止まってよいか」「いつの時点まで戻ってよいか」を書き出してみてください。この 2 列の表ができれば、ベンダーの提案が過剰なのか不足なのかを自分で判断できるようになり、上長への説明にもそのまま使えます。
システムの可用性設計や保守運用体制の整理にあたって、社内での検討材料をお探しの方は、お役立ち資料一覧もご覧ください。要件整理や発注準備に使える資料をまとめています。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- ホットスタンバイとウォームスタンバイ、どちらを選べばいいですか？
停止許容時間（RTO）が数分以内でデータ損失をほぼゼロにしたいならホットスタンバイ、数十分〜1時間の停止とデータ損失数分以内で足りるならウォームスタンバイが目安です。まずRTO・RPOを業務単位で数字にしてから選ぶと、判断が個人の感覚に左右されずに済みます。
- 中小企業でもホットスタンバイは必要ですか？
必須ではありません。全社一律ではなく、止まると即座に事業が止まる業務にだけホットスタンバイやウォームスタンバイを適用し、それ以外はコールドスタンバイやバックアップ運用に留める段階導入が費用面で現実的です。
- コールドスタンバイでも十分な業務の見極め方は？
半日〜1日程度の停止と、数時間分のデータ損失が許容できる業務であれば、コールドスタンバイで十分です。停止1時間あたりの損失額を概算し、方式ごとの追加費用と比較すれば、判断の根拠を上長にも説明しやすくなります。
- 見積の総額が想定より高い場合、まず何を確認すべきですか？
待機系のソフトウェアライセンスや監視エージェントの費用が見積に含まれているか、切替訓練の工数が過剰でないかをまず確認してください。それでも高い場合は、ウォームスタンバイやパイロットライトへ落とす代替案をベンダーに求めるのが有効です。
- 切替訓練は必ず実施しないといけませんか？費用を削れませんか？
切替が実際に動くか未検証のまま運用すると、障害時に切り替わらない恐れが残るため、省略は推奨しません。訓練費用は保守契約にあらかじめ含めておき、年1回など計画的に実施すると総額の見通しも立てやすくなります。
