AIで問い合わせログからFAQ候補を抽出する方法

問い合わせログからFAQ候補を見つけるには、AIへログ全体の要約を頼むより、まず不要な個人情報を除き、同じ原因・同じ回答で解決できる質問をまとめます。そのうえで頻度、対応負荷、回答根拠、例外の多さを見て、公開FAQにできる候補と個別対応に残す候補を分けます。AIが作るTopicは調査の仮説であり、FAQの答えを確定する情報源ではありません。

まず「FAQにできる質問」と個別案件を分ける

問い合わせが似た言葉を使っていても、答えが同じとは限りません。「ログインできない」という話には、パスワード再設定、認証コード、アカウント停止、社内SSOなど異なる原因があり得ます。回答が変わる条件を含めてグループ化し、判断できないログを無理に分類しないでください。

表は横にスクロールできます

ログの例	まとめ方	公開FAQ候補か
再設定メールが届かない	メールアドレス確認、迷惑メール、送信制限で枝分かれ	候補。手順の根拠が必要
SSOでログインできない	管理者設定や社内アカウントの問題	一般FAQで説明できる範囲だけ候補
特定契約の請求額が違う	契約・利用状況を個別照合	FAQにせず個別対応
操作画面が見つからない	製品バージョン、権限、画面状態で分岐	画面・条件を確認してから候補

この表は架空の問い合わせ例です。実際のログには顧客固有の事情があるため、同じ単語だけを手掛かりにまとめないようにします。FAQ化するか決める前に、回答の違いを生む属性を特定してください。

分析用データを作る前に、漏らす情報を減らす

問い合わせログには氏名、メールアドレス、注文番号、電話番号、住所、支払情報、アカウント識別子、画面画像などが含まれることがあります。FAQ候補を探すだけなら不要な識別情報は削除し、ログのIDも個人を追跡できる番号をそのまま残さず、必要な場合は社内で認められた仮IDへ置き換えます。

文章だけのログでなく、添付画像・URL・引用されたメールに個人情報が残っていないかも確認します。自由記述に健康・決済・認証情報などが入っていた場合は、社内の取扱いルールに従って除外し、分析用データへ複製しない方法を検討します。匿名化だけで再識別リスクが必ず消えるとは限らないので、入力先、アクセス権、保存期間、削除方法も確認します。

次に分析範囲を決めます。期間、対象チャネル、問い合わせの定義、除外対象を決めずに件数を比べると、季節性やチャネルの違いをFAQ効果と誤解するからです。たとえば「直近4週間のメールとチャット」「スパムと社内テストを除く」「問い合わせ1件を1レコードにする」といった定義を先に記録します。これは例であり、期間や対象チャネルは自社の量と運用に合わせます。

AIに渡すのは、答えではなく分類の仮説

初回の分類は少量のサンプルを人が読み、会社独自の言い回しや同音異義の用語を把握してから始めます。AIには分類名の案、同じTopicと考えた理由、別分類の可能性、未分類理由を一緒に出させます。内容を確認できないログや複数の問題を含むログは「要確認」にします。

【Prompt例】

以下は識別情報を除去した問い合わせ記録です。回答を作ったり、顧客の状態を推測したりせず、FAQ候補の分類だけをしてください。

各記録について：問い合わせの要旨（書かれている範囲）／Topic・Subtopic候補／同じ回答で解決できると考えた根拠／別の原因・回答になる可能性／個別対応が必要か／分類できない場合は「未分類」。

禁止：顧客名や契約条件を推測する、問い合わせにない回答・解決策を作る、複数の問題を一つにまとめる、FAQ掲載可否を最終決定する。

「確信度」を数値で返させても、その数値を統計的な信頼性や正解率と見なさないでください。実際のログを人が確認し、分類の境界を調整する方が重要です。

Topic名は「同じ回答を使えるか」で決める

分類の細かさは、見た目の類似度ではなく回答内容で決めます。たとえば「再設定メールが届かない」と「メールアドレスを忘れた」は、同じログインTopicでも案内する手順が違う可能性があります。逆に、表現が異なる質問でも、同じ確認手順で解決するなら同じFAQの言い換えとして扱えるかもしれません。

表は横にスクロールできます

問い合わせ群	同じに見える理由	分ける確認	Topic決定の条件
パスワード変更／再設定	どちらも認証情報に関する	変更済みでログイン中か、ログイン不能か	最初の操作が同じなら候補を統合
請求書／領収書	どちらも支払い証憑	発行主体、必要な書類、契約形態	依頼先と手順が違えば分ける
画面が見つからない	同じUIの質問に見える	権限、プラン、Web/モバイル	操作手順が変わる条件を残す
解約したい／返金したい	契約を終えたい要望	解約受付と返金可否は別条件	個別契約の判断はFAQで断定しない

Topicの数を少なく見せることが目的ではありません。分類が細かすぎて担当者が選べない場合は親Topicへまとめ、回答を変える条件だけSubtopicとして残します。分類不能のケースを無理に既存Topicへ押し込まず、「未分類」をレビュー対象にします。

頻度だけでなく、対応負荷と回答可能性を見る

FAQを先に作る候補は、問い合わせ件数が多い順とは限りません。件数、対応時間、同じ説明の再利用可能性、回答根拠、例外・個別条件を同じ表で見ます。

表は横にスクロールできます

候補	件数	対応負荷	回答根拠	例外の多さ	暫定判断
再設定メールの確認	中	低〜中	現行Helpがある	条件で分岐	手順FAQ候補
契約ごとの請求差	低	高	個別契約情報	多い	FAQではなく個別対応
設定画面の場所	中	低	現行画面のHelp	権限・プランで分岐	条件を明記した候補
仕様改善の要望	低	高	回答根拠ではなく要望	顧客ごとに異なる	公開FAQにしない

この評価では「件数」はログの対象期間や対象チャネルと一緒に扱います。期間が違う候補を件数だけで比べないようにします。対応時間が記録されていない場合は、推定値を埋めず「未計測」と残してください。頻度が高くても、回答が契約・本人確認・個別の技術状態で変わるなら、FAQとして一般化できる範囲を限定します。

出力には、質問だけでなく根拠と例外を残す

FAQ候補を決める段階では、AIに回答文まで完成させる必要はありません。まず候補の質問、想定される言い換え、回答の正本、適用条件、例外、担当者による確認を一覧にします。

表は横にスクロールできます

項目	記録例
FAQ候補	再設定メールが見当たらないときの確認方法
言い換え	メールが届かない、パスワードを戻せない
対象条件	登録メールアドレスでログインする利用者
回答根拠	現行Help Centerの該当手順
例外	SSO利用者、アカウント停止、登録先不明
内容責任者	Support担当
公開前確認	手順・画面・URL・例外を実画面と正本で確認
再確認条件	画面変更、認証方式変更、問い合わせ増加

Help Centerに正しい回答がないなら、AIに埋めさせず「回答根拠未整備」と記録します。Helpや規約にない回答は、人が答えを決めた後にFAQへ反映します。FAQ記事の作成・公開をAIのTopic抽出と同じ工程に混ぜないことで、分類の仮説がそのまま公式回答になることを防げます。

分類結果を検証する小さな手順

全件を自動分類してそのまま採用するのではなく、まずサンプルで境界を確かめます。

1. 代表的な問い合わせを読み、分類定義案を人が作る。

2. 匿名化したサンプルでAIに候補分類と根拠を出させる。

3. 人が元ログへ戻り、誤統合・誤分割・未分類を記録する。

4. 境界が分かりにくいTopicを定義し直す。

5. 修正後に別のサンプルで再確認する。

6. 本番候補の全件を対象にする前に、社内承認とデータ保護条件を確認する。

サンプルの結果は全期間・全チャネルにそのまま当てはまりません。問い合わせ構成が変わるとTopicも変化します。IntercomのTopics Explorerも、会話を分類・表示する製品機能として使えますが、対象となる会話や期間などの条件があり、Topicに出ない会話もあります。特定製品のTopic表示は分析の一つの材料であり、FAQ候補の完全な母集団ではありません。

FAQ公開後は「減少」だけで成功を決めない

FAQを公開した後、同じ問い合わせが減ったかだけを見ると、サポート窓口への到達方法が変わった場合や、分類・受付数が変わった場合を見落とします。公開日、対象FAQ、関連問い合わせの定義、比較期間、サポート量の変化を記録してください。

FAQ経由で解決した割合を測れる場合も、他の変更と切り分けられるとは限りません。閲覧数が増えたのに問い合わせが減らないなら、FAQが見つからない、回答が途中で止まる、対象条件が不明、個別対応の問題だった可能性を調べます。問い合わせが減っていても、顧客が解決できず離脱した可能性を別指標やサンプルレビューで確認します。

再分類は、サービス仕様や問い合わせ経路が変わったとき、未分類が増えたとき、回答根拠が更新されたときに行います。AI分類は一度作ったら固定できるカテゴリ表ではなく、人が管理する運用仮説です。

AIものさしの判断

問い合わせログからFAQを作る工程は、「匿名化してAIへ渡す」だけでは完了しません。何を分析対象にしたか、何を除いたか、分類を誰が確認したか、回答の正本はどこか、どの質問を公開FAQから外すかを残して初めて、FAQ制作へ渡せる候補になります。

次に行うことは、少数のログを社内承認済みの分析環境で確認し、回答が同じケースと個別に分けるケースを人が定義することです。識別情報を安全に除けない、入力先が未承認、あるいは正本となる回答が見つからない場合は、そのデータをAIへ入れず、保留理由と担当者を記録してください。