UAT（受け入れテスト）とは？目的・進め方・失敗しないポイントをわかりやすく解説【AI活用も】

最終更新日:2026/05/07

システム開発の最終局面で、「仕様通りだが現場では使いにくい」という致命的なズレを防ぐ工程がUAT（ユーザー受け入れテスト）です。

本記事では、UATの定義や進め方、システムテストとの違いといった基本に加え、近年重要性が増している「生成AI導入時のチェックポイント」まで、実務に即して解説します。

UATとは

UAT（User Acceptance Testing：ユーザー受け入れテスト）は、開発されたシステムが意図した利用者に受け入れられる状態かをチェックするテストです。受け入れ基準や業務の流れに照らして、利用者が問題なく運用を開始できるかを判断します。

単体テストや結合テスト、システムテストが主に開発側やQA部門によって行われるのに対し、UATでは実際にシステムを使う側の視点で確認する点が大きな特徴です。

たとえば、画面や機能が仕様通りに動いていたとしても、現場の業務フローに合っていなければ、リリース後の定着は難しくなります。UATは、そうした「仕様上は問題ないが、現場では使いにくい」という課題を見つける最終確認の役割を担います。

UATの基本情報

項目	内容
正式名称	User Acceptance Testing
日本語	ユーザー受け入れテスト
実施タイミング	本番リリース前の最終確認工程
主な実施主体	発注側、利用部門、エンドユーザー
主な目的	受け入れ基準や利用者ニーズへの適合確認

UATの目的

UATの目的は、大きく次の3つです。技術的に動作するかだけでなく、現場で受け入れられる状態にあるかを確認することが大切です。

業務要件とのズレを確認する

開発プロジェクトでは、要件定義の段階で合意した内容が、開発の過程で少しずつ解釈のズレが生じることがあります。UATでは、完成したシステムが実際の業務フローや現場の使い方に合っているかをチェックします。

リリース後のトラブルを減らす

本番稼働後に問題が見つかると、修正コストだけでなく、業務停止や問い合わせ対応などの負担も大きくなります。UATで事前に課題を見つけておくことで、リリース後の混乱を抑えやすくなります。

受け入れ可否を判断する

UATは、事前に定めた基準に沿ってシステムの受け入れ可否を判断する工程です。外部ベンダーに発注した案件では、検収や納品受け入れの判断にも関わる重要な工程です。

UATと他のテストの違い

UATを理解するうえでは、他のテストと何が違うのかを把握しておきましょう。

テスト種別	一般的な実施主体	主な確認内容	目的
単体テスト	開発者	個々の機能や処理	コードや機能単位の動作確認
結合テスト	開発者・QA	機能間の連携	モジュール同士の相互作用・整合性確認
システムテスト	開発者・QA	システム全体	システム全体が要件を満たすかの確認
UAT	発注側・利用部門・利用者	業務プロセス、利用者要件、受け入れ可否	業務で受け入れ可能かの確認

特に混同しやすいのが、システムテストとUATの違いです。

システムテストは、開発側の視点でシステム全体が要件通りに動作するかを確認する工程です。一方、UATは利用者の視点で、実際の業務や業務プロセスの中で受け入れ可能かをチェックする工程です。

同じ機能を触ることがあっても、確認の目的と判断基準は異なります。

受け入れテストの主な種類

受け入れテストにはいくつかの種類があり、「誰が」「どの観点で」「何を」確認するかによって役割が変わります。実際に使う現場担当者が使いやすさを確認する場合もあれば、運用担当者が保守しやすさをチェックする場合や、契約条件や法令への対応を確認する場合もあります。

そのため、受け入れテストを進める際は、「今回のプロジェクトでどの観点を確認するか」を先に決めておくことが求められます。

ユーザー受け入れテスト（UAT）

もっとも一般的な受け入れテストです。実際にシステムを使う利用部門や現場担当者が、業務で問題なく使えるかをチェックします。

たとえば、営業支援システムであれば「顧客情報の登録から案件管理までスムーズに進められるか」、申請システムであれば「申請から承認、通知まで現場の流れに合っているか」といった観点で確認します。

機能が動くかだけでなく、業務の中で違和感なく使えるかを見ることが大切です。

業務観点の受け入れ確認（BATと呼ばれることもあります）

個別の機能だけでなく、部門をまたぐ業務全体が成立するかを確認する考え方です。現場の担当者に加えて、部門責任者や業務設計に関わるメンバーが確認に加わることもあります。

たとえば、受発注システムの導入であれば、営業・受注処理・経理といった複数の部門をまたいで、業務が滞りなく進むかを検証します。

「機能は動くが、部門をまたぐ運用では使いにくい」といった問題を見つけるのに役立ちます。

運用受け入れテスト（OAT）

運用担当者や情報システム部門が、そのシステムを安定して運用・保守できるかを確認するテストです。

主な確認項目としては、次のようなものがあります。

• 監視ができるか
• バックアップと復旧ができるか
• 障害発生時に対応しやすいか
• アカウント管理や権限管理がしやすいか
• ログを確認できるか

たとえば、システム自体は問題なく動いていても、障害時の復旧が難しかったり、監視設定が不十分だったりすると、運用開始後に大きな負担になります。OATでは、実際に運用を回していけるかを検証します。

契約による受け入れテスト（CAT）

発注側と開発側で合意した契約条件や要件を満たしているかを確認するテストです。外部ベンダーに開発を委託したプロジェクトで重要になる考え方です。

たとえば、次のような項目を確認します。

• 契約で定めた機能が実装されているか
• 性能や対応範囲が合意内容を満たしているか
• 納品物やマニュアルがそろっているか

検収や納品受け入れの判断にも関わるため、事前に何を満たせば受け入れとするのかを明確にしておくことが欠かせません。

規制受け入れテスト（RAT）

法令・規制・関連ポリシーに適合しているかを確認するテストです。特に、金融・医療・公共・製造など、ルールや監査要件が厳しい分野で重要になります。

たとえば、次のような観点があります。

• 個人情報の扱いに問題がないか
• 監査で必要な記録が残るか
• 業界のガイドラインや社内ルールに沿っているか
• セキュリティ要件を満たしているか

通常の動作確認では問題がなくても、規制やルールに適合していなければ本番利用できないこともあるため、対象業界によっては欠かせない確認です。

アルファテスト

開発側のテスト環境で、開発チーム以外の関係者が行う公開前のチェックです。外部ユーザーに見せる前に、限られた関係者に試してもらう場面で使われます。

たとえば、新しいSaaS機能を正式公開する前に、営業部門やカスタマーサポート部門に使ってもらい、操作性や不具合を検証するケースがこれにあたります。

外部公開前の初期チェックとして活用しやすい方法です。

ベータテスト

開発側のテスト環境の外で、限定した外部ユーザーや一部の顧客に実際に使ってもらい、本番に近い形でフィードバックを得るテストです。

たとえば、新機能を一部ユーザーに先行公開し、以下の点を確認します。

• 操作しにくい点はないか
• 実際の利用環境で問題が起きないか
• 想定外の使われ方がないか

といった点を確認します。

社内だけでは気づきにくい課題を見つけやすいため、市場投入前の最終確認として有効です。

どの種類を選ぶべきか

受け入れテストは、プロジェクトによって必要な観点が異なります。1つだけを行うとは限らず、複数の種類を組み合わせて進めることも少なくありません。

たとえば、次のような組み合わせが考えられます。

• 業務システム導入：UATとOAT
• 外部ベンダーへの発注案件：UATとCAT
• 規制の厳しい業界のシステム：UATとRAT
• SaaSや新機能のリリース前：アルファテストとベータテスト

このように、受け入れテストは1つの決まった形ではなく、プロジェクトの目的に合わせて必要な観点を組み合わせるものと考えると理解しやすくなります。

UATで確認したい観点

UATでは、単に「エラーが出ないか」を見るだけでは不十分です。実際の業務で使うことを前提に、次のような観点を検証しておくと有効です。

• 主要な業務フローを最後まで完了できるか
• 例外的な操作や入力ミス時にも適切に動作するか
• 権限設定や承認フローが実運用に合っているか
• 帳票、通知、出力結果が業務で使える内容になっているか
• 現場の利用者が迷わず操作できるか
• 事前に定めた受け入れ基準を満たしているか

UATでは、機能単体の動作だけでなく、利用者が日々の業務を滞りなく進められるかをチェックします。

UATの進め方

UATは、単にテストを実施するだけでなく、何を基準に受け入れるのかを決め、実際の業務に近い形で確認し、見つかった課題に対応したうえで最終判断するまでの一連のプロセスとして進めることが求められます。

各工程の役割を把握しておくことで、UAT全体の目的や進め方が見えやすくなります。

受け入れ基準を決める

最初に行うのは、どの状態になれば「受け入れ可」と判断するのかを明確にすることです。ここが曖昧なままだと、テストを終える終了条件や優先順位も曖昧になります。事前に基準を設けて共有しておくことで、テストの途中や終了時の認識違いを防げます。

たとえば、以下のような基準が考えられます。

• 重大な不具合が残っていない
• 主要な業務フローがすべて完了できる
• 利用部門が業務上問題ないと判断している
• 運用開始に必要な手順書やマニュアルがそろっている

実運用に近い環境を用意する

次に、本番に近い環境を整えます。本番環境とかけ離れた状態で確認してしまうと、テスト中は問題が見つからなくても、実際の運用開始後に想定外の不具合や使いにくさが出ることがあります。

利用者の権限、データ、周辺システムとの連携など、できる限り本番に近い状態で実施することが重要です。

この工程では、実際の業務で起こり得る課題を、できるだけ事前に見つけやすくします。環境の再現性が低いと、UAT自体の精度も下がります。

業務シナリオに沿ってテストケースを作る

UATでは、画面ごとの動作確認だけでなく、業務の流れに沿ってチェックできるようにテストケースを業務シナリオごとに作成することが大切です。画面単位ではなく、申請や承認、通知、帳票出力といった一連の業務シナリオをもとにすると、実際の業務に近い確認がしやすくなります。

たとえば、「申請→承認→通知→帳票出力」までをひと続きの流れとして検証することで、画面単体では見えない業務上の使いやすさや抜け漏れが見つかりやすくなります。

現場ユーザーを交えて実施する

UATでは、情報システム部門だけでなく、実際にシステムを使う利用部門や現場担当者に参加してもらうことが求められます。開発側やIT部門だけでは気づきにくい操作上の違和感や、業務フローとのズレは、現場ユーザーが入ることで見つかりやすくなります。

この工程の目的は、実際の利用者の視点で、業務に無理なく組み込めるかを確認することです。UATが他のテストと大きく異なるのは、この利用者視点が中心になる点にあります。

不具合を管理し、再テストを行う

UATの中で見つかった課題や不具合は、その場で終わらせず、内容を記録し、重大度、再現条件、影響範囲ごとに管理しておく必要があります。修正後には、影響が出る範囲を含めて再度チェックを行います。

合否判定を行う

最後に、あらかじめ定めた受け入れ基準を満たしているかを確認し、正式に受け入れ可否を判断します。ここでは、単に不具合が減ったかを見るのではなく、業務として利用開始できる状態にあるかを総合的に判断することが求められます。

UATの質を保つために意識したいこと

UATを形だけの確認で終わらせず、実際の業務に沿った確認にするには、いくつか意識したい点があります。特に、準備を始める時期、現場視点、判断基準の明確さ、情報共有の方法は、UAT全体の質に影響しやすい要素です。

早い段階で準備を始める

UATは開発終盤に実施される工程ですが、準備まで終盤に回してしまうと、十分な確認時間を確保しにくくなります。受け入れ基準やテスト方針、テスト体制などは、できるだけ早い段階から固めておくことが重要です。

開発の遅延が発生した場合でも、UATの準備ができていれば、限られた期間の中で優先順位をつけて確認しやすくなります。UATは、本番前だけの確認作業ではなく、プロジェクト全体の中で早めに準備を進める工程として捉えることが大切です。

現場視点を必ず入れる

IT部門や開発側だけでUATを進めると、現場ならではの使いにくさや、業務フローとの細かなズレを見落とすことがあります。実際の利用者が参加することで、業務上の違和感や、運用開始後に負担になりそうな点に気づきやすくなります。

たとえば、画面の入力順や確認項目の並び、帳票の見やすさ、承認の流れなどは、仕様上は問題がなくても、現場では使いにくいと感じられることがあります。UATでは、実際に使う立場の視点を取り入れることが重要です。

合格基準を曖昧にしない

「大きな問題がなければOK」といった曖昧な基準では、判断があいまいになります。重大不具合をどう扱うのか、どの業務フローが完了していれば受け入れ可能とするのかを、事前に明確にしておくことが欠かせません。

合格基準が明確であれば、テストの途中で何を優先してチェックするかも判断しやすくなります。逆に、基準が曖昧なままだと、テストを終える条件が見えにくくなり、手戻りや認識のズレが生じやすくなります。

記録と共有を徹底する

UATで見つかった課題や判断結果を口頭だけで済ませると、後から認識のズレが起こりやすくなります。指摘事項は、内容、重大度、再現条件、対応状況などを記録し、関係者間で見える形にしておくことが重要です。

課題管理ツールや表計算シートなどを活用し、誰が見ても状況がわかるようにしておくことで、開発側とのやり取りや再テストも進めやすくなります。UATでは、確認すること自体だけでなく、その結果を正しく残し、共有できる状態にすることも大切です。

UATでよくある失敗

UATでは、手順そのものよりも、進め方や体制の整え方によって失敗が起こることがあります。特に、期間不足、確認範囲の偏り、現場理解の不足、判断基準の曖昧さは、現場で起こりやすい代表的な課題です。

UATの期間が足りない

開発遅延の影響を受けて、UATの期間が短くなるケースも多いです。その結果、表面的な確認にとどまり、業務シナリオ全体を十分に検証できないまま本番に進んでしまうことがあります。

UATは、問題が見つかれば修正と再確認も必要になるため、単純に「確認するだけの期間」を確保すればよいわけではありません。スケジュールを組む際は、指摘対応や再テストまで含めた期間を見込んでおくことが望ましいです。

画面確認だけで終わってしまう

画面ごとの動作確認だけでは、業務全体で使ったときの課題を見つけにくくなります。個別画面では問題がなくても、前後の処理や部門間の受け渡しまで含めて見ると、現場では使いにくいケースもあります。

UATでは、画面単位ではなく、申請から承認・通知・帳票出力までのような業務シナリオ単位でチェックすることが重要です。システムの完成度を見るのではなく、業務の中で成立するかを見る意識が求められます。

テスターが現場業務を十分に理解していない

実際の業務を知らないメンバーだけで進めると、現場視点の検証が不足しやすくなります。利用開始後になってから「実際の運用に合わない」「作業手順が増えてしまった」といった問題が見つかることがあります。

業務フローが複雑なシステムや、部門をまたいで使うシステムでは、現場の理解がないままでは十分な確認が難しくなります。利用部門の参加は、できるだけ早い段階で調整しておくことが望まれます。

合否の判断基準が曖昧

完了条件が曖昧だと何度も差し戻しが発生したり、逆に十分な確認をしないまま受け入れてしまったりするリスクがあります。

「どの不具合まで許容するのか」「どの業務フローが確認できればよいのか」が決まっていないと、関係者ごとに判断が分かれやすくなります。

UATでは、最終的に受け入れ可否を判断する必要があるため、判断基準を事前に文書化し、関係者間で共有しておくことが重要です。

AIや自動化を活用したUATの効率化

近年は、生成AIや支援ツール、自動テストを活用し、UATの準備や周辺作業の負担を減らす動きが広がっています。受け入れ判断そのものをすべて自動化するのは難しいものの、テストケースのたたき台作成、再テスト、指摘内容の要約や集約などは取り入れやすい領域です。

受け入れ可否の最終判断は人が担いながら、準備や再確認の一部をAIや自動化で補う使い方が現実的です。

テストケース作成を効率化する

要件定義書やユーザーストーリー、業務フローをもとに、生成AIでテストケースのたたき台を作成する使い方があります。ゼロから人が書き起こすよりも、まずAIで初稿を作り、その後に業務観点や優先順位を人が調整するほうが、効率よく進められるケースもあります。

特に、確認項目が多い案件では、抜け漏れの確認や確認観点を広げる際に役立ちます。

再テストや回帰テストを効率化する

定型的な操作については、自動テストツールやRPAを活用することで、再テストや回帰テストの負担を軽減できます。UATは利用者視点での確認が中心になるため、すべてを自動化するのは難しいものの、毎回同じ手順で確認する部分は自動化と相性がよい領域です。

たとえば、入力チェックや画面遷移、通知処理、帳票出力など、繰り返し確認が必要な処理は効率化しやすい部分です。

指摘内容の集約や分析を支援する

生成AIを使って、不具合報告の要約、分類、傾向分析を行うケースも増えています。複数部門から指摘が上がるプロジェクトでは、内容の重複や優先順位が見えにくくなることがありますが、AIを使うことで共通点を拾いやすくなります。

その結果、開発側とのやり取りや対応判断がしやすくなり、プロジェクト全体の意思決定のスピード向上にもつながります。

AIシステムのUATで確認したいこと

生成AIやAIエージェントを組み込んだシステムでは、通常のUATに加えて、AI特有の確認観点も意識しておくことが重要です。従来のシステムのように「仕様通りに動くか」だけではなく、回答の再現性、安全性、機密情報の扱い、業務で使う際の許容範囲まで確認する必要があります。

回答の再現性と許容範囲

同じような質問や条件に対して、業務上許容できる範囲の回答が返ってくるかをチェックします。AIは入力の違いや文脈によって出力が変わるため、毎回完全に同じ結果になるとは限りません。そのため、完全一致ではなく、どの程度のばらつきまで受け入れるかを先に決めておくことが大切です。

誤回答や不適切な出力がないか

業務で使う以上、誤情報や不適切な出力がどの程度発生するかは重要な確認項目です。社内問い合わせ対応や顧客対応に活用する場合は、誤回答がそのまま業務ミスや信用低下につながる可能性があります。

事実と異なる回答、業務上ふさわしくない内容、利用者に誤解を与える出力がないかを慎重に見ておく必要があります。

判断に偏りが出ないか

採用、審査、問い合わせ振り分けなど、人への対応や判断に関わる用途では、特定の属性や条件に偏った出力がされていないかの確認が必要です。入力例を変えても不当な差が出ないかを検証しておくことで、運用開始後のトラブルを防げます。

プロンプト設計が意図通り機能するか

AIへの指示内容によって、出力品質は大きく変わります。想定した質問や利用シーンに対して、プロンプトや設定が意図通りに機能し、回答範囲や禁止事項が守られているかをチェックすることが重要です。

社内向けFAQであれば「回答は簡潔にする」「不明な場合は推測せず案内先を示す」といったルールが、出力に正しく反映されているかを見る必要があります。

機密情報の扱いと不正な誘導への耐性

AIを含むシステムでは、機密情報の漏えい防止や不正な誘導への耐性も欠かせません。外部入力によって意図しない出力が生じないか、社内ルールや禁止事項を逸脱していないか、機密情報や個人情報を不用意に出力しないかを検証する必要があります。

特に、外部公開するチャットボットや業務支援AIでは、プロンプトインジェクションのような誘導に対して、どこまで耐えられるかを事前に見ておくことが大切です。

利用条件を決めたうえで受け入れ可否を判断する

AIを組み込んだシステムでは、単に機能が動くかだけでなく、どの利用条件なら業務で使えるかを定めた上で受け入れ可否を判断することが望ましいです。UATでは、利用者視点での使いやすさに加えて、回答品質、安全性、運用上のリスクを確認し、必要に応じて利用範囲や禁止事項も合わせて決めます。

UATに役立つツール

UATでは、テストそのものだけでなく、課題の管理やテストケースの管理、再テストの効率化も重要です。そのため、プロジェクトでは課題管理ツール、テスト管理ツール、テスト自動化ツールを組み合わせて使うケースが多く見られます。どのツールが適しているかは、プロジェクト規模や社内体制、既存の開発環境との相性を踏まえて判断することが求められます。

課題・進捗管理ツール

Jira

Jiraは、課題管理やバグ管理に強みのある代表的なツールです。ワークフローやステータス管理、通知、可視化の仕組みが充実しており、UATで見つかった不具合や確認事項を管理しながら進めたいプロジェクトに向いています。開発チームと利用部門のやり取りを一元化しやすい点も特徴です。

Redmine

Redmineは、複数プロジェクト管理、柔軟な課題管理、ロールベースの権限設定、ガントチャート、Wiki、SCM連携などを備えたオープンソースの管理ツールです。すでに社内でRedmine運用が定着している場合は、UATの指摘管理にもそのまま活用しやすい選択肢です。

Backlog

Backlogは、課題管理に加えて、Wiki、ドキュメント、Git / SVN などを1つの基盤で扱えるツールです。情報システム部門と現場部門が同じ場所で課題、ナレッジ、関連ファイルを確認しながらUATを進めたい案件で使いやすい選択肢です。

テスト管理ツール

TestRail

TestRailは、テストケースの設計、テストスイートの管理、テスト実行、結果記録までを行えるWebベースのテスト管理ツールです。ExcelでUATケースを管理していると煩雑になりやすいため、ケース数が多い案件や、実施状況を見える形で追いたい案件で使いやすいツールです。

Zephyr

Zephyrは、Jira上でテストケースの作成、ユーザーストーリーとの紐づけ、進捗管理、テスト結果の可視化ができるテスト管理ツールです。すでにJiraを使って開発管理をしている組織では、課題管理とテスト管理を同じ基盤で扱いやすい点がメリットです。

テスト自動化ツール

Playwright

Playwrightは、Chromium、Firefox、WebKitを1つのAPIで操作できるWebテスト自動化フレームワークです。公式にcodegenも用意されており、ブラウザ操作からテストコードのたたき台を生成できます。繰り返し確認が必要な画面操作や回帰テストの効率化に向いています。

Cypress

Cypressは、ブラウザ内で実行しながらデバッグしやすいフロントエンド向けのテストツールです。失敗したテストをブラウザの開発者ツールで確認しやすく、Webアプリの画面操作を確かめながら進めたい場合に向いています。

Selenium

Seleniumは、Webブラウザ自動化の代表的なプロジェクトで、WebDriverを通じてブラウザをネイティブに操作できます。長く使われてきた実績があり、幅広い言語や環境に対応しやすいため、既存資産がある企業や柔軟なカスタマイズを重視するケースで候補になります。

mabl

mablは、Web、モバイル、APIに対応したAIネイティブのテスト自動化プラットフォームです。ローコード機能や AI Auto-Healing を備えており、保守負担を抑えながら自動化を進めたい場合の候補になります。

ツール選定で見ておきたいポイント

どのツールを選ぶかは、機能の多さだけで決めるのではなく、既存の開発・運用環境と連携しやすいか、UATの参加者が使いこなせるか、継続運用しやすいかまで含めて考えることが重要です。

たとえば、Jiraを中心に開発管理をしている組織ならZephyrとの相性がよく、Excel管理から脱却したい場合はTestRail、回帰テストの効率化を重視するならPlaywrightやCypress、Selenium、mablなどが候補になります。

まとめ

UAT（受け入れテスト）は、開発されたシステムが実際の業務で受け入れ可能かを確認する最終工程です。仕様通りに動くことと、現場で問題なく使えることは同じではありません。そのギャップを埋めるのがUATの役割です。

近年は生成AIを活用したシステムも増えており、従来の業務適合性に加えて、回答の再現性、誤回答リスク、判断の偏り、安全性、機密情報の扱いといった観点も重要になっています。

UATを形だけで終わらせず、現場視点・業務視点で丁寧に確認することが、リリース後のトラブルを減らし、システムを定着させるうえで大切です。

アイスマイリーでは、生成AI のサービス比較と企業一覧を無料配布しています。課題や目的に応じたサービスを比較検討できますので、ぜひこの機会にお問い合わせください。