ストーリー
田
田中VPoE
「RPA×AI統合と承認フローの設計が終わった。本番運用に入る前に、テスト戦略を立てる必要がある。AIシステムのテストは従来のシステムテストとは異なるポイントがある。」
田
田中VPoE
「AIは確率的な出力を返すため、従来の『入力Aに対して出力Bが返ること』という決定論的なテストだけでは不十分だ。精度、公平性、ロバスト性など、多面的なテストが必要になる。」
AIシステムテストの全体像
テストピラミッド(AI版)
┌─────────┐
│ E2Eテスト │ ← 業務シナリオ全体の検証
┌┴─────────┴┐
│ 統合テスト │ ← AI+業務システム連携の検証
┌┴───────────┴┐
│ AIモデルテスト │ ← 精度・公平性・ロバスト性
┌┴─────────────┴┐
│ ユニットテスト │ ← 個別コンポーネントの動作確認
└─────────────────┘
従来テストとの違い
| 観点 | 従来のシステムテスト | AIシステムテスト |
|---|
| 正解の定義 | 明確(仕様通り) | 曖昧(許容範囲で判断) |
| テスト基準 | Pass/Fail | 精度指標(F1、AUCなど) |
| テストデータ | 境界値・異常値 | 実データ分布を反映 |
| 再現性 | 完全に再現可能 | モデルの非決定性を考慮 |
| 回帰テスト | 差分のみ確認 | 全体の精度劣化を確認 |
テスト種別と実施方法
1. AIモデルテスト
| テスト項目 | 内容 | 合格基準(例) |
|---|
| 精度テスト | テストデータでの正解率 | F1スコア 0.95以上 |
| 公平性テスト | 属性間での精度差 | グループ間精度差 5%以内 |
| ロバスト性テスト | ノイズ入力での安定性 | ノイズ付加で精度低下10%以内 |
| エッジケーステスト | 境界的な入力での挙動 | 適切にフォールバック処理 |
| ドリフト検出テスト | 入力データ分布の変化検出 | アラート発報の正常動作 |
2. 統合テスト
| テスト項目 | 内容 | 合格基準(例) |
|---|
| API連携 | AI APIとの通信正常性 | レスポンスタイム 3秒以内 |
| データフロー | 入出力データの整合性 | データ欠損率 0% |
| エラーハンドリング | AI異常時のフォールバック | 人間対応への切替 30秒以内 |
| 負荷テスト | 同時処理時の性能 | 100件同時処理で劣化10%以内 |
3. 業務シナリオテスト(E2E)
| シナリオ | テスト内容 | 確認ポイント |
|---|
| 正常処理 | 標準的な請求書の自動処理 | 正しく処理完了すること |
| AI判定NG | AIの確信度が閾値未満 | 人間レビューに正しく回ること |
| 例外処理 | 初めての取引先からの請求書 | マスタ未登録のアラートが出ること |
| 障害時 | AIサービスがダウン | 手動フローに切り替わること |
| 大量処理 | 月末の請求書集中処理 | 処理遅延なく完了すること |
テスト計画の立て方
テストフェーズ
| フェーズ | 期間 | 内容 | 参加者 |
|---|
| Phase 1: 机上検証 | 1週間 | テストケース設計、テストデータ準備 | AIチーム、業務担当 |
| Phase 2: AI単体テスト | 2週間 | モデルの精度検証、チューニング | AIチーム |
| Phase 3: 統合テスト | 2週間 | システム連携、データフロー検証 | AIチーム、IT部門 |
| Phase 4: UAT | 2週間 | 業務担当者による受入テスト | 業務担当、管理者 |
| Phase 5: パイロット運用 | 4週間 | 限定範囲での本番相当運用 | 全関係者 |
パイロット運用の設計
パイロット運用の設計要素:
対象範囲:
- 部門: 経理部 第1チーム(10名)
- 業務: 国内取引先の請求書処理
- 期間: 4週間(月初〜月末の1サイクル)
並行運用:
- Week 1-2: AI処理 + 全件人間レビュー(Shadow Mode)
- Week 3-4: AI処理 + サンプルレビュー(30%抽出)
撤退基準:
- AI精度が90%未満の場合 → チューニングして再テスト
- 重大エラーが3件以上発生 → パイロット中断
- 業務担当者の不満が深刻 → プロセス見直し
UAT(受入テスト)のポイント
テストケースの分類
| カテゴリ | 割合 | 例 |
|---|
| 典型的なケース | 60% | 定型取引先の標準的な請求書 |
| バリエーション | 20% | 複数明細、外税/内税混在 |
| エッジケース | 10% | 手書き請求書、破損PDF |
| 異常ケース | 10% | 不正請求書、重複請求 |
UAT実施の注意点
| 注意点 | 説明 |
|---|
| 実データを使う | テスト用の理想的なデータではなく、実業務のデータを使用する |
| 現場の声を聞く | テスト結果だけでなく、使い勝手や不安点もヒアリングする |
| 比較を見せる | AI処理結果と人間処理結果を並べて比較する |
| フィードバックの仕組み | 不具合や改善要望を簡単に報告できる仕組みを用意する |
まとめ
| 項目 | ポイント |
|---|
| AIテストの特殊性 | 確率的な出力のため、精度指標で評価する |
| テストピラミッド | ユニット→AIモデル→統合→E2Eの段階で実施 |
| パイロット運用 | Shadow Modeから段階的に移行し、撤退基準も明確にする |
| UAT | 実データ+現場の声で受入判断を行う |
チェックリスト
次のステップへ
次は「ロールアウト計画」として、パイロットから全社展開への移行計画を策定しよう。
推定読了時間: 30分