【発注前】システム保守費用の相場15〜20%、IPA基準の根拠は示されず

システム開発では、初期費用の話は熱心に詰めるのに、保守費になると「まあ、それは追々」となりがちです。気持ちはよく分かります。作る話は楽しいし、保守費は何に払っているのか分かりにくい。

ただ、3年動かせば保守費の累計が初期費用の半分に届くことも珍しくありません。発注前に決着をつけておくべき論点です。この記事では、相場の数字と、その数字を額面どおり受け取ってはいけない理由を整理します。

まず数字：年間で開発費の15〜20%が中心

調べると、こういうレンジが出てきます。

金額でいうと、1,000万円で開発したシステムなら年間150〜200万円が一例として挙げられます。月額ベースでは、中小企業向けの小規模システムで月3〜10万円、中規模で月10〜30万円、大規模になると月30万円以上、というのが目安です。

ここで気づいてほしいのですが、下は5%、上は30%。6倍の開きがあります。 相場表としては、正直あまり役に立ちません。

「IPA基準で15〜20%」の出典を当たってみた

この比率を調べていると、「IPA（情報処理推進機構）の統計に基づく」「IPA基準で15〜20%」と書いている記事に何度か行き当たります。公的機関の名前が出てくると、急に信用したくなりますよね。私もそう思って、出典を確認しにいきました。

結果を先に書きます。根拠として示された図表番号やページ番号は、確認できた記事のどれにも書かれていませんでした。

IPAが公開している「ソフトウェア開発分析データ集」の説明ページで、分析対象として挙げられているのはこれです。

工数、工期、規模、生産性、信頼性等

——ソフトウェア開発分析データ集2022（IPA）（2026年8月21日閲覧）

保守・運用という語が出てきません。データ集の紹介ページにも「5,546プロジェクトの定量データからソフトウェアの信頼性を中心に分析」とあり、集めているのは開発プロジェクトの実績データです。リリース後の不具合密度は扱われていますが、それは信頼性の指標であって、保守費が開発費の何％かという話ではありません。

念のため補足すると、私はデータ集の全文を読み切ったわけではないので、「IPAのどこにも保守費比率は載っていない」と断定はしません。ただ、公開ページで説明されている資料の性格からして、保守費比率の一次資料として引くのは無理がある——これは言えます。もし根拠があるなら、図表番号まで示せるはずです。

つまり15〜20%という数字は、業界の経験則としては広く共有されているが、公的な統計に裏打ちされた基準ではない。この前提で扱ったほうが安全です。数字自体を否定したいのではなく、「公的基準だから交渉の余地がない」と言われたら、それは違う、という話です。

なぜ、これほど幅があるのか

答えは単純で、「保守」という言葉が指す範囲が会社ごとに違うからです。

同じ「保守費 月10万円」でも、サーバー代と監視と障害対応と月5時間分の改修まで全部入っている会社もあれば、不具合が出たときに直すだけ、という会社もある。前者と後者を「率」で比べても意味がないわけです。

運用と保守は、本来は別物

用語としても分かれています。

• 運用 — 稼働状況の監視、トラブル対応、定例のアップデートやセキュリティパッチ適用、バックアップと情報管理。日常的にシステムを回し続ける仕事
• 保守 — 不具合やバグの修正、OS更新に合わせた調整、ユーザーの要望に応じた機能追加。機能を維持・改善する仕事

保守はさらに、適応的保守（OS等の更新への追随）、完全化保守（機能追加や性能向上）、予防的保守（障害を未然に防ぐ）、緊急保守（重大障害への対応）などに分類されます。

見積書ではこれらが「運用保守費 一式」とまとめられがちです。まとめること自体が悪いのではなく、まとめた中身を聞かずに契約するのが問題だと思っています。

見積書の「保守費」を分解する

というわけで、率を見るより先にやるべきは分解です。次の項目のうち、どれが含まれていてどれが含まれていないかを確認してください。

特に「小規模改修が含まれるか」は後から効きます。含まれていない契約だと、「ボタンの文言を変えたい」程度でも都度見積もりになり、そのやり取りのほうが面倒になる。逆に月◯時間の枠があると、現場は気軽に相談できます。

見積書全般の読み方は見積書の読み方（5つの視点）にまとめました。保守費もこの延長で読めます。

率をやめて、人時で検算する

分解したら、次はその金額が何人分の仕事量なのかに置き換えます。率は比べられませんが、時間は比べられるからです。

やることは割り算ひとつです。

月額保守費 ÷ 想定の時間単価 ＝ 月に何時間分の人が張り付く前提か

時間単価は、国内の受託開発でよく使われる人月単価から逆算します。月160時間として、人月80万円なら時間単価5,000円、120万円なら7,500円といったところです。この単価はベンダーの体制や技術領域で変わるので、見積もりを出した相手に「御社の想定単価は何円ですか」と聞くのが早いです。答えられない会社は、正直あまり良い兆候ではありません。

1,000万円で作ったシステムに、率で当てはめてみます。

こう並べると、率の議論がぐっと現実的になります。15%＝月17〜25時間。人ひとりの3日分くらいです。ここに監視もサーバー代も障害対応も小規模改修も全部入るのだとしたら、改修に回せるのは実際には数時間でしょう。

だから検算の問いはこうなります。

• 月に何時間の改修を頼みたいか。四半期に一度、半日で終わる修正を頼む程度なら月2〜3時間で足ります。現場の要望を毎月拾って直していきたいなら、月10時間でも足りません
• その時間は、サーバー代と監視を引いた残りか。クラウド費が月3万円なら、12.5万円の保守費のうち人が動ける分は9.5万円＝月13〜19時間まで落ちます
• 障害が起きた月は、その時間をどこから捻出するのか。改修枠を食い潰すのか、別枠なのか

逆に言えば、率が20%を超えていても、月30時間の改修枠が本当に付いているなら高くありません。率が10%でも、実質が監視だけで改修は都度見積もりなら、思っていたものとは違うはずです。率だけを見て「相場より高い／安い」と判断するのが、いちばん危ない読み方です。

私が見積もりを受け取る側だったら、この割り算を1回やってから打ち合わせに行きます。「月◯時間分という理解で合っていますか」と聞くだけで、話が具体になります。

そもそも、その比率は「スクラッチで作った会社」の数字です

比率の話には、あまり言われていない前提があります。分母になる開発費が存在しないと、比率そのものが計算できないという前提です。

• スクラッチ開発……初期に開発費を払っているので、分母があります。15〜20%という数字が意味を持つのはここです
• パッケージ・SaaS……初期費用は導入設定ぶんで、機能の維持はベンダー側の月額利用料に入っています。払っているのは保守費ではなく利用料なので、「開発費の何%」という問いが成立しません
• 自社の情報システム部門が見ている既存システム……分母が何年も前の金額で、当時の見積書が残っていないこともあります

つまり「保守費は開発費の15〜20%」を自社に当てるには、まず自社がどの型なのかを決める必要があります。 SaaSを使っている会社が15%の話を読んで「うちは安すぎる／高すぎる」と判断しても、比べているものが違います。

型そのものの選び方はスクラッチ・パッケージ・SaaSの比較にまとめました。 型が決まっていないうちは、比率より先にそこを決めたほうが早いです。

なお、型をまたいで比べられるのは比率ではなく総額です。5年間で「初期＋保守」をいくら払うのかを並べると、スクラッチとSaaSを同じ物差しに乗せられます。

費用をいちばん動かすのはSLAの対応時間帯

分解のなかでも、金額へのインパクトが突出しているのがここです。

平日9〜18時対応なのか、24時間365日対応なのか。この違いは、ベンダー側から見ると「交代要員を常時確保し続けるかどうか」の違いで、その人件費がそのまま月額に乗ります。社内利用の業務システムなら平日日中で足りることが多く、ECサイトやSaaSのように止まると売上が直撃するものは24時間体制が要る、という切り分けが基本です。

中小企業の一般的な目安としては、営業時間内（平日9〜18時）の稼働率99.5%、障害対応の着手まで2時間以内、復旧目標（RTO）24時間以内、といった水準が挙げられます。

「24時間365日対応」の落とし穴

ここは強調しておきたいところです。「24時間365日対応」という表記の実態は、会社によってかなり違います。

夜間は受付だけで、実際の復旧作業は翌営業日の朝から——という契約も普通にあります。つまり「24時間受付」と「24時間復旧対応」は別物。深夜2時に電話が繋がることと、深夜2時に直り始めることは、まったく違う話です。

私だったら、契約前にこの一点だけは口頭ではなく書面で確認します。「夜間に障害が起きた場合、御社は何時から作業を開始しますか」。この質問への答えが曖昧な会社は、実際に障害が起きたときも曖昧です。

保守費を抑えたいときに考えること

削り方には、良い削り方と悪い削り方があります。

良い削り方は、要件を落とすことです。24時間対応をやめて平日日中にする。監視の粒度を下げる。使わない機能を減らして保守対象そのものを小さくする。いずれも「何を諦めるか」を自分で決めているので、後で困りません。

悪い削り方は、保守契約を結ばないことです。「壊れたときに都度お願いすればいい」は一見合理的に見えますが、都度対応は優先度が下がりますし、単価も高くなります。何より、作った会社が体制を維持していない状態になりやすい。数年後に改修を頼もうとしたら担当者がいない、というのが典型的な結末です。

保守費込みで3年・5年の総額を見て判断する——業務システムの費用を機能別に分解するでも触れた総保有コストの考え方が、ここでも効きます。

契約前に聞く6つの質問

長くなったので、そのまま使える形にまとめます。

1. この保守費に、サーバー費・ライセンス費は含まれますか
2. 障害対応の時間帯と、着手までの目安時間はどうなっていますか
3. 夜間・休日は「受付」までですか、「復旧作業」まで含みますか
4. 小規模な改修は月何時間まで含まれますか
5. 契約期間と、値上げがあり得る条件を教えてください
6. この月額は、御社の想定単価だと月何時間分の作業に当たりますか

5つ目を入れているのは、数年後に「体制強化のため」として保守費の改定を持ちかけられる、という話がネット上の相談や解説記事でも繰り返し出てくるからです。あらかじめ条件を明示してもらっておくほうが、お互い健全だと思います。

6つ目は、ひとつ前の章でやった検算をそのまま相手にぶつける質問です。ここで詰まる会社は、社内でも原価を把握できていない可能性があります。

自社のケースで初期費用と保守費がどの程度になるかを先に把握したい方は、作りたいものを入力するとAIが約3分で概算を出すAI見積もりを無料公開しています。相場観をつかむだけの利用でも構いません。

---

出典（2026年8月時点。相場は調査・出典により幅があります）

• ソフトウェア開発分析データ集2022（IPA 独立行政法人情報処理推進機構）（2026年8月21日閲覧。分析対象は工数・工期・規模・生産性・信頼性等）
• システム開発の保守費用相場・内訳具体例とコスト削減のポイント【2026年最新版】（システム幹事）
• システム保守費用の相場はいくら？月額2.5万〜、開発費15〜25%が目安【2026年版】（FUNBREW）
• システム保守費用の相場と算出方法【妥当性の判断基準】（秋霜堂）
• 運用保守とは？ システムの運用と保守の業務の違いを解説（情シスBlog）
• システム保守契約とは？契約形態・SLA・契約書の必須項目・費用相場【2026年版】（C3index）
• Webシステム保守の外注先選び｜契約前に確認すべき5つのSLA（みんなシステムズ）