受託開発の保守・運用費用は、初期開発費の年間5〜15%程度が目安です。システムの複雑さや対応範囲、サポート時間帯によって、最大20%程度まで変わります。
保守費の目安や費用に含まれる作業、契約の注意点、費用を抑える方法を順に見ていきます。全体像は受託開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・受託開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
受託開発における保守・運用費用の全体像
受託開発したシステムは、リリース後に保守・運用の段階へ移ります。初期開発費は一度きりですが、保守費は稼働中、毎月・毎年かかり続けます。
そのため発注時には、初期開発費がいくらかだけでなく、稼働後に毎年いくらかかるかも見通しておく必要があります。保守は開発ベンダーに委託するのが一般的ですが、契約内容や費用体系はベンダーごとに異なります。費用の構造を理解しないまま契約すると、予算を圧迫する追加請求につながることがあります。
受託開発で「作った後」の費用が重要になる理由
内製の場合は、保守・運用を自社のエンジニアが担います。そのため既存の人件費の範囲に収まりやすく、追加費用として意識されにくい面があります。
一方、受託開発では外部ベンダーに保守を委託するため、月額または年額の請求が発生します。しかも開発ベンダーはシステムの構造をよく理解しているので、他社へ保守を切り替えにくく、依存が続く場合があります。
この依存がある状態では、保守費用や対応範囲がベンダーの提示に左右されがちです。そのため契約時には、何にいくら請求されるか、どこから追加費用になるか、将来どう移管できるかを、ベンダーと具体的に詰めておく必要があります。
- 費用体系：月額・年額で何にいくら請求されるか
- 対応範囲：保守に含む作業と、追加費用になる作業の境界
- 切替の余地：将来の移管条件を契約段階で確認する
保守を後回しにすると、稼働後に不利な条件を受け入れる場合があります。開発と保守を一続きの長期の取り組みとして捉えておくと、費用面の失敗を避けやすくなります。
初期開発費に対する保守費の年率と月次費用の目安
保守費用の目安は、初期開発費とシステムの特性によって変わります。相場として示される金額にも幅があるため、下の目安を参考に考えるとよいでしょう。
- 一般的な目安：初期開発費の年間5〜15%。1,000万円なら年50万〜150万円、月数万〜十数万円程度
- 複雑なシステム：高度なカスタマイズ、複雑なレガシーコード、多数のAPI連携では最大20%程度
- 国内事例：開発費1,000万円のシステムで、運用・保守費が月額50万〜150万円
金額は、サポートの手厚さや24時間対応の有無、システムの複雑さで変わります。そのため、保守費の年率を計算し、自社の保守費が妥当かをベンダーと確認しておきましょう。年率を見ておくと、高すぎる費用や、対応が手薄なわりに安い費用を判断する手がかりになります。
保守・運用費用に含まれる作業とインフラ費用との違い
保守費用の内訳を分けて把握すると、予算の見落としを防げます。特に混同しやすいのが保守費用とインフラ費用（クラウド利用料）ですが、両者は性質が異なります。見積もりや予算計画で区別しないと、予想外の出費につながります。
保守費用に含まれる3つの作業内容
受託開発の保守・運用費用は、主に次の作業に分かれます。
- ソフトウェア運用保守：保守の中心となる作業。不具合対応や軽微な修正、機能改善、更新、問い合わせ対応
- ハードウェア運用保守：サーバー管理、故障・ネットワーク障害対応、バックアップや復旧
- サービス委託：ヘルプデスク運営やユーザーサポートなどの実務
ソフトウェア保守には、OSやミドルウェアの更新、法改正に伴う改修も含まれます。一方、クラウド環境では、ハードウェアの部分がインフラ費用と一体になる場合もあります。
発注者と開発ベンダーは、契約でどの作業まで保守費に含み、どこから追加費用になるかを決めておく必要があります。たとえば、軽微な修正は含むが新機能は別料金、問い合わせ対応は月◯件まで、といった形で線を引きます。線引きが曖昧だと、依頼のたびに範囲外として追加請求され、想定外の費用が積み上がることがあります。
保守費用とインフラ費用（クラウド利用料）の区別
保守費用は技術者の作業に払うもので、インフラ費用はクラウドやライセンスの利用に払うものです。支払う中身が違うため、見積もりでは両者を分けて確認します。
- 保守費用：技術者の作業やサポート体制を維持する人件費・サービス費
- インフラ費用：クラウドやライセンスなどの利用料。AWS、Azure、Google Cloudの利用料やソフトウェアライセンス料は、場所代・ツール代にあたる
保守費が月額10万円でも、クラウド利用料が別途、月額数万円〜数十万円かかる場合があります。特に従量課金型では、アクセス数に応じて費用が変わるため、トラフィックが急増するとインフラ費用が上がるリスクもあります。
IT予算では、保守費とインフラ費を別枠で計上し、合算して毎月のランニングコストを把握しておきましょう。見積もりの段階で、インフラ費が保守費に含まれているかを確かめておくことも大切です。
受託開発ならではの保守の論点
内製と共通する論点もありますが、受託開発には外部ベンダーへの委託ならではの課題があります。主な論点は、依存の管理、対応範囲の取り決め、将来の保守体制の見直しです。これらは費用だけでなく、長期運用の持続性にも関わります。
ベンダーロックインのリスクと回避策
他社で保守・改修できず、特定のベンダーに依存し続ける状態を、ベンダーロックインといいます。独自業務向けのスクラッチ開発や追加開発で複雑化したシステムに起きやすく、他社は構造が分からず保守を断ることがあります。そのため、値上げや高額な改修でも言い値を受け入れる場合があります。
回避策は、開発を委託するときに決めておきます。他社が保守を引き継げるように、次のような条件を契約に含めておくのが基本です。
- 納品：ソースコードや設計書を受け取り、発注者側で保管する
- 契約条件：著作権の譲渡と、第三者への再委託・移管の明記
- 技術選定：特殊な独自技術に過度に依存せず、標準的な技術を使う
これらを開発の入り口で決めておくかどうかで、将来の保守における交渉力が変わります。稼働後では手遅れになりやすいため、早い段階での備えが欠かせません。
SLAと保守契約範囲の明文化
「保守をお願いします」とだけ伝えて契約すると、対応範囲が曖昧なまま進んでしまうことがあります。そこでSLA（サービスレベルアグリーメント＝サービス品質保証）を使い、範囲とサービス水準を文書に書き表します。SLAで決めておきたいのは、障害時の初動、復旧目標、対応時間帯、定額の範囲の4点です。
- 初動対応：障害発生から何時間以内に対応を始めるか
- 復旧目標：暫定復旧までの目標時間
- 対応時間：平日日中のみか、24時間365日か
- 定額範囲：月の問い合わせ・修正件数の上限
数値で決めておくと認識の違いを防げ、費用に見合ったサービスも受けやすくなります。SLAがないと、緊急時や些細な依頼が範囲外とされ、追加の見積もりで費用も品質も不透明になりがちです。
課金の方式には、月額定額制と、インシデントごとに費用が発生する従量課金制があります。システムの重要度と、障害時に求める対応速度を踏まえて、どちらが合うかを判断します。
内製保守への切替と、開発・保守ベンダーを分ける場合の注意
保守費用を抑える方法には、内製化と、開発会社とは別の会社への移管があります。どちらも費用以外の負担がかかるため、その中身も確かめておく必要があります。
- 内製保守：外注費を抑えられ、柔軟な改善もできる一方、体制づくりが必要
- 別会社へ移管：費用競争が働く一方、移管の手間や費用がかかる場合がある
内製で保守するには技術力が求められます。さらに、24時間や夜間の対応による負荷や、IT人材の確保・育成にかかる時間と費用も、あらかじめ見込んでおく必要があります。
担当者に知識が偏ると、退職後に運用が回らなくなる属人化のリスクもあります。そのため内製化は、外注費だけでなく体制づくりを含めて判断することが大切です。
別会社は、設計思想や開発の背景を一から解析する必要があるため、保守を敬遠することがあります。引き受けてもらえても、過去のプログラムを理解するための初期費用は、通常は別途かかります。ベンダーを分ける場合は、その引き継ぎ費用も見込んでおきましょう。
ソースコードや設計書の納品と、標準的な技術の採用は、将来の選択肢を残すことにつながります。
保守・運用費用が想定より膨らむ主な原因
保守・運用費用が想定を超えて膨らむことは、珍しくありません。主な原因は2つあり、発注や契約の段階で工夫すると、ある程度抑えられます。まずは原因を知り、予防策を検討しましょう。
ブラックボックス化と技術的負債
保守費用が膨らむ原因の一つは、ブラックボックス化と技術的負債の蓄積です。ブラックボックス化とは、システムの内部構造や仕様が外から分からない状態のことです。
設計書が古いまま場当たり的な改修を重ねると、当初の設計から複雑化し、保守のたびに構造を理解し直す必要が生じます。その理解にかかる時間は費用に上乗せされ、簡単に見える修正でも工数が増えます。
また、技術的負債とは、短期の速度を優先して品質を犠牲にした結果、将来の改修が必要になる問題です。防ぐには、次のような対策が考えられます。
- 設計書を維持する：開発時に整備し、稼働後も最新に保つ作業を契約に含める
- 構造を健全に保つ：改修のたびに場当たり的な対応で済ませない
品質を省いた開発は、短期的には安くても、長期的には保守費の高騰につながることがあります。だからこそ、発注者とベンダーの双方が、システムの構造を保つ意識を持つ必要があります。
SLA未整備による対応範囲の認識齟齬
保守費用が膨らむ原因には、SLAが整っていないことによる対応範囲の認識違いもあります。「保守一式」とだけ記載され、内訳や範囲が不明確な契約は、後のトラブルにつながります。
発注者は軽微な修正も含まれると考える一方、ベンダーは範囲外として追加費用を求めます。この食い違いは日常的に起こるため、小さな改修でも追加の見積もりが予算を圧迫します。
対応範囲を明確にするには、契約書に次の内容を盛り込むことが有効です。
- 作業内訳：保守費用で何を行い、何にいくらかかるかを示す
- 定額範囲：障害対応や監視、軽微な改修の上限を決める
- 超過単価：範囲を超えた改修の単価の明記
たとえば、障害対応を◯時間分、定例の稼働監視、月◯件までの軽微な改修まで含め、超過分は◯円/人日とする形が考えられます。内訳が分かれば、追加費用の妥当性を判断でき、予算も見通しやすくなります。契約の透明性を高めることが、想定外の費用膨張を防ぐ方法です。
保守・運用費用を適正化するためのポイント
保守・運用費用は、発注者の取り組みで適正な水準に調整できます。初期費用の安さに惑わされず、長期の費用を見たうえで、契約前に必要な条件を決めておきましょう。
TCO（総所有コスト）での比較検討
TCO（Total Cost of Ownership＝総所有コスト）は、システムの導入から運用まで、ライフサイクル全体にかかる費用の総額です。その中身は、初期開発費、運用費、将来費用の3つです。
- 初期開発費：導入時の開発費用
- 運用費：数年間の保守・運用費とインフラ費
- 将来費用：将来的に見込む改修費
初期費用だけで最安のベンダーを選ぶと、保守が手薄なために追加費用が増える場合があります。また、ブラックボックス化しやすい構造では、数年後の改修費が高騰し、総額が高くなることもあります。
ベンダーを選ぶときは、「5年間運用した場合の総額」を試算して、TCOで比較しましょう。見積もりでは、初期費用に加えて年間保守費、インフラ費、想定改修費も提示してもらいます。長期の総所有コストで判断すると、保守を含む支出を適正に保つことにつながります。
契約前の取り決めと相見積もり
保守費用の水準は、契約前の取り決めで大きく変わります。相場から極端に安い見積もりは、スキルの低い人員や狭い対応範囲、後からの追加費用を示している可能性があります。見積もりを比べるときは、次の方法と取り決めが有効です。
- 相見積もり：保守を含めて3〜4社程度から取り、費用の妥当性を比べる
- 契約条件：責任範囲、再委託、損害賠償、著作権、ソースコードの帰属の取り決め
複数社を比べると相場観が身につき、極端に高い提案や安い提案を見分けられるようになります。取り決めを事前に固めておくと、将来のトラブルや追加費用を防ぎやすくなります。
問題が起きてからでは、発注者に不利な条件を受け入れざるを得ないことがあります。長期にわたり適正なコストで運用できるかは、契約前の取り決めで決まります。保守費用は、作る前に設計しておくという意識が第一歩になります。
まとめ
発注者の視点では、保守・運用費用を稼働後も続くランニングコストとして捉えることが大切です。
受託開発の保守・運用費用は、初期開発費の年間5〜15%程度が目安です。複雑なシステムでは最大20%程度になる場合があり、稼働中は継続的に費用がかかります。
費用を管理するには、保守とインフラ費を分けて把握し、ソースコードや設計書の納品、著作権の扱いを開発時に決めてロックインを避けます。さらに、SLAで対応範囲と水準を明確にしておくことも欠かせません。
ブラックボックス化やSLAの未整備を防ぎ、初期費用ではなくTCOで複数社を比較すると、長期的に納得できるコストで運用しやすくなります。そして、保守は発注段階から準備することが、受託開発を成功させる鍵になります。
▼全体ガイドの記事
・受託開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。