システム開発の契約書チェックリスト｜検収・契約不適合責任・支払条件で揉めないために
システム開発の契約書は、開発会社から雛形が提示され、発注側は金額と納期だけを確認して押印するという流れになりがちです。しかし、開発のトラブルが表面化するのは、納品の直前や納品後であることがほとんどです。そのときに頼りになるのは、契約書に書かれた条項だけです。
揉めやすいのは、検収をいつ・どう終えるか、納品後に見つかった不具合を誰の負担で直すか、代金をいつ払うかの三点です。この三点は、民法にも原則となるルールがありますが、多くの契約書はそれを別の内容に置き換えています。条文を読まずに署名すると、民法の原則より不利な条件を受け入れていることに気づかないまま開発が進みます。
契約書の確認は法務担当者の仕事と考えられがちですが、検収の方法や不具合の範囲は、開発の中身を知っている発注担当者でなければ判断できない部分です。法律の専門家に見てもらう場合も、業務上の前提は発注担当者が伝える必要があります。
この記事では、システム開発の契約書で発注側が確認すべき項目を、検収、契約不適合責任、支払条件を中心にチェックリストとして整理します。最終的な判断が必要な場合は弁護士に相談することを前提に、発注担当者が自分で確認できる範囲を扱います。
契約書のどこで揉めやすいか
システム開発の契約は、取引全体の共通ルールを定める基本契約と、工程や案件ごとの金額・納期・範囲を定める個別契約の二層で結ぶことがよくあります。独立行政法人情報処理推進機構（IPA）と経済産業省の「情報システム・モデル取引・契約書」も、この形を基本にしています。
二層構造の場合、検収や不具合対応のルールは基本契約に、具体的な検査期間や支払期日は個別契約に書かれていることが多く、片方だけ読んでも全体が分かりません。確認するときは、両方を並べて読むようにしてください。
揉めやすい点を、トラブルの起き方と合わせて整理すると次のようになります。
| 揉めやすい点 | よくある食い違い | 確認する条項 |
|---|---|---|
| 検収 | 発注側は検査中のつもりでも、期間が過ぎて合格扱いになっていた | 検査期間、みなし合格、不合格時の手続き |
| 不具合の責任 | 納品後に見つかった不具合の修正を、有償の保守として請求された | 契約不適合責任の範囲と期間 |
| 支払条件 | 検収前に請求が来た、または分割払いの条件が曖昧だった | 支払時期、支払方法、分割の条件 |
| 仕様変更 | 口頭で頼んだ変更に追加費用を請求された | 変更の手続き、追加費用の決め方 |
| 損害賠償 | システム障害の損害が、賠償上限で大きく制限されていた | 賠償の範囲と上限額 |
契約類型が請負か準委任かによって、検収や不具合責任の考え方そのものが変わります。請負は仕事の完成を約束する契約で、引き渡された成果物が契約内容に適合しないときは契約不適合責任が問題になります。準委任は事務の処理を約束する契約で、受注者は善管注意義務を負います。まず契約書の冒頭で類型を確認してから、各条項を読み進めてください。
参考：情報システム・モデル取引・契約書（第二版）／IPA（情報処理推進機構）
参考：民法／e-Gov法令検索
検収条項のチェックポイント
検収は、納品されたシステムが仕様どおりかを発注側が確認し、受け入れを確定させる手続きです。請負では検収完了が支払いや不具合責任の期間の起点になることが多いため、契約書の中でも重要な条項です。
IPAのモデル契約書では、発注者が個別契約で定めた検査期間内に検査仕様書に基づいて検査し、合格なら検査合格書を交付し、不合格なら具体的な理由を書面で示して修正を求める流れが定められています。そのうえで、検査期間内に書面で具体的な理由を示して異議を述べなければ、検査に合格したものとみなすという条文が置かれています。多くの開発会社の雛形にも、同じような「みなし合格」の条項があります。
みなし合格の条項自体は珍しいものではなく、開発会社が検収待ちで代金を受け取れない状態を防ぐための合理的なルールです。問題は、検査期間が発注側の体制に対して短すぎる場合です。次の点を確認してください。
- 検査期間は何日か。発注側の担当者が通常業務と並行して検査できる長さか
- 検査の基準になる文書（検査仕様書、テスト項目）が事前に決まっているか
- みなし合格の条項がある場合、異議の出し方（書面、メールなど）が明確か
- 不合格の場合の修正期限と、再検査の期間が定められているか
- 一部の機能だけ不合格の場合に、合格部分を先に検収できるか
検査期間の適切な長さは、システムの規模と発注側の検査体制によって変わります。現場の担当者が実際の業務データで確認する必要がある場合は、その担当者の予定を押さえたうえで期間を決めましょう。期間を延ばすのが難しければ、検査仕様書を開発の早い段階で合意しておき、納品前に開発会社側のテスト結果を確認しておくと、検査期間内に判断しやすくなります。
準委任の契約では、仕事の完成を検査する請負の検収とは性質が異なり、「業務が終了したことの確認」や「作業報告書の承認」が支払いの前提になることが多くあります。この場合も、報告書を受け取ってから何日以内に確認するのか、確認しなかった場合に承認したとみなすのかが書かれているかを確認してください。成果完成型の準委任であれば、成果物を受け取る手続きが請負の検収に近くなるため、受け入れの基準を事前に決めておく必要があります。
契約不適合責任のチェックポイント
契約不適合責任は、引き渡された成果物が種類や品質の点で契約の内容に適合しないときに、受注者が負う責任です。2020年4月施行の改正民法で、従来の「瑕疵担保責任」から考え方と名称が改められました。
民法の原則
請負で成果物が契約内容に適合しない場合、発注者は履行の追完（修補など）、報酬の減額、損害賠償、契約の解除を求められます。民法第637条により、発注者が不適合を知った時から1年以内にその旨を通知しなければ、原則としてこれらを求められなくなります。ただし、引渡しの時点で開発会社が不適合を知っていた、または重大な過失で知らなかった場合は、この期間制限は適用されません。
また、民法第636条により、発注者が提供した材料の性質や発注者の指図によって生じた不適合は、原則として責任を追及できません。開発会社がその指図が不適当だと知りながら告げなかった場合は例外です。
契約書で変えられていないかを確認する
民法の「知った時から1年」は、いつまでも責任を問える余地があるため、開発会社にとって負担が大きく、実務の契約書では期間を区切り直すことが一般的です。IPAのモデル契約書も、「検収完了後○か月／○年以内」に通知された場合に限る、という形で期間を空欄にした条文を用意しています。
- 責任を負う期間はどのくらいか。起算点は検収完了時か、不適合を知った時か
- 追完、減額、損害賠償、解除のうち、どれが認められているか
- 損害賠償が「受注者の責めに帰すべき事由」による場合に限定されているか
- 何が不適合にあたるかの基準（仕様書との不一致、バグを含むか）が書かれているか
- 保守契約の範囲と、契約不適合として無償で直す範囲が区別されているか
期間の長さに決まった正解はありません。業務の繁忙期にしか使わない機能や、月末・年度末にしか動かない処理がある場合は、その処理が一度は動く時期までを責任期間に含めておくと安心です。たとえば年次の集計処理があるなら、検収から最初の年次処理までの期間が入るかを確認しましょう。
納品後の不具合対応で特に揉めやすいのが、保守契約との境目です。保守契約を別に結ぶ場合、「契約不適合責任の期間中に見つかった仕様との不一致は無償で修正し、それ以外の改修や問い合わせ対応は保守契約で扱う」というように、どちらで扱うかを書き分けておくことが重要です。
参考：民法の一部を改正する法律（債権法改正）について／法務省
支払条件のチェックポイント
民法上、請負の報酬は仕事の目的物の引渡しと同時に払うのが原則です（第633条）。履行割合型の準委任では事務を履行した後に、期間で報酬を定めた場合はその期間が経過した後に請求できます（第648条）。実務では、これらを前提に、着手金や中間金を組み合わせた支払条件が定められることが多くあります。
| 支払方法 | 発注側の利点 | 発注側の注意点 |
|---|---|---|
| 検収後一括払い | 完成を確認してから払える | 開発期間が長いと開発会社の資金負担が大きく、見積額に反映される場合がある |
| 着手金と検収後の残金 | 開発会社の着手が早くなる | 途中で中止した場合の着手金の扱いを決めておく |
| 工程ごとの分割払い | 工程ごとに成果を確認して払える | 各工程の完了の基準と検収方法を決めておく |
| 月額払い（準委任） | 毎月の作業量に応じて払える | 作業報告の内容と精算方法を決めておく |
確認すべきは、請求できる時期の起点です。「納品後」なのか「検収完了後」なのかで、発注側が検査を終える前に支払いが確定するかどうかが変わります。また、検収後の支払期日が月末締め翌月末払いなのか、それ以外なのかも、社内の支払サイトと合わせて確認しておきましょう。
なお、2026年1月1日に施行された中小受託取引適正化法（取適法）では、対象となる取引について、受領した日から60日以内のできる限り短い期間で支払期日を定めることや、手形払いの禁止などが定められています。ただし、公正取引委員会のQ&Aでは、自社で使うソフトウェアの作成を外部に委託する場合、自社でその部分を作成する能力がなければ情報成果物作成委託にあたらないとされています。一般の事業会社が自社の業務システムを開発会社に発注する場合は、対象にならないことが多いと考えられます。対象になるかどうかは取引の内容と資本金・従業員数で決まるため、判断に迷う場合は公正取引委員会の資料で確認してください。
参考：製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律／e-Gov法令検索
そのほかに確認したい条項のチェックリスト
検収、契約不適合責任、支払条件のほかにも、トラブルの原因になりやすい条項があります。契約前に次の表で一通り確認しておくと、見落としを減らせます。
| 条項 | 確認すること |
|---|---|
| 仕様変更 | 変更の申し入れ方法、影響（費用・納期）の見積もり方、合意の形式（書面かメールか） |
| 損害賠償 | 賠償の範囲、上限額（「個別契約の委託料を上限とする」など）、故意・重過失の場合の扱い |
| 著作権 | 成果物の著作権が発注側に移るか、移る時期、開発会社が従前から持つ部品の扱い |
| 再委託 | 再委託に事前承諾が必要か、再委託先にも同じ義務を負わせるか |
| 秘密保持・個人情報 | 対象となる情報の範囲、契約終了後の返却・廃棄の方法 |
| 中途解約 | 解約の申し入れ期限、それまでの作業分の精算方法 |
| 第三者ソフトウェア・OSS | 利用するライブラリのライセンスの確認責任を誰が負うか |
| 発注者の協力義務 | 発注側が提供する資料や回答の期限、遅れた場合の扱い |
損害賠償の上限は、開発会社にとっては事業を続けるために必要な条項で、上限そのものをなくすのは現実的でない場合が多いです。発注側としては、上限額が想定される損害に対して低すぎないか、故意や重大な過失の場合まで上限が適用されていないかを確認するのが現実的な落としどころです。IPAのモデル契約書でも、故意・重大な過失の場合は上限を適用しない形の条文が用意されています。
発注者の協力義務も見落とされやすい条項です。システム開発では、発注側の回答や資料の提供が遅れると、それだけで納期が遅れます。契約書に発注側の役割が書かれているかを確認し、社内で対応する担当者と回答の期限を事前に決めておきましょう。
請負の契約書は印紙税法上の課税文書（第2号文書）にあたり、記載された契約金額に応じた印紙税がかかります。紙で取り交わすか電子契約にするかも、契約前に開発会社と決めておくとよいでしょう。
参考：請負に関する契約書（タックスアンサーNo.7102）／国税庁
まとめ
システム開発の契約書で揉めやすいのは、検収、契約不適合責任、支払条件の三点です。いずれも民法に原則がありますが、契約書でその内容が置き換えられていることが多いため、条文を読んで確認する必要があります。
検収では検査期間の長さとみなし合格の条件を、契約不適合責任では期間の起算点と保守契約との境目を、支払条件では請求の起点が納品なのか検収なのかを確認してください。仕様変更、損害賠償の上限、著作権、再委託、発注者の協力義務も、トラブルになる前に確認しておきたい条項です。
次に契約書を受け取ったら、この記事のチェック項目と照らし合わせ、自社の検査体制や業務のサイクルに合わない条項があれば、署名の前に開発会社に修正を相談しましょう。金額が大きい案件や、損害賠償の上限など判断が難しい条項がある場合は、弁護士に確認を依頼するのが確実です。