AIで問い合わせ履歴からFAQ候補を探すには？似た質問と別の判断を分ける方法

サポート責任者は、AIが拾う候補とFAQの採用を分ける

履歴には、顧客の質問だけでなく、挨拶、受付の連絡、過去のやり取り、担当者の見立てなども含まれます。全文の言葉が似ているだけでまとめると、同じ「請求書」でも、再取得したい相談と宛名を変えたい相談を一緒にしてしまうことがあります。まず、顧客が何をしたいのか、答えを変える条件は何かを分けて拾います。

AIの役割は、その整理を人が見比べるための候補を用意することです。候補のまとまりができても、正しい回答や承認済みのルールが得られたわけではありません。サポート責任者は、元の相談と既存FAQ、回答の根拠資料を照合し、同じ回答で扱えるかを決めます。候補抽出と回答採用を分けると、根拠のない回答を付け足さずに質問を整理できます。

たとえば、同じ再取得の質問が違う言い方で現れた場合、FAQを別々に2本作るより、既存の案内で答えられるか、見出しや別表現の案内を直せるかを先に確かめます。一方、宛名変更は再取得とは別の判断が必要です。請求書という共通の話題だけで、同じ手順を使えるとは決めません。

Zendeskの公式実務資料も、問い合わせを用件で分類し、個別の記録を読んで、記載する課題や既存コンテンツを検討する流れを示しています。当該サービスの実務参考であり、記事内の件数例を、すべての会社の開始条件や必要データ量にするものではありません。

担当者は、AIへ渡す履歴の範囲と照合資料をそろえる

AIへ何を渡し、何をまだ決めないか。

原文と質問候補の対応を残し、既存案内と根拠資料を分けて用意します。図の資料は説明用で、実データ利用の承認を示しません。この図は理解を助ける説明用で、実AI実行・承認・公開の結果ではありません。

最初に、何の相談から、どのFAQを見直すために候補を拾うかを決めます。問い合わせの入口、対象期間、商品・機能、顧客向けか社内向けかをそろえると、異なる仕事を混ぜにくくなります。期間や対象が不明な履歴なら、その不明点を残し、頻度や傾向の根拠として扱う前に確かめます。

実際の履歴を使う場合は、自社で利用を認めた範囲に限り、氏名・請求先・契約情報など、候補を整理するのに不要な情報を社内の取扱条件に従って取り除きます。匿名にしただけで、どのAIへでも入力してよいことにはなりません。使う環境と情報の利用範囲が分からなければ、担当窓口へ確認し、実データの投入を先に進めないでください。本稿の架空例は、実データ処理の許可を示しません。

次に、現在の顧客向けFAQと、回答を承認できる根拠資料の所在を分けてそろえます。過去の返信や担当者のメモは、探すべき話題の手掛かりにはなっても、今も適用できる公開回答とは限りません。資料の対象・版・適用条件を確かめる担当と、候補を採用する責任者も決めます。

履歴には、元の相談へ戻れる参照先を残します。教材では「再取得の質問1」「再取得の質問2」「宛名変更の質問」と呼びます。実業務では自社の許可された記録に戻れる方法を使い、顧客の識別情報を質問見出しへ持ち出さないようにします。質問案だけが独り歩きすると、条件の抜けや、違う相談が混ざったことを後から確かめにくくなるためです。

Zendeskの社内ナレッジに関する資料は、対象読者と最初の範囲を決め、社内向けと顧客向けの内容を区別しています。ここで参照するのは対象の分け方で、製品の設定変更や公開権限を案内するものではありません。

担当者は、原文と対応する質問候補をAIへ依頼する

候補を原文に戻して確かめられるか。

教材原文と要点・条件の整理例を両方向で照合します。「先月分」を具体的な年月へ補っていません。実AI出力ではありません。この図は理解を助ける説明用で、実AI実行・承認・公開の結果ではありません。

AIへの依頼は「履歴からFAQを作って」だけで終えず、何を拾い、何をまだ決めないかを示します。先に質問候補を拾う段階では、回答を創作させず、顧客の言葉・求める行為・条件・元の相談との対応を分けて出すように頼みます。挨拶や進捗連絡を質問として数えないこと、不明な条件を推測で埋めないことも明記します。

依頼に条件を書いても、正しい候補が必ず出るわけではありません。出てきた候補がどの原文に対応しているかを、人が1件ずつ戻って確かめます。たとえば、宛名変更の言葉が再取得の候補へ混ざった場合は、同じ回答を使えるかを判断する前に、その対応を分け直します。

逆に、短く言い換えた質問が一覧から落ちることもあります。抽出された候補の数だけを見ると、元の相談が全部扱われたかは分かりません。元の相談側から候補へたどり、どこにも対応していない質問がないかも確認します。候補から原文へ、原文から候補へという両方の照合が必要です。

モデルや分類方法を変える前に、抽出する単位が何かを見ます。挨拶を含む長い相談全文なのか、顧客が求める行為と条件なのかで、候補の意味は変わります。本稿は特定のモデル・類似度の数値・データベースの設定を推奨せず、担当者が確かめられる候補と原文の対応を扱います。

担当者は、3相談の誤統合と拾い漏れを元文で確かめる

似た3相談を、どこまでまとめるか。

再取得の2表現は同じ答えで扱う候補です。宛名変更は別判断で条件未確認です。実際の承認済み資料と解決は全3相談で未確認です。この図は理解を助ける説明用で、実AI実行・承認・公開の結果ではありません。

原文の質問が混ざったり落ちたりしていないか。

仮の編集例です。請求書という話題だけで行為を混ぜていないか、元文2の対応先があるかを確認します。実AIのエラーや修正成功ではありません。この図は理解を助ける説明用で、実AI実行・承認・公開の結果ではありません。

架空の元文は「前月の請求書PDFをもう一度見たい」「先月の請求書を再ダウンロードしたい」「請求書の宛名を会社名に変えたい」の3つです。説明用の3件であり、実際のチケット件数や繰り返す頻度を測った母集団ではありません。2表現が並んだことから、多数の顧客に同じ問題が起きているとは言えません。

最初の2表現は、同じ再取得の答えで扱えるかを確かめる候補です。「前月」と「先月」は似た相対表現ですが、別の日に届いた相談なら対象月が同じとは限りません。この教材には受付日や対象の年月がないため、具体的な月へ直したり、同じ利用者の同じ請求書だと決めたりしません。

既存案内として挙げた「架空の既存案内：請求書画面の再取得手順」も、照合先の候補というラベルだけです。実際の承認済み資料は3相談とも未取得なので、画面のボタンやクリック手順を作らず、再取得できた結果も付け足しません。同じ答えとして採用する前に、対象月や利用条件がその案内に合うかを担当者が確かめます。

次の元記録では、各相談の8項目を読めます。「未取得・未確認」は、資料が存在しないと確定したこと、変更が拒否されたこと、処理が失敗したことを意味しません。求める行為の整理や同じ答えの候補は教材上の整理で、顧客の逐語発言や承認済み回答と区別します。

教材全体の会社・担当・判断案と実施状況も以下に示します。実AI実行と顧客への返信は未実施です。実際の対象数、頻度、影響、公開FAQ、削減、業務成果は未取得のままです。

責任者は、既存回答への統合・新候補・保留を判断する

候補を既存案内へつなぐか、新候補か、保留か。

根拠と適用条件を確認できた場合の編集案を示します。今回の再取得は照合待ち、宛名変更は保留して請求担当へ確認する段階です。この図は理解を助ける説明用で、実AI実行・承認・公開の結果ではありません。

候補と元文の対応を確かめたら、既存の顧客向けFAQと承認済み資料を人が読みます。質問の言葉が似ているかだけでなく、顧客が求める行為、対象の条件、案内できる手順、例外が同じ範囲に収まるかを確かめます。資料へのリンクがあるだけで、今回の候補の答えが裏付けられたことにはなりません。

この教材の再取得2表現は、架空の既存案内と条件を照合する段階です。新しいFAQが2本できたわけでも、既存FAQの更新が完了したわけでもありません。宛名変更は別の質問候補として保留し、対象の請求書や月、変更できる条件、案内の根拠を請求担当へ確かめます。ここで挙げる確認項目は、実際の条件が判明した値ではありません。

返答や資料が得られたら、それがどの質問と条件に当てはまるかを読みます。ある月や利用条件だけの手順なら、すべての請求書へ広げず、その範囲を回答案の近くに残します。担当者が確認したことと、公開を判断したこと、実際に掲載されたことも分けて記録します。資料が戻らなければ、候補を保留したまま確認先へつなぎます。

候補の優先順位を付ける際も、今回の架空3件から頻度や影響を作りません。実業務で同じ期間・同じ対象にそろえた記録が得られた場合に、相談の繰り返し、対応負担、顧客が止まる仕事などを見ます。記録がない項目は未測定とし、候補の数を増やしたことを効果にしないでください。

掲載する場合は、責任者が根拠の版・適用範囲と実際の質問・回答を照合し、変更時に見直す担当を残します。公開後に同じ相談が届いたら、質問候補が漏れていたのか、回答の条件が足りないのか、既存回答へたどり着けなかったのかを分けて調べます。検索や閲覧、顧客の理解、問い合わせ削減、仕事の成果は別の確認です。

同じ答えになる単位と別の判断を分ける基本は、社内FAQの質問と回答範囲を整える記事でも説明しています。本稿は顧客サポート履歴からAIに候補を拾わせる前段を扱います。承認済みFAQから顧客への回答案を作る段階は、FAQに基づく回答案と人への引継ぎで扱います。

まとめ：許可済みの1件から、元文と候補を対応させる

最初に何をそろえ、何を人が判断するか。

利用範囲を確かめ、元文と候補、誤統合と漏れ、根拠と条件を順に照合します。実AI実行・返信は未実施、承認・解決・成果は未確認です。この図は理解を助ける説明用で、実AI実行・承認・公開の結果ではありません。

AIで問い合わせ履歴からFAQ候補を探すときは、顧客が求める行為と条件を拾い、元文との対応を残します。人が誤統合と漏れを確かめ、既存FAQと根拠へ戻って、既存回答への統合・新候補・保留を判断します。

• 履歴を渡す前に、利用を認めた情報の範囲、対象期間、照合資料と担当をそろえる。
• AIには回答の確定ではなく候補の整理を頼み、顧客の原文と候補の対応を両方向で確かめる。
• 再取得の2表現は同じ答えの候補にとどめ、実暦月や承認済み手順を推測しない。
• 宛名変更は別の判断として保留し、請求担当へ必要条件と根拠を確かめる。
• 候補数、公開、検索、問い合わせ削減、業務成果を別の記録として扱う。

AI業務の判断を整理する案内へ