Amazon Connectで保存されたコンタクト属性を処理するための構成3選
2024.12.24はじめに
Amazon Connectフロー内で[コンタクト属性の設定]ブロックを使用して保存したコンタクト属性に対して処理を行う方法について、3つの構成をご紹介します。
[コンタクト属性の設定]ブロック
[コンタクト属性の設定]ブロックに保存したコンタクト属性に対して処理したい場合、以下の３つの構成が考えられます。
- フロー内でLambdaを呼び出す
- コンタクト属性の保存をトリガーにEventBridge経由でSFを起動する
- 終話後、KDS経由でSFを起動する
[コンタクト属性の設定]ブロックに保存する例として、コンタクトセンターで対応可能なオペレーターが不在の場合を挙げます。
この場合、Amazon Connectフロー内でAmazon Lexボットを呼び出し、ユーザーからのお問い合わせを自動でヒアリングします。
その後、ヒアリング内容をコンタクト属性（キー名をrecordingとします）として保存し、Amazon Bedrockを使用して整形した上で、管理者にメール通知を行うという流れです。
1. フロー内でLambdaを呼び出す
１つ目の方法は、フロー内でLambdaを呼び出す方法です。
これは、Connectフロー内で、[コンタクト属性の設定] ブロックの後に、[Lambdaを呼び出す]ブロックを設定します。Lambdaでは、コンタクト属性を取得し処理を開始します。
この構成の構築方法は、以下の記事をご参照ください。
構成としては以下です。
Lambdaを呼び出す方法の利点は、Lambdaが処理した内容をフロー内で直接利用できる点です。
ただし、ブロック内で呼び出すため、Lambdaが処理を行っている間、ユーザーを待たせてしまう可能性があります。また、Lambdaのタイムアウトには最大8秒という制限がある点にも注意が必要です。
さらに、Lambdaのコードを開発する必要があります。
2. コンタクト属性の保存をトリガーにEventBridge経由でSFを起動する
Connectフロー内で、Lexでヒアリングした内容を[コンタクト属性の設定] ブロックに保存した時、ConnectからそのイベントがEventBridgeに送信されるので、EventBridge経由でStep Functions起動して処理します。
この構成の構築方法は、以下の記事をご参照ください。
構成としては以下です。
コンタクト属性を処理できない可能性がある
Connectの問い合わせイベントは基本的にEventBridgeに送信されますが、ベストエフォート方式であるため、まれに配信されない場合があります。この点には注意が必要です。
Step Functionsの処理やフローが複雑になる
構築方法のブログにも記載しておりますが、EventBridgeへ送信される問い合わせイベントにはコンタクト属性は含まれない仕様のため、問い合わせイベントに含まれるコンタクトIDとConnectインスタンスIDをStepFunctionに渡し、コンタクト属性を取得する処理を挟む必要があります。
さらに、[コンタクト属性の設定]ブロックの前に[コンタクトのタグ]ブロックを追加し、EventBridgeのイベントパターンにそのタグを設定する必要があります。
理由としては、タグでフィルタリングしないと、Lexの文字起こし内容を[コンタクト属性の設定] ブロックで定義しますが、他の[コンタクト属性の設定] ブロックでもEventBridgeが発火するためです。
後続のフローでも[コンタクト属性の設定] ブロックが存在する場合、[コンタクト属性の設定] ブロックの前に[コンタクトのタグ]ブロックを追加し、タグを解除する必要があります。タグを解除しないと、後続の[コンタクトのタグ]ブロックでもEventBridgeが発火するためです。
タグの解除
上記の4つのブロックを例に挙げていますが、「プロンプトの再生」の後に「コンタクトのタグ」ブロックでタグを解除する理由は、問い合わせイベントが順番通りに配信されるとは限らないためです。
EventBridge イベントは順序付けされていませんが、データの使用に役立つタイムスタンプがあります
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/contact-events.html#subscribe-contact-events
実際に、「プロンプトの再生」の前に「コンタクトのタグ」ブロックを設置してタグを解除すると、「コンタクト属性の設定」でrecordingキーを設定した際に、EventBridgeからStep Functionsが起動しませんでした。
これは、おそらく recordingキーの保存イベントよりも先に、タグ解除イベントがEventBridgeに送信されたためと推測されます。
このように、フローや処理が複雑化してしまう点がデメリットです。
3. 終話後、KDS経由でSFを起動する
Connectフロー内で、Lexでヒアリングした内容を[コンタクト属性の設定] ブロックで定義した後、終話後、問い合わせレコードがKinesis Data Streams（以降、KDS）にストリーミングされるので、EventBridge Pipes経由でStep Functionsステートマシンを起動して処理します。
この構成の構築方法は、以下の記事をご参照ください。
構成としては以下です。
問い合わせレコードは確実にKDSへ配信されますが、重複して配信される可能性があります。
Amazon Connect は、少なくとも 1 回問い合わせレコードを配信します。
問い合わせレコードは、最初の配信後に新しい情報が到着するなど、複数の理由で再度配信される場合があります。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/ctr-data-model.html#important-things-to-know-ctr-data-model
また、KDSの設定はConnectインスタンス単位で行われるため、有効化すると他のフローもKDSに配信されます。そのため、Step Functions側で他のフローの処理も適切に対応できるよう考慮が必要です。
例えば、特定のコンタクト属性が存在しない場合には、処理を終了するなどの対応が考えられます。
さらに、KDSにはランニングコストが発生します。最も費用が少ない設定は、プロビジョニングモードでシャード数を1に設定した場合です。東京リージョンでは、この設定で月額14.04 USDのコストがかかります。
- 0.0195 USD /時間 * 24時間 * 30日 = 14.04 USD
比較
3つの構成のまとめです。
| 項目 | 1. Lambda | 2. EventBridge→SF | 3. KDS→SF |
|---|---|---|---|
| 同期/非同期 | 同期（フロー中に処理を行い、処理結果をフローに反映可能） | 非同期（通話中に処理を実行可能） | 非同期（通話終了後に処理を実行） |
| 最低ランニングコスト | 0 USD | 0 USD | 最小14 USD |
| コード | コードの開発が必要 | ローコード | ローコード |
| 考慮点 | 最大8秒間、Lambdaの処理が完了するまでユーザーを待たせる必要がある | ・ EventBridgeにイベントが送信されない可能性がある ・ フローや処理が複雑になる |
・ 他のフローも含めてすべてKDSにストリーミングされ、SFが起動してしまう ・ 重複処理が発生する可能性がある |
終話後の処理で問題ない場合は、KDS+SFの構成が適しています。
一方、ランニングコストを抑えたい場合や、フロー内で処理を完結させる必要がある場合は、Lambdaの構成が適しています。
