はじめに Amazon Elastic Kubernetes Service (Amazon EKS) の「Elastic」とは、 「必要なときにリソースを確保し、不要になったときにリソースを解放する」 機能を指します。Amazon EKS はほとんどすべてのワークロードを処理できるように拡張できますが、Amazon EKS のお客様から「1 つの Amazon EKS クラスターでサポートされる Pod やノードの最大数はいくつですか」というような質問をよく耳にします。 Kubernetes は複雑なシステムであり、Kubernetes クラスターのパフォーマンス特性はワークロードの特性によって異なる場合があるため、これらの質問に対する答えはさまざまです。 Kubernetes コミュニティは Kubernetes コンポーネントのサービスレベル指標 (SLI) とサービスレベル目標 (SLO) を定義しており 、これらをスケーラビリティに関する議論の出発点として使用できます。この投稿では、これらの SLI と SLO について説明し、Amazon EKS チームがどのようにスケーラビリティテストを実施しているのか説明します。 SLI は私たちがシステムを測定する方法です。例えばリクエストのレイテンシーやカウントのように、システムの稼働状況を判断するために使用できる指標があります。SLO は、例えば、リクエストのレイテンシーが 3 秒未満というように、システムが正常に稼働しているときに期待される値を定義します。Kubernetes SLO と SLI は Kubernetes コンポーネントのパフォーマンスに重点を置いており、Amazon EKS クラスターの Kubernetes API エンドポイントの可用性に重点を置いた Amazon EKS サービス SLA とは無関係です。 Kubernetes アップストリームの SLO Amazon EKS はアップストリームの Kubernetes リリースに準拠しており、Amazon EKS クラスターが Kubernetes コミュニティによって定義された SLO の範囲内で動作することを保証しています。 Scalability Special Interest Group (SIG) は Kubernetes のスケーラビリティ目標を定義し、SLI と SLO を通じてパフォーマンスのボトルネックを調査しています。 Kubernetes には、Container Storage Interface (CSI) ドライバー、Admission Webhook、Autoscaler など、ユーザーがカスタムのアドオンやドライバーを使用してシステムを拡張できる機能が数多くあります。これらの拡張は、Kubernetes クラスターのパフォーマンスにさまざまな形で影響を与える可能性があります。例えば、 failurePolicy=Ignore の Admission Webhook は、Webhook ターゲットが利用できない場合、Kubernetes API リクエストのレイテンシーを増加させる可能性があります。Kubernetes Scalability SIG は、 「you promise, we promise」フレームワーク を使用してスケーラビリティを定義しています。 次のことを約束していただければ: クラスターを正しく構成する 拡張機能を「合理的に」使用する クラスターの負荷を 推奨制限 内に抑える クラスターがスケールすることをお約束します: すべての SLO が満たされます Kubernetes SLO は、ワーカーノードのスケーリングや Admission Webhook など、クラスターに影響を与える可能性のあるプラグインや外部要因をすべて考慮しているわけではありません。これらの SLO は Kubernetes コンポーネント に重点を置いており、Kubernetes のアクションとリソースが期待どおりに動作することを保証します。SLO は、Kubernetes 開発者が Kubernetes コードの変更によってシステム全体のパフォーマンスをデグレードさせない役割を担っています。 Kubernetes Scalability SIG では、以下の公式 SLO/SLI を定義 しており、Amazon EKS チームはこれらの SLO や SLI について Amazon EKS クラスターで定期的にスケーラビリティテストを実施して、変更が行われたり新しいバージョンがリリースされたりしたときのパフォーマンスのデグレードを監視しています。 Objective Definition SLO API request latency (mutating) Latency of processing mutating API calls for single objects for every (resource, verb) pair, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99 th percentile per cluster-day <= 1 second API request latency (read-only) Latency of processing non-streaming read-only API calls for every (resource, scope) pair, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99 th percentile per cluster-day: (a) <= 1 second if scope=resource (b) <= 30 seconds otherwise (if scope=namespace or scope=cluster) Pod startup latency Startup latency of schedulable stateless pods, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99 th percentile over last 5 minutes In default Kubernetes installation, 99 th percentile per cluster-day <= 5 seconds API リクエストのレイテンシー kube-apiserver では、 --request-timeout がデフォルトで 1m0s と定義されています。つまり、リクエストがタイムアウトしてキャンセルされるまでに最大 1 分（60 秒）実行できます。Latency に定義された SLO は、送信されるリクエストのタイプによって分類されます。リクエストのタイプは、変更可能な場合もあれば、読み取り専用の場合もあります。 変更 Kubernetes のリソース変更リクエストは、作成、削除、更新などを行います。これらのリクエストは、変更されたオブジェクトが返される前に etcd バックエンド に書き込まれます。etcd はすべての Kubernetes クラスターデータに使用される分散型のキーバリューストアです。 このレイテンシーは、Kubernetes リソースの (resource, verb) ペアに対して 5 分間の 99 パーセンタイルとして測定されます。例えば、Pod 作成リクエストやノード更新リクエストのレイテンシーが測定されます。SLO を満たすには、リクエストのレイテンシーが 1 秒未満である必要があります。 読み取り専用 読み取り専用リクエストは、「Get Pod X」など単一のリソース、または「Get all Pod from Namespace X」などコレクションを取得します。kube-apiserver はオブジェクトのキャッシュを保持するので、要求されたリソースをキャッシュから返すこともあれば、etcd から取得する必要がある場合もあります。 また、これらのレイテンシーは 5 分間にわたって 99 パーセンタイルで測定されますが、読み取り専用リクエストではスコープが異なっていてもかまいません。SLO には 2 つの異なる目標が定義されています。 kubectl get pod -n mynamespace my-controller-xxx など単一のリソースに対して行われるリクエストの場合、リクエストのレイテンシーは 1 秒未満にとどまる必要があります。 kubectl get pods -A など名前空間またはクラスター内の複数のリソースに対して行われるリクエストの場合、レイテンシーは 30 秒未満にとどまる必要があります。 Kubernetes リソースのリストに対するリクエストでは、リクエストに含まれるすべてのオブジェクトの詳細が SLO 内で返されることを前提としているため、SLO はリクエストスコープごとにターゲット値が異なります。クラスター上の Kubernetes オブジェクトなどリソースの大きな集合では、応答サイズが大きくなり返されるまでに時間がかかることがあります。例えば、数万の Pod を実行しているクラスターで、JSON でエンコードした各 Pod が約 1KiB の場合、クラスター内のすべての Pod を返そうとすると 10MB 以上になります。Kubernetes クライアントは、 ApiListChunking を使用して大量のリソースコレクションを取得する ことで、このレスポンスサイズを減らしています。 Pod 起動時のレイテンシー この SLO は主に、Pod の作成から Pod 内のコンテナが実際に実行を開始するまでにかかる時間に関係します。これを測定するために、Pod に記録された作成タイムスタンプと、その Pod の WATCH がコンテナの起動を報告した時刻の差が計算されます (コンテナイメージのプルとコンテナの初期化にかかる時間は除く)。この SLO を満たすには、Pod 起動レイテンシーの 1 クラスター稼働日あたりの 99 パーセンタイルを 5 秒未満にする必要があります。 Kubernetes SLI メトリクス Kubernetes では、これらの SLI を経時的に追跡する Kubernetes コンポーネントに Prometheus メトリクス を追加することで、SLI に関するオブザーバビリティも向上させています。 Prometheus Query Language (PromQL) を使って、Prometheus や Grafana ダッシュボードなどのツールで SLI のパフォーマンスを経時的に表示するクエリを作成できます。以下は先述の SLO の例です。 API サーバーのリクエストレイテンシー メトリクス 定義 apiserver_request_sli_duration_seconds verb、group、version、resource、subresource、scope、および component ごとの秒単位の応答レイテンシー分布 (Webhook の持続時間、優先度、公平性キューの待機時間はカウントされません)。 apiserver_request_duration_seconds verb、dry run value、group、version、resource、subresource、scope、および component ごとの秒単位の応答レイテンシー分布。 注 : apiserver_request_sli_duration_seconds メトリクスは Kubernetes 1.27 から利用可能になりました。 これらのメトリクスを使用して API サーバーの応答時間を調査 したり、Kubernetes コンポーネントや他のプラグイン/コンポーネントにボトルネックがないかを調べたりすることができます。これらのメトリクスを比較することで、リクエスト処理の遅延がどこで発生しているのかを把握できます。 API リクエストレイテンシー SLI — Kubernetes コンポーネントがリクエストを処理して応答するのにかかった時間です。SLI メトリクスは、リクエストが API 優先度や公平性のキュー で待機している時間、および Admission Webhook やその他の Kubernetes 拡張機能での処理に費やされる時間を除外することで、Kubernetes コンポーネントのパフォーマンスに関するインサイトを提供します。 API リクエスト合計レイテンシー — 合計時間メトリクスは、アプリケーションが API サーバーからの応答を待つ時間を反映しているため、より包括的な見方ができます。リクエストが受信されてからレスポンスが送信されるまでの時間が計算されます。これには、すべての Webhook 実行時間と、優先度と公平性のキューに費やされた時間が含まれます。 Pod 起動のレイテンシー メトリクス 定義 kubelet_pod_start_sli_duration_seconds イメージのプルと init コンテナーを実行する時間を除く、Pod を起動するまでの秒数。 Pod の作成タイムスタンプから、すべてのコンテナーが起動済みとして報告され、監視されるまでの時間を測定します。 kubelet_pod_start_duration_seconds kubelet が初めて Pod を確認してから Pod の実行が開始されるまでの秒数。これには、Pod をスケジュールする時間やワーカーノードのキャパシティをスケールアウトする時間は含まれていません。 注 : kubelet_pod_start_sli_duration_seconds メトリクスは Kubernetes 1.27 から利用可能になりました。 前のクエリと同様に、これらのメトリクスを使用すると、kubelet アクションと比較して、ノードのスケーリング、イメージのプル、および init コンテナが Pod の起動を遅延させている時間の長さを把握できます。 Pod 起動レイテンシー SLI – Pod が作成されてから、アプリケーションコンテナが実行中と報告されるまでの時間です。これには、ワーカーノードのキャパシティが利用可能になり、Pod がスケジュールされるまでにかかる時間が含まれますが、イメージをプルしたり、init コンテナを実行したりするのにかかる時間は含まれません。 Pod 起動合計レイテンシー – kubelet が初めて Pod を起動するまでにかかる時間です。これは、kubelet が WATCH 経由で Pod を受信した時点から測定したもので、ワーカーノードのスケーリングやスケジューリングにかかる時間は含まれていません。これには、イメージをプルし、 init コンテナ を起動して実行する時間も含まれます。 Amazon EKS がスケーラビリティにアプローチする方法 Amazon EKS は Kubernetes コントロールプレーンコンポーネントを管理し、そのセキュリティ、可用性、スケーラビリティを確保しますが、アプリケーション、拡張機能、およびデータプレーンインフラストラクチャ ( AWS Fargate を使用していない場合) の可用性とスケーラビリティについてはお客様の責任となります。Amazon EKS チームは定期的に一連の内部負荷テストを実施して、変更や新しいリリースによって改善されるか、同じパフォーマンスレベルが維持されるかを検証しています。 EKS ベストプラクティスガイドの「スケーラビリティ」セクション には、クラスターのスケーラビリティを向上させるために実装できる推奨事項とパターンが記載されています。 アップストリームの Kubernetes SLO および SLI 定義との一貫性を確保するために、Amazon EKS チームは SIG スケーラビリティで定義されているアップストリームのスケーラビリティテストに使用されているものと同じ基準を適用して Amazon EKS クラスターのスケーラビリティを測定しています。さまざまなユースケースや構成をすべてテストすることはできないため、これらのテストは、より高度なワークロードを評価または比較する際に使用できるスケーラビリティのベースラインとなります。 Amazon EKS でスケーラビリティテストを実行する方法 Amazon EKS チームは、Kubernetes の公式スケーラビリティおよびパフォーマンステストフレームワーク ClusterLoader2 を使用しています。Cluster Loader は宣言型スタイルのテストを使用して、指定された規模と速度で Kubernetes オブジェクトを作成します (例えば「5,000 ノードでノードあたり 30 Pod を実行し、1 秒あたり 50 Pod の速度でリソースを作成したい」など)。詳細については、 ClusterLoader2 の GitHub リポジトリ を参照してください。 Amazon EKS スケーラビリティテストは、 kubernetes/perf-tests リポジトリで定義されている汎用負荷テスト設定 に基づいています。Amazon EKS コントロールプレーンが大規模な場合でも SLO を維持できるように、5,000 ノードでテストを実行するように設定しています。Kubernetes コミュニティでは、これをクラスターあたり 5,000 ノードを超えると Kubernetes のパフォーマンスが低下する可能性があるという しきい値として定義しています 。ノード数は、ClusterLoader2 でテストを実行する際の追加パラメータ (名前空間の合計数など) の計算に使用されます。負荷テストを開始する前に、クラスター内のノードを 5,000 にスケールアウトしておきます。 負荷テストでは、Pod、(ReplicaSet と Pod を作成する) Deployment、Service、Secret などのさまざまな Kubernetes リソースが 1 秒あたり 50 Pod で作成され、Kubernetes コントロールプレーンのコンポーネントに持続的な負荷がかかります。Prometheus メトリクスは、リソースが作成されても SLO が満たされていることを確認するために、追加の詳細とともにテスト中に収集されます。 AWS のサービスクォータと考慮事項 クラスターを 5,000 ノードにスケールアウトするには、AWS アカウントの サービスクォータ を増やす必要がありました。テストに必要な制限項目を以下の表に示します。これらはテストクラスターのスケールとチャーンに合わせて増やす必要があったクォータです。 EKS ベストプラクティスガイド には、ワークロードに影響する可能性のあるその他の AWS サービスクォータが掲載されています。 AWS サービスクォータコンソール または AWS コマンドラインインターフェイス (AWS CLI) から、名前またはクォータコードを使用して、これらの制限の引き上げをリクエストできます。 サービス クォータ名 クォータコード デフォルト 増加後の値 Amazon Elastic Compute Cloud (Amazon EC2) Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances (最大 vCPU 数) L-1216C47A 5 32,000 Amazon Elastic Kubernetes Service (Amazon EKS) Nodes per managed node group L-BD136A63 450 1,000 Amazon Virtual Private Cloud (Amazon VPC) Security groups per network interface L-2AFB9258 5 16 Amazon VPC IPv4 CIDR blocks per VPC L-83CA0A9D 5 20 Amazon Elastic Block Store (Amazon EBS) Storage for General Purpose SSD (gp3) volumes, in TiB L-7A658B76 50 1,100 Amazon EBS Storage for General Purpose SSD (gp2) volumes, in TiB L-D18FCD1D 50 1,100 また、次の表に示すアクションに対する Amazon Elastic Compute Cloud (Amazon EC2) へのリクエストに対応するため、AWS アカウントのレート制限を引き上げています。Amazon EC2 のレートスロットリングの計算方法、アカウントでのレートスロットリングのモニタリング方法、および引き上げのリクエスト方法の詳細は、 EC2 ドキュメント に記載されています。 変更アクション 読み取り専用アクション AssignPrivateIpAddresses DescribeDhcpOptions AttachNetworkInterface DescribeInstances CreateNetworkInterface DescribeNetworkInterfaces DeleteNetworkInterface DescribeSecurityGroups DeleteTags DescribeTags DetachNetworkInterface DescribeVpcs ModifyNetworkInterfaceAttribute DescribeVolumes Amazon EKS クラスター ClusterLoader2 テストを実行するには、事前に合計 5,000 のワーカーノードにスケールアップされた マネージド型ノードグループ を含む Amazon EKS クラスターを使用します。Amazon EKS は、クラスターからの多数のシグナルに応じて Kubernetes コントロールプレーンを自動的にスケーリング します。そのスケーリングの一環として、Amazon EKS は 1 秒あたりのクエリ数 (QPS) や処理中リクエストの制限など、Kubernetes コントロールプレーンコンポーネントの一部のパラメータもスケーリングします。Amazon EKS クラスターは Kubernetes アップストリームのこれらのパラメータのデフォルト値を使用して作成され、Amazon EKS サービスはコントロールプレーンのスケールアップに合わせて自動的に値を増加させます。 Kubernetes コンポーネントは、起動時に設定された値をログに出力します。Kubernetes コンポーネントで Amazon EKS コントロールプレーンのログ が有効になっている場合は、 FLAG: で始まるログメッセージを検索してこれらのメッセージを確認できます。Amazon EKS が特定のクラスタースケールに設定する正確な値は、Kubernetes が変更されたり、より適切な値が見つかったりすると変わる可能性があります。 テスト用の Amazon VPC Container Networking Interface (CNI) プラグイン は、Pod の集約率と IP アドレス割り当てのパフォーマンスを向上させるために、IP アドレス割り当てに プレフィックス委任 を使用するように設定されています。クラスターはマネージド型ノードグループを幅広いインスタンスファミリーで使用しています。インスタンスタイプ間でインスタンスを多様化することで、複数のキャパシティプールからキャパシティを調達しやすくなります。テスト構成では、c5.large、m5.large、r5.large、t3.large、t3a.large、c5a.large、m5a.large、r5a.large のインスタンスを使用できます。 クラスターから Prometheus メトリクスを収集し、 Amazon Managed Service for Prometheus と Amazon Managed Grafana を使用して確認します。 テストの結果 負荷テスト中、ClusterLoader2 はクラスターのパフォーマンスを監視します。上記の SLO が満たされていない (つまり、1 つの Pod を取得する API リクエストのレイテンシーの 99 パーセンタイル [p99] が 1 秒以上かかっている) 場合、テストは失敗とみなされます。Amazon EKS チームはこれらの結果をレビューし、失敗したテストを調査して失敗の原因を把握し、リグレッションが対処されていることを確認します。 負荷テスト中に作成されるリソースの総数は ClusterLoader の設定 によって決まります。負荷テストでは、ノードあたり 30 Pod 、名前空間あたり 100 ノードで 計 5,000 ノードを想定しています。次に、テスト構成として、Pod の総数 (ノードあたり 30Pod に 5,000 ノードを掛けたもの)、名前空間 (5,000 ノードを名前空間あたり 100 ノードで割ったもの)、および名前空間あたりの Pod 数を計算します。 テストのピーク時には、クラスター内の SLO と予想されるチャーンを維持しながら、クラスター内のリソースの数を確認しています。 リソースタイプ テスト中に達した最大値 #Nodes 5,000 #Namespaces 50 #Pods 170,000* #Pods per node 30* #Deployments 16,000 #Services 8,000 #Endpoints 8,000 #Endpoints slice count 8,000 #Secrets 16,000 #ConfigMaps 16,000 #CRDs 4 #Jobs 150 * 負荷テストでは、ノードあたり 30 個のアプリケーション Pod を実行します。 Pod の総数には、プラグインと DaemonSet の Pod が含まれます。 SLO はアクションまたはリクエストを完了するまでの時間の閾値を定義するため、Kubernetes リソースの総数は実際にはこれらのテストの成功の決定要因ではないことに注意してください。例えば、Pod が起動するまでの時間のほうが、Pod の総数よりもクラスターのパフォーマンスをより深く把握できます。 クラスターの SLO Kubernetes が SLO をどのように定義しているか、Amazon EKS がクラスターのパフォーマンスをどのように測定するかを見てきました。Amazon EKS クラスターが、設定、プラグイン拡張機能、およびワークロードでどのように機能しているかを知りたいと思うかもしれません。既存の Amazon EKS クラスターで同じパフォーマンスベンチマークを確認するのに、5,000 ノードの負荷テストを全部実行する必要はありません。Amazon EKS クラスターの Kubernetes リソースから Prometheus メトリクスを収集すると、Kubernetes コントロールプレーンコンポーネントのパフォーマンスについてより深い洞察を得ることができます。使用できるメトリクスと Prometheus クエリの詳細については、 EKS ベストプラクティスガイドの「スケーラビリティ」セクション を参照してください。 SLO はクラスター内の Kubernetes コンポーネントのパフォーマンスに重点を置いていますが、他にも確認できるメトリクスが存在し、クラスターについて異なる視点が得られることを考慮してください。 kube-state-metrics のような Kubernetes コミュニティプロジェクトは、クラスター内の傾向をすばやく分析するのに役立ちます。Kubernetes コミュニティのコミュニティプラグインやドライバーは Prometheus メトリクスを出力することが多く、オートスケーラーやカスタムスケジューラーなどを調べることができます。 Observability Best Practices ガイド には、さらなる洞察を得るために使用できるその他の Kubernetes メトリクスの例が掲載されています。 Kubernetes コミュニティとの連携について Amazon EKS は Kubernetes コミュニティに貢献しています。Amazon EKS チームは Scalability SIG と協力して、 ネットワークプログラミングレイテンシー SLO のスケーラビリティテスト を実施しました。また、Amazon EKS チームは Kubernetes コミュニティと協力して、Kubernetes クラスターをプロビジョニングするためのコミュニティツールである kOps を使用して、AWS で 5,000 ノードのテストを実施しました。このテストは、Kubernetes のコード変更がパフォーマンスに悪影響を及ぼさないことを確認するために定期的に実施され、その結果は コミュニティのパフォーマンスダッシュボード で確認できます。これらのスケーラビリティテストの 1 つが失敗すると、Amazon EKS チームに通知され、調査を手伝ってもらえます。これらのテストの結果は、Kubernetes コミュニティのパフォーマンスダッシュボード で確認できます。 Amazon EKS チームは、アップストリームの Kubernetes コミュニティと同じパフォーマンスメトリクスをモニタリングするために、社内で 5,000 ノードで同じ負荷テストを実施しています。同じテストを同じ規模で使用することで、Amazon EKS 固有のコンポーネントがアップストリームの Kubernetes テストと同じレベルのパフォーマンスを維持できることを確認できます。 この作業は出発点に過ぎません。Kubernetes コントロールプレーンをスケーリングするに従って QPS や処理中リクエストのオプションを増やすなど、お客様が実際の使用で遭遇するボトルネックや問題に基づいて Amazon EKS クラスターのスケーラビリティを常に向上させています。Amazon EKS では、こうした改善がクラスターに自動的にデプロイされるため、スケーラビリティの問題が発生する前に回避できます。 まとめ この投稿では、Kubernetes コミュニティによって定義された SLO と、Amazon EKS がスケーラビリティをテストする方法について説明しました。1 つのクラスターを 1,000 ノードまたは 50,000 Pod を超えてスケーリングする場合は、ぜひご相談ください。Amazon EKS には大規模なクラスターを実行しているお客様がいます。可能な限り最高のパフォーマンスを提供するために、クラスターのスケーラビリティの向上に常に取り組んでいます。スケーリングについては、AWS アカウントチーム(ソリューションアーキテクトまたはテクニカルアカウントマネージャー)、AWS サポートチーム、または AWS Containers Roadmap に問い合わせてください。Kubernetes ワークロードを大規模に実行する方法の詳細については、 EKS ベストプラクティスガイドのスケーラビリティセクション をご覧ください。 本記事は Deep dive into Amazon EKS scalability testing (2024 年 1 月 31 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

はじめに アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの馬渕です。 2024 年 1 月 30 日、AWS re:Invent 2023 のアップデートから建設・不動産・物流・交通業向けのアップデートや事例をご紹介する Recap (振り返り) ウェビナーを開催しました。今回のウェビナーでは、AWS ジャパンで業界特化でお客様の AWS 活用を支援するソリューションアーキテクトが、re:Invent での AWS からのアップデートやお客様事例をピックアップし、業界の最新動向も交えてご紹介しました。 今回のウェビナーでは、① re:Invent 2023キーノートおよび技術アップデート、② 物流業界事例と関連サービス紹介、③ 建設・不動産業界事例と関連サービス紹介、④ 交通ソリューション 事例と関連サービス紹介、の 4 つのセッションを配信しました。本ブログ記事では、セッション内容のサマリーと、セッションの資料・動画へのリンクをまとめてお届けします。 re:Invent 2023キーノートおよび技術アップデート ( 資料 ) – 馬渕 俊介 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 交通物流 ソリューションアーキテクト このセッションでは、re:Invent 2023 の概要と、AWS のリーダーが目玉機能の発表とメッセージをお伝えする基調講演のご紹介を行いました。加えて、今年の発表の中で特に注目を集めた生成 AI についてもご紹介しました。「生成 AI とは何か？」という基本に始まり、AWS の主要な生成 AI サービスである Amazon Q ・ Amazon Bedrock のご紹介や、最新の交通・物流等の事例からみる生成 AI の最新動向、生成 AI 活用を成功させるためのコツについてお話しました。また、生成 AI をビジネスで活用するには自社のデータとの融合が必要となることから、データ関連のアップデートについてもご紹介しました。生成 AI サービスのご紹介では、活用イメージを持ちやすいようにデモ動画なども交えてご説明していますので、「AWS の生成 AI サービスが具体的にどう役立つのか？」という疑問の解消にもお役立ていただけます。 物流業界事例と関連サービス紹介 ( 資料 ) – 横山 誠 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 交通物流 シニアソリューションアーキテクト さまざまな課題に直面している物流業界は、グローバルでビジネスを展開する多くの事業者にとって大きな関心ごとになっています。本セッションでは、データ活用による効率化とIoTによる自動化というテクノロジートレンドがどのように活用されているのかを紹介します。2022年に発表されたAWS Supply Chainは、2023年4月に一般公開されてからお客様のフィードバックを受けてより実用的な機能改善・追加が行われています。またAmazon RedshiftやAmazon QuickSightなどのAWSデータ分析サービスを組み合わせて、従来の売上や在庫ばかりでなく、作業員の行動のような情報もデータ化・可視化が進んでいます。物流倉庫ではマテリアル・ハンドリング機器のIoT化が注目されており、世界的な労働力の減少を受けて検証・導入が加速しています。なお、近年の生成AIの発展は音声アシスタントなどで利用されており、今後現場作業のデジタル化を大きく促進させる可能性があります。 建設・不動産業界事例と関連サービス紹介 ( 資料 ) – 岩野 洋平 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 建設不動産 シニアソリューションアーキテクト 建設と不動産業界では、建物やインフラ設備といった重要な都市機能を作り維持する中で老朽化や次世代の担い手不足、長時間労働など様々な課題があります。一方で、これらを改善する一つの手段として IoT や AI をクラウドと共に活用したデジタル化や業務改革が注目を浴びています。本セッションでは、AWS re:Invent 2023 で発表された事例セッションの中から IoT を活用したスマートホーム事例、デジタルツインとシミュレーションの融合やロボットを活用したインスペクション事例について紹介いたします。建物やインフラといったライフサイクルの長いハードウェア中心の世界にデジタルというライフサイクルが比較的短いソフトウェアを融合し、どういった改善や取り組みを進めているか参考にしてもらえればと思います。 交通ソリューション 事例と関連サービス紹介 ( 資料 ) – 矢形 拓也 アマゾン ウェブ サービス ジャパン 合同会社 エンタープライズ統括技術本部 交通物流 シニアソリューションアーキテクト 多くの方が旅行やビジネスで公共交通機関を利用し、業界としての活気を取り戻しつつあると感じています。交通業界もインバウンドや生活サービスを拡充させることにより、新たなお客様のニーズをつかむべく様々な施策に取り組まれていると認識しています。re:Invent2023の振り返りとして、「AIを活用し働く人の負荷を軽減」、「お客様からの難しい問い合わせに挑むために」と「生活サービスを拡充するためのデータ活用」では発表された新サービスを中心にテーマに沿った利用方法についてお話をさせていただいています。セッション後半ではモダナイゼーションを推進されている United Airlines の事例や、現地で参加された日本のお客様が現地で感じられた事をご紹介させていただきました。航空会社、鉄道会社をはじめとした交通業界で働く皆様の取り組みにお役立ていただければ幸いです。 まとめ 2024 年 1 月 30 日に開催した AWS re:Invent Recap の振り返りとして、各セッションの概要をご紹介いたしました。セミナーにご参加いただいた方、誠にありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考になりましたら幸いです。内容に関して、ご質問やご要望がございましたら、お問い合わせページ、もしくは担当営業までご連絡をお願いします。 馬渕 俊介 (Mabuchi, Shunsuke) 交通業界のお客様を支援するソリューションアーキテクト。前職では性能のスペシャリストとして従事していたため、負荷テストや性能問題分析の知見を持っています。好きな AWS サービスは Amazon CloudWatch、好きな AWS ソリューションは AWS での分散負荷テスト ソリューションです。

AWS Lambda でワークロードを設計すると、コードレベルでもインフラレベルでも表現できるモジュール性のために、開発者に疑問が生じます。また、コードを実行するためにサーバーレスを使用するには、基盤となる機能コンポーネントからビジネスロジックを抽出するためのさらなる検討が必要です。この意図的な関心の分離により、堅牢なモジュール性が保証され、進化的なアーキテクチャへの道が開かれます。 この投稿は同期ワークロードに焦点を当てていますが、他のワークロードのタイプでも同様の考慮が当てはまります。API の境界を特定し、コンシューマと API について擦り合わせた後、その境界と関連するアーキテクチャを構成します。 Lambda 関数を使用して API を構成する最も一般的な 2 つの方法は、単一責任 と Lambda-lith (Monolith な Lambda という意味の造語) です。しかし、このブログでは、これらのアプローチに代わる、両方の長所を提供できる方法を探ります。 単一責任の Lambda 関数 単一責任の Lambda 関数は、サーバーレスアーキテクチャ内で特定のタスクを実行したり、イベントによってトリガーされた特定の操作を処理したりするように設計されています: このアプローチにより、ビジネスロジックと機能の関心が強力に分離されます。特定の機能を分離してテストし、Lambda 関数を個別にデプロイし、バグが発生する可能性を減らし、 Amazon CloudWatch でのデバッグが容易になります。 さらに、単一目的の関数は、Lambda が需要に応じて自動的にスケールするため、効率的なリソース割り当てが可能になり、リソースの消費を最適化し、コストを最小限に抑えることができます。つまり、メモリサイズやアーキテクチャなど、関数ごとに利用可能な設定を変更できます。さらに、すべてのリクエストを処理する単一の Lambda 関数にトラフィックを集約するのではなく、単一のタスクのトラフィックに基づいて上限緩和を要求できるため、サポートチケットを介して関数の同時実行数の上限緩和を要求することが容易になります。 もう 1 つの利点は、実行時間の速さです。単一のタスクのために設計された単一目的の Lambda 関数のビジネスロジックでは、他のアプローチで必要な追加ライブラリを必要とせず、関数のサイズをより簡単に最適化できます。これにより、バンドルサイズが小さくなり、コールドスタートの時間を短縮できます。 このような利点がある一方で、単一目的の Lambda 関数だけに依存する場合、いくつかの問題が存在します。コールドスタートの時間は短縮されますが、特に散発的な、または呼び出し頻度が低い関数では、コールドスタートの回数が増える可能性があります。例えば、 Amazon DynamoDB テーブルのユーザーを削除する関数は、ユーザーデータを読み込む関数ほど頻繁にトリガーされることはないでしょう。また、単一目的の Lambda 関数に大きく依存することは、関数の数が増えるにつれて、システムの複雑さを増大させる可能性があります。 関心をうまく分離すると、コードベースを保守し易くなりますが、コードの凝縮度が失われます。API の書き込み操作 (POST, PUT, DELETE) など、似たようなタスクを持つ関数では、複数の関数にまたがってコードや動作が重複する可能性があります。さらに、Lambda Layer やその他の依存関係管理の仕組みを介して共有される共通ライブラリを更新する場合、単一のファイルに対するアトミックな変更ではなく、すべての関数にわたって複数の変更が必要になります。これは、ランタイムバージョンの更新など、複数の関数にまたがる他の変更にも当てはまります。 Lambda-lith: 1 つの Lambda 関数を使う 多くのワークロードで単一目的の Lambda 関数を使用すると、開発者の AWS アカウント全体で Lambda 関数が増殖してしまいます。開発者が直面する主な課題の 1 つは、共通の依存関係や関数の設定を更新することです。この問題に対処するための明確なガバナンス戦略 (依存関係の更新を強制するための Dependabot や、プロビジョニング時に取得されるパラメータ化されたパラメータの使用など) が実装されていない限り、開発者は別の戦略を選ぶかもしれません。 その結果、多くの開発チームは逆の方向に進み、API に関連するすべてのコードを同じ Lambda 関数内に集約します。 このアプローチは、API を構成するすべての HTTP メソッド、場合によっては複数の API を同じ関数にまとめるため、しばしば Lambda-lith と呼ばれます。 これにより、アプリケーションのさまざまな部分にわたって、より高いコードの凝縮度とコロケーションを実現できます。この場合のモジュール性はコードレベルで表現され、単一責任、依存性の注入、ファサードというようなパターンがコードを構造化するために適用されます。開発チームが適用する規律とコードのベストプラクティスは、大規模なコードベースを維持するために極めて重要です。 Lambda 関数の数が減ることを考慮すると、単一責任のアプローチに比べ、設定の更新や複数の API にまたがる新規格の実装がより簡単に実現できます。 さらに、すべてのリクエストはすべての HTTP メソッドに対して同じ Lambda 関数を呼び出すので、リクエストに対応する実行環境が利用できる可能性が高くなるため、呼び出し頻度の高くないコードのレスポンスタイムが向上する可能性が高くなります。 考慮すべき点をもう一箇所挙げるとすると、関数のサイズです。これは、API のすべての依存関係とビジネスロジックを持つメソッドを同じ関数内に配置すると増加します。これは、ワークロードが急増する Lambda 関数のコールドスタートに影響するかもしれません。特に、コールドスタートによって影響を受けるような厳しい SLA を持つアプリケーションの場合、顧客はこのアプローチの利点が欠点を上回っているか評価する必要があります。開発者は、使用されている依存関係に注意を払い、tree-shaking、minification、デッドコード除去などのテクニックを実装することで、この問題を軽減することができます。 このような粗いアプローチでは、関数設定を個別に調整することはできません。しかし、より高いメモリサイズや、セキュリティチームが設計した仕様に合わないほど緩いセキュリティ権限で、すべてのコードが機能するような設定を探し出さないといけなくなります 読み取り関数と書き込み関数 今までの 2 つのアプローチにはトレードオフがありますが、それぞれの利点を併せ持つ第 3 の選択肢があります。 多くの場合、API のトラフィックは読み込みと書き込みのどちらかに偏っているため、開発者はコードや構成をどちらか一方に最適化せざるを得ません。 例えば、利用者がユーザーを作成、更新、削除できるだけでなく、ユーザーやユーザーのリストを検索することもできるユーザー API を構築することを考えてみましょう。このシナリオでは、1 度に 1 人のユーザーを変更でき、一括操作は利用できませんが、API リクエストごとに 複数のユーザーを取得できます。API の設計を読み取り操作と書き込み操作に分けると、このようなアーキテクチャになります: 書き込み操作 (create, update, delete) をコードでまとめることは、多くの理由で有益です。たとえば、リクエストボディを検証し、必須パラメータがすべて含まれていることを確認する必要があるかもしれません。ワークロードが書き込みに集中している場合、あまり使用されない操作 (例えば、Delete 操作) は、ウォームスタートの恩恵を受けます。コードのコロケーションは、似たようなアクションのコードの再利用を可能にし、例えば共有ライブラリや Lambda Layer でプロジェクトを構成する際の認知負荷を軽減します。 読み取り操作の側面を見ると、この関数にバンドルされるコードを減らし、コールドスタートを高速化し、書き込み操作に比べてパフォーマンスを大幅に最適化することができます。また、Lambda 関数の実行時間を改善するために、実行環境のメモリ内にクエリ結果の一部または全部を保存することもできます。 このアプローチは、進化的なアーキテクチャではさらに効果を発揮します。プラットフォームがもっと普及した場合を想像してみてください。 ElastiCache と Redis を使った キャッシュアサイドパターン を追加することで、読み取り性能を改善し、API をさらに最適化しなければなりません。さらに、キャッシュミスの場合に読み取り機能を最適化した 2 つ目のデータベースを使用して、読み取りクエリを最適化することにしました。 書き込み側では、API のコンシューマがユーザー作成指示や削除指示の受付通知だけを受け取ることで、分散システムにおける結果整合性の恩恵を得れるかもしれません。 そこで、Lambda 関数の前に SQS キューを追加することで、書き込み操作のレスポンスタイムを改善できます。書き込みデータベースをバッチで更新することで、すべてのリクエストを個別に処理する代わりに、書き込み操作の処理に必要な呼び出し回数を減らすことができます。 コマンドクエリ責任分離 (CQRS) パターン は、データ変更、つまりシステムのコマンド部分をクエリ部分から分離する、よく知られたパターンです。スループット、遅延、または一貫性に関する要件が異なる場合は、CQRS パターンを使用して更新とクエリを分離できます。 完全な CQRS パターンから始めることは必須ではありませんが、API を大規模にリファクタリングすることなく、最初の読み書きの実装で強調されたインフラをより簡単に発展させることができます。 3 つのアプローチの比較 ここで 3 つのアプローチを比較してみましょう:   単一責任 Lambda-lith 読み込みと書き込みの分離 メリット 強い関心の分離 きめ細かな設定 デバッグのしやすさ 実行時間の速さ コールドスタートの回数が減る コードの凝縮度の向上 メンテナンスの簡素化 必要に応じたコードの凝縮度 進化的なアーキテクチャ 読み書き操作の最適化 課題 コードの重複 メンテナンスが複雑 コールドスタートの回数が多い 設定が粗い コールドスタートの時間が長い 2 つのデータモデルで CQRS パターンを利用する CQRS パターンにより、システムが結果整合性を持つようになる まとめ アーキテクチャが進化するにつれて、単一責任の Lambda 関数から Lambda-lith に移行することがよくありますが、どちらのアプローチにも相対的なトレードオフがあります。このブログでは、読み取りと書き込みの操作ごとにワークロードを分離することで、両方のアプローチの長所を活かす方法を紹介しました。 この 3 つのアプローチはいずれもサーバーレス API を設計する上で有効であり、何のために最適化するのかを理解することが、最適な決断を下すための鍵となります。アプリケーションで表現すべきコンテキストとビジネス要件を理解することが、特定のワークロード内で考慮すべきトレードオフにつながることを忘れないでください。広い視野を持ち、問題を解決し、セキュリティ、開発体験、コスト、保守性のバランスをとるソリューションを見つけましょう。 その他のサーバーレス学習リソースについては、 Serverless Land をご覧ください。 この記事は、テクニカルインストラクターの青木克臣が翻訳しました。 原文は こちら です。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）は 2023 年 7 月 3 日に、日本独自の施策として国内に法人または拠点を持つ企業・団体の生成 AI 基盤モデル・大規模言語モデル（以下、LLM）の開発を支援する AWS LLM 開発支援プログラム を発表しました。 本プログラムでは、LLM 開発を行うための計算機リソース確保に関するガイダンスや AWS 上での LLM 事前学習に関わる技術的なメンタリング、LLM 事前学習用クレジット、ビジネス支援などのサポートを提供します。 そして 2024 年 1 月 31 日に、本プログラムにおける支援対象の企業・団体が集まり成果を共有する、AWS LLM 開発支援プログラム 成果発表会が開催されました。ここではそのレポートをダイジェスト形式でお届けします。 ご挨拶 AWS ジャパン 執行役員 デジタルサービス事業統括本部 統括本部長 佐藤 有紀子 イベント冒頭では、AWS ジャパン 執行役員 デジタルサービス事業統括本部 統括本部長 佐藤 有紀子より開会のご挨拶をしました。AWS LLM 開発支援プログラムは 2023 年 7 月に開始し、これまで中間報告会や AWS ジャパンと各企業・団体とのさまざまなコミュニケーションを経たうえで今回のイベントに至りました。佐藤は本プログラムのエグゼクティブスポンサーとして、企画の段階から関わっております。 「私たちが企業・団体のみなさまとともに目指したのは、日本の生成 AI のイノベーションの加速です。日本のビジネスや言語環境、企業の状況に合った LLM が求められていると考えて、AWS LLM 開発支援プログラムを立ち上げました」と佐藤は語りました。 日本における生成 AI の利活用が本格的になっていく中で、LLM はより重要な位置付けになっていくと考えます。「プログラム実行委員から、本プログラムに関する学びをみなさまに共有させていただきたく存じます」と結びました。 AWS LLM 開発支援プログラム Program Results AWS LLM 開発支援プログラム 実行委員 宇都宮 聖子 次に、AWS LLM 開発支援プログラム 実行委員の宇都宮 聖子が登壇。本プログラムで得られた成果について、ショートサマリーをお話ししました。本プログラムでは 2023 年 7 月のプログラムローンチ以降、成果発表会まで約半年の期間で 17 社という多くの企業・団体にご参画いただきました。 セッション内で、宇都宮は多くの開発者の方々にご利用いただいた AI アクセラレーター AWS Trainium をタイムリーにサポートする AWS Neuron SDK の変遷についても言及。本支援プログラムの開始以降、AWS Neuron SDK はこのプログラムでの LLM 開発を強力にサポートすべく、2023 年 12 月までの間に多くのソフトウエアアップデートが行われたことを解説しました。 また、サービスの利用方法について実践形式で学ぶ Prototyping Camp を開催するなど、AWS ジャパンでは企業・団体の方々に効率良く開発を進めていただくための技術支援も行ってきました。2023 年 11 月には、プログラムの中間報告会にて、LLM 開発を国内でリードする技術者同士で、LLM開発の技術的な難しさやビジネス化への課題について、パネルディスカッション等を通じて技術交流を行いました。そして、2023 年 9 月以降にはプログラム参画企業合計 9 社より報道発表がリリースされました。 成果発表 Part1 ここからは、各社による成果発表がスタート。Part1 では、NTT人間情報研究所とストックマーク株式会社、株式会社リコーの 3 社が登壇しました。 NTT人間情報研究所 NTT人間情報研究所 上席研究員 西田 京介 氏 まずは NTT人間情報研究所 上席研究員 西田 京介 氏による発表。NTT グループは IOWN（Innovative Optical and Wireless Network）技術を中心として、サステナブルな社会の実現に取り組んでいます。大量の計算機資源を必要とする大きな AI ではなく、専門性や個性を持った小さな AI の集合知による社会課題解決を目指し、小型で性能の良い LLM「tsuzumi」の研究開発を行っています。 メディカル領域やソフトウエア開発といった、ドキュメント内に専門用語や業界特有の表現が多く含まれる領域においては、既存の汎用 AI では十分な性能を発揮しないケースがあります。「tsuzumi-7B」は Rakuda ベンチマークにおいて、こうした業界特有のデータに対してもカスタマイズが可能であるため、AI を活用する領域を広げることができます。 また、顧客サポート領域では顧客体験向上のために、図表などのマニュアル類の読解と顧客情報の解析によるパーソナライズが不可欠です。「tsuzumi」は世界トップクラスの日本語処理能力を有しており、かつ図表読解も可能なため、コンタクトセンターや相談チャットボットといった顧客サポート領域での活用に向いています。 プログラムの中で得られたベネフィットとして、 Amazon EC2 P5 インスタンスの利用により最新の NVIDIA H100 Tensor Core GPU 96基を迅速に調達できたこと、Elastic Fabric Adapter (EFA) の高速なノード間通信による高速・高効率な学習が行えたこと、LLM 学習ライブラリを AWS 上で技術検証することによりスムーズな環境移行を行えたこと、GPU クラスタ構築・運用のための技術支援を受けられたこと、などを紹介されていました。 ストックマーク株式会社 ストックマーク株式会社 共同創業者 CTO 有馬 幸介 氏（写真左）、VP of Research 近江 崇宏 氏（写真右） 次に登壇したのはストックマーク株式会社 共同創業者 CTO 有馬 幸介 氏とVP of Research 近江 崇宏 氏。有馬 氏は同社が LLM の自社開発を行う理由として「産業界では、ChatGPT よりもさらにハルシネーション（誤情報の出力）が抑止された信頼性の高い LLM が求められている」というモチベーションを語りました。 ハルシネーション抑止は LLM の知識量にも大きく依存します。グローバルでよく利用される LLM では学習データの 0.1% 程度しか日本語が含まれておらず、とりわけ日本国内のビジネス系知識に不足があるといいます。ストックマーク社はその品質ではエンタープライズサーチや素材・技術用途探索などのアプリケーションで顧客のニーズに応えきれないと判断し、自社開発を決意しました。 近江 氏は AWS LLM 開発支援プログラムにおける具体的な検証内容や成果などを発表。実用的なビジネス領域に対応するため、公開データだけでなくビジネスドメインの独自 Web コーパスや特許のデータを含めた、合計 2,200 億トークン日本語テキストデータを使用し、130 億パラメータ LLM をゼロから学習させたことなどを説明しました。 今回ストックマーク社は AWS Trainium を搭載した EC2 Trn1 インスタンスを用いて独自 LLM の開発を行いました。その際、trn1.32xlarge を 16 インスタンス用いることで、約 30 日といった短期間で迅速に開発が行えたといいます。また、開発した Stockmark-13b を自社サービスへ導入するため、AWS Inferentia2 による推論も検証を進めています。 株式会社リコー 株式会社リコー デジタル戦略部 デジタル技術開発センター 副所長 鈴木 剛 氏 次に株式会社リコー デジタル戦略部 デジタル技術開発センター 副所長 鈴木 剛 氏が登壇。セッション冒頭で、英語 LLM に比べて日本語 LLM の開発が遅れているという見方について触れ、産業で使い倒せる LLM を作る、すなわち、ビジネスで使える十分な品質の文章を生成できる LLM を作ることを目指して日英バイリンガル LLM を開発したことを説明しました。 リコーが重視したのは、データの質と量、そして学習戦略をいかに組み上げるかという観点です。モデルのアーキテクチャは日進月歩で新しいものが出ていますが、学習戦略やデータは企業の開発技術として注力すべきであるとし、カリキュラム学習戦略の例をご紹介頂きました。英語で学習された Llama 2 13B Chat の初期重みに、はじめから難易度の高い日本語データを多く入れても、忘却効果が出てしまいうまく学習が進みません。そのため、初期段階では英語を多く混ぜ、続いて多量低品質な英語・日本語データを投入し、最後は頑健な推論性能の底上げを狙うために高品質な日本語データを学習させるという戦略をとりました。 計算環境は Amazon EC2 Trn1 インスタンスを利用。プログラムの支援により調達した 64 インスタンスの trn1.32xlarge (1,024 Trainium チップ、2,048 Neuron コア) により、大規模な分散学習を行いました。これだけ大規模な学習になるとノード不良が避けられませんが、AWS の技術メンバーが密に並走することにより迅速な復旧が可能だったといいます。また、復旧のため実装されたノード不良検知・自動ジョブ再投入などの機能を SDK として公開するといった改善プロセスに関しても信頼と感謝の言葉を頂きました。 日本語ベンチマークツール llm-jp-eval を用いた130億パラメータ LLM との性能比較では、産業応用で重要となる論理的な推論性能に関して良好な結果を得られたといいます。今後も、本プログラムで開発した130億パラメータモデルのカスタマイズや、700億パラメータ規模のさらなる大規模モデルの開発に取り組んでいく展望を述べました。 成果発表 Part2 プログラムの後半パートでは、以下の企業が成果発表を行いました。 株式会社サイバーエージェント（左上）、Sparticle株式会社（右上）、カラクリ株式会社（左下）、株式会社Poetics（右下） 株式会社サイバーエージェント AI事業本部 極LP/基盤モデル事業部 石上 亮介 氏 ●  AWS Trainium による LLM 開発の技術・次世代アーキテクチャ検証。学習データに含まれる日本語・英語の割合を変えた性能や、Grouped Query Attention (GQA) への拡張。RetNet や Sparse Mixture of Experts (MoE) などのアーキテクチャ検証。 Sparticle株式会社 執行役員 藤井 秀樹 氏 ●  音声認識に加えて視覚情報を含めたマルチモーダル AI 開発を目指す。本プログラムでは独自 LLM により高い日本語性能を達成。自律型エージェントの実現も視野に入れる。 カラクリ株式会社 取締役 CPO 中山 智文 氏 ●  カスタマーサポート領域での AI Chat 提供。Llama 2 70B をベースとした事前学習とファインチューニングを、独自収集カスタマーサポートコーパスを含むデータで実施。Japanese MT-Bench において日本語モデルの中で最高性能。 株式会社Poetics AIエンジニア・NLPリサーチャー 河東 宗祐 氏 ●  オンライン商談解析サービス Jamroll を提供。自動音声書き起こし (Automatic Speech Recognition; ASR) 話し言葉データを用いた、対話に特化した LLM の開発。4台の trn1.32xlarge を用いて、NeuronX Distributed による分散学習で Llama 2 7B を継続事前学習。 株式会社松尾研究所（左上）、株式会社リクルート（右上）、株式会社わたしは（左下）、株式会社Lightblue（右下） 株式会社松尾研究所 リサーチエンジニア　松島 創一郎 氏 ●  東京大学大学院工学系研究科松尾研究室とビジョンを共有しながら先端技術の社会実装を行なっており、本プログラムではリテール業界や旅行業界などに向けた LLM を用いた推薦システムに取り組んだ。推薦候補をユーザーに提示する前にリランキングを行う LLM を開発。旅行・予約サイトのデータを用いて、ELYZA-japanese-Llama-2-7b をベースに学習。 株式会社リクルート データ推進室 桐生 佳介 氏 ●  リクルートが提供する顧客・クライアントの接点を作るプロダクトにおいて、労働人口減少に伴うスケーラビリティに課題があり、ビジネスドメイン特化の LLM でユーザー体験の向上を見込む。ELYZA-japanese-Llama-2-7b-fast と Llama-2-13b-chat-hf に対して、オープンデータと自社コーパスを用いて継続学習と Instruction Turing を実施し、継続事前学習を施した自社モデルで QA 回答と文章要約の性能向上を確認。AWS Trainium の使用感として良かった点で、インスタンス確保が柔軟であったことと AWS ParallelCluster による分散学習環境構築の容易さが挙げられた。 株式会社わたしは CTO 小橋 洋平 氏 ●  ユーモアを志向し、ズレた会話を扱える基盤モデルの開発と、大喜利 AI など目的に応じたチューニングを実施。EC2 trn1.32xlarge を 4 インスタンス用いた分散学習で Llama 2 13B に対して継続事前学習を行い、ファインチューニングと DPO により大喜利 AI を構築。このモデルによる日本語・英語での大喜利性能について、いくつか例が紹介された。 株式会社Lightblue 取締役 谷口 俊一 氏 ●  特定業務・タスク特化の LLM を志向し、推論コストにおける優位性も期待できる小規模軽量 LLM を開発。TinyLlama-1.1B をベースモデルとし、独自日本語コーパスを用いた AWS Trainium での継続事前学習により Karasu-1.1B を開発。AWS VPN や AWS Direct Connect (専用線接続) などの閉域網での提供を検討。 Turing株式会社（左上）、株式会社ユビタス（右上）、rinna株式会社（左下）、株式会社Preferred Networks（右下） Turing株式会社 Director of AI 山口 祐 氏 ●  完全自動運転を目指し、運転時の外部情報として LLM に視覚を与える学習フレームワーク Heron を開発。NVIDIA H100 GPU を搭載した EC2 p5.48xlarge インスタンスにより、画像 + LLM の 70.3B マルチモーダル基盤モデルのフルパラメータファインチューニングを実施。また、自動運転用データセットの生成・評価にも p5.48xlarge インスタンスを活用。 株式会社ユビタス 大畑 浩司 氏 ●  エンターテイメント (ゲーム・アニメ・映画) や観光・レジャーに特化した LLM や Graph Diffusion Model を開発。国立台湾大学との共同研究による台湾 LLM 13B (Taiwan-LLM-13B-v2.0-base) の開発・公開や、ユビちゃん (ゲーム攻略アシスタントなどに使われる AI キャラクター) の開発で AWS を活用。 rinna株式会社 Research and Data Manager 沢田 慶 氏 ●  中国語・英語を主データとして学習された Qwen モデルをベースに継続事前学習。Nekomata 14B は Qwen 14B に対して 66B トークンの日本語データで継続事前学習、EC2 trn1.32xlarge で 16インスタンス約6.5日、オンデマンド価格で800万円ほど、LLM プログラムの支援をうけ実施。SFT による対話応答や 4bit 量子化版も含め 7B, 14B モデルを公開。 株式会社Preferred Networks Karim Hamzaoui 氏 ●  本プログラムでは画像のモダリティを扱える汎用的な視覚基盤モデルを開発。画像タスクの学習には大容量メモリを必要とするため、NVIDIA H100 Tensor Core GPU (80 GB GPU メモリ) を搭載した EC2 p5.48xlarge インスタンスを活用し複数タスクの表現方法、タスクの学習順番・バランス、言語と画像のアラインメントの効率化などに取り組んだ。今後も本プログラムで確立した開発手法を踏まえ、100B/1T パラメータからなる PLaMo をベースとしたマルチモーダル基盤モデルの開発を推進。 ご講評 経済産業省 商務情報政策局 情報産業課 ソフトウエア・情報サービス戦略室長 渡辺 琢也 氏（写真左） 経済産業省 商務情報政策局 情報産業課企画官 小川 宏高 氏（写真右） 各社による成果発表の後、経済産業省 商務情報政策局 情報産業課 ソフトウエア・情報サービス戦略室長の渡辺 琢也 氏がコメントをしました。近年、LLM は大きな注目を集めています。渡辺 氏は、これまでの人類の歴史のなかで自動車やパソコン、スマホといった人間の能力をエンパワーメントするような技術がイノベーションを起こしてきたことについて触れ「間違いなく、LLM は次のイノベーションを起こす可能性を秘めた技術です。だからこそ世界中で注目されているのでしょう」と述べました。 そして、今後の日本で発生する労働者不足の課題を解決するうえでも、LLM を活用して生産性を向上させることが重要であると言及。「計算資源をはじめとしたインフラの確保や、開発者同士やユーザーとのネットワーキング構築の機会の創出、イノベーションを阻害しないルールの創設は政府の責務だと思っております」と語りました。 続いて、経済産業省 商務情報政策局 情報産業課企画官 小川 宏高 氏は登壇した各社のプレゼンテーションを講評。スクラッチでのモデル開発や継続事前学習、ファインチューニング、各種の技術検証など、各社がそれぞれの強みを活かして研究・開発を行っていることに対して「みなさまの技術力の高さに、大変心強い思いをしております」と総括しました。 ご挨拶 AWS ジャパン 代表執行役員社長 長崎 忠雄 イベント最終盤では、AWS ジャパン 代表執行役員社長 長崎 忠雄がご挨拶をしました。お集まりいただいた関係者の方々に感謝の言葉を伝えたうえで「本日で AWS LLM 開発支援プログラムは終了しますが、LLM の開発はこれで終わりではありません。技術の社会実装が肝であるため、私たち AWS は引き続き各企業・団体を支援していきます」と述べました。 そのうえで、「LLM の社会実装ができるようになれば、それがひいては日本の国力の向上につながります。私たち AWS が、日本そのものの進歩に貢献できればと思っております」と結びました。

この記事は、James Eastham、Norm Johanson、Ulili Nhaga が寄稿しました。日本語訳はソリューションアーキテクトの遠藤宣嗣が翻訳しました。原文は こちら です。 はじめに .NET 8 は、2023 年 11 月にリリースされたクロスプラットフォーム .NET の最新の長期サポート (LTS) バージョンです。.NET 8 にはパフォーマンスの改善、コンテナの拡張機能、C# 言語の簡略化された構文、フルスタック Web アプリケーションのための Blazor サポート、ネイティブ Ahead of Time コンパイル  (Native AOT) の ASP.NET Core での部分サポートが含まれています。この記事では、.NET 8 をサポートする AWS コンピューティングサービスとツールを確認し、開発者向けのリソースを紹介します。 .NET の古いバージョンを実行している場合、.NET 7 と .NET 6 の両方が 2024 年にサポート終了となることに注意してください。 Microsoft の .NET サポートポリシー によると、.NET 7 のサポートは 2024 年 5 月 14 日に、.NET 6 のサポートは 2024 年 11 月 12 日に終了します。.NET 8 のサポートは 2026 年 11 月 10 日までです。 コンピューティング サービス ワークロードがセルフマネージド型のもの、マネージドサービス上で実行されるもの、コンテナを使用するもの、サーバレスなものに関わらず、AWS 上で .NET 8 を使用できます。.NET 8 は現在、 Amazon Elastic Compute Cloud (Amazon EC2)、 AWS Elastic Beanstalk 、 Amazon Elastic Container Service (Amazon ECS)、 Amazon Elastic Kubernetes Service (Amazon EKS)、 AWS App Runner 、 AWS Lambda 上で実行できます。 Amazon EC2 Amazon EC2 は、プロセッサ、ストレージ、ネットワーキングの選択してインフラストラクチャを細かく管理できる、広範囲で高度なコンピューティング機能を提供します。お客様は 400 を超える インスタンスタイプ で .NET 8 をインストールできます。 EC2 インスタンスに .NET 8 をインストールするには、インスタンスの起動時に ユーザーデータ コマンドを指定します。 次の例は、Amazon Linux 2023 インスタンスに .NET 8 をインストールする方法を示しています。 #!/bin/bash sudo rpm  --import   https://packages.microsoft.com/keys/microsoft.asc sudo wget  -O  /etc/yum.repos.d/microsoft-prod.repo https://packages.microsoft.com/config/fedora/37/prod.repo sudo dnf install  -y dotnet-sdk-8.0 dotnet  --version  > /tmp/dotnet-version Linux への.NET のインストール方法は、 https://learn.microsoft.com/ja-jp/dotnet/core/install/linux#packages で確認できます。.NET のインストールスクリプトは、 https://learn.microsoft.com/ja-jp/dotnet/core/install/linux-scripted-manual#scripted-install で入手できます。 AWS Systems Manager サービスの自動化機能を使用して、オートメーションドキュメントを使って .NET ランタイムを自動的にインストールできます。また、 EC2 Image Builder サービスを使用して、.NET ランタイムがプリインストールされた EC2 イメージを事前に作成できます。 AWS Elastic Beanstalk Elastic Beanstalk は、アプリケーションを実行するインフラストラクチャーを意識することなく、AWS クラウドでアプリケーションをすばやくデプロイおよび管理できるマネージドサービスです。EC2 リソースは AWS アカウントですべて表示され、それらにアクセスできます。 2023/12/05 のプラットフォームアップデート より、Elastic Beanstalk Windows が .NET 8 をサポートするようになりました。 Elastic Beanstalk Linux はこの記事を書いている時点で .NET 6 ランタイムをサポートしていますが、次のいずれかのオプションを使用して .NET 8 をデプロイできます: .NET Core on Linux プラットフォーム用のアプリケーションのバンドル  (AWS) および .NET アプリケーションの発行の概要 (Microsoft) で説明されている自己完結型アプリケーションを提供できます。Elastic Beanstalk Linux で .NET 8 を使用するもう 1 つの方法は、 Docker コンテナからのデプロイ です。 AWS Lambda AWS Lambda は .NET 8 ランタイムをサポートしています。AWS Lambda コンソールには、図 1 に示すように、.NET 8 (C#/F#/PowerShell) のランタイムオプションがあります。.NET 8 の Lambda 関数の作成と更新、およびネイティブ AOT の使用の詳細については、 AWS Lambda の .NET 8 ランタイムのご紹介（英文） を参照してください。 AWS Lambda で .NET 8 アプリケーションを実行するその他の方法もあります。 カスタムランタイム を作成したり、 コンテナーをデプロイ したり、.NET 8 のネイティブ AOT コンパイルを使用してネイティブコードを Lambda に公開することができます。 図1: AWS Lambda コンソールの .NET 8 オプション ビデオ: .NET 8 ネイティブ AOT Lambda 関数を構築する最もシンプルな方法 ブログ: .NET 7 を使用して AWS Lambda でサーバーレスの .NET アプリケーションを構築する AWS .NET Lambda パッケージ が .NET 8 をターゲットに更新され、ネイティブ AOT の警告に対処するようになりました。これにより、ネイティブ AOT Lambda 関数でそれらをより簡単かつ安全に使用できるようになります。 .NET Lambda アノテーション フレームワークは、プログラミング モデルを簡素化し、C# でより自然に .NET Lambda 関数を記述できるようにします。カスタム ランタイムやネイティブ Ahead of Time コンパイル (Native AOT) を使用する場合、このフレームワークにより、 Lambda ランタイムを手動でブートストラップする必要がなくなり、Main メソッドを自動生成できます。詳細は、 .NET Lambda アノテーション設計 – Main の自動生成 を参照してください。 コンテナ Windows または Linux コンテナ上で実行される .NET アプリケーションを、 Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (EKS) にデプロイできます。 AWS Fargate は、コンテナインフラストラクチャを自分で管理する必要なく、ECS および EKS コンテナのライフサイクルを実行および管理するために使用できるサービスです。 AWS App Runner は、コンテナ化された Web アプリケーションや API をすぐにデプロイできる、フルマネージドなサービスです。トラフィックのニーズに応じて自動的にスケールアップ/ダウンします。.NET 8 アプリケーションで使用するには、.NET 8 アプリケーションのイメージを Amazon Elastic Container Registry (ECR) にアップロードし、 ソースイメージ のサポートを利用して、AWS App Runner がアプリケーションの起動、実行、スケール、ロードバランシングを設定します。 .NET 8 アプリケーションをコンテナ内に Elastic Beanstalk にデプロイできます。詳細は、 Docker コンテナからの Elastic Beanstalk アプリケーションのデプロイ を参照してください。 セキュリティと診断 AWS X-Ray AWS X-Ray は、マイクロサービスアーキテクチャを使用して構築された分散アプリケーションなどを分析およびデバッグするのに役立ちます。.NET 8 アプリケーションは、 .NET 用 AWS X-Ray SDK と OpenTelemetry .NET 用 AWS ディストリビューション を使用して、AWS X-Ray と統合できます。 現時点では、ネイティブ AOT .NET アプリケーションで AWS X-Ray を使用することはおすすめしません。 ツール、ライブラリ、SDK AWS で古いバージョンの .NET を使用していた場合は、開発マシンにインストールされている AWS ツールを更新することをおすすめします。 .NET 用 AWS SDK AWS SDK for .NET を使用すると、.NET 開発者は AWS サービスをアプリケーションコードに親しみやすく一貫した方法で統合できます。バージョン 3.7.300 から、SDK に .NET 8 ターゲットフレームワークが追加され、すべてのトリミング警告に対処することでネイティブ AOT との互換性が実現しました。このライブラリは NuGet から利用できます。 開発者ーガイド の AWS SDK for .NET の使用方法をご覧ください。 AWS CodeBuild AWS CodeBuild は、開発者がソースコードから自動的にアプリケーションをビルドできるように支援する、フルマネージドなサービスです。CodeBuild サービスでは、ビルドしているアプリケーションのニーズに合わせて、ビルド環境をカスタマイズできます。これには、追加の .NET ランタイムをインストールする機能が含まれます。アプリケーションの buildspec.yml ファイルに次のスニペットを追加することで、.NET 8 アプリケーションのビルドをサポートできます。 install: commands: - curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --channel 8.0 これにより、CodeBuild のインストールフェーズの一部として、.NET 8 SDK が自動的にダウンロードおよびインストールされます。 AWS Deploy Tool for .NET AWS Deploy Tool for .NET コマンドラインインターフェース (CLI) は、.NET アプリケーションのコンピューティング推奨事項を提供し、数ステップで AWS にデプロイする対話型アシスタントです。Deploy Tool は、Amazon ECS や AWS App Runner などのコンテナベースのサービス用にコンテナイメージを作成したり、Elastic Beanstalk で .NET の自己完結型パブリッシングを使用することにより、.NET 8 アプリケーションをサポートします。 AWS Toolkit for Visual Studio AWS Toolkit for Visual Studio は、Windows の Microsoft Visual Studio 向けの拡張機能で、開発者が Amazon Web Services を使用して .NET アプリケーションをより簡単に開発、デバッグ、デプロイできるようにします。Visual Studio 2022 は .NET 8 開発をサポートしています。 図2: Visual Studio の .NET 8プロジェクト Toolkit の Publish to AWS 機能は、.NET 用の AWS Deploy Tool と統合されており、Visual Studio からさまざまな AWS サービスに .NET 8 プロジェクトをデプロイできます。ASP.NET Core プロジェクトを Amazon ECS、AWS App Runner、Elastic Beanstalk Windows、Elastic Beanstalk Linux、または Amazon Elastic Container Registry (Amazon ECR) にデプロイできます。 図3: Toolkit for Visual Studio を使用した .NET 8 ASP.NET Core プロジェクトの AWS への公開 Visual Studio 2022 用の AWS Toolkit は、 Visual Studio Marketplace からダウンロードできます。 すでに Visual Studio 用の AWS Toolkit を使用している場合は、Visual Studio の 拡張機能の管理 > 更新の確認 から最新バージョンにアップグレードすることをおすすめします。 .NET モダナイゼーションツール AWS は、アーキテクト、開発者、IT プロフェッショナルが .NET ワークロードをモダナイズするのに役立つ支援ツールを提供しています。現在、次の AWS モダナイゼーションツールが .NET 8 をサポートしています: AWS App2Container (A2C) は、アプリケーションをコンテナ化するコマンドラインツールです。 正しい依存関係、ネットワーク構成、Amazon ECS または Amazon EKS のデプロイ手順を使用して構成されたコンテナイメージを自動的に生成します。 A2C は現在 .NET 8 ランタイムバージョンを検出できるようになり、対応するランタイムベースイメージを使用してアプリケーションをコンテナ化できます。 AWS Microservice Extractor for .NET は、人工知能とヒューリスティックを使用してモノリシックコードを評価、可視化し、マイクロサービスの候補を推奨するアドバイザーとして機能する支援ツールです。また、マイクロサービスの抽出を簡素化するロボットビルダーとしても機能します。Microservice Extractor は現在、.NET 8 アプリケーションの解析、グルーピング、抽出をサポートしています。統合されたストラングラーフィグポーティング機能により、数百のプロジェクトと数千のクラスで構成される大規模な .NET Framework ベースのアプリケーションを管理可能なグループに分割し、それらを直接 .NET 8 に移植することもできます。 Migration Hub Strategy Recommendations (MHSR) は、アプリケーションの実行可能なトランスフォーメーションパスの戦略的な推奨を提供することで、移行とモダナイゼーションの取り組みの計画を支援します。MHSR は現在 .NET 8 アプリケーションを検出し、推奨を提供できるようになりました。 AWS Toolkit for .NET Refactoring は、レガシーな .NET アプリケーションを AWS 上のクラウドベースの代替手段にリファクタリングするのに役立つ Visual Studio 拡張機能です。 互換性アセスメントレポートを提供し、コードの移植を支援します。.NET Refactoring Toolkit は現在、アセスメント、移植、テストデプロイの対象として .NET 8 をターゲットにできます。 AWS で .NET ワークロードの計画、移行、モダナイゼーションを行う際、これらの支援ツールを使用することで .NET 8 を最大限活用できます。.NET のモダナイゼーションのユースケースとツールの詳細は、AWS 上の .NET 開発者センターの「 AWS で .NET ワークロードをモダナイズ 」をご覧ください。 まとめ AWS のさまざまなコンピューティングサービス上で、今すぐ .NET 8 ワークロードを実行できます。.NET 用 SDK、複数の開発者向けツール、複数の .NET モダナイゼーションツールも .NET 8 をサポートしています。.NET 6 または .NET 7 上で既存の AWS ワークロードがある場合は、サポート終了に至る前に .NET 8 へのアップグレードを積極的に行うことをおすすめします。AWS の .NET 関連の最新情報については、AWS の .NET デベロッパーセンター をご覧ください。 投稿者について David Pallmann AWS の EC2 チームのシニアプロダクトマネージャーです。彼のミッションは、AWS を .NET 開発者にとってワールドクラスのエクスペリエンスにすることです。David は以前、エンジニアリング、コンサルティング、プロダクト、テクニカルマネージャの役割を担っていました。彼は WCF に取り組み、後に最初の .NET ベースのエンタープライズサービスバスである Neuron ESB を開発しました。X では @davidpallmann でフォローしてください。

3月7日は、 Amazon Relational Database Service (Amazon RDS) のすべてのデータベースエンジンに使用できるプロビジョンド IOPS (PIOPS) io2 Block Express ストレージボリュームの提供が開始されたことを皆さんにお知らせしたいと思います。Amazon RDS は、データベースワークロードのパフォーマンス要件に応じてさまざまなストレージタイプから選択する柔軟性を提供します。io2 Block Express ボリュームは、低レイテンシーで優れたパフォーマンスとスループットを必要とするミッションクリティカルなデータベースワークロード向けに設計されています。 I/O 集約型ワークロードのための低レイテンシーと高可用性 io2 Block Express ボリュームを使用することで、データベースワークロードは安定したミリ秒未満のレイテンシーと、io1 ボリュームよりも優れた 99.999 パーセントの耐久性からメリットを得るだけでなく、プロビジョニングされたストレージからは、io1 と同じ価格で 20 倍の IOPS (1 GBあたり最大1,000 IOPS) も実現できます。io1 ボリュームから io2 Block Express ボリュームへのアップグレードはダウンタイムなしで実行できるため、アプリケーションのパフォーマンスと信頼性が大幅に向上する一方で、ストレージコストは増加しません。 デジタル製品を設計して構築するチームのための主要プラットフォームである Figma のエンジニアリングディレクターを務める Samir Goel 氏は、このように語っています。「2 週間以内で主な Amazon RDS インスタンスのすべてを io2 Block Express に移行しました。 Io2 Block Express は、Figma のデータベースレイヤーの可用性に大きな影響をもたらしています。私たちは io2 Block Express によるパフォーマンスの一貫性を高く評価しており、当社の観測によると、レイテンシーの変動は 0.1 ミリ秒未満です」。 io2 Block Express ボリュームは、最大 64 TiB のストレージ、最大 256,000 のプロビジョンド IOPS、4,000 MiB/秒の最大スループットをサポートします。io2 Block Express ボリュームのスループットは、プロビジョンド IOPS の量とボリュームストレージのサイズに応じて異なります。各データベースエンジンとストレージサイズの対応範囲は以下のとおりです。 データベースエンジン ストレージサイズ プロビジョンド IOPS 最大スループット Db2、MariaDB、MySQL、PostgreSQL 100 GiB から 65,536 GiB まで 1,000～256,000 IOPS 4,000 MiB/秒 Oracle 100 GiB から 199 GiB まで 1,000～199,000 IOPS 4,000 MiB/秒 Oracle 200 GiB から 65,536 GiB まで 1,000～256,000 IOPS 4,000 MiB/秒 SQL Server 20 GiB から16,384 GiB まで 1,000～64,000 IOPS 4,000 MiB/秒 io2 Block Express ボリュームの使用開始方法 Amazon RDS コンソール を使用して、io2 Block Express ボリュームを使用して設定された新しい RDS インスタンスを作成するか、io1、gp2、または gp3 ボリュームを使用する既存のインスタンスを変更することができます。 以下は、io2 Block Express ボリュームを使用して Amazon RDS for PostgreSQL インスタンスを作成する方法です。 まず、エンジンやバージョンなどの基本情報から始めます。次に、 [ストレージタイプ] オプションから [プロビジョンド IOPS SDD (io2)] を選択します。 以下の AWS CLI コマンドを使用して、io2 Block Express ボリュームを使用する新しい RDS インスタンスを作成します。 aws rds create-db-instance --storage-type io2 --db-instance-identifier new-db-instance --db-instance-class db.t4g.large --engine mysql --master-username masteruser --master-user-password <enter password> --allocated-storage 400 --iops 3000 同様に、io2 Block Express ボリュームを使用するように既存の RDS インスタンスを変更するには、以下のコマンドを実行します。 aws rds modify-db-instance --db-instance-identifier existing-db-instance --storage-type io2 --allocated-storage 500 --iops 3000 --apply-immediately 知っておくべきこと io2 Block Express ボリュームは、 AWS Nitro System インスタンスを使用するすべての RDS データベースで利用できます。 io2 Block Express ボリュームがサポートする、IOPS と割り当てられたストレージとの比率は 1000:1 です。例を挙げると、RDS for PostgreSQL インスタンスでは、256 GiB 以上のボリューム で最大 IOPS をプロビジョニングできます(1,000 IOPS × 256 GiB = 256,000 IOPS)。 AWS Nitro System を基盤としない DB インスタンスでは、IOPS と割り当てられたストレージとの比率は 500:1 です。この場合は、512 GiB のボリュームで最大 IOPS を実現できます (500 IOPS x 512 GiB = 256,000 IOPS)。 今すぐご利用いただけます Amazon RDS io2 Block Express ストレージボリュームは、すべての RDS データベースエンジンでサポートされており、米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ストックホルム)、および中東 (バーレーン) の各リージョンで利用できます。 io1 ボリュームと io2 Block Express ストレージボリュームの料金と請求に関しては、どちらも同じ料金で請求されます。詳細については、 Amazon EBS の料金 ページを参照してください。 プロビジョンド IOPS SSD ストレージの詳細については、「 Amazon RDS ユーザーガイド 」をお読みください。 — Abhishek 原文は こちら です。

AWS ヒーロー は、人々のインスピレーションとなるソートリーダーであり、努力を惜しむことなくさまざまな方法で知識を共有しています。地域のミートアップ、 AWS Community Day 、re: Invent のイベントでは、ヒーローたちが講演しているのを見ることができます。これらのテクニカルエキスパートたちは、学ぶことを決してやめず、問題の解決と、コミュニティが AWS でよりすばやく構築することを可能にするコンテンツの作成に情熱を注いでいます。3月6日は、2024 年最初のヒーローたちを発表したいと思います。 新しいヒーローに拍手を送りましょう! Awedis Keofteian 氏 – レバノン、ベイルート コミュニティヒーローである Awedis Keofteian 氏は、Anghami で DevOps エンジニアを務めています。DevOps で優れた実績を積んできた Keofteian 氏は、最新のテクノロジーを活用して Anghami のクラウドベースアーキテクチャのスケーラビリティ、信頼性、効率性を向上させています。Keofteian 氏 は AWS コミュニティビルダーとしてスタートしましたが、やがてベイルートで AWS User Group のリーダーとしての役割を担うようになりました。AWS コミュニティを育成し、成長をサポートすることに情熱を注いでおり、DevOps、自動化、サーバーレス、クラウドテクノロジーの全体におよぶ知識を共有しています。 Daniel Aniszkiewicz 氏 – ポーランド、ヴロツワフ セキュリティヒーローである Daniel Aniszkiewicz 氏 は、Algoteque International Hub でシニアソフトウェアエンジニアを務めています。Wrocław AWS User Group の共催者である Aniszkiewicz 氏は、地域の AWS コミュニティの成長とエンゲージメントへの貢献に情熱を注いでいます。Aniszkiewicz 氏 は経験豊富な講演者でもあり、re: Invent、AWS ミートアップ、AWS Community Day でのプレゼンテーションなど、知識を他の人と共有することが好きです。特に、ワークショップ、ブログ記事、IaC テンプレート、オープンソースプロジェクトを通じた Amazon Verified Permissions と Cedar の推薦に焦点を合わせています。 Hazel Sáenz 氏 – グアテマラ サーバーレスヒーローである Hazel Sáenz 氏 は、Cognits でソフトウェアアーキテクトを務めています。Sáenz 氏の主な焦点は、AWS を使用してオンプレミスアプリケーションをクラウド環境にモダナイズすることであり、主にサーバーレスフレームワークで高負荷アーキテクチャを設計しています。Sáenz 氏は、地域および国際イベントでのテックトーク、AWS Summit、AWS Community Day、ミートアップへの参加、英語とスペイン語両方での技術論文の執筆を通じてコミュニティと知識を共有することを楽しんでいます。また、Sáenz 氏は AWS User Group Guatemala のリーダーでもあり、インクルーシブなイベントの企画やコミュニティとの知識の共有で能力を発揮しています。 後藤健太氏 – 日本、東京 DevTools ヒーローである 後藤健太氏 は、バックエンドテクニカルリードを務めるだけでなく、AWS CDK の熱心なコントリビューターでもあります。後藤氏は、AWS CDK のトップコントリビューターおよび信頼の置けるレビュアーとして選出されており、コミュニティ主導の CDK Construct ライブラリのメンテナーとしての役割も果たしています。カンファレンス講演者でもあり、2022 年と 2023 年に日本で開催された AWS Dev Day でプレゼンテーションを行いました。後藤氏はさらに、自作の AWS ツールや AWS CDK Construct ライブラリを開発および公開することで、オープンソースコミュニティに積極的に貢献しており、これらは世界中で使用されています。 Martin Damovsky 氏 – チェコ共和国、プラハ コミュニティヒーローである Martin Damovsky 氏 は、UDM (Unified Data Management) ソリューションを提供する AWS パートナー、Ataccama.com でクラウドガバナンスリードを務めています。AWS Control Tower Account Factory for Terraform、Cloud Intelligence Dashboard の他、 AWS Security Hub 、 Amazon GuardDuty 、 AWS Config などのセキュリティツールやガバナンスツールに特に関心を持っています。Damovsky 氏は AWS User Group Prague のリーダーであり、ブログやミートアップ、ポッドキャスト、カンファレンスでの講演を通じて、より広範な AWS コミュニティと知識を共有することを楽しんでいます。 Rafał Mituła 氏 – ポーランド、ワルシャワ コミュニティヒーローである Rafał Mituła 氏 は、Chaos Gears の Data & AI 部門でクラウドエンジニア兼アーキテクトを務めています。Mituła 氏は AWS コミュニティに積極的に参加しており、AWS User Group Warsaw のミートアップや AWS Community Day Poland カンファレンスを共催しています。Mituła 氏は、技術的および組織的な役割以外にも、カンファレンスで講演したり、AWS Data Engineering Immersion Day などの AWS とデータ分析を新しいビルダーに紹介することを目的としたワークショップをリードしたりすることで、専門知識を共有しています。 Sena Yakut 氏 – トルコ、イズミル セキュリティヒーローである Sena Yakut 氏 は、Lyrebird Studio でシニアクラウドセキュリティエンジニアを務めています。クラウドセキュリティの修士号を修めた Yakut 氏は、アーキテクチャ設計のためのセキュリティ要件を策定することで、AWS を使用した脅威管理、セキュリティ概念、およびサービスを提供しています。Yakut 氏は、さまざまなプラットフォーム全体でのブログ記事を通じて知識を共有しており、AWS Community Day Türkiye や DevOps Days Istanbul などのイベントでクラウドセキュリティに関するディスカッションに参加しています。活発なブロガーであり講演者でもあるYakut 氏は、AWS の新しいセキュリティ機能について学び、それらを他の人に伝えることを楽しんでいます。 Tiago Rodrigues 氏 – ポルトガル、リスボン コミュニティヒーローである Tiago Rodrigues 氏 は、AWS プレミアパートナー兼 AWS アドバンストトレーニングパートナーである tecRacer.com でシニアクラウドコンサルタントを務めており、オンプレミス環境からクラウドへの移行、アーキテクチャのモダナイゼーション、およびサーバーレスソリューションの実装を専門としています。その役割以外にも、知識の共有に熱心に取り組んでおり、AWS User Group Lisbon、教育ワークショップ、大学でのゲスト講義などの活動を通じて AWS コミュニティに積極的に貢献しています。教育とイノベーションに情熱を注いでいる Rodrigues 氏は、オープンソースのモバイルアプリである AWSary を開発しました。これは、ソリューションアーキテクチャダイアグラムと、AWS サービスに関するわかりやすいインサイトを提供するために設計された AWS ディクショナリです。 詳細はこちら AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローウェブサイト をご覧ください。 — Taylor 原文は こちら です。

このブログは 2023 年 11 月 24 日に Justin Leto (Sr. Solutions Architect) 、Emad Tawfik (Senior Solutions Architect) 、Juha Sarimaa (Senior Solutions Architect Storage Specialist) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 企業がクラウドガバナンスのプラクティスを進化させるにつれて、別のアカウントで作業する複数のチームがデータを共有する必要が生じる場合があります。 あるチームがあるアカウントでエンタープライズデータレイクを管理している一方で、データサイエンスチームが別のアカウントで高性能コンピューティング (HPC) のユースケースを開発している場合があります。お客様は低コストのオブジェクトストレージを活用し、追加でデータをコピーすることなく、高性能ファイルシステムから迅速にこのデータを利活用し、 HPC ユースケースをサポートしたいと考えています。 Amazon FSx for Lustre は、AWS 上の機械学習 (ML) と高性能コンピューティング (HPC) のユースケースを加速するための重要な構成要素となっています。Amazon FSx for Lustre は、サブミリ秒のレイテンシー、最大数百 GB / 秒のスループット、数百万 IOPS を提供する、完全に POSIX 準拠の高性能ファイルシステムです。 これは Amazon Simple Storage Service (Amazon S3) とシームレスに統合されており、クラウド利用者に S3 データセットへのシームレスなアクセス提供し、コールドデータセットのコスト効率性を向上させます。 本記事では、Amazon FSx ファイルシステムと Amazon S3 バケットが同一 AWS リージョン内の異なる AWS アカウントに存在する際の、Amazon FSx for Lustre ファイルシステムを Amazon S3 データレイクとシームレスに統合するプロセスを紹介します。このソリューションでは、中央のエンタープライズデータレイクから専門チームのアカウントにデータを共有し、ML や HPC のユースケースでそのデータを利活用することにより、 AWS 環境をスケールさせることができます。 ソリューションの概要 次のソリューションのアーキテクチャ図は、2 つのアクセス許可の問題への対処を表しています。1 つ目は、初期ロードのために別のアカウントの Amazon S3 バケットから読み取ることを Amazon FSx for Lustre に許可します。2 つ目は、データの同期を維持するために継続的な変更をレプリケートするためにファイルシステムがバケットに対する put の通知を受信することを許可します。 前提条件 本ソリューションをデプロイするには、次のものが必要です。 2 つの AWS アカウント。利用可能なアカウントを 2 つ持っていない場合は、 AWS アカウント作成の流れ より作成できます。 ソリューションの実装 本セクションでは、 Data Repository Association (DRA) を使用して、 ACCOUNT-A の Amazon FSx for Lustre ファイルシステムを ACCOUNT-B の Amazon S3 バケットと統合する方法について説明します。 ステップ 1: Amazon FSx ファイルシステムを作成する ステップ 2: ソースバケットを作成する ステップ 3: データリポジトリの関連付けを作成する ステップ 4: バケットポリシーを設定する ステップ 1: Amazon FSx ファイルシステムを作成する ACCOUNT-A で、US East (バージニア北部) リージョンにいることを確認し、Amazon FSx コンソールに移動してください。 1. ファイルシステムを作成 をクリックします。 次の画面で、さまざまなタイプの Amazon FSx ファイルシステムが表示されます。 Amazon FSx for Lustre を選択し、 次へ をクリックします。 2. 次の画像に示すように、 ファイルシステム名 、 ストレージキャパシティ を入力し、 データ圧縮タイプ を LZ4 に設定します。 3. ネットワークとセキュリティ のセクションで、新しいファイルシステムの Virtual Private Cloud (VPC) 、 VPC セキュリティグループ 、 サブネット を選択します。 選択したセキュリティグループは、同じ VPC 内の Amazon EC2 インスタンスが Amazon FSx ファイルシステムをマウントできるように、Amazon FSx for Lustre トラフィック(TCP ポート 988、1018-1023)へのインバウンドアクセスを許可する必要があります。詳細については、 FSx for Lustre ユーザーガイド の Amazon VPC を使用したファイルシステムアクセスコントロール のドキュメントを参照してください。 Amazon FSx は、Amazon S3 バケットにリンクされたファイルシステムのバックアップをサポートしていないので、新しいファイルシステムのバックアップを無効にする必要があります。 4. バックアップとメンテナンス セクションで, 無効 を選択し、 次へ をクリックします。 5. オプションが正確であることを確認し、 ファイルシステムを作成 をクリックしてください。初期化には数分かかります。ファイルシステムが利用可能になると、ステータスが 利用可能 と表示されます。 ステップ 2: ソース S3 バケットの作成 ACCOUNT-B に Amazon S3 バケットを作成します。バケットの作成の詳細な手順は、 Amazon S3 ユーザーガイド の バケットの作成 をご覧ください。 今回の例では、US East (バージニア北部)リージョンを選択し、バケットの名前を「new-lustre-file-system」とします。次のセクションでデータリポジトリの関連付けを作成した後、バケットポリシーを更新します。 ステップ 3: データリポジトリの関連付けの作成 次にデータリポジトリの関連付け (DRA) を作成して、Amazon FSx for Lustre ファイルシステムを Amazon S3 バケットにリンクします。 1. ACCOUNT-A で、Amazon FSx コンソールに移動し、作成したファイルシステムを選択します。 データリポジトリ のタブを選択して、 データリポジトリの関連付けを作成 を選択します。 2. ファイルシステムのパス と Amazon S3 バケットへのパスを入力します。今回の例ではバケット全体を使用しましたが、DRA を特定のプレフィックスに限定することもできます。 3. 作成 をクリックします。ステータスが 利用可能 になるまでに初期化に数分かかります。 4. DRA 作成時に、Amazon S3 アクセスのための Amazon FSx のサービスリンクロールが作成されました。 AWS Identity and Access Management (AWS IAM) コンソールに移動し、新しいファイルシステムのために作成されたサービスロールを検索してください。 5. Amazon FSx for Lustre のサービスリンクロールの Amazon Resource Name (ARN) を見つけて、手元に保存しておきます。次のセクションのバケットポリシーの設定で必要になります。 ステップ 4: S3 バケットポリシーの設定 先程のセクションの ARN を使用して、Amazon S3 バケットにバケットポリシーを適用します。 1. ACCOUNT-B で、Amazon S3 コンソールに移動し、作成したバケットを選択します。 アクセス許可 タブをクリックし、 バケットポリシー セクションで 編集 を選択します。現在のポリシーを下記のポリシーに置き換えます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "Example permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT-A:role/aws-service-role/…/AWSServiceRoleForFSxS3Access_fs-XXXXXXX" }, "Action": [ "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:PutObject", "s3:Get*", "s3:List*", "s3:PutBucketNotification" ], "Resource": [ "arn:aws:s3:::new-lustre-file-system", "arn:aws:s3:::new-lustre-file-system/*" ] } ] } 2. ステップ 3 で保存したサービスリンクロールの ARN を使用して、AWS プリンシパルの値を置き換えます。 3. 「new-lustre-file-system」を作成したバケット名に置き換えます。 変更の保存 を選択します。 Amazon FSx が S3 バケットにデータを書き込む際に暗号化する場合、S3 バケットのデフォルト暗号化を SSE-S3 または SSE-KMS に設定する必要があります。詳細は、 サーバー側で暗号化された Simple Storage Service (Amazon S3) バケットの使用 のドキュメントを参照してください。 ソリューションのテスト ここまでの作業で、別の AWS アカウントの Amazon S3 バケットと同期している Amazon FSx for Lustre ファイルシステムを作成しました。 ステップ 1. Amazon EC2 インスタンスの作成 同期のテストのために、ファイルシステムをマウントできる Amazon EC2 インスタンスが必要です。 ACCOUNT-A で、Amazon EC2 コンソールに移動します。Amazon FSx ファイルシステムと同じ VPC 内に Amazon Linux 2 AMI を使用してインスタンスを起動します。 インスタンスの起動方法については、 インスタンスの起動 のドキュメントを参照してください。 ステップ 2. ファイルシステムのマウント ドキュメントに記載されているいずれかの方法を使用して Linux インスタンスへの接続 を実施します。 ターミナルウィンドウから、Amazon FSx ファイルシステムをマウントします。Amazon FSx コンソールからファイルシステムのマウント方法を確認できます。ファイルシステムを選択し、 アタッチ を選択します。 ステップ 3. テストファイルの作成 ファイルシステムのマウントに成功したら、マウントされたディレクトリ /fsx/ns1/ にテストファイルを作成します。このファイルの名前は「 file1.txt 」とします。 ACCOUNT-B に切り替えて、作成した Amazon S3 バケットを確認してください。「 file1.txt 」を確認できます。 次に、別のファイルを直接 Amazon S3 バケットにアップロードしましょう。このファイルの名前を「 file2.txt 」とします。 EC2 ターミナルに戻り、 ls -l と入力してください。/fsx/ns1/ に「 file2.txt 」が表示されることが確認できます。 削除と更新でテストプロセスを繰り返すことができます。 クリーンアップ テストしたソリューションですが、不要な料金が発生しないようにするために、プロビジョニングしたリソースを削除する次の 4 つのステップを実行してください。 ファイルシステムのマウントとテストに使用した Amazon EC2 インスタンスを終了してください。 ACCOUNT-A で作成した Amazon FSx for Lustre ファイルシステムを削除してください。 ACCOUNT-B で作成したサンプルデータと Amazon S3 バケットを削除してください。 Amazon FSx for Lustre ファイルシステムへ Amazon S3 アクセスを提供するために作成した IAM サービスリンクロールを削除してください。 結論 Amazon FSx for Lustre の S3 とのネイティブ統合は、スケールアウト型 Lustre ファイルシステムの高パフォーマンスと Amazon S3 上に構築されたデータレイクのメリットを活用できる、実績のある簡単にデプロイできるソリューションを提供します。本記事では、異なる AWS アカウントの Amazon S3 バケット内のソースデータへの変更と同期を取る Amazon FSx ファイルシステムをデプロイする方法を紹介しました。このソリューションにより、企業は中央のエンタープライズデータレイクから ML や HPC のユースケースでそのデータを利活用する専門チームのアカウントにデータを共有することで、AWS 環境をスケールできます。 Justin Leto Justin Leto は、機械学習を専門とするアマゾンウェブサービスのシニアソリューションアーキテクトです。彼の情熱は、お客様が機械学習とAIの力を活用してビジネスの成長を促進できるよう支援することです。Justin はグローバルカンファレンスで発表したり、大学で講義を持っています。彼はニューヨーク市の機械学習とAIのミートアップをリードしています。休日には、オフショアセーリングやジャズ演奏を楽しんでいます。彼は妻と娘と一緒にニューヨーク市に住んでいます。 Emad Tawfik Emad Tawfik は、アマゾンウェブサービスの10 年以上の経験をもつ経験豊富なシニアソリューションアーキテクトです。彼の専門はストレージとクラウドソリューションの領域にあり、お客様向けの費用対効果が高くスケーラブルなアーキテクチャの構築が得意です。Emadは、仕事だけではなく、家族と時間を過ごすこととアウトドアを楽しんでいます。 Juha Sarimaa Juha Sarimaa は AWS のシニアソリューションアーキテクトストレージスペシャリストです。エンタープライズ規模のストレージシステムで28年の経験があります。お客様がビジネス課題を解決するためのペタバイト規模のストレージアーキテクチャを設計および構築できるよう支援することを楽しんでいます。Juha はフィンランド出身で、オーストラリアに住み、現在はコネチカット州に住んでいます。業務外では、Juha は外で家族や友人と森の中や水辺で時間を過ごしています。

大規模言語モデル (LLM) を中心に構成された生成 AI (人工知能) アプリケーションは、ビジネスに経済的価値を生み出し、さらに加速する可能性を示してきました。アプリケーションの例には、 会話型検索 、 カスタマーサポートエージェントアシスト 、 カスタマーサポート分析 、 セルフサービス仮想アシスタント 、 チャットボット 、 リッチメディア生成 、 コンテンツモデレーション 、 セキュアで高パフォーマンスなソフトウェア開発を加速するコーディングコンパニオン 、 マルチモーダルコンテンツソースからのより深いインサイト 、 組織のセキュリティ調査と緩和策の加速 などがあります。 多くのお客様が、生成 AI アプリケーションを開発する際に、セキュリティ、プライバシー、コンプライアンスの管理手法についてのガイダンスを求めています。 設計およびアーキテクティングのフェーズで LLM の脆弱性、脅威、リスクを理解し対処することで、チームは経済性および生産性のメリットを最大化することに集中できます。 リスクを認識することは、生成 AI アプリケーションの透明性と信頼性を高め、可観測性を向上させ、コンプライアンス要件を満たすのに役立ち、十分な情報に基づくリーダーの意思決定を促進します。 この記事の目的は、AI と機械学習 (ML) のエンジニア、データサイエンティスト、ソリューションアーキテクト、セキュリティチーム、その他のステークホルダーが、共通のメンタルモデルとフレームワークを持ち、セキュリティのベストプラクティスを適用できるようにすることです。これにより、AI/ML チームは、セキュリティを犠牲にすることなく、スピードを上げることができます。 具体的には、これまでセキュリティの原則について触れたことのない AI/ML およびデータサイエンティストが、LLM を使用した生成 AI アプリケーションの開発に関連する中核となるセキュリティとプライバシーのベストプラクティスを理解するのに役立つことを目的としています。 また、 Open Worldwide Application Security Project (OWASP) Top 10 for LLM Applications によって特定された、AI への信頼を損なう可能性のある一般的なセキュリティ上の懸念についても説明します。そして、生成 AI でイノベーションを起こしながら、AWSを使用してセキュリティ態勢と信頼性を高める方法を示します。 この記事では、LLM を使用して生成 AI アプリケーションを開発する際に、リスク管理戦略を構築するための 3 つの手順を紹介します。 まず、LLM ソリューションの実装、デプロイ、使用から生じる脆弱性、脅威、リスクについて掘り下げ、セキュリティを念頭に置いたイノベーションの始め方についてのガイダンスを提供します。 次に、安全な基盤の上に構築することが、生成 AI にとって不可欠である理由について説明します。 最後に、これらを LLM ワークロードの例と結び付けて、信頼境界を越えた多層防御のセキュリティを構築するためのアプローチを説明します。 この記事により、AI/ML エンジニア、データサイエンティスト、セキュリティ指向の技術者は、生成 AI アプリケーションのための多層防御を設計する戦略を特定し、OWASP Top 10 for LLM のセキュリティ上の懸念への対応策を理解できます。そして、お客様のアプリケーションに関する、次のようなよくある質問に答えるための基礎的な知識を構築できるようになります。 LLM ベースの生成 AI をアプリケーションで使用する際の、一般的なセキュリティとプライバシーのリスクのうち、この記事に示すガイダンスにより最も影響があるものは何ですか ? AWS 上の生成 AI アプリケーションの開発ライフサイクルにセキュリティとプライバシー制御を実装するにはどのような方法がありますか ? LLM を使用した生成 AI アプリケーションのリスクを管理し信頼性を高めるために、組織が生成 AI アプリケーションを構築する方法において、どのような運用面および技術面でのベストプラクティスを組み込むことができますか ? 生成 AI の開発をしながらセキュリティレベルを高める LLM を使用した生成 AI でイノベーションを起こすためには、セキュリティを念頭に置き、組織のレジリエンスを高め、安全な基盤の上に構築し、多層防御のセキュリティアプローチと統合する必要があります。 セキュリティは、AWS と AWS のお客様の間で 共有される責任 です。 AWS 責任共有モデルのすべての原則が、生成 AI ソリューションに適用されます。LLM ソリューションを構築する際に、インフラストラクチャ、サービス、データ適用される AWS 責任共有モデルを新たに理解しましょう。 セキュリティを念頭において組織のレジリエンスを構築する セキュリティを念頭に置き、セキュリティとコンプライアンスの目標を満たす生成 AI アプリケーション開発のための組織のレジリエンスを構築します。 組織のレジリエンスは、 AWS Well-Architected フレームワークのレジリエンシーの定義 を取り入れ拡張したもので、組織が混乱から回復する能力が含まれています。 LLM を使用した生成 AI を開発するための全体的な準備状況と、潜在的な影響に対する組織のレジリエンスを評価する際は、セキュリティ態勢、ガバナンス、およびオペレーショナルエクセレンスの優位性を考慮してください。 組織が生成 AI や LLM などの新興テクノロジーの利用を進めるにつれ、資産や事業部門を意図しない結果から保護するための多層防御の基礎として、組織全体のレジリエンスを考慮する必要があります。 組織のレジリエンスは LLM アプリケーションにとって極めて重要です すべてのリスク管理プログラムではレジリエンスから恩恵を受けることができますが、組織のレジリエンスは生成 AI にとって非常に重要です。LLM アプリケーションの上位 10 のリスクのうち OWASP が特定した 5 つは、リスクを管理するためにアーキテクチャおよび運用上のコントロールを定義し、組織規模でそれらを適用することに依存しています。これら 5 つのリスクは、安全が確認されていない出力ハンドリング、サプライチェーンの脆弱性、機密情報の漏えい、過剰な代理行為、過度の信頼です。アイデアの発案から研究、アプリケーションの開発、デプロイ、使用に至る製品のライフサイクル全体で、AI、ML、生成 AI のセキュリティを中心的なビジネス要件であり最優先事項であるとチームに認識させることで、組織のレジリエンスを高めることから始めてください。意識の向上に加えて、チームはガバナンス、保証、コンプライアンス検証の実践の中で生成 AI を考慮するための行動を取る必要があります。 生成 AI を中心に組織のレジリエンスを構築する 組織は、組織内での AI/ML および生成 AI セキュリティのための能力と機能を構築する方法を採用し始めることができます。 まずは既存のセキュリティ、保証、コンプライアンス、開発プログラムを拡張して、生成 AI を考慮することから始める必要があります。 組織の AI、ML、および生成 AI のセキュリティにおける 5 つの主要な関心領域は以下の通りです。 AI/ML のセキュリティの状況を理解する セキュリティ戦略に多様な視点を取り入れる 研究開発活動のセキュリティ対策に積極的に取り組む インセンティブを組織の成果と整合させる AI/ML と生成 AI における現実的なセキュリティシナリオに備える 生成 AI のライフサイクル全体を通じて脅威モデルを開発する 生成 AI を構築する組織は、リスクの排除ではなく、リスク管理に重点を置き、生成 AI ワークロードの計画、開発、運用において 脅威モデリング と 事業継続計画 を含める必要があります。生成 AI の本番利用から逆算して、従来のセキュリティリスクと生成 AI 特有のリスクの両方を用いて、各アプリケーションの脅威モデルを開発することから始めてください。あるリスクはビジネスにとって許容できる可能性があり、脅威モデリングの実施により許容できるリスク範囲を特定するのに役立ちます。例えば、生成 AI アプリケーションに 99.999% の稼働時間を要求しない場合、 AWS Backup と Amazon S3 Glacier を使用したリカバリに関連する追加のリカバリ時間は、許容できるリスクとなる可能性があります。反対に、モデル内のデータが極めて機密性が高く、規制対象である場合、 AWS Key Management Service (AWS KMS) の カスタマーマネージドキー (CMK) のローテーションからの逸脱や、データ漏えいから保護するために AWS Network Firewall を使用したり入出力トラフィックに Transport Layer Security (TLS) を適用することは、許容できないリスクとなる可能性があります。 生成 AI アプリケーションを本番環境で使用する際の固有リスクと残存リスクを評価し、基盤およびアプリケーションレベルの適切なコントロールを特定します。OWASP Top 10 for LLM で挙げられている、プロンプトインジェクション、訓練データの汚染、モデルの DoS 、モデルの盗難などの本番環境でのセキュリティイベントやサービス中断のロールバックと復旧を計画し、アプリケーション要件を定義する際に使用するリスク軽減策を早期に定義します。リスクとコントロールについて学ぶことは、生成 AI アプリケーション構築のための最適な実装アプローチを定義するのに役立ち、ステークホルダーや意思決定者がリスクに関する情報に基づいたビジネス上の意思決定を行うための情報を提供します。AI および ML の全体的なワークフローに不慣れな場合は、まず 機械学習ワークロードのセキュリティを改善する 7 つの方法 を確認して、従来の AI/ML システムに必要なセキュリティコントロールの理解を深めてください。 他の ML アプリケーションを構築するのと同様に、生成 AI アプリケーションを構築するには、一連の研究開発ライフサイクルの段階を経る必要があります。 選択した生成 AI ソリューションに応じて考慮すべき主要なセキュリティ領域を理解するためのメンタルモデルを構築するのに役立つ AWS 生成 AI セキュリティスコーピングマトリックス を確認することをおすすめします。 LLM を使用した生成 AI アプリケーションは、通常、次の順序立ったステップに従って開発および運用されます。 アプリケーションの要件 – ユースケースのビジネス目的、要件、成功基準を特定する モデルの選択 – ユースケースの要件と整合する基盤モデルを選択する モデルの適応とファインチューニング – データの準備、プロンプトの作成、モデルのファインチューニングを行う モデルの評価 – ユースケース固有のメトリクスで基盤モデルを評価し、最もパフォーマンスの高いモデルを選択する デプロイとインテグレーション – 選択した基盤モデルを最適化されたインフラストラクチャにデプロイし、生成 AI アプリケーションと統合する アプリケーションのモニタリング – アプリケーションとモデルのパフォーマンスをモニタリングして、根本原因の分析を可能にする ソフトウェア開発ライフサイクルの初日から、設計およびアーキテクチャフェーズの一部として、セキュリティが極めて重要であるとチームが理解していることを確認してください。これは、ソフトウェアの構成要素や開発サイクルの各レイヤーでセキュリティについて議論し、セキュリティとプライバシーをビジネス目標を達成するための手段として位置付けることを意味します。LLM アプリケーションのリリース前に脅威に対するコントロールを設計し、モデルの適応とファインチューニングに使用するデータと情報が、研究・開発・トレーニング環境でのコントロールの実装を必要とするかどうかを検討してください。品質保証テストの一環として、定期的に防御とセキュリティ態勢をテストするために、統合されたセキュリティ脅威 (訓練データを汚染したり、悪意のあるプロンプトエンジニアリングを通じた機密データを抽出することを試行するなど) を導入してください。 加えて、ステークホルダーは、本番の AI、ML、生成 AI ワークロードについて一貫したレビューの頻度を設定し、人間と機械の制御およびエラーのトレードオフを理解することを組織の優先事項として設定する必要があります。 デプロイされた LLM アプリケーションにおいて、これらのトレードオフが尊重されていることを検証および保証することで、リスク軽減が成功する可能性が高まります。 セキュアなクラウド基盤上で生成 AI アプリケーションを構築する AWS において、セキュリティは最優先事項です。 AWS は、アプリケーションとワークロードを構築、移行、管理するための、最もセキュアなグローバルクラウドインフラストラクチャとして設計されています。 これは、300 を超えるクラウドセキュリティツールの豊富なセットと、政府機関、ヘルスケア、金融サービスなどのセキュリティ要件の高い組織を含む、数百万のお客様からの信頼に支えられています。 AWS 上で LLM を使用して生成 AI アプリケーションを構築する場合、 セキュアで信頼性が高く、柔軟な AWS クラウドコンピューティング環境 からセキュリティ上のメリットを得ることができます。 セキュリティ、プライバシー、コンプライアンスのためにAWS グローバルインフラストラクチャを活用する AWS でデータ集約型アプリケーションを開発する際、AWS のグローバルリージョンインフラストラクチャを活用できます。このインフラストラクチャは、セキュリティとコンプライアンスに関する中核となる要件を満たす機能を提供するよう設計されています。これは、クラウドで利用できる最も高度な統制管理と機能のセットを提供するという、 AWS のデジタル統制に関するお客様との約束 によって強化されています。AWS は、パフォーマンス、イノベーション、セキュリティ、スケールを犠牲にすることなく、お客様の デジタル主権 に関するニーズを満たすための機能を拡張することにコミットしています。セキュリティとプライバシーのベストプラクティスを簡単に実装するために、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) や AWS プライバシーリファレンスアーキテクチャ (AWS PRA) などのリファレンスデザインやインフラストラクチャコードリソースをご利用ください。 プライバシーソリューションの設計 、 設計による主権 、 AWS でのコンプライアンス の詳細をご確認ください。また、 AWS Config 、 AWS Artifact 、 AWS Audit Manager などのサービスを利用して、プライバシー、コンプライアンス、監査、可観測性のニーズをサポートします。 AWS Well-Architected フレームワークとクラウド導入フレームワークを使用したセキュリティ態勢を理解する AWS は、 AWS Well-Architected フレームワーク を使用してクラウド環境を設計したり、 AWS Cloud Adoption Framework (AWS CAF) を使用してクラウドテクノロジーからビジネス価値を実現したりと、お客様をサポートする長年の経験から得られたベストプラクティスのガイダンスを提供しています。 AI、ML、生成 AI ワークロードのセキュリティ態勢を理解するために、Well-Architected フレームワークのレビューを実施してください。 レビューは、 AWS Well-Architected Tool などのツールを使用して実施できます。または、 AWS エンタープライズサポート を通じて AWS チームの支援を受けることもできます。 AWS Well-Architected Tool は、 AWS Trusted Advisor からのインサイトを自動的に統合して、ベストプラクティスがどの程度実装されているか、機能とコスト最適化を改善するためにどのような機会があるか評価します。 また、AWS Well-Architected Tool には、 Machine Learning Lens などの特定のベストプラクティスを備えたカスタマイズされたレンズも用意されているため、アーキテクチャを定期的にベストプラクティスと比較して改善点を特定できます。 AWS のお客様が 人工知能、機械学習、生成 AI の AWS クラウド導入フレームワーク により組織的な能力を開発するための戦略をどのように採用しているかを理解してすることで、価値の実現とクラウドの成熟への道のりを歩むチェックポイントを設定します。 また、 AWS クラウドレディネスアセスメント に参加することで、全体的なクラウド準備状況を理解するメリットもあるかもしれません。 AWS では追加のエンゲージメントの機会も提供しています – Generative AI Innovation Center の利用を開始する方法についての詳細は、AWS アカウントチームにお問い合わせください。 セキュリティと AI/ML の学習をベストプラクティスのガイダンス、トレーニング、認定で加速させる AWS は、トレーニング、開発、テスト、運用環境を保護する方法を特定するのに役立つ、 セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス や AWS セキュリティドキュメント からの推奨事項をまとめています。 初めての方は、セキュリティトレーニングと認定資格についてさらに詳しく学習し、 AWS セキュリティの基礎 と AWS セキュリティラーニングプラン から始めることをおすすめします。 また、 AWS セキュリティ成熟度モデル を利用して、Quick Wins から基礎、効率化、最適化の各段階で、AWS 上の最適なアクティビティを見つけて優先順位付けすることもできます。 AWS 上のセキュリティの基本的な理解ができたら、 脅威モデリングのアプローチ方法 を確認し、チームと Threat Modeling For Builders ワークショップ トレーニングプログラムから始める脅威モデリング演習を主導することを強くおすすめします。 その他にも、利用可能な AWS セキュリティトレーニングと認定資格 が多数あります。 LLM アプリケーションを保護するための多層防御アプローチを適用する 生成 AI ワークロード、データ、情報に対して多層防御のセキュリティアプローチを適用することで、ビジネス目標の達成に最適な条件を整えるのに役立ちます。多層防御のセキュリティベストプラクティスは、あらゆるワークロードが直面する一般的なリスクの多くを軽減し、あなたのチームが生成 AI イノベーションを加速するのに役立ちます。 多層防御のセキュリティ戦略は、AWS アカウント、ワークロード、データ、資産を保護するために、複数の冗長な防御を使用します。 これにより、セキュリティコントロールの 1 つが侵害されたり失敗した場合でも、脅威を分離し、セキュリティイベントから防御、検知、対応、回復するのに役立つ追加のレイヤーが存在することを確認するのに役立ちます。 AWS サービスとソリューションを含む複数の戦略を組み合わせて、各レイヤーで使用することで、生成 AI ワークロードのセキュリティとレジリエンスを向上させることができます。 多くの AWS のお客様は、 NIST のサイバーセキュリティフレームワーク などの業界標準のフレームワークに準拠しています。このフレームワークは、識別、防御、検知、対応、復旧、最近追加されたガバナンスの柱にわたってセキュリティ防御を確実に保護するのに役立ちます。このフレームワークは、AWS のセキュリティサービスや統合されたサードパーティのサービスに簡単にマッピングできるため、組織が遭遇するあらゆるセキュリティイベントに対して、適切な対応範囲とポリシーを検証するのに役立ちます。 （訳者注：CloudEndure Disaster Recovery は一部リージョンを除いて廃止が予定されているため、代わりに AWS Elastic Disaster Recovery の利用をご検討ください） 多層防御 : 環境をセキュアにし、強化された AI/ML 固有のセキュリティとプライバシーの機能を追加する 多層防御の戦略は、最初にアカウントと組織を保護することから始め、その後 Amazon Bedrock や Amazon SageMaker などのサービスに組み込まれたセキュリティとプライバシーの機能を、階層的に追加していく必要があります。 Amazonは 30 を超えるセキュリティ、アイデンティティ、コンプライアンスのポートフォリオを持ち 、それらは AWS の AI/ML サービスと統合されており、ワークロード、アカウント、組織を保護するのに役立ちます。OWASP Top 10 for LLM の観点で適切に防御するには、これらのセキュリティサービスを AWS の AI/ML サービスと合わせて使用していく必要があります。 まず、最小権限のポリシーを実装し、 IAM Access Analyzer などのサービスを使用して、アクセス許可が広範囲に設定されたアカウント、ロール、リソースを見つけ、 一時的な認証情報を使用してアクセスを制限 します。次に、 AWS KMS を使用して、CMK の利用も考慮しつつ、保管中のすべてのデータが暗号化されていることを確認します。また、 Amazon S3 のバージョニングとオブジェクトレベルの不変性を適用するための Amazon S3 オブジェクトロック を使用して、すべてのデータとモデルをバージョン管理しバックアップします。サービス間を転送するすべてのデータは、 AWS Certificate Manager や AWS Private CA を使用して保護し、 AWS PrivateLink を使用して VPC 内にとどめておきます。 改ざんやデータ漏洩からの保護のために、 AWS Network Firewall ポリシーを使用した VPC を利用して、データの厳格な入出力ルールを定義します。 悪意のあるボット 、 SQL インジェクション攻撃、クロスサイトスクリプティング (XSS) から Web アプリケーションと API を保護 するために、 AWS WAF を前面に配置し、アカウントの乗っ取り防止のため Fraud Control を使用することも検討します。ログの記録に AWS CloudTrail 、 Amazon VPC フローログ、 Amazon EKS 監査ログを使用することにより、フォレンジックの際に Amazon Detective などのサービスで各トランザクションをレビューすることができます。 Amazon Inspector を使用して、 Amazon EC2 インスタンス、コンテナ、 AWS Lambda 関数の脆弱性の自動で発見し管理することができたり、 ワークロードのネットワーク到達可能性を特定 することもできます。データとモデルを疑わしいアクティビティから保護するために、 Amazon GuardDuty の ML を利用した脅威モデルと脅威インテリジェンスフィードを使用します。さらに EKS Protection、ECS Protection、S3 Protection、RDS Protection、Malware Protection、Lambda Protection など、追加の機能を有効にします。 AWS Security Hub のようなサービスを使用することで、セキュリティチェックを集中化および自動化し、セキュリティのベストプラクティスからの逸脱の検出や、調査の迅速化、プレイブックを使用した修復の自動化が可能となります。 さらに、 ゼロトラスト アーキテクチャを AWS 上で実装し、人間のユーザーまたはマシン間プロセスがリクエストごとにアクセスできるものに対し、きめ細かい認証認可の制御を強化することもできます。 また、 Amazon Security Lake を使用して、AWS 環境、SaaS プロバイダー、オンプレミス、クラウドソースからのセキュリティデータを自動的に集約し、アカウント内に構築された専用のデータレイクに保存することも検討します。Security Lake を使用することで、組織全体のセキュリティデータをより包括的に理解できます。 生成 AI ワークロード環境をセキュリティで保護した後は、 Amazon SageMaker Data Wrangler を使用してデータ準備における潜在的なバイアスを特定したり、 Amazon SageMaker Clarify を使用して ML データとモデルのバイアスを検出するなど、AI/ML 固有の機能を追加できます。 また、 Amazon SageMaker Model Monitor を使用して、本番環境の SageMaker ML モデルの品質を評価し、データ品質、モデル品質、Feature Attribution のドリフトが発生した場合に通知を受けることもできます。 これら AWS の AI/ML サービス (Amazon Bedrock と連携する Amazon SageMaker を含む) と AWS のセキュリティサービス が連携することで、バイアスの潜在的なソースを特定し、悪意のあるデータ改ざんから保護するのに役立ちます。 AWS サービスの価値を最大限に活用して、データとワークロードを保護するための多層防御を実装するために、OWASP Top 10 for LLM の各脆弱性についてこのプロセスを繰り返してください。 AWS Enterprise Strategist の Clarke Rodgers 氏がブログ記事「 CISO Insight: Every AWS Service Is A Security Service 」で次のように述べています。「AWS クラウド内のほぼすべてのサービスはセキュリティが単体で確保されており、お客様がセキュリティ、リスク、コンプライアンスの目的を達成するために、単体または 1 つ以上のサービスと組み合わせて使用できます」。 加えて、「お客様の最高情報セキュリティ責任者 (CISO)、またはそれらの関連チームは、すべての AWS サービスに精通しているかどうか確認する時間を取ることが望ましいです。なぜなら、サービスが『セキュリティ、アイデンティティ、コンプライアンス』のカテゴリに含まれていなくても、セキュリティ、リスク、コンプライアンスの目的を満たすことができるためです。」と述べています。 LLM アプリケーションの信頼境界における各レイヤーの防御 生成 AI ベースのシステムやアプリケーションを開発する際には、 MITRE ATLAS Machine Learning Threat Matrix で述べられているように、ソフトウェアおよびデータコンポーネントの出所 (オープンソースソフトウェア監査の実行、ソフトウェア部品表 (SBOM) のレビュー、データワークフローと API インテグレーションの分析など) に注意を払うことや、LLM サプライチェーンの脅威に対する必要な保護を実装することなど、他の ML アプリケーションと同様の懸念事項を考慮する必要があります。 業界のフレームワークからの洞察を取り入れ、脅威インテリジェンスやリスク情報といった複数のソースを使用し、従来のフレームワークには含まれていない AI、ML、および生成 AI の新たなセキュリティリスクに対応できるよう、セキュリティ対策を調整および拡張する方法を認識してください。この分野では定期的に新しい脅威が出現し、かつ進化しているため、フレームワークやガイドも頻繁に更新されています。 そのため、AI 固有のリスクに関する情報を、業界、国防、政府、国際機関、学術機関などのソースから探してください。たとえば、検索拡張生成 (RAG) モデルを使用する場合、モデルに必要なデータが含まれていないと、推論とファインチューニングの際に外部データソースへ要求する可能性があります。このようなクエリを実行するソースは管理外にある可能性があり、サプライチェーンでの潜在的な侵害源となり得ます。外部ソースに対しても多層防御アプローチを拡張し、アクセスしているデータの信頼性、認証、認可、アクセス、セキュリティ、プライバシー、正確性を確立する必要があります。 より深く掘り下げるには、「 Build a secure enterprise application with Generative AI and RAG using Amazon SageMaker JumpStart 」を確認してください。 LLM アプリケーションにおけるリスクを分析し軽減する このセクションでは、信頼境界とインタラクション、または同様の適切なコントロールの範囲とリスクプロファイルを持つワークロードの個別の領域に基づいて、いくつかのリスク軽減手法を分析して説明します。 以下のチャットボットアプリケーションのサンプルアーキテクチャでは、AWS のお客様が一般的な LLM アプリケーションを構築する方法に基づいて、コントロールが実証される 5 つの管理されている信頼境界があります。 実際の LLM アプリケーションには、より少ない、またはより多くの定義可能な信頼境界がありえます。 次のサンプルアーキテクチャでは、これらの信頼境界は次のように定義されています: ユーザーインターフェースのインタラクション (リクエストとレスポンス) アプリケーションのインタラクション モデルのインタラクション データのインタラクション 組織のインタラクションと利用 ユーザーインターフェースのインタラクション : リクエストとレスポンスのモニタリングの開発 生成 AI アプリケーションの入力と出力に関するリスク戦略を評価することにより、生成 AI に関連するサイバーインシデントをタイムリーに検知および対応します。 例えば、LLM アプリケーションの場合、ドメインまたは組織の外部への機密情報の漏洩を検知するために、挙動とデータ流出のための追加のモニタリングが必要となる場合があります。 生成 AI アプリケーションは、データを保護する際にも標準的なセキュリティのベストプラクティスを維持する必要があります。 セキュアなデータ境界 を確立し、 センシティブなデータストアを保護 します。 LLM アプリケーションで使用されるデータと情報は、保管時および転送時に暗号化します。 モデルの訓練データは、どのユーザー、プロセス、ロールがデータストアにアクセスできるかを理解し制御することにより、訓練データの汚染（Training Data Poisoning）から保護します。 また、アプリケーション内のデータフロー、バイアスの監視、Amazon S3などのストレージサービスでのバージョニングとイミュータブルストレージを使用することも重要です。 AWS Network Firewall や AWS VPC などのサービスを使用して、厳格なデータの入出力制御を確立し、疑わしい入力やデータ漏洩の可能性から保護します。 学習、再学習、ファインチューニングのプロセス中は、利用される個人情報に注意を払う必要があります。 これらのプロセスのいずれかでデータが利用された後、プロンプトインジェクション技術を用いて、ユーザーがデータや情報をモデルから抽出できるシナリオを想定する必要があります。 モデルと推論に個人情報を利用することのリスクと効果を理解します。 細かいアクセス許可を設定し管理するために、LLM アプリケーションロジックに依存しないロバストな認証認可メカニズムを実装します。 生成 AI アプリケーションへのユーザーが管理する入力は、一部の条件下において、モデルやユーザー管理外の入力から情報を抽出するベクトルを提供できることが実証されています。 これはプロンプトインジェクションを通じて発生する可能性があります。 LLM アプリケーションが想定するガードレールから逸脱した出力をするような入力がなされ、その出力の中には、モデル学習に使われたオリジナルのデータセットに関する情報も含まれることになります。 モデルへの入力やモデルからの出力を受け取るユーザーに対して、ユーザーレベルのアクセス制御を実装します。 トレーニングデータや情報の機密性が高い場合や、攻撃者によって入力とモデル出力に基づいてモデルを模倣されるリスクがある場合は、匿名アクセスを許可しないアプローチを検討する必要があります。 一般に、モデルへの入力の一部が任意のユーザー提供のテキストで構成されている場合、出力がプロンプトインジェクションに対して脆弱であると見なされます。そのため、安全が確認されていない出力ハンドリング（Insecure Output Handling）、過剰な代理行為（Excessive Agency）、過度の信頼（Overreliance）といったリスクに対して技術的および組織的な対策が実行されているか確認する必要があります。前述の AWS WAF を使用した悪意のある入力のフィルタリングの例では、プロンプトの誤用の可能性に対してアプリケーションの前にフィルターを構築し、モデルとデータが成長するにつれてそれらをどのように処理および進化させるかのポリシーを開発することを検討します。 また、品質、精度、コンテンツモデレーションの基準を満たしていることを確認するために、ユーザーに返される前に出力をフィルタリングするレビューを行うことも検討してください。 組織のニーズに合わせて、モデルの前に入力と出力の追加の制御レイヤーを追加することで、疑わしいトラフィックパターンを軽減できます。 アプリケーションのインタラクション : アプリケーションのセキュリティと可観測性 LLM アプリケーションをレビューする際は、ユーザーがモデルを利用して、本来はアクセスや使用の許可がない下流のツールやツールチェーンへの標準認可を回避しないか注意してください。このレイヤーでのもう 1 つの懸念は、緩和されていない技術的または組織的な LLM リスクを使用した攻撃メカニズムとしてモデルを利用して、外部データストアにアクセスすることです。 例えば、機密データを含む可能性のある特定のデータストアにアクセスするようモデルがトレーニングされている場合は、モデルとデータストアの間で適切に認可の確認がなされることを確認する必要があります。 認可チェックを実行する際には、モデルからではなく、ユーザーに関する不変の属性を使用します。 安全が確認されていない出力ハンドリング（Insecure Output Handling）、安全が確認されていないプラグイン設計（Insecure Plugin Design）、過剰な代理行為（Excessive Agency）などの対策が講じられていない場合は、攻撃者が認可システムを騙すためにモデルを使用し、実行権限をエスカレーションさせる状況を作り出す可能性があります。これにより下流コンポーネントが、ユーザーがデータの取得や特定のアクションの実行を認可されていると信じてしまうことにつながります。 生成 AI プラグインやツールを実装する際には、付与されるアクセスレベルを検証し、理解することが不可欠です。また、設定されたアクセス制御を精査することも重要です。対策の講じられておらず安全でない生成 AI プラグインを使用すると、サプライチェーンの脆弱性や脅威にシステムがさらされる可能性があり、リモートコードの実行などの悪意のあるアクションにつながる可能性があります。 モデルのインタラクション : モデル攻撃の防止 使用するモデル、プラグイン、ツール、データの出所を認識しておく必要があります。これにより、サプライチェーンの脆弱性を評価および軽減することができます。例えば、一部の一般的なモデルフォーマットでは、モデル自体に任意の実行可能コードを埋め込むことが許可されています。組織のセキュリティ目標に関連する場合は、パッケージをミラーしたり、スキャンや追加の検査を実行します。 モデルのトレーニングとファインチューニングを行うために使用するデータセットもレビューする必要があります。 ユーザーからのフィードバック (またはその他のエンドユーザーがコントロールできる情報) に基づいてモデルの自動ファインチューニングを行う場合は、悪意のある攻撃者がレスポンスを操作することでモデルを任意に変更し、訓練データの汚染（Training Data Poisoning）を引き起こす可能性があるかどうかを考慮する必要があります。 データのインタラクション : データ品質と利用状況のモニタリング 大規模言語モデル (LLM) のような生成 AI モデルは、一般的に大量のデータで訓練されているため、優れた性能を発揮します。このデータは LLM が複雑なタスクを遂行するのに役立ちますが、同時に訓練データの汚染 (Training Data Poisoning) のリスクにシステムをさらす可能性もあります。これは、不適切なデータが訓練データに含まれたり省かれたりすることで、モデルの振る舞いが変わることを指します。このリスクを軽減するには、モデルで使用する前に、システムのデータレビュープロセスとサプライチェーンを確認する必要があります。トレーニングパイプラインはデータ汚染攻撃の主な発生源ですが、他にも RAG モデルやデータレイクなど、モデルがデータを取得する方法も確認する必要があります。そのデータソースが信頼でき保護されているかどうかを確認します。 AWS Security Hub、Amazon GuardDuty、Amazon Inspector などの AWS セキュリティサービスを使用して、Amazon EC2、Amazon EKS、Amazon S3、 Amazon Relational Database Service (Amazon RDS)、ネットワークアクセスなどでの疑わしいアクティビティを継続的に監視し、新たな脅威の兆候を検知します。また Detective を使用してセキュリティ調査を視覚化することもできます。さらに、 Amazon Security Lake などのサービスを使用して、AI/ML ワークロードに貢献する AWS 環境、SaaS プロバイダー、オンプレミス、およびクラウドソースから、セキュリティデータを自動的に集約する専用データレイクを作成することで、セキュリティ調査を加速することも検討します。 組織のインタラクション : 生成 AI のためのエンタープライズガバナンスガードレールの実装 ビジネスにおける生成 AI の利用に関連するリスクを特定します。生成 AI ソリューションを展開する際には、組織のリスクを分類し、リスク評価を実施し、情報に基づく意思決定が必要です。AI/ML、生成 AI ワークロードを含めた 事業継続計画(BCP) を策定し、影響を受けたりオフラインになった LLM アプリケーションの機能を迅速に置き換えて、SLA を満たすことができるようにします。 プロセスとリソースのギャップ、非効率性、不整合性を特定し、ビジネス全体の認知とオーナーシップを向上させます。 すべての生成 AI ワークロードを 脅威モデリング し、データの不正アクセス、サービスの拒否、リソースの誤用など、ビジネスに影響を与える可能性のあるセキュリティ上の脅威を特定し軽減します。 脅威モデリングを実施する際には、新しい AWS Threat Composer モデリングツール が価値創出までの時間短縮に役立ちます。 開発サイクルの後半では、 セキュリティカオスエンジニアリング のフォールトインジェクションの試みを導入して、システムが未知の問題にどのように反応するかを理解し、システムの回復力とセキュリティに対する信頼性を高めるための実環境での条件を作成することを検討します。 すべての職種と機能にわたって AI/ML や生成 AI に関するセキュリティの遵守とカバレッジを確保するため、セキュリティ戦略とリスク管理メカニズムの開発に多様な視点を取り入れます。 生成 AI アプリケーションの初期やリサーチの段階から要件と整合させるためにセキュリティの考え方を取り入れます。 AWSからの追加のサポートが必要な場合は、AWS のアカウントマネージャーに相談し、AWS セキュリティと AI/ML のソリューションアーキテクトのサポートをリクエストし、協力して取り組みます。 セキュリティ組織は、プロダクトマネージャー、ソフトウェア開発者、データサイエンティスト、経営陣などの生成 AI のステークホルダー間で、リスクの認識とリスク管理の理解を促進するコミュニケーションを定期的に行うようにします。これにより、脅威インテリジェンスとコントロールのガイダンスが、影響を受ける可能性のあるチームに届くようになります。セキュリティ組織は、ディスカッションに参加し、ビジネス目標に関連する新しいアイデアや情報を生成 AI のステークホルダーに提供することで、責任ある情報開示と反復的な改善の文化を支援できます。より詳細については、 責任ある AI に関する私たちの取り組み や、お客様を支援する 責任ある AI のリソース をご確認ください。 組織の既存のセキュリティプロセスにおける時間対効果に対する障害を取り除くことにより、生成 AI のためのよりよい組織態勢に向けた優位性が得られます。 組織が生成 AI のセキュリティの状況下で過度に負担を強いられるプロセスがあるかを積極的に評価し、これらを改善して、適切なコントロールをもとにローンチする計画を開発者やデータサイエンティストに提供します。 インセンティブの調整や、リスクの低減、目標とする結果への明確な見通しを提供する機会があるかどうかを評価します。 AI/ML と生成 AI アプリケーション開発の進化するニーズを満たすように、コントロールのガイダンスと防御を更新することで、開発時間のコスト増加、リスクの増加、影響範囲の増加を招くような混乱と不確実性を軽減します。 セキュリティの専門家ではないステークホルダーが、組織のガバナンス、ポリシー、リスク管理のステップが自分のワークロードにどのように適用されるかを理解できるようにするとともに、リスク管理メカニズムを適用できるようにしてください。 組織が生成 AI アプリケーションで発生しうる現実的なイベントとシナリオに対応できるよう準備し、生成 AI ビルダーの役割と対応チームが、疑わしい活動について懸念がある場合のエスカレーションパスとアクションを認識していることを確認します。 結論 先進技術を活用して市場でのイノベーションを成功させるには、セキュリティを最優先に考え、セキュアなインフラストラクチャーの基盤上に構築していくことが必要です。また、多層防御のセキュリティアプローチをもとに、テクノロジースタックの各レイヤーでセキュリティをさらに統合できる方法を考えることが必要です。これには、組織のレジリエンシーを確保するための、テクノロジースタックの複数のレイヤー間のインタラクションと、デジタルサプライチェーン内の統合ポイント間のインタラクションが含まれます。 生成 AI はいくつかの新しいセキュリティとプライバシーの課題をもたらしますが、レイヤー化されたセキュリティサービスを使用した多層防御などの基本的なセキュリティのベストプラクティスに従えば、多くの共通的な問題や進化する脅威から組織を保護するのに役立ちます。 生成 AI ワークロード全体と組織全体にわたって、レイヤー化されたAWSセキュリティサービスを実装し、デジタルサプライチェーンの統合ポイントに焦点を当てて、クラウド環境を保護する必要があります。そして、Amazon SageMaker や Amazon Bedrock などの AWS AI/ML サービスで強化されたセキュリティとプライバシー機能を利用して、生成 AI アプリケーションにさらなるセキュリティとプライバシーコントロールのレイヤーを追加できます。 セキュリティを最初から組み込むことで、コンプライアンスを簡素化しながら、生成 AI でのイノベーションをより迅速かつ容易、そしてコスト効率よく実現できます。 これにより、従業員、顧客、パートナー、規制機関、その他の利害関係者のために、生成 AI アプリケーションのコントロール、信頼性、可観測性を高めることができます。 追加の参考資料 AI/ML 固有のリスク管理とセキュリティの業界標準フレームワーク: NIST AI Risk Management Framework (AI RMF) OWASP Top 10 for Large Language Model LLM Applications MITRE ATLAS Machine Learning Threat Matrix OWASP AI Security & Privacy Guide 著者について Christopher Rae は、AWS のセキュリティサービスの採用を加速および拡大する戦略的イニシアチブを開発および実行することに焦点を当てたプリンシパルワールドワイドセキュリティ GTM スペシャリストです。サイバーセキュリティと新興テクノロジーの交差点に情熱を注ぎ、20 年以上にわたってメディア、エンターテインメント、テレコムのお客様にセキュリティソリューションを提供するグローバルな戦略的リーダーシップの経験を持っています。読書、旅行、食べ物とワイン、新しい音楽の発見、初期段階のスタートアップへのアドバイスを通じてリフレッシュしています。 Elijah Winter は、サイバーセキュリティ工学の学士号を持ち、ハリー・ポッターへの愛に満ちたシニアセキュリティエンジニアです。 AI システムの脆弱性を特定し対処することに秀でており、技術的専門知識と魔法使いのような感覚を融合させています。 AI エコシステムのためのカスタマイズされたセキュリティプロトコルを設計し、デジタル防御に魔法のような魅力をもたらしています。 正直さを重んじる Elijah は、信頼を守ることに焦点を当てた公共および民間セクターの両方の組織でセキュリティのバックグラウンドを持っています。 Ram Vittal は、AWS のプリンシパル ML ソリューションアーキテクトです。 30 年以上にわたり、分散型、ハイブリッド、クラウドアプリケーションのアーキテクチャ設計と構築の経験があります。 セキュアでスケーラブルな AI/ML とビッグデータのソリューションを構築し、エンタープライズのお客様がクラウドへの移行と最適化の旅を支援し、ビジネス成果を向上させることに情熱を注いでいます。 余暇には、バイクに乗ったり、3 歳のシーパドゥードルと散歩したりしています! Navneet Tuteja  は、Amazon Web Services のデータスペシャリストです。AWS に加入する前は、データアーキテクチャの近代化と包括的な AI/ML ソリューションの実装を目指す組織のファシリテータとして働いていました。Thapar University で工学の学位を取得し、Texas A&M University で統計学の修士号を取得しています。 Emily Soward は、AWS プロフェッショナルサービスのデータサイエンティストです。スコットランドのエディンバラ大学で人工知能の理学修士号を取得しており、自然言語処理 (NLP) に重点を置いています。Emily は、公共および民間セクターの組織で実行されている AI ワークロードの運用効率とガバナンスに焦点を当てた、AI を活用した製品の研究開発に従事してきました。AWS シニアスピーカーとして顧客へのガイダンスに貢献するとともに、最近では機械学習レンズの AWS Well-Architected の著者としても活動しています。 翻訳はプロフェッショナルサービスの藤浦雄大、相川遼介が担当しました。原文は こちら です。 「AWS Security and Risk Management Forum ～レジリエントな未来：生成AIなどの最新技術を活用したセキュリティ・リスクマネージメント～」 のご案内 2024 年 3 月 19 日に東京にて表題のイベントが開催されます。本イベントでは、生成 AI の活用やクラウドの活用の最新動向および生成 AI の押さえるべきポイント、AWS 内の取り組みについて米国セキュリティ部門のディレクターが直接解説します。また、有識者や外部ゲストを迎え、クラウドにおけるセキュリティ、リスクマネジメントに焦点を当てた各種対策を具体的に解説します。ご希望の方は、 こちら からご登録をお願いいたします。

re:Invent は、革新的なテクノロジーを深く理解し、新しいアイデアを探求する機会です。現在様々な業界においてサステナビリティ（持続可能性）が大きな課題となっています。AWS クラウドによって実現するサステナビリティには、「クラウドの」、「クラウド内」、「クラウドを通じて」の 3 つの要素があります。 クラウドのサステナビリティ (Sustainability of the cloud) : クラウドへのマイグレーション（移行）による IT システムのサステナビリティを向上する クラウド内のサステナビリティ (Sustainability in the cloud) : Well-Architected Framework のサステナビリティの柱や様々なサービスを利用した AWS のワークロードの最適化 クラウドを通じたサステナビリティ (Sustainability through the cloud) : クラウドベースのソリューションとアドバイザリーサポートの導入により、サステナビリティ目標を加速させる このブログでは、re:Invent 2023 での発表内容を中心に、サステナビリティのそれぞれの要素について、AWS の取り組みや事例をご紹介していきます。 クラウドのサステナビリティ Sustainability innovation in AWS Global Infrastructure (SUS101) では、AWS グローバルインフラストラクチャのサステナビリティに関する紹介を行いました。 調査会社 451 Research によると、AWS のような大規模なクラウドインフラストラクチャはオンプレミスのエンタープライズデータセンターを利用するよりもエネルギー効率がよく、一般的な平均的なオンプレミスデータセンターと比較して、 米国 で 3.6 倍、 ヨーロッパ や アジア太平洋地域 では約 5 倍エネルギー効率が高いことがわかりました。平均して、AWS ではお客様の二酸化炭素排出量を現在約 80% 近く削減でき、今後 100% 再生可能エネルギーで事業を運営するようになった場合は、最大 96% 二酸化炭素排出量を削減できます。 クラウドインフラストラクチャーでは、最新のサーバーをより高い稼働率で使用し、複数のお客様間でリソースを共有して動的に割り当てるとともに、施設レベルでは、冷却と配電の両方でエネルギー効率を高める設計により、データセンターのエネルギー効率を向上させています。 AWS は、グローバルな事業とサプライチェーン全体で二酸化炭素排出量を削減することにより、二酸化炭素排出量のネットゼロに向けて取り組んでいます。主な取り組みとして以下のようなものがあります: AWS Graviton プロセッサや、AI/ML に特化した AWS Trainium や AWS Inferentia など、独自設計のハードウェアによるエネルギー効率化 データセンター建設において、製造時に発生する二酸化炭素量を削減した低炭素コンクリートや低炭素鋼を使用 データセンターのバックアップ発電機で再生可能燃料の利用 サプライヤーと協力し半導体デバイスのライフサイクル全体で排出量を削減 Amazon は世界最大の再生可能エネルギー購入企業であり、AWS でもすでに 19 の AWS リージョンで 100% 再生可能エネルギーを利用 ハードウェアのライフサイクルにおけるサーキュラーエコノミー（循環型経済）の採用 水利用効率の向上と社会への水の還元 クラウド内のサステナビリティ Sustainable architecture: Past, present, and future (SUS302) では、「サステナブルなアーキテクチャー：過去、現在、未来」という講演が行われ、クラウド内のサステナビリティを向上させるための考え方や具体的なサービスについての紹介が行われました。 クラウドの登場により自由に計算リソースを増減して変化するワークロードに対応することが可能になり、またコストやサステナビリティの観点でアプリケーションをチューニングしてリソースを最適化する考え方が生まれました。 AWS の責任共有モデル の考え方では、AWS はクラウドインフラストラクチャのサステナビリティ（持続可能性）に責任を持つ一方で、お客様は、 クラウド内のサステナビリティに責任を持ち、ワークロードとリソース利用率を最適化する必要があります。 図1）AWS 責任共有モデル クラウド内のサステナビリティを最適化するためのガイドとして、2021 年の AWS re:Invent で Well-Architected Framework に 6 本目の柱、持続可能性（サステナビリティ） が追加されました。この中では、リージョン選択、需要に合わせた調整、ソフトウェアアーキテクチャ、ストレージの最適化やデータのライフサイクル管理、ハードウェアとサービスの選択、プロセスと文化、といった重点領域を定義し、それぞれの領域におけるベストプラクティスを紹介しています。 クラウド内のサステナビリティを改善するには、まず現状を把握する必要があります。AWS の請求コンソールから確認できる AWS カスタマーカーボンフットプリントツールでは AWS ワークロードから発生する二酸化炭素排出量を表示することができます。さらにプロキシメトリクスと呼ばれる手法を使うことにより、AWS リソースの利用量をプロキシ、つまり代替的な指標とすることで、よりリアルタイムに近い形で、自分のワークロードの排出量を把握することができます。 またこの講演では、 Cloud Intelligent Dashboard というオープンソースのダッシュボードも紹介しています。これは AWS リソースの使用状況を詳細に分析することができるツールで、 デプロイメントガイド や デモ が公開されています。 組織内に AWS アカウントが複数あって AWS リソースを大量に利用している場合、その全体像の把握は難しいものですが、このようなダッシュボードにより、AWS リソースの利用状況について正確に把握することができます。 図2） Cloud Intelligence Dashboard またその他にも、AWS ワークロードのサステナビリティを高めるために利用可能な、様々なツールが紹介されています。 クラウドを通じたサステナビリティ AWS クラウドを通じてサステナビリティ目標を実現するというテーマに関しては、複数の講演がありました。 AI を利用した ESG レポーティングとデータ主導の意思決定 (SUS204) Using AI for ESG reporting and data-driven decision-making (SUS204) では、 AI を利用した ESG レポーティングとデータ主導の意思決定 に関する発表が行われました。 ESG レポーティングというのは、いわゆる非財務情報に関する開示であり、日本でも ESG 情報開示が求められることが多くなってきていますが、海外でも規制による ESG 情報開示の義務化が進んでおり、同時に不正確な報告による訴訟リスクが増加しています。また、サプライチェーンの安全性、レジリエンス、透明性などの評価が重要になっています。 一方で、ESG レポーティングに関して様々な課題があり、データが社内の様々なシステムでバラバラに管理されサイロ化していること、手作業の集計による非効率性や誤りのリスクが指摘されています。また、年 1 回程度の特定の時点でのみの集計では実行可能なアクションに結びつけた改善を行うのには不十分です。 このような問題に対して、AI/ML を活用することで課題の解決が可能になります。例えばデータの収集を自動化したり、データのギャップを埋めて補完したり、コンプライアンス関係文書に対するクエリや要約を実行したり、生成 AI による ESG レポートの自動作成を行う、といったことです。このセッションでは、 (1) 生成 AI を利用したチャット bot によるサステナビリティ関係の様々なクエリの実施、(2) AI/ML を利用した排出係数の選択、(3) Amazon Textract による電力請求書からのデータ抽出、など、AWS の AI/ML を使用したデモを紹介しています。 AI/ML でエンド・ツー・エンドのサプライチェーン透明性を加速 (SUS203) Accelerating end-to-end supply chain transparency with AI/ML (SUS203) では、AI/ML によってサプライチェーンの透明性を加速させる技術に関する紹介がありました。 現在、様々な理由で製品のサプライチェーン透明性の向上が求められています。例えば特に消費財や衣服については、製品の安全性や真正性を確認するために製品のトレーサビリティを求める消費者の声が強く、またコンプライアンスや規制上の理由でサプライチェーン透明性が求められる場合もあります。また、二酸化炭素排出量の算定においては、Scope 3 と呼ばれる間接排出量では、製品の原材料や製造、輸送、最終的な利用から破棄に渡るライフサイクルを通じた排出量が対象となるため、サプライチェーンの透明性を高めることが非常に重要になってきます。 一方で、様々な製品のサプライチェーンは複雑化しており、特に、L2、L3 と呼ばれる、間接的な取引相手にまたがるサプライチェーン情報を取得するのは困難です。これはサプライヤーが情報提供に懸念を示すといったケースがあるだけでなく、データが様々な箇所に分散され、データフォーマットが統一されていないといった技術的な要因もあります。 AWS は PVH Europe というヨーロッパの大手のアパレル企業と協力して、サステナビリティのプラットフォームを開発し、サプライチェーン情報を分析・可視化するためのデータメッシュとダッシュボードを開発しました。この事例では “ Prouct Traceability on AWS ” という AWS ソリューションガイダンスにより、企業の購買履歴や NGO の発行した証明書などの情報を統合し、AI/ML によって足りない情報を推定することにより、サプライチェーン情報を分析・可視化するためのデータメッシュとダッシュボードを開発しています。 図3）サプライチェーン情報を可視化したダッシュボード例 AI, ML, オープンソースデータにより森林破壊を減速 Slowing down deforestation by using AI, ML, and open source data (SUS205) では、AI、ML、オープンデータを利用した森林破壊を減速させる取り組みを紹介しています。 森林は大量の二酸化炭素を吸収し固定化し、生物多様性や人間の営みを守るなど、気候変動やサプライチェーン安定性に大きな影響を持っています。 一方で、森林破壊が大きな問題となっています。例えば、ブラジルのアマゾン地域では 90% の森林破壊は違法に行われており、違法な農地で生産された農産物が問題となっています。 サンパウロの Minas Gerais 大学は、ブラジルの Para 州の自治体と協力して、 SeloVerde 2.1 というソリューションを開発しました。これは、トレーサビリティを向上し、違法な土地利用に基づく農産物を市場から排除することによって、森林破壊を減速させることを目的としています。 SeloVerde 2.1 は、 Amazon Sustainability Data Initiative (ASDI) や PlanetScope で公開されている衛星画像を利用し、他の公共データと統合し、AI/ML 技術によって分析することで、5m 四方の高解像度で土地の利用状況をトラッキングし、土地利用の変更を検知します。また、様々なデータソースを統合して分析することで、牛や大豆などの農産物のサプライチェーンを追跡し、透明性を高めています。 まとめ 以上、re:Invent 2023 のサステナビリティに関する発表をご紹介しました。本日ご紹介した内容を含む解説動画については、 Recap イベントのアーカイブ をご覧ください。 また、YouTube のプレイリスト re:Invent Sustainability Content 2023 には、本日ご紹介した講演を含め、サステナビリティ関係の講演がまとまっています。 AWS グローバルインフラストラクチャのサステナビリティ Sustainability innovation in AWS Global Infrastructure (SUS101) サステナブルなアーキテクチャー：過去、現在、未来 Sustainable architecture: Past, present, and future (SUS302) AWS でデータ主導のサーキュラーエコノミーを加速 Accelerate data-driven circular economy initiatives with AWS (SUS202) AI/ML でエンド・ツー・エンドのサプライチェーン透明性を加速 Accelerating end-to-end supply chain transparency with AI/ML (SUS203) AI を利用した ESG レポーティングとデータ主導の意思決定 Using AI for ESG reporting and data-driven decision-making (SUS204) AI, ML, オープンソースデータにより森林破壊を減速 Slowing down deforestation by using AI, ML, and open source data (SUS205) オープンデータによる次世代サステナビリティワークロードの構築 Building next-generation sustainability workloads with open data (SUS304) その他のサステナビリティ事例やお問い合わせ先については、 AWS のサステナビリティ のサイトをご覧ください。

はじめに 本ブログ記事は、 AWS Entity Resolution を利用することにより、ヘルスケア分野における記録のリンクと照合の課題にどのように取り組むことができるかを示し、継続的なエンティティ解決のワークフローにて患者の 360 度ビューを実現する方法の概要を説明します。また、 AWS HealthLake が、ヘルスケアのお客様のデータを安全に保存、変換、管理する上で、どのように役立つかも説明します。本ブログ記事を最後まで読めば、ヘルスケア業界におけるエンティティ解決のための準備が整うはずです。 医療機関は、それぞれが独自の形式とモダリティを持つ大量のデータと多様なデータソースを管理する必要がますます高まっています。ヘルスケアシステム全体において、データ入力と保存方法が異なるため、異なる患者や医療従事者の入力、研究対象、研究レポート、診断レポートと検査、請求と請求書情報など、エンティティの不整合が発生する可能性があります。誤った請求が誤った支払いにつながる可能性がある医療において、エンティティの全体像を把握することは、患者の顧客体験向上のために重要です。 たとえば、情報の統合が不十分で患者の記録に不整合がある場合、実際には受けていないサービスの請求を誤って患者にしてしまったり、実際に受けたサービスの請求がされていなかったり、といった請求ミスにつながる可能性があります。このようなミスは、患者の混乱や不満を引き起こし、負担を増やし、ヘルスケアシステム全体に悪影響を及ぼします。正確で徹底したデータ管理は、効果的な患者ケアが行えるだけでなく、正しい請求や明確なコミュニケーションが重要な医療において、良好な顧客体験実現のために重要です。 ヘルスケア分野において、様々なデータソース間で正確な患者記録の照合を行うために、記録のリンクと照合は重要です。エンティティ解決の実装は、患者照合の改善などのメリットを医療機関にもたらします。データの一貫性が向上し、請求プロセスが合理化されることにより、請求ミスが減少し、システム間の相互運用性が強化され、プライバシー規制への準拠が容易になります。患者データの正確性を維持することで、エンティティ解決は最終的に、ヘルスケアの保険者と医療従事者が、患者ケアの向上、運用コストの最適化、規制遵守の強化を、統一的なアプローチで実現できるようになります。 ヘルスデータの記録精度の課題 ヘルスケアとライフサイエンス (HCLS) の組織が、関連性のある異なる記録のリンクおよび照合を困難にしている、いくつかの課題は以下の通りです。 データの断片化: ヘルスケアには、患者、医療従事者、研究対象と研究レポート、診断レポートと検査、請求と請求書など、多数のエンティティが含まれます。これらのエンティティは、電子カルテ (EHR)、請求プラットフォーム、保険データベース、診断研究など、異なるシステムに分散された大量のデータを生成します。これらの多様なデータソースは、しばしば異なる識別方法や一貫性のないデータ入力を行なっているため、エンティティ記録の不一致や誤りが発生します。この断片化は、様々なエンティティの包括的かつ正確なプロファイルの作成を妨げます。 データ流動性: 現代のヘルスケアにおいて、患者は頻繁に異なる医療機関からケアを求めたり、新しい地域に移住したり、保険プランを変更したりします。これらの変化は、HCLS 組織がヘルスケアシステムとのやり取りにおいて、一貫性のある正確な患者記録を維持するうえでの課題となります。記録が古くなったり断片化したりすることで、患者ケアの質、データの一致、正確性に影響を与えます。 データ品質: データの不正確さは、様々な医療機関で広く共通の課題です。つづりの誤り、入力基準のバラつき、古い情報、不完全な記録などの問題があると、請求データの正確性に大きな影響を及ぼします。こうした不正確さは誤った請求や見落とされた請求などのエラーを引き起こし、患者の不満や医療機関の財務的な齟齬を招くことがあります。請求データの正確性を確保できるかどうかは、財務運営や患者満足度に直接影響するため、最も医療機関が直面する重要かつ困難な課題の 1 つです。 データの相互運用性: ヘルスケアシステムは多様な技術を使用することが多く、それぞれに独自の標準があるため、相互運用性を実現し、プライバシーを維持することは大きな課題です。これらの異なるシステムは、一意の識別子やコード化システムを使用する可能性があり、様々なヘルスケアプラットフォームや組織間において、情報を正確に相互参照するプロセスを複雑にしています。この複雑さは技術的な困難だけでなく、コンプライアンスとプライバシーの課題も発生させます。患者データのセキュリティを保ちつつ、異なるシステム間でアクセス可能かつ正確な状態を維持するためには、慎重にバランスをとる必要があります。医療機関は、米国 HIPAA のような厳格なデータ保護規制を順守する必要があり、これらは患者情報の保護を義務付けています。HIPAA 対応には、シームレスなデータ統合を保証する技術的ソリューションと、機密性を維持し法的基準を順守するための堅牢なプライバシーポリシーの両方が含まれます。 AWS Entity Resolution AWS Entity Resolution は、柔軟に設定できるワークフローを作成し、わずか数分でセットアップでき、企業が複数のアプリケーション、システム、データストアに存在する関連記録を容易に照合、リンク、強化できる HIPAA 適格サービスです。 柔軟なデータ準備: このサービスは、 Amazon Simple Storage Service (Amazon S3) に格納されたデータを AWS Glue テーブルとして読み込むなど、柔軟にカスタマイズ可能なデータプレパレーション (データ準備) を提供します。このサービスには、ソース間のデータをクレンジングおよび整合性の取れたものにできる、データ正規化機能が組み込まれています。ユーザーはデータ入力とスキーママッピングを指定できるので、照合ワークフローが特定の要件と整合性が取れていることを確認できます。 データ保護: AWS Entity Resolution は、すべてのデータ入力に対するハッシュ化や暗号化など、堅牢なデータ保護機能を提供します。これにより、ユーザーは照合プロセス中にデータが保護されたままであることを確認できます。 データの地域化: AWS Entity Resolution におけるデータの地域化サポートは、HLCS 組織にとって極めて重要です。たとえば、機密性の高い遺伝情報が、それが存在する同じ地域内で正確にリンクされ、照合されていることを確認できます。これによりデータの主権が守られ、地域の医療情報規制に準拠するとともに、データの整合性とプライバシーを保護しつつ、安全にグローバルな遺伝子共同研究を行うことが容易に可能となります。 高度で構成可能な照合技術: このサービスは、ルールベースの照合、機械学習 (ML) ベースの照合、データサービスプロバイダ主導の照合など、高度な照合技術を提供します。これにより、関連するヘルスケア情報、研究、検査、診断、プロシージャコード、施設データを正確にリンク、強化できます。この照合技術の柔軟性と選択肢により、医療機関は様々なデータシナリオに対応することが可能になります。 すぐに使えるルールベースの照合: この照合技術には、入力フィールドに基づく一致を見つけるために、 AWS Management Console や AWS Command Line Interface (AWS CLI) にて、すぐに使えるルールセットが含まれます。医療機関は、独自のニーズに合わせるためにこれらのルールを微調整し、入力フィールドに基づいて関連記録を見つけるプロセスを簡素化でき、照合精度がニーズを確実に満たすことが可能となります。 ML を活用した照合: 事前に学習された ML モデルを使用して、複数のデータ入力間で一致を見つけることが可能です。照合品質の信頼度スコアを提供し、それを使って患者記録を照合することができます。 データサービスプロバイダ主導の照合: このワークフローは、数回クリックするだけで、信頼できるデータサービスプロバイダのデータセットと ID に記録をリンク、強化するすることが可能です。 手動処理および自動処理: ユーザーは、新しいデータが時間とともに到着する際、エンティティを最新の状態に保つために、手動の一括処理または自動の増分処理を通じて、ルールベースの照合を開始することができます。 準リアルタイム検索: このサービスは、ルールベースの照合を準リアルタイムに行う検索機能を提供します。これにより、ユーザーは既存の一致IDを同期的に取得できるため、データ取得の効率が向上します。 ヘルスデータを用いたAWS Entity Resolutionの使用例 AWS Entity Resolution は、ヘルスケアおよびライフサイエンスのユーザが、次のような新しいユースケースを実現できるよう支援します。 患者記録の連携: AWS Entity Resolution を利用することで、医療機関は、診療予約、検査結果、保険請求などのイベントを一意の一致IDにリンクでき、患者とのやり取りを統一されたビューで確立できます。これにより、様々な医療機関、保険会社、調剤サービス間で患者データの追跡が容易になり、患者記録と医療業務の全体的な正確性が向上します。 正確かつ継続的な患者の治療過程: AWS Entity Resolution を使用することで、ヘルスケアの保険者と医療従事者は、患者のイベントと入力の360度継続マップを構築できます。目標は、異なるデータセットをリンクすることによって患者ケアを強化することです。たとえば、大学病院ネットワークのメンバー機関からデータが提供される場合、このサービスにより容易に照合技術を利用できます。その結果、大学病院ネットワークは、各患者の統合された包括的な記録を作成できます。この改善された保存記録により、より正確な診断、健康管理、患者ケアの調整を行うことができます。最終的には、全体的な患者の治療過程を改善します。 最適化された臨床開発と研究記録: 新しい医薬品やアウトカムベースの研究は、正確にリンクされたデータ記録が必要です。科学者はこれらのデータを利用して研究を設計し、分析を実行、洞察を引き出します。これにより、最終的には臨床研究のアプローチを改善したり、臨床試験の被験者募集のためのコホート全体に共通する傾向を特定したりすることが可能となります。AWS Entity Resolution は、異なるデータソースを正確にリンクするのに役立つ、様々な照合技術を提供します。これにより、研究データの統一的な照会が促進され、データの不一致や冗長性を最小限に抑えながら、研究結果の信頼性を高めるのに役立ちます。たとえば、研究者や臨床医は、患者の反応をより効果的に追跡、分析、予測できるため、個別化医療の開発や治療戦略の最適化に貢献できます。 リンクされた医薬品コード: 製薬研究所、バイオテクノロジー企業、臨床研究機関、およびそれぞれのサプライチェーンは、複数の異なる分類、識別子、コードを利用して、医薬品と有効成分を一意に識別します。これらは、地域、国、標準化組織 (ATC、NDC、SNOMED、DIN) によって異なります。AWS Entity Resolution を使用することで、組織は識別子を含むデータセットをマップしてリンク、一意なエンティティに変換することができ、分析と研究を実行、サプライチェーンを最適化することができます。 相互運用性に関する義務 米国のヘルスケアセクターは変革期を迎えており、EHR ベンダー、医療機関、医療保険制度を含む様々な関係者間で、Fast Healthcare Interoperability Resources (FHIR) データ形式を採用するルールが形成されています。メディケアおよびメディケイドサービスセンター (CMS) の相互運用と患者アクセスに関する最終規則や、今後の法律規制の枠組みは、より広範で包括的なヘルスデータ相互運用の標準化推進を後押ししています。 これは医療保険者だけでなく、各々の専門的な規制ガイドラインに対応している医療制度と EHR ベンダーにも影響が及びます。これらの規制は、氏名、電話番号、住所など、患者照合に不可欠な重要データ要素へのアクセス支援をますます推奨しています。この新たな状況は、FHIR の採用が技術的な移行だけでなく、多面的なヘルスケアエコシステム全体での合理化された、安全な標準化データへのアクセス性を確保するための包括的な移行であることも示しています。 AWS HealthLake AWS HealthLake などのサービスを使用することにより、ヘルスケアシステムが必要な相互運用性要件を満たすのに役立ちます。HealthLake の FHIR ベース API を使用することで、医療機関は、臨床記録や患者の記録などの大量のヘルスデータを、オンプレミスのシステムからセキュアかつコンプライアンスに準拠した、従量課金制のクラウドサービスに簡単にインポートできます。HealthLake を活用することで、医療システムは医療上の要求を満たすだけでなく、組み込まれた自然言語処理 (NLP) モデルを使用して、顧客が必要とする医療情報を理解して抽出します。そして、安全かつ効率的な方法でイノベーションを推進し、患者ケアを改善させることができます。 ヘルスデータの容易な取り込み: ヘルスケアシステムは、臨床ノート、検査報告書、保険請求、その他のヘルスデータを S3 バケットに効率的にインポートできます。一括インポート機能により、後続のアプリケーションとワークフローのデータ取得が簡素化されます。 FHIR REST API 操作: AWS HealthLake は FHIR REST API オペレーションをサポートしており、ヘルスケアシステムはデータストア上で CRUD オペレーションを実行できます。これには FHIR 検索を実行し、効率的なデータ取得を可能にする機能が含まれます。 安全な HIPAA 適格ストレージ: AWS HealthLake は、データが安全な HIPAA 適格手法にて AWS クラウドに保存されることを保証しています。FHIR R4 標準形式でデータの問い合わせ、および構造化できるよう、FHIR 形式に準拠しています。 非構造化データの変換: AWS HealthLake には、 Amazon Comprehend Medical を使用した統合医療自然言語処理 (NLP) 機能を備えています。これにより、生の医療テキストデータが構造化情報に変換され、医療テキストからエンティティ、エンティティ関係、エンティティ特性が抽出されます。次に、このデータは新しいリソースタイプに整理され、データへのアクセス性が向上します。 用例: FHIR 患者エンティティの解決 このセクションでは、AWS HealthLake に保存されている患者記録のエンティティ解決を実行するための AWS Entity Resolution を活用したソリューションを紹介します。AWS HealthLake 内のエンティティ解決の実装は、データストア全体にわたりデータ整合性を確保する上で重要な基盤として機能します。この文脈における「エンティティ」は、単一の患者、医療従事者、組織、医療施設を指します。エンティティ解決は、患者や医療従事者などの同じ実世界のオブジェクトに関連する AWS HealthLake 内の複数の記録を判断する重要なプロセスです。たとえば、ヘルスケアのお客様からは、複数の内部システムや複数の組織に由来するデータソース間で患者を照合することには課題があると聞いています。 このプロジェクトでは、AWS Entity Resolution を使用し、ML ベースの照合アルゴリズムを採用、異なる患者記録を正確に識別およびリンクし、信頼度スコアを備えた包括的な患者プロファイルを確立できる AWS HealthLake の機能を強化することにより、この課題に対処しています。これにより、正確かつ一貫性のあるヘルスケアデータ管理が可能になります。このプロセスは、 マスターデータ管理 (MDM) 、 エンタープライズマスター患者インデックス (EMPI) として知られる、より広範かつ必要なステップの 1 つです。 アーキテクチャ 次の図は、この患者エンティティ解決ソリューションのアーキテクチャを示しています。このソリューションは AWS ネイティブサービスを活用、 AWS Well-Architected フレームワークに準拠し、セキュリティ、信頼性、パフォーマンス効率、コスト最適化などの主要な側面にわたり堅牢なアーキテクチャを確保しています。 図1: アーキテクチャ図 このソリューションには、次のハイレベルなステップとAWS ネイティブサービスが含まれています: Amazon Athena の SQL クエリを使用して、AWS HealthLake データストアから患者識別情報を取得します。 Amazon Athena クエリは、HealthLake データストアが最初に起動されるときに自動的に作成される AWS Lake Formation リソースリンクデータベースに対して実行されます。 クエリの結果セットは、CSV ファイルとして S3 バケットに保存されます。クエリに使用される患者の FHIR リソースの識別子属性には、HealthLake 患者リソース ID、名前、住所、電話番号、生年月日、性別などの属性が含まれる可能性があります。 AWS Entity Resolution に患者データセットを指定します。 前のステップで患者データセットが作成されたら、 AWS Glue クローラー を使用してデータセットをクロールし、 AWS Glue Data Catalog テーブルを生成します。これにより、このテーブルを AWS Entity Resolution サービスへ取り込む準備が整います。 AWS Entity Resolution を使用して ML 主導の照合を生成します。 このソリューションでは、AWS Entity Resolution のスキーママッピングと照合ワークフローが作成され、入力患者データを照合する方法と照合結果を書き込む場所が定義されます。デフォルトでは、このソリューションは入力された患者データセット全体で一致を見つけるために、事前に構成された 機械学習ベースの照合 技術を使用します。 AWS Lambda 関数が照合ワークフローのジョブをトリガーし、AWS Entity Resolution により生成された一致 ID と信頼度スコアを含む結果を別の S3 バケットに書き込みます。照合ワークフローで、独自の照合ルールを定義し、エンティティ解決の要件を満たす完全一致を見つけるために、 ルールベースの照合 技術を使用することもできます。 AWS Entity Resolution の 一致ID を AWS HealthLake の患者 FHIR リソースに挿入します。 AWS Entity Resolution が一致する患者記録を特定すると、ソリューションは Lambda 関数を使用してAWS Entity Resolution の結果を読み取り、解析します。その後、信頼度スコアと関連付けられた AWS Entity Resolution で生成された一致IDを、患者の FHIR リソースの新しい識別子属性に挿入します。これにより、AWS HealthLake データストア全体の一致する患者記録を簡単に識別してリンクできるようになります。 前提条件 このソリューションをデプロイする前に、 AWS CloudFormation テンプレートの入力パラメータとして使用する次の情報が必要です。 患者エンティティ解決を実行する AWS HealthLake データストアのデータストアID 次の図に示すように、AWS HealthLake データストアにリンクされている AWS Lake Formation データベースのデータベース名と共有リソース所有者ID ( またはカタログ ID) 図2: Lake Formation データベース名と共有リソース所有者 ID を特定するスクリーンショット 導入 このソリューションを実装するには、この AWS CloudFormation テンプレート をデプロイします。 このテンプレートの出力には、 ahl-entity-resolution-state-machine という名前の AWS Step Functions が含まれます。このステートマシンをオンデマンドで実行することで、ソリューションを実行し、AWS HealthLake データストアの患者エンティティ解決を実行できます。このテンプレートは、毎夜 10 時のように、ステートマシンを定期的に自動トリガーする AWS EventBridge スケジューラー も作成します。このスケジューラーのスケジュールをビジネスニーズにあわせて変更することで、ソリューションの実行頻度を調整できます。 結果の検証 このソリューションによって識別された一致した患者記録を確認するには、次のいずれかを実行します: Step Function にリンクされた AWS CloudWatch ロググループ に移動してください。このロググループには、各ステップの入力と出力を含む、Step Function の実行に関する詳細な情報が含まれています。 Step Function の実行ページに移動し、ステートマシンの最後のステップの出力を確認してください。ステートマシンの最後のステップは、一致した患者リソース ID ( source_id ) と AWS Entity Resolution が返した match_id を含む一致結果を生成します。 図3: ステップ関数の実行出力のスクリーンショット AWS Entity Resolution の照合出力から患者リソース ID を特定したら、以前に特定した患者リソース ID を使用して AWS HealthLake データストアで患者リソースをクエリできます。match_id が識別子属性値として示されている AWS Entity Resolution から、患者に新しい識別子属性が作成されたことがわかります。 次の図に示すように、AWS Entity Resolution から返される一致 ID は、照合ワークフローの設定や患者記録が大幅に更新されない限り、複数のワークフロー実行にわたり、ソース患者記録に対して同じままです。これらの一致 IDは、HealthLake データストア内の内部患者記録を相互にリンク付けするためのものであり、HealthLake 外の後続システムまたは外部システムで識別子として使用しないでください。 図4: エンティティ解決の一致 ID を示す HealthLake クエリのスクリーンショット また、次の図に示すように、サンプルの Amazon QuickSight ダッシュボードを構築し、HealthLake データストアにある複数の患者記録が、このソリューションによって HealthLake に挿入された新しい識別子属性に基づき、AWS Entity Resolution によって返された同一の match_id に合致していることを確認しました。 図5: 同じAWS Entity Resolution 一致 ID によって照合された複数の患者記録を示す QuickSight ダッシュボードのサンプル このソリューションは、HealthLake における患者エンティティ解決のベースラインを提供します。これは柔軟で拡張性のあるフレームワークで、これをベースに独自のアプリケーションやワークロードを構築できます。このソリューションを拡張または変更して、固有のヘルスケアエンティティ解決の要件を満たすことができます。 クリーンアップ 本ブログ記事の例に関連する不要なインフラストラクチャコストを避けるために、CloudFormation スタックと、前提条件として追加した他のすべての手動リソースを必ず削除してください。 次のステップ この変革の旅に乗り出すには、 AWS Entity Resolution と AWS HealthLake に関するドキュメント、ウェビナー、ビデオ、その他のブログ記事などのリソースを探索してください。AWS HealthLake は、高度な小児科医療など、他のヘルスケア分析ニーズにも対応できます。その実現方法を説明したブログ記事「 Amazon HealthLake を使用したスケーラブルな FHIR ベースのデータ分析による小児科医療の進歩 」や「 AWS Entity Resolution: 複数のアプリケーションとデータストアからの関連記録を照合してリンクする 」を参照してください。実践的アプローチについては、 AWS Entity Resolution 、 AWS HealthLake 、 AWS HealthLake Patient Matching のワークショップを確認してください。 まとめ: AWS Entity Resolution および AWS HealthLake AWS Entity Resolution と AWS HealthLake は、シームレスに統合することで、ヘルスケアデータ内のエンティティの管理、構造化、正確な解決を包括的に実現するソリューションを医療機関に提供できます。この統合により、データの正確性が向上し、患者ケアの連携が改善され、規制へのコンプライアンスが確保され、ヘルスケア企業が研究、イノベーション、高品質な患者ケアの提供に効果的にデータを活用できるよう後押しします。 翻訳はソリューションアーキテクトの松浦が担当しました。原文は こちら です。 Tyler Replogle Tyler Replogle は、AWS で世界中の公共部門を担当するシニアソリューションアーキテクト兼テクニカルデータベースリーダーです。顧客やパートナーがエンドミッションソリューションを AWS で実行できるように支援しています。彼は建築が好きで、レゴ、マインクラフト、コーディングを使った建築を通じて、3 人の娘たちとつながる方法を見つけました。 Kai Xu Kai Xu – Kai は AWS のシニアソリューションアーキテクトで、学術医療センターのお客様をサポートしています。Kai はヘルスケア業界で 15 年以上の経験があり、情報セキュリティ、コンプライアンス、クラウド移行に情熱を注いでいます。自由時間には、読書、サッカーゲーム、そして子供たちとの楽しい時間を楽しんでいます。

Amazon Web Services (AWS) を導入する主な理由の 1 つは、ワークロードの革新、構築、デプロイ、モニタリングを可能にする、AWS の幅広いサービスの選択肢であるというご意見をお客様からいただいています。AWS は、ほとんどすべてのクラウドワークロードをサポートするために、そのサービスを絶えず拡大してきました。現在、AWS はコンピューティング、ストレージ、データベース、ネットワーク、分析、機械学習 (ML)、人工知能 (AI) など、200 を超えるフル機能のサービスを提供しています。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) は、他のどの主要クラウドプロバイダーよりも多い 750 を超えるインスタンスを一般提供しており、 リレーショナル、分析、key-value、ドキュメント、またはグラフといった多数のデータベース から選択することができます。 AWS は、データを別のクラウドプロバイダーやオンプレミスに移行するオプションもこの選択肢に含まれている必要があると考えています。このため、3月5日より、お客様が AWS 外への移行を希望する場合のインターネットへのデータ転送 (アウト) (DTO) 料金が免除されることになりました。 AWS は、 AWS リージョンからインターネットへのデータ転送のために 1 か月あたり 100 ギガバイトの無料枠を提供 しているため、お客様の 90 パーセント以上は既に、料金を発生させることなく AWS 外へのデータ転送を実行しています。これには、Amazon EC2、 Amazon Simple Storage Service (Amazon S3) 、 Application Load Balancer などからのトラフィックが含まれます。さらに、 Amazon CloudFront からのデータ転送についても、毎月 1 テラバイトの無料枠を提供しています。 移行中に 1 か月あたり 100 ギガバイトを超えるデータ転送が必要になる場合は、 AWS サポート に連絡して、追加のデータのための無料 DTO 料金をリクエストすることができます。AWS サポートを通じてリクエストする必要がある理由は、毎日何億件ものデータ転送が行われているため、インターネットへのデータ転送が通常業務の一環として行われる転送なのか、別のクラウドプロバイダーやオンプレミスへの切り替えの一環として行われる 1 回限りの転送なのかを判断できないことがほとんどだからです。 リクエストは、AWS アカウントレベルで審査されます。承認されると、移行されているデータに対するクレジットが付与されます。アカウントを閉鎖したり、AWS との関係を変更したりする必要は一切ありません。戻りたいときにいつでも戻ってきてください。もちろん、同一の AWS アカウントが無料 DTO を何度も申請する場合は、さらなる審査が行われます。 AWS では、お客様に選択権があるべきだと考えており、AWS 外にデータを移行する選択も例外ではありません。インターネットへのデータ転送料金の免除は、 欧州データ法 に規定された指示に従うものでもあり、世界中のあらゆる AWS リージョンからの AWS のお客様全員に提供されています。 選択の自由は、データ転送料金に関するものだけではありません。AWS は、ユーザーが選択した他の IT プロバイダーとのソフトウェアの使用を容易にする、 公正なソフトウェアライセンスの原則 もサポートしています。 詳細については、こちらのブログ記事をお読みください。 切り替えにあたり、 詳しい情報について「よくある質問」 を確認、または AWS カスタマーサポートに連絡 して DTO のクレジットをリクエストすることができます。 とは言うものの、私は皆さんがこれからも AWS を選択することを心から願っています。 — seb 原文は こちら です。

2024 年 1 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Kubernetes Service(Amazon EKS) 編 AWS SAW(AWS Support Automation Workflows) は AWS サポートエンジニアリングチームが作成した安全で高速なセルフサービス自動化を使用して、AWS 環境の一般的な問題を解決やログの収集、分析などを行います。本セッションでは Amazon Elastic Kubernetes Service(Amazon EKS) で利用可能な 3 つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EKS を利用した運用を実施されている方 Amazon EKS のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること Amazon EKS 向けに利用可能な 3 つの SAW(AWS Support Automation Workflows) について利用ユースケースおよび概要を理解することができます。 スピーカー 坂元 龍太 クラウドサポートエンジニア Amazon DynamoDB – How it works Amazon DynamoDB が信頼のおけるシステムを構築する上でどのようなことを行なっているのかを説明し、基盤のコンポーネントがどのように設計されたのかを説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon DynamoDB をご利用中の方 Amazon DynamoDB の基礎的な内容を理解し、効率的な利用方法を学びたい方 本 BlackBelt で学習できること Amazon DynamoDB の背景知識を身に着けることにより、データモデリングの注意点やアプリケーション構築の際に気を付けるべき点について、Amazon DynamoDB の特性を踏まえて理解できるようになります。 スピーカー 堤 勇人 ソリューションアーキテクト Amazon MemoryDB for Redis 本セッションでは、Amazon MemoryDB for Redis の特徴と機能、ユースケースといった基礎的な部分から、バックエンドの動きやどのように耐久性を担保しているのかという技術的背景をまとめて解説致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon MemoryDB for Redis とは何かを知りたい方 Amazon MemoryDB for Redis をご利用予定の方 Amazon ElastiCache や Redis をご利用中で、より耐久性を高めたい方 本 BlackBelt で学習できること MemoryDB と他のサービスとの使い分け、有効な活用方法といった理解が深まります。 スピーカー 堤 勇人 ソリューションアーキテクト Amazon Monitron Part 3（サービス連携編） Amazon Monitron は回転機器の振動や温度データを、設備に貼り付けた電源不要のセンサーデバイスでクラウド上へ収集しクラウドで分析することで、潜在的な障害の予兆を検知して、計画外のダウンタイム発生を防止するソリューションです。このセミナーでは Amazon Monitron シリーズ Part 3 として、Amazon Monitron と外部システムとの連携と、re:Invent 2023 で発表された Amazon Monitron の最新 Update について説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 工場、プラント、物流拠点等で設備の計画外ダウンタイムを減らしたい方 モーター・ギア・ベアリング・ポンプ・コンプレッサーなどの回転体部品を多く稼働させておりそれらの点検保守を効率化したい方 機器の計画保守（定期的な点検保守）を減らし、データに基づく予測型保守を導入したい方 本 BlackBelt で学習できること Amazon Monitron と外部システムとの連携と、re:Invent 2023 で発表された Amazon Monitron の最新 Update について説明します。 スピーカー 村松　謙 ソリューションアーキテクト AWS Distro for OpenTelemetry（前編） OpenTelemetry とは AWS Distro for OpenTelemetry の前編として、OpenTelemetry について説明したコンテンツとなります。 資料（ PDF ） 対象者 Observability に関心のある方 OpenTelemetry の利用を検討している方 AWS Distro for OpenTelemetry の利用を検討している方 本 BlackBelt で学習できること OpenTelemetry の概要を理解することが可能です。 スピーカー 津郷　光明 ソリューションアーキテクト モダナイゼーションプロジェクト立ち上げのポイント ここ数年でモダナイゼーションという言葉が浸透し、実際に取り組まれている事例が増えています。モダナイゼーションプロジェクトも従来のプロジェクトの延長線上にあるものの、扱う技術やアーキテクチャのみならず、組織・人やプロセスなど検討すべき範囲は広くなり、また難易度もあがっていると考えられます。本セッションでは、モダナイゼーションプロジェクトを立ち上げる際に検討・考慮すべきポイントについてお話します。 資料（ PDF ） | 動画（ YouTube ） 対象者 システム刷新を検討している責任者やリードする方 システムのモダナイゼーションに取り組んでおり、進め方のポイントを確認したい方 本 BlackBelt で学習できること モダナイゼーションプロジェクトを立ち上げる際に、検討・考慮すべきポイントについて理解を深める スピーカー 平岩 梨果 ソリューションアーキテクト

生成 AI の発展と共にモデルの規模はどんどん大きくなり、デプロイするためのインフラの選択や設定はますます複雑になっています。 Amazon SageMaker JumpStart は大規模言語モデルを最適な設定、かつワンクリックでデプロイする機能を提供します。 オープンソースコミュニティとの連携を通じ 、AWS はこれまで Meta の Llama2 や TII の Falcon 、 rinna の japanese-gpt-neox などを JumpStart で提供してきました。このたび 株式会社サイバーエージェント から公開されている大規模言語モデルである CyberAgentLM2-7B-Chat (CALM2-7B-Chat) が JumpStart から利用できるようになりました。 サイバーエージェントは 2023 年 6 月に独自の LLM である OpenCALM を初めて発表し、 このモデルを用いてクイズ王に挑戦するブログ を掲載しました。今回 Amazon SageMaker Jumpstart から利用できるようになったモデルは、11 月に同社から発表された次世代の CALM2 シリーズのチャット用途向けの CALM2-7B-Chat です。このモデルは 1.3 兆トークンの日本語と英語の公開データセットで学習された Transformer ベース（Llama）の CyberAgentLM2-7B (CALM2-7B) をチャット向けに教師有り学習でファインチューニングしたモデルです。入出力の長さとして 32,000 トークンに対応しており、日本語の文章として約 50,000 文字を一度に処理することができます。モデルは商用利用可能な Apache License 2.0 で提供されています。 70 億パラメータのモデルであるため、昨今の大規模モデルに比べて比較的軽量です。応答速度も早く、軽量ながら高い精度を期待できます。そのため、有料なプロプライエタリモデルの代用としての利用が考えられます。例えば、コストを最適化したい場合や、プロプライエタリなモデルに送信できない社内の秘匿情報を使用したい場合などに CALM2 の利用を検討できます。また、CALM2-7B-Chat は 50,000 文字の日本語を一度に処理することができるため、他の OSS モデルと比べ RAG や要約などを用いたチャット用途で高い精度を期待できます。また、軽量なモデルのため低コストでファインチューニングを行いことができ用途にあったモデルへのカスタマイズに向いています。 今回のアップデートにより、この CALM2-7B-Chat を SageMaker JumpStart を利用して素早くお試しいただけます。また、データを用意するだけで JumpStart から追加学習を行えるため、各ユーザーの用途にあったチャットモデルを簡単に構築できます。 Amazon SageMaker JumpStart で CALM 2 のモデルを起動する Amazon SageMaker Studio から JumpStart のメニューを起動します。 SageMaker Studio を使うのが初めてという方は、 SageMaker Immersion Day のハンズオン を参考に環境を構築してください。環境を作るだけ / 起動するだけでは料金はかかりません。実行する Jupyter Notebook やエンドポイント、学習ジョブなどに割り当てたインスタンス、またデータの保管や転送に対し課金が発生します。ここから先、課金が発生するタイミングについてはその旨と価格の目安を記載します。 SageMaker Studio にアクセスしたら、 JumpStart のメニューから “calm2” で検索を行います。 ヒットしたモデルカードをクリックすると、モデルの詳細画面が開きます。デプロイするのに必要なのは、 “Deploy” のボタンを押すだけです。 Deployment Configuration ではインスタンスの選択やエンドポイントの設定を行うことができます。インスタンスは最適なものからのみ選べるようになっているので、非常に長いドロップダウンリストに悩まされることはありません。 Security Settings ではエンドポイントの作成に使用する IAM ロールや VPC 、モデルの暗号化に使うキーを設定できます。 Deploy を押すとデプロイが開始します。 4~5 分で完了します。 “In Service” となったらデプロイ完了です。この時点から、エンドポイント用に指定したインスタンスの課金 ( 今回は ml.g5.2xlarge で オンデマンドの価格 は 2024 年 2 月時点で $1.212/時 、同時期の換算レートで 181 円/時 ) が発生しますが、本ブログの動作確認をするだけなら 100 円程度で済みます。 Use Endpoint from Studio のセクションから “Open Notebook” をクリックします。 ここで、ノートブックを動かすためのインスタンスが別途必要になります。ノートブックが動けばよいので、それほどスペックのあるインスタンスは必要ありません。今回使用したインスタンスは ml.t3.medium で 東京リージョンのオンデマンド価格 は $0.065 (同時期の換算レートで 10 円/時) です。料金が気になる方は、ローカル PC や Amazon SageMaker Studio Lab から API を通じ利用することもできます。 Notebook を立ち上げると目次が表示されます。Notebook には複数のタスクをすぐに試せるようにプロンプトエンジニアリングのサンプルが提供されています。 CALM2 に合わせてプロンプトのフォーマットを行う実装になっており、異なるユースケースでのプロンプトエンジニアリングの検証ができます。例えば、SageMaker の推論エンドポイントを呼び出す際は以下のようなコードでお試しいただけます。 import json import boto3 newline, bold, unbold = '\n', '\033[1m', '\033[0m' endpoint_name = "jumpstart-dft-hf-llm-calm2-7b-chat-bf16" # Your Inference Endpoint parameters = { "max_new_tokens": 256, "return_full_text": False, "do_sample": True, "top_k": 2, "repetition_penalty": 1.1, "stop": ["<|endoftext|>", "USER:"] } def query_endpoint(payload, do_print = False): client = boto3.client('runtime.sagemaker') response = client.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/json', Body=json.dumps(payload).encode('utf-8')) model_predictions = json.loads(response['Body'].read()) generated_text = model_predictions[0]['generated_text'] if do_print: print ( f"Input Text: {payload['inputs']}{newline}" f"Generated Text: {bold}{generated_text}{unbold}{newline}") return generated_text def format_prompt (prompt_pairs, system_add=True): prompt = [ f"{uttr['speaker']}: {uttr['text']}" + ("<|endoftext|>" if uttr['speaker'] == "ASSISTANT" else "") for uttr in prompt_pairs ] prompt = "\n".join(prompt) if system_add: prompt = ( prompt + "\n" + "ASSISTANT: " ) return prompt prompt = [ { "speaker": "USER", "text": "Hello, you are an assistant that helps me learn Japanese." }, { "speaker": "ASSISTANT", "text": "Sure, what can I do for you?" }, { "speaker": "USER", "text": "VRはなんですか。" } ] formated_prompt = format_prompt(prompt) payload = { "inputs": formated_prompt, "parameters": parameters } query_endpoint(payload) 検証が終了したら、忘れずに 1) Notebook に使ったインスタンスを停止して、 2) エンドポイントのインスタンスも停止してください。 SageMaker Studio の画面の左側にある電源メニューから Notebook の起動に使われているインスタンスを確認、停止できます。 JumpStart のエンドポイントはモデルの詳細画面にある Delete Endpoint から停止することができます。 モデルの詳細画面を見失った場合、JumpStart の Launched JumpStart assets のメニューからいつでも参照できます。 Title がリンクになっており、モデル詳細画面が開けます。一度エンドポイントを停止すると、ここには表示されなくなります。 Amazon SageMaker JumpStart で CALM2 を FineTune する方法 また、SageMaker JumpStart ではファインチューニング用のコードを書かずに、自社のデータを用意するだけで簡単にファインチューニングすることが可能です。 軽量な OSS モデルは大規模な API モデルと比較してレスポンス速度とコストの面で優れており、特定タスクに特化させるファインチューニングを行うことで該当タスクにおいて API モデルに匹敵する高精度なモデルを作れる可能性があります。例えば、情報抽出タスクに特化させたり、特定のフォーマットや文体で要約を行ったり、人格を模倣したりするなどのプロンプトエンジニアリングだけでは精度が不十分なユースケースに向いています。モデルのパラメータ数と学習させるデータ量による精度の違いについては以前 API と OSS のモデルを比較した記事 で検証しており、モデルの選定と必要な学習データ量についての目安としてご参照ください。 モデルのファインチューニングを行うには、まずはデータを用意する必要があります。CALM2 のファインチューニングはデータのフォーマットとして、ドメイン適応ファインチューニング（Domain Adaptation Fine-Tuning）とインストラクションファインチューニング（Instruction Fine-Tuning）をサポートしています。一般的に、特定のタスクに特化させることが目的の場合インストラクションファインチューニングが利用されることが多く、ドメイン適応ファインチューニングはラベルなしデータで特定ドメインの知識を強化する際に利用されます。 ドメイン適応ファインチューニングの場合は学習データは CSV / JSON / TXT ファイルを用意します。インストラクションファインチューニングの場合は、学習データが含まれる JSON 行 (.jsonl) 形式のファイルと入出力のフォーマットを記述する JSON ファイルを用意します。例えば、 instruction , input , output の列が含まれる JSON 行 データセットで情報抽出タスクで学習させる場合は以下のような JSON ファイルで入出力のフォーマットを指定します。詳細なデータフォーマットの仕様については SageMaker JumpStart のモデルの詳細画面をご確認ください。 { "prompt": "USER: 与えられた文脈から、質問に対する答えを抜き出してください。\n\n文脈：{input}\n質問：{instruction}\nASSISTANT: ", "completion": "{output}<|endoftext|>" } このブログの検証を行いたい場合は、例えばサンプルデータとして Databricks 社が公開している Dolly Dataset や要約データセットの xlsum をダウンロードし上記のフォーマットを指定する JSON を手元に作成してください。 データを用意したら、S3 にアップロードし学習データが格納された S3 パスを指定します。また、必要に応じてハイパーパラメーターも変更することが可能です。学習の設定が完了したら “Train” を押すと学習が開始されます。学習時間はデータ量、インスタンスサイズ、バッチサイズ、学習手法（フルパラメータ/LoRA）などのハイパーパラメーターにより変化します。 学習が終了したら、ファインチューニングしたモデルをデプロイすることが可能です。 AWS Japan の大規模言語モデルに対する取り組み AWS Japan では昨年 7 月 3 日に「 LLM 開発支援プログラム 」を発表し、日本で大規模言語モデルの構築にチャレンジするお客様を支援しており、 1 月 30 日には成果発表が行われました 。開発支援プログラムの成果として Karakuri LM 、 Nekomata 、 stockmark-13b 、 Watashiha-Llama2-13B-Ogiri など、LLM のトレーニングを最大 50 ％削減可能な AWS Trainium を活用して学習を行った 複数のモデルが OSS モデルとして公開されています 。 AWS は、常にお客様の声に耳を傾け、そのご要望にお応えすることを大切にしています。特に日本のお客様からいただいたフィードバックは、サービス改善に欠かせない貴重な意見となっています。日本語対応の強化やモデルのカスタマイズなど、お客様のニーズに合わせて機能を拡充することで、AWS はより使いやすく、便利なサービスを提供していきます。先の API と OSS モデルを比較した記事 のように性能検証も公平に行い、モデルのメリットを最大限に引き出せるよう取り組んでまいります。AWS はオープンプラットフォームとして、常に進化を続けていきます。その原動力となるのが、お客様の生の声です。今後もお客様とともに歩み、ご要望にお応えすることで、AWS の価値を高めてまいりたいと考えています。ぜひ引き続き、ご意見・ご要望をお寄せください。 著者プロフィール 前川 泰毅 (Taiki Maekawa) は AWS Japan のソリューションアーキテクトでメディア領域のお客様中心にアーキテクチャ設計や構築を支援しています。機械学習領域を得意としておりソリューションやサンプルコードの作成を行っています。 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Web 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

生成AIが急速に普及する中、文部科学省が2023年7月に「初等中等教育段階における生成AIの利用に関する暫定的なガイドライン」を公表しました。⽂部科学省では、当ガイドラインを踏まえ、リーディングDXスクール事業におけるパイロット的な取組として、教育活動や校務において⽣成AIの活⽤に取り組む学校を指定し、「効果的な教育実践の創出」を⾏うことで、今後の更なる議論に資するよう、知⾒の備蓄をすすめることとしています。パイロット校に指定されたうちの1校が⼋丈町⽴富⼠中学校です。富⼠中学校での⽣成AI活⽤を⽀援したライフイズテック株式会社にお誘いいただき、2023年12⽉に中学2年⽣の授業を視察しました。本記事ではその模様をレポートします。 素敵なウェルカムボードでお迎えしてくださいました！ 八丈島の魅力を伝えるオリジナルチャットボットを制作！ 富士中学校では、ライフイズテック株式会社の協力のもと、3年前から生徒が島の魅力を探究し、「ライフイズテック　レッスン」を活用したWebサイト制作を通じて島外に発信するという地域課題解決型の取組を進めています。 今回は、富士中学校の２年生が、生成AIを活用しながら「八丈島の魅力を伝えるチャットボット」を制作しました。ライフイズテック レッスンを活用して制作を進めているオリジナルのWebサイトに、このチャットボットを搭載させ、Webサイトをさらに充実させようというものです。子どもたちがAIを使って新たな価値の「生産者」になるために「課題解決をベースに生成AIの使い方を学び実践する」という高度なチャレンジになります。 チャットボットは、ライフイズテック社で開発中の学校向け生成AIサービスを利用して、計6時間の授業で作成しました。生成AIが書いたプログラミングコードを、ブラウザのみでコードを記述/ 実行 / デバッグできるクラウドベースの統合開発環境（IDE）である AWS Cloud9で動作を確認しながらチャットボットを作成していきます。学校向け生成AIサービスは、学校向けに特化した機能やUI・UXの最適化を図ってあり、生徒も教師も安心安全に生成AIを利活用できるようになっています。 最初の2時間では、チャットボットの枠組を作るため、学校向け生成AIサービスを活用し必要なプログラミングコードを生成しました。 視察した3-4時間目では、先生が生成AIのプロンプトの書き方や、個人情報・著作物など入力してはいけない文言についてレクチャーをした後、プロンプトを体験。最初は何を入れるべきか、躊躇していた生徒もいましたが、「どんなことでも入れて大丈夫だよ」という声掛けで、どんどん活用できるようになり、「八丈島の魅力を伝えるチャットボット」を作成するためのアイディアを練りました。プロンプトの回答が返ってくるのに少し時間がかかるので、その間は教材を見たり、別の作業をしたりと工夫していました。次に、練ったアイディアをチャットボット制作画面に入れました。実際にチャットボットが思うような操作をするか確認。真剣な顔をして、集中して取り組んでいる生徒たちの姿が印象的でした。 ライフイズテック社で開発中の学校向け生成AIサービスにはプロンプトのヒントを出す工夫などがあり、生徒たちが使いやすいインターフェースになっています チャットボットはAWS Cloud9を立ち上げて作成します 「チャットボットが観光施設の問い合せ先の電話番号を伝えてしまうけど、大丈夫かな？」と先生に聞いている生徒も。先生からは「観光施設に、電話番号を出してもよいか、電話で聞いてみたら？」とアドバイスされ、「電話だと緊張するから、メールで聞いてみる」とのこと。実社会と結びついた学習の広がりを感じた一幕でした。 最後の5-6時間で、画像生成AIを使って、チャットボットのキャラクターを作成しました。3-4時間目で先取りで作業をしている生徒もいました。狙った画像が出るまで、何度もプロンプトを工夫していました。 画像生成はAmazon SageMakerにStable Diffusionをデプロイして利用しています 山下孝輔先生は、「（生徒たちは）面白かったでしょう。響くものがありました。」と手応えを感じてくださったと同時に、「生成AIを利用すると、中学生も高度なことができてしまう。ただどこまで理解しているかは、確認が必要」「生成AIに『使われない』ために、自分の思いやアイデアをいかに取り入れられるか、AIを使っていかに発展させられるかということに今後チャレンジしていきたい」と語っていました。 放課後の時間にも、クラスの半数以上の生徒たちが残っていて、続きの作業をしていましたが、そこで一番盛り上がっていたのは、先生の顔を真似た画像を生成する競争でした！ 生徒が生成AIを使うための工夫 今回、富士中学校での授業に協力したライフイズテック社は、次世代デジタル人材育成を手がけ、「中高生ひとり一人の可能性を一人でも多く、最大限伸ばす」をミッションに2010年に創業したEdTech企業です。主力事業である中学校・高校向けクラウド教材「ライフイズテック レッスン」は、全国600以上の自治体で4,000校の公立・私立学校、約120万人が利用(2023年8月時点)する、情報・プログラミング学習サービスへと成長しています。さらに生成AIの登場以降、すでに数多くの生成AI×教育の新サービス開発や取組を進めており、AIネイティブのための教育変革を牽引しています。 本授業で利用した学校向け生成AIサービスのプロダクトマネージャーの窪田秀行氏から、「文章生成／画像生成を生徒のみなさんが簡単かつ安心して使うことができる環境の提供が必要と考えています。例えば、画像生成のためのプロンプト入力の場面においては、必要な構成要素及びその入力例の組み合わせからプロンプト作成できる機能を具備し、プロンプトの専門知識の必要性を軽減させる工夫をしています。また、生成された画像を安心・安全に生徒画面へ届けるための仕組みとして、Amazon Rekognitionを活用させていただき、性的・暴力的な画像の生成を抑止する機能も搭載しています。」と生徒が生成AIを使うための工夫を教えていただきました。 今回の視察した授業では、中学生が最先端のことを学び、AIの利用者に留まらず、AIを使った課題解決者や開発者といった「生産者」への一歩を踏み出したことに感銘を受け、生徒たちを頼もしく感じました。 【参考：AWS導入事例】ライフイズテック株式会社 「本格化する情報教育をオンラインプログラミング教材で支援全国の中高生が“学び”に没頭できる環境を AWS で実現」 このブログは、アマゾン ウェブ サービス ジャパン合同会社　パブリックセクター　教育事業本部　初等中等教育/EdTech営業部　アカウントエグゼクティブである 尾島菜穂 が執筆しました。

3月4日週は忙しい一週間でした。新しい種類の Amazon CloudFront インフラストラクチャ、 Amazon Simple Storage Service (Amazon S3) に保存されているデータをより効率的に分析する方法、および新しい生成 AI 機能を導入しました。 2月26日週のリリース 注目すべき内容はこちらです。 Amazon Bedrock – Mistral AI の Mixtral 8x7B および Mistral 7B ファンデーションモデルが Amazon Bedrock で一般利用可能になりました。詳細については、 Donnie の投稿 をご覧ください。ここでは、同僚の Mike により、 Mistral 7B と Mixtral 8x7B モデル についてより詳しく説明します。 Amazon Bedrock のナレッジベース – ハイブリッド検索のサポートにより 、検索で得た結果、特にキーワード検索結果の関連性を高めることができます。 AWS 機械学習ブログ 内のこの投稿にあるより多くの詳細と例をご覧ください。 Amazon CloudFront – インターネットサービスプロバイダー (ISP) およびモバイルネットワークオペレーター (MNO) のネットワーク内で、エンドユーザーに最も近い場所にデプロイされる新しいタイプの CloudFront インフラストラクチャである 埋め込み型 Point of Presence (POP) の利用が可能になったと発表しました。埋め込み型 POP は、大規模なライブストリーム動画、ビデオオンデマンド (VOD)、ゲームダウンロードなどのサービスを提供するためにカスタマイズされています。現在、CloudFront は世界 200 以上の都市に 600 以上の埋め込み型 POP を導入しています。 Amazon Kinesis Data Streams – ストリーム内のデータをリアルタイムで分析して視覚化できるように、 AWS マネジメントコンソールで SQL クエリをワンクリックで実行することを可能にしました 。 Amazon EventBridge – API 送信先が コンテンツタイプのヘッダーのカスタマイズ をサポートするようになりました。独自のコンテンツタイプを定義することで、 CloudEvents へのサポートなど、より多くの API 送信先 HTTP ターゲットを利用可能にすることができます。詳細については、 AWS Lambda のプリンシパルエンジニアである Nik によるこの X/Twitter スレッドを参照してください 。 Amazon MWAA – Amazon Managed Workflows for Apache Airflow (MWAA) で Apache Airflow バージョン 2.8 に向ける環境を作成できるようになりました 。詳細については、この AWS ビッグデータブログ投稿 をご覧ください。 Amazon CloudWatch Logs – IPv6 をサポートする CloudWatch Logs を使用すると 、IPv4 と IPv6 の両方をサポートするデュアルスタックネットワーク上で Amazon CloudWatch ロググループを実行することにより、ネットワークスタックを簡素化できます。 IPv6 をサポートする AWS サービス に関する詳細情報について、このドキュメント内で確認できます。 SQL Workbench for Amazon DynamoDB – このクライアント側アプリケーションで拡張可能な高性能データモデルを視覚化して構築する際に、 開発環境間でのテーブルのクローン作成 が可能になりました。この機能を使用すると、複数の開発環境で同じ状態の Amazon DynamoDB テーブルを使用して、コードを開発およびテストすることができます。 AWS Cloud Development Kit (AWS CDK) – 新しい AWS AppConfig レベル 2 (L2) コンストラクト は、機能フラグや動的設定データを含む AWS AppConfig リソースのプロビジョニングを簡素化します。 Amazon Location Service – iOS および Android プラットフォーム用の認証ライブラリを使用して 、 Amazon Location Service をモバイルアプリに簡単に統合できるようになりました。ライブラリは API キーと Amazon Cognito 認証をサポートしています。 Amazon SageMaker – Amazon S3 Express One Zone ストレージクラスを使用して、Amazon SageMaker モデルのトレーニングを加速し、トレーニングデータ、チェックポイント、およびモデルアウトプットの読み込み時間を短縮することができるようになりました 。S3 Express One Zone はパフォーマンスに重点を置くアプリケーションのために特別に設計されたもので、より速いクラウドオブジェクトストレージ、安定な一桁のミリ秒単位レベルのリクエスト遅延および高いスループットを提供します。 Amazon Data Firehose – CloudWatch Logs のメッセージ抽出 をサポートするようになりました。CloudWatch Logs レコードはネストされた JSON 構造を使用しており、各レコード内のメッセージはヘッダー情報に埋め込まれています。ヘッダー情報にフィルタを掛けて、埋め込まれたメッセージのみを送信先に配信することがより容易になり、その後の処理とストレージのコストを削減します。 Amazon OpenSearch – Terraform は今、Amazon OpenSearch Service の完全に管理されたデータインジェスト層である Amazon OpenSearch Ingestion のデプロイメントをサポートするようになりました 。これにより、ペタバイト規模のデータを取り込んで処理した後に、Amazon OpenSearch が管理するクラスターやサーバーレスコレクションでデータをインデックス化することが可能になります。詳細については、この AWS ビッグデータブログ投稿 をご覧ください。 AWS Mainframe Modernization – AWS Blu Age Runtime は AWS Fargate 上の Amazon ECS でのシームレスなデプロイが可能になり 、サーバーレスコンテナで近代化されたアプリケーションを実行できるようになりました。 AWS Local Zones – アトランタに新設された Local Zones は 、リアルタイムゲーム、ハイブリッド移行、メディアやエンターテインメントのコンテンツの作成、ライブビデオストリーミング、エンジニアリングシミュレーションなど、ミリ秒単位の低遅延が求められるユーズケースに向けるアプリケーションをサポートします。 AWS からの発表の完全なリストについては、 「AWS の最新情報」ページ をご覧ください。 その他の AWS のニュース 皆さんが興味を持ちそうな追加のプロジェクト、プログラム、ニュース項目をいくつか紹介します。 PartyRock Hackathon は今月終了ですが、 まだ参加してコードなしのアプリを作る時間があります! これは、新しい場所を訪れる際に何をすべきかを計画するのに役立つクイックアプリのスクリーンショットです。 Amazon Bedrock のナレッジベースを用いた創薬のための RAG の使用 – 生成 AI の非常に興味深い使用例です。 複雑なクエリを生成および自動修正し、さまざまなデータソースにクエリを実行する、堅牢なテキストから SQL へのソリューションを構築するための 完全なソリューションを紹介します。 AWS での .NET 8 サポート の素敵な概要です。これはプラットフォーム全体の .NET の最新長期サポート (LTS) バージョンです。 AWS WAF トラフィック概要ダッシュボードの紹介 – AWS WAF によって保護されたアプリケーションのセキュリティ態勢について、情報に基づいた意思決定を支援する新しいツールです。 Mountpoint for Amazon S3 を使用してハイパフォーマンスコンピューティング (HPC) デプロイの速度とコストを改善する方法に関するヒントをいくつか紹介します。 Mountpoint for Amazon S3 は、コンピューティングインスタンスに S3 バケットをマウントし、ローカルファイルシステムとしてアクセスするために使用できるオープンソースのファイルクライアントです。 私の同僚である Ricardo が、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、デモをハイライトするこの 週刊オープンソースニュースレター を執筆しています。 今後の AWS イベント AWS Summit シーズンが戻ってきていることを実感していたはずです! 最初のイベントはヨーロッパで、 パリ (4 月 3 日)、 アムステルダム (4 月 9 日)、 ロンドン (4 月 24 日) で参加できます。3 月 12 日に ブリュッセルで開催される AWS 公共部門シンポジウム では、公共部門の業界リーダーや AWS の専門家に会うことができます。 AWS Innovate は、インフラストラクチャとアプリケーションを設計、デプロイ、運用するための適切なスキルを身に付けるのに役立つオンラインイベントです。 アメリカ大陸向けの AWS Innovate Generative AI + Data Edition は 3 月 14 日に開始されます。これは、2 月に開催したアジア太平洋地域と日本、EMEA のイベントに続くものです。 世界中の AWS ユーザーグループ および AWS クラウドクラブ からのボランティアが主催する AWS コミュニティ re:Invent re:Cap イベントがまだいくつかあります。これらのイベントでは、 AWS re:Invent からの最新の発表について知ることができます。 こちらで、近日中に開催されるすべての対面およびバーチャルイベントを 閲覧することができます 。 今週のニュースは以上です。3月11日週に次回 Weekly Roundup もお楽しみに! – Danilo この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

2月26日週、 Mistral AI モデルが Amazon Bedrock に導入される予定であること を発表しました。その記事では、Mistral AI モデルがお客様にとって最適である可能性がある理由をいくつか詳しく説明しました。Mistral AI は、コストとパフォーマンスのバランス、高速な推論速度、透明性と信頼を提供し、幅広いユーザーによるアクセスが可能です。 3月1日、2 つの高性能 Mistral AI モデルである Mistral 7B と Mixtral 8x7B が Amazon Bedrock で使用可能になったことを発表します。Mistral AI は、 AI21 Labs 、 Anthropic 、 Cohere 、 Meta 、 Stability AI 、 Amazon などの他の大手 AI 企業に次ぐ、Amazon Bedrock で最先端のモデルを提供する 7 番目の基盤モデルプロバイダーです。この統合により、Amazon Bedrock で最適な高性能基盤モデルを柔軟に選択できるようになります。 Mistral 7B は、Mistral AI の最初の基盤モデルであり、自然なコーディング機能で英語のテキスト生成タスクをサポートします。低レイテンシーを実現するために最適化されており、サイズの割にメモリ要件は低く、スループットは大きいです。Mixtral 8x7B は、テキストの要約、質疑応答、テキストの分類、テキスト補完、コード生成に最適な、人気のある高品質の Sparse Mixture-of-Experts (MoE) モデルです。 Amazon Bedrock で Mistral AI モデルがどのように見えるのかを次に示します。 Mistral AI モデルの開始方法 Amazon Bedrock で Mistral AI モデルの使用を開始するには、まずモデルにアクセスする必要があります。Amazon Bedrock コンソールで、 [モデルアクセス] を選択してから、 [モデルアクセスを管理] を選択します。次に、Mistral AI モデルを選択し、 [モデルアクセスをリクエスト] を選択します。 選択した Mistral AI モデルにアクセスできるようになったら、 [プレイグラウンド] セクションの [チャット] または [テキスト] でプロンプトを使用してモデルをテストできます。 Mistral AI モデルをプログラムで操作する また、 AWS コマンドラインインターフェイス (CLI) と AWS Software Development Kit (SDK) で Amazon Bedrock API を使用してさまざまな呼び出しを実行することもできます。AWS SDK を使用して Amazon Bedrock Runtime API を操作する Python のサンプルコードを次に示します。 import boto3 import json bedrock = boto3.client(service_name="bedrock-runtime") prompt = "<s>[INST] INSERT YOUR PROMPT HERE [/INST]" body = json.dumps({ "prompt": prompt, "max_tokens": 512, "top_p": 0.8, "temperature": 0.5, }) modelId = "mistral.mistral-7b-instruct-v0:2" accept = "application/json" contentType = "application/json" response = bedrock.invoke_model( body=body, modelId=modelId, accept=accept, contentType=contentType ) print(json.loads(response.get('body').read())) Mistral AI モデルの動作 アプリケーションを AWS SDK と統合し、Amazon Bedrock を利用して Mistral AI モデルを呼び出すことで、さまざまなユースケースを実装する可能性を広げることができます。ここでは、サンプルプロンプトで Mistral AI モデルを使用する、私が個人的に気に入っているユースケースをいくつかご紹介します。その他の例については、Mistral AI ドキュメントページの「 プロンプト機能 」をご覧ください。 テキストの要約 – Mistral AI モデルは長い記事からでも要点を抽出できるため、重要なアイデアや核となるメッセージをすぐに把握できます。 You are a summarization system.In clear and concise language, provide three short summaries in bullet points of the following essay. # Essay: {insert essay text here} パーソナライゼーション – 言語の理解、推論、学習という AI の中核的な機能により、Mistral AI モデルはより人間らしい質のテキストを使用して回答をパーソナライズできます。Mistral AI モデルの精度、説明機能、多用途性により、個々のユーザーに合わせたコンテンツを提供できるため、パーソナライゼーションタスクに役立ちます。 You are a mortgage lender customer service bot, and your task is to create personalized email responses to address customer questions.Answer the customer's inquiry using the provided facts below.Ensure that your response is clear, concise, and directly addresses the customer's question.Address the customer in a friendly and professional manner.Sign the email with "Lender Customer Support." # Facts <INSERT FACTS AND INFORMATION HERE> # Email {insert customer email here} コード補完 – Mistral AI モデルは、自然言語とコード関連のタスクについて、非常に高い理解度を備えています。これは、コンピュータコードや通常の言語を使用する必要があるプロジェクトにとって不可欠です。Mistral AI モデルは、コードスニペットの生成、バグ修正の提案、既存のコードの最適化に役立ち、開発プロセスを加速します。 [INST] You are a code assistant.Your task is to generate a 5 valid JSON object based on the following properties: name: lastname: address: Just generate the JSON object without explanations: [/INST] 知っておくべきこと その他の情報をいくつかご紹介します。 利用可能なリージョン – Amazon Bedrock における Mistral AI の Mixtral 8x7B および Mistral 7B モデルは、米国西部 (オレゴン) リージョンでご利用いただけます。 Mistral 7B と Mixtral 8x7B の詳細 – Amazon Bedrock での Mistral AI モデルについてさらに詳しく知りたい場合は、私の同僚の Mike による「 Mistral AI – Winds of Change 」というタイトルの記事もぜひお読みください。 今すぐご利用いただけます Mistral AI モデルは現在、Amazon Bedrock でご利用いただけます。皆さんが構築するものを見るのが楽しみです。まずは、「 Mistral AI on Amazon Bedrock 」にアクセスしてください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

みなさんこんにちは！アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。 2024 年 2 月 29 日に AWS オンラインセミナー「 プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜 」を開催しました。 本イベントは、プラットフォームエンジニアリングの基本的な概要と現状について解説した上で、SRE や DevOps との関連性、どんな課題をどう解決するのか、実装するとなれば、AWS でどう実現するのかといった点についてご紹介させていただきました。400 名を超える多くの方々にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました！ アジェンダ AWS メンバーから、プラットフォームエンジニアリングに関する 3 つのセッションを 2 時間でお届けしました。本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！ チームとプラットフォームをクラウドネイティブな開発に最適化する (45 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Specialist Solutions Architect, Containers 林 政利 クラウドネイティブな開発では、アプリケーションとクラウドリソースの垣根はあいまいになり、開発チームと運用チームの役割も自ずと変化します。「運用チームがインフラストラクチャーを用意し、開発チームが作ったアプリケーションを載せる」という開発スタイルから、さまざまなクラウドの機能をネイティブに活用したクラウドネイティブ開発へと移行する組織にとって、「基盤 (プラットフォーム)」というものの考え方も大きく変わってくることになります。このセッションでは、プラットフォームエンジニアリングというアプローチを紹介し、クラウドネイティブな開発でどのようにチームと基盤を最適化するべきかご紹介します。 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-1-team_platform_cloudnative.pdf 動画: https://youtu.be/Bs2hTbWJveo ちがいからみる Platform Engineering – クラウドネイティブ化に伴って生じた新たなチームトポロジー (45 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Tech Training Specialist 山田 遼太 近年、急速なデジタル変革が進む中で、企業は IT インフラストラクチャの信頼性と効率性を確保するために新たなアプローチを模索しています。そこで、Site Reliability Engineering（SRE）とプラットフォームエンジニアリングが注目を集めています。本セッションでは、SRE とプラットフォームエンジニアリングの役割と相違について探究します。どちらも IT インフラストラクチャに関する技術を扱いますが、責任範囲、目的、チームトポロジー、コミュニケーションスタイルなどが異なります。これらの異なる側面に焦点を当てながら、それぞれの役割がどのように組織において共存し、相互補完的になり得るかについて議論します。さらに、組織がプラットフォームエンジニアリングを導入する際の潜在的な利点や課題、実践的なエンジニアリングにおいて活用できる具体的な手法やベストプラクティスについても提案します。これにより、お客さまは組織のニーズや目標に合わせて、SRE とプラットフォームエンジニアリングを効果的に組み合わせ、持続可能な IT インフラストラクチャを構築するための手法を理解することができます。 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-2-platformengineering_differences.pdf 動画: https://youtu.be/w6kDd5B4OSs Amazon ECS で実現するプラットフォームエンジニアリング (30 分) スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Solutions Architect 後藤 健汰 ビジネスの拡大やサービスの増加に伴う開発組織の急速な規模拡大により、組織には様々な課題が生じます。そのような状況下で、開発者体験や生産性を向上させ、ビジネス価値の創出を加速することを目的とした「プラットフォームエンジニアリング」というアプローチが、近年注目を集めています。本セッションでは、開発組織が拡大する中で様々な課題を抱えている、または将来的に直面する可能性があると考えられるお客様が「プラットフォームエンジニアリング」を導入していく上で、抑えておくべき考慮事項や Amazon ECS をはじめとしたプラットフォーム構築に活用できる技術についてご紹介いたします。 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-3-amazon_ecs_platformengineering.pdf 動画: https://youtu.be/u8KEQl1wIgU いただいた質問とその回答 セッション当日に頂いたご質問の中で、回答しきれなかったものをこの場で回答させていただきます。 Q. ストリームアラインドチームをプラットフォームエンジニアリングがサポートし負荷を軽減するゴールデンパスの例が IaC テンプレートの利用促進となる理解で正しいでしょか？ A. 正しいです。さらにいうと、テンプレートの利用促進だけではなく、ゴールデンパスのトレーニングや、アーキテクチャレビューもその一例になります。 Q. 受託開発では業務要件を組織内に持っておらず、これを整理し、かみ砕き、複数のコンポーネントを統合した時の結果を保証する必要があります。ストリームアラインドチーム型で構成する時には従来の SI 系開発と比較してこの分割統合の難易度がさらに上がると思うのですが、プラットフォームチームのような、ここをサポートする方法はあるのでしょうか。 A. 受託開発でプラットフォームエンジニアリングの難易度が上がる、というのはご認識の通りです。特に、アプリケーション実装の一部を受託開発して納品し、発注側で統合し、保守運用を他の会社に外注する、というような、ストリームが組織で細かく分断されているケースでプラットフォームエンジニアリングを導入することは現実的ではないでしょう。プラットフォームエンジニアリングは、DevOps の文化が下地にあるため、まずはストリームを「引き継ぐ」場面を最小化する必要があります。例えば、受託開発のスコープを技術的なコンポーネントを単位にするのではなく、ビジネスのユーザーストーリー単位とし、そのストーリーのストリーム、つまり開発から保守運用までを一貫して受注するようなビジネス構造が必要です。多くのストリームとストリームアラインドチームが並行して稼働している環境で、そのチームを支援するような疎結合なプラットフォームを構築できます。 Q. 分散型プラットフォームと中央集権型のプラットフォームはエンジニアの組織規模によってどちらが優れているとかありますでしょうか？ A. 「最小限のプラットフォームから始める」という観点からは、分散型のプラットフォームから検討するといいでしょう。チームの負荷やスケーラビリティが確保しやすくなります。そこから、エンジニアの組織規模によっては、すべてのチームで強制的に適用したいポリシーや開発手法もあるでしょう。このような部分に限って段階的に中央集権的なプラットフォームを導入していくことができます。例えば、AWS のアカウントは BLEA と AWS Control Tower で必要なポリシーが設定されたものを中央集権的に管理し、 アプリケーションのデプロイは CDK テンプレートを開発者に配布するという分散型のプラットフォームで運用するという構成も考えられます。 Q. プラットフォームチームは内製すべきでしょうか？内製するとしてプラットフォームチームはまずどういったメンバーで構成すべきですか？ A. プラットフォームチームは内製すべきです。これは、良いプラットフォームを作るためにサポート対象のストリームアラインドチームのフィードバックを受け続ける環境が必要だからです。一般的には、プラットフォームチームはクラウドインフラストラクチャーに詳しい運用チームのメンバーで構成されます。しかし、ストリームアラインドチームをサポートするには、ソフトウェア開発の経験が必要です。これは、CI/CD やソースコードの管理戦略、テスト戦略、アプリケーションモニタリングなどが含まれます。このような経験や知識を持つメンバーもあわせてプラットフォームチームを構成するといいでしょう。 Q. 中央集権型プラットフォームモデルと従来型の開発/運用分立モデルの明確な相違点は何でしょうか。（従来の「アプリケーション開発チーム」「運用チーム」が「ストリームアラインドチーム」と「プラットフォームチーム」に名前が変わっただけのようにも見えます） A. 明確な相違点は、チームの自律性です。中央集権型のプラットフォームモデルであっても、プラットフォームエンジニアリングの文化ではストリームアラインドチームは自律的に設計、開発、運用を行います。プラットフォームが使いやすいものであれば採用するし、そうでなければ採用しません。逆に、「プラットフォーム」を運用しているチームが、別チームの作ったアプリケーションを引き継いで運用している、というような状態であれば、従来の開発/運用分立モデルと同じだと言えるでしょう。 Q. プラットフォームチームが行うテンプレートのサポートを AmazonQ が代替できる場合、ストリームアラインドチームが直接 AmazonQ を利用する形態でプラットフォームエンジニアリングが成立しますでしょうか？ A. 成立します。しかし、Amazon Q が提案したテンプレートが本当に要件に合うものか判断できる知見がストリームアラインドチームには必要になります。もし、現時点でそうした知見に不安があるようであれば、プラットフォームチームはさらにレビューやトレーニングをストリームアラインドチームへ提供するというサポートが必要です。 Q. 中央集権型のプラットフォームの実現方法として k8s を利用したものが例として上がっていましたが、ECS を利用した場合の具体的なイメージを知りたいんですが何か良い資料はないでしょうか？ A. 本セミナーの「Amazon ECS で実現するプラットフォームエンジニアリング」のセッションで、ECS を前提にした具体的なイメージが紹介されておりますので、ぜひご参照ください Q. 分散型のプラットフォームでは、ストリームアラインドチームからプラットフォームへの実運用 IaC コードなどのフィードバックも GitHub などで管理する認識でよいでしょうか、それともサンプルコードのフィードバックだけを受けるのでしょうか A. これは、プラットフォームエンジニアリング導入のフェーズで変わる部分です。最初は、サンプルコードを提供して、そのフィードバックを受けます。このフェーズでは、プラットフォームチームはストリームアラインドチームと並走してサンプルコードを参考にしたアプリケーション開発、運用のフィードバックを受けることになるでしょう。そして、ストリームアラインドチームの運用が進んだ段階で、サンプルコードを汎用化し、GitHub で管理し、さらに広いストリームアラインドチームへ配布してフィードバックを受けるフェーズへ進みます。もちろん、すでに実運用されているシステムがあれば、サンプルコードを提供するフェーズをスキップして、その内容を直接汎用化することも考えられます。 Q. 弊社では中央集権型のプラットフォームレイヤーを設けており、AWS 上でインフラ構築をしておりますが、成果として構築されたインフラが開発チームのニーズを満たさず、結果として開発チームが調査しプラットフォームチームに修正を依頼しており、開発チームの負荷の増大や開発スケジュールの遅延の原因となっております。プラットフォームチームに「アプリを良く動かすためのインフラの構築」をさせるための方策等あればご教授いただけませんでしょうか。 A. プラットフォームエンジニアリングの観点からは、次に挙げる二点で開発チームのニーズを満たすことが考えられます。まず、「中央集権型のプラットフォーム」が何を提供するのか、というのを明確にします。そして、提供する機能がプラットフォームが開発チームの要件を満たさない部分は、分散型のプラットフォームの考え方を採用し、自律的に作業を行えるようにする、ということが重要です。プラットフォームエンジニアリングのベースにはチームの考え方があり、チームに自律性と必要な権限がなければ実践が難しいというのが実際のところです。また、プラットフォームはプロダクトとして開発する必要があり、例えば開発チームの KPI のような明確な品質の基準を設けるということも重要になるでしょう。 Q. 方法論を DevOps に変えていきたいという現場要求はありつつ、外的な要求、例えば認証規格 (ISO27017 ISMSクラウドセキュリティだとか) によりある程度手法の制約が出るケースがあると思います。社内は頑張って説得するにしても、対外的には(例えば監査機関に)何かしらロジカルに回答する必要があるわけですが、どんなアプローチを取っていったらいいのでしょうか。 A. 適切な回答のためには、準拠すべき要件の土台となる原理・原則や、その要求の背景を学び、解釈をアップデートしていく必要があります。具体的なアプローチとしては「 The Era Of DevSecOps ～AWSサービスによる DevOps とセキュリティのマリアージュ～ 」という発表の中でも触れられておりますので、ぜひご参照ください。 Q. 19 頁 The ROAD to SRE？ Devops でなくとも普通にやることやらないといけないことのように思えましたがどういう意図の説明でしたでしょうか？ 「 The ROAD to SRE 」は、SRE で取り組むべきことについて記述された Medium の記事を参考にお話しさせていただきました。SRE の実践を組織に導入する方法はいくつかありますが、どこから始めればいいか迷うことがあります。具体的なエリアを4 つ示すことで、SRE が具体的にどのエリアの信頼性に関する取り組みを行うのかについて説明させていただきました。 Q. ツーピザチームの自主的に機能するための権限というのは、例えばどのような権限になりますでしょうか? 予算とか、アーキテクチャ選択の自由等でしょうか? A. ツー・ピザ・チームが自律的に機能するためには、権限と環境の両方が揃っていることが重要です。権限については、ツー・ピザ・チームがお客様のために独立してイノベーションを起こすことができる権限が必要と考えています。従来型の組織構造では、上層部での意思決定によって方針が決まり、具体的なアクションを遂行することのみを求められるような場合があります。一方で、ツー・ピザ・チームは、お客さまに最高の価値を届けるために、チーム内で自ら決断しアクションを遂行します。ここには、技術選定に関わるものから、どのプロジェクトに注力するか、アイデアの創出から実行、継続的な業務改善から絶え間ない製品のイテレーションやイノベーションに至るまであらゆるものに対する権限が含まれます。もう一つの環境の観点では、範囲内での予算を利用できることや、サービスをエンドツーエンドで所有して実行するのに必要なリソース (エンジニアリング、テスト、製品とプログラムの管理、運用など) がチームに組み込まれていることなどイノベーションを起こす上で必要なあらゆるものが含まれています。ただし、自律性と無秩序は別物です。Amazon では無秩序にならないよう適切なレベルの監督体制を確立します。ここでは従来のように上層部がすべての意思決定で乗り越えなければならない障壁となるわけではありません。むしろ、障害を取り除くことをサポートします。Amazon において組織を監督するために用いられている仕組みの 1 つにナラティブと呼ばれる文書があります。Amazon では、新しいサービスのリリース前に運用上の準備状況を厳密にレビューし、サービスのアーキテクチャ、そのリリースの質と手順、および関連するインシデントやイベントの管理手順のさまざまな側面が適切に定められ、文書化するために詳細な確認を行うナラティブを用意しています。ツー・ピザ・チームは説明責任を果たすために、決められたナラティブを作成し提供しなければなりません。 Q. Platform というものがよくわからないです。内部の開発チームに所属している方から品質に不安があるという声があがっています。そういった品質的な部分は Platform Team にお願いして品質の向上基盤、テスト自動化などの API を platform として提供してもらうとかもできるのでしょうか？それらも局所的な要件になるのですか？ A. 特定の課題がプラットフォームによって提供されるべき課題かどうかというのは、組織全体が抱えている課題の状況によって異なります。多くの開発チーム（ストリームアラインドチーム）が抱えている共通の認知負荷であれば、プラットフォームチームにによって解決できるようなプロダクトを作成するチャンスと捉えられます。もしプラットフォームとして課題解決をする場合は、開発チームはプラットフォームチームに対して適切なフィードバックを提供する、機能要求を送るなどのコラボレーションをしながら、適切なプロダクトの開発をサポートすることが推奨されます。 Q. EmbeddedSRE の認知負荷がすごく大きくなるような気がしますがどうなのでしょうか？ A. Embedded SRE チームには、信頼性に関わる技術的に際立った専門性を有しているメンバーを集めます。また、チームにアサインされた場合も、アサインされたチームが抱えている信頼性に関する課題解決や、信頼性に関わる知識の移譲を行うため、サービス自体に関するドメイン知識が求められることはありません。 Q. AWS における two pizza teamとは、特定サービスに強い権限を持つ少数のサービスアラインドチームという理解で相違ないでしょうか？ A. はい。詳しくは、「 高いパフォーマンスを発揮する組織 – Amazon ピザ 2 枚チーム | AWS Executive Insights 」をご確認ください。 Q. プロトタイプエンジニアとプラットフォームエンジニアの違いはなんなのでしょうか？ A. 一般的にプロトタイプエンジニアは「特定の顧客のユースケースを実現するプロトタイプを開発し、技術的な実現性を確認する」ことを責務として持つロールです。それに対してプラットフォームエンジニアは、ストリームアラインドチームの認知負荷を軽減し開発生産性を高めることを目的とした「プラットフォーム」を開発・運用することを責務として持つロールになります。両方ともにストリームアラインドチームを支援しますが、異なる責務を持ったロールと言えます。 Q. プラットフォームチームは、一般的な組織としてどの部署（情シスのインフラチームとか。。）が担当するのが一般的なのでしょうか？また、兼務したりするのでしょうか？ A. 一般的には、プラットフォームを開発するケイパビリティを持った人材でプラットフォームチームを組成することが多いと考えています。兼務については開発組織の文化などにもよりますが、プラットフォームの開発においては、開発チームと積極的にコラボレーションをする必要があるので、開発チームに対して一定のコミットを求める必要があります。 Q. 責務の分担はプロジェクト開始タイミングで決めた方が良いと思いますが、プロジェクト開始前に開発と運用のマネージャー層だけで決めた方が良いのでしょうか。それとも開始直後にメンバーにヒアリングして現場の意見も含めた方が良いのでしょうか。トップダウン、ボトムアップのどちらの方が成功しやすいのか、実績などからお分かりでしたらご教示ください。 A. 現場の意見を踏まえた上で、最終的にはマネージャー層の合意が必要だと考えています。開発チームの教育などにも一定のコストがかかる可能性があるため、現場のメンバーだけでは決められず、また責務分担の現実的な落とし所を決める際には現場のメンバーの意見が重要になるためです。 Q. セッション３のゴールデンパスの実装において、IaC テンプレートの抽象化のレベルをどう決定していくかに悩んでいます。決定の仕方や、例などを教えていただくことはできるでしょうか。 A. 様々な要因がありますが、開発チームが持っている技術的なナレッジを考慮する、というのは大切です。また「どの程度抽象化するべきか」についてユーザーにヒアリングをしながら決めていく、というのも有効な方法になります。もし抽象化の必要がなくカスタマイズ性を重視するのであれば、一切抽象化していない IaC コードをテンプレートとして提供するというのも、選択肢の一つになりえます。 Q. プラットフォームチームの運用負荷を下げる事が容易になる AWS サービス一覧はありますでしょうか？ A. プラットフォームの構成によって、様々な AWS サービスが活用できます。例えば、プラットフォームチームによる AWS アカウントの管理や統制を支援するサービスとして AWS Control Tower や AWS Control Tower Account Factory といったサービスがあります。 Q. 開発チームとプラットフォームチームがスキルや文化の違い、コミュニケーション不足などで衝突している場面を多くの現場で見かけますが、プロジェクトが成功するためにプラットフォームチームが心がけるポイントなどはございますか？ A. 開発チームへのスキルトランスファーや文化の啓蒙も、プラットフォームチームの責務のひとつです。具体的には、ユーザーのニーズに対応する適切なドキュメントを整備するであったり、開発チーム向けの勉強会やデモを提供するといった、Platform as a Product の思想に基いた活動が大切です。 Q. TVPという考え方がありました。これであれば、あまり深かけずにできることから実現できそうですが、プラットフォームエンジニアリングを選ばないほうが良いケースってどういうものがありますか？ A. プラットフォームエンジニアリングのアプローチを適用すべきかどうかは、現在の開発組織が抱える課題について明らかにした上で、その課題を改善するためにプラットフォームエンジニアリングが必要かを明らかにする必要があります。 こちらのブログ に開発組織の運用モデルの評価について記載がありますので、ぜひご参照ください。 Q. 非常にためになるセミナーを開催頂きありがとうございます。以下、ご教授願います。複数のシステムを運用しており、各システムはそれぞれアカウント（システムごと、本番、開発ごと）が異なっている状況下です。AWS 上でプラットフォーム（例えば CICD 機能など）を提供する場合にこのようなプラットフォームは 1 つのアカウントに集約して各システムとクロスアカウントで連携するのが望ましいのか、もしくは各アカウントに部品を提供していく形で連携するのが望ましいのか。指標や考え方があればご教授頂きたい。 A. ひとつの考え方として、提供する「部品」の責務を持つのはどのチームか？によって決定するという考え方があります。もし CI/CD パイプラインの責務を開発チームに持たせるのであれば、各 AWS アカウントに配置した方が、トラブルシュート時の確認などが容易に実現できます。 おわりに 本セミナーにご参加いただいた皆様、改めてありがとうございました。今後も様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。

ノーベル賞受賞者のダニエル・カーネマンによる世界的なベストセラー「ファスト & スロー あなたの意思はどのように決まるか?」によると、人々は直感的もしくは論理的に意思決定を行います。直感は迅速な意思決定につながり、合理的思考は意思決定を遅らせます。組織においては、その逆です。直感は長い意思決定プロセスにつながり、データや事実に基づく意思決定はプロセスの短縮につながります。 直感ドリブン ( 訳註 : データドリブンとは対照的に、意思決定が誰かの直感に基づいていること ) のカルチャーでは、他人は誰かの証明不能な直感に従うことになります。意見がぶつかり合い、最終的に勝つのは、最も素晴らしいストーリーを語れる人か、最も給料が高い人です。データドリブンの組織は通常、より少ない議論でより高い成功確率の意思決定を、より迅速に行います。 しかし、データドリブンのカルチャーを採用することは容易ではありません。確立された行動を変えなければならず、意思決定に必要なデータはしばしば入手できず、正しく解釈できません。 「意見」を「疑問と実験」に変える 経験や直感、信念に基づく自己主張は、議論や意思決定プロセスを開始するのに役立つ重要な資質です。直感ドリブンの組織では、人々は、意見から解決策へとすぐに飛躍します。意見はしばしば感嘆符 ( ! ) 付きで表現され、別の感嘆符 ( ! ) 付きの意見が重ねられます。 データドリブンの組織では、意見の最後に疑問符 ( ? ) が付き、「試してみよう」という返答を引き出します。意見は疑問につながり、それが仮説となって小規模に試行され、検証されます。あらゆる観点と結果を比較検討した経験のある人々は、データと実験の結果に基づいて意思決定を行います。 意思決定プロセスを導くのは直感ではなく、対象を絞った実験からのデータです。 「無作為なデータ保存」から、「意図的なインサイトの生成」へと変える データドリブンのカルチャーを取り入れたい組織はしばしば、データがない、データが多すぎる、または意味のないデータを持っていることに気づきます。これは通常、データが無計画で保存されているためです。データウェアハウスとデータレイクはフリーマーケットになり、場合によっては貴重なものを見つけることができますが、ほとんどのアイテムは役に立たず、コストに見合う価値もありません。 データドリブンの組織は、特定の課題に特化したデータを生成します。彼らは意見を裏付けるための実験を定義して実施し、必要となる正確なデータとインサイトを生み出します。質問、意味、構文に応じて、さまざまなテクノロジーを使用してデータを保存、処理、分析、視覚化します。データは特定の明示的な目的で収集され ( 目的制限 ) 、処理される理由から必要なものに限定されるため ( データ最小化 ) 、データ保護にも役立ちます。 AWS は、エンドツーエンドのデータ戦略の構築に役立つテクノロジーを提供しています。 (データを使って組織を改革する方法の詳細については、 AWS for Data をご覧ください。) 「ストーリーの語り聞かせ」から「データリテラシー」へ変える 直感ドリブンの組織では、無数のパワーポイントスライドを使用してストーリーを伝えることが不可欠なスキルとなり、意思決定会議というよりも、サーカスのショーになってしまうことがよくあります。データと統計は使われていますが、それは「ストーリー」を裏付けるためだけに使われています。これらの統計は文脈から外れていることが多く、特にフォーキャストは統計的に有意ではありません。 多くの組織では、従業員は合計と平均を理解しています。しかし、彼らは中央値、標準偏差、パーセンタイル、またはコホートを理解していません。データを適切に生成、準備、特に視覚化する方法を知りません。組織によっては、ほぼ毎年、より新しく、より便利で、よりカラフルなビジネスインテリジェンスツールを導入しているのに、ツールの使い方は言うまでもなく、基本的なデータリテラシー ( 訳註 : データを適切に読み、分析し、伝える能力 ) について従業員にトレーニングすることを忘れています。 一方、データドリブン組織では、ストーリーの語り聞かせは意図的に制限され、データに基づく推論が優先されます。たとえば、AWS では、社内の意思決定の基礎として、プレゼンテーションの代わりにドキュメントを使用しています。 これにより、誰もが意思決定者になることができます。お客様のことを念頭に置いて、より迅速に意思決定が下されます。 Matthias Patzak Matthias は AWS ソリューションアーキテクチャのプリンシパルアドバイザーを務めた後、2023 年初頭にエンタープライズストラテジストチームに加わりました。この役職では、マティアスは経営陣と協力して、クラウドがイノベーションのスピードやITの効率を高め、自社のテクノロジーが生み出すビジネス価値を高めるのにどのように役立つかについて、人、プロセス、テクノロジーの観点から検討しています。AWS に入社する前は、マティアスは AutoScout24 で IT 担当副社長を務め、Home Shopping Europe でマネージングディレクターを務めていました。両社とも、リーン・アジャイルのオペレーションモデルを大規模に導入し、クラウドトランスフォーメーションを成功させた結果、納期の短縮、ビジネス価値の向上、企業価値の向上を実現しました。 この記事はアマゾンウェブサービスジャパンの大塚信男が翻訳を担当しました。（オリジナルは こちら ）

これまでの年月を経て、ユーザーが検索エンジンに期待するものは進化してきました。ほとんどのユーザーにとって、迅速に文字通りに関連性の高い結果を返すだけでは、もはや十分とはいえません。今では、ユーザーは意味的理解を通じてさらに関連性の高い結果を取得したり、メタデータのテキスト検索ではなく画像の視覚的類似性を通じて検索することを可能にする方法を求めています。 Amazon OpenSearch Service には、検索エクスペリエンスを強化できる多くの機能が含まれています。2023 年にそのツールキットに追加した OpenSearch Service の機能と拡張についてうれしく思っています。 2023 年は、人工知能 (AI) と機械学習 (ML) の分野で急速なイノベーションがあった年であり、検索はその進歩の大きな受益者となりました。2023年を通じて、Amazon OpenSearch Service は、アプリケーションの書き換えやカスタムオーケストレーションの構築を行うことなく、最新の AI/ML テクノロジーを利用して既存の検索エクスペリエンスを改善および拡張できるよう、検索チームをサポートする投資を行ってきました。これにより、迅速な開発、反復、製品化が可能になります。 これらの投資には、新しい検索メソッドの導入と、利用可能なメソッドの実装を簡素化する機能が含まれています。本記事では、これらの機能を振り返っていきます。 背景: レキシカル検索とセマンティック検索 まず始めに、レキシカル検索とセマンティック検索の違いを確認しておきましょう。 レキシカル検索 レキシカル検索では、検索エンジンが検索クエリの単語とドキュメントの単語を比較し、単語と単語が一致するかどうかを照合します。 ユーザーが入力した単語を含むアイテムのみがクエリと一致します。BM25 のような用語頻度モデルに基づく従来のレキシカル検索は、広く使用されており、多くの検索アプリケーションでは効果的です。 しかし、レキシカル検索技術は、ユーザーのクエリに含まれる単語を超えて進むことが困難であり、その結果、高い関連性を持つ潜在的な結果が常に返されているとは限りません。 セマンティック検索 セマンティック検索では、検索エンジンは ML モデルを使用して、ソースドキュメントのテキストやその他のメディア(画像や動画など)を高次元のベクトル空間内の密ベクトル (dense vector) としてエンコードします。これはテキストをベクトル空間に埋め込むことから、「埋め込み」とも呼ばれます。同様にクエリもベクトルとしエンコードし、次に距離メトリックを使用して多次元空間内の近傍ベクトルから一致するものを探索します。近傍ベクトルを探索するアルゴリズムは k 最近傍 (k-NN) と呼ばれます。セマンティック検索は個々のクエリ用語とのマッチングを行いません。ベクトル空間内でクエリのベクトル埋め込みに近いベクトル埋め込みを持つドキュメントを見つけます。そのため、クエリに含まれる単語のいずれも含まない場合でも、クエリと意味的に類似した関連性の高いアイテムを返すことができます。 OpenSearch は数年にわたりベクトル類似性検索 (k-NN および Approximate k-NN)を提供してきました。この取り組みは、本機能を採用した顧客にとって貴重なものとなりました。 しかし、k-NN の恩恵を受ける機会のあるすべての顧客が本機能を採用したわけではありません。その理由は、採用にあたり、相当なエンジニアリング努力とリソースが必要であるためです。 2023年のリリース: 基本事項 2023 年に、OpenSearch Service でいくつかの機能と改善がリリースされました。これには、検索機能の継続的な強化のための基本的な構成要素である新機能が含まれています。 OpenSearch Compare Search Results ツール Compare Search Results は、OpenSearch Service バージョン 2.11 より一般提供されている、OpenSearch Dashboards 上で 2 つのランキング技術の検索結果を並べて比較できるツールです。本ツールにより、あるクエリが別のクエリよりも良い結果を生み出すか判断できます。ML アシステッドモデルによって動作する最新の検索手法を試したいユーザーにとって、検索結果の比較機能は欠かせません。また、自社のコーパスに対して、各手法のメリットを理解するために、レキシカル検索、セマンティック検索、ハイブリッド検索技術を比較したり、フィールド重み付けやステミングや、レンマ化の戦略のような調整を比較することもできます。 次のスクリーンショットは、Compare Search Results ツールの使用例を示しています。 セマンティック検索およびクロスモーダル検索の詳細や、Compare Search Results ツールのデモを試すには、 Amazon OpenSearch Service ベクトルエンジンを使用したセマンティック検索の試行 を参照してください。 Search pipelines 検索の実践者は、検索クエリと結果を強化する新しい方法を導入しようとしています。OpenSearch Service バージョン 2.9 から一般提供されている Search pipelines を使用すると、アプリケーションソフトウェアを複雑にすることなく、検索クエリと結果の処理をモジュール化された処理ステップの組み合わせで構築できます。フィルタなどの関数のプロセッサを統合し、新しく格納されたドキュメントに対してスクリプトを実行する機能を追加することで、検索アプリケーションの精度と効率を高め、カスタム開発の必要性を減らすことができます。 検索パイプラインには、filter_query、rename_field、script request の3つの組み込みプロセッサに加えて、独自のプロセッサを構築したい開発者向けの新しい開発者中心の API が組み込まれています。OpenSearch は、今後のリリースでこの機能をさらに拡張するために、追加の組み込みプロセッサを継続的に追加していきます。 次の図は、検索パイプラインのアーキテクチャを示しています。 Byte-sized vectors in Lucene これまで、OpenSearch の k-NN プラグインは、ベクトル要素が 4 バイトを占有する float 型のベクトルのインデックス作成とクエリをサポートしてきました。これはメモリとストレージの両面でコストがかかる場合があります。特に大規模なユースケースでは顕著です。 OpenSearch Service バージョン 2.9 から利用可能な新しい byte 型のベクトルを使用することで、メモリ必要量を 4 分の 1 に削減し、クオリティ(再現率)の大きな低下なく検索レイテンシを大幅に短縮できます。 詳細は、 OpenSearch のバイト量子化ベクトル をご参照ください。 新しい言語アナライザのサポート OpenSearch Service は以前より、IK (中国語)、Kuromoji (日本語)、Seunjeon (韓国語)など、複数の言語アナライザープラグインをサポートしていました。新たに、Nori(韓国語)、Sudachi (日本語)、Pinyin (中国語)、STConvert Analysis (中国語)のサポートを追加しました。これらの新しいプラグインは、TXT-DICTIONARY パッケージタイプに加えて、ZIP-PLUGIN という新しいパッケージタイプとして利用できます。OpenSearch Service コンソールの [パッケージ] ページや、AssociatePackage API を使用することでこれらのプラグインをクラスターに関連付けられます。 2023年のリリース: 操作性の向上 OpenSearch Service は、2023年に主要な検索機能内の使いやすさを向上させる改善も行いました。 Neural search によるセマンティック検索 これまで、セマンティック検索を実装するには、テキスト埋め込みモデルを検索とインジェストに統合するためのミドルウェアをアプリケーションが担当し、コーパスのエンコードをオーケストレーションし、クエリ時に k-NN 検索を使用する必要がありました。 OpenSearch Service はバージョン 2.9 で Neural search を導入し、開発者が大幅に軽減された定型作業なしにセマンティック検索アプリケーションを構築および運用できるようにしました。セマンティック検索では、テキストクエリからベクトルを生成し k-NN クエリを呼び出すため、 アプリケーションでドキュメントやクエリのベクトル化を行う必要がありません。 Neural search 機能によるセマンティック検索は、ドキュメントやその他のメディアをベクトル埋め込みに変換し、テキストとそのベクトル埋め込みの両方をベクトルインデックスに格納します。 検索時にニューラルクエリを使用すると、Neural search はクエリテキストをベクトル埋め込みに変換し、ベクトル検索を使用してクエリとドキュメントの埋め込みを比較し、最も近い結果を返します。 この機能は OpenSearch Service バージョン 2.4 で当初実験的にリリースされ、バージョン 2.9 で一般提供されるようになりました。 AI/ML コネクタによる AI パワー検索機能の実現 OpenSearch Service 2.9 より、Neural search のような機能を実現するために、AWS の AI と ML サービスやサードパーティの代替サービスとの接続が可能な、すぐに利用できる AI コネクタを提供しました。 たとえば、本番環境でモデルを適切に管理するための包括的な機能を提供する Amazon SageMaker 上にホストされた外部の ML モデルに接続できます。 フルマネージドな体験を通じて最新のファンデーションモデルを使用したい場合は、マルチモーダル検索のようなユースケースを実現するために Amazon Bedrock のコネクタを使用できます。 当初のリリースには Cohere Embed へのコネクタが含まれており、SageMaker と Amazon Bedrock を通じて、さらに多くのサードパーティのオプションにアクセスできます。 これらの統合の一部は、 OpenSearch Service コンソールの統合 (次のスクリーンショットを参照)を介してドメインで構成でき、SageMaker へのモデルの自動デプロイも可能です。 統合モデルは OpenSearch Service ドメインにカタログ化されるため、チームは統合され利用可能な様々なモデルを発見できます。モデルとコネクタのリソースについて細かいセキュリティ制御を有効にするオプションがあり、モデルとコネクタレベルのアクセスを管理できます。 オープンなエコシステムを育成するために、パートナーがAIコネクタを簡単に構築および公開できるフレームワークを作成しました。テクノロジープロバイダーは、OpenSearch と自社サービス間のセキュアな RESTful 通信を記述したJSONドキュメントである ブループリント を簡単に作成できます。テクノロジーパートナーはコミュニティサイトで自社のコネクタを公開でき、セルフマネージドクラスタや OpenSearch Service で、これらのAIコネクタをすぐに利用できます。各コネクタのブループリントは、 ML Commons GitHubリポジトリ で参照できます。 スコアの組み合わせによってサポートされるハイブリッド検索 Neural search のためのベクトル埋め込みや自然言語処理のための大規模言語モデル (LLM) などのセマンティック技術は、検索を革新し、手動の同義語リスト管理や微調整の必要性を減らしました。 一方で、テキストベース(レキシカル)検索は、部品番号やブランド名などの重要なケースでセマンティック検索よりも高いパフォーマンスを発揮します。ハイブリッド検索は2つの方法を組み合わせたもので、BM25単体と比較して14%高い検索の適合率(NDCG@10で測定 – ランキング品質の尺度)を実現するため、ユーザーは両方の長所を活かすためにハイブリッド検索を利用したいと考えています。スコアの正確性とパフォーマンスの詳細なベンチマークについては、 OpenSearch 2.10 で一般公開されたハイブリッド検索による検索の適合率向上 を参照してください。 これまで、各メソッドの関連性スケールの違いから、これらを組み合わせることは困難でした。以前はハイブリッドアプローチを実装するために、複数のクエリを個別に実行し、スコアの正規化と結合を OpenSearch の外で行う必要がありました。OpenSearch Service 2.11 で導入された新しい ハイブリッドスコアの組み合わせと正規化 クエリタイプを使用することで、OpenSearch が 1 つのクエリ内でスコアの正規化と結合を処理できるようになりました。これによりハイブリッド検索の実装が容易になり、検索の関連性を向上させるより効率的な方法が実現できました。 新しい検索方法 最後に、OpenSearch Service に追加された新しい検索メソッドを紹介します。 Neural sparse search OpenSearch Service 2.11 では、 Neural sparse search が導入されました。これは、従来の用語ベースのインデックスとよく似た新しい種類のスパース埋め込みメソッドですが、低頻度の単語とフレーズがより適切に表現されています。スパースセマンティック検索は、トランスフォーマーモデル(BERT など)を使用して、語彙のミスマッチ問題をスケーラブルな方法で解決する情報豊富な埋め込みを構築します。これにより、レキシカル検索と同様の計算コストとレイテンシを発揮できます。OpenSearch におけるこの新しい Sparse search 機能は、それぞれ異なる利点を持つ 2 つのモードを提供します。ドキュメントのみのモードと、バイエンコーダーモードです。ドキュメントのみのモードは、BM25 検索に匹敵する低レイテンシーなパフォーマンスを発揮できますが、密な方法と比較して高度な構文の制限があります。バイエンコーダーモードは、より高いレイテンシーで実行しながらも、検索の関連性を最大化できます。このアップデートにより、パフォーマンス、精度、コストの要件に最適なメソッドを選択できるようになりました。 マルチモーダル検索 OpenSearch Service 2.11 では、Neural search を使用したテキストと画像のマルチモーダル検索が導入されました。この機能により、製品カタログのアイテム(製品画像と説明文)のような画像とテキストのペアを、視覚的および意味的な類似性に基づいて検索できるようになります。これにより、より適切な結果を提供できる新しい検索エクスペリエンスが可能になります。例えば、「白いブラウス」で検索することで、製品タイトルが「クリーム色のシャツ」であっても、その説明に一致する画像の製品を検索できます。このエクスペリエンスを実現している機械学習モデルは、意味と視覚的特徴を関連付けることができます。画像で検索して視覚的に類似した製品を検索したり、テキストと画像の両方で検索して、特定の製品カタログアイテムに最も類似した製品を見つけることもできます。 アプリケーションにこれらの機能を組み込むことで、カスタムミドルウェアを構築することなく、マルチモーダルモデルに直接接続し、マルチモーダル検索クエリを実行できるようになりました。Amazon Titan Multimodal Embeddings モデルは、この方法をサポートするために OpenSearch Service と統合できます。マルチモーダルセマンティック検索を始める方法のガイダンスについては、 マルチモーダル検索 を参照してください。また、今後のリリースでさらに入力タイプが追加されることをご期待ください。また、 テキストと画像の クロスモーダル検索のデモ を試すこともできます。これは、テキストの説明を使用して画像を検索する方法を示しています。 まとめ OpenSearch Service は、検索アプリケーションを構築するためのさまざまなツールを提供していますが、最適な実装は、コーパスやビジネスニーズ、目標によって異なります。検索の実践者の方には、ユースケースに適したものを見つけるために、 利用可能な検索メソッド のテストを開始することをおすすめします。2024 年以降も、OpenSearch の検索実践者が最新・最高の検索テクノロジーを手元で利用できるよう、速いペースでの検索イノベーションが続くことが期待されます。 著者について Dagney Braun は、Amazon Web Services の OpenSearch チームのプロダクト シニア マネージャーです。 OpenSearch の使いやすさを向上させ、すべてのお客様のユースケースをより良くサポートするためのツールを拡張することに熱心です。 Stavros Macrakis は、Amazon Web Services の OpenSearch プロジェクトのシニアテクニカルプロダクトマネージャーです。検索結果の品質を向上させるツールを顧客に提供することに熱心です。 Dylan Tong は、Amazon Web Services のシニアプロダクトマネージャーです。 OpenSearch のベクトルデータベース機能を含む AI と機械学習 (ML) に関する OpenSearch の製品イニシアチブを率いています。Dylan は、データベース、アナリティクス、AI/ML ドメインの製品とソリューションの作成において、顧客と直接働く経験を数十年にわたって積んでいます。Dylan はコーネル大学でコンピュータサイエンスの学士号と修士号を持っています。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文は こちら です。