はじめに
AIサービス、特にエージェント型や自動化支援プロダクトは、ユーザーの入力や状況に応じて振る舞いが変化する、“非決定的”な体験を特徴としています。そのため、一般的なSaaSやWebサービスとは異なり、「UXのブレ幅が大きい」ことが課題となりやすく、同時にテストの重要性も跳ね上がることになります。
本記事では、UXデザイナーの立場から、AIサービスに適したユーザビリティテストの設計・実施方法を解説します。
なぜAIサービスのテストは難しいのか？
出力が毎回違う
- 同じ操作でもLLMの温度やタイミングにより異なる反応が返る
- A/Bテストの制御が困難で、比較評価が難しい
ユーザーごとに「前提知識」が異なる
- 生成AIに慣れているかどうか、業務内容の理解度によって使い方が異なる
- 初心者〜上級者でニーズや詰まり方が全然違う
「正しい使い方」が明示されていない
- ChatGPTのようにプロンプト入力型のUIでは、何が“正解操作”か分からない
- 操作ミスと機能限界の区別がつきづらい
テスト設計における重要ポイント
1. 検証したいのは“結果”ではなく“過程”
- ユーザーが「どう操作したか」「なぜそうしたか」を観察する
- 出力そのものが正解でも、途中で迷っていれば改善余地あり
2. “期待値とのギャップ”を中心に見る
- 「ユーザーはAIが何をしてくれると思っていたか？」に注目する
- 結果ではなく“誤解”や“誤認”がどこで生まれたかを抽出する
3. ユースケースではなく“行動シナリオ”ベースで設計する
- ユーザーの実業務に近いシナリオを提示する
- 例：「営業資料を短くして上司に提出したいとき、どう操作する？」
テストの進め方：具体的ステップ
Step 1｜目的を定める
- 例：「初回オンボーディングで離脱しないか？」「出力に納得できるか？」
- 定性的・定量的に観察したい指標を明確にする
Step 2｜シナリオとプロンプト例を準備
- 自由入力型サービスでは「使ってください」ではなく、課題ベースの指示が効果的
- 例：「この契約書をレビューしたい時、どこをクリックしますか？」
Step 3｜テスト観察と記録
- 操作中の発言（シンキング・アラウド）と、画面遷移を同時に記録
- 「あ、これ何だろう？」「あれ、反応が遅いな」などのつぶやきがヒントに
Step 4｜インタビュー＋フィードバック取得
- 何が分かりにくかったか／期待通りだったか／改善してほしい点は？
- LLMの振る舞いに対する“納得感”も聞く（信頼性・違和感）
Step 5｜再現性のあるまとめ方を意識する
- 単なる感想で終わらせず、再現可能な課題として記述
→「〜のときに〜という誤解を生むUIである」 - 出力がブレるAIサービスだからこそ、ユーザー行動の共通パターンに注目
実施パターン別の工夫例
| パターン | 特徴 | 工夫ポイント |
|---|---|---|
| 対面テスト | 実際の操作＋観察 | シンキングアラウド必須、リアルタイムで補足質問も |
| リモート録画 | ユーザー操作＋画面録画 | 操作後の簡単なアンケート＋録画の質的分析が有効 |
| 社内ユーザーテスト | 開発メンバーへの実装確認も兼ねる | “分かったフリ”が出ないように、業務目線の課題で実施 |
| クローズドβ／ログ分析 | 大規模に回すことで定量傾向を見る | ログから“行き止まりパターン”を抽出できる |
デザイナーの視点で見る“テストすべき観点”
- UIからAI挙動が想像しやすいか？（黒い箱に見えないか）
- プロンプト入力／選択肢UIが誤解を生みにくいか？
- 出力までの時間が妥当だと感じるか？（体感スピードが不安や戸惑いにつながっていないか）
- 出力内容に対して信頼できたか、納得できたか？→ 信頼性のUXは、機能ではなく文脈と説明に宿る
おわりに（まとめ）
AIプロダクトは、動作や結果の“正しさ”だけでなく、ユーザーが「どう理解し、どう受け取ったか」がUXの成否を左右します。「使いにくい」ではなく、「どう使えばいいか分からなかった」という声こそ、UXテストで拾うべき最重要インサイトになります。
UXデザイナーは、機能の完成度を見るのではなく、ユーザー体験の“ずれ”を探す仕事です。AIサービスにおいてはその重要性がさらに高まり、プロダクト成功の鍵を握っていると言えます。
コメント