Amazon Web Services ブログ

Amazon Lex の感情分析を用いた会話体験の設計

効果的な会話をするには、感情を理解し、適切に対応することが重要です。コールセンターでは、不満を抱えた顧客と話すときには、たとえば「お手数をお掛けして申し訳ございません」といった簡単な謝辞が役立つこともあります。 感情を理解することは、人間のエージェントに電話を代わってサポートを引き継ぐタイミングを判断するのにも役立ちます。 このような会話の流れをボットで実現するには、ユーザーがあらわにした感情を検出し、適切に対応する必要があります。以前は、Comprehend API を使用してカスタム統合を構築する必要がありました。この記事の執筆時点では、Amazon Lex で感情をネイティブに判断できるようになっています。 本稿では、ユーザーの感情を使用して会話の流れをより適切に管理する方法を説明します。 ボットを構築し、ユーザーの感情に基づいて応答を更新するロジックを追加し、エージェントへの引き継ぎを設定する手順を説明します。 ボットを構築する 次の会話を使用して、ボットをモデル化します: ユーザー: 荷物はいつ到着しますか? とても遅いのですが。 エージェント: ご不便をおかけして申し訳ございません。 追跡番号をお教えいただけますか? ユーザー: 21132 です。 エージェント: 確認いたしました。11 月 27 日にご自宅に到着いたします。 ユーザー: 分かりました、ありがとう。 それでは、配達ステータスを追跡し、配達日を変更する目的で、Amazon Lex ボットを構築しましょう。CheckDeliveryStatus インテントは、追跡番号情報を引き出し、配達日を返します。ChangeDeliveryDate インテントは、配達日を新しい日付に更新します。本稿では、追跡番号と配達日でデータベースを管理しています。AWS Lambda 関数を使用して配達日を更新できます。 ボットで感情分析を有効にするには、次の手順を実行します: Amazon Lex コンソールで、該当のボットをクリックします [Settings] の中から [General] を選択します [Sentiment Analysis] では [Yes] を選択します [Build] をクリックして新規ビルドを作成します ロジックを追加して応答を変更する ボットをセットアップしたので、ユーザーの感情に反応するロジックを追加します。CheckDeliveryStatus 内のダイアログのコードフックは、感情スコアを検査します。否定的な感情のスコアが特定のしきい値を超えている場合、追跡番号の入力を求めるときに、「ご不便をおかけして申し訳ございません」などの謝辞を挿入できます。以下の Lambda コードスニペットをご覧ください:   if (negativeSentimentVal […]

Read More

AWS IoT Core向けのAlexa Voice Service 統合方法の紹介、Alexa Voiceをあらゆるタイプの接続されたデバイスにコスト効率ご利用いただく方法

Alexa Voice Service(AVS)Integrationは、AWS IoT Coreの新機能であり、デバイスメーカーは、接続されたデバイスをAlexa組み込みデバイスにすることができます。 AVS for AWS IoTは、コンピューティングおよびメモリ集約型のタスクを物理デバイスからクラウドにオフロードすることで、Alexa Built-inデバイスの生産コストと複雑さの両方を削減します。エンジニアリング部品表(eBoM)コストの削減により、デバイスメーカーは、ライトスイッチ、サーモスタット、小型家電など、差別化された音声対応製品の新しいカテゴリをコスト効率よく構築できるようになりました。これにより、最終消費者は自宅、オフィス、またはホテルの部屋の新しい場所でAlexaと直接会話し、真にアンビエントな体験をすることができます。

Read More

IoT CoreからWebサービスに直接データをルーティング可能に

このブログでは、AWS IoT Core Rule EngineのHTTPアクションを使って任意のHTTPS エンドポイントへ追加コードなしもしくは変更してデータを送る方法を紹介します。この機能を使用すると、AWS IoTを独自のウェブサービスと統合できます。中間サービスの使用に伴う追加Latencyの発生や複雑さはありません。 この機能の詳細については、HTTPアクションのドキュメントを参照してください。 AWS IoTルールを初めて使用する場合は、このチュートリアルをご覧ください。 本ブログの前提: AWS IoTのコンソールにログイン可能もしくはAWS CLIがインストール済みであること あなたがすでに証明局(CA)により署名された確かな証明書が存在するHTTPSをもっていること HTTPSエンドポイントのログへアクセス可能もしくは、エンドポイントへ送ったメッセージを読むことができること 本ブログでは以下をウォークスルーします コンソールでトピックに基づくHTTPアクションルールを作成します コンソールでルールの宛先の確認と有効化 HTTPアクションルールの作成をAWS CLIで実施 置換用のテンプレートを使わずにHTTPアクションを定義 HTTPアクションのhaeaderと認証を定義 ルールの宛先をAWS CLIを使って管理する 作成 確認 更新 リスト 削除

Read More

S3 複製更新:複製 SLA、メトリック、およびイベント

S3 相互リージョン複製 は 2015年初頭からあります (新規 Amazon S3用相互リージョン複製)、および 同一リージョン複製 は 数ヶ月間存在しています。 複製はセットアップが非常に簡単で、S3バケットから他のものにオブジェクトをコピーするためのルールを使用できます。このルールは 全体のバケットまたは接頭辞またはタグに基づくサブセットの複製を指定できます: 複製を使用して、事故復旧計画またはその他のオペレーションの理由の一部として地理的な 冗長の規定要件を満たすために AWS リージョン内またはその間の重要なデータをコピーできます。リージョン内でコピーして、履歴を集計、テストおよび開発環境のセットアップ、およびコンプライアンス要件への対処ができます。 S3の複製機能は非常に大きな利用価値があります: 2015年のサービス開始から、当社のお客様は何兆ものオブジェクトおよびエクサバイトのデータを複製しました。 本日私は当社が複製時間管理の追加によりそれを更に強化したことをお伝えすることを嬉しく思います。この機能は既存のルール に基づく複製を補強し、タグまたは接頭辞に基づいてより滑らかなコントロールを可能にするため、お客様が指定するデータセットで複製時間管理を使用できます。サービスの詳細は以下のとおりです。 複製 SLA – 複製 SLA を利用して複製時間の予測を用意にします。 複製メトリック – 新規 CloudWatch メトリクスを使用して、各ルールの最大複製時間をモニタリングできます。 複製イベント – イベントを使用して SLA から逸脱するオブジェクトの複製を追跡できます。 より詳しく見てみましょう… 新規複製 SLA S3はオブジェクトサイズおよびカウント、利用できる帯域幅、その他のバケットに対するトラフィックなどにより影響されるタイミングにより、オブジェクトを複製先バケットに複製します。複製時間全体で追加の管理が必要な場合は、当社の以下を行うために設計された新規複製時間管理機能を使用できます: 大部分 のオブジェクトは数秒内に作成されます。 99% のオブジェクトは5秒以内に複製されます。 99.99% のオブジェクトは15秒以内に複製されます。 この機能を有効化すると、関連するサービスレベル契約からの恩恵を得られます。SLA は 15分以内で複製をすることが予期されているオブジェクトのパーセンテージの期間が表示されて、SLA が満たされていない場合は 請求クレジットを提供します。 99.9% ~ 98.0% – […]

Read More

Windows ファイルサーバー用 Amazon FSx の更新 – Multi-AZ, & 新規企業が即使用できる機能

昨年私は高速、完全に管理され安全な Windows File Server 用の Amazon FSx についてお伝えしました。このサービス開始は正常に受信され、当社のお客様 (一部の例を挙げるとNeiman Marcus、Ancestry, Logicworks、および Qube Research & Technologies ) は本サービスを喜んで使用しています。お客様は 多岐にわたるソースからの視野にアクセスできるということを大変気に入っており 既存の Active Directory 環境を認証ユーザー向けに使用することができるお客様は 高速な SSD 内臓のパフォーマンス 見よる ネイティブな実装から恩恵を得ており ストレージデバイスのフォーマット Windows サーバーの更新または ハードウェアの故障からの 復旧 に時間を費やす必要がなくなりました そのサービス開始から、当社はAmazon FSx for Windows File Server を、お客様のリクエストに大いに堪えるため強化し続けてきました。一部のさらに重要な補強は以下を含みます: 自己管理されたダイレクトリ – この発売により Amazon FSx をオンプレミスまたはインクラウド自己管理 Microsoft アクティブダイレクトリに連結する能力をもたらしました。この機能を開始する方法の詳細については、 自己管理 Microsoft アクティブダイレクトリによる Amazon FSx の使用を閲覧してください。 微粒子ファイル復元 […]

Read More

AWS re:Invent 2019 での Amazon Managed Blockchain および Amazon QLDB のブレークアウトセッション、ワークショップ、チョークトークの案内

AWS re:Invent 2019 がもうすぐ開催されます。 この記事には、AWS re:Invent 2019 で行われる Amazon Managed Blockchain および Amazon Quantum Ledger Database (QLDB) のブレークアウトセッション、ワークショップ、チョークトークの完全なリストが記載されています。 今年は、7 つのブレイクアウトセッション、5 つのチョークトーク、6 つのビルダーセッション、4 つのワークショップなど、合計で 22 の Amazon Managed Blockchain および Amazon QLDB のセッションがあります。セッションの詳細と登録のためのリンクは下にあります。スポットを予約するには、必ず指定席のサインアップをしてください。 このトラックへの参加を検討する必要がある理由 BMW、DVLA、Nestle、Jinju Beer、Sony Music Entertainment Japan、Sage、Workday などの顧客と、ブロックチェーンおよび台帳技術のエンタープライズユースケースについて学ぶことができます。 製品およびエンジニアリングチームから直接、Amazon Managed Blockchain および Amazon QLDB の背後にある革新と機能の詳細について聞くことができます。 当社の専門家と一緒に実践的な体験をして、サンプルアプリケーションを構築することができます。 ブレークアウトセッション BLC203 – 台帳データベースが必要な理由: BMW、DVLA、Sage が語るユースケース 不変な台帳データベースが必要なのはなぜでしょうか? このセッションでは、Amazon Quantum Ledger […]

Read More

Amazon SageMaker Ground Truth ジョブをチェーン化して、ラベルを段階的に作成する

Amazon SageMaker Ground Truth は、機械学習用の高精度なトレーニングデータセットを構築するお手伝いをします。自動ラベル付け機能を使用して、ラベル付けコストを最大 70% 下げることができます。 このブログ投稿では、Amazon SageMaker Ground Truth チェーン機能について、いくつかの例とデータセットのラベル付けの可能性について説明しています。Amazon SageMaker Ground Truth がすでにラベル付けされているオブジェクトを判別し、自動データラベル付けモード用にデータを最適化するため、連鎖により時間とコストが大幅に削減されます。前提条件として、Amazon SageMaker Ground Truth を使用して階層型ラベル分類法を作成するという投稿を確認してください。この記事では、マルチステップの階層ラベル付けを実現する方法と、拡張マニフェスト機能の使用方法に関するドキュメントを示しています。 ラベリングジョブのチェーン チェーンは、次のシナリオで役立ちます。 部分的に完了したラベル付けジョブ – ラベルがほとんど含まれていない入力マニフェストがあり、残りはラベル付けされているラベル付けジョブです。 失敗したラベル付けジョブ – いくつかのラベルを生成し、残りのラベルが失敗または期限切れになったラベル付けジョブです。 停止されたラベル付けジョブ – ユーザーが停止したラベル付けジョブです。停止する前にいくつかのラベルが生成された可能性があります。 チェーン機能により、これらの以前のラベルを再利用し、残りのラベルを一貫して取得できます。詳細については、ラベル付けジョブのチェーンを参照してください。 チェーンでは、前のジョブの出力を後続のジョブの入力として使用します。 以下は、新しいチェーンラベル付けジョブのブートストラップに使用されるアーティファクトです。 LabelAttributeName 前のラベル付けジョブからマニフェストファイルの内容を出力する モデル (利用可能な場合) Amazon Sagemaker Ground Truth コンソールからジョブを開始する場合、デフォルトでは、LabelingJob 名が LabelAttributeName として使用されます。詳細については、LabelAttributeName を参照してください。 部分的に完了したジョブをチェーンしている場合、コンソールは親ジョブの LabelAttributeName を使用して、既にラベル付けされているオブジェクトとラベル付けされていないオブジェクトを決定します。その結果、ラベル付けされていないオブジェクトまたは以前に失敗したオブジェクトのみがラベル付けのために送信されます。別の LabelAttributeName を指定することでこの動作を上書きできます。その場合、以前のラベルはカウントされず、新しいラベル付けジョブはラベル付けのためにすべてのデータを送信します。このプロセスについては、この投稿の後半で詳しく説明します。 API または SDK […]

Read More

Amazon EMR、Amazon SageMaker、および AWS Service Catalog で Intuit Data Lake をプロビジョニングする

この投稿では、Intuitの学習内容と AWS 上でのデータレイクの推奨事項を共有します。Intuit Data Lake は、Intuit データプラットフォームの数多くのチームにより構築され、運営されています。Tristan Baker (チーフアーキテクト)、Neil Lamka (プリンシパル製品マネージャー)、Achal Kumar (開発マネージャー)、Nicholas Audo、および Jimmy Armitage のフィードバックとサポートに感謝いたします。 データレイクとは、あらゆる規模で構造化データと非構造化データを保存する、一元化されたリポジトリです。Intuit では、未加工データのパイルなどを作成することは、容易です。しかし、より興味深い課題がその中に存在しています。 AWS アカウントを整理する方法 使用する取得方法 アナリストの必要とするデータの検索方法 データの保存場所 アクセスの管理方法 Intuit の機密データを保護するために必要なセキュリティ措置 このエコシステムで自動化できる部分 この投稿では、Intuit で採用されるアプローチを概説します。ただし、データレイクを構築するには多くの方法 (例: AWS Lake Formation) があることを覚えておくことは重要です。 高いレベルで Intuit Data Lake を作成する際に含まれる技術やプロセスを取り上げます。これには、全体的な構造とアカウントやリソースのプロビジョニングに使用される自動化を含みます。Intuit Data Lake を協力して構築した他のチームやエンジニアから寄せられたシステムの特定の局面でより詳細なブログ投稿について、今後もこのスペースをご覧ください。 アーキテクチャ アカウント構造 データレイクは一般的にデータソースへのアクセスをコントロールする共有サービスを含むハブアカウントにより、hub-and-spoke モデル に従います。この投稿の目的で、ハブアカウントを Central Data Lake と呼びます。 このパターンでは、Central Data Lake […]

Read More

新機能 – Amazon EBS Fast Snapshot Restore (FSR)

Amazon Elastic Block Store (EBS) はサービス開始から 10 年以上になりますが、今では AWS の土台をなすビルディングブロックとなりました。EBS では、最大 16 TiB までの保存と最大 64,000 IOPS (1 秒あたりの入出力オペレーション数) までの処理が可能な永続的ストレージボリュームを作成できます。4 種類のボリュームをデータ転送スループット、IOPS、料金の要件に合わせて選択できます。要件が変わっても、ボリュームはオンラインでアクティブなままでボリュームタイプの変更、ボリュームの拡張、パフォーマンスの変更ができます。EBS スナップショットでは、バックアップ、災害対策などの用途でボリュームの状態をキャプチャできます。作成したスナップショットは、EBS ボリュームの新規作成に使用できます。スナップショットは、耐久性の高い Amazon Simple Storage Service (S3) に保存されます。 AWS の常にクリエイティブなお客様は、EBS スナップショットをさまざまな興味深い用途に活用しています。バックアップや災害対策といったユースケース以外にも、スナップショットの用途として、本番環境から収集したデータを使用した分析用環境やテスト用環境のすばやい作成や、仮想デスクトップインターフェイス (VDI、Virtual Desktop Interface) 環境のサポートといったものがありました。ご存知と思いますが、EC2 インスタンスの起動に利用されている AMI (Amazon マシンイメージ) も、1 個または複数のスナップショットとして保存されます。 Fast Snapshot Restore 本日より、EBS の Fast Snapshot Restore (FSR) の提供を開始いたします。新規および既存のスナップショットで AZ (アベイラビリティーゾーン) ごとに有効化して、パフォーマンスを最大化する EBS […]

Read More

新機能 – シングルリージョン限定の Amazon DynamoDB テーブルをグローバルテーブルに変換する

何十万人もの AWS のお客様が Amazon DynamoDB を活用しています。AWS は 2017 年に、DynamoDB グローバルテーブルを提供開始しました。これは、マルチリージョン、マルチマスター対応の DynamoDB テーブルを独自のレプリケーションソリューションを構築して維持する必要なくデプロイできるフルマネージド型ソリューションです。グローバルテーブルを作成するときには、テーブルを使用できるようにしたい複数の AWS リージョンを指定します。DynamoDB は、これらのリージョンに同一のテーブルを作成して、進行中のデータ変更をそれらすべてに伝播するために必要なタスクのすべてを実行します。 AWS のお客様が DynamoDB グローバルテーブルを利用する主な 2 つの理由があります。クライアントに低レイテンシーの提供と、バックアップや災害対策の円滑化です。レイテンシーとは、ネットワークに転送要求を出してから実際にデータが送られてくるまでに生じる通信の遅延時間を指します。低いレイテンシーのアプリケーションでは、高い顧客エンゲージメントと、売上拡大が見込まれます。バックエンドをユーザーに近い複数のリージョンにデプロイすると、お客様のアプリケーションのレイテンシーが下がります。別のリージョンにデータをフルコピーしておくと、きわめてまれに起こるリージョン全体の不具合の際でもトラフィックをそのリージョンに切り替えやすくなります。AWS の CTO であるWerner Vogels 博士は以前に「障害は起こるものだ。あらゆるものは時間が経てば必ず障害が生じる」と述べています。 本日より、お持ちの DynamoDB テーブルはわずか数回のクリックでグローバルテーブルに変換できるようになりました。これには、直接AWS マネジメントコンソールから操作するか、または AWS コマンドラインインターフェイス (CLI) 、Amazon DynamoDB API のいずれかを使用します。これまでグローバルテーブルに変換できるのは空のテーブルだけでした。つまり、テーブルを作成する時点で、リージョン内のテーブルの使用法を推測する必要がありました。それが今回、テーブルのグローバル化や、既存のグローバルテーブルを別のリージョンへの拡張がいつでもできるようになりました。 レプリケーションの設定中であっても、ユーザーのアプリケーションではテーブルの使用を継続できます。テーブルにリージョンを追加すると、DynamoDB では既存のテーブルのスナップショットを使用して新しいレプリカの追加を開始します。DynamoDB で新しいレプリカを構築すると同時に、アプリケーションでは既存のリージョンに対して書き込みを継続します。進行中に生じたアップデートは最終的にはすべて新しいレプリカにレプリケーションされます。 AWS コマンドラインインターフェイス (CLI) を使用して DynamoDB グローバルテーブルを作成するために、まず米国西部 (オレゴン) リージョン (us-west-2) のローカルテーブルを作成します。 aws dynamodb create-table –region us-west-2 […]

Read More