本ブログは 2025 年 11 月 17 日に公開された AWS Blog “ Post-quantum (ML-DSA) code signing with AWS Private CA and AWS KMS ” を翻訳したものです。 2025 年 6 月の AWS Key Management Service (AWS KMS) における ML-DSA サポートの発表 に続き、 AWS Private Certificate Authority (AWS Private CA) でもポスト量子 ML-DSA 署名のサポートが導入 されました。 AWS Private CA を使用すると、独自のプライベート公開鍵基盤 (PKI) 階層を作成、管理できます。今回の対応により、コード署名、デバイス認証、 AWS IAM Roles Anywhere を使用した AWS 外部のワークロード認証、IKEv2/IPsec や 相互 TLS (mTLS) などの通信トンネルといったユースケースにおいて、プライベート PKI を使用してお客様が管理する耐量子の信頼の基点を構築し利用できるようになります。 AWS の ポスト量子暗号移行計画 で述べているとおり、耐量子の信頼の基点を確立することは、長期間にわたってセキュリティを維持する必要があるシステムにとって極めて重要です。 FIPS 204 で標準化された署名方式である ML-DSA は、大規模な展開に必要なパフォーマンス特性を維持しながら、量子コンピュータへの耐性を実現します。 以前、AWS Private CA と AWS KMS を使用した コード署名の方法を紹介 しました。本記事では、AWS KMS が提供するポスト量子署名機能と AWS Private CA のポスト量子コード署名 PKI を組み合わせる方法を説明します。ポスト量子 PKI のルート証明書を事前にプロビジョニングしておくことで、署名済みコードの利用者は、暗号解読能力を持つ量子コンピュータ (CRQC) を利用した攻撃を受けても、ソフトウェアが改ざんされていないことを信頼できます。デモンストレーションとして、 AWS SDK for Java を使用するサンプルプログラム diy-code-signing-kms-private-ca を使用します。このコードは、PKI インフラストラクチャの作成、コード署名証明書の生成、バイナリコードへの署名、およびその署名の検証を行います。本記事では機能をわかりやすく説明するためにステップごとに分解していますが、 README ファイルに記載されているコマンドで Runner をそのまま実行して動作を確認することもできます。 本記事では、入力バイナリデータに対して生成された署名をカプセル化するために CMS (Cryptographic Message Syntax) 標準を使用します。CMS は、信頼を確立するために使用される署名、X.509 証明書、および証明書チェーンを格納します。この署名は デタッチド署名 と呼ばれ、元のデータを含みません。デタッチド署名は、署名された元のファイルと組み合わせることで、OpenSSL などの標準ツールを使用してファイルの真正性を検証できます。 ポスト量子 PKI 階層の作成 本記事では、AWS Private CA を使用して コード署名 PKI を構築します。この PKI は、ルート CA が下位 CA に署名し、下位 CA がコード署名証明書に署名するという構成です。チェーン全体が耐量子の ML-DSA 証明書で構成されます。 CA 階層の作成 まず、ML-DSA を使用してポスト量子 CA 階層を作成します。この例では、ポスト量子署名アルゴリズムの ML-DSA-65 バリアントを使用します。 Runner.java ファイルで示されているように、AWS Java SDK を使用して以下のように実行できます。 PrivateCA rootPrivateCA = PrivateCA.builder() .withCommonName(ROOT_COMMON_NAME) .withType(CertificateAuthorityType.ROOT) .withAlgorithmFamily(ML_DSA_65_ALGORITHM_FAMILY) .getOrCreate(); PrivateCA subordinatePrivateCA = PrivateCA.builder() .withIssuer(rootPrivateCA).withCommonName(SUBORDINATE_COMMON_NAME) .withType(CertificateAuthorityType.SUBORDINATE) .withAlgorithmFamily(ML_DSA_65_ALGORITHM_FAMILY) .getOrCreate(); コード署名の準備 コード署名には、非対称キーペアとコード署名証明書が必要です。非対称 ML-DSA キーペアは AWS KMS で生成し、コード署名証明書は AWS Private CA から発行します。 AWS KMS で ML-DSA キーペアを作成 まず、コード署名用の非対称キーペアを作成します。CA 階層の作成時と同様に、AWS Java SDK を使用してこの AWS KMS キー (キーペア) を作成できます。署名は、AWS KMS 内のキーペアのプライベートキーで行います。対応するパブリックキーは、下位 CA が署名するコード署名リーフ証明書に含まれます。これらの呼び出しは、 Runner.java ファイルの main メソッド内で実行されます。 AsymmetricCMK codeSigningCMK = AsymmetricCMK .builder().withAlias(CMK_ALIAS) .withAlgorithmFamily(ML_DSA_65_ALGORITHM_FAMILY) .getOrCreate(); また、Security Blog の 「AWS KMS と ML-DSA を使用してポスト量子署名を作成する方法」 で紹介されているように、 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) を使用して AWS KMS でキーペアを生成することもできます。 コード署名証明書の発行 AWS Private CA を使用した証明書署名リクエスト (CSR) の作成は、2 つのステップで行います。まず、ID (Subject) と先ほど作成した AWS KMS パブリックキーを含む CSR を作成します。 Runner.java 内の以下のコードスニペットで、この処理を行います。 String codeSigningCSR = codeSigningCMK .generateCSR(END_ENTITY_COMMON_NAME); CSR をディスク上の csr.pem に書き出した場合、OpenSSL 3.5 以降で以下のコマンドを使用して内容を確認できます。 openssl req -in csr.pem -inform pem -text -noout Certificate Request: Data: Version: 1 (0x0) Subject: CN=CodeSigningCertificate Subject Public Key Info: Public Key Algorithm: ML-DSA-65 ML-DSA-65 Public-Key: pub: <Public Key Data> Attributes: Requested Extensions: X509v3 Basic Constraints: CA:FALSE Signature Algorithm: ML-DSA-65 Signature Value: <Signature Data> CSR に ML-DSA-65 パブリックキーが含まれていることがわかります。対応するプライベートキーがコード署名に使用されます。 次に、この CSR を使用して下位 CA からコード署名証明書を発行します。 PrivateCA.java ファイル の IssueCertificate リクエストの templateArn にコード署名テンプレートが使用されている点に注目してください。このテンプレートを使用することで、CSR で提示された値に関係なく、AWS Private CA が正しい Key Usage (KU) と Extended Key Usage (EKU) の拡張値を持つ証明書を発行できるようになります。 IssueCertificateRequest issueCertificateRequest = IssueCertificateRequest.builder() .idempotencyToken(UUID.randomUUID().toString()) .certificateAuthorityArn(subordinatePrivateCA.arn()) .csr(SdkBytes.fromUtf8String(csr)) .signingAlgorithm(algorithmFamily.getPcaSigningAlgorithm()) .templateArn("arn:aws:acm-pca:::template/CodeSigningCertificate/V1") .validity(validity) .build(); IssueCertificateResponse issueCertificateResponse = client .issueCertificate(issueCertificateRequest); String certificateArn = issueCertificateResponse.certificateArn(); GetCertificateRequest getCertificateRequest = GetCertificateRequest.builder() .certificateAuthorityArn(ca.arn()) .certificateArn(certificateArn) .build(); レスポンスには ML-DSA-65 コード署名証明書が含まれます。証明書を code-signing-cert.pem というファイル名で保存した後、OpenSSL 3.5 以降を使用して内容を確認できます。 openssl x509 -in code-signing-cert.pem -inform pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 1a:15:af:1e:64:8d:cd:29:b4:dc:66:2a:8b:1e:ee:b0 Signature Algorithm: ML-DSA-65 Issuer: CN=CodeSigningSubordinate-MLDSA65 Validity Not Before: Sep 24 13:10:38 2025 GMT Not After : Sep 24 14:10:38 2026 GMT Subject: CN=CodeSigningCertificate Subject Public Key Info: Public Key Algorithm: ML-DSA-65 ML-DSA-65 Public-Key: pub: <Public Key Data> X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Authority Key Identifier: B7:EF:2E:C9:7A:A8:7E:B5:D6:2D:9A:3F:C7:A7:F8:9D:74:01:6A:EF X509v3 Subject Key Identifier: 7F:63:35:0C:56:F8:ED:F1:2A:DF:B5:2E:7C:F1:2C:D9:A0:0E:63:B6 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical Code Signing Signature Algorithm: ML-DSA-65 Signature Value: <Signature Data> 証明書にコード署名キーペアの ML-DSA-65 パブリックキーと、下位 CA による ML-DSA-65 署名が含まれていることがわかります。また、KU と EKU の値も確認でき、AWS Private CA テンプレートによってコード署名用の証明書として適切に発行されていることを示しています。 コードへの署名 ここまでで、コード署名 PKI のセットアップが完了しました。AWS Private CA が発行したコード署名証明書と、AWS KMS に保管されている対応する ML-DSA キーペアの準備が整っています。 Java SDK を使用して、コードのバイナリファイルに対する CMS 署名を生成できます。内部的には、 Runner.java に示すように、ML-DSA キーペアを指定して AWS KMS Sign API を呼び出すことで署名処理を行っています。以下は Java コードの一部です。最初のスニペットでは、証明書チェーンを構築し、コード署名用の AWS KMS キー、署名者の証明書、およびコードファイルのバイト配列表現である <DATA_TO_SIGN> と組み合わせて、CMS 構造のデタッチド署名を生成します。 // Parse code-signing certificate from PEM X509CertificateHolder signerCert = CertificateUtils .fromPEM(codeSigningCertificate.certificate()); Collection<X509CertificateHolder> chainCerts = CertificateUtils .toCertificateHolders(codeSigningCertificate.certificateChain()); // Build certificate chain including code-signing cert and intermediate certs Collection<X509CertificateHolder> certChain = new ArrayList<> (); certChain.add(signerCert); // Parse certificate chain for (X509CertificateHolder chainCert : chainCerts) { if (!chainCert.equals(signerCert)) { certChain.add(chainCert); } } // Create detached CMS signature CMSCodeSigningObject cmsCodeSigningObject = CMSCodeSigningObject .createDetachedSignature( codeSigningCMK, ML_DSA_65_ALGORITHM_FAMILY, <DATA_TO_SIGN>, signerCert, certChain); コード署名オブジェクトは signature-MLDSA65.p7s としてディスクに書き出されます。OpenSSL 3.5 以降で内容を確認できます。 openssl cms -cmsout -in signature-MLDSA65.p7s -inform DER -print CMS_ContentInfo: contentType: pkcs7-signedData (1.2.840.113549.1.7.2) d.signedData: version: 1 digestAlgorithms: algorithm: shake256 (2.16.840.1.101.3.4.2.12) parameter: <ABSENT> encapContentInfo: eContentType: pkcs7-data (1.2.840.113549.1.7.1) eContent: <ABSENT> certificates: d.certificate: cert_info: version: 2 serialNumber: 0xD0B2937F5BABC80AD55C0A90E1DE7057 signature: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> issuer: CN=CodeSigningSubordinate-MLDSA65 validity: notBefore: Oct 28 15:05:27 2025 GMT notAfter: Oct 28 16:05:26 2026 GMT subject: CN=CodeSigningCertificate key: X509_PUBKEY: algor: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> public_key:(0 unused bits) ... issuerUID: <ABSENT> subjectUID: <ABSENT> extensions: object: X509v3 Basic Constraints (2.5.29.19) critical: FALSE value: 0000 - 30 00 0. object: X509v3 Authority Key Identifier (2.5.29.35) critical: FALSE value: 0000 - 30 16 80 14 b7 ef 2e c9-7a a8 7e b5 d60.......z.~.. 000d - 2d 9a 3f c7 a7 f8 9d 74-01 6a ef-.?....t.j. object: X509v3 Subject Key Identifier (2.5.29.14) critical: FALSE value: 0000 - 04 14 7f 63 35 0c 56 f8-ed f1 2a df b5...c5.V...*.. 000d - 2e 7c f1 2c d9 a0 0e 63-b6.|.,...c. object: X509v3 Key Usage (2.5.29.15) critical: TRUE value: 0000 - 03 02 07 80.... object: X509v3 Extended Key Usage (2.5.29.37) critical: TRUE value: 0000 - 30 0a 06 08 2b 06 01 05-05 07 03 030...+....... sig_alg: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> signature:(0 unused bits) ... d.certificate: cert_info: version: 2 serialNumber: 29577999257397559174219641462943780786 signature: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> issuer: CN=CodeSigningRoot-MLDSA65 [...] d.certificate: cert_info: version: 2 serialNumber: 0xB9419A2C5D2422B3A58A5B449546D74B signature: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> issuer: CN=CodeSigningRoot-MLDSA65 [...] crls: <ABSENT> signerInfos: version: 1 d.issuerAndSerialNumber: issuer: CN=CodeSigningSubordinate-MLDSA65 serialNumber: 0xD0B2937F5BABC80AD55C0A90E1DE7057 digestAlgorithm: algorithm: shake256 (2.16.840.1.101.3.4.2.12) parameter: <ABSENT> signedAttrs: object: contentType (1.2.840.113549.1.9.3) set: OBJECT:pkcs7-data (1.2.840.113549.1.7.1) object: signingTime (1.2.840.113549.1.9.5) set: UTCTIME:Oct 28 16:05:27 2025 GMT object: id-aa-CMSAlgorithmProtection (1.2.840.113549.1.9.52) set: SEQUENCE: 0:d=0hl=2 l=26 cons: SEQUENCE 2:d=1hl=2 l=11 cons:SEQUENCE 4:d=2hl=2 l=9 prim:OBJECT:shake256 15:d=1hl=2 l=11 cons:cont [ 1 ] 17:d=2hl=2 l=9 prim:OBJECT:ML-DSA-65 object: messageDigest (1.2.840.113549.1.9.4) set: OCTET STRING: ... signatureAlgorithm: algorithm: ML-DSA-65 (2.16.840.1.101.3.4.3.18) parameter: <ABSENT> signature: [...] CMS 署名オブジェクトには、コード署名証明書と下位 CA 証明書の両方が直接格納されています。ルート証明書は、お客様が管理するトラストストアに配置される想定です。これらの証明書に加えて、CMS オブジェクトの ASN.1 構造では、 signerInfos 内の signedAttrs に入力データのダイジェストも含まれています。ダイジェストアルゴリズムは SHAKE256 で、OCTET STRING がバイナリダイジェストそのものを表します。CMS における ML-DSA の使用方法は RFC9882 で規定されています。 注意 : この例では 1 つの ML-DSA 署名のみを使用していますが、ユースケースによっては従来型と耐量子型の 2 つの署名を含む場合もあります。このようなデュアル署名のアーティファクトを使用すると、従来型の署名のみをサポートするレガシーな検証者との後方互換性を維持できます。アップグレードされた検証者は、両方の署名を検証できます。 署名済みコードの検証 署名済みコードのアーティファクトをロードする前に、署名を検証する必要があります。検証には、コードの署名の検証と、信頼されたルート CA までの証明書チェーンの検証が含まれます。 Runner.java ファイルの main メソッド内にある以下のコードスニペットで、証明書チェーンの検証とコードオブジェクト内の署名の検証を行います。 X509CertificateHolder rootCACertificate = CertificateUtils.fromPEM(rootCACertificatePEM); cmsCodeSigningObject.verifyDetachedSignature(<DATA_TO_SIGN>, rootCACertificate); このコードは、コード署名証明書から ML-DSA パブリックキーを取得します。署名の検証には AWS へのアクセスや認証情報は不要です。トラストストアにルート CA 証明書をロードしているエンティティであれば、 AWS KMS verify API にアクセスせずに署名を検証できます。 注意: Runner.java の実装では、ブラウザやデバイス・サーバーの OS 上のファイルシステムに組み込まれた証明書トラストストアは使用していません。本記事ではデモンストレーションの目的で、トラストストアを Java クラスオブジェクトのインスタンス内に配置しています。このコード署名の例を本番システムで使用する場合は、ホスト上のトラストストアを使用するよう実装を 変更する必要があります 。その際は、ルート CA 証明書を含む安全なトラストストアを構築して配布してください。 また、OpenSSL 3.5 以降を使用して、AWS Private CA から提供されるルート CA 証明書 root-ca-MLDSA65.pem をトラストアンカーとして、入力データファイルのデタッチド署名を検証することもできます。 openssl cms -verify -in signature-MLDSA65.p7s -content <input-data-file> \ -CAfile root-ca-MLDSA65.pem -inform DER -purpose any \ -binary -out /dev/null CMS Verification successful 注意: 本記事ではコード署名に焦点を当てていますが、AWS Private CA はその他のプライベート PKI ユースケースでもポスト量子 ML-DSA 認証を実現できます。例えば、AWS 外部のアプリケーションが AWS IAM Roles Anywhere を使用して、証明書ベースの認証で一時的な AWS 認証情報を取得し 、AWS リソースにアクセスできます。AWS IAM Roles Anywhere は現在、本記事で作成したような ML-DSA PKI をサポートしています。別のシナリオでは、mTLS クライアントや IKEv2/IPsec ピアが、AWS Private CA から発行された ML-DSA 証明書を使用して、ポスト量子 PKI ルート証明書を事前にプロビジョニングしたサーバーやピアに対して認証を行うことができます。 まとめ 今回の発表は、ポスト量子認証における重要なマイルストーンです。AWS Private CA に ML-DSA X.509 証明書が導入されたことで、プライベート PKI ユースケースに量子コンピュータへの耐性を取り入れることが可能になりました。対象となるユースケースには、mTLS や IKEv2/IPsec トンネルのクライアント認証、IAM Roles Anywhere、プライベート PKI 認証を使用するアプリケーションなどがあります。AWS Private CA の ML-DSA 証明書と AWS KMS による署名を組み合わせることで、ポスト量子コード署名や、CRQC が利用可能になった後も長期間にわたって動作するよう設計されたデバイスに向けた、ポスト量子の長期的な信頼の基点を確立できます。 ポスト量子暗号 全般と、 ポスト量子暗号への移行 に関する AWS の全体計画について、詳しくはそれぞれのページをご覧ください。 この記事に関するご質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを作成するか、 AWS サポート にお問い合わせください。AWS の PQC への取り組みの詳細については、 PQC ページ を参照してください。   Panos Kampanakis Panos は AWS の Principal Security Engineer です。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の分野で豊富な経験を持っています。サイバーセキュリティに関する論文を共著し、セキュリティ情報共有、暗号、公開鍵基盤のための共通の相互運用可能なプロトコルと言語を提供するさまざまなセキュリティ標準化団体に参加してきました。現在は、暗号技術的に安全なツール、プロトコル、標準を提供するため、エンジニアや業界標準パートナーと連携しています。 Jake Massimo Jake は AWS Cryptography チームの Senior Applied Scientist です。国際会議、学術論文、標準化団体を通じて Amazon とグローバルな暗号コミュニティをつなぐ役割を担い、ポスト量子クラウドスケール暗号技術の導入に貢献しています。最近は、AWS とお客様が量子安全な暗号にシームレスに移行できるよう、コアライブラリやインフラストラクチャを含む AWS のポスト量子暗号機能のアーキテクチャ設計に注力しています。 Kyle Schultheiss Kyle は AWS Cryptography チームの Senior Software Engineer です。2018 年のサービス開始以来、AWS Private Certificate Authority サービスの開発に携わっています。以前は、Amazon Virtual Private Cloud、Amazon EC2、Amazon Route 53 などの AWS サービスの開発にも貢献しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 13 日に公開された AWS Blog “ How to create post-quantum signatures using AWS KMS and ML-DSA ” を翻訳したものです。 量子コンピューティングの能力が進化し続ける中、AWS は、公開鍵暗号に対する新たな脅威にお客様が先手を打てるよう取り組んでいます。本日 (2025 年 6 月 13 日)、 FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Standard) の AWS Key Management Service (AWS KMS) でのサポート開始を発表します。デジタル署名に使用している既存の AWS KMS API ( CreateKey 、 Sign 、 Verify オペレーションなど) を通じて、ML-DSA キーの作成と使用が可能になりました。この新機能は一般提供されており、米国西部 (北カリフォルニア) および欧州 (ミラノ) の AWS リージョンで ML-DSA を使用できます。残りの商用リージョンも数日以内に対応予定です。今回のリリースは、先日の ブログ記事 で紹介した、AWS のより広範なポスト量子暗号移行計画の一環です。この記事では、AWS KMS を使用して ML-DSA キーを作成し、ポスト量子署名を生成する手順を説明します。 多くの組織が AWS KMS を使用して、ファームウェア、オペレーティングシステム、アプリケーション、その他のアーティファクトにデジタル署名を行っています。AWS KMS で ML-DSA をサポートしたことにより、FIPS 140-3 レベル 3 認定の HSM 内でポスト量子キーを生成し、署名・検証処理に使用できるようになりました。ML-DSA 署名を今から導入しておけば、暗号解読能力を持つ量子コンピュータ (CRQC) が利用可能になった場合でも、システムの運用期間全体を通じてセキュリティを維持できます。これは、長期間有効な信頼の基点を製造段階でデバイスに組み込むメーカーにとって特に重要です。ハードウェアに直接組み込む場合でも、長期間オフラインのままになる可能性のあるデバイスに組み込む場合でも同様です。いずれの場合も、出荷後にデジタル署名を簡単に更新することはできないため、システムの運用期間全体にわたるポスト量子対応が不可欠です。 新機能 AWS KMS では、3 つの新しい AWS KMS キースペック ( ML_DSA_44 、 ML_DSA_65 、 ML_DSA_87 ) が利用可能になりました。これらは新しいポスト量子 SigningAlgorithm である ML_DSA_SHAKE_256 と組み合わせて使用します。他の署名アルゴリズムと同様に、この名前には、署名スキーム内で署名または検証の前にメッセージをダイジェストするために使用されるハッシュ関数が含まれています。ここで使用されるハッシュ関数は、NIST が FIPS 202 で標準化した SHA-3 ファミリーに属する SHAKE256 です。 表 1 に、各キースペックの詳細 (NIST セキュリティカテゴリおよび対応するキーサイズ (バイト単位) など) を示します。各 ML-DSA キースペックは、セキュリティ強度とリソース要件のバランスが異なります。ML-DSA-44 は従来の 128 ビット暗号化に匹敵するセキュリティが必要なアプリケーションに適しています。一方、ML-DSA-65 と ML-DSA-87 はそれぞれ従来の 192 ビットおよび 256 ビット暗号化に相当する、より強力なセキュリティレベルを提供します。セキュリティレベルが上がるにつれてキーと署名のサイズも大きくなるため、セキュリティ要件とエンジニアリング上の制約に応じて最適なキースペックを選択できます。 Key spec NIST security Level Public key (B) Private key (B) Signature (B) ML_DSA_44 1 (128 ビットセキュリティ相当) 1,312 2,560 2,420 ML_DSA_65 3 (192 ビットセキュリティ相当) 1,952 4,032 3,309 ML_DSA_87 5 (256 ビットセキュリティ相当) 2,592 4,896 4,627 AWS KMS Sign API を RAW MessageType で使用する場合、署名対象のメッセージは 4,096 バイトに制限されます。4,096 バイトを超えるメッセージに署名するには、KMS Sign API への入力サイズを削減するために、AWS KMS の外部でメッセージを前処理して µ (mu) を作成する必要があります。この external mu プロセスでは、ML-DSA 署名キーペアの公開鍵を使用してメッセージをプリハッシュし、メッセージサイズを 64 バイトに縮小します。今回のリリースに合わせて、KMS Sign API に新しいメッセージタイプ EXTERNAL_MU を追加しました。これは ML-DSA の署名または検証の呼び出しで使用でき、AWS KMS に送信する前にメッセージが µ (mu) を使用して前処理済みであることを示します。 以降のセクションでは、external mu の作成方法を詳しく説明し、ML-DSA を使用した AWS KMS の基本的な操作を紹介します。キーの作成、署名の生成と検証について、 RAW と EXTERNAL_MU の両方の署名モードを取り上げます。なお、同じメッセージと署名キーを使用した場合、 RAW と EXTERNAL_MU のどちらで生成しても ML-DSA 署名は同一になります。 ML-DSA キーの作成 まず、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、以下のコマンドで非対称 AWS KMS キーを作成します。 aws kms create-key --key-spec ML_DSA_65 --key-usage SIGN_VERIFY このコマンドは、以下のようなレスポンスを返します。 { "KeyMetadata": { "Origin": "AWS_KMS", "KeyId": " 1234abcd-12ab-34cd-56ef-1234567890ab ", "MultiRegion": false, "Description": "", "KeyManager": "CUSTOMER", "Enabled": true, "SigningAlgorithms": [ "ML_DSA_SHAKE_256" ], "CustomerMasterKeySpec": "ML_DSA_65", "KeyUsage": "SIGN_VERIFY", "KeySpec": "ML_DSA_65", "KeyState": "Enabled", "CreationDate": 1748371316.734, "Arn": " arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab ", "AWSAccountId": " 111122223333 " } } レスポンスに含まれる KeyId または Arn の値を控えておいてください。以降の署名操作でキーを参照する際に必要になります。このレスポンスから、 SIGN_VERIFY オペレーション用に ML_DSA_65 キーが作成され、署名オペレーションには ML_DSA_SHAKE_256 署名アルゴリズムが使用されることを確認できます。 署名 このセクションでは、Web における認可処理において当事者間のクレーム受け渡しに広く使われている JSON Web Token (JWT) を例に、ML-DSA による署名と検証の方法を紹介します。2021 年には、従来の非対称暗号アルゴリズムである楕円曲線デジタル署名アルゴリズム (ECDSA) を使用した JWT の署名と検証の方法を紹介しました (「 How to verify AWS KMS signatures in decoupled architectures at scale 」を参照)。以下の例では、AWS KMS で管理される ML-DSA プライベートキーで JWT に署名し、AWS KMS 内または OpenSSL を使用して外部で検証します。 署名対象の JWT コンテンツは、 RFC7519 のセクション 3.1 に基づいています。JWT ヘッダーは以下のとおりです。 {"typ":"JWT", "alg":"ML-DSA-65"} JWT クレームセットは以下のとおりです。 {"iss":"joe", "exp":1748952000, "http://example.com/is_root":true} ヘッダーとペイロードを Base64URL エンコードすることで、署名対象の JWT メッセージを生成できます。 echo -n -e '{"typ":"JWT",\015\012 "alg":"ML-DSA-65"}' | \ basenc --base64url -w 0 | \ sed 's/=//g' ; echo -n "." ; echo -n -e '{"iss":"joe",\015\012 "exp":1748952000,\015\012 "http://example.com/is_root":true}' | \ basenc --base64url -w 0 | sed 's/=//g' ; echo "" このコマンドは、ML-DSA で署名する対象となる以下の Base64 文字列を出力します。 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ 以下の例では、AWS KMS で管理される ML-DSA プライベートキーを使用してメッセージの ML-DSA 署名を生成し、バイナリ形式で出力します。JWT で使用するには Base64URL に変換する必要がありますが、この署名はさまざまなデータ暗号化および署名形式で利用できます。具体的には、Cryptographic Message Syntax (CMS)、CBOR Object Signing and Encryption (COSE)、UEFI や Open Titan のイメージ署名エンコーディングなどが挙げられます。バイナリからこれらの形式への変換は容易ですが、本記事の執筆時点では、一般的な暗号ライブラリの実装において新しいアルゴリズムのサポートがまだ利用できない場合があります。 RAW モードでの ML-DSA 署名 4,096 バイト未満のメッセージに AWS KMS で ML-DSA 署名を行うには、以下のように AWS CLI を使用します。 aws kms sign \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --message ' eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ' \ --message-type RAW \ --signing-algorithm ML_DSA_SHAKE_256 \ --output text \ --query Signature | base64 --decode > ExampleSignature.bin target-key-id の値 <1234abcd-12ab-34cd-56ef-1234567890ab> を実際の KeyId に置き換えてください。このコマンドは署名を生成し、 ExampleSignature.bin としてディスクに書き込みます。 署名を生成したら、以下のコマンドでヘッダー、ペイロード、署名から構成される完全な JWT を作成できます。 echo -n "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ." ; \ basenc --base64url -w 0 ExampleSignature.bin | \ sed 's/=//g' ; echo "" このコマンドは、 RFC 7519 で要求される形式に準拠した、AWS KMS で署名済みの JWT を出力します。 eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ. <base64url of the signature as per RFC7519> external mu モードでの ML-DSA 署名 AWS KMS では、Sign API 使用時のレスポンスレイテンシーを最小限に抑えるため、RAW メッセージのサイズを 4,096 バイトに制限しています。署名対象のメッセージが 4,096 バイトを超える場合や、external mu のプリハッシュによるパフォーマンス上のメリットを活用したい場合は、 RAW の代わりに EXTERNAL_MU メッセージタイプを使用する必要があります。 AWS KMS Sign API で EXTERNAL_MU メッセージタイプを使用するには、事前にローカルでメッセージのプリハッシュ計算を行う必要があります。まず、以下のコマンドで AWS KMS から公開鍵を取得し、DER 形式に変換します。下記の例のキー ID は、実際の AWS アカウントの有効なキー ID に置き換えてください。 aws kms get-public-key \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --output text \ --query PublicKey | base64 --decode > public_key.der external mu ダイジェストの作成手順は以下のとおりです。 メッセージプレフィックス (M`) を作成します M` = (domain separator || context length || context || Message) この例では、ドメインセパレータの値とコンテキスト長をゼロに設定します。これにより、署名で使用されるコンテキストが空文字列 (デフォルト) になります。 公開鍵をハッシュし、メッセージプレフィックスの先頭に付加します (SHAKE256(pk) || M') ハッシュして 64 バイトの mu を生成します Mu = SHAKE256(SHAKE256(pk) || M') OpenSSL 3.5 では、以下の単一コマンドでダイジェストを作成できます。 { openssl asn1parse -inform DER -in public_key.der -strparse 17 -noout -out - 2>/dev/null | openssl dgst -provider default -shake256 -xoflen 64 -binary; printf '\x00\x00'; echo -n "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ" } | openssl dgst -provider default -shake256 -xoflen 64 -binary > mu.bin これで、AWS KMS を呼び出して 64 バイトのダイジェストに署名し、ML-DSA 署名をファイル ExampleSignature.bin に出力できます。 MessageType は EXTERNAL_MU に設定してください。 aws kms sign \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --output text \ --query Signature | base64 --decode > ExampleSignature.bin 最終的に署名された JWT トークンは、前述の RAW モードで生成されたものと同一です。 AWS KMS を使用した署名検証 このセクションでは、AWS KMS またはローカル環境で ML-DSA 署名を検証する方法を説明します。ここでは、AWS KMS 内のプライベートキーを使用して JWT コンテンツに対して生成された ML-DSA 署名が ExampleSignature.bin に格納されており、 KEY_ARN で識別されることを前提とします。 以下の例では、AWS KMS から直接取得した公開鍵を使用した署名検証を示していますが、これらの原則はプライベート PKI などの証明書ベースのシステムにも適用できます。プライベート PKI では、公開鍵は署名者のエンドエンティティ証明書に埋め込まれています。このようなシナリオでは、検証者はまず証明書チェーンが信頼されたルート証明書に結びついていることを検証して署名者の身元を確認し、次にエンドエンティティ証明書の公開鍵を使用してコンテンツの ML-DSA 署名を検証します。 IETF は、RFC ドラフト draft-ietf-lamps-dilithium-certificates を通じて、X.509 証明書での ML-DSA の使用を標準化しています。 RAW モードでの ML-DSA 検証 AWS KMS を使用して署名を検証するには、以下のコマンドを実行します。例の key-id は、署名時に使用したものと同じキー ID に置き換えてください。 aws kms verify \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --message "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ" \ --message-type RAW \ --signing-algorithm ML_DSA_SHAKE_256 \ --signature fileb://ExampleSignature.bin 以下のようなレスポンスが返されます。 { "KeyId": " arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab ", "SignatureValid": true, "SigningAlgorithm": "ML_DSA_SHAKE_256" } 検証結果は SignatureValid フィールドで確認できます。 external mu モードでの ML-DSA 検証 JWT コンテンツの external mu ダイジェストが mu.bin に格納されており、署名と対応するキーペアが AWS KMS にある場合、メッセージ全体にアクセスしたりダイジェストを再計算したりすることなく、このダイジェストを使用して検証できます。 aws kms verify \ --key-id <1234abcd-12ab-34cd-56ef-1234567890ab> \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --signature fileb://ExampleSignature.bin メッセージと公開鍵から external mu mu.bin を再生成する方法については、前述の 「external mu モードでの ML-DSA 署名」セクション を参照してください。 OpenSSL 3.5 を使用したローカル署名検証 ML-DSA 署名の生成には AWS KMS で生成・保管されたキーのセキュリティを維持しつつ、API の呼び出しコストを削減し、API クォータの使用をより細かく制御したい場合は、AWS KMS の外部でローカルに ML-DSA 署名を検証できます。 この例では、OpenSSL 3.5 を使用して ExampleSignature.bin の署名を検証します。まず、 「external mu モードでの ML-DSA 署名」 セクションで示したように、AWS KMS から DER エンコードされた公開鍵を取得し、ファイル public_key.der に保存する必要があります。OpenSSL 3.5 では、この公開鍵を使用してメッセージの署名を検証できます。 echo -n "eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJNTC1EU0EtNjUifQ.eyJpc3MiOiJqb2UiLA0KICJleHAiOjE3NDg5NTIwMDAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ" | \ openssl dgst -verify public_key.der -signature ExampleSignature.bin 検証が成功すると、 Verified OK と出力されます。 まとめ 本日 (2025 年 6 月 13 日) の AWS KMS における ML-DSA サポートの開始は、ポスト量子暗号に対する AWS の取り組みにおける重要なマイルストーンです。3 段階のセキュリティレベルと RAW・external mu の 2 つの署名モードにより、量子コンピューティング時代を見据えたセキュリティ要件に柔軟に対応できます。既存の AWS KMS API とシームレスに統合できるため、量子コンピュータに耐性のある署名を今すぐアプリケーションに組み込むことが可能です。この実装は、以下のようなユースケースで特に効果を発揮します。 ポスト量子暗号の使用時に FIPS 140-3 準拠要件を満たす必要がある場合 コード、アーティファクト、ドキュメントなどに対して、暗号解読能力を持つ量子コンピュータ (CRQC) が実現した後も長期間にわたって検証可能な署名を付与する必要がある場合 AWS KMS のような承認済みの暗号サービスを活用し、アプリケーション開発プロセスの一環としてポスト量子暗号のテストを開始する場合 ポスト量子暗号 全般、および AWS の ポスト量子暗号への移行計画 の詳細についてはリンク先をご覧ください。 Jake Massimo Jake は AWS Cryptography チームの Applied Scientist です。国際会議、学術研究、標準化団体への積極的な参加を通じて、Amazon とグローバルな暗号コミュニティの橋渡し役を担っています。クラウド規模でのポスト量子暗号技術の導入推進に取り組んでおり、現在は AWS 暗号ライブラリにおいて、最適化され形式的に検証されたポスト量子アルゴリズムの開発をリードしています。 Panos Kampanakis Panos はサイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理に関する豊富な経験を持っています。長年にわたり、技術イベントでさまざまなセキュリティトピックに関するトレーニングやプレゼンテーションを行ってきました。サイバーセキュリティに関する出版物を共同執筆し、セキュリティ情報共有、暗号、PKI のための共通の相互運用可能なプロトコルや言語を提供するさまざまなセキュリティ標準化団体に参加しています。 Mayank Ambaliya Mayank は AWS Key Management Service (AWS KMS) の Software Development Manager です。AWS KMS の暗号 API およびカスタムキーストアの開発をリードしています。AWS CloudHSM のお客様向け暗号 API および暗号 SDK の開発経験があり、最近では AWS KMS でのポスト量子アルゴリズムサポートや新しい暗号 API の追加に取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2023 年 6 月 13 日に公開された AWS Blog “ Post-quantum hybrid SFTP file transfers using AWS Transfer Family ” を翻訳したものです。 2025 年 9 月 5 日: AWS Transfer Family は、ポスト量子ハイブリッド鍵交換のサポートを、Kyber から NIST が FIPS 203 で標準化した ML-KEM にアップグレードしました。ML-KEM によるポスト量子鍵交換をサポートする SSH ポリシーは TransferSecurityPolicy-2025-03 と TransferSecurityPolicy-FIPS-2025-03 です。これらのポリシーに含まれるポスト量子 SSH 鍵交換方式は、 ポスト量子ハイブリッド SSH 鍵交換のドラフト仕様 で定義されている mlkem768nistp256-sha256 、 mlkem1024nistp384-sha384 、 mlkem768x25519-sha256 です。詳細については、「 AWS Transfer Family announces ML-KEM quantum-resistant key exchange for SFTP 」を参照してください。 以下の記事の例で使用されている 2023 年当時の実験的ポリシー ( TransferSecurityPolicy-PQ-SSH-Experimental-2023-04 および TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 ) と SSH メソッド名には、ML-KEM の標準化前バージョンである Kyber が含まれていました。これらのポリシーを使用している SFTP エンドポイントについては、対応する SFTP クライアントがまだ ML-KEM にアップグレードされておらず、引き続き Kyber を使用している場合を除き、 TransferSecurityPolicy-2025-03 and TransferSecurityPolicy-FIPS-2025-03 に更新してください。 Amazon Web Services (AWS) は、セキュリティ、プライバシー、パフォーマンスを最優先としています。暗号化はプライバシーの重要な要素です。暗号化されたデータを長期にわたって保護するために、AWS はお客様が使用する一般的なトランスポートプロトコルに耐量子鍵交換を導入してきました。本記事では、Secure Shell (SSH) プロトコルにおける Kyber を使用したポスト量子ハイブリッド鍵交換について紹介します。Kyber は、米国国立標準技術研究所 (NIST) が選定した耐量子鍵カプセル化アルゴリズムです。ポスト量子ハイブリッド鍵交換が重要な理由を解説し、AWS のファイル転送サービスである AWS Transfer Family の Secure File Transfer Protocol (SFTP) で使用する方法を紹介します。 SSH でポスト量子ハイブリッド鍵確立を使用する理由 現時点では実用化されていませんが、暗号解読能力を持つ量子コンピュータ (CRQC) が実現すれば、現在使用されている標準的な公開鍵アルゴリズムを理論的に破ることが可能になります。現在のネットワークトラフィックを記録しておき、将来 CRQC で復号するという脅威も想定されます。これは harvest-now-decrypt-later (今収集して後で復号する攻撃) と呼ばれています。 こうした懸念を踏まえ、米国議会は Quantum Computing Cybersecurity Preparedness Act に署名し、ホワイトハウスは耐量子暗号への適切かつ公平な移行に備えるための国家安全保障覚書 ( NSM-8 、 NSM-10 ) を発行しました。米国国家安全保障局 (NSA) も CNSA 2.0 リリース で耐量子アルゴリズムの要件とタイムラインを公表しています。 カナダ 、 ドイツ 、 フランス をはじめとする多くの政府や、ISO/IEC、 IEEE などの標準化団体も、耐量子暗号技術への備えと実証を優先的に進めています。 AWS はポスト量子暗号への移行を積極的に推進しています。 AWS Key Management Service (AWS KMS) 、 AWS Certificate Manager (ACM) 、 AWS Secrets Manager の TLS エンドポイントでは、楕円曲線 Diffie-Hellman (ECDH) と Kyber を使用した ポスト量子ハイブリッド鍵確立が既にサポート されています。Kyber は、 NIST のポスト量子暗号 (PQC) プロジェクト で選定された鍵カプセル化メカニズム (KEM) です。ポスト量子ハイブリッド TLS 1.3 鍵交換は大きな注目を集めていますが、SSH に関する取り組みはこれまで限定的でした。 SSH は、マシン間のファイル転送から Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの管理まで、AWS のお客様に幅広く使用されているプロトコルです。SSH プロトコルの重要性、広範な利用状況、転送されるデータの性質を考慮し、AWS は SSH にも Kyber を使用したポスト量子ハイブリッド鍵交換を導入しました。 Transfer Family SFTP におけるポスト量子ハイブリッド鍵交換の仕組み AWS は、2023 年 6 月に AWS Transfer Family の SFTP ファイル転送におけるポスト量子鍵交換のサポートを発表 しました。Transfer Family は、SFTP やその他のプロトコルを使用して、AWS Storage サービスへの企業間ファイル転送を安全にスケールするサービスです。SFTP は SSH 上で動作する File Transfer Protocol (FTP) のセキュアバージョンです。Transfer Family がポスト量子鍵交換をサポートすることで、SFTP 経由のデータ転送のセキュリティが向上します。 SSH におけるポスト量子ハイブリッド鍵確立では、ポスト量子 KEM を従来の鍵交換と組み合わせて使用します。クライアントとサーバーは引き続き ECDH 鍵交換 を行います。さらに、サーバーはクライアントが SSH 鍵交換メッセージで提示したポスト量子 KEM 公開鍵を用いて、ポスト量子共有シークレットをカプセル化します。この方式は、従来の鍵交換の高い信頼性とポスト量子鍵交換によるセキュリティを組み合わせたもので、ECDH またはポスト量子共有シークレットのどちらか一方が安全である限り、ハンドシェイクは保護されます。 具体的には、Transfer Family のポスト量子ハイブリッド鍵交換 SFTP サポートは、ポスト量子 Kyber-512、Kyber-768、Kyber-1024 と、ECDH (楕円曲線 P256、P384、P521、Curve25519) を組み合わせた方式に対応しています。対応する SSH 鍵交換方式は、 ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org、ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org、ecdh-nistp521-kyber-1024r3-sha512-d00@openquantumsafe.org 、および x25519-kyber-512r3-sha256-d00@amazon.com で、 ポスト量子ハイブリッド SSH 鍵交換のドラフト仕様 で定義されています。 Kyber を採用した理由 AWS は標準化された相互運用可能なアルゴリズムのサポートに取り組んでおり、SSH には Kyber を導入しました。Kyber は、NIST の ポスト量子暗号 (PQC) プロジェクト で標準化の対象として選定されたアルゴリズムです。複数の標準化団体が、既にさまざまなプロトコルへの Kyber の統合を進めています。 また、AWS は相互運用性の促進にも取り組んでおり、SSH 向けに Kyber と NIST 標準の楕円曲線 (P256 など) を組み合わせた ドラフト仕様 を策定・公開し、標準化に向けて提出しました。SFTP および SSH におけるポスト量子鍵交換の AWS 実装は、お客様のセキュリティ強化のため、このドラフト仕様に準拠しています。 相互運用性 新しい鍵交換方式 ( ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org、ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org、ecdh-nistp521-kyber-1024r3-sha512-d00@openquantumsafe.org 、および x25519-kyber-512r3-sha256-d00@amazon.com ) は、Transfer Family の 2 つの新しい セキュリティポリシー でサポートされています。これらの方式名やポリシーは、ドラフト仕様の標準化の進展や NIST による Kyber アルゴリズムの正式承認に伴い、変更される可能性があります。 ポスト量子ハイブリッド SSH 鍵交換と FIPS 140 などの暗号要件への適合性 FIPS 準拠が必要なお客様向けに、Transfer Family ではオープンソース暗号ライブラリである AWS-LC を使用して SSH の FIPS 暗号を提供しています。Transfer Family の TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 ポリシーでサポートされるポスト量子ハイブリッド鍵交換方式は、 SP 800-56Cr2 (section 2) に記載のとおり、引き続き FIPS 要件を満たしています。ドイツ連邦情報セキュリティ庁 ( BSI ) やフランス国家情報システムセキュリティ庁 ( ANSSI ) も、このようなポスト量子ハイブリッド鍵交換方式を推奨しています。 Transfer Family でポスト量子 SFTP をテストする方法 Transfer Family でポスト量子ハイブリッド SFTP を有効にするには、SFTP 対応エンドポイントに、ポスト量子ハイブリッド鍵交換をサポートする 2 つのセキュリティポリシー のいずれかを適用する必要があります。セキュリティポリシーは、 ドキュメント に記載のとおり、Transfer Family で新しい SFTP サーバーエンドポイントを作成する際に選択できます。また、既存の SFTP エンドポイントの [Cryptographic algorithm options] を編集して変更することもできます。以下の図 1 に、 AWS マネジメントコンソール でセキュリティポリシーを更新する画面の例を示します。 図 1: コンソールから Transfer Family エンドポイントにポスト量子ハイブリッドセキュリティポリシーを設定する Transfer Family でポスト量子鍵交換をサポートするセキュリティポリシー名は、 TransferSecurityPolicy-PQ-SSH-Experimental-2023-04 と TransferSecurityPolicy-PQ-SSH-FIPS-Experimental-2023-04 です。Transfer Family のポリシーの詳細については、「 Security policies for AWS Transfer Family 」を参照してください。 SFTP の Transfer Family エンドポイントで適切なポスト量子セキュリティポリシーを選択したら、 前述のドラフト仕様 のガイダンスに従い、ポスト量子ハイブリッド鍵交換をサポートする SFTP クライアントを使用して、Transfer Family でのポスト量子 SFTP を検証できます。AWS は、 NIST NCCOE Post-Quantum Migration プロジェクト の協力者でもある OQS OpenSSH および wolfSSH の SSH 実装と、Transfer Family のポスト量子ハイブリッド鍵交換 SFTP との相互運用性をテストし、確認しています。 OQS OpenSSH クライアント OQS OpenSSH は、liboqs を使用して SSH に耐量子暗号を追加する OpenSSH のオープンソースフォークです。 liboqs は、耐量子暗号アルゴリズムを実装するオープンソースの C ライブラリです。OQS OpenSSH と liboqs は、いずれも Open Quantum Safe (OQS) プロジェクト の一部です。 OQS OpenSSH を使用して Transfer Family SFTP でポスト量子ハイブリッド鍵交換をテストするには、まずプロジェクトの README の手順に従って OQS OpenSSH をビルドします。次に、以下のコマンドのように、ポスト量子ハイブリッド鍵交換方式を指定して SFTP クライアントを実行し、AWS SFTP エンドポイント (例: s-9999999999999999999.server.transfer.us-west-2.amazonaws.com ) に接続します。 &lt;user_priv_key_PEM_file&gt; はユーザー認証に使用する SFTP ユーザーの PEM エンコード秘密鍵ファイルに、 &lt;username&gt; はユーザー名に置き換えてください。また、SFTP 対応エンドポイントは Transfer Family で作成したものに更新してください。 ./sftp -S ./ssh -v -o \ KexAlgorithms=ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org \ -i &lt;user_priv_key_PEM_file&gt; \ &lt;username&gt; @s-9999999999999999999.server.transfer.us-west-2.amazonaws.com wolfSSH クライアント wolfSSH は、暗号処理に wolfCrypt を使用する SSHv2 クライアントおよびサーバーライブラリです。詳細とダウンロードリンクについては、 wolfSSL の製品ライセンス情報 を参照してください。 wolfSSH を使用して Transfer Family SFTP でポスト量子ハイブリッド鍵交換をテストするには、まず wolfSSH をビルド します。耐量子暗号アルゴリズムを実装するオープンソースライブラリ liboqs を使用してビルドすると、wolfSSH は自動的に ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org をネゴシエートします。以下のコマンドのように SFTP クライアントを実行して AWS SFTP サーバーエンドポイントに接続します。 &lt;user_priv_key_DER_file&gt; はユーザー認証に使用する SFTP ユーザーの DER エンコード秘密鍵ファイルに、 &lt;user_public_key_PEM_file&gt; は対応する SSH ユーザーの PEM 形式公開鍵ファイルに、 &lt;username&gt; はユーザー名に置き換えてください。また、SFTP エンドポイント s-9999999999999999999.server.transfer.us-west-2.amazonaws.com は Transfer Family で作成したものに更新してください。 ./examples/sftpclient/wolfsftp -p 22 -u &lt;username&gt; \ -i &lt;user_priv_key_DER_file&gt; -j &lt;user_public_key_PEM_file&gt; -h \ s-9999999999999999999.server.transfer.us-west-2.amazonaws.com 耐量子の将来に向けた移行が進むにつれ、SSH 向けに標準化されたポスト量子ハイブリッド鍵交換をサポートする SFTP および SSH クライアントは今後ますます増えていくと見込まれます。 SFTP でポスト量子ハイブリッド鍵交換を確認する方法 Transfer Family への SFTP 用 SSH 接続でポスト量子ハイブリッド鍵交換が使用されたことを確認するには、クライアントの出力を確認するか、パケットキャプチャを使用します。 OQS OpenSSH クライアント クライアントの出力 (関連のない情報は省略) は以下のようになります。 $./sftp -S ./ssh -v -o KexAlgorithms=ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org -i panos_priv_key_PEM_file panos@s-9999999999999999999.server.transfer.us-west-2.amazonaws.com OpenSSH_8.9-2022-01_p1, Open Quantum Safe 2022-08, OpenSSL 3.0.2 15 Mar 2022 debug1: Reading configuration data /home/lab/openssh/oqs-test/tmp/ssh_config debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com [xx.yy.zz..12] port 22. debug1: Connection established. [...] debug1: Local version string SSH-2.0-OpenSSH_8.9-2022-01_ debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1 debug1: compat_banner: no match: AWS_SFTP_1.1 debug1: Authenticating to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com:22 as 'panos' debug1: load_hostkeys: fopen /home/lab/.ssh/known_hosts2: No such file or directory [...] debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server-&gt;client cipher: aes192-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none debug1: kex: client-&gt;server cipher: aes192-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ssh-ed25519 SHA256:BY3gNMHwTfjd4n2VuT4pTyLOk82zWZj4KEYEu7y4r/0 [...] debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 4294967296 blocks [...] Authenticated to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com ([xx.yy.zz..12]:22) using "publickey".s debug1: channel 0: new [client-session] [...] Connected to s-9999999999999999999.server.transfer.us-west-2.amazonaws.com. sftp&gt; この出力から、ポスト量子ハイブリッド方式 ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org を使用した鍵交換のネゴシエーションが行われ、SFTP セッションが正常に確立されたことがわかります。 ネゴシエートされたポスト量子ハイブリッド鍵をさらに確認するには、 Wireshark などのネットワークトラフィック分析ツールでパケットキャプチャを使用します。クライアントが提案する鍵交換方式のネゴシエーションは以下のように表示されます。 図 2: Wireshark でクライアントが提案するポスト量子ハイブリッド鍵交換方式を確認する 図 2 は、クライアントがポスト量子ハイブリッド鍵交換方式 ecdh-nistp384-kyber-768r3-sha384-d00@openquantumsafe.org を提案していることを示しています。Transfer Family SFTP サーバーは同じ方式をネゴシエートし、クライアントはポスト量子ハイブリッド公開鍵を提案します。 図 3: クライアントの ECDH P384 および Kyber-768 公開鍵を確認する 図 3 に示すように、クライアントはポスト量子ハイブリッド公開鍵として 1,281 バイトを送信しています。これは、ECDH P384 の 92 バイトの公開鍵、1,184 バイトの Kyber-768 公開鍵、および 5 バイトのパディングで構成されています。サーバーのレスポンスも同様のサイズで、92 バイトの P384 公開鍵と 1,088 バイトの Kyber-768 暗号文が含まれています。 wolfSSH クライアント クライアントの出力 (関連のない情報は省略) は以下のようになります。 $ ./examples/sftpclient/wolfsftp -p 22 -u panos -i panos_priv_key_DER_file -j panos_public_key_PEM_file -h s-9999999999999999999.server.transfer.us-west-2.amazonaws.com [...] 2023-05-25 17:37:24 [DEBUG] SSH-2.0-wolfSSHv1.4.12 [...] 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = unknown 2023-05-25 17:37:24 [DEBUG] DNL: name ID = diffie-hellman-group-exchange-sha256 [...] 2023-05-25 17:37:24 [DEBUG] connect state: SERVER_KEXINIT_DONE [...] 2023-05-25 17:37:24 [DEBUG] connect state: CLIENT_KEXDH_INIT_SENT [...] 2023-05-25 17:37:24 [DEBUG] Decoding MSGID_KEXDH_REPLY 2023-05-25 17:37:24 [DEBUG] Entering DoKexDhReply() 2023-05-25 17:37:24 [DEBUG] DKDR: Calling the public key check callback Sample public key check callback public key = 0x24d011a public key size = 104 ctx = s-9999999999999999999.server.transfer.us-west-2.amazonaws.com 2023-05-25 17:37:24 [DEBUG] DKDR: public key accepted [...] 2023-05-25 17:37:26 [DEBUG] Entering wolfSSH_get_error() 2023-05-25 17:37:26 [DEBUG] Entering wolfSSH_get_error() wolfSSH sftp&gt; この出力から、クライアントがポスト量子ハイブリッド方式 ecdh-nistp256-kyber-512r3-sha256-d00@openquantumsafe.org をネゴシエートし、耐量子 SFTP セッションが正常に確立されたことがわかります。このセッションのパケットキャプチャは前述のものとほぼ同様です。 まとめ 本記事では、ポスト量子暗号への移行と、標準化されたアルゴリズムおよびプロトコルの採用が重要な理由を紹介しました。また、SSH にポスト量子ハイブリッド鍵交換を導入する AWS のアプローチと、Transfer Family の SFTP での利用方法についても説明しました。AWS は暗号技術の専門家と協力して、ポスト量子ハイブリッド SSH 鍵交換のドラフトを策定しています。Transfer Family はこの ドラフト仕様 に準拠しています。 Transfer Family でのポスト量子鍵交換の使用方法についてご質問がある場合は、 Transfer Family for SFTP フォーラム で新しいスレッドを開始してください。AWS のポスト量子暗号について詳しく知りたい場合は、 ポスト量子暗号チーム にお問い合わせください。 本記事に関するご質問は、 AWS Security, Identity, &amp; Compliance re:Post で新しいスレッドを開始するか、 AWS サポート までお問い合わせください。 AWS セキュリティに関するその他のニュースは、 Twitter でフォローしてください。 Panos Kampanakis Panos は AWS Cryptography 組織の Principal Security Engineer です。サイバーセキュリティ、応用暗号技術、セキュリティ自動化、脆弱性管理に関する豊富な経験を持っています。サイバーセキュリティに関する出版物を共同執筆しており、セキュリティ情報の共有や暗号技術、PKI のための相互運用可能なプロトコルおよび言語の策定に取り組むさまざまなセキュリティ標準化団体に参加してきました。現在は、エンジニアや業界の標準化パートナーと協力し、暗号実装、プロトコル、標準の策定に取り組んでいます。 Torben Hansen Torben は AWS Cryptography チームの暗号技術者です。暗号ライブラリの開発とデプロイに注力しており、AWS 全体にわたる暗号ソリューションの設計と分析にも貢献しています。 Alex Volanis Alex は AWS の Software Development Engineer で、分散システム、暗号技術、認証、ビルドツールの経験があります。現在は AWS Transfer Family チームと協力し、社内外のお客様向けにスケーラブルで安全かつ高パフォーマンスなデータ転送ソリューションを提供しています。コーディングと問題解決に情熱を注いでおり、スキーの腕前も相当なものです。 Gerardo Ravago Gerardo は AWS Cryptography 組織の Senior Software Development Engineer で、ポスト量子暗号と Amazon Corretto Crypto Provider の開発に貢献しています。以前は AWS で Storage Gateway と DataSync に携わっていました。仕事以外では、旅行を通じて世界各地の食、芸術、文化、歴史の探求を楽しんでいます。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 アマゾン ウェブ サービス ジャパン合同会社では、レガシーな Windows アプリケーションで課題を抱えている開発者様向けに、「AWS Transform for .NET セミナー」を毎月開催しています。今年 1 回目となる 1/26 のセミナーを AWS オフィスにて開催し、ご好評をいただきました。本セミナーでは、.NET Framework のモダナイゼーションの考え方を学び、ハンズオンを通じて AWS Transform for .NET を実際に体験いただけます。また、AWS の専門家との意見交換を通じて、モダナイゼーションに向けた具体的なヒントを得ることができます。次回は 2/27 午後に開催予定です。 ご興味のある方は、ぜひ御社営業担当までお問い合わせください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年2月9日週の主要なアップデート 2/9(月) Amazon Redshift が自動最適化のための追加コンピュートリソース割り当てをサポート Amazon Redshift で自動最適化機能 (autonomics) 専用の追加コンピュートリソースを割り当てられるようになりました。これまでユーザーのワークロードが高い時間帯は自動最適化を手動でスケジューリングする必要がありましたが、今回のアップデートで専用リソースを使って常時実行可能になります。テーブル最適化やバキューム処理などがユーザー処理に影響を与えずに動作し、コスト制御機能で上限設定も可能です。詳細は こちらのドキュメントをご参照ください。 AWS HealthOmics がバイオインフォマティクスワークフロー開発のための Kiro Power と Kiro IDE 拡張機能を導入 AWS HealthOmics が Kiro Power と Kiro IDE 拡張機能を発表しました。これまでバイオインフォマティクスのワークフロー開発は複雑で時間がかかっていましたが、今回の AI エージェント支援により開発速度が大幅に向上します。Nextflow や WDL などの専門言語でのコード作成時に、IDE拡張機能によるシンタックスハイライトや自動補完機能が利用でき、エラーの診断や性能最適化の提案も自動で行われます。研究者や開発者が科学的発見により集中できる環境が整いました。 2/10(火) Amazon OpenSearch Serverless でコレクショングループがサポート開始 Amazon OpenSearch Serverless に Collection Groups という新機能が追加されました。従来は異なる KMS キーを使うコレクション間で OCU (OpenSearch Compute Units) を共有できませんでしたが、この機能により共有が可能になりました。これにより OCU の利用効率が向上し、コスト削減を実現できます。また最小 OCU 設定により起動時から安定したパフォーマンスを確保でき、マルチテナント環境で特に効果を発揮します。詳細は こちらのドキュメントをご参照ください。 Amazon Athena が 1 分間の予約と 4 DPU の最小容量をサポート Amazon Athena で 1 分単位の Capacity Reservations と最小 4 DPU での予約が可能になりました。従来の最小 24 DPU から 1/6 の容量で開始でき、ワークロードパターンに合わせてより頻繁で細かい調整が可能です。短期間のクエリワークロードでは最大 95 % のコスト削減を実現できます。データスキャン料金は発生せず、予約した容量分のみの支払いとなります。既存の SQL クエリやアプリケーションコードを変更することなく、ワークグループを予約に紐づけるだけで利用開始できるのも魅力です。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 C8id、M8id、R8id インスタンスが追加リージョンで利用可能に Amazon EC2 の新世代インスタンス C8id, M8id, R8id が新たに追加リージョンで利用可能になりました。東京リージョンでは3タイプすべてが対応し、フランクフルトでは C8id・M8id、スペインでは M8id・R8id が利用できます。Intel Xeon 6 プロセッサー搭載で、前世代比 43% 高性能を実現します。C8id は Web サーバーや動画エンコード、M8id はアプリケーションサーバー、R8id はインメモリデータベースに最適です。リージョン選択肢が増えることで、ユーザーに近い場所でのデプロイが可能となり、レイテンシ改善とコスト最適化を両立できます。詳細は こちらの EC2 インスタンスタイプページをご参照ください。 2/11(水) Amazon Connect がノイズの多い環境向けのオーディオ拡張機能を導入 Amazon Connect でエージェント側のノイズを除去するオーディオ拡張機能が提供開始されました。コールセンター環境でのノイズや雑談を自動で抑制し、エージェントの音声をクリアにして顧客に届けることができます。従来はノイズの多い環境で音声品質が低下する課題がありましたが、この機能により背景音を除去して音声を分離できるようになりました。Voice Isolation (音声分離) と Noise Suppression (ノイズ抑制) の 2 つのモードから環境に応じて選択可能です。詳細は こちらをご参照ください。 AWS Elastic Beanstalk が自動アプリケーションデプロイメント用の GitHub Actions をサポート開始 AWS Elastic Beanstalk で GitHub Actions を利用した自動デプロイが可能になりました。GitHub リポジトリにコードをプッシュするだけで、アプリケーションが自動的にデプロイされ、開発チームの CI/CD パイプラインが大幅に効率化されます。これまで手動で行っていたデプロイ作業が自動化され、S3 アップロードやバージョン管理も含めて一括処理できます。詳細は こちらをご参照ください。 AWS が AWS Data Transfer Terminal の 6 つの新しい拠点を発表 AWS Data Transfer Terminal が新たに 6 箇所で利用可能になり、東京を含む世界各地でサービスが拡大されました。これにより日本のお客様も物理的にストレージデバイスを持参して、高速ネットワーク経由で大容量データを Amazon S3 などに安全かつ迅速にアップロードできます。国内でのデータ転送が可能になったことで、メディア制作データや機械学習の訓練データなどの大容量ファイルを効率的に AWS に移行できます。詳細は こちらの製品ページ をご参照ください。 2/12(木) Amazon Connect が分析ダッシュボードの詳細なアクセス制御を開始 Amazon Connect のダッシュボードで、部門やチームごとに細かいアクセス制御ができるようになりました。これまでは全てのメトリクスが見えてしまっていましたが、今回のアップデートでリソースタグを活用して、特定のエージェントやキューの分析データを必要な人だけに表示することが可能です。例えば、カスタマーサービス部門のエージェントにタグを付けて、その部門のマネージャーだけがそのメトリクスを確認できるように設定できます。部門間でのデータセキュリティが向上し、より効率的な管理が実現します。詳細は こちらのドキュメント をご参照ください。 新しい Amazon EC2 汎用 M8azn インスタンスの発表 新しい EC2 M8azn インスタンスの一般提供を開始しました。AMD EPYC 第 5 世代プロセッサー搭載で最大 5GHz の高周波数を実現し、従来の M5zn インスタンスと比較してコンピュート性能が 2 倍向上しています。リアルタイム金融分析や高頻度取引 (HFT)、CI/CD パイプライン、ゲーミングアプリケーションなどの低レイテンシーが求められる用途に最適です。現在、東京リージョンやバージニア北部リージョンなどで利用可能です。詳細は こちらのインスタンスタイプページ をご参照ください。 AWS Support Center Console の AI トラブルシューティングが 7 つの追加言語をサポート AWS Support Center Console の AI トラブルシューティング機能が、英語に加えて日本語など 7 言語をサポートしました。これまで英語のみだったため言語の壁がありましたが、日本語で EC2 の接続エラーなどの問題解決のための AI アドバイスを受けられるようになります。全てのサポートプランで利用できます。詳細は こちらのユーザーガイド をご参照ください。 2/13(金) Amazon Connect が Tasks にリアルタイム AI 搭載の概要と推奨次アクションを提供開始 Amazon Connect で AI 搭載のタスク概要と推奨アクションが利用できるようになりました。エージェントが返金リクエストなどのタスクを受け取ると、過去の注文確認や返品可否チェックなどの活動を AI が自動要約し、次に取るべきアクションを提案してくれます。これまでエージェントが手動で履歴を確認していた作業が効率化され、より迅速な問題解決が可能です。Connect assistant フローブロックを追加することで機能を有効化でき、ナレッジベースのカスタマイズも可能です。詳細は こちらのドキュメントをご参照ください。 AWS Batch でジョブキューと共有使用率の可視化機能を提供開始 AWS Batch で新しくジョブキューと共有利用率の可視性機能が提供開始されました。この機能により、コンピュートリソースがワークロード間でどう使われているかを詳細に確認できます。従来は見えなかった FIFO キューや公平共有キューの容量使用状況、個別の共有割り当ての消費量が確認可能になり、どのジョブがリソースを最も消費しているかを特定できます。リソース配分の最適化や効率的な運用計画の策定に活用できます。詳細は こちらのドキュメント をご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

本稿は、パナソニック インフォメーションシステムズ社による「Oracle Database@AWS 検証レポート – 閉域接続・バックアップ・Data Guard・監視構成の検証」について、検証を実施された 田村 俊樹 様に寄稿いただきました。 はじめに 東京リージョンでの Oracle Database@AWS 稼働を見据え、技術的な実現可能性と課題を把握するため、先行してバージニア北部環境とオレゴン環境において、Oracle Database@AWS の設計・構築を行いました。 本記事では、閉域接続、バックアップ構成、Oracle Data Guard、監視構成について検証を実施した内容をご紹介します。 構成詳細 AWS 側では、ODB ネットワーク、Application VPC（今回の検証ではアプリケーションは未配置）、Transit VPC、及びこれらを接続する Transit Gateway の構成を採用しました。 OCI との閉域接続は ODB ピアリングを利用して確立しました。今回の検証では、Oracle Database@AWS は AWS リージョン内に設置された OCI 管理の Exadata インフラ上の VM で稼働し、AWS 側の ODB Networkと閉域接続されています。ODB ピアリングは Amazon Virtual Private Cloud と ODB ネットワーク間のセキュアな通信を実現します。 ※ ODB ピアリング、ODB ネットワークに関しては こちらのブログ をご参照ください。 一方、OCI 側では VCN 内の Compute からローカルピアリングゲートウェイ(以下、LPG )を通じて Exadata クラスタに接続する構成を採用し、リージョン間は動的ルーティングゲートウェイ (以下、DRG )で接続されています。DRG は OCI リージョン間の接続を担い、LPG は VCN 間のピアリングを提供することで、閉域網での通信を可能にしました。 検証目的 オンプレミスで稼働可能な構成を AWS と OCI 上でどのように再現できるかを検討し、その設計が Oracle Database@AWS で正常に稼働可能であることを確認することを目的としました。 検証観点 閉域接続を確認するため、AWS と OCI 間での疎通検証を実施しました。さらに、RMAN を用いたバックアップ取得の可否を確認し、監視構成については、AWS 側に OMS/OMR、Exadata 環境に Oracle Enterprise Manager Management Agent を導入し、閉域接続を介して CPU 使用率や I/Oなどのメトリクスを収集し、Oracle Enterprise Manager（以下、OEM）サーバに転送できることを確認しました。 ※ Oracle Enterprise Manager (OEM) Management Agent は、ホスト上で実行中のターゲットをモニタリングし、その情報を中間層 Oracle Management Service (OMS) に送信するソフトウェアコンポーネントです。詳細については、Oracle ドキュメントの「 Oracle Enterprise Manager Cloud Control 12c の概要 」と「 Oracle Enterprise Manager Cloud Control 13c の概要 」を参照してください。 加えて、Data Guard 構成の可否を検証し、AWS 側のネットワーク、OCI 側のネットワークそれぞれでの同期が正常に行えることを確認しました。バックアップ方式については、OCI の Object Storage を利用した場合の構成手順を検証し、災害対策やデータ保護の観点からも有効な構成であることを確認しました。 OEM による監視構成 今回の検証では、OEM を用いて Oracle Database@AWS 上の Exadata 環境を監視しました。AWS 側では、Transit VPC 内に EC2 インスタンス（RHEL9）を配置し、OEM の管理サービス（以下、OMS）と管理リポジトリ（以下、OMR）を構成しました。OCI 側の Exadata データベースノードには OEM エージェントを導入し、CPU 使用率や I/O 性能などのメトリクスを収集できることを確認しました。（①の通信） ※&nbsp;Oracle Management Repository (管理リポジトリ)は、 OMA によって収集された情報が格納されるリポジトリデータベースです。詳細については、Oracle ドキュメントの「Oracle Enterprise Manager Cloud Control 12c の概要」と「Oracle Enterprise Manager Cloud Control 13c の概要」を参照してください。 OCI 側では VCN 内に Compute インスタンス（RHEL9）を配置し、同様に監視エージェントを導入することで、Exadata の稼働状況を確認しました。(②の通信) これにより、AWS と OCI 双方から Exadata のメトリクス収集と可視化が可能となり、閉域接続を介した監視構成の有効性を確認しました。 Data GuardによるDR構成 今回の検証では、Data Guard を利用して DR サイトへのデータベース同期を実現しました。AWS 側（①の通信）と OCI 側（②の通信）から Oracle Database@AWS の Exadata 環境に対して Data Guard 構成を設定し、OCI コンソールの作業リクエストで「スタンバイデータベースの作成」が成功したことにより、構成が正常に完了したことを確認しました。 障害発生時には AWS リージョンまたは OCI リージョンのいずれかでフェイルオーバが可能となり、高可用性と災害対策の観点で有効性を確認できました。 当初は、バージニア北部環境とオレゴン環境の ODB ネットワーク間の通信を VPC ピアリングで構成することを検討しました。しかし、 VPC ピアリング では推移的な接続がサポートされないため、複数ネットワーク間の経路確立ができませんでした。そこで、Transit Gateway を利用した構成に変更した結果、期待通りの通信が可能となりました。 検証結果 閉域接続は AWS 側と OCI 側の双方で問題なく成立し、Oracle Database@AWS からのバックアップ取得も可能であることを確認しました。監視構成についても、メトリクス転送が正常に行えることを確認しています。これにより、東京リージョンでの設計においても同様の構成が適用可能であると考えています。 さらに、Data Guard による DR 構成が有効であり、フェイルオーバが可能であることを確認しました。これにより、災害対策の観点からも高い信頼性を確保できることを確認しました。 まとめ 今回の検証は、東京リージョンでの設計に向けた参考情報として、閉域接続やバックアップ構成の成立を確認することを目的としました。今後は東京リージョンでの再検証を行い、運用設計に反映していく予定です。 執筆者 田村 俊樹 (パナソニック インフォメーションシステムズ株式会社 インフラソリューション本部 プラットフォームサービス事業部 インフラ標準サービス部 DB基盤チーム) データベースエンジニアとして、Oracle Database の運用・保守に10年以上従事。2025年に現在の会社へ転職し、AWS Certified Solutions Architect Professional、OCI Architect Professional、ORACLE MASTER Gold、情報処理安全確保支援士などの資格取得で培った知識を活かし、AWS と OCI を中心としたクラウド環境の設計・構築・運用・保守、および IaC による自動化に取り組む。

本記事は「 Kiro 0.9: Custom subagents in the IDE, new enterprise controls, and granular code review 」を翻訳したものです。 このリリースでは、開発者の作業速度を落とすことなくより多くのコントロールを提供し、同時にエンタープライズチームが必要とするガバナンスも提供する新機能を IDE に追加しました。カスタムサブエージェント、Skills サポート、よりスマートなリファクタリングツールを提供します。詳しく見ていきましょう。 カスタムサブエージェント: 独自のスペシャリストを構築 サブエージェントは数リリース前から存在していましたが、汎用的なものでした。多くの方々から、さまざまなユースケースに合わせて動作をカスタマイズできるようにしてほしいという要望をいただいていました。 繰り返し出てきたシナリオの一つをご紹介します: あるチームが React フロントエンドと Python バックエンドを持っています。1 つのエージェントコンテキストが両方を処理するため、すべてのツール (Chrome DevTools、データベース MCP サーバー、コンポーネントライブラリ、API ドキュメント) を読み込むことになります。コンテキストウィンドウがすぐにいっぱいになり、パフォーマンスが低下し始めます。 カスタムサブエージェントを使用すると、これを分割できます。コンポーネントとブラウザツールについて知っている frontend-agent を作成します。データベースサーバーと API ドキュメントを読み込む backend-agent を作成します。各サブエージェントは集中した状態を保ち、独自のコンテキストを管理します。 エンタープライズチームがより多くのコントロールと柔軟性を獲得 組織管理者は、プラグインとツールへのアクセスをより適切に管理できるようになりました。 拡張機能レジストリガバナンス — Kiro IDE を独自の VS Code 拡張機能レジストリに向けることができます。セキュリティチームは利用可能なものをキュレーションでき、開発者は必要な拡張機能を事前承認されたリストから入手できます。 Web ツールトグル – ワークフローやセキュリティニーズに基づいて、Web ツール (Web 検索と Web フェッチ) を有効または無効にできるようになりました。 組織管理者からは、ツール全体でのユーザーレベルの使用状況メトリクスも要望されています。私たちは積極的に取り組んでおり、今後数週間でこの機能の最初のバージョンをリリースする予定です。 Agent Skills : 必要なときに読み込まれるモジュール式の指示 オープンな agentskills.io 標準に基づいた Agent Skills のサポートを導入します。Skills は、エージェントに新しい機能を教えるモジュール式の指示パッケージです。Skills を考える良い方法は、ワークフローにドロップできる専門知識です。 Steering と Powers があるのに、なぜ Skills が必要なのでしょうか? Steering ファイルは常時オンのガイダンスには最適ですが、関連性がある場合にのみ読み込まれる特化した知識が必要な場合があります。Terraform Skillは、React コンポーネントを書いているときにコンテキストを消費すべきではありません。セキュリティレビュー Skill は、通常のリファクタリング中にアクティブであるべきではありません。Powers はこの問題を解決しますが、Skills のスーパーセットであり、MCP サーバーとルールも含まれており、必要ない場合があります。Skills はプログレッシブディスクロージャーを使用します。起動時、Kiro は各 Skill の名前と説明のみを読み込みます。エージェントが Skills が関連していると判断した場合 (または明示的に要求した場合)、完全な指示がコンテキストに読み込まれます。これにより、実際に専門知識が必要になるまでコンテキストウィンドウをスリムに保ちます。 Skills は、どこでも必要な機能のためにユーザーレベル ( ~/.kiro/skills/ ) 、またはプロジェクト固有の知識のためにワークスペースレベルでインストールできます。名前が衝突した場合、ワークスペース Skill が優先されるため、チームはグローバルデフォルトをオーバーライドできます。各 Skill は SKILL.md ファイルを持つ独自のディレクトリに存在し、エージェントが参照できるスクリプトとリソースを含めることができます。 Steering と Powers との区別は意図的なものです。Steering ファイルはエージェントの動作 (コーディング標準、プロジェクト規約、常に適用すべきもの) を指示します。Skills は、エージェントがオンデマンドで学習する機能です。両方とも同じ UI に表示されますが、異なる目的を果たし、異なる方法で読み込まれます。 他の AI コーディングツールで Skills をすでに使用しているチームの場合、フォーマットは互換性があります。既存の Skills を .kiro/skills/ ディレクトリにドロップするだけで動作します。 エージェントによるスマートなリファクタリング リファクタリングは、単なる大規模な検索と置換ではありません。ワークスペース全体のグラフトラバーサル問題です。シンボルの名前を変更したり、ファイルを移動したりすると、変更はさまざまな呼び出しサイト、インポートステートメントなどに連鎖します。その結果、エージェントはこれらの参照の一部を見逃したり、更新するのに多くのターンを要したりして、リファクタリング時につまずくことがよくあります。 これを修正するために、言語サーバーによって駆動される IDE リファクタリング機能をエージェントに直接公開する 2 つの新しいリファクタリングツールを作成しました。これらのツールを使用すると、エージェントがシンボルの名前を変更したり、ファイルを移動したりする必要がある場合、適切なリファクタリングツールを選択して呼び出すため、連鎖的な更新が自動的かつ確実に適用されます。 初期の使用では、エージェントがリファクタリング操作をエンドツーエンドでより速く完了し、その結果としてビルド、コンパイル、ランタイムエラーが少なくなることが示されています。 この新機能の詳細については、エンジニアリング詳細ブログ記事をご覧ください 。 0.9 のまとめ 個々の開発者は、サブエージェントを通じてワークフローのカスタマイズを簡単に行えるようになりました。組織はより正確なガバナンスコントロールを取得します。すべての人が、エージェントの動作方法とコードに加えられる変更をより適切に制御できるようになります。各機能は、重要な場所でコントロールを提供します。 IDE を 0.9 に更新 して開始してください。

本記事は「 Open weight models are here: more choice, more speed, less cost 」を翻訳したものです。 当初から、私たちは Kiro を最高の AI コーディング体験を提供できるように構築してきました。それは、現在の最先端コーディングモデルを搭載し、高品質な出力を中心にすべてを構築することを意味していました。6 ヶ月前、私たちは Auto を導入しました。これは、フロンティアモデルと特化型モデルを組み合わせ、インテント検出、キャッシング、その他の最適化技術を重ねることで、パフォーマンス、効率性、出力品質に優れたバランスを提供するエージェントモードです。本日、Kiro にオープンウェイトモデルを追加し、IDE と CLI の両方で利用可能になりました。 速度、品質、コスト効率の優れた組み合わせ 私たちはオープンウェイト分野を注意深く見守ってきましたが、その進歩は目覚ましいものがあります。1 年前であればプロプライエタリなオプションに大きく遅れをとっていたであろうモデルが、今では多くの開発タスクにおいて真に競争力のある結果を提供しています。高速で、コスト効率が良く、そして改善を続けています。多くの方々がこれらのモデルを独自に試し、直接サポートするよう私たちに要望を寄せてくださいました。その声をお聞きしました。 オープンウェイトモデルは、作業方法においてより多くの選択肢を提供します。すべてのタスクが最も重いモデルを必要とするわけではありません。クイックイテレーション、ボイラープレート生成、単純なリファクタリングには、生の推論能力よりも速度と低コストが必要です。他のタスクは、強力なエージェント機能や特化した言語サポートを必要とします。さまざまなモデルを持つことで、仕事に合わせてツールを選択できます。 モデル 本日から利用可能になるモデルと、それぞれが優れている分野をご紹介します。 DeepSeek v3.2 (0.25x クレジット) — スパース Mixture-of-Experts アーキテクチャに基づいて構築された DeepSeek v3.2 は、タスクごとに必要なパラメータのみをアクティブ化します。エマルチステップのツール呼び出し、長いセッション全体での状態維持、複雑な推論チェーンなど、エージェントワークフローに優れています。初期コード生成には優れていますが、複雑なデバッグやコードレビューの品質には課題がある場合があります。エージェントを構築している場合や、複雑なデバッグセッションに取り組んでいる場合は、これが強力な選択肢です。 MiniMax 2.1 (0.15x クレジット) — このモデルは多言語プログラミングで際立っています。Rust、Java、Go、C++、Kotlin、TypeScript、JavaScript などで優れた結果を提供します。また、Web、Android、iOS の UI 生成機能も特に優れています。開発者は、フロンティアモデルと比較して複雑なリファクタリングタスクに苦労する可能性があることに気づいています。チームが複数の言語で作業している場合や、フロントエンド開発が多い場合は、MiniMax 2.1 を試す価値があります。 Qwen3 Coder Next (0.05x クレジット) — トークンあたりわずか 3B パラメータをアクティブ化する 80B スパース MoE モデルである Qwen3 Coder Next は、コーディングエージェント向けに特別に構築されています。SWE-Bench Verified で 70% 以上のスコアを獲得し、256K コンテキストをサポートし、エラー検出、リカバリ、ツール呼び出しにおいて強力な機能を持っています。コミュニティは、より一貫した結果を得るために慎重な設定が必要な互換性と統合の課題をいくつか指摘しています。長いエージェントコーディングセッションを確実に処理する効率的なモデルが必要な場合、特に CLI では、Qwen3 を試してみてください。 IDE と CLI で試してみてください すべてのモデルは、 IDE モデルセレクター と Kiro CLI で実験的サポートとして現在利用可能で、Google、GitHub、AWS BuilderID でログインする無料ユーザーと有料ユーザーの両方が利用できます。推論は AWS US East (N. Virginia) リージョンで実行されます。モデルを切り替えたり、Auto と組み合わせたり、特定のプロジェクトタイプのデフォルトを設定したりできます。いつものように、実験して これらがどのように機能しているかお知らせください 。どのモデルが共感を呼び、どのようなギャップが残っているかに細心の注意を払っています。次にサポートしてほしいモデルがある場合は、 お知らせください 。

本記事は 2026/02/04に投稿された Auto Analyze in Aurora DSQL: Managed optimizer statistics in a multi-Region database を翻訳した記事です。 Amazon Aurora DSQL &nbsp;および他の最新のリレーショナルデータベースシステムにおいて、正確な統計情報はクエリプランにおける最も重要な要因の一つです。悪いクエリプランを良いクエリプランの代わりに誤って選択してしまうと、100倍の性能低下を引き起こす可能性があります。プランのリグレッションが発生するリスクを最小化するために、最新の統計情報が重要です。この投稿では、DSQL オプティマイザー統計を自動的に計算する確率的かつ事実上ステートレスな手法である Aurora DSQL Auto Analyze について解説します。PostgreSQL に精通しているユーザーは、 autovacuum analyze &nbsp;との類似性を理解していただけるでしょう。 クエリパフォーマンスにおける統計情報の重要性 統計情報がクエリパフォーマンスに与える影響を説明するために、オプティマイザーがフルテーブルスキャンまたはインデックススキャンを使用してデータにアクセスするかを選択できる基本的な例を見てみましょう。統計情報の効果を説明するために、内部パラメータを使用してAuto Analyzeを無効にしました。お客様にとって、Auto Analyze は常に有効になっており、無効にするオプションはありません。 まず、int 型の列 A とtext 型の列 B を持つテーブルを生成します。また、列 A にインデックスを作成します。次に、このテーブルに 600,000 行を挿入します。この例では、列 A に注目します。300,000 行は 0 から 299,999 までの A 値を含みます。残りの 300,000 行は A 値が 42 です。 create table mytable (A int, B text); create index async mytableidx on mytable(A); SELECT 'INSERT INTO mytable SELECT generate_series(3000 * ' || i-1 || ', 3000 * ' || i || ' - 1), ''AWS Aurora DSQL is great'';' FROM generate_series(1, 100) i; \gexec SELECT 'INSERT INTO mytable SELECT 42, ''AWS Aurora DSQL is great'' FROM generate_series(1, 3000);' FROM generate_series(1, 100); \gexec 以下のクエリを使用して、 A 値が 42 の行が 300,001 行あることを確認します。したがって、 A 値が 42 の行は全体の半分以上を占めています。 SELECT count(*) FROM mytable GROUP BY GROUPING SETS (A = 42); count -------- 299999 300001 (2 rows) 以下のコマンドを実行して、 A 値が 42 の全ての行を選択する場合に、オプティマイザーがどのプランを選択するかを観察してみましょう。 EXPLAIN ANALYZE SELECT * FROM mytable WHERE A = 42; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------ Index Scan using mytableidx on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual time=15.926..5217.368 rows=300001 loops=1) Index Cond: (a = 42) -&gt; Storage Scan on mytableidx (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) -&gt; B-Tree Scan on mytableidx (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Index Cond: (a = 42) -&gt; Storage Lookup on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Projections: a, b -&gt; B-Tree Lookup on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Planning Time: 3.367 ms Execution Time: 5228.314 ms (10 rows) 選択されたプランにはインデックススキャンが含まれていることがわかります。 A = 42 が半数を占めることから、明らかにインデックスからの間接参照のコストを避けて、フルテーブルスキャンを選択することが期待されます。 オプティマイザーが最適なプランを見つけるのを助けるために、テーブルで ANALYZE を実行します。 ANALYZE mytable; 今度は選択されたプランにフルテーブルスキャンが含まれています。クエリは半分以下の時間で完了するようになりました。 EXPLAIN ANALYZE SELECT * FROM mytable WHERE A = 42; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------- Full Scan (btree-table) on mytable (cost=74756.80..87915.45 rows=296975 width=32) (actual time=1.179..1977.851 rows=300001 loops=1) -&gt; Storage Scan on mytable (cost=74756.80..87915.45 rows=296975 width=32) (actual rows=300001 loops=1) Projections: a, b Filters: (a = 42) Rows Filtered: 299999 -&gt; B-Tree Scan on mytable (cost=74756.80..87915.45 rows=597254 width=32) (actual rows=600000 loops=1) Planning Time: 5.055 ms Execution Time: 1989.230 ms (8 rows) Aurora DSQL クラスターでこの例を再現すると、手動で analyze を実行する前でも、フルテーブルスキャンを使用する高速なクエリプランが得られることがわかります。Auto Analyze がバックグラウンドで自動的に統計情報を計算し、このパフォーマンス向上を提供してくれます。 Aurora DSQL における Auto Analyze このセクションでは、まず PostgreSQL の autovacuuming について再確認します。次に、Aurora DSQL が マルチAWSリージョン 環境において、事実上無制限のスケールで2つの構成要素を通じて PostgreSQL の動作を模倣する方法を説明します。 PostgreSQL では、 ANALYZE は autovacuum デーモン ( AUTOVACUUM ) を通じて自動的にトリガーされます。これはテーブルの変更を継続的に監視し、事前定義された閾値に達した時（通常はテーブルの行の 10% が挿入、更新、または削除された後）に統計情報を更新します。詳細については、 autovacuumデーモン のPostgreSQL ドキュメントを参照してください。 Aurora DSQL において、Auto Analyze 機能は PostgreSQL の autovacuum による ANALYZE 処理プロセスに相当し、クエリプランニングに不可欠なテーブル統計情報を自動的に維持します。PostgreSQL の決定論的な閾値ベースのアプローチとは異なり、DSQL は 2 つの主要な構成要素に基づいたマルチリージョン対応のソリューションを実装しています： 確率的トリガー がトリガーメカニズムとして機能します。テーブルの変更を監視・追跡する代わりに、各トランザクションは、テーブルサイズに対して変更する行数に基づいて ANALYZE をトリガーする確率を計算します。この確率的アプローチにより、セッション間の調整の必要性がなくなり、テーブルの進化に応じて統計情報が更新されることを保証します。 サンプリングベースの analyze 手法 が実際の統計計算を処理します。トリガーされると、ANALYZE はサンプリング技術を使用して、大規模なマルチテラバイトテーブルであっても効率的に正確な統計情報を計算し、Aurora DSQL が事実上無制限のテーブルサイズにスケールできるようにします。 確率的トリガー Aurora DSQL は、テーブル統計情報をいつ更新するかを決定するために、Auto Analyze の確率的トリガーを使用します。コミットする各トランザクションは、テーブルサイズと挿入、更新、削除操作を通じて行う変更数に依存する ANALYZE をトリガーする確率を持ちます。 ANALYZE のトリガーはトランザクションのパフォーマンスに大きな影響を与えないことに注意してください。このセクションでは、トランザクションの ANALYZE 確率がどのように決定されるかを説明します。 Aurora DSQL は各トランザクション内でテーブルごとの変更を追跡します。トランザクションがコミットされると、変更された各テーブルが 10% の閾値比に対して評価されます。トランザクションがテーブルの行の 10% 以上を変更する場合、 ANALYZE は常にトリガーされます。より小さな変更の場合、 ANALYZE をトリガーする確率は変更された行の割合に比例します。 Let threshold_ratio = 0.1 for each modified table R: change_count = num_inserts + num_updates + num_deletes threshold_count = threshold_ratio * pg_class.reltuples(R) probability = change_count / threshold_count if random_number(0,1) &lt;= probability: submit_job("ANALYZE R") この説明は現在、100万行以上のテーブルについてのみ正確です。より小さなテーブルについては、Aurora DSQLの別のクエリプロセッサで実行される ANALYZE のセットアップコストを考慮した減衰係数があります。 この確率的アプローチは、データベースセッション間の調整を必要とせずに、平均してテーブルの 10% が変更された後に ANALYZE をトリガーします。システムは、確率を計算するために pg_class.reltuples (以前の ANALYZE 実行によって設定される) からの行数推定値を使用し、分析されていないテーブルについてはデフォルトで1行とします。 確率的メカニズムはワークロードパターンに自然に適応します。頻繁に変更されるテーブルでは、統計情報がより頻繁に更新されます。逆に、静的なテーブルでは不要な ANALYZE オーバーヘッドを回避します。 サンプリングベースの ANALYZE Aurora DSQL が ANALYZE 操作をトリガーすると、テーブル全体をスキャンすることなく効率的に正確な統計情報を計算するためにサンプリングを使用します。システムは最低30,000行のサンプルを収集するように設計されたサンプリング率を計算し、大きなテーブルではさらに多くの行を収集します。このサンプルは pg_class のテーブル全体の統計情報を計算するために使用されます。その後、PostgreSQLと同様に、厳密な30,000行のサブセットが列固有の統計情報を生成するために使用されます。 私たちの手法は、計算された確率に基づいてストレージから行をランダムに選択することで機能します。このアプローチは PostgreSQL のサンプリング手法を反映しながら、Aurora DSQL の分散アーキテクチャに適応しています。サンプリング率は、以前の統計情報から推定されるテーブルサイズに対する目標行数によって決定されます。 前述したように、収集されたサンプルは2種類の統計情報を生成します： pg_class に格納されるテーブル全体の統計情報と、pg_stats&nbsp;の列固有の統計情報です。テーブル全体の推定値は行数とページ数の推定値です。 pg_stats の列固有の統計情報には、null値の割合、個別値の比率、ヒストグラム、最頻値が含まれます。これらの統計情報は、効率的な実行プランを生成するために必要な情報をクエリオプティマイザーに提供します。 Aurora DSQLが使用するサンプリングベースの Analyze 手法は、テーブルの成長に関係なく一貫したサンプルサイズを提供することで、マルチテラバイトのテーブルであっても効率的な計算を保証します。実験では、最大240TBまでのあらゆるサイズのテーブルで ANALYZE が数分で完了することがわかりました。 まとめ この投稿では、Aurora DSQL の Auto Analyze 機能について学びました。Auto Analyze は、分散マルチリージョンデータベースシステム特有の課題に対処しながら、PostgreSQL の autovacuum による ANALYZE の信頼性を提供します。確率的トリガーと効率的なサンプリングベースの計算を組み合わせることで、手動介入なしにクエリが適切に維持された統計情報から一貫して恩恵を受けることができます。確率的アプローチは、従来の閾値ベースのシステムが必要とする調整オーバーヘッドの多くを排除し、分散アーキテクチャに自然に適しています。一方、サンプリングベースの分析は、小さなテーブルから大規模な 240TB のデータセットまでスケールします。Aurora DSQL Auto Analyze は、バックグラウンドで透過的に動作しながら、適切に維持されたオプティマイザー統計情報の利点を提供し、開発者がテーブル統計の管理ではなくアプリケーションの構築に集中できるようにします。 Aurora DSQL Auto Analyze は、 Aurora DSQLが利用可能なすべてのリージョン で利用できます。Aurora DSQL の詳細については、 ウェブページ と ドキュメント をご覧ください。 Magnus Mueller Magnus &nbsp;は AWS の応用科学者で、カーディナリティ推定、クエリ最適化、システム向け機械学習を専門としています。カーディナリティ推定の博士号を取得し、主要なデータベース会議で研究を発表しています。 James Morle James &nbsp;はプリンシパルエンジニア兼分散データベースアーキテクトで、ハイパースケールでの大規模トランザクショナル・分析システムの設計・実装において 20 年以上の経験を持ちます。 Matthys Strydom Matthys &nbsp;は AWS のプリンシパルエンジニアで、分散データベースクエリ処理、AWS クラウドサービスコントロールプレーン、高スループット電話網統合、デスクトップCADプログラムなど、幅広いソフトウェアシステムにおいて 20 年以上の経験を持ちます。 Vishwas Karthiveerya Vishwas &nbsp;は AWS のシニアソフトウェア開発・データベースシステムエンジニアで、大規模分散データベースのクエリプランニング、コストベース最適化、実行性能を専門としています。 Raluca Constantin Raluca &nbsp;は AWSのシニアデータベースエンジニアで、Amazon Aurora DSQL を専門としています。Oracle、MySQL、PostgreSQL およびクラウドネイティブソリューションにわたる 18年のデータベース専門知識を持ち、データベースのスケーラビリティ、性能、リアルタイムデータ処理に焦点を当てています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。

本記事は 2026 年 2 月 12 日 に公開された「 Matching your Ingestion Strategy with your OpenSearch Query Patterns 」を翻訳したものです。 Amazon OpenSearch Service クラスターで適切なインデックス戦略を選択すると、効率性を維持しながら低レイテンシーで正確な結果を得られます。アクセスパターンに複雑なクエリが必要な場合は、インデックス戦略を見直すことをお勧めします。 本記事では、OpenSearch でカスタムインデックスアナライザーを作成し、 Edge n-gram トークナイザー を使ってワイルドカードを使わずにプレフィックスクエリをマッチさせ、オートコンプリート機能を効率的に実装する方法を紹介します。 インデックスアナライザーとは インデックスアナライザー は、ドキュメントの取り込み時にテキストフィールドを解析します。アナライザーが出力するトークンを使ってクエリをマッチングします。 デフォルトでは、OpenSearch は 標準インデックスアナライザー でデータをインデックスします。標準インデックスアナライザーは、スペースでトークンを分割し、小文字に変換し、ほとんどの句読点を除去します。ログ分析などのユースケースでは、標準インデックスアナライザーだけで十分な場合もあります。 標準インデックスアナライザー 標準インデックスアナライザーの動作を見てみましょう。 _analyze API を使って、標準インデックスアナライザーが「Standard Index Analyzer.」という文をどのようにトークン化するかテストします。 注意 : 本記事のコマンドはすべて、OpenSearch Dashboard の DevTools で実行できます。 GET /_analyze { "analyzer": "standard", "text": "Standard Index Analyzer." } #======== #Results #======== { "tokens": [ { "token": "standard", "start_offset": 0, "end_offset": 8, "type": "&lt;ALPHANUM&gt;", "position": 0 }, { "token": "index", "start_offset": 9, "end_offset": 14, "type": "&lt;ALPHANUM&gt;", "position": 1 }, { "token": "analyzer", "start_offset": 15, "end_offset": 23, "type": "&lt;ALPHANUM&gt;", "position": 2 } ] } 各単語が小文字に変換され、ピリオド (句読点) が除去されていることがわかります。 独自のインデックスアナライザーを作成する OpenSearch には、さまざまなアクセスパターンに対応する多数の組み込みアナライザーが用意されています。また、特定の検索ニーズに合わせたカスタムアナライザーも構築できます。次の例では、住所リストに対して部分一致を返すカスタムアナライザーを設定します。このアナライザーは オートコンプリート 機能向けに設計されており、ユーザーが住所全体を入力しなくても素早く住所を見つけられます。オートコンプリートにより、マッチしたプレフィックスに基づいて検索語を補完できます。 まず、 standard_index_test というインデックスを作成します。 PUT standard_index_test { "mappings": { "properties": { "text_entry": { "type": "text", "analyzer": "standard" } } } } 標準アナライザーはデフォルトのアナライザーであるため、analyzer に standard を指定する必要はありません。 テストのために、作成した standard_index_test にデータを一括追加します。 POST _bulk {"index":{"_index":"standard_index_test"}} {"text_entry": "123 Amazon Street Seattle, Wa 12345 "} {"index":{"_index":"standard_index_test"}} {"text_entry": "456 OpenSearch Drive Anytown, Ny 78910"} {"index":{"_index":"standard_index_test"}} {"text_entry": "789 Palm way Ocean Ave, Ca 33345"} {"index":{"_index":"standard_index_test"}} {"text_entry": "987 Openworld Street, Tx 48981"} 「ope」というテキストでデータをクエリします。 GET standard_index_test/_search { "query": { "match": { "text_entry": { "query": "ope" } } } } #======== #Results #======== { "took": 2, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 0, "relation": "eq" }, "max_score": null, "hits": [] # No matches } } 「ope」で検索しても結果が返りません。理由を確認するために、標準インデックスアナライザーがテキストをどのようにトークン化しているか詳しく見てみましょう。標準インデックスアナライザーで住所「456 OpenSearch Drive Anytown, Ny 78910」をテストします。 POST standard_index_test/_analyze { "analyzer": "standard", "text": "456 OpenSearch Drive Anytown, Ny 78910" } #======== #Results #======== "tokens": "456" "opensearch" "drive" "anytown" "ny" "78910" 標準インデックスアナライザーは住所を 456 、 opensearch 、 drive などの個別のトークンに分割しています。つまり、個別のトークン ( 456 や opensearch など) を検索しない限り、 o 、 op 、 ope 、さらには open でも結果は返りません。1 つの方法として、インデックスには標準インデックスアナライザーを使いつつ、 ワイルドカード を使う方法があります。 GET standard_index_test/_search { "query": { "wildcard": { "text_entry": "ope*" } } } ワイルドカードクエリは「456 OpenSearch Drive Anytown, Ny 78910」にマッチしますが、ワイルドカードクエリはリソース消費が大きく低速になる可能性があります。OpenSearch で ope* をクエリすると、 転置インデックス のルックアップ最適化をバイパスして、インデックス内の各トークンを反復処理します。メモリ使用量が増加し、パフォーマンスが低下します。クエリと検索のパフォーマンスを向上させるには、アクセスパターンに適したインデックスアナライザーを使用します。 Edge n-gram Edge n-gram トークナイザー は、単語のプレフィックスをトークン化することで、ワイルドカードを使わずに部分一致を実現します。たとえば、入力語 coffee は c 、 co 、 cof などすべてのプレフィックスに展開されます。最小長 ( min_gram ) と最大長 ( max_gram ) の間のプレフィックスに制限できます。 min_gram=3 、 max_gram=5 の場合、「coffee」は cof 、 coff 、 coffe に展開されます。 Edge n-gram を使用するカスタムインデックスアナライザーで custom_index という新しいインデックスを作成します。最小トークン長 ( min_gram ) を 3 文字、最大トークン長 ( max_gram ) を 20 文字に設定します。 min_gram と max_gram はそれぞれ返されるトークンの最小長と最大長を設定します。アクセスパターンに基づいて min_gram と max_gram を選択してください。この例では「ope」という語で検索するため、 o や op のような語は検索しないので最小長を 3 未満にする必要はありません。 min_gram を低く設定しすぎるとレイテンシーが高くなる可能性があります。同様に、個別のトークンが 20 文字を超えることはないため、最大長を 20 より大きくする必要はありません。最大長を 20 に設定することで、将来より長いトークン長の住所を取り込む場合にも余裕を持たせています。なお、ここで作成するインデックスはオートコンプリート機能に特化したものであり、一般的な検索インデックスには不要な場合があります。 PUT custom_index { "mappings": { "properties": { "text_entry": { "type": "text", "analyzer": "autocomplete", "search_analyzer": "standard" } } }, "settings": { "analysis": { "filter": { "edge_ngram_filter": { "type": "edge_ngram", "min_gram": 3, "max_gram": 20 } }, "analyzer": { "autocomplete": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "edge_ngram_filter" ] } } } } } 上記のコードでは、 autocomplete というカスタムアナライザーを持つ custom_index というインデックスを作成しました。このアナライザーは以下の処理を行います。 標準トークナイザーでテキストをトークンに分割する lowercase フィルターですべてのトークンを小文字に変換する edge_ngram の最小値と最大値に基づいてトークンをさらに小さなチャンクに分割する 検索アナライザーには標準アナライザーを設定し、検索時のクエリ処理を軽減しています。取り込み時にカスタムアナライザーでテキストを分割済みのため、検索時に同じ処理を繰り返す必要はありません。カスタムアナライザーが「Lexington Avenue」というテキストをどのように解析するかテストします。 GET custom_index/_analyze { "analyzer": "autocomplete", "text": "Lexington Avenue" } #======== #Results #======== # Minimum token length is 3 so we won't see l, or le "tokens": "lex" "lexi" "lexin" "lexing" "lexingt" "lexingto" "lexington" "ave" "aven" "avenu" "avenue" トークンが小文字に変換され、部分一致に対応していることがわかります。アナライザーがテキストをどのようにトークン化するか確認できたので、データを一括追加します。 POST _bulk {"index":{"_index":"custom_index"}} {"text_entry": "123 Amazon Street Seattle, Wa 12345 "} {"index":{"_index":"custom_index"}} {"text_entry": "456 OpenSearch Drive Anytown, Ny 78910"} {"index":{"_index":"custom_index"}} {"text_entry": "789 Palm way Ocean Ave, Ca 33345"} {"index":{"_index":"custom_index"}} {"text_entry": "987 Openworld Street, Tx 48981"} テストしてみましょう。 GET custom_index/_search { "query": { "match": { "text_entry": { "query": "ope" } } } } #======== #Results #======== "hits": [ { "_index": "custom_index", "_id": "aYCEIJgB4vgFQw3LmByc", "_score": 0.9733556, "_source": { "text_entry": "456 OpenSearch Drive Anytown, Ny 78910" } }, { "_index": "custom_index", "_id": "a4CEIJgB4vgFQw3LmByc", "_score": 0.4095239, "_source": { "text_entry": "987 Openworld Street, Tx 48981" } } ] カスタム n-gram アナライザーを設定して、住所リスト内の部分一致を実現できました。 なお、非標準のインデックスアナライザーの使用と計算コストの高いクエリの記述にはトレードオフがあります。アナライザーは、特に非効率に使用した場合、インデックスのスループットに影響を与え、全体のインデックスサイズを増加させる可能性があります。たとえば、 custom_index の作成時に検索アナライザーを標準アナライザーに設定しました。取り込み時と検索時の両方で n-gram を使用していれば、クラスターのパフォーマンスに不要な負荷がかかっていたでしょう。さらに、 min_gram と max_gram をアクセスパターンに合った値に設定し、検索ユースケースに必要以上の n-gram を作成しないようにしました。適切な設定により、取り込みスループットに影響を与えず、検索の最適化によるメリットを得られました。 まとめ 本記事では、オートコンプリートクエリを簡素化し高速化するために、OpenSearch のデータインデックス方法を変更しました。今回のケースでは、Edge n-gram を使用することで、ワイルドカードクエリによるクラスターパフォーマンスへの影響なしに、住所の一部をマッチさせて正確な結果を得られました。 本番環境にデプロイする前に、必ずクラスターをテストしてください。インデックスと検索の両面からクラスターを最適化するには、アクセスパターンの理解が不可欠です。本記事のガイドラインを出発点として活用してください。インデックスを作成する前にアクセスパターンを確認し、テスト環境でさまざまなインデックスアナライザーを試して、クエリの簡素化やクラスター全体のパフォーマンス向上に役立つか確認してください。OpenSearch クラスターの一般的な最適化手法については、 Get started with Amazon OpenSearch Service: T-shirt-size your domain の記事を参照してください。 著者について Rakan Kandah Rakan は、AWS のソリューションアーキテクトです。余暇にはギターの演奏や読書を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

2026 年 2 月 2 日週に行われた注目のリリースとアップデートをご紹介します。これらはすべて、AWS での構築、スケーリング、イノベーションに役立てることができます。 2026 年 2 月 2 日週のリリース こちらは、2026 年 2 月 9 日週私の目に留まったリリースです。 まず、コンピューティングとネットワークインフラストラクチャに関するニュースから始めましょう。 Amazon EC2 C8id、M8id、R8id インスタンスの導入: これらの新しい Amazon EC2 C8id、M8id、R8id インスタンスにはカスタム Intel Xeon 6 プロセッサが搭載されており、前世代のインスタンスよりも最大 43% 優れたパフォーマンスと 3.3 倍のメモリ帯域幅を提供します。 AWS Network Firewall が料金の新たな値下げを発表: AWS Network Firewall が、Network Firewall セカンダリエンドポイントとサービスチェーン接続されている NAT ゲートウェイに時間単位の割引とデータ処理割引を追加しました。また、暗号化されたネットワークトラフィックの Transport Layer Security (TLS) インスペクションを可能にする Advanced Inspection の追加データ処理料金も廃止されました。 Amazon ECS がリニアデプロイとカナリアデプロイに対する Network Load Balancer サポートを追加: NLB の使用が一般的なアプリケーション (TCP/UDP ベースの接続、低レイテンシー、長時間接続、または静的 IP アドレスを必要とするアプリケーションなど) で、更新のロールアウト時に ECS からネイティブにシフトするマネージド増分トラフィックを利用できるようになりました。 AWS Config が 30 の新しいリソースタイプのサポートを開始: これらは、Amazon EKS、Amazon Q、AWS IoT を含めた主要サービスを対象とするものです。この拡張によって AWS 環境のカバレッジ範囲が広がるため、これまで以上に広い範囲のリソースの検出、評価、監査、修正をより効果的に行うことができます。 Amazon DynamoDB グローバルテーブルが複数の AWS アカウント間でのレプリケーションのサポートを開始: DynamoDB グローバルテーブルは、フルマネージド型、サーバーレス、マルチリージョン、かつマルチアクティブなデータベースです。この新機能により、複数の AWS アカウントおよびリージョン間でテーブルをレプリケートできるため、レジリエンシーが向上するとともに、アカウントレベルでのワークロードの分離、異なるセキュリティコントロールとガバナンスコントロールの適用が可能になります。 Amazon RDS がデータベース接続のためのコンソールエクスペリエンスを強化: 新しいコンソールエクスペリエンスは、Java、Python、Node.js、その他プログラミング言語の既製のコードスニペットに加えて、 psql コマンドラインユーティリティといったツールを提供します。これらのコードスニペットは、データベースの認証設定に基づいて自動的に調整されます。例えば、クラスターが IAM 認証を使用している場合、生成されたコードスニペットはトークンベースの認証を使用してデータベースに接続します。コンソールエクスペリエンスには統合された CloudShell アクセスも含まれているため、RDS コンソール内からデータベースに直接接続できます。 次に、AWS でのセキュリティと認証方法に関する 3 つのニュース記事を見つけました。 AWS ビルダー ID が「Apple でサインイン」のサポートを開始: AWS ビルダー ID は、AWS Builder Center、AWS トレーニングと認定、AWS re:Post、AWS スタートアップ、Kiro などの AWS アプリケーションにアクセスするためのプロファイルです。この ID が、ソーシャルログインプロバイダーとしての Apple でのサインインをサポートするようになりました。サインインオプションの拡張は既存の「Google でログイン」機能を踏まえたもので、AWS で別個の認証情報を管理しなくても AWS リソースにアクセスできる効率的な手段を Apple ユーザーに提供します。 AWS STS が Google、GitHub、CircleCI、OCI からの特定のアイデンティティプロバイダー固有のクレームの検証をサポート: これらのカスタムクレームを IAM ロール信頼ポリシーとリソースコントロールポリシーの条件キーとして参照できるようになりました。これは、フェデレーションアイデンティティにきめ細かなアクセス制御を実装する能力を拡大するとともに、データ境界の確立にも役立ちます。この機能強化は、OIDC 互換の外部アイデンティティプロバイダー経由で認証されたユーザーに一時的な AWS 認証情報を付与できる、IAM の既存の OIDC フェデレーション機能を基盤としています。 AWS マネジメントコンソールがアカウントの特定を容易にするためのアカウント名をナビゲーションバーに表示: アカウントを一目で簡単に特定できるようになりました。今後は、アカウント内のすべての承認済みユーザーに表示されるナビゲーションバー上のアカウント名を使用して、アカウントを視覚的にすばやく区別できます。 Amazon CloudFront がオリジンに対する相互 TLS 認証サポートを発表: オリジン mTLS サポートにより、運用上の負担を排除する、標準化された証明書ベースの認証アプローチを実装できるようになりました。この機能は、組織が独自のコンテンツに厳格な認証を適用できるようにすることで、検証済みの CloudFront ディストリビューション以外は AWS オリジンとオンプレミスサーバーからサードパーティークラウドプロバイダーと外部 CDN におよぶバックエンドインフラストラクチャへの接続を確立できないようにします。 最後は AI 関連のニュースです。こうしたニュースを聞かない週はありません。 Amazon Bedrock が Claude Opus 4.6 の提供を開始: Opus 4.6 は、Anthropic 史上最高のインテリジェンスを備えたモデルであり、コーディング、エンタープライズエージェント、専門的業務のためのプレミアモデルです。Claude Opus 4.6 は、エージェンティックタスク、複雑なコーディングプロジェクト、深層推論と信頼性を必要とするエンタープライズグレードのワークフローのための業界トップクラスのパフォーマンスを含めた高度な機能性を Amazon Bedrock のお客様に提供します。 Amazon Bedrock が構造化出力の提供を開始: Amazon Bedrock が構造化出力のサポートを開始しました。これは、基盤モデルからユーザー定義の JSON スキーマに準拠した一貫性のある機械読み取り可能な応答を提供する機能です。プロンプトで有効な JSON を指定したり、アプリケーションで追加のチェックを行ったりする代わりに、必要な形式を指定して、その形式に合った応答を受け取ることができるため、プロダクションワークフローの予測可能性とレジリエンシーが向上します。 今後の AWS イベント カレンダーを確認して、近日開催予定のイベントにサインアップしましょう。 AWS Community Day Romania (2026 年 4 月 23～24 日): このコミュニティ主導の AWS イベントでは、AWS ヒーロー、ソリューションアーキテクト、および業界エキスパートによる 10 を超えるプロフェッショナルセッションのために、開発者、アーキテクト、起業家、学生が一堂に会します。参加者は、エキスパートによるテクニカルトーク、世界的なカンファレンスで経験を積んだ講演者からのインサイト、参加者だけのネットワーキングブレイクでつながる機会を得られ、これらのすべてがコラボレーションとコミュニティエンゲージメントをサポートするために設計されたプレミアム会場で行われます。 このイベント外でもつながりを維持する方法をお探しの場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学び、構築し、つながりましょう。 2026 年 2 月 16 日週の Weekly Roundup もお楽しみに! – seb 原文は こちら です。

こんにちは。ソリューションアーキテクトの松本 敢大です。三井物産デジタル・アセットマネジメント株式会社（以下、MDM）では、デジタル証券や資産運用のビジネスを展開しており、金融機関として高いセキュリティ要件を満たすことが求められています。本ブログは、MDM が Amazon Security Lake を活用して SIEM の限界を超え、セキュリティデータ基盤を構築した事例について、Chief Information Security Officer 鈴木様から寄稿していただいたものです。 背景 AWS： Security Lake の導入に至った背景を教えてください。 鈴木様： 当社は証券会社として、昨今の証券会社に対する監査要件の強化を受け、セキュリティ対策の強化が必要でした。特に不正アクセス対策や本人確認などの要件に対応するため、セキュリティログの一元管理と高度な分析が必要になりました。 従来は主に 3rd party の SEIM を利用していましたが、以下のような課題を感じていました。 監査ログ以外にも、ユーザーやデバイスの資産情報、権限情報、ネットワークトラフィックなど多様なデータを相関分析する必要があった VPC Flow Log や Route53 Query Log などの大容量データを長期間保存するコストが高額になりがち データの種別に応じてサービスを使い分けると、データ連携やクエリ言語の習熟に工数がかかる SIEM ではデータの自由度が限定的で、独自のユースケースに対応するカスタマイズが困難 こうした課題から、「メンテナンスや運用、対応策にかかるコストと工数に比して、自社の持てるコントロールや自由度が限定的」という課題を既存の SIEM に感じていました。そこで次世代のセキュリティ管理を行うため、Amazon Security Lake を活用したデータ基盤の構築に着手しました。 ソリューション 鈴木様： Amazon Security Lake を中心とした構成は下図の通りです。複数のソースシステムからログを取り込み、Archive 専用の S3 に保存後、Object Replication により分析アカウントにレプリケートしています。続いて Lambda がデータを OCSF（Open CyberSecurity Schema Framework）に変換し、Security Lake に投入します。そして、Lambda が日次でセキュリティ監査用のジョブを実行する仕組みになっています。 ソースシステムは当初からあまり変わっていませんが、AppFabric と DataDog の使い分けについては、基本的に DataDog を優先しています。AppFabric は DataDog に連携できないソースシステムにのみ利用しています。 現在実装しているユースケースとしては以下があります。 長期間活動のないアカウントの検出と集計 サインインイベントから認証の検出と、対象ユーザーおよび認証先アプリケーションの集計 これらの分析は Athena または日次の Lambda から実行し、レポートやアラートを生成しています。このような可視化により、アカセス権限の見直しや多要素認証の強制適用などの適切なセキュリティ対策を講じることができます。 また、Security Lake が採用している Apache Iceberg テーブルフォーマットに関する理解を深めるため、メタデータ構造の分析や最適化にも取り組んでいます。 Apache Iceberg のメタデータ構造 Apache Iceberg は以下の層構造でデータを管理します。 Metadata File : スナップショットの一覧など全体情報を管理 Manifest List : スナップショット単位で複数のManifest Fileを追跡 Manifest File : 実データファイルの詳細情報・統計情報を列挙 { "snapshots" : [ { "sequence-number" : 111111, "snapshot-id" : 1111111111111111111, "parent-snapshot-id" : 1111111111111111110, "timestamp-ms" : 1738086192629, "summary" : { "operation" : "append", "added-data-files" : "7", "added-records" : "1719", "added-files-size" : "421902", "total-records" : "780945471" }, "manifest-list" : "s3://aws-security-data-lake-ap-northeast-1-xxx/aws/CLOUD_TRAIL_MGMT/2.0/metadata/snap-xxx.avro", "schema-id" : 0 } ] } このようなメタデータを用い、運用改善を図っています。 Why AWS? AWS： なぜ Security Lake を選択されたのでしょうか？ 鈴木様： 大きな理由は、コストパフォーマンスと自由度のバランスです。3rd party の SIEM も優れたサービスですが、特にVPC Flow Log や Route53 Query Log といった大容量データを考慮すると、Security Lake の方が財布に優しいです。 また、AWS 上でのデータエンジニアリングのアプローチを取ることで、セキュリティデータの取り込み・変換・提供のライフサイクル全体を AWS で完結させることができます。これにより、さまざまなデータソースを統合し、高度な分析と柔軟なカスタマイズが可能になります。 Security Lake が OCSF を採用していることも選定理由の一つです。標準化されたスキーマにより、異なるソースからのセキュリティデータを統合的に扱うことができます。また、Apache Iceberg を使用したParquet形式でのデータ保存により、効率的なクエリと分析が可能になりました。 導入効果 AWS： Security Lake 導入の効果と今後の展望について教えてください。 鈴木様： まず、コスト面での大きな効果がありました。Security Lake の月額コストは他社 SIEM よりも大幅に低く抑えられています。特に VPC Flow Log や Route53 Query Log などの大容量データを取り込む場合の差は顕著です。 運用面では、AWS 上でのデータエンジニアリングのアプローチにより、データの取り込み・変換・分析の各フェーズでの柔軟性が向上しました。例えば、特定の監査ニーズに応じたカスタム分析ジョブを追加したり、新しいデータソースを統合したりすることが容易になっています。 今後の展望 鈴木様： 将来的には、フルマネージドサービスと AWS 上でのカスタム開発を組み合わせることで、セキュリティデータを中心とした本格的なデータレイクハウスの構築を目指しています。これにより、リアルタイム性の要求されるセキュリティ監視とバッチ処理による詳細分析の両立、過去データの機械学習モデルへの適用による異常検知の高度化などを実現したいと考えています。 また、今後 S3 Tables など新しいサービスの利用も視野に入れながら、より効率的なデータ管理と分析基盤の構築を進めていく予定です。 著者について 三井物産デジタル・アセットマネジメント株式会社 鈴木 研吾 三井物産デジタル・アセットマネジメント株式会社にて、サイバーセキュリティ・インフラ・社内基盤担当などを担当。前職では SOC での経験もあり、ユーザー企業でのセキュリティ運用に造詣が深い。セキュリティ基盤の構築に取り組んでいる。 経歴 NRIセキュアにて証券会社むけMSSに勤務（2010～2014) Fintech企業（2014～2018）、証券会社（2018～2020）にてモバイルアプリ開発やSREをしつつセキュリティ関連に従事 LayerX株式会社及び出向先の三井物産デジタル・アセットマネジメント株式会社でセキュリティエンジニア（2020～） デジタル庁にも勤務（2021～) 個人活動: Secure旅団というセキュリティ系サークルで同人誌、週刊ニュースまとめ、Podcast、監訳・翻訳 セキュリティ・キャンプ全国大会講師（2019, 2023） アマゾンウェブサービスジャパン合同会社 松本 敢大 (Kanta Matsumoto) ソリューションアーキテクトとして、商社業界のお客様を中心に技術支援を行っています。様々な領域を扱う商社という業界で沢山の刺激を受けております。 新入社員育成として、生成 AI 活用ブログ（ ブログ1 、 ブログ2 、 ブログ3 、 ブログ4 ）などを投稿。 AWS User Group – Japan IoT 支部で登壇などをしております。Physical AI が最近のブームです。 好きな AWS サービスは AWS IoT Core（ ブログ ）。趣味はカメラで、動物が好きです。

本ブログは 2025 年 7 月 24 日に公開された AWS Blog “ Post-quantum TLS in Python ” を翻訳したものです。 Amazon Web Services (AWS) では、セキュリティが最優先事項です。データの機密性を維持することは、AWS とお客様の運用環境セキュリティにおいて重要な要素です。まだ実現していませんが、暗号解読能力を持つ量子コンピュータ (CRQC: cryptographically relevant quantum computer) が登場すれば、現在使用されている公開鍵アルゴリズムを破り、データの機密性を脅かす可能性があります。こうした脅威に備えるため、米国国立標準技術研究所 (NIST) は 2016 年にCRQC に耐性のある新しい暗号アルゴリズムの 標準化に取りかかりました 。2024年8月、暗号コミュニティによる8年間の厳密な審査を経て、NIST は従来の公開鍵アルゴリズムを補完し、最終的に置き換えるための3つのポスト量子暗号 (PQC) 標準を選定しました。その中には FIPS 203 の ML-KEM が含まれています。 最近のいくつかの AWS Blog 記事では、AWS における PQC、特に ML-KEM を使用したポスト量子 TLS について説明しています。 ポスト量子 TLS とは何か、どのように機能するか ポスト量子 TLS パフォーマンスの詳細 AWS SDK for Java v2 でのポスト量子 TLS の使用 AWS PQC 移行計画 この記事では、Python アプリケーションでポスト量子 TLS をテストする方法を紹介します。 Python でのポスト量子 TLS のテスト 別の記事 で詳しく説明されているように、AWS は現在、データの機密性に対する多層防御を提供するため、従来の鍵交換と ML-KEM を併用するハイブリッド構成でポスト量子 TLS を提供しています。ML-KEM は従来の方式よりもはるかに大きな鍵を使用するため、ハイブリッド TLS ハンドシェイクでは接続確立時により多くのデータを送受信します。他のプロトコル更新と同様に、セキュリティアプライアンスやネットワークデバイスがこれらの接続を適切に処理できることを検証するために、ネットワークでハイブリッド TLS をテストすることが重要です。このようなテストに、AWS が提供するサンプルをぜひご活用ください。 ハイブリッド TLS をネゴシエートするには、接続の 両端 (クライアントとサーバー) にポスト量子対応ソフトウェアが必要です。AWS は現在、サーバー側でハイブリッド TLS の 導入を進めています 。クライアント側では、ハイブリッド TLS を有効にする方法は SDK の言語 ごとに若干異なります。 AWS SDK for Python (Boto3) は、TLS に Python インタープリターの ssl モジュールを使用しており、このモジュールはオペレーティングシステムの暗号ライブラリを使用します。ほとんどの Linux ディストリビューションでは、これは OpenSSL です。OpenSSL は最近、ハイブリッド TLS のサポートを 発表 し、バージョン 3.5 ではデフォルトで有効になっています。ただし、OpenSSL 3.5 はまだほとんどのオペレーティングシステムディストリビューションでデフォルトになっていません。 テストを可能にするため、標準の Python ディストリビューションと一緒に OpenSSL 3.5 をインストールする Dockerfile を提供しています。これにより、Python アプリケーションでポスト量子ハイブリッド TLS 接続を実行できます。この Dockerfile には、 boto3 や requests などの一般的なパッケージもインストールされています。AWS サービス ( boto3 と AWS コマンドラインインターフェイス (AWS CLI) を使用)、任意の HTTPS エンドポイント ( requests を使用)、TLS で保護された TCP サーバー (Python の標準ライブラリ ssl モジュールを使用) との基本的なやり取りを行うサンプル Python コードを提供しています。 以下のセクションでは、この Dockerfile を使用して Python アプリケーションから AWS サービスへのポスト量子 TLS 接続をテストする方法を説明します。 コンテナのビルド このコンテナはローカルマシンでビルドすることも、 Amazon Elastic Compute Cloud (Amazon EC2) や AWS CloudShell などのクラウド環境でビルドすることもできます。なお、お使いのマシンと AWS 間のネットワークパスを検証したい場合は、コンテナをローカルでビルドして実行する必要があります。コンテナをビルドするための唯一の前提条件は、Docker (または同等のコンテナツール) がインストールされていることです。簡単にするため、以下の手順では主に Linux CloudShell 環境でこれらのコマンドを実行することを想定しています。 サンプルリポジトリ をクローンします。 git clone https://github.com/aws-samples/sample-post-quantum-tls-python サンプルのディレクトリに移動し、以下のコマンドを実行してコンテナをビルドします。 cd sample-post-quantum-tls-python &amp;&amp; docker build . -t pq-tls-python コンテナの実行 前述のサンプルを実行するには、以下のコマンドを実行します。 docker run --rm \ -e AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id) \ -e AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key) \ -it pq-tls-python \ test.sh 上記のコマンドは、 AWS Secrets Manager の ListSecrets API を呼び出す権限を持つ AWS CLI のデフォルトプロファイルが設定されていることを前提としています。この権限があれば、Secrets Manager のポスト量子対応 API エンドポイントに対して、機密情報やシークレット値を返さない基本的な読み取り専用のテスト呼び出しを行うことができます。CloudShell では、 aws configure でアクセスキーとシークレットキーの値を設定する必要があります。Amazon EC2 では、 インスタンスプロファイルを設定 して、アクセスキーとシークレットキーの環境変数を不要にできます。 Python が使用する暗号ライブラリの名前とバージョンを出力した後、 test.sh は以下の順序でハイブリッド TLS 接続をテストします。 Python の socket モジュールと ssl モジュールを使用した TCP ソケット通信 requests ライブラリを使用した HTTP リクエストの実行 boto3 と AWS CLI を使用した AWS API リクエストの実行 テストが成功すると、以下の出力が表示されます。 Crypto library: OpenSSL 3.5.0 8 Apr 2025 Testing ssl socket... ok Testing requests... ok Testing boto3... ok Testing AWS CLI... ok 必要に応じて、 tests/ ディレクトリ内のサンプルを確認、変更、拡張できます。提供されている test.sh スクリプトを実行する代わりに、以下のコマンドで対話型シェルにアクセスできます。 docker run --rm -it pq-tls-python テスト用にファイルを追加または変更した場合は、必ずコンテナを再ビルドしてください。 ポスト量子 TLS ネゴシエーションの確認 ポスト量子ハイブリッド TLS がネゴシエートされたことを確認するには、サンプルの TLS ハンドシェイクを検査して、ポスト量子ハイブリッド TLS 鍵交換が実行されたことを確認します。これを行うには、ホストのネットワークトラフィックをキャプチャする必要があります。CloudShell では、以下のコマンドを使用してキャプチャできます。 sudo tcpdump -A -i docker0 -w pq_tls.pcap このコマンドにより、Docker のネットワークインターフェイス docker0 上のトラフィックがキャプチャされます。コンテナをローカルで実行している場合は、Linux の docker0 や MacOS の en0 などのローカルネットワークインターフェイスで Wireshark の GUI を使用してパケットキャプチャを実行することもできます。 次に、別のターミナルで「 コンテナの実行 」セクションの Docker run コマンドを使用してテストスイートを実行します。前述と同様に、ターミナルに成功メッセージが表示され、 tcpdump を使用している場合は pq_tls.pcap という名前の新しいファイルが作成されます。このファイルを CloudShell から ダウンロード して、ローカルの Wireshark で表示できます。具体的には、クライアントまたはサーバーの Hello ハンドシェイクメッセージ内の key_share 拡張を確認します。Wireshark を使用してパケットキャプチャを表示する場合は、表示フィルター tls.handshake を指定して、ハンドシェイクメッセージのみを表示できます。パケットキャプチャは図 1 のようになります。 図 1: Wireshark でのパケットキャプチャ表示 図 1 では、サーバーの Hello ハンドシェイクメッセージで X25519MLKEM768 が選択されており、ポスト量子ハイブリッド TLS が正常にネゴシエートされたことがわかります。 まとめ この記事では、Dockerfile を使用して Python でポスト量子ハイブリッド TLS をテストする方法を紹介しました。この AWS サンプル を使用すると、以下の通信でポスト量子ハイブリッド TLS 接続をテストできます。 boto3 または AWS CLI を使用した AWS API リクエスト requests を使用した一般的な HTTPS リクエスト Python の socket モジュールと ssl モジュールを使用した TLS で保護された TCP ソケット通信 今後のポスト量子ハイブリッド TLS 移行に備えて、この AWS サンプルを使用してネットワークと Python アプリケーションの検証を開始することをお勧めします。AWS はお客様の移行をサポートすることに尽力しており、ポスト量子ハイブリッド TLS も例外ではありません。 この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 Will Childs-Klein Will は AWS Cryptography のシニアソフトウェアエンジニアで、暗号ライブラリの開発、ソフトウェアパフォーマンスの最適化、ポスト量子暗号の実用化に注力しています。以前は AWS で Storage Gateway、Elastic File System、DataSync などのデータストレージおよび転送サービスに携わっていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 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 以降が必要です。 &lt;dependency&gt; &lt;groupId&gt;software.amazon.awssdk&lt;/groupId&gt; &lt;artifactId&gt;aws-crt-client&lt;/artifactId&gt; &lt;version&gt;2.30.22&lt;version&gt; &lt;/dependency&gt; ステップ 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, &amp; 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, &amp; Compliance re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。AWS の PQC への取り組みの詳細については、 PQC ページ を参照してください。 &nbsp; 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 &lt; your DB identifier &gt; ^ - - db - instance - class &lt; instance class &gt; ^ - - processor - features "Name=coreCount,Value=&lt;X&gt;" "Name=threadsPerCore,Value=1" - - apply - immediately Python 以下のコードは Mac 向けです： aws rds modify - db - instance \ - - db - instance - identifier &lt; your DB identifier &gt; \ - - db - instance - class &lt; instance class &gt; \ - - processor - features "Name=coreCount,Value=&lt;X&gt;" "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 &lt; your source DB identifier &gt; ^ - - target - db - instance &lt; target DB identifier &gt; ^ - - db - instance - class &lt; instance class &gt; ^ - - use - latest - restorable - time ^ - - processor - features "Name=coreCount,Value=&lt;X&gt;" "Name=threadsPerCore,Value=1" Python 以下のコードは Mac 向けです： aws rds restore - db - instance - to - point - in - time \ - - source - db - instance - identifier &lt; your source DB identifier &gt; \ - - target - db - instance &lt; target DB identifier &gt; \ - - db - instance - class &lt; instance class &gt; \ - - use - latest - restorable - time \ - - processor - features "Name=coreCount,Value=&lt;X&gt;" "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 &nbsp;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 &amp; 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 のプリンシパルデータ &amp; 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 がレビューしました。