見積書や契約書案に「契約不適合責任」「瑕疵対応」「保証期間」といった言葉が並んでいて、意味も、金額や条件への影響も判断できずに手が止まっている。受託開発の発注を検討している担当者の方から、こうした相談はよく聞かれます。
結論から言うと、契約不適合責任とは、納品されたシステムが契約の内容（仕様・品質・性能）に合っていない場合に、受注者（開発会社）が負う責任のことです。2020年4月の民法改正で、旧「瑕疵担保責任」はこの制度に置き換わりました。発注者は、不具合の修正（追完）、代金の減額、損害賠償、契約解除を求められます。
ただし、この責任で何が守られるかは、契約書・仕様書に何を書くかで大きく変わります。この記事では、契約不適合責任の意味と瑕疵担保責任との違い、発注前に見積・契約で確認すべき点、不具合が起きた後の初動までを、発注者の立場で順に解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
契約不適合責任とは？システム開発での意味を一言で
「契約の内容に適合しない」とは
契約不適合とは、引き渡された成果物が、契約で合意した種類・品質・数量に合っていない状態を指します。システム開発では、次のようなケースが典型です。
- 要件定義書・仕様書に書かれた機能が実装されていない、または仕様どおりに動かないケース
- 処理速度・同時接続数など、合意したパフォーマンス要件を満たさないケース
- 暗号化・アクセス制御など、合意したセキュリティ要件が実装されていないケース
- 画面操作でエラーが起きる、データが期待どおりに保存・表示されないケース
共通するのは、契約や仕様書で合意した内容とずれている点です。契約の趣旨に照らして通常期待される品質を欠く場合は別ですが、仕様書に書かれていない機能の不足や、発注者が後から追加した要件は、原則として契約不適合にはなりません。
ソフトウェア開発で責任を問える契約は請負
契約不適合責任が問題になるのは、主に「完成した成果物の納品」を約束する請負契約（受託開発の多くがこの形です）です。請負契約では、売買の規定が準用され、契約不適合責任が適用されます。一方、「業務の遂行」を約束する準委任契約（SES契約など）では、成果物の完成責任はなく、契約不適合責任は原則として問えません。この違いは、後述の「発注前に確認する5つのポイント」でも重要になります。
「瑕疵（かし）」との関係
「瑕疵」は、契約で定めた品質・性能・機能を満たさない欠陥を意味する旧来の言葉です。現在の民法に「瑕疵担保責任」という条文はありませんが、契約書や業界の慣習ではいまも「瑕疵対応」「瑕疵担保」という言い方が残っています。見積書や契約書でこれらの語を見かけたら、実質的には契約不適合責任（および契約で決めた無償の修補対応）を指していると読み替えて確認してください。
瑕疵担保責任と契約不適合責任の違い（2020年民法改正）
2017年に成立し、2020年4月1日に施行された民法改正（約120年ぶりの大改正）で、瑕疵担保責任は廃止され、契約不適合責任に置き換わりました。ソフトウェア開発に適用される主な違いは次のとおりです。
| 項目 | 瑕疵担保責任（旧法） | 契約不適合責任（新法） |
|---|---|---|
| 責任の発生要件 | 「隠れた瑕疵」が必要（発注者が知らなかった欠陥） | 「契約の内容に適合しない」ことで発生（隠れているかどうかは問わない） |
| 発注者が使える権利 | 損害賠償請求・契約解除が中心 | 追完請求・代金減額請求・損害賠償請求・契約解除の4種類 |
| 権利行使の期間 | 仕事の目的物の引渡しから1年以内（旧法の請負） | 不適合を知った時から1年以内に受注者へ通知（その後は一般の消滅時効） |
| 損害賠償の要件 | 受注者の過失は不要（無過失責任） | 受注者の帰責事由（故意・過失など）が必要 |
発注者にとっての最大の変化は、「隠れた瑕疵」でなくても責任を問えるようになったことと、追完請求・代金減額請求が明文化されたことです。一方で、損害賠償には受注者の帰責事由が必要になり、「どの範囲までが契約の内容か」を示す書面の重要性が増しています。
発注者が使える4つの権利
① 追完請求（修補）
不具合を直してもらう権利です。修補のほか、代替物の引渡しや不足分の引渡しを求められます。発注者に不相当な負担を与えない限り、受注者は発注者が選んだ方法と異なる方法で追完することも可能です。
② 代金減額請求
追完を求めても相当な期間内に対応されない場合や、追完が不可能な場合に、不適合の程度に応じて代金の減額を求められます。原則は「追完請求 → 相当期間内に対応なし → 代金減額請求」という順序です（追完不能などの場合は即時の減額請求も可能）。
③ 損害賠償請求
不具合によって実際に損害が生じた場合（業務停止による損失、データ復旧費用、代替手段の利用費用など）に、その賠償を求められます。新法では受注者の帰責事由（故意・過失など）が必要で、損害額の証明も求められます。
④ 契約解除
追完や代金減額では解決できない重大な不適合の場合に、契約の解除と代金の返還を求められます。不適合が軽微な場合は解除できません。システム開発では、すでに稼働している部分や支払い済みの費用の扱いも絡むため、実行前に弁護士へ相談することをおすすめします。
契約不適合責任を問える場合・問えない場合
問える可能性が高いケース
仕様書・要件定義書に書かれた機能が実装されていない場合 たとえば「月次レポートのPDF出力」が仕様書に明記されているのに、納品物にその機能がない場合は、明確な契約不適合です。
合意したパフォーマンス要件を満たさない場合 「同時1,000ユーザーが利用できる処理能力」と定めていたのに、100ユーザーでシステムが落ちる場合は、品質面の契約不適合に当たります。
重大なバグが繰り返し発生し、業務に支障が出る場合 軽微なバグは運用でカバーできることもありますが、基幹業務が止まるほどの不具合が繰り返される場合は、責任を問える可能性が高くなります。
問えない（問いにくい）ケース
仕様書に記載されていなかった機能の不足 「ついていると思っていた機能」や、口頭で伝えただけで文書化されていない機能は、契約上の根拠がなく、不適合の主張は難しくなります。
検収後に発注者が追加・変更した要件 検収後の「やはりここを変えたい」は、通常は別途の変更契約（追加費用）になります。
発注者の指示や提供した材料が原因の不具合 発注者が与えた指図や材料が原因で生じた不適合は、受注者がその不適切さを知りながら告げなかった場合を除き、責任を問えません。
準委任契約（SES契約など）での成果物の品質 準委任は「仕事の完成」ではなく「一定の業務の遂行」が目的です。受注者は善管注意義務（専門家として期待される注意を払う義務）を負いますが、成果物に対する契約不適合責任は原則として発生しません。請負と準委任の違いは「システム開発の請負契約と準委任契約の違いと選び方」も参考にしてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
発注前に確認する5つのポイント：見積・契約・保守の判断に使う
契約不適合責任は、法律に書かれているだけでは発注者を守りきれません。条件の多くは契約で調整でき、見積書・契約書・保守契約の書き方で、実際に受けられる対応が決まります。発注前に、次の5点を確認してください。
1. 保証期間（いつまで無償で直してもらえるか）
民法上は「不適合を知った時から1年以内の通知」が基本ですが、契約で保証期間を短縮・延長できます。一般的には、納品後3〜12か月程度の無償修補期間が設定されることが多いです。見積書に保証期間の記載がない場合は、必ず確認してください。なお、受注者が不適合を知りながら告げなかった場合は、責任を免除・制限する特約があっても受注者は免れられません。
2. 保証範囲（何が対象で、何が対象外か）
「仕様書に明記された機能の不具合を対象とする」「発注者が指示した変更や、発注者側の環境起因の不具合は対象外」など、範囲が文書で定義されているかを確認します。範囲が曖昧だと、不具合が出たときに「仕様の範囲内か」という争いになります。
3. 検収の基準と期間
検収は、納品物が契約に適合しているかを発注者が確認する手続きです。「検収期間は納品後○営業日」「仕様書の機能要件を満たすことを合格基準とする」と決めておきます。検収書に署名する前に確認を尽くすことが大切で、検収後に見つけた不具合の対応範囲も契約に書いておくと安心です。
4. 請負か準委任か、またその切り分け
請負なら契約不適合責任の対象になり、準委任なら対象外になるのが原則です。要件定義・設計は準委任、開発・テストは請負といった混在契約では、どのフェーズにどちらの契約が適用されるかが契約書で明確になっているかを確認します。
5. 損害賠償の上限
受注者の保護のため「損害賠償は契約金額を上限とする」といった条項が入ることが一般的です。想定される業務停止の損失などと比べて、上限が妥当かどうかを確認しましょう。
「瑕疵対応」と保守契約は何が違う？無償対応との線引き
「瑕疵対応」と「保守」は、どちらも納品後にシステムを直す話ですが、目的も費用の考え方も別です。
| 項目 | 瑕疵対応（契約不適合責任・保証期間） | 保守契約 |
|---|---|---|
| 対象 | 納品物が契約の内容と合っていないこと（不具合・仕様との不一致） | 稼働後の運用支援、軽微な改善、環境変化への対応、問い合わせ対応など |
| 費用の考え方 | 原則として受注者負担（保証期間・範囲は契約による） | 月額・工数ベースの有償が一般的 |
| 期間 | 保証期間内（民法上は不適合を知った時から1年以内の通知） | 契約期間（更新型が多い） |
| 根拠 | 民法・請負契約の条項 | 保守契約・SLA（対応時間・範囲の取り決め） |
見積段階では、「保証期間が終わったらどうなるのか」「保証期間内でも対象外になる修正は何か」を、保守契約への切り替え条件とあわせて確認します。保証期間内の修正がすべて無償とは限らないため、不具合なのか、新しい要望なのかを切り分けるルールを決めておくと、後の費用トラブルを避けやすくなります。
リリース後のバグ修正費用を誰が負担するのか、有償になるのはどんなケースか、といった費用負担の判断軸は、「システム開発のバグ修正費用は誰が負担？無償の範囲と交渉軸」で詳しく整理しています。本記事は「責任の法的な意味と発注者の権利・初動」、そちらは「修正費用の負担の考え方」と役割を分けているので、あわせて確認してください。
不具合が発生したとき、発注者が取るべき行動5ステップ
ここからは、納品後に不具合が見つかった場合の初動です。「記録 → 通知 → 修補要求 → 交渉 → 法的手続き」の順に進めます。
ステップ1: 不具合の記録・証拠保全
最初に、不具合の事実を記録します。後の交渉や法的手続きで証拠になります。
記録すべき内容:
- 不具合の発生日時
- 症状・エラーメッセージの内容
- 再現手順（「○○の画面で△△を入力して××ボタンを押すと…」という形式）
- スクリーンショット・エラーログのキャプチャ
- 誰が・いつ・どのように発見したか
- 業務への影響（何が使えなくなったか）
注意点: 感情的な表現を避け、「○○という状態が△△という問題を引き起こしている」という事実ベースで記録します。開発会社と共有することを前提に、客観的な内容にしてください。
ステップ2: 開発会社への通知（期間に注意）
記録ができたら、速やかに開発会社へ通知します。
重要な期間制限: 請負契約では、不適合を知った時から1年以内に通知しなければ、追完請求・代金減額請求・損害賠償請求・契約解除の権利を行使できなくなります（請負は民法637条。売買は同566条）。「そのうち連絡しよう」と後回しにすると、権利を失うリスクがあります。
通知の方法: 口頭ではなく、メールなど記録が残る方法で通知してください。口頭の報告は「言った・言わない」の争いになりやすく、通知した事実を証明できません。
通知に含めるべき情報:
- 不具合の概要（ステップ1で記録した内容）
- 発見日時
- 業務への影響
- 対応を求めている旨
NG例: 電話での「バグがあるので見てください」という一言。記録が残らず、内容も曖昧で、後から「そんな報告は受けていない」と言われるリスクがあります。
ステップ3: 修補要求と対応期限の設定
通知後、正式に修補（追完）を求めます。
修補依頼書に含めるべき内容:
- 不具合の詳細な説明と再現手順
- 求める対応内容（「○○機能を仕様書どおりに動作するよう修正すること」）
- 対応期限（1〜4週間が一般的。緊急度に応じて調整）
- 確認完了の基準（「○○の操作を行い、△△の結果になれば完了とみなす」）
対応期限は「相当な期間」にしてください: 「24時間以内に対応せよ」のように極端に短い期限は、受注者から「不相当な期限」と主張される場合があります。不具合の複雑さに応じた合理的な期間を設けましょう。
受注者から対応の見通しをもらう: 期限内に「○○日に修補対応を行う」という回答をメールなど書面でもらうと、交渉の記録が積み上がります。
ステップ4: 交渉の進め方（修補拒否・無回答の場合）
修補要求に対応してもらえない、または拒否された場合の対処です。
まず代金減額の交渉を提案する: 全面的な修補が難しい場合は、不適合の程度に応じた代金減額を提案するのが現実的な解決策になることがあります。「○○の機能が使えない分、代金の○%を減額してほしい」という形で交渉します。
内容証明郵便で正式に通知する: 交渉が進まない場合は、内容証明郵便で改めて修補または代金減額を求めます。送達の事実が記録されるため、その後の法的手続きでも有効な証拠になります。
損害賠償の請求を検討する: 不具合で実際の損害（業務停止、再開発費用など）が出ている場合は、損害賠償の請求も検討します。損害額の証明が必要なため、金額の記録を残しておきましょう。
弁護士に相談するタイミング:
- 修補要求を無視され続けている場合です
- 受注者が「仕様どおりの納品だ」と主張して交渉が平行線になっている場合です
- 損害額が大きく、訴訟も視野に入れる必要がある場合です
上記のいずれかに当てはまる場合は、IT分野に詳しい弁護士への相談を検討してください。
ステップ5: 法的手続きへのエスカレーション判断
交渉がまとまらない場合は、法的手続きへの移行を検討します。
少額訴訟（請求額60万円以下の場合）: 弁護士なしでも比較的手続きしやすく、1回の期日で審理を終えることが多いため、コストを抑えられます。
通常訴訟（60万円超の場合）: 弁護士費用も含めたコスト計算が必要です。
裁判外紛争解決（ADR）の活用: 訴訟より迅速・低コストに解決できる場合があります。IT専門の知識を持つ中立的な第三者が関与するため、技術的な争点がある場合に特に有効です。
開発会社は不具合報告をどう受け取るか？〜受注者側の視点から
受注者側の対応の流れを知っておくと、交渉を進めやすくなります。
受注者の内部対応プロセス
1. 不具合トリアージ（優先度判断） 報告された不具合について、「本当に仕様書の要件に違反しているか」「検収時に承認された既知の問題ではないか」「他の機能に影響があるか」を確認します。
2. 原因調査と責任範囲の確認 仕様書・要件定義書・検収書と照合し、「自社の実装ミスか」「発注者側の仕様変更によるものか」「第三者のAPIや外部連携に起因するものか」を判断します。仕様書の記載が曖昧だと、責任の所在が争いになります。
3. 修補工数の見積もりと報告 責任範囲内の修補については、修正工数と対応予定日を発注者に報告します。責任範囲外と判断した場合は、その理由を説明します。
「良い開発会社」を見分けるポイント
保証期間・保証範囲を明示しているか 「納品後3か月間は無償で修補対応する」「保証範囲は仕様書に基づく機能の不具合に限る」のように、保証の条件を事前に文書化している開発会社は誠実です。口頭の「任せてください」だけで進める会社は要注意です。
不具合報告の窓口・対応の目安が決まっているか 「不具合報告はメールで○○宛て、通常○営業日以内に返答します」といった対応フローがある会社は、受注体制が整っています。担当者個人への電話だけが窓口の会社は、記録が残りにくく、担当者が変わると対応が滞るリスクがあります。
検収フローが明確か 「どのような基準で検収するか」「検収書に署名する前に何を確認すべきか」を一緒に決めようとする開発会社は、トラブルを防ぐ意識が高いと言えます。
契約書でリスクを減らすためのチェックリスト
契約を結ぶ前に、次の項目を契約書・仕様書で確認してください。
保証関連の条項
- 保証期間が明記されているか: 契約特約で短縮・延長できます。一般的に3〜12か月の保証期間が設定されることが多いです
- 保証範囲が具体的に定義されているか: 「仕様書に明記された機能の不具合」「発注者起因の変更は対象外」などの定義を確認
- 損害賠償の上限が設定されているか: 「契約金額を上限とする」条項が入ることが一般的です。想定リスクと比べて適切かを確認
- 準委任と請負の区分が明記されているか: フェーズごとにどちらが適用されるかが明確か
検収フロー
- 検収期間が定められているか: 納品後○営業日以内に検収を完了する、というルールがあるか
- 検収基準が明確か: 「仕様書の機能要件を満たしていること」など、合否の判断基準が記載されているか
- 検収後の追加不具合対応の扱いが決まっているか: 検収後に見つかった不具合の対応範囲が契約で定まっているか
仕様変更のルール
- 仕様変更の手続きが定められているか: 「仕様変更は書面で双方が合意すること」というルールがあるか。口頭での変更指示が増えると、後で「言った・言わない」の争いになりやすいです
まとめ
この記事では、契約不適合責任とは何か、システム開発での意味、瑕疵担保責任との違い、発注前の確認点、不具合発生後の初動を解説しました。
- 契約不適合責任とは、納品物が契約の内容に合っていない場合に受注者が負う責任で、2020年4月施行の民法改正で瑕疵担保責任に置き換わりました
- 発注者は追完請求・代金減額請求・損害賠償請求・契約解除の4つを使えます
- 請負契約では不適合を知った時から1年以内の通知が必要で、準委任契約では原則として責任を問えません
- 見積・契約では、保証期間・保証範囲・検収基準・請負か準委任か・損害賠償の上限を確認します
- 「瑕疵対応」と保守契約は別物。保証期間の終了後や対象外の修正は、保守契約や追加費用の話になります
- 不具合発生時は「記録 → 通知 → 修補要求 → 交渉 → 法的手続き」の順で動きます
最も重要なのは、トラブルが起きてから動くのではなく、発注前に契約書・仕様書を整えることです。「何が納品されるか」「不具合が出たときの対応ルール」を事前に文書化しておくことが、発注者にとって最大の予防策です。
システム開発の発注をこれから検討している方へ: 発注前から公開後まで、失敗しないためのチェックリストを無料でご提供しています。「システム開発 完全チェックリスト」はこちらからダウンロードいただけます。
関連記事
- システム開発のバグ修正費用は誰が負担？無償の範囲と交渉軸
- システム開発の請負契約と準委任契約の違いと選び方｜発注者のためのリスク判断ガイド
- ソフトウェアの受託開発とは？メリット・デメリットや費用相場を紹介
- システム開発の仕様変更と追加費用のトラブル防止策
- システム開発の著作権は誰のもの？発注者が知っておくべき基礎知識
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 2020年の民法改正前に結んだ契約の不具合にも、契約不適合責任は適用されますか？
2020年4月1日以降に締結した契約には新法（契約不適合責任）が適用され、それ以前の契約には旧法（瑕疵担保責任）が適用されます。契約締結日を確認し、どちらの制度が適用されるかを把握した上で権利行使の方法を選んでください。
- 不適合を「知った日」はいつになりますか？納品日ですか、不具合を発見した日ですか？
「不適合を知った日」とは実際に不具合を認識した日を指し、納品日ではありません。ただし、検収時に確認できたはずの不具合は「知り得た日」と判断されるリスクがあるため、発見した時点で速やかに記録・通知することが重要です。
- 要件定義フェーズが準委任、開発フェーズが請負の混在契約で不具合が出た場合、責任はどう判断しますか？
不具合が「仕様書に定めた機能の不達」であれば請負フェーズの契約不適合責任を問える可能性があります。一方、要件定義段階の成果物（要件定義書の記載内容）に起因する問題であれば準委任の善管注意義務違反として扱われ、責任の立証が難しくなります。フェーズと不具合の発生源を照合して判断してください。
- 仕様書が曖昧で、不具合かどうか争いになりそうです。どうすればよいですか？
仕様書の記載が争点になった場合は、契約締結前後のメール・議事録・口頭合意の記録を集め、双方の意思解釈を補強する証拠として活用してください。仕様が不明確なまま交渉が進まない場合は、IT分野に詳しい弁護士への相談を早めに検討することをおすすめします。
- 追完請求をしたのに開発会社が対応してくれません。次に取るべき手順は何ですか？
相当な期間を設けて追完請求をしても対応がない場合は、代金減額請求または損害賠償請求に移行できます。まず内容証明郵便で正式な催告を行い、それでも解決しない場合はITに詳しい弁護士への相談か、裁判外紛争解決手続き（ADR）の活用を検討してください。IT分野に特化した民間ADR機関（IT-ADRセンター等）を利用すると、技術的な争点がある案件でも専門知識を持つ中立的な第三者による迅速な解決が期待できます。
