本文へスキップ
会員限定
tech公開更新約4分で読めます

通話要約AIで後処理時間が減らない理由 ー ACWを修正・転記まで測る

シェア
【FC要修正】通話要約AIで後処理時間が減らない理由 ー ACWを修正・転記まで測る

通話要約AIを入れれば、ACW(後処理時間)は減るはずだ、という前提が現場で崩れることがある。Metrigyの調査(Zoomブログでの引用)は、AI文字起こし・要約を使うオペレーターの平均通話時間が16.2分から10.4分へ、35%短縮したと報告する。だが、この数字をそのまま自社のACW削減効果として期待すると、多くの現場で「思ったほど減らない」という結果に直面する。理由は単純で、多くの効果測定が「要約が生成されるまで」だけを測り、その後のオペレーターの確認・修正・システムへの転記までを測っていないからだ。ACWは要約AIを入れた瞬間にゼロになる作業ではなく、内訳を分解して測り直す必要がある。

コールセンターのACWを要約生成待ち・確認・修正・転記に分ける

コールセンターのACWを要約生成待ち・確認・修正・転記に分ける

まず定義を揃える。Genesysの用語集は、AHT(平均処理時間)を「通話時間・保留時間・ACW(後処理時間)の合計」と定義し、NICEの用語集はACW(ラップアップタイム)を「通話終了後にオペレーターが行う付随作業に必要な時間」としている。ここでいう付随作業には、要約の確認、誤りの修正、CRMやチケットシステムへの転記が含まれる。

問題は、AI要約導入の効果を語る際、この内訳が分解されないまま「ACWが減った」と語られることだ。ACWは実際には4つの工程に分けられる。①要約が生成されるまでの待ち時間、②生成された要約を読んで正しいか確認する時間、③誤りがあれば修正する時間、④確定した内容を別システムへ転記する時間。Amazon Connectの生成AI要約機能は、通話終了後に構造化された要約をオペレーターへ提示し、Contact Control Panel上でこれを使ってACWを完了できるとしている(同社ドキュメント)。ここで短縮されるのは①の待ち時間と要約を一から書く手間の代替分だが、②③④が残ることに変わりはない。

同じ用件で導入前後を比べる

同じ用件で導入前後を比べる

比較を成立させるには、同じ用件・同じ難易度のコールを、導入前後で揃えて計測する必要がある。導入直後の効果測定でありがちな失敗は、比較対象がずれていることだ。導入前は複雑な用件も単純な用件も混在した平均値で、導入後は「AI要約が正しく生成できた案件」だけを抽出して平均を取ると、見かけ上の短縮幅は実際より大きく出る。

家計簿にたとえるとわかりやすい。「先月は外食費を含めた総支出」と「今月は外食費を除いた支出」を並べて「支出が減った」と言っても意味がない。項目を揃えなければ比較にならないのと同じで、ACWの前後比較も、要約の生成に失敗した案件・複雑で要約が使い物にならなかった案件を測定対象から外さずに含めるべきだ。

誤記修正と未生成を除外しない

ここが最も見落とされやすい論点だ。要約AIは常に正しい要約を返すわけではない。Vectaraのハルシネーション・リーダーボードは、要約タスクにおける主要な大規模言語モデルの事実不整合率(ハルシネーション率)を継続的に計測しており、最も精度の高いモデルでも0.6〜0.7%程度、モデルによっては10%を超える結果を公表している(同社調査・要約全般を対象にした汎用ベンチマークで、コンタクトセンター用途に特化した数値ではない点には留保が要る)。つまりモデルが進化しても、要約の事実不整合が完全にゼロになることは想定しにくい。

現場でこれが意味するのは、②確認・③修正の工程が、AI要約導入後も消えないどころか、要約を鵜呑みにできない以上は必須の工程として残り続けるということだ。効果測定で「要約が正しく生成できた場合の時間短縮」だけを採用し、修正が必要だった案件や、そもそも要約が生成されなかった案件(通信障害・録音不良等)を除外すると、実態より良い数字が出る。改善効果を語るなら、生成失敗・修正発生を含めた全件の平均で語るべきだ。

改善候補を時間と品質で並べる

再現可能な型として、ACW改善の打ち手を「時間」と「品質」の2軸で並べる。

型1: 待ち時間の短縮(時間軸)。 要約の生成が数秒〜十数秒で完了するよう処理を高速化する。オペレーターの手待ちを減らす直接的な打ち手だが、④転記の手間には効かない。

型2: 定型フォーマットへの構造化(品質軸)。 要約を自由文ではなく、用件・対応内容・次アクションといった固定フィールドに構造化して出力させる。確認しやすくなり②の時間が短縮されるが、フィールド設計を誤ると却って確認項目が増える。

型3: 転記先システムとの自動連携(時間軸)。 確認・修正済みの要約をCRM・チケットシステムへ自動反映する。④の転記時間そのものをなくせるが、連携先のデータ項目が要約のフィールドと一致していることが前提になる。

型4: 修正発生率そのものをモニタリングする(品質軸)。 「要約を編集した比率」を新しいKPIとして継続計測する。この比率が下がらなければ、モデルの精度改善が現場に効いていないことになる。

ここから先は会員限定です。

無料登録で記事の続きと限定コンテンツが閲覧できます。

この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア