Amazon Web Services ブログ

はじめに AWS では、機械学習モデルの開発、学習、推論に最適な AWS サービスを提供しています。これらを活用することで、お客様は、データに基づく適切なビジネス判断、高品質な顧客サービスの提供、コンプライアンスの遵守等の実現が可能となります。ただし、機械学習モデルが扱うデータには細心の注意が必要です。機械学習モデルの学習データと推論時に入力されるデータに、許容範囲を超えた乖離が発生すると、モデルは期待した精度で推論結果を返すことができなくなります。昨今、 COVID-19 や企業のデジタルトランスフォーメーション (DX) の影響等で、一般消費者の生活スタイルやソーシャルネットワークでの言動、企業における従業員のワークスタイルや財務状況に至るまで、様々な指標に、予測を超えた変化が起きている可能性があります。これらは、それまでに学習された機械学習モデルの精度に影響を与える可能性があります。このように、推論時の入力データや出力結果が、学習時の許容範囲を超えて変化することをデータドリフトと呼びます。( 注釈 : データドリフトまたはデータシフトの文脈では、共変量シフト (covariate shift) やコンセプトドリフト (concept drift) などの概念、用語が使われることもありますが、本記事では、データドリフトという用語を、上記の定義に基づいて使用します。) このデータドリフトを継続的に監視する仕組みが、精度の高い推論を提供し続けるために重要です。 AWS は、このようなデータドリフト検知を含め、機械学習を組み込んだアーキテクチャにおけるベストプラクティスを、Machine Learning Lens というホワイトペーパーで公開しています (日本語版) 。また、 Amazon SageMaker を活用しているお客様は、 Amazon SageMaker Model Monitor ( 以下、 Model Monitor ) を活用して、すぐにデータドリフトの検知を開始することが可能です。本記事では、 AWS を利用した機械学習システムの検討や実装に関わる皆様を対象に、 Model Monitor のアウトプットをどのように解釈しデータドリフトの検知に利用できるのか、関連する論文や技術を、できるだけ具体的、かつ簡潔に解説したいと思います。 機械学習のビジネス活用においては、モデルのベースとなるアルゴリズムの正しい理解が重要です。それと同じように、データドリフトの検知に活用されている様々なアルゴリズムや技術についても理解することは、誤ったビジネス活用を未然に防ぐために必要不可欠です。AWS では、クラウドならではのスピード感で、すぐに Model Monitor を活用したデータドリフト検知を開始することが可能です。私たちプロフェッショナルサービスのコンサルタントは日頃、AWSを活用した機械学習モデルの開発、学習、推論のためのアーキテクチャの最適化についてガイドしています。コンサルタントにはデータサイエンティストや Machine Learning ( 以下、ML ) エンジニアなどがおり、関連論文に関する知識や現場で得たノウハウを蓄えています。本記事により、みなさまのご理解の一助となれば幸いです。 […]

産業機器を運用する企業は、運用効率性の向上と、コンポーネントの故障による計画外ダウンタイムの回避に絶えず取り組んでいます。これらの企業は長年の間、機器の状態を監視し、リアルタイムのアラートを受け取るために、物理センサー (タグ)、データ接続、データストレージ、およびダッシュボードの構築に多額の投資を繰り返し行っています。主なデータ分析手法は、単一変数の閾値と物理学に基づくモデリングのアプローチであり、これらの手法は特定の故障タイプや稼働状態の検出には効果的ですが、各機器の多変量関係を導き出すことによって検出される重要な情報を見逃すことがよくあります。 機械学習の使用により、機器の履歴的なデータから学習するデータ駆動のモデルを提供できる、より強力なテクノロジーを利用できるようになりました。しかし、このような機械学習ソリューションの実装は、設備投資とエンジニアのトレーニングが原因で時間がかかり、コストも高額になります。 本日は、機器の異常な動作を検出する API ベースの機械学習 (ML) サービス、Amazon Lookout for Equipment をご紹介します。Lookout for Equipment を使用することによって、お客様は、モデルごとにセンサーやアクチュエータなどのコンポーネントからのデータタグを最大 300 個設定できる、産業機器から生成された履歴的な時系列データと過去のメンテナンスイベントを取り込むことができます。Lookout for Equipment は、可能な組み合わせを自動的にテストし、機械学習モデルを構築して機器の正常な動作を学習します。エンジニアに機械学習の専門知識は必要なく、クラウドでリアルタイム処理のためのモデルを簡単にデプロイできます。

2017 年の Amazon Connect のローンチ以来、何千社ものお客様がクラウドで独自にコンタクトセンターを構築しておられます。Amazon Connect は、非技術系のお客様によるインタラクションフローの設計、エージェントの管理、およびパフォーマンスメトリクスの追跡を容易にします。 たとえば、ヨーロッパで Best Western ホテルの部屋を電話で予約した場合、その通話は Amazon Connect によって管理されます。イギリスでは、郵便局が、アイデアから本稼働開始までわずか 3 週間で完了しました。フランスでは、ビジネスプロセスアウトソーシングの世界的リーダーである WebHelp が、わずか 72 時間で数千台のワークステーションとリモートエージェントをアクティブ化しました。 Amazon Connect について最後にブログを投稿して以来、チームは継続的にお客様からのフィードバックを聞いています。本日、Amazon Connect をよりスマートにし、サードパーティのツールとの統合を強化する新しい機能セットを発表できることをうれしく思います。 機械学習 (ML) を使用して、Amazon Connect が、会話をリアルタイムで分析し、コンタクトセンターのエージェントが必要とする関連情報を見つけ、顧客の声で顧客を認証することで、よりスマートにしてます。2 番目の機能セットにより、Amazon Connect はサードパーティのツールやサービスとの統合が容易になり、統合化された顧客プロファイル情報をコンタクトセンターエージェントに提示し、タスクの管理を容易にします。 それでは、詳細を一つずつ見ていきましょう。 Contact Lens Real Time Contact Lens for Amazon Connect は、機械学習 (ML) 機能のセットです。これを使うと、コンタクトセンターのスーパーバイザーは、顧客との会話の感情、傾向、コンプライアンスをよりよく理解することができます。re:Invent 2019 で初めて発表され、2020 年 7 月から 利用可能になりました。エージェントを効果的にトレーニングし、成功したインタラクションを複製し、企業と製品に関する重要なフィードバックを特定することができます。 本日から、顧客が不満を表明するなど、ライブ通話中のカスタマーエクスペリエンスに関するリアルタイムの洞察を得ることができます。カスタマーエクスペリエンスの分析とライブコールのアラートは、Amazon Connect のリアルタイムメトリクスダッシュボードで配信されます。スーパーバイザーは、重要なコールをいつリッスンするかを特定し、チャットを介してエージェントにガイダンスを提供したり、エージェントにコールを転送して支援を求めたりすることが容易になります。 […]

2020 年 12 月 1 日 AWS re:Invent で、AWS Panorama Appliance のプレビューを行いました。また、AWS Panorama SDK が近日公開される予定であることも発表いたしました。これにより、組織はコンピュータビジョンをオンプレミスのカメラに取り込み、高精度で低レイテンシーな自動予測を行うことができます。 過去数十年にわたり、コンピュータビジョンは、学者によって議論されるトピックから、世界中の企業で使用されるツールへと変化してきました。この成長を実現するうえで、クラウドが重要であり、これまで不可能だったサービスやインフラストラクチャ機能が急増しています。 お客様は、製造ライン上の部品の検査、危険な場所での作業員のヘルメットの着用の確認、小売店での顧客トラフィックの分析など、物理的なシステムに関するさまざまな課題に直面しています。お客様は、多くの場合、問題やインシデントが発生した後に、ライブビデオフィードを手動で監視したり、録画した映像を確認したりして、これらの問題を解決しています。こうしたソリューションは、手作業でエラーが発生しやすく、拡張が困難です。 コンピュータビジョンは、クラウドで実行されているモデルを使用して、こうした検査タスクを実行するためにますます使用されています。それでも、レイテンシーの要件や断続的な接続により、クラウドへのラウンドトリップを実現できないため、クラウドのみに依存することが最適ではない場合があります。 本日の発表内容 これからは、Amazon SageMaker を使用してコンピュータービジョンモデルを開発し、それを Panorama Appliance にデプロイして、複数のネットワークと IP カメラからのビデオフィードでそのモデルを実行させることができるようになります。Panorama Appliance と関連するコンソールがプレビュー中です。 近日公開予定の Panorama SDK は、サードパーティデバイス製造元が Panorama 対応デバイスを構築するために使用できるソフトウェア開発キット (SDK) です。Panorama SDK は柔軟性が高く、設置面積が小さく、ハードウェアベンダーがさまざまなフォームファクタやセンサで新しいデバイスを簡単に構築できます。したがって、工業用地、低照度シナリオ、屋外など、さまざまな業界や環境のユースケースを満たすことができます。 アプライアンスの開梱 このブログを書くことができるように、AWS re:Invent の数週間前に Jeff に Panorama Appliance が送られました。これは、Jeff のオフィスに設置されたデバイスの写真です。 Panorama Applianceをセットアップするには、コンソールに移動し、[Get Started] をクリックします。 コンソールには、Panorama Appliance […]

この記事は、New AWS Amplify Admin UI Helps You Develop App Backends, No Cloud Experience Requiredを翻訳したものです。 2018年にAWS Amplifyをリリースしてから、ウェブのフロントエンドとモバイルアプリケーションの開発者の開発とクラウド環境へのデプロイを支援してきました。時代の最先端を行き、顧客にイノベーションを提供するためにもプロダクトは機能を素早く届ける必要があります。しかし、クラウド、AWSの基本的な操作に慣れていない場合は、開発者・非開発者に関わらず学習やトレーニングが必要となります。この学習コストは、設計や実装、意思判断などプロセス全体の速度の低下を招きます。 本日、AWS AmplifyはチームメンバーがAWSアカウントを必要とせずにAWSの利用を可能とする新機能Admin UIをリリースしました（AWSアカウントは、最初のデプロイでのみ必要となります）。 Admin UIは、データベーステーブルのモデリング、認可認証機能の追加、アプリケーションのコンテンツ・管理者・管理者グループの管理を行うシンプルで強力なツールを提供します。また、アプリケーションのユーザーや、ユーザーによって作成されたコンテンツの管理を行う機能も提供します。Admin UIは、バックエンドやインフラストラクチャではなくデータモデルに焦点を当てています。全てのバックエンドのリソースは、チームのリポジトリで管理可能なInfrastructure as Code（IaC）のテンプレートを生成します。また、このリソースはAWS Amplifyの継続的デプロイのワークフローと統合されており、異なる環境（environment）ごとに管理が可能となっています。 新機能: AWS Amplify Admin UIを使った例のご紹介 あなたは、地元にあるレストランのウェブサイトを開発しているフロントエンド開発者であると想像してみてください。レストランのオーナーは、日替わりメニューを掲載できるようなウェブサイトで、毎日ウェブサイト上のコンテンツを簡単に更新したいと考えています。 この要求を満たすシステムの実装方法は多くあります。例えば、サーバーを構築し、CMSをインストールし、レストランのオーナーが日替わりメニューの更新を行うための機能を実装することができます。しかし、この要求を満たすためだけにサーバーを構築するのは、過剰に設備投資を行うことになります。他の実装方法として、サーバーレスのサービスを使用して自分でCMSを構築することもできますが、開発が複雑になり、より多くの時間が開発をするのに必要となります。 AWS Amplifyの新機能Admin UIを活用することで、既存のAWSのマネージドサービスを活用しながらバックエンドを素早く構築することができます。また、アプリケーションのユーザーとコンテンツの管理を行う機能も提供します。 Admin UIを利用するために、最初にAWS Console内のAWS Amplifyの管理画面にてアプリケーションのバックエンド（backend）を作成してください。これにより、AWS Amplifyはstagingと呼ばれるバックエンドの環境（environment）を作成します。バックエンドの作成が完了したら、早速Admin UIを開いてみましょう。AWSの利用経験がなく、AWSアカウントを持っていない開発者を招待したい場合は、この段階でAdmin UIへのアクセス権限を付与することができます。今回の例では、あなた一人で全ての開発を行う想定とし、管理者の追加は行わないこととします。 Admin UIでは、アプリケーションの開発者がバックエンドを構成するために必要な開発ツールと、コンテンツの管理者がアプリケーションのコンテンツを管理するための機能が含まれています。 Admin UIのサイドバー（下記の画像参照）にて、アプリケーションの設定を行うための様々なオプションを確認することができます。 レストランのウェブサイト構築を行う最初のステップとして、日替わりメニューのためのデータモデルを作成してみましょう。次の3ステップを実行してみましょう Dataタブに移動 Menuという名前でデータモデルを作成 必要なデータ項目を追加して保存とデプロイ データモデルを保存とデプロイを行うと、メニュー項目を保存するAmazon DynamoDBのテーブルやGraphQLのAPIを提供するAWS AppSyncなどのリソースがAWS上に自動で作成されます。 デプロイの完了には数分程度かかります。 モデルがデプロイされたら、次にウェブサイトのフロントエンドを構築してみましょう。今回は、AWS […]

本日、Amazon Monitron を発表しました。Amazon Monitron は状態モニタリングサービスで、潜在的な障害の検出、および開発中の誤りの追跡により、予知保全を実施し、予期しないダウンタイムを低減できます。 実話：数ヶ月前、私は新しい洗濯機を購入しました。配達業者が地下室にそれを設置した時に、最近製品は数年も持たなく、信頼できなくなっていることについて雑談しました。彼が去ろうした時に、私は老朽化してメンテナンスが不十分な給湯器を指さし、数週間後にこれを新しいものと交換することを伝えました。信じがたいことに、次の日それが壊れました。どうぞ、笑ってください。事前に計画していないので当然のことです。 この出来事には苛立ちましたが、生産ラインや倉庫などの産業環境で機械の予期せぬ故障による時間やコストの巨大な損失に比べれば、何てことありません。砂粒が原因で予定外の停止が起こることもあります。事は最悪の形で、最悪の時に起こる可能性が高い、そして結果として、深刻なビジネスへの影響をもたらすということを、マーフィーの法則から学びました。 故障を回避するために、信頼性マネージャやメンテナンス技術者が次の 3 つの戦略を組み合わせることがよくあります。 故障まで実行 ：確実に動作しなくなるまで、メンテナンスをせずに機器を操作させる。修理の完了後、機器を稼働状態に戻す。ただし、機器の状態は不明で、故障は制御不能です。 計画的保守 : 状態に関係なく、事前定義された保守作業が定期的または計量の基準で実行される。計画的なメンテナンス活動の有効性は、メンテナンスの指示や計画するサイクルの良し悪しに依存します。機器のメンテナンスが過剰だったり、あるいは不十分だったりする場合に、不必要なコストが発生したり、故障が発生したりする危険性があります。 状態基準保全 : 監視対象コンポーネントの状態が定義済みのしきい値を超えたときにメンテナンスを完了させる。耐性、振動、温度などの物理的特性を監視することは、より適切な戦略です。これにより、メンテナンスの必要性やメンテナンスコストを低減できます。 予知保全 : コンポーネントの状態を監視し、潜在的な障害を検出し、障害の発生を追跡する。メンテナンスは、将来予想される障害発生の前に、且つメンテナンスの総コストが最も効率の高いときに計画します。 状態基準保全と予知保全では、重要な機器にセンサーを設置する必要があります。これらのセンサは、温度や振動などの物理量を測定し、取得します。その変化は、潜在的な故障または悪化状態の先行指標となります。 ご想像のとおり、このようなメンテナンスシステムの構築と導入には、特注のハードウェア、ソフトウェア、インフラストラクチャ、プロセスなどが必要で、長期的かつ複雑でコストのかかるプロジェクトになる可能性があります。お客様から支援を求められ、この事業に取り組みました。 Amazon Monitron のご紹介 Amazon Monitron は、簡単に利用ができて、費用対効果の高い監視サービスで、施設内の機器の状態を監視し、予知保全プログラムを実施します。 Amazon Monitron の設定はとても簡単です。まず、 Monitron センサーをインストールします。これで、ベアリング、ギアボックス、モーター、ポンプ、コンプレッサ、ファンなどの回転機械から振動と温度データを取得します。センサーは、Bluetooth Low Energy (BLE) 技術を使用して、振動と温度の測定値を近くの Monitron ゲートウェイに毎時送信します。センサーを少なくとも 3 年間稼働させることができます。 Monitron ゲートウェイ自体は WiFi ネットワークに接続され、センサーデータを AWS に送信します。データは格納され、機械学習と ISO 20816 振動関連規格を使用して分析されます。 通信頻度が低いため、最大 20 個のセンサーを 1 […]

Amazon Elastic Block Store (EBS) は、あらゆる規模のスループット集約型のワークロードとトランザクションを集中的に使用するワークロードの両方で Amazon EC2 インスタンスとともに使用するために設計された、使いやすく高性能なブロックストレージサービスです。既存の汎用ソリッドステートドライブ (SSD) gp2 ボリュームを使用すると、ストレージキャパシティーに応じてパフォーマンスをスケールできます。より大きなストレージボリュームのサイズをプロビジョニングすることで、アプリケーションの 1 秒あたりの入力/出力オペレーション (IOPS) とスループットを向上させることができます。 ただし、MySQL、Cassandra、Hadoop クラスターなどの一部のアプリケーションは、高パフォーマンスを必要としますが、高キャパシティーストレージは必要としません。お客様は、必要以上のストレージボリュームに料金を支払うことなく、このようなタイプのアプリケーションのパフォーマンス要件を満たすことを望んでいます。 本日は、ストレージキャパシティーに関係なくパフォーマンスをプロビジョニングでき、既存の gp2 ボリュームタイプよりも 20% 低い価格で提供される、新しいタイプの SSD EBS ボリュームである gp3 について説明したいと思います。

本日、完全マネージド型運用サービスの Amazon DevOps Guru を発表します。Amazon DevOps Guru は、運用上の問題を自動的に検出して修正を推奨することで、デベロッパーやオペレーターがアプリケーションの可用性を容易に向上させることができるようにするサービスです。DevOps Guru は、Amazon.com とアマゾン ウェブ サービス (AWS) の長年にわたるオペレーショナルエクセレンスを習得した機械学習を適用し、アプリケーションメトリクス、ログ、イベントなどのデータを自動的に収集および分析し、通常の運用パターンから逸脱した動作を特定します。 動作が運用上の問題またはリスクとして特定されると、DevOps Guru はデベロッパーとオペレーターに問題の詳細を通知し、問題の範囲と原因の可能性を迅速に把握できるようにします。DevOps Guru では問題を解決するためのインテリジェントな推奨事項が提供されるため、解決までにかかる時間を節約できます。DevOps Guru では、ハードウェアやソフトウェアをデプロイする必要はなく、分析されたデータに対してのみ課金されます。前払いコストやコミットメントは発生しません。 分散された/複雑なアーキテクチャとオペレーショナルエクセレンス アプリケーションの分散化と複雑化が進むにつれ、オペレーターはアプリケーションの可用性を維持し、運用上の問題の検出、デバッグ、および解決に費やす時間と労力を削減するために、より自動化されたプラクティスを必要とします。例えば、設定ミス、不均衡なコンテナクラスター、またはリソースの枯渇などによるアプリケーションのダウンタイムは、企業にとって大きな収益損失につながる可能性があります。

Amazon Elastic Block Store (EBS) ボリュームは、2008 年の発売以来、EC2 の必要不可欠なコンポーネントです。現在、特定のユースケースに対応し、指定されたパフォーマンスが得られるように設計された 6 種類の HDD ボリュームおよび SSD ボリュームから選択できます。 今年初めに、以前の io1 ボリュームよりも 100 倍高い耐久性と 10 倍の IOPS/GiB を備えた io2 ボリュームを発売しました。io2 ボリュームは、ハイパフォーマンスでビジネスクリティカルなワークロードなど、I/O 負荷が高くレイテンシーの影響を受けやすいアプリケーションに最適です。 さらに進化 本日から、さらに優れたパフォーマンスを提供する io2 Block Express ボリュームのプレビューを開始します! このボリュームは、AWS Nitro System の一部として実装された高度な通信プロトコルを活用した新しい EBS Block Express アーキテクチャに基づいて構築され、最大 256 K IOPS と 4000 MBps のスループット、最大 64 TiB のボリュームサイズを実現します。すべてミリ秒未満で、低分散 I/O レイテンシーです。スループットは、プロビジョンド IOPS ごとに […]

AWS Lambda では、サーバーについて気にすることなくコードをアップロードして実行できます。多くのお客様に Lambda のこの仕組みをご活用いただいていますが、開発ワークフローのためにコンテナツールに投資した場合は、Lambda でのアプリケーションの構築に同じアプローチを使用することが難しくなります。 この問題に対応するため、Lambda 関数を最大 10 GB のコンテナイメージとしてパッケージ化し、デプロイできるようになりました。これにより、機械学習やデータ集約型のワークロードなど、大きな依存関係に頼る大規模なワークロードを簡単に構築してデプロイできます。ZIP アーカイブとしてパッケージ化された関数と同様に、コンテナイメージとしてデプロイされた関数は、同様の操作のシンプルさ、自動スケーリング、高可用性、多数のサービスとのネイティブ統合による恩恵を受けます。 当社では。サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。 Alpine や Debian Linux をベースにしたイメージなど、独自のベースイメージを任意で Lambda にデプロイできます。Lambda を操作するには、これらのイメージに Lambda ランタイム API を実装する必要があります。独自のベースイメージの構築を容易にするため、当社ではサポートされているすべてのランタイムにランタイム API を実装する Lambda Runtime Interface Clients をリリースしています。これらの実装は、ネイティブのパッケージマネージャーを介して利用できるため、イメージ内で簡単に取得でき、オープンソースライセンスを使用してコミュニティと共有されます。 また、Lambda Runtime Interface Emulator をオープンソースとしてリリースします。これにより、コンテナイメージのローカルテストを実行して、Lambda にデプロイした際に実行されることを確認することができます。Lambda Runtime Interface Emulator は、AWS が提供するすべてのベースイメージに含まれており、任意のイメージでも使用できます。 コンテナイメージは、Lambda Extensions […]