はじめに
この記事はDMMグループ Advent Calendar 2025の3日目の記事です。
こんにちは。プラットフォーム開発本部の佐々木 勝春です。 今年度の上半期に、コンタクトセンターにリアルタイム文字起こし機能を導入しました。
本記事では、これまでバッチ形式で実施していたコンタクトセンターの文字起こし処理をリアルタイム化し、スーパーバイザーが通話中にモニタリングできるようにした取り組みについて、技術的な実装のポイントと導入効果についてお伝えしたいと思います。
背景と課題
従来の文字起こし処理の課題
私たちのコンタクトセンターでは、顧客対応の音声データを文字起こしして、後から内容を確認する仕組みがありました。
従来の方式：Azure Speech-to-Textの採用理由
当時は、GPT をセキュアに利用できる基盤として Azure を選定しており、その中で高精度な文字起こしが可能な Azure Speech-to-Text を採用していました。 Azure Speech-to-Textにはリアルタイム文字起こし機能も存在しますが、AWS環境からAzureへストリームデータをSDK経由で転送する部分がうまく処理できず、修正対応に時間を要することが見込まれました。
そのため、リアルタイム性よりもリリースまでの速度を優先し、バッチ形式の文字起こしが提供されている専用REST APIを使う形で許容しました。当時は文字起こしのリアルタイム性がそこまで重視されていなかったこともあり、妥協案としてこの方式で対応していました。
1. リアルタイム性の欠如
従来の方式では、通話終了後に音声データをWAV形式でS3にアップロードし、Lambda関数でAzure Speech-to-Textのバッチ形式REST APIを使って文字起こしを行っていました。そのため、スーパーバイザーが通話中に内容を確認したい場合、途中から会話に参加するか、その時点までの音声ファイルをダウンロードして確認する、もしくはAmazon Connectのインスタンスにログインしてコンタクトを確認するなどの手順を踏む必要がありました。
2. 処理回数とコストの問題
「Agent(カスタマーサポート)単独」、「Customer単独」、「AgentとCustomerの双方」の3つのセグメントごとに文字起こしを取得するという要件があり、これを実現するにはそれぞれのセグメントの音声ファイルから文字起こしを行う必要がありました。つまり、1回の通話で3回の文字起こし処理が必要で、通信量や処理コストが大きくなっていました。
解決策の概要
これらの課題を解決するため、以下の方針でリアルタイム文字起こし機能を導入しました。
- Amazon Connect Contact Lensによるリアルタイム文字起こしの活用
- AWS AppSync EventsによるマネージドWebSocketでのリアルタイム配信
- AWS Step Functionsによる効率的なデータ処理
技術的な実装のポイント
1. Contact Lensによる文字起こし処理の統合とコスト削減
Contact Lensの選定理由
あらためてリアルタイム性を求めていくにあたり、当時はなかった製品や機能が追加されていたり、文字起こしの精度の改善などを確認するため、これまでどおりAzure Speech-to-Textを使い続けるか、ほかの製品に乗り換えるかを検討しました。
検討の結果、以下の理由からAmazon Connect Contact Lensを採用しました。
- 文字起こし品質: サンプルデータでの検証により、Contact Lensの文字起こし品質が従来のAzure Speech-to-Textとそこまで変わらなかった
- AWSとの親和性: AWS Amazon Connectと親和性が高く、機能追加や拡張がしやすい
- コスト削減: 処理回数の削減により、コストも削減できる見込みがあった
- 統合の容易さ: Amazon Connectのコンタクトフロー上で有効化するだけで利用でき、既存の文字起こし処理パイプラインを簡素化できる
呼び出し回数削減によるコスト削減と利便性の向上
従来のAzure Speech-to-Textによる文字起こし処理を削除し、Amazon Connect Contact Lensのリアルタイム文字起こし機能に統合しました。Contact Lensを利用することで、以下の効果が得られました。
- 処理回数の削減: 従来は3つのセグメントごとに文字起こしをするために1回の通話で3回の文字起こし処理が必要でしたが、Contact Lensでは1度の処理でAgentとCustomerの両方の文字起こしが可能になりました。
- コスト削減: 処理回数の削減と通信量の削減により、文字起こし処理にかかるコストを大きく削減できました
- リアルタイムでの結果確認: 問い合わせの通話内容をバッチ形式からリアルタイムに確認できるようになりました
Contact Lensは、Amazon Connectのコンタクトフロー上で有効化するだけで、リアルタイムに会話分析セグメントとして文字起こしデータを取得できます。これにより、既存の複雑な文字起こし処理パイプラインを簡素化できました。 さらにContact Lensにより感情分析結果も取得できるようになりました。 Contact Lensではその他にカスタム語彙を利用した文字起こし精度の向上なども利用しています。
参考：Amazon Connect Contact Lensで会話分析を有効にする
2. AWS AppSync EventsによるマネージドWebSocketの実装
リアルタイムに文字起こしデータをクライアントに配信するため、WebSocket通信が必要でした。 今回はAWS AppSync Eventsを利用しました。
AppSync Eventsを選んだ理由
AppSync Eventsは、以下の理由から選択しました。
- マネージドサービス: WebSocket接続の管理やスケーリングをAWSが自動で行ってくれるため、運用負荷が低い
- 認証・認可の柔軟性: IAM認証、API Key認証、Lambda認証など、5種類の認証方法をサポートしており、要件に応じて選択できる
- PubSub形式: 複数のクライアントに対して効率的にデータを配信できる。特定のクライアント向けや接続中の全クライアントに対してデータ送信が可能
今回はフロントエンドとの認証にAWS IAMを利用しました。そして通話ごとに発行されるcontact_idごとにチャンネルを分けるように設定しました。
システム構成概要
システムの処理フローは以下の通りです。
- Contact Lensから取得した会話分析セグメントをKinesis Data Streamsに配信
- EventBridge Pipes経由でStep Functionsにデータを渡す
- Step FunctionsからAppSync Events Publisher EndpointにHTTPリクエストでデータを送信
- AppSync EventsがWebSocket経由で接続されているクライアントにリアルタイム配信
- 通話が完了した時点でEventTypeがCOMPLETEDの会話分析セグメントが送られるのでそれを受信した場合は、文字起こし結果を元に問い合わせ内容の要約を生成するAPIを呼び出すLambda関数をInvokeする
この構成により、サーバーレスでスケーラブルなリアルタイム配信システムを構築できました。
文字起こし結果の利用
上記フローの5番目で通話が終了したタイミングで文字起こし結果を元にカスタマーサポートの方が通話内容を確認しやすい形式で要約しています。
加えて問い合わせ内容の管理のためカスタマーサポートの方が行っているサービス区分などの分類についても、文字起こし結果を元にAIで自動分類するAPIにリクエストし、自動でできるようにしています。
3. Step Functionsによる並列処理
Step Functionsを活用して、Contact Lensの文字起こし結果をDynamoDBへのインサートと、AppSync EventsのPublisher Endpointへのデータ配信を並列に実行するようにしました。 Step Functionsのステートの実装に使うASL(Amazon States Language Specification)はJSONataを利用して記述しました。
並列処理の構成
会話分析セグメントのEventTypeがSEGMENTSの場合、以下の2つの処理を並列で実行します。
- DynamoDBへの保存: 文字起こしデータを
transcript_segmentsテーブルに保存（後から取得できるようにするため） - AppSync Eventsへの配信: リアルタイムにクライアントに配信するため、AppSync Events Publisher Endpointにデータを送信
並列処理により、データ保存とリアルタイム配信の両方を効率的に実行でき、レイテンシを削減できました。
DynamoDBスキーマ設計の注意ポイント
transcript_segmentsテーブルのスキーマ設計において、重要な注意点があります。
Contact Lensから送信される文字起こしデータでは、トランスクリプトの問い合わせの開始オフセットであるbegin_offset_millisの値が同じになる場合があります。そのため、DynamoDBのキー設計において、begin_offset_millisをそのままsort keyに設定できません。
Data model for conversational analytics segment streams to analyze voice contacts in Contact Lens
例えば、contact_idをpartition key、transcript_idをsort keyとして設計することで、各文字起こしセグメントを一意に識別できるようになります。transcript_idはContact Lensから送信される各セグメントごとに割り振られる一意のIDであるため、この設計により、同じタイミングで送信されるAgentとCustomerの両方のデータを正しく保存できます。
データ取得の仕組み
クライアントは、以下の2段階でデータを取得します。
- 既存データの取得: WebSocket接続前に、REST API（
/v1/transcripts/{contact_id}）ですでに配信済みの文字起こしデータを取得 - リアルタイムデータの取得: WebSocket接続後、AppSync Events経由でリアルタイムに配信される文字起こしデータを受信
この構成により、接続前に配信されたデータも含めて、すべての文字起こしデータを確認できるようになりました。
REST APIを別途用意した理由
他の画面や機能から文字起こし結果を参照する可能性も想定されたため、REST APIとして用意することにしました。
さらに、当時のAppSync EventsではWebSocket接続前の既存データ取得が単体では実現できませんでした。
ただし、リリース間際の2025年4月24日に、AWS AppSync Eventsのデータソース統合機能がリリースされました。この機能により、AppSync EventsからDynamoDBなどのデータソースに直接アクセスできるようになっています。
AWS AppSync Events のデータソース統合を使用してリアルタイムアプリケーションを強化
今後、AppSync Eventsのデータソース統合機能を活用するかどうかは、要件や運用状況を踏まえて検討していく予定です。
導入効果と利用者評価
利用頻度
本システムは、回答者全員が「毎日」または「週に数回」利用しており、業務に定着していることが分かりました。
- ほぼ毎日利用している：85.7%
- 週に数回利用している：14.3%
- 月に数回利用している：0%
- ほとんど利用していない：0%
日常業務の中で欠かせないツールとなっています。
主な利用場面
- クレーム電話のモニタリング：78.6%
- 長時間電話のモニタリング：100%
- 対応者からモニタリング依頼があったとき：7.7%
使い勝手
「使いやすい」との回答が多数を占めており、直感的な操作性やシンプルな画面設計が高く評価されています。
- とても使いやすい：42.9%
- 使いやすい：50.0%
- どちらともいえない：7.1%
- 使いにくい／とても使いにくい：0%
良かった点
利用者からは、以下のような効果が報告されました。
- 作業効率の向上: 対応者にヒアリングしなくても内容を即時把握できる
- 情報把握の迅速化: 長時間・クレーム電話のモニタリング時、途中からでも内容を把握できる
- 会話の確認: 会話の最初に遡って確認できる
- メンタル負担の軽減: モニタリング担当者のメンタル負担軽減になる（ユーザーの怒った声を直接聞かずに済む）
- 操作性の向上: シートマップからワンクリックで確認できるのが便利（Amazon Connectの管理画面を経由せずに済む）
利用者の声
実際に利用している方々から、以下のような声をいただきました。
通話の途中からモニタリングを開始したときなどに、やり取りを確認するために使用しています。状況把握がしやすく便利です。
チャットでオペレーターに状況確認していたので時間がかかっていましたが、文字起こしのおかげでオペレーターとやり取りしなくても大体の状況を把握できるようになりました。
まとめ
本プロジェクトでは、以下の技術的な工夫により、リアルタイム文字起こし機能を実現しました。
- Contact Lensによる統合: 従来の3回の文字起こし処理を1回に削減し、コストと通信量を大幅に削減
- AppSync Eventsの活用: マネージドWebSocketにより、運用負荷を抑えながらリアルタイム配信を実現
- Step Functionsによる並列処理: データ保存とリアルタイム配信を並列実行し、効率的な処理を実現
これらの技術的な工夫により、スーパーバイザーが通話中にリアルタイムで内容を確認できるようになり、業務効率の向上と通話中のモニタリングの向上につながりました。 インフラ面の費用を削減しながら利用者の利便性を向上できたのがよかったと思います。
今後はDynamoDBに保存した文字起こし結果を元にナレッジサジェストなどでAgentの対応を支援したりコールバック時のメモ作成の際の補助などに利用できたらと考えています。
