こんにちは、LINE上で動くおくすり連絡帳 Pocket Musubiというサービスを開発している南光(@stnamco)です。
この記事では、Amazon Connectの音声問い合わせを実運用していく過程で遭遇した問題とそのデバッグで得られた知見などを紹介します。
そもそもAmazon Connectとは
Amazon Connectとは、AWSが提供しているクラウドのコンタクトセンターを利用するためのサービスで、雑な言い方をするとAWSを利用して電話をかけることができます。 また電話以外にも、インタラクティブなチャット機能や、人工知能 (AI) /機械学習 (ML) を利用したインタラクションの自動化などの機能を低コストで利用することができるそうです。
AWSマンガ第 12 話:短期間でコンタクトセンターを立ち上げろ!
発生した問題
前述のおくすり連絡帳サービスには処方箋画像を薬局側に送信する機能が提供されているのですが、処方箋画像が薬局に送られた際に薬局へ電話で通知するという機能を実装するためにAmazon Connectを利用していました。
業務フロー ※pockebiはおくすり連絡帳サービスの略称です。
上記機能に対して、特定の薬局から電話をとっても無音で電話が切れてしまうという調査依頼がありました。
その問題解決のために以下のような方法で検証を進めました。
- 問い合わせ検索から指定のContactTraceRecordを確認。
- Cloud Watchのログを確認。
問い合わせ検索から指定のContactTraceRecordを確認
まずは問い合わせ検索から、指定の問い合わせのデータを確認しました。
電話番号がわかっていたので、電話番号から対象の問い合わせを見つけました。 余談ですがContact Lensという音声分析を利用した検索Filterもあるそうで、機会があれば触ってみたいなと思いました。
指定の問い合わせを見つけたので、Disconnect reasonを確認したところ、CONTACT_FLOW_DISCONNECTという理由が入っていました。これはフローで通話が切断されたときに入る値です。 対象の問い合わせフロー以外にもDisconnect reasonがCONTACT_FLOW_DISCONNECTになっている問い合わせがありましたが、薬局ユーザに確認したところ問題なく機能が使えていたので、これが原因ではなさそうでした。
ちなみに他の接続解除理由には以下のようなものがあります。
- CUSTOMER_DISCONNECT: お客様から切断されました。
- AGENT_DISCONNECT: 問い合わせがまだ通話中に、エージェントから切断しました。
- THIRD_PARTY_DISCONNECT: サードパーティーとの通話では、エージェントが離れた後、問い合わせがまだ通話中にサードパーティーが通話を切断しました。
- TELECOM_PROBLEM: 通信事業者、ネットワークの輻輳、ネットワークエラーなどに起因する、通話の接続の問題により切断されました。
- CONTACT_FLOW_DISCONNECT: フローで通話が切断されました。
- OTHER: これには、前のコードで明示的にカバーされていない理由がすべて含まれます。問い合わせがAPIによって切断された場合などです。
Cloud Watchのログを確認
次にCloud Watchにあげられている問い合わせフローのログから調査を行いました。 ログの有効化をしていれば、新しいAmazon Connectインスタンスを作成した際、Amazon CloudWatchロググループに自動的に収集されます。
※Amazon CloudWatch ロググループに保存される問い合わせフローログ
問い合わせフローのログには、ログに関連付けられているブロック、問い合わせID、およびブロック内のステップが完了した後に取られたアクションに関する詳細が含まれています。
こんな感じ
{ "ContactId": "11111111-2222-3333-4444-555555555555", "ContactFlowId": "arn:aws:connect:us-west-2:0123456789012:instance/nnnnnnnnnnn-3333-4444-5555-111111111111/contact-flow/123456789000-aaaa-bbbbbbbbb-cccccccccccc", "ContactFlowModuleType": "SetQueue", "Timestamp": "2021-04-13T00:14:31.581Z", "Parameters": { "Queue": "arn:aws:connect:us-west-2:0123456789012:instance/nnnnnnnnnnn-3333-4444-5555-111111111111/queue/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" } }
こちらも有効な処理ができているログとの差分を確認しましたが、特に問題となるような点が見受けられませんでした。以上のような調査結果から、ログからだけでは原因を辿っていくのは難しそうだなと判断しました。
調査結果を含めAWSのサポートに問い合わせしたところ、ユーザの電話側の設定確認をして欲しい旨を共有されました。 ユーザに電話の設定確認を依頼したところ、電話通知を受ける側のユーザで電話の転送サービスを利用されていることがわかりました。Amazon Connectはエンドカスタマー側で転送の設定がされている場合、エンドカスタマーに転送された時点でコンタクトフローが終了となるようです。
これで無事原因の把握をすることができました。Amazon Connectの音声問い合わせは、システムログからだけでは追えない部分が多いので、電話の受け手であるユーザともうまく連携してデバッグしていくのが良さそうです。
Tips
通話内容の録音
AWSからの返答の中で電話の設定だけでなく、通話内容の録音をすると良いとのアドバイスをもらいました。 というのも今回はユーザからの無音で電話が切れるという問い合わせから調査を開始しましたが、実際ユーザがどういった振る舞いをもとにそのように判断したのかを、言葉のやりとりからだけでは正確に事象を把握することができないからです。
録音はAmazon Connectのインスタンスが作成された際に作られたAmazon S3バケットに保存されていきます。
ただ今回のユースケースで言うと、電話を利用した通知のみでありエンドユーザとの通話が発生するわけではありません。そのため前述のような方法は使えないとのことです。
このような場合には、発話内容を録音できるライブメディアストリーミングを利用する必要があります。
AWSサポートへの問い合わせテンプレート
AWSサポートに問い合わせをした際、いくつかの情報提供を求められて複数回メールのやりとりが発生しました。次回サポート依頼することになった際にはそのようなラリーは避けたいので、技術的なお問い合わせに関するガイドラインを参考にしながら、Amazon Connect用の問い合わせTemplateを作ったので書き残しておきます。
上記ガイドラインに記載のあるいくつかの項目は、サポートの作成時点でGUIから設定する必要があります。特に緊急度の部分は件名や本文に「緊急」等と記載されても、緊急度は上がらないので注意が必要です。
また個人情報などの秘匿情報が含まれる場合は、当該箇所をマスクする、または記述を省略する等の処理を行ってください。
1) 想定動作 Amazonc Connectは振る舞いの幅が広いので、円滑なコミュニケーションを取るためにも事前にしっかり説明しておくと良いです。 2) 事象の発生日時 下記データモデルの`ConnectedToSystemTimestamp`。タイムゾーンの記載も必要です。 例:11月 12, 2021, 12:34:56 午前 (日本時間) https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/ctr-data-model.html#ctr-ContactTraceRecord 3) コンタクト ID 下記データモデルの`ContactId` https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/ctr-data-model.html#ctr-ContactTraceRecord 4) 問い合わせフロー 下記を参考にExportできます。 https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/contact-flow-import-export.html#how-to-import-export-contact-flows 5) 問い合わせフローのログ Amazon CloudWatchで問い合わせフローのログが確認できます。 ログが見当たらない場合は、有効化の設定を確認してみてください。 https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/contact-flow-logs.html
Amazon Connectの見積もり
今回の記事との関わりは薄いのですが、機能実装にあたり概算の見積もりをした際に便利だったツールも記載しておきます。
https://connect-mitsumori.serverworks.co.jp/
まとめ
この記事では、Amazon Connectの音声問い合わせのデバッグとその過程で得られた知見を共有しました。 Amazon Connectはできることの幅が広くデバッグの方法もその分多彩なので、用途に合わせてしっかりドキュメントを読んで事前の準備をしておきましょう。