本記事は AWS ブログ  re:Invent 2024 recap for the manufacturing industry を翻訳したものです。 AWS re:Invent 2024が閉幕しました。参加者の皆さまは、技術セッションでの学び、展示会場でのインタラクティブなデモ体験、業界関係者とのネットワーキング、そして様々なイベントを通じて充実した一週間を過ごされたことでしょう。 今回、私たちは Venetian の EXPO 会場で電動自転車を使った体験型展示を行い、参加者に模擬工場と実用的なユースケースを体感いただきました。また、製造業や産業分野の企業がデジタル変革を加速し、試験的な取り組みから脱却してクラウドで本格的なビジネス変革を実現するための新サービスや機能、ソリューションについて、数々のエキサイティングな発表を行いました。 製造業の経営者や事業部門の方々も多数ご参加いただき、re:Invent が技術者だけでなく、ビジネスの意思決定者にとっても重要なイベントであることが改めて示されました。 イベントのハイライトとして、 Matt Garman CEOによるキーノートスピーチの内容や主要な発表、顧客の声、そして会場の熱気を伝える動画などを 新しいAWSのウェブページ にまとめましたので、ぜひご覧ください。 注目のセッション キーノートをライブで視聴できなかった方は、 Matt Garman CEO によるクラウド変革に関する基調講演 をお見逃しなく。データ、インフラ、生成 AI と機械学習（ML）の分野における革新について語り、これらの進歩が AWS のお客様のゴール達成や価値あるデータの活用、より良い未来の創造にどう貢献しているかを解説しています。さらに、Amazon の CEO である Andy Jassy 氏も登場し、Amazon 社内での AWS 活用事例を紹介しました。 月曜日のナイトライブでは、 Peter DeSantis 上級副社長が AWS サービスを支える技術の詳細に迫りました。AWS コンピューティングおよびネットワーキングの VP である Dave Brown と共に、コンピューティング、セキュリティ、ストレージ、AI インフラの各分野における革新的な取り組みを紹介しました。また、Amazon Bedrock の新機能であるレイテンシー最適化推論オプションや、Project Rainier、Trainium2 UltraServers の発表など、注目の新技術も披露されました。 水曜日には、 Dr. Swami Sivasubramanian 副社長がデータと AI に関する洞察に満ちたキーノートを行い、革新的なソリューション創出のために強固なデータ基盤がいかに重要かを語りました。実際の顧客事例を交えながら、生成 AI を含む様々なユースケースでのデータ活用方法が紹介されています。 木曜日の Dr. Werner Vogels CTO による恒例のプレゼンテーションでは、複雑性の管理に焦点が当てられました。複雑さがプロジェクトに忍び込む兆候をどう見抜き、イノベーションの妨げとなる前にどう対処するか、具体的な知見が提供されています。 ブレイクアウトセッション IOT203 「AWS IoT を使用した製造業務の最適化 (Optimizing manufacturing operations with AWS IoT)」 では、Industrial IoT のプロダクトヘッドである Nicolas Pouyez 氏と、TotalEnergies のデータエンジニアリングチャプターリーダーである Rudyar Cortes 氏が、AWS IoT SiteWise を活用してインフラを近代化し、強固な産業データ基盤を構築し、業務を変革する方法について共有しました。 これらのキーノートや主要セッションの 録画 は、AWS のウェブサイトでご覧いただけます。製造業や産業分野の方々に特に関連の深いトピックも多数ありますので、ぜひチェックしてみてください。 MFG201 | Empowering the next-generation industrial operator with generative AI (生成AIによる次世代産業事業者の支援) , Georgia Pacificの取り組みを紹介 MFG202 | How Gousto reduces food waste and increases workforce productivity (Gousto が食品廃棄物を削減し、労働力の生産性を向上させる方法) , Gousto の取り組みを紹介 MFG205 | Running a complex design environment on AWS (複雑な設計環境を AWS で実行) ,   Samsung Electronics の取り組みを紹介 MFG206 | Closing the machine-to-cloud gap to jump-start digital transformation (マシンとクラウドのギャップを埋め、デジタルトランスフォーメーションを加速) , Rehrig Pacific の取り組みを紹介 MFG207 | Volkswagen’s platform strategy enables production performance & quality (フォルクスワーゲンのプラットフォーム戦略が生産性と品質向上を実現) ,  Volkswagen の取り組みを紹介 サービス、機能、ソリューションの発表 re:Invent 直前と期間中に、AWSは製造業や産業関連の企業に適用可能な多くの新サービスと機能強化を発表しました。それらの重要な理由について詳しく見ていきましょう。 パートナー活動: 注目すべき新展開として、シーメンスが AWS 上で Industrial Copilot for Engineering を提供開始しました。イノベーショントーク Architectural methods & breakthroughs for innovative apps in the cloud では、シーメンスのオートメーション部門グローバルヘッドである Jelena Mitic が、この新サービスについて発表しました。これは、ドメイン固有のプログラミング言語に精通したオートメーション技術者の不足に対応するため、Structured Control Language (SCL)や構造化テキスト (ST) を用いたプログラマブルロジックコントローラ（PLC）コードのプログラミング支援を提供します。Amazon Bedrock を活用することで、12万人以上のシーメンスTotally Integrated Automation (TIA) ユーザーが、様々なユースケースに最適な基盤モデルを選択して生成 AI アプリケーションを構築・拡張できるようになります。特に、Amazon Bedrock で利用可能な Anthropic の Claude モデルは、シーメンスの深い産業ドメイン知識を用いてファインチューニングを行い、TIAポータルなどの実際の運用環境で直接テストや検証を行うための基礎を提供します。 Compute: AWS は、複雑なエンジニアリングワークロードを大規模に実行するための、最も幅広く深いコンピューティングプラットフォームを提供し続けています。re:Invent では、 Amazon Elastic Compute Cloud (Amazon EC2) ストレージ最適化 I8g インスタンス の一般提供を発表しました。これは、ストレージ集約型ワークロードに対して Amazon EC2 で最高のパフォーマンスを提供し、前世代の I4g インスタンスと比較して最大 60% のコンピューティング性能向上を実現します。また、大規模なストレージ I/O 集約型ワークロード向けに設計された Amazon EC2 次世代の高密度ストレージ最適化インスタンス I7ie も発表しました。I7ie インスタンスは、全コアターボ周波数 3.2 GHz の第 5 世代 Intel Xeon スケーラブルプロセッサを搭載し、既存の I3en インスタンスと比較して最大 40% の演算性能向上と 20% の価格性能向上を提供します。I7ie インスタンスは、最大 100Gbps のネットワーク帯域幅と Amazon Elastic Block Store (EBS) に対して 60Gbps の帯域幅を提供します。 VMWare: VMware は産業環境でエンタープライズ IT インフラの基本的な構成要素として、さらには産業用 PC や装置製造企業の OT 側でも頻繁に使用され、組織がアプリケーションを効率的にデプロイおよび管理するための、柔軟でスケーラブルな基盤を提供しています。re:Invent では、Amazon Elastic VMware Service (Amazon EVS) のプレビューを発表しました。これは、Amazon VPC 内で VMware Cloud Foundation (VCF) を実行する新しいネイティブ AWS サービスで、デプロイメントの自動化と簡素化を行い、AWS 上ですぐに使える VCF 環境を提供します。これにより、オンプレミス環境で既に使用しているのと同じ VCF ソフトウェアとツールを使用して、VMware ベースの仮想マシンを AWS にすばやく移行できます。また、VMware ワークロードの移行と近代化のための Amazon Q Developer エージェントのプレビューも発表しました。これにより、生成 AI の力を活用して、簡単に、自動的に、かつ安全に、VMware ベースのワークロードを Amazon EC2 に移行したり近代化できるようになります。詳しくは このブログ を参照ください。 生成 AI: 以前のブログ で、生成 AI が産業企業の新しい製品の設計を作り出し、前例のないほどの製造生産性を向上させ、サプライチェーンアプリケーションの最適化するためにどう役立つかについて述べました。今回、いくつかの新しい生成 AI 関連サービスと機能を発表しましたが、最も注目すべきは Amazon Nova です。Amazon Nova 基盤モデルは、画像、文書、動画のネイティブサポートにより、最先端のビジョンやマルチモーダルの分析機能を提供し、製造の企業が顧客の検索から購入までの体験向上に役立ちます。例えば、Amazon Nova を使用して、正確な製品説明の翻訳を効率的に作成したり、新製品画像の更新やパーソナライズをしたり、魅力的な製品動画を開発したり、自然な対話型の仮想アシスタンスを提供したりすることができます。製造業の企業はまた、Amazon Nova を使用してサプライチェーンの乱れを検出し、必要な部品を確保するために迅速に在庫を再配置することもできます。Amazon Nova のマルチモーダル機能は、200 以上の言語で正確でローカライズされたコンテンツを効率的に生成し、市場投入までの時間を短縮し、検索性を向上させます。製造業の企業は、テキストや自然言語プロンプトを使用して、標準的な製品画像の修正を数週間もかけず数分で実施したり、特定の顧客層に訴求するようにカスタマイズしたりすることができます。さらに、Amazon Nova Reel を使用すると、既存の画像をもとに、文章、自然言語、あるいストーリーボードを使用して、セキュリティ、安全性、知的財産要件を満たす高品質な製品概要ビデオを開発することもできます。 Amazon Bedrock のナレッジベース は今回、カスタムコネクタとストリーミングデータの取り込みをサポートし、開発者が直接 API コールを通じてナレッジベースにデータを追加、更新、削除できるようになりました。Amazon Bedrock Knowledge Basesは 、完全に管理されたエンド・トゥ・エンドの検索補強生成（RAG）ワークフローを提供し、企業のデータソースからコンテキスト情報を組み込むことで、高精度で低レイテンシー、安全でカスタマイズ可能な生成 AI アプリケーションを作成できます。この強化により、顧客は任意のカスタムデータソースから特定の文書を取り込み、ストリーミングデータの取り込み時の中間ストレージのレイテンシーと運用コストを削減できます。時間のかかる完全な同期と保存のステップを排除し、データへのアクセスを高速化し、レイテンシーを削減し、アプリケーションのパフォーマンスを向上させます。 また、 Amazon Bedrock 用の マルチエージェントコラボレーション機能 （プレビュー）も発表しました。これにより、専門的なスキルを必要とする複雑な複数ステップのタスクに協力して取り組む複数の AI エージェントを構築、デプロイ、管理できます。さらに、 Amazon Bedrock Guardrails に新しいセーフガードとして自動推論チェック（プレビュー）を追加することを発表しました。これにより、 大規模言語モデル（LLM） が生成した回答の正確性を数学的に検証し、幻覚（ハルシネーション）による事実誤認を防ぐことができます。詳しくは、 こちらのブログ をご覧ください。 伝統的な製造業の多くは、社内システムや自社開発の MES アプリケーションにメインフレームを使用しています。Amazon Q Developer のメインフレームモダナイゼーション向け変換機能 (tranformation capabilities、プレビュー）により、顧客とパートナーはメインフレームアプリケーションの大規模な評価とモダナイゼーションを加速できます。Amazon Q Developer エージェントは、コードベースを分析して文書化し、不足しているアセットを特定し、モノリシックアプリケーションをビジネスドメインに分解し、モダナイゼーションの波を計画し、コードをリファクタリングします。エージェントは自律的にアプリケーションアセットを分類・整理し、組織の知識ベースを理解・拡大するための包括的なコードドキュメントを作成します。エージェントは生成 AI とモダナイゼーションの専門知識を使用した目標指向の推論を組み合わせて、コードベースと変換目的に合わせたモダナイゼーション計画を作成します。その後、エージェントとの対話的なやり取りを通じて、計画を協力的にレビュー、調整、承認できます。提案された計画を承認すると、Amazon Q Developer エージェントは自律的に COBOL コードをクラウド最適化された Java コードにリファクタリングし、既存のビジネスロジックを維持します。 データとストレージ: AWS Transfer Family のウェブアプリは、ウェブブラウザを通じて Amazon S3 のデータにアクセスするためのシンプルなインターフェースを作成できる新しいリソースです。これにより、従業員に対して、S3 内のデータの閲覧、アップロード、ダウンロードが可能な、完全に管理されたブランド化されたセキュアなポータルを提供できます。Transfer Family は、SFTP、FTPS、FTP、AS2 経由のファイル転送を完全に管理し、サードパーティクライアントやその設定を変更することなくワークロードの移行をシームレスに行えます。今回、組織内の技術系でないユーザーにも、ユーザーフレンドリーなインターフェースを通じてブラウザベースのファイル転送を可能にしました。Transfer Family ウェブアプリは AWS IAM Identity Center および S3 Access Grants と統合されているため、既存のディレクトリの企業アイデンティティを S3 データセットに直接マッピングするきめ細かなアクセス制御が可能になります。Transfer Familyコンソールで数回クリックするだけで、ウェブアプリの共有可能なURLを生成できます。これで、認証されたユーザーは、アクセスが許可されたデータに Web ブラウザーからアクセスできるようになります。詳細については、AWS ニュースブログを読むか、Transfer Family ユーザーガイドをご覧ください。 新しい Amazon S3 Tables は、日々の購買取引、ストリーミングセンサーデータ、広告インプレッションなどの表形式データに最適化されたストレージを提供し、Apache Iceberg 形式で保存します。これにより、 Amazon Athena 、 Amazon EMR 、 Apache Spark などの一般的なクエリエンジンを使用して簡単にクエリを実行できます。自己管理型のテーブルストレージと比較して、最大 3 倍速いクエリパフォーマンスと最大 10 倍の毎秒トランザクション数を実現し、完全マネージドサービスならではの効率的な運用も行えます。 Storage Browser for S3 の一般提供開始により、ストレージを簡単に扱うこともできるようになりました。これは、ウェブアプリケーションに追加できるオープンソースコンポーネントで、エンドユーザーに対して S3 に保存されたデータへのシンプルなインターフェースを提供します。Storage Browser for S3 を使用すると、顧客、パートナー、従業員などの権限のあるエンドユーザーに、独自のアプリケーションから S3 のデータを簡単に閲覧、ダウンロード、アップロードするためのアクセスを提供できます。S3 用ストレージブラウザは AWS Amplify React と JavaScript クライアントライブラリで利用できます。 産業機械メーカーにとって特に興味深いのが AWS Clean Rooms です。これまで、機械のエンドユーザーは生産に関する情報を保護するために、機械の使用状況のデータを機械メーカーと共有したがらないことがありました。AWS Clean Rooms は、機械メーカーと製造業の顧客・パートナーが、元となるデータを共有または開示することなく、より簡単かつ安全に複数のデータセットのマッチング、分析、コラボレーションを行えるようにします。これは、機械メーカーが装置の使用状況をより良く理解したり、メンテナンスの警告を発報したり、さらには次世代製品の開発に活用するために、エンドユーザーである製造業者の装置の利用状況データセットにアクセスする必要がある場合に非常に有用です。エンドユーザーはデータ自体を明かさずにデータセットを共有できるため、機密と見なされるデータを保護できます。両当事者は、この「秘密の」データ交換の恩恵を受けます。今年は、 AWS Clean Rooms が複数のクラウドとデータソースのデータセットとのコラボレーションをサポートすることを発表しました 。今回の発表により、企業とそのパートナーは、基礎となるデータを共同作業者間で移動または共有することなく、Snowflake と Amazon Athena に保存されているデータを簡単に操作できるようになります。 データ抽出には、多くの産業企業が AWS Glue を使用しています 。これは、複数のソースからのデータを簡単に発見、準備、移動、統合できるサーバーレスのデータ統合サービスです。AWS Glue は、業界トップクラスのスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスである Amazon Simple Storage Service (Amazon S3) からデータを取得し、Amazon Redshift で分析できるように変換します。また、AWS Glue 5.0 の一般提供についても発表しました。AWS Glue 5.0 では、パフォーマンスの向上、セキュリティの強化、Amazon Sagemaker Unified Studio と Sagemaker Lakehouse のサポートなどが提供されています。AWS Glue 5.0 では、データ統合ワークロードを開発、実行、スケーリングして、より迅速に洞察を得ることができます。 また、 Amazon SageMaker Lakehouse  の立ち上げを発表しました。これは、統一されたオープンで安全なデータレイクハウスを使用して分析と AI を簡素化します。Amazon Redshift と共同で、アプリケーションからのゼロ ETL 統合をサポートするようになり、Salesforce、SAP、ServiceNow、Zendesk を含む8つのアプリケーションからのデータの抽出と読み込みが自動化されました。Amazon SageMaker Lakehouse は、分析と AI の取り組みのためのオープンで統一された安全なレイクハウスとして、これらの統合を強化してデータ管理プロセスを合理化します。 AWS Outposts は、AWS インフラストラクチャ、AWS サービス、API、およびツールをお客様の施設に拡張する完全マネージド型サービスです。Outposts では、AWS マネージドインフラストラクチャへのローカルアクセスを提供することで、AWS リージョンと同じアプリケーションプログラミングインターフェイス (API) を使用してオンプレミスでアプリケーションを構築して実行できます。さらに、これはローカルのコンピューティングリソースとストレージリソースを使用しながら行われるため、製造時の低レイテンシー要件とローカルデータ処理のニーズを満たすことができます。AWS Outposts によるサードパーティストレージの使用を効率化するために、業界をリードするストレージソリューションとのより緊密なコラボレーションを発表しました。NetApp® オンプレミスエンタープライズストレージアレイと Pure Storage® FlashArray の外部ブロックデータボリュームを AWS マネジメントコンソールから直接アタッチして使用できるようになりました。詳細については、 このブログ をご覧ください。 産業用 IoT 関連の発表: re:Invent の直前に、 AWS IoT SiteWise の重要な機能強化を発表しました。AWS IoT SiteWise は、産業用機器からのデータを大規模に収集、保存、整理、監視することを容易にする管理サービスで、データに基づくより良い意思決定を支援します。新たに AWS パートナーである Belden と Litmus のソリューションと統合し、100 以上のプロトコルと数千のセンサーからのデータ取り込みをさらに容易にする、産業用プロトコルサポートの拡充を一般提供することを発表しました。 また、AWS IoT SiteWise の 生成 AI によるアシスタント を一般提供することも発表しました。AWS IoT SiteWise アシスタントにより、工場管理者、品質エンジニア、保守技術者などの産業ユーザーは、装置の運用データと知識ベースにある関連情報から自然言語を使用して直接洞察を得て、問題を解決し、行動を起こせるようになります。これにより、プロセスの最適化や、復旧までの時間短縮、ダウンタイムの削減のために、情報に基づく素早い意思決定が可能になります。 AWS は昨年、多数の IoT に関する機能強化を発表しました。新機能については、 このページ ですべてご確認いただけます。 まとめ 私にとっては今回で6回目の re:Invent となりましたが、今年のイベントでも再び、AWS のイノベーションがデジタル変革を加速し、製造業ビジネスを最適化するのに役立つことが示されました。イベントは引き続き開発者中心ではありますが、今年は開発者中心の会議から製造バリューチェーン全体に向けたイベントへの移行も見られました。今年参加できなかった方は、来年のイベント（2025年12月1日〜6日、ラスベガスで開催予定）にぜひご参加ください！ Scot Wlodarczak Scot は2018年7月に AWS に入社し、産業領域のマーケターとして活躍しています。それ以前は、シスコやロックウェル・オートメーションで勤務し、産業マーケティングマネージャーや地域マーケティングリーダーとしての役割を担ってきました。現在、Scot は産業顧客向けのマーケティングを担当し、デジタル変革の道筋を示すとともに、IT と現場運用の間のギャップを埋める役割を果たしています。幅広い産業分野における自動化の経験を有しています。学歴としては、ニューヨーク州立大学バッファロー校で機械工学の学位を取得し、その後コロラド大学で MBA を取得しています。現在はコロラド州を拠点に活動しています。 翻訳はソリューションアーキテクトの山本が担当しました。

本記事では、2024 年 10月 25 日に金融機関向けにサービスやプラットフォームを提供されている金融プラットフォーム事業に関わるエンジニアの方々を対象に、企業の枠を超えたAWSスキルの研鑽と交流をテーマとして開催した 「 AWS GameDay DOJO YABURI for 金融プラットフォーマー 」の開催概要、および熱い戦いの模様と結果をご報告いたします。 AWS GameDay とは？ AWS GameDay は、ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップです。3～4 名でチームを結成し、待ち受けるさまざまなトラブル（クエスト）の技術課題の解決に取り組みます。各クエストをクリアするごとにポイントが付与され、最も多くのポイントを獲得したチームが勝者となります。AWS GameDay は従来のワークショップとは異なり、参加者は決まりきった手順の無い自由な形式で、固定概念にとらわれずに探索し、楽しみながらAWS を学ぶことができます。詳細は こちら を参照ください。 イベント開催概要 今回の AWS GameDay は AWS Japan 金融事業統括本部が主催し、日本の金融サービスを支える金融プラットフォーマー企業 総勢 10チーム 40名にご参加頂きました。このイベントは DOJO YABURI と題した他流試合として企画され、AWS を活用した実務経験者（95%が中級者以上）や様々な AWS 資格保有者、Japan AWS Top Engineer や Japan AWS Jr. Champions といった AWS Award 受賞経験者など、豊富な経験と高い AWS スキルを持ったエンジニアの皆さんにお集まりいただき、ハイレベルなコンペティションとなりました。オープニングの各チームリーダーからの決意表明では、「絶対、負けません！必ず優勝してトロフィーを持ち帰ります！」などの熱い意気込みが語られ、各チームとも日頃鍛えたAWSスキルとチームワークを活かして一致団結し、白熱した戦いを繰り広げられていました。 図1: 参加企業一覧 今回のゲームシナリオは、「 Microservice Magic 」を採用し、マイクロサービスを運用する中での様々なトラブル (クエスト) をクリアしながら、パフォーマンスの良いサービスを安定運用させるというミッションの達成を目指します。各クエストを迅速にクリアすることでより多くのポイントが得られる一方、発生した問題を放置してしまうと見るみるポイントが減ってしまいます。また、各チームは他チームの品質の良いマイクロサービスをバックエンドに利用して、自らのサービスの品質を高めることもできます。品質の良い魅力的なマイクロサービスを提供することでより多くのユーザーを獲得することも、得点を獲得するための重要な戦略の一つとなります。 AWS GameDay オープニング ワークショップは、架空のテクノロジースタートアップであるユニコーンレンタル社のユニコーンによるモビリティレンタルサービスが、人々の注目と支持を得てビジネスとして大成功したという紹介から始まりました。ところが、これまでシステム運用を担っていたメンバーが一斉退職してしまいます。参加者の皆様は、ユニコーンレンタル社の優秀な新入社員として入社したという設定で、限られたドキュメントを元に開発済みのマイクロサービスをデプロイするとともに、 さまざまな障害に対応しながらサービスのパフォーマンスを改善し安定稼働させる というミッションに取り組んでいただくことが説明されました。 参加者の皆様は、わずかな文書しか引き継がれていないアプリケーションの稼働という困難な状況設定に戸惑いながらも、説明に真剣に耳を傾けていました。 AWS GameDay スタート！ ゲームに取り組む時間は4時間。その間に、サービスが壊れたり、パフォーマンスが悪化したり、さまざまなカオスが発生します。チームのポイントが減少し始めると、各種サービスの設定状況を確認したり、 AWS CloudTrail や Amazon CloudWatch Logs でエラーを確認したりと、日頃鍛えたスキルとチームワークを活かして障害の根本原因を探る様子がみられました。 図2: 各チームがGameDayに取り組む様子 発生する障害 (クエスト) だけでなく、各チームのポイントも刻々と変化します。最初のクエストに時間がかかったチームが後から追い上げたり、パフォーマンスの良いサービスを他チームに利用してもらうことで高得点をあげたり、最後まで接戦が繰り広げられました。参加者の皆様には、熱い眼差しと高い集中力で最後まであきらめることなく戦い抜いていただきました。 AWS GameDay 結果発表 本イベントの結果、上位3チームは以下の通りとなりました。上位入賞者の皆様、本当におめでとうございます！ 第 1 位 株式会社 Finatext / スコア : 563,104 points （田島 悟史 氏、松﨑 稔矢 氏、呉 智瀚 氏、和田 哲郎 氏) 図3: 株式会社 Finatext のみなさま 第 2 位 株式会社NTT データ / スコア : 477,144 points （松岡 雄地 氏、高田 大輔 氏、南條 綾乃 氏、須藤 敬仁 氏) 図4: 株式会社NTT データのみなさま 第 3 位 株式会社キャピタル・アセット・プランニング / スコア : 431,310 points （佐々木 勝則 氏、秋山 純希 氏、趙 文来 氏、林 健太郎 氏) 図5: 株式会社キャピタル・アセット・プランニングのみなさま 白熱した戦いを終えて 今回の GameDay は次々と不可解な障害が発生するクエストだったため、問題を特定しクリアするスピードだけでなく、継続して安定稼働を続けられるかが高得点の鍵となりました。本番環境でこのような状況が起きると大変ですが、ゲーミフィケーションされた安全な環境で「 事前に知らされていないイベント（障害発生等）に対して、冷静に筋道立てて事象の確認、原因分析・調査を行うための基本動作が身についているかどうかを確認できる」 点が良かったという感想をいただきました。また、 「入賞したことで、自信につながった！」「チームメイトの新しい一面を知ることができた」「相次ぐトラブルを解決しながら他企業と競い合うという、普段の業務では味わえない刺激があり、とても楽しかった」「優勝を逃した悔しさをばねに、更にAWSスキルを磨きたい！」 など、他社対抗戦でのGameDayが刺激になり、各社更なるAWSスキルの向上に向けたコメントも多くあり、このような交流ができることも GameDay の醍醐味だと思います。 イベント後のネットワーキングでは、各企業のAWSエンジニア同士が交流し、お互いの健闘を笑顔で讃えあわれました。 改めて、AWS GameDay DOJO YABURI for 金融プラットフォーマーにご参加いただいた皆様、ありがとうございました。 図6: イベント終了後の集合写真 最後に 金融プラットフォーマーの皆様のAWSスキルの向上や交流によって、金融業界におけるデジタル変革の加速や新たな体験価値創造につながっていくと我々は信じています。今回、入賞したチーム、惜しくも入賞を逃したチームの皆様、もしくは次回参加してみたい！と思ったエンジニアの皆様、今後も GameDay の開催を予定していますので、機会を見かけましたら奮って挑戦ください。また、次回のGameDay でお会いできることを楽しみにしています！

データ準備はあらゆる機械学習 (ML) ワークフローにおいて重要なステップですが、多くの場合、面倒で時間のかかるタスクを伴います。 Amazon SageMaker Canvas は、 Amazon SageMaker Data Wrangler を利用した包括的なデータ準備機能をサポートするようになりました。この統合により、SageMaker Canvas はエンドツーエンドのコード不要のワークスペースをお客様に提供し、データを準備し、ML や基礎モデルを構築して使用することで、データからビジネスインサイトを得るまでの時間を短縮できます。SageMaker Canvas のビジュアルインターフェイスでは、50 を超えるデータソースからデータを簡単に見つけて集約し、300 種類を超える組み込みの分析と変換を使用してデータを探索して準備できるようになりました。また、変換と分析のパフォーマンスが向上し、自然言語インターフェイスを使用して ML 向けにデータを検索および変換することもできます。 この投稿では、SageMaker Canvasでのエンドツーエンドのモデル構築のためのデータを準備するプロセスを順を追って説明します。 ソリューション概要 今回は、金融サービス会社のデータ専門家のユースケースを想定しています。借手がローンを完済するかどうかを予測する機械学習モデルを構築するために、2つのサンプルデータセットを使用します。これは信用リスク管理に不可欠です。SageMaker Canvasのノーコード環境により、コーディングなしに、データの準備、特徴量エンジニアリング、機械学習モデルのトレーニング、デプロイまでのエンドツーエンドのワークフローを迅速に実行することができます。 前提条件 この記事の手順を実施するには、以下に記載されている前提条件を満たしていることを確認してください。 Amazon SageMaker Canvas を起動 します。すでに SageMaker Canvas ユーザーである場合は、この新機能を使用できるように、一度 ログアウト して再度ログインしてください。 Snowflake からデータをインポートするには、［ Snowflake用のOAuthをセットアップする ］の手順に従ってください。 インタラクティブデータの準備 セットアップが完了したら、インタラクティブなデータ準備を可能にするデータフローを作成できます。データフローには、データをまとめるための変換処理とリアルタイムの視覚化が組み込まれています。以下のステップを実行してください。 以下のいずれかの方法を使用して新しいデータフローを作成します。 [ Data Wrangler ]、[ Data flows ] を選択し、[ Create ] を選択します。 SageMaker Canvas データセットを選択し、[ Create a data flow ]を選択します。 [ Import data ] を選択し、ドロップダウンリストから [ Tabular ] を選択します。 Amazon Simple Storage Service (Amazon S3)、 Amazon Athena 、 Amazon Redshift 、Snowflake、Salesforce などの 50 を超えるデータコネクタを介してデータを直接インポートできます。この記事では、Snowflake から直接データをインポートする方法について説明します。 または、ローカルマシンから同じデータセットをアップロードすることもできます。データセット [ loans-part-1.csv ] と [ loans-part-2.csv ] をリンクからダウンロードして使用できます。 [Import data] ページのリストから [Snowflake] を選択し、[Add connection] を選択します。 接続の名前を入力し、認証方法のドロップダウンリストから [ OAuth ] オプションを選択します。okta アカウント ID を入力し、[ Add connection ] を選択します。 Okta ログイン画面にリダイレクトされるので、Okta 認証情報を入力します。認証が成功すると、データフローページにリダイレクトされます。 Snowflakeデータベースからローンデータセットを参照して検索します。 2 つのローンデータセットを画面の左側から右側にドラッグアンドドロップして選択します。2 つのデータセットが結合され、赤いビックリマークの付いた結合記号が表示されます。これをクリックし、両方のデータセットの ID キーを選択します。結合タイプは Inner のままにしておきます。結果以下のスクリーンショットのようになるはずです。 [ Save & close ] を選択します。 [ Create dataset ] を選択します。データセットに名前を付けます。 データフローページに移動すると、次のように表示されます。 ローンデータをすばやく分析するには、[ Get data insights ]を選択し、ターゲット列に loan_status 、問題タイプに[ Classification ]を選択します。 生成された データ品質とインサイトのレポート は、主要な統計、視覚化、および機能の重要性分析を提供します。 データ品質の問題と不均衡なクラスに関する警告を確認して、データセットを理解し、改善してください。 このユースケースのデータセットでは、「クイックモデルスコアが非常に低い」という警告が優先度が高く、マイノリティクラス（課金対象および現行）に対するモデルの有効性が非常に低いことが予想されます。これは、データをクリーンアップしてバランスを取る必要があることを示しています。データインサイトレポートの詳細については、 Canvas のドキュメント を参照してください。 SageMaker Data Wrangler によって強化された 300 種類以上の組み込み変換処理を備えた SageMaker Canvas を使用すると、ローンデータをすばやく整理できます。[ Add step ]をクリックして、適切なトランスフォーメーションを参照または検索できます。このデータセットでは、[ Drop missing ] と [ Handle outliers ] を使用してデータを消去し、次に [ One-hot encode ] と [ Vectorize text ] を適用して ML 用の機能を作成します。 Chat for Data Prep は、リクエストをわかりやすい英語で説明することで直感的なデータ分析を可能にする新しい自然言語機能です。たとえば、自然なフレーズを使用して、ローンデータの統計や特徴相関分析を行うことができます。SageMaker Canvas は会話形式のインタラクションを通じてアクションを理解して実行し、データ準備を次のレベルに引き上げます。 チャットを使用してデータ準備を行い、組み込みの変換処理を使用してローンデータのバランスを取ることができます。 まず、以下の指示を入力します。replace “charged off” and “current” in loan_status with “default” Chat for Data Prep は、2 つの少数派クラスを 1 つのデフォルトクラスにマージするコードを生成します。 組み込みの SMOTE 変換関数を選択して、デフォルトクラスの合成データを生成します。 これで、バランスの取れたターゲット列ができました。 （訳者追記：上記の SageMaker Canvas UI では、 Amazon SageMaker Canvas に統合された Amazon SageMaker Data Wrangler を利用してデータの変換処理を行います。またチャットの質問は日本語にも対応しております。以下に日本語で同様の内容をチャットに指定する場合のスクリーンショットを添付します。） （訳者追記：ここまで） ローンデータをクリーニングして処理したら、 データ品質およびインサイトのレポート を再生成して改善点を確認します。 優先度の高い警告が消え、データ品質が向上したことを示しています。必要に応じてさらに変換を追加して、モデルトレーニングのデータ品質を高めることができます。 データ処理のスケーリングと自動化 データ準備を自動化するには、ワークフロー全体を分散型Sparkジョブとして実行またはスケジュールして、データセット全体または新しいデータセットを大規模に処理できます。 データフロー内に Amazon S3 送信先ノードを追加します。 [ Create job ] を選択して SageMaker Processing ジョブを起動します。 Processing ジョブを設定し、[ Create ] を選択します。これにより、フローをサンプリングせずに数百 GB のデータでジョブが実行できるようになります。 データフローをエンドツーエンドの MLOps パイプラインに組み込んで、ML ライフサイクルを自動化できます。データフローは、SageMaker パイプラインのデータ処理ステップ、または SageMaker inference パイプラインをデプロイ処理として、SageMaker Studio ノートブックに設定できます。これにより、データ準備から SageMaker のトレーニング、ホスティングまでのフローを自動化できます。 SageMaker Canvasでモデルを構築しデプロイする データを準備したら、最終的なデータセットを SageMaker Canvas にシームレスに取り込み、ローン支払い予測モデルの構築、トレーニング、デプロイを行うことができます。 データフローの最後のノードまたはノードペインで [ Create model ] を選択します。 これにより、データセットがエクスポートされ、ガイド付きモデル作成ワークフローが開始されます。 エクスポートされたデータセットに名前を付け、[ Export ] を選択します。 通知バーから [ Create model ] を選択します。 モデルに名前を付け、[ Predictive analysis ] を選択し、[ Create ] を選択します。 これにより、モデル構築ページにリダイレクトされます。 SageMaker Canvas のモデル構築作業を続行するには、ターゲット列とモデルタイプを選択し、次に [Quick build] または [Standard build] を選択します。 モデル構築方法の詳細については、 モデルの構築 を参照してください。 トレーニングが完了したら、モデルを使用して新しいデータを予測したり、展開したりできます。SageMaker Canvas からモデルをデプロイする方法の詳細については、「 Amazon SageMaker Canvas で構築された ML モデルを Amazon SageMaker リアルタイムエンドポイントにデプロイする 」を参照してください。 まとめ この投稿では、SageMaker Data Wrangler を活用して、ローン支払いを予測するためのデータを準備する金融データプロフェッショナルの役割を引き受け、SageMaker Canvas のエンドツーエンド機能を紹介しました。インタラクティブなデータ準備により、ローンデータを迅速にクリーニング、変換、分析して、有益な機能を設計することができました。SageMaker Canvas を使うことで、コーディングの複雑さが解消され、質の高いトレーニングデータセットを迅速に作成できるようになりました。この加速されたワークフローは、ビジネスに影響を与える高性能な ML モデルの構築、トレーニング、展開に直接つながります。SageMaker Canvas の包括的なデータ準備と、データからインサイトまでの統一されたエクスペリエンスにより、ML の成果を向上させることができます。データからビジネスインサイトを得るまでの時間を短縮する方法の詳細については、「 SageMaker Canvas Immersion Day 」と「 AWS ユーザーガイド 」を参照してください。 翻訳は Solution Architect の Masanari Ikuta が担当しました。原文は こちら です。 著者について Dr. Changsha Ma は AWS の AI/ML スペシャリストです。彼女はコンピューターサイエンスの博士号、教育心理学の修士号を持つ技術者であり、データサイエンスと AI/ML の独立系コンサルティングで長年の経験を積んでいます。彼女は機械と人間の知能のための方法論的アプローチの研究に情熱を注いでいます。仕事以外では、ハイキング、料理、食べ物狩り、友人や家族と過ごす時間が大好きです。     Ajjay Govindaram は AWS のシニアソリューションアーキテクトです。複雑なビジネス上の問題を解決するために AI/ML を利用している戦略的顧客と仕事をしています。彼の経験は、中規模から大規模のAI/MLアプリケーション導入の技術的な方向性や設計支援を提供した経験があります。彼の知識は、アプリケーションアーキテクチャからビッグデータ、分析、機械学習まで多岐にわたります。彼は休憩しながら音楽を聴いたり、アウトドアを体験したり、愛する人と時間を過ごしたりすることを楽しんでいます。     Huong Nguyen は AWS のシニアプロダクトマネージャーです。SageMaker Canvas と SageMaker データラングラーの機械学習データ準備を率いており、15 年にわたり顧客中心のデータ主導型の製品を構築してきた経験があります。

Amazon SageMaker Canvas では、機械学習 (ML) モデルのリアルタイム推論エンドポイントへのデプロイがサポートされるようになりました。これにより、ML モデルを本番環境に移行し、ML を活用したインサイトに基づいてアクションを起こすことができます。SageMaker Canvas は、アナリストやシチズンデータサイエンティスト（注：ガートナー社が命名した用語で、本業以外の業務でデータ分析を行う人材を指す）がビジネスニーズに合わせて正確な ML 予測を生成できるようにするコード不要のワークスペースです。 これまで、SageMaker Canvas はインタラクティブなワークスペース内で ML モデルを評価し、一括予測を生成し、What-if 分析を実行する機能を備えていました。しかし今では、モデルを Amazon SageMaker エンドポイントにデプロイしてリアルタイムで推論することもできるようになったため、SageMaker Canvas ワークスペースの外でモデル予測を利用したり、アクションを実行したりするのが簡単になりました。SageMaker Canvas から ML モデルを直接デプロイできるので、ML モデルを手動でエクスポート、設定、テスト、本番環境にデプロイする必要がなくなり、複雑さの軽減と時間の節約につながります。また、コードを記述しなくても、個人が ML モデルを運用しやすくなります。 この投稿では、 SageMaker Canvas のモデルをリアルタイムエンドポイントにデプロイするプロセス を順を追って説明します。 ソリューション概要 今回のユースケースでは、携帯電話事業者のマーケティング部門のビジネスユーザーを想定しています。SageMaker Canvasで機械学習モデルを作成して、解約のリスクがある顧客を特定することに成功しました。モデルによって生成された予測のおかげで、今度はこれを開発環境から本番環境に移行したいと考えています。モデルエンドポイントを推論用にデプロイするプロセスを効率化するために、SageMaker Canvas から ML モデルを直接デプロイしています。これにより、ML モデルを手動でエクスポート、構成、テスト、本番環境にデプロイする必要がなくなりました。これにより、複雑さが軽減され、時間が節約されるだけでなく、コードを記述しなくても ML モデルを個人が操作しやすくなります。 ワークフローのステップは次のとおりです。 現在の顧客を含む新しいデータセットを SageMaker Canvas にアップロードします。サポートされているデータソースの完全なリストについては、 Canvas へのデータのインポート を参照してください。 ML モデルを構築し、そのパフォーマンス指標を分析します。手順については、 カスタムモデルの構築 と Amazon SageMaker Canvas でのモデルのパフォーマンスの評価 を参照してください。 承認されたモデルバージョンをリアルタイム推論のエンドポイントとしてデプロイします。 前提条件 このチュートリアルでは、次の前提条件が満たされていることを確認してください。 モデルバージョンを SageMaker エンドポイントにデプロイするには、SageMaker Canvas 管理者が SageMaker Canvas ユーザーに必要な権限を付与する必要があります。この権限は SageMaker Canvas アプリケーションをホストする SageMaker ドメインで管理できます。詳細については、 Canvas での権限の管理 を参照してください。 Amazon SageMaker Canvas を使用したノーコード機械学習による顧客離れの予測 に記載されている前提条件を実装します。 これで、Canvasに過去の顧客離れ予測データに基づいてトレーニングされた3つのモデルバージョンができたはずです。 V1 は 21 個の機能すべてでトレーニングを行い、モデルのスコアは 96.903% のクイックビルド構成でした。 V2 は 19 個の機能すべて (電話と州の機能を削除) とクイックビルド構成でトレーニングし、97.403% の精度向上を実現しました。 V3 は標準ビルド構成でトレーニングされ、モデルスコアは 97.103% でした。 顧客離れ予測モデルを使用する SageMaker にエンドポイントとしてデプロイする場合に最もパフォーマンスの高いモデルを選択できるように、モデルの詳細ページで高度なメトリクスを表示を有効にし、各モデルバージョンに関連するメトリクスを確認します。 パフォーマンスメトリックに基づいて、デプロイするバージョン 2 を選択します。 モデルデプロイ設定 (デプロイ名、インスタンスタイプ、インスタンス数) を設定します。 初期値として、Canvasはモデルのデプロイに最適なインスタンスタイプとインスタンス数の推奨値を自動的に設定します。ワークロードのニーズに合わせて変更できます。 デプロイされた SageMaker 推論エンドポイントは、SageMaker Canvas 内から直接テストできます。 SageMaker Canvas ユーザーインターフェイスを使用して入力値を変更すると、What-if分析の形式でさまざまなケースをテスト推論できます。 それでは、 Amazon SageMaker Studio に移動して、デプロイされたエンドポイントを確認してみましょう。 SageMaker Studio でノートブックを開き、次のコードを実行してデプロイされたモデルエンドポイントを推測します。モデルエンドポイント名を独自のモデルエンドポイント名に置き換えてください。 import boto3, sysimport pandas as pd endpoint_name = "canvas-customer-churn-prediction-model" sm_rt = boto3.Session().client('runtime.sagemaker'); payload = [['PA',163,806,403-2562, 'no', 'yes', 300, 8.16, 3, 7.57,3.93,4,6.5,4.07,100,5.11,4.92,6,5.67,3] body = pd.DataFrame(payload).to_csv(header=False, index=False).encode("utf-8") response = sm_rt.invoke_endpoint(EndpointName=endpoint_name, Body=body, ContentType="text/csv",Accept="application/json") response = response['Body'].read().decode("utf-8") print(response) Canvas からデプロイしたモデルエンドポイントは ml.m5.xlarge インスタンスを 1つ使用しています。ここで、モデルエンドポイントで推論を実施するエンドユーザーの数が増えると予想され、より多くの計算能力をプロビジョニングしたいと仮定しましょう。これは SageMaker Canvas 内から[ Update configuration ]を選択することで直接実行できます。 Clean up 今後課金されないようにするには、この記事の手順を進めて作成したリソースを削除してください。これには、SageMaker Canvas からのログアウトとデプロイされた SageMaker エンドポイントの削除 が含まれます。SageMaker Canvas はセッションの期間中はユーザーに請求されるため、SageMaker Canvas を使用していないときは SageMaker Canvas からログアウトすることをお勧めします。詳細については、 Amazon SageMaker Canvas からのログアウト を参照してください。 まとめ この投稿では、SageMaker CanvasからMLモデルをリアルタイム推論エンドポイントにデプロイする方法について説明しました。これにより、MLモデルを本番環境に移行し、MLを活用した洞察に基づいて行動を起こすことができます。この例では、アナリストがコードを記述せずに非常に正確な予測 ML モデルを迅速に構築し、それをエンドポイントとして SageMaker にデプロイし、SageMaker Canvas と SageMaker Studio ノートブックからモデルエンドポイントをテストする方法を示しました。 ローコード/ノーコードの ML ジャーニーを始めるには、 Amazon SageMaker Canvas を参照してください。 立ち上げに貢献してくれたすべての人、プラシャント・クルマッダリ、アビシェック・クマール、アレン・リウ、ショーン・レスター、リチャ・サンドラーニ、アリシア・チーに感謝します。 翻訳は Solution Architect の Masanari Ikuta が担当しました。原文は こちら です。 著者について Janisha Anand は、SageMaker Canvas と SageMaker Autopilot を含む Amazon SageMaker Low/No Code ML チームのシニアプロダクトマネージャーです。彼女はコーヒーを楽しみ、アクティブな状態を保ち、家族と過ごす時間を楽しんでいます。   Indy Sawhney は、アマゾンウェブサービスのシニアカスタマーソリューションリーダーです。Indy は、常に顧客の問題から後戻りして、AWS 企業の顧客幹部に独自のクラウド変革の道筋について助言しています。25 年以上にわたり、企業が新しいテクノロジーやビジネスソリューションを採用できるよう支援してきました。Indy は AWS の AI/ML テクニカルフィールドコミュニティの専門分野のスペシャリストであり、ジェネレーティブ AI とローコード/ノーコード Amazon SageMaker ソリューションを専門としています。

このブログは Fast and accurate zero-shot forecasting with Chronos-Bolt and AutoGluon を翻訳したものです。 Chronos-Bolt は AutoGluon-TimeSeries の最新追加機能であり、元の Chronos [1]モデルと比較して最大 250 倍高速に追加学習なしで高精度な予測を実現します。 時系列予測は、小売、エネルギー、金融、ヘルスケアなどの産業全体で重要なビジネス決定を導く上で極めて重要な役割を果たしています。従来、予測は ETS や ARIMA などの統計モデル [2] に依存してきました。これらのモデルは、特にトレーニングデータが限られている場合に、今でも強力なベースラインとなっています。過去10年間で、深層学習の進歩により、 DeepAR [3] や PatchTST [4] などのいわゆるグローバルモデルへのシフトが促進されました。これらのアプローチは、データセット内の複数の時系列データで横断的に単一の深層学習モデルをトレーニングします。例えば、幅広い e コマースカタログの売上や、何千もの顧客の観測可能な指標などが対象です。 Chronos [1] のような基盤モデルは、さまざまなドメインの時系列データを利用して単一のモデルを学習させるというアイデアをさらに大きく前進させました。これらのモデルは、膨大な時系列データで事前学習されています。学習データには実際のデータと合成データが含まれ、様々な分野、頻度、時系列の長さをカバーしています。その結果、追加学習なしの予測が可能となり、未知の時系列データセットに対しても正確な予測を提供します。時系列予測に取り組むハードルが低くなり、追加の学習なしで正確な予測が可能になるため、予測プロセス全体が大幅に簡素化されます。Chronos の各種モデルは、 Hugging Face から 1 億 2000 万回以上ダウンロードされており、 Amazon SageMaker AI の AutoGluon-TimeSeries から利用できます。また、 Chronos-T5 は Amazon SageMaker JumpStart を通じて利用できます。 Chronos-Bolt の紹介 Chronos-Bolt は T5 エンコーダー-デコーダーアーキテクチャ [5] に基づいており、約 1000 億個のデータポイントで学習されています。このモデルは、過去の時系列データを複数のデータポイントからなるパッチに分割し、それをエンコーダーに入力します。デコーダーはこれらの特徴表現を使用して、複数の将来時点の予測値を一度に生成します。この手法は「直接マルチステップ予測」として知られています。これは、自己回帰的なデコーディングを行う(将来の予測を１ステップずつ順次生成する)元の Chronos モデルとは異なるアプローチです。時系列データの分割と直接マルチステップ予測により、Chronos-Bolt は元のChronos モデルと比較して最大 250 倍高速で、20 倍のメモリ効率を実現しています。 以下のグラフは、512 個のデータポイントを入力として使用し、64 ステップ先までを予測する 1024 の時系列に対する、Chronos-Bolt と元の Chronos モデルの推論時間を比較しています。 Chronos-Bolt は、元の Chronos と比較して大幅に高速であるだけでなく、より高精度です。以下のグラフは、27 のデータセットにわたって集計された Chronos-Bolt の確率的予測および点予測の性能を、 加重分位数損失 (Weighted Quantile Loss: WQL、予測の確率分布における分位点の精度) と 平均絶対スケール誤差 (Mean Absolute Scaled Error: MASE、予測値の精度を測る指標) の観点から示しています。 (データセットの詳細については [1] を参照） 。注目すべきは、これらのデータセットを学習に使用していないにもかかわらず、追加学習をしていない Chronos-Bolt が、これらのデータセットで学習された一般的な統計モデルや深層学習モデル (*で強調表示) を上回る性能を示していることです。さらに、他の基盤モデルよりも優れた性能を発揮しています。これらの + で示されている基盤モデルは、我々のベンチマークで使用される一部のデータセットで事前学習されているため、厳密には追加学習なしのモデルとは異なります。特筆すべきは、Chronos-Bolt（Base） が予測精度の面で元の Chronos(Large) モデルを上回りながら、600 倍以上高速であることです。 Chronos-Bolt は現在、 Hugging Face で4つのサイズ — Tiny(9M)、Mini(21M)、Small(48M)、Base(205M)—で利用可能であり、CPU でも使用できます。 ソリューションの概要 この記事では、AutoGluon-TimeSeries の使い慣れたインターフェースを使用して Chronos-Bolt を利用する方法を紹介します。AutoGluon-TimeSeries を使用することで、SageMaker のユーザーは時系列予測のためのモデルを構築およびデプロイできます。これには、Chronos-Bolt などの 基盤モデルや他のグローバルモデルが含まれ、さらに統計モデルと容易にアンサンブルして精度を最大化することができます。 Chronos-Bolt で追加学習なしの予測実行 本ブログでは Amazon SageMaker Studio Notebook 上で Chronos-Bolt を使って追加学習なしでの予測を実行する方法をご紹介します。 始めるには、Amazon SageMaker Studio Notebook またはターミナルで以下のコマンドを実行して、AutoGluon v1.2 をインストールする必要があります : pip install autogluon.timeseries~=1.2.0 AutoGluon-TimeSeries は、時系列データセットを扱うために TimeSeriesDataFrame を使用します。 TimeSeriesDataFrame は、縦型データ形式のデータフレームを想定しており、少なくとも以下の 3 つの列が必要です：データセット内の個々の時系列の ID を示す ID 列、タイムスタンプ列、そして生の時系列値を含むターゲット列です。タイムスタンプは均等な間隔で配置されている必要があり、欠損値は NaN で表されます。Chronos-Bolt はこれらを適切に処理します。以下のコードスニペットは、オーストラリアの 5 つの州の 30 分間隔の電力需要データを含むオーストラリア電力データセット [6] を TimeSeriesDataFrame にロードします : from autogluon.timeseries import TimeSeriesDataFrame, TimeSeriesPredictor train_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/australian_electricity_subset/train.csv" , id_column= "item_id" , timestamp_column= "timestamp" , ) 次のステップは、このデータを  TimeSeriesPredictor  でフィッティングします : predictor = TimeSeriesPredictor(prediction_length= 48 ).fit(train_data, presets=" bolt_base ") ここでは、 TimeSeriesPredictor が次の 48 ステップ（この場合は 1 日分）の予測を生成するよう指定しています。AutoGluon-TimeSeries は、予測モデルの構築時に使用できるさまざまなプリセットを提供しています。この例で使用されている bolt_base プリセットは、追加学習なしの予測のために Chronos-BoltのBase（205M）モデルバリアントを採用しています。追加学習なしの予測ではモデルの学習が不要なため、 fit() の呼び出しはほぼ瞬時に完了します。これで予測モデルは追加学習なしの予測を生成する準備が整い、 predict メソッドを使用して実行できます。 predictions = predictor.predict(train_data) AutoGluon-TimeSeriesは、ターゲット値に対して点予測と確率的予測（分位数予測）の両方を生成します。確率的予測は予測値の不確実性の範囲を示しており、多くの計画立案において重要な役割を果たします。 予測結果を視覚化し、予測期間にわたって実際のターゲット値と比較することもできます : test_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/australian_electricity_subset/test.csv" , id_column= "item_id" , timestamp_column= "timestamp" , ) predictor.plot(test_data,predictions,max_history_length= 200 ,item_ids=[ "T000002" ]) Chronos-Bolt は追加学習なしで高精度の予測を生成します。以下のグラフは、点予測と 80% 信頼区間を示しています。 AutoGluon の Chronos-Bolt でファインチューニング これまで、追加学習をさせずに zero-shot で予測を実行する推論専用のモードで Chronos-Bolt を使用してきました。しかし、AutoGluon-TimeSeries を使用すると、特定のデータセットに対して Chronos-Bolt をファインチューニングすることもできます。ファインチューニングには g5.2xlarge などの GPU インスタンスの使用をお勧めします。以下のコードスニペットでは、Chronos-Bolt(Small、48M) モデルに対して 2 つの設定を指定しています : 追加学習なしの zero-shot とファインチューニングです。AutoGluon-TimeSeries は、提供されたトレーニングデータを使用して、事前学習済みモデルの軽量なファインチューニングを実行します。モデルの追加学習なしバージョンとファインチューニング済みバージョンを識別するために、名前に接尾辞を追加します。 predictor = TimeSeriesPredictor(prediction_length=48, eval_metric="MASE").fit( train_data, hyperparameters={ "Chronos": [ {"model_path": "bolt_small", "ag_args": {"name_suffix": "ZeroShot"}}, {"model_path": "bolt_small", "fine_tune": True, "ag_args": {"name_suffix": "FineTuned"}}, ] }, enable_ensemble=False, time_limit=600, ) 予測モデルは、 time_limit で指定された最大 10 分間フィッティングされます。フィッティングが完了した後、テストデータに対して 2 つのモデルバリアントを評価し、リーダーボードを生成します : predictor.leaderboard(test_data) ファインチューニングの結果、テストデータにおける MASE の値が示すように、予測精度が大幅に向上しました。AutoGluon-TimeSeries のすべてのモデルは、評価指標の値が大きいほど性能が良いという形式で結果を表示します。つまり、MASE のような多くの予測誤差指標は、表示時に -1 を乗じて変換されます。 外部情報を用いた Chronos-Bolt の拡張 Chronos-Bolt は単変量モデルであり、予測を行う際に対象となる時系列の過去データのみを使用します。しかし、実際のシナリオでは、対象となる時系列に関連する追加の外部情報（休日やプロモーションなど）が利用可能なことがよくあります。予測時にこれらの情報を使用することで、予測精度を向上させることができます。AutoGluon-TimeSeries には共変量回帰（外部特徴量を用いた回帰）モデルが実装されており、これを Chronos-Bolt のような単変量モデルと組み合わせることで予測に外部情報を活用できます。AutoGluon-TimeSeries の共変量回帰モデルは、各時点のターゲット列を予測するために、利用可能な外部特徴量とその他の固定的な特徴量を使用する表形式データの回帰モデルです。この回帰モデルによる予測値はターゲット列から差し引かれ、その残差を単変量モデルが予測します。 Chronos-Bolt と共変量回帰モデルの組み合わせ方を示すために、食料品の販売データセットを使用します。このデータセットには、 scaled_price 、 promotion_email 、 promotion_homepage という 3 つの外部特徴量が含まれており、 unit_sales の予測を行います： train_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/grocery_sales/train.csv", id_column="item_id", timestamp_column="timestamp", ) 以下のコードは、今後 7 週間 unit_sales を予測するために TimeSeriesPredictor を設定します。 TimeSeriesPredictor の構築時に、予測対象とするターゲット列と利用可能な外部特徴量の名前を指定しています。Chronos-Bolt に対して 2 つの設定を定義しています : 1 つ目は外部特徴量を考慮せず、 unit_sales の過去の時系列データのみを使用する追加学習なしの設定、2 つ目は外部特徴量を活用する設定で、CatBoost モデルを covariate_regressor として使用します。また、 target_scaler も使用しており、これにより時系列データは学習前に比較可能なスケールに調整され、通常より高い精度が得られます。 predictor = TimeSeriesPredictor( prediction_length=7, eval_metric="MASE", target="unit_sales", known_covariates_names=["scaled_price", "promotion_email", "promotion_homepage"], ).fit( train_data, hyperparameters={ "Chronos": [ {"model_path": "bolt_small", "ag_args": {"name_suffix": "ZeroShot"}}, { "model_path": "bolt_small", "covariate_regressor": "CAT", "target_scaler": "standard", "ag_args": {"name_suffix": "WithRegressor"}, }, ], }, time_limit=600, enable_ensemble=False, ) 予測モデルの学習後、テストデータセットで評価を行い、リーダーボードを生成することができます。共変量回帰モデルと Chronos-Bolt を組み合わせることで、外部特徴量を使用しない場合と比べて予測性能が大幅に向上します。 test_data = TimeSeriesDataFrame.from_path( "https://autogluon.s3.amazonaws.com/datasets/timeseries/grocery_sales/test.csv", id_column="item_id", timestamp_column="timestamp", ) predictor.leaderboard(test_data) ただし、外部特徴量が常に有効とは限りません。データセットによっては、追加学習なしのモデルの方が高い精度を示す場合もあります。そのため、複数のモデルを試し、検証用データで最も予測精度が高いモデルを選択することが重要です。 結論 Chronos-Bolt を使用することで、実務者は追加学習なしで高品質な予測を素早く生成できます。AutoGluon-TimeSeries は、Chronos-Bolt の簡単なファインチューニング、共変量回帰モデルとの統合、そして様々な予測モデルとのアンサンブルを可能にすることで、この機能をさらに強化します。上級ユーザー向けには、この記事で紹介した以上に予測モデルをカスタマイズできる包括的な機能セットを提供しています。AutoGluon の予測モデルは、 AutoGluon-Cloud と公式の Deep Learning Containers を使用して SageMaker に簡単にデプロイできます。 AutoGluon-TimeSeries を使用した正確で堅牢な予測モデルの構築について詳しく学ぶには、 チュートリアル をご覧ください。 X(旧 Twitter ) で AutoGluon をフォローし、 GitHub でスターを付けることで、最新情報を入手できます！ 参考文献 [1] Ansari, Abdul Fatir, Lorenzo Stella, Ali Caner Turkmen, Xiyuan Zhang, Pedro Mercado, Huibin Shen, Oleksandr Shchur, et al. “Chronos: Learning the language of time series.” Transactions on Machine Learning Research (2024). [2] Hyndman, R. J., and G. Athanasopoulos. “Forecasting: principles and practice 3rd Ed.” O Texts (2018). [3] Salinas, David, Valentin Flunkert, Jan Gasthaus, and Tim Januschowski. “DeepAR: Probabilistic forecasting with autoregressive recurrent networks.” International Journal of Forecasting 36, no. 3 (2020): 1181-1191. [4] Nie, Yuqi, Nam H. Nguyen, Phanwadee Sinthong, and Jayant Kalagnanam. “A time series is worth 64 words: long-term forecasting with transformers.” In The Eleventh International Conference on Learning Representations (2023). [5] Raffel, Colin, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J. Liu. “Exploring the limits of transfer learning with a unified text-to-text transformer.” Journal of Machine Learning Research 21, no. 140 (2020): 1-67. [6] Godahewa, Rakshitha, Christoph Bergmeir, Geoffrey I. Webb, Rob J. Hyndman, and Pablo Montero-Manso. “Monash time series forecasting archive.” In NeurIPS Track on Datasets and Benchmarks (2021). 著者について Abdul Fatir Ansariは、Amazon Web Servicesのシニアアプライドサイエンティストとして、機械学習と予測分析に特化し、時系列などの構造化データのための基盤モデルを専門としています。シンガポール国立大学で博士号を取得し、画像と時系列データのための深層生成モデルを研究しました。     Caner Turkmenは、Amazon Web Servicesのシニアアプライドサイエンティストとして、機械学習と予測分析が交差する研究課題に取り組んでいます。AWSに参画する前は、金融サービスと通信部門を担当するデータサイエンティストとして経営コンサルティング業界で働いていました。イスタンブールのボアジチ大学でコンピュータ工学の博士号を取得しています。   Oleksandr Shchurは、Amazon Web Servicesのシニアアプライドサイエンティストとして、AutoGluonにおける時系列予測に取り組んでいます。AWSに参画する前は、ドイツのミュンヘン工科大学で機械学習の博士号を取得し、イベントデータの確率モデルに関する研究を行いました。時系列データの機械学習と生成モデリングを研究分野としています。   Lorenzo Stellaは、Amazon Web Servicesのシニアアプライドサイエンティストとして、分析と意思決定のための機械学習、予測分析、生成AIに取り組んでいます。イタリアのIMTLuccaとベルギーのKUルーヴェン大学でコンピュータサイエンスと電気工学の博士号を取得し、機械学習と最適制御応用のための数値最適化アルゴリズムを研究しました。

当初、お客様に必要な Amazon Virtual Private Cloud (Amazon VPC) は1つだけだと考えていましたが、多くのことを学んでおり、今日、 AWS Well-Architected Framework では、 単一の VPC を持つ 単一のアカウント をアンチパターンとして記述しています。AWS クラウド内のアカウントとネットワークパスの数が増加するにつれ、お客様やパートナーの皆様から、大規模なクラウド環境を理解し、セキュリティを確保するために役立つシンプルなツールが欲しいという要望がありました。 AWSは、お客様が発見的統制や予防的コントロール、プロアクティブコントロール、およびレスポンシブコントロールの実装を可能にするサービスや機能を提供しています。例えば、 自動推論と証明可能セキュリティ への投資により、パブリックに公開された Amazon Simple Storage Service (Amazon S3) バケットを検出し、単純なミスや誤解から生じた 予期せぬインターネットアクセス を特定することが可能となりました。大規模な予防的コントロールのために、 Amazon S3 ブロックパブリックアクセス のような機能を提供し、S3 オブジェクトがプライベートであることを簡単に保証できるようにしています。 Amazon VPC に対する Block Public Access の実装 2024年11月19日に、インターネットアクセス制御を簡素化する強力な新機能を発表できることを嬉しく思います。 Amazon VPC Block Public Access は、AWS が提供するインターネット経路を通じて入ってくる (インバウンド) および出ていく (アウトバウンド) VPC トラフィックを確実にブロックするシンプルで宣言的な制御機能です。Amazon VPC Block Public Access により、 VPC 内のリソースに対する AWS 提供のインターネットアクセスを一元的にブロックすることで、お客様は組織のセキュリティとコンプライアンス要件への準拠を確保できます。双方向ブロックに設定すると、全てのインバウンドおよびアウトバウンド VPC トラフィックが拒否されます。Amazon VPC Block Public Access は、Internet Gateway (IGW) や Egress-Only Internet Gateway (EIGW) などの経路を通してインターネットに公開される全てのトラフィックを遮断するように、既存の VPC 設定よりも優先されます。 しかし、VPC からのトラフィックがインターネットにアクセスする必要がある場合はどうでしょうか? NAT Gateway と EIGW は一般的に、VPC 内のリソースにインバウンドのインターネットトラフィックにさらすことなく、インターネットアクセスを提供するために使用されています。お客様から、Amazon VPC Block Public Access を使用する際に、このような一般的なアーキテクチャをサポートするシンプルで信頼性の高く一貫したアプローチが求められていました。双方向ブロックの代替として、Amazon VPC Block Public Access はこれらのユースケースに対してイングレス方向のみのブロックをサポートしています。イングレス方向のみのブロックでは、インターネットからのインバウンドトラフィックが確実にブロックされ、VPC からのアウトバウンドトラフィックは NAT Gateway と EIGW を通してのみ許可されます。 Amazon VPC Block Public Access は、AWS アカウント内、リージョン単位で有効にでき、近日中に AWS Organizations のサポートも予定されています。 除外によるきめ細やかな制御 VPC 内の一部リソースでは、双方向のインターネットアクセスが必要になる場合があることを理解しています。あるいは、Amazon VPC Block Public Access の双方向ブロックまたはイングレス方向のみのブロックでは拒否されるような、エグレス方向のみのインターネットパスが必要になるといった集中型のトラフィック検査のようなユースケースがあります。この要件に対応するために、Amazon VPC Block Public Access には細かな除外機能が含まれています。管理者は、Amazon VPC Block Public Access の適用から除外する VPC またはサブネットを個別に指定でき、必要に応じてターゲットを絞ったインターネットアクセスを許可できます。 これらの除外を設定することで、全て (双方向) またはアウトバウンド (エグレス方向のみ) のインターネットアクセスを許可できます。イングレス方向のみのブロックと同様に、エグレス方向のみの除外を許可すると、VPC またはサブネットからのエグレストラフィックは NAT Gateway と EIGW を通してのみ許可されます。 Amazon VPC Block Public Access の動作方法と主要機能について、より深く掘り下げていきます。 Amazon VPC Block Public Access を理解する Amazon VPC Block Public Access を実演するために、シンプルなデュアルスタック (IPv4とIPv6) の VPC アーキテクチャを作成しました。2つのパブリックサブネット、2つのプライベートサブネット、2つの NAT Gateway、EIGW、IGW があります。パブリックサブネットには、IGW へのデフォルトルートがあります。プライベートサブネットには、同じアベイラビリティーゾーン内の NAT Gateway への IPv4 デフォルトルートと、EIGW への IPv6 デフォルトルートがあります。パブリックサブネットには、HTTP を受け付けるインターネット向け Application Load Balancer (ALB) をデプロイしました。ALB はインターネットからのインバウンドトラフィックをプライベートサブネット内の Web サーバーに渡します。 図1. シンプルかつデュアルスタック VPC アーキテクチャ Amazon VPC Block Public Access を有効にする前は、ALB を通してインターネットから Web サーバーにアクセスできます。また、Web サーバーにログインしている間、IPv4 用の NAT Gateway とIPv6 用の EIGW を通してインターネットにアクセスでき、AWS ホームページに ping を実行することもできます。 図2. ブラウザウィンドウに “Hello, World!” と表示されている 図3. IPv4およびIPv6 を介して成功したアウトバウンド ping Amazon VPC Block Public Access を設定して、パブリックサブネットのみとの双方向の全トラフィックを許可したいと思います。しかし、Amazon VPC Block Public Access の有効化後に、Web サイトが利用できなくなることは避けたいです。そのため、Amazon VPC Block Public Access を有効化する前に、これらのサブネットに対する除外設定を行います。 VPC コンソールに移動し、次のことを行います。 設定 を選択します。 次に、 パブリックアクセスをブロック タブを選択します。 図4. パブリックアクセスをブロックのタブ 次に、以下を行います。 除外を作成 をクリックし、2つのパブリックサブネットが全てのインターネットトラフィック (双方向通信) を許可するように指定してください。 次に、 除外を作成 をクリックします。 図5. パブリックサブネットに対して除外を作成 数分後、除外が Active になります。 図6. パブリックサブネットに対しての Active な除外 さて、Amazon VPC Block Public Access を有効化する準備ができました。この機能を有効にした際に何が起こるのかを確実に理解しておきたいと思います。 Network Access Scope を作成 をクリックし、 Network Access Analyzer を使用して、現在許可されている AWS 提供のインターネットパスを特定します。2 つの除外条件を使用して、パブリックサブネットをインターネットトラフィックの送信元または宛先としてフィルタリングします。これらのサブネットへのトラフィックは、除外によって許可されていることがわかります。 図7. Network Access Analyzer の結果 分析によると、Web サーバーでは ALB を介したインターネットトラフィックの受け入れや応答が許可されており、また、NAT Gateway を介してアウトバウンド (エグレス) のインターネットトラフィックを開始することができます。プライベートサブネットには EIGW への IPv6 デフォルトルートもあることや、プライベートサブネットに対して Amazon VPC Block Public Access の除外を行っていないことを思い出してください。その結果、Amazon VPC Block Public Access がWeb サーバーからのエグレス IPv6 トラフィックを拒否すると予想されます。 パブリックアクセスをブロックのタブに戻り、以下を行います。 パブリックアクセス設定を編集 をクリックします。 [パブリックアクセスをブロックする]をオンにする のボックスをチェックし、すべてのインターネットトラフィック (双方向) をブロックする動作を設定します。 変更を保存 をクリックします。 図8. 双方向ブロックによる Block Public Access を有効化にする 数分後、パブリックアクセス設定の ステータス が オン と表示されます。 図9. Block Public Access がオン 確認のため、インターネットから ALB を通して Web サーバーにアクセスできるかどうかを確認します。“Hello, World!” ページが正常に表示されました。Web サーバーに戻ると、Network Access Analyzer の結果で確認したように、NAT Gateway と IGW を介して IPv4 で AWS ホームページに ping を送ることができます。予想通り、IPv6 では AWS ホームページに ping を送ることはできません。 図10. IPv4でのアウトバウンドの ping は成功し、IPv6 でのアウトバウンドの ping は失敗 プライベートサブネットで有効化されていた VPCフローログ を見ると、IPv6 トラフィックが拒否されているのが分かります。最初の行 (ACCEPT) は、パケットがネットワークインターフェースのセキュリティグループとサブネットのネットワーク ACL によって許可されたことを示しています。しかし、Amazon VPC Block Public Access がトラフィックをブロックしています (REJECT)。VPC フローログでカスタムフォーマットを設定していれば、 reject-reason フィールドを含めることができ、トラフィックをブロックした理由が BPA であることが表示されたはずです。 図11. ACCEPT の後に REJECT が続く VPC フローログ プライベートサブネットからの EIGW を介した IPv6 アウトバウンドトラフィックを有効にするために、新しい除外を追加します。この除外は、EIGW を通過するトラフィックが流れる方向に一致する、エグレス方向のみです。 図12. プライベートサブネットに対する除外を作成します 数分後、除外が Active になります。Web サーバーに戻ると、EIGW を介して IPv6 経由で AWS ホームページに再び ping を送ることができます。 図13. 成功した IPv6 経由のアウトバウンドの ping 最後の操作として、すべての除外を削除します。除外がない状態では、この VPC のすべてのインターネットトラフィックがブロックされます。 図14. 除外を削除 予想通り、ALB にはアクセスできなくなり、Web サーバーからのアウトバウンドトラフィックも開始できなくなりました。 図15. ブラウザウィンドウに “接続がタイムアウトしました” と表示されている パブリックアクセスをブロックのタブに戻り、 パブリックアクセス設定を編集 をクリックします。 [パブリックアクセスをブロックする]をオンにする のブロックのチェックを外し、 変更を保存 をクリックします。数分後、パブリックアクセス設定の ステータス が オフ と表示されます。再び ALB にアクセスできるようになり、IPv4 と IPv6 を使用して AWS ホームページに ping を送ることができるようになります。 知っておくべきポイント Amazon VPC Block Public Access は、イングレス方向のみのブロック、またはエグレス方向のみの除外を許可する場合、ステートフルです。許可された接続の戻りのトラフィックは自動的に許可されます。この動作はセキュリティグループと類似しています。 有効にすると、Amazon VPC Block Public Access は新規および既存のネットワーク接続に影響します。 Amazon VPC Block Public Accessには、デフォルトで50個の除外までといったクォータがあります。クォータの引き上げは可能です。 イングレス方向のみのブロックが有効になっているか、エグレス方向のみの除外が許可されている場合、NAT Gateway と EIGW のみが VPC から出ることを許可します。 Amazon VPC Block Public Access は、Elastic Load Balancing や AWS Global Accelerator などの他のサービスと統合されています。 AWS Client VPN とAWS Site-to-Site VPN は安全な通信とみなされてるため、Amazon VPC Block Public Access から除外されています。 結論 本稿では、お客様が VPC のインターネットアクセスを管理するための宣言的なコントロールを求めていたことについて議論しました。Amazon VPC Block Public Access を使用することで、お客様はどの VPC やサブネットが Amazon が提供するインターネットにアクセスできるかを管理することができます。これにより、VPC 内のリソースへの AWS 提供のインターネットアクセスを一元的にブロックすることで、組織のセキュリティとコンプライアンス要件への準拠を確保できます。Network Access Analyzer と VPC フローログを活用してトラフィックパターンを理解し、Amazon VPC Block Public Access を有効にすることで、今すぐ始めることができます。詳細については、 Amazon VPC Block Public Access のドキュメントをご覧ください。 本稿は、2024年11月19日に Networking & Content Delivery で公開された “ Enhancing VPC Security with Amazon VPC Block Public Access ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

この記事は、” Ten steps to modernizing legacy monoliths in the AWS Cloud ”を翻訳したものです。 モダナイゼーションの課題 レガシーなモノリシックアプリケーションをモダナイズするプロセスは複雑であり、しばしば成功するまでに数年かかり、その過程で組織はさまざまな障害に直面します。主な課題の 1 つは、変更の影響を受けるビジネスプロセスが移行中および移行後もシームレスにに運用され続けることを確認することです。組織は、大がかりなビッグバン形式のリリースを行うか、小さなサイクルでリリースを行い中断を最小限に抑えるかを決める必要があります。後者の場合、モノリシックなアプリケーションをどのように小さな部分に分割するかを明らかにすることが大きな課題となります。 モダナイゼーションを開始する前に見過ごされがちですが、重要なステップは、目的を明確に特定し、動機を理解し、成功の指標を設定することです。モダナイゼーションが必要な理由として、しばしば古いハードウェアやソフトウェアの保守の困難さ、サポートコストの増加、サポート契約期限切れに伴う既存のシステムの廃止の必要性が挙げられます。しかし、古い技術だけではシステムの更新の理由にはなりません。成功したモダナイゼーション戦略は、コストの削減、効率の向上、既存の投資の最大活用といったビジネス目標を優先させます。最終的には、レガシーシステムをアジャイル、スケーラブル、柔軟な環境に変革し、実質的なビジネス上のメリットをもたらすことを目指しています。 マイグレーションパス クラウドへのアプリケーションの移行には、7 つの戦略である「7 R」があります。 リタイア 、 リテイン 、 リホスト 、 リロケート 、 リパーチェス 、 リプラットフォーム 、 リファクタリング/リアーキテクト です。リファクタリングは、クラウド移行時にアプリケーションをモダナイズし、アーキテクチャをクラウドベースの機能を利用するように変換することで、アジリティ、パフォーマンス、スケーラビリティを強化します。迅速な開発、スケーラビリティ、コスト削減の要求に応えるために選択されます。典型的なシナリオには、レガシーシステムの制限の克服、モノリシックなアプリケーションの高速デリバリーの課題への対処、保守が困難なレガシーソフトウェアの管理、テスト容易性とセキュリティの向上が含まれます。 この記事では、 Volkswagen AG と AWS での経験に基づいて、レガシーモノリシックなアプリケーションのリファクタリング手順を 10 ステップで説明しています (図 1)。ビジネスプロセスやビジネス機能に基づいてモノリシックなアプリケーションを 分割 し、その後 ストラングラー・フィグ・パターン を適用することを推奨しています。このパターンでは、新しいサービスでレガシーシステムの機能を徐々に置き換えていきます。目標は、レガシーシステムとモダナイズされたシステムを共存させながら、スムーズな移行を実現することです。完全な置き換えが完了するまでその状態が続きます。 図 1 – リファクタリングのための10ステップのプロセスフロー ステップ 1 – 目標と成功のためのKPIの概要を示す 組織全体の戦略的目標に沿うように、モダナイズの取り組みの企業目標と技術目標を理解し概要を示します。そして、コスト削減、柔軟性向上、オペレーション効率の向上、サイクル時間の短縮、生産性の向上などの具体的なビジネス目標に基づく第一動機を理解しながら、主要な原動力を特定します。 成功の KPI モダナイゼーションの成功を測るために、顧客ニーズとの整合性を確保し、オペレーショナル・エクセレンスを推進するため、ビジネス面と技術面の両方で主要業績評価指標 (KPI) を設定します。ゴール、質問、指標 (GQM) フレームワークを使用して、目的と関連する指標を特定します。指標は主に 2 つのグループに分類できます。 1. プロダクトメトリクス は、新機能がビジネス運営に与える影響など、お客様への価値提供に焦点を当てています。 2. 運用メトリクス は、リードタイム、サイクルタイム、デプロイ頻度、サービス復旧時間、変更失敗率など、ソフトウェア開発プロセスの改善に焦点を当てています。 ステップ 2 – ビジネスプロセスとケーパビリティをマッピング バリューストリーム (リーン原則) および企業資産管理 (EAM) プロセスを把握することで、識別されたビジネスプロセスの効率化と確立された目標が合致することを保証できます。ビジネスプロセス分析 (BPA) では、内部のワークフローを検証して最適なプロセスを導きます。プロセスフロー図を作成すれば、複雑なプロセスを単純化し、相互作用を明確にし、ユーザ関連のワークフローの分析と改善を支援できます。これらの図は、ステークホルダー向けの明確な概要を提供し、事業を自動化して効率と生産性を高める改善案を着想するきっかけにもなります。 モダナイゼーションは、従来のシステムから移行するだけでなく、新しい環境でそれらを再構築することを目指しています。現在と将来の業務機能を特定し、 scaled agile framework (SAFe) の戦略的テーマを統合します。「現状」の徹底的な分析をターゲットのビジョンと合わせて行うと、新しい機能を導入するためのギャップが明らかになります。プロセスや機能が実際の価値の流れとは無関係な歴史的、政治的、または技術的な理由で存在することがよくあります。このステップでは、柔軟性に欠けるレガシーシステムによって発生した手動プロセスとシステムのギャップに対処します。例えば、定期的なスプレッドシート計算は新しいシステムに統合し、別々の管理と電話やメールでの対応を、イベントトリガーによる通知で自動化できます。 ステップ 3 – ビジネスケーパビリティと将来のサービスをマッピングする このステップでは、以前に特定されたビジネスケーパビリティを、ビジネス要件と技術的ソリューションを関連付けた詳細なケーパビリティ – サービスマップを作成することで、将来のサービスにマッピングします。アプリケーションは、特定のユースケース向けにカスタマイズされたモノリシックなものから始まることが多いですが、内部構造が貧弱、保守コストが高い、新しい開発者のオンボーディングでサポートコストが増大するなどの理由から、モダンな環境での制限に直面することが多くあります。高い結合度と低い凝集度により、新機能の追加が大幅に遅れる可能性があります。原因は、メジャーアップデートのためのチーム間の広範な調整が必要となるためです。 これらの課題に対処するために、マイクロサービスのアーキテクチャが採用され、継続的インテグレーションおよびデプロイ (CI/CD) の実践を通じて開発の高速化とスケーリングの容易化が図られます。この段階では、新しいマイクロサービスとターゲットの API が特定され、定義されます。新しいマイクロサービスは明確な境界線と特定の機能を持つように設計され、独立して開発、デプロイ、スケーリングができるようになります。 ステップ 4 – モノリシックアプリケーションの分割とプロダクトチームの編成 レガシーのモノリシックアプリケーションを分割するには、特定されたサービスを論理的に分類して一貫したユニットを構築し、それらの運用範囲を設定する必要があります。これらのユニットは、独立したアプリケーションとして、または広範なプロダクトの一部として、あるいは複数のアプリケーションにまたがって動作する可能性があります。分割は次の手順で行えます。(1) ドメイン駆動設計の中心的なパターンであるバウンデッドコンテキストによりプロダクトを特定し分離する。(2) 依存関係とデータフローを特定する。(3) ストラングラーパターンを使って移行パスと優先順位を決める。 このステップの目的は、サービスを各システムに合わせて効率化および統合を最適化し、組織の戦略的方向性と変化への対応力を支える明確なドメインモデルを作成することです。さらに、このステップではドメイン駆動設計の原理に従って、新規または既存の境界づけられたコンテキストを中心としたプロダクトチームを編成します。ビジネス ユーザーの配置を考慮し、プロセス オーナーを特定し、自律したプロダクトチームを設立します。これらのチームを特定のドメインまたはコンテキストに合わせることで、集中した開発、スムーズなデリバリ、より良いプロダクト管理が可能になります。 ステップ 5 – データフローを特定し、統合層を確立する データフロー図を使用して、上流と下流の内部および外部データフローをマッピングし、真のデータ所有者を特定します。なぜなら、時間の経過とともにレガシーシステムが下流システムの主要なデータソースになる傾向があるためです。これにより、データをオリジナルソースから新しいアプリケーションに直接ルーティングできるようになり、レガシーシステムへの依存度が低減します。あらゆるデータ責任を新しく作成したアプリケーションに移譲し、これらがデプロイされ稼働した後の下流データフローに対処してください。データフローをレガシーシステムから外れた経路に振り分けることで、完全に移行するまでレガシーシステムと新しいアプリケーション間で必要なデータ同期を最小限に抑えることができます。さらに、モダナイズ後にレポートおよび分析機能がどのように適応するかを評価し、分散型レポートか集中型レポートを選択し、新しいデータソースを決定する必要があります。 効果的な統合層を構築するには、現在の通信プロトコルを評価し、アプリケーション間のデータフローを促進するための今後の変更点を特定する必要があります。統合層では、次の 3 つの主要なデータフローに対処する必要があります。(1) 従来のアプリと新しいアプリとの間のデータ同期(2) 新しく作成されたアプリに割り当てられたアップストリームとダウンストリームのデータ責任(3) 新しいシステム内部のデータフロー ステップ 6 – 共有およびプラットフォーム全体のサービスを特定して構造化する 機能を特定してサービスに対応付けると、一部のサービスが共通で共有できることがわかります。これらのサービスを共有サービスまたは基盤プラットフォームサービスとして分類します。共有サービスは、認証やアクセス制御のための認証・承認サービス、アラートや更新の通知システム、ロギングなど、複数のアプリケーションにまたがる横断的な関心事に対応します。プラットフォーム サービスは、全体のプラットフォームをまたいでイベント駆動型のアーキテクチャを構築できるようにする統合サービスなどの基本的なコンポーネントです。共有サービスまたはプラットフォームサービスとしてこの戦略的な分類を行うことで、冗長な機能を排除し、効率的で一貫したアプリケーション環境を促進できます。これらのサービスは、標準化と再利用を通じて、さまざまなアプリケーションをサポートするスケーラブルで一貫したフレームワークを提供します。 ステップ 7 – 非機能要件を文書化する レイテンシ、スループット、データ残存などの重要な非機能的側面を詳述します。これらの要素を理解することは、デプロイ戦略を決定し、モダナイズされたアプリケーションがパフォーマンス基準を満たし、規制やコンプライアンス基準を順守し、組織の運用目標と合致することを確実にする上で不可欠です。このステップでは、リソースの最適化、セキュリティ対策の強化、スケーラビリティと信頼性の確保を行います。これらの要件を明確に定義することで、チームは明確な期待値を設定し、効果的な計画とテストを可能にし、シームレスなユーザーエクスペリエンスと堅牢な運用継続性を実現するソリューションを提供できます。 ステップ 8 – 技術選定と達成したい状態を定義する データベース、バックエンドサービス、フロントエンドコンポーネントなど、アプリケーションに適した技術スタックを決定します。バックエンドサービスにはコンテナ化を取り入れ、ポータビリティとスケーラビリティを高めます。これは組織のプラットフォームの選択と、チームの専門性に沿ったものです。技術選定には、モジュール性と業界標準の遵守など、原則に沿った決定を行います。アプリケーションおよびデータ アーキテクチャ、ターゲットのデータモデル、統合ポイント、データフロー、API エンドポイントの定義、サービスの相互作用について詳細なターゲット状態の設計を作成してください。目標は、システムの理想的な最終状態を捉えた首尾一貫したブループリントを作成し、ベストプラクティスに沿うこと、長期的なビジョンをサポートし、変化するビジネスニーズに迅速に適応しながら、将来の開発を最適化することです。 ステップ 9 – MVP の開発 最小機能製品 (MVP) の最初のアプリケーションのデプロイを計画します。複雑さが低く、依存関係が少なく、初期の分離において高いビジネス価値があるものに焦点を当てます。これにより、ビジネス価値の迅速なデモンストレーションが可能になり、必要な実装プロセスが設定されます。ユーザーの参加スピードや地理的な影響など、即時的な恩恵を最大化する要因に基づいて MVP を優先順位付けします。リスクの低い管理可能なプロジェクトから始めることで、初期の成功が容易になり、信頼が構築され、スケーラブルなモダナイゼーションの基盤が確立されます。 この方法に従えば、プロダクトチームは予め定められた成功基準に沿って MVP アプリケーションを立ち上げます。成功した場合は、チームメンバーが新しいグループを形成して他のアプリケーションを開発し、分割してシーディングする戦略を用いて段階的にモダナイズを拡大します。 ステップ 10 – ロールアウト戦略とデータ移行計画を作成する 順調な移行と、アプリケーションの成功裏な立ち上げのためには、ロールアウト、データ移行、切り替えの綿密な計画が不可欠です。特定のユーザーグループにカナリアリリースを利用するなどし、ビジネスチームとダウンタイムの調整を行うことで、リスクを最小限に抑えます。ミッションクリティカルなアプリケーションでは、一時的にキューを活用し、新システムが運用可能になるまで受信リクエストを管理し、リダイレクトします。新しい MVP をそれまでのシステムと併用し、新システムが完全に引き継ぐまでデータの整合性とトランザクションのセキュリティを確保します。両システム間でデータの一貫性を保ち、アクションがトランザクションとして安全であることを確認します。移行専用のコードを後から削除できるよう設計します。 移行前に、データ量とデータ移行のパフォーマンスを考慮したデータ移行およびデータ同期の計画を立ててください。AWS は、 AWS Data Migration Service (AWS DMS) がオンプレミスから AWS へのデータベース移行、 AWS DataSync がオンプレミスと AWS ストレージサービス間のデータ移行の自動化と高速化、 AWS Transfer Family が企業間の継続的なファイル転送の AWS ストレージサービスへの安全なスケーリングを実現する包括的なデータ転送サービスを提供しています。これらのサービスは、オンプレミスシステムとクラウドストレージの統合を合理化し、オンラインおよびオフラインのデータ移行を容易にします。 レガシーシステムから堅牢な DevOps アプローチに徐々に移行し、リリース後に問題が発生した場合の ロールバックに備えることで、運用上の要件を満たします。変更管理プロセスを改善して、より俊敏な 開発とリリースを実現し、市場投入時間を短縮します。 レガシーシステムと新しい MVP を並行して実行しながら、モダナイズしたアプリケーションが目的を果たした時点で、レガシー機能の廃止を計画、スケジュールします。 Volkswagen AG におけるレガシーモダナイゼーションの事例 この Volkswagen AG (VW) における IT 変革の例では、レガシーモノリスアプリケーションをアップグレードし、新機能とクロスプロセス機能を追加しながら、モダンな AWS クラウドインフラストラクチャへの移行中のビジネスリスクを削減するために、チームが特定のパターンとステップを利用した様子が示されています (図 2)。 図 2 – Volkswagen 移行プロセス 例 ビジネスプロセスの概要を説明した後、レガシーシステムはプロセス単位で分割され、新しいシステムの機能について最終決定を行う専任のビジネスオーナーが配置されました。レガシーシステムの知識の低下と古い文書化のため、新製品の機能を定義するために、ビジネスオーナーと複数のステークホルダー面談を行う必要がありました。 VW チームは、目標、ビジネス影響、依存関係、相乗効果、実装するモジュールの全体的な複雑さに基づいて MVP の優先順位を決定しました。モダナイズが必要な従属システムについて、ロールアウト計画が検討され、ブランドごとに実施されました。一部のブランドがレガシーシステムを引き続き使用していたため、モダナイズされたシステムからレガシーシステムへのデータ同期が必要でした。共通の統合レイヤーを確立することが重要なステップで、これによりソース、モダナイズ、ダウンストリームのシステム間の新しいデータ交換と、レガシーシステムへのデータ同期が可能になりました。 教訓 複雑なモノリシックシステムをモダナイズするプロジェクトでは、同様の課題が何度も発生しています。 これらのシステムは多くの場合、共通のデータベースを持っていました。通常、システムのすべてのモジュールで共有される、中央のリレーショナルデータベースが備わっていました。 データフローは年々要件に基づいて成長し、システム全体の見直しは稀にしか行われませんでした。 新しい要件では、システムに新しい機能が追加され、旧式の機能を削除することなく、複雑さがさらに増し続けました。 個々のモジュールは密接に結合されており、当初の役割分担の明確な分離とモジュール間の境界が多くの場所でぼやけてしまいました。 これらの点の総体は以下のようになります。 システムを拡張するには多大な費用がかかりました。 実装された機能に関する知識が失われていきました。 新しいユースケースは遅れがちだったり、多大な費用がかかりました。 多くの場合、システムの刷新は、一から作り直したり、一度に全面的に入れ替えたりすることはできませんでした。課題は、置き換え対象のシステムが新システムと長期間並行して稼働する必要があったことです。つまり、両方のシステムでデータを常に同期させ、トランザクションを安全に実行する必要がありました。 こうした場合に更新を成功させるには、次のことが重要でした。 組織とステークホルダーのビジョンを理解する。 業務プロセス、価値の流れ、該当ドメイン内の情報の流れを把握する。 ビジネスおよび技術的な目標をサポートするために、対象システムに必要な機能を導き出す。 移行戦略を立案する。 まとめ レガシーモノリスアプリケーションのモダナイズは、慎重な計画、実行、モニタリングを要する戦略的な旅路です。このブログの 10 の手順に従うことで、組織はレガシーのモダナイズの複雑さに対処し、進化する要求に応えることができます。主要な要素には、ビジネス目標との整合性、クラウド機能の利用、シームレスなデータ移行、主要な指標に対する継続的なパフォーマンス測定が含まれます。成功した変革の報酬は非常に大きく、成長と革新の新しい機会と並んで、ビジネス上の利点がもたらされます。レガシーアプリケーションのモダナイズに関するガイダンスを受け、AWS がどのようにモダナイズの旅路を支援できるかを知るには、 AWS の自動車向業界向けページ を訪問するか、 AWS チーム までお問い合わせください。 翻訳はソリューションアーキテクトの小森谷が担当しました。原文は こちら

この記事は How to build serverless entity resolution workflows on AWS (記事公開日: 2024 年 1 月 8 日) を翻訳したものです。 消費者は、チャネルに関係なく、企業が高度に関連性のあるパーソナライズされた方法で自分たちとやり取りすることを期待しています。 Twilio が行った調査では、消費者の 60% がパーソナライズされた体験の後にリピート購入すると述べています。 McKinsey & Company の調査によると、70% 以上の消費者がパーソナライズされたジャーニーを期待しており、パーソナライゼーションを実施している組織は 10 〜 15% の収益増加を実現しています。 今日、マーケターや広告主は、ウェブ、モバイル、コンタクトセンター、ソーシャルメディアチャネルにわたってパーソナライズされたマーケティングや広告キャンペーンを展開するために、消費者データの統合ビューを必要としています。例えば、消費者がブランドのウェブサイトで商品を購入した直後に、同じ商品のプロモーションメールを送信することは避け、代わりに補完的な商品を提案することで、消費者のエンゲージメント、ロイヤリティ、ブランドへの信頼を高めたいと考えています。しかし、マーケターは多くの場合、様々なチャネル、事業部門、パートナー間で異なっている消費者データを最適化しなければなりません。これらのデータには、情報が不足していたり、スペルミスがあったり、不正確または古い情報が含まれているため、最適化が困難です。 Experian の推定によると、94% もの組織が、自社の消費者や見込み客のデータが不正確である可能性を疑っています。この数値には、データ品質イニシアチブを実施していない企業で 10 〜 30% の重複率が含まれます。これらの課題に対処するために、企業は使いやすく、設定可能で、安全なエンティティ解決機能を必要としており、それによって消費者データを正確にマッチング、リンク、強化することができます。 このブログ記事では、 AWS Entity Resolution を使用してサーバーレスにエンドツーエンドのエンティティ解決ソリューションを構築するのに役立つ、組み合わせ可能なアーキテクチャパターンについて説明します。AWS Entity Resolution は、柔軟で設定可能なワークフローを使用して、複数のアプリケーション、チャネル、データストアにわたる関連データのマッチング、リンク、強化を支援します。この記事では、AWS Entity Resolution を使用して、データの取り込みと準備（ニアリアルタイムおよびバッチベース）、マッチングの実行、ニアリアルタイムでマッチング結果を取得できる自動化されたデータパイプラインの構築に焦点を当てています。顧客は、80 以上の SaaS アプリケーションデータコネクタからのデータ取り込み、重複プロファイルを削除するためのエンティティ解決を含む統合プロファイルの作成、 Amazon Connect Customer Profiles を使用した低レイテンシーのデータアクセスなど、エンドツーエンドのデータ管理ニーズにマネージドサービスも利用できます。関連する顧客情報の完全なビューを 1 か所で得ることで、企業はよりパーソナライズされた顧客サービスを提供し、関連性の高いキャンペーンを展開し、顧客満足度を向上させることができます。 Amazon Connect で統合顧客プロファイルを構築する方法 を読むか、 Choice Hotels が統合旅行者プロファイルを構築するために Customer Profiles をどのように使用したか をご覧いただけます。 ハイレベルな例 提案するソリューションのコンテキストとして、大手 e コマースブランドである AnyCompany の例を使用しましょう。AnyCompany は、消費財（CPG）、電子機器、旅行など、100 以上のサブブランドを持っています。彼らは顧客にパーソナライズされた体験を提供し、顧客ロイヤルティを構築したいと考えています。組み合わせ可能なアーキテクチャパターンを使用して、AnyCompany は複数のソース（顧客関係管理（CRM）、顧客データプラットフォーム（CDP）、コンテンツ管理システム（CMS）、マスターデータ管理（MDM）システム）からレコードを取り込み、顧客の統合ビューを作成するサーバーレスソリューションを構築します。 ソリューションのアーキテクチャ 以下のアーキテクチャと説明は、様々な目的に特化したサーバーレス AWS サービスを使用したデータの取り込み、準備、解決のためのエンドツーエンドのフローの概要を提供します。 Step I – 履歴データ処理 ワークフロー設定の初日（Day 0）として、エンゲージメントシステム（ソースシステム）に AWS Entity Resolution で解決される消費者に関する履歴データが含まれています。 バッチデータ取り込みサービスまたは AWS Data Connector Solution を使用して、履歴データが Amazon Simple Storage Service （Amazon S3）の Raw Zone にロードされます。詳細については、 AWS Cloud Data Ingestion Patterns and Practices を参照してください。 AWS Entity Resolution 用に履歴データを準備するために、 Amazon EventBridge ルールを使って AWS Step Functions Standard workflow を実行し、データエンジニアリングパイプラインをオーケストレーションします。Amazon EventBridge ルールは、バッチデータソースを処理するために特定の頻度で起動するようにスケジュールできます。 AWS Step Functions Standard workflow 内で、 AWS Glue ジョブが Raw Zone（Amazon S3 ロケーション）に格納されたデータを変換します。この手順を使って、個人を特定できる情報（PII）を検証、正規化、保護します。 カスタマイズされたデータ正規化ワークフローの構築については、 Guidance for Customizing Normalization Library for AWS Entity Resolution を参照してください。 データの検証と標準化を含むデータ準備ワークフローの作成については、 Guidance for Preparing and Validating Records for Entity Resolution on AWS を参照してください。 正規化および検証されたデータは、Clean Zone S3バケット内に CSV または parquet 形式で保存され、AWS Glue Catalog で AWS Glue テーブルとしてカタログ化されます。 Clean Zone S3 バケットを設定し、EventBridge 通知を生成します。詳細については、 Use Amazon S3 Event Notifications with Amazon EventBridge を参照してください。 ルールベースのマッチング技術を使用し、自動処理のケイデンスで動作する AWS Entity Resolution マッチングワークフロー を作成します。これにより、Clean Zone に到着する様々なデータセットから ID を解決できます。AWS Entity Resolution は、レコードをリンクおよびマッチングして、MatchGroup と呼ばれるユニークなプロファイルを作成します。各 MatchGroup には一意の永続的 ID（MatchId）が割り当てられます。 Step II – ニアリアルタイムの検索 Amazon API Gateway を使用して、エンゲージメントシステムのニアリアルタイムな ID 解決検索ニーズに対応する REST API をホストします。 AWS Step Functions Synchronous Express Workflows を使用して、既存のエンティティ検索やその他のビジネスルール検証をニアリアルタイムで実現するためのマイクロサービスをオーケストレーションします。Amazon API Gateway を組み合わせて Synchronous Express Workflow を作成する詳細な手順については、 New Synchronous Express Workflows for AWS Step Functions を参照してください。 AWS Step Functions ワークフローは、電子メール、住所、電話番号などの PII データを検証するために、1 つ以上の AWS Lambda 関数を順次または並列に呼び出します。 正規化および検証された PII データは、以前に作成された MatchGroup と照合するための入力として、AWS Entity Resolution の GetMatchId アクションで送信されます。例えば、AnyCompany は、サイト訪問者が既知の消費者であるかどうかを知り、コンテキストに応じた体験を提供したいと考えるかもしれません。この場合、ファーストパーティ（1P）クッキーによって収集されたデータは、GetMatchId API を通じて AWS Entity Resolution に送信され、既知の MatchGroup と照合されます。一致した場合、対応する MatchId が応答として返されます。 Step III – 継続した増分処理 データが一致した場合、エンゲージメントシステムは MatchId を使用し、アプリケーションの意思決定に活用します。この ID はアプリケーションデータベースに保存されるか、ダウンストリームの非同期処理のために生成されるイベントデータを強化するために使用されます。 関連するソース（バッチまたはリアルタイム）からの新たな増分データフィードは全て、MatchGroup を最新の状態に保つために AWS Entity Resolution に送信されます。ニアリアルタイムの検索フローでは、入力された検索リクエストを Amazon Kinesis Data Streams に送信するよう Lambda 関数が設定されています。 Amazon Data Firehose を使用して、ストリーミングデータを S3 バケットに書き込みます。このデータは、履歴処理時に設定されたものと同じワークフローで処理されます。増分データは、以前に作成された MatchGroup と照合するために AWS Entity Resolution に渡されます。増分データが既存の MatchGroup で解決される場合、同じ MatchId を継承し、そうでない場合は独自の MatchId を持つ新しい MatchGroup を作成する可能性があります。増分実行の一部として既存のデータが更新されるシナリオでは、新しい情報が既存の MatchGroup に対して評価され、情報の変更に基づいて、新しい MatchGroup に分割されるか、既存の MatchGroup を維持するかが決まります。 AWS Entity Resolution は、S3 バケットに出力ファイルを生成します。これはパッケージ化され、AWS Glue を使用してアクティベーションとパーソナライゼーションのためにエンゲージメントシステムに送信されます。このポスト処理では、他の処理と共に、複数のソースからのレコードを単一のゴールデンレコードにマージする場合があります。ポスト処理には、人間による分類のためにサービスが生成する、ワークフローエラーファイルの処理も含まれます。 セキュリティ 以下の AWS サービスを使用して、セキュリティとアクセス制御を実装します： AWS Identity and Access Management（IAM） : 特定のリソースとオペレーションへの最小特権アクセス AWS Key Management Service（AWS KMS） : 保存中、および転送中のデータを保護するために使用される暗号化キーのライフサイクル管理 AWS Secrets Manager : パスワードや API キーなどの秘密情報を安全に保存 Amazon CloudWatch : このソリューションで使用されるすべてのサービスのログやメトリクスを一元管理 結論 本記事では、AnyCompany のユースケースを例にし、消費者にパーソナライズされた体験を提供するために、AWS サービスを使用してサーバーレスのエンティティ解決ワークフローを構築する方法を紹介しました。その中で、データマッチングワークフローを構築できる AWS Entity Resolution の 3 つの主要機能を紹介しました。 ニアリアルタイムのエンティティ検索 自動増分処理 オンデマンドバッチワークフロー 詳細については、 AWS Entity Resolution の機能 をご覧ください。 また、ニアリアルタイムのシステム統合とバッチデータ処理ワークフローのためのマイクロサービスオーケストレーションを構築するために、他の AWS サーバーレスサービスをどのように組み合わせることができるかについても説明しました。詳細については、 AWS Entity Resolution resources をご覧ください。 TAGS: identity resolution , serverless Ranjith Krishnamoorthy Ranjith は、広告およびマーケティングテクノロジー業界ソリューションチームにおけるデータプラットフォームのワールドワイドの責任者です。この役割において、彼の焦点は、AWS のサービス、AWS ソリューション、ソリューションガイダンス、およびパートナーソリューションを使用して、AWS の顧客が広告およびマーケティングのビジネス目標を達成するのを支援することにあります。彼は、大手企業（通信、小売、製造）、独立系ソフトウェアベンダー、システムインテグレーターでの 20 年以上にわたる幅広い国際経験を活かし、顧客の課題解決に取り組んでいます。彼の目標は、深く掘り下げて公平な視点を提供し、顧客がビジネスおよび技術的課題に対応するための適切なクラウドおよびデータ分析技術 / アーキテクチャを選択するのを支援することです。現在、プライバシー強化データコラボレーション、オーディエンスおよび顧客データ管理、リアルタイム広告ソリューション分野のユースケースに対応する AWS ソリューションの市場投入に取り組んでいます。 Punit Shah Punit は、アマゾン ウェブ サービスのシニアソリューションアーキテクトです。彼の役割は、顧客がクラウド上でデータおよび分析戦略を構築するのを支援することに焦点を当てています。現在の職務では、AWS Entity Resolution、Amazon Connect、Amazon Neptune などの AWS サービスを使用して、広告およびマーケティングのユースケースを解決するための強固なデータ基盤の構築を顧客に支援しています。彼は大規模なデータレイクの構築において 15 年以上の業界経験を持っています。 Shobhit Gupta Shobhit は、アマゾン ウェブ サービスのプロダクト責任者です。彼は、ヘルスケア、小売、金融サービス、公共部門などの業界にまたがる機械学習のためのデータ管理サービスの構築に関する専門知識を持っています。AWS では、AWS Clean Rooms、Amazon Connect、AWS Entity Resolution、Amazon Personalize など、データと機械学習が交差するチームと協力しています。彼は連続起業家であり、モバイルアプリケーション、ビッグデータ、モノのインターネット（IoT）分野で企業をスケールさせた 10 年以上の経験を持っています。また、経営コンサルティングにも携わり、公共部門、ヘルスケア、小売の顧客にアドバイスを提供してきました。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

この 20 年で、3,283 件の記事を投稿し、合計 1,577,106 文字を綴った私は、AWS ニュースブログのリードブロガーとしての仕事を締めくくろうとしています。 過去 20 年間において、「未来に生きる」と同時に、ほんのいくつかを挙げると、 メッセージキューイング 、 ストレージ 、 オンデマンドコンピューティング 、 サーバーレス 、 量子コンピューティング などの多くの AWS のイノベーションについて学び、書くことができて光栄でした。また、長年にわたって私のコンテンツを忠実に読み、(願わくば) 学んでくださった多くの皆さんに会ったり、連絡をいただいたりしたことも素晴らしい経験でした。こうした交流と皆さんの優しい言葉は私の宝物です。書くときは、その両方を念頭に置いています。 Jeff の今後 私はビルダーとしてキャリアを開始しました。何年にもわたり、私は何万行ものアセンブリコード (6502、Z80、68000)、Visual Basic、PHP、そして何十万行もの C を書いてきました。しかし、構築に費やす時間は次第に減り、構築について話す時間が増えていきました。新しいサービスや機能がサポート終了を迎えるたびに、実際にこれらのサービスや機能を使ってクールな何かを作ることができた日々や時代のことを思い出します。私はマーケティングができる開発者から、以前は開発ができたマーケティング担当者になりました。それには何の問題もありませんでしたが、私は構築するのが好きなのです。コード、3D 印刷、レゴブロック、電子部品、または段ボール。媒体はなんでもかまいません。創造と革新こそが、私のモチベーションおよび支えとなっています。 そのことを原動力とした、私のキャリアでの次のステップにおける目標は、より少ないものの学習および使用、クールな何かの構築、開発者に焦点を当てた新鮮なコンテンツの作成に焦点を当て、より多くの時間を費やすことです。これがどのような形になるかはまだ検討中ですので、ご期待ください。また、引き続き AWS OnAir (金曜日の Twitch 番組) に毎週出演するとともに、世界中の AWS コミュニティイベントでも講演する予定です。 ブログの今後 AWS ニュースブログに関してお話しすると、長い間、皆さんに記事をお届けするスタッフも縁の下の力持ちも含む、素晴らしいチームに支えられてきました。ブログの 20 周年を記念して最近開催された AWS re:Invent の様子です (写真提供: Liz Fuentes 。 Channy Yun による編集で、その場にいなかった人々の写真を付け加えています)。 お祝いの場で、私はチームに、re:Invent 2034 で彼らと一緒に 30 周年を祝うことを楽しみにしていると伝えました。 今後もチームは成長を続けますが、最新かつ最も有意義な AWS のリリースについて、厳選された質の高い情報をお客様に提供するという目標は変わりません。このブログは、優れた人々に引き継がれます。AWS のイノベーションのペースが加速し続けている中、このチームは引き続き皆さんに情報を提供してまいります。 改めて、ありがとうございました 改めて、長年にわたり非常に親切な言葉と姿勢を示してくださった皆さんに感謝します。一生に一度、一生懸命働き、本当に運が良ければ、人々にとって真に重要なことを行う、またとない機会を得ることができます。私はとても運が良かったのだと言えます。 – Jeff ; 原文は こちら です。

AWS re:Invent の次の週は、イベントの興奮とエネルギーがさらに高まります。これは、詳細について学び、最新の発表が課題の解決にどのように役立つかを理解する良い機会です。いつものように、 AWS re:Invent 2024 の注目の発表の記事 をご用意しました。 AWS イベントの YouTube チャンネル で、基調講演やセッションを視聴できるようになりました。今年、Amazon の President 兼 CEO となった Andy Jassy は、 re:Invent に戻り、これらの動画でいくつかの考えを共有 しました。 Amazon の VP 兼 CTO である Werner Vogels は、Amazon が大規模に分散システムを構築してきた経験を活かして、複雑なシステムを管理するために学んだ重要な教訓と戦略を 基調講演 で共有しました。 12 月 9 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Elastic Compute Cloud (Amazon EC2) – 新世代の FPGA 搭載インスタンス (F2) が利用可能になりました 。1 つの機能を念頭に置いて設計され、それを実装するために配線された専用チップとは対照的に、フィールドプログラマブルゲートアレイ (FPGA) は、PC ボードのソケットに接続した後に、フィールドでプログラミングできます。また、6 TiB と 8 TiB のメモリを搭載した Amazon EC2 High Memory U7i インスタンスもリリース します。U7i インスタンスは、SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースを実行するのに最適です。Graviton ベースの第 8 世代インスタンスは、 Amazon VPC と Amazon EBS の帯域幅設定のサポート を開始しました。 Amazon Bedrock Guardrails – 生成 AI アプリケーションの保護対策の実装を支援するため、 価格を最大 85% 引き下げ ています。また、スペイン語とフランス語をサポートする 多言語機能 も追加しています。 Amazon Simple Email Services (SES) – マルチリージョンの送信レジリエンスを高めるグローバルエンドポイント の提供を開始しました。また、DomainKeys Identified Mail (DKIM) 管理の使用を簡素化する、新しい形式のグローバルアイデンティティである Deterministic Easy DKIM (DEED) のリリースを発表しました。 AWS CloudFormation – AWS Secrets Manager 変換の拡張バージョンでは、自動の AWS Lambda アップグレードの提供を開始しました。 Amazon Lex – ヨーロッパベースのモデル (ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語、スペイン語) とアジアパシフィックベースのモデル (中国語、韓国語、日本語) の 2 つの専門グループを通じて認識精度を向上させる、新しい 多言語ストリーミング音声認識モデル をリリースします。 Amazon Connect – iOS デバイスと Android デバイスでの モバイルチャットのプッシュ通知のサポート を開始しました。これにより、能動的にチャットしていないときでも、エージェントやチャットボットから新しいメッセージが届いたら、すぐに能動的な通知を受け取ることができます。また、 コンタクトセンターの営業時間に対して、休日やその他の差異を設定 できるようになりました。 AWS Security Hub – クレジットカードとデビットカードの情報を安全に取り扱うための一連のルールとガイドラインを提供するコンプライアンスフレームワークである、 ペイメントカード業界データセキュリティ基準 (PCI DSS) v4.0.1 に準拠した自動セキュリティチェックのサポート を開始しました。 AWS Resource Explorer – Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Kendra 、 、AWS Identity and Access Management (IAM) Access Analyzer 、 Amazon SageMaker など、 59 種類の新しいリソースタイプをサポート します。 Amazon SageMaker AI – 推論向けに最適化された Amazon EC2 G6e インスタンス ( NVIDIA L40S Tensor Core GPU を搭載) と P5e (NVIDIA H200 Tensor Core GPU を搭載) を Amazon SageMaker で利用 できるようになりました。 Amazon Redshift – ゼロ ETL 統合のテーブルで、自動的かつ段階的に更新可能なマテリアライズドビューのサポート を開始しました。以前は、このような場合、完全更新を実行する必要がありました。 AWS Toolkit for Visual Studio Code – ログをリアルタイムで可視化し、アプリケーションの開発とトラブルシューティングを容易にする、インタラクティブなログストリーミングおよび分析機能である Amazon CloudWatch Logs Live Tail が追加 されました。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Amazon S3 テーブルを使用したマネージド型トランザクションデータレイクの構築 – re:Invent 2024 で発表されたばかりの Amazon S3 テーブル は、 Apache Iceberg のサポートが組み込まれた初のクラウドオブジェクトストアであり、表形式のデータを大規模に保存する最も簡単な方法です。 AWS ストレージブログのこの記事 では、S3 テーブルの概要と、 Amazon EMR で Apache Spark を使用して S3 テーブルでトランザクションデータレイクを構築する方法の例をご紹介します。 AWS PrivateLink のクロスリージョン接続の紹介 – さまざまな AWS リージョン 間で Amazon Virtual Private Cloud (Amazon VPC) エンドポイントサービスを共有およびアクセスするために使用できる、この最近のリリースに関する詳細情報をご覧ください。 AWS の VP 兼 Distinguished Engineer である Marc Brooker は、 Amazon Aurora DSQL とは何か、その仕組み、および最大限活用する方法について、 個人ブログ にいくつか記事を投稿しています。 DSQL Vignette: Aurora DSQL, and A Personal Story DSQL Vignette: Reads and Compute DSQL Vignette: Transactions and Durability DSQL Vignette: Wait! Isn’t That Impossible? 12 月 16 日週のニュースは以上です。12 月 23 日週の Weekly Roundup もお楽しみに! – Danilo この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

最大 8 個の AMD FPGA、最大 192 コアの AMD EPYC (Milan) プロセッサ、高帯域幅メモリ (HBM)、最大 8 TiB の SSD ベースのインスタンスストレージ、最大 2 TiB のメモリを搭載した F2 インスタンスは、2 つのサイズからお選びいただけます。このインスタンスを使用すると、ゲノミクス、マルチメディア処理、ビッグデータ、衛星通信、ネットワーキング、シリコンシミュレーション、ライブ動画ワークロードを加速できます。 FPGA の簡単なまとめ FPGA を搭載した第 1 世代の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを プレビュー したとき、FPGA モデルについて、次のように説明しました カスタムかつハードウェアベースのソリューションへの興味深いルートの 1 つは、Field Programmable Gate Array (FPGA) として知られています。1 つの機能を念頭に置いて設計された専用チップとは対照的に、FPGA はより柔軟です。PC ボードのソケットに差し込んだ後、現場でプログラミングできます。各 FPGA には、固定かつ有限数のシンプルなロジックゲートが含まれています。FPGA のプログラミングでは、それらを接続して目的の論理関数 (AND、OR、XOR など) またはストレージ要素 (フリップフロップとシフトレジスタ) を作成するだけです。基本的にシリアル (いくつかの並列要素を含む) で、固定サイズの指示とデータパス (通常は 32 ビットまたは 64 ビット) を備えた CPU とは異なり、FPGA は多くの演算を並行して実行するようにプログラミングすることが可能で、演算自体の幅の広狭にはほぼ制限がありません。 リリース以来、AWS のお客様は F1 インスタンスを利用して、さまざまな種類のアプリケーションやサービスをホストしてきました。より新しい FPGA、より高い処理能力、より多くのメモリ帯域幅を備えた新しい F2 インスタンスは、高度な並列化が可能で、コンピューティング負荷が高いワークロードのホストとしてより優れています。 AMD Virtex UltraScale+ HBM VU47P FPGA には、それぞれ 285 万個のシステムロジックセルと、9,024 個の DSP スライス (INT8 値の処理時に最大 28 TOPS の DSP コンピューティングパフォーマンス) が搭載されています。各 F2 インスタンスに関連付けられた FPGA アクセラレータカードは、FPGA あたり 16 GiB の高帯域幅メモリと 64 GiB の DDR4 メモリを提供します。 F2 の内部 F2 インスタンスは、第 3 世代 AMD EPYC (Milan) プロセッサを搭載しています。F1 インスタンスと比較すると、プロセッサコア数は最大 3 倍、システムメモリと NVMe ストレージは最大 2 倍、ネットワーク帯域幅は最大 4 倍です。各 FPGA には、最大 460 GiB/ 秒の帯域幅を備えた 16 GiB の高帯域幅メモリ (HBM) が搭載されています。インスタンスサイズと仕様については、こちらをご覧ください。 インスタンス名 vCPU FPGA FPGA メモリ HBM/DDR4 インスタンスメモリ NVMe ストレージ EBS 帯域幅 ネットワーク帯域幅 f2.12xlarge 48 2 32 GiB/ 128 GiB 512 GiB 1900 GiB (2x 950 GiB) 15 Gbps 25 Gbps f2.48xlarge 192 8 128 GiB/ 512 GiB 2,048 GiB 7600 GiB (8x 950 GiB) 60 Gbps 100 Gbps ハイエンドの f2.48xlarge インスタンスは AWS Cloud Digital Interface (CDI) をサポートしているため、非圧縮のライブ動画をアプリケーション間で確実に転送できます。インスタンス間のレイテンシーは 8 ミリ秒と低くなります。 FPGA アプリケーションの構築 AWS EC2 FPGA Development Kit には、ハードウェアアクセラレーション FPGA アプリケーションの開発、シミュレーション、デバッグ、コンパイル、実行に使用するツールが含まれています。キットの FPGA Developer AMI をメモリ最適化インスタンスまたはコンピューティング最適化インスタンスで起動して開発とシミュレーションを行い、F2 インスタンスを使用して最終的なデバッグとテストを行うことができます。 開発者キットに含まれるツールは、さまざまな開発パラダイム、ツール、アクセラレータ言語、デバッグオプションをサポートしています。いずれを選択しても、最終的にはカスタムアクセラレーションロジックと、FPGA メモリ、PCIe バス、割り込み、外部周辺機器へのアクセスを実装する AWS Shell を含む Amazon FPGA Image (AFI) を作成できます。AFI は、必要な数の F2 インスタンスにデプロイしたり、他の AWS アカウントと共有したり、AWS Marketplace で公開したりできます。 F1 インスタンスで実行するアプリケーションを既に作成している場合は、最新の AMD ツールを使用するように開発環境を更新し、F2 インスタンスにアップグレードする前に再構築して検証する必要があります。 稼働中の FPGA インスタンス F1 インスタンスと F2 インスタンスがユニークかつ極めて要求の厳しいワークロードをどのようにサポートできるかを示す、優れた例をいくつか示します。 ゲノミクス – 多国籍の製薬およびバイオテクノロジー企業である AstraZeneca は、数千の F1 インスタンスを使用して世界最速のゲノミクスパイプラインを構築しました。このパイプラインでは、2 か月以内に 40 万を超える全ゲノムサンプルを処理できます。F2 で Illumina DRAGEN を採用すると、より低コストでより優れたパフォーマンスを実現すると同時に、疾患の発見、診断、治療を加速することができます。 衛星通信 – 衛星通信事業者は、柔軟性がなく高価な物理インフラストラクチャ (変調器、復調器、コンバイナ、スプリッタなど) から、アジャイルかつソフトウェア定義の FPGA 搭載ソリューションに移行しています。FPGA のデジタルシグナルプロセッサ (DSP) 要素を使用することで、これらのソリューションを現場で再設定して、新しい波形に対応したり、変化する要件に対応したりすることができます。インスタンスあたり最大 8 個の FPGA のサポート、十分なネットワーク帯域幅、 仮想イーサネット を使用した Data Plan Development Kit (DPDK) のサポートなど、F2 の主要な機能を使用して、複数の複雑な波形の並列処理をサポートできます。 分析 – NeuroBlade の SQL プロセッシングユニット (SPU) は、Presto、Apache Spark、およびその他のオープンソースのクエリエンジンと統合され、F2 インスタンスで実行した場合、より高速なクエリ処理と市場をリードするクエリスループット効率を実現します。 知っておくべきこと これらの F2 インスタンスについて知っておくべきことがいくつかあります。 リージョン – F2 インスタンスは、現在米国東部 (バージニア北部) と欧州 (ロンドン) の AWS リージョンで利用可能です。今後、他のリージョンでも利用可能になる予定です。 オペレーティングシステム – F2 インスタンスは Linux 専用です。 購入オプション – F2 インスタンスは、 オンデマンド 、 スポット 、 Savings Plan 、 ハードウェア専有インスタンス 、 専有ホスト の形式で使用できます。 – Jeff ; 原文は こちら です。

12 月 4 日、 Buy with AWS を発表しました。これは、 AWS パートナー サイトから AWS Marketplace で入手可能なソリューションを検索および購入する新しい方法です。Buy with AWS を使用すると、 Amazon Web Services (AWS) 外のウェブサイトでの製品調達プロセスを迅速化および合理化できます。この機能では、AWS アカウントを使用して、パートナーのウェブサイトからソリューションを検索、試用、購入することができます。 AWS Marketplace は、パートナーが提供するクラウドソリューションを検索、購入、デプロイ、管理するための厳選されたデジタルストアです。Buy with AWS は、必要なときに必要な場所で適切なパートナーソリューションを見つけて調達することが容易になる AWS Marketplace へのもう 1 つのステップです。AWS Marketplace のソリューションは、統合された AWS サービスコンソールから利便性の高い方法で検索および購入できますが、パートナーのウェブサイトで検索して購入することも可能になりました。 クラウドソリューションの発見と評価を加速 AWS 以外のウェブ上でソリューションを探すとき、AWS Marketplace から購入できるパートナーのソリューションを見つけることができるようになりました。 パートナーサイトを参照するときに「Available in AWS Marketplace」の製品を探し、無料トライアルへのすばやいアクセス、デモのリクエスト、カスタム価格の問い合わせを行って評価プロセスを加速できます。 例えば、 Wiz がクラウドのセキュリティ要件にどのように役立つかを評価するとします。Wiz のウェブサイトを閲覧すると、「 Connect Wiz with Amazon Web Services (AWS) 」というページが見つかります。 [Try with AWS] を選択します。サインインしていない場合は、AWS アカウントにサインインするよう要求されます。その後、無料トライアルにサインアップするための Wiz と AWS の共同ブランドページが表示されます。 表示される発見エクスペリエンスは、購入元のパートナーウェブサイトのタイプに応じて異なります。Wiz は、独立系ソフトウェアベンダーが Buy with AWS をどのように実装できるかを示す一例です。次に、独自のストアフロントを運営している AWS Marketplace チャネルパートナー (リセラー) の例を見てみましょう。 AWS Marketplace の製品リストが掲載されている Bytes のストアフロント にアクセスします。Bytes サイトには、フィルターを適用して AWS Marketplace で入手可能な厳選された製品リストから検索できるオプションがあります。 Fortinet の [View Details] を選択すると、AWS からのプライベートオファーをリクエストする [Request Private Offer] のオプションが表示されます。 ここに見られるように、チャネルパートナーのサイトでは、AWS Marketplace で入手可能な厳選された製品リストの閲覧、製品のフィルタリングに加えて、AWS アカウントを使用してカスタム価格をリクエストすることができます。 AWS パートナーサイトの製品調達を合理化する ここまで、Buy with AWS を使用して Wiz の無料トライアルにアクセスし、Bytes ストアフロントを閲覧してプライベートオファーをリクエストするというシームレスな体験を紹介しました。 今度は、私が開発中のアプリケーションで Databricks を試してみたいと思います。Databricks のウェブサイトから Databricks のトライアル にサインアップします。 [Upgrade] を選択すると、Databricks が AWS Marketplace で入手可能であることがわかります。AWS で購入する [Buy with AWS] のオプションが表示されます。 [Buy with AWS] を選択します。AWS アカウントにサインインすると、Databricks と AWS Marketplace の共同ブランドの調達ページが表示されます。 共同ブランドの調達ページで購入を完了し、Databricks アカウントの設定を行います。 この例で見られたように、複数のベンダーの調達プロセスを管理するという課題に対処する必要はありませんでした。また、営業担当者と話す必要や、請求システムで新しいベンダーのオンボーディングを行う必要もありませんでした。仮に請求システムでオンボーディングを行った場合、複数の承認が必要になり、プロセス全体が遅れてしまいます。 AWS Marketplace を介して一元化された請求と特典にアクセスする Buy with AWS での購入は AWS Marketplace を通して処理され、AWS Marketplace で管理されるため、統合された AWS の請求、一元的なサブスクリプション管理、コスト最適化ツールへのアクセスなど、購入後の AWS Marketplace のメリットもあります。 例えば、 AWS Billing and Cost Management から、Buy with AWS での購入を含むすべての AWS 購入を 1 つのダッシュボードで一元管理できます。組織での AWS 購入のすべての請求書に簡単にアクセスして処理できます。また、サブスクリプションの管理と AWS Marketplace からの購入を行うには、有効な AWS Identity and Access Management (IAM) アクセス許可 が必要です。 AWS Marketplace は、請求処理を簡素化するだけでなく、組織の購買権限とサブスクリプションアクセスを一元的に可視化して管理できるようになるので、購買に関するガバナンスを維持するためにも役立ちます。柔軟な価格設定、コストの透明性、AWS コスト管理ツールで予算を管理できます。 パートナーにとっての Buy with AWS Buy with AWS では、AWS Marketplace で製品を販売または再販するパートナーは、自社のウェブサイトで顧客に新しいソリューション発見と購入のエクスペリエンスを提供できます。パートナーは、「Buy with AWS」、「Try free with AWS」、「Request private offer」、「Request demo」などの行動の呼びかけ (CTA) ボタンをウェブサイトに追加することで、顧客の製品評価と購入までのプロセスを短縮できます。 パートナーは、 AWS Marketplace API を統合することで、AWS Marketplace カタログの製品の表示、顧客による製品のソートとフィルター、プライベートオファーの合理化を行うことができます。Buy with AWS を実装するパートナーは、AWS Marketplace のクリエイティブリソースやメッセージングリソースにアクセスして、独自のウェブ体験を構築するためのガイダンスを利用できます。Buy with AWS を実装するパートナーは、メトリクスにアクセスしてエンゲージメントとコンバージョンパフォーマンスに関するインサイトを取得できます。 AWS Marketplace 管理ポータルの Buy with AWS オンボーディングガイド には、パートナーが Buy with AWS の利用を開始する方法が詳しく説明されています。 詳細情報 Buy with AWS のページ にアクセスして詳細を確認し、Buy with AWS を提供するパートナーサイトを参照してください。 ウェブサイトで Buy with AWS を使用して製品を販売または再販する方法の詳細については、以下をご覧ください。 Buy with AWS の出品者向けページ AWS Marketplace 管理ポータルの Buy with AWS オンボーディングガイド – Prasad 原文は こちら です。

12 月 4 日、 Amazon SageMaker HyperPod レシピ の一般提供が開始されたことをお知らせいたします。このレシピは、あらゆるスキルセットのデータサイエンティストや開発者が、 基盤モデル (FM) のトレーニングと微調整を数分で開始できるようにすると同時に、最先端のパフォーマンスを実現します。 Llama 3.1 405B 、 Llama 3.2 90B 、 Mixtral 8x22B など、一般公開されている人気の FM をトレーニングおよび微調整するための最適化されたレシピをご利用いただけるようになりました。 AWS re:Invent 2023 では、FM のトレーニングにかかる時間を最大 40% 短縮し、事前設定された分散トレーニングライブラリと並行して 1,000 個を超えるコンピューティングリソース全体でのスケールリングを可能にする、 SageMaker HyperPod を発表 しました。SageMaker HyperPod を使用すると、トレーニングに必要な高速コンピューティングリソースを見つけ、最適なトレーニングプランを作成し、コンピューティングリソースの可用性に応じて、さまざまなキャパシティブロックにまたがってトレーニングワークロードを実行できます。 SageMaker HyperPod レシピには AWS でテストされたトレーニングスタックが含まれているため、さまざまなモデル構成を試す面倒な作業を省くことができ、何週間にもわたる反復的な評価とテストが不要になります。レシピは、トレーニングデータセットの読み込み、分散トレーニング手法の適用、障害からの迅速な回復のためのチェックポイントの自動化、エンドツーエンドのトレーニングループの管理など、いくつかの重要なステップを自動化します。 レシピを変更するだけで、GPU ベースと Trainium ベースのインスタンスの切り替えがシームレスに行え、トレーニングパフォーマンスをさらに最適化し、コストを削減できます。SageMaker HyperPod または SageMaker トレーニングジョブでは、本稼働のワークロードを簡単に実行できます。 SageMaker HyperPod レシピの実践 はじめに、 SageMaker HyperPod レシピの GitHub リポジトリ にアクセスして、一般公開されている人気の FM 用トレーニングレシピを参照します。 簡単なレシピパラメータを編集して、クラスター構成のインスタンスタイプやデータセットの場所を指定するだけで、1 行のコマンドでレシピを実行し、最先端のパフォーマンスを実現できます。 リポジトリの複製後、レシピの config.yaml ファイルを編集して、モデルとクラスタータイプを指定する必要があります。 $ git clone --recursive https://github.com/aws/sagemaker-hyperpod-recipes.git $ cd sagemaker-hyperpod-recipes $ pip3 install -r requirements.txt. $ cd ./recipes_collections $ vim config.yaml レシピは、 Slurm を使用した SageMaker HyperPod 、 Amazon Elastic Kubernetes Service (Amazon EKS) を使用した SageMaker HyperPod 、 SageMaker トレーニングジョブ をサポートしています。例えば、クラスタータイプ (Slurm オーケストレーター)、モデル名 (Meta Llama 3.1 405B 言語モデル)、インスタンスタイプ ( ml.p5.48xlarge )、そしてトレーニングデータ、結果、ログなどを保存するデータロケーションを設定できます。 defaults: - cluster: slurm # サポート: slurm / k8s / sm_jobs - recipes: fine-tuning/llama/hf_llama3_405b_seq8k_gpu_qlora # トレーニングするモデルの名前 debug: False # ランチャーの設定をデバックする場合は True に設定 instance_type: ml.p5.48xlarge # またはその他のサポートされているクラスターインスタンス base_results_dir: # 結果、チェックポイント、ログなどを保存する場所 必要な場合、この YAML ファイルのモデル固有のトレーニングパラメータを調整できます。このパラメータには、アクセラレータデバイスの数、インスタンスタイプ、トレーニング精度、並列化とシャーディングの手法、オプティマイザー、 TensorBoard による実験をモニタリングするためのログ記録など、最適な構成の概要が記載されています。 run: name: llama-405b results_dir: ${base_results_dir}/${.name} time_limit: "6-00:00:00" restore_from_path: null trainer: devices: 8 num_nodes: 2 accelerator: gpu precision: bf16 max_steps: 50 log_every_n_steps: 10 ... exp_manager: exp_dir: # TensorBoard ログ記録の場所 name: helloworld create_tensorboard_logger: True create_checkpoint_callback: True checkpoint_callback_params: ... auto_checkpoint: True # 自動チェックポイント用 use_smp: True distributed_backend: smddp # 最適化された集団通信 # 事前トレーニング済みのモデルからトレーニングを開始 model: model_type: llama_v3 train_batch_size: 4 tensor_model_parallel_degree: 1 expert_model_parallel_degree: 1 # その他のモデル固有のパラメータ Slurm を使用した SageMaker HyperPod でこのレシピを実行するには、 クラスターのセットアップ手順 に従って SageMaker HyperPod クラスターを準備する必要があります。 次に、SageMaker HyperPod ヘッドノードに接続し、Slurm コントローラーにアクセスして、編集したレシピをコピーします。続いて、ヘルパーファイルを実行して、ジョブの Slurm 送信スクリプトを生成します。このスクリプトは、トレーニングジョブの開始前に内容を検査するためのドライランに使用できます。 $ python3 main.py --config-path recipes_collection --config-name=config トレーニングが完了すると、トレーニングされたモデルは自動的に割り当てられたデータロケーションに保存されます。 Amazon EKS を使用した SageMaker HyperPod でこのレシピを実行するには、GitHub リポジトリからレシピを複製し、要件をインストールして、ノートパソコンでレシピ ( cluster: k8s ) を編集します。次に、ノートパソコンと実行中のEKS クラスター間のリンクを作成し、続いて HyperPod コマンドラインインターフェイス (CLI) を使用して、レシピを実行します。 $ hyperpod start-job –recipe fine-tuning/llama/hf_llama3_405b_seq8k_gpu_qlora \ --persistent-volume-claims fsx-claim:data \ --override-parameters \ '{ "recipes.run.name": "hf-llama3-405b-seq8k-gpu-qlora", "recipes.exp_manager.exp_dir": "/data/<your_exp_dir>", "cluster": "k8s", "cluster_type": "k8s", "container": "658645717510.dkr.ecr.<region>.amazonaws.com/smdistributed-modelparallel:2.4.1-gpu-py311-cu121", "recipes.model.data.train_dir": "<your_train_data_dir>", "recipes.model.data.val_dir": "<your_val_data_dir>", }' SageMaker Python SDK を使用して SageMaker トレーニングジョブでレシピを実行することもできます。次の例では、トレーニングレシピをオーバーライドして、SageMaker トレーニングジョブで PyTorch トレーニングスクリプトを実行しています。 ... recipe_overrides = { "run": { "results_dir": "/opt/ml/model", }, "exp_manager": { "exp_dir": "", "explicit_log_dir": "/opt/ml/output/tensorboard", "checkpoint_dir": "/opt/ml/checkpoints", }, "model": { "data": { "train_dir": "/opt/ml/input/data/train", "val_dir": "/opt/ml/input/data/val", }, }, } pytorch_estimator = PyTorch( output_path=<output_path>, base_job_name=f"llama-recipe", role=<role>, instance_type="p5.48xlarge", training_recipe="fine-tuning/llama/hf_llama3_405b_seq8k_gpu_qlora", recipe_overrides=recipe_overrides, sagemaker_session=sagemaker_session, tensorboard_output_config=tensorboard_output_config, ) ... トレーニングの進行に伴い、モデルチェックポイントは Amazon Simple Storage Service (Amazon S3) に保存され、完全に自動化されたチェックポイント機能により、トレーニング障害やインスタンスの再起動からの迅速な復旧が可能になります。 今すぐ利用可能 Amazon SageMaker HyperPod レシピが SageMaker HyperPod レシピの GitHub リポジトリ で入手可能になりました。詳細については、 SageMaker HyperPod の製品ページ と「 Amazon SageMaker AI デベロッパーガイド 」をご覧ください。 SageMaker HyperPod レシピをお試しいただき、 AWS re:Post for SageMaker 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

この記事は、「 Use AWS services to build secure, resilient, and global OT and IT networks 」を翻訳したものです。 エネルギー企業は事業領域において多数の制御・運用技術 (OT)、情報技術 (IT)、および OT 資産を展開しています。SCADA (監視制御および データ収集) システム、OPC UA サーバー、PLC、IoT デバイス、ヒストリアンなどは、AWS のエネルギー業界のお客さまが利用している最も著名な OT 資産の一部です。これらの OT 資産は、エネルギー産業だけに限らず、石油・ガス、再生可能エネルギー、製造業、自動車産業、建設業など、他業界でも大きな存在感があります。 OT とは、バックグラウンドで動作する機械、ハードウェア、デバイス、センサーなどを指します。OT 資産は、多くの場合、目的特化型で作られ、時には数十年という長期間使用され、カスタムプロトコル (200 種類以上) で通信し、重要資産を制御するため、重要インフラとしてしばしば言及されます。発電所、変電所、変圧器、送電網などがその例です。一方、IT は、データの可用性、セキュリティ、可観測性、トレーサビリティ、分析、認可されたアクセス、ニアリアルタイムの状態監視、人工知能/機械学習 (AI/ML) などの必要なツールを提供する役割を担っています。 組織の成功のためには、OT と IT が互いを補完し、シナジーを生む必要があります。しかしながら、特に OT/IT インフラストラクチャをクラウド上に展開する際、エネルギー業界のお客さまは危険と隣り合わせの様々な課題を抱えながら取り組みを進めているのが現状です。規制コンプライアンス(NERC CIP: 北米電力信頼度協会の重要インフラ防護基準)、サイバーセキュリティ、レジリエンス、接続性、さらには時として文化的偏見などが、OT と IT の統合に関してお客さまが直面する最も一般的な課題です。 お客さまとの対話の中で、私たちが常に目にするのは、産業用 OT/IT/IoT ワークロードで唯一共通することは、一貫性の欠如であるということです。デバイス、プロトコル、OEM、エッジ構成など、あらゆるものがそれぞれの仕様を持ちます。エネルギー企業は、OT 資産から絶え間なく発生するデータフローを取り込み、正規化/コンテキスト化し、解釈し、最終的にはインテリジェントな意思決定を行うための、堅牢で安全かつスケーラブルなメカニズムを必要としています。 OT/IT 統合に AWS を活用する エネルギー業界のお客さまが IT、OT、サイバーセキュリティに AWS を活用できる主なユースケースには、以下が含まれます(ただしこれらに限定されるものではありません): IT ヒストリアンのモダナイゼーション ( AWS 上での AVEVA PI System の活用 など) (訳者注: AWS 上での AVEVA PI System のホスティングについて詳しく知りたい方は Guidance for Hosting AVEVA PI System on AWS もご覧ください) 100 % のデータ所有権を実現する産業用 IoT データレイク ニアリアルタイムの状況認識、監視、制御 ( AWS IoT や Esri ArcGIS Velocity を使った公益施設のリアルタイムなダッシュボードと分析 など) 分析、レポーティング、高度な AI/ML 活用 予知保全 出力制御、スケジューリング、ディスパッチ管理 OT データとシームレスに連携し、インテリジェントな意思決定を促進する、安全なグローバル IT ネットワークの構築 昨年、 AWS 上の再生可能エネルギーデータレイクおよび分析のためのソリューション ガイダンスをリリースしました。このソリューションは、インドの Greenko グループ が 2,200 基の風力タービンの AWS 上での監視と分析に活用されています。(詳細は こちら をご覧ください)。このソリューションガイダンスは、再生可能エネルギー以外にも、SCADA システム、PLC、IoT デバイスなどの OT システムを活用する石油・ガスや従来型のエネルギー発電・運用事業者にも等しく適用可能です。 OT デバイス、プロトコル、エッジ構成からの解放 (つまり、クラウドへの接続性やデータ転送時・保存時のセキュリティを気にすることなく、あらゆる産業用デバイスを自由に選択できること) 様々な OT 資産 (SCADA システム、OPC UA サーバー、PLC、IoT デバイス、ヒストリアンなど) をシームレスかつ迅速にオンボーディングできる、安全なグローバル OT ネットワークの構築 エッジ側の OT 資産に加えた変更がクラウド上のアプリケーションにリアルタイムで可視化され、その逆も可能なエッジ駆動のアーキテクチャ エッジでのコンピューティングおよび ML 機能を含む、クラウドからエッジへの互換性の提供 サイバーセキュリティ Purdue モデル (ネットワークレイヤーでの分離と OT/IT 資産間のトラフィック分離に関するレファレンス) に基づくクラウド上のグローバル OT/IT セキュアインフラストラクチャの構築 エッジからクラウドまで一切のインターネットを経由しない 100 % プライベートネットワーク カスタムルールに基づく通信パケットの詳細検査 サイバーインシデント発生時の影響範囲の最小化 侵害されたネットワークやアプリケーションの迅速な隔離 1 か所から全ネットワークを管理することによるネットワーク複雑性の低減 Purdue モデルに基づくセキュア OT/IT インフラの AWS を活用した構築 Purdue Enterprise Reference Architecture (PERA) の一部として開発された Purdue モデル は、産業制御システム (ICS) ネットワークアーキテクチャを構築するための一般的な標準となっています。このモデルでは OT、IT、セキュリティ、外部ネットワーク接続、それぞれに対して、分離されたネットワークセグメントを構築することを推奨しており、OT/IT ネットワークインフラストラクチャの開発にも適用できます。 上記の課題に対処し、お客さまのニーズに応えるため、AWS は AWS Cloud WAN を使用した産業用資産向けの安全なグローバル OT/IT ネットワークの構築方法に関する ホワイトペーパー を公開しました。AWS Cloud WAN を使えば、データセンターやお客さま拠点、 Amazon Virtual Private Cloud (Amazon VPC) を簡単に接続し、仮想ネットワーク環境を完全に制御できます。AWS Cloud WAN では、お客様が選択したローカルネットワークプロバイダーを経由して AWS に接続し、中央集権型のダッシュボードとネットワークポリシーを使って、複数の拠点をさまざまな種類の方法で接続する統合ネットワークを作成できます。これにより、さまざまなテクノロジーを使用する異なるネットワークを個別に構成・管理する必要がなくなります。AWS Cloud WAN では、オンプレミスと AWS ネットワーク全体の健全性、セキュリティ、パフォーマンスを可視化できる包括的なビューが生成されます。 本ブログは、ソリューションアーキテクトの高橋が翻訳しました。原文は こちら です。 著者について Avneet Singh Avneet は Amazon Web Services のエネルギー分野における EMEA 地域のプリンシパルスペシャリストソリューションアーキテクトです。オランダのアムステルダムを拠点に、エネルギー業界向けの堅牢なクラウドネイティブソリューションの構築において AWS のリーダーシップ確立に責任を負っています。Avneet は公益事業会社で 15 年以上の経験があり、スマートメーター、請求、インボイス、規制コンプライアンスに至るメーターからキャッシュサイクル全体にわたる技術ソリューションプロジェクトに成功しています。Avneet は IoT、データ分析、再生可能エネルギーの最適化に強い関心を持っています。彼は「AWS上の再生可能エネルギーデータレイクおよび分析」ソリューションガイダンスの著者です。NAMER および EMEA、APJ 地域の世界中の再生可能エネルギー事業者と積極的に協力し、AWS クラウド上で次世代の再生可能エネルギーソリューションを開発しています。 Abhishek Naik Abhishek は AWS for Energy における電力・公益事業担当ソリューションアーキテクトグループを率いるシニアマネージャーです。15 年以上にわたりインフラストラクチャの設計・構築とプロダクトソリューションのリーディングを行ってきた経験があります。アビシェックは、テクノロジーを活用してお客さまの事業成果の加速と事業運営の脱炭素化をサポートしています。お客さまが AWS 上で成功を収められるよう、技術的なガイダンスと専門知識を提供し、設計からプロジェクト実装までをリードしています。仕事以外では、Abhishek はアウトドアでの活動を楽しんでいます。 Yashar Araghi Yashar は AWS のシニアソリューションアーキテクトです。20 年以上にわたり、インフラストラクチャとアプリケーションセキュリティソリューションの設計と構築の経験があります。政府、教育、金融、エネルギー・公益事業など、様々な業界のお客さまと協力してきました。AWS での過去 5 年間、ヤシャルはお客さまがセキュリティ、信頼性、パフォーマンス、コスト最適化されたクラウドソリューションを設計、構築、運用できるよう支援してきました。

この記事は、「 Iberdrola reduces incidents at power distribution facilities using AWS IoT and edge services 」を翻訳したものです。 Iberdrola は、発電、配電、商業化の分野でグローバルリーダーであり、風力発電と再生可能エネルギーの先駆者です。i-DE は Iberdrola のスペインとポルトガルの電力配電網を担当する部門で、様々な性質の数百万にわたる資産を管理・運用しており、各資産の健全性と全体の配電パフォーマンスとの相関関係を把握するのが難しい状況にあります。この記事では、i-DE のイノベーションチームが開発した資産管理プラットフォーム「SmartPoint」について説明します。SmartPoint は、電線支持塔/電柱、変電所、配電用変電所、送電線、現場作業員など、さまざまなコンポーネントの健全性をモニタリングするためのものです。 i-DE のビジネス課題 電力配電網を所有する i-DE は、以下のように様々な資産の種類を効率的に管理するための技術的ソリューションを導入するなかで、さまざまな課題に直面してきました。例えば以下のような課題があります。 変電所 は、電力システムの重要な構成要素であり、電圧を変換し、信頼性の高い電力供給を確保します。施設内の資産は屋外に曝されているため、物理的な脅威や異常を検出するためのビデオ分析が必要です。固定カメラで資産への画角を確保するには、多くの補助的なカメラが必要となりますが、死角はどうしても発生します。 配電用変電所 は、送電線から低電圧に変圧し、配電に適した電圧に変換する施設です。この種の設備では、煙、侵入、温度、浸水などの様々な環境変数を監視するために、従来のセンサーからのデータの監視を実装することがキーとなる要件となります。 送電線と配電線 は、電力を供給するための重要なインフラストラクチャです。これらには、火災を検出するためのビデオ分析と、植生に起因するリスクを検出するための衛星画像の活用が必要です。 電線支持塔と電柱 は、電線を保持し支える物理的な構造物です。これらの資産には、地滑りに起因する傾斜変化などのさまざまなパラメータを測定するための最新の IoT (モノのインターネット) センサーが組み込まれています。さらに、火災発生時の早期検知のため、IoT サーモカメラが配備されています。 現場作業員 は、電力網のインフラストラクチャの保守と修理を担当しています。現場作業の安全確保を目的として、SmartPoint では、転倒検知、ジオフェンシング、変電所内での位置制御、スマートキーなどのセンサーの使用が可能になります。 要約すると、i-DE は、このような多様な資産からデータを一元的に収集し、異常を検知し、インシデントを報告し、現場の作業員と協力して修復するためのプラットフォームを必要としています。 SmartPoint に求められる機能要件 i-DE は、従来のセンサーと最新の IoT センサーの両方に接続でき、ビデオから洞察を得て異常を検出し対応できるソリューションを探していました。Web アプリを通じて、Iberdrola 社の運用担当者は、変電所で発生するイベントについてアラートを受け取る必要があります。その一方で、プラットフォームは、イベントに関連するシステムのデータの相関分析、クロス分析を実施し、現場の運用担当者が問題を解決するためのインシデント報告レポートを提供します。 図 1. SmartPoint のアラートダッシュボード したがって、プラットフォームはデータを 2 つの異なる方法で表示する必要があります。1 つ目は、リアルタイムで発生するイベントのアラートという形式です。2 つ目は、資産の現在の状態を反映するためにオンデマンドで更新可能なチャートです。さらに、変電所のパフォーマンスに関しての KPI がありますが、これを分析・可視化するためには、設備の複数の要素間の相関関係を得る必要があります。 図 2. 視覚的な異常の検出 図 3. 勾配計のチャート これを実現するため、Iberdrola 社と AWS ソリューションアーキテクトは、以下の設計原則を定義しました デバイス接続の標準化とクロスプラットフォーム互換性 : 新しいユースケースはすべて、SmartPoint にシームレスに接続できる必要があります。そのため、SmartPoint は MQTT やその他の業界標準プロトコルのコネクタをサポートが求められ、Iberdrola 社は調達時に製造業者にリストを提示したり、機器開発チームと共有したりできます 目的別のデータリポジトリ : SmartPoint は、さまざまなプロトコルを使って変電所の制御システムとテレメトリシステムに接続し、データとイベントを、特定のデータ駆動型のユースケースに対応できる最適なクラウド上のデータリポジトリにルーティングする必要があります。IoT ユースケースのためのリアルタイムクエリ可能なデータベースと、ビジネスインテリジェンスやデータサイエンス目的でクエリ可能な中央データリポジトリが必要です。これらを適切に疎結合化することにより、プラットフォームはコスト効率よく分析ユースケースをサポートでき、必要な場合にのみ本番データベースを使用することで実行時のパフォーマンスを確保できます スケーラビリティ : AWS クラウド上でサーバーレスサービスのみを使用することで、市場投入までの期間短縮、運用負荷の軽減、プラットフォームの総コストの削減が可能になります。サーバーレスは、インフラストラクチャ管理の複雑さを排除しながら、重要な時にサービス品質を保証できるため、コスト効率の良いスケーリング戦略となります 直観性 : これにより、UX/UI チームは、デザインとユーザビリティのベストプラクティスに従って、バックエンドやデータチームから独立して作業を行うことができ、Iberdrola 社の運用担当者がプラットフォームの機能を最大限に活用できるようになります。SmartPoint のフロントエンドホスティングは、バックエンドインフラストラクチャから完全に分離されているため、フロントエンド開発者は、ユーザビリティをテストし、より直観的な体験に向けて自律的に変更を展開し、反復できます 拡張性と将来性 : このプラットフォームでは、デジタルツイン、VR/AR、生成 AI、BIM (ビルディングインフォメーションモデリング)、量子コンピューティングなどの新しいワークフローを簡単に統合し、有効化できる必要があります ソリューション概要 これらの設計原則を定義した上で、Iberdrola は SmartPoint を作成しました。これは AWS IoT スタックを使用して、さまざまなフィールド機器やセンサーに接続できます。次に、取り込まれたデータに基づいてリアルタイムで動作するためのストリーミング分析を適用し、さらなる分析のためにデータを目的別のデータリポジトリに永続化します。これにより、ビジネスインテリジェンスとデータサイエンス機能が可能になります。SmartPoint のデータパイプラインは、デバイスが追加され続ける中でシステムのスケーラビリティとパフォーマンスを保証するために、AWS サーバーレスサービスを使用しています。設置する機器の性質と数から、エッジコンピューティング機能を使用してセンサーからユニットデータを取得し、必要に応じて現場で判断を下します。これらのエッジゲートウェイは、northbound 方向(エッジからクラウドへ)のテレメトリ収集トラフィックと、southbound 方向(クラウドからエッジへ)のビジネスルール・更新プログラムなどの管理トラフィックの両方で SmartPoint との接続が必要です。 図 4. SmartPoint のアーキテクチャ プラットフォームのアーキテクチャは、すべてのタイプのアセットに対して同じ接続性とデータ処理パイプラインを使用するように設計されました。 MQTT 対応のセンサーが AWS IoT Core ブローカーにメッセージをパブリッシュするためのサブスクライブ MQTT をサポートしていないレガシーセンサーからの読み取りを行い、読み取り値をAWS IoT Core に注入してすべてのデバイスの統合ビューを作成するための、スケジューリングされた拡張可能な AWS Lambda にコーディングされた同期ロジック スタートアップパートナーの Star Robotics によって導入された、自律ロボット上で実行される機械学習ビデオ推論機能。この機能により、i-DE は異常を検出し、イベントを MQTT ブローカーにパブリッシュし、業界をリードする拡張性、データ可用性、セキュリティ、およびパフォーマンスを備えた AWS オブジェクトストレージサービスである Amazon Simple Storage Service (S3) にオブジェクト (画像とビデオ) をアップロードできます。デバイスソフトウェアの構築、デプロイ、および管理のためのオープンソースエッジランタイムとクラウドサービスである AWS IoT Greengrass が、Over-the-Air (OTA) デプロイメントと共に、ロボットのビデオ推論と自律ナビゲーションランタイムプロセスで使用されています。詳細は次のセクションを参照してください ルールにより、トピックメッセージを目的に合わせたデータ永続化サービスにルーティング 履歴ストレージ、分析、および、機械学習の適用のためのイベントの生データの S3 バケットへの保存機能 AWS Glue は生のイベントに対して Extract、Transform、Load (ETL) ジョブを実行し、 Amazon Athena でサーバーレスでクエリできるようにし、SQL アドホックで Amazon S3 に直接クエリできるようにし、 Amazon QuickSight BI ダッシュボードにデータを供給します。このスタックにより、複数のシステムの相関関係が確立され、配電設備全体のパフォーマンスのベンチマークが確立され、ビジネス意思決定をサポートします。さらに、これはリアルタイムな本番環境用途向けに、専用のトランザクションデータベースに影響を与えることなく行われます Amazon IoT Events は、プロセスとデバイスの状態を検出するために複数のソースからデータを取り込みます。これは、障害や運用の変更に対してアラームをトリガーし、運用のパフォーマンスと品質を可視化し、より長い時間ウィンドウ同士を相関させることで、より複雑なパターンを認識するために使用されます フロントエンドは Angular で構築され、S3 バケットにデプロイされ、 Amazon CloudFront のコンテンツ配信ネットワークを通して提供されます バックエンドはサーバーレスアプリケーションとして定義され、イベントがリアルタイムでユーザーアプリケーションで利用可能になるようにキーバリューペアデータベースである Amazon DynamoDB に永続化されます。また、低レイテンシーで SQL を使ってセンサーデータに対してローリングタイムウィンドウでクエリできるマネージド時系列データベースである Amazon Timestream にも永続化されます。バックエンドとやり取りする API は Amazon API Gateway によってサーバーレスでホストされ、セキュアな認証は Amazon Cognito によって有効化されています エッジでのビデオ推論 Star Robotics はスペインのスタートアップ企業で、さまざまな用途や業界向けにカスタマイズされたソリューションを構成するため、メカニクス、エレクトロニクス、自律ナビゲーション、人工知能 (AI) のモジュール技術を提供しています。SmartPoint は、Star Robotics によって可能になったインテリジェントな監視および詳細検査タスクの 2 段階検出ソリューションを使用しています。初期の推論段階では、Nvidia Edge ツールと AWS IoT Greengrass を Amazon SageMaker でクラウド上で学習されたモデルの OTA 配信と組み合わせており、完全に管理されたインフラストラクチャ、ツール、ワークフローを使用して ML モデルを構築、学習、デプロイするのに AWS サービスを利用しています。 このアプローチにより、ロボットに搭載された 360 度カメラモジュールからキャプチャされたデータに対する即時の推論が可能になり、迅速かつローカライズされた意思決定が保証されます。 図 5. ロボットを介した 360 度ビュー 異常が検出されると、アラートが生成され、AWS IoT Core を介してクラウドへ送信されます。そこで IoT ルールがメッセージを処理し、DynamoDB と Timestream に保存します。同時に、イベントが発生すると、PTZ カメラ (Pan-Tilt-Zoom、Pan: 左右方向にカメラレンズの向きを動かせる、Tilt: 上下方向にカメラレンズの向きを動かせる、Zoom: 映像をズームイン/ズームアウトできる) がターゲットを捉え、複数の画像を撮影し、S3 のメディア保存用バケットにアップロードします。クラウド上の 2 番目の推論段階がトリガーされ、結果がユーザーレビュー用のアプリケーションバックエンドに送信されます。 図 6. ロボットによる人物検知 このデュアル階層の推論パイプラインを実装することで、プラットフォームはエッジコンピューティングの俊敏性とクラウドベースの分析の深さの両方を確保しています。さらに、このアプローチにより、ユーザーフィードバックと以前のアラートからの誤検知 (False Positive) フィードバックを組み込んで、システムの精度を時間の経過とともに洗練させることができます。 結果と効果 SmartPoint をプロダクション環境に導入したことで、配送施設で報告された事故が 40 % 減少し、以下のカテゴリーで i-DE 事業運営に大きな影響がありました。 事故発生時の施設への移動回数が 50 % 減少 ジオフェンシング(特定エリアに仮想的な境界を作り、位置情報をもとに境界の出入りの際にアクションを実行する仕組みのこと)と位置情報追跡ソリューションを使用することで、危険エリアへの不正アクセスが 30 % 減少 スマートキーの導入により、施設への不正アクセスがほぼゼロに 現場のカメラやロボットを使った日常点検により、環境上の脅威を早期に検知できるようになり、主要変電所での熱故障が 50 % 減少 火災検知器、転倒検知器、その他のセンサーを導入したことで、緊急時の電力供給停止時間が短縮 追加リソース 詳細を知りたい場合は、 AWS Solutions for Energy をご覧いただき、運用上の優秀性と持続可能性の向上に役立ててください。また、 AWS IoT と Edge Computing を活用して、リアルタイムデータと予測分析を行うことができます。スマートでより効率的なエネルギー未来への第一歩を踏み出すには、 AWS Energy Experts にご連絡ください。 本ブログは、ソリューションアーキテクトの高橋が翻訳しました。原文は こちら です。 著者について Luis Conde Luis Conde は、2010 年から i-DE Grupo Iberdrola 社で IT 技術者として働いています。新しい技術が私たちの生活をどのように改善できるかを常に考えており、セキュリティを確保し、日常業務を簡単にすることを心がけています。2022 年からは、グローバル・スマート・グリッド・イノベーション・ハブのデジタル・ラボの責任者を務めており、VR/AR、IoT、ロボット工学などの新しい技術が扱われています。そこでは、i-DE の資産の全体像を把握するためにさまざまなセンサーやデータソースを1つのプラットフォームに統合する方法を検討するブレインストーミングセッションの結果、SmartPoint が生まれました。 Andrés Hernández Acevedo Andrés Hernández Acevedo – 2020 年から AWS スタートアップでソリューションアーキテクトとして活動しています。エッジコンピューティング、産業用 IoT、製造業、エネルギー、クリーンテックが専門です。彼の得意分野はイノベーションです。技術とインターネットビジネスモデルの両方において、スタートアップのエコシステムが最も好まれる場所です。Andrés は、「日々世界をよりよくすることこそが私たちのミッションだ」と、毎日の一歩一歩すべてで変化を生み出すことを夢見るチームの一員です。

本ブログは 2024 年 11 月 22 日に公開された Blog ”Improve your app authentication workflow with new Amazon Cognito features” を翻訳したものです。 Amazon Cognito は、10 年前に導入されたサービスで、Web およびモバイルアプリケーションにおける Customer Identity and Access Management(CIAM) の実装を支援します。Amazon Cognito は、お客様がアプリケーションにサインイン/サインアップ機能を素早く追加したり、認可のメカニズムで Machine-to-Machine 認証をセキュアに実現したり、 AWS リソースへのロールベースのアクセスを実現したりと、さまざまなユースケースで利用できます。 本日は、Amazon Cognito に対する一連の重要な更新をご紹介できることを喜ばしく思います。これらの機能強化により、より一層アプリケーションの柔軟性が高まり、セキュリティが向上し、ユーザーエクスペリエンスが改善されることを目指しています。 簡単にまとめると次のようになります: 人気のあるアプリケーションフレームワークとの統合をサポートを含む、開発者向けの新しいコンソール体験を通じてすぐに始めることができるようになりました Managed Login の導入 – Cognito が管理し、すぐに利用できる サインイン/サインアップページと、カスタマイズオプションのセットが刷新されました Amazon Cognito がパスワードレスログイン、パスキー認証をサポートするようになりました 価格体系の選択肢が充実しました: Lite、Essentials、Plus の各プランで、ユースケースに合わせて選択できます 新しくなった開発者向けのコンソール体験 Amazon Cognito は、クイックウィザードとユースケース別の推奨事項を備えたストリームラインされた開始体験を提供するようになりました。この新しいアプローチにより、設定を行い、エンドユーザーに到達するまでの時間が、これまでよりも速く効率的になります。 これは、アプリケーションをすばやく設定するための新しい Amazon Cognito フローです。3 ステップで開始できます: 構築する必要のあるアプリケーションタイプを選択してください アプリケーションタイプに応じて、サインインオプションを構成してください 手順に従って、サインインとサインアップページをアプリケーションと統合してください 次に、 作成 を選択します。 Amazon Cognito はアプリケーションと新しい ユーザープール (認証と認可のためのユーザーディレクトリ) を自動的に作成します。ここから、 ログインページを表示 を選択してサインインページを確認するか、アプリケーションのサンプルコードを使って始めることができます。さらに、Amazon Cognito は主要なアプリケーションフレームワークをサポートしており、標準の OpenID Connect (OIDC) と OAuth のオープンソースライブラリを使ってそれらを統合する詳細な手順を提供しています。 これがアプリケーションの新しい概要ダッシュボードです。ユーザープールダッシュボードでは、 概要 セクションに重要な情報が表示されるようになり、開発を進めるための一連の レコメンデーション も提供されるようになりました。 このページでは、 Managed Login 機能を使って、ユーザーのサインインとサインアップ体験をカスタマイズできます。これは次の新機能の概要を簡単に説明するのに適した導入になります。 Managed Login の導入 Managed Login の導入により、Amazon Cognito にカスタマイズの新しいレベルが加わりました。Managed Login は、企業のための可用性、スケーリング、セキュリティの重荷を肩代わりします。一度統合すれば、新しいセキュリティパッチや将来の機能強化を、さらなるコード変更なしで自動的に取り入れることができます。 この機能を使えば、エンドユーザー向けに、企業のアプリケーションとシームレスに統合された、パーソナライズされたサインアップおよびサインイン体験を作成できます。 Managed Login を使用する前に、ドメインを割り当てる必要があります。これには 2 つの方法があります。Amazon Cognito ドメインのランダムに生成されたサブドメインであるプレフィックスドメインを使用するか、ユーザーに馴染みのあるドメイン名を提供するために独自のカスタムドメインを使用します。 次に、 マネージドログイン または ホストされた UI (クラシック) のいずれかを選択して、 ブランディングバージョン を選択できます。 既存の Amazon Cognito ユーザーの方は、従来の Hosted UI 機能をご存知かもしれません。Managed Login は Hosted UI の改良版で、ユーザープールでのサインアップ、サインイン、さまざまな画面サイズに対応したレスポンシブデザイン、多要素認証、パスワードリセットの機能を備えた新しいウェブインターフェイスのコレクションを提供します。 Managed Login では、新しいブランディングデザイナー (Managed Login アセットとスタイルのノーコードビジュアルエディター) に加え、API 操作のセットを利用したプログラマブルな構成や、AWS CloudFormation による Infrastructure-as-code を介したデプロイを行うことができます。 ブランディングデザイナーを使えば、サインアップ、サインイン、パスワードリカバリー、多要素認証など、ユーザーの全体的な体験のルックアンドフィールをカスタマイズできます。この機能では、リアルタイムでプレビューを確認でき、さまざまな画面サイズやディスプレイモードでプレビューする便利なショートカットが用意されているので、本番環境に反映する前に確認できます。 Managed Login の詳細は、 Managed Login ドキュメント ページをご覧ください。 パスワードレスログインのサポート Managed Login 機能には、パスキー、メール OTP (ワンタイムパスワード)、SMS OTP を使ったサインインなど、パスワードレスの認証方式のための事前構築済みの統合機能も用意されています。パスキーのサポートにより、ユーザーはデバイスにセキュアに保存された暗号化キーを使って認証できるため、従来のパスワードよりも高いセキュリティが実現します。この機能により、WebAuthn 関連のプロトコルを理解・実装する必要なく、シームレスでセキュアな認証方式を導入できます。 従来のパスワードベースのサインインに関連する摩擦を減らすことで、この機能はユーザーのアプリケーションアクセスを簡素化しながら、高いセキュリティ基準を維持します。 パスワードレスログインのサポートの詳細は、 ユーザープールの認証フロー のドキュメントページをご覧ください。 価格体系の選択肢が充実: Lite、Essentials、Plus Amazon Cognito では、ユーザープールの新しい機能プランとして Lite、Essentials、Plus が導入されました。これらのプランは、お客様のさまざまなニーズとユースケースに対応するよう設計されています。Essentials が、お客様が新しくユーザープールを作成する際のデフォルトのプランとなります。この新しい体系により、アプリケーションの要件に最適なオプションを選択でき、必要に応じてプランを切り替えることができるようになりました。 現在のプランを確認するには、アプリケーションダッシュボードから 機能プラン を選択するか、ナビゲーションメニューから 設定 を選択してください。 このページでは、各プランの詳細情報を確認でき、プランのダウングレードまたはアップグレードを選択できます。 各層の概要は次のとおりです: Lite プラン: ユーザー登録、パスワードベースの認証、ソーシャルアイデンティティプロバイダーの統合などの既存の機能がこのプランにパッケージ化されています。既存の Amazon Cognito ユーザーの方は、ユーザープールに変更を加えることなく、これらの機能を引き続き利用できます。 Essentials プラン: 包括的な認証とアクセス制御機能を提供し、数分でアプリケーションに安全でスケーラブルなカスタマイズ可能なサインアップとサインイン体験を実装できます。Lite の全機能に加え、Managed Login とパスキー、メール、SMS を使ったパスワードレスログインのサポート、アクセストークンのカスタマイズ、パスワードの再利用禁止などの機能が含まれます。 Plus プラン: Essentials プランに基づき、高度なセキュリティニーズに対応します。Essentials の全機能に加え、不審なログイン活動に対する脅威保護、侵害された資格情報の検出、リスクベースのアダプティブ認証、脅威分析のためのユーザー認証イベントログの出力などの機能が含まれます。 Lite、Essentials、Plus の各プランの価格は、月間アクティブユーザー数に基づいています。現在 Amazon Cognito の高度なセキュリティ機能(ASF: Advanced Security Feature)を利用しているお客様は、Plus プランをご検討ください。Plus プランには、すべての高度なセキュリティ機能、パスワードレス認証などの追加機能が含まれており、単独の高度なセキュリティ機能を利用する場合と比べて最大 60% のコスト削減が可能です。 これらの新しい価格体系について学びたい場合は、 Amazon Cognito 料金 ページを参照してください。 知っておく必要があること 利用可能なリージョン – Essentials および Plus プランは、 Amazon Cognito が利用可能なすべての AWS リージョン で利用できます (AWS GovCloud (US) リージョンを除く)。 Lite および Essentials プランの無料利用枠 – Lite および Essentials プランのお客様は、自動的に期限が切れることのない毎月の無料利用枠を利用できます。これは、既存および新規の AWS のお客様に対して無期限で利用可能です。無料利用枠の詳細については、 Amazon Cognito 料金 ページをご覧ください。 既存のお客様向けの拡張価格特典 – お客様は、高度なセキュリティ機能 (ASF) を備えていない既存アカウントのユーザープールを Essentials にアップグレードし、2025 年 11 月 30 日まで今までの Cognito ユーザープールと同じ価格で利用できます。対象となるには、2024 年 11 月 22 日午前 10 時 (太平洋標準時) までの過去 12 か月間に、少なくとも 1 人の月間アクティブユーザー (MAU) がアカウントに存在する必要があります。これらのお客様は、2025 年 11 月 30 日までの間、それらのアカウントで Essentials レベルの新しいユーザープールを Cognito ユーザープールと同じ価格で作成することもできます。 これらの更新により、Amazon Cognito を使用して、アプリケーション向けのセキュリティ、スケーラビリティ、カスタマイズ性に優れた認証ソリューションを実装できます。 Happy building, — Donnie Donnie Prakoso Donnie Prakoso は、AWS のソフトウェアエンジニア、自称バリスタ、プリンシパルデベロッパーアドボケイトです。電気通信、銀行からスタートアップまで、テクノロジー業界で 17 年以上の経験があります。彼は現在、開発者がさまざまなテクノロジーを理解し、アイデアを実行に移すのを支援することに注力しています。彼はコーヒーが大好きで、マイクロサービスから AI/ML まで、あらゆるトピックについてのディスカッションが大好きです。 本ブログは Sr. Security Solutions Architect の勝原 達也が翻訳しました。

本ブログは株式会社シスラボ様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの上野です。 生成 AI の活用シーンが急激に増えてきており、今この瞬間に時代が変化しているのだと感じる毎日です。生成 AI の活用例としては、社内情報を活用したチャットボットや、長い文章や議事録などを要約させるといったお話をよく耳にするかと思います。一方で、Web 上で情報を検索して集めた情報をまとめるという活用例についてはいかがでしょうか。複数の情報を検索することに加えて、全ての情報を整理して見やすい形にまとめるというのは非常に時間がかかる業務かと思います。 本記事では、株式会社シスラボ様が Amazon Bedrock を活用して構築した Marketing AI によって市場調査・分析業務を効率化した事例についてご紹介します。 お客様の状況とサービス構築に至る背景 シスラボ様は、IT ソリューションの企画・立案からシステム導入後のアフターサポートまでを一貫して提供していらっしゃいます。そんなシスラボ様の営業チームでは、新サービスの企画をいくつかのステップで進めていくのですが、最初のステップである市場調査・分析に時間がかかるという課題がありました。具体的には、競合サービスの Web サイトを一つ一つ検索、情報の整理、比較表の作成などの業務に約 2 時間がかかる状況でした。 そこで、Amazon Bedrock を活用し、市場調査・分析業務を効率化するサービスを開発することになりました。 お客様が開発された “Marketing AI” について シスラボ様は、Amazon Bedrock 上で Anthropic 社の Claude モデルを利用するとともに、 Amazon Bedrock Agents を活用し、キーワードを指定するだけで、競合比較表を作成できるサービス “Marketing AI” を開発されました。サービスの軸となっているのはユーザーが入力したキーワードに応じて Web 上の情報を検索し、結果に基づいて回答を生成する機能で、 Amazon Bedrock Agents 及び AWS Lambda が利用されています。 ここで少しだけ生成 AI における Agent について補足をします。Agent は目的達成に向けて必要なタスクを分割し、タスクごとに適切な手段（API など）を呼び出すことで目的を達成しようとします。タスクを実行するための手段（API など）は事前に用意をしておく必要があり、今回のシスラボ様のケースでは、キーワードで Web 検索をして情報を取得する API を AWS Lambda で実装されています。この API を Amazon Bedrock Agents に手段として認識させているため、必要に応じて Web 検索が行えるようになっています。 現時点のシスラボ様の Marketing AI の構成では Web 検索機能のみが用意されている状況ではありますが、Agent を介してタスクを実行させている点が特徴的であり、今後、実現したいことが複雑化してきた際には、手段（API）を増やすことで、Agent に適宜必要な手段を使い分けさせることができる作りになっています。 出力については、営業チームが見やすいように比較表形式にしており、こちらはプロンプトエンジニアリングによって実現されています。よくある出力例としては、シンプルな文章や箇条書きでの要約などがありますが、プロンプト次第で比較表形式でも出力できることがわかる例となっております。開発初期段階では、会話形式で生成 AI と複数回やりとりすることで、比較表形式の結果が出てくる状態だったものの、プロンプトを工夫することで一度のリクエストで比較表形式が出力されるように改善されたとのことです。以下は出力例になりますが、キーワードを入力するだけで、製品ごとの特長や値段が比較表形式で出力されるため、市場調査・分析業務を効率化できることがお分かりいただけるのではないでしょうか。 導入効果 シスラボ様は、約 1 カ月間でサービスを構築されました。体制としてはわずか 3 名で、開発の中心となったのは入社 2 年目のエンジニアの方となります。サービスを利用することで、企画ごとに約 2 時間かかっていた業務が、98.3 % 減の 2 分に短縮することに成功しています。 Web 上の情報を調べて整理するという業務と生成 AI の相性が良いことがよくわかる結果だと思います。また今回は市場調査・分析業務というユースケースでしたが、Web 上の情報検索と情報整理の組み合わせは他のユースケースにも応用しやすいのではないでしょうか。 まとめ 今回は、株式会社シスラボ様の AWS 生成 AI 事例「新サービス企画における市場調査・分析業務を効率化する Marketing AI の開発」についてご紹介いたしました。シスラボ様の今後の展望としては、Marketing AI を正式な自社サービスとして展開していくことと、キーワードやリクエスト内容に応じた適切な検索ワードの設定や任意の出力形式を選択できるなどの機能強化を行うことです。 シスラボ様の事例は Agent を活用したケースということで、必要に応じて Web 上の情報を検索するなど、手段の使い分けを生成 AI 側にまかせたいユースケースをお持ちの方には、ご参考になるのではないでしょうか。 株式会社シスラボ：営業本部 ソリューション営業部 1 課 課長 濱井 啓介 様（右から 2 番目）、営業本部 ソリューション営業部 1 課 課員 佐藤 晃 様（左から 2 番目） Amazon Web Services Japan：アカウントマネージャー 北舘 もも子（左端）、ソリューションアーキテクト 上野 涼平（右端） ソリューションアーキテクト 上野 涼平

Amazon Connect は、あらゆる規模の企業が低コストで優れたカスタマーサービスを提供できる、使いやすいクラウドコンタクトセンターです。今回、構築の簡素化、生成 AI の活用、使いやすいオブザーバビリティなどの新機能が追加され、顧客向けの効果的なセルフサービス体験を作成、管理、最適化することがこれまで以上に容易になりました。 セルフサービスのカスタマーサポート は、企業にとって重要な要素となっています。24 時間 365 日のサポート提供を可能にし、問い合わせ件数を削減し、人間のエージェントが複雑な問題に集中できるようにすることで、顧客満足度と運用効率の向上を実現します。Amazon Connect の新機能は、セルフサービス体験の作成と管理の合理化、変更実装にかかる時間の短縮、包括的な分析による性能の最適化など、主要な課題を単一のアプリケーションで解決します。 本ブログでは、これらの最新機能について詳しく説明し、セルフサービス体験の向上、バーチャルアシスタントの効率的な作成方法、そしてアプリケーション内での分析機能の改善について解説していきます。 Amazon Connect でバーチャルアシスタントを容易に作成 コンタクトセンター管理者は、 Amazon Connect 内で数回クリックするだけでセルフサービス体験を構築、編集、管理できるようになりました。 この機能を通じて、アシスタントが理解できる言語、サポートする問題の種類（インテントとも呼ばれます）、顧客がどのようにインテントを伝えるか（発話とも呼ばれます）、そしてチャットボットや音声ボットが問題に対処するために何を行うか、何を言うかを定義することができます。 バーチャルアシスタントが作成または変更されると、コンタクトセンター管理者はバージョンを作成し、フロー内で使用するエイリアスに割り当てることができます。コンタクトセンターの管理者は Amazon Connect 内の深い会話分析を使用して、顧客がバーチャルアシスタントとどのように関わっているかを理解し、将来の改善に活かすことができます。 生成 AI によるセルフサービスの強化 Amazon Q in Connect は、エージェント支援とセルフサービスを強化する強力な生成 AI 機能の両方を提供します。Amazon Q in Connect は、リアルタイムの補助や推奨アクションを通じてエージェントのサービス提供を支援するだけでなく、 自動化されたセルフサービスを通じて顧客が直接問題を解決できるようサポートします 。 Amazon Connect フローとの統合により、Amazon Q in Connect は音声とチャットの両チャネルでリアルタイムに顧客とコミュニケーションを取ることができます。ナレッジベースから情報提供を行うだけでなく、注文状況の確認、返品の処理、アカウント情報の更新など、顧客に代わってアクションを実行することも可能です。この会話型 AI と自動化されたアクションの組み合わせにより、エージェントの介入なしでより複雑な顧客ニーズに対応できる包括的なセルフサービス体験を実現します。また、追加サポートが必要な場合は、会話の文脈を保持したままスムーズにカスタマーサービスエージェントへ引き継ぐことができ、一貫した顧客体験を提供します。 それでは、Amazon Q in Connect を使用してAmazon Connect のセルフサービス体験を改善する方法を見ていきましょう。 1) Q in Connect による既存体験の強化 Amazon Q in Connect は、ナレッジベースのコンテンツと顧客情報から、より自然で文脈に即した応答を提供することで、既存のセルフサービス体験を強化できます。ボット用の個別の応答テンプレートを維持する代わりに、エージェントが使用するのと同じナレッジベースのコンテンツを活用して、顧客の問い合わせに適切な応答を生成することができます。これにより、セルフサービスとエージェント支援の両チャネルで一貫性を確保しながら、複数のコンテンツソースを管理する負担を軽減できます。 2) プロンプトのカスタマイズによるアシスタントの振る舞い定義とパーソナライゼーションの強化 Amazon Q in Connect のプロンプトカスタマイズ機能を使用すると、バーチャルアシスタントの顧客とのコミュニケーション方法を微調整できます。これには、トーン、言語の複雑さ、ブランドボイスの調整が含まれ、インタラクションが企業の価値観と顧客の期待に沿ったものになるようにします。また、顧客データを活用してより関連性の高いパーソナライズされた応答を提供することも可能です。この機能により、自社の公開 Web サイトをクロールするなどのセルフサービス応答用のナレッジコンテンツと、組織内の SharePoint リポジトリを活用するなどのエージェント支援用のナレッジコンテンツを分けることができます。 3) ガードレールによるワークロードの保護 安全で適切なセルフサービスのインタラクションを確保するため、 Amazon Q in Connect では、ユースケースと責任ある AI ポリシーに基づいてセーフガードを実装するための AI ガードレールをネイティブに設定できます 。これらの企業固有のガードレールにより、Amazon Q in Connect は有害で不適切な応答をフィルタリングし、機密性の高い個人情報を編集し、大規模言語モデル（LLM）のハルシネーションによる誤った情報を制限することができます。 エンドカスタマーのセルフサービスシナリオでは、ガードレールを使用して Amazon Q in Connect の応答を企業関連のトピックに限定し、プロフェッショナルなコミュニケーション基準を維持することができます。また、エージェントが顧客の問題解決に Amazon Q in Connect を活用する際、これらのガードレールによってエージェントへの個人識別情報（PII）の偶発的な露出を防ぐことができます。 オブザーバビリティ、監査性、分析の改善 コンタクトセンターにとって、顧客体験の継続的な向上とセルフサービス率、ボットとの対話時間、適切なエージェントへの初回ルーティング率などの重要業績評価指標（KPI）の最適化は非常に重要です。2024 年 12 月 2 日、Amazon Connect で、エンドツーエンドの自動音声応答（IVR）録音機能と組み込みのセルフサービス分析機能を提供開始しました。これにより、顧客がボットとどのように関わっているかについて、集計レベルと個別の会話の両方で貴重な洞察を得ることができ、今後の顧客体験戦略の改善に活用できます。 1) IVR 録音 お客様は、エージェントと顧客の会話を録音する際に使用するのと同じフローブロック設定を使用して、 自動化されたインタラクションの録音を取得できるようになりました 。自動化されたインタラクションの録音音声は、エージェントと顧客の録音で現在実現されている信頼性と同じで、堅牢なセキュリティとガバナンスコントロールの対象となります。これには、きめ細かなユーザーアクセス制御、お客様所有の S3 バケットへの保存、デフォルト設定としてのエンドツーエンドの暗号化が含まれ、貴重なデータの最高レベルの保護を確保します。 自動化された顧客とのインタラクションが録音されると、音声録音とその文字起こしは問い合わせレコードにシームレスに統合されます。これは、コンタクトセンター管理者が現在顧客とエージェントの録音にアクセスしているのと同じです。この統合により、管理者は自動化されたインタラクションを含むすべてのインタラクションを包括的に把握でき、価値のある通話洞察も得られます。文字起こし機能の追加により、完全な音声録音を聴く必要なく、会話のフローと顧客体験を簡単に分析できる、自動化されたインタラクションの迅速で効率的なレビューが可能になります。 2) Amazon Connect でのセルフサービス分析 Amazon Connect の分析ダッシュボードは、 セルフサービスのインタラクションに関する包括的な洞察を提供し 、組織が顧客のエンゲージメントパターンを深く理解できるようにします。直感的なコンソールインターフェイスを通じて、コンタクトセンター管理者はセルフサービスのパフォーマンス指標を監視し、顧客のインタラクションパスを分析し、詳細な個別の問い合わせレコードを調査することができます。 ダッシュボードのボットエイリアスとバージョンによるフィルタリング機能により、A/B テストとパフォーマンス測定が容易になり、組織はセルフサービス体験を最適化するためのデータドリブンな意思決定を行うことができます。自動化されたインタラクションに関するこの詳細な可視性は、企業が顧客体験戦略を継続的に改善し、セルフサービスの効果を向上させるのに役立ちます。 結論 Amazon Connect のこれらの機能強化により、顧客向けのセルフサービス体験を簡素化し改善する方法が大きく進歩しました。Amazon Connect に直接統合されシンプルになった構築機能、Amazon Q in Connect を通じて強化された生成 AI 機能、そして改善された分析と録音機能により、組織は顧客セルフサービスソリューションを効果的に作成、管理、最適化することができます。お客様はこれらの機能を活用して、セルフサービスのパフォーマンスを向上させ、最終的に時間を節約し、全体的なコンタクトセンターのコストを削減することができます。 — 翻訳はソリューションアーキテクト 新谷 が担当しました。原文は こちら です。

Amazon は、 AWS Education Equity Initiative の一環として、Amazon とパートナーが長年にわたって行ってきた取り組みを基に、最大で 1 億ドルのクラウドテクノロジーと技術リソースを投入して、既存の専任学習組織が新しく革新的なデジタル学習ソリューションを開発することで、より多くの学習者にリーチできるようにしています。 これまでの仕事 AWS と Amazon は長年にわたり、学習と教育に取り組んできました。以下は、私たちがすでに行ったことのサンプルです。 AWS AI & ML 奨学金プログラム – このプログラムは、約 6000 人の学生に 2,800 万ドルの奨学金を授与しました。 機械学習大学 – MLU は、コミュニティカレッジや歴史的に黒人の多い大学（HBCU）がデータ管理、人工知能、機械学習の概念を教えるのに役立つ無料のプログラムを提供しています。このプログラムは、これまでテクノロジー分野で十分な教育を受けておらず、過小評価されてきた学生を支援することにより、機会のギャップを解消することを目的としています。 Amazon フューチャーエンジニア – 2021 年以降、このプログラムを通じて 1150 人の学生に最大 4,600 万ドルの奨学金が授与されています。過去1年間で、210 万人以上の学生が、このプログラムやその他の米国 Amazon 慈善教育プログラムを通じて、1,700 万時間を超える STEM 教育、リテラシー、キャリア探索コースを受講しました。昨年、そのようなセッションで話をすることができましたが、素晴らしい経験でした。 無料のクラウドトレーニング – 2020 年後半に、2025 年までに 2,900 万人が無料のクラウドコンピューティングトレーニングを通じて技術スキルの向上を支援するという目標を設定しました。私たちは一生懸命働き、その目標を1年前に達成しました！ やるべきことはまだまだある このような努力と進歩にもかかわらず、やるべきことはまだまだあります。未来は間違いなく均等に分散されていません。今日、5 億人以上の学生にデジタル学習では連絡が取れません。 生成 AI は、社会志向の教育技術組織、非営利団体、政府がすでに行っている優れた取り組みをさらに発展させることができると私たちは信じています。私たちの目標は、学習者が新しい革新的なデジタル学習システムを構築できるようにすることです。これにより、学習者は業務を拡大し、より多くの対象者にリーチできるようになります。 AWS Education Equity Initiative の立ち上げにより、次世代のテクノロジーパイオニアたちが強力なツールを構築し、基盤モデルを大規模にトレーニングし、AI を活用したティーチングアシスタントを作成できるよう支援したいと考えています。 今後5年間で、最大 1 億ドルのクラウドテクノロジーと包括的な技術アドバイスを提供する予定です。受賞者は、学習管理システム、モバイルアプリ、チャットボット、その他のデジタル学習ツールを構築および拡張できるように、AWS のサービスと技術的な専門知識のポートフォリオを利用できるようになります。申請プロセスの一環として、申請者は、提案したソリューションが、十分なサービスを受けていない地域社会や過小評価されているコミュニティの学生にどのように役立つかを示すよう求められます。 先に述べたように、私たちのパートナーはすでにこの分野で多くの素晴らしい仕事をしています。例: Code.org はすでに AWS を使用して、無料のコンピュータサイエンスカリキュラムを 100 か国以上の数百万人の学生に拡大しています。この取り組みにより、 Amazon Bedrock の活用範囲が広がり、学生プロジェクトの自動評価が可能になり、教育者の時間が解放され、その時間を個別の指導や学習に充てることができます。 ロケットラーニング は、インドの幼児教育に焦点を当てています。彼らは Amazon Q を QuickSight で使用して、300 万人以上の子供たちの学習成果を向上させる予定です。 この取り組みにとても興奮しています。次世代のテクノロジーパイオニアの育成と教育にどのように役立つかを楽しみにしています。 – Jeff ; 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週開催の AWS re:Invent 2024 では新サービス発表やさまざまなブレイクアウトセッションをお届けしましたが、楽しんでいただけたでしょうか？新機能・新サービスについては、先週の 週刊AWS でまとめていますので、まだの方はぜひご覧ください。 また、 AWS re:Invent 2024 の内容をジャンル別に日本語で解説する re:Invent Recap を順次開催していきますので、こちらもぜひご参加ください。まずはキーノートの内容を90分で振り返るオンラインセミナーを今週開催します。下記の日時で同じ内容を3回実施しますので、ご都合の良い日時にご参加ください。 – AWS re:Invent Recap – Keynote 編 > 2024 年 12 月 17 日（火）10:00-11:30 > 2024 年 12 月 19 日（木）14:00-15:30 > 2024 年 12 月 20 日（金）19:00-20:30 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年12月9日週の主要なアップデート 12/9(月) Introducing Amazon EC2 High Memory U7i Instances with 6TiB and 8TiB of memory – AWS Amazon EC2 U7i ファミリーに新しく U7i-6tb(6TiBメモリ) と U7i-8tb(8TiBメモリ) の2つのインスタンスが追加されました。第4世代インテル Xeon スケーラブルプロセッサーを搭載しており、旧世代の EC2 U-1 インスタンスと比較して、パフォーマンスが最大 35% 向上し、価格性能比が最大 15% 向上します。 12/10(火) Amazon Bedrock Guardrails reduces pricing by up to 85% – AWS Amazon Bedrock Guardrails は価格が、最大で85%引き下げされました。Bedrock Guardrailsは自社のポリシーに基づいて、例えば望ましくないコンテンツをフィルタリングしたり、個人情報 を排除したりといった、生成AIアプリケーションの実行を制御するための機能です。Bedrock Guardrailsの概要については Preview発表時のこちらのブログをご覧ください 。 Amazon RDS for SQL Server Supports new custom parameters for native backup and restore – AWS Amazon RDS for SQL Server では、新しいカスタムパラメータを使用してバックアップとリストア時により詳細に制御できるようになりました。新たに追加されたのは、BLOCKSIZE、MAXTRANSFERSIZE、BUFFERCOUNTパラメーターで、これらを調整することで、性能の改善やバックアップデータの互換性を高めることが可能です。 Amazon Simple Email Services (SES) announces Deterministic Easy DKIM – AWS Amazon Simple Email Services (SES) は、Deterministic Easy DKIM (DEED) の提供を開始しました。これは DomainKeys Identified Mail (DKIM) 管理を簡単に利用できるようにする新しい方法です。既存の Easy DKIMでは、IDが検証されたリージョンでDNSルックアップを行う必要がありましたが、DEEDはそれを拡張し、リージョンごとにDNS設定を変更せずに複数のリージョンで同じIDを使用できるようにするものです。 Amazon MQ now supports AWS PrivateLink – AWS Amazon MQ で AWS PrivateLink (インターフェイス VPC エンドポイント) が利用可能になりました。これにより、インターネットゲートウェイを持たないVPC内から、Amazon MQ API に直接接続できるようになります。 12/11(水) Amazon Lex launches new multilingual speech recognition models – AWS AIチャットボットを構築するためのサービス、 Amazon Lex で新しい多言語ストリーミング音声認識モデル (ASR-2.0) が利用可能になりました。新たに、ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語、スペイン語をサポートするヨーロッパベースのモデルと、中国語、韓国語、日本語をサポートするアジア太平洋ベースのモデルという2つの特化したモデルが用意され、より高い認識精度を提供します。特に英数字の音声認識に優れているため、たとえば、アカウント番号やシリアル番号といった内容を認識する際に有用です。 Amazon EC2 R8g instances now available in AWS Asia Pacific (Tokyo) – AWS Amazon EC2 R8g インスタンスが東京リージョンで利用可能になりました。AWS Graviton4 プロセッサを搭載しており、AWS Graviton3 ベースのインスタンスと比較してパフォーマンスが最大 30% 向上しています。R8gの詳細については こちらのブログ をご覧ください。 Amazon SageMaker AI announces availability of P5e and G6e instances for Inference – AWS Amazon SageMaker AI で、機械学習の推論に最適化された G6e インスタンス (NVIDIA L40S Tensor Core GPUを搭載) と P5e (NVIDIA H200 Tensor Core GPUを搭載) が利用可能になりました。現在、米国東部 (オハイオ) と米国西部 (オレゴン)リージョン の SageMaker AIで使用できます。利用には AWS Service Quota から利用制限の引き上げ申請が必要です。 AWS Security Hub now supports PCI DSS v4.0.1 standard – AWS AWS Security Hub は、PCI DSS v4.0.1 に準拠した自動セキュリティチェックをサポートするようになりました。PCI DSSは、クレジットカードの情報を安全に取り扱うための一連の規則とガイドラインを提供するコンプライアンスフレームワークです。今回の機能追加でPCI DSS 要件を継続的にチェックする 144 個の自動コントロールが提供されるようになりました。 12/12(木) Amazon EC2 F2 instances, featuring up to 8 FPGAs, are generally available – AWS 最大 8つの FPGA を搭載する Amazon EC2 F2 インスタンスが利用可能になりました。現在、米国東部 (バージニア北部) とヨーロッパ (ロンドン) リージョンで利用可能です。F2 インスタンスは第2世代の FPGA搭載インスタンスです。詳細は こちらのブログ をご覧ください。 AWS Toolkit for Visual Studio Code now includes Amazon CloudWatch Logs Live Tail – AWS AWS Toolkit for Visual Studio Code に Amazon CloudWatch Logs Live Tail の連携機能が追加されました。CloudWatch Logs Live Tailは、ほぼリアルタイムでログを表示し、フィルタリングやハイライト機能で分析を容易にするための機能です。CloudWatch Logs Live Trailの概要については こちらのブログ をご覧ください。 12/13(金) AWS announces new AWS Direct Connect location in Osaka, Japan – AWS 専用線サービス AWS Direct Connect のロケーション(接続口)が、新たに大阪の TELEHOUSE データセンターで提供されるようになりました。大阪ではEquinixデータセンターに続いて2つ目、日本全体では5つ目のロケーションです。 ロケーション一覧 はこちらに情報があります。 Amazon Redshift supports auto and incremental refresh of Materialized Views for zero-ETL integrations – AWS Amazon Redshift でZero-ETL統合で連携した表からマテリアライズドビュー (MV) の差分更新(incremental refresh)に対応しました。これによりMVの更新にかかる時間やコストが最小化されます。差分更新できるMVの定義など注意点については、 こちらのドキュメントをご覧ください 。 Amazon EC2 instances support bandwidth configurations for VPC and EBS – AWS Amazon EC2 C8g, M8g, R8g, X8g インスタンスで利用可能な、インスタンス帯域幅構成（Instance Bandwidth Configurations – IBC）が利用可能になりました。多くのEC2インスタンスはEBSとの通信とVPCへの通信とで2つのネットワーク帯域を持っていますが、これを最大25%の幅で調整して融通可能にするものです。たとえば VPCへの帯域幅を増やすと、その分EBSで利用できる帯域幅が減少します。これにより、ニーズに合わせた柔軟な帯域調整が可能になります。詳細は こちらのドキュメント をご覧ください。 AWS Resource Explorer supports 59 new resource types – AWS AWS Resource Explorer で、新たに 59 種類のリソースタイプをサポートするようになりました。これには Amazon EKS や、Amazon Kendra等が含まれます。AWS Resource Explorer は自分がもつAWS内のリソースを検索・検出するためのサービスです。 私（下佐粉）が週刊AWSを執筆するのはこれが最後です。現在の形で週刊AWSを開始したのは、 2019年5月21日 で、小林と私の2名で書きはじめたのですが、その後メンバーが増え、現在は週刊AWSが(私を除いて)4名、週刊生成AI with AWSが2名の体制で執筆しています。 長く執筆をつづけてきたことで、「週刊AWS、読んでますよ」とお声をかけていただく事も多く、執筆の励みになっていました。改めてお礼申し上げます。 これからも週刊AWSをよろしくお願いいたします。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。