この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AIソリューション部の平内です。
昨日、第22回 JAWS-UG札幌 勉強会でAmazon Connnectについて、お話する機会を頂きました。
スライド https://www.slideshare.net/furuya02/presentations
以下、その内容です。
1 Amazon Connect
Amazon Connect(以下、Connect)で提供可能なサービスは、大別すると以下の３つです。
Connectでは、他のAWSサービスと綿密に連携することが可能なため、これらを組み合わせる事で色々な仕組みを簡単に作ることができます。
以下は、Connectが直接つながっている各種サービスですが、LambdaやLexも利用可能であるため、その先の連携も考えると、外部のサービスも含めて、何でもできてしまいそうです。
2 IVRのみでの構築例
最初に、IVRで構築した例をいくつか紹介させて下さい。
(1) 居酒屋の予約
席だけの予約であれば、必要な情報は「人数」と「時間」ぐらいだと思います。 そして、店員が電話に対応するのは、少なからずコストもかかると思います。
そこで、「可能であれば無人でやっつけたい」という事で作成してみたものです。
次の図は、「居酒屋の予約」のコンタクトフローです。営業時間や無効な入力のバリデーション、そして、再入力など、比較的多くの分岐があるのですが、かなりシンプルなフローになっています。
コンタクトフローをシンプルなものにするため、ここではLambdaを中心としたフローにしています。
Lambdaでメッセージの作成や、その後の分岐を担い、それ以外は、可能な限り抽象化した数個の処理とします。 抽象化された処理を行った後は、切断以外の場合、すべて最初に戻ってLambdaに再突入させています。
バリデーションや、メッセージ作成は、全てLambdaで処理されます。
IVRによる仕組みを作成する場合のキーワードは、個人的に以下の２つだと感じています。
なお、Connectで使用するLambdaでは、セッション管理の仕組みはありませんので、コンタクトフローの属性を利用して、その仕組を自前で準備する必要があります。
参考：[Amazon Connect] IVRで無人の予約受付を作ってみました 〜居酒屋の予約の場合〜
(2) 電話アンケート
電話アンケートなどを軽易に作れる仕組みを考えてみました。
次のように、アンケート内容と、その選択肢を書いたファイルを用意して、S3などに置くことで、それを読み込んでConnectが動作するようにしています。
構成は、以下のとおりです。
IVRを回す主役は、S3に置かれたアンケートの内容を読み込んだLambdaです。アンケートの結果は、S3に保存され、そのタイミングで集計結果（グラフ表示）を更新します。
担当者が見ているブラウザの画面は、集計結果が変わるごとに、MQTTを利用した仕組みで更新されています。
参考：[Amazon Connect] 電話アンケートの仕組みを作ってみた 〜 S3に質問内容を置くだけで自動で集計してグラフ表示するのです〜
(3) ログの整形
IVRの仕組みを作ると、果たして有効に機能できているのか、少し心配になってきます。
Connectのログは、一応残すことができますが、１接続単位ではなく、ブロックごとのログであり、全体を見渡すには、やや辛いかも知れません。
そこで、データストリームとして出力されるエージェントイベントのログをトリガーに、CloudWatchLogsから、当該接続に関連するログを集めて、整形してS3に出力する仕組みを作ってみました。
一例として整形したログでは、IVRからのアナウンスとユーザーが入力した値を時系列に眺めることができます。
下記は、S3上に出力されている様子です。
参考：[Amazon Connect] IVRによる居酒屋の無人予約受付のログを整形してみました
参考：[Amazon Connect] 整形ログをKinesis Firehose経由で自動的に生成するようにしてみました
3 OUTBOUNDの構築例
続いて、OUTBOUNDで構築してみた仕組みを紹介させて頂きます。
(1) 電話番号を公開しないで効率的な発信を行う
キャンペーンなどで、顧客リストなどに一斉に電話をかける場面をイメージしています。
オペレーターが電話番号を入力するとなると、入力間違いが発生するコストが無視できません。また、顧客情報としての「名前」と「電話番号」の情報が、オペレーターに公開されることになってしまいます。
次の動画は、顧客情報からリストした作成したボタンを押すことで、次々発信を行えるようにしたものです。
発信は、顧客情報に基づいてAPIで行われるため、電話番号を間違えるリスクはありません。また、オペレーターに電話番号（個人情報）を知らせる必要もなくなります。
参考：[Amazon Connect] キャンペーンなどで電話をする時は、一覧をS3に置いて、クリックだけで次々発信できると便利かも
(2) 「興味あり」の顧客だけ接続する
アウトバウンドでは、その時の顧客の状況が分からないため、断られて話を聞いてさえ頂けない事は、一定数あるでしょう。
また、電話で話を聞くのは難しくても、興味はあるので、「後でかけ直して欲しい」とか「メールでの連絡は欲しい」みたいな顧客もあるかも知れません。
そこで、次のような仕組みを考えてみました。
発信は、自動発信で機械的に行ない、まずは、IVRだけで顧客の状況を確認します。そして、現在通話が可能であるという場合だけ、初めてオペレーターに繋ぐというものです。
顧客が現在対応可能である場合だけ、オペレーターに繋ぐようにしたものです。
こちらは、自動IVRで顧客の興味の状況を、自動発信で収集しているサンプルです。
収集されたデータ（興味あり・なし）は、顧客情報に蓄積され、後のセールスに利用されます。
仕組みとしては、顧客情報から自動発信して、IVRによよるユーザーの情報で、顧客情報のDBを更新するだけです。
4 INBOUNDの構築例
最後に、INBOUNDの構築例ですが、時間外の電話の対応と、留守番電話の仕組みを紹介させて頂きます。
(1) 時間外の対応
IUNBOUNDで受け付けるシステムでは、２４時間３６５日オペレーターを配置することは、現実的に不可能でしょう。しかし、機会損失があることは否定できません。
次のように、営業時間外に入った電話は、蓄積しておいて、次の営業日に、管理者に纏めてメールで送ったり、アウトバウンドキューに入れておいて、オペレーターが出勤したら、そのキューを順次処理するというような仕組みが考えられます。
詳しくは、下記のリンクを辿って見て下さい。
参考：[Amazon Connect] 営業時間外（夜間など）に着信した電話を翌日折り返す超簡単なコールバックシステム
参考：[Amazon Connect] 営業時間外に着信した電話番号の一覧を、翌朝メールで受け取る仕組みを作ってみた
(2) 留守番電話で受け付ける
留守番電話を利用して受付を無人化する例として「企業内のシステムサポート」を考えてみました。
電話対応が本来の業務でない場合、可能であれば自動化したい。しかし、IVRだけで受け付けると、なかなか色々が事象への対応が難しい。
そこで、自由な入力のために録音機能を使用し、受け付けた内容（録音データ）は、テキスト化して、既存のチャットなどに流すようにしたものです。
実は、Connectでは、留守番電話の機能がありません。（ユーザーとオペレーターが接続された状態での会話しか録音できない）
そこで、最初に受け付けたコンタクトフローで録音を開始し、擬似的にオペレーターが対応するように作り込み、新たに、別のコンタクトフローでIVRを構築しています。
構成は以下のようになっています。S3に蓄積された録音データは、テキスト化し（現時点で日本語に対応した文字起こしがAWSでできないため、Watson Speech To Textを利用させて頂きました） ユーザーの発信番号などの情報とともに、チャットに投稿しています。
参考：[Amazon Connect] 留守番電話形式で無人受付のサポートデスクを作ってみました 〜録音されたメッセージは、チャットに投稿されます〜
5 検討が必要だと感じる事項
現時点で私が感じている検討が必要な事項を、思いつくまま列挙してみました。（時間の関係で列挙のみとさせて頂きました）
6 最後に
Connectを使用すると、他のAWSサービスなどと組み合わせて、色々な仕組みを簡単に作れると思います。
AWSのAI関連サービスは、まだ、日本語対応されていないものが多数あります。
- Amazon Lex 音声対応ボット
- Amazon Transcribe 文字起こし
- Amazon Comprehend 感情分析
これらが、日本語で利用可能になってくると、もっと夢のあるシステムが構築可能になるかも知れません。
今回のセッションが、何かのヒントになれば幸いです。
弊社では、３月に「無料Amazon Connectハンズオンセミナー」を開催致します。導入を検討されておられる方は、是非、お申し込み下さい。
また、音声を利用した各種ソリューションの導入支援を行っております。お気軽にお問い合わせください。
46
