システム保守費用の相場は？【2026年版】開発費15〜20%の内訳とフルスクラッチの注意点

「開発費は見積もりを取ったけれど、保守費用のことは聞いていなかった」——システムが完成し、運用が始まってから、この言葉を口にする経営者の方は少なくありません。

初期の開発費用にばかり目が向きがちですが、システムは作って終わりではなく、そこから数年、場合によっては10年近く使い続けるものです。保守・運用の費用とリスクを見落としたまま契約すると、後になって「毎月の保守費が想定外に高い」「担当会社以外は誰も直せない」という事態に直面しかねません。

先に、要点を3つにまとめます。

年間保守費用の目安は、開発費の15〜20%程度（内容や契約範囲によって変動）。開発費500万円なら年75〜125万円、月6〜10万円前後が一つの相場感
フルスクラッチ開発は「ブラックボックス化」のリスクと隣り合わせ。仕様書・設計書・ソースコードの引き渡し条件を契約前に決めておくことが、将来の乗り換え自由度を左右する
仕様凍結後の追加要望が費用超過・訴訟リスクの最大要因。変更管理のルールを最初に握っておくことが、保守費用そのものより重要なケースもある

本記事では、中小企業の経営者・情シス担当の方に向けて、システム開発を発注する前に知っておきたい「保守・運用フェーズ」の費用相場と落とし穴を、2026年7月時点の情報をもとに整理します。

システムの保守費用は、開発費のどれくらいが相場？

開発費300万〜2000万円ごとの年間保守費用目安（15〜20%）と保守費用の内訳5項目を示す図解

年間保守費用は、開発費のおおむね15〜20%が目安とされています。5年、10年と使い続けるほど、この積み上げが総コストに占める割合は大きくなります。

システム開発の費用というと、初期の開発費用（イニシャルコスト）に注目が集まりがちです。しかし実際には、公開後も継続して発生する保守・運用費用（ランニングコスト）を含めて総コストを考える必要があります。

複数の受託開発会社が示す目安では、年間保守費用は開発費の15〜20%程度とされることが多く、システムの複雑さやSLA（サービス品質保証）の水準、稼働年数によっては20〜25%まで見込むケースもあります。目安として金額に置き換えると、次のようになります。

開発費用	年間保守費用の目安（15〜20%）	月額換算
300万円	45〜60万円	約3.8〜5.0万円
500万円	75〜100万円	約6.3〜8.3万円
1,000万円	150〜200万円	約12.5〜16.7万円
2,000万円	300〜400万円	約25.0〜33.3万円

あくまで目安であり、実際の金額は保守範囲・SLA・稼働年数によって上下します。契約前には、この比率がどのように算出されているか、開発会社に根拠を確認することをおすすめします。

保守費用の内訳は、一般的に次のような項目で構成されます。

サーバー・インフラ監視：稼働状況の監視、障害の予兆検知
セキュリティ対応：脆弱性対応、ライブラリ・OSのアップデート
障害対応：不具合発生時の切り分け・修正
軽微な修正・改善：ちょっとした仕様変更、UI調整
管理・レポート：稼働報告、月次のミーティング

「保守費用一式・月額◯万円」という見積もりだけでは、この5項目のうちどこまでが含まれているかが分かりません。特に「軽微な修正」の範囲は会社によって解釈が大きく異なるため、何時間分の作業がその金額に含まれるかを契約書や見積書の注記で確認しておくと、後々のトラブルを避けやすくなります。

フルスクラッチ開発、保守はどこに頼めばいい？

契約した開発会社以外がソースコードや設計書の全体像を把握していない場合、実質的にその会社でしか保守できない「ベンダーロックイン」状態になりやすい点に注意が必要です。

既製のパッケージ製品やSaaSであれば、提供元がどこであっても仕様はある程度共通化されています。一方でフルスクラッチ開発（ゼロから独自に作るシステム）は、その会社独自の設計・実装になるため、開発を担当した会社以外が保守を引き継ぐハードルが高くなりがちです。

これは「フルスクラッチが悪い」という話ではありません。既製品にない柔軟性・独自性はフルスクラッチの明確なメリットです。問題は、引き継ぎを想定した準備を契約時にしているかどうかにあります。具体的には、次の点を契約前に確認しておくことをおすすめします。

ソースコードの著作権・利用権の帰属：発注者に譲渡されるのか、開発会社に留保されるのか
設計書・仕様書の納品有無：口頭やチャットのやり取りだけで完結していないか
ソースコードのバージョン管理・アクセス権：GitHubなどのリポジトリに発注者もアクセスできる状態か
開発会社が事業を終了・撤退した場合の対応：エスクロー（第三者預託）などの取り決めがあるか

経済産業省の「DXレポート」でも、老朽化・ブラックボックス化した既存システムが刷新や連携の足かせになる「レガシーシステム問題」が長年指摘されてきました。フルスクラッチで新しく作ったシステムであっても、引き継ぎ準備を怠れば同じ構造の問題を将来抱えることになります。「今の担当会社と長く付き合えるか」だけでなく、「万が一の際に他社へ引き継げるか」の両面で発注先を見ておくと安心です。

このあたりの考え方は、老朽化した社内システムをいつ・どう刷新するかでも詳しく整理しています。既存システムのリプレースを検討する際にも同じ視点が役立ちます。

保守費用より怖い「仕様変更の追加費用」、どう防ぐ？

保守費用そのものより、開発中・開発後の仕様変更が際限なく積み重なることの方が、費用超過や訴訟リスクとして深刻になりやすい問題です。

システム開発の費用トラブルとして最も多いのが、実は保守費用の高さそのものではなく、**「仕様凍結後の追加要望」**です。仕様を決めて開発が始まった後に「やっぱりこの機能も欲しい」という要望が積み重なると、当初の見積もりを大きく超えるコストと納期遅延が発生します。

象徴的な例として、電子カルテシステムの開発を巡り、旭川医科大学とNTT東日本の間で争われた裁判があります。仕様を一度凍結した後も現場からの追加要望が続き、最終的に発注者側に約14億円の支払いを命じる判決が下されました（札幌高裁2017年8月31日判決）。これは大学病院向けの大規模プロジェクトの事例であり、中小企業の一般的な受託開発とは規模が大きく異なりますが、「仕様を決めた後の追加要望をどう扱うか」というルールを最初に握っておくことの重要性を示す事例として、業界でよく参照されています。

中小企業の受託開発でこのリスクを避けるには、次のような進め方が現実的です。

要件定義の段階で「やらないこと」も明文化する：やることのリストだけでなく、対象外の範囲も合意しておく
仕様凍結のタイミングを契約書に明記する：「基本設計完了時点で仕様を確定する」など、区切りを決める
凍結後の変更は「変更管理プロセス」に乗せる：追加費用・納期影響を都度見積もり、書面で合意してから着手する
現場の声を拾う窓口を一本化する：複数の現場担当者が個別に開発会社へ要望を出す状態を避ける

「追加費用が発生する変更」と「無償で対応できる軽微な調整」の線引きを、契約時にある程度言語化しておくことが、保守・運用フェーズに入ってからの費用トラブルを防ぐ最も効果的な手立てです。

見積書の読み方そのものについては、システム開発の見積書、どう読む？で詳しく解説しています。あわせて確認しておくと、保守フェーズまで見通した契約がしやすくなります。

保守・運用コストを抑えながら、安心して任せるには？

「保守費用の金額」だけでなく「何かあったときに引き継げる体制か」を含めて評価することが、長期的なコスト最適化につながります。

保守・運用フェーズでよくある失敗パターンを整理すると、次のようなものがあります。

失敗例1：保守契約の範囲を確認せずに契約し、軽微な修正のたびに追加費用を請求された → 契約前に「月◯時間分まで無償」といった上限を明記してもらう
失敗例2：担当エンジニアの退職・会社の縮小をきっかけに、保守対応が急に滞った → 属人化を避けるため、複数名体制で対応している会社か、ドキュメントが整備されているかを確認する
失敗例3：現場からの要望をそのまま次々と実装依頼し、気づけば保守費用が開発費に迫るほど膨らんだ → 四半期ごとに「本当に必要な改修か」を棚卸しする運用ルールを設ける
失敗例4：SaaSを何個も併用した結果、保守対応窓口がバラバラで障害時にどこに連絡すべきか分からなくなった → システムを一元化するか、窓口を集約する

保守・運用コストを抑えるうえで有効なのは、「安い保守契約を探す」ことよりも、「そもそも保守がかかりにくい設計にしておく」ことです。過剰に複雑な機能を最初から詰め込まず、必要な範囲から段階的に作る進め方（MVP的なアプローチ）は、初期費用だけでなく保守費用の圧縮にもつながります。

ゼットリンカーでは、既存システムの保守・改修のご相談も承っています。詳しくは既存システム改修・ITよろず相談のページをご覧ください。新規のオーダーメイド開発をご検討の場合はウェブ開発のサービス内容もあわせてご確認いただけます。

保守・運用のことも含めて相談したい、今の保守費用が適正か確認してほしいという場合は、お気軽にお問い合わせください。

保守費用が膨らむ根本原因がシステムの老朽化にある場合は、作り変えという選択肢もあります。業務を止めない段階移行の進め方はシステムリプレース開発で紹介しています。

FAQ

Q. システムの保守費用は開発費の何％くらいが目安ですか？

A. 年間保守費用は、開発費のおおむね15〜20%が一つの目安とされています。開発費500万円のシステムであれば、年75〜100万円（月6〜8万円程度）が目安です。ただしシステムの複雑さやSLAの水準、稼働年数によって上下するため、契約前に内訳と算出根拠を確認することをおすすめします。

Q. フルスクラッチ開発は保守費用が高くなりますか？

A. 一概には言えません。既製品と違い独自設計になるため保守の専門性は必要ですが、無駄な機能を削ぎ落とせる分、保守すべき範囲自体を小さく抑えられる場合もあります。重要なのは金額の高低よりも、開発会社以外が保守を引き継げる状態（ソースコードの権利・設計書の有無）を確保しておくことです。

Q. 保守を依頼していた開発会社と契約を終了したい場合、どうすればいいですか？

A. ソースコードの著作権・利用権が発注者に帰属しているか、設計書や仕様書が納品されているかによって、引き継ぎの難易度が大きく変わります。契約時にこれらの条件を明記しておくことで、将来的に別の会社へスムーズに移行できる可能性が高まります。

Q. 仕様変更のたびに追加費用がかかるのは仕方ないのですか？

A. 仕様凍結後の変更に追加費用がかかること自体は一般的です。重要なのは、どこからが「追加費用の対象」で、どこまでが「無償対応の範囲」かを契約時に言語化しておくことです。曖昧なまま進めると、費用超過だけでなく開発会社との関係悪化にもつながります。

Q. 保守・運用コストを抑える一番の方法は何ですか？

A. 「安い保守契約を探す」よりも「保守がかかりにくい設計にする」ことが効果的です。必要な機能から段階的に作り、過剰な作り込みを避けることで、初期費用と保守費用の両方を抑えやすくなります。あわせて、複数名体制やドキュメント整備がある開発会社を選ぶことで、属人化によるリスクも減らせます。