【受託開発】検収後の不具合、修正費用は無償か有償か｜契約不適合責任の実務

【受託開発】検収後の不具合、修正費用は無償か有償か｜契約不適合責任の実務

中級 ／ ★★★ ／ 前半無料・後半有料（500円）

検収が完了し請求書も発行し終えたプロジェクトで、後日「不具合を見つけた」と顧客から連絡が来たとき、無償で直すべきか追加費用を請求すべきか、その場で即答できるPM・エンジニアは意外と多くありません。この記事では、民法の契約不適合責任の考え方に沿って、受託開発の現場で判断に迷うこの境界線を整理します。

この記事でわかること：

• 検収完了とは法的に何を意味するのか、なぜ「終わったはず」のプロジェクトで揉め事が起きるのか

• 契約不適合責任とは何か——2020年民法改正で「瑕疵担保責任」から何が変わったのか

• 無償対応すべきケースと追加請求できるケースを分ける、3つの判断基準

• 契約不適合責任に基づく4つの請求類型（追完請求・代金減額請求・損害賠償請求・解除）の使い分けと行使の優先順位【有料】

• 3つの具体的なケーススタディでの判定シミュレーション（明確なバグ／要件定義書にない要望／性能面のクレーム）【有料】

• 契約不適合責任期間の契約書条項の実務——相場とサンプル条項文言【有料】

• 顧客への回答文言サンプルと、社内エスカレーションのチェックリスト（そのまま使えるテンプレート）【有料】

検収完了は「契約の終わり」ではない——なぜ後から不具合報告が来るのか

受託開発のプロジェクトでは、成果物を納品し、顧客側の検収（受入テスト）に合格した時点で、多くの現場では「このプロジェクトは完了した」という空気になります。請求書を発行し、PMは次の案件にアサインされ、開発チームも解散していく。ところが実際には、検収完了から数週間〜数か月が経ったころに、顧客から「使っていたらエラーが出た」「想定していた動きと違う」という連絡が入ることが珍しくありません。

ここで最初につまずきやすいのが、「検収に合格した＝もう何も責任を負わない」という誤解です。検収は、あくまで納品時点で確認できた範囲において、契約書・仕様書に定めた内容を満たしていることを顧客が確認した、という手続きにすぎません。検収に合格していても、契約内容に適合しない部分が後から見つかれば、請負人（受託開発会社）は民法上の責任を問われる可能性があります。これが「契約不適合責任」と呼ばれる考え方です。

一方で、検収後に来る要望のすべてが無償対応の対象になるわけでもありません。顧客からの連絡の中には、明らかなバグ修正もあれば、「使ってみたらこういう機能も欲しくなった」という新規の追加要望が紛れ込んでいることもあります。この2つを混同したまま対応してしまうと、本来は追加請求できるはずの工数を無償で提供してしまったり、逆に無償対応すべき不具合を有償扱いにして顧客との信頼関係を損なったりする事態につながります。

【検収後によくある連絡と、その正体（例）】

パターン1：「入力した金額が正しく合計されない」
　→ 仕様書どおりに動作していない典型的なバグ
　→ 契約不適合の可能性が高い

パターン2：「もっと見やすい画面にしてほしい」
　→ 仕様書に明記のない、UI改善の新規要望
　→ 契約不適合ではなく追加開発の対象になりやすい

パターン3：「月末に処理が重くて固まる」
　→ 仕様書に性能要件（応答時間・同時接続数等）の
　　 記載があったかどうかで判定が分かれる
　→ 契約不適合／追加開発、どちらもあり得る

この3つのパターンを見分けるための土台になるのが、次に説明する契約不適合責任という法的な枠組みです。

契約不適合責任とは何か——2020年民法改正で「瑕疵担保責任」から何が変わったのか

契約不適合責任は、2020年4月に施行された改正民法で整理された考え方です。それ以前は「瑕疵担保責任」という言葉が使われていましたが、名称だけでなく中身にもいくつかの重要な変更が加えられました。

【瑕疵担保責任（旧法）と契約不適合責任（現行法）の違い（概要）】

旧法：瑕疵担保責任
　対象　　：目的物に「隠れた瑕疵」（通常の注意では
　　　　　　発見できない欠陥）があること
　請求できること：損害賠償請求・契約解除が中心
　　　　　　　　　（修補請求は請負契約に限り認められていた）

現行法：契約不適合責任（民法559条・562条〜564条等）
　対象　　：成果物の種類・品質・数量が「契約の内容に
　　　　　　適合しない」こと（隠れているかどうかは問わない）
　請求できること：
　　①履行の追完請求（修補・代替物の引渡し等）
　　②代金減額請求
　　③損害賠償請求
　　④契約の解除
　　※①②が現行法で明文化された点が実務上の大きな変化

ポイントは、判断基準が「隠れた欠陥かどうか」という発見のしやすさではなく、「契約書・仕様書で合意した内容と、実際の成果物が食い違っているかどうか」という契約内容との比較に一本化されたことです。つまり、契約不適合責任の議論をするときは、常に「契約書・仕様書に何と書いてあったか」に立ち返る必要があります。逆に言えば、仕様書に明記されていない事柄については、そもそも契約不適合責任の議論の土俵に乗らない、ということでもあります。

また、期間の考え方にも注意が必要です。請負契約（受託開発契約）における種類・品質に関する契約不適合については、民法637条により、注文者（顧客）が不適合を知った時から1年以内に請負人へ通知しなければ、原則としてその責任を追及できないと定められています（売買契約における同様の期間制限は566条に規定されており、637条はこれに準じた請負契約向けの規定です）。ただし、これは民法上のデフォルトルールであり、受託開発の契約書では、システムの性質を踏まえて「検収完了日から6か月」「1年」のように、この期間を個別に定め直しているケースが一般的です。自社の契約書のひな形に契約不適合責任の期間条項があるかどうか、一度確認しておくことを強くおすすめします。

なお、この記事の説明は一般的な考え方の整理であり、個別の契約・トラブルにおける法的な最終判断は、契約書の文言と個別の事実関係に基づいて顧問弁護士に確認することが前提になります。

無償対応と追加請求を分ける、3つの判断基準

ここまでの整理を踏まえて、検収後に顧客から連絡が来たときに、その場で当たりをつけるための3つの判断基準をまとめます。

【判断基準1：契約書・仕様書との照合】
　問い：報告された事象は、契約書・仕様書（要件定義書・
　　　　基本設計書等）に明記された内容と食い違っているか
　YES → 契約不適合の可能性が高い（無償対応の検討対象）
　NO　→ 仕様書に記載のない事柄＝追加開発の対象
　　　　　（有償対応の検討対象）

【判断基準2：契約不適合責任の期間内かどうか】
　問い：契約書に定めた契約不適合責任の期間
　　　　（検収完了日から○か月等）を過ぎていないか
　期間内 → 契約不適合責任の追及対象になり得る
　期間外 → 別途、保守契約の範囲か、新規の
　　　　　 見積り案件として扱うのが原則

【判断基準3：注文者側の指示・提供資料に起因していないか】
　問い：不適合の原因が、注文者（顧客）が提供した
　　　　仕様・指示・データにあるのではないか
　YES → 請負人（自社）の契約不適合責任は
　　　　軽減・免責される可能性がある（民法636条等）
　NO　→ 請負人側の責任として検討を進める

この3つの基準のうち、実務で最も揉めやすいのが判断基準1です。「仕様書に書いてあったかどうか」を確認しようとしても、仕様書自体の記載が曖昧だったり、口頭やチャットでのやり取りだけで仕様が変更されていたりするケースが少なくありません。この曖昧さこそが、検収後のトラブルを長引かせる最大の原因です。裏を返せば、要件定義・設計の段階で仕様書の記載を具体的にしておくこと自体が、将来の紛争を防ぐ最良の予防策だといえます。

ここまでで、検収完了が契約の終わりを意味しないこと、契約不適合責任という枠組みの全体像、そして無償対応と有償対応を分ける3つの判断基準の骨格を確認しました。しかし実際の現場では、「仕様書に書いてあるかどうか」を確認した後、具体的にどの請求方法を選び、顧客にどう説明し、社内でどう合意形成すればよいのかという「その先」の手順で足が止まってしまうことがほとんどです。

ここから先の有料パートでは、契約不適合責任に基づく4つの請求類型の使い分け、実際によくある3つのケースでの判定シミュレーション、契約書に盛り込むべき条項のサンプル文言、そして顧客への回答文言テンプレートと社内エスカレーションのチェックリストまで、明日からそのまま使える形で整理します。

ここから先は有料コンテンツです（500円）。

有料パートでは以下を詳しく解説します：

• 契約不適合責任に基づく4つの請求類型（追完請求・代金減額請求・損害賠償請求・解除）それぞれの要件と、行使する順序の実務上のセオリー

• 3つの具体的なケーススタディ（明確なバグ／要件定義書にない追加要望／性能面のクレーム）を、無料パートの3つの判断基準に当てはめて判定する実践演習

• 契約不適合責任期間の契約書条項の実務——相場の期間設定とサンプル条項文言

• 顧客への回答文言サンプル（無償対応時・有償対応時それぞれ）と、社内エスカレーションのチェックリスト・判定シートのテンプレート

無料パートで整理したのは、「契約不適合責任とは何か」「無償か有償かを分ける3つの判断基準」という考え方の骨格までです。有料パートは、その骨格を実際の顧客対応の現場に落とし込み、請求類型の選び方、ケース別の判定、契約書の条文、顧客への回答文言まで、実務でそのまま使える「解答例」にあたります。読み終えた時点で、自分のプロジェクトで検収後の不具合報告を受けたときに、迷わず初動を切れる状態を目指した構成です。