システム開発の契約不適合責任｜納品後の不具合と対応範囲

システムを納品してしばらく経ってから不具合が見つかったとき、誰がどこまで直すのかは、契約で何を決めていたかによって変わります。この記事では、システム開発の契約不適合責任の基本的な考え方と、発注側が使える手段、通知の期限を整理します。あわせて、契約前に確認しておきたい対応範囲の項目も紹介します。

なお、ここで扱うのは民法の一般的な考え方です。実際の契約では書かれた条項が優先される場面が多いため、個別の契約書の判断は弁護士などの専門家に確認してください。

契約不適合責任とは何か

「瑕疵担保責任」から名前と考え方が変わった

契約不適合責任とは、納品された成果物が、契約で決めた内容（種類・品質・数量）に合っていないときに、作った側（請負人）が負う責任のことです。2020年4月に施行された改正民法で、それまでの「瑕疵担保責任」に代わって整理されました。

旧来の瑕疵担保責任は「隠れた瑕疵（発注者が気づけなかった欠陥）」を前提にしていました。現在は「契約の内容に合っているか」が基準になります。考える軸が「欠陥があるか」から「約束どおりか」に移ったと捉えると分かりやすいです。

何が「不適合」と判断されるのか

システム開発では、次のようなものが不適合として問題になりえます。

• 仕様書や要件定義書に書いてある機能が動かない、または抜けている
• 合意した性能（表示速度、同時に使える人数など）を満たしていない
• 計算や集計の結果が、合意したルールと食い違っている
• 通常求められる水準のセキュリティが欠けていて、契約上の前提を満たさない

ここで大切なのは、「何を約束したか」が文書に残っているかどうかです。要件が口頭のやり取りだけで決まっていると、そもそも不適合かどうかを客観的に示しにくくなります。仕様の決め方については、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方も参考になります。

また、「使いにくい」「イメージと違った」という感想は、契約に書かれた内容と合っていれば、不適合にはなりません。この違いが、納品後のもめごとの出発点になりやすい点です。認識のズレを前もって減らす方法は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで触れています。

不具合が見つかったとき、発注側が求められる4つのこと

民法上、成果物が契約に合っていないとき、発注側には主に次の4つの手段があります。

1. 追完請求（直してもらう）

修補（不具合の修正）や、代替物の引き渡し、足りない部分の補充を求める手段です。システム開発では、ほとんどの場合これが最初の選択肢になります。発注側が方法を選べるとされていますが、請負人は、発注側に不相当な負担を課さないときは別の方法で追完することもできます。

2. 代金減額請求

追完を求めても相当の期間内に応じてもらえないときなどに、不適合の程度に応じて代金の減額を求める手段です。原則として、まず追完を催告する流れになります。

3. 損害賠償請求

不適合によって生じた損害の賠償を求める手段です。ただし、請負人の責めに帰すべき事由（帰責事由）が必要です。また、賠償の範囲や上限は契約書で定められていることが多く、上限条項が置かれていればその影響を受けます。

4. 契約の解除

不適合が重大で、契約の目的を達成できない場合などに解除を求める手段です。通常は、相当の期間を定めて追完を催告したうえで進めます。不適合が軽微なときは、解除は認められません。

実務では、いきなり解除や賠償の話になることは少なく、不具合の報告、原因の切り分け、修正という順で進むのが一般的です。この順序をあらかじめ契約に書いておくと、いざというときに迷いません。

通知の期限と、検収との関係

「知った時から1年以内」に伝える

請負契約では、不適合を知った時から1年以内に、その旨を請負人に通知しないと、原則として追完請求などができなくなります（民法637条）。この期限は、不適合を「見つけた」時点から数えるのがポイントです。

ただし、請負人が引き渡しの時点で不適合を知っていた、または重大な過失で知らなかったときは、この期間制限は適用されません。

これとは別に、権利そのものの消滅時効もあります。一般には、権利を行使できると知った時から5年、行使できる時から10年とされます。「通知の期限」と「時効」は別の話なので、混同しないようにしたいところです。

検収に合格したら終わりではない

検収は、納品物が契約どおりかを発注側が確認し、受け入れる手続きです。検収を終えたからといって、契約不適合責任の追及ができなくなるわけではありません。検収時には分からなかった不具合が後から見つかることもあるからです。

ただし、検収の時点で確認できたはずの項目を見逃していた場合は、「検収で合格としたはず」という反論を受けやすくなります。検収で何を確認し、何を確認していないのかを残しておくことは、発注側にとっても請負側にとっても重要です。確認項目の考え方は、システム開発の検収とは｜納品時の確認項目と進め方で整理しています。

発注側の指示が原因だった場合

不適合の原因が、発注側が与えた材料の性質や、発注側の指示にあるときは、請負人は原則として責任を負いません（民法636条）。ただし、請負人がその指示の不適切さを知りながら告げなかったときは別です。

たとえば、発注側が「この方式で作ってほしい」と指定した結果、問題が起きたケースです。このとき、請負側がリスクを事前に伝えていたかどうかが争点になります。作り方を指定するときは、懸念点を相談し、やり取りを記録に残しておくと安心です。

契約の種類で、考え方が変わる

請負契約と準委任契約

ここまで述べた契約不適合責任は、成果物の完成を約束する請負契約で主に問題になる考え方です。システム開発では、請負のほかに準委任契約もよく使われます。

• 請負契約：成果物を完成させて引き渡すことが約束。完成した成果物が契約に合っているかが問われる
• 準委任契約：作業を行うこと（業務の遂行）が約束。成果物の完成そのものは約束に含まれないのが基本

準委任では、成果物に不具合があっても、直ちに契約不適合責任を追及できるとは限りません。代わりに、受託側が専門家としての注意義務（善管注意義務）を尽くしていたかどうかが問われます。ただし、契約の名前が準委任でも、成果物の納品を前提にしたものは、条項の内容を見て個別に判断されます。

契約形態ごとの違いは、受託開発とは？メリット・デメリットと依頼の流れ・契約の違いでも説明しています。依頼前に、今回の契約が請負なのか準委任なのか、あるいはフェーズごとに分けるのかを確認しておくことが、納品後の議論の出発点になります。

民法の規定は、契約で変えられる

契約不適合責任に関する民法の規定は、多くが当事者の合意で変更できる性質のものです。実際の契約書では、次のような形で民法と違う定めが置かれることがあります。

• 責任を負う期間を、検収後の一定期間に限る
• 対応方法を「修補のみ」とし、減額や賠償は制限する
• 損害賠償の上限を決める

経済産業省が公表している「情報システム・モデル取引・契約書」のようなひな型でも、契約不適合責任の期間や対応内容を契約で定める考え方が示されています。契約書に「民法のとおり」と書いてあるのか、独自に決めているのかは、読み飛ばさずに確認したい点です。

契約前に確認したい対応範囲

契約不適合責任は、事故が起きてから調べるものではなく、契約前に条件を確かめておく項目です。見積もりの金額より先に、次の点を確認しておくと、納品後の食い違いを減らせます。見積もりの前提の見方は、システム開発の見積もりの違い｜金額より先に見る前提と範囲も参考になります。

責任の期間と起点

• 不具合に対応する期間は、いつからいつまでか
• 起点は「納品日」か「検収完了日」か
• 期間を過ぎた後は、どのような扱いになるか

「不具合」の定義と対象

• 仕様書に書かれた機能を満たさないものだけが対象か
• 利用環境（ブラウザ、OS、端末）の範囲はどこまでか
• 性能やセキュリティに関する基準が、文書に書かれているか

不具合と仕様変更の線引き

納品後のもめごとで多いのが、「これは不具合なのか、追加の要望なのか」という線引きの問題です。契約で決めた内容と違えば不具合、決めた内容どおりだが変えたいのであれば仕様変更、という整理になります。この判断を誰が、どんな基準でするのかを、事前に確認しておきたいところです。追加要望の扱いはシステム開発の仕様変更への対応｜追加要望の扱い方にまとめています。

対応の進め方と窓口

• 不具合の連絡は、どの窓口に、どの方法で行うか
• 報告から初動までの目安の時間は決まっているか
• 緊急度によって対応の優先順位をどう分けるか
• 原因調査の結果は、報告書などの形で受け取れるか

外部要因による不具合の扱い

自社の開発範囲の外で起きる不具合もあります。たとえば、利用している外部サービスの仕様変更、OSやブラウザの更新、クラウド側の変更です。こうした外部要因によるものを、保証の対象に含めるのか、別の保守として扱うのかを確認します。

生成AIのモデルを組み込んだシステムでは、提供元のモデルが変更・終了されることがあります。こうした外部の変更をどう扱うかは、LLMモデル変更に備える開発の進め方｜提供終了の前にでも触れています。

保証期間後の保守との関係

契約不適合責任の期間が終わった後は、保守契約で対応するのが一般的です。責任の期間と保守の期間がつながっているのか、間に空白ができないかを確認します。保守の範囲の確認点は、システム開発の保守契約｜納品後の対応範囲の確認点で整理しています。

受け取る成果物とソースコード

不具合を直す、あるいは別の会社に引き継ぐ場面では、ソースコードや設計書、環境の情報が手元にあるかどうかが影響します。何を納品物として受け取れるのかは、システム開発の納品物一覧｜ソースコード以外に受け取る成果物を参考にしてください。著作権の扱いは、ソースコードの著作権譲渡｜費用を払っても自動では移らないで説明しています。

AIを使った開発の場合

AIを活用した開発でも、納品物が契約に合っているかを問う考え方は変わりません。AIが書いたコードかどうかは、契約不適合責任の有無を左右する要素ではなく、成果物の品質に責任を持つのは契約の相手方です。そのうえで、AIが生成した部分の品質を、誰がどう確認しているのかを聞いておくと安心できます。確認の考え方は、AI開発でも品質には人の確認が必要な理由や、AI生成コードの保守は可能か｜引き継ぎと改修の確認点が参考になります。

発注側が手元に残しておきたい記録

いざ不具合が見つかったとき、請求や相談の土台になるのは記録です。次のものは、納品後も保管しておきたい資料です。

• 契約書、仕様書、要件定義書など、約束の内容が分かる文書
• 検収の記録（確認項目、確認した日、結果、指摘事項）
• 不具合を発見した日時、画面、操作手順、画面の写し
• 不具合を連絡した日と、相手の返答
• 修正後の確認結果

特に「発見した日」と「連絡した日」は、前述の1年以内の通知に関わるため、日付が分かる形（メールなど）で残すのがよいでしょう。

また、不具合が見つかった時点で、連絡の遅れを避けるために、最初の一報は短くても構いません。何が起きたか、いつ気づいたかを伝え、詳細は後から補う進め方で十分です。

まとめ

システム開発の契約不適合責任について、要点を整理します。

• 契約不適合責任は、納品物が契約で決めた内容に合っていないときに、作った側が負う責任。2020年4月施行の改正民法で、瑕疵担保責任から整理し直された
• 発注側が使える手段は、追完請求、代金減額請求、損害賠償請求、契約の解除の4つ。実務では、まず修正を求める流れが中心
• 請負契約では、不適合を知った時から1年以内に通知することが原則。通知の日付が分かる記録を残すことが大切
• 検収に合格しても責任追及ができなくなるわけではないが、検収で確認できたはずの項目は争点になりやすい
• 民法の規定は契約で変更できるため、責任の期間、対象、対応方法、上限が契約書でどうなっているかの確認が欠かせない
• 契約前には、責任の期間と起点、不具合の定義、仕様変更との線引き、外部要因の扱い、保守契約との接続を確認しておく

不具合の対応範囲は、契約のあとに話し合うのでは遅く、契約の前に確かめておく項目です。契約書の読み方に迷うときは、専門家の確認と合わせて進めると安心です。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから契約するかを判断していただく受託開発サービスです。納品後も、システムの維持や不具合修正、毎月ひとつの機能追加まで、業務に合わせて育て続ける伴走型で支援しています。対応範囲の考え方や進め方については、JustFitのサービス紹介をご覧のうえ、お気軽にご相談ください。