UAT は、BA とビジネスステークホルダーがリリース前に実行する最終テストラウンドです。従来の機能では合格/不合格が明確です。AI 機能では、AI が技術的には動作する可能性がありますが、ビジネスはまだそれを受け入れる準備ができていません。
1. 従来の UAT と何が異なるか
| 側面 | 従来の機能 | AI 機能 |
|---|---|---|
| テストケース | Input X → Output Y 固定 | Input X → Output Y 可変 |
| 合格/不合格 | バイナリ | 「受け入れ可能な範囲」の可能性あり |
| エッジケース | 有限、リストアップ可能 | ほぼ無限 |
| バイアステスト | 不要 | 必須 |
| ユーザー信頼 | 関連性少ない | 重要（ユーザーは AI を信頼しているか？） |
| ロールバック | コードリバート | モデルバージョンロールバックが必要な場合あり |
2. AI 機能用 3 層式 UAT
層 1：機能 UAT（従来型）
コアビジネスフローをテスト：
- 受け入れ基準に従うハッピーパス
- 無効入力のエラーハンドリング
- 他のシステムとの統合
層 2：AI 出力品質 UAT
ビジネスコンテキストで AI 出力品質をテスト：
- 精度：テストセットの正確性はどの程度か？
- 関連性：回答はコンテキストに対応しているか？
- 幻覚チェック：AI は情報を作成しているか？
- トーン・形式：ブランド/ポリシーに合っているか？
方法： BA + ドメインエキスパートがゴールデンテストセットを準備します。50～100 のサンプル入力と期待される出力。AI でこのセットを実行してスコアリングします。
ゴールデンテストセット テンプレート：
| テスト ID | 入力 | 期待 | 実際 | 合否 | 備考 |
|---------|------|------|------|------|------|
| TC-001 | 「利率は...」 | 「現在の利率は...」 | ... | ... | ... |
層 3：ビジネスレディネス UAT
組織的準備をテスト（システムだけではない）：
- ユーザーは訓練を受けていますか？
- ヘルプデスク/エージェントは AI の失敗時に対処できますか？
- ロールバック手順は準備ができていますか？
- 監視ダッシュボードはライブですか？
3. AI 機能用 UAT プランテンプレート
# UAT プラン：[機能名]
## 1. スコープと目標
- 機能：[説明]
- UAT 期間：[開始 → 終了日]
- 環境：[UAT env URL、データセット]
- 目標：検証 [ビジネス目標のリスト]
## 2. 参加者
| 役割 | 担当者 | 責任 |
|------|--------|------|
| UAT リード (BA) | ... | プラン、調整、サインオフ |
| ビジネステスター | ... | テストケース実行 |
| ドメインエキスパート | ... | AI 出力品質評価 |
| プロダクトオーナー | ... | Go/No-Go 決定 |
## 3. テストシナリオ
### グループ A：機能（合格必須）
- [TC-F-001] ハッピーパス：[説明]
- [TC-F-002] エラーパス：[説明]
### グループ B：AI 品質（受け入れ閾値）
- [TC-AI-001] ゴールデンテストセットの精度 ≥ [N]%
- [TC-AI-002] テストセットの幻覚率 ≤ [M]%
- [TC-AI-003] 信頼度 < 閾値の場合のエスカレーション正確
### グループ C：ビジネスレディネス（完了必須）
- [TC-BR-001] 訓練資料 [チーム] でレビュー
- [TC-BR-002] ロールバック手順テスト
- [TC-BR-003] 監視アラート構成
4. Go/No-Go 決定フレームワーク
BA は UAT 結果を統合して go/no-go を提案します：
| カテゴリ | 基準 | ステータス | 重み |
|---|---|---|---|
| ブロッカー | 重大欠陥 0 件 | ✅/❌ | 合格必須 |
| ブロッカー | 精度 ≥ 閾値 | ✅/❌ | 合格必須 |
| ブロッカー | 人間オーバーライド動作 | ✅/❌ | 合格必須 |
| 重要 | すべてのハッピーパス合格 | ✅/❌ | 高 |
| 重要 | ビジネステスターサインオフ | ✅/❌ | 高 |
| あると良い | すべてのエッジケース合格 | ✅/❌ | 中 |
| あると良い | SLA 内のパフォーマンス | ✅/❌ | 中 |
決定ルール：
- ✅ すべてのブロッカー → GO
- ❌ 任意のブロッカー → NO-GO（修正して再テスト）
- ブロッカー OK で重要欠陥あり → 既知の問題付き GO（明確に伝える）
5. ビジネスレディネスチェックリスト
リリース前に BA が検証：
ユーザー訓練
☐ ユーザーガイド/FAQ 記述・レビュー
☐ 訓練セッションスケジュール
☐ ユーザー用サンドボックス/デモ環境
☐ 変更管理メール下書き
サポート準備
☐ ヘルプデスク/エージェントは AI が失敗する可能性があることを理解
☐ AI → エージェント → スーパーバイザーへのエスカレーションパス明確
☐ AI 制限についての FAQ サポートチーム向け
☐ 既知の制限事項ドキュメント配布
技術的準備
☐ 監視ダッシュボードライブ・テスト
☐ アラートルール設定（精度低下、エラー率スパイク）
☐ ロールバック手順記載・テスト
☐ リリース日のオンコール スケジュール
コミュニケーション
☐ リリース告知ドラフト承認
☐ 内部ステークホルダー [N] 日前通知
☐ 外部コミュニケーション（あれば）承認
6. AI 機能のロールアウト戦略
100% 即座ローンチは危険です。一般的な戦略：
| 戦略 | 使用時 | リスク |
|---|---|---|
| フルローンチ | 低リスク、高信頼 | 最高 |
| カナリア (5% → 20% → 100%) | 中リスク、監視必要 | より低い、早期問題検出 |
| A/B テスト | ビジネスインパクト測定したい | サンプルサイズ必要 |
| シャドウモード | AI がバックグラウンドで実行、人間が決定 | ユーザーインパクトなし、データ収集 |
まとめ
良い AI 機能 UAT = 機能テスト + AI 品質テスト + ビジネスレディネス。BA が 3 つをつなぎます。テストケース実行者ではなく。
重要な思考転換：絶対的な合格/不合格ではなく受け入れ閾値。AI 精度 85% は「十分」である可能性があります。ただし「十分」はステークホルダーが事前に同意する必要があります。結果後の決定ではなく。