Amazon Web Services ブログ

 信用貸しを行う金融機関は、各融資申請に関連する信用リスクを評価し、引き受けるリスクのレベルを定義するしきい値を決定するという二重のタスクに直面しています。信用リスクの評価は、機械学習 (ML) 分類モデルを一般的に当てはめて行います。ただし、分類のしきい値の決定は、多くの場合、副次的な関心事として扱われ、その場しのぎで原則のない方法で設定されます。その結果、金融機関はパフォーマンスの低いポートフォリオを作成し、リスク調整後のリターンをテーブルに残している可能性があります。 このブログ記事では、Amazon SageMaker の自動モデルチューニングを使用して、融資対象の借り手のサブセットを選択する貸し手のポートフォリオ値を最大化する分類しきい値を決定する方法について説明します。より一般的には、分類設定で最適なしきい値またはしきい値のセットを選択する方法について説明します。ここで説明する方法は、経験則や一般的なメトリクスに依存しません。これは、目前の問題に固有のビジネスの成功指標に依存する体系的かつ原則的な方法です。この方法は、効用理論と、合理的な個人は期待される効用または主観的価値を最大化するために意思決定を行うという考えに基づいています。 この記事では、貸し手は、融資申し込みを、受け入れた上で貸し出すグループと、受入れを拒否するグループの 2 つのグループに分ける分類のしきい値を選択することにより、ポートフォリオの期待ドル価値を最大化しようとしていると仮定します。言い換えれば、貸し手は、ポートフォリオ値を説明する関数の最高値となるしきい値を見つけるために、潜在的なしきい値のスペースを検索しています。 この記事では、Amazon SageMaker の自動モデルチューニングを使用して、最適なしきい値を見つけます。付随する Jupyter ノートブックは、このユースケースをサポートするコードを示しています。これは、モデルのパフォーマンスを最適化するハイパーパラメータを選択するために通常使用する自動モデルチューニング機能の新しい使用法です。この記事では、特定のパラメータ空間で関数を最大化する一般的なツールとして使用しています。 このアプローチには、一般的なしきい値決定アプローチに比べていくつかの利点があります。通常、分類しきい値は 0.5 に設定されます (またはデフォルトに設定されます)。このしきい値は、ほとんどのユースケースで可能な最大の結果を生成しません。対照的に、ここで説明するアプローチでは、対処する特定のビジネスユースケースの最大の結果を生成するしきい値を選択します。この記事のユースケースでは、説明した方法で最適なしきい値を選択すると、ポートフォリオ値が 2.1% 増加します。 また、このアプローチは、最適なしきい値を決定する際に一般的な経験則と専門家の判断を使用するだけではありません。分類問題に体系的に適用できる構造化されたフレームワークをレイアウトします。さらに、このアプローチでは、モデルの予測とその利点とコストに対して実行される特定のアクションに基づいて、ビジネスがコストマトリクスを明示的に提示する必要があります。この評価プロセスは、モデルの分類結果を単純に評価するだけではありません。このアプローチは、ビジネスにおける挑戦的な議論を促し、オープンな議論と合意のためにさまざまな暗黙の意思決定や評価を明らかにすることができます。これにより、単純な「この価値の最大化」から、より複雑な経済的トレードオフを可能にするより有益な分析に至る議論が促進され、ビジネスにより多くの価値がもたらされます。 このブログ記事について 読む時間 20 分 完了するまでの時間 1.5 時間 完了するためのコスト ～2 USD 学習レベル 高度 (300) AWS のサービス Amazon SageMaker 背景 貸し手が潜在的なローンのプールからポートフォリオを構築しようとしていると仮定します。このユースケースに取り組むには、貸し手はまず、各ローンのデフォルトの確率を計算することにより、プール内の各ローンに関連する信用リスクを評価する必要があります。ローンに関連するデフォルトの可能性が高いほど、ローンに関連する信用リスクが高くなります。ローンのデフォルトの確率を計算するために、貸し手はロジスティック回帰やランダムフォレストなどの ML 分類モデルを使用します。 貸し手がデフォルトの確率モデルを推定したとすると、ローンが有し得る最大のデフォルト確率を設定し、ローンを貸し出す意思があるしきい値をどのように選択すればよいでしょうか? 分類モデルのユーザーは、多くの場合、しきい値の値を従来のデフォルト値の 0.5 に設定しています。ユースケース固有のしきい値を設定しようとしても、精度や再現率などのしきい値ベースのメトリクスを最大化することに基づいて設定します。メトリクスの問題の 1 つは、分類マトリクスに記述されている個別の結果の特定の部分を無視することです。たとえば、精度は真と偽の負の結果を見落とします。さらに、これらのメトリクスには、分類マトリクスの各セルに関連するコストと利点が組み込まれていません。たとえば、この記事で検討する場合、各ローンに関連付けられたデフォルトを考慮した金利と損失は、一般的なしきい値ベースの測定の計算では無視されます。最終的に、ビジネスの価値はそのモデルの精度や再現率ではなく、特定のモデルとしきい値を使用することによる増分利益のドル価値であるため、この状況は理想的ではありません。 したがって、一般的なメトリクスを使用する代わりに、目の前の特定のビジネスユースケースのコストと利益の構造を捉えたしきい値ベースのメトリクスを設計することが、ビジネスにとってより有益で有意義です。この記事で説明する貸し手は、特定の借り手に貸すかどうかを決定しています。そのため、予測されるデフォルトの確率を考慮して各ローンの予想利子と損失を組み込んだメトリクスは、精度や再現率などの一般的なメトリクスよりも、ビジネスとその意思決定プロセスにより関連性があります。具体的には、定義するポートフォリオ値メトリクスは、各ローンを真陽性 (TP)、偽陰性 (FN)、真陰性 (TN)、および偽陽性 (FP) の […]

 学術研究とオープンソースソフトウェア開発は、機械学習 (ML) 技術開発の最前線にあります。2017 年以降、 AWS Machine Learning Research Awards (MLRA) は機械学習の進化を目指し、革新的な研究への資金提供や、学生へのトレーニング、さらに研究者への最新技術の提供を行ってきました。MLRA は、MLアルゴリズム、コンピュータービジョン、自然言語処理、医学研究、神経科学、社会科学、物理学、ロボット工学などの分野において、100 件を超える最先端の ML プロジェクトをサポートしてきました。MLRA が支援するプロジェクトの多くが、メディアで取り上げられています。たとえば、「Researchers are Using Machine Learning to Screen for Autism in Children」、「The Robotic Future: Where Bots Operate Together and Learn from Each Other」、「Autonomous Vehicles: The Answer to Our Growing Traffic Woes」、「Amazon Gives AI to Harvard Hospital in Tech’s Latest Health […]

 AWS 上でビッグデータの ETL ワークフローを実行している大企業は、多数の内部エンドユーザーにサービスを提供できるようなスケールで運用しており、何千もの同時パイプラインを実行しています。これは、新しいフレームワークと、ビッグデータ処理フレームワークの最新のリリースに後れを取らないためにビッグデータプラットフォームを更新し拡張する継続的なニーズだけでなく、ビッグデータプラットフォームの管理の簡素化、そしてビッグデータアプリケーションへの容易なアクセスの促進の両方を可能にする効率的なアーキテクチャと組織構造が必要となります。 この記事シリーズのパート 1 では、Apache Airflow、Genie、および Amazon EMR を使用してビッグデータワークフローを管理する方法を学びました。 今回の記事では、AWS CloudFormation テンプレートのデプロイメント、Genie の設定、および Apache Airflow で作成されたワークフロー例の実行について説明していきます。 前提条件 このウォークスルーには、以下の前提条件が必要です。 AWS アカウント ソリューションの概要 このソリューションは、AWS CloudFormation テンプレートを使用して必要なリソースを作成します。 ユーザーは、踏み台ホストへの SSH トンネルを経由して Apache Airflow Web UI と Genie Web UI にアクセスします。 Apache Airflow デプロイメントは、Celery バックエンドとして Amazon ElastiCache for Redis、DAG を保存するためのマウントポイントとして Amazon EFS、およびデータベースサービスに Amazon RDS for PostgreSQL を使用します。 […]

AWSパブリックセクターより、これまで英語版でのみ閲覧頂いていましたホワイトペーパー『Ten Considerations for a Cloud Procurement』の和訳版が公開されましたのでお知らせします（下記ウェブページからダウンロードいただけます　 https://d1.awsstatic.com/whitepapers/ja_JP/10-considerations-for-a-cloud-procurement.pdf?did=wp_card&trk=wp_card）。 多くの場合、官公庁や教育機関などパブリックセクターの各機関のお客様においては、過去のソフトウェア調達、物品調達の調達仕様書・要件定義書を参考にしながら、クラウドサービス調達の検討を進めることになると考えられます。今回のホワイトペーパーでは、AWSのこれまでの多くのお客様との意見交換やベストプラクティスを踏まえ、そうした検討を進めるにあたってまず考慮いただくべきハイレベルな考え方を、以下の10の切り口から整理しています。 クラウドコンピューティングの違い；　カスタマイズ性が高い製品を購入し物理的資産として所有・管理するものでなく、標準化された市販のサービスをオンデマンドで利用するもの。 早期にクラウドのメリットを引き出せるように計画する；　すべての主要な関係者が早期より関与すべき 過度に規範的に要求しない；　データセンター等に関しカスタマイズされた調達仕様（例　ラック、サーバーのタイプ、データセンター間の距離など）を指示する必要はなく、商用クラウド業界の標準やベストプラクティスを活用。不用意な制約を避け、革新的でコスト効率の高いソリューションを活用していく クラウドインフラストラクチャ（IaaS）と、その活用のためのサービスを分けて考える；　システムの設計・開発・運用として包括的に調達するにせよ分離して調達するにせよ、クラウドインフラストラクチャはそれ自体に責任分界・SLA・利用規約が設定されている別個のサービスとみておく “従量課金”；　“毎月末に使用した分の料金を支払う”　“市場価格に基づいて変動する柔軟な料金体系” セキュリティ、プライバシー、監査について第三者認証等を活用；　FedRAMP, SOC, ISOなど セキュリティは“責任共有モデル”；　IaaSモデルでは、クラウド事業者は強固なインフラを構築し、様々なセキュリティ機能を提供。これらを活用してシステムを構成し、アプリケーションやデータをコントロールするのは利用者 データガバナンスの設計・実装；　クラウド利用者はデータの統制と所有を完全に保持（クラウド事業者はデータ管理しない）。この原則を前提に検討を進めることが必要。 “市販品”の利用規約；　クラウドコンピューティングは民間利用者も政府利用者も同じ利用規約の下で利用するもの。どの事業者の利用規約が適切か考慮した上で、これを組み込んでいくという考え方。 “クラウド評価基準”を定義する；　性能要件に照準をおき、適切なクラウド事業者を選定していくとの考え方   調達担当者にとってクラウドサービスに適合的な調達仕様書を作り込むことは、チャレンジと言えますが、今回の和訳版は、日本政府が推進する「クラウド・バイ・デフォルト原則」の下で具体的な調達プロジェクトに取り組む日本の調達担当者の皆様に、グローバルな議論の積み上げを知っていただく指針の一つとして活用いただけるものと考えています。今後、AWSとしては、このホワイトペーパーやその他資料のご説明の機会を日本のパブリックセクター領域の皆様に提供し、更に活用し易くすると同時に、具体的な調達プロジェクトへの当てはめを含め、各機関からの相談にも対応していきたいと考えています。 今回の資料をご覧いただき、「なんとなくわかる気もするけど、具体的にはどういうこと？」「日本ではどう理解したらいいの？」等々様々な疑問やご質問がありましたら、ぜひ、AWSパブリック・セクター公共調達渉外担当までお問い合わせください。 なお、英語版原文は下記より参照可能です。https://aws.amazon.com/jp/blogs/publicsector/ten-considerations-for-a-cloud-procurement/ 本ブログは、アマゾンウェブサービスジャパン株式会社 パブリックセクター 統括本部長補佐の小木郁夫・市ノ渡佳明が執筆いたしました。

NFL の試合をストリーミングで観戦することや、ミステリースリラー番組「ストレンジャー・シングス」の新シーズンを好きなだけ見たりする事から、消費者はストリーミングビデオ体験に対し、高い映像品質を期待するようになってきています。また、コンテンツ制作者や配給事業者にとって、低遅延且つ高品質のビデオを作成することが不可欠となっています。ただし、拡大するデバイスへの配信や多様なネットワーク接続環境を考慮に入れると、映像品質について高い水準を維持することは困難になっています。 日本の SoC（ System-on-Chip ）テクノロジープロバイダーである株式会社ソシオネクスト（以下、ソシオネクスト社）では、映像伝送にAWS Elemental MediaConnect、AV1エンコード処理にAmazon Elastic Compute Cloud（ EC2 ）F1 インスタンス、コンテンツ配信に Amazon CloudFront を使用しクラウドベースの AV1 リアルタイムエンコードを可能にするソリューションを構築することで、処理時間を大幅に短縮しながら一貫した高い映像品質を実現しました。 その仕組みは次のとおりです。 エンコーダを内蔵し Zixi プロトコルに対応した JVCのCONNECTED CAMカメラで撮影をします。JVC カメラは 前方誤り訂正（FEC）および自動再送要求（ARQ）パケット損失回復を使用するメカニズムであるZixiプロトコルに対応した唯一のプロフェッショナル用カメラです。JVC カメラから出力された信号は MediaConnect に送信されます。その後、信号は EC2 F1 インスタンスに入力され、リアルタイムで次世代の圧縮コーデック AV1 にエンコードされ、CloudFront を介して視聴者に送信されます。 適切に実装された場合、AV1 エンコーディングは H.264 および H.265 コーデックよりも小さいファイルサイズでより高品質の画像を生成しますが、エンコーディングのための高いコンピューター処理装置（ CPU ）要件によって、広く採用されていません。MediaConnect と EC2 F1 インスタンスがサポートするフィールドプログラマブルゲートアレイ（ FPGA ）を組み合わせることで、ソシオネクスト社のソリューションはリアルタイムの AV1 エンコードを可能にし、専用 CPU のハードウェアコストを削減します。また、不安定なネットワーク環境でも、エンドユーザーエクスペリエンスとストリームの品質を向上させながら、ストレージとコンテンツ配信ネットワーク（ CDN […]

こんにちは、AWSソリューションアーキテクトの小林です。そろそろ紅葉でも見に行ってみようかな、という時期になってきました。どこにでかけようかと色々考えているのですが、なんとなく例年よりも色づきが遅いような印象があります。最近寒くなってきたので、一気に色づいていくパターンなのかもしれません。お勧めの紅葉スポットがあれば是非教えてください。

必要なデータを検索するためにSAP GUIを果てしなくクリックすることがありませんか？そして、必要な結果を得るための単純なクエリを実行するだけのために、表をスプレッドシートに出力しなければならないときがありませんか？ 私にはあります。そのため、SAPデータに簡単にアクセスして、思い通りに利用できる場所に格納したいと思っていました。 この記事では、AWS Glueを使用してSAP HANAとの接続を構成し、 Amazon S3にデータを抽出します。このソリューションにより、SAPをさまざまな分析サービスや可視化サービスに公開し、必要な結果を得ることのできる、シームレスなメカニズムを実現します。

こんにちは。アマゾン ウェブ サービス ジャパン 株式会社 Well-Architected リードの高山です。 このたびクラウド設計・運用のベストプラクティス集である”AWS Well-Architected フレームワーク“から、特に信頼性にフォーカスした「信頼性の柱ホワイトペーパー日本語版」を公開しましたのでお知らせします。 AWS Well-Architected フレームワーク「信頼性の柱」には、インフラストラクチャまたはサービスの障害からの復旧、必要に応じた動的なコンピューティングリソースの獲得、設定ミスや一時的なネットワークの問題などによる障害の軽減などのシステムの機能が含まれます。このホワイトペーパーでは、AWS で信頼性の高いシステムを構築するための、詳細なベストプラクティスを扱っています。 ダウンロードはこちらから＞ AWS Well-Architected フレームワーク 信頼性の柱ホワイトペーパー(PDF) ■ AWS Well-Architected フレームワークとは？ AWS Well-Architected フレームワークは、AWSのソリューションアーキテクト(SA)が、AWSのサービス開始から10年以上に渡り、様々な業種業界、数多くのお客様のアーキテクチャ設計および検証をお手伝いしてきた経験から作成したクラウド活用のベストプラクティス集です。具体的には「運用の優秀性」「セキュリティ」「可用性」「パフォーマンス効率」「コスト最適化」の5つの観点について、クラウドをより活用するための設計原則と、お客様システムがベストプラクティスに沿っているかを確認するための質問と回答で構成されています。本ホワイトペーパーは、クラウドにおけるアーキテクチャ設計や運用に携わっているすべての方に読んでいただきたい内容となっています。 一方でお客様のシステムが必ずしもAWSが提唱する全てのベストプラクティスに沿っている必要はありません。ベストプラクティスをご理解いただいた上で、お客様ご自身でのビジネス的なご判断を実施いただくためのアイデアです。 ■ AWS Well-Architected フレームワーク ホワイトペーパーから先にご覧ください 9月26日にお伝えしたとおり、AWS Well-Architected Toolの日本語化および東京リージョン対応と合わせて、最新の日本語版AWS Well-Architected フレームワークホワイトペーパーも公開しております。こちらを先にお読みいただいた上で、より詳細を扱った信頼性の柱ホワイトペーパーに進んでいただくことをおすすめします。 AWS Well-Architected フレームワーク(ウェブサイト形式で閲覧) | ホワイトペーパー(PDF)    

 何十年もの間、IT 管理者は SQL Server ワークロードを Windows でしか実行できませんでした。ただし、SQL Server 2017 の時点で、SQL Server は Linux オペレーティングシステムでも実行できるようになりました。IT 管理者にとって、これは、希望するオペレーティングシステムで SQL Server ワークロードを実行できる機会であり、Windows Server のライセンスコストを削減し、オープンソース技術でアプリケーションスタックの近代化を開始できる機会でもあります。しかも、すべてシステムアーキテクチャやユーザーエクスペリエンスを大幅に変更することはありません。Linux で既存の SQL Server ワークロードを実行したいお客様を支援するために、AWS は Microsoft SQL Server データベースのための Windows から Linux へのプラットフォーム変更アシスタントの提供を開始しました。 この記事では、Microsoft SQL Server データベースのための Windows から Linux へのプラットフォーム変更アシスタントを利用して、Microsoft SQL Server データベースを Windows から Amazon EC2 Linux に移行するプロセスについて解説します。この記事では、プラットフォーム変更アシスタントを実行するための前提条件の設定を示し、2 つの使用例を提示します。最初の例では、プラットフォーム変更アシスタントを利用して、SQL Server 2017 で新しい […]

 データのソースが増えると、新しく接続されたデータを保存する必要性が高まります。企業のお客様は、オンプレミス Hadoop アプリケーションのデータレイクストレージリポジトリとして Hadoop 分散ファイルシステム (HDFS) を使用しています。お客様は、より安全で、スケーラブルで、アジャイルで、費用対効果の高いソリューションを求めて、データレイクを AWS に移行しています。 AWS への高速転送速度が妥当ではない HDFS 移行には、AWS は AWS Snowball Edge サービスを提供しています。AWS Snowball Edge を使用した HDFS 移行のベストプラクティスは、ファイル転送に中間ステージングマシンを使用することです。このブログ記事では、移行中に中間ステージングマシンを使用する方法を詳しく説明します。 AWS Snowball Edge がお客様に出荷するのは、物理的なデータ移行およびエッジコンピューティングデバイスです (図 1)。デバイスは大量のデータを Amazon Simple Storage Service (Amazon S3) に転送するために使用します。 Amazon S3 は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。バルク取り込みの場合、データレイクのエントリポイントが Amazon S3 です。99.999999999％ (9 が 11 個) の耐久性を持つオブジェクトストアである Amazon S3 は、10,000 データレイク以上をホストします。 AWS のデータレイクストレージの基盤として、Amazon S3 […]