システム開発の失敗事例｜訴訟・統計・AI時代の失敗パターンまで完全解説【2026年版】

「200億円超の訴訟になり最終的に約42億円の賠償命令」「55億円が無駄になり開発中断」「30年もの基幹システム刷新で5億円賠償命令」——これらは推測ではなく、すべて公的判決資料・行政報告書・大手報道に基づく実在のシステム開発失敗事例です。発注側担当者の多くは「次は失敗したくない」という強い動機で本記事にたどり着きます。

本記事では、システム開発の失敗を実在訴訟・公的統計・実務知見の3層で解説します。さらに従来の失敗パターン10選に加えて、AI/生成AI開発に特有の新しい失敗パターン6選を独自に整理し、契約類型別の責任分界マトリクス、発注前から受入までの工程別チェックリスト40項目まで掲載しています。

結論: 失敗の根本原因は「技術」ではなく「仕組み」にある

先に結論を述べます。システム開発が失敗する根本原因の大半は、技術力不足ではなく「要件定義の曖昧さ」「コミュニケーション不全」「意思決定の遅さ」「契約と責任分界の曖昧さ」に起因します。 逆に言えば、プロジェクトの「仕組み」を事前に設計すれば、失敗リスクを大幅に低減できます。

この記事で紹介する大規模失敗事例も、技術的に不可能だったから失敗したわけではありません。いずれも「人と仕組み」の問題が根本にあります。さらに2026年現在は、AI/生成AI開発という不確実性の高い領域が加わり、従来の失敗予防だけでは防げない新しいパターンが生まれています。

統計で見るシステム開発の失敗率

システム開発の失敗率については、複数の公的調査で定量化されています。重要な指標は次の3つです。

主要4機関の失敗率データ

Standish Group「CHAOS Report 2020」（同社公式サンプル）は約5万件のプロジェクト分析から、何らかの問題を抱えるプロジェクトが69%にのぼることを示しました（Henny Portman氏による2020年版レビューも参照）。さらに同レポートはプロジェクト規模別の差を強調しており、「Grand/Large」規模区分では成功率が10%以下、小規模プロジェクトは90%前後の成功率と、規模で結果が大きく分かれます。

JUAS「5:5:3の法則」と最新データ

JUAS（日本情報システム・ユーザー協会）のソフトウェアメトリックス調査は、日本のシステム開発プロジェクト数千件を継続調査しており、**500人月以上のプロジェクトでは工期遅延が50%、予算超過が50%、品質に不満が残るケースが30%**という「5:5:3の法則」を示しました（2008年版）。10年以上経った2026年現在も、大規模プロジェクトの構造的課題は変わっていません。

JUAS「ソフトウェア・メトリクス調査2025」では次の数値が示されています。

• 標準工期 = 3.23 × ∛投入工数（例: 125人月のプロジェクトは16.15ヶ月が標準）
• 計画工期は標準工期の1.04倍とほぼ標準工期に近い
• 納期を優先したプロジェクトの予定通り完了率は74.5%、20%以上の大幅遅延は8.2%
• 納期を優先しなかったプロジェクトの20%以上遅延は19.6%
• 平均欠陥数: 計画工期が標準工期以上のプロジェクト5.94件 ＜ 計画工期が標準工期未満のプロジェクト11.2件

JUASの分析が示すのは「標準工期より余裕を持った計画工期を設定し、計画段階で納期遵守を優先することで、遅延と欠陥の両方を大幅に抑制できる」という事実です。逆に言えば、無理な短納期を要求するプロジェクトはほぼ確実に破綻します。

経済産業省DXレポート — 2025年以降の経済損失

経済産業省「DXレポート」（2018年）は、レガシーシステムの技術負債が未解決のまま2025年を迎えた場合、2025年以降に年間最大12兆円の経済損失が発生すると警鐘を鳴らしました。さらに約43万人のIT人材不足が2025年に発生するため、システム開発の難易度はますます上がります。技術負債の側面については技術的負債の解消ガイドで詳しく解説しています。

このような環境では、1度の失敗が次の改修プロジェクトの原資を奪い、企業全体のIT競争力を10年単位で後退させるリスクがあります。だからこそ、過去の失敗事例から学ぶ価値が極めて大きいのです。

実際に起きた大規模失敗事例 6 選

「事例」と称しながら実在企業を伏せている解説記事が多い中、本章では公的判決資料・行政報告書・大手報道に基づく実在事例6件を取り上げます。判決文・新聞報道・判例コメンタリーから事実を整理しました。

事例 1: スルガ銀行 vs 日本IBM｜プロジェクトマネジメント義務違反で約42億円賠償

事案の概要

スルガ銀行は2000年頃から次世代システムの検討を開始し、2004年に日本IBMが米国Corebank社のパッケージソフトを使った提案を行い、両社で約95億円の基本合意書を締結しました（Westlaw Japan判例コラム、SOFTIC研究会資料）。

その後、日本IBMはCorebankを国内銀行業務に適用するためのカスタマイズ難易度を見誤り、要件定義段階から納期と費用の不確実性が顕在化しました。スルガ銀行は2008年にプロジェクトを中止し、両社が相互に提訴する訴額200億円超の大型訴訟に発展します。

判決と争点

控訴審の核心は「プロジェクトマネジメント義務」の認定です。東京高裁は、ベンダーは「専門家として、開発の遅延や費用増大が見込まれる場合に、その状況を発注者に説明し、必要に応じて開発計画の見直しや中止を提案する義務がある」と判示しました。一方で、最終合意書を交わす2005年9月以前の企画・提案段階については「IBMに不法行為が成立するほどの過失はない」とし、賠償範囲を限定したのも特徴です。

この事例から学ぶ3つの教訓

1. ベンダーの「専門家としての警告義務」は契約書に明記されていなくても発生する — パッケージソフトのカスタマイズ難易度は提案段階で評価し、不確実性を発注者に正確に伝える運用を契約書・議事録で証跡化する
2. プロジェクト破綻の責任は「いつから」発生するかを区切れる — 提案段階・要件定義段階・本格開発段階のフェーズごとに合意書を分割し、各段階の責任範囲を明文化する
3. 訴訟になったときに勝敗を分けるのは「議事録・進捗報告書・警告メール」の証跡 — 定例会議事録は必ず両社署名で残し、リスク警告は口頭ではなくメール+署名付き文書で行う

事例 2: みずほ銀行 基幹システム統合

事案の概要

みずほフィナンシャルグループは、2002年の合併時に旧3行（第一勧業銀行・富士銀行・日本興業銀行）のシステム統合に着手しました。当初は既存システムの「つなぎ合わせ」で対応しましたが、2011年の東日本大震災時に大規模なシステム障害が発生。その後、日経新聞・日経xTECHなどの報道によると約4,000億円規模を投じて新基幹システム「MINORI」を開発し、2019年に完了しました。しかし2021年にも複数回のシステム障害が発生し、金融庁から業務改善命令を受けています（金融庁「みずほ銀行及びみずほフィナンシャルグループに対する行政処分について」2021年11月26日）。

失敗の本質

• 旧3行の文化・業務プロセスの違いを技術で解決しようとしたこと
• システム統合の意思決定が組織の政治力学に左右されたこと
• 障害発生時の復旧体制とエスカレーションルールが不十分だったこと

この事例から学ぶ3つの教訓

1. システム統合は技術プロジェクトではなく組織統合プロジェクト — 技術的な整合性だけでなく、業務プロセスの統一と運用体制の構築を同時に進める
2. 障害発生時の意思決定権を事前に明確化する — 障害対応の経営判断には数時間しか猶予がないため、CIO/CTOへの権限移譲を平時に文書化する
3. 大規模刷新後も「障害監視と継続的改善」を制度化する — リリースで終わりではなく、稼働後の運用フェーズに同等の経営資源を投じる

事例 3: 特許庁 基幹システム刷新｜入札最低価格落札の落とし穴で55億円が無に

事案の概要

特許庁は2004年、特許審査期間を2年から1年に短縮するための基幹システム刷新を立ち上げました。2006年11月の一般競争入札にはNTTデータ・日立・東芝ソリューションの3社が参加し、東芝ソリューションが予定価格の約6割という99億2,500万円で落札しました（日経xTECH、ROBOTEER）。

何が起きたか（時系列）

この事例から学ぶ3つの教訓

1. 「最低価格落札」は技術力評価を実質的に無効化するリスク — 入札・相見積もりでは技術評価点と価格点の重み付けを事前に明示し、「予定価格の何%を下回る場合は説明責任を求める」ルールを設計する
2. CIO補佐官・PMOを置いただけでは大規模プロジェクトは制御できない — 特許庁案件では民間からCIO補佐官を高額報酬で招聘していたが破綻を防げなかった。意思決定プロセス・エスカレーション基準・予算再承認フローまで設計しないと「補佐官がいるだけ」の体制になる
3. 進捗の「異常値」は最初の3ヶ月で必ず現れる — 開発開始直後の遅延・要件追加・コミュニケーション問題は、後の致命的失敗の予兆。最初の3ヶ月で**プロジェクト中断の判断基準（KPI）**を契約書に組み込む

事例 4: 京都市 vs システムズ｜自治体システムが教える検収基準の重要性

事案の概要

京都市は約30年前からNEC製メインフレーム上で稼働させていた基幹システム（国民健康保険・徴税・住民基本台帳など18業務）を、老朽化対策と運用費削減のため2013年度からオープン化することにしました。複数の段階で東京のIT企業「株式会社システムズ」に発注しましたが、作業遅延を理由に契約が解除されます（時事ドットコム、システム開発失敗.com、日経xTECH 京都市基幹刷新失敗をめぐる争い）。

訴訟の展開と判決

判決はシステムズの責任を主に認めつつ、京都市側にも要件定義段階での協力義務違反を認定し、両社双方に支払い命令を下しました。

この事例から学ぶ3つの教訓

1. 発注者にも「協力義務」がある — 自治体・大企業特有の業務要件を伝えるのは発注者の責任。要件ヒアリングへの非協力・意思決定の遅延・現場担当者の確保不足は、後の訴訟で発注者側の過失として認定される
2. 検収基準は「機能要件」だけでなく「業務シナリオ」で定義する — 18業務それぞれの業務シナリオに対する受入基準を契約締結時に文書化しないと、納品物の合否判定で揉める
3. 大規模プロジェクトは「全完成型」ではなく「業務単位の段階リリース」で発注する — 18業務一括ではなく、業務ごとの個別契約とフェーズ完了報告で進めれば、1業務の失敗が全体破綻に直結しない

レガシーシステムの段階的刷新の具体的手法はレガシーシステム刷新ガイドで解説しています。

事例 5: 旭川医科大学 電子カルテシステム（報道ベース）

事案の概要

旭川医科大学は電子カルテシステムの開発をNTT東日本に発注しましたが、開発が大幅に遅延し、大学側がNTT東日本に対して損害賠償を求めて提訴したと報道されました。日経xTECH・ITmedia等の報道では、双方の主張・要件追加の経緯・判決額について複数の段階で報じられています。本記事では報道時点の情報をもとに、専門性の高い業務システムに共通する失敗構造を抽出します（個別の判決日・確定額は報道機関の最新記事で必ず確認してください）。

報道から読み取れる失敗構造

• 医療現場の多様な業務フローを事前に十分に調査しなかったこと
• 現場の医師・看護師からの要望が際限なく追加され、スコープが膨張したこと
• ベンダー側が**「できません」と言えない**力関係にあったこと

この事例から学ぶ3つの教訓

1. 専門性の高い業務システムでは現場ヒアリングを「最初に集中投下」する — 開発開始後の追加要望が雪崩を打って来ない構造を、要件定義段階で作る
2. 現場ユーザーの要望はすべて受け入れず、MoSCoW法で優先順位を付ける — 「全部入り」志向は専門業務ほど破綻しやすい
3. ベンダー側に「断る権利」を契約で保障する — スコープ外要望はCRプロセスを経ないと着手しないことを契約条項として明記する

事例 6: 野村證券 vs 日本IBM 証券システム開発（報道ベース）

事案の概要

野村證券は証券取引用のシステム開発を日本IBMに発注した後、開発の遅延・品質問題を理由に日本IBMに対する損害賠償請求訴訟を提起したと報じられました。本事案については請求額・判決日・確定状況について報道に揺らぎがあるため、本記事では「報道された事案」として、ベンダー・ユーザー双方の責任構造を抽出することに焦点を当てます。最新の判決動向は報道機関の続報を必ず確認してください。

報道から読み取れる失敗構造

• 発注側の協力義務（仕様確認・レビュー・意思決定）が不十分だったこと
• 受注側のプロジェクト管理義務（リスク報告・スケジュール管理）が不十分だったこと
• 契約段階で成果物の定義と検収基準が曖昧だったこと

この事例から学ぶ3つの教訓

1. 大規模ユーザーでも発注者の協力義務は免除されない — スルガ銀行判決と同じく、ベンダーへの「丸投げ」体制では発注者側責任が認定される
2. プロジェクトマネジメント義務は契約金額に比例して重くなる — 大型案件では、ベンダーは経営層レベルでのリスク開示が求められる
3. 検収基準は契約締結時に文書化する — 検収段階での争いは契約書の不備が原因であることが多い

6 事例に共通する失敗要因

フェーズ別・失敗パターン 10 選と具体的な対策

大規模事例から共通する失敗要因を抽出し、開発フェーズ別に10のパターンに整理しました。

要件定義フェーズの失敗

パターン 1: 目的が曖昧なまま開発に入る

症状: 「とりあえず作り始めて、動くものを見ながら決めよう」で開始したプロジェクトは、開発中盤で「思っていたのと違う」が頻発し、手戻りの連鎖に陥ります。

典型的なケース: 基幹システムのリプレースを「現行と同じ機能」という要件で発注したが、「現行と同じ」の解釈が発注側と受注側で異なり、テスト段階で多数の仕様齟齬が発覚。納期が大幅に延長し、追加費用が当初見積もりの数十%に達するケースは、JUASソフトウェア・メトリクス調査でも工期遅延・予算超過の主要因として継続的に報告されています。

対策:

• 要件定義に 最低 2 ヶ月 を確保する（業界の一般的な推奨値として全体工期の 20% 以上が目安。JUAS 2025 の工程比率データでも要件定義の工期比率は 20% が標準）
• ビジネス目的と KPI を先に定義し、システム要件はそこから逆算する
• 要件定義書を「機能一覧」ではなく「業務目的→優先順位→例外シナリオ→受入基準」の4層で構造化する
• プロトタイプ（画面モック）で関係者の合意を得てから開発に入る
• 要件定義書には「やらないこと（スコープ外）」を必ず明記する

パターン 2: 「現行踏襲」で要件を定義する

症状: 「現行システムと同じ機能」を要件にすると、現行の業務フローに含まれる非効率やレガシーな仕様がそのまま引き継がれます。さらに「現行と同じ」の定義が人によって異なり、認識齟齬の温床になります。

対策:

• 「現行踏襲」ではなく、業務フローを基に要件を再定義する
• 現行機能の棚卸しを行い、使用頻度と業務インパクトで優先順位を付ける
• 刷新を機に不要な機能を廃止する勇気を持つ
• 新システムで実現したい業務改善の目標を先に設定する

パターン 3: ステークホルダーの巻き込み不足

症状: プロジェクト開始時に情報システム部門だけで要件を固め、現場の業務部門や経営層を巻き込まなかった結果、開発後半またはリリース後に「聞いていない」「使えない」という声が上がります。

対策:

• プロジェクト開始時にステークホルダーマップを作成し、関与すべき人を特定する
• キーユーザー（各部門の代表者）を選任し、要件レビューに参加させる
• 経営層には月次でプロジェクト状況を報告し、意思決定を求める
• 現場へのヒアリングは最低 3 部門以上で実施する

設計・ベンダー選定フェーズの失敗

パターン 4: 価格だけでベンダーを選定する

症状: 見積もりが最も安い会社に発注した結果、経験の浅いエンジニアがアサインされ、品質が低いコードが納品される。修正コストが膨らみ、最初から適正価格の会社に依頼した方が安く済んだという結果に至りやすい構造があります。特許庁の事例（東芝ソリューションが予定価格の6割で落札→55億円が無駄に）は最低価格落札の典型的な失敗例です。

典型的なケース: 複数社から見積もりを取得し最安値の会社に発注したが、その会社が下請け・孫請けに再委託しており、実際の開発者とクライアントの間に複数層のコミュニケーション障壁が存在。仕様の伝達ミスが頻発し、結局契約を解除して別の会社に再発注する——多重下請け構造に起因するこうしたパターンは、経済産業省「DXレポート」でも日本のIT業界の構造的課題として指摘されています。

対策:

• 見積もりは 最低 3 社 から取得し、**内訳（人月単価・工数・管理費）**を比較する
• 安さの理由を確認する（オフショア活用なのか、工数を削っているのか）
• 再委託の有無と層数を契約時に確認する
• 過去の類似プロジェクトの実績と体制を確認する
• 入札・相見積もりでは技術評価点と価格点の重み付けを事前に明示する
• 開発パートナーの選び方 7 つの基準に基づいて総合評価する
• 費用の相場感は 開発費用ガイド 2026 で事前に把握しておく

パターン 5: 技術選定のミスマッチ

症状: 最新のトレンド技術を採用したが、開発チームに十分な経験がなく、開発速度の低下と品質問題が発生。あるいは、要件に対して過剰に複雑なアーキテクチャを採用し、開発・運用コストが膨張するパターン。

対策:

• 技術選定は要件とチームのスキルセットの両方を考慮して判断する
• 新技術を採用する場合は、PoC（概念実証）を先に実施して技術的リスクを検証する
• 「枯れた技術」を選ぶことがリスク低減策として正当な判断であることを認識する
• ベンダーの提案する技術スタックについて、そのベンダーでの採用実績を確認する

開発フェーズの失敗

パターン 6: スコープクリープ（要件の膨張）

症状: 開発中に「ついでにこの機能も」「やっぱりこの画面も変えたい」と追加要件が次々に入り、プロジェクトの範囲が際限なく広がっていきます。

典型的なケース: ECサイトやポータルサイトのリニューアルプロジェクトで、当初の画面数が追加要件により2倍以上に膨張し、開発期間・予算ともに当初計画の2倍を超える構造は、JUASソフトウェア・メトリクス調査でも変更管理プロセス未整備のプロジェクトで継続的に観測されています。

対策:

• 要件定義書に スコープ外の明示（「今回やらないこと」リスト）を含める
• 追加要件は 変更管理プロセス（Change Request: CR）（影響評価 → 承認 → スケジュール調整）を経る
• 追加要件のコスト・スケジュール影響を毎回定量的に提示する
• 「軽微な変更」の閾値（例: 4時間以内）を契約で明示しておくと現場が判断しやすくなる
• 「Phase 1 で MVP をリリースし、Phase 2 で追加機能」の段階的アプローチを採用する

パターン 7: コミュニケーション断絶

症状: 発注側と受注側の間で定期的なコミュニケーションがなく、数ヶ月後に「できあがったもの」を見たら期待と大きくずれていたパターン。

典型的なケース: ベンダーに要件定義書を渡した後、数ヶ月間ほぼ接触なし。中間報告で初めて画面を確認したところ、UIの設計思想が根本的に異なっており、それまでの作業の大部分がやり直しになる——ウォーターフォール型開発に共通する構造的パターンです。スルガ銀行訴訟が示したように、議事録・進捗報告書・警告メールの証跡が訴訟時の生命線になります。

対策:

• 週次の定例ミーティング を必須にする（30 分〜1 時間で十分）
• 2 週間ごとに 動くデモ を確認する（アジャイル開発のスプリントレビュー）
• 仕様の確認・決定は 文書化（議事録・仕様確認書）し、口頭だけで済ませない
• コミュニケーションツール（Slack・Teams 等）で日常的な情報共有の場を設ける
• **RACI（Responsible・Accountable・Consulted・Informed）**を明文化し、各タスクの「実施者・最終責任者・相談先・報告先」を表にする
• エスカレーション基準を契約書に組み込み、「予算超過X%」「工期遅延Y日」を超えたら自動的に経営層会議が招集される運用にする

パターン 8: 属人化・ブラックボックス化

症状: 特定のエンジニアだけがコードを理解している状態で、そのエンジニアが異動・退職すると、保守も改修もできなくなります。技術的負債の蓄積メカニズムはこのパターンが温床になります。

対策:

• ベンダー側に**「キーパーソンの離脱時には30日前通知＋引き継ぎ計画書の提出」**を契約に明記する
• コードレビューを必須にし、2 人以上がコードを理解している状態を維持する
• 設計ドキュメント（アーキテクチャ図、API 仕様、データモデル）を最新に保つ
• 定期的なペアプログラミングやモブプログラミングを実施する
• 特定の人に知識が集中していないか、定期的にバス係数（その人がいなくなった場合のリスク）を評価する

テスト・移行フェーズの失敗

パターン 9: テスト工程の軽視

症状: 納期に追われてテスト工程を短縮した結果、リリース直後にバグが頻発。本番環境での障害対応に追われ、ユーザーの信頼を失います。

典型的なケース: スケジュール遅延を取り戻すためにテスト期間を大幅に短縮した結果、リリース直後に多数のバグが報告され、データ不整合を引き起こす重大障害に発展。障害対応に数ヶ月を要し、結果的にテスト期間を確保した場合より多くの工数がかかる——テスト軽視の代償は常に「テスト以上のコスト」です。JUAS 2025のデータでも、計画工期が標準工期以上のプロジェクトは平均欠陥数5.94に対し、計画工期が標準工期未満のプロジェクトは11.2と倍近い差が出ています。

対策:

• テスト工数は 全体工期の 30% 以上 を確保する（IPA「共通フレーム」等でも推奨される一般的な目安）
• テストピラミッド（単体テスト多 → 結合テスト中 → E2Eテスト少）を採用し、シフトレフト（開発工程の早期にテストを織り込む）を徹底する
• 単体テスト・結合テスト・ユーザー受入テスト（UAT）の 3 段階を省略しない
• テスト自動化を導入し、回帰テストの工数を削減する
• テスト計画は開発開始時に策定し、テスト期間は固定（開発が遅延してもテスト期間は削らない）とする
• 本番データに近いテストデータで検証する（テストデータと本番データの乖離が障害の原因になることが多い）

パターン 10: 移行計画の不備

症状: 新システムの開発は成功したが、旧システムからのデータ移行や業務切り替えの計画が不十分で、移行期間中にトラブルが多発するパターン。

対策:

• 移行計画は 開発と同時に策定 する（開発完了後ではなく）
• データ移行のリハーサルを 本番前に最低 2 回 実施する
• 段階的移行（並行稼働期間の設定）でリスクを分散する
• 移行当日のタイムスケジュールとロールバック手順を事前に策定する
• エンドユーザー向けの操作研修を移行前に実施する

失敗パターンの影響度マトリクス

10のパターンの発生頻度と影響度を整理すると、優先的に対策すべきものが明確になります。

パターン1・2（要件定義）と4（ベンダー選定）は発生頻度・影響度ともに最高で、対策コストも比較的低いため最優先で取り組むべきです。

【AI時代の新章】生成AI/AI開発に特有の失敗パターン 6 選

ここからは2026年時点の業界知見として、AI/生成AIプロジェクトに特有の失敗パターンを整理します。これらは従来のシステム開発の失敗予防では防げない、新しいタイプの失敗です。AI戦略の進め方全体はAI導入の進め方ガイドで詳しく解説しています。

AI 失敗パターン 1: データ不足・データ品質不備によるモデル精度未達

失敗の現れ方: AIモデルを構築したが、学習データが不足・偏っている・ラベル品質が低いため、目標精度に達しない。「精度85%目標が60%しか出ない」「特定セグメントで誤判定が多発する」といった事象が発生し、本番投入が見送られる。

回避策: プロジェクト開始前にデータアセスメント（量・質・分布・偏り・欠損率）を実施する。必要データ量の目安は業界経験則として「タスク複雑度×クラス数×100〜1,000件」が参考にされるが、ドメイン特性で大きく変動するため、PoC段階で実データに基づき再評価することが必要です。データが不足する場合はデータ収集計画を要件定義段階で立て、データ拡張・転移学習・少数ショット学習の活用余地を検討する。

チェック観点: 学習データの量と質は事前に評価したか／本番運用時のデータドリフト対応計画はあるか／プライバシー・著作権上の利用可能性は確認済みか

AI 失敗パターン 2: 評価指標（業務KPI接続）未設定によるPoC止まり

失敗の現れ方: PoCで「精度80%」を達成したが、それが業務KPI（売上・コスト削減・処理時間）にどう貢献するかが不明確で、本番化の意思決定ができない。「PoCは成功したが、本番化のROIが見えない」というデッドロックに陥る。

回避策: AI技術指標（精度・F1スコア等）と業務KPIを紐付けるロジックツリーをPoC開始前に作成する。例: 「需要予測精度+10%→在庫適正化→在庫コスト削減XX百万円/年」のように、技術指標→業務指標→金額の3段階で接続する。

チェック観点: PoCの成功条件は技術指標と業務KPIの両方で定義されているか／本番化判断の意思決定基準は事前に明文化されているか／費用対効果のシミュレーションはあるか

AI 失敗パターン 3: 要件凍結困難な性質に未対応の従来型ウォーターフォール適用

失敗の現れ方: AI開発は「データを見ながら設計を変える」反復が前提だが、従来のウォーターフォール契約で「要件凍結→設計→実装」と進めた結果、データに合わない設計のまま実装し、後で大規模手戻りが発生する。

回避策: AI開発は準委任契約 + アジャイル/イテレーション開発を基本とする。「データ確認→仮説検証→モデル改善→再評価」のサイクルを2-4週間単位で回す前提で計画する。請負契約を選ぶ場合も、要件確定までの「探索フェーズ」を別契約で切り出す。

チェック観点: 契約類型はAI開発の不確実性に適合しているか／反復サイクルの計画と承認プロセスは設計されているか／変更管理プロセスは柔軟か

AI 失敗パターン 4: 本番運用設計の欠落（モニタリング／再学習／ロールバック）

失敗の現れ方: モデル開発に集中するあまり、本番運用後のモニタリング・再学習・ロールバックの仕組みがない。データドリフトで精度が劣化していることに気づかず、誤判定が積み重なってから問題が顕在化する。

回避策: 本番運用前にMLOps基盤（モデルのバージョン管理・推論ログ収集・精度モニタリング・再学習パイプライン・ロールバック機構）を構築する。「精度がX%以下になったらアラート」「Y日以上モデル更新がない場合は警告」といった運用基準を設計に組み込む。

チェック観点: モデル監視ダッシュボードはあるか／再学習トリガーは定義されているか／ロールバック手順はテスト済みか

AI 失敗パターン 5: LLMハルシネーション・誤回答時の責任分界の曖昧さ

失敗の現れ方: 生成AIが事実と異なる情報を回答（ハルシネーション）し、ユーザーが誤った判断をしたケースで、「ベンダー責任か発注者責任か」が契約で曖昧なまま訴訟リスクに発展する。

回避策: 契約でLLMの出力責任分界を明文化する。典型的には「(1)モデル選定の妥当性はベンダー責任、(2)出力内容の最終確認はユーザー責任、(3)システム側でハルシネーション低減策（RAG/ガードレール/人間レビュー）を実装する責任はベンダー責任」という3層で整理する。免責文言の表示・ログ保管・誤回答報告フローも契約に組み込む。

チェック観点: ハルシネーション低減策（RAG/Few-shot/検証ループ）は設計されているか／誤回答時のユーザー導線（人間エスカレーション）は明確か／法務リスクはレビュー済みか

AI 失敗パターン 6: AIセキュリティ要件（プロンプトインジェクション等）の見積もり漏れ

失敗の現れ方: 従来のWebアプリケーションセキュリティ（OWASP Top 10）には対策したが、プロンプトインジェクション・データ抜き取り・モデル乗っ取り等のAI特有の脅威への対策が見積もりに含まれず、リリース直前に追加見積もりが発生する。

回避策: 要件定義段階でOWASP Top 10 for LLM Applications等のAI特有脅威リストをチェックリストに加える。プロンプトインジェクション対策（入力サニタイズ・システムプロンプト保護）、データ漏洩対策（個人情報マスキング・推論ログの暗号化）、モデルアクセス制御（APIキー管理・レート制限）を要件と費用に組み込む。

チェック観点: AI特有の脅威モデリングは実施したか／本番環境のAI関連ログは監査可能か／モデル/API利用のガバナンスポリシーは整備されているか

契約類型別 責任分界マトリクス｜誰が何の義務を負うのか

システム開発の契約は主に請負契約・準委任契約・ハイブリッド型の3類型があり、それぞれで責任分界が異なります。スルガ銀行判決はこの分界を明確にした重要判例です。

スルガ判決が示した「プロジェクトマネジメント義務」の射程

東京高裁判決の核心は「ベンダーは専門家として、プロジェクトの遅延・費用増大が見込まれる場合に、状況を発注者に説明し、必要に応じて開発計画の見直しや中止を提案する義務がある」というものでした。この義務は契約類型を問わず、システム開発の専門性を持つベンダー側に発生します。

特に請負契約においては、「成果物完成義務」と並んで「プロジェクトマネジメント義務」が中核的な債務とされる傾向にあります。ベンダー側は提案段階・要件定義段階・開発段階の各フェーズで、リスクを早期に検知して発注者に説明する責任を負います。

解約時の違約金は契約類型で大きく異なる

請負契約は中途解約時、出来高に応じた精算と、未完成部分の損害賠償が問題になります。準委任契約は民法651条（民法656条により準委任に準用）により任意解除が可能ですが、相手方に不利な時期の解除は損害賠償義務が発生します（民法651条2項）。ハイブリッド型ではフェーズ完了部分を請負として扱い、進行中フェーズを準委任として扱う設計にすることで、解約時のリスクを分散できます。

「内製と外注のどちらを選ぶべきか」を含めた判断基準はシステム開発の外注 vs 内製 判断ガイドで詳しく解説しています。

外注 vs 内製：それぞれに特有の失敗パターン

失敗の原因は外注と内製で傾向が異なります。自社の開発体制に合わせた対策が必要です。

外注特有の失敗パターン

内製特有の失敗パターン

外注 vs 内製のさらに詳しい比較は システム開発の外注 vs 内製 判断ガイド で解説しています。

工程別 失敗予防チェックリスト【発注前／要件定義／契約／受入 計40項目】

ここからは実務で使える40項目のチェックリストを、4工程に分けて提示します。各工程で1つでもチェックが付かない項目があれば、そこがプロジェクトの脆弱点になります。

発注前チェックリスト 10項目

要件定義に入る前の準備段階で確認すべき項目です。ここで手を抜くと、後工程のすべてに影響します。

• 業務目的が定量的に表現されている（例: 「業務効率化」ではなく「月末棚卸時間を50%削減」）
• 対象業務の現行フロー（誰が・いつ・何を・どれだけの頻度で）がドキュメント化されている
• 影響を受ける関係部署と人数が把握できている
• 意思決定者・承認者が明確で、稟議フローが固まっている
• 予算枠の上限と下限（理想予算と最低限予算）が経営承認済み
• 想定スケジュール（リリース希望日とその根拠）が明確
• 発注先候補3社以上から提案を受ける体制が整っている
• 同業界の類似案件実績がある会社をリストアップしている
• 発注側プロジェクトリーダーが専任で確保されている
• 失敗時のリスク（事業影響・業務継続性）を経営層と共有済み

要件定義チェックリスト 10項目

要件定義は失敗の8割が発生する工程です。経済産業省・IPA系の調査でも、後工程の手戻りの大部分が要件定義に起因することが繰り返し指摘されています。

• 業務目的→優先順位→例外シナリオ→受入基準の4層で要件を構造化している
• ペーパープロトタイプで現場担当者にレビューしてもらった
• 画面遷移図・データフロー図を作成し、ベンダーと合意している
• 非機能要件（性能・可用性・セキュリティ・運用）を機能要件と同等の粒度で定義している
• 法令・業界規制（個人情報保護法・業界ガイドライン）の遵守要件が織り込まれている
• データ移行（既存データの量・形式・移行方針）が要件に含まれている
• 外部システム連携（API・ファイル連携）の仕様が確定している
• MVP範囲とフルスコープを分離し、段階リリース計画がある
• 要件定義レビュー会に発注側意思決定者が参加している
• 要件凍結のタイミングと、その後の変更管理プロセスが決まっている

契約締結前チェックリスト 10項目

契約書は訴訟になったときに勝敗を分けます。スルガ銀行・京都市の事例でも、契約条項の不備が争点になりました。

• 契約類型（請負/準委任/ハイブリッド）が開発手法に適合している
• 成果物の定義（ソースコード・ドキュメント・設計書）と所有権が明記されている
• 検収基準（合否判定の具体的条件）が契約書に記載されている
• 仕様変更管理（CR）プロセスが契約書に組み込まれている
• キーパーソンの離脱時の通知義務（30日前通知等）が明記されている
• エスカレーション基準（予算超過X%・工期遅延Y日で経営層会議）が定義されている
• 契約不適合責任（バグ対応期間・対応範囲）の条件が明確
• 中途解約時の精算ルール（出来高評価・違約金）が定められている
• 知的財産権の帰属（OSS利用時の取り扱い含む）が整理されている
• 守秘義務・データ取扱の範囲と期間が明確

受入テストチェックリスト 10項目

検収は「終わりの始まり」です。ここを甘くすると、運用開始後の障害ですべて吹き飛びます。

• 受入テスト項目書が機能要件と業務シナリオの両方をカバーしている
• テストデータ（本番相当のボリュームと多様性）が準備されている
• 性能テスト（同時接続数・応答時間）の合否基準が明確
• セキュリティテスト（脆弱性診断・ペネトレーションテスト）が実施されている
• 障害時の挙動（フェイルセーフ・バックアップ・リカバリ）が確認済み
• 業務シナリオに沿った操作テストを現場担当者が実施している
• エッジケース（境界値・異常入力・大量処理）のテストが済んでいる
• 運用マニュアル・障害対応手順書の納品が完了している
• 教育プログラム（管理者向け・一般ユーザー向け）が実施されている
• 検収後の保守契約・SLA（サービスレベル合意）が締結されている

失敗回避フローチャート｜あなたのプロジェクトのリスクパターンを判定

下記の判定フローで、自社プロジェクトが現在どのリスクパターンにあるか確認してください。

Q1. 発注前の準備はできていますか？

  └─ NO（業務目的・予算・関係者が未確定） → 【危険信号①】
       → 「発注前チェックリスト 10項目」を完走してから次へ

  └─ YES → Q2へ

Q2. 要件定義は構造化されていますか？

  └─ NO（機能一覧のみで業務目的・例外・受入基準が未整理） → 【危険信号②】
       → スルガ銀行判決の教訓を参照し、ベンダーと共同で要件定義を再設計する

  └─ YES → Q3へ

Q3. 契約類型は開発手法に適合していますか？

  └─ NO（AI開発なのに請負契約一択／要件未確定なのに固定価格契約） → 【危険信号③】
       → 「契約類型別 責任分界マトリクス」を参照し、契約類型を見直す

  └─ YES → Q4へ

Q4. 検収基準は事前に文書化されていますか？

  └─ NO（合否判定基準が口頭合意のみ） → 【危険信号④】
       → 京都市vsシステムズ訴訟の教訓を参照し、検収基準を契約書に追記する

  └─ YES → Q5へ

Q5. 進捗の異常値（工期遅延・予算超過）を検知する仕組みはありますか？

  └─ NO（定例会の議事録すら残っていない） → 【危険信号⑤】
       → 特許庁vs東芝の教訓を参照し、エスカレーション基準とKPI監視を導入する

  └─ YES → 【低リスク】 — 引き続き「工程別チェックリスト40項目」で定期的に自己点検する

複数の【危険信号】が点灯している場合は、即座に第三者（外部PMO・コンサルタント・法務）のレビューを受けることを強く推奨します。プロジェクトの早期段階での介入は、後の訴訟・全面破綻と比較して桁違いに低コストです。

失敗プロジェクトを途中から立て直す方法

すでに問題が発生しているプロジェクトでも、早期に立て直し策を講じることで被害を最小限に抑えられます。

立て直しの 4 ステップ

重要なのは「問題を隠さない」こと。 立て直しが遅れる最大の原因は、プロジェクトの問題がエスカレーションされず、経営層に報告されるのが手遅れになった段階であることが多いです。

立て直しが困難なサイン

以下に2つ以上該当する場合は、プロジェクトの中止・再スタートを検討すべきです。

• プロジェクトの60%以上が完了しているのに、根本的な設計変更が必要
• 発注側と受注側の信頼関係が完全に崩壊している
• 当初の予算を 2倍以上超過しており、追加予算の見込みがない
• ビジネス環境の変化により、そもそもの要件が意味をなさなくなった
• PMが2回以上交代しており、プロジェクトの経緯を把握している人がいない

プロジェクトの中止は「失敗」ではなく、これ以上の損失を防ぐ合理的な判断です。特許庁の事例のように、中止の判断が遅れるほどサンクコスト（埋没費用）が大きくなります。

失敗を防ぐパートナー選定の5つの基準｜koromoのアプローチ

過去の失敗事例と訴訟判例を踏まえ、開発パートナー選定で確認すべきは次の5基準です。

1. ドメイン理解力 — 同業界・類似業務の案件実績があるか。要件ヒアリング時に「業務上の暗黙知」を引き出せるか
2. プロセスの透明性 — 進捗・課題・リスクを定期的に可視化する運用があるか。議事録・進捗報告書の品質は十分か
3. コミュニケーション設計力 — 定例会・エスカレーション基準・RACIなど、コミュニケーション崩壊を防ぐ仕組みを設計できるか
4. 技術選定の説明責任 — 採用技術の選定理由と、移行可能性（ベンダーロックインの回避）を説明できるか
5. 契約設計力 — 開発手法に適した契約類型を提案でき、検収基準・変更管理・解約条件を契約書に的確に反映できるか

koromoは「6ヶ月→1ヶ月」の高速プロダクト開発、AI戦略・CAIO代行、生成AIによる業務効率化、組織横断プロジェクト推進の4サービスを通じて、上記5基準を満たすパートナーシップを提供しています。要件定義段階からの伴走、AI/生成AI開発に特有の不確実性への対応、訴訟事例から学んだリスク予防策の組み込みまでを一気通貫で支援します。

具体的なパートナー選定基準は開発パートナーの選び方 7 つの基準、AI開発会社の比較はAI開発会社の比較ガイド、生成AI業務効率化の実装事例は生成AI業務効率化事例で詳しく解説しています。

よくある質問

まとめ — システム開発の失敗は「防げる原因の積み重ね」

システム開発の失敗は、特殊な事故ではなく統計的に高頻度で発生する経営リスクです。Standish Group CHAOS Report 2020で69%のプロジェクトが何らかの問題を抱え、JUAS「5:5:3の法則」が示すように500人月以上のプロジェクトでは半数が工期・予算で破綻します。本記事で取り上げた6つの大規模失敗事例（うち判決確定済み3事例：スルガ銀行・特許庁・京都市）はいずれも、事前のリスク管理で大幅に被害を抑えられた事例です。

6つの事例とフェーズ別10パターン、AI時代の新しい失敗パターン6選に共通する教訓は以下の3つです。

1. 要件定義に十分な時間をかける — 「早く作り始めたい」衝動に負けない。「現行踏襲」ではなく業務フローから再定義する。要件定義は全体工期の20%以上を確保する
2. コミュニケーションと契約の仕組みを設計する — 週次定例とデモを省略しない。発注側にも積極的な協力義務がある。契約類型は開発手法（ウォーターフォール/アジャイル/AI）に適合させる
3. テスト・移行・運用設計を軽視しない — 「作る」だけでなく「届ける」「運用する」まで含めて計画する。AI開発ではMLOps基盤の事前構築が必須

今日から始められる失敗予防の3アクション:

• 工程別40項目チェックリストで自社プロジェクトの脆弱点を診断する（所要時間: 1時間）
• 失敗回避フローチャートで現在のリスクパターンを判定し、対応する章を再読する（所要時間: 30分）
• 契約類型別 責任分界マトリクスを参考に、現在の契約書をレビューする（所要時間: 2時間）

合計4時間弱の作業で、大半のプロジェクトリスクを早期検知できます。AI/生成AI開発に着手する場合は、AI時代の新しい失敗パターン6選を必ず織り込んでください。失敗予防は、失敗が起きてからの対応コストの数十分の一で済む投資です。

訴訟事例の教訓は、すべて契約書・要件定義書・議事録という日常運用の証跡で対処できた——これが本記事の最大の結論です。技術負債を溜めない開発手法については技術負債のROI計算と4つの解消戦略を、外注と内製の判断基準はシステム開発の外注 vs 内製 判断ガイドを、MVP開発の進め方はMVP開発ガイドを参照してください。

koromoでは、要件定義段階からの伴走、AI開発の不確実性への対応、判例から学んだリスク予防策の組み込みまでを一気通貫で支援しています。発注前のリスク診断・要件定義の構造化・契約類型の選定でお困りの場合は、お気軽にご相談ください。

参考文献

• スルガ銀行 vs 日本IBM 東京高裁平成25年9月26日判決コラム（Westlaw Japan）
• スルガ銀行 vs 日本IBM 訴訟確定のお知らせ（スルガ銀行公式）
• スルガ銀行対日本IBM事件 SOFTIC研究会資料
• 55億円無駄に、特許庁の失敗（日経xTECH）
• 特許庁の中止された基幹系システム開発、約56億円を返還（財経新聞）
• 京都市システム開発訴訟判決報道（時事ドットコム）
• 京都市システム更新訴訟判決の詳細（システム開発失敗.com）
• JUASソフトウェア・メトリクス調査2025
• JUAS企業IT動向調査2025
• Standish Group CHAOS Report 2020レビュー（Henny Portman's Blog）
• 経済産業省 DXレポート（2018年）
• 金融庁「みずほ銀行及びみずほフィナンシャルグループに対する行政処分について」（2021年11月）