AIチャットボットの回答精度を評価する方法｜テスト質問と改善順

AIチャットボットを試していると、「文章は自然だが、本当に正しいのか」「誤答を見つけたあと、どこから直せばよいのか」が分からなくなります。

回答精度は、会話の印象や正答件数だけでは判断できません。質問ごとに期待する回答を先に決め、期待回答→実際の回答→判定→修正→再テストを一続きで記録します。正しい情報を使ったか、質問に直接答えたか、答えるべきでない内容を担当者へ渡せたかまで確認すると、改善箇所を具体的に特定できます。

回答を正答・保留・誤答に分ける

最初に、三つの判定を社内でそろえます。正答は、質問への答えが正本に支えられ、必要な条件と次の行動まで合っている状態です。文章の長短や丁寧さだけで決めません。営業時間を聞かれたのに店舗の特徴だけを説明した回答は、書かれた事実が正しくても質問に答えていないため、正答にはできません。

保留は失敗ではありません。根拠がない質問、条件が足りない質問、担当者の判断が必要な質問に対し、推測や確約をせず、確認事項と窓口を示せた状態です。「分かりません」だけで終わる、または保留しながら断定的な表現を混ぜる回答は改善対象です。

誤答は、事実と違う案内、古い条件、別の商品や店舗の情報、根拠のない数字、質問の一部を落とした回答です。自然な文章でも、利用者の判断を誤らせる内容なら誤答です。判定名だけを残すのではなく、どの条件が欠けたかも記録します。

採点時は「事実の正しさ」「質問への適合」「根拠」「保留・次の行動」を別々に見ます。複数の要求がある質問では、要素ごとに確認してください。「営業時間と予約方法を教えてください」に営業時間しか答えていない場合、記載内容が正しくても回答としては不十分です。

評価前に正本と対象範囲を固定する

テストを始める前に、何を正しい情報とするかを決めます。Webページ、社内規程、商品資料などが複数ある場合は、回答の根拠として使う正本と、その管理者を明記します。正本どうしで条件が食い違う状態では、AIの回答だけを直しても判定が安定しません。先に情報の所有者へ確認し、確定できない内容は保留条件にします。

また、定型案内、条件付き案内、個別判断を同じ合格基準で採点しないことが重要です。営業時間のような定型案内は事実と例外条件の一致を見ます。返品のような条件付き案内は、対象条件を確認してから答えたかを見ます。返金の例外や契約可否のような個別判断は、AIが結論を確約せず、必要情報と確認先を示せたかを見ます。

期待回答は模範文を一字一句再現させるためのものではありません。「必ず含める事実」「条件不足なら尋ねること」「確約してはいけないこと」を分けて書きます。評価者が二人いる場合は、最初の数件を別々に判定し、結果が割れた質問の期待回答を見直します。人が読んでも判断が分かれるなら、AIより先に基準や正本を整える必要があります。

テスト質問は四つの型で作る

質問は、実際の問い合わせを参考にしつつ、個人を特定できない形へ置き換えて作ります。最初から網羅を目指すのではなく、料金、営業時間、予約、キャンセル、返品など、間違えたときの影響が大きい業務から選びます。固定の必要件数はありません。少数でも、次の四つの型をそろえるほうが弱点を見つけやすくなります。

1. 代表質問

「営業時間を教えてください」「返品できる条件は何ですか」のように、正本と期待回答が明確な質問です。基本的な情報を正しく取り出せるかを確認します。

2. 言い換え質問

「何時まで開いてる？」「返品ってできる？」のような話し言葉、短い表現、よくある表記ゆれを含めます。代表質問にだけ答えられても、同じ意図の言い換えで別の情報へ流れるなら実運用では不十分です。

3. 境界質問

「例外として返金できますか」「この条件なら必ず契約できますか」のように、AIが確約すべきでない質問です。情報不足を伝え、確認事項や有人対応への導線を出せるかを評価します。

4. 複合質問

「料金と予約方法を教えてください」のように、要求を二つ以上含む質問です。片方だけ答える、条件を混ぜる、結論が見つけにくくなるといった問題を確認します。要求が多すぎる場合は、順番に確認する案内ができるかも見ます。

テスト条件をそろえて比較できるようにする

同じ質問でも、直前の会話や登録情報の状態が違えば、回答は変わります。修正前後を比べるときは、質問文だけでなく、会話履歴、正本の版、テスト日、利用した設定、確認者をそろえて記録します。条件が違う結果を並べて「改善した」と判断すると、別の要因による変化を見落とします。

単独で完結する代表質問は、新しい会話として試すと比較しやすくなります。一方、「それは未使用です」「では別の店舗なら？」のように前の発言を受ける質問は、必要な会話を一つのシナリオとして保存します。シナリオには、どの発言を受け継ぐべきか、途中で確認すべき条件は何かも書きます。独立した質問と会話の続きである質問を混ぜないことが大切です。

実際の回答は、誤字や冗長な部分も含めてそのまま保存します。評価者が読みやすく直した文章を記録すると、質問への直接回答が遅い、不要な断定が混じるといった問題が消えてしまいます。その横に、欠けた必須条件、余分な主張、参照できた根拠を評価者の所見として分けて書きます。「回答そのもの」と「評価者の解釈」を別欄にすることで、後から別の担当者が判定を確認できます。

判定に迷ったときは、文章の好みで決着させず、期待回答へ戻ります。必須条件はすべて含まれたか、禁止した確約はないか、質問者が次に取る行動は明確かを順に確認します。それでも決められない場合は未評価として残し、正本の管理者に確認します。未評価を無理に正答や誤答へ寄せないことが、基準のぶれを見つける手掛かりになります。

また、回答が一度だけ期待どおりでも、重要な質問は条件を変えずに再確認します。結果が変わった場合は、どの表現や会話履歴で差が出たかを残し、公開時に許容できる状態かを担当者が判断します。回数だけで合否を決めるのではなく、誤答した場合の影響と、適切に保留できるかを優先してください。

期待回答から再テストまでを一件でつなぐ

ここでは、架空の店舗の返品案内を例に、台帳の一行がどのようにつながるかを示します。実在する店舗やSocratesの製品仕様を示すものではありません。

期待回答

質問：「購入から7日ですが、レシートをなくしました。返金できますか？」

期待するのは、「通常の手続きにはレシートが必要であり、レシートがない場合は個別確認になる」と伝え、返金できると断定せず、担当窓口への確認を案内する回答です。購入から14日以内という一条件だけで結論を出してはいけません。

実際の回答

「購入から14日以内ですので返金できます。商品を店舗へお持ちください。」

判定

誤答です。「14日以内」は正本と一致していますが、必須条件のレシートを無視し、担当者の確認が必要な例外について返金を確約しています。文章の一部が正しくても、利用者の行動を誤らせるため正答にはできません。台帳には「レシート条件の欠落」「例外時の有人切替漏れ」と記録します。

原因と修正

確認すると、返品期限とレシート条件が別々の資料にあり、例外時の扱いも回答ルールに明記されていませんでした。そこで、正本側で期限・必要物・例外時の対応を一つのまとまりとして確認できるようにし、「条件が欠ける場合は可否を断定せず、担当者へ確認を案内する」というルールを追加します。変更はこの原因に絞り、文章の口調などは同時に変えません。

再テスト

同じ質問を再実行したところ、「通常の返品手続きにはレシートが必要です。レシートがない場合の返金可否は個別確認となるため、商品情報と購入日を用意して担当窓口へご確認ください」と回答しました。返金を確約せず、必要な条件と次の行動を示しているため、判定は適切な保留です。

ここで終わらず、「レシートはあります。購入から7日で未使用です」という代表質問、「レシートないけど返品できる？」という言い換え、「使用済みでも例外で返金できますか」という境界質問も試します。元の誤答が直っていても、答えられる質問まで一律に保留するようになった場合は合格ではありません。この一連の記録があれば、何を直し、どこまで影響したかを後から確認できます。

誤答の原因を切り分け、改善順を決める

誤答を見つけたとき、すぐに資料を増やすと、重複や矛盾が増えることがあります。まず症状と原因を分けます。正本に情報がないのか、古いのか、複数の資料が衝突しているのか、質問の意図を取り違えたのか、保留条件がないのかを確認してください。

改善は、まず料金、契約、返金、個人情報など、誤ると影響が大きい回答と有人切替漏れを止めます。次に、実際によく聞かれる質問の誤答、情報更新によって再発しやすい質問を直します。語尾や文章の長さなど、意味を変えない表現調整はその後です。単純な正答率が高くても、重要な一件の誤答を平均に埋もれさせてはいけません。

一度に複数箇所を変えると、何が判定を変えたのか分からなくなります。正本、質問の分類、回答指示、有人切替条件のうち、原因に対応する一項目を修正し、結果を見てから次へ進みます。修正内容、変更日、確認者を台帳に残しておくと、後で同じ問題が起きたときに比較できます。

再テストは同じ質問と周辺質問で行う

修正後は、誤答した質問を同じ文面で再実行します。ただし、それだけでは修正の副作用を見逃します。同じ意図の言い換え、答えてよい代表質問、保留すべき境界質問、近い条件を持つ周辺質問も一緒に確認してください。料金を直したなら、通常料金だけでなく、対象条件や古い条件を前提にした質問も対象になります。

再テストでは、期待回答と実際の回答を新しい行に残し、前回との差を記録します。「誤答が保留へ変わった」なら安全性は改善していますが、本来答えられる定型質問まで保留になっていないかを確認します。反対に、回答が詳しくなっても、根拠のない条件が増えたなら改善とはいえません。

公開可否は、合格件数だけで決めません。重大な誤答、有人切替漏れ、正本を確認できず未評価になっている質問を分けて示します。未評価を正答に含めず、正本の担当者と次の確認時期を決めます。重要情報を変更したときは関連する質問を再テストし、評価基準を変えた場合は過去の結果にも同じ基準を適用できるか確認します。

公開後の会話を質問台帳へ戻す

評価は公開前だけで終わりません。確認できる会話記録がある場合は、未解決になった会話、同じ質問の繰り返し、有人対応へ移った相談を匿名化し、新しいテスト質問として台帳へ加えます。顧客の文章や個人情報をそのまま共有せず、意図と条件を保ったテスト文へ置き換えてください。

正本が変わったときは、変更箇所に関係する質問IDを探し、代表質問・言い換え・境界質問を再テストします。定期確認では、長く使われていない質問、重複した質問、判定が繰り返し割れる質問を整理します。Socratesで利用できる設定、連携、ログの範囲は利用環境や契約によって異なるため、確認できない機能を前提に人の確認工程を省かないでください。

よくある質問

関連ガイド

• AIの回答精度とハルシネーション対策：誤回答が起きる仕組みを理解し、根拠となる情報の整え方から見直したいときに使います。
• ナレッジ更新の実務：評価で古い情報や重複資料が見つかり、正本の更新手順と管理方法を決めたいときに使います。
• チャットボット会話ログの分析：公開後の未解決会話や繰り返し質問から、次にテストする質問を選びたいときに使います。
• AIから有人対応へつなぐ設計：保留すべき条件、担当窓口、引き継ぐ情報を具体化したいときに使います。