FAQをAIで作成・整備する方法 品質を保つコツ
この記事の要点
問い合わせログからFAQを生成するプロセス、AIが生成したQ&Aの事実確認方法、定期更新の仕組み、チャットボット連携までを実務目線で解説します。適切な手順を踏めば、FAQの初稿を数時間で仕上げられます。
結論:問い合わせログがあればFAQの初稿は数時間で作れる
問い合わせログをAIに渡し、質問パターンの分類とQ&A化を指示すれば、FAQの初稿を数時間で作れます。ゼロから考えるより、実際に届いた質問を土台にするため、「使われるFAQ」になりやすいのが最大の利点です。
ただし、AIが生成したQ&Aをそのまま公開すると、事実と異なる内容が混入するリスクがあります。生成後の事実確認と定期更新の仕組みを合わせて作らないと、FAQが信頼を損なう原因になります。
この記事では、問い合わせログからFAQを作るプロセス、確認の手順、更新の仕組み、チャットボットとの連携まで、順を追って解説します。
なぜFAQはすぐ陳腐化するのか
FAQが役に立たない最大の原因は、作りっぱなしになることです。製品の仕様が変わった、料金体系が変わった、サービスの提供範囲が変わった。それでもFAQが更新されないと、顧客は古い情報を信じて行動し、問題が起きてから担当者に問い合わせを入れます。
もう一つの原因は、FAQ作成者の推測で作られていることです。「こういう質問が来るだろう」という想定で作るFAQは、実際に届いている質問とずれることが多い。問い合わせログを使えばこのずれをなくせます。
AIを使うと、この2つの問題に対応できます。ログから実際の質問を拾い、更新作業の手間を下げることで、FAQを生きた状態に保てます。
ステップ1:問い合わせログの前処理
最初に行うのは、AIに渡す素材を整えることです。
まず、個人情報を除去します。顧客名、メールアドレス、電話番号、住所など、個人を識別できる情報はすべて削除またはマスキングします。「〇〇様」は「お客様」に置き換える、メールアドレスは削除するといった処理を、AIに渡す前に行います。
次に、問い合わせ内容だけを抽出します。定型的な挨拶文、担当者の署名、チケット番号などは除き、顧客が聞きたいことの核心だけを残します。
件数が多い場合は、期間を絞ります。直近3〜6か月のログを使うと、現在の問い合わせ傾向を反映したFAQになります。
前処理したログをテキストファイルやスプレッドシートにまとめておくと、この後の作業がスムーズです。
ステップ2:問い合わせの分類と質問パターンの抽出
前処理したログをAIに渡し、質問のパターンを分類させます。
以下は当社への問い合わせ内容のリストです。
個人情報は除去済みです。
このリストから、よく聞かれている質問のパターンを
カテゴリ別に分類し、それぞれの件数と代表的な質問文を出してください。
# 出力形式
カテゴリ名:○件
代表的な質問:〜
---
# 問い合わせリスト
(ここに貼り付け)
このプロンプトで、「料金に関する質問:23件」「返品・交換:18件」「配送状況:15件」のように、優先度の高いFAQ項目が見えてきます。
件数が多いカテゴリから順にFAQを整備すると、対応できる問い合わせの割合が効率よく上がります。
ステップ3:FAQのQ&A生成
分類結果を確認したうえで、カテゴリごとにQ&Aを生成します。
以下のカテゴリの問い合わせから、FAQのQ&Aを作成してください。
# 条件
- Q:顧客が実際に使う言葉で質問文を作る
- A:一問につき100〜200字で、結論を先に書く
- 推測で書かず、提供する情報のみを回答に含める
- 「〜と思います」「〜でしょう」などの不確かな表現は使わない
# カテゴリ:返品・交換
(該当する問い合わせ内容をここに貼り付け)
「推測で書かず」の一文が重要です。この指示がないと、AIが実際の規定を知らなくても、もっともらしい回答を作ってしまいます。
一度に大量のカテゴリを処理しようとすると、回答の質が下がります。カテゴリを1つずつ処理し、担当者が確認できる粒度で進めるほうが、後の修正コストが低くなります。
ステップ4:事実確認の手順
AIが生成したQ&Aは、必ず事実確認を行います。これはFAQ品質を保つ最も重要な工程です。
確認のポイントは3つです。
第一に、回答の内容が自社の規定・仕様・サービス内容と一致しているかを確かめます。料金、期間、対応範囲などの数字は特に念入りに確認します。AIは「7営業日」のような具体的な数値を学習データから類推して書くことがあり、自社の実際の規定と違う場合があります。
第二に、古くなった情報が含まれていないかを確認します。問い合わせログ自体が古い場合、仕様変更前の内容が回答に反映されてしまうことがあります。
第三に、回答が曖昧になっていないかを確認します。「お問い合わせください」で終わる回答は、FAQとして機能しません。顧客が何を知りたいのかを考え、具体的な回答に書き直します。
確認は、その業務を担当する人が行うのが原則です。カスタマーサポートのFAQなら担当者が、製品仕様のFAQなら開発や製品管理の担当者が確認します。
ステップ5:FAQの体裁を整える
Q&Aの内容が確定したら、公開に向けて体裁を整えます。
質問文の統一です。「〜できますか」「〜はどうすればよいですか」のように、表現のパターンをそろえます。これはAIに渡して一括変換できます。
以下のQ&Aリストの質問文を、すべて「〜できますか」
または「〜はどうすればよいですか」の形に統一してください。
回答はそのままにしてください。
(Q&Aリストを貼り付け)
カテゴリ分類の見直しも行います。ユーザーが探しやすいカテゴリ構造になっているかを確認します。社内の業務分類より、顧客の関心ごとを軸にカテゴリを設けるほうが、目的の回答を見つけやすいFAQになります。
関連するQ&Aのリンクも設定します。「返品」を調べた顧客が「交換条件」も知りたいケースは多い。関連FAQへの動線を作ると、顧客の自己解決率が上がります。
定期更新の仕組みを作る
FAQを作るだけでなく、更新の仕組みまで設計しないと、作りっぱなしになります。
推奨するのは、問い合わせ件数のモニタリングと連動した更新サイクルです。月次または週次で問い合わせ件数を集計し、上位の質問にFAQで対応できているかを確認します。対応できていない質問が増えていたら、FAQを追加するシグナルです。
更新トリガーとして以下を設定します。
| トリガー | 対応 |
|---|---|
| 製品・サービスの仕様変更 | 関連FAQを即時更新 |
| 料金改定 | 料金関連FAQを即時更新 |
| 同じ質問が週5件以上 | 新規FAQ追加を検討 |
| 四半期に1回 | 全件の内容を見直し |
更新作業そのものもAIで補助できます。改定前後の差分をAIに渡し、影響するFAQを洗い出させる手順は、製品仕様の変更が多い現場で特に効果があります。
以下の仕様変更の内容に基づいて、更新が必要な可能性があるFAQを
一覧から選び出し、何を変更すべきかを提案してください。
# 仕様変更の内容
(変更内容を記載)
# 現在のFAQ一覧
(FAQをここに貼り付け)
FAQをチャットボットに組み込む
整備したFAQは、チャットボットの知識ベースとして活用できます。
多くのチャットボットツールは、Q&A形式のデータを登録してボットの回答として使う機能を持っています。FAQのデータをCSV形式やJSON形式でエクスポートし、ツールが指定する形式にAIで変換する手順が一般的です。
以下のFAQデータをCSV形式に変換してください。
列は「question」「answer」「category」の3列にしてください。
(FAQのQ&Aリストを貼り付け)
注意点は、チャットボットの知識ベースとFAQページを別々に管理すると、どちらかが古くなることです。FAQを更新したら知識ベースも更新する手順をセットで運用するか、単一のデータソースから両方に配信する仕組みを作ると、ズレが生じません。
また、チャットボットが回答できなかった質問のログは、FAQ拡充の素材になります。「対応できなかった質問」を定期的に確認し、FAQに追加するサイクルを作ると、ボットの対応率が継続的に改善します。
AIが生成したFAQに出やすい問題
現場で使ってみると、AIが生成したFAQには特有の問題が出やすいです。あらかじめ知っておくと、確認の効率が上がります。
最も多いのは、数字や期間の誤りです。「○営業日」「月額○円」などの具体的な数値をAIが推測で入れることがあります。すべての数字は自社の実際の規定と照合します。
次に、否定や例外の抜け落ちです。「〜できます」という肯定形で書いてしまい、「ただし〜の場合を除く」という条件が抜けるケースがあります。例外や条件が多い回答ほど注意して確認します。
また、複数のサービスや製品が混在する場合に、どれに当てはまる回答なのかが曖昧になることがあります。「どのプランに適用されますか」「対象製品はどれですか」を明記するよう、確認時に追記します。
ハルシネーションとは何かを理解しておくと、AIが誤情報を生成するメカニズムが分かり、確認ポイントが明確になります。
問い合わせログがない場合の代替手法
問い合わせログが蓄積されていない、または少ない場合も、AIを使ってFAQの土台を作れます。
一つは、製品マニュアルや規約文書からFAQを生成する手法です。
以下のサービス利用規約から、ユーザーが疑問に思いやすい点を
Q&A形式でまとめてください。
回答は規約の記述に基づいてのみ作成し、
規約に書かれていないことは推測せず「規約をご確認ください」と記載します。
# 利用規約
(規約文を貼り付け)
もう一つは、競合他社の公開FAQを参照して、自社サービスに当てはまる質問パターンを抽出する手法です。競合FAQをそのままコピーするのではなく、「この業界でよく聞かれる質問パターン」として参考にし、自社の回答を作ります。
マニュアルや手順書をAIで作る方法も、FAQの整備と並行して取り組むと、顧客向けと社内向けのドキュメント体系を効率よく作れます。
関係者を巻き込む進め方
FAQは、作成した後に現場で使われ、更新され続けないと意味がありません。作成プロセスから関係者を巻き込むと、使われるFAQになります。
カスタマーサポート担当者は、実際に問い合わせを受けている当事者です。AIが生成した回答が現場感覚と合っているかを確認してもらいます。
製品・サービスの担当者は、仕様や規定の正確性を確認します。数字や条件の正確さは、この担当者が確認しないと保証できません。
法務や品質管理の担当者は、誤解を招く表現や法的リスクのある表現を確認します。規約に関わるFAQや、返金・補償に関する内容は特に確認が必要です。
AIを使って短時間でドラフトを作り、関係者に短時間でレビューしてもらう。この分業が、FAQの品質と更新速度を両立させます。
効果の目安
FAQを整備した場合の問い合わせ削減効果は、内容と周知の仕方によって大きく変わります。一般的に、問い合わせ全体の30〜50%はFAQで対応できる内容と言われていますが、自社の数値は問い合わせログを分析してみないと分かりません。
効果を測るには、FAQページへのアクセス数と、その後の問い合わせ転換率を追います。FAQを見た後に問い合わせを送った割合が高ければ、FAQが疑問を解決できていないことを示しています。
また、問い合わせ件数の月次推移と、FAQの更新履歴を照らし合わせると、どの更新が効いたかが見えてきます。
セキュリティと個人情報の扱い
FAQの整備でAIを使う際の個人情報の扱いを、改めて整理します。
問い合わせログには顧客の個人情報が含まれることがほとんどです。これをAIに渡す前には、個人を識別できる情報を必ず除去します。名前、メールアドレス、電話番号、住所のほか、注文番号や会員IDも、それ単体では識別できなくても、組み合わせると個人を特定できる情報になる場合があります。
社内で利用するAIツールが、入力したデータを学習に使わない設定になっているかを確認します。法人向けプランではデータが学習に使われない契約になっているケースが多いですが、契約内容を確認してから使います。
個人情報保護法の観点では、顧客から得た情報を本来の利用目的以外に使うことは制限されています。FAQの整備への活用が、自社の利用規約やプライバシーポリシーの範囲内であるかを確認してから進めます。最新の法規制については、法務担当者または専門家に確認してください。
会社で生成AIを使うときの注意点として、情報漏洩リスクの考え方をまとめています。
FAQの品質チェックリスト
公開前に確認する項目をまとめます。
- 回答の内容が自社の規定・仕様と一致しているか
- 数字や期間、金額に誤りがないか
- 例外や条件が適切に記載されているか
- 「〜と思います」「〜でしょう」などの推測表現がないか
- リンク切れや参照先が正しいか
- 顧客が使う言葉で質問文が書かれているか
- カテゴリ分類が顧客目線になっているか
- 更新日が記載されているか
これらを確認してから公開します。公開後も定期的にこのチェックリストで見直すと、品質が安定します。
まとめ
問い合わせログをAIに渡して分類とQ&A生成を行い、担当者が事実確認をして公開する。この流れで、FAQの初稿を短時間で作れます。生成後の確認と定期更新の仕組みを合わせて作ることが、FAQを使えるドキュメントにし続ける条件です。チャットボットとの連携まで設計しておくと、自己解決率の向上につながります。
よくある質問
AIで生成したFAQをそのまま公開してもよいですか
そのままの公開は避けてください。AIは事実でない内容を自信を持って書くことがあります。必ず担当者が内容を確認し、製品・サービスの実態と一致しているかを検証してから公開します。
FAQの更新はどのくらいの頻度で行うべきですか
最低でも四半期に1回の見直しを推奨します。新製品のリリース、仕様変更、問い合わせ傾向の変化があった際は都度更新します。古いFAQは顧客の不信を招くリスクがあります。
問い合わせデータをAIに渡すとき個人情報はどうすればよいですか
顧客名、メールアドレス、電話番号などの個人を識別できる情報はAIに渡す前に削除またはマスキングします。問い合わせの内容と傾向だけを残した形で使います。
チャットボットとFAQはどう連携させますか
チャットボットの知識ベースにFAQのQ&Aデータを登録します。FAQが更新されたら知識ベースも同時に更新する運用にしないと、回答が古くなります。