LASSIC Media らしくメディア

2026.10.20 らしくコラム

サーバー保守費用の内訳と見積もりで確かめる5つのポイント

監修・編集責任者:牛尾 昭昌(株式会社LASSIC 執行役員)

サーバールームで扉を開けたラックの前に立ち、見積もりの紙を持って機器を指している

この記事の結論

  • サーバー保守の費用は、ハードウェア、ソフトウェア、パッチ、監視、バックアップ、一次対応に分けると比べやすくなります。
  • 金額は台数よりも、対応する時間帯や駆けつけまでの時間など、求める保守の水準で大きく変わります。
  • クラウドに移してもOSの更新とパッチ適用は利用者側に残るため、受け持つ人を決めておく必要があります。

※ 本記事は2026年10月時点の公式情報(省庁・公的機関、および製品やサービスを提供する事業者が公開している資料)に基づきます。

見積もりに「サーバー保守 一式」とだけ書かれていて、何が含まれているのか分からない。契約の更新のたびに保守料を示されるが、高いのか安いのか判断がつかない——。サーバー保守の費用では、こうした分かりにくさが起こりがちです。サーバー保守とは、サーバーが止まらずに動き続けるように、機器の故障への備え、OSやミドルウェアの更新、監視、バックアップなどを続けて行うことを指します。

費用は、この中のどれを、どの水準で頼むかによって大きく変わります。ただし金額だけを並べても答えは出にくく、まず内訳を分けて見ることが近道です。本記事では、情報システムの担当者に向けて、サーバー保守の費用の内訳、オンプレミスとクラウドでの違い、金額を左右する条件、そして見積もりで確かめたい5つのポイントを整理します。

サーバー保守とは

IPA(情報処理推進機構)の「非機能要求グレード」は、システムの土台に求める水準を項目ごとに決めるための資料で、その「運用・保守性」の区分には、ハードウェアとソフトウェアの保守契約、監視、パッチ(不具合や弱点を直す更新プログラム)の適用、バックアップからの復旧などが並んでいます。*1 サーバー保守の中身も、この区分に沿って4つに分けられます。

  • ハードウェアの保守:故障した部品の交換、保守員の駆けつけ、交換用の部品の確保
  • ソフトウェアの保守:OSやミドルウェア(データベースなど、OSとアプリの間で働くソフト)のサポート契約と、パッチの適用
  • 監視:サーバーが動いているか、エラーが出ていないか、CPUやディスクに余裕があるかを見張り、異常を知らせる
  • バックアップと復旧:データや設定を保存しておき、障害のときに元の状態へ戻す

障害のときに最初に連絡を受けて原因を切り分ける「一次対応」を誰が受け持つかも、保守の範囲に含めます。IPAの資料では、メンテナンス作業と一次対応のそれぞれを、利用者側がすべて行う・一部行う・保守会社に全部任せる、の段階から選ぶ形です。*1 見積もりの金額は、この分担によっても変わります。

費用の内訳と見方

サーバー保守の見積もりは、「一式」の1行ではなく、上の4つと一次対応に分けて出してもらうと比べやすくなります。次の表は、内訳ごとに金額を左右する条件を、非機能要求グレードの項目から拾って並べたものです。*1

保守員が引き出したサーバーからディスクを半分引き抜き、交換部品を帯電防止袋の上に置いている

サーバー保守費用の内訳と金額を左右する条件
内訳 主な中身 金額を左右する条件
ハードウェアの保守契約 部品の交換、保守員の駆けつけ 受け付ける時間帯、駆けつけまでの時間、交換部品の確保、予備機の有無
ソフトウェアの保守契約 OSやミドルウェアの問い合わせ窓口と修正の提供 製品ごとの契約か、複数社の製品をまとめて受ける契約か
パッチの適用 更新プログラムの情報提供、検証、適用 推奨分だけか全部か、当てる時期、事前に検証するか
監視 死活・エラー・リソース・性能の監視 何を見るか、どの間隔で見るか、離れた場所から見るか
バックアップと復旧 データと設定の保存、障害時の復元 どこまで戻すか、手作業か専用の製品を使うか
一次対応 障害の受付と切り分け 自社と保守会社のどちらが受け持つか、受け付ける時間帯

見落としやすいのは、ハードウェアとソフトウェアの保守契約の結び方です。製品ごとにその製品の会社と契約する形と、複数社の製品でできたシステム全体を1つの窓口でまとめて受けてもらう形があります。*1 どちらの形かで見積もりに含まれる範囲が変わるので、金額を比べる前にそろえておきます。

オンプレミスとクラウドの違い

オンプレミス(自社でサーバーを持つ形)とクラウドとでは、自社が受け持つ保守の部分が変わります。AWSの責任共有モデルは、ホストのOSや仮想化の仕組みから、施設の物理的なセキュリティまでをAWSが運用・管理すると説明しています。一方で利用者は、ゲストOS(借りたサーバーの上で動くOS)の更新とセキュリティパッチ、その上のアプリケーション、ファイアウォールの設定を受け持ちます。*2

オンプレミスとクラウド(IaaS)で保守を受け持つ側の違い
項目 オンプレミス クラウド(IaaS)
機器の故障と部品の交換 自社(保守契約で保守会社に任せる) クラウド事業者
施設の物理的な管理 自社またはデータセンター クラウド事業者
OSの更新とパッチ 自社(または保守会社) 自社(または保守会社)
アプリケーションと設定の管理 自社(または保守会社) 自社(または保守会社)
データの管理 自社 自社

つまりクラウドに移すと、ハードウェアの保守契約は要らなくなりますが、OSのパッチ適用は利用者側に残ります。*2 監視やバックアップの組み方も自社で決める必要があります。「クラウドにしたから保守はいらない」と考えて契約を外し、OSの更新が止まったままにならないよう、残る作業の担当を先に決めておきます。

金額が大きく変わる条件

同じ台数のサーバーでも、求める水準によって保守の体制は大きく変わります。非機能要求グレードは、保守員が駆けつけるまでの時間を、駆けつけ無し、数日中、翌営業日中、翌営業開始時まで、数時間内、常駐の段階に分けています。対応できる時間帯も、9時〜17時の定時内から24時間対応までの段階があります。*1 一般に、段階が上がるほど保守会社が人を待機させておく時間が長くなるため、見積もりの金額も高くなりがちです。

保守員が駆けつけるまでの水準を6段階で左から順に並べた図。駆けつけ無し、数日中、翌営業日中、翌営業開始時まで、数時間内、常駐の順に、待機する体制が厚くなる。

  • パッチの適用:推奨されるものだけか、すべてか。新しいパッチが出るたびに当てるか、定期保守のときにまとめて当てるか*1
  • 監視の間隔:1日1回の定期監視か、分単位のリアルタイム監視か
  • 保守部品の確保:交換部品をそのシステム専用に、決まった年数のあいだ確保しておくか
  • 使う年数:次の更改までの期間が製品の保守できる期間より長いと、保守の延長や版上げが別に必要になる*1

金額を下げたいときも、すべての水準を下げればよいわけではありません。IPAの資料は保守契約について、問題が起きたときの費用が大きくなるため「サポート契約を行ったほうが結果として運用コストは小さくなる場合がある」と書いています。*1 障害のときにかかる費用まで含めて、業務が止まってよい時間から水準を選ぶのが順序です。

見積もりで確かめる5つのポイント

サーバー保守を保守会社に頼むとき、また今の契約を見直すときは、金額を比べる前に次の5点を確かめておきます。

西日の入る机で2社分の見積書を左右に並べ、ペンで行をたどっている

  • ポイント1 内訳が分かれているか:ハードウェア、ソフトウェア、パッチ、監視、バックアップ、一次対応が「一式」にまとめられていないか
  • ポイント2 対応時間と駆けつけの水準:何時から何時まで受け付けるか、保守員がいつまでに来るか。業務が止まってよい時間と合っているか
  • ポイント3 パッチの扱い:どのパッチを、いつ、検証してから当てるか。そのためにサーバーを止める時間を誰が調整するか
  • ポイント4 役割の分担:障害の受付、切り分け、復旧の作業のうち、自社と保守会社がそれぞれ何を受け持つか
  • ポイント5 製品の保守期限:サーバーやOSのメーカーのサポートがいつまでか。次の更改まで足りるか

メーカーの保守期限が先に来ると、保守の延長か機器の入れ替えで、毎月の保守費とは別の費用がかかります。入れ替えの進め方はサーバーリプレイスの外注で、アプリケーションまで含めた運用保守全体の費用はシステム運用保守の費用相場と内訳で扱っています。

まとめ:サーバー保守費用で確かめておきたい3つの点

サーバー保守の費用を判断するうえで、確かめておきたい点は3つに整理できます。第一に、見積もりを「一式」で受け取らず、内訳に分けてもらうこと。第二に、対応する時間帯や駆けつけまでの時間を、業務が止まってよい時間から選ぶこと。第三に、クラウドに移した後も残るOSの更新や監視を、誰が受け持つかを決めておくことです。この3点を踏まえておけば、「安い契約に切り替えたら、障害のときに誰も来てくれなかった」という事態を避けやすくなります。保守の範囲や水準の決め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

LASSICに相談するメリット

LASSICは2006年の創業以来、システムの運用・保守に特化したプライム(一次請け)のシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。日本ニアショア開発推進機構の認定ベンダーとして、全国のリモート人材による開発・運用の体制を整えています。

サーバー保守の設計では、ZabbixやPrometheusによる死活監視とリソース監視、Windows ServerやRed Hat Enterprise Linuxの更新プログラムの検証環境での事前適用、スナップショットとバックアップ製品を組み合わせた復旧手順を、お客様の環境に合わせて組み立てます。設計の段階では、業務が止まってよい時間から、受け付ける時間帯と駆けつけの水準、パッチを当てる時期と停止の時間、監視の閾値と通知先を決めます。運用では、バックアップから実際に戻せるかを定期的に試し、障害の記録と月ごとの報告をもとに、監視の項目や保守の範囲の見直しを提案します。

よくある質問

サーバー保守の費用はどれくらいが相場ですか

台数、対応する時間帯、駆けつけの水準、監視やパッチの範囲によって大きく変わるため、一律の相場では判断しにくい費用です。同じ条件で複数の会社から見積もりを取り、内訳ごとに比べると判断しやすくなります。

保守契約を結ばずに、故障したときだけ修理を頼むことはできますか

そうした頼み方ができる場合もありますが、部品や技術者の手配に時間がかかり、業務が長く止まるおそれがあります。IPAの資料も、保守契約を結んだほうが結果として運用コストが小さくなる場合があるとしています。*1 止まってよい時間が短いサーバーほど、保守契約で備えておくことをおすすめします。

保守会社を変えるときに準備しておくものはありますか

サーバーの構成、OSとミドルウェアの版、監視の設定、バックアップの取り方と戻し方の手順、過去の障害の記録をまとめておくと、引き継ぎが進めやすくなります。

サーバー保守の範囲と体制の見直しのご相談

サーバーの監視、パッチ適用、バックアップから障害時の一次対応まで、保守の範囲と体制を整理し、元請(プライムベンダー)としてご提案します。

2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。

無料相談はこちら

出典

  1. *1 参考:独立行政法人情報処理推進機構(IPA)「非機能要求グレード2018 システム基盤の非機能要求に関する項目一覧」(https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html)。出典:運用・保守性(C)の項目(運用監視、パッチ適用ポリシー、システム異常検知時の対応、交換用部材の確保、保守契約(ハードウェア・ソフトウェア)、ライフサイクル期間、メンテナンス作業と一次対応の役割分担)の記述を参照(2026年10月確認)
  2. *2 参考:Amazon Web Services「責任共有モデル」(https://aws.amazon.com/jp/compliance/shared-responsibility-model/)。出典:AWSと利用者の責任の分担(ホストOS・仮想化レイヤー・施設の物理的なセキュリティ、ゲストOSの更新とセキュリティパッチ、パッチ管理の共有統制)の記述を参照(2026年10月確認)




View