「納期を過ぎても動くものが出てこない」「納品されたが想定と違い、追加費用を言われた」「SaaSが突然値上げ・サービス終了になり、データの取り出しに困った」――当事務所にはこうしたご相談が寄せられます。システム開発委託とSaaS利用契約は目に見えない成果物を扱うため、契約書で「何を・いつまでに・どの基準で」合意しているかが結果を左右します。この記事では、請負と準委任の違い、仕様・検収、契約不適合責任と損害賠償の上限、SaaS利用規約のチェックポイント、解約時のデータ返還を、民法の条文を確認しながら整理します。
システム開発・SaaSでトラブルが起きる3つの構造
システム開発やSaaS導入をめぐる紛争には、業種を問わず共通する構造があります。第一に、成果物が無形で、契約時点では「完成形」を双方が正確に共有できないこと。見積書と注文書だけで着手すると、後から「言った・言わない」になります。第二に、ユーザ企業とベンダの知識差で、互いに相手が分かっている前提で進めてしまうこと。第三に、SaaSのように相手方が用意した利用規約をそのまま受け入れる取引では、免責・解約・データの条項を読まずに申し込み、問題が起きて初めて内容を知ることです。
トラブルの原因は技術ではなく「合意の不足」であることがほとんどです。契約書は「何を・いつまでに・どの基準で・いくらで」を文章で固定する道具です。
請負か準委任か ― 契約の型で「完成責任」と「報酬」が変わる
システム開発の契約は、民法上「請負」か「準委任」か、または工程ごとの組み合わせになります。請負は「仕事の完成」を約束し、その結果に報酬を支払う契約です（民法632条）。準委任は法律行為でない事務の処理を委託する契約で（643条・656条）、善良な管理者の注意義務（644条）は負いますが、完成は約束しません。
| 項目 | 請負（民法632条以下） | 準委任（643条・656条以下） |
|---|---|---|
| ベンダの義務 | 仕事（システム）を完成させる | 善管注意義務をもって作業する（644条）。完成は約束しない |
| 報酬の支払時期 | 原則、目的物の引渡しと同時（633条） | 事務処理後、または期間ごと（648条2項）。成果完成型もある（648条の2） |
| 途中で終わった場合 | 可分な部分で注文者が利益を受けるときは、その割合で報酬請求できる（634条） | 履行した割合に応じて報酬請求できる（648条3項） |
| 不具合への責任 | 契約不適合責任（559条により562条以下を準用、636条・637条） | 善管注意義務違反としての債務不履行責任（415条） |
| 発注者側からの解除 | 完成前はいつでも損害を賠償して解除できる（641条） | いつでも解除できるが、相手に不利な時期の解除は損害賠償が必要（651条） |
落とし穴は、契約書の表題と中身のずれです。報酬は月額固定（準委任的）なのに納期と成果物が細かく定められている（請負的）契約は少なくなく、紛争になれば裁判所は表題ではなく内容と実態から型を判断します。要件定義は準委任、開発は請負と工程ごとに契約を分ける多段階契約は、独立行政法人情報処理推進機構（IPA）の「情報システム・モデル取引・契約書」でも採用されている考え方です。
仕様と検収 ― 「完成」の基準を契約書に書く
請負型の開発で最も争いになるのは「完成したかどうか」です。ベンダは「仕様どおりに作った」と言い、ユーザは「業務で使えない」と言う。この対立を防ぐ鍵は、契約書と仕様書で「何ができれば完成か」を客観的に書くことです。
仕様書を契約の一部にする
- 要件定義書・基本設計書を契約書の別紙として引用し、契約内容であることを明記する。提案書やデモ画面は別紙に取り込まない限り契約内容にならないことがあり、「現行システムと同等」などの抽象的な表現ではなく機能一覧・画面一覧・処理件数などで書きます。
- 仕様変更の手続（変更管理）を定め、納期と費用への反映を書面（メールでも可）で残す。追加費用紛争の多くは、口頭で頼んだ変更の積み重ねで起きます。
検収の手順と期間を定める
- 納品後にユーザがテストする期間（例えば10営業日〜1か月程度）と、合格基準（テスト仕様書の全項目合格、重大な不具合がないなど）を決める。期間内に不合格の通知をしなければ合格とみなす「みなし検収」条項はベンダ側のひな型にほぼ入っているため、自社の体力で現実的にテストできる長さにし、繁忙期を避けます。
「完成」の基準が書かれていない契約では、ユーザが「使えない」と主張しても、仕様どおりの納品と判断されれば報酬の支払義務を免れません。
契約不適合責任と損害賠償の上限 ― 民法562条以下・637条
納品されたシステムに不具合があった場合、請負契約では売買の規定が有償契約に準用され（559条）、注文者は次の権利を持ちます。
| 注文者の権利 | 条文 | 内容 |
|---|---|---|
| 追完請求 | 562条 | 修補（バグ修正）を請求できる。不適合が注文者の責めによる場合は請求できない |
| 報酬減額請求 | 563条 | 相当期間を定めて追完を催告し、期間内に追完がないときは不適合の程度に応じて減額を請求できる |
| 損害賠償・解除 | 564条（415条・541条・542条） | 追完・減額とは別に、債務不履行による損害賠償と契約解除ができる |
| 注文者の指図による不適合 | 636条 | 注文者が供した材料や指図が原因の不適合は、ベンダが不適当を知りながら告げなかった場合を除き、責任を追及できない |
| 権利行使の期間制限 | 637条 | 不適合を知った時から1年以内に通知しないと、追完・減額・損害賠償・解除のいずれもできなくなる（ベンダが引渡し時に知り、または重過失で知らなかった場合を除く） |
契約書で変えられる部分と注意点
これらの規定は契約で修正できます。ベンダ側のひな型では、責任期間を「検収後6か月」などに定め、損害賠償の上限を「委託料相当額」とし、逸失利益を除外するのが一般的です。
- 期間の起算点と長さ：637条は「知った時から1年」ですが、契約で「検収完了から〇か月」とされると、気づかなかった潜在的な不具合は期間経過で請求できなくなります。決算期や年次処理など自社の運用サイクルを一巡する長さが一つの目安です。
- 損害賠償の上限：民法上の賠償範囲は通常生ずべき損害と、予見すべきであった特別の事情による損害です（416条）。契約で上限額を定めることは可能で、ベンダにとっても事業継続のために必要な条項です。ユーザ側は、上限を委託料相当額にするとしても、ベンダの故意・重過失の場合は上限を適用しない例外を入れるのが実務上の標準です（IPAのモデル契約書第二版でも「重大な過失」の明確化が論点とされています）。
SaaS利用契約のチェックポイント ― 定型約款・SLA・データの扱い
SaaSの利用規約は民法の「定型約款」に当たることが一般的で、規約を契約内容とする旨を表示したうえで申し込めば、個別の条項を読んでいなくても合意したものとみなされます（548条の2第1項）。ただし、相手方の権利を制限し義務を加重する条項で、信義則に反して相手方の利益を一方的に害するものは合意しなかったものとみなされ（同条2項）、事業者が規約を一方的に変更するには効力発生時期を定めてインターネット等で周知する必要があります（548条の4）。「読んでいなくても拘束される」のが原則ですから、申込前に少なくとも次の項目を確認してください。
| 確認項目 | ユーザにとって不利な典型例 | 確認・交渉の方向 |
|---|---|---|
| サービスレベル（SLA） | 稼働率の保証なし／下回っても料金の一部返金のみ | 障害時の連絡体制、返金・クレジットの条件 |
| 損害賠償 | 一切責任を負わない／直近1か月分の利用料が上限 | 故意・重過失の例外、データ消失時の復旧協力。不足分はバックアップや保険で補う |
| データの帰属・利用 | 入力データを事業者がサービス改善やAI学習に自由に利用できる | 提供に必要な範囲に限定。個人データを預けるなら委託先として安全管理措置・サーバー所在国を確認 |
| 料金改定・規約変更 | サイト掲載のみで即時変更 | 事前通知と不同意時の解約権（548条の4の周知要件も確認） |
| 最低利用期間・自動更新 | 更新日60日前までの申出が必要、中途解約は残期間の料金全額 | 申出期限のカレンダー管理、企業向けプランでの個別交渉 |
| サービス終了・データ返還 | 解約と同時にデータ削除、エクスポート機能なし | 終了の予告期間、解約後〇日間の取り出し期間、汎用形式での出力 |
解約・サービス終了時のデータ返還と移行
見落とされやすいのが「出口」の条項です。開発委託では、ソースコードや設計書の著作権がベンダに残り、ユーザには利用許諾しか与えられない契約が多く、ベンダを変えて改修しようとしても改変が許されない事態が起きます。少なくとも自社業務に固有の部分（カスタマイズ部分・業務仕様書）については、著作権の譲渡または第三者による改変を含む利用許諾と、ソースコード・設計書の納品を契約書に明記しておくことを検討してください。
SaaSでは、解約やサービス終了の際に自社データをどの形式で、いつまで取り出せるかが問題になります。「解約と同時に削除」という規約だと、数年分の顧客データを失うおそれがあります。契約前にCSVなど汎用形式でのエクスポート機能と解約後の猶予期間を確認し、重要データは定期的に自社でバックアップを取る運用を決めておくことが現実的な備えです。保守契約がある場合は、終了時の引継ぎ義務と解約予告期間も確認します。
トラブルが起きたときの進め方
納期遅延や不具合が発生したときは、感情的な打ち切りや支払停止の前に、次の順序で進めます。
- 事実と記録の整理：契約書・仕様書・議事録・メール・チャット履歴を時系列に並べ、何が合意され何が未了かを確認します。自社の協力義務（データ提供・仕様確定・テスト）の履行状況も客観的に見ます。
- 書面での催告：請負契約で履行が遅れている場合、相当の期間を定めて催告し、期間内に履行がなければ解除できます（541条）。履行の見込みがないことが明らかなときは催告なしに解除できる場合もあります（542条）。催告は内容証明郵便など記録が残る方法で行います。
- 支払いの扱い：検収前の報酬は原則として支払義務が生じていませんが（633条）、中途解除時の出来高報酬（634条）などは契約内容で結論が変わります。一方的な支払停止はこちらの債務不履行とされるリスクがあるため、理由を書面で示して行います。
- SaaSの場合：規約の上限条項で請求額が限られることが多いため、まず規約上の救済（返金・クレジット）とデータの確保を優先します。
弁護士への相談は、催告書を送る前、または相手方から請求書・内容証明が届いた段階が目安です。なお、ベンダが中小事業者や個人事業者の場合、発注側である貴社に書面交付や支払期日などの義務が課されることがあります。詳しくは取適法・フリーランス法の解説記事をご参照ください。
よくある質問（FAQ）
納品されたシステムに不具合があります。いつまでベンダに修正を求められますか？
準委任契約なのに、ベンダは「完成しなかった責任」を負わないのですか？
SaaSの利用規約が一方的に変更されました。従わなければなりませんか？
開発したシステムのソースコードは当社のものになりますか？
SaaSを解約したら、入力していたデータはどうなりますか？
まとめ
- システム開発の契約は、請負（完成責任あり・民法632条）か準委任（善管注意義務・656条）かで、ベンダの責任と途中終了時の報酬が変わります。
- 仕様書の別紙化、変更管理の手続、検収期間と合格基準の3点を着手前に確定することが、「完成したかどうか」の争いを防ぐ最大の対策です。
- 不具合への権利は追完・減額・損害賠償・解除（562条以下）で、通知は知った時から1年以内（637条）。契約の賠償上限には故意・重過失の例外を確認します。
- SaaSの利用規約は定型約款として読んでいなくても拘束される（548条の2）。SLA・免責・データの帰属・自動更新・解約時のデータ返還を申込前に点検します。
システム開発やSaaSの契約書はベンダ側のひな型で進むことが多く、気づかないまま不利な条項を受け入れているケースが少なくありません。当事務所の顧問弁護士サービスでは、企業法務を専門とする弁護士チームに、契約書のチェックからトラブル対応まで、チャット・オンラインで日常的にご相談いただけます。発注・導入前の契約書確認も、すでに起きている納期遅延や不具合への対応も、お問い合わせ（無料相談）からお気軽にご連絡ください。
※ 本記事は一般的な情報提供を目的とするものであり、個別の事案に対する法的助言ではありません。法令・制度の内容は公開日時点のものです。具体的なご対応にあたっては、最新の法令をご確認のうえ、弁護士にご相談ください。