顧客アンケートや問い合わせを感情分析にかけるときは、「何に対する評価か」と「どの単位で分類するか」を先に決めることが大切です。文章全体に肯定・否定のラベルを一つ付けるだけでは、改善すべき対象を判断しにくい場合があります。
この記事では、顧客の文章を分析する企業担当者に向けて、分類の考え方と人が確認すべき範囲を整理します。以下の判断表と手順は編集上の運用提案、顧客文は説明のための架空例です。
感情分析とは、文章に表れた評価の傾向を捉えること
テキストの感情分析は、文章に表れた肯定的・否定的・中立的な傾向を推定する技術です。たとえばMicrosoftの感情分析では、文と文書の単位でラベルと信頼度を返し、文書全体には肯定と否定が混在する「mixed」もあります。Microsoftの感情分析の仕様
「感情」という名称でも、怒り・悲しみ・喜びをそれぞれ判定するとは限りません。Google CloudのNatural Language APIは、否定的な文章について怒りと悲しみを区別する出力ではないと説明しています。Google Cloudの感情分析の説明
業務では「配送の否定的な意見を確認する」「料金への評価を整理する」など、文章から確認できる問いに使うことを提案します。本人の心理状態や解約意向まで、感情ラベルだけで決めない設計にしましょう。
肯定・否定だけでなく、中立・混在・保留を分ける
まず、業務上の分類基準を次のように決めます。これは各製品の標準ラベル一覧ではありません。「判定保留」は、モデルの出力とは別に設ける確認用の状態です。
| 業務上の分類 | 架空の顧客文 | 扱い方の案 |
|---|---|---|
| 肯定 | 設定が簡単で助かりました | 設定の使いやすさへの肯定として記録 |
| 否定 | 設定が難しく、途中で諦めました | 設定の使いやすさへの否定として記録 |
| 中立 | 設定手順の資料を送ってください | 明示的な評価はない依頼として扱う |
| 混在 | 設定は簡単ですが、料金は高いです | 設定は肯定、料金は否定に分ける |
| 判定保留 | さすがですね。また待たされました | 皮肉の可能性を含め、原文と前後のやり取りを確認 |
中立は、肯定と否定が混在している状態や、判断できない状態とは分けます。「分からない」を中立に寄せると、集計表から確認が必要な文章を見つけにくくなるためです。
感情と話題も別の項目にします。「料金についての質問」と「料金への不満」は、話題は同じでも評価が異なります。出力には少なくとも、原文の管理ID、話題、評価対象、感情ラベル、根拠となる原文箇所、確認状態を残す案が考えられます。根拠箇所は、AIに説明を補わせるのではなく原文へ戻って照合します。
文書全体と、対象ごとの評価を使い分ける
全体の反応を把握するなら、回答1件を一つの単位にする方法があります。具体的な改善点を探すなら、同じ回答の中でも評価対象ごとに分けます。
MicrosoftのOpinion Miningは、製品・サービスの属性などの対象と、それに結び付く評価を取り出す機能です。文書全体の感情とは別に、何が評価されているかを扱えます。MicrosoftのOpinion Miningの説明
たとえば「操作は簡単。問い合わせの返信は遅かった」という架空文なら、操作性と問い合わせ対応を別の項目にする設計が考えられます。対象別に集計する場合は、同じ回答が複数の対象に入ることを集計表へ明記してください。
長いやり取りを扱う際は、顧客の発言と担当者の返信を区別する運用を提案します。分析対象は顧客の発言とし、解釈に必要な前後関係は人が確認できる形で保持します。
信頼度の高さと、不満の強さは違う
Microsoftは、信頼度の値は分類に対するモデルの確信度を示すもので、感情の強さを表すものではないと説明しています。また、皮肉や入力文にない文脈、学習データに少ない表現などは精度上の制約になります。Microsoftの制約に関する説明
Google Cloudでは、感情の方向を表すscoreと、感情表現の強さを表すmagnitudeを返します。ただし文書のmagnitudeは正規化されず、文章が長いほど大きくなる場合があります。scoreがゼロ付近でも、中立と肯定・否定の混在の両方が考えられます。Google Cloudのスコア解釈
こうした仕様の違いから、異なる製品の数値を同じ基準で比べる運用は避けましょう。対応優先度も独立した項目にします。たとえば「ログインできません」という淡々とした連絡でも、業務停止の有無や期限は別途確認すべき内容です。否定的な表現が強い順に並べるだけで、対応順を確定しない設計を提案します。
導入前に、自社の文章で分類を確かめる
Microsoftは、実運用の特徴やばらつきを反映したデータでテストする必要性を示しています。Microsoftのテストデータに関する説明
試行は次の順序で進めることを提案します。
- 問いを一つ決める。「問い合わせ全体の感情」より、「初期設定への不満を確認する」など対象を具体化する。
- 入力できるデータの範囲を決める。氏名・連絡先など分析に不要な情報を外し、利用環境の保存・学習利用・閲覧権限を確認する。
- 実運用から確認用の文章を選ぶ。短文、長文、混在、皮肉が疑われる文も含め、人が分類した比較用データを作る。
- 人同士で判断が割れた例を検討する。基準を修正し、解消しない例は保留として残す。
- 基準調整に使っていない文章でAIの結果を確認する。全体の一致だけでなく、否定的な意見の見逃しと、否定扱いした誤判定を分けて数える。
- 誤判定の影響と確認作業の量を見て、採用範囲を決める。モデルや分類ルールを変えた際も、同じ確認用データで差を調べる。
一律の合格率はここでは設けません。担当者が読む順序を補助する用途と、自動で対応を確定する用途では、許容できる誤りが異なるためです。最初は人が原文を確認する前提で、確認対象の整理に使う方法が考えられます。
集計では、分母と保留件数を残す
否定的な意見の割合を出すなら、分母が「全回答」「感情を判定できた回答」「特定の対象に言及した回答」のどれかを明記します。混在を否定に含めるかどうかも先に決め、判定保留を除外した場合は件数を併記しましょう。
期間や受付経路を比較するときは、対象と除外条件をそろえて確認することを提案します。また、集計を読む際は「今回集めた文章の傾向」と「顧客全体の満足度」を区別します。分析対象外の顧客についてまで結論を広げないためです。
集計条件や検算の進め方は、AIでデータ分析を進める手順で確認できます。利用環境の選定へ進む場合は、AIデータ分析ツールの比較観点も参考になります。
感情分析を業務へ組み込む際は、分類表、原文を確認する担当者、集計の分母を一緒に決めましょう。ラベルを付けた後に誰が何を判断するかまで設計すると、試行の結果を次の業務判断へつなげられます。