有人対応へ切り替えた会話は、そこで終わりにせず次のFAQの材料にできる。FAQを何もない状態から作り、育てていく順番を、自社のログ設計をもとに整理する。
この記事で分かること
- FAQを何から手をつけて増やしていくか
- ログをどう分けて残すと、後から資産として使えるか
- ログ保存の設計で外してはいけない原則
この記事で分からないこと(正直に書く)
- 何件のログが溜まればFAQとして十分な網羅になるか
- 自動生成したFAQと人手で書いたFAQの、どちらを優先して育てるべきか
材料は「人が答えた質問」と「答えられなかった質問」
FAQを何もない状態から作るとき、最初の材料になるのは大きく2種類ある。一つは有人対応で人間が実際に答えたQ&Aペアで、そのまま事前生成FAQの材料になる。もう一つは、ボットが答えられずに未マッチ・フォールバックになった質問で、これはFAQのカバレッジに穴が空いている場所を知る唯一の観測手段になる(出所: 自社の運用記録、確認日2026-09-06)。この2つを継続的に拾える形でログを残しておくことが、整備の出発点になる。
ログは索引と全文を分けて残す
会話ログは要約や切り詰めをせず全件・全文で残す方針にしている。ただし全部を1か所にまとめると保存先が肥大化し、逆に全部を検索に不向きな場所に置くと経路の分析ができなくなるため、索引と全文を分けて保存している。索引側にはセッションID・発話者・経路・一致したFAQのID・スコア・カテゴリ・有人切り替えの有無などを持たせ、全文側は日付ごとにまとめて後からまとめて取り出せる形にしている(出所: 自社の運用記録、確認日2026-09-06)。
ログの書き込み失敗が応答を壊してはいけない
ログの保存で外してはいけない設計判断が一つある。ログの書き込みに失敗しても、利用者への応答自体は止めてはいけないという原則で、書き込みは応答の経路の外に出し、失敗した場合は「本文が保存できなかった」ことを索引側の記録に残して、欠損を後から分かる状態にしておく(出所: 自社の運用記録、確認日2026-09-06)。ログを取ることが目的化して応答が壊れては本末転倒になる。
整備の順番
以上を踏まえた整備の順番は、まず未マッチ・フォールバックのログから頻度の高い質問を拾い、次に有人対応で実際に答えた内容をFAQ化し、そのFAQを公開前検査の記事にある検査にかけてから配信に載せる、という流れになる。どこまでを事前生成のFAQに固定できるかは、自動化してよい範囲の記事にある有界ドメインの考え方と同じ基準で決まる。
ログを資産化せず、都度の自然文生成に頼り続けた結果として誤答が積み重なった事例は、Air Canadaのチャットボット訴訟の記事を参照してほしい。
自社のFAQ整備・ログ設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. FAQを作り始めるとき最初の材料は何か
有人対応で人間が実際に答えたQ&Aペアと、ボットが答えられず未マッチ・フォールバックになった質問の2つである。
Q2. 会話ログはどう保存するのか
要約・切り詰めをせず全件・全文で残す。索引と全文を分けて保存し、索引側にはセッションIDや一致したFAQのIDなどを、全文側は日付ごとにまとめて持たせている。
Q3. ログの保存で最も外してはいけない設計は何か
ログの書き込みに失敗しても利用者への応答は止めないことである。失敗時は索引側に記録を残し、欠損を後から分かる状態にしておく。
Q4. FAQを配信に載せる前に何をするか
公開前検査にかけて、事実として裏付けのある内容かを確認してから配信に載せる。