仕様書に書いていない不具合は無償で直してもらえる？納品後に揉めないための5つの見分け方

2026年11月5日

納品されたシステムを使い始めたら、思っていた動きと違う箇所が見つかった。開発会社に伝えたいけれど、仕様書を見返しても、その動きについては何も書かれていない。「これは不具合として直してもらえるのか、それとも追加の費用がかかるのか」と、連絡する前から気が重くなる場面です。

「納品後に見つかった不具合の修正が、無償か有償かで揉めそう。仕様書に書いていない場合は、どう決まるのでしょうか」

先に結論をお伝えします。仕様書に書いていないからといって、有償と決まるわけではありません。無償になるかどうかは、「契約の内容に合っているか」で判断されます。契約の内容は、仕様書だけでなく、見積書・要件定義書・打ち合わせの記録・システムの目的も含めて考えるのが一般的です。

この記事では、仕様書に書かれていない不具合を、無償・有償のどちらで話し合うことになりやすいかを見分ける5つのポイントを、チェックリストと開発会社への質問例とあわせて解説します。契約や法律の話は一般的な考え方の紹介にとどめます。個別の判断は弁護士などの専門家に確認してください（執筆時点：2026年11月）。

なお、検収（＝発注した内容どおりにできているか確かめて、受け取りを認める手続き）の期間が過ぎたあとの対応は、別の記事で詳しく扱っています。

あわせて読みたい

検収の期間が過ぎたあとで不具合に気づいた。無償で直してもらえる？発注者が最初に確認する5つのこと検収の期間が過ぎたあとで不具合に気づいたとき、無償で直してもらえるのか。契約不適合責任の考え方と、発注者が最初に確認する5つのことを解説します。

仕様書に書いていないのに揉めやすい3つの理由

理由1：仕様書は「全部の動き」を書ききれない

仕様書（＝作るものの内容を文章にした資料）には、画面や機能の主な動きが書かれています。ただ、入力ミスをしたときの表示、同時に大勢が使ったときの速さ、使えるブラウザの種類など、細かい動きまで全部書くことは現実的ではありません。そのため、書かれていない部分でトラブルが起きやすくなります。

理由2：発注者と開発会社で「当然」の範囲が違う

発注者は「こう動くのが当然」と考え、開発会社は「書いていないので対象外」と考える。どちらも悪意があるわけではなく、前提が違うだけです。この食い違いは、仕様が曖昧なまま進んだ案件で起きやすくなります。

理由3：直す側にも費用がかかる

不具合の修正には、原因の調査・修正・確認の作業が必要です。開発会社は、契約の範囲外の作業を無償で引き受けると赤字になりかねません。そのため「契約の範囲内かどうか」を慎重に確認するのは、自然な対応です。

無償か有償かを見分ける5つのポイント

1. 契約の内容は仕様書だけではない

請負契約（＝完成したものに対して報酬を払う契約）では、納品物が契約の内容に合っていないとき、発注者は修正の請求などができる、というのが民法の基本的な考え方です。この責任は契約不適合責任（＝納品されたものが契約の内容に合っていないときに、開発会社が負う責任。以前は瑕疵担保責任と呼ばれていた）といいます。

📰 出典：e-Gov法令検索「民法」

ここで大切なのは、「契約の内容」が仕様書の文字だけを指すとは限らない点です。次の資料も、何を約束したのかを示す手がかりになります。

見積書に載っている機能の一覧
要件定義書（＝何を作るかを決めた資料）
打ち合わせの議事録やメールのやり取り
システムの目的として共有されていた内容

2. 「バグ」か「仕様の解釈違い」か「追加要望」かに分ける

見つけた問題を、次の3つに分けて考えると整理しやすくなります。

種類	例	話し合いの方向性
バグ（＝プログラムの誤り）	書いてあるとおりに押しても動かない、計算結果が間違っている	無償で対応する対象になりやすい
仕様の解釈違い	「一覧を出力」の項目や並び順が想定と違う	資料を突き合わせて話し合う
追加要望	最初の相談になかった機能を足したい	別の見積もりになりやすい

真ん中の「解釈違い」が、最も揉めやすい部分です。ここは、次のポイント3以降で材料をそろえます。