このブログは 2024 年 1 月 29 日に Ron Kolwitz (Senior Solutions Architect)、Robert Fountain (Sr. EUC Specialist Solutions Architect)、Roy Tokeshi (EUC Specialist Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 お客様は Amazon AppStream 2.0 を使用して、仮想化されたデスクトップとアプリケーションのフリートをエンドカスタマーにデプロイし、無数の永続的なストレージソリューションをサポートします。AppStream 2.0 は組織のユーザに複数の一般的なストレージオプションですぐに使用できる機能を提供します。例えば Amazon Simple Storage Service (S3) 、 Amazon WorkDocs 、Google Drive for G Suite、OneDrive for Business などです。これらのストレージソリューションで動作する場合、AppStream 2.0 はユーザーセッションの開始時にファイルをダウンロードし、セッションの終了時にストレージプロバイダーと同期します。これらのサービスはほとんどのデスクトップワークロードに最適化されており、典型的なシステム要件に対するデファクトのアプローチとなっています。 AppStream 2.0 のお客様の中には、大規模なデータセット、数百から数百万のファイル、バックエンドストレージプロバイダーとの継続的な同期など、強化されたストレージ機能を必要とする厳しい要求をお持ちのお客様もいます。たとえば、AppStream 2.0 フリートインスタンスで作業する大規模な開発チームは、大規模なソフトウェアアプリケーションを構築するために、数千のファイルを共同でコンパイルする必要がある場合があります。このようなユースケースでは、マネージドストレージオプションである Amazon FSx ファミリーなどの AWS ストレージサービスとフリートを統合できます。たとえば、 FSx for ONTAP と組み合わせると、VPC 内で実行されるカスタマイズ可能な IOPS、スループット、キャッシュ機能を備えた独自の NetApp ONTAP ストレージ機能を活用する堅牢なソリューションをフリートに提供できます。マネージドサービスである Amazon FSx は、可用性や耐久性、パッチ適用、可視性を維持し、お客様をご自身のストレージソリューションの管理から解放します。 このブログでは、高性能なストレージを提供するストレージ共有ドライブとして Amazon FSx ファミリーを使用し Amazon AppStream 2.0 Linux ベースのフリートをデプロイする方法を紹介します。このソリューションは、AWS ネットワークバックボーンで提供されるキャッシュ、パフォーマンス、拡張可能なストレージすべての機能を管理する Amazon FSx を必要とするチームに役立ちます。Windows ベースのユーザーに対しては、同様の Windows ソリューションをセットアップする方法として 以前のブログ がございます。 読了までの時間 10 分 完了までの時間 30 分 学習レベル 上級 (300) 完了までの費用 (推定) 割り当てられた FSx ストレージと最新のフリートを設定するための AppStream 2.0 イメージビルダーインスタンスの利用時間に対してのみ料金が発生します。詳細については、 Amazon AppStream 2.0 の料金 と Amazon FSx for NetApp ONTAP の料金 を参照してください。 利用したサービス Amazon AppStream 2.0 Amazon FSx for NetApp ONTAP 前提条件 次の前提条件が必要です。 AWS アカウント 必要な権限を持つ AWS IAM ロールとポリシー 2 つ以上のプライベートサブネットを持つ Amazon Virtual Private Cloud (VPC) AppStream 2.0 フリート、スタック、イメージビルダー – セットアップの詳細については Amazon AppStream 2.0 の開始方法 を参照してください。 Amazon FSx for NetApp ONTAP ファイルシステム – セットアップの詳細については Amazon FSx for NetApp ONTAP の開始方法 を参照してください。新しいファイルシステムの FSxN の共有ポイントを書き留めます。 例: <<svm>>.<<fileshare>>.fsx.<<region>>.com:/<<volume>> ソリューションの概要 Amazon AppStream 2.0 を Amazon FSx ストレージと一緒に使用するには、セッション開始時に FSx ストレージをマウントするようにイメージビルダーを設定する必要があります。このアプローチは、ホームフォルダーあるいは共通のファイル共有としてユーザーごとにストレージをマウントするために使用できます。 次の図は、さまざまな AppStream 2.0 および Amazon FSx for NetApp ONTAP コンポーネントとそのデプロイメントを示しています。 実装 カスタムイメージを作成するには、まずイメージビルダーインスタンスを作成します。 AppStream 2.0 管理コンソール AppStream 2.0 管理コンソールから、 Images を選択します。 Image builder タブを選択し、 Launch image builder を選択します。 フィルターを使用して利用可能な Linux イメージを検索し、Linux イメージを選択します。 イメージの名前を入力し、利用可能なインスタンスタイプを選択します。この例では、IAM ロールと VPC エンドポイントのセクションはそのままにしておきます。 Next を選択します。 VPC、利用可能なサブネット、セキュリティグループを選択します。注意: VPC セキュリティグループは、Amazon FSx ファイルシステムへのアクセスを許可する必要があります。 Launch Image builder を選択します。 次のオプションは、Amazon AppStream 2.0 Linux ベースのフリートと FSx for ONTAP 永続ストレージを組み合わせる方法を示しています。 オプション 1 ) すべてのユーザーに対するホームフォルダードライブの提供 Amazon FSx を使用して、ユーザーごとにアタッチされたフォルダーを提供することができます。このデータは、ネットワークファイルシステム (NFS) プロトコルを使用してマウントされ、ユーザーの AppStream 2.0 インスタンスに直接接続され、継続的に同期されたネットワークストレージを提供します。 手順 AppStream 2.0 管理コンソール から、 Images を選択します。 Image builder タブを選択し、Image builder の横にあるラジオボタンを選択して、 Connect を選択します。 以前にメモした FSx 共有ボリュームを使用して、FSx ファイルシステムをイメージビルダーインスタンスにマウントし、各ユーザーのディレクトリを構築します。 sudo mkdir /fsx sudo mount -t nfs "<<svm>>.<<fileshare>>.fsx.<<region>>.amazonaws.com:/<<volume>>" /fsx # repeat below for each user sudo mkdir /fsx/<<username>> sudo chown 1002:1004 /fsx/<<username>> 起動時にマウントスクリプトを実行するには、SessionStart の executables セクションにある /opt/appstream/SessionScripts/config.json にエントリを挿入して更新します。 {    "SessionStart": {     "executables": [            …,            {                     "Context": "system",                     "Filename": "/opt/appstream/SessionScripts/system-start-fsx-user.sh",                     "Arguments": "",                     "S3LogEnabled": true             }     ],     "waitingTime": 60   },   … } ユーザーごとの FSx 共有をマウントするため、 /opt/appstream/SessionScripts/system-start-fsx-user.sh に新しいマウントスクリプトファイルを作成します。NFS_SHARE 変数を、以前にメモした FSx 共有に更新します。このスクリプトは、 appstream_user_sh 環境変数の $AppStream_UserName を自動的に追加し、ボリューム上の Linux ユーザーのマウントディレクトリのみを一意にマウントします。 #!/bin/bash NFS_SHARE="<<svm>>.<<fileshare>>.fsx.<<region>>.amazonaws.com:/<<volume>>" HOMEFOLDER_BASE="$HOME/MyFiles/HomeFolder" # Load the appstream user variables if [ -f /etc/profile.d/appstream_user_vars.sh ]; then . /etc/profile.d/appstream_user_vars.sh fi  # Mount FSX Storage for user session, create new directory if HomeFolder already exists (e.g. if S3 storage is already mounted) INDEX=”” while [ -d "$HOMEFOLDER_BASE$INDEX" ]; do   ((INDEX++)) done HOMEFOLDER="$HOMEFOLDER_BASE$INDEX" mkdir "$HOMEFOLDER" chown as2-streaming-user:as2-streaming-user "$HOMEFOLDER" sudo mount -t nfs "$NFS_SHARE/$AppStream_UserName" "$HOMEFOLDER" スクリプトファイルの権限を実行可能に変更します。 sudo chmod 755 /opt/appstream/SessionScripts/system-start-fsx-user.sh イメージアシスタントを起動して新しいイメージを作成します。 新しく作成されたイメージを使用して AppStream 2.0 フリートを更新します。フリートを停止して起動します。 AppStream 2.0 ユーザーセッションを起動します。S3 または同様のバックアップストレージをオフにするまで FSx ネットワークストレージはユーザーの MyFiles/HomeFolder2 ディレクトリに表示されるため、チームは必要に応じて FSx ストレージにファイルを移行できます。必要ならば以前のストレージをオフにすることができ、その場合 FSx ストレージは MyFiles/HomeFolder として表示されます。希望する場合、FSx と AppStream 2.0 組み込みストレージメソッドの両方を共存させることができます。 オプション 2 ) ユーザー間のファイル共有の提供 FSx を使用すると、すべてのユーザーで必要な共通ファイルで共同作業するために組織内のユーザーに共有フォルダーの場所を提供できます。プロセスはオプション 1 と似ていますが、すべてのフリートユーザーインスタンス間で共通のポイントにマウントされ、共有されます。 手順 AppStream 2.0 管理コンソール から、 Images を選択します。 Image builder タブを選択し、Image builder の横にあるラジオボタンを選択して、 Connect を選択します。 FSx 共有ボリュームを使用して FSx ファイルシステムをイメージビルダーインスタンスにマウントし、共有利用のための共通ディレクトリを構築します。 sudo mkdir /fsx sudo mount -t nfs "<<svm>>.<<fileshare>>.fsx.<<region>>.amazonaws.com:/<<volume" /fsx sudo mkdir /fsx/common sudo chown 1002:1004 /fsx/common 起動時にマウントスクリプトを実行するには、SessionStart の executables セクションにある /opt/appstream/SessionScripts/config.json にエントリを挿入して更新します。 { "SessionStart": {     "executables": [            …,            {                     "Context": "system",                     "Filename": "/opt/appstream/SessionScripts/system-start-fsx-common.sh",                     "Arguments": "",                     "S3LogEnabled": true             }     ],     "waitingTime": 60   },   … } ユーザー間で共通の共有フォルダーをマウントするには、 /opt/appstream/SessionScripts/system-start-fsx-common.sh の新しいマウントスクリプトファイルを作成します。NFS_SHARE 変数を、以前にメモした FSx 共有で更新します。 #!/bin/bash NFS_SHARE="<<svm>>.<<fileshare>>.fsx.<<region>>.amazonaws.com:/<<volume>>/common" COMMONFOLDER_BASE="/fsx/common" # Mount FSX Storage for common storage sudo mount -t nfs "$NFS_SHARE" "$COMMONFOLDER_BASE" ファイルの権限を実行可能に変更します。 sudo chmod 755 /opt/appstream/SessionScripts/system-start-fsx-common.sh イメージアシスタントを起動して新しいイメージを作成します。 新しく作成されたイメージを使用して AppStream 2.0 フリートを更新します。 フリートを停止および起動します。 AppStream 2.0 ユーザーセッションを起動します。Amazon FSx 共有ストレージが表示され、ユーザーは /fsx/common の下でデータを共有できるようになります。 クリーンアップ AWS アカウントで継続的な課金が発生しないようにするには、新しく作成されたすべての AWS リソースを削除します。 AWS マネジメントコンソール にログインして、フリート、イメージビルダー、FSx ファイルシステムなど、このデプロイメントの一部として作成した可能性のあるリソースを削除します。イメージの削除については、 AppStream 2.0 管理者ガイド を参照してください。FSx ストレージの削除については、 FSx for ONTAP ユーザーガイドの入門 リソースのクリーンアップ を参照してください。 まとめ Amazon AppStream 2.0 と Amazon FSx を使用すると、数千から数百万のファイルを継続的に同期する高性能ストレージのユースケースに対応できる仮想化デスクトップを構築できます。この例は、強化されたストレージ機能を必要とするハイエンドの共同開発でお客様にご利用いただいています。 適切な FSx ストレージ サービスの選択に関する詳細については、 Amazon FSx ファイルシステムの選択 の概要を参照してください。 高度なパフォーマンスチューニングの詳細については、 Amazon FSx for NetApp ONTAP パフォーマンス を参照してください。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Cloud Support Engineer の戸松が担当しました。 Ron Kolwitz は、米国連邦政府科学部門の顧客をサポートするシニアソリューションアーキテクトです。顧客と連携して、エンタープライズクラウドの導入と戦略に関する技術ガイダンスを提供し、適切に設計されたソリューションの構築を支援しています。特に航空宇宙と量子ベースのコンピューティングに熱心に取り組んでいます。余暇には、水上スキー愛好家の家族と過ごすのが好きで、大自然を楽しんでいる姿をよく見かけます。 Roy Tokeshi は、IT コンサルティング、教育、アーキテクチャ設計の分野で 25 年以上の経験を持つ、熟練した技術愛好家です。彼の技術に対する愛情は、新しいトレンドの探求と包括的なコミュニティの構築に注力していることを示しています。彼は複雑な概念を簡素化し、すべての専門家が技術を利用できるようにします。Roy は、AWS サービス、CNC、レーザー彫刻機、IoT を使用して作成および構築することを楽しんでいます。チェスは下手ですが、あらゆる年齢や職業の人々に、ボード上やオンラインでチェスをプレイするよう勧めるのが大好きです。 Robert Fountain は、ペンシルバニア州を拠点とするシニア EUC スペシャリストソリューションアーキテクトです。Robert は 2020 年から AWS に勤務しており、現在 6 つの AWS 認定を取得しています。オフィスの外では、Robert はナショナル・スキー・パトロールのメンバーであり、妻と 2 人の息子、そして愛犬の Daisy と一緒に過ごすことを楽しんでいます。    

オランダの私が住んでいる地域ではまだまだ冬が続いており、まれに顔をのぞかせる太陽の光はまたとない贈り物になります。この週末は、そのようなすばらしい時間を体験できました。静かな運河に沿ってサイクリングしていると、オランダの典型的な曇り空から金色の光が差し込み、完璧な静けさと安らぎを感じるひとときを生み出してくれました。ヨーロッパのこの地域では太陽の光がほとんど差さない 1 月にこのような輝きを垣間見ることは、とりわけ特別に感じます。2025 年のお正月気分も過ぎた新年の第 3 週目は、振り返りと前進する意気の両方をもたらします。テクノロジーの進歩をめぐってグローバルな会話が飛び交っていますが、このようなちょっとした個人的な瞬間は、急速に進化する世界の中で立ち止まり、ささやかな喜びに感謝することを思い出させてくれます。 では、1 月 13 日週の新しい発表を見てみましょう。 1 月 13 日週のリリース 私が注目したリリースをいくつかご紹介します。 AWS メキシコ (中部) リージョン – 2024 年 2 月にメキシコのインフラストラクチャを拡大する計画を発表した AWS は、3 つのアベイラビリティーゾーンを備え、API コードを mx-central-1 とする AWS メキシコ (中部) リージョンの提供を開始しました。このリージョンはメキシコ初の AWS インフラストラクチャリージョンとなり、中南米における AWS の存在感をさらに高めます。ローカルワークロード管理、データストレージ機能、低レイテンシーでのパフォーマンス向上、強固なセキュリティ標準を提供するこの新しいリージョンは、専用プロセッサを用いた最先端の人工知能と機械学習 (AI/ML) 機能、143 のセキュリティ標準とコンプライアンス認証をサポートする包括的なセキュリティ機能など、高度なクラウドテクノロジーを備えています。このリージョンの提供開始に伴い、AWS の規模は 36 の地理的リージョン内の 114 のアベイラビリティーゾーンに拡大されました。 AWS マネジメントコンソールが複数の AWS アカウントへの同時サインインのサポートを開始 – AWS マネジメントコンソール にあるマルチセッション機能を使用することで、複数の AWS アカウントにサインインし、単一のブラウザでリソースを管理できるようになりました。最大 5 つのセッションにサインインでき、異なるアカウント内、または同じアカウント内にあるルート、 AWS Identity and Access Management (IAM) 、フェデレーションロールの任意の組み合わせにすることが可能です。アプリケーションは、AWS のベストプラクティスガイドラインに従って、複数のアカウントを用いてスケールできます。アプリケーション問題やその他のアプリケーション関連のジョブをトラブルシューティングするために、開発、テスト、本番環境などのさまざまな環境のアカウントを使用して、複数のアカウント全体のリソース設定とステータスを比較することができます。 Amazon EC2 Flex インスタンスに新しいより大きなサイズを導入 – Amazon Elastic Compute Cloud (Amazon EC2) Flex (C7i-flex および M7i-flex) インスタンスでの 2 つの新しいより大きなサイズ (12xlarge および 16xlarge) の一般提供が発表されました。新しいサイズは EC2 Flex ポートフォリオを拡大し、既存のワークロードをスケールアップしたり、追加のメモリを必要とするより大規模なアプリケーションを実行したりするための追加のコンピューティングオプションを提供します。これらのインスタンスには、AWS でしか利用できないカスタム第 4 世代 Intel Xeon Scalable プロセッサが搭載されており、他のクラウドプロバイダーが使用する同等の x86 ベースの Intel プロセッサよりも最大 15% 優れたパフォーマンスを提供します。Flex インスタンスは、コンピューティング集約型ワークロードと汎用ワークロードの大多数でコストパフォーマンスのメリットと低料金を実現するための最も簡単な方法です。同等の前世代インスタンスよりも最大 19% 優れたコストパフォーマンスを提供し、コンピューティングリソースを完全に活用しないアプリケーションには最優先の優れた選択肢になります。Flex インスタンスは、ウェブサーバーやアプリケーションサーバー、バッチ処理、エンタープライズアプリケーション、データベースなどに最適です。さらに大きなインスタンスサイズ (最大 192 個の vCPU と 768 GiB のメモリ) や、継続的な高 CPU 使用率を必要とするコンピューティング集約型ワークロードと汎用ワークロードには、Amazon EC2 C7i および M7i の各インスタンスを使用できます。 AWS CloudFormation での AWS User Notifications の一般提供を発表 – AWS User Notifications は、AWS マネジメントコンソールの通知センター、E メール、 AWS Chatbot 、またはモバイルプッシュ通知を使用して AWS コンソールモバイルアプリ に送信される通知を設定し、 Amazon CloudWatch アラーム などの重要なイベントを常に把握しておくために使用できます。この機能を使用すると、Infrastructure-as-Code (IaC) プラクティスの一環として通知設定を定義して、 AWS CloudFormation テンプレート内で特定のリソースタイプに対する通知設定を指定することができます。例えば、 Amazon EC2 Auto Scaling グループがスケールアウトしたとき、 Elastic Load Balancing (ELB) ロードバランサーがプロビジョニングされたとき、または Amazon Relational Database Service (Amazon RDS) データベースが変更されたときにトリガーされる通知を設定できます。どのイベントが通知をトリガーし、誰が通知を受け取るのかをきめ細かく制御できます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 AWS 欧州 (ストックホルム) での Amazon EC2 M8g インスタンスの提供開始 – これらのインスタンスは、Graviton3 ベースの Amazon M7g インスタンスよりも最大 3 倍多い vCPU とメモリを用いたより大きなインスタンスサイズを提供します。AWS Graviton3 プロセッサと比較して、AWS Graviton4 プロセッサはデータベースで最大 40%、ウェブアプリケーションで最大 30%、大規模な Java アプリケーションで最大 45% 高速です。 AWS がメキシコのケレタロでの新たな AWS Direct Connect ロケーションと拡大を発表 – Direct Connect サービスは、AWS とデータセンター、オフィス、またはコロケーション環境の間に物理的なプライベートネットワーク接続を確立するために役立ちます。これらのプライベート接続は、パブリックインターネット経由での接続よりも安定性に優れたネットワークエクスペリエンスを提供できます。 AWS GovCloud (米国西部) リージョンでの Amazon EC2 C7i-flex インスタンスの提供開始 – EC2 Flex インスタンスのポートフォリオを拡大するこれらのインスタンスは、コンピューティング集約型ワークロードの大多数でコストパフォーマンスのメリットを実現するための最も簡単な方法を提供します。 AWS Backup が AWS GovCloud (米国) リージョンで組織全体のレポートのサポートを開始 – AWS Backup Audit Manager を使用して、データ保護ポリシーに関する集約的なクロスアカウントレポートとクロスリージョンレポートを生成し、バックアップアクティビティとリカバリアクティビティに関する運用データを取得できます。 アジアパシフィック (香港) リージョンでの Amazon OpenSearch Serverless の提供開始 – OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションで、複雑なインフラストラクチャ管理を必要とすることなく、検索と分析のワークロードを簡単に実行できます。 アジアパシフィック (タイ) リージョン での AWS Backup の提供開始 – AWS Backup を使用することで、アプリケーションデータのバックアップの作成と管理、イミュータブルなリカバリポイントとボールトを用いた不注意によるアクションまたは悪意のあるアクションからのデータの保護、およびデータ損失インシデントが発生した場合におけるデータの復元を一元的に実行できます。 アジアパシフィック (マレーシア) リージョンでの Amazon GuardDuty の提供開始 – この追加のリージョンを使用して、異常な動作、セキュリティ脅威、AWS アカウントをターゲットとした高度なマルチステージ攻撃シーケンスを継続的に監視して検出し、AWS アカウント、ワークロード、データの保護を支援できるようになりました。 追加リージョンでの Amazon EC2 R8g インスタンスの提供開始 – Amazon EC2 R8g インスタンスは、データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析などのメモリ集約型ワークロードに最適です。 欧州 (フランクフルト) での Amazon EC2 I8g の提供開始 – I8g インスタンスは、ストレージ集約型ワークロードに対し、Amazon EC2 で最も優れたパフォーマンスを提供します。 5 つの追加 AWS リージョンでの Amazon S3 Tables の提供開始 – Amazon S3 Tables は、Apache Iceberg サポートが組み込まれた初のクラウドオブジェクトストアと、表形式データを大規模に保存するための最も簡単な手段を提供します。S3 Tables は特に分析ワークロード向けに最適化されているため、継続的なテーブル最適化による非マネージド型 Iceberg テーブルよりも最大 3 倍速いクエリパフォーマンス、汎用 S3 バケットに保存されている Iceberg テーブルよりも最大 10 倍多い 1 秒あたりのトランザクション数を実現します。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。公式 AWS Summit ウェブサイト にアクセスして最新情報を入手し、お住まいの地域内で行われるイベントの登録開始時を把握するための通知にサインアップしましょう。 コラボレーションスペースで、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日中に開催されるすべての AWS 主催の対面およびバーチャルイベント は、こちらで閲覧できます。 1 月 20 日週のニュースは以上です。1 月 27 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

このブログは 2025 年 1 月 15 日に Steve de Vera（AWS Customer Incident Response Team）と Jennifer Paz（AWS Customer Incident Response Team）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 2025 年 1 月 17 日: 本投稿で詳解されている不正な方法のリスクを軽減するために、一時的な認証情報を使用することの重要性を強調するために、原文は更新されました。 Amazon Web Services（AWS） では、お客様のデータセキュリティが最優先事項であり、今後もそれは変わりません。 AWS Customer Incident Response Team（CIRT） と当社の自動セキュリティ監視システムは、最近 Amazon Simple Storage Service（Amazon S3） バケットに関連する異常な暗号化アクティビティの増加を確認しました。 これらの行為は AWS サービス内の脆弱性を悪用するものではありません。権限のないユーザーが、意図しない方法で利用できる有効な認証情報を用いたものであることを認識する必要があります。これらの行為は 責任共有モデル のお客様範囲で発生しますが、AWS では、お客様がこのようなアクティビティの影響を防止または軽減できる手順を推奨します。 私たちのセキュリティチームは、お客様と協力しながらカスタマー提供キーを使用した サーバーサイド暗号化（SSE-C） と呼ばれる暗号化方式を使用した、Amazon S3 におけるデータ暗号化イベントの増加を検出しました。これは多くのお客様が使用している機能ですが、SSE-C を使用した多数の S3 CopyObject コマンドによってオブジェクトが上書きされ、新しい暗号化キーでお客様データを再暗号化するというパターンを私たちは検出しました。私たちの分析により、これはお客様の有効な認証情報を入手し、それを使用してオブジェクトを再暗号化した悪意のある人物によって実行されていたことが判明しました。 アクティブディフェンスツール を使用して、多くのケースにおけるこの種の不正なアクティビティを防止することに役立つ自動緩和策を実装しました。これらの緩和策により、お客様が保護措置を行わない場合でも、すでに高い確率で防止に成功しています。ただし、攻撃者は有効な認証情報を使用しており、AWS が正常なアクティビティと悪意のあるアクティビティを明確に区別することは困難です。したがって、リスクを軽減するためにベストプラクティスに従うことを推奨します。 SSE-C の不正使用を防ぐために、次の 4 つのセキュリティのベストプラクティスを実装することをお勧めします: 一時的な認証情報を利用する データ復旧手順を実装する AWS リソースの予期しないアクセスパターンを監視する アプリケーションで必要な場合を除き、SSE-C の使用をブロックする 1. 一時的な認証情報を利用する 上述したアクティビティでは SSE-C 暗号化が使用されていますが、この行為と多くのセキュリティイベントの根本的な原因は、長期的なアクセスキーの侵害にあります。認証情報の侵害リスクを軽減する最も効果的な方法は、そもそも長期的な認証情報を作成しないことです。存在しない認証情報は公開または盗難されることはありません。また、AWS は、ソースコードまたは設定ファイルに認証情報を保存しないで済むような豊富な機能を提供しています。 AWS IAM ロール を利用することで、アプリケーションは、一時的な認証情報を使用して、 Amazon Elastic Compute Cloud（Amazon EC2） インスタンス、 Amazon Elastic Container Service（Amazon ECS） または Amazon Elastic Kubernetes Service（Amazon EKS） コンテナ、AWS Lambda 関数からの署名された API リクエストを安全に実行できます。AWS クラウドの外部システムにおいても、 AWS IAM Roles Anywhere を使用することで、長期的な AWS 認証情報がなくとも認証された API リクエストを実行できます。さらに、 AWS IAM Identity Center を使用すると、開発者は多要素認証（MFA）によって保護された長期的なユーザー ID に裏付けられた一時的な認証情報を取得できます。 これらの技術はすべて AWS Security Token Service（AWS STS） を利用し、アプリケーション内のコードまたは設定ファイルで長期的な AWS セキュリティ認証情報を配布または埋め込むことなく、AWS リソースへのアクセスを制御できる一時的なセキュリティ認証情報を発行します。 2. データ復旧手順を実装する データ保護メカニズムが整備されていない場合、データの復旧に時間がかかる可能性があります。データ保護のベストプラクティスとして、データが上書きされないように保護し、重要なデータのセカンダリコピーを保持することをお勧めします。 Amazon S3 で バージョニング を有効にすると、バケット内のオブジェクトの複数のバージョンが保持され、誤って削除または上書きされたオブジェクトを復元できます。特にバケット内のオブジェクトを頻繁に上書きするアプリケーションの場合には、バージョニングによってストレージコストが増加する可能性があることに注意する必要があります。この場合、古いバージョンを管理し、ストレージコストを制御するために Amazon S3 Lifecycle ポリシー を実装することを検討してください。 さらに、重要なデータを別のバケットにコピーしたり、バックアップを作成することもできます。また、別の AWS アカウントや AWS リージョンにコピーすることもできます。この場合、Amazon S3 の レプリケーション機能 を使用してバケット間でオブジェクトを自動的にコピーします。これらのバケットは、同じ AWS アカウントまたは別の AWS アカウント、同じ AWS リージョンまたは別の AWS リージョンでも可能です。Amazon S3 におけるレプリケーションでは、より厳格な目標復旧時点（RPO）と目標復旧時間（RTO）を持つお客様向けに SLA を提供しています。また、Amazon S3 バケットの定期的なバックアップを自動化するマネージドサービス AWS Backup for Amazon S3 を使用することもできます。 3. AWS リソースの予期しないアクセスパターンを監視する 監視を行わない場合、Amazon S3 バケットに対する不正なアクティビティに気付かない可能性があります。 AWS CloudTrail や Amazon S3 サーバーアクセスログ などのツールを使用して、データへのアクセスを監視することをお勧めします。 AWS CloudTrail を使用すると、Amazon S3 を含めた AWS リソース全体のイベントをログに記録したり、ログを 1 つのアカウントに統合して、セキュリティチームがアクセスして監視するなどのことが実現できます。また、 特定の Amazon S3 メトリクス またはログに基づいて Amazon CloudWatch アラーム を作成し、異常なアクティビティを警告することもできます。これらのアラートは、異常な動作を迅速に特定するのに役立ちます。 Amazon EventBridge と AWS Lambda を使用した是正措置の自動化も設定することができます。組織全体のすべてのバケットをスキャンし、 Amazon S3 ブロックパブリックアクセス を適用するために使用できる実装例もあります。また、 この記事 では、オブジェクトのアップロードの暗号化方法をリアルタイムで監査する方法が説明されています。 4. アプリケーションで必要な場合を除き、SSE-C の使用をブロックする アプリケーションが暗号化する際に SSE-C を使用していない場合は、Amazon S3 バケットのリソースポリシー、または AWS Organizations 内の組織に適用された Resource Control Policy（RCP）を使用して、SSE-C の使用をブロックできます。 Amazon S3 バケットのリソースポリシーは一般的にバケットポリシーと呼ばれ、お客様が個々の Amazon S3 バケットのアクセス許可を制御できるようにします。バケットポリシーは、S3 PutBucketPolicy API コール、AWS Command Line Interface（CLI）、または AWS マネジメントコンソールを使用して適用できます。バケットポリシーの仕組みの詳細については、 Amazon S3 のドキュメント を参照してください。次の例は、 <your-bucket-name> というバケットに対する SSE-C リクエストをブロックするバケットポリシーを示しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictSSECObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3::: <your-bucket-name> /*", "Condition": { "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "false" } } } ] } RCP を使用すると、AWS Organizations 内の組織全体のリソースに適用される、アクセス許可の最大範囲をお客様が指定できます。RCP は、AWS Organizations UpdatePolicy API コール、AWS CLI、または AWS マネジメントコンソールを使用して適用できます。RCP の仕組みの詳細については、 AWS Organizations のドキュメント を参照してください。次の例は、組織内のバケットに対する SSE-C リクエストをブロックする RCP を示しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictSSECObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "*", "Condition": { "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "false" } } } ] } まとめ AWS 環境に対する一般的な攻撃から利用者の貴重なデータを守るために実行できる最も価値があり、本質的なことは、長期的な認証情報（アクセスキー/シークレットキー）の使用を控えるまたは最小限に抑えることです。その後、すべてのプリンシパルの権限を必要最小限に抑えるようにします（いわゆる「最小権限」分析）。さらに、このブログで説明した特定の攻撃パターンについては、最も一般的な指標を強調して示しました。お客様のセキュリティチームが環境を常に保護するために取り組んでいる間、AWS の多くのチーム （ AWS CIRT 、Amazon の脅威インテリジェンス、 Amazon S3 チームなどのサービスチームなど）が、貴重なデータを保護するために革新、コラボレーション、インサイトの共有に熱心に取り組んでいることを知っておいてください。 この投稿では、お客様のデータに対する最近の脅威に関する最新情報を提供し、紛失または盗難された AWS 認証情報を使用して SSE-C でデータを暗号化する悪意のあるユーザーのリスクから、お客様を保護するために使用できる 4 つのセキュリティのベストプラクティスを紹介しました。 攻撃者の戦術が進化しても、お客様のセキュリティに対する私たちの取り組みは揺るぎません。私たちは協力して、より安全なクラウド環境を構築し、お客様が自信を持って革新できるようにしています。 不正なアクティビティが疑われる場合は、すぐに AWS サポート にご連絡ください。 Steve de Vera Steve は、脅威の調査と脅威インテリジェンスに重点を置く AWS CIRT のマネージャーです。アメリカンスタイルのバーベキューに情熱を傾けており、バーベキュー競技会の認定審査員でもあります。Brisket という名前の犬を飼っています。 Jennifer Paz Jennifer は 10 年以上の経験を持つセキュリティエンジニアで、現在は AWS CIRT に所属しています。Jennifer は、お客様のセキュリティ課題への取り組みを支援し、複雑なソリューションを実装してセキュリティ体制を強化することに喜びを感じています。休暇には、熱心にウォーキング、ジョギング、ピックルボール、旅行、グルメに取り組み、常に新しい料理の冒険を追い求めています。

この記事は Getting started with Amazon Q Developer operational investigations （記事公開日：2024 年 12 月 21 日）を翻訳したものです。翻訳はデベロッパーアドボケイトの山口が担当しました。 このブログポストでは、AWS上の 運用調査のために Amazon Q Developer を使用する クイックスタートをご紹介します。この強力なAI支援トラブルシューティングツールをセットアップするためのステップバイステップのプロセスを説明します。ユーザー権限の設定、データアクセスの管理、暗号化の設定、そして最初の調査の開始方法について説明します。また、このブログでは、この新機能がどのように機能するかのセルフペースデモもご紹介します。 Amazon Q Developer の運用調査機能とはなにか 先日、この新機能の詳細を説明する 包括的なブログ記事 を公開しました。Amazon Q の運用調査機能は、生成AI技術の力を活用し、関連情報を浮き彫りにすることで、インシデントの迅速な調査と解決を支援します。Amazon Q は、メトリクス、ログ、トレース、デプロイメントイベント、およびその他のデータをスキャンして、根本原因の仮説と実用的な洞察を生成します。 はじめ方 CloudWatch コンソール https://console.aws.amazon.com/cloudwatch/ を開く 左側のナビゲーションペインでAIオペレーション、調査の順で選択する Configure for this accountを選択します。(注意: Investigation group を作成して Amazon Q Developer の運用調査を設定するには、 AIOpsConsoleAdminPolicy または AdministratorAccess IAMポリシーのいずれかがアタッチされているIAMプリンシパル、または同様の権限を持つアカウントにサインインする必要があります。調査グループの設定により、調査の共通プロパティを一元管理できます。） 調査の保持期間を選択します。デフォルトは90日です。 オプションで暗号化設定をカスタマイズすることができます。たとえば、AWSが提供するデフォルトの鍵ではなく、カスタマーが管理する鍵を使用したい場合などです。詳細については、 調査データの暗号化を 参照してください。 Create investigation group の画面で保持期間と高度な暗号化を設定できます (オプション) Getting startedウィザードのUser accessセクションは、Amazon Q Developer の運用調査機能とやり取りするさまざまなユーザーロールに適切な権限を設定する方法を理解するのに役立ちます。(スクリーンショット内のリンク先には詳細な情報が記載されたドキュメントがあります。) AWSは3つのマネージドIAMポリシーを提供しています。管理者用の AIOpsConsoleAdminPolicy 、調査の開始と管理が必要なユーザー用の AIOpsOperatorAccess 、情報の閲覧のみが必要なユーザー用の AIOpsReadOnlyAccess です。 User access画面では Amazon Q Developer Investigations assistant の IAM パーミッションをユーザーに与える方法を説明しています オプションで、Amazon Q Developer の運用調査機能を IAM Identity Center に接続できます。IAM Identity Center と統合することで、調査フィードに追加された提案を個々のユーザーに帰属させることができます。詳細については、このリンクを参照してください。 IAM Identity Center を設定し、提案がユーザーに適切に帰属するようにするための Identity aware console session の画面 “Next“を押して次に進みます “Investigation configuration” セクションでは、Q Developer が調査のためにテレメトリーデータにアクセスするために使用する IAM ロールを設定できます。”Auto-create”を選択します。これにより、必要な権限を持つ新しいロールが作成されます。 Amazon Q Developer の権限を設定する Investigation configuration の画面 Enhanced integration のセクションでは、Amazon Q Developer の調査実行をさらに支援する追加オプションを設定できます。次のステップでは、これらのオプションの機能について簡単に説明します。 Tags for application boundary detection : このセクションでは、アプリケーションで使用する既存のカスタムタグキーを指定できます。これらのタグは、Amazon Q Developer がリソースの関係を検出する際に検索を絞り込むのに役立ちます。詳細は こちら をご覧ください。 Enhanced ingetrations の画面。アプリケーションの境界を識別するためのタグを設定できます。 CloudTrail for change event detection のセクションでは、Amazon Q Developer が CloudTrail データにアクセスし、システム変更の分析と根本原因の仮説を改善できます。 CloudTrail for change event detection の画面 X-Ray for topology mapping と Application Signals for health assessment のセクションでは、Amazon Q Developer の機能を強化することができる追加のAWSサービスを紹介しています。 X-Ray と Application Signals のための追加の統合に関する画面 ”Next“を押して次へ進みます ウィザードの最後のセクションでは、サードパーティの統合を設定できます。これらには、チケットシステム、チャットとの統合、SNSが含まれます。本記事ではこれらについて詳しく説明しません。しかし、より詳細な情報を求めている場合は、 こちらのリンク をご覧ください。 “Complete setup”を選択して設定を開始します。数秒後、”Initial Setup success” の確認メッセージが表示されます。 次のステップ Amazon Q Developer の運用調査機能は、厳格なセキュリティ管理を維持しながら、インシデントレスポンスを加速させる強力な方法を提供します。セキュリティ体制をさらに強化するためには以下も実施してみてください。 ドキュメント の参照 必要に応じたIAMロールとIAMポリシー の調整 必要であればカスタマーのマネージドキーでの 暗号化の設定 設定が正しく動作しているかの検証のために テストの調査 を実施 Amazon Q Developer をあなたのAI搭載アシスタントにすることで、データとシステムを安全に保ちながら、AWSの問題をこれまで以上に迅速に解決できるようになります。セキュリティを優先して実装することで、システムとデータの完全性と機密性を維持しながら、その強力なAI機能を自信を持って活用できます。このバランスの取れたアプローチにより、セキュリティのベストプラクティスを妥協することなく、インシデントレスポンスとトラブルシューティングのプロセスを加速できます。 この機能を実際にご覧になるには、 インタラクティブデモ をご覧ください。 著者について Andres Silva Andres Silva は、Amazon Web Services（AWS）のグローバルクラウドオペレーション＆オブザーバビリティリーダー兼プリンシパルスペシャリストソリューションアーキテクトとして、企業のクラウド運用の変革を支援しています。AWSでの約10年を含む30年以上の技術経験を持ち、DevOps、クラウド技術、SaaSインフラ管理を専門としています。ノースカロライナ州ハイポイントを拠点に、オブザーバビリティ、AIOps、ガバナンスを中心に、企業全体のクラウド運用戦略を推進しています。AIを活用したインテリジェントなクラウドオペレーションフレームワークを構築・導入し、卓越した運用と自動化されたインシデント対応を大規模に実現するため、グローバル企業と提携しています。

このブログは 2023 年 2 月 6 日に Megan O’Neil (Principal Specialist Solutions Architect)、Karthik Ram (Senior Solutions Architect)、Kyle Dickinson (Sr. Security Solution Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェアによる被害は過去数年で大幅に増加し、世界中から注目を集めています。従来のランサムウェアは、主にサーバーやデータベース、共有ファイルシステムなどのインフラストラクチャリソースに影響を与えていました。しかし、 Amazon Simple Storage Service (Amazon S3) に保存されたデータを標的とするような、あまり馴染みのない事案もあります。ランサムウェア攻撃を未然に防ぎ、そして早期に特定して復旧対処できるように実施すべき重要な対策があります。このブログのゴールは、ランサムウェアから保護するために使用できる AWS のサービスと機能について学び、攻撃が発生した場合の調査方法を理解していただくことです。 ランサムウェア は、悪意のある攻撃者が組織から金銭を要求するために使用できるマルウェアの一種です。攻撃者は、未修正のソフトウェアの脆弱性を悪用や、弱いクレデンシャルを不正利用、過去に意図せず漏洩したクレデンシャルの使用やソーシャルエンジニアリングなどさまざまな手段を使って、ターゲットのデータやシステムへの不正アクセスを試みます。ランサムウェア攻撃が発生すると、正当な組織がデータやシステムにアクセスできなくなり、デジタル資産の安全な返還と引き換えに身代金が要求されます。攻撃者が正規のアクセスを制限または無効化する手段には、a) 暗号化または削除、b) アクセス制御の変更、c) ネットワークベースの DoS (Denial of Service) 攻撃などがあります。場合によっては、データアクセスが暗号化キーの提供やデータの返却によって復旧した後、データのコピーを持つ攻撃者から、そのデータを販売したり公開したりしないことを約束する二重の身代金要求がされることもあります。 次のセクションでは、Amazon S3 でのランサムウェア発生時の対応における 4 つの重要なフェーズ、検知、対応、復旧、保護について説明します。 観測できたアクティビティ AWS Customer Incident Response Team (CIRT) が観測するところによると、Amazon S3 内のデータを標的とするランサムウェア攻撃の最も一般的な原因は、 AWS Identity and Access Management (IAM) アクセスキー の漏洩です。他の要因としては、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされた IAM インスタンスプロファイルとアクセス許可を持つアプリケーションに欠陥があり、そのインスタンスが Instance Metadata Service Version 1 (IMDSv1) を使用している場合です。この場合、不正なユーザーが Amazon EC2 インスタンスの IAM インスタンスプロファイルから AWS Security Token Service (STS) セッション キー を使用して、Amazon S3 バケット内のオブジェクトを人質に取ることができる可能性があります。この記事では、最も一般的なシナリオである、IAM アクセスキーの漏洩に焦点を当てます。 検出 攻撃者がクレデンシャルを入手した後、 IAM プリンシパル に付与されているアクセス権限を把握するために、AWS API を繰り返し実行します。悪意のある者はこれを複数の方法で行うことができ、さまざまなアクティビティが発生する可能性があります。このアクティビティは、エラーが発生する API 呼び出しの増加により、セキュリティチームに警告を発する可能性があります。一方で、悪意のある者の目的が Amazon S3 オブジェクトの身代金要求である場合、API 呼び出しは Amazon S3 に特化したものになります。利用される IAM プリンシパルにおいて Amazon S3 へのアクセスが許可されている場合、 s3:ListBuckets 、 s3:GetBucketLocation 、 s3:GetBucketPolicy 、 s3:GetBucketAcl などの API アクションの増加が見られる可能性があります。 分析 このセクションでは、ランサムウェアイベントをより詳細に分析するのに役立つログとメトリクスデータについて説明します。 ランサムウェア攻撃が Amazon S3 に保存されたデータを標的とする場合、多くの場合、Amazon S3 バケットに保存されているオブジェクトが悪意のある攻撃者によってコピーされることなく削除されます。これは、オブジェクトが暗号化されるランサムウェア攻撃というよりも、データ破壊イベントに近いものです。 この操作を記録するログがいくつかあります。 Amazon S3 データに対する AWS CloudTrail イベントログ の有効化ができます。これにより、特定のオブジェクトに対して実行された読み取りや削除の操作を確認できます。 さらに、ランサムウェア事案の前に Amazon S3 の Amazon CloudWatch メトリクス を有効化していた場合は、 BytesDownloaded メトリクスの合計を使って、異常な転送スパイクを把握できます。 別の観点では、 region-DataTransfer-Out-Bytes メトリクスを使うことです。これは、Amazon S3 からインターネットへ転送されたデータ量を示します。このメトリクスはデフォルトで有効になっており、Amazon S3 の AWS 課金と使用状況レポートに関連付けられています。 詳細については、AWS CIRT チームの インシデント対応プレイブック: Amazon S3 のランサムウェア対応 、および GitHub リポジトリの AWS カスタマープレイブック で公開されている他の対応フレームワークを参照してください。 対応 次に、IAM アクセスキーが漏洩した場合の対応方法について説明します。ビジネスへの影響に基づいて、それらのクレデンシャルをすべて置き換えるために 2 つ目のアクセスキーセットの作成を検討します。これにより、侵害されたアクセスキーを非アクティブ化しても、正当なシステムが中断されることはありません。アクセスキーの無効化は、IAM コンソールまたはインシデント対応計画に基づいた自動化ツールを通じて実施します。同時に、将来参照できるように、インシデントの詳細な記録をセキュアで非公開のインシデント対応文書内に保存する必要もあります。アクティビティが IAM ロールまたは一時的な資格情報の使用に関連している場合は、追加のステップとして アクティブなセッションを取り消す 必要があります。これを行うには、IAM コンソールで アクティブセッションの取り消し を選択し、その時点以前にロールを引き受けたユーザーへのアクセスを拒否するポリシーを付加します。その後、露出したアクセスキーを削除できます。 さらに、 AWS CloudTrail のダッシュボードとイベント履歴 (90 日間のログが参照可能) を使用して、侵害された IAM ユーザーまたはロールによるアクティビティを確認できます。この分析により、悪意のある攻撃者が作成した可能性のある永続的なアクセスを示すことができます。また、IAM コンソールを使用して、4 時間ごとに更新される IAM 認証情報レポートを確認し、アクセスキーの最終使用時間、ユーザーの作成時間、パスワードの最終使用時間などのアクティビティを確認できます。あるいは、 Amazon Athena を使用して、 AWS CloudTrail ログを照会 し、同じ情報を取得することもできます。以下の Amazon Athena クエリは、Amazon Resource Names (ARN) で指定した IAM ユーザーにおける、特定期間内のアクティビティを取得するものです。 SELECT eventtime, eventname, awsregion, sourceipaddress, useragent FROM cloudtrail WHERE useridentity.arn = 'arn:aws:iam::1234567890:user/Name' AND -- Enter timeframe (event_date >= '2022/08/04' AND event_date <= '2022/11/04') ORDER BY eventtime ASC 復旧 悪意のある行為者からのアクセスを削除した後、データを復旧するための複数のオプションがあります。これについては次のセクションで説明します。Amazon S3 には現在 undelete 機能がなく、データ削除後の復旧機能がないことに注意してください。 Amazon S3 バージョニング機能 Amazon S3 バケットでバージョニングを使用することで、同じバケット内にオブジェクトの複数のバージョンを保持できます。これにより、リカバリプロセス中に特定のバージョンを復元できます。 Amazon S3 バージョニング 機能を使用すると、バケットに保存されたすべてのオブジェクトのすべてのバージョンを保存、取得、復元できます。つまり、意図しないユーザーアクションによる削除や上書きやアプリケーションの障害からより簡単に復旧できます。たとえば、オブジェクトを削除すると、Amazon S3 はオブジェクトを完全に削除するのではなく、削除マーカーを挿入します。以前のバージョンはバケット内に残り、非最新バージョンになります。これにより、必要に応じて以前のバージョンを復元できます。バージョン管理はデフォルトでは有効になっておらず、同じオブジェクトの複数のコピーを保持するため、追加のストレージコストがかかります。コストの詳細については、 Amazon S3 の料金 を参照してください。 AWS Backup の利用 AWS Backup を使用すると、Amazon S3 データのコピーを別のアクセス認証情報の下で作成および保管し、復元プロセス中にデータを復元できるようになります。AWS Backup は複数の AWS サービスに対する集中的なバックアップを提供するため、1 か所でバックアップを管理できます。Amazon S3 に対する AWS Backup では、過去 35 日間のいつでも任意の時点に復元可能な 継続的バックアップ と、無期限を含む指定期間データを保持可能な 定期的バックアップ 、2 つのオプションがあります。詳細は、 Amazon S3 に対する AWS Backup をご覧ください。 保護 このセクションでは、AWS で利用可能ないくつかの予防的セキュリティ対策について説明します。 Amazon S3 オブジェクトロック Amazon S3 バケットに対して Amazon S3 オブジェクトロック を有効にすることで、オブジェクトの変更や削除に対するさらなる保護レイヤーを追加できます。Amazon S3 オブジェクトロックを使用すると、write-once-read-many (WORM) を使ってオブジェクトを保存し、一定期間または無期限にオブジェクトが削除または上書きされるのを防ぐことができます。 AWS Backup ボールトロック Amazon S3 オブジェクトロックが Amazon S3 オブジェクトに追加の保護を提供するのと同様に、AWS Backup を使用する場合は、 AWS Backup ボールトロック を有効にすることを検討できます。これにより、バックアップボールトに保存および作成されるすべてのバックアップに対して、同じ WORM 設定が適用されます。AWS Backup ボールトロック は、AWS アカウントのルートユーザーによる誤った削除操作やマルウェアによる削除操作を防ぐのに役立ちます。 Amazon S3 インベントリ 組織内で Amazon S3 に保存されているオブジェクトの機密性を確実に理解するために、最も重要で機密性の高いデータを Amazon S3 全体で棚卸しし、データを保護し復旧を可能にするための適切なバケット設定が行われていることを確認します。 Amazon S3 インベントリ を使用すると、Amazon S3 バケット内のオブジェクトと、暗号化ステータス、レプリケーションステータス、オブジェクトロック情報などの既存の構成を把握できます。またリソース タグ を使用して、Amazon S3 内のオブジェクトの分類と所有者にラベルを付けることで、特定の Amazon S3 バケットに保存されているオブジェクトの機密性に合わせた自動アクションとコントロールを適用できます。 MFA 削除 別の予防的な対策として、Amazon S3 バージョニングを有効化している場合 多要素認証 (MFA) 削除 を適用することができます。MFA 削除は追加のセキュリティを提供し、削除操作を開始するユーザーに MFA デバイスの物理的または仮想的な所有を MFA コードで証明させることで、誤ったオブジェクト削除を防ぐのに役立ちます。これにより、削除操作に対するセキュリティレイヤーが追加されます。 一時的な認証情報に IAM ロールを使用する 多くのランサムウェア事案は、IAM アクセスキーの漏洩から発生するため、AWS では長期的な IAM アクセスキーを使用するのではなく、一時的な認証情報を提供する IAM ロールを使用することをお勧めしています。これには、AWS にアクセスする開発者に対して ID フェデレーション を使用すること、システム間アクセスに IAM ロールを使用すること、ハイブリッドアクセスに IAM Roles Anywhere を使用することが含まれます。ほとんどのユースケースでは、IAM アクセスキーを使用する必要はありません。今こそ、IAM アクセスキーの使用を環境から排除するための監査と作業を行う良い機会です。以下の手順を検討してください。 すべての AWS アカウント一覧を作成し、IAM ユーザー、認証情報が最後にローテーションされた時期と最後に使用された時期、および付加されたポリシーを特定します。 すべての AWS アカウントのルートアクセスキーを無効化して削除します。 認証情報をローテーションさせ、ユーザーに MFA を適用します。 一時的なロールベースのアクセスを活用するように再設計します。例えば、IAM ロールや IAM Roles Anywhere を使用します。 付加されたポリシーにおいて、ワイルドカードを削除するなど、最小限のアクセス許可であることを確認します。 顧客管理の AWS KMS 鍵によるサーバー側の暗号化 別の保護策として、 AWS Key Management Service (SSE-KMS) を使用したサーバー側の暗号化 を実装し、 カスタマー管理の鍵 を使用して Amazon S3 オブジェクトを暗号化することができます。カスタマー管理の鍵を使用すると、バケット内のデータを暗号化および復号化できるユーザーを指定するキーポリシーを適用する必要があり、これによりデータを保護するための追加のアクセス制御メカニズムが提供されます。また、AWS KMS 鍵を一元的に管理し、鍵の使用時期と使用者の証跡を監査することができます。 Amazon S3 に対する Amazon GuardDuty の保護 Amazon GuardDuty に対する Amazon S3 保護 を有効にできます。Amazon S3 保護により、Amazon GuardDuty はオブジェクトレベルの API 操作を監視し、バケットのデータに対する潜在的なセキュリティリスクを特定します。これには、異常な API アクティビティと Amazon S3 内のデータに関する異常な動作に関する検出結果が含まれ、セキュリティイベントの早期発見に役立ちます。 結論 この投稿では、Amazon S3 に保存されたデータを標的とするランサムウェア攻撃について学びました。事前に対策を講じることで、潜在的なランサムウェア攻撃を迅速に特定し、その後セキュリティインシデントのリスクを軽減するための追加の保護対策を講じることができます。 この投稿に関する質問がある場合は、 Security, Identity and Compliance re:Post で新しいスレッドを開始するか、 AWS サポートに問い合わせ てください。 AWS セキュリティニュースをさらに見たい方は、 X をフォローしてください。 Megan O ’ Neil Megan は脅威検知とインシデント対応に特化したプリンシパルスペシャリストソリューションアーキテクトです。Megan とそのチームは AWS の顧客が、ビジネス課題を解決する高度で、スケーラブルで、セキュアなソリューションを実装できるよう支援しています。 Karthik Ram Karthik は、オハイオ州コロンバスを拠点とするAmazon Web Services のシニアソリューションアーキテクトです。IT ネットワーク、インフラストラクチャアーキテクチャ、セキュリティの経験を持っています。AWS では、データ駆動型のアプローチを用いて顧客のビジネス課題を解決し、セキュアで革新的なクラウドソリューションの構築を支援しています。Karthik の専門分野は、脅威検知とインシデント対応（TDIR）に焦点を当てたクラウドセキュリティです。. Kyle Dickinson Kyle はシニアセキュリティソリューションアーキテクトで、脅威検知と事故対応に特化しています。彼は顧客がセキュリティインシデントに自信を持って対応できるよう支援しています。彼はまた、AWS のセキュリティ関連のライブ番組「AWS on Air: Lockdown」の司会もしています。仕事以外の時間は、ホッケーを楽しんだり、バーベキューをしたり、自分は大型犬と勘違いしている小型犬のシャーシを説得したりと、楽しく過ごしています。

このブログは 2021 年 6 月 29 日に Nabil Mohamed (Senior Technical Account Manager)、Bruce Walker (Senior Technical Account Manager)、Jessie Felix (Senior Product Manager with Amazon S3) によって執筆された内容を日本語化したものです。その後、2021 年 11 月に S3 Intelligent-Tiering Archive Instant Access ティア が発表されるなど、Amazon S3 Intelligent-Tiering ではさらにコスト効率を高めることが可能となっています。原文は こちら を参照してください。 あらゆる規模と業種の多くの顧客が、ビジネスとデータの両方が前例のないスケールで成長していると私たちに伝えています。 Amazon S3 は、どのような開発者でも、初期投資やパフォーマンスの妥協なしに、Amazon の利点を大規模に活用することを可能にします。顧客は、S3 で得られる弾力性と俊敏性を好んでいます。なぜなら、ビジネスの成長を促進するために、顧客向けの全く新しいアプリケーションや体験の創造に集中できるからです。そして、その成長に伴い、コスト管理とコスト最適化が不可欠となります。顧客は、アプリケーションのパフォーマンスに影響を与えたり、運用の負担を増やしたりすることなく、S3 のコストを最適化するための最良のアプローチを知りたがっています。データレイク、機械学習、衛星画像、DNA配列解析、コールセンターのログ、自動運転車のシミュレーション、さらにはお気に入りのメディアや自宅でのフィットネスコンテンツまで、想像できるあらゆるワークロードが S3 上で実行されています。同時に、組織全体で S3 のストレージコストを最適化するための基本原則は、一度学べば実装するのは難しくありません。移動、分析、またはアーカイブする必要があるデータがある場合でも、S3 にはデータのアクセス、パフォーマンス、およびコスト要件に最適化されたストレージクラスがあります。すべての S3 ストレージクラス は、99.999999999% (イレブンナイン) の耐久性と最高の可用性を実現するように設計されています。 このブログの目標は、予測可能で変化するアクセスパターンを持つワークロードのストレージコストを管理する方法と、コスト削減を実現するための具体的な方法について理解していただくことです。 予測可能なアクセスパターンを持つワークロードの最適化 一定期間後にアクセス頻度が低くなるデータをお持ちですか？例えば、ソーシャルメディアアプリのようなユーザー生成コンテンツを考えてみましょう。私たちはネットワークに動画や写真を共有しますが、アップロード直後は頻繁にアクセスされるものの、数週間後、あるいは数日後や数時間後には、アクセス頻度が低くなります。このようなユースケースでは、多くの顧客はデータがいつアクセス頻度が低くなるかを知っており、S3 標準ストレージクラスから低頻度アクセスやアーカイブ用に最適化された低コストのストレージクラスにデータを移動すべき適切なタイミングを通常特定できます。 予測可能なアクセスパターンを持つ多くの顧客は、アカウント内のすべてのバケットの使用状況を詳細に理解するために、 S3 Storage Lens を使い始めます。S3 Storage Lens の高度なメトリクスを有効にしている場合、アクセスが頻繁な、まれな、あるいはほとんどないデータセット (バケット) を特定するための アクティビティメトリクス にアクセスできます。GET リクエストやダウンロードバイト数などのメトリクスは、データセットが毎日どの程度アクセスされているかを示します。このデータを数ヶ月間にわたって傾向分析し (高度なメトリクスでは長期間のデータ保持が可能)、アクセスパターンの一貫性を理解し、アクセス頻度が低くなったデータセットを特定することができます。 データセットがいつアクセス頻度が低くなるか、またはアーカイブ可能になるかがわかれば、 Amazon S3 ライフサイクル ルールを簡単に設定して、S3 標準ストレージクラスに保存されているオブジェクトを、データの経過時間に基づいて自動的に S3 標準 – 低頻度アクセス、S3 1ゾーン – 低頻度アクセス、および/または、S3 Glacier ストレージクラスに移行することができます。ライフサイクルポリシーは、AWS マネジメントコンソール、 S3 REST API 、AWS SDK、または AWS コマンドラインインターフェイス (CLI) で設定および管理可能です。ポリシーはプレフィックスレベルまたはバケットレベルで指定します。例えば、オブジェクトを作成してから 30 日後に S3 標準 – 低頻度アクセスストレージクラスに移行したり、1 年後に S3 Glacier ストレージクラスにアーカイブしたりすることを選択できます。 未知または変化するアクセスパターンを持つワークロードの最適化 アクセスパターンが未知または変化するデータがある場合はどうすればよいでしょうか？多くの顧客は、 Amazon S3 Intelligent-Tiering (S3 Intelligent-Tiering) を使用して共有データセットを保存しています。このデータセットは、分析、機械学習、リアルタイムモニタリング、その他のデータレイクのユースケースのために、異なるアプリケーション、チーム、個人によって集約されアクセスされます。これらのユースケースでは、組織内の多くのユーザーが異なるツールを使用して S3 にアクセスすることが一般的です。例えば、 Amazon Athena を使用すれば標準 SQL で S3 のデータを簡単に分析できますし、 Amazon Redshift Spectrum を使用してデータのロードや変換なしに S3 のペタバイト規模のデータに対してクエリを実行することもできます。これらのユースケースの多くでは、年間を通じてアクセスパターンが大きく変動し、ほとんどまたは全くアクセスがない状態から、1 ヶ月に複数回データが読み取られる状態まで幅広く変化する可能性があります。これが S3 標準 – 低頻度アクセスストレージクラスに保存されている場合、取り出し料金が発生する可能性があります。 アクセスパターンが変化するユースケースを持つ顧客や、カスタマイズされた階層化ルールを管理したくない顧客は、S3 Intelligent-Tiering をデフォルトのストレージクラスとして使用することを検討してください。S3 Intelligent-Tiering は、アクセスパターンが変化しても、パフォーマンスへの影響なし、運用オーバーヘッドなし、取り出し料金なしで、コスト削減の方法を提供します。これは、4 つのアクセス階層にオブジェクトを保存することで機能します：高頻度アクセスと低頻度アクセス用に最適化された 2 つの低レイテンシーアクセス階層、および非同期アクセス用に設計された 2 つのオプションのアーカイブアクセス階層です。(訳註: 現在の S3 Intelligent-Tiering にはアーカイブインスタントアクセス階層が追加されており、5 つのアクセス階層を利用することが可能です) オブジェクトを S3 Intelligent-Tiering にアップロードまたは移行すると、自動的に高頻度アクセス階層に保存されます。S3 Intelligent-Tiering は、アクセスパターンを監視し、30 日間連続でアクセスされていないオブジェクトを低頻度アクセス階層に移動させることで機能します。また、1 つまたは両方のオプションのアーカイブアクセス階層を有効にすることもできます。アーカイブアクセス階層を有効にすると、S3 Intelligent-Tiering は 90 日間連続でアクセスされていないオブジェクトをアーカイブアクセス階層に自動的に移動します。180 日間連続でアクセスがない場合、S3 Intelligent-Tiering はオブジェクトをディープアーカイブアクセス階層に移動します。後でオブジェクトに再びアクセスされた場合、高頻度アクセス階層に戻されます。 このアプローチにより、考える必要なく、ストレージコストを最大 95% 削減することができます。S3 Intelligent-Tiering にはオブジェクト数に応じた小額の月次監視料金がかかりますが、これはオブジェクトのサイズが大きくなるほど、節約額が大きくなることを意味します。128 KB 未満のオブジェクトは自動階層化の対象外であるため、S3 標準ストレージクラスに保持することをお勧めします。顧客が S3 Intelligent-Tiering を好む理由は、取り出し料金がなく、アクセスパターンが変化しても予期せぬストレージ料金の増加がないためです。 ストレージ節約シナリオ 要約すると、S3 Storage Lens と S3 ライフサイクルポリシーを組み合わせて使用することで、オブジェクトをより安価なストレージクラスに移動する適切なタイミングを知っているか、容易に特定できる場合に、最大のストレージコスト削減を実現できます。また、アクセスパターンが未知または変化するデータに対しては、S3 Intelligent-Tiering クラスを使用することで最大のストレージコスト削減を実現できます。以下では、米国東部 (バージニア北部) リージョンにある、合計 1 PB のストレージと 1 億個のオブジェクトを持つバケットの 2 つの異なるワークロードを例に挙げ、アクセスパターンに適したストレージクラスを選択することで得られる潜在的なストレージコスト削減効果を示します。価格については、 S3 の公開価格 を参照してください。また AWS Pricing Calculator for Amazon S3 を使用して、ワークロードの S3 ストレージコストを見積もることもできます。 最初のシナリオでは、オンラインビデオプラットフォームのメディアアセットを作成後 30 日で S3 標準 – 低頻度アクセスストレージクラスに移動し、オブジェクトの 10% が月に 1 回アクセスされると仮定します。1 年間で、このユースケースでは S3 標準 – 低頻度アクセスを使用した場合 $90,583 (33.3%)、S3 Intelligent-Tiering を使用した場合 $89,711 (33.0%) のストレージコスト削減が達成されます。アクセスパターンが変化しないことが分かっている場合、S3 標準 – 低頻度アクセスストレージクラスを使用することで、このユースケースでの最低ストレージコストを実現できます。アクセスパターンの予測可能性が不確かな場合でも、S3 Intelligent-Tiering を使用することで、取り出し料金の急増を心配することなく、大幅なストレージコスト削減を実現できます。 予測可能なアクセスパターン 年間コスト S3 標準 標準 – 低頻度アクセス S3 Intelligent-Tiering (アーカイブ無効) ストレージコスト $270,999 $166,762 $178,288 PUT リクエスト* $500 $500 $500 GET リクエスト $48 $120 $48 ライフサイクル移行リクエスト* NA $1,000 NA データ取り出しリクエスト Free $12,582 Free モニタリングおよびオートメーション NA NA $3,000 トータルコスト $271,547 $180,964 $181,836 * PUT リクエストとライフサイクル移行リクエストは、オブジェクトのアップロードまたは移行時に発生する一回限りの料金です 2 つ目のシナリオでは、データウェアハウジングのデータセットを S3 Intelligent-Tiering にアップロードするとします。このユースケースでは、全オブジェクトの 30% が、組織全体での計画外の分析やレポーティングワークフローのために、月に少なくとも 4 回アクセスされると仮定します。1 年間で、このユースケースでは S3 Intelligent-Tiering を使用することで 67,273 ドル (24.7%) のストレージコスト削減が達成されます。このようなユースケースは、取り出し料金によって S3 標準よりも高くなる可能性があるため、S3 標準 – 低頻度アクセスには適していません。S3 Intelligent-Tiering を使用すれば、アクセスパターンが変化しても、パフォーマンスへの影響や運用のオーバーヘッド、取り出し料金なしで、コストを削減できます。 アクセスパターンの変更 年間コスト S3 標準 S3 Intelligent-Tiering (アーカイブ無効) 標準 – 低頻度アクセス ストレージコスト $270,999 $200,198 $166,762 PUT リクエスト* $500 $500 $500 GET リクエスト $576 $576 $1,320 ライフサイクル移行リクエスト* NA NA $1,000 データ取り出しリクエスト Free Free $138,412 モニタリングおよびオートメーション NA $3,000 NA トータルコスト $271,547 $204,274 $307,994 * PUTリクエストとライフサイクル移行リクエストは、オブジェクトをアップロードまたは移行する際の一回限りの料金です 多くの場合、顧客は長期間アクセスされていないデータセットのサブセットに対して、自動的にストレージコストをさらに削減したいと考えています。例えば、研究プロジェクトや機械学習モデルの再トレーニングにのみ時々使用される過去のデータセットがあります。このようなユースケースでは、データをアーカイブし、即座にアクセス可能になるまで数分から数時間待つことを許容できるかもしれません。これがあなたのユースケースに当てはまるなら、さらなるコスト削減のために S3 Intelligent-Tiering アーカイブアクセス階層 を有効にすることをお勧めします。 年間コスト S3 Intelligent-Tiering (アーカイブ無効) S3 Intelligent-Tiering (アーカイブ有効) ストレージコスト $200,198 $158,501 PUT リクエスト* $500 $500 GET リクエスト $576 $576 ライフサイクル移行リクエスト* NA NA データ取り出しリクエスト Free Free モニタリングおよびオートメーション $3,000 $3,000 トータルコスト $204,274 $162,577 * PUTリクエストとライフサイクルリクエストは、オブジェクトをアップロードまたは移行する際の一回限りの料金です * S3 Intelligent-Tiering (アーカイブ有効) の前提条件：オブジェクトの 30% を高頻度アクセス階層に、20% を低頻度アクセス階層に、25% をアーカイブアクセス階層に、25% をディープアーカイブアクセス階層に保存 最後に覚えておくべきいくつかのこと: オブジェクトサイズ: S3 Intelligent-Tiering は任意のサイズのオブジェクトに使用できますが、128 KB 未満のオブジェクトは高頻度アクセス階層に保持されます。アーカイブアクセス階層またはディープアーカイブアクセス階層にアーカイブされた各オブジェクトについて、Amazon S3 はオブジェクト名とその他のメタデータ用に 8 KB のストレージ (S3 標準ストレージクラス料金で課金) と、インデックスおよび関連メタデータ用に 32 KB のストレージ (S3 Glacier Flexible Retrieval および S3 Glacier Deep Archive ストレージクラス料金で課金) を使用します。これにより、すべての S3 オブジェクトのリアルタイムリストまたは S3 インベントリレポートを取得できます。 オブジェクトの寿命:  S3 Intelligent-Tiering は 30 日以上の寿命を持つオブジェクトに適しており、このストレージクラスを使用するすべてのオブジェクトは最低 30 日が課金対象となります。 耐久性と可用性: Amazon S3 Intelligent-Tiering は 99.9% の可用性と 99.999999999% の耐久性を目指して設計されています。 価格: 月間のストレージ、リクエスト、データ転送 に対して料金を支払います。S3 Intelligent-Tiering を使用する場合、モニタリングおよびオートメーションのために小額のオブジェクト単位の月額料金を支払います。S3 Intelligent-Tiering に取り出し料金はなく、階層間のデータ移動に対する料金もありません。高頻度アクセス階層のオブジェクトは S3 標準と同じ料金で課金され、低頻度アクセス階層のオブジェクトは S3 標準 – 低頻度アクセスと同じ料金で課金され、アーカイブアクセス階層のオブジェクトは S3 Glacier Flexible Retrieval と同じレートで課金され、ディープアーカイブアクセス層のオブジェクトは S3 Glacier Deep Archive と同じレートで課金されます。 API と CLI によるアクセス: S3 CLI と S3 API を使用して、INTELLIGENT_TIERING ストレージクラスで S3 Intelligent-Tiering を利用できます。また、特定のバケットに対して PUT、GET、DELETE 設定 API を使用して S3 Intelligent-Tiering アーカイブを設定することもできます。 サポートする機能: S3 Intelligent-Tiering は、オブジェクトのアクセス層を報告する S3 インベントリや、データを任意の AWS リージョンにレプリケートする S3 プリケーションなどの機能をサポートしています。 結論 このブログでは、予測可能なアクセスパターンを持つユースケースと、変化するアクセスパターンを持つユースケースの ストレージコストを最適化 する方法について説明します。多くの場合、適切なストレージクラスを選択することで、お客様のストレージコストを最大 95% 削減できることがわかっています。これを実現するために、一部のお客様は異なるバケット間でカスタマイズされた階層化 S3 ライフサイクルポリシーを構築することを好み、多くのお客様は自動的にストレージコストを節約できる簡単な方法として S3 Intelligent-Tiering を使用しています。 重要なのは、データのアクセスパターンとビジネスニーズに基づいて適切なアプローチを選択することです。始める際には、ワークロードに最適なアプローチを決定するために、オブジェクトの以下のプロパティを考慮してください: 判断基準 S3 Intelligent-Tiering の検討 ストレージクラスとライフサイクル管理の検討 Overhead ストレージの最適化にほとんどまたは全くエンジニアリングリソースを割り当てる意思がない ストレージの最適化にリソースを割り当てる意思がある アクセス頻度 データレイク、ビジネスインテリジェンス、機械学習などの未知または変化するアクセスパターン ロングテールメディア、バックアップ、災害復旧などの予測可能なアクセスパターン オブジェクトのサイズ S3 Intelligent-Tiering は小額の階層化料金を請求し、自動階層化の対象となる最小オブジェクトサイズは 128 KB です。より小さなオブジェクトも保存できますが、常に高頻度アクセス階層の料金で課金されます。 標準 – 低頻度アクセスストレージクラスと 1 ゾーン – 低頻度アクセスストレージクラスの最小課金対象オブジェクトサイズは 128 KB、S3 Glacier Deep Archive ストレージクラスの最小課金対象オブジェクトサイズは 40 KB です。 オブジェクトの寿命 30 日以上保存される長寿命オブジェクトに最適。 S3 標準は 30 日以内に削除される短寿命オブジェクトに最適。 標準 – 低頻度アクセスストレージクラスと 1 ゾーン – 低頻度アクセスストレージクラスは 30 日以上保存される長寿命オブジェクトに最適、S3 Glacier Flexible Retrieval は 90 日以上、Glacier Deep Archive は 180 日以上の保存に最適 予測可能で変化するアクセスパターンを持つワークロードのストレージコストを制御および最適化する方法に関するこのブログをお読みいただき、ありがとうございます。Amazon S3 バケットの数が増加し、数十または数百のアカウントにまたがっている場合は、 「5 Ways to reduce data storage costs using Amazon S3 Storage Lens (Amazon S3 Storage Lens を使用してデータストレージコストを削減する 5 つの方法)」というブログ も併せてお読みください。これにより、S3 Storage Lens を使用して典型的なコスト削減の機会を特定する方法と、それらのコスト削減を実現するための変更を実施する方法について基本的な理解を得ることができます。 Nabil Mohamed Nabil Mohamed は AWS のシニアテクニカルアカウントマネージャーで、顧客の運用効率とコスト最適化の推進に注力しています。シアトルを拠点としており、ハイキングや妻との世界旅行、そして 2 匹の猫 (メインクーン) と過ごす時間を楽しんでいます。 Bruce Walker Bruce Walker はサンフランシスコを拠点とする AWS のシニアテクニカルアカウントマネージャーです。彼は顧客との信頼性、最適化、および運用メカニズムの改善に焦点を当てています。ブルースは妻と旅行することが大好きで、オーストラリアとキプロスの両方で家族と時間を過ごすことを楽しんでいます。 Jessie Felix Jessie Felix は、Amazon S3 のシニアプロダクトマネージャーで、S3 Intelligent-Tiering などの S3 のストレージ技術とデータサイエンスに焦点を当てています。2015 年に Amazon に入社し、AWS リクルーティング部門の分析およびデータインフラストラクチャの構築に携わりました。ビッグデータ分析への情熱から、2017 年に Amazon S3 チームに加わりました。仕事以外では、地元のカフェに行ったり、妻とラブラドール・レトリバーと一緒に湖畔でくつろいだりすることを楽しんでいます。

この投稿は株式会社ニコンの森谷 俊洋 氏、村上 隆哉 氏より金属 3D プリンター向けリモートモニタリングプラットフォーム開発の取り組みについて寄稿いただいたものです。本寄稿は前後編の 2 回に分けてご紹介するうちの前編となります。後編の内容は こちら よりアクセスできますので、ご興味のある回をご覧いただければ幸いです。 はじめに 株式会社ニコンではレーザー加工機 Lasermeister（レーザーマイスター）シリーズ を開発・販売しています。半導体露光装置で培った光計測、精密制御を応用し、レーザーによる様々な加工を高精度で行うことができ、金属積層造形からマーキング、接合、様々な材料の精密除去加工まで、材料加工分野の幅広いニーズに対応できる製品です。今回、この Lasermeister を対象にリモート監視を行う IoT 基盤として、 リモートモニタリングプラットフォーム One Board を開発しました。2024 年 10 月時点で One Board に接続済みの金属 3D プリンターは数十台を超え、今後も増加する見込みです。この One Board は AWS 上に構築しています。金属 3D プリンターからのデータ収集には AWS IoT Greengrass、ユーザー認証には Amazon Cognito を利用し、また時系列データの蓄積には、時系列データを扱うための完全マネージド型データベースであり、IoT 基盤のデータ蓄積プラットフォームとして実績のある Amazon Timestream を活用しました。Timestream により、金属 3D プリンターに搭載された各種センサから発生した時系列データへの素早いアクセスを実現しています。このように AWS の各種サービスを組み合わせることで 10 ヶ月という短期間でシステムを構築でき、また構築後の運用コストも安価に抑えられています。 本寄稿では、Lasermeister シリーズや One Board の概要を述べた後 One Board のアーキテクチャを説明します。また、後編では Timestream のデータモデルといった技術面を説明します。 製品概要 レーザー加工機 Lasermeister シリーズ レーザー加工機 Lasermeister シリーズは、金属積層造形を行う金属 3D プリンター Lasermeister 100A シリーズと Lasermeister LM300A、および、精密除去加工を行うレーザー除去加工機 Lasermeister 1000S シリーズからなります。この内、リモートモニタリングプラットフォーム One Board の現時点での対象は Lasermeister 100A シリーズと Lasermeister LM300A です。 .        参考1. Lasermeister 100A シリーズと Lasermeister LM300A の外観 Lasermeister 100A シリーズは、手軽に金属積層造形の技術を試していただけるよう、「誰でも簡単に使える装置」をコンセプトに開発した金属 3D プリンターです。とてもコンパクトなサイズで設置場所を選ばず、コンクリート建屋であればそのまま設置が可能でき、安全規格にも準拠、学生やデザイナーなど誰でも安心して使える装置となっています。また金属積層造形には様々な金属を金属粉体として利用可能です。 参考2. Lasermeister 100A シリーズを使った金属積層造形の例 一方、 Lasermeister LM300A は産業用途を考慮して開発した金属 3D プリンターです。主な特徴の一つとして、3D スキャナー Lasermeister SB100 と連携することで、タービンブレードなどの産業用部品向けの高精度で自動化された補修ソリューションを提供します。 リモートモニタリングプラットフォーム One Board One Board は、Lasermeister の状態を遠隔監視するプラットフォームであり、PC だけでなくスマホやタブレットなどを使って、金属 3D プリンターのステータスや金属粉体の残量といった状態をどこからでも簡単に把握できます。金属積層造形が完了するまでの残り時間も確認できるため、金属積層造形の終了に合わせて金属 3D プリンターの設置場所に向かうといった、利用者の効率的な働き方を推進します。この他、金属 3D プリンターのイベント履歴や金属 3D プリンター内に搭載された各種センサの値の時系列変化も確認できるため、金属 3D プリンターが正常に稼働していたかどうかや、万一トラブルが発生したときの原因追及にも使用できます。 図1. One Board の導入利点 One Board の画面では所有する金属 3D プリンターの一覧が表示され、各装置のステータスや粉体残量等を一目で確認できます。 参考3. One Boardの画面イメージ さらに金属 3D プリンターごとの詳細データとして、金属積層造形が完了するまでの残り時間やイベント履歴、各種センサ値の時系列変化を確認できます。 参考4. One Boardの画面イメージ また、万一 金属 3D プリンターがトラブルで緊急停止したとしても、利用者にはメール通知が届くため早期に気付くことができるとともに、カスタマーサポートにも同時に通知が共有され、トラブルの早期解決に貢献します。 アーキテクチャ One Board では以下のアーキテクチャを採用しています： 以下に、図中の①～④の処理の概要を記載します： 通信 SIM を搭載したゲートウェイ機器内にある AWS IoT Greengrass が定期的に金属 3D プリンターのセンサ値のデータを収集し、携帯回線を通じて Amazon S3 に送信。その後、Amazon S3 に保存されたことをトリガーに AWS Lambda が起動し、必要なデータの抽出や加工、Timestream への保存を行う。 AWS IoT Greengrass は数秒に 1 回の頻度で 金属 3D プリンターのステータスや金属粉体の残量、各種イベント等を収集するが、各種イベントのうち、金属 3D プリンターのアラートやエラーに関するものは Amazon SES を通じて 利用者やニコンの保守要員へ即座にメール通知する。 Amazon Timestream に保存された各種データは、Grafana と React を使って構築した Web アプリを通じてユーザーが確認できる。 One Board の各種設定値や構成情報は Amazon RDS for MySQL に保存し、各サービスが適宜参照している。 AWS で運用する利点 One Board をお客様に初回リリースしてから2年以上が経過した現在、One Board を運用する上での AWS の利点として以下を感じています： 多様なサービスの情報集約 One Board は AWS が提供する多様なサービスを組み合わせて構築したが、それら各サービスのログは Amazon CloudWatch に集約されており、運用中の挙動を確認しやすい。他にもAPI の使用状況は AWS CloudTrail に、各種最適化に関する情報は AWS Trusted Advisor に集約されており、それら情報の定期的なモニタリングに便利である。 安価な運用コスト 遠隔地にある金属 3D プリンターの状態を常時確認でき、万一のトラブルにも備えられる価値を考慮すると、AWS のコストは安価と考えている。また、AWS Billing and Cost Management にサービスごとのコストが整理されて表示され、コスト低減活動もやりやすい。 Timestream のスケーラビリティ 将来 One Board に接続される金属 3D プリンターの台数やユーザー数が更に増加する予定であり、蓄積されるデータ量の増加が想定されるものの、こちらについては Serverless アーキテクチャを採用する Timestream のスケーラビリティに期待している。 本稿では、リモートモニタリングプラットフォーム One Board の概要と、それを支えるアーキテクチャや AWS で運用することのメリットについて寄稿いただきました。後編については、「 【寄稿】ニコンのリモートモニタリングプラットフォームにおける Amazon Timestream の活用 」をご参照ください。 著者について 森谷俊洋 株式会社ニコン 次世代プロジェクト本部 第二開発部 第一開発課 リモートモニタリングプラットフォーム「One Board」のソフトウェア開発を担当。デジタルマニュファクチャリングへのAWSの活用に取り組んでいます。 村上隆哉 株式会社ニコン アドバンスドマニュファクチャリング事業部 戦略協業統括室 リモートモニタリングプラットフォーム「One Board」やLasermeisterシリーズのソフトウェア開発マネージャーを担当。デジタルマニュファクチャリングの推進をミッションとし、日々取り組んでいます。

この投稿は株式会社ニコンの森谷 俊洋 氏、村上 隆哉 氏より金属 3D プリンター向けリモートモニタリングプラットフォームにおける Amazon Timestream 活用の取り組みについて寄稿いただいたものです。本寄稿は前後編の 2 回に分けてご紹介するうちの後編となります。前編の内容は こちら よりアクセスできますので、ご興味のある回をご覧いただければ幸いです。 Amazon Timestream の活用 Amazon Timestream を選んだ理由 One Board の開発当初、オンプレミスのデータベースとクラウドのデータベースのどちらを採用するかをまず検討しました。その結果、以下の理由からクラウドのデータベースを選択しました： マネージドサービスとしてスケールアップ/ダウンが自動で行われるため、オンプレミスに比べて手間がかからず開発作業に注力できること ベストプラクティスも広く公開されていること 次にAWS以外のクラウドベンダーが提供するデータベースとも比較しました。その結果、以下の理由からAWSを採用しました： 社内で AWS の開発事例が多いこと AWS とコーポレート契約を締結しており、コストを抑えて利用できること 24 時間 365 日の問い合わせ可能サポートがあること 尚、One Board では時系列データ以外のデータ保管には Amazon RDS for MySQL を利用しており、ケースバイケースで最適なデータベースを選択しています。 データモデル One Board が Timestream で適用しているデータモデルの一部を以下に示します。One Board では単一のレコードに複数の測定値を登録するマルチメジャーレコードを採用しています： 表 1. One Board のデータモデル 各列の概要は以下の通りです： Serial_number 金属 3D プリンターの機体ごとの識別子。機体ごとのデータ集計に利用する Time レコードのタイムスタンプ Laser_power 金属 3D プリンターが金属積層造形に使うレーザーの出力の実測値 [kW] 。期待どおりに出力されることが金属積層造形の品質に影響するため、品質を示す指標の一つとして収集する Oximeter_1, Oximeter_2 金属 3D プリンター内に搭載する２種類の酸素濃度計の計測値 [%] 。金属 3D プリンターがレーザーを使って金属積層造形を行うには、金属 3D プリンター内の酸素濃度が一定値以下となる必要がある。また、金属 3D プリンターのオペレーション・ドアは安全のため金属積層造形中には自動施錠され、金属積層造形完了後に酸素濃度が一定値以上になると自動解除される。このように酸素濃度は金属積層造形の重要な指標であり、それぞれ計測レンジが異なる2種類の酸素濃度系を収集し、金属 3D プリンターが正しく動作したことを示す指標の一つとして収集する Gas_pressure レーザーを使った金属積層造形時の安全性を確保する不活性ガスの供給圧力 [kPa] 。供給圧力が一定値以下になると、安全のために金属積層造形が自動的に停止される。One Board は金属 3D プリンターが正しく動作したことを示す指標の一つとして収集する データ量や参照頻度 Amazon Timestream に保存するデータの量や参照頻度は以下の通りです： 発生するデータ量 金属 3D プリンター1台あたり、数百MB/日 保存されているデータの総量 2024 年 10 月時点で数百 GB 超 データの参照頻度 利用者一人あたり、1 時間に 1 回ほど参照 ※ 主なユース―ケースとして、金属 3D プリンターの稼働中にそのステータスや金属積層造形の予定完了時刻を確認する使い方を想定。 クエリのレスポンス Grafana から Timestream にクエリをかけてグラフ一つを表示するまでに約 2 秒 Amazon Timestream の良かった点 まず時系列データの保存に関しては、マルチメジャーレコードを利用することで直感的に格納データを理解でき有用でした。また、性能やコストの異なるメモリストアとマグネティックストアの２つのストレージ階層を、特段意識せずとも自動的に使い分けてくれる点も有用でした。一方で時系列データの活用に関しては、SQL として Date & Time の変換機能 や Window 関数など一通りの機能が揃っており、使い慣れた SQL を利用することで取得したデータを様々に加工して Grafana へ表示することが可能である点を評価しています。また AWS マネジメントコンソールから容易に SQL を発行できる点も好評です。さらに現時点で性能問題は発生しておらず、安定したレスポンスを維持できています。 開発完遂に向けた取り組み One Board は開発者数 5 人ほどで開発をスタート、当時は筆者の所属部署には金属 3D プリンターの組込ソフトウェアの開発者はいるものの、クラウド開発の知見は皆無であったため、予定した期間内での開発完遂を目指し以下の取り組みを実施しました。その結果、約 10 か月間という短い期間で社外のお客様にリリースすることができました： 既に AWS 上での開発経験がある他部署に相談し協力を依頼した リーンスタートアップの手法を採用し、仮説設定→最低限の機能の試作→仮説検証のサイクルを繰り返した AWS の技術サポート窓口を適宜活用した 特に 3 点目に関しては、システム設計においてはマルチテナントを実現する必要がある中で、レコードへのアクセス権を厳密に管理するための方法が課題となりました。結果としてレコードのオーナーごとにデータベースを分け、データベース毎にアクセス権を限定した IAM ユーザーを用意するサイロモデルを採用することにしましたが、そういった過程において適宜 AWS サポート窓口を活用することで短時間で課題解決に至ることができました。 今後の方向性 現在は金属 3D プリンターの遠隔監視に使用している One Board の今後の方向性として、以下を想定しています。 蓄積したデータの活用 運用開始から 2 年以上が経過し、金属 3D プリンター内に設置した各種センサのデータが一定量蓄積されてきた。その間、金属 3D プリンターにおけるレーザー等の重要部品の故障事例も記録しているため、これらを組み合わせて、重要部品の故障予知の実現につなげたい サプライチェーン上で前後の工程に関するデータの蓄積・活用 例えば、金属 3D プリンターによる金属積層造形の品質に大きく関わり、その前工程で調達する金属粉体の状態やロット、あるいは、後工程である造形結果の外観検査結果を One Board に蓄積し、金属 3D プリンターのデータと組み合わせて確認することで、金属積層造形の品質向上に活用することを想定している エンジニアリングチェーン上で前後の工程に関するデータの蓄積・活用 金属 3D プリンターでは、事前に造形対象物の 3D CAD を用意し、それを CAM ソフトウェアでツールパスとよばれる金属3D プリンターの動作を表すデータに変換した後、ツールパスを基に金属積層造形を実行することが一般的である。このプロセスにおいて、3D CAD の形状や CAM ソフトウェアによる変換結果も金属積層造形の精度や造形時間に影響を与える。これら 3D CAD や CAM ソフトウェアのデータも、金属 3D プリンターのデータと組み合わせて One Board に蓄積することで、造形対象物に応じた金属積層造形の精度向上や造形時間の短縮に活用したい 図 1. 金属 3D プリンターにおけるサプライチェーンとエンジニアリングチェーン おわりに 本稿では、株式会社ニコンが開発・販売する金属 3D プリンター向けのリモートプラットフォーム One Board についてご紹介しました。One Board は AWS の様々なサービスを活用し構築しており、One Board の遠隔監視機能がもたらす価値を鑑みると、運用コストも安価に抑えることに成功しています。今後は蓄積したデータの活用や、サプライチェーンやエンジニアリングチェーンの前後の工程のデータの蓄積・活用を想定しています。 本寄稿シリーズでは、前編「 【寄稿】ニコンの金属 3D プリンター向けリモートモニタリングプラットフォーム開発の取り組み 」にて Lasermeister シリーズ や One Board の概要と One Board を支えるアーキテクチャやAWS で運用するメリットを説明いただきました。また、後編（本稿）では Amazon Timestream の活用やデータモデル設計といった技術面を説明いただきました。 著者について 森谷俊洋 株式会社ニコン 次世代プロジェクト本部 第二開発部 第一開発課 リモートモニタリングプラットフォーム「One Board」のソフトウェア開発を担当。デジタルマニュファクチャリングへのAWSの活用に取り組んでいます。 村上隆哉 株式会社ニコン アドバンスドマニュファクチャリング事業部 戦略協業統括室 リモートモニタリングプラットフォーム「One Board」やLasermeisterシリーズのソフトウェア開発マネージャーを担当。デジタルマニュファクチャリングの推進をミッションとし、日々取り組んでいます。

広告やマーケティングに携わる方々を主な対象として、2024 年 10 月 17 日に「生成 AI と AWS Ad/Marketing Tech Services で実現する広告・マーケティングイノベーション」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログではセミナーの内容を簡単にご紹介します。 見所としては以下3点です。 【いまさら聞けない!?】AWS の Ad/Mktg Tech サービスの効果的な活用方法 生成 AI やデータクリーンルーム等、AWS の Ad/Mktg Tech サービスの最新アップデート（2024年10月時点） データコラボレーションサービスである AWS Clean Rooms のお客様事例 Session 1. オープニング アマゾン ウェブ サービス ジャパン合同会社 事業開発統括本部 シニア事業開発マネジャー 松本 鋼治 資料ダウンロードリンク オープニングでは、本イベントの開催目的や、Amazon グループにおける広告マーケティングテクノロジーの位置付け、AWSとしてどのようなコンセプトでソリューション開発や支援を行っているかについて、全体概要をご説明いたしました。 広告・マーケティングテクノロジーの分野は Amazon グループ全体においても重要な位置づけを持ち、AWS の技術がその基盤を支えています。Amazon が提供する多様なサービス（eコマース、リテールメディアなど）は、AWSを活用した適切なマーケティングの仕組みとともに進化を続けています。特に、AWSの広告・マーケティングソリューションは以下の3つを重要なコンセプトとして展開されています： イノベーションの加速 コストパフォーマンスの最適化 データ連携の強化 また、生成 AI の活用にはデータが不可欠です。AWS のデータ管理技術は、プライバシーやセキュリティを確保しながら、企業のデジタルトランスフォーメーションを支援します。また、個人情報保護規制が強化される中、ファーストパーティデータを適切に管理し、ビジネスパートナーと連携して活用する仕組み作りが不可欠です。企業が競争力を高めるには、顧客やパートナーと共にデータや技術を活用し、安心・安全なイノベーションを推進することが求められていると考えます。 Session 2. 顧客の行動の理解促進と最適なキャンペーン展開 アマゾン ウェブ サービス ジャパン合同会社 ストラテジックインダストリ技術本部 デジタルソリューション部 ソリューションアーキテクト 関藤 寛喜 資料ダウンロードリンク 本セッションでは、デジタルマーケティングの課題と、AWS が提供する広告・マーケティングテクノロジーの最新ソリューション（2024年10月時点）について解説いたしました。 デジタルマーケティングの課題として、昨今の 3rd Party Cookie に関する規制の影響もあり、顧客行動の理解を深めて特定のセグメントに対して的確にキャンペーン情報を送信する上で、ターゲティングの精度やプライバシーへの配慮の難しさが挙げられます。それらの課題を解決するソリューションとして、Amazon Ads が提供するAmazon Marketing Cloud、そして AWS が提供する AWS Clean Rooms と AWS Entity Resolution について、それらの違いやサービス概要について解説いたしました。特に、AWS Clean Rooms と AWS Entity Resolution のサービスを組み合わせて実現する具体的なユースケースと、各サービスの最新アップデート（2024年10月時点）についてご紹介いたしました。 また、生成 AI を活用してユーザープロファイルを作成するユースケースや、実運用で課題になりがちな日本語データの突合のための前処理（ID マッチング）を AWS Entity Resolution で実現する方法についてもご紹介しています。 Session 3. AWS で実現するクッキーレス時代のマーケティング変革 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第三ソリューション部 部長/シニアソリューションアーキテクト 鈴木 浩之 資料ダウンロードリンク 本セッションでは、お客様からよく伺う広告マーケティングに関する課題をもとにした以下の３つのユースケースを取り上げ、生成 AI 機能を含む様々な AWS サービスを活用したマーケティング変革のためのアプローチについてご紹介いたしました。 他社データとのコラボレーションで顧客プロファイル拡充 パーソナライズしたセグメントにキャンペーン送信 Web サイトのユーザ行動分析 ユースケース 1 では、AWS Clean Rooms と AWS Entity Resolutions を利用した Customer 360 強化のためのデータコラボレーションや、生成 AI 機能によって進化した BI サービス Amazon QuickSight による可視化についてデモを交えてご紹介しました。ユースケース 2 では、マーケティングコミュニケーションサービス Amazon Pinpointと、Amazon Bedrock の生成 AI 機能を組み合わせ、顧客離反予測からパーソナライズされたオファー生成と提案の自動化のユースケースをご紹介しました。また、ユースケース 3 では、Google Analytics や Amplitude などの 3rd Party ツールと連携した WEB サイトのユーザー行動分析およびレコメンド生成の実現方法について解説しています。 Session 4. AWS で拓く地方都市における地域共創プラットフォームの未来 株式会社中国新聞社 メディア開発局 メディア開発部長 石井 将文様 資料ダウンロードリンク 株式会社中国新聞社様は、従来の強みを活かしながら新たな価値提供へのチャレンジを進められており、デジタル領域のプレゼンスを高めるビジネスドメインとして開始した新サービスである地域IDプラットホーム「たるポ」と、関連する取り組みについてご紹介頂きました。 「たるポ」は B2C と B2B それぞれの領域に様々な価値を提供するプラットフォームです。例として B2C 領域では、一つの ID で様々なサービスと幅広く連携可能になります。B2B 領域では、たるポのプラットフォームをそのまま導入することで、早く安く会員基盤を構築できる点や、個人情報と興味関心・行動などのデータを掛け合わせたデータ分析が可能となります。 たるポの特徴 AWS採用の理由と技術的背景について、複数ある中から以下３点を取り挙げられています スケーラビリティと可用性: 利用者の増加や外部システムとの連携を見据えた柔軟性確保、サービスの継続性担保。 マネージドサービスの活用: 運用コストを低減し、セキュリティを担保しながらも効率的な拡張を可能に エコシステムの充実: 外部連携も容易にする多種多様なサービス、ユーザーコミュニティの強さ、ドキュメントの豊富さ システム構成はサーバーレスを採用し、運用負荷を軽減されています。さらに、データ分析機能としてサーバーレス BI の Amazon QuickSight と Amazon Redshift Serverless を採用しています。 また、「たるポ」ではオンライン・オフラインのデータを幅広く収集・活用されており、AWS Clean Rooms を活用したデータコラボレーションを進行中で、他企業との連携による新たな価値創出を目指されています。個人を特定しないセキュアな環境で、自社と連携企業のデータをコラボレーションさせて新しい気づきを得るデータクリーンルームの概念が「たるポ」のビジョンにマッチしていると考えられています。同社では AWS と連携し、データ利活用体験を地域に広げるため、広島にて複数の企業を招き、データクリーンルームによるデータコラボレーションワークショップも開催されました。 参考） 【開催報告】中国新聞社/ AWS 共催 データコラボレーションワークショップ in 広島 Session 5. クロージング アマゾン ウェブ サービス ジャパン合同会社 事業開発統括本部 シニア事業開発マネジャー 松本 鋼治 クロージングでは、本イベント各セッションの振り返りのほか、AWS がご提供する各種支援プログラムについてご紹介しました。例えば、AWS の専門人材と先端テクノロジー・業界先進事例・Amazon のビジネスノウハウをもとに、お客様の経営層や次世代リーダーの方と議論を行う Executive Briefing Center （EBC）があります。また、ワークショップを通じて Amazon の顧客視点でのプロダクト企画手法である Working Backwards を体験・実践するプログラムである Digital Innovation Program (DIP) があります。さらに、サービス開発のコンサルティング支援を行う AWS Professional Services など、お客様のビジネスを加速・具体化する様々な支援プログラムをご紹介しています。 まとめ 今回のセミナーでは、広告マーケティング領域における市場動向や、Amazon および AWS の取り組み、生成 AI を含む各種 AWS 関連サービスやユースケースに加え、中国新聞社様にデータコラボレーションに関する事例をご紹介頂きました。 AWS は広告マーケティング業界において、広告主、マーケティング担当者、パブリッシャー、代理店、テクノロジーリーダー向けに様々なサービスやソリューションを提供し、お客様のイノベーションの実現に貢献を続けています。昨今注目される 生成 AI やデータクリーンルームなどの技術によって、その進化は加速していると言えます。 本イベントの各セッションが、皆様 1人1人の学びの一助となり、皆様ご自身や企業、組織のITのみならず経営や事業課題解決に貢献できれ ば幸いです。今後も広告やマーケティングに携わる皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しておりますので是非ご覧ください。 広告マーケティング業界参考情報 [1] 広告とマーケティングのための AWS [2] AWS Blog Marketing & Advertising [3] AWS Black Belt Online Seminar AWS Clean Rooms 著者 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第三ソリューション部 部長/シニアソリューションアーキテクト 鈴木 浩之

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 1月も下旬になりました。そろそろ4月の新年度を意識して、いろいろなチャレンジや新しい取り組みについて思いを巡らせている方も多いのではないでしょうか？いろいろな方と会話する中で、「去年始めた生成AI活用を進めたい」「今年から新たに取り組むことになっている」「去年の取り組みを振り返って、より良い活用を模索したい」などいろいろな声をいただいています。AWSとしては、みなさんの新しい取り組みを様々な形でお手伝いしたいと思っていますので、引き続き情報のチェックをよろしくお願いします。 それでは、1 月 13 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「あらゆるデータソースに会話型インタフェースを追加する」を公開 この記事では、生成AIを構成するモデルが外部データや機能にアクセスする、Tool(Function Callingともいいます)機能を利用することで、モデル自身の学習データに含まれない知識や、リアルタイムな情報を取得できるようにする方法を説明しています。Tool機能を利用することで、最新の天気予報や今現在の株価などのリアルタイム情報を扱ったり、社内のデータベースを参照して必要なデータを利用できるように、生成AIアプリケーションを拡張することが可能になりますので、興味のある方はぜひご一読を。 ブログ記事「生成 AI アプリをノーコードで作成・社内配布できる GenU ユースケースビルダー」を公開 AWSジャパンが公開している生成AIアプリケーションのサンプル実装である GenU(Generative AI Use Case JP) で、事前に用意されているものではない独自のユースケースを自分で追加できる「ユースケースビルダー」という機能が提供されています。この記事では、ユースケースビルダーの利用方法をご紹介しています。 ブログ記事「エンタープライズ向けのマルチテナント型の生成 AI 環境を AWS で構築する」を公開 企業や団体内部の様々なチームが、個別に生成AIを活用したアプリケーションを開発している状況も珍しくなくなってきました。この記事では、組織内で共通する生成AIコンポーネントを集約し、重複する作業を集約することで全体を効率化し、イノベーションを加速する方法をご紹介しています。ちょっぴり長い記事ですが、ガバナンスや責任あるAIなどの観点についてもカバーされていますので、同時多発的に生成AI活用を検討している組織の方などにおすすめです。 ブログ記事「AWS の生成 AI を活用した Happy Sad アプリ、児童の心身の健康を向上」を公開 この記事は、子どもの感情に関する自己認識を向上させるとともに、教室で子どもと接する教員向けに感情状態のパターンや傾向認識を目的とした米国内での取り組みである「Happy Sadアプリ」に関するストーリーをまとめたものです。AWSの様々なお客様支援の枠組みを活用し、Happy Sadアプリの教育現場での適用を加速している一例です。 ブログ記事「Amazon Bedrock の新しい RAG 評価機能と LLM-as-a-Judge 機能」を公開 AWS re:Inventで発表された、生成AIアプリケーションの開発とテストの合理化に役立つ2つの機能について深掘りする記事の和訳を公開しました。この記事ではAmazon Bedrock Knolwedge Basesを利用してRAGアプリケーションを評価し最適化できる機能、モデル評価にLLMを活用することで人間が評価したものと近い品質のモデル評価を実現するLLM-as-a-Judge機能について掘り下げています。 サービスアップデート Amazon Q Developer plugin for CloudZeroが一般利用開始に Amazon Q Developerの機能が拡張され、AWSマネジメントコンソールを離れることなく、CloudZeroのクラウド費用最適化プラットフォームにアクセスできるようになりました。Amazon Q Developerを利用して、コストに関するインサイトや請求情報を得るためにシームレスにCloudZeroを呼び出すことが可能になります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年1月30日(木) 19:00-21:00に「 2025クラウドガバナンスはこう変わる！マルチアカウント運用のre:Invent最新情報と活用例 」が AWS Startup Loft Tokyo にて開催されます。このイベントでは AWS アカウントの実践的な運用方法や、ガバナンス強化のベストプラクティスについて、AWS アカウントの運用のエキスパートである企業様にご登壇頂くほか、昨年の re:Invent での発表を含む最新アップデート情報や Tips を共有する内容となっています。クラウド運用を改善していきたい方にとって、AWSのクラウドガバナンス、アカウント運用の最前線をキャッチアップする良い機会かと思いますので、お時間あれば、ぜひご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月13日週の主要なアップデート 1/13(月) Amazon MSK Connect now supports updating connector configuration Amazon MSK Connect で既存コネクタの設定更新機能をサポートしました。この機能アップデートにより、コネクタの設定におけるデータソースやデータシンクの更新、処理設定を変更することができます。MSK Connect のコネクタ更新機能は、Amazon MSK Connect がサポートされているすべての AWS リーションで利用可能です。 AWS Security Hub now integrates with Amazon Route 53 Resolver DNS Firewall AWS Security Hub は Amazon Route 53 Resolver DNS Firewall と統合され、AWSアカウント全体のセキュリティアラートとコンプライアンスステータスを包括的に確認することができるようになりました。Route 53 Resolver DNS Firewall は悪意あるドメインに対する DNS クエリをブロックするとともに、信頼できるドメインに対するクエリ許可を行うマネージドファイアウォールです。今回の統合により、悪意あるDNS クエリに対するセキュリティ検出結果を、AWS Security Hub 内で、Amazon GuardDuty や Amazon Inspector などの複数のAWS サービスからのセキュリティ検出結果と併せて確認することが可能です。 1/14(火) EC2 Image Builder simplifies converting Windows ISO files to AMIs Amazon EC2 Image Builder で、Microsoft Windows の ISO ファイルを Amazon Machine Images (AMIs) に直接変換できるようになりました。今までは、Windows の ISO ファイルを AMIs に変換する際、複数のツールを利用したり、手動での作業が必要で、運用作業の負担がありました。今回のアップデートにより、EC2 Image Builder で Windows 11 ISO ファイルをシームレスにインポートできるようになったため、変換ワークフローの負荷軽減につながります。また、Amazon WorkSpaces で既存の Windows ライセンス (BYOL) を活用するプロセスも簡素化されます。この機能はすべてのAWS の商用リージョンで利用可能です。 1/15(水) Announcing larger General Purpose bundles for WorkSpaces Personal and Core Amazon WorkSpaces PersonalとAmazon WorkSpaces Core 用の GeneralPurpose.4xlarge (16vCPUと64GB RAM)および GeneralPurpose.8xlarge (32vCPUと128GB RAM) のバンドルを提供開始しました。これらのバンドルは 開発者はVisual Studio、IntelliJ、Eclipseなどのツールを使用して大規模なコンパイルや開発タスクを処理でき、エンジニアやサイエンティストは MatLab、GNU Octave、R、Stata を使用して複雑なシミュレーションを実行できるように設計されています。両バンドルとも 175 GB のルートボリュームと 100 GB のユーザーボリュームを含み、Windows Server 2022 と Windows 11 を BYOLオプションでサポートしています。アフリカ（ケープタウン）とイスラエル（テルアビブ）を除く、WorkSpaces Personal と WorkSpaces Core が提供されているAWSリージョンで利用可能です。 AWS Step Functions adds integration for 36 services including AWS End User Messaging AWS Step Functions は、AWS SDK 統合を拡張し、AWS End User Messaging や Amazon Q Apps (Amazon Q Business の機能) を含む 36 の AWS サービスのサポートを新たに提供しました。また、36 の新しく追加されたサービスに加えて、Step Functions は AWS Transfer Family、Amazon EC2、AWS Lambda、AWS Glue などの AWS サービスから 1,000 以上の新しい API アクションのサポートも追加しました。追加されたサービスの一覧リストは、 ユーザガイド をご参照ください。 Amazon MemoryDB and Amazon ElastiCache now supports Service Quotas Amazon MemoryDB と Amazon ElastiCache で Service Quotas をサポートしました。AWS Service Quotas コンソールを通じて、 Amazon MemoryDB および Amazon ElastiCache のクォータ制限を直接確認でき、そして管理が可能です。このアップデートにより、適格なリクエストに対する自動化された上限増加の承認を可能にし、サポートチケットの数を減らせます。 1/16(木) The AWS Management Console now supports simultaneous sign-in for multiple AWS accounts AWS マネージメントコンソールにおけるマルチセッションサポートを発表しました。この機能により、AWSコンソールで複数のAWSアカウントにアクセス可能となります。１つのブラウザにつき、最大で５つのセッションにサインインでき、同じアカウント、もしくは異なるアカウント内でルート、IAM、フェデレーテッドロールの柔軟な組み合わせでの利用が可能です。開発環境、テスト環境、本番環境と異なる環境ごとに別々のアカウントをそれぞれ複数のブラウザを利用したりする手間が軽減されます。 Introducing new larger sizes on Amazon EC2 Flex instances Amazon EC2 Flex（C7i-flex、M7i-flex）インスタンスで新しく2つの大きいサイズ（12xlarge、16xlarge）の一般提供を開始しました。これらのインスタンスは、AWS カスタムの第4世代 Intel Xeon スケーラブルプロセッサーを搭載しており、他のクラウドプロバイダーが使用する同等の x86 ベースの Intel プロセッサーよりも最大 15% 優れたパフォーマンスを提供します。両インスタンスサイズともに、日本においては東京リージョンで利用可能です。 Amazon Connect Contact Lens launches new real-time dashboard Amazon Connect Contact Lens で新しいダッシュボードの提供を開始しました。このダッシュボードでは、オペレーターの活動をリアルタイムでモニターでき、例えば、オペレーターが難しい対応状態にある場合、自動的に赤色でハイライトしたり、追加の支援が必要な状態を視覚的に素早く示すことができます。 1/17(金) Amazon S3 Tables are now available in five additional AWS Regions Amazon S3 Tables が東京リージョンを含む、５つの AWS リージョンで利用可能となりました。S3 Tables はビルトインの Apache Iceberg サポートを備えたオブジェクトストアで、分析用のワークロードに最適化されています。Amazon S3 Tables は今まで3つの US リージョン (オレゴン、バージニア、オハイオ) で利用可能でしたが、新たに、東京リージョンと４つのヨーロッパリージョン(フランクフルト、アイルランド、ロンドン、ストックホルム)でご利用いただけるようになりました。詳細は ユーザガイド をご参照ください。 AWS CodeBuild now supports test splitting and parallelism AWS CodeBuild でテスト分割をおこない、複数の並列環境で実行できるようになりました。単一のコンピューティングリソースを使用する条件下で、プロジェクトにおけるテスト数が増えると、テスト作業の時間も比例して増加してしまいます。今回のアップデートにより、シャーディング戦略に基づいて、テスト分割を行い、指定された複数のコンピューティングリソースで並列テストを実行することで、CI/CD パイプラインの全体的なテスト時間の短縮が期待できます。 1月28日(火) -31日(金) にかけて、「 AWS re:Invent Recap – インダストリー編 」のオンラインセミナーが行われます。先進的な取組をされている各業界のお客様が、 どのようにクラウドテクノロジーを活用しているかといった AWS re:Invent でのブレイクアウトセッションの講演内容を、インダストリーごとに厳選し、お届けします。ぜひ事前登録の上ご参加ください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

2024 年 12 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS CodeConnections AWS CodeConnections は、AWS のサービスとサードパーティの Git リポジトリを統合するためのサービスです。本セミナーでは、AWS CodeConnections の概要、機能解説、ユースケースについてご紹介します。 資料（ PDF ）  対象者 サードパーティの Git ベースのソースプロバイダと AWS サービスを安全に統合 AWS CodePipeline, AWS CloudFormation, Amazon Q Developer などの AWS サービスが以下の機能を利用できるようにすること リポジトリイベントに関する通知の受信 ソースコードのダウンロード コードのビルド、テスト、デプロイ 本 BlackBelt で学習できること AWS CodeConnections の概要 AWS CodeConnections の機能解説と使用方法 AWS CodeConnections のユースケース スピーカー 伊原 健太 ソリューションアーキテクト AWS 本番移行に向けた準備、移行リハーサルの進め方 クラウド移行を進める際、本番移行に向けた準備が必要です。 本セッションでは、本番移行に向けた移行準備、移行リハーサルについて説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 本番移行に関わるプロジェクトマネージャー、移行プロジェクトリーダー、移行担当メンバー 初めて AWS 本番移行をされる方 本 BlackBelt で学習できること 本番移行に向けた移行準備、移行リハーサルについて理解できる。 スピーカー 須山 健吾 ソリューションアーキテクト AWS Identity and Access Management (IAM) Access Analyzer AWS Identity and Access Management (IAM) Access Analyzer は、AWS IAM の機能の一部であり、セキュリティベースラインを構築する上で重要なアクセス権限管理の効率化に役立ちます。本セッションでは、AWS Identity and Access Management (IAM) Access Analyzer の概要や各種機能についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS IAM のアクセス権限の管理・運用を担当されている方 AWS IAM Access Analyzer の利用を検討されており、各種機能の理解を深めたい方 本 BlackBelt で学習できること AWS IAM Access Analyzer の各種機能に対する理解 AWS IAM Access Analyzer を用いたアクセス権限管理の効率化について スピーカー 田中 崚 クラウドサポートエンジニア Amazon Elastic Block Store(Amazon EBS) 基礎編 Amazon Elastic Block Store (Amazon EBS) は、2008 年の登場後、今も進化を続けるブロックストレージサービスです。本セミナーでは、Amazon EBS の基本的な概念や各種機能、お使いいただくメリットについて解説します。はじめてクラウドをご利用いただく方に特におすすめです。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスのインフラ運用をされており、これから AWS を利⽤される⽅ Amazon EBS の基本を押さえたい⽅ Amazon EBS を深く知るための最初の⼀歩を踏み出したい⽅ 本 BlackBelt で学習できること 本セミナーでは、オンプレミスにおけるデータ保管、すなわちストレージの課題を、クラウドストレージでどう解決できるのかについて学べます。 スピーカー 田中 里絵 ソリューションアーキテクト 自動車業界と AWS セキュリティ すでに自動車のユーザー体験にクラウドは密接に関わっており、自動車業界でのセキュリティへの取組みについての準拠もクラウド運用もおいて求められています。本セッションでは、自動車とクラウドの関係と自動車のセキュリティがどのようにクラウドと関係するかを整理していきます。 資料（ PDF ） | 動画（ YouTube ） 対象者 自動車業界に関係する、 AWS リーダー、メンバー、AWS セキュリティ運用を担当としているエンジニアの方 本 BlackBelt で学習できること 自動車とクラウドの関係と自動車のセキュリティがどのようにクラウドと関係するかを整理し、AWS のセキュリティの取り組みについてご紹介いたします。 スピーカー 福嶋　拓 シニアソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-01 AWS Transit Gateway Deep Dive ソリューションアーキテクト 櫻井 俊和 2025-01 AWS Database Migration Service ベストプラクティス – 計画・検討編 クラウドサポートエンジニア 菅原 照太 2025-01 AWS MGN 大規模移行の計画と実行をお手軽にする便利な機能紹介編 ソリューションアーキテクト 鈴木 槙将 2025-02 AWS Database Migration Service ベストプラクティス – 運用・監視編 クラウドサポートエンジニア 大井 基彰  

Amazon Bedrockを使用してジェネレーティブAIアプリケーションを構築する際、外部データや機能にアクセスさせることでモデルの機能を強化する必要があることがよくあります。それを行う方法は、 Tool （Function Calling と呼ばれることもあります）を使うことです。これらの Tool はブリッジの役割を果たし、モデルの学習データにはない、アプリケーション固有のリアルタイムまたは動的な情報をモデルが取得できるようにします。例えば、一般的な問い合わせに答えるだけでなく、ライブの天気予報やニュースを取得したり、最新の株価を取得したり、社内のデータベースと対話したりできる会話アシスタントを想像してみてください。 LLM Tool の仕組み Tool の説明 はじめに、LLM は使用可能な Tool について知る必要があります。適切な状況に適切なものを選択するために、名称や説明など、使用可能な Tool に関する情報が必要です。詳細な説明とわかりやすい名称を提供することで、LLM の決定を助け、より良い結果につなげることができます。また、LLM は API 仕様や関数インターフェースのように、 Tool のインプットに何があるかを知る必要があります。 Amazon Bedrock Converse API では、Tool の定義は次のようになります： { "tools": [ { "toolSpec": { "name": "get_news", "description": "Provides the latest news for a given topic.", "inputSchema": { "json": { "type": "object", "properties": { "topic": { "type": "string", "description": "The Topic we want the news about." } }, "required": [ "topic" ] } } } } ] } このオブジェクトは、Tool が何を行い、どのような入力を必要とするかを記述します。例えば、「 News API 」Tool はニュースを返すためにトピックを入力として必要とするかもしれません。 AWS Amplify AI Kit を使えば、これは大幅に簡略化されるため、このような方法でTool を定義する必要がなくなることは後ほど説明します。 Tool の呼び出し ユーザーが Amazon Bedrock と対話するとき、モデルはプロンプトを分析し、レスポンスを生成するために Tool が必要かどうかを判断します。もし必要であれば、モデルは使用する Tool を指定し、アプリケーションコードに Tool の使用を依頼しレスポンスを返します。 アプリケーションは Tool のレスポンスを受信し、リクエストを満たすためのコードを実行します。この実行の出力は会話履歴に追加され、モデルに送り返されます。モデルは会話履歴にある Tool の実行結果を用いてこのリクエストを処理し、人間が読めるレスポンスを生成することでユーザーに応答するか、必要であれば別の Tool を呼び出すことを選びます。LLM はステートレスであり、LLM への各リクエストは個別のユニークな API コールであり、会話履歴、システムプロンプト、 Tool 設定はすべて毎回 LLM に送信されます。LLM の外側にあるアプリケーションコードは、会話履歴を管理し、適切なタイミングで Tool を起動し、LLM にプロンプトを出したり再プロンプトを出したりする必要があります。何が起きているのか、簡略化した図を見てみましょう： LLM Tool の使用は非常に強力ですが、管理もかなり複雑になっています。AWS Amplify AI Kit が、リッチでインタラクティブな生成 AI アプリケーションを構築するための Tool として、どのように簡単に定義できるかを見てみましょう。 AWS Amplify で LLM Tool を利用する まず、Amplify ライブラリーがインストールされていて、Amplify アプリケーションがセットアップされていることを確認してください。 新しい Amplify AI Kit を使ってフルスタック AI アプリを構築する方法 については、こちらの記事で詳しく説明しています。 Amplify では、 amplify/data/resource.ts ファイルのスキーマで、TypeScript を用いてデータを定義します。カスタムクエリだけでなく、リレーションシップや認可ルールを持つデータモデルを定義することが可能です。データへのアクセスは生成 AI アプリケーションにとって非常に重要なので、生成 AI Tool がアクセスできるデータもこのデータスキーマで定義できます。 LLM Tool を使って、外部APIからデータをフェッチし、そのAPIの上に会話型検索を追加できるカスタムクエリを定義する方法を見てみましょう。 クエリの定義 クエリレスポンスの形を定義することから始めてみましょう。 amplify/data/resource.ts ファイルを開き、スキーマに News という customType を追加します。このカスタムタイプは、タイトル、説明、ニュース記事のソースを含めます。 const schema = a.schema({ News: a.customType({ source: a.float(), title: a.string(), description: a.string() }), //... }) 次に、カスタムクエリを定義します。そのためには、受け取る引数（ API への入力）、返却する値（先ほど定義したカスタム型）、ハンドラー関数（実装）、権限（アクセスできる人）を定義する必要があります。 const schema = a.schema({ //... getNews: a .query() .arguments({ topic: a.string() }) .returns(a.ref("News").array()) .handler(a.handler.function(getNews)) .authorization((allow) => allow.authenticated()). //... }) 次にハンドラ関数を定義しましょう。 defineFunction を使って、 amplify/data/resource.ts ファイルに getNews 関数を定義します。 import { defineFunction, secret } from '@aws-amplify/backend'; export const getNews = defineFunction({ name: "getNews", entry: "./getNews.ts", environment: { NEWSAPI_API_KEY: secret("NEWSAPI_API_KEY"), }, }); API キーは、AWS Systems Manager Parameter Store に保存される Amplify secrets を使用して保存することを推奨します。サンドボックス環境にシークレットを追加するには、以下のコマンドを使用します： npx ampx sandbox secret set NEWSAPI_API_KEY あとは amplify/data/getNews.ts ファイルに getNews 関数を記述するだけです。この例では、 https://newsapi.org/ API を使用して、トピックに関する最新のニュースを取得します。 import { env } from "$amplify/env/getNews"; import type { Schema } from "./resource"; export const handler: Schema["getNews"]["functionHandler"] = async (event) => { const res = await fetch(`https://newsapi.org/v2/everything?q=${encodeURIComponent( event.arguments.topic ?? "" )}&apiKey=${env.NEWSAPI_API_KEY}`); const news = await res.json(); const result = news.articles.slice(0, 3).map((article: any) => ({ source: article.source.name, title: article.title, description: article.description, })); return result; }; これで、トピックを受け取り、最新のニュース記事を取得するカスタムクエリがデータスキーマに定義されました。あとは、このクエリを LLM Tool として使うだけです。そのためには、 a.conversation() を使用して、データスキーマに AI 会話ルートを定義します。使用したい AI モデル、システムプロンプト、アクセスできる Tool を指定します。LLM Tool を定義するには、 a.ai.dataTool を使用し、名前と説明、および先ほど定義したカスタムクエリへの参照を指定します。 const schema = a.schema({ //... chat: a.conversation({ aiModel: a.ai.model("Claude 3.5 Sonnet"), systemPrompt: ` You are a helpful assistant. `, tools: [ a.ai.dataTool({ name: "get_news", description: "Provides the latest news for a given topic.", query: a.ref("getNews"), }), ], }) .authorization((allow) => allow.owner()), }) Amplify sandbox を使用している場合、データリソースファイルを保存すると、変更が個人のクラウドサンドボックスにデプロイされるはずです。または、Amplify コンソールで、Amplify アプリケーションに接続されている git ブランチに変更をプッシュしてデプロイすることもできます。 会話型インターフェースの構築 Amplify クライアントライブラリーと React コンポーネントをインストールします： npm i aws-amplify @aws-amplify/ui-react @aws-amplify/ui-react-ai react-markdown 次に、サンドボックスを使用する際に Amplify が生成する amplify_outputs.json ファイルを使用して Amplify.configure を呼び出すか、Amplify コンソールからファイルをダウンロードして、フロントエンドのコードに Amplify ライブラリが設定されていることを確認してください。 import { Amplify } from 'aws-amplify'; import '@aws-amplify/ui-react/styles.css'; import outputs from '../amplify_outputs.json'; Amplify.configure(outputs); 次に、 useAIConversation React フックを使用して、チャット AI の会話ルートに接続し、メッセージと送信メッセージハンドラを AIConversation React コンポーネントに渡します。会話がユーザーに閲覧されてしまうため、必ず Authenticator コンポーネントでラップしてください。 import { generateClient } from "aws-amplify/api"; import { Authenticator } from '@aws-amplify/ui-react'; import { createAIHooks, AIConversation } from "@aws-amplify/ui-react-ai"; import { Schema } from "../amplify/data/resource"; export const client = generateClient<Schema>({ authMode: "userPool" }); export const { useAIConversation } = createAIHooks(client); function App() { const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation('chat'); return ( <Authenticator> <AIConversation messageRenderer={{ text: ({ text }) => <ReactMarkdown>{text}</ReactMarkdown> }} messages={messages} isLoading={isLoading} handleSendMessage={handleSendMessage} /> </Authenticator> ); } データモデルの取得 また、データスキーマで定義したデータモデルに LLM がアクセスできるようにすることもできます。例えば、メモを取るアプリケーションを作成していて、会話アシスタントにメモだけでなく現在のニュース記事にもアクセスさせたい場合、そのようにすることができます。 まず、データスキーマにデータモデルを追加します： const schema = a.schema({ //... Note: a.model({ title: a.string(), content: a.string() }) .authorization((allow) => [allow.owner()]) //... }); 次に、会話ルートの定義に新しい Tool を追加します： tools: [ //... a.ai.dataTool({ name: 'SearchNotes', description: 'Used to search for notes the user has written', model: a.ref('Note'), modelOperation: 'list' }) ] これで会話アシスタントは、ユーザーが作成したメモや最新のニュース記事を用いた応答ができるようになるでしょう。 クリーンアップ サンドボックスを実行している場合は、ターミナルで以下のコマンドを実行することで、サンドボックスと作成されたすべてのバックエンド環境を削除できます。 npx ampx sandbox delete まとめ このブログ記事では、LLM Tool とは何か、AWS Amplify で外部 API コールや AWS AppSync を使用してデータベースからデータを取得するためにどのように使い方ができるのかを学びました。もっと詳しく知りたい場合は、 AI のスタートガイド を見るか、 サンプルコード を確認してください。 本記事は、 Add a Conversational Interface to any Data Source を翻訳したものです。翻訳は Solutions Architect の 瀬高 が担当しました。

DMM.com は動画配信事業とオンラインゲーム事業、FX 等の金融サービスを主力として、オンライン英会話サービスなど 60 以上のサービスを展開している企業です。DMM.com では、オンプレミスの MySQL で稼働していたユーザーレビュー機能を、Aurora MySQL に移行しています。データの移行は AWS Database Migration Service (DMS) を使用してダウンタイムを最小限に抑えつつ、移行元への逆同期や SageMaker を使用したデータ検証の仕組みなど、様々な工夫をしながら移行を成功させることができました。本ブログでは、DMM.com でオンプレミスの MySQL から Amazon Aurora MySQL へ移行した際に直面した課題やその工夫についてご紹介いたします。 システム概要とデータベースの課題 DMM.com では、DMM TV や DMM ブックスなど様々なサービスを提供しています。そのサービスの多くはユーザーレビュー機能があり、例えば DMM TV では視聴した動画の評価を投稿する際に使われています。このユーザーレビュー機能のサーバーアプリケーションは AWS で稼働していましたが、データベースはオンプレミスの MySQL を採用していました。長年このような構成で運用されていましたが、幾つかの課題を抱えている状況でした。 1. データベースの運用負荷の増加 当該環境では冗長化のために Master High Availability Manager and tools for MySQL (MHA) というクラスタウェアを採用していました。MHA では、2 台のプライマリサーバーと 5 台のセカンダリサーバー、1 台の MHA マネージャーサーバーの合計 8 台でデータベースを冗長化していました。ユーザーレビュー機能は年々多くのシステムから利用されるようになっていて、月間 3 億リクエストを超える状況になっていました。そして、それに伴うスケールアップやスケールアウトなどが頻繁に発生していましたがこのような作業の難易度が高く、準備のために多くの作業工数が必要でした。また、データベースサーバーの障害でフェイルオーバーが発生した時に、スプリットブレインによるデータの不整合が発生するといった事象も出ており、リペア後のパフォーマンス遅延なども発生してしまうなど、エラーへの対処に多くの時間が割かれていました。 2. 旧バージョンによる不具合の発生 ユーザーレビューの機能は 20 年以上オンプレミスで稼働していました。そのため、MySQL のバージョンも 5.6 と古く、保守期限が迫っていました。さらに、テーブルのクラッシュによって読み取りエラーが発生するといった、最新版では改修されているような問題が頻繁に発生していました。 3. リアクティブな障害対応 障害が発生した際に、その障害を検知できないことも課題になっていました。上記のような問題もあり、多い日には 1 日 1 万件以上のアラートが発生していました。そのため、本当に対処が必要なアラートに気づくことができず、事業部や顧客からのクレームや問い合わせによって気づいて対処する、といったリアクティブな対応になってしまっていました。 移行先の検討 これらの課題を改善するために、2023 年 11 月から移行プロジェクトが開始されました。上記の課題が解決できるかどうかはもちろん、可用性やバックトラックなどの独自機能の多さ、DMM.com 社内での実績などを考慮した結果、移行先を Aurora MySQL に決定しました。ただ、Aurora MySQL への移行に向けては、クリアすべき課題がいくつかありました。 1. Aurora MySQL への移行による影響 Aurora MySQL への移行に伴い、MySQL のバージョンを 5.6 から 8.0 にアップグレードする必要がありました。また、MySQL のストレージエンジンを MyISAM から InnoDB に、文字コードを EUC からデフォルトの UTF8 に、タイムゾーンも JST から UTC に変更する必要がありました。 移行による変更箇所 これらの変更点について、多くの時間を使って影響を確認し対処方法を検討していきました。パフォーマンスが劣化するなど影響度が高いクエリについては、一つずつチューニングを実施して対処していきました。また、マージテーブルのような InnoDB では対応していないテーブルに対するクエリも実行されていたため、回避策を検討して修正を進めました。 2. 接続元不明なシステムへの対処 長年この機能を運用していく中で、様々なシステムがこのデータベースにアクセスしている状態でした。この為、Aurora MySQL への移行に合わせて API 化を進める方針でした。どのようなシステムからアクセスしているのかについては、サービス側に協力を依頼してアクセス元を特定していきましたが、アクセス元を全て特定できたかを確認することができず移行時にシステムに影響を与えてしまうリスクがありました。これに対処するため、本番切り替え後に数ヶ月間、 DMS でオンプレミスの MySQL に逆同期を実施することにしました。これにより、Aurora MySQL に移行した後もオンプレミスの MySQL にアクセスしているシステムへの影響を最小限に抑えつつ、アクセス元を特定するような仕組みを構築することができました。 3. データ移行の課題 オンプレミスの MySQL には 3 TB のデータがあり、ダウンタイムを抑えて Aurora MySQL に移行する必要がありました。また、移行後の切り戻しを想定した再同期の仕組みを構築する必要があり、下位互換性の問題から MySQL のレプリケーションが使えなかった為、今回の移行では DMS を採用することになりました。DMS を使って実際のデータ移行をしたところ、絵文字や常用漢字ではない文字など、一部の文字で文字化けする事象が発生したため、対処が必要でした。DMS にはデータ検証という移行元と移行先でデータに差異がないかを検知する機能がありましたが、文字化けした文字自体を修正することはできず、文字化けが発生したレコードも大量であったため、DMS のデータ検証機能の採用は現実的ではありませんでした。このような課題を解消する方法を検討した結果、Amazon SageMaker Notebook を採用しました。具体的には、オンプレミスの MySQL から新環境の Aurora MySQL へ、データを DMS のフルロード + CDC で移行していますが、この DMS フルロードタスクの停止後に SageMaker Notebook の Jupyter Notebook から両データベースのレコードを検証する仕組みを実装しました。この仕組みでは、それぞれのデータベースのレコードを pandas のデータフレームに格納して結合し、レコード単位でそれぞれのレビューテキストのハッシュ値を生成して比較します。不一致がある場合には必要に応じて移行元、もしくは移行先のレビューテキストを更新します。その際に修正の内容を差分リストとして記録し、それ以降の更新で利用します。最初に既存データで検証と修正を行い、その後 Python スクリプトに変換して SageMaker Notebook で定期実行できるようにしました。これにより、新たに発生する差異に対して継続的なチェックを実施しました。長期間運用することでほとんどの文字化けを修正することができ、実際の移行時には文字化けの問題がほとんど発生しないレベルで移行することができる状態になりました。 データベース移行とその効果 このような課題に対応しつつ、アプリケーションやデータ移行の入念なテストを実施した後、2024 年 3 月に本番移行を実施しました。DMS による差分同期により、ダウンタイムがほとんど発生しない状態で切り替えられました。移行後に SQL のパフォーマンス問題はありましたがチューニングを実施して対処し、結果として大きな問題はなく移行を完了しました。現在も安定した運用を実現できています。 そして、今回の Aurora MySQL への移行で得た効果は以下の 3 つでした。 1. データベースの運用負荷の低減 Aurora MySQL への移行後、オンプレミスで発生していたスケールアップ時の作業工数がほぼなくなり、スケールアップまでのリードタイムも大きく改善しました。また、オンプレミスで発生していたデータベースサーバーの障害も発生しなくなりました。その結果、多い日には 1 日 1 万件以上発生していた API のエラーやタイムアウトエラーによるアラートが、ほぼゼロになるまで減少しました。 2. サービス品質の向上 アラート数が激減したことにより、事業部や顧客からの指摘で気づくようなこともなくなり、エラーに対してプロアクティブに対応できるようになりました。また、老朽化したサーバーからの移行ということもあり、パフォーマンスも劇的に向上しました。API レイテンシーは全体で 50%、最も利用頻度の高い 3 つの API では最大 70% の改善が見られ、レビュー投稿が遅いといったクレームがなくなりました。 3. コスト削減 オンプレミスでは、8 台のデータベースサーバーで運用していましたが、Aurora MySQL への移行後は最終的に 3 台構成となりました。移行直後は、安定稼働を優先して Aurora MySQL を6 台で構成していましたが、Performance Insights などを使用してチューニングしたり、負荷が増加した時に Auto Scaling でスケールアウトする仕組みを採用して最適化を進めました。これにより、より少ない台数での稼働が可能になり、移行前の想定より 96% のコスト削減を実現できました (Reserved Instanceの採用も含む)。 一方で、Aurora MySQL の課題として、アップグレード時のダウンタイムをあげていました。今後、Aurora MySQL のバージョンのアップグレードに向けて、ダウンタイムを削減するアップグレード方式を検討していくとのことでした。 最後に DMM.com では、Aurora MySQL への移行によって、コスト削減とサービス品質の向上を同時に実現することができました。 今回の移行の効果について、合同会社 DMM .com プラットフォーム第一開発部ユーザーレビューグループの松井氏、室木氏は、以下のように振り返っています。 “オンプレミス時代では、1 日 1 万件のエラーが発生していて、休日に呼び出されることもあり、常に不安で心理的な負担が大きくなっていました。しかし、Aurora MySQL に移行したことでそのようなストレスがなくなりました。技術的な問題が解消されたことで、サービスの安定性が大幅に向上し、運用面での負担が軽減されました。” (松井氏) “Aurora MySQL への移行後、「レビュー投稿が遅い、できない」といった技術的な問い合わせがなくなり、UI や書き込み内容のようなサービスそのものの問い合わせが増えるという状況に変わりました。技術的な足かせがなくなったことで、サービス拡張や新しいチャレンジにリソースを向けられるようになったことが、移行による大きなメリットです。” (室木氏) 今後については、Aurora MySQL 移行でできた時間を使って、AI を活用してユーザーレビュー機能のサービス品質向上を進めていく予定とのことでした。

このブログは 2022 年 6 月 20 日に Sean Phuphanich（Principal Solutions Architect）、Adam Cerini（Principal Solutions Architect）、Henry Axelrod（Tech Lead for the Storage Partner Segment）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 金融業界特集の月刊連載における今回の投稿では、 Amazon FSx for NetApp ONTAP （FSx for ONTAP）でワークロードを実行するお客様がコンプライアンス、データ保護、コンピューティング環境の分離、API による監査、アクセス制御/セキュリティを実現するための 5 つの重要な考慮事項 に焦点を当てています。それぞれの領域において、具体的なガイダンス、推奨されるリファレンスアーキテクチャ、および FSx for ONTAP のサービス承認を効率化するための技術的なコードについて検討します。 FSx for ONTAP は、NetApp ONTAP 上に構築されたフルマネージドファイルストレージサービスで、信頼性が高く、スケーラブルで、パフォーマンスに優れた共有ストレージを提供します。また、SMB、NFS、iSCSI をサポートする AWS で利用できる最初のマルチプロトコルファイルサービスでもあります。フルマネージドサービスであるため、ファイルサーバーとストレージボリュームのセットアップとプロビジョニング、データのレプリケーション、ソフトウェアのインストールとパッチ適用、ハードウェア障害の検出と対処、フェイルオーバーとフェイルバックの管理、手動でのバックアップの実行について心配する必要がなくなります。 FSx for ONTAP は、クラウドおよびハイブリッドクラウドのシナリオで幅広いユースケースに対応し、それぞれの環境に合わせてカスタマイズすることで最適化できます。例えば、FSx for ONTAP はミリ秒未満のレイテンシが実現できる高性能 SSD ストレージを提供しており、Oracle、SAP、VMware、Microsoft SQL Server に適した高性能ストレージとして活用できます。FSx for ONTAP は、事実上無制限で低コストストレージを提供する、伸縮自在なキャパシティプール層を使用して、一般的な NAS ベースのワークロードのコストを最適化することもできます。 FSx for ONTAP は他の NetApp 製品とネイティブに連携し、ハイブリッドクラウドアーキテクチャで重要な役割を果たすことができます。インラインデータ圧縮、重複排除、コンパクション、シンプロビジョニング、レプリケーション（ SnapMirror ）、ポイントインタイムクローニング（ FlexClone ）など、データ管理をより安価かつ容易にする追加機能も用意されています。オンプレミスとクラウドで既存の技術スタックを維持したいお客様は、 VMware Cloud と FSx for ONTAP を組み合わせることで、移行、ディザスタリカバリ、クラウドバーストなどのユースケースを迅速に実装できます。FSx for ONTAP は、他の AWS サービスである AWS Identity and Access Management（IAM）、 Amazon WorkSpaces 、 Amazon Key Management Service（KMS） 、 AWS CloudTrail 、および Amazon Elastic Compute Cloud（EC2）、Amazon Elastic Container Service（ECS）、Amazon Kubernetes Service（EKS）といった一般的なコンピューティングサービスとの豊富な統合も備えています。 Amazon FSx for NetApp ONTAP によるコンプライアンスの達成 マネージドサービスである Amazon FSx シリーズの基準により、コンプライアンスの達成が容易になります。コンプライアンス基準を完全に満たすには、お客様は自身の環境を設定し維持する責任があります。セキュリティとコンプライアンスは、AWS とお客様の間で 共有される責任 です。マネージドサービスではない NetApp Cloud Volumes ONTAP を導入する場合と比較すると、コンプライアンスに準拠した安全なファイルシステムを導入するために必要なお客様の負担は少なくなります。お客様は、環境とサービスを適切に設定するために、ネットワーク接続、暗号化、アクセス制御の要件を決定する必要があります。この記事では、お客様の責任の一部であるセキュリティ設定に関する追加のガイダンスを提供します。 AWS の サービスコンプライアンスページ には、Amazon FSx が承認されているすべてのコンプライアンスプログラムが掲載されています。金融業界の読者に向けた短いリストとして、Amazon FSx のコンプライアンスには次のものが含まれます。 SOC 1,2,3 PCI ISO/IEC 27001:2013, 27017:2015, 27018:2019, and ISO/IEC 9001:2015 OSPAR FINMA IRAP データ保護 保管中の暗号化 FSx for ONTAP では、 保管中のデータの暗号化 がデフォルトで有効になっており、保管時のデータとメタデータには AES-256 暗号化アルゴリズムが使用されます。データはディスクに書き込まれる前に自動的に暗号化され、読み取られるときに自動的に復号されます。暗号化キーは、 AWS KMS を使用して管理され、FSx for ONTAP と統合されます。AWS の暗号化キー管理インフラストラクチャは、連邦情報処理標準規格（FIPS）140-2 承認の暗号化アルゴリズムを使用します。インフラストラクチャは、米国立標準技術研究所（NIST）800-57 の推奨事項に準拠しています。 図1: ファイルシステム作成時に暗号化キーを選択する 図 1 に示すように、ファイルシステムを設定するとき、保管中の暗号化に使用されるデフォルトの AWS KMS キーがあらかじめ選択されています。代わりに、 独自の AWS KMS キー を指定することもできます。オンプレミスで使用される NetApp Volume Encryption（NVE）は、クラウドで保存するときには必要ありません。 転送中の暗号化 FSx for ONTAP がどのように通信し、どのような目的で通信するかを理解することは、すべての転送プロトコルを安全に保護する上で重要です。SMB、NFS、iSCSI はファイルアクセス用にクライアントによって使用されます。HTTPS は AWS Console、AWS API、ONTAP REST API で使用されます。SSH は ONTAP CLI への管理アクセスに使用されます。 図 2: FSx for ONTAP マルチ AZ アーキテクチャ 図 2 は、ファイルシステムが AWS アベイラビリティーゾーン（AZ）にまたがる様子を示しています。高可用性とノードペア間のデータレプリケーションをサポートするために使用されるノード間通信では、TLS 1.2 が使用されます。クラスタ間通信は、TLS または IPSEC を使用して構成できます（パフォーマンスのためには TLS が推奨されます）。 エンドユーザーからのファイル共有アクセスでは、NFS は暗号化や認証はデフォルトでは有効ではありません。転送中の暗号化は SMB プロトコル 3.0 以降でサポートされていますが、SMB 共有と SMB 暗号化はデフォルトでは無効です。SMB 共有を有効にするには、「 Amazon FSx for NetApp ONTAP でマルチプロトコルワークロードを有効にする 」の記事をご覧ください。有効にすると、FSx for ONTAP は、ファイルシステムにアクセスするときに、SMB 暗号化を使用して転送中のデータを自動的に暗号化します。SMB 暗号化は、個々の共有で有効にすることも、ストレージ仮想マシン（SVM）で有効にすることもできます。SVM で有効にすると、その SVM のすべての共有で有効になります。FSx for ONTAP は 128 または 256 ビットの暗号化をサポートしていますが、使用する暗号化のレベルはクライアントによって決まります。 SMB 暗号化を有効にする詳細な手順については、 ユーザーガイド をご覧ください。 （注意: SVM 名「fsx」は、最初に自動作成された SVM のデフォルト名であり、この記事全体のコードサンプルで「-vserver」引数として使用されます。必要に応じて、「fsx」を SVM の名前に置き換えることができます。） ONTAP CLI: SVM のすべての共有に対して SMB 暗号化を有効にする vserver cifs security modify -vserver fsx -is-smb-encryption-required true ONTAP は SMB 署名を使用して、ストレージシステムとクライアント間のトラフィックが反射攻撃や中間者攻撃によって侵害されないようにすることで、データファブリックを保護します。これは、SMB メッセージに有効な署名があることを確認することで実現します。この機能はデフォルトでは有効になっていませんが、以下の ONTAP CLI コマンドを使用して有効にすることができます。 ONTAP CLI: vserver cifs security modify -vserver fsx -kerberos-clock-skew 3 - kerberos-ticket-age 8 -is-signing-required true FSx for ONTAP では、デフォルトで複数のバージョンの SMB と NFS が有効になっています（SMB 2 と 3、NFS 3 と 4）。ONTAP CLI を使用して、不要なバージョンを無効にすることができます。 ONTAP CLI: smb 1、smb 2、nfs3、nfs 4 を無効化する set -privilege advanced vserver cifs options modify -vserver fsx -smb1-enabled false vserver cifs options modify -vserver fsx -smb2-enabled false vserver nfs modify -vserver fsx -v3 disabled vserver nfs modify -vserver fsx -v4 disabled ウイルス対策 一括保護が必要なお客様のために、FSx for ONTAP は NetApp ウイルススキャン機能である Vscan をサポートしています。Symantec、Mcafee、または Trend Micro から追加購入したパートナーのウイルス対策アプリケーションと組み合わせることで、FSx for ONTAP は、ファイルシステムに書き込まれる新しいファイルを自動的にスキャンできます。Vscan に使用されるウイルス対策ソフトウェアは、別途購入して導入します。詳細については、 Vscan の NetApp ドキュメント を参照してください。 コンピューティング環境の分離 ファイルシステムは、Amazon Virtual Private Cloud（VPC）およびサブネット内にデプロイされた FSx for ONTAP（オンプレミスの ONTAP クラスタに対応）のプライマリリソースです。各ファイルシステムには、ONTAP CLI または ONTAP REST API を使用してデータを管理できる管理エンドポイントと、レプリケーションまたはキャッシュ設定用のクラスタ間エンドポイントがあります。各ファイルシステムには VM によって強制される分離境界があり、別のファイルシステムとリソースを共有しません。 図 3 に示すように、SVM は、データの管理とアクセスのための独自の管理認証情報とネットワークエンドポイントを備えた、論理的に分離されたファイルサーバーです。AWS Console を使用してファイルシステムを作成すると、「fsx」という名前のデフォルトの SVM が作成されます。各 SVM には、固有の認証情報とネットワークアクセス制御があります。SVM には最大 4 つのネットワークエンドポイント があり、3 つはデータにアクセスするためのエンドポイント（NFS、SMB、および iSCSI）、1 つは SVM を管理するためのエンドポイントです。 図3: FSx for ONTAP エンドポイントと分離境界 ネットワークアクセス制御のために、AWS セキュリティグループ と Network Access Control Lists が SVM エンドポイントとサブネットに設定されます。セキュリティグループは、FSx for ONTAP ファイルシステムの仮想ファイアウォールとして機能し、受信トラフィックと送信トラフィックを制御します。FSx for ONTAP はさまざまな機能を設定できるため、ユースケースごとに使用するポートを確認し、必要に応じて有効にする必要があります。次のリストには、基本設定に必要な一般的なポートが含まれていますが、ポートの完全なリストは こちら で確認できます。 Protocol Ports Role All ICMP All Pinging the instance SSH 22 SSH access to Management endpoint TCP 443 ONTAP REST API access to Management endpoint TCP 445 Microsoft SMB/CIFS over TCP TCP 635 NFS mount TCP 749 Kerberos TCP 2049 NFS server daemon TCP 3260 iSCSI access TCP 2049 NFS server daemon View more ピアリングネットワークからのアクセス FSx for ONTAP では SVM は、Amazon VPC 内に 4 つのエンドポイントを公開します。 シングル AZ モード を使用する場合、すべてのエンドポイント IP は、展開先のサブネットと同じ CIDR（ クラスレスドメイン間ルーティング ）内にあります。マルチ AZ モードを使用する場合、管理、NFS、および SMB エンドポイントは、Amazon VPC CIDR 外のフローティング IP 範囲（デフォルトでは 198.18.0.0/16）を使用します。Amazon VPC 外からこれらのエンドポイントに接続するクライアントは、推移的ルーティングをサポートする接続方法を使用する必要があります。これには、AWS Transit Gateway（TGW）と AWS VPN の両方が含まれます。これらの IP アドレスは、図 4 に示すように、SVM のコンソールビューで確認できます。 図4: SVM の固定 IP とフローティング IP エンドポイント iSCSI エンドポイントとファイルシステムのクラスタ間エンドポイントは、Amazon VPC CIDR 範囲内の IP アドレスを使用します。つまり、これらのユースケースでは、推移的ルーティングが可能な方法に加えて、Amazon VPC ピアリングなどの非推移的な接続方法も使用できます。図 5 は、Amazon FSx ファイルシステムをオンプレミスの NetApp デバイスと同期するための一般的なパターンを示しています。 図 5: FSx for ONTAP とオンプレミスの NetApp ボリュームの同期 クラスタ間エンドポイントは、クロスリージョンレプリケーション、FlexCache、または GlobalFileCache にも利用できます。 API による監査の自動化 FSx for ONTAP には、考慮すべき 3 種類の監査証跡があります: Amazon FSx の管理 API コール ONTAP CLI コマンド エンドユーザーのファイル共有アクセス Amazon FSx の管理 API コール AWS CloudTrail は、Amazon FSx への API リクエストをログに記録できるサービスです。ボリューム、SVM、またはファイル システムの削除などの管理イベントを追跡するのに役立ちます。AWS CloudTrail はファイルまたはフォルダレベルのイベントを追跡できません。 AWS CloudTrail の設定方法の詳細 をご覧ください。 監視する主要な API には、 CreateFileSystem および DeleteFileSystem があります。 以下は CreateFileSystem に関する AWS CloudTrail ログエントリの例です。異なる Amazon FSx ファイルシステムにも同じ API が使用されることに注意してください。この場合、属性「 fileSystemType 」は is ONTAP です。 { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAAAAABBBBAAAABBBBA:example", "arn": "arn:aws:sts::121212121212:assumed-role/example", "accountId": "327468301555", "accessKeyId": "ASIAAAAABBBBAAAABBBBA", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAAAAAABBBBAAAABBBBA", "arn": "arn:aws:iam::121212121212:role/example", "accountId": "121212121212", "userName": "example" }, "webIdFederationData": {}, "attributes": { "creationDate": "2022-03-15T13:35:49Z", "mfaAuthenticated": "true" } } }, "eventTime": "2022-03-15T14:26:58Z", "eventSource": "fsx.amazonaws.com", "eventName": "CreateFileSystem", "awsRegion": "us-east-2", "sourceIPAddress": "AWS Internal", "userAgent": "AWS Internal", "requestParameters": { "clientRequestToken": "f9c77684-0394-111d-a23e-12121212", "fileSystemType": "ONTAP", "storageCapacity": 1024, "subnetIds": [ "subnet-0101example", "subnet-0101example" ], "securityGroupIds": [ "sg-0101example", "sg-0101example" ], "kmsKeyId": "arn:aws:kms:us-east-2:121212121212:key/4ccexex-example", "ontapConfiguration": { "automaticBackupRetentionDays": 7, "deploymentType": "MULTI_AZ_1", "diskIopsConfiguration": { "mode": "AUTOMATIC" }, "preferredSubnetId": " subnet-0101example ", "routeTableIds": [ "rtb-0101example" ], "throughputCapacity": 128 } }, "responseElements": { "fileSystem": { "ownerId": "121212121212", "creationTime": "Mar 15, 2022 2:26:57 PM", "fileSystemId": "fs-1212example", "fileSystemType": "ONTAP", "lifecycle": "CREATING", "storageCapacity": 1024, "storageType": "SSD", "vpcId": "vpc-0101example", "subnetIds": [ "subnet-0101example", "subnet-0101example" ], "kmsKeyId": "arn:aws:kms:us-east-2:121212121212:key/4ccexex-example ", "resourceARN": "arn:aws:fsx:us-east-2:121212121212:file-system/ fs-1212example", "ontapConfiguration": { "automaticBackupRetentionDays": 7, "dailyAutomaticBackupStartTime": "05:00", "deploymentType": "MULTI_AZ_1", "endpointIpAddressRange": "198.19.255.0/24", "endpoints": { "intercluster": { "dNSName": "intercluster.fs-1212example.fsx.us-east-2.amazonaws.com" }, "management": { "dNSName": "management.fs-1212example.fsx.us-east-2.amazonaws.com" } }, "diskIopsConfiguration": { "mode": "AUTOMATIC", "iops": 3072 }, "preferredSubnetId": "subnet-0101example", "routeTableIds": [ "rtb-0101example" ], "throughputCapacity": 128, "weeklyMaintenanceStartTime": "4:04:00" } } }, "requestID": "d32e1da5-848e-4d44-84b4-d58b7121212", "eventID": "659358ca-1ba7-482c-8f96-40cc7121212", "readOnly": false, "eventType": "AwsApiCall", "apiVersion": "2018-03-01", "managementEvent": true, "recipientAccountId": "121212121212", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ONTAP CLI コマンド ONTAP CLI コマンドに関するログはデフォルトで有効になっています。ファイルシステムまたは SVM の管理エンドポイントに ssh でログインすると、ONTAP CLI コマンドが利用できます。ONTAP CLI コマンドに関する監査ログは SVM ごとに保存されます。履歴は、コマンド「security audit log show」を使用して表示できます。FSx for ONTAP は、セキュリティ監査ログエントリに基づいて自動的に監視および警告することはできないため、ログデータをそれらの機能を備えたシステムに転送する必要があります。ONTAP は、監査ログを syslog をサポートする任意の宛先に転送することで、既存のセキュリティ情報およびイベント管理（SIEM）システムと統合できます。ログ転送プロセスと、ログ転送中の TLS 暗号化を有効にする方法については、 NetApp のドキュメント をご覧ください。 以下のセキュリティ監査ログの例には、アクセスタスクと操作タスクの両方の監査エントリが含まれます。 エンドユーザーのファイル共有アクセス FSx for ONTAP は、ファイルやディレクトリへのエンドユーザーアクセスなどのイベントを 追跡してログに記録する機能 を備えているため、ファイルアクセス監査要件をサポートします。これはデフォルトでは有効になっていません。ログに記録できるイベントの例としては、ログインの成功または失敗、ファイルアクセスの読み取り/書き込み、権限の変更などがあります。SMB アクセスと NFS アクセスには異なるイベントがあります。SVM で 監査設定を作成 し、SVM で有効にする必要があります。イベントログは、EVTX または XML 形式でファイルシステムの特別なフォルダに保存されます。ログは、Windows イベントビューアで表示できます。 ONTAP CLI の次のコマンドは、SVM である「fsx」上にローテーションログを作成します。ローテーションログファイルはサイズが 200 MB に到達したらローテーションされます。最大 10 世代まで保存され、古いファイルから上書きされます。ログのステージングスペースは 2 GB に制限されているため、ローテーションを有効にすることが重要です。 ONTAP CLI: ログローテーションによるファイルアクセス監査ログの設定 vserver audit create -vserver fsx -destination /audit_log -rotate-limit 9 -rotate-size 200M vserver audit enable -vserver fsx これらのファイルアクセス監査ログはローカルに保存され、セキュリティ監査ログのように syslog サーバーに転送することはできません。ただし、この記事では取り扱いませんが、追加のツールを使用してログ記録ソリューションを構築することもできます。 図6: ログ記録ソリューションのシステムアーキテクチャ ブログ記事「 アプリケーションのログファイルを第三者と安全に共有する方法 」では、図 6 に示すソリューションについて説明しています。これは、ログのアーカイブ、通知、ログ管理プラットフォームへの取り込みなどの一般的なユースケースに役立ちます。 運用アクセスとセキュリティ FSx for ONTAP の認証と認可のメカニズムを理解することは、アクセスセキュリティの管理に役立ちます。 Amazon FSx サービス AWS Console –（AWS IAM） Amazon FSx API –（AWS IAM） FSx for ONTAP ファイルシステム 管理エンドポイント –（SSH） クラスタ間エンドポイント –（事前共有されたパスワード FSx for ONTAP SVM 管理エンドポイント –（SSH） ファイルアクセスエンドポイント –（Kerberos） iSCSI エンドポイント –（なし） AWS Console と Amazon FSx API は、バックアップ、ファイルシステムの作成または削除、SVM 管理者パスワードのリセットなどの管理タスクに使用されます。 FSx for ONTAP ファイルシステムのサービスアカウント（NetApp 用語ではクラスタ管理者）には、ファイル システム内のすべての SVM を管理するアクセス権があります。fsxadmin アカウントのパスワードは変更できます。 Amazon FSx ファイルシステム内の分離されたファイルサーバーである SVM には、独自の管理者権限情報があります。SVM 管理エンドポイントは、ONTAP CLI と ONTAP REST API をサポートしています。SVM 管理者は、自身の SVM 内でのみ権限を持ちます。 SMB 共有の場合、ユーザーの認証と認可には Microsoft Active Directory を使用します。詳細については、 FSx for ONTAP での Microsoft Active Directory の操作 に関するドキュメントを参照してください。 まとめ この記事では、FSx for ONTAP について、コンプライアンスの達成、データ保護、コンピューティング環境の分離、API による監査の自動化、アクセス制御/セキュリティという 5 つのカテゴリで金融業界のお客様がサービスの承認を迅速化するために役立つ情報を紹介しました。 オンプレミスの NetApp のお客様が AWS に移行するのに役立つ 移行計画および戦略ガイド があります。その他の Amazon FSx for NetApp ONTAP に関するブログはすべて こちら でご覧いただけます。 AWS Industries ブログチャンネル にアクセスして、金融業界のニュースやベストプラクティスを引き続きご覧ください。 <!-- '"` --> TAGS: Financial Services , Financial Services Industry Service Spotlight Series Sean Phuphanich Sean は、AWS の Principal Solutions Architect で、セキュアでスケーラブルなハイブリッドクラウドソリューションに取り組んでいます。Sean はソフトウェア開発と IT リーダーシップのバックグラウンドを持ち、大規模で複雑なワークロードを世界中で簡素化および最適化する支援をしています。 Adam Cerini Adam は、Amazon Web Services の Principal Solutions Architect です。公共部門のお客様がスケーラブルでセキュアかつコスト効率の高いシステムを設計できるよう支援することに重点を置いています。余暇には料理を楽しんだり、ボードゲームを熱心に楽しんだりしています。 Henry Axelrod Henry Axelrod は、AWS の Partner Solutions Architect 兼 Tech Lead for the Storage Partner Segment です。さまざまな役割を担い、さまざまなストレージおよびバックアップテクノロジーを管理してきた 20 年以上の業界経験があります。AWS に入社する直前、Henry は国際的な M&amp;E 企業でストレージチームを率い、数 PB の大規模なストレージ環境を管理していました。

このブログは “ Healthcare and Life Sciences: Top 10 announcements from AWS re:Invent 2024 ” を翻訳したものです。 技術的なブレークスルーを実現するには、目的に応じたツール、戦略的イノベーション、そして業界固有の課題に対する深い理解が、綿密に統合される必要があります。AWS re:Invent 2024 では、ヘルスケア・ライフサイエンス業界のお客様が、生成 AI と機械学習 (ML) の最新のイノベーションにより、医学研究、患者ケア、科学的発見へのアプローチ方法をどのように変えることができるかを探りました。また、re:Invent 前の数週間において、創薬研究、ヘルスケアデータ管理、患者体験に関する下記の HCLS サービスの新機能を発表しました。 AWS HealthOmics タンパク質言語モデル (pLM) オーケストレーション、コールキャッシュ、中間ファイルアクセスを発表しました。pLM 機能により、医薬品開発、酵素エンジニアリング、バイオセンサー開発などのアプリケーションにおけるタンパク質エンジニアリングの取り組みが効率化されます。コールキャッシュと中間ファイルアクセスが連携することで、反復的な開発サイクルが大幅に改善され、処理時間が短縮されます。 AWS HealthImaging ホールスライドイメージング、超音波、循環器など、非可逆圧縮の画像モダリティをサポート。これにより、HealthImaging DICOMデータストアでサポートされているX線、CT、MRI画像などのモダリティが拡張されました。この強化により、HealthImagingは、ペタバイト規模で医療画像を保存、分析、共有できる幅広いソフトウェアアプリケーションを実現できます。 AWS HealthLake 医療機関やライフサイエンス企業は患者データを規制対応しながら簡単に管理できます。HealthLake は、FHIR バージョン管理、eu-west-2 リージョンへのリージョナルサポートの拡大、そしてより多くの医療システムフレームワークのサポートなどの新機能により、ヘルスケアデータを正確かつ最新の状態に保ち、必要な人がアクセスできるように支援します。 医薬品開発の加速や治療プロトコルの個別化から、臨床ワークフロー改善や予測診断まで、その可能性は計り知れません。この可能性を実現するには、最先端のテクノロジーとヘルスケアイノベーションの厳しい要求を橋渡しする、包括的で責任あるアプローチが必要です。これを念頭に置いて、 ヘルスケア・ライフサイエンス業界のお客様にとって重要な AWS re:Invent の新発表トップ 10 をご紹介します。 Amazon Nova Amazon Nova は、 最先端のインテリジェンスと業界をリードするコストパフォーマンス を提供する最先端の 基盤モデル （FM）シリーズで、Amazon Bedrock でのみご利用いただけます。医療機関やライフサイエンス企業は Amazon Nova を使用して、複雑な研究論文、企業内文書、図表の分析など、多くの 生成 AI タスクのコストと応答時間を削減できます。ユーザーは、企業のワークロードに最適化されたさまざまなインテリジェンスクラスから高度な AI エージェントを構築できます。Nova モデルファミリーには Amazon Nova Micro、Amazon Nova Lite、および Amazon Nova Pro が含まれており、テキスト、画像、または動画の入力に対してテキスト出力を生成するモデルです。( 発表 ) Amazon Bedrock Amazon Bedrock は、生成 AI アプリケーションの構築とデプロイをさらに簡単にする新機能により、ヘルスケア・ライフサイエンス業界のお客様が AI アプリケーションを構築して重要なインサイトを引き出すのに役立ちます。 Model Distillation は、教師モデルと呼ばれる大規模な基盤モデル (FM) から応答を生成し、生成された応答を使用して生徒モデルと呼ばれる小規模な FM をファインチューニングすることで、特定のユースケースに合わせた抽出モデルを作成するプロセスを自動化します。これにより、ユースケースに合わせて、教師モデルに近い精度で、より高速で費用対効果の高いモデルが得られます。( 発表 ) Amazon Bedrock Guardrails の自動推論チェックを使用すると、大規模言語モデル (LLM) によって生成された応答の正確さを数学的に検証し、ハルシネーションを防ぐことができます。( 発表 ) Amazon Bedrockのマルチエージェントコラボレーションにより、開発者は複数の専用エージェントをシームレスに構築、デプロイ、管理して、より複雑なマルチステップのワークフローに取り組むことができます。プラットフォームはカスタムオーケストレーションをサポートし、開発者は計画と実行、思考過程、標準運用手順などの特殊な戦略を実装して、より制御された効率的なタスク実行が可能になります。( 発表 ) Amazon Bedrock Marketplace では、生成 AI 開発者が、業界をリードする Amazon Bedrock のサーバーレスモデルに加えて、100 を超える公開されている独自の基盤モデル (FM) にアクセスできます。( 発表 ) プロンプトキャッシュは、頻繁に使用されるプロンプトを複数の API 呼び出しにわたってキャッシュすることで、サポート対象モデルのコストを最大 90% 削減し、レイテンシーを最大 85% 削減できる新機能です。( 発表 ) Amazon Bedrock Data Automation (BDA) を使用すると、開発者は開発時間と労力を削減しながら、インテリジェントなドキュメント処理、メディア分析、その他のマルチモーダルデータ中心の自動化ソリューションを簡単に構築できます。BDAには、説明しやすくするための信頼スコアの可視化や、組み込みのハルシネーション緩和機能などの機能があります。( 発表 ) Amazon SageMaker Amazon SageMaker には、データ探索、準備と統合、ビッグデータ処理、高速 SQL 分析、機械学習 (ML) モデルの開発と学習、生成 AI アプリケーション開発に必要なコンポーネントがほぼすべて含まれるようになりました。新機能には以下が含まれます。 Amazon SageMaker Unified Studio (プレビュー) — データ分析と AI のためのすべてのデータとツールを単一の環境で構築 Amazon SageMaker HyperPod flexible training plans — 予測可能なモデルトレーニングのタイムラインを確保し、予算要件の範囲内でトレーニングワークロードを実行 データサイロの解消 — Amazon SageMaker Lakehouse を使用して、 Amazon Simple Storage Service (Amazon S3) データレイク、 Amazon Redshift データウェアハウス、サードパーティデータソースのデータを統合 データと AI ガバナンス — Amazon DataZone 上に構築された Amazon SageMaker Catalog を使用して、データと AI を安全に探索、管理、共有 データ処理 — Amazon Athena 、 Amazon EMR 、 AWS Glue のオープンソースフレームワークを使用して、分析と AI のためのデータを探索、準備、統合 モデル開発 — Amazon SageMaker AI でフルマネージド型のインフラストラクチャ、ツール、ワークフローを使用して ML と基盤モデル (FM) を構築、学習、デプロイ 生成 AI アプリケーション開発 — Amazon Bedrock を使用して生成 AI アプリケーションを構築、スケーリング SQL 分析 — 最もコストパフォーマンスに優れた SQL エンジンである Amazon Redshift でインサイトを獲得 Amazon Q Developer ソフトウェアを構築、運用、移行するための 最も有能な生成AI搭載アシスタント が、さらに改良され、さらに使いやすくなりました。 Amazon Q Developer Agentは、お客様の知識ベースを理解、拡張するために、アプリケーション資産を自律的に分類、整理し、統合的なコードドキュメントを作成します。( 発表 ) SageMaker Canvas 内の Amazon Q Developer は、ヘルスケア・ライフサイエンスのユーザーが ML の専門知識を持っていなくても、自然言語による対話を通じて正確で実用品質の ML モデルを構築できるよう支援します。Amazon Q Developer は、こうしたユーザーのビジネス上の問題に基づいてデータを分析し、カスタム ML モデルを構築するためのステップバイステップのガイダンスを提案します。( 発表 ) Amazon DataZone ヘルスケア・ライフサイエンスのお客様にとって有益な新機能として、 Amazon DataZone では データリネージ 機能の一般提供を開始しました。データリネージ機能では、AWS Glue と Amazon Redshift からの履歴が自動的に取得されるため、ユーザーはソースから利用までのデータ移動を可視化できます。時間の経過に伴うデータ変換を追跡し、資産の履歴全体の変化を比較できるため、包括的な監査と検証が可能になります。メタデータ適用ルールの新機能により、ヘルスケア・ライフサイエンスのお客様はメタデータ標準に準拠し、研究、臨床、パートナーなどの間で HIPAA に対応したデータ共有が可能になります。( 発表 ) AWS Security Incident Response AWS Security Incident Response は、セキュリティイベントへの準備、対応、復旧を支援する新しいサービスです。このサービスでは、日常的なタスクから要員を解放するための、セキュリティ結果の自動モニタリングと調査、対応調整を合理化するためのコミュニケーションおよびコラボレーション機能、 AWS Customer Incident Response Team (CIRT) への 24 時間の直接アクセスを提供します。( 発表 ) Amazon EC2 Trn2 Amazon Elastic Compute Cloud (Amazon EC2) Trn2 instances と AWS Trainium2 チップを搭載した Trn2 UltraServers のプレビューが GA になりました。 EC2 キャパシティブロック 経由で利用可能な Trn2 インスタンスと UltraServer は、ディープラーニングと生成 AI トレーニングおよび推論のための最も強力な EC2 コンピューティングソリューションです。ライフサイエンスおよび医療の研究機関は、Trn2 インスタンスを使用して、新しい生物学基盤モデルやヘルスケアに特化したLLMを学習およびデプロイできます。( 発表 ) Amazon Kendra GenAI Index Amazon Kendra GenAI Index は Amazon Kendra の新しいインデックスで、RAG とインテリジェント検索向けに設計されており、デジタルアシスタントとインテリジェント検索エクスペリエンスをより効率的かつ効果的に構築するのに役立ちます。このインデックスは、高度なセマンティックモデルと最新の情報検索テクノロジーを使用して高い検索精度を実現し、 Amazon Bedrock ナレッジベース や Amazon Q Business と統合できます。また、お客様はナレッジベースをガードレール、プロンプトフロー、エージェントなどの他のBedrockサービスと統合して、高度な生成AIアプリケーションを構築することもできます。( 発表 ) Amazon S3 Amazon S3 の機能強化には次のものが含まれます。 Amazon S3 Tables は、Apache Iceberg サポートが組み込まれた初めてのクラウドオブジェクトストアであり、表形式のデータを大規模に保存する最も簡単な方法です。S3 テーブルは分析ワークロード専用に最適化されているため、セルフマネージドテーブルと比較して、クエリのスループットが最大 3 倍速く、1 秒あたりのトランザクション数が最大 10 倍多くなります。これにより、データレイクが拡大および進化しても、継続的にテーブルメンテナンスを実行してクエリ効率とストレージコストを時間の経過とともに自動的に最適化することで、オペレーションオーバーヘッドが削減されます。米国東部 (バージニア北部)、米国東部 (オハイオ)、および米国西部 (オレゴン) リージョンでご利用いただけます。( 発表 ) Amazon S3 Metadata は、ほぼリアルタイムで更新される自動化され簡単にクエリできるメタデータにより、S3 データを即座に探索して理解するのに役立つ新しい方法です。S3 メタデータは、オブジェクトのサイズやソースなどのシステム定義の詳細を含むオブジェクトメタデータと、組織が品質スコア、サンプル ID、実験 ID などの情報を非構造化 R&amp;D データに付与できるカスタムメタデータをサポートしています。( 発表 ) AWS Transfer Family に、認証されたユーザーがコードなしのインターフェイスでS3バケット内のファイルを簡単に管理できるウェブアプリが含まれるようになりました。これにより、デスクトップクライアントや技術的な専門知識を必要とせずに、研究機関、CRO、そして製薬企業の研究者間でシームレスなファイル交換が可能になります。( 発表 ) Amazon DynamoDB Global Tables 現在プレビュー段階にある Amazon DynamoDB global tables は、マルチリージョンの強い一貫性をサポートしています。DynamoDB グローバルテーブルは、何万ものお客様が使用するフルマネージド型のサーバーレスマルチリージョンマルチアクティブデータベースです。この新機能により、グローバルな製薬企業は、目標復旧時点（RPO）がゼロの高可用性マルチリージョンアプリケーションを構築できるようになり、最高レベルのレジリエンスを実現できるようになります。( 発表 ) ブレイクアウトセッションのオンデマンド動画 HCLS Innovation Talk : Accelerating healthcare &amp; life sciences innovation with generative AI (feat. Genentech, Merck, Eli Lilly, Pieces Tech, and Cleveland Clinic) （生成 AI によるヘルスケアとライフサイエンスのイノベーションの加速） ヘルスケア セッション HLS208 | Accelerate healthcare innovation: TriZetto’s data-powered approach （ヘルスケアイノベーションを加速：TriZetto のデータ活用型アプローチ） HLS214 | Froedtert Health transforms patient engagement with generative AI （Froedtert Health 生成 AI で患者エンゲージメントを変革） HLS207 | Geisinger’s Epic journey: Scaling EHR operations on AWS （Geisinger の壮大な道のり：AWS での EHR オペレーションのスケーリング） HLS220 | Creating powerful member experiences: Cigna’s AWS HealthLake journey （パワフルなメンバーエクスペリエンスの創造:Cigna の AWS HealthLake ジャーニー） NTA310 | HIPAA-compliant IVD SaaS: Werfen’s global AWS solution journey （HIPAA 対応の IVD SaaS：Werfen のグローバル AWS ソリューションジャーニー） IDE104 | Inclusive wellness: Leveraging Amazon One Medical for LGBTQIA+ care （インクルーシブ・ウェルネス：アマゾン・ワン・メディカルを LGBTQIA+ のケアに活用） MKT104 | Transform healthcare outcomes with AWS Marketplace (feat. Fred Hutch Cancer Research Center ) （AWS マーケットプレイスで医療成果を変革） SEC224-S | Data security in the cloud, from Xsolis , an AI leader in healthcare （ヘルスケアの AI リーダーである Xsolis が提供する、クラウド内のデータセキュリティ） ARC212-S | How Cambia supercharged their Amazon EKS based platform （Cambia が Amazon EKS ベースのプラットフォームをどのように強化したか） CEN201-S | Cigna’s sales and client onboarding transformation journey （Cigna のセールスおよびクライアントオンボーディングの変革への道のり） ライフサイエンス セッション HLS215 | How Merck improves drug design with biological foundation models （Merck が生物学的基盤モデルを使用して医薬品設計を改善する方法） HLS206 | Scale clinical diagnostic operations: Natera’s genomic innovation （大規模な臨床診断業務：Natera のゲノムイノベーション） PRO302 | Gilead Sciences : Operational excellence for cloud, data, and AI/ML （Gilead Sciences：クラウド、データ、AI/ML のオペレーショナル・エクセレンス） MAM214 | Gilead Science s: Executing a large-scale VMware transformation on AWS （Gilead Sciences：AWS での大規模な VMware トランスフォーメーションの実行） BIZ220 | How Moderna Is building a healthier supply chain （Moderna 社がより健全なサプライチェーンを構築する方法） PRO203 | Merck advances healthcare data extraction using text-to-SQL on AWS （Merck、AWS で text-to-SQL 変換で医療データ抽出を推進） HYB201 | AWS wherever you need it: From the cloud to the edge (feat. Merck ) （AWS をどこでも必要な場所で:クラウドからエッジまで） CMP203 | Drive innovation and results with high performance computing on AWS (feat. Merck ) （AWS でのハイパフォーマンスコンピューティングによるイノベーションと成果の促進） 今年、ラスベガスで開催された re:Invent でたくさんの素晴らしい発表がありました。私たちの業界がこの新しいテクノロジーで何を構築できるかを楽しみにしています。ヘルスケア・ライフサイエンスのお客様が AWS でどのようにブレークスルーを実現しているかについて詳しくは、 https://aws.amazon.com/health をご覧ください。 <!-- '"` --> Oiendrilla Das Oiendrilla Das は、AWS のライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリーダーです。彼女はライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。Oiendrillaは、マーケティングのMBA学位を取得しており、MBAを取得する前にバイオテクノロジーのエンジニアリングを修了しました。 Jennifer Rouse Jennifer Rouse は AWS のヘルスケアマーケティングのワールドワイドヘッドです。IBMやCiscoなどの大企業や、2つのクラウドベースのスタートアップで指導的役割を果たしてきました。直近では、Forrester Research/Sirius Decisionsのグローバルアナリスト兼アドバイザーを務めました。Jennifer は、公共部門など、これまでサービスが行き届いていなかった業界で変化をもたらす企業でキャリアの多くを過ごしてきました。 Lee Tessler Lee Tessler, Ph.D. は AWS のヘルスケアおよびライフサイエンス業界のプリンシパルテクノロジーストラテジストです。研究開発、臨床試験、製造、患者エンゲージメントを最新化するためのクラウドアーキテクチャに重点を置いています。AWS に入社する前は、バイオインフォマティクス、創薬、診断、ラボ機器、医薬品製造の分野で製品を提供していました。Leeは、セントルイスのワシントン大学で計算生物学の博士号を、ブラウン大学で理学士号を取得しています。 このブログは、Senior Solutions Architect, HCLS の松永が翻訳しました。

こんにちは、Amazon Connect ソリューションアーキテクトの坂田です。 みなさん、 re:Invent 2024 はご参加（現地、あるいはオンライン）頂けましたでしょうか？今回も、たくさんのアップデートが発表されましたね。イベントの後にも複数のアップデートが追加されており、2024年12月はいつにも増して盛りだくさんでした。 今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートについて 2024年12月のアップデート一覧 AWS Contact Center Blog のご紹介 1. 注目のアップデートとブログについて 注目#1: Amazon Connect の Amazon Q in Connect エージェントアシスタンスで 64 言語のサポートを開始 Amazon Q in Connect で、エージェントアシスタンス機能で 日本語を含む64 の言語がサポートされるようになりました。エージェントは、Amazon Q in Connect と母国語でチャットしてアシスタンスを利用でき、Amazon Q は回答、ナレッジ記事へのリンク、推奨されるステップバイステップガイドを各国語で提供します。新たにサポートされる言語には、中国語、フランス語、フランス語 (カナダ)、イタリア語、日本語、韓国語、マレー語、ポルトガル語、スペイン語、スウェーデン語、タガログ語が含まれます。ただし、会話内容に基づくナレッジの自動推奨は英語のみのサポートです。 Amazon Q in Connect を英語以外の言語で利用するためには、あらかじめロケールを設定する必要があります。日本語ロケールの設定手順の流れは以下の通りです。 利用する Amazon Connect インスタンスで Amazon Q in Connect を有効にし、ナレッジベース（統合）を作成 しておく。 以下のコマンドで、対象となる assistant-id を取得する。 aws qconnect list-assistants ロケールを指定して、AI エージェントを作成する。 aws qconnect create-ai-agent \ --assistant-id &lt;assistant-id&gt; \ --name jp_manual_search_ai_agent \ --visibility-status PUBLISHED \ --type MANUAL_SEARCH \ --configuration '{"manualSearchAIAgentConfiguration": {"locale": "ja_JP"}}' AI エージェントバーションを作成する。（ai-agent-id は上のコマンドの出力で確認する aws qconnect create-ai-agent-version \ --assistant-id &lt;assistant-id&gt; \ --ai-agent-id &lt;ai-agent-id&gt; 作成したAI エージェントバージョンを適用する。 aws qconnect update-assistant-ai-agent \ --assistant-id &lt;assistant-id&gt; \ --ai-agent-type MANUAL_SEARCH \ --configuration '{ "aiAgentId": "&lt;ai-agent-id&gt;:1" }' 以上で Amazon Q in Connect でのマニュアル検索における日本語ロケールが設定できました。詳細な手順は 管理者ガイド をご確認ください。 注目#2: Amazon Connect が Amazon Q in Connect で生成 AI を活用したセルフサービスを開始 Amazon Connect のチャットあるいは音声チャネルにおいて、Amazon Q in Connect を利用したセルフサービスを簡単に提供できるようになりました。これにより、Amazon Q in Connect はセルフサービスシナリオにおいてそのナレッジベースに基づいて、顧客へのQA対応、ステップバイステップガイドを利用した推奨アクションの提示、スケジュールの変更などを実行することができます。 Amazon Q in Connect を利用したセルフサービスを構築するための手順は以下の通りです。 利用する Amazon Connect インスタンスで Amazon Q in Connect を有効にし、ナレッジベース（統合）を作成 しておく。 Amazon Connect の管理者ウェブサイトから Lex ボットを作成し、Amazon Q in Connect インテントを有効にする。 利用するフローで Amazon Q in Connect を有効にし、作成した Lex ボットを呼び出す。 最低限の設定は以上です。なお、2025年1月16日時点では selfServiceAIAgentConfiguration は locale の指定をサポートしていません。そのため、Amazon Q in Connect インテントで英語以外の言語を利用するには、 セルフサービスプロンプト(SELF_SERVICE_PRE_PROCESSING と SELF_SERVICE_ANSWER_GENERATION) を特定の言語で応答するようにカスタマイズ する必要があります。詳細については、管理者ガイドの Customize Amazon Q in Connect をご確認ください。 2. 2024年12月のアップデート一覧 Amazon Connect でルーティング時に特定の習熟度を除外する機能を提供 – 2024/12/24 Amazon Connect ではコンタクトをエージェントに割り当てる際のエージェントセレクション基準として、”エージェント習熟度（スキルレベル）”を利用することができます。今回のアップデートにより、特定の習熟度をもつエージェントをコンタクトルーティングの対象から除外することができるようになりました。これを利用して、数は少ないが重要な問い合わせに対応することができるエージェントを空けておくことができます。 習熟度の除外条件（NOT 条件）をルーティング基準として利用するには、 Lambda 関数を使ってルーティング基準を動的に設定 する必要があります。 関連リンク 管理者ガイド Amazon Connect で特定の範囲の習熟度を備えたエージェントへのルーティングのサポートを開始 – 2024/12/24 Amazon Connect におけるコンタクトルーティングの基準として、エージェントの習熟レベルの 範囲 をターゲットに指定できるようになりました。例えば、フランス語の「レベル 1 から 3」をターゲットにする、 などです。それぞれの問い合わせを適切なスキルレベルのエージェントに確実にマッチングできるため、コンタクトを割り当てるまでの時間を最適化できます。 関連リンク 管理者ガイド Amazon Connect がチャット内で組み込みのお客様認証機能の提供を開始 – 2024/12/21 Amazon Connect のチャットに、お客様認証の機能が組み込まれました。これにより、チャット対話においてお客様の身元確認を行い、本人情報に基づくパーソナライズされたサービスを提供することが容易になります。 「顧客を認証」フローブロック を使用することで、チャットのワークフローで簡単に認証を行うことができます。例えば、認証されていないお客様がエージェントの支援を必要とする場合には、エージェントにコンタクトする前にサインインするためのポップアップが表示されるので、エージェントはよりパーソナライズされた効率的なサポートを提供できます。 この機能の利用を開始するには、AWS コンソールから Amazon Connect &gt; [顧客認証] ページにアクセスして、 ID プロバイダーを構成してください。その後、Amazon Connect の管理者ワークスペースで、チャットで使用するコンタクトフローに「顧客を認証」ブロックを追加してください。 関連リンク 管理者ガイド Amazon Connect が管理ウェブサイトからのキューとルーティングプロファイルの削除のサポートを開始 – 2024/12/21 不要になったキューやルーティングプロファイルを、これまでサポートされていた API ベースの削除に加えて、直接 Amazon Connect の管理者ワークスペースから削除できるようになりました。 関連リンク 管理者ガイド Amazon Connect がエージェントステータスの構成のための AWS CloudTrail のサポートを開始 – 2024/12/21 Amazon Connect で、エージェントステータスのページに対して加えられたすべての変更が AWS CloudTrail のイベントとして記録されるようになりました。これにより、AWS CloudTrail を調べて、エージェントステータスの追加、更新、無効化を行った管理ウェブサイトユーザーを特定できます。 関連リンク CloudTrail イベント履歴でのイベントの表示 Amazon Connect でエージェント階層構成インターフェイスが改善され AWS CloudTrail のサポートを開始 – 2024/12/21 Amazon Connect で、管理ウェブサイトで階層を構成する UI が一新され、複雑な組織構造をすばやく正確にナビゲートできるように改善されました。階層とは、レポートを作成する目的でエージェントをチームやグループにまとめる手法です (部門別、場所別、知識や技能別など)。この改善でお客様はツリー構造を視覚化し、全文先行入力検索を使用してリソースを検索できるようになりました。 また、新しい UI での変更は、AWS CloudTrail を利用して追跡することができるようになりました。階層のグループや構造へのすべての変更を、変更者や変更方法にかかわらずログに記録したり、参照したり、監査したりできるようになります。 Amazon Connect の Amazon Q in Connect エージェントアシスタンスで 64 言語のサポートを開始 – 2024/12/20 Amazon Connect 上ですぐに使える、生成 AI を活用したアシスタント機能の Amazon Q in Connect が日本語対応しました！ Amazon Q in Connect のエージェントアシスタンス機能において、日本語を含む 64 の言語が新たにサポートされるようになりました。これにより、エージェントは Amazon Q in Connect に日本語で質問し回答を得ることができます。Amazon Q in Connect は、回答、ナレッジ記事へのリンク、推奨されるステップバイステップガイドをそれぞれの言語で提供します。 新たにサポートされる言語には、中国語、フランス語、フランス語 (カナダ)、イタリア語、日本語、韓国語、マレー語、ポルトガル語、スペイン語、スウェーデン語、タガログ語が含まれます。サポートされている言語の全一覧については、 Amazon Connect 機能でサポートされている言語 をご覧ください。 Amazon Q in Connect で日本語を利用するには、CLI または API から 言語ロケールを変更 する必要があります。 なお、2025年1月16日時点では、日本語で利用できる Amazon Q in Connect の機能は”マニュアル検索”となります。会話の内容に基づくナレッジの自動推奨は英語のみのサポートとなります。 関連リンク 管理者ガイド Amazon Connect でマルチパーティチャットのサポートを開始 – 2024/12/20 Amazon Connect でマルチパーティチャットがサポートされるようになりました。これにより、最大 4 人のエージェントが進行中のチャットの会話に参加できるようになり、コラボレーションと顧客の問題の迅速な解決が容易になります。たとえば、エージェントはスーパーバイザーや対象分野の専門家にチャットに参加してもらい、顧客が正確でタイムリーなサポートを受けられるようにすることができます。 関連リンク 管理者ガイド Amazon Connect タスクが最大 30 日間の期間をサポート – 2024/12/19 Amazon Connect タスクは作成から最大 30 日で有効期限が切れるように設定できるようになりました。デフォルトは 7 日間です。 たとえば、毎月の経費通知などの緊急度の低いタスクは上司にエスカレーションされるまで最大 30 日間アクティブに保たれ、顧客エスカレーションなどの緊急タスクは 1 分後に上司に送信できるようになりました。 関連リンク 管理者ガイド Amazon Connect が分析データレイクでエージェントのスケジュールデータの提供を開始 – 2024/12/18 Amazon Connect の分析データレイクで、公開されたスケジュールデータを提供するようになりました。これにより、このデータからレポートやインサイトを簡単に生成できるようになります。 例えば、分析データレイク内のエージェントのスケジュールデータから、給与計算の有給時間と無給時間に関するレポートの生成、特定の期間で勤務がスケジュールされているエージェントの数と休暇をとるエージェントの数の概要ビューの生成など、主要な運用ユースケースを自動化できます。また、過去 2 年間ですべてのエージェントについてスケジュールされているすべてのイベントの詳細レポートの生成など、監査とコンプライアンスのユースケースにも対応できます。 これらのレポートやインサイトを生成するには、Amazon Athena と Amazon QuickSight または他の任意のビジネスインテリジェンスツールを使用できます。 関連リンク Amazon Connect エージェントのスケジューリングの詳細については、 こちら をクリックしてください。 Amazon Connect 分析データレイクの詳細については、 こちら をクリックしてください。 Amazon Connect で営業時間の休日のオーバーライドをサポート – 2024/12/13 Amazon Connect のオペレーション時間を「オーバーライド」できるようになりました。これを使用して、コンタクトセンターの特別休日やその他の営業時間を設定できるようになりました。 オーバーライドは、コンタクトセンターの標準曜日営業時間の例外です。たとえば、コンタクトセンターが午前 9 時に開店、午後 10 時に閉店するが、大晦日にはエージェントがお祝いに間に合うように午後 4 時に閉店したい場合、そのためのオーバーライドを追加できます。休暇が近づいてコンタクトセンターを早期に閉鎖すると、電話をかけてきた人は営業時間外のカスタマーエクスペリエンスを得ることができます。 関連リンク 管理者ガイド Amazon Connect がモバイルチャット用のプッシュ通知のサポートを開始 – 2024/12/12 Amazon Connect は、iOS および Android デバイスでのモバイルチャットのプッシュ通知をサポートするようになりました。これにより、カスタマーエクスペリエンスが向上し、より迅速な問題解決が可能になります。 Amazon Connect Chat SDK を使用するモバイルチャットエクスペリエンス向けに組み込みのプッシュ通知が利用可能になったため、顧客が積極的にチャットをしていない場合でも、エージェントやチャットボットから新しいメッセージを受信するとすぐにプロアクティブに通知されます。 なお、 Web チャットではブラウザ通知が利用できます 。 関連リンク 管理者ガイド Amazon Lex が新しい多言語音声認識モデルを発表 – 2024/12/11 Amazon Lex で新しい多言語ストリーミング音声認識モデル (ASR-2.0) の一般提供が開始されました。これらのモデルは、ポルトガル語、カタロニア語、フランス語、イタリア語、ドイツ語、スペイン語をサポートする欧州ベースのモデルと、中国語、韓国語、日本語をサポートするアジアパシフィックベースのモデルという 2 つの特殊なグループによって認識精度を向上させます。 これらの Amazon Lex 多言語ストリーミングモデルは、各グループで共有されている言語パターンを利用して、認識精度を向上させます。これらのモデルは特に英数字の認識に優れているため、発信者の識別や自動音声応答 (IVR) アプリケーションでのタスクの自動化にしばしば必要となる顧客の発話を正確に理解しやすくなります。たとえば、新しいモデルでは、アカウント番号、確認番号、シリアル番号、製品コードをより正確に認識できます。 これらのモデルは現在 Amazon Lex でサポートされている言語の標準となっており、お客様は既存のボットをリビルドするだけでこれらの機能強化を利用できます。新しい ASR-2.0 モデルは Amazon Lex V2 をサポートするすべてのリージョンで利用できます。 re:Invent 2024期間中のアップデートは以下の通りです。 こちら も合わせてご覧ください。 Amazon Connect が WhatsApp Business メッセージングのサポートを開始 – 2024/12/02 Amazon Connect Contact Lens がエージェントのパフォーマンス評価を生成 AI を使用して自動化 – 2024/12/02 Amazon Connect が Amazon Q in Connect で生成 AI を活用したセルフサービスを開始 – 2024/12/02 Amazon Connect では、チャット内で重要な顧客データを簡単に収集できるようになりました – 2024/12/02 Amazon Connect が外部音声の転送をサポート – 2024/12/02 Amazon Connect Contact Lens が会話型 AI ボットのパフォーマンスを分析するための組み込みダッシュボードをリリース – 2024/12/02 AWS が Amazon Connect での Salesforce Contact Center を発表 (プレビュー) – 2024/12/02 Amazon Connect が新しい日中予測ダッシュボードを発表 – 2024/12/02 Amazon Connect Contact Lens が生成 AI を使用してコンタクトを自動的に分類 – 2024/12/02 Amazon Connect が Amazon Q in Connect の AI ガードレールを発表 – 2024/12/02 Amazon Connect Contact Lens が外部音声のサポートを開始 – 2024/12/02 Amazon Connect がシンプルな会話型 AI ボットの作成を提供 – 2024/12/02 Amazon Connect が顧客セグメントとトリガーベースのキャンペーン向けの AI アシスタントをリリース – 2024/12/02 Amazon Connect で IVR およびその他の自動対話中の音声が録音可能に – 2024/12/01 3. AWS Contact Center Blog のご紹介 Revolutionise CX in your contact centre through IVR modernisation （英語記事） AWS re:Invent 2024 recap: Amazon Connect の新しいアナウンス （日本語翻訳） Elevate your contact center: AI-powered analytics with Amazon Connect （英語記事） Amazon Connect で実現する生成 AI を活用したセルフサービスの簡素化 （日本語翻訳） Amazon Connect チャットによる機密情報の収集 （日本語翻訳） Amazon Connect が生成 AI、WhatsApp、セキュアなデータ収集機能を強化 （日本語翻訳） Amazon Connect でさらにサステナブルなコンタクトセンターを実現 （日本語翻訳） 今月のお知らせは以上です。2024年もたくさんのアップデートが発表されましたが、これらは利用者の皆さんからのフィードバックに基づいています。今後も皆さんのコンタクトセンター変革に役立つ改善を続けられるよう、ぜひフィードバックやアイデアを我々に教えてください。それでは、本年もどうぞよろしくお願いいたします！ シニア Amazon Connect ソリューションアーキテクト 坂田 陽一郎

2024 年 2 月、弊社はメキシコで Amazon Web Services (AWS) インフラストラクチャを拡張する計画を 発表 しました。1 月 14 日、3 つのアベイラビリティーゾーンと API コード mx-central-1 を備えた AWS メキシコ (中部) リージョンの一般提供が開始されたことをお知らせいたします。この新しい AWS リージョン は、メキシコで最初の AWS インフラストラクチャリージョンで、中南米における当社の存在感をさらに高めるものです。 メキシコの AWS リージョンは、同国のデジタルの未来に対する大きなコミットメントを示しています。AWS は、15 年間でメキシコに 50 億ドル以上を投資する予定です。この AWS リージョンは、メキシコで成長を遂げるデジタル経済を支援すると同時に、専用のプロセッサを備えた最先端の人工知能 (AI) や機械学習 (ML) 機能など、高度で安全なクラウドテクノロジーをお客様に提供します。この取り組みにより、AWS はメキシコで年間平均 7,000 件を超えるフルタイム相当の雇用をサポートし、メキシコの国内総生産 (GDP) を 100 億ドル以上増加させます。また、AWS は地域のグループ、学校、組織による新しいコミュニティプロジェクトの開始を支援するために、30 万ドルの AWS InCommunities 基金をケレタロで立ち上げました。 メキシコシティ、パラシオデベラスアルテス AWS メキシコ (中部) リージョンは、ワークロードを実行してデータをローカルに保存する新しいオプションを、メキシコの組織に提供します。データレジデンシー機能、低レイテンシーによるパフォーマンスの向上、または強固なセキュリティ標準を必要とする組織は、メキシコにあるインフラストラクチャを利用できるようになりました。 メキシコの AWS AWS は 2020 年以降、メキシコでインフラストラクチャを運用してきました。インフラストラクチャには、7 つの Amazon CloudFront エッジロケーション、 AWS Outposts 、 ケレタロの AWS Local Zones や AWS Direct Connect などの戦略的サービスが含まれています。これらのインフラストラクチャサービスは、お客様が安全な接続を維持しながら低レイテンシのアプリケーションを実行するのに役立ちます。 パフォーマンスとイノベーション AWS メキシコ (中部) リージョンは、AWS のインフラストラクチャとサービスを地域のお客様に近づけます。この新しいリージョンにより、メキシコのお客様は、他の AWS リージョンを使用する場合と比較して、レイテンシーを削減することができます。また、さまざまなワークロードで、x86 ベースの Amazon EC2 インスタンスと比較して最大 40% 優れた価格パフォーマンスを実現する AWS Graviton をはじめとする当社の革新的な専用プロセッサも利用できるようになります。 この技術的優位性は、次のような当社の最先端の AI および ML 機能にも及びます。 AWS Trainium と AWS Inferentia を備えた高度な ML インフラストラクチャによる、スケーラブルな生成 AI デプロイ。 クラウドワークロード向けに最適化された専用プロセッサが実現する、最高のコストパフォーマンス。 セキュリティとコンプライアンス AWS は PCI-DSS 、 HIPAA / HITECH 、 FedRAMP 、 GDPR 、 FIPS 140-2 、 NIST 800-171 を含む 143 のセキュリティ標準とコンプライアンス認証をサポートする、 包括的なセキュリティ機能 を提供しています。AWS のすべてのお客様はデータを所有し、保存場所を選択して、データを移動するかどうか、またはいつ移動するかを決定します。つまり、AWS メキシコ (中部) リージョンにコンテンツを保存しているお客様は、移行を選択しない限り、コンテンツがメキシコから流出しないという保証を受けることができます。 メキシコの AWS のお客様 メキシコの主要な組織は、すでに AWS で大きな成果を上げています。 Aeroméxico 、 Banco Santander Mexico 、 Cinépolis 、 Grupo Salinas 、 Kavak 、 Palace Resorts 、 Vector Casa de Bolsa などの企業が、AWS でミッションクリティカルなワークロードを実行しています。主な例を次に示します。 大手多国籍金融サービス企業である BBVA は、AWS を使用してデータ主導型の変革を加速しています。BBVA は Amazon SageMaker と Amazon Bedrock を使用して、1,000 人以上のデータサイエンティストが機械学習モデルを効率的に構築、トレーニング、デプロイできるよう支援しています。このテクノロジーは、BBVA による高度なテクノロジーの探求と、革新的な金融ソリューションの構築を実現し、真のデータおよび AI 主導のデジタル組織になるという同社の目標を支援しています。 メキシコの大手メディアグループである Grupo Multimedios は、自社の メディアアセットマネージャー (MAM) に Amazon Bedrock を導入して、コンテンツ調査時間を 88% を削減し、ニュース生成時間を 40% 短縮し、コンテンツ制作を 70% 増加 (1 日あたりニュース記事が 250 件増加) させることで、生成 AI の活用をいち早く進めています。テクノロジー面でのリーダーシップを活用し、急成長を遂げているメディアグループである同社の AI 導入は、業務を合理化しながらイノベーションに取り組む姿勢を示しています。 デジタルヘルスケア企業の Bowhead Health は、Amazon Bedrock を使用して研究パイプラインを加速することで、がん研究に革命を起こしています。同社は、従来の採用の障壁なしに、すぐに分析できる匿名化された膨大なデータセットを構築しました。Bowhead Health は、オンコロジー医薬品開発におけるブレークスルーを早めるための確固たる現実世界の知見も提供しています。 SkyAlert は、地震が発生しやすい地域の何百万もの地域を保護する革新的なテクノロジー企業で、2018 年に AWS に移行して警報システムを変革しました。AWS を採用する前、同社のシステムには 20 台の仮想マシンが必要で、重大な瞬間に大幅な遅延が発生していました。 AWS Lambda 、 AWS Fargate 、 Amazon Pinpoint を使用することで、自動的にスケーリングし、ユーザーにすばやくメッセージを配信できるようになりました。AWS メキシコ (中部) リージョンの開設により、SkyAlert はローカル AWS インフラストラクチャを使用したサービスのさらなる改善を見込んでいます。 SkyAlert の Co-Founder である Santiago Cantú 氏 は次のように説明しています。「メキシコでの AWS リージョンの開設は、SkyAlert にとっても、私たちを信頼してくださるお客様の安全にとっても非常に重要な出来事です。ローカルの AWS インフラストラクチャを持つことで、命を救う可能性のある重要なアラートを配信する能力が向上し、さらに迅速かつ確実に配信を行えるようになります。これは、最も堅牢で高度な地震速報システムを提供するという私たちの使命と完全に一致しています。新しいリージョンにより、AWS のサービスをさらに活用できるようになり、災害対策におけるイノベーションの最前線に立ち続けることが保証されます」 ともにスキルを構築 AWS はメキシコでのスキルアップの取り組みに、多額の投資を行ってきました。これには次が含まれます。 2017 年以降、500,000 人以上にクラウドテクノロジーに関するトレーニングを実施。 経済省 と協力し、2024 年までに 138,000 人にデジタルテクノロジーのトレーニングを実施。 パンアメリカーナ大学 や モンテレイ工科大学 などの大学と提携してデジタルスキルを教える。 2 万人の中堅・中小企業 (SMB) リーダーを対象とした Canacintra のトレーニングプログラム。 持続可能性に向けた AWS の取り組み Amazon は、2040 年までに事業全体で正味ゼロ炭素を達成することを約束しています。 Accenture による最近の調査 では、AWS でワークロードを実行すると、オンプレミス環境と比較してエネルギー効率が最大 4.1 倍向上することが示されています。AWS でワークロードを最適化すると、関連する二酸化炭素排出量を最大 99% 削減できます。AWS メキシコ (中部) リージョンでは、空冷技術を使用して持続可能な設計手法を採用しているため、運用時に冷却水を使用する必要がありません。この新しいリージョンにより、お客様はインフラストラクチャ全体にわたる AWS の持続可能性への取り組みからも恩恵を受けることができます。AWS の持続可能性の詳細については、 AWS クラウドの持続可能性ページ をご覧ください。 知っておくべきこと メキシコの AWS コミュニティ – メキシコの AWS コミュニティはラテンアメリカで最も活気のあるコミュニティの 1 つで、 26 人以上の AWS コミュニティビルダー が存在し、15 の AWS ユーザーグループ があります。これらのグループは、 ハリスコ 、プエブラ、 モンテレイ 、メリダ、 メキシコシティ 、メヒカリ、カンクン、レオン、 ケレタロ 、サンルイスポトシ、 エンセナーダ 、 サルティーヨ 、ティファナ、 ビヤエルモサ にあります。さらに、女性のプロフェッショナル育成に焦点を当てた Embajadoras cloud (クラウドアンバサダー) と呼ばれる専門ユーザーグループもあります。これらのグループを合わせると、メンバーは合計 9,000 人以上となります。 AWS のグローバルフットプリント – この立ち上げに伴い、AWS の事業活動の場は、世界各地の 36 の地理的リージョンにおける 114 のアベイラビリティーゾーンに広がりました。 今すぐ利用可能 – 新しい AWS メキシコ (中部) リージョンでは、お客様のビジネスをサポートする準備が整いました。このリージョンで利用できるサービスの詳細なリストは、「 リージョン別の AWS サービス 」ページに記載されています。 mx-central-1 での構築を開始するには、「 AWS グローバルインフラストラクチャ 」ページをご覧ください。 AWS コミュニティメキシコ 2024 の写真を提供してくださった David Victoria 氏に感謝します。 – Eli 原文は こちら です。

AWS ジャパンでは、お客様の生成 AI 活用促進のため様々な支援を提供しています。有志により開発されているオープンソースのサンプルアセット generative-ai-use-cases-jp (GenU) もその一つです。GenU は、すぐに業務活用できる生成 AI ユースケース集として 2023 年に誕生し、今日まで Amazon Bedrock の新機能追従や新たなユースケースの拡充など、精力的なアップデートを継続しています。本記事では、2024 年 11 月に GenU の新たな機能としてリリースされた、ノーコードの生成 AI アプリ開発環境「ユースケースビルダー」についてご紹介します。 GenU とは generative-ai-use-cases-jp (GenU) は aws-samples で公開されている生成 AI アプリケーションのサンプル実装です。オープンソースライセンスで提供されており、お客様はアプリケーションを無料で迅速に AWS アカウント上に構築いただけます※1。AWS や IT の知識不要で、 簡単に展開できる方法 が用意されており、すぐに利用開始することが可能です。アプリケーションは AWS のサーバーレスサービスを中心に構築されており、使った分だけの従量課金で小さく始め、数千人規模の全社展開にも設定変更なく対応可能です。提供開始から 1 年あまりで、多数の日本のお客様にプライベートな生成 AI 活用基盤としてご利用いただいています。GenU についての詳細は github リポジトリ をご参照ください。 ※1 ご利用状況に応じた AWS 利用料が別途発生いたします。詳細は 料金試算 をご参照ください。 ユースケースビルダーとは GenU には一般的な AI チャットのみならず、要約、翻訳、校正などの基本的な生成 AI のユースケースが標準で用意されています。一方、お客様からは自社の業務に特化したユースケースの追加を望まれる声をいただいていました。GenU はオープンソースライセンスで提供されており、お客様により自由な改造を行うことができます。しかし、改造のためにはフロントエンドフレームワーク React の知識等が必要であり、敷居が高いという課題がありました。そこで、シンプルなプロンプトのみでのカスタムユースケース構築機能を「ユースケースビルダー」として新たに提供開始しました。 ユースケースビルダーでは、プロンプト内に 2 つの中括弧 {{}} によるプレースホルダを使って、ノーコードで利用者向けのインプットフォームを作成することができます。現状では、自由記述のテキストフォームとファイル添付に対応しており、Kendra や Knowledge Base など、GenU で対応しているデータソースと連携することも可能です。また、今後のアップデートで利用できる入力フォームの種類は拡張される予定です。ユースケースビルダーには豊富なサンプルユースケースも用意されています。まずはサンプルを見るだけでも、生成 AI を活用した独自アプリのイメージが湧くのではないかと思います。 ユースケースビルダーの利用例 実際にユースケースビルダーで独自ユースケースの作成を行ってみましょう。(1) まず、GenU の初期ページから「ビルダーモード」のスイッチを有効化してユースケースビルダーを利用開始し、(2) 新規作成ボタンをクリックします。 ユースケース新規作成画面にて、「タイトル」「概要」「プロンプトテンプレート」を設定します。「タイトル」と「概要」は生成には影響しません。利用者が内容をイメージしやすいものをご自由に入力してください。「プロンプトテンプレート」に記載した内容が、実行時に生成 AI に入力されます。テンプレート内に {{text:入力}} のようにプレースホルダを記載すると、右側のプレビュー画面に対応するテキストボックスが出現します。アプリ実行時、利用者がテキストボックスに記載した内容がプレースホルダを置き換えます。プロンプトテンプレートの作成時には、用意されているサンプルプロンプトや、AWS ドキュメントの プロンプトエンジニアリングの概念 などを参照し、モデルのパフォーマンスを最適化するプロンプトの作成を心がけましょう。 図の通り、初めてのアプリとして、テキスト中の表形式データをcsvに変換して抽出するユースケースを作成できました。作成したユースケースは、画面右側のプレビュー欄ですぐに試すことができます。動作確認のため、Wikipedia から 国民の祝日 の一節を入力し、祝日一覧を csv 形式で出力してみます。すると、意図通り説明文が省略され、表部分のデータのみを csv 形式で抜き出すことができました。 アプリが狙い通りに動作したら、詳細設定を行いましょう。入力例を追加してユーザーに利用方法を伝えたり、利用する大規模言語モデルを固定してコストや応答速度を最適化し、生成 AI に不慣れなユーザーにも使いやすいアプリにすることができます。また、一部モデルでは添付ファイルのアップロードに対応しており、画像や動画を入力するマルチモーダル推論や、PDF などの読み込みを行うことも可能です。 設定が終わったら、ユースケースの作成ボタンをクリックし、設定内容を保存しましょう。作成したカスタムユースケースは同じ GenU にログインできる利用者間で共有できます。便利なユースケースが作成できたら社内で共有することで、部門や会社全体での生成 AI 活用促進に役立てることができます。 さいごに 本記事では、オープンソースの生成 AI サンプルアセット GenU に新たに追加された「ユースケースビルダー」について紹介しました。生成 AI チャットだけではなく、自社の業務内容に沿った生成 AI アプリを簡単に作成し、社内で共有する手段として、GenU を活用いただけます。ぜひお試しください。GenU は AWS ジャパン有志を中心に、オープンソースプロジェクトとして開発が行われています。利用者の皆様からの貢献も歓迎しております。こんな機能がほしい、というアイディアがありましたら、ぜひ github リポジトリ の Issues や Pull Request の投稿をいただけますと幸いです。 著者について 岡本 晋太朗 (Shintaro Okamoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 石化プラントの計装制御設計エンジニアを経て、プラントデジタルツインソリューションの構築に従事。現在は AWS Japan で製造業のお客様を中心に技術支援を行っています。特技は美味しいご飯を炊くことです。 &nbsp;

本記事は、2024年11月7日に公開された Build a multi-tenant generative AI environment for your enterprise on AWS を翻訳したものです。 企業が 生成 AI の有用なアプリケーションを開発し続けている一方で、チームのサイロ化やワークフローのカスタム化によって展開が遅れることも少なくありません。より迅速に展開するには、企業はしっかりとした運用形態や生成 AI のライフサイクルをシンプルにする包括的なアプローチを必要とします。本シリーズの 第1部 では、さまざまな事業部門が Amazon Bedrock 上の基盤モデルにアクセスできるように、AI の管理者が生成 AI の SaaS (Software as a Service) のゲートウェイを構築する方法を紹介しました。第2部となる今回は、ソリューションを拡張し、共通の生成 AI のコンポーネントを集約することでイノベーションを加速する方法を紹介します。また、アクセスパターン、ガバナンス、責任ある AI、オブザーバビリティ、Retrieval Augmented Generation (RAG) のような一般的なソリューションの構成についても掘り下げていきます。 このソリューションは、 Amazon Bedrock というマネージドサービスを使用し、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった主要な AI 企業が提供する高性能な基盤モデルを、単一の API から選択することができます。また、セキュリティ、プライバシー、責任あるAIを重視した生成 AI のアプリケーションを構築するための幅広い機能も備えています。そして、 Amazon API Gateway 、 AWS Lambda 、 Amazon SageMaker など、多数の AWS サービスも使用しています。 マルチテナント型の生成 AI 環境を AWS で構築 企業が求めるマルチテナント型の生成 AI ソリューションでは、企業ポリシーの遵守、テナントおよびデータの分離、アクセスやコストの管理といったことを担保しながら、生成 AI ワークロードの固有の要件や責任ある AI といったガバナンスに対応していく必要があります。そのため、このようなソリューションの構築は、IT チームにとって負担の大きい取組となることが往々にしてあります。 本記事では、主な設計上の考慮事項について説明し、リファレンスアーキテクチャを紹介します。 素早い試行、統一されたモデルへのアクセス、共通の生成 AI コンポーネントの再利用を可能にすることで、生成 AI の展開を加速します。 テナント毎にユースケースに応じた適切な設計や実装を柔軟に選択できるようにします。 一元化されたガバナンス、ガードレール、そして制御を実装します。 テナント、事業部門、または基盤モデルのプロバイダー毎にモデルの利用やコストの追跡や監査ができるようにします。 ソリューションの概要 ソリューションは2つの部分から構成されています。 生成 AI ゲートウェイ（下図の左側） 事業部門毎等のテナント（下図の右側） 次の図はソリューションの概要を示しています。 生成 AI ゲートウェイ 共有コンポーネントは、生成 AI ゲートウェイの領域に配置されます。共有コンポーネントとは、すべてのテナントで共有される機能のことです。上図の各コンポーネントは、マイクロサービスとして実装され、基本はマルチテナントで、テナント毎の詳細情報は一意のテナント ID で保持されます。一部のコンポーネントは、その機能の種類に基づいてグループに分類されます。 独立したコンポーネントは以下の通りです。 HTTPS エンドポイント (HTTPS endpoint) はゲートウェイへのエントリーポイントです。この HTTPS エンドポイントを介して共有サービスとのやりとりが行われます。ソリューションにおける唯一のエントリーポイントとなります。 オーケストレーター (Orchestrator) は、HTTPS エンドポイントからのリクエストを受け、実行中のタスクに基づいて対応するマイクロサービスを呼び出す役割を担います。これ自体がマイクロサービスであり、マイクロサービスにおける Saga オーケストレーションパターン に由来したものです。 生成 AI プレイグラウンド (Generative AI Playgroud) は、一時的な試行、複数の基盤モデルとのチャット、ガードレールやモデル評価のような機能の探索的な検証のために、テナントに提供されるUIです。 コンポーネントグループは以下の通りです。 コアサービス (Core services) は環境の管理者を主に対象にしたものです。環境の導入、管理、運用に使用されるサービスが含まれています。例えば、テナント、ユーザー、モデルのオンボードとオフボード、各テナントへのクォータの割当、そして認証や認可のマイクロサービスなどです。また、コストや予算の管理、監査、ログ記録などのための監視のコンポーネントも含まれます。 生成 AI モデルコンポーネント (Generative AI model components) には、基礎モデルやカスタムモデルの実行操作のマイクロサービスが含まれます。これらのマイクロサービスは、Amazon Bedrock、Amazon SageMaker、またはサードパーティのモデルプロバイダーを通じて提供される基盤モデルとのやりとりを汎用化します。 生成 AI コンポーネント (Generative AI components) は、生成 AI アプリケーションの構築に必要な機能を提供します。プロンプトのキャッシュ、プロンプトチェーン、エージェント、またはハイブリッド検索などの機能は、これらのマイクロサービスに含まれます。 責任ある AI コンポーネント (Responsible AI components) は、テナント全体にわたって AI の安全かつ責任ある開発を可能にします。ガードレール、レッドチーミング、モデル評価などの機能が含まれます。 テナント ここでは AI ゲートウェイの機能を使用するテナントについて述べます。各テナントには異なる要件やニーズがあり、そして独自のアプリケーションスタックがあります。生成 AI ゲートウェイにアプリケーションを連携することで、生成 AI 機能をアプリケーションに実装することができます。環境の 管理者 は生成 AI ゲートウェイにアクセスして、コアサービスと連携します。 ソリューションの概要 このセクションでは、ソリューションの各部についてより詳しく説明します。 HTTPS エンドポイント これは生成 AI ゲートウェイのエントリーポイントとして機能します。ゲートウェイへの要求は、このポイントを通過します。エンドポイントを設計する際には、さまざまなアプローチがあります。 REST API エンドポイント – すべての認証、認可、そしてスロットリングの処理のために API Gateway などのサービスを使用して、REST API エンドポイントを設定します。API Gateway はサーバーレスであるため、トラフィックに応じて自動的にスケールします。 WebSocket – 長時間の接続には、REST インターフェースの代わりに WebSocket を使用します。この方法により、同期的な REST リクエストのタイムアウト制限が解消されます。WebSocket の採用により、複数回または長時間のやりとりでも接続が維持されます。 API Gateway は、WebSocket APIも提供しています。 ロードバランサー – もう一つの選択肢は、HTTPS エンドポイントを公開し、リクエストをオーケストレーターにルーティングするロードバランサーを使用することです。このアプローチを実装するには、 Application Load Balancer などの AWS サービスを使用できます。Application Load Balancer を使用する利点は、実質的にあらゆるマネージド型、サーバーレス型、またはセルフホスト型のコンポーネントにシームレスにリクエストをルーティングでき、スケールも容易なことです。 テナントとアクセスパターン 事業部門やチームなどのテナントは、共有サービスを利用して API にアクセスし、生成 AI の機能をアプリケーションに導入します。また、本格的なアプリケーションの開発に着手する前に、特定のユースケースに対する生成 AI の適合性を評価するために、プレイグラウンドを適宜使用することもできます。 また、データソース、処理のパイプライン、ベクトルストア、データガバナンスといった機能により、テナントはそれぞれのユースケースで必要となるデータを安全に識別してアクセスすることができます。この段階ではユースケースとデータの分離要件について考慮する必要があります。個人識別情報 (PII) を含むデータへのアクセスが必要になるアプリケーションもある一方、クリティカルでないデータだけを必要とするアプリケーションもあるでしょう。また、運用上の特性や ノイジーネイバー のリスクについても考慮する必要があります。 RAG (Retrieval Augmented Generation) を例に取ります。ユースケースやデータの分離要件に応じて、テナントは共有型もしくは個別型のナレッジベースを構築し、データに対してアイテムレベルもしくはリソースレベルでの分離を実装できます。テナントは、アクセス可能なデータソースからデータを選択します。そしてアプリケーションに適したチャンキング手法を選択し、共有されている生成 AI の基盤モデルをデータのエンベッディングに使用して、ベクトルストアにエンベッディングを保存できます。 ユーザーの質問にリアルタイムで回答するために、テナントはキャッシュ機能を実装して、頻繁なクエリに対する待ち時間とコストを削減することができます。さらに、カスタムロジックを実装して、以前のセッション、インタラクションの状態、エンドユーザー固有の情報を取得することもできます。最終的な応答を生成するために、ゲートウェイを通じて、利用可能なモデルやリランキングの機能にアクセスすることができます。 次の図は、このアプローチでのチャットベースのエージェントアプリケーションの実装例を示しています。テナントのアプリケーションは、生成 AI ゲートウェイ経由で、利用可能な基盤モデルや独自のベクトルストアを使用し、エンドユーザーにパーソナライズされた関連性の高いレスポンスを提示します。 共有サービス このセクションでは、共有サービスグループについて説明します。 モデルコンポーネント このコンポーネントグループの役割は、テナントがホストされている場所に関係なく、基盤モデルにアクセスするための統一された API をテナントに提供することです。呼び出しの仕様を汎用化し、アプリケーション開発を加速します。基盤モデルのプロバイダー数や、使用するカスタムモデルの数や種類に応じて、1つまたは複数のコンポーネントで構成されます。以下の図に示します。 テナントが基盤モデルを利用する方法について、AWSではいくつかの選択肢があります。 Amazon Bedrockは、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazonといった AI 企業が提供する基盤モデルを、単一の API を通じて選択できるフルマネージドなサービスです。サーバーレスなので、インフラストラクチャを管理する必要はありません。また、カスタマイズしたモデルを Amazon Bedrock に持ち込み、 サポートされているモデルアーキテクチャに対応するもの としてデプロイすることもできます。 SageMaker JumpStart は、AI21 Labs、Cohere、Hugging Face、Meta、Stability AI などのプロバイダーが提供する、公開されている独自仕様の幅広い基盤モデルを提供する機械学習 (ML) のハブです。これらの基盤モデルは、お客さまの AWS アカウントの SageMaker エンドポイントにデプロイできます。 SageMaker では、 SageMaker のエンドポイントでの推論 が可能で、HuggingFace などの公開モデルや独自モデルをデプロイできます。 また、 Amazon Elastic Kubernetes Service (Amazon EKS) などのコンテナサービスや、セルフマネージドのアプローチで、モデルをAWSのコンピューティングにデプロイすることもできます。 AWS PrivateLink を使用すると、仮想プライベートクラウド (VPC) と Amazon Bedrock および SageMakerのエンドポイント間のプライベート接続を確立できます。 生成 AI アプリケーションコンポーネント このグループには、生成 AI アプリケーションの固有要件に関連するコンポーネントが含まれています。以下の図に示します。 プロンプトカタログ (Prompt catalog)&nbsp;– 効果的なプロンプトを作成することは、大規模言語モデル (LLM) に適切な出力を生成させる上で重要です。プロンプトエンジニアリングは通常反復的なプロセスであり、チームは目標とする結果が得られるまで、さまざまなテクニックやプロンプトの構文を試行します。プロンプトの保存、バージョン管理、追跡、共有のためには、プロンプトカタログを一元管理することが不可欠です。また、本番の手前の環境で評価プロセスを自動化することもできます。新しいプロンプトがカタログに追加されると、評価のパイプラインが起動します。パフォーマンスが向上した場合は、アプリケーションの既存のデフォルトプロンプトは新しいプロンプトに置換されます。Amazon Bedrock を使用すると、 Amazon Bedrock Prompt Management で独自のプロンプトを作成して保存できるため、同じプロンプトを異なるワークフローに適用することができ、時間を節約できます。また、サーバーレスのフルマネージド型の NoSQL データベースである Amazon DynamoDB を使用してプロンプトを保存することもできます。 プロンプトチェーン (Prompt chaining) – 生成 AI の開発者は、LLM に送信する前に複雑なタスクをサブタスクに分割するために、プロンプトチェーンのテクニックをよく使用します。 共通的なプロンプトチェーンのアーキテクチャの API をテナントに公開する集約型のサービスを利用すると、開発を加速できます。 AWS Step Functions を使用してチェーンのワークフローを構成し、タスクの完了イベントを Amazon EventBridge を使用して監視し、次ステップのトリガーとすることができます。 詳細は、「 AI プロンプトチェーンを Amazon Bedrock で実行する 」を参照してください。 エージェント (Agent) – テナントは複雑なタスクを処理するために自律型エージェントを採用することもあります。 このようなエージェントは、モデル、データソース、API、およびアプリケーション間のやりとりを統合します。 エージェントコンポーネントにより、エージェントの作成、管理、アクセス、および共有が可能になります。 AWSでは、フルマネジードの Amazon Bedrock Agents や、LangChain や LlamaIndex のエージェントなどの任意のツールを使用できます。 リランク (Re-ranker) – RAGの設計では、企業内のデータ検索で複数の候補が返されることがよくあります。Cohere の Rerank 2 モデル などのリランク機能は、事前に定義された基準に基づいて最適な候補を判別するのに役立ちます。テナントが Amazon OpenSearch Service や Amazon Kendra などのマネージドサービスの機能を使用することを選択する場合は、このコンポーネントは必要ありません。 ハイブリッド検索 (Hybrid search) – RAGでは、必要に応じて、抽出されるドキュメントの品質を向上すべくハイブリッド検索を実行するために、複数のテンプレートを実装したり公開することもできます。このロジックは、ハイブリッド検索コンポーネントに組み込まれます。Amazon OpenSearch Service などのマネージドサービスを使用する場合は、このコンポーネントは必要ありません。 責任ある AI コンポーネント このグループには、以下の図に示す責任ある AIの主要コンポーネントが含まれます。 ガードレール (Guardrails) – ガードレールは、基盤モデルに組み込まれた保護に加えて、安全対策を実施するのに役立ちます。組織のユーザーに対して汎用的なデフォルトとして適用することも、各ユースケースに特化して適用することもできます。 Amazon Bedrock Guardrails を使用すると、アプリケーションの要件と責任ある AI のポリシーに基づいて、このような保護策を実装することができます。Amazon Bedrock Guardrails により、望ましくないトピックをブロックしたり、有害なコンテンツをフィルタリングしたり、PII やカスタム正規表現などの機密情報を削除またはブロックしてプライバシーを保護することができます。さらに、コンテクストに基づくグラウンドチェックにより、参照ソースとユーザークエリに基づいて、モデルのレスポンスにおけるハルシネーションを検出することができます。ApplyGuardrail API は、Amazon Bedrock 上 の基盤モデル、カスタムの基盤モデル、サードパーティの基盤モデルに対する入力プロンプトとモデルのレスポンスを評価することができ、生成 AI アプリケーションの全体に渡る統合的なガバナンスを実現します。 レッドチーミング (Red teaming) – レッドチーミングは、ユーザー経験の低下や悪意ある行為につながりうるモデルの制約を特定するのに役立ちます。LLM は、バックドア攻撃、ポイズニング攻撃、プロンプトインジェクション、ジェイルブレイク、PII 漏洩攻撃、メンバーシップ推論攻撃、勾配漏洩攻撃などのセキュリティおよびプライバシー攻撃に対して脆弱性を持つ可能性があります。テスト用のアプリケーションや自社の従業員で構成するレッドチームを立ち上げることや、既知の脆弱性に対して自動化したりするといった対応ができます。例えば、既知のジェイルブレイクのデータセットを用いてアプリケーションをテストするといったことです。 テスト結果を用いて、Amazon Bedrock Guardrails を調整し、望ましくないトピックをブロックしたり、有害なコンテンツをフィルタリングしたり、機密情報を削除またはブロックしたりすることができます。 ヒューマン・イン・ザ・ループ (Human in the loop) – ヒューマン・イン・ザ・ループのアプローチは、モデルの精度や関連性を向上させるために、ML のライフサイクル全体を通じて人間のインプットを収集するプロセスです。人間は、データの作成や注釈付けから、モデルのレビュー、カスタマイズ、評価まで、さまざまなタスクを行えます。 SageMaker Ground Truth では、セルフサービスと AWS マネージドサービスが用意されています。セルフサービスでは、データの注釈付の担当者、コンテンツの作成者、そしてプロンプトエンジニア（社内人材、ベンダー人材、またはパブリック人材）が、ローコードの UI を用いてヒューマン・イン・ザ・ループのタスクを迅速化できます。AWS マネージドサービス ( SageMaker Ground Truth Plus ) は、エンドツーエンドのワークフローのデザインやカスタマイズをし、特定のタスクのトレーニングを受けた専門知識のある AWS マネージドチームを提供し、お客さまのデータ品質、セキュリティ、およびコンプライアンスに関する要件を満たします。 Amazon Bedrock のモデル評価 を用いて、人間の作業者が複数のモデルからのレスポンスをGround Truthのレスポンスと比較して評価するといった、基盤モデルの評価のジョブを設定できます。評価方法として、サムズアップまたはサムズダウン、5段階評価、2択ボタン、順序付けなどを設定できます。 モデルの評価 (Model evaluation) – モデルの評価では、モデルの出力を比較し、下流の生成 AI アプリケーションに最適なモデルを選択できます。自動的な評価、ヒューマン・イン・ザ・ループでの評価、またはその両方を使用できます。Amazon Bedrock でのモデルの評価は、自動的な評価のジョブとヒューマン・イン・ザ・ループでの評価のジョブを設定できます。既存のデータセットを選択するか、独自のカスタムプロンプトのデータセットを投入できます。 Amazon SageMaker Clarify を使用すると、 Amazon SageMaker JumpStart の 評価用基盤モデル を評価できます。 テキスト生成、要約、分類、質問応答など、さまざまなタスクに対して、プロンプトのステレオタイプ化、毒性、事実に関する知識、セマンティック堅牢性、正確性など、さまざまな側面からのモデルの評価を設定することができます。そして独自の評価パイプラインを構築したり、 fmeval などのツールを使用することができます。 モデルの監視 (Model monitoring) – モデルの監視サービスでは、テナントが事前に定義したメトリクスに対するモデルのパフォーマンスを評価できます。モデル監視ソリューションは、リクエストとレスポンスのデータを収集し、評価ジョブを実行し、事前に設定のベースラインに対するパフォーマンスメトリクスを計算し、その結果を保存し、問題が発生した場合はアラートを送信します。 Amazon Bedrock を使用している場合は、 モデル呼び出しのログ を有効にして入力と出力のデータを収集し、Amazon Bedrock 評価を使用してモデル評価ジョブを実行できます。あるいは AWS Lambda を使用して独自のロジックを実装したり、 fmeval などのオープンソースツールを使用することもできます。SageMaker では、SageMaker のリアルタイムエンドポイントで データキャプチャ を有効にして、 SageMaker Clarify を使用してモデルの評価ジョブを実行したり、独自の評価ロジックを実装することができます。Amazon Bedrock と SageMaker はどちらも SageMaker Ground Truth と統合されており、グランドトゥルースのデータ（トレーニングやテストに使用される実際のデータ）や、モデルのレスポンスに対するヒューマンフィードバックの収集に役立ちます。そして AWS Step Functions は、エンドツーエンドのモニタリングワークフローのオーケストレーションに役立ちます。 コアサービス コアサービスは、管理や運用のコンポーネントやモジュールの集合体です。これらのコンポーネントは、システム運用、リソース管理、ユーザーおよびテナント管理、モデル管理など、さまざまな側面を監視、制御、管理できるように設計されています。これらは次の図に示されています。これらのコンポーネントは、システムの運用、リソース管理、ユーザーおよびテナント管理、モデル管理のさまざまな側面を監視、制御、および管理できるように設計されています。以下の図に示します。 テナントの管理と認証 (Tenant management and identity) テナント管理は、マルチテナントシステムにおいて重要な要素です。マルチテナントシステムでは、アプリケーションや環境のシングルインスタンスが複数のテナントや顧客に提供され、それぞれが独立した安全な環境で利用されます。テナント管理のコンポーネントは、システム内のテナントの管理や運用を担います。 テナントのオンボーディングとプロビジョニング – 新規テナント向けのオンボーディングの再利用可能なプロセスの作成を担います。これには、テナント固有の環境の作成、リソースの割り当て、テナントの要件に基づくアクセス制御の設定が含まれます。 テナントの構成とカスタマイズ – 多くのマルチテナントシステムでは、テナント毎に特定のニーズに合わせてアプリケーションや環境を部分的に変更することができます。テナント管理のコンポーネントは、テナントが分離された環境で設定、ブランディング、ワークフロー、その他の設定を変更するためのインターフェースやツールを提供できます。 テナントの監視とレポーティング – このコンポーネントは、監視や計測のコンポーネントとリンクしており、テナント固有の使用状況、パフォーマンス、およびリソース消費に関するレポートを作成します。テナントのアクティビティに関するインサイトを提供し、潜在的な問題を特定し、各テナントのキャパシティプランニングやリソース割り当てを容易にします。 テナントの料金請求とサブスクリプション管理 – 複数の価格モデルやサブスクリプションプランが存在するソリューションでは、テナント管理のコンポーネントが、各テナントの利用状況、リソース消費量、もしくは契約サービスレベルに基づいて、テナント毎の料金請求やサブスクリプション管理を処理することができます。 提案のソリューションでは、リクエストを行うユーザーの認証フローも必要となります。 AWS IAM Identity Center を使用すると、作業ユーザーを作成または連携し、AWS アカウントとアプリケーションに渡ってアクセスを一元管理できます。 Amazon Cognito を使用すると、ビルトインのユーザーディレクトリ、お客さまのエンタープライズディレクトリ、およびその他のコンシューマーアイデンティティプロバイダーから、ユーザーを認証および認可することができます。 AWS Identity and Access Management (IAM) は、細粒度のアクセス制御を可能にします。IAM を使用して、どのユーザーがどの基盤モデルやリソースにアクセスできるかを指定し、最小権限でのアクセス許可を保つことができます。 例えば、Cognito でよくあるシナリオの1つとして、 ユーザープールを用いて API Gateway と Lambda でリソースにアクセスする といったものがあります。次の図では、ユーザーが Amazon Cognito ユーザープールにサインインすると、アプリケーションが JSON Web トークン (JWT) を受け取ります。ユーザープールのグループを使用して、グループの権限を IAM ロールにマッピングすることで、API Gateway での権限を制御することができます。ユーザープールのトークンを API Gateway へのリクエストに含めて送信し、Amazon Cognito のオーソライザーとしての Lambda ファンクションで検証することができます。詳細は、「 Amazon Cognito ユーザープールをオーソライザーとして使用してREST API へのアクセスを制御する 」を参照してください。 APIへのアクセスの制御で、認証や認可に API キーを使用しないことをお勧めします。代わりに、IAM ロール、 Lambda オーソライザー 、または Amazon Cognito ユーザープール を使用してください。 モデルのオンボーディング (Model onboarding) 生成 AI ゲートウェイの重要な点は、基礎モデルやカスタムモデルへの統制されたアクセスをテナント全体で可能にすることです。Amazon Bedrock で利用可能な基盤モデルの場合、テナントがアクセスできる承認済みのモデルの許可リストを、モデルのオンボーディングコンポーネントが保持します。 Amazon DynamoDB などのサービスを使用して、許可リストに登録されたモデルを追跡することができます。同様に、Amazon SageMaker にデプロイされたカスタムモデルの場合、コンポーネントは、DynamoDB のレジストリテーブルのエントリから、どのテナントがどのモデルバージョンにアクセスしているかを追跡します。 アクセス制御を強化するために、Amazon API Gateway と AWS Lambda オーソライザーを併用することができます。テナントのアプリケーションがモデルを呼び出す API をコールすると、Lambda オーソライザーがテナントの ID を確認し、DynamoDB レジストリテーブルに照らして要求されたモデルへのアクセス権限があるかどうかをチェックします。アクセスが許可された場合、一時的なクレデンシャルが発行され、テナントの権限が許可されたモデルのみに適用されます。これにより、テナントがアクセス権限のないモデルにアクセスするのを防ぎます。認可のロジックは、組織のモデルへのアクセスのポリシーやガバナンスの要件に基づいてカスタマイズできます。このアプローチは、モデルの運用終了をサポートします。DynamoDB のレジストリテーブルの許可リストから、すべてのテナントもしくは特定のテナントのモデルを管理することで、コードを変更することなく、リストに含まれていないモデルが自動的に使用できなくなります。 モデルのレジストリ (Model registry) モデルのレジストリは、カスタムモデルのさまざまなバージョンの管理や追跡に役立ちます。 Amazon SageMaker Model Registry や Amazon DynamoDB などのサービスは、利用可能なモデル、関連するモデルのアーティファクト、そしてリネージ（系統）の追跡に役立ちます。モデルのレジストリは、以下の機能を提供します。 バージョンの管理 – 生成AIのモデルのさまざまなバージョンを追跡します。 モデルのリネージや来歴 – トレーニングデータ、ハイパーパラメータ、モデルアーキテクチャ、モデルの来歴や特性を記述する関連するメタデータなどの情報を含め、各モデルのバージョンのリネージや来歴を追跡します。 モデルのデプロイとロールバック – 新しいモデルのバージョンを本番環境にデプロイして利用可能にし、また必要に応じて以前のバージョンへのロールバックを可能にします。これにより、システムの運用を中断することなく、モデルをシームレスに更新または復元することができます。 モデルのガバナンスとコンプライアンス – モデルのバージョンが適切に文書化され、監査され、関連するポリシーやレグレーショ制に準拠していることを確認します。これは、規制産業やコンプライアンス要件が厳しい環境で特に有用です。 オブザーバビリティ オブザーバビリティは、アプリケーションの健全性の監視、問題のトラブルシューティング、基盤モデルの使用、パフォーマンスやコストの最適化には不可欠です。 ログの取得と監視 (Logging and monitoring) Amazon CloudWatch は強力なモニタリングとオブザーバビリティのサービスであり、API Gateway、Amazon Bedrock、Amazon SageMaker、カスタムサービスなどのアプリケーションコンポーネントからのログを収集・分析できます。CloudWatch でスタック全体にわたるログからテナント ID を特定することで、生成 AI ゲートウェイのパフォーマンスや健全性に関するインサイトをテナントレベルで得ることができ、問題が深刻化する前に、問題を特定して解決することができます。予期しない挙動が発生した場合に通知を受け取るよう、アラームを設定することもできます。Amazon SageMaker と Amazon Bedrock は、AWS CloudTrail と統合されています。 計測 (Metering) 計測は、ソリューションのさまざまな部分から運用や使用のデータやパフォーマンスメトリクスを収集、集約、分析するのに役立ちます。従量課金制やサブスクリプションベースのモデルを提供するシステムでは、テナント毎に正確に請求するためにリソース消費を測定して報告するといった計測が重要となります。 このソリューションでは、コストを効果的に管理し、リソースの使用率を最適化するために、基盤モデルの使用状況を追跡する必要があります。 使用したモデル、入力されたトークン数、出力として生成されたトークン数、使用された AWS リージョン 、チームに関連するタグの適用など、関連する情報を収集することで、コスト配分や請求処理を合理化することができます。基盤モデルとのやりとりを構造化データとして記録し、利用情報を収集することができます。次の図は、Lambda 関数がテナント毎の情報を Amazon CloudWatch に記録しながら、Amazon Bedrock を呼び出す実装を示しています。Amazon Bedrock の呼び出しにより、AWS CloudTrail のイベントが生成されます。 監査 (Auditing) AWS Lambda 関数を使用して Amazon CloudWatch からのデータを集約し、S3 バケットに保存して長期保存やさらなる分析を行うことができます。Amazon S3 は、耐久性、拡張性、コスト効率に優れたオブジェクトストレージソリューションであり、大量のデータを保存するのに最適です。実装の詳細については、このシリーズの第1部の「 Amazon Bedrock での基盤モデルのコストと使用状況の追跡を備えた社内 SaaS サービスの構築 」を参照してください。 Amazon S3 にデータが保存された後、Amazon Athena、 AWS Glue Data Catalog 、 Amazon QuickSight などの AWS のアナリティクスサービスを使用して、コストや使用のパターンを明らかにし、レポートを生成し、傾向を可視化します。そしてリソースの割り当て、予算の予測、コスト最適化戦略といったことに基づいて意思決定を行うことができます。AWS Glue Data Catalog（一元的なメタデータリポジトリ）と Amazon Athena（インタラクティブなクエリサービス）を使用すると、Amazon S3 に保存されたデータに対して、SQL クエリを直接実行することができます。以下の例では、Athena での各テナントのモデル毎の使用とコストについて示します。 企業全体への展開 以下は、組織内の多くの事業部門やチームにこのソリューションをスケールさせる場合の設計上の考慮事項です。 アカウントの制限 – これまで単一の AWS アカウントでゲートウェイソリューションを展開する方法について説明してきました。チームがゲートウェイに次々と参加し、LLM の利用を拡大していくと、さまざまなコンポーネントがAWSアカウントの制限に達し、ボトルネックとなっていく可能性があります。生成 AI ゲートウェイは、1つの AWS アカウントが1つの事業部門に対応するようにして、複数の AWS アカウントを展開していくことをお勧めします。その理由は、一般的には大企業の各事業部門は自律的であり、そして数十から数百のチームを抱えている可能性があるからです。さらに各事業部門は、他の事業部門とのデータの共有を制限する厳格なデータプライバシーポリシーを定めている場合もあります。本番環境のアカウントに加えて、各事業部門はテスト環境やインテグレーション環境のAWSアカウントも保有する可能性もあります。 本番および非本番のワークロード – ほとんどの場合、事業部門等のテナント側のチームは、開発、テスト、本番の各環境でこのゲートウェイを使用したいと考えるでしょう。組織の運用モデルに大きく依るものですが、本番環境のゲートウェイに負荷をかけたり、非本番環境のデータを混在したりすることなく、チームが自由に実験を行えるよう、ゲートウェイにも専用の開発、テスト、本番環境を用意することを推奨しています。これにより、非本番環境のゲートウェイの制限値を本番環境よりも低く設定できるというメリットも得られます。 RAG のデータコンポーネントの取り扱い – RAG ソリューションを実装する際には、すべてのデータ関連のコンポーネントをテナント側で管理することをお勧めします。各テナントには、独自のデータ制約、更新サイクル、フォーマット、用語、および権限グループがあります。データソースの管理責任をゲートウェイに割り当てると、スケーラビリティが妨げられる可能性があります。ゲートウェイは各テナントのデータソースの固有の要件に対応できないため、おそらくは最低限の共通項目を処理することになるでしょう。したがって、データソースおよび関連コンポーネントはテナント側で管理することをお勧めします。 車輪の再発明の回避 – このソリューションは、モデル評価、ガードレール、プロンプトカタログ、監視など、独自のコンポーネントを構築および管理できます。Amazon Bedrock などのサービスは、セキュリティ、プライバシー、責任ある AI を最初から備えた生成 AI アプリケーションを構築するために必要な機能を提供しています。バランスの取れたアプローチを取り、極力 AWS ネイティブの機能を使用して運用コストを削減することをお勧めします。 スリムな生成 AI ゲートウェイの維持 – ビジネスロジックの保持という観点で、このゲートウェイをスリムに保つことを提案します。ゲートウェイに、特定のテナントに対するビジネスルールを追加すべきではなく、既に取り上げたような運用データ以外のテナント固有のデータを保持することは避けるべきです。 おわりに 生成 AI のマルチテナントのアーキテクチャは、複数のユースケースやチームに渡って生成 AI の利用を拡大しながら、セキュリティ、ガバナンス、コスト管理を維持するのに役立ちます。本記事では、生成 AI の導入を加速させるための参考となるマルチテナントのアーキテクチャを紹介しました。共通的な生成 AI コンポーネントの標準化と、それらを共有サービスとして公開する方法について説明しました。また、提案のアーキテクチャでは、ガバナンス、セキュリティ、オブザーバビリティ、責任ある AI といった主要な観点についても取り上げました。最後に、このアーキテクチャを多くのチームに拡張していく際の主な考慮事項について説明しました。 このトピックについてさらに詳しくお知りになりたい方は、以下もご覧ください。 AI/ML CoE (Center of Excellence) の設立 基盤モデルを安全かつコンプライアンスに準拠して利用するための生成 AI ゲートウェイの構築 著者について Anastasia Tzeveleka は、AWSのシニア生成 AI/ML スペシャリストソリューションアーキテクトです。EMEA 全域のお客さまが AWS サービスを使用して基盤モデルを構築し、スケーラブルな生成 AI および機械学習のソリューションを構築できるよう支援しています。 . . . . Hasan Poonawala は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトとして、ヘルスケアおよびライフサイエンス業界のお客さまを担当しています。AWS での生成 AI および機械学習アプリケーションの設計、デプロイ、およびスケールを支援しています。クラウド上での機械学習、ソフトウェア開発、およびデータサイエンスで、合計15年以上の業務経験があります。余暇は自然探索や友人や家族との時間を大切にしています。 . . Bruno Pistone は、ミラノを拠点とする AWS のシニア生成 AI および ML スペシャリストソリューションアーキテクトです。 お客さまと共同し、お客さまの技術的なニーズを深く理解し、AWS クラウドと Amazon Machine Learning スタックを最大限に活用する AI および機械学習ソリューションの設計を支援しています。 専門分野は、機械学習全般、機械学習の商用化、生成 AI です。 友人と過ごす時間や新しい場所を探索することを楽しんでおり、新しい場所への旅行も好んでいます。 . . Vikesh Pandey は、金融サービスを専門とするプリンシパル生成 AI/ML ソリューションアーキテクトで、お客さまが生成 AI/ML プラットフォームやソリューションを構築し、数百人から数千人のユーザーに拡張することを支援しています。余暇には、さまざまなブログフォーラムに投稿したり、子供と一緒にレゴを組み立てたりするのが好きです。 . . . Antonio Rodriguez は、Amazon Web Servicesのプリンシパル生成 AI スペシャリストソリューションアーキテクトです。あらゆる規模の企業が抱える課題の解決、イノベーションの導入、Amazon Bedrock による新たなビジネスオポチュニティの創出を支援しています。仕事以外では、家族と過ごしたり、友人とスポーツを楽しんだりしています。 . . . 翻訳者について 川口賢太郎 (Kentaro Kawaguchi) は、プロフェッショナルサービスのシニア CS&amp;O アドバイザリーコンサルタントで、デジタル戦略立案とそれに即した組織の変革に注力しています。 CCoE や AI CoE などの xCoE の組成支援などに従事しています。