先に、要点をまとめます。
- 受入テストは、納品されたシステムが自社の業務で使えるかを、発注した会社が自分で確かめる工程です。 開発会社が行うシステムテストとは目的も担当も違い、検収（契約上の合格の確認）の判断材料になります。
- 発注側が用意するのは、業務シナリオ、テストデータ、合格基準の3つです。 開発会社はテスト環境や手順書づくりを支援できますが、「この結果で業務が回るか」は発注側にしか判断できません。
- 検査期間と、期間内に異議を出さなかったときの扱いを契約で確認しておきます。 IPAのモデル契約では、期間内に書面で異議を述べなければ合格とみなす条項が置かれています。
2026年10月15日時点で、IPA（情報処理推進機構）の公開資料と民法の条文を確認した内容です。契約条項は個別の契約書が優先します。自社の契約書の該当条項とあわせてお読みください。
受入テストとは？検収とは何が違いますか？
受入テストは「業務で使えるか」を発注側が確かめる作業で、検収はその結果をもとに「契約どおりに納品された」と発注側が認める手続きです。
システム開発のテストは、一般に単体テスト・結合テスト・システムテスト・受入テストの順に進みます。前の3つは開発会社が、作った部品やシステム全体が設計どおりに動くかを確かめるものです。受入テストは最後の工程で、発注した会社の担当者が、普段の業務の流れに沿って操作して確かめます。
IPAが公開している情報システム・モデル取引・契約書（第二版）は、ユーザ企業とITベンダの間の取引を透明にする目的でIPAが公開している、契約書のひな型です。このひな型では、受入と検収の流れを次のように定めています。
| 条項 | 定めている内容 |
|---|---|
| 第27条（検査仕様書の作成及び承認） | ユーザ（発注側）が、ベンダと協議のうえ、テスト項目・テストデータ・テスト方法・テスト期間等を定めた検査仕様書を作成する |
| 第28条（本件ソフトウェアの検収） | ユーザは契約で定めた検査期間内に検査仕様書に基づいて検査し、合格なら検査合格書を交付する。不合格なら具体的な理由を書面で示し、ベンダは期限内に無償で修正する |
| 第28条第3項 | 検査期間内に書面で具体的な理由を示して異議を述べない場合は、検査に合格したものとみなす |
| 第28条第4項 | 検査合格をもって検収完了とする |
ここから読み取れるのは、受入テストの準備は発注側の役割として書かれていること、そして期間を過ぎると不合格を主張する機会がなくなる形になっていることです。実際の契約がこのひな型どおりとは限りませんが、自社の契約書で「検査期間」「合否の通知方法」「みなし合格」の3点を探すと、受入テストにかけられる時間と締め切りが分かります。
発注者は何を用意すればよいですか？
業務シナリオ、テストデータ、合格基準の3つです。どれも、自社の業務を知っている人でないと書けません。
既存システムを移行したいについて相談する老朽化した業務システム、限界がきたSaaS、連絡の取れない開発会社が作ったシステムを、業務を止めずに引き取って作り変える受託開発既存システムを移行したいを見る →開発会社のシステムテストは、仕様書に書かれた機能が動くかを確かめます。一方で「月末の締めのあとに返品が入ったらどうするか」のように、業務の流れの中で初めて出てくる確認は、仕様書の機能一覧からは作れません。受入テストの価値はここにあります。
業務シナリオは、画面ごとの確認ではなく、1件の取引が始まってから終わるまでを追う形で書きます。以下は卸売の受注から請求までを題材にした確認例です。当社が受託した案件の内容ではありません。自社の業務に置き換えて書いてください。
| シナリオ | 操作の流れ | 期待する結果 | 確認者 |
|---|---|---|---|
| 通常の受注 | 受注入力 → 在庫引当 → 出荷指示 → 出荷完了 → 請求書発行 | 在庫が出荷数だけ減り、請求書の金額が受注と一致する | 受注担当、倉庫責任者 |
| 分納 | 在庫不足の受注を2回に分けて出荷 | 残数が残り、2回目の出荷後に受注が完了になる | 受注担当 |
| 締め後の返品 | 月末締めのあとに前月出荷分の返品を登録 | 前月の請求は変わらず、当月の請求で差し引かれる | 経理担当 |
| 単価の改定 | 単価改定日をまたぐ受注を入力 | 出荷日ではなく、自社のルールで決めた日付の単価が使われる | 営業責任者 |
| 権限 | 倉庫担当のアカウントで単価を変更しようとする | 変更できない、または承認待ちになる | システム担当 |
確認者の欄を埋めると、受入テストに誰の時間が必要かが見えてきます。業務ごとに判断できる人が違うため、1人の担当者がすべてを確認する計画は、結果の判断が止まりやすくなります。
物流・卸売の業務でどこまでをテストの工数として見込むかは、物流システム開発の費用と期間でも扱っています。
テストデータはどう作ればよいですか？
本番に近い件数と内容のデータに、例外のデータを意図的に混ぜて作ります。きれいなサンプルデータだけでは、業務で困る場面を確かめられません。
テストデータは、次の3種類を組み合わせると漏れが減ります。
- 通常のデータ: 普段の取引の典型。件数は実際の1日分や1か月分に近づけ、一覧の表示速度や帳票の改ページも確かめる
- 例外のデータ: 分納、返品、取消、締め日をまたぐ取引、税率や単価の切り替え日をまたぐ取引など、年に数回しか起きないが起きると手作業になるもの
- 移行データ: 旧システムから移したデータ。件数・金額の合計・コードの対応が旧システムと一致するかを確かめる
本番の顧客情報や個人情報をそのままテスト環境に入れるかは、テストの前に決めておく項目です。氏名や連絡先を置き換えたデータで足りるのか、本番データでないと確かめられない項目があるのかを、開発会社と相談して決めます。テスト環境に入れるデータの範囲と、テスト後に消去する手順も記録しておきます。
既存システムからの移行を伴う場合、移行データの照合は受入テストの中でも時間がかかる部分です。照合の項目と旧システムを止める判断は、レガシーシステム刷新の進め方で整理しています。
合格基準はどう決めますか？
「見つかった問題をどう分類し、どの分類が残っていたら不合格にするか」を、テストを始める前に決めます。
受入テストで見つかる指摘は、性質の違う3つが混ざります。これを分けずに一覧にすると、修正の費用を誰が持つかで話が止まります。
受入テストの流れ。契約時に検査期間と合否の通知方法を確認し、業務シナリオ・テストデータ・合格基準を用意して実施する。指摘は不具合・仕様との差・要望に分けて扱い、合格の通知で検収が完了する
| 分類 | 判断の目安 | 主な扱い |
|---|---|---|
| 不具合 | 合意した仕様のとおりに動かない | 開発会社が修正し、該当シナリオを再確認する |
| 仕様との差 | 仕様のとおりに動くが、仕様そのものが業務と合っていない | 仕様変更として、費用・納期への影響を確認してから対応を決める |
| 要望 | 動作に問題はないが、使いやすくしたい | 本稼働後の改善として記録し、優先順位をつける |
合格基準は、この分類と業務への影響を組み合わせて決めます。たとえば「業務が止まる不具合が残っていないこと」「回避手順がある不具合は、修正の期限を決めたうえで合格とする」のように書いておくと、テストの終盤で判断が割れにくくなります。何を「業務が止まる」とみなすかは、出荷や請求など、止まると取引先に影響する処理から決めていきます。
「仕様との差」が多く出る場合は、要件を固める段階で業務の例外を拾いきれていなかった可能性があります。画面を見ながら要件を合わせる進め方は、仕様書なしで開発相談する方法で紹介しています。
期間と体制はどれくらい見込めばよいですか？
期間は、シナリオの数、確認者が通常業務と兼務できる時間、修正と再確認の往復回数で決まります。日数の決め打ちより、この3つを先に見積もります。
受入テストの期間でよく足りなくなるのは、確認者の時間です。業務の担当者は通常業務を続けながらテストに参加するため、繁忙期や月末の締めと重なると、確認が進みません。テストの日程は、確認者の予定を先に押さえてから組みます。
あわせて、次の点を開発会社と決めておきます。
- 検査期間の起算日: 納品の連絡を受けた日か、テスト環境で操作できるようになった日か
- 再検査の範囲: 修正後に、修正した箇所だけを確認するのか、関連するシナリオも確認し直すのか
- 合否を通知する人: 社内で誰が最終的に合格を判断し、どの方法で開発会社へ伝えるのか
- 指摘の受け渡し方法: 画面の写し、操作の手順、使ったデータを1件ずつ記録する様式
指摘の記録には、「どのシナリオの、どの操作で、何を入力したら、何が起きたか」を残します。この4点が揃っていれば、開発会社は同じ現象を再現して原因を調べられます。
検収後に問題が見つかったらどうなりますか？
請負契約で作られたシステムの場合、合意した仕様と違う点は、契約で定めた期間内に通知すれば修正などを求められます。期間は契約ごとに違うため、検収の前に確認しておきます。
民法第637条は、請負の目的物が契約の内容に適合しない場合、注文者がそれを知った時から1年以内に請負人へ通知しないと、修正の請求や報酬の減額などを求められなくなると定めています。IPAのモデル契約の第29条は、検収完了後の一定期間内に通知された場合に限ってベンダが責任を負う形にしており、その期間は契約ごとに空欄を埋める書式です。
実際の期間や対象は契約書によって異なり、要件定義などを準委任で契約している部分は扱いが変わります。判断に迷う条項がある場合は、契約前に法務の担当者や専門家に確認してください。
もう1つ分けておきたいのが、契約不適合として扱う修正と、保守契約の範囲で対応する作業です。納品後の不具合対応、設定の変更、機能の追加をどの契約で扱うかは、システムの納品物・保守範囲を確認するチェックリストで項目ごとに整理できます。
開発会社にはどこまで任せられますか？
テスト環境の用意、手順書の作成、操作の説明、指摘の再現と修正は任せられます。シナリオの中身と合否の判断は、発注側に残ります。
IPAのモデル契約でも、ベンダの業務は「導入・受入支援」と書かれ、検査仕様書の作成をベンダに手伝ってもらう場合は別の契約として結べる形になっています。発注側が何も用意しなくても進むものとして、受入テストを考えないほうが安全です。
当社では、見積もりの段階で受入確認を開発とは別の作業として分け、確認者、合格条件、不具合の修正と仕様追加の区別をお客様と確認します。作業単価は 1時間11,000円（税込） で、要件定義・契約後のすり合わせ・開発・テスト・バッファの時間を積み上げて見積もります。受入テストで見込む作業が見積書のどこに入っているかの読み方は、システム開発の見積書の読み方をご覧ください。
よくある質問
Q. 受入テストは開発会社に代わりにやってもらえますか？
テスト環境の準備、手順書の作成、操作の補助は依頼できます。ただし、業務の結果として正しいかどうかは、発注側の担当者でないと判断できません。シナリオと合格基準は発注側が決め、作業の補助を開発会社に頼む分担が現実的です。
Q. 検査期間中に確認が終わらないときはどうすればよいですか？
期間の延長が必要になった時点で、理由と残っているシナリオを書面で開発会社へ伝え、延長を合意します。IPAのモデル契約のように、期間内に異議を述べないと合格とみなす条項がある場合、何も伝えずに期間を過ぎるのは避けてください。
Q. 受入テストで見つかった修正は、すべて無償になりますか？
合意した仕様どおりに動かない不具合について、IPAのモデル契約では、ベンダが期限内に無償で修正すると定めています。自社の契約書の該当条項も確認してください。仕様どおりに動いているが業務と合わない点や、使いやすさの改善は、仕様変更や追加開発として費用と納期を相談します。分類はテストを始める前に開発会社とすり合わせておきます。
受入テストの準備から相談する
業務シナリオが書けていなくても、相談はできます。対象の業務、確認できる担当者、本稼働させたい時期の3点が分かれば、受入確認にかかる作業を見積もりに含められます。見積もり範囲の検討シートで受入確認の行から書き始め、分からない項目は空欄のまま残してください。新しく業務システムを作る場合は、新規開発のご相談から内容をお聞かせください。
運営・編集