Amazon Web Services ブログ

Category: Messaging

[AWS Black Belt Online Seminar] Amazon Connect Update 資料及び QA 公開

先日 (2019/12/17) 開催しました AWS Black Belt Online Seminar「Amazon Connect Update」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20191217 AWS Black Belt Online Seminar Amazon Connect Update AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. エージェント間でチャットはできますか? A. CCP を使ったエージェント間のチャットはできません。エージェント間のチャットについては、Amazon Chime などの利用をご検討ください。 Q. チャットの顧客名が入力必須とのことですが、顧客は Guest 状態でのチャットができないということでしょうか。 A. 項目としては必須ですが、カスタマー Web サイト側でチャットを開始する際に顧客名を Guest や Anonymous などにすることは可能です。ただし、その場合はお客様ごとのルーティングや、お客様名での検索等を行うことはできませんのでご留意ください。 — 今後の AWS Webinar | イベントスケジュール 直近で以下を予定しています。各詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 — AWS re:Invent サービス・ソリューション別 RE:CAP AWS […]

Read More

Contact Lens for Amazon Connect (Preview)

12月3日、AWS は Contact Lens for Amazon Connect を発表しました。これは、機械学習(ML)によって実現される Amazon Connect の機能セットであり、重要な顧客フィードバックを特定し、顧客体験を改善するために、顧客との会話の内容、感情、傾向を理解する手段をコンタクトセンターのスーパーバイザとアナリストにもたらします。Amazon Connect は、Amazon の受賞歴のあるカスタマーサービスを支えるのと同じテクノロジーが用いられたオムニチャネルクラウドコンタクトセンターサービスです。 Intuit、GEアプライアンス、Capital One、Dow Jonesなどの企業は、Amazon Connectを使用して数千のエージェントを容易にスケーリングしながらコンタクトセンターを低コストで運営しています。   コンタクトセンターは毎日大量の顧客との会話を行うため、何百万時間もの通話が記録されます。企業は、これらのコールの正確なトランスクリプト(会話の文字起こし)を取得し、すべてのコールを検索して、問題、共通のテーマ、エージェント・コーチングの機会を特定できるようにしたいと考えています。既存のコンタクトセンター分析サービスを使用できますが、これらのツールはコストが高く、トランスクリプトの提供に時間がかかり、必要な精度が不足しています。そのため、顧客の問題を迅速に検出し、エージェントに実用的なパフォーマンスフィードバックを提供することが困難になります。また、既存のツールがリアルタイム分析を提供できないため、通話中に不満を感じた顧客が電話を切る前にそのようなコールをスーパーバイザが特定して支援することができなくなります。このような課題に対して、企業の中には時間をかけてデータサイエンティストやプログラマを雇い、機械学習技術を適用してカスタムアプリケーションを管理していくところもあります。   Contact Lens for Amazon Connectは、これらの課題に対処し、コンタクトセンターのスタッフが数クリックで機械学習のパワーを簡単に利用できるような従来の枠を超えるエクスペリエンスの一部として、機械学習の分析セットを簡単に有効にできる機能を提供します。Contact Lens for Amazon Connectの使用は簡単です。問い合わせフロー設定で分析するコールを設定するには、「通話記録動作の設定」ブロックの「Contact Lens for Amazon Connect」オプションをチェックします。設定が完了すると、Contact Lens for Amazon Connectは指定されたコールの分析を自動的に開始します。ここをクリックして、プレビューにサインアップできます。   それでは、顧客との会話の分析にContact Lens for Amazon Connectがどのように役立つのかを見てみましょう。   1. 問い合わせ検索の強化:   Amazon Connectの問い合わせの検索ページでは、日付範囲、エージェントのログイン、電話番号、キューなどの条件に基づいて履歴の問い合わせを検索できるようになりました。Contact Lens for Amazon Connect では、指定されたすべてのコールは、最先端の機械学習技術を使用して自動的に文字起こしされ、自然言語処理エンジンを使用して感情を抽出し、検索用にインデックス化されます。したがって、コンタクトセンターのスーパーバイザおよびアナリストは、問い合わせの検索ページから、コール中に顧客やエージェントが言及した単語やフレーズに基づいて問い合わせが特定できるエクスペリエンスをすぐに使用できるようになります。コールで話された内容に基づいて問い合わせを検索できるため、組織は顧客に影響を与えている問題を深く掘り下げることができます。たとえば、ある組織は、自社製品の1つに対して最近発売されたプロモーションコードが機能していないことに気付きました。顧客がこの問題について問い合わせのどの部分で言及したかを検索することで、問題の重大度を把握し、プロモーションコードが失敗した状況を正確に診断することができました。 […]

Read More

Amazon SNS, Amazon SQS, AWS Lambda のデッドレターキューによる耐久性のあるサーバーレスアプリケーション設計

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]

Read More

[AWS Black Belt Online Seminar] Amazon Simple Queue Service (SQS) 資料及び QA 公開

先日 (2019/07/17) 開催しました AWS Black Belt Online Seminar「Amazon Simple Queue Service (SQS)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190717 AWS Black Belt Online Seminar Amazon Simple Queue Service AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. AWS LambdaでサポートされたAmazon SQSに対するポーリングはどういう方式になりますか? A. 以前はLambdaを定期的に起動し、かつ、SQSに対してポーリング処理を実装する必要がありました。2018年6月にリリースされたAWS Lambdaの新機能により、Amazon SQSがAWS Lambdaのイベントソースとして加わり、LambdaがSQSにロングポーリングをしてメッセージの到着イベントをもとに関数を起動するようになりました。なお正常終了するとキューからメッセージをLambdaが削除します。 構成方法等はこちらをご覧ください また、SQSと連携する場合のAWS Lambdaのエラー発生時の挙動についてはこちらに記載がありますので併せてご確認ください。 Q. 過去のAWS Black Belt Online Seminarの動画は見れますか? A. こちらで、YouTubeをご確認いただけます。 Q. 同期処理の場合に利用できるマネージドサービスにはどのようなものがありますか? A. メッセージングサービスは非同期型になりますが、例えば、HTTP(S)の負荷分散サーバであるELBや、API環境を構築するAmazon API Gatewayは同期型で処理が可能です。 — 今後の AWS Webinar […]

Read More

[AWS Black Belt Online Seminar] Amazon Simple Notification Service (SNS) 資料及び QA 公開

先日 (2019/6/4) 開催しました AWS Black Belt Online Seminar「Amazon Simple Notification Service (SNS)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190604 AWS Black Belt Online Seminar Amazon Simple Notification Service (SNS) AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. SNS と Pinpoint との違いを教えて欲しい。 A. アプリケーション統合の目的でpub-subを実現したい場合はAmazon SNSをご利用ください。 mobile pushの用途で、より顧客エンゲージメントに関するマネージドな機能(分析、セグメントプッシュ、キャンペーン)を利用したい場合はAmazon Pinpointをご利用いただくのがお勧めです。またこれから新規にmobile push機能を利用される場合には、より新しいサービスであるAmazon Pinpointを選択して始めてみるのが、顧客エンゲージメント機能の独自実装が不要なため簡単です。Amazon SNSはデバイストークンを独自にデータベースで管理する必要があり、運用面のアーキテクチャも考えなければならない箇所が多くなります。一方、独自にデバイストークンのライフサイクルを管理したいといった要求がある場合には、Amazon SNSを選択することもできます。 Amazon PinpointはSMSの双方向送信が可能ですが、Amazon SNSは購読解除時以外に逆方向のSMSを受け付けることはできません。 Q. アンスクライブリンクの消し方について、ベストプラクティスはありますか? A. AWS CLIを使ってサブスクリプション解除されないようにできます。詳細はAWS公式サイトを参照ください。 Q. ブラックリストとホワイトリストの併用はできますか? A. サブスクリプションフィルターポリシー内の属性名が異なれば併用は可能です。詳細はAWS公式サイトを参照ください。 — […]

Read More

[AWS Black Belt Online Seminar] Amazon Simple Email Service (SES) 資料及び QA 公開

先日 (2019/5/21) 開催しました AWS Black Belt Online Seminar「Amazon Simple Email Service (SES)」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190521 AWS Black Belt Online Seminar Amazon Simple Email Service (Amazon SES) AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. 一般的に、SPF、DKIMやそれらに基づいたDMARC準拠を実施すれば、メールのセキュリティ対策としては十分なのでしょうか。 A. 大事なのは相手先メールサービスも関係しているいうことです。どれがいいのか?これで十分なのか? ではなく、やれることは全てやっておいた方がより安定する可能性があるということです。 SPF, DKIM, DMARC だけに限りません。 Q. SESのバウンス例はバウンス処理をする為にあの構成を組まないといけないということですか? A. あくまでバウンス処理の構成例となります。必ずそのような構成にしなければならないわけではありません。お客様がバウンス処理を実装する際のお役に立てればと思います。 Q. SES での受信メールにLambdaをアクションさせています。大量mailを受信したとき、S3への書き込みやLambdaのスロットリングエラーが発生した時は、何のErrorで確認できますか ? また、Error リトライはどうなりますか ? A. CloudWatch にて、PublishFailure/PublishExpire メトリクスをご確認ください。 4 時間以内にアクションが成功しなかった場合、PublishExpire となり、バウンスメールが送信元へ送られます。 […]

Read More

Amazon Connectのスケジュールされた レポートを自動的に送信する

コンタクトセンターではデータが重要です。 スーパーバイザとマネージャは、レポートを使用して、チームのパフォーマンスを確認し、要員配置の計画を立てます。 必要なときに必要なデータを人々に提供することは不可欠です。 このブログ記事では、レポートの生成を有効にしてEメールで自動的にユーザーに送信する方法について説明します。 以下のサービスを使用します。 Amazon S3 AWS Lambda Amazon SES Amazon CloudWatch with Amazon Connect このブログでは、 AWS CloudFormationを使用してデプロイを簡素化する方法についても説明します。 このブログのソリューションでは、 Amazon Connectのネイティブレポート機能を使用してレポートを設定およびスケジュールします。 そのスケジュール設定されたレポートは、Amazon Connectの設定で指定したS3バケットに作成されます。 レポートがS3に作成されると、Lambda関数を起動するイベントが発生します。 Lambda関数はイベントを読み取り、S3からレポートを取得して、指定されたEメールアドレスに送信します。 すべてのアクティビティは追跡目的でCloudWatchに記録されます。 では始めましょう。 このセットアップを完了するには、次のものが必要です。 アクティブなAWSアカウント us-east-1(バージニア北部)またはus-west-2(オレゴン)のいずれかにあるAmazon Connectインスタンス。 Amazon SESはこれらのAmazon Connectリージョンでのみ使用可能であるため、この設定ではこれら2つのリージョンのみがサポートされています。 インスタンスを作成したら、電話番号を取得します。 詳細については、Amazon Connect の使用開始を参照してください。 あなたのアカウントに設定されたAmazon SES。 このソリューションでは、Amazon SESを使用してレポートを指定の受信者にEメールで送信します。 SESを使用してEメールを送信するには、送信元アドレスを確認して、自分が所有者であることを示します。 サンドボックスにいる場合は、 送信先アドレスも確認する必要があります。 あなたは、Eメールアドレスまたはドメイン全体を確認することができます。 検証プロセスについては、Amazon SES のIDの検証を参照してください。 アカウントをサンドボックスから削除する方法については、Amazon SES サンドボックスの外への移動を参照してください。 このCloudFormationテンプレートを実行するための適切なIAM権限。 これには、IAMロールとLambda関数を作成する権限が含まれます。 […]

Read More

Elasticsearch と Kibana を使って Amazon Connect のデータをリアルタイムに活用する

このブログポストでは、Amazon Elasticsearch Service (Amazon ES) と Kibana を使って、どのように Amazon Connect コンタクトセンターでリアルタイムなデータ分析を行うかを紹介します。問い合わせ対応時間やサービスレベル、問い合わせの効率具合、エージェントのパフォーマンス、顧客満足度など、様々なサービス・メトリクスを改善するためにコンタクトセンターのパフォーマンスをモニタリングできます。 加えて、Amazon ES を使って問い合わせ追跡レコード (CTR) 、エージェントのイベント・ストリーム、Amazon CloudWatch で取得できる問い合わせフローログを処理し、Kibana を使ってリアルタイムに近い形で可視化するソリューションも紹介します。Elasticsearch はオープンソースの、分散システムの検索と分析のエンジンで、ログ分析や全文検索に利用されています。Kibana はデータ集約と可視化のツールです。Amazon ES と Kibana を用いて、リアルタイムにデータを検索、可視化、分析、洞察することができます。 Amazon Connect は顧客とのやり取りで発生したイベントの詳細をリアルタイムに問い合わせフローログとして提供します。問い合わせフローとは顧客が問い合わせを行ったときの顧客体験を定義したもので、再生するプロンプトや顧客からの入力、問い合わせキューの転送などを定義します。 さらに、Amazon Connect は 分析用にデータをエクスポートするために CTR を Amazon Kinesis Data Firehose に、エージェントのイベントを Amazon Kinesis Data Streams にストリーミングできます。CTR は Amazon Connect インスタンスで発生するイベントや、属性、キュー、エージェントのやり取りをキャプチャーしたものです。エージェントのイベントは、Amazon Connect インスタンスにて起こる、ログイン、ログアウト、ステータスの変更といったエージェントのアクティビティを記録したものです。 ソリューション概要 以下の図は Amazon Connect からの問い合わせフローログや CTR、エージェントのイベントを処理し、Amazon […]

Read More

Amazon Connectで作るセキュアなIVRソリューション

Amazon Connectで作るセキュアなIVRソリューション Amazon Connectの問い合わせフローを使用して、ダイナミックな自動音声応答(IVR)ソリューションを作成できます。 Amazon Connectを使用すると、適切に個人情報を収集し、IVRによる顧客体験をカスタマイズすることができます。 個人情報として、社会保障番号、クレジットカード情報、および住所などが考えられます。 コンプライアンス上の理由から、個人情報など機密性の高い情報は通信時および保管時に暗号化する必要があります。 常に個人情報は暗号化しましょう。 このブログでは、Amazon Connectの[顧客の入力を保存する]ブロックを使用して機密な個人情報を収集し、ご自身でお持ちの暗号化キーを使用してデータを自動的に暗号化する方法について説明します。 この機能により、暗号化の要求に応えることができます。 この目的のために、Amazon ConnectはAWS Encryption SDKを使用して顧客提供データを暗号化します。 SDKはエンベロープ暗号化アプローチを使用します。 これにより、生データとそれらの暗号化に使用されるデータキーの両方が保護されます。 AWS Encryption SDKの機能の詳細については、Envelope Encryptionを参照してください。 この記事では、以下の手順を説明しています。 クレジットカード番号を収集するようにAmazon Connectを設定します。 クレジットカードの番号を暗号化します。 ご自身でお持ちの復号化キーを使って復号化するために、バックエンドのAWS Lambdaに暗号化されたクレジットカード番号を送信します。 次の図に示すAmazon Connect問い合わせフローを使用します。 セキュアなIVRの作成 このセキュアなIVRを作るために、以下を実施する必要があります。 新しい暗号化キーと復号化キーを作成するか、既存のものをインポートします。 復号化キーをAWSパラメータストアに安全に保存する 収集した番号を復号化するためのAWS Lambda関数を作成します。 収集したクレジットカード番号を暗号化するために、Amazon Connectに公開鍵をアップロードします。 前のセクションで説明した問い合わせフローを作成します。 注意 セキュアなIVRを作るために、AWS Command Line Interface(AWS CLI)がインストールされ、セットアップされ、Amazon Connectインスタンスと同じリージョンに設定されていることを確認しましょう。 ターミナルウィンドウから“ aws configure”を実行できることを確認し、デフォルトのリージョンパラメータに正しい値が設定されていることを確認します。 Amazon Connectの顧客入力を暗号化する機能は、ご自身でお持ちの公開鍵を使用してデータを暗号化するように設計されています。 これにより、自分の秘密鍵を使用してデータを復号化し、データを後続処理に利用できます。 顧客だけが知っている秘密鍵を使用すると、要求されるプライバシーを保護するのに役立ちます。 既存の鍵ペアを使用することも、新しい鍵ペアを作成することもできます。 鍵情報が利用可能であるかぎり、このプロセスは変わりません。 […]

Read More

Amazon Connectインスタンスへの迷惑電話を特定し対処する

我々はAmazon Connectによって強化されたコンタクトセンターを展開してきました。 あなたは今、顧客から電話で問い合わせを受けています。 素晴らしいことです。 ただし、迷惑電話が増えてきていることにも気付いています。 それはあまり素晴らしいことではありません。 このブログでは、発信者の番号に基づいてこの不要な着信通話の発信者を識別するソリューションを構築する方法をご紹介します。 着信を識別して対処するステップ まず、Amazon DynamoDBに電話番号のリストを作成し、Amazon Connectにすべての着信呼び出しについてこのリストをチェックさせます。 Amazon Connectがこのリストにアクセスするために、AWS LambdaをAmazon Connect問い合わせフローと統合します。 その後、すべての着信呼び出しに対してそのLambda関数を実行します。 AWS Lambdaは、着信呼び出しの番号についてデータベースを検索します。 一致したレコードが見つかった場合に問い合わせフロー内で別のパスへルーティングできるようにするために、AWS Lambdaはレコードの一致を示す値を返します。 このプロセスの4つのステップは以下のとおりです: Amazon DynamoDBにテーブルを作成する AWS Lambdaを使用して番号データベースを検索する 問い合わせフローでAWS Lambdaを使用するようにAmazon Connectを設定する Amazon Connectに返される値を確認する ステップ1:Amazon DynamoDBにテーブルを作成する Amazon DynamoDBコンソールを開きます。 テーブル作成を選択します。 [テーブル名]に、filteredNumbersと入力します。 プライマリキーにphoneNumberと入力します。 デフォルト設定を使用をチェックしたままにして、作成を選択します。 テーブルを作成したら、ブロックする電話番号を追加します。filteredNumbersを選択し、項目タブを選択し、「項目の作成」を選択します。 国際的に認められたE.164形式で電話番号を入力してください。 たとえば、北米の場合は+ 15551234567などです。 ブロックする番号を入力してから、保存を選択します。 ブロックするすべての番号について手順6を繰り返します。 注意 電話番号を入力するこれらの手順では、番号を個別に入力する必要があります。 電話番号をまとめて追加する方法については、DynamoDB CLIリファレンスを参照してください。 ステップ2:AWS Lambdaを使用して番号リストを検索する AWS Lambdaは、Amazon ConnectとAmazon DynamoDBテーブルをつなぐパイプの役割を果たします。 Amazon […]

Read More