システム開発トラブルでは、「何が原因で」「どこまでが損害か」が争点になりやすく、発注側が損害賠償を検討する場面だけでなく、受託側（ベンダ）が高額請求を受けて防御しなければならない場面も少なくありません。本記事では、システム開発に特有の損害（瑕疵・バグ、追加費用、納期遅れ）を中心に、請求できる範囲と立証の勘所を整理します。
結論として、損害賠償は「起きたトラブル＝全部請求できる」ではありません。契約書の責任分担・検収・変更管理の設計、相当因果関係（損害の範囲）と立証資料、責任制限条項（上限・免責）の有無で、見通しが大きく変わります。なお、システム開発トラブルの全体像については、**システム開発・IT紛争の対応：契約・証拠・交渉・訴訟の実務**でまとめています。
坂尾陽弁護士
- 瑕疵・バグで争われやすい損害（再開発費・運用暫定費用・データ復旧等）と立証
- 仕様変更・追加要望による追加費用は「合意の有無」と記録で勝負が決まる
- 納期遅れは起算点・帰責事由（発注側要因/ベンダ要因）の切り分けが重要
- 責任制限条項（上限・間接損害排除）を前提に、請求額の組み立て/減額を設計する
- 交渉・訴訟で使える証拠パッケージ（チケット、議事録、成果物、ログ）の作り方
執筆者：弁護士 坂尾 陽（企業法務・M&A担当）
Contents
企業法務の無料法律相談実施中！
- 0円！完全無料の法律相談
- 弁護士による無料の電話相談も対応
- お問合せは24時間365日受付
- 土日・夜間の法律相談も実施
- 全国どこでも対応いたします
損害賠償の基本枠組み：争点は「契約違反」より「範囲と立証」
システム開発の損害賠償は、一般論としては債務不履行（約束した成果や作業を提供しない、納期に遅れる等）や契約不適合（成果物が契約内容に適合しない）に基づいて整理されることが多いです。ただ、実務上は「どの法的構成か」以上に、次の3点の当てはめで結論が動きます。
- 契約と前提資料で、何が“約束”だったか（要件定義・仕様・範囲・前提条件）
- 損害の範囲（相当因果関係、間接損害/逸失利益の扱い、責任制限条項）
- 立証（いつ何が起き、誰の行為が原因で、いくら発生したかを裏付ける記録）
なお、民法上の損害賠償の一般的な考え方（損害の範囲・予見可能性など）を基礎から確認したい場合は、債務不履行による損害賠償請求の基本もあわせて参照すると整理しやすいです。また、契約不適合責任については**システム開発の契約不適合責任：バグ・仕様不適合への請求と防御**にまとめています。
まず確認すべき契約・資料：最初の30分で見るチェックリスト
請求する側も、請求される側も、最初に「資料をそろえる順番」を間違えると、後から主張がブレたり、証拠が散逸したりします。まずは次を集め、争点を固定しましょう。
- 契約書・個別契約・注文書/発注書（請負/準委任、成果物定義、検収、報酬、瑕疵対応、責任制限）
- RFP・要件定義書・基本設計/詳細設計（前提条件・非機能要件・運用条件・外部連携）
- 仕様変更の記録（変更要求票、チケット、メール、議事録、見積、追加発注の有無）
- 検収・受入テスト資料（合否基準、テスト結果、指摘票、暫定受入の有無）
- 障害対応の記録（障害報告、原因分析、再発防止策、ログ、監視データ）
- 損害の根拠資料（再作業工数、外注費、代替システム費、売上/粗利資料、残業・追加人員の証憑）
特に受託側は、請求を受けた直後に「現場の口頭説明」だけで対応方針を決めると、後で記録と矛盾して防御が難しくなります。まずは記録ベースで時系列を作るのが安全です。
瑕疵・バグによる損害賠償：請求できる典型項目と立証ポイント
システムの不具合は、損害賠償の中でも金額が膨らみやすい一方、「それは瑕疵なのか（仕様か運用か）」で争われやすい分野です。典型的な損害項目ごとに、立証のポイントを押さえます。
再開発費・修補費（手戻り工数）は「何を直すのか」を切り分ける
バグ修正や再開発費は、契約上の成果物（要件）に足りない部分の補填として位置づけられると認められやすい反面、「追加機能」「運用改善」「仕様の後出し」まで混ざると争点化します。
- 要件・受入基準との不一致（どの要件に違反しているかを、仕様書・テスト項目に紐付ける）
- 修補の範囲（不具合修正と、改修・機能追加を明確に分ける）
- 工数の合理性（チケット・コミット履歴・作業報告で、誰が何時間かけたかを裏付ける）
業務停止・データ毀損の損害は「因果関係」と「回避可能性」が問われる
障害で業務が止まった、データが壊れた、復旧に外注が必要になった、といった損害は、主張としては分かりやすい一方、裁判ではシステム外の要因（運用ミス、社内権限、ネットワーク、他システム連携）を理由に争われがちです。
- 障害発生の客観記録（監視ログ、アラート、アクセスログ、DBログ、障害報告書）
- 切り戻し/暫定対応の履歴（復旧作業の時系列、代替運用コストの算定根拠）
- 発注側の協力義務（情報提供・検証環境提供が遅れた場合の影響）
受託側（ベンダ）が請求されたときの防御ポイント
受託側は、全面的に争うか一部認めるかを早期に判断するために、次の観点で「減額できる余地」を確認します。
- 要件定義の曖昧さ（仕様が確定していないのに成果責任を負わせていないか）
- 変更管理の欠如（追加要望が実質の仕様変更なのに、追加契約がない/記録がない）
- 検収・受入の効果（検収合格/暫定受入後に、どこまで追加請求できるか）
- 損害の拡大防止（発注側が回避可能な対策を取らず損害が膨らんでいないか）
- 責任制限条項（上限額、間接損害排除、特別損害の扱い、請求期限）
技術的な原因が争点になる場合は、社内の説明だけで固めず、第三者の技術者にログ・成果物・チケットをレビューしてもらい「技術的に言えること/言えないこと」を早めに仕分けると、交渉・訴訟でのブレが減ります。
追加費用の争い：仕様変更・追加要望と「無償対応」の線引き
追加費用は、発注側から見ると「当初の範囲内のはず」、受託側から見ると「追加要望だから別料金」という形で対立しやすい典型争点です。ここは法律論よりも、合意のプロセスと記録が中心になります。
- 見積・追加発注のやり取り（金額だけでなく、変更内容が特定されているか）
- スコープ定義（要件定義書等のどこまでが当初範囲か）
- 軽微変更の扱い（保守・瑕疵対応の範囲として無償に含む条項があるか）
- 発注側の承認者（現場担当の口頭了承が、契約上の合意といえるか）
受託側は、追加費用を請求する局面で「仕様変更の指摘→見積→承認→着手」の順番を崩すと、後で合意が否定されやすくなります。逆に発注側は、口頭やチャットだけで作業を進めさせると、後で“黙示の合意”と主張されるリスクがあるため、承認の基準と権限を明確にしておく必要があります。
納期遅れ（遅延損害）：起算点・帰責事由・ペナルティ条項を整理する
納期遅れの損害は、「いつまでに何を納める契約だったのか」と「遅れの原因がどちらにあるのか」で大きく変わります。特にシステム開発は、発注側の確認・受入・データ提供の遅れが連鎖して全体が遅れることが多いため、帰責事由の切り分けが重要です。
- 納期の定義（最終納品日か、検収完了日か）
- 遅延の起算点（いつから遅れていると評価できるか。仕様未確定の期間を含めるか）
- 発注側要因（要件確定の遅れ、レビュー放置、データ/環境提供の遅延、承認者不在）
- ペナルティ条項（遅延損害金・違約金の定め、上限、免責事由）
遅延が争点化している場合は、メールや議事録等の時系列で「ボトルネックがどこにあったか」を可視化すると、交渉の着地点（減額・追加納期・保守条件）を作りやすくなります。
逸失利益（機会損失）・間接損害はどこまで認められるか
売上減少や逸失利益（機会損失）、ブランド毀損などの間接損害は、システム障害と結びつけて主張されることがありますが、実務上は因果関係・金額の合理性・予見可能性のハードルが高く、責任制限条項で排除されているケースも多い類型です。
請求する側は、（1）障害の内容と期間、（2）障害がなければ得られたであろう取引・稼働の蓋然性、（3）算定式（粗利、成約率、過去実績）をセットで示す必要があります。請求される側（受託側）は、条項上の排除・上限に加え、他要因（市場要因、社内体制）や損害拡大防止の観点から争うのが典型です。
交渉・訴訟での実務：損害項目を分解して「落としどころ」を作る
損害賠償は感情的に対立しやすい一方、損害項目を分解して整理すると、合意しやすい部分と争う部分が見えます。交渉では次の順で棚卸しするのが実務的です。
- 事実：何がいつ起きたか（時系列）
- 原因：仕様/実装/運用/外部要因のどこか（技術レビューの範囲を決める）
- 責任：契約上の役割分担・協力義務・検収の効果
- 損害：再作業費、外注費、暫定運用費、遅延損害、間接損害を分けて算定
- 条項：責任制限、免責、通知期限、準拠法・管轄
訴訟を見据える場合でも、最初から全面対決にせず、「ここは認める（代替提供/保守の上積み）」「ここは争う（逸失利益など）」と線を引くことで、コストとリスクをコントロールできます。
請求期限・時効・通知期限：契約条項で短くなることがある
システム開発では、法律上の時効だけでなく、契約で「検収後◯か月以内に通知」「請求は◯年以内」などの期限が置かれることがあります。期限を徒過すると、請求できるはずの主張が通らなくなることがあるため、早い段階で条項とスケジュールを確認しましょう。
また、損害が継続して発生している（運用暫定費用が積み上がる等）場合は、損害の範囲を固定するためにも、どの時点までの損害を請求対象にするか（または争うか）を整理しておくと、交渉が進みやすくなります。
まとめ：システム開発の損害賠償で押さえるべき要点
- 瑕疵・バグは「要件との不一致」と「修補範囲の切り分け」で勝負が決まる
- 追加費用は合意プロセス（見積→承認→着手）の記録が最大の証拠になる
- 納期遅れは起算点と帰責事由（発注側要因/受託側要因）の可視化が重要
- 責任制限条項（上限・間接損害排除）と通知期限で、請求の上限が決まることが多い
- 交渉では損害項目を分解し、合意しやすい部分から着地を作る
請求する側は、まず「要件・検収・変更履歴」と「損害の根拠資料」を揃えて、請求項目を分解して提示すると交渉が進みます。請求される側（受託側）は、責任制限条項・発注側要因・検収の効果を早期に確認し、技術面はログ等の客観記録に基づいて反論できる体制を作ることが重要です。
坂尾陽弁護士
関連記事
企業法務の無料法律相談実施中！
- 0円！完全無料の法律相談
- 弁護士による無料の電話相談も対応
- お問合せは24時間365日受付
- 土日・夜間の法律相談も実施
- 全国どこでも対応いたします