UAT（受け入れテスト）とは｜進め方とテストシナリオの作り方

2026年7月11日

＠SOHO編集部

この記事のポイント

✓UAT（受け入れテスト）とは
✓業務で本当に使えるかを確かめるテストです
✓テストシナリオの作り方と例

新しいシステムの導入で「UATをお願いします」と言われたものの、何をどこまで確かめればよいのか分からず困っている人は多いはずです。UATとは、User Acceptance Testの略で、日本語では受け入れテストやユーザー受け入れテストと呼ばれます。システムを作った側ではなく、使う側の担当者が、自分たちの業務で本当に使えるかどうかを確かめる最後のテストです。この記事では、UATの意味と目的、ほかのテストとの違い、進め方の手順、テストシナリオの作り方と例、合格の基準の決め方、見つかった不具合の管理、よくある失敗と防ぎ方までを順に説明します。テストの作業と不具合の対応を担当と期限で管理する方法の1つとして、プロジェクト管理ツールのPinatecaにも後半で触れます。

UATとは何か

UATは、システムやソフトウェアの開発の最後の段階で行うテストです。開発を頼んだ会社や部署、つまりシステムを使う側が主体となって、実際の業務の流れに沿ってシステムを操作し、要望どおりに動くか、業務で使える状態になっているかを確かめます。

UATの大きな特徴は、確かめる人が使う側であることです。開発の途中で行うテストは、主に作る側の技術者が、設計どおりに動くかを確かめます。一方、UATでは、ふだんその業務をしている担当者が、自分の仕事の目線で「この画面で注文を受け付けられるか」「月末の締めの作業ができるか」を確かめます。

UATは、システムを受け取るかどうかを決めるためのテストでもあります。UATで問題がないと確かめられたら、使う側はシステムを受け入れ、本番での利用を始めます。外部の会社に開発を頼んでいる場合は、UATの結果をもとに、納品を受け入れる手続き（検収）に進むことが一般的です。

UATの目的

UATの目的は、大きく分けて3つあります。

1つ目は、業務で使えるかを確かめることです。設計書どおりに作られていても、実際の業務の流れに当てはめると使いにくい、足りない機能がある、ということは珍しくありません。UATは、こうした食い違いを本番の前に見つける最後の機会です。

2つ目は、利用者が使い方に慣れることです。UATで実際にシステムを操作することで、担当者は本番の前に画面や操作の流れに慣れられます。使い方の手引きを作る材料にもなります。

3つ目は、受け入れの判断の根拠を残すことです。どの業務を、どのデータで、どのように確かめたのかを記録しておけば、後から問題が起きたときに、どこまで確かめていたのかを振り返れます。

ほかのテストとの違い

システムの開発では、UATの前にいくつかの段階のテストが行われます。それぞれの役割を知っておくと、UATで何を確かめるべきかがはっきりします。

単体テスト

単体テストは、プログラムの小さな部品ごとに、正しく動くかを確かめるテストです。開発の担当者が行います。たとえば、金額を計算する部品に数字を入れて、正しい結果が返るかを確かめます。

結合テスト

結合テストは、いくつかの部品を組み合わせたときに、部品どうしが正しくつながって動くかを確かめるテストです。これも主に開発の側が行います。注文の画面で入力した内容が、在庫の部品に正しく渡るか、といったことを確かめます。

システムテスト

システムテストは、システム全体が設計書どおりに動くかを確かめるテストです。機能だけでなく、処理の速さ、多くの人が同時に使ったときの動き、セキュリティなども確かめます。開発の側のテストの担当者が行うことが多い段階です。

UAT（受け入れテスト）

UATは、ここまでのテストを終えたシステムを、使う側が業務の目線で確かめるテストです。ほかのテストが「設計どおりに作られているか」を確かめるのに対し、UATは「業務で使えるか」を確かめる点が違います。

違いの整理

それぞれの違いを整理すると次のようになります。

テスト	主に行う人	確かめること
単体テスト	開発の担当者	部品が正しく動くか
結合テスト	開発の担当者	部品どうしが正しくつながるか
システムテスト	開発の側のテスト担当	全体が設計どおりに動くか
UAT	使う側の業務の担当者	業務で使えるか

UATで、単体テストのような細かい確認をくり返す必要はありません。細かい確認は開発の側の役目です。役割を分けることで、限られた時間を業務の確認に使えます。UATでは、業務の流れに沿って、使う側にしか分からない観点で確かめることに集中します。

UATで確かめること

UATで確かめることは、システムの種類によって違いますが、一般に次の観点があります。

業務の流れ：ふだんの業務の手順どおりに、最初から最後まで操作できるか
計算や結果の正しさ：金額、数量、日付などが、業務の決まりどおりに計算されるか
例外の扱い：返品、取り消し、修正のような、ふだんと違う処理ができるか
画面の分かりやすさ：担当者が迷わずに操作できるか、表示される言葉が業務で使う言葉と合っているか
帳票や出力：請求書や報告書などの出力が、業務で使える形になっているか
権限：担当者ごとに、見られる画面や操作できる範囲が正しく分かれているか
ほかの仕組みとのつながり：会計の仕組みなど、ほかのシステムにデータが正しく渡るか

特に大切なのが、例外の扱いです。ふだんの流れは開発の側のテストでも確かめられていることが多いのですが、返品や取り消しのような業務の例外は、業務をよく知っている人でないと思いつきません。UATでは、実際の業務で起きる例外を、できるだけ多く確かめます。

UATの体制と役割

UATは、使う側の担当者だけで進めるものではなく、いくつかの役割の人が協力して進めます。役割をはっきりさせておくと、テストの途中で迷いが生じません。

責任者

使う側の部署の責任者が、UATの責任者を務めます。合格の基準を決め、最後に受け入れを判断する役目です。不具合を本番の前に直すか、後に回すかの判断も、責任者が行います。

テストの担当者

実際にシステムを操作して確かめる人です。ふだんその業務をしている担当者が務めます。1つの業務につき、経験の長い人と短い人の両方が参加すると、操作に慣れた人には気づかない分かりにくさも見つけられます。

進行役

UATの日程を管理し、テストの担当者の質問に答え、不具合の報告を取りまとめる人です。使う側の情報システムの担当者や、導入を進めるプロジェクトの担当者が務めることが多い役目です。

開発の側の窓口

報告された不具合を受け取り、開発の担当者に伝え、直した結果を返す役目です。外部の会社に開発を頼んでいる場合は、その会社の担当者が務めます。

小さな会社では、1人が複数の役割を兼ねることもあります。その場合も、誰が受け入れを判断するのかだけは、最初に決めておきます。

UATを始める前に確かめておくこと

UATを始めてみたら、基本的な機能がまだ動かない、ということが起きると、使う側の担当者の時間が無駄になります。UATを始める前に、次のことを確かめておきます。

開発の側のテスト（システムテストまで）が終わっていること
開発の側で分かっている不具合の一覧を受け取っていること
テストの環境が用意され、担当者がログインできること
テストに使うデータが入っていること
操作の手引きや画面の説明が、簡単なものでも用意されていること

開発の側で分かっている不具合の一覧を先に受け取っておくと、同じ不具合を何度も報告する手間が省けます。こうした始める条件を、計画の段階で開発の側と合意しておくと、準備が整わないままUATが始まることを防げます。

UATの進め方

UATは、次の手順で進めるのが一般的です。

手順1：計画を立てる

最初に、UATの計画を立てます。計画には、次のことを決めておきます。

確かめる業務の範囲
期間と日程
参加する担当者と、それぞれの役割
テストに使う環境とデータ
合格の基準
不具合が見つかったときの連絡と対応の流れ

UATの期間は、システムの大きさによりますが、業務の担当者はふだんの仕事と並行してテストを行うことが多いので、余裕を持った日程にします。日程を見積もるときは、シナリオの数に、1本あたりにかかる時間をかけて、担当者ごとの作業時間を出します。そのうえで、不具合を直してもう一度確かめる時間を足します。最初の見積もりどおりに進むことは少ないので、全体の日程の中に、予備の日を数日入れておくと安心です。月末や繁忙期のように、業務の担当者が忙しい時期はUATの日程から外します。

手順2：テストシナリオを作る

確かめる業務ごとに、テストシナリオを作ります。テストシナリオとは、どの業務を、どんな手順で操作し、どんな結果になれば合格かを書いたものです。作り方は後の節で詳しく説明します。

手順3：テストの環境とデータを用意する

UATは、本番と同じか、できるだけ近い環境で行います。テストに使うデータも、実際の業務に近いものを用意します。架空のデータばかりだと、実際の業務で起きる問題に気づけないことがあります。ただし、本物の顧客の個人情報をそのままテストに使うのは避け、名前や連絡先を置き換えたデータを使うなど、扱いに注意します。

手順4：テストを実施する

テストシナリオに沿って、担当者がシステムを操作します。結果をシナリオに記録し、期待どおりの結果にならなかったときは、不具合として報告します。操作の画面を写真に撮っておくと、不具合の報告が伝わりやすくなります。合格したシナリオも、結果と確かめた日を記録しておきます。

手順5：不具合を直し、もう一度確かめる

報告された不具合は、開発の側が直します。直ったら、使う側がもう一度同じシナリオで確かめます。1つの不具合を直したことで、ほかの部分に影響が出ていないかも確かめます。

手順6：受け入れを判断する

すべてのシナリオを終え、合格の基準を満たしたら、使う側の責任者が受け入れを判断します。判断の結果と、残っている課題があればその扱いを記録に残します。受け入れの判断は、責任者の名前と日付を入れた書面やメールで残しておくと確実です。

テストの担当者に伝えておくこと

UATに初めて参加する業務の担当者は、何をどこまで確かめればよいのか分からず、戸惑うことがあります。テストを始める前に、進行役から次のことを伝えておくと、担当者は安心してテストに取り組めます。

1つ目は、UATの目的です。システムの細かい不具合を探すことよりも、ふだんの業務で使えるかどうかを確かめることが目的だと伝えます。「いつもの仕事をこの画面でやってみて、困るところがないかを教えてください」と言えば、担当者は自分の仕事の目線で確かめられます。

2つ目は、気づいたことは小さなことでも報告してよいことです。「この言葉の意味が分からない」「このボタンの場所が分かりにくい」のような声は、本番で多くの人がつまずく場所を教えてくれます。報告するかどうか迷ったら報告する、と伝えておきます。

3つ目は、報告の書き方です。どの画面で、何をしたら、どうなったのかを書き、画面の写真を付けるよう伝えます。報告の様式を先に配っておくと、書き方がそろいます。

4つ目は、テストの環境で操作したことは本番のデータに影響しないことです。テストの環境だと分かっていても、「間違えて本当に注文してしまわないか」と心配して、操作をためらう担当者もいます。安心して操作してよいことを伝えます。

テストシナリオの作り方

UATの出来は、テストシナリオの出来で決まると言っても言い過ぎではありません。良いシナリオを作るための手順を紹介します。

業務の一覧を作る

まず、新しいシステムで行う業務を一覧にします。受注、出荷、請求、入金の確認のように、業務の名前を並べます。業務の流れ図があれば、それを使います。

業務ごとに流れを書く

次に、業務ごとに、最初から最後までの流れを書きます。「注文を受け付ける」「在庫を確かめる」「出荷を指示する」「請求書を出す」のように、1つの業務がどう流れるかを順に書きます。

確かめる場面を決める

業務の流れの中で、ふだんの場面と、例外の場面を書き出します。ふだんの場面は「通常の注文」、例外の場面は「在庫が足りない注文」「注文の取り消し」「数量の変更」のようなものです。

期待する結果を書く

それぞれの場面について、操作した後にどうなれば正しいのかを書きます。「在庫が足りない場合は、画面に在庫不足の表示が出て、注文は保留になる」のように、具体的に書きます。期待する結果があいまいだと、テストをした人によって合否の判断がばらつきます。

シナリオの例

注文の受付のシナリオは、次のような形になります。

シナリオ番号：UAT-001 業務：注文の受付場面：在庫が足りない商品の注文前提：商品Aの在庫が5個ある手順

注文の画面を開く
取引先として「株式会社〇〇」を選ぶ
商品Aを10個入力する
「登録」を押す期待する結果：在庫が足りないことを示す表示が出て、注文は保留の状態で保存される結果：（合格／不合格）確かめた人：〇〇確かめた日：〇月〇日備考：

シナリオには番号を付けておくと、不具合の報告や進み具合の管理がしやすくなります。1本のシナリオに多くの場面を詰め込むと、どこで失敗したのかが分かりにくくなるので、1本のシナリオでは1つの場面だけを確かめるようにします。前提の欄には、テストを始める前のデータの状態を書いておきます。前提が書かれていないと、担当者によって始める状態が違い、同じ手順でも結果がばらつくことがあります。

シナリオを作る人

シナリオは、業務をよく知っている使う側の担当者が中心になって作ります。開発の側に作ってもらうと、設計書をもとにしたシナリオになりがちで、業務の例外が抜けやすくなります。開発の側には、シナリオの書き方の助言や、システムの仕様についての確認を頼みます。

業務ごとのシナリオの例

テストシナリオの考え方を、よくあるシステムの例で紹介します。

請求の仕組みのシナリオ

請求書を作る仕組みでは、次のような場面を確かめます。

通常の請求：1か月分の取引をまとめて請求書を作り、金額と消費税が正しく計算されるか
月の途中の契約：月の途中から始まった契約の料金が、決まりどおりに日割りされるか
値引きがある場合：値引きの金額が正しく差し引かれ、請求書に表示されるか
請求の取り消し：誤って作った請求書を取り消し、作り直せるか
締め日の扱い：締め日が休日にあたる場合に、決まりどおりの日付で処理されるか

金額の計算は、表計算ソフトなどで別に計算した結果と照らし合わせて確かめます。端数の扱い（切り捨て、四捨五入）が業務の決まりと合っているかも確かめます。

予約の仕組みのシナリオ

予約を受け付ける仕組みでは、次のような場面を確かめます。

通常の予約：空いている枠に予約を入れ、確認のメールが届くか
満席の枠：埋まっている枠には予約できないか
予約の変更：日時を変えたときに、元の枠が空き、新しい枠が埋まるか
予約の取り消し：取り消しの期限を過ぎた場合に、決まりどおりの扱いになるか
同時の予約：2人がほぼ同時に同じ枠を予約しようとしたときに、二重の予約にならないか

ネットショップのシナリオ

商品を売るネットショップでは、次のような場面を確かめます。

通常の購入：商品を選び、支払いを終え、注文の確認のメールが届くか
在庫切れ：在庫がなくなった商品が、購入できない表示になるか
送料：届け先の地域や購入金額によって、送料が決まりどおりに計算されるか
返品：返品を受け付け、返金と在庫の戻しが正しく処理されるか
スマートフォン：スマートフォンの画面でも、同じように購入できるか

どのシステムでも、ふだんの流れに加えて、取り消し、変更、例外の場面を必ず入れることが、抜けの少ないシナリオを作るこつです。

合格の基準の決め方

UATを始める前に、どうなれば合格とするのかを決めておきます。基準があいまいなままテストを始めると、終わりどころが分からず、UATがいつまでも続いてしまいます。

合格の基準の例は、次のようなものです。

すべてのシナリオを実施していること
業務を止めてしまう重大な不具合が残っていないこと
残っている不具合は、本番の後に直す予定と、それまでの回避策が決まっていること

不具合は、重さで分けて考えます。業務が止まるもの、業務はできるが手間がかかるもの、見た目の問題だけのもの、のように分けておくと、どれを本番の前に直すべきかを判断しやすくなります。すべての不具合を本番の前に直すのが理想ですが、時間が限られる場合は、重さに応じて優先順位を決めます。

契約との関係

外部の会社に開発を頼んでいる場合、UATの結果は、納品の受け入れや支払いに関わります。どの時点で検収とするのか、検収の後に不具合が見つかったらどうするのかは、契約で決めておくことが大切です。

システム開発の契約の考え方については、情報処理推進機構（IPA）が契約書のひな形を公開しています。

情報システム開発におけるユーザ企業とITベンダ間の取引構造を透明化するため、DXの進展によるそれぞれの役割の変化等を踏まえた、それぞれが各開発段階で担うべき責務等の解説と、契約書のひな型を提供しています。出典: IPA「情報システム・モデル取引・契約書」

また、民法では、請負の契約で納めたものが契約の内容に合わない場合について、注文した側が不適合を知った時から1年以内に通知しなければならないという決まりがあります（民法第637条）。実際の扱いは契約の内容によって変わるので、検収や不具合の対応の期間は、契約書で確かめてください。

見つかった不具合の管理

UATでは、多くの不具合や要望が報告されます。これを整理して管理しないと、直したはずの不具合が残っていたり、同じ不具合が何度も報告されたりします。

報告の書き方をそろえる

不具合の報告は、決まった項目で書きます。

報告の番号
関係するシナリオの番号
起きたこと（どの画面で、何をしたら、どうなったか）
期待していた結果
重さ
報告した人と日付
画面の写真

起きたことは、開発の担当者が同じ操作をくり返して確かめられるよう、手順を具体的に書きます。「うまく動かない」だけでは、何が問題なのかが伝わりません。

不具合と要望を分ける

UATでは、不具合だけでなく、「この画面にこの項目もほしい」という要望も出てきます。設計どおりに動いていないものは不具合、設計にはないが追加してほしいものは要望として分けて管理します。要望は、本番の前に対応するのか、本番の後に検討するのかを、責任者が判断します。要望をすべて本番の前に入れようとすると、日程が大きく遅れます。要望が設計の段階での伝え漏れによるものか、UATで初めて気づいたものかも記録しておくと、次のシステムの導入で、要件を決める段階の改善に生かせます。

状況を追いかける

報告した不具合ごとに、今どの状況にあるのかを記録します。「報告済み」「確認中」「修正中」「修正済み」「再確認済み」のように、状況の段階を決めておきます。担当者と期限も決めておくと、誰がいつまでに何をするのかが分かります。

テストの作業と不具合の対応を管理する方法

小さなシステムのUATなら、テストシナリオと不具合の一覧を表計算ソフトで管理すれば十分です。シナリオの一覧のシートと、不具合の一覧のシートを作り、それぞれに担当者、状況、期限の列を設けます。

参加する担当者が多い場合や、開発の会社と使う側の会社をまたいでやり取りする場合は、表計算ソフトのファイルを何人もで書き換えると、誰がどこを変えたのかが分かりにくくなります。こうした場面では、作業の管理の道具を使う方法もあります。選択肢の1つが、Pinatecaです。公式サイトによると、Pinatecaはカンバン、ガントチャート、カレンダーなど8種類のボードとチャットを備えたプロジェクト管理ツールで、カードに担当者と期限を付けて管理できます。不具合を1件ずつカードにし、「報告済み」「修正中」「再確認待ち」「完了」の列に並べれば、カードを動かすだけで状況が一目で分かります。カードにはコメントや画面の写真を付けられるので、開発の担当者とのやり取りも同じ場所に残ります。見積もりの工数や優先度のような項目をカードに追加することもでき、社外のメンバーを招待して、見える範囲を分けることもできます。

料金は、5人までのチームなら無料で、ボードは10個まで作れます。6人目、または11個目のボードからはスタンダードプランになり、1人あたり月額500円（税抜、年払いなら1人あたり月額400円）です。Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

UATの結果の報告書

UATが終わったら、結果を報告書にまとめます。報告書は、受け入れの判断の根拠になり、後から問題が起きたときに、どこまで確かめていたのかを振り返る記録にもなります。

報告書には、次のことを書きます。

UATの期間と、参加した担当者
確かめた業務の範囲
実施したシナリオの数と、合格したシナリオの数
見つかった不具合の数と、重さごとの内訳
直した不具合と、残っている不具合
残っている不具合の扱い（直す予定の時期と、それまでの回避策）
受け入れの判断の結果と、判断した責任者

残っている不具合については、本番を始めた後に誰がいつまでに直すのかを書いておきます。本番を始めると、関係者の関心がほかに移り、残った課題が忘れられがちだからです。

本番を始めた後に気をつけること

UATを終えて本番での利用を始めた後も、しばらくは注意が要ります。UATでは確かめきれなかった問題が、実際の業務の中で見つかることがあるからです。

本番を始めてから最初の数週間は、問い合わせの窓口を決めておき、担当者が困ったときにすぐに相談できるようにします。見つかった問題は、UATと同じ形で記録し、重さに応じて対応します。

月末の締めや、年に1回の処理のように、UATの期間中には起きなかった業務もあります。こうした業務を初めて行うときは、開発の側にも立ち会ってもらうなど、あらかじめ備えておくと安心です。

UATでよくある失敗と防ぎ方

最後に、UATでよく起きる失敗と、その防ぎ方を紹介します。

業務の担当者が参加できない

業務の担当者が、ふだんの仕事が忙しくて、UATに時間を割けないことはよくあります。結果として、テストが形だけになり、本番で問題が見つかります。UATの期間は、担当者の仕事の量を調整し、テストのための時間を確保しておくことが大切です。

シナリオが足りない

ふだんの流れだけを確かめて、例外の場面を確かめていないと、本番で返品や取り消しが起きたときに初めて問題に気づきます。シナリオを作るときに、業務の担当者に「月に1回でも起きる例外は何か」を挙げてもらいます。

UATで要望が増え続ける

UATで初めて画面を触った担当者から、要望が次々に出ることがあります。すべてに応じていると、いつまでも本番を始められません。要望は一覧にして、本番の前に必要なものと、後で検討するものに分けます。

合格の基準が決まっていない

基準がないまま始めると、どこで終えればよいのかが分からなくなります。UATの計画の段階で、合格の基準を関係者で合意しておきます。

テストのデータが現実と違う

架空の、きれいなデータだけでテストすると、実際のデータに含まれる長い名前や特殊な文字、古い形式のデータで起きる問題に気づけません。個人情報に配慮したうえで、実際のデータに近いものを用意します。

アジャイル開発でのUAT

最近は、短い期間で機能を少しずつ作って公開していく、アジャイル開発と呼ばれる進め方も広がっています。アジャイル開発では、開発の最後にまとめてUATを行うのではなく、機能ができるたびに、使う側の担当者が確かめていくことが多くなります。

この場合も、使う側が業務の目線で確かめるという考え方は変わりません。機能ごとに、どうなれば受け入れるのかという条件を、作り始める前に決めておきます。条件がはっきりしていれば、機能ができたときにすぐに確かめられ、手戻りが減ります。IPAの契約書のひな形にも、アジャイル開発向けのものが用意されています。

UATを外部の専門家に手伝ってもらう

社内にシステムの導入の経験がある人がいない場合は、UATの計画やシナリオの作成を、外部の専門家に手伝ってもらう方法もあります。テストの専門家に頼めば、抜けやすい観点を指摘してもらえます。ただし、業務の目線で確かめるというUATの性質上、業務の担当者が参加しないと意味がありません。外部の専門家には進め方の支援を頼み、確かめる作業そのものは、使う側の担当者が行う形が基本です。

2004年から在宅ワークとフリーランスの仲介を続けてきた運営者として見てきた範囲では、システムの開発を外部に頼んでうまくいく会社ほど、受け入れの基準を最初の打ち合わせで決めています。「何ができたら完成とするのか」を発注の段階で書面にしておけば、納品のときに双方の認識がずれにくく、追加の費用をめぐる行き違いも起きにくくなります。依頼する側と受ける側が直接やり取りする関係では、仲介の手数料がかからない分、予算を開発そのものに回せますが、受け入れの基準を決める責任は依頼する側にあります。

システムの開発やテストの仕事に関心があるなら、アプリケーション開発のお仕事で、アプリ開発の仕事の内容と必要な技術を紹介しています。業務にAIを取り入れる仕組みづくりを支援する仕事については、AIコンサル・業務活用支援のお仕事で確かめられます。デザインの側から画面の使いやすさに関わる人は、デザイナーの年収・単価相場で仕事の収入と単価の目安を確かめられます。