Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレスの時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析できます。 様々な業界のお客様 が Amazon Timestream を採用して、重要なビジネスアプリケーションを監視し、モノのインターネット (IoT) を含むアプリケーション、ウェブサイト、デバイスにわたる数百万のリアルタイムイベントを分析し、リアルタイムの洞察を導き出しています。 Timestream は、基盤となるインフラストラクチャの管理が不要で、ワークロードの要求に合わせて自動的に拡張するため、お客様はアプリケーション開発に集中する事が出来ます。 Amazon Timestream for LiveAnalytics は、お客様からのフィードバックに応える形で、時系列データをクエリ時にコスト効率が高く、金額が予測可能となるように設計された新しい価格モデルを導入しました。以前のクエリの価格モデルは、スキャンされるデータ量に基づいて課金され、クエリ毎に最低 10 MB でしたが、クエリが数 KB 程度の比較的小さい時系列データをスキャンすることが多いユースケースでは、高額となる場合がありました。さらに、クエリへの課金に上限を設定することも困難でした。これらの懸念に対処するために、クエリによってスキャンされたデータ量ではなく、使用されたコンピューティングリソースに基づいて料金を請求する 新しい料金モデル を導入しました。 Timestream Computing Unit (TCUs) に基づくこの新しい価格モデルにより、実際に使用されるリソースに応じてコストが調整され、クエリに使用するコンピューティングリソースの最大数を設定できるため、予算の順守が容易になります。 本投稿では、TCU の概要、TCU を使用したコスト管理、および最適なコストパフォーマンスを実現するためのワークロードに必要な TCU を見積もる方法について説明します。 Timestream Compute Units (TCU) TCU は、Timestream for LiveAnalytics のクエリに割り当てられるコンピューティングの容量です。各 TCU は 4 つの vCPU と 16 GB のメモリで構成されます。時系列データをクエリすると、Timestream サービスは主にクエリ (リアルタイムクエリと分析クエリ) の複雑さと、処理されるデータ量に基づき、必要な TCU の数を決定します。各コンピューティングユニットは同時に複数のクエリを実行するため、使用中の TCU で全クエリを処理できるかどうか、または追加のコンピューティングユニットが必要かどうかを評価し、必要に応じて、コンピューティングユニットを拡張します。TCU の数とその使用期間によって関連コストが決まり、クエリワークロードの管理が透過的かつコスト効率よく行われます。 コスト管理 TCU の利点の 1 つは、クエリコストを制御し、より効率的に管理できることです。 MaxQueryTCU は、AWS リージョン毎、アカウント毎に 設定 できますが、この設定をすることで、Timestream はクエリワークロードに対してMaxQueryTCU までスケールされるように制限することができます。 TCU の最大制限を設定することで、ワークロードのコスト上限を設定できるため、予算内に収める事が容易になります。 コンピューティングユニットの最大数は 4 の倍数に設定できます。料金は、使用したコンピューティングリソースに対してのみ発生します。つまり、最大 TCU を 128 に設定しても、一貫して 8 TCU のみを使用する場合は、 8 つの TCU を使用した課金のみが発生します。従量課金制の料金設定と使用制限の構成により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。Timestream を初めて利用する場合、各 AWS アカウントのデフォルトの MaxQueryTCU 制限は 200 になります。 MaxQueryTCU の設定は UpdateAccountSettings API を使用するか、 AWS マネジメントコンソール から行います。また、TCU を事前に見積もる方法については、本投稿の後半で詳しく説明します。 Timestream コンソールの 管理者ダッシュボード で、 管理者設定を設定 を選択します。 最大クエリ TCU に希望の値を設定し、 設定を保存 します。 現在、使用中のアカウントがクエリによってスキャンされたデータ量に対して請求が行われており、TCU にオプトインするか選択できる場合は、追加のポップアップが表示されます。 尚、最大クエリ TCU を削減する際、使用状況によっては有効になるまでに最大 24 時間かかる場合があります。また、クエリが実際に消費した TCU に対してのみ料金が請求される為、最大クエリ TCU 制限を高くしても、それらの TCU がワークロードで使用されない限り、コストには影響しません。 TCU による請求 TCU を使用すると、最低 30 秒間、使用したコンピューティングリソースに対して 1 秒毎に料金が請求されます。これらのコンピューティングユニットの使用単位は TCU 時間です。アプリケーションが Timestream にクエリを送信すると、Timestream サービスは使用中のコンピューティングユニットでリクエストを処理できるかどうかを確認します。処理出来ない場合、サービスはスケールアップして、クエリを処理するために追加のコンピューティングユニットを割り当てます。クエリの実行後、サービスは追加のクエリを最大 10 秒間待機します。この期間内に追加のクエリがない場合は、使用中のコンピューティングユニットの数をスケールダウンして、リソースを最適化し、コストを最小限に抑えます。 実際の例を使って説明しましょう。まず、アプリケーションに 1 分のうち 40 秒の間、レイテンシが 1 秒未満のクエリを含むクエリパターンがあると仮定します。アプリケーションは、1 分の開始時刻 t1 秒から t40 秒にクエリを Timestream に送信します。 コンピューティングユニットには、最低 30 秒ごとに料金が請求されます。Timestream サービスは、最小時間(30 秒)が経過し、最大 10 秒間クエリがない場合に、コンピューティング ユニットをスケールダウンします。サービスが t1 でクエリ用に 4 つの TCU を割り当て、後続のすべてのクエリが同じ 4 つの TCU で処理されると想定します。 4 つの TCU 使用量のうち 50 秒 (=0.0138889 TCU 時間)、即ち、4 * 0.01388 TCU 時間 = 0.05552 TCU 時間に対して請求されます。このパターンが 1 日 8 時間、毎分 (t1 ～ t60) 繰り返されると仮定すると、消費される合計 TCU 時間は、1 日あたり 0.05552 TCU 時間 * 60 分 * 8 時間 = 26.6496 TCU 時間となります。 TCU 時間を取得したら、目的のリージョンごとのクエリ料金を確認する事で料金を計算できます。 請求をより深く理解するために、さらにいくつかの例を見てみましょう。 ワークロードが 3 時間で 20 個の TCU を使用する場合、 60 TCU 時間 (20 TCU x 3 時間) に対して請求されます。 ワークロードが 30 分間に 12 TCU を使用し、次の 30 分間に 20 TCU を使用します。この場合、16 TCU 時間に対して請求されます (12 TCU x 0.5 時間 + 20 TCU x 0.5 時間)。 TCU の推定 Timestream for LiveAnalytics は、容量とパフォーマンスを調整するために自動的にスケーリングされるため、基盤となるインフラストラクチャの管理や容量のプロビジョニングは必要ありません。データの取り込み、ストレージ、クエリを独立して拡張できる 完全に分離されたアーキテクチャ を特徴としており、アプリケーションのニーズに合わせて事実上無限の拡張性を提供できます。 必要なコンピューティングユニットの数は、クエリの同時実行性、データモデル、クエリによってスキャンされるデータ量などのワークロードの特性によって決まります。処理可能なクエリの数を見積もるために、Timestream for LiveAnalytics でデータが収集および分析され、Grafana を通じて視覚化されるインフラストラクチャ監視のユースケースをシミュレートしました。現実世界のシナリオと同様に、複数のユーザーがメトリクスを監視する 2 つの一般的な可観測性クエリパターンをシミュレートし、ユーザーを 1 から 21 に増やしました。次に、MaxQueryTCU 設定 (4 および 8) を変更して、ユーザーの増加に応じて処理されるクエリの量とそれに対応する待ち時間を監視しました。 ホストの最新のメモリ使用率 ( lastpoint-query.ipynb ) を取得するパターン、及び、過去 10 分間の CPU 使用率をビニングする ( single-groupby-orderby.ipynb ) クエリパターンについて、4 および 8 TCU でクエリボリュームとレイテンシーメトリクスを測定しました。 これらのワークロードでは、サービスにクエリを発行する 1 人のユーザーから開始し、同時ユーザーの数を 21 人までスケールします。テストは、ユーザー構成毎に 1 分間実行され、対応するレイテンシー (p50、p90、p99)、 1 分あたりのクエリ数、およびスロットリング数 (もしあれば) が観察されます。詳細については、 README.md を参照してください。 最初のシミュレーションでは、MaxQueryTCU を 4 に設定し、 次のクエリ を実行します。これにより、特定のホストの最新のメモリ使用率が取得されます。 select memory from "devops"."sample_devops" where time > ago(10m) and hostname='host1' order by time desc limit 1 次のグラフは、レイテンシーのパーセンタイル (秒)、1 分あたりのクエリ数、およびスロットリング数とユーザー数の関係を示しています。 最初は 1 人のユーザーから始めて、時系列データにアクセスするユーザーの数を増やし続けます。わずか 4 つの TCU で、Timestream サービスは 1 分あたり 4,560 件のクエリ、つまり 1 秒あたり約 76 クエリ (QPS) を処理し、p99 レイテンシーは 160 ミリ秒未満でした。 Grafana ユーザーの数が増えると、レイテンシーが増加し、それによって 1 分あたりのクエリ数が減少しますが、スロットリングは最小限に抑えられました。これは、 デフォルトの SDK の最大再試行数が 3 (ベストプラクティス) に設定されており、SDK はスロットリングが発生する前にクエリをリトライするためです。クエリのレイテンシには再試行時間が含まれるため、同時ユーザー数が 7 名 (76 QPS) を超えると、主に複数のリトライが原因で p99 レイテンシーが増加していることがわかります。ユースケースで 1 秒未満のクエリ遅延が許容できる場合は、4 つの TCU で最大 9 人の同時ユーザーと 1 分あたり 4,853 件のクエリをサポート出来る事が分かりました。 次に、MaxQueryTCU を 8 に増やしてテストを再実行します。Timestream サービスはオンデマンドでコンピューティング ユニットを割り当てるため、サービスは 4 TCU から開始され、ワークロードが増加するにつれて追加の 4 TCU を割り当てます。次のグラフは、8 TCU のメトリクスを示しています。 8 TCU の場合、200 ミリ秒未満の p99 レイテンシーで 9,556 件のクエリ (約 159 QPS) を処理可能でした。Grafana ユーザーの数が増えると、レイテンシーが増加し (330 ミリ秒未満)、そのため 1 分あたりのクエリ数がわずかに減少しますが、スロットリングは発生しませんでした。つまり、500 ミリ秒未満のクエリ遅延がユースケースで許容できる場合は、 8 つの TCU で最大 15 人の同時ユーザーと 1 分あたり 9,556 のクエリをサポート出来る事が分かりました。 MaxQueryTCU は最大 1,000 まで増やすことができるため、ユーザーベースの拡大に合わせて拡張できます。許容できるコストに応じて、MaxQueryTCU を増やし続けることも、遅延がユースケースとして許容できる場合には、既存の TCU を使用して追加のユーザーにもサービスを提供することもできます。 次に、以下の クエリ 2 でシミュレーションを繰り返します。これは、ビン分割、グループ化、並べ替えを実行しますが、クエリ 1 と比べるとリソースを大量に消費するクエリです。 select bin(time, 1m) AS binned_time, max(cpu_utilization) as max_cpu_utilization from "devops"."sample_devops" where time > ago(10m) and hostname='host2' group by bin(time, 1m) order by binned_time asc 次のグラフは、クエリ 2 に対応するメトリクスを示しています。 前のテストと同様に、1 人のユーザーから始めて、データにアクセスするユーザーの数を増やしていきます。4 つの TCU で、180 ミリ秒の p99 レイテンシーで 6 人の同時ユーザーに対して 3,310 件のクエリ(約 55 QPS)を処理出来ました。 Grafana ユーザーの数が増加すると、主に再試行によるオーバーヘッドが原因で 1 分あたりのクエリが減少し、レイテンシーも増加します。 次のグラフは、8 つの TCU の際のメトリクスを示しています。 8 つの TCU を使用すると、500 ミリ秒未満の p99 レイテンシーで 15 人の同時ユーザーに対して 6,051 (約 100 QPS) 件のクエリをサポートできます。 必要なパフォーマンスに必要な TCU を使用できますが、少ない TCU から始めて、希望のパフォーマンス基準を満たすか、価格とパフォーマンスの適切なバランスが見つかるまで、アカウント内の MaxQueryTCU を増やすアプローチがあります。 尚、Timestream のスケジュールクエリ機能は、集計およびロールアップ操作をサポートするように設計されており、パフォーマンスを向上させるために派生テーブル (データがすでに集計されており、データ量が削減されている) からダッシュボードや視覚化用のデータを生成するのに最適です。詳細については、「 Improve query performance and reduce cost using scheduled queries in Amazon Timestream 」を参照してください。 シミュレーションで実証されたように、4 つの TCU は 76 QPS (月間 1 億 9,900 万クエリに相当) および 55 QPS (月間 1 億 4,300 万クエリに相当) のクエリ量をサポート可能でしたが、クエリの複雑さに依存する為、シミュレーションで示されているよりも多くなる可能性があります。また、TCU はクエリ数ではなくコンピューティング使用時間に基づいて課金されるため、76 QPS と 55 QPS の費用は変わりません。クエリの同時実行の利点を最大限に高めるには、 データモデル、クエリ、ワークロードを最適化 してコンピューティングリソースを効果的に利用することが不可欠です。これにより、コストが削減され、クエリのスループットが向上し、リソースの使用率が向上します。 AWS Pricing Calculator を使用したコストの見積もり AWS Pricing Calculator を使用して、Timestream for LiveAnalytics の月額コストを見積もることができます。このセクションでは、リアルタイムクエリと分析クエリとみなされるものについての一般的なガイダンスを提供します。 リアルタイムクエリ – 小さなウィンドウ (5 分や 15 分などの数分) 内で メジャー を分析するクエリ、または通常は数百のレコードをスキャンするクエリ。 分析クエリ – 大きな時間範囲 (12 時間、日、月等) にわたってメジャーを分析するクエリ。複雑な結合やサブクエリが含まれる場合があり、通常は数千のレコードをスキャンします。これらのクエリでは、パフォーマンスを向上させるためにデータの集約とセグメント化に高いコンピューティング (CPU/メモリ) が必要です。 これは一般的なガイダンスです。小さなウィンドウ内で補間、導出、またはその他の複雑な関数を要求するような、リアルタイムクエリとして認められない可能性のあるコストのかかるクエリが存在する可能性があります。 わかりやすくするために、料金計算では、1 秒あたり 7 つの同時クエリが 4 つの TCU で 1 秒のレイテンシーで処理されると想定しています。我々の実験では、160 ミリ秒未満の p99 レイテンシーで 72 QPS を達成しました。料金計算ツールは、指定された時間単位 (秒、分、時間、日、月あたり) にわたって均等に分散されるクエリの数を分割します。場合によっては、クエリが 30 秒を超えて実行されない場合 (アイドル期間を含む)、その 1 分全体に対して料金が請求されるわけではありませんが、この Calculator では考慮されないため、実際の合計額はさらに小さくなる可能性があります。クエリのワークロードをよりよく理解している場合は、本投稿の前半で共有した例に基づいて、さらに正確なコストを計算できます。 TCU の監視 TCU の使用状況を効果的に監視するために、Timestream for Live Analytics は Amazon CloudWatch メトリクス QueryTCU を提供します。このメトリクスは、1 分間に使用されるコンピューティングユニットの数を測定し、1 分ごとに更新されます。このメトリクスを使用すると、1 分間に使用された最大および最小の TCU を追跡でき、コンピューティングの使用状況を把握できます。さらに、このメトリクスにアラームを設定して、コンピューティング使用量が特定の閾値を超えたときにリアルタイム通知を受け取ることができ、使用量を最適化し、クエリコストを削減できます。 次のグラフは、過去 3 時間に使用された QueryTCU の最大値を示しています。 最大 TCU は価格の計算には直接役立ちませんが、最大/最小 TCU がどの程度になるかに関して洞察を与える事が出来ます。正確な TCU 時間は、AWS Cost Management コンソールを開いて Cost Explorer を開始 し、Timestream for LiveAnalytics でフィルターする事で確認できます。 2024 年 4 月 29 日以降に初めて Timestream for LiveAnalytics を使用する全ての AWS アカウントは、クエリ料金設定にデフォルトで TCU を使用するようになります。 2024 年 4 月 29 日より前にサービスを利用していた場合は、「コスト管理」セクションで説明されているように、 API を通じて TCU へのオプトインを行うか、AWS Timestream コンソールで変更出来ます。 TCU ベースの価格設定に移行すると、コスト管理が改善され、クエリごとに計測される最小バイト数が無くなります。 TCU ベースの価格設定モデルへのオプトインはオプションであり、元に戻すことのできない変更です。つまり、クエリ価格設定に TCU を使用するように AWS アカウントを移行した場合、クエリ価格設定にスキャンされたバイト数を使用するように戻す事はできません。 結論 この投稿では、TCU、請求、コスト見積もりについて説明し、4 および 8 TCU 構成でのクエリワークロードのシミュレーションを実証しました。リソースを効果的に利用すれば、コストを増加させることなくワークロードを拡張できます。従量制の料金体系と TCU 使用量の最大値の設定により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。詳細については、次のリソースを参照してください。 Timestream Compute Unit (TCU) Data Modeling Best Practices to Unlock the Value of your Time-series Data Amazon Timestream pricing 今すぐ Timestream for LiveAnalytics の利用頂き、多くのメリットを享受することをお勧めします。さらに詳しく知りたい場合は、通常の AWS サポート連絡先に問い合わせるか、 Amazon Timestream の AWS re:Post に質問を投稿してください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本ブログは 2024 年 10 月 10 日に公開されたBlog ” Strengthening security in the era of generative AI: Must-attend sessions at re:Invent 2024 ” を翻訳したものです。 生成 AI は日々新たな、革新的な方法で産業を変革しています。 Amazon Web Services (AWS) では、セキュリティを最優先事項としており、イノベーションを目指す組織にとって重要な要素と考えています。AWS re:Invent 2024 に向けて準備する際は、セキュリティがどのように組織の生成 AI ソリューションを迅速かつ安全に革新するのに役立つかを学ぶため、これらの重要なセッションをスケジュールに組み込むことをお勧めします。業界をリードする専門家が、データを保護するため、あるいは、ガバナンス、リスク、コンプライアンスに対処するために、生成 AI ワークロードをどのように保護できるかについて深い洞察を共有します。 このブログでは、セキュリティリーダーや担当者、技術的な意思決定者、人工知能と機械学習 (AI/ML) の開発者向けに、必見のセッションやお気に入りのアクティビティをいくつかハイライトしました。この楽しさを共有するには、 こちらから登録 してください。ラスベガスでお待ちしています！ 基調講演とイノベーショントーク AWS re:Invent 2024 の 基調講演 と イノベーショントーク は、AWS のシニアリーダーから直接、革新的な洞察を得る機会となります。これらのセッションでは、生成 AI、クラウドセキュリティ、そしてアプリケーション開発と AWS クラウドの未来に新たな方向性を示す革新的なアーキテクチャにおける最新のブレークスルーを深く掘り下げます。 KEY002 – CEO Keynote with Matt Garman (Matt Garman による CEO 基調講演) 。基幹サービスの刷新から新しい体験の創造まで、AWS がクラウド全体でどのようにイノベーションを起こし、お客様とパートナーが安全で豊かな未来を構築できるようにしているかをご覧ください。 SEC203-INT – Security insights and innovation from AWS with Chris Betz (Chris Betz による AWS のセキュリティに関する洞察とイノベーション) 。 AWS の CISO である Chris Betz が、セキュリティを統合・自動化し、チームが重要な取り組みに集中できるようにする変革的な戦略を明らかにする中で、革新的なセキュリティ技術と生成 AI が、組織のセキュアなイノベーションの加速をどのように支援するかをご覧ください。 ARC203-INT – Architectural methods & breakthroughs in innovative apps in the cloud with Shaown Nandi and Ben Cabanas (Shaown Nandi と Ben Cabanas によるクラウドにおける革新的なアプリケーションのアーキテクチャの方法論とブレイクスルー) 。 このトークでは、生成 AI と最先端のアーキテクチャの進歩がアプリケーション設計をどのように変革し、AWS のお客様がシステムを近代化し、堅牢なデータ戦略を開発し、変化し続けるクラウド環境を安全に活用できるようにしているかを紹介します。 イノベーショントーク の全リストをご覧ください。今年、現地に参加できない方も、基調講演とすべてのイノベーショントークはライブストリーミングされます。 セッション 生成 AI のセキュリティに関する専門知識を深めるために設計された、さまざまな学習機会をご覧ください。今年のセッションでは、AI ワークロードとそれを支えるデータを保護するための、実際の環境で有効な具体的な対策をお客様に提供することに重点を置いています。講義形式のブレイクアウトセッション、インタラクティブなチョークトーク、ハンズオンワークショップ、ライブコーディングやコードサンプルを使ったインタラクティブなディスカッションなど、あなたのニーズに合わせたセッションがあります。以下のオプションをご覧いただき、 参加を申し込んで 、この急速に発展する分野での理解と実践的なスキルを向上させてください。 セッションレベル (100 – 400) とセッションタイプの詳細や説明については、 re:Invent のウェブサイト でご確認いただけます。 ブレイクアウトセッション ブレイクアウトセッションは、AWS のエキスパート、お客様、パートナーが提供する 1 時間の講義形式のセッションです。重要なトピックに関する知識を深め、実用的な洞察を得て、業界のリーダーとネットワークを築くのに最適です。 SEC214 – Elevating client experiences with secure AI: Rocket Mortgage’s approach (安全な AI によるクライアント体験の向上： Rocket Mortgage のアプローチ) 。 Rocket Mortgage が AWS の生成 AI サービスを実装して、セキュリティの課題に対処しながら顧客体験を向上させた方法をご覧ください。 セッションの登録 SEC315 – Bring your workforce identities to AWS for generative AI and analytics (生成 AI と分析のために従業員のアイデンティティを AWS に持ち込む) 。 このセッションでは、従業員のアイデンティティプロバイダーを統合して、生成 AI アプリケーションやツールへのアクセスを容易にする力を実演します。AWS と NVIDIA が、アイデンティティを意識したエンドツーエンドの体験をデモンストレーションします。 セッションの登録 SEC323 – The AWS approach to secure generative AI (生成 AI をセキュアにする AWS のアプローチ) 。 AWS がインフラストラクチャ、モデル、アプリケーションの各層で生成 AI をどのように保護し、組み込みのセキュリティ機能でお客様にデータの制御を提供しているかを学びます。 セッションの登録 SEC403 – Generative AI for security in the real world (現実世界におけるセキュリティのための生成 AI) 。 セキュリティチームのための実用的な生成 AI アプリケーションを探索し、インシデント対応、レッドチーム/ブルーチームの強化、セキュリティオペレーションセンター (SOC) のユースケースを含め、セキュリティ運用を強化します。 セッションの登録 チョークトーク チョークトーク（ Chalk talk ）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。このフォーマットは、特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問に答えてもらえるのに理想的です。 SEC303 – Protecting data within your generative AI architectures (生成 AI アーキテクチャ内のデータ保護) 。 機密データを用いた大規模言語モデル (LLM) のトレーニングにおけるリスクを軽減します。サニタイゼーション、匿名化、差分プライバシーなどの技術を探ります。 このトークに登録する SEC327 – Building secure network designs for gen AI applications (生成 AI アプリケーションのためのセキュアなネットワーク設計の構築) 。 AWS 上でのイノベーションを加速し、より安全に変革的な生成 AI アプリケーションを実現するため、クラウドネットワーク設計を最適化します。実証済みのベストプラクティス、先制的な制御、および回復力のある多層防御アーキテクチャを構築するためのリファレンスアーキテクチャを共有します。 このトークに登録する SEC335 – Harness generative AI for business growth amidst the regulatory landscape (規制環境の中で生成 AI を活用してビジネス成長を促進) 。 AWS AI/ML ソリューションがどのように責任あるプラクティスに沿いながらビジネス成長を促進できるかを探ります。欧州連合の一般データ保護規則 (GDPR) から業界固有の規制まで、進化する規制環境をナビゲートするための戦略について、お客様事例から学びます。 このトークに登録する SEC336 – Security and compliance considerations using Amazon Q Business (Amazon Q Business 使用時のセキュリティとコンプライアンスの考慮事項) 。 Amazon Q Business アプリケーションを安全に保つためのベストプラクティスを探ります。アクセス制御、データ保護、コンプライアンスの考慮事項に焦点を当て、AI アシスタントを安全かつコンプライアンスに準拠した状態に保つ方法を学びます。 このトークに登録する SEC338 – Safeguard your generative AI apps from prompt injections. (プロンプトインジェクションから生成 AI アプリを保護) 。 入力検証、セキュアなプロンプトエンジニアリング、コンテンツモデレーションを理解することで、生成 AI アプリケーションをプロンプトインジェクション攻撃 (AI システムを操作して意図しない出力を生成させる攻撃) から保護する方法を学びます。 このトークに登録する PEX308 – Securing generative AI on AWS (AWS 上の生成 AI のセキュリティ確保) 。 パートナーの視点から生成 AI のセキュリティ考慮事項を探ります。パートナーがどのようにデータセキュリティを強化できるか、またお客様の生成 AI ワークロードにパートナーがもたらす付加価値について学びます。 このトークに登録する AIM344 – Understanding the deep security controls within Amazon Q Business (Amazon Q Business 内の深層セキュリティ制御の理解) 。 Amazon Q 内のセキュリティ関連の機能と制御について学び、ビジネスデータを安全に自信を持って使用できるようにします。 このトークに登録する AIM407 – Understand the deep security controls within Amazon Bedrock (Amazon Bedrock 内の深層セキュリティ制御の理解) 。 Amazon Bedrock のセキュリティの詳細に深く踏み込みます。ガードレール、エージェント、ナレッジベースなどの複雑な機能のアーキテクチャ、データフロー、ライフサイクル管理を解説し、データのプライバシーと制御を妥協することなくこの生成 AI サービスを使用できるようにします。 このトークに登録する DEV323 – OWASP Top 10 for LLMs (LLM のための OWASP トップ 10) 。 大規模言語モデル (LLM) に対する OWASP トップ 10 リスクの実際の脆弱性と実証済みの緩和戦略を、インタラクティブなデモと実践的な演習を通じて探ることで、生成 AI アプリケーションのセキュリティ確保スキルを強化します。 このトークに登録する コードトーク コードトークは、人気のあるチョークトーク形式に似ていますが、ホワイトボードでの説明ではなく、ライブコーディングやコードサンプルに焦点を当てています。これらのセッションでは、ソリューションの構築に使用される実際のコードを詳しく見ていき、参加者がアプローチの「理由」を理解し、エラーも含めた開発プロセスを観察できます。参加者は質問をしたり、実際に手を動かしながら学んだりすることが推奨され、より深い実践的な学習体験を得ることができます。 SEC401 – Inspect and secure your application with generative AI (生成 AI を活用したアプリケーションの検査とセキュリティの確保) 。 生成 AI の力を活用してアプリケーションのセキュリティを強化します。AI 駆動型ツールが脆弱性を迅速に検出し、修復戦略を推奨する方法を紹介しながら、より安全なソフトウェアを容易に構築する方法を解説します。 このセッションに登録 SEC405 – Consolidated data protection insights with generative AI (生成 AI を用いたデータ保護の包括的な洞察) 。 Amazon Q in QuickSight を使用して、アカウント全体の AWS KMS キーを迅速かつ実用的な洞察で保護する方法を学びます。 このセッションに登録 ビルダーズセッション AWS のエキスパートが主導する少人数のグループに参加し、AWS 上での構築方法についてインタラクティブに学習します。各ビルダーズセッションは、これから構築するものについての簡単な説明やデモンストレーションから始まり、その後はみなさんの番です！エキスパートがこの一連のハンズオン体験をガイドします。 注意： これらのセッションに参加するには、必ずご自身のラップトップを持参してください。 DOP302 – Creating secure code with Amazon Q Developer (Amazon Q Developer を使用したセキュアなコードの作成) 。 Amazon Q Developer の AI を活用した機能を使用して、よりセキュアで最適化されたコードを書き、脆弱性を検出し、即座に修正を実装する実践的な経験を積むことで、開発ワークフローを変革し、コーディング能力を飛躍的に向上させます。 このセッションに登録する SMB302 – Empower your business with defense-in-depth architecture (多層防御アーキテクチャによるビジネスの強化) 。 実用的でコスト効率の高い多層防御戦略、階層化されたセキュリティアーキテクチャ、AI 特有の保護策を探求することで、中小企業が生成 AI を使ってより安全にイノベーションを起こせるようにし、AWS クラウド上でレジリエントで信頼性の高い AI を活用したソリューションを構築します。 このセッションに登録する ワークショップ ワークショップは 2 時間のインタラクティブなセッションで、チームで協力するか個人で取り組み、AWS サービスを使用して現実世界の課題を解決します。これはハンズオン学習に最適です。各ワークショップは短い講義から始まり、その後、問題に取り組むための時間が確保されています。 注意： AWS エキスパートと一緒に構築作業を行うため、ノートパソコンの持参をお忘れなく。 SEC305 – Generative AI-based code remediations and patch management at scale (生成 AI を活用したスケーラブルなコード修復とパッチ管理) 。 AWS Lambda 、コンテナ、 Amazon Elastic Compute Cloud (Amazon EC2) 全体で、生成 AI を使用して脆弱性の検出と修復を自動化する方法を実践的に体験します。これにより、チームはアプリケーションを積極的に保護することができます。 このワークショップに登録する SEC306 – Securing your generative AI applications on AWS (AWS 上の生成 AI アプリケーションのセキュリティ確保) 。 AWS のサービスと機能を使用して、生成 AI アプリケーションのセキュリティを確保する実践的な経験を得ることができます。脆弱性のあるサンプル AI アプリをデプロイし、その後、問題を保護、検出、対応するための階層的なセキュリティ制御を実装します。これらのベストプラクティスを活用して、帰国後に自身の AI アプリケーションのセキュリティを確保できます。 このワークショップに登録する SEC309 – AWS IAM Identity Center: Secure access to generative AI applications (AWS IAM Identity Center: 生成 AI アプリケーションへの安全なアクセス) 。 アイデンティティを認識するチャットエクスペリエンスの構築方法、サンプルデータセットでのトレーニング方法、そして Amazon Q Business と AWS IAM Identity Center 間のネイティブ統合を使用して外部ワークフォース ID プロバイダーに接続する方法を学びます。 このワークショップに登録する SEC310 – Persona-based access to enterprise data for generative AI applications (生成 AI アプリケーションのための企業データへのペルソナに基づいたアクセス) 。 このインタラクティブなワークショップでは、検索拡張生成 (RAG)、メタデータフィルタリング、 Amazon Cognito を使用して、生成 AI アプリケーションでのドキュメントアクセスを保護する方法を学びます。 このワークショップに登録する Expo の概要 生成 AI のセキュリティや、その他さまざまなセキュリティトピックについて AWS のセキュリティエキスパートと直接話したいですか？その場合は、展示会場のセキュリティアクティベーションエリアで AWS の主要なセキュリティエキスパートと 1 対 1 で会話できます。この機会をお見逃しなく。組織のセキュリティ態勢を強化するお手伝いをします。 以下のような主要なセキュリティ領域について詳しく説明します： 検出と対応: 大規模なワークロードを保護するために、セキュリティリスクの検出と対応のテクニックを探ります。 ネットワークとインフラストラクチャのセキュリティ: AWS サービスを使用して、安全なグローバルネットワークを構築および管理する方法を学びます。 アプリケーションセキュリティ: セキュアなソフトウェアを提供し、アプリケーションセキュリティの課題に対処するための戦略を探ります。 アイデンティティとアクセス管理: 最新のクラウドネイティブなアイデンティティソリューションを採用し、最小権限のアクセス制御を適用します。 デジタル主権とデータ保護: データの制御を維持し、AWS クラウドでデータをセキュアに保護し管理する方法を選択できます。 楽しい時間はまだ続きます！ 革新的な洞察と深い学習に満ちた刺激的な 1 週間の後、世界的に有名な re:Play パーティー にご参加ください。これは re:Invent のフィナーレを飾るパーティーです！ヘッドライナーアーティストによるライブエンターテイメント、絶品の料理、たっぷりの飲み物に囲まれながら、リラックスし、交流を深め、無限の可能性に満ちた未来に乾杯しましょう。 今すぐ登録 re:Invent 2024 は素晴らしいイベントになることは間違いありません。みなさまにお会いできることを楽しみにしています！ 今すぐ登録 して、席を確保してください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Anna Montalat Anna は、AWS 生成 AI セキュリティのシニアプロダクトマーケティングマネージャーで、お客様が Amazon Bedrock、Amazon SageMaker、Amazon Q、その他の AI/ML ソリューションを安全にデプロイできるよう支援しています。新興技術を市場に投入することに情熱を注ぎ、サービスチームやエンタープライズのお客様と緊密に連携しています。仕事以外では、冬はスキー、夏はセーリングを楽しんでいます。 Matt Saner AWS のシニアマネージャーとして、Matt は世界で最も複雑な組織が重要なセキュリティ課題に取り組むのを支援するセキュリティスペシャリストのチームを率いています。Matt とそのチームはセキュリティ組織を戦略的なビジネスイネーブラーに変革するよう取り組んでいます。AWS に入社する前は、金融サービス業界で約 20 年間のキャリアを積みました。仕事以外では、パイロットとして一般航空機を操縦することに喜びを見出しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました

本ブログは 2024 年 1 月 17 日に公開されたBlog ” Building a security-first mindset: three key themes from AWS re:Invent 2023 ” を翻訳したものです。 AWS re:Invent 2023 が 2023 年 11 月 27 日から 12 月 1 日までネバダ州ラスベガスで開催され、世界中から 52,000 人が参加しました。 12 回目となる今回のカンファレンスでは、5 つの基調講演、17 のイノベーショントーク、そして 2,250 を超えるセッションとハンズオンラボを開催して、参加者には実践的な学習とネットワーキングの機会をご提供しました。 Amazon CSO Stephen Schmidt 何十もの新サービスと新機能の発表、そして AWS の幹部、お客様、 パートナー が共有する数え切れないほどのベストプラクティスにより、会場は熱気に包まれていました。私たちは現地ですべての革新的な取り組みと知見を体験しましたが、その要点をまとめるのは容易ではありません。このブログでは、注目を集めた 3 つの重要なセキュリティテーマに焦点を当てて説明します。 セキュリティ文化 サイバーセキュリティについて考えるとき、ビジネスを保護するための技術的なセキュリティ対策に注目するのは自然なことです。しかし、組織は技術ではなく人々で構成されています。自らを守る最良の方法は、効果的なリスク軽減、インシデントの検出と対応、そして継続的なコラボレーションを支える、積極的でレジリエントなサイバーセキュリティ文化を育むことです。 Sustainable security culture: Empower builders for success (持続可能なセキュリティ文化：ビルダー成功の促進) において、AWS Global Services Security Vice President の Hart Rossman 氏と AWS Global Services Security Organizational Excellence Leader の Sarah Currey 氏が、持続可能なセキュリティ文化を構築するための実践的な戦略を提示しました。 Rossman 氏は、セキュリティの課題について AWS と話し合う多くのお客様が、セキュリティをプロジェクト、プログラム、またはサイドプロジェクトとして管理しようとしていると指摘しました。セキュリティ態勢を強化するには、ビジネスにセキュリティを組み込む必要があると彼は述べました。 「セキュリティをプロジェクトやプログラムのように運用していては効果的になり得ないということを、早い段階で理解する必要があります。セキュリティは、経営上の必須事項、つまりビジネスの中核機能として運営しなければなりません。そうすることで、真の効果を発揮できるのです。」— Hart Rossman 、 AWS Global Services Security Vice President 3 つの役立つベストプラクティスを紹介しましょう。 継続的に粘り強く取り組む。 セキュリティの課題を提起してくれた従業員に対して、定期的かつ明確に感謝の意を表しましょう。繰り返しのように感じるかもしれませんが、セキュリティイベントやエスカレーションを学習の機会として扱うことで、ポジティブな文化を醸成できます。こうしたポジティブな文化を築くことで、プラクティスを組織全体に広めていくことができるようになります。共感的なリーダーシップアプローチは、従業員がセキュリティを全員の責任として捉え、経験を共有し、協力者として感じることを促します。 経営陣に報告する。 定期的にビジネスに焦点を当てた会議で経営陣と関わりを持ちましょう。セキュリティ文化が顧客に与える影響に関連する業務指標を明確に提供し、データとビジネス成果を明確に結びつけ、質問する機会を設けることで、経営陣の支持を得ることができます。そして、持続可能で積極的なセキュリティ態勢を確立する取り組みを前進させることができます。 考え方の枠組みを持つ。 良好なセキュリティ文化を創造するための考え方の枠組みを持ちましょう。Rossman 氏は、AWS で観察したセキュリティ文化の 3 つの要素を強調する図(図1) を提示しました：学習者、管理者(スチュワード)、そして構築者(ビルダー)です。セキュリティ文化の良き管理者になりたいのであれば、常に学び、実験し、ベストプラクティスを伝える学習者であるべきです。管理者としての役割が成長するにつれて、セキュリティ文化の構築者となり、文化を新しい方向に進展させることができます。 図1: セキュリティ文化を構築するための考え方の枠組み例 包括性、共感、心理的安全性の原則に対する配慮と取り組みは、チームメンバーが自信を持って発言し、リスクを取り、アイデアや懸念を表現するのに役立ちます。これにより、課題提起を奨励する文化が促進され、従業員が燃え尽きてしまうことを減らし、チームが組織全体のセキュリティ向上に貢献できるようにします。 Shipping securely: How strong security can be your strategic advantage (安全なデリバリー：強力なセキュリティが戦略的優位性となる方法) において、AWS Enterprise Strategy Director の Clarke Rodgers 氏は、セキュリティを最優先するマインドセットを醸成する上でのセキュリティ文化の重要性を改めて強調しました。 Rodgers 氏は、800 社以上のお客様との会議に基づいて、発展段階の 3 つの柱(図2) —認識段階(aware)、追加段階(bolted-on)、統合段階(embedded)—を強調しました。組織が受動的なセキュリティ態勢から能動的なセキュリティ重視のアプローチへと成熟するにつれて、セキュリティ文化が真のビジネスの推進力になると彼は指摘しました。 「組織が強力なセキュリティ文化を持ち、全員がセキュリティを自分の責任と考えるとき、より迅速に行動し、より迅速かつ安全な製品やサービスのリリースを実現できます。」— Clarke Rodgers 、 Director of Enterprise Strategy at AWS 図2: セキュリティを最優先した開発 人間中心の AI CISO やセキュリティ関係者は、効果的なサイバーセキュリティを確立し、従業員の負担を軽減するために、ますます人間中心の視点へと転換しています。 Gartner によると、2027 年までに、大企業の CISO の 50% が、サイバーセキュリティ施策による煩わしさを最小限に抑え、セキュリティ対策の導入を最大化するために、人間中心のセキュリティ設計手法を採用するようになるとされています。 Amazon の CSO である Stephen Schmidt 氏が Move fast, stay secure: Strategies for the future of security (迅速に行動し、安全を確保する: セキュリティの未来に向けた戦略) で述べているように、技術を最優先することは根本的に間違っています。セキュリティは、脅威アクターにとっても、防御側にとっても、人的な課題です。絶え間なく変化する環境に対応し、私たちが支援するお客様のビジネスを安全にサポートするには、ソフトウェアでは解決できない常に変化する課題に焦点を当てる必要があります。 そのような重点を置き続けるには、セキュリティチームと開発チームに、業務の一部を自動化し効率的に拡張するために必要なツールを提供することが求められます。 「人間は最も限りがあり、最も価値のあるリソースです。人間はセキュリティのあらゆる層に影響を与えます。人間が最大限効果的に活動できるよう、私たちがツールとプロセスを提供することが重要です。」— Stephen Schmidt 、 Amazon CSO 組織は、セキュリティのあらゆる層に適用するために人工知能(AI) を使用できますが、AI は熟練したエンジニアの役割を置き換えるものではありません。他のツールと連携して使用し、適切な人間によるレビューを行うことで、セキュリティコントロールをより効果的にすることができます。 Schmidt 氏は、ソフトウェア開発プロセスを加速させるための Amazon 社内での AI の活用や、新たに生成 AI を活用し、人間のスキルを補完する Amazon Inspector 、 Amazon Detective 、 AWS Config 、 Amazon CodeWhisperer の機能を強調しました。これらは、より広範な知識を活用し、人々のセキュリティに関する意思決定を支援します。高度なツールと熟練したエンジニアを組み合わせるこのアプローチは非常に効果的です。なぜなら、AI 単独では難しい、効果的なセキュリティに必要な繊細な判断を人間が行える立場に置くからです。 How security teams can strengthen security using generative AI (セキュリティチームが生成 AI を活用してセキュリティを強化する方法) では、AWS のシニア セキュリティスペシャリスト ソリューションアーキテクトである Anna McAbee 氏と Marshall Jones 氏、そしてプリンシパルコンサルタントの Fritz Kunstler 氏が、内部のナレッジベースと信頼できる公開ソースに基づいて一般的なセキュリティの質問やユースケースに対応できる仮想セキュリティアシスタント (チャットボット) を紹介しています。 図3: 生成 AI を活用したチャットボットのアーキテクチャ 図3 に示されている生成 AI を活用したソリューション（ Amazon Kendra 、 Amazon Security Lake 、 Amazon Bedrock を使用した検索拡張生成 (RAG) を含む）は、定型的なタスクの自動化、セキュリティに関する意思決定の迅速化、新たなセキュリティ課題への注力を増やすことに役立ちます。 このコードは GitHub から入手できます 。すぐに使えるコードのため、お客様の AWS アカウントでさまざまな大規模言語モデルとマルチモーダル言語モデル、設定、プロンプトを使って試してみることができます。 セキュアなコラボレーション コラボレーションはサイバーセキュリティの成功に不可欠ですが、進化する脅威、柔軟な勤務形態、そして拡大するデータ保護とプライバシーの錯綜する規制により、 安全で規制に準拠したメッセージング の維持が課題となっています。 推定で 30.9 億人のスマートフォンユーザーがコミュニケーションのためにメッセージングアプリを利用しており、この数字は 2025 年には 35.1 億人 に増加すると予測されています。 一般利用者向けメッセージングアプリをビジネス関連のコミュニケーションに使用することは、組織にとってデータが適切に保護され保持されているかを確認することが難しくなります。これは、特に特別な記録保持要件がある業界において、リスクの増大につながる可能性があります。 How the U.S. Army uses AWS Wickr to deliver lifesaving telemedicine (米国陸軍が AWS Wickr を使用して救命遠隔医療を提供する方法) において、米国陸軍遠隔医療先端技術研究センター (TATRC) のシニアディレクター Matt Quinn 氏、Deloitte のシニアマネージャー Laura Baker 氏、AWS Wickr のプロダクト責任者 Arvind Muthukrishnan 氏が講演を行いました。彼らは、TATRC の National Emergency Tele-Critical Care Network (NETCCN) が、 AWS Wickr および AWS Private 5G とどのように統合されたかを説明しました。AWS Wickr は HIPAA 対応の安全なメッセージングおよびコラボレーションサービスであり、AWS Private 5G はプライベートセルラーネットワークの展開とスケーリングのためのマネージドサービスです。 セッション中、Quinn 氏、Baker 氏、Muthukrishnan 氏は、TATRC が厳しい環境下でリアルタイムの患者ケアを行うために、現場と遠隔地の医療チーム間の安全な連携を可能にする、リソースの少ない環境でも利用可能な、クラウドベースの遠隔医療ソリューションをどのように実現したかを説明しました。Wickr を使用することで、現場の医療従事者は、医療専門家とのエンドツーエンドで暗号化されたビデオ通話、メッセージング、ファイル共有を通じて、自身の訓練レベルを超える怪我の治療を行うことができました(図4)。また、組織の要件に従って通信記録を安全に保持することができました。 「Wickr を軍事緊急遠隔重症治療プラットフォーム (METTC-P) に組み込むことで、エンドツーエンドの暗号化通信によるセキュリティとプライバシーを提供するだけでなく、戦闘救護員やその他の最前線の医療従事者が世界中の医療専門家から即座に助言を得る能力を与えます。これらの機能は、長期化する治療と、多領域作戦 (MDO) 戦場における多数の負傷者の治療という同時に直面する課題に対処するために必要となるでしょう。」— Matt Quinn 、 TATRC Senior Director 図4: AWS Wickr を使用した遠隔医療ワークフロー 別のチョーク・トークセッション Bolstering Incident Response with AWS Wickr and Amazon EventBridge (AWS Wickr と Amazon EventBridge を活用したインシデント対応の強化) では、AWS Wickr のシニアソリューションアーキテクトである Wes Wood 氏と Charles Chowdhury-Hanscombe 氏が、Wickr を Amazon EventBridge および Amazon GuardDuty と統合する方法をデモンストレーションしました。この統合により、AWS リソースを Wickr ボットに接続する統合ワークフロー(図5) が実現し、インシデント対応能力を強化することができます。このアプローチを使用することで、ネットワークが侵害されている可能性がある場合でも、セキュアな通信チャネルを通じて適切な関係者に重大な検出結果を迅速に警告することが可能になります。 図5: インシデントレスポンスのコミュニケーションのための AWS Wickr 統合 セキュリティは私たちの最優先事項 AWS re:Invent 2023 では、 ゼロトラスト によるアダプティブアクセスコントロール、 AWS サイバー保険パートナー 、Amazon の CTO である ワーナー・ヴォゲルス博士 の人気のキーノート、そして Expo フロアで紹介されたセキュリティパートナーシップなど、さまざまなトピックについてさらに多くのハイライトがありました。多岐にわたる内容でしたが、1 つ明確なことがあります。それは、AWS が技術面とビジネス面の両方の成果を実質的に改善できるよう、セキュリティ最優先のマインドセットの醸成を支援するために懸命に取り組んでいるということです。 オンデマンドのカンファレンスセッションを視聴するには、 YouTube の AWS re:Invent 2023 セキュリティ、アイデンティティ、コンプライアンスのプレイリスト をご覧ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 Clarke Rodgers Clarke は AWS のエンタープライズセキュリティ担当ディレクターです。セキュリティ業界で 25 年以上の経験を持ち、エンタープライズのセキュリティ、リスク、コンプライアンスに焦点を当てた幹部と協力して、セキュリティ態勢を強化し、クラウドのセキュリティ機能を理解するための支援を行っています。AWS に入社する前は、多国籍保険会社の北米事業の CISO を務めていました。 Anne Grahn Anne は、シカゴを拠点とする AWS のシニアワールドワイドセキュリティ GTM スペシャリストです。セキュリティ業界で 13 年以上の経験を持ち、サイバーセキュリティリスクを効果的に伝えることに焦点を当てています。公認情報システムセキュリティ専門家（ CISSP ）の資格を保持しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

スポーツ業界が大きな変革期を迎える中、クラウドテクノロジーがイノベーションの原動力となっています。2024 年 9 月 5 日に開催したウェビナーでは、スポーツビジネスの変革を加速する AWS の取り組みと、先進的な活用事例をご紹介しました。 セミナーのアジェンダ: スポーツ業界のイノベーション – アマゾン ウェブ サービス ジャパン合同会社 山口 新時代の競輪レース映像と、AWS クラウドを活用した全国展開 – 株式会社 WinTicket 内田様 スポーツコンテンツホルダーが進めるクラウド活用～映像とデータ領域のシステム内製化～ – パシフィックリーグマーケティング株式会社  渡邉様 スポーツ業界のイノベーション アマゾン ウェブ サービス ジャパン合同会社 インダストリースペシャリスト 山口 [ 資料 ] AI やスポーツデータレイク、IoT などの先端技術を導入し、スポーツ現場に多様な変革をもたらすためにクラウドの活用が進んでいます。選手分析の高度化、スマートスタジアムの実現、ファンエンゲージメントの向上など、スポーツの体験そのものを革新するソリューションが続々と生まれています。こうした業界変革の中で、AWS の取り組みと世界のお客様事例を紹介しました。 新時代の競輪レース映像と、AWSクラウドを活用した全国展開 株式会社 WinTicket スポーツ映像テック事業部 事業責任者　内田 厚太郎 様 [ 資料 ] WINTICKET が提供する、リアルと CG が融合した独自の競輪ライブ映像「WINLIVE」。競輪は全国 43 ヶ所の競輪場で毎日 100 レース前後おこなわれており、そのすべてで WINLIVE を実施するには AWS のクラウド活用が不可欠です。選手トラッキングのための画像認識、データ計算、CG 描画、映像配信、すべてのシステムを AWS クラウドへ移行する取り組み（鋭意進行中）についてご紹介いただきました。 スポーツコンテンツホルダーが進めるクラウド活用～映像とデータ領域のシステム内製化～ パシフィックリーグマーケティング株式会社 メディア事業本部 IT統括部部長 兼 開発グループマネージャー　渡邉 公悠 様 [ 資料 ] スポーツ業界の”コンテンツホルダー”側は IT リソース不足の課題がある中、パシフィックリーグマーケティング (PLM) ではクラウドサービスを使って映像配信基盤やデータ分析システムを構築、データの活用やコスト削減を実現し、技術的なナレッジも社内に蓄積される体制構築を進めています。また、内製化によってコンテンツのニーズへ素早く対応し、今後のビジネスの拡大を目指しています。今回は、パ・リーグTV、パ・リーグ.com 開発の背景にある AWS を中心としたクラウドサービスの活用事例を紹介しただきました。 おわりに 本ブログでは、2024 年 9 月 5 日に開催されたメディアセミナーについて紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 —- 参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは AWS 山口が担当いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 2024 年 10 月 17 日 (木) に「 生成 AI と AWS Ad/Marketing Tech Services で実現する広告・マーケティングイノベーション 」というイベントをオンラインで開催します。クッキーレス時代における広告やマーケティングの最新技術とビジネスの動向、AWS のお客様事例をお届けします。広告やマーケティングに携わる方はぜひご参加ください。 コンテンツ回りでは「 2024 年 9 月の AWS Black Belt オンラインセミナー資料及び動画 」が公開されています。「Amazon Bedrock Agents 自律型 AI の実現に向けて: 検討編」、「Amazon Bedrock Knowledge Bases」、「Amazon Bedrock モデル推論 a. 準備編, b.実践編」と Bedrock のコンテンツが盛りだくさんです。資料でも動画でもご都合良い方でご覧ください。 これまで何度か紹介していた「 AWSジャパン生成AI実用化推進プログラム 」は、受付期限が 2024 年 11 月 22 日 に延長されました。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 7 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 大阪ガス株式会社様、生成 AI を使った高精度のカーボンクレジット評価システムを構築 こちらのブログは 前半 と 後半 の連載となっています。大阪ガス様は、2050 年までにカーボンニュートラルを実現することを目標としており、その一環としてカーボンクレジットの活用推進を行っています。カーボンクレジットとは、企業の温室効果ガス排出削減量をクレジットとして発行し取引可能にする仕組みです。カーボンクレジットを利用する際は、企業の取り組みの品質を評価することが非常に重要です。そこで、大阪ガス様ではカーボンクレジットの計画書を生成 AI で解析し、品質評価を行う仕組みを AWS 上に開発しました。計画書に対し、Claude 3.5 Sonnet などのモデルを使って重要な評価基準に基づいたリスク評価を行うことができます。格付会社による評価結果との一致率を測る検証の結果、Claude 3.5 Sonnet では、正解率 97.5%、再現率 96.4%、適合率 99.1% と高い精度の結果を得ることができました。今後は、本システムを気候変動対策のための共通プラットフォームとすることを目指し、精度と信頼性向上に取り組んでいくとのことです。 AWS生成AI国内事例ブログ: ANA X様、生成 AI によるお客様の声 (VoC) 分析により、分類作業や分析時間を60％削減 ANA X様は、商品の改善策の検討のために、コンタクトセンターの通話内容の分析を行っています。分析では、「えーっと」などの意味のない言葉が上位ワードとして捉えられてしまう、言葉の意味を踏まえた問い合わせの分類が難しい、といった課題があり、分類作業を含めた分析作業に1週間程度の時間を要していました。そこで、Amazon Bedrock を使ったお客様の声 (VoC) 分析を行いました。Bedrock の利用により、文脈に沿った問い合わせ理由の自動分類や、これまで見過ごされていた詳細な問い合わせ理由の可視化が実現でき、分類作業、詳細分析時間が 60％ 削減されました。、プロンプトエンジニアリングの設計には、 生成 AI 練習帳 の活用や異なる部門のメンバーを巻き込んだ社内プロンプトワークショップの開催を行なった点も参考になります。 ブログ記事「経済産業省 GENIAC 基盤モデル開発支援事業 (第2期) における採択事業者への支援を開始」を公開 2024年10月10日、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が協力して実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の第2期 (2024年7月公募) における採択事業者のキックオフが行われ、本事業の採択事業者が発表されました。AWS は、計算リソース提供事業者として、技術支援や事業化支援等を行います。ブログではAWSを利用する採択事業者とコメントを掲載しています。 ブログ記事「流通・小売・消費財企業のイノベーションを生成 AI で促進する」を公開 AWS は生成 AI を活用した流通・小売・消費財企業の変革を支援しています。本ブログでは、 こちらのe-book  に記載されている生成AI のユースケース、導入のステップ、関連する技術のハイライトを解説しています。 ブログ記事「Amazon Bedrock で利用可能になった Meta からの Llama 3.2 モデルの紹介: 新世代のマルチモーダルビジョンモデルと軽量モデル」を公開 先々週の週刊生成AI with AWS にて、Amazon Bedrock で Meta 社の Llama 3.2 が利用できるようになったとお知らせしました。このブログ記事では、その話題をさらに深掘りする記事の和訳バージョンです。4つのモデル (90B、11B、3B、1B) それぞれの特徴や使用方法を解説しています。 ブログ記事「AI21 Labs の Jamba 1.5 ファミリーのモデルが Amazon Bedrock で利用可能に」を公開 こちらも 先々週の週刊生成AI with AWS でお知らせした AI21 Labs の Jamba 1.5 ファミリーモデルの解説を行う和訳記事です。Jamba 1.5 Mini と Jamba 1.5 Large の特徴について解説しています。 ブログ記事「生成 AI ワークロードのインシデント対応方法論」を公開 生成AI ワークロードにおけるインシデント対応は、 AWS セキュリティインシデント対応ガイド に記載されているガイダンスに加えて生成AI ならではの要素も考慮する必要があります。本ブログでは、インシデント発生前の準備、対応方法、インシデント例を紹介しています。 ブログ記事「Amazon Connect で簡単に実現する、生成 AI を活かしたより良いカスタマーエクスペリエンス」を公開 このブログは、カスタマーエスクペリエンス (CX) 向け生成 AI ブログシリーズの パート1 、 パート2 に続くパート 3 の記事です。今回の記事では、エージェントの効率性の向上、分析と品質のモニタリングといったカスタマーサービスのユースケースに対して、生成 AI を迅速かつ簡単に有効化する方法を紹介しています。 サービスアップデート コンソールからコードを生成する Console to Code の一般提供を開始 AWS マネジメントコンソールから本番デプロイメント用のコード作成を行う Console to Code の一般提供を開始しました。Console to Code を使用すると、コンソールで実行したアクションを、CLI、CloudFormation、CDK 形式から選択したコードに簡単に変換できます。コード変換には Amazon Q Developer が活用されています。現在は、EC2・VPC・RDS に対応しています。 Amazon Q in Connect のプロンプトカスタマイズ機能が利用可能に コンタクトセンターのエージェント向け生成AI搭載アシスタントである Amazon Q in Connect にて、LLMプロンプトを事前設定する機能を提供開始しました。スーパーバイザーはプロンプトをカスタマイズすることで、応答に特定のフレーズを組み込んだり、ビジネスガイドラインに従った応答をしたりすることが可能になりました。利用可能なリージョン情報は こちら をご覧ください。 Amazon Q in Connect にてパーソナライズされたガイダンス機能を追加 Amazon Q in Connect にて、CRM システム内の顧客データを使用して、パーソナライズされたガイダンスをエージェントに推奨する機能が追加されました。リアルタイムの音声から顧客の意図を検出するのに加えて、顧客データを理解した上で、エージェントがどのようなアクションを取るべきかを推奨します。顧客にパーソナライズされた対応によって、顧客満足度向上に繋げることができます。 プレビュー：Amazon Q Business が Smartsheet との統合をサポート Amazon Q Business が、エンタープライズ向け業務管理プラットフォームである Smartsheet との統合をサポートするようになりました。Smartsheet のデータを Amazon Q Business に同期することで、Smartsheet のプロジェクトやタスクに関する情報をAmazon Q Business に問い合わせることができます。本機能は、Amazon Q Business が利用可能なすべての AWS リージョンで利用できます。 Amazon Polly向けの4つの新しい音声合成を追加 Amazon Polly は、テキストを音声に変換するサービスです。今回、アメリカ英語とオーストラリア英語に対応した4つの新たな音声合成の一般提供を開始しました。より自然な発音やイントネーションを備えており、教育、出版、マーケティングなど、様々な産業や目的で使用が可能です。 Amazon Bedrock モデル評価機能が、カスタムモデルの評価に対応 Amazon Bedrock のモデル評価機能は、精度、堅牢性、有害性などの指標に対して基盤モデルを評価、比較することができる機能です。今回、ファインチューニングや継続事前学習による独自のカスタムモデルを評価できるようになりました。これにより、お客様はベースモデルの選択、カスタマイズ、評価、本番環境への移行という一連のサイクルを迅速に回すことができるようになりました。 対応リージョン についてはこちらをご覧ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成AI と毎日戯れており、特にコード生成に注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 みなさんは「週刊AWS キャッチアップ」をご存じでしょうか？過去に一度紹介したことがあるのですが、この週刊AWSと週刊生成AI with AWSの内容を振り返るオンラインの勉強会です。実施回数は現時点で50回を超えていますから、1年以上も継続されていることになりますね。過去の内容はYoutubeでアーカイブされているのを見ることが出来ますし、参加されたい方はぜひ以下JAWS-UGのリンクから、次回スケジュールを確認してください。（木曜もしくは金曜の21時に実施されていますので、現時点では予告が出ていないかもしれません）。 – 週刊AWSキャッチアップ(Youtube再生リスト) – JAWS-UG それでは、先週の主なアップデートについて振り返っていきましょう。 2024年10月7日週の主要なアップデート 10/7(月) （この日は週刊AWSでとりあげるアップデートがありませんでした） 10/8(火) Amazon VPC Lattice is now available in 3 additional Regions – AWS Amazon VPC Lattice の利用可能リージョンが追加され、大阪リージョンでも利用可能になりました。Amazon VPC Lattice は、サービス間通信の接続、セキュリティ保護、モニタリングをシンプルに実現するアプリケーションネットワーキングサービスです。 Mountpoint for Amazon S3 CSI driver introduces new access controls for individual Kubernetes pods – AWS Mountpoint for Amazon S3 Container Storage Interface (CSI) ドライバーで、個々の Kubernetes Pod に個別の AWS ID およびIAM Roleの設定が可能になりました（以前は、Kubernetes クラスター内のすべてのポッド共通する１つのIAM Roleを設定する方式でした）。これにより、より細かい粒度で権限が設定可能になります。 Amazon OpenSearch Serverless introduces a suite of new features and enhancements – AWS Amazon OpenSearch Serverless に複数の新機能と拡張機能が追加されました。これには、ネストされたデータのより効率的な保存と検索を可能にするフラットオブジェクトデータ型、拡張された地理空間機能、多項集計(multi-term aggregation)等が含まれます。また、インデックス作成のレイテンシーの削減、昇順/降順の検索ソートの高速化等、全体的なパフォーマンスも向上しています。 Amazon Connect launches prompt customizations for Amazon Q in Connect – AWS Amazon Q in Connect はクラウドコンタクトセンターのAmazon Qに生成AIのアシスタント機能を追加するものです。今回の改善で、コンタクトセンターのスーパーバイザーが会社のブランドやビジネスガイドラインに合わせて、LLMプロンプトを事前設定できるようになりました。例えば特定の企業フレーズを取り入れたり、特定状況において固定応答を指定したりできます。 Extension of EOL Dates for Amazon Corretto 8 and 11 – AWS AWSが提供する、無料で利用可能な OpenJDK ディストリビューションのAmazon Corretto でサポート終了日(EOL)の延長が発表されました。Amazon Corretto 8 は、以前は2026年4月までだったものが、2030年12月に、Amazon Corretto 11は、以前は2027年9月だったものが、2032年の1月まで延長されており、安定したOpenJDKをより長く使っていただけるようになりました。 Announcing Amazon ElastiCache for Valkey – AWS Amazon ElastiCache で、OSSのインメモリデータベース Valkey が選択可能になりました。プロビジョン型、サーバーレスの両方から選択可能で、サーバーレスの方は他の提供エンジンと比較して33%低い料金が設定されています。 詳細はこちらのブログをご覧ください 。 Announcing Amazon MemoryDB for Valkey – AWS Amazon MemoryDB でも同様に Valkey が選択可能になりました。料金面では、書きこみが10TB/月未満は無料で利用でき、それを超えても$0.04/GBである等、既存エンジンより安価に提供されています。 詳細はこちらのブログをご覧ください 。 10/9(水) Amazon Bedrock Model Evaluation now supports evaluating custom models – AWS Amazon Bedrock のモデル評価（Model Evaluation）で、カスタムモデルも評価可能になりました。これにより、基礎となるモデルを選択し、カスタマイズして評価し、必要に応じて再度カスタマイズする、という評価のサイクルをより容易に実現可能になります。 AWS Lambda now detects and stops recursive loops between Lambda and Amazon S3 – AWS Lambda recursive loop detection (再帰ループ検出)で新たに、S3とLambda間のループを検出可能になりました。Lambda関数はS3のイベントを元に起動するよう設定できるため、Lambda関数の中で同じS3バケットにデータを置くと、再帰ループ（無限ループ）が発生してしまう可能性がありますが、これを検出して停止する等の設定が可能になりました。意図的に再帰ループさせたい場合はこの機能をオフにすることも可能です。詳細は こちらのドキュメントをご覧ください 。 10/10(木) Announcing general availability of Console to Code to generate code – AWS 管理コンソールで Console to Code 機能が利用可能になりました。名前の通り、コンソールの操作を記録して、CDKやCloudFormation等のコードに変換してくれる機能です。現時点では、Amazon EC2、Amazon VPC、Amazon RDSに対応しています。 詳細はこちらのドキュメントをご覧ください 。 10/11(金) Amazon Redshift announces generally availability for data sharing with data lake tables – AWS Amazon Redshift で data sharing with data lake tables 機能が一般提供開始（GA）になりました。これはS3上のデータを一種の外部表としてアクセスする機能を、LakeFormation経由で他Redshiftクラスターに共有可能にするものです。これにより、Redshiftクラスターそれぞれで個別にデータレイク(S3)上へのアクセス設定を行う必要がなくなります。 Cross-zone enabled Network Load Balancer now supports zonal shift and zonal autoshift – AWS AWS Network Load Balancer (NLB) で、Amazon Application Recovery Controller の zonal shift と zonal autoshift のサポートが強化されました。zonal shiftは、AZ内でのみルーティングすることで、他AZへの通信を行わないように制御する仕組みで、autoshiftと組み合わせることで、AZで大きな障害が発生した際、そのAZへルーティングをしないようにすることで、耐障害性を向上させることが可能になる機能です。今回の改善で、NLBでクロスゾーンの負荷分散を実行している環境においても、zonal shiftが利用可能になりました。詳細は こちらのブログを参照してください 。 Amazon CloudFront launches support for JA4 fingerprinting – AWS Amazon CloudFront で、Cloudfront-viewer-ja4-fingerprint ヘッダーに JA4 finger print のデータが渡されるようになりました。このJA4 fingerprintをサーバー上のカスタムロジックや、CloudFront Functions、Lambda @Edge を使用して検査、対応することが可能です。例えばマルウェアやBOTからのアクセスを検出するために利用可能です。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

このブログは 2024 年 9 月 17 日に Kanishk Mahajan (Principal, Solutions Architect) と、NetApp の Michael Shaul 氏と Sasha Korman 氏によって共同執筆された内容を日本語化したものです。原文は こちら を参照してください。 生成 AI アプリケーションは、一般的に Retrieval Augmented Generation (RAG) と呼ばれる手法を使用して構築されます。RAG を使用することで、基礎モデル (FM) はトレーニングで使用されていない追加データへアクセスすることができます。このデータは、生成 AI プロンプトを強化するために使用され、FM を継続的に再トレーニングすることなく、よりコンテキスト固有で正確な応答を提供し、透明性を向上させ、ハルシネーションを最小限に抑えます。 このブログでは、 Amazon Bedrock と Amazon FSx for NetApp ONTAP を使用して、企業固有の非構造化ユーザーファイルデータを簡単、高速、かつ安全な方法で Amazon Bedrock に取り込み、AWS 上の生成 AI アプリケーションに RAG エクスペリエンスを提供するソリューションを紹介します。 今回のソリューションでは、FSx for ONTAP ファイルシステムを非構造化データのソースとして使用し、ユーザーの既存のファイルとフォルダー、および関連するメタデータを Amazon OpenSearch Serverless ベクトルデータベース に継続的に格納します。これにより、OpenSearch Serverless から取得した企業固有のデータを用いて生成 AI のプロンプトを強化し、Amazon Bedrock を活用した RAG シナリオを実現します。 RAG を使用して Q&A チャットボットなどの生成 AI アプリケーションを開発する場合、お客様はデータのセキュリティを維持し、エンドユーザーが許可されていないデータソースから情報を照会できないようにすることも懸念しています。今回のソリューションでは、FSx for ONTAP を使用して、ユーザーが現在のデータセキュリティとアクセスメカニズムを拡張し、Amazon Bedrock からのモデル応答に適用できるようにしています。FSx for ONTAP を関連メタデータのソースとして使用し、具体的には、ファイルとフォルダーに添付されたユーザーのセキュリティアクセスコントロールリスト (ACL) 構成を使用して、そのメタデータを OpenSearch Serverless に格納します。アクセス制御操作とファイルシステム上の新規データと変更されたデータを RAG アプリケーションに通知するファイルイベントを組み合わせることで、 FSx for ONTAP によって Amazon Bedrock が 生成 AI アプリケーションに接続する特定のユーザーに対して、承認されたファイルのみを使用できるようにする方法を示しています。 AWS のサーバーレスなサービスでは、自動スケーリング、高可用性、従量課金モデルが提供されるため、開発者は生成 AI アプリケーションの構築に集中しやすくなります。 AWS Lambda を使用したイベント駆動型コンピューティングは、ドキュメントの埋め込みや柔軟な大規模言語モデル (LLM) オーケストレーションなどのコンピューティング集約型のオンデマンドタスクに適しています。また、 Amazon API Gateway は、フロントエンドとの連携や LLM のイベント駆動型呼び出しを可能にする API インターフェイスを提供します。今回のソリューションでは、API Gateway と Lambda を使用して、Amazon Bedrock と FSx for ONTAP 上にスケーラブルで自動化された API 駆動型サーバーレスアプリケーションレイヤーを構築する方法も示しています。 ソリューションの概要 このソリューションは、 AWS Managed Microsoft AD のドメインに参加した ストレージ仮想マシン (SVM) を持つ、 FSx for ONTAP マルチ AZ 構成 のファイルシステムを使用します。OpenSearch Serverless ベクトル検索コレクションは、スケーラブルで高性能な類似検索機能を提供します。 Amazon Elastic Compute Cloud (Amazon EC2) Windows サーバーを FSx for ONTAP ボリュームの SMB/CIFS クライアントとして使用し、ボリューム内の SMB 共有に対してデータ共有と ACL を設定します。このデータと ACL を使用して、Amazon Bedrock を使用した RAG シナリオにおける埋め込みへのアクセス許可をテストします。 今回のソリューションにおける埋め込みコンテナコンポーネントは、EC2 Linux サーバーにデプロイされ、FSx for ONTAP ボリュームを NFS クライアントとしてマウントします。このコンポーネントは、既存のファイルとフォルダーをセキュリティ ACL 設定とともに定期的に OpenSearch Serverless に送信します。FSx for ONTAP ファイルシステム上の NFS 共有から、企業固有のデータ (および関連するメタデータと ACL) を OpenSearch Serverless ベクトル検索コレクションのインデックスに格納します。 加えて、このソリューションでは RAG 実装用に Lambda 関数を使用します。この関数は、埋め込みコンテナコンポーネントによって格納された OpenSearch Serverless インデックスから会社固有のデータと関連メタデータ (ACL を含む) を取得して、生成 AI プロンプトを強化することで、Amazon Bedrock による RAG を可能にします。また、この Lambda 関数は、ユーザーとの会話履歴を Amazon DynamoDB テーブルに保存します。 エンドユーザーは、チャットボットアプリケーションまたは API Gateway インターフェイスから直接、自然言語プロンプトを送信することでソリューションと対話します。チャットボットコンテナは Streamlit を使用して構築され、 AWS Application Load Balancer (ALB) が前面に配置されます。ユーザーは ALB を通してチャットボット UI に自然言語プロンプトを送信すると、チャットボットコンテナは API Gateway インターフェイスと対話し、RAG 取得 Lambda 関数を呼び出してユーザーの応答を取得します。ユーザーは、プロンプトリクエストを API Gateway に直接送信して応答を取得することもできます。ドキュメントへの権限ベースのアクセスを実証するために、ユーザーの SID を明示的に取得し、その SID をチャットボットまたは API Gateway リクエストで使用します。RAG 取得用の Lambda 関数は、SID をドキュメント用に構成された Windows ACL と照合します。本番環境での追加の認証手順として、ユーザーを ID プロバイダーに対して認証し、ユーザーをドキュメント用に構成されたアクセス許可と照合することもできます。 次の図は、今回のソリューションのフローを示しています。まず、FSx for ONTAP を使用してデータ共有と ACL を設定し、次にこれらを埋め込みコンテナで定期的にスキャンします。埋め込みコンテナはドキュメントをチャンクに分割し、Amazon Titan Embeddings モデルを使用してこれらのチャンクから埋め込んだベクトルを作成します。次に、OpenSearch Serverless のベクトル検索コレクションにインデックスを設定することで、これらの埋め込んだベクトルを関連するメタデータとともに保存します。次の図は、エンドツーエンドのフローを示しています。 次のアーキテクチャ図は、ソリューションの全体像を示しています。 前提条件 次の前提条件の手順を完了してください。 Amazon Bedrock でモデルにアクセス できることを確認する。このソリューションでは、Amazon Bedrock にて Anthropic Claude v3 Sonnet を使用する。 AWS コマンドラインインターフェイス (AWS CLI) をインストールする。 Docker をインストールする 。 Terraform をインストールする 。 ソリューションをデプロイする このソリューションは、 GitHub リポジトリ からダウンロードできます。リポジトリをクローンし、Terraform テンプレートを使用すると、すべてのコンポーネントが必要な構成でプロビジョニングされます。 このソリューションのリポジトリをクローンする。 sudo yum install -y unzip git clone https://github.com/aws-samples/genai-bedrock-fsxontap.git cd genai-bedrock-fsxontap/terraform terraform フォルダーから、Terraform を使用してソリューション全体をデプロイする。 terraform init terraform apply -auto-approve このプロセスは完了するまでに 15～20 分かかることがあります。完了すると、terraform コマンドの出力は次のようになります。 api-invoke-url = "https://9ng1jjn8qi.execute-api.<region>.amazonaws.com/prod" fsx-management-ip = toset ( [ "198.19.255.230" , ] ) fsx-secret-id = "arn:aws:secretsmanager:<region>:<account-id>:secret:AmazonBedrock-FSx-NetAPP-ONTAP-a2fZEdIt-0fBcS9" fsx-svm-smb-dns-name = "BRSVM.BEDROCK-01.COM" lb-dns-name = "chat-load-balancer-2040177936.<region>.elb.amazonaws.com" データを読み込み、権限を設定する ソリューションをテストするには、FSx for ONTAP ボリュームにおいて SMB/CIFS クライアントである EC2 Windows サーバー ( ad_host ) を使用してサンプルデータを共有しユーザー権限を設定します。これらはのちに、埋め込みコンテナコンポーネントによって OpenSearch Serverless インデックスに格納されます。FSx for ONTAP SVM データボリュームをネットワークドライブとしてマウントし、この共有ネットワークドライブにデータをアップロードして Windows ACL に基づいて権限を設定するには、次の手順を実行します。 Terraform テンプレートの出力から ad_host インスタンスの DNS を取得します。 AWS コンソールで AWS Systems Manager Fleet Manager に移動し、 ad_host インスタンスを見つけて、 リモートデスクトップでログイン します。その際、ドメイン管理者ユーザー bedrock-01\Admin に対応するパスワードを AWS Secrets Manager から取得します。パスワードは、Terraform テンプレートの出力から Secrets Managerの項目で fsx-secret-id のシークレット ID を使用して見つけます。 FSx for ONTAP データ ボリュームをネットワークドライブとしてマウントするには、[ This PC ] の下で [ Network ] を選択 (右クリック) し、[ Map Network drive ] を選します。 ドライブを選択し、マウントに FSx for ONTAP 共有パス (\\<svm>.<domain >\c$\<volume-name>) を使用します。 Amazon Bedrock ユーザーガイド を共有ネットワークドライブにアップロードし、管理者ユーザーのみにアクセス権限を設定します ( [ Advanced ] で継承が無効になっていることも確認します)。 FSx for ONTAP ユーザーガイド を共有ドライブにアップロードし、権限が [ Everyone ] に設定されていることを確認します。 ad_host サーバー上で コマンド プロンプトを開き、次のコマンドを入力して管理者ユーザーの SID を取得します。 wmic useraccount where name = 'Admin' get sid チャットボットを使用して権限をテストする チャットボットを使用して権限をテストするには、Terraform テンプレートの出力から lb-dns-name の URL を取得し、Web ブラウザからアクセスします。 プロンプトクエリでは、誰でもアクセスできるように設定した FSx for ONTAP ユーザーガイドに関する一般的な質問をします。例えば「FSx for ONTAP ファイルシステムを作成するにはどうすればよいですか」と質問すると、モデルは、AWS マネジメントコンソール、AWS CLI、または FSx API を使用して FSx for ONTAP ファイルシステムを作成するための詳細な手順と出典をチャットウィンドウに返信しました。 次に、管理者アクセスのみが利用できる Amazon Bedrock ユーザーガイドに基づいて質問してみましょう。この例では、「Amazon Bedrock で基盤モデルを使用する方法」を質問したところ、モデルは質問に詳細な回答を提供するには情報が不十分であると返答しました。 チャット UI のユーザー (SID) フィルター検索で管理者 SID を使用し、同じ質問をします。するとモデルは Amazon Bedrock で FM を使用する方法の詳細手順を返信し、応答にはモデルが使用した出典が含まれています。 API Gateway を使用して権限をテストする API Gateway を使用してモデルを直接クエリすることもできます。Terraform テンプレートの出力から api-invoke-url パラメータを取得します。 curl -v '<api-invoke-url>/bedrock_rag_retreival' -X POST -H 'content-type: application/json' -d '{"session_id": "1","prompt": "What is an FSxN ONTAP filesystem?", "bedrock_model_id": "anthropic.claude-3-sonnet-20240229-v1:0", "model_kwargs": {"temperature": 1.0, "top_p": 1.0, "top_k": 500}, "metadata": "NA", "memory_window": 10}' 次に、FSx for ONTAP ユーザー ガイドに関連するクエリについて、全員からのアクセスで API Gateway を呼び出します。これを行うには、metadata パラメータの値を NA にして、全員からのアクセスを指定します。 curl -v '<api-invoke-url>/bedrock_rag_retreival' -X POST -H 'content-type: application/json' -d '{"session_id": "1","prompt": "what is bedrock?", "bedrock_model_id": "anthropic.claude-3-sonnet-20240229-v1:0", "model_kwargs": {"temperature": 1.0, "top_p": 1.0, "top_k": 500}, "metadata": "S-1-5-21-4037439088-1296877785-2872080499-1112", "memory_window": 10}' クリーンアップ 繰り返し課金されないようにするには、ソリューションを試した後、アカウントをクリーンアップしてください。terraform フォルダーから、ソリューションの Terraform テンプレートを削除します。 terraform apply --destroy まとめ この記事では、Amazon Bedrock と FSx for ONTAP を組み合わせたソリューションを紹介しました。FSx for ONTAP のファイル所有権と ACL を使用して、生成 AI アプリケーションの RAG シナリオで権限ベースのアクセスを提供します。このソリューションを使用すると、Amazon Bedrock で生成 AI アプリケーションを構築し、FSx for ONTAP ファイルシステムから企業固有の非構造化ユーザーファイルデータを使用して Amazon Bedrock の生成 AI プロンプトを強化できます。このソリューションにより、より関連性が高く文脈に即した正確な応答を提供できると同時に、承認されたユーザーのみがそのデータにアクセスできるようになります。さらにこのソリューションでは、FSx for ONTAP と Amazon Bedrock と一緒に AWS のサーバーレスサービスを使用することで、生成 AI アプリケーションの自動スケーリング、イベント駆動型コンピューティング、API インターフェイスを実現する方法、それぞれを示しています。 Amazon Bedrock と FSx for ONTAP の詳細については、次のリソースを参照してください。 Amazon Bedrock ワークショップ GitHub リポジトリ Amazon FSx for NetApp ONTAP ファイルストレージワークショップ NetApp helps customers unlock the full potential of GenAI with BlueXP workload factory and Amazon Bedrock 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Solutions Architect 吉澤が担当しました。 About the authors Kanishk Mahajan は、AWS の Principal, Solutions Architect です。AWS の ISV 顧客およびパートナー向けのクラウド変革とソリューション アーキテクチャをリードしています。Kanishk は、コンテナ、クラウド運用、移行とモダナイゼーション、AI/ML、回復力、セキュリティ、コンプライアンスを専門としています。彼は AWS においてこれらの領域の Technical Field Community (TFC) メンバーでもあります。 Michael Shaul は、NetApp の CTO オフィスの Principal Architect です。データ管理システム、アプリケーション、インフラストラクチャ ソリューションの構築に 20 年以上携わっており、クラウドテクノロジー、ビルダー、AI ソリューションに関して独自の深い視点を持っています。 Sasha Korman は、イスラエルとインドにまたがるダイナミックな開発および QA チームの技術リーダーです。プログラマーとして NetApp に入社して 14 年間のキャリアを持つ彼の実践的な経験とリーダーシップは、イノベーション、スケーラビリティ、信頼性を重視しながら複雑なプロジェクトを成功に導く上で極めて重要な役割を果たしてきました。

本ブログは 2024 年 2 月 22 日に公開された Blog ” AWS Customer Compliance Guides now publicly available ” を翻訳したものです。 AWS グローバルセキュリティ＆コンプライアンスアクセラレーション (GSCA) プログラム が、 AWS カスタマーコンプライアンスガイド (CCG) をリリースしました。CCG は、 AWS コンプライアンスのリソース ページから取得できます。業界をリードするコンプライアンスフレームワークが AWS セキュリティドキュメント とセキュリティのベストプラクティスにどのようにマッピングされているかを、お客様、 AWS パートナー 、および評価者が迅速に理解するのに役立ちます。 CCG は、130 を超える AWS サービスや機能に対して、16 の異なるコンプライアンスフレームワークにマッピングされたセキュリティガイダンスを提供します。お客様は、利用可能なフレームワークとサービスを選択し、コンプライアンスの観点を通して「クラウド内」のセキュリティが AWS サービスにどのように適用されるかを確認できます。 CCG は、AWS サービスの構成オプションに関連するセキュリティトピックと技術的管理策に重点を置いています。これらのガイドは、AWS サービス全体で一貫しているセキュリティトピックや管理策、あるいはポリシーやガバナンスなどお客様組織特有のものは扱いません。その結果、ガイドはより簡潔で、各 AWS サービスに特有のセキュリティとコンプライアンスの考慮事項に重点が置かれるようになりました。 ガイドに関するフィードバックを大切にしています。 アンケート にご回答いただき、あなたのご意見をお聞かせください。また、新しいサービスやフレームワークのリクエスト、改善の提案もお待ちしています。 CCG (Control-Based Cloud Configuration Guide) は、AWS サービスのユーザーガイドの要約を提供し、構成ガイダンスを以下のフレームワークのセキュリティ統制要件にマッピングします。 米国国立標準技術研究所 (NIST) SP 800-53 NIST サイバーセキュリティフレームワーク (CSF) NIST SP 800-171 System and Organization Controls (SOC) II Center for Internet Security (CIS) Critical Controls v8.0 ISO 27001 北米電力信頼性協議会 (NERC) 重要インフラ保護 (CIP) クレジットカード業界データセキュリティ基準 (PCI DSS) v4.0 米国防総省サイバーセキュリティ成熟度モデル認証 (CMMC) 医療保険の相互運用性と説明責任に関する法律（HIPAA） カナダサイバーセキュリティセンター (CCCS) ニューヨーク州金融サービス局 (NYDFS) 米国連邦金融機関検査協議会 (FFIEC) クラウドコントロールマトリクス (CCM) v4 情報セキュリティマニュアル (ISM) (オーストラリア) 政府情報システムのためのセキュリティ評価制度 (ISMAP) (日本) CCG は、以下の方法でお客様を支援できます： AWS ユーザーガイドを手動で検索して「クラウド内」のセキュリティ詳細を理解し、構成ガイダンスをコンプライアンス要件に合わせるプロセスを短縮します お客様のワークロードで実行されている AWS サービスに基づいて、リスク評価や監査に適用される統制の範囲を決定します 組織での使用を検討している新しい AWS サービスについて、デューデリジェンス評価を実施するお客様を支援します 評価者やリスクチームに、AWS サービスのセキュリティ統制範囲と、お客様が実装する責任のある統制範囲を特定するためのリソースを提供します。これにより、評価や内部セキュリティチェックに必要なエビデンスの範囲が影響を受ける可能性があります 様々なコンプライアンス文書要件を満たすため、または評価エビデンス要求に応えるために必要となる可能性のある、統制対応や手順などのセキュリティ文書を作成するための基礎を提供します AWS グローバルセキュリティ＆コンプライアンスアクセラレーション (GSCA) プログラム は、時間とコストの削減を支援することで、AWS 上でコンプライアンスに準拠したワークロードの構築を導き、自動化し、加速するのに役立つお客様を AWS パートナーとつなぎます。GSCA は、医療、プライバシー、国家安全保障、金融セクターのセキュリティ、プライバシー、コンプライアンス要件を満たす必要があるグローバルに企業をサポートしています。GSCA コンプライアンススペシャリストとつながるには、 GSCA プログラムのアンケート にご記入ください。 このブログに関するご意見やご感想がある場合は、以下の コメント セクションにコメントをお寄せください。このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Kevin Donohue Kevin は AWS ワールドワイドパブリックセクターのシニアセキュリティパートナーストラテジストで、顧客のコンプライアンス目標達成を支援することを専門としています。Kevin は 2019 年に AWS に入社し、AWS セキュリティアシュアランスで米国政府顧客をサポートしてきました。バージニア州北部を拠点とし、仕事以外では妻と娘と一緒に屋外で過ごすことを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました

本ブログは 2024 年 8 月 19 日に公開されたBlog ” Announcing AWS KMS Elliptic Curve Diffie-Hellman (ECDH) support ” を翻訳したものです。 データ保護のために暗号化をする場合、プロトコル設計者は通常、その速度と効率性から対称鍵アルゴリズムを好みます。しかし、インターネットのような信頼されていないネットワーク上でデータを交換する場合、 交換する当事者のみ が同じ鍵を知ることができるようにするのは難しくなります。非対称鍵ペアとアルゴリズムは、公開鍵を信頼されていないネットワーク上で共有できるようにすることで、この問題の解決に役立ちます。そして、鍵共有方式を使用することで、2 つの当事者は、自身の秘密鍵と相手の公開鍵を組み合わせて、同じ共有シークレットを導出できます。 AWS Key Management Service (AWS KMS) が、 楕円曲線 (ECC) KMS キーによる楕円曲線ディフィー・ヘルマン (ECDH) 鍵共有をサポート するようになったことを発表できることを嬉しく思います。新しい DeriveSharedSecret API アクションを使用することで、2 つの当事者間が導出された共有シークレットを使用して安全な通信チャネルを確立できるようになります。 このブログでは、新しい API アクションの概要を説明し、公開鍵のみを交換して共有シークレットを導出することで、安全な通信を確立する方法を解説します。次に、2 つの当事者間で共有シークレットを導出するために AWS KMS と OpenSSL を使用する方法を示すコマンド例を紹介します。 この新しい DeriveSharedSecret API アクションにより、お客様は相手方の公開鍵と AWS KMS 内に存在する秘密鍵を組み合わせて、共有シークレットを導出できます。この共有シークレットは、鍵導出関数 (KDF) を使用して対称暗号化鍵を作成するために使用できます。お客様は、この対称暗号化鍵を使用して、ローカルのアプリケーション内でデータを暗号化できます。 この相手方は、自身の対応する秘密鍵と AWS KMS のお客様の対応する公開鍵を組み合わせて、同じ共有シークレットを導出することができます。 2つの当事者が同じ共有シークレットを持つようになったので、交換するデータの暗号化と復号に使用できる対称暗号化鍵を生成できます。 DeriveSharedSecret は、お客様がアプリケーション内から自身の秘密鍵を使用するためのシンプルで安全な方法を提供します。これにより、楕円曲線統合暗号化方式 (ECIES) やエンドツーエンド暗号化方式 (E2EE) など、AWS KMS で保護されたキーを使用した新しい非対称暗号のユースケースが可能になります。 AWS KMS DeriveSharedSecret の概要 AWS KMS API リファレンスドキュメント では、 DeriveSharedSecret API アクションについて、さらに詳細に説明しています。次のステップは、API アクションの操作方法に関する大まかな説明です。 キーのタイプに非対称、キーの使用方法に キーアグリーメント (鍵共有) を選択し、サポートされているキー仕様を 1 つ選び、楕円曲線 (ECC) KMS キーを作成します。既存の ECC キーをキーアグリーメント用に変更することはできません。 相手方に、あなたの KMS キーに定義したキー仕様に一致する ECC キーを作成してもらいます。 既存の GetPublicKey API アクションを使用して、KMS キーに関連付けられた公開鍵を取得します。 信頼できる方法を通じて、相手方と公開鍵を交換します。 DeriveSharedSecret では、公開鍵を base64 エンコードされた DER 形式にしてください。 相手方の公開鍵と、指定した キーアグリーメント 用キーを、入力値として使用して共有シークレットを導入します。AWS KMS が現時点でサポートする鍵共有アルゴリズムは ECDH です。 相手方は、AWS KMS から取得した公開鍵と、生成した ECC キーペアに関連付けられた秘密鍵を使用して、共有シークレットを導出します。 前述のステップの結果、両者は秘密情報を交換することなく同じ出力を得ることができます。2 つの当事者の間で交換されたのは公開鍵のみです。 DeriveSharedSecret の出力は未加工の共有シークレットです。この共有シークレットは楕円曲線上の点の積であり、暗号鍵に必要なバイト数をはるかに超える可能性があります。暗号鍵をこの共有シークレットから導出するために、 米国国立標準技術研究所 (NIST) SP800-56A Rev. 3 のセクション 5.8 のガイダンスに従って、KDF (鍵導出関数) を使用することをお勧めします。 本ブログでは、 AWS CLI と OpenSSL コマンドラインを使用してこの手順を説明します。AWS Encryption SDK は本ブログでは詳しく説明しませんが、お客様のためのベストプラクティスを組み込んでいますので、 AWS KMS ECDH キーリング もあわせてご確認ください。 ユースケース例 ECDH 鍵共有を使用したい例として、エンドツーエンド暗号化が挙げられます。セキュアな通信のためのフレームワークを提供するプロトコルは存在しますが（例えば AWS Wickr 内など）、ここではこれらのプロトコルの背後にある簡略化された主要なステップを紹介します。この例では、Alice と Bob は両方ともメッセージングネットワークの一部です。 このネットワークは中央管理型のサービスによって管理されており、このサービスは Alice や Bob の暗号化されていないメッセージにアクセスできてはいけません。 図 1 ：ユースケース例で説明されているサービスの高レベルアーキテクチャ 図 1 に示すように、Alice と Bob はそれぞれ ECC キーペアを持ち、以下のステップで ECDH を使用して共有シークレットの導出を行います： Alice は、中央集中型キーストレージサービスに自身の公開鍵を登録します。キーストレージサービスの詳細な説明は、このブログでは扱いません。 Bob は、AWS KMS ユーザーであるため、AWS KMS の GetPublicKey アクションを呼び出して、ECC KMS キーペアの公開鍵を取得します。 Bob は、同じ中央集中型キーストレージサービスに自身の公開鍵を登録します。 Aliceは、Bob と暗号化されたメッセージを交換するために、中央集中型キーストレージサービスから Bob の公開鍵を取得します。 Bob は、Alice が彼とコミュニケーションを取りたがっていることを通知され、中央集中型キーストレージサービスから Alice の公開鍵を取得します。 Alice は、Bob の公開鍵と自身の秘密鍵を使用して、自身の暗号プロバイダーを利用して共有シークレットを導出します。 Bob は、Alice の公開鍵と自身の秘密鍵を使用して、 DeriveSharedSecret を利用して共有シークレットを導出します。 Alice と Bob は、同一の共有シークレットを持つことになります。この共有シークレットから、適切な KDF を使用して対称暗号化鍵を作成できます。この暗号鍵を使用して、Bob に送信可能な暗号文を作成できます。 ユースケース例の詳細な解説 AWS KMS を使用して ECDH 用の KMS キーを作成し、共有シークレットを導出するには、以下の手順を使用できます。説明のために、例として挙げたユースケースでは、ユーザー Alice は暗号化ツールとして OpenSSL を使用しています。以下に、AWS KMS ユーザーの Bob と OpenSSL ユーザーの Alice が、お互いの公開鍵を使用して共有シークレットを導出する方法を説明します。 一般的な前提条件 このサンプルソリューションを実装するには、以下の前提条件を満たしている必要があります： AWS CLI — 最新バージョンを推奨します。ここでの例では aws-cli/2.15.40 および aws-cli/1.32.110 を使用しています。 OpenSSL — ここでの例では OpenSSL 3.3.0 を使用しています。 両当事者（この例で使用するユースケースの Alice と Bob）が同じ楕円曲線暗号の ECC キーを持っています。次のセクション キー作成の事前準備 のステップで、これらのキーの作成方法を説明します。 キー作成の前提条件 Alice と Bob は、鍵生成時に同じ楕円曲線暗号を使用する必要があります。 DeriveSharedSecret API オペレーションは、ECC_NIST_P256、ECC_NIST_P384、ECC_NIST_P521 の楕円曲線に対応しており、これらは OpenSSL ではそれぞれ P-256、P-384、P-521 に対応します。AWS KMS がサポートする楕円曲線は、米国国立標準技術研究所 (NIST) によって承認された暗号化アルゴリズムです。AWS 中国リージョン の AWS KMS は SM2 キー仕様のみサポートしています。 Bob は鍵共有の目的で KMS の非対称キーを作成 Bob は AWS KMS で CreateKey API アクションを使用してキーペアを作成します。次の例では、Bob は KeySpec パラメータに ECC_NIST_P256 を、 KeyUsage パラメータに KEY_AGREEMENT を指定して ECC キーペアを作成します。 aws kms create-key \ --key-spec ECC_NIST_P256 \ --key-usage KEY_AGREEMENT \ --description "Example ECDH key pair" レスポンスは以下のようになります： { "KeyMetadata": { "AWSAccountId": "111122223333", "KeyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "Arn": "arn:aws:kms:us-east-1:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "CreationDate": "2024-06-25T13:06:24.888000-07:00", "Enabled": true, "Description": "Example ECDH key pair", "KeyUsage": "KEY_AGREEMENT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "ECC_NIST_P256", "KeySpec": "ECC_NIST_P256", "KeyAgreementAlgorithms": [ "ECDH" ], "MultiRegion": false } } ドキュメントの 非対称 KMS キーの作成 では、 AWS マネジメントコンソール を使用して、上記 CLI で作成した同じプロパティを持つ KMS キーペアを作成する方法が説明されています。このサンプルでは、デフォルトの KMS キーポリシー を持つ KMS キーを作成しますが、お使いの環境に適した最小権限の原則に従って、キーポリシーを確認し、設定することを推奨します。 注: KMS キーが作成されると、アカウント内のアクティビティを監視し記録するサービスである AWS CloudTrail によってログに記録されます。AWS KMS サービスへの API コールは CloudTrail にログとして記録され 、これを使用して KMS キーへのアクセスを監査できます。 KMS キーを KeyId の値ではなく人間が読みやすい文字列で識別できるようにするために、 KMS キーにエイリアスを作成 できます（ target-key-id の値 a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 を、ご自身の KeyId の値に置き換えてください）。エイリアスにより、KMS キーをより簡単に使用・管理できるようになります。 Bob は以下の CLI コマンドを使用して、KMS キーのエイリアスを作成します： aws kms create-alias \ --alias-name alias/example-ecdh-key \ --target-key-id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 Alice は OpenSSL を使用して、鍵共有のための ECC 鍵を作成 OpenSSL の ecparam および genkey オプションを使用して、Alice は P-256 ECC キーを作成します。P-256 楕円曲線は、AWS KMS では ECC_NIST_P256 となります。 注: ECDH が機能するためには、OpenSSL の ECC キーの楕円曲線が、相手方（この例では Bob）が作成した ECC KMS キーと同じ楕円曲線暗号である必要があります。 openssl ecparam -name P-256 \ -genkey -out openssl_ecc_private_key.pem 以上で、事前準備のキー作成は完了です。 鍵交換と共有シークレット導出プロセス このセクションでは、Alice と Bob は公開鍵を共有し、お互いの公開鍵を取得し、同じ共有シークレットを導出する手順を概説します。Alice と Bob それぞれが導出した共有シークレットを比較し、両者が同じ共有シークレットを導出したことを説明します。 ステップ 1: Alice による OpenSSL 公開鍵の生成と中央サービスへの登録 AWS KMS では 公開鍵は DER 形式ある必要があります。そのため、この例では Alice は自身の ECC 秘密鍵を使用して、以下の CLI コマンドで DER 形式の公開鍵を作成します。 openssl ec -in openssl_ecc_private_key.pem \ -pubout -outform DER \ > openssl_ecc_public_key.bin.der 生成されたファイルの openssl_ecc_public_key.bin.der は DER 形式の公開鍵です。Alice はこれを中央集中型キーストレージサービスに保存する(または通信したい相手に送信する)ことができます。中央集中型キーストレージサービスの詳細については、このブログでは扱いません。 ステップ 2: Bob が ECC KMS キーの公開鍵を取得 Bob は、ECC KMS キーの公開鍵を取得するために、 GetPublicKey API アクションを使用します。Bob は、以下のように AWS CLI コマンド get-public-key を使用してこの API を呼び出します。 aws kms get-public-key \ --key-id alias/example-ecdh-key \ --output text \ --query PublicKey | base64 --decode > kms_ecdh_public_key.der AWS CLI コマンドで PublicKey をクエリした値は、DER 形式の X.509 公開鍵で、可読性のために base64 でエンコードされています。この base64 エンコードされた値を base64 コマンドでデコードし、デコードされた値を、ファイル kms_ecdh_public_key.der に出力しています 注: Boto3 などの AWS SDK のいずれかを使用してこの API を呼び出す場合、返される PublicKey の値は base64 エンコードされていません。 このユースケース例では、Alice は OpenSSL を使用しており、PEM 形式の公開鍵が必要です。Bob は、次のコマンドを用いて DER 形式の公開鍵を PEM 形式に変換します。 openssl ec -pubin -inform DER -outform PEM \ -in kms_ecdh_public_key.der \ -out kms_ecdh_public_key.pem kms_ecdh_public_key.pem ファイルは、PEM 形式の公開鍵です。 ステップ 3: Bob が公開鍵を中央集中型キーストレージサービスに登録 Bob は、ステップ 2 で取得した PEM 形式の公開鍵を、中央集中型キーストレージサービスに保存します。 ステップ 4: Alice が共有シークレット導出のために Bob の公開鍵を取得 ECDH 鍵共有を実行するには、関係する 2 つの当事者 (この例では Alice と Bob) が互いに公開鍵を交換する必要があります。Alice は、Bob に暗号化されたメッセージを送信するために、中央集中型キーストレージサービスから Bob の公開鍵を取得します。 Bob の公開鍵である kms_ecdh_public_key.pem は、すでに OpenSSL が想定する PEM 形式になっています。 ステップ 5: Bob が共有シークレット導出のために Alice の公開鍵を取得 ECDH 鍵共有を実行するには、関係する 2 つの当事者、Alice と Bob が互いに公開鍵を交換する必要があります。Bob は Alice が彼と通信したいという通知を受け取り、中央集中型キーストレージサービスから Alice の公開鍵を取得します。 Alice の公開鍵である openssl_ecc_public_key.bin.der は、AWS KMS が想定する DER 形式にすでになっています。 ステップ 6: Alice による OpenSSL を使用した共有シークレットの導出 Alice は、自身の秘密鍵と Bob の公開鍵を使用して、OpenSSL で共有シークレットを導出できます。Alice は、OpenSSL の pkeyutl コマンドの derive オプションを使用して共有シークレットを導出します openssl pkeyutl -derive \ -inkey openssl_ecc_private_key.pem \ -peerkey kms_ecdh_public_key.pem > openssl.ss openssl.ss ファイルには、共有シークレットがバイナリ形式で格納されます。 ステップ 7: Bob による AWS KMS を使用した共有シークレットの導出 Bob は、自身の秘密鍵 (AWS KMS 内で安全に保管されています) と Alice の公開鍵を使用して、AWS KMS を通じて共有シークレットを導出できます。以下は、Bob が AWS CLI コマンド derive-shared-secret を使用して DeriveSharedSecret API アクションを実行する例です。現時点のサポートされている鍵共有アルゴリズムは ECDH です。 PublicKey パラメータには Alice の公開鍵を渡します。 aws kms derive-shared-secret \ --key-id alias/example-ecdh-key \ --public-key fileb://path/to/openssl_ecc_public_key.bin.der \ --key-agreement-algorithm ECDH \ --output text --query SharedSecret | base64 --decode > kms.ss AWS CLI を使用すると、返された SharedSecret の値は可読性のために base64 エンコードされています。 base64 --decode コマンドを使用して、デコードされたバイナリ形式をファイルに保存します。 注: Boto3 などの AWS SDK のいずれかを使用してこの API を呼び出す場合、返される SharedSecret の値は base64 エンコードされていません。 kms.ss ファイルには、バイナリ形式で共有シークレットが含まれます。 ステップ 8: Alice が共有シークレットと適切な KDF を使用して、Bob への通信を暗号化するための暗号鍵を導出 次のコマンドを使用してステップ 6 と 7 でそれぞれ導出した共有シークレットの 2 つのファイルを比較し、同一であることを確認します diff -qs openssl.ss kms.ss これらのファイルが同一であることから、AWS KMS と OpenSSL の両方を使用して同じシークレットが導出されたことがわかります。 次のステップとして、共有シークレットを使用して、Alice は適切な 鍵導出関数 (KDF) を用いて対称暗号化鍵を導出します。この対称暗号化鍵を使用してデータを暗号化し、暗号文を Bob に送信します。 このブログでは、対称暗号化鍵を導出するステップについては説明しません。これは、ユースケースによっては複雑なトピックになる可能性があるためです。ただし、生の共有シークレットは均一ではないため、暗号鍵として使用しないでください。共有シークレットには多くのエントロピーがありますが、バイト文字列自体はランダムではありません。 NIST は、生の共有シークレット ( NIST SP800-56A Rev. 3 のセクション 5.8 で説明されている値 Z) に対して KDF を使用することを推奨しています。推奨される KDF については、 NIST SP800-56C Rev. 2 でより詳細に説明されています。その一例として、OpenSSL Single Step KDF (SSKDF) EVP_KDF-SS がありますが、この KDF を使用する際は、 FixedInfo などの他の値を慎重に選択する必要があります。 お客様が共有シークレットに対して使用する適切な KDF を選択できるよう、AWS Encryption SDK に AWS KMS ECDH キーリング が追加されました。キーリングは、コード内に実装する AWS Encryption SDK 内の構成要素です。キーリングは、データを保護するためのベストプラクティスを適用しながら、暗号鍵の管理を処理します。キーリングを使用して、鍵交換のための KMS キーを参照し、データを暗号化する関数を呼び出すことができます。データは NIST の推奨に従って導出された共有ラッピングキーを使用して暗号化され、Encryption SDK は暗号文に キーコミットメント を適用します。 まとめ このブログでは、2024 年 8 月に一般利用が開始された DeriveSharedSecret API アクションを使用して、安全に共有シークレットを導出する方法を紹介しました。信頼できないネットワーク上で秘密情報を共有することなく、2 つの当事者間で ECDH を使用する方法を説明しました。AWS CloudTrail ログを通じて AWS KMS キーの使用状況を追跡こともできます。共有シークレットから対称暗号化鍵を生成するには、KDF を使用する必要があることを述べました。データの暗号化には AWS Encryption SDK の使用を強くお勧めします。これは、対称暗号化鍵の生成に推奨される NIST の鍵導出関数 (KDF) を確実に使用します。 この投稿に関するフィードバックがある場合は、以下の コメント セクションにコメントを投稿してください。この投稿に関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Patrick Palmer Patrick は AWS のプリンシパルセキュリティスペシャリストソリューションアーキテクトです。世界中のお客様が AWS サービスを安全に使用できるよう支援し、暗号技術を専門としています。仕事以外では、成長する家族と過ごす時間とビデオゲームを楽しんでいます。 Raj Puttaiah Raj は AWS KMS のソフトウェア開発マネージャーです。運用の卓越性に焦点を当てて、AWS KMS の機能開発をリードしています。仕事以外では、ワシントン州の美しい自然の中で家族とハイキングを楽しんだり、2 人の息子の活動に同行したりして時間を過ごしています。 Michael Miller Michael はアイルランドを拠点とする AWS のシニアソリューションアーキテクトです。英国とアイルランドの公共部門のお客様のクラウド導入を加速させるのを支援し、セキュリティとネットワーキングを専門としています。以前の役職では、サービスプロバイダー、コンサルティング、金融サービス組織など、さまざまな分野でのアーキテクチャ設計と実装支援を担当してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2024/09/09 に投稿された Life Sciences Industry Guide to AWS re:Invent 2024 | AWS for Industries  を翻訳した記事です。 2024 年は、ヘルスケアとテクノロジーの岐路に立つイノベーションにとって歴史の残る年となります。 AWS re:Invent 2024 が近づくにつれ、業界のパイオニアと AWS の専門家が、生成 AI、機械学習、高度なデータ戦略によって促進されるテクノロジー、ユースケース、ブレークスルーを紹介する態勢を整えています。 2024 年 12 月 2 日から 6 日にかけてラスベガスで開催される今年のカンファレンスは、何百ものセッションにわたる豊富な知識を提供します。「2024 年：生成 AI の成果の年」をテーマにした Healthcare and Life Sciences (HLS) industry track  では、Merck, Geisinger, Gilead, Natera, Elevance Health などの業界リーダーからの洞察を取り上げます。 Come learn and build with us! 参加は こちらから登録 していただけます。 AWS re: Invent に参加すると、このようなことができます： 生成 AI を実際のヘルスケア・ライフサイエンスユースケースに適用して、ビジネスの様々な側面を変革するスキルを身につける ヘルスケア・ライフサイエンス向け専用の最新のソリューションについて知る AWS の専門家や同業他社とのネットワーキングを行う 今すぐ組織に適用できる、実用的な知識やベストプラクティスを学び持ち帰る 週の締めくくりには、最高のテクノロジーパーティーで成果を祝いましょう！ 参加に興味が湧いてきましたか？参加のためには次のことを行ってください： re: Invent についてより詳しく知るためには、 re:Invent website  を参照してください HLS Industry guide を確認し、関心のあるセッションを特定、アジェンダを計画しましょう   HLS Pavilion at the re:Invent Expo Hall ( Venetian Hall B ) を訪れて、最新の生成 AI デモを体験してください。また、2人の非常に特別な小児患者によってデザインされた限定版のピンを手に入れましょう！ おすすめセッション：ライフサイエンス ここからは、ライフサイエンスセッション参加者向けに厳選されたセッションをご覧ください。おすすめヘルスケアセッションについては、 healthcare industry guide to AWS re:Invent 2024  をご覧ください。 イノベーショントーク イノベーショントークでは、AWS の専門家がデータ、生成 AI、クラウド運用、モダナイゼーションなどの重要なトピックについて意見を交わします。 HLC201-INT | Accelerating healthcare & life sciences innovation with generative AI（生成 AI によるヘルスケアとライフサイエンスのイノベーションの加速） 12/5 (木) 12:30 PM – 1:30 PM (太平洋標準時) | Venetian, Level 5, Palazzo Ballroom B ブレイクアウトセッション ブレイクアウトセッションでは 60 分の講義形式のセッションを行います。この幅広い魅力は多くの聴衆に配信されます。セッションは録画されるため、見逃した場合は、re: Invent の後にオンデマンドで視聴できます。 HLS215 | How Merck improves drug design with biological foundation models）（Merck が生物学的基盤モデルを使用して医薬品設計を改善する方法） 12/3 (火) 12:00 PM – 1:00 PM (太平洋標準時) | Wynn, Upper Level, Cristal 7 HLS206 | Scale clinical diagnostic operations: Natera’s genomic innovation（大規模な臨床診断業務：Natera のゲノムイノベーション） 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | Wynn, Level 1, Latour 2 IOT204-S | Transform troubleshooting in manufacturing with AWS gen AI services (sponsored by Cognizant)（AWS 生成 AI サービスで製造業のトラブルシューティングを変革しましょう） 12/2 (月) 11:30 AM – 12:30 PM (太平洋標準時) | Venetian, Level 3, Murano 3305 MAM214 | Gilead Sciences: Executing a large-scale VMware transformation on AWS（Gilead Sciences：AWS での大規模な VMware トランスフォーメーションの実行） 12/2 (月) 4:30 PM – 5:30 PM (太平洋標準時) | MGM, Level 1, Grand 122 BIZ220 | How Moderna Is building a healthier supply chain（Moderna 社がより健全なサプライチェーンを構築する方法） 12/2 (月) 2:30 PM – 3:30 PM (太平洋標準時) | MGM, Level 3, Chairmans 366 CMP203 | Drive innovation and results with high performance computing on AWS（AWS でのハイパフォーマンスコンピューティングによるイノベーションと成果の促進） 12/3 (火) 12:00 PM – 1:00 PM (太平洋標準時) | Venetian, Level 3, Lido 3002 PRO203 | Merck advances healthcare data extraction using text-to-SQL on AWS（Merck、AWS で text-to-SQL 変換で医療データ抽出を推進） 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | MGM, Level 3, Premier 318 PRO302 | Gilead Sciences: Operational excellence for cloud, data, and AI/ML（Gilead Sciences：クラウド、データ、AI/ML のオペレーショナル・エクセレンス） 12/4 (水) 10:00 AM – 11:00 AM (太平洋標準時) | Caesars Forum, Level 1, Summit 232, Content Hub, Pink AIM255-S | Transforming the future of life sciences R&D with generative AI (sponsored by Accenture)（生成 AI でライフサイエンス研究開発の未来を変える） 12/4 (水) 11:30 AM – 12:30 PM (太平洋標準時) | Venetian, Level 3, Murano 3305 ビルダーセッション 60 分間のビルダーセッションでは、AWS の専門家が指導し、AWS での構築に関する実践的な学習を提供します。これには簡単なデモンストレーションと、それに続くガイド付きの実践体験が含まれます。ご自身のラップトップを持参してご参加ください。 HLS204 | Streamlining clinical protocol reviews with Amazon Q Business（Amazon Q Business による臨床プロトコルレビューの効率化） 12/2 (月) 10:30 AM – 11:30 AM (太平洋標準時) | Wynn, Level 1, Lafite 4, Builders’ 1 12/2 (月) 4:30 PM – 5:30 PM (太平洋標準時) | Wynn, Level 1, Lafite 4, Builders’ 1 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | Wynn, Level 1, Latour 7 STG317 | Use your own proprietary data to build customized generative AI apps（あなた独自のデータを使用し、カスタマイズされた生成 AI アプリケーションを構築） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) | Caesars Forum, Level 1, Alliance 315 ワークショップ ワークショップは、参加者がグループに分かれて作業し、AWS を使用する際の問題の解決策を 2 時間で構築するインタラクティブなハンズオンセッションです。ご自身のラップトップを持参してご参加ください。 HLS205 | Building scalable drug discovery applications（スケーラブルな創薬アプリケーションの構築） 12/2 (月) 3:30 PM – 5:30 PM (太平洋標準時) | Wynn, Level 1, Margaux 2 HYB304 | Implement RAG without compromising on digital sovereignty（デジタル主権を損なうことなく RAG を実装する） 12/2 (月) 8:00 AM – 10:00 AM (太平洋標準時) | Caesars Forum, Level 1, Summit 228 HYB305 | Cutting-edge AI: Real-time anomaly detection and forecasting（最先端の人工知能：リアルタイムの異常検出と予測） 12/4 (水) 9:00 AM – 11:00 AM (太平洋標準時) | Caesars Forum, Level 1, Summit 216 チョークトーク チョークトークは、AWS の専門家による少人数向けの 60 分間の講義です。実用的なアーキテクチャの課題に関する技術的な議論を促進するための、インタラクティブなホワイトボードセッションがあります。 HLS209 | Migrating regulated workloads on to AWS at scale（規制対象のワークロードを AWS に大規模に移行） 12/2 (月) 8:30 AM – 9:30 AM (太平洋標準時) | MGM, Level 1, 102 12/2 (月) 4:00 PM – 5:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 HLS201 | End-to-end biological foundation model workflows for drug discovery（創薬のためのエンドツーエンドの生物学的基盤モデルワークフロー） 12/4 (水) 8:30 AM – 9:30 AM (太平洋標準時) | Mandalay Bay, Level 3, South Convention Center , South Seas C 12/5 (木) 2:00 PM – 3:00 PM (太平洋標準時) | MGM, Level 1, 102 HLS303 | Accelerate cancer biomarker discovery with Amazon Bedrock Agents（Amazon Bedrock Agents で癌バイオマーカーの発見を加速） 12/2 (月) 1:00 PM – 2:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 12/4 (水) 1:00 PM – 2:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 CMP412 | High performance computing is a capacity challenge. We have solutions.（ハイパフォーマンスコンピューティングは容量に関する課題。私たちには解決策があります。） 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | Caesars Forum, Level 1, Academy 416 CMP406 | Making HPC and other R&D workloads accessible beyond the AWS console（HPC やその他の研究開発ワークロードを AWS コンソールからアクセスできるように） 12/3 (火) 1:00 PM – 3:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 CMP326 | Accelerate AI innovation for healthcare and life sciences on AWS（AWS でヘルスケアとライフサイエンスのための AI イノベーションを加速） 12/4 (水) 10:30 AM – 11:30 AM (太平洋標準時) | Mandalay Bay, Level 3, South Convention Center, South Seas D HYB310 | Addressing data residency requirements with hybrid and edge services（ハイブリッドサービスとエッジサービスによるデータレジデンシー要件への対応） 12/4 (水) 8:30 AM – 9:30 AM (太平洋標準時) | MGM, Level 1, Boulevard 158 ライトニングトーク ライトニングトークは、エキスポホールで開催される 20 分間のシアタープレゼンテーションです。特定のお客様事例、サービスデモ、AWS パートナーサービスなどに特化してお話しします。 AIM242-S | Agentic AI and journey to gen AI value realization (Sponsored by ZS)（AI Agent と生成 AI の価値実現への道のり） MAM234-S | Cloud Transformation: Merck’s proven modernization factory model (Sponsored by HCLTech)（クラウド・トランスフォーメーション：Merck の実績あるモダナイゼーション・ファクトリー・モデル） PEX214 | AWS Partners accelerating industry modernization through LoB（LoB を通じて業界の近代化を加速している AWS パートナー） AIM247-S | Data’s renaissance: Gen AI and the new value of data (sponsored by ZS)（データのルネッサンス：生成 AI とデータの新しい価値） [注 : イベントカタログにセッションが増え次第、さらにセッションが追加されます] AWS for Industries Pavilion で AWS の専門家と出会い、アイデアを交換しましょう ヘルスケア・ライフサイエンス向けの最新の生成 AI イノベーションを見て、交流しましょう。AWS の業界サービスとソリューションを直接体験してください。あなたと同じクラウドの旅をしている AWS の専門家や仲間とつながりましょう。 AWS for Industries Pavilion 営業時間 (太平洋標準時) : 12/2 (月) 4:00 PM – 7:00 PM 12/3 (火) 10:00 AM – 6:00 PM 12/4 (水) 10:00 AM – 6:00 PM 12/5 (木) 10:00 AM – 4:00 PM パビリオンで予定されている生成 AI デモは以下の通りです： 生成 AI による創薬の変革 生成 AI による臨床試験の変革 生成 AI による患者と臨床医の体験の変革 さらに、 Undiagnosed Diseases Network  および John Hopkins 小児センターと提携して、小児患者さんがデザインした限定版のピンを配布します。未診断の病気と闘っている 11 歳のクーパーと拡張型心筋症の 7 歳のハナがデザインしたピンは、クラウドベースのイノベーションが患者に与え続けている影響を象徴的に思い出させてくれます。ベネチアンのヘルスケア＆ライフサイエンスエキスポパビリオンに立ち寄って、ピンを集めましょう。 それでは、ラスベガスでお会いできるのを楽しみにしています！ ヘルスケアとライフサイエンスの新時代を今すぐ開拓する方法の詳細については、 AWS for Healthcare and Life Sciences  をご覧ください。 おすすめヘルスケアセッションについては、 healthcare industry guide to AWS re:Invent 2024  をご覧ください。 Oiendrilla Das Oiendrilla Das は、AWS のライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリーダーです。彼女はライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。Oiendrilla はマーケティングの MBA 学位を取得しており、MBA を取得する前にバイオテクノロジーのエンジニアリングを修了しました。 Jennifer Rouse Jennifer Rouse は、AWS のヘルスケアマーケティングのワールドワイドヘッドです。IBM や Cisco などの大企業や、2 つのクラウドベースのスタートアップで指導的役割を果たしてきました。直近では、Forrester Research/Sirius Decisions のグローバルアナリスト兼アドバイザーを務めました。彼女は、公共部門など、これまでサービスが行き届いていなかった業界で変化をもたらす企業でキャリアの多くを過ごしてきました。公共部門での経験から、医療、公共安全、教育、政府機関における人生を変える多くのテクノロジープログラムに取り組んできました。 Ryan Greene Ryan Greene は、AWS のグローバルヘルスケア及びライフサイエンスチームのシニアプロダクトマーケティングマネージャーです。ビルダーとしての考え方と、チームの運営方法を変革したいという情熱を持った彼は、複雑な問題に大規模に取り組むことを好みます。彼は 2 人の幼い子供たちからやる気を引き出し、革新的なアプローチを活用して世界で最も大規模な顧客の課題や作業負荷に対処することへのプロとしての関心を高めています。

本記事は 2024/10/01 に投稿された Healthcare Industry Guide to AWS re:Invent 2024 | AWS for Industries  を翻訳した記事です。 2024 年は、ヘルスケアとテクノロジーの岐路に立つイノベーションにとって歴史の残る年となります。 AWS re:Invent 2024 が近づくにつれ、業界のパイオニアと AWS の専門家が、生成 AI、機械学習、高度なデータ戦略によって促進されるテクノロジー、ユースケース、ブレークスルーを紹介する態勢を整えています。 2024 年 12 月 2 日から 6 日にかけてラスベガスで開催される今年のカンファレンスは、何百ものセッションにわたる豊富な知識を提供します。「2024 年：生成 AI の成果の年」をテーマにした Healthcare and Life Sciences (HLS) industry track  では、TriZetto、Froedtert Health、Geisinger などの業界リーダーからの洞察を取り上げます。 Come learn and build with us! 参加は こちらから登録 していただけます。 AWS re: Invent に参加すると、このようなことができます： 生成 AI を実際の医療ユースケースに適用して、ビジネスの様々な側面を変革するスキルを身につける ヘルスケア向け専用の最新のソリューションについて知る AWS の専門家や同業他社とのネットワーキングを行う 今すぐ組織に適用できる、実用的な知識やベストプラクティスを学び持ち帰る 週の締めくくりには、最高のテクノロジーパーティーで成果を祝いましょう！ 参加に興味が湧いてきましたか？参加のためには次のことを行ってください： re: Invent についてより詳しく知るためには、 re:Invent website  を参照してください HLS Industry guide を確認し、関心のあるセッションを特定、アジェンダを計画しましょう   HLS Pavilion at the re:Invent Expo Hall  ( Venetian Hall B ) を訪れて、最新の生成 AI デモを体験してください。また、2人の非常に特別な小児患者によってデザインされた限定版のピンを手に入れましょう！ おすすめセッション：ヘルスケア ここからは、ヘルスケアセッション参加者向けに厳選されたセッションをご覧ください。おすすめライフサイエンスセッションについては、 life sciences industry guide to AWS re:Invent 2024  をご覧ください。 イノベーショントーク イノベーショントークでは、AWS の専門家がデータ、生成 AI、クラウド運用、モダナイゼーションなどの重要なトピックについて意見を交わします。 HLC201-INT | Accelerating healthcare & life sciences innovation with generative AI（生成 AI によるヘルスケアとライフサイエンスのイノベーションの加速） 12/5 (木) 12:00 PM – 1:30 PM（太平洋標準時） WPS202-INT | WWPS pre-keynote address: Igniting innovation for a better tomorrow（WWPS 基調講演前の講演：より良い未来のためのイノベーションの火付け役） 12/3 (火) 1:30 PM – 2:00 PM (太平洋標準時) ブレイクアウトセッション ブレイクアウトセッションでは 60 分の講義形式のセッションを行います。この幅広い魅力は多くの聴衆に配信されます。セッションは録画されるため、見逃した場合は、re: Invent の後にオンデマンドで視聴できます。 HLS208 | Accelerate healthcare innovation: TriZetto’s data-powered approach（ヘルスケアイノベーションを加速：TriZetto のデータ活用型アプローチ） 12/5 (木) 12:30 PM – 1:30 PM (太平洋標準時) HLS214 | Froedtert Health transforms patient engagement with generative AI（Froedtert Health は生成 AI で患者エンゲージメントを変革します） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) HLS207 | Geisinger’s epic journey: Scaling EHR operations on AWS（Geisinger の壮大な道のり：AWS での EHR オペレーションのスケーリング） 12/3 (火) 1:30 PM – 2:30 PM (太平洋標準時) NTA310 | HIPAA-compliant IVD SaaS: Werfen’s global AWS solution journey（HIPAA 準拠の IVD SaaS：Werfen のグローバル AWS ソリューションジャーニー） 12/4 (水) 4:00 PM – 5:00 PM (太平洋標準時) IDE104 | Inclusive wellness: Leveraging Amazon One Medical for LGBTQIA+ care（インクルーシブ・ウェルネス：アマゾン・ワン・メディカルを LGBTQIA+ のケアに活用） 12/4 (水) 10:00 AM – 11:00 AM (太平洋標準時) HYB201 | AWS wherever you need it: From the cloud to the edge（AWS 必要な場所ならどこでも：クラウドからエッジまで） 12/2 (月) 1:00 PM – 2:00 PM (太平洋標準時) MKT104 | Transform healthcare outcomes with AWS Marketplace（AWS マーケットプレイスで医療成果を変革） 12/2 (月) 12:00 PM – 1:00 PM (太平洋標準時) SEC224-S | Data security in the cloud, from Xsolis, an AI leader in healthcare (sponsored by Trend Micro)（ヘルスケアの AI リーダーである Xsolis が提供する、クラウド内のデータセキュリティ） 12/5 (木) 2:00 PM – 3:00 PM (太平洋標準時) ARC212-S | How Cambia supercharged their Amazon EKS based platform (sponsored by Datadog)（Cambia が Amazon EKS ベースのプラットフォームをどのように強化したか） 12/3 (火) 11:30 AM – 12:30 PM (太平洋標準時) ビルダーセッション 60 分間のビルダーセッションでは、AWS の専門家が指導し、AWS での構築に関する実践的な学習を提供します。これには簡単なデモンストレーションと、それに続くガイド付きの実践体験が含まれます。ご自身のラップトップを持参してご参加ください。 HLS203 | Enhancing patient and clinician experiences with AWS HealthScribe（AWS HealthScribe による患者と臨床医のエクスペリエンスの向上） 12/4 (水) 1:30 PM – 2:30 PM (太平洋標準時) STG317 | Use your own proprietary data to build customized generative AI apps（あなた独自のデータを使用し、カスタマイズされた生成 AI アプリケーションを構築） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) ワークショップ ワークショップは、参加者がグループに分かれて作業し、AWS を使用する際の問題の解決策を 2 時間で構築するインタラクティブなハンズオンセッションです。ご自身のラップトップを持参してご参加ください。 HLS202 | Amazon Q Apps for healthcare （ヘルスケア向け Amazon Q アプリ） 12/5 (木) 3:30 PM – 5:30 PM (太平洋標準時) AIM315 | Transforming intelligent document processing with generative AI（生成 AI によるインテリジェントな文書処理の変革 12/2 (月) 8:00 AM – 10:00 AM (太平洋標準時) IOT315 | Transforming healthcare with IoT, Amazon Location, and generative AI（ IoT、アマゾンロケーション、生成 AI によるヘルスケアの変革） 12/4 (水) 3:00 PM – 5:30 PM (太平洋標準時) チョークトーク チョークトークは、AWS の専門家による少人数向けの 60 分間の講義です。実用的なアーキテクチャの課題に関する技術的な議論を促進するための、インタラクティブなホワイトボードセッションがあります。 HLS304 | Accelerate healthcare innovation with real-world data and evidence（現実世界のデータとエビデンスでヘルスケアイノベーションを加速） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) HLS301 | Building an interoperable healthcare data layer with AWS（AWS による相互運用可能な医療データレイヤーの構築） 12/4 (水) 2:30 PM – 3:30 PM (太平洋標準時) HLS302 | Transform clinical apps with gen AI: Netsmart’s AI Data Lab journey（生成 AI による臨床アプリケーションの変革：Netsmart の AI データラボジャーニー） 12/4 (水) 10:00 AM – 11:00 AM (太平洋標準時) HLS305 | Optimize clinical documentation with generative AI: NextGen case study（生成 AI による臨床ドキュメンテーションの最適化：次世代ケーススタディ） 12/4 (水) 2:30 PM – 3:30 PM (太平洋標準時) DEV333 | Automating insurance claims and policy management using generative AI（生成 AI を使用した保険金請求とポリシー管理の自動化） 12/5 (木) 11:30 AM – 12:30 PM (太平洋標準時) CMP326 | Accelerate AI innovation for healthcare and life sciences on AWS（AWS でヘルスケアとライフサイエンスの AI イノベーションを加速） 12/4 (水) 10:30 PM – 11:30 PM (太平洋標準時) HYB310 | Addressing data residency requirements with hybrid and edge services（ハイブリッドサービスとエッジサービスによるデータレジデンシー要件への対応） 12/4 (水) 8:30 AM – 9:30 AM (太平洋標準時) ライトニングトーク ライトニングトークは、エキスポホールで開催される 20 分間のシアタープレゼンテーションです。特定のお客様事例、サービスデモ、AWS パートナーサービスなどに特化してお話しします。 PEX218 | AWS Partner Solutions: AI-based insights transforms radiology workflows（AWS パートナーソリューション：AI ベースの洞察が放射線医学のワークフローを変える） SMB204 | Using generative AI to restore the human connection in medicine（生成 AI を活用して医療における人と人とのつながりを回復させる） PEX207 | The good, teh bad, and the ugly of AI and cybersecurity（AI とサイバーセキュリティの良い点、悪い点、醜い点） PRO208 | Santa Clara County & AWS: Collaborative disease surveillance system（サンタクララ郡と AWS：共同疾病監視システム） SEC103-S | Managing cyber vulnerability in connected healthcare devices (Sponsored by Claroty)（コネクテッドヘルスケア機器におけるサイバー脆弱性の管理） PRO207 | Improving patient care with large-scale data engineering and ML（大規模データエンジニアリングと機械学習による患者ケアの向上） AIM242-S | Agentic AI and the journey to gen AI value realization (sponsored by ZS)（エージェント AI と生成 AI の価値実現への道のり） [注 : イベントカタログにセッションが増え次第、さらにセッションが追加されます] AWS for Industries Pavilion で AWS の専門家と出会い、アイデアを交換しましょう ヘルスケア・ライフサイエンス向けの最新の生成 AI イノベーションを見て、交流しましょう。AWS の業界サービスとソリューションを直接体験してください。あなたと同じクラウドの旅をしている AWS の専門家や仲間とつながりましょう。 AWS for Industries Pavilion 営業時間 (太平洋標準時) : 12/2 (月) 4:00 PM – 7:00 PM 12/3 (火) 10:00 AM – 6:00 PM 12/4 (水) 10:00 AM – 6:00 PM 12/5 (木) 10:00 AM – 4:00 PM パビリオンで予定されている生成 AI デモは以下の通りです： 生成 AI による創薬の変革 生成 AI による臨床試験の変革 生成 AI による患者と臨床医の体験の変革 さらに、 Undiagnosed Diseases Network  および John Hopkins 小児センターと提携して、小児患者さんがデザインした限定版のピンを配布します。未診断の病気と闘っている 11 歳のクーパーと拡張型心筋症の 7 歳のハナがデザインしたピンは、クラウドベースのイノベーションが患者に与え続けている影響を象徴的に思い出させてくれます。ベネチアンのヘルスケア＆ライフサイエンスエキスポパビリオンに立ち寄って、ピンを集めましょう。 それでは、ラスベガスでお会いできるのを楽しみにしています！ ヘルスケアとライフサイエンスの新時代を今すぐ開拓する方法の詳細については、 AWS for Healthcare and Life Sciences  をご覧ください。 おすすめライフサイエンスセッションについては、 life sciences industry guide to AWS re:Invent 2024  をご覧ください。 Oiendrilla Das Oiendrilla Das は、AWS のライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリーダーです。彼女はライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。Oiendrilla はマーケティングの MBA 学位を取得しており、MBA を取得する前にバイオテクノロジーのエンジニアリングを修了しました。 Jennifer Rouse Jennifer Rouse は、AWS のヘルスケアマーケティングのワールドワイドヘッドです。IBM や Cisco などの大企業や、2 つのクラウドベースのスタートアップで指導的役割を果たしてきました。直近では、Forrester Research/Sirius Decisions のグローバルアナリスト兼アドバイザーを務めました。彼女は、公共部門など、これまでサービスが行き届いていなかった業界で変化をもたらす企業でキャリアの多くを過ごしてきました。公共部門での経験から、医療、公共安全、教育、政府機関における人生を変える多くのテクノロジープログラムに取り組んできました。 Ryan Greene Ryan Greene は、AWS のグローバルヘルスケア及びライフサイエンスチームのシニアプロダクトマーケティングマネージャーです。ビルダーとしての考え方と、チームの運営方法を変革したいという情熱を持った彼は、複雑な問題に大規模に取り組むことを好みます。彼は 2 人の幼い子供たちからやる気を引き出し、革新的なアプローチを活用して世界で最も大規模な顧客の課題や作業負荷に対処することへのプロとしての関心を高めています。

2024 年 2 月に 更新された原文を日本語版として 9 月に反映しました： この記事は、コストベースの最適化とクエリ結果の再利用を含む Amazon Athena エンジンバージョン 3 の変更を反映するために確認および更新されました。 Amazon Athena は、オープンソースのフレームワークに基づいた対話型分析サービスで、標準の SQL を使って Amazon Simple Storage Service (Amazon S3) に格納されたオープンテーブルおよびファイル形式のデータを簡単に分析できます。Athena はサーバーレスなので、インフラストラクチャの管理は不要で、実行したクエリに対してのみ料金を支払います。Athena は使いやすく、Amazon S3 内のデータを指定し、スキーマを定義すれば、標準 SQL を使ってクエリを実行できます。 この投稿では、クエリのパフォーマンスを向上させるためのヒントのトップ10を紹介します。Amazon S3 への データ保存 とクエリ特有の チューニング に関連する側面に焦点を当てます。 ストレージ 本セクションでは、Athena で最大限の効果を得るためのデータの構造化方法について紹介します。Amazon S3 にデータを保存する場合、同じ実践方法を Amazon EMR のデータ処理アプリケーション (Spark、Trino、Presto、Hive など) にも適用できます。以下のベストプラクティスについて説明します。 データのパーティション分割 データのバケット化 圧縮の利用 ファイルサイズの最適化 列指向のファイル形式の利用 1. データのパーティション分割 パーティション分割は、テーブルを論理的なパーティションに分割し、日付、国、地域などのカラム値に基づいて関連するデータを同じパーティションに格納します。パーティションは仮想的な列として機能します。パーティションはパーティション値に基づいてデータが論理的に区分されます。テーブル作成時にパーティションを定義し、クエリごとにスキャンするデータ量を減らすことで、パフォーマンスが向上します。パーティションに基づいたフィルタを指定することで、クエリでスキャンするデータ量を制限できます。詳細は、 Partitioning data in Athena をご覧ください。 次の例は、S3 バケットに年ごとにパーティション分割されたデータセットを示しています。 $ aws s3 ls s3://athena-examples/flight/parquet/ PRE year=1987/ PRE year=1988/ PRE year=1989/ PRE year=1990/ PRE year=1991/ PRE year=1992/ PRE year=1993/ このデータセットの場合、テーブルには PARTITIONED BY (year STRING) 句を含め、Athena に年単位でパーティション分割されていることを伝える必要があります。テーブル作成後、たとえば ALTER TABLE ADD PARTITION を使用するか、 AWS Glue クローラーを使用するか、 MSCK REPAIR TABLE を実行して、各パーティションを追加する必要があります( Iceberg テーブルでは テーブルレイアウト情報が追跡されるため、 MSCK REPAIR TABLE の実行は必要なく、サポートもされていません)。また、テーブルはパーティションプロジェクションを使用するように構成することもできます (設定方法については、ボーナスチップのセクションを参照してください)。 パーティション化されたテーブルを問い合わせる際、 WHERE 句でパーティションキーを使用することで、スキャン対象となるパーティションを限定できます: SELECT dest, origin FROM flights WHERE year = '1991' このクエリを実行すると、Athena は年のパーティションキーにプレディケート (フィルター) があることを認識し、一致するパーティションからのみデータを読み込みます。この場合、 s3://athena-examples/flight/parquet/year=1991/ のデータのみが読み込まれます。 データセットには複数のパーティションキーを持つことができます。以下は、 AWS Open Data Registry の NOAA Global Historical Climatology Network データセット からの例です。このデータセットは、STATION と ELEMENT でパーティション分割されており、コマンドを実行すると、特定の STATION(=ASN00023351) の ELEMENT パーティションのリストを取得することができます。 $ aws s3 ls --no-sign-request s3://noaa-ghcn-pds/parquet/by_station/ STATION=ASN00023351 / PRE ELEMENT=DAPR/ PRE ELEMENT=DWPR/ PRE ELEMENT=MDPR/ PRE ELEMENT=PRCP/ このデータセットのテーブルには、 PARTITIONED BY (station STRING, element STRING) 句が含まれ、Athena にこのようにパーティション分割されていることを伝えます。 パーティション分割するカラムを決定する際は、以下の点を考慮してください。 クエリに適したパーティションキーを選択します。クエリから逆算して、データセットをフィルタリングするのによく使われるフィールドを見つけてください。 パーティションキーのカーディナリティ(パーティションキーが取りうるユニークな値の数を指します)は比較的低い方が良いです。テーブル内のパーティション数が増えるほど、パーティションメタデータの取得と処理のオーバーヘッドが高くなり、ファイルサイズが小さくなります。パーティションキーのカーディナリティが高すぎると、パーティション分割のメリットが失われる可能性があります。 データがある特定のパーティション値に偏っていて、ほとんどのクエリがその値を使用する場合、パーティション分割のメリットがオーバーヘッドで打ち消される可能性があります。 時間の経過とともに増大するデータセットは、一般的に日付でパーティションされるべきです。特定の期間、例えば過去 1 週間や過去 1 か月を見るクエリは一般的なパターンです。日付でパーティションすることで、全体のデータセットのサイズが時間とともに増大しても、これらのクエリが読み取るデータ量は一定に保たれます。 次の表は、パーティション分割されたテーブルとパーティション分割されていないテーブルのクエリ実行時間を比較しています。このテーブルは、業界標準のベンチマークデータセット TPC-H から取得されています。テーブルの両バージョンには、74 GB の非圧縮テキストデータが格納されています。パーティション分割されたテーブルは、 l_shipdate 列でパーティション分割され、2,526 のパーティションがあります。 クエリ パーティション分割されていないテーブル コスト パーティション分割されたテーブル コスト 節約分 . 実行時間 スキャンされたデータ . 実行時間 スキャンされたデータ . . SELECT COUNT(*) FROM lineitem WHERE l_shipdate = '1996-09-01' 4.8 秒 74.1 GB $0.36 0.7 秒 29.96 MB $0.0001 99% 安価 85% 高速 SELECT COUNT(*) FROM lineitem WHERE l_shipdate >= '1996-09-01' AND l_shipdate < '1996-10-01' 4.4 秒 74.1 GB $0.36 2.0 秒 898.58 MB $0.004 98% 安価 54% 高速 EXPLAIN コマンドを使用すると、クエリによってどのパーティションが読み取られるかを確認できます: EXPLAIN SELECT COUNT(*) FROM lineitem WHERE l_shipdate = '1996-09-01' 出力で SOURCE 項目を探し、その中の PARTITION_KEY ラベルを確認してください。この行は、クエリによって読み取られるパーティションを示しています。 … Fragment 1 [SOURCE] Output layout: [count_0] Output partitioning: SINGLE [] Aggregate[type = PARTIAL] │ Layout: [count_0:bigint] │ Estimates: {rows: 1 (9B), cpu: 0, memory: 9B, network: 0B} │ count_0 := count(*) └─ TableScan[table = awsdatacatalog:tpc_h:lineitem] Layout: [] Estimates: {rows: ? (0B), cpu: 0, memory: 0B, network: 0B} l_shipdate:string:PARTITION_KEY :: [[1996-09-01]] テーブルに複数のパーティションキーがある場合、それぞれのキー値について行が出力されます。クエリがパーティションキーの複数の値に一致する場合、出力にはそれぞれの値が含まれます。たとえば、クエリを変更して l_shipdate の値の範囲を選択した場合、最後の 2 行は次のようになります。 l_shipdate:string:PARTITION_KEY :: [[1996-09-01], [1996-09-02], [1996-09-03], [1996-09-04], [1996-09-05]] 次の表に示すように、パーティション分割にも、クエリでパーティションフィルターが使用されない場合にパフォーマンス低下が生じます。データを過剰にパーティション分割しないよう注意してください。過剰なパーティション分割は、多数の小さなファイルを生成するため、パフォーマンスが低下します。この点については、この記事の後半で詳しく説明します。 クエリ パーティション分割されていないテーブル パーティション分割されたテーブル 節約 . 実行時間 スキャンされたデータ 実行時間 スキャンされたデータ . SELECT COUNT(*) FROM lineitem 3.4 秒 74.1 GB 8.9 秒 74.1 GB 62% 遅い パーティション分割のもう一つのペナルティは、クエリに一致するパーティションを見つけるのにかかる時間です。この問題を軽減する方法の 1 つは、テーブルにパーティションインデックスを有効にすることです。これにより、テーブルにパーティションが数万個以上ある場合のパフォーマンスが向上する可能性があります。パーティションインデックスを使用すると、すべてのパーティションのメタデータを取得するのではなく、クエリのフィルタ内のパーティション値のメタデータのみがカタログから取得されます。その結果、このようにパーティションが多数あるテーブルに対するクエリが高速化されます。次の表は、パーティションインデックスがない場合とある場合のパーティション分割テーブルのクエリ実行時間を比較しています。このテーブルには約 10 万個のパーティションと非圧縮のテキストデータが含まれています。orders テーブルは o_custkey 列でパーティション分割されています。 クエリ パーティションインデックス = 無効 パーティションインデックス = 有効 高速化 . 実行時間 実行時間 . SELECT COUNT(*) FROM orders WHERE o_custkey BETWEEN 1 AND 100 19.5 秒 1.2 秒 16 倍 Athena での AWS Glue Data Catalog のパーティションインデックスの利点の詳細については、 AWS Glue Data Catalog パーティションインデックスを使用して Amazon Athena クエリのパフォーマンスを向上 を参照してください。 データをパーティション分割する方法の例については、この記事の後半にある最適化されたデータセットの作成に関するセクションを参照してください。 2. データのバケット化 クエリが読み取らなければならないデータ量を減らす別の方法は、各パーティション内のデータをバケット化することです。 バケット化 とは、ある列の値に基づいてレコードを別々のファイルに分散させる手法です。これにより、同じ値を持つすべてのレコードが同じファイルに入ります。バケット化は、高いカーディナリティを持つ列があり、多くのクエリがその列の特定の値を検索する場合に有用です。バケット化の良い候補は、ユーザーやデバイスの ID などの列です。 Athena で既にバケット化されたデータセットがある場合、 CREATE TABLE ステートメントの中で CLUSTERED BY ( <バケット化されたカラム> ) INTO <バケット数> BUCKETS と指定することで、バケット化されたカラムを指定できます。Athena は Hive または Spark でバケット化されたデータセットをサポートしており、Athena の CREATE TABLE AS (CTAS) でバケット化されたデータセットを作成できます。 次の表は、 c_custkey 列を使用して 32 個のバケットを作成した場合の顧客テーブルの違いを示しています。顧客テーブルのサイズは 2.29 GB です。 クエリ 非バケット化テーブル コスト c_custkey をクラスター化カラムとしてバケット化したテーブル コスト 節約分 . 実行時間 スキャンしたデータ . 実行時間 スキャンしたデータ . . SELECT COUNT(*) FROM customer WHERE c_custkey = 12677856 1.3 秒 2.29 GB $0.01145 0.82 秒 72.94 MB $0.0003645 97% 安く 37% 高速 前述のクエリに対して EXPLAIN ANALYZE を実行すると、バケット化が customer テーブルから Amazon S3 からのデータ読み取り量を減らすのに役立ったことがわかります。バケット化されていないテーブルとバケット化されたテーブルのクエリに対する EXPLAIN ANALYZE 出力の抜粋から、入力行数とデータサイズの違いがわかります。 以下はバケット化されていないテーブルの出力です: … ─ ScanFilterProject[table = awsdatacatalog:tpc_h:customer, filterPredicate = ("c_custkey" = 12677856), projectLocality = LOCAL, protectedBarrier = NONE] Layout: [] Estimates: {rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: 0, memory: 0B, network: 0B} CPU: 19.48s (99.94%), Scheduled: 37.43s (99.97%), Blocked: 0.00ns (0.00%), Output: 1 row (0B) Input avg.: 202702.70 rows , Input std.dev.: 4.83% c_custkey := c_custkey:int:REGULAR Input: 15000000 rows (2.29GB), Filtered: 100.00%, Physical input: 2.29GB, Physical input time: 0.00ms 以下はバケット化されたテーブルの出力です: … ─ ScanFilterProject[table = awsdatacatalog:tpc_h:customer buckets=32, filterPredicate = ("c_custkey" = 12677856), projectLocality = LOCAL, protectedBarrier = NONE] Layout: [] Estimates: {rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: ?, memory: 0B, network: 0B}/{rows: ? (0B), cpu: 0, memory: 0B, network: 0B} CPU: 654.00ms (100.00%), Scheduled: 1.13s (100.00%), Blocked: 0.00ns (0.00%), Output: 1 row (0B) Input avg.: 156250.00 rows , Input std.dev.: 22.35% c_custkey := c_custkey:int:REGULAR Input: 468750 rows (72.94MB), Filtered: 100.00%, Physical input: 72.94MB, Physical input time: 0.00ns Athena でバケット化されたデータを扱う方法の詳細は、以下のリソースを参照してください。 Athena でのパーティション分割とバケット分割 CTAS クエリの例: バケット分割とパーティション分割されたテーブルの作成 データをバケットに分割する方法の例については、この記事の後半にある最適化されたデータセットの作成に関するセクションを参照してください。 3. 圧縮の利用 データを圧縮すると、クエリの実行速度が大幅に向上します。データサイズが小さくなることで、Amazon S3 からスキャンするデータ量が減るため、クエリの実行コストが下がります。また、Amazon S3 から Athena へのネットワークトラフィックも減少させることができます。 Athena は gzip、Snappy、zstd などの一般的な形式を含む、さまざまな圧縮形式をサポートしています。サポートされている形式の一覧については、 Athena の圧縮サポート を参照してください。 JSON や CSV などの圧縮されたテキストデータを問い合わせるには、特別な考慮が必要です。Athena がデータを読み取る際、データの並列処理を最大化するために、ファイルの異なる範囲をさまざまなノードに割り当てます。各範囲は スプリット と呼ばれ、並列で読み取れるファイルは スプリット可能 と呼ばれます。一般的な圧縮形式のほとんどはスプリット不可能です。つまり、リーダーは圧縮ファイルの先頭から読み取る必要があります。これは、データセットが単一の圧縮された CSV ファイルである場合、クエリ処理に使用できるのは 1 つのノードだけであることを意味します。 テキストファイルを圧縮したデータセットを作成する際は、ファイル数とファイルサイズのバランスを心がけてください。ファイルサイズの最適化については、次のセクションで詳しく説明します。 Parquet ファイルと ORC ファイルは、これらの形式がファイルを構成する複数のセクションを個別に圧縮し、ファイル内の各セクションの場所を含むメタデータを持つため、分割が可能です(ファイル全体が1つのセクションで構成されている場合は分割できないので注意が必要です)。 gzip 形式は高い圧縮率を持ち、他のツールやサービスでも幅広くサポートされています。 zstd (Zstandard) 形式は、パフォーマンスと圧縮率のバランスが良い新しい圧縮形式です。bzip2 と LZO 圧縮形式は分割可能ですが、パフォーマンスと互換性を重視する場合は推奨されません。 データを圧縮する方法の例については、この記事の後半にある最適化されたデータセットの作成に関するセクションを参照してください。 4. ファイルサイズの最適化 データを並列で読み取れ、1回の読み取り要求で可能な限り多くのデータを読み取れるときに、クエリは効率的に実行されます。各ファイルの読み取りにはオーバーヘッドがあり、例えばメタデータの取得、Amazon S3 への要求、圧縮辞書のセットアップなどが発生します。これは通常は気付かれませんが、ファイル数が増えるにつれて、オーバーヘッドが蓄積されます。クエリのパフォーマンスを最大化するには、ファイル数とサイズのバランスを取る必要があります。 一般的なガイドラインとして、128 MB 程度の分割を目指すことをお勧めします。分割とは、ファイルの一部を指します。たとえば、非圧縮テキストファイルのバイト範囲、または Parquet ファイルのページです。圧縮のセクションで説明したように、ほとんどの圧縮テキストファイルは分割できないため、一括して処理されます。Parquet や ORC などの分析用に最適化された形式は、いつでも分割可能です。 小さなファイルが多数生成される理由の 1 つは、前のセクションで説明したパーティション分割の過剰分割です。クエリのパフォーマンスが小さなファイルが多すぎるために低下していることを示す兆候は、クエリ統計の計画フェーズが全実行時間の数パーセントを超えることです。最悪の場合、クエリが「Please reduce your request rate.」という Amazon S3 エラーで失敗する可能性があります。これは、大量のファイルに対し、Athena が Amazon S3 のサービスクォータを超える数の参照リクエストを実行する場合に発生します。 詳細については、 ベストプラクティスデザインパターン: Amazon S3 のパフォーマンス最適化 を参照してください。 小さいファイルの問題を解決する 1 つの方法は、Amazon EMR の S3DistCP ユーティリティを使うことです。これを使って、小さなファイルを大きなオブジェクトにまとめることができます。また、S3DistCP を使えば、HDFS から Amazon S3 へ、Amazon S3 から Amazon S3 へ、Amazon S3 から HDFS へと、大量のデータを最適化された方法で移動できます。このセクションの最後で、Athena Spark を使ってデータを再処理する別の方法について説明します。 ファイル数が少なく、サイズが大きい方が、ディレクトリ内のファイルリスト取得が速くなり、Amazon S3 へのリクエスト数が減り、管理するメタデータも少なくなるというメリットがあります。 例えば、次の表は、100,000 個のファイルを読み取る必要があるクエリと、同じデータセットを単一のファイルとして格納したクエリの違いを比較しています。両方のファイルセットには同じデータが、圧縮されていないテキストファイルとして格納されています。データの総量は 74 GB です。 クエリ ファイル数 実行時間 SELECT COUNT(*) FROM lineitem 100,000 ファイル 11.5 秒 SELECT COUNT(*) FROM lineitem 1 ファイル 4.3 秒 処理速度向上率 . ~ 62% 同様に、次の表は、データが圧縮された場合にファイル数の違いがどのような影響を与えるかを比較しています。データは前の例と同じですが、それぞれ 10 ファイルと 100 ファイルに gzip 圧縮されています。 クエリ ファイル数 平均ファイルサイズ 実行時間 SELECT COUNT(*) FROM lineitem 10 ファイル 2.4 GB 60 秒 SELECT COUNT(*) FROM lineitem 100 ファイル 243 MB 6.8 秒 処理速度向上率 . . 約 88% ファイルサイズ、ファイル数、ファイルが圧縮されているかどうかによって、クエリのパフォーマンスに大きな違いが生じます。データが圧縮されていない場合、Athena は最適なサイズでファイルを並列処理できます。これにより、単一の非圧縮テキストファイルのほうが 10 万個の非圧縮ファイルを処理するよりも効率的です。データが圧縮されている場合、ファイル数とサイズの影響はさらに大きくなりますが、この場合、Athena がデータセットを並列処理できるように十分な数のファイルが必要になります。 データセットを最適化する方法については、この記事の後半にある小さなファイルを結合してデータセットを書き換える例を参照してください。 5. 列指向のファイル形式の利用 Apache Parquet と Apache ORC は、分析ワークロードで人気のあるファイル形式です。これらは、行ごとではなく列ごとにデータを格納することから、 列指向 のファイル形式と呼ばれることが多いです。また、読み込む必要のあるデータ量を様々な方法で削減できる機能も備えています。たとえば、列を個別に格納・圧縮することで、より高い圧縮率を実現でき、クエリで参照される列のみを読み込めます。 列指向のファイル形式では、データに対して複数の圧縮戦略が使用されます。たとえば、多くの繰り返し値を含む列は、値を 1 回格納し、繰り返し回数を付加するランレングス圧縮を使用してエンコードすることも、各値を検索テーブルへのポインタに置き換える辞書符号化を使用してエンコードすることもできます。テキストデータは、gzip、Snappy、zstd などの標準的な圧縮形式で圧縮できます。詳細については、 Athena の圧縮サポート を参照してください。 Parquet と ORC は、さまざまなデータセットに合わせて調整できます。たとえば、ブロック (Parquet) またはストライプ (ORC) サイズを大きくすると、状況によっては有益な場合があります。データセットに多数のカラムがある場合は、Parquet のデフォルト 128MB、ORC のデフォルト 64MB から大きくすることをお勧めします。これにより、各カラムの十分な値が一緒に格納され、読み取りの回数が減ります。 列指向のファイル形式を使ってデータセットを調整する別の方法は、クエリに頻繁に含まれる列でデータを並べ替えておくことです。Parquet と ORC は、各データブロックの列の最小値と最大値などのメタデータを格納しています。つまり、クエリエンジンは、そのブロックに含まれる値がクエリに一致しないと判断した場合、そのブロックのデータを読み込む必要がありません。これは 述語プッシュダウン と呼ばれます。たとえば、データにはタイムスタンプのようなものがあり、この属性でファイル内のデータを並べ替えておくと、特定の時間範囲を探すクエリは、タイムスタンプの前後のブロックのデータを読み込む必要がなくなります。 タイムスタンプによる並べ替えとパーティション分割を組み合わせると、さらにパフォーマンスが向上し、コストを節約できます。たとえば、数時間の時間枠で集計を行うことが多い場合を考えてみましょう。時間単位でパーティション分割することは可能ですが、ファイルが多すぎたり小さすぎたりするリスクがあります。代わりに、日単位でパーティション分割し、データをタイムスタンプで並べ替えることができます。このようにすると、粗粒度のパーティション分割を使用してクエリに含まれるファイルセットを一致するパーティションのみに減らし、並べ替えを使用して残りのファイル内のブロックをスキップできます。パーティションキーとタイムスタンプ列の両方でフィルタリングを行うことを忘れないでください。 次の表は、テキスト gzip、ソート無しの Parquet gzip、および l_partkey でソートされた Parquet gzip の同じデータセットに対する実行時間とスキャンされたデータを比較しています。 クエリ SELECT l_orderkey FROM lineitem WHERE l_partkey = 17766770 テキスト形式と比較した節約分 テキスト gzip データ 実行時間 11.9 秒 . スキャンしたデータ 23.7 GB . コスト $0.1 . ソート無しの Parquet gzip データ 実行時間 2.1 秒 ~ 82% 高速化 スキャンしたデータ 2.0 GB . コスト $0.009 ~ 91% 安価 l_partkey でソート済みの Parquet gzip データ 実行時間 1.1 秒 ~ 90% 高速化 スキャンしたデータ 38.8 MB . コスト $0.0001 ~ 99.9% 安価 最適化データセットの作成 このセクションでは、Athena Spark を使用してデータセットを変換し、前のセクションで説明した最適化を適用する方法を示します。このコードは、 Amazon EMR Serverless や AWS Glue ETL など、ほとんどの他の Spark ランタイムでも使用できます。Athena SQL を使ってデータを変換し、この記事で説明されている多くの最適化を適用することもできますが、Athena Spark の方がプロセスに対する設定オプションとコントロールが多くなります。 次のコードは最初に tpc_h データベースをデフォルトに設定します。このデータベースの場所は、データが書き込まれる場所を決定するために使用されます。次に、以下の操作を実行して customer_optimized という新しいテーブルを作成します: customer テーブルのすべての行を読み込みます coalesce を使用して、バケットごとにパーティションごとに書き込まれるファイル数を 4 に減らします sortWithinPartitions で c_name によってレコードを並べ替えます partitionBy で c_mktsegment と c_nationkey によってパーティション分割し、 bucketBy で c_custkey によって 32 のバケットに分割し、 zstd で圧縮された Parquet ファイルに書き込みます 次のコードを参照してください: spark.sql("use tpc_h") spark\ .read.table("customer")\ .coalesce(4)\ .sortWithinPartitions("c_name")\ .write\ .partitionBy("c_mktsegment", "c_nationkey")\ .bucketBy(32, "c_custkey") .saveAsTable("customer_optimized", format="parquet", compression="gzip") この例では、すべての最適化を同時に示しています。使用ケースによっては、1 つまたはいくつかの最適化だけが必要な場合があります。それぞれの最適化がもっとも役立つ場合については、この記事の前のセクションを参照してください。 Amazon EMR、EMR Serverless、AWS Glue ETL、または Athena SQL を使用してデータを処理する方法の詳細については、以下のリソースを参照してください。 Amazon Athena の CTAS と INSERT INTO ステートメントを使用して、S3 データレイクにデータを抽出、変換、ロードする Amazon Athena の UNLOAD 機能を使用して ETL と ML パイプラインを簡素化する AWS Glue と Amazon S3 を使用してデータレイクの基盤を構築する 大規模データセットを Parquet 形式に変換する 列指向のファイル形式への変換 クエリチューニング Athena SQL エンジンは、オープンソースの分散クエリエンジン Trino と Presto 上に構築されています。その動作を理解することで、クエリを実行する際の最適化の手がかりが得られます。このセクションでは、以下のベストプラクティスについて解説します。 ORDER BY の最適化 結合の最適化 GROUP BY の最適化 近似関数の利用 必要なカラムのみを含める 6. ORDER BY の最適化 ORDER BY 句は、クエリの結果を並べ替えた順序で返します。Athena は分散ソートを使用して、複数のノードでソート操作を並列に実行します。上位または下位 N 件の値を見るために ORDER BY 句を使用する場合は、 LIMIT 句を使用してソートのコストを削減し、クエリの実行時間を短縮できます。 例えば、次の表は、サイズが 7.25 GB の約 6,000 万行のテキスト形式非圧縮テーブルを使用したデータセットに対するクエリ実行時間をまとめたものです。 クエリ 実行時間 SELECT * FROM lineitem ORDER BY l_shipdate 274 秒 SELECT * FROM lineitem ORDER BY l_shipdate LIMIT 10000 4.6 秒 高速化 98% 高速 7. 結合の最適化 適切な結合順序を選ぶことは、クエリのパフォーマンスを向上させるために重要です。2 つのテーブルを結合する際は、大きい方のテーブルを結合の左側に、小さい方のテーブルを右側に指定してください。等値条件を使う一般的な結合の場合、Athena は右側のテーブルから検索テーブルを構築し、ワーカーノードに配布します。次に左側のテーブルをストリーミングし、検索テーブル内の一致する値を探して行を結合します。これは 分散ハッシュ結合 と呼ばれます。右側のテーブルから構築された検索テーブルはメモリ内に保持されるため、そのテーブルが小さいほど、使用するメモリが少なく、結合の実行速度が速くなります。 ハッシュテーブルがワーカーノード間に分散されているため、データスキュー(テーブル内のデータがクラスター内で偏って保持される状態)がパフォーマンスに影響を与える可能性があります。結合条件で使用されるカラムの値に偏りがある場合、1 つのノードが結合の大部分を処理しなければならず、他のノードは遊休状態になってしまいます。最高のパフォーマンスを得るには、結合条件のカラムに値が均一に分布するようにしてください。 次の表は、テキスト形式で圧縮されていない合計 74 GB のデータセットに対する実行時間を示しています。lineitem テーブルには約 6 億行、part テーブルには約 2,000 万行があります。 クエリ 実行時間 SELECT COUNT(*) FROM lineitem, part WHERE l_partkey = p_partkey 6.4 秒 SELECT COUNT(*) FROM part, lineitem WHERE p_partkey = l_partkey 8.1 秒 高速化 約 20% 高速 Athena コンソールの実行詳細ビジュアライザーを使用すると、結合の実行順序を確認できます。ビジュアライザーには、各テーブルから結合された行数も表示されます。ビジュアライザーの使用方法の詳細については、 完了したクエリの統計と実行詳細の表示 を参照してください。 3 つ以上のテーブルを結合する場合は、中間結果を減らすために、最初に大きなテーブルと最も小さなテーブルを結合し、次に他のテーブルと結合することを検討してください。 コストベースの結合最適化 テーブルに AWS Glue Data Catalog でテーブル統計情報がある場合、Athena はこれらを使用して、コストベースの最適化 (ここでの「コスト」は計算コストを指します) によりジョイン順序の変更と集約プッシュダウンを実行します。テーブルに統計情報がある場合、クエリ最適化エンジンはテーブルの順序のどれが最も効率的かを把握でき、自動的に最適化を行えます。つまり、大きなテーブルを手動でジョインの左側に配置する必要がなくなります。 コストベースの最適化機能の使用方法の詳細については、 Amazon Athena でコストベースの最適化機能を使ってクエリを高速化する および コストベースの最適化機能の使用 を参照してください。 パーティションテーブルの結合 パーティションテーブルを問い合わせる際は、すべてのテーブルのすべてのパーティションキーでフィルタを含めることが最適です。これにより、クエリプランナーはファイルのリストと読み取りをできるだけ省略できるようになります。 次の例では、 orders テーブルと lineitem テーブルが注文日 ( orders の o_orderdate 、 lineitem の l_orderdate ) でパーティションされています。最初のクエリでは l_orderdate に条件がないため、エンジンは lineitem テーブルのすべてのパーティションをスキャンする必要があります。注文日を結合条件に追加すると、クエリプランナーは 2 つのテーブルに対して1つのパーティションのみを読み込めば良いことがわかり、スキャンされるデータ量が大幅に減少します。 クエリ スキャンされたデータ 実行時間 SELECT AVG(l_extendedprice) FROM lineitem JOIN orders ON (l_orderkey = o_orderkey) AND o_orderdate = '1993-07-08' 68.1 GB 106 秒 SELECT AVG(l_extendedprice) FROM lineitem JOIN orders ON (l_orderkey = o_orderkey AND l_orderdate = o_orderdate ) AND o_orderdate = '1993-07-08' 35.4 MB 2 秒 前述のように、 EXPLAIN を使用してクエリによってどのパーティションが読み取られるかを確認できます。これは、複数のパーティション化されたテーブルを結合する際に特に重要です。 クエリに関わるテーブルの 1 つ以上のパーティションが、クエリの実行時に発見される情報に依存することがあります。最悪の場合、クエリプランナーがクエリを分析してパーティションを決定できないため、すべてのパーティションを読み取る必要があります。しかし、このような場合でも、Athena は 動的パーティションプルーニング と呼ばれるメカニズムを使用して、クエリの実行中にパーティションの読み取りをスキップできることがよくあります。たとえば、エンジンが結合条件にパーティションキーが関与していることを認識し、右側の値の数が少ない場合、ワーカーノード間でこの情報をブロードキャストできます。その後、ワーカーノードはこの情報を使用して、結合条件で後から除外されるパーティションのファイル読み取りをスキップできます。 次の例では、 orders テーブルと lineitem テーブルが注文日 ( orders の o_orderdate 、 lineitem の l_orderdate ) でパーティション分割されています。 lineitem テーブルは合計で約 75 GB の CSV で、orders は約 16 GB です。このクエリは、パーティションの約 10% に出現する特定の条件セットで注文された品目の平均価格を計算します。これらのパーティションは事前に分からないため、最悪の場合は 90 GB のデータをスキャンする必要がありますが、実際にはわずか 26.5 GB しかスキャンしません。 SELECT AVG(l_extendedprice) FROM lineitem JOIN orders ON (l_orderkey = o_orderkey AND l_orderdate = o_orderdate) WHERE o_clerk = 'Clerk#000094772' AND o_orderpriority = '1-URGENT' AND o_orderstatus = 'F' クエリが実行されると、Athena は条件を満たす行の o_orderdate の値を収集します。これらの値をクラスター全体にブロードキャストし、ノードが lineitem テーブルの一致しないパーティションの読み込みをスキップできるようにします。 EXPLAIN コマンドを使用すると、Athena が動的パーティションプルーニングを実行するかどうかを確認できます。出力で dynamicFilterAssignment を探してください。この例のクエリでは、EXPLAIN プランは次のようになります。 … Fragment 1 [HASH] Output layout: [avg_4] Output partitioning: SINGLE [] Aggregate[type = PARTIAL] │ Layout: [avg_4:row(double, bigint)] │ Estimates: {rows: 1 (55B), cpu: ?, memory: 55B, network: 0B} │ avg_4 := avg("l_extendedprice") └─ InnerJoin[criteria = ("l_orderkey" = "o_orderkey") AND ("l_orderdate" = "o_orderdate"), hash = [$hashvalue, $hashvalue_6], distribution = PARTITIONED] │ Layout: [l_extendedprice:double] │ Estimates: {rows: ? (?), cpu: ?, memory: ?, network: 0B} │ Distribution: PARTITIONED │ dynamicFilterAssignments = {o_orderkey -> #df_562, o_orderdate -> #df_563} ├─ RemoteSource[sourceFragmentIds = [2]] │ Layout: [l_orderkey:integer, l_extendedprice:double, l_orderdate:varchar, $hashvalue:bigint] └─ LocalExchange[partitioning = HASH, hashColumn = [$hashvalue_6], arguments = ["o_orderkey", "o_orderdate"]] │ Layout: [o_orderkey:integer, o_orderdate:varchar, $hashvalue_6:bigint] │ Estimates: {rows: ? (?), cpu: ?, memory: 0B, network: 0B} └─ RemoteSource[sourceFragmentIds = [3]] Layout: [o_orderkey:integer, o_orderdate:varchar, $hashvalue_7:bigint] … 動的パーティションプルーニングの詳細については、Trino ドキュメントの 動的フィルタリング をご覧ください。 クロスジョインに注意 結合条件は結合のパフォーマンスにも大きな影響を与えます。結合条件が複雑な場合、例えば LIKE や > を使用する場合、計算コストがはるかに高くなります。最悪の場合、一方の結合側のすべてのレコードを、もう一方の結合側のすべてのレコードと比較する必要があります。これは クロス結合 と呼ばれます。可能な限り、等値条件を使用してください。 EXPLAIN コマンドを使用すると、Athena がどのようなジョインを実行するかを確認できます。たとえば、 ON t1.name LIKE (t2.prefix || '%') のようなジョイン条件でクエリに対して EXPLAIN を実行すると、次のように出力されます。 Fragment 1 [HASH] … └─ CrossJoin[] クエリプランにクロスジョインが表示される場合は、代わりに等価条件を使用するようにクエリを書き換えることを検討してください。テーブルの 1 つが非常に小さい場合を除き、クロスジョインを含むクエリはクエリタイムアウト制限を超えるリスクが高くなります。 8. GROUP BY の最適化 集約を実行する際は、 GROUP BY 句に含めるカラムを可能な限り少なくして、必要な CPU とメモリの量を減らすべきです。さらに、値の分布が可能な限り均一なカラムでグループ化することを確認してください。 集約クエリのパフォーマンス問題の一因はデータスキューです。これは、多くの行が GROUP BY 句のカラムに同じ値を持っている場合に発生する可能性があります。集約中、行は GROUP BY 句のカラムのハッシュに基づいてワーカーノードに分散されます。データにスキューがある場合、1 つのノードが集約の大部分を処理しなければならず、他のノードはアイドル状態になる可能性があります。 冗長なカラムは、SQL 言語が式を GROUP BY 句に含めるか集約関数を使用することを要求するため、しばしば GROUP BY 句に追加されます。たとえば、 customer_id と customer_name カラムがあるテーブルの場合、1 つの customer_id に対して 1 つの名前しかないにもかかわらず、顧客ごとに集計する場合は GROUP BY c_custkey, c_name と書く必要があります。 GROUP BY 句に多くの冗長なカラムがある場合にクエリを高速化する方法の 1 つが ARBITRARY 関数です。この関数は、名前が示すように、そのグループから任意の値を返す集約関数です。 この例では、顧客ごとの注文数を知りたいと考えています。顧客テーブルと orders テーブルを結合すると、注文ごとに 1 行になるので、 GROUP BY c_custkey を使って顧客ごとに集約します。結果に顧客名を含めたいので、 GROUP BY 句に c_name 列を追加する代わりに、 ARBITRARY(c_name) を使用します。 SELECT c_custkey, ARBITRARY(c_name) AS c_name, COUNT(*) AS order_count FROM customer JOIN orders ON (customer.c_custkey = orders.o_custkey) GROUP BY c_custkey 可能な限り、 GROUP BY 句から不要なカラムを削除する必要があります。前の例のように 1 つのカラムしかない場合、パフォーマンスの向上は目立ちません。しかし、 GROUP BY 句に多数の列がある大規模なデータセットに対するクエリのパフォーマンスにとっては非常に重要です。 9. 近似関数の利用 大規模なデータセットを探索する際の一般的なユースケースは、 COUNT(DISTINCT column) を使用して特定の列の重複のない値の数をカウントすることです。例としては、Web ページにアクセスしたユニークユーザーの数を調べることが挙げられます。 正確な数値が必要ない場合 (例えば、どのウェブページを詳しく調べるかを探している場合)、 approx_distinct(column) の使用を検討してください。この関数は、完全な文字列ではなく、値のユニークなハッシュをカウントすることで、メモリ使用量を最小限に抑えようとします。注意点は、標準誤差が 2.3% あることです。 次の表は、テキスト形式で圧縮されていない約 6 億行の 74 GB のテーブルを使用したときの高速化の概要をまとめたものです。 クエリ 実行時間 SELECT COUNT(DISTINCT l_comment) FROM lineitem 7.7 秒 SELECT approx_distinct(l_comment) FROM lineitem 4.6 秒 高速化 約 40% 高速 詳細については、Trino ドキュメントの 概算集約関数 を参照してください。 10. 必要なカラムのみを含める クエリを実行する際は、 SELECT ステートメントで必要なカラムのみを選択し、すべてのカラムを選択しないようにしてください。カラム数を削減することで、クエリ全体のパイプラインを通して処理する必要があるデータ量が減り、最終的な結果に書き込まれるデータ量も減ります。これは特に、多数の文字列ベースのカラムを持つテーブルを照会したり、複数の結合や集約を実行する場合に特に効果的です。参照データが列指向のファイル形式の場合は、特定のカラムのデータのみが Amazon S3 から読み取られるため、スキャンされるデータ量が減ります。 次の表は、約 6000 万行のテキスト形式の非圧縮 7.25 GB のテーブルを使用したときの高速化の概要をまとめたものです。 クエリ 実行時間 SELECT * FROM lineitem, orders, customer WHERE l_orderkey = o_orderkey AND c_custkey = o_custkey 19.7 秒 SELECT c_name, l_quantity, o_totalprice FROM lineitem, orders, customer WHERE l_orderkey = o_orderkey AND c_custkey = o_custkey 5.2 秒 高速化 73% 高速 ボーナスのヒント このセクションでは、追加のパフォーマンスチューニングのヒントと、この記事の最初のバージョン以降にリリースされた新しいパフォーマンス指向の機能について説明します。 パーティションプロジェクションを使用したパーティション処理の最適化 パーティション数が非常に多く、AWS Glue のパーティションインデックスを使用していない場合、パーティション情報の処理が Athena クエリのボトルネックになる可能性があります。Athena の パーティションプロジェクション を使用すると、パーティション数が非常に多いテーブルのクエリ処理を高速化し、パーティション管理を自動化できます。パーティションプロジェクションは、パーティション情報をメタストアから取得するのではなく、パーティション情報を計算してクエリするため、このオーバーヘッドを最小限に抑えることができます。AWS Glue テーブルにパーティションのメタデータを追加する必要がなくなります(この機能は Athena でのみ利用することができる機能である点にご注意ください)。 パーティションプロジェクションでは、AWS Glue Data Catalog のようなリポジトリから読み取るのではなく、構成から計算されたパーティション値とロケーションが使用されます。メモリ内の操作はリモート操作よりも通常高速であるため、パーティションプロジェクションはパーティション数が非常に多いテーブルに対するクエリの実行時間を短縮できます。クエリと基盤となるデータの特性によっては、パーティションメタデータの取得で遅延が生じるクエリの実行時間を大幅に短縮できる可能性があります。 パーティションプロジェクションを使用するのは、パーティションのスキーマが同じである場合や、テーブルのスキーマがパーティションのスキーマを正確に記述している場合に理想的です。ID のような非常に値の種類が多い列や、非常に細かい粒度の日付範囲でパーティション分割するのに使用できます。 詳細については、 Amazon Athena でのパーティションプロジェクション をご覧ください。 大規模な結果セットを生成するクエリの高速化 (UNLOAD の利用) Athena で SELECT クエリを実行すると、非圧縮 CSV 形式の単一の結果ファイルが Amazon S3 に生成されます。クエリの出力結果が大きくなると予想される場合、単一のファイルへの書き込みに多くの時間がかかります。 UNLOAD を使用すると、結果を Amazon S3 の複数のファイルに分割できるため、書き込み段階で費やされる時間が短縮されます。また、結果セットの形式 (ORC、Parquet、Avro、JSON、TEXTFILE) と圧縮タイプ (Parquet、JSON、TEXTFILE の場合はデフォルトで gzip、ORC の場合は zlib) を指定できます。 次の表は、 SELECT と UNLOAD ステートメントの比較を示しています。このクエリでは、約 13 GB の非圧縮データが出力されることが予想されます。 クエリ SELECT * FROM lineitem LIMIT 85700000 UNLOAD (SELECT * FROM lineitem LIMIT 85700000) to with (format=’TEXTFILE’) 節約 実行時間 362 秒 33.2 秒 ~ 90% 高速化 結果セット 13 GB (CSV、非圧縮) 3.2 GB (CSV、gzip 圧縮) ~ 75% ストレージ削減 データが変更されていない場合のクエリ結果の再利用 データレイクのデータセットは、多くの場合、1 日に 1 回、または 1 日に数回しか更新されませんが、より頻繁にクエリが実行されることもよくあります。ダッシュボードを更新するためのクエリや、アプリケーションのビューにアクセスするたびに実行されるクエリがある可能性があります。前回実行した時から、データが変更されていない場合は、結果を再計算する必要はありません。実際、再計算するとより時間がかかり、コストも高くなります。このような状況では、クエリ結果の再利用を活用できます。これは、同じクエリが例えば過去 15 分以内に実行された場合、Athena がその実行結果を返すように指示する機能です。そのような結果がある場合、Athena はすぐにその結果を返し、データのスキャンは行われません。 クエリ結果の再利用の詳細については、 Amazon Athena のクエリ結果再利用によるコスト削減とクエリパフォーマンス向上 および クエリ結果の再利用 を参照してください。 結論 この投稿では、Athena SQL での対話型分析を最適化するためのトップ 10 のヒントを紹介しました。これらの実践方法は、Amazon EMR 上の Trino を使用する際にも適用できます。 この記事の トルコ語翻訳版 もご覧いただけます。 著者について Mert Hocanin は、AWS Lake Formation の Principal Big Data Architect です。 Pathik Shah は、Amazon Athena の Sr. ビッグデータアーキテクトです。2015 年に AWS に入社し、以来ビッグデータ分析の分野に注力し、AWS の分析サービスを使用してスケーラブルで堅牢なソリューションを構築するお客様をサポートしています。 Theo Tolv はスウェーデン、ストックホルムに拠点を置くシニアアナリティクスアーキテクトです。彼はキャリアの大半を小さなデータと大きなデータで仕事をしてきました。そして 2008 年から AWS 上で動作するアプリケーションを構築しています。余暇時間には、電子工作をいじったり、宇宙オペラを読むのが好きです。 監査履歴 2024 年 2 月に Theo Tolv 氏 (シニアアナリティクスアーキテクト) による最終確認と更新が行われました。翻訳はアナリティクススペシャリストソリューションアーキテクトの川村が担当しました。原文は こちら です。

9 月 30 日週の金曜日、私は Amazon Web Services (AWS) のスピーカーとして、杭州で開催された China Engineer’s Day 2024 (CED 2024) に出席する機会に恵まれました。これは、中国で最も影響力のあるプロの開発者コミュニティの 1 つである中国計算機学会 (CCF) によって主催されるイベントです。 CED 2024 では、AI 開発ツールが開発者の生産性を向上させる方法について話しました。光栄なことに CCF から優秀賞を授与され、 Amazon Q は出席者から大きな注目を集めました。 それでは、9 月 30 日週の AWS に関するその他のエキサイティングなニュースを見てみましょう。 9 月 30 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Q Business が HIPAA の対象に – Amazon Q Business が、 医療保険の相互運用性と説明責任に関する法律 (HIPAA) の認定を受けました。つまり、健康保険会社や医療提供者などのヘルスケアおよびライフサイエンス組織は、Amazon Q Business を使用して、米国の HIPAA 法で規制されている機密性の高いワークロードを実行できるようになりました。 NICE DCV が Amazon DCV に名称変更 – NICE DCV は、 Amazon DCV にリブランディングされました。この高性能リモートディスプレイプロトコルでは、ネットワーク状態が変化しても、任意のクラウドまたはデータセンターから任意のデバイスに、リモートデスクトップとアプリケーションストリーミングを安全に配信できます。Amazon DCV は、サーバー側で Windows ディストリビューションと主要な Linux ディストリビューションの両方をサポートしています。クライアントは、Windows、Linux、macOS 用のネイティブ DCV クライアントとウェブブラウザを使用して、デスクトップやアプリケーションストリーミングを受信できます。DCV サーバーとクライアントは暗号化されたピクセルのみを転送し、データは転送しないため、機密情報がダウンロードされることはありません。Amazon DCV on AWS を Amazon Elastic Compute Cloud (Amazon EC2) と併用すると、 33 の地理的リージョンと 31 のローカルゾーンにわたる AWS 108 のアベイラビリティーゾーン を利用できます。2024.0 リリースでは、最新の Ubuntu 24.04 LTS がサポートされるようになりました。詳細については、 Sébastien Stormacq による 新しいローンチブログ記事 をご覧ください。 AWS re:Post が re:Post Agent をリリース – AWS re:Post は、キュレーションされた知識や活気あるコミュニティへのアクセスを提供し、ユーザーが AWS でさらに成功できるよう支援します。re:Post Agent は、re:Post コミュニティの質問に迅速かつインテリジェントに回答できるよう設計された、 生成 AI アシスタントです。これにより、利用可能な AWS ナレッジベースが拡張されます。また、コミュニティのエキスパートは AI が生成した回答を確認することで、レピュテーションポイントを獲得できます。 Amazon Timestream for InfluxDB を使用した高度な設定 – 今回のリリースでは、ユーザーが AWS マネジメントコンソール からインスタンスの CPU、メモリ、ディスク使用率メトリクスを直接モニタリングできる機能が導入されました。 Amazon Bedrock のナレッジベースの新しいインジェスト停止 API – この新しい API により、ユーザーは進行中のインジェストジョブを自由に停止できるようになります。データインジェストのワークフローをより細かく制御できるため、ユーザーは完了を待つことなく、偶発的なインジェストプロセスや望ましくないインジェストプロセスをすばやく停止できます。新しい StopIngestionJob API を使用することで、進化するニーズに迅速に対応できるようになり、コスト削減につながる可能性があります。この機能は、 Amazon Bedrock のナレッジベース が提供されている、すべての AWS リージョン で利用できます。 Amazon AppStream 2.0 のストレージ制限の引き上げ – Amazon AppStream 2.0 では、アプリケーション設定パーシステンスのデフォルトサイズ制限が 1 GB から 5 GB に拡大されました。この引き上げにより、エンドユーザーは手動の介入なしで、またパフォーマンスやセッションセットアップ時間に影響を与えることなく、より多くのアプリケーションデータと設定を保存できるようになります。 先週は 40 以上ものローンチとリリースがありました。重要なものを選ぶのが難しかったほどです。すでに言及した内容に加えて、重要になる可能性のある機能アップデートのリストを次に示します。 Amazon Aurora Serverless v2 が最大 256 個の ACU のサポートを開始 Amazon Aurora MySQL が RDS データ API のサポートを開始 Amazon Aurora が PostgreSQL 16.4、15.8、14.13、13.16、12.20 をサポート Amazon Redshift が RA3.large インスタンスの提供を開始 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース その他にも、先週の注目アイテムをご紹介します。 Amazon WorkSpaces シンクライアント – Amazon WorkSpaces シンクライアントのインベントリは、 米国 、 フランス 、 ドイツ 、 イタリア 、 スペイン に加えて、 英国 の Amazon Business で購入できるようになりました。スマートかつ費用対効果の高いデバイスで、AWS エンドユーザーコンピューティングサービスへの安全なアクセスをすぐにご利用いただけます。この優れたガジェットは、デジタル要塞のようなものです。不正なデータストレージやアプリケーションを防止すると同時に、多数のシンクライアントを簡単に管理およびモニタリングするためのツールを IT 管理者に提供します。 ハリケーン「ヘレン」の影響を受けたコミュニティの支援 – AWS 災害対策 チームは、地域のパートナーや人道支援団体と緊密に連携して、米国南東部で支援を必要としている人々に重要な物資を届けています。また、AWS テクノロジーを導入して、再接続の支援、現場での救援活動の支援、地域での食糧配給ニーズのサポートを行なっています。 Amazon Pharmacy での処方箋の流れ – Amazon Pharmacy の AI ユースケースを読んで、薬の調剤プロセスの複雑さを解消し、患者体験を改善しましょう。このシステムでは、未加工の処方データを標準化された形式に転記し、医療略語を同等のフルテキストに変換し、医薬品の詳細を業界データベースと照合して検証します。この自動化プロセスとそれに続く薬剤師のレビューにより、潜在的な投薬ミスが 50% 減少し、処理速度が最大 90% 向上したため、薬剤師は重要なタスクとパーソナライズされたケアに集中できるようになりました。 WIRED 誌の生成 AI に関するソートリーダーシップの記事 – Antje による「Wired」のニュースコラムをご確認ください。AWS があらゆる規模や経験レベルの組織に AI の変革力を提供している方法について説明しています。すべての AI 愛好家やビジネスイノベーターにお勧めします。AWS は、生成 AI の魔法をあらゆる規模の企業にもたらすことを使命としており、テックに長けた企業にも新規参入企業にも、さまざまな AI ツールを提供しています。大きな夢を抱くスタートアップにも、業界をリードし続けることを目指す大企業にも、AWS は AI 革命のレッドカーペットを広げてお待ちしています。ワイルドなテックファンタジーを現実に変える、このチャンスをお見逃しなく! 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS re:Invent 2024 – 12 月 2〜6 日にラスベガスで開催される、毎年恒例のテックイベントへの登録が開始されました。私も、新しいリリースについて知るのが待ちきれません。また、セキュリティトピックに焦点を当てた 2 つのチョークトーク (Dev311 – 生成 AI を使用したコードセキュリティの強化と、SEC228 – AWS 中国リージョンにおけるマルチレベル保護スキームのコンプライアンスへの対応) に参加できることを楽しみにしています。 AWS Innovate 移行、モダナイズ、構築 – クラウドを初めて使用する方も、経験豊富なユーザーも、AWS Innovate で何か新しいことを学習できます。これは無料のオンライン会議です。 北米 (10 月 15 日) またはヨーロッパ、中東、アフリカ (10 月 24 日) のうち、都合の良い時間と地域でご登録ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。10 月 12 日に ソフィアで 、10 月 19 日に ヴァドーダラー 、 スペイン 、 グアテマラ で開催される AWS Community Day をお見逃しなく。 今後開催される AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 10 月 7 日週はここまでです。10 月 14 日週の Weekly Roundup もお楽しみに! – Betty この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本稿は、2024 年 8 月 24 日に公開された “ Propelling Innovation: The People, Culture, and Process Imperatives “を翻訳したものです。 新たな需要に対し中小企業が対応するのは、小さな船で嵐の中をかき抜けるようなものです。テクノロジーの進歩が続く中、顧客の期待はさらに高まっています。このような波の中を乗り越えるためには、レジリエンスや適応性、積極的な問題解決力、そして慎重なリスク管理が必要不可欠となっています。 最近のデータ によると、テクノロジーの進歩とともに、顧客の 73% が更なる差別化を期待し、また顧客ニーズの変化に対応することを 65% の顧客が求めています。これは、商品や顧客体験の絶え間ない改善を望んでいることを示しており、競争の激しい事業環境においては、イノベーションを受け入れることが成功への鍵となっています。 しかし、数々の問題に直面する中で、テクノロジーファーストの考えに惑わされることなく、立ち位置をしっかりと保つことが重要です。イノベーションは真空の中で生まれるものではありません。多様な考えを奨励する活気に満ちたエコシステム、新しいアプローチを評価する企業文化、アイデアを具体的な成果につなげるプロセス、それらによってイノベーションは初めて生まれるのです。この3つの領域にフォーカスすることで、企業は新しい製品やサービスを素早くスケールさせ、顧客価値を最大化するための態勢を整えることができるのです。 イノベーションの原動力となる人材 デジタルツールはイノベーションを推進する上で重要な役割を果たしますが、それらを活かすことができる人材がいなければ空の器となります。適切な人材がいれば、顧客のニーズに沿ってビジネスを前に進めるだけでなく、未知の領域を積極的に探求し、イノベーションの旅に情熱的に取り組むことができます。Amazon の CEO、Andy Jassy はイノベーションについて次のように述べています。 「一般常識を疑い、常識の枠組みを超えて考えられる人こそがイノベーションを生み出すのです」。 しかし、実際のところ多くの人にとって、イノベーションは自分の快適な範囲を超えるものだと感じられています。議論の中心は楽しさや創造性に置かれがちですが、現実はそうではないのです。優秀な人だったとしても、顧客体験の向上やソリューションの効率化において、さまざまな課題に直面して前に進めなくなることがよくあります。これは、イノベーションとは大きな変革を意味すると誤解していることが原因です。実際には、小さな継続的な改善の方が、より大きな変革をもたらすことも多いのです。 社員にリスクをとることを奨励すれば、他の人が見落としていた新しい可能性やソリューションに気づくことができるようになります。変化への不安に立ち向かい、自己認識を高めることで、イノベーションに活かせる心の知能指数 (EQ：Emotional Intelligence Quotient) を培うことができます。研究では、リーダーの EQ が、既存の能力やIQ(Intelligence Quotient) よりも将来の成功を予測するのに優れた指標であることが示されていることから、これは非常に重要なことです。強い対人スキルは、部門を超えた関係構築、ステークホルダーへの影響力、新しいコンセプトに向けた関係者の巻き込みを可能にします。 好奇心を含んだ企業文化の醸成 テクノロジーの変革は、企業文化の変革と表裏一体です。なぜなら、イノベーションは個人の取り組みだけでは生まれないからです。組織全体が絶えず学習し続け、新発想に向けて活動していれば、ポジティブな変化を生み出す大きな原動力となります。全社を挙げて実験的な取り組みを推進できるのは、高いコストが払える大企業だけというわけではありません。むしろ、企業には、お金ではなく、成長のマインドセットを醸成することが求められるのです。 経営者が社員との間に心理的安全性を持つことができれば、社員一人一人が通常業務を超えて、会社の成功をリードする立場にもなれます。心理的安全性があることが、高いパフォーマンスを発揮し、イノベーションを起こすのに最も重要な要因だと 研究 からも裏付けられています。組織の進化と学びは、チームが互いに啓発し、弱点を見つめ直し、懸念を表明し、ためらわずに間違いを認められるような、そうした活気ある職場環境を醸成することから生まれるのです。 ただし、イノベーションのために重要なのは、企業内の課題ではなく、顧客ニーズに目を向けることです。 Amazon の Day1 カルチャーとオペレーションモデル をご覧ください。Amazonの 取り組みは、好奇心を評価し、顧客にこだわり、大胆に実験を重ねることで、顧客のニーズに応えようとしていることがことが分かります。一方で、Day 2 のカルチャーは、企業の成長に伴い広がり、意思決定が遅くなることで、ビジネスのアジリティに影響を与えることになります。 急成長を遂げている決済プラットフォームの「 Equals Money 」は、組織の各層に渡って成長のマインドセットを醸成することで、グローバルな成長目標を実現しています。共感性に富んだ経営層と、そして絶えず変化し続けようとする企業姿勢が、慢心を防ぎ、イノベーションを呼び起こしています。初期メンバー 6 人から 450 人以上にまで成長したにもかかわらず、同社は多様性のある視点を保ち続けています。さらに AWS とのイノベーションや変革に関する取り組みを通じ、Equals Money は常に顧客に目を向け続けています。 好奇心旺盛な姿勢は、外部の動向にも積極的に目を向けることにつながります。ただし、最新の技術動向に振り回されないことも重要です。顧客ニーズを起点として、そのニーズを解決するためにどのような技術が活用できるかを見極めていくことが、成功へと導く道筋となります。 アイデアから影響力へ 人材と企業文化がイノベーションの基礎を築く一方で、構造化されたメカニズムによって、アイデアは実際のソリューションへと変化します。例えば、Amazon におけるCutomer Obsession（顧客へのこだわり）という行動指針は、社員に顧客の代理として創造することを促します。顧客ニーズから逆算し、潜在的な欲求を理解することが重要となります – それは顧客自身が明確にニーズを表現できない場合でも同様です。 効果的なフレームワークを利用することで、早すぎる要件の議論によってビジネスが振り回されるのを防ぎ、顧客にとって価値のある整合した1つのビジョンに集中することができます。例えば、Amazon の PRFAQ (Press Release and FAQ) プロセスは、ビジョンを具体的な成果物へと固めていきます。まず、企業内で新製品によって得られる顧客体験を描いた未来のプレスリリースを作成することから始め、その後、仮定やリスク、未解決の課題を体系的に捉え、関係者間で調整するために広くPRFAQ を活用します。 これらの実践は、Amazon のようなグローバル大企業だけのものではありません。プロセスも必ずしも複雑なもの、または手間がかかるものでもないのです。Amazon のドキュメントには、通常 30 近くの PRFAQ が含まれますが、中小企業の場合は、自社向けの一貫性のある外部向けの 3 つの質問と内部向けの 3 つの質問を設定し、それらを繰り返し使え、広く展開可能なテンプレートに単に記入するだけで十分です。そして、実際の顧客との対話を通じてこれらの仮説を検証することができます。これにより、早い段階で先入観に気づき、市場に合致しないソリューションを盲目的に作らずにすむようになります。 イノベーションという到達目標 顧客の期待が高まり、技術進化が加速する中、絶えずイノベーションに取り組むことが事業を継続する重要な鍵となります。結局のところ、活発なイノベーションを実践として確立することは、多方面でのチャレンジとなります。これは変化に柔軟に対応できる感情知性と回復力を備えた人材を育てることについて言及しています。イノベーションは、実験志向やアジリティ、顧客にこだわるという文化を意図的に形作ることを必要としています。そしてイノベーションは、生のアイデアを具体的なソリューションへと変換するという、実証されたプロセスを必要としています。 これまで述べてきた全体的なアプローチこそが、人を中心としたイノベーションを推進することができますが、その実践方法はたくさんあります。人材、企業文化、プロセスを企業戦略の中心にすることについて、これまで以上に詳しく学びたい場合は、 AWS Connected Community のオンデマンドインサイトを探索してください。もしくはあなたが、 クラウド初心者 であれば、 AWS Cloud エキスパート にガイダンスを求め、自社のイノベーション創出をどのように支援できるかを確認してください。 Claire Gribbin Claire Gribbin は、AWS の SMB 部門のグローバルヘッドであり、SMB セグメントの次なる成長フェーズを牽引しています。10 年間世界各国でフィールド営業のリーダーを務めた後、Microsoft Azure にて顧客やパートナーのデジタルトランスフォーメーションを大規模に推進する SMB 戦略をリードしていました。Claire は米国を拠点としています。 本記事の飜訳は、カスタマーソリューションマネージャーの釈迦郡一郎が担当しました。

こんにちわ。ソリューションアーキテクトの齋藤です。 本稿では、AWS PrivateLink による企業間プライベートネットワーク接続の例についてご紹介します。 AWSは、グローバルでは数百万、日本でも数十万のお客様にご利用いただいているクラウドサービスであり、昨今、企業でAWSクラウドの環境を持っている場合が多く、企業間のプライベートネットワーク接続を AWS 上で構築するケースも増えてきました。その際、オンプレミスで構築するような専用線を敷設し、双方でルーター、ファイアウォール設置して DMZ を構築するような手法をそのまま踏襲するのではなく、AWS のサービスに置き換えて設計する必要があります。 まず、企業間のプライベートネットワーク接続の際に考慮となるポイントはどんなものがあるでしょうか。以下のオンプレミスにおける接続例を見てみましょう。 図1: オンプレミスにおける企業間プライベートネットワーク接続の構成例 上図は、企業 A と企業 B のデータセンター同士を専用線でプライベート接続している例です。企業Aから企業Bに対し、HTTP/HTTPS 通信、SFTP 通信を行う要件があります。前提条件・構成は、企業によって異なりますが、例として以下のように設定してみました。 前提条件 企業 A は、企業 B の提供する HTTP/HTTPS サービス、SFTP サーバーにインターネットを介さず、プライベートネットワーク経由でアクセスすること Inbound 通信は、必要な通信のみを許可すること 双方のプライベートネットワークアドレス帯の重複を考慮し、お互い合意をとった CIDR を DMZ に割り当て、NAT変換を行うこと 構成 DMZ に配置した Firewall アプライアンスで、アドレス変換( NAT )とアクセスコントロールを設定 DMZ に配置ルーター同士で DMZ の CIDR のみを経路交換 DMZ 内のコンポーネントは冗長性を持ち、ここでは 専用線、Firewallアプライアンス、ルーターがそれぞれ冗長構成 このような前提条件・構成を AWS でどのように実現できるのか見て行きましょう。 AWS における企業間接続 AWS で前述のようなオンプレミスで実施している企業間接続を実現したい場合、重要なことは、 DMZ を作って、Firewall で NAT とアクセスコントロールを導入することではありません。連携したい企業とのネットワーク接続要件を最小限のアクセスでセキュアに実現することです。 AWS では、 AWS PrivateLink を利用することで、企業間、つまり異なる AWS アカウントの VPC 間の全てのトラフィックを AWS のネットワーク内に維持しながら、AWS 内にホストされているサービスに対するプライベート接続を提供することができます。サービス利用者側の VPC 内にあるかのようにサービス提供側の VPC 内のサービスにプライベートに接続するために使用できる、可用性が高くスケーラブルなテクノロジーです。 Internet Gateway 、 NAT Gateway 、 VPC Peering 、 VPN 接続 等も不要であるため、サービス提供側はリソースを外部ネットワークに公開するリスクを低減することができます。 セキュリティグループ 等で、アクセス制御することも可能です。 以下の図は、AWS PrivateLink を用いて、異なる AWS アカウントの VPC 間で、AWS リソースへのネットワークアクセスを提供している構成例です。ここでは、企業 B のホストするHTTP(S) サービス、SFTP サービスを企業 A にプライベート接続で提供しています。サービス利用者側(企業 A )は、Direct Connect Gateway, Transit Gateway で接続されたオンプレミス環境と AWS 環境を持っており、アクセス元となるクライアントは、オンプレミスのネットワーク、VPC に存在することを想定しています。 図2: AWS PrivateLink を用いた企業間プライベートネットワーク接続の構成例 サービス利用者側（企業A：Consumer）、サービス提供者側（企業B：Service Provider）それぞれの構成を解説していきます。 サービス提供者側（企業 B：Service Provider） サービス提供側である企業 B は、 Application Load Balancer でホストされるHTTP(S) サービスと Amazon EC2 でホストする SFTP サービスを企業 A に提供をしたいです。この 2 つのサービスに対するプライベートアクセスを AWS PrivateLink を介して提供するためには、 Network Load Balancer (NLB) を構築し、NLB と関連づく AWS PrivateLink endpoint を作成、サービス利用者へアクセス権限を付与することで、別の AWS アカウントからのプライベートアクセスを実現します。NLB はレイヤー 4 で動作するロードバランサーで、Private Link endpoint 作成するために必要となるコンポーネントです。NLB は、HTTP/HTTPS(tcp/80,443) に対する接続リクエストを Application Load Balancer でホストされるHTTP(S) サービス、SFTP(tcp/22) に対する接続リクエストを、Amazon EC2 でホストする SFTP サービスにルーティングします。また、アクセスコントロールは、AWS PrivateLink における プリンシパルに対する許可設定 、NLB に紐づくセキュリティグループで行います。 サービス利用者側（企業 A：Consumer） サービス利用側は、企業 B から提供を受けた AWS PrivateLink のエンドポイントサービスから自社 AWS アカウントの VPC 内に VPC エンドポイントを作成することで対象のサービスへのプライベートアクセスができるようになります。作成した VPC エンドポイントに紐づくセキュリティグループでアクセスコントロールを行います。 このように、AWS PrivateLink を利用することで、企業間、つまり異なる AWS アカウントの VPC 間で必要な通信のみを許可するプライベートアクセスを実現することができます。また、お互いの VPC の CIDR 割り当てに依存しないため、IP の重複を考慮する必要もなく、DMZ を新たに構築する必要もありません。ここでは、企業 A から企業 B へのアクセス方向の例を挙げましたが、逆向きの場合は、同様のことを企業 A と B で入れ替えて実施することで、双方向にサービスの提供を行うことができます。 手順・構成方法 ここからは、具体的な手順の例として、以下の図のような ALB でホストされる HTTP サービス、Amazon EC2 でホストする SFTP サービスを、AWS PrivateLink で、別の AWS アカウントの VPC に提供する方法を紹介します。 AWS Account B (Service Provider) NLB の設定 ここでは、NLB の構築方法については省略しますが、以下のように、TCP/80 は ALB の属するターゲットグループ、TCP/22 は SFTP サーバーの属するターゲットグループにルーティングするリスナー設定を持つ NLB があり、これを別の AWS アカウントの VPC に AWS PrivateLink でプライベート接続を提供していきます。 NLB で使用するセキュリティグループでは以下のように、AWS Account A(Consumer) 側のアクセス元となるサーバーの CIDR を指定してアクセス許可を行います。 AWS Account B(Service Provider) PrivateLink Endpoint の作成 次に、PrivateLink Endpoint の作成を行います。AWS マネジメントコンソールの VPC のメニューのエンドポイントサービスから、エンドポイントサービスを作成を選択すると以下のような画面となりますので、対象の NLB を選択します。 作成を行うと、以下のように、エンドポイントサービスが作成されます。「サービス名」が提供先で必要な情報となります。また、NLB の存在するアベイラビリティゾーンがリストされていますが、提供先で作成する VPC エンドポイントも同じ アベリラビリティゾーン ID である必要があるため、合わせて伝える必要があります。 次に「プリンシパルを許可」のタブを開き、提供先となる AWS アカウントからの利用を許可します。 ここでは、AWS アカウント A の ID を指定するため、プリンシパルで arn:aws:iam::[AWS Account ID]:root のように記述します。事前に提供先の AWS アカウント ID は確認しておきましょう。 これで AWS アカウント B 側でのPrivate Link の作成は完了です。 AWS Account A(Consumer) VPC endpoint の作成 次に、AWS Account A 側での作業を行います。 AWS マネジメントコンソールの VPC のメニューから エンドポイント＞エンドポイントの作成を行います。 サービスカテゴリは、「その他のエンドポイントサービス」を選択し、サービス名で、AWS アカウント B 側で作成したエンドポイントサービスのサービス名を入力し、サービスの検証を行います。検証が成功すれば、そのまま設定を進めていきます。 エンドポイントを作成する VPC を選択すると、作成可能なアベイラビリティゾーンとサブネットが選択可能になります。ここで選択可能なアベイラビリティゾーンは、サービス提供側の NLB の存在するアベイラビリティゾーンであるため、エンドポイントを作成するサブネットのアベイラビリティゾーンは事前に確認しておきましょう。 エンドポイントに対し、セキュリティグループを設定しますので、事前に必要な通信を許可するセキュリティグループを作成しておきましょう。   AWS Account B(Service Provider) PrivateLink の承諾 承認設定で、特定のプリンシパルに許可を付与して自動的にすべての接続リクエストを承諾するか、手動で承諾するかエンドポイントサービスにアクセスできる AWS プリンシパルを制御できます。ここではデフォルトのままなので、手動で承諾します。 AWS Account A 側で、VPC エンドポイントを作成すると状態が承諾待ちになります。以下のように、AWS Account B 側でエンドポイントリクエストの承諾を完了することで、利用可能な状態となります。 AWS Account B 側   AWS Account A 側   AWS Account A(Consumer) 動作確認 それでは、AWS Account A にあるクライアントである EC2 インスタンスからアクセス確認をしてみます。アクセス先は VPC エンドポイントの DNS 名に対して行います。 HTTP リクエスト [ssm-user@ip-10-2-11-30 ~]$ curl http://vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com ip-10-1-22-193.ec2.internal (レスポンス結果) SFTP アクセス [ssm-user@ip-10-2-11-30 ~]$ sftp sftpuser@vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com sftpuser@vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com's password: Connected to vpce-XXXXXX-fuhi0awy.vpce-svc-XXXXXX.us-east-1.vpce.amazonaws.com. sftp> AWS Account A の VPC 内にある EC2 インスタンスから、VPC 内のアドレスを持つ VPC エンドポイントを経由して、AWS Account B のVPC 内でホスティングされているサービスにアクセスをすることができました。 まとめ 本稿では、AWS PrivateLink を利用した 企業間プライベートネットワーク接続の例をご紹介しました。AWS PrivateLink を用いることで、必要最小限のアクセス許可で、お互いの VPC の CIDR の重複を考慮することなく、企業間プライベートネットワーク接続を構築することが可能です。 オンプレミス同士の接続を AWS クラウド同士の接続に移行をご検討されている際には、 AWS Well-Architected Framework において、「最小特権の原則に則った設計の一部として、可能な限り、ネットワークピアリングよりもポイントツーポイントフローを優先します。」と記述がある通り、AWS PrivateLink をまずご検討いただくことをお勧めします。 本稿が、AWSにおける企業間プライベートネットワーク接続をご検討されている方のお役に立てば幸いです。

新しい Amazon Web Services (AWS) コミュニティイベントが毎週開催されており、交流の輪を広げ、新しい事柄を学び、コミュニティに活発に参加することができます。コミュニティにいるときは、誰もが共に成長し、取り残される人は 1 人もいません。9 月 23 日週も例外ではありませんでした。そのハイライトとして、 Viktoria Semaan による How to Create Impactful Content and Build a Strong Personal Brand というタイトルの講演で幕を閉じた Dutch AWS Community Day や、 Peru User Group が企画した 2 日間の講演と学びの機会であり、 Jeff Barr が自分の運を創り出す方法について話した UGCONF & SERVERLESSDAY 2024 などが挙げられます。コミュニティイベントはまだまだ続いています。 近日開催予定の AWS Community Day でイベントをご確認ください。 9 月 23 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock が AI21 Labs による Jamba 1.5 モデルファミリーの提供を開始   – Jamba 1.5 Large モデルと 1.5 Mini モデルは 256,000 のコンテキストウィンドウを備えています。これは市場で最も長いコンテキストウィンドウの 1 つであり、長い時間がかかるドキュメント分析といった複雑なタスクの実行を可能にします。これらのモデルは構造化された JSON 出力、関数の呼び出し、およびドキュメント処理をネイティブにサポートしており、特化型 AI ソリューションのエンタープライズワークフローに統合されます。詳細については、「 Jamba 1.5 family of models by AI21 Labs is now available in Amazon Bedrock 」と ドキュメント を読み、 Amazon Bedrock の AI21 Labs ページ にアクセスしてください。 AWS GovCloud (米国) リージョンで AWS Lambda が Amazon Linux 2023 ランタイムのサポートを開始 – これらのランタイムは、Python 3.12、Node.js 20、Java 21、.NET 8、Ruby 3.3、および Amazon Linux 2023 などの最新の言語機能を提供します。デプロイフットプリントがより小さくなっており、更新されたライブラリと新しいパッケージマネージャーが装備されています。また、コンテナベースのイメージを使用して、関数をコンテナイメージとして構築し、デプロイすることもできます。 Amazon SageMaker Studio がアイドル状態になったアプリケーションの自動シャットダウンのサポートを開始 – Amazon SageMaker Distribution イメージ v2.0 以降を使用して、非アクティブな JupyterLab アプリケーションと CodeEditor アプリケーションを自動的にシャットダウンできるようになりました。管理者は、ドメインまたはユーザープロファイルレベルでアイドルシャットダウン時間を設定でき、オプションでユーザーによるカスタマイズも可能です。このコスト管理メカニズムは、使用されていないインスタンスの料金を回避するために役立ち、SageMaker Studio が提供されているすべての AWS リージョンで利用できます。 Amazon S3 が、あらゆる S3 ストレージクラスに対する S3 ライフサイクル移行ルールにデフォルトの128 KB 最小オブジェクトサイズを実装 – 移行リクエスト数を削減することで、多数の小規模オブジェクトが含まれるデータセットの移行コストを低減します。ユーザーは、デフォルトを上書きして最小オブジェクトサイズをカスタマイズできます。既存のルールは変更されませんが、新しい設定または変更された設定には新しいデフォルトが適用されます。 11 の追加リージョンで Amazon Redshift データ共有のための AWS Lake Formation の一元化されたアクセスコントロールの提供を開始 – 共有された Amazon Redshift データへのテーブル、列、および行レベルでのアクセスを含めた、きめ細かな許可管理を実現します。また、セキュリティの強化と管理の簡素化のために、タグベースのアクセスコントロールや、 AWS IAM アイデンティティセンター を用いた信頼できるアイデンティティの伝達もサポートしています。 Amazon Bedrock が Llama 3.2 生成 AI モデルの提供を開始 – このコレクションには、高度な推論タスク向けの 90B および 11B パラメータマルチモーダルモデルと、エッジデバイス向けの 3B および 1B テキスト専用モデルが含まれています。ビジョンタスクをサポートし、より優れたパフォーマンスを提供するこれらのモデルは、さまざまなアプリケーション全体で責任ある AI イノベーションを実現するように設計されています。これらのモデルは、128,000 のコンテキスト長と、8 言語での多言語機能をサポートしています。詳細については、「 Amazon Bedrock で利用可能になった Meta からの Llama 3.2 モデルの紹介 」をお読みください。 AWS End User Messaging SMS リソースを複数の AWS アカウント間で共有 – AWS Resource Access Manager (RAM) を使用して、電話番号、送信者 ID、電話プール、オプトアウトリストを共有できます。さらに、 Amazon SNS が AWS End User Messaging 経由で SMS テキストメッセージを配信するようになったため 、双方向メッセージングやきめ細かな許可といった拡張機能も提供されます。これらの更新は、AWS サービス全体で SMS メッセージングの柔軟性を向上させ、制御を強化します。 AWS Serverless Application Repository が AWS PrivateLink のサポートを開始 – インターネットに露出されることなく、 Amazon Virtual Private Cloud (VPC) から直接接続することを可能にします。この機能は、コミュニケーションを AWS ネットワーク内に留めておくことで、セキュリティを強化します。 AWS Serverless Application Repository が提供されているすべてのリージョンで利用でき、 AWS マネジメントコンソール 、または AWS コマンドラインインターフェイス (AWS CLI) を使用してセットアップできます。 Amazon SageMaker with MLflow がセキュアなトラフィックルーティングのために AWS PrivateLink のサポートを開始 – AWS ネットワーク内での Amazon Virtual Private Cloud (VPC) から MLflow Tracking Server へのセキュアなデータ転送を実現します。この機能は、パブリックインターネットへの露出を回避することで、機密情報の保護を強化します。ほとんどの AWS リージョンで利用でき、MLflow を使用した機械学習 (ML) と生成 AI 実験のセキュリティを向上させます。 Amazon EC2 C8g および M8g インスタンスの導入 – コンピューティング集約型および汎用ワークロードのパフォーマンスを向上させます。最大 3 倍の vCPU、3 倍のメモリ、75% 多いメモリ帯域幅、および 2 倍の L2 キャッシュを備えたこれらのインスタンスは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、マイクロサービスなどのさまざまなアプリケーションのデータ処理、スケーラビリティ、コスト効率性を向上させます。詳細については、「 Run your compute- intensive and general purpose workloads sustainably with the new Amazon EC2 C8g, M8g instances 」をお読みください。 Amazon SageMaker JumpStart が Llama 3.2 モデルの提供を開始 – これらのモデルは、1B パラメータから 90B パラメータにおよぶさまざまなサイズを提供しており、画像推論などのマルチモーダルタスクをサポートし、AI ワークロードをより効率的に実行できます。1B モデルと 3B モデルはファインチューニングが可能で、Llama Guard 3 11B Vision は責任あるイノベーションとシステムレベルの安全性をサポートします。詳細については、「 Llama 3.2 models from Meta are now available in Amazon SageMaker JumpStart 」をお読みください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページを定期的にご確認ください。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Deploy generative AI agents in your contact center for voice and chat using Amazon Connect, Amazon Lex, and Amazon Bedrock Knowledge Bases – このソリューションはお客様との低レイテンシーでのやり取りを可能にし、ナレッジベースから質問に回答します。機能には、サーバーレスアーキテクチャでの会話分析、自動化されたテスト、ハルシネーション検出などがあります。 How AWS WAF threat intelligence features help protect the player experience for betting and gaming customers – AWS WAF は、ベッティングやゲーミングのためのボット保護を強化します。新しい機能には、ブラウザフィンガープリント、自動化検出、組織的なボットを識別するための ML モデルなどがあります。これらのツールは、スクレイピング、不正行為、分散型サービス拒否 (DDoS) 攻撃、およびチート行為に対抗することで、プレイヤーエクスペリエンスを保護します。 How to migrate 3DES keys from a FIPS to a non-FIPS AWS CloudHSM cluster – RSA-AES ラッピングを使用して、バックアップなしで 3DES (Triple Data Encryption Algorithm) キーを米国連邦情報処理規格 (FIPS) hsm1 クラスターから非 FIPS hsm2 クラスターにセキュアに転送する方法を学びます。この方法は、FIPS 140-3 レベル 3 のサポート、非 FIPS モード、より多くのキー容量、および相互 TLS (mTLS) を備えた新しい hsm2.medium インスタンスの使用を可能にします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。これらのイベントは、エキスパートによるテクニカルセッション、デモ、ワークショップを提供します。登録可能なイベントは、残すところ オタワ (10 月 9 日) のみになりました。 AWS Community Day  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。次回の AWS Community Day は、10 月 3 日に オランダ と ルーマニア 、および 10 月 5 日に ジャイプル 、 メキシコ 、 ボリビア 、 エクアドル 、 パナマ で開催される予定です。私は 10 月 5 日のパナマコミュニティに参加する予定で、とても楽しみにしています。 AWS GenAI Loft  – クラウドと AI に関する AWS の専門知識を紹介するコラボレーションスペース兼没入型エクスペリエンスであり、AI 製品やサービスを実際に体験し、業界リーダーとの独占セッションに参加して、投資家や同業者との交流の輪を広げる貴重な機会をスタートアップやデベロッパーに提供します。 お近くの GenAI Loft 開催地を見つけて 、登録するのをお忘れなく。私は、10 月 15 日の Gen AI Developer Day でサンフランシスコラウンジに参加し、いくつかのデモを行う予定です。参加される場合は、ぜひ立ち寄ってお声をおかけください! 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 今週はここまでです。10 月 7 日週の Weekly Roundup もお楽しみに! コミュニティイベントの写真を提供してくださった Dmytro Hlotenko 氏と Diana Alfaro 氏に感謝いたします。 – Eli この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024年10月10日、経済産業省と国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が協力して実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の2サイクル目 (2024年7月公募) における採択事業者のキックオフが行われ、本事業の採択事業者が発表されました。 7月の AWS ブログ でお伝えした通り、「経済産業省が計算リソース提供事業者から一括で確保し採択事業者へ提供する提供事業者」として AWS が選定され、同スキームを通じて NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge ) を提供します。また、「採択事業者が計算リソース提供事業者と個別に調整し直接確保」するスキームを通じて、上記 EC2 P5 インスタンスに加えて、採択事業者のニーズに合わせ Amazon SageMaker HyperPod および Amazon EC2 Trn1 インスタンス を提供することとなりました。 AWS は、計算リソース提供事業者として、GENIAC 支援チームを立ち上げたうえで以下の支援を提供します: 計算資源 : NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンスまたは EC2 Trn1 インスタンスの提供 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster や SageMaker HyperPod を活用した構築・管理の支援 開発者コミュニティ : 海外の機械学習エンジニアとの交流による最先端の開発動向 (11月)、国内の機械学習エンジニア同士の交流による知見共有 (11月) をはじめとした国内外の知見共有に向けた支援 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの go-to-market 支援や AWS Marketplace の活用、利用企業との AWS 主催イベントを通じたマッチング機会の提供 (11月) これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみを掲載): AI inside株式会社 AiHUB株式会社 SyntheticGestalt株式会社 Turing株式会社 カラクリ株式会社 ストックマーク株式会社 フューチャー株式会社 株式会社EQUES 株式会社Preferred Elements 株式会社ヒューマノーム研究所 株式会社ユビタス 株式会社リコー 国立研究開発法人海洋研究開発機構 採択事業者からコメントを頂きました: 先端AIアーキテクチャを用いた処理においても信頼性高く稼働するインフラサービスを提供するAWS様に、技術/ビジネスの両面にていつもお世話になっております。GENIACサイクル2における大規模なAIモデルの学習処理においても、SageMaker HyperPodを活用することで円滑に開発が進むことを期待させていただければと思います。 — ストックマーク株式会社 取締役CTO 有馬 幸介 氏 この度インバウンド業務の課題を解決することを目的に、アジア言語対応の強化を目指したモデル開発において、モデル開発に弊社リソースを集中させ、効率的に開発が推進できるよう、基盤モデル構築に最適化されたマネージド型のインフラストラクチャを提供する Amazon SageMaker HyperPod を選択しました。今後AWSとAI活用に向けて更なる協業を期待しています。 — 株式会社ユビタス CEO Wesley Kuo 氏 AWSからは技術・ビジネスの両面でご支援いただき大変感謝しております。AWS Trainium は効率的にLLM開発を進めることができる最適な選択肢だと思っております。 — カラクリ株式会社 取締役CPO 中山 智文 氏 Preferred Networksグループでは、世界最大級の高品質なデータセットを構築し、私たちが開発する大規模言語モデル「PLaMo」のさらなる進化と社会実装に向けて取り組みます。 研究開発の効率化のため、Amazon EC2 P5インスタンスおよびAWS ParallelClusterを利用します。 AWSからの多大なサポートと革新的なソリューションに感謝いたします。 — Preferred Networks 代表取締役 最高研究責任者, Preferred Elements 代表取締役社長 岡野原 大輔 氏 AWSが提供するEC2 P5インスタンスおよびAWS ParallelClusterを活用し、完全自動運転の実現に向けた身体性をもつマルチモーダル基盤モデルの開発を進めていきます。現実の多様な運転環境に対応するため、独自の大規模走行データを新規に構築し、これをもとに複雑な交通状況を理解・予測できるモデルの開発を行います。AWSのスケーラブルなインフラにより、膨大なデータの処理と大規模モデルの学習を効率的に進め、短期間で高精度なモデルの実現を目指しています。 — Turing株式会社 CTO 山口 祐 氏 地域または企業レベルで効果的な温暖化対策立案を目的とした気候サービスのための生成AI基盤モデル開発に当たり、大規模言語モデルを始めとした深層学習において高いパフォーマンスを発揮するNVIDIA H100 Tensor Core GPUを搭載したAmazon EC2 P5インスタンスを選択しました。基盤技術の開発から実用化・事業化、社会実装に向けた開発までが加速されることを期待しています。 — 国立研究開発法人海洋研究開発機構 付加価値情報創生部門 地球情報科学技術センター データサイエンス研究グループ 松岡 大祐 氏 AWS では日本のお客様に対し、昨年の AWS LLM 開発支援プログラム にはじまり、 グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。そこで得られた知見をもとに、GENIAC における日本の生成 AI 開発力向上に貢献できれば幸いです。

本ブログでは、消費財業界向けに発表した e-Book「 消費者に愛される ブランドを 構築する 」について紹介します。 消費財業界は、テクノロジーの急速な進歩により、かつてないほど多様性に富んだ時代を迎えています。企業は、商品の製造、流通、マーケティング、評価の方法を改善するために必要なデータ、分析、ツールを利用できるようになりました。しかし、消費財企業の経営幹部の多くは、自社のビジネスを継続的にモダナイズしなければ、事業の存続が危ぶまれる可能性さえあると考えています。次世代のコンピテンシーを迅速に適用できるよう努め、消費者に愛されるブランドの構築が事業成功の鍵になるのです。 ブランドとは、商品の品質、カスタマーサービス、マーケティングや広告の印象、評判などの無形要素を含む、企業に対する総合的な認識を表すものです。新たに公開された Amazon Web Services (AWS) の eBook では、消費財ブランドを高める際に欠かすことのできない重要な要素について解説しています。また、魅力的なブランドの構築に役立つ長期的な考慮事項や、消費財企業が AWS のクラウドテクノロジーを利用して、この動的な市場の進化する課題に対応する方法についても説明します。さらに、先進消費財企業の事例に見る 6 つの重要なソリューション分野や、AI によって消費財ブランドがどのように変革されるのかについても触れています。 魅力的なブランドを構築するための 4 つの重要な要素と長期的な考慮事項 魅力的なブランドを構築し維持するためのポイントについて整理しています。まずブランド構築のために、データ戦略、サプライチェーン、IT インフラ、イノベーションの 4 つの要素に注力することが重要です。さらに、長期的な視点から、パーソナライゼーション、D2C （Direct to Consumer）戦略、オムニチャネル販売、社会的責任、M&A 活動にも取り組む必要があります。これらの要素を組み合わせることで、消費者のニーズに応え、競争力のあるブランドを確立することができます。デジタル技術の活用と消費者中心のアプローチを通じて、ブランドの価値を高め、持続可能な成長を実現することが可能となります。 4 つの重要な要素 セキュリティに基づくデータ戦略の設定 ：消費者のプライバシーを尊重しつつ、パーソナライズされたレコメンデーションを提供するためのデータ戦略を策定します。 サプライチェーン業務のモダナイズ ：AI ベースの予測や在庫の最適化を通じて、消費者がいつでもどこでも商品を購入できるようにします。 IT インフラストラクチャの変革 ：クラウドインフラとマイクロサービスアーキテクチャを活用し、業務改善とコスト削減を実現します。 イノベーションのパイプライン確立 ：継続的に革新的な新商品を提供、ビジネス全体でイノベーションを推進します。 長期的な考慮事項 パーソナライズを強化してロイヤルティを高める ：AI と機械学習を活用し、すべてのタッチポイントでパーソナライズされた体験を提供します。 コスト効率の高い方法で D2C を実現する ：直接消費者とつながり、ファーストパーティデータを収集するための D2C 戦略を検討します。 商品をどこからでも購入可能にする ：オムニチャネル戦略を採用し、消費者がいつでもどこでも商品を購入できるようにします。 社会的責任と信頼性を一致させる ：環境への配慮や社会貢献活動を通じて、ブランドの信頼性を高めます。 M&A 活動をモニタリングする ：新商品やブランドの追加、競合他社の買収などの M&A 機会を常に探ります。 　 先進消費財企業の事例に見る 6 つの重要ソリューション分野と AWS の成功事例 消費財企業が AWS を選ぶ理由 上記の考慮事項を踏まえ、多くの消費財企業から AWS は選ばれてきました。AWS は、Amazon が過去 25 年間に使用および改良を重ねてきたものと同じクラウド機能を提供し、実証済みの価値をもたらすことで、消費者の信頼とブランドロイヤルティを高める消費財のユースケースを推進しています。AWS を利用することで、データプライバシーを保護しながら消費者のインサイトを得る、品質を犠牲にすることなくコストを削減する、モダンなITインフラストラクチャで俊敏性と柔軟性を得る、AIを活用した俊敏なイノベーションパイプラインを作成する、といったメリットがあります。 6 つの重要なソリューション分野とAWS の成功事例 AWS の先進的なソリューションは、消費財企業の様々な課題解決に貢献しています。商品開発から製造、サプライチェーン管理、マーケティング、コマース、IT インフラまで、幅広い分野で AWS のサービスが活用されています。AI 、IoT 、データ分析などの最新技術を駆使することで、消費者ニーズへの迅速な対応、効率的な業務運営、一貫したブランド体験の提供が可能になります。これらの成功事例は、AWS が消費財企業のデジタルトランスフォーメーションと競争力強化に不可欠なパートナーであることを示しています。 商品開発：高度な技術で商品開発を加速する 消費者のフィードバック、ソーシャルメディアでの口コミ、市場動向などをを収集、分析することから、新たな消費者の好みや満たされていないニーズを特定する、このインサイトドリブンなアプローチは、革新的な商品を開発するのに役立ちます。 紹介されている顧客事例 家庭用品からヘルスケア用品まで消費者製品の提供を手がける Helen of Troy は、 AWS IoT Core を使用して消費者の Bluetooth 対応デバイスである、コネクテッド体温計からデータを収集し、カスタマーエクスペリエンスの継続的な革新と改善を実現しています。このデータ分析により、スマートデバイスの最も有用な機能を特定し、効果的なリソース配分を行っています。例えば米国全土で体温データを収集していることで、ある地域で病気が増加している場合に、保護者に通知することが可能です。この通知が行動に影響を与え、感染症の伝染減少につながる可能性があります。 製造：品質とサステナビリティを維持しながら製造を最適化する 消費者はよりよい商品をより安く手に入れるだけでなく、持続可能な方法で生産された商品を求めてもいます。環境に配慮しつつ製造プロセスを最適化する新しい方法を模索し、消費者の期待に応え、上回らなくてはなりません。 紹介されている顧客事例 大手パルプ・製紙企業の Georgia-Pacific は、AWS で稼働する SAS Viya ソリューションを導入し、生産性と流通を向上させました。15,000 以上の機械学習モデルと分析プラットフォームにより、潜在的な機器の故障を予測して計画外のダウンタイムを 30% 削減しながら、安全上の事故や非効率的な機械運用、予期しない生産中断を防止しています サプライチェーン：AI ドリブンの分析によりサプライチェーンの回復力を向上させる サプライチェーンにおけるコラボレーションは、在庫管理の改善、在庫切れの減少、物流コストの削減につながります。消費者が購入したいときにどこからでも商品を購入できるようにすることで、カスタマーエクスペリエンスを向上させます。欠品によるブランドの信頼低下も防ぎます。 紹介されている顧客事例 飲料ボトリング会社 Coca-Cola Andina は、AWS を活用して社内向け Thanos アプリケーションを構築し、在庫管理やニアリアルタイムでの業務追跡を実現しました。これにより、各流通センターの状況確認や従業員の生産性追跡、注文ステータスの追跡が可能となり、業務の可視性が大幅に向上しました。分析チームの生産性が 80% 向上したことで、よりデータ駆動型の意思決定ができるようになったのです。 マーケティング：エンゲージメントの価値強化で、ブランドロイヤルティを高める ブランドロイヤルティを構築する体験を生み出すためには、商品の魅力を高めるだけでなく、有意義な消費者エンゲージメントを通じて、今日の競合ひしめく市場で差別化を図る必要があります。 紹介されている顧客事例 食品飲料メーカーである Danone Indonesia は、AWS パートナーの Treasure Data の顧客データプラットフォーム (CDP) を使用して、消費者の関心を特定し、ウェブサイトでのエンゲージメントを追跡、過去の購入履歴を確認しています。これにより、デジタルおよび非デジタルチャネルを通じた一貫したカスタマージャーニーの追跡が可能となり、AI ベースの商品レコメンデーションやライフタイムバリューの予測などが実現しました。 ユニファイドコマース：オムニチャネルコマースにより一貫性のある消費者エクスペリエンスを創出 現代のオムニチャネルコマースを理解し、商品をいつでも、どこからでも見つけられるように、小売業者とデジタルコマース機能をシームレスに連携する必要があります。また、消費者がどこでどのように買い物をしても一貫したブランド体験を提供できるようにすることも求められます。 紹介されている顧客事例 燻製器、グリル、バーベキュー用品でよく知られている Traeger は、 Amazon Connect の機能を活用して、データと機械学習モデルを使用した自動問題検出システムを構築しました。これにより、エージェントの顧客満足度と初回解決率が約 15% 向上し、通話時間も約 15% 短縮されました。 IT とデジタルトランスフォーメーション：IT インフラストラクチャのモダナイズによるビジネス成果の向上 消費財企業は、スピードと俊敏性を高めるために、クラウドベースのソリューションを使用してテクノロジーインフラストラクチャをモダナイズする必要があります。 紹介されている顧客事例 サントリー は、AWS を共通環境として採用し、5 つの異なるシステムを 1 つの一貫性のあるグローバルインフラストラクチャシステムに統合しました。インフラストラクチャの総保有コスト (TCO) を約 25% 削減できました。これにより、アプリ開発の高速化やメンテナンス負荷の軽減、セキュリティ対策の強化、ビジネスの可視化を実現しました。 　 AI によって消費財ブランドはどう変わるのか 消費財企業が AI を活用してブランド構築を強化する動きが加速しています。効率向上、意思決定の強化、イノベーション推進を目指す中で、特に以下において AI の利用が増加すると予想されています。 需要予測 : AI アルゴリズムが過去の売上データや市場動向を分析し、より正確な需要予測を生成。在庫の最適化と顧客体験の向上につながります。 サプライチェーンの最適化 : AI システムがリスク予測や非効率箇所の特定、配送ルートの最適化を行い、物流効率を高めコスト削減を実現します。 商品開発とイノベーション : 機械学習や NLP （自然言語処理）を活用し、消費者のフィードバックや市場動向を分析。消費者ニーズに合った商品開発や改良が可能になります。 品質管理と保証 : AI 画像認識システムが生産ライン上で効率的に商品を検査。一貫した品質確保と不良品リスクの軽減に貢献します。 価格の最適化 : AI アルゴリズムがリアルタイムで市場動向を分析し、最適な価格戦略を提案。競争力維持と収益最大化を両立させます。 カスタマーサービス : AI チャットボットやバーチャルアシスタントが 24 時間体制のサポートを提供。顧客体験の向上と人的リソースの効率化を実現します。 これらの分野で AI を活用することで、消費財企業はより効率的で革新的なブランド構築が可能になります。市場の変化に迅速に対応し、顧客ニーズを的確に捉えた商品開発やサービス提供が実現することで、ブランド価値の向上と競争力の強化が期待できます。 　 まとめ 消費財業界は、テクノロジーの急速な進歩により大きな変革期を迎えています。企業は、商品の製造、流通、マーケティング、評価の方法を改善するために必要なデータ、分析、ツールを利用できるようになりました。消費財企業が消費者に愛されるブランドを構築するためには、セキュリティに基づくデータ戦略の設定、サプライチェーン業務のモダナイズ、IT インフラストラクチャの変革、イノベーションのパイプラインの確立が重要です。 また、パーソナライズの強化、D2C の実現、商品の購入可能性の拡大、社会的責任と信頼性の一致、M&A 活動のモニタリングなど、長期的な考慮事項にも注目する必要があります。 本 eBook において、先進消費財企業の事例から、商品開発、製造、サプライチェーン、マーケティング、ユニファイドコマース、IT とデジタルトランスフォーメーションの 6 つの重要なソリューション分野における AWS の活用方法を学ぶことができます。AWS は、消費財ビジネスの業務と業績を変革する支援体制が整っています。消費財企業は、AWS の技術力とサービス、経験豊富なパートナーとビジネスイネーブラーを活用することで、スタートアップ並みの俊敏さで、チャンスを逃さず行動し、実践での効率性を高め、消費者に愛されるブランドを構築することができるのです。詳細についてはぜひ、本 eBook や その他の e-book をご参照ください。 消費財企業が成長するための極意 スマートストアテクノロジーの力を活用する 小売業のデジタルコマースを最適化する 4 つの重要なステップ 流通・小売・消費財企業のイノベーションを生成 AI で促進する 本ブログはソリューションアーキテクトの山下が執筆しました。

本ブログでは、消費財業界向けに発表した e-Book「 消費財企業が成長するための極意 」について紹介します。 消費財業界は、販売量と収益性の向上に焦点を当てた変革期を迎えています。 Deloitte の「 2024 Consumer Products Industry Outlook 」によると、72% もの経営幹部が、2024 年の業績目標を達成するためには販売数量を増やす必要があると答えています。販売量の増加は、収益、収益性、株主価値の向上を意味します。一方、消費者のし好の変化、競争激化、景気低迷、サプライチェーンの混乱などの要因はすべて、販売量停滞の一因となりかねません。成長を遂げるには、販売量と収益性のバランスが取れた戦略的なアプローチによる変革が必要です。この変革のカギとなるのが、クラウドテクノロジーとAI、特に生成 AI の活用です。 新たに公開された AWS の eBook では、 AWS が提供する包括的なクラウドソリューションを基盤として、消費財企業が成長するための方法を、IT とデジタルトランスフォーメーション、製品開発、消費財製造のスマート化、サプライチェーンの最適化、データドリブンマーケティング、e コマースという 6 つのビジネスの側面から、AI および AWS の活用について紹介しています。 IT とデジタルトランスフォーメーション ‐ AI で成果を生むための基盤を築く コード作成の高速化とエラー削減やデジタルトランスフォーメーションの加速と開発コスト削減という形で、AI の活用は開始されています。そして、IT とデジタルトランスフォーメーションは、AI 活用の基盤となり、強固なデータ戦略とモダンクラウドインフラストラクチャの構築が重要です。サイロ化されたデータをクラウドに集めてデータ基盤を確立してAIジャーニーをスタートするために、AWS は効率的なデータ管理に必要な柔軟性とスケーラビリティを提供します。そして生成 AI の導入により、開発プロセスの効率化やコスト削減が可能になります。 紹介されている顧客事例 Dole Packaged Foods は、AWS で稼働する Pillir の EdgeReady Cloud を活用して、製品発売プロセスを合理化しました。その結果、材料のマスターデータ管理コストを 30% 削減し、製品発売までの時間を短縮した事例を紹介しています。 製品開発 – 製品開発を最適化してイノベーションを起こす 成熟市場では、イノベーションが競争力維持の鍵となります。同じような商品だと価格競争になってしまうことも多く、そうならないためには製品開発の競争力が大事になります。AI は製品開発プロセスを革新し、消費者ニーズに合った画期的な製品の創出を支援します。また、生成 AI の導入により製品レビューの分析や新製品のアイデア創出が効率化され、市場投入までの時間短縮が可能になります。AWS は、AI やクラウドベーステクノロジーを最大限活用するためのインフラストラクチャ、サービス、ツール、ソリューションを提供し、企業が迅速な製品開発に集中できる環境を整えます。 紹介されている顧客事例 adidas は AI を活用して、販売実績、類似品、市場、競合他社に関する分析をまとめて、より適切な製品構成を決定しました。これにより、メンズの黒のパーカーの種類の最適化を実現しています。また15 万枚のシューズ画像で Stable Diffusion アルゴリズムをトレーニングし、迅速なアイデア創出と視覚化を実現している例についても紹介しています。 消費財製造のスマート化 – AI で製造コストを削減する Bain & Company によると、消費財業界の経営幹部の 54% が、2023 年の消費者支出削減の影響を大きく受けたと回答しています。消費者支出の削減への対応には、製品開発力だけでなく、AI を活用したスマートマニュファクチャリングによる、コスト削減も利益維持の鍵となります。AWS の製造業向けソリューションは、品質の向上、製造ラインのダウンタイムの削減、セキュリティ強化を実現し、製造オペレーションの変革を支援します。生成AIの導入により、機器のトラブルシューティングや診断が効率化され、ダウンタイムの削減ができる点についても紹介しています。 紹介されている顧客事例 Georgia-Pacific は、AWS パートナーである SAS の SAS Viya ソリューションを導入し、15,000 以上の機械学習モデルを実行しています。その結果、潜在的な機器の故障の警告を検出できるようになり、生産施設での計画外のダウンタイムを 30% 削減、さらに設備総合効率 (OEE) を 10% 向上できた事例となっています。 サプライチェーンの最適化 ‐ AI で俊敏性とレジリエンスを高める AI を活用したサプライチェーンの最適化は、効率的な製品配送と顧客満足度向上の要となります。予測の改善、在庫の最適化、マルチチャネル流通の実現により、企業の俊敏性とレジリエンスが高まります。生成 AI の導入により、複雑なサプライチェーンシナリオの分析や意思決定のサポートが可能になり、より戦略的なサプライチェーン管理が実現します。 紹介されている顧客事例 The Modern Milkman は、AWS パートナーの Peak と連携し、AI を活用した牛乳の需要予測を実装しました。これにより、サプライチェーンを全面的に合理化し、プロセスの効率を大幅に向上させ、食品廃棄を削減できています。向上した需要予測の精度とプロセスの効率性により、食品が傷まないようにする一方で、顧客にはこれまでどおり地元の農場の新鮮な商品を玄関先で受け取れ、新鮮な配達を実現できました。また、効率的な在庫管理プロセスにより、最大で週 3 回の注文を一晩で輸送および配達できるようになり、顧客体験の向上も実現しています。 データドリブンマーケティング ‐ 適切な消費者に適切なタイミングで訴求する データドリブンマーケティングは、効果的で強力なキャンペーンの実現と投資収益率の最大化を可能にします。顧客データプラットフォーム（ CDP ）の構築や、 AWS Clean Rooms などのツールの活用により、顧客データの力を最大限に引き出すことができます。生成AIの導入により、ターゲット顧客のセグメント化やパーソナライズされたコンテンツ作成が効率化され、より効果的なマーケティング活動が可能になります。 紹介されている顧客事例 水筒など飲料容器のメーカーの Pacific Market International（PMI） は、AWS パートナーの Amperity が提供する AI 搭載 CDP ソリューションを実装して分散している顧客データを統合し、統合カスタマービューを構築しました。その結果、高価格商品を買うセグメントが特定できて、そこに効果的なマーケティングを打つことができるようになり、それでクリックスルー率がが 350% 以上増加し、販売のコンバージョン率は 7 倍になりました。 e コマース – 消費者の購入機会を捉え接点を持つ eコマースにおける AI の活用は、オムニチャネル戦略と消費者直販（ D2C ）戦略の成功に不可欠です。需要計画、パーソナライズされたプロモーション、自動化されたカスタマーサービスなど、AI を活用することで販売機会を最大化できます。生成 AI の導入により、製品レビューの要約や検索体験の向上、インテリジェントなデジタルアシスタントの実現が可能となり、よりシームレスで魅力的な顧客体験を提供できます。 紹介されている顧客事例 L’Oréal Kerastase は、AWS パートナーの Valtech と協力して、ブラジルの消費者向けにシームレスでラグジュアリーなオンラインショッピング体験を 10 週間で構築しました。新しいプラットフォームにより、ブランドのサイトとバックエンドにおける e コマース機能が統合されていない部分が解消されてスムーズな UXを実現できました。これにより、デバイスやチャネルを問わずカートにアクセスできるようになり、ショッピング体験が向上したことで、カゴ落ちが減少しました。 まとめ 消費財企業が成長するための方法を IT とデジタルトランスフォーメーション、製品開発、消費財製造のスマート化、サプライチェーンの最適化、データドリブンマーケティング、e コマースという6つのビジネスの側面から、e-Book の一部を紹介しました。消費財業界では販売量と収益性に再びスポットが当たったことで、変革が進んでいます。AI は企業が優位に立つために必要な生産性と効率の向上をもたらしますが、AI を効果的に活用するには適切な戦略が必要です。AWS は、AI での成功を導く強固な基盤の設計と実装を支援します。AWS やパートナーが提供する AI などのクラウドベースソリューションは、お客様の成長の可能性を最大限に引き出すのに役立ちます。詳細についてはぜひ、本 eBook や その他の e-book をご参照ください。 スマートストアテクノロジーの力を活用する 小売業のデジタルコマースを最適化する 4 つの重要なステップ 流通・小売・消費財企業のイノベーションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの山下が執筆しました。

生成 AI が流通・小売・消費財業界にもたらす年間付加価値は 4,000 〜 6,600 億 USD と 試算 されています。多くの企業が生成 AI の導入を開始し、イノベーションや生産性向上を目指しています。2024 年には、マーケティング、カスタマーサービス、サプライチェーンなどの分野で AI ツールへの投資が検討されています。Amazon Web Services（AWS）は 25 年の経験を基に、エンタープライズグレードの生成 AI アプリケーションとインフラストラクチャを提供し、専門企業と提携して業界向けの AI ソリューションを展開しています。この e-book では、関連性の高いユースケースと導入のステップを紹介しています。本ブログはその概要と具体的なユースケースと関連する技術のハイライトを解説するものです。 生成 AI の導入を始めるには AWS は生成 AI を広く利用可能にし、流通・小売・消費財企業の変革を支援しています。生成 AI の効果的な導入には適切な戦略が必要で、以下の手順が推奨されます： 明確な目標を設定する 具体的で現実的なユースケースを特定する 最適な基盤モデル（FM）を選択する AWS のエキスパートやツールを活用する これらのステップを通じて、組織は生成 AI の導入を円滑に進め、イノベーションを促進できます。AWS は、 AWS Learning Needs Analysis ツールや AWS Skill Builder コースといった学習ツールを提供しています。AWS または AWS パートナーは、お客様が実行可能なロードマップを作成するお手伝いもしています。 生成 AI の導入における課題を検証する 流通・小売・消費財業界で生成 AI の競争が始まっています。導入には指針が必要で、技術とその影響の両面を考慮し、選択基準や成功指標、プロジェクト計画に反映させることが重要です。 生成 AI の活用事例: 流通・小売・消費財業界のユースケース AWS は小売業者と協働し、まず問題の最終的な解決策を構想し、そこを起点に逆算して考え、ビジネス目標を達成するために必要なタスクを特定します。この e-book では、さまざまなユースケースについて詳しく紹介しています。 ユースケース 1：消費者起点 生成 AI は、マーケティング、ショッピング、カスタマーサポートの各分野で顧客体験を向上させる強力なツールです。 マーケティングでは、消費者データの分析や、パーソナライズされたコンテンツ作成に活用できます。 ショッピングでは、AI スタイリストやバーチャル試着、ボイスコマースなどを通じて、最適な製品選びをサポートし、返品率の低減にも貢献します。 カスタマーサポートでは、AI チャットボットやエージェント支援システムにより、迅速な問題解決と顧客満足度の向上を実現します。 事例として、 Amazon Rufus があります。これは生成 AI を活用した自然言語で対応の可能なショッピングアシスタントで、Amazon の豊富なデータを基に、商品に関する質問への回答や比較、提案などを行い、消費者のショッピング体験を効率化・最適化します。シーンや目的に応じた買い物や商品カテゴリの比較、最適なおすすめ商品を見つけたり、商品詳細ページにいながら特定の商品について質問することができます。例えば、「ドリップ式とプアオーバー式（いわゆるハンドドリップ式）のコーヒーメーカーを比較してほしい」とユーザーが入力すると、それぞれの長所などを回答します。ユーザーがさらに「洗いやすいのはどっち」と質問すると「一般的にはドリップ式のほうが簡易」などと答えます。 ユースケース 2：製品起点 生成 AI は消費財企業の製品開発と市場投入を革新しています。顧客センチメント分析から新製品アイデアの創出、プロトタイプ作成、パッケージデザイン、品質確認、価格設定まで、幅広い用途があります。 The Very Group は、AWS の 生成 AI イノベーションセンター と協力し、AWS の技術を活用して高い精度で製品説明を作成するシステムを構築したことで製品の市場投入の速度を向上させました。 adidas は、大量の靴の画像データを用いて拡散アルゴリズムをトレーニングし、特定基準に基づく新しいランニングシューズデザインの生成を可能にしました。これにより、デザイナーは革新的なアイデアを得られ、創造性を高めることができます。 これらの事例は、生成 AI が製品開発プロセスを加速し、消費者ニーズへの対応を改善する可能性を示しています。 ユースケース 3：従業員起点 生成 AI は企業の日常業務を自動化し、効率性、従業員の定着率、品質を向上させることができます。特に、データレイクを持つ小売・消費財企業では、従業員への迅速な情報提供が可能になります。 従業員は自然言語でチャットボットに質問することで、在庫状況、機器の修理方法、過去の売上データなどの情報に簡単にアクセスできます。これにより、データに基づいたより良い意思決定が可能になります。また、生成ビジネスインテリジェンス（BI）を活用することで、実用的なインサイトやレポートの即時作成・共有も可能になります。 具体例として、 adidas の事例が挙げられます。同社は新入エンジニアが仕事を円滑に進められるようにチャットボットアシスタントを開発し、AWS 関連の質問に迅速に回答できるようにしました。 Amazon Titan Embeddings や Amazon Bedrock 、 LangChain を使用してアシスタントを構築しました。 さらに、 Amazon Q Developer を用いたパイロットプログラムも実施し、エンジニアのコーディング支援を提供しています。 adidas の Markus Rautert 氏は「Amazon Bedrock の導入により、インフラ管理の負担が軽減され、大規模言語モデルの開発プロジェクトの核心部分に集中できるようになりました。Amazon Bedrock を使用して、adidas のエンジニアは単一の会話型インターフェースを通じて、幅広い情報や回答を得ることができるようになりました」とコメントしています。 ユースケース 4：IT 起点 生成 AI は、プログラマーのコーディング効率を向上させます。大量のデータでトレーニングされた AI は、リアルタイムでコード案を生成し、複雑な作業を支援します。また、類似コードの検出や脆弱性のスキャン、修正提案も行い、開発プロセスを最適化します。 開始に適したツールとインフラストラクチャの選び方 目標を設定し、ユースケースを絞り込んだら、 次のことが可能になります。 生成 AI を活用したアプリケーションでユー ザー体験を変革する セキュアかつプライベートな生成 AI アプリケーションを簡単に構築してスケールする 最も高性能で低コストな生成 AI 向けインフラストラクチャのメリットを享受する データを差別化要因として活用する 1. 生成 AI を活用したアプリケーションでユーザーエクスペリエンスを変革する AWS には生成 AI を組み込んだ様々なアプリケーションが用意されており、今も開発が続けられています。自社にとって実現したいことが、すでに用意されているアプリケーションで解決されるのであれば、これを活用することは一つの選択肢です。例えば主要サービスの一つである Amazon Q は、コード生成、テスト、デバッグ機能を備え、複数ステップの計画・推論機能により開発者の要求に応じたコード生成が可能です。また、企業データリポジトリに接続し、データの要約、分析、対話を行うことで、従業員がより簡単に業務関連の情報にアクセスできます。この Amazon Q を使用した製品について、この e-book で紹介されているので、ご参照ください。 2. セキュアかつプライベートな生成 AI アプリケーションを簡単に構築してスケールする AWS は、あらゆる規模の組織や開発者が、生成 AI を組み込んだセキュアなアプリケーションを構築し、それをスケールさせるための環境を提供しています。主要なサービスである Amazon Bedrock を使うと、API を利用してさまざまな基盤モデルをアプリやシステムに組み込むことができます。モデルは複数の AI 企業から提供され、用途に合わせて簡単に切り替えられますし、自社のデータを用いたカスマイズやその評価、不適切な出力をフィルタする機能などが整っています。 実例として、 OfferUp の CTO Melissa Binde 氏は、Amazon Bedrock が提供するモデルの一つである、Amazon Titan Multimodal Embeddings を活用したセマンティック検索機能の実験について言及しています。「この新しいマルチモーダルモデルにより、キーワード検索の関連性が大幅に向上しています。 この進歩により、ユーザーマッチングの成功が大幅に促進され、買い手と売り手の両方に利益がもたらされます。」 3. 最も高性能で低コストな生成 AI 向けインフラストラクチャのメリットを 享受する AWS は、生成 AI を支える基盤モデル自体を自社で開発するのに最適なインフラストラクチャを提供しています。高性能の GPU ベース Amazon Elastic Compute Cloud （Amazon EC2）インスタンスや、専用アクセラレーターの AWS Trainium と AWS Inferentia を用意しており、これらを用いることで高性能で低コストな生成 AI 環境を作れます。 Databricks の事例では、AWS Trainium を使用して Mosaic MPT モデルのトレーニングを行い、高性能かつ低コストでスケーラブルな環境を実現しています。また、 Trainium2 の導入により、モデル構築の高速化と規模を拡大し、顧客が生成 AI アプリケーションの市場投入を加速させています。 4. データを差別化要因として活用する 生成 AI アプリケーションは大規模言語モデルだけで成立するわけではありません。自社で蓄えたデータを組み合わせて最適化することが必要になります。他社との差別化のために組織のデータを資産として活用します。そのためにはデータを蓄えるストレージやデータレイク、自社の様々なデータを統合するためのツールが必要です。そしてデータは資産であるため、セキュリティやガバナンスを確保することも重要です。AWS にはこれらのためのサービスが揃っています。 AWS パートナーとともに 生成 AI を活用する AWS の小売・消費財コンピテンシーパートナーは、生成 AI の実装を支援し、生産性向上、差別化された顧客体験の構築、イノベーションの加速を促進します。これらのパートナーは、製品開発、製造、サプライチェーン、ユニファイドコマースなど、多様な分野で AI を活用したビジネス価値創出を支援します。 効果的な導入のために、重要なユースケースの優先的な取り組み、ビジネスチームとテクノロジーチームの連携、AWS ワークショップの活用、PoC の実施、開発者のトレーニングが推奨されます。既に PoC を開始している場合は、ビジネス価値と ROI の測定、長期的な最適化計画、適切なインフラ導入、責任あるテクノロジー使用のためのコンプライアンスとガバナンスの確立が重要です。 まとめ 流通・小売業界、消費財業界のビジネスを成長させる方法については、 AWS にお問い合わせください。 流通・小売・消費財業界向け AWS の詳細はこちら 流通・小売・消費財業界のための生成 AI について また、AWS のパートナーは以下から探すことができます。 AWS リテールコンピテンシーパートナー を探す AWS 消費財パートナー を探す この e-book では AWS で生成 AI の導入を開始し、 変革とモダナイゼーションを加速する方法があることをご紹介しました。ぜひ、その他の e-book もご覧ください。 消費財企業が成長するための極意 スマートストアテクノロジーの力を活用する 小売業のデジタルコマースを最適化する 4 つの重要なステップ 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの松本が執筆しました。