受入テスト（UAT）とは？進め方と合否基準・システムテストとの違いを発注者向けに解説

受入テストは、開発会社から納品されたシステムを発注者が自分たちの業務で動かし、受け取ってよいかを決めるテストです。英語での名称はUser Acceptance Testingで、その略称がUATです。本記事では、システムテストとの違い、計画から検査合格書の交付までの進め方、合否基準を数値で決める方法を順に整理します。後半では、IPAのモデル契約が定める検査期間とみなし合格、検収後に見つかった不具合の扱いまで、発注者が契約前に押さえておく点を解説します。

まとめ：受入テストは発注者が合否基準を先に決めて業務の流れで確かめる工程

受入テストの主体は発注者です。開発会社がシステムテストで仕様どおりに動くことを確かめたあと、発注者の業務担当が実際の業務シナリオで操作し、業務に使えるかを判断します。

結果を左右するのは、テストを始める前に合否基準を数値で決めておけるかどうかです。「業務が止まる不具合は0件」「回避策のある不具合は件数と修正期日を合意」のように重大度別の基準を置けば、判定会議で揉めません。契約面では、検査期間内に書面で異議を出さないと合格とみなされる条項が一般的なので、業務担当の工数と期間を先に確保します。テストケースの作成まで開発会社に任せきりにする進め方は避けてください。

受入テストとは何か｜システムテストとの違いと発注者が主体になる理由

受入テストは、テスト工程の最後に置かれる段階です。名前は似ていても、それまでのテストとは目的も実施者も変わります。

受入テストの定義と目的｜業務で使えるかを想定ユーザーが確かめる工程

JSTQBのFoundation Levelシラバス（V4.0・2023年4月12日版）は、2.2.1節で受け入れテストを「妥当性確認と、デプロイの準備ができていることの実証に焦点を当てる」テストレベルと説明しています。システムがユーザーのビジネスニーズを満たしているかを確かめるもので、想定ユーザーが実施するのが理想とされています。

言い換えると、受入テストが答える問いは「仕様どおりか」ではなく「この業務に使えるか」です。仕様書どおりに作られていても、締め日の処理に3時間かかる、帳票の並び順が現場の運用と合わないといった問題は、業務を知る人が触らないと見つかりません。日本の現場では「受入テスト」「受け入れテスト」「ユーザーテスト」「UAT」が同じ工程を指して使われています。

システムテストとの違い｜実施者・テストベース・見つける欠陥の比較表

受入テストの1つ手前にあるシステムテストとは、次の点で役割が分かれます。

受入テストで機能の誤りが大量に見つかる場合、システムテストが十分でなかった兆候です。その状態で受入テストを続けても、業務担当の時間が不具合の報告に消えるだけなので、いったん開発会社へ差し戻す判断も必要になります。テスト工程全体の流れとV字モデルの対応はシステム開発のテスト工程とは？種類・流れとV字モデルで解説しています。

UAT・運用受け入れ・契約による受け入れなど受入テストの5つの形式

JSTQBシラバスは、受け入れテストの主な形式として次の5つを挙げています。

• ユーザー受け入れテスト（UAT）：業務担当が業務シナリオで確かめる
• 運用受け入れテスト：バックアップ・障害時の復旧・監視など運用面を確かめる
• 契約および規制による受け入れテスト：契約の受入基準や法令・業界規制への適合を確かめる
• アルファテスト：開発元の環境で、想定ユーザーが使ってみる
• ベータテスト：利用者自身の環境で、限られた利用者が先行して使う

受託開発の業務システムで発注者が担うのは、主にUATと契約による受け入れテストです。アルファテストとベータテストは、パッケージ製品やアプリを不特定の利用者へ出す場面で使われます。日本の現場で「運用テスト」と呼ぶ工程は、運用受け入れテストに業務の移行リハーサルを加えたもので、受入テストのあとに本番環境で行うことが多い工程です。

受入テストの進め方｜計画から検査合格書の交付までの6つの手順

受入テストは、テスト期間に入ってから準備を始めると間に合いません。全体の流れは次の6手順です。

1. 受入テスト計画を作り、範囲・体制・期間・合否基準を決める
2. 業務シナリオに沿ってテストケースを作り、開発会社と内容を確認する
3. テスト環境・テストデータ・利用者アカウントを準備する
4. テストを実施し、不具合を重大度付きで報告する
5. 修正版で再テストし、判定会議で合否を決める
6. 合格なら検査合格書を交付し、不合格なら理由を書面で通知する

以下では、発注者が判断を迫られる手順1〜5を掘り下げます。手順6の書面の扱いは、契約の章で解説します。

受入テスト計画｜範囲・体制・期間と開始基準を決める最初の工程

計画で決めるのは、どの業務を確かめるか、誰が何日テストに入るか、いつまでに合否を出すかの3点です。テスト担当には、その業務を日常的に担当している人を各部門から最低1人ずつ割り当てます。情報システム部門だけで実施すると、現場の運用との食い違いが見つかりません。

開始基準も計画に書いておきます。JSTQBシラバスの5.1.3節は、典型的な開始基準として、人・環境・テストデータなどのリソースがそろっていることや、スモークテストがすべて合格していることを挙げています。受託開発に当てはめると「システムテストの完了報告書を受領している」「主要画面にログインして登録できる」が受入テスト開始の条件です。満たさないまま始めると、ログインできない、画面が開かないといった報告だけで初日が終わります。

業務シナリオで書くテストケース｜1日の業務と月末処理を通しで確かめる

受入テストのテストケースは、画面ごとではなく業務の流れごとに書きます。受注管理なら「電話で受けた注文を登録し、在庫を引き当て、出荷指示を出し、請求書を発行する」までを含めた一連の流れが、1本のシナリオです。画面単位の確認はシステムテストで済んでいるので、受入テストでは画面と画面のつなぎ目、部門をまたぐ受け渡しに時間を割きます。

見落とされやすいのは、毎日ではない処理です。月末締め、年度替わり、消費税率や単価の改定、担当者の異動による権限の付け替えは、通常業務のシナリオだけでは通りません。業務カレンダーを見て、1か月と1年の周期で発生する処理をシナリオに加えます。テストケースの記載項目と書き方はテスト仕様書とは？書き方とテストケースの項目・発注者がレビューで見る観点で詳しく扱っています。

テスト環境とテストデータの準備｜本番相当のデータと権限の用意

受入テストの環境は、本番と同じ構成・同じデータ量に近づけます。テスト用に作った10件の取引先データでは、検索が遅い、一覧の表示が崩れるといった問題が出ません。既存システムからの移行がある案件では、移行リハーサルで作ったデータを受入テストに使うと、移行データの不備も同時に見つかります。

実データを使う場合は、個人情報の扱いを先に決めておきます。氏名・電話番号・口座番号を加工したデータを使うのか、本番相当のアクセス管理をかけた環境で実データを使うのかで、準備の工数が変わるためです。利用者アカウントは役職・部門ごとに用意し、権限による表示の違いも確かめられるようにします。

実施・不具合報告・再テストの回し方｜重大度の付け方と判定会議

不具合は、見つけた人が重大度を付けて報告します。重大度は「A：業務が止まる」「B：回避策があり業務は続けられる」「C：表示や文言の軽微な問題」の3段階程度で報告を整理できれば十分です。報告には操作手順、期待した結果、実際の結果、画面の画像を添え、開発会社が再現できる形にします。

報告された不具合は、発注者と開発会社が週1〜2回の判定会議で1件ずつ確認し、不具合か仕様変更か、修正するか見送るかを決めます。修正版を受け取ったら、直した箇所だけでなく、その修正が影響しうる周辺の業務シナリオも流し直してください。修正のたびに確かめる範囲の選び方はリグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断にまとめています。

受入テストの合否基準｜終了基準を数値で決めて判定を揉めさせない方法

受入テストで最も揉めるのは、合格か不合格かの判断です。「業務に支障がないこと」とだけ決めて始めると、判定会議で発注者と開発会社の解釈が割れます。

合否基準の項目例｜シナリオ実施率と未解決不具合の件数を重大度別に置く

JSTQBシラバスの5.1.3節は、典型的な終了基準として、達成したカバレッジ、未解決欠陥の数、不合格になったテストケースの数などの測定値と、計画したテストを実行したといった完了の条件を挙げています。受入テストの合否基準も、この形で数値にして計画書に書きます。

件数の上限は案件の規模と稼働日までの余裕で決めるもので、表の値は一例です。大切なのは数字そのものより、テスト開始前に発注者と開発会社が同じ表に合意していることです。合意した基準は計画書に版数付きで残し、途中で変える場合も会議で決めて記録します。

不具合と仕様変更の切り分け｜要件定義書に書かれているかで判定する

受入テストで出てくる指摘の多くは、実は不具合ではありません。「この項目も一覧に出してほしい」「承認の順番を変えたい」といった要望は、要件定義書に書かれていなければ仕様変更として扱います。判定の物差しは、要件定義書・設計書に書かれた内容と食い違っているかどうかです。

この切り分けを曖昧にすると、仕様変更が不具合として無償修正の扱いで積み上がり、開発会社との関係が悪化するか、稼働日が延びます。仕様変更と判定した指摘は、稼働前に入れる必要があるものと、稼働後の改修に回すものに分け、費用と期日を別途見積もってもらいます。

条件付き合格の扱い｜残存不具合を抱えたまま本番稼働させる判断

すべての基準を満たせないまま稼働日が来ることもあります。JSTQBシラバスは、時間切れや予算切れも終了基準として妥当な場合があり、ステークホルダーが本稼働させるリスクをレビューして受け入れたのであれば、テストを終えることは許容されると述べています。

条件付きで合格にするなら、残っている不具合の一覧、それぞれの回避策、修正の期日、修正版を確かめる担当者を書面にして双方で署名します。重大度Aが残っている状態での稼働は避けてください。業務が止まる不具合を回避策なしで抱えたまま切り替えると、旧システムへ戻す判断まで必要になります。残存不具合を移行判定会議でGo／No-Goにどう反映するかはカットオーバーとは？本番切替の計画と移行判定会議の基準・切り戻しの決め方を参照してください。切替と切り戻しの計画はシステム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準で整理しています。

契約から見た受入テスト｜検査期間・みなし合格と検収後の不具合対応

受入テストは、契約上は「検査」として扱われ、その合格が検収になります。IPAと経済産業省がまとめた情報システム・モデル取引・契約書（第二版）を例に、発注者が押さえる条項を確認します。

モデル契約第28条の検査期間｜異議を出さないと合格とみなされる規定

モデル契約の第28条では、発注者（甲）は個別契約で定めた検査期間内に、検査仕様書に基づいてソフトウェアを検査します。合格なら検査合格書を交付し、不合格なら具体的な理由を書いた書面を速やかに渡して修正を求めます。不合格の理由が認められれば、開発会社（乙）は協議で決めた期限内に無償で修正して納入し、発注者は必要な範囲で再び検査する流れです。

見落とされやすいのが第3項です。検査合格書を交付していなくても、検査期間内に書面で具体的な理由を示して異議を述べなければ、検査に合格したものとみなされます。そして第4項が定める検収完了の時点は、検査に合格した時点です。業務担当の時間が取れずに受入テストが終わらなかった場合でも、期間が過ぎれば検収は成立します。検査期間は、業務シナリオを一巡して再テストまで終えられる日数で個別契約に書いてください。検査の基準になる検査仕様書の作り方（第27条）はテスト仕様書の解説記事の後半で扱っています。

検収後に見つかった不具合｜契約不適合責任と通知期間の契約上の扱い

受入テストに合格したあとで不具合が見つかった場合は、第29条の契約不適合責任で扱います。システム仕様書との不一致（バグを含む）が見つかれば、発注者は修正などの追完を請求できます。開発会社が責任を負うのは、検収完了後の一定期間内に発注者が通知した場合に限られ、その期間はモデル契約では空欄で、当事者が個別に決める形です。

この期間が短いと、年1回しか動かない年度更新の処理で不具合が見つかったときに、通知が間に合いません。受入テストで確かめられなかった周期処理がある場合は、その処理が初めて動く時期まで期間を確保するか、稼働後の確認を条件に含めておきます。民法改正で瑕疵担保責任から契約不適合責任に変わった経緯は瑕疵担保責任とは？契約不適合責任への改正とシステム開発契約での扱いを、検収日の会計上の意味は検収とは？検収日の意味と受入検査との違いを参照してください。

受入テストで発注者が陥る失敗例｜丸投げ・兼務・全件確認の3つの型

受入テストの失敗は、テストの技法よりも発注者側の体制で起きます。採るべきでない進め方を、条件付きで挙げます。

テストケースの作成から実施まで開発会社に任せきりにする発注者の失敗

業務担当が忙しいからと、受入テストのテストケース作成も実施も開発会社に任せる進め方は採りません。開発会社は要件定義書の範囲で確かめることしかできず、要件定義で漏れた業務はテストにも出てこないためです。結果として、受入テストは合格したのに稼働初日に現場が回らない、という事態になります。

開発会社に任せてよいのは、テストケースの叩き台作成、テスト環境の準備、不具合の記録と集計までです。業務シナリオの選定、期待結果の確認、合否の判断を担うのは発注者です。社内に受入基準を書ける担当がいない場合は、発注者側に立って要件定義から受入基準づくりまでを支える体制を外部に求める方法があります。一創の要件定義・RFP作成・PMO支援では、要件定義書の整備から受入テストの計画・合否基準のレビューまでを発注者側で支援しています。

業務担当の工数を確保しない計画｜通常業務と兼務で消化率が落ちる

受入テストの期間に、業務担当を通常業務と兼務のまま割り当てると、シナリオの実施が後ろへずれ込みます。月末や繁忙期と重なれば、テストはほぼ停止した状態です。計画の段階で、担当者ごとに「週に何時間テストに入るか」を上長の承認付きで決め、繁忙期を避けた日程を組みます。

前の章で見たとおり、検査期間を過ぎれば合格とみなされる契約が一般的です。工数を確保できないなら、受入テストの期間を延ばす交渉を契約前に済ませておきます。

受入テストで全件を確認しようとする過剰な検査｜システムテストとの重複

反対に、不安から全画面・全項目を受入テストで確かめようとするのも失敗です。入力欄の桁数チェックやエラー文言の確認は、開発会社のシステムテストの領分で、発注者が同じことを繰り返しても新しい問題はほとんど見つかりません。

受入テストは、業務の主要シナリオ、金額と権限が絡む処理、外部システムとの連携に絞ります。システムテストの品質に不安があるなら、受入テストを厚くするのではなく、システムテストの結果報告書で要件ごとのテスト件数と不具合の収束状況を確認し、足りなければ開発会社に追加を求める方が工数を抑えられます。

受入テストの期間・実施者・修正費用について発注者からよくある質問

受入テストの計画や契約について、発注者から寄せられやすい質問に回答します。

受入テストと受け入れテスト、UATは同じ意味ですか？

同じ工程を指しています。「受入テスト」「受け入れテスト」は表記の違いで、UATはUser Acceptance Testingの略です。厳密には、JSTQBシラバスが受け入れテストの形式としてUAT・運用受け入れテスト・契約および規制による受け入れテストなどを分けており、UATはその中の業務担当による確認を指します。受託開発の現場では、これらをまとめて受入テストと呼ぶことが多く、契約書では「検査」と書かれます。

受入テストの期間はどれくらい確保すればよいですか？

一律の目安はなく、業務シナリオを一巡し、見つかった不具合の修正版で再テストまで終えられる日数で決めます。月末締めや月次の集計がある業務では、テスト期間の中に月末の処理を含めるか、日付を進めて月末処理を再現できる環境を用意します。決めた日数は個別契約の検査期間に書き、期間内に終わらない見込みが出た時点で延長を書面で協議してください。

受入テストは誰が実施するのですか？

発注者の業務担当が実施します。JSTQBシラバスでも、受け入れテストは想定ユーザーによる実施が理想とされています。情報システム部門は計画と進行管理を受け持ち、各部門の実務担当が業務シナリオを操作する分担が一般的です。開発会社はテスト環境の準備や不具合の受付・修正を担当し、立ち会いを求めることもできますが、合否の判断は発注者が行います。

受入テストで見つかった不具合の修正費用は誰が負担しますか？

要件定義書や設計書のとおりに作られていない不具合であれば、開発会社が無償で修正するのが一般的です。IPAのモデル契約第28条も、不合格の理由が認められるときは開発会社が無償で修正して納入すると定めています。一方、要件定義書に無い要望を受入テストの段階で追加する場合は仕様変更になり、追加の費用と期日を見積もってもらう対象です。

アジャイル開発では受入テストをどう行いますか？

リリースの最後にまとめて行うのではなく、ユーザーストーリーごとに受け入れ基準を決め、スプリントの中で確かめていきます。JSTQBシラバスの4.5節が紹介しているのは、受け入れ基準をテスト条件として扱い、受け入れテスト駆動開発（ATDD）でテストを先に書く進め方です。請負契約で発注する場合は、スプリントごとの確認とは別に、全体の検収をどの基準で行うかを契約で決めておきます。

関連記事

• システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定の手順：受入テストより前の工程で品質をどう測り、判定するかをまとめています。
• 準委任契約とは？請負・派遣との違いとシステム開発での使い分け：検収の有無が変わる、請負と準委任の契約の違いを解説しています。
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：受入テストの計画や進行管理を外部に任せるかの判断材料になります。
• 納品とは？システム開発の成果物・検収との違いと契約別の扱い：受入テストの前提になる納品と成果物の扱いを整理しています。