ITシステム保守管理の見積相場や費用/コスト/値段について

ITシステムを開発して稼働させた後、必ず発生し続けるのが「保守管理」のコストです。開発費は一度きりの支出ですが、保守費用はシステムを使い続ける限り毎年かかり続けるため、トータルで見ると開発費を上回ることも珍しくありません。それにもかかわらず、見積書に「保守費用 月額○○万円」と書かれていても、その金額が妥当なのか、何にどれだけ費用がかかっているのかが分かりにくいという声を多くいただきます。

この記事では「ITシステム保守管理」の費用相場を、是正保守・予防保守・適応保守・完全化保守・予測保守という保守の種類ごとの観点から整理します。一般的に語られる「開発費の15〜20%」という相場の根拠と妥当性の見極め方、保守タイプによって費用がどう変わるのか、そして見積金額が高いのか安いのかを判断するための物差しまで、具体的な数字を交えて解説します。読み終えるころには、保守費用の見積書を受け取ったときに「この金額にはこの作業が含まれているはず」と中身を読み解けるようになっているはずです。

ITシステム保守管理の費用相場の全体像

ITシステム保守管理の費用を理解する出発点は、「保守費用は開発費に連動する」という考え方です。業界では年間の保守費用がシステム開発費の15〜20%程度に設定されることが一般的で、金額にすると年間で50万円から800万円程度と幅広いレンジに分布します。この幅の大きさこそ、保守費用の相場が分かりにくい原因です。まずは全体像を押さえましょう。

保守費用の相場としてもっとも広く使われているのが「年間で開発費の15〜20%」という目安です。たとえば3,000万円で開発したシステムであれば、年間の保守費用はおおむね450万円から600万円が目安になります。この比率には根拠があり、システムを安定稼働させ続けるには、開発時に投入した工数の一定割合を毎年メンテナンスに振り向ける必要があるという経験則に基づいています。

ただしこの15〜20%はあくまで標準的なレンジであり、システムの性質によって上下します。金融や医療のように障害が許されないシステム、法改正対応が頻繁に必要なシステム、24時間365日の稼働が前提のシステムでは、20%を超えて25〜30%に達することもあります。逆に、社内利用のみで稼働時間が限定され、障害対応の緊急性が低いシステムであれば10%前後に収まることもあります。比率の数字だけを鵜呑みにせず、自社のシステムがどちらに寄っているかを意識することが大切です。

もう一つ注意したいのは、この比率の分母となる「開発費」の定義です。要件定義から本番リリースまでの総額なのか、それともパッケージのカスタマイズ費用だけなのかで、計算結果は大きく変わります。見積を比較するときは、各社が何を分母にして保守費用を算出しているのかを揃えて確認しないと、見かけ上の安さに惑わされてしまいます。

保守費用を金額で見ると、年間50万円から800万円という非常に広いレンジになります。下限の年間50万円程度に収まるのは、小規模なWebシステムや業務ツールで、障害対応も軽微な修正が中心といったケースです。月額にすると4万円前後で、軽微な問い合わせ対応とごく簡単な修正をカバーする水準と考えると分かりやすいでしょう。

一方、上限の年間800万円に近づくのは、複数のシステムが連携した基幹システムや、専任に近い体制で監視・障害対応を行うケースです。月額にすると60万円を超え、エンジニアの稼働時間を一定数確保する契約に近くなります。同じ「保守」という言葉でも、ここまで金額が違うのは、含まれる作業範囲と体制がまったく異なるためです。

つまり相場を判断するときは「年間いくらか」という総額だけを見るのではなく、その金額でどこまでの作業と体制が約束されているのかをセットで確認する必要があります。次の章では、保守の種類ごとに費用構造がどう変わるのかを掘り下げていきます。

保守タイプ別に見る費用構造の違い

ITシステムの保守は、ISO/IEC 14764などの国際規格で「是正保守」「予防保守」「適応保守」「完全化保守」の4つに分類され、近年はこれにデータ分析で障害を予知する「予測保守」を加えた5分類で語られることもあります。保守費用の妥当性を判断するうえで重要なのは、自社が契約している保守がこのうちどのタイプをカバーしているかを把握することです。タイプによって必要な工数も技術レベルも費用も大きく異なります。

是正保守は、すでに発生した障害やバグを修正する「事後対応型」の保守です。多くの保守契約の基本に含まれる部分で、費用は障害発生の頻度と緊急度に左右されます。障害が起きてから対応するため工数の見積が難しく、月額固定の契約では「月○時間まで」という上限工数を設けたり、規定時間を超えた分は追加で請求する従量制を組み合わせたりするのが一般的です。緊急対応の即時性を高めるほど待機コストが乗るため、費用は上がります。

予防保守は、障害が起きる前に劣化や不具合の兆候をつぶしておく「事前対応型」の保守です。ログの定期点検、ディスク容量やメモリ使用率の監視、バックアップの正常性確認といった作業がこれにあたります。予防保守は地味で成果が見えにくいため、コストを削られがちな領域ですが、ここを手厚くすることで是正保守の発生頻度が下がり、結果的にトータルの保守費用を抑えられます。予防に毎月一定の工数を割く契約は、月額数万円から十数万円のレンジに収まることが多いです。

費用の妥当性を見るときは、是正保守だけの「壊れたら直す」契約なのか、予防保守まで含む「壊れないように見る」契約なのかを確認することがポイントです。前者は一見安く見えますが、障害が起きるたびに追加費用が発生し、結果的に割高になることもあります。

適応保守は、OSやミドルウェアのバージョンアップ、法改正への対応、外部サービスのAPI変更への追従など、システムを取り巻く環境の変化に合わせて手を加える保守です。たとえば消費税率の変更や、ブラウザの仕様変更への対応がこれにあたります。発生のタイミングが外部要因に左右されるため、年間を通じて平準化しにくく、まとまった対応が必要になった月は工数が跳ね上がります。法改正が頻繁な業務システムでは、この適応保守が保守費用の大きな割合を占めることもあります。

完全化保守は、性能の改善や保守性の向上、使い勝手の改善といった、障害ではないものの品質を高めるための保守です。処理が遅くなってきた機能のチューニングや、繰り返し発生している手間を減らすための小改修などが含まれます。実務では機能拡張に近い意味で使われることも多く、純粋な保守というより「小規模な追加開発」として別見積になるケースも少なくありません。

適応保守と完全化保守は、是正・予防に比べて発生の予測が難しく、費用も変動しやすい領域です。月額固定の保守契約に「どこまで含まれるか」を明記しておかないと、後から想定外の追加請求が発生しやすいポイントなので、契約時に範囲を具体的に切り分けておくことが費用管理の鍵になります。

予測保守は、稼働データやログをAIやデータ分析で解析し、障害が起きる前にその予兆を検知して先回りで対処する、もっとも先進的な保守タイプです。規格上は予防保守に含まれる位置づけですが、近年のデータアナリティクスの発展により、実務では独立した技術ドメインとして扱われるようになってきました。人手による定期点検とは異なり、システムが自動で異常の兆候を拾い上げる点が特徴です。

予測保守を実現するには、監視ツールやログ分析基盤への投資が前提になります。ZabbixやDatadogといった監視ツールの導入・運用費用が保守コストに上乗せされる一方で、こうしたツールによって障害の早期発見と対応工数の削減が進めば、人手による是正保守のコストを圧縮できます。つまり予測保守は「ツール費用を払って人件費を下げる」というトレードオフの構造を持っています。

費用対効果を判断するときは、ツール導入費と運用費を足した金額が、それによって削減できる障害対応の人件費やダウンタイムによる機会損失を下回るかどうかをシミュレーションすることが大切です。規模の大きいシステムほど、予測保守への投資が回収しやすくなる傾向があります。

保守費用の内訳とコストを左右する要因

保守費用が「月額○○万円」と提示されたとき、その金額がどんな要素から積み上がっているのかを理解しておくと、相見積を比較する精度が大きく上がります。保守費用の大半は人件費ですが、それ以外にもツール費用やインフラ費用、そして体制を維持するための待機コストが含まれます。ここでは費用の内訳と、金額を左右する主な要因を整理します。

保守費用のもっとも大きな割合を占めるのが、エンジニアの人件費です。保守費用は実質的に「どれだけの工数を、どのレベルのエンジニアが確保するか」で決まります。エンジニアの単価は経験やスキルによって幅があり、月額の人月単価でいえば数十万円から100万円を超える水準まで分布します。保守を担当するエンジニアが高いスキルを持つほど単価は上がりますが、その分、障害の切り分けや復旧が速くなるという面もあります。

工数の観点では、月にどれだけの時間を保守に割り当てるかが費用を決めます。たとえば月10時間の軽微な対応で済む契約と、月40時間の手厚い対応を約束する契約では、当然ながら後者のほうが高くなります。見積を比較するときは、月額金額に対して「何時間分の工数が含まれているのか」を必ず確認し、時間単価に換算して比べると、各社の水準を公平に判断できます。

注意したいのは、保守には実際に手を動かす時間だけでなく、いつでも対応できるように待機している時間のコストも含まれることです。とくに緊急対応を約束する契約では、実作業がない月でも待機の人件費が発生するため、月額固定費が高めに設定されます。この待機コストは目に見えにくいですが、安心して任せるための対価でもあるので、削るべきか維持すべきかは自社の障害リスクと相談して決めるのが妥当です。

保守費用を大きく左右するのが、SLA（サービスレベル合意）でどこまでの水準を約束するかです。たとえば「障害発生から1時間以内に対応を開始し、4時間以内に復旧する」といった厳しい水準を求めるほど、それを支える体制が必要になり、費用は跳ね上がります。実際、官公庁の維持管理業務委託仕様書では、障害発生時に1時間以内の現地到着・対処開始や、原則4時間以内の完全復旧といったシビアな数値が定められている例もあり、こうした要件はそのまま保守コストの上昇要因になります。

サポートの時間帯も費用に直結します。平日日中のみの対応であれば標準的な費用で収まりますが、夜間や休日も含めた24時間365日の対応を求めると、交代要員を確保する必要があるため、費用は数倍に膨らむこともあります。自社のシステムが止まったときに、どれだけ早く復旧する必要があるのかを冷静に見極め、過剰なSLAに費用を払いすぎないようにすることが、コスト最適化の重要なポイントです。

また、定期報告や記録提出の頻度もコストに影響します。先述の官公庁仕様では、定期報告を年4回行い、すべての作業について開始・終了時間や所要時間、再発防止策まで記録して提出することが義務付けられている例があります。こうしたドキュメント整備は透明性を担保しブラックボックス化を防ぐ一方で、作業工数を増やすため費用に反映されます。報告の手厚さと費用のバランスをどう取るかも、契約時に検討すべき論点です。

保守費用を考えるとき、エンジニアの人件費だけに目が行きがちですが、それ以外にも継続的に発生するコストがあります。代表的なのが、サーバーやクラウドの利用料、ミドルウェアやライセンスの年間費用、監視ツールの利用料です。これらはシステムを稼働させ続ける限り発生し続けるため、保守契約とは別枠で計上されることが多く、見落とすとトータルコストを過小に見積もってしまいます。

さらに見落とされやすいのが、保守ドキュメントが整備されていないシステムの「解きほぐし」にかかるコストです。長年放置されてブラックボックス化したシステムを引き継ぐ場合、まず内部を調査してドキュメント化する作業が必要になり、これが初期の追加費用として発生します。新しい保守会社に乗り換える際は、この立ち上げコストを見込んでおかないと、想定外の出費に驚くことになります。

官公庁の仕様書では、維持管理に要する電力料や通信費を受託者の負担と明記している例もあり、どこまでが保守費用に含まれ、どこからが発注者負担なのかという線引きが費用の総額を左右します。見積を受け取ったら、これらの周辺コストが含まれているのか別途なのかを必ず確認し、システムを維持するための総額で比較する習慣をつけましょう。

保守費用の見積を正しく判断するポイント

保守費用の相場と内訳が分かったら、最後は実際の見積をどう判断するかです。同じシステムでも会社によって見積金額が倍以上変わることは珍しくありませんが、それは必ずしも一方がぼったくっているという意味ではなく、想定している作業範囲やSLA水準が違うことの表れであることが多いです。ここでは妥当性を見極めるための具体的な視点を解説します。

保守見積を比較するうえで最初にやるべきは、保守範囲を明文化して各社の前提を揃えることです。是正保守だけなのか、予防保守や適応保守まで含むのか、対応するシステムの範囲はどこまでか、緊急対応の時間帯はいつかといった条件を発注者側で先に定義しておけば、各社が同じ土俵で見積を出してくれます。この前提を揃えずに金額だけを比べると、安い見積に飛びついた結果、必要な作業が含まれておらず追加費用がかさむという事態に陥ります。

IPAが提唱する見積りの考え方でも、不確定要素が多い中での見積りをそのまま確定値として扱うことの危うさが指摘されています。情報が少ない段階で出した概算を、そのまま予算の固定値にしてしまうとリスクが高いということです。保守も同様で、最初に範囲を曖昧にしたまま安い金額で契約すると、後から実態に合わせて費用が膨らみがちです。範囲を具体的に固めることが、結果的にコストの予測精度を高めます。

保守の発注先は、システムを開発したベンダーにそのまま依頼するケースが多いですが、必ずしもそれが最適とは限りません。開発元は内部を熟知している強みがある一方で、他社に競合がいないことで費用が高止まりすることもあります。MSP（マネージドサービスプロバイダー）や保守専門の会社、フリーランスのエンジニアなど、複数の選択肢から相見積を取ることで、相場感が掴めて交渉材料にもなります。

比較するときは、月額金額をそのまま並べるのではなく、含まれる工数で割って時間単価に換算するのが有効です。月額30万円で20時間分なら時間単価1.5万円、月額20万円で10時間分なら時間単価2万円というように、換算すると見かけの安さと実際の割安さが必ずしも一致しないことが分かります。安く見える見積が、実は含まれる工数が少ないだけということもよくあります。

あわせて、見積金額を出してきた根拠を尋ねることも大切です。月にどれだけの工数を想定し、どのレベルのエンジニアが担当し、緊急時の体制はどうなっているのかを説明できる会社は、保守の中身を把握している証拠です。逆に「一式」でしか答えられない会社は、丸投げ体質だったり、実際にはスキルの低い要員をアサインする可能性があるため、注意が必要です。

保守費用は単なるコストではなく、システムを止めないための投資という側面があります。妥当性を判断するときは、その保守によって防げる損失と、保守に払う費用を天秤にかけるROIの視点が役立ちます。たとえば、システムが半日止まったときの売上機会の損失や、業務停止による人件費の損失を金額化すれば、それを防ぐためにいくらまでの保守費用なら妥当かが見えてきます。

監視ツールや自動化への投資も、同じROIの考え方で判断できます。ツールの導入費と運用費を、それによって削減できる障害対応の人件費やダウンタイムの損失と比較し、回収できるなら投資する価値があるということです。この数字を整理しておくと、コストセンターと見なされがちな保守費用を、経営層に対して「払うべき理由がある投資」として説明しやすくなります。

保守費用の妥当性は、絶対額の高い安いだけでは決まりません。自社のシステムがどれだけ重要で、止まったときの影響がどれだけ大きいかという文脈の中で、費用が見合っているかを判断することが本質です。相場の数字はあくまで出発点として使い、最終的には自社の事情に照らして納得できる水準を選ぶことが、後悔しない保守契約につながります。

ITシステム保守管理に関する関連記事

ITシステム保守管理は、費用相場だけでなく、保守の進め方や委託先の選び方、外注の具体的な進め方まで幅広い論点があります。本記事とあわせて以下の関連記事もご覧いただくと、保守管理の全体像をより深く理解できます。

保守の進め方を体系的に知りたい方はITシステム保守管理の進め方｜是正・予防・適応・完全化保守の使い分けと年間計画をご覧ください。委託先の比較検討にはITシステム保守管理のおすすめ会社｜障害対応SLA・予防保守実績で比較が参考になります。外注の具体的な進め方はITシステム保守管理の外注・発注方法｜保守範囲の明文化とレガシー解きほぐしで解説しています。全体を網羅的に把握したい方はITシステム保守管理の完全ガイド｜4-5分類と予測保守まで総まとめもあわせてお読みください。

まとめ

ITシステム保守管理の費用相場は、年間で開発費の15〜20%、金額にして50万円から800万円という広いレンジに分布します。この幅の大きさは、保守に含まれる作業範囲やSLA水準、体制が契約によって大きく異なることに起因しています。相場の数字は出発点として有効ですが、総額だけを比べても妥当性は判断できません。

費用を正しく読み解くには、是正・予防・適応・完全化・予測という保守タイプのどれを含む契約なのかを把握し、人件費や工数、SLA水準、隠れたランニングコストといった内訳を理解することが欠かせません。そのうえで、保守範囲を明文化して各社の前提を揃え、月額を時間単価に換算して複数社を比較し、防げる損失とのROIで妥当性を判断するというステップを踏めば、納得感のある保守契約にたどり着けます。

保守費用は、システムを止めずに価値を生み続けるための投資です。自社のシステムがどれだけ重要かという文脈の中で適切な水準を見極め、過剰でも過少でもない、ちょうどよい保守の体制とコストを選んでいきましょう。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。