システム開発の契約不適合責任：バグ・仕様不適合への請求と防御

システム開発で「仕様どおりに動かない」「バグが多く業務に使えない」「要件定義と成果物がズレている」といったトラブルが起きたとき、まず問題になるのが契約不適合（契約の内容に適合しない状態）です。契約不適合責任は、発注側（ユーザー企業）が追完（修補）や代金減額、解除、損害賠償を検討するための基本フレームになります。

もっとも、システム開発は「請負／準委任のどちらか」「検収（受入テスト）の位置付け」「仕様変更の履歴」「責任制限条項」の有無で結論が大きく変わります。この記事では、発注側の“損害賠償を取りたい”という場面を中心に、受託側（ベンダ／開発会社）の防御ポイントも含めて、実務で争点になりやすい順に整理します。

※個別の契約条項やプロジェクト経緯で最適解は変わります。早い段階で証拠と論点を整理するほど、交渉での着地点（修補・減額・解約精算・和解）を作りやすくなります。

執筆者：弁護士 坂尾 陽（企業法務・M&A担当）

システム開発でいう「契約不適合」とは（バグ＝必ず不適合ではない）

契約不適合とは、成果物（ソフトウェアやシステム）が種類・品質・数量などの点で、契約で約束した内容に合っていない状態です。システム開発では「契約＝要件定義・仕様書・見積の前提条件・合意した性能要件（非機能要件）・受入基準」と考えると整理しやすくなります。

よくある“契約不適合と評価されやすい例”は次のとおりです。

一方で、開発では軽微な不具合が一定数残ることもあり、「バグがある＝直ちに契約不適合」とは限りません。バグの性質（再現性・影響範囲・回避可能性）や、契約上の受入基準・保証範囲との関係で評価が分かれます。

まず確認すべき3点：請負か準委任か／契約内容（仕様）／検収の位置付け

請負か準委任かで「責任の立て方」が変わる

成果物の完成を約束する請負（または成果完成型の準委任に近い契約）では、成果物の不具合が“契約内容に適合しない”として、追完・減額・解除・損害賠償の議論が組み立てやすくなります。

これに対し、準委任（履行割合型・工数提供型）では「完成保証」ではなく、受託側の善管注意義務（プロとして相当の注意で業務を行う義務）違反や、合意した業務範囲の不履行（債務不履行）として争うことが多く、“どこまでが業務範囲だったか”が前面に出やすい傾向があります。

仕様書・要件定義・議事録が「契約内容」を決める

システム開発の紛争では、契約書本文よりも、要件定義書・基本設計書・画面一覧・API仕様・RFP・提案書・見積の前提条件などが、実質的に「何を約束したか」を決めます。仕様変更（追加開発）が多い案件ほど、後から争いにならないよう、変更管理の証跡が重要です。

検収（受入テスト）条項は、主張の出発点になる

検収条項は、①いつ納品とするか、②合格基準は何か、③不合格の場合の修補期限、④検収合格後の保証（瑕疵対応）期間、を定めます。仮に「検収合格＝一切免責」のような条項があると受託側の防御材料になり得る一方、重大な不具合が後日発覚した場合に、条項の解釈や適用範囲が争点になります。

発注側が取り得る4つの請求（優先順位：損害賠償→代金減額→解除→追完）

契約不適合が疑われるとき、発注側が選べる手段は大きく4つです。実務では「まず追完を求め、改善しなければ減額・解除へ」という流れが多いものの、損害賠償は並行して検討します（特に業務停止や代替対応が発生しているケース）。

損害賠償：最優先で検討されやすいが、立証が重い

損害賠償では、①契約不適合（または債務不履行）、②損害の発生、③因果関係（相当因果関係）、④損害額の根拠、が問われます。システム開発では「バグはあったが、損害は別原因」という反論が出やすいため、後述の証拠設計が重要です。

典型的な損害項目は次のとおりです（契約の責任制限条項がある場合は上限が問題になります）。

代金減額：成果が一部使えない／品質が足りない場合の着地点になりやすい

「修補しても完全には直らない」「納期遅延で価値が下がった」「機能の一部をあきらめる」といった場合、代金減額は現実的な解決手段になります。減額の基準は契約で定めていないことも多く、不具合の影響範囲・代替に要した費用・残存価値などから合理的な線を作ります。

解除：不適合が重大で、契約目的を達成できない場合に選択肢になる

解除は強力ですが、不適合が軽微にとどまる場合は解除できないと整理されることが多く、争点になりやすい類型です。実務上は、解除に踏み切る前に、追完の催告（是正期限の設定）や、代替案（縮小納品・減額）を提示しながら交渉するケースが多いです。

追完（修補・再提供）：紛争を“止血”するための基本だが、範囲の合意が必要

追完は「直して使える状態にする」ための手段です。とはいえ、追完の範囲が曖昧だと、修補の泥沼化や追加費用の対立につながります。発注側は受入基準と修補期限を明確にし、受託側は追加要望（仕様追加）と切り分けて合意することが重要です。

損害賠償を通すための立証ポイント（発注側の実務チェックリスト）

損害賠償を狙う場合、最終的に問われるのは「その不具合のせいで、どんな損害が、いくら発生したか」です。発注側は、次の4点をセットで固めます。

技術的な争点が大きい案件では、第三者の調査（ログ解析・再現テスト・簡易鑑定）を検討することがあります。調査は「勝てる証拠を増やす」一方でコストもかかるため、争点（仕様のズレか、運用か、環境か）を絞って実施するのがポイントです。

受託側（ベンダ）が主張しやすい防御と、発注側の備え

受託側は、責任を否定・限定するために次のような主張を組み立てることが多いです。発注側は先回りして反証・補強を準備します。

トラブル発生後の実務フロー：通知→是正要求→協議→（必要なら）解除・損害賠償

実務では、次の順で動くと整理しやすく、証拠も残しやすくなります。

期間面では、請負に近い契約では、不適合を知ってから1年以内に通知しないと、追完・減額・損害賠償・解除が制限される整理が問題になることがあります（例外もあります）。また、契約書で保証期間や通知期間が短く定められているケースもあるため、「気付いたら早めに通知」が安全です。

よくある質問

Q. 検収後に不具合が見つかった場合でも、請求できますか？

契約条項（保証期間、検収の効果、免責の範囲）と、不具合の性質（重大か、当時発見できたか）で結論が分かれます。検収合格でも直ちに全てが終わるとは限らないため、まずは契約と検収資料（合格判定・留保）を確認します。

Q. 仕様変更が多い案件は、どこが争点になりますか？

「いつ、何を、誰が承認したか（変更管理）」が最大の争点になります。口頭合意だけだと後で争いやすいため、メール・議事録で“合意の証跡”を残します。

Q. 受託側から責任制限条項を示されたら、損害賠償は無理ですか？

上限や間接損害の除外が定められていると請求額が抑えられる可能性はありますが、条項の適用範囲・例外、契約違反の態様（重大性）によって検討余地があります。まずは条項の文言と、実際の損害項目を突き合わせます。

まとめ

損害賠償を狙うか、減額・解約精算で早期に終わらせるかは、事実関係と証拠の強さで現実的なラインが変わります。まずは「契約内容」「不具合の実態」「影響（損害）」を並べて整理することが出発点です。

関連記事（システム開発・IT紛争）