契約不適合責任とは｜納品後に不具合が見つかったときの対応

システムの納品後に不具合が見つかったとき、発注者が開発会社に修正などを求める根拠になるのが「契約不適合責任」です。2020年の民法改正で、それまでの「瑕疵担保責任」から変わりました。この記事では、システム開発の契約不適合責任について、改正で変わった点、発注者が請求できる4つの手段、通知の期限、契約書で期間や対応方法を定める方法を整理します。

契約不適合責任とは何か

契約不適合責任は、引き渡された物が「種類・品質・数量に関して契約の内容に適合しない」ときに、売主や請負人が負う責任です（民法第562条ほか）。システム開発の請負契約では、売買の規定が準用され（同法第559条）、納品されたシステムが契約で約束した仕様どおりに動かない場合に問題になります。

ポイントは、基準が「契約の内容」であることです。何が契約不適合かは、要件定義書や仕様書、合意した議事録などから判断されます。仕様書に書かれていない期待は、不適合と認められにくくなります。

なお、準委任契約では、請負のような契約不適合責任は負いません。業務の進め方に善管注意義務違反があった場合に、通常の債務不履行責任を問うことになります。どちらの契約かで、不具合への対応の根拠が変わる点に注意してください。

2020年の民法改正で瑕疵担保責任から変わった点

2020年4月1日施行の改正民法で、請負人の担保責任は売買のルールにそろえる形で見直されました。法務省の説明資料（主な改正事項）をもとに、主な変更点をまとめます。

「瑕疵」という言葉は、判例上も「契約の内容に適合していないこと」の意味で理解されていたため、その考え方が条文で明確になりました。発注者にとって大きいのは、報酬の減額を請求できるようになった点と、期間の数え方が変わった点です。

発注者が請求できる4つの手段

納品物に契約不適合があった場合、発注者は次の4つを請求できます。

減額請求は、原則として先に「相当の期間を定めて修正を求める」ことが必要です。修正が不可能な場合や、開発会社が修正をはっきり拒んだ場合は、すぐに減額を求められます。

一方、発注者が提供した資料や発注者の指示が原因で生じた不適合については、原則として責任を問えません（同法第636条）。ただし、開発会社がその指示が不適当だと知りながら告げなかった場合は別です。

「知ってから1年以内に通知」という期間制限

請負の場合、発注者が不適合を知った時から1年以内に開発会社へ通知しないと、上の4つの請求ができなくなります（同法第637条第1項）。

ここで求められるのは「通知」で、1年以内に裁判を起こすことまでは求められていません。ただし、どの機能のどんな不具合かを具体的に伝えておくことが大切です。メールなど記録の残る方法で通知しましょう。

引渡しの時点で開発会社が不適合を知っていた、または重大な過失で知らなかった場合は、この1年の制限は適用されません（同条第2項）。また、別に一般の消滅時効（権利を使えることを知った時から5年、使える時から10年。同法第166条）もかかります。

契約書で期間や追完期限を定める方法

民法のルールは、契約で変えることができます。実務では、民法のままではなく、契約書で期間や手続きを定めることが一般的です。

IPA（情報処理推進機構）の情報システム・モデル取引・契約書（第二版）の契約不適合責任の条項は、次のような形を示しています。

• 起算点を「検収完了時」にし、「検収完了後◯か月／◯年以内」に通知された場合に限り責任を負う
• それに加えて「不適合を知った時から◯か月以内」という条件を重ねることもできる
• 修正に過分な費用がかかり、契約の目的は達成できる場合は、無償の修正義務を負わない
• 開発会社が不適合を知っていた場合や、故意・重過失の場合は期間制限を適用しない

起算点を検収完了時にするのは、発注者に検収でしっかり確認してもらうためです。発注者は、期間が短すぎないか、受入テストで十分に確認できる計画になっているかを見ておきましょう（受入テストの進め方も参考になります）。

あわせて、次の点も契約書や仕様書で決めておくと揉めにくくなります。

• 修正の着手期限と完了期限（重大度別に決めることもある）
• 外部サービスやOSの仕様変更による不具合を対象に含めるか
• 対象期間が終わった後の不具合を、保守契約でどう扱うか

納品後に不具合が見つかったときの進め方

実際に不具合が見つかったら、次の順に進めると話がこじれにくくなります。

1. 再現手順、発生日時、画面のスクリーンショットなど、事実を記録する
2. 仕様書や要件定義書で、本来どう動くべきだったかを確認する
3. 契約書で、対応期間・対象範囲・通知方法を確認する
4. 記録の残る方法で開発会社に通知し、修正の方法と期限を相談する
5. 修正後に再テストし、直ったことを確認して記録する

「仕様どおりだが使いにくい」という不満は、契約不適合ではなく改善要望として扱われることが多く、追加費用の対象になりえます。不具合か要望かで意見が分かれたときは、仕様書の記載に立ち返って話し合うことが基本です。

受託開発の現場から

ある受託開発会社の考え方と、同社の提案書での定め方です。

• 設計どおりに作っても、納品後に新たな不具合は出る。 既存アプリでOSのアップデートにより「戻る」操作が効かなくなる不具合が見つかった例があり、こうした不具合の回収も含めて動きやすい契約形態を考えるべき、という考え方です。
• 対応期間を提案書に明記する。 同社の提案書では、「納品後12か月の契約適合性に反する不具合への対応」を明記しています。
• 対象外も先に書く。 開発会社の制作範囲に起因する不具合は契約の範囲で対応し、クラウドや外部の基盤サービスの標準機能の不具合、仕様変更、障害は対象外と書き分けています。
• AIの精度は「実測値」で受入基準を決める。 音声認識などAIの精度は環境に左右されるため100%を保証せず、検証（PoC）の実測値をもとに受入基準を合意する形をとっています。

まとめ

• 契約不適合責任は、納品物が「契約の内容」に合わないときに開発会社が負う責任
• 2020年の改正で、報酬の減額請求が加わり、期間は「知ってから1年以内に通知」になった
• 発注者は追完、減額、損害賠償、解除の4つを請求できる
• 実務では契約書で起算点や期間、対象外の範囲を定めることが多いので、署名前に確認する

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

納品後の対応範囲まで含めて開発会社を比べたいときは、FastProposal の無料AI相談で案件を整理し、費用の目安を確認するところから始められます。