先に要点
受託開発やシステム開発の現場では、今でも 瑕疵対応 という言葉がよく出ます。
ただ、契約書や改正民法の文脈では、契約不適合責任 という言い方が前提になりやすいです。
このあたりが曖昧だと、納品後に見つかった不具合が 契約上の責任として直すべき話 なのか、通常の不具合修正 なのか、保守契約の範囲 なのか、仕様変更 なのかが混ざります。
その結果、発注側も受注側もかなり疲れます。
この記事では、システム開発で瑕疵対応はどこまで必要かを、契約不適合責任 の考え方、不具合修正との違い、検収や保守契約との線引き、実務で揉めにくくする整理の仕方からまとめます。
検収そのものの進め方を先に見たい場合は、検収とは？受託開発で納品後に揉めない確認項目と進め方 もつながりやすいです。
契約類型そのものの違いから整理したい場合は、準委任契約と請負契約の違い｜システム開発でどう使い分ける？ もあわせて読むと流れがつかみやすいです。
この記事では、2026年4月22日時点で法務省の民法改正説明資料、IPAの改正民法対応版・第二版の情報システム・モデル取引・契約書を確認しながら整理しています。ここでは法的助言ではなく、受託開発で使いやすい実務上の整理としてまとめます。個別契約の判断は、契約書と専門家確認を優先してください。
結論：瑕疵対応は「何でも無料修正」ではなく「契約に合っているか」の話
最初に結論を言うと、瑕疵対応を考えるときに大事なのは、不具合があるかどうか だけではありません。
本当に見るべきなのは、納品物が契約、要件定義、見積もり、合意済み仕様、検収 条件に適合しているかです。
そのため、次を混ぜない方が安全です。
- 合意済み仕様どおりに動いていない話
- 納品後に見つかった通常の不具合修正
- 合意後に変えたくなった要望
- 保守契約で引き受ける運用上の調整
ここを混ぜると、契約上の責任として無償対応すべき範囲 と 通常の追加作業 の境目が見えなくなります。
そもそも瑕疵対応と契約不適合責任はどう違う？
実務では今も 瑕疵 という言葉が残っていますが、改正民法では 契約不適合責任 で整理されます。
法務省の説明資料でも、瑕疵 という用語は 契約の内容に適合していないこと を意味するものとして見直されたとされています。
ざっくり言うと、今の実務では次の理解で十分です。
| 言い方 | 意味 | 実務での扱い |
|---|---|---|
| 瑕疵対応 | 現場で昔から使われる言い方 | 口頭や慣習では残るが、契約書では別表現になることが多い |
| 瑕疵担保責任 | 改正前民法でよく使われた整理 | 古い契約書や説明文で見かける |
| 契約不適合責任 | 契約内容に適合しない場合の責任 | 現在の契約や法的説明ではこちらが前提になりやすい |
なので、クライアントとの説明では 瑕疵対応というより、契約内容に合っているかで見る話です と言い換える方が伝わりやすいことがあります。
契約不適合責任と不具合修正の違い
ここが一番混ざりやすいです。
不具合修正は技術的な現象の話ですが、契約不適合責任は契約との適合の話です。
| 観点 | 契約不適合責任 | 不具合修正 |
|---|---|---|
| 基準 | 契約、要件、仕様、検収条件に合っているか | 期待した動きと違う技術的問題があるか |
| 見る範囲 | 成果物全体、契約上の責任、救済方法 | 特定機能や画面の修正対応 |
| 混ざりやすい場面 | 納品後、検収後、保守開始前後 | テスト中、運用中、問い合わせ対応時 |
たとえば、次のように見ると整理しやすいです。
- 仕様書にある必須チェックが動いていない: 契約不適合の可能性が高い
- 一部画面で表示崩れがある: 不具合修正として扱いやすい
- 要件で決めていなかったCSV項目を追加したい: 不具合ではなく追加要望
- 外部サービス仕様変更で既存機能が動かなくなった: 保守や運用契約の話が混ざる
つまり、バグっぽい見た目 でも、契約との関係まで見ないと判断を誤りやすいです。
どこまで対応が必要かは、契約と検収でかなり変わる
IPAのモデル契約でも、契約のタイミングで仕様や検収方法を共通理解のもとで対話することが重視されています。
また、改正民法対応の整理では、責任期間や起算点についても、契約上どう置くかが重要な論点になっています。
実務では、少なくとも次が曖昧だとかなり揉めます。
ここがないと、納品直後の軽微バグから、数か月後の環境差異、運用ミス、追加要望まで全部 瑕疵対応ですよね と言われやすくなります。
受託開発で実際に揉めやすいパターン
1. 検収条件が弱い
検収条件が曖昧だと、後から 思っていたものと違う が出やすいです。
でも、その違いが契約不適合なのか、期待値のズレなのかが分からなくなります。
2. 仕様変更と混ざる
合意後に やっぱりこうしたい が入ると、現場では修正に見えても、契約上は仕様変更のことがあります。
これを瑕疵対応に入れてしまうと、責任範囲が広がりすぎます。
3. 保守契約との境目がない
納品後の問い合わせ、環境変化対応、外部サービス変更追随をどこまで保守で見るかが決まっていないと、契約不適合責任と運用保守が混ざります。
4. 古い契約書の言葉だけ残っている
契約書では 瑕疵 という古い表現のまま、現場では バグ対応 と呼び、説明では 保守で見ます と言っている。こういう状態も危険です。
言葉がずれると、期待値もずれます。
実務で使いやすい整理のしかた
受託開発では、納品後の問題を次の順で見ると整理しやすいです。
- 合意済み仕様や要件に書かれていたか
- 検収時に確認対象だったか
- 納品時点で存在していた問題か
- 運用環境や外部サービス変更が原因か
- 追加要望や仕様変更が混ざっていないか
この順で見れば、少なくとも 契約不適合の可能性がある話 と 通常の不具合修正 と 追加作業 を分けやすくなります。
クライアントへどう説明すると揉めにくいか
説明では、法律用語だけで押し切るより、契約との関係を日常語で言い換える方が伝わりやすいです。
説明例
今回の修正が、合意済み仕様どおりに動いていないための対応なのか、納品後の追加要望なのかで扱いが変わります。
まず契約と要件定義、検収条件に照らして確認し、そのうえで無償対応範囲か、保守範囲か、別見積かを整理します。
この言い方なら、いきなり それは契約不適合責任です と強く言わずに、線引きの前提を共有しやすいです。
よくある失敗
`納品後に見つかった修正は全部瑕疵対応` と雑にまとめてしまうことです。これだと、契約上の責任、不具合修正、保守、仕様変更が全部混ざり、どちらにとっても不満が残りやすくなります。
ほかにも次の失敗はかなり多いです。
- 検収条件を先に決めていない
- 責任期間の置き方が曖昧
- 保守契約の開始条件が弱い
- 古い
瑕疵の言い方と今の契約表現が混ざる - 契約書、見積書、議事録で言葉がそろっていない
まとめ
システム開発で言う 瑕疵対応 は、今の整理では 契約不適合責任 の話として見る方が安全です。
そして、その中心は バグがあるか ではなく 契約内容に適合しているか です。
実務では、不具合修正、仕様変更、保守対応と混ぜず、契約、要件定義、検収条件、責任期間、保守契約の境目をそろえておくことがかなり大事です。
納品後に揉めないためには、最後に法律用語で戦うより、最初に完了条件と責任範囲を言葉でそろえる方がずっと効きます。