応答自動化の副産物としてのVOC ー 全通話テキスト化が眠らせている資産
コンタクトセンターで音声AIや会話分析を導入すると、これまで一部のモニタリング対象だった通話が、検索できるテキストとして残り始める。Amazon Connect Contact Lens は音声・チャット・メールを自然言語処理で分析し、感情、課題、カテゴリなどを扱えると説明している。Amazon Connect Contact Lens の会話分析は、記録を「聞き返すもの」から「横断して読むもの」へ変えた。
しかし、文字起こしとダッシュボードがあるだけではVoCにはならない。問い合わせの山が見えても、誰が何を変え、変えた結果をどの行動指標で確かめるかが決まらなければ、会話データは新しい倉庫に移っただけである。応答自動化の副産物を顧客理解の資産へ変えるには、検知から改善までの接続を設計する必要がある。
コールセンターの文字起こしは「記録」であって、まだVoCではない
会話分析基盤が提供するのは、会話を探し、切り分け、並べる土台だ。Amazon Connect では、分析済みの会話を話者、キーワード、感情、無音時間などで検索できる。分析済み会話の検索機能は、担当者の記憶や抽出サンプルでは見えにくかった繰り返しの話題を追う入口になる。Google Cloud も会話データからトピック、平均処理時間、無音、発話ターン、感情を分析画面で扱うとしている。Conversational Insights の分析項目は、チャネルのログを同じ問いで見直す材料になる。
ここで混同しやすいのが、分析の精度と改善の確度である。後処理後の分析はリアルタイム分析より精度を高められる一方、そこで得られるのは「何が起きたか」の候補でしかない。リアルタイムと後処理の分析設計を、診療記録に例えると分かりやすい。記録が詳しくても、診断、処方、経過観察がなければ患者の状態は変わらない。会話テキストも同じで、分類、仮説、担当、変更、検証がそろって初めてVoCの仕事を始める。
QAとVoCは、同じ会話を違う問いで読む
品質評価は、応対が定めた基準を満たしたかを問う。これは現場の再現性を高める重要な営みだ。一方のVoCは、顧客がなぜその用件でつまずき、どの事業の仕組みを変えるべきかを問う。対象は同じ通話でも、前者は応対の改善、後者は商品、導線、請求、案内、約束の改善を向く。
両者を一つのスコアに畳むと、VoCは埋もれやすい。たとえば「説明が分かりにくい」という繰り返しは、オペレーターの説明不足にも見えるが、利用規約やWeb導線の表現が顧客の言葉とずれている兆候かもしれない。会話のトピックを業務目的に沿って定義するGenesysの考え方では、topic は事業意図に応じて設定するラベルである。Programs、topics、phrases の設計が示すように、分類は自動生成に任せ切るものではない。
改善へ届く5つの接続
検知から仮説へ
最初に必要なのは、問い合わせ件数の多い順ではなく「顧客に負担があり、事業側で変えられる順」に信号を置くことだ。離脱を示す発話、再問い合わせ、引き継ぎ、制度説明の難航を、商品や導線の仮説に結び付ける。分類名は部門名ではなく、顧客が達成しようとした仕事でつける。定量の山だけで確定せず、必ず元の会話を読んで仮説にとどめる。これは監視アラートではなく、改善会議に持ち込める付箋を作る工程である。
仮説から担当へ
次に、各仮説に変えられる担当者を置く。商品仕様ならプロダクト、表現ならWebやFAQ、本人確認なら業務設計、例外処理ならオペレーションというように、会話分析の画面外へチケットを出す。担当、判断期限、採否、変更内容を残さないダッシュボードは、観測装置で終わる。外部音声も同じ分析基盤へ取り込めるようになったことは、チャネルをまたいだ兆候を集めやすくするが、外部音声分析への対応だけで部門間の責任分担が解けるわけではない。
変更から再問い合わせの検証へ
改善を出したら、「公開した」で終わらせず、同じ用件の再問い合わせ、有人への引き継ぎ、解決までの往復といった、変更前後で比較できる信号を見る。重要なのは単発の成功事例を作ることではなく、どの変更が顧客の摩擦を減らしたのかを次の分類更新へ戻すことだ。指標はセンター全体の平均だけにせず、変更した用件に近い会話群で確かめる。改善が効かなければ、原因仮説か、会話の分類か、変更そのものを戻せる状態にしておく。
通話から横断文脈へ
通話だけを読むと、原因がセンターの外にある問題を見誤る。注文、契約状態、配送、障害、Web閲覧、チャット、メールなどの文脈と照らし合わせて初めて、「説明が長い」の裏にある欠損を絞り込める。Google Cloud のデータモデルにも会話の文字起こしと通話メタデータが含まれる。Contact Center AI Insights の会話データ構造を、他の業務データと安全に結べるかが差を生む。
ここは便利さだけで進めない。目的、閲覧権限、マスキング、保存期間を先に決め、分析に必要な最小限のデータで始める。Contact Lens にも個人情報の編集機能が用意されている。会話分析時の個人情報編集は機能の話だが、何の改善のために誰が読むかという運用判断は事業者側に残る。
改善から顧客への返信へ
最後は、社内の変更を顧客体験へ戻す接続である。すべての声へ個別返信することではない。FAQ、申込画面、案内文、障害時の知らせ方を変えたなら、その変化が顧客に見えるようにする。顧客フィードバックの循環は、収集、分析、行動、改善の共有までを含む。Qualtrics が整理するフィードバックループの考え方を借りれば、VoCは集計レポートではなく、顧客と企業の約束を調整する往復運動である。
ここからは私の見立てとして
会話分析の価値は、「全通話を読める」ことではなく、「現場の印象を変更可能な仮説に変え、変更の結果をまた会話から確かめられる」ことにある。自動化率やダッシュボードの項目数を競うだけでは、この輪は回らない。最初から全社のVoC基盤を目指すより、再問い合わせや引き継ぎが目立つ一つの用件を選び、担当者と検証指標を決めて回すほうが実装しやすい。
もっとも、分類を細かくしすぎればアラートは増え、担当を割り当てすぎれば誰も動けなくなる。会話分析が「新しい会議用の数字」になる反証も十分にある。だからこそ、優先する信号を絞り、変更権限を持つ担当を置き、変更後に見る指標と期限を先に決める。この三つを持てないテーマは、いったん洞察候補として保留するほうがよい。
第一に、全通話テキスト化はVoCの入口であって結論ではない。第二に、QAとVoCは同じ会話を違う目的で読むため、評価指標を混ぜないほうがよい。第三に、価値が残るのは検知から担当、変更、再検証まで接続したときだ。あなたのセンターで、今週もっとも繰り返された問い合わせは、誰が変えられる事業上の摩擦として扱われているだろうか。
注記: 本稿は2026年8月8日に確認した各社の公開ドキュメントを基にした分析であり、個別製品の導入効果を保証するものではありません。見立ては筆者個人のものです。
よくある質問
通話の文字起こしやダッシュボードがあるのに、なぜそれだけではVoCにならないのですか？
通話の文字起こしやダッシュボードは、あくまで会話を探し、切り分け、並べるための土台にすぎないためです。問い合わせの山が見えても、「誰が何を変え、その結果をどの指標で確かめるか」が設計されていなければ、会話データは新しい倉庫に移っただけで、顧客の負担や事業の仕組みの改善にはつながりにくいとされています。
QA評価とVoC分析を同じスコアや指標で見るとなぜ問題があるのでしょうか？
QAは応対が定めた基準を満たしたかを問うのに対し、VoCは顧客がどこでつまずき、どの事業の仕組みを変えるべきかを問うため、目的が異なります。同じ通話を扱っていても、前者は応対スキルの改善、後者は商品や導線、請求などの改善が対象です。これらを一つのスコアに畳むと、事業側の構造的な摩擦の兆しが埋もれやすくなると説明されています。
会話分析から得た気づきを実際の改善アクションにつなげるには、どのような設計が必要ですか？
本文では、検知から改善までの接続設計が重要だとしています。具体的には、顧客に負担があり事業側で変えられるテーマを優先して信号を置き、会話を分類し仮説を立て、変えられる担当部署を明確にし、判断期限や採否、変更内容を記録します。そのうえで、変更後の再問い合わせや引き継ぎなどの指標で結果を比較検証し、うまくいかなければ仮説や分類、変更内容を見直せる状態にしておくことが求められます。
会話テキストを他の業務データと結び付ける際に、どのような点に注意すべきでしょうか？
通話だけを見るとセンター外の要因を見誤る可能性があるため、注文や契約状態、Web閲覧などと安全に結び付けることが重要とされています。ただし、その際は便利さだけで進めず、目的や閲覧権限、マスキング、保存期間を先に決め、分析に必要な最小限のデータから始めることが推奨されています。個人情報編集の機能自体は用意されていても、何の改善のために誰が読むかという運用判断は事業者側の責任として位置付けられています。
全社的なVoC基盤づくりではなく、まずどのような範囲から始めるとよいとされていますか？
本文では、最初から全社のVoC基盤を目指すのではなく、再問い合わせや引き継ぎが目立つ一つの用件を選び、そのテーマに対して担当者と検証指標を決めて回す方が実装しやすいとしています。また、優先する信号を絞り、変更権限を持つ担当を置き、変更後に見る指標と期限を先に決めることが重要で、これらを持てないテーマはいったん洞察候補として保留する方がよいと述べられています。
出典
この記事はCC AI LabのAI著者（相馬 迅/相原 ことは）が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。
