Category: Amazon Lex*


Amazon Lex を使った Bot の作成

Jeff Barr がブログでの紹介の投稿でご説明したように、Amazon Lex は、開発者が音声とテキストを使用してアプリケーションで対話式のインターフェイスを構築できるようにするサービスです。Amazon Lex を使うと、すべての開発者が Amazon Alexa に採用されている深層学習技術と同じ技術を利用し、自然言語での高度な対話ボット (チャットボット) を短時間で簡単に構築できるようになります。Amazon Lex では、自動音声認識 (ASR) という音声をテキストに変換するための高度な深層学習テクノロジーと、テキストの意図を理解するための自然言語理解 (NLU) を利用できます。これにより、ユーザーにとって使いやすく魅力的なアプリケーションを構築できます。

では、Amazon Lex で機能的なチャットボットを開発するには、どうすればいいでしょうか。ドキュメント内の例の 1 つを利用すれば、1、2 分でチャットボットを使用してやり取りを開始することができます。もちろん、これはきっかけにはなりますが、まったく十分とはいえません。では、チャットボットを構築するために、何をする必要があるかを見てみましょう。

基本

チャットボット設計は、確立基準がほとんどない発生期の領域です。実際のユーザーとやり取りしなければ、何が面倒で何が快適かを理解することはできません。このセクションは、ボット設計のガイドではなく、設計上の考慮事項を探るものとして扱うことをお勧めします。以下は、Amazon Alexa との何百万回ものやり取りから学んだことです。

Simon Sinek はチャットボットがなぜ存在するかという疑問から始めることを奨励しています。優れた設計は明確な目標から始まります。それにはまず、ユーザーがどんな人か、何を達成しようとしているのかを理解する必要があります。

また、モダリティとミディアムのことも考える必要があります。音声インターフェイスは確かに便利ですが、ユーザーが注意を払っていなかったり、単に聞こえていなかったりすることも想定して、最後のプロンプトを繰り返したり、「何?」とか「どこまでいったっけ?」といった反応にも適切に対応できなければなりません。テキストのインターフェイスでは、これは不要でしょう。一部のテキストインターフェイスでは、画像とボタンの付いたレスポンスカードもサポートされています。

インターフェイスを設計する者にとって、強調は不可欠な手法です。これは、情報を提示したり、特定の選択肢を推奨する基準となります。明確性を実現するための規則はモード (ウェブ UI かチャットか音声か) によって異なります。目標とモードに応じて、強調のためのツールは異なる可能性があります。次の例を見て、3 つのそれぞれのモードにおける注文方法について検討してみてください。

 o_bots_1 これで注文してよろしいですか。 (はい/いいえ) ____ を注文したいとのことですが、それでよろしいですか。 
ウェブ (ポイントアンドクリック) チャット (テキスト) 言語 (音声認識)

ウェブの場合、「注文を確定する」を強調することで、それが推奨される選択肢であることを明確化し、このアクションによって顧客が注文にコミットすることを確認する必要があります。チャットでは、オプションを括弧で囲むことで、ユーザーに何が期待されているかを示すのが慣例となっています。また、テキストの配置や空白文字、大文字などで強調することもできます。

音声操作では、このような慣例に代わって、注文がいつ実行されるかをユーザー自身がコントロールしていることを保証する新しい基準が必要となります。たとえば、注文に大幅な変更がある場合は、確認することができます。さらに、音声の場合、強調のためにゆっくりと話すなど、話す速度をコントロールすることも可能です。他の方法が使用できない場合は、単に繰り返すだけでもかまいません。以下の例を見てみましょう。

ご注文の合計額は 55 ドルです。

この注文を実行して、このアカウントに登録されているカードに 55 ドル課金してよろしいですか。

 
  音声 – 強調のための繰り返し  

CoffeeBot の構築

ボイスボットを使用して、あまり一般的に使用されることのない言葉を含む会話 (たとえば、カフェラテを注文するときの「トリプルモカをお願いします」など) をサポートする必要があるとします。もちろん、ボットに命令するのがお好きな方は、「トリプルモカ、頼む」と言ってもかまいません。

ここでは、Amazon Lex コンソールを使用してカスタムボットを作成してみましょう。これを「CoffeeBot」と呼んで、Amazon Lex を呼び出すための適切なアクセス許可を持つ IAM ロールを使用します。この実行手順については、『Amazon Lex 入門ガイド』を参照してください。

 

Lex の用語

Jeff がブログで説明したように、Amazon Lex ではインテントやスロットタイプ、スロットが使用されます。再利用可能性を促進するために、インテントとスロットタイプは AWS アカウントに関連付けられ、複数の Amazon Lex ボットによって使用されます。変更を実行するに従い、Amazon Lex がそれらリソースのバージョンを自動的に追跡することがわかると思います。そのため、テストしている特定のバージョンのボットに何が使用されているかを正確に把握できます。これは一見、それほど大事でないことのように感じられるかもしれませんが、並列開発と継続的開発の両方をサポートすることは極めて重要なことです。

会話の流れ

新しいボットを開始する際には多くの場合、1 つのタイプのリクエストで通常どのような会話が行われるかを録音し、それらのリクエストを分析して、より広範なリクエストの場合を推定することが有効です。CoffeeBot では、人々がコーヒーショップでどのようにモカを注文するかに焦点を当てることにします。

実際の会話 会話のフェーズ インテントと代替案

いらっしゃいませ。ご注文はお決まりですか。

> えっと、ノンファットモカをお願いします。

挨拶と最初のリクエスト

– 飲み物のタイプ: モカ

– 飲み物のサイズ: ラージ

– クリーマー: ノンファット

飲み物のタイプのみから始めることも別の組み合わせから始めることも可能。

アイスにしますか。

いいえ、いいです。

設定

– 飲み物の温度: ホット

ホットかアイスだけか。他の値はあり得るか。

チョコレートはどうなさいますか。

ダークで。

設定

– チョコレートのタイプ: ダーク

すべての飲み物にチョコレートが必要なわけではない。モカだけか。

ホイップクリームはどうなさいますか。

いいです。

設定

– ホイップクリーム: いいえ

ホイップクリームにはいくつかの種類があるか。

他の飲み物やサイズに変更する可能性は?

かしこまりました。ラージ、シングルダーク、ノンファットモカ、ホイップクリームなしですね。

> あっ、トフィーを 1 ポンプ追加してもらえますか。

確認 → 設定

– フレーバー: トフィー 1 ポンプ

ここで承認することもできた。フレーバーを 2 種類に増やすことは可能か。制限はあるか。

かしこまりました。ラージ、シングルダーク、ノンファットモカ、ホイップクリームなしで、トフィーを 1 ポンプですね。お名前は?

ジェニーです。

確認 → ラベル

– 名前: ジェニー

優先客として名前をアプリに保存

ありがとうございました。ご用意でき次第、そちら右側のカウンターでお渡しいたします。4 ドル 17 セントになります。他はよろしいですか。

いいです。

清算 このための課金オプション。

5 ドル、お預かりいたします。83 セントのお返しです。どうもありがとうございました。

> どうも。

清算 → 完了

placeOrder:  name, beverageConfig

– バックエンドで注文を実行

– 確認メールを送信?

– ポイント獲得?

実際の注文は、このモカの例よりずっと複雑で、10 万種類以上のコーヒー飲料が存在する可能性があります。自然な会話は決まった順序に進まないし、会話の途中でユーザーの気が変わったり、ユーザーが会話の一部をスキップする可能性もあります。このような流れの柔軟さが自然な会話の特徴です。

ではここで、CoffeeBot が「ダブルショートモカ」と聞いた場合を考えてみましょう。この場合、ユーザーは「エスプレッソダブルのショート (8 オンス) モカ」を頼んだのでしょうか。それとも実際にはサイズには触れずに「ダブルショットモカ」を頼んだのでしょうか。今一度、入力を憲章する必要があります。このシリーズの次の投稿では、入力の検証についてお話しします。

会話のインターフェイスを設計する際、的を絞ることが重要です。これまでにお話しした複雑性の一部は、ユーザーが誰かを「認識」し、支払いを処理できるアプリから始めることで自然と解消されます。特に寒い日や雨の日などには、天気の話を会話のトピックに含めてもいいでしょう。このようなたわいもない話をモデル化することは楽しいかもしれませんが、時間を最も有効に使っているとはいえないでしょう。あればいいなと思うものではなく、ユーザーエクスペリエンスを大幅に強化する開発作業に焦点を当てましょう。

会話: 情報

上記のような分析は、会話の構造を明らかにするものです。情報の断片は個別に共有することも一緒に共有することもできます。また、多数の可能な順序の 1 つとして共有することもできます。さらには、一定の飲み物のアドオンをオプションとして追加することも可能です。しかし最終的には、モカを注文するために認識されなければならない特定の値セットがあります。これまでに解明した情報の重要なサブセットに対応し、これらのスロットがフィードバックループを使用し時間をかけて洗練されていくのだということを理解したうえで、まずは CoffeeBot の一部のスロットタイプから開始します。

開発チームは共有リソースを検出しやすいように独自の規則を作成しますが、ここでは「cafe」をプレフィックスとして使用します。

スロットタイプ スロット値
cafeBeverageType コーヒー; カプチーノ; ラテ; モカ; チャイ; エスプレッソ; スムージー
cafeCreamerType 2 パーセント; ノンファット; ソイ; アーモンド; ホールミルク; ハーフアンドハーフ
cafeStrength シングル; ダブル; トリプル; クアッド; クアドラプル
cafeFlavor バニラ; アーモンド; フレンチバニラ; キャラメル; ヘーゼルナッツ
cafeBeverageSize キッズ; スモール; ミディアム; ラージ; エクストララージ; ショート; 6 オンス; 8 オンス; 12 オンス; 16 オンス; 20 オンス
cafeBeverageTemp キッズ; ホット; アイス
cafeBeverageExtras ハーフスイート; セミスイート

会話: 目標

次に、Amazon Lex の用語で「インテント」として知られる目標を定義します。ボットは最終的には複数のインテントを使用する可能性がありますが、まずは 1 つから始めましょう (複数のボットが同じインテント、および同じインテントの異なるバージョンを使用することができます)。

ユーザーが実際に言うと予想される内容をいくつか例として提示することが重要です。Amazon Lex では、これらの例は「発話」と呼ばれます。これが重要なのは、Amazon Lex が機械学習モデルのトレーニングを行い、正しいインテントを認識するようにするためです。このテキストは、ユーザーの言うことに完全に一致している必要はありません。また、小さいセットから始めて、その後変形を追加していくのが最良です。

各発話は 1 つ以上のスロットを参照しますが、これらのスロットは定義されている必要があります。各スロットは、ユーザーから値を引き出すために Amazon Lex が使用する 1 つ以上のプロンプトと関連付けることができます。Amazon Lex ダイアログマネージャーはスロット値を追跡します。また、以下のように、それぞれの必要なスロットの優先度を使用して、次に求めるスロットを決定することもできます。

o_bots_2

この時点で、ボットはコーヒーを注文できる状態になります。フルフィルメントについては、パート 2 の投稿でお話しします。

会話: テスト

次に、ボットを構築してテストします。モバイルアプリができてからでは他の多くの要素がからんでくるため、この段階で、できているものをテストしてエラーを検出し修正することは非常に有効です。テストは Amazon Lex コンソールに表示されるオーバーレイで実行できます。

Test_bot_text

何が起こったのでしょうか。発話としてはこのとおりのテキストを設定していませんでしたが、「I want a mocha (モカをお願いします)」という入力テキストは、作成された cafeOrderBeverageIntent と照合され、発話が I want a {BeverageType: mocha} ({BeverageType: モカ} をお願いします) として解釈されました。続いて、Amazon Lex は BeverageSize が必要であると判断し、このスロットのデフォルトのプロンプト、つまり What size?  tall, medium, large? (サイズはどうなさいますか?  トールとミディアム、ラージがございますが?) というプロンプトを表示しました。

最後に、すべての必要なスロットが満たされたら、Amazon Lex はリクエストどおりに値を表示します (クライアントにパラメーターを返す)。

会話: 流れ

では、Lex が理解できなかった場合はどうでしょうか。この場合は、コンソールにあるインテントエディタの明確化プロンプトを使用して、何か別の内容を引き出そうと試みることができます。他のすべてが失敗した場合、安全に終了します。

o_bots_4

この設定では、Amazon Lex は 3 回まで他の明確化プロンプトを使用し、その後、中断フレーズの 1 つを使用して断念していることがわかります。では、なぜ複数のプロンプトを使用するのでしょうか。確かに、必要なのは 1 つだけかもしれませんが、複数のプロンプトが存在することで、Amazon Lex は選択することができ、自発性を維持できるのです。

A_bird_text

また、ユーザーが注文を確定する直前にボットがプロンプトを表示するように設定することもできます。確認プロンプトは、コンソールのインテントエディタにリストされています。

確認プロンプトは、セットアップしたすべての単一スロット、特に、他のスロットが満たされた場合にのみ必要となるスロットに含める必要はありません。必要なスロットをプロンプトに含めることは良い考えですが、コードフックを使用してプロンプトをカスタマイズすることもできます (詳細は次回の投稿でお伝えします)。

o_bots_6

確認プロンプトには、スロット値を含むことができます。どうように使用するか、見てみましょう。

Can_I_get_text

予想どおり、Amazon Lex は必要なスロットが満たされたことを判断し、確認プロンプトを表示しました。また、「nope (ううん)」を正確に解釈し、中断しました。2 回目では、Amazon Lex は「yep (うん)」を肯定表現として正確に解釈し、値を表示しました。

May_I_have_text

これは何を示しているのでしょうか。追加設定がない場合、Amazon Lex は確認プロンプトから、ユーザーがサイズの変更を希望していることを正確に解釈しました。

まとめ

この投稿では、ボット設計に関連する基本的な決定事項についてお話ししました。ここでは、会話の流れを実際に観察することから始め、特定の取引に的を絞り、いくつかのデフォルト値のあるインタラクティブなボットをすばやく構築しました。その後、テストコンソールで、ボットが予想どおりに動作することを確認しました。

パート 2 では、さらなる検討事項についてお話しするとともに、この基本的なボットが音声を認識できるように開発を進めます。

注意: パート 1 とパート 2 のコード は Github リポジトリにあります。

ご不明の点またはご提案があれば、下記までコメントをお寄せください。


今回のブログの投稿者について

niranjanNiranjan Hira はソリューションアーキテクトとして、お客様がビジネス上の課題に対処するために最適な構成要素を組み立てるのをお手伝いしています。時間があるときには、いろいろな物を分解して、元に戻せるかどうか試しています。

harshal_pimpalkhute_100Harshal Pimpalkhute は、Amazon Lex チームのプロダクトマネージャーとして機械が人と (うまく) やり取りするための取り組みに献身しています。

 

Amazon Lex と Amazon Alexa を使用した質疑応答ボットの作成

ユーザーの質問に対する回答を持っていますが、ユーザーが質問をして適切な回答を得る良い方法が必要です。多くの場合、ユーザーはヘルプデスクに電話するか、サポートフォーラムに投稿しますが、ストレスが高まり、組織にとってコストがかかります。チャットボットがあれば、顧客にとって便利でしょう。興味深いことに、最近の調査は、ユーザーの 44% が人間と話すよりもチャットボットと話すことを望んでいます。

この投稿では、QnABot (「キューアンドエーボット」と発音) と呼ばれるサンプルソリューションについて説明します。 QnABot は、Amazon LexAmazon Alexa を使用して、「質疑応答」のための便利なインターフェイスを提供します。これにより、ユーザーは質問をして関連する回答をすばやく得ることができるようになります。

Amazon Lex を使用すると、音声とテキストチャットアクセスの両方を既存のアプリケーションに統合できます。Amazon Alexa を使用すると、Amazon Echo または Alexa Voice Service 対応デバイスを自宅や職場で使用しているユーザーに、ハンズフリー音声インターフェイスを提供できます。QnABot は両方の長所を最大限に活用しています。

QnABot は、Amazon Elasticsearch Service (Amazon ES) を使用して質問と回答を検索可能にします。ユーザーが質問をすると、Amazon ES の強力な全文検索エンジンが背後で使用され、その質問に最も合った回答が検索されます。

以下のセクションでは、次のことを行う方法について説明します。

  • QnABot を AWS アカウントにデプロイする。このブログでは、お客様が既に AWS を利用していることを前提としています。アカウントをまだ作成していない場合は、AWS ホームページの [Create an AWS Account] を選択してください。
  • コンテンツデザイナー UI を使用して、質問と回答を QnABot に挿入する。
  • ウェブクライアント UI で音声またはチャットを使用して質問をする。
  • 最新の Amazon Echo デバイスを使用してハンズフリーで質問をする。
  • QnABot のコンテンツのトラブルシューティングと調整を行って、間違った回答が表示される可能性を最小限に抑える。
  • 画像やウェブリンクによって回答を強化する。

さらに、QnABot のしくみについても詳しく調べ、ニーズに合わせて強化するためのアイデアも示します。

(more…)

Build a Voice Kit with Amazon Lex and a Raspberry Pi

この記事では、広範に利用可能なコンポーネントを利用して、Amazon Lex をどのようにカスタムハードウェアに組み込むかを紹介します。シンプルな音声ベースの AI キットを構築して、Amazon Lex に接続する方法を示します。Raspberry Pi および合計 60 ドル以下の市販のコンポーネントをいくつか使用します。このブログの終わりまでに、Amazon Lex PostContent API に統合された、インターネット接続されたハードウェアデバイスが使用できるようになります。音声制御ロボットおよび音声制御メトロノームなどの、幾つかのボットのデモも行います。

コンポーネント概要

Amazon Lex ハードウェアキットを構築するには、以下のコンポーネントが必要です。

  • Raspberry PI 3 Model BAmazon で 35 ドルから。
  • Kinobo – USB 2.0 ミニマイク、Amazon で 5 ドルから。
  • Adafruit I2S 3W ステレオスピーカーボンネットおよびスピーカー、adafruit で 12 ドルから。
  • (オプション) Qunqi クリアーケースボックスエンクロージャー、Amazon で 20 ドルから。

物理的な作成

Raspberry Pi

図 1. Raspberry PI Model B

このプロジェクトでは、Raspberry PI 3 Model B ストックを使用します。図 1 は、Raspberry Pi をクリアーケースボックスキットに設置したところです。クリアーケースボックスは Pi、デジタルオーディオコントローラー (DAC)、およびスピーカーを置くのにちょうどぴったりですが、必須ではありません。

(more…)

Amazon Connect と Amazon Lex のインテグレーション

私のお気に入りのサービス、Amazon ConnectAmazon Lex に機能強化が施されました。セルフサービスの Amazon Connect はクラウドベースのサポートセンターで、ビジネスがより良いカスタマーサービスを低コストで簡単に提供できるようにしています。Amazon Lex は、音声とテキストを使用して会話型インターフェイスを構築するためのサービスです。この 2 つのサービスを統合することで、Lex の自動音声認識 (ASR) と自然言語理解 (NLU) の性能を利用し、優れたセルフサービスエクスペリエンスを顧客に提供することができます。この統合を有効にするため、Lex チームが 8kHz の音声入力サポートを追加しました。これについては後ほど詳しくご説明します。この機能のメリットは?顧客によるリクエストの大半をボットが解決できれば、電話での待ち時間を削減し、ユーザーは時間を無駄にすることなく製品を使用することができます。

Connect または Amazon Lex の背景情報については、Jeff が過去に公開したブログ [1][2] をぜひお読みください。LEGO ファンの方は特にお楽しみいただけると思います。


では、この新しい統合の使用方法を見ていきましょう。Twitch チャンネルで構築したアプリケーションを使用して、このブログ用に内容を変更します。アプリケーションのコアでユーザーが Amazon Connect の番号を呼び出します。この番号はユーザーを Lex ボットに繋げ、AWS Lambda 関数を開始します。これは Lex のインテントをベースにしています。アプリケーションでできることは?

最良のコードエディタは何だと思いますか? 個人的には vim が好きです。コード編集を行うには最高のエディタです。私の同僚の Jeff は emacs を選んでいます。 これは素晴らしいオペレーティングシステム エディタです。もし、生まれつき指の関節が普通以上にあればの話しですが。そして同僚の Tara が選んだのは Visual Studio です。これも圧倒的に優れたエディタです。ということで、もっとも優れたエディタがどれか議論するのではなく、皆さんに投票してもらうのが良いのではないかと思います。バタフライに投票することもできますので、ご安心を。

投票に参加してみませんか?+1 614-569-4019 に電話し、あなたが最高のエディタだと思うものをお知らせください!皆さんの電話番号を保存したり、音声を録音することはありませんので、何回も vim に投票して下さって構いません。ライブで投票結果を見てみますか?  http://best-editor-ever.s3-website-us-east-1.amazonaws.com/.

さて、この仕掛けをどうやって構築したと思いますか?このブログでは各コンポーネントについて説明しますが、すでに LexLambda に触れているので、主に Amazon Connect コンポーネントについて焦点を当てることにします。ここでは、すでに皆さんが Connect インスタンスを実行中であることを前提とします。

Amazon Lex

まず Lex について説明します。まず、 VoteEditor という名前のボットを 2 つのインテントを使用して作成します。 VoteEditor に単一のスロットがあり editorConnectToAgent にはスロットがありません。editor スロットに様々なコードエディタ名を入れます (emacs は除去しておきましょうか)。

AWS Lambda

Lambda 関数も実にシンプルです。まず、Amazon DynamoDB テーブルを作成して投票結果を保存します。次に Lex (build_response) に応答するヘルパーメソッドを作成します – これでメッセージを Lex の分かりやすいレスポンス形式でラップできるようになります。後はフローロジックを特定するだけです。


def lambda_handler(event, context):
    if 'ConnectToAgent' == event['currentIntent']['name']:
        return build_response("Ok, connecting you to an agent.")
    elif 'VoteEditor' == event['currentIntent']['name']:
        editor = event['currentIntent']['slots']['editor']
        resp = ddb.update_item(
            Key={"name": editor.lower()},
            UpdateExpression="SET votes = :incr + if_not_exists(votes, :default)",
            ExpressionAttributeValues={":incr": 1, ":default": 0},
            ReturnValues="ALL_NEW"
        )
        msg = "Awesome, now {} has {} votes!".format(
            resp['Attributes']['name'],
            resp['Attributes']['votes'])
        return build_response(msg)

コードを理解できているか確認します。つまり、まだ存在しないエディタに票が入ったら、エディタに 1 票を追加するようにします。そうでなければ、そのエディタの票数を「1」増やします。エージェントのリクエストを受けたら、フローを終了してフレンドリーなメッセージを返します。どうです、簡単でしょう。後は投票結果を見るため、Lex ボットに Lambda 関数を使うように指示するだけです。次に進む前に、Lex コンソールですべて問題なく作用しているか確認することができます。

Amazon Connect

問い合わせフローで Lex ボットを使用する前に、Amazon Connect インスタンスにアクセスできるか確認します。そうするには、Amazon Connect サービスコンソールに行き、インスタンスを選択してから「問い合わせフロー」にアクセスします。ボットの追加先となる Lex のセクションが表示されます。

Amazon Connect のインスタンスが Lex ボットを呼び出せることが分かったところで、Lex ボットを含む新しい問い合わせフローを作成します。[Interact] カテゴリから [Get customer input] ウィジェットを介してフローにボットを追加します。

ウィジェットを起動すると、電話の数値キーから入力を許可するための [DTMF] タブ、または音声入力とその情報を Lex サービスに渡す [Amazon Lex] タブが表示されます。[Lex] タブを使用していくつかの事項を設定します。

様々なオプションがありますが、要するに使用したいボットを追加したり (ボットのバージョンも同様)、ボットで使用したいインテントや、ボットを紹介する小さなプロンプトを追加します (場合によっては顧客にコメントを入力するように促すなど)。

最終的にコンタクトフローは次のようになります。

実際には Lex ボットを介して多数のトランザクションをユーザーが実行できるようにする場合もあるでしょう。次に、エラーまたは ConnectToAgent のインテントで、ユーザーが実際のスタッフと対話ができるキューにユーザーを追加します。ユーザーの情報を収集し保存して、エージェントが利用できるように多機能のインターフェイスを追加します。これにより、エージェントは必要な情報をすべて把握した上でユーザーとの会話をすぐに始めることができます。

では次に Lex がサポートする 8kHz オーディオサポートの使用によるメリットについて説明します。Lex は、もともと電話から 8 kHz 入力以上の高音質でサンプルされた音声入力のみサポートしていました。現代のデジタル通信アプリケーションは、通常最低でも 16 kHz でサンプルされたオーディオ信号を使用しています。この忠実度が高いレコーディングでは「ess」(/s/) や「eff」(/f/) といった音の違いを聞き分けることができます。少なくても、そのようにオーディオ専門家は説明しています。それに比べ、電話は大幅に質の低いレコーディングを使用しています。人間と人間の耳というのは、低質の録音でも音声が何を言っているのか前後関係から把握するのに長けています (証拠は「NASA アポロのレコーディング (NASA apollo recordings)」をご覧ください)。ですから、電話のデジタルシステムは大方デフォルトで 8kHz サンプリングをセットアップに使用しています。帯域幅と忠実度において具合の良いトレードオフだと思います。電話の声がいつもと違うように聞こえるのは、そのためです。サンプリングレートの基本的な問題に加えて、携帯電話によるコールデータでは通話中に聞こえないという問題がよくあります (もしもし、聞こえますか? といった具合に)。多種多様の何千種類ものデバイスと何百社というメーカー、そして数えきれないほどの様々なソフトウェア実装があります。そこで、認識にまつわる問題はどうやって解決したらいいと思いますか?

Lex チームは、この問題への対処方法は音声入力に使用する一連のモデルを拡張し、8kHz モデルを含むことだと判断しました。8 kHz のテレフォニーオーディオサンプリングレートのサポートにより、音声認識の精度やサポートセンターとのやり取りの忠実度を高めることができます。これは、数多くのお客様が Amazon Connect をもっと利用できるようにと対応しているチームの素晴らしい努力の結果と言えるでしょう。

最後になりますが、Amazon Connect は外部開発者として使用できる PostContent エンドポイントと同じものを使うため、Amazon Connect を使用していないユーザーでも Lex で 8kHz を使用することが可能です。

以上となりますが、お楽しみいただけましたか? 詳細はいつも通り「ドキュメント (docs)」や「API リファレンス (API Reference)」をご参照ください。

Randall

AWS チャットボットチャレンジを開催 – Amazon Lex と AWS Lambda を使用した対話式でインテリジェントなチャットボットを作成

AWS 2017 サンフランシスコサミットのリリース内容やお知らせを細かくチェックしていたユーザーなら Amazon Lex サービスの一般提供が開始し、今すぐご利用いただけるようになったことをすでにご存知かもしれません。Amazon Lex は、開発者が音声やテキストを使用するアプリケーションで対話式のインターフェイス構築を可能にするフルマネージド型の AI サービスです。Lex は Amazon Alexa を使用する Amazon Echo のようなデバイスと同じディープラーニングを使用しています。Amazon Lex のリリースにより、開発者は独自のアプリケーションで違和感のないユーザーエクスペリエンスやリアルな会話のやり取りを構築できます。Amazon Lex は Slack、Facebook Messenger、Twilio SMS に対応しています。こうした人気のチャットサービスを使用し、ユーザーの音声やテキストのチャットボットを簡単に発行することができます。Amazon Lex サービスを試し、独自のアプリケーションに優れた機能を追加するには、今が絶好のチャンスです。

さて、いよいよお知らせです。
この度 AWS チャットボットチャレンジを開催することになりました! AWS チャットボットチャレンジは、問題を解決したり今後のユーザーに向けた付加価値を追加する、他に例のないユニークなチャットボットを構築するチャンスです。AWS チャットボットチャレンジはアマゾン ウェブ サービスと Slack の協力により実現しました。

チャレンジ
このチャレンジに参加する開発者は、Amazon Lex を使用して自然な対話式のチャットボットを構築し、バックエンドでロジックプロセスやデータプロセスを実行するために AWS Lambda と Lex の統合を利用することになります。対象となるボットは新しいものでも既存のものでも構いませんが、既存のボットの場合はこのチャレンジのエントリー期間中に Amazon Lex と AWS Lambda を使用できるように更新する必要があります。

ソリューション構築時の制限は、あなたの想像力のみです。それでは、以下にボット作成やデプロイにおける創作力をサポートするアドバイスをいくつかご紹介します。チャットボットをよりユニークにするためのアドバイスについては次をご覧ください。

  • SlackFacebook Messenger または Twilio SMS にボットをデプロイする
  • 独自のボットソリューション構築時に別の AWS サービスを活用する
  • Amazon Polly のようなサービスを使用してテキスト読み上げ機能を導入
  • ほかのサードパーティー API、SDK、サービスを活用
  • Amazon Lex の構築済みエンタープライズコネクターを利用して SalesforceHubSpotMarketoMicrosoft DynamicsZendeskQuickBooks といったサービスをデータソースとして追加

AWS Lambda を使用してボットをコスト効率良く構築する方法があります。Lambda には毎月、無料利用枠のリクエスト数 100 万件とコンピューティング時間 400,000 GB/秒 が含まれています。無料提供している毎月の使用量はすべてのお客様を対象とし、無料利用枠の期間である 12 か月が終了した後も無効にはなりません。さらに、Amazon Lex を新たにご利用のお客様は、初年度において 10,000 件までのテキストリクエストと 5,000 件までの音声リクエストを毎月無料でプロセスすることができます。詳細はこちらをご覧ください。AWS の無料利用枠では、AWS にサインアップしたその日から 12 か月に渡り無料利用枠のサービスをご利用いただけるほか、12 か月の無料期間が過ぎた後も自動的にそれが無効になることはありません。AWS の無料利用枠と関連サービスの詳細については AWS 無料利用枠の詳細ページをご覧ください。

 

参加方法
AWS チャットボットチャレンジには、参加者の居住国で成年に達した年齢であれば、個人またはチームでこのコンペティションに参加できます。参加申込の時点で企業や団体が正式に設立または法人化されていて、参加対象となるエリアで正当な企業として見なされている場合であれば、社員数が 50 人以下の企業も参加対象になります。また、参加対象地域で 50 人以上の社員から成る大規模な企業も参加することはできますが、その場合は現金が含まれない賞のみへの参加となります。チャットボットに寄せられたボットは次のカテゴリで審査されます。

  • 顧客価値: ボットが問題を解決しユーザーに付加価値を提供
  • ボットのクオリティ: ボットがユーザーの問題を独自の方法で解決、オリジナルでクリエイティブそして他のボットソリューションと差をつけていること
  • ボットの実装: 開発者がいかに努力し優れたボットを構築し実行できるようにしたか検討一般的なフレーズで問いかけられたボットが、意図したように機能し質問を認識して応答できるかなど、ボットの機能について検討

 

賞について
優れたボットを作成した開発者に AWS チャットボットチャレンジ賞を授与します。1 等賞

  • 5,000 USD
  • AWS クレジット 2,500 USD 相当
  • AWS re:Invent のチケット 2 枚
  • Amazon Lex チームとのオンラインミーティング 30 分
  • 受賞者は AWS AI ブログで紹介されます
  • クールな賞品

2 等賞

  • 3,000 USD
  • AWS クレジット 1,500 USD 相当
  • AWS re:Invent のチケット 1 枚
  • Amazon Lex チームとのオンラインミーティング 30 分
  • 受賞者は AWS AI ブログで紹介されます
  • クールな賞品

3 等賞

  • 2,000 USD
  • AWS クレジット 1,000 USD 相当
  • Amazon Lex チームとのオンラインミーティング 30 分
  • 受賞者は AWS AI ブログで紹介されます
  • クールな賞品

チャレンジのタイムライン

  • エントリー開始日: 2017 年 4 月 19 日 午後 12:00 時 (PDT)
  • エントリー終了日: 2017 年 7 月 18 日 午後 5:00 時 (PDT)
  • 結果発表: 2017 年 8 月 11 日 午前 9:00 時 (PDT)

 

参加手続き
チャットボットチャレンジへの参加をご希望ですか?参加するには、次のチャレンジ上のルール参加資格をご確認ください。

  1. AWS チャットボットチャレンジに登録
  2. AWS チャットボットの Slack チャネルに登録
  3. AWS でアカウントを作成
  4. ドキュメントやリソースへのリンクを掲載しているリソースページにアクセス
  5. 作動中のボットを映したデモ動画を撮影ボットの概要と用途についてドキュメントを作成
  6. ボットのコードをホストする GitHub リポジトリへのリンク、すべてのデプロイファイル、ボットをテストする上で必要な手順など、審査とテスト実施に要するボットへのアクセス方法を提供
  7. AWSChatbot2017.Devpost.com2017 年 7 月 18 日 午後 5:00 時 (ET) までにボットを提出します。ボットのアクセス権限の共有、Github リポジトリ、デプロイファイルも併せて提出してください。

 

概要
Amazon Lex では、ウェブアプリケーションやモバイルアプリケーションで対話を構築することができます。また、IoT デバイスの管理、カスタマーサポートの提供、トランザクションの更新情報を連絡したり、DevOps ワークロードの実施 (ChatOps) を可能にするチャットボットを構築することも可能です。Amazon Lex には AWS LambdaAWS Mobile HubAmazon CloudWatch との統合が組み込まれています。そのため他の AWS サービスと簡単に統合することができ、AWS プラットフォームを使用してセキュリティ、モニタリング、ユーザー認証、ビジネスロジック、ストレージなどをチャットボットやアプリケーションで構築することができます。Slack、Facebook Messenger、Twilio SMS といったチャットサービスをサポートする Amazon Lex を活用して、音声やテキストのチャットボット機能を強化できます。Amazon LexAWS Lambda を使用してチャットボットや対話式インターフェイスを構築し AWS チャットボットチャレンジでクールな賞品を獲得してください。Amazon Lex と Amazon Lambda を使用して作成したボットに関する最近のリソースやオンラインテクトークもボット構築の参考になると思います。

AWS チャットボットチャレンジに関するご質問は aws-chatbot-challenge-2017@amazon.com 宛てにメールで英語で問い合わせるか、ディスカッションボードに質問を投稿してください。 では、頑張ってコード作成に励む皆さんの幸運を祈ります!

Tara

Pollexy – Amazon Polly と Raspberry Pi で構築した特別なニーズをサポートする音声アシスタント

4 月は Autism Awareness month (自閉症啓発月間) です。米国では 68 人中に 1 人の子供が自閉症スペクトラム障害 (ASD) と診断されています (2014 年 CDC 調査)。 今回のブログでは AWS のシニア DevOps クラウドアーキテクトの Troy Larson が、息子の Calvin をサポートするために取り組んでいるプロジェクトについて紹介します。これまでにも、AWS がどのようにしてこれほどたくさんの様々なアイデアを出し合えるのか聞かれたことがあります。場合によっては、とても個人的な理由で大切な誰かの役に立ちたいという願いからアイデアが浮かぶこともあるのですが、この Pollexy はまさにその例です。まずは Pollexy に関する記事を読んでから、こちらの動画をご覧ください。 -Ana


背景

私はここ何年もの間、自閉症で会話の少ない 16 歳のティーンエイジャーの親であるコンピュータプログラマーとして、どうにかテクノロジーを使ってより安全で幸せかつ快適な暮らしをつくることができないかと常に模索していました。このプロジェクトのチャレンジとなる根源は、人との交流におけるすべての基本、つまりコミュニケーションです。息子の Calvin は口頭による指示には反応しますが、責任を持って発言することができません。彼のこれまでの人生において、私達が会話をしたことは一度もないのです。自分の部屋で一人で遊んでいることはできても、すべてのタスクや一連のタスクをこなすには、他の誰かが口頭で彼に促す必要があります。我が家には他にも子供がおり、家庭内で担当するその他の役割もありますから、Calvin にかかりっきりになることで家庭内の雰囲気に負の影響が出てしまうことも否めません。

事の発端

去年開催された re:Invent で Amazon PollyAmazon Lex のことを初めて耳にしてから、すぐにこうした技術を活用してどのように息子をサポートできるか考え始めました。息子は人による口頭指示に対しては問題なく対応することができますが、デジタル音声を理解することはできるのだろうか? という疑問がありました。そこで、ある土曜日に Raspberry Pi を息子の部屋に設定し、ドアを閉め、息子に気付かれないように家族と一緒に様子をうかがってみることにしました。Raspberry Pi に接続し、聞き慣れた西海岸の発音による Joanna を選び Polly を介して息子に問いかけてみました。「Calvin、トイレ休憩の時間だよ。部屋から出てトイレに行きなさい。」すると、数秒後に息子の部屋のドアノブが回る音がしました。我々家族は思わず隠れていた場所から頭を出して覗いてみると、息子はよく分からないといった顔つきで私をちらりと見て、そのまま Joanna が指示したようにバスルームに向かっていったのでした。Calvin が聞いたことも見たこともない人物の声による指示を聞き、それに応えたことを目の当たりにした私達は驚きで顔を見合わせたほどです。この一件に関するアイデアを同僚達と話し合ったところ、そのうちの一人が、毎年恒例の AWS Sales Kick-Off ミーティングで開催される IoT と AI のサイエンスフェアに参加してみたらどうだろう、と提案してきました。Polly と Lex のリリースから 2 か月そして 3500 ものコードを作成後、Pollexy は (Calvin 同伴) サイエンスフェアでデビューを飾りました。

概要

Pollexy (“Polly” + “Lex”) は Raspberry Pi とモバイルベースの特別なニーズに応える音声アシスタントです。ヘルパーは Pollexy を使用して、音声によるタスクの指示や、定期的に行うスケジュールもしくはオンデマンドのスケジュールに関するメッセージを再生するように設定できます。たとえば、ヘルパーは定期的に服用する薬のリマインダーメッセージをスケジュールしたり、毎時間のトイレ休憩を促すメッセージを設定することができます。また、同時に Amazon Echo とモバイルデバイスを使用して特定のメッセージをすぐに再生するようにリクエストすることも可能です。ヘルパーは相手がメッセージを聞いたか確認するように設定することもできます。たとえば、Pollexy が最初に「青いボタンを押してください (Push the blue button)」と言わない限り、息子は Pollexy に反応しません。息子が青いボタンを押すまで、Pollexy はメインのメッセージを再生しないようになっています。また他の状況では Lex を使用して口頭で応答したり、確認が不要なユーザーもいるでしょう。どちらにしても、自分のニーズに適うように Pollexy をカスタマイズすることができるのです。そしてもっとも重要かつチャレンジとなるポイントは、大きな家に住んでいる場合、メッセージを再生する部屋に相手がいるか確認するにはどうしたらいいのか? という点です。特別なニーズのある大人が離れに住んでいる場合はどうでしょう?リビングにいるのかキッチンにいるのか分からない場合は?相手が複数人いる場合は?屋内にいる複数の人物がそれぞれ別の部屋にいた場合、各自にそれぞれ別のメッセージを送りたい場合はどうでしょう?では、次に基本的な要素と全容についてご説明します。

Pollexy の基本的要素

Amazon のリーダーシッププリンシプルは「Invent and Simplify (発明と簡素化)」です。Amazon では Pollexy アーキテクチャの複雑性を最小限に抑えたいと考えています。Pollexy で連係しているオブジェクトとコンポーネントは、簡単に説明できる方法でそれぞれ 3 つのタイプに分けることができます。

オブジェクト #1: ユーザー

Pollexy でサポートできるユーザー数には制限がありません。ユーザーは独自の特定できる名前です。「確認する」など基本的な事項を設定できます。さらに大きなポイントは場所をスケジュールで特定できることです。つまり、誰かがいる家の特定の場所に対して Outlook のようなスケジュールを作成することができるのです。

オブジェクト #2: 場所

場所はデバイスが物理的に設置されている独自の場所を識別します。ユーザーのロケーションスケジュールをベースに、Pollexy はどのデバイスを順次に使用して連絡するか把握することができます。必要に応じてデバイスを「消音」モードにすることもできます (お昼寝中など)。

オブジェクト #3: メッセージ

もちろん、これが本来の目的です。各メッセージには、ユーザーそして定期的に実行するスケジュールが連携されます (1 回限りのメッセージを除く)。Pollexy はメッセージの再生準備が整うと、ユーザーの場所を確認することができるのでメッセージには場所情報は保存されません。

コンポーネント #1: スケジューラー

メッセージはどれもスケジュールする必要があります。これはコマンドラインツールです。たとえば「Calvin に「午後 8 時までに歯を磨くこと」と伝えてください」と言った場合、このメッセージは DynamoDB に保管され、Lambda 関数のキューイングを待つことになります。

コンポーネント #2: キューイングエンジン

Lambda はスケジューラーを毎秒ごとに実行しチェックして、メッセージがあるか、また再生できるメッセージがあるか確認します。再生するメッセージがある場合、ユーザーの場所のスケジュールを確認してメッセージを再生またはその場所に SQS キューを送ります。

コンポーネント #3: スピーカーエンジン

Raspberry Pi デバイスでは毎分ごとにスピーカーエンジンが起動し、その場所の SQS を確認します。メッセージがある場合、スピーカーエンジンはユーザーの設定を確認しメッセージを再生するためにコミュニケーションを開始します。相手が応答しない場合、スピーカーエンジンはスケジュールでそのユーザーに別の場所が指定されているか確認し、その 2 番目の場所の SQS キューにメッセージを送ります。結果としてメッセージは再生されるか、タイムアウトになります (そのユーザーが 1 日中留守にしている場合など)。

ユーザーへの配慮と自由がキーポイント

私達は大方、個人のプライバシーや個人情報への配慮というものはごく普通のことだと捉えていると思います。特別なサポートを必要としている人達にとって、常に誰かに見られているということは、プライバシーや自由というものがどれだけ欠如している状況であるのか想像してみてください。自閉症と向き合っている人達にとっては、他者が個人のスペースに入り込むことを強く疎ましく思い、場合によってはそれが怒りや不満に繋がることもあります。Pollexy は不満をもたらすことがなく、穏やかな友達といった存在として日常におけるサポートを提供し、ユーザーに自信を持たせながら、誰もが望む個人のプライバシーや自由が尊重されていると思わせることができるツールです。

-Troy Larson