システム開発のバグ修正費用は誰が負担？無償の範囲と交渉軸

システム開発のリリース後に「先日発覚したバグの修正に追加で30万円かかります」と開発会社から見積を受け取り、戸惑った経験はないでしょうか。「リリースしたばかりなのに、バグ修正費用が発生するのはおかしいのでは」「無償で直してもらえる範囲のはずでは」と感じる発注者は少なくありません。

一方で、開発会社からすれば「仕様変更に該当するため有償対応」「無償保証期間を過ぎている」といった主張にも、それなりの根拠があります。両者の言い分が食い違うのは、バグ修正の費用負担が「契約不適合責任」「契約形態」「経過期間」「仕様書の記載」といった複数の軸で決まる仕組みになっているためです。

つまり、すべてのバグが無償対応とは限らず、逆にすべてが有償対応でもありません。判断軸を整理してから交渉に臨めば、「払うべき費用」と「押し返せる費用」を切り分けられます。

本記事では、システム開発のリリース後に発覚したバグについて、無償修正の範囲と有償になるケースをどう判断するか、発注者の立場で整理します。原因切り分けのチェックリスト、見積金額の妥当性確認、関係を壊さない交渉の進め方まで、開発会社との打合せ前に押さえておきたい論点をまとめました。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

リリース後にバグ修正費用を請求されたときの考え方

開発会社からバグ修正の請求書や見積を受け取ったとき、最初に避けたいのは「全部払う」または「全部押し返す」という極端な判断です。実際には、リリース後のバグ修正費用は4つの軸で「無償か有償か」が決まります。

バグ修正費用が「無償・有償」に分かれる4つの判断軸

費用負担の判断は、以下の4軸を順に確認することで切り分けられます。

1. 原因の所在: そのバグは開発会社の実装ミスか、発注者側の仕様未定義・仕様変更によるものか
2. 契約形態: 請負契約か準委任契約か（責任の範囲が異なります）
3. 経過期間: 検収・引き渡しからどれだけ経過しているか、無償保証期間内か
4. 仕様書・議事録の記載: 該当機能の挙動が文書で合意されているか

この4軸のうち、原因の所在と契約形態は「そもそも無償交渉できるか」を決め、経過期間と仕様書の記載は「どこまで強く主張できるか」を決めます。本記事では以降、この4軸を順に解きほぐしていきます。

多くの発注者が誤解しがちな2つのパターン

費用判断でつまずきやすい誤解として、特に多いのが次の2つです。

• 「リリース後だから全部無償で直してもらえる」: 仕様未定義の領域や運用開始後に判明した新しい要件は、無償保証の対象外になることが一般的です。「バグに見えるが仕様変更」というケースは想像以上に多くあります
• 「請求書が来たから全部払うしかない」: 開発会社のミスに該当するバグであれば、契約不適合責任に基づき無償での修正を求められます。請求金額そのものの妥当性も確認の余地があります

どちらも、判断軸を持たずに反射的に決めてしまうことで起きる誤解です。打合せの前に、自社のケースが4軸のどこに該当するかを整理しておくと、感情的にならずに交渉を進められます。

無償修正が認められる範囲 — 契約不適合責任の正体

無償でバグを直してもらえる根拠となるのが「契約不適合責任」です。発注者が交渉カードとして持つべき権利の中身を整理します。

契約不適合責任とは

契約不適合責任とは、納品されたシステムが「契約で定めた内容に適合していない」場合に、受注者（開発会社）が負う責任のことです。2020年4月の民法改正で、それまでの「瑕疵担保責任」から名称と内容が変更されました（民法改正による情報システム開発プロジェクト・運用への影響は？（Authense法律事務所））。

改正のポイントは、判断基準が「隠れた瑕疵があるか」から「当事者が合意した契約内容に適合しているか」に変わったことです。つまり、「仕様書・要件定義書・議事録などで合意した内容」がそのまま責任範囲の判断材料になります。発注者が「これは契約内容に適合していない」と主張するためには、合意内容を示せる文書を準備することが第一歩です。

発注者が請求できる4つの内容

契約不適合責任に基づき、発注者は次の4つを請求できます。

交渉の場で「無償で直してください」と求めるのは、4つのうち修補請求にあたります。開発会社が応じない場合には、減額や損害賠償といったカードに切り替える、というのが法的な建て付けです。

「バグがある＝即・無償修正」ではない

ここで注意したいのは、契約不適合責任は「不適合があった場合の責任」であって、「あらゆる不具合への無償対応の約束」ではないという点です。判例の傾向では、軽微な不具合や、運用上の工夫で回避できる事象は、契約不適合と認定されないこともあります（システム開発における契約不適合責任（BUSINESS LAWYERS））。

たとえば、「ボタンの色が想定と違う」「処理が3秒遅い」程度の事象は、契約書や仕様書に明記されていなければ、契約不適合に該当しないと判断される可能性が高くなります。一方で、「決済処理が失敗する」「データが消失する」といった事業運営に影響する事象は、契約不適合と認定されやすい傾向があります。

なお、契約不適合責任の法的な詳細（判例の傾向・要件論・損害賠償の範囲）については、瑕疵担保責任・契約不適合責任とは｜システム開発での違いと発注者の対処法で深く扱っています。本記事は「費用判断と交渉実務」に絞って解説します。

無償修正期間の法的デフォルトと契約での変更

「いつまで無償で直してもらえるか」を決めるのが、契約不適合責任の存続期間です。法的なデフォルトと、契約書でよく見るカスタマイズを整理します。

民法上の原則: 知った時から1年以内に通知

改正民法では、請負契約の場合「注文者が不適合を知った時から1年以内」に、その内容を受注者に通知する必要があります（民法637条1項）。改正前は「目的物の引き渡しから1年以内に請求」が原則だったため、改正により発注者が責任を追及できる期間は実質的に長くなりました（民法改正後の「契約不適合」で何がどう変わるのか（EGG SYSTEM））。

ただし、「通知すればよい」とされているのは、不適合の存在と概要を伝えるところまでです。1年以内に通知すれば、その後の具体的な修補請求は通知から消滅時効（一般的に5年または10年）までの間に行えると整理されています。

なお、商人間の取引には商法526条の規定があり、「目的物を受け取った後、遅滞なく検査して、直ちに通知する」ことが求められます。隠れた瑕疵については「引き渡しから6ヶ月以内」に発見・通知することが必要となるため、企業間のシステム開発では商法のほうが厳しい条件になる点に注意が必要です。

契約書でよく見る無償保証期間

民法の規定は「任意規定」であり、契約書で別途定めれば法定の期間より短くも長くもできます。実務でよく見る取り決めは次のとおりです。

経済産業省・IPA が公開している「情報システム・モデル取引・契約書」では、契約不適合責任の起算点を「検収完了後」とし、期間はシステムの重要度に応じて個別に定めるよう推奨されています（改正民法に対応した「情報システム・モデル取引・契約書」（IPA））。手元の契約書を見直す際は、まずこの条項がどうなっているかを確認してください。

期間を過ぎても請求できるケース

無償保証期間が過ぎていても、次のような場合は引き続き責任を追及できる可能性があります。

• 開発会社が不適合を知りながら告げなかった場合: 民法637条2項により、期間制限が適用されません
• 重大な過失による不具合: 通常のテストで発見可能だった重大なバグなどは、信義則上の責任が問われる場合があります
• 検収時には発見不可能だった「隠れた不適合」: 特殊な条件下でしか発現しないバグなど

これらは個別の事案で判断が分かれる領域です。期間を過ぎているが諦めきれない、というケースでは弁護士への相談を検討してください。

なお、契約形態（請負か準委任か）によっても期間の扱いが変わります。準委任契約では「成果物の完成」自体が義務ではないため、契約不適合責任ではなく「善管注意義務違反」での請求になります。詳しくはシステム開発の請負契約と準委任契約の違いと選び方を参照してください。

発注者都合のバグと開発会社のミス、見分け方の4ステップ

ここからが本記事の核です。バグの原因を「発注者都合」と「開発会社のミス」に切り分ける実務的な手順を、4つのステップで整理します。打合せ前に手元で1件ずつ確認することを想定しています。

ステップ1: 仕様書に該当機能の記載があるか

最初に確認するのは、発覚したバグの対象機能が、要件定義書や仕様書にどう書かれているかです。

• 記載あり、かつ現状が記載と異なる → 開発会社のミスである可能性が高いです
• 記載あり、かつ現状が記載どおり → 発注者側の仕様検討漏れの可能性が高いです
• 記載なし → ステップ2へ進みます

「記載あり」の判定は、要件の解像度にも依存します。「ユーザー一覧を表示する」という記載だけでは、「並び順」「ページング」「権限による表示制御」の挙動を断定できません。仕様書の粒度を踏まえて判断します。

ステップ2: 議事録・メールで合意した経緯があるか

仕様書に明記がなくても、開発期間中の議事録・チャット・メールで「この挙動にする」と合意していれば、その合意が契約内容の一部とみなされることがあります。

• 「○月○日のレビューで、A方式に決定」といった記録が残っている → 合意済みとして扱えます
• 「検討中」「次回判断」のままで未確定 → 仕様未定義領域となり、発注者側の責任要素が大きくなります

合意の証跡を探す際は、リリースから遡って「該当機能が初めて議論された会議」までの議事録を確認するのが効率的です。

ステップ3: テスト計画書・テスト結果で確認済みか

開発会社が実施した結合テスト・受入テストの計画書と結果報告書を見直します。

• 該当ケースがテスト計画に含まれ、合格と報告されている → 開発会社のミスである強い根拠になります
• テスト計画に含まれていなかった → グレーゾーンとなり、「テストすべきだったか」の議論になります
• テスト計画に含まれていたが、想定環境と本番環境が異なっていた → 環境差異の問題として、次のステップ4で判定します

「テスト合格と報告された機能で不具合が出た」というケースは、無償修正を強く主張できる典型例です。

ステップ4: 環境固有の問題か（本番環境・データ・ユーザー数）

本番環境特有の条件で発生するバグは、責任の所在が複雑になります。

• 本番データの量・内容に依存するバグ: テストデータと本番データの差が大きく、開発会社が把握できる範囲を超えていた場合、発注者側の責任要素が大きくなります
• 同時アクセス数・負荷に依存するバグ: 性能要件として明示されていれば開発会社のミス、未定義であれば発注者の責任要素となります
• OS・ブラウザ・第三者システムのバージョン差異: 動作環境として合意していたバージョンの範囲内であれば開発会社のミス、範囲外なら発注者の責任要素となります

開発会社のミスと判定できる典型パターン

ステップ1〜4を踏まえると、次のようなパターンでは無償修正を強く主張できます。

• 仕様書どおりに作られていないケース（実装ミス・読み違い）
• 結合テスト・受入テストで合格と報告された機能が、本番で同じ条件で動かないケース
• 一般的な開発で予防すべき脆弱性が残っているケース（SQLインジェクション、認証バイパス等）
• 合意済みの動作環境内で再現するバグ

発注者都合と判定される典型パターン

逆に、次のような場合は発注者側の費用負担になりやすい領域です。

• 仕様書・議事録にも記載のない挙動を「想定と違う」と訴えるケース
• リリース後に「やはりこうしたい」と要件を追加したケース
• 開発時には未確定だった外部システムの仕様変更に伴う改修
• 想定ユーザー数を大幅に超える運用負荷による性能問題

グレーゾーンの落とし所

最も悩ましいのが、どちらとも言い切れないグレーゾーンです。仕様書が曖昧、議事録に明確な合意がない、テスト範囲が想定外、といった場合は次のような落とし所が現実的です。

• 工数の折半: 双方の責任要素を認め合い、修正工数を半分ずつ負担します
• 修正対応は開発会社・運用支援は発注者: 直接的な修正は無償、運用切り替えやデータ移行は発注者負担とします
• 保守契約での吸収: 月額保守費の範囲内で対応してもらう代わりに、次月以降の対応リクエストの優先順位を下げます

仕様変更扱いになるグレーゾーンの整理や、契約書での予防策については、システム開発の仕様変更と追加費用のトラブル防止策もあわせて参照してください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

修正費用の交渉ポイント — 金額・工数の妥当性確認

「これは払うべき費用」と判断した場合でも、提示された金額がそのまま妥当とは限りません。見積の中身を確認する観点を整理します。

見積に含まれるべき内訳

バグ修正の見積は、次の4つの工数で構成されるのが一般的です。

見積を受け取ったら、4区分のうち「どの工数にどれだけ計上されているか」の内訳を開発会社に確認することをおすすめします。内訳が出てこない見積は、それ自体が見直し交渉の余地があります。

エンジニア単価相場の確認

工数に掛ける単価（人月単価・人日単価）も、業界相場と照らし合わせる価値があります。2026年時点での国内受託開発の単価相場は次のとおりです（【2026年版】エンジニアの単価相場と年収目安を徹底解説（セラク））。

1人月を160時間とすると、シニアエンジニアの時間単価は5,000〜7,500円程度が目安です。バグ修正のような短時間作業では、1時間あたり8,000〜15,000円程度で計上されるケースもありますが、それを大幅に超える単価が提示されている場合は内訳の根拠を確認してください。

ただし、単価そのものよりも「総工数の妥当性」のほうが交渉余地は大きい傾向にあります。「単価を下げてほしい」より「修正範囲が局所的なのに、なぜ調査工数が5人日も必要なのか」という問いかけのほうが効果的です。

セカンドオピニオン取得・別ベンダーへの相見積りの是非

提示金額への違和感が強い場合、別の開発会社に相見積りを依頼することも選択肢です。ただし、いくつか注意点があります。

• コード・仕様書の開示が必要: 別ベンダーが正確な見積を出すには、現行コードや仕様書の確認が必要となります。契約上開示可能か確認してください
• 既存開発会社との関係悪化リスク: 相見積りそのものが既存ベンダーへの不信表明と受け取られる可能性があります
• 修正と保守の継続性: 別ベンダーに修正を依頼すると、その後の保守も分断されます。総合的なコストでは割高になる場合があります

実務的には、相見積りまで踏み込まずに「業界相場の参考情報」を社内で持っておき、交渉材料として使う形が現実的です。

関係を壊さない交渉の進め方

開発会社は今後の保守・追加開発の相手でもあります。関係を維持しながら交渉する手順を整理します。

1. 事実確認から始める: 「請求金額に納得できない」と切り出す前に、「見積の内訳を教えてほしい」「該当バグの原因と影響範囲を教えてほしい」とまず情報を求めます
2. 切り分けの仮説を提示する: 「弊社の認識では、ステップ1〜4のチェックで○○に該当するのではないか」と、自社の判断材料を共有します
3. 着地点の選択肢を複数提示する: 「無償対応」一択ではなく、「折半案」「保守契約での吸収」「次回リリースでまとめて対応」など、相手も検討しやすい複数案を出します
4. 書面で合意を残す: 落とし所が決まったら、口頭で終わらせずメール・議事録で合意内容を確認します

感情的な押し返しではなく、事実と論点で進めることで、長期的な関係を維持しながら適正な負担に着地できます。

今回のトラブルを繰り返さないために — 契約書で事前に合意すべきバグ修正条件

今回の費用判断が落ち着いたら、次回の発注で同じトラブルを繰り返さないための仕組みを契約書に落とし込んでおきましょう。多くの紛争は、契約書に「曖昧な余地」が残っていることが原因です。今回の経験を活かして、次の契約書では以下の4点を明示してください。

契約形態の明示

請負契約か準委任契約かを契約書冒頭で明示します。両者では責任範囲がまったく異なります。

• 請負契約: 成果物の完成義務があります。完成しなければ報酬が支払われません。契約不適合責任があります
• 準委任契約: 善管注意義務に基づき業務を遂行する義務があります。成果物の完成は必須ではありません。契約不適合責任は原則発生しません

「成果物の完成を期待しているのに準委任契約になっていた」というケースでは、後日のバグ発覚時に責任を追及しにくくなります。発注内容に応じた契約形態の選択は、システム開発の請負契約と準委任契約の違いと選び方で詳しく整理しています。

無償保証期間の明示

契約不適合責任の存続期間を具体的に定めます。

• 起算点: 「検収完了の日」とすることが一般的です（引き渡し日との混同を避けるため）
• 期間: 検収後3ヶ月〜2年の範囲で、システムの重要度に応じて設定します。一般的には1年が標準です

期間と起算点を曖昧にしておくと、「期限切れだから対応できません」と早期に終了させられるリスクがあります。

バグの定義と除外条件

「何がバグで、何がバグでないか」を契約書で定義しておくと、グレーゾーンの議論が大幅に減ります。

• バグの定義例: 「仕様書・要件定義書に記載された動作と異なる挙動」「セキュリティ上の重大な脆弱性」「データの破損・消失」など
• 除外条件の例: 「合意された動作環境外での挙動」「発注者の指示変更による不具合」「第三者システムの変更に起因する不具合」など

定義を明確にすることで、「これはバグだから無償」「いやこれは仕様変更だから有償」という押し合いを契約段階で予防できます。

検収基準・テスト合格基準の文書化

検収時に「合格」と判断する基準を、契約書または別紙で文書化します。

• 結合テスト・受入テストの実施範囲（テスト計画書として別紙化が一般的です）
• 受入テストの合格基準（重大度別の許容バグ数、性能要件の数値目標など）
• 検収完了の判定方法（合格基準を満たした旨を書面で確認します）

検収基準を曖昧なまま運用すると、「検収済みなのにあとから不具合発覚」のときに責任の所在が不明確になります。検収基準と契約不適合責任の関係を契約書で明示しておくことが、トラブル予防の核です。

竣工後の保守契約とバグ対応範囲の違い

開発契約の無償保証期間が終了した後は、多くの場合「保守契約」のフェーズに移行します。ここでバグ対応費用の扱いがどう変わるかを押さえておきましょう。

保守契約の典型的な範囲と料金相場

システム保守契約に含まれる対応は、契約内容により幅があるものの、一般的には次の範囲です。

• 稼働監視: サーバ・アプリケーションの稼働状況の確認
• 障害対応: 障害発生時の調査・復旧作業
• 小規模バグ修正: 軽微なバグの修正対応
• 問い合わせ対応: 操作方法・運用面の相談

料金相場は「初期開発費の年間5%程度」が目安とされており、大規模で運用・保守が複雑なシステムでは年間15%程度になるケースもあります。サービス委託の形では月額20〜50万円程度がよく見られる水準です（システム開発の保守費用相場・内訳具体例とコスト削減のポイントも解説（システム幹事））。たとえば1,000万円で開発したシステムなら、年間50〜150万円・月額4〜12万円程度が目安となります。

ただし、24時間対応や基幹システムの場合は、これより高くなることが一般的です。逆に「軽微な相談対応のみ」「営業時間内のみ対応」など範囲を絞ると、月額5万円前後まで抑えられるケースもあります。

保守契約でも有償になりがちな対応

「保守契約を結んでいるから、すべてのバグ対応が無償」というのは誤解です。次のような対応は、保守契約の範囲外として別途請求になるのが一般的です。

• 仕様変更を伴う修正: 「バグの修正」ではなく「機能の変更」にあたるもの
• 新機能の追加: 既存機能の修正範囲を超える追加開発
• 大規模な改修: 数十時間〜数百時間規模の修正工数が必要なもの
• 第三者システムの変更対応: 連携先のAPI仕様変更に伴う改修

保守契約書の「対応範囲」「除外項目」を契約締結時に細かく確認しておくと、後日「これは別途見積です」と言われたときに納得しやすくなります。

開発契約の契約不適合責任期間と保守契約の関係

開発契約の契約不適合責任期間（たとえば検収後1年）と、保守契約の期間（通常は契約締結後1年単位）は、時系列で重なります。重なっている期間に発覚したバグについては、契約不適合責任に基づき「開発契約の枠で無償対応してもらう」のが原則です。

具体的には次のような整理になります。

「保守契約があるから契約不適合責任は使えない」ということはありません。重要なバグについては、保守契約の枠ではなく契約不適合責任を根拠に無償対応を求めるほうが、発注者にとって有利な場合があります。

まとめ — 「払うか・交渉するか」の判断フロー

ここまで整理してきた内容を、実際の意思決定フローとして再構成します。開発会社との打合せ前に、次の順序で社内整理しておくと交渉の準備が整います。

ステップ1: 原因の切り分け 発覚したバグについて、本記事の4ステップ（仕様書・議事録・テスト計画・環境）で原因を切り分けます。開発会社のミスか、発注者都合か、グレーゾーンかを判定します。

ステップ2: 契約形態と期間の確認 契約書を見直し、契約形態（請負・準委任）と契約不適合責任の存続期間を確認します。期間内であれば無償修補請求の根拠が立ちます。

ステップ3: 見積妥当性の確認 有償対応と判断した場合でも、見積の内訳（調査・修正・再テスト・リリース）と単価を確認します。総工数の妥当性に違和感があれば内訳の根拠を求めます。

ステップ4: 落とし所の提案 無償・有償・折半・保守契約での吸収など、複数の選択肢を準備して交渉に臨みます。書面で合意内容を残します。

このフローを踏むことで、「払うべき費用」と「押し返せる費用」「交渉で着地させる費用」を切り分けられます。重要なのは、判断軸を持って臨むことです。判断軸がなければ、開発会社の主張に押し切られるか、感情的な押し返しで関係を悪化させるかのいずれかになりがちです。

なお、バグ発覚直後の対応手順そのもの（トリアージ・報告の進め方）については、リリース後バグ多発の対応フロー｜PM・発注者が知るべきトリアージと報告手順で時系列にまとめています。本記事で「費用判断」を、別記事で「対応フロー」を、それぞれ整理することで、リリース後のトラブル全体を見渡せるようになります。

社内で論点が整理しきれない場合や、法的な争いに発展しそうな場合は、IT分野に詳しい弁護士への相談も検討してください。本記事の判断軸を持って弁護士に相談すれば、論点が明確な分、相談時間も費用も抑えられます。

バグ・不具合・エラーの違いや報告手順について整理した記事もありますので、社内の用語統一にはバグ・不具合・エラーの違いとは？発注者が知るべき判断軸もあわせてお役立てください。

関連記事

• 瑕疵担保責任・契約不適合責任とは｜システム開発での違いと発注者の対処法
• リリース後バグ多発の対応フロー｜PM・発注者が知るべきトリアージと報告手順
• システム開発の請負契約と準委任契約の違いと選び方
• システム開発の仕様変更と追加費用のトラブル防止策

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。