◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- B2B ECの賠償額は不具合を直す費用ではなく、取引先の業務が止まったことで積み上がる費用で決まりやすい
- BtoB取引では責任範囲を契約で定めることが原則有効だが、故意・重過失があれば責任限定条項の適用が認められない場合がある
- 自社構築は責任が自社に集中し、ASP/SaaS利用でも商品マスタや出荷指示など自社運用の責任は残る
- 上限額はひな形によって水準が大きく異なり、低すぎる場合は合理的な額を上限とすべきとした裁判例もある
- 契約の上限で埋まらない部分は保険で持つ選択肢があり、適用可否や保険料は保険会社の引受審査による
目次
B2B ECのトラブルで賠償責任が問題になる場面
取引先から「御社のシステムが止まったせいで出荷が組めなかった。損害を賠償してほしい」と連絡が入ったとき、その場で法律を調べても、自社がどこまで払う立場なのかは出てきません。
損害保険会社が示す事故例には、物流システムの瑕疵で取引先の配送業務が約3か月混乱し、およそ4,000万円の請求に至った例もあります。
ただ事業者同士の取引では、賠償の範囲が法律で一律に決まっているわけではなく、契約書に置いた責任限定条項の設計で大きく変わります。
故意・重過失があればその条項が働かない場面がある点と、自社構築かASP/SaaS利用かで責任の持ち先が変わる点。
この二つを押さえることが、実務上の備えの中心になります。
システム障害・データ漏洩・誤配送で生じる損害の例
B2B ECで起きるトラブルの怖さは、復旧そのものの手間ではなく、止まっている間に取引先の側で費用が積み上がっていくところにあります。
自社のサーバーが半日止まっただけでも、受注データが流れなければ取引先の倉庫は出荷を組めず、その日の配送枠が空き、欠品の連絡と再手配が発生します。
その分の人件費や運賃は取引先が先に負担し、後から請求という形でこちらに回ってきます。
損害保険会社が特約の説明として示している事故例には、物流システムの新規開発でソフトウェアに瑕疵があり、約3か月にわたって取引先の配送業務が混乱した例があります。
再発送業務の人件費・交通費・発送運賃・外部倉庫料金に加えて、納入資材のキャンセル料、物流経費の増分、営業利益の損失まで含め、およそ4,000万円の賠償請求を受けたとされています5。
このページには判決年や事件番号までは示されていないため、確定した判決の事例としてではなく、請求がどの程度の規模になり得るかという水準感として読むのが妥当です。
同じページには、ECサイトの商品受注システムの開発でセキュリティ対策を怠ったためにクレジットカード情報が漏洩し、謝罪や調査にかかる費用、売上の減少などを含めておよそ2,300万円の賠償が認定されたとされる例も挙げられています5。
二つの例に共通するのは、賠償の中身が原因を直すための費用ではないという点です。
相手の業務が止まったこと、相手の顧客に迷惑がかかったことから派生した費用が、金額の大半を占めています。
ですから「どこまで賠償責任を負うのか」という問いは、不具合の技術的な大きさよりも、自社のシステムが相手の業務にどこまで食い込んでいるかで見当を付けることになります。
受発注だけを預かっているのか、在庫の引き当てや出荷指示まで担っているのか。
後者に近いほど、一度の停止が相手側で生む費用は大きくなります。
請求する側か、される側か
同じ障害でも、請求する側と請求される側では、手に取る書類が逆になります。
取引先としてB2B ECを利用していて損害を被った立場なら、読むのは相手方の利用規約や取引基本契約で、どこまで請求できるかを探すことになります。
一方、商品やシステムを提供して対価を受け取っている受注側であれば、読むのは自社が差し出した契約書と規約であり、そこに書いた条項が自社を守れるかどうかが論点です。
ここから先は後者、つまり請求を受ける側の立場で整理していきます。
受注側の確認は、二つの方向に分かれます。
ひとつは取引先との間で、自社がどこまで負うと約束しているか。
もうひとつは、システムを外部ベンダーから借りている場合に、そのベンダーが自社に対してどこまで負うと定めているかです。
この二つは別々の契約で決まるため、上限額も免責の範囲も一致しているとは限りません。
受注側事業者が負う損害賠償責任の法的な原則
契約自由の原則と責任限定条項
賠償の範囲が法律で一律に決まっていれば話は単純ですが、事業者同士の取引ではそうなっていません。
契約当事者間、とくにBtoB取引において、当事者が負う責任の範囲について契約で特別の定めを置くことは、原則として有効とされています3。
つまり、取引基本契約や利用規約に書いた賠償の上限や免責の範囲は、体裁を整えるための文言ではなく、実際に効く条件として扱われるということです。
この種の条項は、二つの型に分けて読むと理解しやすくなります。
一定の事由については責任を負わないと定める免責条項と、責任は負うとしてもその額に上限を設ける責任限定条項です。
実際の契約書では、「当社の責めに帰すべき事由による場合に限る」という限定と、「賠償額は〇〇を上限とする」という上限の定めが、一つの条文にまとめて書かれていることもあります。
どちらの型として書かれているかで、争いになったときに相手が突いてくる箇所も変わります。
BtoBのSaaS利用規約について解説した弁護士監修の記事では、事業者に故意・重過失がない限り、免責・責任限定条項は原則として有効に機能すると整理されています2。
裏を返せば、有効に機能する範囲には「故意・重過失がない限り」という条件が付いているということでもあります。
この条件が実際にどう働くかは、次の節で判例に沿って確認します。
消費者契約法との違い
賠償条項を書くときに混乱しやすいのが、消費者向けの規制との関係です。
消費者契約法には、事業者の故意・重過失による損害賠償責任を一部免除する条項などを無効とする規制がありますが、この規制はBtoC取引に向けられたものであり、事業者間の取引には原則として適用されません2。
同じ会社がBtoC向けの通販サイトとBtoB ECの両方を運営している場合、この違いは規約の書き分けに直結します。
消費者向けの規約で使っていた表現をそのままB2B側に持ってくると、事業者間だからこそ置ける条件を活かせないまま、取引先との力関係だけで賠償範囲が決まってしまうことがあります。
逆に、BtoB向けの広い免責をそのまま消費者向けへ流用すれば、今度は消費者契約法の規制に触れる話になります。
一つの規約を使い回すのではなく、どちらの取引に向けた文書なのかをはっきりさせておくところが出発点です。
もっとも、BtoB取引なら何を書いても通るという意味ではありません。
適用されないのはあくまで消費者契約法の規制であって、条項の内容が当事者間の衡平を著しく損なう場合には、別の理由でその適用が認められないことがあります。
その代表が、故意・重過失があった場合の扱いです。
責任限定条項が無効になるケース
判例に見る故意・重過失の境界
この点でよく参照されるのが、東京地方裁判所平成26年1月23日の判決です。
ベンダーが製作したアプリケーションの脆弱性により顧客のクレジットカード情報が流出した事案で、裁判所は、故意・重過失がある場合に責任限定条項を適用することは「著しく衡平を害するものであって、当事者の通常の意思に合致しない」として、その適用を認めませんでした3。
ここで示されたのは、条項そのものが最初から無効だという判断ではなく、故意・重過失という場面にはその条項を及ぼさないという判断です。
したがって、軽過失にとどまる場合には責任限定条項は原則どおり働きます。
上限を定めた意味がなくなるわけではなく、効く場面と効かない場面が分かれる。
この区別を押さえておかないと、上限額さえ書いておけば支払いはそこで止まるという前提で契約を設計してしまいます。
では、どこからが重過失なのか。
これは事案ごとの判断であり、「この対応をしていれば軽過失にとどまる」という線が一般に引かれているわけではありません。
確実に言えるのは、争いになったときに問われるのが、その時点で自社が何を知っていて、何をしていたかだという点です。
脆弱性の存在を把握していたのか、報告を受けてどう扱ったのか、対策を見送った理由は何だったのか。
これらを説明できるかどうかが、条項が働く側に立てるかどうかを左右します。
そして「知っていて何をしていたか」を説明できる相手は、システムの実装と運用を誰が握っているかによって変わります。
自社で構築したECなのか、ベンダーのASP/SaaSを借りているのかで責任の持ち先が分かれるのは、このためです。
自社構築ECとASP/SaaS利用で責任の所在はどう変わるか
自社構築の場合の責任の集中
自社でECを構築し、サーバーも自社の管理下に置いている場合、設計・実装・運用のどこで起きた不具合であっても、取引先から見れば相手は自社ひとつです。
原因がミドルウェアの古さにあっても、外注した開発会社の実装にあっても、取引先に対して一次的に説明し、請求を受けるのは契約の相手方である自社になります。
その分、社内で誰が何をいつやるかが決まっているかどうかが、そのまま説明力の差になります。
脆弱性の情報が公開されてから修正を適用するまでの手順、外部による診断をどの頻度で入れるか、ログを日常的に誰が見ているか。
こうした運用が決まっていなければ、事故が起きたときに「対応していた」と示す材料が手元に残りません。
重過失の線が事案ごとであることは前節のとおりですが、把握していた不具合を放置していた経過が残っているかどうかは、争いの中で必ず見られる部分です。
開発を外部に委託している場合も、取引先との契約が自社名義である限り、取引先に対する責任が委託先へ移るわけではありません。
委託先にどこまで求償できるかは、自社と委託先の間の契約で別に決まる話です。
取引先への対応と委託先への求償は、同じ事故に対して二本立てで進むことになります。
ASP/SaaS利用時のベンダー側の対策例
ベンダーが提供するASP型のB2B ECを使う場合、基盤のセキュリティはベンダー側の守備範囲に入ります。
たとえばASP型のB2B ECシステムであるEC-Rider B2B Ⅱでは、日本政府が求めるセキュリティ要求を満たすISMAP対応プラットフォームの採用、OS・ミドルウェアの継続的な最新化、ファイアウォール・WAF・IPS/IDS・アンチウイルスによる不正アクセス対策、第三者セキュリティ診断によるアプリケーション脆弱性対策、ISMS認証の取得という5つの対策を講じていると説明されています1。
これは特定のベンダー1社の実装例であり、ASP/SaaSであれば共通して備わる法定の基準ではありません。
とはいえ、この並びを見ると、自社構築を選んだ場合に自前で用意すべき項目がそのまま浮かび上がります。
基盤の準拠、パッチの適用、通信経路の防御、外部からの診断、組織としての管理体制。
どれも一度整えれば終わりではなく、継続して回す前提の対策です。
自社の体制でここまで維持できるかどうかは、構築方式を選ぶ段階で考えておく判断材料になります。
ただし、ASP/SaaSを使えば賠償責任がベンダーへ移るわけではありません。
取引先と契約しているのは自社であり、商品マスタの登録内容、価格や在庫の設定、アカウントの発行と停止、出荷指示の運用は自社の手元に残ります。
取引先が被った損害の原因がこの領域にあれば、基盤がどれだけ堅牢でも責任の所在は自社側です。
誤った価格を登録して取引先が大量に発注した、退職者のアカウントを止めていなかったという類の事故は、基盤の対策では防げません。
そして、ベンダーとの契約は取引先との契約とは別に結ばれています。
ベンダーの利用規約やSLAには、ベンダーが自社に対して負う責任の範囲と上限が定められており、その水準が、自社が取引先に対して負っている約束と揃っている保証はありません。
取引先からは業務停止に伴う費用を含めた請求を受け得る一方で、ベンダーから回収できる額は規約上の上限までということも起こります。
この段差をどこで埋めるかが、次に考える上限額の設計と、その先の保険の話につながります。
賠償額の上限を契約でどう定めるか
業界のひな形が示す上限額の目安
上限額をいくらに置くかは、参照するひな形によって水準が大きく違います。
JISA(情報サービス産業協会)のASPサービスモデル利用規約では、損害賠償額の上限を平均月額料金1か月分とする例がある一方、米国のY Combinatorが公開しているひな形では、直近12か月分の支払済み利用料という、より高い水準が採られています2。
どちらも業界団体や海外の契約ひな形が示す一例であり、法律が定めた基準ではありません。
同じ「上限を定める」という作業でも、平均月額料金1か月分と直近12か月分では、実際に支払う額が一桁変わります。
ここに前半で見た事故例を並べてみると、取引先の配送業務が約3か月混乱して積み上がった費用の規模と、月額料金1か月分という水準の間には大きな開きがあることがわかります5。
上限を低く置くことは受注側にとって当然に有利に見えますが、その水準を取引先が受け入れるかどうかは別の問題です。
さらに、低く書けば必ずその額に収まるとも限りません。
契約上定められていた責任限度額が低すぎるときは、信義公平の原則から合理的な額を上限とすべきとした裁判例があると紹介されています2。
上限の額は、自社が受け取っている対価の大きさや、預かっている業務の重さと釣り合う範囲で考えておくほうが、実際に争いになったときに説明が立ちます。
取引先が大手で、購買部門から上限の引き上げや削除を求められることもあります。
その場合、一律に拒むか全面的に飲むかの二択にする必要はありません。
上限を引き上げる代わりに賠償の対象となる損害の範囲を絞る、重要度の高い取引だけ個別契約で別扱いにするといった組み合わせで調整する余地があります。
どの組み合わせを選ぶにせよ、自社が引き受けた上限と、ベンダーから回収できる上限との差は、自社が抱えることになります。
賠償リスクを減らすための準備
契約見直しのポイント
契約を見直すとき、最初に手を付けるのは条文の書き換えではなく、賠償について書かれた文書がいくつあるかの確認です。
取引基本契約、個別契約や注文書の裏面約款、B2B ECサイトの利用規約、SLA。
これらが別々の時期に作られていると、上限額や免責の範囲が文書ごとに食い違っていることがあります。
食い違ったままだと、いざというときに「どれが優先するのか」という入口の議論から始めることになります。
取引先ごとに個別契約を結んでいる場合は、社内で条件がばらついていないかも見ておく必要があります。
ある取引先とだけ上限を外していた、別の取引先には改定前の規約を適用したままになっていた。
こうした状態になっていないかは、平時のうちにしか確認できません。
あわせて、ベンダーとの契約も同じ観点で読みます。
自社が取引先に約束している上限と、ベンダーが自社に約束している上限との間に、どれくらいの差があるのか。
その差は、契約の文言をどう直しても文書の中だけでは埋まりません。
埋められない分をどう持つかが、次の判断になります。
保険加入という選択肢
契約の条項でできるのは、通常の過失で起きた事故について、支払う額におおよその見通しを付けるところまでです。
故意・重過失が認定されれば条項の適用が認められない場合があり3、上限が低すぎると判断されれば合理的な額まで引き上げられる可能性もあります2。
残ったこの部分を、契約以外の手段で持つかどうかが最後の判断です。
その選択肢のひとつが保険です。
サイバーリスク保険のIT業務担保特約は、記名被保険者が日本国内でシステム設計・ソフトウェア開発業務等のIT業務を行っていることを前提に適用され、他人の事業の休止・阻害等に起因する損害を補償の対象としています4。
補償の中身には、法律上の損害賠償金と弁護士費用等の争訟費用に加えて、緊急対応費用、サイバー攻撃対応費用、コンピュータシステム復旧費用、再発防止費用といった事故対応の費用が含まれます4。
賠償金だけでなく事故対応の費用が含まれている点は、実務では小さくありません。
情報漏洩が疑われた段階から、原因の調査、取引先への説明、再発防止策の実施と、賠償額が固まるよりずっと前に支出が始まるからです。
先に見た事故例でも、謝罪や調査にかかる費用が認定された金額の一部を構成していました5。
ただし、この特約の説明はシステム設計やソフトウェア開発といったIT業務を行う事業者を主な対象として書かれており、商品を販売するEC事業者への適用について直接の記載があるわけではありません4。
自社が特約の前提に当てはまるのか、保険料がどの程度になるのかは、保険会社の引受審査を経なければわかりません。
自社でシステムを構築して取引先に提供しているのか、ベンダーのASPを利用して商品を売っているのかによって、相談の入口も変わります。
加入を判断するときの物差しは、契約で定めた上限と、取引先の業務が止まったときに現実に積み上がる費用との差です。
その差が自社で吸収できる範囲にとどまるなら、契約の設計を整えるだけで足ります。
桁が違うと感じたなら、その分を保険で持てるかを保険会社に当たってみる順序になります。
自社の契約がどちらに近いかは、条項を一つずつ当たってみないと判断できません。
読み返すときに目を向ける箇所を、次に整理しておきます。
契約の条項をどう書くかは、システムの基盤を誰が持ち、どの作業が自社の手元に残るかと切り離して決められないため。
ASP型のB2B ECで基盤側にどこまでのセキュリティ対策が備わり、商品マスタや出荷指示など自社の運用としてどの作業が残るのかを、自社の取引の流れに当てはめて確認できます。無料相談で要件を整理する
契約書で確認すべき賠償条項のチェックポイント
責任を負うかどうか、負うとしていくらまでか、上限を超えた分をどう持つかという関係で並べています。
- 責任を負う場面が「当社の責めに帰すべき事由による場合」などの形で限定されているか2
- 故意・重過失があった場合には上限が及ばないことを前提に、条項全体を設計しているか3
- 賠償額の上限をどの基準で置いているか(平均月額料金1か月分か、直近12か月分の支払済み利用料か)2
- 上限の水準が、受け取っている対価や預かっている業務の重さと釣り合っているか2
- 取引先の営業利益の損失や再発送費用といった二次的な費用を、賠償の対象に含めるか除くか5
- ベンダーが自社に対して負う上限と、自社が取引先に対して負う上限の差がどれくらいあるか1
- 契約で埋まらない差を、保険などの別の手当てで持つかどうかを決めているか4
自社構築か、ベンダーのASP/SaaS利用かで、確認する先が自社の開発・運用体制になるか、ベンダーの利用規約とSLAになるかが変わります。
要点の整理
| 軸 | 基準 |
|---|---|
| BtoB取引の原則 | 責任の範囲を契約で特別に定めることは原則有効。消費者契約法の規制はBtoCに限定される |
| 原則が働かない場面 | 故意・重過失があるときは責任限定条項の適用が認められないことがある |
| 上限額の水準 | 平均月額料金1か月分から直近12か月分の支払済み利用料まで、参照するひな形で差が大きい |
| 責任の持ち先 | 自社構築は自社に集中。ASP/SaaSは基盤をベンダーが担うが、設定・運用の責任は自社に残る |
| 契約で埋まらない分 | 故意・重過失や上限の見直しで残る部分は、保険などの手当てを個別に検討する |
契約の上限だけでは埋まらない部分を測るには、現在の受発注の流れと、システムのどこを誰が管理しているかの整理が先に必要になるため。 いまの受注業務のどこが外部の基盤に載り、どこが自社の設定と運用に残るのかを切り分けたうえで、契約と保険のどちらで備える範囲なのかを検討する材料が得られます。
よくある質問
発注企業から損害賠償を請求された場合、受注側としてまず何を確認すべきか
取引先との間にある契約文書のうち、賠償について定めた条項がどれかを特定し、上限額と責任を負う範囲の限定がどう書かれているかを確認します。
次に、その事故が自社の管理範囲で起きたのか、利用しているベンダーの基盤で起きたのかを切り分けます。
取引先への責任とベンダーへの求償は別の契約で決まるため、二本立てで進める話になります。
あわせて、いつ事象を把握し、その後どう対応したかの経過を記録として残しておくことが、故意・重過失を巡る議論で必要になります3。
責任限定条項を定めていれば、故意・重過失の場合でも一切請求されないのか
そうとは限りません。
東京地方裁判所平成26年1月23日判決は、故意・重過失がある場合に責任限定条項を適用することは著しく衡平を害するとして、その適用を認めませんでした3。
軽過失にとどまる場合は原則どおり条項が働きますが、どこからが重過失にあたるかは事案ごとの判断で、あらかじめ一般的な線が引かれているわけではありません。
海外の取引先とのBtoB EC契約でも、同じ考え方が使えるか
本記事で扱った「BtoB取引では責任限定条項が原則有効」という整理は、日本法を前提とした解説に基づくもので、そのまま海外取引に及ぶとは言えません。
上限額の水準感も地域によって異なり、米国のY Combinatorのひな形では直近12か月分の支払済み利用料という例が採られています2。
準拠法と裁判管轄をどう定めるかで結論が変わる領域のため、取引を始める前に個別に専門家へ確認するのが確実です。
ASP/SaaS型のBtoB ECからベンダーを乗り換える際、賠償責任の引き継ぎで確認すべき点は何か
ベンダーが変わっても、取引先に対して責任を負うのは契約の相手方である自社のままです。
確認したいのは、旧ベンダーの契約期間中に生じた事象について契約終了後も責任を問えるか、データ移行の期間に起きた事故がどちらの責任範囲に入るか、新ベンダーの規約で定められた上限が自社の取引先への約束と大きくずれていないかの三点です。
いずれも各契約で別々に定まるため、移行の計画を立てる段階で条項を突き合わせておく必要があります。
- 1 出典：株式会社フライトソリューションズ「5つの強力なセキュリティ対策（EC-Rider B2B Ⅱ 機能紹介）」（2026年）
- 2 出典：クラウドサイン（弁護士監修記事）「SaaS・サブスクリプションビジネスの利用規約—免責・責任限定条項とその限界」（2019年）
- 3 出典：弁護士法人内田・鮫島法律事務所「責任限定条項の有効性」（2024年）
- 4 出典：東京海上日動火災保険株式会社「IT業務を行う事業者の皆様向け－基本補償の概要（サイバーリスク保険）」
- 5 出典：東京海上日動火災保険株式会社「IT業務を行う事業者の皆様向け－IT業務の事故例」
