受入テスト（UAT）とは？意味・仕組みと使い方

受入テスト（UAT）とは

受入テストとは、システムが、発注した側や実際の利用者の求める条件を満たしているかを、受け入れる側が確認する最終段階の試験です。UAT（User Acceptance Test）とも呼ばれます。

開発側が行うテストは「設計どおりに作られているか」を確認しますが、受入テストは「業務で実際に使えるか」を確認します。両者は目的が異なり、前者が通っても、後者で問題が見つかることがあります。

この試験に合格することは、成果物を受け入れ、検収（納品の確認）に進むための条件になることが一般的です。

仕組み・ポイント

受入テストの進め方は次のとおりです。

受入条件の確認：要件定義で決めた完了の条件を基準にする
シナリオの作成：実際の業務の流れに沿った確認項目を作る
実施：実際の利用者または業務の担当者が、本番に近い条件で操作する
結果の整理：見つかった問題を、重要度で分類する
判断：受け入れるか、修正を求めるかを決める

重要な点は、確認する人です。業務に詳しい担当者が行わないと、実際の運用で起きる問題を見逃します。また、判断の基準が曖昧だと、合否で意見が割れるため、事前に「何ができれば合格か」を合意しておきます。

実務での使い方・具体例

架空の例として、受注管理の仕組みを発注した会社を考えます。受入テストでは、営業担当者が、実際の受注の流れ（見積り、注文、出荷の指示）を、日々の業務で使うデータに近い内容で操作します。すると、開発側のテストでは気づかなかった、「特定の取引先の特殊な処理」が足りないことが見つかります。

発見された問題は、すぐに直すもの、公開後に直すもの、対応しないものに分類し、関係者で合意します。受入条件に基づく判断の記録を残しておくと、後でのトラブルを避けられます。

実施の前に、確認の担当者へ、操作の説明と、問題を記録する方法を共有しておきます。記録は、画面の写真や再現の手順を添えると、開発側が原因を調べやすくなります。また、期間中に見つかった要望と、不具合を分けて整理し、要望は次の改善の候補として別に管理します。実施の結果は、合否の判断とともに、残った課題の一覧として記録します。

判断のチェックポイント

受入条件を、事前に具体的な基準として合意したか
実際の業務の流れに沿った確認項目を作ったか
業務に詳しい担当者が、確認に参加できるか
本番に近いデータと条件で試せる環境があるか
見つかった問題の分類と、対応の判断基準を決めたか
確認に必要な期間を、計画に確保したか

よくある誤解と注意点

開発側のテスト完了と同じではない：確認する観点と担当者が異なります。
直前に慌てて行うと確認が不十分になる：計画に十分な時間を確保します。
担当者の負担を見落としやすい：通常業務と並行するため、時間の調整が必要です。
合格の基準を後で決めない：判断が割れて、トラブルのもとになります。
契約の検収とは別の概念になる場合がある：条件の定めを契約で確認します。

Otsumuに相談できること

受入テストは、発注側が主体になる確認のため、準備と体制の整備が成否を分けます。Otsumuでは、受入条件の整理や確認項目の設計を、事業の状況に合わせてご一緒にお手伝いできます。

MVP開発のご支援内容もご覧いただけます。進め方に迷う段階であれば、30分の無料相談でお話しください。

執筆：Otsumu株式会社／編集日 2026.10.04

受入テスト（UAT）とは？意味・仕組みと使い方