受託開発の保守・運用費用・ランニングコストについて

外部のシステム開発会社に開発を委託する「受託開発」を検討するとき、多くの発注担当者は初期の開発費用ばかりに目を向けがちです。しかし、システムは納品されて終わりではなく、そこから何年にもわたって運用し、保守し続けていくものです。むしろ、システムのライフサイクル全体で見れば、初期開発費よりも稼働後にかかる保守・運用費用の合計のほうが大きくなることも珍しくありません。「開発費の見積もりは取ったが、その後のランニングコストは考えていなかった」「保守契約の内容が曖昧で、ちょっとした修正のたびに追加費用を請求される」といった悩みは、受託開発を発注した企業が後から直面しがちな典型的な落とし穴です。

本記事では、システム開発を外部に委託する「受託開発」という発注形態における保守・運用費用・ランニングコストの考え方を、発注者の視点から体系的に解説します。初期開発費に対する保守費の相場、保守費用に含まれる作業とインフラ費用との違い、受託開発ならではのベンダーロックインやSLAといった論点、費用が想定より膨らむ原因、そして総所有コスト（TCO）で費用を適正化するためのポイントまでを、具体的な数字とともに整理しました。開発を委託する前の段階から「作った後の費用」を見据えて意思決定できる発注者になることを目指した内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・受託開発の完全ガイド

受託開発における保守・運用費用の全体像

受託開発で構築したシステムは、リリースした瞬間から保守・運用のフェーズに入ります。ここで発生する費用は、初期開発費のように一度きりの支出ではなく、システムが稼働し続ける限り毎月・毎年かかり続ける継続的なコストです。だからこそ、発注の意思決定は「初期開発費がいくらか」だけでなく、「稼働後に毎年いくらかかり続けるのか」まで見据えて行う必要があります。受託開発の場合、この保守・運用を開発したベンダーにそのまま委託するのが一般的ですが、その契約内容や費用体系はベンダーによって大きく異なります。発注者が保守・運用費用の構造を理解しないまま契約を結んでしまうと、後から予算を圧迫する追加請求に悩まされることになりかねません。

受託開発で「作った後」の費用が特に重要になるのには、明確な理由があります。自社で開発する内製の場合、保守・運用は自社のエンジニアが担当するため、費用は既存の人件費の範囲内に収まりやすく、追加コストとして意識されにくい面があります。しかし受託開発では、保守・運用も外部ベンダーに委託するため、その費用が明示的な月額・年額の請求として発生します。しかも、開発したベンダーはそのシステムの構造を最もよく理解しているため、保守を他社に切り替えるのが難しく、結果として特定のベンダーに依存し続ける構造になりやすいのです。この依存構造のもとでは、保守費用の水準や対応範囲がベンダー側の提示に大きく左右されます。だからこそ、発注者は開発を委託する契約の段階から、保守・運用フェーズの費用体系や対応範囲、そしてベンダーを切り替える余地までを見据えて交渉しておく必要があります。「まず開発を頼んで、保守のことは後で考える」という姿勢では、稼働後に不利な条件を飲まざるを得ない状況に陥りがちです。システムの発注は、開発と保守をセットでとらえる長期的な視点で臨むことが、費用面での失敗を避ける鍵になります。

受託開発したシステムの保守・運用費用は、一般的に「初期開発費用の年間5〜15%程度」が相場の目安とされています。たとえば初期開発費が1,000万円のシステムであれば、年間で50万〜150万円程度、月額換算で数万円〜十数万円程度が一つの基準になります。ただし、高度にカスタマイズされたシステムや、複雑なレガシーコードを抱えるシステム、外部のサードパーティAPIとの連携が多いシステムでは、年間の保守コストが初期開発費の最大20%程度にまで高騰する傾向があります。なお、国内の事例では「開発費1,000万円のシステムで、運用・保守費用が月額50万〜150万円かかる」というケースも報告されており、サポートの手厚さや対応時間帯（24時間対応かどうか）、システムの複雑さによって金額は大きく変動します。重要なのは、これらの相場感を持ったうえで、自社のシステムの保守費が妥当な水準に収まっているかをベンダーと確認することです。年率で何%に相当するのかを計算してみると、提示された保守費が高すぎないか、あるいは安すぎて対応が手薄になっていないかを判断する手がかりになります。

保守・運用費用に含まれる作業とインフラ費用との違い

受託開発の保守・運用費用を正しく理解するには、その中に何が含まれているのかを分解して把握することが欠かせません。発注者がよく混乱するのが、「保守費用」と「インフラ費用（クラウド利用料）」の違いです。この2つは性質がまったく異なる費用であり、見積もりや予算計画の段階で明確に区別しておかないと、予想外の出費に驚くことになります。ここでは、保守費用に含まれる作業内容と、インフラ費用との違いを整理します。

受託開発の保守・運用費用は、大きく3つの作業内容に分類できます。1つ目は「ソフトウェア運用保守費」で、これが保守費用の中心を占めます。具体的には、バグやトラブルへの対応、プログラムの軽微な修正、機能改善やバージョンアップ、OSやミドルウェアのアップデート対応、法改正に伴う改修、利用者からの問い合わせ対応などが含まれます。2つ目は「ハードウェア運用保守費」で、サーバーなどのハードウェアの管理、故障対応、ネットワーク障害への対応、データのバックアップや復旧作業などが該当します。クラウド環境が主流となった現在では、この部分がインフラ費用と一体化しているケースも増えています。3つ目は「サービス委託費」で、ヘルプデスクの運営やユーザーサポートなど、システム運営に付随する実務を委託する費用です。発注者が確認すべきなのは、契約している保守費用の中に、これらの作業のどこまでが含まれ、どこからが範囲外（追加費用）になるのかという線引きです。たとえば「軽微な修正は含むが、新機能の追加は別途見積もり」「問い合わせ対応は月◯件まで含む」といった具体的な範囲を、契約時に明確にしておくことが重要です。この線引きが曖昧なまま契約すると、日々発生する細かな依頼のたびに「それは範囲外です」と追加請求され、当初想定していなかった費用が積み上がっていきます。

保守費用とインフラ費用は、しばしば混同されますが、性質がまったく異なります。保守費用は「技術者の作業やサポート体制を維持するための人件費・サービス費」であるのに対し、AWSやAzure、Google Cloudといったクラウドのホスティング費用や、利用するソフトウェアのライセンス費用といったインフラ費用は、「純粋な場所代・ツール代」に該当します。言い換えれば、保守費用は人の稼働に対する対価、インフラ費用はコンピューティングリソースの利用料です。この2つを混同すると、予算計画で大きな見落としが生じます。たとえば「保守費用は月額10万円」という契約を結んでいても、それとは別にクラウドの利用料が月額数万円〜数十万円かかることを見込んでいなければ、実際の月次支出は想定を上回ってしまいます。特にアクセス数に応じて費用が変動する従量課金型のクラウドでは、トラフィックが急増した月にインフラ費用が跳ね上がるリスクもあります。発注者は、IT予算を計画する際に、保守費用（人の作業に対する費用）と、インフラ費用（クラウド利用料・ライセンス料といった場所代・ツール代）を別枠で計上し、両者を合算した総額で毎月のランニングコストを把握しておく必要があります。見積もりを受け取ったら、インフラ費用が保守費用に含まれているのか、それとも別途発生するのかを必ず確認しましょう。

受託開発ならではの保守の論点

保守・運用費用の論点は、内製と受託開発で共通する部分もありますが、外部ベンダーに委託する受託開発ならではの固有の論点があります。それが、ベンダーへの依存構造をどう管理するか、保守の対応範囲をどう取り決めるか、将来的に保守体制をどう見直すか、という問題です。これらは費用の多寡だけでなく、システムを長期的に持続可能な形で運用できるかどうかを左右する重要なテーマです。

受託開発の保守で最も注意すべきリスクが「ベンダーロックイン」です。これは、システムの保守・改修が特定のベンダーにしか対応できなくなり、その会社に依存し続けざるを得なくなる状態を指します。特に、独自の業務に合わせてゼロから作り込んだスクラッチ開発のシステムや、稼働後に追加開発を重ねて複雑化したシステムでは、開発したベンダー以外にはその内部構造が分からず、他社に保守を頼もうにも引き受け手が見つからない、という状況に陥りがちです。こうなると、保守費用の値上げや改修費の高額請求を提示されても、発注者は交渉の余地を失い、言い値を飲まざるを得なくなります。ベンダーロックインを回避するための現実的な対策は、開発を委託する契約の段階で手を打っておくことです。具体的には、ソースコードや設計ドキュメント、データベース定義書といった成果物を必ず納品してもらい、発注者側で保管しておくこと。契約書に、システムの著作権の譲渡や、第三者への再委託・移管に関するルールを明記しておくこと。そして、特殊な独自技術に過度に依存せず、一般的で標準的な技術で構築してもらうよう働きかけることです。これらを開発の入り口で取り決めておくかどうかで、将来の保守における発注者の交渉力は大きく変わります。ロックインは、稼働後に気づいても手遅れになりがちな問題であり、発注の初期段階からの備えが不可欠です。

保守費用のトラブルを避けるうえで欠かせないのが、保守の対応範囲とサービス水準の明文化です。ベンダーによって保守の対応範囲は大きく異なり、漠然と「保守をお願いします」と依頼するだけでは、何がどこまで対応してもらえるのかが不明確なまま契約することになります。ここで重要になるのがSLA（サービスレベルアグリーメント＝サービス品質保証）です。SLAでは、障害が発生した際の初動対応の時間（何時間以内に対応を開始するか）、暫定復旧の目標時間、対応する時間帯（平日日中のみか、24時間365日か）、月に何件までの問い合わせや修正を定額に含むか、といった項目を数値で取り決めます。これを明文化しておくことで、「思っていた対応と違う」という認識の齟齬を防ぎ、費用に見合ったサービスを受けられるようになります。逆に、SLAを定めずに契約すると、緊急時に「その対応は契約範囲外です」と言われたり、些細な依頼のたびに追加見積もりを求められたりして、結果的に費用も対応品質も不透明なまま推移してしまいます。また、保守の課金形態にも、月額定額制と、事象（インシデント）ごとに費用が発生する従量課金制があります。システムの重要度や、障害発生時にどれだけ迅速な対応が必要かに応じて、どちらの形態が自社に合っているかを見極めることも、発注者の大切な判断です。

保守費用を抑える選択肢として、保守を内製化したり、開発したベンダーとは別の会社に保守を移管したりする方法があります。ただし、いずれも相応の注意が必要です。内製保守は、自社に技術力があれば外注費を抑えられ、柔軟な改善も可能になりますが、24時間・夜間対応の負荷や、IT人材を確保・育成するための時間的・金銭的コストがかかります。さらに、保守を担える人材が特定の担当者に偏ると、その人が退職した途端に運用が回らなくなる属人化のリスクも生じます。内製化は「外注費が浮く」という単純な話ではなく、体制づくりまで含めた総合的な判断が求められます。一方、開発を担ったベンダーとは別の会社に保守を委託する方法は、費用競争を働かせられる利点がありますが、大きな注意点があります。他社が開発したシステムの保守を引き受けるベンダーは、その設計思想や開発の背景を一から解析・理解しなければならず、これは大きな負担となるため、そもそも引き受けを敬遠されることが少なくありません。仮に引き受けてもらえたとしても、過去のプログラムを解析・理解するための「初期費用」が別途発生するのが通常です。したがって、開発ベンダーと保守ベンダーを分ける場合は、この引き継ぎコストを織り込んで検討する必要があります。こうした選択肢を将来的に確保しておくためにも、前述したソースコードや設計書の納品、標準的な技術での構築といった、ロックイン回避の備えが効いてくるのです。

保守・運用費用が想定より膨らむ主な原因

受託開発の保守・運用費用が、当初の想定を超えて膨らんでいくことは決して珍しくありません。その原因を理解しておくことは、契約時に予防策を講じるうえで役立ちます。ここでは、保守費用が想定より膨らむ2つの代表的な原因を取り上げます。いずれも、システムの発注段階や契約段階での取り組みによって、ある程度コントロールできるものです。

保守費用が膨らむ大きな原因の一つが、システムの「ブラックボックス化」と「技術的負債」の蓄積です。ブラックボックス化とは、システムの内部構造や仕様が、外からは分からない状態になってしまうことを指します。設計書が最新の状態に更新されていなかったり、稼働後に場当たり的な改修を繰り返した結果、システムが当初の設計から原型をとどめないほど複雑化していたりすると、保守作業のたびにベンダーはシステムの構造を理解し直すところから始めなければなりません。この理解のための時間がそのまま費用に上乗せされ、簡単に見える修正でも高額な工数を要するようになります。技術的負債とは、目先のスピードを優先して品質を犠牲にした結果、将来的に返済（改修）が必要になる「負債」のように蓄積した問題を指します。安さやスピードを重視して品質の作り込みを省いた開発は、短期的には安く済んでも、長期的には保守コストの高騰という形で跳ね返ってきます。これらを防ぐには、開発の段階で設計書やドキュメントを整備してもらい、稼働後もそれを最新の状態に保つことを保守契約に含めておくこと、そして改修のたびに場当たり的な対応で済ませず、システムの構造を健全に保つ意識を発注者・ベンダー双方が持つことが重要です。

保守費用が膨らむもう一つの主要な原因が、SLAが未整備であることによる対応範囲の認識齟齬です。毎月の保守費用が「保守一式」としか示されておらず、作業内容の内訳や対応範囲が明確でない契約は、後々のトラブルの温床になります。というのも、発注者は「この程度の修正なら当然含まれているだろう」と考えるのに対し、ベンダーは「それは契約範囲外なので追加費用が必要です」と判断する、という食い違いが日常的に起こるからです。この認識の齟齬があると、少しの仕様変更や軽微な改修を依頼するたびに範囲外扱いされ、その都度、追加の見積もりと請求が発生して予算を圧迫していきます。こうした事態を防ぐには、前述したSLAの明文化に加えて、保守費用の内訳を「何にいくらかかっているのか」が分かる形で提示してもらうことが有効です。「保守一式で月額◯◯円」ではなく、「障害対応◯時間分、定例の稼働監視、月◯件までの軽微な改修を含み、それを超える改修は別途◯円/人日」といった形で、含まれる作業と、範囲を超えた場合の単価が明示されていれば、発注者は追加費用の妥当性を判断でき、予算の見通しも立てやすくなります。契約の透明性を高めることが、想定外の費用膨張を防ぐ最も確実な方法です。

保守・運用費用を適正化するためのポイント

受託開発の保守・運用費用は、発注者の取り組み次第で適正な水準にコントロールできます。ポイントは、目先の初期費用の安さに惑わされず、長期的な視点でコストを評価すること、そして契約前の段階で必要な取り決めをしておくことです。ここでは、保守・運用費用を適正化するための2つの実践的なポイントを解説します。

保守・運用費用を適正化するうえで最も重要な考え方が、TCO（Total Cost of Ownership＝総所有コスト）での比較検討です。TCOとは、システムを導入・運用するために、そのライフサイクル全体でかかる費用の総額を指します。具体的には、初期の開発費用に加えて、数年間にわたる保守・運用費用、クラウドなどのインフラ費用、将来的な改修費用までを合算した金額です。発注者が陥りがちな失敗は、初期開発費の見積もりだけを比較して、最も安いベンダーを選んでしまうことです。しかし、初期費用が安くても、保守の対応が手薄で後から追加費用が頻発したり、ブラックボックス化しやすい作りで数年後の改修費が高騰したりすれば、トータルでは高くついてしまいます。ベンダーを選定する際は、初期開発費だけでなく、「このシステムを5年間運用したら、総額でいくらになるのか」というTCOをシミュレーションして比較することが重要です。そのためには、見積もりを取る段階で、初期費用に加えて年間の保守費用の目安、インフラ費用の想定、想定される改修の費用感までをベンダーに提示してもらいましょう。目先の初期費用の安さではなく、長期の総所有コストで判断することが、結果的に保守・運用費用を含めたトータルの支出を最適化することにつながります。

保守・運用費用の適正化は、契約を結ぶ前の取り決めで大きく決まります。まず、極端に安い見積もりには注意が必要です。相場から大きく外れて安い保守費用は、スキルの低いエンジニアが配置されていたり、対応範囲が極端に狭かったり、あるいは後から追加費用が発生する構造になっていたりする可能性を示唆しています。これを見極めるためにも、保守を含む見積もりは3〜4社程度から相見積もりを取り、費用の妥当性を比較検討することが推奨されます。複数社の見積もりを並べることで、相場観が身につき、極端に高い・安い提案を見抜けるようになります。加えて、契約前の段階で、責任の所在（障害時の責任範囲）、再委託の可否、損害賠償の範囲、著作権やソースコードの帰属といった条件をしっかり取り決めておくことが、将来的なトラブルや想定外の追加費用の発生を防ぎます。これらの取り決めは、いざ問題が起きてから交渉しようとしても手遅れになりがちで、発注者にとって不利な条件を飲まざるを得なくなります。開発を委託する契約の段階で、保守・運用フェーズまで見据えた条件を明文化しておくこと。この一手間が、システムを長期にわたって適正なコストで運用し続けられるかどうかを決定づけます。保守は「作った後に考える」ものではなく、「作る前に設計する」ものだという意識を持つことが、賢い発注者への第一歩です。

まとめ

本記事では、システム開発を外部に委託する「受託開発」における保守・運用費用・ランニングコストの考え方を、発注者の視点から解説しました。受託開発したシステムは納品して終わりではなく、初期開発費の年間5〜15%程度（複雑なシステムでは最大20%程度）を目安とする保守・運用費用が、稼働し続ける限り継続的に発生します。この費用を適正にコントロールするには、保守費用の作業内容とインフラ費用（クラウド利用料）を区別して予算計画に組み込むこと、ベンダーロックインを回避するためにソースコードや設計書の納品と著作権の取り決めを開発時に済ませておくこと、SLAで保守の対応範囲とサービス水準を明文化することが重要です。そして、費用が膨らむ原因となるブラックボックス化やSLA未整備を予防し、初期費用だけでなくTCO（総所有コスト）で複数社を比較検討することで、長期的に見て納得感のあるコストで運用を続けられます。保守は「作った後に考える」ものではなく「作る前に設計する」もの。この意識を持って発注段階から動くことが、受託開発を成功させる鍵になります。

▼全体ガイドの記事
・受託開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。