検収とは｜ビジネスサイドのための IT 用語集

 検収とは開発会社から納品されたシステムや成果物を発注側が検査し、契約で定めた仕様どおりだと認めて受領する手続きです。

検査に合格した時点、または検査期間内に不合格の通知がなく合格とみなされた時点を検収完了と呼びます。

合格は検査合格書や検収書などの書面で開発会社に通知します。
確認作業の中心は受け入れテストで、発注側が業務の手順どおりに操作し、仕様どおりに動作するかを確認します。

検収はその結果をもとに受領の可否を決定する、契約上の区切りにあたります。
 検収で確定すること完成品を製作して納品する 請負契約 では、民法上は 報酬の支払時期を引き渡しの時点とする のが原則です。

システム開発の契約ではこの引き渡しを検収完了と連動させ、支払いや、所有権などの権利の移転を検収の後に設定する形式が一般的です。

IPA（情報処理推進機構）の 情報システム・モデル取引・契約書 も、検査の合格をもって検収完了とする形式を採用しています。
検収の完了によって次の事項が確定します。
開発会社は委託料を請求でき、発注側は契約で定めた期日までに支払いの義務を負う
納品物の所有権は モデル契約 と同じく委託料の完済時に移転するか、検収完了時に移転すると定める。著作権の扱いは契約によって異なり、モデル契約 にも開発会社に帰属させる案と発注側へ移転する案がある。著作権が開発会社に帰属すると別の会社にプログラムの改変を依頼するときに開発会社の許諾が必要になる。将来保守の担い手を変更する可能性があるなら、帰属の条項を確認する
不具合を無償で修正してもらえる期間が、契約によっては検収完了の日から起算される
開発会社は検収の時点で売上を計上することがある。そのため期末の直前には開発会社から検収の前倒しを依頼されることがある
反対に、検収の完了後はできなくなることもあります。
未完成を理由に支払いを停止する交渉はできなくなる
仕事の完成前なら発注側は開発会社の損害を賠償すれば いつでも契約を解除できる。完成を確認する検収の後はこの方法を利用できない
仕様書にない要望は不具合ではなく追加の依頼になり、別に費用がかかる。検収の前後で要望が増え続け、作業範囲が当初より広がり続ける状態をスコープクリープと呼ぶ
 検収期間とみなし検収モデル契約 は発注側が個別契約で定めた検査期間内に納品物を確認すると定めています。

不合格なら具体的な理由を書面で示して修正を求め、開発会社は無償で修正して再納品します。

検査期間内に不合格の理由を書面で通知しなければ、検査に合格したものとみなされます。

これをみなし検収と呼びます。
みなし検収は発注側が確認を先送りし、支払いが確定しないまま放置される事態を防止するための条項で、それ自体が不当なわけではありません。

問題になるのは検査期間が確認作業の量に対して不足している場合です。

業務の担当者が通常業務の合間に操作を確認する体制では、画面や帳票の多いシステムの確認を数日で完了できません。

期間は受け入れテストの項目数と、確認に充当できる人数と日数から逆算します。

目安は小規模な改修なら1〜2週間、業務全体に関係するシステムなら数週間から1か月程度です。

確認の項目と期間は開発の途中で検査仕様書として合意しておきます。
大規模なシステムを一括で検収するのが困難なら、機能のまとまりや工程ごとに分割して検収する方法があります。

その場合は支払いもその単位で分割するよう、発注側と開発会社で契約に定めます。

稼働後の一定期間を検査期間に含める取り決めも可能で、締め処理のように本番でしか動作しない機能を確認しやすくなります。
 検収後に判明した不具合検収は不具合がないことの保証ではありません。

仕様に適合しない不具合が後から判明すれば、発注側は契約不適合責任として、修正、代金の減額、損害賠償、契約の解除を請求できます。
民法上は発注側が 不適合を知った時から1年以内に開発会社へ通知 すれば、この責任を追及できます。

引き渡しの時点で開発会社が不具合を認識していたか、重大な過失で認識していなかった場合は、この1年の制限も適用されません。

2020年4月の民法改正の前は瑕疵担保責任と呼ばれ、期限は引き渡しから1年でした。
ただし実際の契約では検収完了から何か月以内と期限を設定することが多くあります。

期限の経過後は同じ不具合でも有償の保守対応になります。

不具合の原因が発注側の提供した資料や指示にある場合、開発会社の責任は追及できません。

ただし開発会社がその問題を認識しながら告知しなかった場合は除きます。
月末だけ実行する締め処理や年1回の決算処理は、受け入れテストの期間中に動作しません。

こうした機能は検収の時点では確認できません。
その場合は責任の期間を少なくとも処理の一巡分を含む長さに設定するか、不適合を認識した時点から起算する規定を維持するよう契約で交渉します。
 準委任契約の検収作業そのものを依頼する準委任契約では、開発会社に完成の義務がありません。

そのため検収は報告された作業の完了を確認するだけで、仕様どおりに動作することの保証にはなりません。

成果物に対して報酬が発生する 成果完成型の準委任 もあり、同じ検収という言葉でも契約によって中身が異なります。
 法律で支払いの期日が制限される取引2026年1月に下請法を改正した中小受託取引適正化法の対象取引では、検収に時間がかかっても、受領から60日以内に定めた期日までに代金の支払いが必要です。

公正取引委員会の Q&A はプログラムなどの作成を委託する場合について、納期前でも一定の水準を満たしていると確認した時点を受領とする扱いを認めています。
対象はソフトウェアを販売・提供する事業、または自社で利用するソフトウェアを社内でも業として開発している事業の一部を、外部に委託する取引です。

さらに、発注側と委託先の資本金や従業員数が基準を満たす必要があります。

社内に開発部門を有する会社や、受託した開発の一部を再委託する会社は、検収の期間と支払いの期日を整合させて設計します。
 気にすべき場面と気にしなくてよい場面気にすべきなのは請負で開発を一括発注する高額な案件で、検収と同時に大半の支払いが発生する場面です。

本番稼働やデータ移行の前に検収時期が来る計画や、期末を理由に検収を求められている場面も、条件を確認してから受領します。
SaaS（Software as a Service）の月額利用や、保守契約の中の小さな修正では、検収を厳密に行う場面は少なくなります。

準委任で月ごとに作業を精算している場合も、月次の報告の確認で十分です。
 よくある誤解 検収は書類に押印するだけの事務手続き書類への押印の時点で、支払いの義務が発生します。

責任の期間もこの時点から起算されます。

未確認の機能がある状態で押印すれば、その機能の不具合は稼働後に発注側が自分で発見する必要があります。

無償で修正してもらえるのは、責任の期間内に発見して通知した不具合に限られます。
 検収後の不具合はもう修正してもらえない仕様に適合しない不具合は契約に定めた期間内なら無償で修正してもらえます。

仕様書に記載のない要望と、期間の経過後に判明した不具合は、無償の修正の対象外です。
 残課題があっても後日の修正を約束すれば検収してよい口頭の約束だけで検収すると、修正の交渉は支払いの完了後になります。

修正の優先度も低下しやすくなります。

残課題を一覧にして修正の期限と費用負担を書面で合意してから検収するか、残課題のある機能だけを分離して後日検収します。
 検収の時期の決め方大半の支払いが検収と同時に発生する請負では、本番のデータで月次の締めまで稼働させた後を検収の時期にするほうが安全です。

開発会社の期末の都合で検収の時期を前倒しするなら、未確認の機能の検査期間と責任の期間を延長する条件と引き換えにします。