この記事は Preventing log loss with non-blocking mode in the AWSLogs container log driver (記事公開日: 2023 年 8 月 3 日) を翻訳したものです。 Introduction 可観測性の向上とトラブルシューティングのために、コンテナログをコンピューティングプラットフォームから、ログ集約サーバーに転送することをお勧めします。実際には、ログサーバーが到達不能になったり、ログを受け入れられなくなる場合があります。ログサーバーの障害に対するアーキテクチャ設計には、トレードオフがあります。サービス所有者は、次の点を検討する必要があります。 アプリケーションは、トラフィックへの応答 (または作業の実行) を停止し、ログ集約サーバーが復旧するのを待つべきでしょうか? (正確な監査ログがサービスの可用性よりも優先されますか?) アプリケーションは、ログサーバーがバッファを使い切る前に復旧することを期待してログをバッファリングしながらトラフィックに対応し続けるべきでしょうか? ログ送信先が利用できないレアケースにおいてログが失われるリスクを受け入れるべきでしょうか? コンテナの ログドライバー では、このトレードオフは上記 1 の考慮事項に対して「ブロッキング」の設定パラメータ、2 の考慮事項に対して「ノンブロッキング」の設定パラメータで実装されています。AWS ブログの「 Choosing container logging options to avoid backpressure 」では、Rob Charlton がこのトレードオフを探求し、 AWSLogs コンテナログドライバーのデフォルトの「ブロッキング」モードでアプリケーションがどのように動作するかをテストする方法を説明しています。 この記事では、「ノンブロッキング」 について詳しく説明し、AWSLogs ログドライバーを使用したログ損失の試験結果を示します。 ソリューションの概要 AWSLogs ドライバーのモード Amazon Elastic Container Service ( Amazon ECS ) では、 AWSLogs ログドライバー がコンテナの stdout と stderr からログをキャプチャし、 Amazon CloudWatch Logs に PutLogEvents API 経由でアップロードします。このログドライバーは、 モード設定 をサポートしており、次のように構成できます。 ブロッキング ( デフォルト) : ログを Amazon CloudWatch に即座に送信できない場合、コンテナコードから stdout または stderr への書き込み呼び出しがブロックされ、コードの実行が停止します。アプリケーションのロギングスレッドがブロックされるため、アプリケーションが機能しなくなり、ヘルスチェックの失敗やタスクの終了につながる可能性があります。必要なロググループまたはログストリームを作成できない場合、コンテナの起動に失敗します。 ノンブロッキング: ログを Amazon CloudWatch に即座に送信できない場合、max-buffer-size 設定で構成されたインメモリバッファに格納されます。バッファを使い切ると、ログが失われます。コンテナコードから stdout または stderr への書き込み呼び出しはブロックされず、即座に実行されます。Amazon ECS on Amazon Elastic Compute Cloud ( Amazon EC2 ) では、必要なロググループまたはログストリームを作成できない場合でも、コンテナの起動は失敗しません。AWS Fargate 上の Amazon ECS では、構成されたモードに関係なく、ロググループまたはログストリームを作成できない場合、コンテナの起動は必ず失敗します。 デフォルトのブロッキングモードから、ノンブロッキングモードへの変更を検討するべきか？ デフォルトのブロッキングモードではアプリケーションの可用性リスクがあるため、サービス所有者はノンブロッキングモードに切り替えることを検討する必要があります。その場合、次のような疑問が生じます。 max-buffer-size はどのように選択すべきでしょうか? デフォルトの 1 MB サイズでログの損失を防げますか? ノンブロッキングモードを使うと、高レートでログを出力するアプリケーションにてログの損失が発生しますか? これらの質問に答えるため、AWS チームはノンブロッキングモードで AWSLogs ドライバー上でスケールしたログの取り込みテストを実行しました。 推奨される max-buffer-size の値はどれですか？ ノンブロッキングモードを選択する場合、このテストから推奨される Amazon ECS タスク定義の設定は以下のとおりです。 "logConfiguration": { "logDriver": "awslogs", "options": { "mode": "non-blocking", "max-buffer-size": "25m", } } バッファのサイズを決定する変数は何ですか？ 最大バッファサイズに影響を与える主な変数は、アプリケーションがデータを出力する頻度とログのスループットです。 CloudWatch Metrics の IncomingBytes メトリクスを使用して、ロググループへの取り込みレートを追跡 します。すべてのコンテナがほぼ同じレートで送信すると想定すると、ロググループの取り込みレートをコンテナの数で割ることで、 個々のコンテナのレート が分かります。 各コンテナからのログのスループットを多めに見積もることをお勧めします。ログ出力は、特にインシデント発生時に一時的に急増する可能性があります。可能であれば、負荷テストや最近のインシデント時のスループットを計算してください。スループットのバーストに対応するため、1 分以下の時間間隔でのピークログ出力レートを使用してください。 テストでわかったことは何ですか？ この記事で説明した結果はパフォーマンスを保証するものではないことにご注意ください。AWS チームが実施したテストの結果を単に共有しているだけです。 ログ集約サーバーが利用可能で正常な場合の主な所見は次のとおりです。 max-buffer-size が 4 MB 以上の場合、コンテナからの出力ログレートが 2 MB/s 以下であれば、ログの損失は発生しません。 max-buffer-size が 25 MB 以上の場合、コンテナからの出力ログレートが 5 MB/s 以下であれば、ログの損失は発生しません。 6 MB/s を超えると、AWSLogs ドライバーのパフォーマンスは予測可能性と一貫性が低くなります。たとえば、100 MB のバッファと 7 MB/s のテストで異常値による失敗が発生しました。6 MB/s 以上 (持続的またはバースト) でログを出力する場合、時折ログ損失を防ぐことができない可能性があります。 Amazon EC2 起動タイプと AWS Fargate 起動タイプの Amazon ECS で、結果は同様です。 このドキュメントでは、テスト結果の簡単な要約を示します。起動タイプとログサイズ別に分けられた完全なベンチマーク結果、分析、データは、 GitHub で確認できます。 テストはどのように実行されましたか？ ベンチマークに使用したコードは GitHub で確認できます。Amazon EC2 のテストは Docker バージョン v20.10.25 で実行しました。AWS Fargate のテストは プラットフォームバージョン 1.4 で実行しました。 各ログ損失テストは、AWSLogs ドライバーを使用して 1 GB のログデータを Amazon CloudWatch Logs に送信する Amazon ECS タスクで実行しました。そのタスクは次に Amazon CloudWatch Logs をクエリして、すべてのログイベントを取得し、受信したログイベントの数をチェックします。各ログメッセージには、予測可能なシーケンス番号である一意の ID が付いています。1 KB と 250 KB のサイズの単一ログメッセージでテストが実行されました。 数千回のテストを実行し、有意な統計分析を行うための十分なデータを取得しました。 バッファを使い切り、ログが失われているかどうかを知ることができますか？ 残念ながら、AWSLogs ログドライバーでは、ノンブロッキングモードのバッファによって失われたログを確認することはできません。Docker デーモンは、ログの損失が発生した際にログステートメントやメトリクスを出力しません。ログ損失メトリクスの提案については、 GitHub にコメントしてください。 バッファサイズはアプリケーションで使用可能なメモリにどのように影響しますか? max-buffer-size 設定は、 Go スライス内のメッセージのバイトサイズ を制御します。ただし、 Go はガベージコレクションされる言語なので、直接メモリ使用量を制約するわけではありません。ある 1 つのテストスイートでは、キューの実際のサイズは平均すると非常に小さく、一般的に 500 KB 未満であることが分かりました。バッファサイズは、レイテンシの期間や、ログのスループットの増加時に一時的に制限値まで上がります。つまり、バッファによって使用されるメモリは瞬間ごとに大きく変動し、Go のガベージコレクションのため、実際のメモリ使用量が設定サイズを超える可能性があります。 コンピューティングプラットフォームはバッファサイズに影響しますか？ テストでは、Amazon EC2 と AWS Fargate の両方で起動した Amazon ECS タスクの結果が同様であることがわかりました。 リージョン間でログを送信する場合、ノンブロッキングモードは安全ですか? AWSLogs ドライバーは、テストタスクと同じリージョンの Amazon CloudWatch API にログを送信する場合、CloudWatch への接続の待ち時間が短いため、はるかに高い速度で一貫してアップロードできます。リージョン間でのログアップロードは信頼性が低くなります。さらに、リージョンの分離というベストプラクティスに反します。リージョン間のログプッシュはネットワークコストも高くなります。 テスト結果 この記事で説明した結果はパフォーマンスを保証するものではありません。私たちは単に実行したテストの結果を共有しているだけです。コンピューティングプラットフォーム (AWS Fargate と Amazon EC2) やログメッセージサイズなどの次元別の完全なデータテーブルについては、 GitHub をご覧ください。 リージョン内テスト実行の概要 以下は、約 17,000 回のリージョン内テスト実行のヒートマップ概要です。シェーディングされたボックス内のパーセント注釈は、最悪のテスト実行でのログ損失のパーセンテージです。赤の濃い色ほど、ログ損失が大きかったことを示しています。ログ出力レートが 2 MB/s 未満のテスト実行では、ログ損失は発生しませんでした。 リージョン間テスト実行の概要 タスクは us-west-2 で実行され、us-east-1 の Amazon CloudWatch にアップロードされました。 結果は、リージョン間のログアップロードは信頼性が低く、ログの損失を防ぐためにはるかに大きなバッファサイズが必要であることを示しています。 まとめ この記事では、以下のことを学びました: コンテナログドライバーのブロッキングとノンブロッキングにおいて、アプリケーションの可用性とログ損失のトレードオフがあります。 max-buffer-size の異なる値でノンブロッキングモードの AWSLogs ドライバーの動作を確認します。 クロスリージョンのログアップロードは推奨されず、ノンブロッキングではログ損失のリスクが高くなります。 コンテナごとのログ出力レートを確認する方法を説明しました。 AWSLogs ドライバーのノンブロッキングモードではログ損失を監視することはできません。 アプリケーションの可用性とログ損失のトレードオフを検討する際、ユースケースがブロッキングモードまたはノンブロッキングモードのどちらを必要とするかを決定する必要があります。トレードオフとしてアプリケーション側の可用性を選択する場合、ノンブロッキングモードの AWSLogs ドライバーまたは他のログ収集ソリューションのどちらを選択しますか？ Fluent Bit と FireLens などの他のほとんどのログ収集ソリューションは、ログのバッファは有限ですがトレードオフとしてアプリケーション側をブロックしません。ただし、ログの損失を防ぐための チューニング や 監視 が容易なソリューションもあります。ノンブロッキングモードの AWSLogs ドライバーを選択する場合、コンテナごとのログ出力レートに応じて、max-buffer-size の値をリスク許容範囲内に設定する必要があります。 GitHub の完全なテスト結果を慎重に確認することをお勧めします。結果に基づき、max-buffer-size には 25m を推奨し、すべてのログアップロードがリージョン内であることを確認してください。リージョン間のログプッシュは非常に信頼性が低いためです。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

新しい Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスを作成すると、そのデータベースインスタンスに対して 特定の権限 がマスターユーザーに付与されます。アプリケーションでマスターユーザーを直接使用しないことを強くお勧めします。代わりに、最小権限の原則とベストプラクティスに従い、アプリケーションに必要な最小限の権限を持つデータベースユーザーを作成してください。 この手法は、次のようなユースケースに適用できます。 アプリケーション固有の SQL Server ログインを使用する代わりにマスターユーザーを使用する セキュリティと説明責任のために、データベース管理者 (DBA) に名前付きアカウントを使用する Amazon RDS for SQL Server に接続するアプリケーションとサービスに対して、最小権限のセキュリティモデルを実装し、特定の名前付きアカウントを使用する この投稿では、マスターユーザーを新しいログインにクローンし、必要最小限の権限を確認する方法について説明します。アプリケーションに必要のない権限を削除することで、最小権限の セキュリティモデルを実装できます。 ソリューション概要 このソリューションでは、マスターユーザーをクローンするために以下の手順を実行します。 ユーザーを複製したい環境で、 usp_rds_clone_login という名前のストアドプロシージャを作成します。これは、 SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server インスタンスに接続することで実現できます。 ストアドプロシージャを実行すると、実行した時点での権限が記述された T-SQL スクリプトが生成されます。 SSMS の結果ペインからスクリプトをコピーし、新しいクエリウィンドウで実行します。 ストアドプロシージャが実行された後、マスターログインと同様のサーバーレベルおよびデータベースレベルの権限を持つ「create login」スクリプトが生成されます。 前提条件 RDS インスタンスでマスターユーザーをクローンする前に、次の準備が整っている必要があります。 Amazon RDS for SQL Server インスタンス データベースへの接続が可能な SSMS 必要な権限を持つユーザー ストアドプロシージャの作成 ユーザーを複製したい環境で、 usp_rds_clone_login ( ダウンロード ) という名前のストアドプロシージャを作成します。次のステップで、特定のログインアカウント、データベースユーザー、サーバーレベルの権限、およびデータベースレベルの権限のクローンを作成するためにこのストアドプロシージャを使用します。Amazon RDS for SQL Server のシステムデータベース以外の任意のユーザーデータベースにストアドプロシージャを作成できます。 プロセスの一部として、スクリプトは次のアクションを実行します。 指定されたパスワードを使用して新しいログインを作成する 新しいログインにサーバーロールのメンバーシップを割り当てる 新しいログインにサーバーレベルの権限を割り当てる LoginToDuplicate に従って、新しいログイン用のデータベースユーザーを作成する LoginToDuplicate に従って、新しいユーザーにデータベースロールメンバーシップを割り当てる LoginToDuplicate に従って、新しいユーザーにデータベースレベルの権限を割り当てる ストアドプロシージャを実行する際、ストアドプロシージャを実行するユーザーにこれらの権限を付与するアクセス権がない場合、スクリプトは結果を生成しません。ユーザーに権限を付与するアクセス権がない場合、出力スクリプトにはその権限が表示されません。これは、スクリプトにアクセスするために使用されるログインに表示権限がないためです。さらに、権限を付与する権限がないのに手動で権限スクリプトを追加しようとするとスクリプトは失敗します。 ストアドプロシージャの実行 ストアドプロシージャを作成した後、新しい T-SQL ウィンドウを開き、次の形式でストアドプロシージャを実行します。スクリプトを実行する前に、キーボードの CTRL + T を押して、結果がテキスト形式になっていることを確認してください。 -- SQL server authentication login EXEC usp_rds_clone_login @NewLogin = [ < duplicate_login_name > ] , @NewLoginPwd = 'Password_for_new_login_here' , @LoginToDuplicate = master_login , @WindowsAuth = 0 ; -- Windows authentication login EXEC usp_rds_clone_login @NewLogin = [ < domain\duplicate_login_name > ] , @NewLoginPwd = NULL , @LoginToDuplicate = master_login , @WindowsAuth = 1 ; SQL 次は、管理者アカウントを新しいドメインユーザーアカウントにクローニングした際の出力例です。 EXEC dbo . usp_rds_clone_login @NewLogin = 'MyDomain\MyDomainUser' , @NewLoginPwd = NULL , @WindowsAuth = 1 , @LoginToDuplicate = 'admin' ; SQL 出力： /*Cloning Process Steps*/ /*==================================================*/ /*1 - Create new login*/ /*2 - Server role membership for new login*/ /*3 - Server level permissions for the new login*/ /*4 - Create database user for new login*/ /*5 - Database role membership for db user*/ /*6 - Database level permissions*/ /*==================================================*/ /*1 - Create new login*/ CREATE LOGIN [ MyDomain\MyDomainUser ] FROM WINDOWS ; /*2 - Server role memberships for new login*/ EXEC sp_addsrvrolemember @loginame = 'MyDomain\MyDomainUser' , @rolename = 'setupadmin' ; EXEC sp_addsrvrolemember @loginame = 'MyDomain\MyDomainUser' , @rolename = 'processadmin' ; /*3 - Server level permissions for the new login*/ USE master ; GRANT ALTER ANY EVENT SESSION TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ADMINISTER BULK OPERATIONS TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY SERVER AUDIT TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY CONNECTION TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY LOGIN TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY LINKED SERVER TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY SERVER ROLE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER SERVER STATE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER TRACE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT CREATE ANY DATABASE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT VIEW ANY DEFINITION TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT VIEW ANY DATABASE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT VIEW SERVER STATE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; GRANT ALTER ANY CREDENTIAL TO [ MyDomain\MyDomainUser ] ; /*4 - Create database user for new login*/ USE [ DBATools ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ master ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ msdb ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ rdsadmin ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ tempdb ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; /*5 - Database role membership for db user*/ USE [ DBATools ] ; EXEC sp_addrolemember @rolename = 'db_owner' , @membername = 'MyDomain\MyDomainUser' ; USE [ msdb ] ; EXEC sp_addrolemember @rolename = 'SQLAgentUserRole' , @membername = 'MyDomain\MyDomainUser' ; /*6 - Database level permissions*/ USE [ DBATools ] ; DENY BACKUP DATABASE ON DATABASE :: [ DBATools ] TO [ MyDomain\MyDomainUser ] ; USE [ DBATools ] ; DENY BACKUP LOG ON DATABASE :: [ DBATools ] TO [ MyDomain\MyDomainUser ] ; USE [ msdb ] ; GRANT ALTER ANY USER ON DATABASE :: [ msdb ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_restore_tde_certificate ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_task_status ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_tlog_copy_setup ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_tlog_backup_copy_to_S3 ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_output ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_task_status ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_shrink_tempdbfile ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_cdc_disable_db ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_cdc_enable_db ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_tuninglog ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_get_audit_file ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_download_from_s3 ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_delete_from_filesystem ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_gather_file_details ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_list_file_details ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_partitionfunction ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_sqlagent_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_msbi_task ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_upload_to_s3 ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_partitionscheme ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_msdtc_transaction_tracing ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_drop_ssrs_databases ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_drop_ssis_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_table ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_failover_time ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_changedbowner_to_rdsa ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_tableview ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_purge_jobhistory ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_query ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_dms_tlog_download ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_dms_tlog_list_current_lsn ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_dms_tlog_read ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_querytable ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_configure_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_querydatabase ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_index ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_status_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_queue_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_queryindex ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_column ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_indexcolumn ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_send_dbmail ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_querycolumn ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_delete_database_backuphistory ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysjobhistory ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysjobs ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysjobactivity ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_add_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_delete_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_update_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_grant_login_to_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_revoke_login_from_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_enum_proxy_for_subsystem ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_sysmail_control ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_enum_login_for_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_sysmail_allitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_sysmail_event_log ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_sysmail_mailattachments ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_sysmail_delete_mailitems_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_allitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_server_object_last_sync_time ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_sentitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_get_system_database_sync_objects ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_unsentitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_set_system_database_sync_objects ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_faileditems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_input ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_mailitems_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_backup_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_backup_tde_certificate ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_mailattachments ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_cancel_task ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_drop_tde_certificate ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_event_log ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_finish_restore ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_log_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_list_tlog_backup_metadata ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_list_user_tde_certificates ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_progress ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_restore_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_restore_log ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT ALTER ON ROLE:: [ SQLAgentUserRole ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT ALTER ON ROLE:: [ SQLAgentOperatorRole ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ tempdb ] ; GRANT CONTROL ON DATABASE :: [ tempdb ] TO [ MyDomain\MyDomainUser ] ; SQL 出力されたスクリプトをコピーして実行 スクリプトが出力を生成した後、SSMS の結果タブから出力されたスクリプトをコピーし、新しいクエリウィンドウから実行します。スクリプトが実行された後、マスターログインと同様のサーバーレベルとデータベースレベルの権限を持つ新しいログインアカウントが作成されます。 この例では、SSISDB データベースの ssis_admin と ssis_logreader の権限は除外されています。これらの権限が必要な場合は、別途指定してください。 ALTER ROLE [ ssis_admin ] ADD MEMBER [ mydomain\user_name ] ; ALTER ROLE [ ssis_logreader ] ADD MEMBER [ mydomain\user_name ] ; SQL クリーンアップ ログインを複製した後、(例えば、コンプライアンスの理由で) ストアドプロシージャを保持したくない場合は、次のスクリプトを使用してドロップできます。 USE [ DB_NAME ] GO DROP PROCEDURE [ dbo ] . [ usp_rds_clone_login ] ; GO SQL 結論 この投稿では、Amazon RDS for SQL Server でマスターユーザーを新しいログインにクローンする方法について説明しました。また、アプリケーションでマスターユーザーを使用しないための主な考慮事項とベストプラクティスについても説明しました。このソリューションは、ビジネスニーズに必要な最小限の権限を持つ新しいログインを作成するのに役立ちます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Alvaro Costa-Neto は AWS のデータベーススペシャリストソリューションアーキテクトで、クラウド上でのデータベースソリューションの設計と実装を支援しています。彼はデータベース技術に興味があり、主に Microsoft SQL Server を使って 19 年以上にわたり活動してきました。彼はフロリダ州クレルモントに妻と 2 人の子供たちと住んでおり、家族と航空と旅行の愛好家です。仕事を離れると、家族や友人とクックアウトを主催したり、新しい場所を探索したりするのが好きです。 Rakesh Ramanukolanu は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。様々な業界のお客様に対し、SQL Server のワークロードを Amazon RDS や Amazon RDS Custom のようなマネージド データベース プラットフォームに設計、移行、最適化するのを支援しています。 Mesgana Gormley は Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。彼女は Amazon RDS チームで働き、お客様に技術的なガイダンスを提供し、リレーショナルデータベースワークロードの移行、設計、展開、最適化を支援しています。

Amazon Relational Database Service (Amazon RDS) for SQL Server が、SQL Server 認証を使用するログインのパスワードポリシーの設定をサポートするようになりました。この機能により、ビジネス要件に合わせてカスタムパスワードポリシーを作成できます。SQL Server のパスワードポリシーは、パスワードの評価とそれらのパスワードを使用するエンティティの維持に関する様々なルールを定義します。これらのポリシーには以下が含まれる可能性があります。 新しいパスワードに対するパスワードの長さと複雑さの要件の強制 パスワードの有効期限と定期的な変更の強制 不正なパスワードが多数回入力された場合のアカウントのロックアウト この投稿では、Amazon RDS for SQL Server のパスワードポリシーを有効にし、そのポリシーに準拠する SQL Server ログインを作成するプロセスについてご案内します。 SQL Server のさまざまな認証の概要 SQL Server ログインは、データベースに対して認証可能なセキュリティプリンシパルを表すサーバーレベルのオブジェクトです。SQL Server インスタンスに接続するには、ユーザーはログインを使用して認証する必要があります。以下の形式でログインを作成します。 SQL Server 認証（ログイン名とパスワード）を使用 Windows 認証（Windows ユーザーまたはドメインアカウント）を使用 証明書から 非対称キーから この投稿では、SQL Server 認証を使用してログインのパスワード ポリシーを構成する方法にフォーカスします。 前提条件 Amazon RDS for SQL Server インスタンス Amazon RDS for SQL Server インスタンスに接続できる SQL Server Management Studio (SSMS) カスタムパラメータグループ パラメータグループの作成または修正 Amazon RDS for SQL Server ではパラメータグループを通じてパスワードポリシーを有効にすることができます。詳細については、「 Amazon RDS のパラメータグループ 」を参照してください。 以下の表は、SQL Server のパスワードポリシーを設定するために構成可能なパラメータを示しています。以下のパラメータはすべて動的であり、RDS データベースインスタンスの再起動を必要とせずに変更を即座に適用できます。 DB パラメーター 説明 許可された値 デフォルト値 rds.password_complexity_enabled SQL Server ログインのパスワードを作成または変更する際は、パスワードの複雑さの要件を満たす必要がある。 0,1 0 rds.password_min_length SQL Server ログインのパスワードに必要な最小文字数。 0-14 0 rds.password_min_age SQL Server ログインパスワードがユーザーによって変更可能になるまで使用しなければならない最小日数。0 に設定すると、パスワードはすぐに変更できる。 0-998 0 rds.password_max_age SQL Server ログインパスワードが使用できる最大日数で、この日数を超えるとユーザーはパスワードの変更を要求されます。0 に設定すると、パスワードは無期限に有効となる。 0-999 42 rds.password_lockout_threshold SQL Server ログインがロックアウトされる原因となる連続したログイン失敗の回数。 0-999 0 rds.password_lockout_duration ロックアウトされた SQL Server ログインが、ロック解除されるまでに待機しなければならない分数。 1-60 10 rds.password_lockout_reset_counter_after ログイン試行が失敗した後、失敗したログイン試行カウンターが 0 にリセットされるまでに経過しなければならない分数。 1-60 10 RDS インスタンスのバージョンとエディションに基づいて、 新しいパラメータグループを作成 するか、既存のパラメータグループを使用することができます。カスタムパラメータグループが必要です。RDS インスタンスがデフォルトのパラメータグループで実行されている場合は、新しいパラメータグループを作成してください。すでに Amazon RDS for SQL Server インスタンスとそれにアタッチされたカスタムパラメータグループがある場合は、そのパラメータグループの名前をメモしてください。その後、以下の手順を実行します。 Amazon RDS コンソールで、RDS for SQL Server インスタンスを見つけます。 設定タブで、DB インスタンスパラメータグループ rds-sql-parametergroup を選択します。 名前にパスワードというテキストを含むパラメータを検索します。 これにより、RDS インスタンスのパスワード設定に関連するすべてのパラメータが読み込まれます。 編集 をクリックしてパラメータ値を変更します。 rds.password_complexity_enabled の値を 0 から 1 に変更します。 保存をクリックします。 注意: Amazon RDS for SQL Server のマルチ AZ 構成では、パスワードポリシーはプライマリインスタンスとスタンバイインスタンスの両方に適用されます。 SQL Server ログインのパスワードの複雑さを構成 rds.password_complexity_enabled パラメータを有効にしたので、RDS インスタンスに接続し、以下の手順を実行して既存のログインの 1 つにパスワード複雑性ポリシーを適用してください。 SSMSを開きます。 ALTER ANY LOGIN 権限を持つログインを使用して、RDS for SQL Server に接続します。 セキュリティ、ログインのフォルダを展開します。 既存のログインの 1 つを選択し、そのプロパティを表示します。 複雑なパスワードを入力して、ログインのパスワードをリセットします。 パスワードポリシーを適用とパスワードの有効期限を適用を選択します。 OK をクリックします。 パスワードロックアウトポリシーの設定 さらに一歩進んで、Amazon RDS for SQL Server インスタンスにロックアウトポリシーを追加しましょう。ロックアウトの動作を制御する 3 つのパラメータがあります（詳細は上記のパラメータ表を参照してください）。 rds.password_lockout_threshold （デフォルト値 = 0） rds.password_lockout_duration （デフォルト値 = 10） rds.password_lockout_reset_counter_after （デフォルト値 = 10） SQL Server ログインのロックアウトポリシーを有効にするには、RDS パラメータグループに戻り、 rds.password_lockout_threshold パラメータを 0 から 3 に更新します。この設定により、3 回のパスワード入力失敗後に SQL Server ログインがロックアウトされます。 rds.password_lockout_threshold は動的パラメータであり、 CHECK_POLICY が有効になっているすべてのログインに適用されます。 ロックアウトポリシーを有効にしたことで、「CHECK_POLICY」または「パスワードポリシーを適用する」が有効になっている任意の SQL Server ログインに対して、不正なパスワードを使用して 3 回連続でログインに失敗すると、そのログインはロックアウトされます。 以下の図に示すように、SQL Server Management Studio から SQL Server のログイン状態を確認できます。 あるいは、SQL サーバーのログファイルを参照することもできます。 EXEC rdsadmin.dbo.rds_read_error_log Amazon RDS for SQL Server のエラーログによると、3 回のパスワード入力ミスの後、ログインユーザー user1 がロックアウトされ、正しいパスワードを入力しても接続できなくなっています。設定例のパラメータによると、ロックアウト期間は 10 分後に解除されます。データベース管理者は、ロックアウトされたログインを任意のタイミングで手動でロック解除することができます。 注意：プロアクティブな監視のために、失敗したログインを追跡するために SQL Server 監査用の データベースアクティビティストリーム を構成してください。 クリーンアップ この設定が不要になり、今後の料金を避けたい場合は、Amazon RDS for SQL Server インスタンスを 削除 することができます。 結論 この投稿では、Amazon RDS for SQL Server データベースインスタンスで SQL Server 認証を使用したログインに対するパスワードポリシーの適用方法を紹介しました。この機能により、組織の要件に基づいて SQL Server ログインのパスワードポリシーを設定することができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Vikas Babu Gali は、アマゾンウェブサービスにおいてマイクロソフトのワークロードに特化したシニアスペシャリストソリューションズアーキテクトです。彼は、クリケットをプレイすることや、家族や友人と屋外で時間を過ごすことを楽しんでいます。 Wasim Shaikh は AWS のデータベース専門のシニアパートナーソリューションアーキテクトです。お客様と協力して、様々なデータベースや分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を使用する際のソリューションの価値向上を支援しています。

この記事は 「 Upbound Group builds its modernized point-of-sale platform on AWS 」（記事公開日： 2024 年 11 月 18 日）の翻訳記事です。 Upbound Group Inc. (NASDAQ: UPBD) は、テキサス州 Plano に本社を置くオムニチャネルプラットフォーム企業です。 時代とともに進化する消費者のニーズや期待に応える、革新的で包括的、かつテクノロジー主導の金融ソリューションを提供することに力を入れています。 Upbound Group の顧客向け事業部門には、 Rent-A-Center® や Acima® などの業界をリードするブランドが含まれ、店舗をベースとしたさまざまな小売チャネルおよびデジタル小売チャネルでもブランド企業と消費者とが容易に取引できるようにしています。 Upbound Group は、米国、メキシコ、プエルトリコに 2,400 超の自社店舗を構えています。 変化するニーズへの適応 目まぐるしく変化する小売業界では、効率化と顧客満足度の向上にテクノロジーが不可欠です。 Upbound Group は、従来の Swing ベースの SIMS POS システムがイノベーションを妨げていることに気がつきました。 Upbound Group は、以下の主な阻害要因を考慮した結果、オールインクラウドの実装を進めることに決定しました。 時代遅れのテクノロジー 制約のある、時代遅れのテクノロジーを使用した Swing ベースのシステム スケーリングや最新の SaaS ソリューションとの統合が困難 回避策が必要で、開発とテストのサイクルが遅延 技術的な負債が発生し、仕事の進捗において社員のストレスが増加 一貫性のない顧客情報 顧客プロファイルや、実店舗と E コマース事業とのやりとりを統一的に把握する視点が欠如 多くの場合、満足していただける顧客体験を提供できず、また詐欺のリスクが増大 運用上の混乱 レガシーな POS システムのため、運用状況のエンドツーエンドでの可視化が不可能 問題の診断と解決が長期化 以下の図は、Upbound Group が使用したデジタルトランスフォーメーションフレームワークの概要を示しています。 この技術スタックは、API、イベント駆動を中心とする、最新のマイクロサービスアーキテクチャで構成されています。 Upbound Group の顧客需要の高まりに対応できるスケーラビリティと弾力性を備えています。 イベント駆動型のサーバーレスアーキテクチャの採用 モダナイゼーション以前は、Upbound Group はオンプレミスのレガシーインフラストラクチャ上にモノリシックなアーキテクチャを構築していました。 そのため、変化する顧客需要に応じたスケーリングができませんでした。 また、開発者は必要に応じて迅速に機能を構築することもできませんでした。 Upbound Group は、 Amazon API Gateway 、 AWS Lambda 、および AWS Fargate を使用して API ファーストの設計を実装することで、マイクロサービスアーキテクチャに移行しました。 さらに自社レンタルサービスとエンタープライズサービスのアプリケーションスタックを完全にモダナイズし、 開発チームはショッピング体験を向上させる新しい機能を迅速にリリースできるようになりました。 また、ビジネスチームは戦略的および戦術的なビジネス目標を達成するために、ソリューションを自由に組み合わせることが可能になりました。 Upbound Group には、1,080 を超えるトランザクションテーブル、レガシーリース契約、アーカイブデータのほか、2,600 を超えるテーブルを含む 45 TB の履歴データがありました。また商用ソフトウェアの使用やデータベースサーバーの自己管理をやめ、データサイロ化を排除し、データ価値を最大化し、アプリケーションや組織間でデータを共有したいとも考えていました。 そこで Upbound Groupは、 AWS Data Migration Service (DMS) 、 AWS Schema Conversion Tool (AWS SCT) 、カスタムデータベース開発を利用して、従来のトランザクションデータベース (Oracle Exadata 上で実行) から自社専用の Amazon Aurora PostgreSQL に移行したのです。 その後、Upbound Group は正規化と効率的なインデックス作成を優先して、トランザクションデータモデルの最適化、再設計、統合を行いました。 これによりアプリケーションのパフォーマンスが向上し、テーブル数が 400 に、データサイズが 30 TB 未満に減少しました。 また、Upbound Group は Aurora インスタンスを AWS Graviton3 ベースの R7g データベースインスタンスにアップグレードし、システム全体のパフォーマンスを向上させました。 現在では、データは予測可能な程度に安定して着実に、しかもコストを抑えて増加しています。 柔軟でスケーラブルなインテグレーションの選択 Upbound Group は、コアビジネスとエンタープライズマイクロサービスを主要なトランザクションデータベースである RACDB と統合するために、フルマネージド型の高可用性データベースである Amazon RDS Proxy を採用しました。 RDS Proxy のコネクションプールにより、Lambda のマイクロサービスと Aurora データベースが疎結合となることで、Lambda と Aurora はそれぞれの負荷や要件に応じて、個別にスケールできるようになります。これにより、RDS への過剰な接続によるリソースの不足およびメモリの競合が排除できます。というのも、 Amazon Simple Notification Service (SNS) のトピックは、イベント駆動に伴う非同期処理のニーズに対応して複数の Amazon Simple Queue Service (SQS) キューにメッセージを 分散する ことができるからです。 オムニチャネルのカスタマーエクスペリエンスを向上させるため、Upbound Group は Amazon DynamoDB を使用するグローバルカスタマーデータベース (GCDB) と Amazon OpenSearch Service を使用する検索機能を追加しました。これにより、モダナイズされた POS システムである RACPad など、顧客と接点を持つアプリケーションも GCDB と連携します。RACPad で処理される新規顧客の取引データも GCDB に反映されます。こうして Upbound Group は顧客データを一元的に把握できるため、パーソナライズされたマーケティングキャンペーン、統合型カスタマーサポート、クロスセル、アップセルといった顧客にあわせたきめ細かなアプローチが可能になります。 エンドツーエンドのセキュリティ、可用性、回復力の強化 可用性を向上させ、ダウンタイムを短縮するために、Upbound Group は技術スタックを 複数の AWS リージョンに パイロットライト戦略 でデプロイしました。 データレイヤーとして、Upbound Group はリードレプリカを備えた Amazon Aurora マルチ AZ クラスターを採用しました。 ストレージレイヤーでは、Upbound Group は AWS S3 クロスリージョンレプリケーションを使用して、ビジネスデータとアプリケーションデータをプライマリリージョンからセカンダリリージョンに複製します。 DynamoDB グローバルテーブルは複数リージョンのテーブルレプリケーションの管理に使用され、DynamoDB ストリームの変更データキャプチャによりプライマリ GCDB とセカンダリ GCDB の同期が保たれます。 CI/CD パイプラインは、アプリケーションパッケージをセカンダリリージョンにデプロイし、セカンダリデータベースクラスターと統合するように設定されています。 また、プラットフォームエンジニアリングチームは AWS CloudFormation スタックを使って、IaC でデプロイを行っています。 Upbound Group は、以下のような他の AWS サービスも使用しています。 AWS Control Tower は AWS ランディングゾーンを作成、管理、スケーリングします。 AWS Direct Connect は、プライベートインフラストラクチャと AWS 間の専用のハイブリッドネットワーク接続ができるようにします。 アプリケーション開発者は Amazon CloudWatch と AWS X-Ray を使用してカスタムメトリックス、カスタムログ、トレースを有効にし、アプリケーションのパフォーマンスをトラブルシューティングおよびモニタリングします。 データベース管理者は Performance Insights を使用して高度なパフォーマンスモニタリングと Aurora PostgreSQL クラスターの調整を行います。 ビジネス成果 AWS CloudFormation を使用することでインフラの設定やプロビジョニングをテンプレート化できるため、Upbound Group は、この CloudFormation のテンプレートを作成し、それに基づいてインフラのスタックをプロビジョニングしており、また作成したスタックを継続的に管理、更新しています。 AWS Config は、セキュリティとガバナンスを強化するために、AWS リソースのインベントリ、設定履歴、変更通知を管理します。 また、プラットフォームエンジニアリング、アプリケーション開発、エンタープライズサービスエンジニアリングの各チームは、複数の「 Two-Pizza Teams 」を結成することで効果的に連携ができます。 この変革により、Upbound Group は顧客に一貫したオムニチャネル体験を提供できるようになりました。 Amazon OpenSearch を活用したグローバル顧客データベースの統合顧客プロファイルにより、ビジネスチームは顧客獲得と維持を目的とした、ターゲットを絞ったパーソナライズされたキャンペーンを作成できます。 Upbound Group は膨大な履歴データの移行に成功し、2,400 を超える店舗とパートナー拠点で RACPad を活用してスケーラビリティ、信頼性、運用の俊敏性を高めました。 このクラウドファーストのアーキテクチャにより、店舗全体でプロセスが合理化され、1 か月あたり数百時間を節約できたため、スタッフは戦略的なタスクや顧客サービスの向上に集中できるようになりました。 次回のブログでは、RACPad の技術コンポーネントと設計フレームワークについて詳しく説明します。 「サーバーレスファーストのアプローチで AWS のサービススイートに RACPad を構築すると、革新的な体験ができます。 このシフトにより、インフラストラクチャのプロビジョニングという制約を受けずに新機能を迅速にデプロイできるため、開発サイクルを短縮できます。 サーバーレスアーキテクチャの主な利点の 1 つは、オフピーク時にコストをゼロにスケールダウンできることです。 これは従量課金制の価格モデルによって実現されています」 — Pranav Sharma、Director of Platform Delivery 「従来のオンプレミスアーキテクチャからサーバーレスアーキテクチャに移行する際には、移行に関する自社の技術的能力を考慮する必要があります… サーバーレスコミュニティと AWS エンタープライズサポートに頼ることができたおかげで、安心して移行できました」 — Mike Porras、Director of Platform Engineering 「 Transforming Retail in the cloud: A CIO’s Handbook 」をダウンロードして、AWS がビジネスの成長にどのように役立つかをご覧ください。 AWS は MACH Alliance のメンバーでもあります。 イノベーションを促進し、企業、小売業者、CPG 企業が最高の顧客体験を提供できるよう支援します。 AWS Retail Solutions の詳細については、こちら をご覧ください。 著者について Mike Porras Mike Porras は Upbound Group のプラットフォームエンジニアリング担当ディレクターです。 彼は、多様な開発チームと運用チームのニーズをサポートする統合クラウドテクノロジープラットフォームの設計と保守に注力しています。 Brad King Brad King は AWS の Enterprise Account Executive です。 Brad は、複雑な技術概念を説明し、長期的なパートナーシップを通じてクライアントがデジタルトランスフォーメーションの目標を効率的かつ効果的に達成できるようにすることを専門としています。 AK Soni AK Soni は AWS エンタープライズサポートのシニアテクニカルアカウントマネージャーです。 彼は積極的なガイダンスを提供することで、企業顧客がビジネス目標を達成できるよう支援しています。 エンタープライズアプリケーションのアーキテクチャと開発に 19 年以上携わってきた経験から、生成 AI テクノロジーを使用して事業運営を強化し、既存のテクノロジーの限界を克服することに熱心に取り組んでいます。 Pranav Sharma Pranav SharmaはUpbound Group のプラットフォームデリバリー担当ディレクターであり、革新的なテクノロジーソリューションを通じてデジタル変革を推進することに情熱を注いでいます。 彼は最近、AI の使用における倫理と、社会に有益な方法で開発を導く原則の実際についてより深く考え始めました。 プライベートでは料理に腕をふるい、旅行することが大好きです。 Suprakash Dutta Suprakash は AWS のシニアソリューションアーキテクトです。 デジタルトランスフォーメーション戦略、アプリケーションのモダナイゼーションと移行、データ分析、機械学習を専門としています。 AWS の AI/ML コミュニティの一員であり、生成 AI とインテリジェントなドキュメント処理ソリューションを設計しています。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

アマゾン ウェブ サービス ジャパン合同会社は、2025年1月14日に「 基盤モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術 ～ AWS Trainium2 & Amazon Bedrock Marketplace ～ 」を開催しました。 本イベントでは、最新の AWS Trainium2 チップ を搭載した Amazon EC2 Trn2 インスタンスおよび Trn2 UltraServers 、 100以上の基盤モデルへのアクセスが可能な Amazon Bedrock Marketplace について、生成 AI 基盤モデル開発者向けに深掘りするセッションが行われました。本記事では、その模様をお届けします。 オープニング はじめに、アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 サービス & テクノロジー統括本部 統括本部長 安田 俊彦より開会のあいさつをしました。これまで AWS は一貫して、エンジニアがものづくりをしやすい環境を構築してきました。各種のサービスを提供するだけではなく、技術ノウハウをエンジニア同士で共有する場を設けています。 特に近年では日本において、2023年に「 AWS LLM 開発支援プログラム 」、2024年に「 AWS ジャパン 生成 AI 実用化推進プログラム 」を開始するなど、生成 AI や大規模言語モデル (以下、LLM) の開発支援に注力しています。また、経済産業省の「 GENIAC (Generative AI Accelerator Challenge) 」においても 計算リソース提供者として選定 されました。 グローバルでも、「 AWS re:Invent 2024 」では生成 AI 関連で 500 以上のセッションが行われ、最新の AWS Trainium2 チップを搭載する Amazon EC2 Trn2 インスタンスの一般提供開始となり Trn2 UltraServers のプレビューが発表されました。さらに、Amazon Bedrock 上で100以上の基盤モデルを利用できる Amazon Bedrock Marketplace も発表されました。 これらの新サービスについて、今回のイベントにて詳細を解説する旨を述べたうえで「AWS はこれからも、新しいテクノロジーを世界中に届けます」と結びました。 Amazon EC2 Accelerated Compute Update + AWS Trainium2 Deep Dive ここからは、AWS Sr. Product Manager で AWS Trainium, Inferentiaを担当している Joe Senerchia (写真左) と 同じく GPU インスタンスを担当している Dvij Bajpai (写真右) が登壇しました。生成 AI の基盤モデルの学習や推論に適したインフラストラクチャーについて述べ、その上で動作する「Accelerated Compute」アーキテクチャ、その中核をなす新しいサービスについて解説を行いました。 冒頭では、基盤モデルの学習を支えるAWSのインフラ技術要素として、二つの重要なポイントが挙げられました。一つ目はネットワークです。複数のインスタンスへ学習をスケールさせるためには、広帯域の Elastic Fabric Adapter (EFA) が必要不可欠であると説明されました。 二つ目はストレージです。大規模なモデルの学習には膨大なデータが必要となります。さらに、チェックポイントやデータセットの保存も考慮しなければなりません。これらの課題に対応するため、AWS ではマネージドサービスである Amazon FSx for Lustre を提供しています。このサービスを利用することで、ストレージがボトルネックとなることなく GPU 利用率を向上させる仕組みが実現されています。また、FSx for Lustre は昨年、前述の EFA にも対応いたしました。 この２つのサービスを組み合わせることで、これまで以上に大規模学習に伴うデータの読み書きが高速化されます。 EC2 Trn2 インスタンス は Trainium2 (96 GiB HBM) を16チップ搭載し、192 vCPU、2 TiB のホストメモリ、3.2 Tbps の EFA v3 ネットワーク帯域幅を備えています。Trn2 インスタンスでは、Dense 演算性能で 20.8 PFLOPS (FP8)、Sparse 演算性能で 41 PFLOPS (FP8/FP16/BF16/TF32) の性能を持ち、1.5 TiB の HBM を搭載し 46.4 TB/s のメモリ帯域幅を提供します。 さらに、 Trn2 UltraServers についても解説がありました。Trn2 UltraServers は、1 台のサーバー内に 64 個の AWS Trainium2 チップを搭載し、NeuronLink というチップ間の低遅延・高帯域幅通信により、高密度な計算環境を実現します。この設計は、大規模モデルの分散学習や推論において優れたパフォーマンスを発揮します。 AWS Trainium2 の性能を最大限に引き出すためには、 AWS Neuron SDK の利用が重要です。Neuron SDK は、Trainium チップ専用に設計された開発ツールであり、PyTorch や JAX などの主要な機械学習フレームワークをサポートしています。 また、AWS は Anthropic と共同で次世代の AI プロジェクト「Project Rainier」にも取り組んでいます。このプロジェクトでは、数十万個の AWS Trainium2 チップを用いて ExaFLOPS 規模の学習を実現することを目指しており、EC2 UltraServers の進化がその中核を支えています。 Introducing Amazon Bedrock Marketplace 次に、AWS で Amazon Bedrock の Principal Product Manager を務める John Liu が登場しました。Amazon Bedrock は企業がさまざまな生成 AI モデルやツールにアクセスし、それらを簡単に利用できるようにします。 Amazon Bedrock Marketplace では、特定業界や用途に特化した100以上の多様なモデルへのアクセスが可能です。これらのモデルは、Amazon Bedrock の Converse API や InvokeModel API を通じて簡単に利用できます。モデルの利用に必要なインフラは Amazon SageMaker AI 上で提供されています。ユーザーはインスタンスのタイプや数を柔軟に選択でき、必要に応じてオートスケールのポリシーを設定することも可能です。これにより、ワークフローに最適化されたスケーラブルなモデル運用が実現します。 プロバイダー側にも多くの利点があります。Amazon Bedrock Marketplace を活用することで、プロバイダーはモデルの提供プロセスを効率化し、オンボーディングにかかる時間を短縮できます。また、 AWS Marketplace を通じて価格設定を管理することも可能です。セキュリティとプライバシー保護も重要な特徴です。 Amazon SageMaker AI に基づくコンテナ環境で、モデルの重みといった知的財産 (IP) が外部へ流出しない仕組みが整えられています。 Customer Session ここからは、AWS の生成 AI 関連サービスを活用している企業の方々による Customer Session が行われました。 カラクリ株式会社 カラクリ株式会社 取締役 CPO の中山 智文 氏は、同社が開発した生成 AI モデル「 KARAKURI LM シリーズ 」について紹介しました。このシリーズは、日本のカスタマーサポート関連データを大量に学習したオープンモデルです。 HuggingFace で公開されているほか、AWS Marketplace でも利用可能です。 同社はコスト削減やモデルの計算リソース確保のために AWS Trainium を活用しています。AWS Trainium は GPU の約半額で運用でき、AWS からの手厚いサポートが受けられることが大きな利点です。一方で、対応済みのモデルやアルゴリズム以外は自前で対応する必要があることや、AWS Trainium に関連するコミュニティや知見がまだ不足している点を課題に挙げ、「ユーザーコミュニティの成長による、技術の共有と発展が重要」と期待を表現しました。 株式会社 Preferred Networks 株式会社Preferred Networks Vice President of Consumer Products の福田 昌昭 氏は、同社が開発した大規模言語モデル「 PLaMo 」について説明しました。「PLaMo」は GENIAC 第一期で 100B モデルとしてリリースされ、商用版である「PLaMo Prime」は 2024 年 12 月に提供開始されました。また、小規模言語モデル (SLM) の開発にも注力し、コスト削減やリアルタイム処理への対応を目指しています。 「PLaMo」は Amazon Bedrock Marketplace で提供されており、クローズドなクラウド環境で安全に利用できる仕組みを構築しています。また、コスト削減や計算リソースの安定確保などの課題を解消するために、 EC2 G6e インスタンス (NVIDIA L40S Tensor Core GPU) やカスタムシリコン (AWS Trainium、AWS Inferentia) の活用を進めています。福田 氏は生成 AI が「試す」段階から「使う」段階に進んでいると述べ、AWS を活用して生成 AI の社会実装を推進する意向を示しました。 株式会社 リコー 株式会社リコー デジタル戦略部 デジタル技術開発センター 副所長の鈴木 剛 氏は、同社の AI 事業と生成 AI に関連する取り組みについて説明しました。リコー社は、生成 AI やプライベート LLM を活用した AI ソリューションを提供しており、高性能な日本語 LLM の開発を進めています。特に、ベクトル検索やプライベート LLM の実用化に注力し、オープンソースや独自技術を組み合わせることで柔軟なモデル構築を実現しています。 AI モデルの開発においては、オープンなモデルをベースとしつつ、日本語性能を高めるためトークナイザーの工夫やカリキュラム学習、モデルマージを駆使しています。GPT-4 と同等の日本語性能を達成し、多言語対応も進めています。また、AWS Trainium を利用することで、GPU と比較して大幅なコスト削減と効率向上を実現しました。特に、モデルの学習時にスループットを測定し、最適な運用方法を導き出すことで開発効率を高めています。 ストックマーク株式会社 ストックマーク株式会社 取締役 CTO の有馬 幸介 氏は、同社が提供する AI プロダクトと AWS の活用について説明しました。 同社のプロダクト である「A news」「A strategy」には、独自開発の LLM が導入されています。LLM 開発において AWS Trainium を利用したことで、GPU と比較して約 20% のコスト削減を実現しました。また、推論基盤としても AWS Inferentia2 を活用しています。 さらに、Amazon Bedrock Marketplace にモデルを提供しており、これにより広範囲の顧客にリーチできるほか、モデルファイルを直接共有せずに価値を提供できることが利点です。有馬 氏は、AWS Trainium や Amazon Bedrock の活用は敷居が低く、効率的なプロダクト開発を可能にする手段であると強調しました。同社はこれらの技術を活用し、顧客価値を提供するプロダクトの開発を今後も進めていくと締めくくりました。 懇親会 セッション終了後には懇親会が開催され、登壇者や参加者同士が自由に交流する場が設けられました。ここでは、生成 AI 技術や AWS の最新サービスについての情報共有や意見交換が活発に行われ、参加者にとって有益な時間となりました。 おわりに AWS は引き続き、最先端の技術を提供するだけでなく、開発者や企業がそれを最大限に活用できる環境を構築してまいります。学習や交流のための場も積極的に設けますので、ぜひ次回のイベントにご参加いただければ幸いです。 AWSと生成AIでのビジネス課題を解決されたい方は 生成AI実用化推進プログラム をご活用ください (申し込みは2月14日まで)。2月7日に 第2回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ も開催しますのでご参加ください。 著者について 針原 佳貴 Sr. GenAI Startup Solutions Architect, AWS Japan. 日本の生成 AI スタートアップ担当として、基盤モデル開発や Amazon Bedrock Marketplace へのモデル公開を支援。本イベントでは、John のサポートと Customer Session のファシリテーションで参加。

この記事は 「 Unlock new capabilities from product images using generative AI 」（記事公開日： 2024 年 11 月 12 日）の翻訳記事です。 小売および消費財企業は、顧客体験の向上、業務効率の向上、新しい収益源の創出を目的として、生成 AI を採用していっています。 マルチモーダルおよび画像生成の大規模言語モデル (LLM) の最近の進歩により、ビジュアルデータの利用も拡大しています。 たとえば、 Amazon の生成 AI ツール は、出品者が商品説明や動画広告を作成できるよう支援し、業務を効率化し、販売体験を向上させます。 このブログ記事では、革新的な生成 AI のユースケースを 3 つご紹介します。 それぞれのユースケースでは、生成 AI が商品画像やビジュアルアセットからどのように新しい可能性を引き出すことができるかに注目しています。 また、小売企業や消費財企業にもたらされる主なメリットについても説明し、これらのソリューションを AWS 上で実装するためのアーキテクチャガイダンスを提供します。 画像ベースの生成 AI のユースケース 画像からテキストへ コンピュータービジョン機能を備えた生成 AI モデルは、商品コンテンツを変革し、顧客体験を大幅に向上させることができます。 Amazon Bedrock でホストされている Anthropic の Claude 3 などのマルチモーダル LLM を使用することで、企業はビジュアルアセットから詳細な商品説明をシームレスかつ自動的に作成できます。 マルチモーダル LLM は、商品画像内の重要な要素を認識して識別できます。 関連するメタデータを抽出し、この情報を説得力のある、読みやすいテキストに変換します。 生成されたコンテンツは、検索エンジン最適化 (SEO) を改善して商品を見つけやすくし、実際の商品と商品情報の間のギャップを埋め、より包括的で正確な詳細を作成することで、商品ページの内容を充実させます。 こうした改善は、コンバージョン率の向上と顧客満足度の向上につながります。 消費財ブランドは、商品の寸法、素材、スタイルを自動的に推論することで、カタログ管理を効率化することもできます。 この自動化により、より完全で充実した商品データが作成され、業務効率が向上します。 LLM は画像内の特定のオブジェクト、シーン、属性を識別できるため、コンテンツモデレーションのワークフローが効率化され、その一方で規制を遵守するようにします。 また、目の見えないユーザーや弱視のユーザー向けに、詳細な画像キャプションを自動で作成できるため、アクセシビリティも向上します。 アーキテクチャの例 商品イメージと説明プロンプトを 1 つの入力に組み合わせ、Anthropic Claude 3.5 といった Amazon Bedrock 上でホストされているマルチモーダル言語モデルで処理を行います。例ではチェック柄のシャツの画像に対し、「この商品イメージにあった詳細で、検索エンジンで最も見つけやすくなるような商品説明文を作成して」と指示が付加されています。 Amazon Bedrock はこの商品とその特徴について豊富な情報を含む詳細な説明を出力します。例では「このスタイリッシュなチェック柄のフランネルシャツは様々な用途で使えるトレンディな基本アイテムです。高品質な綿フランネル生地を使用し…」といった説明が出力されています。 画像ベースの検索 画像ベースの検索では、コンピュータービジョンを採用して、より直感的で効果的な検索体験を提供します。 Amazon Bedrock の Amazon Titan Multimodal Embeddings などのマルチモーダル埋め込みモデルや、 Amazon OpenSearch Serverless 用の Vector Engine などのベクターデータベースを使用することで、企業はテキストとビジュアルデータの両方を理解する自然言語のセマンティック検索機能を実装できます。 このアプローチにより、より直感的で魅力的なショッピング体験が可能になります。つまり、顧客に厳格な検索条件を強いるのではなく、自然言語と視覚的な手がかりを通じて顧客の意図を理解しようとします。 小売および消費財アプリケーションでは、画像ベースの検索は、顧客が自然言語クエリを使用して商品を見つけるのに役立ちます。 顧客は参考画像をアップロードすることもできます。 顧客は「花柄の赤いドレス」を検索したり、画像をアップロードしてそれに類似するドレスを検索したりすることができます。 システムは視覚的にも意味的にも類似した商品を検索するため、検索の関連性が向上し、コンバージョン率が高まる可能性があります。 組み込み LLM は商品画像を処理し、テキストとビジュアル入力を関連する商品組み込みにマッピングします。 組み込みモデルは、複雑な検索入力の解釈と照合という面倒な作業を行ってくれるため、広範囲にわたるキーワード管理や SEO の取り組みの必要性が軽減されます。 画像ベースの検索は、商品の見つけやすさと検索結果の関連性を大幅に向上させます。 顧客エンゲージメントが向上し、コンバージョン率の向上と売上の増加につながります。 さらに、顧客の意図を深く理解することで、小売業者は状況に応じたパーソナライズされた商品レコメンデーションを提供できるようになり、ショッピング体験がさらに向上し、ビジネスの成長を促進します。 アーキテクチャ例 商品画像は Amazon Bedrock 上でホストされているマルチモーダル組み込みモデル（例えば、Amazon Titan Multimodal Embeddings など）で処理され、商品のビジュアルな特徴をコード化した数値ベクトルに変換されます。 手順 1 で生成されたベクトル情報は Amazon OpenSearch といったベクトルデータベースに格納されます。 ユーザーが検索したい対象商品の画像をアップロードすると、マルチモーダル埋め込みモデルによって処理され、ベクトル表現に変換されます。 ユーザーが入力したクエリのベクトル表現はベクトルデータベースを検索し、最も類似した画像埋め込みを探し出すと、それに関連した商品を出力します。 画像生成 (テキストから画像、画像から画像) Stability AI の Stable Diffusion Ultra や Amazon Titan Image Generator V2 などの画像生成モデルは、どちらも Amazon Bedrock でホストされており、商品のアイディエーションやパーソナライズされた体験に新たな可能性を切り開いています。 このアプローチにより、アイディエーションが迅速になり、複数あることの多いデザイン案を同時に検討して方向性を決定できます。 一般的なユースケースでは、ビジュアルを利用して商品のアイディエーションを行います。 設計者は、基本的なスケッチやコンセプトから始めて、画像生成モデルを使用して、さまざまな商品のアイデアやバリエーションを開発し、具体化できます。 小売業者はまた、画像生成を利用して、ユーザーが指定したシーンや環境で商品をレンダリングすることで、パーソナライズされた商品体験を作り出せます。 たとえばユーザーが居間の画像をアップロードすると、モデルはそれを参照し、その居間に実際に商品が置かれているかのような画像を生成します。 このように指示に基づいて画像を作成することで、購買決定を支援し、顧客エンゲージメントを高めます。 生成 AI を活用した画像生成は、ビジネスに大きなメリットをもたらします。 商品のアイディエーションと設計を加速させると同時に、購入の決定に役立つ高度にパーソナライズされた顧客体験を可能にします。 ただし、これらの機能を実装する場合、企業は信頼性、透明性、責任ある使用を徹底する必要があります。 AWS は、Amazon Titan Image Generator モデルで生成された画像に目に見えない電子透かしを入れることで、こうした取り組みを支援しています。 これにより、商品表現に対する信頼を維持することができます。 また、基本モデルのコンテンツフィルタリング機能は、誤解を招くような商品画像や有害な商品画像が生成されるのを防ぎ、ブランドイメージを守るのに役立ちます。 商品の完全性を保ち、顧客との関係を強化しながら、生成 AI の革新的な可能性を最大限に引き出すには、ブランドはビジュアルコンテンツ制作における AI の使用に関する明確なポリシーを確立する必要があります。 これには、AI をいつ、どのように利用するかについて、顧客に対して明確に説明できるよう透明性を保つことも含まれます。 これらの倫理ガイドラインに従い、AWS の生成 AI 機能を利用することで、企業はクリエイティブな新しいアプリケーションを模索し、収益の可能性を引き出して事業を進めることができます。 アーキテクチャ例 Amazon Bedrock 上のマルチモーダル LLM （例えば Anthropic Claude 3.5 Sonnet）を使って、アイデアの下書きスケッチを解析し、画像生成モデル向けの詳細なプロンプトを生成します。 生成されたプロンプトとオリジナルのアイデア画像を Amazon Bedrock 上でホストされている、Amazon Titan Image Generator G1 といった画像生成 LLM に入力します。 入力プロンプトとオリジナルの下書きスケッチに基づいた高精細にレンダリングされたアイデアイメージが出力されます。 LLM で小売業者の生産性向上 生成 AI は従業員に取って代わるものではありません。 チームがより多くのことを成し遂げられるように支援するのが役目です。 これらのテクノロジーを導入することで、小売業者はさまざまな業務においてアウトプットの質と量の両方を大幅に向上させることができます。 業界を代表するブランドはすでに AWS の生成 AI ソリューションでビジネスを変革しています。 The Very Group が生成 AI でどのように顧客体験を向上させたかをご覧ください。 Zalando と AWS Gen AI Innovation Center が Amazon Bedrock を使用して非構造化データから商品属性を抽出した方法をご覧ください。 生成 AI で小売業務を変革する準備はできていますか? 次の一歩を踏み出しましょう。 Generative AI for Retail and Customer Goods ページ で、AWS がどのように効率を高め、顧客エンゲージメントを高め、ビジネスのイノベーションを加速できるかをご覧ください。 AWS の小売スペシャリストとの個別相談を設定していただき、御社の課題に関してお聞かせください。 AWS re: Invent の「 RCG206: How Nykaa automates product descriptions using generative 」を視聴して、インドの大手小売業者である Nykaa が生成 AI を使用して商品説明を作成している方法をご覧ください。 こうした機能のライブデモンストレーションをNRF 2025: Retailer’s Big Show (2025 年 1 月 12 日～ 14 日) にて実施いたしました。詳細は こちら 。 著者について Matt Barbieri Matt Barbieri は AWS のシニアソリューションアーキテクトで、ニューヨークオフィスに勤務しています。 AWS の元顧客として 10 年近くの経験を持つ Matt は、クラウドの導入とデジタルトランスフォーメーションを通じて小売および消費財企業のビジネスを導いています。 生成 AI やその他のテクノロジーを使用してビジネス上の課題を解決することを専門としています。 Matt は、複雑な技術概念を実用的な戦略に変換しながら、安全かつ規制に準拠した効率的な AWS ソリューションを設計しています。 彼の仕事は、小売企業や消費財企業が急速に変化する市場でイノベーションを加速し、より効果的に競争できるようにすることです。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

このブログは 2023 年 11 月 7 日に Randy Seamans (Principal Storage Specialist and advocate for AWS) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 電子健康記録 (EHR) アプリケーションの市場規模は、高い年間成長率で 400 億 ドル規模に近づきつつあります。EHR の利用者は、革新的な医療の実現に引き続き注力しながら、運用上の負担、管理オーバーヘッド、資本支出、総所有コストを削減するクラウドベースのアプローチを採用することで恩恵を受けることができます。EHR の導入は本質的に複雑で、相互接続された多数のアプリケーションと周辺環境で構成されており、それぞれに独自のストレージとパフォーマンス要件があります。EHR の中核にある本番環境データベースのパフォーマンスは、オンプレミスでもクラウドでも制約要因になる可能性があります。ほとんどの場合、本番環境データベースのストレージ環境は、現在の要件だけでなく、3 ～ 5 年の成長も考慮して構築されています。 Amazon FSx for NetApp ONTAP (FSx for ONTAP) と Amazon Elastic Block Store (EBS) は、医療機関がクラウド導入の過程で直面するあらゆる EHR のストレージ要件に対応できます。 このブログでは、EHR 環境が、使用したパフォーマンスに対してのみ料金を支払いながら、ストレージパフォーマンスを弾力的かつエレガントに、中断なく最適に拡張する方法を学ぶことができます。これにより、医療機関は予測不可能な成長期でもストレージコストを管理できます。まず、ランサムウェアや災害が発生した場合に EHR 環境のクラウドベースの読み取り専用コピーを拡張できる FSx for ONTAP のアーキテクチャについて説明します。次に、可用性が高く災害復旧が可能なクラウドベースの EHR 本番環境について、オンデマンドで拡張可能な FSx for ONTAP のアーキテクチャーを見ていきます。 規模拡大の機会 患者の負荷が増大し 、 医療機関が業務を統合する につれて、これらのワークロードを処理するためのコンピューティング、ネットワーク、ストレージのパフォーマンスに対する需要も高まります。これに応えて、AWS は最近、高度な新しい AWS インスタンスと EBS io2 Block Express を活用して、 Epic のパフォーマンスの拡張性を向上させる ことを発表しました。これは、医療機関が現在導入している EHR 環境の大部分には十分すぎるほどのものです。ただし、医療機関は、合併、買収、または前例のない成長により、計画外の成長を経験することがよくあります。この課題に対処するために、本ブログでは、ストレージコストを制御しながら EHR ストレージ環境を拡張する最適な方法について説明します。 昨年、ストレージブログで、従来のブロックベースのデータベースワークロードを拡張する 並列ストレージとしての FSx for ONTAP アーキテクチャ を紹介しました。本日はこれと同じアプローチを使用して、EHR 関連のストレージパフォーマンスを前例のないレベルにまで高める方法について説明します。実際に、ブログの公開とより高速で新しい Amazon EC2 インスタンス の導入以降、現在では 1 台のサーバーで最大 200 万 IOPS (8K ランダム、サブミリ秒) を実現しています。 ただし、何度も実行できるような基礎的で継続性のあるストレージベンチマークパフォーマンスと、アプリケーション層のストレージパフォーマンスメトリクスを混同しないように注意する必要があります。多くの高度に統合されたアプリケーションがそうであるように、デプロイした EHR アプリケーションが、全体的なアプリケーションパフォーマンスへの影響を左右しない状態で動いていれば、それはストレージパフォーマンスのほんの一部しか利用していないことになります。実際の経験では、この要素は 40 ～ 60% の範囲になる可能性があります。つまり、8K で 200 万 IOPS 実行可能なストレージ環境では、アプリケーションスタック全体からデータベースの本番環境コピーまで含めると、約 100 万 IOPS がそのアプリケーションに対する事実上の実行可能な範囲になる可能性があります。もちろん、その他に関連ワークフローが存在すれば、AWS ストレージ層によって提供される残りのストレージパフォーマンスの余剰分を有効に活用できます。 このことから、ストレージの拡張性が非常に要求されることがわかります。オンプレミスに設置された固定的なストレージ資産とは異なり、クラウドデプロイメントでは、要求するパフォーマンスレベルに対してのみ支払えば良く、前払い資本コストはありません。運用変更や中断もなく、ストレージパフォーマンスを 10 倍以上にすることができます。この拡張性により、組織は現在および将来の EHR 本番環境のストレージ要件を経済的に満たすことができるという確信が得られます。組織は、時間の経過とともにストレージパフォーマンスをゆっくりと拡張することも、災害時に パイロットライト レベルから完全な本番環境ワークロードに数分以内に拡張することもできます。最後に、ストレージのパフォーマンスをほぼリアルタイムで増減できるため、買収・合併やランサムウェアのような不可抗力の事態にも対応できます。 スケーラブルな EHR のストレージ環境に向けて 従来、ほとんどのアプリケーションでは垂直のストレージサイロが好まれていたため、アレイベースのスナップショットを使用して特定の時点での ストレージ IO の一貫性 を確保していました。複数のストレージアレイ間の一貫性はサポートされていませんでした。ワークロードまたは環境全体が単一のアレイに収まらない場合、アプリケーション層またはミドルウェア層は、スナップショットとバックアップのために複数のアレイにわたって一貫性のあるタイミングを調整する必要がありました。この問題は、より現代的な並列ストレージアプローチを採用する上で、長い間障壁となっていました。ONTAP バージョン 9.1.1 以降、 FSx for ONTAP は、 クラスター間 (2 フェーズ) の整合性グループ をサポートしています。この問題を解決することで、ストレージの一貫性を確保しながら、ONTAP の複数のインスタンスにわたってアプリケーションを拡張できるようになりました。これにより、一貫性、瞬時で容量効率の高いクローン、レプリケーション、およびその他の多くの ONTAP 機能を維持しながら、スケーラビリティを大幅に向上させ、次の図に示すように、250 万を超える 8K ランダム IOPS と 64 GB/秒を達成できます。 図 1: IO の一貫性を確保しながら総合パフォーマンスをスケール EHR の本番環境データベースやその他の周辺環境で 250 万 IOPS が必要ない場合は、16 個の FSx for ONTAP サービスのスループットと IOPS をそれぞれ低いレベルに設定できますので、コストを大幅に削減できます。各 FSx for ONTAP の IOPS は、デフォルトで SSD ストレージ 1 GB あたり 3 IOPS ですが、容量に関係なく最大 160,000 IOPS をプロビジョニングすることもできます。各 FSx for ONTAP の DRAM キャッシュに存在するデータでは、読み取り IOPS のレベルがさらに高くなります。また、IOPS は動的に上下に変更できます。同様に、各 FSx for ONTAP のスループットは 128 MB/秒から 4 GB/秒まで動的に設定できます。プロビジョニングするパフォーマンスの量によってコストを制御できます。特定の総合パフォーマンスと容量レベルでは、複数の FSx for ONTAP を利用しても追加料金は発生せず、コストのペナルティなしで極めて高いスケーラビリティを享受できます。このコストモデルは、並列化によってコスト上の利点が得られないオンプレミス環境とは大きく異なります。 パフォーマンス設定の動的な特性について説明したので、2 種類の EHR デプロイメントの例に戻り、パフォーマンスを拡張しながらコストを最適化する方法を説明します。 クラウドベースの EHR 読み取り専用コピー オンプレミスで EHR を運用している組織が災害、悪意のある人物、またはランサムウェアのために追加の保護を必要とする場合、クラウドベースの EHR 資産の読み取り専用コピーを使用すると、オフサイトバックアップよりも迅速に回復できるだけでなく、他の高度なクラウドサービスを活用することもできます。EHR 環境では、クラウドに読み取り専用コピーを作成する方法が複数あります。次の図は、アプリケーション層やデータベース層のレプリケーションの使用方法を示しています。 図 2: EHR のレプリケーションによる読み取り専用コピー 次の図は、オンプレミスの NetApp ファイラーと、SnapMirror レプリケーションのアシスト役として FSx for ONTAP を組み合わせて活用する方法を示しています。AWS でヘルスケアアプリケーションをデプロイする場合は常に、信頼性の高い設計で AWS のベストプラクティスに準拠し、ヘルスケアワークロードの複数のグローバルコンプライアンスフレームワークと複雑なコンプライアンス要件に準拠している Landing Zone for Healthcare の利用を検討してください。オンプレミスのストレージ環境、リカバリの目標、計画に応じて、最適な読み取り専用アーキテクチャを選択してください。 図 3: NetApp SnapMirror による読み取り専用コピー いずれのシナリオでも、通常の運用中は、FSx for ONTAP を並列に複数用意することで、ランサムウェアイベントやその他の急増するユースケースで必要とされるよりもはるかに低い合計 IOPS とスループットに設定できることに注目してください。これにより、コストを抑えながら、オンデマンドでシームレスにパフォーマンスを向上できます。 クラウドベースの EHR 本番環境 FSx for ONTAP は、AWS で実行される完全な EHR 本番環境の基盤要素としても使用できます。オンプレミスの EHR 環境と比較すると、ハードウェアの更新サイクルが不要になり、総所有コスト (TCO) を削減しながら、中断のない従量課金制のスケーラビリティを実現できます。計画外の成長、合併、買収、または急増する要件に直面している医療機関は、AWS 上の FSx for ONTAP のスケーラビリティを活用してコストを管理しながら、同時に無数の高度なクラウドベースのヘルスケアアプリケーションの相互運用性を実現できます。 あらゆる EHR 本番環境の重要なコンポーネントは、災害復旧が可能な高可用性アーキテクチャです。AWS EHR FSx for ONTAP リファレンスアーキテクチャは、次の図に示すように、複数の アベイラビリティゾーン (AZ) (高可用性用) と複数の AWS リージョン (災害復旧用) を活用してこれを実現します。 図 4: 災害復旧機能を備えた高可用性の EHR 本番環境 本番環境リージョンでは、データベース、レポート、テストと開発、およびその他の統合された周辺アプリケーションが 1 つの AZ で実行されています。AZ 全体が使用できなくなる可能性は低いものの、FSx for ONTAP はマルチ AZ サービスとして構成されており、データの同期された独立したコピーが 2 つあるため (図には示されていませんが、各 AZ に 1 つのコピーがあります)、処理は 2 番目の AZ にフェイルオーバーできます。この構成により、オペレーションが大幅に簡素化されるとともに、災害を宣言することなく完全な単一 AZ 障害への対応を可能にします。 AWS リージョン全体が利用できなくなった場合は、災害が宣言され、セカンダリリージョンで処理が再開されます。上の図は、レプリケーションの 2 つの方法を示しています。いずれかまたは両方を使用して、目的の RPO/RTO を達成できます。ストレージ層のレプリケーション (FSx for ONTAP によって実行) は SnapMirror によって実行され、データベースレベルのレプリケーションはアプリケーションスタックによって実行されます。セカンダリリージョンにも FSx for ONTAP によって維持される 2 つの同期コピーがあり、レプリケートされたデータのコピーは合計 4 つあることに注目してください。コストを削減するために、セカンダリリージョンの FSx for ONTAP をはるかに低いパフォーマンスレベルに設定し、災害時またはテストのオンデマンド時にのみパフォーマンスを上げることを検討できます。たとえば、通常の運用中は、並列 FSx for ONTAP の合計パフォーマンスを 300,000 IOPS および 8 GB/秒に設定できます。 単一データベースサーバーのストレージパフォーマンス AWS の 200 Gbit 対応インスタンス が導入されて以来、クライアントネットワークを介して単一のインスタンスに最大 20 GB/秒、8K で 200 万 IOPS を超える FSx for ONTAP のパフォーマンスを集約することが可能になりました。これらのインスタンスは、 EBS 最適化 ネットワークを介して最大 8 GB/秒、350,000 IOPS にも対応しており、場合によっては、 EBS インスタンスストア と呼ばれる NVMe がローカルに接続されていることもあります。その結果、これらのインスタンスの合計ストレージパフォーマンスは 30 GB/秒を超える可能性があります。ただし、極端なスケールを必要とするストレージのデプロイメントでは、データベース用に FSx for ONTAP ブロックデバイスを使用し、一時データベース用に EBS ボリュームを使用することもあります。つまり、テーブルスペース操作の実質的な制限は 20 GB/秒です。一時データベースにインスタンスストアを使用すると、インスタンスに直接接続されたストレージが活用されるためレイテンシーが低くなり、最適化された EBS ボリュームと FSx for ONTAP ブロックデバイスのいずれの場合でもパフォーマンスが高まります。本番データベースを FSx for ONTAP ブロックデバイスに限定すると、FSx for ONTAP スナップショットと FlexClone の使用が可能になり、容量コストが大幅に削減され、Amazon EBS と FSx for ONTAP ベースのスナップショット間の一貫性の問題が回避されます。 集約されたストレージパフォーマンスの分析 ピーク時に 8K で 100 万 IOPS に達する EHR 本番環境のデータベースを考えてみましょう。これは、単一の 200 Gbit 対応クライアントから約 10 GB/秒を消費します。ONTAP 環境全体で 16 個の FSx を利用すると、合計読み取り能力は 64 GB/秒を超え、8K で 250 万 IOPS になります。この総合パフォーマンスの余裕により、他のインスタンスに接続された FlexClone をレポート、クエリ、バックアップ、テスト、開発、またはその他のアクティビティに使用しても、本番環境のパフォーマンスに影響を与えず、全体的なストレージパフォーマンスを低下させる可能性のあるデータ移動 (コピー) も発生しません。これらの AWS アプリケーションインスタンスを組み合わせると、合計で 50 GB/秒、200 万 IOPS を超えるストレージレベルのパフォーマンスが得られます。 まとめ このブログでは、FSx for ONTAP ブロックサービスを EBS と組み合わせて導入する独自の方法について説明しました。この方法では、電子健康記録アプリケーションのパフォーマンスニーズを満たしながら、現在世界最大規模の EHR 導入をはるかに超える拡張が可能です。クラウドの動的で従量課金の特性を活用してストレージレイヤーを最適化し、コストを制御して、EHR アプリケーションを中断したり意識させたりすることなくスケールアップとスケールダウンの両方が可能な環境を作成し、FSx for ONTAP の容量効率の高い FlexClone を活用できます。そのため、組織のストレージ要件が拡大または縮小しても、組織が遊休の資産にコストを支払う必要はありません。 従量課金制の経済性と FSx for ONTAP の高度なストレージ効率性の強力な組み合わせにより、AWS 上で構築された電子健康記録アプリケーション向けに、スケーラブルで信頼性が高く、高可用性、耐災害性を備えながらもコスト効率に優れたストレージソリューションを実現します。 EHR 環境向けに最適化されたストレージへの取り組みを今すぐ開始する方法については、 AWS for Healthcare and Life Sciences にアクセスするか、AWS HCLS の担当者にお問い合わせください。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修はソリューションアーキテクトの宮城が担当しました。 <!-- '"` --> Randy Seamans Randy はストレージ業界のベテランであり、高性能ストレージ、コンピューティング (HPC)、および災害復旧を専門とする AWS のプリンシパルストレージスペシャリスト兼アドボケートです。彼のストレージに関する洞察や楽しみをさらに知るには、https://www.linkedin.com/in/storageperformance で彼をフォローしてください。

はじめに 様々な業界の組織がカスタマーサービス能力の向上を目指す中、 Amazon Connect のようなクラウドベースのコンタクトセンターソリューションの導入は戦略的な優先事項として重要になっています。英国の大手銀行・金融サービスグループである NatWest Group にとって、Amazon Connect を活用したコンタクトセンターを通じて顧客体験を向上させることは、長期的な顧客のロイヤルティと競争優位性を推進する重要な取り組みでした。 しかし、このような大規模な導入に対して包括的な DevSecOps エコシステムの実装と管理することには、独自の課題がよく発生します。 NatWest はこの課題を認識し、Amazon Connect の導入に加え、コンタクトセンター変革の長期的な成功と回復力を確保するため、戦略的に堅牢な DevSecOps エコシステム構築の取り組みを開始しました。 この記事では、このような組織の豊富な経験とそこから得られた教訓、 NatWest の取り組みから得られた貴重な洞察とベストプラクティスを提供します。DevSecOps アプローチを採用することで、組織は効率的で安全性が高く、スケーラブルな顧客体験を提供し、業界における基準を確立することができました。 NatWest が直面した課題 企業全体で共有された Amazon Connect インスタンスの管理 : NatWest は、複数のビジネスユニットとチームにまたがる単一の共有 Amazon Connect インスタンスを導入することを選択しました。このアプローチはリソースの最適化と一貫性の面でメリットを提供しましたが、リソースの分離、リリース管理、チーム間のコラボレーションなどの領域で複雑な課題も発生しました 堅牢なセキュリティとコンプライアンス順守の確保 : 銀行・金融サービスを提供するグループとして、NatWest はコンタクトセンター業務における最高水準のセキュリティとコンプライアンスを維持する必要性を強く認識していました。機密性の高い顧客データの保護と業界規制の遵守のためには、包括的なセキュリティ戦略が最重要事項でした イノベーションのペースの加速 : 競争が激化し、スピードが求められる市場において、NatWest は Amazon Connect を活用したコンタクトセンターの新機能と能力を迅速に開発・展開する必要性を認識しています。組織は、進化する顧客の要求に対応するため、デプロイメントプロセスの最適化を目指しました 運用効率と一貫性の向上 : 複数のチームとビジネスユニットが共有の Amazon Connect インスタンスを活用する中、NatWest はコンタクトセンター環境全体での一貫性を維持することを目指しました。組織は、運用効率と俊敏性を向上させるため、重複した作業、サイロ化されたワークフロー、標準化の欠如に対処しようとしました NatWest のアプローチ NatWest は Amazon Connect の採用とともに、認識した課題に対し、プラットフォームのための包括的な DevSecOps エコシステムを実装する戦略的な取り組みを開始し、実装を完了しました。このアプローチは、顧客体験の向上、業務効率の推進、組織のセキュリティ体制の強化を目的として設計されました。 AWS プロフェッショナルサービスチーム と緊密に連携し、NatWest は主要な課題に対処する多面的なアプローチを実装しました。 環境分離戦略 NatWest の DevSecOps アプローチの中核となったのは、Amazon Connect インスタンスに対する明確に定義された環境分離戦略の実装でした。彼らは、サイロ化された複数インスタンスを用意するのではなく、組織全体のビジネスユニットで共有される単一の Amazon Connect インスタンスを持つことを選択しました。このアプローチにより、管理の一貫性の確保、リソースの利用の効率化が実現でき、チーム間の効果的なコラボレーションが可能になりました。 開発、テスト、本番環境を用意するため、NatWest は以下の環境構造を実装しました。 サンドボックス環境 : 開発者が他の環境に影響を与えることなく、Amazon Connect の機能を試験、探索、習熟するための専用の実験環境です 開発環境 : 新機能や設定の開発と初期テストに使用される個別の AWS アカウントです テスト環境 : 上位環境への変更を適用する前に、機能テストを含む包括的なシステム統合テストを行うための専用の AWS アカウントです 本番前環境 : 本番環境への展開前の最終検証ステップで、個別の AWS アカウントでホストされ、本番環境の設定を密接に反映した環境です 本番前災害復旧環境 : 事業継続性を確保するため、異なる AWS リージョンにデプロイされた本番前環境用の災害復旧環境です 本番環境 : 厳格なセキュリティ対策を備えた専用の AWS アカウントでホストされる、実稼働中の顧客向け環境です 本番災害復旧環境 : リージョンの停止時のバックアップとして機能する、異なる AWS リージョンにデプロイされたフェイルオーバー環境です 各環境を別々の AWS アカウントとリージョンに分離することで、NatWest は明確な責務の分離、セキュリティ強化、効率的なテストと災害復旧戦略を実現しました。この構成により、組織は Amazon Connect インスタンスを効果的に管理し、スムーズな開発ライフサイクル、堅牢なテスト、そしてコンタクトセンター運用の高可用性を確保することができました。 Infrastructure as Code (IaC) 戦略 NatWest は様々な事業部門が利用する共有の Amazon Connect 環境を持っています。このインフラストラクチャを管理するため、組織では IaC ツールとして Terraform を採用しています。画一的なアプローチではなく、NatWest はモジュール型の戦略を採用し、インフラストラクチャをより小さく管理しやすい単位で定義しています。 独立した管理のための分散型アプローチ このモジュール型アプローチにより、異なるチームが専用の Terraform コードリポジトリを使用して、それぞれのインフラストラクチャコンポーネントを独立して管理およびリリースすることができます。この分散型構造を採用することで、NatWest は単一のリポジトリの変更が広範な問題に発展するリスクを軽減することができました。さらに、この戦略によってリリースプロセスを高速化し、インフラストラクチャに導入される問題の潜在的な影響範囲が縮小できます。 意味を持ったリソース命名とタグ付け リソースの競合を防ぎ、チーム間での一貫性を確保するため、NatWest は独自のリソース命名とタグ付けの戦略を実装しています。組織のポリシーと標準に準拠しながら柔軟性を提供することが重要であるため、チームは Amazon Connect の共通のリソースタイプに対するカスタム Terraform モジュールを作成しています。 これらの独自のモジュールにより、一貫した命名規則、タグ付け基準、および事前定義されたポリシー（セキュリティ、コンプライアンスなど）への準拠を強制できます。これらのモジュールを活用することで、NatWest は異なるチームによって作成されたリソースであっても NatWest の Amazon Connect プラットフォーム全体が一貫したアプローチに従うことを確保しています。以下が Amazon Connect 用に定義された Terraform モジュールのリストです。 Amazon Connect AWS Lambda Amazon Lex Amazon DynamoDB その他の一般的なリソース：Amazon Simple Storage Service (S3)、AWS Identity and Access Management (IAM)、AWS Key Management Service (AWS KMS)、Amazon Kinesis このモジュール化された独自のアプローチは、チームによる独立したインフラストラクチャ管理を可能にするだけでなく、一貫性、ベストプラクティスへの準拠、組織のポリシーとの整合性を実現します。 デプロイ戦略 NatWest は、堅牢な IaC アプローチに加えて、Amazon Connect 内の重要なコンポーネントのデプロイプロセスも最適化しています。Amazon Lex ボットや Amazon QuickSight のアセットなどの主要リソースのデプロイ戦略を効率化することで、組織は新機能や性能の開発と提供を加速し、顧客に対してシームレスで一貫性のある体験を確保することができています。 Amazon Lex のデプロイ戦略 NatWest の Amazon Connect コンタクトセンターにおける顧客セルフサービスの重要な部分は、特に Amazon Lex V2 に焦点を当てた複数の Amazon Lex ボットの活用です。チームが迅速にこれらの Lex ボットを開発・デプロイできるようにするため、NatWest はエクスポートとインポートの CI/CD パイプラインを使用した自動デプロイ戦略を実装しています。 複雑な Amazon Lex ボットスキーマのデプロイ管理は、AWS CloudFormation のような従来の IaC ツールを使用すると、課題になる可能性があります。これらのツールに必要な YAML や JSON の定義は、すぐに扱いづらく保守が困難になる可能性があります。この課題に対処するため、NatWest は次のようなより効率的なアプローチを採用しました。 開発者は使いやすい Lex コンソールを使用して Amazon Lex ボットを作成・構築します ボットが十分にテストされた後、開発者はエクスポートパイプラインを活用してボットのスキーマをコードとして取得し、Git リポジトリに保存します 上位環境（開発、テスト、本番など）へのデプロイには、インポート CI/CD パイプラインを使用します。このパイプラインは Git リポジトリからボットスキーマを取得し、対象環境にボットをデプロイします このエクスポートとインポートのアプローチにより、手動での IaC コード作成の必要性を排除し、NatWest は Lex ボットのデプロイプロセスを効率化し、全体的な開発・デリバリーサイクルを加速することができました。 Amazon QuickSight のデプロイ戦略 NatWest はコンタクトセンター業務と並行して、データ駆動型の意思決定をサポートするため、ダッシュボードとレポートの作成に Amazon QuickSight を活用しています。複数の環境でこれらのアセットへの需要が高まるにつれ、QuickSight のアセットを手動でデプロイし管理することは、時間がかかり、エラーが発生しやすいプロセスであることが分かりました。 この課題に対処するため、NatWest は開発者が QuickSight コンソールを使用して QuickSight のダッシュボード、分析、データセット、データソースを迅速に構築およびカスタマイズできる戦略を定義しました。これにより、組織はエクスポートとインポートのパイプラインを活用して、これらのアセットを異なる環境間で迅速にデプロイしています。 NatWest における QuickSight アセットのデプロイメントプロセスは以下の通りです。 ユーザーは QuickSight コンソールを使用して、必要な QuickSight アセット（ダッシュボード、分析、データセット、データソース）を作成・カスタマイズします アセットの準備が整ったら、開発者は NatWest の QuickSight のパイプラインで統合された QuickSight エクスポート API を使用して、それらを JSON バンドルとしてエクスポートします エクスポートされた JSON バンドルは、ソースコードとしてバージョン管理システム（Git）に保存されます 異なる環境（開発、テスト、本番など）へのデプロイ時には、NatWest の QuickSight へインポートするパイプラインを通じ QuickSight インポート API を活用して、JSON バンドルをターゲットの QuickSight アカウントにデプロイします このアプローチにより、大規模な、あるいは複雑な QuickSight 構成で扱いづらくなる可能性がある、AWS CloudFormation や Terraform のようなツールによる複雑な IaC リソースを定義する必要性を回避できます。代わりに、エクスポートとインポートのパイプラインにより、NatWest は QuickSight アセットをコードとして扱い、バージョン管理に保存し、環境全体で一貫してデプロイすることができます。 QuickSight コンソールの使いやすさと自動化されたエクスポート・インポートパイプラインを組み合わせることで、NatWest は開発者の俊敏性を促進しながら、組織全体でデータの可視化と分析アセットの一貫性があり、信頼できるデプロイメントを確保できました。 セキュリティコントロール コンタクトセンター業務における機密性と顧客データの保護の必要性を考慮すると、セキュリティは NatWest にとって最も重要な関心事でした。これに対処するため、Amazon Connect を保護するための予防的および検知的な制御に重点を置いた包括的な DevSecOps セキュリティ戦略を策定しました。 予防的統制 NatWest は DevSecOps 全体で予防的なセキュリティ統制を実装する積極的なアプローチを取りました。 リソースの命名とタグ付けポリシー : 組織はインフラストラクチャの可視性と制御を向上させるため、一貫性があり、意味のあるリソース命名規則とタグ付け基準を実施しました セキュアな構成 : NatWest は独自の Terraform モジュールを活用して、Amazon Connect、AWS Lambda、Amazon Lex、その他のサービスを慎重に構成しました。これらのモジュールにはセキュリティのベストプラクティスと組織のポリシーが組み込まれており、インフラストラクチャが安全かつコンプライアンスに準拠した方法でデプロイされるように構成しました 静的コードスキャン : CI/CD パイプラインの一部として、NatWest は Terraform コード用の Checkov や Python コード用の Bandit などのセキュリティスキャンツールを用い、脆弱性と設定ミスの継続的なスキャンを実装しました AWS サービスコントロールポリシー : サービスコントロールポリシーを活用して、Amazon Connect インスタンスや Amazon Connect の問い合わせ記録、通話録音などの機密データの削除を拒否するなど、厳格なガードレールを実装し、特定のアクションを制限しました 発見的統制 予防的統制を補完するため、NatWest は以下を含む堅牢な発見的統制も実装しました。 AWS Config : NatWest は、標準・カスタム設定ルールの両方を使用して AWS Config を活用、リソースの設定を継続的に監視し、ドリフトや変更を検知しています Amazon Inspector : Amazon Inspector を有効にし、AWS Lambda 関数の脆弱性と設定ミスを定期的にスキャン、潜在的なセキュリティ問題に対処するための貴重な洞察を確認しています セキュリティ監視とアラート : Amazon CloudWatch や AWS Security Hub などのサービスを統合することで、包括的なセキュリティ監視とアラートのフレームワークを確立し、セキュリティインシデントの迅速な特定と対応を可能にしました 予防的統制と発見的統制を組み合わせたこの多層的な DevSecOps アプローチにより、NatWest のコンタクトセンター運営における強力なセキュリティ体制が確保されました。リスクを事前に軽減し、セキュリティインシデントをタイムリーに検知して対処することで、顧客のデータ保護を最高レベルで維持することができました。 開発とデプロイを高速化するツール群 NatWest は、Amazon Connect の開発とデプロイをさらに効率化するために、カスタマイズしたユーティリティとアクセラレーターを作成しました。これらには以下が含まれます。 コンタクトフローを Terraform テンプレートとして出力するツール NatWest が開発した主要なユーティリティの 1 つは、コンタクトフローのエクスポートツールでした。これにより、 Amazon Connect コンソールを使用して開発したコンタクトフローを Terraform テンプレートとしてエクスポート、ハードコードされた ARN を Terraform 変数に置き換えることができます。このユーティリティを活用することで、NatWest は以下を実現できました。 コンタクトフローを IaC として扱い、バージョン管理、環境間での一貫したデプロイを可能にしました Terraform テンプレートを直接適用し、ターゲット環境へのコンタクトフローのデプロイ時に手動設定を回避しました AWS Lambda 関数や Lex ボットなどの共通のコンタクトフローコンポーネントを Terraform 変数で参照することで、一貫性と再利用性を確保しました Contact Lens ルールのエクスポートとパイプライン内でのインポートツール コンタクトフロー管理ツールに加えて、NatWest は Amazon Connect Contact Lens ルールのエクスポートとインポートのパイプラインも作成しました。これにより、組織は Contact Lens ルールの設定をバージョン管理し、環境間で一貫してデプロイすることができ、会話分析に対する標準化されたアプローチを実現しました。 パフォーマンスメトリクスのレポート NatWest は、Amazon Connect コンタクトセンターの全体的なパフォーマンスの可視化を提供するために、カスタムレポートユーティリティを開発しました。これらのツールは、Amazon Connect、Amazon Lex、DynamoDB、AWS Lambda などの様々なソースからログとメトリクスを収集・分析し、包括的なパフォーマンスレポートを生成しました。これにより、組織はデータに基づく意思決定を行い、コンタクトセンター運営の効率性と信頼性を継続的に最適化することができました。 このカスタマイズされたツール群を活用することで、NatWest は Amazon Connect ベースのコンタクトセンターサービスの構築、テスト、デプロイに必要な時間と労力を大幅に削減し、最終的に組織全体の効率性と俊敏性を高めることができました。 実現した効果 Amazon Connect プラットフォームに包括的な DevSecOps エコシステムを実装することで、NatWest は主に以下のような効果が得られました。 標準化され一貫性のあるアプローチ : 複数の環境とビジネスユニットにわたる Amazon Connect リソースを管理するための標準化された一貫したアプローチを確立し、複雑さを軽減し、組織のポリシーとの整合性を確保しました セキュリティ体制の改善 : 予防的および発見的なセキュリティ統制の実装により、NatWest のコンタクトセンター環境の全体的なセキュリティを強化し、機密性の高い顧客データを保護しました 効率性と信頼性の向上 : 自動化されたデプロイメントと IaC の採用により、NatWest のコンタクトセンター運営の効率性と信頼性が向上し、組織は進化する顧客ニーズに迅速に対応できるようになりました リリースプロセスの効率化： NatWest は堅牢なテスト、検証、ロールバックメカニズムを実装し、コンタクトセンターへの新機能と機能の円滑で信頼性の高いデリバリーを確保しました 開発とデプロイの加速 : NatWest が開発した様々なデプロイメント戦略、ユーティリティ、アクセラレーターにより、Amazon Connect プラットフォームのコンポーネントの構築、テスト、デプロイに必要な時間と労力が大幅に削減されました まとめ Amazon Connect コンタクトセンターに包括的な DevSecOps エコシステムを実装することで、NatWest は効率的で安全でスケーラブルな顧客体験を責任もって提供することができました。 NatWest が採用した包括的な DevSecOps フレームワークにより、組織はコンタクトセンター運営のモダナイゼーションで直面する複雑な課題に対処することができました。Amazon Connect リソースを管理するための標準化された一貫したアプローチを確立することで、NatWest は複雑さを軽減し、セキュリティを改善し、コンタクトセンター運営の効率性と信頼性を向上させました。 さらに、Lex ボットと QuickSight アセットのエクスポート・インポートパイプラインの活用を含む、組織の革新的なデプロイメント戦略により、新機能の開発と提供が加速されました。カスタムビルドのユーティリティとアクセラレーターと組み合わせることで、NatWest のチームは進化する顧客ニーズにより俊敏に対応できるようになりました。 この包括的なガイドで説明した戦略とベストプラクティスは、自社のコンタクトセンター運営をモダナイズし、Amazon Connect の可能性を最大限に引き出そうとする組織にとって、貴重な参考事例となります。DevSecOps の考え方を取り入れ、AWS の幅広い機能を活用することで、企業は顧客満足度を向上させ、運用効率を改善し、堅牢なセキュリティ体制を維持することができます。 金融サービス業界が進化し続ける中、Amazon Connect における NatWest の DevSecOps の取り組みは、技術的なモダナイゼーションに対する包括的で顧客中心のアプローチによる変革を示しています。この記事では、コンタクトセンターの変革で同様の成功を目指す他の組織に役立つロードマップを提供しました。 筆者について Abhay Kumar は Natwest のエンジニアリング ディレクターです。コンタクトセンター プラットフォームのアーキテクチャ、開発、保守、品質、セキュリティを担当しています。 Prateek Guleria は Natwest の DevOps リードです。自動化の実行、CI/CD の開発と実装の監督、AWS プラットフォーム上のクラウドインフラストラクチャの維持を担当しています。 Krishanu Bhar は Natwest のシニアソリューションアーキテクトで、金融業界特有のニーズに合わせた安全で拡張性のある、コンプライアンスに準拠したクラウドソリューションの設計に注力しています。デジタルトランスフォーメーションを推進し、銀行業務を最適化するために AWS テクノロジーを活用することに情熱を注いでいます。 Anand Jumnani は英国を拠点とする AWS の DevOps コンサルタントです。 Alex Buckhurst は AWS の シニア Amazon Connect コンサルタントで、イノベーションと顧客中心の設計の構築に焦点を当てています。余暇には、スカッシュをプレイし、バーベキューの腕を磨き、家族との時間を大切にしています。 Wajahat Khan は英国を拠点とする AWS のシニア Amazon Connect コンサルタントです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 先週はDeepSeekの話題がホットな一週間でしたね。私自身もいろいろなお客さんから、DeepSeekに関してお問い合わせやご相談をいただきました。AWSとしては用途に応じて最適な精度・コスト・レイテンシを備えたモデルを選択して利用できたり、時には自分で開発・調達したモデルをデプロイして利用できることが大事だと考えており、さっそく DeepSeekモデルについても選択肢のひとつに加わりました 。 それでは、1 月 27 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「DeepSeek-R1 models now available on AWS」を公開 英語版の記事そのままですが、速報ということで取り上げます。世の中で注目されているDeepSeekモデルですが、AWSのAmazon BedrockやAmazon SageMaker AIで動作させることが可能になっています。昨年のre:inventで発表されたBedrock Marketplaceの仕組みを使ってDeepSeek-R1を組み込んだアプリケーションをホストしたり、SageMaker JumpStartで学習済みのDeepSeek-R1モデルを動かしてハンズオンの検証を行うなどができるようになっていますので、興味のある方はぜひトライしてみてください。 ブログ記事「Amazon Bedrock で DeepSeek-R1 Distilled Llama モデルをデプロイする」を公開 こちらはDeepSeekに関する和訳済みのブログ記事です。DeepSeek-R1をベースとして、Meta LlamaやQwenのアーキテクチャに基づく15-700億パラメータの蒸留モデルが公開されています。DeepSeek-R1-Distill-Llama-8BとDeepSeek-R1-Distill-Llama-70BについてはAmazon Bedrock Custom Model Import機能でインポートして利用できますので、その方法をご紹介するブログ記事です。 AWS生成AI国内事例ブログ: 東京海上日動システムズ株式会社様、LLMによるアプリケーションモダナイゼーションへの挑戦 東京海上日動システムズ様では、多くの基幹系システムをAWSに移行済みですが、一部はオンプレミスでの運用を継続しており、移行済みのシステムの多くはリフト&amp;シフトによるレガシーなアプリケーション構造のままとなっています。オンプレミスのサーバやEC2で稼働しているJavaアプリケーションをサーバレスアーキテクチャにモダナイズするために、生成AIを活用し効率化することにチャレンジされています。AWS Prototyping Programを活用することで素早く小規模なアプリケーションでの検証を実施、95%は生成AIによるコードで動作し、エラーの多くが単純な修正で解消できることが確認されました。次のチャレンジはひとつのパッケージで完結しないアプリケーションでのバリデーションチェックやエラーハンドリングとのことです。生成AIによるアプリケーションモダナイゼーションは興味深い分野ですので、同様の課題感をお持ちの方はぜひご一読ください。 ブログ記事「GraphRAG Toolkit の紹介」を公開 検索拡張生成(RAG)の精度や、質問への適合性を高めるため、グラフDBによる情報間の関係性を利用するGraphRAGというテクニックが知られています。この記事はグラフDBを活用したRAGワークフローの構築を容易にするPythonライブラリであるGraphRAG Toolkitの意義と使い方をご紹介するものです。 ブログ記事「AWSで実現する安全な生成 AI アプリケーション – OWASP Top 10 for LLM Applications 2025 の活用例」を公開 生成AIによるアプリケーションの安全性は、様々な企業や組織にとって重要な課題です。このブログ記事ではOWASP(Open Worldwide Application Security Project)が提唱する、LLMを組み込んだアプリケーションにおける主要な10のセキュリティ脅威をまとめたOWASP Top10 for LLM ApplicationについてAWSでアプリケーションを設計・開発する方が考慮すべきポイントやリスクシナリオを概説しています。 ブログ記事「金融業界における生成AI活用動向」 様々な業界で生成AIの可能性への期待が高まる中で、2024年は業務での実用を検討・開始する年となりました。この記事では、AWSで金融領域の事業開発担当者からみたAIの活用動向について、インタビュー形式でご紹介するものです。読み物として気軽に読めるようになっていますので、金融業界と関わりの深い方も、そうでない方も、ぜひご覧ください。 ブログ記事「デジタル庁主催の AI ハッカソンに参加しました」を公開 2024年11月にデジタル庁主催で「AIハッカソン、アイデアソン」が開催されました。AWSのエンジニアチームとしてもこの取り組みに参加させていただきましたので、考案したソリューションについてご紹介するブログ記事です。 ブログ記事「生成AIとデータによる小売体験の刷新」 他業界でもそうですが、小売業や消費財業界ではデジタルトランスフォーメーションの重要性が一段と高く叫ばれています。この記事では、生成AIによってどういった変革が可能になるのかを紹介しています。 サービスアップデート Amazon SageMaker Unified Studioのプレビュー可能リージョンを7箇所追加 Amazon SageMaker Unified Studioはデータ・アナリティクス・AIに関するコラボレーションやデータを扱う処理の素早い構築を可能にする統合環境です。今回、新たに7つのリージョン(ソウル、シンガポール、シドニー、フランクフルト、ロンドン、サンパウロ、カナダ(中央))でプレビューが可能になりました。 Amazon Q in QuickSightのDashboard Q&amp;A機能を発表 Amazon Q in QuickSightでDashboard Q&amp;A機能がご利用いただけるようになりました。ダッシュボードにおいて、データに関するQ&amp;Aに応答する機能をワンクリックで追加でき、ダッシュボードのユーザがデータに関する疑問を持った際にセルフサービスで解決するために役立ちます。 Amazon Q Developer Agentが生成したコードに対するビルドとテストのリアルタイム実行に対応 Amazon Q Developer Agentがアップデートされ、生成したコードを開発者がレビューする前にビルドやテストを行うスクリプトを実行できるようになりました。Amazon Qが生成したコードを開発者がチェックする前に、指定されたビルドやテストを自動実行しそれにパスしたものだけを開発者に提示することで、開発者に対してより精度の高いコードが提示される可能性が高まる機能です。 Amazon Q Developer Pro Tierで新規登録ユーザに対する通知メールの自動送信に対応 Amazon Q Developer Pro Tierで新規登録されたユーザに対して自動的にメール通知が行われるようになりました。このメールは24時間以内に送信され、開発者がAmazon Q Developerを利用する上で重要な情報が含まれており、管理者の手間を省くことにつながります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 注目のアップデートがあり冒頭で紹介します。中国 AI スタートアップ企業の DeepSeek が公開した DeepSeek-R1 モデルや、DeepSeek-R1 をベースとした蒸留モデルを AWS 上にデプロイが出来るようになりました。現時点で 4 つの方法があります。 1. Amazon Bedrock Marketplace で DeepSeek-R1 モデルを利用 2. Amazon SageMaker Jumpstart で DeepSeek-R1 モデルを利用 3. Amazon Bedrock の Custom Model Import で DeepSeek-R1-蒸留モデルを利用 4. EC2 の Trn1 インスタンスで DeepSeek-R1-蒸留モデルを利用 詳細は こちらのブログ で紹介されております。ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月27日週の主要なアップデート 1/27(月) AWS User Notifications で新機能の AWS Managed Notifications を提供開始 AWS User Notifications の新機能である AWS Managed Notifications の一般提供を開始しました。AWS Health から通知されるメッセージについて、通知先の管理や変更が簡単になります。例えば、セキュリティに関する通知はセキュリティチームのメーリングリストに送付し、料金に関しては管理者のメーリングリストに送付する、といった設定が可能です。メール以外にも、スマートフォンへのプッシュ通知や、Slack や Teams といったチャットを送信先として設定できます。 Amazon EKS マネージドノードグループで新しい minimal アップデート戦略を導入 Amazon EKS のマネージドノードグループで、従来の default に加えて、新しい minimal アップデート戦略を導入しました。アップデート戦略は、更新作業でノードを入れ替える際の動作を指定できます。新しい minimal は、需要の高い GPU 付きの EC2 インスタンスや、Reserved Instance でキャパシティ予約を行っている環境などでメリットがあります。新しいノードを作成する前に古いノードを終了するため、総キャパシティが設定した量を超えることがなく、リソースやコストに制限のある環境で利用しやすいです。詳細は こちらの AWS Document をご覧ください。 Amazon S3 メタデータの一般提供を開始 Amazon S3 メタデータの一般提供を開始しました。S3 Bucket に保存しているデータの種別をメタデータとして付与することで、必要なデータを発見しやすくなるメリットがあります。サイズやオブジェクトソースなどのシステム的なメタデータや、業務内で利用する、製品 SKU、トランザクション ID、コンテンツ評価などのカスタムメタデータの付与ができます。Amazon Athena、Amazon Data Firehose、Amazon EMR、Amazon QuickSight、Amazon Redshift などの AWS 分析サービスを使用して、S3 メタデータテーブルの可視化やクエリーが可能です。 詳細はこちらのブログ をご覧ください。 1/28(火) AWS Amplify がサーバーサイドの AWS Lambda 関数で TypeScript データクライアントの使用をサポート AWS Lambda 関数内で Amplify データクライアントを使用できるようになりました。この新機能により、フロントエンドアプリケーションで使用する時と同様に、型安全なデータ操作を Lambda 関数内で直接利用でき、生の GraphQL クエリを記述する必要がなくなります。これにより、開発時間が短縮でき、エラーが最小限に抑えられ、コードベースの保守性が向上します。 1/29(水) Amazon Redshift がクエリ監視と診断を改善するための強化されたクエリモニタリングを提供開始 Amazon Redshift で、パフォーマンスのボトルネックを効率的に特定し改善に活かせる、強化されたクエリモニタリング機能を提供開始しました。トレンド分析のためのパフォーマンス履歴の表示、ワークロードの変更の検出、時間の経過に伴うクエリパフォーマンスの変化の理解、クエリプロファイラーによるパフォーマンスの問題の診断などがやりやすくなります。 1/30(木) Amazon SES Mail Manager が大阪リージョンを含めた新しいリージョンで提供開始 SES Mail Manager が、大阪リージョンを含む、11 個の新しいリージョンで利用が可能になりました。Mail Manager は組織内でメールを送受信する際に、コンプライアンスを一元的に管理できる機能セットです。例えば、DKIM が Pass になったメールのみ受信する、Trend Micro Virus Scanning と連携しウイルススキャン後にメールを受信する、といったルール管理が可能です。 SES Mail Manager がアドレスとドメインリストのサポートを追加 SES Mail Manager が既知のアドレスと未知のアドレスを区別するために、定義済みのメールアドレスとドメインリストをサポートしました。この機能により、Mail Manager を利用してメールを送受信する際に、誤入力されたメールアドレスや、ディレクトリハーベスティング攻撃、すでに信頼しているドメインなどをルールエンジン上で識別でき、必要に応じたセキュリティのアクションを指定できます。 Amazon Lex のアシスト付きスロット解決機能を東京リージョンを含めた新しいリージョンで提供開始 Amazon Lex のアシスト付きスロット解決機能の提供リージョンを拡大しました。東京リージョンを含む 10 リージョンで利用可能です。アシスト付きスロット解決機能は、Amazon Bedrock と連携することで、お客様との会話で精度向上のメリットがあります。例えば、「レンタル契約の期限はいつですか?」という質問に対して、お客様が「リースは来月 1 日に期限切れになります。」と回答したときに、生成 AI 機能を活かして 2025-02-01 といった内容の理解を試みるものです。 詳細はこちらのドキュメント をご覧ください。 Amazon Timestream for InfluxDB でストレージスケーリングをサポート Amazon Timestream for InfluxDB で、ストレージスケーリング機能を提供開始しました。割り当てられたストレージをスケーリングし、ストレージ階層を変更することが可能になります。より高速で性能の高いストレージ階層に移行したり、割り当てられたストレージ容量を拡張したりすることで、データ取り込み、クエリ量、その他のワークロードの変動に素早く対応できます。 CloudWatch Database Insights が OS プロセスの履歴スナップショットをサポート CloudWatch Database Insights が、データベースで実行されているオペレーティングシステム (OS) プロセスの履歴スナップショットの分析をサポートするようになり、データベースの負荷状況と OS プロセスを紐づけた分析がやりやすくなります。この新機能では、実行プロセスがデータベース上のシステムリソースをどのように使用しているかを DBA が理解するのに役立ち、OS プロセスメトリクスとデータベース負荷を簡単に関連付けることができます。OS プロセススナップショットは、Database Insights が利用可能なすべてのリージョンで、Aurora PostgreSQL と Aurora MySQL の両方で利用できるようになりました。 1/31(金) Amazon EBS でスナップショットから EBS を作成する際のリソースレベルのアクセス許可をサポート Amazon EBS で、スナップショットから EBS ボリューム作成時にリソースレベルのアクセス許可をサポートするようになりました。例えば、EBS スナップショットに機密性の高いデータが存在しているときに、特定の Organizations や AWS アカウントに存在する EBS スナップショットのみの利用を制限することが可能です。 詳細はこちらのブログ をご確認ください。 AWS Glue で新たに 14 個のコネクタを提供開始 AWS Glue で新たに、アプリケーション用途の 14 個のコネクタを提供開始しました。Blackbaud Raiser’s Edge NXT、CircleCI、Docusign Monitor、Domo、Dynatrace、Kustomer、Mailchimp、Microsoft Teams、Monday、Okta、Pendo、Pipedrive、Productboard、Salesforce Commerce Cloud からデータを取り込むことが可能です。コネクタごとに行う設定や制限事項などが AWS Document にまとめられております。 AWS Transfer Family web apps で、大阪を含めたリージョンの拡張 AWS Transfer Family web apps で、大阪リージョンを含む、20 個の新しいリージョンで利用が可能になりました。AWS Transfer Family web apps は、ウェブブラウザを通じて Amazon S3 のデータにアクセスができるインターフェースを提供します。S3 のデータの閲覧、アップロード、ダウンロードなどが可能な画面を利用可能です。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

AWS re:Invent 2024 で事前に発表したように、 Amazon Bedrock の Luma AI Ray2 動画モデル を使用して、テキストから高品質の動画クリップを生成できるようになりました。静的なコンセプトから魅力的なモーショングラフィックを作成していただけます。AWS は Luma AI のフルマネージドモデルを提供する、最初かつ唯一のクラウドプロバイダーです。 2025 年 1 月 16 日、 Luma AI は Luma Ray2 を発表しました。これは、テキストによる指示を深く理解した上で、一貫性のある自然な動きを使用してリアルなビジュアルを作成できる、大規模な動画生成モデルです。Luma Ray2 は、Luma の新しいマルチモーダルアーキテクチャでトレーニングを受けた結果、高度な機能を発揮するようになりました。Ray1 の 10 倍の計算量までスケールできるため、540p と 720p の解像度で、一貫性のある高速な動き、非常にリアルなディテール、論理的なイベントシーケンスを表示する 5 秒または 9 秒の動画クリップを作成できます。 Luma Ray2 in Amazon Bedrock を使用すると、 生成 AI アプリケーションのテキストから生成された、すぐに使える高品質でリアルな動画を、単一の API を介して追加できます。Luma Ray2 動画モデルは、人、動物、物体の相互作用を理解します。また、最先端の自然言語による指示の理解と推論を通じて、一貫性のある物理的精度が高いキャラクターを作成できます。 Ray2 動画生成は、コンテンツ制作、エンターテインメント、広告、メディアのユースケースに使用することができ、コンセプトから実行までのクリエイティブプロセスを合理化します。各シーンの意図する感情に沿った、映画のようになめらかでリアルなカメラの動きを生成できます。さまざまなカメラアングルやスタイルをすばやく試して、建築、ファッション、映画、グラフィックデザイン、音楽などのクリエイティブなアウトプットを生み出すことが可能です。 Luma が公開している Luma Ray2 の 印象的な動画生成 をご覧ください。 Amazon Bedrock での Luma Ray2 モデルの開始方法 Luma モデルを初めて使用する場合は、使用を開始する前に Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択してください。最新の Luma AI モデルにアクセスするには、Luma AI で Luma Ray2 へのアクセスをリクエストしてください。 Amazon Bedrock で Luma AI モデルをテストするには、左側のメニューペインの [プレイグラウンド] で [画像/動画] を選択します。 [モデルを選択] を選択し、カテゴリとして [Luma AI] を選択し、モデルとして [Ray] を選択します。 動画生成モデルには、生成されたすべての動画を保存するための Amazon Simple Storage Service (Amazon S3) バケットが必要です。このバケットはお客様の AWS アカウントで作成され、Amazon Bedrock にはそのバケットに対する読み取りおよび書き込み許可が付与されます。 [確認] を選択してバケットを作成し、動画を生成します。 ここではプロンプト用に、720P、24フレーム/秒、アスペクト比 16:9 の 5 秒の動画を生成します。 プロンプトと生成された動画の例を次に示します。これを S3 バケットに保存してダウンロードできます。 宇宙粒子の中を泳ぐザトウクジラ Ray2 モデルでできることを示す、もう 1 つの注目の例を次に示します。 プロンプト 1: ミニチュアの子猫が人間の指先の表面を歩いたり探検したりしている プロンプト 2: 逆光に照らされた森に浮かぶ巨大な水の球 プロンプト 3: サックスを演奏する男性 (作成者: @ziguratt ) プロンプト 4: 受粉中のミツバチのマクロクローズアップ その他の例と生成された動画を確認するには、 Luma Ray2 ページをご覧ください。 また、Bedrock コンソールで [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。 luma.ray-v2:0 をモデル ID として使用できます。 AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id luma.ray-v2:0 \ --region us-west-2 \ --body "{\"modelInput\":{\"taskType\":\"TEXT_VIDEO\",\"textToVideoParams\":{\"text\":\"a humpback whale swimming through space particles\"},\"videoGenerationConfig\":{\"seconds\":6,\"fps\":24,\"dimension\":\"1280x720\"}},\"outputDataConfig\":{\"s3OutputDataConfig\":{\"s3Uri\":\"s3://your-bucket-name\"}}}" invoke-model-output.txt Converse API サンプル を使用し、 AWS SDK を活用して動画を生成し、さまざまなプログラミング言語を使用してアプリケーションを構築できます。 今すぐご利用いただけます Luma Ray2 動画モデルは、1 月 16 日、米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で一般公開されています。今後の最新情報については、 詳細なリージョンリスト をご確認ください。詳細については、 Luma AI in Amazon Bedrock 製品ページと Amazon Bedrock の料金 ページをご覧ください。 Amazon Bedrock コンソール で Luma Ray2 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

本記事は 2025 年 1 月 10 日に公開された “ Unlocking AWS Console: Diagnosing Errors with Amazon Q Developer ” を翻訳したものです。 はじめに 開発者や IT 運用者、場合によってはサイト信頼性エンジニア（SRE）は、インフラストラクチャとアプリケーションのデプロイと運用、そしてインシデントへの効果的かつタイムリーな対応と解決を担当しています。効果的なインシデント管理には、迅速な診断、根本原因の分析、そして是正措置の実施が必要です。分散環境に複数のリソースがデプロイされている現代のシステムにおいて、根本原因の診断は困難な場合があります。生成 AI を活用したアシスタントである Amazon Q Developer は、 AWS マネジメントコンソールで表示されたエラーを診断することで、このインシデント管理のプロセスの簡素化を支援できます。 Amazon Q Developer は、AWS 環境に関連する エラーの診断 を支援することで、本番環境の問題に対処する際の貴重な時間を節約できます。これらのエラーは、複数のリソースにまたがる設定ミスが原因である可能性があり、通常、根本原因を特定するために複数の AWS サービスコンソールの画面を行き来する必要があります。Amazon Q Developer は生成 AI を使用して、 AWS コンソールで発生するエラーの診断を自動化します。これにより、修復までの平均時間（MTTR）が短縮され、ビジネス活動・事業運営へのインシデントの影響を最小限に抑えることができます。 このブログ記事では、サポートされている AWS サービスを使用する際に、 Amazon Q Developer が AWS コンソールのエラーの診断 をどのように支援できるかを紹介します。この機能の仕組みを説明し、トラブルシューティングのガイダンスを提供します。また、この機能を支える処理の裏側も見ていきます。 Amazon Q による診断 Amazon Q による診断の機能は、 現在この機能でサポートされている AWS サービス のコンソールで発生する一般的なエラーのほとんどの診断に役立ちます。この機能は、 適切な権限 を持つユーザーがエラーメッセージの横にある「 Diagnose with Amazon Q 」（Amazon Q で診断）ボタンをクリックすると有効になります。 Amazon Q は、エラーの根本原因を分析し、自然言語で説明を提供します。「 Help me resolve 」（解決を手伝って）ボタンをクリックすると、 Amazon Q はエラー状態を解決するための手順を順序立てて表示します。完了後、 Amazon Q が提供した解決策が役立ったかどうかのフィードバックを提供できます。 Amazon Q Developer が Amazon EC2 インスタンス起動エラーの診断を支援し、エラー解決のための手順のガイダンスを提供する方法を示す実行例はこちら: Amazon Q による診断：EC2 インスタンス起動エラーに関連する IAM 権限 処理の裏側：Amazon Q が診断を生成する仕組み 概念を説明するために、2つの実践的な例を用いて説明します。 例1: 空ではない Amazon S3 バケットを削除しようとした場合。以下のエラーメッセージが表示されます: This bucket is not empty. Buckets must be empty before they can be deleted. To delete all objects in the bucket, use the empty bucket configuration. （※訳者注: このバケットは空ではありません。バケットを削除するには、事前に空にする必要があります。バケット内のすべてのオブジェクトを削除するには、バケットを空にする設定を使用してください。） 例2: 特定の S3 バケット内のオブジェクトを一覧表示しようとしたが、そのための AWS Identity and Access Management (IAM) 権限がない場合。以下のエラーメッセージが表示されます: Insufficient permissions to list objects. After you or your AWS administrator has updated your permissions to allow the s3:ListBucket action, refresh the page. Learn more about Identity and access management in Amazon S3. （※訳者注: オブジェクトを一覧表示するための権限が不足しています。あなたまたは AWS 管理者が s3:ListBucket アクションを許可するように権限を更新した後、ページを更新してください。 Amazon S3 のアイデンティティとアクセス管理についての詳細はこちら。） AWS マネジメントコンソールでエラーメッセージの横にある「 Diagnose with Amazon Q 」（Amazon Q で診断）ボタンをクリックすると、 Amazon Q はエラーの根本原因を自然言語で説明する Analysis （分析結果）を生成します。このステップは 大規模言語モデル (LLM) によってサポートされています。 LLM に提供されるコンテキスト情報には、コンソールに表示されるエラーメッセージ、トリガーとなるアクションの URL、 AWS コンソールにサインインしているユーザーの IAM ロールが含まれます。この機能は、常にコンソールでの操作時に付与されたロールの権限内で動作し、付与された権限を超えて動作することはありません。 分析結果を確認した後で「 Help me resolve 」（解決を手伝って）ボタンをクリックすると、 Amazon Q はエラーが発生した AWS アカウントのリソースの状態に関する追加情報を取得します。この段階で、システムは不足している情報を能動的に判断し、情報の不足を補うために、各サービスに対して情報の取得リクエストを発行します。上記の例1のような単純なエラーでは照会は必要ありませんが、コンテキストからの情報が不十分な、より複雑なエラーを解決するためには不可欠です。 コンテキスト、エラー分析、ユーザー権限、およびアカウント内部への問い合わせ結果を考慮して、 Amazon Q はステップバイステップの Resolution （解決手順）を生成します。このステップも LLM によってサポートされています。 コンソールでエラーを解決するために Amazon Q が提供した手順を実装し検証した後、エラー解決の体験についてフィードバックを提供することができます。 ユーザー、 AWS コンソール、および Amazon Q Developer 間の相互作用を示す図 コンテキスト情報 コンテキスト情報は、 LLM がより関連性の高い、十分な情報に基づいた出力を生成するのに役立ちます。コンテキストは、コンソールから Amazon Q に入力として自動的に提供されます。コンテキストはすべての分析と判断のための基礎として、できるだけ豊富な情報であるべきです。最低限、 Amazon Q はエラーメッセージ、トリガーとなるアクションの URL、およびサインインしているユーザーが引き受けている IAM ロールを取得します。システムはコンテキストから関連する識別子を自動的に抽出します。例1では、 URL が https://s3.console.aws.amazon.com/s3/bucket/my-bucket-123456/delete?region=us-west-2 である場合、 Amazon Q は aws_region = "us-west-2" と s3_bucket_name = "my-bucket-123456" を抽出します。 この最小限のコンテキストの他にも、Amazon Q はエラーが発生した時点でユーザーが画面上で見ているもの、たとえば現在の UI のテキストフィールドやウィジェットの内容など、コンソールから追加情報を取得できます。また、基盤となるサービスが提供する特定のコンテキストも利用できます。上記の例2の場合、バケット名は URL から、アクション s3:ListBucket はエラーメッセージから抽出されます。さらに、Amazon Q は IAM から関連するポリシーや許可・拒否ステートメントに関する追加情報を取得することもあります。 サインインしているユーザーアカウントの照会 Amazon Q による診断の機能は、単にコンテキスト情報を受動的に受け取るだけではありません。能動的に追加情報を要求する機能が組み込まれています。Amazon Q は、変更を加えない読み取り専用の問い合わせクエリを実行し、AWS アカウント内のリソース、それらのリソースの状態、およびエラーが発生している特定のリソースとの関係についてのより多くのコンテキストを収集するために使用されます。この関係についてのコンテキストを LLM に提供することで、エラーの診断における根本原因分析の精度が向上します。 Amazon Q は AWS Cloud Control API (CCAPI) を使用してサインインしているユーザーアカウントを照会し、アカウントで現在プロビジョニングされているリソースを検索します。 Amazon Q を利用する際、ユーザーが引き受ける IAM ロールに AmazonQFullAccess マネージドポリシー が添付されます。このマネージドポリシーには、 CCAPI の読み取りおよびリストのエンドポイントへのアクセスを提供する cloudformation:ListResources および cloudformation:GetResource の CCAPI IAM 権限が含まれています。 AmazonQFullAccess マネージドポリシーを添付したくない場合は、 cloudformation:ListResources および cloudformation:GetResource アクションを IAM ロールに直接追加できます。 例1 は空でない S3 バケットが原因でエラーが発生する単純なケースなので、エラーメッセージとコンソール URL に必要な情報がすべて含まれており、 AWS アカウントの能動的な照会は必要ありません。一方、例2の IAM 権限エラーの場合、エラーが発生しているリソースに関連する IAM ロールの権限を理解する必要があります。 Amazon Q は、ロールのアイデンティティレベルのポリシーと影響を受けるリソースのリソースレベルのポリシーを取得でき、それに基づいて内部 IAM サービスを使用してエラーの原因を診断できます。具体的には、例2の URL は https://s3.console.aws.amazon.com/s3/buckets/my-bucket-123456?region=us-west-2&amp;bucketType=general&amp;tab=objects のようになり、 Amazon Q はそこからリージョンと S3 バケット名を抽出します。また、エラーメッセージ自体から s3:ListBucket アクションを抽出することもできます。この情報をもとに、 Amazon Q は my-bucket-123456 のバケットポリシーや、ロールに適用されているアイデンティティレベルのポリシーを取得し、それらをスキャンして s3:ListBucket アクションの認可・不認可を確認したり、内部 IAM サービスを呼び出してアクセスが拒否された原因に関する追加情報を取得したりできます。 Amazon Q は、サインインしているユーザーのロールによって付与された権限の範囲内でのみ動作し、権限がユーザーの IAM ロールに割り当てられているものを超えて特権が昇格されることはありません。Amazon Q は、サインインユーザーの IAM ロールによって許可された権限を使用して CCAPI を呼び出します。 CCAPI はサインインユーザーの権限を引き継ぎ、ユーザーのアカウント内のリソースを照会できるのは同じレベルのアクセス権限内に限られます。たとえば、例2ではサインインしているユーザーが my-bucket-123456 のバケットポリシーにアクセスする権限を持っていない場合、 Amazon Q もアクセスできません。そして、すべての API 呼び出しは CloudTrail に記録 されます。これには、 Amazon Q による CCAPI の呼び出しや、 CCAPI がリクエストに応じてエンドサービス（例：S3、IAM）を呼び出す処理も含まれます。 ステップバイステップの解決手順の生成 Amazon Q は収集したすべての情報を統合し、有用で実行可能な解決手順を生成します。例として、検討中の例に対する可能なサンプル手順を以下に示します。モデルは時間とともに更新・改善されるため、応答は変更される可能性があります。 例1の場合のサンプル手順: S3 コンソールに移動し、「バケット」をクリックして、 my-bucket-123456 バケットを選択します 「空にする」ボタンをクリックします バケットに大量のオブジェクトが含まれている場合、ライフサイクルルールを作成してバケット内のすべて オブジェクトを削除する方が、より効率的な方法かもしれません テキスト入力フィールドに「完全に削除」と入力し、すべてのオブジェクトを削除することを確認します my-bucket-123456 S3 バケットの削除を再試行します 例2の場合のサンプル手順: IAM コンソールに移動します。 ReadOnly ロールに添付されている IAM ポリシーを編集します S3 バケット ARN arn:aws:s3:::my-bucket-123456 に対して s3:ListBucket アクションを許可します 更新された IAM ポリシーを保存します S3 コンソールページを更新して、バケット my-bucket-123456 内のオブジェクトを一覧表示します 手順には、プレースホルダーの代わりに、バケット名 my-bucket-123456 のようなコンテキストから推測された情報が含まれていることに注意してください。 Amazon Q による診断で返される手順は、追加の労力なしに実行できるよう、完全かつ詳細に記述されています。実際、このサービスは LLM を使用して解決手順を生成しますが、Amazon Q は後処理を行い、よくある誤りを修正します。例えば、上記の例 2 では、LLM が arn:aws:s3:&lt;region&gt;::&lt;bucket_name&gt; という形式で ARN を返した場合、それを適切な形式へ修正します。 上記の例2で返される手順は、ユーザーがオブジェクトを一覧表示できない原因が、 ReadOnly ロールにアタッチされているポリシーに Allow ステートメントがないことであると仮定しています。その他の根本原因として、 S3 バケットや ReadOnly ロールに添付されているポリシーの Deny ステートメントなどが考えられます。 Amazon Q による診断では、アカウントの照会を使用して正しい根本原因を特定し、適切な解決策を提案できます。上記の例では、 ReadOnly ロールにアタッチされているポリシーを取得して s3:ListBucket が実際に欠けているかどうかを確認したり、バケット bucket-123456 にアタッチされているポリシーを取得したりできます。 検証 Amazon Q による診断の目標の1つは、エラーが発生した場所で有用かつ実行可能なアドバイスを得られるよう、高い品質基準を維持することです。この目標を達成するためには、堅牢で柔軟な評価システムが重要な前提条件となります。生成 AI に基づくシステムの評価は、出力が自然言語であることによる広大な表現の可能性や、非決定的な動作といった特徴があるため、特有の課題があります。 簡単に言えば、私たちの検証システムは、各レコードが一定数のアノテーションを持つ大規模なエラーデータセットの構築に基づいています。各レコードには、テンプレート化されたエラーメッセージとコンソール URL（例えば、 bucket-123456 は {{s3_bucket_name}} に、 us-west-2 は {{aws_region}} に置き換えられたもの）が含まれています。アノテーションには、エラーのあるアカウントの状態とトリガーとなるアクションを記述した Infrastructure as Code（CloudFormation）の定義、および専門家による正解の応答データが含まれます。これらのレコードを活用することで、人間の介入なしに、システムのさまざまなバージョンの動作をシミュレーションでき、並列処理によってリアルタイムよりもはるかに高速に実行できます。また、Ground truth アノテーションとシステムの応答を比較する自動評価指標の開発も進めており、これに基づいて完全自動のオフライン評価を実施できるよう取り組んでいます。 この検証システムにより、新しいアイディアを現在の状態と比較しながら迅速に検証でき、さらに機能の低下も防ぐことができます。エラーレコードのアノテーションを入力するために専門家はまだ必要ですが、私たちはこの作業の効率化と簡素化を積極的に進めています。そのために、自然言語の手入力を避け、検証機能を組み込み、専門家が一から正解のアノテーションを入力するのではなくシステム出力を修正する形でアノテーションツールを構築しています。 まとめ Amazon Q Developer の「Amazon Q による診断機能」を使用すると、複数のサービスコンソール間を移動することなく、AWS コンソールでのエラーの原因を特定できます。AWS アカウントとエラーコンテキストに特化したきめ細かなステップバイステップの手順を提供することで、Amazon Q Developer は効率的なトラブルシューティングと問題解決を支援します。これにより、組織の運用効率の向上、ダウンタイムの削減、サービス品質の改善が実現し、貴重な人的リソースを解放して、より価値の高い活動に集中できるようになります。また、この機能を実現するために AI と機械学習の機能によって処理の裏側がどのように機能しているかについての詳細についてもご紹介しました。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Matthias Seeger Matthias Seeger は AWS の Principal Applied Scientist です。彼は確率モデルを用いたベイズ学習と意思決定、ガウス過程モデルの理論と実践、確率的予測、そして最近では大規模言語モデルと関連するデータ作成およびアノテーションの課題に関心を持っています。 Marco Frattallone Marco Frattallone は、パートナー支援に重点を置く AWS の Senior Technical Account Manager です。パートナーと緊密に協力し、 AWS 上でのソリューションの構築、デプロイ、最適化を支援し、ガイダンスを提供してベストプラクティスを活用しています。 Marco はテクノロジーに情熱を持ち、パートナーがイノベーションの最前線に立ち続けるよう支援しています。仕事以外では、アウトドアサイクリング、セーリング、新しい文化の探索を楽しんでいます。 Surabhi Tandon Surabhi Tandon は Amazon Web Services (AWS) の Senior Technical Account Manager です。戦略的な技術ガイダンスを提供することで、エンタープライズのお客様の運用の優れた実践の達成と AWS でのクラウドジャーニーを支援しています。 Surabhi は生成 AI 、自動化、 DevOps に関心を持つビルダーです。仕事以外では、ハイキング、読書、家族や友人との時間を楽しんでいます。

本記事は 2025 年 1 月 14 日に公開された AWS CDK is splitting Construct Library and CLI を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 AWS CDK は、クラウドインフラストラクチャをコードで定義し、 AWS CloudFormation を通じてプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK は主に 2 つのコンポーネントで構成されています。AWS CDK CLI と、AWS アプリケーションをモデル化するためにプログラミング言語から使用する CDK コンストラクトライブラリです。CDK コンストラクトライブラリはアプリケーションのモデルをローカルのディレクトリに「合成」し、AWS CDK CLI はそのディレクトリのファイルを読み取って AWS にアプリケーションをデプロイします。 2025 年 2 月より、AWS CDK CLI と CDK コンストラクトライブラリは同時リリースではなくなります。代わりに、それぞれが独自のリリースサイクルを持つようになり、バージョン番号も異なるものとなります。AWS CDK で利用する API やユーザーエクスペリエンスへの影響はありません。 これは AWS CDK の動作方法や AWS CDK の使用方法を根本的に変更するものではありません。最新バージョンの AWS CDK CLI は、それ以前の過去にリリースされたすべてのバージョンの CDK コンストラクトライブラリをサポートし続けます。ユーザーは引き続きいつでも自由に AWS CDK CLI を最新バージョンにアップグレードすることができます。この変更による最大の違いは AWS CDK CLI と関連コンポーネントのソースコードが新しい GitHub リポジトリに移行されることです。新しいリポジトリは https://github.com/aws/aws-cdk-cli (訳註: 2025-02-03 時点ではアクセス不可) となり、移行完了後に一般公開される予定です。 新しいバージョニング体系での AWS CDK CLI の最初の新バージョンは 2.1000.0 としてリリースされ、次のバージョンは 2.1001.0 に続きます。CDK コンストラクトライブラリは現在のバージョニング体系を継続し、 2.174.0 , 2.175.0 , 2.176.0 というように順次リリースされます。 変更の理由 AWS CDK CLI と CDK コンストラクトライブラリは元々別個のコンポーネントでした。これらは歴史的に同じリポジトリに配置されていましたが、これは私たちが迅速に反復開発を行うために役立ちました。AWS CDK が成熟するにつれて、異なるコンポーネントへの変更は異なるサイクルで進み、異なるテスト戦略が必要であることがわかりました。この変更により一方のサブプロジェクトのリリースサイクルを他方に影響を与えることなく変更できるようになり、プロジェクト全体により高い俊敏性をもたらすことができます。 AWS CDK CLI の基本的な互換性モデルは変わりません。AWS CDK CLI はそれと同時期またはそれ以前にリリースされたすべての CDK コンストラクトライブラリの出力を処理できます。これまでは CLI version &gt;= Lib version が常に有効なバージョンの組合せであるというルールとして表現されていました。バージョンが同時にリリースされなくなるため、新しいルールは CLI release date &gt;= Lib release date となります。バージョン番号だけでは一目でこの関係を把握することは難しくなりますが、CDK コンストラクトライブラリが必要とする最小限の AWS CDK CLI バージョンが cdk.out マニフェストに含まれます。エラーメッセージには必要なバージョンを表示し、各バージョンの互換性情報を GitHub に公開します。 バージョンの連続性の区切りを示すため、AWS CDK CLI のバージョン番号に大きな明確な区切りを設けます。 2.174.0 の後、AWS CDK CLI のバージョンは 2.1000.0 にスキップし、その後 2.1001.0 に進みます。これによりメジャーバージョン番号を変更することなく、AWS CDK CLI と CDK コンストラクトライブラリのバージョニング体系の関連性が途切れていることが明確になることを期待しています。 CDK コンストラクトライブラリは、 2.175.0 、 2.176.0 などのように、現在のバージョニング体系でリリースを継続します。 変更しない項目について メジャーバージョン番号は変更しません: バージョンの連続性が途切れていることを示す目的で AWS CDK CLI 3.x をリリースすることはありません。その理由は以下の 2 つです: ほとんどのお客様のプロジェクトには、 "aws-cdk": "^2.174.0" のような依存関係の範囲が設定されています。メジャーバージョン番号を 3.x に変更すると、これらのプロジェクトは AWS CDK CLI の更新を自動的に取り込まなくなり、次のスキーマ変更時に AWS CDK CLI の互換性エラーが発生することになります。メジャーバージョン 2 のままであれば新しいリリースは指定された依存関係の範囲に引き続き一致し、自動的にインストールされます。 この変更は "CDKv3" リリースを意味するものではないため、そのように解釈される可能性を避けるために AWS CDK CLI のメジャーバージョンを 3 に変更しません。これは AWS CDK CLI のメジャーバージョン番号を決して上げないという約束ではありません。将来、変更する正当な理由がある場合は結果的に変更する可能性があります。その場合は影響を最小限に抑える方法で実施します。少なくとも将来の AWS CDK CLI v3 は非推奨でない CDK コンストラクトライブラリの 2.x バージョンとの互換性を維持します。 issue を報告する場所は変更されません： AWS CDK CLI のコードは別のリポジトリに移動し、プルリクエストは別のリポジトリに対して行う必要がありますが、AWS CDK に関する問題は引き続きメインの aws/aws-cdk リポジトリに報告することができます。AWS CDK フレームワーク全体に関する問題を、その問題がどのコンポーネントから発生したかに関係なく 1 つの場所で簡単に報告できるようにしたいと考えています。AWS CDK チームは、すべてのリポジトリにわたって issue を監視し、必要に応じて issue を別のリポジトリに移動します。これは、jsii のような他の AWS CDK コンポーネントで採用している運用手順と同じです。 互換性モデルは変更されません: 互換性モデルに変更はありません。AWS CDK CLI はそれ以前の過去ににリリースされた非推奨でないバージョンの CDK コンストラクトライブラリによって生成されたすべての cdk.out ディレクトリを常に読み取ることができます。互換性を確保するために、CDK コンストラクトライブラリのバージョンをアップグレードする頻度と同じかそれ以上の頻度で npm upgrade を使用して AWS CDK CLI バージョンをアップグレードすることをお勧めします。 互換性を確保するために使用できるいくつかの有用なヒントを紹介します。従うべき簡単なルールは CLI release date &gt;= Lib release date であれば確実に動作するということです。より複雑ではありますが、やはりライブラリリリース前の最新の AWS CDK CLI リリースは確実に動作し、それ以降のバージョンも同様に動作します。 cdk.out ディレクトリ内のファイル形式に変更がない場合、古いバージョンでも動作する可能性がありますが、その互換性は保証されません。 お客様への影響について AWS CDK ユーザーの皆様へ ： AWS CDK CLI と CDK コンストラクトライブラリのバージョンが異なることにお気づきになると思います。AWS CDK の日常的な使用経験に最も影響を与えるのは CDK コンストラクトライブラリのバージョンであるため、これを「AWS CDK のバージョン」として考えることをお勧めします。また、使用している CDK コンストラクトライブラリのバージョンをサポートする AWS CDK CLI バージョンを常に使用するために、AWS CDK CLI は最新バージョンに保つことをお勧めします。CDK コンストラクトライブラリと AWS CDK CLI の両方を単一の「AWS CDK バージョン」でインストールすることを前提としたスクリプトは書き直す必要があります。 # このスクリプトは今後正常に動作しません。aws-cdk と aws-cdk-lib は異なるバージョンを持つ場合があります。 $ CDK_VERSION=2.714.0 $ npm install aws-cdk-lib@$CDK_VERSION $ npm install aws-cdk@$CDK_VERSION # Do this instead (install the latest 2.x) $ npm install aws-cdk@^2 AWS CDK コントリビューターの方へ： AWS CDK CLI 関連の issue は引き続き aws-cdk リポジトリ に報告してください。ただし、プルリクエストは新しいリポジトリに対して行う必要があります。AWS CDK CLI と CDK コンストラクトライブラリの両方に関わる変更は両方のリポジトリに対して送り、個別にマージする必要があります。コンストラクトライブラリの PR をマージする前に AWS CDK CLI の変更をリリースする必要があります。具体的なワークフローについては、新しい https://github.com/aws/aws-cdk-cli リポジトリに記載されます。 まとめ この変更により AWS CDK をより速いペースで改善できるようになることを嬉しく思います。お客様側での準備やスクリプトの更新が必要になる可能性はありますが、ユーザーへの影響は最小限に抑えられると考えています。ご質問がある場合や、この変更に関する議論に参加したい場合は GitHub の該当 Issue をご覧いただくか、 AWS Support または Slack を通じて直接お問い合わせください。

1 月 20 日週以降、AWS から 40 件ほどの新規リリースがありました。リリースは通常のリズムに戻りました。サービスチームはお客様のフィードバックに耳を傾け、当社のサービスを使用する際のお客様の作業を容易にする小さな (または大きな) 変更を開発しています。AWS コンソールで複数のセッションをサポートする機能は、2025 年に入ってからのこれまでのところ、私のお気に入りです。 しかし、私たちのチームはそこで止まりませんでした。先週の新しいお知らせを見てみましょう。 1 月 20 日週のリリース 通常のリージョンレベルの拡張 (新しいリージョンで使用できるようになった新機能) の他に、私が注目したリリースをご紹介します。 Amazon EventBridge がクロスアカウントターゲットへの直接配信を発表 – Amazon EventBridge は、イベントをターゲットアカウントのデフォルトバスに最初に送信することなく、別の AWS アカウントのターゲットに直接配信できるようになりました。これにより、とても多くのアーキテクチャが簡素化されます! これは、 AWS Lambda 、 Amazon Simple Queue Service (Amazon SQS)、 Amazon Simple Notification Service (Amazon SNS)、 Amazon Kinesis 、 Amazon API Gateway など、 リソースベースのポリシー をサポートするすべてのターゲットをサポートします。 Amazon Corretto の四半期ごとの更新 – Amazon Corretto の長期サポート (LTS) および OpenJDK の機能リリース (FR) バージョンの四半期ごとのセキュリティおよび重要な更新を発表しました。Corretto 23.0.2、21.0.6、17.0.14、11.0.26、8u442 がダウンロードできるようになりました。Amazon Corretto は、OpenJDK の無料かつマルチプラットフォームの本番対応ディストリビューションです。更新は、 Corretto ホームページ からダウンロードできるほか、 apt-get または yum update と入力するだけでもダウンロードできます。 Amazon SNS FIFO トピック向けの高スループットモード – Amazon SNS は、SNS FIFO トピック向けの高スループットモードをサポートするようになりました。デフォルトのスループットは、すべてのリージョンの SNS 標準トピックと一致します。高スループットモードを有効にすると、SNS FIFO トピックはメッセージグループ内の順序を維持し、重複排除の範囲を メッセージグループレベル に縮小します。この変更により、米国東部 (バージニア北部) リージョンではデフォルトでアカウントあたり最大 30K メッセージ/秒 (MPS)、米国西部 (オレゴン) および欧州 (アイルランド) リージョンではアカウントあたり最大 9K MPS を活用でき、どのリージョンでも追加のスループットのためにクォータの引き上げをリクエストできます。 Amazon Connect エージェントワークスペースが、Citrix および Amazon WorkSpaces 仮想デスクトップの音声最適化のサポートを開始 – Amazon Connect エージェントワークスペースが、Citrix および Amazon WorkSpaces 仮想デスクトップインフラストラクチャ (VDI) 環境からカスタマーサービスエージェントのローカルデバイスに音声をリダイレクトする機能をサポートするようになりました。音声リダイレクトにより、仮想デスクトップで処理される音声通話の音声の質が改善され、レイテンシーが低減されるため、エンドカスタマーとエージェントの両方に優れたエクスペリエンスが提供されます。 Amazon Redshift がゼロ ETL 統合の履歴モードのサポートを発表 – この新しい機能により、コードを記述することなく、データベースの履歴データに基づいて Type 2 Slowly Changing Dimension (SCD 2) テーブルを Amazon Redshift ですぐに構築できます。履歴モードにより、履歴データの変更を追跡および分析するプロセスが簡素化され、時間の経過に伴うデータの進化から有益なインサイトを得ることができます。 最後に、 Amazon Bedrock からも一連のお知らせがあります。まず、 検索拡張生成 に投資しているお客様のために、Bedrock は Cohere Embed 3 Multilingual および Embed 3 English モデルを使用してマルチモーダルコンテンツをサポートするようになりました。これにより、埋め込みを作成して、テキストだけでなく画像もインデックス化できます。 次に、「 Luma AI’s Ray2 visual AI model now available in Amazon Bedrock 」をお読みください。Luma Ray2 は、滑らか、かつ、自然な動きでリアルなビジュアルを作成できる大規模な動画生成モデルです。Amazon Bedrock の Luma Ray2 を使用すると、シームレスなアニメーション、超リアルなディテール、自然言語プロンプトによる論理的なイベントシーケンスを含む、本番対応の動画クリップを生成できるため、技術的なプロンプトエンジニアリングが不要になります。Ray2 は現在、540p および 720p の解像度で 5 秒と 9 秒の動画生成をサポートしています。 そして最後に、 Amazon Bedrock Flows がマルチターン会話サポートのプレビューを発表しました 。 Amazon Bedrock Flows を使用すると、基盤モデル (FM)、 Amazon Bedrock Prompts 、 Amazon Bedrock エージェント 、 Amazon Bedrock ナレッジベース 、 Amazon Bedrock ガードレール 、および他の AWS サービスをリンクして、事前定義済みの生成 AI ワークフローを構築およびスケールできます。今週、チームは Flows のエージェントノード向けのマルチターン会話サポートのプレビューを発表しました。この機能により、自然な対話と同様に、ユーザーとフローの間で動的な会話が可能になります。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit のシーズンが始まります! 私は既に現地のチームと協力して、パリとロンドンの Summit のコンテンツを準備しています。Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。公式 AWS Summit ウェブサイト にアクセスして最新情報を入手し、お住まいの地域内で開催されるイベントの登録開始時期を知るために通知にサインアップしましょう。 コラボレーションスペースで、没入型エクスペリエンスでもある AWS GenAI Lofts &nbsp;は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスへのハンズオンアクセス、業界リーダーとの特別セッション、投資家や同業他社との貴重なネットワーキングの機会をスタートアップやデベロッパーに提供します。&nbsp; お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 1 月 20 日週のニュースは以上です。1 月 27 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は 2024/03/19に投稿された Simplify private connectivity to Amazon DynamoDB with AWS PrivateLink を翻訳した記事です。翻訳は Solutions Architect 嶋田朱里が担当しました。 Amazon DynamoDB は、サーバーレス、NoSQL、完全マネージド型のデータベースで、あらゆるスケールでミリ秒単位のパフォーマンスを実現します。マルチリージョン、マルチアクティブ、高耐久性のデータベースで、組み込みのセキュリティ、バックアップ/リストア、メモリキャッシングを備えています。 お客様は VPC またはオンプレミスで実行されるワークロードから ゲートウェイエンドポイント を使用して DynamoDB にアクセスできます。オンプレミスのプライベートネットワークからゲートウェイエンドポイントに接続する場合、多くのお客様はプロキシサーバーまたはファイアウォールルールを設定して DynamoDB へのトラフィックをルーティングおよび制限しています。これはゲートウェイエンドポイントが AWS Direct Connect または AWS Virtual Private Network (AWS VPN) と互換性がないためです。この追加のインフラストラクチャ設定は運用負荷とコンプライアンスを複雑化させる可能性があります。お客様からは、追加のプロキシインフラストラクチャを必要とせずに、オンプレミスワークロードから DynamoDB にプライベートネットワーク接続を設定できるソリューションが求められていました。 私たちは DynamoDB 向けの AWS PrivateLink サポート を発表できることを喜ばしく思います。PrivateLink を使用すると、 インターフェイス VPC エンドポイント とプライベート IP アドレスを使って、オンプレミスのワークロードから DynamoDB へのプライベートネットワーク接続を簡素化できます。インターフェイスエンドポイントは、Direct Connect と AWS VPN に対応しており、エンドツーエンドのプライベートネットワーク接続が可能です。その結果、公開 IP アドレス、プロキシインフラ、ファイアウォールルールを必要とせずオンプレミスから DynamoDB にアクセスすることができ、コンプライアンスを維持できます。VPC 内のネットワークトラフィックにはゲートウェイエンドポイントを、オンプレミスのネットワークトラフィックにはインターフェイスエンドポイントを使用することで、DynamoDB への低コストのプライベートネットワーク接続を実現できます。 この投稿では、オンプレミス環境をエミュレートして、PrivateLink を使用したインターフェイス VPC エンドポイントをDynamoDB で利用する例を示します。PrivateLink でインターフェイスエンドポイントを使用する他の例については、 ユースケース例 を参照してください。 プライベート IP アドレスを使用した、オンプレミスから DynamoDB へのアクセス この投稿では、保険会社が、オンプレミスのメインフレームシステムに保存されているリスクスコアを再評価するために、DynamoDB に保存されている見積もりと請求データにアクセスする必要があるという想定で説明します。 オンプレミスのワークロードは、 AWS Client VPN を通じて us-west-1 リージョンの VPC に接続するローカルマシンで、PrivateLink のインターフェイスエンドポイントを使用して、プライベート IP アドレスで DynamoDB にアクセスします。次の図は、このアーキテクチャを示しています。 このソリューションには、以下の主要コンポーネントが含まれています。 AWS Client VPN エンドポイントが VPC に関連付けられている OpenVPN ベースの AWS Client VPN がローカルマシンに設定されている。AWS Client VPN エンドポイントを使用して VPC に接続できる DynamoDB 用 PrivateLink のインターフェイス VPC エンドポイントが作成され、VPC のサブネットに関連付けられている ローカルマシン上で実行されているオンプレミスアプリケーションは、インターフェイス VPC エンドポイントを使用して DynamoDB テーブルにプライベートにアクセスできる 次のセクションでは、この設定を構成し、新しい PrivateLink のインターフェイス VPC エンドポイントを作成します。 前提条件 始めるにあたり、以下のようにネットワークを設定していることを確認してください: ローカルマシンの AWS クライアント VPN で設定したリージョンに VPC があること インターフェイスエンドポイントのセキュリティグループが、オンプレミス環境と同じか、オンプレミス環境 (AWS Client VPN エンドポイント) からのトラフィックを受信するためのインバウンドルールが含まれている AWS Client VPN を使用する場合、AWS Client VPN エンドポイントの承認ルールが、インターフェイスエンドポイントが関連付けられているサブネットの CIDR ブロックへのトラフィックを許可している オプションで、ローカルマシンに Python3 と AWS SDK for Python (Boto3) がインストールされている ソリューションの設定 以下の手順で、us-west-1 リージョンの VPC 内に DynamoDB 用 PrivateLink のインターフェイス VPC エンドポイントを作成します。 Amazon VPC に移動し、ナビゲーションペインから Endpoints を選択します。 Create endpoint を選択します。 Name tag には、任意のタグを入力します。 Service category は AWS services を選択します。 DynamoDB のインターフェイスタイプのエンドポイントを検索して選択します。これは DynamoDB 用 PrivateLink の VPC エンドポイントです。 インターフェイスエンドポイントは VPC に関連付けられているため、対象の VPC、インターフェイスエンドポイントを関連付けたいサブネット、設定したいセキュリティグループを選択します。 インターフェイス VPC エンドポイントを使用して DynamoDB と接続する AWS Identity and Access Management (IAM) エンティティに対して、許可される DynamoDB アクションを制限するために、VPC エンドポイントポリシーを指定します。この記事では、 Full access を選択します。 最小特権のアクセス原則 に基づいて、このポリシー内のアクセスを絞り込むことをお勧めします。 Create endpoint を選択します。 エンドポイントの作成には数分かかる場合があります。 インターフェイス VPC エンドポイントが正常に作成されると、VPC 固有の複数の DNS 名が表示されます。DNS 名には、リージョナルエンドポイントである単一のエントリと、設定したサブネットが属する各アベイラビリティーゾーンに付与されるゾーナルエントリが含まれています。 VPC に接続されたローカルマシン上のアプリケーションからアクセスするために、リージョナル DNS 名をコピーします。 Boto3 SDK の DynamoDB クライアントを初期化する際、適切な region_name とともに、 endpoint_url にコピーしたリージョナル DNS 名を渡します。これは AWS SDK によって異なる場合があります。 import boto3 ddb_client = boto3.client( "dynamodb", region_name="us-west-1", endpoint_url="https://vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com", ) response = ddb_client.get_item( TableName="plays", Key={"pk": {"S": "64.0"}, "sk": {"S": "2014-01-02T09:44:24Z"}}, ) print(response["Item"]) Output: {'sk': {'S': '2014-01-02T09:44:24Z'}, 'data': {'S': '208356596'}, 'pk': {'S': '64.0'}, 'type': {'S': 'sample'}} リージョン間の DynamoDB アクセス (プライベート IP アドレスを使用) オンプレミスから AWS Client VPN を使用して VPC にアクセスするシナリオと同様に、PrivateLink のインターフェイス VPC エンドポイントを使用して、プライベート IP アドレスを介して別リージョンの DynamoDB リソースにプライベートにアクセスすることができます。これには 2 つの VPC をピアリングし、ルートテーブルを適切に更新する必要があります。このアーキテクチャを以下に示します。 この場合、us-east-1 リージョンに VPC ベースの AWS Lambda アプリケーションがあり、PrivateLink のインターフェイス VPC エンドポイントを使用して us-west-1 リージョンの DynamoDB テーブルにアクセスできます。Lambda 関数は、PrivateLink のインターフェイス VPC エンドポイントを使用して、リージョン間の DynamoDB リソースにアクセスできます。 プライベート IP アドレスを使用したリソースへのアクセス インターフェイスエンドポイントの主な利点は、関連付けられた VPC の特定のサブネット内のプライベート IP アドレスに解決されることです。たとえば、VPC の CIDR 範囲が 172.31.0.0/16 で 2 つのサブネットがある場合、インターフェイスエンドポイントはこの範囲内の IP アドレスに解決されるため、エンドポイントに関連付けられた各サブネットに少なくとも 1 つの IP アドレスが割り当てられます。次のコードを参照してください。 $ dig vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com ; &lt;&gt; DiG 9.10.6 &lt;&gt; vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com ... ;; QUESTION SECTION: ; vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com. IN A ;; ANSWER SECTION: vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com. 60 IN A 172.31.8.44 vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com. 60 IN A 172.31.16.71 DNS 名は公開されていますが、VPC のサブネットに属するプライベート IP アドレスに解決されるため、インターフェイスエンドポイントから DynamoDB にインターネット経由で接続することはできません。エンドツーエンドでプライベートアクセスが提供されます。オンプレミスの設定では、 AWS Direct Connect または AWS Client VPN を使用して VPC にルーティングされるトラフィックは、シームレスにインターフェイスエンドポイントにルーティングできるように構成できます。 オンプレミスネットワーク オンプレミスのアプリケーションで DynamoDB のインターフェイスエンドポイントを設定するには、Direct Connect または VPN ソリューションを使用して VPC との接続を確立する必要があります。さらに、インターフェイスエンドポイントが関連付けられている VPC の CIDR へのルートが設定されていることを確認してください。また、オンプレミスネットワークの CIDR からのインバウンドルールを含むように、インターフェイスエンドポイントのセキュリティグループを設定します。最後に、DynamoDB のパブリック DNS ドメイン内で解決可能なインターフェイスエンドポイントの DNS 名を解決するために、オンプレミスで DNS 設定が実装されていることを確認してください。ネットワークから VPC への接続に関する詳細は、 Network-to-Amazon VPC connectivity options を参照してください。 次の図は、PrivateLink のインターフェイス VPC エンドポイントが、オンプレミスのアプリケーションと AWS Cloud 内の DynamoDB テーブルとの接続を容易にする方法を示しています。このセットアップには、VPC 内のトラフィックをルーティングするためのゲートウェイエンドポイントも組み込まれています。 考慮事項 PrivateLink のインターフェイスエンドポイントを使用する際は、以下の点に注意してください。 DynamoDB のゲートウェイエンドポイントとインターフェイスエンドポイントのどちらを選択しても、ネットワークトラフィックは両方のシナリオで AWS ネットワーク内に留まります。単一の VPC 内、または VPC 間の通信にはゲートウェイエンドポイントの使用を推奨しますが、オンプレミスのデータセンターからの通信にはインターフェイスエンドポイントを使用することをお勧めします。現時点では、インターフェイスエンドポイントは IPv4 アドレスのみをサポートしています。 PrivateLink は、エンドポイントごとにアベイラビリティーゾーンあたり最大 100Gbps をサポートします。オンプレミスのデータセンターから DynamoDB インターフェイスエンドポイントへの 1 秒あたりのデータ転送量が AZ あたり 100Gbps を超える場合は、予想されるデータ転送要件に対応するために追加のインターフェイスエンドポイントを構成できます。 DynamoDB のゲートウェイ VPC エンドポイントの使用に関連するデータ処理料金や時間料金はありません。ただし、PrivateLink を使用したインターフェイスエンドポイントの場合は標準料金が適用されます。詳細については、 AWS PrivateLink 料金 を参照してください。 クリーンアップ このポストの一環で作成した AWS リソースを削除してください。 AWS Client VPN エンドポイント 、 インターフェイス VPC エンドポイント 、 Lambda 関数 、およびその他のリソースを削除してください。 結論 DynamoDB 用の PrivateLink を使用すると、オンプレミスのデータセンターまたは VPC 内の プライベート IP アドレスから DynamoDB への接続を確立することができ、ネットワークアーキテクチャを簡素化できます。PrivateLink では、オンプレミスの場所から DynamoDB にアクセスするために、パブリック IP アドレスの設定、ファイアウォールルールの設定、インターネットゲートウェイの設定が不要になります。この新機能は、すべての AWS 商用リージョン でご利用いただけます。 DynamoDB 用の PrivateLink バックエンドのインターフェイス VPC エンドポイントを使用し、コメントセクションでフィードバックを共有してください。 著者について Aman Dhingra はアイルランドのダブリンを拠点とする DynamoDB 専門のソリューションアーキテクトです。分散システムに情熱を持ち、ビッグデータ &amp; 分析技術の経験があります。DynamoDB 専門のソリューションアーキテクトとして、DynamoDB をバックエンドとするワークロードの設計、評価、最適化をサポートしています。 Ashwin Venkatesh は、Amazon Web Services の Amazon DynamoDB のシニアプロダクトマネージャーで、カリフォルニア州サンタクララに拠点を置いています。25 年以上にわたるプロダクトマネジメントとテクノロジーの役割を経験し、顧客とのエンゲージメントを通じてビジネスユースケースを理解しています。戦略と長期的な顧客価値を提供する新機能を逆算して定義することや、同僚と技術について深く議論することに情熱を持っています。仕事の外では、旅行、スポーツ、家族行事を楽しんでいます。

エグゼクティブやそのチームに実用的で客観的なインサイトを提供する Gartner は、 2024 Gartner Magic Quadrant for Contact Center as a Service(CCaaS) を発表しました。AWS がリーダーに選ばれたのは 2 年連続で、私たちはこのリーダーへの選出は、柔軟で、AI を活用したクラウドコンタクトセンターソリューションである Amazon Connect の革新性を示すものだと考えています。また、あらゆる規模の企業が優れた顧客体験を低コストで提供可能にする私たちのコミットメントを反映していると考えています。 Gartner によると、AWS は実行能力とビジョンの完全性により CCaaS のリーダーと判断されました。Amazon Connect のバイスプレジデントである Pasquale DeMaio は、「わずか 7 年で、Amazon Connect は数万の顧客から信頼を得るまでに成長し、2 年連続でリーダーに位置付けられ、私たちはますます情熱をもっています。私たちは、あらゆる規模の企業に、柔軟で拡張性があり、インテリジェントなクラウドコンタクトセンターソリューションを提供するため、急速なイノベーションを続けています。私たちは、企業が測定可能な結果をもたらす、より意味のある、パーソナライズされた顧客とのやり取りを実現できることに焦点を当てています」と述べています。 現在、Capital One、Intuit、Hilton、Air Canada、DoorDash、National Australia Bank、 Amazon.com のような お客様 が、優れた顧客体験を提供するために Amazon Connect を活用しています。 Gartner のレポートは、お客様のビジネスに適したクラウドコンタクトセンターソリューションを評価する際の有益なガイダンスを提供しています。 このリンクより、 2024 Gartner Magic Quadrant for CCaaS のレポート に無料でアクセスいただけます。Amazon Connect についてさらに詳しく知るには : Amazon Connect のページをご覧ください Amazon Connect IVR についてもっと知りたいですか ? お客様のペースに合わせた柔軟な移行オプションをご用意しています re:Invent 2024 でのAmazon Connect のセッションにご興味がありますか ? Amazon Connect によるカスタマーエクスペリエンスガイド をご確認ください re:Invent 2024 の振り返りは AWS re:Invent 2024 recap: Amazon Connect の新しいアナウンス をご覧ください Amazon Connect で顧客サービス体験を変革する準備はできましたか？ お問い合わせ ください。 この図は、Gartner, Inc. が発行したより大きな調査文書の一部であり、文書全体の文脈で評価されるべきものです。 Gartner の文書は、 AWS にリクエストすることで入手可能です。 GARTNER および Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。すべての権利は留保されています。All rights reserved. Gartner は、その調査出版物に記載されているいかなるベンダー、製品またはサービスも推奨するものではなく、また、テクノロジーユーザーに対して、最高の格付けまたはその他の指定を受けたベンダーのみを選択するよう助言するものでもありません。Gartner の調査出版物は、 Gartner の調査組織の見解で構成されており、事実の記述として解釈されるべきものではありません。ガートナーは、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は 2025 年 1 月 29 日に公開された Deploy DeepSeek-R1 Distilled Llama models in Amazon Bedrock を翻訳したものです。翻訳はソリューションアーキテクトの森下裕介が担当しました。 オープンな基盤モデル (FM) は 生成 AI イノベーションの要であり、それによりあらゆる組織はコストとデプロイ戦略をコントロールしながら AI アプリケーションを構築・カスタマイズすることができます。高品質でありオープンに利用可能なモデルを提供することで、AI コミュニティは迅速なイテレーション、ナレッジシェア、そして開発者とエンドユーザーの両方に利益をもたらす費用対効果の高いソリューションを促進しています。AI 技術の進歩にフォーカスしている研究開発企業である DeepSeek AI は、このエコシステムに大きく貢献しています。彼らの DeepSeek-R1 モデルは、コード生成から一般的な推論まで幅広いタスクを処理しながら、競争力の高いパフォーマンスと効率性を維持するように設計された大規模言語モデル (LLM) のファミリーを表しています。 Amazon Bedrock Custom Model Import を使用することで、Amazon Bedrock が提供する既存の基盤モデルと同様に、カスタマイズしたモデルを単一のサーバーレスかつ統一された API を通じてインポートし、利用することができます。インフラストラクチャを管理する必要なく、インポートしたカスタムモデルにオンデマンドでアクセスすることが可能です。また、Knowledge Bases、Guardrails、Agents のような Amazon Bedrock のネイティブなツールや機能とカスタムモデルを統合することで、生成 AI アプリケーションの開発を加速させることができます。 この記事では、Amazon Bedrock Custom Model Import を使用して DeepSeek-R1 の蒸留バージョンをデプロイする方法を探ります。これにより、最先端のAI 機能を安全でスケーラブルな AWS インフラストラクチャ内で効果的なコストで使用したい組織がアクセスできるようになります。 訳註：2025 年 1 月 31 日現在、オリジナルバージョンである DeepSeek-R1 は Amazon Bedrock Marketplace 経由にて Amazon Bedrock 上で利用することが可能です。詳細は こちらのブログ をご覧ください。 DeepSeek-R1 蒸留モデルのバリエーション DeepSeek-R1 をベースとして、DeepSeek AI は Meta Llama および Qwen のアーキテクチャに基づいて、15 億から 700 億のパラメータを持つ一連の蒸留モデルを作成しました。蒸留プロセスでは、より大きな DeepSeek-R1 モデルを教師として使用し、その動作と推論パターンを模倣するように、より小さく効率的なモデルを訓練します。6710 億パラメータモデルの知識と能力を、よりコンパクトなアーキテクチャに転移させるのです。結果として得られた DeepSeek-R1-Distill-Llama-8B (ベースモデル Llama-3.1-8B から) や DeepSeek-R1-Distill-Llama-70B (ベースモデル Llama-3.3-70B-Instruct から) などの蒸留モデルは、パフォーマンスとリソース要件の間で異なるトレードオフを提供します。蒸留モデルは元の 6710 億モデルと比較して推論能力がやや低下する可能性がありますが、推論速度を大幅に向上させ、計算コストを削減します。例えば、8B バージョンのような小さな蒸留モデルは、リクエストの処理が非常に速く、リソース消費が少ないため、本番環境でのデプロイにおいては費用対効果が高くなります。一方、70B モデルのような大きな蒸留バージョンは、元のモデルに近いパフォーマンスを維持しながらも依然として意味のある効率性の向上を提供します。 ソリューション概要 この記事では、Amazon Bedrock Custom Model Import を使用して DeepSeek-R1 モデルの蒸留バージョンをデプロイする方法をご紹介します。今回は現在サポートされている DeepSeek-R1-Distill-Llama-8B と DeepSeek-R1-Distill-Llama-70B にフォーカスします。これらは、パフォーマンスとリソース効率の最適なバランスを提供します。これらのモデルを Amazon Simple Storage Service (Amazon S3) または Amazon SageMaker AI モデルリポジトリからインポートし、Amazon Bedrock を通じてフルマネージドなサーバーレス環境にデプロイできます。以下の図は、エンドツーエンドのフローを示しています。 このワークフローでは、Amazon S3 に保存されたモデルアーティファクトが Amazon Bedrock にインポートされ、Amazon Bedrock がモデルのデプロイメントとスケーリングを自動的に処理します。このサーバーレスアプローチにより、インフラ管理の必要性がなくなり、エンタープライズグレードのセキュリティとスケーラビリティが提供されます。 GUI を使用してデプロイする場合は、Amazon Bedrock コンソールを使用し、以下のこの記事の手順に従って操作してください。または、Amazon Bedrock SDK によるプログラムによってデプロイしたい方は こちらのノートブック を参照ください。 前提条件 手順を進めるにあたっては以下の前提条件が必要となります。 Amazon Bedrock にアクセスできる AWS アカウント。 Amazon Bedrock と Amazon S3 の操作に必要となる AWS Identity and Access Management (IAM) ロールと権限。詳細については ドキュメント を参照してください。 カスタムモデルを保存するために準備された S3 バケット。詳細については ドキュメント を参照してください。 十分なローカルストレージスペース ( 8B モデルの場合は少なくとも 17GB、70B モデルの場合は 135GB ) 。 モデルパッケージの準備 1. モデルパッケージを準備するには、以下の手順を完了してください： デプロイしたいモデルに応じて、以下の Hugging Face のリンクのいずれかから DeepSeek-R1-Distill-Llama モデルアーティファクトをダウンロードします。 https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-8B/tree/main https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-70B/tree/main ダウンロードの詳細については、Hugging Faceの「 モデルのダウンロード 」または「 ハブからのファイルのダウンロード 」の手順を参照ください。 通常、以下のファイルが必要です。 モデル設定ファイル： config.json トークナイザーファイル： tokenizer.json 、 tokenizer_config.json 、 tokenizer.mode .safetensors 形式のモデルの重みファイル 2. これらのファイルを S3 バケット内のフォルダにアップロードします。Amazon Bedrock を利用する AWS リージョンと同じリージョンを使用してください。使用している S3 パスをメモしておきます。( 訳註：2025 年 1 月 29 日現在 Amazon Bedrock Custom Model Import をサポートしているのは、米国東部 (バージニア北部) リージョンおよび米国西部 (オレゴン) リージョンとなります。) モデルのインポート モデルをインポートするには、以下の手順を完了してください： 1. Amazon Bedrock コンソールにてナビゲーションペインの Foundation models の下にある Imported models を選択します。 2. Import model を選択します。 3. Model name にモデルの名前を入力します (インポートしたモデルを追跡するために、名前にバージョニングスキームを使用することをお勧めします) 。 4. Import job name にインポートジョブの名前を入力します。 5. Model import settings にて、インポートソースとして Amazon S3 bucket を選択し、先ほどメモした S3 パスを入力します ( s3://&lt;your-bucket&gt;/folder-with-model-artifacts/ の形式で完全なパスを提供してください）。 6. Encryption で、必要に応じて暗号化設定をカスタマイズすることができます。 7. Service access role で、新しい IAM ロールを作成するか、独自のロールを提供するかを選択します。 8. Import model を選択します。 モデルのインポートには、インポートされるモデルに応じて数分かかります (例えば、Distill-Llama-8B モデルの場合完了までに5〜20 分かかる可能性があります) 。 ステップバイステップのガイドについては、このビデオデモをご覧ください。 インポートしたモデルのテスト モデルをインポートした後、Amazon Bedrock Playground を使用するか Amazon Bedrock のモデル呼び出し API を直接使用してテストできます。Playground を使用するには、以下の手順を完了してください。 Amazon Bedrock コンソールで、ナビゲーションペインの Playgrounds の下にある Chat / Text を選択します。 モデルセレクターから、インポートしたモデル名を選択します。 必要に応じて推論パラメータを調整し、テストプロンプトを書きます。例えば、 &lt;|begin▁of▁sentence|&gt;&lt;|User|&gt;Given the following financial data: - Company A's revenue grew from $10M to $15M in 2023 - Operating costs increased by 20% - Initial operating costs were $7M Calculate the company's operating margin for 2023. Please reason step by step, and put your final answer within \boxed{}&lt;| Assistant|&gt; Playground でインポートしたモデルを使用しているため、DeepSeek モデルのコンテキストを適切にフォーマットするために、”beginning_of_sentence” と “user/assistant” タグを含める必要があります。これらのタグは、モデルが会話の構造を理解し、より正確な応答を提供するのに役立ちます。ノートブック を用いてプログラムによるアプローチに従っている場合、これはモデルを設定することで自動的に処理されます。 4. モデルの応答とメトリクスを確認します。 注： モデルを初めて呼び出すときに、 ModelNotReadyException エラーが発生した場合、SDK はエクスポネンシャルバックオフを使用してリクエストを自動的に再試行します。復元時間は、オンデマンドフリートのサイズとモデルのサイズによって異なります。 AWS SDK for Python (Boto3) Config オブジェクトを使用して、再試行の動作をカスタマイズできます。詳細については、 こちらのドキュメント を参照してください。 モデルのインポートの準備ができたら、上記のステップバイステップのビデオデモを参考にしながら利用を開始してください。 料金 Custom Model Import を使用すると、サポートされているアーキテクチャのカスタムモデルの重みを Amazon Bedrock 内で使用でき、Amazon Bedrock の既存の基盤モデルと同様にフルマネージドな環境でオンデマンドモードにてモデルをサーブすることが可能となります。Custom Model Import はモデルのインポートに対して課金はなされません。推論に対して、「アクティブなモデルコピーの数」と「アクティビティ期間」の 2 つの要因に基づいて課金されます。 請求は、各モデルコピーの最初の成功した呼び出しから始まる 5 分間のウィンドウで行われます。モデルコピーあたりの 1 分あたりの価格は、アーキテクチャ、コンテキスト長、リージョン、コンピュートユニットバージョンなどの要因に基づいて変動し、モデルコピーのサイズによって階層化されています。ホスティングに必要なカスタムモデルユニットは、モデルのアーキテクチャ、パラメータ数、コンテキスト長に依存し、例えば Llama 3.1 8B 128K モデルの場合は 2 ユニット、Llama 3.1 70B 128Kモデルの場合は 8 ユニットとなります。 Amazon Bedrock は自動的にスケーリングを管理し、デフォルトでは使用パターンに基づいて 0 から 3 のモデルコピーを維持します (Service Quotas を通じて調整可能)。5 分間呼び出しがない場合、0 にスケールダウンし、必要に応じてスケールアップしますが、これには数十秒のコールドスタート遅延が伴う可能性があります。推論量が単一コピーの同時実行制限を一貫して超える場合、追加のコピーが追加されます。コピーあたりの最大スループットと同時実行性は、入/出力トークンの組み合わせ、ハードウェアタイプ、モデルサイズ、アーキテクチャ、推論の最適化などの要因に基づいてインポート時に決定されます。 料金の例を見てみましょう：アプリケーション開発者が us-east-1 リージョンで 128K シーケンス長・パラメータサイズ 8B のカスタマイズ済み Llama 3.1 タイプモデルをインポートし、1 ヶ月後にモデルを削除するケースです。これには、2 つのカスタムモデルユニットが必要となります。したがって、1 分あたりの価格は $0.1570 となり、モデルのストレージコストは 1 ヶ月で $3.90 となります。 詳細については、 Amazon Bedrock の料金ページ をご覧ください。 ベンチマーク DeepSeek は、モデルリポジトリで利用可能な、DeepSeek-R1 から蒸留された彼らのモデルとベースとなる Llama モデルを比較した ベンチマークを公開 しています。ベンチマークによると、タスクに応じて DeepSeek-R1-Distill-Llama-70B は元のモデルの推論能力の 80-90% を維持し、8B バージョンはリソース要件を大幅に削減しながら 59-92% のパフォーマンスを達成しています。どちらの蒸留バージョンも、特定の推論タスクにおいて対応するベースの Llama モデルよりも改善を示しています。 その他の考慮事項 Amazon Bedrock で DeepSeek モデルをデプロイする際は、以下の点を考慮してください。 モデルのバージョン管理が不可欠です。Custom Model Import は各インポートに対して固有のモデルを作成するため、異なるバージョンやバリエーションを追跡するためには、モデル名に明確なバージョニング戦略を実装してください。 現在サポートされているモデル形式は Llama ベースのアーキテクチャに焦点を当てています。DeepSeek-R1 の蒸留バージョンモデルは優れたパフォーマンスを提供しますが、AI エコシステムは急速に進化し続けています。新しいアーキテクチャやより大きなモデルがプラットフォームを通じて利用可能になる Amazon Bedrock のモデルカタログに注目してください。 ユースケースの要件を慎重に評価してください。DeepSeek-R1-Distill-Llama-70B のような大きなモデルはより良いパフォーマンスを提供しますが、8B バージョンは多くのアプリケーションに対して十分な能力を低コストで提供する可能性があります。 モニタリングと可観測性の実装を検討してください。 Amazon CloudWatch はインポートしたモデルのメトリクスを提供し、利用パターンとパフォーマンスを追跡するのに役立ちます。 AWS Cost Explorer を使用してコストを監視できます。 低い同時実行クォータから始め、実際の使用パターンに基づいてスケールアップすることを検討してください。アカウントあたり 3 つの同時モデルコピーというデフォルトの制限は、殆どのケースにおいて初期のデプロイメントに適しています。 結論 Amazon Bedrock Custom Model Import は、あらゆる組織が DeepSeek-R1 蒸留バージョンモデルなどの強力な公開モデルを使用しながら、エンタープライズグレードのインフラストラクチャの恩恵を受けることを可能にします。Amazon Bedrock のサーバーレスな特性により、モデルのデプロイメントと運用の管理の複雑さが解消され、チームはインフラストラクチャではなくアプリケーションの構築に集中できます。自動スケーリング、使用量に応じた料金設定、AWS サービスとのシームレスな統合などの機能により、Amazon Bedrock は AI ワークロードに対する本番対応の環境を提供します。DeepSeek の革新的な蒸留アプローチと Amazon Bedrock のマネージドインフラストラクチャの組み合わせは、パフォーマンス、コスト、運用効率の最適なバランスを提供します。組織は小さなモデルから始め、必要に応じてスケールアップしながら、モデルのデプロイメントを完全にコントロールし、AWS のセキュリティとコンプライアンス機能の恩恵を受けることができます。 Amazon Bedrock が提供する独自の基盤モデルとオープンな基盤モデルの選択肢により、組織は特定のニーズに最適化する柔軟性を得られます。オープンモデルは、モデルアーティファクトを完全に制御しながら費用対効果の高いデプロイメントを可能にし、カスタマイズ、コスト最適化、またはモデルの透明性が重要なシナリオに適しています。この柔軟性と、Amazon Bedrock の統一的な API およびエンタープライズグレードのインフラストラクチャを組み合わせることで、組織は要件の進化に適応できる耐久性のある AI 戦略を構築できます。 詳細については、 Amazon Bedrock ユーザーガイド を参照してください。 著者について Raj Pathak は、プリンシパルソリューションアーキテクトであり、カナダと米国の Fortune 50および 中堅金融サービス業 (銀行、保険、資本市場) のお客様の技術顧問を務めています。Raj は機械学習を専門とし、生成 AI、自然言語処理、インテリジェントドキュメント処理、MLOps の領域において高い専門性を持っています。 Yanyan Zhang は、Amazon Web Services のシニア生成 AI データサイエンティストです。生成 AI スペシャリストとして最先端の AI/ML 技術に取り組み、お客様が生成 AI を使用して望む成果を達成できるよう支援しています。Yanyan はテキサス A&amp;M 大学で電気工学の博士号を取得しました。仕事以外では、旅行、運動、新しいことの探求を楽しんでいます。 Ishan Singh は、Amazon Web Services の生成 AI データサイエンティストで、お客様が革新的で責任ある生成 AI ソリューションと製品を構築するのを支援しています。AI/ML の強力な背景を持つ Ishan は、ビジネス価値を推進する生成 AI ソリューションの構築を専門としています。仕事以外では、バレーボールをしたり、地元の自転車道を探索したり、妻と犬の Beau と時間を過ごすことを楽しんでいます。 Morgan Rankey は、ニューヨークを拠点とするソリューションアーキテクトで、ヘッジファンドを専門としています。AWS エコシステム内で耐障害性のあるワークロードを構築するお客様の支援に優れています。AWS に入社する前は、Riskified のセールスエンジニアリングチームを IPO までリードしました。キャリアの始まりは、機械資産管理のための AI/ML ソリューションに焦点を当て、世界中の大手自動車会社にサービスを提供しました。 Harsh Patel は、クラウドネイティブソリューションを通じてデジタル変革を推進するため、米国全土の 200 以上の SMB のお客様をサポートするソリューションアーキテクトです。AI &amp; ML スペシャリストとして、生成 AI、コンピュータビジョン、強化学習、異常検出に焦点を当てています。テクノロジーの世界以外では、ゴルフコースでリフレッシュしたり愛犬と一緒にハイキングに出かけたりしています。

本稿は 2025 年 1 月 27 日に公開された “ Introducing the GraphRAG Toolkit ” を翻訳したものです。 Amazon Neptune チームは 2025 年 1 月 21 日に GraphRAG Toolkit を リリース しました。これは、グラフデータベースを活用した検索拡張生成 (Retrieval Augmented Generation; RAG) ワークフローの構築を容易にするオープンソースの Python ライブラリです。このツールキットは、非構造化データから、ベクトル埋め込みを含むグラフを自動的に構築するフレームワークを提供します。ユーザーの質問に答える際に、構造的に関連する情報を取得するために、このグラフをクエリする質問応答戦略を組み立てることができます。 本稿では、GraphRAG Toolkit の使い方について説明します。まず、RAG アプリケーションにグラフを追加することのメリットについて説明します。次に、クイックスタート環境のセットアップ方法とツールキットのインストール方法を説明します。最後に、このツールキットのグラフモデルとコンテンツ取得アプローチに至った設計上の考慮点について説明します。 なぜ RAG アプリケーションにグラフを追加するのか？ 以下のような 架空の 物語を考えてみましょう。これは数週間にわたる、様々な架空のニュース記事、プレスリリース、業界出版物、アナリストレポートを集めたものであり、他の多くの文書と共に RAG ワークフローに投入されると想定しています。 Example Corp (人気の個人用ガジェットである “Widget” を製造する米国企業) は最近、国際的な輸送、保管、ラストマイル配送を提供する AnyCompany Logistics と提携することで、世界的な流通チャネルを拡大しました。“Widget” は、新世代の生成 AI テクノロジーによって会話機能を備えた AI 搭載のパーソナルデスクトップペットです。オースティンを拠点とする Example Corp の研究所で開発され、台湾で製造されています。 まだ 8 月であるにもかかわらず、英国のクリスマストップ 10 おもちゃの予測が既に発表されており、業界アナリストは Example Corp のおしゃべりデスクトップペット “Widget“ への大きな需要を予測しています。ロンドン、マンチェスター、その他の主要都市の小売業者は既に 100 万台以上 (1,500 万ドル相当) の注文を行っており、クリスマスまでの数ヶ月でその数字はさらに増加する見込みです。 AnyCompany Logistics は本日、最近開通した Fictitious Canal (架空の運河) を通じて全ての配送を行うことで、 2 週間かかっていた台湾から英国までの輸送時間を僅か 3 日に短縮すると発表しました。Fictitious Canal は、製造業者や流通業者がエネルギー消費とコストを削減するため、空輸から海運への移行を検討する中で、今後 5 年間で最も交通量の多い水路のひとつになる見込みです。 Fictitious Canal で地滑りが発生し、閉塞と遅延が続いています。現在、500 万トン以上の岩が南部水域を塞ぎ、コンテナ船を閉じ込め、国際サプライチェーンを混乱させています。ヨーロッパ向けの商品は数ヶ月の遅延が予想され、多くの小売業者のクリスマス在庫が危機にさらされています。 あなたがアナリストだとしましょう。どんなことを知りたいでしょうか？例えば、Example Corp の英国での販売見通しはどうか調査したいとします。 まず、ベクトルベースの主要な RAG アプリケーションに質問したところ、以下のような回答が得られました。 提供されたコンテキストに基づくと、 Example Corp の Widget 製品の英国での販売見通しは、きたるクリスマスシーズンに向けて非常に明るいものとなっています。業界アナリストは Widget おしゃべりデスクトップペットへの大きな需要を予測しており、クリスマスのトップ 10 おもちゃにもランクインしています。ロンドンやマンチェスターなど英国の主要都市の小売業者は既に 1,500 万ドル相当の 100 万台以上の注文を行っており、クリスマスが近づくにつれてさらに注文数は増加すると予想されています。このコンテキストは、 Example Corp が重要な年末商戦期間中、英国市場で Widget 製品の非常に高い販売量と収益を見込めることを示唆しています。 次に、 GraphRAG Toolkit を使用して構築されたアプリケーションに質問したところ、以下のような回答が得られました。 検索結果に基づくと、 Example Corp のおしゃべりデスクトップペット Widget の英国での販売見通しは当初非常に有望ですが、後にサプライチェーンの問題が販売を妨げる可能性があります。 検索結果によると、ロンドンやマンチェスターなど英国の主要都市の小売業者は、大きな需要を見込んで Widget 製品の 100 万台以上の注文を既に行っています。業界アナリストもこのおもちゃへの高い需要を予測しています。 この予想される需要に応えるため、 Example Corp は AnyCompany Logistics と提携して、英国を含む世界的な流通チャネルを拡大しています。 AnyCompany Logistics は、新たに開通した Fictitious Canal を経由して輸送することで、台湾から英国までの輸送時間を 2 週間から僅か 3 日に短縮する計画を発表していました。 しかし、 Fictitious Canal では地滑りによる大規模な閉塞が報告されており、500 万トン以上の岩が南部水域を塞ぎ、コンテナ船を閉じ込めています。これにより国際サプライチェーンが混乱し、英国を含むヨーロッパ向けの商品が数ヶ月遅延する可能性があります。 そのため、 Example Corp の Widget 製品の英国での初期の販売見通しは、予約注文と予想される需要に基づいて非常に有望に見えますが、状況が早急に解決されない場合、 Fictitious Canal の閉塞によるサプライチェーンの問題が今後数ヶ月間の需要への対応能力を妨げるリスクがあります。 なぜ回答にこれほどの大きな違いがあるのでしょうか？グラフアプローチは、ベクトルベースのアプローチにはない何を提供するのでしょうか？ ベクトル検索では、問われている質問に対して意味的に類似している、つまり言語的に近い情報しか取得できません。類似していない情報は、構造的に取得できません。この例では、 AnyCompany Logistics による Fictitious Canal の使用と、現在 Fictitious Canal を悩ませている閉塞に関する断片情報は、問われている質問との類似性が十分でないため、ベクトルベースのソリューションではコンテキストに取り込まれません。たとえそれらが、より正確で完全な回答を作成する上で極めて重要な情報であったとしてもです。 情報検索における 関連性 (relevancy) は 関係性 (relatedness) という観点で考えることができます。質問に関連するものは、直接的または間接的に、その質問と何らかの関係があります。関係性は 類似性 (similarity) よりも広い概念です。意味的類似性は、私たちが興味を持つものが互いに関係する方法のひとつに過ぎません。例えば、テキスト A と B は意味的に類似しているために関係があると言えるでしょう。しかし、物事が関係を持つ方法は他にもたくさんあります。時間や空間における連続性、因果関係、親子関係、部分-全体関係、あるいは社会的、組織的、法的、分類学的な関係など、このリストは無限に続きます。物事が関係する方法や、それらの関係の相対的な重要性、強さ、質は、業界ドメインによって異なりますが、「意味的に類似している」ことは RAG 検索ツールボックスのひとつのツールに過ぎないと言えます。 私たちのドメインをグラフとしてモデル化し、グラフのエッジを使って私たちにとって重要な異なるタイプの関係を表現することで、質問とは異なるものの、正確で完全な回答を作成する上で構造的に関連する情報へのアクセスを提供できます。 類似性に基づく検索は依然として重要な RAG 戦略であり、質問と意味的に類似したコンテキストは、しばしば良い回答の基礎となります。しかし、類似性に基づく検索だけでは、ニュアンスのある回答を生成するのに常に十分というわけではありません。多くの場合、比較、議論、要約を展開するためのより差別化されたコンテキストを質問応答プロセスに提示するために、ベクトル類似度検索では見つけられない情報を見つけて返す必要があります。グラフ内の関係は、検索プロセスがこのような追加の関連情報を見つけるための手段を提供します。 GraphRAG Toolkit すべての RAG アプリケーションは、インデックス化 (indexing) とクエリ処理 (querying) というふたつのコア機能を中心に構築されています。 GraphRAG Toolkit は、データをグラフとベクトルストアにインデックス化し、このグラフから関連コンテンツを取得する質問応答ソリューションを構築するために使用できるオープンソースの Python ライブラリです。 ツールキットの第 1 版では、非構造化および半構造化テキストコンテンツ (ウェブページ、PDF、JSON ドキュメントなど) を用いてグラフベースの RAG アプリケーションを構築することに焦点を当てています。ツールキットのセットアップと実行の詳細については、この投稿の後半にある「GraphRAG Toolkit のインストール」セクションをご参照ください。 インデックス化 コンテンツのインデックス化は、少量のコードで実現できます。 from graphrag_toolkit import LexicalGraphIndex from graphrag_toolkit.storage import GraphStoreFactory from graphrag_toolkit.storage import VectorStoreFactory from llama_index.readers.web import SimpleWebPageReader import nest_asyncio nest_asyncio.apply() doc_urls = [ 'https://docs.aws.amazon.com/neptune/latest/userguide/intro.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-features.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-vs-neptune-database.html' ] docs = SimpleWebPageReader( html_to_text=True, metadata_fn=lambda url:{'url': url} ).load_data(doc_urls) graph_store = GraphStoreFactory.for_graph_store( 'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com' ) vector_store = VectorStoreFactory.for_vector_store( 'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com' ) graph_index = LexicalGraphIndex( graph_store, vector_store ) graph_index.extract_and_build(docs) LexicalGraphIndex はコンテンツのインデックス化の主要な手段です。この例で示すように、連続取り込み方式で使用できます。コンテンツは一連の抽出とビルドのステージを通してパイプライン処理され、グラフはすぐにデータで埋められ始め、取り込みが続いている最中でもクエリを実行できるようになります。また、抽出とビルドのステージを別々に実行することもできます。1 回限りのジョブを実行する場合だけでなく、同じ抽出されたコンテンツを再利用してグラフを複数回構築したい場合にこの仕組みが役立ちます。 LexicalGraphIndex は、グラフストアとベクトルストアで構成されています。この例では、 Neptune Database グラフストアと Amazon OpenSearch Serverless ベクトルストアを使用しています。執筆時点で、このツールキットは Neptune Database と Neptune Analytics 、OpenSearch Serverless、およびコンテンツの抽出と埋め込みに使用される基盤モデル用の Amazon Bedrock をサポートしています。 前述の例では、インデックス化するコンテンツとして、 Neptune のドキュメントの複数ページを取り込んでいます。データをパースしてインデックスに取り込むために、 LlamaIndex の SimpleWebPageReader を使用しています。ソースデータの種類と場所に応じて、 SimpleDirectoryReader や JSONReader を含む他の LlamaIndex リーダーを使用してデータをインデックスにロードすることもできます。 クエリ処理 クエリ処理、つまり質問応答は、インデックス化と同じくらい簡単です。 from graphrag_toolkit import LexicalGraphQueryEngine from graphrag_toolkit.storage import GraphStoreFactory from graphrag_toolkit.storage import VectorStoreFactory import nest_asyncio nest_asyncio.apply() graph_store = GraphStoreFactory.for_graph_store( 'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com' ) vector_store = VectorStoreFactory.for_vector_store( 'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com' ) query_engine = LexicalGraphQueryEngine.for_traversal_based_search( graph_store, vector_store ) response = query_engine.query('''What are the differences between Neptune Database and Neptune Analytics?''') print(response.response) クエリ処理は実際には 2 段階のプロセスです。基礎となるストレージから関連情報を取得することから始まり、その後、この情報を大規模言語モデルに渡して回答を生成します。 LexicalGraphQueryEngine はこの両方のステップをあなたに代わって実行します。 インデックス化の段階で LexicalGraphIndex を構成したときと同様に、ここでも、グラフストアとベクトルストアを引数にして LexicalGraphQueryEngine を構成しています。一見すると、これは少し冗長に思えるかもしれません。しかし、インデックス化とクエリ処理はそれぞれ異なるプロセスであり、異なる環境で、異なるマシン上で、異なる時間に実行される可能性があります。そのため、各プロセスを構成する際には個別にグラフストアとベクトルストアの URI を指定する必要があります。 GraphRAG Toolkit のインストール プロジェクトの GitHub リポジトリにあるクイックスタート用の AWS CloudFormation テンプレート を使用して、 GraphRAG Toolkit を使い始めることができます。このテンプレートは、 Neptune Database と OpenSearch Serverless コレクション、そしてサンプルコードを含む Amazon SageMaker ノートブックインスタンスを作成します。これらの例では、 Amazon Bedrock の基盤モデルを使用してコンテンツの抽出と埋め込み、および回答の生成を行います。 前提条件 テンプレートを実行する前に、 Amazon Bedrock で適切な基盤モデルへのアクセスを有効にしていることを確認してください。デフォルトのモデルは以下の通りです： anthropic.claude-3-sonnet-20240229-v1:0 cohere.embed-english-v3 クイックスタートの例で構成されているモデル以外でも、ツールキットを 構成する ことができます。 CloudFormation スタックは、これらのモデルを提供している AWS リージョンで実行する必要があり、ノートブック例を実行する前に モデルへのアクセスを有効にする 必要があります。 CloudFormation スタックのデプロイ 以下のスクリーンショットは、 CloudFormation テンプレートのスタックの詳細を示しています。 まず、スタック名を指定する必要があります。ほとんどのパラメータには適切なデフォルト値が設定されていますが、変更したい項目がいくつかあるかもしれません。 ApplicationId – Neptune クラスターとインスタンス、 OpenSearch Serverless コレクションを含むデプロイメント内のリソースの名前付けに使用される一意の識別子を指定する。 IamPolicyArn – SageMaker ノートブックインスタンスにアタッチされる追加の AWS Identity and Access Management (IAM) ポリシーの Amazon リソースネーム (ARN) を指定する。このカスタムポリシーには、特定の Amazon Simple Storage Service (Amazon S3) バケットや追加の Amazon Bedrock 基盤モデルなど、使用したい追加リソースへのアクセス権限を含めることができる。 なお、このテンプレートは以下のリソースを作成します。 3 つのプライベートサブネット、1 つのパブリックサブネット、およびインターネットゲートウェイを持つ仮想プライベートクラウド (VPC) 単一の Neptune サーバーレスインスタンスを持つ Neptune Database クラスター パブリックエンドポイントを持つ OpenSearch Serverless コレクション GraphRAG Toolkit のサンプルノートブックを含む SageMaker ノートブック スタックのデプロイメントが完了したら、 SageMaker サンプルノートブックを開くことができます (スタックの Outputs タブに、ノートブックインスタンスへのリンクを含む NeptuneSagemakerNotebook 出力パラメータがあります)。そして、コンテンツのインデックス化とクエリ処理を開始できます。 ノートブックの実行 ノートブック「 01 – Combined-Extract-and-Build 」は良い出発点です。各ノートブックの最初のセルでは、 GitHub リポジトリからツールキットをインストールします。なお、このインストールは、デプロイメントごとに 1 回だけ実行する必要があるもので、各ノートブックごとに実行する必要はありません。 インストールが完了したら、2 番目のセルを実行できます。これによりサンプルコンテンツのインデックスが作成されます。 インデックス化が完了したら、コンテンツへのクエリ処理を開始できます。 ノートブック「 04 – Querying 」では、ツールキットに含まれる異なるクエリ戦略を試すことができます。 リソースのクリーンアップ デプロイされたリソースはアカウントに課金されます。不要な料金 (米国東部 (バージニア北部) リージョンで約 1.5 ドル/時) が発生しないよう、使用し終わったら スタックを削除 することを忘れないでください。 独自のアプリケーションの構築 ツールキットを使用するためには必ずしもクイックスタート用の CloudFormation テンプレートを起動する必要はありません。独自の環境にツールキットをインストールし、他のライブラリやサービスとツールキットを組み合わせて独自の Python アプリケーションを構築できます (あらかじめ必要なグラフとベクトルストアのリソースをプロビジョニングし、適切な基盤モデルへのアクセスを事前に確保する必要はあります)。 ツールキットとその依存関係は pip を使用してインストールできます (現在、ツールキットは PyPi では配布されていませんが、プロジェクトの GitHub リポジトリ上で頻繁にリリースしています)。最新バージョンをインストールするには、プロジェクトのホームページにある インストール手順 に従ってください。 プロジェクトの ドキュメント には、 インデックス化 と クエリ処理 プロセスの設定と実行に関する多くの例が含まれています。これらの例を自分のアプリケーションで使用するように適応できます。ドキュメントの例はノートブック環境で実行するように書かれています。メインエントリーポイントを持つアプリケーションを構築する場合は、アプリケーションロジックをメソッド内に配置し、 if __name__ == ’__main__' ブロックを追加する必要があります： import os from graphrag_toolkit import LexicalGraphIndex from graphrag_toolkit.storage import GraphStoreFactory from graphrag_toolkit.storage import VectorStoreFactory from llama_index.readers.web import SimpleWebPageReader import nest_asyncio nest_asyncio.apply() def run_extract_and_build(): graph_store = GraphStoreFactory.for_graph_store( 'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com' ) vector_store = VectorStoreFactory.for_vector_store( 'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com' ) graph_index = LexicalGraphIndex( graph_store, vector_store ) doc_urls = [ 'https://docs.aws.amazon.com/neptune/latest/userguide/intro.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-features.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-vs-neptune-database.html' ] docs = SimpleWebPageReader( html_to_text=True, metadata_fn=lambda url:{'url': url} ).load_data(doc_urls) graph_index.extract_and_build(docs, show_progress=True) if __name__ == '__main__': run_extract_and_build() グラフモデルとクエリ戦略の設計 RAG ソリューションを設計する際は、特定のワークロードのニーズをサポートできる適切な検索と生成の戦略、および基盤となるインデックス化とストレージの仕組みを決定するために、Working Backwards (お客様を起点に考える) アプローチを採用するといいでしょう。ワークフローは、どのような質問応答やエンドユーザー、アプリケーションのデータニーズを満たすことを意図していますか？それらのニーズを満たすためにどのようなデータを取得する必要がありますか？どのような検索戦略がこのデータをコンテキストウィンドウに最も効果的に提供しますか？そして、どのようなインデックス構造やデータモデルがそのような検索を最も効率的に促進しますか？ GraphRAG Toolkit は、非構造化および半構造化テキストコンテンツに対する質問応答ワークフローをサポートするように設計されており、特に複数の潜在的に無関係なソースから、またはベクトルベースのソリューションのみでは構造的にアクセスできない情報から関連情報を取得する必要があるワークフローをサポートします。これらは 検索ベース のワークフローと呼ぶことができ、数値結果の計算を必要とする カウントベース や 集計ベース のワークフローとは異なります。 検索ベースのワークフローのニーズを満たすために、システムは質問応答プロセス、つまり基盤モデルに対して関連するテキストコンテンツの断片 (テキストのスニペット、または語彙単位 (lexical unit)) を渡す必要があります。これを念頭に置いて、最初に取り組まなければならない設計上の決定のひとつは、 基盤モデルに提供されるコンテキストの基礎となる語彙単位のサイズはどのくらいにすべきか、ということでした。多くの RAG アプリケーションでは、コンテキストの主要な単位はチャンクです。つまり、コンテキストウィンドウはコーパスから取得されたひとつ以上のチャンクで構成されます。異なるチャンク分割戦略は異なるサイズのチャンクを生成します (チャンクの万能な定義はありません) が、チャンクは通常、個々の文よりも大きく、文書全体よりも小さいものです。 GraphRAG Toolkit では、コンテキストの主要な単位はチャンクではなく、独立した主張や命題である ステートメント (statement) です。ソース文書はチャンクに分割され、これらのチャンクからステートメントが抽出されます。ステートメントは トピック (topic) ごとにテーマ別にグループ化され、 事実 (fact) によって裏付けられます。質問応答時に、ツールキットはトピックでグループ化された関連ステートメントのセットを取得し、基盤モデルのコンテキストウィンドウに渡します。 基盤モデルにステートメントの形で語彙単位を提供するという要件により、 語彙グラフ (lexical graph) モデルと、語彙グラフモデルをターゲットとする抽出プロセスを設計することになりました。この語彙グラフには 3 つの階層があります。 系統 (lineage) – ソース、チャンク、およびそれらの間の関係。下図の水色パート。 要約 (summarization) – トピック、ステートメント、およびステートメントを裏付ける事実。下図の緑色パート。 エンティティ-関係 (entity-relationship) – 基礎となるソースから抽出された個々のエンティティと関係。下図の赤色パート。 以下の図は、全体的な語彙グラフモデルを示しています。 このグラフモデルの詳細については、ツールキットの ドキュメント で確認することができます。このセクションでは、緑色で示されている「要約」階層についてより深く掘り下げます。 グラフモデルを設計する際、私たちはしばしばこのモデルを、興味のある物事を表現する能力という観点で考えます。もうひとつの、しかし補完的な視点は、モデルがサポートすることを意図しているアプリケーションとデータのニーズの文脈における、各モデル要素の役割や責任を考えることです。ツールキットのために特定した検索ベースのワークフローのニーズの文脈では、モデルは質問に直接または間接的に関連する離散的な語彙単位の取得をサポートする必要があります。モデルがこの関連性や接続性 (connectedness) をどのように示し適用するかが、検索戦略の効果を大きく決定します。単にすべてのものをすべてのものに結びつけてしまうと、無関係な情報の海の中から関連するコンテキストの単位を抽出することが難しくなります。一方、グラフ内の要素間の接続をほとんど許可しないモデルは、関連はあるものの意味的に異なる情報を発見する機会を減らします。よく設計されたグラフはバランスを取ります。関連性を薄めてしまう膨大な量の接続を避けながら、文脈的に重要だが明白でない関係を発見するのに十分な接続を確保します。 要約階層の要素は、いくつかの異なる責任を果たします。語彙単位の取得に関して、ステートメント (statement) は基盤モデルに返される主要なコンテキストの単位として機能します。接続性に関して、要約階層はローカルとグローバルの接続性を区別します。トピック (topic) は同じソースから派生したステートメント間のローカルな主題的接続を提供します。事実 (fact) は異なるソースから派生したステートメント間のグローバルな接続を提供します。また、トピックと事実には二次的な責任もあります。トピックはステートメントをグループ化する役割を果たし、事実はステートメントに注釈を付けたりより詳細な情報を提供したりします。ローカルとグローバルの接続性の責任のこの区分により、検索戦略はグラフの探索を制御できます。例えば、リトリーバー (retriever) はより遠い機会を試験的に探索しつつ、主にローカルに留まることを選択できます。あるいは、広く探索し始めてから、最も有望なトピックに絞り込むこともできます。 グラフからコンテンツを取得する際、検索戦略はまずひとつ以上の適切なエントリーポイントを見つけ、その後関連するステートメントに移動します。ベクトルストアはここでエントリーポイントを見つけるのに重要な役割を果たします。現在の語彙グラフの実装では、ステートメントとチャンクの両方が埋め込まれています。そのため、リトリーバーはチャンクレベルまたはステートメントレベルで質問と意味的に類似したエントリーポイントを見つけ、そこから近隣のローカルステートメントを探索し、より間接的に接続された遠いステートメントにホップすることができます。リトリーバーはまた、エンティティ-関係階層のエンティティに対してキーワード検索を実行し、そこからステートメントとトピックに移動することもできます。この方法は通常、より広範なステートメントのセットを生成します。 ツールキットには現在、 TraversalBasedRetriever と SemanticGuidedRetriever というふたつの異なる高レベルのリトリーバーが含まれています。 TraversalBasedRetriever は、ベクトル類似度検索を通じてチャンクを見つけ、これらのチャンクからトピックを通じてステートメントと事実に移動するトップダウン検索と、エンティティのキーワードベースの検索を実行し、事実からステートメントとトピックに進むボトムアップ検索を組み合わせて使用します。 SemanticGuidedRetriever は、ベクトルベースの意味検索と構造化されたグラフ走査を組み合わせます。意味検索とキーワード検索を通じてエントリーポイントを特定し、その後ビーム検索 (beam search) とパス分析 (path analysis) を通じてグラフをインテリジェントに探索し、再ランク付け (reranking) と多様性フィルタリング (diversity filtering) を使用して質の高い結果を得ます。このハイブリッドアプローチにより、正確なマッチングと文脈的な探索の両方が可能になります。 まとめ この記事では、 GraphRAG Toolkit の使い方について説明しました。このオープンソースの Python ライブラリは、構造的に関連する情報を取得するためにグラフを使用する RAG アプリケーションの構築を支援できます。 ぜひ、ご自身のユースケースで ツールキット を試してみて、フィードバックを共有してください。 著者について Ian Robinson は Amazon Neptune のプリンシパルグラフアーキテクトです。著書に「Graph Databases」と「REST in Practice」(いずれも O’Reilly 出版) があり、「REST: From Research to Practice」(Springer) と「Service Design Patterns」(Addison-Wesley) の共著者です。 Abdellah Ghassel は Amazon Neptune の機械学習エンジニアとしてインターンをしています。 本稿の翻訳は AWS Japan の機械学習スペシャリストソリューションアーキテクトの本橋が担当しました。

近年、企業や組織において、生成 AI を自社のプロダクトに組み込む取り組みが広がっています。生成 AI は、テキスト生成、画像や動画の生成、音声生成など、様々な分野で活用されるようになり、業務の効率化や新しい価値の創出などに期待が高まっています。 一方で、生成 AI を自社のプロダクトに組み込むにあたっては、セキュリティ面での課題にも十分に注意を払う必要があります。生成 AI は、機械学習や自然言語処理などの高度な技術を用いて構築されるため、従来のプロダクトとは異なる脆弱性が存在する可能性があります。例えば、生成 AI が不正に操作されて、偽のコンテンツを生成されたり、機微情報が漏洩したりするなど、深刻な影響が生じる可能性が指摘されています。 これらの脅威への対策は、生成 AI に関わるプロダクトを開発する企業や組織にとって重要な課題となっています。生成 AI のセキュリティ対策については、さまざまな組織や団体からセキュリティフレームワークが提案されてきています。このブログでは、OWASP が生成 AI アプリケーションにおける主要な 10 のセキュリティ脅威をまとめた OWASP Top10 for LLM Applications を参照しながら、AWS 上で生成 AI アプリケーションを設計・開発する方が考慮すべきポイントやリスクシナリオを概説します。 OWASP Top10 for LLM Applications は 2024 年 11 月にVersion 2025 が公開 されました。生成 AI の技術や活用が進むにつれて脅威も変化します。このブログでは、以前の Version との差分などに触れながら、具体的な事例や対策方法をご紹介します。生成 AI を安全に活用していくためのヒントが見つかるはずです。ぜひ最後までお読みください。 Amazon Bedrock を用いた基本的な生成 AI アプリケーションのアーキテクチャとコンポーネント AWS 上で構成される生成 AI アプリケーションをベースに OWASP Top 10 for LLM Applications の考慮事項を考えられるように、まずは基本的な生成 AI アプリケーションのアーキテクチャについて説明します。 図 1: 基本的な生成 AI アプリケーションのアーキテクチャの例 構成要素となるコンポーネントの例 以下で、図 1 の基本的な生成 AI アプリケーションのアーキテクチャで扱われているサービスをご紹介します。 Amazon Cognito ：ユーザーがアプリケーションを利用する前に認証を行います。 生成 AI アプリ：ユーザーに対してウェブのインターフェースを提供します。またユーザーのリクエストを処理するために、各コンポーネントとの一連のやり取りをオーケストレーションします。一例として静的コンテンツを Amazon Simple Storage Service (Amazon S3) へホスティングし Amazon CloudFront で配信し、動的コンテンツについては Amazon API Gateway で API としてリクエストを受け付けサーバーレスの AWS Lambda で処理をするように構成する場合があります。または仮想サーバーの Amazon Elastic Compute Cloud (Amazon EC2) やコンテナ実行環境の Amazon Elastic Container Service (Amazon ECS) を利用したウェブサーバやアプリケーションサーバを構成する場合もあります。 Amazon DynamoDB ：ユーザーの会話履歴を NoSQL のデータベースに保存します。 Amazon Bedrock ： 大規模言語モデル (Large Language Model：LLM)：ユーザーのリクエストを基に回答を生成する大規模言語モデルです。 ナレッジベース：LLM が事前学習していない (LLM 自体には学習させたくない) ユーザー固有の情報を生成 AI アプリケーションが利用できるようにするために、他のデータソースとの接続をマネージドに提供します。 埋め込みモデル：データソースに含まれるテキストなどの情報の埋め込みを行いベクトルデータに変換します。 ベクトルデータベース：埋め込みモデルで変換されたベクトルデータを保存し、ユーザからのリクエストに基づいてベクトルデータベース内を検索します。例として Amazon OpenSearch Service などがあります。 Amazon S3：LLM が事前学習していないユーザー固有の情報を生成 AI アプリケーションが利用できるようにするために、ユーザー固有の情報を保管するデータソースです。 生成 AI アプリケーションの動作 事前準備： a. 事前にアプリケーションで利用するユーザー固有の情報を S3 バケットへ格納しておきます。 b. ナレッジベースを S3 がデータソースとするように構成し、データを同期します。これにより S3 バケットに含まれる情報が埋め込みモデルによって処理されます。 c. 埋め込みモデルによって処理された情報はベクトルデータベースである OpenSearch Service へ保管されます。 アプリケーションのデータフロー： ユーザーはアプリケーションにアクセスすると Cognito にリダイレクトされ、認証を行います。 ユーザーはチャットベースのインターフェース上で、リクエストをプロンプトとして記入し送信します。 (過去のチャット履歴を参照するような処理をしている場合) アプリケーションは認証情報に含まれるユーザー ID から過去のチャット履歴を照会し、内容を取得します。 アプリケーションはユーザーのプロンプトに関連する情報を検索するために、プロンプトの文言をナレッジベースで検索します。この動作の過程でユーザーのプロンプトは埋め込みモデルでベクトル化され、ベクトルデータベース上で検索されます。これによりユーザーのプロンプトに関連性の高い情報を効率的に検索することが可能です。結果、アプリケーションはユーザーのプロンプトに関連性の高い情報と、その情報のメタデータ (ファイル名、ファイルのパスなど) を取得します。 アプリケーションは [2] で取得したユーザーのプロンプト、[3] で取得した会話履歴、[4] で取得した関連性の高い情報とそのメタデータを LLM に入力し、LLM の推論結果を取得します。 [5] で取得した LLM の推論結果をユーザーに返答します。 OWASP Top 10 for LLM Applications の概要と更新点 OWASP Top10 for LLM Applications では生成 AI アプリケーションの 10 の主要な脆弱性と、それぞれの脅威の概要やリスクシナリオが各項目ごとに示されています。2023 年 10 月に Version 1.1 が公開されていましたが、2024 年 11 月には Version 2025 がリリースされました。 前回の Version&nbsp; と比べてどのような変更がなされたのでしょうか。図 2 に変更点を独自に整理した内容を記載します。 図 2: OWASP Top 10 for LLM Applications の Version 1.1 と Version 2025 の変更点比較 まず、注目すべきは順位の変化です。以前の Version では 6 位だった「機微情報の漏えい」が 2 位にランクアップしています。一方で、1 位の「プロンプトインジェクション」は変わっていません。 新たな項目として、「LLM07:2025 システムプロンプトの流出」、「LLM08:2025 ベクトル化と埋め込みの脆弱性」の 2 つが追加されました。「システムプロンプトの流出」は、ユーザーの入力のようなユーザープロンプトとは別に、本来は生成 AI アプリケーションの内部で制御に使用されるプロンプト (システムプロンプト) が不正に流出し、悪用される可能性のある脆弱性です。システムプロンプトには機微情報が含まれていたり、不適切な出力を生み出さないような出力を制御する内容が記載されている可能性があるため、システムプロンプトの適切な利用や管理が重要になります。 また、「ベクトル化と埋め込みの脆弱性」は、Retrieval Augmented Generation (RAG) を使用する生成 AI アプリケーションにおけるセキュリティリスクです。RAG では、事前学習済みの言語モデルとベクトル化された外部のデータソースを組み合わせることで、応答の性能と文脈の関連性を高めています。しかし、ベクトルや埋め込みの生成、保存、検索の方法に脆弱性があると、悪意のある行為 (意図的または非意図的) によって有害なコンテンツの注入、モデル出力の操作、機微情報へのアクセスなどが可能になる可能性があります。 OWASP Top 10 for LLM Applications の脆弱性と生成 AI アプリケーションとのマッピング OWASP Top 10 for LLM Applications の各脆弱性を AWS 上で構成する生成 AI アプリケーションで考えられるように、図2 のアーキテクチャ上にマッピングしてみましょう。 図 3: OWASP Top 10 for LLM Applications の各項目のマッピング 今回例示しているような生成 AI を活用したチャットボットのようなシンプルなアプリケーションであっても、各考慮事項がアーキテクチャ上のコンポーネントを幅広くとらえていることが図 3 からも分かります。 本ブログでは、この中から、特に Version 2025 で新たに追加された、LLM07:2025 システムプロンプトの流出と、LLM08:2025 ベクトル化と埋め込みの脆弱性について着目し深堀します。この 2 点以外も重要な観点であり Version 1.1 から内容もアップデートされていますが、引き続き「 OWASP Top 10 for LLM を活用した生成 AI アプリケーションの多層防御セキュリティ設計 」の内容が参考になります。必要に応じてご活用ください。 &nbsp;Version 2025 で追加された新たな考慮事項 LLM07:2025 システムプロンプトの流出 システムプロンプトの流出のリスクとは、モデルの動作を制御するために使用されるシステムプロンプトに、本来第三者に閲覧されるべきではない機微情報が含まれたり、システムプロンプトに記載されるルールやユーザーの役割や権限、フィルタリングなどのセキュリティ制御を他者に知られてしまうことです。開発者はシステムプロンプトに機微情報を含めるべきではなく、セキュリティ制御として使用すべきではないことを理解することが重要です。 システムプロンプトの例として、GitHub で公開されている generative-ai-usecases-jp (通称: GenU) のサンプル実装で記載されている いくつかのユースケースでのシステムプロンプト を例として確認してみましょう。 文章要約ユースケース あなたは文章を要約する AI アシスタントです。 最初のチャットで要約の指示を出すので、その後のチャットで要約結果の改善を行なってください。 翻訳ユースケース 以下は文章を翻訳したいユーザーと、ユーザーの意図と文章を理解して適切に翻訳する AI のやりとりです。 ユーザーは &lt;input&gt; タグで翻訳する文章と、&lt;language&gt; タグで翻訳先の言語を与えます。 また、&lt;考慮してほしいこと&gt; タグで翻訳時に考慮してほしいことを与えることもあります。 AI は &lt;考慮してほしいこと&gt; がある場合は考慮しつつ、&lt;input&gt; で与えるテキストを &lt;language&gt; で与える言語に翻訳してください。 出力は &lt;output&gt; {翻訳結果} &lt;/output&gt;の形で翻訳した文章だけを出力してください。 それ以外の文章は一切出力してはいけません。 システムプロンプトの流出における、予防と緩和戦略は主に 2 点になります。1 つ目は、API キー、認証キー、データベース情報、アプリケーションの権限構造などの機微情報をシステムプロンプトに含めることを避けてください。権限を分離し、機微情報にモデルが直接アクセスしないよう外部で管理することが望ましいです。 Amazon Bedrock Converse API の Tool Use (function calling) では モデルが直接ツールを利用することなく、ユーザー側 (アプリケーション) でツールの実行を行うことが可能です。また Amazon Bedrock Agents では Action Group として Lambda 関数を指定し、モデルには関数の実行権限だけを与え、動的な処理を実装することも可能です。2 つ目は、モデルの厳格な動作の制御にシステムプロンプトを使用することは可能な限り避けることが推奨されます。システムプロンプトを明らかにしないように学習されたモデルもありますが、現時点でモデルが常にこれを遵守する保証はありません。モデルが期待に沿った動作をしているかどうかを判断するための独立した仕組みを用意することが望ましいです。これらは一般にガードレールと呼ばれ、例えば自社で開発する生成 AI アプリケーションが有害なコンテンツを生成していないかの検出と防止はモデルの外部で行うべきです。 Amazon Bedrock Guardrails のコンテンツフィルターでは、有害なコンテンツの判定が可能です。マルチモーダルにも対応しており、 テキストデータに加えて画像の検出にも活用可能 です。 (筆者注) Amazon Bedrock Guardrails は 2025 年 1 月 16 日時点で 公式には英語、スペイン語、フランス語のみをサポートしており 、他の言語でテキストコンテンツを評価すると、信頼できない結果になる可能性があります。テストデータで検証し、実装方法をご検討ください。 LLM08:2025 ベクトル化と埋め込みの脆弱性 RAG を使用する生成 AI アプリケーションの考慮事項として、不適切なアクセス制御や 反転攻撃 (モデルをリバースエンジニアリングする攻撃) によるデータの流出、ナレッジの競合、データの汚染、モデルの振る舞いへの影響などがあります。これらに対する予防・緩和戦略として 3 つの観点を掘り下げてみます。 アクセス制御： ユーザー固有の情報の保護のために適切なアクセス制御が必要です。ここでは AWS アカウントと RAG の 2 つの観点で考えてみましょう。まずは AWS アカウントについて、関係者を洗い出してみます。生成 AI アプリケーション開発者はもちろん、精度評価や改善を行うデータサイエンティスト、マルチアカウント環境の管理者や監査人などです。次にユーザー固有の情報が含まれるコンポーネントを特定します。S3 や OpenSearch、DynamoDB、またモデル呼び出しのログを記録する場合はログを格納する Amazon CloudWatch Logs や S3 などです。これらを踏まえ、アイデンティティベース、あるいはリソースベースのポリシーを活用し適切にアクセス制御を行います。厳格にアクセス制御を行うことが難しい場合、代わりに Amazon GuardDuty のような脅威検出サービスを使って S3 バケットへの異常な振る舞いや脅威を検知したり、 S3 や DynamoDB のデータに対するアクセスを AWS CloudTrail のデータイベントとして取得し、データに対するアクセスを追跡できるようにしておくことも考えられます。 続いて、ユーザーの所属する部署などに応じて参照可能なデータのみを RAG のコンテキストとして扱うケースを考えてみます。この場合、ユーザーやユーザーが所属する部署などの識別子を Cognito から取得したトークンから確認し、適切に参照する情報を制御できる必要があります。 ナレッジベースのマルチテナントに関する考察（英語） や メタデータを用いたフィルタリング をご参考いただいたり、ナレッジベースの代わりに ユーザーに応じたアクセス制御をサポートしている Amazon Kendra を利用することも考えられます。 データのバリデーションとデータソースのリスク評価： RAG で参照するデータのバリデーションを適切に行うことで、ユーザー固有の情報に含まれる個人情報などの流出から保護します。一例として、S3 にデータを格納する際に個人情報をマスクする前処理を行うパイプラインを構成しているケースがあります。データがアップロードされるとパイプラインが自動で起動し、文書の中から個人情報に該当する氏名や電話番号、メールアドレス、社員番号などの情報がマスクされてから、ナレッジベースが参照する S3 バケットにデータが格納されます。これにより、アプリケーションを通して個人情報が公開されるリスクを低減します。 またデータソースのデータが安全に利用できるものであるかリスク評価を行うことが重要です。例としてナレッジベースのデータソースタイプとして Web クローラーを活用する場合、参照先が信頼できる情報ソースなのか十分にリスク評価する必要があります。特に参照する Web サイトが任意の第三者が任意の記載を行うことができる場合、データの汚染を引き起こし、それが悪意あるプロンプトを含んでいる場合に間接的なプロンプトインジェクションが生じる可能性があります。 ログの取得と評価・分析： 悪意あるプロンプトやナレッジの競合などモデルの振る舞いに影響となる要因を特定し対処するために、ログの取得と評価や分析を行います。一例として、ナレッジベースに対して実行された処理にて、どのような情報を取得したかアプリケーションでログとして出力するように構成できます。また、ユーザーの入力と最終的にモデルが生成した出力は、アプリケーション上、あるいはモデル呼び出しのログ記録でログ取得ができます。アプリケーションが意図しない応答をしていることが分かった場合、ログを調査することでどのユーザーが行ったことなのか、意図しない応答を引き起こしたプロンプトがユーザーの入力と RAG で参照した情報のどちらに含まれていたのかを追跡できます。またアプリケーションの開発体制にデータサイエンティストが入ることで、ログの評価・分析を行う場合があります。 RAGAS などを用いて RAG の精度評価を行い、検索時と生成時のどちらに課題があるかを切り分け、分析に基づくパラメータのチューニングやアプリケーションの改修など RAG の改善活動を行います。 このような予防緩和戦略を取り入れ、図 1 のアーキテクチャの例をアップデートしたものが図 4 となります。 図 4: ベクトル化と埋め込みの脆弱性に対する予防緩和戦略の実装例 まとめ 本ブログでは生成 AI アプリケーションにおける主要な 10 のセキュリティ脅威をまとめた OWASP Top10 for LLM Applications で挙げられている脅威の概要について触れ、特に Version 2025 で新たに追加されたシステムプロンプトの流出とベクトル化と埋め込みの脆弱性について記載しました。本内容が生成 AI アプリケーションの開発に関わられている皆様の参考になれば幸いです。 著者について 片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。 &nbsp; &nbsp; 藤浦 雄大 (Yuta Fujiura) は AWS Japan のプロフェッショナルサービス本部所属のセキュリティコンサルタントです。生成 AI セキュリティリードを担当し、生成 AI セキュリティや責任ある AI のトレーニング、アセスメント、ガイドライン策定などでお客様をご支援しています。また生成 AI に関するブログ翻訳も数多く担当しています。余暇はブロックでオリジナル作品を作っています。

お客様は常に AWS の支出をよりよく理解する方法を探しています。多くのお客様が、特定のチームがどのくらい支出をしているか、特定のアプリケーションの実行コストはどのくらいか、様々な組織的な取り組みにおける節約の機会はどのくらいあるかについて知りたがっています。リソースレベルのコストの透明性を提供できることは、AWS クラウドへの移行の大きなメリットです。このような詳細な可視化を実現するカギは、包括的かつ組織的なタグ付け戦略の実装と適用です。 コスト配分戦略を実装するためのツール この投稿では、組織のコスト意識を向上させるタグ付け戦略を定義・実装・適用するために使用できるツールと、その使用方法について紹介します。最初のツールは AWS Cost Explorer です。これは、組織の支出に関するより深い洞察をもたらす説得力のある可視化により、AWS のコストや使用状況の分析や管理を可能にしてくれます。Cost Explorer を使用すると、日次で更新される過去 12 か月間のコストデータを取得できます。日付範囲、アカウント、サービス、リージョンなど、様々なパラメーターでデータをフィルタリングできます。 コスト使用状況データを詳細にするために、リソースに「タグ」を適用することができます。タグはキーと値のペアで、AWS リソースにメタデータを追加したり、タグ値ごとにコスト使用状況データを要約したりすることができます。タグはキーと値のペアであるため、組織に合った名前 (キー) を作成したり、ビジネスにとって意味のある値を使ったりできるような柔軟性があります。たとえば、組織において “CostCenter” を使用してコストを追跡することができます。AWS では、CostCenter というキーのタグをリソースに割り当て、そこにそのリソースの課金先となる CostCenter を表す値 (例：CostCenter=12345) を割り当てることができます。 また、タグポリシーおよびサービスコントロールポリシーと呼ばれる、 AWS Organizations の 2 つの機能についても見ていきます。これらのポリシーは遡及的には機能しないため、過去に作成された “タグの付与されていないリソース” を識別しやすくするためには AWS Tag Editor (タグエディタ) を使用します。そして、 AWS Config は継続的な戦略のコンプライアンスをサポートします。 タグ付け分類の作成 タグを使用するとさらに詳細な情報を得られるため、組織レベルでのタグ付け戦略と、それを適用する方法を確立することが重要です。ベストプラクティスとしては、タグの分類を定義して、すべてのビジネスユニットに推奨されるタグを整理するところから始めるのがよいでしょう。タグは様々な目的でリソースに関連付けることができます。技術タグは識別情報を提供します。オートメーションタグは開始/停止時間をスケジュールしたり、リソースを自動的にバックアップする必要がある場合に役立ちます。ビジネスタグは所有者やビジネスコンテキストを追加し、セキュリティタグはデータセキュリティ上の懸念事項を定義するのに役立ちます。以下にこれらの例を示します。 図 1. タグの分類とタイプの例 すべてのビジネスユニットに適用されるタグ付け戦略を実装する際には、その戦略が適切にドキュメント化されているのを確認することが重要です。以下に組織で必須となるタグの詳細を記載したタグ分類ドキュメントの例を示します。 図 2. 必須タグ例のタグ分類 タグ付け戦略のアプローチ 組織は通常、タグ付け戦略を実装する際に 2 つの異なる方法に従います。すべてのポリシーをトップダウンで実装するか、子組織が自分でタグを定義できるようにするかのどちらかです。どちらにも長所と短所があります。トップダウン型のアプローチは、定義と設定に時間がかかりますが、組織全体のコストの可視性が向上する可能性があります。一方、子組織が自分でタグ付け要件を柔軟に決定できるようにすると、俊敏性は向上しますが、組織全体の AWS 支出を分析しようとする際に一貫性が失われる可能性があります。 これら 2 つの戦略を組み合わせることが、おそらく最も効果的なアプローチでしょう。たとえば、組織の最上位レベルでは、下の図に示すように、すべてのチームと組織ユニットが従うビジネスタグ付け戦略を適用できます。そのあとで、個々のユニットは自主性と柔軟性をもって追加となるビジネス固有のタグを実装することができます。 許容できるキー値を定義することで、タグ分類ドキュメント内のタグをさらに細かく指定できます。たとえば、今回の CostCenter タグの例では、ビジネスユニットまたは部門を表す “Two Digit Division (2 桁の部門)” を追加しました。また、コストを追跡するために、プロジェクト、アプリケーション、チーム、その他のグループを表す “Four Digit Code (4 桁のコード)” も追加しました。これにより、各ビジネスユニットは、リソースを適切に識別するための適切なタグ付け規則を明確に把握できます。タグ付け戦略を明確に定義してドキュメント化したら、適用に移ることができます。 図 3. CostCenter タグ例のタグドキュメント タグ付けポリシーの適用 タグ付け戦略が組織全体に浸透したら、AWS Organization 内で必須のタグの設定を開始できます。目標は、AWS リソースの作成時に、新たな標準化されたタグ付けポリシーを適用することです。ここでの例では、特定のタグに必須の ”事前定義済みの値“ がない場合、Amazon EC2 インスタンスの作成は拒否されます。今回は、カスタム CostCenter タグを使用します。 1. まず最初に、管理アカウントの AWS Organizations コンソールに移動し、[Policies (ポリシー)] を選択します。次に [Tag policies (タグポリシー)] をクリックします。 図 4. AWS Organizations ポリシーページのタグポリシー部分 2. 次に、上記の例で定義した値を使用して、CostCenter タグのタグポリシーを作成します。このポリシーを Amazon EC2 インスタンスに適用し、組織によって指定された値でなければ、CostCenter タグを使用してリソースを作成することを禁止するようにします。 画面上部のタグポリシーに名前を付けます。ポリシーの説明を追加することもできます。この画面の中央では、ポリシー自体にタグを追加して、誰がポリシーを作成したかを追跡できます (ポリシーが適用されるリソースではなく、ポリシー自体にタグを付けることに注意してください)。“Visual editor (ビジュアルエディタ)” タブ内でタグキーを定義できます。ここでの例ではそれを “CostCenter” としています。 CostCenter タグキーの下にある、大文字と小文字の区別を確認するボックスにもチェックを入れます。これにより、タグの大文字と小文字が区別される (case-sensitive) ため、タグキーフィールドで指定されたとおりに正確に入力する必要があります。 “Allowed values (許容される値)” セクションで、CostCenter タグキーに使用できる値を指定するボックスにチェックを入れます。次に、上記の例で定義した CostCenter 値のリストを追加します。 最後に、“Resource types enforcement” (リソースタイプの強制)” セクションで、”Prevent noncompliant operations for this tag (このタグの非準拠操作を防止します)” をクリックします。リストから “ec2:instance” を選択します。これにより、Amazon EC2 インスタンスに CostCenter タグが含まれていて、かつタグ付けポリシーに基づく有効な値がない場合には、Amazon EC2 インスタンスが起動されなくなります。 図 5. タグポリシー設定ページ 3. この新しく作成されたポリシーを組織全体で確実に適用するには、組織単位 (OU) にポリシーをアタッチする必要があります。そのためには、タグポリシーページに戻り、先ほど作成した “CostCenterTagPolicy” を選択します。次に “Actions (アクション)” を選択し、“Attach policy (ポリシーのアタッチ)” をクリックします。 図 6. 既存のタグポリシーページでのポリシーのアタッチ 4. 次の画面では、新しいタグポリシーが特定の組織単位 (OU) にアタッチされていることを選択して確認できます。 図 7. 組織単位 (OU) へのタグポリシーのアタッチ 5. それでは、Amazon EC2 コンソールに移動して、適切な CostCenter タグ値を指定せずに新しい Amazon EC2 インスタンスを起動してみましょう。 図 8. EC2 コンソールでのタグ付けポリシーのテスト 6. 必須のタグポリシー値を指定せずにこのインスタンスを起動しようとすると、エラーが表示されます。 図 9. 許可されていない CostCenter タグ値であることにより EC2 の起動に失敗 タグポリシーが設定されたため、タグポリシー内の CostCenter タグに設定した値パラメーターに従わないリソースを、組織が起動できなくなりました。ただし、これでは CostCenter タグキーそのものがない場合はリソースを起動できてしまいます。それを防ぐためには、サービスコントロールポリシー (SCP) を利用します。 タグの適用の強化 ユーザーが特定のタグを含めていない場合はリソースを起動できないようにするなど、タグ付けの適用に関するより厳しいポリシーが必要な場合は、 サービスコントロールポリシー (SCP) を使用できます。SCP により、組織内のすべてのアカウントで使用可能な最大権限を一元的に制御できます。SCP を使用すると、CostCenter タグなどの特定のタグが含まれていない場合に特定のアクションを拒否できます。 このタイプの SCP の例を以下に示します。作成すると、先程作成したタグ付けポリシーをアタッチしたのと同じように、特定の組織単位 (OU) にアタッチできます。 SCP を定義する には、管理アカウントの AWS Organizations ページに移動し、“ポリシー (Policies)” をクリックしてから “サービスコントロールポリシー (Service Control Policies)” をクリックします。 図 10. CostCenter タグを必要とするサービスコントロールポリシー (SCP) の例 注: SCP の使用は完全にオプションであり、特にタグコンプライアンスに関するガバナンスのレベルを高めることができます。ただし、SCP の使用は慎重に行うべきです。SCP の設定は既存のリソースに影響を与える可能性があります。たとえば、必須である CostCenter キーが設定されていないリソースのオートスケーリングプランでは、SCP がスケーリング動作を妨げる可能性があります。既存のリソースを持つ組織に SCP を導入する場合は、この点を必ず考慮してください。 タグコンプライアンスの理解 この新しいタグ付けポリシーのコンプライアンスを継続的に検証するには、AWS Config を使用できます。AWS Config には、AWS アカウントの AWS リソースの設定の詳細が表示されます。AWS Config ルール、特に “required-tags” ルールを使用すると、リソースに必要なタグがあるかどうかをチェックできます (つまり、Amazon EC2 インスタンスに、先程作成した CostCenter タグが付いていることを確認できます)。 タグコンプライアンスをモニタリングするには、AWS Config コンソールページに移動し、左側のナビゲーションメニューから “ルール (Rules)” を選択します。 図 11. AWS Config ルールセクション画面 新しいルールを追加する方法の詳細はこのブログの範囲外ですが、required-tags 組み込み設定ルールの使用方法の詳細は AWS Config ドキュメント に記載されています。AWS Config と SCP により、組織全体にタグ付けポリシーをさらに適用し、長期的なコンプライアンスを検証できます。 しかし、新しいタグ付けポリシーに準拠していない可能性のある既存のリソースについてはどうでしょうか？これらのリソースをコンプライアンスに準拠させるにはどうすればよいでしょうか？ タグエディタによるタグなしリソースの識別 タグ付けポリシー実装の最後のステップは、過去にタグなしでプロビジョニングされたリソースに対処することです。これはタグエディタを使うことで実行できます。 タグエディタを使用するには、AWS マネジメントコンソールに移動し、“Resource Groups &amp; Tag Editor” を検索してクリックします。 次に、左側のナビゲーションにある “タグ付け (Tagging)” の下にある “タグエディタ (Tag Editor)” をクリックします。 タグエディタページで、まずリソースを検索したいリージョンを選択します。この例では “All regions” を検索します。 次に、検索するリソースタイプを設定します。この例では、Amazon EC2 インスタンスを検索します。 最後に、検索するタグを入力します。ここでは、CostCenter タグが付いていないすべての Amazon EC2 インスタンスを検索します。 条件を満たすリソースのリスト、つまり CostCenter タグのついていない、すべてのリージョンのすべての Amazon EC2 インスタンスのリストが表示されます。結果を CSV にエクスポートし、組織内の従業員に通知して対応を依頼できます。 図 12. タグエディタの設定画面 注: タグエディタは単一のアカウントでのみ実行でき、組織レベルでは実行できません。組織内の各アカウントでタグが付いていないリソースを識別するには、各アカウントでタグエディタを使用する必要があります。 コスト配分タグを有効化する 新しく実装したタグ付け戦略を使って Cost Explorer でのコスト分析を開始する前に、コストと使用状況に関するレポート作成用にタグを有効化する必要があります。“請求とコスト管理” コンソールを開いて “コスト配分タグ (Cost Allocation Tags)” を選択し、新しく作成した CostCenter タグを有効化します。リソースにタグを付けてタグを有効化するまで、AWS Cost Explorer にはこれらのタグを適用した結果は表示されません。 図 13. ”請求とコスト管理“ コンソールでのコスト配分タグの有効化 AWS Cost Explorer での支出の可視化と分析 タグ付け戦略を実装し、“請求とコスト管理” コンソールでタグを有効化すると、AWS Cost Explorer を使用して個々のコストセンターのコストを分析できます。この例では、個々のコストセンターの支出をサービスごとに表示できます。 図 14. Cost Explorer レポート (フィルターなし) Cost Explorer を使用してコストを確認する際、タグ付けされているはずなのに以前の期間のコストには反映されておらず混乱してしまうことがあるかもしれません。タグ付けは遡って適用されることはなく、(タグ付け以降の) 将来のコストと使用状況のレポートにのみ正確に反映されます。 Cost Explorer を使用すると、適切な CostCenter タグが関連付けられていないアカウントのうち、最も支出が多いアカウントを分析できます。これを行うには、ディメンションを “連結アカウント (Linked Account)”、タグのフィルターを “CostCenter”、およびタグ値を “タグキーがありません :CostCenter (No tag key: CostCenter)” に設定した Cost Explorer レポートを作成します。 図 15. Cost Explorer レポート (“タグキーがありません :CostCenter” フィルターを適用した場合) このようなレポートを使用すると、組織はこれらの (タグ付けされていないリソースのある) 特定のアカウントが新しいタグ付け戦略を実装できるよう支援できます。時間が経過とともに、コストセンター別に組織の AWS 支出の詳細な内訳を示す追加の Cost Explorer レポートを作成できるようになります。 図16. Cost Explorer レポート (ディメンションを “CostCenter” タグにした場合) まとめ このブログでは、AWS アカウント内のタグ付けされていないリソースの識別を含む、組織のタグ付け戦略の定義・実装・適用に役立つプロセスの概要を説明しました。これが完了すると、Cost Explorer を使用して、これらのタグを使用して AWS のコストと使用状況を可視化・理解・管理・レポートすることができます。その結果、組織のコストに対する可視性と認識が高まるだけでなく、個々のビジネスユニットのコストの結果責任が促進され、クラウドコストの最適化とビジネス価値の実現にプラスの影響を与えることができます。 TAGS: AWS Billing Console , AWS Cost Explorer , AWS Organizations , Tagging Policies , Track and Allocate Ryan Doty Ryan Doty は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。革新的でスケーラブルなソリューションを設計するためのアーキテクチャガイドラインを提供することで、米国北東部のエンタープライズカスタマーが AWS クラウドの採用を加速できるよう支援しています。ソフトウェア開発とセールスエンジニアリングのバックグラウンドを持つ彼は、クラウドが世界にもたらす可能性にワクワクしています。仕事以外では、コンピューターゲームをしたり、リバプール FC を応援したりすることが大好きです。 Bert Zahniser, CISSP, CCSP Bert Zahniser は、フィラデルフィア地域を拠点とする AWS のシニアソリューションアーキテクトです。IT インフラストラクチャで 30 年以上の経験があり、情報セキュリティに重点を置いています。彼はクラウド採用の強力な提唱者であり、クラウド移行中のお客様がセキュリティとガバナンスを念頭に置いて AWS でソリューションを設計および実装できるよう支援しています。仕事以外では、野球やアイスホッケーが好きで、ゴルフやクラフトビールの醸造所を訪れるのが大好きです。 Vishal Manan Vishal Manan は、シアトルを拠点とする AWS のスペシャリストソリューションアーキテクトです。お客様が Graviton プロセッサ (クラウドでは arm64) を使用して、費用対効果やパフォーマンスが高く、持続可能な EC2 コンピューティングインスタンスを採用できるよう支援しています。プラットフォームソフトウェア開発のスキルとコンサルティングのバックグラウンドを AWS クラウドに活かせることに興奮しています。仕事以外では、父親であること、料理をすること、ゴルフをすること、ハイキングをすることが大好きです。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。