メインコンテンツへスキップ
発注・内製化・コスト
システム開発
発注
受託開発
要件定義
DX

システム開発の検収 実務ガイド:発注者が「中身を読めないもの」をどう受け入れるか(民法・2026年施行の新法対応)

検収は「動いたら合格」ではなく、支払い義務と責任追及期限が同時に確定する法律行為です。請負と準委任で何が変わるか、民法562〜564条の3つの武器と636条の落とし穴、637条の『知った時から1年』、非エンジニアでも実行できる受け入れテストの作り方、そして2026年1月施行の新法が発注者側に課す制約まで、一次法令で裏を取って整理します。

公開日
読了時間
15分
著者
友田 陽大
シェア

システム開発の発注で、発注者がいちばん無防備になる瞬間があります。検収です。

見積もりは相見積もりで比べられます。契約書は読めば分かります。しかし納品されたソフトウェアは、中身を読めません。画面を触って「動いているように見える」ことは確認できても、それが仕様どおりなのか、負荷がかかったときに壊れないのか、セキュリティ上の穴がないのかは、発注者側から見えません。

にもかかわらず、検収は支払い義務と責任追及の起算点を同時に確定させる法律行為です。見えないものに、法的な意味のある「はい」を言わされる——これが検収の構造的な難しさです。

この記事は、その非対称をどう埋めるかを扱います。法律の話は一次法令(e-Gov法令検索の条文そのもの)で裏を取り、実務の話は受託側として要件定義から引き渡しまでを担当してきた経験から書きます。

免責:本記事は発注実務の設計指針であり、法的助言ではありません。条文の解釈や個別事案の判断は弁護士にご確認ください。条文は執筆時点(2026年9月)のものです。


0. 結論:検収は「品質判定」ではなく「線引き」

先に要点を置きます。

誤解実際
検収=動作確認検収=受け入れの意思表示。動作確認(受け入れテスト)はその前工程
検収を通したら終わり契約不適合責任は別ルートで残る(民法562条以下)
不具合が出たらいつでも言える知った時から1年以内の通知が必要(民法637条)
検収が終わるまで払わない発注者が新法の委託事業者なら、検査の有無を問わず受領日から60日以内

そしてもっとも重要な原則がこれです。

検収の合否基準は、検収の時に決めるものではない。要件定義の時に決まっていなければならない。

「動いていない気がする」は検収の理由になりません。何をもって完成とするかを先に文書化していない限り、検収は交渉になり、交渉には力関係が出ます。


発注で失敗しないために

外注先の技術力を見極める「発注前チェックリスト」を無料配布中

1. 契約形態で検収の意味が変わる(請負 vs 準委任)

最初に確認すべきは契約書の種類です。ここを見ずに検収基準を作ると噛み合いません。

請負(民法632条):

請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対して報酬を支払うことを約することによって、その効力を生ずる。

完成を約束しているので、「完成物が契約内容に適合しているか」を検収で判定できます。

準委任(民法656条)は「法律行為でない事務の委託」で、売買の規定を準用する請負とは性質が違います。特定の成果物の完成を約束していないため、検収で問うべきは「仕様どおりの物ができたか」ではなく「合意した作業が適切に行われたか」になります。

つまり——

  • 請負:成果物ベースの検収。契約不適合責任が働く
  • 準委任:作業ベースの確認。成果物の不適合を理由にした責任追及は原則なじまない

アジャイル開発で準委任を選びながら「動くものが出てこない」と検収で揉めるケースは、この不一致が原因です。契約形態の選び方はシステム開発の契約形態ガイドで詳しく扱っています。


2. 発注者に与えられた3つの武器(民法562〜564条)

請負にも売買の規定が準用されます(民法559条:「この節の規定は、売買以外の有償契約について準用する」)。したがって発注者は次の3つを持ちます。

① 追完請求(562条)

引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。

まず「直せ」と言えます。ただし但書により、売主側が別の方法で追完することも許されます(買主に不相当な負担を課さない場合)。「作り直せ」と要求しても「修正で対応する」と返される余地がある、ということです。

② 代金減額請求(563条)— ここが実務で誤解される

563条は原則として催告を要求します。

買主が相当の期間を定めて履行の追完の催告をし、その期間内に履行の追完がないときは、買主は、その不適合の程度に応じて代金の減額を請求することができる。

いきなり減額はできません。「いつまでに直してください」と期間を切った催告が先です。無催告で直ちに減額できるのは、条文が列挙する次の4つの場合だけです。

  1. 履行の追完が不能であるとき
  2. 売主が追完を拒絶する意思を明確に表示したとき
  3. 契約の性質・当事者の意思表示により特定の日時内でなければ目的を達せられない場合に、その時期を経過したとき
  4. 催告をしても追完を受ける見込みがないことが明らかなとき

実務上の含意は明確です——催告は口頭ではなく記録の残る形で、期限を明示して行う。この一手間を省くと、減額請求の前提が欠けます。

③ 損害賠償請求・契約解除(564条)

564条は、①②が損害賠償請求(415条)や解除権の行使(541条・542条)を妨げないと定めます。さらに請負では641条により、請負人が仕事を完成しない間は、注文者はいつでも損害を賠償して契約を解除できます。「途中でやめる」選択肢は法律上確保されています(損害賠償は必要です)。


3. 最大の落とし穴:民法636条(発注者の指図)

ここが本記事でいちばん伝えたい条文です。

請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したときは、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

平たく言えば——発注者自身の指示が原因の不具合は、ベンダーに責任を負わせられません。

これは検収の何倍も上流で効いてきます。

  • 「この仕様でお願いします」と発注者が決めた画面遷移が使いにくかった → 原則、追完も減額も請求できない
  • 発注者が支給したマスタデータの設計が原因で性能が出ない → 同上
  • ただしベンダーが不適当と知りながら黙っていたなら、責任を問える

だから重要なのは、「誰がその判断をしたか」と「ベンダーが何を助言したか」を記録に残すことです。議事録に「この方式は将来のデータ増で性能が劣化する可能性がある旨、ベンダーより指摘あり。発注者判断で採用」と書かれていれば、636条本文の適用範囲が変わります。逆に指摘が記録に無ければ、但書を主張する材料がありません。

検収の勝敗は、検収の日ではなく、要件定義の議事録の質で決まります。 要件定義の進め方はRFP・要件定義ガイドを参照してください。


4. 期限:637条の「知った時から1年」

注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。

読み違えやすい点を3つ。

  1. 起点は「引き渡し」ではなく「知った時」。検収で見抜けなかった不具合も、後で気づけばそこから1年です。検収を通した=即失権、ではありません。
  2. 必要なのは通知であって提訴ではありません。「不適合があるので対応を求める」という意思表示を、記録の残る方法で送ることが要件です。
  3. 例外:引き渡し時に請負人が不適合を知っていた、または重大な過失で知らなかった場合、この1年制限は適用されません(637条2項)。

実務としては「気づいたらその日のうちにメールで通知し、後から詳細を詰める」が正解です。原因調査が終わるまで通知を待つ必要はありません。


5. 非エンジニアでも実行できる受け入れテストの作り方

ここからは法律ではなく実務です。「中身が読めない」発注者が、それでも検証できる方法を組み立てます。

原則:コードではなく「業務」を検証する。

発注者はコードの品質を判定できません。しかし自分の業務が回るかは誰よりも正確に判定できます。だから受け入れテストは技術項目ではなく、業務シナリオで書きます。

❌ 技術項目で書く(発注者に判定できない)
  - APIのレスポンスが200を返すこと
  - DBのトランザクションが正しく張られていること

✅ 業務シナリオで書く(発注者が判定できる)
  1. 営業担当が外出先のスマホで見積を作成し、送信する
  2. 上長に承認依頼が飛び、上長が承認する
  3. 承認済みの見積が顧客にPDFで届く
  4. 経理が月末に、その月の承認済み見積を一覧で出力できる
  → 4がCSVで出せなければ不合格(要件定義書 3.2 に記載)

シナリオには必ず「要件定義書のどこに書いてあるか」を添えます。 これが無い項目は検収の根拠になりません(そして、要件定義に無いことを検収で要求するのは仕様追加であって、ベンダー側に断る正当性があります)。

さらに、非エンジニアが確認しづらいが業務を壊す4つの観点は、証跡の提出を求める形にします。

観点発注者が求めるもの
異常系「重複送信したらどうなるか」の実演。二重登録されないこと
権限一般ユーザーで管理画面URLを直接開いて、拒否されること
データ量本番相当件数を入れた状態での一覧表示の実演
復旧バックアップからの復元手順書と、復元を実施した記録

これらは「動いて見える」だけでは分からず、しかし壊れると業務が止まります。実演か記録の提出を求めるのが、読めない側の最も合理的な検証手段です。


6. 発注者の側にも法的制約がある(2026年1月施行の新法)

ここは通常の発注ガイドがほぼ触れない領域です。検収は発注者の自由裁量ではありません。

かつて「下請代金支払遅延等防止法(下請法)」と呼ばれていた昭和31年法律第120号は、令和7年5月23日法律第41号により改正され、2026年(令和8年)1月1日から施行されています。現在の題名は「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」で、用語も「親事業者/下請事業者」から「委託事業者/中小受託事業者」に変わりました。

ソフトウェア開発は対象に含まれる

同法2条は「情報成果物」の第一に「プログラム(電子計算機に対する指令であつて、一の結果を得ることができるように組み合わされたもの)」を挙げ、その作成の委託を「情報成果物作成委託」としています。システム開発の外注はここに入ります。

適用されるかどうか(情報成果物作成委託の場合)

委託事業者(発注者)側中小受託事業者(受注者)側
資本金5,000万円超個人 または 資本金5,000万円以下
資本金1,000万円超〜5,000万円以下個人 または 資本金1,000万円以下
常時使用する従業員100人超常時使用する従業員100人以下

3行目に注目してください。従業員数の基準は改正で加わったものです。資本金が小さくても、従業員が100人を超えていれば適用されます。「うちは資本金1,000万円だから関係ない」という従来の判断は、もう成り立ちません

検収に直結する3つの規定

① 支払期日は検査の有無を問わない(3条)

製造委託等代金の支払期日は、委託事業者が中小受託事業者の給付の内容について検査をするかどうかを問わず、委託事業者が中小受託事業者の給付を受領した日から起算して、六十日の期間内において、かつ、できる限り短い期間内において、定められなければならない。

さらに、支払期日を定めなかったときは受領日が、60日を超えて定めたときは受領日から60日を経過した日の前日が、支払期日とみなされます「検収が終わらないから払わない」は成立しません。

② 受領拒否・返品・やり直しの禁止(5条)

5条1項は、中小受託事業者の責めに帰すべき理由がないのに「給付の受領を拒むこと」(1号)、「受領した後、給付に係る物を引き取らせること」(4号)を禁じています。さらに5条2項3号は、責めに帰すべき理由がないのに「給付の内容を変更させ、又は受領した後に給付をやり直させること」で利益を不当に害することを禁じています。

要件定義に無い機能を検収時に要求して修正させる——これは仕様追加であり、条文が想定する「やり直し」に近づきます

③ 遅延利息(6条)

支払期日までに支払わなかった場合、受領日から60日を経過した日から支払日まで、未払金額に公正取引委員会規則で定める率を乗じた遅延利息を支払う義務が生じます。

なぜ発注者にこれを書くのか。 発注者を萎縮させるためではありません。検収を「力で押し切る場」にしないほうが、結果として良いものが手に入るからです。支払を人質にした交渉は、ベンダー側の合理的な対応を「最小限の手直しで逃げ切る」方向に歪めます。期日どおり払い、不適合は民法の枠組みで正面から追及する——このほうが速く、確実です。


7. 補助金を使う場合の検収

補助金を使った開発では、検収は事業完了の証明という追加の役割を負います。実績報告では一般に、契約書・納品書・検収書・請求書・支払を証明する記録の整合が求められます。

決定的なのは日付の順序です。

交付決定 → 契約 → 着手 → 納品 → 検収 → 支払 → 実績報告
   ↑
   ここより前に着手すると、多くの制度で対象外になる

検収書の日付だけを後から辻褄合わせすることは、証拠書類の改ざんに当たり得ます。絶対に避けてください。 スケジュールが厳しいなら、日付を動かすのではなく検収の範囲を段階に分ける(フェーズ検収)ほうが健全です。

なお補助金は原則として精算払い(後払い)なので、検収から入金までのキャッシュフローは別途設計が必要です。制度ごとの使い分けは補助金でシステム開発を外注する完全ガイド、立替期間の資金繰りは補助金は「後払い」— 入金までの資金繰りと支払い設計にまとめています。要求書類は制度・年度で変わるため、必ず当該年度の公募要領で確認してください


8. 検収チェックリスト

発注者が検収の前に確認すべき10項目です。

契約・基準(検収の前に揃っているべきもの)

  • 契約形態が請負か準委任かを確認した
  • 合否基準が要件定義書に文書化されている(検収時に決めていない)
  • 検収期間と、期間内に異議を述べない場合の扱いが契約書に書かれている
  • 発注者側の指図・判断が議事録に残っている(636条対策)

実施

  • 受け入れテストを業務シナリオで書き、各項目に要件定義書の該当箇所を紐づけた
  • 異常系・権限・データ量・復旧の4観点について実演または証跡を受け取った
  • 不合格項目は「いつまでに直すか」を期限付きの書面で催告した(563条の前提)

検収後

  • 支払期日が受領日から60日以内に設定されている(新法が適用される場合)
  • 不適合を見つけたら気づいた日のうちに記録の残る方法で通知する運用を決めた(637条)
  • 補助金を使う場合、交付決定→契約→着手→納品→検収→支払の日付順序が崩れていない

まとめ

検収は「動くかどうかを見る日」ではなく、それまでに積み上げた文書の質が精算される日です。

  • 検収は支払い義務と責任追及の起点を確定させる法律行為。合否基準は要件定義で決まる
  • 民法は追完請求・代金減額・損害賠償/解除の3つを与えるが、減額は原則「期間を定めた催告」が先
  • 636条——発注者の指図が原因の不適合は責任追及できない。だから議事録が武器になる
  • 637条——起点は「知った時」。気づいたら即、記録の残る方法で通知する
  • 2026年1月施行の新法は発注者も縛る。支払期日は検査の有無を問わず受領日から60日以内、従業員100人超の基準も新設された

発注全体の意思決定はシステム開発の発注 完全ガイドに、費用の見方は費用相場と見積もりの見抜き方にまとめています。

よくある質問

検収と受け入れテストは何が違うのですか?
受け入れテストは「仕様どおり動くか」を確かめる技術的な作業で、検収はその結果を踏まえて「成果物を受け入れる」と意思表示する契約上の行為です。順序は受け入れテスト→検収で、逆にはできません。検収書に押印した瞬間に支払い義務が確定し、以後の不具合は契約不適合責任という別のルートで争うことになるため、テストを終える前に検収を通すと交渉上の立場を自ら手放すことになります。
検収を通した後に不具合が見つかったら、もう何も言えないのですか?
言えます。検収の完了と契約不適合責任は別物です。民法562条以下により、引き渡された成果物が契約内容に適合しない場合、発注者は修補などの追完請求、代金減額請求、損害賠償請求、契約解除を求められます。ただし民法637条により、不適合を知った時から1年以内にその旨を通知しないとこれらの権利を失います。「知った時」が起点なので、気づいた時点で速やかに書面で通知することが実務上の要点です。
請負契約と準委任契約で、検収の考え方はどう変わりますか?
大きく変わります。請負(民法632条)は「仕事の完成」を約束する契約なので、完成物が契約内容に適合しているかを検収で判定します。一方、準委任(民法656条)は事務の遂行そのものを引き受ける契約で、特定の成果物の完成を約束していません。したがって準委任では「成果物が仕様どおりか」ではなく「合意した作業が適切に行われたか」を確認することになり、契約不適合責任を前提とした検収は原則としてなじみません。契約形態を確認せずに検収基準だけ作ると噛み合わなくなります。
検収が終わらないことを理由に支払いを止めてよいですか?
発注者が新法(旧・下請法、2026年1月1日施行)の委託事業者に該当する場合、それはできません。同法3条は支払期日について「委託事業者が中小受託事業者の給付の内容について検査をするかどうかを問わず」受領日から起算して60日以内、かつできる限り短い期間内に定めなければならないと規定しています。支払期日を定めなかった場合は受領日が、60日を超えて定めた場合は受領日から60日を経過した日の前日が支払期日とみなされます。検収の引き延ばしは支払を遅らせる法的根拠になりません。
補助金を使って開発する場合、検収で気をつけることはありますか?
実績報告の証拠書類として、検収書・納品書・請求書・支払を証明する記録の整合が求められるのが一般的です。日付の前後関係(交付決定→契約→着手→納品→検収→支払)が崩れていると、事業完了の証明で問題になり得ます。特に「交付決定前の着手」は各制度で厳しく扱われるため、検収書の日付だけを後から辻褄合わせすることは絶対に避けてください。制度ごとに要求書類は異なるので、必ず当該年度の公募要領で確認が必要です。

参考文献

友田

友田 陽大

経済産業大臣賞 受賞プロダクト開発者。TypeScript + Python + AWS で、SaaS・業界DX・実用レベルの生成AI(RAG)を、要件定義からインフラ・運用まで一人で完遂します。

発注で失敗しないために

外注先の技術力を見極める「発注前チェックリスト」を無料配布中

設計・セキュリティ・テスト・運用・契約の5領域20問で、見積書や商談では見えない「技術力の差」を発注前に確認できます。メールアドレスだけで受け取れます。

プロジェクト単位(請負)・技術顧問のどちらにも対応可能です。まずは30分の無料技術相談から。

最短ルート:カレンダーから直接予約

相談内容が固まっている方は、フォーム送信よりその場で日程を確定する方がスムーズです。下記から空き時間をお選びください。

  • 30分のオンライン無料相談
  • Google Meet / Zoom / Microsoft Teams
  • NDA 商談前締結可・無理な営業はいたしません
無料相談の空き枠を予約する

あわせて読みたい