チャットボットの会話ログ分析方法：改善につなげる分類と確認項目

チャットボットの会話ログ分析では、会話件数や頻出語を集計するだけでは不十分です。利用者が何を尋ね、どの情報を根拠に回答し、どこで未解決や離脱が生じたのかを確認します。そのうえで、FAQ、ナレッジ、会話導線、有人対応のうち、どこを修正するかを決める必要があります。 分析の基本となるのは、質問意図、回答根拠、解決状況、離脱、有人引き継ぎの五項目です。五項目で分類し、未解決原因の切り分け、修正の優先順位、再確認までの流れを整理します。 ## チャットボットの会話ログ分析で確認するべきこと チャットボットの会話ログは、次の五項目で確認します。 1. 質問意図：利用者が確認したかった内容 2. 回答根拠：回答時に参照した情報と、その情報が適切かどうか 3. 解決状況：解決、未解決、要確認のいずれか 4. 離脱：利用者が会話を終えた位置と、その直前の応答 5. 有人引き継ぎ：担当者への切り替えが必要だったか、実際に行われたか この五項目を記録すると、会話件数だけでは分からない問題を切り分けられます。同じ未解決ログでも、回答に必要な情報が登録されていない場合と、情報はあるものの質問意図を判別できなかった場合とでは、修正する箇所が異なります。 会話ログ分析の目的は、チャットボット全体を一律に評価することではありません。個々の会話で問題が生じた理由を特定し、次に行う修正を決めることです。分析表には分類結果だけでなく、修正対象、担当者、期限、再確認結果まで記録します。 ## 分析を始める前に対象範囲と取り扱いルールを決める ログを読み始める前に、対象期間、対象チャネル、抽出条件、情報の取り扱い、担当者を決めます。条件が曖昧なままでは、担当者によって確認対象が変わり、分析結果を比較できません。 対象期間は、通常時と繁忙時を区別して設定します。繁忙日だけを対象にすると、一時的な問い合わせの増加を通常時の課題と混同するおそれがあります。キャンペーンや障害など、問い合わせ内容に影響する事情があった場合は、その内容と期間も記録します。 対象チャネルには、Webサイト、アプリ、会員画面など、チャットボットが設置されている場所を記載します。同じ質問でも、利用者が閲覧しているページによって求める回答が異なるためです。 次に、全件を確認するのか、未解決候補、離脱、有人引き継ぎなどの条件で抽出するのかを決めます。一部のログだけを分析する場合は、次回も同じ条件で抽出できるよう、対象条件を具体的に残してください。 会話ログに氏名、連絡先、注文情報、相談内容などが含まれる場合は、閲覧できる担当者と利用目的を限定します。分析表へ転記する情報も必要最小限にとどめます。保存期間、管理方法、閲覧権限については、自社規程と利用サービスの契約条件を確認したうえで決定します。 あわせて、ログを分類する担当者と、修正の要否を判断する担当者を決めます。分類担当者だけで回答内容の正否を判断できない場合は、商品、契約、配送などを所管する担当者へ確認する手順も用意します。 ## 会話ログを五つの確認項目で分類する 分析表では、一つの会話を一行で記録します。最低限必要な列は、ログ識別子、質問意図、回答根拠、解決状況、離脱位置、有人引き継ぎです。 営業時間を尋ねた会話は、次のように分類できます。 |質問意図|回答根拠|解決状況|離脱位置|有人引き継ぎ| |---|---|---|---|---| |営業時間の確認|登録済みの店舗情報|解決候補|回答後|なし| 登録済みの店舗情報を根拠に営業時間を回答し、その後に再質問や有人対応の要求がなければ「解決候補」とします。ただし、会話が終了したという事実だけで、問題が解決したとは断定できません。 返品条件を尋ねた会話は、次のように記録できます。 |質問意図|回答根拠|解決状況|離脱位置|有人引き継ぎ| |---|---|---|---|---| |返品条件の確認|根拠不足|未解決・要確認|回答直後|なし| この例では、返品できる期間や対象条件を裏付ける情報が不足しています。質問文や選択肢を直す前に、回答根拠となるナレッジの有無と内容を確認する必要があります。 質問意図の分類名や担当範囲が担当者ごとに異なると、同じログでも判定が分かれます。分類ルールをそろえる際は、問い合わせ分類と担当範囲の決め方も確認してください。分析後の対応先まで含めて分類を設計できます。 ## 未解決になった理由を原因別に切り分ける 未解決ログを見つけたら、原因を次の五つに切り分けます。 - 情報不足：回答に必要なFAQやナレッジが登録されていない - 意図判別の不足：情報はあるが、質問の意味を適切に区別できない - 回答範囲外：個別判断や本人確認が必要で、チャットボットだけでは回答できない - 導線の問題：選択肢、質問の順番、案内先が分かりにくい - 有人切替の不足：担当者へ渡すべき状況で切り替えられていない 同じ質問でも、原因によって修正箇所は変わります。たとえば「解約したい」という質問には、サービス全体の解約、オプションの停止、申込直後の取消しなど、複数の意味が含まれる場合があります。 必要な手続き情報が登録されていなければ、ナレッジを追加または更新します。情報はあるものの意味を区別できていない場合は、「サービス全体の解約」「オプションの停止」などの選択肢を提示し、手続き別の導線へ分けます。 一方、契約状態を確認しなければ回答できない相談は、一般的なFAQを増やしても解決しません。本人確認を含む個別対応が必要かを判断し、該当する場合は有人対応へ切り替える条件を整えます。 複数の原因が重なっている場合は、主原因と副原因を分けて記録します。たとえば、回答根拠となる情報が不足し、必要な有人切替も行われていなければ、主原因を「情報不足」、副原因を「有人切替の不足」とします。修正候補が複数ある場合は、それぞれの担当者と対応状況を分けて管理してください。 ## 離脱ログは発生位置と直前の応答をセットで確認する 離脱は、必ずしも対応の失敗を意味しません。回答を読んで目的を達成した利用者と、回答を理解できずに中断した利用者が、同じ終了ログとして残る場合があるためです。 離脱ログでは、次の項目をまとめて確認します。 - 離脱した位置 - 離脱直前の質問 - チャットボットが提示した回答 - 提示した選択肢の数と内容 - 同じ内容の再質問があったか - 有人対応を求める表現があったか - 完了を示す操作や後続行動を確認できるか 営業時間を回答した直後に会話が終了し、再質問もなければ「解決候補」と分類できます。返品条件に曖昧な回答を示した直後に終了した場合は、「未解決・根拠不足・要確認」と記録します。このように、離脱位置だけでなく、その直前に何を案内したかを合わせて判定します。 選択肢を提示した直後に離脱している場合は、利用者が該当する項目を見つけられなかった可能性があります。選択肢に社内用語を使っていないか、必要な手続きが含まれているか、選択するために必要な説明が先に示されているかを確認します。 ログだけでは完了を判断できない場合、解決または未解決へ無理に振り分ける必要はありません。「要確認」という区分を設け、確認できていない理由と、追加で必要な判断材料を記録します。 ## 有人引き継ぎの成否から担当範囲を見直す 有人引き継ぎについては、発生件数だけでなく、切り替えの必要性とタイミングを確認します。分析時には、次の三つに分けます。 1. 引き継ぎが必要で、適切に切り替わった相談 2. 引き継ぎが必要だったが、切り替えが遅れた、または行われなかった相談 3. チャットボットで案内できる内容だったが、不要な引き継ぎが発生した相談 個別の契約判断、本人確認、例外処理、苦情などは、自社の運用ルールに基づいて有人対応の要否を決めます。たとえば配送遅延への苦情では、配送FAQを提示しただけで対応済みとは判断できません。注文状況の確認や個別の説明が必要であれば、有人対応へ渡す基準とタイミングを見直します。 引き継ぎが行われたログでは、担当者が対応を始めるために必要な情報が渡っているかも確認します。質問の要約、利用者が選択した項目、すでに案内した内容など、引き継ぐ情報をあらかじめ決めておくと、担当者が同じ質問を最初から聞き直す事態を防ぎやすくなります。 不要な引き継ぎが多い分類では、チャットボットの回答範囲が狭すぎないかを確認します。ただし、引き継ぎ件数を減らすことだけを目的に、個別判断が必要な相談まで自動回答へ含めてはいけません。回答範囲は、案内に必要な根拠を確認できるか、担当者による判断が必要かという基準で決めます。 ## 原因に応じてFAQ・ナレッジ・会話導線を修正する 原因を分類したら、対応する修正対象を決めます。 |原因|主な修正対象|確認する内容| |---|---|---| |情報不足|FAQ・ナレッジ|必要な条件、対象、例外が記載されているか| |回答根拠が曖昧|参照情報|情報の管理元と更新状況を確認できるか| |意図判別の不足|質問表現・選択肢|複数の意味を区別できるか| |導線の問題|案内順・遷移先|必要な説明と手続きが適切な順番か| |回答範囲外|有人切替|切替条件と引き継ぐ情報が明確か| 情報不足が見つかった場合は、元となる規程や商品情報を確認してからFAQやナレッジを更新します。分析表に記載した文章をそのまま回答へ追加すると、適用条件や例外が抜けるおそれがあります。情報の管理元、対象、条件、例外、更新状況を確認してから反映してください。 分析で見つかった情報不足を、根拠の明確な回答情報へ反映する際は、ナレッジ登録の手順を参照できます。登録する文章だけでなく、情報の根拠や管理方法も確認しておくことが重要です。 意図判別に問題がある場合は、利用者が実際に使った表現を確認します。表記の揺れを追加するだけでなく、一つの表現に複数の手続きが含まれていないかを見ます。意味が分かれる場合は、確認質問や選択肢を追加し、それぞれの案内先へ導線を分けます。 回答範囲外の相談には、無理に自動回答を追加しません。有人対応へ切り替える条件、受付時間外の案内、担当者へ引き継ぐ情報を確認します。修正前には、変更対象を所管する担当者へ回答根拠と運用条件を確認してください。 ## 改善の優先順位は影響範囲と対応リスクで決める 修正候補の優先順位は、発生件数だけで決めません。次の判断基準を組み合わせます。 - 利用者が必要な手続きを完了できないか - 誤案内が契約、支払い、返品などの判断に影響するか - 苦情や個別判断など、有人対応の要否を確認すべき内容か - 同じ原因が複数の質問に影響しているか - 正しい回答根拠を確認できるか - 修正後の結果を同じ条件で再確認できるか 件数が多くても、表記の違いだけで回答内容に問題がなければ、緊急修正の対象とは限りません。反対に件数が少なくても、支払い条件や返品可否を誤って案内するおそれがあるログは、優先して確認する必要があります。 優先度を「高・中・低」と付けるだけでは、後から判断の妥当性を確認できません。「誤案内が返品可否の判断に影響するため、回答根拠を先に確認する」など、優先した理由も記録します。根拠を確認できない項目は推測で修正せず、所管担当者の確認対象としてください。 ## 修正内容と再確認結果を一行で記録する 分析を改善作業へつなげるには、分類から再確認までを一つの管理表で追跡します。管理表には、次の項目を設けます。 - 対象ログまたは質問分類 - 解決状況 - 原因 - 修正対象 - 具体的な変更内容 - 担当者 - 確認期限 - 再確認結果 記録例は次のとおりです。 |対象|原因|修正対象|変更内容|担当者|確認期限|再確認結果| |---|---|---|---|---|---|---| |返品条件|回答根拠の不足|ナレッジ|返品可能な条件と例外を所管情報に基づいて更新|CS担当|次回確認日|同種ログを再確認| 「FAQを改善する」だけでは、作業の完了条件が分かりません。どの情報を変更するのか、誰が根拠を確認するのか、いつ同種のログを再確認するのかまで記載します。修正作業の完了と、修正後の確認完了も分けて管理してください。 修正後も問題が残った場合は、以前の結果を消さずに再確認結果を追記します。ナレッジを更新しても未解決が続くのであれば、質問意図の判別や会話導線など、別の原因がないかを改めて切り分けます。 ## 同じ分類基準で定期的に再分析する 修正前後を比較するため、質問意図、回答根拠、解決状況、離脱、有人引き継ぎの分類基準をそろえます。途中で分類名や判定条件を変更した場合は、変更日と変更内容を記録してください。基準を変更する前後の結果を、そのまま同じ条件として比較しないよう注意が必要です。 再分析では、全体の会話件数だけを見て改善したと判断しません。修正対象だった質問について、同じ原因による未解決、離脱、有人引き継ぎが再発していないかを確認します。 たとえば返品条件のナレッジを更新した場合は、返品に関する会話を同じ抽出条件で確認します。回答根拠が明確になったか、条件を尋ねる再質問が続いていないか、必要な有人引き継ぎが行われたかを見ます。 個別ログで特定した原因を継続的な指標へつなげる場合は、チャットボットの効果測定とKPIの決め方を確認してください。KPIは全体の変化を把握するために使い、数値が変化した理由は個別ログへ戻って確認します。 管理画面の集計結果から確認対象を絞り込む流れは、ダッシュボードの見方も参考になります。集計値だけで結論を出さず、該当する会話ログと回答内容を確認して原因を判断してください。 ## 会話ログ分析を改善作業へつなげるための確認表 チャットボットの会話ログ分析は、次の順序で進めます。 - 対象期間、対象チャネル、抽出条件を決めたか - 個人情報や機密情報の取り扱いを決めたか - 分類担当者と判断担当者を決めたか - 質問意図、回答根拠、解決状況、離脱、有人引き継ぎを記録したか - 未解決の原因を情報不足、意図判別の不足、回答範囲外、導線の問題、有人切替の不足に分けたか - 原因に対応する修正箇所を決めたか - 修正内容、担当者、確認期限を記録したか - 修正後も同じ抽出条件と分類基準で確認したか - 再確認結果を管理表へ残したか 会話件数は、確認対象を探す手掛かりになります。ただし、実際の修正箇所は、個別ログの質問意図、回答根拠、未解決原因を確認して決めます。原因、修正箇所、担当者、期限を一行で管理し、修正後も同じ基準で確認すれば、会話ログ分析を継続的な改善作業として運用できます。 ## よくある質問 ### 会話が終了していれば、解決したと判断できますか 会話が終了した事実だけでは判断できません。離脱位置、直前の回答、再質問の有無、完了を示す操作や後続行動を確認します。判断材料が不足している場合は、「解決候補」または「要確認」と記録してください。 ### 未解決ログはすべてFAQへ追加するべきですか すべてをFAQへ追加する必要はありません。情報不足ならFAQやナレッジを修正します。個別判断や本人確認が必要な相談では、有人対応への切替条件を見直します。質問意図を判別できていない場合は、確認質問や選択肢を修正してください。 ### 分析の優先順位は問い合わせ件数で決めればよいですか 件数だけでは決めません。手続きを完了できない問題、誤案内の可能性、契約や支払いへの影響、有人対応の必要性を確認します。件数が少なくても、利用者の判断に大きく影響する内容は優先して確認します。 ### 修正後は何を確認すればよいですか 修正対象と同じ種類のログを、修正前と同じ条件で抽出して分類します。同じ未解決原因が再発していないか、離脱位置や直前の応答に問題がないか、必要な有人引き継ぎが行われたかを確認し、結果を管理表へ記録します。 ## Socratesでの運用を確認する 会話ログ分析を始める前に、自社で回答する範囲、回答根拠となるナレッジ、有人対応へ切り替える条件を整理してください。次に、分類結果をFAQ、ナレッジ、会話導線、担当範囲のどこへ反映するかを決めます。 Socratesで実現できる運用方法を確認したい場合は、現在の問い合わせ分類、回答範囲、ナレッジの管理元、有人切替条件を整理したうえで、導入相談をご利用ください。