ユーザーシュミレーション AIプロダクトのバグを事前検知

Transcript

1. ユーザーシュミレーション AIプロダクトのバグを事前検知 立野 祐太
2. 品質に関する現状の課題 顧客のバグ報告を受けてから対応する運用が常態化 顧客がデバッカーになってしまっている 顧客満足・解約リスクに直結する 2
3. 現状の品質担保 テスト、 UATをしっかり行っているのになぜバグ報告が頻発する？ 2
4. 原因 現状のテストは理想的な使われ方が前提で、実運用の想定外な使われ方に対する品質を担保できていない これらをカバーできるテストの種類が足りていない
5. 解決案 エージェントが様々な使われ方をシュミレーション。想定外の挙動を検証し、早期にバグを発見する
6. イメージ（世界観） ※夜間はコストを抑えられる 「顧客からの報告」を「事前の発見」に置き換えることが可能になる 5
7. どう実現するか
8. 必要なデータ シナリオの定義 評価の定義 ゴール＋ペルソナ （何をどんな人が検証するのか） 合否の採点表 （ゴール達成 ＋ 性質） シミュレーター層（演者） 評価層（審査員） 顧客を演じて会話を作る─ 採点表は知らない 会話を後から採点する 1
9. 検証精度 検証 精度 ＝ シナリオの質 × 評価の質 シナリオが雑 → 何回まわしても見つからない ／ 評価が弱い → 起きた失敗を見逃す 1
10. シナリオの質をどうやって高めるか 機能一覧 機能一覧から体系的に生成 新機能もリリース前に作れる 例：「ファイル要約」機能→ 「営業資料を添付して要約を頼む」 抽出してシナリオ生成 シナリオ集 本番ログ 実セッションを匿名化・蒸留 実顧客の壊し方と頻出の重みを供給 例：「あの件まとめといて。やっぱ英語で」 → 曖昧指示＋方針変更シナリオ 4
11. 評価の質をどうやって高めるか • • 汎用の基準 専用の基準 エラーかどうか 決めたゴールを達成できているか ハルシネーションが発生しているか 過去の不具合を項目化 定めたルールを項目化 （書式・トーンなど） 最初から張ってある ─ 未知の失敗もかかる 失敗のたびに 1 枚ずつ増える ─ 既知を狙い撃ち 最初は汎用の基準だけで検証 運用してバグ発見いくうちに専用の基準が勝手に増えてくる
12. 評価の難易度 簡単 普通 エラー ハルシネーション 難しい 品質の良し悪しなどの主観 例外・タイムアウト・ツール失敗 機械判定はできないが、正解がある 決定的に判定できる 主観的で正解が多様で曖昧 過去の評価データの蓄積で精度をあげていく 2
13. 全体の流れ 人間 AI AI AI ① シナリオ作成 ② シナリオ承認 ③ パターン量産 ④ 実行 シナリオと成功条件を AI が下書き 人間がレビューして シナリオ集へ登録 変化形を AI が毎回生成 夜間の探索 ＋ PR ごとの回帰 人間 AI ⑧ 回帰テストへ昇格 シナリオ集へ戻り 以後は再発を自動監視 AI ⑦ 修正 AI ⑥ Issue起票 ⑤バグ検知 開発チームが対応 ↩ ⑧ で昇格したシナリオは ④ の回帰実行に自動で組み込まれ、ループが回り続ける 6
14. 注意点 誤検知の量産は、レポートを読まれなくする 対策：精度の高い検出を目指していく。機械チェック優先の二段構え ＋ Issue 化の前に人間のトリアージ 「通った ＝ 本番で安全」ではない 位置づけ：保証ではなく、顧客が先にバグを踏む回数を減らす施策
15. まとめ 足りないのは、テストの量ではなく種類 AI が顧客を演じる「デバッカー」になり、未知のバグを探す 見つけた失敗は回帰テストへ昇格し、テスト資産を育て続ける