本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ Quantum-resistant signing on AWS, Part 1: Build a software supply chain with ML-DSA ” を翻訳したものです。 ソフトウェアサプライチェーン攻撃は、頻度と巧妙さの両面で増しています。最近注目を集めた、ビルドシステムやオープンソースの依存関係の侵害事例は、ソフトウェアの完全性を検証する信頼メカニズムを攻撃者が標的にするケースが増えていることを示しています。こうした信頼メカニズムはデジタル署名アルゴリズムに依存しており、現在その多くが RSA (Rivest-Shamir-Adleman) や ECDSA (Elliptic Curve Digital Signature Algorithm) などの従来型のアルゴリズムを使用しています。十分に強力な量子コンピュータによってこれらの署名が偽造できるようになると、攻撃者は署名済みアーティファクトに不正なコードを挿入したり、ビルドアテステーションを捏造したり、正当な発行元になりすましたりできる可能性があります。耐量子署名を今から使用しておくことで、将来出現する可能性のある脅威に備えることができます。 米国国家安全保障局 (NSA) が公開した Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) は、2025 年以降、米国国家安全保障システム (NSS) に対して、ソフトウェアとファームウェアの署名に耐量子方式を「サポートし優先する (support and prefer)」ことを求めており、2030 年までには耐量子署名のみを使用することを義務付けています。 EU サイバーレジリエンス法 (CRA) は 2027 年 12 月に全面適用されます。CRA は、製品のライフサイクル全体を通じて、検証可能な形でソフトウェアの完全性を維持することを製造業者に求めています。米国連邦機関にソフトウェアを提供する組織や欧州市場で製品を販売する組織は、時期が重なる複数の期限に直面しており、今すぐ対応を始める必要があります。 Amazon Web Services (AWS) は、本番環境に対応した一般提供済みのサービスで、耐量子ソフトウェアサプライチェーンを今すぐ構築するための構成要素を提供しています。この記事では、 ML-DSA (Module-Lattice-Based Digital Signature Algorithm) キーを AWS Key Management Service (AWS KMS) で、ML-DSA 証明書階層を AWS Private Certificate Authority で、ML-DSA トラストアンカーを AWS Identity and Access Management (IAM) Roles Anywhere で用意し、それらを組み合わせて、バイナリ、コンテナイメージ、ソフトウェア部品表 (SBOM) を対象とするエンドツーエンドの署名アーキテクチャを構築する方法を紹介します。 この記事は、 NIST FIPS 204 で標準化された ML-DSA 署名を AWS で導入するための 2 部構成シリーズのパート 1 です。2026 年 10 月時点で、このシリーズは、ML-DSA の信頼のルート (root of trust) の確立から組織全体でのアルゴリズムポリシーの適用まで、ソフトウェアサプライチェーン全体にわたる耐量子署名を扱うエンドツーエンドのガイドとして、クラウドプロバイダーが提供する初めてのものです。パート 1 はビルダー向けで、署名パイプラインの構築と運用の手順を説明します。パート 2「 SCP と IAM による ML-DSA アルゴリズムポリシーの強制 」はセキュリティチームとガバナンスチーム向けで、ここで選択したアルゴリズムを、組織全体にわたる予防的コントロールと発見的コントロールに落とし込む方法を紹介します。 「 今収集し、後で偽造する (harvest now, forge later) 」脅威を理解する 暗号解読能力を持つ量子コンピュータ (CRQC) が実現すると、現在の公開鍵暗号の安全性を支えている数学的問題を効率的に解けるようになります。計算量の多さから現在は現実的でない攻撃も、CRQC を使用すれば一気に現実的なものになります。ポスト量子暗号 (PQC) に関する議論のほとんどは、データの機密性に対する「 今収集し、後で復号する (harvest now, decrypt later) 」脅威に焦点を当てています。転送中のデータを保護する非対称鍵は CRQC を使用すれば効率的に導出できるため、保護されるはずだったデータが露呈してしまいます。デジタル署名も、非対称暗号と同じ数学的問題に依存しており、CRQC が実現すればその安全性は破られます。つまり、ソフトウェアサプライチェーンも、機密性ではなく完全性を標的とする同様の脅威にさらされています。署名済みアーティファクトを今のうちに記録しておいた攻撃者は、将来 CRQC を使用して、まったく別のアーティファクトに対する署名を偽造できます。 2026 年に ECDSA P-256 で署名され、組み込みデバイスのフリートにデプロイされたファームウェアを例に考えてみましょう。これらのデバイスは、15 年間の運用期間中、起動のたびにファームウェアの署名を検証します。また、デプロイ後に再署名のために回収することはできません。2035 年に CRQC が稼働した場合、攻撃者は改ざんしたファームウェアに対して有効に見える署名を作成でき、フリート内のすべてのデバイスが次回の再起動時にそれを本物として受け入れてしまいます。ソフトウェアの完全性を検証する主な手段として古典的なデジタル署名に依存している組織にとって、これは検証チェーンの重要な部分が弱体化することを意味します。CNSA 2.0 がデジタル署名に厳しいタイムラインを定めているのはこのためです。今日署名するアーティファクトは、運用期間全体にわたって信頼できる状態を維持しなければなりません。 ML-DSA は、古典コンピュータと量子コンピュータのどちらからの攻撃にも耐えられるように設計されています。AWS KMS、AWS Private CA、AWS IAM Roles Anywhere はいずれも ML-DSA をサポートしているため、追加のツールなしで、サプライチェーン全体にわたって将来の署名偽造の脅威に今すぐ対処できます。 アーキテクチャの概要: 耐量子サプライチェーンの 5 つの柱 このアーキテクチャは、連携してソフトウェアデリバリーパイプラインを保護する 5 つの信頼の柱で構成されています。 AWS KMS での ML-DSA キー管理 – すべての署名キーは、FIPS 140-3 セキュリティレベル 3 のハードウェアセキュリティモジュール (HSM) で生成、保護されます。プライベートキーが HSM の境界の外に出ることはありません。 AWS Private CA による ML-DSA 公開鍵基盤 (PKI) – 証明書階層 (ルート CA、下位 CA、エンドエンティティ証明書) によって ML-DSA パブリックキーをアイデンティティにバインドし、誰が何に署名したかを明確にします。CA のプライベートキーは、サービスが管理するハードウェア保護された HSM で生成、保存され、HSM の境界の外に出ることはありません。 耐量子ワークロードアイデンティティ (外部ビルドエージェント向け) – AWS の外部で実行され、X.509 証明書で認証する継続的インテグレーションと継続的デリバリー (CI/CD) エージェントについては、ML-DSA 証明書を使用する IAM Roles Anywhere によって、署名者のアイデンティティを同じ耐量子の信頼のルートに結び付けます。 ML-DSA アーティファクト署名 – ビルド出力 (バイナリ、コンテナイメージのマニフェスト、パッケージ) には、AWS KMS の ML-DSA キーで署名します。署名はアーティファクトと一緒に Amazon Simple Storage Service (Amazon S3) または Amazon Elastic Container Registry (Amazon ECR) に保存します。 ML-DSA SBOM 完全性アテステーション – 各リリースの SBOM を、記述対象のアーティファクトをダイジェストで指定する in-toto Statement でラップし、その Statement に同じ ML-DSA コード署名キーで署名します。これにより、依存関係のマニフェストが改ざんされていないこと、そして添付先のアーティファクトに対応するものであることを、耐量子の方式で証明できます。 これらの柱によって信頼のチェーンが形成されます。AWS Private CA は自身の HSM でルート CA キーを保護し、アイデンティティを AWS KMS のコード署名キーにバインドする証明書を発行します。IAM Roles Anywhere はそれらの証明書を使用してビルドエージェントを認証し、認証されたエージェントは、自身が生成するすべてのアーティファクトと SBOM に署名します。 図 1: AWS におけるエンドツーエンドの耐量子ソフトウェアサプライチェーン 図 1 では、このアーキテクチャを 4 つのレイヤーに分け、構築する順に番号を付けて示しています。 信頼のルート (柱 1 と 2) – AWS Private CA の階層を確立し、AWS KMS でコード署名キーを作成します。 ワークロードアイデンティティ (柱 3) – CA を IAM Roles Anywhere のトラストアンカーとして登録し、ビルドエージェントに ML-DSA 証明書を発行します。これにより、署名者のアイデンティティを同じ耐量子の信頼のルートまでたどれるようにします。 アーティファクト署名 (柱 4 と 5) – 認証されたビルドエージェントを使用して、バイナリ、コンテナイメージ、SBOM に署名します。 検証と適用 – デプロイ時に署名を検証し、ML-DSA のみを許可するポリシーを適用します。 前提条件 この手順を実行するには、以下が必要です。 AWS KMS、AWS Private CA、IAM Roles Anywhere、Amazon ECR でリソースを作成する権限を持つ AWS アカウント。 AWS Command Line Interface (AWS CLI) v2 (適切な認証情報を設定済みのもの)。 ワークロードの認証に使用する IAM Roles Anywhere 認証情報ヘルパー ( aws_signing_helper ) v1.8.0 以降。ML-DSA キーと証明書に対応した最初のリリースです。 IAM Roles Anywhere のドキュメント からダウンロードできます。 OpenSSL 3.5 以降 (ML-DSA 署名の検証と mu の計算に必要)。 ORAS CLI v1.2 以降 (コンテナイメージに Open Container Initiative (OCI) リファラーアーティファクトを添付するために使用)。代わりに、カスタムプラグインを使用した Notation CLI や、 OCI Referrers API をサポートする任意の OCI 準拠クライアントを使用することもできます。 jq (SBOM アテステーションに使用する in-toto Statement の作成と解析、および ORAS 出力の解析に使用)。 SBOM の例で使用する Amazon Inspector SBOM Generator (Sbomgen)、または CycloneDX JSON 形式の SBOM を生成できる別のツール。Sbomgen は Linux (x86-64 および ARM64) でのみ動作するため、該当する手順は Linux のビルドエージェントまたはコンテナで実行してください。Sbomgen は、 oras login が Docker の設定ファイルに保存したレジストリ認証情報を使用します。 --username オプション、または INSPECTOR_SBOMGEN_USERNAME と INSPECTOR_SBOMGEN_PASSWORD の環境変数で認証情報を渡すこともできます。 Java 11 以降と Apache Maven (「ML-DSA PKI 基盤の構築」のステップ 4 で、コード署名用の証明書署名リクエスト (CSR) を生成する diy-code-signing-kms-private-ca サンプルの実行に使用)。 Amazon ECR にプッシュ済みのコンテナイメージ (コンテナ署名の例で使用)。 ML-DSA PKI 基盤の構築 まず、サプライチェーンの信頼の基点となる証明書階層を作成します。AWS Private CA では、認証機関 (CA) を作成すると、その CA の署名キーがハードウェア保護された HSM 内で生成、保存されます。ルート CA には ML-DSA-87 (NIST セキュリティカテゴリ 5。AES-256 の全数鍵探索と同等以上に破ることが困難であると定義されています) を使用します。これは、最も長期間使用されるトラストアンカーであるルート CA を保護するためです。下位 CA には ML-DSA-65 (NIST セキュリティカテゴリ 3) を使用し、頻繁に発行される証明書の署名サイズを抑えつつ、セキュリティとのバランスを取ります。 ここで使用するパラメータセット ML-DSA-87 と ML-DSA-65 は、このシリーズの パート 2 で強制可能なコントロールに落とし込むアルゴリズムポリシーの例でも、承認済みのセットとして使われています。組織で別のセットを標準として採用している場合は、以降のコマンド内のパラメータセットをそのセットに置き換えてください。ビルド手順自体は変わりません。 ステップ 1: AWS Private CA でルート CA を作成する KeyAlgorithm: ML_DSA_87 を指定すると、Private CA が内部で ML-DSA-87 キーペアを生成します。CA 用に別途 AWS KMS キーを作成する必要はありません。 aws acm-pca create-certificate-authority \ --certificate-authority-configuration '{ "KeyAlgorithm": "ML_DSA_87", "SigningAlgorithm": "ML_DSA_87", "Subject": { "CommonName": "PQC Supply Chain Root CA", "Organization": "Example Corp", "Country": "US" } }' \ --certificate-authority-type ROOT 作成直後のルート CA は PENDING_CERTIFICATE 状態です。証明書に自己署名してアクティブ化します。ルート CA の有効期間はこの手順で設定します (ルート CA では 10 年が一般的です)。 # Retrieve the root CA's CSR aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn <root-ca-arn> \ --output text > root-ca.csr # Self-sign the root CA certificate (valid for 10 years) ROOT_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn <root-ca-arn> \ --csr fileb://root-ca.csr \ --signing-algorithm ML_DSA_87 \ --validity Value=3650,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \ --query CertificateArn --output text) # Retrieve and install the self-signed root certificate aws acm-pca get-certificate \ --certificate-authority-arn <root-ca-arn> \ --certificate-arn $ROOT_CERT_ARN \ --query Certificate --output text > root-ca-cert.pem aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn <root-ca-arn> \ --certificate fileb://root-ca-cert.pem ステップ 2: コード署名用の下位 CA を作成する aws acm-pca create-certificate-authority \ --certificate-authority-configuration '{ "KeyAlgorithm": "ML_DSA_65", "SigningAlgorithm": "ML_DSA_65", "Subject": { "CommonName": "PQC Code Signing CA", "Organization": "Example Corp", "Country": "US" } }' \ --certificate-authority-type SUBORDINATE 作成直後の下位 CA は PENDING_CERTIFICATE 状態で、まだルートとはリンクされていません。下位 CA の CSR にルート CA で署名して、アクティブ化します。 # Retrieve the subordinate CA's certificate signing request aws acm-pca get-certificate-authority-csr \ --certificate-authority-arn <sub-ca-arn> \ --output text > sub-ca.csr # Sign the CSR using the root CA (this establishes the trust hierarchy) SUB_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn <root-ca-arn> \ --csr fileb://sub-ca.csr \ --signing-algorithm ML_DSA_87 \ --validity Value=1825,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1 \ --query CertificateArn --output text) # Retrieve the signed certificate and import it to activate the subordinate CA aws acm-pca get-certificate \ --certificate-authority-arn <root-ca-arn> \ --certificate-arn $SUB_CERT_ARN \ --query Certificate --output text > sub-ca-cert.pem aws acm-pca import-certificate-authority-certificate \ --certificate-authority-arn <sub-ca-arn> \ --certificate fileb://sub-ca-cert.pem \ --certificate-chain fileb://root-ca-cert.pem ステップ 3: AWS KMS でコード署名キーを作成する ビルドエージェントはこのキーでアーティファクトに署名するため、ビルドエージェントの IAM ロールには、このキーに対する kms:Sign 権限が必要です。下位 CA が発行するエンドエンティティ証明書によって、アイデンティティがこのキーのパブリックキーにバインドされます。 aws kms create-key \ --key-spec ML_DSA_65 \ --key-usage SIGN_VERIFY \ --description "PQC code-signing key for supply chain" \ --tags TagKey=Purpose,TagValue=CodeSigning CI/CD スクリプトから参照しやすいように、エイリアスを作成します。 aws kms create-alias \ --alias-name alias/pqc-code-signing \ --target-key-id <key-id-from-above> ステップ 4: エンドエンティティのコード署名証明書を発行する 証明書を発行するには CSR が必要です。ML-DSA プライベートキーは AWS KMS の HSM の外に出ないため、OpenSSL を使用してローカルで CSR を生成することはできません。代わりに、サブジェクト名とパブリックキーを含む CSR の TBS (to-be-signed) 構造を作成し、 aws kms sign を呼び出してリモートで署名したうえで、それらを組み合わせて最終的な CSR を作成します。 AWS KMS で管理されるプライベートキーを使用して ML-DSA CSR を作成し、AWS KMS で署名する実装例については、「 AWS Private CA と AWS KMS を使用したポスト量子 (ML-DSA) コード署名 」と、GitHub で公開されている diy-code-signing-kms-private-ca サンプル (Java、Maven でビルド) を参照してください。この手順は AWS CLI だけでは完結しません。CSR はコードで作成して署名する必要があり、このサンプルがそのリファレンス実装です。 code-signing.csr ファイルが用意できたら、下位 CA から証明書を発行します。 # Issue a code-signing certificate valid for one year, signed by the subordinate CA using ML-DSA-65. # Replace <sub-ca-arn> with the ARN that create-certificate-authority returned for the subordinate CA in Step 2. CODE_SIGNING_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn <sub-ca-arn> \ --csr fileb://code-signing.csr \ --signing-algorithm ML_DSA_65 \ --validity Value=365,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/CodeSigningCertificate/V1 \ --query CertificateArn --output text) # Retrieve the issued certificate aws acm-pca get-certificate \ --certificate-authority-arn <sub-ca-arn> \ --certificate-arn $CODE_SIGNING_CERT_ARN \ --query Certificate --output text > code-signing-cert.pem この証明書によって、署名者のアイデンティティが AWS KMS のコード署名キーマテリアルにバインドされます。なお、検証者が証明書の確認だけで署名を検証できる期間は、証明書の有効期間 (この例では 365 日) で決まります。AWS Private CA では、発行元 CA 自身の証明書の有効期限を超えない範囲で、発行する証明書の有効期間を自由に選択できます。この例では、ステップ 2 で作成した下位 CA 証明書の有効期間が 1,825 日であるため、後述の 3 年のオプションもその範囲内に収まります。証明書の有効期限が切れた後も検証できる状態を維持する必要があるアーティファクトについては、次のアプローチを検討してください。 証明書の有効期間の延長 – プライベート PKI では発行ポリシーを自組織で管理できるため、コード署名証明書を複数年の有効期間 (例えば、 Value=1095,Type=DAYS で 3 年) で発行するのが一般的です。 信頼されたタイムスタンプ (RFC 3161) – 署名時に、タイムスタンプ局 (TSA) から取得した RFC 3161 タイムスタンプで各署名に副署します。タイムスタンプによって、証明書の有効期間中に署名が作成されたことが証明されるため、無期限に検証できるようになります。AWS はマネージド TSA を提供していないため、サードパーティの TSA を使用するか、独自の TSA を運用してください。 再署名 – 証明書の有効期限が切れる前に、新しく発行した証明書で、現在使用中のアーティファクトに再署名します。 署名を検証する必要があるシステムに、証明書チェーン (ルート CA 証明書、下位 CA 証明書、エンドエンティティ証明書) を配布します。 CI/CD パイプラインでの ML-DSA によるアーティファクトの署名 PKI 階層の準備ができたら、ML-DSA 署名をビルドプロセスに組み込みます。方法はアーティファクトの種類によって異なります。ML-DSA-65 の署名サイズは 3,309 バイト (ECDSA P-256 では 64 バイト) ですが、ML-DSA に対する AWS KMS の Sign オペレーションのレイテンシーは、既存の非対称オペレーションと同程度です。署名サイズの増加は、数メガバイトのコンテナイメージやパッケージと一緒に保存する場合にはほとんど影響しません。ただし、低帯域幅のリンク経由で送信される組み込みデバイスイメージなど、サイズに制約のある環境では考慮しておく必要があります。 バイナリとパッケージの署名 コンパイル済みのバイナリやパッケージなど、ほとんどのビルド出力は、 aws kms sign に渡すメッセージに対して AWS KMS が設けている 4,096 バイトの上限をはるかに超えるサイズです。パイプラインのデフォルトには EXTERNAL_MU メソッドを使用してください。この方法では、OpenSSL 3.5 を使用して 64 バイトのメッセージ代表値 (mu) を外部で計算し、mu だけを AWS KMS に渡します。任意のサイズのアーティファクトを処理でき、アーティファクトが大きくなっても変更は不要です。AWS KMS では、 --message-type RAW を使用して、最大 4,096 バイトまでのコンテンツを直接渡すこともできます。ただし、 RAW は、後述のコンテナイメージの例で扱う 71 文字のマニフェストダイジェストのように、構造上サイズが固定されている入力にのみ使用してください。現時点で上限に収まるアーティファクトでも、いずれ上限を超える可能性が高く、その時点で RAW に依存しているパイプラインは失敗します。どちらの方法でも、暗号学的に同一の署名が生成されます。検証者はどちらの方法が使用されたかを知る必要はなく、いずれの場合も標準的な ML-DSA 検証を適用できます。 # Retrieve the public key aws kms get-public-key --key-id alias/pqc-code-signing \ --query PublicKey --output text | base64 --decode > pk.der # Extract raw public key bytes from the DER-encoded SubjectPublicKeyInfo. # The BIT STRING starts at offset 17 for all ML-DSA key sizes. # Expected output: 1,312 bytes (ML-DSA-44), 1,952 bytes (ML-DSA-65), or 2,592 bytes (ML-DSA-87). openssl asn1parse -inform DER -in pk.der -strparse 17 -noout -out pk_raw.bin # Compute mu per FIPS 204 Section 6.2 printf '\x00\x00' | cat - artifact.bin > m_prime.bin openssl dgst -shake256 -xoflen 64 -binary pk_raw.bin > pk_hash.bin cat pk_hash.bin m_prime.bin | openssl dgst -shake256 -xoflen 64 -binary > mu.bin # Sign the mu value aws kms sign \ --key-id alias/pqc-code-signing \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --query Signature --output text | base64 --decode > artifact.bin.sig .sig ファイルは、アーティファクトと一緒に Amazon S3 またはパッケージリポジトリに保存します。アーティファクトと署名の両方の完全性を保護するために、 S3 Object Lock (WORM 保護) を有効にするか、少なくとも書き込みアクセスを制限したうえで S3 バージョニングを有効にしてください。攻撃者がどちらかのファイルを変更または削除できる状態では、検証結果を信頼できません。包括的なガイダンスについては、「 Amazon S3 のセキュリティのベストプラクティス 」を参照してください。 コンテナイメージの署名 コンテナイメージの署名には、 OCI Image and Distribution Specifications v1.1 で定義されている OCI リファラーパターンを使用します。リファラーとは、署名や SBOM などのアーティファクトのうち、そのマニフェストの subject フィールドで別のイメージを指定しているものです。Amazon ECR をはじめ、このパターンをサポートするレジストリは、クライアントがイメージのリファラーを要求すると、これらのアーティファクトを返します。この方法では、AWS KMS の ML-DSA キーで署名を生成し、それをイメージのリファラーとして保存します。 # Repository URI used by ORAS here and in the SBOM steps; replace the account ID and Region ECR_URI=111122223333.dkr.ecr.us-east-1.amazonaws.com/myapp # Authenticate ORAS to Amazon ECR aws ecr get-login-password --region us-east-1 | \ oras login --username AWS --password-stdin 111122223333.dkr.ecr.us-east-1.amazonaws.com # Get the image manifest digest IMAGE_DIGEST=$(aws ecr batch-get-image \ --repository-name myapp \ --image-ids imageTag=v1.2.0 \ --query 'images[0].imageId.imageDigest' --output text) # Sign the digest. It is a fixed 71 characters, so RAW is safe here (see Binary and package signing). # AWS CLI v2 expects blob parameters to be base64, so write the digest to a file and pass it with fileb:// echo -n "$IMAGE_DIGEST" > digest.txt aws kms sign \ --key-id alias/pqc-code-signing \ --message fileb://digest.txt \ --message-type RAW \ --signing-algorithm ML_DSA_SHAKE_256 \ --query Signature --output text | base64 --decode > image.mldsa.sig # Attach signature as OCI referrer using ORAS oras attach $ECR_URI@$IMAGE_DIGEST \ --artifact-type "application/vnd.example.mldsa-signature.v1" \ image.mldsa.sig:application/octet-stream デプロイ時には、アドミッションコントローラーがリファラーアーティファクトを取得して ML-DSA 署名を検証し、その後でイメージの実行を許可します。検証ワークフロー全体とアドミッションコントロールの実装については、この記事の後半にある「 デプロイ前のコンテナイメージ署名の検証 」を参照してください。 SBOM の署名 SBOM は、ソフトウェアリリースに含まれるすべてのコンポーネント、ライブラリ、依存関係をまとめた構造化インベントリです。パッケージ名、バージョン、サプライヤー、依存関係を記載します。組織は SBOM を使用して脆弱性の追跡やライセンスコンプライアンスの検証を行い、侵害されたコンポーネントが公表された際に迅速に対応します。 SBOM ファイルだけに署名した場合、署名後にインベントリが改ざんされていないことは証明できますが、そのインベントリがどのアーティファクトを記述しているかは証明できません。イメージの署名と SBOM の署名が互いに独立していると、クリーンなイメージに対して正当に署名された SBOM を手に入れた攻撃者は、それを別の署名済みイメージに添えて提示し、両者が対応していると主張できてしまいます。SBOM を OCI リファラーとしてイメージに添付するだけでは、このギャップは解消されません。リファラーマニフェストの subject フィールドはリファラーをプッシュする人が設定するものであり、関連するアーティファクトを見つけるための仕組みにすぎず、暗号学的なバインドではないためです。バインドは、署名の対象となるバイト列の中に含める必要があります。 このバインドを実現するには、署名の前に SBOM を in-toto Statement でラップします。Statement は、記述対象のアーティファクトを subject フィールドでダイジェストにより指定し、SBOM を predicate として保持します。イメージマニフェストのダイジェストが署名対象のコンテンツに含まれるため、検証者は手元の SBOM が、これからデプロイするイメージに対して発行されたものであることを確認できます。SBOM やダイジェストが差し替えられていれば、検証は失敗します。イメージのファイルシステムに SBOM を埋め込むと、イメージダイジェストが SBOM のバイト列もカバーするようになるため、この方法でも両者をバインドできます。この記事で Statement を使う方法を採用しているのは、完成したイメージをスキャンして生成した SBOM、バイナリやファームウェアなどファイルシステムを持たないアーティファクト、既にレジストリにあるイメージのいずれにも適用でき、さらにイメージをプルしなくてもレジストリから SBOM を読み取れるためです。 任意のツール (コンテナイメージの場合は Amazon Inspector SBOM Generator (Sbomgen) など) で SBOM を生成して Statement でラップし、バイナリと同じ EXTERNAL_MU の手順で Statement に署名します。 # Scan the pushed image by digest so the inventory describes exactly the manifest you signed. # Sbomgen reuses the registry login from the oras login step in the previous section. inspector-sbomgen container --image $ECR_URI@$IMAGE_DIGEST -o sbom.json # Wrap the SBOM in an in-toto Statement whose subject is the image manifest digest. # This puts the digest inside the signed bytes, which binds this SBOM to this image. jq -n \ --arg name "$ECR_URI" \ --arg digest "${IMAGE_DIGEST#sha256:}" \ --slurpfile sbom sbom.json \ '{ "_type": "https://in-toto.io/Statement/v1", "subject": [{"name": $name, "digest": {"sha256": $digest}}], "predicateType": "https://cyclonedx.org/bom", "predicate": $sbom[0] }' > sbom.statement.json # Sign using EXTERNAL_MU (same mu computation as binary signing above, # with sbom.statement.json as the input) # ... compute mu from sbom.statement.json ... aws kms sign \ --key-id alias/pqc-code-signing \ --message fileb://mu.bin \ --message-type EXTERNAL_MU \ --signing-algorithm ML_DSA_SHAKE_256 \ --query Signature --output text | base64 --decode > sbom.statement.json.sig # Attach the Statement and its signature to the image as an OCI referrer so # verifiers discover them alongside the image signature oras attach $ECR_URI@$IMAGE_DIGEST \ --artifact-type "application/vnd.example.mldsa-sbom-attestation.v1" \ sbom.statement.json:application/vnd.in-toto+json \ sbom.statement.json.sig:application/octet-stream Statement とその .sig ファイルは必ずセットで配布してください。SBOM 自体は Statement の predicate フィールドに格納されており、検証者は検証後にそれを抽出します。同じパターンで、SBOM をバイナリやパッケージにバインドすることもできます。その場合は、イメージマニフェストのダイジェストの代わりに、ファイルの SHA-256 をサブジェクトダイジェストに設定します。バインドを完結させるサブジェクトの確認を含めた検証ワークフロー全体については、この記事の後半にある「 バイナリまたは SBOM の署名の検証 」セクションで説明します。 ビルドエージェント用の耐量子ワークロードアイデンティティ ML-DSA キーによるアーティファクトの署名で保護できるのは、アーティファクト自体の完全性です。これとは別に、AWS の外部で実行されるビルドエージェント (オンプレミスの Jenkins、セルフホスト型の GitHub Actions ランナー、サードパーティの CI/CD システム) は、通常 RSA や ECDSA で署名された X.509 証明書や OIDC トークンを使用して認証します。これらの認証情報は、パイプラインにおける古典暗号への依存となります。ML-DSA 証明書を使用する IAM Roles Anywhere は、この依存を解消します。外部のビルドエージェントが提示する認証情報も、それを保証する CA も、量子攻撃に脆弱なアルゴリズムに依存しなくなります。(リクエストを伝送する TLS 接続では、現在のパブリック TLS と同様に、引き続き従来型の証明書で AWS エンドポイントが認証されます。これはトランスポート層の問題であり、この記事で扱う署名アイデンティティとは別のものです。) IAM ロールがアタッチされ、AWS 上で実行されるビルドエージェントには、この依存はありません。こうしたビルドエージェントの API リクエストは AWS Signature Version 4 (SigV4) で認証されます。SigV4 は、対称方式のハッシュベースメッセージ認証コード (HMAC-SHA256) を使用します。このような対称方式は既に耐量子であると考えられているため、追加の対応は必要ありません。 ステップ 1: ワークロードアイデンティティ用の CA をトラストアンカーとして登録する このウォークスルーでは、前の手順で作成した下位 CA を再利用します。こうすることで、2 つ目の CA の月額料金を避けられます。以降のコマンドも、この CA を前提としています。本番環境では、コード署名用の CA とは別に、ワークロードアイデンティティ証明書専用の下位 CA を使用してください。これにより、いずれかの CA が侵害されて失効させる必要が生じた場合の影響範囲を限定でき、2 種類の証明書にそれぞれ異なる発行ポリシーを適用できます。 # Use the ARN that create-certificate-authority returned when you created the # subordinate CA earlier. If you no longer have it, list your CAs and copy the # ARN of the SUBORDINATE one. aws acm-pca list-certificate-authorities \ --query "CertificateAuthorities[?Type=='SUBORDINATE'].[Arn,Status,CertificateAuthorityConfiguration.Subject.CommonName]" \ --output table SUB_CA_ARN=arn:aws:acm-pca:us-east-1:111122223333:certificate-authority/abc-123 # replace with yours # Register the subordinate CA as an IAM Roles Anywhere trust anchor aws rolesanywhere create-trust-anchor \ --name "PQC-CI-CD-Trust-Anchor" \ --source "sourceType=AWS_ACM_PCA,sourceData={acmPcaArn=$SUB_CA_ARN}" \ --enabled ステップ 2: ビルドエージェントのロールと、それを参照するプロファイルを作成する IAM Roles Anywhere プロファイルでは、トラストアンカーとして登録した CA が発行した証明書で認証したワークロードが引き受けられる IAM ロールを指定します。まず、ロールを作成します。ロールの信頼ポリシーでは、IAM Roles Anywhere がロールを引き受けられる条件を、トラストアンカー経由であること、かつサブジェクトのコモンネームがビルドエージェントを示す証明書であることに限定します。これらの条件がないと、トラストアンカーの CA が発行したどの証明書でもロールを引き受けられてしまいます。ロールのアクセス許可ポリシーでは、署名に必要な権限だけを、コード署名キーに対してのみ付与します。信頼ポリシーを build-agent-trust.json として保存し、トラストアンカーの ARN を、ステップ 1 で create-trust-anchor が返した ARN に置き換えます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Service": "rolesanywhere.amazonaws.com"}, "Action": ["sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity"], "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:111122223333:trust-anchor/ta-id" }, "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "pqc-build-agent-01" } } } ] } アクセス許可ポリシーを build-agent-permissions.json として保存し、リソースをキーの ARN に置き換えます (ARN は aws kms describe-key --key-id alias/pqc-code-signing --query KeyMetadata.Arn --output text で確認できます)。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["kms:Sign", "kms:GetPublicKey", "kms:DescribeKey"], "Resource": "<code-signing-key-arn>" } ] } ロールを作成してポリシーをアタッチし、そのロールを参照するプロファイルを作成します。 aws iam create-role \ --role-name PQCBuildAgentRole \ --assume-role-policy-document file://build-agent-trust.json aws iam put-role-policy \ --role-name PQCBuildAgentRole \ --policy-name pqc-code-signing \ --policy-document file://build-agent-permissions.json aws rolesanywhere create-profile \ --name "PQC-Build-Agent-Profile" \ --role-arns "arn:aws:iam::111122223333:role/PQCBuildAgentRole" \ --enabled ステップ 3: ビルドエージェントの証明書を発行し、認証情報ヘルパーを設定する OpenSSL を使用してビルドエージェントの ML-DSA-65 キーペアと CSR をローカルで生成し、下位 CA からクライアント認証証明書を発行します。その後、その証明書を提示するように IAM Roles Anywhere 認証情報ヘルパーを設定します。 # Generate the build agent's key pair and CSR. The CN must match the # aws:PrincipalTag/x509Subject/CN condition in the role's trust policy. openssl genpkey -algorithm ML-DSA-65 -out build-agent-mldsa-key.pem chmod 400 build-agent-mldsa-key.pem openssl req -new -key build-agent-mldsa-key.pem \ -subj "/C=US/O=Example Corp/CN=pqc-build-agent-01" \ -out build-agent.csr # Issue a 30-day client authentication certificate from the subordinate CA # registered as the trust anchor in Step 1. BUILD_AGENT_CERT_ARN=$(aws acm-pca issue-certificate \ --certificate-authority-arn $SUB_CA_ARN \ --csr fileb://build-agent.csr \ --signing-algorithm ML_DSA_65 \ --validity Value=30,Type=DAYS \ --template-arn arn:aws:acm-pca:::template/EndEntityClientAuthCertificate/V1 \ --query CertificateArn --output text) aws acm-pca get-certificate \ --certificate-authority-arn $SUB_CA_ARN \ --certificate-arn $BUILD_AGENT_CERT_ARN \ --query Certificate --output text > build-agent-mldsa.pem # In production, store the private key in a TPM or HSM rather than as a plaintext file. aws_signing_helper credential-process \ --certificate build-agent-mldsa.pem \ --private-key build-agent-mldsa-key.pem \ --trust-anchor-arn arn:aws:rolesanywhere:us-east-1:111122223333:trust-anchor/ta-id \ --profile-arn arn:aws:rolesanywhere:us-east-1:111122223333:profile/profile-id \ --role-arn arn:aws:iam::111122223333:role/PQCBuildAgentRole ヘルパーは、ビルドロールに権限が限定された短期間有効な AWS Security Token Service (AWS STS) の認証情報を生成するため、長期間有効な AWS アクセスキーが不要になります。本番環境では、Trusted Platform Module (TPM)、HSM、ファイルのアクセス許可を制限した暗号化認証情報ストアなど、ハードウェアベースのストレージで ML-DSA プライベートキーを保護してください。ここで示しているプレーンテキストファイルのパスは、デモンストレーション用です。このプライベートキーはコード署名インフラストラクチャへのアクセスを認可するものなので、他の署名キーと同等のレベルで保護する必要があります。Linux のビルドエージェントでは、少なくともファイルの所有者をサービスアカウントにしたうえで、 chmod 400 でアクセスを制限してください。また、PKCS#11 プロバイダーを使用して、未加工のキーをディスクに一切保存しない構成も検討してください。 検証とポリシーの適用 署名アーキテクチャの強さは、検証の強さで決まります。署名を生成するだけでは全体の半分にすぎません。残りの半分は、デプロイパイプライン、Kubernetes のアドミッションコントローラー、パッケージをインストールするエンジニアなど、アーティファクトをデプロイするシステムや人に対して、アーティファクトのデプロイや実行の前に署名を検証し、信頼できるかどうかを判断するための具体的な手段を提供することです。 信頼チェーンの配布 検証者が署名を確認するには、まずコード署名証明書を発行した CA を信頼している必要があります。この信頼はトラストストアによって確立されます。トラストストアとは、システムが信頼できるものとして扱うルート CA 証明書をローカルにまとめたものです。トラストストアは、オペレーティングシステム (Linux の /etc/pki/ca-trust/ 、macOS の Keychain など)、言語ランタイム (Java の cacerts )、コンテナベースイメージ、カスタムアプリケーションの設定などに存在します。 この記事で構築するようなプライベート PKI 階層の場合、ルート CA 証明書はデフォルトのパブリックトラストストアには含まれていません。署名を検証するすべてのシステムのトラストストアに、ルート CA 証明書を明示的に追加する必要があります。一般的な方法は次のとおりです。 ビルドプロセスでルート CA 証明書をコンテナベースイメージに組み込む 構成管理 ( AWS Systems Manager Parameter Store 、 AWS Secrets Manager 、または既存の構成ツール) を通じて配布する バージョニングとアクセスログ記録を有効にした内部の S3 バケットで公開する 保護対象のイメージと一緒に、OCI アーティファクトとして Amazon ECR に保存する トラストストアの管理は、認証情報の管理と同じくらい厳密に行ってください。攻撃者が不正なルート証明書をトラストストアに挿入できれば、偽造した署名を有効に見せかけることができてしまいます。トラストストアへの書き込みアクセスを制限し、AWS CloudTrail またはシステムレベルの監査ログで変更を監査してください。 証明書チェーンをエクスポートするには、ルート CA に加えて、署名の検証に関係する証明書を発行する下位 CA をエクスポートします。 # Export the root CA certificate aws acm-pca get-certificate-authority-certificate \ --certificate-authority-arn <root-ca-arn> \ --query Certificate --output text > root-ca.pem # Export the subordinate CA certificate. Select only the Certificate field: for a # subordinate CA this call also returns CertificateChain, and --output text would # print both on one tab-separated line, producing a file that OpenSSL can't parse. aws acm-pca get-certificate-authority-certificate \ --certificate-authority-arn <sub-ca-arn> \ --query Certificate --output text > sub-ca.pem # Bundle the full chain for verifiers cat root-ca.pem sub-ca.pem > trust-chain.pem 検証者はこのチェーンを使用して、コード署名のパブリックキーが信頼できる CA によって発行されたものであることを確認します。 ウォークスルーを簡潔にするため、この記事の CA は失効設定なしで作成しており、以降の検証コマンドでも失効ステータスは確認しません。本番環境では、下位 CA に証明書失効リスト (CRL) または OCSP (Online Certificate Status Protocol) レスポンダーを設定してください (AWS Private CA ユーザーガイドの「 AWS Private CA 証明書の失効方法を計画する 」を参照してください。どちらも ML-DSA CA で使用できます)。CRL を使用する場合は、信頼チェーンと一緒に CRL を配布し、オプション -crl_check -CRLfile <crl-file> を後述の openssl verify コマンドに追加します。 <crl-file> には、AWS Private CA が S3 バケットに公開する CRL を指定します。これにより、失効したコード署名証明書は検証に失敗するようになります。 バイナリまたは SBOM の署名の検証 まずコード署名証明書を信頼チェーンに照らして検証し、想定どおりの署名者に発行されたコード署名証明書であることを確認します。そのうえでパブリックキーを抽出し、OpenSSL 3.5 で署名を検証します。2 つ目の確認は重要です。チェーンの確認だけでは、前のセクションで発行したビルドエージェント用のクライアント証明書を含め、CA 階層が発行したすべての証明書が受け入れられてしまいます。そのため、検証者の設定で想定するサブジェクトを固定してください。 # Step 1: Verify that the code-signing certificate chains to the trusted root CA and carries the # Code Signing extended key usage. -purpose codesign (OpenSSL 3.2 and later) rejects a certificate # that chains correctly but was issued for another purpose, such as a build agent's client # authentication certificate from the same subordinate CA. # trust-chain.pem contains the root CA and subordinate CA certificates distributed in the previous section. openssl verify -CAfile trust-chain.pem -purpose codesign code-signing-cert.pem # Confirm that the certificate was issued to the signer you expect. Replace <signer-cn> with the # common name in your code-signing certificate's subject. openssl x509 -in code-signing-cert.pem -noout -subject -nameopt RFC2253 | grep -q "CN=<signer-cn>" || { echo "Unexpected signer"; exit 1; } # Step 2: Extract the public key from the verified certificate. openssl x509 -in code-signing-cert.pem -pubkey -noout > signing-key.pem # Step 3: Verify the artifact signature using the trusted public key. openssl pkeyutl -verify \ -pubin -inkey signing-key.pem \ -in artifact.bin \ -sigfile artifact.bin.sig \ -rawin 検証に成功すると Signature Verified Successfully (署名の検証に成功しました) と出力され、終了ステータス 0 が返されます。検証に失敗すると Signature Verification Failure (署名の検証に失敗しました) と出力され、0 以外の終了ステータスが返されます。シェルスクリプトでは、各コマンドの終了ステータスを確認するか、 set -e を指定してブロックを実行してください。こうすることで、証明書チェーンの確認に失敗した場合は署名の検証前にスクリプトが停止し、署名の確認に失敗した場合は後続の処理がブロックされます。 SBOM の場合は、 sbom.statement.json を -in の入力ファイル、 sbom.statement.json.sig を -sigfile の署名ファイルとして指定して同じ 3 つのステップを実行し、さらに 4 つ目のステップとして、検証済みの Statement 内のサブジェクトダイジェストが、これからデプロイするアーティファクトのダイジェストと一致することを確認します。署名の検証によって Statement が本物であることが証明され、サブジェクトの確認によって Statement が別のアーティファクトではなくこのアーティファクトを記述していることが証明されます。比較に使うダイジェストは、Statement からではなく、必ずアーティファクト自体から取得してください。イメージの場合はレジストリから取得し、バイナリの場合はファイルから計算します。イメージの場合、このダイジェストはイメージ署名の検証に使用するダイジェストと同じものです。そのため、2 つの確認を組み合わせることで、この SBOM がこの署名済みイメージを記述していることを確かめられます。 # Step 4 (SBOM only): the signed Statement must name the image being deployed. # Resolve the digest from Amazon ECR, not from the Statement. IMAGE_DIGEST=$(aws ecr batch-get-image \ --repository-name myapp \ --image-ids imageTag=v1.2.0 \ --query 'images[0].imageId.imageDigest' --output text) SUBJECT_DIGEST=$(jq -r '.subject[0].digest.sha256' sbom.statement.json) [ "sha256:$SUBJECT_DIGEST" = "$IMAGE_DIGEST" ] || { echo "SBOM does not describe this image"; exit 1; } # Only now extract the SBOM for downstream tooling jq '.predicate' sbom.statement.json > sbom.json バイナリの場合は、サブジェクトダイジェストを sha256sum artifact.bin の出力と比較します。署名とサブジェクトのどちらかの確認に失敗した場合は、その SBOM を拒否してください。 デプロイ前のコンテナイメージ署名の検証 Amazon ECR の OCI リファラーアーティファクトから ML-DSA 署名をプルし、イメージマニフェストのダイジェストに対して検証します。 # Pull the signature referrer. ORAS 1.2 lists referrers under "manifests"; # ORAS 1.3 and later list them under "referrers". The jq filter accepts either. oras discover $ECR_URI@$IMAGE_DIGEST \ --artifact-type "application/vnd.example.mldsa-signature.v1" --format json | \ jq -r '(.referrers // .manifests)[0].digest' | \ xargs -I{} oras pull $ECR_URI@{} -o /tmp/sig/ # Re-derive the image digest and verify echo -n "$IMAGE_DIGEST" > /tmp/digest.txt openssl pkeyutl -verify \ -pubin -inkey signing-key.pem \ -in /tmp/digest.txt \ -sigfile /tmp/sig/image.mldsa.sig \ -rawin # Exit code 0 = image is authentic; non-zero = reject deployment 同じ oras discover コマンドに --artifact-type "application/vnd.example.mldsa-sbom-attestation.v1" を指定すると、SBOM アテステーションとその署名を取得できます。取得したら、サブジェクトの確認も含め、前のセクションで説明した手順で検証してください。ここで示した jq フィルターは、指定したタイプの最初のリファラーを取得します。レジストリがリファラーを返す順序には依存しないでください。また、イメージを再署名した後は、リファラーが複数存在することを想定しておく必要があります。本番環境の検証者は、そのタイプのリファラーをすべて確認し、トラストストアまでチェーンをたどれる証明書で少なくとも 1 つの署名が検証できた場合に、イメージを受け入れるようにしてください。最初のリファラーだけを確認する方法では、正しく署名されたイメージを誤って拒否することはあっても、署名されていないイメージを受け入れることはありません。 デプロイ時にこれらのチェックを適用するには、Kubernetes のアドミッションコントローラーでチェックを実行します。アドミッションコントローラーは、API サーバーがポッドを受け入れる前に呼び出すコンポーネントで、リクエストを拒否できます。アドミッションコントローラーは、検証用のアドミッション Webhook として独自に作成するか (Kubernetes ドキュメントの「 Dynamic Admission Control 」を参照)、 Open Policy Agent (OPA) Gatekeeper (OPA ポリシーエンジンで評価したポリシーを適用するアドミッション Webhook) を使用し、制約から呼び出される Gatekeeper の 外部データプロバイダー として検証手順をパッケージ化します。イメージ署名に基づいて Amazon EKS へのデプロイを制御する実例については、「 AWS Signer と Amazon EKS におけるコンテナイメージ署名の提供開始 」を参照してください。同記事では、Kyverno を使用してアドミッション時に AWS Signer の署名を検証しており、代替手段として Gatekeeper やカスタム Webhook についても説明しています。この記事の ML-DSA 署名リファラーは、これらのツールではそのまま検証できないカスタムアーティファクトタイプであるため、このセクションの検証手順は独自に用意したコードで実行します。どちらの設計でも、コントローラーはポッドがスケジュールされる前に実行され、Amazon ECR に有効な ML-DSA 署名リファラーがないイメージや、SBOM アテステーションがデプロイ対象のイメージを指定していないイメージを拒否します。 予防的コントロールと発見的コントロール 署名の検証によって、信頼されていないアーティファクトがデプロイ時に使用されるのを防げます。組織レベルのコントロールは、それよりも早い段階で、より広い範囲に適用されます。予防的コントロールは、チームが従来型の署名キーを新たに作成することを防ぎます。発見的コントロールはすべての署名オペレーションを記録するため、どのプリンシパルがいつ各アーティファクトに署名したかを監査できます。 予防的ガードレール。 セキュリティ上重要なアカウントで従来型の署名キーの作成をブロックし、新しい署名ワークロードすべてに ML-DSA の使用を強制するには、次のような AWS Organizations サービスコントロールポリシー (SCP) を使用します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RequirePQCSigningKeys", "Effect": "Deny", "Action": "kms:CreateKey", "Resource": "*", "Condition": { "StringNotLike": { "kms:KeySpec": "ML_DSA_*" }, "StringEquals": { "kms:KeyUsage": "SIGN_VERIFY" } } } ] } この SCP により、チームは RSA や ECDSA の署名キーを新たに作成できなくなり、新しいワークロードでは耐量子署名が唯一の選択肢になります。なお、この SCP で制限されるのはアルゴリズムファミリーであり、パラメータセットではありません。そのため、このアーキテクチャでは使用しない ML-DSA-44 キーの作成は引き続き許可されます。このシリーズのパート 2 は、まさにこの点から始まります。パート 2 では、完全なアルゴリズムポリシー (その例では ML-DSA-65 と ML-DSA-87 を承認し、ML-DSA-44 を除外) を、SCP、IAM のアクセス許可の境界、AWS KMS キーポリシーで kms:KeySpec 条件キーを使用した多層的なコントロールとして表現する方法を紹介します。さらに、既存のキーの使用を制限する方法や、アルゴリズムの条件キーがない AWS Private CA などの領域を管理する方法も説明します。この SCP とパート 2 のパラメータセット用の SCP は組み合わせて使用します。両方をアタッチすると、新しい署名キーはすべて承認済みのパラメータセットを使用しなければならなくなります。 監査証跡。 AWS CloudTrail は、すべての kms:Sign および kms:Verify API コールをログに記録し、各アーティファクトがいつ、どのプリンシパルによって署名されたかを示す変更不可能な記録を提供します。組織の証跡を使用し、Amazon Athena でそのログをクエリすることで、複数のアカウントにわたる署名アクティビティを分析し、デプロイイベントと関連付けてください。 規制のタイムラインと推奨アクション 次の表は、規制上のマイルストーンと、この記事で説明したアーキテクチャを使用して今すぐ実行できる具体的なアクションの対応を示しています。この情報は一般的な情報提供のみを目的としたものであり、法律上またはコンプライアンス上の助言ではありません。組織固有の義務については、法務チームやコンプライアンスチームに確認してください。PQC に関する世界各国の規制タイムラインの概要については、「 Migrating to Post-Quantum Cryptography 」を参照してください。 規制 期限 規制の文言 AWS でのアクション CNSA 2.0: サポートと優先 2025 年 (適用中) CNSA 2.0 タイムライン (2022 年 9 月、FAQ v2.1 は 2024 年 12 月): ソフトウェアとファームウェアの署名は、2025 年までに CNSA 2.0 アルゴリズムを「サポートし優先する (support and prefer)」必要がある AWS KMS で ML-DSA キーを作成し、既存の従来型の署名と並行して ML-DSA によるアーティファクトの署名を開始する CNSA 2.0: 新規システムの調達 2027 年 1 月 CNSA 2.0 FAQ v2.1 (2024 年 12 月): 「2027 年 1 月 1 日以降、すべての新規 NSS 調達は、デプロイ時に CNSA 2.0 に準拠している必要がある (All new NSS acquisitions must be CNSA 2.0 compliant at deployment, effective 1 January 2027)」 ML-DSA PKI を本格運用し、IAM Roles Anywhere のトラストアンカーで ML-DSA を使用し、すべての新規ビルドに ML-DSA 署名を付与する EU サイバーレジリエンス法 2027 年 12 月 11 日 規則 (EU) 2024/2847、附属書 I、第 I 部 (2)(f): 製品は「保存、送信、またはその他の方法で処理されるデータ (個人データかその他のデータかを問わない)、コマンド、プログラム、設定の完全性を、ユーザーが許可していない操作や変更から保護し、破損について報告する (protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions)」必要がある。第 II 部 (7): 製造業者は「アップデートを安全に配布するメカニズムを提供する (provide for mechanisms to securely distribute updates)」必要がある EU 市場向けに出荷するすべてのソフトウェアアップデートに ML-DSA コード署名を適用し、すべてのリリースに署名済みの SBOM を添付する CNSA 2.0: 排他的使用 2030 年 CNSA 2.0 タイムライン: ソフトウェアとファームウェアの署名は、2030 年までに CNSA 2.0 アルゴリズム「のみを使用する (exclusively use)」必要がある サプライチェーンから従来型の署名キーを削除し、SCP によって ML-DSA キー以外の作成を禁止する PCI DSS 4.0 要件 12.3.3 2025 年 3 月から必須 PCI DSS v4.0.1、要件 12.3.3: 「使用中の暗号スイートとプロトコルを文書化し、少なくとも 12 か月に 1 回レビューする (Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months)」(使用中の暗号スイートとプロトコルの最新のインベントリを含む) AWS KMS で暗号インベントリを文書化し、ML-DSA キーと従来型のキーを区別するタグを付け、移行の進捗状況を追跡する NSS のお客様およびその他の CNSA 2.0 採用組織への注意事項: CNSA 2.0 は、NSA が NSS に要求する耐量子アルゴリズムスイートです。NSS とは、機密情報を扱う連邦システム、または諜報、暗号、軍の指揮統制、兵器の各機能をサポートする連邦システムを指します。CNSA 2.0 では、ソフトウェアとファームウェアの署名を含め、あらゆる署名用途で ML-DSA を使用する場合、ML-DSA-87 パラメータセットのみが許可されています。(ソフトウェアとファームウェアの署名については、ステートフルなハッシュベースの方式である LMS と XMSS も承認されていますが、この記事では扱いません。) この記事のコード署名の例で使用している ML-DSA-65 パラメータセットは、商用ワークロードには適していますが、NSS では許可されていません。CNSA 2.0 が拘束力を持つのは NSS に対してのみですが、その範囲を大きく超えて自主的に採用されています。採用しているのは、米国および同盟国で米国の防衛市場や諜報市場に製品を供給し、その製品が NSS の要件を満たす必要があるサプライヤーや、米国内外の商用組織です。商用組織が CNSA 2.0 を保守的なベースラインとして採用するのは、CNSA 2.0 が NIST の最高セキュリティカテゴリを指定しており、後でパラメータの選択を見直す必要がなくなるためです。システムが CNSA 2.0 の対象範囲に該当する場合や、CNSA 2.0 への準拠を選択した場合は、すべての署名キーと証明書で ML-DSA-87 を使用してください。このシリーズの パート 2 では、この置き換えを強制可能にする方法を紹介します。パート 2 の例で ML-DSA-44 を除外している kms:KeySpec のコントロールをそのまま利用し、 ML_DSA_87 を唯一の承認済みキー仕様として指定できます。 米国政府と EU の商用市場の両方を対象とする組織にとって、2027 年 1 月と 2027 年 12 月の期限は 1 つの移行期間に集約されます。今すぐ着手すれば、テスト、キーローテーションの計画、証明書チェーンの検証のための余裕を確保できます。 クリーンアップ これまでの手順と例では、多数の暗号リソースを作成しました。AWS Private CA では CA ごとに、AWS KMS ではキーごとに月額料金が発生します。継続的に料金が発生しないように、使用していないリソースは削除してください。まず、既存のリソースを一覧表示し、繰り返し実行したことで生じた重複も含めて、作成したすべてのリソースを把握します。以下のコマンドは 1 つのリージョンを対象とします。複数のリージョンで作業した場合は、リージョンごとに --region を指定してコマンドを繰り返し実行してください。 # List every private CA with its type, status, key algorithm, and subject. # A CA you already deleted shows DELETED until its restoration window ends. aws acm-pca list-certificate-authorities \ --query 'CertificateAuthorities[].[Arn,Type,Status,CertificateAuthorityConfiguration.KeyAlgorithm,CertificateAuthorityConfiguration.Subject.CommonName]' \ --output table # List every ML-DSA key in AWS KMS with its state and creation date. # A key already scheduled for deletion shows PendingDeletion. for KEY_ID in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do aws kms describe-key --key-id "$KEY_ID" \ --query 'KeyMetadata.[KeyId,KeySpec,KeyState,CreationDate]' --output text done | grep ML_DSA # Show which alias points at which key. A key that no alias points at # is usually a leftover from an earlier run. aws kms list-aliases --query 'Aliases[].[AliasName,TargetKeyId]' --output text | grep -v '^alias/aws/' AWS Private CA には、CA が発行した証明書を一覧表示するコマンドはありません。後述の失効手順でシリアル番号が必要な場合は、 aws acm-pca create-certificate-authority-audit-report を使用して監査レポートを生成してください。このコマンドは、CA が発行または失効させたすべての証明書の一覧を、サービスに書き込みアクセスを許可した S3 バケットに出力します。 一覧で見つかった余分なコピーも含めて不要なリソースをそれぞれ削除し、再度一覧を表示して何も残っていないことを確認します。 # Revoke any issued end-entity certificates while the subordinate CA is still active aws acm-pca revoke-certificate \ --certificate-authority-arn <sub-ca-arn> \ --certificate-serial <serial-number> \ --revocation-reason CESSATION_OF_OPERATION # Delete the IAM Roles Anywhere resources that reference the CA aws rolesanywhere delete-profile --profile-id <profile-id> aws rolesanywhere delete-trust-anchor --trust-anchor-id <trust-anchor-id> # Delete the build agent role that the profile referenced, and the local copy of its private key aws iam delete-role-policy --role-name PQCBuildAgentRole --policy-name pqc-code-signing aws iam delete-role --role-name PQCBuildAgentRole rm -f build-agent-mldsa-key.pem # Delete the AWS KMS code-signing key (schedule 7-day waiting period). # ScheduleKeyDeletion doesn't accept an alias, so resolve the key ID first. KEY_ID=$(aws kms describe-key --key-id alias/pqc-code-signing \ --query KeyMetadata.KeyId --output text) aws kms schedule-key-deletion --key-id $KEY_ID --pending-window-in-days 7 # Remove the alias. It survives key deletion and would otherwise show up in the # listing above on your next run. aws kms delete-alias --alias-name alias/pqc-code-signing # Disable and delete the subordinate CA aws acm-pca update-certificate-authority \ --certificate-authority-arn <sub-ca-arn> --status DISABLED aws acm-pca delete-certificate-authority \ --certificate-authority-arn <sub-ca-arn> --permanent-deletion-time-in-days 7 # Disable and delete the root CA aws acm-pca update-certificate-authority \ --certificate-authority-arn <root-ca-arn> --status DISABLED aws acm-pca delete-certificate-authority \ --certificate-authority-arn <root-ca-arn> --permanent-deletion-time-in-days 7 長期的な運用を前提にこの構成を応用する場合は、ログの保持について計画してください。CloudTrail のイベント履歴に保持されるのは直近 90 日間の管理イベントのみであり、証跡の代わりにはなりません。前述の監査証跡を実現するには、保持要件に合ったライフサイクルポリシーとアクセスコントロールを設定した S3 バケットに配信する証跡を作成してください。 まとめ この記事では、AWS KMS での ML-DSA 署名、AWS Private CA での ML-DSA 証明書階層、IAM Roles Anywhere を通じた ML-DSA ワークロード認証を組み合わせて、AWS で耐量子ソフトウェアサプライチェーンを構築する方法を紹介しました。このアーキテクチャは、認証されたビルドエージェントから、署名済みのバイナリ、コンテナイメージ、SBOM、デプロイ時の検証とポリシーの適用に至るまで、パイプライン全体をカバーしています。 この記事で使用した ML-DSA の機能は、いずれも一般提供されています。AWS Private CA と IAM Roles Anywhere は、すべての商用 AWS リージョン、AWS GovCloud (米国) リージョン、中国リージョンで ML-DSA をサポートしています。AWS KMS は、商用 AWS リージョンで ML-DSA をサポートしています。標準化団体やサードパーティのツールによる PQC 対応が確定するのを待つ必要はありません。必要な基本要素は既にそろっています。 まずは AWS KMS で最初の ML-DSA キーを作成し、テスト用のアーティファクトに署名してみてください。次に PKI 階層を構築し、ビルドエージェント向けに IAM Roles Anywhere を統合して、コンテナと SBOM のワークフローに ML-DSA 署名を追加していきましょう。 パイプラインの構築は、作業の半分にすぎません。残りの半分は、アカウント、チーム、標準が変化しても、選択したアルゴリズムが引き続き確実に適用されるようにすることです。これが、このシリーズのパート 2「 SCP と IAM による ML-DSA アルゴリズムポリシーの強制 」のテーマです。パート 2 は、この課題を担当するセキュリティチームとガバナンスチームを対象としています。 詳細については、以下を参照してください。 AWS における耐量子署名、パート 2: SCP と IAM による ML-DSA アルゴリズムポリシーの強制 Post-quantum cryptography on AWS ML-DSA keys in AWS KMS AWS Private CA と AWS KMS を使用したポスト量子 (ML-DSA) コード署名 IAM Roles Anywhere post-quantum digital certificates AWS ポスト量子暗号への移行計画 Harshvardhan Chunawala Harshvardhan は AWS の Solutions Architect 兼 Security SME です。Amazon Leo、Amazon Security、AWS Agentic AI と連携し、チーム横断の取り組みを主導しています。クラウドセキュリティ分野で 10 年以上の経験を持つ Golden Jacket 受賞者で、カーネギーメロン大学ではアドバイザリーボードメンバー、客員教員、研究者を務めています。世界中の経営幹部、企業のリーダー、スタートアップの創業者に対し、安全でスケーラブルなクラウドプラットフォームの構築について助言しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

「自治体のためのクラウドコスト最適化」シリーズについて 自治体がガバメントクラウド上で業務システムを運用する場合、クラウド利用料の管理はオンプレミスとは性質の異なる実務になります。従来は、機器を調達した時点で費用がほぼ固定され、その後の管理は保守契約の範囲で済みました。クラウドは使った分だけ課金されるため、構成を変えれば費用も変わります。移行しただけでは費用は下がらず、稼働後に構成を見直し続けることで効果が出ます。 ところがこの見直し作業は、技術的な判断を伴うため日々の運用を担う事業者に委ねられがちです。結果として、自治体側に判断の材料が届かないまま請求額だけが確定していくことがあります。クラウド利用料は自治体の予算から支出され、住民や議会に説明する主体は自治体です。本シリーズは、 自治体が自らクラウド費用を把握し、事業者と協働して最適化を続けられる状態 を目標にしています。 ただしコスト最適化は、コンソールで数値を確認する日々の運用から、調達仕様書への反映、予算要求・決算の手続き、システム基盤そのものの設計まで、性質の異なる複数の作業で成り立っています。これらは担い手も検討のタイミングも異なるため、本シリーズでは領域ごとに記事を分けています。 # タイトル 扱う領域 自治体職員 ベンダー 情報政策 担当 財政担当 運用管理 補助者 ASP ① 定期レビューで回すコスト最適化の手順 日々の運用 ● ○ ● ○ ②-1 運用管理補助者との協働体制を調達仕様書に落とし込む 調達・契約 ● ○ ○ ○ ②-2 AI Agent でコスト分析を自動化する（公開予定） 運用の効率化 ● ○ ○ ③ 予算要求・執行・決算の実務（本記事） 予算・会計 ○ ● ④ 20業務の最適化設計と実践（公開予定） 基盤の設計 ○ ● ● 補足： ②-2、④は今後公開予定です。公開時にはこの表からリンクします。 ● は主な対象、 ○ は関連する範囲で参考になる読者です。 情報政策担当 ：情報システム部門でクラウド環境の運用を所管する職員 財政担当 ：予算要求・執行・決算の手続きを担当する職員 運用管理補助者 ：ガバメントクラウドの運用管理を自治体から受託する事業者 ASP ：業務システム（パッケージ）を提供し、その動作保証を担う事業者 どこから読むか ：情報政策を担当される方は①から、財政を担当される方は③から始めてください。運用管理補助者・ASP の方は④が中心になります。 本記事について シリーズ②-1では、GCASガイド「継続的運用経費最適化(FinOps)ガイド」において、クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等に取り組むこととされていることを紹介しました。これらを実現するためには、運用管理補助者・ASP、政策担当原課、情報システム部門、財政部門が各々の立場で役割を果たすことが必要になります。 そこで今回は、クラウドコストの予算管理等をテーマとし、特に、財政部門の皆さまがクラウド経費の予算査定・執行管理を行う際の実務的な視点で記載しています。 目次 1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い 1.1 クラウドサービス利用料の特徴 1.2 クラウドの特性を踏まえた新たな予算管理の考え方 1.3 コスト最適化への取組 2. 年度予算要求時のコスト見積もり 2.1 移行初年度の見積もり 2.2 2年目以降の見積もり 3. 年度途中のコスト変動への対応 3.1 AWS Budgets による予算設定・予算超過の防止 3.2 執行残発生時の扱い 4. まとめ Appendix 長期利用割引（リザーブドインスタンス・Savings Plans）の予算上の扱い 1. はじめに ― 従量課金等のクラウドサービスの特徴に伴う運用の違い 1.1 クラウドサービス利用料の特徴 自治体の予算制度は単年度が原則です。従来のオンプレミス方式（庁舎内又はデータセンターにサーバーを設置する方式）では、5年リースの契約時に年間費用が確定し、リース料を長期継続契約や債務負担行為により複数年にわたる経費の平準化と予算の見通しを確保してきました。 一方、クラウドサービスは初期投資不要/従量課金で利用できる特性を有するため、システム利用状況に合わせて無駄なく利用できる一方、予算の編成や執行等において、従来のオンプレミスとは異なる運用が必要になります。例えば、AWSのクラウドサービスの利用料には、次のような特徴があります。 従量課金 ：使った分だけ請求される仕組みであり、月ごとに金額が変動します。繁忙期（確定申告時期等）にはリソースを拡張し、閑散期には縮小することで無駄を抑制できます。 USD（米ドル）建て ：ガバメントクラウド（AWS）の利用料は米ドルで計算されるため、為替レートの変動が円換算後の支出に影響します。なお、為替を固定する契約方式も選択肢として存在します。 運用中のリソース最適化・コスト最適化が可能 ：オンプレミスでは契約更新時にしかコスト見直しができませんが、クラウドでは稼働中に随時リソースの追加・削減が可能です。 つまり、クラウドの予算管理では「予算要求時の見積もり精度」と「年度途中の予実管理」の双方が重要になります。 1.2 クラウドの特性を踏まえた新たな予算管理の考え方 また、オンプレミスの情報システムの構成をそのままクラウドに移行する「単純リフト」では、クラウドの特性を活かしきることができず、サーバーの規模が過大なまま稼働するなどにより、利用料がオンプレミス時代を上回るおそれがあります。デジタル庁による先行・検証事業等においても、単純移行ではコスト増となる事例が報告されています。 こうしたなか、財政部門としては、予算査定の際に「コスト最適化計画」の実行状況を確認することが有効となります。クラウドの費用対効果を発揮するには、移行後にコスト適正化（不要リソースの削減、サーバー規模の見直し等）を継続的に実施することが重要になります。デジタル庁が整備しガバメントクラウドに関する情報を提供しているGCASガイドにおいても、本番稼働後に継続的なコスト最適化へ取り組むことの重要性が示されています。 1.3 コスト最適化への取組 クラウドは本番稼働後がコスト最適化のスタート地点です。財政課としては、最適化の取組が継続的に行われているかを経年の予算査定や四半期報告の中で確認することが考えられます。従来、運用経費としてまとめられている経費の詳細な内訳、費目、区分が判然とせず、算出することも困難な状況にありました。しかし、クラウドサービスの特徴と、AWS Cost Explorer、AWS Budgets 等の管理ツールにより、リアルタイムで状況を可視化できます。毎月の従量課金の請求を踏まえることで、どのサービスを、どのように活用しているのか、関連する運用の人件費との切れ目はどうなっているのか、工数・人月・単価は適切かどうか、人件費のほかシステムやサービス利用料以外が過大になっていないかなどを精査できるようになります。 例えば、クラウド利用料だけを見ると「新規コストが発生した」ように見える場合であっても、オンプレミス時代には「見えにくい形」で発生していた「隠れたコスト」を含めた総保有コスト（TCO）で比較すると、クラウド移行によりシステム全体のコストが削減されているケースもあります。 （隠れたコストの例） データセンターの電気代・空調費（施設管理費の中に含まれていたもの） 職員がサーバー管理に費やしていた工数（人件費の中に含まれていたもの） 5年ごとのハードウェア更新費用（更新年度に一括計上されていたもの） 災害対策用のバックアップ設備投資 このように、コスト最適化の取組によりクラウドサービスに適した運用管理を実施していくためには、事業者（ASP/運用管理補助者）も含め、各部門が連携するスキームを確立して運用することが重要です。また、各部門の役割分担と報告ルート（情報システム部門→原課→財政課）を予め明確にしておくことで、PDCAサイクルに基づく継続的なコスト適正化が実現します。 また、例えば、情報システム専任部署を持たない小規模団体においては、ASP事業者からの月次コストレポートを受領することを基本とし、四半期ごとに財政担当が確認するという簡易な運用から始めることも方法のひとつです。この場合、ASP契約仕様書において、コストレポート（利用量・費用明細）の月次提出義務を含めておくことが考えられます。 なお、このコスト最適化には、予算を縮減することばかりが含まれるのではなく、より適切なサービスを利用するため、あるいは、より適した人材をアサインするために予算の枠内で割り当てを再分配したり、必要な経費等を増加させることも含まれる点にご留意ください。 （参考） 利用方式や環境によっては、AWS マネジメントコンソール（AWS Cost Explorer、AWS Budgets 等を含む）の閲覧権限が自治体職員に付与される場合があり、従来はASP（事業者）経由でしか確認できなかったコスト情報を、自治体職員が自ら確認できる事例も出ています。閲覧権限の付与を運用管理補助者に求める際の調達仕様書の記載例は、シリーズ②-1 の 3.1 で紹介しています。 以降、自治体の予算サイクル（予算要求→執行→決算）に沿って、クラウドコストの管理方法を具体的に解説します。 図: クラウドコストと自治体の予算サイクル（括弧内は本記事の対応章） 2. 年度予算要求時のコスト見積もり 原課又は情報システム担当から提出されるクラウド利用料の予算要求書を査定する際に、財政課が確認するとよいポイントを解説します。なお、ガバメントクラウドの利用形態は「共同利用方式」と「単独利用方式」に大別され、それぞれ見積もり精査のポイントが異なります。本記事では主に共同利用方式を念頭に記載しますが、単独利用方式の場合は、AWS アカウント内のリソースがすべて自団体の費用等となるため按分が不要となり、見積もりにおいて、共同利用方式と比較して考慮事項等が少ない特徴があります。 2.1 移行初年度の見積もり ガバメントクラウドへの移行初年度は、過去の実績データがないため、見積もりの難度が最も高い年度です。主に、 AWS Pricing Calculator を用いて概算を行います。現行システムの構成（サーバー台数、CPU/メモリ/ディスク等）を整理し、対応するAWSサービスにマッピングして試算します。また、デジタル庁がGCAS上で提供する利用料比較の仕組み（提供状況・利用方法はデジタル庁の案内をご確認ください）を活用し、人口規模や業務内容が類似する他団体の利用実績を参考値（メルクマール）とすることで、見積もりの妥当性を検証することも重要です。財政部門が予算査定を行う際は、これらの比較データの提示を求めることが有効です。 また、クラウドへの移行完了までの既存システム運用費が見落とされてしまうと、システム停止を余儀なくされてしまう可能性があります。このような移行過渡期に係る費用についても適切に計上されていることを確認してください。なお、クラウド移行に当たっては、テスト環境の稼働、一時的なスケールアップ、想定外のデータ転送等のコストの考慮も必要になります。提供する行政サービス等の停止等を防ぐためにも、初めてのシステムの移行は抜け漏れなく慎重に、かつ従量課金を加味してバッファを持つことが考えられます。そのため、類似する、あるいは先行する同規模の事例を参照した上で、初年度は特に余裕を持った予算を確保することを推奨します。 確認項目 主なチェックポイント 見積もり根拠 AWS Pricing Calculator 等のツールを使った試算結果が添付されているか スペック インスタンスサイズ（サーバー規模）が現行システムの実使用量に対し適正か。類似規模の他団体における実績値と大きく乖離していないか クラウド利用料・移行スケジュール ・何月からクラウド利用料が発生するか（月数 × 月額で積算されているか） ・テスト環境稼働から移行完了後年度末までの月数分が適切に計上されているか 移行作業費 データ移行、環境構築、テスト等に要する作業費用が適切に計上されているか 環境稼働 ・テスト環境の稼働時間が限定されているか（24時間稼働は不要） ・共同利用方式の場合、運用管理部分（監視・バックアップ等）及びネットワーク部分の費用が適切に按分されているか ・開発環境・テスト環境が移行計画に沿ったタイミングで縮退・終了される計画となっているか（稼働後も残存していないか） 並行稼働費 移行完了までの既存システム運用費が適切に計上されているか 為替考慮 為替変動と為替固定の双方の契約方式における費用や差異を比較しているか 査定のコツ : 初年度は「不確実性が高い」ことを前提に、予算を認める代わりに「四半期ごとの実績報告」を条件として付すことで、執行段階での管理を担保できます。 2.2 2年目以降の見積もり 2年目以降は、前年度の実績データが最も信頼できる見積もり根拠になります。 見積もり手順： 前年度の月別利用実績（USD）をAWSの請求データから取得します。 季節変動（確定申告時期の負荷増、年度末処理等）による増減を考慮します。 新規サービスの追加・既存サービスの廃止の影響を加味します。 前年度に実施したコスト最適化施策の通年効果（年度途中の実施分を12か月に拡張）を反映します。 為替レートを設定してJPYに換算します。 予見し難い環境変化への対応に要する経費として予備的な経費を上乗せします。なお、予算査定においては、予備的な経費分の予算については執行保留分とする運用も考えられます。いずれにせよ、予備的な経費の設定にあたっては根拠の明示が重要です。 （参考）計算例：前年度の月平均利用額が$4,200の場合、通年換算で$50,400。変動要因（+$5,100）と最適化効果（▲$4,800）を加味すると$50,700。レート160円/USDで換算すると約811万円。予備的な経費として仮に12%（97万円）を加えると、予算要求額は908万円となります（12%は計算のための仮の値です）。 長期利用割引（リザーブドインスタンス・Savings Plans）を適用している場合、または適用を予定している場合の予算上の扱いは、Appendix で補足しています。 確認項目 主なチェックポイント 前年度実績 月別実績データ（USD）が添付されているか。根拠のない増額要求になっていないか 変動要因 増額の場合：具体的な理由（利用者増、新機能追加等）が示されているか 最適化効果の反映 前年度の削減施策の効果が次年度見積もりに反映されているか（反映されていなければ過大） リスク予見・予備的な経費 過去1年間の実際の変動幅に対して上乗せ幅が過大でないか（2年目以降も初年度と同じ上乗せ幅のままになっていないか） 3. 年度途中のコスト変動への対応 情報システム担当または原課から四半期ごとに報告を受ける際、次の観点で確認します。 確認項目 主なチェックポイント 予算消化率 経過月数に対し、許容範囲であるかどうか 年度内の予算消化 予算内に収まる見通しかどうか 為替の影響 実績が予算レートを上回っている場合、予算の枠内に収まる見込みかどうか 最適化の取組 施策が実施されているか（「特になし」は要確認） 3.1 AWS Budgets による予算設定・予算超過の防止 GCASガイドの予実管理では、AWS Budgets に月次予算を設定することとされています。年間予算額（USD）を利用月数で除算して月次予算額を算出しつつ、季節変動を考慮し、繁忙月（確定申告時期の1〜3月等）は多めに、閑散月は少なめに配分されていることを確認してください。これらの設定を行うことで、予算超過が見込まれる場合に事前アラートにより早期検知と対策が可能になります。アラートの主な設定方法としては、①AWS Budgetsにより閾値を設定して予算上限超過を監視する、②AWS Cost Anomaly Detectionによりコスト急騰などの異常検知を行う、の2つが挙げられます。 アラートが発報された場合の原課の主な対応は、次のとおりです。 設定ミスや不要リソースの放置であれば即時是正 月末までと年度末までの累計見込みを算出し、意思決定権者に報告 予算超過が見込まれる場合に事前アラートの通知先に、財政課を含めておくことで、財政課側から対応を指示することが可能となり、早期の対策による予算超過の予防にも繋がります。 図: （参考）AWS Budgets と AWS Cost Anomaly Detection による予算超過・異常の検知 3.2 執行残発生時の扱い 従量課金では、利用が少なかった場合に執行残が発生します。発生要因には、次のようなケースがあります。 コスト最適化施策の成果（積極的な取組の結果） 想定より利用量が少なかった（利用者数が見込みを下回った等） 為替レートが有利に推移した（外部要因） 見積もり時の予備的な経費の設定が過大だった このうち、最適化の成果による執行残は、クラウドサービス及びFinOpsの活動の優れた成果になります。一方で、執行残が発生したことを理由に、翌年度予算を機械的に削減することにはリスクもあります。最適化の取組の再現性の検証、関連システムも含めた全体最適としての運用の確認等、次年度以降の変動事由の考慮等を踏まえる必要があります。そこで、最適化の効果が生じた翌年度（N＋1年度）は、効果が継続しているかを検証する期間とし、効果が定着したことを確認できた段階で、翌々年度（N＋2年度）の予算の見直しに反映するといった段階的な扱いも考えられます。政策目的に照らした適切なシステム運用等を目指しつつ、原課の意欲を最大限発揮することが可能な仕掛けで、FinOpsと効果検証を着実に進めることが重要です。 また、クラウドサービスの強みは、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等が可能である点です。これらは、住民サービスの向上、DXの加速化、セキュリティ強化にも直結するものであり、さらなる利便性と安心の好循環を生み出すことが期待されます。また、平時の運用管理やシステム/サービスを活用した執務の遂行について、更なる業務効率化に向け、最新のデジタル技術やAI等の活用を図ることも効果的です。 そのため、最適化の取組等により発生した執行残について、予算活用の短期・中期の運用サイクルとして、本来的な政策目的等を含め、原課・情報システム課・財政課その他の関係機関で認識合わせを行うことが重要です。その際、例えば、予算執行のルールの範囲内において、執行残をうまく活用しつつ、FinOpsの結果の定性化や最新技術の試用や実証実験等への活用を選択肢の一つとして検討することで、コスト最適化の取組を継続する動機付けにもなり得ると考えられます。 4. まとめ 以上、クラウドコストの予算管理をテーマとし、クラウド経費の予算査定・執行管理を行う際の実務的な視点についてご紹介いたしました。 繰り返しになりますが、クラウドは本番稼働後がコスト最適化のスタート地点です。クラウドサービス利用料の適正化によるコスト削減に努めつつ、柔軟な機能拡張やログ分析基盤をスピーディに構築し、最新技術の短期間の試験運用等を通じて、住民サービスの向上、DXの加速化、セキュリティ強化に取り組むことが期待されます。クラウドサービスの利用実績の可視化、削減提案、翌事業年度の改善提案・目標設定等のサイクルを効果的に実施することで、デジタル技術を使いこなし、効率的な行政運営と豊かで便利な社会を実現していただければと存じます。 より詳しく知りたい方へ 本記事で扱わなかった日々のコスト確認や調達仕様書への反映などは、シリーズの他の記事で解説しています。 やりたいこと 参照先 定期的なコスト確認の手順・チェックリストを知りたい シリーズ① 調達仕様書へのFinOps要件の反映方法を知りたい シリーズ②-1 生成 AI を使ったコスト確認の効率化を知りたい（公開予定） シリーズ②-2 運用管理補助者・ASPとして具体的に何をすべきか知りたい（公開予定） シリーズ④ Appendix 長期利用割引（リザーブドインスタンス・Savings Plans）の予算上の扱い AWSには、一定期間（1年又は3年）の利用を約束（コミット）することで割引を受けられる仕組みがあります。これは、自治体が複合機やコピー用紙を「年間契約」することで単価が下がるのと同じ考え方です。 通常利用（従量課金） ：毎月、使った分だけ定価で請求されます。 長期利用割引適用後 ：Savings Plans は「1時間あたりの利用金額（USD）」、リザーブドインスタンスは「インスタンスの種類と台数」を単位としてコミットし、コミット分には割引単価が適用されます。コミットを超えた利用分は通常の従量課金単価で請求されます。 購入・設定の流れ ガバメントクラウドでは、リザーブドインスタンス・Savings Plans のいずれも、自治体と合意した内容に基づいて運用管理補助者が購入・設定します。財政部門としては、購入の時期・期間・コミットの水準が予算と整合しているかを、情報システム担当とあらかじめ確認しておくことが考えられます。コミットは期間中の変更・取消が原則できないため、確実に利用する水準で設定することが重要です。購入時期の考え方は、シリーズ①の 2.2 で紹介しています。 自治体が過去の利用実績を基に、確実に利用する最低水準のコミット額を算出します。 デジタル庁に対して長期利用割引の適用を申請します。 デジタル庁が申請を取りまとめ、一括で割引を購入・適用します。 割引効果が自治体の月次利用料に反映されます。 ※ コミットは期間中の変更・取消が原則できないため、確実に利用する最低水準で設定することが重要です。申請手続きの詳細や最新の運用は、デジタル庁の案内をご確認ください。 免責事項 : 本記事の内容は情報提供を目的としたものであり、特定の環境や要件に対する推奨を保証するものではありません。実際の効果は個別の環境・構成により異なります。AWS サービスの料金は変更される場合がありますので、最新の料金情報は AWS 料金ページ をご確認ください。 ガバメントクラウドに関するご相談: ガバメントクラウドの利活用に関するご質問やご相談は、 AWS ガバメントクラウド相談窓口 までお問い合わせください。 筆者について Chisaki Noguchi 野口 智紗樹（Chisaki Noguchi）は、自治体向けの新規事業開発等担当です。中央省庁での勤務経験を活かし、政府の方針等を踏まえた中長期的な視点で、クラウドやAIを活用した行政課題・地域課題の解決、持続可能なサービスの構築等による豊かで便利な社会の実現に取り組んでいます。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。

本ブログは 2026 年 4 月 16 日に公開された AWS Blog “ How Automated Reasoning checks in Amazon Bedrock transform generative AI compliance ” を翻訳したものです。 規制業界のコンプライアンスチームは、手作業のレビューに数週間を費やし、外部コンサルタントにも費用を支払っていますが、AI の出力に形式的な証明がない場合には、依然として監査上のギャップに直面します。 Amazon Bedrock Guardrails の自動推論チェック (Automated Reasoning checks) は、確率的な AI 検証を数学的な検証に置き換えることでこの課題に対処し、AI が生成した判断を、正しさを証明でき、監査も可能な結果へと変えます。 この記事では、規制業界で確率的な AI 検証が不十分となる理由と、自動推論チェックが 形式的検証 によって数学的に証明された結果を提供する仕組みを説明します。さらに、6 つの業界のお客様がこのテクノロジーを活用して形式的に検証された監査可能な AI 出力を実現している事例と、利用を開始する方法も紹介します。 コンプライアンスの課題 規制業界は、失敗の代償が大きいコンプライアンスの課題に直面しています。病院は放射線安全規制に対応しなければなりません。金融機関は EU AI 法 に基づいて AI リスクを分類します。保険会社は補償範囲に関する質問に答えていますが、回答を誤ると規制上の責任を問われかねません。手作業のレビュー、高額なコンサルタント、従来型のプロセスはスケールしません。 生成 AI やエージェンティック AI ソリューションを構築する多くのチームは、LLM-as-a-judge パターン、つまり 2 つ目の大規模言語モデル (LLM) に最初のモデルの出力を評価させる手法に頼りがちです。直感的な方法ではありますが、このアプローチには 根本的な限界 があります。確率的なシステムが別の確率的なシステムを検証しても、規制業界が求める形式的で監査可能な保証は得られないのです。 自動推論チェックが定義済みのルールと制約に対して証明可能なコンプライアンスを実現する仕組み Amazon Bedrock Guardrails の自動推論チェックは、数理論理学に基づく 形式的検証手法 を適用し、AI が生成した出力を定義済みのルールと制約に照らして検証します。これにより、すべてのリクエストに対して、正しさを証明でき、監査も可能な評価結果が得られます。 例を挙げて考えてみましょう。AI アシスタントが、顧客の保険金請求は補償対象だと回答したとします。LLM-as-a-judge のアプローチでは、2 つ目のモデルがその回答をレビューして「妥当と思われる」と判断するだけです。一方、自動推論チェックでは、その回答がポリシー内のすべてのルールと整合していることを数学的に証明します。ルール違反があれば、どのルールにどのような理由で違反しているのかを正確に特定します。 図 1: 定理証明、型システム、モデル検査、抽象解釈、シンボリック実行、SMT 問題の求解、SAT 問題の求解を含む自動推論の分類。SAT 問題と SMT 問題の求解が自動推論チェックの基盤を形成します   自動推論は、与えられた前提から論理的な結論を自動的に導き出すアルゴリズムを開発する分野です。 形式的検証 (システムが仕様を満たすことを数学的に証明する手法)、 充足可能性判定 (satisfiability solving。論理式を充足できるかどうかを判定する手法)、 数理論理学 といった分野で数十年にわたり蓄積された研究成果を基盤としています。 これと同じ基盤は、ハードウェア設計の検証、暗号プロトコルの健全性の証明、安全性に直結するソフトウェアにおける仕様違反箇所の正確な特定にも使われています。自動推論チェックは、これらの手法を生成 AI に適用したものです。 自動推論チェックは、ニューラルネットワークと論理的推論を組み合わせ、AI の出力を定義済みのルールと制約に照らして検証することで、確率的な応答を形式的に検証された監査可能なアーティファクトへと変換します。AWS は、AI アプリケーションを保護するための複数の 責任ある AI ツールの 1 つとして、自動推論チェックを提供しています。 自動推論ポリシー (Automated Reasoning policy) の設定方法と検証の実際の動作を詳しく知りたい場合は、 「Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks」 を参照してください。 訳注: 上記の記事はプレビュー期間中 (2025 年 4 月) に公開されたものです。一般提供開始後の機能に基づいた手順は、日本語版ブログの「 Amazon Bedrock の自動推論チェックによる信頼できる AI システムの構築 – パート 1 」で確認できます。 図 2: Amazon Bedrock の自動推論チェック。ポリシーのエンコード、出力の変換、形式的検証エンジン、結果の生成という 4 段階のプロセスを示しています。 業界での活用例 ヘルスケア、金融、エネルギー、保険、教育といった分野の組織が、自動推論チェックを使って AI の出力を検証し、監査にそのまま使えるエビデンスとともにコンプライアンス上の判断を説明しています。 オペレーションエンジニアリング: Amazon Logistics Amazon Logistics では、エンジニアリングレビューの所要時間を約 8 時間から数分へ短縮しながら、すべての判定について形式的なコンプライアンス検証を得られるようになりました。Amazon Logistics の Sustainability Engineering チームは、Amazon のデリバリーステーションネットワーク全体への電気自動車充電ポイント (EVCP) の展開を主導しています。設置提案は、それぞれ地域固有の規制と社内技術仕様を満たす必要があります。以前は、レビュー 1 件ごとに対象分野の専門家がエンジニアリングパラメータを手作業で照合し、約 8 時間を費やしていました。 チームは AWS と協力し、自動推論チェックを活用した生成 AI 支援の設計レビューポータルを構築しました。このポータルは技術仕様を自動推論ポリシーへ変換し、変数、型、条件を明示的に定義した厳密な論理ルールを作成します。そして、提案書から抽出したエンジニアリングパラメータを形式的な数学的推論によって検証します。ドキュメントインテリジェンスレイヤーは Amazon Bedrock の Claude が担い、構造化されていない提案書からデータを抽出して構造化します。 「意思決定を行うのは引き続き当社の専門家です。ツールの動作は完全に可視化されており、あらゆる推奨事項をトレース、検証、妥当性確認できるという確信を持てます」 – AMZL、Sr. Sustainability Engineer、Paula Garcia Carrasco 対象分野の専門家は、煩雑なパラメータの照合ではなく、エンジニアリング上の判断に集中できるようになりました。 詳細は Amazon Logistics の導入事例をご覧ください 。 金融サービス: Lucid Motors と PwC Lucid Motors は、予測の生成にかかる時間を数週間から 1 分未満へ短縮し、わずか 10 週間で 14 の AI ユースケースを全社規模にスケールしました。電気自動車メーカーである同社は、PwC および AWS と協力して、AI ネイティブな財務予測・分析ソリューションを構築しました。財務チームが抱えていたのは、予測サイクルに数週間の手作業を要し、急速に変化する市場環境へ迅速に対応できないという、多くの企業に共通する課題でした。 PwC と AWS は共同で、Amazon Bedrock 上に機械学習 (ML) ベースの予測エージェントを構築しました。さらに自動推論チェックを形式的検証レイヤーとして適用し、モデルの出力があらかじめ定義された財務上のルールと制約に従っていることを数学的に検証しました。このアプローチにより、確率的な AI だけでは見逃しかねない論理的な不整合を検出できます。 財務チームは、レポートを数週間待つのではなく、リアルタイムでビジネス上の意思決定に積極的に関与できるようになりました。 「PwC と AWS とともに、Lucid はクラウド環境をイノベーションのためのプラットフォームへと変えています……PwC のチームは予測ツールを迅速に構築し、数週間かかっていた手作業を 1 分未満に短縮しました」 – Lucid、Head of Business Finance、Aditya Baheti 氏 Lucid Motors の導入事例をご覧ください。 ヘルスケア: 規制の複雑さへの対応 ヘルスケア組織は規制と安全に関する厳しい監督の下で事業を運営しており、厳格な内部統制、文書化、継続的な監査が求められます。臨床、業務、安全の各基準にわたってコンプライアンスを確保する作業はヘルスケアチームに大きな負担となり、本来の患者ケア業務から時間と労力を奪っています。 Fortive のヘルスケア事業会社は、テクノロジーを活用した安全性とコンプライアンスのソリューションを通じて、顧客がこの複雑さに対処できるよう支援することに注力しています。Fortive はイノベーション戦略の一環として、自動推論などの AI 主導のアプローチがよりプロアクティブなコンプライアンス管理をどう支援できるかを評価しています。ポリシーを要件に照らして決定論的に検証し、潜在的なギャップを早期に可視化することで、監督業務の効率化、手作業の削減、そして厳密性を損なわない意思決定の迅速化を実現できる可能性があります。 「自動推論を評価したことで、その強みと、最も価値を発揮する課題の種類の両方をより深く理解でき、確率的な AI を超えて数学的な確実性へと進むことができました」 – Fortive、Data Science & AI Leader、Gaurav Mantro 氏 教育: First Education & Technology Group (FETG) と PwC FETG は、ルール設定の作業を最大 80%、継続的なコンプライアンスの運用負荷を 50% それぞれ削減し、応答レイテンシーを 8～13 秒から 1.5 秒へ最適化しました。MarsLadder AI 学習システムを運営する First Education & Technology Group (FETG) は、PwC および AWS と協力して、生徒向け生成 AI のための責任ある AI ガバナンスレイヤーを構築しました。従来のモデレーション手法やキーワードフィルター、確率的な分類器では、文脈と意図が重要となる Safer Technologies 4 Schools (ST4S) フレームワークを確実に適用できませんでした。 PwC は自動推論チェックを決定論的な検証レイヤーとして実装し、ST4S の原則をデータ保護と生徒の安全を網羅する 10 個の形式論理ルールへ変換しました。このシステムは、AI が生成したすべての応答を学習者に届く前に検証し、確率的な判断を数学的に証明可能なコンプライアンスへ置き換えます。 このソリューションは、教育分野の規制当局が ST4S フレームワークの遵守のために求める、数学的に証明可能なコンプライアンスのエビデンスを提供します。 教育における責任ある AI に関する PwC の導入事例をご覧ください。 自動推論チェックを採用するその他の業界 他の規制業界の組織も、コンプライアンスを強化するために自動推論チェックを採用しています。 金融サービス (EU AI 法): EU AI 法に基づいて AI リスクを分類する組織は、自動推論チェックを使って、一貫性のない手作業のレビューから、形式的に検証でき、監査にも対応できるコンプライアンスワークフローへ移行しています。詳細は 「PwC and AWS Build Responsible AI with Automated Reasoning on Amazon Bedrock」 をご覧ください。 エネルギー・公益事業: 電力事業者は、AI が生成した停電の分類を北米電力信頼度協議会 (NERC) および米国連邦エネルギー規制委員会 (FERC) の規制要件に照らして検証し、個々のディスパッチ判断を形式的検証で裏付けています。 このユースケースに関する PwC との re:Invent セッションをご覧ください 。 製薬とライフサイエンス: プロフェッショナルサービス企業は、AI 主導のマーケティングコンテンツ向けに数学的に裏付けられる検証レイヤーを構築し、コンテンツの主張が承認済みの根拠資料に基づいていることを確認しています。 保険: 保険会社は、約款の記述に対して形式的に推論する顧客向けチャットボットを構築し、確率的な近似ではなく検証可能な補償判定を提供しています。 まとめ この記事では、Amazon Bedrock Guardrails の自動推論チェックが、監査にそのまま使えるエビデンスとともに数学的に証明可能な検証を提供する仕組みを説明しました。規制業界でコンプライアンスアシスタントを構築するチームや、既存の AI ワークフローに形式的検証レイヤーを追加したいチームにとって、このテクノロジーは確率的な確信から数学的な証明へ進むための道筋となります。 自動推論チェック は、AWS の他の責任ある AI 機能を補完します。例えば、検索拡張生成 (RAG) のための Amazon Bedrock ナレッジベース 、コンプライアンス追跡のための AWS Audit Manager 、モデルガバナンスのための Amazon SageMaker AI などです。 訳注: AWS Audit Manager はメンテナンスモードへの移行が公表されており、2026 年 4 月 30 日以降は新しいアカウントでこのサービスをセットアップできません。セットアップ済みのアカウントでは引き続き利用できます。参照: AWS Audit Manager 可用性の変更 、 AWS Audit Manager とは 開始方法 使ってみる: セットアップのガイダンスについては、 自動推論チェックのドキュメント をご覧ください。 訳注: 2026 年 9 月現在、自動推論チェックがサポートする言語は英語です。最新の対応状況は、Amazon Bedrock ユーザーガイドの「 Amazon Bedrock ガードレールの自動推論チェックとは 」を参照してください。 実践的な手順については、 「Minimize generative AI hallucinations with Amazon Bedrock Automated Reasoning checks」 を参照してください。 チャットボットは、自動推論チェックのフィードバックを使い、正しさを証明できる回答に到達するまでユーザーに確認の質問をしながら、回答を繰り返し書き換えることができます。 始めるには、 「自動推論チェックで回答を書き換えてハルシネーションを抑えるチャットボットのリファレンス実装」 を参照してください。 エージェントを使えば、自動推論ポリシーを改善するプロセス全体を自然言語で対象分野の専門家に案内できます。そうしたエージェントの オープンソースのサンプル をご覧ください。 お客様の成果を見る: Amazon Logistics の導入事例 | 教育における責任ある AI に関する PwC の導入事例 | AWS の責任ある AI のリソース Amazon Bedrock の機能の詳細: Amazon Bedrock Guardrails | Amazon Bedrock AgentCore AI ライフサイクル全体にわたるガイダンスと責任ある AI のベストプラクティス: AWS Well-Architected 責任ある AI レンズ 自動推論チェックがお客様のコンプライアンスのユースケースにどう役立つかについては、担当の AWS アカウントチームにお問い合わせください。準備として、AI の出力に形式的検証が必要となるコンプライアンスワークフローを、重要度の高い順に 3 つ挙げておくとよいでしょう。 図 3: Amazon Bedrock の自動推論によるコンプライアンスチェックのリファレンスアーキテクチャ。 ユーザーは Amazon CloudFront 経由でアプリケーションにアクセスします。CloudFront は Amazon Simple Storage Service (Amazon S3) の静的ホスティングから React フロントエンドを配信します。 Amazon Cognito がユーザーを認証し、JWT トークンを発行します。CloudFront は下流のリクエストに対して認証を強制します。 ユーザーは、地域、施設タイプ、ライセンスカテゴリを指定してコンプライアンスチェックのリクエストを送信します。CloudFront はそのリクエストを AWS Lambda にルーティングします。 Lambda は、地域、施設タイプ、ライセンスカテゴリをキーとして Amazon DynamoDB のルールエンジンにクエリを実行し、該当する規制ルールを正確に取得します。 Lambda はルールをプロンプトに挿入し、Amazon Bedrock を呼び出します。ナレッジベースは、Amazon S3 に保存された検証済みの規制文書から RAG のコンテキストを提供します。 生成されたコンプライアンスチェックリストは Amazon Bedrock の自動推論チェックに送信されます。自動推論チェックはルールを形式論理モデルにコンパイルし、各項目を数学的に検証します。この検証は確率的ではなく、証明可能です。 検証済みの項目は Amazon S3 に保存され、ユーザーに返されます。無効な項目は、モデルによって修正版が再生成されます (最大 3 回まで再試行)。対象範囲外の項目は理由付きで自動的に除外されます。 2 つ目の DynamoDB テーブルには顧客施設のプロファイルが保存されており、リクエストごとにデータを再アップロードすることなく、ID で病院を検索できます。 Amazon EventBridge スケジューラが設定可能なスケジュールで Lambda のウェブクローラーを起動し、政府の規制関連ウェブサイトをスクレイピングして、ポリシーの変更に関する情報を収集します。 スクレイピングしたコンテンツは Amazon Bedrock のポリシー差分エージェントに送信され、変更内容が検出されます。更新されたルールは DynamoDB に書き込まれ、新しい文書はナレッジベースに再インデックスされます。 自動推論チェックの検証証明を含むコンプライアンスレポートは DynamoDB に保存され、監査証跡、フィルタリング、ダウンロードのために [レポート] タブからアクセスできます。 謝辞 本取り組みに貢献いただいた Suresh Kanan、Tonny Ouma、Laurie Kasper、Stefano Buliani に特に感謝します。 著者について Nafi Diallo Nafi Diallo は Amazon Web Services の Senior Automated Reasoning Architect で、信頼できる AI ソリューションのための AI の安全性、形式的検証、ガードレールの実装を専門としています。Amazon Bedrock 上の生成 AI およびエージェンティック AI システムの信頼性を評価し、向上させる豊富な経験を持っています。また、AWS の Women in AI and ML (WAIML) 組織で北米地域の Regional Lead を務め、チャプターの成長を支援しながら、地域全体で WAIML のミッションを推進しています。 Aishwarya Natarajan Aishwarya Natarajan は、ジョージア州アトランタを拠点とする AWS の Solutions Architect で、産業用 IoT と AI/ML の専門知識を活かして自動車・製造業界を担当しています。クラウドテクノロジーを使ってお客様独自のビジネス課題の解決を支援することに情熱を注いでいます。余暇には家族や友人と過ごしたり、新しい場所を訪れたりすることを楽しんでいます。 Adewale Akinfaderin Adewale Akinfaderin は Amazon Bedrock の Generative AI 担当 Sr. Data Scientist で、AWS における基盤モデルと生成 AI アプリケーションの進化に貢献しています。再現可能でエンドツーエンドの AI/ML 手法、実践的な実装、そして世界中のお客様が学際的な課題に対してスケーラブルなソリューションを策定・開発できるよう支援することを専門としています。物理学分野で大学院の学位を 2 つ、工学の博士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。