「受け入れテストをやってほしい」と開発会社から言われたが、何をどう確認すればいいのかわからない。そう感じている発注者の方は少なくありません。
UATは、システム開発の最終段階で発注者が実施するテストです。「合格させてしまった後は変更要求が難しくなる」という現実がある一方で、「何をどこまで確認すれば合格にしていいのか」という基準が曖昧なまま進めてしまうケースが多くあります。
この記事では、発注者として主体的にUATを進めるために必要な知識をすべて解説します。確認すべき項目のチェックリスト、テストシナリオの作り方、AI機能を含むシステムに特有のチェックポイント、そして「何をもって合格とするか」の判断基準まで、実践的な内容をお伝えします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
UAT（受け入れテスト）とは何か
UATの定義と開発テストとの違い
UAT（User Acceptance Test）は、開発を依頼したシステムに問題がないかを発注者が確認するテストです。日本語では「ユーザー受け入れテスト」「受け入れテスト」「検収テスト」とも呼ばれます。
システム開発には、一般的に以下の4段階のテスト工程があります。
テスト種類 | 実施者 | 目的 |
|---|---|---|
単体テスト（UT） | 開発会社 | 個々の機能・画面単体の動作確認 |
結合テスト（IT） | 開発会社 | 複数機能をまたいだ連携の確認 |
システムテスト（ST） | 開発会社 | システム全体を統合した最終動作確認 |
受け入れテスト（UAT） | 発注者 | 業務要件の充足・実運用環境での動作確認 |
単体テスト〜システムテストは開発会社が主体となって実施します。UATは唯一、発注者が主体となって行うテストです。開発会社が「技術的に正しく動く」ことを確認するのに対し、発注者は「実際の業務で使えるか」を確認する役割を担います。
なぜUATが発注者の責任なのか
UATには、単なる動作確認以上の意味があります。
受け入れ判断には法的な意味がある
受託開発の契約において、UATの合格（受け入れ承認）はシステムを「問題なし」として受け取ったことを意味します。この承認を行った後は、「仕様が違う」「この機能が要件と異なる」という主張が難しくなります。
つまり、UATは「発注者として最後のチェックができるタイミング」です。開発会社任せにしてしまうと、後になって問題が見つかった際にコスト増や紛争につながるリスクがあります。
発注者にしか確認できないことがある
開発会社は技術的な正確性は確認できますが、「業務の現場で本当に使えるか」は発注者しか判断できません。たとえば：
- 「承認フローが実際の社内規程と合っているか」
- 「入力画面の順序が現場の作業手順と合っているか」
- 「エラーメッセージが現場のスタッフに理解できるか」
これらは発注者側の業務知識がないと確認できない項目です。開発会社に任せることは、そもそも不可能な部分があります。
UATで発注者が確認すべき項目
基本機能の確認（要件定義との突合）
最初の確認は「要件定義書に書いたことが実装されているか」です。
確認ポイント:
- 画面の入力項目・表示項目が仕様書通りか
- ボタンの動作・リンク先が正しいか
- 入力バリデーション（必須チェック・文字数制限・形式チェック）が機能するか
- データの保存・更新・削除が正しく動作するか
- 一覧画面の検索・絞り込み・並び替えが要件通りか
チェックリストとして活用する際は、要件定義書の項目を1行1チェックボックスに変換し、「確認済み」「NG」「保留」の3択で記録していきましょう。
業務フローに沿ったシナリオテスト
個別機能の確認が終わったら、実際の業務の流れ通しで動かす「シナリオテスト」を実施します。
シナリオテストとは、「実際にこのシステムを使って業務を行う」という想定で、一連の操作を最初から最後まで通して確認するテストです。
シナリオ例（受発注管理システムの場合）:
シナリオA: 新規注文の受付から請求書発行まで
1. 顧客から注文を受ける → 注文登録画面で入力
2. 上長が注文を承認 → 承認通知メールが届く
3. 在庫を引き当て → 在庫数量が正しく減少する
4. 出荷処理を実施 → 出荷履歴に記録される
5. 請求書を発行 → 正しい金額・宛先で発行される
重要なのは「正常系（普通に使えるか）」だけでなく「異常系・例外系」も確認することです。
異常系・例外系のチェックポイント:
- 在庫不足の状態で注文を入れようとした場合
- 権限のないユーザーが承認操作をしようとした場合
- 処理の途中でブラウザを閉じてしまった場合
- 大量データを一括登録した場合
業務の「うまくいかない場面」でシステムが適切に対応できるかどうかが、実運用での安定性を左右します。
非機能要件の確認
「動く」だけでなく、「業務の現場で使い続けられるか」という観点での確認も必要です。
性能（パフォーマンス）:
- 繁忙期に想定される同時アクセス数でも処理速度が落ちないか
- 大量データ（数千件〜数万件）の検索・集計が実用的な速度で動くか
セキュリティ:
- 権限設定が正しく機能しているか（一般ユーザーが管理者メニューにアクセスできないか）
- ログイン認証・セッション管理が適切か
- 個人情報・機密情報へのアクセス制御が機能しているか
互換性:
- 社内で使用しているブラウザ（Chrome・Edge・Safari等）での動作確認
- スマートフォン・タブレットでの利用が想定される場合の動作確認
テストシナリオの作り方
業務フローを基にしたシナリオ設計
テストシナリオは、難しく考える必要はありません。「今の業務でやっていること」をそのままシナリオにするのが最も確実な方法です。
手順:
- 対象システムで実行される業務フロー（開始〜完了）を書き出す
- 各業務フローを「誰が」「何をする」という形式で整理する
- それぞれの操作に対して「こうなるはず」という期待結果を書く
ユーザーストーリー形式での書き方:
シナリオID: SC-001
シナリオ名: 営業担当者による顧客登録
前提条件: 新規顧客からの問い合わせがあった
操作手順:
1. [顧客管理] > [新規登録] を開く
2. 会社名・担当者名・連絡先を入力する
3. [登録] ボタンを押す
期待結果:
- 顧客一覧に追加される
- 登録完了のメッセージが表示される
- 入力した内容が正しく保存されている
テストケースの具体例
シナリオをもとに「正常系」と「異常系」の両方のテストケースを用意します。
正常系（期待通りに動く場合）:
- 必須項目をすべて入力して登録する → 正常に登録される
異常系（エラーになるべき場合）:
- 必須項目（会社名）を空欄のまま登録する → 「必須項目です」エラーが表示される
- メールアドレスに不正な形式（「@」なし）を入力する → 「メールアドレスの形式が正しくありません」エラーが表示される
テストの記録は以下のような表形式で管理すると、後の整理がしやすくなります。
テストID | シナリオ名 | 操作 | 期待結果 | 実際の結果 | 判定 |
|---|---|---|---|---|---|
TC-001 | 顧客登録 | 全項目入力→登録 | 一覧に表示 | 一覧に表示された | 合格 |
TC-002 | 顧客登録（異常系） | 会社名空欄→登録 | エラーメッセージ表示 | 入力フォームが空のまま登録された | 不合格 |
AI機能を含むシステムのUAT特有チェック項目
近年、チャットボット・文章生成・需要予測など、AI機能を搭載したシステムの発注が増えています。AI機能のUATは、通常の機能テストと異なる観点が必要です。
AI機能のUATが通常と異なる理由
通常の機能テストは「同じ入力→同じ出力」が前提です。しかしAI機能、特に生成AI（ChatGPTのような大規模言語モデル等）は非決定論的な動作をします。つまり、同じ質問に対しても毎回異なる回答が生成される可能性があります。
そのため、AI機能のUATでは「この入力に対してこの出力が出るか」という単純な一致確認ではなく、「品質基準の範囲内の出力が継続的に出るか」という観点でテストする必要があります。
AI機能のチェック項目
出力品質の評価基準の設定（事前に開発会社と合意）:
- 誤回答率の許容範囲を数値で定める（例: 100問中95問以上が正しい回答）
- 「正解」の判断基準を明示する（だれが見ても判断できる基準であること）
ハルシネーション（事実と異なる生成）の確認:
- AI機能が意図した業務範囲外の情報を自信満々に提示しないか
- 確認方法: 答えが明確に定まっている質問（例: 自社の商品名・価格）を多数投げて回答の正確性を計測する
フォールバック動作の確認:
- AIが回答不能な質問に対して「わかりません」と適切に回答するか
- AI機能が利用不能な場合（APIエラー等）に、システム全体がクラッシュしないか
個人情報・機密情報の取り扱い:
- 入力した個人情報がAIの学習データとして外部に送信されないか
- セキュリティポリシーに沿ったデータ管理がされているか（開発会社に書面で確認することを推奨）
合格・不合格の判断基準と次のステップ
UATの最大の難しさは「何をもって合格とするか」がわからないことです。このセクションでは、判断基準の設定方法を具体的に解説します。
UATの合格基準の設定方法
合格基準はUAT開始前に、テスト計画書に明記しておく必要があります。開始後に基準を設けようとすると、開発会社と発注者の間で認識が食い違いやすくなります。
不具合の重大度分類と合格条件（例）:
重大度 | 定義 | 合格条件（例） |
|---|---|---|
Critical（致命的） | 業務が全面停止する不具合（データ消失・ログイン不可等） | 0件 で合格 |
Major（重大） | 一部の業務が正常に行えない不具合 | テスト期間内に修正完了で合格 |
Minor（軽微） | 回避策があり業務継続可能な不具合 | 合計 5件以内 で合格（修正は次回リリース対応可） |
この表は一例です。実際のシステムの重要度・リリーススケジュール・業務への影響に応じて、開発会社と事前に合意して設定しましょう。
不合格・保留の場合の対応
UATで不具合が見つかった場合は、以下の手順で対応します。
- 不具合票に記録する: 発生手順・期待結果・実際の結果・スクリーンショットを記録
- 重大度を分類する: Critical / Major / Minor のいずれかに分類
- 開発会社にフィードバック: 不具合票を共有し、修正期限を合意する
- 修正後に再テスト: 修正が完了したら、同じシナリオで再度確認する
「不具合」と「要望（追加機能の要求）」を明確に区別することが重要です。「仕様書に書いてないが、あったほうが便利な機能」は追加開発の話し合いとなり、UATの合否とは別の問題です。
UAT完了後の次のステップ
UATの合格基準を満たしたら、最終承認のステップに進みます。
- 受け入れ書（サインオフ）への署名: UATを合格と判断し、システムを受け入れることを正式に承認する書類
- 本番環境への移行準備: 本番データの移行・システムの切り替えスケジュールの確認
- ユーザートレーニング: 現場スタッフへの操作説明・マニュアル配布
なお、UATの合格は「受け入れテストの合格」であり、法的な意味での最終受け入れ（検収）とは異なります。検収は契約上の最終的な成果物の受け取りを意味し、品質保証の観点で重要な意義を持ちます。検収の手続き・チェックリストについてはシステム開発の検収・受け入れテストの進め方で詳しく解説しています。
まとめ
UAT（受け入れテスト）は、発注者がシステムを受け入れるかどうかを最終的に判断するテストです。開発会社任せにするのではなく、発注者が主体的に動くことが、後々のトラブルを防ぐうえで非常に重要です。
本記事で解説した内容をまとめます：
- UATは発注者の責任: 受け入れ承認後は要求変更が難しくなるため、発注者自身が業務フローに沿って確認する
- チェック項目の3本柱: 基本機能（要件定義との突合）・業務シナリオテスト・非機能要件
- シナリオは業務フローから作る: 難しく考えず、実際の業務手順をそのままシナリオにする
- AI機能は非決定論的な評価が必要: 品質基準・ハルシネーション対策・フォールバック動作を重点確認
- 合否基準はUAT開始前に合意: 不具合の重大度分類と合格条件を書面で合意しておく
システム開発をご検討中の場合や、UAT支援も含めた開発パートナーをお探しの場合は、秋霜堂株式会社にお気軽にご相談ください。要件定義から受け入れテストまで、発注者に伴走する開発体制でご支援します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
