受託開発のバグ・不具合対応における責任分界点の決め方
受託開発で発生したバグや不具合の修正費用は誰が負担すべきか判断に迷うケースがあります。契約段階で責任分界点をどう定義し、トラブルを防ぐかを実務目線で解説します。
「納品後に見つかった不具合の修正費用は無償なのか、それとも追加費用が発生するのか」——受託開発でシステムを導入した企業の担当者から、こうした疑問が寄せられることがあります。契約時に責任分界点が明確に定義されていないと、同じような不具合でも「これは無償対応です」「これは追加費用が必要です」という判断が開発会発ごとに揺れ動き、トラブルの原因になりかねません。
責任分界点とは、簡単に言えば「どこまでが開発会社の責任で、どこからが発注者側の責任か」を区切る境界線のことです。この境界線が曖昧なまま契約を進めてしまうと、不具合発生時に双方の認識がすれ違い、関係悪化につながるケースも少なくありません。
この記事では、受託開発におけるバグ・不具合対応の責任分界点をどう決めるべきか、契約段階で確認しておきたいポイントを解説します。
この記事の要点(30秒でわかるまとめ)
- 責任分界点は**「バグ(契約不適合)」と「仕様変更・追加要望」を区別する基準**から考えるのが出発点
- 契約段階で瑕疵担保・契約不適合責任の期間と範囲を明記しておくことが重要
- 外部要因(他システム連携先の仕様変更など)による不具合の扱いも事前に取り決めておくべき論点
- 責任分界点の曖昧さは、要件定義書の記述の精度にも大きく左右される
バグと仕様変更の違いを整理する
結論:「要件定義書・仕様書に記載された内容と異なる動作」はバグ、「記載されていない新たな要望」は仕様変更として区別するのが基本的な考え方です。
責任分界点を考える上でまず押さえておきたいのが、バグ(契約不適合)と仕様変更・追加要望の違いです。要件定義書や仕様書に明記された内容どおりに動作しない場合は、開発会社の契約不適合として無償修正の対象になるのが一般的な考え方です。一方で、要件定義書に記載されていなかった動作を新たに求める場合は、追加開発・仕様変更として扱われることが多くなります。
この区別が機能するためには、そもそも要件定義書・仕様書に動作が具体的に記載されていることが前提になります。記載が曖昧なまま「言った言わない」の水掛け論になるケースも多く、要件定義後のスコープ管理:「言った言わない」を防ぐ合意形成術で紹介している進め方が参考になります。
契約書で確認すべき瑕疵担保・契約不適合責任の条項
結論:修正対応の無償期間と対象範囲が契約書に具体的に明記されているかを、契約締結前に必ず確認します。
| 確認項目 | 内容 |
|---|---|
| 無償対応期間 | 納品後何ヶ月(または何年)まで無償修正の対象となるか |
| 対象範囲 | 要件定義書・仕様書に記載された機能のうち、どこまでが対象か |
| 除外事項 | 発注者側の操作ミスや環境要因による不具合は対象外となる旨 |
| 対応フロー | 不具合報告から修正完了までの標準的な流れと目安期間 |
これらの条項が曖昧、あるいは契約書に記載がない場合は、契約締結前に開発会社と具体的にすり合わせておくことをおすすめします。なお、法的な契約不適合責任の解釈は個別の契約内容や状況によって異なるため、重要な契約判断については弁護士など専門家への確認を推奨します。
外部要因による不具合の扱い
結論:連携先システムの仕様変更やインフラ側の障害など、開発会社の制御が及ばない外部要因による不具合は、契約段階で別枠として取り決めておく必要があります。
業務システムは単体で完結せず、他システムとのAPI連携やクラウドサービスの利用を伴うことが多くあります。連携先のAPI仕様が予告なく変更され、その結果として不具合が発生した場合、これを開発会社の契約不適合として扱うのは必ずしも適切ではありません。こうした外部要因起因の不具合への対応方針(調査費用の扱い、対応の優先度など)は、トラブルが起きてから決めるのではなく、契約段階であらかじめ想定しておくことが望ましいといえます。
責任分界点を明確にするための要件定義の精度
結論:責任分界点をめぐるトラブルの多くは、そもそも要件定義書・仕様書の記載が曖昧であることに起因します。
バグかどうかの判断基準は「要件定義書・仕様書に記載された内容と異なるか」である以上、記載そのものが曖昧であれば判断基準自体が機能しません。特に、画面の挙動や入力値の境界条件(最大文字数、同時アクセス時の挙動など)は見落とされやすく、後から「これはバグではないか」という認識の相違が生まれやすい部分です。要件定義書の精度を高めるポイントについては非エンジニアにも伝わる要件定義書の書き方で詳しく解説しています。
検収段階でできる予防策
結論:検収・受け入れテストの段階で境界条件やエラーケースまで確認しておくことで、納品後の責任分界点をめぐるトラブルを減らせます。
検収テストを「正常系の動作確認」だけで終えてしまうと、境界条件やエラーケースの挙動は納品後に初めて判明することになります。検収段階でどこまで確認しておくべきかは検収・受け入れテストで確認すべきポイントで整理していますので、責任分界点を明確にする観点からもあわせて確認しておくことをおすすめします。
よくある質問(FAQ)
Q. 無償修正の対象期間はどのくらいが一般的ですか? A. 契約によって異なりますが、納品後3ヶ月〜1年程度を無償対応期間とする契約が多く見られます。期間は契約内容によって個別に確認が必要です。
Q. バグか仕様変更か判断が分かれた場合はどうすればよいですか? A. 要件定義書・仕様書の記載内容に立ち返って判断するのが基本です。それでも判断がつかない場合は、双方で協議の上、必要に応じて第三者や専門家の見解を仰ぐことも選択肢になります。
Q. 責任分界点は契約書のどこに記載されますか? A. 一般的には契約書本体の瑕疵担保・契約不適合責任に関する条項や、個別契約の別紙として添付される仕様書に関連する記載がなされます。契約形態によって異なるため、契約書全体を確認することが重要です。
Q. 保守契約と責任分界点はどう関係しますか? A. 無償対応期間終了後は保守契約の範囲内での対応となることが一般的です。保守契約の内容と責任分界点の関係は、契約締結時にあわせて確認しておくことをおすすめします。
まとめ
受託開発におけるバグ対応の責任分界点は、「要件定義書・仕様書に記載された内容と異なるか」を基準に、バグと仕様変更を区別するところから整理が始まります。契約書における無償対応期間・対象範囲の明記、外部要因への対応方針の事前合意、そして要件定義書そのものの精度向上が、トラブルを防ぐための具体的な対策になります。
Irwin&co株式会社では、要件定義の段階で現場の業務フローを丁寧にヒアリングし、仕様の記載精度を高めることで、納品後の責任分界点をめぐる認識のズレを防ぐ進め方を行っています。契約・保守体制についてのご相談は、お問い合わせからお気軽にどうぞ。
執筆者プロフィール

アーウィン 海Irwin&co株式会社 代表取締役
生成AIを活用したシステム開発・コンサルティング・研修サービスを提供するIrwin&co株式会社を創業し、IT専任者のいない中小企業を中心に、業務システムの構築とSaaSからの移行を支援している。「SaaSの標準機能に業務を合わせるのではなく、業務に合わせたシステムを自社の資産として持つ」という考え方のもと、不動産をはじめとする業界で、生成AIを前提とした業務システムの設計・開発を数多く手がける。
