「ベンダーが約束した機能が動かない」「納期が半年以上遅れた」「結局リリースできず数千万円が消えた」——システム開発の現場では、こうした炎上案件が珍しくありません。発注者として最後に頭をよぎるのが「損害賠償を請求できるのか」という問いです。本記事では、実際に損害賠償が争われたケースの傾向を整理し、認められる範囲と限界、訴訟前にできる現実的な対応を中小企業の経営者目線で解説します。
この記事の結論（3行）
- 損害賠償は理論上請求できるが、認められるのは「直接の損害」が中心で、逸失利益までは届かないケースが多い
- 契約書の責任制限条項・要件定義書の精度・打ち合わせ議事録の有無で、認容額は数倍動く
- 訴訟は時間とコストを食うため、和解・契約解除・追加対応の交渉で着地させる方が経営合理性が高いケースが多い
システム開発の損害賠償は「請求できる」と「認められる」が別物
最初に押さえておきたいのは、損害賠償を「請求すること」と「裁判所に認められること」は別物だという点です。請求書を内容証明で送る、訴状を提出する——ここまではどんな案件でも実行できます。一方、最終的に裁判所が認容する金額は、契約内容・要件定義書の精度・進行中のやり取りの記録によって大きく変わってきます。
- 「動かないシステムに払った金を返してほしい」は通りやすい
- 「動かなかった分の機会損失を払ってほしい」は通りにくい
- 「契約書に責任制限条項があると、認容額の上限はそこで止まる」
この3点が、システム開発訴訟の基本構造です。ここを理解しておかないと、「数千万円の損害賠償を取れるはずだ」と思い込んで訴訟に踏み切り、判決が出る頃には事業機会も消えている、という二重の損失につながります。
「直接の損害」と「間接の損害」の境目
裁判所が認める損害には、おおむね2つの層があります。直接の損害——既に支払った開発費用、追加で発生した修正費用、別ベンダーへの発注費用——は、ベンダー側の責任が認められれば返還が比較的通りやすい類型です。一方、間接の損害——システムが動かなかったことで失った売上、本来得られたはずの利益、社内人件費——は、因果関係の立証が難しく、認容されにくい傾向があります。
裁判例を見ると、発注者が「3,000万円払ったが動かないので3,000万円返してほしい」という訴えは通りやすく、「動かなかったことで本来1億円の売上が得られたはずだから1億円賠償しろ」という訴えは、ほぼ通らないと考えてください。
契約書の責任制限条項が認容額の上限を作る
システム開発契約書には、ほぼ必ず「責任制限条項」が入っています。「ベンダーの損害賠償責任は、本契約に基づき発注者が支払った委託料の金額を上限とする」といった文言です。これがあると、たとえ発注者側に大きな被害が出ても、認容額は契約金額の範囲に止まる、という結論になりやすくなります。
中小企業がベンダーと契約する際、この条項を意識せずにサインしてしまうケースが大半です。「事故が起きないだろう」前提で進めると、いざ事故が起きたときに賠償の天井がすでに決まっていた、という結果になります。
要件定義書と議事録が「責任の所在」を決める
裁判所が「ベンダーに責任あり」と判断する場合、根拠になるのは要件定義書と打ち合わせ議事録です。「この機能を入れる約束だった」「この納期で動かす合意があった」——これらが文書として残っていなければ、ベンダー側は「そんな約束はしていない」と主張できてしまいます。
口頭ベースで進めた案件ほど、裁判では発注者側が苦戦します。プロジェクト中にどれだけ記録を残すかが、後で損害賠償を請求するときの実弾の量を決めると言えます。
損害賠償が認められやすいケース3パターン
過去の判例傾向を整理すると、システム開発訴訟で発注者の損害賠償請求が認められやすいパターンは、おおむね3つに分類できます。
| パターン | 内容 | 認められる損害の範囲 | |---|---|---| | 完全不履行型 | 納期を過ぎても何も納品されない／動くものが一切ない | 既払い金の返還、別ベンダー再発注の差額 | | 重大な欠陥型 | 納品されたが基幹業務が動作せず、業務に重大な支障が出た | 修正費用、追加で発生した実費、一部の人件費 | | 説明義務違反型 | ベンダーが必要な技術的説明・リスク説明を怠り、発注者の意思決定を誤らせた | 既払い金の一部、追加で発生した費用 |
この3パターンに当てはまる場合、訴訟まで進めば一定の認容判決を得られる可能性があります。一方、「思ったような出来ではない」「使い勝手が悪い」レベルでは、ベンダー側の責任を立証するのが難しくなります。自社の案件がどのパターンに該当するかを判断したい場合は、業務改善・システム見積もりAI適正診断で状況を整理してから次の手を選ぶのが現実的です。
完全不履行型：払った金が戻ってくる可能性が高い
納期を過ぎても何も納品されない、デモすら動かない、リリース時期を再三延期して結局形にならない——これが完全不履行型です。このケースでは、契約解除と既払い金の返還請求が認められる可能性が高くなります。さらに、別ベンダーに再発注した費用の差額も、損害として認められる場合があります。
ただし、注意したいのは「発注者側の協力義務」の問題です。ベンダー側が「要件定義に発注者が協力してくれなかった」「仕様確認の回答に2か月かかった」と反論してくる場合、責任の一部が発注者側に振られる可能性があります。
重大な欠陥型：修正費用の範囲で認められやすい
納品されたが基幹業務が動かない、データが壊れる、月次処理が回らない——重大な欠陥型のケースです。このパターンでは、契約解除までは認められないものの、修正費用や、修正期間中に発生した追加実費が認められる傾向があります。
修正費用の見積もりは、第三者ベンダーに有償で出してもらうのが鉄則です。発注者側が独自に積算した金額は、裁判所に「過大」と判断されやすいためです。
説明義務違反型：プロのベンダーとしての注意義務違反
ベンダー側がプロとして当然説明すべきリスクを説明しなかった、技術選定の前提を誤って伝えた——こうした説明義務違反型のケースも、近年は認容判例が増えてきました。例えば「このパッケージで全要件をカバーできる」と説明しながら、実際は半分しかカバーできなかった、というケースです。
このパターンは契約書の責任条項を超えて損害賠償が認められる可能性がある一方、「プロとして当然説明すべきこと」の立証が難しい類型でもあります。
損害賠償が認められにくい・限界がある領域
逆に、システム開発訴訟で「請求しても認められにくい」「認められても金額が伸びない」領域もあります。
逸失利益（本来得られたはずの売上）
「システムが動いていれば月間1,000万円の売上が立ったはず」という逸失利益の請求は、裁判所はほぼ認めません。理由は単純で、「システムが動いていたら本当にその売上が立ったのか」を立証する手段がないからです。新規事業のシステムでは特に、市場が受け入れたかどうかの保証はなく、逸失利益の額は推測の域を出ません。
内部人件費・社内工数
プロジェクトに費やした社内担当者の人件費や、社内の他業務への支障も、損害賠償としてはほぼ認められません。仮に「炎上で半年間プロジェクトを引きずったために、社内担当者の人件費が2,000万円かかった」と主張しても、その人件費は「動こうが動くまいが社内で発生していた」と判断されます。
慰謝料・信用毀損
法人取引において、慰謝料や信用毀損による精神的損害は、ほぼ認容されません。「炎上案件で経営者として精神的負担を負った」という主張も、法的には損害として評価されにくい領域です。
認容額の上限：契約金額の範囲
責任制限条項がある契約書では、認容額は契約金額の範囲に止まるのが原則です。3,000万円の契約で1億円の損害が出ても、裁判所が認める額は契約金額前後に収束していきます。例外として、ベンダー側に重大な過失や故意があった場合は責任制限条項が無効化されるケースもありますが、立証のハードルは高くなります。
経営者目線で考える「訴訟に進むかの判断軸」
ここからが、本記事の本題かもしれません。法的に損害賠償を請求できる状態にあったとしても、訴訟に進むべきかどうかは別の経営判断です。経営者目線で訴訟を判断する軸は、3つあります。
第一に、「訴訟にかかる時間とコスト」と「想定される認容額」の比較です。システム開発訴訟は、一審判決まで2〜3年、控訴審まで含めると4〜5年かかるケースもあります。弁護士費用は着手金と成功報酬で数百万円規模。経営者の時間も訴訟準備で大きく食われます。3,000万円の認容を得ても、コストと時間で半分以上が消えるなら、経営合理性は低くなります。
第二に、「事業への影響」です。訴訟が動いている間、その案件に振り回されて新規事業や別の改善案件が止まる、という事態がよく起こります。係争中は経営者の意識がそこに割かれ、組織全体の判断速度も落ちます。事業の伸びしろが大きいフェーズでは、訴訟より「区切りをつけて前に進む」選択の方が経営合理性が高いケースが多くあります。
第三に、「ベンダーとの今後の関係」です。同じ業界の小さなコミュニティでは、訴訟を起こした事実が広がります。次のベンダー選びにも影響しますし、業界内での発注者としての評価にも関わってきます。ここまで含めて、訴訟に進む意義があるかを冷静に判断する必要があります。
訴訟に進む前に、「契約解除＋追加対応の交渉」「修正費用の値引き交渉」「別ベンダーへの引き継ぎを条件にした和解」など、現実的な着地点を項目別に整理してから判断するのをお勧めします。
仮想ケース：3,000万円の基幹システム炎上案件
ある中堅製造業で、3,000万円の基幹システム開発が炎上したケースを仮想で整理します。要件定義から半年、設計フェーズに入ってから9か月、当初12か月の予定が18か月を超えても結合テストに進めない状態でした。発注者側は契約解除と全額返還、加えて別ベンダーへの再発注差額1,500万円、合計4,500万円の損害賠償を弁護士経由で請求しました。
ベンダー側は「要件定義に発注者の協力が不足していた」「仕様変更が繰り返された」と反論。要件定義書には曖昧な記述が多く、議事録は半分以上が口頭ベースでした。弁護士からの想定回答は「訴訟まで進めば既払い金の60〜70%程度が認められる可能性があるが、判決まで2〜3年、弁護士費用は数百万円」というもの。
経営者は最終的に、訴訟ではなく和解の道を選びました。既払い金の50%返還、未払い分の支払い義務消滅、別ベンダーへの引き継ぎ協力、という条件で書面和解。返還額は訴訟の想定より少ない一方、半年で着地し、別ベンダーへの再発注がすぐに動き出しました。「金額の最大化」より「事業の早期再開」を選んだ判断です。このタイプの判断を整理したい経営者は、現状の事案を診断することから始めてください。
解決の方向性：炎上案件で経営者が取るべき5つの動き
最後に、システム開発が炎上した際、経営者が取るべき動きを5つに整理します。
- 全ての打ち合わせ記録と契約書類を即座に保全する
- 第三者ベンダーに「現状の納品物の評価」を有償で依頼する
- 弁護士に「訴訟と和解の想定線」を整理してもらう
- 別ベンダー候補に「引き継ぎ前提の見積もり」を取る
- 「金額の最大化」と「事業の早期再開」のどちらを優先するか経営判断する
この5つは順番が重要です。記録の保全を最初にしないと、後でベンダー側から「都合の良い書類だけ出している」と反論されます。第三者評価がないと、社内主観での損害額になり裁判所に通りません。弁護士相談を後回しにすると、時効や催告のタイミングを逃します。
全ての打ち合わせ記録と契約書類を即座に保全する
メール、チャットツールのログ、議事録、設計書、ソースコード——全てを保全してください。クラウドサービスを使っていた場合は、退会前にエクスポートを必ず行うこと。ベンダー側のサーバーにしかないデータは、契約解除と同時にアクセスできなくなる場合があります。
第三者ベンダーに「現状の納品物の評価」を有償で依頼する
現状のシステムにどれだけの「使える資産」と「使えない欠陥」があるか、第三者ベンダーに有償評価を依頼してください。評価書は裁判でも交渉でも実弾になります。費用は50〜100万円程度ですが、ここでの投資は後の交渉力を大きく変えます。
弁護士に「訴訟と和解の想定線」を整理してもらう
弁護士には「訴訟ルートと和解ルートそれぞれの想定線」を出してもらってください。具体的には、訴訟の場合の認容想定額・期間・費用、和解の場合の現実的な着地額・期間。これがないと、経営判断の比較ができません。
別ベンダー候補に「引き継ぎ前提の見積もり」を取る
並行して、別ベンダーに「今のソースコードを引き継いで、続きから開発する場合の見積もり」を取ってください。これがないと、現状のシステムを捨てるか活かすかの判断ができません。引き継ぎ前提の見積もりは、ゼロから作る見積もりより1.5〜2倍幅が出やすいので、複数社で比較を依頼するのが安全です。
「金額の最大化」と「事業の早期再開」のどちらを優先するか経営判断する
最後は経営判断です。訴訟で金額の最大化を狙うか、和解で事業の早期再開を選ぶか。多くの中小企業では、後者を選んだ方が事業全体への寄与が大きくなります。前者は「金額自体が事業の運命を左右する」規模の案件で初めて選択肢になります。
まとめ
システム開発の損害賠償は、理論上は請求できるものの、認められるのは「直接の損害」が中心で、逸失利益や内部人件費は届きにくい領域です。契約書の責任制限条項・要件定義書・議事録の有無で認容額は数倍変動します。訴訟ルートは2〜3年の時間と数百万円の弁護士費用を食うため、和解での早期着地が経営合理性に合うケースが多いと言えます。
大事なのは、炎上した時点で「金額の最大化」と「事業の早期再開」のどちらを優先するか経営判断することです。記録の保全、第三者評価、弁護士による訴訟・和解の想定線、別ベンダーの引き継ぎ見積もり——この4点を揃えてから判断する流れが、現実的な解決の方向性につながります。