カスタマーサポートでLLMナレッジベースを整える方法｜FAQ・マニュアル・応対情報をどう整理するか

記事概要：カスタマーサポート向けLLMナレッジベースの作り方を解説。FAQやマニュアルの整理、情報源の優先順位、古い情報の更新、担当者の決め方まで紹介します。

LLMナレッジベースをカスタマーサポートに導入するとき、モデルの選定より先にぶつかるのが「何を知識として登録するのか」という問題です。

例えば、EC企業の返品問い合わせをAIで対応したいとしても、社内には公式FAQ、返品規約、オペレーター向けマニュアル、過去の研修資料、商品別の注意事項など、複数の情報源があります。しかも、同じ「返品」というテーマでも、資料によって表現や更新時期が違うことがあります。

この状態で資料をそのまま登録すると、「知識が増えた」だけで、AIが使いやすい知識体系になったとは限りません。重要なのは、どの情報を使うのか、どれを優先するのか、古い情報をどう扱うのか、誰が更新するのかを最初に決めることです。

LLMナレッジベースとは

LLMナレッジベースを実務で考えるとき、まず見るべきなのは「どんな資料をAIに渡すか」です。

FAQだけでなく、商品情報、サービス条件、業務マニュアル、問い合わせ対応ルールなど、日常のカスタマーサポートで使われる情報を整理しておく必要があります。

例えば顧客が「セールで買った商品は返品できますか」と質問した場合、AIが必要とするのは「返品FAQ」だけではありません。通常の返品条件、セール商品の例外条件、返品期限など、複数の情報を組み合わせる必要があります。

Udeskの公式情報でも、LLMナレッジベースはFAQ、製品情報、マニュアル、サービスルールなどの企業知識を統合し、RAGを通じて関連情報を検索してAIの回答に活用する仕組みとして紹介されています。

何を登録するべきか

最初から社内資料をすべて登録するのではなく、実際に問い合わせ対応で使う情報から整理するほうが効率的です。

例えば、あるEC企業が「配送」「返品」「返金」の問い合わせをAIで対応したい場合、まず直近の問い合わせを確認し、回答に実際に使われている情報を洗い出します。

配送なら配送方法、配送予定、再配達など。返品なら返品期限、商品条件、送料負担、対象外商品など。返金なら返金条件、返金方法、処理期間、例外条件などです。

ここで役立つのが「資料単位」ではなく「問い合わせ単位」での整理です。

例えば「返品規約」という100ページの文書をそのまま登録するより、

「通常商品の返品条件」
「セール商品の返品条件」
「返品送料の負担」
「不良品の場合の対応」

のように、実際の質問に対応する単位へ整理したほうが、後の検索や回答に使いやすくなります。

盤点の段階では、各情報について「誰が使うか」「どの問い合わせに使うか」「いつ有効か」も合わせて記録しておくと、後の更新がしやすくなります。

情報源の優先順位を決める

実務で一番困るのは、同じ質問に複数の答えが存在するケースです。

例えば、WebのFAQでは「返品は30日以内」、社内マニュアルでは「14日以内」、昨年の研修資料では「7日以内」と書かれているとします。このままではAIがどれを参照すべきか判断しにくくなります。

そこで、先に情報源の優先順位を決めます。

例えば、

現在有効な公式規約
↓
最新の商品・サービス情報
↓
承認済みの業務マニュアル
↓
過去の研修資料・個人メモ

というように、企業内で「最終的にどの情報を正とするか」を決めておきます。

さらに、各知識に更新日や適用期間を付けておけば、ルール変更時に古い情報を見つけやすくなります。

Udeskの公式FAQ管理資料でも、FAQのバージョンや更新フロー、担当者を明確にし、常に有効な情報を維持することの重要性が説明されています。

古い情報・重複を整理する

ナレッジベースを作る前後で、意外に時間がかかるのが「何を削るか」です。

例えば価格改定があったのに旧価格の資料が残っている、同じ返品ルールを営業・客服・法務がそれぞれ別の文書で管理している、といった状態は珍しくありません。

この場合、すべてを残すのではなく、

「現行版」
「旧版・利用停止」
「重複」
「確認待ち」

のように状態を整理します。

特に重要なのは、古い資料を単純に「削除したつもり」にしないことです。どの資料が現行なのか、いつから旧版になったのかを明確にしておけば、担当者が誤って古い情報を使うリスクを下げられます。

また、一つの文書に複数の業務が混在している場合は、実際に使う単位へ分割したほうが運用しやすくなります。

更新責任者とレビューを決める

ナレッジベースで最も起きやすい失敗は、「最初はきれいだったが、半年後には古くなっている」ことです。

例えば製品仕様は商品部門、返品ルールはCS部門、契約条件は法務が管理しているとします。責任者が決まっていなければ、情報が変わってもナレッジベースが更新されない可能性があります。

そのため、知識ごとにOwnerを決めます。

例えば「返品ルールはCS責任者」「製品仕様は商品担当」「契約条件は法務担当」というように、誰が最終確認するのかを明確にします。

さらに、定期レビューだけに頼らず、実際の問い合わせから更新候補を拾う仕組みも必要です。

同じ質問が急に増えた、オペレーターから「答えが見つからない」という報告が増えた、新しい例外ケースが頻発している。このような変化自体が、ナレッジ更新のサインになります。

Udeskが公開している大手ガス企業の事例では、LLMナレッジベースを活用して部門をまたいだナレッジ共有と運用を進めています。公式情報によると、ナレッジの更新時間を24時間以内に短縮し、カスタマーサービスロボットのインターセプト率を40％から80％に向上させ、重複したナレッジ作成作業を40％削減しました。

この事例で参考になるのは、ナレッジを「保存する」ことよりも、誰が更新し、どう再利用するかまで運用に組み込んでいることです。

FAQ・オペレーター支援とつなぐ

ナレッジベースを作ったら、その後どこで使うのかまで考えます。

例えば「返品期限」という知識は、顧客向けのFAQやAIチャットボットに使うこともできます。一方、「例外的な返品を受け付ける条件」や社内処理手順は、オペレーター向けに限定したほうがよい場合があります。

同じ知識をすべての人に同じ形で見せるのではなく、利用者と用途に応じて出し分けることが重要です。

例えば、

顧客 → 通常の返品条件
オペレーター → 通常条件＋例外対応
管理者 → 更新履歴＋レビュー状況

というように分ければ、ナレッジの利用範囲を整理できます。

Udeskの公式情報でも、LLMナレッジベースをAIチャットボットやオペレーター支援に接続し、同じ企業知識を異なるサービスシーンで活用する方法が案内されています。

つまり、良いナレッジベースとは資料の数が多いものではありません。顧客やオペレーターが必要な情報を、必要な場面で使えるものです。

まとめ

LLMナレッジベースを整える際は、FAQやマニュアルをそのまま登録するのではなく、実際の問い合わせで使われる情報を中心に整理することが重要です。情報源の優先順位を決め、古い情報や重複を整理し、知識ごとに更新責任者を設定することで、AIが参照する情報を継続的に管理しやすくなります。

さらに、問い合わせの増加やオペレーターからのフィードバックを更新のきっかけとして、ナレッジをFAQやAIチャットボット、オペレーター支援へつなげれば、知識を一度作って終わりにせず、実際の顧客対応の中で継続的に活用できます。

UdeskのLLMナレッジベースは、企業内のFAQ、製品情報、マニュアル、業務ルールなどを一元管理し、RAGによる検索を通じてAIやオペレーターの対応に活用できるナレッジ基盤を提供しています。

FAQ

Q. 最初に登録するべき情報は？
問い合わせ頻度が高く、回答に直接使われるFAQや業務ルールから始めます。

Q. 古い情報はどう管理しますか？
現行版と旧版を明確に分け、適用期間や更新日を管理します。

Q. ナレッジの更新担当者は必要ですか？
必要です。各分野のOwnerを決め、更新とレビューの責任を明確にします。

》》Udesk ナレッジベースの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください

本記事はUdeskのオリジナルであり、転載する際は出典を明記してください：https://www.udesk.jp/blog/news/guide/6574/