バックアップの保守費用｜取得と復旧テストは別の費用として見積書を読む

バックアップの保守費用が見積書でどう書かれているかを確かめると、たいてい「バックアップ　月額◯円」の1行で終わっています。金額そのものは大きくありません。ただ、この1行が何を約束しているのかが、その1行からは分かりません。データは取れているらしい。では、事故が起きた日に、この1行のおかげで業務は戻るのでしょうか。

この記事は、その1行を分けるための手順書です。値下げ交渉の話はしません。バックアップの費用は「取得」「復旧テスト」「実際の復元」という性質の違う3つに分かれ、月額へまとめて成立するのは基本的に1つ目だけであるという前提から、手元の見積書をどう読み直すかだけを扱います。3つ目の「復元」は、誤操作から戻す場合と、事故から戻す場合で扱いが分かれます。

TL;DR｜「バックアップ　月額◯円」は3つの別の商品をまとめた1行

• 取得・復旧テスト・復元は別の作業です。 取得（毎日データを退避する）は自動化された処理で、量が読めるため月額へ載せられます。復旧テスト（実際に戻せるかを試す）は人が計画して動かす作業で、回数を決めないと値段が決まりません。実際の復元（事故や誤操作からデータを戻す）は、事後にしか量が決まりません
• なお本記事では、クラウドの機能として自動実行されるものを「復元テスト」、人が計画して実施するものを「復旧テスト」と書き分けます。 事業者によって呼び方が違うため、見積書では言葉ではなく作業の中身で確認してください
• 費用を決めているのは容量ではなく「いつの時点まで、いつまでに戻すか」です。 内閣府の事業継続ガイドラインは、どれくらいの期間のデータ損失を許容するかを先に決め、それに基づいてバックアップの取得頻度を決めるよう書いています。この順番が逆になっている見積書は金額の根拠を説明できない状態にある、というのが本記事の見方です
• 「取れている」と「戻せる」は別で、「戻せる」と「業務が再開できる」もまた別です。 IPAの非機能要求グレード2018は、目標復旧地点（RPO）の備考で、目標復旧レベルによって業務の復旧までを指定している場合について「業務再開の整合性の確認は別途必要となる」と書いています。ここが誰の作業なのかを決めないまま契約すると、事故の当日に決めることになります
• クラウドの公式料金でも、取得と復元テストは別の課金項目です。 AWS Backupは「復元テストの評価」をバックアップまたはリカバリポイントごとに課金しています（東京リージョン 1.80 USD／2026年8月21日取得）。ただしこれは自動の復元処理に対する課金で、業務が再開できるかを人が確かめる工数は含みません
• 「安い」ほうが危険なことがあります。 復旧テストは、削っても平時には何も起きません。影響は事故が起きた日にだけ現れます。見積書を金額だけで比べると、テストを削った会社が安く見えます
• 判断は「高い／安い」ではなく、説明済み／要確認／高リスク／判断不能の4状態で持ってください。 バックアップの保守費に公的な相場はありません。この記事でも「月額◯円が妥当」という数字は出さず、公開されている料金表から、価格が何で決まっているのか（保存容量・保護対象の台数や容量・リカバリポイント数・作業時間）を取り出します

保守費全体を実費・人の作業・システムの作業・待機の4区分へ分解する手順は、保守見積書を4区分へ分解する手順にまとめています。この記事は、そのうち「バックアップ」と名前のついた行だけを扱います。

見積書ではどう書かれているか｜1行から決まらないこと

手元の見積書に並ぶ書かれ方は、だいたい次のどれかです。左の書き方から右の情報は決まりません。

いちばん下の「記載なし」は、意外に多い状態です。保守契約の約款では、データの管理は顧客側の責任と書かれていることがあり、「保守契約の範囲を4状態で判定する手順」では、公開されている複数の保守約款が、顧客のデータや動作環境の復旧までは保証しないと定めている例を扱っています。誰がバックアップを取る責任を負っているのかが、契約上は自明でない場合があります。

「バックアップ込み」が指しうる4つの範囲

ベンダーが「バックアップは含まれています」と答えたとき、その言葉が指しうる範囲は次の4つです。どれを指しているかで、事故が起きた日にあなたの会社がやることが変わります。

多くの見積書は①か②を指して「バックアップ込み」と書いています。③と④が入っているなら、その分の作業量が金額のどこかに現れているはずです。月額が小さいのに④まで含むと書かれている場合は、書き方と金額のどちらかが実態と合っていない可能性があります。

そして、復旧テストはこの4段のどこにも現れません。 取得（②）とも復元（③）とも別の、事故が起きる前に前倒しで行う作業だからです。だから見積書では別行になります。これは後述するIPAの項目一覧が、取得の設計と復旧の訓練を中項目の段階から別の場所に置いているのと同じ構造です。

取得の設計値は5つ｜頻度・世代数・保管場所・保存期間・対象範囲

「取得まで」を買っている場合でも、その中身は5つの設計値で決まります。見積書に頻度しか書かれていないことが多いのですが、残りが抜けると、取得していても戻れない状態が起こります。この5つは本記事による整理で、公的な基準ではありません。

世代数が効くのは、壊れた状態を正常だと思って取得してしまう場合です。IPAの非機能要求グレード2018は、バックアップ利用範囲という指標のレベル2（ユーザエラーからの回復）の備考で、次のように書いています。

ユーザエラーからの回復の場合、システムとしては正常に完了してしまった処理を元に戻さなければならないため、複数世代のバックアップの管理や時間指定回復（Point in Time Recovery）等の機能が必要となる場合が考えられる。

「正常に完了してしまった処理」を元に戻すには、複数世代の管理か、時間指定回復（PITR）のような仕組みが要ります。 どちらも無い運用では、誤更新やランサムウェアのように「壊れた状態が正常な処理として記録される」事象に対応しにくくなります。

保管場所については、内閣府 防災担当の「事業継続ガイドライン」（令和5年3月）が、重要な情報についてはバックアップを確保し、同じ発生事象（インシデント）で同時に被災しない場所に保存することが必要であると書いています。本番と同じ基盤にしか置かれていないバックアップは、この条件を満たしません。

5つ目の対象範囲について、IPAの非機能要求グレード2018は、データ復旧範囲の備考で次のように書いています。

システムを障害から復旧するためには、データバックアップ以外に、OSやアプリケーションの設定ファイル等を保管するシステムバックアップも必要となることが考えられる。システムバックアップの取得方法や保管方法についても、同時に検討すべきである。

業務データだけを戻しても、動かす環境が再現できなければ業務は再開しません。見積書の「バックアップ」が業務データだけを指しているのか、環境の構成情報まで含むのかは、確認する価値があります。

費用を決めているのは容量ではなく「いつの時点まで、いつまでに戻すか」

バックアップの見積もりを容量で議論すると、話が噛み合わなくなります。容量が決めているのは保管料だけで、作業量を決めているのは別の変数だからです。

その変数が、RPOとRTOと呼ばれる2つの目標値です。技術用語ですが、意味は経営の言葉に置き換えられます。

RPO＝何時間分の業務が失われるか

前掲の内閣府 防災担当「事業継続ガイドライン－あらゆる危機的事象を乗り越えるための戦略と対応－」（令和5年3月）は、脚注でRPOを次のように定義しています。

失ったデータを過去のどの時点まで復旧させるか（例えば、１週間前のデータまで、１日前のデータまでなど）の目標値を、目標復旧時点（Recovery Point Objective、RPO）と呼ぶ。データは直近まで復旧させるのがもちろん望ましいが、相応して対策費用が高くなる場合が多い。

同ガイドラインの本文は、この順番を明示しています。

なお、情報のバックアップについては、平常時に使用している情報データが失われた場合に、どれくらいの期間のデータ損失を許容するかを慎重に検討して決定し、それに基づいてバックアップの取得頻度を決定することが重要である。

つまり先に決めるのは「何時間分の入力をやり直せるか」であって、頻度や容量はその結果です。前日夜のバックアップまでしか戻せないなら、事故が昼に起きたとき、その日の午前中に入力した受注・出荷・入金の記録は消えます。それを手で入れ直す人数と時間が、RPOの実際の値段です。

RTO＝何時間止まっても事業が持つか

同じガイドラインは、RTOとRLOを次のように定義しています。

さらに、この重要な事業に必要な各業務（重要業務）について、どれくらいの時間で復旧させるかを「目標復旧時間」（Recovery Time Objective、RTO）として、どの水準まで復旧させるかを「目標復旧レベル」(Recovery Level Objective、RLO)として決定し、また、重要業務間に優先順位を付ける。

そして、この記事の主題に直結する一文が続きます。

ただし、この段階における目標復旧時間及び目標復旧レベルは、実現性が未検証であるため、あくまで「案」にとどまる。

検証していない復旧時間は「案」である、と公的なガイドラインが書いています。見積書や提案書に「復旧目標2時間」と書かれていても、それを試したことがなければ、その2時間は案の段階にとどまっています。案を確定させる作業が復旧テストであり、その作業には費用がかかります。

なお、このガイドラインは地震・水害・システム障害などの危機的事象に対する事業継続マネジメント（BCM）を扱う文書で、日常の保守契約そのものを規定した資料ではありません。用語の定義と考え方の順番を借りるために引用しています。

公的な項目一覧では、取得の設計と復旧の訓練は別の場所にある

独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センターが公開している「非機能要求グレード2018 システム基盤の非機能要求に関する項目一覧」（2018年4月発行）を見ると、この分かれ方が項目の置き方として設計されていることが確認できます。

可用性の大項目には、目標復旧水準（業務停止時）という小項目のもとに3つの指標が並んでいます。

注目したいのは、RPOのレベル1〜3が、取得頻度そのもので説明されていることです（レベル0は「復旧不要」で、頻度の記載はありません）。週次バックアップならレベル1（5営業日前の時点まで）、日次バックアップならレベル2（1営業日前の時点まで）。頻度を下げることは、失われる業務時間を増やすことと同義だと、項目一覧の側が書いています。

そして、A.1.3.1の備考には次の一文があります。

RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務再開の整合性の確認は別途必要となる。

さらにA.1.3.3の備考（レベル0の説明）は、こう書いています。

システムの復旧は、ハードウェアの復旧だけでなくデータのリストアまでを対象とする。

目標復旧レベルで業務の復旧までを指定した場合でも、対象になるのはそのデータの復旧までで、業務再開の整合性の確認は「別途」。 これが、見積書の1行が①〜④のどこまでを買っているのかを聞くべき理由です。

運用・保守性の側を見ると、中項目「通常運用」の下にある小項目「バックアップ」に7つの指標（C.1.2.1〜C.1.2.7）が並んでいますが、その7つに復旧テストに相当する指標はありません。 障害発生時の復旧作業に関する訓練は、別の中項目「サポート体制」の下にある小項目「オペレーション訓練」（C.5.8.1〜C.5.8.3）に置かれており、そのうち「オペレーション訓練範囲」のレベル3が「通常運用、保守運用に加えて、障害発生時の復旧作業に関する訓練を実施」となっています。

取得の設計と、復旧の訓練は、公的な項目一覧では中項目の段階から別の場所にあります。 見積書で別々に値段が付いていることは、不自然でも水増しでもありません。付いていないほうが、確認すべき状態です。

この資料は受発注者間で非機能要求を合意するためのツール群です。付属の利用ガイド［解説編］は、レベルについて「あくまでも合意形成の出発点であって、ある程度の幅を持たせている。最終的にはユーザ/ベンダ間で具体的な数値として合意する必要がある」と書いています。自社がどのレベルを選ぶべきかを示す資料ではありません。

RPO・RTOを業務の言葉へ翻訳する

技術者以外が判断できるように、2つの目標値を業務の言葉へ置き換えると次のようになります。この表は本記事による整理で、公的な基準ではありません。

この表を先に埋めてからベンダーへ聞くと、話が早く終わります。 逆に、ここが空欄のままだと、ベンダーが提示した数字が高いのか安いのかを判断する基準を、発注側が持てません。

取得は自動で安く、復旧テストは人手で高い｜公式料金で確かめる

「取得は安く、テストは高い」という言い方は感覚的に聞こえますが、公開されている料金を見ると、課金単位そのものが違うことが分かります。以下はすべて2026年8月21日時点の公開情報です。

クラウド3社の課金単位を同じ軸へそろえる

USD建てで、日本の消費税は含みません。

3社に共通しているのは、保管と復元が別建てで規定されていることです（Azureのように、Standardレベルからの復元を無料と定める形も含みます）。「バックアップ費用」という単一の金額はクラウド側にも存在しません。手元の見積書に単一の金額しか書かれていないなら、ベンダーが内部で足し込んだ結果を見ていることになります。何を足したのかを聞く根拠は、ここにあります。

AWSは「復元テスト」を単独の課金項目として持っている

AWS Backupの料金ページは、復元テストの課金を次のように説明しています。

復元テストの評価料金は、復元テストプランを通じて復元のためにオーケストレーションできたバックアップポイントまたはリカバリポイントごとに発生します。

つまりテストした復旧ポイントの個数で課金されます。同ページの計算例では、米国東部（バージニア北部）で10個のEBSスナップショット（各64GB）と15個のEFSリカバリポイント（各50GB、ウォームストレージから）を復元した場合、評価料の合計が37.50 USD（1リカバリポイントあたり1.50 USD）、これに復元テスト用ストレージ15 USDが加わって合計52.50 USDと示されています。東京リージョンの評価料の単価は1.80 USDです。

1リカバリポイントあたり1.80 USDで買えるのは、リソースを復元できるかの確認までです。 金額が小さいのは、標準で自動化されるのがそこまでだからでもあります。

日本語の公開料金表でも、取得と戻す作業は別建てになっている

同じ分かれ方は、日本語で公開されている保守サービスの料金表でも確認できます。いずれも各社が公開している定価であって、業界の相場ではありません。

株式会社シーズの「シーズホスティングサービス」が公開している「サーバーオプションサービス料金表」（表示価格は税抜と明記）では、バックアップ関連のオプションが保管容量と対象台数で価格化されています。専用バックアップサーバーはRAID1 1TBが月額¥27,500（同表には「最低利用期間6ヶ月未満の場合、初期費用を別途いただいております」と注記）、イメージバックアップ（サーバータイプ・標準）は200GB／1台までが初期¥16,500・月額¥16,500、3.2TB／8台までが初期¥55,000・月額¥55,000です。このオプション料金表の範囲では、リストアや復旧テストの項目はありません。 同社のマネージドサービス（運用保守）側の料金表は本記事では確認していないため、同社が戻す作業を提供していないという意味ではありません。ここで言えるのは、バックアップのオプションとして値段が付いているのは保管の仕組みのほうだということです。

一方、株式会社ハイパーボックスが公開している「MSP(監視・保守・運用)サービス料金表」（同ページのセクション見出しは「MSP BOX [監視・保守・運用]」。表示価格は税別と明記）では、戻す作業が別オプションとして値段を持っています。

リストアは、監視・一次対応のパッケージには入っておらず、追加オプションとして値段が付いています。 これは隠された追加費用ではなく、作業の性質が違うことが価格表の構成に現れている、ということです。同ページには「負荷テスト（WEB・DB）¥50,000〜」というテスト項目や「その他作業代行 ¥5,000/人・時間」という時間単価も公開されていますが、リストアテストや復旧テストという項目はありません。回数と範囲が決まらないと値段が決まらない作業は、定価として公開しにくいと考えられます。 だからこそ、見積書に金額が入っているなら回数と範囲が書かれているはずで、書かれていないなら聞く必要がある、という順番になります。

それでも自動の復元テストが見ているのは「戻せるか」まで

AWSの開発者ガイドは、復元テストを「復元の実行可能性の自動的かつ定期的な評価と、復元ジョブの所要時間をモニタリングする機能」と説明しています（2026年8月21日取得）。復元後の検証を足すこともできますが、同ガイドの「復元テストの検証」は、Lambda等を使って検証ワークフローを設定できると書いており、何をどう検証するかのコードは利用者が用意します。 業務データの検算や、担当者が実際に業務を回してみる工程が、既定で付いてくるわけではありません。自動で担保できるのは「データのリストアまで」で、「業務再開の整合性の確認」は別途 ——前掲のIPAの備考のとおりです。

内閣府のガイドラインも、代替設備・手段から平常運用へ切り替える際に「データの欠落や不整合による障害を防ぐための復帰計画も必要である」とし、その内容の例として、受注売上システムのバックアップシステムを稼動させた場合に経理システムとの整合性をとること、手作業で事務処理を行った場合に情報システム復旧後もすぐに入力処理は行わず、手作業で行った処理がシステムへ反映されたことを確認することを挙げています。この確認は自動化されません。

だから見積書では、次の2つを分けて確認する価値があります。

• クラウドの機能として自動で回る復元テスト：単価が小さく、実費に近い性質を持つ。月額へ含めやすい
• 人が計画して実施する復旧テスト：回数と範囲で費用が決まる。年◯回という形でしか値段が決まらない

見積書に「復旧テスト実施」とだけ書かれているとき、それが前者を指しているのか後者を指しているのかで、買っているものがまったく違います。

実際に費用を生む作業は何か｜復旧テストの中身を6つに割る

人が実施する復旧テストで、実際に工数が発生するのは次の6つです。この分け方は本記事による整理で、公的な基準や価格の根拠ではありません。見積書の「復旧テスト　一式」を分解するための枠として使ってください。

1・2・3はベンダー側の作業として見積書に現れやすく、4・5・6は誰の作業か曖昧なまま残りがちです。 とくに5は、発注側の業務部門が時間を使う作業です。ベンダーの見積書に金額が現れないため「無料」に見えますが、自社の人件費として発生します。年1回の実施でも、参加する部門と時間を先に決めておかないと、当日に人が集まらず流会になります。

初回にいちばん工数がかかるのは1で、2回目以降は作った計画を回す作業になります。見積書に初回と2回目以降で同じ金額が並んでいるなら、そこは説明を求めてよい箇所です。

「戻せた」と「業務が再開できた」の間にあるもの

4と5が飛ばされやすいのは、3で終わったように見えるからです。実際には、次のようなことが3と5の間で起きます。

• 戻したデータと、外部サービス側に残っている状態が食い違う（決済、在庫、配送のステータス）
• 障害中に手作業で処理した分が、システムへ二重に入る
• 復元後のシステムから出ていく自動送信（メール、EDI、Webhook）が、過去分をもう一度送ってしまう
• 権限やアカウント設定が古い時点に戻り、担当者がログインできない

前掲の内閣府ガイドラインが「復帰計画」と呼んでいるのが、この確認の手順です。復旧テストの費用のうち、金額に対して効果がいちばん大きいのは、この手順を1回作る部分です。

この料金体系が合理的なケース

ここまで確認の話を続けてきましたが、バックアップの費用が1行にまとまっていること自体は、正当な場合があります。次の条件を満たしているなら、その見積書は説明可能な状態にあります。

確認すべきなのは、作業費まで容量に比例していないかのほうです。100GBを戻すのと1TBを戻すのでは復元時間は変わりますが、テストの計画・整合性確認・業務再開確認の工数は、容量ではなく対象業務の数で決まります。ここが容量に比例している見積書は、根拠を聞く価値があります。

確認が必要なケース｜4状態で切り分ける

「高い・安い」ではなく、次の4状態で判定します。この枠組みはシステム保守費用の相場と妥当性と共通です。

項目ごとに当てはめると、次のようになります。

太字の行は、金額の大小と無関係に優先度が高い項目です。復旧目標だけが契約され、それを検証する費用がどこにも計上されていない状態は、前掲の内閣府ガイドラインの言い方を借りれば「実現性が未検証」の案が契約書に載っている状態です。

「安い」保守見積もりのほうが危険なケース

保守見積もりを金額だけで比較すると、範囲を削った会社が安く見えます。バックアップまわりで削られやすいのは次の順です。

1. 復旧テスト（削っても平時に何も起きない）
2. 世代数と保存期間（減らすと、壊れた状態で上書きされたときに戻れる時点が残らない）
3. 保管場所の分離（本番と同じ基盤に置けば安くなるが、同時に失われる）
4. 月次の実施報告（報告がないと、実施されたかを検証する手段がなくなる）

1と3は、ランサムウェア被害の文脈でとくに効きます。セキュリティ保守費用の内訳では、事故が起きたときの復旧費用と復旧期間について公的統計を扱っています。平時のコストを最小にした見積書は、事故時の金額を発注側が制御できない状態と表裏です。

見積書の比較シート｜同じ月額でも中身は変わる

複数社の見積もりを比べる前に、次のシートを埋めてください。金額の欄より先に、範囲の欄が埋まらないと比較になりません。

以下は実在の見積書ではなく、範囲の組み合わせを示すための説明用の型です（金額を挙げる場合も説明用の仮の数字です）。同じ「バックアップ　月額3万円」を提示されていても、この表の埋まり方で買っているものは変わります。

3つの型のどれが正解ということはありません。 決めるのは、前掲のRPO・RTOの翻訳表です。1日分の入力をやり直せる業務なら業務再開型でも足りますし、当日分の受注を失えない業務なら足りません。先に業務側の許容値を決め、それに合う範囲を買うという順番になります。

埋め終わったときに、範囲の欄に空欄が残っていないことが目標です。分割の依頼と確認質問をまとめて送りたい場合は、保守見積書の無料診断（登録不要）に手元の見積書の内容を入力すると、対応範囲・対応時間・作業の扱いについて確認事項が整理されます。結果を見るまでメールアドレスの入力も不要です。

ベンダーへそのまま送れる確認質問8問

以下をそのままコピーして送れます。宛先と対象システム名だけ書き換えてください。質問1〜2が【取得】の設計値と対象範囲、質問3〜4が【復旧テスト】の有無と費用、質問5〜7が【復元】の扱いと責任分担、質問8が【取得】が実際に効いているかの確認に対応します。 返ってきた回答は、そのまま前掲の比較シートへ書き写せます。

そのまま送れるメール文面

◯◯株式会社 ご担当者様

いつもお世話になっております。 現在ご提示いただいている保守見積書について、社内で費用の内訳を確認しております。 「バックアップ」に含まれる作業を整理したく、以下8点について書面でご回答いただけますでしょうか。 金額の交渉が目的ではなく、対応範囲を社内で正確に説明できるようにするための確認です。

1.【取得】設計値 バックアップの取得頻度、保管世代数、保管場所（本番環境と物理的・論理的に分離されているか）、保存期間を教えてください。

2.【取得】対象範囲 バックアップの対象に、業務データだけでなくOS・ミドルウェアの設定やアプリケーションの構成情報が含まれるかを教えてください。含まれない場合、障害から環境を再構築する手順と、その作業がどちらの担当になるかもあわせてお願いします。

3.【復旧テスト】有無と範囲 バックアップから実際に戻せることを確認する復旧テスト（リストアテスト）は、契約に含まれますか。含まれる場合、年間の実施回数と、テストの範囲（データの復元まで／他システムとの整合性確認まで／業務手順での再開確認まで）を教えてください。直近の実施日と、そのときの所要時間もあわせてお願いします。

4.【復旧テスト】費用の内訳 復旧テストが別料金の場合、1回あたりの費用と、その内訳（テスト計画の作成、戻す先の用意、復元の実施、整合性の確認、記録と是正）を教えてください。当社側の作業となる業務手順での再開確認は、この内訳から除いて構いません。初回と2回目以降で金額が変わるかもあわせてお願いします。

5.【復元】誤削除・誤更新からの復元 誤って削除・更新したデータの復元を依頼した場合、月額に含まれますか、別料金ですか。別料金の場合は単価と、月または年あたりの上限の有無を教えてください。

6.【復元】事故時の作業 実際に障害が発生してデータを戻す場合、作業は御社が実施されますか、当社が実施しますか。御社が実施される場合、対応時間帯、作業の単価または上限、超過時の扱いを教えてください。

7.【復元】業務再開の確認は誰の作業か データを戻したあと、他システムとの整合性の確認と、業務が実際に回ることの確認は、どちらの作業になりますか。当社側の作業となる場合、必要な手順書はご提供いただけますか。

8.【取得】実施の報告 バックアップの取得が成功しているかは、どのように確認・報告されますか。失敗した場合の連絡方法と、月次または定期の報告書に何が記載されるかを教えてください。

お忙しいところ恐れ入りますが、◯月◯日までにご回答いただけますと幸いです。 よろしくお願いいたします。

回答をどう読むか

返ってきた回答は、金額ではなく次の観点で読みます。

質問3と質問7が、この記事の中心です。 3で直近の実施日が出てこない場合、契約書に書かれた復旧目標はまだ検証されていない可能性があります。7が曖昧なまま契約すると、事故の当日に「誰が確認するのか」を決めることになります。

分解を依頼しても内訳が出てこない場合、それは価格の問題ではなく引き継ぎの問題として扱ってください。バックアップの設定内容と復元手順が発注側に開示されないと、保守会社を変える選択肢そのものが狭くなります。

回答が揃ったあとの選択肢

まず、この記事の翻訳表を使って、自社のRPOとRTOを業務の言葉で1行ずつ書いてください。「前日夜以降の入力はやり直せる／やり直せない」「2時間で受注を再開する必要がある／翌営業日でよい」の2つが決まれば、見積書のバックアップの行が足りているかどうかは、ほぼ判定できます。

そのうえで、回答は次の4つのどれかに落ち着きます。

要確認の段階でいきなり相見積もりへ進まないでください。 範囲が揃っていない見積書を他社へ渡しても、比較のしようがない見積もりが1枚増えるだけです。まず現行ベンダーへ内訳の分解を依頼するほうが、切り替えコストをかけずに検証できます。

バックアップ以外の行も同じ手順で分けたい場合は、次が近道です。

• 月額の総額しか書かれていない → 保守見積書を4区分へ分解する手順
• 「これは保守に含まれるのか」で揉めている → 保守契約の範囲を4状態で判定する手順
• 金額そのものが妥当か知りたい → システム保守費用の相場と妥当性

手元の見積書をその場で分けたい場合は、前掲の保守見積書の無料診断（登録不要）が使えます。

根拠資料と適用条件

本記事で使った資料と、その適用範囲です。数値ごとに性格が違うため、まとめて扱わないでください。金額はすべて2026年8月21日時点の公開情報で、税区分は各社の表記に従っています。

バックアップの保守費の「相場」は、本記事では示していません。 公的機関が公表しているバックアップ保守費の相場データを確認できなかったためです。開発費に対する保守費の比率（いわゆる15〜20%）も業界慣習値であって公的な相場ではなく、この点はシステム保守費用の相場と妥当性で扱っています。

また、「リストアテスト」「復旧テスト」を価格つきのメニュー項目として公開している運用保守サービスは、本記事の調査範囲では確認できませんでした。 存在しないという意味ではなく、確認できなかったという意味です。

よくある質問