Genesys Cloudでは通話録音を標準機能として利用できますが、業務によっては通話録音をGenesys Cloud上で確認するだけでなく、外部システムから検索・参照したり、他の業務データと組み合わせて活用したいケースがあります
そこで現在、Genesys Cloudの録音情報や通話情報をAWSへ取り込み、データベースへ蓄積し、将来的にはWebアプリなどから検索・参照できるようにするための基盤を構築しています。
この記事では、具体的な実装手順や詳細仕様を紹介するのではなく、
- どのような課題を解決したいのか
- どのような構成で仕組みを考えたのか
- 運用を見据えてどのような点を意識したのか
といった、構成の全体像や設計の考え方を中心にご紹介します。
この仕組みで実現したいこと
Genesys Cloudの録音情報を外部活用できるようにすることで、単に録音ファイルを保存するだけでなく、必要な録音を検索・参照しやすくし、将来的に他の業務データと組み合わせて活用できるようにすることを目指しています。
たとえば、以下のような活用を想定しています。
- 録音情報を日時や担当者、キューなどの条件で検索しやすくする
- 外部システムの業務データと組み合わせて活用する
- 将来的に検索・参照できる仕組みへ発展させる
今回作ろうとしているもの
今回構築しているのは、Genesys Cloudの録音情報を外部で活用するための収集・蓄積基盤です。
大きな流れとしては、次のようなイメージです。
Genesys Cloudの録音・通話情報
→ AWSへ連携
→ データベースへ蓄積
→ 将来的に検索・参照
現時点では、まずこのうちの前半部分、つまり録音情報・通話情報を安定的に取り込み、蓄積するための基盤を中心に構築しています。
なぜ外部に録音情報を蓄積するのか
Genesys Cloud単体でも録音の確認は可能ですが、実際の業務ではそれだけでは足りない場面があります。
たとえば、
- 顧客情報と通話履歴をあわせて確認したい
- 独自の条件で録音情報を検索したい
- 別システムから録音情報を参照したい
- 将来的に分析や二次活用につなげたい
といった要件です。
こうした使い方を考えると、録音ファイルそのものだけではなく、「いつ・誰が・どのような通話を行ったのか」という関連情報もあわせて管理することが重要になります。
そのため今回の仕組みでは、録音情報に加えて、通話情報や関連するマスタ情報もあわせてAWS側へ蓄積できるようにしています。
システム全体の構成
今回の構成では、Genesys CloudとAWSの各サービスを組み合わせて、録音情報を蓄積するための基盤を構成しています。
主な役割としては、
- Genesys Cloud：通話・録音の元データ
- AWS上のストレージ：録音関連データの受け取り
- 非同期連携基盤：後続処理への受け渡し
- サーバレス処理：録音情報・通話情報の取込み
- データベース：蓄積先
- 監視・通知：異常時の検知
- 定期実行：再取得やマスタ同期
といった形になります。
重要なのは、すべてを一度に同期的に処理するのではなく、役割ごとに処理を分けていることです。
これにより、一時的な障害が発生しても影響範囲を抑えやすくし、運用しやすい構成を目指しています。
録音情報はどのように取り込むのか
録音情報の取込みでは、Genesys Cloudから連携される録音関連データを起点に、AWS側で必要な処理を進めていきます。
まず録音関連データを受け取り、それを起点にメイン処理を実行し、録音情報を蓄積します。
さらに、録音に対応する通話情報についてもAPIを利用して取得し、録音情報と関連付けて保存します。
こうすることで、将来的に
- 日時
- 担当ユーザー
- キュー
- 通話種別
- 後処理情報
といった条件で検索しやすくなります。
通話情報もあわせて扱う理由
外部で録音情報を活用する場合、重要なのは音声ファイルそのものだけではありません。
実際には、
- この録音がどの通話に対応しているのか
- 誰が対応したのか
- どのキューで受けた通話なのか
- 通話後にどのような処理が行われたのか
といった情報が揃ってはじめて、実務で使いやすいデータになります。
そのため今回の構成では、録音情報だけを単独で蓄積するのではなく、関連する通話情報もあわせて取得して管理する形にしています。
一時的な失敗をどう扱うか
外部APIやクラウドサービスと連携する以上、処理が常に一度で成功するとは限りません。
たとえば、録音情報そのものは正常に受け取れていても、関連する通話情報の取得だけが一時的に失敗するケースも考えられます。
このような場合に、すべてを丸ごと失敗として最初からやり直すと、正常に処理できていた部分まで無駄に再処理することになります。
そこで今回の仕組みでは、正常に保存できた情報は保持しつつ、失敗した部分だけ後から再取得できるようにすることを重視しています。
この考え方によって、処理の安定性と運用性の両方を高められるようにしています。
再取得処理と定期実行
一時的に取得できなかったデータについては、別の定期処理から再取得できるようにしています。
このようにメインの取込み処理と再取得処理を分けておくことで、
- 初回取込みの処理をシンプルに保てる
- 一時的な失敗から回復しやすい
- 異常時の運用ポイントを整理しやすい
といったメリットがあります。
また、無制限に再試行し続けるのではなく、一定の条件を超えても解消しない場合には、監視や通知の仕組みと組み合わせて、人が確認できるようにすることも重要です。
マスタ情報も定期的に同期する
録音の検索や参照をしやすくするには、IDだけではなく、ユーザー名やキュー名、後処理コードのような人が見て分かる情報も必要です。
そのため今回の仕組みでは、録音情報や通話情報だけではなく、Genesys Cloud上の各種マスタ情報についても定期的に同期するようにしています。
これにより、将来的に検索・参照の仕組みを構築する際にも、より実用的で分かりやすい形にしやすくなります。
障害が起きる前提で設計する
今回のような外部連携基盤では、正常系の処理を作るだけでなく、障害が起きることを前提に考えることが重要です。
たとえば、
- 一時的なAPI取得失敗
- データベース接続エラー
- 処理の異常終了
- 定期処理の未実行
といったケースを想定しながら、どこまでを自動復旧に任せ、どこから人が確認するのかを切り分けておく必要があります。
このあたりは、単にデータを取り込む仕組みを作るだけではなく、継続運用できる基盤として成立させるために重要なポイントだと感じています。
実際に構築して感じたこと
今回の構築を通して、特に重要だと感じたのは次のような点です。
1. 必要な情報をどう組み合わせるかが重要
録音情報を外部で活用するためには、音声データだけでなく、検索や参照に利用する通話情報もあわせて管理する必要があります。
この考え方自体は当初から想定していましたが、実際に構築を進める中で、どの情報をどこから取得し、どのタイミングで蓄積するのかを整理することの重要性を改めて感じました。
また、将来的にどのような条件で録音を検索・活用したいのかを意識しながら、蓄積する情報を選定していくことも重要だと考えます。
2. 取込みよりも運用設計が重要になる
最初は「どうやってデータを取得するか」に目が向きがちですが、実際には
- 失敗したときにどうするか
- 再取得をどう考えるか
- どう監視するか
といった運用面の設計が、かなり重要でした。
3. 将来の活用イメージを持って設計することが大事
検索・参照の仕組みをまだ構築していない段階でも、将来どのように使いたいかを想定して蓄積内容を考えておくことで、後の拡張がしやすくなります。
現在の進捗と今後
現在は、録音情報・通話情報・マスタ情報を取り込む基盤の整備と動作確認を進めています。
今後は、
- 監視・通知まわりの調整
- セキュリティ面の整理
- 正常系／異常系を含めたテスト
- 設計資料の整理
などを進めながら、基盤としての完成度を高めていく予定です。
その後は、この基盤に蓄積した録音情報や通話情報を活用するための検索・参照の仕組みの設計・開発へ進めていく想定です。
まとめ
今回は、Genesys Cloudの通話録音を外部活用するために構築しているAWS基盤の概要をご紹介しました。
この仕組みによって、録音ファイルを保存するだけではなく、通話情報やマスタ情報もあわせて蓄積し、将来的に検索・参照しやすい形へつなげていくことを目指しています。
実際に構築してみると、データを取得することそのものよりも、
- どの情報を蓄積するか
- 失敗時にどう扱うか
- どう監視・運用するか
といった点が非常に重要でした。
今後は、この取込み基盤を土台として、録音情報をより効果的に活用できる仕組みへ発展させていきたいと考えています。
