Amazon Web Services ブログ

「AWS re:Invent のレビュー」といったブログカテゴリを追加した方がいいかもしれませんね。去年の 11 月、AWS Storage Gateway に重要な機能を追加しましたが、忙しすぎてその調査やブログを書く時間を取れずにいました。Storage Gateway は既存のアプリケーションと AWS Cloud の間に位置するマルチプロトコルストレージアプライアンスです。お使いのアプリケーションやクライアントオペレーティングシステムは (設定によりますが) ゲートウェイをファイルサーバー、ローカルディスクボリュームまたは仮想テープライブラリ (VTL) と見なします。その背景でゲートウェイはコスト効率が良く耐久性のある安全なストレージに Amazon Simple Storage Service (S3) を使用しています。Storage Gateway はデータをローカルでキャッシュし、帯域幅の管理機能を使用してデータ転送を最適化します。Storage Gateway はインストールや設定そして実行が簡単な自己完結型の仮想アプライアンスとして提供されています (詳細は「Storage Gateway のユーザーガイド (Storage Gateway User Guide) 」をご覧ください)。既存の環境でクラウドストレージのスケールや耐久性そしてコスト面におけるメリットを活用できます。既存のファイルやディレクトリを S3 に移動するプロセスを減らし、ドラッグアンドドロップ (または CLI ベースのコピー) でシンプルに移動できます。その他多くの AWS サービスと同様に、2012 年にリリースされてから Storage Gateway にいくつもの機能が追加されてきました (「AWS Storage Gateway – AWS クラウドストレージと既存のオンプレミスアプリケーションを統合 (The AWS […]

テクノロジーの進化とその改良を見るのは実に面白いものです。たとえば、最近の携帯電話にはハイエンドなデスクトップが備えるほどの解像度を持つ画面が使用されているほか、接続性や携帯性においても複数のオプションが提供されています。今週初めに、最新の Samsung Galaxy S8+ スマートフォンと、独自の新しいコンパニオンデバイス、Samsung DeX Station を試す機会に恵まれました。まず、スマートフォンに Android 向けの Amazon WorkSpaces クライアントをインストールし、WorkSpace の登録コードを入力してログインしてみました。これら一連の操作は、こちらの新しいビデオでご覧いただけます。 DeX にはキーボードとマウス用の USB コネクターが含まれています。Bluetooth で操作することもできます。冷却ファン、時間を短縮できるスマートフォンの充電器、HDMI とイーサネットポートも含まれています (スマートフォンのデータ通信または Wi-Fi 接続の使用も可)。すべて一緒にすれば、どこにいてもクラウドベースのデスクトップにアクセスできます。滞在先のテレビやモニターを使用すれば、企業ネットワークのフルアクセスでファイルやその他のリソースにアクセスできるので、旅先の荷物も軽くなります。 — Jeff; PS – 私の WorkSpace についてもう少し詳しく知りたければ「Amazon WorkSpace が大活躍 (I Love my Amazon WorkSpace)」をご覧ください。

本日、最大リリースであるLumberyard Beta 1.9がリリースされたことをお知らせします。 473以上に及ぶ改良、修正、および機能のリリースには、30分以下でプレーヤー認証を実装するための新しい Player Account  Cloud Gemが含まれ、複雑なコンテンツをより迅速に構築するためのComponent Entity workflow のアップデート、particle editorの新しいGPU機能とエミッタタイプ、視覚的に素晴らしい効果でゲーム世界を満たすことができ、そしてより多くの機能が追加されました。Lumberyard Beta 1.9 はこちらからダウンロードできます。 これらの改善は皆様の直接のフィードバックのお陰です。以前、私たちのチームの中核的哲学の1つである「continuous improvement（継続的改善）」の日本語であるカイゼンについて話しました。先月のGDCの素晴らしい提案とアイデアのおかげで、我々はLumberyardのいくつかの主要分野でのカイゼンへのコミットメントを強化することができました。ここにいくつかあります： New Player Account Cloud Gem 私たちがGDCで得た最も一般的なリクエストの1つは、より多くのCloud Gemsを提供することでした。2月にリリースされた当社独自のCloud Gems Frameworkにより、開発者は、1人のエンジニアとわずか30分で、ネットワーク通信が必要なゲーム要素（dynamic content、leaderboards、live messagesなど）を構築し、起動することが簡単になりました。今回のリリースでは、Player Account Cloud GemをLumberyardの成長し続けるGemコレクションに追加し、プレイヤーの認証と管理のためのカスタマイズ可能なスタンドアロンのソリューションを提供しています。プレイヤーがゲームに登録したときにゲームキーを要求したり、クラウドのプレーヤーのために追加のメタデータを保存したい場合、Player Account Cloud Gemを利用するとその時間と労力を節約できます。 理由は次のとおりです。これまではプレーヤーアカウントシステムを自分で実装するには、アカウント情報を保存するデータベースサービスをセットアップし、プレーヤー情報を安全なハッシュで保護をするための実装をし、サービスと電子メールシステムを実装する必要があります。 ID。また、ログイン・フロー、アイデンティティ・キャッシング、および期限切れの認証トークン更新プロセスをゲーム・クライアントでセットアップする必要があります。2〜3人のエンジニアがこの作業を行うには数カ月かかることがあります。何か間違ったことがあれば、プレイヤーがゲームに参加できないという危険性があります。Player Account Cloud Gemを使用すると、ほんの数ステップで実行できるように簡略化されているので、1人のエンジニアは約30分ですべてを実行できます。その結果、Cloud Gem Portal dashboardからプレーヤーのデータを管理し更新することができます。 Component Entity Workflows また、今年はGDCでComponent Entityシステムの最新のワークフローをデビューしました。皆様のご意見のおかげで、このリリースでゲームとエンジンの要素を構築するためのモジュラーで直感的な方法を提供する、いくつかの重要な改善を行う事ができました。新しいComponent Entityシステムの目標は、小規模なゲーム、カジュアルゲーム、大規模なAAAエクスペリエンスのいずれを構築しているかに関係なく、複雑で実用的なエンティティを短時間で最小限の労力で作成するのに役立てます。私たちが最近Component Entityシステムを改善したいくつかの方法を見てみましょう。 第1に新しいComponent Entityシステムでは、リフレクション、シリアライゼーション、およびメッセージングを使用して、エンジニアリングを必要とせずにコンポーネントの機能をデザイナーに自動的に公開します。これは、Lumberyard Editorでコンポーネントのプロパティをドラッグ＆ドロップして編集できることを意味し、わずか数回のクリックで「スライス」と呼ばれる完全にカスケード化されたプレハブを作成します。 第2に、努力を減らしイテレーションを加速するために、働かないエンティティを作成することは困難でした。たとえば、同じエンティティ（複数の静的メッシュなど）に重複するコンポーネントを追加しようとすると、システムは間違いを犯さないようにします。コンポーネントが機能するために別のコンポーネントを必要とする場合（単純なアニメーションコンポーネントではスキンメッシュが機能する必要があります）、依存関係を自動的に追加し、そうする必要はありません。 第3に、新しいComponent Entityシステムが欠落した構成や誤った構成をどのように処理するかについて、より柔軟に作成したいと考えました。エンティティに無効なコンポーネントや互換性のないコンポーネントが含まれるようになったときに、新しい警告システムでサービスの問題が表示されます。この警告は、問題を修正し、不足している依存関係をすばやく解決するのに役立ちます。たとえば、最初にシェイプを追加せずにプリミティブコライダーを追加すると、プリミティブコライダーはシェイプを追加することを提案します。ワンクリックで必要なシェイプのタイプを選択できます。シェイプが追加されるまで、プリミティブコライダーは登録されないため、シェイプを選択する前にゲームを実行すると実行時の問題を防ぐことができます。 最後に、皆様のフィードバックのおかげで、エンティティインスペクタの新しい使いやすさが改善されました。インスペクタでコンポーネントが追加された順序を覚えることができ、右クリックメニューからコンポーネントをより簡単に並べ替えることができます。（今後のリリースでドラッグ＆ドロップを追加する予定です）また、エンティティ間でコンポーネントの切り取り、コピー、貼り付けを可能にし、検索機能を改善して大量のコンテンツをナビゲートし、コンポーネントのUIを見直して読みやすくしました。 Particle […]

同僚の Mia Champion は科学者 (彼女が発表した記事) であり、AWS 認定ソリューションアーキテクト そして AWS 認定開発者でもあります。今回は、彼女が大量なデータのデータセットリサーチを行っている際に、バイオインフォマティクスにおけるクラウドコンピューティングの価値に気付いた時のことについてブログを投稿いただきました。 — Jeff; 科学研究における技術の進歩は、そのコンテンツにおいても複雑性を増し、日々急増しているデータセットのコレクションに可能性を与えています。世界中で加速化するイノベーションは、最近のクラウドコンピューティング革命によっても活気付けられ、一見したところ無限でスケーラブルそして迅速なインフラストラクチャを研究者に提供しています。現在では、研究者が独自のシーケンサー、マイクロスコープ、コンピューティングクラスターなどを所有するための障害を排除しています。クラウドを使用することで、科学者はギガバイトにも及ぶ何百万人という患者のサンプルのデータセットや各患者のその他の情報を簡単に保存、管理、処理そして共有することができます。アメリカの物理学者である John Bardeen はこのように言っています。「科学というものは協同して取り組むものです。数人の科学者が共に努力し出し合った結果を組み合わせることで、1 人の科学者が行うよりも効率よく研究を進めることができるのです (Science is a collaborative effort. The combined results of several people working together is much more effective than could be that of an individual scientist working alone)」 再現性のイノベーション、一般化、データ保護の優先 これまでにないスケールで、安全性を備えたクラウドを有効にしたデータ共有を活用する研究者や組織は日々増え、AWS クラウドを使用して革新的でカスタマイズした分析ソリューションを作り出しています。しかし、そうしたスケールの共同作業環境において、対象分野そして科学における従来の方法を根本的に変え、安全なデータ共有と分析を行うことは可能でしょうか?クラウドを有効にしたリソースの共同体を構築することで、研究結果の説明やその影響において問題となり、再現性の下落に繋げた分析変動性を排除することはできるのでしょうか? こうした疑問への答えは「イエス」です。Neuro Cloud Consortium、The Global Alliance for Genomics and […]

Elasticsearch、Logstash、および、Kibana（ELK）スタックを所有して運用する多くのお客様が、他の種類のログの中でもApache Webログを読み込んで可視化しています。 Amazon Elasticsearch Serviceは、AWSクラウドにElasticsearchとKibanaを提供しており、セットアップと運用が簡単です。 Amazon Kinesis Firehoseは、Amazon Elasticsearch ServiceにApache Webログ（またはその他のログデータ）をサーバーレスで確実に配信します。 Firehoseを使用すると、Firehose内のレコードを変換するAWS Lambda関数への自動呼び出しを追加できます。これらの2つのテクノロジーを使用すると、既存のELKスタックを効果的かつ簡単に管理することができます。 この記事では、最初にAmazon Elasticsearch Serviceドメインを設定する方法を説明します。次に、事前ビルドされたLambda関数を使用してApache Webログを解析するFirehoseストリームを作成して接続する方法を示します。最後に、Amazon Kinesis Agentでデータをロードし、Kibanaで可視化する方法を示します。

今日のビジネス環境では、多様なデータソースが着実に増加していく中で、データが継続的に生成されています。したがって、このデータを継続的にキャプチャ、格納、および処理して、大量の生データストリームを実用的な洞察に素早く繋げることは、組織にとって大きな競争上のメリットになっています。 Apache Flinkは、このようなストリーム処理パイプラインの基礎を形成するのに適したオープンソースプロジェクトです。ストリーミングデータの継続的な分析に合わせたユニークな機能を提供しています。しかし、Flinkを基にしたパイプラインの構築と維持には、物理​​的なリソースと運用上の努力に加え、かなりの専門知識が必要になることがよくあります。 この記事では、Amazon EMR、Amazon Kinesis、Amazon Elasticsearch Serviceを使用してApache Flinkを基にした、一貫性のあるスケーラブルで信頼性の高いストリーム処理パイプラインの参照アーキテクチャの概要を説明します。 AWSLabs GitHubリポジトリは、実際に参照アーキテクチャを深く理解するために必要なアーティファクトを提供します。リソースには、サンプルデータをAmazon Kinesisストリームに取り込むプロデューサアプリケーションと、リアルタイムでデータを分析し、その結果をAmazon ESに可視化するためのFlinkプログラムが含まれています。

Amazon Inspector は当社の自動セキュリティ評価サービスです。このサービスは AWS で実行するアプリケーションの動作を分析し、セキュリティ問題を識別する上で役立ちます。Inspector については 2015 年の後半にこのブログで紹介し、その使い方についてご説明したことがあります (「Amazon Inspector – 自動セキュリティ評価サービス (Amazon Inspector – Automated Security Assessment Service)」)。同サービスを使うには、まずタグを使用してアプリケーションを生成する AWS リソースのコレクションを定義します。次に、セキュリティ評価テンプレートを作成し評価の一部として実行したい一連のルールを特定します。 評価ターゲットとセキュリティ評価テンプレートを作成したら、クリック 1 つでターゲットリソースに対して実行することができます。この評価は Linux と Windows ベースの EC2 インスタンスで実行するエージェントを活用します (詳細については「AWS エージェント (AWS Agents)」をご覧ください)。評価は手動で実行したり、AWS Lambda を使用して既存の発券システムに結果を転送することができます (手順については「Amazon Inspector でセキュリティ脆弱性テストをスケールする (Scale Your Security Vulnerability Testing with Amazon Inspector)」をご覧ください)。実行するインスタンスが 1 件または何千件とある場合でも、定期的かつ頻繁に評価を行うことをおすすめします。デプロイや統合インスタンスといった DevOps パイプラインの一部として実行できます。そうすることで、セキュリティ評価テンプレートの作成時に選択したルールパッケージによる条件に見合った本稼働環境で、コードやシステムを安心してデプロイすることが可能になります。また、設定ドリフトを回避するため、本稼働システムに対しても頻繁に評価を実行することをおすすめします。Amazon Inspector には、次の強力な新機能を追加したばかりです。 評価レポート – […]

私のように、あなたは好きな本を読んでもらうために図書館か書店に行くのが好きかもしれません。幼い頃、声の抑揚を変えて話に命を吹き込むことができる上手な物語作家が物語る本の話を聞くのが好きでした。物語作家がよく使うスライド付きの本のナレーションは、新しい本を読んだり、見つけたりする私の趣味を駆り立てました。 実際、私の読書に関する趣味が古典小説にいたるように、両親はテープレコーダー付きの小さなプロジェクターを姉妹と私に買ってくれました。このプロジェクターは話を物語り、次のスクリーンに進むべきタイミングをチャイム音で知らせ、本と映像の投影を同期しました。不運にも、私はその話に夢中になってしまったけれど、私たちが TTS のようなスピーチ技術を実現するのにどれくらいの位置にいるのかについて振り返り、考えることが私にとって重要でした。あらゆるスピーチ技術の進歩をもってしても、TTS を利用して、ゲームやビデオ、デジタル書籍の中でキャラクターのアニメーションやグラフィックスに同期した会話／音声を追加することはデベロッパーにとって今だチャレンジングなものでした。加えて、リアルな音声のピッチやテンポ、音圧の強さを模倣するために TTS を利用したソリューションの成功事例は非常に稀でした。 これを踏まえて、Amazon Polly がスピーチマークとウィスパーをサポート開始することを私は喜んで発表します。 Amazon Polly はテキストをリアルな音声に変換することを可能にする深層学習を利用したサービスです。サービスが提供する24の言語と47のリアルな音声から好きな音声を選択することが可能です。Polly を使って、音声に変換したいテキストを Polly の API に送信することができます。そして、API は再生、もしくは、MP3 のような共通オーディオファイルフォーマットに保存可能なオーディオストリームを返却します。 スピーチマークはデベロッパーが映像体験と会話の同期を可能とするメタデータです。この機能は、会話を顔のアニメーションと同期することや、カラオケスタイルの単語の強調表示を利用することで、リップシンクのようなシナリオを可能とします。スピーチマークメタデータは合成された音声を記述します。そして、スピーチマークメタデータを会話と一緒に使うことにより、音声ストリームが音、語句、文、そして SSML タグの始まりと終わりを決定することができます。新しいスピーチマークを利用することで、デベロッパーは今、リップシンクするアバターや視覚的に強調表示された読み下し体験を生み出すことができ、そして、キャラクターに声を与えるために Amazon Lumberyard のようなゲーミングエンジンに会話能力を統合することができます。 スピーチマークには4つの種類があります： 文： 入力テキストの1文要素を明示する 語句： 入力テキストの1単語要素を表す ビゼーム(Viseme)： 話された音に対応する顔と口の位置を説明する Speech Synthesis Markup Language(SSML)： SSML で表現された入力テキストから <mark> タグを記述する ウィスパーはピッチやテンポ、音圧と似たスピーチエフェクトの１つで、デベロッパーに TTS 出力を装飾可能とするもう一つの音声表現機能を提供します。ウィスパー機能はデベロッパーが <amazon:effect name=”whispered”> SSML タグを使って、ささやき声で話される言葉を持つのを可能とします。 これら2つの新しい機能について、見てみることにしましょう。   スピーチマークの利用 AWS 管理コンソールで Amazon Polly […]

ミックスワークロードの環境下では、ビジネス上の要求を満たすために、バッチとインタラクティブのワークロード双方が同時に実行されます。ミックスワークロードを管理し構成するには、アクセスパターンやシステムリソースの使われ方、およびパフォーマンス要件についての詳細な理解が必要です。 ミックスワークロードでは、一般に、一部のプロセスが他より高い優先順位を必要とします。あるケースでは、これはあるジョブが特定のSLA内で完了しなくてはならないことを意味します。別のケースでは、あまりクリティカルではないレポーティングワークロードが一度に多くのクラスターリソースを消費しすぎないようにするだけでよいこともあります。 ワークロード管理（WLM）を利用しない場合、各クエリーは同じ優先順位で処理されます。これによって、あるメンバー、チーム、あるいはワークロードが、他のビジネス上重要なジョブに比べてさほど重要ではない処理のために、大量のクラスターリソースを消費するといった事態が起こり得ます。 このブログポストでは、一般的なWLMパターンに関するガイドラインを提供するとともに、WLMに関連する様々なクエリーとビューを使用して本番ワークロードの構成を最適化する方法について記載します。 ワークロードの概念 WLMを使用して、複数のビジネスワークロードを分離すると共に、システム上で実行される様々なタイプの同時実行クエリ−の優先順位を設定することができます。 インタラクティブ：実行する人間の入力を受け付けるソフトウェア。インタラクティブなソフトウェアには、BIツールやレポーティングアプリケーションなどのポピュラーなプログラムが含まれます。 短時間のみ実行される、読み取り専用のユーザークエリー。低レイテンシーで実行する要件を含むTableauダッシュボードクエリーなどが該当します。 長時間実行される、読み取り専用のユーザークエリー。過去10年間の営業データの集計する複雑な構造化レポートなどが該当します。 バッチ：手動介入を伴わない、サーバープログラム内の一連のジョブの実行（非インタラクティブ）。単一の入力ではなく、複数の入力の集合（”バッチ的な”入力とも言えます）に基づく一連のプログラムの実行は、カスタムジョブと呼ばれます。 一括で実行されるINSERT、UPDATE、およびDELETEトランザクションもバッチクエリーに含まれます。ETLやELTプログラムはこの一例です。 Amazon Redshift ワークロード管理（WLM） Amazon Redshift はスケーラビリティ、セキュリティおよび高パフォーマンスを提供する、ペタバイトスケール・カラムナー・超並列型の、完全に管理されたデータウェアハウスです。Amazon Redshiftは業界標準のJDBC/ODBCドライバーインターフェイスを提供します。これにより、お客様は彼らの既存のBIツールを用いて接続することができ、また既存の分析クエリーを再利用することが可能です。 Amazon Redshiftは様々な種類の分析的データモデルに適合します。例えば、スタースキーマ、スノーフレークスキーマや、 シンプルな非正規化テーブルなどが利用できます。 ワークロードを管理する Amazon Redshiftワークロード管理は、特定環境下における、様々なサイズと複雑性を持つワークロードの管理を可能にします。WLMの構成はパラメーターグループに含まれ、いくつのクエリーキューが処理に利用可能か、およびそれぞれのキューがどのようにそれらのキューにルーティングされるかを決定します。カスタムパラメーターグループを作成してグループ内の設定を編集し、それをクラスターに関連付けて下さい。以下のような設定が構成可能です。 それぞれのキュー内でいくつのクエリーが同時に実行可能か キュー間でのメモリ配分 クエリーがどのようにキューにルーティングされるか。誰がクエリーを実行しているか、クエリーレベルは、などの基準 あるキューにおけるクエリータイムアウト設定 ユーザーがクエリーを実行する際、WLMはそのクエリーを最初にマッチしたキューに割り当てた上で、WLMの構成に基づいてルールを実行します。WLMクエリキュー、同時実行、ユーザーグループ、クエリーグループ、タイムアウト設定、およびキューホッピング機能等の詳細については、クエリーキューの定義を参照して下さい。動的に変更可能な構成プロパティの詳細については、WLM の動的設定プロパティと静的設定プロパティを参照して下さい。 例えば、以下のスクリーンショットのWLM構成では、ETL、BI、およびそれ以外のユーザーをサポートするための三つのキューが構成されています。ETLジョブは長時間実行用のキューに割り当てられ、BIクエリーは短時間実行用のキューに割り当てられます。その他のユーザーのクエリーはデフォルトキューで実行されます。   WLM最適化クラスター構成のガイドライン 1. 複数のビジネスワークロードを分離し、クエリーを互いに独立して実行する。 ダッシュボードクエリーとETLといった異なるビジネスプロセスをサポートするため、互いに独立したキューを作成します。例えば、ワンタイムクエリーのための独立したキューを作成することは、それらのクエリーがより重要なETLジョブを阻害しないようにするための有益なソリューションと言えます。 また、より短時間で実行されるクエリーは一般的にメモリー使用量が少ないため、それらのワンタイムユーザーやクエリーグループ用のキューには、より低いWLM使用メモリー比率（訳者註：マネジメントコンソール上の”メモリ（％）”の設定値）を設定することができます。 2. 同時実行数やメモリー割り当てをアクセスパターンに合わせてローテーションする。（適合するユースケースの場合） トラディショナルなデータ管理では、ETLジョブはソースシステムから特定のバッチウィンドウ内でデータを取得、整形した後、ターゲットのデータウェアハウスにロードします。このアプローチでは、業務時間中は、BI_USERグループにより多くの同時実行数とメモリを割り当て、ETL_USERには非常に限られたリソースのみを割り当てます。業務時間後は、重くリソースインテンシブなジョブが迅速に完了するよう、ETL_USERへの割り当てを動的に変更またはスイッチすることを、クラスターの再起動なしに行うことが可能です。 注：下記のAWS　CLIコマンドサンプルはデモ目的のために、複数の行で表示されています。実際のコマンドは改行を挟まず一行で実行する必要があります。また、下記のJSON構成にはエスケープクォートが必要です。 WLM設定を動的に変更する方法として、AWSはスケジュールされたLambda関数あるいはスケジュールされたデータパイプライン（ShellCmd）をお勧めします。 3. ミックスワークロード（ETLとBIワークロード）を継続的にサポートないし最適化するために、キューホッピングを使用する WLMキューホッピングは、読み取り専用クエリー（BI_USERのクエリー）が、キャンセルされる代わりにあるキューから別のキューに移動することを可能にします。例えば、以下のスクリーンショットにあるように、二つのキュー（一つはタイムアウトが60秒に設定されたインタラクティブクエリー用のもの、もう一つはタイムアウトなしで設定されたバッチクエリー用のもの）を作成し、同じユーザーグループ（BI_USER）をそれぞれのキューに設定します。WLMは、インタラクティブキューで実行され、タイムアウトしたBI_USERのクエリー（のみ）を、バッチキューに自動的に再ルーティングし再実行します。 この例では、ETLワークロードはBIワークロードクエリーを阻害しません。長時間実行されている読み取り専用クエリーは、自動的にバッチとして分類され、より短時間で完了するクエリーをブロックしないようになります。 4. リソースインテンシブなETLやバッチクエリー用に、スロットカウントを一時的に増やす。 Amazon Redshiftはメモリー不足エラーを回避するために中間結果をディスクに書きますが、ディスクI/Oはパフォーマンスを劣化させる要因となります。次のクエリーは、ディスク上で実行されているアクティブクエリーを表示します。 SELECT query, label, is_diskbased FROM svv_query_state […]

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 を使用できるように更新する必要があります。 ソリューション構築時の制限は、あなたの想像力のみです。それでは、以下にボット作成やデプロイにおける創作力をサポートするアドバイスをいくつかご紹介します。チャットボットをよりユニークにするためのアドバイスについては次をご覧ください。 Slack、Facebook […]