システム保守費用の相場はいくら？【2026年版】情シスが使える5つの判断基準と削減策
「現在の保守費用が相場と比べて高いのか、それとも妥当なのか分からない」——多くの情シス担当者が抱えるこの悩みには、判断基準がないことが根本原因です。
本記事では、システム保守費用の相場と、自社の費用が適正かを判断する5つのチェックポイントを解説します。費用が高くなる原因、削減の具体策、ベンダー変更を検討すべきタイミングまで一気通貫でカバーします。
この記事でわかること
- システム保守費用の相場（規模・種別ごとの目安）
- 保守費用が高すぎるかを判断する5つの指標
- 保守費用が高くなる3つの構造的原因
- 費用を適正化する3つの対処法
- ベンダー変更を検討すべきタイミングと準備の進め方
想定読者
- 現在の保守費用が相場と比べて高いかどうかを確認したい情シス担当者
- ベンダーから提示された保守費用の見積もりが妥当かを判断したい方
- 予算削減を求められており、保守費用の見直しを検討している方
目次
システム保守費用の相場
開発費用に対する比率の目安
システム保守費用の一般的な目安として、年間保守費用 ＝ 開発費用 × 15〜20% という基準がよく用いられます。
たとえば開発費用が3,000万円のシステムであれば、年間保守費用の相場は 450〜600万円（月額37〜50万円） が一つの目安です。
ただしこの比率は保守内容や契約範囲によって大きく変わります。20%を大幅に超えている場合は見直しのサインです。
システム種別・規模別の相場
| システム種別 | 年間保守費用の目安 | 備考 |
|---|---|---|
| 中小規模の基幹システム（ERP・販売管理など） | 300〜800万円 | 開発費3,000〜5,000万円規模の場合 |
| 大規模基幹システム | 800万円〜 | カスタマイズが多いほど高くなる傾向 |
| ECサイト・Webシステム | 50〜200万円 | クラウド型は割安なケースが多い |
| スマホアプリ | 100〜300万円 | OS更新対応のたびに追加費用が発生しやすい |
| 社内ツール・ポータル | 50〜150万円 | Microsoft 365等のSaaSに移行で削減できることも |
| 製造業の生産管理・基幹システム | 500〜1,500万円 | オンプレミス環境では特に高くなりやすい |
保守費用に含まれる主な内容
「月額○○万円」という一括金額の内訳を把握することが、妥当性判断の第一歩です。
| 項目 | 内容 |
|---|---|
| 障害対応・トラブルサポート | 障害発生時の調査・修正・復旧対応 |
| ソフトウェアアップデート | OS・ミドルウェア・ライブラリのセキュリティパッチ適用 |
| ハードウェア保守 | サーバー・ネットワーク機器の故障対応・部品交換 |
| 定期監視・レポート | サーバー稼働監視・ログ確認・月次報告 |
| 軽微な改修対応 | 仕様変更が不要な小さな修正・設定変更 |
この5項目のうち何が含まれていて何が含まれていないかを契約書で確認することが重要です。含まれていると思っていた対応が「別途見積もり」になっているケースは珍しくありません。
保守費用が高くなる3つの構造的原因
現在の保守費用が相場を上回っている場合、以下の3つのどれかに該当することがほとんどです。
原因1：長年の契約継続による「市場価格との乖離」
同じベンダーと5年以上契約継続している場合、当初は適正だった費用が市場相場と乖離したまま固定されているケースがあります。ベンダー側も「継続契約の顧客には値上げ交渉しやすい」という実態があり、特に比較検討の機会がないまま更新し続けると費用が高止まりします。
確認方法： 他社に概算見積もりを依頼し、現在の保守内容と比較してみる。
原因2：システムの老朽化による「保守工数の増大」
リリースから10年以上経過したシステムは、ソースコードの複雑化・担当者の属人化・技術スタックの陳腐化が進み、障害対応や軽微な改修にかかる工数が増大します。ベンダー側のコストが上がるため、保守費用に上乗せされるか、都度追加費用として請求されます。
対処の方向性： 部分的なリファクタリングまたはクラウド移行・システム刷新を検討する段階のサイン。
原因3：契約範囲の曖昧さによる「追加費用の積み上がり」
SLAが未定義で保守範囲が曖昧な契約では、ベンダー側の裁量で「これは保守範囲外」と判断された作業が都度追加請求されます。毎月の保守費用は低く見えても、実質的な年間コストは高くなっているケースがあります。
対処の方向性： 契約書でSLAと保守範囲を明文化する再交渉を行う。
自社の保守費用が適正かを判断する5つのポイント
ポイント1：開発費比率が20%を超えていないか
年間保守費用 ÷ 開発費用を計算して、20%を大幅に超えている場合は見直しの余地があります。
開発から10年以上経過したシステムは開発費が低い一方で保守費用が高止まりするケースがあります。この場合は「現在の市場価格でのシステム再構築費用」を参照して比率を計算すると実態に近い判断ができます。
ポイント2：SLA（サービスレベル合意）が契約書に定義されているか
保守費用に見合ったサービス品質かどうかを判断するには、SLAの存在が前提になります。以下の項目が契約書に明記されているか確認してください。
- 障害発生時の初動対応時間（例：「受付から2時間以内に一次回答」）
- 復旧目標時間（RTO）・復旧目標時点（RPO）
- 月次の稼働率保証（例：99.5%など）
SLAが定義されていない場合、どれだけ対応が遅くてもベンダー側に契約上の責任が発生しません。SLAなしで高額の保守費用を支払っている場合は、費用の根拠を問い直す必要があります。
ポイント3：担当者が1〜2名に集中していないか（属人化リスク）
ベンダー側の対応担当者が1〜2名のみで、その担当者が退職・異動した途端に対応品質が落ちるケースは珍しくありません。
確認すべき点：
- 担当者が変わった場合の引き継ぎ体制は整っているか
- 担当技術者は何名いるか
- 障害対応時に代替できる担当者はいるか
担当者依存の保守体制は将来的に対応不能になるリスクを抱えており、リスクプレミアムとして費用が高くなっていることがあります。
ポイント4：改修・追加開発の対応スピードと費用は適正か
小さな改修依頼に対して、都度「別途見積もり」として追加費用を請求されていないでしょうか。
目安として：
- 軽微な修正（1〜2時間の作業）：月次保守費用に含まれているべき
- 機能追加（数日〜1週間の作業）：別途見積もりが適切
- 改修の回答・見積もりまでの日数：3営業日以内が一般的
月次保守費用の範囲で対応すべき修正に都度追加費用が発生している場合は、実質的な保守費用が想定より高くなっています。
ポイント5：複数のベンダーと費用を比較したことがあるか
現在のベンダーとのみ取引を続けている場合、市場相場との乖離が広がりやすくなります。特に同じベンダーと5年以上契約継続している場合は、少なくとも他社の概算見積もりを取得して比較することをお勧めします。
比較のポイント：
- 月額費用と含まれる対応内容（SLAの有無）
- 障害対応の体制（24時間対応か、平日日中のみか）
- 引き継ぎ時に提供されるドキュメントの範囲
保守費用が高い場合の3つの対処法
対処1：保守範囲の再定義・契約の見直し
現在の保守契約に含まれているすべての項目を洗い出し、「本当に必要か」を評価します。
よくあるケース：
- クラウドに移行済みなのにオンプレサーバーのハードウェア保守費が残っている
- すでに使われていない機能のサポートを継続している
- 平日日中のみ稼働するシステムなのに24時間監視費用を払っている
実態と契約内容のズレを解消するだけでコストが下がることがあります。まずは契約書と実際の対応実績を照らし合わせる棚卸しから始めましょう。
対処2：クラウド移行・SaaS化による保守コスト削減
オンプレミス環境の保守費用はハードウェア保守費が含まれるため割高になる傾向があります。クラウド移行によってハードウェア保守費用を削減し、月次費用をOPEX化することで保守費用を適正化できるケースがあります。
特に以下の場合は移行を検討するタイミングです：
- サーバーの保守期限が3〜5年以内に切れる
- ハードウェアの老朽化でトラブルが増えている
- オンプレの保守費用がクラウドの運用費を大幅に上回っている
対処3：ベンダー変更の検討
複数社の比較・SLAの改善交渉・費用根拠の開示要求を行った上でなお費用が相場より高い場合は、ベンダー変更の検討に入ります。
移行コストの試算方法：
| 項目 | 内容 |
|---|---|
| 移行支援費 | 新ベンダーへのドキュメント引き継ぎ・受け入れテスト費用（通常1〜3ヶ月分の保守費相当） |
| 年間削減額 | 現在の保守費 − 新ベンダーの保守費 |
| 回収期間の目安 | 移行支援費 ÷ 年間削減額（1〜3年以内が目安） |
「ベンダーを変えると引き継ぎが大変そう」という懸念は多いですが、移行コストと年間削減効果を試算すると、多くのケースで1〜3年以内に回収できます。
ベンダー変更を検討すべきタイミングと準備
保守費用の妥当性を第三者視点で確認したいですか？
c3indexでは、現在の保守契約の棚卸しから、ベンダー変更の要件整理・新ベンダーの選定支援まで対応しています。まずはご相談ください。
ベンダー変更を検討すべき4つのサイン
以下のいずれかに当てはまる場合は、ベンダー変更の検討を具体化する時期です。
- 保守費用が開発費の25%以上で、費用根拠の説明を求めても明確な回答が得られない
- 障害発生時の初動対応が遅く、SLAが未定義または守られていない
- 担当者が高齢化・属人化しており、退職リスクが顕在化してきた
- 改修依頼のたびに見積もりが高く、対応も遅い状態が1年以上続いている
ベンダー変更前に準備すること
| 準備項目 | 内容 | 優先度 |
|---|---|---|
| ドキュメント整備 | 設計書・ソースコード・テスト仕様書・操作マニュアルを現ベンダーから取得 | 高 |
| 要件定義 | 新ベンダーに何を引き継ぐかをまとめた引き継ぎ要件書の作成 | 高 |
| 複数社からの見積もり取得 | 2〜3社から概算見積もりを取得して比較 | 中 |
| 社内合意形成 | 経営・調達・事業部門への説明・稟議 | 中 |
| 移行スケジュールの策定 | 引き継ぎ期間（通常2〜3ヶ月）を確保したスケジュール作成 | 中 |
ドキュメントが不足している場合（ブラックボックス化）は、新ベンダーへの引き継ぎ前にドキュメント整備を行う必要があります。これは通常1〜3ヶ月の追加作業となりますが、適正な保守費用での新契約が可能になる重要な投資です。
よくある質問
Q. 保守費用の相場が分からず、ベンダーに言われるままになっています。何から始めればよいですか？
A. まず「年間保守費用 ÷ 開発費用」で比率を計算し、20%を超えていないかを確認してください。次に契約書でSLAが定義されているかを確認します。この2点だけでも費用の妥当性を判断する材料になります。さらに他社の概算見積もりを取ることで、より具体的な比較ができます。
Q. ベンダーに「これくらいかかる」と言われても根拠が分かりません。
A. 見積もりに対して「工数の内訳（誰が何時間作業するか）」と「単価の根拠（エンジニアの時間単価）」を開示してもらうことが有効です。月次保守の場合は「月あたり何時間の作業を想定しているか」を確認してください。根拠を示せないベンダーであれば、他社との比較を検討する理由になります。
Q. ベンダーを変えると引き継ぎが大変そうで踏み出せません。
A. 引き継ぎには工数がかかりますが、移行コスト（移行支援費＋テスト費）と年間の保守費削減額を比較した場合、多くのケースで1〜3年以内に回収できます。まずは「移行コストの試算」だけを行ってみると、決断のしやすさが変わります。
Q. 社内でコスト削減を進めたいが、現在のベンダーとの関係が悪化するのが心配です。
A. 費用の見直しを検討していると伝えることは正当な交渉です。まず契約範囲の確認と費用根拠の開示を依頼し、交渉が難航する場合は並行して他社の見積もりを取得する進め方が現実的です。関係悪化を恐れて費用が高止まりしたまま契約継続することのリスクの方が大きい場合が多いです。
Q. 保守費用を削減したいが、品質が落ちるのが不安です。
A. SLAを明文化した上でベンダー変更を行うことで、現在より品質が向上するケースも多くあります。現在の保守契約にSLAがない場合は、むしろベンダー変更が品質向上の機会になります。新ベンダーの選定時はSLAの内容を必ず比較してください。
まとめ
- 相場の目安：年間保守費用 ＝ 開発費の15〜20%。20%超は見直しの余地あり
- 費用が高くなる3原因：長年契約による市場乖離・システム老朽化・契約範囲の曖昧さ
- 5つのチェックポイント：開発費比率 / SLAの有無 / 属人化リスク / 改修対応の範囲と速度 / 他社比較
- 対処法：保守範囲の再定義 → クラウド移行検討 → ベンダー変更の検討
- ベンダー変更の判断基準：移行コストを年間削減額で割り、1〜3年以内に回収できるか試算する
保守費用の見直しは、単なるコスト削減だけでなく、保守品質の向上・リスク低減・将来のDX基盤整備にもつながります。「高い気はするけど、判断基準がない」という状態をそのまま放置するのが最もリスクが高いと言えます。
保守費用の見直しをc3indexに相談する
現在の保守費用が適正かどうか、第三者の視点で確認したい方はお気軽にご相談ください。c3indexでは、現行の保守契約の棚卸し・相場との比較・ベンダー変更の要件整理まで一貫してサポートしています。
CATEGORIES
CATEGORIES
