AI顧客対応の準備で、営業時間を聞くと正しい答えが返った。それだけでは公開してよいか判断できません。条件の付いた料金、案内にない質問、古い情報、個人情報を含む入力など、通常の例から外れる場面でも想定した対応になるかを確認する必要があります。
この記事では、島田市の中小企業が問い合わせ案内にAIを使う前に、公開前テストの質問集と判定表を作る手順を整理します。自動返信の範囲や人への引き継ぎルールは先に決めておき、ここでは「決めたルールどおりに動くか」を確かめることに集中します。
正答例ではなく期待する行動を決める
テストケースには、入力する質問だけでなく、参照すべき資料、回答に含める事実、してはいけない案内を記録します。文章が一字一句同じかよりも、必要な条件が含まれ、不明なことを勝手に補っていないかを確認します。
NISTのAI RMF CoreのMeasureでは、運用前と運用中のテスト、テスト集合や測定方法の記録が示されています。以下の質問区分は、その考え方を小規模な顧客案内へ適用した独自の編集例です。公式の合格基準や、網羅的な安全保証ではありません。
正解の根拠は、確認済みの営業時間表、料金案内、受付条件などに置きます。AIが生成したFAQを、そのまま正解資料にしてはいけません。資料の確認者と確認日を残し、資料にない内容は不明と扱います。
六つの質問区分でテスト集合を作る
| 区分 | 質問の作り方 | 期待する行動 |
|---|---|---|
| 通常の質問 | 公開資料で答えが確定している内容 | 資料と一致する事実を簡潔に案内する |
| 条件付きの質問 | 料金や受付条件に例外がある内容 | 条件を省かず、必要な確認を促す |
| 情報がない質問 | 未提供サービスや未確定の日程 | 架空の案内を作らず確認窓口を示す |
| 古い情報を含む質問 | 廃止した料金や以前の営業時間を引用 | 旧情報を追認せず現行資料を確認する |
| 個人情報を含む質問 | 架空の氏名や予約情報を含む入力 | 他人の情報を回答せず適切な窓口へつなぐ |
| 案内のルールを変えようとする質問 | 資料を無視して回答するよう要求 | 決めた参照範囲と禁止事項を守る |
テスト用の顧客名や予約番号は架空の値を使い、実在する顧客データをそのまま入力しません。質問の文面例は社内検証用であり、実際に発生した問い合わせや顧客事例ではないことも明記します。六区分を作っただけで、すべての誤回答を防げるとは考えないようにします。
一つの質問に言い換えと会話の続きも加える
同じ営業時間の質問でも、「何時まで」「夕方でも行ける」「今日の受付は」と表現が変わります。短い質問、誤字を含む質問、前の会話を受けた質問などを加え、特定の言い回しにだけ正答する状態を見つけます。
続きの会話では、AIが先に誤った前提を置いていないかも確認します。初回は資料どおりでも、利用者が「前は安かったはず」と言うと旧料金へ戻る、といった変化を観察します。新しい会話での単発テストと、会話履歴を持った連続テストは分けて記録します。
可能なら同じケースを複数回実行し、回答の揺れも確認します。回数と結果を残しますが、少数回の成功率を全問い合わせの正答率と表現してはいけません。モデル、指示文、参照資料、設定が変わると結果も変わり得るため、テスト時の条件を控えます。
重大な誤案内は平均点で隠さない
判定は、事実の正確さ、条件の欠落、不明時の対応、禁止事項、人への引き継ぎに分けます。自然な日本語や親しみやすさだけで高評価にすると、重要な誤りを見逃します。料金の断定、存在しない予約確約、他人の情報を含む回答などは、文章が上手でも公開を止める対象にします。
- 根拠資料と違う事実を断定していないか。
- 価格・日時・受付に関する重要な条件を落としていないか。
- 分からない質問へ想像で答えていないか。
- 資料の範囲を超えた予約確約や契約判断をしていないか。
- 人へ確認する案内が、実際に利用できる窓口につながるか。
公開停止の条件は実行前に責任者が決めます。正答が多いから重大な一件を許容する、と後から基準を緩めないことが重要です。人への引き継ぎを期待するケースでは、正しい窓口が表示されるだけでなく、リンク先や受付方法が実際に機能するかも確認します。
修正後は失敗例だけでなく全体を再確認する
- 失敗したケースの入力、出力、資料、設定を記録する。
- 原因を資料不足、指示の曖昧さ、検索の問題、案内範囲の広さに分ける。
- 確認した原因に対応する修正を行い、変更点を控える。
- 失敗ケースと、以前成功したケースの両方を再実行する。
- 未解決の重大な誤りがあれば、公開せず範囲を縮小する。
一つの誤りを直すために指示を追加すると、別の質問に答えなくなることがあります。失敗例だけを通す調整ではなく、通常質問を含む全体のテスト集合で影響を見ます。資料不足の場合は、指示文を長くするだけで埋め合わせず、確認済み情報を整備します。
公開後も問い合わせからテストケースを追加する
公開前テストは開始条件の確認であり、運用後の監視を不要にするものではありません。利用者からの指摘や、担当者が見つけた誤案内を、個人情報を除いた形で新しいケースへ追加します。料金変更、受付条件の変更、モデルや参照設定の変更時も再テストの対象にします。
誰が記録を確認し、誰が停止を判断し、停止時にどの案内へ戻すかを決めておくと、問題を見つけた後の対応が曖昧になりにくくなります。最初から広い顧客対応を任せず、答えを確認できる案内に絞って検証しましょう。
顧客対応AIの公開前テストや回答範囲を整理したい場合は、LIFESEEDSのAI活用・業務効率化支援をご確認ください。案内資料と確認したい質問をまとめ、お問い合わせフォームからご相談いただけます。
コメント