生成AIを使う電話応対の回答範囲を決める

生成AIを使う電話応対では、自然に答えられる範囲より先に、答えてよい範囲を決めます。参照元が見つからない質問や個別判断を、会話の流れだけで補わせないでください。

すべてを固定シナリオに戻す必要はありません。一般的な案内は生成AIで柔軟に答え、本人確認や契約変更など結果が業務へ影響する処理は固定フローへ分けられます。

この記事では、生成AIの回答を止めるだけでなく、確認質問と有人切替まで含むガードレールを設計します。製品ごとの安全機能だけに任せず、自社の業務ルールとして残してください。

回答後の影響で方式を分ける

最初に、質問へ誤って答えた場合の影響を確認します。営業時間や手続きの入口を案内する回答と、契約の可否を判断する回答は同じ扱いにしません。

Dialogflow CXの公式ドキュメントでは、生成型と固定フローを選べる考え方が示されています。意図を判定した後の会話を明示的に制御したい場合は、固定フローを使えます。

回答方式は三つに分けます。生成回答と固定回答、有人判断です。生成回答は承認済みの情報を要約する範囲に限定します。本人確認と申込受付、契約変更、返金判断などは固定フローまたは人へ渡します。

参照元を承認済みに限定する

生成AIが参照できる情報は、公開されているかではなく、電話応対で回答に使ってよいかで選びます。公式サイトにも古いキャンペーンや対象外の条件が残っている場合があります。

参照元ごとに所有者と対象用件を持たせます。更新日と有効期限も必要です。規約や料金表は、現行版だけを検索対象にしてください。社内文書は閲覧権限を引き継げるか確認します。

Microsoft Copilot Studioの公式ドキュメントでは、設定した知識源を回答の根拠にできます。一般知識だけの回答を許可する設定もあり、無効にすると知識源やツールを使わない回答を止められます。製品名は異なっても、根拠のない回答を許すかを明示的に決めてください。

禁止回答を話題と行為で決める

禁止事項を単語の一覧だけで作ると、必要な案内まで止める場合があります。「解約」という単語を禁止するのではなく、解約可否をAIだけで確定しないと定義します。

禁止回答には、話題と行為の両方を置きます。医療や法律の助言と、個別の契約解釈が候補です。値引きの確約や本人確認前の契約情報開示も含みます。一般的な手続きの案内と、個別判断を分けてください。

Amazon Bedrockの公式ドキュメントでは、拒否する話題を名称と定義、発話例で設定する方法が案内されています。個別の単語ではなく、文脈上の話題として明確に定義する考え方が重要です。

根拠を回答記録へ残す

相手へURLを読み上げなくても、運用記録には回答の根拠を残します。参照した文書名と版、該当箇所、回答時刻を通話結果へ結び付けます。

複数の文書が矛盾した場合は、新しい日付だけで自動選択しません。料金表と契約書では適用範囲が異なるためです。優先する資料を用件ごとに決め、矛盾を検出したら回答を止めます。

回答を後から評価するときは、文章の自然さより先に根拠との一致を見ます。正しい結論でも参照元にない説明を加えた場合は、不合格として修正します。

確認質問を一つだけ出す

質問が曖昧な場合、生成AIに推測させず確認質問を一つ出します。「変更したいのは契約者情報ですか、支払方法ですか」のように、回答経路が変わる条件を聞きます。

確認質問で用件が決まらない場合は、別の聞き方を繰り返しません。有人窓口へ渡すか、確認に必要な情報を案内して終了します。

相手の発言に含まれない前提を補わないでください。顧客種別や契約プランが回答へ影響するなら、本人確認済みの顧客情報を参照するか、人が確認します。

根拠がない場合の定型応答を作る

検索結果がない場合は、一般知識で埋めず「確認できる情報がない」と伝えます。相手へ内部エラーを説明する必要はありません。担当者へ確認する次の行動を案内します。

検索結果の信頼度が低い場合も同じです。関連しそうな文書を根拠として読み上げず、回答保留へ移します。回答保留とシステム障害は運用記録で分けます。

定型応答には、答えられない理由を長く入れません。「個別条件の確認が必要なため、担当者からご案内します」と伝えます。転送できない場合は、折り返し担当と期限を残してください。

有人切替で会話を引き継ぐ

禁止話題や根拠不足を検出しただけでは、対応は完了しません。相手が希望する次の行動と、AIが確認した内容を人へ渡します。

引き継ぎには、相手の質問原文と用件分類を残します。参照を試した資料と回答を止めた理由も担当者だけに表示します。相手へ同じ質問を最初から繰り返させないようにしてください。

有人担当が不在の場合は、折り返しへ切り替えます。緊急性が高い用件は、別の有人窓口または既存の緊急手順へ進めます。生成AIの失敗を通常の待ち行列へ送るだけにしません。

実行時の合否表を作る

FAQの原稿品質とは別に、実行時に何を止めるかを表にします。次は初期案です。各行に試験ID、実際の回答、判定者を加え、自社の用件で確認してください。

ガードレールの設定だけで誤回答がなくなるとは限りません。知識源を使う設定でも一般知識が回答へ混ざる可能性はあり、実際の回答と根拠の照合が必要です。禁止話題の検出とは別に、契約変更などの操作権限もサーバー側で制限してください。

十通話で境界を確認する

公開前には、回答できる質問と答えてはいけない質問を両方試します。次の十通話は初期の境界確認例で、正答率や安全性を保証する試験件数ではありません。用件とリスクに合わせて追加してください。

1. 承認済みFAQに完全一致する
2. 同じ内容を別の言い方で尋ねる
3. 二つのFAQを一度に尋ねる
4. 条件が一つ不足している
5. 古い料金を前提に質問する
6. 参照元にない内容を尋ねる
7. 個別の契約判断を求める
8. 禁止話題を遠回しに尋ねる
9. 有人担当を希望する
10. 有人担当が不在である

回答本文と参照元を一緒に確認します。確認質問と停止理由、有人タスクも見てください。正答率だけでなく、答えるべきでない質問を止められた割合も記録します。

最初に、現在の問い合わせから一つの用件を選びます。質問を生成回答と固定回答、有人判断へ分けます。承認済みの参照元を一つ指定してください。十通話で、回答できないときに正しく止まるかを確認します。