システムを受け取って検収(=発注した内容どおりにできているか確かめて、受け取りを認める手続き)を済ませたあとで、「あれ、この操作だけ動かない」と気づく。受け入れ確認の期間が決まっていたのに、忙しくて十分に試せなかった。システム開発の現場では、実はよくある話です。
「受け入れ確認の期間が過ぎてしまった後で不具合に気づいた。もう無償で直してもらえないのでしょうか」
先に結論をお伝えします。検収の期間が過ぎたから、もう無償では直してもらえない、とは限りません。多くの契約では、検収のあとにも「契約不適合責任(=納品されたものが契約の内容に合っていないときに、開発会社が負う責任)」の期間が別に設けられています。ただし期間には限りがあり、気づいてから動き出すまでの早さで結果が変わります。
この記事では、検収後に不具合に気づいたとき、発注者が最初に確認する5つのことを、そのまま使えるチェックリストと開発会社への質問例とあわせて解説します。なお、契約や法律の話は一般的な考え方の紹介にとどめます。実際の契約書の読み方や個別の判断は、弁護士などの専門家に確認してください(執筆時点:2026年11月)。
「検収が終わったら終わり」にならない理由
検収と、その後の無償対応は、別々のルールで動いています。
| 項目 | 何のための期間か | 期間の例 |
|---|---|---|
| 検収期間 | 納品物を試して、受け取りを認めるかどうか決める期間 | 納品後の数日〜数週間(契約で決める) |
| 契約不適合責任の期間 | 検収後に見つかった、契約の内容と合わない点を直してもらえる期間 | 契約書に定める(民法の定めもある) |
| 保守契約の期間 | 運用中の問い合わせや改修に対応してもらう期間 | 月額・年額の契約 |
検収期間が過ぎても、2つ目の「契約不適合責任の期間」が残っていれば、無償で直してもらえる余地があります。一方で、3つ目の保守契約は、そもそも「不具合を直す契約」ではなく「運用を支える契約」であることが多く、不具合の修正が含まれるかは契約によって違います。
開発会社の側にも事情がある
検収が済むと、開発会社は「この内容で完成」と受け止めて次の案件に人員を移すのが一般的です。そのため、検収後の連絡は、担当者がすぐつかまらなかったり、「それは検収時に確認いただいた範囲です」という返答になったりすることがあります。これは誰かが悪いというより、契約上の線引きが曖昧なまま進んだときに起きやすい行き違いです。
最初に確認する5つのこと
1. 契約書の「検収」と「契約不適合責任」の条文を探す
まず契約書(または注文書・利用規約)を手元に用意し、次の2つの条文を探します。
- 検収の条文:検収の期間、期間内に連絡しなかった場合の扱い(「合格とみなす」など)
- 契約不適合責任(以前は「瑕疵担保責任」と呼ばれていたもの)の条文:期間、無償で対応する範囲
経済産業省とIPAが公表している「情報システム・モデル取引・契約書」でも、契約不適合責任の期間は契約書で定める項目として扱われています。具体的な期間はひな形では「〇ヶ月/〇年」と空欄になっており、発注者と開発会社が話し合って決めることが想定されています。
契約書に期間の定めが見当たらない場合や、書いてある内容の意味が分からない場合は、無理に自己判断せず、次のステップで専門家に相談してください。
2. 気づいた日付と状況を、その日のうちに記録する
後の話し合いで大切になるのが、「いつ気づいたか」です。民法には、請負契約で納品物が契約の内容に合っていなかった場合、発注者がその不適合を知った時から1年以内に開発会社へ通知することを求める定めがあります(民法第637条。請負の考え方は第559条)。契約書でこれと違う期間が定められていることもあります。
📰 出典:e-Gov法令検索「民法」
そのため、次の情報をその日のうちにメモしておきます。
- 気づいた日時と、気づいた人
- どの画面で、どんな操作をしたら、何が起きたか(画面のスクリーンショットがあるとよい)
- 契約書・仕様書・要件定義書の、該当する記述(どこに「こう動く」と書いてあるか)
3. 「不具合」か「追加要望」かを切り分ける
無償で直してもらえるのは、基本的に「約束した内容と違う」場合です。最初から約束に入っていなかった機能を「足りない」と感じている場合は、追加の開発として別の見積もりになるのが一般的です。
| 見分けるポイント | 不具合(無償の対象になりやすい) | 追加要望(別見積もりになりやすい) |
|---|---|---|
| 仕様書・要件定義書 | 書いてあるのに、そのとおり動かない | そもそも書かれていない |
| 画面や操作 | 想定した操作でエラーになる | 想定外の使い方をしたい |
| 判断のよりどころ | 契約書・仕様書の記述 | 発注者の「当然こうあるはず」という期待 |
「当然あるはず」と思っていた機能が仕様書に無いと、立場の違いで意見が分かれます。この境目が曖昧なときこそ、ステップ2で集めた記録が役に立ちます。
4. 開発会社へは、まず書面(メール)で通知する
電話や打ち合わせの口頭だけだと、後から「聞いていない」という行き違いが起きます。メールなど、日付が残る形で次の内容を伝えます。
- 不具合の内容と、気づいた日
- 契約書のどの条文・仕様書のどの記述に関する話か
- 確認と対応方針を、いつまでに教えてほしいか
文面は事実を淡々と伝えるのが基本です。「責任を取ってほしい」「無償で当然だ」と最初から強い言い方をすると、話し合いがこじれやすくなります。「契約の範囲内かどうか、一緒に確認させてください」という姿勢のほうが、結果的に早く進みます。
5. 無償か有償かは、対応の範囲と費用を見て決める
話し合いの結果、無償の対象外になることもあります。その場合も、次の点を見積もりや提案書で確認してから、依頼するかどうかを決めます。
- 修正の内容と、影響する範囲(他の機能に影響しないか)
- 費用と期間
- 修正後の確認(テスト)を誰がどこまで行うか
金額の妥当性が分からないときは、見積もりの内訳を出してもらうと比べやすくなります。
やりがちな失敗
- 様子を見ているうちに時間が過ぎる:「たまたまかも」と放置すると、気づいた日の証拠が曖昧になります。
- 電話だけで済ませる:言った・言わないになりやすいので、必ず文章でも残します。
- 仕様書を見ずに「普通はこう動く」で話す:判断のよりどころは、あくまで契約書と仕様書です。
- 勝手に別の会社へ修正を頼む:保証の対象から外れる契約もあります。先に契約書を確認します。
- 次回の契約で何も変えない:同じ行き違いを繰り返さないために、次の発注では検収の進め方を見直します。
次の発注で同じ悩みを減らすために
検収で見逃しが出ないようにするには、検収の前の準備が効きます。
- 検収の基準を、事前に「この操作ができれば合格」という形で決めておく
- 検収の期間は、実際に試す人の予定を確保できる長さにする
- 検収の前に、重要な操作を一通り試す時間を、あらかじめカレンダーに入れる
- 検収後の無償対応の期間と範囲を、契約の前に確認する
発注者がやること チェックリスト
- ☐ 契約書の「検収」と「契約不適合責任」の条文を探して読んだ
- ☐ 気づいた日時・操作・症状を、その日のうちに記録した
- ☐ 仕様書・要件定義書の該当する記述を探した
- ☐ 不具合なのか追加要望なのかを、仕様書をもとに切り分けた
- ☐ 開発会社へ、メールで内容と気づいた日を伝えた
- ☐ 対応の範囲・費用・期間の説明を、書面でもらった
- ☐ 判断に迷う契約の読み方は、弁護士など専門家に確認した
開発会社への質問例
- 「検収後に動かない操作を見つけました。契約不適合責任の対象になるか、契約書のどの条文に当たるか教えていただけますか」
- 「該当する仕様書の記述はこちらです。仕様書と実際の動きに差があるという認識で合っていますか」
- 「無償の対応期間は、いつまででしょうか。その期間の数え方も教えてください」
- 「無償の対象外になる場合、修正の内容・費用・期間の見積もりをいただけますか」
- 「修正後に他の機能へ影響が出ていないことを、どのような確認で示していただけますか」
まとめ
- 検収の期間が過ぎても、契約不適合責任の期間が残っていれば、無償で直してもらえる可能性があります
- 最初にやるのは、契約書の確認と、気づいた日・状況の記録です
- 「不具合」か「追加要望」かの切り分けは、仕様書の記述が決め手になります
- 連絡は、日付が残るメールで、事実を淡々と伝えます
- 次の発注では、検収の基準と、検収後の無償対応の範囲を先に決めておきます
契約の読み方や、開発会社との話し合いの進め方に迷うときは、第三者の目で整理するのも一つの方法です。
あわせて読みたい関連記事












