コールセンターの通話を自動要約、記録の後処理を毎日6時間縮めた設計

コールセンターに寄せられる問い合わせは、商品仕様や納期、配送時間からWebフォームの操作方法まで幅広く、通話が終わるとオペレーターはその内容を記録に残します。この記録が自由記入だったため、どの項目をどこまで詳しく書くかは各自の技量に委ねられ、記録に時間がかかる人が出たり、受発注処理や見積作成を担うバックエンド側へ引き継ぐ際に情報が足りなかったりする状態が続いていました。

編集部の見立てでは、ここでの困りごとは文章を書く速さの差ではなく、「次に動く人が何を知っていれば仕事を進められるか」という基準が言語化されないまま、個人の判断に置かれていた点にあります。基準がなければ、丁寧な人ほど時間を使い、簡潔な人ほど情報が落ちる。文字起こしの精度に満足できず、コールセンター向けパッケージ製品はオーバースペックで見送ったという過去の検討も、求めるものの輪郭が定まらないうちは製品比較に落とし込めなかったことの表れではないでしょうか。

コールセンター製品そのものを入れ替えるのではなく、すでに稼働しているAmazon Connectに、要約を担うAmazon Bedrockを組み合わせるという構成の取り方が、この取り組みの土台になっています。Amazon Connect側に要約機能がないぶんを、同じクラウド内の別サービスで補う形です。機能一式を新たに買うのではなく、足りない一機能だけを既存環境に継ぎ足す判断が、コストを理由に一度は諦めた領域への着手を可能にしたと考えられます。

要約の実用性を左右したのは、プロンプトを一本にまとめなかった運用設計でした。オペレーターが手動で選ぶコールリーズンは大分類だけで約20種類あり、当初はひとつのプロンプトで全分類をまかなう作りでしたが、狙った要約にならない問い合わせが残ったため、プロンプトの種類を増やす方向へ切り替えられています。通話内容を300字から400字にまとめたうえで商品コードなどの定型項目は別途記録させるという出力形式の決め方や、顧客が長い数字を区切って発音するせいで6桁の商品コードに空白やハイフンが混ざる現象への補正は、机上の設計では出てこない類の調整です。ベースとなるプロンプトを支援側が用意し、それを自社環境で試しながら磨いていくという分担が、この細かさに耐える進め方でした。

請負契約で実装を任せ切らず、方式検討とレクチャーをクラスメソッドが、自社AWS環境への実装を同社の担当者が担う役割分担も見逃せません。2週間に1回の定例会議に加えて個別の技術的な問い合わせにも応じる体制があったため、要約完了まで15分かかっていた初期実装を文字起こし精度とAIモデルの調整で通話終了後のリアルタイム出力に変え、混雑によるタイムアウトはAmazon Bedrockへのリクエスト先を国内リージョン限定からグローバルへ広げて回避する、といった手当てをその都度打てています。

運用開始後は通話終了後の処理時間が縮み、オペレーター全員の稼働時間の合計で毎日6時間ほどの短縮になっています。当初はAIが通話内容を要約することへの抵抗感もありましたが、今では会話に集中するための機能として受け入れられました。引き継ぎ先でも、以前は「〇日まで希望」としか残らなかった記録になぜ急いでいるのかという背景まで含まれるようになり、各方面との調整が進めやすくなっています。社内の電話回線へも適用範囲が広がり、蓄積した文字起こしや要約のデータ分析、チャット問い合わせへの要約機能の展開も視野に入っています。