ITシステムのバグ修正費用は、契約でどこまでを保守に含めるか、調査やテストにどれだけ工数がかかるか、緊急度がどの程度かによって変わります。テキストや画像の差し替えなら、1回3,000円〜10,000円が目安です。
全体像は、ITシステムバグ修正の完全ガイドにまとめています。
▼全体ガイドの記事
・ITシステムバグ修正の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
バグ修正費用の位置づけと保守費用全体の相場観
バグ修正費用を理解するには、まずランニングコスト全体のなかでの位置づけを押さえ、そのうえで月額保守費用の相場を確認することが近道です。
ランニングコストの3分類（維持費・管理費・運用費）とバグ修正の位置づけ
システムのランニングコストは、維持費、管理費（保守費）、運用費の3つに分類できます。
- 維持費：ドメイン、サーバー（クラウド）、SSL証明書などの実費。
- 管理費：バックアップ、監視、セキュリティパッチ適用、障害復旧などの費用。
- 運用費：コンテンツ更新、アクセス解析、SEO対策などにかかる費用。
バグ修正や軽微な不具合対応は、一般に管理費（保守費）の範囲で行われます。ただし、既存のバグ修正と新たな仕様追加（機能改修）の境界はトラブルになりやすく、機能追加とみなされると保守費用の枠外で別途費用が発生します。
契約がどの分類のどこまでを対象にしているかは、発注前に確認しておく必要があります。
月額保守費用の相場（開発費の年5〜15%、規模別目安）
月額保守費用は、システム開発費の年間5〜15%が一般的な目安です。たとえば初期開発費が500万円なら、年間25万〜75万円、月額約2万〜6万円が基本の計算になります。
月額保守費用の幅が大きくなるのは、インフラの規模と対応範囲によって、必要な監視や運用が変わるためです。
- 小規模：1〜5台程度。監視、バックアップ、障害の一次対応が中心で、10万〜30万円。
- 中規模：6〜20台程度。上記にパッチ適用とヘルプデスクを加え、30万〜100万円。
- 大規模：21台以上。上記に設計と、コスト面の見直しを加え、100万〜500万円以上。
軽微なバグ修正は、月額保守費用に含まれるのが一般的です。ただし、契約によっては「月◯件まで」や「月◯時間まで」と上限が決まっていて、超過分は別途費用になります。
IT予算に占める保守運用費の割合
保守運用費は、初期開発が終わったあとも長期にわたって続きます。そのため、ライフサイクル全体での比重を踏まえ、バグ修正の費用を予算計画に入れておく必要があります。
- 継続費用：リリース後も、保守・運用費用は長期にわたって発生し続けます。
- 不具合の発生時期：リリース直後や大規模な機能追加の直後は、発生率が高まりやすい傾向があります。
- 予算の備え：この時期の費用を低く見積もると、想定外の追加費用が生じかねません。
- 年間予算：月額保守費用に加えて、突発修正やスポット対応に備える余裕分も含めます。
バグ修正の費用構造（改良開発の見積り手法）
バグ修正は、既存システムを対象とする改良開発の一種です。新規開発とは費用の構造が違うため、見積もりの内訳を読み解く考え方を先に押さえておきましょう。
調査・分析／機能実現／テストの3フェーズと工数配分
改良開発の見積もりは、調査・分析、機能実現（設計・実装）、テストの3段階で構成されます。
- 調査・分析：既存システムの仕様と影響範囲の把握。
- 機能実現：原因を特定した後に行う、実際の修正作業。
- テスト：修正が及ぼす影響の確認と、安全性の検証。
新規開発にはない追加コストは、既存システムという母体を理解・分析する工程で生まれます。とくに調査・分析工数は保守作業全体の約30%とされ、仕様や影響範囲の把握に欠かせません。
調査工数は、設計書や運用マニュアルの整備状況、システムの作り、担当者の習熟度によって変わります。
機能実現は原因を特定した後に行う、目に見えやすい工程です。ただし、調査やテストの工数が多いと、費用全体に占める機能実現の割合は小さくなることもあります。そのため、見積書で3段階の工数配分を確認すると、金額の妥当性を判断しやすくなります。
改造密度・改造分散度など見積り精度を左右する要素
見積もりの工数には、コード量だけでなく、既存システムの複雑さや影響範囲も反映されます。
- 改造密度：母体規模に対する追加・削除の量。
- 改造分散度：母体規模に対する修正箇所の数や広がり。
- 改造母体錬度：担当者の既存システムへの習熟度。
改造分散度が高いほど、修正が広範囲に及んで影響の確認に手間がかかり、生産性が落ちて費用も増えます。また、担当者が初めて触るシステムでは習熟度が低く、同じ修正でも工数が増える要因になります。
見積もりに疑問があるときは、改造密度、分散度、母体錬度の観点から工数の根拠を説明してもらい、そのうえで話し合うとよいでしょう。
「1行の修正でも全体テストが必要」になるケース
依頼者から「1行の修正になぜ費用がかかるのか」と疑問が出ることがあります。改良開発では、修正量とテスト量の相関が新規開発より低いため、少量の修正でも費用がかかる場合があります。
- 共通箇所への修正：複数の機能で使われる箇所は、既存機能全体に影響が及ぶ可能性があります。
- テスト範囲：影響の範囲を保証するために、全体のリグレッションテストが必要になる場合があります。
- 費用の内訳：修正作業より、安全性を確かめるテストに費用の大半がかかることもあります。
テスト費用の割合が大きい見積もりでは、共通部分の修正でテスト範囲が広がった可能性も考えてみるとよいでしょう。
保守契約なしのスポット対応費用相場
保守契約がない状態でバグが起きると、都度課金のスポット対応費用が発生します。そのため、費用の目安と対応上のリスクを、あらかじめ確認しておきたいところです。
修正内容別の費用レンジ（軽微修正〜障害対応〜セキュリティ）
スポット対応の金額は、テキストや画像の更新から障害・セキュリティ対応まで、作業内容によって異なります。
- テキスト・画像差し替え：3,000円〜10,000円。
- 軽微な不具合：レイアウト崩れやリンク切れは5,000円〜15,000円程度。
- サーバー・DB障害：原因特定と復旧は20,000円〜50,000円。
- セキュリティ侵害：ウイルス感染などの防止・復旧は50,000円〜150,000円。
費用を左右するのは、見た目の作業量よりも、原因を特定するための調査やシステムへの影響範囲です。そのため、複雑な障害やセキュリティ関連の不具合ほど高額になりやすい点を踏まえて、見積もりを確認しておくとよいでしょう。
エンジニア単価と緊急対応の割増費用
見積もりは作業時間とエンジニア単価をもとに算出されます。そのため、依頼先の所在地や対応時間も確認しておきたいところです。
- 所在地による単価差：首都圏は平均約116万円、ニアショアは約87万円で、2割強低い傾向です。
- 総額への影響：複数修正の同時発生や継続保守では、単価差が総額にも表れます。
- 時間外の割増：夜間・早朝・休日は通常料金に割増が加わり、1回30,000円〜100,000円程度の例があります。
業務時間外のトラブルで予算を超えないよう、緊急時の料金体系は事前に確認しておきましょう。
保守契約がない場合の対応スピードのリスク
保守契約の有無は、障害後の着手時期と対応先の確保にも影響します。
- 着手までの手順：トラブル後は、見積もりの依頼、提示、発注の順に進むため、着手までに時間がかかる場合があります。
- 依頼先の確保：保守契約のない顧客のスポット対応を、原則として受け付けない会社もあります。
- 事業への影響：重要システムでは、対応先がない、または着手に数日かかると機会損失につながります。
- 契約判断：単月の費用だけでなく、緊急対応体制の価値も含めて契約の要否を判断します。
契約形態とコストトラブルを防ぐポイント
費用トラブルの多くは、契約段階での取り決め不足が原因です。そこで、契約形態の違いと、事前に確認すべき点を押さえておきます。
準委任と請負、月額固定と従量課金の違い
保守契約は、法的な契約類型と課金方式という2つの観点で整理できます。
- 準委任：日常監視や障害復旧など、継続的なサービス提供に使われる契約。
- 請負：明確な新機能追加や仕様変更を伴う大規模改修に使われる契約。
- 月額固定：毎月一定額で予算を管理しやすい一方、対応がない月も費用が発生します。
- 従量課金：作業量に応じて課金され、安定月は割安でも障害多発月は急増し得ます。
- チケット制：あらかじめ購入したポイントを消費する方式。
通常の保守は、完成責任を負わない準委任契約で結ばれるのが一般的です。柔軟に進められる反面、対応範囲が曖昧になりやすい面があります。一方、請負契約は仕事の完成を約束する契約で、大規模改修では別に結ばれます。
不具合の起きやすさと、許容できる予算の変動リスクに合わせて、課金方式を選ぶとよいでしょう。
「バグ」と「仕様追加」の境界線トラブルの防止
費用をめぐって特に起こりやすいのは、既存の不具合か新たな機能改修かという境界について、発注側と開発側の認識がずれることです。そのため、契約と仕様の記録で境界を明確にしておきましょう。
- 認識の違い：発注側が本来の挙動として無償修正を求めても、開発側は仕様書どおりと判断し、高額な追加見積もりになる場合があります。
- 契約上の定義：「仕様書に明記された挙動と異なる場合をバグとする」など、定義の明文化。
- 仕様の記録：資料が未整備だと境界が曖昧になりやすいので、要求仕様書や設計書を整えて、あるべき仕様を残しておく。
見積もり時に確認すべきチェックポイント
トラブルを防ぐには、見積もりの金額の根拠と契約条件を確認することが欠かせません。
- 単価と超過費用：「一式」とせず、単価と計算根拠、超過作業時の追加費用の算定方法を明記しているか。
- バグの定義：「バグ」と「仕様追加」の切り分け基準が示されているか。
- 緊急料金：夜間・休日の費用が別建てになっているか、料金体系は明確か。
- SLA：要求水準によって費用がどう変わるか。
SLA（サービス水準合意）には、たとえば24時間365日対応、初回応答を何分以内にするか、稼働率を何%保証するかといった水準があります。厳格なSLAでは、夜間休日の待機要員や専任担当者をベンダーが確保する必要があり、その分、相場より高額になる点も押さえておきましょう。
ランニングコストを予測の立つ範囲に収めるには、契約前に確認事項を書面に残しておくことが有効です。
まとめ
バグ修正は一般に管理費（保守費）の範囲で扱われ、保守費は開発費の年5〜15%が目安です。改良開発では、調査・分析工数が保守作業全体の約30%とされ、テスト範囲も費用を左右するため、見積書の内訳で確かめておきたいところです。
スポット対応は、軽微な修正なら数千円、障害やセキュリティ対応なら数万円〜十数万円が目安です。ただし、緊急対応には割増がかかり、保守契約がないと着手が遅れるリスクもあります。
契約形態やバグの定義を明文化し、単価根拠、境界線、緊急費用、SLAを確認しておくと、想定外の費用トラブルを防ぎやすくなります。複数社に相談して、自社に合う保守体制を選びましょう。
▼全体ガイドの記事
・ITシステムバグ修正の完全ガイド
▼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を創業。