AIで問い合わせログからFAQを継続更新する方法

問い合わせログからFAQを更新するには、会話の要約をそのまま公開せず、繰り返される質問を「Knowledge Gap」として整理し、回答の正しさを正式な仕様・規約・担当者確認で確かめます。問い合わせは何が分かりにくいかを示すEvidenceであり、回答内容の正本ではありません。質問傾向の把握、根拠確認、改稿、公開後の再問い合わせ確認を一つの改善loopにします。

問い合わせを回答候補へ直結させない

会話ログには顧客の状況を知る材料がありますが、担当者の暫定回答、誤った案内、個別契約の例外、本人を特定する情報も含まれます。複数の会話で同じ説明が出たとしても、その説明が現在の公式条件だとは限りません。まず質問の型を抽出し、回答は別の正本から再構成します。

| 観測したこと | そこから分かること | まだ分からないこと |

| 同じ質問が複数回ある | そのtopicで迷いが生じている可能性 | FAQがないことが原因か |

| FAQ閲覧後に追加質問がある | 条件や例外の説明が不足する可能性 | 元記事が誤っているか |

| 担当者が同じ補足を繰り返す | 記事に書かれていない運用知識がある可能性 | 補足を全顧客へ公開できるか |

| 回答が担当者ごとに違う | 正本、更新日、案内手順の再確認が必要 | どちらの回答が現行か |

| 質問が急に増えた | 製品変更や障害の影響かもしれない | 恒久FAQにすべきか |

「問い合わせが多いのでFAQを作る」だけでは判断が足りません。障害や一時的なキャンペーンに関する質問なら、FAQよりstatus告知が適切な場合があります。契約固有の質問なら、一般記事でなく個別サポートへ戻すべきかもしれません。まずtopic、期間、製品version、問い合わせ経路を揃え、同じ原因から出た質問かを確かめます。

Gapを分類して担当へ渡す

FAQ候補は、最低でも「情報がない」「記述はあるが条件が足りない」「記事を見つけられない」「内容が古い疑い」「案内のばらつき」「記事では解決できない」に分けます。分類によって次のActionが変わります。見つけにくさはタイトルや導線の問題、古い疑いはownerへの事実確認、解決不能はサポート体制や製品改善へ渡します。

更新queueには、質問topic、観測期間、問い合わせ件数、再問い合わせや否定的反応、参照した既存記事、Gap仮説、回答の正本、owner、判定、公開後の確認指標を記録します。件数は優先順位の一材料です。頻度が低くても返金、契約、権限、securityに関わる誤解は影響が大きい可能性があり、頻度だけで後回しにしません。影響度を判断できない場合は、勝手に重要度を低くせず担当者へ確認します。

ログから公開FAQへ進めるworkflow

1. 対象を決める：問い合わせ期間、製品機能、言語、channelを限定します。複数製品の質問が同じtopicに混ざらないようにします。

2. 個人情報を除く：氏名、メール、注文番号、住所、会話中の秘密情報をFAQ案から外します。原ログへのアクセス権とAIサービスへの入力条件は別途確認します。

3. 質問をまとめる：言い換えをまとめても、前提条件が違う質問を同じtopicに潰さないようにします。質問本文は必要なら匿名化し、個別の引用を公開しません。

4. Gapを分類する：欠落、曖昧、見つけにくい、矛盾、古さ、サポート対象外のどれかを仮置きします。AIの分類は候補であり、ownerが確認します。

5. 回答の正本を探す：製品仕様、契約、公式policy、承認済み手順などを参照します。会話ログだけで料金・返金・権利・securityの回答を決めません。

6. FAQ案を作る：質問、短い回答、条件、例外、更新日、参照元、問い合わせ先を分けます。確認できない点は「要確認」とし、断定文に変換しません。

7. 公開前reviewを行う：内容ownerが根拠と適用範囲を確認し、support担当が顧客に伝わる言葉か確認します。変更履歴と公開責任者を残します。

8. 効果を追う：公開後に同じtopicの再問い合わせ、解決率、記事評価、誤回答報告を観察します。減少しても、季節性や製品変更の影響を考慮します。

この流れでは、質問集約と文章の下書きをAIに任せやすく、公開判断と事実の承認は人に残します。生成された回答をそのままナレッジsourceへ追加する設定にすると、誤案内が次のAI回答にも使われる循環が起こり得ます。下書き領域と公開済みknowledgeを分離し、承認済みの記事だけが回答sourceに入る構成にします。

具体例：料金の質問が増えた場合

「月額はいくらですか」という質問が増えたとき、まず同じplan、通貨、契約期間、seat数、税の扱いについて質問しているかを分けます。複数の条件を一つのFAQへまとめると、読者が異なる料金条件を誤って適用することがあります。価格ページや契約条件を確認し、変動しやすい情報は確認日、対象plan、地域を明示します。

たとえばログから「無料で使えますか」が繰り返し見つかっても、ログだけから無料枠の内容を答えてはいけません。公式の現行plan説明を確認し、「無料登録できるか」「無料枠の制限」「有料への切替条件」を別の問いとして整理します。未確認の制限や将来の価格は、回答から外すかowner確認へ回します。確認後に「対象者」「条件」「例外」を短い冒頭回答のあとへ配置すれば、検索者は自分の状況に当てはまるか判断しやすくなります。

同じ質問が多いのにFAQへの訪問が少ないなら、記事の検索性や導線を調べます。FAQを読んでも再問い合わせが続くなら、回答の曖昧さ、例外、読者の前提、製品側の不具合を切り分けます。記事への誘導だけを強めると、実際には解決しない質問を「自己解決できるはず」と押し戻すことがあります。サポートが必要なケースへの連絡先も残します。

AIによるrecommendationを使う場合の境界

Intercomの公式Helpでは、会話からcontent recommendationを作り、missing、unclear、duplicate、contradictoryといった内容上の候補を確認する機能が説明されています。提案は受け入れ、編集、却下などのreview対象です。利用条件、対象データ、追加プラン、十分な会話量などの条件は変わるため、現在のworkspaceと公式説明で確かめます。recommendationがないことは「Gapがない」という意味ではありません。

過去の会話データをナレッジ改善へ使う機能と、顧客へ公開する回答を作る機能も分けて考えます。会話履歴を参照できても、その内容が正式な仕様書と同じ権威を持つわけではありません。個別サポートでのみ正しい例外や、誤案内、個人情報が含まれる場合があります。学習・検索・保存の扱いは製品の契約条件と組織のprivacyルールに沿って確認し、公開用の文面には必要最小限の情報だけを残します。

公開前と公開後のQA

公開前は、次の観点で短いチェックをします。

| 観点 | PASS条件 | HOLD条件 |

| 根拠 | 現在の正式資料または権限あるownerの確認がある | 会話ログだけが根拠 |

| 対象 | 読者、plan、地域、製品versionが分かる | 適用範囲が曖昧 |

| 例外 | 料金・契約・返金など条件が明記される | 重大条件が未確認 |

| privacy | 個人が識別できる情報を外した | 固有名詞・個人情報が残る |

| 更新責任 | ownerと見直し契機が分かる | 更新後の責任者がいない |

| 次の行動 | 読者が自己解決か問い合わせか選べる | 行き先が分からない |

公開後は「問い合わせ件数だけ」を成功指標にしません。記事が見つからないため問い合わせが減らない場合もあれば、製品障害で質問が増えることもあります。topic別の自己解決、再問い合わせ、記事feedback、誤案内の報告を見て、記事、導線、製品、サポート手順のどこを直すかを判断します。問い合わせが減った場合でも、ユーザーが諦めて離脱していないかを確認できる指標と組み合わせます。

AIものさしの判断

FAQ更新は「会話を要約して掲載」する作業ではなく、質問傾向を見つけ、Gapを特定し、正本で回答を確かめ、ownerが承認し、公開後に解決状況を確かめる継続loopです。会話量は何を調べるかを決める手掛かりですが、回答の根拠そのものにはなりません。AIを使う範囲は候補整理とdraftまでにし、公開範囲と事実判断を人が持つと、FAQを更新しながら誤案内の再生産を抑えられます。

更新queueの優先順位を決める

候補を並べるときは問い合わせ件数の降順だけにしません。読者への影響、誤案内の危険、解決できないまま残る頻度、内容の変更しやすさ、根拠の入手可能性を分けて記録します。根拠が見つからない候補は、公開用FAQに進めず「owner確認待ち」に置きます。影響が大きく情報が不足しているときは、暫定記事を書くより、問い合わせ窓口や障害告知へ誘導するほうが適切な場合があります。

たとえば、月に一度の質問でもアカウント停止やデータ消失に関わるなら、件数だけで低優先とはしません。逆に、同じ単純質問が多数あっても、既存記事へのリンクが一箇所で見つからないだけなら、新規記事ではなく導線修正で解決する可能性があります。候補の「発生量」と「影響度」を別軸にし、どちらの情報もないときは仮定で順位を固定しないようにします。

AI生成案を評価する記録

提案を受け入れたかどうかだけでは、recommendationの質は分かりません。提案ごとに、該当する会話例、既存knowledge、判断理由、修正後の文章、却下理由を記録します。一定期間後に、誤った提案、重複、すでに解決したGap、見落とされた重要質問をサンプル確認します。少数の会話しかないtopicでは、AIが候補を出さない可能性があるため、検索ログや担当者の定期レビューなど別の観測方法を残します。

AI recommendationを採用したあとに問い合わせが減っても、直ちにFAQの効果と断定しません。製品のUI変更、季節性、サポート人員、問い合わせ分類方法の変更が影響することがあります。対象期間と変更点を記録し、可能なら同じtopicの解決率や再問い合わせ率と合わせて判断します。