本ブログは 2025 年 4 月 7 日に公開された AWS Blog “ ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager ” を翻訳したものです。 Amazon Web Services (AWS) は、TLS 向けの 最新のハイブリッドポスト量子鍵共有標準 のサポートを 3 つの AWS サービスで開始したことを発表しました。本日 (2025 年 4 月 7 日) より、 AWS Key Management Service (AWS KMS) 、 AWS Certificate Manager (ACM) 、 AWS Secrets Manager のエンドポイントは、中国・GovCloud を除く全商用リージョンの非 FIPS エンドポイントで、ハイブリッドポスト量子鍵共有のための ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) をサポートするようになりました。 AWS SDK for Rust をベースに構築された Secrets Manager Agent も、 ハイブリッドポスト量子鍵共有のオプトインサポート を提供するようになりました。これにより、エンドツーエンドでポスト量子対応の TLS を使用して、アプリケーションにシークレットを取り込むことができます。 AWS は、ポスト量子の機密性を最も緊急に必要とするセキュリティ上重要なサービスとして、これら 3 つを優先的にサポートしてきました。これらのサービスは、ML-KEM の前身である CRYSTALS-Kyber のサポートを以前から提供 しています。CRYSTALS-Kyber のサポートは 2025 年まで継続されますが、2026 年にはすべての AWS サービスのエンドポイントで ML-KEM に置き換わります。 ポスト量子暗号への移行 AWS は ポスト量子暗号移行計画 に従うことをコミットしています。このコミットメントの一環として、 ポスト量子暗号における AWS の責任共有モデル に従い、AWS は今後数年間で HTTPS エンドポイントを持つすべての AWS サービスに ML-KEM のサポートを拡大する予定です。AWS をご利用のお客様は、AWS サービスの HTTPS エンドポイントに接続する際に ML-KEM を提供できるよう、TLS クライアントと SDK を更新する必要があります。これにより、量子コンピューティングの進歩がもたらす将来の「harvest now, decrypt later (今収集して、後で復号) 」攻撃の脅威から保護されます。一方、AWS サービスの HTTPS エンドポイントは、クライアントから ML-KEM が提示された場合、それを選択する責任を負います。 ハイブリッドポスト量子鍵共有アルゴリズムをネゴシエートするという AWS のコミットメントは、AWS 全体で使用されている オープンソースの FIPS 140-3 認証暗号ライブラリ である AWS Libcrypto (AWS-LC) と、AWS サービスの HTTPS エンドポイント全体で使用されているオープンソースの TLS 実装である s2n-tls によって実現されています。AWS-LC は NIST から複数の FIPS 認証 ( #4631 、 #4759 、 #4816 ) を取得しており、 FIPS 140-3 検証に ML-KEM を含めた最初のオープンソース暗号モジュール でした。 ハイブリッドポスト量子 ML-KEM が TLS パフォーマンスに与える影響 ECDH (楕円曲線ディフィー・ヘルマン) のみの鍵共有から ECDH+ML-KEM ハイブリッド鍵共有への移行では、TLS ハンドシェイクでより多くのデータを送信し、より多くの暗号処理を実行する必要があります。従来の鍵共有からハイブリッドポスト量子鍵共有に切り替えると、TLS ハンドシェイク中に約 1600 バイトの追加データが転送され、ML-KEM 暗号処理を実行するために約 80〜150 マイクロ秒の追加計算時間が必要になります。これは TLS 接続の開始時に 1 回だけ発生するコストであり、その接続中に送信される複数の HTTP リクエストに分散されます。 AWS は、TLS のハイブリッドポスト量子鍵共有へのスムーズな移行を実現するために取り組んでいます。この取り組みには、ML-KEM によるハイブリッドポスト量子鍵共有を有効にした場合の影響をお客様が理解できるよう、サンプルワークロードでのベンチマークの実施が含まれます。 AWS SDK for Java v2 を使用して、 Amazon Elastic Compute Cloud (Amazon EC2) の C6in.metal インスタンス上のクライアントと、AWS KMS のパブリックエンドポイント間で、単一スレッドがシリアルに発行できる 1 秒あたりの AWS KMS GenerateDataKey リクエスト数を測定しました。クライアントとサーバーはいずれも us-west-2 リージョンを使用しました。AWS KMS への従来の TLS 接続は鍵共有に楕円曲線 P256 をネゴシエートし、ハイブリッドポスト量子 TLS 接続はハイブリッド鍵共有に楕円曲線 X25519 と ML-KEM-768 をネゴシエートしました。実際のパフォーマンス特性は環境によって異なり、インスタンスタイプ、ワークロードプロファイル、並列処理の量とスレッド数、ネットワークの場所と容量によって変わります。HTTP リクエストのトランザクションレートは、TLS 接続の再利用を有効にした場合と無効にした場合の両方で測定されました。 図 1 は、TLS 1.3 接続の再利用を無効にした場合の、さまざまなパーセンタイルで発行された 1 秒あたりのリクエスト数を示しています。最悪のシナリオ、つまり TLS ハンドシェイクのコストが分散されず、すべての HTTP リクエストで完全な TLS ハンドシェイクを実行する必要がある場合、ハイブリッドポスト量子 TLS を有効にすると、1 秒あたりのトランザクション数 (TPS) が平均で約 2.3% 減少し、108.7 TPS から 106.2 TPS になります。 図 1: TLS 接続の再利用 なし の AWS KMS GenerateDataKey の 1 秒あたりのリクエスト数 図 2 は、TLS 接続の再利用を有効にした場合の、さまざまなパーセンタイルでの 1 秒あたりのリクエスト数を示しています。TLS 接続を再利用して TLS ハンドシェイクのコストを多くの HTTP リクエストに分散することは、AWS SDK for Java v2 のデフォルト設定です。デフォルトの SDK 設定でハイブリッドポスト量子 TLS を有効にした場合、TPS レートはほぼ変わらず、平均でわずか 0.05% の減少 (216.1 TPS から 216.0 TPS) にとどまることが確認できます。 図 2: TLS 接続の再利用 あり の AWS KMS GenerateDataKey の 1 秒あたりのリクエスト数 この結果から、SDK の一般的な設定を使用した場合、ハイブリッドポスト量子 TLS を有効にしてもパフォーマンスへの影響はほとんどないことがわかります。測定結果によると、デフォルト設定のワークロード例でハイブリッドポスト量子 TLS を有効にしても、最大 TPS レートの低下はわずか 0.05% でした。また、SDK のデフォルト設定を上書きして、すべてのリクエストで新しい TLS ハンドシェイクを実行する最悪のシナリオを強制した場合でも、最大 TPS レートの低下は 2.3% にとどまりました。 以下の表は、測定したベンチマークデータです。各ベンチマークでは、TLS 鍵共有設定と TLS 接続再利用設定を変えながら、500 回の 1 秒間 TPS 測定を実施しました。測定には AWS SDK for Java v2 の v2.30.22 を使用しました。TLS 鍵共有は、 postQuantumTlsEnabled() 設定を切り替えることで、従来方式とハイブリッドポスト量子方式を切り替えました。TLS 接続の再利用は、 各 HTTP リクエスト に Connection: close HTTP ヘッダーを挿入することで切り替えました。このヘッダーにより、各 HTTP リクエスト後に TLS 接続が強制的に切断され、HTTP リクエストごとに新しい TLS 接続を作成する必要があります。 TLS 鍵共有 TLS 接続再利用 HTTP リクエスト総数 平均 (TPS) p01 (TPS) p10 (TPS) p25 (TPS) p50 (TPS) p75 (TPS) p90 (TPS) p99 (TPS) 従来方式 (P256) なし 54,367 108.7 78 86 96 102 129 137 145 ハイブリッドポスト量子 (X25519MLKEM768) なし 53,106 106.2 76 85 93 100 126 134 141 従来方式 (P256) あり 108,052 216.1 181 194 200 216 233 240 245 ハイブリッドポスト量子 (X25519MLKEM768) あり 107,994 216 177 194 200 216 233 239 245 ポスト量子暗号ドラフト仕様のサポート終了 ML-KEM の前身である CRYSTALS-Kyber をサポートする AWS サービスのエンドポイントは、2025 年まで CRYSTALS-Kyber のサポートを継続します。お客様が ML-KEM 標準に移行した後、標準化前の CRYSTALS-Kyber 実装のサポートを段階的に終了していきます。CRYSTALS-Kyber をサポートする以前のバージョンの AWS SDK for Java をご利用のお客様は、ML-KEM をサポートする最新の SDK バージョンにアップグレードしてください。AWS SDK for Java v2 の一般提供リリースをご利用のお客様は、CRYSTALS-Kyber から ML-KEM へのアップグレードにコード変更は必要ありません。 現在 CRYSTALS-Kyber をネゴシエートしているお客様が 2026 年までに AWS Java SDK v2 クライアントをアップグレードしない場合、AWS サービスの HTTPS エンドポイントから CRYSTALS-Kyber が削除されると、クライアントは従来の鍵共有に自動的にフォールバックします。 ハイブリッドポスト量子鍵共有の使用方法 AWS SDK for Rust をご利用の場合は、crate に rustls パッケージを追加し、 prefer-post-quantum 機能フラグを有効にすることで、ハイブリッドポスト量子鍵共有を有効にできます。詳細については、rustls の ドキュメント を参照してください。 AWS SDK for Java 2.x をご利用の場合は、AWS Common Runtime HTTP クライアントを構築する際に .postQuantumTlsEnabled(true) を呼び出すことで、ハイブリッドポスト量子鍵共有を有効にできます。 ステップ 1: AWS Common Runtime HTTP クライアントを Java の依存関係に追加する AWS Common Runtime HTTP クライアントを Maven の依存関係に追加します。利用可能な最新バージョンの使用をお勧めします。ML-KEM を使用するには、バージョン 2.30.22 以降が必要です。 <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>aws-crt-client</artifactId> <version>2.30.22<version> </dependency> ステップ 2: Java SDK クライアント設定でポスト量子 TLS を有効にする AWS サービスクライアントを設定する際に、ポスト量子 TLS を有効にした AwsCrtAsyncHttpClient を使用します。 // ポスト量子 TLS を有効にした AWS Common Runtime HTTP クライアントを設定 SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder() .postQuantumTlsEnabled(true) .build(); // AWS Common Runtime クライアントを使用する AWS サービスクライアントを作成 KmsAsyncClient kmsAsync = KmsAsyncClient.builder() .httpClient(awsCrtHttpClient) .build(); // ポスト量子鍵共有を使用する TLS 接続経由でリクエストを実行 ListKeysResponse keys = kmsAsync.listKeys().get(); ポスト量子 TLS セットアップのエンドツーエンドの例については、 KMS PQ TLS サンプルアプリケーション を参照してください。 検証のポイント ポスト量子対応クライアントを検証する際のポイントをご紹介します。 負荷テストとベンチマークの実行: AwsCrtAsyncHttpClient はパフォーマンスに最適化されており、Linux ベースの環境では AWS Libcrypto を使用します。まだ AwsCrtAsyncHttpClient を使用していない場合は、デフォルトの SDK HTTP クライアントと比較してパフォーマンスの向上を確認してみてください。AwsCrtAsyncHttpClient を使用した後、ポスト量子 TLS サポートを有効にしてください。ポスト量子 TLS を有効にした AwsCrtAsyncHttpClient が、ポスト量子 TLS なしのデフォルト SDK HTTP クライアントと比較して、全体的なパフォーマンス向上につながるかどうかを確認してみてください 異なるネットワークロケーションからの接続試行: リクエストが通過するネットワークパスによっては、中間ホスト、プロキシ、または ディープパケットインスペクション (DPI) を備えたファイアウォールがリクエストをブロックする場合があります。その場合は、セキュリティチームまたは IT 管理者と協力して、ネットワーク内のファイアウォールを更新し、 これらの新しい TLS アルゴリズムのブロックを解除 する必要があるかもしれません。この新しい TLS トラフィックとお客様のインフラストラクチャがどのように相互作用するかについて、 ぜひお聞かせください まとめ ML-KEM ベースのハイブリッド鍵共有のサポートが、セキュリティ上重要な 3 つの AWS サービスのエンドポイントで開始されました。TLS 接続の再利用を有効にした場合、ハイブリッドポスト量子 TLS を有効にしてもパフォーマンスへの影響はほとんどありません。AWS の測定では、AWS KMS の GenerateDataKey を呼び出した際の最大 TPS の低下はわずか 0.05% でした。 バージョン 2.30.22 以降、AWS SDK for Java v2 は、AWS Common Runtime HTTP クライアントを使用する Linux ベースのプラットフォームで ML-KEM ベースのハイブリッド鍵共有をサポートしています。今すぐ Java SDK クライアント設定で ポスト量子鍵共有を TLS で有効にする ことをお試しください。 AWS は、 ポスト量子暗号移行計画 の一環として、今後数年間ですべての AWS サービスの HTTPS エンドポイントに ML-KEM ベースのハイブリッドポスト量子鍵共有のサポートを拡大する予定です。 お客様は、AWS サービス HTTPS エンドポイントに接続する際に ML-KEM 鍵共有が提供されるよう、TLS クライアントと SDK を更新する責任を負います。 これにより、量子コンピューティングの進歩がもたらす将来の harvest now, decrypt later 攻撃の脅威から保護されます。 ポスト量子暗号移行に関する追加情報、ブログ投稿、定期的な更新については、 AWS ポスト量子暗号ページ をご覧ください。AWS でのポスト量子暗号の詳細については、 ポスト量子暗号チーム にお問い合わせください。 この投稿に関するご質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 その他のリソース: AWS ポスト量子暗号 AWS ポスト量子暗号移行計画 ポスト量子暗号への移行におけるセキュアな TLS 接続の仕組みとクライアント設定ガイド AWS-LC FIPS 3.0: FIPS 140-3 検証に ML-KEM を含めた最初の暗号ライブラリ ポスト量子暗号のレイテンシー影響はデータ量の増加で軽減 AWS ワークショップ: AWS でのポスト量子暗号の使用 NIST FIPS 203、Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM) Alex Weibel Alex は AWS Cryptography のシニアソフトウェア開発エンジニアです。Amazon TLS ライブラリ s2n-tls、Amazon Corretto Crypto Provider (ACCP)、AWS Libcrypto (AWS-LC) のコントリビューターです。以前は Amazon S3 と Elastic Load Balancing の TLS 終端と HTTP リクエストプロキシに携わり、お客様向けの新機能を開発していました。テキサス大学オースティン校でコンピュータサイエンスの学士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 10 月 3 日に公開された AWS Blog “ Customer compliance and security during the post-quantum cryptographic migration ” を翻訳したものです。 Amazon Web Services (AWS) は、サービスのセキュリティ、プライバシー、パフォーマンスを重視しています。AWS はクラウドと提供するサービスのセキュリティに責任を持ち、お客様はクラウドにデプロイまたは設定するホスト、アプリケーション、サービスのセキュリティに責任を持ちます。AWS は、長期的な機密性を確保するために、お客様が使用する一般的なトランスポートプロトコルに 耐量子暗号鍵交換を導入 してきました。このブログ記事では、クラウドへのセキュアな接続をポスト量子暗号へ移行する際に、お客様のコンプライアンスとセキュリティ設定の責任がどのように適用されるかを説明します。お客様は、AWS に接続するアプリケーションで耐量子アルゴリズムを有効にするか、デフォルトで有効にしているクライアントを使用する責任があります。また、サーバー側でサポートされている場合に、AWS がクライアントの選択した耐量子アルゴリズムを、多少の遅延が発生するとしても優先的に採用する仕組みについても説明します。 セキュアな接続 セキュリティとコンプライアンスは、AWS とお客様が共有する責任です。この 責任共有モデル により、お客様の運用負担が軽減されます。AWS がホストオペレーティングシステムや仮想化レイヤーから、サービスが稼働する施設の物理的なセキュリティに至るまで、運用、管理、制御を担当するためです。お客様は、ゲストオペレーティングシステムやその他の関連アプリケーションソフトウェア、および AWS が提供するセキュリティグループファイアウォール等の設定について責任と管理を担います。AWS は、主要なフレームワークのコンプライアンス要件が AWS サービスのセキュリティ推奨事項にどのようにマッピングされるかを、お客様、パートナー、監査人が理解できるよう、 カスタマーコンプライアンスガイド (CCG) を公開しています。 セキュアな接続に関しては、AWS はサービスに接続するお客様向けに、暗号化プロトコル (TLS、SSH、VPN など) でセキュアなアルゴリズムを提供しています。AWS は、AWS クラウドへの接続において最新の暗号化を有効にし、優先的に提供する責任を負います。一方、お客様は AWS に接続する際に、これらのアルゴリズムを有効にしたクライアントを使用し、暗号スイートをネゴシエートします。接続時に使用するアルゴリズムとして、お客様が希望し信頼するもののみをネゴシエートするようクライアントを設定することは、お客様の責任です。 耐量子暗号とパフォーマンスのどちらを優先するか? AWS は、AWS サービスへのネットワーク接続において ポスト量子暗号への移行 を進めてきました。新しい暗号アルゴリズムは、将来の暗号解読能力を持つ量子コンピュータ (CRQC) から保護するように設計されています。CRQC は現在使用しているアルゴリズムを脅かす可能性があります。ポスト量子暗号では、TLS 1.3 や SSH/SFTP などのプロトコルにポスト量子ハイブリッド鍵交換を導入します。後方互換性のために従来型とポスト量子ハイブリッドの両方の交換をサポートする必要があるため、AWS はポスト量子ハイブリッドをサポートするクライアントにはポスト量子ハイブリッド交換を優先し、まだアップグレードされていないクライアントには従来型を優先します。クライアントがポスト量子のサポートをアドバタイズしている場合、従来型に切り替えることは望ましくありません。 ポスト量子ハイブリッドキー確立は、従来の鍵交換と組み合わせて使用される耐量子暗号の鍵カプセル化メカニズム (KEM) を活用します。クライアントとサーバーは引き続き ECDH 鍵交換 を行い、対称鍵を導出する際に KEM の共有シークレットと組み合わせます。例えば、クライアントは AWS Certificate Manager (ACM) 、 AWS Key Management Service (AWS KMS) 、 AWS Secrets Manager に接続する際に、楕円曲線 P256 を使用した ECDH 鍵交換と NIST の PQC プロジェクト Round 3 のポスト量子 Kyber-768 (TLS グループ識別子 X25519Kyber768Draft00 ) を実行できます。 訳注: 本ブログの原文公開後、NIST により ML-KEM として標準化された方式が AWS KMS、ACM、Secrets Manager で利用可能になっています。詳細については Security Blog「 AWS KMS、ACM、Secrets Manager で ML-KEM ポスト量子 TLS をサポート開始 」を参照してください。 この戦略は、長年の実績がある従来の鍵交換の信頼性と、ポスト量子鍵交換の耐量子性を組み合わせることで、ECDH とポスト量子の共有シークレットの両方が破られない限り、ハンドシェイクが保護されます。ML-KEM アルゴリズムの導入により、転送されるデータが増加し (2.3 KB)、処理オーバーヘッドもわずかに増加します。処理オーバーヘッドは、長年ほとんどの TLS 接続で使用されてきた既存の ECDH アルゴリズムと同程度です。以下の表に示すように、ハイブリッド鍵交換の総オーバーヘッドは、インターネット上の一般的なハンドシェイクでは実質的に影響がないことが示されています。(出典: ブログ記事「 Kyber を使用したハイブリッドポスト量子 TLS のチューニング方法 」および「 The state of the post-quantum Internet 」) 転送データ (bytes) CPU 処理 (thousand ops/sec) クライアント サーバー ECDH with P256 128 17 17 X25519 64 31 31 ML-KEM-768 2,272 13 25 新しい鍵交換では、これまでにはなかった設計上の判断が必要になり、ピア間で従来型のみのアルゴリズムがネゴシエートされてしまう可能性があります。これまで、暗号プロトコルの設定には、安全であると広く信頼されているアルゴリズムが含まれていました。クライアントとサーバーは選択したアルゴリズムの優先順位を設定し、ネゴシエートされた優先順位から最も適切なものを選択していました。現在、「信頼された従来型」と「信頼されたポスト量子」という 2 つのアルゴリズムファミリーがあります。CRQC が利用できない現状では、従来型とポスト量子の両方のアルゴリズムが安全と見なされています。そのため、「安全な従来型」または「安全なポスト量子」アルゴリズムに関して、ベンダーがクライアントとサーバーの設定でどちらを優先すべきかという判断を求めるパラダイムシフトが起きています。 図 1 は、TLS における典型的なポスト量子ハイブリッド鍵交換を示しています。 図 1: 典型的な TLS 1.3 ハンドシェイク 図 1 の例では、クライアントは楕円曲線 P256 を使用した ECDH と耐量子 ML-KEM-768、楕円曲線 P256 を使用した ECDH と耐量子 Kyber-512 Round 3、および楕円曲線 P256 を使用した従来型 ECDH によるポスト量子ハイブリッドアルゴリズムのサポートをアドバタイズしています。クライアントは、P256 を使用した従来型 ECDH、およびポスト量子ハイブリッド P256+MLKEM768 の Keyshare 値も送信します。 Keyshare 値にはクライアントの公開鍵が含まれています。クライアントは P256+Kyber512 の Keyshare を含めていません。これは ClientHello のサイズを不必要に増加させるためです。また、ML-KEM-768 が Kyber Round 3 の批准版であるため、クライアントは P256+MLKEM768 の公開鍵のみを生成して送信することを選択しました。ここで、サーバーが楕円曲線 P256 を使用した ECDH とポスト量子ハイブリッド P256+Kyber512 をサポートしているが、P256+MLKEM768 をサポートしていないとします。クライアントが ClientHello に含めたグループと Keyshare 値を考慮すると、サーバーには次の 2 つのオプションがあります。 図 1 に示すように、クライアントの P256 Keyshare を使用して従来型鍵交換をネゴシエートする。P256+Kyber512 Keyshare が耐量子鍵交換に使用できると思われるかもしれませんが、サーバーは P256 による従来型 ECDH 鍵交換のみをネゴシエートすることを選択でき、これは CRQC に対して耐性がありません Hello Retry Request (HRR) を送信して、クライアントに新しい ClientHello で P256+Kyber512 のポスト量子ハイブリッド Keyshare を送信するよう指示する (図 2)。これによりラウンドトリップが発生しますが、ピア間で耐量子対称鍵をネゴシエートすることが強制されます 注: 一般的なインターネット接続では、ラウンドトリップに 30〜50 ミリ秒かかる場合があります。 以前は、一部のサーバーが Keyshare 値を使用して鍵交換アルゴリズムを選択していました (上記のオプション 1)。これにより、追加のラウンドトリップ (HRR) を必要としない高速な TLS 1.3 ハンドシェイクが可能でしたが、前述のポスト量子シナリオでは、両方のピアがサポートしているにもかかわらず、サーバーが耐量子アルゴリズムをネゴシエートしないことを意味します。 このようなシナリオは、クライアントとサーバーが新しいアルゴリズムの同じバージョンを同時にデプロイしない場合に発生する可能性があります。図 1 の例では、サーバーがポスト量子アルゴリズムの早期採用者であり、P256+Kyber512 Round 3 のサポートを追加した可能性があります。その後、クライアントが ML-KEM (P256+MLKEM768) を使用した批准済みポスト量子アルゴリズムにアップグレードした可能性があります。AWS はクライアントとサーバーの両方を常に制御できるわけではありません。一部の AWS サービスは Kyber の初期バージョンを採用しており、他のサービスは最初から ML-KEM-768 をデプロイしています。そのため、AWS がポスト量子移行フェーズにある間、このようなシナリオが発生する可能性があります。 注: これらのケースでは、接続の失敗は発生しません。副作用として、ポスト量子ハイブリッドをネゴシエートできたにもかかわらず、接続が従来型のみのアルゴリズムを使用することになります。 これらの複雑さは AWS に固有のものではありません。他の業界関係者もこれらの問題について検討しており、Internet Engineering Task Force (IETF) TLS ワーキンググループで議論のトピックとなっています。クライアントとサーバーが耐量子アルゴリズムをサポートしているにもかかわらず、従来型鍵交換をネゴシエートする可能性がある問題は、 TLS Key Share Prediction draft (draft-davidben-tls-key-share-prediction) の セキュリティに関する考慮事項 で議論されています。これらの懸念に対処するため、TLS 1.3 (RFC 8446) のドラフト更新版である Transport Layer Security (TLS) Protocol Version 1.3 draft (draft-ietf-tls-rfc8446bis) では、鍵交換グループの選択時のクライアントとサーバーの動作、および Keyshare 値の使用に関するテキストが セクション 4.2.8 に導入されています。 TLS Key Share Prediction draft は、クライアントがサーバーがサポートする適切な Keyshare を使用するためのメカニズムとして DNS を提供することで、この問題に対処しようとしています。 耐量子性の優先 一般的な TLS 1.3 ハンドシェイクでは、 ClientHello にクライアントの鍵交換アルゴリズムの優先順位が含まれています。 ClientHello を受信すると、サーバーは自身の優先順位に基づいてアルゴリズムを選択して応答します。 図 2 は、前述のシナリオ (図 1) において、サーバーが P256+Kyber512 を使用した耐量子鍵のネゴシエーションを要求するために、クライアントに HelloRetryRequest (HRR) を送信する方法を示しています。このアプローチでは、ハンドシェイクに追加のラウンドトリップが発生します。 図 2: サーバーからクライアントへの HRR による、相互にサポートされた耐量子鍵のネゴシエーション要求 TLS 1.3 接続を終端する AWS サービスは、このアプローチを採用します。耐量子アルゴリズムのサポートをアドバタイズするクライアントに対して、耐量子性を優先します。AWS サービスが耐量子アルゴリズムを追加している場合、ハンドシェイクに追加のラウンドトリップが発生し、ポスト量子ハイブリッド鍵交換にわずかな処理オーバーヘッドが含まれる場合でも (ML-KEM は ECDH とほぼ同等のパフォーマンス)、クライアントがサポートするポスト量子鍵交換を尊重します。現在のリージョン化された TLS 接続における一般的なラウンドトリップは通常 50 ミリ秒未満であり、接続パフォーマンスに大きな影響を与えません。ポスト量子移行において、AWS は耐量子鍵交換のサポートをアドバタイズするクライアントを、CRQC リスクを真剣に捉えているクライアントと見なします。そのため、サーバーがアルゴリズムをサポートしている場合、AWS サーバーはその優先順位を尊重します。 Pull Request 4526 は、 s2n-tls にこの動作を導入しています。s2n-tls は、OpenSSL libcrypto や AWS libcrypto (AWS-LC) などの他の暗号ライブラリ上に構築された、AWS のオープンソースで効率的な TLS ライブラリです。s2n-tls でビルドされた s2n-quic のハンドシェイクも同じ動作を継承します。 s2n-quic は、QUIC プロトコルの AWS オープンソース Rust 実装です。 AWS のお客様がポスト量子鍵交換を検証する方法 この記事で説明した動作をすでに採用している AWS サービスには、AWS KMS、ACM、Secrets Manager の TLS エンドポイントがあります。これらは数年前からポスト量子ハイブリッド鍵交換をサポートしています。耐量子アルゴリズムをデプロイする他のエンドポイントも、同じ動作を継承します。 AWS サービスに導入された新しい耐量子アルゴリズムを活用したいお客様は、クライアント側またはお客様が管理するエンドポイントのサーバー側でそれらを有効にする必要があります。例えば、AWS SDK for Java v2 で AWS Common Runtime (CRT) HTTP クライアント を使用している場合、以下のように ポスト量子ハイブリッド TLS 鍵交換を有効にする必要があります。 SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder() .postQuantumTlsEnabled(true) .build(); AWS KMS および Secrets Manager のドキュメントには、ポスト量子 TLS をサポートする AWS エンドポイントへの耐量子接続を介して HTTP API 呼び出しを行うための AWS SDK の使用方法が詳しく記載されています。 サーバーエンドポイントがポスト量子アルゴリズムを適切に優先し、強制していることを確認するには、ポスト量子対応サーバーがサポートしていないポスト量子ハイブリッド Keyshare 値を送信する「古い」クライアントを使用できます。例えば、AWS-LC (耐量子 KEM をサポート) でビルドされた s2n-tls を使用できます。サーバーのポリシー (PQ-TLS-1-0-2021-05-24) よりも新しいクライアント TLS ポリシー (PQ-TLS-1-3-2023-06-01) を使用すると、以下に示すように、サーバーは HRR を通じてクライアントに P256+MLKEM768 を含む新しい ClientHello を送信するよう要求します。 ./bin/s2nd -c PQ-TLS-1-0-2021-05-24 localhost 4444 sudo tcpdump port 4444 -w hrr-capture.pcap ./bin/s2nc localhost 4444 -c PQ-TLS-1-3-2023-06-01 -i hrr-capture.pcap パケットキャプチャには、ネゴシエーションとサーバーからの HRR が表示されます。 サーバーエンドポイントがポスト量子ハイブリッド鍵交換を適切に実装していることを確認するには、鍵交換をサポートする最新のクライアントを使用してエンドポイントに接続します。例えば、AWS-LC (耐量子 KEM をサポート) でビルドされた s2n-tls クライアントを使用して、ポスト量子 TLS ポリシー (例: PQ-TLS-1-2-2023-12-15 ) で Secrets Manager エンドポイントに接続し、以下に示すように出力で使用されたポスト量子ハイブリッド鍵交換を確認できます。 ./bin/s2nc -c PQ-TLS-1-2-2023-12-15 secretsmanager.us-east-1.amazonaws.com 443 CONNECTED: Handshake: NEGOTIATED|FULL_HANDSHAKE|MIDDLEBOX_COMPAT Client hello version: 33 Client protocol version: 34 Server protocol version: 34 Actual protocol version: 34 Server name: secretsmanager.us-east-1.amazonaws.com Curve: NONE KEM: NONE KEM Group: SecP256r1Kyber768Draft00 Cipher negotiated: TLS_AES_128_GCM_SHA256 Server signature negotiated: RSA-PSS-RSAE+SHA256 Early Data status: NOT REQUESTED Wire bytes in: 6699 Wire bytes out: 1674 s2n is ready Connected to secretsmanager.us-east-1.amazonaws.com:443 代替手段として、 Open Quantum Safe (OQS) for OpenSSL クライアントを使用することもできます。 別の例として、 AWS Transfer Family で耐量子 SFTP 接続を介してファイルを転送する場合、 AWS File Transfer SFTP エンドポイントにポスト量子暗号 SSH セキュリティポリシーを設定 (例: TransferSecurityPolicy-2024-01 ) し、 SFTP クライアントで耐量子 SSH 鍵交換を有効にする 必要があります。SSH/SFTP では、AWS サーバー側が耐量子スキームをより高い優先順位でアドバタイズしますが、鍵交換アルゴリズムを選択するのはクライアントであることに注意してください。そのため、ポスト量子暗号をサポートするクライアントは、( 責任共有モデル で説明されているように) ポスト量子アルゴリズムをより高い優先順位で設定する必要があります。詳細については、 AWS Transfer Family のドキュメント を参照してください。 まとめ 暗号移行は、クライアントとサーバー間の暗号ネゴシエーションに複雑さをもたらす可能性があります。移行フェーズにおいて、AWS サービスは、これらのアルゴリズムのサポートをアドバタイズするお客様に対してポスト量子アルゴリズムを優先することで、これらの複雑さのリスクを軽減します。初期ネゴシエーションでわずかな遅延が発生する場合でも、AWS はポスト量子アルゴリズムを優先します。ポスト量子移行フェーズにおいて耐量子性を有効にすることを選択したお客様は、CRQC リスクを真剣に捉えていると言えます。このリスクを軽減するため、サーバー側で耐量子性がサポートされている場合、AWS はネゴシエーション時にお客様が選択した耐量子アルゴリズムを優先的に使用します。 この記事についてご質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。AWS の PQC への取り組みの詳細については、 PQC ページ を参照してください。   Panos Kampanakis Panos は AWS のプリンシパルセキュリティエンジニアです。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の経験があります。サイバーセキュリティに関する出版物を共同執筆し、セキュリティ情報共有、暗号、公開鍵基盤のための共通の相互運用可能なプロトコルと言語を提供するために、さまざまなセキュリティ標準化団体に参加してきました。現在は、エンジニアや業界標準パートナーと協力して、暗号的に安全なツール、プロトコル、標準を提供しています。 Alex Weibel Alex は AWS Crypto Algorithms チームのシニアソフトウェア開発エンジニアです。Amazon の TLS ライブラリ s2n-tls、Amazon Corretto Crypto Provider (ACCP)、AWS LibCrypto のコントリビューターです。以前は、S3 と Elastic Load Balancing Service の TLS 終端とリクエストプロキシに携わり、お客様向けの新機能を開発していました。Alex はテキサス大学オースティン校でコンピュータサイエンスの学士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、コア数変更設定によって vCPU 割り当てを制御でき CPU 最適化 機能を提供するようになりました。SQL Server のライセンス費用は、特に十分に活用されていない vCPU に対して支払いを行っている場合、データベース予算の大部分を占める可能性があります。この投稿では、新規および既存の Amazon RDS インスタンスの両方において、パフォーマンスを維持しながらライセンス費用を削減する可能性がある CPU 最適化機能の実装方法を、パフォーマンスベンチマーク結果とコストへの影響とともに説明します。 ソリューション概要 AWS Management Console を使用してソリューションを実装したり、プロセスを自動化したりできます。SQL Server のパフォーマンスは通常、適切なインスタンスタイプの選択に依存し、メモリとストレージ (1 秒あたりの入出力操作数 (IOPS) とスループット) が重要な要素となります。オンライントランザクション処理 (OLTP) ワークロードは一般的に CPU 集約的というよりもメモリまたは I/O バウンドですが、CPU リソースを最適化することで、パフォーマンスを損なうことなくコスト効果を得ることができます。 この投稿では、新規および既存の RDS インスタンスに対する CPU 最適化の設定方法を実演し、パフォーマンスベンチマーク結果をお見せし、コストの影響を理解していただけるよう支援します。このソリューションでは、以下を行います： 最適化された CPU 設定で新しい Amazon RDS インスタンスを作成 既存インスタンスの変更 CPU 最適化を使用した復元操作の実行 様々な設定でのパフォーマンステスト コスト効果分析 以下の図は、ソリューションアーキテクチャを示しています。 前提条件 このソリューションを実装する前に、以下を確認してください： アクティブな AWS アカウント AWS Command Line Interface (AWS CLI) が インストールされ、設定されていること テスト用の非本番環境 CPU 最適化機能 が Amazon RDS for SQL Server の価格とパフォーマンスに与える影響についての理解 このソリューションには、新しい AWS リソースの作成と利用が含まれます。そのため、お客様のアカウントに費用が発生します。詳細については、 AWS 料金表 をご参照ください。 本番環境にこのソリューションを実装する前に、本番環境以外の環境でこれを設定してエンドツーエンドの検証を実行することを強く推奨します。 CPU 最適化の実装 CPU を最適化する方法は 3 つあります。新しい RDS インスタンスを作成する、既存の RDS インスタンスを変更する、そしてインスタンスを復元する方法です。次のセクションでは、各オプションを実装するためのステップバイステップガイドを提供します。 オプション 1 : 新しい RDS インスタンスの作成 最適化された CPU 機能を持つ新しい RDS for SQL Server インスタンスを作成するには、以下の手順を実行してください： Amazon RDS コンソール で、データベースの作成を選択します。 データベース作成方法を選択でフル設定を選択します。 エンジンタイプとして Microsoft SQL Server を選択します。 データベース管理タイプで、Amazon RDS を選択します。 エディションを選択します。この投稿では、Enterprise Edition を選択します。 サポートされている SQL Server バージョン を選択します。この投稿では、SQL Server 2022 の最新マイナーバージョンを選択します。 テンプレートで 開発 / テスト を選択します。 設定で、DB インスタンス識別子とプライマリユーザーのプライマリユーザー名とパスワードを入力します。 インスタンス設定で、標準クラスを選択し、希望するインスタンスクラスを選択します。この投稿では、db.m7i.8xlarge を選択します。 CPU 最適化セクションで vCPU の数を設定にチェックを入れます。 希望するコア数を設定します。CPU 最適化をサポートする第 7 世代以降のインスタンスでは、ハイパースレッディングはデフォルトで無効になっています。 これらの設定は以下のスクリーンショットに示されています。 接続設定で、EC2 コンピュートリソースに接続しない、IPv4 ネットワークタイプ、および作成した VPC とサブネットグループを選択します。 パブリックアクセスには「いいえ」を選択します。 VPC セキュリティグループでは、「既存の選択」を選び、作成したセキュリティグループを選択します。 その他の設定はデフォルトのままにしておきます。 「データベースの作成」をクリックし、インスタンスがプロビジョニングされるまで待ちます。 インスタンスが「利用可能」になったら、DB インスタンスの名前を選択します。設定タブを選択して、以下の画面ショットに示すように、vCPU 数、コア数、およびコアあたりのスレッド数の設定を確認することができます。 オプション 2 : 既存の Amazon RDS インスタンスの修正 次の AWS CLI コマンドを使用して、既存のインスタンスを変更して CPU 最適化設定を変更できます。 以下のコードは Windows 向けです： aws rds modify - db - instance ^ - - db - instance - identifier < your DB identifier > ^ - - db - instance - class < instance class > ^ - - processor - features "Name=coreCount,Value=<X>" "Name=threadsPerCore,Value=1" - - apply - immediately Python 以下のコードは Mac 向けです： aws rds modify - db - instance \ - - db - instance - identifier < your DB identifier > \ - - db - instance - class < instance class > \ - - processor - features "Name=coreCount,Value=<X>" "Name=threadsPerCore,Value=1" - - apply - immediately Python Option 3 : インスタンスの復元 スナップショットからインスタンスを復元する際、以下の AWS CLI コマンドを使用して CPU 設定の最適化を構成できます。 ポイントインタイムリカバリー 以下のコードは Windows 向けです： aws rds restore - db - instance - to - point - in - time ^ - - source - db - instance - identifier < your source DB identifier > ^ - - target - db - instance < target DB identifier > ^ - - db - instance - class < instance class > ^ - - use - latest - restorable - time ^ - - processor - features "Name=coreCount,Value=<X>" "Name=threadsPerCore,Value=1" Python 以下のコードは Mac 向けです： aws rds restore - db - instance - to - point - in - time \ - - source - db - instance - identifier < your source DB identifier > \ - - target - db - instance < target DB identifier > \ - - db - instance - class < instance class > \ - - use - latest - restorable - time \ - - processor - features "Name=coreCount,Value=<X>" "Name=threadsPerCore,Value=1" Python パフォーマンス設定 CPU 最適化がパフォーマンスにどのような影響を与えるかを理解していただくために、典型的な OLTP データベースワークロードをシミュレートするテストを実施しました。以下のコンポーネントを使用してテスト環境を構築しました： インスタンス SQL Server 2022 Enterprise Edition がインストールされた db.r7i.12xlarge RDS インスタンス SQL Server 2022 Enterprise Edition がインストールされた db.r6i.12xlarge RDS インスタンス SQL Server 2022 Enterprise Edition がインストールされた db.m6i.8xlarge RDS インスタンス SQL Server 2022 Enterprise Edition がインストールされた db.m7i.8xlarge RDS インスタンス ストレージ設定 – 64,000 IOPS をもつ 2 TiB io2 ストレージ クライアントマシン – m6i.12xlarge インスタンス テストツール – TPCC 類似ワークロードを使用した HammerDB 同期レプリケーションのレイテンシーを排除し、純粋なパフォーマンス指標に焦点を当てるために、シングル AZ デプロイメントを選択しました。テストデータベースは 8,000 のウェアハウスで構成され、I/O ワークロードシミュレーションを最大化するために「すべてのウェアハウスを使用」オプションを選択しています。 テスト手法 私たちのパフォーマンス評価では、HammerDB の Autopilot 機能を使用し、体系的なアプローチを実装しました： パフォーマンスの停滞地点に達するまでの仮想ユーザーの段階的スケーリング 様々な同時実行シナリオをテストするためのユーザー負荷の指数的増加 統計的妥当性のための各テストシナリオの 3 回実行 信頼性の高いパフォーマンス指標のための結果の平均化 この方法論を用いることで、私たちは以下のことができます： 最大持続可能トランザクション率を特定 様々な負荷条件下でのシステム動作を測定 再現可能で信頼性の高いパフォーマンスベースラインを確立 パフォーマンステスト結果を通じて異なる RDS インスタンス間でのパフォーマンス一貫性を検証 仮想ユーザー数を 16、32、64、128、256、384、512、1024 と指数的に設定します。 db.r6i.12xlarge と db.r7i.12xlarge の比較テスト 我々は、48 vCPU (ハイパースレッディング有効で 24 コア) の r6i インスタンスクラスと、24 vCPU (ハイパースレッディング無効で 24 コア) との比較テストを開始しました。両方のインスタンスは最大 60,000 IOPS をサポートしています。以下の図はパフォーマンステストを表しています。r7i インスタンスクラスのパフォーマンスは、実際には 512 仮想ユーザーまでにおいて、r6i インスタンスクラスと比較してわずかに優れています。以下のグラフは、仮想ユーザー数を変化させたパフォーマンス比較を示しています。 以下のグラフは、インスタンス間で取得された一連のテストの平均 CPU 使用率を表しています。r6i インスタンスは最大 CPU 使用率 20% を記録し、r7i インスタンスは 1024 の仮想ユーザーが同時にクエリを実行している際に 40% を示しました。40% は、ほとんどのデータベースインスタンスにとって快適な閾値です。 次の図は、テストがインスタンスクラスとサイズでサポートされている IOPS(60,000) を最大まで使用していることを示しています。サポートされているストレージ IOPS とスループットの詳細については、 Amazon EBS 最適化インスタンスタイプ をご覧ください。 db.m6i.8xlarge と db.m7i.8xlarge 比較テスト 32 vCPU で構成された m6i と 16 vCPU の m7i インスタンスクラスのパフォーマンスを比較するテストを継続しました。両方のインスタンスタイプのベースライン IOPS 値は 40,000 です。テスト結果は以下のグラフに示されています。m7i インスタンスクラスのパフォーマンスは、512 の同時仮想ユーザーまでは m6i インスタンスクラスと同等です。 以下のグラフは、インスタンスの CPU 使用率を示しています。m6i インスタンスの CPU 使用率は 15～20% と低く、一方で m7i インスタンスは最大 40% を記録しました。m6i インスタンスと比較して CPU が 50% 少ないため、m7i インスタンスの CPU 使用率がより高くなることは予想されますが、快適な閾値である 70～80% を大幅に下回っています。 これらの各テストケースにおいて、各インスタンスでサポートされているプロビジョンド IOPS を最大限に活用しました。メトリクスから、ベンチマークがインスタンスの 40,000 IOPS の制限を利用していることが確認できました。以下の図は、仮想ユーザー数を変化させた場合の総 IOPS を示しています。 パフォーマンステストのまとめ db.r6i.12xlarge、db.r7i.12xlarge、db.m6i.8xlarge、および db.m7i.8xlarge における RDS for SQL Server のパフォーマンステスト結果を以下の表にまとめました。 db.r6i.12xlarge db.r7i.12xlarge db.m6i.8xlarge db.m7i.8xlarge CPU Count 48 vCPU (24 * 2) 24 vCPU (24 * 1) 32 vCPU (16 * 2) 16 vCPU (16 * 1) TPM 327668 328791 171104 169794 Relative performance (%) 100 100.34 100 99.23 IOPS/CPU 1250 2500 1250 2500 0.34% -0.77% ハイパースレッディングを無効にした新世代インスタンスクラス (m7i および r7i) のパフォーマンスは、vCPU 数を 50% 削減しても、第 6 世代インスタンスクラスに匹敵します。ベンチマークデータから、ワークロードが増加すると CPU 使用率が上昇することが確認されました。しかし、使用率は 95 パーセンタイル使用率 (約 80%) を下回っており、これは多くの DB アドミニストレーターが快適に感じるレベルです。このインスタンスは、CPU 数が 2 倍のインスタンスと同等の 1 分あたりのトランザクション数 (TPM) を達成することができました。本番環境で変更を行う前に、非本番環境で特定のインスタンスクラスでワークロードをテストすることを強く推奨します。 費用対効果 RDS for SQL Server の CPU 最適化機能は、パフォーマンスを損なうことなく、お客様に大幅なコスト削減の機会を提供します。SQL Server のライセンスは仮想 CPU あたりで課金されるため、アクティブな仮想 CPU を削減することで、特にEnterprise Edition ライセンスにおいて直接的にコストを削減できます。この機能は、最大パフォーマンスが常に必要ではない開発環境やテスト環境で特に有効で、25〜50% のコスト削減が期待できます。本番ワークロードにおいては、お客様は実際の使用率パターンに基づいて CPU 割り当てを適正化し、パフォーマンス基準を維持することができます。メリットを最大化するために、組織は CPU 使用率を監視し、テスト環境で最適化を開始し、本番環境で段階的に変更を実装する必要があります。設定とパフォーマンス指標の定期的な見直しにより、ワークロード要件を満たしながら最適なコスト効率を実現できます。以下は、ベンチマークに使用された第 7 世代インスタンスのデフォルト CPU と CPU 最適化設定の比較表です。 db.r7i.12xlarge Compute(1) SQL license(2) Windows license(3) Total(1)+(2)+(3) Price reduction Enterprise 48 vCPU $4380.00 $13140.00 $1611.84 $19131.84 Enterprise 24 vCPU $4380.00 $6570.00 $805.92 $8755.92 −54.2% db.m7i.8xlarge Enterprise 32 vCPU $2079.04 $8760.00 $1074.56 $11913.60 Enterprise 16 vCPU $2079.04 $4380.00 $537.28 $6996.32 −41.2% クリーンアップ 継続的な課金を避けるために、不要になったインスタンスを削除してください。リソースをクリーンアップするには、「 RDS for SQL Server DB インスタンスの削除 」の手順を完了してください。 結論 Amazon RDS for SQL Server の CPU 最適化機能は、クラウドリソース最適化における重要な進歩を表しており、お客様にパフォーマンスとコスト効率の両方でデータベースインスタンスを細かく調整する柔軟性を提供します。AWS の包括的なテストにより、vCPU 数を削減しても最適なパフォーマンスを維持しながら、ライセンスコストを大幅に削減できることが実証されています。パフォーマンスベンチマークでは、削減された CPU 構成で実行されるワークロードが一貫したスループットレベルを維持し、当社のテストシナリオでは、vCPU が大幅に少ない状況でも 100% を超える相対的なパフォーマンスを達成していることが明確に示されています。これは、多くの SQL Server ワークロードが最適化された CPU 構成で効率的に動作でき、組織が年間数万ドルのライセンスコストを節約できる可能性があることを示しています。組織がクラウド支出の最適化を続ける中、Amazon RDS の CPU 最適化機能は、データベースパフォーマンスがビジネス要件を満たしながら大幅なコスト削減を実現するための強力なツールを提供します。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Barry Ooi Barry は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。彼の専門分野は、お客様の AWS 導入の一環として、クラウドネイティブサービスを使用したデータプラットフォームの設計、構築、実装です。彼の関心領域には、データ分析と可視化が含まれます。 Sudarshan Roy Sudarshan は、World Wide AWS Database Services Organization (WWSO) のシニアデータベーススペシャリスト クラウドソリューションアーキテクトです。彼はエンタープライズなお客様向けの大規模なデータベース移行・モダナイゼーションプロジェクトを主導しており、データベースワークロードを AWS クラウドに移行する際の複雑な移行課題の解決に情熱を注いでいます。

マルチテナント SQL Server 環境では、データベース名の公開により機密のテナント情報が漏洩するリスクという設計上の課題があります。オンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) 上で動作するセルフマネージドな SQL Server では、特定のログインに対してサーバーレベルの権限を手動で拒否することで、この課題に対処できます。 Amazon Relational Database Service (Amazon RDS) for SQL Server では、 専用のストアドプロシージャ を使用してデータベースの可視性を設定します。 デフォルトでは、SQL Server の PUBLIC ロールは認証されたユーザーがすべてのデータベース名を表示することを許可しています。これは透明性を意図した機能ですが、マルチテナントアーキテクチャにおいては重大な懸念事項となる可能性があります。同一インスタンス上で複数の顧客データベースをホスティングする独立系ソフトウェアベンダー (ISV) やサービスとしてのソフトウェア (SaaS) プロバイダーは、テナントの機密性を保護するためにこのデフォルト動作に対する慎重な検討対策が必要です。 この投稿では、可視性レベルでのテナント分離を実装し、各テナントが自身のリソースにはアクセスできる一方で、他の顧客のデータベース名は参照できないようにする方法を紹介します。 ソリューション概要 このソリューションは、データベース名からテナント情報が漏洩してしまう可能性があるマルチテナントの SQL Server 環境における重要なアーキテクチャ課題に対処します。Amazon RDS for SQL Server のカスタムストアドプロシージャである msdb.dbo.rds_manage_view_db_permission を使用することで、アプリケーション機能を完全に維持しながら、ログイン単位でデータベースの可視性を効果的に制御できます。 重要なことは、このソリューションはデータベースの可視性のみを管理します。 適切なデータベース権限を持つログインは、SQL Server Management Studio (SSMS) やその他の SQL Server クライアントでデータベース名が表示されない場合でも、付与された権限に従ってデータベースに完全にアクセスし、使用することができます。これは、共有インスタンス上でマルチテナントデータベースをホスティングする SaaS プロバイダーや ISV にとって特に価値があります。 実装は以下のハイレベルなステップに従います： マルチテナントデータベースとログインを含む RDS for SQL Server インスタンスを準備します。 特定のログインに対してデータベースの可視性を拒否するカスタムストアドプロシージャを適用します。 制限された可視性を確認して設定を検証します。 必要に応じて変更を元に戻す機能を維持します。 このソリューションは、情報開示のリスクを軽減することでセキュリティ体制を強化し、データベース名をテナントに公開することなく、クリーンなテナント体験を提供します。以下の図は、実装前後のセキュリティ体制を示しています。 前提条件 以下の前提条件を満たしている必要があります： AWS アカウントへのアクセス SQL Server とセキュリティ概念の基本的な理解 RDS for SQL Server DB インスタンス とそれに接続するためのログイン情報 Amazon RDS for SQL Server をデプロイすると料金が発生します。続行する前に AWS 料金 を確認してください。 RDS for SQL Server インスタンスの準備 2 つの新しいデータベースと 2 つのログインを作成し、適切な権限を付与する： AWS CLI または AWS Management Console を使用して RDS for SQL Server インスタンスを作成します。 Primary ログインを使用して RDS for SQL Server インスタンスに接続します。 Tenant1DB と Tenant2DB の 2 つのデータベースを作成します： CREATE DATABASE Tenant1DB GO CREATE DATABASE Tenant2DB GO Code 2 つのログインオブジェクト 、 Tenant1 と Tenant2 を作成してください： USE [ master ] GO CREATE LOGIN [ Tenant1 ] WITH PASSWORD = N 'xxxxxx' GO USE [ master ] GO CREATE LOGIN [ Tenant2 ] WITH PASSWORD = N 'xxxxxx' GO SQL Tenant1 に Tenant1DB への権限を付与します： USE [ Tenant1DB ] GO CREATE USER [ Tenant1 ] FOR LOGIN [ Tenant1 ] GO USE [ Tenant1DB ] GO ALTER ROLE [ db_owner ] ADD MEMBER [ Tenant1 ] GO SQL Tenant2 に Tenant2DB への権限を付与します: USE [ Tenant2DB ] GO CREATE USER [ Tenant2 ] FOR LOGIN [ Tenant2 ] GO USE [ Tenant2DB ] GO ALTER ROLE [ db_owner ] ADD MEMBER [ Tenant2 ] GO SQL データベース権限の確認 各テナントのログインを使用してログインし、すべてのデータベース名が表示されるデフォルトの動作を検証します： SSMS を開きます。 Tenant1 を使用してログインします。 Databases フォルダを展開します。 Tenant1 がすべてのデータベース名を確認できることを確認します。 同様に、 Tenant2 を使用してインスタンスにログインします。 Tenant2 がすべてのデータベース名を確認できることを確認します。 データベース名の表示権限を変更 このセクションでは、Amazon RDS for SQL Server のカスタムストアドプロシージャを適用して、ログインのデータベース可視性を変更します： Primary ログイン を使用してインスタンスに接続してください。 以下のスクリプトを実行してください： EXEC msdb . dbo . rds_manage_view_db_permission @permission = 'DENY' , @server_principal = 'Tenant1' SQL 前述したように、ストアドプロシージャはデータベースの権限を制御するのではなく、データベース名を非表示にするだけです。 データベース名表示の権限を検証 Tenant1 がデータベース名を表示されていないことを確認できます： SSMSを開きます。 Tenant1 を使用してログインします。 Databases フォルダを展開します。 Tenant1 が データベース名を一切見ることができないことを確認します。 データベース名は非表示になっています。ただし、 Tenant2 ログインでインスタンスに接続すると、データベース名が表示されるはずです。これは、カスタムストアドプロシージャが Tenant2 ログインに適用されていないからです。 データベース名が表示されています。 変更を元に戻す 変更を元に戻すには、以下の手順を実行してください： 以下のコマンドを実行して変更を元に戻してください： EXEC msdb . dbo . rds_manage_view_db_permission @permission = 'GRANT' , @server_principal = ‘Tenant1’ SQL ログアウトして、 Tenant1 ログインを使用して RDS インスタンスへの新しいクエリセッションを開きます。 データベース名を再度確認できることを確認してください。 データベース名が表示されています。 制限事項 ログインが削除され再作成された場合、権限を再適用するために ストアドプロシージャ を再実行する必要があります。 このストアドプロシージャはデータベースアクセス権限を管理しません。データベースアクセス権限は、適切なセキュリティ対策を通じて別途管理する必要があります。 この権限が適用されている場合でも、データベース名は SQL Server トレース、エラーログ、および特定の動的管理ビュー (DMV) に表示される可能性があります。 権限が取り消されると、そのログインにデータベース名が表示されるようになります。 権限はサーバーレベルで設定されます。復元方法を使用してデータベースが新しいインスタンスに復元される場合、権限を再適用する必要があります。 データベース名の表示制御は Primary ログインには適用できません。 Primary ログインには常にすべてのデータベース名が表示されます。 クリーンアップ このデモンストレーションに従うためにテストデータベースを作成した場合は、不要な料金を避けるために リソースをクリーンアップ してください。RDS for SQL Server インスタンスからテストユーザー、ログイン、データベースを削除してください。このデモのために特別に RDS インスタンスや EC2 ホストを作成した場合は、これ以上使用しないのであれば、それぞれ Amazon RDS コンソールと Amazon EC2 コンソールを通じてこれらのリソースを削除してください。これにより、不要な料金の発生を避けることができます。 結論 この投稿では、Amazon RDS for SQL Server を使用したマルチテナント環境でのデータベース名の可視性管理方法を実演しました。 同一ホスト上の他のテナントがデータベース名を通じて漏洩する可能性のある機密性の高い顧客情報を見ることを防ぐことができるよう、Amazon RDS for SQL Server カスタムストアドプロシージャを使用してデータベース名を非表示にするプロセスを説明しました。この解決策を Amazon RDS for SQL Server 環境に適用して、アプリケーションに必要なアクセス権限を維持しながらデータベース名の可視性を制御することができます。 Amazon RDS 固有の一般的な DBA タスクについて詳しく学ぶには、「 Amazon RDS for Microsoft SQL Serverの一般的な DBA タスク 」を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Swarndeep Singh Swarndeep は、AWS のシニアデータベース専門ソリューションアーキテクトです。データベースエンジニアリングとアーキテクチャにおいて 20 年以上の経験を持ち、商用およびオープンソースのデータベースエンジン全般にわたって革新的なソリューションの提供を専門としています。 Alex Pawvathil Alex は、データベースソリューションと実装を専門とする AWS のシニアテクニカルアカウントマネージャーです。データベースエンジニアリングと SQL Server テクノロジーにおいて 14 年以上の経験を持ち、Amazon RDS for SQL Server の実装とエンタープライズ規模の展開に関する専門家として活動しています。

本記事は 2026 年 2 月 3 日 に公開された「 AI agents in enterprises: Best practices with Amazon Bedrock AgentCore 」を翻訳したものです。 本番環境で使える AI エージェントを構築するには、開発ライフサイクル全体を通じた綿密な計画と実行が欠かせません。デモで印象的なプロトタイプと、本番環境で価値を提供するエージェントの差は、規律あるエンジニアリングプラクティス、堅牢なアーキテクチャ、そして継続的な改善によって生まれます。 本記事では、 Amazon Bedrock AgentCore を活用してエンタープライズ向け AI エージェントを構築するための 9 つのベストプラクティスを紹介します。Amazon Bedrock AgentCore は、AI エージェントの作成、デプロイ、管理を大規模に行うために必要なサービスを提供するエージェンティックプラットフォームです。初期のスコーピングから組織全体へのスケーリングまで、すぐに実践できるガイダンスを幅広くカバーしています。 小さく始めて、成功を明確に定義する 最初に答えるべき問いは「このエージェントに何ができるか?」ではなく、「私たちはどんな課題を解決しようとしているのか?」です。多くのチームが、あらゆるシナリオに対応しようとするエージェントの構築から着手してしまいます。これは複雑さ、遅いイテレーション、そして中途半端なエージェントに繋がります。 その代わりに、ユースケースから逆算して取り組みましょう。財務アシスタントを構築するなら、アナリストが最もよく行う 3 つのタスクから始めます。HR ヘルパーを構築するなら、従業員から寄せられる質問の上位 5 つに絞ります。まずはそれらを確実に動かしてから、スコープを広げていきます。 初期の計画段階では、次の 4 つの項目を明確にしておく必要があります: エージェントが「やるべきこと」と「やるべきでないこと」の 明確な定義 。必ず文書化し、ステークホルダーと共有してください。機能の肥大化に対して「ノー」と言うための拠り所になります。 エージェントのトーンとパーソナリティ 。フォーマルにするか会話調にするか、ユーザーにどのように挨拶するか、スコープ外の質問に遭遇した場合にどうするかを決定します。 すべてのツール、パラメータ、ナレッジソースの明確な定義 。それらの説明が曖昧だと、エージェントが誤ったツールを選択する原因になります。 一般的なクエリとエッジケースの両方を網羅した、期待されるインタラクションの Ground truth データセット 。 エージェントの定義 エージェントのトーンとパーソナリティ ツールの定義 Ground truth データセット 財務分析エージェント : アナリストが四半期の収益データを取得し、成長指標を計算し、特定のリージョン (EMEA、APAC、AMER) のエグゼクティブサマリーを生成する作業を支援する。 投資アドバイスの提供、取引の実行、従業員の報酬データへのアクセスは行わない。 プロフェッショナルだが堅すぎない会話的なトーン。ユーザーをファーストネームで呼ぶ。 データの制約は率直に伝える。 データ品質に不確実性がある場合は、信頼度を明示する。 専門用語は説明なしに使わない。 getQuarterlyRevenue(Region: EMEA|APAC|AMER, quarter: YYYY-QN) – 収益を百万ドル単位で返す。 calculateGrowth(currentValue: number, previousValue: number) – 変化率を返す。 getMarketData(Region: string, dataType: revenue|sales|customers) – 最新の業界指標を取得する。 50 件のクエリ (例): 「EMEA の Q3 の収益は?」 「前四半期と比較した成長率を見せて」 「アジアでの業績はどうだった?」 「CEO のボーナスはいくら?」(拒否すべき) 「2024 年の全リージョンを比較して」 HR ポリシーアシスタント : 休暇ポリシー、休暇申請、福利厚生、社内ポリシーに関する従業員の質問に回答する。 機密の人事ファイルへのアクセス、法的アドバイスの提供、個人の報酬やパフォーマンスレビューに関する対応は行わない。 フレンドリーで親身なトーン。 従業員の希望する呼び名を使う。 親しみやすさを保ちつつプロフェッショナルさを維持する。 ポリシーが複雑であればわかりやすいステップに分解する。 デリケートな問題は HR 担当者への連絡を提案する。 checkVacationBalance(employeeId: string) – 種類別の残日数を返す。 getPolicy(policyName: string) – ナレッジベースからポリシー文書を取得する。 createHRTicket(employeeId: string, category: string, description: string) – 複雑な問題をエスカレーションする。 getUpcomingHolidays(year: number, region: string) – 会社の休日カレンダーを返す。 45 件のクエリ (例): 「休暇の残日数は何日?」 「育児休暇のポリシーは?」 「来週休みを取得できる?」 「なぜボーナスが想定より少なかったの?」(エスカレーションすべき) 「健康保険の加入方法は?」 IT サポートエージェント : パスワードリセット、ソフトウェアのアクセス申請、VPN のトラブルシューティング、一般的な技術的問題について従業員を支援する。 本番システムへのアクセス、セキュリティ権限の直接変更、インフラの変更は行わない。 丁寧で分かり易いトーン。 専門用語を避ける。 ステップバイステップで案内する。 次のステップに進む前に理解を確認する。 小さな成功を一緒に喜ぶ (「Great, that worked!」)。 システムアクセスが必要な問題は IT チームにエスカレーションする。 resetPassword(userId: string, system: string) – パスワードリセットのワークフローを開始する。 checkVPNStatus(userId: string) – VPN の設定と接続を検証する。 requestSoftwareAccess(userId: string, software: string, justification: string) – アクセス申請チケットを作成する。 searchKnowledgeBase(query: string) – トラブルシューティング記事を取得する。 40 件のクエリ (例): 「メールにログインできない」 「VPN が切断され続ける」 「Salesforce へのアクセスが必要」 「管理者権限をもらえる?」(拒否すべき) 「ノート PC が Wi-Fi に繋がらない」 「Slack のインストール方法は?」 このような限定したスコープで概念実証 (PoC) を構築し、実際のユーザーに試してもらいます。想定していなかった問題がすぐに見つかるはずです。例えば、エージェントが日付の解析をうまくできない、略語を正しく処理できない、想定外の言い回しで質問されると誤ったツールを呼び出してしまう、といった問題です。PoC でこれに気づけばコストは数週間で済みますが、本番環境でこれに気づくと、失うコストは信頼性とユーザーの信用です。 初日からすべてを計装する オブザーバビリティに関してチームが陥りがちな過ちの一つは、「後から追加すればいい」と考えることです。必要性に気づいた頃にはすでにエージェントをリリースしており、効果的なデバッグが難しくなっている可能性があります。 最初のテストクエリの時点から、エージェントの挙動を可視化しておく必要があります。AgentCore のサービス群は OpenTelemetry トレース を自動的に出力します。モデルの呼び出し、ツールの呼び出し、推論のステップがキャプチャされます。あるクエリに 12 秒かかった場合、その遅延が言語モデル、データベースクエリ、外部 API 呼び出しのどこに起因するのかを特定できます。 オブザーバビリティ戦略には、次の 3 つのレイヤーを含めるべきです: 開発中はトレースレベルのデバッグを有効にし、会話の各ステップを追跡できるようにする。ユーザーがエージェントの想定外の動作を報告した場合、該当するトレースを取得してエージェントの動作を正確に把握できます。 AgentCore Observability に付属する Amazon CloudWatch の生成 AI オブザーバビリティダッシュボードを活用し、本番モニタリング用のダッシュボードを構築する。 トークン使用量、レイテンシーのパーセンタイル値、エラー率、ツール呼び出しパターンを追跡する。組織で Datadog 、 Dynatrace 、 LangSmith 、 Langfuse などを利用している場合は、既存のオブザーバビリティ基盤にそれらのデータをエクスポートする。 次の図は、AgentCore Observability がどのようにセッション内で実行のエージェントのトレースやメタデータを詳細に確認できるかを示しています: オブザーバビリティは、役割によって異なるニーズに応えます。開発者にとってはデバッグのための手段です。エージェントがなぜハルシネーションを起こしたのか、どのプロンプトバージョンの性能が優れているのか、レイテンシーのボトルネックはどこにあるのか、といった疑問に答えるために必要です。プラットフォームチームにとってはガバナンスの手段です。各チームがどれだけ支出しているか、どのエージェントがコスト増加を引き起こしているか、特定のインシデントで何が起きたのかを把握する必要があります。原則は単純で測定できないものは改善できません。必要になる前に、測定のためのインフラを整えておきます。 計画的なツール戦略を構築する ツールは、エージェントが現実世界にアクセスするための手段です。データベースからデータを取得し、外部 API を呼び出し、ドキュメントを検索し、ビジネスロジックを実行します。ツール定義の品質は、エージェントの性能に直結します。 ツールを定義する際は、簡潔さよりも明確さを優先してください。同一の関数に対する 2 つの記述を比較してみます: 悪い例: 「収益データを取得する」 良い例: 「指定されたリージョンと期間の四半期収益データを取得する。値は百万ドル単位で返される。リージョンコード (EMEA、APAC、AMER) と YYYY-QN 形式の四半期 (例: 2024-Q3) が必要である。」 1 番目の記述では、エージェントはどんな入力が有効で、出力をどう解釈すべきかを推測するしかありません。2 番目の記述は曖昧さを排除しています。これが 20 個のツールに及ぶと、その差は歴然です。ツール戦略では、次の 4 つの領域に取り組む必要があります: エラー処理とレジリエンス : ツールは失敗します。API はエラーを返し、タイムアウトも発生します。障害モードごとにリトライすべきか、キャッシュデータにフォールバックすべきか、サービス停止中であることをユーザーに伝えるべきかの期待される動作を定義します。これらをツール定義と合わせて記述します。 Model Context Protocol (MCP) の再利用 : Slack、Google Drive、Salesforce、GitHub など、多くのサービスプロバイダーがすでに MCP サーバーを提供しています。独自の統合を一から構築する代わりに、これらを活用します。社内 API については、AgentCore Gateway を通じて MCP ツールとしてラップすることで、すべてのツールを統一プロトコルで扱え、異なるエージェントから検出可能になります。 一元管理されたツールカタログ : 同一データベースコネクタを複数のチームがそれぞれ構築するべきではありません。セキュリティチームがレビュー済みで、本番環境でテスト済みの承認済みツールカタログを整備します。新しいチームが機能を必要とする場合は、まずカタログを確認するところから始めます。 すべてのツールでのコード例 : ドキュメントのみでは不十分です。開発者がコピーしてすぐに使える動作するコードサンプルで、各ツールの統合方法を示します。 次の表は、効果的なツールドキュメントに含める要素を示しています: 要素 目的 例 明確な関数名 ツールの機能を端的に表す getQuarterlyRevenue  not getData 明示的なパラメータ 入力に関する曖昧さを排除する region : string (EMEA|APAC|AMER), quarter : string (YYYY-QN) 戻り値の形式 出力の構造を明示する Returns: { revenue : number , currency : “USD”, period: string} エラー条件 障害モードを記述する 該当する四半期が見つからない場合は 404 、サービス停止時は 503 を返す 使用ガイダンス どのような場面で使うかを説明する ユーザーが収益、売上、財務パフォーマンスを質問した場合に使用する こうしたドキュメント標準化は、複数のソースやタイプのツールを管理する場面でさらに重要になります。次の図は、 AgentCore Gateway が異なるオリジンのツールに対して統一されたインターフェイスを提供する仕組みを示しています。例えば Gateway インスタンス (データ取得・分析関数用)、 AWS Lambda (レポート機能用)、 Amazon API Gateway (プロジェクト管理などの社内サービス用) のいずれを通じて公開されていても、統一されたインターフェイスを提供します。この例では簡略化のために単一のゲートウェイを示していますが、実際には多くのチームが明確な境界とオーナーシップを維持するために複数の Gateway インスタンス (エージェントごと、または関連するエージェント群ごとに 1 つ) をデプロイしています。このモジュール型のアプローチにより、各チームは独自のツール群を管理しつつ、組織全体で一貫した認証、検出、統合パターンの恩恵を受けられます。 AgentCore Gateway は、ツールの乱立という現実的な課題の解決に役立ちます 。組織全体でエージェントの構築が進むにつれ、MCP サーバー経由、Amazon API Gateway 経由、Lambda 関数として公開されたものなど、数十のツールが急速に蓄積されていきます。AgentCore Gateway がなければ、各エージェントチームは認証を個別に実装し、エンドポイントをそれぞれ管理し、実際に使うのはごく一部であっても全ツール定義をプロンプトに読み込むことになります。AgentCore Gateway は、ツールの所在に関係なく統一されたエントリポイントを提供します。既存の MCP サーバーや API Gateway を登録すれば、エージェントは単一のインターフェイスからそれらを検出できます。ツールの数が 20 から 30 に増えてくると、セマンティック検索機能が重要になります。セマンティック検索機能によって、エージェントは、すべてをコンテキストに読み込むのではなく、達成しようとしていることに基づいて適切なツールを発見できます。さらに、双方向の包括的な認証処理も一元化されます。どのエージェントがどのツールにアクセスできるかの検証と、サードパーティーサービスの認証情報の管理です。これこそが、一元管理されたツールカタログを大規模に実用化するためのインフラです。 最初から評価を自動化する 変更を加えるたびに、エージェントが良くなっているのか悪くなっているのかを把握する必要があります。自動化された評価がこのフィードバックループを実現します。まずは、対象のユースケースにおいて「良い」とは何かを定義するところから始めます。評価指標は業界やタスクによって異なります: カスタマーサービスエージェントであれば、解決率と顧客満足度が指標になり得る。 財務アナリストエージェントであれば、計算精度と引用の質が指標になり得る。 HR アシスタントであれば、ポリシーの正確性と回答の網羅性が指標になり得る。 技術的な指標とビジネス指標のバランスを取ります。レスポンスのレイテンシーは重要ですが、それはレスポンスが正しい場合に限ります。トークンコストも重要ですが、それはユーザーがエージェントに価値を感じている場合に限ります。両方の指標を定義し、合わせて追跡します。評価データセットは丁寧に構築してください。次のようなデータを含めます: 同一質問の複数の表現。ユーザーは API ドキュメントのような話し方はしないため。 エージェントが回答を拒否するか、人間にエスカレーションすべきエッジケース。 複数の解釈が成り立つ曖昧なクエリ。 先ほどの財務分析エージェントの例で考えてみましょう。評価データセットには「EMEA の Q3 の収益は?」のようなクエリと、期待される回答および正しいツール呼び出しを含めます。ただし、「前四半期のヨーロッパの売上はいくら?」「EMEA の Q3 の数字は?」「7 月から 9 月のヨーロッパの収益を見せて」といったバリエーションも必要です。どの表現でも、同一パラメータで同一ツールが呼び出されるべきです。評価指標の例を挙げます: ツール選択精度 : getMarketData ではなく getQuarterlyRevenue を正しく選択できたか? 目標: 95% パラメータ抽出精度 : EMEA と Q3 2024 を正しい形式にマッピングできたか? 目標: 98% 拒否精度 : CEO のボーナスはいくら? のような質問を適切に拒否できたか? 目標: 100% レスポンス品質 : 専門用語を使わずにデータをわかりやすく説明できたか? LLM-as-Judge で評価。 レイテンシー : P50 が 2 秒未満、P95 が 5 秒未満。 クエリあたりのコスト : 平均トークン使用量が 5,000 トークン未満。 この評価を Ground truth データセットに対して実行します。最初の変更前のベースラインでは、ツール選択精度 92%、P50 レイテンシー 3.2 秒といった結果が出るかもしれません。 Amazon Bedrock 上で Claude 4.5 Sonnet から Claude 4.5 Haiku に切り替えた後に評価を再実行すると、ツール選択精度が 87% に低下した一方、レイテンシーは 1.8 秒に改善された、という結果になるかもしれません。こうしてトレードオフを定量化することで、速度の向上が精度の低下に見合うかどうかを判断できます。 評価ワークフローは開発プロセスの一部に組み込むべきです。例えば、プロンプトの変更時点、ツールの追加時点、モデルを切り替え時点などで評価を実行します。フィードバックループは、問題が発生した時点ですぐに検知できるだけの速さが必要です。 マルチエージェントシステムで複雑さを分解する 単一のエージェントにあまりにも多くの責務を持たせると、メンテナンスが困難になります。プロンプトは複雑化し、ツール選択のロジックは破綻し、性能は低下します。解決策は、課題を複数の専門エージェントに分解し、それらを協調させることです。チーム編成に置き換えて考えてみてください。営業、エンジニアリング、サポート、財務をすべて 1 人に任せることはありません。それぞれの専門家を配置し、協調させます。エージェントにも同様の原則が当てはまります。次の図で示すように、30 種類のタスクを 1 つのエージェントに処理させるのではなく、関連する 10 タスクずつを担当する 3 つのエージェントを構築します。各エージェントはより明確な指示、よりシンプルなツールセット、より焦点の絞られたロジックを持つことになります。複雑さが分離されれば、問題のデバッグと修正は格段に容易になります。 適切なオーケストレーションパターンの選択が重要です。シーケンシャルパターンは、タスクに自然な順序がある場合に適しています。最初のエージェントがデータを取得し、2 番目が分析し、3 番目がレポートを生成する、といった流れです。階層型パターンは、インテリジェントなルーティングが必要な場合に適しています。スーパーバイザーエージェントがユーザーの意図を判断し、専門エージェントに振り分けます。ピアツーピアパターンは、中央のコーディネーターなしにエージェント同士が動的に協調する必要がある場合に適しています。 マルチエージェントシステムにおける最大の課題は、エージェント間の引き継ぎ時にコンテキストを維持することです。あるエージェントが別のエージェントに処理を渡す際、引き継ぎ先のエージェントはそれまでの経緯を把握している必要があります。ユーザーが最初のエージェントにアカウント番号を伝えたのに、次のエージェントがまた聞き直すようでは困ります。 AgentCore Memory は、セッション内で複数のエージェントがアクセスできる共有コンテキストを提供します。 エージェント間の引き継ぎは注意深くモニタリングしてください。障害の多くはここで発生します。どのエージェントがリクエストのどの部分を処理したのか? どこで遅延が生じたのか? どこでコンテキストが失われたのか? AgentCore Observability はワークフロー全体をエンドツーエンドでトレースするため、こうした問題の診断が可能です。 ここで、よくある混同を整理しておきましょう。プロトコルとパターンは別物です。プロトコルはエージェント間の通信方法を定義するもので、インフラレイヤー、通信フォーマット、API コントラクトに相当します。 Agent2Agent (A2A) プロトコル 、MCP、HTTP はプロトコルです。一方、パターンはエージェントの作業の組織化方法を定義するもので、アーキテクチャレイヤー、ワークフロー設計、協調戦略に相当します。シーケンシャル、階層型、ピアツーピアはパターンです。 同一プロトコルを異なるパターンで使うことができます。A2A を使ってシーケンシャルパイプラインを構築することも、階層型スーパーバイザーを構築することもできます。逆に、同一パターンを異なるプロトコルで実現することも可能です。シーケンシャルな引き継ぎは MCP、A2A、HTTP でも動作します。インフラとビジネスロジックを密結合させないよう、これらは分離しておきましょう。 次の表は、マルチエージェント協調のプロトコルとパターンにおけるレイヤー、対象、例の違いを整理したものです。 プロトコル – エージェント間の通信方法 パターン – エージェントの組織化方法 レイヤー 通信とインフラ アーキテクチャと組織化 対象 メッセージ形式、API、標準規格 ワークフロー、役割分担、協調方法 例 A2A、MCP、HTTP など シーケンシャル、階層型、ピアツーピアなど パーソナライゼーションを維持しながら安全にスケールする 1 人の開発者向けに動くプロトタイプから、数千人のユーザーにサービスを提供する本番システムへ移行するには、分離性、セキュリティ、パーソナライゼーションに関する新たな要件が生まれます。 まず最優先はセッションの分離です。ユーザー A の会話がユーザー B のセッションに漏れることは、いかなる状況でもあってはなりません。2 人のユーザーが異なるプロジェクト、異なるリージョン、異なるアカウントについて同時に質問している場合、それぞれのセッションは完全に独立していなければなりません。 AgentCore Runtime は、各セッションを専用のコンピューティングとメモリを備えた独立したマイクロ仮想マシン (microVM) 上で実行することで、この要件に対応しています。セッションが終了すると microVM も終了し、ユーザー間で共有される状態は一切残りません。 パーソナライゼーションには、セッションをまたいで永続化されるメモリが必要です。ユーザーには情報の提示方法に関して好みがあります。ユーザーが携わっているプロジェクトが質問のコンテキストとなり、ユーザーは職種に固有の用語や略語を使います。AgentCore Memory は、会話履歴のための短期メモリと、事実・好み・過去のインタラクションのための長期メモリの両方を提供します。メモリはユーザーごとに名前空間が分かれているため、各ユーザーのコンテキストはプライベートに保たれます。セキュリティとアクセス制御は、ツールが実行される前の段階で適用される必要があります。ユーザーは、閲覧権限のあるデータにのみアクセスできるべきです。次の図は、AgentCore の各コンポーネントが連携して複数のレイヤーでセキュリティを適用する仕組みを示しています。 ユーザーがエージェントとインタラクトする際、まず Amazon Cognito 、 Microsoft Entra ID 、 Okta などの ID プロバイダー (IdP) を通じて認証を行います。 AgentCore Identity は認証トークンを受け取り、ユーザーの権限と属性を定義するカスタム OAuth クレームを抽出します。これらのクレームは AgentCore Runtime を通じてエージェントに渡され、セッション内で利用可能になります。 エージェントがどのツールを呼び出すかを決定する段階で、AgentCore Gateway がポリシー適用のポイントとして機能します。ツールが実行される前に、Gateway はリクエストをインターセプトし、2 つのポリシーレイヤーに対して評価します。 AgentCore Policy は、当該ユーザーが当該ツールを当該パラメータで呼び出す権限を持っているかどうかを検証し、誰が何にアクセスできるかを定義するリソースポリシーをチェックします。同時に、AgentCore Gateway は認証情報プロバイダー (Google Drive、Dropbox、Outlook など) を確認し、サードパーティーサービスに必要な認証情報を取得・使用します。ゲートウェイインターセプターは、ツール呼び出しが実行される前にカスタム認可ロジック、レート制限、監査ログなどを実装できる追加のフックを提供します。 これらのチェックをすべて通過して初めて、ツールが実行されます。例えば、ジュニアアナリストが経営幹部の報酬データにアクセスしようとした場合、リクエストはデータベースに到達する前に AgentCore Gateway の段階で拒否されます。ユーザーが Google Drive に対する OAuth 同意を付与していない場合、エージェントは明確なエラーメッセージを受け取り、ユーザーに通知します。ユーザーの同意フローは透過的に処理されます。エージェントが初めて認証情報プロバイダーへのアクセスを必要とした場合、システムが認可を求めるプロンプトを表示し、以降のリクエストのためにトークンを保存します。 この多層防御のアプローチにより、どのチームがエージェントやツールを構築したか、ツールがどこでホストされているかに関係なく、エージェントとツール全体でセキュリティが一貫して適用されます。 スケールが大きくなると、モニタリングの複雑さも増します。数千の同時セッションを扱う場合、集約的なパターンを把握しつつ、個々のインタラクションを掘り下げて調査できるダッシュボードが必要です。次の図のように、AgentCore Observability は、トークン使用量、レイテンシー分布、エラー率、ツール呼び出しパターンといったリアルタイムの指標をユーザー全体に渡って提供します。次の図のように、特定のユーザーで問題が発生した場合は、そのセッションで何が起きたかを正確にトレースできます。 AgentCore Runtime は、ツールを MCP サーバーとしてホストする機能も備えています。これにより、アーキテクチャのモジュール性が保たれます。エージェントは密結合なしに AgentCore Gateway を通じてツールを検出および呼び出しを行います。ツールの実装を更新すると、エージェントはコード変更なしに自動的に新しいバージョンを使用します。 エージェントと決定論的コードを組み合わせる アーキテクチャ上の最も重要な判断の 1 つは、エージェンティックな振る舞いに頼る場面と、従来のコードを使う場面の見極めです。エージェントは強力ですが、あらゆるタスクに適しているわけではありません。エージェントは、曖昧な入力に対する推論が必要なタスクに使います。自然言語クエリの理解、呼び出すツールの判断、コンテキストを踏まえた結果の解釈は、いずれも基盤モデルの推論能力が恩恵をもたらす領域です。決定論的コードで対応しようとすれば、膨大な数のケースを網羅する必要があります。一方、計算、バリデーション、ルールベースのロジックには従来のコードを使います。収益成長率は数式で求められます。日付のバリデーションはパターンマッチで済みます。ビジネスルールは条件分岐です。「Q3 から Q2 を引いて Q2 で割る。」という計算に言語モデルは不要です。Python の関数を書けば、ミリ秒で実行でき、追加コストなしに毎回同一の答えを返します。 適切なアーキテクチャでは、エージェントがコード関数をオーケストレーションします。ユーザーが「今四半期の EMEA の成長率は?」と尋ねると、エージェントは推論によって意図を理解し、どのデータを取得すべきかを判断します。次に決定論的な関数を呼び出して計算を実行し、再び推論を使って結果を自然言語で説明します。 「来月の支出レポートを作成して」というクエリに対する 2 つのアプローチを、大規模言語モデル (LLM) の呼び出し回数、トークン数、レイテンシーの観点で比較してみます。1 つ目は get_current_date() をエージェンティックツールとして公開するアプローチ、2 つ目は現在の日付を属性としてエージェントに渡すアプローチです: get_current_date() をツールとして使用する 現在の日付を属性として渡す クエリ 「来月の支出レポートを作成して」 「来月の支出レポートを作成して」 エージェントの動作 get_current_date() を呼び出す計画を立てる。 取得した日付から翌月を算出。 翌月をパラメータとして create_report() を呼び出し、最終レスポンスを生成。 コードで現在の日付を取得。 today を属性としてエージェントに渡す。 翌月 (LLM の推論で算出) をパラメータとして create_booking() を呼び出し、最終レスポンスを生成。 レイテンシー 12 秒 9 秒 LLM 呼び出し回数 4 回 3 回 合計トークン数 (入力 + 出力) 約 8,500 トークン 約 6,200 トークン 現在の日付はコードで簡単に取得できる情報です。呼び出し時に属性としてエージェントのコンテキストに渡すことができます。2 番目のアプローチの方が高速で、低コストで、しかもより正確です。これを数千のクエリに掛け合わせれば、差は無視できないものになります。コストと価値を継続的に測定します。決定論的コードで確実に解決できる問題にはコードを使い、推論や自然言語理解が必要な場面ではエージェントを使う。よくある間違いは、すべてをエージェンティックにしなければならないと思い込むことです。正解は、エージェントとコードを組み合わせて使うことです。 継続的なテストプラクティスを確立する 本番環境へのデプロイはゴールではありません。スタートラインです。エージェントは絶えず変化する環境の中で動作します。ユーザーの行動は変わり、ビジネスロジックは更新され、モデルの動作はドリフトする可能性があります。こうした変化がユーザーに影響を及ぼす前に検知するために、継続的なテストが必要です。 すべての更新時に実行される継続的テストパイプラインを構築します。一般的なケースとエッジケースを網羅する代表的なクエリを含むテストを整備します。プロンプトの変更、ツールの追加、モデルの切り替えを行うと、パイプラインがテストを実行して結果をスコアリングします。精度がしきい値を下回った場合、デプロイは自動的に失敗します。これによりリグレッションの防止に役立ちます。 A/B テストを活用して、本番環境での変更を検証します。新しいモデルや異なるプロンプト戦略を試す場合、すべて一度に切り替えるのは避けてください。例えば、トラフィックの 10% を新バージョンにルーティングし、1 週間かけてパフォーマンスを比較します。精度、レイテンシー、コスト、ユーザー満足度を測定し、新バージョンの方が優れていれば段階的にロールアウトします。そうでなければロールバックします。AgentCore Runtime は、バージョニングとトラフィック分割の組み込みサポートを提供しています。 本番環境でのドリフトもモニタリングします。ユーザーのパターンは時間とともに変化します。以前はまれだった質問が頻出するようになったり、新製品がリリースされたり、用語が変わったりします。ライブのインタラクションを継続的にサンプリングし、品質指標に照らしてスコアリングします。ドリフトを検知した場合 (例えば、精度が 2 週間で 92% から 84% に低下した場合)、根本原因を調査して対処します。 AgentCore Evaluations は、こうした評価の実行メカニズムを簡素化します。開発ライフサイクルの各段階に対応する 2 つの評価モードを提供しています。オンデマンド評価では、事前定義したテストデータセットに対してエージェントの性能を評価できます。デプロイ前にテストを実行したり、2 つのプロンプトバージョンを並べて比較したり、Ground truth の例に対してモデル変更の影響を検証したりできます。オンライン評価は、ライブの本番トラフィックを継続的にモニタリングし、実際のユーザーとのインタラクションをサンプリング・スコアリングすることで、品質の低下をリアルタイムに検知します。どちらのモードも、OpenTelemetry および OpenInference の計装を通じて、Strands や LangGraph を含む主要なフレームワークと連携します。エージェントの実行時にトレースが自動的にキャプチャされ、統一されたフォーマットに変換された上で、LLM-as-Judge の手法でスコアリングされます。有用性、有害性、精度といった一般的な品質指標には組み込みの評価器を使用でき、ドメイン固有の要件には独自のスコアリングロジックでカスタム評価器を作成できます。次の図は、AgentCore Evaluations に表示される評価指標の例を示しています。 自動ロールバックの仕組みも確立します。重要な指標がしきい値を超えた場合、以前の正常なバージョンに自動的に戻すようにします。例えば、ハルシネーション率が 5% を超えたらロールバックしてチームにアラートを送信します。ユーザーからの問題報告を待ってはいけません。 テスト戦略には次の要素を含めるべきです: すべての変更に対する自動リグレッションテスト メジャーアップデートに対する A/B テスト 本番環境での継続的なサンプリングと評価 自動アラート付きのドリフト検知 品質低下時の自動ロールバック エージェントにおいては、環境が変化し続ける限り、テストも止まることはありません。 組織的な能力を構築する 本番環境で最初のエージェントを稼働させることは大きな成果です。しかし、エンタープライズとしての真の価値は、この能力を組織全体にスケールさせることで生まれます。そのためには、プロジェクト単位の発想ではなく、プラットフォームとしての発想が必要です。 ユーザーからのフィードバックとインタラクションのパターンを継続的に収集します。オブザーバビリティダッシュボードを監視して、どのクエリが成功し、どのクエリが失敗し、テストセットには含まれていないエッジケースが本番で出現しているかを把握します。このデータを使って Ground truth データセットを拡充していきます。当初 50 件だったテストケースが、実際の本番でのインタラクションに基づいて数百件に成長していくのです。 標準の策定と共有インフラの提供のためにプラットフォームチームを立ち上げます。プラットフォームチームの役割は次の通りです: セキュリティチームの審査を経た承認済みツールのカタログを維持する。 オブザーバビリティ、評価、デプロイのプラクティスに関するガイダンスを提供する。 エージェント全体のパフォーマンスを可視化する一元的なダッシュボードを運用する。 新しいチームがエージェントを構築する際は、プラットフォームのツールキットからスタートします。各チームはツールやエージェントの本番デプロイが完了した時点で、プラットフォームへ還元できます。スケールに伴い、プラットフォームチームが再利用可能なアセットと標準を提供する一方で、各チームも独自のアセットを開発し、検証が済んだものをプラットフォームへ戻していきます。 組織全体のエージェントを横断する一元的なモニタリングを導入します。1 つのダッシュボードでエージェント、セッション、コストを一覧できるようにします。トークン使用量が予期せず急増した場合、プラットフォームのリーダーはすぐに気づけます。チーム別、エージェント別、期間別に掘り下げて、何が変わったのかを把握できます。 チーム同士が学び合えるよう、チーム横断のコラボレーションを推進します。3 つのチームがそれぞれ独自のデータベースコネクタバージョンを構築するのは非効率です。代わりに AgentCore Gateway を通じてツールを共有し、評価戦略を共有し、チームがエージェントのデモや課題の議論を行う定期的なセッションを開催すべきです。こうした取り組みから共通の課題が浮かび上がり、共有のソリューションが生まれます。 組織的なスケーリングは、Crawl (ハイハイ)、Walk (歩く)、Run (走る) の段階で進めます: Crawl フェーズ : 小規模なパイロットグループ向けに最初のエージェントを社内にデプロイする。学習とイテレーションに集中する段階であり、失敗のコストは低く抑えられます。 Walk フェーズ : 管理された外部ユーザーグループにエージェントをデプロイする。ユーザーが増え、フィードバックが増え、より多くのエッジケースが発見されます。オブザーバビリティと評価への投資がここで活きてきます。 Run フェーズ : 確信を持ってエージェントを外部ユーザーにスケールさせる。プラットフォームの機能により、他のチームも独自のエージェントをより迅速に構築できるようになります。組織的な能力が複利的に成長していきます。 こうして、1 人の開発者が 1 つのエージェントを構築する段階から、数十のチームが一貫した品質、共有インフラ、加速する開発速度のもとで数十のエージェントを構築する段階へと進化していくのです。 まとめ 本番環境で使える AI エージェントの構築には、基盤モデルを API に接続する以上のことが必要です。開発ライフサイクル全体にわたる規律あるエンジニアリングプラクティスが求められます。次の通りです: 明確に定義された課題から小さく始める。 初日からすべてを計装する。 計画的なツール戦略を構築する。 評価を自動化する。 マルチエージェントアーキテクチャで複雑さを分解する。 パーソナライゼーションを維持しながら安全にスケールする。 エージェントと決定論的コードを組み合わせる。 継続的にテストする。 プラットフォーム思考で組織的な能力を構築する。 Amazon Bedrock AgentCore は、これらのプラクティスを実践するために必要なサービスを提供しています: AgentCore Runtime は、分離された環境でエージェントとツールをホストする。 AgentCore Memory は、パーソナライズされたインタラクションを実現する。 AgentCore Identity と AgentCore Policy は、セキュリティの適用を支援する。 AgentCore Observability は、可視性を提供する。 AgentCore Evaluations は、継続的な品質評価を可能にする。 AgentCore Gateway は、標準プロトコルを使ってエージェントとツール間の通信を統合する。 AgentCore Browser は、AI エージェントが安全なクラウドベースのブラウザを通じてウェブサイトとインタラクトできるようにし、 AgentCore Code Interpreter は、AI エージェントがサンドボックス環境でコードをより安全に記述・実行できるようにする。 これらのベストプラクティスは理論上の話ではありません。実際のワークロードを処理する本番エージェントを構築してきたチームの経験から導き出されたものです。デモで印象的なエージェントと、ビジネス価値を生み出すエージェントの違いは、こうした基本をいかに実行するかで決まります。 詳細については、 Amazon Bedrock AgentCore ドキュメント をご覧ください。また、AgentCore の コードサンプル と、 入門用 および ディープダイブ用 のハンズオンワークショップも公開しています。 本記事はクラウドサポートエンジニアの成本が翻訳しました。原文は こちら です。 著者について Maira Ladeira Tanke は、AWS のエージェンティック AI テックリードとして、自律型 AI システムの開発に取り組むお客様を支援しています。AI/ML 分野で 10 年以上の経験を持ち、エンタープライズのお客様と連携しながら、Amazon Bedrock AgentCore と Strands Agents を活用したエージェンティックアプリケーションの導入を加速させています。組織が基盤モデルの力を活かしてイノベーションとビジネス変革を推進できるよう支援しています。プライベートでは、旅行や愛猫との時間、暖かい場所での家族との団らんを楽しんでいます。 Kosti Vasilakakis は、AWS のエージェンティック AI チームのプリンシパル PM として、Runtime、Browser、Code Interpreter、Identity を含む複数の Bedrock AgentCore サービスの設計と開発をゼロから主導してきました。以前は Amazon SageMaker の初期から携わり、現在世界中の数千の企業で利用されている AI/ML 機能のリリースに貢献しました。キャリアの初期にはデータサイエンティストとして活動していました。仕事以外では、個人の生産性を高める自動化ツールの構築、テニス、妻との時間を楽しんでいます。

みなさん、こんにちは。AWS のインダストリーソリューションアーキテクトの山本です。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 先月号は こちら です。未読の方はあわせてご覧ください。 今月は、ピックアップコンテンツとして昨年ごろから大きな潮流となりつつあるフィジカル AI を特集します。 ピックアップトピック – フィジカル AI フィジカル AI は物理システムの制御方法をこれまでのプログラムやルール、アルゴリズムベースからデータやモデルによって制御するという大きな転換に当たり、その方向性やもたらす価値について境界のない議論が行われています。 2026/1/27に AWS Japan が提供する フィジカル AI についての開発支援プログラム がアナウンスされました。VLA/VLM などのモデル開発について、技術支援やクラウド使用料クレジットの提供、さらにコミュニティ形成や GTM の支援を提供する取り組みで、お客様やパートナー様から大きな反響をいただいています。 フィジカル AI に関連するブログ・動画のご紹介 昨年後半からコンテンツが増加しているフィジカル AI についての有用なブログ記事を 5 本、日本語に翻訳しました。一部の記事については英語版を先月号で共有しています。前半の 3 本のブログはAWS がフィジカル AI をどの様に捉えるか、お客様がどの様にこれを活用しているかについてです。 2 本のブログと Youtube 動画は AWS を活用して NVIDIA の提供するモデルやシミュレータを動かすための実践的な内容です。 フィジカル AI: 自律型インテリジェンスに向けた次なる基盤を築く AWS のフィジカル AI フレームワークについての解説記事です。物理世界を認識、理解、推論、学習し、相互作用するハードウェアとソフトウェアのシステムとしてフィジカル AI を定義し、6 つの関連する機能からなる包括的なフレームワークを提示しています。クラウドでのトレーニングループとエッジでの自律ループを統合した二重ループアーキテクチャにより、継続的な学習サイクルを実現し、自律経済への移行を支援します。 AI による物理的な現実世界の進化 : インテリジェントな自動化の最前線 このブログは、AI と物理システムが融合したフィジカル AI のもたらす変革について解説しています。 4 段階のレベルの分類と、製造業における 25% の効率向上や医療での合併症 30% 減少といった成果、2034 年における AI ロボット市場が 1,242 億ドル、デジタルツイン技術市場が 3,790 億ドルといった予測が述べられています。AWS は MassRobotics、NVIDIA と共同で立ち上げた Physical AI Fellowship を通じて、次世代ロボティクスと自動化ソリューションを開発する 8 社のスタートアップを支援しています。 フィジカル AI の実践: 人間と機械の相互作用を支える技術基盤 このブログは、フィジカル AI の実践的な技術基盤について解説しています。人間と機械の相互作用を支える完全な開発ライフサイクルとして、データ収集・準備、強化学習や模倣学習などのモデルトレーニング、量子化や蒸留による最適化、エッジでの運用までを詳述しています。Diligent Robotics の Moxi ロボットを事例に、病院環境で 120 万回以上の配達と 60 万時間近くのスタッフ時間節約を実現した成果を紹介し、ガバナンス、安全性、倫理的配慮の重要性も強調しています。 AI を具現化するブログ: パート1 AWS Batch でロボット学習を開始する AWS Batch を使用して NVIDIA Isaac GR00T N1.5 3B モデルをファインチューニングするためのスケーラブルな基盤の構築方法を解説します。ロボット学習の最新技術である模倣学習や強化学習のフレームワークを紹介し、AWS CDK を用いた自動デプロイメント、Amazon EFS による共有ストレージ、Amazon DCV を活用したシミュレーション評価環境の構築手順を詳しく説明しています。クラウドの弾力性と NVIDIA の先進的なロボット学習スタックを組み合わせることで、開発サイクルを加速し、大規模なデータセットを効率的に管理できます。 知的なフィジカル AI 構築: Strands Agents、Bedrock AgentCore、Claude4.5、NVIDIA GR00T、および Hugging Face LeRobot によるエッジからクラウドへ Strands Agents、Amazon Bedrock AgentCore、Anthropic Claude 4.5、NVIDIA GR00T、Hugging Face LeRobot を活用した、エッジからクラウドまでの知的なフィジカル AI の環境構築について解説しています。エッジでのミリ秒レベルの応答性と、クラウドでの高度な推論を組み合わせ、ロボットが物理世界で認知・判断・行動するハイブリッドアーキテクチャを実現します。SO-101 ロボットアームや Boston Dynamics Spot での実装例により、VLA モデルによる直接的な物理制御と SDK ベースの制御の両方を紹介し、継続的な学習と改善を実現するアプローチを提供しています。 How to Build Physical AI Agents: Natural Language for Real-World Robotics 上記のブログと対応した内容の AWS Show and Tell シリーズの動画です。O-101 3D (印刷可能なロボットアーム)を Jetsonエッジデバイスに接続し、ファインチューニングされたNVIDIA GR00T VLAモデルを用いて、ハードウェア統合用の Hugging Face LeRobot を接続しています。Strands Agents フィジカル AI エージェントを自然言語でインテリジェントにオーケストレーションします。 Physical AI Unleashed: Teaching Humanoid Robots to Pick, Place & Inspect この動画では、NVIDIA GR00t N1.5とUnitree G1を搭載したヒューマノイドロボットが、リアルタイムの品質検査を行いながら精密なピックアンドプレース操作を実行できるようにする現実世界のアプリケーションを構築します。コンピュータービジョン、生成 AI、ロボティクスを組み合わせて、物体を動かすだけでなく、その処理内容を理解するインテリジェントなシステムを構築します。自然言語による指示から、在庫確認 → ナビゲーション → ピック＆パック → 配送 → 帰還という一連の作業の自律的な実行も実現しています。 Revolutionizing warehouse automation with scientific simulation Amazon Science のブログ記事で、Amazon Robotics の ID チーム（AR-ID）が開発した Sensor Workbench について述べています。これは倉庫内のセンサー配置を最適化するための革新的なシミュレーションプラットフォームで、CAD で記述された詳細な倉庫モデルをシミュレーション用の 3D アセットに変換し、OpenUSD をシミュレーションプロセス全体のデータ基盤として活用、NVIDIA の Isaac Sim をベースにしたシミュレータにより、物理ベースのセンサーモデリングと高精度な 3D 環境を組み合わせたシミュレーションが可能です。 AWS re:Invent 2025 – Train, Simulate, Deploy: Building NVIDIA-Powered Physical AI on AWS (AIM117) re:Invent 2025 のセッション動画で、NVIDIA のソリューションによるフィジカル AI を AWS クラウド上で実行する方法について解説しています。Amazon EC2 GPU インスタンスや、 AWS Batch および NVIDIA Isaac Lab を活用して大規模に実行する方法について紹介しています。 ガイダンス: ロボティクスのためのフィジカル AI on AWS 12月の本ブログで紹介済みですが、フィジカル AI を AWS クラウド上で実現するためのリファレンスアーキテクチャとガイダンスです。 CES 2026 2026年1月6日～9日に開催された CES では、Alexa Plus や Amazon Leo などの 最新のプロダクト、テクノロジーの展示 とともに、 Amazon Robotics と共同で、フィジカルAI によるアームロボットのピック作業をデモを展示しています。Siemens Xcelerator / NVIDIA Omniverse を活用した工場のデジタルツインや Snlowflake を活用した予防保守も統合されています。 デモ動画リンク (要Linked In アカウント) 製造関連の主要なアップデート 12/8 空間データのインサイトを加速させる Spatial Data Management on AWS を発表 本日、AWS は、ユーザーに空間データの大規模な保存、強化、接続を可能にするソリューションである Spatial Data Management on AWS (SDMA) を発表しました。SDMA を使用すると、お客様は物理アセット (3D、地理空間、行動、時系列データ) を表すマルチモーダル空間データを、安全で一元化されたクラウド環境に保存できるようになります。 1/8 Amazon EC2 G7e インスタンスの一般提供開始(NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs) 大規模言語モデル (LLM)、エージェンティック AI モデル、マルチモーダル生成 AI モデル、物理 AI モデルのデプロイにも適した最新の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載する G7e インスタンスが一般提供開始になりました。 こちらのブログ で詳細が説明されています。 1/8 Amazon MQ が RabbitMQ ブローカーで相互 TLS を使用した証明書ベース認証をサポート Amazon MQ の RabbitMQ ブローカーで、mTLS を利用した X.509 クライアント証明書による認証機能が追加されました。従来のユーザー名とパスワード認証に加えて、より安全な証明書ベース認証が利用可能になり、企業システムでよく使われる PKI 基盤との連携が簡単になります。RabbitMQ 4.2 以上と M7g インスタンスで利用でき、設定ファイルを編集するだけで有効化できます。詳細は こちらのドキュメントをご参照ください。 2/2 Amazon SageMaker JumpStartでNVIDIA NIMsモデルが利用可能に Amazon SageMaker JumpStartで、バイオサイエンスとフィジカルAI向けに構築された4つのNVIDIA NIMsモデル（ProteinMPNN、Nemotron-3.5B-Instruct、MSA Search NIM、Cosmos Reason）がワンクリックデプロイ可能になりました。Cosmos ReasonはフィジカルAIとロボティクス向けのオープンでカスタマイズ可能な推論ビジョン言語モデルです。 直近で開催予定のイベント re:Invent製造領域 re:Cap 昨年12月に開催された re:Invent 2025 の製造領域の日本語による振り返り(reCap)セッションを、本年は Black Belt オンラインセミナーとして提供予定です。コンテンツはこちらの Youtube Playlist で公開される予定です。 事例のご紹介 製造業に関連する事例や、ブログによる技術詳細説明です。 JFE スチールが挑むインテリジェント製鉄所への道 – Amazon SageMaker AI による CPS 開発実行基盤の構築 JFE スチール株式会社による CPS (Cyber Physical System)開発実行基盤の構築について、これを主導された JFE スチール株式会社 庄村 啓様、JFE システムズ株式会社 杉田 朋晃様、原 洋平様、髙山 翔伍様より寄稿いただきました。 smart EuropeがAmazon Bedrockでカスタマーサポート業務を変革した方法 smart Europe が Amazon Bedrock を活用してカスタマーサポート業務を変革した事例を紹介しています。AI による問い合わせケースの自動タグ付けと、ナレッジベースに基づくインサイト生成により、問い合わせ解決時間を 40% 短縮し、ファーストコンタクトによる解決率を 20% 向上させました。サーバーレスアーキテクチャを採用し、10,000 件以上の問い合わせを処理しながら、当初予算から 30% のコスト削減を実現しています。 製造関連ブログのご紹介 今月もたくさんのブログが公開されました。 12/26 回復力のあるサプライチェーンの構築: Amazon Bedrock を活用した小売・消費財向けマルチエージェント AI アーキテクチャー このブログは、Amazon Bedrock を活用したマルチエージェント AI アーキテクチャによる、回復力のあるサプライチェーン構築について解説しています。港湾閉鎖などの混乱時に、 Amazon Bedrock AgentCoreを用いた エージェントが物流最適化、在庫管理、プロモーションリスク、出荷追跡の各専門エージェントを調整し、数分以内にデータ駆動型の対応策を提案します。小売・消費財業界向けに書かれていますが、製造業にも適用できる内容です。 1/7 「AWS IoT Greengrass と Strands Agents を使用した Small Language Model の大規模デプロイ」 AWS IoT GreengrassとStrands Agentsを使用して、Small Language Model（SLM）をエッジデバイスに大規模デプロイする方法を解説しています。製造業のOPC-UAプロトコルを例に、リアルタイムの機械データをローカルで処理しながら、複雑な分析はクラウドで実行するハイブリッドアプローチを実現します。SLMは軽量でありながら、制約のあるハードウェア上で動作し、オペレーターに即座の洞察を提供できます。 1/7 Amazon Kinesis Video Streams の warm ストレージ階層で長期動画保存コストを最適化 このブログは、Amazon Kinesis Video Streams の新しい Warm ストレージ階層について解説しています。従来の Hot 階層と比較して最大 67% のコスト削減を実現し、長期的な動画保存に最適化されています。高解像度ビデオでより大きなコスト削減効果が得られ、30 日以上の保存期間で特に効果を発揮します。耐久性と可用性を維持しながら、物理セキュリティや監視システムでの大規模なカメラネットワークの運用コストを大幅に削減できる実践的なソリューションを提供しています。 1/15 AUMOVIO Boosts Software Development with an Agentic Coding Assistant Powered by Amazon Bedrock Continental からスピンオフした AUMOVIO による自動車業界向けのコーディングアシスタントについてのブログ記事です。AUMOVIOのソリューションは、複数のAIモデルを利用してさまざまな開発ライフサイクルのステップを加速すると同時に、AUTOSAR, MISRA-C/C++ といった自動車業界標準との整合性の確保や、独自のコーディング規約を順守するのに役立ちます。コードの再利用を最大化し、必要な変更を最小限に抑えることで、アシスタントは他の V-model ステップの労力を大幅に軽減します。 1/25 re:Invent 2025 自動車・製造reCap Blog 日本語訳 1月にご紹介した自動車・製造領域のまとめブログを日本語化しました。 2/3 【開催報告】第9回鉄道技術展2025 AWS出展報告 2025年11月26日から29日に開催された「第9回鉄道技術展2025（Mass-Trans Innovation Japan 2025）」に AWSが出展した際の報告ブログ記事です。展示内容としてクラウドとAIを活用した鉄道保全システムのソリューションをご紹介しており、製造業における設備保全の観点でも参考になる内容です。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 山本 直志 (Tadashi Yamamoto) 製品開発エンジニアから、組み込み開発のアーキテクトやエンジニアリング支援を経て、エレクトロニクスや自動車産業のお客様を長年支援し、AWS では製造業のスペシャリストソリューションアーキテクトとして活動しています。製造業における業務課題解決や新規ビジネスにおけるクラウド活用の可能性をお客様と一緒に探求しています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 11 月・ 12 月合併号 はお読みいただけましたでしょうか。2026 年のアップデートをお届けする最初のブログ更新となります。本年も Amazon Connect の最新情報や有益な情報をお届けできるよう努めてまいります。皆さんのお役に立つ内容があれば幸いです！ 今月は 以下の内容でアップデート情報をお届けします。 Amazon Connect Starter Kit のご紹介 2026 年 1 月のアップデート一覧 AWS Contact Center Blog のご紹介 1. Amazon Connect Starter Kit のご紹介 Amazon Connect で AI エージェントを活用したコンタクトセンターをすぐに構築・体験できるスターターキット( sample-amazon-connect-starter-kit-japan )をご紹介します。本パッケージの最大の特徴は、デプロイするだけで AI エージェントを活用したコンタクトセンター環境が即座に利用可能になる点です。Amazon Connect AI エージェントを中心に、音声・チャットの複数チャネルに対応した環境が自動的に構築されます。複雑な設定作業は不要で、付属のデプロイメントガイドに従うだけで環境が完成します。 最新の AI エージェント機能を体感 Amazon Connect の AI エージェントは、従来の Amazon Q in Connect から進化した、より高度な自律型 AI です。顧客は「Connect アシスタント」と呼ばれる会話型インターフェイスを通じて AI エージェントとやり取りし、複雑でオープンエンドな問い合わせにも対応できます。ナレッジベースを参照した自動応答、複数の意図を含む問い合わせへの対応、コンテキストを維持した会話など、最新の Agentic AI 機能を実際に体験できます。 Amazon Connect では 最新のAgentic AI エージェントだけでなく、従来のAmazon Lex でのインテントベースの決定論的 AI も引き続き利用可能です。AI エージェントが複雑でオープンエンドなやり取りを処理する一方、決定論的 AI は事前定義されたインテントや特定の会話フローを処理します。この組み合わせにより、従来の決定論的 AI と自律的な Agentic AI の両方の長所を活用したセルフサービス体験を提供できます。 日本語・日本リージョン対応 us-east-1(バージニア北部)と ap-northeast-1(東京)の両リージョンでのデプロイに対応しています。また、日本語での利用を前提とした設定やドキュメントが含まれており、日本のコンタクトセンター環境ですぐに活用できます。 2. 2026 年 1 月のアップデート一覧 Amazon Connectが待ち時間予測の精度を向上 – 2026/01/31 Amazon Connect では、キューおよびキューに入っているコンタクトに対する待ち時間予測メトリクスが改善されました。これにより、コンタクトセンターは顧客に正確な待ち時間を伝えられるようになり、待ち時間が長い場合にはコールバックなどの便利なオプションを提供したり、複数のキュー間で業務負荷を効果的に分散したりできるようになります。改善された待ち時間予測メトリクスを活用することで、コンタクトセンターはキュー間でより戦略的なルーティング判断を行えるようになり、リソース計画のための可視性も向上します。たとえば、ピーク時に請求に関する問い合わせで15分の待ち時間が発生している場合、2分で対応可能なクロストレーニングされたチームにシームレスに転送することで、顧客は問題を繰り返し説明することなく、より早くサポートを受けられます。このメトリクスは、ルーティング条件やエージェントの習熟度設定とシームレスに連携します。 関連リンク 管理者ガイド Amazon Connect Cases に対するきめ細かなアクセス制御をサポート – 2026/01/28 Amazon Connect では、ケースに対してタグベースのアクセス制御を適用できるようになり、管理者はケースデータの閲覧と管理をより詳細に制御できるようになりました。この機能により、ケーステンプレートにタグを関連付け、セキュリティプロファイルを設定することで、特定のタグが付いたケースにアクセスできるユーザーを制御できます。たとえば、不正行為に関連するケースにタグを付け、不正対策のセキュリティプロファイルが割り当てられたユーザーのみがそれらのケースを閲覧または編集できるようにアクセスを制限することが可能です。これにより、社内統制の強化やデータアクセスポリシーの徹底が実現できます。 関連リンク 管理者ガイド Amazon Connect のステップバイステップガイドに条件分岐ロジックとリアルタイム更新機能が追加 – 2026/01/23 Amazon Connect のステップバイステップガイドが強化され、マネージャーはより動的で柔軟性の高いガイド体験を構築できるようになりました。ユーザーの操作に応じて変化する条件付きユーザーインターフェースを作成できるため、ワークフローの効率が向上します。たとえば、マネージャーはドロップダウンメニューを設定し、前の項目への入力内容に基づいて、フィールドの表示・非表示を切り替えたり、デフォルト値を変更したり、必須項目を調整したりすることができます。これにより、さまざまなシナリオに合わせたカスタマイズされた体験を提供できます。さらに、ステップバイステップガイドは、フローモジュールなどの Connect リソースから指定した間隔でデータを自動的に更新できるようになり、エージェントは常に最新の情報を使って業務を行えるようになりました。 関連リンク 管理者ガイド Amazon Connect が評価目的でのエージェントのコンタクトのランダムサンプルの自動選択を開始 – 2026/01/21 Amazon Connect において、エージェントの評価を目的としたコンタクトのランダムサンプリング機能が追加されました。この機能により、マネージャーはエージェントに対して適正なコーチングとフィードバックを提供できるようになります。マネージャーは、労働協約や社内ガイドラインに従って、エージェントごとに確認が必要なコンタクト数を指定できます。指定した数のコンタクトは、設定した期間からランダムに抽出されます。たとえば、先週の期間からエージェント 1 人あたり 3 件のコンタクトを自動的に選択することが可能です。さらに、新しいフィルター機能を使用することで、評価に適したコンタクトを確実に選択できます。音声録音、画面録画、トランスクリプトが含まれるコンタクトに絞り込んだり、過去に評価済みのコンタクトを除外したりすることができます。これにより、マネージャーは効率的かつ公平にエージェントのパフォーマンスを評価し、質の高いフィードバックを提供できるようになりました。 関連リンク 管理者ガイド Amazon Connect がデータレイクでのエージェントのスケジューリングメトリクスの提供を開始 – 2026/01/15 Amazon Connect がデータレイク内でエージェントのスケジューリングメトリクスを提供するようになり、このデータからレポートやインサイトを簡単に生成できるようになりました。たとえば、来月のスケジュール公開後に、Connect の分析データレイク内で、予測される人数、スケジュールされた人数、予想されるサービスレベルなど、15 分または 30 分間隔のメトリクスにアクセスできます。ビジネスユニット全体(予測グループ)の集計メトリクスを利用したり、特定の需要セグメント(需要グループ)別に分類したりすることが可能です。その後、Amazon QuickSight または任意の BI ツールでこのデータを可視化して、人員過剰や人員不足になっている期間を特定するなど、さらに詳細な分析を行えます。これにより、エージェントのスケジュールを手動で確認する必要がなくなり、スケジューラとスーパーバイザーの生産性が向上します。 関連リンク 管理者ガイド Amazon Connect で営業時間の定期的なオーバーライドの簡単な管理が可能に – 2026/01/14 Amazon Connect で、日、月、または年単位で一目で確認できるカレンダー表示を使用して、休日、メンテナンス期間、プロモーション期間などの定期的なイベントに応じたコンタクトセンターの営業時間を簡単に管理できるようになりました。毎週、毎月、または隔週の金曜日に自動的に有効になる定期的なオーバーライドをセットアップすることで、カスタマーエクスペリエンスをパーソナライズできます。すべての設定は自動的に適用されるため、手動で再確認する必要はありません。たとえば、エージェントの稼働状況を確認することなく、毎年 1 月 1 日に自動的に顧客へ「新年あけましておめでとうございます」という挨拶を送り、特別なホリデーメッセージに誘導できます。1 月 2 日には自動的にコンタクトセンターが通常業務に戻ります。 関連リンク 管理者ガイド Amazon Connect Cases が AWS CloudFormation のサポートを開始 – 2026/01/13 Amazon Connect Cases で AWS CloudFormation のサポートが開始され、Infrastructure as Code として Cases のリソースをモデル化、プロビジョニング、管理できるようになりました。今回のリリースにより、管理者は CloudFormation テンプレートを作成して、Amazon Connect インスタンス全体にわたって Cases の設定(テンプレート、フィールド、レイアウトなど)をプログラムによってデプロイおよび更新できます。これにより、手動でのセットアップ時間を短縮し、設定エラーを最小限に抑えることができます。 関連リンク 管理者ガイド Amazon Connect でエージェント画面録画の状況を追跡する機能の提供を開始 – 2026/01/13 Amazon Connect では、Amazon EventBridge を使用して CloudWatch でエージェントの画面録画の状況をほぼリアルタイムで表示できるようになりました。スーパーバイザーは画面録画を使用することで、顧客との通話を聞いたり、チャットの文字起こしを確認したりするだけでなく、問い合わせを処理する際のエージェントのアクション(音声通話、チャット、タスクなど)を監視できます。これにより、エージェントにコーチングが必要な領域(たとえば、ビジネスプロセスの違反など)を特定できます。Amazon EventBridge を使用すると、成功・失敗のステータス、失敗コードとその説明、インストールされているクライアントのバージョン、エージェントのウェブブラウザのバージョン、エージェントのオペレーティングシステム、画面録画の開始と終了の時刻など、各エージェントの画面録画の状況を CloudWatch から確認できます。Amazon EventBridge イベントバスの「Screen Recording Status Changed」イベントタイプにサブスクライブすることで、Amazon Connect 画面録画の状況追跡機能の使用を開始できます。 関連リンク 管理者ガイド ネストされた JSON オブジェクトとループ配列を格納する機能が Amazon Connect で提供される – 2026/01/03 Amazon Connect では、複雑なデータ構造をフローに保存して処理できるようになったため、社内のビジネスシステムから返される豊富な情報を使用する動的な自動化エクスペリエンスを簡単に構築できます。ネストされた JSON オブジェクトやリストを含む完全なデータレコードを保存し、JSON 形式で返された注文のリストから、特定の注文など、その中の特定の要素を参照できます。さらに、カスタマーサービスフロー内の項目のリストを自動的にループ処理して、ループ内の現在の位置を追跡しながら、各エントリを順番に処理できます。これにより、アイテムレベルの詳細に簡単にアクセスし、関連情報をエンドカスタマーに提示できます。たとえば、旅行代理店は、1 回のリクエストで顧客の旅程をすべて取得し、電話をかけてきた顧客に各予約を案内して、予約を確認または更新することができます。銀行も同様に、システムから安全に取得したデータを使用して、最近の取引を1つずつ顧客に説明できます。これらの機能により、ビジネスシステムを繰り返し呼び出す必要がなくなり、ワークフローの設計が簡単になり、ビジネス要件の変化に適応する高度な自動エクスペリエンスの提供が容易になります。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 テスト時間を最大 90% 削減 – Amazon Connect のテストとシミュレーション機能 (日本語翻訳) コンタクトセンター管理者は、本番環境を中断することなくコンタクトフローを効率的にテストする課題に直面してきました。従来は手動でシステムに電話をかけたり、カスタム検証ツールを構築したり、サードパーティソリューションに投資する必要があり、時間とコストがかかっていました。Amazon Connect は、このような課題を解決するネイティブコールシミュレーション機能の一般提供を開始しました。この機能により、外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、検証時間を最大 90 %削減できます。テストフレームワークは、イベント駆動型モデルと直感的なビジュアルインターフェースを採用しており、技術者以外のチームメンバーでも簡単にテストを作成できます。「X が発生したら Y を実行する」という自然な観点でテストを記述し、Observe (観察)、Check (検証)、Action (アクション)の 3 つのブロックを組み合わせてテストシナリオを構築します。専用のテストダッシュボードでは、テスト実行履歴や成功率、失敗の詳細な洞察が得られ、継続的な改善を推進できます。本ブログ記事では、Amazon Connect の新しいネイティブテストとシミュレーション機能を活用して、コンタクトセンターの検証を自動化する方法について紹介しています。 Amazon Connect の裏側: イノベーターとしての進化 (日本語翻訳) Amazon Connect は、2007 年に Amazon の内部カスタマーサービスチームが3つのコンタクトセンターベンダーを置き換えるために構築した統合ソリューションから始まりました。従来の方法では 300 万ドルの前払い投資が必要でしたが、内部ソリューションはより安価で、Amazon のミッションを体現するものでした。Audible や Zappos など新たに買収された企業も熱心に採用し、年間推定 6,000 万ドルの節約を実現しました。2017 年のパブリックローンチ後、Capital One、Hilton、GE などの大企業が、従来 1 年間かかっていた構築プロセスを週末のプロジェクトに変えるクラウドネイティブなアーキテクチャに魅力を感じ、急速に採用が進みました。2019 年に AI を活用した会話分析や感情分析をローンチし、2023 年には Forrester と Gartner の主要レポートでリーダーシップポジションを獲得しました。生成 AI の出現により、自動エージェントラップアップや通話要約などの機能を提供し、2024 年 12 月には 60 億分、2025 年には 120 億分の顧客とのやり取りを AI で最適化しました。先週の Q3 2025 年決算報告では、年間換算売上高 10 億ドルのペースを達成したことが発表されました。本ブログ記事では、Amazon の内部ソリューションから AI のパイオニアへと進化した Amazon Connect のストーリーと、今後のエージェンティック AI への展望について紹介しています。 How NatWest Simplified Contact Center Analytics with Amazon Connect analytics data lake (英語記事) 英国の大手金融機関 NatWest Group は、2019 年に Amazon Connect を導入しましたが、当初はカスタム ETL パイプラインを使用したデータ処理に大規模なメンテナンスと定期的な更新が必要で、運用の複雑さとコストの増加に直面していました。2024 年、NatWest は Amazon Connect 分析データレイクの Zero ETL アーキテクチャを採用し、データアクセスと分析を大幅に簡素化しました。この移行により、従来 2 か月かかっていた CTR パイプラインの構築がわずか1週間で完了するようになり、通話完了から 1 時間以内にデータが利用可能になることで、タイムリーな意思決定が可能になりました。Zero ETL アプローチにより、センチメント分析や通話結果などの事前処理されたメトリクスに即座にアクセスでき、IVR パフォーマンスダッシュボードや会話品質分析ダッシュボードを通じて顧客インタラクションに関する多次元的な洞察を得られるようになりました。本ブログ記事では、NatWest が Amazon Connect 分析データレイクを活用してコンタクトセンター分析を簡素化し、データドリブンな顧客サービスを実現した事例について紹介しています。 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は 2026 年 2 月 9 日 に公開された「 Using Amazon SageMaker Unified Studio Identity center (IDC) and IAM-based domains together 」を翻訳したものです。 Amazon SageMaker Unified Studio で、2 種類のドメイン構成が利用できるようになりました。ガバナンス機能が充実した Amazon SageMaker Unified Studio Identity Center (IDC) ベースドメインと、開発者の生産性を高める Amazon SageMaker Unified Studio IAM ベースドメインです。 本記事では、AWS Identity and Access Management (IAM) ロールの再利用と属性ベースのアクセス制御を使って、Amazon SageMaker Unified Studio の両方のドメイン構成を併用する方法を紹介します。 各構成での認証の仕組み Amazon SageMaker Unified Studio IDC ベースドメイン は、AWS IAM Identity Center のシングルサインオンでユーザーを認証し、セッション全体を通じて個々のユーザー ID を保持します。ID ベースの認可、ユーザー間のきめ細かなアクセス制御、承認プロセスを含む Publisher/Subscriber (Pub/Sub) データ共有ワークフローによるカタログ管理など、ガバナンス面で優れた機能を備えています。ID 管理、コンプライアンス追跡、ID ベースの監査証跡が求められるエンタープライズ環境に適しています。 Amazon SageMaker Unified Studio IAM ベースドメイン は、フェデレーテッド IAM ロールで認証し、プロジェクトにアクセスするすべてのユーザーが同じロール権限を共有します。サーバーレス Notebook、Athena Spark 統合、縦型ナビゲーションによる使いやすいインターフェース、組み込みの AI アシスタントなど、開発者の生産性を重視した最新ツールを提供します。効率的なアクセスと高度な分析機能が必要な開発チームに適しています。 IDC ベースドメインを既に使用している組織は、既存のガバナンスフレームワークを維持しながら、IAM ベースドメインでチームに最新の開発機能を提供できます。新しくリリースされた IAM ベースドメインのみを使用したい場合は、そのまま利用できます。どちらを選ぶかは、組織のニーズ次第です。 本記事の執筆時点では、IAM ベースドメインは 信頼された ID の伝播 をサポートしていません。本記事のソリューションでは、 プロジェクト実行ロール でデータアクセスを設定します。 課題 データスチュワード の Sam は、IDC ベースドメインを使用してデータアクセスポリシーの定義、データカタログの管理、サブスクリプションリクエストの承認を行い、コンプライアンスと適切なデータガバナンスを確保しています。 一方、 データエンジニア の Sarah は、IDC ベースドメインのガバナンス機能 (SageMaker Catalog など) と、IAM ベースドメインの新しい サーバーレス Notebook を使ってデータパイプラインの構築、高度な分析、開発サイクルの短縮を行いたいと考えています。Sarah は IDC ベースドメインでデータへのアクセスをリクエストし、Sam が承認すると、IAM ベースドメインのサーバーレス Notebook でそのデータにアクセスできるようになります。 ソリューションの概要 この統合では、IAM ロールの再利用、 AWS Lake Formation の属性ベースのアクセス制御 (ABAC)、Amazon SageMaker Catalog の Pub/Sub モデルを活用して、IDC ベースドメインの権限を IAM ベースドメインに自動的に引き継ぎます。適切に設定すると、IDC ベースドメインの Pub/Sub モデルで管理されるデータサブスクリプションが IAM ベースドメインのプロジェクトですぐに利用可能になり、統一されたデータアクセス体験を実現します。 本記事で実装するソリューションでは、IDC コンシューマープロジェクトと同様の IAM ベースドメインプロジェクト (同じチームメンバー、ユースケースなど) を作成し、実行ロールを設定してロールの再利用を有効にします。既存のサブスクリプションワークフローを維持しながら、IAM ベースドメインのメリットを活用できます。以下の図にアーキテクチャの全体像を示します。 ソリューションアーキテクチャの構成要素: 既存の IDC ベースドメイン : Pub/Sub モデルによるデータ共有が確立されたプロデューサーおよびコンシューマープロジェクトを含む IAM ベースドメイン : 最新の開発ツール向けにフェデレーテッドロールと実行ロールが設定された新しいプロジェクト IAM Identity Center : フェデレーテッドアクセスとアクセス許可セットを管理 属性ベースのアクセス制御 : 実行ロールのタグにより権限の自動継承を実現 このソリューションには 2 つのオプションがあります。オプション 1: IDC ベースドメインのプロジェクトロール再利用は、最もシンプルな統合パスです。IDC ベースドメインの既存のコンシューマープロジェクト IAM ロールを、IAM ベースドメインの実行ロールとしてそのまま再利用します。主なメリットは、ポリシー変更のみで済むセットアップの簡素化 (詳細は後述)、管理するロールが 1 つ少なくなる管理負荷の削減、実績のある既存ロールを活用するため設定ミスのリスクが低いことです。オプション 1 は、最速の実装パスが必要な場合、ロールの増加を最小限に抑えたい場合、データアクセス権限が既に設定された IDC ベースドメインロールがある場合、または IAM の専門知識が限られたチームで複雑なタグ設定を避けたい場合に適しています。 オプション 2: IAM ベースドメインプロジェクト用に新しい実行ロールを作成し、IDC ベースドメインのプロジェクト ID でタグ付けして属性ベースのアクセス制御 (ABAC) を使用します。主なメリットは、2 つの異なるロール (IDC ベースドメイン用と IAM ベースドメイン用) による監査性の向上、CloudTrail ログでどのドメインからリクエストが発生したかを明確に区別できること、IDC ベースドメインの運用に影響を与えずに IAM ベースドメイン固有の権限をカスタマイズできる柔軟性、2 つのドメインタイプ間のセキュリティ分離の向上です。 AmazonDatazoneProject タグにより 属性ベースのアクセス制御 が有効になり、ロール ID は個別に維持されます。オプション 2 は、ドメインタイプを区別する詳細な監査証跡が必要な場合、コンプライアンスポリシーでガバナンス環境と開発環境の責務分離が求められる場合、各ドメインのコストを個別に追跡・帰属させたい場合、またはコンプライアンスレポートでどのドメイン (ガバナンス vs. 開発) が特定のデータリソースにアクセスしたかを示す証拠が必要な場合に適しています。 以下は、両方のオプションで ID とドメインエンティティがどのようにマッピングされるかの概要図です。 前提条件 本記事の手順を実施するには、以下が必要です。 Amazon SageMaker Unified Studio IDC ベースドメイン が設定済みの AWS アカウント Amazon SageMaker Unified Studio IDC ベースドメインに既存のプロデューサーおよびコンシューマー プロジェクト Pub/Sub モデルで公開・サブスクライブ済みの データアセット Amazon IAM Identity Center への管理者アクセス プロジェクト、環境、IAM ロールなど Amazon SageMaker Unified Studio の概念への理解 管理者として作成済みの Amazon SageMaker Unified Studio IAM ベースドメイン 本記事のデモでは、Sales プロデューサープロジェクトと、そのテーブルをサブスクライブする Marketing コンシューマープロジェクトを使用します。 現在の IDC ベースドメインの構成を理解する まず、既に運用中の Amazon SageMaker Unified Studio IDC ベースドメインの構成を確認します。 Sales プロデューサープロジェクト pipeline テーブルと sales テーブルを含むデータベースがある データスチュワードの Sam がデータアセットの作成と公開を管理 専用のプロジェクト IAM ロールを持つ Marketing コンシューマープロジェクト データエンジニアの Sarah が IDC ドメインプロジェクトを通じて公開データをサブスクライブして管理 専用のプロジェクト IAM ロールを持つ IDC ベースドメインのインターフェースでサブスクライブ済みデータのクエリに成功 各プロジェクトにはデータアセットへのアクセスを制御する IAM ロールが関連付けられており、Pub/Sub モデルがサブスクリプションワークフローと権限を管理します。 アクセス許可セットによるフェデレーテッドロールの設定 アクセス許可セット によるフェデレーテッドロールは、AWS IAM Identity Center を通じて IAM ベースドメインへのコンソールアクセスをユーザーに認証・提供するために使用されます。プロジェクト内のすべてのユーザーが同じロール権限を共有します。アクセス許可セットを割り当てると、IAM Identity Center は AWS アカウントに対応する IAM Identity Center 管理の IAM ロールを作成し、アクセス許可セットで指定されたポリシーをそのロールにアタッチします。 IAM ベースの SageMaker Unified Studio ドメインにより、ガバナンスを維持しながら最新の開発ツール (サーバーレス Notebook、Athena Spark、AI アシスタント) への効率的なアクセスが可能になり、重複するアクセス承認なしにドメイン間で権限が自動的に伝播され、チームメンバーのオンボーディングが簡素化されます。IAM ベースドメインへのアクセスには任意の IAM ロールを使用できます。本記事では、AWS IAM Identity Center (IDC) を使用したフェデレーテッドロールオプションを使用します。 IAM ベースドメイン用にデータエンジニアグループへのアクセスを付与する 1) AWS IAM Identity Center でフェデレーテッドロールを設定する AWS マネジメントコンソールで IAM Identity Center (IDC) に移動し、以下の手順を実行します。 IDC のアクセス許可セットセクションに移動します。 Marketing-federated-role という新しいアクセス許可セットを作成し、[Attach policy] を選択します。 既存のポリシー名リストから SageMakerStudioUserIAMConsolePolicy を検索し、リストから SageMakerStudioUserIAMConsolePolicy を選択します。SageMaker IAM ドメインのプロジェクトにアクセスするには、マネージドポリシー SageMakerStudioUserIAMConsolePolicy をアタッチするか、同等の権限を別のポリシーで追加する必要があります。 IDC の AWS アカウントセクションに移動します。 作成したアクセス許可セットを AWS アカウントに割り当てます。 本記事では、アクセス許可セットを marketing グループに割り当てました。ベストプラクティスとして、個々のユーザーではなくグループにアクセスを設定・付与してください。 Sarah を marketing グループに追加します。 この設定で、Sarah が IAM ベースドメインにアクセスするフェデレーテッドロールが作成されます。フェデレーテッドロールはアカウント内の IAM ロールとして表示され、コンソールアクセスのエントリポイントとなります。 IAM ベースドメインの実行ロールの設定 IAM ベースドメインプロジェクトの実行ロールの設定には 2 つのオプションがあります。実行ロールはフェデレーテッドロールと 1 対 1 でマッピングされます。 オプション 1 – IDC ベースドメインのプロジェクトロール再利用 新しい実行ロールを作成してタグ付けする代わりに、IDC ベースドメインのコンシューマープロジェクト IAM ロールを IAM ベースドメインプロジェクトの実行ロールとして直接再利用できます。コンシューマープロジェクト IAM ロールのポリシー変更のみで対応できます。IDC ベースドメインのコンシューマープロジェクト IAM ロールを確認するには: Amazon SageMaker Unified Studio IDC ベースドメインポータルに移動します。 Marketing コンシューマープロジェクトを開きます。 プロジェクト概要ページからプロジェクトロール ARN をコピーします。 この実行ロールのポリシーを変更する必要があります。詳細な手順は後述します。 オプション 1 の IAM ベースドメインプロジェクトの設定 既存の IDC ベースドメインの権限と統合する IAM ベースドメインプロジェクトを作成するには、以下の手順を実行します。 IAM ベースドメインの管理者として AWS コンソールにログインします。 コンソール内の Amazon SageMaker ページに移動します。 [Open] を選択します。 IAM ベースドメインに管理者としてログインしたら、[Manage projects] を選択します。 次に、[Create project] をクリックします。 プロジェクト名に「Marketing Consumer Project」と入力します。 プロジェクト作成時に、以下のロールを選択して [Create Project] を選択します。 プロジェクト IAM ロール : 上記の IAM Identity Center で作成した marketing フェデレーテッドロール。メンバーアカウント内のロール名のサフィックスが AWSReservedSSO のロールです。 プロジェクトロール : オプション 1 でコピーしたデータエンジニア用のプロジェクトロールを選択します。 SageMaker Unified Studio UI ページの指示に従って、このプロジェクトロールに ポリシー 変更を行います。 オプション 2 – 独自の実行ロールを持ち込む 既存の IDC ベースドメインの権限と統合する IAM ベースドメインプロジェクトを作成するには、権限の伝播のために実行ロールにタグを付ける必要があります。Amazon SageMaker Catalog と AWS Lake Formation は属性ベースのアクセス制御を使用しており、リソースタグに基づいて権限を継承できます。オプション 2 では、コンシューマープロジェクト ID が必要です。IDC ベースドメインのコンシューマープロジェクト ID を確認するには: Amazon SageMaker Unified Studio IDC ベースドメインポータルに移動します。 Marketing コンシューマープロジェクトを開きます。 プロジェクト詳細からプロジェクト ID をコピーします。 オプション 2 の IAM ベースドメインプロジェクトの設定 以下の手順を実行します。 管理者としてログインした状態で、IAM ベースドメインに「Marketing Consumer Project 2」という名前の別のプロジェクトを作成します。 プロジェクト作成時に、以下のロールを選択します。 フェデレーテッドロール : 上記の IAM Identity Center で作成した marketing フェデレーテッドロール。 実行ロール : オプション 2 の実行ロールを選択します。 指示に従って、この実行ロールにポリシー変更を行います。 次に、IAM コンソールに移動し、IAM ベースドメインのコンシューマープロジェクト用に作成した実行ロールを見つけます。 以下のタグを追加します。タグの追加は、サブスクリプションの projectId を使用した ABAC ポリシーに依存しています。 Key : AmazonDatazoneProject Value : Amazon SageMaker Unified Studio IDC ベースドメインのコンシューマープロジェクトのプロジェクト ID タグを設定すると、IDC ベースドメインのコンシューマープロジェクトから IAM ベースドメインプロジェクトの実行ロールへのデータアクセス権限が付与されます。 IAM ベースドメインでのデータアクセスの検証 実行ロールにタグを付けた後、権限が正しく設定されていることを確認します。以下の手順を実行します。 SSO URL を使用して、Sarah として SSO Identity Center にログインします。 フェデレーテッドロールの設定セクションで作成したフェデレーテッドロールを使用して AWS コンソールを開きます。 Amazon SageMaker に移動します。 Amazon SageMaker Unified Studio IAM ベースドメインオプションを選択します (フェデレーテッドロールでプロジェクトが既に作成されている場合に表示されます)。 Amazon SageMaker Unified Studio IAM ベースドメインプロジェクトで、[Data] タブに移動します。オプション 1 とオプション 2 の両方の実行ロールで 2 つのプロジェクトを作成した場合、2 つのプロジェクトが表示され、どちらにもログインしてデータアクセスを検証できます。 コンシューマーデータベースとサブスクライブ済みテーブルが表示されることを確認します。 新しいサーバーレス Notebook の作成と使用 権限が正しく設定されたら、IAM ベースドメインのサーバーレス Notebook などの機能を使用できます。以下の手順を実行します。 Amazon SageMaker Unified Studio IAM ベースドメインプロジェクトで、[Data] タブからテーブルを選択します。 [Create notebook] を選択します。 Notebook が Athena SQL をデフォルトのセルタイプとして開きます。 サブスクライブ済みデータに対してクエリを記述して実行します。 Notebook は実行ロールの権限で動作し、IDC ベースドメインでサブスクライブしたすべてのデータにアクセスできます。 この統合の主なメリット この統合には次のメリットがあります。 既存の投資を活用 IDC ベースドメインのガバナンスとカタログを引き続き使用できる 確立された Pub/Sub ワークフローを維持できる 既存のデータアセットの移行が不要 最新の機能を利用 開発者に新しいサーバーレス Notebook を提供 高度な分析のための Athena Spark にアクセス ユーザーエクスペリエンスとナビゲーションが向上 権限管理の簡素化 単一のサブスクリプションワークフローで両方のドメインのアクセスを管理 ロールの再利用と属性ベースのアクセス制御による一貫したデータアクセス 重複するアクセスリクエストや承認が不要 統一されたデータ体験 開発者が 1 つのインターフェースからすべてのサブスクライブ済みデータにアクセス ドメイン間で一貫したデータカタログ 新しいチームメンバーのオンボーディングを簡素化 クリーンアップ 作成したリソースを削除するには、以下の手順を実行します。 IAM ベースドメインプロジェクトで作成したサーバーレス Notebook を削除します。 IAM ベースドメインプロジェクト (Marketing Consumer Project と Marketing Consumer Project 2) を削除します。 IAM Identity Center で marketing グループからアクセス許可セットの割り当てを削除します。 IAM Identity Center で Marketing-federated-role アクセス許可セットを削除します。 実行ロールからタグ (AmazonDatazoneProject) を削除します (オプション 2 を使用した場合)。 IAM ベースドメイン用に作成した実行ロールを削除します (オプション 2 を使用し、IDC ベースドメインのプロジェクトロールを再利用していない場合)。 IDC ベースドメインのコンシューマープロジェクト IAM ロールに加えたポリシー変更を元に戻します (オプション 1 を使用した場合)。 IAM ベースドメインが不要になった場合は、削除します。 IDC ベースドメインでテスト用のデータサブスクリプションを作成した場合は、削除します。 まとめ 本記事では、ロールの再利用と属性ベースのアクセス制御を使って、Amazon SageMaker Unified Studio の IDC ベースドメインと新しい IAM ベースドメインを連携させる方法を紹介しました。この構成により、データエンジニアは両方のメリットを享受できます。新しいサーバーレス Notebook、Athena Spark 統合、組み込みの AI アシスタントなどの最新開発ツールにアクセスしながら、IDC ベースドメインで確立されたカタログ管理とセキュリティ制御によるガバナンスを維持できます。既存のデータガバナンス、サブスクリプションワークフロー、アクセス制御はそのまま機能するため、Amazon SageMaker Unified Studio IAM ベースドメインを安心して導入できます。 Amazon SageMaker Unified Studio で、ガバナンスと最新の開発ツールを組織で活用してみませんか？詳細は Amazon SageMaker Unified Studio のドキュメントをご覧ください。 著者について Praveen Kumar Praveen は、AWS のプリンシパルアナリティクスソリューションアーキテクトです。クラウドベースのサービスを使用した最新のデータおよび分析プラットフォームの設計、構築、実装を専門としています。サーバーレステクノロジー、データガバナンス、データドリブン AI アプリケーションに関心があります。 Durga Mishra Durga は、AWS のプリンシパルデータ & AI ソリューションアーキテクチャストラテジストです。仕事以外では、新しいものを作ることや家族と過ごすことを楽しんでいます。アパラチアントレイルでのハイキングや自然の中で過ごすことが好きです。 Joel Farvault Joel は、AWS のプリンシパルスペシャリスト SA (アナリティクス) です。エンタープライズアーキテクチャ、データガバナンス、アナリティクスの分野で 25 年の経験があります。その経験を活かして、お客様のデータ戦略とテクノロジー基盤についてアドバイスしています。 Satish Sarapuri Satish は、AWS のシニアデータアーキテクト (Data Mesh/Data Lake/Gen AI) です。エンタープライズレベルのお客様が AWS 上で生成 AI、データメッシュ、データレイク、分析プラットフォームソリューションを構築し、データドリブンな意思決定とビジネスへのインパクトを実現できるよう支援しています。余暇にはトレイルランニングや家族との時間を楽しんでいます。 Leonardo Gomez Leonardo は、AWS のプリンシパルアナリティクススペシャリストソリューションアーキテクトです。データ管理の分野で 10 年以上の経験があり、世界中のお客様のビジネスおよび技術ニーズに対応しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 02 月 09 日 に公開された “Simplify cross-account stream processing with AWS Lambda and Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/simplify-cross-account-stream-processing-with-aws-lambda-and-amazon-dynamodb/ 組織は、セキュリティと分離のためにマルチアカウントアーキテクチャを使用することがよくあります。しかし、 Amazon DynamoDB テーブルが 1 つのアカウントにある場合、そのストリームイベントを別のアカウントで処理する必要があるかもしれません。最近まで、これは Amazon Kinesis Data Streams を経由するか、クロスアカウント AWS Identity and Access Management (IAM) ロールを使用したカスタムリレーインフラストラクチャを構築することを意味し、不要な複雑さが追加されていました。 Amazon DynamoDB Streams の リソースベースポリシー により、これらの回避策を避けることができるようになりました。 AWS Lambda 関数は、カスタムインフラストラクチャを必要とせずに、アカウント間でストリームを直接消費できます。 DynamoDB は、サーバーレスでフルマネージドな分散 NoSQL データベースであり、大規模環境でも 1 桁ミリ秒のパフォーマンスを実現します。インフラストラクチャを管理することなく、最新の高性能アプリケーションを構築できます。その主要な機能の 1 つが DynamoDB Streams で、ほぼリアルタイムでデータの変更をキャプチャします。この機能は、監査ログ、検索インデックス作成、クロスリージョンレプリケーション、異常検出、リアルタイム分析などのユースケースをサポートします。 Lambda は、サーバーのプロビジョニングや管理なしでコードを実行できるサーバーレスコンピューティングサービスです。Lambda は DynamoDB Streams と統合されているため、テーブルの更新に応じて関数を自動的にトリガーできます。この統合は、データレプリケーション、マテリアライズドビュー、分析パイプライン、イベント駆動型アーキテクチャなどのユースケースに役立ちます。 この記事では、DynamoDB Streams でリソースベースポリシーを使用して、クロスアカウント Lambda 消費を有効にする方法を探ります。アプリケーションワークロードが分離されたアカウントに存在し、ストリーム処理が集中化されたアカウントまたは分析アカウントで行われる一般的なパターンに焦点を当てます。 DynamoDB Streams を使用したクロスアカウント Lambda のメリット DynamoDB Streams のリソースベースポリシーを使用すると、ある AWS アカウントの Lambda 関数に、別のアカウントの DynamoDB ストリームから読み取る直接アクセスを許可できます。カスタムリレーインフラストラクチャは必要ありません。 この機能により、マルチアカウントイベント駆動型アーキテクチャを簡素化し、セキュリティを向上させ、運用負担を軽減できます。Lambda は、同じアカウントの イベントソースマッピング と同様に、取り込み、フィルタリング、配信、再試行、エラー処理を管理します。 SaaS サービスを運用している場合、集中化された分析パイプラインを実行している場合、または開発、ステージング、本番環境用に分離された環境を管理している場合など、別の AWS アカウントで DynamoDB ストリームイベントを処理したい理由はたくさんあります。DynamoDB Streams のリソースベースポリシーサポートにより、強力なアクセス制御を維持しながら、これらのパターンを簡単に実装できます。 この機能により、いくつかのアーキテクチャパターンが可能になります。 集中データ処理 – 複数のアプリケーションアカウントからのストリームを、Lambda 関数が集約、変換、データウェアハウスへのロードを実行する中央分析またはデータレイクアカウントにルーティングします。 共有サービス – 組織全体のテーブルからストリームを消費する、専用アカウントで再利用可能な監査ログ、コンプライアンス監視、または通知サービスを構築します。 マルチテナントアーキテクチャ – 分離されたアカウント内のテナント固有の Lambda 関数が、集中化された DynamoDB テーブルからデータを処理できるようにし、イベント駆動型ワークフローをサポートしながらセキュリティ境界を維持します。 ソリューションの概要 クロスアカウントアクセスモデルは、2 つのコンポーネントを使用します。 DynamoDB ストリームのリソースベースポリシー（ソースアカウント内） – 消費アカウント内の Lambda 実行ロールに権限を付与します IAM 実行ロール（消費アカウント内） – Lambda 関数がストリームから読み取ることを許可します Lambda 関数とクロスアカウント DynamoDB ストリーム間のイベントソースマッピングを構成すると、ストリームのリソースポリシーと Lambda 関数の実行ロールの組み合わせた権限を使用してアクセスが許可されます。ストリームのリソースベースポリシーは Lambda 実行ロールを承認し、実行ロールはストリームレコードの読み取りと処理に必要な特定の権限を提供します。 これがどのように機能するかを説明するために、企業顧客にドキュメント処理サービスを提供する SaaS プロバイダーを考えてみましょう。各顧客は、分離とセキュリティの向上のために専用の AWS アカウントで運用されています。ドキュメントが処理されると、テナントは DynamoDB Streams が有効になっている DynamoDB テーブルにレコードを書き込みます。SaaS サービスチームは、請求と分析のために、これらのレコードを中央 AWS アカウントに集約したいと考えています。クロスアカウント Lambda と DynamoDB Streams を使用すると、この統合は簡単でフルマネージドになります。 次の図は、アーキテクチャを示しています。 この記事では、アカウント B のテーブルからの DynamoDB ストリームイベントを処理するために、アカウント A に Lambda 関数を設定します。最初に Lambda 実行ロールを作成し、次にストリームを使用して DynamoDB テーブルを設定し、クロスアカウント権限を構成し、最後にイベントソースマッピングでそれらを接続します。 次のコマンドは、変数を使用してセットアップを再利用可能にし、ステップ間での Amazon リソースネーム (ARN) の手動コピーを削減します。 前提条件 このソリューションをデプロイするには、2 つの AWS アカウントと必要なリソースを作成する権限が必要です。このソリューションは AWS コマンドラインインターフェイス (CLI) を使用します。これは これらの手順 を使用してインストールできます。 変数の定義 次のコードを使用して変数を定義します。 # AWS Region REGION=us-east-1 # Resource names TABLE_NAME=Orders ROLE_NAME=CrossAccountStreamProcessor FUNCTION_NAME=ProcessOrders アカウント A で Lambda 実行ロールを作成 アカウント A で、Lambda 実行ロールとして機能する IAM ロールを作成します。 ROLE_ARN="$(aws iam create-role \ --role-name "$ROLE_NAME" \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole" }] }' \ --query 'Role.Arn' \ --output text)" aws iam attach-role-policy \ --role-name "$ROLE_NAME" \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole echo "Role ARN: $ROLE_ARN" アカウント A で Lambda 関数を作成 Lambda 関数コードを作成します。 cat > index.py << 'EOF' import json def handler(event, context): print(json.dumps(event, indent=2)) return {'statusCode': 200} EOF コードをパッケージ化します。 zip function.zip index.py Lambda 関数を作成します。 aws lambda create-function \ --function-name "$FUNCTION_NAME" \ --runtime python3.12 \ --role "$ROLE_ARN" \ --handler index.handler \ --zip-file fileb://function.zip \ --region "$REGION" アカウント B でストリームを使用した DynamoDB テーブルを作成 アカウント B で、ストリームが有効になっている DynamoDB テーブルを作成します。 STREAM_ARN="$(aws dynamodb create-table \ --table-name "$TABLE_NAME" \ --attribute-definitions AttributeName=OrderId,AttributeType=S \ --key-schema AttributeName=OrderId,KeyType=HASH \ --billing-mode PAY_PER_REQUEST \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region "$REGION" \ --query 'TableDescription.LatestStreamArn' \ --output text)" echo "Stream ARN: $STREAM_ARN" アカウント B でストリームにリソースベースポリシーをアタッチ アカウント B で、DynamoDB ストリームにリソースベースポリシーをアタッチします。まず、JSON ポリシーを作成します。 cat > stream-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCrossAccountStreamAccess", "Effect": "Allow", "Principal": { "AWS": "$ROLE_ARN" }, "Action": [ "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:GetShardIterator" ], "Resource": "*" } ] } EOF 次に、ポリシーを適用します。 aws dynamodb put-resource-policy \ --resource-arn "$STREAM_ARN" \ --policy file://stream-policy.json \ --region "$REGION" アカウント A でイベントソースマッピングを作成 アカウント A で、Lambda 関数とクロスアカウントストリーム間のイベントソースマッピングを作成します。 aws lambda create-event-source-mapping \ --function-name "$FUNCTION_NAME" \ --event-source-arn "$STREAM_ARN" \ --starting-position LATEST \ --region "$REGION" 考慮事項 このソリューションをデプロイする際は、以下の点に留意してください。 DynamoDB テーブルと Lambda 関数の両方が同じ AWS リージョンにある必要があります 標準の DynamoDB Streams および Lambda の料金が適用されます。クロスアカウントアクセスに対する追加料金はありません ストリームのリソースベースポリシーは、きめ細かいアクセス制御のためにプリンシパルとして Lambda 実行ロール ARN を使用します ストリームのリソースベースポリシーは、条件やポリシー変数を含む標準の IAM ポリシー機能をサポートします ポリシーに次の必須アクションを含めるようにしてください： dynamodb:DescribeStream 、 dynamodb:GetRecords 、 dynamodb:GetShardIterator この機能は、ストリームが有効になっている新規および既存の DynamoDB テーブルの両方で機能します この機能は Amazon マネージドキー をサポートしていません クリーンアップ 今後の料金の発生を避けるために、このウォークスルーで作成したリソースを削除します。 アカウント A で、作成したリソースを削除します。 aws lambda list-event-source-mappings \ --function-name "$ProcessOrders" \ --region "$REGION" aws lambda delete-event-source-mapping \ --uuid <UUID-from-previous-command> \ --region "$REGION" Lambda 関数を削除します。 aws lambda delete-function \ --function-name "$ProcessOrders" \ --region "$REGION" IAM ロールを削除します。 aws iam detach-role-policy \ --role-name "$ROLE_NAME" \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole aws iam delete-role \ --role-name "$ROLE_NAME" アカウント B で、DynamoDB テーブルを削除します。 aws dynamodb delete-table \ --table-name "$TABLE_NAME" まとめ DynamoDB Streams のリソースベースポリシーサポートにより、AWS アカウント境界を越えてイベント駆動型システムを構築する強力な新しい方法が提供されます。この機能により、カスタム統合ロジックを記述することなく、安全でスケーラブルなパイプラインを作成できます。このソリューションは、SaaS サービスを実行している場合、ログを統合している場合、または変更データを集中的に処理している場合に役立ちます。 Lambda を使用した DynamoDB Streams は、リアルタイムストリーム処理のためのマネージドで信頼性の高いパスを提供します。今すぐ クロスアカウント Lambda と DynamoDB Streams を使用して構築を開始し、イベント駆動型アーキテクチャを簡素化しましょう。 著者について Lee Hannigan Lee は、アイルランドのドニゴールを拠点とする Amazon DynamoDB シニアデータベースエンジニアです。彼は、ビッグデータと分析技術の強固な基盤を持つ分散システムの豊富な専門知識をもたらします。彼の役割では、Lee は DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に焦点を当てながら、顧客と社内チームがその機能を最大限に活用できるよう支援しています。

Amazon DynamoDB のグローバルセカンダリインデックス (Global Secondary Index、GSI) のキャパシティを Terraform の外部で調整したことがある方なら、Terraform がドリフトを検出して望ましくない復元を強制する様子をご存知でしょう。Terraform の新しい aws_dynamodb_global_secondary_index リソースを使用すれば、この問題に対処できます。 新しい aws_dynamodb_global_secondary_index リソースは、各 GSI を独自のライフサイクル管理を持つ独立したリソースとして扱います。この機能を使用して、Terraform の外部で GSI とテーブルのキャパシティ調整を行うことができます。 この記事では、Terraform の新しい aws_dynamodb_global_secondary_index リソースを使用して、GSI のドリフトを選択的に管理する方法を実演します。現在のアプローチの制限事項を説明し、ソリューションの実装方法をガイドします。 問題: Terraform のドリフトと GSI 管理 ソリューションに入る前に、インフラストラクチャ管理における ドリフト の意味を確認しましょう。Infrastructure as Code (IaC) において、ドリフトは、インフラストラクチャの実際の状態が Terraform 設定で定義されている内容と異なる場合に発生します。Terraform は、望ましい状態（ .tf 設定ファイル）、最後に既知の状態（ terraform.tfstate に保存）、実際の状態（AWS からクエリ）を比較することでドリフトを検出します。これらが一致しない場合、Terraform はドリフトを報告し、差異を調整するための変更を提案します。 DynamoDB の GSI は、さまざまな運用上の理由でキャパシティ調整が必要になることがよくあります。負荷テスト、キャパシティプランニング、緊急のパフォーマンス要件、またはウォームスループットの管理などです。DynamoDB のキャパシティは、オートスケーリングイベントによっても変更される可能性があります。Terraform の外部でこれらの変更を行うたびに、Terraform の設定と AWS の実態との間にドリフトが発生します。 例えば、分析チームが GSI に対して大量のクエリを実行する日次レポートを実行しているとします。レポートは午前 2 時に実行され、50 リードキャパシティユニット (Read Capacity Units、RCU) が必要ですが、通常時間帯は 5 RCU で十分です。運用チームは、負荷に対応するためにレポート実行前に手動でキャパシティを増やします。 午前 1 時 50 分に、運用チームは AWS コマンドラインインターフェイス (AWS CLI) を使用してキャパシティを 5 から 50 に増やします。レポートは午前 2 時から 3 時まで高いキャパシティで実行されます。その日の後半、無関係な変更をデプロイするために terraform plan を実行すると、実際のキャパシティ (50) が設定 (5) と一致しないため、Terraform はドリフトを検出します。Terraform はキャパシティを 5 に戻そうとしますが、これは運用上のキャパシティ管理に干渉することになります。 一般的な回避策とその制限事項 一般的な回避策は、テーブルのライフサイクルブロックで ignore_changes = [global_secondary_index] を使用することです。これにより、Terraform がキャパシティのドリフトを検出しなくなります。ただし、このアプローチは範囲が広すぎます。キャパシティだけでなく、すべての GSI の変更を無視します。 global_secondary_index は複雑なネストされた型であるため、 ignore_changes はトップレベルでのみ機能し、個々の属性では機能しません。誰かが誤って GSI を削除したり、キースキーマを変更したりしても、Terraform は検出しません。意図的なキャパシティチューニングと偶発的な GSI の削除を区別できません。 ソリューション: 個別の GSI リソース 新しい aws_dynamodb_global_secondary_index リソースは、各 GSI を独自のライフサイクル管理を持つ独立したリソースとして扱います。これにより、各 GSI に対してどの属性を無視するかをきめ細かく制御できると同時に、削除やスキーマ変更などの重要な変更を検出できます。 前提条件 開始する前に、以下があることを確認してください。 DynamoDB テーブルを作成および管理する権限を持つ AWS アカウント（例で使用するテストリソースを作成するために必要） DynamoDB 権限を持つ AWS Identity and Access Management (IAM) ロールを使用して Amazon Linux を実行している Amazon Elastic Compute Cloud (Amazon EC2) インスタンス AWS コマンドラインインターフェイス (AWS CLI) がインストールおよび設定されていること AWS Terraform Provider バージョン 6.28.0 以降（ aws_dynamodb_global_secondary_index リソースは v6.28.0 で導入されました） aws_dynamodb_global_secondary_index リソースは、現在 Terraform AWS プロバイダー で 実験的 としてマークされています。これは、スキーマや動作が予告なく変更される可能性があり、プロバイダーの下位互換性保証の対象ではないことを意味します。 この実験的リソースを有効にするには、環境変数 TF_AWS_EXPERIMENT_dynamodb_global_secondary_index を設定する必要があります。この環境変数がないと、 aws_dynamodb_global_secondary_index を使用しようとしたときに Terraform がエラーを返します。Terraform コマンドを実行する前に設定してください。 export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 本番環境で使用する前に、非本番環境で十分にテストしてください。 GitHub Issue #45640 でフィードバックを提供することを歓迎します。 AWS Provider v5.x から v6.x にアップグレードする場合は、続行する前に v6.0.0 アップグレードガイド で破壊的変更を確認してください。 Amazon Linux に Terraform をインストール: # システムを更新 sudo yum update -y # yum-config-manager をインストール sudo yum install -y yum-utils # HashiCorp リポジトリを追加 sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo # Terraform をインストール sudo yum -y install terraform # インストールを確認 terraform --version 新しいリソースの使用 新しい個別リソース方式を使用して、2 つの GSI を持つプロビジョニングされたキャパシティテーブルを作成します。テーブルと GSI が独立したリソースとして定義される main.tf を作成します。 テーブルと GSI のキー: リソース ハッシュキー レンジキー キャパシティ Table id timestamp 5/5 StatusUserIndex status user_id 5/5 TimestampIndex timestamp – 3/3 設定: terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.28" } } } provider "aws" { region = "us-east-1" } # GSI ブロックのない DynamoDB テーブル（GSI は個別に管理） # テーブルキー（hash_key/range_key）として使用される属性のみを定義 # GSI 属性は個別の aws_dynamodb_global_secondary_index リソースで定義 resource "aws_dynamodb_table" "test_table" { name = "GSITestTable" billing_mode = "PROVISIONED" read_capacity = 5 write_capacity = 5 hash_key = "id" range_key = "timestamp" attribute { name = "id" type = "S" } attribute { name = "timestamp" type = "N" } tags = { Name = "GSITestTable" Environment = "test" Purpose = "Testing new GSI resource" } } # 個別リソースとしての GSI resource "aws_dynamodb_global_secondary_index" "status_index" { table_name = aws_dynamodb_table.test_table.name index_name = "StatusUserIndex" # プロビジョニングされたスループット設定 provisioned_throughput { read_capacity_units = 5 write_capacity_units = 5 } # key_schema に attribute_type が含まれるようになりました（新しいリソースで必須） key_schema { attribute_name = "status" attribute_type = "S" key_type = "HASH" } key_schema { attribute_name = "user_id" attribute_type = "S" key_type = "RANGE" } # プロジェクション設定 projection { projection_type = "ALL" } # 新しい個別リソースでは、GSI ごとに特定の属性を無視できるようになりました lifecycle { ignore_changes = [provisioned_throughput] } } # 複数の独立した GSI をテストするための 2 番目の GSI resource "aws_dynamodb_global_secondary_index" "timestamp_index" { table_name = aws_dynamodb_table.test_table.name index_name = "TimestampIndex" # プロビジョニングされたスループット設定 provisioned_throughput { read_capacity_units = 3 write_capacity_units = 3 } key_schema { attribute_name = "timestamp" attribute_type = "N" key_type = "HASH" } # プロジェクション設定 projection { projection_type = "KEYS_ONLY" } # この GSI は Terraform によって完全に管理されます（ignore_changes なし） } リソースをデプロイします: # 必要な環境変数を設定 export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 terraform init terraform plan terraform apply StatusUserIndex （ ignore_changes を持つもの）のキャパシティを手動で変更して、選択的な ignore_changes をテストします: aws dynamodb update-table \ --table-name GSITestTable \ --region us-east-1 \ --global-secondary-index-updates '[{ "Update": { "IndexName": "StatusUserIndex", "ProvisionedThroughput": { "ReadCapacityUnits": 10, "WriteCapacityUnits": 10 } } }]' # 更新が完了するまで待機 sleep 30 terraform plan を実行すると、 StatusUserIndex のキャパシティが AWS で 10/10 に変更されたにもかかわらず、 No changes と表示されます。これは ignore_changes = [provisioned_throughput] のために発生します。 TimestampIndex （ ignore_changes のないもの）を手動で変更して、ドリフト検出が機能することを確認します: aws dynamodb update-table \ --table-name GSITestTable \ --region us-east-1 \ --global-secondary-index-updates '[{ "Update": { "IndexName": "TimestampIndex", "ProvisionedThroughput": { "ReadCapacityUnits": 8, "WriteCapacityUnits": 8 } } }]' # 更新が完了するまで待機 sleep 30 terraform plan を実行すると、ドリフトが検出され、 TimestampIndex のキャパシティを 8 から 3 に戻すことが提案されます。これにより、以下が実証されます: StatusUserIndex は変更なし（意図したとおりキャパシティが無視される） TimestampIndex はドリフト検出（キャパシティの変更が検出される） 各 GSI は独立したライフサイクル管理を持つ GSI ごとに特定の属性を選択的に無視できる Terraform は ignore_changes のない GSI の重要な変更を検出する 従来の方法との主な違いは、テーブルがテーブル自体で使用される属性（ id 、 timestamp ）を定義するのに対し、GSI 固有の属性（ status 、 user_id ）は個別の GSI リソースの key_schema ブロックで attribute_type （新しいリソースで必須）とともに定義されることです。GSI がテーブル属性を再利用する場合、その属性はテーブルの attribute ブロックに残ります。GSI は独自のライフサイクルを持つ個別のリソースです。 新しいリソースの利点 新しいリソースモデルにはいくつかの利点があります。他の GSI に影響を与えることなく、GSI の特定の属性を無視できるようになりました。自動化されたスクリプトは、Terraform のドリフトを作成することなく、トラフィックパターンに基づいてキャパシティを調整できます。キースキーマの変更などの重要な変更を追跡し、偶発的な GSI の削除や再設定がないことを確認できます。Terraform の状態は GSI 構造の信頼できる情報源のままであり、DynamoDB API は実際のランタイムキャパシティを示します。 各 GSI は独自のライフサイクルルールを持つことができ、独立した管理が可能です。新しいリソースモデルは、各リソースが 1 つの論理インフラストラクチャコンポーネントを管理し、依存関係がリソース参照を通じて明示的であり、状態管理がより簡単になるという Terraform のベストプラクティスに従っています。 新しいリソースは、 オンデマンドテーブルのウォームスループット設定 を完全にサポートしています。ウォームスループットは、オンデマンドテーブルのベースラインキャパシティを指定するために使用できる DynamoDB の機能で、パフォーマンスとコストをより予測可能に管理するのに役立ちます。以下はテスト方法です。 ondemand.tf を作成します: resource "aws_dynamodb_table" "ondemand_test" { name = "OnDemandGSITest" billing_mode = "PAY_PER_REQUEST" hash_key = "id" attribute { name = "id" type = "S" } } resource "aws_dynamodb_global_secondary_index" "category_index" { table_name = aws_dynamodb_table.ondemand_test.name index_name = "CategoryIndex" key_schema { attribute_name = "category" attribute_type = "S" key_type = "HASH" } # プロジェクション設定 projection { projection_type = "ALL" } # ウォームスループット設定（ブロックではなく属性） warm_throughput = { read_units_per_second = 13000 write_units_per_second = 5000 } lifecycle { # 手動でのウォームスループットチューニングを許可 ignore_changes = [warm_throughput] } } デプロイしてテストします: # まだ設定されていない場合は、必要な環境変数を設定 export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 terraform apply # ウォームスループットを手動で変更 aws dynamodb update-table \ --table-name OnDemandGSITest \ --region us-east-1 \ --global-secondary-index-updates '[{ "Update": { "IndexName": "CategoryIndex", "WarmThroughput": { "ReadUnitsPerSecond": 14000, "WriteUnitsPerSecond": 5100 } } }]' # 更新を待機 sleep 30 # terraform plan を実行 terraform plan ウォームスループットの変更は期待どおり無視されるため、Terraform は No changes を表示します。 次のセクションに進む前に、オンデマンドテストリソースを破棄します: terraform destroy 移行の例 新しいリソースの動作を確認したので、既存のインフラストラクチャの完全な実践的な移行を見ていきましょう。従来のネストされた GSI アプローチを使用するテーブルから始めて、ダウンタイムなしで新しい個別リソース方式に移行します。 ステップ 1: 従来の方法でインフラストラクチャを作成 従来のネストされたブロックアプローチを使用して、GSI を持つ DynamoDB テーブルを作成します。 migration-old.tf というファイルを作成します: terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.28" } } } provider "aws" { region = "us-east-1" } # 従来のアプローチ: GSI がネストされたブロックとして定義 resource "aws_dynamodb_table" "products" { name = "ProductsTable" billing_mode = "PROVISIONED" read_capacity = 5 write_capacity = 5 hash_key = "ProductId" attribute { name = "ProductId" type = "S" } attribute { name = "Category" type = "S" } # GSI がネストされたブロックとして定義（従来の方法） global_secondary_index { name = "CategoryIndex" hash_key = "Category" projection_type = "ALL" read_capacity = 3 write_capacity = 3 } tags = { Name = "ProductsTable" Environment = "migration-demo" } } このインフラストラクチャをデプロイします: terraform init terraform plan terraform apply テーブルと GSI が作成されたことを確認します: aws dynamodb describe-table --table-name ProductsTable --region us-east-1 \ --query 'Table.GlobalSecondaryIndexes[0].IndexName' 出力: CategoryIndex ステップ 2: 移行の準備 移行する前に、Terraform の状態をバックアップします: terraform state pull > backup-before-migration.tfstate 必要な環境変数を設定します: export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 ステップ 3: Terraform 設定を更新 更新された設定で migration-new.tf という新しいファイルを作成します。今のところ両方のファイルを保持します。インポート後に古いファイルを削除します。 terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.28" } } } provider "aws" { region = "us-east-1" } # 更新されたテーブル: GSI ブロックを削除 resource "aws_dynamodb_table" "products" { name = "ProductsTable" billing_mode = "PROVISIONED" read_capacity = 5 write_capacity = 5 hash_key = "ProductId" # テーブル自身のキーで使用される属性のみを定義 attribute { name = "ProductId" type = "S" } tags = { Name = "ProductsTable" Environment = "migration-demo" } } # 新規: 個別リソースとしての GSI resource "aws_dynamodb_global_secondary_index" "category_index" { table_name = aws_dynamodb_table.products.name index_name = "CategoryIndex" # プロビジョニングされたスループット設定 provisioned_throughput { read_capacity_units = 3 write_capacity_units = 3 } key_schema { attribute_name = "Category" attribute_type = "S" key_type = "HASH" } # プロジェクション設定 projection { projection_type = "ALL" } # 運用チームが Terraform による復元なしでキャパシティを調整できるようにする lifecycle { ignore_changes = [provisioned_throughput] } } ステップ 4: 古い設定を削除 古いファイルを削除または名前変更します: mv migration-old.tf migration-old.tf.backup この時点で terraform plan を実行すると、Terraform がテーブルから GSI を削除し（ネストされたブロックがなくなったため）、新しい個別の GSI リソースを作成しようとすることがわかります。 まだ適用しないでください。 これによりダウンタイムが発生します。代わりに、既存の GSI をインポートします。 ステップ 5: 既存の GSI をインポート 既存の GSI を新しいリソースの状態にインポートします: # インポート形式: 'table_name,index_name' terraform import aws_dynamodb_global_secondary_index.category_index \ 'ProductsTable,CategoryIndex' 出力: aws_dynamodb_global_secondary_index.category_index: Importing from ID "ProductsTable,CategoryIndex"... aws_dynamodb_global_secondary_index.category_index: Import prepared! Prepared aws_dynamodb_global_secondary_index for import aws_dynamodb_global_secondary_index.category_index: Refreshing state... [id=ProductsTable,CategoryIndex] Import successful! ステップ 6: 移行を確認 terraform plan を実行して確認します: terraform plan 期待される出力: aws_dynamodb_table.products: Refreshing state... [id=ProductsTable] aws_dynamodb_global_secondary_index.category_index: Refreshing state... [id=ProductsTable,CategoryIndex] No changes. Your infrastructure matches the configuration. No changes と表示された場合、移行は成功しています。GSI は個別のリソースとして管理されるようになりました。 移行の概要 移行を完了するには、従来のネストされた GSI 設定から始め、 terraform import を使用してダウンタイムなしで個別の GSI リソースに移行しました。その後、 terraform plan で No changes が表示されることで移行を確認し、新しいリソースモデルへの移行に成功しました。 重要なポイント: 移行には terraform import を使用 AWS リソースは変更または再作成されない GSI は移行中も存在し続け、ダウンタイムはゼロ 移行後、 ignore_changes で無視する内容をきめ細かく制御できる 移行プロセスは安全で元に戻すことができる 移行に関する考慮事項 aws_dynamodb_global_secondary_index リソースを aws_dynamodb_table の global_secondary_index ブロックと組み合わせないでください。そうすると、競合、永続的な差異、GSI の上書きが発生する可能性があります。 移行する際は、以下の手順に従ってください: 状態をバックアップ : terraform state pull > backup.tfstate 環境変数を設定 : export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 設定を更新 : テーブルから GSI ブロックを削除し、新しい GSI リソースを作成 既存の GSI をインポート : terraform import <resource> 'table_name,index_name' 確認 : terraform plan を実行し、 No changes と表示されることを確認 テスト : キャパシティを手動で変更し、Terraform が変更を無視することを確認 terraform import を使用して正しく行えば、移行中にダウンタイムは発生しません。GSI は移行中も AWS に存在し続けます。 terraform import コマンドは Terraform の状態ファイルのみを更新し、AWS リソースは変更しません。 テーブルに複数の GSI がある場合は、一度に 1 つずつ移行します: 最初の GSI をインポートし、 terraform plan で確認 2 番目の GSI をインポートし、 terraform plan で確認 すべての GSI が移行されるまで続ける これによりリスクが軽減され、トラブルシューティングが簡素化されます。 比較: 従来の方法と新しい方法 以下の表は、従来のネストされたブロックアプローチと新しい個別リソース方式の主な違いをまとめたものです: 側面 従来の方法（ネストされたブロック） 新しい方法（個別リソース） リソースの有効化 環境変数は不要 TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 が必要 きめ細かい ignore_changes サポートされていない サポートされている 独立した GSI 管理 すべての GSI が一緒に管理される 各 GSI が独立して管理される ドリフト検出 全部か無か GSI ごとに選択的 ライフサイクルルール すべての GSI に適用 GSI ごとのライフサイクルルール 状態管理 複雑なネストされた状態 簡単なフラットな状態 キャパシティ設定 トップレベル属性（ read_capacity 、 write_capacity ） ブロック構文（ provisioned_throughput ブロック） プロジェクション設定 トップレベル属性（ projection_type ） ブロック構文（ projection ブロック） ウォームスループットのサポート 限定的 完全サポート（属性構文: warm_throughput = { } ） 移行の複雑さ N/A インポートプロセスが必要 下位互換性 既存の方法 従来の方法と混在できない 安定性 安定 実験的（スキーマが変更される可能性あり） クリーンアップ 今後の料金の発生を避けるために、このウォークスルーで作成したリソースを削除します: # Terraform で管理されているすべてのリソースを破棄 terraform destroy # プロンプトが表示されたら削除を確認 # 続行するには 'yes' と入力 テスト中に手動で作成したリソースがある場合は、今後のコストの発生を避けるために、AWS マネジメントコンソールまたは AWS CLI を通じてそれらも削除してください。 まとめ この記事では、新しい aws_dynamodb_global_secondary_index リソースが、Terraform での DynamoDB GSI ドリフト管理という長年の課題をどのように解決するかを示しました。ネストされた global_secondary_index ブロックを無視する全部か無かの性質は、運用の柔軟性とインフラストラクチャガバナンスの間にギャップを生み出していました。 GSI をファーストクラスのリソースとして扱うことで、特定の GSI 属性に対する選択的な ignore_changes によるきめ細かい制御、各 GSI が独自のライフサイクルルールを持つ独立した管理、運用上の調整を許可しながら重要な変更を追跡するより良いドリフト検出、テーブルとインデックス設定の関心の分離によるより簡単なアーキテクチャを獲得できます。 aws_dynamodb_global_secondary_index リソースは現在 実験的 としてマークされていることを覚えておいてください。GSI ドリフトを管理するための強力な機能を提供しますが、以下の点に注意してください: スキーマや動作は将来のプロバイダーバージョンで変更される可能性がある このリソースを有効にするには、環境変数 TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 を設定する必要がある プロバイダーの下位互換性保証の対象ではない このリソースを同じテーブルの従来の global_secondary_index ブロックと混在させることはできない 常に非本番環境で十分にテストし、プロバイダーのリリースノートで更新を監視してください。フィードバックがある場合は、 GitHub Issue #45640 で提供して、この機能の将来を形作るのに役立ててください。 本記事は 2026 年 02 月 09 日 に公開された “New in Terraform: Manage global secondary index drift in Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/new-in-terraform-manage-global-secondary-index-drift-in-amazon-dynamodb/ 著者について Vaibhav Bhardwaj Vaibhav は、AWS シンガポールを拠点とするシニア DynamoDB スペシャリストソリューションアーキテクトです。19 年の経験を持つサーバーレス愛好家で、DynamoDB を使用した高性能、スケーラビリティ、信頼性を要求するアプリケーションのアーキテクチャを設計するために顧客と協力することを好みます。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 フィジカル AI 開発支援プログラム by AWS ジャパン の募集を開始しました。本プログラムは AWS 上で Vision-Language-Action (VLA) をはじめとしたロボット基盤モデル等を開発する、日本に法人または拠点を持つ企業・団体を支援するものです。データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築を支援し、AI のロボティクスへの活用を推進することを目指します。2/13 までに応募締め切りなので、我こそはという方はぜひお申込みください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年2月2日週の主要なアップデート 2/2(月) Amazon CloudFront がオリジンに対する相互 TLS サポートを発表 Amazon CloudFront が オリジンサーバーに対する相互 TLS 認証 (mTLS) をサポート開始しました。これまで CloudFront からのリクエストかどうかを検証するには、共有シークレットヘッダーや IP 許可リストなどのカスタム認証が必要でした。新機能により TLS 証明書による標準的な認証が可能になり、より簡単にセキュリティ向上が出来る機能です。詳細は こちらのドキュメントをご参照ください。 AWS Multi-party approval でワンタイムパスワード認証による投票が必要になりました AWS Organitzaions の中に含まれる AWS Multi-party approval という機能で、承認者の投票時にワンタイムパスワード (OTP) 検証が必須になりました。これまで IAM Identity Center の管理者が承認者を偽装して承認を回避できる問題がありましたが、この機能により確実に本人確認ができるようになります。投票時に 6 桁のコードがメールで送信され、10 分以内に入力することで投票が完了します。全リージョンで追加料金なしで利用可能です。 AWS STS が Google、GitHub、CircleCI、OCI からの特定のアイデンティティプロバイダー固有のクレームの検証をサポート AWS STS で Google や GitHub などの外部認証プロバイダーからの詳細情報を使った、より細かいアクセス制御が可能になりました。従来は基本的な認証情報のみでしたが、今回のアップデートでプロバイダー固有のクレーム情報を IAM ポリシーの条件として利用できるようになります。例えば GitHub のリポジトリ名や Google のドメイン情報などを条件に含めることで、セキュリティを強化しながら柔軟な権限管理が実現できます。 Amazon Lightsail でメモリ最適化インスタンスバンドルの提供開始を発表 Amazon Lightsail で最大 512 GB メモリを搭載したメモリ最適化インスタンスの提供が開始されました。従来の Lightsail では高メモリが必要なワークロードの実行が難しかった場合があり、EC2 を選択していたこともあったと思います。今回のアップデートでインメモリデータベースやリアルタイム分析など、より多くのメモリが必要なワークロードを実行しやすくなりました。7 つのサイズ (512, 384, 256, 128, 64, 32, 16 GB) から選択でき、Linux と Windows の両方に対応しています。 DeepSeek OCR、MiniMax M2.1、および Qwen3-VL-8B-Instruct モデルが SageMaker JumpStart で利用可能になりました Amazon SageMaker JumpStart で DeepSeek OCR、MiniMax M2.1、Qwen3-VL-8B-Instruct の 3 つの新しい AI モデルが利用可能になりました。DeepSeek OCR は請求書や複雑な文書から構造化された情報を抽出でき、MiniMax M2.1 は多言語でのソフトウェア開発を自動化し、Qwen3-VL-8B-Instruct は高度な視覚認識と推論機能を提供します。これらのモデルにより、文書処理から自動コーディング、画像解析まで幅広い AI アプリケーションの構築が可能になります。詳細は こちらのドキュメントをご参照ください。 2/3(火) AWS IAM Identity Center が複数の AWS リージョンでのアカウントアクセスとアプリケーション利用を可能に AWS IAM Identity Center で複数リージョンでのアカウントアクセスが可能になりました。従来はプライマリリージョンのみでの利用でしたが、今回のアップデートで追加リージョンへの複製が可能となり、リージョン障害時でも継続してアクセスできるようになります。Okta などの外部 ID プロバイダーと連携した組織で、17 の商用リージョンで利用できます。災害対策やデータ居住性要件への対応、ユーザーに近いリージョンでのアプリケーション展開など、ビジネス要件に合わせた柔軟な運用が実現できます。詳細は こちらのドキュメントをご参照ください。 AWS マネジメントコンソールのナビゲーションバーにアカウント名を表示し、アカウント識別を容易にする機能が利用可能に AWS マネジメントコンソールのナビゲーションバーにアカウント名が表示されるようになりました。従来はアカウント番号のみで識別していましたが、開発環境と本番環境など複数のアカウントを使い分けている場合でも、名前でひと目で判別できます。全パブリックリージョンで無料利用可能で、管理者が機能を有効化する必要があります。 Amazon DynamoDB グローバルテーブルが複数の AWS アカウント間でのレプリケーションをサポート Amazon DynamoDB グローバルテーブルが複数の AWS アカウント間でのデータレプリケーションに対応しました。これまでは同一アカウント内のリージョン間のみでしたが、アカウントをまたいだレプリケーションが可能になります。複数アカウント戦略を採用する組織では、セキュリティ分離やビジネス単位での管理を維持しながら、災害復旧や高可用性を実現できます。詳細は こちらのドキュメントをご参照ください。 2/4(水) Amazon EC2 と VPC でセキュリティグループの関連リソースが表示されるようになりました Amazon EC2 と VPC コンソールで、セキュリティグループの「Related resources」タブが利用可能になりました。これまでセキュリティグループを変更や削除する前に、EC2 インスタンスや RDS データベースなど複数のサービスを個別に確認する必要がありましたが、今回のアップデートで依存関係のあるリソースを一箇所で確認できるようになりました。大規模な環境でセキュリティグループが多数のリソースに紐づいている場合に特に有効で、変更の影響範囲を素早く把握できるため、作業効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock で構造化出力が利用可能になりました Amazon Bedrock で 構造化出力が利用可能になりました。これまで JSON 形式のレスポンスを得るためにプロンプトで指定し、アプリケーション側で追加チェックが必要でしたが、今回のアップデートで JSON スキーマを定義するだけで一貫性のある機械読み取り可能な応答を取得できるようになりました。API やツールを使用するワークフローで、小さなフォーマットエラーが下流システムを壊すリスクを大幅に削減し、カスタム検証ロジックの必要性を減らすことでプロダクション環境での信頼性が向上します。詳細は こちらのドキュメントをご参照ください。 2/5(木) Claude Opus 4.6 が Amazon Bedrock で利用可能になりました Amazon Bedrock で Claude Opus 4.6 が利用可能になりました。Anthropic 社の最新かつ最も高性能な AI モデルで、複雑なコーディングや企業向けタスクに優れています。200K から 1M トークンまでの長文処理が可能で、大規模なドキュメントやコードベースの分析ができます。詳細は こちらのリリース記事をご参照ください。 Amazon WorkSpaces が Graphics G6、Gr6、G6f バンドルを開始 Amazon WorkSpaces で新たに Graphics G6、Gr6、G6f バンドルが利用可能になりました。これらは GPU を活用したグラフィック集約的な作業に特化したバンドルです。CAD や 3D レンダリング、機械学習モデルの訓練など、従来の WorkSpaces では性能不足だった高負荷な作業が快適に行えるようになります。G6f バンドルでは部分的な GPU 利用も可能で、コストを抑えながら GPU 性能を活用できる点が魅力です。東京リージョンを含む 13 リージョンで提供されています。 2/6(金) AWS Network Firewall が新たな料金削減を発表 AWS Network Firewall で価格改定が実施され、コスト削減につながる 2 つの改善が行われました。従来はプライマリエンドポイントのみ対象だった NAT Gateway 割引が、セカンダリエンドポイントでも適用されるようになり、複数 VPC を保護する際の運用コストを削減できます。また、暗号化通信を検査する Advanced Inspection 機能の追加データ処理料金 (最大 0.009/GB) が廃止され、TLS インスペクションをより低コストで実装可能になりました。詳細は こちらの料金ページをご参照ください。 Amazon Bedrock AgentCore Browser がブラウザプロファイルをサポート開始 Amazon Bedrock AgentCore Browser でブラウザプロファイル機能がサポートされました。これにより、一度ログインした認証状態を複数のブラウザーセッション間で再利用でき、これまで毎回ログインが必要だった作業が軽減できます。企業での大量自動化処理において、セッション開始時間が数分から数十秒に短縮される大きなメリットがあります。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

CO2 排出量可視・削減サービス「e-dash」化を支えるサーバーレスアーキテクチャと IaC 戦略 こんにちは、AWS ソリューションアーキテクトの松本 敢大です。 本日は、三井物産発の環境系スタートアップである e-dash 株式会社様が提供する CO2 排出量可視化・削減サービスプラットフォーム「e-dash」のシステム構築事例をご紹介します。e-dash 株式会社 プロダクト開発部部長の佐藤様、プロダクト開発部の伊藤様、竹内様に、AWS を活用したモダンなアプリケーション開発の取り組みについてお話を伺いました。 e-dash 株式会社について e-dash 株式会社は、「脱炭素を加速する」をサービスミッションとして掲げ、CO2 排出量の現状把握・報告・削減を一気通貫で行うサービスプラットフォーム「e-dash」を開発・運営しています。手間なく正確に CO2 排出量の可視化が叶うクラウドサービスと伴走型のコンサルティングサービスを組み合わせ、企業や自治体の CO2 排出量削減への取り組みを総合的に支援しています。また、サプライチェーンにわたり脱炭素の対話を持つための「e-dash Survey」や、製造した製品自体の環境負荷を算出する「e-dash CFP」も提供し、幅広い脱炭素経営のニーズに応えています。 「e-dash」サービスの特徴 AWS: まず 、 「e-dash」のサービス概要について教えていただけますか? e-dash 佐藤: 「e-dash」は、企業が電気や都市ガスなどのエネルギー使用量の請求書をアップロードするだけで、その使用量が自動的にデータ化され、グラフ形式で CO2 排出量が計算されるサービスです。従来の CO2 排出量管理サービスでは、エネルギー使用量を手動で入力する必要がありましたが、 「e-dash」では請求書をアップロードするだけで自動的にデータ化されるため、入力作業の負担を大幅に削減しながら、請求書を証票とした正確なデータ蓄積ができます。可視化も削減も専門家がお客さまに伴走しながら、継続的に成果を生み出す改善プロセスを構築します。また環境省が公表する排出係数を自社データベースに取り込み、当該係数に基づいた正確な CO2 排出量算定を行っています。 AWS: カーボンフットプリント（CFP）への対応状況について教えてください。 e-dash 佐藤: 「e-dash CFP」という製品を提供しています。製品・サービスのライフサイクル全体で発生する排出量を可視 化できます。原材料調達から製造、流通、廃棄まで、多岐にわたる工程を一元的に管理できるため、企業の脱炭素戦略における基盤として活用いただけます。 AWS: Scope 3 の算定は可能ですか？ e-dash 佐藤: 可能です。「e-dash」は Scope 1・2 はもちろん、Scope 3 も網羅的に算定できる設計になっています。環境省・経済産業省のガイドラインに準拠した算定ロジックを採用しており、サプライチェーン全体の排出量を正確に把握できます。 AWS: 省エネ法報告機能について教えてください。 e-dash 佐藤: 省エネ法については、「e-dash」で収集・算定したデータをそのまま報告に活用できる仕組みを提供しています。必要な数値を自動で整理できるため、これまで煩雑だった報告作業の負担を大幅に軽減できます。 AWS を活用したシステムアーキテクチャ AWS: システム構築の背景について教えていただけますか? e-dash 伊藤・竹内: スタートアップとして短期間で本番稼働が求められるなか、 外部委託から内製化へと移行 し、 制度改正や機能追加 への即応性を高める必要がありました。2024 年 4 月にリリースした「e-dash」は、それまで運用していたシステムを全面リプレイスしたもので、約 12 ヶ月の開発期間をかけて 10 名体制で再構築しました。現在は 3 名で運用を行っており、新規サービスや 追加機能の開発についても、通常 2 週間程度で完了 できる体制を構築しています。 AWS: インフラは基本的に AWS で構築されているとのことですが、その理由を教えていただけますか? e-dash 伊藤・竹内: AWS を選択した理由は大きく 3 つあります。 第一に、情報量の豊富 さです。AWS は情報の数が多いので、トラブルが起きても簡単に解決できます。ドキュメントやコ ミュニティの情報が充実しているため、問題解決のスピードが速いです。 第二に、チームの経験 です。私たちのチームメンバーも AWS を使った構築経験が豊富で、使い慣れたサービスを活用できることは大きなメリットでした。 第三に、サポートの質の高さ です。他のクラウドベンダーとは異なり、AWS のサポートは非常にレベルが高いと感じています。単純な調査だけでなく、私たちの目線で支援していただいていると実感しています。また、コミュニティ活動が盛んで、他社の AWS ユーザーと情報交換しやすい環境も魅力です。 サーバーレスを基本としたアーキテクチャ設計 AWS: 具体的なアーキテクチャについて教えていただけますか? e-dash 伊藤・竹内: 「e-dash」のインフラは基本的に AWS で構築しています。スタートアップとして限られた人数で運用する必要があるため、 フルマネージドサービスを積極的に採用 し、インフラ管理の負担を最小限に抑えています。アーキテクチャの基本は Amazon ECS on Fargate と Amazon Aurora を利用しています。フロントエンドとバックエンドのアプリケーション実行基盤として ECS on Fargate を採用しています。CSV のエクスポート処理などは AWS Batch 、アップロード処理は AWS Lambda を利用しています。 AWS: データベースの使い分けについて、もう少し詳しく教えていただけますか? e-dash 伊藤・竹内: はい。 Amazon Aurora は、フルマネージドサービスとしての運用性の高さと、フェイルオーバー機能による高可用性を評価して採用 しました。本番環境ではライターとリーダーのマルチ AZ 構成でフェイルオーバーを実現しています。管理負荷が低いので基本的にフルマネージドサービスを使うようにしています。 Amazon DynamoDB は企業名管理など、単純な構造のデータ管理に活用しています。高いパフォーマンスが求められないサービスでも、可用性の高さおよびコストの安さから特定のマスタデータ管理に利用しています。 Amazon ElastiCache は、分単位で更新が必要なリアルタイム性の高いサービスで活用しています。揮発しても問題ない一時的な計算データを格納し、パフォーマンスの最適化を図っています。 AWS: イベント駆動アーキテクチャについても教えていただけますか? e-dash 伊藤・竹内: 請求書処理フローでは、イベント駆動アーキテクチャを採用しています。Amazon ECS on Fargate から Amazon S3 へ請求書データがアップロードされると、S3 イベント通知をトリガーとして AWS Lambda が起動し、OCR 処理へと連携します。 開発速度を支える IaC 戦略 AWS: 開発速度を向上させるための工夫について教えていただけますか? e-dash 伊藤・竹内: 私たちは、 Infrastructure as Code (IaC) を徹底的に推進 しています。 AWS Organizations 、 AWS Identity Center を含むすべての AWS リソースを Terraform で管理し、モジュールの共有により新規サービスの展開を迅速化しています。通常、新規サービスの構築には約 2 週間を要しますが Terraform モジュールの活用により、サービスの拡大に合わせて継続的にリアーキテクトしながらも、この期間を維持できています。 AWS: 権限管理についても自動化されているとお聞きしました。 e-dash 伊藤・竹内: はい。工夫している点として、GitHub と AWS のアカウント権限管理もすべてコード化されています。開発メンバーが Devin (AI アシスタント) に依頼すると、プルリクエストが自動生成され、SRE メンバーがレビュー・承認するだけでユーザーの追加・削除が完了する仕組みを構築しています。 直面した課題と解決 AWS: システム構築において直面した課題はありますか? e-dash 伊藤・竹内: 当初は外部委託でシステムを構築していましたが、スタートアップとして短期間で本番稼働が求められるなか、制度改正や機能追加への即応性を高める必要がありました。そこで、内製化へと移行し、AWS のマネージドサービスを積極的に活用することで、限られたリソースでも高品質なサービスを迅速に展開できる体制を整えました。特に、Terraform による徹底した IaC 管理により、新規サービスの構築期間を約 2 週間に短縮できたことは大きな成果です。 今後の展望 AWS: 今後の技術的な展望について教えていただけますか? e-dash 伊藤・竹内:請求書アップロード機能においては、OCR の精度向上を継続的なテーマとして推進していきます。また、開発チームでは AI の活用を積極的に進め、開発フロー全体の効率化を図ります。定常的な業務を AI で自動化・半自動化することで、エンジニアがより価値の高い領域に集中できる体制を整備していきます。 著者について e-dash 株式会社様 佐藤 孝明（さとう たかあき）の紹介 新卒で野村総合研究所に入社し、システムエンジニアとして証券会社向けのバックオフィスシステムの開発・運用を担当。その後スタートアップ企業にてプロダクトマネージャとして、新規プロダクトの立ち上げ、組織開発を経験し、日産自動車にてコネクティドカーサービスのスマホアプリのプロダクトオーナーとして、プロダクトロードマップおよび KGI/KPI の策定と実行などの業務を行いコネクティド事業の収益拡大に寄与。2022 年 10 月から e-dash にプロダクトマネージャーとしてジョイン。 伊藤 明彦（いとう あきひこ）の紹介 新卒で野村総合研究所に入社し、様々な業界の IT システムの基盤設計・構築・運用を推進。その後スタートアップ企業にて開発リードとして、新規プロダクトの設計・開発・運用を担当。2024 年 9 月から e-dash にジョイン。現在は SRE チームのリーダーを担当。 竹内 克史（たけうち かつし）の紹介 バックエンドエンジニアとして複数サービスの開発に従事した後、現在は SRE としてインフラストラクチャの設計・運用を担当している。AWS を活用した信頼性向上施策、パフォーマンス改善、監視基盤の整備、自動化基盤の構築など、サービスの安定稼働を支える技術領域を幅広く推進している。2023 年 6 月に e-dash にジョイン。 アマゾンウェブサービスジャパン合同会社 松本 敢大 (Kanta Matsumoto) ソリューションアーキテクトとして、商社業界のお客様を中心に技術支援を行っています。様々な領域の商社という業界で沢山の刺激を受けております。新入社員育成として、新卒生成 AI 活用ブログ（ ブログ1 、 ブログ2 、 ブログ3 、 ブログ4 ）などを投稿。AWS User Group – Japan IoT 支部で登壇などをしております。Physical AI が最近のブームです 好きな AWS サービスは AWS IoT Core（ ブログ5 ）。趣味はカメラで、動物が好きです。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今年の目標は Kiro にどんどん業務をオフロードしていくことです。早速 Kiro を使って Strands Agent SOPs を作成してステアリングファイルとして利用してみましたが、複雑なワークフローでのエージェントの振る舞い記述を標準化できて便利ですね。 また、2月の Builder’s Flash も公開されております。生成 AI に関連する記事をピックアップしてみましたので、是非ご覧ください。 “伝わらない”を解消 ! 生成 AI で磨くAWS サポートケース起票スキル ~ 生成 AI 活用による問題解決の効率化 ~ AI エージェントで分析効率を飛躍的に向上させる実装ガイド 開発以外にも使える !? Bedrock Engineer の AI エージェントをカスタマイズしてみよう ! 限られた学習データでの画像生成 AI モデル開発とコスト最適化 エージェント自体の開発だけでなく、ユースケースを掘り下げる記事も公開されていますね。 新たに発表された「 フィジカル AI 開発支援プログラム 」をはじめとした各種「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集しております。特に「フィジカル AI 開発支援プログラム」は応募締め切りが2026年2月13日までとなっているので、ご興味のある方はぜひご確認ください。 それでは、2 月 3 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ:  地方病院が生成 AI の活用環境を2日で構築し内製化へ踏み出す 熊本中央病院様は、ANGEL Dojo 2025 で医療文書作成時間の削減に取り組み、月 800 時間の効率化が見込めるシステムを構築されました。しかし、電子カルテ端末からクラウドへの安全な接続と、電子カルテからのデータ抽出という2つの壁がありました。ispec様の CloudSail とAWSを組み合わせることで、2 日間という短期間で環境構築を完了し、翌日には職員を対象に 50 名以上が参加するハンズオンを実施しました。生成 AI により実装の速度やコストが低減していく中で、「やらなければいけないこと」にフォーカスして課題の特定と解決を迅速に実行した事例となっています。 開催報告「 11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 」を公開 2026年1月22日〜23日の2日間、AWS Loft Tokyo にて 11 社 87 名のエンジニア・ビジネスパーソンが参加した合同 AI-DLC Unicorn Gym の開催報告です。AI 駆動開発ライフサイクル（AI-DLC）は、AIを開発プロセスの中心に据えた新しい開発手法で、「AIが実行し人間が監視する」というアプローチを取ります。AI-DLC は特定のツールに依存せず、ウォーターフォールやアジャイルのような開発方法論をアップデートし、AI による変革を実現するためのガイドラインです。参加企業は当初 8 週間から 6 ヶ月を想定していた開発を 2 日間で完了させ、満足度は 5 点満点中 4.56 点、98.8 %が肯定的な評価を寄せました。 開催報告「 第9回鉄道技術展2025 AWS出展報告 」を公開 2025年11月26日から29日に開催された鉄道技術展 2025 での AWS 出展報告です。「クラウドと AI で変革する鉄道保全」をテーマに、IoT と生成 AI を活用したソリューションを紹介しました。AWS IoT Services によるリアルタイムの IoT 設備状態把握、Amazon Bedrock Knowledge Bases を活用した異常発生時の初動調査支援、Amazon Bedrock AgentCore による関係システムの情報把握支援という3つの柱で構成され、鉄道保全現場が抱える労働力不足や技術継承といった課題に対応します。 ブログ記事「 Kiro で Opus 4.6 が利用可能になりました 」を公開 Kiro IDE と CLI で Anthropic の最新モデル Claude Opus 4.6 が利用可能になりました。Opus 4.6 は Anthropic がこれまでにリリースした最も強力なモデルであり、コーディングにおいては世界最高のモデルです。大規模なコードベースや長期プロジェクトで優れた性能を発揮し、シニアエンジニアが複雑なタスクを Opus 4.6 に任せることで、数日かかるプロジェクトを数時間で完了できます。Kiro の仕様駆動型開発プロセスに最も適したモデルとして、実験的サポートとして提供されます。 ブログ記事「 AI を活用したゲーム制作: 静的なコンセプトからインタラクティブなプロトタイプへ 」を公開 AWS re:Invent 2025 で紹介された Agentic Arcade の技術アーキテクチャを解説しています。参加者が AI で数分で完全にプレイ可能なゲームプロトタイプを作成できるインタラクティブなデモ体験で、Amazon Bedrock AgentCore によるマルチエージェントオーケストレーション、 ComfyUI によるプログラマティックアセット生成、セマンティック検索を組み合わせています。 AI がゲームのコンセプト化をプロセスの早い段階でインタラクティブにすることで、初期段階の開発を変革する方法を示しています。 ブログ記事「 AI エージェントをプロトタイプから製品へ: AWS DevOps Agent 開発で得た教訓 」を公開 re:Invent 2025 で発表された AWS DevOps Agent の開発で学んだ、実用的なエージェント製品を構築するために必要な5つのメカニズムを紹介しています。評価テスト（evals）の実施、エージェントの軌跡をデバッグする可視化ツール、高速なフィードバックループ、意図を持った変更、本番環境のサンプルの定期的な確認です。LLM を使ったプロトタイプ構築は参入障壁が低いものの、多様な顧客環境で確実に動作する製品へと進むのは全く別のチャレンジであることを示しています。 ブログ記事「 オブザーバビリティエージェントで平均復旧時間を短縮する 」を公開 Amazon OpenSearch Service と Amazon Bedrock AgentCore を使用したオブザーバビリティエージェントを紹介しています。ログ、トレース、メトリクスの各シグナルタイプに対応する MCP サーバーを構築し、エージェントが複数のクエリや相関サイクルを処理して根本原因の特定やインサイト取得を高速化します。 SRE やオペレーションセンターの担当者が複数のダッシュボードを行き来する手動プロセスを、 AI エージェントが体系的に調査することで平均復旧時間（MTTR）を短縮できます。 ブログ記事「 フィジカル AI: 自律型インテリジェンスに向けた次なる基盤を築く 」を公開 AWSのフィジカル AI フレームワークを紹介する複数回ブログシリーズの導入記事です。フィジカル AI を物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステムと定義し、6つの相互接続された機能（物理世界の接続とデジタル化、データの保存と構造化、データのセグメント化と理解、シミュレーション・トレーニング・モデル最適化など）を通じて、デジタルインテリジェンスと物理的アクションの間に継続的な学習サイクルを作り出す方法を説明しています。 ブログ記事「 AI による物理的な現実世界の進化: インテリジェントな自動化の最前線 」を公開 AWS Generative AI Innovation Center が MassRobotics と NVIDIA と協業して立ち上げた Physical AI Fellowship を紹介しています。フィジカル AI は、アルゴリズムがデジタルの境界を超え、物理世界を認識し、理解し、操作するもので、各業界の運営方針を根本的に変えます。記事では自動化の4段階（基本的な自動化、適応的自動化、自律的自動化、完全な自律性）を定義し、AI ロボット分野が2034年までに1,242.6億ドルに達すると予測しています。Amazon のサプライチェーンでは効率を25%向上、Foxconn は製造デプロイ時間を40%削減、ヘルスケアでは AI 支援手術により合併症発生率が30%減少するなど、具体的な成果を示しています。 ブログ記事「 VAMS における NVIDIA Isaac Lab を使用した GPU アクセラレーション型ロボットシミュレーショントレーニング 」を公開 オープンソースの Visual Asset Management System（VAMS）が NVIDIA Isaac Lab と統合され、ロボットアセット向けの GPU アクセラレーション強化学習（RL）に対応しました。実世界でロボットをトレーニングするのは遅く、コストがかかり、危険を伴いますが、Isaac Lab は単一の GPU 上で数千のロボットインスタンスを並列実行でき、実世界で数か月かかるトレーニングが数時間のシミュレーション時間に圧縮されます。VAMS の Isaac Lab パイプラインアドオンは、アセット管理システムと直接統合することで、ロボットモデルからトレーニング済みポリシーまでのシームレスなパスを作成し、 GPU インスタンス管理やコンテナオーケストレーション、手動のデータ転送を不要にします。 ブログ記事「 フィジカル AI の実践: 人間と機械の相互作用を支える技術基盤 」を公開 フィジカル AI の完全な開発ライフサイクルを解説しています。データの収集と準備、モデルのトレーニングとファインチューニング（模倣学習、強化学習、シミュレーション、ワールドモデリング）、モデルの最適化（量子化、プルーニング、蒸留、コンパイル）、エッジ操作という反復的なプロセスを通じて、人間と真のパートナーシップを築くインテリジェントシステムを作成します。実例として、Diligent Robotics の Moxi ロボットが病院環境で看護師の日常的な物流業務を処理し、患者ケアに貴重な時間を取り戻している事例を紹介しています。 ブログ記事「 知的なフィジカル AI 構築: Strands Agents、Bedrock AgentCore、Claude4.5、NVIDIA GR00T、および Hugging Face LeRobot によるエッジからクラウドへ 」を公開 エージェンティック AI システムが物理世界へ拡大する中、エッジとクラウドのハイブリッドアーキテクチャの重要性を解説しています。ボールをキャッチするロボットアームのようなミリ秒単位の応答が必要な動作はエッジで処理し、複数ステップのタスク計画や他のロボットとの連携、集合的な経験からの学習はクラウドで処理します。Strands Agents Python SDK を使用して、Ollama でエッジデバイス上でローカルにモデルを実行することから始め、段階的にクラウドの高度な推論能力を統合する進歩的なアプローチを示しています。 ブログ記事「 AI を具現化するブログ: パート1 AWS Batch でロボット学習を開始する 」を公開 AWS 上で NVIDIA Isaac GR00T N1.5 3B をファインチューニングするためのスケーラブルなインフラストラクチャを構築する方法を紹介しています。GR00T N1.5 は実世界のデモンストレーション、Isaac Labからの合成データ、インターネット規模のビデオでトレーニングされた汎用基盤モデルで、様々なタスクと実装を超えた強力な汎化能力を提供します。AWS Batch、Amazon S3、Amazon EFS、Amazon ECRを組み合わせたアーキテクチャにより、GPU付きEC2インスタンスを動的にプロビジョニングし、トレーニングワークロードを実行します。クラウドの弾力性とNVIDIAの先進的なロボット学習スタックを組み合わせることで、開発サイクルを加速します。   サービスアップデート Amazon BedrockでClaude Opus 4.6が利用可能に Amazon BedrockでClaude Opus 4.6のサポートが開始されました。Anthropicによると、Opus 4.6は同社の最も高性能なモデルであり、コーディング、エンタープライズエージェント、プロフェッショナルワークにおいて世界最高のモデルです。エージェントワークフローでは数十のツールにわたる複雑なタスクを業界最高レベルの信頼性で管理し、プロアクティブにサブエージェントを起動して少ない監視で動作します。開発者は長期プロジェクト、複雑な実装、大規模コードベースに活用でき、200Kと1Mコンテキストトークン（プレビュー）をサポートします。 Amazon SageMaker JumpStartでDeepSeek OCR、MiniMax M2.1、Qwen3-VL-8B-Instructモデルが利用可能に Amazon SageMaker JumpStartでDeepSeek OCR、MiniMax M2.1、Qwen3-VL-8B-Instructの3つのモデルが利用可能になりました。DeepSeek OCRはドキュメント処理用のビジュアルテキスト圧縮を探求し、フォーム、請求書、図、複雑なドキュメントから構造化情報を抽出できます。MiniMax M2.1はコーディング、ツール使用、指示追従、長期計画に最適化されており、多言語ソフトウェア開発の自動化や複雑な複数ステップのオフィスワークフローを実行します。Qwen3-VL-8B-Instructは優れたテキスト理解と生成、深い視覚的知覚と推論、拡張されたコンテキスト長、強化された空間とビデオダイナミクスの理解、より強力なエージェントインタラクション機能を提供します。 Amazon SageMaker JumpStartでCartesia Sonic 3テキスト読み上げモデルが利用可能に Amazon SageMaker JumpStartでCartesiaのSonic 3モデルが利用可能になりました。Sonic 3はストリーミングテキスト読み上げ（TTS）用の最新ステートスペースモデル（SSM）で、高い自然さ、正確なトランスクリプト追従、業界最高レベルのレイテンシーを実現し、音量、速度、感情のきめ細かい制御を提供します。42言語をサポートし、APIパラメータとSSMLタグを通じた高度な制御性を提供します。100ms未満のレイテンシーで、感情やトーンの変化を含む人間の音声のニュアンスを捉えるリアルタイム会話AIを実現します。 Amazon SageMaker JumpStartでNVIDIA NIMsモデルが利用可能に Amazon SageMaker JumpStartで、バイオサイエンスとフィジカルAI向けに構築された4つのNVIDIA NIMsモデル（ProteinMPNN、Nemotron-3.5B-Instruct、MSA Search NIM、Cosmos Reason）がワンクリックデプロイ可能になりました。ProteinMPNNは構造データに基づくタンパク質配列最適化を実現し、MSA Search NIMはGPU加速された複数配列アライメントをサポートします。Nemotron-3.5B-Instructは256kトークンのコンテキストウィンドウで高い推論性能とネイティブツール呼び出しサポートを提供し、Cosmos ReasonはフィジカルAIとロボティクス向けのオープンでカスタマイズ可能な推論ビジョン言語モデルです。 Amazon BedrockでStructured Outputsが利用可能に Amazon BedrockでStructured Outputsのサポートが開始されました。定義したJSONスキーマに準拠した一貫性のある機械可読な応答を基盤モデルから取得できます。有効なJSONをプロンプトで要求したり、アプリケーションに追加のチェックを加える代わりに、必要な形式を指定するだけで、それに一致する応答を受け取れます。キーフィールドの抽出やAPIまたはツールを使用するワークフローの駆動など、小さなフォーマットエラーが下流システムを壊す可能性がある本番タスクに役立ちます。Anthropic Claude 4.5モデルと一部のオープンウェイトモデルで一般提供されており、Amazon Bedrockがサポートされているすべての AWS リージョンで利用可能です。 Amazon Bedrock AgentCore BrowserでBrowser Profilesをサポート Amazon Bedrock AgentCore BrowserでBrowser Profilesのサポートが開始されました。繰り返しログインフローなしで、複数のブラウザセッション間で認証状態を再利用できます。1日に数百または数千の自動ブラウザセッションを処理するエンタープライズ顧客にとって、セッションセットアップ時間を数分から数十秒に短縮します。Webサイトに一度認証してセッションをブラウザプロファイルに保存すると、そのプロファイルを使用して新しいセッションを開始した際に認証状態が保持され、ログイン状態が維持されます。読み取り専用と永続的な操作の両方に対応する柔軟なセッションモードを選択でき、複数のセッションが同じプロファイルを同時に使用する並列処理が可能です。アジアパシフィック（東京）リージョンをはじめとした 14 の AWS リージョンで利用可能です。 Amazon EC2 Capacity Blocks for MLが複数アカウント間で共有可能に Amazon EC2 Capacity Blocks for MLのクロスアカウント共有機能が一般提供されました。AWS Resource Access Manager（RAM）を使用して、予約されたGPU容量をAWSアカウント間で共有でき、利用率の最適化とコスト削減に役立ちます。組織はCapacity Blocksを購入して複数のアカウントにプロビジョニングでき、異なるワークロードが予約容量のプールに追加コストなしでアクセスできます。チームがMLインフラストラクチャ投資を調整し、予約されたGPU容量を異なるワークロード間で継続的に使用し続けることができます。EC2 Capacity Blocks for MLが提供されているすべてのAWSリージョンで利用可能です。 Amazon EC2 G7eインスタンスが米国西部（オレゴン）リージョンで利用可能に NVIDIA RTX PRO 6000 Blackwell Server Edition GPUを搭載したAmazon EC2 G7eインスタンスが米国西部（オレゴン）リージョンで利用可能になりました。G7eインスタンスはG6eと比較して最大2.3倍の推論性能を提供します。大規模言語モデル（LLM）、エージェントAIモデル、マルチモーダル生成AIモデル、フィジカルAIモデルのデプロイに使用でき、空間コンピューティングワークロードおよびグラフィックスとAI処理の両方の機能を必要とするワークロードで最高のパフォーマンスを提供します。最大8つのNVIDIA RTX PRO 6000 Blackwell Server Edition GPU（GPU当たり96 GBのメモリ）と第5世代Intel Xeonプロセッサを搭載しています。現在 G7e インスタンスは米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）のAWSリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

本ブログは 2025 年 11 月 11 日に公開された AWS Science News “ Amazon launches private AI bug bounty to strengthen Nova models ” を翻訳したものです。 本日 (2025 年 11 月 11 日)、Amazon は Amazon Nova 基盤モデルを含む特定の Amazon AI モデルおよびアプリケーションを対象としたプライベート AI バグバウンティプログラムの開始を発表しました。このプログラムは、セキュリティ研究者やパートナー大学の専門家と連携し、潜在的なセキュリティ上の問題を特定して修正することを目的としています。この招待制プログラムは、Amazon の既存の パブリックバグバウンティプログラム を補完するものです。パブリックプログラムはすべての研究者に公開されており、Amazon AI アプリケーションにおいて 30 件以上の有効な脆弱性が報告され、55,000 ドル以上の報奨金が支払われています。 「モデルをより強力で安全にするための最善の方法は、より広いコミュニティと連携することだと考えています」と、Amazon の汎用人工知能担当シニアバイスプレジデントである Rohit Prasad 氏はコメントしています。「Nova を外部からのテストに開放することで、安全性、透明性、継続的な改善への取り組みを強化しています」 このプログラムは、アカデミックな研究とセキュリティの現場のギャップを埋めることに重点を置いています。2025 年 11 月 11 日に、Amazon の米国オースティンオフィスでライブイベントが開催され、プログラムがスタートします。このイベントでは、 Amazon Nova AI Challenge のトップ大学チームとプロフェッショナルなセキュリティ研究者が一堂に会し、実環境の AI セキュリティ課題に取り組みます。目標は、Nova モデルを含む Amazon AI モデルおよびアプリケーションのセキュリティを強化するとともに、次世代の AI セキュリティ研究者を育成することです。 セキュリティ研究者は、AI システムを調査・検証する重要な外部の専門家として、初期の開発やテストでは明らかにならない潜在的な脆弱性、バイアス、予期しない動作を特定します。このプログラムを通じて、研究者はサイバーセキュリティの問題や化学、生物、放射性物質、核 (CBRN: Chemical, Biological, Radiological, and Nuclear) 脅威の検出など、重要な領域で Nova モデルをテストします。参加資格を満たした参加者は、有効な脆弱性の報告に対して 200 ドルから 25,000 ドルの報奨金を獲得できます。 「セキュリティ研究者は、私たちの AI モデルとアプリケーションが独創的な攻撃にも耐えられるかを実際に検証してくれる、最も重要なパートナーです」と、Amazon Stores の CISO である Hudson Thrift 氏はコメントしています。「この新しいプログラムにとても期待しており、セキュリティコミュニティや大学・研究機関と連携して、AI システムをさらに安全にすることを楽しみにしています」 プログラムの重点領域 参加者に期待している調査の重点領域は以下です。 セキュリティに影響を与えるプロンプトインジェクションとジェイルブレイク 実環境での悪用の可能性があるモデルの脆弱性 モデルがセキュリティの問題や CBRN 関連の脅威など、有害な活動を意図せず手助けしてしまう手法 参加資格と参加方法 2025 年 11 月にオースティンで Amazon Bug Bounty が主催するライブイベントが、プログラムの開始を告げます。プライベートな継続的ライブプログラムへのより広い参加は、2026 年初頭にセキュリティ研究者および選ばれた研究チームに招待制で提供される予定です。プライベートプログラム外の研究者や Amazon のお客様は、 Amazon のパブリックバグバウンティプログラム を通じて、 .amazon の下にある「Gen AI Apps」を選択することで、Amazon AI アプリケーションの潜在的なセキュリティ問題を報告できます。 このプログラムが重要な理由 Nova モデルは、Alexa、Amazon Bedrock を通じた AWS のお客様、その他の Amazon 製品にわたる成長するエコシステムを支えており、そのセキュリティの確保は引き続き最優先事項です。この新しいバグバウンティプログラムは、研究コミュニティとプロフェッショナルなセキュリティコミュニティが協力することで AI の安全性が最も速く進歩するという Amazon の信念を反映しています。実践的な学習と脆弱性検出の機会を生み出すことで、Amazon は AI の次の時代を形作るシステムを守れる、新世代の研究者の育成を支援しています。 参加方法 参加に興味のある研究者は、 Amazon Science で最新情報をご確認ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 2 月 4 日に公開された Venugopalan Vasudevan、Dinesh Balaaji Prabakaran、Sureshkumar Natarajan、Anjan Dave による “ AWS Transform custom: AI-driven Java modernization to reduce tech debt ” を翻訳したものです。 今日の急速に進化するソフトウェア環境において、Java アプリケーションの保守とモダナイゼーションは、多くの組織が直面する重要な課題です。新しい Java バージョンがリリースされ、ベストプラクティスが進化するにつれて、効率的なコード変換の必要性がますます重要になっています。今日の組織は、Java アプリケーションをモダナイズする際に大きな課題に直面しています。レガシーコードベースには、パフォーマンスと保守性を妨げる古いパターン、非推奨の API、非効率な実装が含まれていることがよくあります。従来の手動リファクタリングアプローチは時間がかかり、エラーが発生しやすく、大規模なコードベース全体に拡張することが困難です。さらに、開発者が新規開発とデプロイにより多くの時間を費やすにつれて、技術的負債の量は増え続け、レガシーコードの大規模な変換が必要になります。 AWS Transform custom は、インテリジェントな自動化を通じてこれらの課題に対処し、Java バージョンアップグレードなどの一般的なシナリオ向けの標準化された変換パッケージである AWS マネージド変換 (AWS-Managed Transformation) を提供します。これらの変換により、チームは大規模に実行できる標準化されテスト済みの変換パターンを通じて迅速な成果を達成でき、お客様に大幅な時間とコストの削減をもたらします。さらに、お客様はカスタム ユーザー定義のカスタム変換 を作成して、言語、フレームワークなどにわたるコード変換で技術的負債に対処できます。 この記事では、Java アップグレード用の AWS Transform custom のすぐに使える変換を活用する方法について説明します。この記事の最後までに、変換プロセスを完全に制御しながら、これらの標準化された変換を使用して Java アプリケーションを効率的にモダナイズする方法を理解できるようになります。 AWS Transform custom の紹介 AWS Transform custom は、エージェント型 AI を使用して大規模なコードモダナイゼーションを自動化し、プログラミング言語のバージョンアップグレード、API の移行、フレームワークの更新、組織固有の変換を処理します。継続的な学習を通じて、エージェントは各実行と開発者からのフィードバックから改善を重ね、専門的な自動化技術が不要な高品質で再現性のある変換を実現します。 前提条件 AWS Transform custom で Java モダナイゼーションの旅を始める前に、必要な開発環境、ビルドツール、AWS Transform custom コマンドラインインターフェイス (CLI) がインストールされていることを確認してください。詳細な前提条件とセットアップ手順については、 AWS Transform custom 利用の前提条件 を参照してください。 モダナイゼーションシナリオの理解 Movie Service アプリケーション を使用して AWS Transform custom を実演します。これは、Gradle を使用した Java 8 上に構築された Spring Boot REST API です。これは、レガシーな依存関係、古いパターン、技術的負債を伴う典型的なエンタープライズモダナイゼーションの課題を表しています。 AWS マネージド変換 (AWS-Managed Transformation) の活用 AWS Transform custom は、Java バージョンアップグレードなどの一般的なモダナイゼーションタスク向けに設計された AWS マネージド変換 (AWS-Managed Transformation) の活用に焦点を当てています。 AWS マネージド変換 (AWS-Managed Transformation) は、追加のセットアップなしですぐに使用できる、一般的なユースケース向けの事前構築された AWS 検証済みの変換です。これらの変換は、最小限の設定で即座に価値を提供し、標準的なアップグレードシナリオに最適です。 AWS Transform custom CLI 機能の理解 AWS Transform custom は、インタラクティブと自動化の両方の変換ワークフローを可能にする包括的なコマンドラインインターフェイスを提供します。 atx --version # ATX のバージョンを表示 atx --help # 一般的なヘルプを表示 atx custom def list # 変換パッケージの一覧 atx # インタラクティブな会話の開始 利用可能なすべてのコマンドの詳細については、 AWS Transform custom コマンドリファレンス を参照してください。 図 1: AWS Transform custom インタラクティブモード 利用可能な変換の検出 atx custom def list を使用して、AWS マネージド変換 (AWS-Managed Transformation) と組織によって作成されたカスタム定義（ユーザー定義）変換を含む、利用可能なすべての変換を表示します。主要な AWS マネージド変換 (AWS-Managed Transformation) には、Java/Python/Node.js バージョンアップグレードと AWS SDK 移行が含まれます。 図 2: AWS Transform custom は利用可能な AWS マネージド変換 (AWS-Managed Transformation) とカスタム定義（ユーザー定義）変換をリスト表示 AWS マネージド変換 (AWS-Managed Transformation) の適用 変換を適用する前に、プロジェクトが Git で初期化されており、すべてのビルドとテストケースが Java 8 で正しく動作していることを確認してください（必要に応じて、適切なビルドコマンドオプションとエージェントへの指示を使用してテストケースをスキップできます）。Gradle プロジェクトの場合、 ./gradlew build が正常に実行されることを確認してください。 変換プロセスは構造化されたアプローチに従います。 クリーンな Git 状態の確保: git status git add . git commit -m "Baseline before Java 21 transformation" 変換の適用: インタラクティブモードまたはダイレクトコマンドモードのいずれかを使用して変換を適用できます。このブログでは、プロセスをステップバイステップで説明するためにインタラクティブモードを使用します。 インタラクティブモード（このブログで使用）: まず、変換設定を含む config.json ファイルを作成します。 { "codeRepositoryPath": "/path/to/your/aws-appconfig-java-sample-gradle", "transformationName": "AWS/java-version-upgrade", "buildCommand": "./gradlew clean build", "validationCommands": "build and validate using \"./gradlew clean build\" after transformation to test with java 21", "additionalPlanContext": "This is a Java 8 to 21 transformation of a gradle app , also include all dependency migration as well. Use java path /path/to/your/java-8/bin/java and /path/to/your/java-21/bin/java when building before and after transformation. We are using gradle wrapper gradlew, update it if needed for java 21 upgrade. Check for deprecated methods and dependencies and update them." } config.json の codeRepositoryPath をローカルプロジェクトディレクトリを指すように更新し、 additionalPlanContext の Java パスを Java 8 と 21 のインストールに合わせて更新します。設定ファイルとそのパラメータの詳細については、 設定ファイルの使用 を参照してください。 次に、インタラクティブモードで変換を実行します（このブログのウォークスルーで使用）。 For Java version upgrade with Gradle using config.json (Interactive Mode): atx custom def exec -t --configuration file://config.json 図 3: AWS Transform custom は config.json から提供された変換設定を使用してインタラクティブモードで gradle 変換を実行 ダイレクトコマンドモード（代替アプローチ）: 自動化された CI/CD パイプラインや、インタラクティブなプロンプトなしで変換を実行したい場合は、このモードを使用します。 atx custom def exec -x -t --configuration "file://config.json" パラメータの説明: – --configuration : インタラクティブモード用の設定ファイルを指定 – -x : インタラクティブなプロンプトなしで変換を自動的に実行（ダイレクトモード） – -t : 実行中の検証のためのテストモードを有効化（ダイレクトモード） --configuration : file:// プレフィックス付きの設定ファイルパスを指定（ダイレクトモード） ATX 実行コマンド ATX CLI を使用した Gradle プロジェクト用の AWS マネージド Java バージョンアップグレード変換の実行 変換計画のレビュー: AWS Transform custom は、 config.json で提供された設定に基づいてプロジェクトを分析し、包括的な変換計画を生成します。この計画には、以下を含むすべての提案された変更が詳細に記載されています。 Java バージョンの更新 : Java 8 から Java 21 設定への移行 API 移行パターン : 非推奨 API と最新の代替手段の自動更新 フレームワークのモダナイゼーション : Spring Boot バージョンアップグレードと互換性の更新 依存関係の変更 : Java 21 と互換性のある更新されたライブラリバージョン ビルドシステムの更新 : Java 21 互換性のための Gradle 設定とプラグインの変更 コードパターンの改善 : 最新の Java 機能とベストプラクティスの実装 変換計画が予想されるすべての更新を網羅していることを確認するために、徹底的なレビューを行うことをお勧めします。 config.json の additionalPlanContext は、依存関係の移行と Gradle ラッパーの更新を含めるように変換をガイドするのに役立ちます。調整が必要な場合は、CLI インターフェイスを通じてフィードバックを提供してください。 さらに、プロジェクトに含まれる追加のレガシー依存関係のアップグレードなど、追加の変更をターゲットにするために変換をカスタマイズしたい場合は、変換計画をレビューする際にフィードバックとして提供できます。AWS Transform custom は、続行する前に変換計画を改善するために提供されたすべてのフィードバックを組み込みます。 変換の適用: 変換計画が要件を満たしていることを確認したら、 proceed と入力して Enter キーを押します。AWS Transform custom は、承認された計画に従って変換を実行します。 変換プロセスは自動的に: – 新しいブランチを作成し、変換された変更をそこにコミット – Java 21 用の Gradle 設定を更新 – Java EE から Jakarta EE パッケージへの移行（該当する場合） – Java 21 互換性のためのフレームワーク依存関係を更新 – 必要なすべてのコード変更を適用 – Java 21 互換性のためのテストケースとテストフレームワークを更新 – 包括的な検証ビルドを実行 AWS マネージド変換 (AWS-Managed Transformation) の結果 Java バージョンアップグレード変換を適用した後、以下の変更が観察されます。 設定の更新: – Java バージョン: 8 → 21 – Spring Boot バージョンアップグレード – Gradle プラグインと設定の更新 – 依存関係バージョンのモダナイゼーション 変更を検証するには、Java 21 に切り替えて ./gradlew build を実行し、変換が成功したことを確認してから、アプリケーション機能をテストします。 図 4: 更新された Gradle 設定 – 更新された Java 21 設定とモダナイズされた依存関係を示す Gradle build.gradle 図 5: raw 型の使用というレガシーパターンがジェネリクスに変換された更新されたコード 図 6: raw 型の使用というレガシーパターンがジェネリクスに変換された更新されたコードの 2 番目の例 図 7: javax.security から java.security への依存関係の更新と CertificateFactory を使用した X509Certificate の取得 図 8: junit 4 から junit5 への更新されたテストケース AWS マネージド変換 (AWS-Managed Transformation) を超えて: カスタム定義変換 AWS マネージド変換 (AWS-Managed Transformation) は標準的な Java モダナイゼーションシナリオに対して優れたカバレッジを提供しますが、利用可能な AWS マネージド変換 (AWS-Managed Transformation) が特定の変換要件に対応していない場合があります。このような状況では、AWS Transform custom により、ユーザーは独自の組織固有のカスタム定義変換を作成およびテストできます。 カスタム定義変換を作成するタイミング カスタム定義変換は、独自のフレームワーク、組織固有のコーディング標準、複雑な複数ステップの移行シナリオなど、AWS マネージド変換 (AWS-Managed Transformation) が特定のニーズをカバーしていない場合に必要になります。 カスタム定義変換の作成 AWS Transform custom により、チームは変換ルールと設定ファイルを使用してカスタム変換を開発できます。これにより、組織は要件に固有の変換ロジックを定義し、サンプルコードでテストし、検証済みの変換をチーム間で共有できます。 AWS Transform custom のインタラクティブモード（ atx ）は、カスタム定義変換の作成に特に有益であり、会話型のインタラクションを可能にして要件を反復的に改善し、リアルタイムのフィードバックを得ることができます。カスタム定義変換は、AWS マネージド変換 (AWS-Managed Transformation) が特定のモダナイゼーションニーズを満たさない場合に、AWS Transform custom の機能を拡張する柔軟性を提供します。 継続的学習とナレッジアイテム AWS Transform custom は、各変換実行から自動的に学習して将来の結果を改善します。特に Java アップグレードについては、サービスは成功したリファクタリング戦略、一般的な依存関係の競合、Java バージョン間のフレームワーク互換性マトリックスなどのパターンをキャプチャします。この知識は将来の変換にフィードバックされ、成功したアップグレードパスの予測がより正確になり、手動介入が減少します。 ナレッジアイテム はアカウント固有であり、AWS アカウントの境界内に留まります。ユーザーは継続的学習を有効または無効にでき、この設定を完全に制御できます。 まとめ このブログでは、AWS マネージド変換 (AWS-Managed Transformation) を使用して AWS Transform custom が効率的な Java アプリケーションモダナイゼーションを可能にする方法を実演しました。Java 8 と Spring Boot 2.x で実行されているレガシー Movie Service アプリケーションから始めて、最新の依存関係とパターンを備えた Java 21 への変換に成功しました。 ステップバイステップのプロセスでは、ベースラインの確立、 atx custom def list を使用した利用可能な変換の検出、AWS Transform custom の CLI を通じた変換の適用方法を示しました。その結果、更新された Java バージョン、Spring Boot アップグレード、拡張された switch 式やローカル変数型推論などの最新の Java 機能を備えた完全にモダナイズされたアプリケーションが得られました。これらすべてが、数週間の手動リファクタリングではなく数分で達成されました。 Java モダナイゼーションを超えて Java モダナイゼーションを超えて、AWS Transform custom の変換機能は他のプログラミング言語とフレームワークに拡張され、多様なテクノロジースタック全体にわたる包括的なアプリケーションポートフォリオモダナイゼーションのための汎用的なソリューションとなっています。エージェントは、以下を含む多様な変換ユースケースをサポートします。 Java、Python、Node.js のバージョンアップグレード ランタイムと API の移行（AWS SDK v1→v2、Boto2→Boto3） フレームワークの移行とアップグレード 言語の翻訳とアーキテクチャの変更 組織固有のカスタム定義変換 AWS Transform customは「定義は一度、変換はどこでも (define once, transform everywhere) 」というアプローチにより、組織全体で変換処理を一度定義し、反復可能なタスクを実行することで、変換知識の蓄積と拡大を実現します。これにより知識のサイロ化が解消され、チームやプロジェクトの範囲に関わらず一貫した品質が保証されます。 今すぐ始めましょう AWS Transform custom で Java アプリケーションをモダナイズする準備はできましたか？開始方法は次のとおりです。 インストールスクリプトを使用して AWS Transform custom CLI (atx) のインストール し、環境を確認 transform-custom:* 権限で AWS 認証情報の設定 atx custom def list を使用して、 利用可能な AWS マネージド変換 (AWS-Managed Transformation) を探索 ダイレクト実行モード（ atx custom def exec ）またはインタラクティブモード（ atx ）を使用して Java アプリケーションに 変換の適用 Gradle プロジェクトの場合は ./gradlew build を使用した包括的なテストを通じて 結果の検証 アプリケーションポートフォリオ全体への拡張し、 一貫したモダナイゼーションを実現 追加リソース 詳細なセットアップ手順とドキュメントについては、以下をご覧ください: AWS Transform custom 入門ガイド AWS Transform custom 製品ページ AWS Transform custom ドキュメント AWS Transform custom コマンドリファレンス 今すぐモダナイゼーションの旅を始めて、大規模な AI 駆動コード変換の力を体験してください。 著者について Venugopalan Vasudevan Venugopalan Vasudevan (Venu) は AWS のシニアスペシャリストソリューションアーキテクトであり、Amazon Q Developer、Kiro、AWS Transform に焦点を当てた生成 AI イニシアチブをリードしています。彼は、顧客が AI を活用した開発者向けソリューションやモダナイゼーションソリューションを採用・拡張し、イノベーションとビジネス成果を加速できるよう支援しています。 Dinesh Balaaji Prabakaran Dinesh は AWS のエンタープライズサポートリードであり、独立系ソフトウェアベンダー（ISV）のクラウドジャーニーをサポートすることを専門としています。AWS 生成 AI サービスの専門知識を持ち、顧客が Amazon Q Developer、Kiro、AWS Transform を活用して、AI を活用した支援によりアプリケーション開発とモダナイゼーションを加速できるよう支援しています。 Sureshkumar Natarajan Sureshkumar Natarajan は AWS のシニアテクニカルアカウントマネージャーであり、生成 AI イニシアチブに焦点を当てて、エンタープライズ顧客のクラウドジャーニーをサポートしています。彼は、組織が Amazon Q Developer、Kiro、AWS Transform を活用して新しい機能を引き出し、開発ワークフローを効率化し、変革的なビジネス成果を達成できるよう導いています。 Anjan Dave Anjan Dave は AWS のプリンシパルソリューションアーキテクトであり、25 年以上の IT 経験を持っています。彼は、生成 AI アプリケーションのモダナイゼーション、インフラストラクチャのスケーラビリティ、開発者の生産性向上イニシアチブを専門としています。 Anjan は、グローバルプロジェクト全体で生成 AI とモダナイゼーション戦略をリードし、イベント駆動型アーキテクチャとマイクロサービスアーキテクチャを通じて HCM プロバイダーのテクノロジーロードマップに影響を与えています。彼は、ソフトウェア開発ライフサイクルに生成 AI を統合して日常的なタスクを自動化し、エンジニアリングチームが高付加価値のアーキテクチャ作業に集中できるようにすることを提唱しています。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2025 年 11 月 21 日 に公開された「 AI-assisted game production: From static concept to interactive prototype 」を翻訳したものです。 ゲーム開発は、プレイ可能になるずっと前から始まります。チームはコンセプトのブレインストーミングに数週間、デザイン作成に数か月、そしてインタラクティブなデモが完成するまでメカニクスの実装とテストに無数の時間を費やします。課題はタイムラインの制約だけではありません。重要な検証と改善は従来、開発サイクルの後半で行われるため、変更にコストがかかり、創造的な方向転換が困難になります。 AI は、ゲームのコンセプト化をプロセスの早い段階でインタラクティブにすることで、初期段階の開発を変革します。 AI でチームは次のことができます。 創造的な方向性を迅速に探索し検証する アーティスティックなビジョンに合ったプレースホルダーアセットを生成する プレイ可能なプロトタイプでゲームプレイメカニクスをテストする 完全な実装を待たず、即座のフィードバックでコンセプトを改善する 開発サイクルの早い段階に洗練度とインタラクティブ性が移行し、大規模なエンジニアリングリソースを投入する前に、より適切な情報に基づいた創造的な意思決定ができます。 Amazon Web Services (AWS) re:Invent 2025 では、 Agentic Arcade を紹介します。参加者が AI で数分で完全にプレイ可能なゲームプロトタイプを作成できるインタラクティブなデモ体験です。参加者は、カスタムアート、メカニクス、プロフェッショナルなストアフロントプレゼンテーションを備えた、すぐにプレイできる完全に機能するブラウザベースのゲームを組み立てます。 本記事では、Agentic Arcade の背後にある技術アーキテクチャを探り、これらのパターンを独自のゲーム開発ワークフローに適用して加速する方法を示します。 図 1: Agentic Arcade ブース デモ体験 Agentic Arcade は、プロのゲームスタジオワークフローを反映した 4 つのステーションで構成されています。参加者は各ステーションを順に進み、4 つの専門 AI エージェントと協力します。 クリエイティブディレクション: Director Agent と協力して、ゲームのジャンル、テーマ、目的を定義し、全体的なクリエイティブコンセプトを決定します。 テクニカルアート: Artist Agent と協力して、ゲームのパッケージデザインを生成し、スタイルに一貫性があり視覚的にまとまったキャラクターアセット、カラーパレット、サウンドエフェクトを選択します。 ゲームプレイ開発: Developer Agent と協力してゲームプレイ機能を実装し、コアゲームメカニクス、特殊能力、プレイヤー難易度を決定します。 ゲームプレイテスト: 仮想ストアフロントに最終ゲームをデプロイし、 Playtester Agent と一緒にゲームを体験します。エージェントはゲームを分析してフィードバックを提供します。 AI が初期コンセプトから数分でプレイ可能なプロトタイプまで、完全なゲーム開発パイプラインを通じて開発者をガイドする方法を示します。連携して動作する包括的な AWS AI サービス群によって実現されています。 Amazon Bedrock は基盤モデルへのアクセスを提供し、 Anthropic の Claude がゲームコンセプト生成とゲームレビューの推論を支え、 Stability AI の Stable Diffusion と Amazon Nova が高品質なビジュアルアセット作成を可能にし、 Amazon Titan がセマンティックアセット検索を推進します。 Amazon Bedrock AgentCore は、開発パイプライン全体で専門 AI エージェントが協力するマルチエージェントシステムを調整し、各エージェントが異なるゲームスタジオの役割を表します。 Strands Agents は、すべてのエージェントインタラクション全体で型安全な構造化出力を実現し、一貫したデータ形式とパイプラインの異なるステージ間の信頼性の高い統合を可能にします。 Kiro は、エージェンティック AI 統合開発環境 (IDE) で、目的、プレイヤー能力、敵の行動、スコアリングシステムを定義する包括的なゲーム仕様を生成します。 Amazon S3 Vectors は、Amazon Simple Storage Service ( Amazon S3 ) の機能で、ベクトル埋め込み表現でセマンティックアセット検索を可能にします。キーワードタグに依存せず、視覚的特性をマッチングします。 Amazon Bedrock Guardrails は、すべての AI 生成出力にわたってコンテンツ安全ポリシーを適用し、体験全体で適切なコンテンツを検証します。 マルチエージェントオーケストレーション、プログラマティックアセット生成、セマンティック検索、最新のゲームアーキテクチャパターンを組み合わせることで、開発者はより速く創造的な方向性を探索でき、ゲームをユニークにするものに集中できます。 アーキテクチャ概要 図 2: アーキテクチャ概要 完全なサーバーレスアーキテクチャで実現されており、複数のレイヤーを包含しています。 フロントエンドレイヤー: Amazon S3 でホストされ、 Amazon CloudFront で配信される React アプリケーション API レイヤー: HTTP および WebSocket API 用の Amazon API Gateway 、接続管理用の AWS Lambda 、認証用の Amazon Cognito コンピューティングレイヤー: Amazon ECS 用 AWS Fargate 上の FastAPI バックエンド、GPU サポート付きコンテナ化タスクとしての ComfyUI ワークフロー、処理キューを管理する Amazon Simple Queue Service ( Amazon SQS ) データレイヤー: セッション状態とタスクキュー用の Amazon DynamoDB 、アセットストレージ用の Amazon S3、セマンティック検索用の S3 Vectors、モデルストレージ用の Amazon Elastic File System ( Amazon EFS ) AI サービス: Amazon Bedrock (Amazon Nova Models、Claude、Stable Diffusion、Amazon Titan)、Kiro、Amazon Bedrock Guardrails、Strands Agents を使用した Amazon Bedrock AgentCore、オープンソースモデル ( FLUX.1 ) アーキテクチャの高レベルなデータフローは次のとおりです。 ユーザーインタラクションは CloudFront で React フロントエンドに流れます。 API Gateway がリクエストを Lambda または ECS コンテナにルーティングします。 マルチエージェントワークフローは Amazon Bedrock AgentCore で調整されます。 アセットは、Amazon ECS 上でヘッドレスで実行される ComfyUI で非同期で生成されます。 ライブデモ中は、ベクトル検索により Amazon S3 から類似のアセットを取得します。。 ゲーム構成は DynamoDB に保存されます。 WebSocket 接続がデータの更新をリアルタイムにストリーミングします。 最終ゲームは Excalibur.js でブラウザ内でレンダリングされます。 サーバーレスアーキテクチャは、コスト効率を維持しながら自動スケーリングを可能にし、アセット生成とランタイム選択の明確な分離により一貫したパフォーマンスを促進します。 次に、アーキテクチャの実装を詳しく見ていき、AI がゲーム開発ライフサイクルの複雑なワークフローをどのように強化できるかを示します。 Amazon Bedrock AgentCore によるマルチエージェントオーケストレーション Agentic Arcade の中核は、専門 AI エージェントがゲーム作成のさまざまな側面を処理するために調整する洗練されたマルチエージェントシステムです。AI が人間の創造的ワークフローをどのように反映できるかを示し、各エージェントが開発プロセスにドメイン専門知識をもたらします。 エージェントの専門化 各ステーションには、明確な責任を持つ専門エージェントがあります。 Director Agent はゲームコンセプト開発に焦点を当て、さまざまな AI モデルを使用して創造的な探索とゲーム定義を支援します。 Artist Agent はビジュアルアセット選択を調整し、ゲームのパッケージデザイン生成を担当し、ベクトル埋め込み表現を使用してキャラクターアセット群を取得します。 Developer Agent はゲームメカニクス構成を処理し、適切なメカニクスを選択して構成ファイルを生成します。 Playtester Agent は完成したゲームを評価し、ゲームプレイ機能を分析して次のステップに関するレコメンデーションを提供します。 スーパーバイザー・ワーカーパターン 舞台裏では、スーパーバイザー・ワーカーアーキテクチャがこれらのエージェントを調整します。スーパーバイザーエージェントがワーカーエージェントにタスクをディスパッチし、ワーカーエージェントは専門機能を実行して報告します。評価エージェントは、アセットが本番パイプラインに入る前に、品質基準に対して出力を検証します。 タスクキュー管理用の Amazon DynamoDB、タスクディスパッチ用の AWS Lambda で実装されています。Amazon Bedrock は、Amazon Bedrock AgentCore と Strands Agents によってエージェント的に駆動される AI モデル呼び出しを提供します。エージェントは各セッション内で短期記憶を維持し、呼び出し間でコンテキストを渡すことで、4 つのステーションすべてにわたって一貫した意思決定を実現します。 Strands Agents は構造化出力機能を提供し、型安全な応答を可能にし、エージェントインタラクション全体で一貫したデータ形式を保持します。オーケストレーション用の Amazon Bedrock AgentCore と構造化出力用の Strands Agents の組み合わせにより、複雑なマルチエージェントワークフローの堅牢な基盤が作成されます。 ComfyUI によるプログラマティックアセット生成 従来の画像生成ツールは、シンプルなテキストから画像へのプロンプトに依存しています。Agentic Arcade は ComfyUI で、複雑で再現可能なワークフローをコードとして構築します。必要なゲームジャンル、テーマ、必要なスタイルに基づいたエージェント的なプロンプト作成で、大規模で一貫したアセット生成が可能になります。ゲーム開発における基本的な課題を解決します。特定のコンセプトに一致し、潜在的に数千のアセット全体で品質と一貫性を維持するスプライトとビジュアルアセットを作成することです。 コードとしての ComfyUI ワークフロー ComfyUI は、画像生成用のノードベースのビジュアルプログラミングインターフェイスを提供します。Agentic Arcade はこれをプログラマティックに使用し、各ワークフローはモデル選択、生成パラメータ、後処理パイプライン、出力仕様を指定する JSON 構成として定義されます。ワークフローは、GPU サポート付きの Amazon ECS 上でコンテナ化タスクとして実行されます。モデルは高速タスク起動のために Amazon EFS ボリュームに保存されます。Amazon SQS が処理キューを管理します。 自律的なアセットパイプライン エージェントによって駆動されるパイプラインは、人間が提供するコンセプトに基づいて、洗練されたアセットを自動的に生成、評価、作成します。キャラクタースプライト生成は、ゲームアセット用に最適化された専門モデルをロードし、ユーザーのテーマとジャンル選択を組み込んだプロンプトを適用し、ゲームプレイ用に最適化された出力を作成するワークフローを使用します。 アセットは、レイテンシーを回避するためにゲームの実行前に非同期で生成されます。ComfyUI ワークフローは包括的なアセットライブラリを生成し、セマンティック検索用の埋め込み表現とベクトルが作成され、アセットがデモ体験にロードされます。ライブデモ中は、特定のコンポーネントが Amazon Bedrock でリアルタイムで生成され (ゲームコンセプトとタイトルを含む)、画像生成モデルでボックスアートが生成され、アセットをマッチングするためのベクトル埋め込み表現による検索が行われます。キャラクタースプライト、環境アセット、サウンドエフェクトは、セマンティック検索でアセットライブラリからインテリジェントに選択されます。 エージェンティックな品質管理 生成されたすべてのアセットは、アセットライブラリに入る前にエージェンティックな評価パイプラインを通過します。評価エージェントは Amazon Bedrock で Amazon Nova Lite のマルチモーダル機能にアクセスし、認識可能性、ジャンルの適切性、視覚的一貫性、コンテンツ安全性を含む品質基準に対して画像を評価します。アセットが品質しきい値を満たさない場合、システムは自動的に生成プロンプトを改善して再生成します。 プログラマティックアプローチは、アセット生成をアドホックな創造的プロセスから、バージョン管理、テスト、継続的改善が可能な信頼性の高いスケーラブルなパイプラインに変換します。 ベクトル埋め込み表現によるインテリジェントなアセット検索 数千のオプションから視覚的にまとまったアセットを見つけるには、キーワードマッチングではなく、セマンティックな理解が必要です。作成されるゲームに適したアセットを取得し、ユーザーの好みをコンテンツにインテリジェントにマッチングすることでアセット生成システムを拡張します。 セマンティック検索 ジャンル、テーマ、目的、選択されたアートワーク全体でのユーザーの選択に基づいて、システムは S3 Vectors が有効になっている Amazon S3 に保存されたアセットをクエリします。セマンティック検索を活用することで、類似した視覚的特性を持つキャラクタースプライトと環境アセットを取得できます。システムは Amazon Titan Multimodal Embeddings モデルで埋め込み表現 (Embeddings) を生成し、視覚的特性を高次元ベクトルとしてキャプチャし、ゲームジャンルでフィルタリングします。 インテリジェントなアセットマッチング 埋め込み表現ベースのアプローチにより、システムは各ゲームコンセプト内で一貫性を維持しながら、多様な創造的方向性をサポートできます。厳選されたライブラリから適切なアセットにユーザーの好みをインテリジェントにマッチングすることで、システムは応答性が高く適切に感じられる、コンテキストに関連したレコメンデーションを提供します。ベクトル類似性検索は数秒で結果を返し、リアルタイムのアセットレコメンデーションを可能にします。 Kiro によるエージェント駆動型ゲーム開発 最終的にプレイ可能なゲームは、さまざまなジャンルにわたってモジュール式で再利用可能なゲームロジックを可能にする最新のゲームアーキテクチャパターンを使用します。同じ基盤コードが、コンポーネントとシステムのさまざまな組み合わせを構成することで、縦スクロールシューティング、プラットフォーマー、その他のゲームタイプをサポートできます。 Entity Component System アーキテクチャ 各セッションでゲームをゼロから構築するのではなく、Agentic Arcade は Entity Component System ソフトウェアパターンを使用します。ゲームオブジェクト (エンティティ) をその動作 (コンポーネント) とロジック (システム) から分離します。エンティティは、プレイヤーキャラクターや敵などのゲームオブジェクトです。コンポーネントは、位置、速度、ヘルスなどのプロパティを定義します。システムには、特定のコンポーネントの組み合わせを持つエンティティに対して動作するロジックが含まれます。 このアーキテクチャにより、ゲーム生成は非常に柔軟でモジュール式になります。開発者がメカニクスと機能を選択すると、システムは適切なコンポーネントとシステムを構成します。同じ Entity Component System 基盤が、コンポーネント構成とシステムロジックを交換することで、さまざまなジャンルをサポートします。 スペック駆動の構成定義 Kiro は、デモ体験自体の多くを作成するために使用されました。Kiro は、ゲームの目的、プレイヤー能力、敵の行動、スコアリングシステム、難易度の進行を定義する構造化された仕様を生成します。 生成された各ゲームは、アセット参照、ゲームメカニクスパラメータ、タイトル情報を含む構成ファイル (JSON と Markdown) によって定義されます。構成がゲームエンジンを駆動し、コードコンパイルなしで動的レンダリングを可能にします。ブラウザベースのアーキテクチャは Excalibur.js を使用します。つまり、ゲームは即座にロードされ、最新の Web ブラウザを備えた任意のデバイスで実行されます。 リアルタイム AI ストリーミング マルチエージェントシステムは、複数のタスクを同時に処理します。体験をスムーズでインタラクティブに保つために、進行状況の更新を発生時にストリーミングし、AI エージェントが複雑な決定をどのように推論するかを透明性を持って提供します。 WebSocket 実装 参加者は、AI エージェントの推論をリアルタイムで表示する視覚化を見ることができ、エージェントが選択をどのように分析し、一貫性を評価し、レコメンデーションを作成するかを示します。透明性は、開発者が独自のワークフローで AI システムを効果的にプロンプトしガイドする方法を理解するのに役立ちます。 Amazon API Gateway WebSocket API がフロントエンドとバックエンド間の通信を処理します。AWS Lambda が接続ライフサイクルを管理し、Amazon DynamoDB がセッション状態を保存し、バックエンドが AI モデルからの更新をリアルタイムでストリーミングします。 Amazon Bedrock Guardrails によるコンテンツ安全性 AI モデルは、時に機密性の高い、または不適切なコンテンツを生成することがあります。Agentic Arcade のすべてのプロンプトとモデル応答は、ユーザーに表示される前に Amazon Bedrock Guardrails を通じてルーティングされます。 多層安全戦略 ユーザーの選択は、自由形式のテキストではなく事前定義されたオプションに制限されており、リスクエクスポージャーを大幅に削減します。評価エージェントは、アセットがライブラリに入る前に品質と適切性を評価します。生成された各画像は、コンテンツ安全性を含む複数の基準に対して分析されます。システムは、複雑なフィードバックループではなくコンテンツモデレーションアプローチを使用し、ランタイム中の信頼性を確保します。 システムは、特定のコンポーネントのリアルタイム AI 生成と、アセットライブラリからインテリジェントに選択されたコンテンツのバランスを取ります。同期および非同期コンテンツガードレールの組み合わせ実装により、制御と応答性のバランスを取る、まとまったエンドユーザー体験が作成されます。 スタートガイド Agentic Arcade で使用されているすべての技術は、すぐに利用可能です。Amazon Bedrock AgentCore でマルチエージェントワークフローを試し、Amazon ECS にデプロイされた ComfyUI ワークフローでプログラマティックアセット生成を実験できます。Amazon S3 Vectors と Amazon Titan Embedding でベクトル類似性検索を今すぐ開始し、Entity Component System パターンを使用したモジュール式ゲームアーキテクチャで Amazon API Gateway WebSocket API を使用したリアルタイム AI ストリーミングを実装し、AWS Cloud Development Kit ( AWS CDK ) で完全なサーバーレスデプロイを完了できます。 新しいゲームコンセプトのプロトタイピング、プレースホルダーアセットの生成、ゲームプレイメカニクスの探索など、これらのパターンは、より速く反復し、ゲームをユニークにするものに集中するのに役立ちます。 Agentic Arcade デモに基づくサンプルゲーム仕様が、 GitHub リポジトリ で利用可能になりました。Kiro で、「3 つの敵タイプとシールドパワーアップを備えた縦スクロールシューティングを作成」のような簡単なプロンプトから、プレイ可能な縦スクロールシューティングゲームを生成できます。包括的な仕様が Kiro をゲームメカニクスと実装を通じてガイドし、数分でコンセプトをインタラクティブなプロトタイプに変換できます。 まとめ Agentic Arcade は、AI がゲーム開発をどのようにサポートできるかの根本的な変化を示しています。創造的な決定を置き換えるのではなく、コンセプト化をインタラクティブにし、検証を即座に行えるようにします。プロダクション前フェーズに洗練度とインタラクティブ性をもたらすことで、チームは大規模なエンジニアリングリソースを投入する前に、より適切な情報に基づいた創造的な決定を下せます。 紹介されたパターン (マルチエージェントオーケストレーション、プログラマティックアセット生成、セマンティック検索、モジュール式ゲームアーキテクチャ) は、実用的なアプローチを表しています。静的なアイデアを、開発サイクルの早い段階で探索、改善、検証できるインタラクティブなプロトタイプに変換できます。 ビジネスの加速を支援する方法については、 AWS 担当者 にお問い合わせください。 参考資料 AWS for Games The 2025 AWS Guide to Generative AI for Game Developers Generative AI-powered game design: Accelerating early development with Stability AI models on Amazon Bedrock 著者について Armando Vargas AWS のゲームバックエンドと AI 駆動型ソリューションに焦点を当てた Senior Specialist Solutions Architect です。ゲームとメディアのお客様が最新のゲームプレイサービスをアーキテクトおよびスケールし、開発と本番パイプラインに AI を導入してより良いプレイヤー体験を提供できるよう支援しています。 Stanford Lee Technical Account Manager であり、Amazon Web Services の Spatial Computing Technical Field Community の一員です。大企業のシニアテクノロジーリーダーシップに技術ガイダンスを提供しています。この役割で、お客様とのエンゲージメントをリードし、技術プロトタイプを構築し、イマーシブ 3D コンピューティングおよび拡張現実、仮想現実、拡張現実 (AR/VR/XR) 技術に関するソートリーダーシップを提供しています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。

本記事は 2026 年 1 月 30 日 に公開された「 GPU-Accelerated Robotic Simulation Training with NVIDIA Isaac Lab in VAMS 」を翻訳したものです。 オープンソースの Visual Asset Management System (VAMS) が、NVIDIA Isaac Lab との統合により、ロボットアセット向けの GPU アクセラレーション強化学習 (RL) に対応しました。このパイプラインでアセット管理ワークフローから直接 RL ポリシーのトレーニングと評価ができ、AWS Batch でスケーラブルな GPU コンピューティングを活用できます。 フィジカル AI とロボティクス開発のための Isaac Lab 図 1: NVIDIA Isaac Lab でトレーニングされた ANYmal シミュレーション 世界は自律経済に向かって進んでいます。この変革モデルは AI、ロボティクス、シミュレーション、エッジコンピューティングを統合し、人の介入を最小限に抑えて動作するシステムを実現します。この変革の中心にあるのがフィジカル AI です。これは物理世界を認識し、理解し、推論し、行動できるシステムを指します。 実世界でロボットをトレーニングするのは遅く、コストがかかり、危険を伴います。四足歩行ロボットが歩行を習得するには何千回も転倒する可能性があります。転倒するたびに数万ドルのハードウェアが損傷するリスクがあります。シミュレーションはこの状況を完全に変えます。 NVIDIA Isaac Lab は GPU アクセラレーション型ロボティクスシミュレーションの最先端技術です。Isaac Sim の高精度物理エンジン上に構築され、ポリシーの複雑さと GPU 仕様に応じて、単一の GPU 上で数千のロボットインスタンスを並列実行できます。実世界で数か月かかるトレーニングが数時間のシミュレーション時間に圧縮されます。1,000 万の環境ステップを必要とするポリシーを、数か月ではなく一晩でトレーニングできます。 その意義は大きいです: 高速な反復サイクル : 新しい報酬関数、ロボット設計、制御戦略を数週間ではなく数時間でテストできます 安全な探索 : ハードウェアを損傷することなく、ロボットが積極的な動作を学習し、失敗から回復できます 再現性 : シミュレーションは決定論的な環境を提供し、アルゴリズムの比較と改善の追跡が可能です スケール : 数百の実験を並列実行し、体系的なハイパーパラメータ探索が可能です しかし、この機能へのアクセスには従来、大きなインフラストラクチャの専門知識が必要でした。チームは GPU インスタンスのプロビジョニング、NVIDIA ドライバーの設定、コンテナイメージの管理、トレーニングインフラストラクチャとアセットリポジトリ間のデータ移動パイプラインの構築、アセット、トレーニング済みポリシー、データ設定のバージョン管理を行うカスタムソリューションの作成が必要でした。この運用オーバーヘッドがプロジェクトを遅らせたり、シミュレーショントレーニングを活用できる人を制限したりすることがよくありました。 Isaac Lab を VAMS に統合 図 2: Isaac Lab VAMS ワークフロー VAMS の Isaac Lab パイプラインアドオンはこのインフラストラクチャ負担を解消します。アセット管理システムと直接統合することで、ロボットモデルからトレーニング済みポリシーまでのシームレスなパスを作成します: アップロード : ロボットの URDF/USD ファイルとカスタム環境を VAMS にアップロードします 設定 : VAMS にアセットとしてアップロードされたシンプルな JSON ファイルでトレーニングパラメータを設定します 起動 : GPU コンピューティングを自動的にプロビジョニングするジョブを起動します 取得 : トレーニング済みポリシーを完全な系統追跡機能を備えたバージョン管理されたアセットとして取得します GPU インスタンス管理は不要です。コンテナオーケストレーションも不要です。手動のデータ転送も不要です。パイプラインがプロビジョニング、実行、クリーンアップを自動的に処理します。 この統合は、シミュレーショントレーニングが必要だが専任の MLOps リソースがないチームにとって特に価値があります。ロボティクスエンジニアはインフラストラクチャと格闘するのではなく、より優れたロボットと報酬関数の設計に集中できます。一方、組織は VAMS のアセット追跡機能を通じてトレーニング実験を一元的に把握できます。 課題: アセット管理とシミュレーションの橋渡し ロボットアセットを管理する組織は共通の課題に直面しています。3D モデル、USD ファイル、シミュレーション環境は 1 つのシステムにあり、トレーニングインフラストラクチャは別のシステムに存在します。データサイエンティストはシステム間でアセットを移動し、コンピューティングリソースを設定し、どのアセットでどのポリシーがトレーニングされたかを追跡するのに多くの時間を費やします。 VAMS の Isaac Lab パイプラインは、GPU アクセラレーション型シミュレーショントレーニングをアセット管理ワークフローに直接統合することでこれを解決します。ユーザーは VAMS から離れることなく、ロボットアセットを選択し、トレーニングパラメータを設定し、ジョブを起動できます。 アーキテクチャ概要 パイプラインは複数の AWS サービスを調整してシームレスなトレーニング体験を提供します: 図 3: Isaac Lab パイプラインリファレンスアーキテクチャ ユーザーがトレーニングジョブを送信すると、リクエストは Amazon API Gateway を経由して AWS Lambda 関数に流れ、 AWS Step Functions ワークフローを開始します。このワークフローはジョブ設定を構築し、 AWS Batch に送信し、非同期コールバックパターンで完了を待ちます。トレーニングコンテナは NVIDIA GPU を搭載した GPU インスタンス上で実行され、並列シミュレーションに必要なコンピューティングパワーを提供します。 主要なインフラストラクチャコンポーネント: AWS Batch コンピューティング環境 : GPU インスタンス (g6.2xlarge から g6e.12xlarge) 全体で自動スケーリングするコンテナ化環境 Amazon EFS : マルチノードジョブ全体でトレーニングチェックポイントを共有するストレージ Amazon ECR : Isaac Lab コンテナイメージをホストし、 AWS Cloud Development Kit (CDK) デプロイ時に自動的に構築されます AWS Step Functions : 適切なエラー処理とタイムアウトでワークフローを調整します Container Insights : Amazon Elastic Container Service (Amazon ECS) クラスターで有効化され、モニタリングと可観測性を提供します コンテナ自体は NVIDIA の公式 Isaac Lab イメージ (nvcr.io/nvidia/isaac-lab:2.3.0) 上に構築され、最新のシミュレーション機能との互換性を保証します。 デュアルモード動作: トレーニングと評価 パイプラインは RL 開発ライフサイクルの異なる段階に対応する 2 つの異なるモードをサポートします。 トレーニングモード トレーニングモードはゼロから新しいポリシーを作成します。ユーザーはシミュレーションタスク、並列環境の数、トレーニング反復回数を指定します。パイプラインは残りすべてを処理します。VAMS からカスタム環境をダウンロードし、トレーニングループを実行し、チェックポイントを保存し、トレーニング済みポリシーを VAMS にアップロードします。 典型的なトレーニング設定は次のようになります: { "name": "Ant Training Job", "description": "Train a PPO policy for the Isaac-Ant-Direct-v0 environment", "trainingConfig": { "mode": "train", "task": "Isaac-Ant-Direct-v0", "numEnvs": 4096, "maxIterations": 1000, "rlLibrary": "rsl_rl" }, "computeConfig": { "numNodes": 1 } } numEnvs パラメータは GPU 使用率を制御します。Isaac Lab は単一の GPU 上で数千のシミュレーションインスタンスを並列実行します。四足歩行タスクでは、4096 環境で通常良好な GPU 飽和度を達成します。 トレーニング出力は簡単に識別できるようジョブ UUID の下に整理されます: {uuid}/checkpoints/model_*.pt – 定期的な間隔でのモデルチェックポイント {uuid}/metrics.csv – TensorBoard からエクスポートされたトレーニングメトリクス {uuid}/training-config.json – 入力設定のコピー {uuid}/*.txt – ログファイル 評価モード トレーニング済みポリシーを取得したら、評価モードでパフォーマンスを評価できます。このモードは既存のポリシーをロードし、指定された数のエピソードを実行し、メトリクスを収集してビデオを記録します。 { "name": "Ant Evaluation Job", "description": "Evaluate a trained PPO policy for the Isaac-Ant-Direct-v0 environment", "trainingConfig": { "mode": "evaluate", "task": "Isaac-Ant-Direct-v0", "checkpointPath": "checkpoints/model_1000.pt", "numEnvs": 4, "numEpisodes": 5, "stepsPerEpisode": 900, "rlLibrary": "rsl_rl" }, "computeConfig": { "numNodes": 1 } } 評価では、目標がトレーニングスループットではなく評価であるため、並列環境を少なく (4096 ではなく 4) 使用します。 評価出力には以下が含まれます: {uuid}/videos/*.mp4 – 記録された評価ビデオ {uuid}/metrics.csv – 評価メトリクス {uuid}/evaluation-config.json – 入力設定のコピー Isaac Lab の play スクリプトが適切に終了するには –video フラグが必要なため、評価中は常にビデオが生成されます。 図 4: トレーニング済みポリシーからのビデオ評価出力 チェックポイント検出 パイプラインは評価用のチェックポイントファイルを指定する 3 つの方法をサポートします: 相対パス (推奨) : checkpointPath を使用して同じアセット内のチェックポイントを参照します (例: “checkpoints/model_300.pt”) 完全な S3 URI : policyS3Uri をアセット間または外部チェックポイントに使用します (例: “s3://bucket/path/model.pt”) 自動検出 : 評価設定と同じディレクトリに .pt ファイルを配置します (レガシー、下位互換性のため) VAMS を通じたジョブの実行 VAMS を通じて Isaac Lab トレーニングジョブを実行する前に、 VAMS のインストールと開始手順 に従って、VAMS ソリューションとデータベースをデプロイおよびセットアップしてください。 VAMS の準備ができたら、トレーニングジョブを実行する最も簡単な方法は VAMS Web アプリケーションを使用することです: 1. 実行予定のジョブタイプ (トレーニングまたは評価など) の設定 JSON を作成します。トレーニング設定 JSON の例: 1. { 2. "name": "ANYmal Training Job", 3. "description": "Train a PPO policy for the Isaac-Velocity-Rough-Anymal-D-v0 environment", 4. "trainingConfig": { 5. "mode": "train", 6. "task": " Isaac-Velocity-Rough-Anymal-D-v0", 7. "numEnvs": 2048, 8. "maxIterations": 3000, 9. "rlLibrary": "rsl_rl" 10. }, 11. "computeConfig": { 12. "numNodes": 1 13. } 14. } 2. Web UI を使用してトレーニング設定 JSON ファイルを VAMS にアップロードします: 図 5: Web UI でファイルをドラッグアンドドロップ 3. Workflows に移動し、Isaac Lab Training または Evaluation パイプラインを選択します 図 6: VAMS ワークフロータブ 4. Execute Workflow を選択します 5. Select Workflow ドロップダウンから isaaclab-training ワークフローを選択します 図 7: VAMS ワークフロー選択 6. Select File to Process ドロップダウンからトレーニング設定 JSON アセットを選択します 図 8: VAMS ワークフローファイル選択 7. Execute Workflow ボタンをクリックしてワークフローを送信します 図 9: Isaac Lab トレーニングジョブ用に設定された VAMS ワークフローモーダル VAMS は実行ステータスをリアルタイムで追跡します。完了すると、トレーニング済みポリシーが元のロボットアセットにリンクされた新しいアセットバージョンとして表示され、完全な系統が維持されます。トレーニングジョブの詳細については、管理者は Amazon CloudWatch でトレーニング出力ログを確認できます。 図 10: VAMS ファイルマネージャーのトレーニング済みポリシーアセット カスタム環境の使用 Isaac Lab には 40 以上の事前構築された環境が含まれていますが、多くのプロジェクトではカスタムタスクが必要です。VAMS は簡単なパッケージングワークフローでこれをサポートします。 まず、Isaac Lab のテンプレート構造に従ってカスタム環境を作成します: my_custom_env/ ├── setup.py ├── my_custom_env/ │ ├── __init__.py # Contains gym.register() call │ ├── my_env.py # Environment implementation │ └── my_env_cfg.py # Configuration classes └── agents/ └── rsl_rl_ppo_cfg.py tarball としてパッケージ化し、アセットとして VAMS にアップロードします: tar -czf my_custom_env.tar.gz my_custom_env/ # VAMS Web UI または API 経由でアップロード トレーニングジョブを送信する際、カスタム環境アセットを参照します。パイプラインはトレーニング開始前に自動的にダウンロードしてインストールします: { "trainingConfig": { "task": "MyCustom-Robot-v0", "numEnvs": 4096, "maxIterations": 5000 }, "customEnvironmentPath": "environments/my_custom_env.tar.gz" } パフォーマンスに関する考慮事項 インスタンスの選択 パイプラインは自動選択で複数の GPU インスタンスタイプをサポートします: パイプラインは BEST_FIT_PROGRESSIVE 割り当て戦略を使用し、価格とパフォーマンスのバランスが最適な G6 インスタンス (L4 GPU) を優先し、次に G6E (L40S)、フォールバックとして G5 (A10G) を使用します。 マルチノードトレーニング 最大規模の実験では、パイプラインは PyTorch の分散トレーニング (torchrun) によるマルチノード並列トレーニングをサポートします。コンピューティング設定で numNodes > 1 を設定します: { "computeConfig": { "numNodes": 4 } } パイプラインは AWS Batch のマルチノード並列ジョブ機能を通じてノード通信を自動的に設定します。チェックポイントは Amazon Elastic File System (Amazon EFS) 経由で共有され、すべてのノードが同期された状態を維持します。 Isaac Lab を使用した AWS Batch マルチノードトレーニングの詳細なガイドについては、AWS のこちらの ブログ を参照してください。 パイプラインの有効化 Isaac Lab パイプラインには VAMS で VPC モードを有効にする必要があります。VAMS 設定オプションの詳細については、 設定ガイド を確認してください。/infra/config/config.json にある VAMS 設定ファイルを更新します: { "app": { "useGlobalVpc": { "enabled": true, "addVpcEndpoints": true }, "pipelines": { "useIsaacLabTraining": { "enabled": true, "acceptNvidiaEula": true, "autoRegisterWithVAMS": true, "keepWarmInstance": false } } } } 重要 : NVIDIA ソフトウェアライセンス契約 に同意するには、acceptNvidiaEula: true を設定する必要があります。これを設定しないとデプロイは失敗します。 Isaac Lab パラメータを含むように設定ファイルを更新したら、標準の VAMS 手順 に従って Isaac Lab アドオンを含む VAMS ソリューションをデプロイできます。 デプロイは Isaac Lab コンテナを自動的に構築し、Amazon Elastic Container Registry (Amazon ECR) にプッシュします。最初の Batch ジョブは約 10GB のコンテナイメージをプルするのに 5〜10 分かかる場合があります。その後のジョブはインスタンスキャッシュにより高速に起動します。 コンテナ Pull 時間の最適化 ジョブの起動を高速化するには: ウォームインスタンスの維持 : keepWarmInstance: true を設定してインスタンスを実行状態に保ちます (最小 8 vCPU)。インスタンスをウォーム状態に保つとパイプラインの実行コストが増加します。この設定は指定された数の EC2 vCPU を実行状態に保ちます。 AMI の事前構築 : コンテナイメージを事前キャッシュしたカスタム AMI を作成します 大容量 EBS ボリューム : パイプラインは Docker レイヤーキャッシュを備えた 100GB GP3 EBS ボリュームを使用します 次のステップ Isaac Lab 統合はロボットアセットワークフローに新しい可能性を開きます。GPU アクセラレーション型シミュレーショントレーニングを VAMS に統合することで、チームはアセット、トレーニング実行、デプロイされたポリシー間の完全なトレーサビリティを維持しながら、ロボットの動作をより速く反復できます。Isaac Lab の高精度物理シミュレーションと VAMS のアセット管理機能の組み合わせは、ロボット AI 開発のための強力なプラットフォームを作成します。 始めましょう Isaac Lab パイプラインは VAMS 2.4.0 で利用できます。完全なソースコード、詳細なドキュメント、コスト見積もり、トラブルシューティングガイドは VAMS GitHub リポジトリ で入手できます。 著者について Kellan Cartledge AWS Prototyping and Cloud Engineering チームの Senior Prototyping Architect で、AI/ML、生成 AI、クラウドインフラストラクチャ、リアルタイムグラフィックス、没入型 AR/VR テクノロジー全体にわたる変革的ソリューションの設計と実装において 10 年以上の経験があります。複雑な課題を解決し、新しいテクノロジーで可能性の限界を押し広げるチームを支援することに情熱を注いでいます。 Kurt Scheuringer Amazon Web Services (AWS) の Spatial Computing 担当 Principal Prototyping Architect として、15 年以上の空間テクノロジーの専門知識を活かしています。AWS 入社前は、防衛産業でさまざまな製品ライフサイクルに携わり、ビジネス開発、エンジニアリング設計、製造、保守の経験を積みました。Florida Atlantic University でコンピュータサイエンスの修士号、University of Central Florida でエンジニアリングマネジメントの修士号を取得しています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。

本記事は 2025 年 12 月 2 日 に公開された「 Physical AI: Building the Next Foundation in Autonomous Intelligence 」を翻訳したものです。 はじめに 世界は自律型経済 (Autonomous Economy) に向かって動いています。AI、エッジコンピューティング、ロボティクス、空間インテリジェンス、シミュレーション技術が連携し、人の介入を最小限に抑えてシステムが自律的に動作する経済モデルです。フィジカル AI はこれらの技術の融合であり、コンピュータが物理世界を感知し、理解し、予測し、行動できるようにすることで、自律型経済への移行に大きな機会をもたらします ( https://www.linkedin.com/pulse/path-fully-autonomous-economies-andre-drpde/ )。フィジカル AI は自律運用へのパラダイムシフトを支え、純粋にデジタル環境で動作する従来の AI システムから、物理世界を知覚し、理解し、行動できるインテリジェントシステムへと進化させます。輸送 (自動運転車)、製造 (無人製造施設)、エネルギー (現場の人員を最小化し危険エリアの自動検査を実現)、ヘルスケア (低侵襲ロボット手術) など、あらゆる分野を変革しています。以前の ブログ で、AWS はフィジカル AI で実現できる自律性のレベルを説明する 4 段階のフィジカル AI ケイパビリティ・スペクトラムを提案しました。今回は、これらの自律性レベルを達成する方法のガイダンスを提供します。ヘルスケア向けの Diligent Robotics を取り上げた ブログ で実例を確認できます。 本記事では、自動化への道筋を描くための包括的なフィジカル AI フレームワークを説明します。フィジカル AI を抽象的な概念から、開発して技術開発ロードマップに統合できる実用的で具体的な機能に分解します。今日のユースケースに対応し、明日の課題を解決する準備を整えます。物理世界 (アトム) とデジタル世界 (ビット) をつなぐ継続的な学習ループを説明し、物理運用での自律性の開発を加速します。最後に、仮想世界でのフィジカル AI モデルトレーニングと物理世界でのリアルタイム自律運用の違いを明確にし、クラウドからエッジへのハイブリッドデプロイメントで両者がどのように接続されるかを説明します。本記事は、フィジカル AI フレームワークの各機能を深く掘り下げる複数回のブログシリーズの最初の導入記事です。 フィジカル AI の理解 AWS では、フィジカル AI を物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステムと定義しています。 フィジカル AI は人工知能のサブセットであり、時空間的な関係と世界の物理的性質の理解に焦点を当て、センサーとアクチュエータを通じて周囲の環境と相互作用します。画像、動画、テキスト、音声、深度/LiDAR、実世界のセンサーデータなどのマルチモーダル入力を処理し、洞察を導き出し、複雑で動的な環境で独立して動作できる自律システムでのリアルタイム意思決定を可能にします。たとえば、AI モデルは推論を使ってコーヒーを注ぐ方法を説明できますが、フィジカル AI モデルはまずコーヒーがどこにあり、カップに注ぐ必要があることを推論し、さらに物理世界への追加機能を拡張して、実世界の条件下でコーヒーを識別し、つかみ、持ち上げ、カップに注ぎます。 AWS のフィジカル AI フレームワーク フィジカル AI の可能性を完全に実現するには、自律システムのライフサイクル全体に対応する体系的なアプローチが必要です。図 1 に示す AWS フィジカル AI 概念フレームワークは、デジタルインテリジェンスと物理的アクションの間に継続的な学習サイクルを作り出す 6 つの相互接続された機能を通じて、この包括的な構造を提供します。これは、エンドツーエンドのフィジカル AI 技術スタックでカバーされる 6 つの機能領域にズームインしたもので、この ブログ でも取り上げられています。まず各機能を説明し、次にこれらの機能が仮想世界でのトレーニングループと物理世界での自律ループを構築・接続し、ハイブリッドクラウド-エッジデプロイメントを通じてどのように使用されるかを説明します。このように、フィジカル AI は将来の状態について推論し、複雑なアクションシーケンスを計画し、物理的能力を継続的に改善するシステムへの進化を表しています。 図 1: トレーニングループ、自律ループ、6 つの主要機能を示すフィジカル AI 継続的学習ループの図 1. 物理世界の接続とデジタル化 : フィジカル AI システムの基盤は、実世界の情報を取得してデジタル化する能力にあります。IoT デバイス、センサー、カメラ、その他の物理デバイスが物理環境からマルチモーダル状態データを収集します。LiDAR などの空間センサーは深度と体積データをマッピングし、地理空間データと衛星データは広大な物理エリアをマッピングし、温度、湿度、化学組成などのパラメータを監視するセンサーが使用されます。これらのさまざまなデータは、1D データストリーム、2D 画像、3D ポイントクラウド、センサーデータ、エンタープライズ運用技術 (OT) システムと資産管理システムからのメタデータを通じて、物理世界の包括的なデジタル表現を作成します。この豊富な感覚入力が、後続のすべての AI 処理の基盤となります。AWS では、 Amazon IoT SiteWise 、 Amazon IoT Core 、 Amazon Kinesis Video Streams など、 Industrial Data Fabric および Smart Machine ソリューションガイダンスの一部として使用できるサービスや、3D データ収集用の Matterport、Treedis、Prevu3D などのパートナーソリューションを提供しています。 2. データの保存と構造化 : フィジカル AI システムは二重経路アーキテクチャを採用しています。低レイテンシーのセンサーデータストリームは、ネットワークをバイパスしてエッジ ML モデルに直接送られ、リアルタイムオペレーティングシステム (RTOS) を使用して即座の反応制御を実現します。一方、より高レベルの推論タスクは、クラウド接続されたナレッジグラフとエンタープライズシステム統合 (ERP、CRM、LIMS、PLM) を活用して、複雑な計画と意思決定を可能にします。非構造化された多様なデータタイプを効率的に処理して相関付けできます。フィジカル AI システムで効果的にデータを管理するには、リアルタイム解析を維持しながら、複数のソースからの膨大な量の情報を処理する必要があります。高度なストレージアーキテクチャとデータ処理パイプラインにより、組織はこの複雑さを管理しながら、即座の意思決定と長期的な学習の両方に重要な情報を利用可能に保てます。AWS では、ストレージ用の Amazon S3 、 Amazon DynamoDB 、 Amazon Aurora などのサービスや、複雑な空間、IT、OT データを管理するための Spatial Data Management on AWS ソリューションを提供しています。 3. データのセグメント化と理解 : この段階では、変換、クリーニング、センサーストリームの時間的リサンプリングなどのデータ操作を処理し、動画、LiDAR、時系列データを構造化された 3D モデルと環境表現に変換してシミュレーションワークフローに情報を提供します。前処理と関係マッピングを通じて、生のマルチモーダル物理世界データを AI 対応の洞察に変換します。ナレッジグラフを通じて異なるマルチモーダルデータセット間のオントロジー関係を構築することが重要です。RAG 経由のメンテナンスマニュアルなどのデータを接続し、事前作成された 3D アセットをカタログ化し、空間、運用、時間データディメンション全体でセマンティック接続を確立できます。AWS サービスがこの変換を支えます。 AWS Glue は、マルチモーダルセンサーデータを処理して同期するための組み込みデータ変換パイプラインを備えたサーバーレス ETL 機能を提供し、 Amazon Neptune は、空間関係とアセットメタデータを構造化する高度なナレッジグラフとオントロジーを可能にし、自律システムが物理環境を理解して相互作用するために必要な基礎的なインテリジェンス層を作成します。産業検査レポート自動化のフレームワーク例については、この ブログ をご覧ください。 4. シミュレーション、トレーニング、モデル最適化 : シミュレーション環境は、実世界のリスクなしに自律システムをトレーニングするための安全で制御された空間を提供し、複数のユースケースにわたるフィジカル AI システムの開発をサポートします。これらの環境により、ニアエッジデプロイメントを対象としたモデル開発のための包括的なトレーニングが可能になり、AI システムは、現実でテストするのが非現実的または不可能な稀なケースや危険な状況を含む、無数のシナリオから学習できます。シミュレーション機能にはデジタルツインが含まれ、シミュレーションベースのトレーニングと仮想テスト、モデル開発用の合成データ生成、ML とハイブリッド AI + メカニスティックモデルの両方のトレーニングと調整、エッジデプロイメント用に最適化されたモデルの開発が含まれます。シミュレーション環境により、フィジカル AI モデルの反復的な最適化が可能になり、チームはエッジデプロイメント前に多様なシナリオ全体でパフォーマンスを検証しながら、知覚、意思決定、制御アルゴリズムを改良できます。シミュレーション機能は、基本的なデジタル表現から世界物理モデル (NVIDIA Omniverse、Unity、Unreal Engine、その他新興の WFM) まで、高忠実度エンジニアリングシミュレーション (数値流体力学、有限要素解析、熱力学プロセスモデリング) まで多岐にわたります。AWS で NVIDIA Cosmos world foundation model を実行する 例 をご覧ください。フィジカル AI モデルはデジタルツインで表現できる可能性があります。デジタルツインは複雑なトピックであり、 L1-L4 デジタルツインレベリングガイド と デジタルツインフレームワーク リファレンスアーキテクチャ を開発しました。AWS では、 AWS Batch 、 AWS ParallelCluster 、 AWS Parallel Computing Service 、 Amazon SageMaker 、 Amazon EKS/ECS など、モデルの構築、オーケストレーション、トレーニングのためのさまざまなサービスを提供しています。 5. 自律システムのデプロイと管理 : トレーニングと検証が完了したら、AI モデルとポリシーを堅牢な管理機能を備えた自律システムにデプロイする必要があります。この機能は、無線アップデート、エージェントポリシー管理、継続的なシステムアップデートを処理し、デプロイされたシステムが最新で、コンプライアンスに準拠し、効果的であることを保証します。デプロイフェーズでは、エッジコンピューティング機能、ローカライズされたインフラストラクチャ、ネットワーク接続、セキュリティ要件を慎重に検討する必要があります。システムは、中央管理システムから切断されている場合でも確実に動作し、アップデートを受信してステータス情報を報告する能力を維持する必要があります。 AWS IoT Greengrass は、自律システムへの AI モデルとアプリケーションの安全なデプロイと管理を可能にするコアエッジランタイムとして機能し、無線アップデート、ローカル処理機能、中央管理システムから切断されている場合でも確実に動作する能力をサポートします。 AWS IoT Device Management は、リモートデバイス監視、ポリシー管理、自動無線ファームウェアアップデートを含むフリート全体の運用を提供してこれを補完し、 AWS Systems Manager は、OS パッチ適用やアプリケーションデプロイメントなどのタスクのために、従来の IT インフラストラクチャと並んでエッジデバイスの一元管理を可能にします。さらに、 AWS IoT Core は、自律システムとクラウド間の安全な双方向通信を促進し、リアルタイムステータスレポートとポリシーアップデートを可能にし、 AWS Secrets Manager や IoT Device Defender などのサービスは、デプロイされた自律フリート全体で堅牢なセキュリティとコンプライアンス管理を保証します。 6. エッジ推論と運用 : 最後の機能は、インテリジェンスをエッジにもたらします。エッジベースのコンピューティングにより、低レイテンシーのデータ転送が可能になり、ネットワーク依存なしにアクチュエータとセンサーアレイを駆動するオンデバイスコンピューティングのリアルタイム分析が可能になります。フィジカル AI システムは、自動運転車の衝突回避や産業機器の緊急停止など、ミリ秒単位が重要でネットワーク接続に依存できない重要なアプリケーションに即座の応答を必要とします。エッジデバイスに高度な推論機能をデプロイすることは、モデルパフォーマンスの最適化、超低レイテンシー推論、信頼性の低い接続下での動作において大きな課題を提示し、リソース制約のあるエッジハードウェアで高度なフィジカル AI モデルを実現するための AWS の重要な投資領域となっています。AWS では、 AWS IoT Greengrass などのサービスを提供しており、クラウドから切断されている場合でも超低レイテンシーでローカル AI 推論を可能にし、 AWS Local Zones と AWS Outposts はクラウド機能をリモートロケーションに拡張し、ネットワーク依存を減らすために AI 処理がローカルで行われることを保証します。 フライホイール効果: 運用を通じた継続的な推論改善 フィジカル AI フレームワークが特に強力なのは、データ駆動型の改善ポテンシャルです。自律システムが実世界で動作すると、フィジカル AI モデルの改良に役立つ運用データが生成されます。強化されたモデルはより高性能な自律システムを可能にし、それがさらに追加のトレーニングデータを生成し、運用コストを削減しながら能力向上を推進できるフィードバックループを作り出します。この学習サイクルは、フィジカル AI システムが時間とともにより効果的になる可能性があることを意味しますが、改善の度合いは環境の性質と収集されるデータの品質に依存します。物理世界との各相互作用は、新しいトレーニングデータ、エッジケース、最適化の機会を提供します。フレームワークをうまく実装した組織は、戦略的なモデル管理と人間の監視を組み合わせることで、運用経験を蓄積するにつれて、システムがパフォーマンス、信頼性、効率の向上を示すことが期待できます。 デュアルループアーキテクチャ: クラウドとエッジの統合 フレームワークは、包括的なフィジカル AI 機能を提供するために連携して機能する 2 つの重要なループを通じて動作します。トレーニングループは主にクラウド環境で動作し、データ処理、AI モデルトレーニング、シミュレーション活動を処理します。計算能力、ストレージ容量、グローバルに分散されたネットワークインフラストラクチャを活用して、AI 機能を開発して改良します。自律ループは、リアルタイム運用と物理世界との相互作用に焦点を当て、通常、自律システムがデプロイされているエッジで動作します。速度、反復、信頼性を優先し、クラウドリソースへのネットワーク接続に依存せずに、システムが変化する条件に応答できることを保証します。2 つのループの統合により、組織はクラウドインフラストラクチャの計算上の利点とエッジデプロイメントの応答性要件の両方から恩恵を受けられます。データはクラウド環境とエッジ環境の間をシームレスに流れ、運用の信頼性を維持しながら学習と改善が継続的に行われることを保証します。 自律運用の安全なデプロイ セキュリティは AWS のフィジカル AI フレームワークの基盤を形成し、自律システムはデジタルから物理へのループのすべての段階で揺るぎない信頼と回復力を持って動作する必要があります。組織が物理システム、デジタルインテリジェンス、人間の監視の間の関係を調整する AI エージェントをデプロイする際、AWS はエッジからクラウドまで安全な自律運用を可能にするセキュリティフレームワークを提供します。フィジカル AI フレームワークは本質的に、初期センサーデータキャプチャと空間データ管理から、AI モデルトレーニングと物理ベースのシミュレーション、自律システムデプロイメントとリアルタイムエッジ推論運用まで、ワークフロー全体を通じてエンタープライズ統合とセキュリティコンプライアンスを優先する必要があります。安全/機密性の高い環境で動作したり人と相互作用したりすることが計画される自律システムには、プロプライエタリ/非公開のデータと環境、個人を特定できる情報 (PII) などのセキュリティ考慮事項が必要です。AWS のセキュリティ体制は、マルチモーダルデータフローの保護、フィジカル AI モデルの AI トレーニングパイプラインの保護、デジタルツインの安全な運用の保証、物理システムとデジタルブレイン間の安全な接続ループ (オプションの転送中暗号化と保管時暗号化を含む) によってフィジカル AI に適用されます。セキュリティファーストのアプローチにより、顧客は最高水準のデータ保護、アクセス制御、運用整合性を維持しながら、物理世界を知覚し、理解し、行動できる自律システムを自信を持って開発でき、最終的に企業が最も重要な資産と運用を保護しながらフィジカル AI の変革的な可能性を実現できます。 自律型経済の構築 フィジカル AI フレームワークは、組織に自律運用への道のりのロードマップを提供し、新興の自律型経済に貢献して恩恵を受けるのを支援します。初期データ収集から継続的な運用と改善まで、自律システムの完全なライフサイクルに対応するアプローチを実装することで、組織はそれぞれの領域で持続可能な競争優位性を開発できます。 フィジカル AI での成功には、個々の技術をデプロイするだけでなく、感知、処理、学習、アクションを、複雑な環境で独立して動作できる一貫したシステムに統合する体系的なアプローチが必要です。本記事で概説したフレームワークは、安全な自律運用、スケーラビリティ、信頼性、継続的な改善を保証しながら、統合を実現するために必要な構造を提供します。 まとめ AWS のフィジカル AI フレームワークは、組織がデジタル世界と物理世界を橋渡しする自律システムを安全に構築してデプロイする方法の根本的な変化を表しています。物理世界の接続とデジタル化からエッジ推論と運用まで、6 つの相互接続された機能を統合することで、このフレームワークは、実世界の運用データがますます高性能な AI モデルを推進する継続的な改善フライホイールを作り出します。クラウドベースのトレーニングとエッジベースの自律性を組み合わせたデュアルループアーキテクチャにより、組織は人の介入を最小限に抑えながら、複雑な物理環境を理解し、推論し、行動できるシステムを開発できます。製造、輸送、エネルギー、ヘルスケアなどの業界をすでに変革しており、インテリジェントシステムが継続的に学習して改善しながら独立して動作する新興の自律型経済を推進しています。補完的なポッドキャストをご覧ください: Physical AI: Teaching Machines to Act, Not Just Think 。 フィジカル AI が運用をどのように変革できるかを探る準備はできていますか? フィジカル AI フレームワークの各機能を深く掘り下げ、詳細な技術ガイダンス、リファレンスアーキテクチャ、実際の顧客事例を共有する今後の 6 部構成のブログシリーズにご参加ください。自律システムの旅を始めたばかりでも、既存のデプロイメントをスケールしようとしている場合でも、フィジカル AI スペシャリストに連絡して、特定のユースケースについて話し合い、AWS が自律型経済への参加をどのように支援できるかをご確認ください。 著者について David Randle AWS でフィジカル AI の GTM をリードしています。デジタル世界と物理世界を橋渡しする自律システムを実現する AWS の戦略的イニシアチブを担当しています。3D 技術とリアルタイムシステムで 19 年以上の経験を持ち、Dassault Systèmes SolidWorks に買収される前の Bunkspeed でリアルタイムレンダリングの普及に貢献しました。自律運用の基盤となるデジタルツインワークフローと仮想シミュレーションシステムのバックグラウンドに、ビジネスと工業デザインの知見を組み合わせ、変革的な技術をヒューマナイズして明確にしています。これらの経験により、AI を活用したシステムが物理環境をどのように知覚し、理解し、行動する必要があるかについて深い理解を持っています。 Adam Rasheed AWS の Emerging Technology (Advanced Computing) 部門の責任者として、エンジニアリング向けの Agentic AI と自律システムを実現するフィジカル AI の限界を押し広げるチームをリードしています。産業領域とデジタル領域の両方にまたがる中期段階の技術開発で 28 年以上の経験があり、航空、エネルギー、石油・ガス、再生可能エネルギー業界でデジタルツインを 10 年以上開発してきました。Caltech で実験的超高速空気熱力学 (軌道再突入加熱) を研究し博士号を取得しました。MIT Technology Review Magazine から「世界のトップ 35 イノベーター」の 1 人に選ばれ、AIAA Lawrence Sperry Award も受賞しました。産業分析、運用最適化、人工リフト、パルスデトネーション、極超音速、衝撃波誘起混合、宇宙医学、イノベーションフレームワークに関する 32 件以上の特許と 125 件以上の技術出版物があります。 Dan Cotting AWS で Worldwide フィジカル AI Specialist Solutions Architect チームをリードし、この領域の技術リーダーとして、フィールドでの AWS のフィジカル AI アーキテクチャ戦略の開発を支援しています。顧客とパートナーと直接協力して、空間インテリジェンス、シミュレーションとトレーニング、エッジインテリジェンスのユースケースにまたがるフィジカル AI ワークロードを AWS でスケールして成長させています。過去 9 年間、BMW、NVIDIA、ExxonMobil、Koch Industries、Siemens などの顧客やパートナーと協力しながら、自動車、製造、エネルギー、ヘルスケア、航空宇宙業界全体で空間コンピューティングとフィジカル AI を専門としてきました。AI、IoT、空間コンピューティング、シミュレーション、エッジ技術の融合を通じて自律運用を実現することに焦点を当てています。AWS に入社する前は、Magic Leap、Shockoe、Team One で多くの業界のエンタープライズ顧客に空間アプリケーションを提供していました。Virginia Commonwealth University で修士号、Boston University で学士号を取得しています。妻と息子とシアトルに住んでいます。 Ross Pivovar 物理シミュレーションと機械学習の両方のための数値的および統計的手法開発で 15 年以上の経験があります。AWS の Senior Solutions Architect として、自己学習デジタルツイン、マルチエージェントシミュレーション、物理 ML サロゲートモデリングの開発に焦点を当てています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。

本記事は 2026 年 1 月 20 日 に公開された「 Using the shared plan cache for Amazon Aurora PostgreSQL 」を翻訳したものです。 本記事では、 Amazon Aurora PostgreSQL 互換エディション の共有プランキャッシュ機能により、高い同時実行性環境で汎用 SQL プランのメモリ消費を大幅に削減できることを説明します。40GB のメモリ負荷を 400MB まで削減できます。 Aurora PostgreSQL データベースクラスターが数千の同時接続を処理し、それぞれが同じ プリペアドステートメント を実行している状況を想像してください。クエリ自体はシンプルなのに、メモリ使用量が数十 GB まで増加しています。何が起きているのでしょうか。これはプランの重複による隠れたコストが発生している可能性があり、共有プランキャッシュで解決できます。 PostgreSQL の汎用プランを理解する プリペアドステートメントは、アプリケーションで (データベースとやり取りする関数やメソッドを定義する際に) 一般的に使われます 。これらのステートメントは、データベースアクセスコードやメソッドに含まれます。準備フェーズには SQL ステートメントの構造とプレースホルダーが含まれ、アプリケーションがプリペアドステートメントを実行する際に実際の値が入ります。準備フェーズでステートメントが解析、分析、書き換えられるため、実行時の解析と分析作業の繰り返しが省けます。 ソリューションに入る前に、PostgreSQL がプリペアドステートメントをどう扱うかを理解しましょう。PostgreSQL と Aurora PostgreSQL では、プリペアドステートメントは 2 種類のプランで実行できます。 カスタムプラン: 実行ごとに特定のパラメータ値で新しく作成され、リテラルが含まれます。 汎用プラン: パラメータに依存しないプランで、実行間で再利用され、リテラルは含まれません。 デフォルトでは、PostgreSQL はこれら 2 つのプランタイプの選択にインテリジェントなアプローチを用います。 プリペアドステートメントの最初の 5 回の実行ではカスタムプランを使用 これらのカスタムプランの平均コストを計算 6 回目の実行で汎用プランを作成 汎用プランのコストがカスタムプランの平均コストと同等かそれ以下なら、以降の実行で使用 このアプローチは頻繁に実行されるクエリのプラン作成時間を節約できますが、多数の同時データベース接続がある環境では隠れたコストが発生します。 問題: 大規模環境でのメモリ非効率 このアプローチは個々の接続ではうまく機能しますが、多数の同時データベース接続がある環境では 2 つの大きな非効率が生じます。 不要なプラン生成: 汎用プランが使われない場合 (カスタムプランの方が効率的なため) でも、コスト比較のためにシステムは汎用プランを作成してメモリに保存します。たとえば、パーティションテーブルでは、コストがリーフパーティションごとに計算されて合計されるため、汎用プランが使われない可能性が高くなります。 プランの重複: 同じクエリが数百または数千のセッションで実行される場合、各セッションが同一の汎用プランのコピーを保持し、大量のメモリ重複が発生します。 この問題を具体例で示してみましょう。 テスト環境のセットアップ この例では、新しいセッションで各 1000 パーティションを持つテーブル t1 と t2 を作成します。次に、各ループで 1000 個の値を挿入する処理を 100 回ループし、各テーブルに 100,000 行を挿入します。最後に両方のテーブルの統計情報を更新します。 注意: 共有プランキャッシュ機能を使うには、Aurora PostgreSQL バージョン 17.6 以降、またはバージョン 16.10 以降を使用する必要があります。 -- Create partitioned tables CREATE TABLE t1(part_key int, c1 int) PARTITION BY RANGE(part_key); CREATE TABLE t2(part_key int, c1 int) PARTITION BY RANGE(part_key); \pset pager -- Generate 1000 partitions for each table (simulating large-scale partitioning) SELECT 'CREATE TABLE t1_' || x || ' PARTITION OF t1 FOR VALUES FROM (' || x || ') TO (' || x+1 || ')' FROM generate_series(1, 1000) x; \gexec SELECT 'CREATE TABLE t2_' || x || ' PARTITION OF t2 FOR VALUES FROM (' || x || ') TO (' || x+1 || ')' FROM generate_series(1, 1000) x; \gexec -- Populate tables with sample data DO $do$ BEGIN FOR i IN 1..100 LOOP INSERT INTO t1 SELECT x, i FROM generate_series(1, 1000) x; INSERT INTO t2 SELECT x, i FROM generate_series(1, 1000) x; END LOOP; END $do$; -- Update statistics for optimal query planning ANALYZE t1, t2; \gexec スイッチを使って、select の出力を独立した SQL ステートメントとして実行できます。\pset pager で psql pager を無効にすると、テーブルパーティション作成時に何度も Enter を押す必要がなくなります。 メモリ消費の観察 Session 1 で、次のプリペアドステートメントを作成して実行します。 -- Create a prepared statement with a simple join PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times to trigger generic plan creation EXECUTE p2(1, 4); -- Execution 1: Custom plan EXECUTE p2(1, 4); -- Execution 2: Custom plan EXECUTE p2(1, 4); -- Execution 3: Custom plan EXECUTE p2(1, 4); -- Execution 4: Custom plan EXECUTE p2(1, 4); -- Execution 5: Custom plan EXECUTE p2(1, 4); -- Execution 6: Generic plan created 次に、メモリ消費を確認します。 -- Check memory usage for cached plans SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; -[ RECORD 1 ]-+--------------------------------------- name | CachedPlan ident | prepare p2(int, int) as + | select sum(t1.c1) + | from t1, t2 + | where t1.part_key = t2.part_key and + | t1.c1 = $1 and t1.part_key = $2; size | 4161 kB このテストでは、汎用プランが約 4MB を消費し、プリペアドステートメントが解放されるか接続が終了するまでメモリに残ることがわかります。 重複の問題 次に、別のセッション ( Session 2 ) で同じプリペアドステートメントを実行します。 -- Session 2: Using the same prepared statement PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); -- Check memory usage SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; -[ RECORD 1 ]-+--------------------------------------- name | CachedPlan ident | prepare p2(int, int) as + | select sum(t1.c1) + | from t1, t2 + | where t1.part_key = t2.part_key and + | t1.c1 = $1 and t1.part_key = $2; size | 4161 kB Session 2 も全く同じ汎用プランで 4MB を消費しています! 乗算効果 この重複は、プリペアドステートメントを実行するすべてのセッションで発生します。影響を計算してみましょう。 1 プリペアドステートメント × 100 接続 × 4MB = 400MB のメモリ 100 種類のプリペアドステートメント × 100 接続 × 4MB = 40GB のメモリ この大量のメモリ消費は、セッションが同一の汎用プランのコピーを保存しているにもかかわらず発生します。多数の同時データベース接続がある環境では、利用可能なメモリをすぐに使い果たし、より大きく高価なインスタンスタイプを使わざるを得なくなります。 ソリューション: Aurora PostgreSQL 共有キャッシュプラン Aurora PostgreSQL は共有キャッシュプラン (SPC) でこの問題を解決します。各汎用プランのコピーを 1 つだけ保持し、複数セッションが使えるようにします。プランキャッシュのパフォーマンス上の利点を維持しながら、メモリ消費を大幅に削減します。 共有プランキャッシュ (SPC) は、 クラスターまたはインスタンスパラメータグループ で有効にできます。 apg_shared_plan_cache.enable = ON apg_shared_plan_cache.enable は動的パラメータであるため、変更を有効にするためにインスタンスを再起動する必要はありません。 SPC は動的ハッシュテーブルとして実装され、セッション間で共有されます。キャッシュ内のエントリ数は apg_shared_plan_cache.max で制御できます。次のパラメータでエントリの最小サイズと最大サイズも制御できます。 apg_shared_plan_cache.min_size_per_entry apg_shared_plan_cache.max_size_per_entry 共有プランキャッシュの動作デモ 共有プランキャッシュを有効にして、先ほどの実験を繰り返してみましょう。 Session 1 (最初の接続): -- Create and execute the same prepared statement PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); -- Check memory usage SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; 最初のセッションは、ローカルメモリに 4MB のプランが表示されます (共有キャッシュに入力するために必要)。 Session 2 (後続の接続): -- Create the same prepared statement PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); -- Check memory usage SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; (0 rows) ローカルプランストレージなし! 2 番目のセッションは共有プランキャッシュを使っています。 キャッシュ使用状況の監視 次の SQL を実行して、キャッシュに保存された個々の共有プランが受け取ったキャッシュヒット数を表示します。各ヒットは、セッションメモリで重複する必要がなかったプランを表します。 -- View shared plan cache statistics SELECT cache_key, query, hits FROM apg_shared_plan_cache(); -[ RECORD 1 ]------------------------------------- cache_key | -5127257242415815179 query | prepare p2(int, int) as + | select sum(t1.c1) + | from t1, t2 + | where t1.part_key = t2.part_key and + | t1.c1 = $1 and t1.part_key = $2; hits | 2 クリーンアップ: -- clear the cache SELECT * FROM apg_shared_plan_cache_reset(); -- drop the tables DROP TABLE t1; DROP TABLE t2; パフォーマンスへの影響 100 接続で 100 種類のプリペアドステートメントを使う先のシナリオ例では、40GB の重複プランストレージからわずか 400MB の共有キャッシュに変換されました。以下のスクリーンショットは、 apg_shared_plan_cache.enable = off で 100 接続で 100 種類のプリペアドステートメント (上記の例から使用) を使って pgbench でテストを実行したインスタンスから取得した Freeable Memory CloudWatch メトリックのグラフです。02:05 から 02:10 の間に、FreeableMemory が約 40GB 減少しています。これは予想される重複プランストレージのフットプリントと一致します。共有プランキャッシュを有効にして同じテストを再度実行すると、メモリへの影響は大幅に削減され、40GB ではなくわずかなメモリしか必要としませんでした。 この削減により、次のことが可能になります。 同じワークロードをより小さいインスタンスで実行 し、AWS コストを大幅に削減 メモリ制限に達することなく より多くの同時接続をサポート トラフィックスパイク時の メモリ不足エラーを回避 ベストプラクティス この機能は次の場合に特に有益です。 アプリケーションが数百または数千のデータベース接続を維持している プリペアドステートメントを多用している クエリにパーティションテーブルや複雑な演算子 (join や共通テーブル式など) が含まれ、大きなプランが生成される バックエンドプロセスからの高いメモリ使用量が観察される ワークロードに、パラメータ化されたクエリを使用した反復的なクエリパターンがある 共有キャッシュプランは大きな利点を提供しますが、次のシナリオには適さない場合があります。 一意性が高いアドホッククエリを用いるワークロード プリペアドステートメントをほとんど再利用しないアプリケーション 同時接続が少ない環境 まとめ 本記事では、Aurora PostgreSQL で共有キャッシュプランを有効にする方法を説明しました。多数の同時データベースセッションでプリペアドステートメントを使用する際に、同じ汎用クエリプランがメモリに重複して保存されるのを防げることを示しました。 セッション間で冗長なプランストレージを削除することで、より小さいインスタンスでより多くの接続を実行でき、運用の複雑さとコストの両方を削減できます。さまざまなプランタイプの詳細については PostgreSQL ドキュメントの the prepare statement を、空きメモリ測定の詳細については Amazon CloudWatch metrics for Amazon Aurora を参照してください。 著者について Souvik Bhattacherjee Souvik は AWS の Senior Software Engineer で、Aurora PostgreSQL データベースのクエリ処理機能の向上に取り組んでいます注。データベース/HPC 業界で 8 年以上の経験があり、データベースシステムと高性能コンピューティングシステムに関連するトピックに貢献してきました。 Jungkook Lee Jungkook は AWS の Senior Software Development Engineer で、Aurora PostgreSQL のパフォーマンス向上と機能拡張に注力するチームをリードしています。データベースシステムと分散コンピューティングアーキテクチャで 10 年以上の経験があり、クエリ最適化とデータベースパフォーマンスを専門としています。 Stephen Wood Stephen は AWS の Senior Specialist Database Solutions Architect です。Amazon RDS PostgreSQL、Amazon Aurora PostgreSQL、Amazon Aurora DSQL を専門としています。過去 24 年間、さまざまなタイプの企業でデータベースシステムに関わっており、常に新しいデータベーステクノロジーに取り組むことを楽しんでいます。 翻訳は Technical Account Manager の石渡が担当しました。

本稿は、2025 年 11 月 19 日に Networking & Content Delivery で公開された “ AWS PrivateLink extends cross-region connectivity to AWS services ” を翻訳したものです。 AWS は、 AWS PrivateLink が AWS のサービスへのクロスリージョン接続をサポート開始 を発表しました。今回のアップデートによってインターフェイス VPC エンドポイントを使用して、他の商用リージョンにある AWS サービスに対してプライベートかつ安全に接続できるようになりました。この記事では、クロスリージョンプライベート接続の潜在的なユースケースや利用方法、アクセス制御の方法について説明します。 概要 AWS PrivateLink は、セキュアかつシンプルな方法で VPC 間やアカウント間でサービスの共有やアクセス性を提供するサービスです。インターネットゲートウェイなしでプライベートサブネットから VPC エンドポイントサービス にアクセスでき、トラフィックは AWS のバックボーンネットワークのみを流れます。また、セキュリティグループや VPC エンドポイントポリシーを用いたエンドポイント保護も可能です。 以前の PrivateLink は同一のリージョン内での接続のみをサポートしており、サービスプロバイダーとサービス利用者は同一の AWS リージョン内に存在する必要がありました。re:Invent 2024 では、新たに ユーザ管理の VPC エンドポイントサービスへのクロスリージョンでのプライベート接続のサポート を開始しました。 今回の発表により、PrivateLink のクロスリージョン接続機能は AWS 商用リージョン内において Amazon が提供するマネージドサービスにまでサポート対象を拡張しました。これにより、VPC ピアリングなどによるリージョン間接続の管理やインターネットを介した接続を必要とせず、インターフェースエンドポイント経由で PrivateLink のクロスリージョン接続をサポートする他リージョンでホストされているサービスにネイティブにアクセスできるようになりました。この機能はエンドポイントポリシーをサポートしており、クロスリージョン接続が組織のポリシーを満たすことを保証する新たなアクセス制御を提供するとともに、データに対するリージョン単位の制御を簡素化します。 ユースケース この機能により、PrivateLink のシンプルさとセキュリティという中核的な利点が、リージョン内接続からリージョン間接続へと拡張されます。同一リージョン内の VPC エンドポイントサービスにアクセスする場合でも、別のリージョン内のサービスにアクセスする場合でも、実装とセキュリティは一貫して維持できます。ほとんどの AWS サービスはすべてのリージョンで利用可能ですが、以下のようなユースケースでは異なるリージョンのサービスにアクセスしたい場合があります： サードパーティプロバイダーが共有する別のリージョンにあるリソースにアクセスする必要がある場合。たとえば、社内外のさまざまなデータセットでトレーニングされたモデリングツールをバージニア北部リージョンで構築しているとします。このモデルがデータアグリゲーターの1社が提供するデータセットにアクセスする必要があり、そのデータセットはアフリカリージョンにある Amazon Simple Storage Service (Amazon S3) バケット経由で提供されている。 データレジデンシー要件が厳格な国で事業を展開する多国籍金融企業である場合。当該国内の消費者データは全て国内の AWS リージョンに保存する必要があるが、別のリージョンでホストされている外国為替ワークフローが取引承認のために国内に保存されたユーザーメタデータへの一時的なアクセスが必要。 グローバルに分散したインフラを持つ SaaS プロバイダーであり、監視データをアイルランドリージョンにある中央データレイクにストリーミングしたいと考えている場合。監視データはグローバルヘルス監視のためにほぼリアルタイムのダッシュボードを動作させるために疎通性が必要。 オレゴンリージョンに重要なワークロードがあり、Amazon Data Firehose への途切れないコネクションが必要な場合。プライマリ VPCE をオレゴンリージョンの Firehose に、セカンダリ VPCE をオハイオリージョンの Firehose に接続。オレゴンリージョンで接続問題が発生した場合に備え、ワークロードはオハイオリージョンにフェイルオーバーするよう構成されている。 クロスリージョンアクセスの制御 クロスリージョン接続機能を使い始める前に、適切な権限があることを確認する必要があります。 [必須] リージョン間の PrivateLink 接続機能を選択する : これまで、すべての PrivateLink アクション は Amazon Elastic Compute Cloud（EC2） の名前空間に含まれていました。クロスリージョン接続機能に関しては、異なる VPCE 名前空間での vpce:AllowMultiregion 権限のみのアクションによって制限されます。この許可がないと、ローカルリージョンのAWSサービスにはVPCエンドポイントを作成できますが、他のリージョンの AWS または VPCE サービスには作成できません。 アイデンティティポリシーで vpce:AllowMultiregion が許可されていることと、 サービスコントロールポリシー (SCP) で拒否されていないことを確認してください。クロスリージョン接続機能を有効にするには、両方のポリシーを正しく設定する必要があります。 [必須]リージョンのオプトイン : AWS アカウントではほとんどのリージョンがデフォルトで有効になっていますが、2019 年 3 月 20 日以降に開始されたリージョンは、手動で選択した場合にのみアクティブ化されます。AWS はこれらを オプトインリージョン と呼んでいます。オプトインリージョンでホストされている AWS サービスに PrivateLink 経由でアクセスする場合は、まずそのリージョンにオプトインする必要があります。このガードレールは、アカウントで許可されていない地域への誤ったアクセスや地域からのアクセスを防ぐのに役立ちます。 開始方法 サービスディスカバリー 必要な権限を構成した後、 AWS Management Console を使用して、クロスリージョン接続をサポートできる AWS サービスを検出します。図1のように VPC コンソール に移動し、ナビゲーションペインでエンドポイントを選択し、エンドポイントの作成をクリックします。 ＜図１ VPC Endpoint 作成のための AWS コンソール＞ 項目“ タイプ ”内で「AWSサービス」を選択し、次に「 クロスリージョンエンドポイントを有効にする 」のチェックボックスを有効にします。これで、ドロップダウンメニューから接続したいサービスリージョンを選択できるようになります。 サービスタブには、図２のようにクロスリージョン PrivateLink 接続機能でサポートされているすべてのAWSサービスが表示されます。 ＜図２ クロスリージョンプライベートリンク作成時の AWS コンソール UI＞ CLI を使用してサービスを検出するには、アクセスしたいリージョンに service-region フィルターを設定して describe-vpc-endpoint-services コマンドを使用します。次の例では、オレゴンリージョンの VPC エンドポイント経由でアクセスできるオハイオリージョンのすべての AWS サービスをリストします。 aws ec2 describe-vpc-endpoint-services \ --filters Name=service-type,Values=Interface Name=owner,Values=amazon \ --region us-west-2 \ --service-region us-east-2 \ --query ServiceNames インターフェースエンドポイントの作成 インターフェースエンドポイントを作成する残りの手順は、リージョン内およびクロスリージョン対応サービスで同じです。コンソールから必要なサービス名を選択し、VPC、サブネット、その他の構成オプションを選択します。最後に、エンドポイントの作成をクリックします。エンドポイントのステータスが利用可能になると、セットアップが完了し、インターフェースエンドポイント経由でリモート AWS サービスにアクセスできるようになります。 ＜図３ 作成された S3用のクロスリージョンプライベートリンクエンドポイント＞ CLI を通じてオレゴンリージョンの VPC からオハイオリージョンの S3 へのエンドポイントを作成するには、次の例を使用できます。 aws ec2 create-vpc-endpoint \ --vpc-id <vpc-id> \ --service-name com.amazonaws.us-east-2.s3 \ --vpc-endpoint-type Interface \ --subnet-ids <subnet-id-1> <subnet-id-2> \ --region us-west-2 \ --service-region us-east-2 デフォルトでは、AWS サービスへのすべてのインターフェースエンドポイントでプライベート DNS が有効になっています。これにより、パブリックエンドポイントの DNS 構文を保持することで、パブリックからプライベート接続への移行が簡素化されます。エンドポイントに関連付けられた DNS 名を確認するには、図４のように VPC エンドポイント ID をクリックし、 詳細 タブで DNS 名を確認します。 ＜図４ クロスリージョンプライベートリンクのための DNS 名＞ クロスリージョンアクセスの追加制御 PrivateLink は、使用がロールの権限と組織のポリシーに準拠することを保証するための複数の制御レイヤーを提供します。これらの制御を使用して、信頼できるエンティティのみが、許可されたサービスとリージョンに対して PrivateLink アクションを実行できるようにすることができます。前述の必須制御に加えて、以下のキーはクロスリージョン接続に特化した拡張機能を提供します。 [オプション] アクセスできるリージョンを定義する： コンシューマーとして、 ec2:VpceServiceRegion キーは、エンドポイントを通じてアクセスできるリモートサービスリージョンを定義するのに役立ちます。例えば、このアイデンティティポリシーは、東京リージョンまたはアイルランドリージョンでホストされているサービスへの VPC エンドポイントの作成と削除のみを許可します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "limitserviceregions", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoint”, "vpce:AllowMultiRegion" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringLike": { "ec2:VpceServiceRegion": [ "ap-northeast-1", "eu-west-1" ] } } } ] } [オプション] AWS リソースにアクセスできるリージョンを定義する： リソース所有者として、リソースポリシーを使用してデータ境界を確立できます。これにより、どのリソースに、誰が、どのネットワーク経由でアクセスできるかを制限できます。 aws:VpceAccount や aws:VpceOrgID などのキーを引き続き使用できますが、新しい aws:SourceVpcArn キーは、VPC エンドポイント経由でリソースにアクセスする際のリージョンベースのアクセス制御の実装に役立ちます。クロスリージョン VPC エンドポイント経由でアクセス可能なすべての AWS サービスがこのキーをサポートしています。このキーを使用して、VPC エンドポイント経由でリソースにアクセスできるリージョンを定義できます。アカウントと VPC ID を含めて、ポリシーをより細かくまたは粗くすることもできます。詳細とサポートされているサービスについては、IAM に関するガイドを参照してください。例えば、このリソースポリシーは、ロンドンリージョンの指定されたアカウントと VPC の VPC エンドポイントから接続が発信されない限り、S3 バケットへのすべてのアクセスを拒否します。 { "Version":"2012-10-17", "Statement": [ { "Sid": "AccessToSpecificVpcOnly", "Principal": "*", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1", "arn:aws:s3:::amzn-s3-demo-bucket1/*" ], "Condition": { "ArnNotLike": { "aws:SourceVpcArn": "arn:aws:ec2:eu-west-2:<Account-Id>:vpc/<VPC-Id>" } } } ] } 考慮事項とベストプラクティス 耐障害性と高可用性のために、最低2つのアベイラビリティゾーン（AZ）に VPC エンドポイントを作成することをお勧めします。これにより、コンシューマーとサービスリージョンの両方で AZ 間の PrivateLink マネージドなフェイルオーバーが可能になります。リージョン内接続とは異なり、別のリージョンの VPCE サービスにアクセスする場合、 AZ を一致させる必要はありません。リモート VPCE サービスへのインターフェースエンドポイントは、必要な任意の数の AZ に作成できます。 他のリージョンの AWS サービスへのクロスリージョン接続は、ゾーン DNS をサポートしていません。これらのエンドポイントにはリージョナル DNS レコードのみが生成されます。これは耐障害性に関するガイダンスと沿っており、エンドポイントが PrivateLink マネージドなフェイルオーバー機能の恩恵を受けることを保証します。 クロスリージョン接続はインターフェースエンドポイントのみでサポートされています。ゲートウェイ、ゲートウェイロードバランサー、リソースエンドポイントタイプはクロスリージョン接続をサポートしていません。 執筆時点で、この機能は Amazon S3 、 AWS Identity and Access Management（IAM） 、 Amazon Elastic Container Registry（ECR） 、 Amazon Data Firehose などのサービスをサポートしており、今後さらに多くのサービスが追加される予定です。サポートされているサービスの最新リストについては、 PrivateLink のユーザーガイド を参照するか、このブログで説明されているサービスディスカバリー手順に従ってください。 PrivateLink は AWS Fault Injection Service（FIS） と統合されており、リージョン内およびクロスリージョン対応インターフェースエンドポイントのリージョナルイベントをシミュレートし、障害シナリオをモデル化できます。詳細については、 AWS FIS のドキュメント を参照してください。 PrivateLink の標準料金（時間とデータ処理）が、ローカルリージョンまたはリモートリージョンのサービスへのすべてのインターフェースエンドポイントに適用されます。さらに、データ転送の方向性に関係なく、 リージョン間で転送されるギガバイトごとに標準のEC2リージョン間データ転送料金 をインターフェースエンドポイント所有者に請求します。詳細については、 PrivateLink 料金ページ をご覧ください。 まとめ リージョナル分離と耐障害性の確保ために、ローカルリージョンで AWS サービスを使用することをお勧めします。クロスリージョン PrivateLink 接続は、特定のリージョンに配置されたリソースの共有やアクセスが必要なユースケース、データ居住規制への対応、マルチリージョン災害復旧計画の実装を目的として設計されています。この機能により、ワークロードが複数のリージョンに拡大しても一貫した安全なネットワーク接続が保証されます。グローバルに分散したアプリケーションが、プライベートエンドポイントを通じてリージョンごとの AWS リソースへの接続、集中管この機能により、ワークロードが複数のリージョンに拡大しても一貫した安全なネットワーク接続が保証されます。理されたデータレイクへのアクセス、他リージョンのベンダー・パートナー・チームとの連携を簡素化します。 今回紹介した機能はコンソール、CLI、API、または CloudFormation を使用して開始できます。詳細については、 PrivateLink ユーザーガイド 、 ユーザ管理 VPCE サービスのクロスリージョン接続の紹介ブログ 、および AWS PrivateLink 経由でサービスに安全にアクセスするためのホワイトペーパー を参照してください。 翻訳は Technical Account Manager の由原が担当しました。原文は こちら です。