---
title: "検収の進め方：受け入れテストから検収書まで｜アメリア・テクノロジー株式会社"
url: https://www.ameliatechnology.co.jp/blog/acceptance-inspection-howto/
description: "システム開発の検収の進め方を、はじめて発注する方向けに説明します。検収の意味、検査の基準の決め方、受け入れテストの進め方、合格と不合格の扱い、検収の期限、検収の後に見つかった不具合の扱いまでを順に整理します。"
updated: 2026-11-12
publisher: "アメリア・テクノロジー株式会社"
---
# 検収の進め方：受け入れテストから検収書まで

システム開発の検収の進め方を、はじめて発注する方向けに説明します。検収の意味、検査の基準の決め方、受け入れテストの進め方、合格と不合格の扱い、検収の期限、検収の後に見つかった不具合の扱いまでを順に整理します。

2026.11.12 [開発の発注と契約](https://www.ameliatechnology.co.jp/blog/category/outsourcing/)

執筆 [桐谷彰人](https://www.ameliatechnology.co.jp/blog/author/kiritani/)（取締役COO）

開発の発注と契約（OUTSOURCING）のコラム

## この記事の要点

- 検収とは、納品されたものが契約で決めた内容に合っているかを、発注者が確かめて受け入れることです
- 何を確かめれば合格かという基準を、納品の前に開発会社と合意しておくと、検収が進めやすくなります
- 検収の期間内に結果を伝えないと合格とみなす契約もあるため、期間と手順を最初に確かめておきます

検収とは、開発会社から納品されたシステムが、契約で決めた内容に合っているかを発注者が確かめ、受け入れることです。検収が終わると、報酬の支払いや、不具合の責任を負う期間の始まりなど、契約の上で大切なことが動き出します。そのため、何を、いつまでに、どう確かめるかを、前もって決めておくことが大切です。

この記事では、はじめてシステム開発を発注する方に向けて、検収の流れを順に説明します。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」の考え方を参考にしています。

## 検収とは何か

[検収](https://www.ameliatechnology.co.jp/glossary/acceptance-inspection/)とは、納品物を検査し、合格であれば受け入れたことを開発会社に伝える手続きです。請負契約では、報酬は仕事の目的物の引渡しと同時に払うのが原則（民法633条）で、実務では検収の完了を支払いの区切りにしている契約が多く見られます。

IPAのモデル契約書では、開発会社が検収依頼書とともに納入物を納め、発注者が検査の基準（検査仕様書）にもとづいて検査し、合格したら検査合格書を交付する流れになっています。検査に合格したときをもって、検収の完了とする形です。

出典：[民法（e-Gov 法令検索）](https://laws.e-gov.go.jp/law/129AC0000000089)
[情報システム・モデル取引・契約書（第二版）（IPA）](https://www.ipa.go.jp/digital/model/model20201222.html)

## 検査の基準を、納品の前に決めておく

検収をなめらかに進めるには、何を確かめれば合格かという基準を、納品の前に決めておくことが大切です。基準がないまま検収に入ると、「この動きは仕様どおりか」をその場で話し合うことになり、時間がかかります。

IPAのモデル契約書では、発注者が開発会社と相談のうえ、システムの仕様書にもとづいて、テストの項目・テストのデータ・テストの方法・テストの期間などを定めた検査仕様書を作るとしています。開発会社は、それが仕様書に合っているかを確かめて承認します。

基準を決めるときは、次のような点を書き出しておくと進めやすくなります。

- 業務でよく使う操作が、決めた手順どおりに動くか
- 計算の結果や帳票の数字が、正しい値になるか
- 想定していない入力をしたときに、決めたとおりの動きになるか
- 画面の表示の速さなど、機能以外で決めた条件を満たしているか

## 受け入れテストで確かめる

検収の中心になる作業は、[受け入れテスト](https://www.ameliatechnology.co.jp/glossary/acceptance-test/)です。受け入れテストとは、発注者が、実際の業務の流れに沿ってシステムを動かし、使える状態かを確かめるテストです。

開発会社は納品の前に、部品ごとのテストや、全体をつないだテストを済ませています。受け入れテストは、それとは別に、発注者の目で業務に使えるかを確かめるものです。テストの種類の違いは[発注者が知っておきたいテストの種類と確かめ方](https://www.ameliatechnology.co.jp/blog/testing-for-buyers/)で説明しています。

受け入れテストを進めるときは、次の点に気をつけます。

1. 実際にシステムを使う部署の人に参加してもらう
2. 本番に近いデータを使う（個人情報を含むデータは、扱いの決まりに沿って準備する）
3. 見つかった問題は、画面・操作・結果を記録し、一覧で管理する
4. 直してもらった箇所は、もう一度確かめる

IPAのモデル契約書の追補版に載っている検収のチェックリストにも、問題点や直す内容を書面で管理しているか、テストの後に直したソフトウェアをもう一度テストしたか、といった項目が並んでいます。

## 合格と不合格の扱い

検査の結果は、合格か不合格かを、開発会社に書面で伝えます。IPAのモデル契約書では、合格なら検査合格書を交付し、不合格なら不合格の具体的な理由を書いた書面を交付して、修正を求める流れです。開発会社は、決めた期限までに直して納め、発注者は必要な範囲でもう一度検査します。

検査の結果を伝えてから、検収が終わるまで（IPAのモデル契約書の流れ）

- **結果を伝える**：合格か不合格かを、開発会社に書面で伝える
- **合格のとき**：検査合格書を交付する（**検収の完了**）
- **不合格のとき**：具体的な理由を書いた書面を交付し、修正を求める
- **直して納める**：開発会社が決めた期限までに直し、発注者が必要な範囲でもう一度検査する

不合格の理由は、どの基準のどの項目に合わなかったかを具体的に書くと、開発会社も直す箇所を特定しやすくなります。「なんとなく使いにくい」といった理由は、基準に書いていない内容のことが多いため、仕様の変更として別に扱うかどうかを話し合います（[開発の途中で仕様を変えたいときの進め方](https://www.ameliatechnology.co.jp/blog/change-request-handling/)）。

## 検収の期限に気をつける

検収には期間が決められていることが多く、その期間を過ぎたときの扱いに気をつける必要があります。IPAのモデル契約書では、検査期間内に発注者が書面で具体的な理由を示して異議を述べない場合は、検査に合格したものとみなす、としています。

つまり、忙しくて検査ができないまま期間が過ぎると、確かめていないのに合格になってしまうことがあります。検収の期間は、テストの項目の数や、参加する人の予定を考えて、無理のない長さで決めておきます。

また、発注する会社と開発会社の規模によっては、中小受託取引適正化法（取適法）が当てはまることがあります。この法律は、代金の支払期日を、発注者が検査をするかどうかを問わず、給付を受領した日から60日以内の、できる限り短い期間で定めなければならないとしています（第3条）。検収を長引かせても支払いの期日は延びないため、検収の段取りは早めに整えておきます。

出典：[製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律（e-Gov 法令検索）](https://laws.e-gov.go.jp/law/331AC0000000120)

## 検収の後に不具合が見つかったら

検収が終わった後に不具合が見つかることもあります。契約の内容に合わない不具合は、[契約不適合責任](https://www.ameliatechnology.co.jp/glossary/contract-nonconformity/)として、修正などを求められる場合があります。

民法では、請負の注文者は、不適合を知った時から1年以内にその旨を通知しないと、修正などを求められなくなるとされています（637条）。ただし、システム開発の契約書では、検収の完了から何か月以内と、別の期間を決めていることが多いため、自社の契約書を確かめておきます。詳しくは[契約不適合責任とは。期間と請求できること](https://www.ameliatechnology.co.jp/blog/contract-nonconformity-liability/)で説明しています。

検収の段階で、問題の一覧と、直した箇所の記録を残しておくと、後で不具合が見つかったときに、検収の時点ですでにあった問題かどうかを確かめやすくなります。本記事は検収の進め方を一般的に整理したものです。個別の契約書の内容や判断については、弁護士などの専門家にご確認ください。

## 当社のご支援

当社の[Webシステム開発](https://www.ameliatechnology.co.jp/service/web-system/)では、区切りごとに、できたものをお客様と一緒に確かめながら進め、食い違いを早く見つけるようにしています。他社が作ったシステムの受け入れテストの進め方を相談したい場合は、相談や小さな開発を月単位で頼める[AIタイムシェア](https://www.ameliatechnology.co.jp/timeshare/)もご利用いただけます。[お問い合わせ](https://www.ameliatechnology.co.jp/contact/)からお気軽にご相談ください。

- 検収
- 受け入れテスト
- 発注
- 契約

## この記事に出てくる用語

- [検収](https://www.ameliatechnology.co.jp/glossary/acceptance-inspection/)
- [システム開発](https://www.ameliatechnology.co.jp/glossary/system-development/)
- [情報システム・モデル取引・契約書（IPA）](https://www.ameliatechnology.co.jp/glossary/model-contract-ipa/)
- [請負契約](https://www.ameliatechnology.co.jp/glossary/ukeoi-contract/)
- [仕様書](https://www.ameliatechnology.co.jp/glossary/specification/)
- [受け入れテスト（UAT）](https://www.ameliatechnology.co.jp/glossary/acceptance-test/)
- [取適法（中小受託取引適正化法）](https://www.ameliatechnology.co.jp/glossary/toriteki-act/)
- [契約不適合責任](https://www.ameliatechnology.co.jp/glossary/contract-nonconformity/)

## 関連する法令・指針（参考情報）

- 法令
   民法第633条（報酬の支払時期）
   請負の報酬は、仕事の目的物の引渡しと同時に支払うのが原則です。
   明治29年法律第89号 [e-Gov 法令検索で開く](https://laws.e-gov.go.jp/law/129AC0000000089)
- 法令
   民法第637条（目的物の種類又は品質に関する担保責任の期間の制限）
   注文者は、不適合を知った時から1年以内にその旨を請負人に通知しないと、追完・報酬の減額・損害賠償・解除を求められなくなります。引渡しの時に請負人が不適合を知っていたか、重大な過失で知らなかったときは、この制限は適用されません。
   明治29年法律第89号 [e-Gov 法令検索で開く](https://laws.e-gov.go.jp/law/129AC0000000089)
- 法令
   中小受託取引適正化法第3条（製造委託等代金の支払期日）
   代金の支払期日は、委託事業者が給付の内容を検査するかどうかを問わず、給付を受領した日から60日以内の、できる限り短い期間で定めなければなりません。
   製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律・昭和31年法律第120号 [e-Gov 法令検索で開く](https://laws.e-gov.go.jp/law/331AC0000000120)
- 指針
   独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書」（第二版（2020年12月22日））
   情報システムの受託開発（一部の企画を含む）と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。
   [発行元の公式ページで開く](https://www.ipa.go.jp/digital/model/model20201222.html)

法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは[法令・指針の参考情報と凡例](https://www.ameliatechnology.co.jp/knowledge/legal/)をご覧ください。

この記事を書いた人

[桐谷彰人](https://www.ameliatechnology.co.jp/blog/author/kiritani/) 取締役COO

システムエンジニアとして、ビジネスモデルの策定から要件定義、開発、コードレビューまでを担当してきました。運送管理、飲食業向けのDX、ECサイトなど、さまざまな業界のシステム開発に携わっています。

このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。

## あわせて読みたい

- [開発会社を替えるときの引き継ぎと、そろえておく資料](https://www.ameliatechnology.co.jp/blog/vendor-switch-handover/)
- [取適法（中小受託取引適正化法）とシステム開発の発注](https://www.ameliatechnology.co.jp/blog/toriteki-act-system-development/)
- [システム開発の成果物の著作権は誰のものか](https://www.ameliatechnology.co.jp/blog/software-copyright-ownership/)

[開発の発注と契約のコラムを見る](https://www.ameliatechnology.co.jp/blog/category/outsourcing/) [コラムの一覧に戻る](https://www.ameliatechnology.co.jp/blog/)

## 次の一歩

### 現場に入るチームに任せる

技術者がお客様の現場に入り、要件定義から開発・運用までを担います。

[FDEを見る](https://www.ameliatechnology.co.jp/fde/)

### まずは30分、オンラインで話してみる

何に使うかが決まっていない段階でも構いません。30分のオンライン相談は無料です。

[無料で相談する](https://www.ameliatechnology.co.jp/contact/)

## ご関心に合わせて、お選びください。

[情報を集めている方へ会社案内、AI開発の例、セキュリティ診断の報告書の見本をお送りします。資料をダウンロード](https://www.ameliatechnology.co.jp/download/)[課題が見えている方へオンラインで30分、お話をうかがいます。費用はかかりません。無料で相談する](https://www.ameliatechnology.co.jp/contact/)[進め方を決めたい方へ2〜4週間で、優先順位と計画をまとめるAI活用の診断です。診断について見る](https://www.ameliatechnology.co.jp/pricing/#diagnosis)

---

出典：アメリア・テクノロジー株式会社「検収の進め方：受け入れテストから検収書まで｜アメリア・テクノロジー株式会社」 https://www.ameliatechnology.co.jp/blog/acceptance-inspection-howto/