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

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

- 公開日: 2026-09-05
- 著者: 友田 陽大
- タグ: システム開発, 発注, 受託開発, 要件定義, DX
- URL: https://tomodahinata.com/blog/system-development-acceptance-inspection-guide
- カテゴリ: 発注・内製化・コスト
- 総合ガイド: https://tomodahinata.com/blog/system-development-outsourcing-guide-vendor-selection-cost

## 要点

- 検収は品質判定ではなく「支払い義務」と「責任追及の起算点」を同時に確定させる行為。だから合否の基準は検収時ではなく要件定義の時点で決まっていなければならない
- 民法は発注者に3つの武器を与える——追完請求(562条)・代金減額(563条)・損害賠償と解除(564条)。ただし減額は原則として『相当の期間を定めた催告』が先で、無催告で使えるのは4つの例外だけ
- 最大の落とし穴は636条。発注者が出した材料や指図が原因の不適合は、原則として責任を追及できない。だから『誰がその仕様を決めたか』の記録が検収より前に効いてくる
- 637条により、不適合を知った時から1年以内に通知しないと権利を失う。検収で見抜けなくても即失権ではないが、起点は『知った時』なので放置は危険
- 2026年1月1日施行の新法（旧・下請法）は発注者も縛る。支払期日は『検査をするかどうかを問わず』受領日から60日以内で、検収の引き延ばしは支払遅延の理由にならない

---

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

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

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

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

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

---

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

先に要点を置きます。

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

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

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

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

---

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

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

**請負**（民法632条）:

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

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

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

つまり——

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

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

---

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

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

### ① 追完請求（562条）

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

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

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

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

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

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

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

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

### ③ 損害賠償請求・契約解除（564条）

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

---

## 3. 最大の落とし穴：民法636条（発注者の指図）

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

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

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

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

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

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

**検収の勝敗は、検収の日ではなく、要件定義の議事録の質で決まります。** 要件定義の進め方は[RFP・要件定義ガイド](/blog/system-development-rfp-requirements-definition-guide)を参照してください。

---

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

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

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

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

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

---

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

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

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

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

```text
❌ 技術項目で書く（発注者に判定できない）
  - 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. 補助金を使う場合の検収

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

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

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

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

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

---

## 8. 検収チェックリスト

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

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

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

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

---

## まとめ

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

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

発注全体の意思決定は[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)に、費用の見方は[費用相場と見積もりの見抜き方](/blog/system-development-cost-estimate-market-rate-guide)にまとめています。
