レガシーシステムの保守・運用費は、方式や規模によって変わります。自社スクラッチでは初期開発費の年5〜20%が相場で、カスタマイズ率が50%を超えると総費用が予算の2〜3倍になる場合もあります。SaaSやパッケージへ乗り換えると費用構造が変わるため、稼働後5〜10年のTCOで比べます。
この記事は、経営層や情報システム部門が予算を策定する時点で知りたい、乗り換えで保守費が下がるかに絞って扱います。レガシーシステムの見直しには似た言葉が多く、『レガシーシステムのモダナイゼーション』の記事は、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレイスの技術手法を扱います。
『レガシーシステム刷新』の記事は経営層の投資判断や稟議を、『レガシーシステム更改』の記事は契約満了やEOS/EOLなどの外部期限を扱います。『レガシーシステムリニューアル』の記事は顧客体験、『レガシーシステムリアーキテクチャ』の記事は構造の技術的な深掘りが中心です。開発期間や技術手法は、姉妹記事に譲ります。
▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド
レガシーシステム刷新の費用の考え方や見積もりの注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
▼見積依頼前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
自社スクラッチ維持とSaaS・パッケージ乗り換えの保守費用構造の違い
自社スクラッチで構築したシステムの保守・運用費は、一般に初期開発費の年間5〜20%が相場です。たとえば開発費が1,000万円なら、年間50万〜200万円、月額約4万〜17万円が恒常的に発生します。
継ぎ足し開発を重ねてスパゲッティコード化すると、軽微な修正でも影響範囲の調査に工数と費用がかかり、保守費用は年々増える傾向があります。
一方で、SaaS・パッケージへの乗り換えでは、自社で保守するモデルから、ベンダーの保守サービスを利用するモデルへ費用構造が変わります。そのため、保守費用の見積もりも、ビルド・バイ判断で前提となるモデルを決めてから始めます。
自社スクラッチ保守の費用相場と増加していく構造
自社スクラッチの保守費用を押し上げる要因は、年率だけではありません。たとえば、技術者の減少とベンダーへの依存も費用を押し上げます。
- 技術者の減少：古い言語や独自フレームワークに対応できる人が減り、人件費が保守費用に転嫁されます。
- ベンダーへの依存：長期運用でノウハウが社内に残らず、価格競争も働かないため、見積もりが年々高止まりする傾向があります。
ベンダー依存が長く続くと、そのベンダー以外ではシステムを扱えない状態に陥ることもあります。開発当初は妥当な費用でも、10年・20年の運用を経て想定を大きく超える負担になる構造こそが、リプレイス検討の出発点です。
SaaS/パッケージ乗り換え後の費用構造（サブスクリプション・ライセンス・サポート）
乗り換え後の中心費用は、SaaSのサブスクリプション、またはオンプレミス型パッケージの買い切りライセンスです。
- SaaS：月額課金で、1ユーザーあたり数千円〜数万円です。
- オンプレミス型パッケージ：買い切りのライセンス費用が中心です。
SaaSでは、インフラ維持費が料金に含まれるため、自社でハードウェアを管理・更新するコストがなくなります。また、保守料にはOS更新や法改正への対応が含まれることが多く、都度の追加開発や数年ごとの大規模改修を減らせます。
ただし、独自業務を製品に合わせられず追加カスタマイズする場合は、機能1件あたり100万〜1,000万円程度かかることがあります。そのため、標準機能に業務を合わせるFit to Standardを徹底できなければ、乗り換えによる費用削減の効果は薄れます。
乗り換え後の費用内訳とTCO（総所有コスト）比較
リプレイスの妥当性は、初期導入費だけでなく、稼働後5〜10年間の累計投資額であるTCOで比べます。費用の幅は企業規模によって大きく変わるため、規模ごとの目安を次に示します。
- 小規模（50名以下）：100万〜500万円。主にSaaS型クラウドパッケージを利用します。
- 中規模（51〜300名）：500万〜5,000万円。パッケージ導入と部分的なカスタマイズが中心です。
- 大規模（301名以上）：5,000万円〜数億円以上です。
パッケージは基本機能が実装済みのため、フルスクラッチ開発の1/3〜1/2程度で導入できることがあります。特に初期費用の面では、乗り換えが有利なケースが多くあります。
SaaSの「逆転現象」と中長期TCOの見極め方
SaaSは初期費用が数万〜数十万円程度と安価です。一方で、長期利用では累積料金がスクラッチ開発の初期投資を上回る「逆転現象」が起きる場合があります。
直接の支払い額だけを見ると、長期利用でスクラッチが割安に見える局面もあります。ただし、間接効果も含めると、中長期TCOは抑えられやすい傾向があります。
- 人件費：インフラ保守担当者の人件費削減を含めます。
- 機会損失：システムダウンによる損失の回避を考慮します。
- 法改正対応：対応工数の削減分も比較の対象です。
ROI（投資回収期間）は1.5〜4年程度が一般的な目安とされています。事例では、総額800万円の投資を2年で回収する見込みの企業もあります。
ビルド・バイ判断では、単年度の支払額ではなく、5〜10年の時間軸と間接効果を含めて比べます。
カスタマイズが費用を膨張させる「カスタマイズの罠」
SaaS・パッケージの費用削減効果は、標準機能を活用できる範囲に比例します。その前提を軽視すると、乗り換え後の保守・運用費が想定を超えることがあります。
カスタマイズ率50%超で総費用が2〜3倍に膨らむ実態
カスタマイズを広げると、導入時の出費が膨らむだけでなく、稼働後の保守費も引きずられて増えます。
- 費用の膨張：カスタマイズ率が50%を超えると、総費用が当初予算の2〜3倍になるケースも珍しくないとされています。
- 保守費への波及：影響は初期開発費にとどまらず、その後の保守・運用費にも及びます。
- サポート対象：カスタマイズ部分は標準保守・更新の対象外が多く、担当先へ継続発注すると、保守費がスクラッチ同様に戻る場合があります。
- 上限の合意：費用削減の目的を失わないよう、要件定義の時点で、カスタマイズの範囲を社内で合意します。
Fit to Standardを保守運用フェーズでも維持する重要性
導入後も標準機能を中心に運用するには、個別要望や製品更新への対応方針を、あらかじめ定めておく必要があります。
- 方針の継続：Fit to Standardは導入時だけでなく、稼働後の保守運用でも続けます。
- 個別要望への対応：要望のたびにカスタマイズすると、数年後に構成が複雑になり、保守費用が増加します。
- 定期的な見直し：更新時の整合性確認にも費用がかかります。必要な差分だけを残すルールを決めると、長期の運用費を抑えられます。
ベンダーロックインのコストリスクと回避策
レガシーシステムを長く使う企業が陥りやすいベンダーロックインは、リプレイス後の製品でも形を変えて再発するおそれがあります。
乗り換え先製品での新たなロックイン発生というリスク
旧システムのロックインを解消しても、新たな製品やSaaSに再び依存する構図には注意が必要です。
開発から保守まで特定のベンダーや製品に依存すると、社内にノウハウが残りません。その結果、価格競争が働かず、保守料や追加開発費が高止まりします。この点は、自社スクラッチと本質的に同じです。
選定時に契約条件、データ所有権、解約時のデータ取り出し可否を確かめておかないと、数年後に身動きが取れなくなる場合があります。
「連携の余白」の確保による将来のロックインコストの抑制
将来のロックインを避けるには、RFPや設計の段階で、他システムとの連携余地を確保しておきます。
- CSVエクスポート：データを取り出せる機能の有無。
- API連携：他システムと連携できる機能の有無。
データをいつでも取り出せれば、別の製品へ移る際の再移行費（数百万円の場合もあります）を抑えられます。契約時には効果が見えにくいものの、連携の余白は、5年後・10年後の見直しに備える投資です。また、製品選定では、機能だけでなくデータポータビリティも評価項目に含めます。
ランニングコストを最適化する視点
保守・運用費を単純に削るのではなく、乗り換えで得られるはずのコストメリットを維持する視点が、長期的な費用対効果を高めます。
ハイブリッドアプローチによるコスト最適配分
すべての業務を一つの製品に統一せず、標準化しやすい領域はパッケージやSaaSに任せます。一方で、競争優位につながる独自性の高い領域は、自社開発で維持します。
この分け方は、保守・運用費の最適化に有効です。保守の対象を絞り、独自の強みが必要な部分にリソースを集中できるためです。業務領域ごとにビルド・バイ判断を使い分けることが、費用を合理的な水準に抑える現実的な方法です。
予算策定段階からTCOで判断する重要性
費用対効果を高めるには、企画の段階から、初期費用と5〜10年のランニングコストを合算したTCOで判断します。
初期費用だけで選ぶと、カスタマイズや乗り換え後の追加開発費が積み上がることがあります。結果として、スクラッチを維持した場合と変わらない費用構造になるケースもあります。
予算には、初期費用やカスタマイズ費用に加えて、サブスクリプション・ライセンス費用と将来の再乗り換え費用も含めます。そのうえで、ビルド・バイ判断と合わせてTCOを試算することが、ランニングコストの最適化につながります。
まとめ
スクラッチ維持とSaaS等への乗り換えについて、費用構造やTCOから、カスタマイズ、ロックイン対策、運用費の最適化まで、順に見てきました。
自社スクラッチの保守費用は、初期開発費の年間5〜20%が相場です。SaaS・パッケージは、フルスクラッチの1/3〜1/2程度で導入できる一方、カスタマイズ率50%超では総費用が2〜3倍に膨らむリスクがあります。
ROIの目安は1.5〜4年です。人件費削減や機会損失の回避も含めて、中長期TCOで判断します。
乗り換え先でのロックインを避けるには、データエクスポートやAPI連携の余地を確保します。また、初期費用だけでなく数年単位でTCOを試算し、Fit to Standardを維持できる開発パートナーに相談することも選択肢です。
▼全体ガイドの記事
・レガシーシステムリプレイスの完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。