FAQをAIチャットボット用のナレッジに整える方法

FAQをAIチャットボットへ入れるとき、質問と回答の一覧をそのまま読み込ませるだけでは、条件違い・古い回答・似たFAQの競合が起きやすくなります。チャットボット用Knowledgeでは、回答本文に加えて適用条件、例外、Source、更新日、Owner、Statusを持たせるのが基本です。

この記事では、FAQを1論点ずつ分割し、Schema化し、Retrieval Testと回答QAまで行う流れを整理します。最終的には「どの質問に、どの条件のFAQを返し、分からないときはどう止めるか」を設計できる状態を目指します。

まずFAQを1論点1回答へ分ける

1つのFAQに料金、解約、返金、支払方法、例外条件を詰め込むと、検索時に一部だけ一致して誤った回答を返す可能性があります。

たとえば「解約と返金について」という長いFAQを、解約期限、解約方法、返金条件、返金対象外へ分けます。関連は保ちつつ、1件のKnowledgeが何に答えるかを明確にします。

FAQ Knowledge Schemaを作る

最低限、次のようなFieldを持たせます。

表は横にスクロールできます

Field	内容
faq_id	安定した識別子
canonical_question	代表質問
variants	言い換え
answer	回答本文
conditions	適用条件
exceptions	例外
source	根拠URL / 文書
updated_at	確認日
owner	管理責任者
status	ACTIVE / REVIEW / RETIRED
escalation	人へ回す条件

質問文と回答だけではなく、条件・例外・Sourceを検索結果と一緒に扱える形にするのがポイントです。

canonical questionと言い換えを分ける

「解約したい」「退会したい」「契約を止めたい」は同じIntentかもしれません。これらをvariantsとして1つのcanonical questionへ寄せます。

一方、「無料トライアルをやめたい」と「有料契約を解約したい」で条件が違うなら別FAQにします。単語が似ていることではなく、同じ回答で安全に答えられるかで統合を判断します。

条件を本文の奥に埋めない

FAQで危険なのは、「できます」と答えた後に小さく例外が書かれているケースです。チャットボットが前半だけ拾うと誤回答になります。

Plan、契約状態、地域、申請期限、ユーザー権限など、回答を変える条件はconditions Fieldへ出します。例外もexceptionsへ分け、検索・回答時に一緒に参照できるようにします。

架空例：返金FAQを構造化する

説明用の架空例です。

faq_id: billing_refund_001

canonical_question: 返金できますか？

variants: キャンセルしたら返金される？ / 支払後に取り消せる？

answer: 条件を満たす場合のみ返金申請が可能です。

conditions: 購入から7日以内、未使用

exceptions: 一部商品・法人契約は対象外

source: 返金ポリシー

updated_at: 2026-10-01

status: ACTIVE

escalation: 注文状態が不明、例外契約、期限境界

この形なら、AIがanswerだけを拾って「返金できます」と断定するのを防ぎやすくなります。

Sourceとupdated_atを必ず持つ

FAQは時間とともに変わります。料金、返金、契約、機能、サポート範囲などは特に更新されやすいため、Sourceと確認日を残します。

SourceがないFAQは、誰の判断で作られた回答か分かりません。旧FAQと新FAQが競合したときも、更新日とOwnerがあれば整理しやすくなります。

Statusで古いFAQを検索対象から外す

削除だけでなく、ACTIVE / REVIEW / RETIREDのようなStatusを持たせると運用しやすくなります。

REVIEWは内容確認中で自動回答に使わない、RETIREDは履歴として残すが検索対象外、といったRuleを決めます。古いFAQを物理削除するだけより、変更履歴を追いやすくなります。

Retrieval Test用の質問セットを作る

Knowledgeを整えたら、想定質問だけでなく境界質問もテストします。

例：

• 正常：返金できますか？

• 言い換え：支払ったあと取り消せますか？

• 条件付き：8日前に購入したけど返金できる？

• 曖昧：お金を戻してほしい

• 別Intent：請求書を再発行したい

• Unknown：法人特約の返金条件は？

正しいFAQが上位に出るか、誤ったFAQが混ざらないか、Unknownで無理に答えないかを確認します。

Retrieval評価は「Top1が当たった」だけで終わらせない

複数の近いFAQがある場合は、Top候補の順位、条件一致、Source整合も見ます。

返金FAQが上位でも、無料トライアル用と法人契約用が混ざるならKnowledge設計が弱い状態です。MetadataやFAQ分割、Question表現を見直します。

回答生成はRetrieved FAQの範囲へ制約する

検索で正しいFAQを取れても、生成段階で一般知識を足すとFactが変わる可能性があります。

Promptには「取得したKnowledgeの範囲で答える」「条件・例外を省略しない」「不足情報がある場合は追加質問」「Sourceがない場合は断定しない」といったRuleを入れます。

追加質問で条件を確定する

ユーザー質問だけでは条件が足りないFAQがあります。

たとえば「解約できますか？」だけでは、Plan、契約期間、更新日が必要かもしれません。AIが勝手に条件を仮定するのではなく、「どのPlanですか？」のように必要な追加質問を返す設計にします。

回答Templateを決める

回答の形式をそろえると、条件落ちを見つけやすくなります。たとえば「結論 → 適用条件 → 例外 → 次Action → Source」の順です。

短いFAQでは全部を長く書く必要はありませんが、条件がある回答で結論だけ返さないようにします。Sourceをユーザーへ見せるかは製品方針によりますが、内部ではどのKnowledgeを根拠にしたか追える状態が必要です。

回答しない条件を決める

チャットボットは何でも答える必要はありません。

契約例外、個別見積、本人確認が必要な手続き、法的判断、Knowledgeにない事案などはEscalation対象にします。「分からないので人へ回す」が正しい挙動になるケースを先に定義します。

重複FAQを検出する

同じIntentへ異なる回答があると、Retrieval結果が不安定になります。

AIにfaq_id、canonical_question、conditions、answerを渡し、Same Answer / Conditional Difference / Conflictへ分類させます。Conflictは自動Mergeせず、Ownerが正本を決めます。

回答QAはFact・条件・Sourceを見る

テスト回答ごとに、Answer Correct、Condition Correct、Exception Included、Source Correct、Escalation Correctを確認します。

文章が自然でも、条件が1つ抜けていれば不合格です。チャットボットでは流暢さより、適用条件を守ることを優先します。

回答ログからKnowledgeの弱点を見つける

運用後は、回答できなかった質問、誤ったFAQを取った質問、ユーザーが追加質問したケースを記録します。

これをFAQ追加の候補にします。ただし、1回聞かれたから即追加するのではなく、既存FAQの言い換え不足なのか、新しいReader Questionなのか、例外条件なのかを分類します。Retrieval FailureとKnowledge Gapを分けることで、FAQを無制限に増やすのを防げます。

更新フローを作る

FAQのSourceが変わったら、Knowledgeも更新します。Source更新→FAQ差分確認→Status REVIEW→Test→ACTIVEという流れにすると、未検証の新FAQを即時公開するのを防げます。

更新後は代表質問と境界質問を再実行します。FAQ数が増えるほど、新規FAQが既存FAQのRetrievalを壊すことがあります。

小規模なら文書形式から始めてもよい

FAQが10〜20件程度で条件も単純なら、最初から複雑なDBを作る必要はありません。見出し、回答、条件、Sourceを明確にした文書でも始められます。

FAQ数、部門数、更新頻度、条件分岐が増えたらSchema化し、Owner・Status・Metadataを持つ運用へ移します。

実装前Checklist

• 1FAQ1論点になっている

• canonical questionとvariantsを分けた

• conditions / exceptionsがある

• Source / updated_atがある

• ACTIVE以外を検索対象から外せる

• 境界質問をテストした

• Unknownで無理に答えない

• Escalation条件がある

• 重複FAQを確認した

• 更新後に再Testする

AIものさしの判断

FAQをチャットボットKnowledgeへ整える作業は、文章を短くすることではなく、回答の適用範囲を構造化することです。Question / Answerだけでなく、Condition / Exception / Source / Statusまで持たせると、Retrievalと回答の誤りを切り分けやすくなります。

まず既存FAQを20件程度でPilotし、1論点へ分割、Schema化、Retrieval Testを行ってください。誤回答が出たらPromptだけを直すのではなく、FAQ分割・条件・Metadata・Sourceのどこが原因かを確認する。この順で整えると、Knowledgeが増えても運用しやすくなります。