システム保守費用の考え方：月額費用の内訳と見直しのポイント

システム保守費用が妥当かどうかは、月額の総額だけを見ても判断できません。保守費用は、障害に備えて人を確保しておく「待機」、異常に気づくための「監視」、OSやライブラリを最新に保つ「更新作業」、小さな修正に使う「改修枠」、そしてサーバーやクラウドの「インフラ費用」といった、性質の違う費用の合計です。総額を下げようとして中身を確かめずに削ると、必要な予防作業まで失われ、後から大きな障害や作り直しの費用として跳ね返ってきます。

逆に、内訳に分けて一つずつ見直せば、「休日の待機は本当に必要か」「改修枠を使い切れていない」「監視の仕組みを自動化すれば手作業が減る」といった、事業への影響を抑えながら費用を適正にする手がかりが見つかります。

この記事は、毎月支払っている保守費用の中身がよく分からない、見直したいが何から手をつければよいか分からない、という経営者・事業責任者・情報システム担当の方に向けたものです。保守費用の内訳、内訳ごとの妥当性の見方、見直しの手順、費用を抑える方法、見直しで失敗しないための注意点を順に説明します。具体的な相場の金額ではなく、判断の枠組みを中心に扱います。

システム保守費用の内訳を分解する

まず、保守費用がどんな費用でできているかを分解します。見積書や請求書に内訳が書かれていない場合は、保守会社に内訳を出してもらうところから始めます。

インフラ費用は、保守会社を経由して支払っている場合と、自社で直接契約している場合があります。保守費用の中に含まれているのかどうかを確認しておかないと、比較を誤ります。

工数の考え方としては、待機・監視・更新作業・問い合わせ対応・改修枠のそれぞれに「どのくらいの作業時間を見込んでいるか × 単価」で費用が組み立てられていることが多いです。単価そのものは会社によって違うため、比較するときは作業時間の見込みと範囲を中心に確認します。

内訳ごとに妥当性を判断する方法

内訳が分かったら、それぞれが自社の事業に見合っているかを確認します。

待機：止まったときの影響に見合っているか

待機の費用は、受付時間と対応の速さで大きく変わります。夜間・休日も含めて即時に対応する体制は、交代で人を確保する必要があるため、平日の日中だけの体制に比べて費用は大きくなります。

判断の基準は、システムが止まったときの影響です。夜間や休日にも顧客が使い、止まると売上や信用に直結するシステムであれば、手厚い待機は必要な投資です。一方、社内の業務システムで、夜間・休日は使われていないのであれば、平日の日中だけで十分かもしれません。重大な障害だけを夜間・休日も受け付ける、という中間の選択肢もあります。

監視：自動化されているか、通知の後に誰が動くか

監視の費用は、人が目で確認しているのか、仕組みで自動化されているのかで変わります。人手による確認が多い場合は、監視の仕組みを整えることで費用を抑えられる可能性があります。

同時に、監視の通知を受け取った後に誰が何をするのかを確認します。通知を受け取るだけで対応は翌営業日、という契約であれば、夜間に異常が起きても朝まで誰も動きません。監視の考え方は監視（システムモニタリング）の解説や、サービス監視とアラートの設計も参考になります。

更新作業：実際に行われているか

更新作業の費用を払っているのに、実際には更新が行われていない、というケースは珍しくありません。過去一年分の作業報告を確認し、どの構成要素がいつ更新されたかを確かめます。報告がない場合は、現在使っているOSやライブラリのバージョンを一覧にしてもらい、サポートが終わっているものがないかを確認します。

更新作業は、削ると目先の費用は下がりますが、放置した期間が長いほど後から必要な作業が大きくなります。最も削ってはいけない内訳の一つです。

改修枠：使い切れているか、足りているか

改修枠は、毎月どのくらい使っているかを確認します。毎月余っているなら、枠を小さくするか、余った時間を計画的な改善に使う運用に変えます。逆に、毎月超過して別途見積もりになっているなら、枠を広げたほうが単価や手続きの面で効率がよい場合があります。

問い合わせ対応と報告：中身が見えているか

問い合わせ対応の費用は、件数と内容で妥当性を判断します。毎月の問い合わせの件数と、そのうち操作方法の質問、不具合の報告、改修の依頼がそれぞれどのくらいあるかを分けて確認します。操作方法の質問が多いなら、マニュアルや画面の改善で減らせる余地があります。不具合の報告が多いなら、問い合わせ対応ではなく品質そのものに課題があるかもしれません。

管理・報告の費用は、受け取っている報告が判断に役立っているかで評価します。定例会議を開いているのに議題が毎回同じで決めることがない、報告書を受け取っているが誰も読んでいない、という状態であれば、頻度や形式を見直して作業時間を減らせます。反対に、報告がまったくない場合は、他の内訳の妥当性を判断する材料がないため、まず報告の仕組みを整えることが先決です。

インフラ費用：使っていない資源がないか

クラウドの費用は、利用量に応じて変わります。使われていないサーバーや、必要以上に大きな構成、古いバックアップの保管などが費用を押し上げていることがあります。見直しの方法はクラウド費用が想定より高いときの見直しポイントで詳しく説明しています。

保守費用を見直す手順

保守費用の見直しは、次の順に進めると、必要な作業を削りすぎずに済みます。

1. 内訳を出してもらう：保守会社に、費用の内訳と、それぞれに見込んでいる作業時間を出してもらいます。インフラ費用が含まれているかも確認します。
2. 実績を集める：過去一年分の作業報告、障害の件数と対応時間、問い合わせの件数、改修枠の使用時間、インフラの利用状況を集めます。
3. システムの重要度を整理する：機能ごとに、止まったときの業務や売上、顧客への影響を書き出し、どの機能にどの水準の保守が必要かを決めます。
4. 内訳ごとに過不足を判断する：重要度と実績に照らして、待機・監視・更新作業・改修枠・インフラのそれぞれが、多すぎるか、足りないかを判断します。
5. 見直し案を作る：削る内訳、増やす内訳、自動化や構成の見直しで減らせる内訳を整理し、見直し案を作ります。
6. 保守会社と協議する：見直し案を保守会社に示し、実現できるか、リスクはないかを確認します。一方的に減額を求めるのではなく、範囲の変更として協議します。
7. 契約と仕様書を更新する：合意した内容を、契約書や保守仕様書に反映します。
8. 半年から一年後に再確認する：見直し後の実績を確認し、障害の対応や改修の進み方に問題がないかを確かめます。

保守契約にどんな項目を含めるべきかは、システム保守契約に含めるべき内容で詳しく扱っています。

費用を抑えるための具体的な方法

内訳を見直した結果、費用を抑えられる余地が見つかった場合の代表的な方法を挙げます。どの方法も、短期的に作業を減らすだけでなく、保守の対象そのものを小さく、扱いやすくすることを狙っています。費用を削るのではなく、保守にかかる手間の原因を減らすという考え方で選ぶと、障害の対応力を落とさずに済みます。なお、自動化や構成の見直しには最初に作業が必要になるため、その費用を何か月で回収できるかを見積もってから着手します。

待機の水準を重要度で分ける

すべての障害に同じ水準で対応するのではなく、重大な障害だけを夜間・休日も受け付け、それ以外は平日の対応にする、というように重要度で分けます。止まっても業務を続けられる機能まで、即時の対応を求める必要はありません。

監視と定型作業を自動化する

人手で行っている稼働確認、ログの確認、定期的な処理の実行などを自動化すると、継続的な作業時間が減ります。自動化には初期の作業が必要ですが、長く使うシステムほど効果が大きくなります。

テストを自動化して更新作業を軽くする

更新作業の手間の多くは、更新後の動作確認にかかります。主要な機能のテストを自動化しておくと、更新のたびの確認作業が軽くなり、更新の頻度も上げやすくなります。

使われていない機能を整理する

長く運用しているシステムには、ほとんど使われていない機能が残っていることがあります。使われていない機能も、更新作業や不具合対応の対象になり、保守の手間を増やします。利用状況を確認し、不要な機能を廃止することで、保守の対象を減らせます。

問い合わせを減らす

操作に関する同じ質問が繰り返し来ている場合は、マニュアルやよくある質問を整備することで、問い合わせ対応の時間を減らせます。画面の分かりにくさが原因であれば、改修枠を使って画面を改善するほうが効果的な場合もあります。

インフラの構成を見直す

利用量に対して大きすぎる構成、使われていない環境、古いデータの保管などを整理します。構成の変更にはリスクもあるため、保守会社と相談しながら進めます。

見積もりの比較と他社への相見積もり

今の保守費用が妥当かを確かめるために、他の保守会社から見積もりを取ることも一つの方法です。ただし、保守の見積もりは前提条件によって大きく変わるため、比較の仕方に注意が必要です。

他社に見積もりを依頼する場合、新しい会社はシステムの中身を知らないため、最初に現状を調査する作業が必要になります。この調査や引き継ぎの費用が見積もりに含まれているかどうかで、総額が大きく変わります。見積もりの比べ方の考え方は、システム開発の見積もり比較のコツも参考になります。

具体例：保守費用を内訳から見直した場面

ここでは架空の一般例として、社内の受発注を管理する業務システムを数年前に開発し、開発会社と保守契約を続けている製造業の会社を想定します。

この会社では、毎月の保守費用が事業の規模に比べて高いのではないかという声が経営会議で上がりました。担当者が契約書を確認したところ、「保守一式」として月額が書かれているだけで、内訳は書かれていませんでした。

そこで、保守会社に内訳と過去一年分の実績を出してもらいました。分かったことは三つあります。一つ目は、夜間・休日も含めた待機の費用が含まれていたことです。しかし、このシステムは平日の日中しか使われておらず、過去一年で夜間・休日に障害が起きたことはありませんでした。二つ目は、改修枠を毎月の半分程度しか使っていなかったことです。三つ目は、更新作業が契約に含まれているにもかかわらず、OSの更新がしばらく行われておらず、サポートの終了が近づいていたことです。

協議の結果、待機は平日の日中のみに変更し、改修枠は小さくしたうえで、余った時間は四半期ごとの改善に充てる運用にしました。一方で、OSとライブラリの更新は計画を立てて確実に実施することにし、その分の作業時間はむしろ増やしました。総額としては見直し前より抑えられ、同時に放置されていた更新のリスクも解消できました。

この例のように、見直しは「総額を下げること」ではなく、「必要なところに費用を寄せること」だと考えると、判断を誤りにくくなります。

保守費用の見直しでよくある失敗と避け方

総額だけで交渉する：内訳を見ずに一律の値下げを求めると、保守会社は目に見えにくい予防の作業から削らざるを得なくなります。範囲の変更として内訳ごとに協議します。

更新作業を削る：何も起きていないうちは、更新作業は無駄に見えます。しかし、放置するほど後から大きな改修が必要になります。更新作業は削る対象ではなく、確実に実施されているかを確認する対象です。

安さだけで保守会社を乗り換える：新しい会社がシステムを理解するまでには時間がかかり、その間は障害対応が遅れるリスクがあります。乗り換えの判断と手順は、保守会社を乗り換える手順を参考にしてください。

実績を集めずに判断する：障害や問い合わせの実績がないまま見直すと、必要な水準を見誤ります。最低でも半年から一年分の実績を集めてから判断します。

見直し後に確認しない：見直した結果、障害の対応が遅れていないか、改修が滞っていないかを確認しないと、問題に気づくのが遅れます。見直し後も定期的に実績を確認します。

保守費用を見直すときのチェックリスト

• 保守費用の内訳と、それぞれの作業時間の見込みを確認した
• インフラ費用が保守費用に含まれているかを確認した
• 過去一年分の障害・問い合わせ・改修・更新作業の実績を集めた
• 機能ごとに、止まったときの影響と必要な保守の水準を整理した
• 待機の水準が、システムの使われ方と影響に見合っている
• 監視の通知後に誰が動くかが決まっている
• 更新作業が実際に行われていることを確認した
• 改修枠の使用状況を確認し、過不足を判断した
• 自動化や構成の見直しで減らせる作業を洗い出した
• 見直し案を範囲の変更として保守会社と協議した
• 見直し後に実績を再確認する時期を決めた

よくある質問

Q. 保守費用は開発費の何割程度が目安ですか？

開発費に対する割合で保守費用を考える方法が紹介されることがありますが、保守費用は開発費の大きさよりも、求める対応時間、更新作業の範囲、改修の量、インフラの構成で決まります。割合を目安にするより、内訳ごとに自社に必要な水準を決めて積み上げるほうが、実態に合った判断ができます。

Q. 保守費用を払っているのに、何もしてもらっていない気がします。

障害が起きていない月でも、待機や監視、更新作業などの作業が行われているはずです。作業の中身が見えないことが不安の原因であれば、毎月の作業報告を受け取る取り決めにします。報告を見ても作業が行われていないようであれば、契約の範囲と実施状況を保守会社と確認します。

Q. 保守を社内で行うことはできますか？

社内に開発の経験がある人がいて、システムの構成を理解していれば、改修や更新作業の一部を社内で行うことはできます。ただし、夜間・休日の障害対応や、専門的なセキュリティ対応まで社内で担うのは負担が大きいため、一部を外部に任せる組み合わせが現実的です。

Q. 保守費用が高いのは、システムの作りに問題があるからですか？

その可能性もあります。テストが自動化されていない、構成が複雑すぎる、古い技術が使われている、といったシステムは、同じ保守でも手間がかかります。保守費用が継続的に重い場合は、構成の改善やリプレイスを含めて検討する価値があります。

Otsumuに相談できること

保守会社から内訳と実績を出してもらえる関係があり、システムの重要度を社内で判断できる場合は、この記事の手順に沿って内訳ごとに見直し案を作り、保守会社と協議するだけで、自社で十分に適正化を進められます。外部の力を借りなくても、多くの見直しは実現できます。

一方で、保守会社から内訳や実績が出てこない、システムの構成や更新の状態を社内で誰も判断できない、保守費用が重い原因がシステムの作りそのものにありそうだ、といった状況では、技術的な観点から現状を確認できる第三者がいたほうが、判断の根拠を持てます。

Otsumuは自らも事業を手がける立場から、事業への影響を起点に必要な保守の水準を整理し、現状のシステムの調査、保守内容の見直し、監視や更新作業の自動化、保守の引き受けまでを一気通貫で支援しています。既存システムの保守のご相談は保守・運用で承っています。範囲に応じて個別にお見積もりします。

今の保守の契約書や請求の内容をお持ちいただければ、どこから見直すべきかを一緒に整理できます。まずは30分の無料相談をご利用ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01