AWS Community Days は世界中で盛んに開催されています。 AWS Community Day アルゼンチン にスポットライトを当てます。ここでは、 Jeff Barr が基調講演とトークショーを行い、かつて Bill Gates 氏を追ってマクドナルドに行ったときの面白い話など、Jeff の知恵をコミュニティと共有しました。 Jeff の経験について読む ことをお勧めします。 9 月 16 日週のリリース 私が注目したローンチは次のとおりです。先ずは GA リリースを見ていきましょう。 Amazon EC2 X8g インスタンスが一般公開されました – X8g インスタンス は AWS Graviton4 プロセッサを搭載しており、AWS Graviton2 ベースの Amazon EC2 X2gd インスタンスよりもパフォーマンスが最大 60% 向上しています。X8g インスタンスは、Graviton2 ベースの X2gd インスタンスよりも最大 3 倍大きい vCPU (最大 48 倍) とメモリ (最大 3 TiB) を備えた大きなサイズを提供します。 Amazon Redshift 向け Amazon Q 生成 SQL が一般公開されました – Amazon Redshift クエリエディタ の Amazon Q 生成 SQL は、Amazon Redshift 用のすぐに使えるウェブベースの SQL エディタです。生成 AI を使用してユーザーの意図、クエリパターン、スキーマメタデータを分析し、一般的な SQL クエリパターンを Amazon Redshift 内で直接特定します。これにより、ユーザーのクエリ作成プロセスが加速され、実用的なデータインサイトを引き出すのに必要な時間が短縮されます。 AWS SDK for Swift が一般公開されました 。 AWS SDK for Swift は、Apple プラットフォーム、AWS Lambda、および Linux ベースの Swift on Server アプリケーションから Amazon Web Services にアクセスするための、モダンで使いやすいネイティブな Swift インターフェイスを提供します。一般リリースされたので、お客様は本番環境のワークロードに AWS SDK for Swift を使用できます。詳細については、 AWS SDK for Swift デベロッパーガイド をご覧ください。 AWS Amplify が、非同期のサーバーサイドの関数呼び出しによる長時間実行タスクのサポートを開始 。デベロッパーは AWS Amplify を使用して、GraphQL API 応答をブロックすることなく、生成 AI モデル推論、バッチ処理ジョブ、メッセージキューイングなどの操作で Lambda 関数を非同期で呼び出すことができます。これにより、特に即時の応答が不要な場合や、長時間実行されているタスクをオフロードする必要があるシナリオで、応答性とスケーラビリティが向上します。 Amazon Keyspaces (Apache Cassandra 向け) がマルチリージョンテーブルの列追加のサポートを開始 – 今回のリリースにより、 Amazon Keyspaces (Apache Cassandra 向け) の既存のマルチリージョンテーブルのスキーマを変更して、新しい列を追加できます。レプリカリージョンの 1 つでスキーマを変更するだけで、Keyspaces はテーブルが存在する他のリージョンに新しいスキーマをレプリケートします。 Amazon Corretto 23 が一般公開されました – Amazon Corretto は OpenJDK の無償かつマルチプラットフォーム対応の本番環境向けディストリビューションです。Corretto 23 は OpenJDK 23 の機能リリースで、更新されたベクトル API、拡張されたパターンマッチングとスイッチ式などが含まれています。2025 年 4 月までサポートされます。 既存の Amazon OpenSearch Service ドメインに OR1 インスタンスを使用 – OpenSearch 2.15 では、既存のドメイン設定を更新し、データノードに OR1 インスタンスを選択するだけで、既存の Amazon OpenSearch Service ドメインに OR1 インスタンスを活用できます。これにより、OpenSearch 2.15 を実行しているドメインを、ブルー/グリーンデプロイを使用して OR1 インスタンスにシームレスに移行します。 Amazon S3 Express One Zone が、カスタマーマネージドキーによる AWS KMS のサポートを開始 – デフォルトでは、 S3 Express One Zone は S3 マネージドキー (SSE-S3) を使用してサーバー側の暗号化ですべてのオブジェクトを暗号化します。S3 Express One Zone はカスタマーマネージドキーをサポートしているため、データのセキュリティを暗号化して管理するためのオプションが増えました。S3 Express One Zone と SSE-KMS を併用する場合、S3 バケットキーは追加料金なしで常に有効になります。 AWS Chatbot を使用して Microsoft Teams や Slack から Amazon Bedrock エージェントとやり取りする – 以前は、お客様は Microsoft Teams または Slack でカスタムチャットアプリケーションを開発し、それを Amazon Bedrock のエージェント と統合する必要がありました。これで、エージェントエイリアスを AWS Chatbot チャネル設定に接続することで、チャットチャネルから Amazon Bedrock エージェントを呼び出すことができます。 マネージド GitLab ランナー向けの AWS CodeBuild サポート – お客様は、GitLab CI/CD ジョブイベントを受信してエフェメラルホストで実行するように AWS CodeBuild プロジェクト を設定できます。この機能により、GitLab ジョブを AWS とネイティブに統合できるようになり、IAM、AWS Secrets Manager、AWS CloudTrail、Amazon VPC などの機能を通じてセキュリティと利便性が向上します。 既存のサービスがさらに多くのリージョンでご利用いただけるようになりました。 Amazon Aurora PostgreSQL Optimized Reads が AWS GovCloud (米国) リージョンで利用できるように なりました。 Amazon DocumentDB が 欧州 (スペイン) および アフリカ (ケープタウン) リージョンで利用できるようになりました。 Amazon MSK は、Graviton3 ベースの M7G インスタンスのサポートが 欧州 (ロンドン) リージョン でも受けられるようになりました。 Amazon EC2 G6 インスタンス が スペインリージョン で利用可能になり、 High Memory インスタンスが アフリカ (ケープタウン) リージョン で利用できるようになりました。 AWS のその他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 EKS での安全なクラスター間通信 – Amazon VPC Lattice と Pod Identity を使用して EKS クラスター間のアプリケーション通信を保護する方法と、独自のマイクロサービスアプリケーションに適応する際に参考となる例を示します。 Cohere Rerank を使用して RAG パフォーマンスを向上させる – この記事では、Cohere Rerank を使用して RAG システムの検索効率と精度を向上させる方法に焦点を当てます。 AWS オープンソースのニュースと更新 – 同僚の Ricardo Sueiras が AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Ricardo のページ で最新情報をご確認ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Community Days  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催される AWS Community Day は、 イタリア (9 月27 日)、 台湾 (9 月28 日)、 サウジアラビア (9 月28 日)、 オランダ (10 月 3 日)、 ルーマニア (10 月 5 日) で開催されます。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 9 月 23 日週はここまでです。9 月 30 日週の Weekly Roundup もお楽しみに! — Abhishek この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本ブログは「 Methodology for incident response on generative AI workloads 」を翻訳したものとなります。 AWS カスタマーインシデント対応チーム (CIRT) は、生成 AI ベースのアプリケーションに関連するセキュリティインシデントの調査に使用できる方法論を開発しました。生成 AI ワークロードに関連するセキュリティイベントに対応するには、引き続き AWS セキュリティインシデント対応ガイド に記載されているガイダンスと原則に従う必要があります。生成 AI ワークロードでは、いくつかの追加要素も考慮する必要があるため、このブログ投稿で詳しく説明します。 本ブログでは、はじめに生成 AI ワークロードの一般的なコンポーネントについて説明します。次に、イベント発生前における準備と生成 AI ワークロードのインシデント対応方法論をご紹介します。インシデント対応方法論は、生成 AI ワークロードのセキュリティイベントをトリアージして対応する際に考慮すべき 7 つの要素で構成されています。最後に、方法論を検討するのに役立つインシデントの例を応用シナリオを使用してご紹介します。 生成 AI ワークロードのコンポーネント 図 1 に示すように、生成 AI アプリケーションには次の 5 つのコンポーネントが含まれます。 インフラストラクチャ、生成 AI アプリケーション、および組織のプライベートデータを所有または管理する組織。 生成 AI アプリケーション自体に特に関係のない組織内のインフラストラクチャ。これには、データベース、バックエンドサーバー、および Web サイトが含まれます。 生成 AI アプリケーション。これには以下が含まれます。 基盤モデル — 多数のパラメーターを持ち、膨大な量の多様なデータに基づいてトレーニングされた AI モデル。 カスタムモデル — 組織固有の要件に合わせて、組織の特定のデータやユースケースに基づいてファインチューニングまたはトレーニングされたモデル。 ガードレール — 生成 AI アプリケーションが希望する範囲内で動作することを保証するためのメカニズムまたは制約。例としては、コンテンツフィルタリング、安全上の制約、倫理ガイドラインなどがあります。 エージェント — 生成 AI アプリケーションが会社のシステムやデータソース全体で複数ステップのタスクを実行できるようにするワークフロー。 ナレッジベース — 生成 AI アプリケーションがアクセスして使用できるドメイン固有の知識、ルール、またはデータのリポジトリ。 トレーニングデータ — 検索拡張生成 (RAG) などの手法用のデータを含む、生成 AI アプリケーションのモデルのトレーニング、ファインチューニング、または拡張に使用されるデータ。 注 : トレーニングデータは組織の プライベートデータ とは異なります。生成 AI アプリケーションは通常、プライベートデータに直接アクセスすることはありませんが、一部の環境では設定によってアクセスが可能な場合もあります。 プラグイン — 生成 AI アプリケーションと統合して、特殊な機能を提供したり、外部サービスやデータソースにアクセスしたりできる追加のソフトウェアコンポーネントまたは拡張機能。 プライベートデータとは、生成 AI リソースまたはアプリケーションが通常の運用中に操作しないプライベートに保存されたお客様の機微データを指します。 ユーザーとは、生成 AI アプリケーションの操作や、アプリケーションにアクセスするアイデンティティです。人間でも人間以外 (機械など) でもかまいません。 図 1 : 生成 AI ワークロードの一般的なコンポーネント 生成 AI ワークロードでのインシデント対応に備える セキュリティイベントに備えるには、 「人」、「プロセス」、「テクノロジー」 の 3 つのドメインに渡って準備が必要です。準備内容の概要については、『セキュリティインシデント対応ガイド』の準備項目を参照してください。さらに、生成 AI ワークロードに関連するセキュリティイベントの準備には、以下を含める必要があります。 人材: インシデント対応スタッフとセキュリティ運用スタッフへの生成 AI に関するトレーニング — 担当スタッフが生成 AI の概念と組織で使用されている AI/ML サービスに精通していることを確認する必要があります。 AWS Skill Builder では、これら両方の科目に関する無料コースと有料コースの両方を提供しています。 プロセス: 新しいプレイブックの開発 — 生成 AI ワークロードに関連するセキュリティイベントのための新しいプレイブックを開発する必要があります。これらの開発方法の詳細については、以下のサンプルプレイブックを参照してください。 Amazon Bedrock セキュリティイベントへの対応 Amazon SageMaker セキュリティイベントへの対応 Amazon Q セキュリティイベントへの対応 各サービスのプレイブックを出発点として使用し、組織や各サービスの使用状況に合わせて変更することができます。 テクノロジー: 生成 AI アプリケーションのプロンプトと呼び出しをログに記録する — AWS CloudTrail で利用できるような基本的なログに加えて、アプリケーションに入力されるプロンプトと出力内容を分析できるように、 Amazon Bedrock モデルの呼び出しログを記録することを検討する必要があります。詳細については、「 Amazon Bedrock モデル呼び出しのログ記録 」を参照してください。CloudTrail データイベントのログは、Amazon Bedrock、Amazon Q、Amazon SageMaker でも利用できます。一般的なガイダンスについては、「 セキュリティインシデント対応のためのロギング戦略 」を参照してください。 重要: ログには機微情報が含まれる場合があります。この情報を保護するには、他のセキュリティログと同様に、これらのログへの最小権限アクセスを設定する必要があります。 データマスキング を使用して機微なログデータを保護することもできます。 Amazon CloudWatch では、 ロググループのデータ保護ポリシー を使用してデータをネイティブにマスクできます。 生成 AI ワークロードにおけるインシデント対応の方法論 準備項目が完了したら、生成 AI ワークロードのインシデント対応方法論を使用したアクティブな対応が可能になります。これは生成 AI アプリケーションに関連するセキュリティイベントを迅速にトリアージするのに役立ちます。 方法論には 7 つの要素があり、このセクションで詳しく説明します。各要素は、コンポーネントが別のコンポーネントと相互作用する方法や、コンポーネントを変更する方法を記述します。これらの要素を考慮することは、検知、分析、封じ込め、根絶、復旧の各段階を含むセキュリティインシデントの 運用段階 における行動の指針となります。 アクセス — 生成 AI アプリケーションのコンポーネントをホストする組織のアクセスパターンを特定し、それらのパターンからの逸脱や異常を調査します。アプリケーションが外部からアクセス可能か、または内部からアクセス可能かを確認します。 Amazon GuardDuty を使用すると、AWS 環境への異常なアクセスや潜在的な不正アクセスを特定しやすくなります。アプリケーションに外部からアクセスできる場合、脅威アクターは AWS 環境に直接アクセスできない可能性があり、 GuardDuty はそれを検出しません。アプリケーションへの認証の設定方法によって、不正アクセスの検出と分析の方法が決まります。 AWS アカウントまたは関連するインフラストラクチャへの不正アクセスの証拠がある場合は、関連する権限やタイムラインなど、不正アクセスの範囲を特定します。不正アクセスにサービスの認証情報 ( Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの認証情報など) が含まれる場合は、サービスに脆弱性がないか確認してください。 インフラストラクチャの変更 — サーバー、データベース、サーバーレスコンピューティングインスタンス、内部または外部の Web サイトなどの生成 AI アプリケーションをサポートするインフラストラクチャを確認して、アクセスまたは変更されたかを判断します。インフラストラクチャの変更を調査するには、CloudTrail ログを分析して対象範囲内のリソースの変更を調べたり、他のオペレーティングシステムログやデータベースアクセスログを分析します。 AI の変更 — ユーザーが生成 AI アプリケーションのコンポーネントにアクセスしたか、またそれらのコンポーネントに変更を加えたかを調査します。カスタムモデルの作成または削除、モデルの可用性の変更、生成 AI ロギング機能の改ざんまたは削除、アプリケーションコードの改ざん、生成 AI ガードレールの削除または変更など、不正アクティビティの兆候がないか確認します。 データストアの変更 — 設計または意図されたデータアクセスパターンを特定し、ユーザーが生成 AI アプリケーションのデータストアにアクセスしたかどうか、およびこれらのデータストアに変更を加えたかどうかを判断します。また、生成 AI アプリケーションへのエージェントの追加または変更も検討する必要があります。 呼び出し — 文字列やファイル入力を含む生成 AI モデルの呼び出しを分析して、プロンプトインジェクションやマルウェアなどの脅威がないかを確認します。 OWASP Top 10 for LLM は、呼び出し関連の脅威を理解するための出発点として使用できます。また、呼び出しログを使用して、プロンプトを分析して、プロンプトインジェクションの試みを示唆する可能性のある疑わしいパターン、キーワード、または構造がないか調べることができます。ログにはモデルの出力と応答も記録されるため、プロンプトインジェクションを示唆する特徴的でない、または安全でないモデルの動作を特定するための動作分析に役立ちます。ログ内のタイムスタンプを時系列分析に使用すると、組織的なプロンプトインジェクションの試みを経時的に検出し、モデル呼び出しを開始したユーザーまたはシステムに関する情報を収集できるため、潜在的な悪用の原因を特定するのに役立ちます。 プライベートデータ — 対象範囲の生成 AI アプリケーションが、個人データまたは機微データにアクセスが可能か確認します。次に、そのデータへの不正アクセスや改ざんがないか調べます。 代理行為 — 代理行為とは、アプリケーションが組織のリソースを変更したり、ユーザーに代わってアクションを実行したりする機能を指します。たとえば、生成 AI アプリケーションは、メールを送信するために使用されるコンテンツを生成し、そのために別のリソースまたは関数を呼び出すように構成されている場合があります。生成 AI アプリケーションに他の機能を呼び出す機能があるかどうかを判断する必要があります。次に、不正な変更が行われたのか、それとも生成 AI アプリケーションが不正な機能を呼び出したのかを調査します。 次の表は、方法論の 7 つの要素に取り組むのに役立ついくつかの質問を示しています。回答を参考にしてください。 トピック トピックに対する質問 アクセス コンピューティング環境にまだアクセスできますか？ あなたの組織に不正アクセスの証拠は残っていますか？ インフラストラクチャの変更 サポートするインフラリソースへのアクセス、および変更が実施されましたか？ AI の変更 AI モデル、コード、リソースへのアクセス、および変更が実施されましたか？ データストアの変更 データストア、ナレッジベース、エージェント、プラグイン、またはトレーニングデータへのアクセス、および変更が実施されましたか？ 呼び出し どのようなデータ、文字列、ファイルがモデルへの入力として使用されましたか？ どのようなプロンプトが送信されましたか？その結果、どのような応答が生成されましたか？ プライベートデータ 生成AIリソースはどのような個人データや機微データにアクセスできますか？ プライベートデータの変更や改ざんは発生していませんか？ 代理行為 生成 AI リソースを使用して組織内でコンピューティング サービスを開始できますか? 生成 AI リソースに変更を加える権限がありますか? 不正な変更が加えられましたか? インシデントの例 調査と対応のための方法論の使い方を見ていきましょう。ここでは不正なユーザーが公開されたコードリポジトリに流出した認証情報を使用して、 AWS 上でホストされている生成 AI アプリケーションに侵入するというセキュリティイベントの例を扱います。私たちの目標は、どのリソースがアクセス、変更、作成、削除されたかを判断することです。 AWS で生成 AI のセキュリティイベントを調査するために確認すべき主なログソースは以下の通りです: CloudTrail CloudWatch VPC Flow Logs Amazon Simple Storage Service (Amazon S3) データイベント (組織の S3 バケットへのアクセスの証拠用) Amazon Bedrock モデル呼び出しのログ (アプリケーションがこのサービスを使用している場合) アクセス 生成 AI アプリケーションのアクセス分析は、標準的な 3 層ウェブアプリケーションのアクセス分析と似ています。まず、組織が AWS アカウントにアクセスできるかどうかを判断します。AWS アカウントのルートユーザーのパスワードを紛失または変更した場合は、 パスワードをリセット します。次に、ルートユーザーの 多要素認証（MFA）デバイス をすぐに有効にすることを強くお勧めします。これにより、脅威アクターがルートユーザーでアクセスするのを防ぐことができます。 次に、アカウントへの不正アクセスが続いているかどうかを確認します。 AWS Identity and Access Management (IAM) と AWS Security Token Service (Amazon STS) によって記録された変更を伴うアクションを特定するには、GitHub の「 AWS アカウントの認証情報が侵害された場合のセキュリティプレイブック 」の「 分析 」セクションを参照してください。最後に、アクセスキーがパブリックリポジトリやアプリケーションコードに保存されていないことを確認してください。代替案については、「 長期的なアクセスキーに対する代替方法 」を参照してください。 インフラストラクチャの変更 アプリケーションのインフラストラクチャの変更を分析するには、 コントロールプレーンとデータプレーン の両方を考慮する必要があります。この例では、生成 AI アプリケーションのダウンストリームコンポーネントへの認証に Amazon API Gateway が使用され、他の付帯的なリソースがアプリケーションとやり取りしていたとします。CloudTrail でこれらのリソースに対するコントロールプレーンの変更を確認することもできますが、リソースのオペレーティングシステムで行われた変更を確認するには、追加のログ記録を有効にする必要があります。この要素に関して CloudTrail で見つかる可能性のあるコントロールプレーンイベントの一般的な名称は次のとおりです。 ec2:RunInstances ec2:StartInstances ec2:TerminateInstances ecs:CreateCluster cloudformation:CreateStack rds:DeleteDBInstance rds:ModifyDBClusterSnapshotAttribute AI の変更 許可されていない変更には、システムプロンプト、アプリケーションコード、ガードレール、およびモデルの可用性が含まれますが、これらに限定されません。AWS がホストする生成 AI リソースへの内部ユーザーアクセスは CloudTrail に記録され、次のいずれかのイベントソースで表示されます。 bedrock.amazonaws.com sagemaker.amazonaws.com qbusiness.amazonaws.com q.amazonaws.com 以下は、このシナリオ例における生成 AI リソースログの改ざんを表す CloudTrail のイベント名の例をいくつか示しています。 bedrock:PutModelInvocationLoggingConfiguration bedrock:DeleteModelInvocationLoggingConfiguration AI/ML モデルのサービス設定へのアクセスを表す CloudTrail の一般的なイベント名は次のとおりです。 bedrock:GetFoundationModelAvailability bedrock:ListProvisionedModelThroughputs bedrock:ListCustomModels bedrock:ListFoundationModels bedrock:ListProvisionedModelThroughput bedrock:GetGuardrail bedrock:DeleteGuardrail このシナリオ例では、不正なユーザーが AWS アカウントにアクセスしています。ここで、侵害されたユーザーに、すべてのリソースへのフルアクセスを許可するポリシーが添付されているとします。このアクセスにより、権限のないユーザーは Amazon Bedrock の各コンポーネントを列挙し、アプリケーションの一部であるナレッジベースとガードレールを特定できます。 その後、不正なユーザーは Amazon Bedrock 内の他の 基盤モデル (FM) へのモデルアクセスをリクエストし、既存のガードレールを削除します。他の基盤モデルにアクセスできるということは、不正なユーザーが生成 AI アプリケーションを自分の目的で使用しようとしていることを示している可能性があり、ガードレールの削除により、モデルによるフィルタリングや出力チェックが最小限に抑えられます。AWS では、 IAM ポリシーとリソースベースのポリシー を使用してきめ細かなアクセス制御を実装し、必要な Amazon Bedrock リソース、 AWS Lambda 関数、およびアプリケーションに必要なその他のコンポーネントのみへのアクセスを制限することを推奨します。また、Amazon Bedrockなどの重要なコンポーネントや生成 AI アプリケーションの他のコンポーネントにアクセスできる IAM ユーザー、ロール、サービスアカウントには、MFA の使用を強制する必要があります。 データストアの変更 通常、データストアやナレッジベースの使用およびアクセスはモデル呼び出しを通じて行います。Amazon Bedrock の場合は、 bedrock:InvokeModel という API を呼び出します。 ただし、不正なユーザーが環境にアクセスした場合、生成 AI アプリケーションが統合するデータソースとナレッジベースを作成、変更、または削除できます。これにより、データまたはモデルの流出または破壊、データ汚染が発生し、モデルのサービス拒否状態が発生する可能性があります。以下は、このシナリオ例の AI/ML データソースへの変更を表す CloudTrail の一般的なイベント名です。 bedrock:CreateDataSource bedrock:GetKnowledgeBase bedrock:DeleteKnowledgeBase bedrock:CreateAgent bedrock:DeleteAgent bedrock:InvokeAgent bedrock:Retrieve bedrock:RetrieveAndGenerate 実行可能なアクションの完全なリストについては、 Amazon Bedrock API リファレンス を参照してください。 このシナリオでは、不正なユーザーが生成 AI アプリケーションへのフルアクセス権を持ち、ある程度の一覧の取得が行われたことを確認しました。その後、不正なユーザーが生成 AI アプリケーションのナレッジベースである S3 バケットを特定し、不正確なデータをアップロードしたため、LLM が破損しました。この脆弱性の例については、LLM アプリケーションの OWASP TOP 10 の「 LLM03 訓練データの汚染 」セクションを参照してください。 呼び出し Amazon Bedrock は特定の API を使用して モデル呼び出し を行います。Amazon Bedrock のモデルが呼び出されると、CloudTrail はそのモデルをログに記録します。ただし、生成 AI モデルに送信されたプロンプトと、そこから受信した出力応答を確認するには、モデル呼び出しのログ記録を設定しておく必要があります。 これらのログは非常に重要です。なぜなら、脅威アクターがモデルを使ってデータストアから情報を引き出そうとしたり、モデルが学習またはファインチューニングされたデータを開示しようとしたかどうかなど、重要な情報を明らかにする可能性があるからです。たとえば脅威アクターが、機微データを抽出したり、セキュリティコントロールをバイパスしたり、ポリシーに違反するコンテンツを生成したりするように巧妙に作りこまれたプロンプトをモデルに与えようとしたかどうかが、ログから明らかになることがあります。ログを使用すると、セキュリティイベントで使用される可能性のある誤った情報、スパム、またはその他の悪意のある出力を生成するためにモデルが使用されたかどうかもわかります。 注 : Amazon Bedrock などのサービスでは、呼び出しログの記録はデフォルトで無効になっています。可能な場合は、生成 AI サービスのデータイベントとモデル呼び出しのログ記録を有効にすることをお勧めします。ただし、プライバシーや法的な理由から、組織によっては呼び出しログを取得して保存したくない場合があります。一般的な懸念事項の 1 つは、ユーザーが機微データをインプットとして入力することです。これにより、保護する資産の範囲が広がります。これはビジネス上の決定であり、考慮に入れる必要があります。 このシナリオの例では、モデル呼び出しのログ記録が有効になっていないため、インシデント対応者が呼び出しログを収集して、不正呼び出しに関するモデルへの入力または出力データを確認できなかったとします。インシデント対応者は、 LLM からのプロンプトとそれに続く応答を特定することができませんでした。このログを有効にしないと、呼び出し要求に関連するリクエストデータ、応答データ、メタデータ全体を確認することもできませんでした。 Amazon Bedrock のモデル呼び出しのログ記録に含まれる可能性のあるイベント名には、次のものが含まれます。 bedrock:InvokeModel bedrock:InvokeModelWithResponseStream bedrock:Converse bedrock:ConverseStream 以下は、Amazon Bedrock モデル呼び出しログ記録のログエントリのサンプルです。 図 2: プロンプトと応答を含むモデル呼び出しログのサンプル プライベートデータ アーキテクチャの観点から見ると、生成 AI アプリケーションは組織のプライベートデータに直接アクセスすべきではありません。生成 AI アプリケーションのトレーニングに使用されるデータまたは RAG 用のデータをデータストアデータとして分類し、プライベートデータから分離する必要があります。ただし、生成 AI アプリケーションがプライベートデータを使用する場合を除きます（たとえば、生成 AI アプリケーションが患者の医療記録に関する質問に答える必要がある場合）。組織のプライベートデータを生成 AI アプリケーションから確実に分離する 1 つの方法は、 別のアカウント を使用し、最小権限の原則に従って必要に応じて認証と認可を行うことです。 代理行為 LLM における 過剰な代理行為 とは、AI システムが過度の自律性や意思決定力を持ち、意図せず潜在的に有害な結果をもたらすことを指します。これは、LLM が不十分な監視や制約、または人間の価値観との整合性が不十分な状態で導入された場合に発生する可能性があります。その結果、多くの人間が有益または倫理的と考えるものとは異なる選択をモデルが行うことになります。 このシナリオの例では、生成 AI アプリケーションには、アプリケーションが必要としないサービスに対する過剰な権限を持っています。アプリケーションコードが Amazon Simple Email Service (Amazon SES) へのフルアクセス権を持つ実行ロールで実行されていたとします。これにより、LLM がプロンプトに応答して不正なユーザーに代わってスパムメールを送信する可能性があります。生成 AI アプリケーションプラグインとエージェントの権限と機能を制限することで、これを防ぐことができます。詳細については、LLM08 過剰な代理行為の証拠である OWASP LLM Top 10 を参照してください。 調査中にログを分析する際、 SourceIpAddress フィールドと UserAgent フィールドの両方が生成的な AI アプリケーション (たとえば、 sagemaker.amazonaws.com 、 bedrock.amazonaws.com 、 q.amazonaws.com ) に関連付けられます。他のサービスから一般的に呼び出されたり呼び出されたりする可能性のあるサービスの例としては、Lambda、Amazon SNS、Amazon SES などがあります。 結論 生成 AI ワークロードに関連するセキュリティイベントに対応するには、引き続き AWS セキュリティインシデント対応ガイド に記載されているガイダンスと原則に従う必要があります。ただし、これらのワークロードでは、いくつかの追加要素も考慮する必要があります。 本ブログで紹介した方法論を参考にして、これらの新しい要素に対応することができます。この手法は、生成 AI アプリケーションの使用が不正使用の対象または仕組み、あるいはその両方となるインフラストラクチャへの不正アクセスを調査する場合に参考になります。この方法論により、生成 AI ワークロードに関連するセキュリティインシデントに備えて対応するための体系的なアプローチが可能になり、これらの重要なアプリケーションのセキュリティと整合性を維持するのに役立ちます。 生成 AI アプリケーションを設計するためのベストプラクティスの詳細については、「 AWS セキュリティリファレンスアーキテクチャ用の生成 AI 」を参照してください。一般的な生成 AI アプリケーションの戦術的緩和策については、「 セキュアデザインのためのブループリントとアンチパターンへの緩和戦略 」を参照してください。 この投稿について質問がある場合は、 AWS セキュリティ、アイデンティティ、コンプライアンス re: Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Anna McAbee Anna は、AWS で金融サービス、生成 AI、インシデント対応を専門とするセキュリティスペシャリストソリューションアーキテクトです。仕事以外では、Anna はテイラー・スウィフト、フロリダ・ゲイターズのフットボールチームを応援したり、ワインテイスティングをしたり、世界中を旅したりするのを楽しんでいます。 Steve De Vera Steve は AWS カスタマーインシデント対応チーム (CIRT) のマネージャーです。アメリカンスタイルの BBQ に情熱を注いでおり、BBQ コンテストの認定の審査員も務めています。彼は Brisket という名前の犬を飼っています。 AJ Evans AJ は AWS カスタマーインシデント対応チーム (CIRT) のセキュリティエンジニアです。記入犯罪とネットワーク侵入を専門に扱った元米国シークレットサービスの特別捜査官としての経験を活かして、AWS のお客様を保護しています。最新のサイバー脅威に対応していないときは、AJ はゲーム、音楽演奏、カスタム PC の構築、自作の 3D プリントを楽しんでいます。 Jennifer Paz Jennifer は 10 年以上の経験を持つセキュリティエンジニアで、現在は AWS カスタマーインシデント対応チーム (CIRT) に所属しています。Jennifer は、お客様がセキュリティ上の課題に取り組むのを支援し、複雑なソリューションを実装してセキュリティ態勢を強化することを楽しんでいます。仕事をしていないときは、Jennifer は熱心なウォーカー、ジョガー、ピックルボール愛好家、旅行者、そして美食家であり、常に新しい料理のへの探求を求めています。 翻訳はプロフェッショナルサービス本部の高橋、藤浦が担当しました。

Gartner の 2024 Magic Quadrant for DaaS (Desktop as a Service) では、AWS が初めてリーダーに位置付けられました。2023 年、私たちはチャレンジャーとして認められました。これは、ライセンスポータビリティ ( Microsoft 365 Apps for Enterprise を含む )、地理的戦略、およびコストの最適化とオートメーションに重点を置いた運用能力を備えた多様な仮想デスクトップサービスのポートフォリオを提供することにより、幅広いお客様のニーズを満たすという当社の取り組みの成果であると考えています。また、仮想デスクトップサービスの各側面を管理するための使いやすいインターフェイスに重点を置いているため、お客様がサードパーティーのツールを利用する必要はほとんどありません。 詳細については、 Gartner の 2024 Magic Quadrant for Desktop as a Service (DaaS) の全文をご覧ください。 AWS DaaS サービス DaaS サービスのラインナップ ( エンドユーザーコンピューティング ポートフォリオの一部) を簡単に見てみましょう。 Amazon WorkSpaces ファミリー – 2014 年の初め に最初に発売され、それ以来頻繁に強化されてきた Amazon WorkSpaces は、クラウドで Microsoft Windows、Ubuntu、Amazon Linux、または Red Hat Enterprise Linux を実行するデスクトップコンピューティング環境を提供します。リモートワーカーやハイブリッドワーカー、ナレッジワーカー、デベロッパーワークステーション、学習環境をサポートするように設計された WorkSpaces は、16 の AWS リージョンで、GPU 搭載 グラフィックス G4dn バンドル を含む 6 種類のバンドルサイズからお選びいただけます。 WorkSpaces Personal は、各ユーザーに永続的なデスクトップを提供します。アプリケーションをインストールしてファイルやデータを保存する必要があるデベロッパーやナレッジワーカーなどに最適です。ユーザーが常設デスクトップ (コンタクトセンター、トレーニング、仮想学習、バックオフィスへのアクセスなど) を必要としない場合は、 WorkSpaces Pools を使用して管理を簡素化し、コストを削減できます。 WorkSpaces Core は、 Citrix 、 Leostream 、 Omnissa 、 Workspot などのサードパーティーの VDI ソリューションと連携するように設計されたマネージド仮想デスクトップインフラストラクチャを提供します。 Amazon WorkSpaces クライアントはデスクトップとタブレットで利用でき、ウェブアクセス ( Amazon WorkSpaces セキュアブラウザ ) と Amazon WorkSpaces シンクライアント を利用すると、さらに多くの選択肢があります。Microsoft の適切な Windows 10 または 11 デスクトップライセンスをお持ちの場合は、 クラウドに独自のライセンスを持ち込んで (BYOL とも)、専用のハードウェア上で実行できます。 Amazon WorkSpaces ファミリー について読んだり、 WorkSpaces の機能 を確認したりして、WorkSpaces でできることについて詳しく知ることができます。 Amazon AppStream 2.0 – 2016 年後半にリリースされた Amazon AppStream では、コードを記述したり、アプリケーションをリファクタリングしたりすることなく、SaaS アプリケーションやデスクトップアプリケーションに瞬時にストリーミングでアクセスできます。インフラストラクチャを管理しなくても、アプリケーションを簡単にスケールして世界中のユーザーが利用できるようにすることができます。コンピューティング、メモリ、ストレージ、GPU、およびオペレーティングシステムの幅広いオプションにより、リモートワーカーの活動の幅を広げると同時に、自動スケーリングを利用してオーバープロビジョニングを回避できます。 Amazon AppStream には、常時オン (インスタント接続)、オンデマンド (起動まで 2 分)、調整可能 (予測できない需要に対応) の 3 種類の フリートタイプ があります。料金はタイプによって異なり、Windows と Linux の場合は 1 秒あたり、1 時間単位で細かく設定されています。詳細については、 Amazon AppStream 2.0 の料金 をご覧ください。 – Jeff ; Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価やその他認定を受けたベンダーのみを選択するようテクノロジーユーザーに勧告するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 GARTNER は、Gartner の登録商標およびサービスマークです。Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。All rights reserved. グラフィックは、Gartner が発行した大規模な調査文書の一部であり、文書全体の文脈で評価されるべきものです。ガートナーのドキュメントは、AWS からのリクエストに応じて入手可能です。 原文は こちら です。

Graviton 4 を搭載し、メモリを最適化した X8g インスタンスは、現在、最大 3 TiB の DDR5 メモリと最大 192 個の vCPU を備えた、10 の仮想サイズと 2 つのベアメタルサイズで利用できるようになりました。X8g インスタンスは、これまでで最もエネルギー効率が良く、これまでで同等の EC2 Graviton インスタンスの中で最高の料金パフォーマンスとスケールアップ機能を備えています。メモリと vCPU の比率が 16 対 1 のこれらのインスタンスは、Electronic Design Automation、インメモリデータベースとキャッシュ、リレーショナルデータベース、リアルタイム分析、およびメモリに制約のあるマイクロサービス向けに設計されています。インスタンスはすべての高速物理ハードウェアインターフェイスを完全に暗号化し、 AWS Nitro System と Graviton4 のセキュリティ機能も追加されています。 5 万社を超える AWS のお客様が、150 を超える Graviton 搭載インスタンスの既存のラインアップを既に利用しています。 Valkey 、 Redis 、 Apache Spark 、 Apache Hadoop 、 PostgreSQL 、 MariaDB 、 MySQL 、 SAP HANA Cloud など、さまざまなアプリケーションを実行しています。新しい X8g インスタンスは、12 種類のサイズで利用でき、スケールアップ (より大きなインスタンスを使用) とスケールアウト (より多くのインスタンスを使用する) のどちらかを選択できるため、上記のアプリケーションにとってさらに優れたホストとなります。また、現在個別のインスタンスで実行されているメモリの使用量が多い既存のワークロードの柔軟性も高まります。 インスタンス 前世代 (X2gd) インスタンスと比較すると、X8g インスタンスは 3 倍のメモリ、3 倍の vCPU、2 倍以上の EBS 帯域幅 (40 Gbps 対 19 Gbps)、2 倍のネットワーク帯域幅 (50 Gbps 対 25 Gbps) を備えています。 X8g インスタンス内の Graviton4 プロセッサは、X2gd インスタンスの Graviton2 プロセッサの 2 倍 (2 MiB 対 1 MiB) のコアあたり L2 キャッシュを備え、メモリ帯域幅が 160% 高く、コンピューティングパフォーマンスを最大 60% 向上させることができます。 X8g インスタンスは、第 5 世代の AWS Nitro System および Graviton4 プロセッサを使用して構築されています。これには、命令レベルで制御フローを妨害しようとする低レベルの攻撃に対する保護を提供する Branch Target Identification (BTI) などの追加のセキュリティ機能が組み込まれています。これと Graviton4 のその他のセキュリティ機能の詳細については、「 Amazon の新しい CPU がサイバーセキュリティの脅威にどのように対処するか 」を読み、 re:Invent 2023 AWS Graviton セッションをご覧ください。 仕様はこのようになっています。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 x8g.medium 1 16 GiB 最大 10 Gbps 最大 12.5 Gbps x8g.large 2 32 GiB 最大 10 Gbps 最大 12.5 Gbps x8g.xlarge 4 64 GiB 最大 10 Gbps 最大 12.5 Gbps x8g.2xlarge 8 128 GiB 最大 10 Gbps 最大 15 Gbps x8g.4xlarge 16 256 GiB 最大 10 Gbps 最大 15 Gbps x8g.8xlarge 32 512 GiB 10 Gbps 15 Gbps x8g.12xlarge 48 768 GiB 15 Gbps 22.5 Gbps x8g.16xlarge 64 1,024 GiB 20 Gbps 30 Gbps x8g.24xlarge 96 1,536 GiB 30 Gbps 40 Gbps x8g.48xlarge 192 3,072 GiB 40 Gbps 50 Gbps x8g.metal-24xl 96 1,536 GiB 30 Gbps 40 Gbps x8g.metal-48xl 192 3,072 GiB 40 Gbps 50 Gbps インスタンスは ENA 、 ENA Express 、および EFA Enhanced Networking をサポートしています。上の表からわかるように、これらは十分な量の EBS 帯域幅を提供し、 io2 Block Express 、 EBS 汎用 SSD 、 EBS プロビジョンド IOPS SSD を含むすべての EBS ボリュームタイプ をサポートしています。 稼働中の X8g インスタンス vCPU あたり 16 GiB、またはインスタンスあたり最大 3 TiB のメモリを使用できるアプリケーションとユースケースを見てみましょう。 データベース – X8g インスタンスにより、SAP HANA と SAP Data Analytics Cloud は、以前よりも大規模で野心的なワークロードを処理できるようになりました。Graviton4 搭載インスタンス上で実行された SAP は、Graviton3 インスタンスで実行されている同じワークロードと比較して、分析ワークロードのパフォーマンスが最大 25%、トランザクションワークロードのパフォーマンスが最大 40% 向上したことを測定しました。X8g インスタンスにより、SAP は Graviton ベースの使用をさらに大規模なメモリバウンドソリューションにまで拡大できます。 Electronic Design Automation – EDA ワークロードは、Graviton、Trainium、Inferentia などの新世代のチップや、ニトロシステムのビルディングブロックを形成するチップの設計、テスト、検証、テープアウトのプロセスの中心です。AWS をはじめとする多くのチップメーカーは、これらのワークロードに AWS クラウド を採用し、規模と弾力性を利用して設計プロセスの各段階に適切な量のコンピューティング能力を供給しています。これにより、エンジニアは結果を待たずに済むため、より迅速にイノベーションを進めることができます。これは、2022 年後半から 2023 年初頭にかけて Graviton4 の開発を支援するために使用されたクラスターの 1 つからの長期スナップショットです。ご覧のとおり、このクラスターは大規模に稼働しており、ピーク時には通常の使用量の 5 倍にもなります。 毎日および毎週のアクティビティが急増し、テープアウトフェーズでは全体的な使用量が飛躍的な伸びがあることがわかります。クラスター内のインスタンスはサイズスペクトルの中でも大きいため、ピークは同時に稼働している数十万のコアを表しています。必要なときにコンピューティングをスピンアップし、不要な場合はダウンできるため、ハードウェアに専用の投資をしなくても、これまでにない規模で利用できます。 新しい X8g インスタンスにより、当社と EDA のお客様は、Graviton プロセッサでさらに多くのワークロードを実行できるようになり、コストを削減し、エネルギー消費量を削減すると同時に、新製品をこれまで以上に迅速に市場に投入できるようになります。 今すぐご利用いただけます X8g i インスタンスは、9 月 18 日から米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト) の各 AWS リージョンにおいて、オンデマンド、スポット、リザーブドインスタンス、Savings Plan、ハードウェア専有インスタンス、専有ホスト形式でご利用いただけます。詳細については、 X8g ページ をご覧ください。 原文は こちら です。

本ブログは、小売業向け AWS の e-book 「小売業のデジタルコマースを最適化する 4 つの重要なステップ」の概要と、具体的なユースケースと関連する技術のハイライトを解説するものです。このガイドは、クラウドで次世代テクノロジーを活用し、小売業界を変革する方法に関心を持っている小売業界および IT 業界のビジネスリーダーを対象としています。 クラウドによる e コマースの変革 米国における 2023 年の e コマース売上高は 1 兆 1,187 億 USD（前年比 7.6% 増）で、総売上高の 15.4% を占め、世界全体では 7.4 兆 USD に達しています。小売企業は優れた購買体験やカスタマーサービスを提供するため、スマートなデジタルコマースプラットフォームに注目しています。 生成 AI などの革新的な技術が e コマースに新たな機会をもたらし、先進企業はフルフィルメントの自動化やパーソナライズされた顧客体験の提供を行っています。多くの大規模小売企業は、従来の e コマースに代わり、新しいデジタルアーキテクチャに投資しています。デジタルコマースはオムニチャネル体験を提供し、俊敏で柔軟性があり、費用対効果の高いプラットフォームであることが不可欠です。リアルタイムストリーミングや会話型コマース、パーソナライゼーションなどの機能により、新たな消費者層へのリーチやコンバージョン率の向上に役立ちます。 モダナイゼーションのステップ：デジタルコマースの可能性を引き出すための 4 つのステップ AWS は小売企業向けに、e コマースプラットフォームを構築するための 4 段階のプロセスを推奨しています。これは、既存のデジタル投資を活用しつつ、クラウド機能を導入することで、迅速な成功と優れた顧客体験の提供を目指すものです。 俊敏で費用対効果の高いデジタルコマースプラットフォームを構築する パーソナライズされた没入型の体験を提供してコンバージョン率を高める 革新的なソリューションでより多くの消費者にリーチする 消費者の期待に応え、それを上回る ステップ 1：俊敏で費用対効果の高いデジタルコマースプラットフォームを構築する 小売企業の目標は、チャネル間でスムーズかつ切れ目のない顧客体験を実現することです。これには俊敏で費用対効果の高いデジタルコマースが不可欠です。クラウドへの移行により、企業はその多機能性を活用して費用対効果を得られます。 モダナイズされた IT インフラを持つ小売企業は、マイクロサービスアーキテクチャを導入し、個別のビジネス機能を API で組み合わせることができます。これによりコマースアプリケーションを大規模に構築できます。 また、ヘッドレスコマースの手法により、バックエンドサービスをフロントエンド（POSシステム、e コマースサイト、モバイルアプリなど）から分離します。これらの手法により、企業はどのチャネルからでも一貫した顧客体験を提供し、さらにその体験をパーソナライズして、コスト削減とイノベーション促進を実現できます。 AWS への移行で、企業はコストを最大 66% 削減しながら、スケーラビリティ、柔軟性、セキュリティを向上させられます。 小売企業は、レガシーアプリケーションをクラウドに移行することで、モダンなデジタルコマースプラットフォームへの移行を開始できます。徐々にマイクロサービスベースのプラットフォームへの投資を増やしながら、古いシステムを段階的に廃止できます。また、業界団体への加入は市場での優位性獲得に役立ちます。AWS は 2022 年に MACH Alliance に加盟し（関連 ブログ ）、小売企業が自由にソリューションを組み合わせ、新機能を提供し、優れた顧客体験を構築できる共通の e コマースアーキテクチャの構築を支援しています。 例えば、英国第 2 位のスーパーマーケットチェーン Sainsbury’s は、AWS への移行により、年に 5～6 回だったプロダクトリリースが 1 日に複数回行われるようになり、カスタマーエンゲージメントが 5 倍に増加しました。 ステップ 2：パーソナライズされた没入型の体験を提供してコンバージョン率を高める e コマースウェブサイトは、優れた顧客体験を通じたコンバージョン率の向上を目指しています。これには購入プロセスから「フリクション」、つまりは煩雑さを減らすことが重要です。ページ読み込み速度の改善、検索の効率化、チェックアウトの簡素化などが効果的です。AR（拡張現実）、パーソナライズ、ライブストリーミングなどの新機能導入も、顧客満足度とロイヤルティの向上に貢献します。 AWS は継続的に新しい e コマースツールやソリューションに投資し、パートナーコミュニティを拡大しています。AWS への移行により、企業は既存のパッケージツールを活用してデジタルコマースの運用を効率化し、コンバージョン率と売上を向上できます。これにより企業はリスクと資源を抑えつつ、革新的な商品開発が可能になります。 AWS for Retail は、没入型小売体験の創出に必要な高度なコンピューティング能力を提供し、新世代の顧客体験をサポートします。 AWS とそのパートナーは、小売企業向けに多様なソリューションを提供しています。これらは顧客体験の最適化、運用効率の向上、売上増加を目的としており、以下のようなソリューションがあります。 Amazon Personalize によるパーソナライゼーション Amazon Interactive Video Service と Firework を使用したライブストリーミングと動画内ショッピング Amazon OpenSearch Service や Algolia 、 Constructor などによる強力な検索機能 Amazon CloudFront による高速コンテンツ配信 Amazon Lex を利用したチャットボット Hexa によるモバイルでの 3D 商品表示とバーチャル試着 Matterport と Obsess を活用した仮想ストア 企業は 3D コマース、AR、バーチャル試着などを活用してオンラインで実店舗に近い体験を提供できます。没入型の小売ソリューションは、ブランド価値の維持とデジタルトレンドセッターとの連携を支援して購買体験を変革します。 例えば、大手オンラインアパレル小売企業の Zappos は、AWS への移行により、e コマース体験を大幅に改善しました。分析と機械学習を用いて、消費者に合わせたサイジングや検索結果を提供し、99% の検索を 48 ミリ秒未満で完了させるなど、高速で柔軟な顧客体験を提供しています。 ステップ 3：革新的なソリューションでより多くの消費者にリーチする 消費者はスムーズな商品発見、パーソナライズされた体験、多様なサービスチャネル、セルフヘルプオプションなどを求めています。また、ソーシャルメディアを通じた e コマースビジネスの潜在価値は高く、2025 年には米国で 1,000 億 USD 規模に成長すると予想されています。 小売業のデジタルマーケティング担当者は、多様なアプローチを追求し、ターゲット層に応じた戦略を立てる必要があります。こうしたことに対して、企業はオンラインマーケットプレイスやソーシャルコマースプラットフォームを通じて、高度な購買体験を提供する必要があります。 オムニチャネルデジタルコマースでは、 AI や機械学習を活用して、適切な消費者に適切なタイミングでリーチできます。Amazon のようなデジタルマーケットプレイスの構築も、ブランドのリーチ拡大に有効な方法です。 世界中の小売企業が AWS とそのパートナーと協力し、最先端のデジタルコマースプラットフォームを構築しています。これには、ゲームプラットフォームでの商品広告配信、 Amazon Pinpoint や Amazon Advertising などを活用した自動化されたインテリジェントなマーケティングシステム、そしてオンラインマーケットプレイスが含まれます。特に Amazon Pinpoint は、多様なチャネルを通じて顧客とつながる柔軟なマーケティングサービスを提供し、業界トップクラスの配信率を実現しています。また、AWS パートナーの Cisco Meraki はスケーラブルなマーケットプレイス作成を容易にするプラットフォームを提供しています。 例えば、日本のオンラインスナック小売企業の snaq.me は、約 5 万人の会員にパーソナライズされたおやつを提供しています。以前の独自システムの問題を解決するため、Amazon Pinpoint に移行しました。これにより、適切な対象者に的確なメッセージを届けられるようになり、日常業務が 4 時間短縮され、1 日あたりの売上収益が 3 倍に増加しました。 ステップ 4：消費者の期待に応え、それを上回る 効果的なデジタルストアフロントを構築した後、小売企業は顧客ロイヤルティの維持に注力する必要があります。これには、多様な買い物方法のサポートと効率的な注文処理が不可欠です。つまり、適切な商品を適切な場所に適切なタイミングで届けるという基本に常に対応することです。革新的な小売企業は、BOPIS（オンラインで購入して店舗で受け取り）、BOSFS（オンラインで購入して店舗から配送）、ROPIS（オンラインで予約して店舗で受け取り）などのフルフィルメントオプションを提供しています。また、「エンドレスアイル」を設けて、店舗にない商品の直接配送も可能にしています。 返品と交換のプロセスも簡素化し、顧客のニーズに応じて様々なオプションを提供しています。 これらの複雑なサービスと物流プロセスを管理するため、クラウドベースのソリューションが有効です。これにより、ジャストインタイム配送や円滑な返品処理が可能となり、長期的に顧客満足度を維持できます。 AWS は 20 年以上にわたり、小売企業向けの優れたショッピング体験を提供するソリューションを支援してきました。主な例として、オムニチャネルフルフィルメント、 Amazon Connect による効率的なカスタマーサービス、インテリジェントなサプライチェーン管理、スマートストアの実現、分析と機械学習による顧客離れの低減、ラストマイルフルフィルメントの強化、生成AIを活用した効率性の向上などがあります。これらのソリューションにより、小売企業は顧客満足度を高め、業務効率を改善し、競争力を維持できています。 例として、英国の大手食料品チェーン Morrisons は、Amazon Connect を導入し、8 週間で俊敏でスケーラブルなクラウドベースのコンタクトセンターを実装しました。これにより、新しい顧客体験の提供と自立した運用が可能になりました。 一方、高級フットウェアブランドの Kurt Geiger は、オンライン顧客体験の向上に取り組んでいましたが、不正広告によるカスタマージャーニーの中断に悩まされていました。AWS パートナーの Namogoo の機械学習ソリューションを導入し、不正広告をブロックした結果、コンバージョン率が 6% 向上し、400 万ポンド以上の収益回復を実現しました。 次のステップ：AWS でデジタルコマースの最適化を実現する 小売企業の成功には、イノベーションと最適化が不可欠です。AWS は、世界最先端の小売業から生まれたクラウドサービスのリーダーとして、消費者の期待に応え、運用を最適化し、ビジネスインサイトを強化するソリューションを提供しています。 AWS を活用するためのステップとして、現在のプラットフォームの評価、迅速な成功機会の特定、AWSソリューションの検討、AWSリテールコンピテンシーパートナーとの連携が挙げられます。AWS にご相談いただき、競合他社に先駆けて市場機会をつかみ、再現性のある成功を実現しましょう。詳細は、本 e-book やその他の e-book もぜひご覧ください。 消費財企業が成長するための極意 スマートストアテクノロジーの力を活用する 流通・小売・消費財企業のイノベーションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの松本が執筆しました。

本ブログは、カシオ計算機株式会社と Amazon Web Services Japan が共同で執筆しました。 カシオ計算機は、時計、電子辞書、電卓、電子文具、電子楽器などを手掛けており、グループ全体で 9,594 名（ 2024 年 3 月末時点）が所属しております。 同社では、全社員に向けて 2023 年より社内業務支援のため AI チャットボットの検討および試行を開始し、2024 年 3 月に全社展開を行いました。 AI チャットボットではコード作成支援や技術調査、文書作成やアイデア創出など多様な業務利用が想定され、精度が良く且つ用途にあった基盤モデルを都度選択できる必要があり Amazon Bedrock の採用しています。 採用アーキテクチャ 本チャットボットシステムは専用線を用いた閉域網で社内利用できるようにして、フロントエンドは Next.js 、バックエンド処理は FastAPI で実装しました。また、これらのアプリケーションはコンテナ化した上で AWS App Runnner でホストし、 Amazon Bedrock の複数の基盤モデルを利用できるようにしています。 また、 2024 年の全社展開後、 3 月に公開された Anthropic の  Claude 3 Sonnet をすぐに利用できるように対応し、さらに Anthropic の  Claude 3.5 Sonnet については 6 月の公開から数日のスピードで実装及び検証、公開を実現しました。 このスピード感を実現できた背景として、実装に AWS 標準のライブラリである Boto3 を使ったことがあげられます。 Boto3 はストリーミング処理など複雑な処理を簡単に実装でき、 LangChain などの外部ライブラリを使わずとも、 Boto3 の豊富な機能で柔軟な開発が可能でした。さらに、利用する基盤モデルの切り替えも、モデルの指定を変更するだけで対応できるため、非常にシンプルかつ効率的に実現できています。 今後も新しい基盤モデルが提供され次第、有用性を見極めたうえで、順次利用できるようにアップデートしていきます。 その他のアーキテクチャのポイントとしては、プロンプトログを Amazon DynamoDB に保存しており、 zero-ETL により Amazon OpenSearch Service へ連携し、ダッシュボードでの可視化によりリアルタイムでの利用状況分析を可能にしています。 AWS CodePipeline を利用した CI/CD にも対応し、自動ビルドや自動デプロイを実現しており、機能追加や拡張に迅速に対応可能な環境を整備しました。 これらのインフラ環境は全て IaC ( AWS CDK ) で実装しており、これによりシステム構成の変更や環境の横展開などデプロイ作業における柔軟かつ迅速な対応を実現しています。 今回の社内 AI チャットボットは、カシオ計算機の CCoE および AI アルゴリズム開発部の 3 名を中心に実装し、内製で 1 ヵ月程度で構築を完了しました。 利用状況 本チャットボットシステムは、グループ会社を含むカシオ計算機国内従業員に公開されています。 2024 年 9 月現在で 1,600 人強の登録者がおり、そのうちアクティブユーザは約 1,200 名 となっています。現時点ではコーディングサポートとしての利用が最も多く、次いで文章作成/構成、検索、翻訳、ブレストが続きます。特に Claude 3.5 Sonnet はコーディング能力と日本語能力が非常に高く、多種多様な業務に幅広く活用されており、社員の生産性向上に大きく寄与しています。 今後の展望 現在、カシオ計算機内での社内チャットボットの利用は、前述のようにシステム開発業務が中心ですが、アイデア出しなど創造性の高い業務への生成 AI の活用も徐々に広がってきています。 Anthropic の Claude 3.5 Sonnet をはじめとした日本語性能の高い高品質な生成AIに大きなポテンシャルを感じており、今後も利用ユースケースの拡大を狙い、今後も社内での周知を通して浸透を図る予定です。 また、 PoC レベルでは画像生成や PDF 解析、 RAG による社内文書検索の実装等も進めており、ガイドライン整備や精度向上のチューニング等が完了次第、順次全社展開していく予定です。特に RAG に関しては大きな期待を寄せており、さらなる業務効率化や生産性向上を目指して日々対応を進めています。 まとめ カシオ計算機で実用化された社内 AI チャットボットにより、 Amazon Bedrock を利用して社員のスキルの底上げを図ることができました。今後は更なるユースケース拡充を狙って、 AWS サービスを活用した RAG や基盤モデルのバリエーション増を検討し活用の幅を広げていきます。 シニアソリューションアーキテクト 秦 将之

本ブログは、小売業向け AWS の e-book 「スマートストアテクノロジーの力を活用する」の概要と、具体的なユースケースと関連する技術のハイライトを解説するものです。このガイドは、インテリジェントなクラウドベースのテクノロジーによってカスタマーエクスペリエンスを変革し、店舗オペレーションを自動化する実践的な方法に関心を持っている流通・小売業の意思決定者の方々を対象としています。 スマートストアイノベーションの紹介 実店舗が流通・小売業の基盤であり続ける理由 オンライン売上が増加する中、2024 年の米国小売売上の 72% は依然として実店舗が占める見込みです。これは、実店舗は、買い物客が商品を発見、吟味し、見て触れて、購入する人気の場所であり続けているためです。消費者はここ数年で当たり前になったデジタルツールや非接触型サービスを求めており、流通・小売業者はオムニチャネルコマースに適応して消費者の期待に応えるデジタルトランスフォーメーションを実現する必要があります。また、購買行動の主な傾向として、デジタル技術の使用、パーソナライズされた体験、体験重視の売り場への期待、デジタルの影響を受ける店舗での売上などが挙げられます。 クラウドネイティブソリューションの成熟度が低い現在は、実店舗変革の好機です。しかし、多くの流通・小売業者がクラウドを重視しているものの、クラウドファースト運用の加速にはまだ課題があります。 小売体験を変革するスマートストア AWS のスマートストアソリューションは、流通・小売業者の競争力維持に貢献します。主な特徴は以下のとおりです。 フリクションレスチェックアウトによるスムーズな購買体験 コンピュータビジョン技術を用いた在庫管理と購買行動分析 顧客ロイヤルティデータと購入履歴を活用したて、店舗でのパーソナライズドされたオファーの提供 効果的な勤務管理ソリューションによる従業員の生産性向上 これらの機能により、カスタマーエクスペリエンスの向上、オペレーションの効率化、市場変化への迅速な適応が可能となります。AWS はクラウドテクノロジーを活用し、流通・小売業界のイノベーションをリードしています。AWS for Retail は、幅広いサービスとテクノロジーを提供し、多くの小売業者がデジタル機能のデプロイや実店舗のアプローチ変革に活用しています。本 e-book では、店舗オペレーションの強化や従来のチェックアウト体験を刷新するソリューションなど、具体的な機能やユースケースを紹介しています。 AWS スマートストアテクノロジーで流通・小売業のイノベーションを加速する 流通・小売業界では、デジタルと現実の融合による変革が進んでいます。AWS のスマートストア機能を活用することで、顧客体験の向上と店舗オペレーションの効率化が可能です。これにより、イノベーションの加速、コスト削減、ビジネスの成長に合わせたスケーリングが実現できます。スマートストアの例として 3 つの観点で様々なユースケースが挙げられています。1) 店舗でのデジタル活用では、ユニファイド/コンポーザブルコマースやパーソナライズされたレコメンデーション、リテールメディアネットワークなど、2) 店舗オペレーションの自動化では、店舗フルフィルメントやスマートな在庫管理、損失防止など、3) 決済体験では、フリクションレスチェックアウトや非接触型の本人確認と支払い、RFID と IoT チェックアウト などです。これらのいくつかをハイライトとして取り上げます。 店舗でのデジタル活用 買い物客は、店舗での体験にさらに多くのことを期待しています。AWS スマートストアの機能では、体験と期待の両方を変革するテクノロジーを活用できます。AWS のスマートストアソリューションにより、流通・小売業者は、顧客満足度を高める迅速でスムーズかつ魅力的なショッピング体験を提供しながら、オペレーションの俊敏性を高めることができます。 ユニファイドコマースとコンポーザブルコマース ユニファイドコマースは、チャネルや接点に関わらず統一された顧客体験を提供し、顧客満足度とブランドロイヤルティを向上させます。多くの流通・小売業者は、柔軟な「コンポーザブル」なソフトウェアアプリケーションを採用してオペレーションを統合しています。AWS は ISV パートナーと協力し、 MACH アライアンス のメンバーとして、コンポーザブルコマースアーキテクチャを促進し、流通・小売業者のシステムモダナイゼーションを支援しています。この MACH 原則に沿って販売チャネルを開発した流通・小売業者は、競合他社より 80% 迅速に新機能をデプロイできるようになります。 パーソナライズされたレコメンデーション 消費者は高度なパーソナライゼーションを求めており、 Amazon Personalize はこのニーズに応える機械学習ソリューションを提供しています。オーストラリアの 美容・スキンケア企業 Mecca は、Amazon Personalize を導入 後、迅速にカスタマイズされた商品レコメンデーションを生成し、週に 1,000 万件以上のレコメンデーションをマーケティングキャンペーンで活用しています。 リテールメディアネットワーク 店舗内広告は消費財ブランドが買い物客に製品を紹介するために使用され、AWS for Retail のデジタル機能によってブランドは店内の顧客をターゲットにでき、小売業者は店舗内広告を収益化できます。 Amazon フレッシュ はその良い例で、AWS のデマンドサイドプラットフォーム（DSP）を使用してブランドは広告スペースを獲得し、顧客へのリーチを細かく管理できます。 店舗オペレーションの自動化 流通・小売業者は、店舗を最大限の効率で運営し、消費者に再来店してもらうために、日々さまざまな業務活動に取り組んでいます。スマートストアテクノロジーは、エッジコンピューティング、店舗フルフィルメント、損失防止、勤務管理ソリューションなど、最新のクラウドソリューション、IoT デバイス、分析によって、流通・小売業者の極めて複雑な店舗オペレーションを支援します。 店舗フルフィルメント AWS のクラウドベース e コマースサービスを導入した英国の大手食料品店チェーンが、AWS パートナーの支援を得て、オンライン注文から配達までの効率的なシステムを構築し、ラストマイル配送のパートナーとともに最適化されたルートで商品を配送している事例が紹介されています。 スマート在庫管理 消費財企業は店舗の棚画像をリアルタイムに在庫や棚割り分析する新技術を活用しており、AWS はシンガポールを拠点とする Trax と提携してグローバルなデータ分析を行っています。このように在庫を理想的なレベルに保つよう商品の需要を正確に予測するために Amazon SageMaker を用いて大規模な機械学習を行えます。 損失防止 流通・小売業者は、エッジテクノロジーと IoT を活用した損失防止ソリューションで利益の保護を図っています。Edge as a Service（EaaS）は、盗難防止、在庫管理、従業員安全確保などのメリットを提供します。 Rigado の IoT Edge-as-a-Service は、AWS リテールコンピテンシーパートナーソリューションとして、小売業者のスマートストア移行を支援し、RFID と IoT 技術で在庫監視と店舗安全管理を可能にしています。 決済体験 過去 1 年間で、米国の消費者 10 人中約 9 人が、待ち時間が長いことを理由に実店舗での購入を避けています。これは、消費者の 85% がチェックアウト体験を「非常に重要」または「重要」と捉えている一方で、チェックアウト体験に満足しているのがわずか 23% にすぎない理由の一つでもあります。 AWS for Retail では、チェックアウト処理を簡素化する幅広いソリューションを用意しています。そのいくつかを取り上げます。 フリクションレスチェックアウト 流通・小売業者は、顧客の利便性向上と店舗生産性向上のため、セルフレジやスキャンアンドゴーなどのフリクションレスソリューションを導入しています。 Amazon の Just Walk Out テクノロジー は、買い物客が商品を手に取ると自動的に仮想カートに追加され、店を出る際に自動精算される先進的なシステムで、レジ待ちのない快適なショッピング体験を提供しています。 非接触型の本人確認と支払い Amazon One は手のひらを使用する高速かつ便利な非接触型の本人確認サービスです。デバイスの上に手のひらをかざすだけで、店舗や施設に入り、本人確認を行って、商品やサービスの代金を支払うことができます。これは、店舗運営者にとって顧客満足とロイヤルティを高める手段にもなります。 RFID と IoT チェックアウト RFID は小売店での商品追跡に使用される無線技術です。 AWS リテールコンピテンシーパートナー である TensorIoT はフリクションレスチェックアウトシステムの設計・デプロイを支援しています。韓国の Uncommon Store は AWS の支援を受けて完全無人店舗を実現し、デバイスデータや動画ストリームの管理に AWS IoT Core や Amazon Kinesis Video Streams を活用しています。また、Amazon はこの技術を レジなし店舗という体験 にも応用できると考えています。 AWS リテールコンピテンシーパートナーと共にイノベーションを加速する コンポーザブルアプリケーションは MACH に準じた開発フレームワークをベースとしているため、流通・小売業者はヘッドレス API アーキテクチャレイヤーの上にビルディングブロックのマイクロサービスを組み合わせることができます。ビルディングブロックは、スマートストアポートフォリオで構成されています。このポートフォリオには、流通・小売業者を実装へと導くユースケースと重要な統合ポイントが含まれます。 AWS リテールコンピテンシーパートナー は、ユニファイドコマースやコンポーザブルコマース、カスタマーエンゲージメント、サプライチェーンと流通、実店舗/デジタルストア/仮想ストア、高度な小売データサイエンス、小売の基幹業務アプリケーションにわたり、流通・小売業者のイノベーションジャーニーを加速する革新的なテクノロジーサービスを提供します。 まとめ: Born from Retail, built for retailers AWS は、世界で最も大きく最も成功している流通・小売業者の 1 つである企業のもとで生まれました。AWS のスマートストアのサービスでは、その経験を共有し、流通・小売業者が「実験とイノベーションの迅速化」「需要に合わせた迅速なスケール」「テクノロジー投資の最適化」を実現できるようにご支援します。 店舗にインテリジェンスを導入することで、顧客満足度向上と売上増加というメリットを享受できるようになります。AWS と、その幅広い業界パートナーネットワークが、流通・小売業の変革をどのようにサポートできるかの詳細について、ぜひ e-book やその他の e-book をご覧ください。 消費財企業が成長するための極意 小売業のデジタルコマースを最適化する 4 つの重要なステップ 流通・小売・消費財企業のイノベーションを生成 AI で促進する 消費者に愛されるブランドを構築する 本ブログはソリューションアーキテクトの松本が執筆しました。

本記事は 2024 年 10 月 1 日に公開された “ New – Size flexibility for Amazon ElastiCache reserved nodes ” を翻訳したものです。 Amazon ElastiCache は、完全マネージド型の Redis OSS と Memcached 互換のキャッシングサービスです。2024 年 10 月 1 日より、すべてのリザーブドノードオファリングでサイズの柔軟性をサポートするようになりました。これにより、予約時に指定したサイズ以外のノードタイプに対してもリザーブドノード割引が適用されるようになります。 サイズの柔軟性をサポートしたリザーブドノードでは、予約購入時に特定のノードサイズを指定する必要がなくなり、キャパシティプランニングのオーバーヘッドが削減され、ワークロードやキャパシティの変化に合わせてクラスターのサイズを調整できるようになります。この記事では、この新しいサイズ柔軟性機能により、ElastiCache クラスターに割引価格がどのように適用されるかを説明します。 Amazon ElastiCache は、数十万人のお客様のアプリケーションのパフォーマンスを向上させ、より高いスケーラビリティを実現し、コストを最適化するのに役立っています。ElastiCache は、データキャッシング、Web、モバイルアプリ、ヘルスケアアプリ、金融アプリ、ゲーム、アドテック、IoT (モノのインターネット)、メディアストリーミング、セッションストア、リーダーボード、機械学習 (ML)、マイクロサービスベースのアプリケーションなど、高パフォーマンスが必要とされる用途に適しています。ElastiCache はフルマネージドサービスであり、キャッシュのハードウェアプロビジョニング、監視、ノード交換、ソフトウェアパッチ適用の管理をお客様にかわって支援します。 ElastiCache には、サーバーレスとセルフデザイン (ノードベース) の 2 つのデプロイオプションがあります。ノードベースのクラスターの場合、ノードタイプ、ノード数、AWS アベイラビリティーゾーン間でのノード配置を選択します。 リザーブドノード を購入して、1 年または 3 年の期間 ElastiCache ノードタイプを予約し、オンデマンドノード価格に比べて割引 (最大 55%) を受けることができます。ElastiCache リザーブドノードは、前払い不要、一部前払い、全額前払いの構成で利用できます。長期契約でより多くの前払いをすれば、予約期間中の割引率が高くなります。 従来は、特定のインスタンスタイプ (例: cache.r7g.xlarge) の予約を購入した場合、指定されたタイプに対してのみ割引が適用されていました。これにより クラスターのスケールアップまたはダウン のためにノードサイズを変更した場合、リザーブドノードによる割引が適用されなくなっていました。 この柔軟性の欠如により、リザーブドノードでは 1 年または 3 年の期間の使用を予約する必要があるため、長期的な容量計画が困難になっていました。 2024 年 10 月 1 日以降、すべての ElastiCache リザーブドノードはより柔軟になり、特定の AWS リージョンとキャッシュエンジン (Redis OSS または Memcached) のノードファミリー (例: cache.r7g) 内のすべてのノードサイズに適用されるようになります。割引料金は利用に応じて自動的に適用されるため、リザーブドノード割引を実行中のキャッシュノードに合わせる必要がなくなり、管理オーバーヘッドが軽減されます。 割引料金を計算するために、各 ElastiCache ノードには ユニット で測定される 正規化係数 があります。リザーブドノードユニットは、リザーブドノードのインスタンスファミリー内の実行中のノードに適用できます。任意のノードの正規化係数を確認するには、 ノードサイズチャート を参照できます。これは、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Relational Database Service (Amazon RDS) などの他のサービスが、予約のサイズを柔軟に変更できるプロセスと同様です。 シナリオ 1: クラスターのスケールアウトとスケールダウン 例えば、Memcached エンジンで cache.r7g.4xlarge ノード (正規化係数 32) のリザーブドノードを購入した場合です。 このリザーブドノードは、同じリージョン内の任意の Memcached cache.r7g ノードで使用できます。 ノードサイズを小さくしてより多くのノード (同じアカウント内の同じクラスターまたは別のクラスター内) を実行し、リザーブドノードの恩恵を受けることができます。 例えば： cache.r7g.large ノード 8 台 (8 * 4 = 32 ユニット) cache.r7g.xlarge ノード 4 台 (4 * 8 = 32 ユニット) cache.r7g.2xlarge ノード 2 台 (2 * 16 = 32 ユニット) cache.r7g.4xlarge ノード 1 台 (1 * 32 = 32 ユニット) シナリオ 2: 異なるサイズのノードの併用 この cache.r7g.4xlarge のリザーブドノードは、cache.r7g.large ノード 4 台 (4 * 4 = 16 ユニット) と cache.r7g.xlarge ノード 2 台 (2 * 8 = 16 ユニット) のような、異なるサイズのノードの組み合わせにも使用できます。 リザーブドノードの価格は、自動的に、より大きなサイズのノードタイプに適用される前に、同じ種類の中で実行中の小さいサイズのノードタイプに適用されます。リザーブドノードの恩恵を受けるインスタンスを選択することはできません。 たとえば、cache.r7g.large ノード 8 台 (32 ユニット) とcache.r7g.4xlarge ノード 1 台 (32 ユニット) を実行している場合、cache.r7g.large ノード 8 台がリザーブドノードによってカバーされます。 シナリオ 3: クラスターのスケールアップ リザーブドノードよりも大きなノードを実行する場合、超過分に対して時間単位の オンデマンド価格が課金されます。例えば、実行中の 2 ノード cache.m7g.large Redis OSS クラスターをカバーするために、cache.m7g.large Redis OSS のリザーブドノードが 2 つある時、より多くの vCPU を活用するために cache.m7g.2xlarge ノードを使用してクラスターをスケールアップしたい場合を考えます。リザーブドノードの合計は 8 ユニット (ノードのサイズに対応した単位) で、新しいクラスター (16 ユニット) の 50% のリソースを確保できます。つまり、1 つの 2xlarge ノードに相当します。残りのノードは、cache.m7g.2xlarge ノードの時間単位の オンデマンド価格に基づいて課金されます。また、追加で 1 つの cache.m7g.2xlarge リザーブドノードを購入すれば、クラスター全体のリソースを確保できます。 シナリオ 4: クラスターのスケールダウン 所定の使用時間内に適格な実行中のノードが足りない場合、その時間の残りのリザーブドノードユニットは無駄になってしまいます。例えば、Redis OSS エンジンの cache.t4g.medium リザーブドノードがあり、1 ノードの Redis OSS クラスターを cache.t4g.small にスケールダウンした場合、その地域で他の Redis OSS cache.t4g ノードを起動しない限り、残りの 1 ノード分のユニットは消失してしまいます。 結論 ノードタイプの柔軟性は、すべての ElastiCache エンジンのすべてのリージョンで利用できるようになり、10 月 1 日から既存および新規購入のリザーブドノードに自動的に適用されます。柔軟なリザーブドノードの詳細については、 Amazon ElastiCache リザーブドノードページ をご覧ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Kevin McGehee は、Amazon In-Memory Databases チームのプリンシパルエンジニアです。優秀な開発者と共に、パフォーマンスが高く保守性の高いシステムを構築することに情熱を注いでいます。 Goumi Viswanathan は、Amazon In-Memory Databases チームのシニアプロダクトマネージャーです。 12 年以上のプロダクト経験があり、データベースソリューションを提供するクロスファンクショナルチームをリードしています。 仕事以外では、旅行と屋外での時間を楽しんでいます。

みなさま、こんにちは！Generative AI Specialist の大渕です。この記事では、RAG (Retrieval Augmented Generation) を使って自社の課題を解決したり自社サービスを強化したりしたいと考えているみなさまに耳寄りな情報をお届けします。 2024年9月19日に、RAG に関する悩みを持っている方を対象とした AWS オンラインセミナー「RAG の困りごとは今日で一気に解決！ AWS 生成 AI Dive Deep」が開催され、実用的な情報盛りだくさんの 3 つのセッションが実施されました。セミナーの見どころとしては、以下のとおりです。いずれかにピピっと来たら、ぜひこの記事を読み進めてください。 RAG の概要ではなく、実践的なテクニックや開発の進め方を知ることができる RAG でよくある課題とその解決策を具体的に知ることができる RAG に欠かせない AWS サービスとその使い分けを知ることができる セッションの紹介 それではさっそく、セッションの内容を紹介します。資料と動画も公開されているので、詳しく知りたい方はそれぞれのリンクをクリックしてください。 RAG on AWS dive deep [ 資料 ] [ 動画 ] アマゾン ウェブ サービス ジャパン合同会社 公共部門ソリューションアーキテクト 宮口 直樹 はじめのセッションでは、SA 宮口より、RAGを構築する上で多くの方が悩むであろう、ベクトル DB、埋め込みモデル、チャンキングなどの各コンポーネントのサービス選定のポイントを紹介しました。それぞれのコンポーネントを実現する AWS サービスや OSS の選択肢を知り、それぞれの特徴や機能の違いを理解することで、ユースケースに合わせてサービスを選択できるようになります。また、基盤モデルの進化に伴い、テキストだけではなくマルチモーダル RAG も実用レベルになってきたことから、マルチモーダル RAG の概要と実現方式についても紹介しました。 あなたの RAG の精度を改善！Advanced RAG on AWS のすヽめ [ 資料 ] [ 動画 ] アマゾン ウェブ サービス ジャパン合同会社 機械学習ソリューションアーキテクト 本橋 和貴 2つ目のセッションでは、SA 本橋より、RAG の精度改善のさまざまなテクニックを紹介しました。「 Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証 」という AWS ブログでも紹介した Advanced RAG のそれぞれの手法と使いどころが説明されており、RAG の精度改善に取り組もうとしている方にとって、非常に有用な内容となりました。また、精度改善のために闇雲にリッチな手法を適用するのではなく、都度評価を実施してどこに問題があるのかを明らかにした上で適切な手法を選んでいくべき、という指針にも言及がありました。最後には、Graph RAG に関する紹介もあり、今後も RAG がさまざまなユースケースで使われるだろうことが予見される締めくくりでした。 本セッションの内容をもとにしたブログ「 RAG の精度を向上させる Advanced RAG on AWS の道標 」も公開していますので合わせてご覧ください。 Retrieval-Augmented Generation (RAG) の評価 [ 資料 ] [ 動画 ] アマゾン ウェブ サービス ジャパン合同会社 Telco Solutions Architect 近藤 健二郎 最後のセッションでは、SA 近藤より、RAG の評価についての実践的な考え方やテクニックを紹介しました。RAG の評価方法として確立された手法はまだないため、実行しようとすると一筋縄ではいかないこともありますが、実用化に向けた試行錯誤の効果を測るには評価は欠かせません。そこで、一般的な RAG の評価に関する課題やよく利用される評価項目と、RAG 評価の実践的なプラクティスを紹介しました。これから RAG を試す人や RAG を構築中の人に、評価に関する気付きを与えるセッションとなりました。 いただいた質問と回答 セミナーでは、参加者の皆様からたくさんの質問をいただきました。代表的な質問と回答を以下にまとめたので、参考にしていただければ幸いです。 Q. RAG で使いたいドキュメントに表データがあるのですが、上手く読み込めていないようです。表データを含むドキュメントを扱う際の良い方法はありますか。 A. 前処理として LLM を用いた表のマークダウン化をお試しされてはいかがでしょうか。Amazon Bedrock Knowledge BasesのAdvanced Parsing (高度なパース) 機能では、LLM (Anthropic Claude 3) を用いた図表の読み取りが可能です。詳しくは こちらのブログ記事 をご参照ください。 Q. Cohere のリランキングモデルを AWS から使う方法を教えてください。 A. Cohereのリランキングモデルは、Amazon SageMaker JumpStart を通じて簡単にデプロイし、利用することができます。詳しくは こちらのブログ記事 “Improve RAG performance using Cohere Rerank” を参照してください。 Q. Graph RAG における LlamaIndex はどのような役割を担っていますか？ A. Amazon NeptuneはグラフDBであり、LlamaIndexのようなツールを用いることで、ドキュメントをグラフDBに格納可能な形式に変換して保存することができます。詳しくは LlamaIndexのドキュメント をご参照ください。 まとめ 生成AI の業務活用においてよく使われる RAG ですが、いざ業務で使おうとするとさまざまな課題に遭遇します。その課題は、速度や性能だったりしますが、どのように解決したら良いのか悩まれている方も多いと思います。このセミナーの内容が、そんな悩めるみなさまにとって、課題解決の糸口を見つけるきっかけとなれば幸いです。 RAG のベクトル DB の部分を Amazon OpenSearch Service で構築したいとお考えの場合、こちらの GitHub repo のサンプルコードがお役に立つかもしれません。CDK で実装されており、日本語テキストのためのトークナイザ Sudachi プラグインが適用された状態の OpenSearch domain を簡単に構築することができます。本セミナーの 2つ目の Advanced RAG のセッションで紹介されたテクニックを試すためのベースとしてお使いいただけます。

このブログは、第一三共株式会社 研究統括部 研究イノベーション企画部と、アマゾン ウェブ サービス ジャパン合同会社 ソリューション アーキテクト 中島丈博による共著です。 2024 年 6 月 20 日、21 日に幕張メッセで開催された AWS Summit Japan では、EXPO として AWS Village と呼ばれる展示エリアが用意され、AWS のサービスやインダストリーソリューションを扱う 90 以上のAWS 展示と、50 以上のお客様事例展示がございました。その中に展開された Industry Zone では、各業界向けの最新の AWS ソリューションの展示や、実際に AWS を活用している企業のブースも併設されました。 また、第一三共株式会社は業界セッション「 創薬を加速する第一三共のセルフサービス型クラウド基盤　～モブワークで挑む基盤内製と人材育成の両立～ 」へ登壇し、Industry Zone のヘルスケア・ライフサイエンス業界向けブースに出展されました。 今回のブログでは、Industry Zone の第一三共株式会社ブースで展示された創薬研究プラットフォームについて、プラットフォーム概要、AWS アーキテクチャをご紹介します。 第一三共株式会社における創薬研究プラットフォームのご紹介 第一三共株式会社は、革新的な医薬品を継続的に創出し、多様な医療ニーズに対応する製品を提供することで、世界中の人々の健康と豊かな生活に貢献することを目指している製薬企業です。医薬品の研究開発は、その膨大な時間とコスト、そして極めて低い成功確率から、非常に挑戦的な領域です。通常、新薬の開発には 10 〜 20 年という長い期間と、数百億から数千億円に及ぶ莫大な費用がかかります。また、創薬の成功確率は数万分の 1 とも言われており、ますます難易度が増しています。 このような課題に対し、私たちは最新の技術を活用して創薬プロセスの革新を試みております。実験自動化による効率の向上や時間短縮、AI・データサイエンス技術の導入による成功確率の向上が期待される中、これらを支えるデータ蓄積・解析基盤の構築が不可欠です。 当社では、ここ数年にわたり AWS クラウドを全面的に活用し、創薬研究の効率化と成功確率の向上を目指したプラットフォームを構築してきました。 本ブログでは、これらの取り組みから 実験データ転送の自動化 柔軟に利用可能なハイパフォーマンスコンピューティング (HPC) クラスター環境 収集・正規化されたデータの可視化と解析 の 3 つの活用事例についてご紹介します。 実験データの自動転送・処理 実験機器のハイスループット化は近年も著しく、データの効率的な転送や安全な保管は創薬研究においても重要な課題です。私たちのグループの次世代 DNA シーケンサー (NGS) は 1 回のランで数百 GB の生データを出力し、繁忙期には数日おきにランが行われています。従来のデータ転送は、大容量データの扱いに向かない GUI 操作や外付けストレージ（HDD、SSD）の輸送によって行われるケースが多くありました。これらは時間がかかる上に操作ミスによるデータの破損の危険を高めます。そこで私たちは、NGS のランの最中にリアルタイムでデータを Amazon Simple Storage Service (Amazon S3) バケットに転送するシステムを構築しました。Amazon S3 バケットは HPC 用ファイルシステムである Amazon FSx for Lustre と同期されており、Amazon S3 にアップロードされたデータは HPC 環境からアクセス可能です。結果として、NGS のラン終了の 1–2 時間後には出力されたデータの解析を始めることができ、研究サイクルの迅速化が達成されています。執筆時点では AWS コマンドラインインターフェイス (AWS CLI) を社内の PC から定期実行することでシステムを稼働させていますが、AWS では転送サービスの選択肢も多く、転送完了をトリガーとして AWS Lambda によりデータを自動処理するといった将来像も考えることができ、その拡張性は大きな魅力です。 柔軟に利用可能な HPC クラスター環境の開発 私たちのグループでは探索的な研究を主に行っており、トライ&エラーを頻繁に繰り返しています。新規の解析手法を試しても多くは採用されません。また、私たちが関わるバイオインフォマティクス分野はオープンソースの解析ツールが広く用いられており、それらの多くは必要リソースを明記していません。これらの要因によって、必要な計算リソースの見積もりは困難になっています。そのような背景において、AWS クラウド環境の柔軟性は大きな利点となります。 データ解析用の HPC 環境は AWS ParallelCluster を用いて構築し、GPU インスタンスを含めた様々な性能の Amazon EC2 インスタンスを、必要に応じてジョブスケジューラ（Slurm）から利用することができます。前述の NGS のデータ解析はファイル入出力の負荷も大きいのですが、ファイルシステムは Amazon FSx for Lustre を用いることで高速に処理を実行できています。ファイルシステムは Amazon S3 に関連付けておき、処理が終わったデータは Amazon S3 へアーカイブし Amazon FSx for Lustre からのリリースを行なっています。こうすることで、Amazon FSx for Lustre は作業場所、Amazon S3 は保管場所、という役割分担ができコストも抑えることができます。Amazon FSx for Lustre と Amazon S3 のデータ同期は速く、不便を感じることはありません。 その他、 NICE DCV を用いてゲノムブラウザ等の GUI アプリケーションを Amazon EC2 で実行しつつ PC 画面に結果を表示するアーキテクチャも構築しています。また、 AWS Batch を用いてコンテナ化された定型処理を実行可能です。様々な実行環境を備えておくことで、各ツールに応じて最適なものを選択できるようにし、効率良く探索的な創薬研究を行えるようになりました。 収集・正規化されたデータの可視化と解析 私たちのグループではデータを解析・可視化するだけでなく、他の研究者が自身で解析を行うための Web アプリケーションを提供しております。複数のアプリケーションを個別に管理することは多大な労力を要するため、アプリケーション公開のための基盤を構築しました。 この基盤は Amazon Elastic Container Service (Amazon ECS) を用いて設計し、Web ツールを展開するために必要なサーバーインフラの設定は、 AWS Step Functions を活用して全て自動化しました。これにより、開発者は Docker コンテナでアプリケーションを開発し、 Amazon Elastic Container Registry (Amazon ECR) に push するだけで、自動的に Web サーバーのポートが開き、その開いたポートにアクセスするだけでアプリケーションへの接続が可能となります。このような構成を構築したことにより、開発者はアプリケーション公開のための環境を整える必要がなくなり、アプリケーション開発という本質的な業務に集中できるようになりました。さらに、複数のアプリケーションを一つの基盤で管理できるため、効率性と一貫性が向上しました。また、研究データの中には、特許性や共同研究契約などの理由で、一部の研究者にしか閲覧が認められないデータも存在します。こうしたデータを扱うために、アプリケーションの閲覧権限も設定する必要がありました。それを実現するために、ユーザー認証機能を Amazon Cognito と Azure AD を組み合わせて実装しました。これにより、所属部署によってアクセス権を設定可能にし、ユーザー管理を個別に行うのではなく、所属部署で一元管理できるようになりました。これはアプリの管理者にとって、ユーザー管理の手間を大幅に減らし、効率的な運用を可能にしました。 以上のように、収集・正規化されたデータの可視化と解析に関する基盤は、開発者が本質的な業務に集中できる環境を提供し、効率的かつ安全なデータ管理を可能にしています。 アジャイルアプリケーション開発に取り組んだ事例の紹介 アプリケーション開発にあたって、開発者とユーザーのワーキンググループを結成し、ユーザーのニーズに基づいて研究データ解析のためのアプリケーション開発に取り組んでおります。内製でアプリケーション開発を行う場合、ユーザーと開発者との距離が近いため、コミュニケーションが密に取りやすいと実感しています。そのため、要件を適宜確認し、フィードバックを頻繁にもらい、アプリケーションの改善を複数回にわたって行ってきました。実際にこのアプローチにて医薬品候補化合物の活性評価試験結果を可視化するビューワーを作成しました。 ユーザーの意見を反映した可視化方法を採用する等により、データサイエンティストと研究者が共同で効果的なアプリケーションの開発を実現しました。 AWS アーキテクチャのご紹介 ここからは、創薬研究プラットフォームの「データサイエンティストの研究環境」と「研究者に向けたアプリケーションのデプロイ環境」についてそれぞれご紹介します。 データサイエンティストの研究環境 データサイエンティストの研究環境は AWS クラウドでのハイパフォーマンスコンピューティング (HPC) クラスターによって構成されており、両方の HPC クラスターでバイオインフォマティクスの分野で広く利用されているワークフローエンジンである Nextflow がセットアップされています。 解析環境は AWS ParallelCluster と AWS Batch を利用した 2 つの HPC クラスターについてご紹介します。 ジョブスケジューラー Slurm を利用可能な AWS ParallelCluster による解析環境 AWS ParallelCluster は AWS がサポートするオープンソースのクラスター管理ツールです。クラスター構成を yaml ファイルで定義すると、infrastructure as code (IaC) を使用してワークフローの各ステップのニーズに合わせて設定した Amazon EC2 インスタンスのクラスターをプロビジョニングします。 本環境ではバイオインフォマティシャンは AWS Systems Manager (SSM) Session Manager を利用してヘッドノードに SSH ログインしてジョブを実行します。SSM は、AWS アプリケーションおよびリソースを安全でセキュアにオペレーションするためのフルマネージドサービスであり、Session Manager はリソース管理のための SSM 機能です。ここではバイオインフォマティシャンがヘッドノードにインターネットを経由してセキュアに SSH アクセスするために利用しています。 AWS ParallelCluster では Nextflow の Executor 機能を利用することで、SLURM のリソースマネージャーを使用してパイプラインスクリプトを実行しています。こちらについては Nextflow のドキュメント や ブログ が参考となります。またストレージは 大容量データを取り扱うことから高パフォーマンスが求められるため、HPC で使用される分散ファイルシステムである Lustre をフルマネージドで提供する Amazon FSx for Lustre を利用しています。Amazon FSx for Lustre は Amazon S3 とシームレスに連携可能なため、様々な AWS サービスとのデータ連携が容易となります。 バッチコンピューティングのフルマネージドサービス AWS Batch による解析環境 AWS Batch は AWS クラウドでバッチコンピューティングワークロードを実行するためのフルマネージドサービスです。Docker コンテナイメージを利用可能でジョブの実行とコンピューティングリソース管理をAWSが実施するため、ユーザーは結果の分析や問題の解決に集中することが可能です。 Nextflow を AWS Batch で利用するには Nextflow のドキュメントに紹介されたマニュアル をもとに構築します。また、Nextflow は AWS Batch を サポート しており、Executor 機能を利用することが可能です。Nextflow ジョブはヘッドジョブとして実行され、その後パイプラインに定義したタスクに応じてタスクジョブが実行されます。ゲノムデータなどのインプットデータや解析によって得られたアウトプットデータは、Amazon S3 を利用してデータの取得と保存が可能です。 研究者に向けたアプリケーションのデプロイ環境 研究者に向けたアプリケーションのデプロイ環境は Docker コンテナの実行環境となります。 アプリケーションのユーザーであるバイオロジストはロードバランサーを介してコンテナ上で実行されるアプリケーションにアクセスします。その際、認証基盤はウェブアプリとモバイルアプリ用のアイデンティティプラットフォームである Amazon Cognito を利用しており、既存の Azure AD へのフェデレーションログインを可能としています。また Amazon Cognito は Application Load Balancer (ALB) と共に利用することで ユーザー認証機能をALB に実装可能 なため、認証機能をプラットフォームに実装することでセキュアな環境を構築しています。さらに開発者はアプリケーションに認証機能の実装は必要ないため、開発の負担を減らすことができます。 次に、アプリケーションのデプロイについてご紹介します。開発者が Web アプリケーションを Docker コンテナを利用して構築したら、Amazon ECR に Docker イメージを push します。push されると、それをトリガーにして Amazon EventBridge 経由で AWS Step Functions を起動します。AWS Step Functions はフルマネージドな AWS のワークフローサービスであり、様々なワークロードの自動化やオーケストレーションを大規模に実行可能なサービスです。今回実装したワークフローではロードバランサーの設定や認証機能の実装、コンテナイメージの実行を行っています。 おわりに 本ブログでご紹介した第一三共株式会社の展示や関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について 第一三共株式会社 山田 倫太郎 (Rintaro Yamada) 研究イノベーション企画部 研究員: 創薬研究において、データ活用のためのクラウド環境構築や解析ツールの開発などをしています。趣味は、温泉巡りをすること、ピアノを弾くことです。 梶谷 嶺 (Rei Kajitani) 研究イノベーション企画部 専門研究員: 創薬のためのバイオインフォマティクス解析を行いつつ、クラウド環境構築や実験機器との連携の支援をしています。ゲノムに興味を持っています。 国本 亮 (Ryo Kunimoto) 研究イノベーション企画部 データ駆動型創薬担当: 創薬のためのバイオおよびケモインフォマティクス研究、及び研究環境構築に広く関わっています。 中川 寛之 (Hiroyuki Nakagawa) デジタル&テクノロジー部 研究領域担当: Cloud Center of Excellenceのメンバーとして、研究領域のクラウドネイティブな形態への変革とそれを支えるモード2ITの取り組みやアジャイルソフトウェア開発の価値観の普及に奔走しています。 アマゾン ウェブ サービス ジャパン合同会社 中島 丈博 (Takehiro Nakajima) ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト: ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。

自動車業界では大変革が起きています。ソフトウェアのイノベーションに牽引され、自動車の概念は単なる移動手段としての役割を超えています。車両は、高度運転支援システム (ADAS)、高度なインフォテインメント、コネクティビティ機能を備えた知的なマシンに進化しています。 こうした高度な機能を実現するには、自動車メーカーは様々なソースからのデータを管理する必要があり、大規模にデータを収集するソリューションが求められています。このニーズに AWS IoT サービスが役立ちます。 クラウド上にデータがあれば、データ分析ツールの構築、予防保全の実現、またエンドユーザー向けの生成 AI サービスにデータを活用するなど、新しい可能性が広がります。 ソリューション概要 この記事では、図 1 に示されている様々なユースケースに対応するために、複数の車両からデータを収集する、スケーラブルで企業向けの環境を整えた構造を、Raspberry Pi で動作させた車のモデルを使って構築する方法を案内します。 図 1 – ユースケース 全体のアーキテクチャ 図 2 は、アーキテクチャの概要を示しています。 図 2 – 全体のアーキテクチャ ハードウェアとローカルコントローラ ハードウェアとしては、機械部品と電子部品をすべて提供する このシンプルなキット を使用します。また、Raspberry Pi も必要です。キットの組み立てとテストの手順は、メーカーの ウェブサイト に記載されていますので、このブログ記事では説明しません。 図 3 – Raspberry Pi 用スマートカーキット 車両は WebSocket を使った React で書かれた Web インターフェースで制御されます。 ローカル Web アプリでは、カメラの映像を見たり、速度を調整したり、移動方向を制御したり、ライトを制御することができます。 よりリアルな運転体験のために、ゲームコントローラを使うこともできます。 図 4 – ローカルカーコントローラー 物理的なプロトタイプを使うことで、上で説明したサービスの機能が実用的な方法でユースケースに適用できることを効果的にシミュレーションできます。 データの収集と可視化 車両が生成したデータは、 AWS IoT FleetWise を使用して仮想 CAN インターフェースを介してクラウドに送信されます。各データ指標は AWS IoT のルール で処理され、 Amazon Timestream に保存されます。 すべてのデータは Amazon Managed Grafana を使用したダッシュボードに表示されます。 図 5 – データ収集 ウォークスルー 詳細な手順と完全なコードはこの GitHub の リポジトリ で入手できます。 フルリポジトリをダウンロードし、Readme.md ファイルに記載されているステップバイステップのアプローチに従うことをお勧めします。 この記事では全体のアーキテクチャを説明し、主要なステップのコマンドを提供します。 前提条件 AWS アカウント インストール済みの AWS CLI Raspberry Pi 用の スマートカー キット Raspberry PI Python と JavaScript の基本的な知識 ハードウェアとローカルコントローラ Raspberry Pi に車両制御ソフトウェアと AWS IoT FleetWise 向けの Edge Agent をインストールするには、以下の手順を実行します。詳しい手順は、 リポジトリ の Readme.md ファイルの 6 番目の項目に記載されています。 仮想 CAN インターフェースを設定する AWS IoT FleetWise 用の Edge Agent をビルドしてインストールする 車両の運転と制御用のサーバーとアプリケーションをインストールする 図 6 – ステップ 1 後のアーキテクチャ 基本的なクラウドインフラストラクチャの構築 AWS CloudFormation は、Amazon Timestream と Amazon Managed Grafana に必要なすべてのリソースを展開するために使用されます。 テンプレートは、Cloud フォルダ内の付随する リポジトリ にあります。 図 7 – ステップ 2 後のアーキテクチャ Amazon Managed Grafana のデプロイ (AWS CLI) 最初にデプロイするコンポーネントは Amazon Managed Grafana で、AWS IoT FleetWise で収集されたデータを表示するダッシュボードをホストします。リポジトリの “Cloud/Infra” フォルダ内にある CloudFormation の 01-Grafana-Instance.yml テンプレートを使って、次のコマンドでリソースをデプロイします。 aws cloudformation create-stack \ --stack-name macchinetta-grafana-instance \ --template-body file://01-Grafana-Instance.yml \ --capabilities CAPABILITY_NAMED_IAM CloudFormation が CREATE_COMPLETE 状態に到達したら、新しい Grafana ワークスペースが表示されるはずです。 図 8 – Amazon Managed Grafana ワークスペース Amazon Timestream のデプロイ (AWS CLI) Amazon Timestream は、1 日に数兆ものタイムシリーズデータポイントを格納し分析できるフルマネージド型のタイムシリーズデータベースです。 このサービスは、AWS IoT FleetWise によって収集されたデータを格納する、デプロイする 2 番目のコンポーネントになります。リポジトリの「Cloud/Infra」フォルダーにある 02-Timestream-DB.yml テンプレートを使用して、次のコマンドでリソースをデプロイします。 aws cloudformation create-stack \ --stack-name macchinetta-timestream-database \ --template-body file://02-Timestream-DB.yml --capabilities CAPABILITY_NAMED_IAM CloudFormation が CREATE_COMPLETE 状態に達すると、AWS IoT FleetWise で使用される新しい Timestream テーブル、データベース、および関連するロールが表示されます。 AWS IoT Fleet の設定 AWS IoT FleetWise の基盤を設定し、収集するシグナルを定義し、データを受信するよう構成する時間が来ました。シグナルとは、車両データとそのメタデータを含む基本構造体を定義したものです。 例えば、車のバッテリー電圧を表す信号を作成することができます。 Signal definition - Type: Sensor - Data type: float32 - Name: Voltage - Min: 0 - Max: 8 - Unit: Volt - Full qualified name: Vehicle.Battery.Voltage この信号は、車両に関するセマンティックに定義された情報を通信するために、自動車アプリケーションで標準的に使用されています。 VSS 仕様に従ってプロトタイプ車をモデル化してください。これがプロトタイプで使用する構造です。この構造は、リポジトリの Cloud/Fleetwise フォルダにある signals.json ファイルに JSON でコード化されています。 図 9 – VSS 形式の車両モデル ステップ 1: シグナルカタログを作成する (AWS CLI) 次のコマンドを使って、上記のように signals.json に記述された構造を利用してください。 aws iotfleetwise create-signal-catalog --cli-input-json file://signals.json コマンドにより返された ARN をコピーします。 AWS コンソールで AWS IoT FleetWise のページを開き、ナビゲーションパネルから シグナルカタログ を選択すると、新しく作成したシグナルカタログが表示されるはずです。 図 10 – シグナルカタログ ステップ 2: 車両モデルを作成する 車両のフォーマットを標準化し、同じタイプの複数の車両で一貫した情報を実施する 車両モデル です。 json ファイルを開き、 変数を前のコマンドでコピーした <ARN> に置き換えてください。 次のコマンドを実行してください: aws iotfleetwise create-model-manifest --cli-input-json file://model.json コマンドが返した ARN をコピーしてください。 次のコマンドを実行してください: aws iotfleetwise update-model-manifest --name <モデル名> --status ACTIVE AWS コンソールの AWS IoT FleetWise ページを開き、ナビゲーションパネルから 車両モデル セクションを選択すると、新しく作成した車両モデルが表示されます。 図 11 – 車両モデル: シグナル ステップ 3: デコーダー マニフェストを作成する デコーダーマニフェスト は、車両からのバイナリデータを人間が読める形式にデコードすることを可能にします。私たちのプロトタイプでは CAN バスプロトコル を使用しています。これらの信号は、生の CAN バスデータをデコードするための情報を含むテキストファイルである CAN DBC (CAN Database) ファイルからデコードされる必要があります。 decoder.json ファイルを開き、 変数を前のコマンドでコピーした ARN に置き換えます。 次のコマンドを実行してモデルを作成します: aws iotfleetwise create-model-manifest --cli-input-json file://model.json 次のコマンドを実行してデコーダを有効にします: aws iotfleetwise update-decoder-manifest --name <デコーダ名> --status ACTIVE AWS コンソールの AWS IoT FleetWise ページを開き、ナビゲーションパネルから 車両モデル セクションを選択すれば、新しく作成したデコーダーマニフェストが表示されるはずです。 図 12 – 車両モデル: デコーダーマニフェスト ステップ 4: 車両を作成する AWS IoT FleetWise には独自の車両コンストラクトがありますが、その基盤となるリソースは AWS IoT Core のモノ で、デバイス (車両) の静的なメタデータを含む物理デバイスの表現です。 AWS コンソールを AWS IoT FleetWise ページ で開きます ナビゲーションパネルで 車両 を選択します 車両を作成 を選択します リストボックスから車両モデルと関連するマニフェストを選択します 図 13 – 車両のプロパティ ステップ 5: キャンペーンを作成してデプロイする キャンペーンとは、AWS IoT FleetWise Edge Agent ソフトウェアに対して、どのデータを選択して収集するか、およびクラウドのどこにデータを送信するかを指示するものです。 AWS コンソールで AWS IoT FleetWise のページを開きます ナビゲーションパネルから キャンペーン  を選択します キャンペーンを作成  を選択します スキーマタイプでは時間ベースを選択します キャンペーン期間 では一貫した期間を選択します 期間  には 10000 と入力します シグナル名 では Actual Vehicle Speed を選択します 最大サンプル数  count では 1 を選択します ステップ 7 と 8 を他のすべての信号に対して繰り返します 送信先 では Amazon Timestream を選択します Timestream データベース名  では macchinettaDB を選択します Timestream テーブル名  では macchinettaTable を選択します 次へ を選択します 車両名  では macchinetta を選択します 次へ  を選択します 確認して 作成 を選択します 図 14 – キャンペーンを作成してデプロイする デプロイ後、数秒で Amazon Timestream テーブル内のデータが表示されるはずです。 図 15 – Amazon Timestream テーブル Amazon Timestream にデータを保存すると、Amazon Managed Grafana を使ってデータを可視化できます。Amazon Managed Grafana は、メトリクスのクエリ、可視化、アラートを行える、人気のオープンソース分析プラットフォーム Grafana の完全マネージドサービスです。 ダッシュボードで、単一の車両からの関連する詳細なデータを表示するために使用します: 図 16 – Amazon Managed Grafana クリーンアップ 詳しい手順は、 Readme.md ファイルの最後に記載されているリポジトリを参照してください。 結論 このソリューションは、ビークル車両データの収集と管理のためのスケーラブルなアーキテクチャ構築において、AWS IoT の力を実証しています。Raspberry Pi 電源の車両プロトタイプから始まり、自動車業界の主要なユースケースにどのように対処できるかを示しました。しかし、これはほんの始まりにすぎません。プロトタイプはモジュール化されており、新しい機能を追加できるよう設計されています。ソリューションを拡張する魅力的な方法をいくつか紹介しましょう。 Fleet Management Web App : AWS Amplify を使用して、車両の全体フリートを監視する包括的な Web アプリケーションを開発します。 このアプリでは、各車両の健全性状態を大まかに把握し、個別の車両の詳細な分析を行えます。 ライブビデオストリーミング: Raspberry Pi アプリケーションに Amazon Kinesis Video Streams ライブラリを統合して、実時間で車両からビデオフィードを可能にします。 予知保全: AWS IoT FleetWise によって収集されたデータを活用し、予知保全モデルを構築することで、車両の信頼性を高め、ダウンタイムを削減することができます。 生成 AI の統合: Amazon Bedrock のような生成 AI サービスを使用して、収集したデータに基づいてパーソナライズされたコンテンツを生成したり、ユーザーの行動を予測したり、車両の性能を最適化することを検討します。 コネクテッド車両ソリューションを次のレベルに引き上げる準備はできましたか? 私たちは、次のことをお勧めします: さらに詳しく見る: AWS IoT サービスとその自動車業界での応用について深く掘り下げましょう。詳細は、 AWS IoT のドキュメント をご覧ください。 実際に試す: GitHub の リポジトリ にある詳細な手順を参考に、自身でこのプロトタイプを構築してみましょう。 専門家と接する: 質問があれば、弊社の AWS IoT の専門家にご相談ください。 コミュニティに参加: AWS IoT コミュニティフォーラムで、経験を共有し、他者から学びましょう。 著者について Leonardo Fenu はソリューションアーキテクトで、2018年から AWS の顧客が技術をビジネス目標に合わせるのを支援してきました。山でハイキングをしたり家族と過ごしたりしていない時は、ハードウェアやソフトウェアをいじくり回したり、最新のクラウド技術を探求したり、複雑な問題を解決する創造的な方法を見つけたりすることを楽しんでいます。 Edoardo Randazzo は DevOps とクラウドガバナンスを専門とするソリューションアーキテクトです。自由時間には、IoT デバイスを作ったりガジェットをいじったりすることが好きで、それが次の大きなブレークスルーにつながる可能性があるか、単に新しいレゴを買う口実になるかもしれません。 Luca Pallini は AWS のシニアパートナーソリューションアーキテクトで、パートナーが公共部門で優れた成果を上げるのを支援しています。AWS の技術フィールドコミュニティ(TFC)のメンバーとして、特に Oracle Database を中心としたデータベースを専門としています。AWS に入社する前は、データベース設計、アーキテクチャ、クラウド技術で22年以上の経験を積みました。余暇には家族と過ごしたり、ハイキングをしたり、読書をしたり、音楽を聴いたりすることを楽しんでいます。 この記事は Building a connected car physical prototype with AWS IoT services の日本語訳です。 この記事は シニアソリューションアーキテクト渡邊翼が翻訳しました。

Introduction 水道メーターは、住宅や大規模生産施設など、ほとんどの給水場所に設置されています。水不足が世界中で頻発するようになり、水の無駄使いを避けることがますます重要になっています。老朽化したインフラストラクチャのため、パイプを流れる水の 30 % が漏れによって無駄になってしまいます ( AWS announces 6 new projects to help address water scarcity challenges )。IoT 化された水道メーターによる計測ソリューションがこの課題解決に役立つ可能性があります。 従来の水道メーターやガスメーターはクラウドやインターネットに接続されていません。また、1979 年と 2003 年にそれぞれ発表された業界標準のプロトコルである Modbus や Profinet を利用しているケースが多いです。これらのプロトコルはクラウド接続を想定して設計されたものではありませんが、AWS と AWS パートナー が提供するソリューションにより、公益事業のデータをクラウドに転送することができます。 スマートメーターは従来のメーターに比べ、消費パターンのデータを活用することで水漏れや非効率な利用パターンの分析が可能となり、コストや資源の節約につながるなど多くの利点があります。 詳細な消費レポートを持つことで、企業は 環境に対する持続可能性目標 と企業の社会的責任への取り組みを支援できるようになります。 クラウドベースのサービスとスマートメーターを組み合わせることにより、予知保全の機能を活用し、障害が発生する前に新たな問題を自動的に分析して特定できます。 このような自動化により、分析プロセスを合理化し、手動での介入の必要性を低減可能です。 この投稿では、機械学習 (ML) の事前学習済みモデルを使用して漏れなどのデータの異常を検出する、広く適用可能なソリューションを紹介します。 このソリューションを実現するため、実際の水道メーターの例を使用し、既存の水道・ガスメーターを AWS IoT Greengrass と AWS IoT Core に統合する手順を説明します。 Solution Overview 実際のソリューションに入る前に、システムのアーキテクチャとそのコンポーネントを確認しましょう。 図 1: ソリューションアーキテクチャの概要 図 1 は、AWS のソリューションアーキテクチャを示しています。この例では、標準的な電磁水道メーターを使用しています。 このメーターは、アナログ信号を送信するか、 IO-Link マスターと通信するように設定できます。 簡単にするため、ここではアナログ出力を使用しています。 流量計からの測定値は、シングルボードコンピューター (この場合は手頃で軽量な Raspberry Pi Zero W ) によって処理されます。 お好みであれば、AWS IoT Greengrassを実行できる別のデバイスをRaspberry Piの代わりに使うこともできます。 同様に、メーターとの通信に別のプロトコルを使用することもできます。 1 つのオプションとして、AWS が提供する IoT Greengrass コンポーネントによる処理が可能な Modbus が考えられます。 こちらの IoT Greengrass コンポーネントの詳細は、 Modbus-RTU プロトコルアダプター を参照してください。 センサーから取得したデータはエッジデバイス上で処理され、その後 MQTT メッセージを使用して AWS IoT Core に送信されます。AWS IoT ルールエンジンは受信したメッセージを AWS Lambda 関数にルーティングします。この Lambda 関数はメッセージペイロードを解析し、個々の測定値を Amazon Timestream に保存します。(Amazon Timestream は時系列データベースで、Amazon Managed Grafana や Amazon SageMaker と密接に統合されているため、今回のユースケースに最適です。) 次に Lambda 関数は、受信したデータポイントの異常スコアを計算するために、複数の SageMaker エンドポイントを呼び出します。 図 2: AWS IoT Core へのデータフロー 図 2 は、水道メーターから AWS IoT Core にデータが流れる様子を示しています。 このプロジェクトでは、2 つの測定値 (温度と流量) を受け取るため、2 本の電線が使用されています。 特筆すべきは、送信される信号は、既知の下限値と上限値を持つ電圧に過ぎないことです。 Raspberry Pi Zero にはデジタル GPIO ヘッダしかなく、これらの信号を使えるようにするにはアナログデジタル変換器 (ADC) を使う必要があります。 Raspberry Pi 上のセンサーデータコンポーネントは、ADC の出力を使って与えられた電圧と既知の範囲に基づく線形補間によって、実際の値を計算します。(センサーデータコンポーネントはこのアーキテクチャ専用に書かれており、マネージド AWS IoT Greengrass コンポーネントではないことにご注意ください)。 最後に、計算された値と、デバイス名などのメタデータが AWS IoT Core に送信されます。 このアーキテクチャは、センサーデータコンポーネントを適応させるだけで、さまざまな種類の計測器に対応できる柔軟性があります。多数の計測器からデータを収集する使用事例の場合、それらに対応するためにいくつかの変更が必要になる可能性があります。関連するアーキテクチャの選択について詳しくは、 AWS IoT Core および/または Amazon Kinesis を使用してデバイスからデータを取り込むベストプラクティス (Best practices for ingesting data from devices using AWS IoT Core and/or Amazon Kinesis) をご覧ください。 次のセクションでは、このソリューションで使用する 3 つの主要コンポーネントについて説明します。 Data Ingestion and Processing メーターデータを取得するために、エッジデバイスは適切な間隔でセンサーにポーリングします。デバイス上でデータが処理された後、メッセージのペイロード (リスト 1) が AWS IoT Core に送信されます。具体的には、AWS IoT Greengrass コンポーネントは、組み込みの MQTT メッセージング IPC サービス を利用して、センサーデータをブローカーに通信します。 { "response": { "flow": "1.781", "temperature": "24.1", }, "status": "success", "device_id": "water_meter_42", } リスト 1: MQTT メッセージペイロードのサンプル メッセージがブローカーに到着すると、AWS IoT ルール がトリガーされ、受信データを Lambda 関数に中継します。 この Lambda 関数はデータを Timestream に保管し、異常スコアを取得します。 データを時系列データベースに保存することで、過去の測定値の履歴がデータとして蓄積されます。 これにより、過去のデータ分析、機械学習モデルのトレーニング、過去の測定値の可視化など、様々なデータ活用が可能となります。 Data Visualization 履歴データを可視化することで、データの探索やデータの整合性を手動で確認することができます。今回のソリューションでは、Amazon Managed Grafana を使用し、インタラクティブな可視化環境を提供します。 Amazon Managed Grafana は、提供されているデータソースプラグインにより Timestream と統合されています。(詳細は Amazon Timestream データソースに接続する を参照してください。) このプラグインを使うと、収集されたすべてのメトリクスを表示するダッシュボードをセットアップできます。 図 3 は Amazon Managed Grafana ダッシュボードのキャプチャです。 グラフは時間経過に伴う水の流量 (リットル/分) と温度 (摂氏) の測定値を表示しています。 図 3: Amazon Managed Grafana のモニタリングダッシュボード 図 3 の上のグラフは、約 11 時間の期間の流量計の測定値を示しています。水の流れのパターンを確認することで、水ポンプが何度もオン/オフを繰り返しているという特徴がわかります。 下のグラフは、同じく約 11 時間の時間枠において水温が約 20℃ から 40℃ の間で変化していることが読み取れます。 Advanced Use Cases 各センサーの過去の履歴データを活用することで、SageMaker を使用した機械学習モデルをトレーニングすることが可能となります。 今回のメーターデータの例では、オペレーターは異常や故障に迅速に気づき、重大な損害が発生する前に原因を調査できるようになることを目指し、リアルタイムで異常検知を行うモデルの構築を行います。 図 4: 水流量監視における 2 つの異常の例 図 4 には、水の流れの異常がどのようなものかを示す 2 つの例が含まれています。 このグラフは約 35 分間の水の流れの測定値を示しており、2 つの不規則性が見られます。 両方の異常は約 2 分間続き、赤い長方形で強調表示されています。 これらは、水道管の一時的な漏れが原因で発生したもので、特徴的な流れのパターンの変化から特定することができます。 SageMaker には、自動異常検出に使える 組み込みアルゴリズムと事前学習済みモデル がいくつか用意されています。 これらを活用することで、コーディングがほとんどなくすぐに実験を開始いただけます。 加えて、組み込みのアルゴリズムは、必要に応じて複数のインスタンス間での並列処理の最適化がされています。 Amazon の Random Cut Forest (RCF) アルゴリズム は、この アーキテクチャでテストされている組み込みアルゴリズムの 1 つです。 RCF は、各データポイントに対して異常スコアを関連付ける教師なし学習アルゴリズムです。 教師なしアルゴリズムは、ラベルなしデータを使って学習します。 詳細については、 ”教師あり学習と教師なし学習はどのように異なりますか?” のページを参照してください。 計算された異常スコアは、任意の次元数の入力において、規則的または規則的なパターンからはずれた異常な挙動を検出するのに役立ちます。 さらに、このアルゴリズムのプロセスは、特徴量の数、インスタンスの数、データセットサイズに応じてスケールします。 経験上、平均から標準偏差の 3 倍を超える高いスコアが異常と判断されます。 このアルゴリズムは教師なし学習なので、学習プロセスでラベルを提供する必要はなく、正確な異常ラベル付けができないセンサーデータにも特に適しています。 モデルがデータセットで学習された後、そのモデルを使用して全てのメーターのデータポイントに対して異常スコアを計算できます。この異常スコアは、後で参照するために別の Timestream データベースに保存されます。異常判定のための閾値も設定する必要があります。 Amazon Managed Grafana を使用すれば、分類された異常スコアを可視化できます (図 5 参照)。 図 5: Amazon Managed Grafana にて可視化した RCF による異常分類結果 図 5 は、時系列データと状態を示すウィジェットが表示されている Managed Grafana ダッシュボードの一部です。時系列データは水の流量を表しており、異常な流量となっている 1 分の区間が含まれています。状態を示しているウィジェットには、RCF アルゴリズムによる異常分類の結果が表示されます。緑は正常な状態を、赤は異常な状態を表しています。 アルゴリズムが異常を検出した場合、様々な自動化されたアクションを実行できます。 たとえば、 Amazon Simple Notification Service (Amazon SNS) を使用して、SMS やメールでユーザーへの通知が可能です。 スコア算出がリアルタイムに近い形で行われるため、大きな損害が発生する前に潜在的な問題を素早く検出することができます。 Conclusion このブログ記事では、既存の計測データを AWS に統合することで得られる付加価値と、その実装例について説明しました。 このソリューションは、アナログセンサからデータを収集し、AWS IoT Greengrass デバイスを使って AWS IoT Core に取り込み、Amazon Timestream にて計測値を処理・保存し、SageMaker で異常検知を行います。 この例ではメーターとしての水道メーターを取り上げていますが、利用したコンポーネントは任意のタイプのメーターデバイスで動作するように変更できます。 同様のシステムを実装したい場合は、上記の AWS サービスを活用することでメーター監視ソリューションを構築してみてください。 運用レディな本番アプリケーションを開発したい場合は、Raspberry Pi Zero を本番ワークロードに適したデバイスに置き換える必要があります。 デバイスについては、 AWS パートナーデバイスカタログ を参照してください。 水漏れの検出に関するさらなる議論については、 AWS IoT を使用してリアルタイムに近い水漏れを検出する (Detect water leaks in near real time using AWS IoT) をご覧ください。 農業での異常検出の活用にご興味があれば、 AWS IoT を使用したサーバーレス異常検知による農業業務の合理化 (Streamlining agriculture operations with serverless anomaly detection using AWS IoT) をご覧ください。 この記事は Tim Voigt と Christoph Schmitter によって書かれた Connected utility solutions for water and gas metering with AWS IoT の日本語訳です。この記事は Solutions Architect の西亀真之が翻訳しました。 著者について Tim Voigt Tim Voigt は、AWS の PACE チーム (プロトタイピングとクラウド エンジニアリングの略) のソリューション アーキテクトです。ドイツに拠点を置き、AWS で働きながらコンピューターサイエンスの大学院研究を続けています。Tim は、現実世界の問題を解決するための新しいソリューションを開発し、その根底にある技術的概念を深く掘り下げることに情熱を注いでいます。 Christoph Schmitter Christoph Schmitter は、デジタルネイティブのお客様を担当するドイツのソリューションアーキテクトです。Christoph はサステナビリティを専門とし、企業が持続可能な製品やソリューション構築のための変革をサポートしています。 AWS に入社する前は、ソフトウェア開発、アーキテクチャ、クラウド戦略の実装において幅広い経験を積んでいました。スケーラブルで復元力のあるシステムの構築から、子供たちのロボットのクラウドへの接続まで、あらゆるテクノロジーに情熱を注いでいます。仕事以外では、読書、家族との時間を過ごし、テクノロジーをいじることを楽しんでいます。

本稿は、2024 年 9 月 17 日に IBM &amp; Red Hat on AWS Blog で公開された “ Unlocking Transformative Benefits of Modernizing VMware workloads to Red Hat OpenShift on AWS ” を翻訳したものです。 今日の急速に進化する技術の環境において、企業は VMware のワークロードと仮想マシン (VM) をクラウドに移行・モダナイゼーションする方法を求めています。注目を集めているアプローチの 1 つは、従来の VM を Red Hat OpenShift on Amazon Web Services (AWS) などのコンテナ化された環境に移行するか、 OpenShift Virtualization on AWS に直接移行することです。 VMware ワークロードを移行してモダナイゼーションする方法を多くのお客様が探しています。お客様にとってスピードは最も重要な要素の 1 つですが、実際の VM をクラウドに移行するスピードはあくまで考慮すべき 1 つの要素に過ぎません。可観測性や VM へのトラフィック公開方法など、VM を本番環境で使用できるようにする前に実装しなければならない追加の要件があります。 本稿では、VMware の VM とワークロードを Red Hat OpenShift Service on AWS (ROSA) に移行する際の「何を」「なぜ」「どのように」について説明し、移行プロセスの理解と、さらに深く掘り下げるための追加リソースを提供します。 Red Hat OpenShift Service on AWS とは Red Hat OpenShift Service on AWS (ROSA) は、クラウドネイティブのアプリケーションプラットフォームで、組織が AWS 上でコンテナ化されたアプリケーションのビルド、デプロイ、管理をシームレスに行えるようにします。Kubernetes の上に構築されたサービスのスタックを提供し、アプリケーションのデプロイ、スケーリング、管理を自動化するための一連の機能を提供します。 ROSA は、OpenShift の機能と AWS のスケーラビリティと柔軟性を組み合わせた、Red Hat Site Reliability Engineer (SRE) によるフルマネージドなサービスです。この統合により、組織はクラウドネイティブプラットフォームのメリットを活用しながら、サーバーレスコンピューティング、マネージドデータベース、高度な分析などの AWS が提供する幅広いサービスの利点も享受できます。 VMware VM を OpenShift Virtualization on ROSA に移行する理由 OpenShift Virtualization on ROSA を使用すると、VM を クラウドに移行するスピードを満たし、運用要件を簡素化することで VM を本番環境に移行するまでの時間を短縮できます。Red Hat Migration Toolkit for Virtualization (MTV) を使えば、既存の VMware クラスターを ROSA に接続し、移行したい VM を選択して ROSA にインポートできます。お客様は VM 自体を変更する必要なく、ROSA の Infrastructure as Code (IaC) 用の組み込みツール、メトリクス、ダッシュボード、ロードバランシング、アラートを活用できます。 このアプローチにより、お客様は AWS への移行を加速し、VMware vSphere または VMware Cloud Foundation (VCF) から AWS へのリプラットフォームにかかる総時間を短縮できます。 VMware ワークロードを Red Hat OpenShift Service on AWS (ROSA) に移行すると、さまざまな利点があります。特にアプリケーションのモダナイゼーション、クラウドネイティブ機能の活用、運用の簡素化を目指す組織にとって有益です。ROSA に VMware ワークロードを移行する主な理由を以下に示します。 OpenShift Virtualization on ROSA の利点 クラウドネイティブアプローチ : 組織はリソース使用率の改善、より高速なデプロイメントサイクル、アプリケーション管理の合理化など、クラウドネイティブアーキテクチャの利点を活用できます。 アジリティとスケーラビリティの向上 : 従来の仮想マシンはリソースを大量に消費し、アプリケーションのスケーリングや更新に関して俊敏性が低下する可能性があります。ROSA は自動スケーリング機能を提供し、アプリケーションがワークロードの変化に動的に対応できるようになるため、最適なパフォーマンスと効率的なリソース活用が可能になります。 ライセンスコストの削減 : 組み込みの無制限の RHEL エンタイトルメントにより実現します。OpenShift Virtualization には、すべての RHEL ゲスト VM に対する無制限の RHEL サブスクリプションが含まれています。 セキュリティとコンプライアンスの強化 : ROSA は業界をリードするセキュリティ標準に準拠し、さまざまな規制要件に準拠しています。組み込みのセキュリティ制御、自動化された脆弱性管理、セキュアなマルチテナンシーなどの機能を備えており、アプリケーションとデータを保護します。 運用オーバーヘッドの削減 : ROSA を活用することで、組織はインフラストラクチャのプロビジョニング、スケーリング、メンテナンスなどの多くの運用タスクをマネージドサービスにオフロードできます。この運用オーバーヘッドの削減により、チームは複雑なインフラストラクチャの管理ではなく、ビジネス価値の提供に集中できます。 従量課金制 (Pay-As-You-Go) : 使用したリソースに対してのみ支払うことができます。ROSA に移行することで、従来のデータセンターモデルにありがちな多額の先行投資の必要性が軽減されます。 VM ワークロードの高可用性 : OpenShift および AWS アベイラビリティーゾーンの組み込み機能により実現します。アベイラビリティーゾーン間の VM への接続を簡素化するために、Elastic Load Balancing (ELB) を活用できます。 ディザスターリカバリー機能 : AWS のグローバルインフラストラクチャとサービスを活用して、地理的に分散した AWS リージョン間で環境やアプリケーションをレプリケートすることができます。 ROSA を活用したモダナイゼーション：変革をもたらすメリットを解き放つ 従来、VM ベースのアプリケーションをクラウドに移行し、コンテナ化したいお客様は、進め方の選択肢が限られていました。たとえば、VMware のワークロードを Amazon Elastic Compute Cloud (Amazon EC2) 上で実行するように変換するなど、同様のコンピューティングプラットフォームへのリフト＆シフトによる移行を行うことができます。この段階でお客様はクラウドに移行し、 AWS クラウドの利点 を得られますが、アプリケーション自体はメリットを得られません。 コンテナを利用するには、お客様はモダナイゼーションの取り組みに着手し、VM ベースのアプリケーションをマイクロサービスに分解し、コンテナとしてデプロイし、最終的に新しくコンテナ化されたアプリケーションを選択したコンテナプラットフォームに移行する必要があります。 お客様に別の簡単な選択肢、つまり VM をクラウドとコンテナプラットフォームに直接移行できる選択肢があったらどうでしょうか。 ここで OpenShift Virtualization と ROSA が役立ちます。OpenShift Virtualization は、アップストリームプロジェクトの KubeVirt に基づいており、これによりお客様は Kubernetes 内でネイティブリソースとして VM を実行できます。コンテナに利用可能なすべての機能や特徴が VM に拡張されるようになりました。コンテナ化されたアプリケーションがサービスメッシュを使用している場合、VM をそこに追加できます。サービスオブジェクトを定義してコンテナを公開する方法と同様に、VM へのトラフィックを公開して負荷分散します。さらに、オンデマンドで VM リソース (CPU/MEM) の垂直スケーリングや VM のライブマイグレーション機能などの追加機能もあります。 ROSA は、同じプラットフォーム上で VM とコンテナの両方を管理できる機能を提供します。これにより、VM ベースのアプリケーションをマイクロサービスに分解し、移行の手順を減らすことができます。 変換できない VM の場合、またはライセンスなどの理由でVM として残す必要がある場合でも、ROSA からアプリケーション中心のメリットをすべて享受できます。コンテナと VM の両方に単一画面と共通のツールセットを使用することで、運用オーバーヘッドを削減できます。 ROSA 上の VM をモダナイゼーションする手順 移行プロセス全体を通して、アプリケーション開発者、オペレーション担当者、セキュリティ専門家など、さまざまな部門の関係者を関与させることが重要です。このような協業的なアプローチにより、移行が効率的に実行され、結果として得られる環境が組織の目標と要件に沿ったものになります。 さらに、クラウド移行とモダナイゼーションプロジェクトに特化した Red Hat と AWS パートナーの専門知識を活用することをお勧めします。これらのパートナーは、移行プロセスを円滑化し、成功を確実にするための貴重なガイダンス、ベストプラクティス、実践的な支援を提供できます。 VMware VM を ROSA に移行およびモダナイズする際の高レベルの手順を次に示します。 計画と評価 : 移行対象のアプリケーションまたはワークロードを特定し、優先順位付けをします。アプリケーションのアーキテクチャ、依存関係、リソース要件を評価します。移行に伴う潜在的な課題やリスクを評価します。 アプリケーションのコンテナ化 &nbsp;: アプリケーションをコンテナ化の原則とベストプラクティスに従うようにリファクタリングまたは再構築します。アプリケーションとその依存関係をコンテナイメージにパッケージ化します。コンテナ化されたアプリケーションが十分にテストおよび検証されていることを確認します。 インフラストラクチャのセットアップ : Amazon Virtual Private Cloud (Amazon VPC)、サブネット、セキュリティグループなど、AWS 上に必要なインフラストラクチャをプロビジョニングします。 AWS Marketplace の Red Hat OpenShift Service リストを通じてサブスクライブしデプロイすることで、ROSA クラスターをデプロイおよび構成します。アプリケーションで必要な追加の AWS サービス (データベース、キャッシュ、メッセージングシステムなど) をセットアップします。 アプリケーションのデプロイメント : コンテナイメージを OpenShift クラスターからアクセス可能なコンテナレジストリにプッシュすることで行います。必要な Kubernetes リソース (Deployment、Service、ConfigMap など) を定義して適用し、OpenShift にアプリケーションをデプロイします。必要に応じてネットワーキング、ストレージ、その他のリソースを構成します。VMware VM を ROSA Virtualization にシームレスに移行するには、 OpenShift Virtualization on AWS ブログ の情報に従ってください。 テストと検証 : デプロイされたアプリケーションを徹底的にテストし、新しい環境で期待どおりに機能することを確認します。さまざまな負荷条件下でのパフォーマンス、スケーラビリティ、および復元力を検証します。セキュリティとコンプライアンスのチェックを行い、組織のポリシーと規制要件を遵守していることを確認します。 モニタリングとメンテナンス &nbsp;: アプリケーションとインフラストラクチャのパフォーマンスを可視化するため、モニタリングとロギングソリューションを実装します。OpenShift 上のアプリケーションの継続的なメンテナンス、更新、スケーリングのためのプロセスを確立します。ローリングアップデート、ロールバック、自動スケーリングなどの OpenShift 組み込み機能を活用し、アプリケーションライフサイクル管理を合理化します。 まとめ 企業は、コンテナ化によってもたらされるメリットやその影響力、および ROSA のクラウドネイティブ機能を活用することで、デジタルトランスフォーメーションの取り組みを加速し、イノベーションを促進し、ますます競争が激しくなる市場で優位に立つことができます。慎重に計画し、ベストプラクティスを遵守し、経験豊富なパートナーと協力することで、移行における課題と複雑さを最小限に抑えることができます。 さらに詳しく知りたい場合は、AWS または Red Hat のアカウントチームにご連絡いただくか、AWS Red Hat パートナーチームに電子メールをお送りいただくか、近くで開催される OpenShift Virtualization ロードショー の日程をご確認ください。（訳註：日本ではエンドユーザー様を対象に 2024 年 11 月 15 日 14:00-16:00 に 開催 が予定されています。） 関連コンテンツ AWS Marketplace から Red Hat OpenShift on AWS をサブスクライブする OpenShift Virtualization on ROSA に関するブログ Red Hat OpenShift Virtualization について学ぶ <!-- '"` --> Elvis Pappachen Elvis Pappachen は、クラウドと IT 分野でお客様をサポートしてきた 20 年以上の経験があります。Amazon Web Services, Inc (AWS) のソリューション アーキテクトであり、AWS でのパフォーマンス、スケーラビリティ、コスト効率を最適化するための複雑なクラウド移行および変革プロジェクトを通じてお客様とパートナーを支援しています。自宅のオートメーション化をさらに進める方法を考えていない時間には、家族と過ごしたり、旅行したり、新しい料理を楽しんだりして自由時間を過ごしています。 Anupama Padmanabhan Anupama は IT 業界で 24 年以上の経験があります。彼女は、革新的なクラウド ジャーニーを通じてクライアントを導く最前線に立ってきました。彼女の専門知識は、移行、モダナイゼーション、クラウド ターゲット オペレーティング モデル、堅牢なビジネス ケース開発のためのクラウド戦略に重点を置き、大規模クライアントとの数多くのクラウド アドバイザリー業務に携わっています。 Trey Hoehne Trey Hoehne は、Amazon Web Services (AWS) の AWS Go To Market Container スペシャリストであり、お客様が AWS でコンテナを導入できるよう支援することに重点を置いています。 本稿の翻訳は Partner SA の豊田が担当しました。

本ブログは、株式会社エウレカと Amazon Web Services Japan が共同で執筆しました。 背景と概要 Pairs（ペアーズ）は、株式会社エウレカが運営する恋活・婚活のマッチングアプリです。大規模なユーザーベースを持つマッチングサービスであり、システムの安定稼働が非常に重要です。 多くのユーザーにとって、マッチングした後、ペアーズが実際に会うときの唯一の連絡手段となっています。そのため、障害が発生するとユーザー同士の連絡が取れなくなるので、迅速に対応を行い、再発防止のためのナレッジを貯める必要があります。過去には、障害発生時の対応に多大な時間とリソースを費やしてきました。特に、障害対応の指揮を取るコマンダーの責務が多すぎることで、新任のコマンダーが対応に苦労する場面が多々ありました。 そこで、Amazon Bedrock を活用して障害対応の一部を自動化・効率化し、コマンダーの負担を軽減することで、誰でも対応しやすい環境を整えるプロジェクトを開始しました。具体的には、社内チャットツールのメッセージを活用して中間報告書とポストモーテム文書を自動作成する機能を提供しています。 Amazon Bedrock を活用した障害対応の自動化 技術選定 Amazon Bedrock 選定の理由 他の LLM サービスではなく、Amazon Bedrock を選定した理由は以下の通りです。 Amazon Elastic Kubernetes Service (Amazon EKS)との統合が容易: ペアーズのアプリケーションをホスティングしている環境が Amazon EKS で構築されているため、IAM Roles for Service Accounts (IRSA) などを活用してきめ細かい権限設計が可能。 Managed RAG 機能が利用可能: Knowledge base for Amazon Bedrock などの Managed RAG 機能が利用可能であり、ペアーズの LLM チャットボットでの利用にも活用できる。 LLMOps のサポート: モデル評価やプロンプトマネジメントなど、LLMOps で必要な要素が網羅的に提供されている。 モデル選定 Amazon Bedrock のモデル選定に関して、今回の社内利用のユースケースではコストやレスポンス速度はあまり問題にはならないため、性能を重視して Claude 3 Haiku ではなく Claude 3.5 Sonnet を選びました。 Claude 3.5 Sonnet は、Anthropic 社が開発した大規模言語モデル(LLM)であり、自然言語処理タスクにおいて高い性能を発揮します。特に、日本語の処理能力が高く評価されています。ペアーズでは、障害対応の自動化において、高い言語処理能力が求められるため、Claude 3.5 Sonnet を採用しました。 報告書作成シーケンス ペアーズの報告書作成シーケンスは、以下のようになっています(ポストモーテム文書作成も同様)。 従業員が社内チャットツールにて報告書作成依頼コマンドを実行し、それを Incident Bot が受け付ける Incident Bot が LLM API を呼び出す LLM AP Iが Amazon Bedrock を利用して、報告テンプレートと社内チャットツールのメッセージ・障害情報から障害の要約を生成する 。 生成された要約を駆使して報告書が作成され、社内のドキュメント、チャットツールに投稿される このシーケンスでは、従業員が手動で報告書を作成する必要がなくなり、効率的な障害対応が可能になります。また、LLM を活用することで、報告書の品質も向上します。 （※実際の報告書ではありません） システムアーキテクチャ 従業員からの報告書作成依頼コマンドを受け付け、ハンドリングする Incident Bot Server が、Amazon API Gateway と AWS Lambda で構築されています。そこからリクエストを受け付ける LLM API が Amazon EKS 上に構築されており、Amazon Bedrock を用いた障害情報の要約処理が行われております。 このアーキテクチャにより、スケーラビリティの高いシステムを構築することができます。 LLMを利用したAPI処理の工夫点 データ前処理 社内チャットツールのメッセージデータから Bot の発言などを取り除き、必要なメッセージに絞る処理をしています。また、メッセージデータに含まれるタイムスタンプは、対応時系列の項目などで使用したい形式にあらかじめ変換しています。 このように、LLM に任せる必要のない単純なデータ処理は事前に済ませておくことで、LLM を本質的なタスクに集中させ、生成の精度を上げることにつながります。 また、Claude のモデルは命令プロンプトをXML形式で記述すると生成の精度が上がる傾向にあるため、メッセージデータを XML 形式に変換して Amazon Bedrock への命令プロンプトの一部として埋め込んでいます。 リトライ機構 使用しているドキュメントツールの制約により、Amazon Bedrock を用いて XHTML 形式のデータを生成する必要があります。そのため、プロンプトで XHTML 形式のデータ生成を指示します。その際、プロンプトの最後にアウトプットが有効な XHTML かどうかを LLM 自身に再度バリデーションさせるとより効果的です。さらに、有効な XHTML であることを後処理でもバリデーションし、もし有効な XHTML でない場合は生成処理をリトライするように実装しています。LLM の出力はどんなにプロンプトを工夫しても必ずしも命令を守ってくれるとは限らないので、このようなリトライ機構は非常に重要です。 リトライ機構の導入により、出力の品質が大幅に向上しました。初期の試行では、約30%の出力が XHTML の要件を満たしていませんでしたが、リトライ機構の導入後は99%以上の出力が要件を満たすようになりました。 LLM に全てを生成させない 状態が遷移しがちでハルシネーションや処理ミスが起こりやすいテンプレート項目(障害深刻度など)は、別で保存されているデータを取得しテンプレートに埋め込み、LLM に生成させないようにしています。また、静的なテンプレート部分(注意事項など)は、生成データに後処理で結合するようにしています。LLM が生成する必要がない/不得意な部分は、LLM に生成させないという考え方はどのタスクでも有効です。 この工夫により、LLM に適したタスクに特化させることができ、出力の品質が向上しました。また、処理の効率化にもつながりました。 導入効果 Amazon Bedrock を導入した結果、以下の成果を得ることができました。 対応時間/コストの短縮 障害対応報告書とポストモーテム文書の自動生成により、報告や振り返りにかかる工数が約60%削減され、対応時間/コストが大幅に短縮されました。 具体的には、従来は報告書作成に1人当たり平均3時間を要していましたが、自動化後は1時間程度に短縮されました。また、ポストモーテム文書作成に関しても、従来は1人当たり4時間を要していましたが、1.5時間程度に短縮されました。 このように、自動化による大幅な工数削減が実現でき、障害対応にかかるコストを大きく削減することができました。 障害対応の心理的負担軽減 従来は、コマンダーが報告書やポストモーテム文書の作成を含む多くの業務を担っていたため、特に重大な障害発生時には過度の負荷がかかっていました。しかし、自動化により、これらの業務の一部が軽減されたことで、コマンダーの負担が大きく軽減されました。 また、報告書やポストモーテム文書の品質も向上したことで、コマンダーが内容を確認し修正する手間も削減されました。 このように、自動化による業務の効率化と品質向上により、コマンダーの心理的負担が軽減され、障害対応体制の強化につながりました。

はじめに 全日本空輸株式会社 整備センター 機体事業室 機体計画部 航空機売却・リースチームでは航空機のリース返却業務を行っております。 本ブログでは、業務における膨大なドキュメントの転記作業を AWS 上の OCR 技術と AI による画像分析技術を活用し生産性向上を実現された事例について、同チームの九冨様に寄稿いただいたものです。 PDF 化した整備記録から整備タグ情報を読み取る手間 AWS 三宅： 整備タグの読み取り業務において AWS サービスを活用するに至った背景を教えてください。 ANA 九冨様： ANA では、自社で保有する航空機だけでなく、外部の会社からリースしている機体も運航しております。私達のチームでは、リース返却時、機体に装着されている部品の識別を特定するため、過去の全整備記録の中から取り付けられた部品情報の記載がある整備タグ*の内容を抽出しリスト化する業務を行っております。これまで人力で調査を実施しておりましたが、1 機あたり約 1.5 万 – 3 万件もの整備記録からデータを抽出する必要があり大変な負担となっておりました。この作業の負荷低減のためソリューションを模索していたところ、社内 IT チームと AWS 主催の AWS 勉強会にて AWS に OCR を実現する AI サービス「Amazon Textract」があることを知り、活用できないかと考えました。 *整備タグ：航空整備作業で部品交換発生時に使用する部品の品質保証書がシール化されたもの。取り付けられた部品のタグが対象の整備記録に貼り付け、または、添付され保管される。 整備タグ OCR システム AWS 三宅： Amazon Textract を中心にどのような整備タグ OCR システムを開発されたのでしょうか。 ANA 九冨様： 全体アーキテクチャは下記の通りです。PDF 化された整備記録を指定の Amazon S3 に格納することで、OCR 結果が CSV ファイルとして出力されるように構成しました。事前に社内 IT 部門によるセキュリティー審査を行い、AWS 上へのファイルのアップロードやダウンロードは、社内のセキュリティポリシーに則して最小権限を持つユーザのみが実施可能になっています。 Amazon Textract ANA 九冨様： 本システムは AWS のサーバレスサービスを使ったアーキテクチャで構成されています。 Amazon Textract によって、タグ内の表形式の内容を Key と Value の形式で文字データを抽出しています。 抽出した文字データは一時的に Amazon DynamoDB に格納し、全体処理の完了後、Amazon S3 に CSV 形式で結果を出力しています。 Amazon Rekognition ANA九冨様： 当初、整備記録の PDF をそのまま Amazon Textract に処理させようとしていましたが、下記のような課題が発生しました。 &nbsp;数十ページある PDF ファイルの中に、整備タグは数ページにしか存在せず、それ以外のページに対しては不必要な Amazon Textract の処理（ページ数毎の課金）が発生してしまう 1 枚に複数の整備タグが貼付されている場合、抽出した文字を分類することができない そこで、Amazon Textract による処理の前段に Amazon Rekognition のカスタムラベルを用いて、整備記録の中にある整備タグの部分のみの画像を切り抜き、その画像を Amazon Textract にて OCR 処理させるように工夫しました。 具体的な処理手順は下記になります。 数種類ある整備タグを横向き、タテ向きでそれぞれ 100 枚ずつ学習を行い、正解率 92% のカスタムラベルのモデルにて、整備タグの有無を判定 タグ有の判定の場合は、カスタムラベルの推論結果をもとに、AWS Lambda にて OpenCV（画像処理ライブラリ） を用いてタグ部分の切り抜きを実施 Amazon Rekognition カスタムラベルを導入することで、Amazon Textract で処理する枚数を削減することができ、Amazon Textract 単体の場合と比較して、コストの削減を実現しました。 また Amazon Textract は検証で 89% の精度でした。手書きの文字や、罫線に重なった文字は上手く認識しないこともあり、Key となる項目の名前のゆらぎは AWS Lambda 側にて訂正対応する処理を行っています。 スロットリング対策 Amazon Textract や Amazon Rekognition に一度に大量にデータを入力するとスロットリングエラーが発生することから、Amazon SQS や Amazon DynamoDB を用いて、適切に入出力が制御できるよう調整を行いました。 導入効果 AWS 三宅： OCR システムの導入効果と今後の展望についてお聞かせください。 ANA九冨様： １ 機分のデータ約 1.5 万件の中からサンプリングで約 5600 件の整備記録を用いて検証を行い、下記の結果となりました。 Amazon Rekognition カスタムラベルの正解率 ： 99.7% Amazon Textract のOCR の正解率： 89%（癖字や薄い印字は読み取り困難） 5600 ファイル（27,000 ページ）の中から、約 2000 枚の整備タグを抽出し転記する作業の工数削減 作業者の負担を大幅に低減できると判断できたため、今後は、本構成を使って実運用を開始していくとともに、更なる精度向上や保守体制を構築、誰でも使えるよう手順書を作成し汎用性を高めていきたいと考えております。 著者/協力者について 左側から 作山　直臣　マネジャ 整備センター　機体事業室　機体計画部　航空機売却・リースチーム 田中　誉之密　マネジャ 整備センター　機体事業室　機体計画部　航空機売却・リースチーム 九冨　佑輔 整備センター　機体事業室　機体計画部　航空機売却・リースチーム 向　晃弘　リーダー 整備センター　プロセス変革推進部　ＩＴチーム 森　俊介　マネジャ 整備センター　プロセス変革推進部　ＩＴチーム AWS ソリューションアーキテクト 三宅 穂波

メインフレームとAWSを統合する共存アーキテクチャ 本記事は 2024 年 9 月 3 日に Migration &amp; Modernization Blog &nbsp;で公開された Integration architectures between mainframe and AWS for coexistence を翻訳したものです。 ブログでは、移行期におけるハイブリッド アーキテクチャの統合パターンとソリューションの設計方法を説明します。 メインフレーム環境のアプリケーションは、コードやデータもしくはその両方を共有することで、複雑に絡み合い密結合している場合があります。大規模なメインフレームアプリケーションを AWS に移行する際は、 Strangler Fig パターン を使用した段階的アプローチが推奨されます。段階的アプローチにより、移行 (マイグレーション) または変革 (モダナイゼーション) の過渡期の間、メインフレームと AWS 間のハイブリッドアーキテクチャが構築され、その統合が実現されます。 概要 メインフレームのワークロードは通常、一連のビジネス機能を実行する一連のプログラム、ミドルウェア、データストア、依存関係、およびリソースとして定義されます。AWS は、お客様のビジネスおよび技術戦略の目標に応じて、メインフレームのワークロードをモダナイズするための複数のパターンを提案します。これらのオプションは大きく 2 つのグループに分類できます。 マイグレーション &amp; モダナイゼーション (図 1.1 – 左) 拡張 &amp; 統合 (図 1.2 – 右) 図 1: AWS Mainframe Modernization パターン アプリケーションと移行の目的に合わせて、リプラットフォーム、リファクタリング、リライト、リパーチェスなどの各種手法を用い、メインフレームからコンポーネントを切り離して AWS クラウドに移行することを目指します。 ワークロードの拡張と統合は、メインフレームのデータを活用して、AWS 上に新しいビジネス機能を構築することを目的としています。 どちらのアプローチでも、メインフレームと AWS 環境を統合する共存アーキテクチャーが必要です。これには、移行フェーズ中または永続的にメインフレーム上に残るワークロードと、AWS クラウドに作成または移行されたワークロード間の相互作用の管理が含まれます。 アプローチ 通常、大規模なメインフレームのワークロードは並行して実行され、相互に密結合しています。Strangler Fig パターンの場合、各ワークロードは個別に移行されます。全体的に見れば、ワークロードを 1 つずつ順番に移行します。ビジネス価値、アプリケーションの複雑さ、統合ポイント、ビジネスの重要性に基づいてワークロードの移行に優先順位を付けます。時間の経過とともに、メインフレームのワークロードを 1 つずつ分離していきます。 図 2: ワークロードの絞り込みによるメインフレームアプリケーションの移行 メインフレームワークロードの移行に際しては、それらと強く結び付いた別のワークロードが存在しています。それらのワークロードにはアプリケーション間、データ間、またはアプリケーションとデータ間の統合機能が組み込まれています。図 2 は、一部のワークロードが AWS&nbsp; に移行され、他のワークロードがメインフレームに残るシナリオを示しています。 図 3 は、3 つの異なるタイプの統合を説明しています。 アプリケーション間 アプリケーションからデータへ データ間 図 3: 共存のためのハイブリッドアーキテクチャの必要性 さまざまな統合タイプは相互に排他的ではなく、むしろ互いに補完し合うことができます。統合タイプの選択は、主に、ワークロード間のメインフレーム上の既存の統合設定に影響されます。たとえば、ワークロードがアプリケーションコンポーネント (CICS、COBOL、MQ コールなど) を介してワークロード 2 とやり取りする場合は、アプリケーション間のパターンを確立する必要があります。逆に、ワークロードがワークロード 2 のデータにアクセスする必要がある場合は、データからデータへ、またはアプリケーションからアプリケーションへのパターンのいずれかを実装する必要があります。これらのパターンと関連する技術的実装のどちらを選択するかは、主に、スループット、パフォーマンス、プライマリデータの場所という 3 つの重要な基準に基づいて決定されます。 統合パターン 以下のパターンは、共存シナリオでのアプリケーション統合とその利用可能なソリューションについて理解するのに役立ちます。市場には多数の製品がありますが、ここでは数種類について説明します。 パターン 1 – アプリケーション間の統合パターン アプリケーション間統合パターンとは、2 つのソフトウェアアプリケーションやシステムを接続し、それらが協調して動作できるようにするプロセスを指します。用途や要件に応じて、さまざまなタイプのアーキテクチャと統合方式があります。 アーキテクチャ的には、アプリケーションを統合するための手法として、ハブアンドスポーク、エンタープライズサービスバス (ESB)、API マネジメントなど、複数のパターンが存在します。これらのアーキテクチャパターンでは、メインフレームと他の環境の間で仲介役を果たす、中央統合ハブやミドルウェアプラットフォームが関わります。各アプリケーションはハブ、ESB、またはAPIマネジメントレイヤーにのみ接続すれば良く、それらが接続システム間のデータのルーティングと変換を管理します。このアプローチにより、統合の管理と保守が簡素化されます。中央ハブ、ESB、または API マネジメントレイヤーとメインフレーム間の接続は、図 4 で説明されているポイントツーポイント統合パターンに依存します。 図 4: アプリケーション間の統合パターン AWS クラウドとメインフレーム間の最も一般的な統合タイプは以下のとおりです。 JCA コネクタを使用したポイントツーポイント このタイプの統合では、2 つのアプリケーションを相互に直接接続してデータを交換します。Java Connector Architecture (JCA) コネクタを使用したポイントツーポイント統合では、Java EE アプリケーションと CICS、IMS TM、Db2 ストアドプロシージャなどのメインフレームサブシステムとの直接接続を確立する必要があります。JCA コネクタとのポイントツーポイント統合には、Java アプリケーションとメインフレームを直接接続できるため、パフォーマンス、スケーラビリティ、トランザクション性のサポート、セキュリティが向上するなどのメリットがあります。一方、統合システム間の緊密な結合が生じるため、メッセージングや API のように疎結合された統合アプローチに比べて、柔軟性が低下し、保守が困難になります。 CICS、IMS、Db2 との統合に使用される主な 3 つのポイントツーポイントソリューションは次の 3 つです。 CICS との統合には CICS Transaction Gateway (CTG) を使用します。CTG は z/OS またはオープンシステム上にデプロイできます。 IMS との統合には IMS Connect を使用します。IMS Connect は z/OS 上にデプロイする必要があります。 外部アプリケーションから直接 JDBC 接続して Db2 for z/OS ストアドプロシージャを呼び出す。 JCA コネクタを使用したポイントツーポイント統合の注目すべき点は、その単方向性です。つまり、双方向通信をサポートする IMS Connect の場合を除き、 AWS クラウドからメインフレームに流れ、その逆は行われないということです。 API ベースの統合 RESTful API ベースの統合は、ソフトウェアシステムを統合するための柔軟で標準化されたアプローチを提供します。これにより、相互運用性、スケーラビリティ、および開発の容易さが可能になります。RESTful API は、Web 開発、モバイルアプリ、クラウドコンピューティング、Internet of Things (IoT) など、さまざまな分野で広く使用されています。RESTful API ベースの統合を使用するアプリケーションは、2 つの環境間でのトランザクションコンテキストの伝播が軽減されるように設計する必要があります 。(例えば、 SAGA パターンや補償メカニズムを使う) そうしないと、一貫性の問題や同期の問題が発生する可能性があります。 IBM の z/OS Connect や OpenLegacy などのソリューションを使用することで、メインフレームのサブシステムをAPI化することができます。z/OS Connect を使用すると、プログラム、データ、トランザクションなどのメインフレームの資産を RESTful API として公開することができます。これにより、クラウド上の幅広い最新アプリケーションやサービスからこれらの資産にアクセスし、利用することができるようになります。z/OS Connect の大きな利点の 1 つは、双方向の統合機能を持っていることです。これにより、最新のアプリケーションとメインフレームシステムの間で、双方向の通信が可能になります。つまり、最新のアプリケーションがメインフレームからサービスやデータを利用できるだけでなく、メインフレームのトランザクションやアプリケーションが AWS からアプリケーションやサービスを利用することもできるのです。 メッセージ指向とイベント駆動型の統合 アプリケーションは、メッセージを介して非同期に通信します。メッセージはキューに入れられ、システム間で確実に配信されます。メッセージ指向とイベント駆動型の統合は、パブリッシュサブスクライブやリクエストリプライなど、様々なメッセージングパターンをサポートできます。IBM MQ は、メインフレームと AWS 間の通信とデータ交換を促進する主要なメッセージングミドルウェアの 1 つです。パブリッシュサブスクライブパターンやリクエストリプライパターンを活用することで、メインフレームとの統合に使用できます。 もう1つのオプションは、IBM MQ を介して Kafka をメインフレームと統合することです。これには、適切なコネクターを使用してKafkaとMQの間の通信を確立するために、Kafka Connect を使用することが含まれます。Kafka Connect は、メインフレームまたはクラウド上で実行できます。Kafka Connect は、Kafka とメインフレームアプリケーションとのデータストリーミングのためのコネクター構築とデプロイのフレームワークを提供することで、統合プロセスを簡素化します。Kafka を使用すると、メインフレームと AWS の間で追加の統合作業を行うことなく、関連するトピックに追加のコンシューマーがサブスクライブできます。 パターン 2 – データ間の統合パターン ワークロードが AWS クラウドに移行され、他のワークロードがまだメインフレームにある場合、メインフレームとの間でデータを送信する頻度に応じてさまざまな方法があります。図 5 は、データ転送のニーズと頻度に対応するために構築する必要がある、さまざまな統合パターンを示しています。 図 5 : データ間の統合パターン ニアリアルタイムのデータ転送 ニアリアルタイムのデータ転送とは、あるプラットフォームから別のプラットフォームへ、ニアリアルタイムにデータの更新を複製できるプロセスです。関連するツールは、変更ログに基づいてニアリアルタイムでデータを移行するために、変更データキャプチャ (CDC) を使用します。データ転送の要件は、単方向、両方向、または双方向である可能性があります。 単方向とは、メインフレームのデータソースから AWS のデータソースへ、またはその逆方向のいずれかに、データを複製する必要があることを意味します。両方向とは、データのレプリケーションが両方向で行われる必要があるものの、異なる関連性のないテーブルに対して行われることを意味します。一方、双方向は、レプリケーションが両方向で行われる必要があるが、関連するテーブルに対して行われることを意味します。関連するテーブルへの更新によるデータの競合という追加の課題があるため、双方向レプリケーションは最後の手段とすべきです。メインフレームから AWS にアプリケーションを移行する際、一方のプラットフォームのアプリケーションからの更新を、もう一方ですぐに利用できるようになります。 AWS Mainframe Modernization サービスは、Precisely 社の CDC テクノロジーを採用した AWS Mainframe Modernization Data Replication を使用して、メインフレームと AWS 間のデータレプリケーションを実現します。これにより、Db2、IMS、VSAM などのメインフレームや&nbsp; IBM i データソースから、幅広い AWS クラウドデータベースの宛先へ、およびその逆方向に、異種データをニアリアルタイムで複製することができます。AWS のデータレプリケーションは、レイテンシーの低い CDC テクノロジーを活用しており、ソースデータベースに加えられた変更がニアリアルタイムでターゲットデータベースに伝播されると同時に、データの一貫性、正確性、鮮度、および有効性も確保されます。この機能により、共存シナリオ、分析、新しいチャネルの作成など、さまざまなユースケースが可能になります。 ファイルベースの転送 ほとんどの企業では、メインフレームからデータを移動するためのファイルベースの転送メカニズムが存在します。IBM Sterling Connect:Direct または SFTP のようなメカニズムを使用して、ファイル転送をサポートすることができます。メインフレームとオープンシステム間のファイル転送における課題の1つは、データ形式の違いです。メインフレームの COMP、COMP-3、その他のバイナリフィールドを持たないファイルの場合、SFTP と IBM Sterling Connect:Direct は、そのままデータ転送に使用できます。（EBCDIC を ASCII ベースまたは選択した文字セットに変換）。バイナリフィールドを持つファイルの場合は、特別な変換ソフトウェアが必要です。AWS Mainframe Modernization サービスは、さまざまな共存、拡張、移行のユースケースをサポートするためのファイル転送機能を提供しています。 AWS Mainframe Modernization File Transfer を使用すると、完全に管理されたサービスでデータセットとファイルを転送および変換し、AWS Mainframe Modernization サービスと Amazon S3 へのモダナイズ、移行、拡張のユースケースを加速および簡素化できます。 抽出、転送、ロード (ETL)ベースの転送 ETL ベースの転送は、メインフレームから AWS にデータを移動するためのデータ統合および転送メカニズムです。メインフレームのソース (VSAM、Db2 など) のデータは、変換プロセスの一部として抽出、整理、クレンジングされ、AWS にアップロードされます。ETL プロセスのすべてにおいて、ソースとターゲットへの JDBC 接続が使用されます。この方法は、 AWS Glue のような ETL 専用ツールや IBM data stage、Informatica、Precisely ETL connect&nbsp; などの ISV 製品によってサポートされており、メインフレームのデータソースから AWS のデータソースへ、またはその逆方向にデータを移行することができます。 アーカイブデータ転送 仮想テープライブラリ (VTL) のようなメインフレーム独自のストレージソリューションは、複雑なツールを備えたプラットフォームに貴重なデータが保持しています。これにより、それらのデータ検索タスクのためのメインフレームでのコンピューティングおよびストレージのコストが高くなる可能性があります。アーカイブデータ転送のパターンは、メインフレームテープから Amazon S3 にデータを移動するのに役立ちます。 BMC AMI Cloud は、顧客がメインフレームのテープを Amazon S3 に移動することを可能にします。 パターン 3 – アプリケーションとデータの統合パターン このオプションは、プラットフォーム間でアプリケーションとデータの統合を実装することです (図6) 。アプリケーションとデータの統合とは、AWS またはメインフレーム上で実行されているアプリケーションが、AWSまたはメインフレーム上にリモートでホストされているデータにアクセスすることを意味します。 図 6: アプリケーションとデータの統合パターン 一般的に、ローカルデータへのアクセスを可能にし、リモートデータアクセスに伴う遅延の影響を回避するためには、データ間の統合が望ましいです。データが非常に密接に結合されている場合、データ間の統合パターンを実装することは困難になります。このような場合、アプリケーションとデータの統合の方が適している可能性があります。 アプリケーションとデータの統合パターンの2つのバリエーション データの単一コピーを使用するアプリケーションとデータの統合 デュアル書き込みを活用したアプリケーションとデータの統合 データの単一コピーパターン このパターンのバリエーションでは、AWS またはメインフレームのいずれかに存在する、データの単一の情報源があります。データがローカルにないアプリケーションは、JDBC やゲートウェイなどの技術を使用してリモートアクセスを実行する必要があります。このパターンは、単一のデータコピーを維持することでデータ管理を簡素化しますが、データにアクセスするリモートアプリケーションにレイテンシが発生し、アプリケーション全体のパフォーマンスに影響を与えます。 AWS にアプリケーション、メインフレームにデータベース – このタイプの統合では、クラウド上のアプリケーションがメインフレームデータベースに直接接続されています。Java Connector Architecture (JCA) コネクタを使用したポイントツーポイント統合は、標準化されたインターフェース、パフォーマンスの向上、移植性、スケーラビリティ、クラウド上の Java アプリケーションとメインフレーム上のデータベース間の直接接続を確立することによるトランザクション性とセキュリティのサポートなどの利点を提供します。一方で、JCA や JDBC を使った統合では、統合されるシステム間に密結合をもたらし、その結果、システムの柔軟性が低下しメンテナンスが困難になる傾向があります。JCA コネクタまたは JDBC を使用したポイントツーポイント統合は、本質的に一方向であり、統合はクラウド上のアプリケーションからメインフレームデータベースにのみ流れることを意味します。 メインフレーム上のアプリケーションと AWS 上のデータベース、またはその逆の組み合わせには、様々な統合方法があります。 メインフレーム上のアプリケーションは、Db2 フェデレーテッドサーバーを使用して、AWS 内のデータベースにアクセスすることができ、その逆もまた同様です。これにより、あいまいさを減らすことができ、データのコピーを 1 つだけ保存すればよいため、運用の複雑さを軽減できます。 フェデレーションは、機能ごとにデータベースを分割するスケーリング手法です。メインフレームデータのフェデレーションは、異種データへのリアルタイムアクセスを統一的な方法で提供し、最小限の設定オーバーヘッドで、AWS またはその逆の分散アプリケーションやデータベースでの利用を可能にします。ただし、フェデレーテッドサーバーは、異なるデータストアからのデータ結合に関して、ある程度の複雑さの層を導入するため、クエリのパフォーマンスとアプリケーションのスケーラビリティに影響を与える可能性があります。 仮想化もデータ管理技術のひとつで、アプリケーションはデータのフォーマットや所在に関する技術的な詳細を知らなくても、データにアクセスしたり変更したりすることができます。IBM Data Virtualization Manager for z/OS(IBMz DVM) は、データをコピーまたは移動する必要なく、複数のソースからのデータの単一表現を作成します。このため、AWS 上の分散アプリケーションとデータベースは、メインフレーム上のさまざまなデータストア (IMS、IDMS、または Db2) とファイルシステム (シーケンシャル、VSAM、VSAM CICS、ADABAS、または MQ) にアクセスできます。 仮想化により、アプリケーション開発者からデータ実装を隠蔽し、メインフレーム資産を API として AWS アプリケーションやデータベース上の分散チャネルに安全に公開します。 データ仮想化はデータ連携とは対照的に、データベースの結合や初歩的なデータ処理を使用した単純なデータ処理に限定されています。 デュアル書き込みパターン このパターンのバリエーションでは、データのコピーが 2 つあり、1 つは AWS 上に、もう 1 つはメインフレーム上にあります。レプリケーションメカニズムを使用する代わりに、アプリケーションは両方のロケーションに対して二重の書き込み ( 挿入/更新 ) を実行します。このパターンでは、読み込み操作はローカルで行われ、書き込み操作はローカルとリモートの両方で行われるため、レイテンシの影響を減らすことができます。 書き込み頻度が低く、読み出し頻度が高いアプリケーションに適しています。大きな欠点は、1 つのトランザクション内で 2 つの書き込みを実行し、データの整合性と一貫性を確保するために、アプリケーションレベルで複雑さが生じることである。 このパターンは、ニアリアルタイムの同期を提供するデータ間統合とは異なり、両方の場所でリアルタイムのデータコピーを提供します。 AWS 上のアプリケーションとメインフレーム上のデータベース – このタイプの統合では、AWS 上とメインフレーム上の両方でデータの同期コピーを保持します。 AWS 上のアプリケーションは、AWS データベースとメインフレームデータベースに同時に直接接続されます。 この統合は、AWS 上の Java EE アプリケーション、AWS 上のデータベース、JDBC を介したメインフレームデータベース間の直接接続を確立する JCA (Java Connector Architecture) コネクタを使用して実現されます。 デュアル書き込みの選択は、アーキテクチャにデータの弾力性を追加しますが、アプリケーションにパフォーマンスの問題をもたらす可能性があります。統合の特性と性質は、AWS 上のアプリケーションとメインフレーム上のデータベースによるデータの単一コピーパターンに似ています。 メインフレーム上のアプリケーションとメインフレームと AWS 上のデータベース – メインフレーム上のアプリケーションをメインフレーム上のデータベースと AWS 上のデータベースに直接統合する様々なチャネルは、メインフレームと AWS 上に同期的にコピーされたデータを保存するという唯一の違いで、データの単一コピーパターンに似ています。 まとめ 大規模な顧客がメインフレームアプリケーションを AWS に移行する際、一部の顧客は、ビッグバン移行に伴うリスクを最小限に抑えるために、Strangler Fig パターンを使用した段階的なアプローチを採用します。このアプローチでは、メインフレームと AWS 間の相互運用性が必要です。この記事では、この相互運用性を促進するさまざまな統合パターンについてまとめました。すべての統合シナリオに対して、万能のソリューションはありません。各パターンには、それぞれ長所と短所があります。これらの統合パターンを選択する際は、慎重な検討が必要です。決定のための主な要因には、スループット、パフォーマンス、トランザクションコンテキストの伝播、整合性、および主要データの場所が含まれます。 AWS Mainframe Modernization に関するご相談は、担当営業にご連絡頂くか、もしくは公式サイトの&nbsp; Web フォーム &nbsp;でお問い合わせください。 本記事は、Yann Kindelberger, Chiranjeev Mukherjee, Saikat Chatterjee による “ Integration architectures between mainframe and AWS for coexistence ” を翻訳したものです。翻訳はソリューションアーキテクトの萩野谷聡が担当しました。

本記事は2024年9月16日に公開された Enable cloud operations workflows with generative AI using Agents for Amazon Bedrock and Amazon CloudWatch Logs を翻訳したものです。翻訳はソリューションアーキテクトの濱野谷(@yoshiehm)が担当しました。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要 AI 企業の高性能な基盤モデル（ FM ）を単一の API を通じて提供するフルマネージドサービスです。また、生成 AI アプリケーションを構築するために必要な幅広い機能も提供し、セキュリティ、プライバシー、責任ある AI といった特徴を備えています。 Amazon Bedrock Agents は、複数ステップのタスクを自動的にオーケストレーションすることで、生成 AI アプリケーション開発を加速するのに役立ちます。Amazon Bedrock Agents は、Bedrock の FM を拡張して、旅行の予約や保険金請求の処理から広告キャンペーンの作成や在庫管理まで、複雑なビジネスタスクを実行します。これらはすべてコードを書くことなく実行できます。 Amazon CloudWatch Logs を使用すると、すべてのシステム、アプリケーション、使用している AWS サービスからのログを、高度にスケーラブルな単一のサービスに一元化できます。CloudWatch Logs では、ログデータを使用してアプリケーションとシステムを監視したり、特定のエラーコードやパターンを検索したり、特定のフィールドに基づいてフィルタリングしたり、将来の分析のために安全にアーカイブしたりすることができます。 このブログ記事では、AWS のクラウド運用シナリオにおいて、アプリケーションログファイルで観察されたエラーに基づいて問題を分類し、その後解決するために、Amazon Bedrock Agents と Bedrock の FM を使用した 生成 AI の使用例を紹介します。 我々のソリューションでは、Amazon Bedrock Agents は基盤モデル (FM) の推論機能を使用して、CloudWatch Logs に公開されたアプリケーションログについてのエラー解決を要求するユーザー指示を複数のステップに分解します。開発者/アナリストが提供した自然言語の指示を使用してオーケストレーション計画を作成し、その後、関連する API を呼び出し、 Amazon Bedrock Knowledge Base にアクセスすることで計画を実行します。これには、大規模言語モデル (LLM) によって生成された応答を補強するために、ベクトルデータストア ( Amazon OpenSearch Serverless ) から情報を引き出す処理が含まれます。 また、Amazon Bedrock Agents が自動的に計画を作成し、サポートアナリストが提起した自然言語の質問からリクエストを満たすための実行ステップを推論する思考の連鎖を示すトレースも紹介します。 前提条件 AWS SAM をインストールします。 このソリューションのリポジトリをクローンします。: sudo yum install -y unzip git clone https://github.com/aws-samples/genai-bedrock-serverless.git cd genai-bedrock-serverless/cloudops cloudops フォルダから、ソリューションの SAM テンプレートをデプロイします。： sam build -t template.yaml sam deploy --resolve-s3 --stack-name &lt;anyname&gt; --capabilities CAPABILITY_NAMED_IAM テンプレートは 2 つの Amazon S3 バケットを作成します。 AWS CloudFormation コンソールで、デプロイされた SAM テンプレートの出力セクションに移動して、これら 2 つの S3 バケット（ProductDocsBucket と CloudOpsSupportBucket）の名前を取得し、S3 コンソールで探すことができるようにします。 ソリューションの data フォルダにある ProductErrorCodes.xlsx ファイルを S3 コンソールの ProductDocsBucket バケットにアップロードします。 ソリューションの data フォルダにある cloudopsupport.json と applogs.csv ファイルを S3 コンソールの CloudOpsSupportBucket バケットにアップロードします。 Amazon Bedrock knowledge base を作成します。 この手順に従ってナレッジベースを作成します。 ステップ 7 で Amazon OpenSearch Serverless ベクトル検索コレクションをナレッジベースとして作成する 新しいベクトルストアをクイック作成 オプションを含むすべてのデフォルトを受け入れます。ソリューションのユースケースに特有の以下の領域を設定します。： ステップ 4a で、ナレッジベースのオプションの説明を提供します。例えば「エラーの説明に基づいてエラー解決方法を提供する」など。 ステップ 5c で、ナレッジベースのデータソースのS3 URI を提供する必要がある場合、ProductDocsBucket の S3 URI を選択します。 ソリューション概要 このソリューションは、 Amazon EC2 インスタンスまたは AWS 外部（オンプレミスまたはハイブリッドクラウド）のインスタンスで実行されているカスタムアプリケーションから始まります。インスタンスにインストールされた Amazon CloudWatch Agent がアプリケーションのログファイルを Amazon CloudWatch Logs にストリーミングします。Windows または Linux システムに統合 CloudWatch Logs エージェントをインストールする詳細なドキュメントは こちら です。また、 こちら の方法でAWS Systems Manager を使用して EC2 またはハイブリッドインスタンスに CloudWatch エージェントをインストールおよび更新することもできます。CloudWatch Logs にアプリケーションログをストリーミングしたら、 こちら に記載されている手順に従ってログファイルを Amazon S3 にエクスポートできます。このソリューションでは、カスタムアプリケーションの CloudWatch セットアップが完了していることを前提としており、前提条件セクションで S3 にアップロードしたサンプルアプリケーションログファイル（.csv 形式）を提供しています。 このシナリオでは、サポートアナリストはアプリケーションが提供する HTTP エラーコードとエラーのタイムスタンプに基づいてエラーを解決しようとしています。Amazon Bedrock Agents がユーザーリクエストを満たすために、エージェントを次の２つで構成します。エージェントは、エージェントへの指示と、エージェントに提供された API スキーマとナレッジベースに基づいてプロンプトを作成し、適切なタスクのシーケンスを決定します。 （１） アクショングループ – アクションの API スキーマを定義し、エージェントが実行できるアクションを実装する AWS Lambda 関数と紐づく （２）ナレッジベース – 基本的に AWS 管理のベクトルデータベース（この場合は Amazon OpenSearch Serverless）であり、エージェントが顧客のクエリに答え、生成された応答を改善するためにクエリできる情報のリポジトリを提供する 図 1 に示すハイレベルアーキテクチャ図は、ソリューションのさまざまなコンポーネントが連携して動作する様子を示しています。CloudWatch Logs ファイルが Amazon S3 にエクスポートされ、エージェントには API スキーマとスキーマのメソッドを実装する Lambda 関数が提供されます。また、エージェントはアーキテクチャ図に示すように ナレッジベースに関連付けられ、図 2 に示すフローを実行します。 図 1:エンドツーエンドのフローを示すソリューションアーキテクチャ 図 2: エンドツーエンドのフローを説明したフローチャート セットアップ Amazon Bedrock Agents を作成します。Amazon Bedrock Agents コンソールから こちら の手順に従って エージェントを作成してください。以下の、ソリューションの構成に特有の部分を除いて、すべてデフォルトのままで構いません。 エージェントを設定するには のセクションで以下を実施します。: ステップ 2c で モデルを選択 する際、Anthropic Claude 3 以降のモデルを選択します。ステップ 2d の エージェント向けの指示 では、以下の図のように次の指示を提供します: “あなたは、HTTPエラーコードとエラーのタイムスタンプに基づいて、エラー解決と影響を受けるアプリケーションコンポーネント情報を提供するエージェントです” 図 3: エージェントの作成 ステップ 2g の IAM 権限 の エージェント リソースロール のセクションで、 既存のサービスロールを使用 を選択し、ソリューションの SAM テンプレートによってプロビジョニングされたIAM サービスロールの ‘AmazonBedrockExecutionRoleForAgents_CloudOps’ を選択します。 ステップ 3 でエージェントにアクショングループを追加するには、 こちら の手順に従ってコンソールからアクショングループを追加します。” Provide error description for this error based on HTTP error code and timestamp of the error（HTTP エラーコードとエラーのタイムスタンプに基づいてこのエラーのエラー説明を提供する）” のような任意の説明をアクショングループに提供します。（図 4 参照） ステップ 6 の アクショングループタイプ セクションで、 Define with API schemas を選択します。（図 4 参照） 図 4: アクショングループの作成 ステップ 7 の Action group invocation セクションで、既存の Lambda 関数を選択し、既にプロビジョニングされている &lt;stackname&gt;-CloudOpsSupportLambda というプレフィックスの Lambda 関数を選択します（図 5 参照） 図 5: アクショングループに Lambda 関数を関連付ける ステップ 8 の Action group schema セクションで、 Select an existing API schema を選択し、 S3 を参照 ボタンを選択して、アカウントにプロビジョニングされた CloudOpsSupportBucket S3 バケットから cloudsopssupport.json ファイルを選択します（図 6 参照） 図 6: API スキーマをアクショングループに関連付ける ステップ 4 のナレッジベースセクションで 追加 を選択して、前提条件セクションで作成したナレッジグループをエージェントに関連付けます。”このエラーのエラー説明に基づいて、エラー解決と影響を受けるアプリケーションコンポーネントを提供してください” のようなナレッジベース指示をエージェントに提供します。（図 7 参照） 図 7: エージェントへのナレッジベースの追加 テストと検証 Amazon Bedrock コンソールは、エージェントをテストするための UI を提供します。 こちら の手順に従ってエージェントをテストし、デプロイの準備をしてください。 こちら の手順に従って、以下に示すようにエージェントのエイリアスを作成し、そのエイリアスに関連付けられたエージェントバージョンを作成してエージェントをデプロイします: 図 8: エージェントのエイリアスとバージョンを作成する これでエージェントのテストの準備が整いました。Amazon Bedrock Agents UI でサンプルプロンプトを提供します。サポートアナリストとして、アプリケーションが提供する HTTP エラーコードとエラーのタイムスタンプに基づいてエラーを解決しようとしています。ソリューションで提供したサンプルアプリケーションログファイルのサンプルエラーコードと関連するタイムスタンプに基づいて、”HTTP エラーコード 500、タイムスタンプ 202404219:00 のエラー解決方法を提供してください。応答は日本語で表示してください。” のような単純なプロンプトを使用できます。エージェントがエラーを解決するための情報を取得した詳細なエラー解決策を提供します。（図 9 参照） 図 9: プロンプトを提供し、エージェントから最終的な応答を取得する 各応答の トレースを表示 を選択すると、ダイアログボックスにエージェントが使用した推論手法と FM が生成した最終的な応答が表示されます。 図 10: エージェントからの思考の連鎖と推論を表示する クリーンアップ このポストで説明したソリューションを試した後、継続的な料金を避け、アカウントをクリーンアップするには、次の手順を実行してください: agentsforbedrock-cloudops フォルダから、ソリューションの SAM テンプレートを削除します: sam delete --stack-name &lt;yourstackname&gt; --capabilities CAPABILITY_NAMED_IAM Amazon Bedrock Agents を削除します。Amazon Bedrock コンソールから、このソリューションで作成したエージェントを選択し、削除を選択して、 エージェントを削除する手順 に従います。 Amazon Bedrock knowledge base を削除します。Amazon Bedrock コンソールから、このソリューションで作成したナレッジベースを選択し、削除を選択して ナレッジベースを削除する手順 に従います。 結論 このブログ投稿では、AWS のクラウド運用シナリオにおいて、Amazon Bedrock Agents と Bedrock の FM、および Amazon CloudWatch Logs を使用した 生成 AI の使用を実証しました。このソリューションをカスタマイズおよび拡張して、複数のログソースを持つアプリケーションログファイルで観察されたエラーに基づいて問題をトリアージし、その後解決するシナリオに適応させることができます。アクショングループの Lambda に追加のロジックを組み込んだり、ナレッジベースに関連情報リポジトリを追加したりすることも可能です。 著者について Kanishk Mahajan は AWS のプリンシパル ソリューションアーキテクトです。AWS の ISV 顧客とパートナーのクラウド変革とソリューションアーキテクチャをリードしています。Kanishk はコンテナ、クラウド運用、移行とモダナイゼーション、AI/ML、レジリエンス、セキュリティとコンプライアンスを専門としています。彼は AWS でこれらの各ドメインの Technical Field Community (TFC) メンバーです。 Praveen Gudipudi は、テクノロジーと機械学習に強い情熱を持つ Amazon Web Services (AWS) のテクニカルアカウントマネージャーです。複雑な課題を解決し、AWS 顧客のクラウド運用をシームレスに行うことに長けています。仕事以外では、Praveen は本を読むことを楽しみ、熱心な旅行者として常に新しい目的地を探索することを楽しんでいます。

Amazon S3 Express One Zone は、高性能のシングルアベイラビリティーゾーン (AZ) S3 ストレージ クラスで、 AWS Key Management Service (KMS) キー (SSE-KMS) によるサーバー側の暗号化をサポートするようになりました。 S3 Express One Zone では、 S3 ディレクトリバケット に保存されているすべてのオブジェクトが Amazon S3 マネージドキー (SSE-S3) を使用してデフォルトで既に暗号化されています。9 月 17 日より、 AWS KMS のカスタマーマネージドキー を使用して、パフォーマンスに影響を与えずに保管中のデータを暗号化できます。この新しい暗号化機能により、S3 Express One Zone を使用する際に、コンプライアンスおよび規制要件を満たすための追加のオプションがもたらされます。S3 Express One Zone は、最も頻繁にアクセスされるデータやレイテンシーの影響を受けやすいアプリケーションに、1 桁ミリ秒単位のデータアクセスを一貫して提供するように設計されています。 S3 ディレクトリバケットでは、SSE-KMS 暗号化用にバケットごとに 1 つのカスタマーマネージドキーのみを指定できます。カスタマーマネージドキーを追加すると、それを編集して新しいキーを使用することはできません。一方、S3 汎用バケットでは、バケットのデフォルトの暗号化設定を変更することで、または S3 PUT リクエスト中に複数の KMS キーを使用できます。SSE-KMS を S3 Express One Zone で使用する場合、 S3 バケットキー は常に有効になっています。S3 バケットキーは無料で、AWS KMS へのリクエスト数を最大 99% 削減し、パフォーマンスとコストの両方を最適化します。 SSE-KMS と Amazon S3 Express One Zone の併用 この新機能の実際の動作を説明するために、最初にその手順に従って Amazon S3 コンソール で S3 ディレクトリバケットを作成 し、 アベイラビリティーゾーン として apne1-az4 を使用します。 ベース名 に「 s3express-kms 」と入力すると、アベイラビリティーゾーン ID を含むサフィックスが自動的に追加され、最終的な名前が作成されます。次に、 [Data is stored in a single Availability Zone] (データは単一のアベイラビリティーゾーンに保存されます) のチェックボックスをオンにして同意してから、 [Create bucket] (バケットを作成) をクリックします。 次に、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、作成したバケットに暗号化を設定する手順を説明します。 SSE-KMS を AWS CLI 経由で S3 Express One Zone で使用するには、以下の ポリシー に基づく AWS Identity and Access Management (IAM) ユーザー または ロール が必要です。このポリシーでは、暗号化されたファイルを S3 ディレクトリバケットに正常にアップロードおよびダウンロードするために必要な CreateSession API 操作を行えます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3express:CreateSession" ], "Resource": [ "arn:aws:s3express:*:&lt;account&gt;:bucket/s3express-kms--apne1-az4--x-s3" ] }, { "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "arn:aws:kms:*:&lt;account&gt;:key/&lt;keyId&gt;" ] } ] } PutBucketEncryption API を使用して、 デフォルトのバケット暗号化 を SSE-KMS に設定します。&nbsp;以下は AWS CLI の例です。 aws s3api put-bucket-encryption \ --bucket s3express-kms--apne1-az4--x-s3 \ --server-side-encryption-configuration \ '{"Rules": [{"ApplyServerSideEncryptionByDefault":\ {"SSEAlgorithm": "aws:kms", \ "KMSMasterKeyID": "1234abcd-12ab-34cd-56ef-1234567890ab"\ },\ "BucketKeyEnabled":true}]}' この S3 ディレクトリバケットにアップロードした新しいオブジェクトは、AWS KMS キーを使用して自動的に暗号化されます。 PutObject コマンドを使用して、 confidential-doc.txt という名前の新しいファイルを S3 ディレクトリバケットにアップロードします。 aws s3api put-object --bucket s3express-kms--apne1-az4--x-s3 \ --key confidential-doc.txt \ --body confidential-doc.txt 前のコマンドが成功すると、次の出力が表示されます。 { "ETag": "\"664469eeb92c4218bbdcf92ca559d03b\"", "ChecksumCRC32": "0duteA==", "ServerSideEncryption": "aws:kms", "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:&lt;accountId&gt;:key/&lt;keyId&gt;", "BucketKeyEnabled": true } HeadObject コマンドでオブジェクトのプロパティを確認すると、以前に作成したキーで SSE-KMS を使用して暗号化されていることがわかります。 aws s3api head-object --bucket s3express-kms--apne1-az4--x-s3 \ --key confidential-doc.txt すると、以下の出力が得られます。 &nbsp; { "AcceptRanges": "bytes", "LastModified": "2024-08-21T15:29:22+00:00", "ContentLength": 5, "ETag": "\"664469eeb92c4218bbdcf92ca559d03b\"", "ContentType": "binary/octet-stream", "ServerSideEncryption": "aws:kms", "Metadata": {}, "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:&lt;accountId&gt;:key/&lt;keyId&gt;", "BucketKeyEnabled": true, "StorageClass": "EXPRESS_ONEZONE" } I download the encrypted object with GetObject : aws s3api get-object --bucket s3express-kms--apne1-az4--x-s3 \ --key confidential-doc.txt output-confidential-doc.txt 私のセッションには必要なアクセス許可があるため、オブジェクトは自動的にダウンロードされ、復号化されます。 { "AcceptRanges": "bytes", "LastModified": "2024-08-21T15:29:22+00:00", "ContentLength": 5, "ETag": "\"664469eeb92c4218bbdcf92ca559d03b\"", "ContentType": "binary/octet-stream", "ServerSideEncryption": "aws:kms", "Metadata": {}, "SSEKMSKeyId": "arn:aws:kms:ap-northeast-1:&lt;accountId&gt;:key/&lt;keyId&gt;", "BucketKeyEnabled": true, "StorageClass": "EXPRESS_ONEZONE" } この 2 番目のテストでは、オブジェクトをダウンロードするために必要な KMS キーアクセス許可が付与されていないポリシーを持つ別の IAM ユーザーを使用します。この試みは AccessDenied エラーが発生して失敗します。これは、SSE-KMS 暗号化が意図したとおりに機能していることを示します。 CreateSession オペレーションの呼び出し中にエラーが発生しました (AccessDenied): アクセスが拒否されました このデモンストレーションでは、SSE-KMS がどのように S3 Express One Zone とシームレスに連携し、権限のあるユーザーの使いやすさを維持しながらセキュリティをさらに強化するかを示します。 知っておくべきこと はじめに – AWS CLI または AWS SDK を使用して S3 Express One Zone の SSE-KMS を有効にできます。S3 ディレクトリバケットのデフォルトの暗号化設定を SSE-KMS に設定し、AWS KMS キーを指定します。存続期間中、S3 ディレクトリバケットごとに 1 つのカスタマーマネージドキーしか使用できないことに注意してください。 リージョン – カスタマーマネージドキーを使用した SSE-KMS の S3 Express One Zone サポートは、 S3 Express One Zone が現在利用可能なすべての AWS リージョン で利用できます。 パフォーマンス – S3 Express One Zone で SSE-KMS を使用しても、リクエストのレイテンシーには影響しません。これまでと同じ 1 桁のミリ秒単位のデータアクセスが引き続き行えます。 料金 – 暗号化と復号化に使用されるデータキーを生成および取得するには、AWS KMS の料金をお支払いいただきます。詳細については、 AWS KMS の料金ページ をご覧ください。さらに、SSE-KMS と S3 Express One Zone を併用する場合、 CopyObject と UploadPartCopy を除くすべてのデータプレーンオペレーションで S3 バケットキーがデフォルトで有効になり、無効にすることはできません。これにより、AWS KMS へのリクエスト数が最大 99% 削減され、パフォーマンスとコストの両方が最適化されます。 AWS CloudTrail 統合 – AWS CloudTrail を使用して S3 Express One Zone オブジェクトの SSE-KMS アクションを監査できます。これについては、 以前のブログ投稿 で詳しく説明しています。 – Eli. 2024 年 9 月 19 日に更新 – CLI の例を更新して、コンソールではなく既存のバケットのデフォルト暗号化を設定しました。 原文は こちら です。

本稿は 2024 年 7 月 2 日に公開された “ Enhance data security with fine-grained access controls in Amazon DataZone ” を翻訳したものです。 アクセス制御を細かな粒度で行うというのは、現代のデータレイクやデータウェアハウスに求められるデータセキュリティの重要な要素となっています。組織が複数のデータソースにまたがる膨大な量のデータを扱う中で、機密情報を管理する必要性が高まっています。データプライバシー、コンプライアンス、そしてセキュリティを維持する上では、適切な人に適切なデータへのアクセス権を与えつつ、機密情報を不正アクセスから守ることが重要になります。 本日、 Amazon DataZone は細かな粒度のアクセス制御機能を導入しました。Amazon DataZone のビジネスデータカタログで管理されているデータレイクやデータウェアハウス上のデータアセットに対して、細かな粒度のアクセス制御が可能になります。この新機能により、データ所有者はデータアセットの単位でアクセス権を付与するのではなく、行や列の単位でアクセスを制限できるようになります。例えば、データに個人を特定できる情報 (PII) などの機密情報が含まれる列がある場合、必要な列へのアクセスだけを許可することで、機密情報を保護しつつ、機密性の低いデータへのアクセスが可能になります。同様に、行単位でのアクセス制御も可能です。ユーザーの役割やタスクに関連する行のみが表示されるようになります。 この記事では、Amazon DataZone の新機能を使用し、行と列のアセットフィルターによって、細かな粒度のアクセス制御を実現する方法について説明します。 行フィルターと列フィルター 行フィルターを使用すると、定義した条件に基づいて特定の行へのアクセスを制限できます。例えば、テーブルにアメリカとヨーロッパのデータが含まれる場合に、ヨーロッパの従業員がその地域に関連するデータにのみアクセスできるようにするには、地域がヨーロッパ以外の行を除外する行フィルター (例: region != 'Europe' ) を作成できます。同様に、アメリカの従業員がヨーロッパのデータにアクセスできないようにすることも可能です。 列フィルターを使用すると、データアセット内の特定の列へのアクセスを制限できます。例えば、テーブルに個人を特定できる情報 (PII) などの機密情報が含まれている場合、列フィルターを作成して PII に該当する列を除外できます。これにより、データアセットをサブスクライブしたユーザーは、機密情報以外のデータにしかアクセスできなくなります。 Amazon DataZone の行フィルターや列フィルターを使用すると、AWS のデータレイクとデータウェアハウス全体のデータに対して、ビジネスユーザーにとって使いやすいメカニズムを使用しながら、誰がどのデータにアクセスできるかを制御できるようになります。Amazon DataZone で細かな粒度のアクセス制御を使用するには、Amazon DataZone のビジネスデータカタログ上のデータアセットに対して、行フィルターや列フィルターを作成します。ユーザーがデータアセットの利用を希望すると、適切な行フィルターや列フィルターを適用した上でアクセスを許可できます。Amazon DataZone は、 AWS Lake Formation と Amazon Redshift を使用してこれらのフィルターを実現し、利用者が許可された行と列にのみアクセスできるようにします。 ソリューションの概要 この新機能を説明するにあたって、電子機器の e コマースプラットフォームを例として用います。このプラットフォームで、Amazon DataZone を使用して細かな粒度のアクセス制御を実装しようとしているサンプルのユースケースを検討します。この企業は複数のカテゴリの製品を取り扱っており、それぞれこの企業の各担当部門が管理しています。プラットフォーム管理チームは、各部門が自身のカテゴリに属するデータのみを参照できるようにしたいと考えています。加えて、価格関連のデータを参照できるのは財務チームのみに制限するという財務チームの要件に従う必要があります。 営業チームは、データプロデューサーとして AWS Glue の Product Sales (製品販売) テーブルを Amazon DataZone のビジネスデータカタログにパブリッシュ (公開) しました。このテーブルは Product-Sales プロジェクトに属しており、 Laptops (ラップトップ) と Servers (サーバー) の両方のカテゴリのデータが含まれています。ラップトップ部門とサーバー部門の両方の分析チームは、それぞれの分析プロジェクトのためにこのデータへのアクセス権が必要です。データ所有者の目標は、データコンシューマーに対して所属する部門に応じたデータアクセスを許可することです。つまり、ラップトップ部門の販売分析チームにはラップトップの販売データの行に対してのみ、そしてサーバー部門の販売分析チームにはサーバーの販売データの行に対してのみアクセスを許可することです。さらに、データ所有者は両チームが価格関連のデータにアクセスできないようにしたいと考えています。この記事では、Amazon DataZone でこのユースケースを実現するための手順を示します。 この解決策を構成する手順は次のとおりです。 データを公開するパブリッシャーは、アクセスを制限するためのアセットフィルターを作成します: ラップトップの販売データの行のみにアクセスを制限する Laptops only 行フィルターと、サーバーの販売データの行のみにアクセスを制限する Servers only 行フィルターの 2 つの行フィルターを作成します。 また、 Product Sales から価格関連の列を除外する exclude-price-columns という列フィルターも作成します。 データを利用するコンシューマーは、データアセットを検出した後、サブスクリプションをリクエストします: ラップトップ部門の販売分析チームのアナリストが Product Sales データアセットのサブスクリプションをリクエストします。 サーバー部門の販売分析チームのアナリストも Product Sales データアセットのサブスクリプションをリクエストします。 承認をもらうために、両方のサブスクリプションリクエストがパブリッシャーに送られます。 パブリッシャーは、サブスクリプションを承認し、適切なフィルターを適用します: パブリッシャーはラップトップ部門のアナリストからのリクエストを承認し、 Laptops only 行フィルターと exclude-price-columns 列フィルターを適用します。 パブリッシャーはサーバー部門のコンシューマーからのリクエストを承認し、 Servers only 行フィルターと exclude-price-columns 列フィルターを適用します。 コンシューマーは、 Amazon Athena を使用して承認されたデータにアクセスします: サブスクリプションが承認された後、Amazon Athena でデータを参照し、ラップトップ部門のアナリストが Laptop の製品販売データのみにアクセスできます。 同様に、サーバー部門のアナリストは Server の製品販売データのみにアクセスできます。 両方のコンシューマーは、適用された列フィルターに従って、価格関連の列を除くすべての列を参照できます。 次の図は、ソリューションのアーキテクチャとプロセスフローを示しています。 前提条件 この記事に沿って進めるには、 Product Sales データアセットのパブリッシャーが、 Amazon DataZone でこのデータセットを公開している必要があります。 パブリッシャーによるアクセス制限用のアセットフィルターの作成 このセクションでは、パブリッシャーがアセットフィルターを作成するための手順を詳しく説明します。 行フィルターの作成 このデータセットには Laptops と Servers の製品カテゴリのデータが含まれています。したがって、製品カテゴリに応じてデータセットへのアクセスを制限することが必要です。この目的を達成するために、Amazon DataZone の行フィルター機能を使用します。 Amazon DataZone では、サブスクリプションを承認する際に適用できる行フィルターを作成できます。これにより、サブスクライバーがアクセスできるデータの行が、行フィルターで定義された範囲に制限されます。行フィルターを作成するには以下の手順を実行します。 Amazon DataZone コンソールで、 product-sales プロジェクト (アセットが所属するプロジェクト) に移動します。 プロジェクトの Data タブに移動します。 ナビゲーションペインで Inventory data を選択し、次に行フィルターを作成する Product Sales アセットを選択します。 AWS Glue テーブルまたは Amazon Redshift テーブルのタイプのアセットに対して行フィルターを追加できます。 アセットの詳細ページで、 Asset filters タブを選択し、 Add asset filter &nbsp;を選んでください。 Laptops カテゴリと Servers カテゴリの 2 つのカテゴリに対して、それぞれの行フィルターを作成します。 ラップトップのみのアセット行フィルターを作成するには、次の手順を完了してください。 このフィルターの名前を入力します ( Laptops only )。 このフィルターの説明を入力します ( Laptops only )。 フィルターの種類として Row filter を選択します。 行フィルター式として、1 つ以上の式を入力します。 column ドロップダウンメニューから Product Category を選択します。 operator ドロップダウンメニューから演算子 = を選択します。 Value フィールドに Laptops と入力します。 この例では 1 つの条件だけでフィルターを作成していますが、フィルター式に別の条件を追加する必要がある場合は、 Add condition を選択します。 行フィルター式に複数の条件がある場合は、 And または Or を選んで、それらの条件を組み合わせます。 サブスクライバーに対する値の可視性も設定できます。この記事では、デフォルト値 ( No, show values to subscriber ) のままにします。 Create asset filter を選択します。 同様の手順で Servers only という名前の行フィルターを作成します。 Value フィールドには&nbsp; Servers と入力します。 列フィルターの作成 次に、価格関連データを含む列へのアクセスを制限するための列フィルターを作成します。以下の手順を実行してください。 同じアセットに対して column filter タイプの別のアセットフィルターを追加します。 Asset filters タブで、 Add asset filter を選択します。 Name には、フィルターの名前 ( exclude-price-columns ) を入力します。 Description には、フィルターの説明 ( Exclude Price Columns ) を入力します。 フィルターのタイプとして Column を選択し、列フィルターを作成します。これにより、このデータアセットのすべての利用可能なものから適用する列を選択できます。 価格関連の列を除くすべての列を選択します。 Create asset filter を選択します。 コンシューマーによるデータ検出とサブスクリプションリクエスト このセクションでは、ラップトップ部門のアナリストの役割に切り替え、プロジェクト Sales Analytics - Laptop 内で作業します。データコンシューマーとして、データカタログを検索し、 Product Sales data アセットをサブスクライブしてデータを利用します。 プロジェクトにユーザーとしてログインし、 Product Sales データアセットを検索します。 Product Sales データアセットの詳細ページで、 Subscribe を選択します。 Project では、 Sales Analytics – Laptops を選択します。 Reason for request には、サブスクリプションを要求する理由を入力します。 Subscribe を選択して、サブスクリプションリクエストを送信します。 パブリッシャーがサブスクリプションフィルターを承認する サブスクリプションリクエストが送信されると、パブリッシャーはそのリクエストを受け取り、次の手順に従って承認できます。 パブリッシャーとしてプロジェクト Product-Sales を開きます。 Data タブで、左側のナビゲーションペインから Incoming requests を選択します。 リクエストを探し、 View request を選択します。 Pending でフィルタリングすると、まだ対応されていないリクエストのみを表示できます。 リクエストの詳細が表示され、誰が、どのプロジェクトのために、どういう理由でリクエストしたかなどの情報の詳細を確認できます。 リクエストを承認する際には 2 つのオプションがあります。 Full access – このオプションでサブスクリプションを承認すると、サブスクライバーはデータアセット全体にアクセスできるようになります。 Approve with row and column filters – 特定の行と列のみにアクセスを制限するには、このオプションを選択した上で、行と列のフィルターを適用して承認します。この記事では、前に作成した両方のフィルターを使用します。 Choose filter を選び、ドロップダウンメニューから Laptops only と exclude-price-columns &nbsp;を選択します。 Approve を選んでリクエストを承認します。 アクセスが許可され有効になると、サブスクリプションは次のスクリーンショットのように表示されます。 次に、サーバー部門のコンシューマーとしてログインします。 同じ手順を繰り返しますが、今回はサブスクリプションを承認する際に、 Choose filter では Servers only と exclude-price-columns を選択します。その他のステップは同じです。 コンシューマーが Amazon Athena を使用して認可されたデータにアクセスする ここまでの手順で、Amazon DataZone のデータカタログにアセットをパブリッシュし、サブスクライブできました。これを分析するために、ラップトップ担当のコンシューマーとしてログインします。 Amazon DataZone データポータルで、コンシューマープロジェクト Sales Analytics - Laptops を選択します。 Schema タブで、登録済みのアセットを確認できます。 プロジェクト Sales Analytics - Laptops を選択し、 Overview を選択します。 右側のペインで Amazon Athena を開きます。 サブスクライブしたテーブルに対してクエリを実行できるようになりました。 Tables and views の下にあるテーブルを選択し、 Preview を選んでクエリエディターで SELECT ステートメントを確認します。 このクエリを実行すると、 Sales Analytics - Laptops のコンシューマーが参照するデータには、プロダクトカテゴリが Laptops のデータしか含まれていないことが分かります。 Tables and views の中でテーブル product_sales を展開できます。この中に価格関連の列は表示されていません。 次に、サーバー部門のアナリストの視点で見てみましょう。同様の方法でデータセットを分析できます。 product_category では、 Servers のみが確認できます。 まとめ Amazon DataZone では、データアセットに対して細かな粒度のアクセス制御を簡単に設定できます。この機能を使えば、データコンシューマーにデータが提供される前に、行単位と列単位のフィルターを定義し、データプライバシーを強制できます。Amazon DataZone の細かな粒度のアクセス制御機能は、Amazon DataZone をサポートするすべての AWS リージョンで一般提供されています。 この機能を自身のユースケースで試した方は、コメント欄でフィードバックをお知らせください。 著者について Deepmala Agarwal は、AWS のデータ スペシャリスト ソリューションアーキテクトとして働いています。彼女は、お客様が AWS 上でスケーラブルかつ分散型のデータ駆動型ソリューションを構築するのを手助けすることに情熱を注いでいます。 仕事以外では、家族と過ごしたり、散歩をしたり、音楽を聴いたり、映画を観たり、料理をしたりすることが好きです！ Leonardo Gomez は、AWS のプリンシパル アナリティクス スペシャリスト ソリューションアーキテクトです。 10 年以上にわたるデータマネジメントの経験があり、世界中の顧客のビジネスおよび技術的ニーズに対応してきました。 LinkedIn &nbsp;で彼とつながることができます。 Utkarsh Mittal は、Amazon DataZone のシニア テクニカル プロダクトマネージャーを務めています。 顧客のアナリティクスジャーニー全体を簡素化するイノベーティブなプロダクトを作ることに情熱を注いでいます。 仕事を離れれば Utkarsh は音楽を演奏するのが趣味で、最近はドラムを始めたところです。 翻訳はパートナーソリューションアーキテクトの丸山 大輔が担当しました。原文は こちら です。

みなさん、こんにちは! いつものように AWS のニュースが満載の興味深い一週間でした。9 月に開催されたさまざまなイベントは満場で活気に満ちた方々にご参加いただきました。 まず、9 月16 日週に注目のリリースをいくつか取り上げてみましょう。 9 月16 日週の AWS ニュースの発表トップ 3 Amazon RDS for MySQL ゼロ ETL 統合が一般公開され、ワクワクするような新機能が追加されました。 &nbsp; これで、 AWS CloudFormation テンプレートでゼロ ETL 統合を設定できるようになりました。また、最大 5 つの Amazon Redshift ウェアハウスを備えたソースの Amazon RDS for MySQL データベースから複数の統合をセットアップできるようになりました。最後に、どのデータベースとテーブルが自動的にレプリケートされるかを決定するデータフィルターを適用できるようになりました。さらに詳しく知りたい場合は、 このリリースの特徴をレビューし、データフィルタリングを始める方法を紹介しているこちらのブログ記事 をご覧ください。ちなみに、このリリースは今週の別のリリースとの相性が良好です。 Amazon Redshift では、ゼロ ETL 統合を介してレプリケートされたテーブルのソートキーを変更できるようになりました 。 Oracle Database@AWS は、 Amazon Web Services (AWS) と Oracle の戦略的パートナーシップの一環として発表されました。このサービスにより、お客様は AWS 内で Oracle Autonomous Database と Oracle Exadata Database Service に直接アクセスできるようになり、エンタープライズワークロードのクラウド移行が簡単になります。主な機能には、リアルタイムのデータ分析のための Oracle と AWS サービス間のゼロ ETL 統合、セキュリティの強化、ハイブリッドクラウド環境のパフォーマンスの最適化などがあります。このコラボレーションは、マルチクラウドの柔軟性と効率性に対する高まる需要に対応します。年内にプレビュー版が提供され、2025 年には新しいリージョンへの展開に伴い、より幅広く利用できるようになります。 Amazon OpenSearch Service がバージョン 2.15 をサポートするようになり 、検索パフォーマンス、クエリの最適化、AI を活用したアプリケーション機能が向上しました。主なアップデートには、ベクトル空間クエリの放射状検索、ニューラルスパース検索とハイブリッド検索の最適化、既存のインデックスでベクトル検索とハイブリッド検索を有効にする機能が含まれます。さらに、毒性検出ガードレールや、取り込みパイプラインを強化するための ML 推論プロセッサなどの新機能も導入されています。このガイドを読んで、 Amazon OpenSearch Service ドメインをアップグレード する方法をご確認ください。 とてもシンプルだけどとても良い これらのリリースは本質的にシンプルですが、大きなインパクトがあります。 AWS Resource Access Manager (RAM) が AWS PrivateLink のサポートを開始 – 今回のリリースでは、トラフィックをパブリックインターネットに公開することなく、プライベート接続を使用して AWS アカウント間でリソースを安全に共有できるようになりました。この統合により、VPC エンドポイントを介した共有サービスへのより安全で効率的なアクセスが可能になり、ネットワークセキュリティが向上し、組織間でのリソース共有が簡素化されます。 AWS Network Firewall が AWS PrivateLink のサポートを開始 – セキュリティを素早く向上させられ、トラフィックをパブリックインターネットに公開することなく、ネットワークファイアウォールのリソースに安全にアクセスして管理できるようになりました。 AWS IAM アイデンティティセンターでは、ユーザーがエクスペリエンスをカスタマイズできるようになりました – 読みやすさを向上させ、目の疲れを軽減するダークモードなど、言語やビジュアルモードのプリファレンスを設定できます。今回の更新では 12 種類の言語がサポートされ、ユーザーはポータルから AWS リソースにアクセスする際に、よりパーソナライズされたエクスペリエンスが得られるように設定を調整できます。 その他 Amazon EventBridge Pipes がカスタマーマネージドの KMS キーのサポートを開始 – Amazon EventBridge Pipes では、サーバー側の暗号化用にカスタマーマネージドキーがサポートされるようになりました。今回の更新により、お客様は独自の AWS Key Management Service (KMS) キーを使用してソースとターゲット間の転送時にデータを暗号化できるようになり、機密イベントデータの制御とセキュリティが強化されます。この機能により、カスタム統合コードを必要とせずにポイントツーポイント統合のセキュリティが強化されます。 これを設定する方法については 、更新されたドキュメントを参照してください。 AWS Glue データカタログは、Apache Iceberg テーブルの拡張ストレージ最適化をサポートするようになりました – これには、不要なデータファイルの自動削除、孤立ファイル管理、スナップショットの保持が含まれます。これらの最適化により、テーブルを継続的に監視および圧縮することで、ストレージコストの削減とクエリのパフォーマンスの向上に役立ち、Amazon S3 に保存されている大規模なデータセットの管理が容易になります。 この新機能の詳細については 、このビッグデータブログ記事をご覧ください。 Amazon MSK Replicator では、同一のトピック名を維持したまま、クラスター間の Kafka トピックのレプリケーションがサポートされるように – これにより、クラスター間のレプリケーションプロセスが簡略化され、ユーザーはクライアントアプリケーションを再設定しなくてもリージョン間でデータをレプリケートできます。これにより、セットアップの複雑さが軽減され、マルチクラスターストリーミングアーキテクチャにおけるよりシームレスなフェイルオーバーが可能になります。。詳細については、この Amazon MSK Replicator デベロッパーガイド を参照してください。 Amazon SageMaker、推論用のスティッキーセッションルーティングを導入 – これにより、セッションの間、同じクライアントからのリクエストを同じモデルインスタンスに送信できるため、特にセッションベースのやり取りが重要なチャットボットやレコメンデーションシステムなどのリアルタイム推論シナリオで、一貫性が向上し、レイテンシーが削減されます。 設定方法については 、このドキュメントガイドをご覧ください。 イベント AWS GenAI Lofts は世界中で次々と登場しています。 今週、サンフランシスコのデベロッパーは、 サンフランシスコの AWS Gen AI Loft で開催された 2 つの非常にエキサイティングなイベントに参加する機会を得ました。その中には、先週の火曜日の「Generative AI on AWS」ミートアップがあり、拡張現実、将来の AI ツールなどについての議論が行われました。その後、木曜日には Amazon Bedrock で駆動する MineCraft ボットのデモンストレーションと AI ビデオゲームのバトルで盛り上がりました。 10 月 19 日より前にサンフランシスコ周辺にいる場合は、 スケジュールをチェックして 、参加できるイベントのリストに目を通しましょう。 最近オープンした ブラジルのサンパウロ AWS GenAI Loft と、 9 月 30 日にオープンするロンドンの AWS GenAI Loft をぜひチェックしてください。イベントの席がなくなる前に登録を始めることができます。例えば、「 The future of development 」と呼ばれるイベントでは、デベロッパーがスキルを向上させることにターゲットを絞った内容を 1 日中学ぶことができます。 AWS コミュニティも、素晴らしいイベントの開催に大忙しです。 AWS Community Day ベルファストで講演者になれたことを光栄に思います。そこで、北アイルランドで盛り上がっているこの素晴らしいコミュニティの主催者の皆様にようやく会うことができました。Community Day に行ったことがない方は、ぜひチェックしてみることをおすすめします。 周りの笑顔は言うまでもなく、Matt Coulter、Kristi Perreault、Matthew Wilson、Chloe McAteer などのコミュニティリーダーとそのコミュニティメンバーからの献身と情熱に元気づけられるはずです。 認定資格 AWS 認定試験の受験を延期しているなら、今が絶好の機会です。 2024 年 12 月 12 日までに AWS 認定: Associate Challenge に無料で登録すると、AWS 認定ソリューションアーキテクト – アソシエイト、AWS 認定デベロッパー – アソシエイト、AWS 認定システムオペレーションアドミニストレーター – アソシエイト、または AWS 認定データエンジニア – アソシエイトのいずれかの試験を受験できる 50% 割引バウチャーを獲得できます。同僚の Jenna Seybold が、 各試験の学習教材のコレクションを投稿しています。 興味があればチェックしてみてください。 また、新しい AWS 認定 AI プラクティショナー試験 が受験できるようになりました。ベータ段階ですが、すでに受験できます。2025 年 2 月 15 日までに合格すると、 アーリーアダプターバッジ がもらえ、コレクションに追加できます。 まとめ 今週のニュースを楽しんでいただけたら幸いです。 これからもがんばってください! 原文は こちら です。