UATとは?受入テストは発注者側の工程——誰がやるのか、準備する4つ、合否の決め方と検収との関係【2026年版】

「来月からUATに入ります、と言われたのですが、これは何のテストですか」——システム開発を発注している方から、こうした相談をよく受けます。議事録には「UAT」の3文字しか書かれていない。調べると受入テストらしい。しかしなぜ、テストを頼んだはずの自社側が人を出さなければならないのか。しかも、リリース直前の忙しい時期に。

結論から言うと、UAT(User Acceptance Test・受入テスト)は発注者側の工程です。単体テスト、結合テスト、システムテストが開発会社の工程であるのに対し、UATだけは主役が発注者側の業務部門になります。理由は単純で、そのシステムを使って回す業務を知っているのは発注者側だけだからです。開発会社に代行させることが、原理的にできません。

ここを知らないまま直前に人を集めると、画面を順に開いて「動いています」と確認するだけの形式的な工程になります。そして本番が始まってから、月末の締め処理が回らない、特定の取引先だけ帳票が出ない、といった問題が噴き出します。UATは品質を証明する工程ではなく、業務が回るかを確かめる工程です。この一点を押さえておくと、準備すべきものも、合否の決め方も自然に決まります。

本記事では、UATの定義とテストレベルでの位置づけ、誰がいつやるのか、準備する4つ(テストシナリオ・テストデータ・環境・体制)、合否の決め方と指摘の切り分け、そして検収との関係の順に解説します。テストを社外に委託する範囲の話は本記事では扱わず、既存の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。UATに関する相談は、準備期間が2週間を切ってから届くことがほとんどです。うまくいっている案件に共通するのは、たった2つだけでした。この記事を読み終えるころには、自社の誰に何を依頼し、何をもって合格とするかが決められるはずです。

UAT(受入テスト)とは——完成したシステムを「自社の業務で使えるか」で判定する工程

UATとは、開発が終わったシステムを、発注した側が「自社の業務で使えるか」という観点で確かめ、受け取ってよいかどうかを判定する工程です。テストという名前がついていますが、確かめているのはプログラムの正しさではありません。明日から自分たちの仕事がこのシステムで回るかどうかを見ています。

UATは何の略か——User Acceptance Test、日本語では受入テスト・検収テスト・承認テスト

UATは User Acceptance Test の略です。日本語では受入テスト、受け入れテスト、検収テスト、承認テスト、ユーザー受入テストなど、複数の呼び方が使われています。呼び方は現場によってばらつきますが、指しているものは同じです。JSTQB(日本語翻訳版のFoundation Levelシラバス Version 2023V4.0)は、受け入れテストを「妥当性確認と、デプロイの準備ができていることの実証に焦点を当てる」テストレベルと位置づけ、これは「システムがユーザーのビジネスニーズを満たしていること」を意味するとしています。そのうえで「受け入れテストは、想定ユーザーによって実施をすることが理想的である」と述べ、主な形式の1つとしてユーザー受け入れテスト(UAT)を挙げています。開発を外部に委託した場合であれば、最終段階で発注元が納品を受け付けるかどうかを判定する試験が、これにあたります(確認日2026年9月21日)。

呼び名が複数あること自体が、この工程の性格を表しています。テストという技術寄りの言葉と、検収・承認という契約寄りの言葉が、同じものを指している。UATは技術と契約の境目に立っている工程です。

単体・結合・システムテストとの違いは「何と照らし合わせるか」——テストレベルの対応表

テスト工程がいくつも並んでいると、違いが分かりにくくなります。整理の軸はひとつで、何と照らし合わせているかです。

上の3つは、いずれも文書と照らし合わせています。設計書どおりか、要件定義書どおりか。だから開発会社が実施できます。UATだけが文書ではなく、現場の業務そのものと照らし合わせます。要件定義書に書かれていない暗黙の手順や、月末だけ発生する例外処理は、文書には残っていないことが多い。それを知っているのは発注者側の人間だけです。

この対応関係は、開発工程とテスト工程を左右に並べた「V字モデル」として説明されることが多く、UATは要件定義や要求分析に対応するテストレベルに位置づけられます。システム稼働前の最後のテストであり、ここを通って初めて業務で使える品質が確認できたことになります。

UATの目的は品質の証明ではなく、業務が回るかの確認

システムテストが終わっているなら、UATは形式的な確認でよいのではないか——このご質問は本当によくいただきます。答えは「いいえ」です。見ている問いが違うからです。

設計とコーディングが正しく行われていても、結果として業務フローに合っていなければ現場では使えません。たとえば、要件どおりに割引率の入力欄が実装されていても、実務では割引の承認が上長経由で行われるため、その画面に上長が到達できなければ業務は止まります。これは仕様の誤りではなく、業務との噛み合わせの問題です。システムテストでは検出できません。

よくある誤解——「テストは全部、開発会社の仕事」

発注者の方が最初に驚くのが、ここです。テストを含めて委託したつもりだったのに、最後のテストは自分たちがやる。当惑されるのも無理はありません。

ただ、これは開発会社が手を抜いているわけではありません。業務で使えるかという判断は、発注側にしかできないからです。当社の考え方を正直に言えば、丸投げできる範囲は、日本側の会社がどこまで巻き取るかで決まりますが、業務が回るかの判断だけは巻き取れません。ここを開発会社に委ねてしまうと、「動いているのに使えない」システムができあがります。照らし合わせる相手が業務である以上、次に決まるのは実施者です。誰が、いつ、どれだけの時間をかけてやるのかを見ていきます。

誰が、いつやるのか——主役は発注者側の業務部門。情シスが進行、開発会社は支援

UATの実施者は発注者側です。ただし発注者側と言っても、情報システム部門が全部抱えるのか、業務部門が出るのかで、結果はまったく変わります。結論を先に書くと、主役は業務部門、情報システム部門は進行役、開発会社は支援に回るという三層で組むのが実務的です。

業務部門が主役になる理由——業務を知っているのは発注者側だけ

受入テストのテストケースは、基本的に発注者や利用部門が中心となって作成する、というのが一般的な整理です。業務要件を最もよく理解しているのが利用者側だからです。実務では、開発会社がテスト設計のひな型を用意し、発注者が自社の業務シナリオに合わせて修正・補足する形を取ることが多くなっています。

情報システム部門だけで実施すると、何が起きるか。画面と機能の確認は通りますが、「その操作を、実際に誰が、どの順番で、どんな気持ちでやるのか」が抜けます。月末の締めが1日で終わるのか3日かかるのかは、経理の担当者にしか分かりません。だから、営業・経理・物流といった実際に使う部門の担当者を必ず入れます。業務に習熟した方をテストリードとして指名しておくと進行が安定します。

役割分担の表(業務部門 / 情報システム部門 / 開発会社)

三者が何をやるのかを、あらかじめ文書にしておきます。ここが曖昧なまま始まると、シナリオを誰も書かないまま当日を迎えます。

この表で大事なのは、開発会社の欄が空いていないことです。UATが発注者の工程だからといって、開発会社が待っているだけというのは間違いです。ひな型の提供、環境の構築、質問への即答は開発会社の仕事です。発注時に、この支援がどこまで含まれているかを必ず確認してください。含まれていなければ追加費用の話になりますし、それを契約後に知るのは失敗のもとです。

いつやるのか、どのくらいかかるのか——システムテスト完了後、実施期間と準備期間を分けて確保する

時期は、開発会社側のシステムテストが完了し、一定の品質が確認できた後です。システムテストが終わっていない段階でUATを始めると、明らかな不具合に時間を取られ、業務観点の確認まで到達しません。

期間は案件の規模と対象業務の数で決まります。標準的な日数を示した公的な基準や業界調査は確認できないため、本稿では具体的な週数を示しません。押さえておきたいのは、テストを実施する期間と、シナリオの洗い出し・テストケースの整備にあてる準備期間を分けて見積もることです。準備期間を実施期間に含めて計画すると、ほぼ確実に足りなくなります。

私のところに届くUATの相談は、準備期間が2週間を切ってから届くことがほとんどです。すでに業務部門の予定は埋まっており、繁忙期と重なっていることも多い。ここから巻き返すのは簡単ではありません。逆に言えば、プロジェクトの計画段階でUATの日程と体制を押さえておくだけで、この問題の大半は消えます。開発の見積もりを見るときは、UATの期間が工程表に入っているかを確認してください。入っていなければ、そのプロジェクトは最後に予定外の時間を使うことになります。

UATの前に準備する4つ——テストシナリオ、テストデータ、環境、体制

準備するものは4つです。テストシナリオ、テストデータ、テスト環境、そして体制。この4つが揃っていないままUATの初日を迎えると、初日は環境の不具合と操作説明で終わります。3日分の予定が1日に圧縮され、確認の粒度が落ちる。ここが最も多い失敗の入口です。

準備物の一覧と、誰が用意するか

計画段階で3つの文書を作っておくと、当日の迷いがなくなります。

合否基準書だけ、期限が前倒しになっている点に注目してください。理由は後ほど書きますが、これを最後に決めようとすると必ず揉めます。

テストシナリオは「画面ごと」ではなく「業務フローごと」に書く——観点4つ

UATがうまくいっている案件の共通点のひとつが、これです。シナリオを画面単位ではなく、業務フロー単位で書いていること。

画面単位で書くと、「受注入力画面で商品を選べる」「在庫照会画面で在庫が表示される」という確認が並びます。ひとつずつは通ります。しかし、受注を入れてから在庫を引き当て、出荷指示を出して請求まで回したときに、途中でデータの持ち回りが切れている——という問題は、通しでやらないと見つかりません。日常業務をなぞるように操作する。これがUATの基本動作です。

見る観点は次の4つで足ります。

1. 業務シナリオの網羅——想定される業務の流れが漏れなくカバーされているか。通常時だけでなく、返品・訂正・月末締めといった例外も入れる
2. データの入出力——入力した値が、帳票や連携先に正しく反映されるか。特にリプレイス案件では、現行システムと新システムの出力を突き合わせる確認(現新比較)を入れる
3. 操作性——実際の担当者が、説明なしで操作できるか。1件あたりの所要時間が現行より増えていないか
4. エラー時の挙動——入力ミス、通信断、権限のない操作をしたときに、業務が止まらずに復旧できるか

性能やセキュリティ、使いやすさといった非機能の要件も、UATで確認します。ただし負荷試験の技法そのものは専門領域なので、実運用に近いデータ量で通常業務が実用的な速度で回るか、という粒度で見るのが現実的です。

限られた時間で優先順位をつけるなら、重要な機能、仕様変更が入った機能とその周辺、そして実際の環境・実際のデータ、この3つを優先します。開発の途中で仕様を変えた箇所は、既存の設計への考慮漏れが起きやすい場所です。

テストデータと環境——本番相当をどう作るか、個人情報は匿名化する

環境は、本番に近いシステム構成とデータで用意します。外注先の疑似環境から本番環境へ移すときに処理の漏れが出やすいため、できるかぎり本番相当で確認する意味は大きいと言えます。外部システムとの連携がある場合は、連携先の試験環境まで含めて用意できているかを確認してください。ここが抜けていると、UATで最も価値のある確認ができません。

テストデータは、本番のデータをそのまま使うのではなく、業務データを匿名化して投入するのが一般的な整理です。得意先名、担当者名、電話番号、メールアドレスといった個人情報を含む項目は置き換えます。件数はある程度の量を入れてください。10件では見えない問題が、1万件では見えます。

なお、海外の開発チームにデータを渡す場合は、個人情報保護法の越境移転の論点が別に発生します。当社は本番データを海外へ出さない設計を前提にしていますが、この論点は「ベトナム データ越境 個人情報」の記事に詳しく書きました。

準備でつまずく3パターン

最後に、準備段階で多い3つを挙げておきます。ひとつ、シナリオを書く人が決まらないまま日程だけ先に決まっている。ふたつ、テスト環境の用意が見積もりに含まれておらず、直前に追加費用の話になる。みっつ、データの匿名化を誰がやるのか決まっていない。いずれも、テスト計画書に1行足しておけば防げるものです。準備が整えば、次は判定の話になります。

合否はどう決めるか——重大度4段階と判定ルール、指摘は「不具合」か「仕様変更」か

UATで最も揉めるのは、テストそのものではありません。出てきた指摘をどう扱うか、そして何をもって合格とするかです。残っている不具合が3件だとして、リリースしてよいのか。判断の根拠がないまま、リリース予定日という締切だけが迫る。これが最も危ない状況です。

重大度を4段階で定義し、段階ごとに合否ルールを決める

実務では、不具合を重大度で4段階に分け、段階ごとに判定ルールを決めておく方法が使われています。

この表の価値は、判定の線を人ではなく文書に置くことにあります。「まだ直っていませんが、業務に支障はないので進めましょう」という会話が、「Mediumが7件、合意した上限は5件なので、2件は修正後にリリースします」という会話に変わります。

決める時期は、UATの直前ではなく契約時または計画時です。指摘が山ほど出ている状況で基準を決めようとすると、双方が自分に有利な線を引こうとします。何も出ていない時期に決めておけば、これは単なるルールです。当社に届く相談で、UATがこじれている案件は、ほぼ例外なくこの定義がありません。基準を決めずに押印を迫られる状況が最も危ない、というのが私の持論です。

あわせて、どこまで確認したら網羅したと言えるのか(網羅基準)も決めておきます。リスクの高い機能は全フローを通し、参照だけの画面は代表ケースのみ、といった粒度で十分です。

出た指摘を切り分ける——基準は「合意した仕様との一致」

UATで出た指摘は、大きく2つに分かれます。

• 不具合——合意した仕様どおりに動いていない。開発会社が無償で修正する範囲
• 仕様変更(追加要望)——仕様どおりに動いているが、業務に合わない、あるいは別の動きがほしい。追加費用と工期の対象になりうる範囲

切り分けの基準はひとつで、合意した仕様書との一致です。感覚や声の大きさで決めるものではありません。だからこそ、要件定義書や基本設計書が「判定できる文章」で書かれているかが、UATの段階になって効いてきます。「使いやすい画面にする」としか書かれていなければ、使いにくいという指摘を不具合と呼ぶことも、仕様変更と呼ぶこともできてしまいます。

実務的な進め方としては、指摘を一覧に起票するときに、起票者が「不具合と考える/仕様変更と考える/判断できない」の欄を必ず埋めます。そのうえで、判断できないものだけを会議で扱う。全件を会議にかけると時間が足りません。なお、仕様変更として扱うと決まった場合の費用と工期の考え方は、「仕様変更 追加費用」の記事に書きました。

もうひとつ、現実的な助言を。UATで出た仕様変更を、すべてリリース前に取り込もうとしないでください。本番稼働後の改善として残す判断のほうが、結果的に早く価値が出ることが多いのが実情です。当社が手がけた介護記録SaaS「CareViewer」では、日本語のできるブリッジSEをフロントに置き、週次で優先順位を判断しながら継続的に開発しています。リリース前に全部入れるのではなく、優先順位を毎週決め直す形にしたほうが、要件が動くプロダクトには合っていました。

判定を個人に背負わせない——判定会議と記録の残し方

合否の判定を、業務部門のリーダー個人に背負わせてはいけません。本番で問題が起きたときに、その人の判断が悪かったという話になってしまいます。

判定は、業務部門・情報システム部門・開発会社が同席する会議体で行います。残すのは次の4つです。実施したテストケースの件数と消化率、検出した指摘の一覧と重大度の内訳、未修正のまま残す指摘とその回避策・対応期限、そして合否の結論と参加者。この記録が、後で「知った時」を示す資料にもなります。

いま手元にあるプロジェクトで、重大度の定義は文書になっているでしょうか。なっていなければ、UATが始まる前に1枚作っておくことをおすすめします。

UATと検収の関係、オフショア開発でのUATと当社の体制

UATと検収は、しばしば同じものとして語られます。実際、UATは検収テストとも呼ばれます。しかし発注者にとっては、この2つを分けて理解しておく実益があります。片方はテストという作業で、もう片方は契約上の行為だからです。

検収はテストではなく契約上の行為——押印の時期を合否基準と紐づける

UATは「確かめる」作業、検収は「受け取ったと認める」行為です。検収が完了すると、システムの受け入れが確定し、請求と支払いの段階に進みます。

区別が実益を持つのは、押印した後です。2020年4月に施行された改正民法では、旧来の瑕疵担保責任が契約不適合責任として整理され、注文者は不適合を知った時から1年以内に通知することが求められる形になりました(民法637条)。つまり、検収を済ませた後に見つかった不具合は、無償修正の当然の対象ではなく、契約不適合責任という別の枠組みで、期間と範囲の制約を伴って扱われることになります。

ここで起きがちなのが、次の状況です。UATで不具合が残っているのに、検収の期限が来てしまった。ベンダーは「後で直しますから」と言う。支払いサイトの都合もあって、直っていないのに検収書に押印してしまう。この押印が、後の交渉の立場を大きく変えます。

契約書には、納品後の一定期間内に発注者から通知がなければ検収が完了したものとみなす、という「みなし検収」の条項が入っていることがあります。期間の長さは契約によって異なるため、自社の契約書で実際の日数を確認してください。IPAが公開している「情報システム・モデル取引・契約書」(第二版・2020年12月22日公開)も、ユーザとベンダが検収方法について共通理解を持つことを促しています。契約書のこの条項と、UATの日程が整合しているかを、契約時に確認してください。UATが3週間かかるのに、検収期間が10営業日では成り立ちません。

やることは3つです。ひとつ、検収の判定基準を、前章の重大度のルールと同じ文言にする。ふたつ、検収期間をUATの期間と整合させる。みっつ、未修正のまま残す指摘を「残課題一覧」として検収書に添付し、対応期限を明記する。これだけで、押印は判断ではなく手続きになります。

オフショア開発でのUAT——時差2時間なら、指摘は当日中に返せる

海外のチームに開発を委託している場合、UATの進め方で気になるのは往復の速さです。指摘を出してから回答が返るまでが翌々日になると、2週間のUATは実質1週間分しか回りません。

ベトナムと日本の時差は2時間です。日本の午前9時はホーチミンの午前7時、日本の午後6時は現地の午後4時。日本側の業務時間の大半が現地の稼働時間と重なるため、午前中に出た指摘をその日のうちに起票し、当日中に一次回答を返す運用が成り立ちます。UATの期間中は、朝に前日分の指摘を確認する短い定例を置き、午後に修正版を反映するというリズムが現実的です。

注意点も正直に書いておきます。テト(旧正月)の期間は現地が長期休暇に入ります。2026年は2月14日から22日までの9連休です。この時期にUATを重ねる計画は要注意です。日程を引く段階で、現地の祝日カレンダーを確認してください。

当社の体制と、UAT支援が向く案件・向かない案件

当社(TALENTBASE VIETNAM)は、ホーチミンを拠点にベトナムオフショア開発のラボ型チームを提供しています。UATそのものは発注者側の工程ですが、その進行を日本人PMが支援する形を推奨しています。具体的には、テストケースのひな型の提供、テスト環境の用意、指摘の一元管理と一次切り分け、週次定例での優先順位の確認です。判定は発注者が行い、その手前の整理を当社が引き受けます。

体制はパターンA(日本人PM/ブリッジSE+エンジニア・推奨)とパターンB(エンジニアのみ)の2つです。UATの進行支援まで含めるならパターンAになります。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。エンジニアの単価は公開しており、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安とブリッジSEで3,000USDです(1USD=150円換算が目安)。2,000名以上のIT人財データベースから直接アサインするため、協力会社を経由する中間マージンは発生しません。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを標準にしています。

向く案件と向かない案件も書いておきます。向くのは、継続的にリリースがあり、毎回のUATを定型化したい案件です。介護記録SaaS「CareViewer」のように、要件が動き続けるプロダクトでは、週次の優先順位判断とセットで回すほうが成果が出ます。向かないのは、業務部門を1人も出せない案件です。当社がどれだけ整理しても、業務が回るかの判断だけは代われません。その場合は、UATの前に社内の体制づくりから相談していただくほうが結果的に早く進みます。

なお、テストそのものを社外に委託する話——どの種別を外に出すか、テスト会社をどう選ぶか、発注前に何を決めるか——は本記事では扱いません。「テスト 外注」の記事に、線引きと発注前に決めることをまとめてあります。第三者検証を検討している場合は、そちらをご覧ください。

UAT(受入テスト)に関するよくある質問

UATについて、発注者の方から実際によく届く質問を5つ挙げます。いずれも計画段階で確認しておくと、当日の混乱を減らせるものです。

Q1. テストケースは自社で用意する必要がありますか

業務シナリオは自社で洗い出す必要がありますが、テストケースの形式やひな型は開発会社に依頼して構いません。実務では、開発会社がひな型を提供し、発注者が自社の業務に合わせて修正・補足する形が一般的です。発注時に、この支援が見積もりに含まれているかを確認してください。

Q2. 期間はどれくらい見ればよいですか

テストの実施期間は案件の規模と対象業務の数で決まり、標準的な日数を示した公的な基準や業界調査は確認できません。実施期間とは別に、シナリオの洗い出しとテストケースの整備にあてる準備期間が必要です。プロジェクトの工程表にUATの実施期間と準備期間が別々に入っているかを、見積もりの段階で確認してください。

Q3. 本番データをそのまま使ってよいですか

件数と傾向は本番相当にしたほうがよいものの、個人情報を含む項目は匿名化して投入するのが一般的な整理です。得意先名、担当者名、連絡先などが対象になります。海外の開発チームが関わる場合は、個人情報の越境移転の論点が別にあります。

Q4. 不具合が多すぎて合格にできない場合はどうなりますか

重大度の定義と判定ルールを事前に合意していれば、判断は機械的にできます。Criticalが残っていれば不合格、Mediumは合意した上限まで、という形です。未修正のまま残す指摘は、回避策と対応期限を書いた残課題一覧にして、検収書に添付します。ルールが決まっていない状態で判断を迫られるのが、最も避けたい状況です。

Q5. UATを外部に依頼することはできますか

テストの実施作業や、シナリオの整理を支援してもらうことはできます。ただし業務で使えるかの判断そのものは発注者側に残ります。当社の場合は、日本人PMがテストケースのひな型提供、環境の用意、指摘の一次切り分け、週次定例での優先順位の確認までを担当し、判定は発注者が行う形です。最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始可能な体制。

まとめ: UATは発注者の工程——準備は4つ、決めるのは合否基準と指摘の切り分け

UAT(User Acceptance Test・受入テスト)とは、完成したシステムを「自社の業務で使えるか」という観点で判定する工程です。単体テスト・結合テスト・システムテストが設計書や要件定義書という文書と照らし合わせるのに対し、UATだけが現場の業務そのものと照らし合わせます。業務を知っているのは発注者側だけなので、開発会社に代行させることができません。主役は業務部門、情報システム部門が進行役、開発会社は支援という三層で組むのが実務的です。

準備するものは4つです。業務フロー単位で書いたテストシナリオ、本番相当で個人情報を匿名化したテストデータ、外部連携先まで含めた本番に近い環境、そして業務部門から人を出す体制。決めることは2つです。重大度を4段階で定義した合否基準と、出てきた指摘を「不具合」と「仕様変更」に切り分けるルール。切り分けの基準は合意した仕様との一致であって、声の大きさではありません。この2つは、指摘が山ほど出ている時期ではなく、契約時または計画時に決めてください。何も出ていない時期に決めておけば、これは単なるルールです。

そして検収は、テストではなく契約上の行為です。押印した後に見つかった不具合は、契約不適合責任という別の枠組みに移り、期間と範囲の制約がつきます(民法637条)。検収期間とUATの期間が整合しているか、未修正の指摘を残課題一覧として添付できているかを、契約書で確認してください。仕様変更として扱うと決まった場合の費用と工期の考え方は仕様変更の追加費用に、テストそのものを社外に委託する範囲の線引きと発注前に決めることはソフトウェアテストの外注にまとめてあります。なお、この記事は法的助言ではありません。契約条項の個別の判断は弁護士にご確認ください。当社はホーチミンを拠点に、日本人PMがUATの進行を支援するラボ型のチームを提供しています。最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、UATの体制と日程の組み方を含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。