システム開発の損害賠償・リスク管理ガイド｜契約書の読み方と発注者のトラブル対処フロー

システム開発の発注を経験したことがある方なら、一度は「損害賠償額は委託料の○ヶ月分を上限とする」「間接損害・逸失利益は賠償の対象外とする」といった条項を目にしたことがあるのではないでしょうか。こうした損害賠償条項がなぜ存在するのか、自社にとって有利なのか不利なのかを正確に理解している発注担当者は多くありません。

「なんとなく怖い気がするが、そのままサインしてしまった」という経験をお持ちの方もいるはずです。実際、社内に法務専任が不在の中小企業では、IT系の契約書を十分にレビューする機能が整っていないケースがほとんどです。

しかし、損害賠償条項は発注者の権利保護に直結する最重要条項の一つです。開発プロジェクトが失敗したとき、あなたが受け取れる補償の上限はこの条項で決まります。逆に言えば、この条項を正しく理解し、必要であれば交渉して修正することで、発注者としてのリスクを大幅にコントロールできます。

本記事では、システム開発契約における損害賠償トラブルの類型から、損害賠償条項の読み方・交渉ポイント、発注者が確認すべきチェックリスト、トラブル発生時の対処フロー、そしてリスクを最小化する契約設計のコツまでを、法務の専門家がいない中小企業の発注担当者向けに実務的に解説します。

システム開発で起きやすい損害賠償トラブルの類型

損害賠償条項の読み方を理解する前に、まず「どんな状況で損害賠償が問題になるのか」を把握しておくことが重要です。実際の紛争では、トラブルの類型によって賠償が認められやすいケースとそうでないケースが大きく異なるからです。

類型1　納期遅延・プロジェクト中止による損害

最も頻繁に起きる類型です。開発会社（ベンダー）側の責任で納期に遅延し、システムのリリースが遅れることで発注者に損害が発生するケースです。

損害賠償が認められやすい条件:

• 契約書に納期が明記されており、その納期を大幅に超過している
• 遅延の原因がベンダー側の人員不足・技術力不足・管理不備にある
• 遅延によって発注者が具体的な損害（既存システムの延長利用コスト、機会損失など）を被っている

難しいケース:

• 発注者側の仕様変更・追加要求が遅延の原因となっている場合
• 要件定義が曖昧で「どこまでが最初の約束か」が不明確な場合
• 「ベストエフォート」などの曖昧な表現で納期が定められている場合

類型2　成果物の品質不備（契約不適合責任）

完成したシステムが契約で定めた仕様・品質を満たしていない場合です。2020年の民法改正により「瑕疵担保責任」から「契約不適合責任」という概念に変わり、発注者の権利がやや拡充されました。

損害賠償が認められやすい条件:

• 契約書や仕様書に具体的な性能・機能要件が明記されている
• 不具合が発注者の使用環境や運用方法によるものではなく、開発そのものに起因する
• 発注者が契約不適合を知った時から1年以内に通知している（民法566条）

難しいケース:

• 仕様書が不十分で「何が正解か」が双方で異なる解釈になっている
• 発注者が独自に改修を加えた後に不具合が発生した場合
• 検収完了後に長期間が経過した後の不具合申告

類型3　情報漏洩・セキュリティ事故

ベンダーの不適切な情報管理により、発注者の機密情報や顧客データが漏洩するケースです。近年、ランサムウェアや不正アクセス等のセキュリティ事故が増加しており、この類型のトラブルも増えています。

損害賠償が認められやすい条件:

• ベンダーに明らかなセキュリティ対策の不備がある（パスワード管理の杜撰さ、パッチ適用の怠慢など）
• 漏洩した情報の性質と範囲が特定できている
• ベンダーが情報管理に関する義務（NDA・セキュリティ要件）を契約で負っていた

難しいケース:

• 国家レベルのサイバー攻撃など、防御が極めて困難な「高度な攻撃」の場合（不可抗力の主張）
• 発注者が提供したシステム側の脆弱性が原因となっている場合

類型4　仕様変更・スコープ争いによる追加費用請求

開発途中での仕様変更をめぐり、ベンダーから多額の追加費用が請求されるケースです。「それは最初の要件に含まれていたはず」「いいえ、新しい要求です」という争いは、実際の紛争でも双方の主張が食い違い解決が難しいケースが少なくありません。

損害賠償が認められやすい条件（発注者側が支払いを拒否できるケース）:

• 追加費用の合意なく作業が行われ、事後的に請求された
• 変更管理プロセスが契約書に明記されており、そのプロセスが踏まれていない
• 追加要求とされる作業が、実は当初の要件定義書の範囲内である

ここで重要なのは、どのトラブル類型であっても、損害賠償の上限は契約書の損害賠償条項によって定められるという点です。次のセクションでは、この損害賠償条項の読み方を詳しく解説します。

損害賠償条項の読み方と交渉ポイント

システム開発契約書に登場する損害賠償条項には、いくつかの典型的なパターンがあります。それぞれのパターンが発注者にとってどんな意味を持つかを理解しましょう。

損害賠償額の上限条項 — どれくらいが妥当か

多くのシステム開発契約書には、損害賠償額の上限（責任限定条項）が設けられています。よくある文言の例はこうです。

「甲または乙は、相手方の債務不履行または不法行為によって生じた損害について、その損害の種類に関わらず、直近12ヶ月間に甲が乙に支払った対価の総額を上限として賠償の責任を負う」

この条項はベンダー側が強く求めてくる典型的な条項です。なぜかというと、システム開発の失敗によって発注者に生じる損害は、実際には開発費用をはるかに上回ることがあるからです。

たとえば、1,000万円の開発費用のシステムが完成せず、結果として発注者の新サービスのリリースが1年遅れたとしましょう。その1年間の機会損失が1億円だとしても、上記の条項では1,000万円（または12ヶ月分の支払い額）までしか請求できません。

発注者の視点からの考え方:

• 上限額は「委託料相当額（または数ヶ月分）」が一般的: ゼロ上限（免責）や非常に低い額は過度に不利。一般的には委託料の1〜12ヶ月分が設定されます
• 高額案件ほど交渉余地が大きい: 数千万円規模の案件では、上限額の引き上げを交渉することは珍しくありません
• 業界標準を把握しておく: IPA（情報処理推進機構）が公表している情報システム・モデル取引・契約書（第二版）を参考にすると、業界標準の契約条件を理解する上での根拠になります

間接損害・逸失利益の除外 — 発注者にとっての意味

もう一つの典型的な条項が「間接損害・逸失利益の除外」です。

「いかなる場合も、逸失利益、間接損害、特別損害（損害の発生を予見し得た場合を含む）については賠償の責を負わないものとする」

この条項が入っていると、先ほどの機会損失（1億円の逸失利益）は請求できません。損害賠償の対象は「直接損害」のみとなります。

直接損害と間接損害の違い:

損害の種類	内容	例
直接損害	債務不履行と直接因果関係にある損害	開発費用の再調達コスト、既存システムの延長利用費用
間接損害・逸失利益	本来得られたはずの利益の喪失など	システム未リリースによる販売機会の損失、既存顧客の解約による損害

SCROLL→

交渉ポイント:

すべての間接損害を完全に排除するのはベンダーに有利すぎます。少なくとも「情報漏洩・秘密保持義務違反に起因する損害」については除外対象から外す（つまり間接損害も含めて賠償対象とする）交渉は現実的に可能です。

重過失・故意の場合の例外規定 — なぜ重要か

責任制限条項が認められるのは「軽過失の場合のみ」というのが法的な一般論です。ベンダーの故意や重過失がある場合には、責任限定条項は適用されないとする判例も存在します（弁護士法人クラフトマン・開発委託契約における損害賠償限定条項とその有効性）。

ただし、「重過失かどうか」の判断は法的に難しく、実際の紛争では双方が争う論点になります。

契約書でチェックすべき点:

• 「故意または重過失の場合はこの限りでない」という例外規定が明記されているか
• 情報セキュリティ事故・秘密保持義務違反については特別に規定されているか

交渉で変えられる余地とは — 現実的な交渉ポイント

損害賠償条項の交渉で、発注者が現実的に求められる修正の例を示します。

交渉項目	交渉前（典型的なベンダー案）	交渉後（発注者に有利な修正案）
賠償上限額	委託料の1ヶ月分	委託料の全額〜3ヶ月分
間接損害の扱い	一切免責	情報漏洩・NDA違反については賠償対象
重過失例外	記載なし	「故意または重過失の場合はこの限りでない」を追記
保険対応	記載なし	「ベンダーはIT業務賠償責任保険に加入する」を追記

SCROLL→

交渉において重要なのは、「全部変えたい」ではなく「特にリスクが高い部分を優先的に交渉する」という姿勢です。ベンダーとの関係を保ちながら、最重要ポイントに絞って交渉することが実務的です。

契約書チェックリスト — 発注者が確認すべき損害賠償関連10項目

損害賠償条項とその周辺条項について、発注者が確認すべき10の項目をチェックリスト形式で整理します。手元の契約書と照らし合わせながら確認してください。

①損害賠償額の上限と計算基準

確認ポイント: 上限額がどう設定されているか。「直近○ヶ月間の支払い額」「契約金額の○倍」など計算方法は様々です。

危険シグナル: 上限額が「委託料の1ヶ月分」など著しく低い。または「損害の直接起因となる個別業務の報酬額」など、実質的にほぼゼロに近い計算式になっている。

チェック: 賠償上限額は案件のリスク規模と見合っているか？

②間接損害・逸失利益の扱い

確認ポイント: 「間接損害」「特別損害」「逸失利益」などが賠償対象から除外されていないか。

危険シグナル: 「いかなる間接損害についても一切責任を負わない」という包括的な免責。

チェック: 少なくとも情報漏洩・NDA違反については間接損害も対象となるよう交渉したか？

③重過失・故意の例外規定の有無

確認ポイント: 責任限定条項に「故意または重過失の場合はこの限りでない」という例外が明記されているか。

危険シグナル: 例外規定の記載がなく、ベンダーが故意に契約を履行しなかった場合でも賠償上限が適用される可能性がある。

④免責条件（不可抗力・発注者の指示による免責等）

確認ポイント: どんな場合にベンダーは責任を免れるのか。不可抗力の範囲、「発注者の指示に従った場合」の免責規定など。

危険シグナル: 「発注者の要求・指示に起因する不具合については責任を負わない」という広範な免責。これは発注者が仕様を決める限り、すべて発注者の責任になりかねない。

⑤損害賠償請求の通知期限

確認ポイント: 「損害を知ってから○日以内に通知しなければ賠償請求できない」などの通知期限が設定されているか。

危険シグナル: 「トラブルを知ってから30日以内に通知しないと賠償請求できない」などの短期通知要件。実際にはトラブルを把握して通知するまでに30日以上かかることがある。

⑥契約不適合責任の対象・期間

確認ポイント: 「契約不適合責任」（旧・瑕疵担保責任）がどのように規定されているか。対象となる不適合の定義、通知期限、修補・代替・代金減額・解除・損害賠償の各手段が規定されているか。

危険シグナル: 「検収完了後は一切の責任を負わない」という条項。民法上の規定（1年以内通知）より短い通知期限を設定している場合も要注意。

⑦証拠・記録に関する規定の有無

確認ポイント: 議事録・変更記録・承認手続きに関するルールが契約に定められているか。口頭での指示・合意が証拠として有効かどうか。

危険シグナル: 証拠・記録に関する規定が全くない。後のトラブル時に「言った言わない」の争いになるリスクが高い。

推奨策: 「すべての重要な合意は書面（メール含む）で確認する」というプロセスを契約書に明記するよう交渉する。

⑧再委託先への責任の所在

確認ポイント: ベンダーが再委託先（下請け）に一部業務を委託した場合、その下請けが起こしたトラブルについての責任がベンダーにあるのか。

危険シグナル: 「再委託先の行為については責任を負わない」という条項。実質的に再委託先の不正・ミスを発注者が自己責任で負うことになる。

確認事項: 再委託を行う場合はベンダーから事前に承認を得るプロセスが定められているか。

⑨保険加入義務の有無

確認ポイント: ベンダーがIT業務賠償責任保険に加入する義務が規定されているか。保険の補償範囲（第三者への損害賠償、情報漏洩など）が発注者のリスクをカバーするか。

危険シグナル: 保険に関する規定が全くない。高額案件でベンダーの財務基盤が不安定な場合、賠償能力がないと損害賠償を受け取れない可能性がある。

⑩紛争解決方法（ADR・仲裁・訴訟の選択）

確認ポイント: トラブル時の紛争解決手段として何が規定されているか。「協議→調停→訴訟」「仲裁」「ADR機関への付託」など。

注意点: 「東京地方裁判所を専属的合意管轄とする」という条項がある場合、全国どこの会社でも東京で争うことになります。遠方の企業が発注する場合は管轄裁判所の確認が重要です。

トラブル発生時の対処フロー — 証拠保全・交渉・ADR・訴訟

万が一トラブルが発生した場合の対処手順を5つのステップで解説します。「こんな事態になるとは思わなかった」という状況でも、適切な順序で行動することで、損害の最小化と適切な補償の確保が可能になります。

ステップ1 — 発生直後の証拠保全（何を集めるか）

トラブルが発覚したら、まず証拠の保全を最優先に行います。時間の経過とともに証拠は失われ、記憶も曖昧になります。

収集・保全すべき証拠:

• 契約書類一式: 基本契約書、個別契約書、仕様書（全バージョン）、見積書
• コミュニケーション記録: メール（時系列でバックアップ）、チャットのログ（Slack/Teamsなど）、議事録
• 成果物: 受け取ったシステムのソースコード、ドキュメント、テスト結果
• 損害の証拠: 追加コストの請求書、既存システム延長利用の費用、機会損失の記録
• トラブルの証拠: バグレポート、エラーログ、ユーザーからのクレーム記録

やってはいけないこと:

• ベンダーとの合意なく一方的に作業を中止・中断させる
• 怒りにまかせてベンダーに過激なメッセージを送る（後で証拠として不利になる可能性）
• 証拠を改ざん・削除する（法的に不利になる）

ステップ2 — 相手への通知と記録（内容証明・書面交渉）

証拠保全ができたら、ベンダーへの正式な通知を行います。口頭での申し出は後で「言った言わない」になるため、必ず書面で行いましょう。

通知の内容:

• 発生しているトラブルの具体的な内容
• 契約上の根拠（どの条項に違反しているか）
• 求める対応（修補・代替・損害賠償など）と期限

内容証明郵便の活用: 重大なトラブルの場合は内容証明郵便（配達証明付き）で通知することで、「通知した日付」と「内容」を公的に証明できます。損害賠償請求の通知期限（契約書に定められた期限）を守るためにも重要です。

ステップ3 — 直接交渉のポイント（何を求め、何を譲るか）

多くのトラブルは訴訟まで発展せず、当事者間の交渉で解決します。直接交渉では以下の点を意識してください。

交渉の基本戦略:

1. 優先順位を決める: 「まず修補してほしい」「費用を返してほしい」「開発を続けてほしい」など、最も重要な要求を明確にする
2. 証拠に基づいて主張する: 感情論ではなく、収集した証拠に基づいて具体的に主張する
3. 代替案を準備する: 「A案がだめならB案」という代替案を用意しておく
4. 合意内容は必ず書面化: 口頭の合意は無効ではありませんが、後のトラブルを避けるために必ず書面化する

ステップ4 — ADRの活用（SOFTICのソフトウェア紛争解決センター）

直接交渉が決裂した場合、いきなり訴訟に移行するのではなくADR（裁判外紛争解決手続）を検討することをおすすめします。

ADRのメリット:

• 訴訟より迅速に解決できる（平均解決期間3〜6ヶ月程度）
• 費用が訴訟より低い
• 専門的な知識を持つ中立的な第三者が関与する
• 非公開で進められるため、企業の評判への影響が少ない

ソフトウェア紛争解決センター（SOFTIC）: IT分野に特化したADR機関として、SOFTIC（ソフトウェア情報センター）が「和解あっせん」と「仲裁」のサービスを提供しています。IT・ソフトウェア取引に精通した専門家が関与するため、技術的に複雑な紛争の解決に適しています。

ステップ5 — 訴訟への移行判断（弁護士への依頼タイミング）

ADRでも解決できない場合、または損害が大きく訴訟が避けられない場合は、弁護士への依頼を検討します。

弁護士への依頼を検討すべきタイミング:

• 損害額が数百万円以上で、ADRでは解決の見込みがない場合
• ベンダーが誠意ある対応をせず、悪意が疑われる場合
• 契約書の内容が複雑で、法的解釈の専門知識が必要な場合

IT分野に強い弁護士を選ぶ: システム開発トラブルには技術的な知識が必要なため、「IT・ソフトウェア取引」を専門分野として掲げる法律事務所を選ぶことを推奨します。法テラス（日本司法支援センター）や各都道府県弁護士会の紹介サービスを活用できます。

リスクを最小化する契約設計のコツ

損害賠償トラブルが起きてから対処するより、そもそもトラブルが起きにくい契約設計をすることが根本的な解決策です。以下の4つのアプローチを紹介します。

フェーズ分割契約で損害の発生リスクを局所化する

システム開発を一括で請け負う「一括請負契約」の場合、問題が発覚するのがプロジェクト終盤になりやすく、その時点では損害が大きくなっています。

これに対し、フェーズ分割契約（多段階契約）では、要件定義・設計・開発・テストなどの各工程を個別に契約します。

フェーズ分割のメリット:

• 各フェーズ完了時に成果物を確認できるため、問題の早期発見が可能
• 万が一問題が発生しても、損害が発生したフェーズに限定できる（損害の局所化）
• フェーズごとに契約を見直せるため、ベンダーとの関係を柔軟に調整できる

中間検収の設計 — 検収基準と期間の明確化

「検収」（完成した成果物の受領確認）の基準が曖昧だと、「検収完了」の時点が争いになります。

検収条項で明記すべき事項:

• 検収基準（何をもって「完成」とするか。機能一覧・性能要件・テスト通過率など）
• 検収期間（システム受け取りから検収完了まで何日か）
• 検収手続き（誰がどのような方法で確認するか）
• 不合格時の対応（修補期限、修補後の再検収など）

変更管理プロセスを契約に組み込む

仕様変更トラブルの多くは「口頭での変更要求」が積み重なることで発生します。変更管理プロセスを契約に明記することで、このリスクを大幅に低減できます。

変更管理プロセスの基本要素:

1. 変更要求の書面化: 仕様変更は必ず書面（変更依頼書）で申請する
2. 影響評価の義務化: ベンダーは変更による費用・期間への影響を書面で提示する
3. 承認フロー: 発注者の承認なしに変更作業を開始しない
4. 未承認変更の扱い: 承認なしに行われた変更については費用を負担しない

仕様変更によるコスト増加の仕組みや具体的な防止策については、別の記事でより詳しく解説していますので、あわせてご参照ください。

IT業務賠償責任保険という選択肢

ベンダーとの交渉でリスクを完全にカバーできない場合、保険で備えるという選択肢もあります。

IT業務賠償責任保険とは: ベンダー（受注側）が加入する保険で、開発したシステムの不具合や情報漏洩によって顧客（発注者）が損害を被った場合に保険金が支払われるものです。

発注者として確認すべきこと:

• ベンダーがIT業務賠償責任保険に加入しているか
• 保険の補償額が案件の規模に見合っているか
• 情報漏洩・データ損失なども補償対象に含まれているか

契約書に「ベンダーは本業務に関してIT業務賠償責任保険に加入し、保険証書の写しを発注者に提示する」という条項を追加することで、保険加入をベンダーに義務付けることができます。

まとめ — 損害賠償リスクを正しく理解して発注を成功させる

本記事では、システム開発契約における損害賠償リスクの管理について、以下の5つの視点から解説しました。

1. 損害賠償トラブルの類型: 納期遅延・品質不備・情報漏洩・仕様変更争いという4類型を理解することで、自分のリスクを正確に把握できる

2. 損害賠償条項の読み方: 上限額・間接損害の除外・重過失例外という3つのポイントを押さえることで、契約書の実質的なリスクを評価できる

3. チェックリスト10項目: 手元の契約書で今すぐ確認すべきポイントを実務的に整理した

4. トラブル時の対処フロー: 証拠保全→書面通知→直接交渉→ADR→訴訟という段階的な対処手順を理解することで、万が一の事態にも冷静に対応できる

5. リスク最小化の契約設計: フェーズ分割・中間検収・変更管理プロセス・保険という4つのアプローチで、トラブル発生自体を予防できる

「損害賠償条項は怖いもの」ではありません。正しく理解し、必要に応じて交渉することで、発注者としてのリスクをコントロールするためのツールです。

契約書の見直しや、これからのシステム開発発注における契約設計でお悩みの場合は、お気軽にご相談ください。