納品されたシステムに重大な不具合が見つかり、取引先への出荷が10日間止まった。そんな連絡を受けたのは、ある中堅製造業の情報システム担当者だった。取引先とは長年の契約で「出荷遅延1日につき違約金50万円」という条項を結んでいた。10日分で500万円。加えて、緊急対応のための人員手配や代替生産ラインの確保にも数百万円がかかった。合計すると被害額はゆうに1000万円を超えていた。
担当者は、システム開発を委託した会社との契約書を引っ張り出した。損害賠償条項には「甲(発注者)に生じた損害について、乙(開発会社)は契約金額を上限として賠償する」とある。このシステムの契約金額は800万円だった。つまり、どれだけ交渉しても、開発会社から受け取れる賠償金は最大800万円。実際の被害額1000万円超のうち、200万円以上は自社で負担するしかなかった。
担当者は契約締結時、この一文を読み飛ばしていたわけではない。読んではいた。しかし「上限額」という言葉が持つ意味の重さを、実感として理解していなかった。契約書の中で、この条項ほど発注者の運命を静かに左右するものは少ない。にもかかわらず、価格やスケジュールほどには注目されず、雛形のまま流されてしまうことが多い。
この記事は、そうした見落としを防ぐために書いている。法律相談ではなく、契約実務としての一般的な知識として、損害賠償条項をどう読み、何を確認し、どう交渉すべきかを整理する。専門的な法的判断が必要な場面では、必ず弁護士に相談してほしい。それでも、担当者自身が条項の意味を理解し、交渉のテーブルにつく準備をしておくことには、大きな価値がある。契約書の細部と向き合う作業は地味で骨が折れるが、そこに時間をかけた担当者だけが、いざという時に会社を守れる。
損害賠償条項とは何か、なぜ上限額が設定されるのか
損害賠償条項とは、契約の一方が債務を履行しなかった場合や、システムの欠陥によって相手方に損害を与えた場合に、どの範囲まで、いくらまで賠償責任を負うかを定めた条項だ。システム開発契約においては、通常、業務委託契約書や請負契約書の中に「損害賠償」という見出しで数行から十数行の条文として存在する。
この条項の核心は「上限額」の設定にある。多くのシステム開発契約書には、次のような趣旨の一文が入っている。
- 乙の責めに帰すべき事由により甲に損害が生じた場合、乙は当該損害を賠償する
- ただし、乙が負う賠償額は、本契約に基づき甲が乙に支払った金額(または契約金額)を上限とする
この「ただし」以下がなければ、開発会社は理論上、無制限に賠償責任を負うことになる。数百万円のシステム開発案件で、発注者に数億円規模の損害が発生した場合、それを全額賠償するとなれば、開発会社は倒産しかねない。ソフトウェアは物理的な製品と違って不具合をゼロにすることが極めて難しく、どれだけ丁寧にテストを重ねても、リリース後に想定外の不具合が見つかることは珍しくない。そうしたリスクを抱えながら事業を継続するために、開発会社側は上限額の設定を強く求める。これは開発会社の身勝手というより、ソフトウェア開発という仕事の性質そのものに根ざした、業界の共通認識だと理解しておく必要がある。
一方で、発注者側にも譲れない事情がある。システムは業務の根幹を支えるインフラであり、その不具合は売上機会の損失、取引先への違約金、信用の毀損など、契約金額をはるかに超える損害を生むことがある。上限額という一本の線は、開発会社の事業継続と、発注者の実損害の間で、常に綱引きが起きている場所なのだと捉えておくと、条項の読み方が変わってくる。
上限額の相場感 ― 契約金額の何倍が一般的か
実務でよく目にする上限額の水準は、おおむね次のようなレンジに分布している。
- 契約金額と同額(1倍) ― もっとも多いパターン。特に中小規模の開発会社が使う雛形に多い
- 契約金額の1.5倍から2倍 ― やや発注者寄りに調整された水準。交渉の結果としてこの水準に落ち着くケースも多い
- 契約金額の3倍以上、または上限なし ― 大規模なシステム開発や、発注者の交渉力が強い案件で見られる。ただしこの水準を標準で提示する開発会社は少数派
- 直近12ヶ月分の支払額を上限とする(準委任・保守契約に多い) ― 開発案件そのものよりも、保守運用契約でよく見る設計
体感として、契約金額と同額を上限とする条項がもっとも多い。これは開発会社にとって「受け取った対価の範囲でしか責任を負わない」というシンプルで説明しやすい基準であり、雛形として広く流通しているためだ。裏を返せば、この水準は開発会社にとって都合の良いデフォルト値であり、発注者にとって最適な水準とは限らない。相場だから妥当だと考えるのではなく、自社が背負うリスクの大きさに照らして、この水準で足りるかどうかを一度立ち止まって考える必要がある。
上限額が実損害をカバーしない典型的なケース
冒頭の事例のように、上限額と実損害の間にギャップが生まれる場面には、いくつかの典型的なパターンがある。
取引先への違約金・機会損失が発生するケース
基幹システムやEC、生産管理システムなどが停止すると、自社の損害にとどまらず、取引先との契約に定められた違約金や納期遅延ペナルティが発生する。契約金額800万円のシステムが原因で、取引先への違約金だけで500万円を超えることもある。システムの重要度が高いほど、契約金額と実際の事業インパクトの差は開いていく。
個人情報漏えいなど、対外的な補償が必要になるケース
脆弱性を突かれて顧客の個人情報が流出した場合、被害者への通知、コールセンターの設置、見舞金や損害賠償、信用回復のための広告など、対応コストは容易に数千万円規模に膨らむ。契約金額数百万円のシステムが原因でこの規模の対応を迫られた場合、上限額はほとんど機能しない。
長期間にわたる業務停止・売上減少
基幹システムが数週間にわたって使えない状態が続けば、その間の売上減少や従業員の稼働ロスは、日を追うごとに積み上がっていく。開発費用が「システムを作る対価」であるのに対し、業務停止による損害は「システムが動くことで守られていたはずの日常の価値」であり、両者の金額の桁が違うことは珍しくない。
復旧対応にかかる追加コスト
不具合発生時、原因調査や代替手段の手配、応援人員の確保などに、当初のシステム開発費とは別の予算が発生する。これらは「システムの対価」には含まれていないにもかかわらず、実際には発注者が真っ先に支払う費用になる。
これらのケースに共通するのは、上限額が「開発会社が受け取った金額」を基準にしているのに対し、実損害は「そのシステムが業務の中でどれだけ重要な役割を担っているか」で決まるという、基準のズレだ。契約金額と業務上の重要度は、必ずしも比例しない。むしろ、比較的安価に構築されたシステムほど、止まった時のインパクトが甚大というケースは少なくない。
発注前に確認・交渉すべきポイント
契約書にサインする前に、次の観点で条項を読み直し、必要であれば交渉のテーブルに乗せてほしい。
- 上限額の基準は何か ― 契約金額そのものか、直近1年分の支払額か、固定金額かを確認する。同じ「上限あり」でも基準によって金額が大きく変わる
- 上限額の水準は自社のリスクに見合っているか ― システムが停止した場合に想定される損害額を先に試算し、それと上限額を突き合わせる。この試算作業こそが、担当者の腕の見せ所になる
- 上限額の適用が除外される事由はあるか ― 故意または重過失による損害、情報漏えい、知的財産権侵害などについては、上限額を適用しない(青天井とする)特約が入っているかを確認する。この除外規定の有無で、条項の実効性は大きく変わる
- 間接損害・逸失利益の扱い ― 「直接かつ通常の損害に限る」といった限定がある場合、逸失利益や取引先への違約金が賠償対象から外れていないかを確認する
- 損害賠償請求の期間制限 ― 「納品後1年以内に請求されたものに限る」など、時的な制限があるかを確認する。不具合が発覚するタイミングによっては、この期間を過ぎてしまうリスクがある
- 保険への加入状況 ― 開発会社がIT賠償責任保険などに加入していれば、上限額を超える部分の一部がカバーされる可能性がある。加入状況を確認し、必要であれば加入を契約条件に含める交渉も選択肢になる
交渉の際は、いきなり上限額の撤廃を求めるのではなく、まず自社側のリスク試算を示した上で、システムの重要度に応じた段階的な引き上げ(たとえば重要度の高い案件は契約金額の2倍、保守契約は年間支払額の1年分など)を提案すると、開発会社側も検討しやすい。上限額の交渉は、開発会社を疑うためのものではなく、双方が納得できるリスク分担を作るための対話だと捉えると、建設的な議論がしやすくなる。
よくある失敗パターン
現場で繰り返し見られる失敗のパターンを、あらかじめ知っておくだけでも回避できることは多い。
- 雛形をそのまま受け入れてしまう ― 開発会社から提示された契約書は、多くの場合その会社の標準雛形であり、発注者の事業リスクを反映したものではない。読み飛ばさず、自社のケースに当てはめて検討する必要がある
- 価格交渉には時間をかけるが、賠償条項は後回しにする ― 見積金額の数十万円の差には敏感でも、上限額の条項には目を通すだけで済ませてしまうケースが多い。しかし、いざという時の影響額は賠償条項の方がはるかに大きい
- 「うちは大丈夫」という楽観 ― 過去に大きな不具合を経験していない会社ほど、上限額の重要性を実感しにくい。しかし不具合は経験してから対策するのでは遅い
- 担当者が変わり、条項の経緯が引き継がれない ― 契約時の担当者が異動・退職すると、なぜその上限額で合意したのかという背景が失われ、次の契約更新時に同じ検討が繰り返されない
- 複数のベンダーが関わる案件で、責任の所在が曖昧なまま契約する ― システム開発、インフラ、保守が別々の会社に分かれている場合、それぞれの契約書の賠償条項がバラバラで、トラブル時にどの会社がどこまで責任を負うのか整理できていないケースがある
これらの失敗の多くは、悪意や怠慢から生まれるものではない。日々の業務に追われる中で、契約書の細部にまで手が回らないのは、どんな担当者にも起こり得ることだ。だからこそ、契約書を読み込み、リスクを試算し、交渉に臨むという地道な作業を丁寧に積み重ねられる担当者は、それ自体が会社にとって大きな財産になる。
まとめ
損害賠償条項の上限額は、契約書の中で目立たない一文でありながら、システムに何かあった時に会社がどこまで守られるかを決定づける、極めて重要な条項だ。開発会社が上限額を設けるのには相応の事情があり、それ自体を頭ごなしに否定するものではない。大切なのは、自社にとってそのシステムが止まった時にどれほどの損害が発生し得るかを事前に見積もり、その規模に見合った上限額になっているかを確認し、必要であれば交渉するという一連のプロセスを踏むことだ。
契約書の隅々まで目を通し、リスクを数字に落とし込み、開発会社と対等に向き合って交渉する。その作業は地味で、誰かに褒められるものでもない。しかし、いざという時に会社と従業員、そして取引先との信頼を守るのは、まさにその地道な積み重ねだ。契約書と向き合う時間を惜しまなかった担当者だけが、システムが止まったその瞬間に、胸を張って「備えていた」と言える。