チャットボット用FAQの作り方：質問整理から公開テストまで

チャットボットを公開しても、「その質問には答えられません」と返したり、古い料金や条件を案内したりすることがあります。原因はAIの性能だけではありません。利用者の質問、回答の根拠、適用条件がFAQに正しく整理されていない場合にも起こります。

「チャットボット FAQ 作り方」と検索している方が最初に確認すべき点は、既存資料をそのまま登録しないことです。過去の問い合わせから優先する質問を選び、回答の根拠、適用条件、更新期限、回答できない場合の案内までを一つの管理単位として整えます。

1. FAQとチャットボットの役割を整理する

WebページのFAQは、利用者が見出しを選び、必要な説明を読む形式が中心です。一方、チャットボット用FAQでは、自然な質問を適切な回答へ結び付ける必要があります。情報が不足していれば追加確認を行い、回答できなければ有人対応などの次の行動を示す設計も必要です。

そのため、Webページにある「料金」という見出しをそのまま質問として登録するだけでは不十分です。「初期費用はいくらですか」と「月額以外に費用はかかりますか」では、確認すべき条件や回答が異なる場合があります。会話だけで意図が分かる単位に分けてください。

作成前には、購入前案内、予約、社内手続き、サポートなど、チャットボットが扱う目的と担当範囲を決めます。あわせて、FAQの作成担当、根拠確認担当、公開承認担当、更新担当を定めます。複数の役割を一人が担う場合も、各工程で何を確認したかを記録します。

2. 問い合わせログを集めて表にする

材料として、メール、電話メモ、問い合わせフォーム、チャットなどに残る過去の質問を集めます。整った質問だけでなく、短い入力、言い間違い、前提が抜けた相談も残してください。これらは、利用者が実際に使う表現を把握する材料になります。

質問文だけでなく、担当者が返した回答、対応結果、参照した資料、確認日も記録します。現場で使われている回答が、料金表、利用規約、手順書などの正本と一致しているかを確認するためです。

項目	記録例	目的
元の質問	利用者が実際に書いた文	表記や言い換えを把握する
カテゴリ	料金、予約、使い方	担当範囲と優先順位を整理する
回答の根拠	料金表、利用規約、設定画面	回答の正しさを確認する
対応結果	解決、追加質問、有人対応	未解決の原因を調べる
更新情報	担当者、確認日、次回確認日	古い回答を残さない

ログの収集担当者は、個人名、メールアドレス、電話番号、個別の契約情報をAIへ入力する前に除外または置き換えます。匿名化後は別の確認担当者が元データと照合し、質問の意図を変えていないことと、実在する相談者を特定できる情報が残っていないことを確認します。本人確認情報、認証情報、決済情報、公開対象外の契約内容は入力しません。

3. 似た質問をまとめて優先順位を付ける

同じ意図の質問が複数ある場合は、一つの代表質問に整理し、別の言い方は言い換えとして残します。ただし、似た単語が含まれていても、必要な手続きや根拠が異なる質問は統合しません。「解約したい」と「予約をキャンセルしたい」は、回答内容が異なるなら別のFAQとして管理します。

作成順は、問い合わせ頻度だけで決めません。回答が正本から明確に決まるか、業務上重要か、誤答した場合の影響が大きいか、公開可能か、継続して更新できるかを確認します。頻度が高くても個別判断が必要な質問は、回答を自動化する前に有人対応への切り替え条件を整えます。

カテゴリは、利用者の目的と更新担当の双方が判断できる単位にします。「各種手続き」のような広い社内分類ではなく、「予約を変更したい」など、質問の目的が分かる名称を使うと、誤った分類を見つけやすくなります。

4. 質問文は利用者の言葉で書く

質問文には正式な商品名や機能名だけでなく、問い合わせログで確認できた普段の呼び方、短い入力、表記揺れを用います。管理画面の名称を知らない利用者でも質問できる表現になっているかを確認してください。

一つのFAQには、一つの意図を割り当てます。「料金と予約とキャンセルを教えてください」という複合質問にすべてをまとめて回答すると、適用条件や次の行動が分かりにくくなります。どの情報を求めているか確認するか、目的別のFAQへ案内します。

質問文を増やす際は、単語が似ているかではなく、同じ回答を返してよいかで判断します。回答後には、予約、申請、関連情報の確認、担当者への相談など、利用者が取る次の行動を一つ明示します。

5. 回答は根拠・条件・期限まで含める

回答は、最初に結論を示し、その結論が当てはまる条件と必要な行動を続けます。料金なら対象プラン、受付時間なら曜日や休業日、手続きなら事前に用意する情報を記載します。条件が確認できない場合は断定せず、追加確認または有人対応へ進めます。

利用者向けの文章とは別に、根拠となるページや資料、確認日、次回確認日、更新担当、変更が発生する条件を管理します。根拠や更新担当が異なる回答は分割してください。複数の条件を一つにまとめると、更新時に一部だけ古い状態が残りやすくなります。

質問と回答を整理した後は、ナレッジを登録する方法で登録時の確認事項を確認できます。PDFや画像を根拠資料にする場合は、読み取った内容が原本と一致しているか、文字認識結果を編集する手順に沿って確認してください。

6. AIで下書きを作るときに省略しない確認

AIは、問い合わせログの分類、代表質問の候補作成、回答文の下書きに利用できます。ただし、生成された文章を確認せずに公開してはいけません。資料にない条件や例外が、自然な文章として補われている可能性があるためです。

1. 候補の質問が元の問い合わせ意図と一致しているか
2. 回答の各記述を根拠資料で確認できるか
3. 適用条件、例外、確認期限が抜けていないか
4. 個人情報や公開対象外の情報が含まれていないか
5. 個別判断が必要な相談を無理にFAQ化していないか
6. 根拠確認担当と公開承認担当が確認したか

AIが作った文に根拠のない情報が含まれていた場合は、もっともらしい表現へ書き換えるのではなく、その記述を削除するか正本を確認します。AIは整理と下書きを担当し、正しさ、回答範囲、公開可否は人が判断します。

7. 登録前に言い換えと境界ケースをテストする

公開前テストでは、代表質問だけでなく、実際に入力される可能性のある言い換えや情報不足の質問も試します。各入力について、到達したFAQ、回答の正しさ、追加確認の内容、次の行動、有人対応への切り替え結果を記録します。

テスト	見るポイント
代表質問	想定したFAQに到達するか
言い換え・表記揺れ	同じ意図として扱われるか
短文・情報不足	必要な確認質問を返すか
複合質問	目的を切り分けて案内するか
境界ケース	断定を避けて有人対応へ渡すか
対象外の質問	根拠のない回答を生成しないか

誤答が出たら、質問文を追加する前に原因を切り分けます。根拠資料の不足、質問分類の誤り、異なる条件の混在、長すぎる回答、確認質問の不足、有人切替の欠落のどれに当たるかを判断し、該当箇所だけを修正して再テストします。

8. 回答できない質問を「失敗」にしない

チャットボットが扱わない範囲を先に決めておくと、根拠のない推測を防げます。個別の契約条件、本人確認が必要な手続き、担当者の判断を要する相談では、一般案内と個別回答の境界を明示します。

回答できない場合は、確認が必要であること、担当者が確認するために必要な情報、相談先を案内します。引き継ぎ時には、利用者の相談目的、チャットボットが確認した内容、未確認の点、希望する連絡方法を渡せるようにします。

対象外の質問や個別判断を安全に引き継ぐ手順は、AIから有人対応へつなぐ設計で確認できます。FAQごとに切り替え条件と引き継ぐ情報を決めてください。

9. 公開後の未解決ログからFAQを直す

公開後の未解決ログは、回答なし、誤ったFAQへの誘導、条件不足による追加質問、回答後の離脱、有人対応への引き継ぎなどに分類します。分類後に、新規FAQの追加、既存FAQの修正、対象外設定、根拠資料の更新のどれが必要かを判断します。

修正時は、文章を一律に長くしないでください。表現不足なら言い換えを追加し、条件の混在なら回答を分割します。根拠が古ければ資料を更新し、個別判断が必要なら有人対応への案内を追加します。

変更後は、変更日、理由、確認者、再テスト結果を記録します。更新作業の決め方は、ナレッジの更新頻度と反映方法も参考にし、情報の変更を把握する担当とFAQを直す担当を明確にしてください。

FAQ作成の最終チェックリスト

1. 過去の問い合わせログと正本となる資料を集めた
2. 個人情報や公開対象外の情報を除いた
3. 利用者の言葉を残し、似た質問と異なる意図を切り分けた
4. 回答に結論、条件、根拠、必要な行動を含めた
5. 確認日、次回確認日、更新担当を記録した
6. AIの下書きを根拠確認担当と公開承認担当が確認した
7. 言い換え、短文、情報不足、複合質問、境界ケースを試した
8. 回答不可条件と有人対応への切り替え方法を用意した
9. 公開後の未解決ログを確認して改訂する担当を決めた

チェック項目を満たしたら、FAQの登録方法と公開後の運用を確認します。ツール設定を含む導入全体の流れは、FAQチャットボットの導入ガイドで確認できます。

よくある質問

続いて、公開後の改訂と管理に必要な記録項目を確認します。