システム開発の失敗事例7選｜損害賠償に発展した実際の裁判例と対策

システム開発の失敗事例は、経済産業省・IPAの公表資料や実際の訴訟記録に数多く残っています。その多くが「要件定義の不備」「納期遅延」「契約形態の認識ズレ」という共通パターンから始まり、最終的に損害賠償請求へと発展します。

最も有名な事例では、スルガ銀行が日本IBMに勘定系システム開発を委託したプロジェクトが破綻し、最高裁判所（2015年7月8日決定）で約42億円の賠償が確定しています。億単位の損害が生じる以前に、同じ失敗パターンを知っておくことが最大のリスク管理です。

この記事では、実際の裁判例と経済産業省・IPA公表のトラブル事例集をもとに、 システム開発の失敗事例7選 と、各パターンで裁判所がどう判断したかを解説します。また、発注者として押さえておくべき契約上の対策もあわせてまとめました。

システム開発が失敗する主な原因

IPA（情報処理推進機構）が公表した「情報システム・ソフトウェア取引トラブル事例集」（経済産業省委託、2010年3月）によると、システム開発トラブルの主な原因は以下の4つに集約されます。

失敗原因	発生頻度	主な争点
要件定義の不備・曖昧さ	最多	「言った・言わない」の対立
発注者の協力義務違反	多い	情報提供の遅延・仕様決定の先送り
仕様変更の管理不足	多い	追加費用・納期延長の未合意
契約形態の認識ズレ	多い	請負か準委任かの解釈相違

（出典: 経済産業省『情報システム・ソフトウェア取引トラブル事例集』2010年3月 https://www.meti.go.jp/policy/it_policy/softseibi/trouble%20cases.pdf）

これらのパターンごとに、実際の裁判例を確認していきましょう。

失敗事例1：要件定義の不備による「言った・言わない」の対立

【事例の概要】

経産省トラブル事例集に記録された典型パターンです。ある製造業者がECサイト構築を外注した際、発注者は「クレジットカード決済だけでなく電子マネー決済も標準実装される」と認識していましたが、要件定義書には「決済機能の実装」とのみ記載されていました。開発側はクレジット決済のみを実装して納品し、発注者が機能不足を理由に損害賠償を請求するトラブルへと発展しました。

【裁判所の判断基準】

このパターンの裁判では、 開発側の「ヒアリング不足（プロジェクトマネジメント義務違反）」 と 発注側の「確認漏れ（協力義務違反）」 の双方が問われ、過失相殺で賠償額が減額されるケースが多くなります。東京地裁の判例では、発注者側にも「システムの内容を確認・合意する義務がある」として双方の過失が認定されています。

【発注者として取るべき対策】

口頭でのやり取りは議事録に残し、すべての機能要件を「対応する機能」「対応しない機能」の両方を明記した仕様書で確定させてください。非エンジニアにも理解できる 要件定義書の書き方と必須項目 を活用し、合意のエビデンスを残すことがトラブル防止の第一歩です。

失敗事例2：発注者の協力義務違反による開発頓挫

【事例の概要】

東京地裁（平成16年3月10日判決）に類似した事例です。業務管理システムの刷新プロジェクトで、開発会社が既存システムのデータ仕様書や連携API情報を何度も要求したにもかかわらず、発注者が社内調整を理由に提出を3か月以上遅らせました。開発チームは実質的に待機状態となり、スケジュールが崩壊。開発会社は契約解除と待機期間中の人件費相当額の損害賠償を請求しました。

【裁判所の判断基準】

裁判所は、発注者にもシステム完成に向けて必要な情報を提供する 「協力義務」 があると判断します。平成16年の判決では「ベンダーはプロジェクト管理義務を負うが、その義務の履行にはユーザーの協力が前提となる」として、発注者側の協力義務違反が認定されました。

【発注者として取るべき対策】

契約書に「発注者が提供すべき資料とその提出期限」を明記してください。定例会議の議事録でタスクの担当者（ボールがどちらにあるか）を毎回確認し、自社内にも専任の担当者（プロダクトオーナー相当）を設置することが法的リスクを下げます。

失敗事例3：仕様変更の連続による納期遅延と逸失利益

【事例の概要】

IT業界に特有のこのパターンは、経産省トラブル事例集でも「仕様変更の管理不足」として最頻出します。スマートフォンアプリの開発で、プロトタイプを確認した発注者が「競合アプリと同じ機能を追加したい」「デザインを大幅変更したい」と度重なる仕様変更を要求しました。開発側はその都度対応しましたが、リリースが半年遅延。発注者はリリース遅れによる逸失利益（本来得られるはずの売上）の賠償を開発会社に請求しました。

【裁判所の判断基準】

遅延の根本原因（帰責事由）が発注者の仕様変更にあると認定された場合、逸失利益の請求は棄却されます。裁判例では「追加要求の記録がなければ、開発側が自発的に行った変更と判断されるリスクがある」とされており、口頭での仕様変更承諾が開発側に不利に働いたケースもあります。

【発注者として取るべき対策】

仕様変更が発生した際は、変更内容・追加費用・納期の再設定を 必ず書面で合意 してください。「変更管理シート」として残しておくことが、後の紛争防止に直結します。

失敗事例4：請負か準委任か、契約形態の認識ズレ

【事例の概要】

AI・機械学習など要件が固まりにくい領域で特に多いパターンです。開発会社は「技術支援を行う準委任契約」のつもりで参加していましたが、発注者は「成果物の完成を約束する請負契約」と認識していました。システムが完成しないまま予算が尽きた時点で、発注者が完成義務の不履行として損害賠償を請求しました。

【裁判所の判断基準】

契約書の記載が曖昧な場合、裁判所は 実態 に照らして契約の性質を判断します。支払い方法（成果物ベース vs 工数ベース）、スコープの定め方、完成の定義などを総合的に評価し、実態が請負と認定されると開発側が完成責任を負います。東京高裁の裁判例でも「契約書名称に関係なく、実質が請負ならば完成義務がある」と判断した事例があります。

【発注者として取るべき対策】

業務委託の請負契約と準委任契約の違い をあらかじめ理解した上で、フェーズごとに契約形態を使い分ける「多段階契約」が安全です。要件定義フェーズは準委任、開発・テストフェーズは請負、という構成が一般的です。

失敗事例5：過失相殺による賠償額の大幅減額

【事例の概要とスルガ銀行vs日本IBM事件】

システム開発の損害賠償事例で最も注目すべき実例が、 スルガ銀行と日本IBM（現・日本アイ・ビー・エム）の訴訟 です。スルガ銀行は勘定系システムの刷新を日本IBMに委託（総額約95億円で基本合意）しましたが、プロジェクトは度重なる仕様調整と管理不全により破綻しました。

スルガ銀行が約200億円超を請求する訴訟を提起し、東京地裁第一審（2012年）では約74億円の支払いを命じる判決が下されました。その後、東京高裁（2013年9月26日判決）では過失相殺が適用されて賠償額が約42億円に減額され、最高裁判所が2015年7月8日に上告棄却・特別抗告棄却の決定を下し、約42億円の支払いが確定しました。

（出典: スルガ銀行「日本アイ・ビー・エム株式会社に対する損害賠償請求訴訟の決定について」2015年7月9日 https://www.surugabank.co.jp/surugabank/kojin/topics/150709.html）

【裁判所の判断基準】

この判決では、日本IBMの プロジェクトマネジメント義務違反 が認定されると同時に、スルガ銀行側の「協力義務は果たしていた」とも判断されました。ただし、過失相殺によって第一審の74億円から約42億円へ大幅に減額されています。開発側の全責任が100%認められるケースはまれで、発注者側の体制・関与度が賠償額に直結します。

【発注者として取るべき対策】

自社内に専任のプロジェクト担当者を置き、ベンダーからの確認事項に期限内に対応する体制を整えることが、法的リスク管理の基本です。大規模プロジェクトほど「発注者も責任を負う」という裁判所の視点を念頭に置いてください。

失敗事例6：客観的な検収基準がないことによる納品トラブル

【事例の概要】

社内ポータルサイトの開発で、システムは完成したものの、発注者が「ページの読み込み速度が遅くて実業務に使えない」として検収を拒否し、最終支払いを保留しました。しかし、契約書にも要件定義書にも「レスポンスタイムは○秒以内」といった非機能要件（性能要件）が一切記載されていませんでした。

【裁判所の判断基準】

客観的な合格基準が存在しない場合、裁判所は 機能的に動作するシステムが完成している と判断する傾向があります。東京地裁の裁判例では「性能要件が契約書・仕様書のいずれにも記載されていない以上、ベンダーの完成義務は機能の実装をもって履行されたと認める」として、発注者に委託費用の全額支払いを命じた判決があります。

【発注者として取るべき対策】

機能要件だけでなく、処理速度・同時アクセス数・稼働率などの 非機能要件を数値で明記 することが不可欠です。「受け入れテストの合格基準」を初期フェーズで合意しておくことで、納品トラブルを防げます。発注者が受け取るべき成果物の全体像は、システム開発の成果物とテスト計画の基本 も参考にしてください。

失敗事例7：検収後に発覚した重大バグと契約不適合責任

【事例の概要】

顧客管理システムの納品・検収完了から2か月後、特定の操作でシステム全体がダウンしデータが消失する重大なバグが発覚した事例です。開発会社は「検収は終わっている」と主張しましたが、民法の 「契約不適合責任」（旧：瑕疵担保責任） に基づき、納品物が契約の目的に適合していない重大な欠陥であると認定されました。

【裁判所の判断基準】

2020年の民法改正（債権法改正）により、旧来の「瑕疵担保責任」は「契約不適合責任」に整理されました。発注者は不適合を知った時から1年以内にベンダーへ通知することで、修補請求・代金減額請求・損害賠償請求・契約解除を行使できます。検収後であっても、業務の根幹に影響する重大な欠陥は契約不適合責任の対象となります。

【発注者として取るべき対策】

契約書に「どのレベルの不具合をいつまで無償修正するか（契約不適合責任の追及期間）」を明記してください。通常は納品から6か月〜1年程度で設定されます。軽微な仕様の不一致と業務停止を招く重大な欠陥では対応義務の範囲が異なるため、具体的な基準を合意しておくことが重要です。

契約内容の整備には 業務委託契約書テンプレートと必須項目 も参考にしてください。

損害賠償額の上限と契約での備え方

実務上、システム開発契約では 損害賠償の上限を委託料の範囲内に限定する条項 を設けるのが一般的です。しかし、スルガ銀行 vs 日本IBM事件のように、開発側に故意または重大な過失があると認定された場合は、この上限条項が無効とされて実損額全額の賠償を命じられることがあります。

状況	賠償の範囲
通常の過失（軽過失）	契約書の上限条項が有効。委託料の範囲内に限定されることが多い
重大な過失・故意	上限条項が無効と判断される場合あり。実損額全額が対象になりうる
発注者にも過失がある場合	過失相殺が適用され、認容額が減額される

契約書に上限条項を設けることは発注者にとっても重要です。開発会社が倒産・廃業した場合に回収できる金額が限定されるため、プロジェクトの規模に応じてIT賠償責任保険（システム損害賠償保険）の活用も検討してください。

よくある質問

システム開発の損害賠償額の相場はどのくらいですか？

規模によって大きく異なります。中小規模の案件では委託料相当額（数百万〜数千万円）の範囲内で解決するケースが多く、大規模案件ではスルガ銀行 vs 日本IBM事件（42億円確定）のように億単位に達する場合もあります。実務上は契約書に「賠償上限は委託料の範囲内」と定めることが一般的ですが、重大な過失がある場合はこの上限が無効になることがあります。

仕様変更が原因で納期が遅れた場合、どちらの責任になりますか？

発注者が仕様変更を要求したことが根本原因であれば、発注者側の責任となり開発側への賠償請求は認められません。ただし、この判断には「仕様変更の記録・合意書面」が不可欠です。口頭での変更指示しか存在しない場合、後の裁判で証明が困難になります。変更が発生した時点で必ず変更管理書を作成し、納期の再設定を書面で合意してください。

発注者にも過失があると認定されるのはどんな場合ですか？

裁判例が示す発注者側の「協力義務違反」の典型例は以下のとおりです。(1) 開発に必要な情報・資料の提供を長期間怠った場合、(2) 重要な仕様決定の会議を繰り返し欠席・延期した場合、(3) 専任のプロジェクト担当者を置かず、開発会社の質問に回答しなかった場合。こうした事実が認定されると過失相殺が適用され、賠償請求額が大幅に減額されます。

検収後に発覚したバグは必ず無償修正してもらえますか？

軽微なバグ（業務に支障がない）だけでは直ちに無償修正を強制できません。契約書で定めた「受け入れテストの合格基準」を満たしていない場合、またはシステムが頻繁にダウンするなど業務の根幹に影響する重大な欠陥がある場合に、契約不適合責任として修補・賠償を請求できます。無償対応の期間は契約書に明記しておくことが重要です。

まとめ：システム開発の失敗を防ぐ5つのポイント

システム開発の失敗事例と損害賠償裁判例から共通して見えてくる教訓は、以下の5点です。

• 要件定義の徹底: 機能要件・非機能要件・検収基準をすべて文書化し、客観的な合格基準を設ける
• 契約形態の適切な選択: フェーズに応じて請負契約と準委任契約を使い分け、完成責任の所在を明確にする（請負と準委任の違いと選び方 参照）
• 発注者としての協力義務を果たす: 開発会社に丸投げせず、必要な資料提供や意思決定を期限内に行う
• 仕様変更のルール化: 変更が発生したら必ず追加費用・納期の見直しをセットで合意し、変更管理書に残す
• 契約不適合責任の期間設定: 検収後に発覚するバグに備え、無償対応の期間と損害賠償の上限を契約書で明記する

スルガ銀行 vs 日本IBM事件が示すように、発注者・開発会社の双方が責任を分担するのが現実です。適切なリスク管理と密なコミュニケーションで、プロジェクトを成功に導いてください。

初期費用を抑えながら安全にプロジェクトを進めるための資金計画については、新規事業の立ち上げを成功に導く資金調達術！システム開発費用の相場とコスト削減のコツ も参考にしてください。