【専門家コラム】ERP・基幹システムの刷新プロジェクトがとん挫したら、その責任・費用は誰が負担するのか｜請負・準委任の違いと発注側の協力義務

代表的な製品のSAP ERP 6.0では、標準保守が2027年末に終了するバージョンがあり^※1、基幹システムの刷新が課題となっています。基幹システム刷新プロジェクトでは、ERP製品の標準機能に合わせる業務変更や追加開発の範囲についての認識の相違、意思決定の遅れ、進捗・変更管理の不備などから、遅延・費用増や導入中止をめぐる紛争が生じがちです。こうした場合でも、支払済みの費用が当然に戻るわけではありません。本稿では、クラウドERPをFit to Standard（標準機能に業務を合わせる進め方）で導入するプロジェクトが頓挫した場合を想定しつつ、裁判例を踏まえて費用負担・責任分担に関する考え方を整理します。

※1

• ※1　SAP「保守方針」。対象バージョンの標準保守は2027年末まで、オプションの延長保守は2030年末まで。https://support.sap.com/ja/offerings-programs/strategy.html

1　契約が分かれるクラウドERP導入プロジェクトの責任の所在　―サービス提供事業者に支払った利用料は、ベンダーから回収できるか―

契約が分かれると何が問題になるか

クラウドERPでは、サービス提供事業者がERPの機能をクラウドサービスとして提供し、導入ベンダー（導入支援を担うIT企業。以下、単に「ベンダー」ともいいます）が業務要件の整理、設定、データ移行、必要な開発などを担うのが一般的です。発注側は、前者とSaaS利用契約を、後者と導入支援契約を別々に結ぶことになります。

この場合、導入プロジェクトが頓挫したとしても、サービス提供事業者が仕様どおりのサービスを提供している限り、同社の契約違反は問えません。サービス利用契約を中途解約しても、既払金を返還しない契約条項があれば、支払済みの利用料は戻りません^※2。そこで、この種の紛争では、ベンダーに対し、ベンダーに支払った委託料やサービス提供事業者に支払った利用料相当額について損害賠償請求できるかを検討するのが一般的です。

※2

• ※2　さらには、中途解約の場合には残期間分の利用料の支払いを義務付ける規定がある場合もあります。

前提となるベンダーの責任

ベンダーに対して利用料相当額等の損害賠償を請求するためには、ベンダーの債務不履行または不法行為が認められなければなりません。その判断は、導入支援契約が請負か準委任かで変わり得ます（契約の性質は、契約の表題ではなく、成果物、納期、検収、報酬支払条件などの定めに基づき取引の実質で判断します）。請負は仕事の完成を約束する契約であり（民法632条）、合意した期限までにシステムを完成できないような場合には、発注側は契約を解除して支払済みの報酬の返還を求め、損害の賠償も請求できます（同法415条、541条、542条、545条）。

他方、準委任は業務の適切な遂行を約束する契約です（同法656条^※3）。システムが稼働に至らなかったという理由だけで損害の賠償を請求できるとは限らず、ベンダーの善管注意義務（同法644条）違反を主張・立証する必要があります。

※3

• ※3　ただし、準委任の中には、委任事務の履行により得られる成果に対して報酬を支払うことを約する成果完成型準委任と呼ばれる契約類型もあります（民法656条、648条の2）。

なお、工程ごとに個別契約を締結する多段階契約方式のプロジェクトでは、どの個別契約について債務不履行ないし不法行為があったのかも問われます。プロジェクトが頓挫しても、履行済みの工程（個別契約）の費用まで当然に返還・賠償請求できるわけではありません。

サービス提供事業者に支払った利用料相当額はベンダーが責任を負う「損害」に含まれるのか

ベンダーの責任が認められれば、義務違反と相当因果関係のある損害が賠償の対象になります（同法416条）。ベンダーに支払った委託料に限られず、他社へ支払った費用も、義務違反によって無駄になったものといえれば損害に含まれます。

この点で参考になるのが文化シヤッター事件です。同事件では、他社のクラウド基盤（PaaS）を利用した販売管理システムの開発が頓挫しました。控訴審（東京高判2024年5月16日^※4）は、他社のサービス利用料なども損害に含めたうえで、発注側の過失を1割として過失相殺をしたうえで、開発を受託した日本IBMに約20億564万円の賠償を命じました。

※4

• ※4　文化シヤッター事件・東京高判令和6年5月16日令和4年（ネ）第3424号。

もっとも、別の裁判例では、開発のために契約したクラウドサービスのライセンス費用の請求が一部否定されています^※5。すでに利用して便益を得た分や、他の用途に転用できる分は、プロジェクトの頓挫により無駄になった費用とはいえないと判断される可能性があります。

※5

• ※5　東京高判令和7年9月25日（令和6年（ネ）第1341号）。

回収額を左右する事情　―過失相殺や責任制限条項による認容額の減額―

損害と認められても、全額を回収できるとは限りません。文化シヤッター事件の控訴審（東京高判2024年5月16日^※6）は、上記の過失相殺に加え、賠償額の上限を各個別契約の対価とする責任制限条項を適用し、発注側の賠償額を減額しています。その結果、認容額は日本IBMへ支払った委託料と同額にとどまりました。

※6

• ※6　文化シヤッター事件・前掲東京高判令和6年5月16日。

2　ベンダーのプロジェクトマネジメント義務と発注側の協力義務

裁判例に見る発注側・ベンダーの義務

発注側が支払済みの費用を回収できるか、逆に残りの工程分の報酬まで支払わなければならないかの決め手になることが多いのが、ベンダーのプロジェクトマネジメント義務、発注側の協力義務です。

ベンダーは、システム開発の専門家としてプロジェクトの進捗や課題を管理し、実現可能性や遅延・費用増のリスクを説明して、発注側に必要な判断を求めるなどといった内容のプロジェクトマネジメント義務を負います。一方、発注側にも、ベンダーに必要な情報を提供し、現場との調整を進めて適時に仕様を決めるなどといった協力義務があります。プロジェクト頓挫の原因が発注側の協力義務違反にあると認定されてしまうと、ベンダーに対する損害賠償請求が認められる可能性は低くなってしまいます^※7。それでは、どのような行動が協力義務違反と評価されるのでしょうか。近時の裁判例をみていきましょう。

※7

• ※7　発注側に協力義務違反があっても、ベンダーが当然に免責されるわけではなく、双方に原因があるとして過失割合で調整される例もあります。

旭川医科大学事件の控訴審（札幌高判2017年8月31日^※8）では、仕様凍結の合意後も大量の追加要望を出し続けた病院側の協力義務違反が認められ、一審を覆してベンダーの責任が否定されました。必要な機能を伝えただけのつもりでも、開発を妨げる追加要求と判断されれば協力義務違反と評価されます。

※8

• ※8　旭川医科大学事件・札幌高判平成29年8月31日判時2362号24頁。https://www.courts.go.jp/assets/hanrei/hanrei-pdf-87065.pdf

野村ホールディングス事件の控訴審（東京高判2021年4月21日^※9）でも、変更要求の反復や、業務変更を拒む現場との調整不足が問題視され、一審が認めた約16億円の賠償が取り消されました。野村側の損害賠償請求は全部棄却されています。

※9

• ※9　野村ホールディングス事件・東京高判令和3年4月21日（平成31年（ネ）第1616号）。

その他の裁判例にみる協力義務違反を根拠づける事情

協力義務違反が問題になるのは、上記裁判例に顕れている事情に限られません。その他の裁判例では、懸案事項について期限までに意思決定をしなかったこと^※10、仕様の確定作業や資料の提供を行わなかったこと^※11、設計完了の判定後に仕様変更に当たる要求をしたことや発注側の担当者がベンダーに威圧的・侮辱的な発言をしたこと^※12等が、協力義務違反と評価されています。

※10 ※11 ※12

• ※10　東京地判平成16年3月10日判タ1211号129頁。
• ※11　東京地判平成23年10月20日（平成20年（ワ）第25855号）。
• ※12　前掲東京高判令和7年9月25日。

これらの裁判例から見て取れるように、発注側に協力義務違反が認められるかどうかは、要望や対応の内容と時期、開発工程への影響、ベンダーの説明・対応等を総合的に考慮して判断されるといえます。

協力義務違反を問われないための発注側の対応

発注側が協力義務違反の責任を問われないためには、次の対応が重要です。まず、仕様の追加・変更だけでなく、回答や承認の遅れ、現場の抵抗を放置することもリスクと認識すべきです。担当部門が決められない問題を経営層へ上げる仕組みを用意し、ベンダーから判断を求められた事項には期限を設けて回答するような運用も検討すべきでしょう。

ベンダーから求められた資料や情報は期限内に提供し、要件定義の完了後に生じた要望は、変更管理の手続に乗せ、費用と納期への影響を確認したうえで採否を決めるようにすることも重要です。ベンダーの対応に不満がある場合でも、担当者が威圧的な言動をとれば、それ自体が協力義務違反を根拠づける事情と評価されかねません。

また、遅延が生じたときは、納期が確定的な完成期限なのか、目標日程なのかを確認します。予定が遅れたという事実だけでは責任の結論は出ません。遅延原因、各当事者の対応、変更合意の有無を時系列で整理し、当初日程と変更後の日程を区別して記録しておけば、発注側の対応に問題がなかったことを示すための有益な資料になるでしょう。

3　アドオン・カスタマイズの費用と契約・社内体制の備え

膨らんだ作業の費用は誰が負担するか

Fit to Standardで始めても、業務との隔たりが大きければアドオン・カスタマイズの作業量が膨らみます。どの当事者がその費用を負担するかを決める際に重要となるのは、当初の業務範囲（おおむね、要件定義工程で合意した作業範囲です）に含まれているか否かです。当初の委託業務の範囲外の作業を求める場合は、原則として追加契約を結び、追加費用を支払う必要があります。

例えば、従来の帳票を残したいという要望について考えてみると、その帳票が当初から合意した必須帳票なのか、ERPの標準帳票への変更にいったん合意した後の変更要求なのかで評価は変わります。

見積もり・契約書・運用等の注意点

見積もりや契約書、要件定義書等では、業務・機能ごとに、ERP製品の標準機能で従前の業務を実現できる範囲、標準機能を使いつつも発注側が業務を変える必要がある範囲、アドオン・カスタマイズで対応する範囲を区別・確認することが重要です。

契約書等を整えても、社内の体制が伴わなければ、協力義務違反と評価されかねません。現場の要望の採否を判断できる意思決定者を置くこと、要望の窓口を一本化して採否と理由を記録する変更管理を行うこと、議事録を速やかに確認して異議がある場合にはあとで確認できる形式（書面、メール等）で記録を残すこと等が有益です。紛争になれば、誰が、いつ、何を決め、何を求めたかを示すこれらの記録が、双方の責任を判断する重要な証拠になります。

以上の点も含め、本稿のテーマに関する発注側の確認事項をまとめると、次のとおりです。契約締結時と各工程の区切りで確認してください。

どの製品・ベンダーを選んでも、契約上の役割分担と自社の意思決定を整えることが重要です。遅延が見えた段階で課題と記録を整理し、続行・縮小・中止の選択肢を検討することが、損失の拡大を防ぎます。