運用保守費用は、初期開発費用の5〜15%を目安に、月額5万円から100万円以上まで変わります。その幅を左右するのは、システムの規模、対応時間帯、保証する稼働率です。全体像を知りたい場合は、運用保守の完全ガイドもご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
運用保守の費用相場と料金体系の全体像
運用保守費用は、システムの規模、対応時間帯、保証する稼働率で変わります。見積もるには、まず一般的な相場観と料金体系を押さえておく必要があります。
月額・年額の費用相場の目安
月額と年額の相場は、初期開発費用に対する比率とシステム規模の両方から確認するのが基本です。
- 比率の目安：初期開発費用を基準に、年間の保守費用を考えます。
- 規模別の幅：システム規模ごとの月額相場です。
一般的な目安は、初期開発費用の5%から15%程度を年間保守費用とする考え方です。たとえば1,000万円で構築したシステムなら、年間50万円から150万円、月額4万円から12万円程度が基準になります。
中小規模の業務システムは月額5万円から20万円が目安です。一方で、基幹システムや大規模Webサービスは、月額30万円から100万円以上になることもあります。
初期費用の5〜15%という幅は、システムの障害リスクや改修頻度で決まります。単純な情報提供サイトは障害リスクが低く、改修頻度も少ないため、5%前後に収まります。
これに対して、24時間365日の稼働監視や即時の障害対応が必要な基幹システムは、15%を超えることもあります。まずは、自社システムの位置づけを把握することが、相場の妥当性を判断する第一歩です。
料金体系の種類（定額・従量・成果報酬）
料金体系は、予算の安定性とトラブル時の負担を見比べて選ぶのが基本です。
- 定額制：毎月の支払いが一定で、予算を管理しやすい方式です。
- 従量制：作業時間や対応件数に応じて支払う方式です。
- スポット対応：障害発生時に、その都度依頼する形です。
定額制は毎月固定の費用を支払い、軽微な障害対応や問い合わせ対応が一定範囲まで含まれるのが一般的です。また、多くの企業が採用しており、安定的な運用を望む場合に適しています。
従量制は、障害や改修が少ない時期にコストを抑えられる反面、トラブルが多発すると費用が膨らむリスクがあります。
スポット対応は優先対応が保証されず、復旧が遅れる懸念があります。そのため、スポット対応はミッションクリティカルなシステムには向きません。
システムの重要度とトラブル発生頻度を踏まえて料金体系を選ぶと、費用の無駄を減らすことにつながります。
見積もりの内訳とコスト構造
見積もりの妥当性は、提示額が何の作業に、どれだけの工数でかかるのかを分解して判断します。運用保守費用の大部分は人件費です。そのため、内訳を一覧にすると、交渉の余地が見えてきます。
人件費・工数と保守コスト60%の構造
保守費用の比率と工数の中心を確認すると、費用が高くなる背景を把握できます。
- ライフサイクル全体：運用保守の比率は開発より大きくなります。
- 調査・分析：ドキュメント整備が工数と費用を左右します。
ソフトウェアのライフサイクル全体では、開発（構築）の割合は意外に小さいとされます。一方で、運用保守は40%から80%、平均すると約60%を占めるという調査結果があります。
経済産業省の調査では、従来システムの運用と新規構築への支出割合は全産業平均で約2対1です。このため、企業のIT予算の多くが、「作る」よりも「維持する」ことに費やされています。
作業時間で見ると、保守で最も時間がかかるのは「調査・分析」で、全作業時間の約30%を占めるとされています。具体的には、障害原因の特定や改修時の既存仕様の解読に、多くの工数が割かれます。
また、ドキュメントが整い、システムの属人化が解消されるほど、調査・分析の工数は減ります。その結果、保守費用も下がる構造です。見積もりが高いときは、ドキュメント不備による調査コストが増えていないかを確認します。
見積書に含まれる主な費用項目
見積書を役割ごとに分けて読むと、定額に含まれる範囲と追加費用の境界がはっきりします。
- 監視費用：システムの稼働状況を見張る作業にかかる費用です。
- バックアップ費用：データの保存を定期的に行うための費用です。
- パッチ適用費用：OSやミドルウェアの更新にかかる費用です。
- ヘルプデスク・復旧費用：問い合わせへの応対と、障害時の回復作業を指します。
- 追加開発費用：機能改修や仕様変更に別途かかる費用です。
見積書では、各項目が「定額に含まれるもの」と「都度発生する追加費用」のどちらかを確認します。たとえば、月次の定例作業は定額に含まれても、緊急障害対応や軽微な改修は別途見積もりとなるケースが多くあります。
対象範囲と対象外の作業の線引きを、契約の段階で書面に残しておくと、費用の見通しが立ちます。
費用を左右する変動要因
同じ規模のシステムでも、条件次第で運用保守費用に倍以上の差が生じます。見積もりの理由を理解するには、費用を押し上げる要因を先に知っておくことが近道です。そこで、見積もりに大きく影響する要素を順に見ていきます。
SLA（稼働率・対応時間）と対応時間帯
SLAの保証水準と対応時間帯を見れば、必要な運用体制と費用の関係を判断できます。
- SLA水準：保証する稼働率や応答時間が高いほど費用が上がります。
- 対応時間帯：夜間や休日まで含めると人員配置が厚くなります。
費用を最も大きく左右するのは、SLA（サービスレベル合意）の水準です。SLAは、サーバーの稼働率や障害時の応答時間・復旧時間などを数値で約束する取り決めです。そのため、保証水準が高いほど体制を厚くする必要があり、費用も上がります。
大阪市のシステム調達ガイドラインには、具体的な基準値が示されています。たとえば、サーバ・アプリ稼働率は99.8%以上、基準応答時間達成率は93%です。
また、重大障害は年2回まで、障害通知は発生後30分以内とし、その遵守率は100%とされています。ヘルプデスクの電話応答率は97%以上です。
平日日中のみ（5×8時間）と24時間365日（7×24時間）では、費用が大きく異なります。特に、人員配置の都合で、24時間対応の費用が2倍から3倍に跳ね上がることもあります。
夜間障害でも翌朝対応で実害がないシステムなら、24時間対応の必要性を見直せます。こうした見極めは、過剰なSLAによる無駄な支出を防ぐうえで役立ちます。
SLAの設定や交渉の詳細は、運用保守の進め方の記事でも解説しています。
システムの複雑性・属人化・ドキュメント整備状況
技術的な複雑さとドキュメントの状態は、調査・分析の工数を通じて費用に影響します。
- システムの複雑性：構造が複雑なほど保守の調査負担が増えます。
- 属人化と文書：担当者不在や文書不足は保守単価を押し上げます。
設計書や運用手順書が整っていないシステムでは、障害対応や改修のたびに既存仕様を読み解く必要があります。その分の工数が見積もりに上乗せされます。また、古い言語で書かれたレガシーシステムも、保守単価が割高になりがちです。
開発当初の担当者がいないまま内部構造がブラックボックス化したシステムでは、解読に手間がかかります。
ドキュメント整備と属人化の解消は、長期的に保守費用を引き下げる有効な投資です。
仕様書が失われた古いシステムでは、AIに既存コードを解析させる方法も登場しています。この方法を使うと、ブラックボックス化を解消し、省力化につなげられます。
保守費用が高止まりしている場合は、まず属人化やドキュメント不備を点検します。根本の原因から手を打つことが、構造的なコスト削減につながります。
保守費用の妥当性を見抜く監査手法（ITデューデリジェンス）
保守費用の妥当性は、相見積もりに加えて、自社のデータからも検証できます。ただし、相見積もりは、他社が同じ前提条件を理解していなければ、正確な比較になりません。
現行ベンダーに知られると、関係が悪化するリスクもあります。そこで、自社データから適正価格を割り出すITデューデリジェンスの視点が役立ちます。
作業報告書・ログによる実稼働時間の割り出し
監査は、実稼働時間を確認して請求工数と突き合わせるところから始まります。
- 月次の作業報告書をさかのぼり、作業件数と所要時間を集計します。
- サーバーのログイン記録やアクセスログから、作業時間を客観的に確かめます。
- 実稼働時間を、請求されている工数と突き合わせます。
保守費用は基本的に「単価×工数」で構成されます。このため、実稼働時間を市場のエンジニア単価で換算すると、適正な工数ベースの金額を算出できます。
請求額がその金額を大幅に上回る場合は、「待機コスト」や「体制維持費」の過剰請求が疑われます。また、実稼働が少ないのに定額が高い場合は、それが緊急時に即応する体制への対価かを確かめます。その妥当性は、SLAの保証水準と照らし合わせて見ます。
移行コストを含めたTCOによる判断
乗り換えを判断するときは、月額だけでなく、移行を含む総費用を比べます。
- TCO（総保有コスト）：月額以外の費用も含めて比べる考え方です。
- 現行ベンダーとの交渉：競争原理を働かせて、条件を見直す進め方です。
保守費用が割高でも、安易にベンダーを乗り換えることが正解とは限りません。たとえば、新しいベンダーの月額が安くても、引き継ぎの移行コストが300万円から500万円かかる場合があります。
5年間の総額で計算すると、現行ベンダーを継続するほうが安いこともあります。
相見積もりに現行ベンダーも加えると、競争原理が働きます。実際に、現行ベンダーが契約条件を大幅に見直して継続するケースが、30%から40%程度の確率で起きた実例もあります。
移行コストをかけずに適正化できるので、価格交渉と市場価格の把握を並行して進めるのが合理的です。
発注や乗り換えの具体的な進め方は運用保守の発注・外注方法の記事もあわせてご覧ください。
運用保守コストを削減するためのポイント
費用相場と妥当性の判断軸をつかんだら、品質を保ったまま、費用を構造から下げていきます。やみくもに値段を下げるより、費用が確実に下がる施策を選ぶほうが近道です。
自動化・AIOpsによる工数削減
人件費が中心の運用保守では、定型作業の自動化で工数を減らす施策が有効です。
- 定型作業の自動化：監視やログ集計、バックアップを省力化します。
- AIOps：生成AIでアラートの一次切り分けを自動化します。
- 段階導入：限定業務から始めて効果を確認します。
サーバー監視のアラート対応やログ集計、定期的なバックアップは、自動化ツールで省力化できます。
AIOpsでは、膨大なアラートのうち本当に対応が必要なものをAIが判別し、夜間対応の負荷を軽減します。
導入するときは、運用の流れ全体をいきなり刷新せず、小さく始めるのが鉄則です。全体を一度に変えると現場が混乱し、かえってコストが増えることもあります。
AIOpsの効果を確かめながら範囲を広げ、誤検知や学習データを整えるコストも見極めます。負の側面も理解したうえで、投資対効果を見て導入するかを決めます。
契約形態の見直しと費用の落とし穴
契約形態と条項を作業内容に合わせて見直すと、追加費用のリスクを抑えられます。
- 準委任契約：完成責任を負わず、継続的なサービスを提供します。
- 請負契約：明確な成果物の完成を約束します。
- 契約条項：対象範囲や追加費用の条件を確認します。
運用保守の契約は、準委任契約と請負契約に大別されます。
たとえば、監視や問い合わせ対応のような継続業務には準委任が適しています。一方で、機能改修のように成果物がはっきりしている作業は、請負を選ぶのが適切です。
保守契約を準委任契約とすると、第7号文書に該当せず、収入印紙が不要になるケースが多くあります。これは、印紙税法上の実務的なメリットです。
ハードウェア保守でHDDを交換した場合、故障部品の所有権は保守会社に帰属するのが一般的です。ただし、機密データの確実な破棄を求める場合は、別途契約が必要になることがあります。
対象範囲、免責事項、追加費用の発生条件は、契約書で入念に確認します。見落としやすい条項が、後々の追加コストや情報漏洩のリスクにつながります。
コストパフォーマンスに優れたパートナーの選び方は運用保守でおすすめの開発会社・ベンダー6選の記事も参考になります。
まとめ
運用保守の費用相場は、初期開発費用の年間5%から15%が一つの目安です。費用はシステムの規模とSLAの水準で決まり、対応時間帯やドキュメント整備状況も影響します。
また、ソフトウェアのライフサイクル全体に占める保守コストは平均60%です。そのため、妥当性を見極めることは、企業のIT予算に直結する経営課題です。
費用を判断するときは、相見積もりだけに頼らず、作業報告書やサーバーログも確かめます。実稼働時間を請求工数と突き合わせ、移行コストを含めたTCOで比べます。
さらに、現行ベンダーを交えた価格交渉は、品質を維持しながら無駄なコストを削減する方法です。自動化やAIOpsによる工数削減、契約形態の見直しも組み合わせます。そのうえで、適正な価格で運用保守を続けるために、契約条件と投資対効果も確かめます。
運用保守全体を体系的に理解したい方は、運用保守の完全ガイドもあわせてご覧ください。
▼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を創業。