- コラム
FAQチャットボットを作ろうとしたとき、「質問を何件用意すればいいのか」「回答はどこまで詳しく書くのか」で手が止まることがあります。最初から大量のFAQを登録するより、実際の問い合わせから優先度の高い質問を選び、根拠のある回答を作り、小さく試して更新する方が進めやすくなります。
この記事では、問い合わせ対応の担当者が使える質問の集め方、回答文の型、公開前の確認、公開後の見直し方を順に整理します。生成AI型とシナリオ型で登録方法は異なりますが、回答の根拠を整える必要性は共通です。
まず、誰のどの問い合わせを減らす・早く解決するのかを一つ決めます。顧客向けの配送案内、社内向けの申請手順、製品の導入前相談では、必要な質問も参照する資料も異なります。対象を広げすぎると、回答の正しさを確認する担当者も曖昧になります。
最初の対象範囲は「頻繁に聞かれ、回答の根拠が確認でき、案内内容が比較的安定しているもの」から選びましょう。個別契約の判断、本人確認が必要な内容、日々条件が変わる案内は、初期の自動回答に無理に含めず、担当窓口へつなぐ設計にします。
例えばECサイトなら、配送状況の確認方法と返品可能な条件を別の質問として扱います。「返品できますか」だけでは注文日や商品状態によって答えが変わるため、回答の対象条件を先に決める必要があります。導入前に情報源や担当を整理する方法は、生成AIチャットボット導入前に確認したい3つの準備も参照してください。
想像でFAQを並べるのではなく、実際に届いた質問と、正しい回答が載っている資料を突き合わせます。メール、電話メモ、チャット履歴、営業・サポート担当者への聞き取りから候補を集めます。利用者の表現を残すと、社内だけで通じる言葉に偏りにくくなります。
候補を記録するときは、最低限「質問の原文」「同じ意図の言い換え」「回答の根拠となるページ・文書」「確認担当」「最終確認日」を一行にまとめます。個人情報や個別の契約内容は台帳にそのまま転記せず、社内の取り扱いルールに従って匿名化してください。
似た質問は意図ごとにまとめます。例えば「送料はいくら」「配送料は無料ですか」は同じ料金確認でも、無料になる条件を知りたい質問は条件を含めて答える必要があります。一方、「荷物が届かない」は配送状況の確認や個別調査が必要かもしれません。表面上の単語だけで無理に一つに統合しないことが大切です。問い合わせから潜在的な困りごとを見つける視点は問い合わせ分析の記事で解説しています。
質問数の目標を先に決めず、繰り返し届く質問で、回答の根拠と担当者を確認できるものから始めます。問い合わせ件数が多くても、回答が注文内容や契約内容で変わるものは、定型案内と個別確認の境界を分けてください。
優先度を付ける際は、直近の問い合わせでの出現回数、担当者が回答に費やす手間、回答が変わる頻度、誤案内した場合の影響を並べて見ます。検索ボリュームや業界平均だけで、自社で必要なFAQは決まりません。質問が少なくても、重要な手続きで利用者が迷っているなら対象になることがあります。
初回は選んだ質問について、根拠資料に矛盾や古い版がないか確認します。社内マニュアルとWebサイトの表記が違う場合は、チャットボットに入れる前にどちらを正とするか決めましょう。根拠が決まらない質問は「要確認」とし、公開候補に混ぜない方が安全です。
短い一問一答だけで済ませず、利用者が自分に当てはまるか判断できる情報を入れます。基本の型は「結論→対象条件→例外→次に行うこと」です。ただし、条件が多い場合は一つの長文に詰め込まず、詳細ページや担当窓口へ案内します。
例えば「返品できますか」に対して「返品できます」だけでは誤解が残ります。「対象商品は到着後の所定期間内であれば申請できます。開封済み・特注品などは対象外の場合があります。詳しい条件を返品ポリシーで確認し、注文番号を用意して申請してください」のように、実際の自社規定に合わせて条件と行動を記載します。ここに挙げた文面は形式の例であり、返品条件そのものを示すものではありません。
回答の末尾には、根拠ページへのリンクや担当窓口を置きます。日時や料金など変わりやすい事項は、更新責任者と確認日も台帳に残します。生成AI型の場合も、根拠文書が古ければ回答の品質に影響するため、元資料の整備が欠かせません。
登録した質問文をそのまま試すだけでは不十分です。利用者の言い換え、答えてはいけない質問、個別判断が必要な質問まで確認します。テストは実際に想定する利用者の言葉で行い、答えと参照先が合っているかを担当者が見ます。
誤案内があれば、質問の表現、根拠資料、回答の条件、案内先のどこに原因があるかを記録します。テスト結果には質問文、期待する回答、実際の回答、修正内容、再テスト日を残すと、公開可否を判断しやすくなります。
公開が完成ではありません。答えられなかった質問と、答えたのに解決につながらなかった質問を分けて見直します。質問ログから未回答、同じ質問の再入力、有人対応への移行、古い案内の指摘などを拾い、原因を「質問不足」「根拠不足」「回答文の説明不足」「個別対応が必要」に分類します。
その上で、台帳の担当者が根拠を確認し、回答を修正して再テストします。問い合わせの傾向が変わったからといって、すべてをFAQに追加する必要はありません。情報がまだ確定していない内容は、無理に自動回答せず、適切な窓口へ案内します。
運用頻度は問い合わせ量や更新の多さに合わせて決めます。重要な誤案内は見つけ次第対応し、定期的には未解決テーマ、参照資料の更新、利用者からの反応をまとめて確認しましょう。数値で効果を見る場合は、利用数だけではなく、何を解決とみなすかを先に定義します。指標の考え方はチャットボットの効果測定の記事を参照してください。
FAQは何件から始めればよいですか？
一律の必要件数はありません。実際の問い合わせで繰り返され、根拠と確認担当が明確な質問から始めます。登録件数より、正しい回答と更新可能な運用を優先してください。
資料を入れるだけでFAQは完成しますか？
いいえ。資料の最新版・矛盾・対象範囲を確認し、利用者が尋ねる言葉で試す必要があります。生成AI型でも公開前テストと公開後の見直しは必要です。
答えられない質問はどう扱えばよいですか？
推測で答えず、分かる範囲を明示し、必要なら担当窓口へつなぎます。個人情報や個別契約の判断を伴う質問は、最初から有人対応の境界を決めておきましょう。
FAQチャットボットは、質問を大量に登録すれば完成するものではありません。目的を絞り、実際の問い合わせから候補を選び、根拠・条件・例外を確認した回答を作ります。公開前に言い換えや対象外の質問を試し、公開後はログを見て更新することで、利用者に役立つ案内へ近づけられます。
質問の集め方や回答の書き方を整えることは大切ですが、FAQを一問ずつ手作業で作るところから始める必要はありません。chabee®なら、WebサイトのURLを登録し、サイト内の公開情報を回答に活用するところから始められるため、導入のハードルを抑えられます。運用後も質問・回答の履歴を確認し、不十分な回答を修正したり、足りない情報を補って再学習したりできます。URLを登録して終わりではなく、回答ログを見ながら育てていくことが大切です。
Webサイトや社内文書を活用する生成AIチャットボットを検討するときは、以下からchabee®の機能をご確認ください。