生成AI / RAGによる顧客サポートDX

問い合わせ対応の分岐と改善の流れ

＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

＋の付いた項目を選ぶと、その処理で何を確認しているかを表示します。

なぜ必要なのか、次の処理へどうつながるのかを、選んだ項目ごとに確認できます。

問い合わせ内容から、製品・機種・OS・エラーなど、回答に必要な条件を確認します。

条件を特定できないままAIへ渡すと、誤った情報を検索・回答する可能性があります。

必要な条件が揃わない場合は、AIだけで回答せず、人へ引き継ぎます。

マニュアルやFAQなどの知識について、対象の製品・版、公開可否、現在も有効な情報かを確認します。

検索できる文書でも、古い仕様や調査中の情報をそのまま顧客への回答に使うことはできません。

確認した条件を知識とともに管理し、次の検索で回答に使える情報を選べるようにします。

機種・OS・エラーなどの条件を使い、公開可能な知識から回答の根拠を検索します。

文章が似ていても、対象の製品や版が違う情報を使うと、誤った案内につながります。

条件に合う情報を生成AIへ渡し、回答後も参照した文書や箇所を確認できるようにします。

生成AIは、検索で取得した根拠の範囲で、顧客の質問に対する回答案を作ります。

読みやすい文章が出ても、正しさが保証されたわけではなく、根拠にない内容を補っていないか確認が必要です。

回答案をそのまま送らず、対象や公開可否などの条件を確認する次の判定へ渡します。

回答の根拠、対象の製品・版、公開可否、案内が業務へ与える影響をシステムで確認します。

AI自身の自信だけでは決めません。

条件を満たした回答は顧客へ届け、不足や矛盾がある場合、または専門判断が必要な場合は人へ引き継ぎます。

根拠が足りない場合や専門判断が必要な場合は、人が質問・条件・参照情報・AIが回答を止めた理由を確認します。

回答案だけを受け取ると判断の経緯が分からないため、元の質問や文書までたどれる形で引き継ぎます。

人が必要な調査と判断を行い、最終的な業務責任を持って顧客への案内につなげます。

回答条件を満たしたAIの回答、または人が判断した案内を顧客へ届けます。

案内を生成することと業務を確定することは分け、権限や取引などの確定処理は既存システムが担います。

回答の利用結果や有人対応の結果は、知識・検索条件・評価を見直すための情報として次の改善へつなげます。

利用結果、誤回答、有人対応の結果から、どこで回答や引き継ぎがうまくいかなかったかを確認します。

知識の不足だけを原因とせず、検索条件、回答の生成、判定や人への引き継ぎのどこを見直すべきか分けて考えます。

知識・検索条件・評価方法を改善した後は再評価し、次回の検索・回答へ反映します。

このBookについて

企画部門から、プリンタ事業縮小への対応、担当者8名から6名への縮小、残業抑制が与えられています。業務目標は、問い合わせ対応工数を月400時間から300時間以下へ減らし、定型問い合わせ750件のうち600件以上を顧客自身で完結させることです。これらを著者自身が企画した事例ではありません。

本書は、その業務要求を受け、追加確認、回答根拠、有人引継ぎ、品質評価、Knowledge運用のシステム要件と、生成AI・ベクトル検索・RAG・HITLの方式を設計する事例です。企画からシステム要件への境界に沿って、目標と実現方式を区別します。

顧客サポートで生成AIやRAGを使うとき、技術を導入するだけでは業務は変わりません。誰にどのような価値を届けるのか、どの問い合わせを自己解決へ移すのか、どこでAIを止めるのか、人間へ何を引き継ぐのかまで設計する必要があります。

本書は、B2B機器・ITサービス企業の顧客サポートを対象に、業務課題から回答・有人対応・継続改善までを設計するケーススタディです。

企画で与えられた業務要求・業務目標
  ↓
システム要件
  ↓
業務プロセスの再設計
  ↓
AI・人間・既存システムの責任分担
  ↓
PoC / Knowledge / UX / HITL
  ↓
評価・運用・継続改善

設計案、PoCの評価条件、効果試算は、実測した導入成果と区別して扱います。公開実績として確認できない数値は成果として断定しません。

PCでは右側のBook目次、モバイルでは折りたたみ式の目次から任意の章へ移動できます。順番に読む場合は、各章末の前後ナビゲーションを利用してください。