システム保守費用の相場は？【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項目のうちどこまでが含まれているかが分かりません。特に「軽微な修正」の範囲は会社によって解釈が大きく異なるため、何時間分の作業がその金額に含まれるかを契約書や見積書の注記で確認しておくと、後々のトラブルを避けやすくなります。

なお「開発費の15〜20%」という比率は、IPA（情報処理推進機構）などの公的統計に基づく定量調査の数値ではなく、複数の受託開発会社が実務経験から示している目安です。この点を「公的な統計」であるかのように紹介しているサイトも見受けられますが、根拠として引用する場合は出典に注意してください。保守費用の内訳をさらに項目別の比率で示すサイトもありますが、これも各社の経験則であり、公的な定量調査による内訳比率は確認できていません。自社の見積もりを評価する際は、比率の数字そのものより、5項目のうちどこにどれだけ工数が割かれているかを開発会社に説明してもらうことをおすすめします。

業種・システムの重要度によって、保守費用は変わる？

金融・医療・製造ラインの制御システムなど、止まった際の影響が大きいシステムほど、保守費用は高くなる傾向があります。具体的な倍率を示す公的な統計はありませんが、理由は明確です。

可用性要件が厳しい業種のシステムには、次のような追加コストがかかりやすくなります。

24時間365日の監視・対応体制：営業時間内だけの監視では足りず、深夜・休日も含めた体制が必要になる
法規制・業界基準への対応：金融機関のFISC安全対策基準、医療機関の個人情報保護対応など、業界特有の要件を満たす保守作業が発生する
可用性を担保する設計（冗長化・バックアップ）の維持：システム本体だけでなく、障害時の切り替え環境も保守対象に含まれる
変更管理の厳格化：軽微な修正であっても、事前のテスト・承認プロセスが重厚になりやすい

一方、社内向けの業務システムや、止まっても翌営業日に対応すれば大きな支障がない仕組みであれば、保守の水準を必要以上に高くする必要はありません。「このシステムが1日止まったら、どれくらいの損失が出るか」を発注前に言語化しておくと、身の丈に合った保守水準（＝過不足のない費用）を開発会社と合意しやすくなります。

保守契約の形態：定額制・従量制・チケット制のどれを選ぶ？

保守契約には大きく3つの形態があり、システムの利用状況や変更頻度によって向き不向きが分かれます。

契約形態	仕組み	メリット	デメリット	向いているケース
定額制	月額固定で対応範囲内の作業を実施	予算が立てやすい。緊急対応も範囲内なら追加費用なし	対応が少ない月も同額。範囲外の作業は別途見積もり	障害対応や軽微な修正が継続的に発生するシステム
従量制	実際に発生した作業時間・内容に応じて請求	対応が少なければ費用を抑えられる	繁忙期・障害多発期に費用が読みにくい	稼働が安定していて、月1〜2回程度の対応で足りるシステム
チケット制（ポイント制）	事前購入した時間・ポイントを消化する方式	予算の上限を決めやすく、消化状況も可視化しやすい	未消化分の扱い（繰越可否）を契約時に確認する必要がある	スポット対応が中心で、定額ほどの継続的な保守は不要なケース

どの形態が優れているというより、自社のシステムがどれくらいの頻度で「人の手」を必要とするかによって最適解が変わります。立ち上げ直後で不具合や改善要望が多い時期は定額制、安定稼働後は従量制やチケット制に切り替える、という運用も現実的な選択肢です。契約更新のタイミングで、直近半年〜1年の対応実績（何件、何時間分の対応があったか）を開発会社から開示してもらい、契約形態が実態に合っているか見直すことをおすすめします。

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

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

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

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

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

経済産業省の「DXレポート」（2018年9月公表）でも、老朽化・ブラックボックス化した既存システムが刷新や連携の足かせになる「レガシーシステム問題」が指摘されてきました。同レポートによると、わが国企業のIT関連費用の約8割は、新規のデジタル投資ではなく既存システムの維持・運用（ラン・ザ・ビジネス）に割り当てられているとされ、老朽システムを抱える企業の約7割が「DXの足かせになっている」と感じているという調査結果（日本情報システム・ユーザー協会調べ）も紹介されています。フルスクラッチで新しく作ったシステムであっても、引き継ぎ準備を怠れば同じ構造の問題を将来抱えることになります。「今の担当会社と長く付き合えるか」だけでなく、「万が一の際に他社へ引き継げるか」の両面で発注先を見ておくと安心です。

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

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

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

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

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

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

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

仕様変更の追加費用を防ぐ4ステップ：要件定義で「やらないこと」も明文化、仕様凍結タイミングを契約書に明記、凍結後の変更は変更管理プロセスに乗せる、現場の声を拾う窓口を一本化するという流れを示す図

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

要件定義の段階で認識のずれそのものを減らす具体的な進め方は、要件定義でつまずかないヒアリングのコツにまとめています。

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

保守を続ける？作り変える？判断に迷ったときの考え方

「保守費用が高いから刷新する」という単純な判断ではなく、保守費用・改修のしにくさ・事業への影響の3つを合わせて見るのが実務的です。

前述の経済産業省DXレポートでは、稼働年数が古いシステムほど老朽化・ブラックボックス化が進みやすいという実態が示されていますが、「稼働◯年を超えたら刷新すべき」という一律の基準があるわけではありません。年数だけでなく、次の3つの問いで状況を整理すると、判断しやすくなります。

保守費用は、事業の成長に見合っているか：売上や取引件数が増えているのに、保守費用がそれ以上のペースで膨らんでいないか。システムの複雑化が事業の足を引っ張り始めているサインです
軽微な改修にも、想定以上の時間がかかっていないか：簡単なはずの仕様変更のたびに、影響範囲の調査に時間がかかる。これは設計のブラックボックス化が進んでいるサインです
保守を依頼できる会社が、実質1社に固定されていないか：前述のベンダーロックイン状態が続くと、値上げ交渉の余地もなくなり、費用が下がりにくくなります

この3つのうち複数に心当たりがある場合は、部分的な作り直し（段階的リプレース）を含めて検討する時期かもしれません。全面的な作り直しでなくても、負荷の大きい機能だけを新しい設計に置き換える、といった選択肢もあります。業務を止めずに段階的に移行する進め方は、システムリプレース開発で詳しく紹介しています。

保守を続けるか作り変えるかの判断フロー：保守費用は事業成長に見合っているか、軽微な改修に想定以上の時間がかかっていないか、保守を頼める会社が実質1社に固定されていないかの3つの問いを確認し、複数該当する場合は段階的リプレースを検討する

保守契約の妥当性、チェックリストで確認する

今の保守契約、あるいはこれから結ぶ保守契約が妥当かどうかは、次の項目で確認できます。

年間保守費用の算出根拠（何にいくらかかっているか）を開発会社が説明できるか
「軽微な修正」の対象範囲と上限時間が契約書・見積書に明記されているか
ソースコード・設計書の閲覧権限が自社にもあるか（ベンダーロックインの回避）
障害発生時の 初動対応の目標時間（SLA） が定義されているか
保守対応が複数名の体制で行われているか（担当者の退職リスクへの備え）
直近半年〜1年の 対応実績（件数・時間） を確認できるか（契約形態の見直し材料になる）
契約終了時の引き継ぎ手順が取り決められているか

該当しない項目が多いほど、保守費用の妥当性を判断する材料が不足している状態です。次回の契約更新のタイミングで、これらの項目を開発会社に確認することをおすすめします。

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

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

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

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

Q. 保守契約は定額制と従量制、どちらを選べばよいですか？

A. システムの稼働状況によります。リリース直後で不具合や改善要望が多い時期は、対応範囲が読みやすい定額制が向いています。安定稼働後で月1〜2回程度の対応で足りる場合は、従量制やチケット制の方が費用を抑えられることが多いです。契約更新のタイミングで、直近の対応実績（件数・時間）を確認し、実態に合った形態か見直すことをおすすめします。

Q. 保守費用が高いと感じたら、システムを刷新すべきですか？

A. 費用の高さだけで判断するのではなく、「事業の成長に見合っているか」「軽微な改修に想定以上の時間がかかっていないか」「保守を頼める会社が実質1社に固定されていないか」の3点を確認することをおすすめします。複数に該当する場合は、全面刷新でなくても、負荷の大きい機能だけを段階的に作り直す選択肢もあります。