システム開発費が未払いになったとき、最初にすべきこと｜不具合・損害賠償を主張された場合の債権回収

2026.09.22

システム開発費が未払いになったら、すぐサービスを止めるべきか

システム開発会社から、こんな相談を受けることがあります。

「開発費を払ってもらえない」

「不具合があるから支払わないと言われている」

「こちらが請求したら、逆に損害賠償をすると言われた」

「もうシステムを止めたい」

経営者として腹が立つのは当然です。

しかし私は、未払いだからといって、いきなりシステムを停止するのは危険だと考えます。

最初にやるべきなのは、相手へ強く出ることではありません。

開発代金、不具合、追加開発、損害賠償、保守契約を一度分解することです。

相談事例｜2,180万円のシステム開発費が未回収

あるシステム開発会社を想定します。

年商約5億8,000万円。

物流・卸売業向けの業務システムを開発しています。

大口顧客から受発注・在庫管理システムを受注しましたが、本番稼働後、約2,180万円が未払いとなりました。

顧客側の主張は、

「システムに不具合があるので払えない」

というものです。

さらに、過去に発生した3時間程度のシステム障害について、

• 緊急配送費
• 社員の残業代
• 取引先への値引き
• 失注したとされる売上
• 社内対応コスト

など、合計約3,400万円の損害が発生したと主張してきました。

一方、システム自体は現在も毎日利用されています。

ここで開発会社の社長は、

「2,180万円を払わないならシステムを止める」

と言い始めました。

この問題の本質は「払うか、止めるか」ではない

私は、この問題の本質は、

「システムを止めれば払ってくれるか」ではない

と考えます。

まず未回収の2,180万円そのものを分ける必要があります。

例えば、

• 契約・納品・本番稼働・請求が明確な債権
• 追加開発で注文書はないが、メールやTeamsに依頼記録がある債権
• 保守費や追加対応費など、契約条件を再確認すべき債権

です。

今回でいえば、約1,050万円は比較的証拠が揃っています。

一方、約630万円の追加開発費については、正式な注文書がありません。

この2つを同じ「2,180万円の未払い」として扱うと、回収交渉が難しくなります。

私なら、まず「争いのない債権」から回収する

相手から損害賠償を主張されると、経営者は、

「では全部裁判だ」

と言いたくなります。

しかし、相手方の経理担当者が、

「争いのない部分なら払える」

と言っているのであれば、私はそこを使います。

全部を一つの紛争にしない。

これが重要です。

例えば、証拠が明確な1,050万円については、損害賠償協議とは切り離して支払いを求めます。

そのうえで、追加開発費、不具合、損害賠償について別々に検証します。

100点満点の2,180万円を一気に取ろうとして、回収しやすい1,050万円まで止めてしまう必要はありません。

よくある失敗①　未払いを理由に基幹システムを突然止める

保守契約にサービス停止条項が入っていることはあります。

だからといって、

「払わないなら今日止めます」

でよいとは限りません。

今回のシステムは、受発注、在庫、物流に使われています。

停止すれば、顧客側の業務が広範囲に止まる可能性があります。

すると本来は2,180万円の債権回収問題だったものが、

「システムを停止されたことでさらに損害が発生した」

という新しい紛争に変わります。

停止を検討するなら、契約条項、通知期間、停止範囲、データへのアクセス、バックアップ、復旧条件まで確認します。

よくある失敗②　「不具合があるなら支払わなくてよい」と考える

逆に顧客側から、

「バグがあるのだから代金は払わない」

と言われることもあります。

しかし、システムに一部不具合があることと、開発代金全額が支払不要になることは同じではありません。

確認するのは、

• 当初仕様は何だったのか
• 何を完成とする契約だったのか
• 検収条件はどうなっているか
• どの部分に不具合があるのか
• 本番利用できている範囲はどこか
• 修補可能なのか

です。

「バグがあるか」ではなく、「契約上、何が履行され、何が履行されていないのか」を見る必要があります。

追加開発費は、注文書がないと回収できないのか

システム開発でよく起きるのが、追加要望です。

現場では、

「これも追加してください」

「それもできますか」

という依頼がTeamsやメールで飛んできます。

営業担当者が、

「費用はあとでまとめましょう」

と進めてしまう。

そして完成後に金額を出すと、

「そんな金額で頼んでいない」

と言われる。

今回もその状態です。

私なら追加開発を機能単位へ分けます。

そして、

• 誰が依頼したか
• いつ依頼したか
• 具体的に何を作ったか
• 見積や金額説明をしたか
• 顧客がその機能を利用しているか

を、メール、チャット、議事録、チケット、ソースコード、工数記録などから復元します。

「630万円の追加開発」ではなく、一つ一つの機能について請求根拠を作る。

これが重要です。

3,400万円の損害賠償をそのまま差し引かない

顧客から、

「こちらには3,400万円の損害がある。だから御社には払わない」

と言われても、その数字をそのまま受け入れる必要はありません。

例えば失注売上1,600万円。

本当にシステム障害が原因なのか。

売上そのものが損害なのか。

利益はいくらだったのか。

緊急配送費や残業代についても、本当に障害が原因で追加発生したものなのか。

一つずつ確認します。

「損害があった」と「開発会社がその全額を負担する」は別問題です。

新しい追加開発を受けて関係修復するべきか

今回、顧客からさらに約500万円の追加開発依頼が来ています。

「これをやってくれれば、支払問題もまとめやすい」

と言われています。

私は、現在のままでは着手しません。

未払いがある。

追加開発費でも揉めている。

損害賠償でも揉めている。

この状態で新しい仕事を始めれば、争点がさらに増えます。

受けるなら、少なくとも、

• 仕様
• 価格
• 支払時期
• 前払いの有無
• 検収条件
• 既存未払いとの関係

を明確にしてからです。

この問題は、営業部と開発部の問題でもある

今回、開発部は、

「営業が安請け合いした仕事を、こちらが無料で直している」

と不満を持っています。

営業は、

「大口顧客を失いたくない」

と考えています。

経理は、

「売上ではなく入金を見てほしい」

と思っています。

私は、この債権回収問題は、顧客だけの問題ではないと考えます。

追加開発を誰が承認するのか、どこから有償になるのか、検収を誰が取るのかという社内ルールの問題でもあります。

私ならこう進めます

新しい追加開発はいったん止める
↓
既存システムは感情的に停止しない
↓
未回収2,180万円を債権ごとに分解する
↓
契約書・仕様書・検収・メール・チャットを保全する
↓
追加開発の請求根拠を機能別に整理する
↓
システム障害の原因を技術的に検証する
↓
顧客の3,400万円損害主張を項目別に検証する
↓
争いのない債権から支払いを求める
↓
今後の保守費を新たな未回収が生じない条件へ変更する
↓
残った争点について交渉・法的回収を検討する

実務上のチェックポイント

• 基本契約書・個別契約書
• 請負か準委任か
• 成果物と完成条件
• 検収条件と検収期間
• 本番稼働日
• 実際の利用状況
• 未回収金額の請求書別内訳
• 追加開発の依頼記録
• 追加見積の提示状況
• 不具合と追加要望の区別
• 障害ログ
• 負荷テスト条件
• 顧客側データ量
• 損害賠償請求の証拠
• 損害との因果関係
• 損害賠償上限条項
• 保守契約の停止条件
• データ返還・バックアップ条件
• 追加開発の承認ルール
• 今後の支払条件

なぜ法律だけでは解決できないのか

システム開発費の債権回収では、契約、不具合、損害賠償、相殺などの法的整理は重要です。

しかし経営判断としては、それだけでは足りません。

突然サービスを止めれば、自社の評判を傷つける可能性があります。

未払いを放置すれば、開発社員が疲弊します。

顧客を失いたくないという理由だけで追加開発を続ければ、未回収額がさらに増えます。

重要なのは、

債権回収によって、さらに大きな損失を作らないことです。

まとめ｜システム開発費の債権回収で最初に守るもの

私は、システム開発費が未払いになったとき、最初から、

「内容証明を送る」

「システムを止める」

「裁判をする」

とは考えません。

まず、

何が確実に請求できるのか。

何が争われているのか。

本当にどこに不具合があるのか。

相手の損害はいくらなのか。

サービスを止めた場合に何が起きるのか。

これを分けます。

重要なのは、誰が正しいかではなく、会社を守れるかです。

全部を争わない。争わなくていい金から回収する。

そして、債権回収のために新しい損害を作らない。

私は、それがシステム開発費未払いに対応するときの最初の一手だと考えます。

※本記事は、システム開発費の未払い・債権回収に関する一般的な経営上の考え方を整理したものです。個別案件における請求権、契約不適合、損害賠償、相殺、サービス停止、支払督促、訴訟その他の法的判断を示すものではありません。実際の判断は、契約書、仕様書、検収状況、障害原因、損害資料、当事者間の協議経緯などによって異なります。