AIコールセンター向けFAQを作る方法

AIコールセンター向けのFAQは、想定質問と模範回答を並べるだけでは足りません。何を根拠にどこまで答え、どの条件で回答をやめるかまで設計します。回答の責任者と有効期限も、公開前に決めてください。

最初から問い合わせ全体を対象にする必要はありません。変更が少なく、本人確認をせずに案内できる一つの用件から始めます。実際の問い合わせ表現を集め、回答の根拠と終了条件を一組にすると、AIと人の役割を分けやすくなります。

この記事では、FAQの文章を増やす方法ではなく、AIが安全に参照できる回答単位を作る順番を説明します。製品への登録操作や検索方式の比較は扱いません。

FAQではなく回答単位を作る

AIへ渡す情報は、一つの質問に一つの短文を対応させた一覧とは限りません。生成AIを使う製品は、登録した文書から関連箇所を検索し、会話に合わせて回答を組み立てる場合があります。Amazon Bedrockの公式ドキュメントでも、関連する情報片を取得する処理と、取得結果から文章を生成する処理が分けられています。

そのため、設計の単位は「よくある質問」よりも「一つの判断に必要な根拠」です。たとえば営業時間なら、通常営業時間だけでは不十分です。休業日と受付時刻の基準、時間外の案内先までを同じ回答単位へ含めます。別ページに例外があるなら、その関係も明記します。

一方で、複数の制度を一つの長い文書へまとめると、関係のない箇所が回答に混ざりやすくなります。用件と対象者を先に区切ります。適用期間と例外を同じ範囲で管理できる大きさに分けてください。

実際の質問を一つの判断へまとめる

質問文は担当者が想像して作るのではなく、通話記録や問い合わせ分類から集めます。「返品できますか」「開封後でも戻せますか」「セール品は対象ですか」は表現が違いますが、必要な判断が返品条件なら同じ回答単位の候補です。

ただし、似た言葉を同じ質問へ寄せすぎないようにします。「返品したい」と「返金されていない」では、前者は条件案内、後者は個別状況の確認です。AIが参照する情報も、人へ渡す条件も異なります。

集めた表現には、次の三つを付けます。

1. AIが確認する前提
2. 参照する回答単位
3. 回答後の終了状態

終了状態は「案内して完了」「追加の質問へ進む」「人へ渡す」「回答しない」から選びます。質問の言い換えだけを増やすより、会話の次の動きを決める方が運用に使えるFAQになります。

回答の根拠と適用範囲を明記する

各回答には、根拠となる社内規程や公式ページを一つ以上ひも付けます。商品マスタを根拠にする場合も同じです。参照元の名称だけでなく、対象商品と対象地域を残します。

適用開始日も記録してください。同じ名称の資料が更新されたときに、どの版を使った回答か追えるようにします。

Microsoft Copilot Studioの公式ドキュメントでは、知識源を使わない回答を許可する設定と、知識源を使った回答に限定する設定が区別されています。引用がない場合に回答を出さない動作も説明されています。製品によって設定名は異なりますが、根拠を取得できないときの扱いは導入前に決める必要があります。

公開Webサイトを参照させる場合も、ドメイン全体を無条件に対象にしません。ニュースや採用情報まで検索対象へ入れると、現在の問い合わせに使えない文章が返ることがあります。過去キャンペーンも同様です。回答に使う階層を限定し、廃止済みページを除外します。

答える範囲と答えない範囲を分ける

回答は内容によって三段階に分けます。確定した共通情報はAIが回答します。追加条件が必要な情報は、質問して条件をそろえてから回答します。契約判断や個別審査が必要な内容は、人へ渡します。

たとえば料金案内なら、公開中の基本料金は回答できます。個別割引や解約精算は、契約内容を確認できる担当者へ渡す方が安全です。「分かりません」と言わせるだけではなく、何が不足しているため回答できないかを伝え、次の窓口へつなぎます。

Google Cloudの公式ドキュメントでは、生成的な応答と、応答内容を明示的に制御するフローが分けられています。すべてを生成回答へ寄せる必要はありません。金額や期限、本人確認後の処理などは、誤りの影響を考えて固定フローにする選択肢があります。

変わる情報はFAQ本文から分離する

在庫や配送状況は、FAQへ書き写すと古くなります。予約枠と契約状態も同様です。FAQには「どの条件を確認するか」と「どのシステムを見るか」を残し、現在値はAPIや業務画面から取得します。

この区別は、知識検索と業務処理の違いでもあります。FAQは制度や手順を説明できますが、顧客ごとの現在値を確定するものではありません。電話番号が一致しただけで契約内容を読み上げず、本人確認と参照権限を別に設計してください。

システムから値を取れなかった場合も、古いFAQ値で補わないようにします。「現在の配送状況を確認できないため、担当者から案内する」のような代替経路へ進めます。情報取得の失敗と、対象データが存在しない状態は分けて記録します。

更新責任者と有効期限を決める

FAQごとに、内容を承認する責任者と更新作業をする担当者を決めます。料金は商品部、配送条件は物流部のように、内容を確定できる部門を責任者にします。AI運用担当だけで制度変更を判断しない体制が必要です。

有効期限は、すべて同じ日数にそろえなくて構いません。キャンペーンは終了日、料金は次回改定日、通常手続きは定期確認日を持たせます。期限を過ぎた情報は、次回更新まで回答対象から外すか、人へ渡すかを先に決めてください。

変更時には本文だけでなく、質問例と回答範囲を確認します。引き継ぎ条件も確認対象です。制度の表現が変わらなくても、対象商品が増えれば質問の分岐が変わる場合があります。

公開版と更新日時、承認者を一組で記録します。通話結果をどの版で検証したか追える状態にしてください。

人へ渡す条件を回答と一緒に書く

有人引き継ぎは、FAQが見つからなかったときだけ発生するものではありません。本人確認が必要な場合や、複数制度が競合する場合も対象です。相手が回答に納得しない場合と期限が迫っている場合も、人が判断すべきです。

各回答単位には、次の条件を付けます。

• AIが回答して完了できる条件
• 一問だけ追加確認する条件
• その場で人へ転送する条件
• 折り返し受付へ切り替える条件
• 回答せず記録だけ残す条件

引き継ぎ時には、相手の質問と参照した回答単位を渡します。AIが伝えた内容と未確認の条件も必要です。Amazon Connectの公式ドキュメントには、ナレッジベースの文書や抜粋から回答を作るプロンプトの例があります。出典表示や保存の方法は採用する機能で確認し、回答文と参照元を担当者が照合できる状態にしてください。

営業時間の回答単位を一枚にする

次は架空の窓口を使った記入例です。質問と答えだけでなく、適用範囲と例外まで一緒に登録します。実際には自社で承認した資料名と版へ置き換えてください。

この例では、通常営業時間を答えられても「今すぐ担当者につながる」とは約束しません。在席状況は別の情報だからです。FAQ原稿の完成と、実際の転送成功を分けて試してください。

十二の質問で受け入れ確認をする

公開前の試験は、FAQに書いた質問をそのまま読み上げるだけでは足りません。実際の言い換えと条件不足を含む十二件を用意します。対象外や古い情報も試してください。

1. 登録した表現と同じ質問
2. 短い言い換え
3. 会話の途中で条件が追加される質問
4. 二つの用件を含む質問
5. 対象商品が特定できない質問
6. 適用期間の境界日に関する質問
7. 廃止済み制度を尋ねる質問
8. 個別契約の判断が必要な質問
9. 本人確認前に個別情報を求める質問
10. 回答後に相手が否定する質問
11. 参照元を取得できない状態
12. 有効期限を過ぎた回答

各通話では、回答が自然かだけでなく参照元も確認します。適用条件と終了状態、有人引き継ぎも評価対象です。答えられた件数を増やすことより、答えるべきでない質問を正しく止められるかを優先してください。

最初に、変更が少ない一つの用件から実際の質問を十件集めます。回答の根拠と適用範囲、責任者を一枚にまとめてください。有効期限と人へ渡す条件も加えます。その一枚を十二の試験へ通せば、FAQを増やす前に運用上の不足を見つけられます。