ベンダーのテストは「設計書通りに動くか」を確認します。しかし発注側の検収、つまり受入テスト（UAT）で同じことを確認しても、業務で使えるシステムかどうかは分かりません。受入テストの主担当は発注側であり、ベンダーはデータの仕込みや問い合わせ対応といった受入支援に回るのが標準的な分担です。この記事では、検収基準を「現場の業務が止まらないか」に置き直した受入テスト項目の設計方法と、確認作業をAIで効率化する実践プロンプト、テスト自動化への発展までを解説します。

---

受入テスト項目は4カテゴリで設計する

1. 業務適合性（機能要件）。ボタン単位の動作確認ではなく、業務シナリオの「一筆書き」で確認します。販売管理システムなら、見積作成から受注登録、在庫引当、出荷指示、請求書発行までが途切れず流れるか。あわせて、現場でよく起きるイレギュラーからの復帰も項目にします。出荷指示後にキャンセルの連絡が来たとき、出荷を取り消して在庫数を正確に戻せるか。一般社員が100万円以上の値引きを入力したとき、上長の承認待ちに移行するか。

2. 現場での実用性（非機能要件）。「動くけれど遅くて使えない」を排除します。実データ量に近い件数を入れた状態で検索が業務の許容時間内に返るか、現場で実際に使う端末で入力フォームが快適に操作できるか、月末の締め日に全社員が一斉にアクセスしても耐えられるか、といった項目です。

3. データの連続性（移行・連携）。旧字体（﨑、髙など）を含む氏名や過去数年分の履歴が欠損なく移行されているか、新システムから出力したデータを既存の給与計算システムなどに取り込めるか。新システムが孤立しないことを確認します。

4. 納品物（ドキュメント）。システムに触れたことのない社員がマニュアルだけで基本操作を完了できるか、検収中に依頼した仕様変更が最終版の設計書に反映されているか。稼働後の保守運用を回すための資産のチェックです。

AIに4つの役を任せる

受入テストは確認項目が膨大になりがちです。準備と整理をAIに任せ、人間は「実際にシステムを触り倒す」ことに集中します。カテゴリごとにAIの役割を決めておくと使いどころが明確になります。

シナリオ起案者（業務適合性）。人間がテストパターンを洗い出すと正常系に偏ります。業務フローをAIに読み込ませ、異常系のたたき台を作らせます。

以下の「受注管理の業務フロー」を読み込み、受入テスト用のテストシナリオを作成してください。特に、現場で発生しうる「ユーザーの入力ミス」「タイミングの重複」「顧客からのイレギュラーな要望」といった異常系・例外処理のテスト項目を10個挙げてください。表形式で出力してください。

IT用語の翻訳家（実用性）。ベンダーの負荷テスト報告書は専門的で、業務部門には妥当性を判断しにくいものです。AIに要点を平易に解説させ、ベンダーへ返すべき質問の準備をします。

ベンダーから以下の「負荷テスト結果報告書」が提出されました。ITの専門知識がない業務部門の責任者向けに、要点を分かりやすく解説してください。特に「月末に全社員（約500名）が一斉にログインして経費精算システムを使った場合、実業務に支障が出るレベルの遅延やシステムダウンが発生するリスクがあるか」という観点で評価してください。

ダミーデータ生成と照合（データ連続性）。個人情報を含む本番データをテストに使うのは危険です。旧字体入りの氏名や極端に長い住所を意図的に混ぜた架空データをAIに生成させます。移行前後のCSVを比較して差異を見つけるスクリプトを書かせるのも効果的です。

ドキュメント整合性チェッカー（納品物）。要件定義書の機能一覧とマニュアルの目次を比較させ、記載漏れを検出します。現場担当者の「検索したら固まった」という雑なメモを、再現手順・期待結果・実際の結果が整理されたバグ報告に書き直させると、ベンダーとのやりとりのズレも減ります。

注意点もあります。実際に画面を操作して合否を判定することと、「この使い勝手が現場の感覚に合うか」という評価は、AIには任せられません。AIで浮いた時間は、人間がシステムを触る時間に充てます。

受け入れ基準を上流でGherkin化しておくと、テストは自動化に近づく

ここまでは納品されたシステムを検収する話でしたが、テストの効率は検収のずっと前、要件定義の書き方で決まります。受け入れ基準を「問題なく動作すること」のような文章ではなく、Given（前提）・When（操作）・Then（期待結果）のGherkin形式で事前合意しておくと、そこからE2Eテストシナリオを自動生成できるようになります。

gaipackのAIDDスキームはこの形を標準にしています。開発の最小単位（PBI）に受け入れ条件をGherkin形式で記述し、それをE2Eテストの自動生成に使います。さらに、要件から機能要件、E2Eテスト、テストケース、タスク、実装までを追跡する対応表を生成してカバレッジの抜け漏れを可視化します。人間がゼロからテスト設計をするのではなく、要件の時点でテスト可能な形に書いておき、AIに展開させる、という順序です。

検収の場面でも、この仕組みは発注側を助けます。受け入れ基準が最初から検証可能な形で合意されているため、「何をもって合格とするか」の解釈が揉めにくくなります。gaipackのAIDD MVPでは「受け入れレビュー支援」として、リリース直前の実物と受け入れ試験結果にフォーカスし、シナリオ実行動画の確認と定型チェックポイントのAIレビューで、人間（PO）の判断が必要な箇所だけをAIがピックアップして提示する形を取っています。

レガシーシステムの刷新では、さらに踏み込んだ検証もあります。gaipackのAIDD モダナイズでは「現新同一性ハーネス」という仕組みで、要件定義のGherkinシナリオを旧システムと新システムの両方に注入し、DBの更新・APIの応答・画面出力の3層を機械的に全件比較します。AIがコードとテストシナリオを作り、その成果物をAIではなく決定論的な機械比較が裁く、という設計です。「ベテランが確認したから大丈夫」という属人的な検収を、「出力とDB更新が現行と一致している」という客観的な証明に置き換えられます。

まとめ

gaipackでは、受け入れレビュー支援を含む3ヶ月のPoCパッケージをAIDD MVPとして、現新同一性ハーネスによるレガシー刷新をAIDD モダナイズとして提供しています。検収・受入テストの体制づくりでお悩みでしたら、お気軽にKDDIアイレットへお問い合わせください！