チャットボットのテストケース｜公開前の8分類

チャットボットのテストケースは、質問文を並べるだけでは不十分です。入力に対する期待結果、回答してはいけない内容、判断の根拠、有人対応へ切り替える条件まで記録する必要があります。

公開前は、標準質問、言い換え、情報不足、対象外、誤入力、複数ターン、有人引き継ぎ・導線、回帰確認の8分類で検証します。各ケースを同じ条件で再実行できるようにすれば、担当者が変わっても共通の判断基準で公開可否を決められます。

チャットボットの公開前テストで最初に決めること

最初に決めるのは、テストの目的、対象範囲、確認担当者、公開停止条件です。これらが曖昧なままでは、担当者の印象によって合否が変わってしまいます。

対象範囲には、公開時点でチャットボットが案内する商品、手続き、店舗、受付時間などを記載します。あわせて、公開対象に含めない業務も明示します。対象外の範囲が分からなければ、答えるべきでない質問への応答を確認するテストを設計できません。

確認担当者は、回答内容を確認する業務担当者と、画面やリンクの動作を確認する実装担当者に切り分けます。たとえば返品条件は、規約や実際の受付ルールを管理する担当者が期待結果を承認します。テスト実行者だけで内容の正しさを判断してはいけません。

公開停止条件は、テストを始める前に定めます。少なくとも、利用者に不利益を与える誤案内、根拠のない断定、答えるべきでない質問への回答、必要な有人対応へ移れない状態、重要なリンクの誤りは、公開停止の対象として検討します。

回答精度の集計だけで公開可否を決めるのは適切ではありません。多数の軽微な表現差よりも、一件の重大な誤案内を優先して修正すべき場合があるためです。不合格件数だけでなく、それぞれの重大度と影響範囲を確認します。

再実行できるテストケース票の作り方

チャットボットのテストでは、別の担当者でも同じ入力を使い、同じ基準で判定できる記録を残します。プレビュー画面で自由に質問する確認は、初期段階の問題発見には役立ちます。ただし、条件が固定されていないため、修正前後を比較する評価の代わりにはなりません。

テストケース票には、次の項目を一件ずつ記録します。

• ケースID
• 分類と確認目的
• 事前条件
• 利用者の入力
• 期待結果と必須情報
• 禁止回答
• 根拠資料の名称と版
• 期待する有人引き継ぎや導線
• 実際の回答と動作
• 合否と不合格理由
• 確認者と確認日

事前条件には、会話を新規に開始するのか、直前にどのような質問をしたのかを記載します。複数ターンのケースでは、途中の入力と回答も順番どおりに残します。文脈が異なる状態で再実行すると、修正前後の結果を正しく比較できません。

期待結果は、一字一句の模範回答だけで定義しないほうが実務的です。「返品できる条件と期限を案内する」「対象商品を確認する」のように、回答に含める必須情報を列挙します。語尾や言い回しなど、許容できる表現差もあらかじめ決めておきます。

禁止回答には、誤った内容だけでなく、根拠がない内容や開示してはいけない内容も記載します。たとえば、未発表の提供時期を断定する回答や、本人確認前に個別情報を案内する回答です。

根拠資料には、承認済みFAQ、規約、商品情報、問い合わせ対応ルールなどを指定します。資料名だけでなく、更新日や版も記録します。テスト後に資料が更新された場合は、以前の合格結果をそのまま流用せず、影響を受けるケースを再確認します。

分類1：標準質問で正しい回答と根拠を確認する

標準質問とは、承認済みFAQに近い基本的な入力です。営業時間、返品条件、予約方法、配送範囲など、利用頻度が高く、正確な案内が必要な項目から作成します。

営業時間のケースでは、「営業時間を教えてください」と入力します。期待結果には、対象店舗、曜日、営業時間、休業日の扱いなど、案内に必要な情報を指定します。店舗によって営業時間が異なる場合は、店舗名を確認することも期待結果に含めます。

合格条件は、承認済み資料と結論が一致し、必須情報が欠けていないことです。主要な条件が抜けていれば、文章が自然でも不合格です。古い営業時間を案内した場合も不合格とします。

標準質問では、回答本文だけでなく、根拠資料との対応も確認します。回答が偶然正しく見えても、どの資料に基づく回答か分からなければ、資料の更新後に再確認できません。継続して検証できるよう、ケースごとに参照した資料と版を残します。

分類2：言い換えても同じ案内になるか確認する

同じ意図でも、利用者が使う表現は一定ではありません。丁寧語、口語、略称、語順を変えた入力を、それぞれ別のチャットボットテストケースとして用意します。

返品に関する確認では、「返品できますか」「返したい」「サイズが合わない」などを試します。すべてに同じ文章を返す必要はありません。ただし、返品条件という同じ案内へ到達し、結論や重要な条件に矛盾がないことが必要です。

言い換えケースは、対応する標準質問のケースIDと関連付けます。標準質問は合格し、口語の入力だけが不合格なら、回答内容ではなく意図の判別に問題があると切り分けられます。入力表現による差を確認するため、入力以外の事前条件はそろえます。

言い換えによって結論が変わった場合は、どの語句が判定に影響したかを確認します。異なる意図にも読める入力まで、無理に同じ回答へ寄せてはいけません。意図を一つに特定できない場合は、追加確認を行うケースとして分類し直します。

分類3：情報不足の質問では追加確認ができるか

回答に必要な条件が不足している場合は、推測による断定を防ぐことが重要です。「変更したい」という入力だけでは、予約、契約、配送先のどれを変更したいのか特定できません。

このケースでは、変更対象を確認する質問が返れば合格です。候補が少ない場合は選択肢を示します。候補が多い場合は、まず利用者に具体的な用件の説明を求めます。

確認事項を一度に増やしすぎないことも確認します。対象が不明な段階で氏名、注文番号、希望日などをまとめて求めると、不要な情報まで入力させることになります。まず用件を切り分け、その後で手続きに必要な条件を確認します。

条件が確定していないのに、手続きの可否や期限を断定した場合は不合格です。また、追加確認を行っても、利用者の返答を反映せずに最初の案内を繰り返した場合は、複数ターンの不合格としても記録します。

分類4：対象外の質問に答えすぎないか確認する

対象外質問の検証は、正しい回答を返せるかを見るテストではありません。回答しない判断が適切に働くかを確認する負のテストです。

未発表機能の提供時期、競合製品の評価、個別の審査結果、担当者による判断が必要な相談などを入力します。期待結果には、確認できない内容を作らないことと、必要に応じて確認窓口を案内することを指定します。

「分かりません」と答えるだけで、常に合格になるわけではありません。公式の問い合わせ先があり、利用者が次の行動へ進む必要がある場合は、その窓口を案内することまで合格条件に含めます。

禁止回答には、未確認の予定、存在しない制度、承認されていない値引き、個別事情を確認しないままの可否判断などを記載します。もっともらしい表現でも、承認済み資料に根拠がなければ合格にしません。

分類5：誤字・表記揺れ・意味不明入力を確認する

チャットボットのエッジケースには、商品名の一文字抜け、全角と半角の違い、ひらがなとカタカナの違い、途中送信、無関係な文字列を含めます。

誤字があっても意図を一つに特定できる場合は、適切な案内へ進めるかを確認します。複数の商品名に解釈できる場合は、どの商品を指しているか確認する質問が必要です。似た名称の商品を勝手に選び、その条件を断定した場合は不合格です。

途中送信の例として「予約の」と入力します。この時点で予約方法を一方的に説明するのではなく、入力の続きや具体的な用件を確認できるかを試します。

記号の連続や意味を特定できない文字列に対しては、再入力や追加説明を求めることを期待結果にします。無関係な情報を生成した場合や、意図を理解したように見せて手続きを案内した場合は不合格です。

分類6：複数ターンと文脈リセットを確認する

会話テストでは、一つの入力だけでなく、条件の追加や変更、話題の転換も再現します。直前の文脈を引き継ぐ場面と、新しい質問として扱う場面を切り分けて確認します。

たとえば、最初に配送先の変更を相談し、次に「注文自体をキャンセルしたい」と入力します。このケースでは、配送先変更の手続きを続けず、キャンセル条件の案内へ切り替わることが期待結果です。

一方、営業時間を尋ねた後の「土曜日は？」という入力では、直前の対象店舗を引き継ぐ必要があります。省略された質問を単独の入力として処理すると、店舗を再確認するなど、会話の流れに合わない応答になる可能性があります。

途中で条件が変わるケースも用意します。「東京の店舗」を尋ねた後で「大阪の場合は」と変更し、古い地域の情報が残らないかを確認します。変更後の回答に東京の条件が混ざった場合は不合格です。

新しい会話を開始したときは、前の利用者や用件に関する文脈が残らないことも確認します。リセット操作の有無を含め、実際の公開環境と同じ事前条件で検証します。

分類7：有人引き継ぎとリンク・フォーム導線を確認する

AIが担当できない場面では、回答を止めるだけでなく、利用者を有人対応へ確実に案内する必要があります。苦情、本人確認が必要な依頼、個別判断を伴う相談、同じ質問を繰り返しても解決しない状態などをテストします。

ケース票には、有人対応へ切り替える条件、案内文、対応手段、受付時間を記載します。これらの期待結果には、自社の承認済み運用ルールを使用します。実際の担当範囲と異なる窓口を案内した場合は不合格です。

本人確認が必要な依頼では、チャット上で不要な個人情報を入力させず、指定のフォームや窓口へ案内できるかを確認します。案内文が表示されただけでは合格にしません。リンクの遷移先、フォームの表示、送信に必要な項目、送信完了後の到達先まで実際に操作します。

受付時間外の動作も別のケースにします。すぐに担当者が応答するような誤解を招く案内を避け、実際の受付方法と一致していることを確認します。

有人対応へ切り替える判断基準や引き継ぐ情報を整理する場合は、有人引き継ぎの設計手順も確認してください。AIの担当範囲と、有人対応を開始する条件を分けて検討できます。

分類8：修正後の回帰テストで既存回答への影響を確認する

不合格ケースを修正した後、そのケースだけを再実行して完了としてはいけません。一つの修正が、関連する回答や導線へ影響する可能性があるためです。

チャットボットの回帰テストでは、公開停止条件に関わる重大なケースと、利用頻度が高い標準ケースを固定セットにします。対象外応答、有人引き継ぎ、主要なリンクも固定セットに含めます。

返品条件を修正した場合は、標準的な返質問だけでなく、言い換え、情報不足、対象外商品の質問も再実行します。案内先を変更した場合は、リンクとフォームの動作も確認します。

再実行では、入力、事前条件、期待結果、根拠資料の版をそろえます。根拠資料自体を更新した場合は、旧版の結果と新しい期待結果を混同しないよう、ケース票の版を分けます。

修正によって新しい不合格が発生した場合は、影響範囲を確認し、必要なケースを固定セットに追加します。公開後に見つかった失敗パターンを次回の回帰テストへ反映する方法は、チャットボットの会話ログ分析で確認できます。

テスト結果から公開可否を判断する手順

すべてのケースを実行した後は、不合格を重大度と影響範囲で分類します。件数だけを集計するのではなく、利用者への影響と回避手段の有無を確認します。

1. 公開停止条件に該当する不合格を抽出する
2. 不合格の原因と影響するケースを切り分ける
3. 回答、根拠資料、導線、運用ルールのどこを修正するか決める
4. 修正対象と固定の回帰セットを再実行する
5. 重大な不合格が解消したことを確認する
6. ケース票、根拠資料の版、承認者、判定日を保存する

公開停止条件に該当するケースは、修正と再テストが完了するまで合格に変更しません。回避手段のない誤案内や、必要な有人対応へ進めない状態が残っている場合は、公開を止めます。

軽微な表現差などを条件付きで許容する場合は、許容理由、影響範囲、修正担当者、対応期限を残します。「大きな問題ではない」という記録だけでは、次回の判断基準として使えません。

ケース単位の合否に加えて回答品質を評価したい場合は、AIチャットボットの回答精度を評価する方法を参照してください。公開前の安全性に関する判定と、品質指標による評価を分けて整理できます。

公開後の成果は、公開前テストの合否とは分けて測定します。問い合わせ対応や利用状況を評価する指標を設計する場合は、チャットボットの効果測定とKPIを確認してください。

公開前には8分類のテストケースを用意し、入力、期待結果、禁止回答、根拠、有人引き継ぎ条件、実際の結果を記録します。重大な不合格が残っている場合は公開せず、修正後に同じ条件で回帰テストを行います。

自社の公開前テストを整理する

自社のFAQ、対象外の範囲、有人引き継ぎ条件を整理したうえで、Socratesで確認できる内容や導入設計についてご相談ください。現在の問い合わせ対応ルールを基に、公開前に確認すべき項目を切り分けられます。

チャットボットのテストケースに関するFAQ

チャットボットの公開前テストでは何を確認しますか。

標準質問、言い換え、情報不足、対象外、誤入力、複数ターン、有人引き継ぎ・導線、回帰確認の8分類を確認します。回答の正しさだけでなく、答えない判断と、次の行動へ進むための導線も対象です。

テストケース票には何を記録すべきですか。

ケースID、事前条件、入力、期待結果、禁止回答、根拠資料と版、引き継ぎ条件、実際の結果、合否、確認者、確認日を記録します。担当者が変わっても同じ条件で再実行できる具体性が必要です。

回答が自然なら合格にしてもよいですか。

文章が自然という理由だけでは合格にできません。承認済み資料との一致、必須情報の有無、禁止回答が含まれていないこと、必要な導線が正しく動作することを確認します。

情報不足の質問はどのように判定しますか。

不足している条件を推測せず、必要な追加確認を行えれば合格です。条件が確定していない段階で、手続きの可否や期限を断定した場合は不合格にします。

修正後は不合格だったケースだけを再確認すればよいですか。

修正対象に加えて、関連FAQ、対象外応答、有人引き継ぎ、主要なリンク導線を回帰テストします。同じ入力と事前条件を使い、既存の合格ケースが壊れていないことを確認します。