はじめに
システム開発の契約書をレビューしていると、ほぼ必ず出てくるのが「損害賠償の上限」を定めた条項です。ベンダーのひな形では、たとえば次のような書き方になっていることが多いはずです。
「本契約に関して受注者が負う損害賠償責任は、直接かつ現実に生じた通常の損害に限られ、その総額は本契約の委託料を上限とする。」
一見すると標準的な文言で、多くの発注側担当者はそのまま受け入れてしまいます。しかし、この条項は「何かが起きたときに、どこまでを誰が負担するのか」を決める、契約の中でも特に重い条項です。
NDA（秘密保持契約）で発注側が注意すべきポイントの最後で、損害賠償の上限は別の記事で整理すると書きました。今回は、損害賠償の上限条項を発注側としてどう読み、どう交渉するかを整理します。なお、本記事は実務上の考え方の整理であり、個別の契約判断は法務部門や弁護士に確認してください。
なぜベンダーは上限を設けたがるのか
まず、ベンダーが上限を求める理由を理解しておくことが交渉の出発点になります。
システム開発では、不具合が業務停止や顧客対応の遅れにつながり、損害が契約金額をはるかに上回ることがあります。数千万円の開発案件で、数億円規模の損害が発生する可能性もゼロではありません。上限がなければ、ベンダーは1件の案件で会社の経営を揺るがすリスクを負うことになります。
そのため、ベンダーにとって上限条項は「受注できるかどうか」に関わる条件です。発注側が上限そのものを削除しようとしても、まず通りませんし、仮に通ったとしても、そのリスクは見積もり金額に上乗せされて返ってきます。
つまり交渉の目的は「上限をなくすこと」ではなく、上限の金額と適用範囲を、自社のリスクに見合った形に調整することです。
上限条項で確認すべき4つのポイント
①上限金額の基準は何か
上限の決め方にはいくつかのパターンがあります。
- 契約全体の委託料総額を上限とする
- 損害の原因となった個別契約（フェーズごとの契約）の委託料を上限とする
- 直近〇か月分の支払額を上限とする（保守・運用契約に多い）
- 固定の金額を上限とする
注意したいのは、多段階契約の場合です。要件定義・設計・開発・テストを別々の個別契約で結んでいると、「損害の原因となった個別契約の委託料」が基準になり、上限が想定よりかなり小さくなることがあります。たとえば、本番稼働後に見つかった重大な不具合の原因が「要件定義の契約」に帰属すると判断されれば、上限はその要件定義の契約金額になり得ます。
保守・運用契約で「直近1か月分の保守料」が上限になっているケースでは、システム停止で大きな損害が出ても、賠償額は月額保守料程度にとどまります。ベンダーとのSLA（サービスレベル合意）、何を数値で握っておくべきかで触れた通り、運用フェーズのリスクはSLAと賠償条項をセットで考える必要があります。
②故意・重過失の場合も上限が適用されるか
発注側として最も重要なのがこの点です。一般的な契約実務では、故意または重大な過失による損害には上限を適用しないという但し書きを入れるのが通例とされています。
ベンダーのひな形でこの但し書きが抜けている場合は、追加を求めるべきです。極端に言えば、ベンダーが明らかに不注意な作業で重大な事故を起こしても、上限の範囲でしか責任を問えなくなるからです。裁判例でも、故意・重過失がある場合には責任制限の条項がそのまま適用されないと判断されたものがありますが、契約書の文言で明確にしておく方が、争いになったときの負担は小さくなります。
③対象となる損害の範囲
「直接かつ現実に生じた通常の損害に限る」という文言は、逸失利益（得られるはずだった利益）や、特別な事情によって生じた損害を除外する意図を持っています。
発注側として確認しておきたいのは、次のような費用が賠償の対象に含まれるかどうかです。
- 不具合の調査・復旧のために発注側が負担した費用（社内工数、外部専門家の費用）
- 代替手段で業務を回すために発生した費用（手作業での処理、臨時の人員）
- 顧客への対応費用（お詫び、問い合わせ窓口の設置など）
これらが「通常の損害」に含まれるかは解釈が分かれやすいため、重要なものは例示として契約書に書いておく方が安全です。
④上限の対象外にすべき事項
故意・重過失以外にも、上限の対象から外すことを検討したい事項があります。
- 秘密保持義務違反：情報漏えいの損害は委託料を大きく超えやすい
- 個人情報の取扱いに関する義務違反
- 第三者の知的財産権の侵害：ベンダーが納品したプログラムが他社の権利を侵害していた場合
特に個人情報の漏えいは、顧客対応や再発防止の費用が膨らみやすい領域です。基幹刷新プロジェクトにおけるセキュリティ要件の整理で整理したセキュリティ要件と合わせて、契約上の責任範囲を決めておきます。
交渉の進め方
自社が負うリスクを先に見積もる
交渉の前に、「このシステムで最悪の事態が起きたら、どの程度の損害が出るか」をざっくり見積もっておきます。
- システムが1日止まったら、売上や業務にどの程度影響するか
- 個人情報が何件含まれ、漏えいしたらどの程度の対応費用がかかるか
- 稼働が遅れたら、現行システムの延長費用はいくらか
この見積もりがないと、「上限は委託料でよいのか」を判断できません。損害が委託料を大きく超える可能性がある領域を特定し、そこに交渉の力を集中させます。
すべてを一度に求めない
上限条項のすべてを発注側有利に書き換えようとすると、交渉は長引き、ベンダーとの関係も悪くなります。優先順位をつけて臨むのが現実的です。
- 必ず求める：故意・重過失の除外、上限の基準を「契約全体」または妥当な金額にする
- できれば求める：秘密保持・個人情報違反の上限除外、調査・復旧費用の明記
- 譲ってもよい：逸失利益の除外（多くのベンダーが応じにくい項目）
ベンダー交渉で主導権を握る方法で触れたように、交渉は「勝ち負け」ではなく、双方が納得できる落としどころを探す作業です。
公的なひな形を拠り所にする
経済産業省とIPAが公表している「情報システム・モデル取引・契約書」は、損害賠償を含む責任分担の参考として広く使われています。ベンダーのひな形と比べてどこが違うのかを確認し、「モデル契約ではこうなっている」と示すことで、交渉の根拠にしやすくなります。
契約以外の手段でもリスクを下げる
上限を上げることだけがリスク対策ではありません。
- ベンダー側が加入している賠償責任保険の補償額を確認する
- 自社側でもサイバー保険などでカバーできる範囲を検討する
- そもそも損害が大きくならないよう、受け入れテストの設計やカットオーバー判定基準で品質を確保する
ベンダーの賠償能力には限りがあります。契約で取れる金額と、保険や品質管理で抑えるリスクを組み合わせて考えることが重要です。
契約不適合責任との関係
損害賠償の上限条項は、契約不適合責任とも関係します。納品物に不具合があった場合、発注側は修補（修正）を求めるか、損害賠償を求めるかを選ぶことになりますが、損害賠償を求める場面ではこの上限条項が効いてきます。
契約不適合責任の期間がいくら長くても、賠償額の上限が小さければ、実際に回収できる金額は限られます。2つの条項は別々ではなく、セットで確認するようにしてください。
まとめ
損害賠償の上限条項は、ベンダーにとって受注の前提条件であり、削除を求めるのは現実的ではありません。発注側がやるべきことは、上限の基準となる金額、故意・重過失の除外、対象となる損害の範囲、上限の対象外とすべき事項の4点を確認し、自社のリスクに見合った形に調整することです。
交渉の前に「最悪の場合の損害」を見積もり、優先順位をつけて臨むこと。そして契約だけに頼らず、保険や品質管理でリスクを下げる手段も組み合わせること。それが、何かが起きたときに「契約書を見たら何も取れなかった」という事態を防ぐことにつながります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント