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