スクラッチ開発の保守・運用費用は、初期開発費、保守レベル、対応時間帯によって、月額数万円から数百万円以上まで変わります。
費用を左右する要因を知っておくと、見積もりを比べやすくなります。全体像はスクラッチ開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・スクラッチ開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
スクラッチ開発の保守・運用費用が他の開発手法と異なる理由
スクラッチ開発は、パッケージやSaaSを使わず、要件定義から設計・実装まで進めます。業務に合う仕組みを自由に作れる一方で、リリース後の保守・運用費用も発生します。
パッケージやSaaSと保守費用の構造が異なる理由は、提供の仕組みにあります。パッケージやSaaSは、ベンダーが同じ製品を多数の企業へ提供します。機能改善や更新、セキュリティ対応、障害対応は開発元が担い、利用者は月額利用料や年間ライセンス料を支払えば、保守を受けられる場合がほとんどです。
一方、スクラッチ開発は世界に一つの自社専用システムのため、保守・運用の責任は発注者か、契約した委託先が個別に負います。ライセンス料はかからない代わりに、保守体制を一から構築して契約する必要があります。このため、初期開発費用だけで判断すると、稼働後のコスト計画が崩れるおそれがあります。
パッケージ・SaaS利用との保守費用構造の違い
SaaSは保守を利用料に含めて支払う一方、スクラッチは保守を個別に契約し、その人件費が積み上がっていきます。両者は、保守費用が発生する仕組みと、カスタマイズの自由度が異なるため、料金の考え方と比べ方も変わります。
- SaaSの料金：1ユーザーあたり月額1,500円などの従量課金
- スクラッチの料金：保守作業は個別に契約し、人件費として積み上がっていきます。
- 比較の視点：長期利用では、保守費用を含めた総額で比べます。
SaaSの料金には、サーバー管理や機能更新、脆弱性へのセキュリティパッチ適用、障害時の復旧対応が含まれます。ただし、ユーザー数が増えるほど月額費用は膨らみ、カスタマイズにも制約があります。
これに対してスクラッチ開発では、バグ修正やセキュリティ対応を別途手配します。機能改善も個別の保守契約が必要で、利用者数に応じた従量課金はありません。そのため、長期かつ多数の利用者がいる場合は、スクラッチが総額で有利になることもあります。
スクラッチ開発ならではの月次コストの内訳
月次費用は、人が作業する保守費用と、稼働場所のインフラ費用の二つに分けて考えます。
- 保守費用：問い合わせ、障害対応、修正、更新に必要な人件費
- インフラ費用：サーバー、データベース、外部サービスなどの実費
保守費用には、問い合わせの一次対応や不具合の原因調査が含まれます。さらに、障害時の初動対応、暫定復旧、恒久対策プログラムの適用も対象です。
OSやミドルウェアの更新、定例リリースによる改善も保守作業に含まれます。そのため、必要なエンジニアの稼働を月次で確保しておく必要があります。
インフラ費用には、クラウドサーバー、データベース、ストレージの利用料がかかります。外部APIや連携ツールの費用も対象で、ドメインやSSL証明書も含まれます。
インフラ費用は、全体費用の20〜30%程度を占めることも珍しくありません。したがって、月額保守に含む作業と、インフラ実費として請求する範囲は、契約前に切り分けておく必要があります。
規模別に見るスクラッチ開発の保守・運用費用の目安
保守・運用費用は、システムの規模と複雑さで大きく変わります。年間費用は初期開発費用の15〜25%程度、月額は5〜15%程度が目安です。
たとえば、初期開発に2,000万円を投じた場合は、年間300万〜500万円程度が一つの目安です。
費用は利用者数よりも、求める品質水準や対応時間帯で決まります。具体的には、24時間365日監視するか、平日日中だけ対応するかで金額は変わります。
小規模・中規模・大規模別の月額費用相場
初期費用の規模ごとに、月額保守費用の目安と契約内容を並べて見ると、自社がどの段階にあたるかを判断する材料になります。
- 小規模：初期費用300万〜1,000万円で、月額は数万円〜20万円程度です。
- 中規模：初期費用1,000万〜5,000万円で、月額は15万〜80万円程度です。
- 大規模：初期費用5,000万円〜1億円以上で、月額は数十万〜数百万円以上です。
小規模では、問い合わせ対応や簡易な運用サポートが中心です。大規模な改修対応までは、含まれないことが一般的です。
中規模になると、SLA（サービス品質保証）に基づく障害対応が含まれてきます。さらに、定期更新や軽微な改修枠も保守契約の対象になります。
大規模では、同じ規模でも品質水準と対応時間帯によって数倍の差が出ます。だからこそ、必要な保守レベルを見極めることが、過剰な支出や事業停止の回避につながります。
保守費用とインフラ費用（実費）の違い
保守費用とインフラ費用を分けて捉えると、ランニングコストを正しく把握できます。
- 保守費用：問い合わせ、障害、バグ修正、軽微な改修への対価
- インフラの内訳：サーバー、DB、ストレージ、APIなどの利用料
- 契約時の確認：月額保守と別請求の境界
インフラ費用は、実際に使ったリソース量に応じて変動する実費です。たとえば、アクセス数が急増すると、サーバー費用も跳ね上がります。
クラウドサーバーの利用料は月額数万円からで、ほかの費用も加わります。スクラッチ開発では、インフラの契約や監視、支払いの管理を自社で担う必要があります。
そこで、コストの上限を超えたときに知らせるアラートを設定しておくと、費用を予測できる範囲に収めやすくなります。
内製・外注・オフショアで変わる保守コストの実態
保守の担い手によって、費用、対応速度、依存リスクが大きく変わります。そのため、外注、内製、オフショアの中から、自社の条件に合う体制を選ぶ必要があります。
外注保守のメリットとベンダーロックインのリスク
外注保守は、専門人材を確保しにくい企業にとって現実的な選択肢です。
- 費用：月額数十万円から、大規模なら数百万円が継続的にかかります。
- メリット：専門家の体制と、SLAによる対応速度を得られる点
- リスク：開発会社から抜けにくくなる状態（ベンダーロックイン）
自社専用システムは、内部構造を開発会社だけが把握しやすい傾向があります。資料が不足したままブラックボックス化すると、開発会社への依存が強まり、他社への引き継ぎが難しくなります。そのうえ、改修のたびに高額な追加見積もりを受け、他社へ移れなくなる場合もあります。
委託時から仕様書やソースコードの文書化を契約に明記し、成果物として受け取っておくことが、ロックインを抑えるうえで欠かせません。
内製化によるランニングコスト削減とその条件
内製化は外注費とロックインを抑える方法ですが、必要な条件もあります。
- 削減効果：社内人材が保守を担えば、外部委託費を抑えられます。
- 必要条件：24時間監視と障害復旧を担う人材の確保
- 現実的な体制：社内の人員に合わせて、担当する範囲を決める
社内に開発メンバーがいれば、内部構造を理解した人が保守を担えます。一方、パッケージやSaaSは内部へ手を入れにくいため、内製する選択肢がありません。
ただし、採用や育成にはコストと時間がかかり、退職によって属人化することもあります。内製化が効果を出すかどうかは、システムの重要度と社内のIT人材の充実度で決まります。
日常運用を内製し、高度な障害対応や大規模改修を外注する企業も増えています。保守体制を自社で柔軟に設計できる点は、スクラッチ開発の強みです。
スクラッチ開発のランニングコストを適正化するポイント
保守・運用費用は、放置すると膨らみますが、契約の決め方と比べ方によって調整できます。
SLA・保守契約範囲の明文化
保守の範囲を発注前に決めておくと、追加作業をめぐる認識のずれを防げます。
- 対応範囲：バグ修正をどこまで保守費用に含めるか
- 対応時間：重大障害は15分以内に開始するなど、対応の期限
- 改修枠：軽微な改修を月次契約に含めるかどうか
パッケージやSaaSは規約で範囲が決まっています。一方、スクラッチでは個別に合意する形になるため、障害時の初動や暫定復旧、恒久対策の提出期限も、契約に書き込んでおく必要があります。対応範囲を書面に残しておけば、「言った言わない」の争いを防げます。
月次契約に軽微な改修枠を入れると、予算は読みやすくなります。ただし、使わない月も費用は発生するため、改修の頻度に応じて選ぶ必要があります。
総所有コスト（TCO）によるスクラッチとパッケージの比較
初期費用だけでなく、総所有コスト（TCO：Total Cost of Ownership）で比べる必要があります。
- TCOの範囲：初期費用、保守、インフラ、拡張費を含める
- スクラッチ：初期費用は高めで、ライセンス料はかからない
- パッケージ・SaaS：初期費用は抑えやすいが、利用料が続く
TCOは、システムを保有し続けるための総支出を示す考え方です。パッケージやSaaSは、利用者数と期間に応じて月額利用料が積み上がります。
一方、スクラッチの月額費用は、保守費用とインフラ費用に限られます。5年から10年で試算すると、多数の長期利用ではスクラッチが有利な場合があります。
ただし、利用者数が少なく期間も短い場合は、パッケージやSaaSが割安なこともあります。そのため、損益分岐点は利用規模と運用年数で変わり、保守費用まで含めて見極める必要があります。
保守・運用費用を見誤らないための注意点
初期開発費用だけを見ていると、稼働後の見えにくいコストを見落としがちです。スクラッチ開発では、ブラックボックス化や技術的負債にも注意が必要です。
ブラックボックス化・技術的負債のリスク
資料が不足していることや、場当たり的な実装は、保守費用と改修時間を増やす原因になります。
- ブラックボックス化：内部構造が特定の人や会社に偏った状態
- 技術的負債：後から手を入れにくい構造の蓄積
- 予防策：仕様書とソースコードの文書化による属人化の防止
仕様書やコードのコメントが不足すると、担当者の退職後に誰も手を入れられなくなります。その結果、新しいエンジニアがコードを解読する工数が増え、改修費用も跳ね上がります。さらに、技術的負債があると、一つの修正が別の不具合を招く連鎖が起きやすくなります。
委託先の義務として文書化を契約に入れておけば、属人化を防げます。資料がそろえば、保守先を変えることや内製へ移ることも可能になります。
将来の機能拡張を見据えた契約設計
リリース後の拡張費用も、保守・運用費用と合わせて見通しておく必要があります。
- 設計：初期段階から将来の拡張を見込んだ設計
- 単価：追加開発の人月単価を、保守契約の時点で合意しておくこと
- 変更管理：依頼から調査、見積もり、承認を経て実施するまでの流れ
パッケージやSaaSは、追加費用なしで新機能を使えることが多くあります。一方、スクラッチ開発では、新機能の追加が個別案件となり、その都度費用が発生します。さらに、拡張性を考えない設計では、既存構造の作り直しで費用が増えるおそれがあります。
単価を合意しておくと、追加開発で法外な費用を請求されるリスクを抑えられます。また、変更管理を決めておけば、小さな追加依頼が予算を圧迫する事態を防げます。
自由に拡張できる反面、そのぶんコストもかかります。将来への備えを投資判断に含めると、後の負担を正しく見積もれます。
まとめ
スクラッチ開発の保守費用は、利用料に含まれず、保守体制を個別に整える必要があります。
年間は初期開発費用の15〜25%程度が相場の目安です。
保守レベルや対応時間帯によって、費用は大きく変わります。そこで、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を創業。