システム保守費用の相場【2026年版】｜高すぎる3つのサイン・内訳分解・値上げ通知への対応と刷新判断

結論を先に：保守費の目安と「高すぎるサイン」3つ

毎月のシステム保守費が適正かどうかを判断するとき、まず押さえるべき目安は次の通りだ。

• 検算用の経験則：年間保守費は初期開発費の**15〜25%**程度に収まることが多い。ただしこれは公的統計ではなく、見積の違和感を見つけるための経験則である（詳細は第1章）。
• マクロの実態：経済産業省のDXレポートは、日本企業のIT関連費用の**80%が現行ビジネスの維持・運営（ラン・ザ・ビジネス）**に割り当てられていると指摘した（経済産業省 DXレポート、2018年）。JUASの企業IT動向調査でも、ランザビジネス予算の比率は2018年度77.5%→2024年度76.2%とほぼ横ばいで、7割台後半に張り付いたままである（JUAS 企業IT動向調査2025）。つまり「保守・維持にIT予算の大半を食われる」のは例外ではなく日本企業の標準状態であり、放置すれば下がらない。

そのうえで、金額の大小よりも先に確認すべき**「高すぎるサイン」は次の3つ**だ。

1. 内訳が「保守一式」のままで、作業項目・工数・単価に分解できない。分解できない費用は、適正かどうかの判断自体が不可能である。
2. 稼働5年以上で改修も報告もほとんどないのに、金額が一度も下がっていない。作業実態が縮小しているなら、費用も縮小しているべきだ。
3. 値上げ通知に根拠明細がなく、かつ自社がソースコード・設計書・環境アクセス権を持っていない。切替可能性がない状態での値上げ提示は、交渉ではなく通告である。

このいずれかに当てはまるなら、金額の妥当性以前に契約の構造に問題がある。本稿では、経験則の正しい使い方、内訳の分解方法、値上げ通知への対応手順、保守継続か刷新かの判断フロー、契約見直しチェックリストの順に、経営者・決裁者が自分で検証できる形で整理する。

---

目次

1. 保守費率の目安：「開発費の15〜25%」の正しい使い方
2. 保守費の内訳分解：何にいくら払っているのか
3. 経営者が知らない3つの落とし穴
4. 保守継続か、刷新か：判断フロー
5. 保守契約見直しチェックリスト
6. よくある質問（FAQ）
7. GXOに相談すべきタイミング

---

1. 保守費率の目安：「開発費の15〜25%」の正しい使い方

まず訂正：15〜25%はIPAの統計ではない

本記事の旧版では「IPA（独立行政法人 情報処理推進機構）のソフトウェア開発データ白書に、保守費用は初期開発費の15〜25%という統計がある」と説明していたが、この記述は不正確であり、本稿で訂正する。IPAの定量データ資料の系譜は「ソフトウェア開発データ白書」から「ソフトウェア開発分析データ集」へ引き継がれ、最新版は5,546プロジェクトの定量データを収録したソフトウェア開発分析データ集2022である。同資料は開発プロジェクトの規模・工数・信頼性を中心に分析したものであり、保守費用を開発費比率で示す相場統計は含まれていない。なおIPAは同ページで、事業終了に伴い分析データ集の今後の発行予定はないと明記しており、2022年版が事実上の最終版となる（確認日：2026年7月13日）。

つまり「IPAが保守費率の相場を公表している」という前提で書かれた解説は、出典の時点で誤りである。15〜25%という数字は、業界で広く使われてきた経験則として扱うのが正しい。

経験則としての15〜25%：検算テーブル

経験則である以上、この数字の使い道は「適正価格の証明」ではなく「見積の違和感の検出」に限られる。範囲から外れたら即座に不当なのではなく、外れた理由を内訳で説明できるかを確認するトリガーとして使う。

費率が変動する主な要因は、保守範囲の広さ（監視のみか、改修まで含むか）、SLAの厳しさ（平日日中か24時間365日か）、システムの古さ（技術的負債の蓄積度）、外部連携の多さである。GXOが見積レビューで使う検算の目安を示すと次の通りで、これも公的統計ではなく経験則である。

マクロデータが示す「保守費は放っておくと下がらない」構造

個別契約の検算とは別に、経営者が知っておくべきマクロの事実がある。JUASの企業IT動向調査によれば、IT予算のうち現行ビジネスの維持・運営に充てる「ランザビジネス予算」の比率は、2018年度77.5%、2021年度76.4%、2024年度76.2%と、6年間ほぼ動いていない。しかも同調査では、企業は毎回の調査で7割弱への引き下げ目標を掲げている（直近の3年後目標は68.2%）にもかかわらず、実績は7割台後半に張り付いたままだ（JUAS 企業IT動向調査2025 サマリー）。2026年4月公表の最新調査でも、物価高や人件費高騰を背景にランザビジネスのコストは増加していると総括されている（JUAS 企業IT動向調査報告書2026）。

これが意味するのは、「保守費は意思決定しない限り自然には下がらず、むしろ外部要因で上がっていく」ということだ。経済産業省のDXレポートは、既存システムを放置した場合、維持管理費が高額化してIT予算の9割以上を占めるに至るという技術的負債のシナリオを警告している（経済産業省 DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～）。自社のIT予算全体が適正水準かを確認したい場合は、IT予算の売上高比率の業界別ベンチマークを併せて参照してほしい。

セクションまとめ：15〜25%は「違和感検出のトリガー」として使い、適正の最終判断は内訳で行う。そしてマクロデータが示す通り、保守費は経営者が能動的に見直さない限り下がらない。

---

2. 保守費の内訳分解：何にいくら払っているのか

「月額20万円は高いのか」という問いに、金額だけで答えることはできない。監視だけで20万円なら高い可能性があり、障害一次対応・法改正対応・軽微改修・クラウド運用まで含むなら妥当な可能性がある。判断の出発点は、保守費を5つの費目に分解することだ。

保守費の5分解

このうち①〜④は作業や実費に対応するため検証可能だが、問題は⑤である。経産省DXレポートは技術的負債を「短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態」と定義している。古い言語やサポート切れ製品の上でシステムを動かし続けると、対応できる技術者の確保コストや調査工数が年々増え、同じ作業に対して支払う単価と時間が静かに上がっていく。見積書に「塩漬け維持費」という行は存在しないが、実態としては①〜③の工数の中に溶け込んで膨らんでいる。保守費が年々上がっているのに機能は何も増えていないなら、その差分はほぼこの費目だ。

工数×単価で検算する

分解の実務は「時間単価×工数」への還元である。月額15万円の契約なら、たとえば次のような明細に分解して、実績報告と突き合わせる。

単価の水準は地域・技術領域・ベンダー規模で幅があるため、この表の単価はあくまで例示である。重要なのは単価の絶対値ではなく、「月に何時間分の作業に対して払っているのか」が契約書と報告書から読み取れる状態になっているかだ。

SLAによる費用差

同じ作業内容でも、SLA（サービスレベル）の設定で費用は大きく変わる。次の水準は業界で一般に言われる目安であり、公的統計ではない。

ここで経営者が問うべきは「このシステムが夜間に止まったら、実際に何が起きるか」である。夜間バッチも夜間利用者もないシステムに24時間365日対応を付けているなら、それは削れる費用だ。逆に、EC・予約・生産管理のように停止が売上に直結するシステムで復旧目標が「翌営業日」なら、費用ではなくSLAの側を見直すべきである。

セクションまとめ：保守費は「障害対応・問い合わせ・法改正/環境対応・インフラ・塩漬け維持費」の5つに分解する。最後の塩漬け維持費だけは見積書に現れないが、年々の値上がりの正体はたいていここにある。

---

3. 経営者が知らない3つの落とし穴

落とし穴1：値上げ通知への対応手順を誤る

2024〜2026年にかけて、保守費の値上げ通知を受け取る企業は明確に増えている。JUASの調査では、2024年度計画でIT予算が増加した理由のトップが「円安・人件費高騰・ベンダー提供価格の値上げなどによる影響」であり、クラウド化によるランニングコスト上昇も上位に入る。つまり値上げ自体は業界全体の構造要因であり、「値上げ=不当」と決めつけて一律拒否するのは悪手だ。強硬に拒めば、ベンダー側の対応優先度が下がる、更新を断られる、といった形で自社が不利益を被る。

一方で、構造的な値上げ局面は「便乗値上げ」を見分けにくくする局面でもある。正しい対応手順は次の5ステップである。

1. 明細を求める。「何の原価が、いくらから、いくらに上がったのか」を費目別に提示してもらう。人件費単価の改定なのか、対象範囲の拡大なのか、クラウド実費の転嫁なのかで、交渉の余地はまったく異なる。
2. 実費転嫁と単価改定を分離する。クラウド利用料やライセンス費の実費上昇は受け入れるしかないが、実費はそもそも保守費と別建てにして透明化すべき費目だ。
3. 範囲・SLAとの交換条件を設計する。値上げを受けるなら、使っていないSLAの引き下げ、不要な費目の削除、月次報告の実質化など、対価側の改善とセットにする。
4. 相見積で市場水準を把握する。ただし後述のロックイン状態では相見積が機能しないことに注意する。
5. 金額が大きい場合は第三者レビューを挟む。値上げ後の年額×契約年数は経営インパクトのある投資判断であり、見積のセカンドオピニオンで妥当性を検証してから回答する価値がある。

最悪の対応は、明細を求めずにそのまま承認することと、感情的に拒否して関係を壊すことの両方である。値上げ通知は、契約をブラックボックスから明細ベースへ切り替える交渉の好機と捉えるのが正しい。

落とし穴2：保守契約のブラックボックス化

「保守一式・月額○○万円」という契約で、月次報告もなく、何の作業が行われたかの記録も残っていない——この状態を本稿では保守契約のブラックボックス化と呼ぶ。問題は割高かどうか以前に、適正かどうかを判断する材料が構造的に存在しないことだ。

ブラックボックス化は多くの場合、悪意ではなく惰性で進行する。開発直後は障害も改修も多く「一式」でも実態が伴っていたが、システムが安定するにつれ実作業は減り、金額だけが残る。発注側の担当者が異動・退職すると、契約内容を把握している人間が社内からいなくなり、「昔からこの金額だから」という理由だけで自動更新が続く。稼働から5年以上経った保守契約で、直近1年の作業実績を誰も説明できないなら、ブラックボックス化はすでに完成している。

解消の第一歩は、解約でも値切りでもなく可視化の要求である。「保守費用の内訳を、作業項目・想定工数・時間単価で提示してほしい」「月次で実施作業の報告をしてほしい」という要求は、契約継続を前提とした正当な依頼であり、誠実なベンダーなら応じられる。逆に、この要求に対して明細を出せない・出さないベンダーであれば、それ自体が契約を見直すべき強いシグナルとなる。

落とし穴3：ベンダーロックインで「切替不能」になる構造

保守費の交渉力は、突き詰めれば「他社に切り替えられるかどうか」で決まる。そして切替可能性は、金額交渉とは無関係に見える次の要素で静かに失われていく。

• ソースコードを自社が保有していない。契約上の著作権がベンダー帰属で、リポジトリへのアクセス権もない。
• 設計書・運用手順書が存在しない、または更新されていない。引き継ごうにも、現行仕様を知る手段がベンダー担当者の頭の中にしかない。
• 本番環境・クラウドアカウントの管理者権限がベンダー名義。契約を解消すると、自社システムに自社が入れない。
• 特定製品・独自フレームワークへの依存。そのベンダーしか扱えない技術の上に業務が載っている。

この状態で相見積を取っても、他社は「現状が分からないため見積不能」と回答するか、調査費込みの高額見積を出すしかない。結果として現行ベンダーの提示額が唯一の選択肢となり、値上げ通知を飲む以外の道がなくなる。落とし穴1と3は独立した問題ではなく、ロックインが完成しているほど値上げ交渉の余地は消える、という関係にある。

対策は、切替を実行するかどうかとは無関係に、切替「可能性」を常に維持しておくことだ。具体的には、ソースコード・設計書・環境アクセス権の所在を契約書で確認し、自社側に確保する。これは現ベンダーとの関係悪化を意味しない。むしろ「いつでも切り替えられるが、切り替えない」状態こそが、健全な価格と品質を維持する唯一の交渉基盤である。すでにロックインが進み、保守終了予告や障害多発と重なっている場合は、基幹システムの緊急対応（保守終了・障害多発）で整理している通り、時間との勝負になる前に脱出計画を立てるべきだ。

セクションまとめ：値上げ通知は明細要求から始める。ブラックボックス化は可視化要求で解く。そして交渉力の源泉は切替可能性であり、ソースコード・ドキュメント・環境の所在確認は保守費交渉そのものより先に行うべき打ち手である。

---

4. 保守継続か、刷新か：判断フロー

保守費の見直しには上限がある。どれだけ交渉しても、古いシステムを古いまま動かし続ける限り、第2章で述べた塩漬け維持費は増え続けるからだ。ある時点からは「保守費を下げる」ではなく「保守し続けるべきか、刷新すべきか」が正しい問いになる。

比較の基本式

判断の骨格はシンプルで、残存期間の総保守コストと刷新の総コストを同じ土俵で比較することである。

保守継続コスト = 年間保守費 × 残存想定年数 + EOL・障害・法改正の緊急対応リスク費
刷新コスト   = 刷新費用 + 新システムの年間保守費 × 同年数

たとえば年間保守費300万円のシステムをあと7年使う前提なら、単純計算で2,100万円を維持に支払う。保守費が年5%ずつ上がる想定ならさらに増える。この金額が刷新費用の相当部分に達するなら、刷新は「高い買い物」ではなく「同じ支出の振り替え」に近づく。刷新費用が何で決まるか、一括刷新と段階刷新でコスト構造がどう変わるかは、基幹刷新の費用の考え方で詳しく整理している。

ここで注意すべきは、単純な金額比較にリスク項と機会項を加えることだ。保守継続側には、EOL（サポート終了）到来時の強制刷新リスク、担当技術者の退職リスク、法改正に追従できず業務が止まるリスクが乗る。刷新側には、移行失敗リスクと並行運用コストが乗る一方、業務効率化・データ活用・属人化解消という将来価値が加わる。金額の式はあくまで下敷きであり、最終判断は次のフローで行う。

判断フロー：5つの質問

1. 基盤のEOLは何年後か？ OS・データベース・フレームワークのサポート終了が3年以内に確定しているなら、刷新はもはや選択ではなく期限のある義務である。
2. 年間保守費×残存年数は、想定刷新費用の何割か？ 5割を超えるなら刷新の本格検討ライン、同等以上なら保守継続の合理性はほぼない。
3. 業務側の要求に応えられているか？ 「システムが古いからできない」が理由の業務改善案件が年に複数あるなら、保守費に加えて機会損失を払い続けている。
4. 保守できる人材・ベンダーは持続するか？ 現行技術の担い手が市場から減っている場合、保守費単価は今後も上がる前提で計算すべきだ。
5. 刷新の受け皿はあるか？ ドキュメントもソースも整備されていない状態では刷新見積の精度も出ない。まず第3章の可視化・資産確保を済ませるのが先である。

質問1・2で刷新側に振れたなら、進め方の選択肢（一括再構築か、段階的モダナイゼーションか、パッケージ/SaaS移行か）を含めてレガシーシステム刷新の進め方を参照してほしい。逆に質問2で保守継続が合理的と出たなら、本稿第5章のチェックリストで契約の質を引き上げつつ使い切るのが正解であり、無理に刷新を急ぐ必要はない。

セクションまとめ：「年間保守費×残存年数」を刷新費用と並べた瞬間、保守継続は「安全な現状維持」ではなく「金額のついた投資判断」に変わる。EOLが3年以内なら検討を先送りする余地はない。

---

5. 保守契約見直しチェックリスト

契約更新の前に、次の項目を契約書・SLA・直近1年の報告書と突き合わせて確認する。3〜6ヶ月前に着手すれば、相見積や交渉の時間を確保できる。

SLA・対応範囲

• 対応時間帯と初動目標（駆けつけ/リモート、電話/メール）が明文化されているか
• 復旧目標（RTO）と実際の業務要件が釣り合っているか（過剰SLAは削減余地、過小SLAは事業リスク）
• 「軽微な修正」の定義（工数上限・対象範囲）が契約書に書かれているか
• 障害対応で「原因調査まで」か「修正・再発防止まで」かの線引きが明確か
• 法改正・外部サービス仕様変更への対応が保守範囲内か、別途見積か

費用構造

• 費用が作業項目・想定工数・単価に分解して提示されているか
• クラウド利用料・ライセンス費が保守費と分離され、実費が見えるか
• 月次報告に実施作業と工数実績が記載され、契約工数との乖離が分かるか
• 値上げ時の根拠提示・事前通知期間が契約に定められているか

資産・ロックイン対策

• ソースコードの著作権帰属と、自社のリポジトリアクセス権が確保されているか
• 設計書・運用手順書が現行仕様に追従して更新されているか
• 本番環境・クラウドアカウントの管理者権限を自社が保有しているか
• 契約終了時の引き継ぎ義務（成果物・期間・費用）が明記されているか

セキュリティ・事業継続

• セキュリティパッチの適用方針と適用実績が報告されているか
• バックアップの取得頻度と、復旧テストの実施実績があるか
• 脆弱性診断の実施有無（保守範囲か別枠か）が明確か

交渉の進め方——内訳開示の求め方、範囲の再定義、複数年契約の使い方、保守と改修の分離——はシステム保守契約の見直しガイドで手順化している。セキュリティ項目の検証を外部に依頼する場合の選択肢と費用感は脆弱性診断・ペネトレーションテストの比較ガイドを参照してほしい。

セクションまとめ：チェックリストの本質は「SLA・費用・資産・セキュリティの4面で、契約書と実態の乖離を見つける」ことにある。1項目でも「分からない」があるなら、それが次の更新交渉の議題である。

---

6. よくある質問（FAQ）

Q1. 保守費は毎年同じ金額で当然か？

当然ではない。作業実態が減っているなら下がる余地があり、逆にシステムの老朽化・人件費高騰・クラウド費上昇で上がる圧力もかかる。重要なのは金額の固定ではなく、毎年の更新時に工数実績と突き合わせて根拠を確認する運用である。稼働5年を超えたシステムでは技術的負債の影響で費率が25〜30%へ上がるケースもあるが、その場合こそ第4章の刷新比較を並走させるべきだ。

Q2. クラウドのシステムでも保守費率の考え方は同じか？

インフラの物理保守が不要になる分、保守契約の対象はアプリケーション保守（障害対応・改修・環境追従）に絞られる。経験則としてはアプリ保守のみで開発費の15〜20%程度が目安だが、クラウド利用料が別途実費で発生する点に注意が必要だ。保守費とクラウド実費を合算した「一式」契約は実費の変動が見えなくなるため、必ず分離して契約することを推奨する。

Q3. 保守契約を結ばずスポット対応にするのは合理的か？

利用頻度が低くビジネス影響の小さいシステムなら選択肢になり得る。ただしスポット対応の単価は保守契約時の1.5〜2倍程度かかるのが一般的な水準であり、障害時は対応開始までのリードタイムも保証されない。売上・業務に直結するシステムであれば、SLAを最小限に絞った保守契約を維持する方が総コスト・リスクともに小さいことが多い。

Q4. 保守費の値上げ通知が来た。最初にすべきことは？

回答期限の確認と、費目別の値上げ根拠明細の要求である。承認・拒否の判断はその後でよい。第3章で述べた通り、人件費・クラウド費の上昇は業界全体の実態（JUAS調査でもIT予算増加理由の最上位）であり、一律拒否は得策ではない。明細を得たうえで、実費転嫁の受け入れと引き換えに範囲・SLA・報告の質を改善させるのが定石だ。金額が大きければ回答前に第三者レビューを挟む。

Q5. 保守費用に補助金は使えるか？

既存システムの保守費用単体は原則として補助金の対象外である。一方、刷新・新規導入に伴う初年度保守費が対象経費に含められる制度はある。刷新判断とセットで検討する場合は中小企業向け補助金の完全ガイドで対象制度を確認してほしい。

Q6. 保守の内製化はどう判断すべきか？

外注保守費の年額が、保守を担えるエンジニア1名の年間人件費（採用・教育コスト込み）を明確に上回り、かつ改修需要が恒常的にあるなら検討に値する。ただし1名内製は退職で保守が止まる単一障害点にもなるため、完全内製よりも「一次対応と仕様把握は内製、専門対応は外部」というハイブリッドが現実的な解になりやすい。

---

7. GXOに相談すべきタイミング

本稿の枠組みで自社の保守契約を点検したうえで、次のいずれかに該当するなら、社内だけで結論を出す前に第三者の目を入れる価値がある。

• 値上げ通知への回答期限が迫っているが、提示額の妥当性を判断する材料が社内にない。現行契約と値上げ根拠を突き合わせ、受けるべき部分と交渉すべき部分を切り分ける必要がある局面だ。
• 「保守一式」の中身が誰にも説明できず、更新をこのまま続けてよいか不安がある。可視化の要求項目を整理してから交渉に臨む方が、確実に有利な条件を引き出せる。
• 年間保守費×残存年数を計算したら刷新費用に迫っており、継続か刷新かの経営判断が必要になった。この試算の精度を上げるには、現行システムの負債状況と刷新方式ごとの費用構造の両方を評価する必要がある。

GXOは開発会社であると同時に、他社見積・他社契約の第三者レビューを行っている。保守見積や値上げ提示の妥当性検証はシステム開発の見積レビュー（セカンドオピニオン）で、保守継続に見切りをつけた後の進め方はレガシーシステム刷新の支援内容で確認できる。どちらに該当するか判然としない段階の相談はお問い合わせ（無料相談）から受け付けている。自社に売り込む前提のない立場で、継続・交渉・刷新のどれが合理的かから一緒に整理する。

---

公式情報・出典（確認日：2026年7月13日）

• IPA ソフトウェア開発分析データ集（最新版は2022。IPAは事業終了に伴い今後の発行予定なしと明記）: https://www.ipa.go.jp/digital/software-survey/metrics/index.html
• IPA ソフトウェア開発分析データ集2022（5,546プロジェクトの定量データ・信頼性中心の分析）: https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html
• 経済産業省 DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～（2018年9月7日。IT関連費用の80%がラン・ザ・ビジネス、放置時は維持管理費がIT予算の9割以上に、技術的負債の定義）: https://www.meti.go.jp/policy/it_policy/dx/20180907_02.pdf
• JUAS 一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2025」サマリー（ランザビジネス予算比率76.2%〔2024年度〕、IT予算増加理由のトップは円安・人件費高騰・ベンダー提供価格の値上げ）: https://juas.or.jp/cms/media/2025/04/JUAS_IT2025summary.pdf
• JUAS「企業IT動向調査報告書2026」（2026年4月。物価高・人件費高騰を背景にランザビジネスコストが増加）: https://juas.or.jp/cms/media/2026/04/JUAS_IT2026.pdf
• ISO/IEC/IEEE 14764:2022 Software engineering — Software life cycle processes — Maintenance（保守の分類の国際規格）: https://www.iso.org/standard/80710.html

本稿の「開発費の15〜25%/年」および費率区分・SLA費用差・スポット単価倍率は、公的統計ではなくGXOが見積レビューで用いる経験則・業界で一般に言われる水準として記載した。個別の適正判断は、契約範囲・SLA・工数実績・システムの負債状況に基づいて行う。