ITシステムの定期メンテナンス費用は、初期開発費の年間5〜20%が目安で、その幅は開発規模、保守範囲、対応時間帯、自動化レベルによって変わります。
金額を比べるときは、契約条件をそろえて見ることも欠かせません。月額の安さだけで判断すると、後から別途費用が重なることがあります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム定期メンテナンス費用の相場と全体像
定期メンテナンス費用は、初期開発費の年間5〜20%が一般的な目安です。なかでも業界標準は15〜20%とされています。
たとえば、1,000万円で構築したシステムなら、年150万円から200万円程度が相場です。
安定度が高く改修頻度が低い場合は、開発費の約5%を適正な目安とする見方もあり、年50万円前後で収まるケースもあります。
費用の幅が広いのは、システムの種別や利用規模によって必要な工数が変わるためです。
求められる稼働率や対応時間帯も、定期メンテナンス費用を左右します。
開発費の年5〜20%という相場の根拠
年5〜20%という基準は、システム規模に比例して定期作業の対象が増えることから成り立ちます。
- 規模：コードやサーバの対象範囲の広さ
- 連携数：外部システムとの接点の数
- 影響度：停止時に業務へ及ぶ影響の大きさ
コードの行数やサーバ台数、連携する外部システムの数が多いほど、監視やパッチ適用の工数が膨らみます。
バックアップやログ管理の対象も増えるため、開発費が保守費用の見積もり基準として使われます。
ここに挙げる金額は、前述の開発費の割合に基づく例（1,000万円で年150万〜200万円）とは別に、システムの種類ごとに示された年額の目安です。基幹システムの費用は、年間数万円から25万円程度まで幅広く設定されます。一方、ECサイトやアプリケーションは年間10万円から15万円が一つの目安で、利用者数や取引量によって変動します。
基幹系で24時間365日の稼働を求める場合は、相場の上限側になるのが自然です。
費用を左右する主な変動要因
見積もりの差は、対応時間帯、自動化、担当者の構成に分けて読むと手がかりがつかめます。
- 対応時間帯：月額に含む時間帯の範囲
- 自動化：定型作業のうち手作業で残っている部分
- 担当者：役割ごとの作業時間
営業時間内の平日日中だけの対応と、深夜や休日を含む対応とでは、必要な要員体制が異なります。そのため、深夜帯や休日の作業には時間外対応費が上乗せされます。見積書に載っていない費用は、発注側と開発会社の認識がずれる原因になります。
バックアップ取得、ログ削除、サーバ再起動、パッチ適用を手作業で行うと、そのたびに人件費がかかります。一方で、スクリプト化や自動化を進めれば、同じ作業内容でも必要な工数を下げられます。
エンジニアの単価相場は、月70万円から76万円前後が中心です。
上流のPMやITコンサルでは、月295万円に達する場合もあります。
費用が高止まりする二大要因は、手作業の多さとシステムのブラックボックス化です。
費用の内訳と標準的な割合の見方
保守費用が妥当かどうかは、総額より内訳の割合を見ると判断しやすくなります。内訳は、定期保守・メンテナンス、障害対応、軽微な改修・改善の三要素に分けて見るのが基本です。
標準的な割合は、定期保守・メンテナンスが20〜30%、障害対応が25〜35%、軽微な改修・改善が10〜15%です。
残りの部分は、インフラ費用、監視サービス、管理費などが占めます。
標準の割合から外れる項目があれば、その中身を確かめます。
定期メンテナンスが占める20〜30%の中身
定期メンテナンスの20〜30%は、障害を防ぐために計画的に繰り返す作業が占める部分です。
- バックアップ：取得方法と世代管理の決め方
- ログ管理：監視と削除の範囲
- 環境点検：容量や使用率の確認方法
- 更新作業：更新と再起動の対象
定期メンテナンスの対象には、ディスク容量やメモリ使用率の点検、OSやミドルウェアの軽微な更新が含まれます。
セキュリティパッチの適用と定期再起動も、システムの健全性を保つための予防作業です。
比率が極端に高い場合は、自動化できる作業を手作業で行い、工数が膨らんでいる可能性があります。
低すぎる場合は、予防保守が不足し、障害対応に高い費用が回っているおそれがあります。
費用算出の3つの手法
保守費用の見積もりは、どの基準で算出したかによって、透明性や比較のしやすさが変わります。
- 開発費ベース：初期開発費に対する割合
- 工数積算：作業量とエンジニア単価の積み上げ
- 機能ポイント法：機能の複雑さに基づく規模の数値化
開発費ベースは、初期開発費に年5〜20%を掛けて求める方法です。
相場感はつかみやすい反面、運用の負荷が見積もりに反映されにくくなります。
工数積算は、月次作業の人月や人日を積み上げ、単価を掛けて算出します。実態に即しているうえ、作業別の費用も透明です。
機能ポイント法は、機能の複雑さを数値化して規模に応じて算定します。そのため、複数システムの比較や妥当性の検証に向いています。
見積書を受け取ったら、まず算出手法を確かめます。そのうえで、工数積算の内訳が示されているかを見ます。
定期メンテナンスで見落としやすい隠れコスト
月額だけでなく、後から発生する費用も含めた総保有コスト（TCO）で判断する必要があります。特に、定期メンテナンスに含む作業と別途見積もりの境界は、契約前に確認しておきます。
バグ修正、障害対応、OSやミドルウェアの軽微な更新は、一般に月額保守の範囲内とされます。一方で、大幅なデザイン変更や新機能追加など、根本修正を伴う仕様変更は別途費用になります。
時間外対応費とメンテナンスウィンドウのコスト
利用者への影響を抑えた作業ほど、時間帯と追加費用の条件を分けて確認する必要があります。
- 時間外作業：対応時間と月額への含有
- 緊急対応：呼び出し条件と費用
- 超過作業：想定回数と追加条件
深夜や休日のメンテナンスウィンドウには、平日日中とは異なる時間外対応費がかかることがあります。実際、基本料金には平日日中しか含まれず、深夜や休日は都度請求となる契約も少なくありません。
また、メジャーバージョンアップに伴う一時的な作業費も、契約前に洗い出しておく必要があります。そのうえで、設定時間帯と月額への含有を確かめておくと、年間の実質的な費用を見積もれます。
引き継ぎコストと税務・会計上の扱い
月額の安さだけで判断せず、委託先を変えるときの引き継ぎと経理処理も、総コストに含めて考えます。
- 引き継ぎ：仕様と運用知識の移管にかかる工数
- 会計処理：修繕費と資本的支出の区別
同じベンダーに任せ続けると、仕様や運用のノウハウがその会社に集中します。そのため、切り替えでは仕様と運用知識の移管に膨大な工数がかかり、その分の費用を見込んでおく必要があります。
ノウハウが一社に集中し、乗り換えにくくなる状態をベンダーロックインと呼びます。契約時に設計書や運用手順書の整備を求めておくと、乗り換えコストを抑えられます。
目先の月額が安くても、乗り換えの自由度を失うと、将来の総コストが高くなります。
障害除去や現状維持の修正は「修繕費」として期間費用に計上できます。これに対し、新機能追加や性能向上を伴う改修は「資本的支出」として資産計上が必要です。
情報システム部門と経理部門が費用の性質を整理しておくと、予算管理と社内説明が明確になります。
定期メンテナンス費用を適正化する具体策
費用は、品質を落とさずにムダな工数や不要な項目を削ることで下げられます。そのためには、まず実際の利用実績と保守の内訳を確かめることが、再現性のある適正化の出発点になります。
ある民間企業は、未利用サービスを整理したことで、月額28万円を20万円に下げました。削減率は28.6%で、年間96万円の減少です。
定型作業の自動化とスポット契約への切替
削減効果を見込みやすいのは、繰り返し作業の自動化と、契約を利用実績に連動させる方法です。
- 自動化：定型作業のスクリプト化
- クラウド活用：保守対象をクラウド事業者側へ移す
- 契約見直し：利用頻度に応じたスポット契約への切り替え
バックアップ取得、ログ削除、サーバ再起動、パッチ適用を自動化すれば、都度かかる人件費を圧縮できます。さらに、クラウドでOSやミドルウェアの保守を移管すると、自社のメンテナンス対象を減らせます。
標準化と文書化で属人性をなくすことも、高コスト体質からの脱却につながります。
ある政府情報システムは、数年単位の定期保守契約を結んでいました。そのうち、故障率が低く年数回しか使わないPC保守を、スポット契約へ切り替えて費用を下げました。
ほかにも、CPU使用率が低いサーバを稼働率が50%を超えない範囲で停止した事例や、複数のテスト環境を統合・廃止した事例があります。
約50台の物理サーバをメーカー直接保守から第三者保守へ切り替え、コストを削減したケースもあります。これらの事例に共通するのは、実際の利用実績を基準に見直した点です。
第三者保守のコストとセキュリティの両立
第三者保守は有力な削減策ですが、価格とセキュリティは一体で評価する必要があります。
- 脆弱性：メーカーのパッチ非提供に伴うリスク
- 防御策：分離や制限による緩和策
- 責任分界：被害時の担当範囲を契約に明記すること
たとえば、メーカー保守が切れた機器では、製品のセキュリティパッチが提供されない場合があります。そのまま脆弱性が放置されると、重大なインシデントのコストにつながりかねません。
脆弱性が見つかった時点では、代替の防御策としてネットワーク分離やアクセス制限を適用します。
費用を下げる工夫は、削れる工数と守るべきセキュリティ水準のバランスで判断します。
見積もりを取る際のポイントと委託先の選び方
契約時は総額だけでなく、内訳の透明性と条件の明確さを軸に、複数社を比べます。相見積もりでは、対象規模、稼働率、時間帯、作業範囲を同じ前提で各社に伝えることが欠かせません。
前提がそろっていない金額を比べると、安く見えても対応範囲が狭いだけというケースがあります。
保守範囲と契約形態の明確化
追加請求を防ぐには、月額に含む作業と別途費用の境界を、契約で具体的に示しておく必要があります。
- 更新範囲：軽微な更新と大規模更新の区分
- 改修上限：月内に行う軽微改修の工数の上限
- 契約形態：成果重視か柔軟性重視かの選択
たとえば、OSやミドルウェアの軽微な更新を月額に含めるか、メジャー更新を別途見積もりにするかを決めておきます。さらに、月内に対応する軽微改修の上限工数も、契約書や仕様書に落とし込んでおきます。
請負契約は完成義務と契約不適合責任を負うため、納品物が明確な作業に向いています。一方で、準委任契約は善管注意義務のもとで、継続更新や仕様変更に柔軟に対応しやすい契約です。
成果が明確であれば請負、仕様変更の可能性を含めて柔軟性を重視するなら準委任が適しています。
関連記事で深掘りすべきテーマ
費用相場を押さえたら、具体的な進め方や委託先の選定へ進むのが流れです。関連テーマを分けて確認すると、比較の軸が明確になります。
- 進め方：ITシステム定期メンテナンスの進め方で作業の流れを確かめる
- 委託先：ITシステム定期メンテナンスでおすすめの開発会社と比べる
- 発注と全体像：ITシステム定期メンテナンスの発注・外注方法とITシステム定期メンテナンスの完全ガイドを参照する
計画策定からメンテナンスウィンドウの設定、ユーザー告知、実施報告までの全体を押さえておくと、どこにコストがかかるかが見えてきます。
費用、進め方、委託先の選び方、発注方法を横断して理解すると、最適な保守体制を構築できます。
まとめ
費用相場は初期開発費の年間5〜20%で、業界標準は15〜20%です。たとえば1,000万円規模なら、年150万円から200万円が基準になります。
金額は、対応時間帯、稼働率、自動化レベルで変わります。内訳は定期保守20〜30%、障害対応25〜35%、軽微改修10〜15%が目安です。この目安と比べて内訳を見ると、過剰請求やムダな項目にも気づけます。
適正化を考えるときは、時間外対応費、引き継ぎ、税務上の扱いまで含めて総コストを見ます。
未利用サービスを整理して月額28.6%削減した事例のほか、スポット契約や自動化、過剰サーバの停止による事例もあります。
第三者保守を選ぶ場合は、セキュリティと両立させることが前提です。見積もりでは、保守範囲と契約形態を明確にしておきます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。