この記事では、 Amazon DynamoDB データに対する検索を Amazon OpenSearch Service との ゼロ ETL 統合を使用して実装する方法を紹介します。データパイプラインの構築と保守を行うことなく、アプリケーションに全文検索、あいまい一致、複雑な検索クエリを追加する方法を学びます。 Amazon DynamoDB は、大規模な環境で 1 桁ミリ秒の応答時間と高スループット操作を必要とするアプリケーションに最適な選択肢です。OpenSearch Service と組み合わせることで、アプリケーションは複雑な検索と分析のための強力な機能を獲得します。このゼロ ETL 統合がアプリケーションの検索機能をどのように強化できるかを示す実用的なユースケースを見ていきましょう。 現状の概要 AnyCompany は、エコフレンドリーで持続可能な製品を専門とする架空のオンラインマーケットプレイスで、世界中の環境意識の高い消費者にサービスを提供しています。彼らのアプリケーションは AWS サーバーレスアーキテクチャ 上で動作しており、 AWS Lambda 関数が e コマース操作を処理します。製品情報や在庫詳細などのコアトランザクションデータは DynamoDB に保存されています。 AnyCompany の製品用 DynamoDB テーブルレイアウトには、以下の属性が含まれます： 属性 例 product_id ( パーティションキー ) Id_1 name ECO T-Shirt description Organic CottonTee price 100 rating 5 category Activewear brand AnyCompany tags organic specs {“color”:”white”,”size”:”M”} stock 48 created_at 2025-12-16T16:15:43.473864+0000 updated_at 2025-12-16T16:15:43.473864+0000 書き込み操作では、AnyCompany は DynamoDB を使用してデータの一貫性を維持します。製品情報を更新する際、システムは product_id をパーティションキーとして使用して製品の更新を実行します。AnyCompany の製品カタログの拡大により、顧客の検索パターンがより複雑になり、システムはバリエーション、スペルミス、セマンティッククエリ、ファセット検索（顧客が価格帯、ブランド、評価、製品カテゴリなどの複数の属性を使用して製品をフィルタリングし、絞り込むことができる機能）を処理する必要があります。 企業が拡大するにつれて、以下のような検索シナリオが浮上しています： マルチフィールド検索 – 顧客は、製品名、説明、カテゴリ、タグなどの複数のフィールドを同時に検索する必要があります。 マルチレンジ検索 – 顧客は、価格帯（$20-$50）や評価（4-5 つ星）など、複数の基準で製品をフィルタリングしたいと考えています。 発見とナビゲーション – 顧客は、ファセット検索を使用して結果を段階的に絞り込み（カテゴリ、ブランドなどのフィルタを使用）、動的な集計を通じて選択肢を理解したい（カテゴリ別の製品数、ブランド、評価の分布を確認するなど）と考えています。 あいまい検索と提案 – 顧客は、タイプミスやスペルミスがあっても検索が機能することを望んでいます（例えば、「reuseble botl」と入力しても「reusable water bottle」が見つかる）。また、入力中にオートコンプリート提案を受け取り、製品をより迅速に見つけられるようにしたいと考えています。 セマンティック検索 – 顧客は、正確な製品名ではなく自然言語の説明を使用することがよくあります。例えば、「biodegradable kitchen storage containers」を検索すると、関連するエコフレンドリーな食品保存製品が返されるべきです。 AWS は DynamoDB と OpenSearch Service 間のゼロ ETL 統合 を提供し、これら 2 つのサービス間でデータを同期します。この統合により、カスタムデータパイプラインを構築および保守することなく、OpenSearch Service の検索機能で DynamoDB ベースのアプリケーションを補完し、これらの検索要件を満たすことができます。 以下の例では、OpenSearch Service が AnyCompany のこれらの検索シナリオで DynamoDB をどのように補完するかについて説明します。 マルチフィールド検索 顧客の検索パターンは本質的に動的であり、顧客は常に製品を検索する新しい方法を求めています。AnyCompany では、顧客は検索クエリが複数の製品属性に同時に一致することを望んでおり、製品名、説明、カテゴリ、タグで一致を探して、関連するアイテムを見逃さないようにしています。 OpenSearch は、検索ユースケースをカスタマイズし、検索の関連性を向上させるための多くの機能を提供します。完全なリストについては、 検索機能 を参照してください。OpenSearch は、データを検索するために使用できる クエリドメイン固有言語（DSL） と呼ばれる検索言語を提供します。 以下は、この機能を実装するクエリの例です： GET products/_search { "query": { "bool":{ "should": [ { } ] } }, "size":20 } マルチレンジ検索 前述の検索機能に基づいて、AnyCompany の顧客は、特定の価格帯（$25–50）内の製品を検索しながら、特定のカテゴリと評価を考慮するなど、複数のフィルタリング基準を組み合わせたいと考えることがよくあります。 OpenSearch Service では、さまざまな方法を使用して検索結果をフィルタリングできます。各方法は特定のシナリオに適しています。クエリレベルでフィルタを適用し、 Boolean クエリ句と post_filter および aggregation レベルのフィルタを使用できます。 以下は、この機能を実装するクエリの例です： GET products/_search { "query": { "bool":{ "should": [ { "multi_match": { "query": "Men's Wear", "fields": ["name.ngram","description","category","tags"] } } ], } }, "size":20 } 発見とナビゲーション AnyCompany では、顧客は特定のアイテムを検索するのではなく、インタラクティブなインターフェースを通じて製品を発見したいと考えています。例えば、持続可能なファッションを閲覧している顧客は、「Men’s Wear」の検索から始めて、利用可能な製品の全体像を理解したいと考えるかもしれません。彼らは、利用可能なカテゴリ、持続可能なオプションを提供するブランド、一般的な価格帯、製品評価を確認したいと考えています。集計されたデータは通常、サイドバーにフィルタリングオプションとして表示され、顧客が直感的に検索結果を絞り込むことができます。 OpenSearch 集計 を使用すると、データを分析し、そこから統計を抽出できます。メトリクス集計を適用して簡単な計算を実行したり、バケット集計を使用してドキュメントのセットをバケットとして分類したり、パイプライン集計を使用して複数の集計を連鎖させたりできます。 以下は、この機能を実装するクエリの例です： GET products/_search { "query": { "bool":{ "should": [ { "multi_match": { "query": "Men's Wear", "fields": ["name.ngram","description","category","tags"] } } ] } }, "aggs": { "categories": {"terms":{"field":"category.keyword","size":10}}, "brands":{"terms":{"field":"brand.keyword","size":10}}, "colors":{"terms":{"field":"specs.color","size":10}}, "sizes":{"terms":{"field":"specs.size","size":10}}, "size":20 } あいまい検索と提案 AnyCompany では、顧客は不完全な記憶で製品を検索することが多く、タイプミスをしながらも、意図を予測できるリアルタイムの検索提案を期待しています。例えば、「Omga」と入力すると、タイプミスを許容し、「OmegaWear」や「Omega Eco Essentials」などの関連製品を提案する必要があります。これには、スペルのバリエーションやタイプミスを処理しながら、ショッピング体験を向上させる検索提案を提供する堅牢な検索システムが必要です。OpenSearch では、キーストロークごとに更新され、関連する提案を提供し、タイプミスを許容するオートコンプリート機能を設計できます。 以下は、この機能を実装するクエリの例です： GET products/_search { "suggest": { "product_suggest": { "prefix": "Om", }, "size": 5 } } } } セマンティック検索 AnyCompany では、顧客は特定の製品名やカテゴリではなく、「red beach hat for summer」のような自然なフレーズを使用して製品のニーズを表現することがよくあります。この直感的な検索方法には、キーワードの一致だけでなく、顧客のクエリの背後にあるセマンティックな意味を理解するシステムが必要です。 OpenSearch は、 ベクトル検索 を通じてこの自然な検索体験を可能にします。システムは、顧客のクエリをベクトル埋め込み（テキストのセマンティックな意味を捉える数値表現）に変換します。これにより、正確なキーワード一致ではなく、概念的な類似性に基づいて一致させることができます。 以下は、この機能を実装するクエリの例です： GET /products/_search { "query": { }, "aggs": { "categories": { "terms": { "field": "category" }}, "brands": { "terms": { "field": "brand" }}, "avg_rating": { "avg": { "field": "rating" }} }, "size": 20 } 以下のセクションでは、既存の Amazon DynamoDB 操作を維持しながら、検索機能をサポートするソリューションを実装する方法を示します。 ソリューションの概要 以下の図は、ソリューションアーキテクチャを示しています。 AnyCompany の既存のアーキテクチャは、 Amazon API Gateway が顧客のリクエストを AWS Lambda 関数にルーティングするサーバーレスパターンに従っています。この関数は、プライマリデータストアとして機能する DynamoDB テーブルに対して読み取りおよび書き込み操作を実行します。 既存のアーキテクチャを補完するために、AnyCompany は DynamoDB と OpenSearch Service 間のゼロ ETL 統合を実装します。統合は 2 つのフェーズでデータを同期します： ポイントインタイムリカバリ（PITR） は既存の DynamoDB データを Amazon S3 にエクスポートして初期スナップショットを作成し、 DynamoDB Streams は継続的な変更をキャプチャして OpenSearch サービスにほぼリアルタイムで更新します。 セマンティック検索に必要な リモート推論 を有効にするために、 OpenSearch ML コネクタ を使用して OpenSearch を Amazon Bedrock の Titan テキスト埋め込み モデルに接続できます。 OpenSearch Ingestion パイプラインはこれらのストリームを消費し、必要に応じてデータを変換し、ほぼリアルタイムで OpenSearch Service に同期します。同期エラーをキャプチャするために、デッドレターキュー（DLQ）として Amazon Simple Storage Service （Amazon S3）バケットを指定します。 検索機能をサポートするために、ソリューションは OpenSearch Service を使用して検索リクエストを処理する新しい Lambda 関数を追加します。この関数は OpenSearch Service SDK を使用してクライアントを作成し、検索クエリを実行します。この新しい関数は、既存の操作を処理し続ける既存の書き込み Lambda 関数と並行して動作します。 この設計により、AnyCompany は e コマースワークロードを維持しながら、堅牢な検索機能を実装できます。 Amazon DynamoDB と Amazon OpenSearch Service 間のゼロ ETL 統合の実装 このセクションでは、強化された検索機能のためのセマンティック検索機能を含む、DynamoDB と OpenSearch Service 間のゼロ ETL 統合をセットアップする方法を示します。 前提条件 このソリューションをセットアップするには、以下が必要です： AWS アカウント 。 以下の AWS リソースを作成および管理するための適切な AWS Identity & Access Management （IAM）権限： DynamoDB テーブル。 OpenSearch ドメイン 。 Amazon OpenSearch Ingestion（OSIS）パイプライン。 CloudFormation テンプレート 。 DynamoDB エクスポートおよび DLQ イベント用の Amazon S3 汎用バケット。 Amazon Titan Embeddings G1 が有効になっている Amazon Bedrock。詳細については、 Amazon Bedrock 基盤モデルへのアクセス を参照してください。 実装手順 ステップ 1：DynamoDB テーブルの作成 ソリューションのウォークスルーの目的で、「Products」という名前の新しい DynamoDB テーブルを作成します。既存の DynamoDB テーブルでこのソリューションを実装する場合は、このステップをスキップできます。以下の AWS CLI コマンドを実行してテーブルを作成します： aws dynamodb create-table \ --table-name Products \ --attribute-definitions \ AttributeName=product_id,AttributeType=S \ --key-schema \ AttributeName=product_id,KeyType=HASH \ --billing-mode PAY_PER_REQUEST \ --region us-east-1 テーブルのステータスが CREATING から ACTIVE に変わるまで待ちます。ステータスは以下で確認できます： aws dynamodb describe-table \ --table-name Products \ --region us-east-1 \ --query 'Table.TableStatus' ステップ 2：DynamoDB Streams とポイントインタイムリカバリ（PITR）の有効化 以下の AWS CLI コマンドを実行します： aws dynamodb update-table \ --table-name Products \ --stream-specification \ StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region us-east-1 aws dynamodb update-continuous-backups \ --table-name Products \ --point-in-time-recovery-specification \ PointInTimeRecoveryEnabled=true \ --region us-east-1 ステップ 3：OpenSearch ドメインの作成 以下の AWS CLI コマンドを実行してドメインを作成します： aws opensearch create-domain \ --domain-name demo \ --engine-version "OpenSearch_3.1" \ --cluster-config InstanceType=t3.small.search,InstanceCount=1 \ --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=10 \ --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:YOUR_ACCOUNT_ID :domain/demo/*"}]}' \ --advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"admin","MasterUserPassword": "YourStrongPassword123!"}}' \ --node-to-node-encryption-options Enabled=true \ --encryption-at-rest-options Enabled=true \ --domain-endpoint-options EnforceHTTPS=true \ --region us-east-1 注意： YOUR_ACCOUNT_ID を実際の AWS アカウント ID に置き換えてください YourStrongPassword123! を強力なパスワードに置き換えてください（OpenSearch Dashboards へのログインに使用するため保存してください） ドメインのステータスを確認： aws opensearch describe-domain \ --domain-name demo \ --region us-east-1 \ --query 'DomainStatus.{Status:Processing,Endpoint:Endpoint }' Processing フィールドが Status false を返すまで待ちます。これはドメインがアクティブであることを示します。アクティブになったら、Endpoint（API アクセス用）をメモし、作成したマスターユーザー名とパスワードを使用して OpenSearch Dashboards URL（通常は https:///_dashboards/）に移動します。 ステップ 4：OpenSearch セキュリティ設定の構成 OpenSearch Service ドメインの OpenSearch Dashboards プラグインに移動します。Dashboards エンドポイントは、 OpenSearch Service コンソール のドメインダッシュボードで確認できます。 メインメニューから Security 、 Roles を選択し、 ml_full_access ロールを選択します。 Mapped users 、 Manage mapping を選択します。 Backend roles の下に、ドメインを呼び出す権限が必要な Lambda ロールの ARN を追加します。 arn:aws:iam:::role/LambdaInvokeOpenSearchMLCommonsRole Map を選択し、ユーザーまたはロールが Mapped users の下に表示されることを確認します。 このマッピングにより、モデル統合に必要な権限が有効になります。このロールは、モデル ID を登録する次のステップで作成されます。 図 2：OpenSearch セキュリティ設定 ステップ 5：Bedrock モデル統合のセットアップ リモート推論を使用すると、Amazon SageMaker AI や Amazon Bedrock などの ML サービスでモデル推論をリモートでホストし、ML コネクタを使用して Amazon OpenSearch Service に接続できます。 リモート推論のセットアップを容易にするために、Amazon OpenSearch Service はコンソールで AWS CloudFormation テンプレートを提供します。 Amazon OpenSearch Service コンソール を開きます。 左側のナビゲーションペインで、 Integrations を選択します。 Integrate with Amazon Titan Text Embeddings model through Amazon Bedrock を選択します Configure domain 、 Configure public domain を選択します。 「Amazon OpenSearch Endpoint」と「Model region」のパラメータ値を入力します。 「 I acknowledge that AWS CloudFormation might create IAM resources 」をチェックします Create stack を選択します スタックのデプロイが正常に完了したら、Outputs タブに移動し、 Model Id をメモします。 図 3：Bedrock モデル統合 ステップ 6：OpenSearch Ingest パイプラインのセットアップ Amazon Bedrock のモデルを使用して入力フィールド description から埋め込みを作成し、 description_embedding という名前のフィールドにマッピングする インジェストパイプライン を作成します。 ドメインの OpenSearch Dashboards URL に移動します。URL は OpenSearch Service コンソール のドメインダッシュボードで確認できます。 左側のナビゲーションパネルを開き、 DevTools を選択します。 埋め込みパイプラインを作成します： PUT /_ingest/pipeline/bedrock-embedding-pipeline { "description": "A text embedding pipeline", "processors": [ { "text_embedding": { "model_id": "<your_model_id>", // 前のステップの ModelId に置き換えます。 "field_map": { "description": "description_embedding" }, "skip_existing": true } } ] } 図 4：OpenSearch Ingest パイプラインの作成 ステップ 7：OpenSearch インデックステンプレートの準備 ユースケースのゼロ ETL 統合パイプラインをセットアップする前に、検索要件を分析し、最適なパフォーマンスのための適切なインデックステンプレートを設計します。 以下のガイドラインを検討してください： アクセスパターンを分析し、検索可能にする必要があるフィールドを決定し、適切なフィールドタイプを選択します。 product_id や category のような正確な一致には keyword を使用します。 全文検索機能には、アナライザー付きの text を使用します。 タイムスタンプフィールドには date を使用します。 フィールド選択を最適化するために、処理オーバーヘッドを削減するために必要なフィールドのみをインデックス化します。 特殊な検索ニーズに対してカスタムアナライザーを実装します。例えば、オートコンプリート機能には n-gram アナライザーを使用し、部分一致を可能にします。 セマンティック検索要件を決定します。ビジネスユースケースに適したフィールドを埋め込みます。選択した埋め込みモデルとパフォーマンス要件に基づいて、適切な次元とアルゴリズムでベクトルフィールドマッピングを構成します。 以下は、マッピングテンプレートの例です： { "template": { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1, "knn": true, "knn.algo_param.ef_search": 100, "default_pipeline": "bedrock-embedding-pipeline" }, "analysis": { "analyzer": { "custom_analyzer": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "stop" ] }, "ngram_analyzer": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "ngram_filter" ] } }, "filter": { "ngram_filter": { "type": "ngram", "min_gram": 4, "max_gram": 5 } } } }, "mappings": { "properties": { "product_id": { "type": "keyword" }, "name": { "type": "text", "analyzer": "custom_analyzer", "fields": { "keyword": { "type": "keyword" }, "ngram": { "type": "text", "analyzer": "ngram_analyzer" }, "suggest": { "type": "completion", "analyzer": "simple" } } }, "description": { "type": "text", "analyzer": "custom_analyzer" }, "price": { "type": "float" }, "rating": { "type": "float" }, "category": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "brand": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "tags": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "specs": { "properties": { "color": { "type": "keyword" }, "size": { "type": "keyword" }, "weight": { "type": "float" }, "dimensions": { "type": "keyword" } } }, "stock": { "type": "integer" }, "created_at": { "type": "date" }, "updated_at": { "type": "date" }, "description_embedding": { "type": "knn_vector", "dimension": 1536, "method": { "engine": "faiss", "space_type": "l2", "name": "hnsw", "parameters": { } } } } } } } ステップ 8：OpenSearch Ingestion パイプラインのセットアップ DynamoDB Service コンソール を開き、 Integrations を選択し、統合を作成して Amazon OpenSearch を選択します。 ソース（DynamoDB テーブル）の構成 ドロップダウンから統合のソースとなる DynamoDB テーブルを選択します。 Enable Stream Enable Export を有効にし、S3 Bucket、S3 region を構成します Configure processor （データ変換のためのプロセッサーをセットアップ） Configure sink （OpenSearch ドメイン）： Choose a domain 「Index Name」として「products」と入力します。 Customized Mapping を選択し、ステップ 7 で定義したテンプレートを使用します。 失敗したイベントをオフロードし、分析用にアクセス可能にするために、デッドレターキュー（DLQ）を有効にします。S3 バケット名とリージョンを入力します。 Configure pipeline 一意のパイプライン名を入力します（現在の AWS アカウントの現在のリージョン内で）。 要件に応じてパイプライン容量を構成します。単一の Ingestion OpenSearch Compute Unit（OCU）は、課金可能なコンピューティングおよびメモリユニットを表します。データパイプラインの実行に使用される OCU の数に基づいて時間単位で課金されます。ベースラインとして、1 つの OCU は一般的なワークロードで最大 2 MiB/秒を処理できます。ワークロードに応じて最小および最大 OCU 容量を入力します。 OpenSearch Ingestion は、他のサービスを代理で使用するための権限が必要です。 Create and use a new service role を選択します。 ステップ 4 と同様に、OSIS パイプラインの IAM ロールを OpenSearch all_access ロールのバックエンドロールとしてマッピングします。これにより、データインジェストのための安全できめ細かいアクセス制御が可能になります。 Review and create すべての構成を確認します。 Preview pipeline を選択し、yaml ファイルを確認します。 Create Pipeline を選択してパイプラインを作成します。 図 5：OpenSearch Ingestion パイプラインの作成 検証 ゼロ ETL 統合をセットアップした後、データが複製されていることをテストおよび検証できます。 DynamoDB にサンプルアイテムを作成します。以下は、アイテムを作成するサンプルシェルスクリプトです： #!/bin/bash for i in {1..10}; do colors=("red" "white" "green" "blue" "black") sizes=("XS" "S" "M" "L" "XL") products=("Hoodie" "Jacket" "Pants" "Shorts" "Sweater" "Joggers" "Tank Top" "Polo Shirt" "Vest" "Leggings") categories=("Activewear" "Men's Wear" "Women's Wear" "Loungewear" "Outerwear") brands=("AnyCompany1" " AnyCompany2" " AnyCompany3" " AnyCompany4" " AnyCompany5" " AnyCompany6") features=("Sustainably crafted" "Eco-friendly materials" "Ethically produced" "Premium quality" "Organic materials") color=${colors[$((RANDOM % 5))]} features=${features[$((RANDOM % 5))]} size=${sizes[$((RANDOM % 5))]} category=${categories[$((RANDOM % 5))]} brand=${brands[$((RANDOM % 6))]} product_name=${products[$((i - 1))]} timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ") aws dynamodb put-item \ --table-name Products \ --region us-east-1 \ --item "{ \"product_id\": {\"S\": \"product_$i\"}, \"name\": {\"S\": \"$brand $product_name\"}, \"description\": {\"S\": \"$features $product_name - $category\"}, \"price\": {\"N\": \"$((100 + RANDOM % 400)).99\"}, \"rating\": {\"N\": \"4.$((RANDOM % 10))\"}, \"category\": {\"S\": \"$category\"}, \"brand\": {\"S\": \"$brand\"}, \"tags\": {\"L\": [{\"S\": \"organic\"}, {\"S\": \"sustainable\"}, {\"S\": \"eco-friendly\"}]}, \"specs\": {\"M\": { \"color\": {\"S\": \"$color\"}, \"size\": {\"S\": \"$size\"}, \"weight\": {\"N\": \"0.$((RANDOM % 9 + 1))\"}, \"dimensions\": {\"S\": \"$((RANDOM % 30 + 10))x$((RANDOM % 30 + 10))x$((RANDOM % 10 + 1))\"} }}, \"stock\": {\"N\": \"$((RANDOM % 200))\"}, \"created_at\": {\"S\": \"$timestamp\"}, \"updated_at\": {\"S\": \"$timestamp\"} }" && echo "✓ Created: product_id=$i" done echo "Done!" ドメインの OpenSearch Dashboards URL に移動します。URL は OpenSearch Service コンソールのドメインダッシュボードで確認できます。 左側のナビゲーションパネルを開き、 Dev Tools を選択します。 OpenSearch へのデータフローを確認します。 //すべて検索 GET products/_search { "query": { "match_all": {} } } セマンティックユースケースクエリを実行して、セマンティック要件を検証します。 GET products/_search { "query": { "neural": { "description_embedding": { "query_text": "sports", "model_id": "<ステップ 5 で取得した model_id に更新>" } } } } この記事の前半で提供されたクエリを使用して、他のすべてのユースケースをテストできます。 図 6：データ検証 パイプラインのセットアップを完了し、データ同期を検証した後、トランザクション操作を DynamoDB に保持しながら、検索クエリを OpenSearch Service にルーティングするようにアプリケーションコードをリファクタリングします。 具体的な実装は、アプリケーションアーキテクチャとプログラミング言語によって異なります。AWS SDK を使用して OpenSearch Service をクエリする手順については、 AWS SDK を使用した Amazon OpenSearch Service との対話 を参照してください。 ベストプラクティス DynamoDB と OpenSearch Service 間のゼロ ETL 統合を実装する際は、以下の ベストプラクティス を検討してください： OSIS パイプラインのソースオプションとして DynamoDB ストリームを使用します。これにより、完全な初期スナップショットを必要とせずに、新しいレコードまたは更新されたレコードのみがキャプチャされます。ストリーミングデータでパイプラインフローをテストしたら、エクスポートオプションを使用して完全なデータを移行します。 Amazon VPC を使用して、パブリックインターネット経由ではなく、ネットワーク境界内で OpenSearch Ingestion パイプラインを通じてデータフローを強制します。 埋め込みがすでに含まれているフィールドに対する冗長な API 呼び出しを防ぐために、 skip_existing フラグを有効にして、埋め込み生成インジェストパイプラインを最適化します。 OpenSearch Service ドメインと OpenSearch Ingestion パイプラインの Amazon CloudWatch ログ を有効にします。これにより、データフロー全体の可視性が提供され、問題を迅速に特定できます。ドメインレベルでログを構成して、検索クエリ、インデックス操作、クラスターヘルスメトリクスをキャプチャします。OpenSearch Ingestion パイプラインの場合、詳細なログを有効にして、データ変換とインジェストプロセスを監視します。 インジェストパイプラインの DLQ を構成します。マッピングエラー、変換の問題、または一時的なサービスの問題によりドキュメントの処理が失敗した場合、DLQ はこれらの失敗したレコードをキャプチャして、後で分析および再処理できるようにします。これにより、データ損失が防止され、回復メカニズムが提供されます。 AWS Key Management Service（AWS KMS） を使用して、DynamoDB テーブルと OpenSearch Service ドメインの両方で保存時の暗号化を有効にし、暗号化キーを完全に制御し、コンプライアンス要件を満たします。 DynamoDB テーブルで削除保護を有効にして、重要なデータの誤削除を防ぎ、本番ワークロードに追加の安全層を提供します。 統合パイプラインの各コンポーネントに特定の IAM ロールとポリシーを作成して、最小権限アクセスを実装し、サービスが機能するために必要な権限のみを持つようにします。 シャードサイジング、インスタンスタイプ、デプロイ構成を含む OpenSearch Service ドメインのサイジング推奨事項については、 Amazon OpenSearch Service ドメインサイジングガイド を参照してください。 モニタリングとアラート OpenSearch Ingestion は、パイプラインのパフォーマンスを監視するのに役立つメトリクスを公開します。パイプラインの健全性を監視する際は、以下の主要な領域に焦点を当ててください： データインジェストをブロックする可能性のある認証の問題。 データ損失につながる可能性のあるドキュメント処理の失敗。 データ処理を遅くする可能性のある容量のボトルネック。 アプリケーションの応答時間に影響を与えるパフォーマンスの低下。 Bedrock 固有の監視については、モデル呼び出しのレイテンシー、スロットリング、トークン使用量のメトリクスに特に注意してください。 これらの領域を積極的に監視することで、DynamoDB から OpenSearch Service への信頼性の高いデータフローを維持し、検索機能の応答性を確保できます。これらの問題を早期に検出するために CloudWatch アラートを設定し、ユーザーに影響を与える前にプロアクティブなアクションを実行できるようにします。 ログとモニタリング の詳細とベストプラクティスについては、 Amazon OpenSearch Ingestion のベストプラクティス および Amazon Bedrock モニタリング のドキュメントを参照してください。 コストに関する考慮事項 OpenSearch Ingestion を使用した DynamoDB から OpenSearch Service への統合を計画する際は、Amazon CloudWatch メトリクスを通じて DynamoDB の書き込みスループットを分析します。DynamoDB テーブルの書き込みアクティビティは DynamoDB Streams にレコードを生成し、OpenSearch Ingestion パイプラインがそれを消費します。最小、最大、平均の書き込みリクエストユニット（WRU）を理解することで、OpenSearch Ingestion パイプラインを適切にサイジングできます。この記事の執筆時点では、OpenSearch Ingestion パイプラインは 1 から 96 の OpenSearch Compute Unit（OCU）にスケーリングできます。ベースラインとして、1 つの OCU は一般的なワークロードで最大 2 MiB/秒を処理できますが、データサイズ、パイプライン変換、OpenSearch Service ドメインのサイズとインデックス/シャード戦略によって異なる場合があります。 例えば、テーブルが 1 秒あたり 20,000 WRU を処理する場合、このスループットを効率的に処理するには最低 10 OCU が必要です。総コストには、DynamoDB Streams の料金（100,000 読み取りリクエストあたり $0.02）、OpenSearch Service クラスターのコスト（インスタンスタイプとストレージに基づく）、OpenSearch Ingestion パイプラインのコスト（OCU 時間あたりの価格）、および通常の DynamoDB コストが含まれます。DynamoDB から OpenSearch パイプラインにリモート推論用の Amazon Bedrock を組み込む場合は、どのフィールドに埋め込みが必要かを評価し、処理するテキストデータの量を見積もります。レコード数、テキストフィールドのサイズ、更新頻度に基づいて、予想されるトークン使用量を計算します。コスト構造は、選択した基盤モデルによって異なるトークンごとの従量課金モデルに従います。 クリーンアップ 継続的な料金の発生を避けるために、このソリューションで作成したリソースを削除または無効化します。AWS 環境をクリーンアップするには、次の手順に従ってください： CloudFormation スタック を削除します： CloudFormation コンソールを開きます。 モデルアクセス用に作成したスタックを選択します。 Delete を選択し、削除を確認します。 OpenSearch リソースを削除します： Amazon OpenSearch Ingestion コンソールを開き、パイプラインを削除して OSIS パイプラインを削除 します。 Amazon OpenSearch Service コンソールを通じて OpenSearch ドメインを削除 します。 DynamoDB テーブル（Products）を削除します。 デッドレターキュー（DLQ）と DynamoDB エクスポートに使用した S3 バケットを空にします。 これらの手順を完了したら、各サービスコンソールで、すべてのリソースが適切に削除または無効化されていることを確認してください。 まとめ この記事では、 Amazon DynamoDB データに対する検索を Amazon OpenSearch Service との ゼロ ETL 統合を使用して実装する方法を紹介しました。 AnyCompany の例を通じて、この統合が実際の検索課題（顧客のタイプミスやセマンティッククエリの処理から、ファセット検索やマルチフィールド検索の有効化まで）にどのように対処するかを実証しました。 Amazon OpenSearch Service ドキュメント と DynamoDB ゼロ ETL 統合ガイド を探索して、独自の環境でこれらの機能の実装を開始してください。 本記事は 2026 年 02 月 18 日 に公開された “Implementing search on Amazon DynamoDB data using zero-ETL integration with Amazon OpenSearch service” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/implementing-search-on-amazon-dynamodb-data-using-zero-etl-integration-with-amazon-opensearch-service/ 著者について Varun Sharma Varun は、AWS Professional Services チームで働くシニアデリバリーコンサルタントです。 Vamsi Krishna Ganti Vamsi は、AWS Professional Services チームで働くシニアデリバリーコンサルタントです。 Sudhansu Mohapatra Sudhansu は、AWS Professional Services チームで働くデリバリーコンサルタントです。

2021 年に AWS に入社して以来、私は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスファミリーが成長するのを見てきました。そのペースは今でも驚きを隠せません。AWS Graviton 搭載のインスタンスから、特殊な高速コンピューティングオプションまで、パフォーマンスの限界をさらに押し上げる新しいインスタンスタイプが数か月ごとにリリースされているように感じられます。2026 年 2 月の時点で、AWS は 1,160 を超える Amazon EC2 インスタンスタイプを提供しており、その数は今も増え続けています。 2026 年 2 月 16 日週最初のニュースである Amazon EC2 M8azn インスタンスの一般提供はその良い例です。M8azn インスタンスは、第 5 世代 AMD EPYC プロセッサを搭載した高周波で高ネットワークの汎用インスタンスであり、クラウド内で最も高い 5 GHz の最大 CPU 周波数を提供しています。前世代の M5zn インスタンスと比較した場合、M8azn インスタンスは最大 2 倍優れたコンピューティングパフォーマンス、4.3 倍広いメモリ帯域幅、10 倍大きい L3 キャッシュを提供します。また、M5zn より最大 2 倍のネットワークスループット、最大 3 倍の Amazon Elastic Block Store (Amazon EBS) スループットも提供します。 第 6 世代の Nitro Card を使用して AWS Nitro System 上に構築された M8azn インスタンスは、自動車、航空宇宙、エネルギー、電気通信分野におけるリアルタイム財務分析、ハイパフォーマンスコンピューティング、高頻度取引、CI/CD パイプライン、ゲーム、シミュレーションモデリングなどのワークロード向けです。このインスタンスでは、メモリと vCPU の比率が 4:1 になっており、2 個から 96 個の vCPU 数、最大 384 GiB のメモリを搭載した 9 種類のサイズ (2 種類のベアメタルタイプを含む) で利用できます。詳細については、 Amazon EC2 M8azn インスタンスページ をご覧ください。 2026 年 2 月 9 日週のリリース 以下は、2026 年 2 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock が 6 つのフルマネージドオープンウェイトモデルのサポートを追加 – Amazon Bedrock が、DeepSeek V3.2、MiniMax M2.1、GLM 4.7、GLM 4.7 Flash、Kimi K2.5、Qwen3 Coder Next のサポートを開始しました。これらのモデルは、フロンティア推論とエージェンティックコーディングのワークロードに対応します。DeepSeek V3.2 と Kimi K2.5 は推論とエージェンティックインテリジェンスを対象としており、GLM 4.7 と MiniMax M2.1 は大規模な出力ウィンドウでの自律コーディングをサポートし、Qwen3 Coder Next と GLM 4.7 Flash は本番環境デプロイ用のコスト効率に優れた代替手段を提供します。Project Mantle を活用するこれらのモデルは、OpenAI API 仕様との設定不要の互換性を提供します。 このリリースにより、仕様主導型の AI 開発ツールである Kiro での DeepSeek v3.2、MiniMax 2.1、Qwen3 Coder Next といった新しいオープンウェイトモデルの使用も可能になります。 Amazon Bedrock が AWS PrivateLink のサポートを拡大 – Amazon Bedrock が、 bedrock-runtime エンドポイントの既存サポートに加えて、 bedrock-mantle エンドポイントでも AWS PrivateLink をサポートするようになりました。bedrock-mantle エンドポイントは、Amazon Bedrock で提供される大規模な機械学習モデル用の分散型推論エンジンである Project Mantle を活用しています。Project Mantle は、サービス品質制御を備えたサーバーレス推論、自動化されたキャパシティ管理によって引き上げられたデフォルトカスタマークォータ、OpenAI API 仕様との設定不要の互換性を提供します。OpenAI API 互換エンドポイントの AWS PrivateLink サポートは、14 の AWS リージョンでご利用いただけます。使用を開始するには、Amazon Bedrock コンソールにアクセスするか、OpenAI API 互換性ドキュメントを参照してください。 Amazon EKS Auto Mode がマネージド Kubernetes 機能のための強化されたロギング機能を発表 – Amazon EKS Auto Mode で Amazon CloudWatch Vended Logs を使用するログ配信ソースを設定できるようになりました。これは、Auto Mode のマネージド Kubernetes 機能からコンピューティングの自動スケーリング、ブロックストレージ、負荷分散、ポッドネットワーキングに関するログを収集するために役立ちます。各 Auto Mode 機能は、AWS 認証と承認が組み込まれた CloudWatch Vended Logs 配信ソースとして、標準の CloudWatch Logs よりも低い料金で設定できます。ログは、CloudWatch Logs、Amazon S3、または Amazon Data Firehose を宛先として配信できます。この機能は、EKS Auto Mode が提供されているすべてのリージョンでご利用いただけます。 Amazon OpenSearch Serverless がコレクショングループのサポートを開始 – 新しいコレクショングループを使用して、異なる AWS Key Management Service (AWS KMS) キーを持つコレクションの全体で OCU (OpenSearch Compute Unit) を共有できるようになりました。コレクショングループは、コレクションレベルのセキュリティとアクセス制御を維持しながら、共有コンピューティングモデルを通じて全体的な OCU コストを削減します。また、最大 OCU 制限に加えて最小 OCU 割り当てを指定することも可能になったため、遅延の影響を受けやすいアプリケーションの起動時におけるベースラインキャパシティが保証されます。コレクショングループは、現在 Amazon OpenSearch Serverless が提供されているすべてのリージョンでご利用いただけます。 Amazon RDS がスナップショットの復元時におけるバックアップ設定のサポートを開始 – スナップショット復元操作の実行前と実行中にバックアップ保持期間と希望するバックアップウィンドウを表示し、変更できるようになりました。これまで、復元されたデータベースインスタンスとクラスターはスナップショットメタデータからのバックアップパラメータ値を継承し、変更できるのは復元完了後のみでした。これからは、自動バックアップとスナップショットの一部としてバックアップ設定を表示し、復元時にこれらの値を指定または変更できるようになるため、復元後に変更する必要がなくなります。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンにあるすべての Amazon RDS データベースエンジン (MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2) と Amazon Aurora (MySQL 互換および PostgreSQL 互換エディション) で利用でき、追加料金はかかりません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS AI and Data Conference 2026 – 3 月 12 日にアイルランドの Lyrath Convention Centre で開催される、1 日限りの無料対面イベントです。このカンファレンスでは、Amazon Bedrock、Amazon SageMaker、QuickSight を用いたエージェントの設計、トレーニング、およびデプロイの他、エージェントの AWS データサービスとの統合、エージェントを大規模に運用するためのガバナンスプラクティスの適用といったトピックを取り上げます。アジェンダには、アーキテクト、開発者、ビジネスリーダー向けの戦略的ガイダンスとハンズオンラボが含まれています。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。このイベントは、 アーメダバード (2 月 28 日)、 スロバキア (3 月 11 日)、 プネー (3 月 21 日) で開催される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧ください。 2026 年 2 月 16 日週のニュースは以上です。2026 年 2 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

ウェブサイトのパフォーマンス問題はよくあることですが、根本原因の特定は困難な作業となります。この投稿では、 Server-Timing ヘッダー の潜在能力を引き出すことで、パフォーマンスに関するトラブルシューティングのプロセスをシンプルにする方法を学びます。 Server-Timing ヘッダーは、バックエンドのコンポーネントがユーザーリクエストへのレスポンスにおいて、タイミングメトリクスやパフォーマンスモニタリングに関するインサイトを伝達できるようにします。 ウェブサイトのアクセスでは、画像変換などのコンテンツ最適化やデータベースからの動的なデータ取得を含んだ、複雑なサーバーサイドのプロセスが関与しています。遅いリクエストの原因となるサーバーやプロセスを特定するには、複数のログを突き合わせて分析する必要があり、時間がかかってしまいます。このプロセスをシンプルにすることで迅速に問題を解決できます。具体的には、ユーザー体験の品質シグナルとサーバーサイドのパフォーマンス指標とを直接関連付けて、単一のログ行内にカプセル化することで実現します。この方法は、広範なデータクエリや相関分析が不要であり、パフォーマンス問題を素早く特定し、原因となるサーバーコンポーネントまで追跡することを可能にします。このアプローチの実例として Common Media Client Data（CMCD） が挙げられます。 CMCD は動画ストリーミング業界で最近生まれた革新的な技術で、クライアントおよびサーバー両方のオブサーバビリティデータを単一のリクエストログ行にシームレスに統合するものです。ウェブサイトにおいては、 Server-Timing ヘッダーを実装することで同様の方式を採用できます。サーバーサイドのメトリクスとクライアントサイドで利用可能なメトリクスとを効果的に統合し、特定のリクエスト-レスポンスサイクルのパフォーマンスを包括的に把握するのです。 私たちが提案するソリューションは 2 つのパートで構成されます。第一に、エンドユーザーのレイテンシを測定してパフォーマンス問題を特定すること、第二に、そうした問題が発生した際にサーバーのインサイトに即座にアクセスすることです。 まず前者を取り上げてから、 Server-Timing の実装について掘り下げていきましょう。 パフォーマンス問題の検出 ウェブサイトのパフォーマンスはレイテンシに大きく依存します。レイテンシとは、ユーザーアクション（リンクのクリックやフォームの送信など）とサーバーからのレスポンスとの間の時間遅延を指します。ウェブサイトにおけるレイテンシは、通常 Time to First Byte （ TTFB ）、別名 First Byte Latency （ FBL ）の形式で測定されます。これは、ウェブサイトのコンテンツがユーザーの画面に描画され始めるまでの速さを測定したもので、 First Contentful Paint （ FCP ）や Largest Contentful Paint （ LCP ）などの Core Web Vitals シグナルに直接影響します。シームレスなユーザー体験を確保するには、 TTFB を 800 ミリ秒以下に維持することが 推奨されています 。このベンチマークは、遅いリクエストを特定するための有用な閾値として機能します。 Amazon CloudFront のようなサービスを活用することで、静的および 動的コンテンツ 両方の TTFB の改善に役立ちます。 クライアントサイドの視点で TTFB を測定する際は、ユーザーのリクエスト開始時点から、サーバーからのレスポンスの最初のバイト受信時点までの時間を対象範囲とします。この計算には、ネットワーク伝送時間やサーバーサイドでのすべての処理時間が含まれており、ウェブサイトのアーキテクチャに応じて、コンテンツ配信ネットワーク（ CDN ）の処理、オリジンサーバーの処理、データベースのクエリ、およびその他のリクエスト処理タスクなどが含まれます。サーバーサイドの視点で TTFB を測定する場合は、 サーバーがリクエストを受信してから、レスポンスの最初のバイトをネットワーク層に送出する時点までの時間を対象範囲とします。このとき、ネットワーク転送時間は含まれず、 TTFB はレスポンスを開始する前のサーバーの処理時間を本質的に示します。さらに、リクエストフローの途中にサーバーが位置するシナリオでは、サーバーは二重の役割を果たします。一つはダウンストリームからのリクエストを受信するサーバーとして、もう一つはアップストリームの他のサーバーにリクエストを転送するクライアントとして機能するのです。この動作モデルは、 Amazon CloudFront のような CDN 内のサーバーにおいて一般的であり、そのようなサーバーではクライアントサイドとサーバーサイドの両方の TTFB メトリクスが存在することになります。 CloudFront とエッジ関数、 Application Load Balancer 、ウェブサーバー、データベースなどのコンポーネントを含む典型的なウェブサイトアーキテクチャでは、リクエストからレスポンスまでのサイクルは図 1 に示すように進行します。 図 1. 典型的なウェブサイトアーキテクチャにおけるリクエスト-レスポンスサイクルのタイミング 図 1 では、リクエストとレスポンスの開始と終了のそれぞれのタイムスタンプを T を用いて表しています。これらのタイムスタンプを使用して、様々な TTFB を以下のように計算します： ユーザー TTFB は T1 から T18 までの時間間隔です。ユーザーエクスペリエンスをモニタリングし、推奨値を超えた時の問題特定をするために測定すべき指標です。ユーザー TTFB が短いほど、レスポンスが速く、良いユーザーエクスペリエンスであることを示しています。 CloudFront ダウンストリーム TTFB は T2 から T17 までの時間間隔です。キャッシュヒット、つまり、オリジンでの処理を必要とせず CloudFront キャッシュからリクエストが処理される場合には、 TTFB は CloudFront がリクエストを処理してレスポンスを準備するのにかかった時間のみを示します。エッジ関数を使用するのであれば、その実行時間も含まれます。ただし、キャッシュミスの場合には、オリジンがリクエストを処理してレスポンスを準備するまでにかかった時間と、オリジンから CloudFront へレスポンスを転送する時間が追加されます。 CloudFront アップストリーム TTFB は T3 から T14 までの時間間隔です。これは、CloudFront がリクエストをオリジンに送信し、レスポンスを受信するまでのキャッシュミスの場合を表しています。 CloudFront と同様に、オリジン側のシステム内のすべてのサーバーも独自の TTFB を持っています。たとえば、HTML ページを生成するためにデータベースクエリを実行する場合に、T7 から T10 までの時間間隔として、データベース処理時間と伝送時間の両方を測定します。 アップストリームのコンポーネントからダウンストリームへの伝送時間は、ダウンストリーム TTFB からアップストリーム TTFB を引いた値で推定できます。たとえば、CloudFront からユーザーへの最初のバイトの伝送時間は、ユーザー TTFB から CloudFront ダウンストリーム TTFB を引いて計算できます。伝送時間が短いほど、ネットワーク状態が良好で、距離が短いことを示します。 ブラウザ内の JavaScript を使用してユーザー TTFB を測定するには、 Resource Timing API が使用できます。この API では、リクエストの開始時刻、DNS 解決時間、TCP および TLS ハンドシェイク、レスポンスの最初のバイトの受信といったリソースの読み込みに関わるさまざまな段階のタイムスタンプを取得できます。これにより、TTFB の計算やリソースの読み込みに関連するその他の有用なタイミング情報の取得が容易になります。 const timings = {}; new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); entries.forEach(entry => { if (entry.responseStart > 0) { timings.userDNS = (entry.domainLookupEnd - entry.domainLookupStart).toFixed(2); timings.userTCP = (entry.connectEnd - entry.connectStart).toFixed(2); timings.userTLS = (entry.requestStart - entry.secureConnectionStart).toFixed(2); timings.userTTFB = (entry.responseStart - entry.requestStart).toFixed(2); } }); }).observe({ type: 'resource', buffered: true }); このコードスニペットは、ウェブページから読み込まれた各リソースの DNS、TCP、TLS、および TTFB のタイミングを取得しています。同様に、 Navigation Timing API を使用して、ブラウザ内のナビゲーションリクエストに対してこれらのタイミングを取得できます。このデータを使用すると、レイテンシが許容範囲内かどうかを判断できるだけでなく、リクエストの DNS、TCP、TLS 各段階の所要時間を分析することもできます。これらのメトリクスは、パケットが移動することになるユーザーとフロントエンドサーバー間のネットワーク距離や、ネットワークの輻輳状態に影響を受けます。これらの値が大きく、800 ミリ秒のベンチマークに近づいている場合は、よりスムーズなユーザーエクスペリエンスのためにネットワーク状態を改善する必要があることを示しています。 CloudFront は、エッジロケーションでユーザーに近い場所でリクエストを終端することにより、ネットワークパフォーマンスを大幅に向上させることができます。 しかし、サーバーサイドが原因のパフォーマンス問題はこのデータでは可視化できません。そこで Server-Timing が役立ちます。 Server-Timing の実装 あらゆるウェブサーバーでは HTTP レスポンスに Server-Timing ヘッダーを含めることができ、サーバーメトリクスを提供します。このヘッダーはすべてのモダンブラウザでサポートされており、 PerformanceServerTiming インターフェースを使用してメトリクスを簡単に解析および取得できます。 CloudFront はすでに Server-Timing をサポートしており、処理に関連するメトリクスを伝達できます。たとえば、cdn-downstream-fbl メトリクスは前述した CloudFront ダウンストリーム TTFB であり、 cdn-upstream-fbl は CloudFront アップストリーム TTFB です。その他の利用可能なメトリクスとその説明については、 開発者ガイド で確認できます。 CloudFront で Server-Timing を有効化するには、 レスポンスヘッダーポリシー を作成します。 Server-Timing ヘッダーパネルの「有効」オプションを切り替え、サンプリングレートを指定します。他のレスポンスヘッダーの追加または削除も必要に応じて設定します。CloudFront の Server-Timing 機能により、CloudFront がリクエストを十分な速さで処理できているかを評価できます。キャッシュヒットの場合、 cdn-downstream-fbl メトリクスの値は小さくなり、これは CloudFront が迅速にレスポンスを開始したことを示します。逆に、このメトリクスの値が大きい場合は、処理が遅いことを示唆し、CloudFront 側に問題があることを示します。キャッシュミスの場合には、 cdn-upstream-connect と cdn-upstream-dns メトリクスを確認して CloudFront からオリジンへの接続時間の値も評価します。これらのメトリクスの値が小さい場合は、リクエストフローにおける次のサーバー（図 1 に示されている Application Load Balancer など）が正常に稼働しており、接続を素早く確立し、CloudFront のオリジン向けサーバーの近くに配置されていることを示唆しています。たいていの場合、 cdn-upstream-connect や cdn-upstream-dns の値は 0 になります。なぜならば、CloudFront の 持続的接続 機能が以前に確立された接続を再利用しているからです。 cdn-upstream-fbl メトリクスは、オリジンからのレスポンスの最初のバイトが CloudFront に到達する速さを示します。このメトリクスの値が大きく、 cdn-upstream-connect と cdn-upstream-dns の値が小さい場合は、 Application Load Balancer の後段にあるオリジン側のシステムに問題が発生し、速いレスポンスを提供できていないことを示します。理想的には、これらのメトリクスがユーザーの経験するレイテンシ（ユーザー TTFB ）に大きく影響を与えてはいけません。 CloudFront の Server-Timing ヘッダーは、 CloudFront のダウンストリーム・アップストリーム両方のパフォーマンスに関するインサイトを提供しますが、リクエスト中にオリジンで何が起こったかを直接教えてはくれません。複数の異なるコンポーネントやテクノロジーで構成される現代のオリジンアーキテクチャの多様性を鑑みれば、包括的な理解のためには、それぞれのパフォーマンスタイミング情報を組み込むことが不可欠です。オリジンサーバーからインサイトを抽出するには、オリジンからの CloudFront へのレスポンスに Server-Timing ヘッダーを独自に実装して含めることができます。 CloudFront がこのヘッダーを置き換えることはありません。代わりに、オリジンから受信した Server-Timing ヘッダーに CloudFront が自身のメトリクスを追加します。独自で実装する Server-Timing ヘッダーに含めるタイミングメトリクスとしては、画像の最適化、 API 呼び出し、データベースのクエリ、エッジコンピューティングなどの重要なバックエンドプロセスの測定値が考えられます。たとえば、 PHP を使用してデータベースクエリを実行している場合、次のようにしてクエリの所要時間を測定できます。 $dbReadStartTime = hrtime(true); // Database query goes here $dbReadEndTime = hrtime(true); $dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1000000; header('Server-Timing: my-query;dur=' . $dbReadTotalTime); こちらのコードスニペットでは、データベース操作の完了にかかった時間を取得し、 Server-Timing ヘッダー内で my-query メトリクスとして伝達しています。データベースは時に過負荷状態になり、パフォーマンスのボトルネックとなることがあるため、このデータはそのようなシナリオを明らかにするのに役立ちます。 Node.js を使用している場合は、 PerformanceServerTiming インターフェース仕様の 例 を参考にして、 Server-Timing ヘッダーを実装してください。 エッジ関数 によって追加になるレイテンシも Node.js を使用している場合と同様の実装で測定を行います。ネットワーク呼び出しを含んだ複雑な処理を行う Lambda@Edge 関数では特に有益です。以下の例では、オリジンレスポンスイベントにアタッチされた Lambda@Edge 関数で Server-Timing ヘッダーの実装をしています： import json import time # CF headers are available in request object for Lambda@Edge functions attached to origin response event only def lambda_handler(event, context): # Get function's start timestamp handler_start_time = time.time() response = event['Records'][0]['cf']['response'] request = event['Records'][0]['cf']['request'] server_timing_value = [] # List of CloudFront headers to include in server timing for additional inisghts cf_headers = ['cloudfront-viewer-country', 'cloudfront-viewer-city', 'cloudfront-viewer-asn'] # Iterate over each header name and construct the value for the Server-Timing header for header_name in cf_headers: if header_name in request['headers']: header_value = request['headers'][header_name][0]['value'] server_timing_value.append('{}; desc="{}"'.format(header_name, header_value)) # Function's logic goes here # Get function's stop timestamp handler_stop_time = time.time() handler_duration = round((handler_stop_time - handler_start_time) * 1000, 2) server_timing_value.append('{}; dur={}'.format("my-function", handler_duration)) if server_timing_value: # Construct the Server-Timing header server_timing = [{ "key": "Server-Timing", "value": ', '.join(server_timing_value) }] # Add or append the Server-Timing header if 'server-timing' in response['headers']: response['headers']['server-timing'][0]['value'] += ', ' + ', '.join(server_timing_value) else: response['headers']['server-timing'] = server_timing print("Server-Timing:", response['headers']['server-timing']) return response 注目すべき点として、このコードで追加されるメトリクスは、ハンドラーコードの実行時間のみであり、その他の Lambda のタイミングは除外されています。なお、オリジンアーキテクチャの情報が悪意のある攻撃者に悪用されるおそれがあるため、メトリクスには意図的に抽象的な名前を使用しています。 また、ユーザーの地理的位置情報と ASN 番号に関するインサイトを Server-Timing ヘッダーに追加したことにも注目すべき点です。 そして、 クライアントサイドでも Server Timing を取得できるように serverTiming プロパティを使用してコードを拡張します。以下が修正されたコードスニペットとなります。 // Creating a new PerformanceObserver to monitor performance entries new PerformanceObserver((entryList) => { const entries = entryList.getEntries(); for (const entry of entries) { // Object to store timings for various stages const timings = { userDNS: null, // User DNS resolution time userTCP: null, // User TCP handshake time userTLS: null, // User TLS handshake time CFDNS: null, // CDN DNS resolution time CFUpstreamHandshake: null, // CDN upstream TCP handshake time MyQuery: null, // Query time CFUpstreamTTFB: null, // CDN upstream Time To First Byte (TTFB) MyFunction: null, // Function execution time CFDownstreamTTFB: null, // CDN downstream TTFB userTTFB: null, // User Time To First Byte (TTFB) CFRID: null, // CDN Request ID CFCacheStatus: null, // CDN Cache status (Hit or Miss) UserASN: null // User Autonomous System Number (ASN) }; // Iterating through server timing entries for the current performance entry entry.serverTiming.forEach((serverEntry) => { switch (serverEntry.name) { case 'cdn-rid': timings.CFRID = serverEntry.description; break; case 'cdn-cache-miss': timings.CFCacheStatus = "Miss"; break; case 'cdn-cache-hit': timings.CFCacheStatus = "Hit"; break; case 'cdn-upstream-connect': timings.CFUpstreamHandshake = serverEntry.duration; break; case 'cdn-downstream-fbl': timings.CFDownstreamTTFB = serverEntry.duration; break; case 'cdn-upstream-dns': timings.CFDNS = serverEntry.duration; break; case 'cdn-upstream-fbl': timings.CFUpstreamTTFB = serverEntry.duration; break; case 'my-query': timings.MyQuery = serverEntry.duration; break; case 'my-function': timings.MyFunction = serverEntry.duration; break; case 'cloudfront-viewer-asn': timings.UserASN = serverEntry.description; break; } }); // Calculating user-specific timings if the response not served from the local cache if (entry.responseStart > 0) { timings.userDNS = (entry.domainLookupEnd - entry.domainLookupStart).toFixed(2); timings.userTCP = (entry.connectEnd - entry.connectStart).toFixed(2); timings.userTLS = (entry.requestStart - entry.secureConnectionStart).toFixed(2); timings.userTTFB = (entry.responseStart - entry.requestStart).toFixed(2); // Logging metrics for the current entry console.log("Metrics for:", entry.name); console.log("userDNS:", timings.userDNS); console.log("userTCP:", timings.userTCP); console.log("userTLS:", timings.userTLS); console.log("CFDNS:", timings.CFDNS); console.log("CFUpstreamHandshake:", timings.CFUpstreamHandshake); console.log("DBQuery:", timings.MyQuery); console.log("CFUpstreamTTFB:", timings.CFUpstreamTTFB); console.log("lambdaEdge:", timings.MyFunction); console.log("CFDownstreamTTFB:", timings.CFDownstreamTTFB); console.log("userTTFB:", timings.userTTFB); console.log("CFRID:", timings.CFRID); console.log("CFCacheStatus:", timings.CFCacheStatus); console.log("UserASN:", timings.UserASN); console.log("------------------------------------------------------"); } } }).observe({ type: 'resource', // Observing resource-related performance entries buffered: true }); この改良されたコードスニペットでは、Server Timing を取得したのちに、クライアントメトリクスと共に timings オブジェクトに統合しています。これにより、クライアントサイドとサーバーサイドの両方のリクエスト – レスポンスサイクルにおける包括的なパフォーマンスのインサイトを一箇所にまとめることができました。以下は console.log の出力例です。 Metrics for: https://d1234.cloudfront.net/script.php userDNS: 0.00 userTCP: 0.00 userTLS: 5.00 CFDNS: 0 CFUpstreamHandshake: 88 DBQuery: 0.538685 CFUpstreamTTFB: 178 lambdaEdge: 0.09 CFDownstreamTTFB: 229 userTTFB: 233.10 CFRID: mRq-Uvr__3OBDo0IX9ELV5Lrk3lF-bOp4eOIqTEXlFkFn0wIWPKgpA== CFCacheStatus: Miss UserASN: 1257 この例を見てみましょう。 CloudFront の Lambda@Edge 関数の実行と、オリジンサーバーのデータベースクエリの両方を合わせて、最初のバイトをネットワークに送信するまでに 229 ミリ秒かかりました（ CFDownstreamTTFB ）。最初のバイトは 233 ミリ秒後にクライアントデバイスに到達しているので（ userTTFB ）、伝送時間は 4 ミリ秒であることを示しています。クライアントデバイスは、以前に確立された TCP および TLS 接続を再利用しており（ userTCP 、 userTLS ）、 CloudFront の IP アドレスをキャッシュしていました（ userDNS ）。 CloudFront はオリジンに向けて新しい TCP 接続を確立する際（ CFUpstreamHandshake ）、 88 ミリ秒かかりました。オリジンはリクエストを 90 ミリ秒以内（ CFUpstreamTTFB – CFUpstreamHandshake ）で処理しており、素早くレスポンスの最初のバイトを返していることがわかります。結論として、エンドユーザーの全体的なレイテンシは推奨値の 800 ミリ秒を下回っており、満足のいくものであると言えます。 Server-Timing を他のデータで拡充する Server-Timing ヘッダーは、サーバーサイドの処理時間を伝達するために設計されたものですが、その構文は単にその用途に限定されたものではありません。たとえば、CloudFront ではキャッシュのステータスや内部のユニークなリクエスト ID をメトリクスに含んでいます。これらのデータは CloudFront の処理を正確に分析するために不可欠なものです。同様にして、リクエストの経路に関してインサイトを提供するメトリクスを加えて、 Server-Timing ヘッダーを独自に拡充することができます。たとえば、ログを見つけやすくするために、クラスター内のサーバーの内部 ID を追加することもできます。ユーザーの地理的位置情報やデバイスタイプも追加はできますが、 CloudFront のヘッダー の使用で実現できます。先述の Lambda@Edge 関数で使用方法を示した通りです。これらのヘッダーは、オリジンレスポンスイベントに関連付けられた Lambda@Edge 関数、もしくは、ビューワーレスポンスイベントやビューワーリクエストイベントに関連付けられた CloudFront 関数のリクエストオブジェクトで利用できます。オリジンリクエストポリシーでこれらのヘッダーを有効化すると、 オリジンウェブサーバーが CloudFront からのリクエストに含まれるこれらのヘッダーを取り扱えるようになります。こうして、拡充されたメトリクスを Server-Timing ヘッダーに統合するのです。 Amazon CloudWatch で結果を分析する Server-Timing ヘッダーは、パフォーマンス問題を特定し、根本原因を突き止めるのに有用ですが、ウェブサイトパフォーマンスの他の重要な側面に関するインサイトは提供しません。たとえば、JavaScript 実行に関連するエラーや、累積レイアウトシフト（ Cumulative Layout Shift ）などの特定の Web Vitals メトリクスは、このソリューションでは直接キャプチャされません。もしすでにリアルユーザーモニタリング（ RUM ） ベースのウェブサイトモニタリングソリューションを利用しているのであれば、 Server-Timing ヘッダーを統合することで、 既存の手法を置き換えたり、パフォーマンスモニタリングを Server-Timing のみに限定したりするのではなく、既存の手法を補完できます。包括的なウェブサイトモニタリングソリューションの一例として Amazon CloudWatch RUM があります。 CloudWatch RUM のインサイトを前述の手法で拡張するには、 Server-Timing ヘッダーから抽出したメトリクスを取得する カスタムイベント を作成し、 CloudWatch RUM クライアント経由で CloudWatch に送信します。このアプローチにより、すべての CloudWatch RUM のインサイトと Server-Timing を同じサービス内に統合し、両方のデータセットをシームレスに分析できるようになります。 前述のコードスニペットについて、 Server-Timing ヘッダーから抽出したデータとクライアントサイドの測定値を使用して、CloudWatch RUM クライアントを介してカスタムイベントを記録する方法の例を以下に示します： // Sending performance data to a remote server cwr('recordEvent', { type: 'my-server-timing', data: { current_url: entry.name, ...timings // Spread operator to include all timings } }); この例では、 timings オブジェクトのすべてのプロパティと値を、 cwr 関数 に送信される data オブジェクトに含めています。これは、特定のエントリに対してキャプチャされたすべてのタイミングが、 current_url と共に送信されることを意味します。 カスタムイベントは CloudWatch Logs に記録され、CloudWatch Logs Insights を使用してクエリを実行できます。さらに、 メトリクスフィルター を使用して CloudWatch メトリクスを作成して、モニタリング目的のメトリクスアラームを設定することができます。 上記のコードで収集しているタイミングのカスタムメトリクス実装の例を以下に示します： { "event_timestamp": 1710929230000, "event_type": "my-server-timing", "event_id": "9ae82980-4bfb-47f5-8183-b241379e09e1", "event_version": "1.0.0", "log_stream": "2024-03-20T03", "application_id": "c27d1cef-e531-45ad-9bc4-8e03a716c775", "application_version": "1.0.0", "metadata": { "version": "1.0.0", "browserLanguage": "en", "browserName": "Chrome", "browserVersion": "123.0.0.0", "osName": "Mac OS", "osVersion": "10.15.7", "deviceType": "desktop", "platformType": "web", "pageId": "/", "interaction": 0, "title": "TTFB Demo", "domain": "d1234.cloudfront.net", "aws:client": "arw-script", "aws:clientVersion": "1.17.0", "countryCode": "SE", "subdivisionCode": "AB" }, "user_details": { "sessionId": "c9d2514a-8884-4b32-aec0-25203f213f84", "userId": "0f7f2bf3-c9b7-46ab-bc9e-2ff53864ea74" }, "event_details": { "current_url": "https://d1234.cloudfront.net/getmeal.php", "userDNS": "0.00", "userTCP": "0.00", "userTLS": "9.50", "CFDNS": 0, "CFUpstreamHandshake": 90, "MyQuery": 0.517874, "CFUpstreamTTFB": 180, "MyFunction": 0.12, "CFDownstreamTTFB": 233, "userTTFB": "239.30", "CFRID": "ujYncZYVJeIOk6fI7ApFuNt-mJoh8hfL3nZPgAj77z7RdtSzNMTcqQ==", "CFCacheStatus": "Miss", "UserASN": "1257" } } このメトリクスに基づいて、ユーザー TTFB のメトリクス用に以下のフィルターパターンを作成できます: { $.event_details.userTTFB= * && $.event_details.CFCacheStatus= * && $.event_details.UserASN= * && $.metadata.countryCode=*} これにより、国コード、 ASN 番号、 CloudFront キャッシュステータスなどのディメンションを持つユーザー TTFB のメトリクスを作成できます。その後、このメトリクスに対してアラートを作成し、推奨される 800 ミリ秒などの事前定義された静的な閾値を超えた場合に通知を受け取ることができます。また、 CloudWatch 異常検出 を利用することもできます。 最適化とコスト 重要なこととして、Server-Timing ヘッダーがレスポンスサイズを増加させる点を認識してください。これは、 CloudFront のデータ転送アウトに関するコストや、分析システム内でのデータの保存や処理に影響を与える可能性があります。たとえば、前述の Server-Timing ヘッダーの値は約 350 バイトに相当しますが、仮に 100 万リクエストを仮定した場合、追加で 0.325 ギガバイトのデータを転送することになります。ウェブサイトが受信するリクエスト数によっては、これが大きなコストになる場合とならない場合があります。ただし、 Server-Timing に必須情報、特にアクション可能なデータのみを含めることで、このコストを削減できます。たとえば、主にパフォーマンス低下の検出に Server-Timing が必要な場合は、推奨しきい値である 800 ミリ秒を超えるリクエストにのみ追加することを選択できます。さらに、インタラクティブフォームや API 呼び出しなど、ウェブサイト上の重要なリソースの読み込みにのみ適用することで、使用量を最小限に抑えることもできます。これには、クライアントサイドの JavaScript コードで該当するメトリクスに必要なフィルターを実装することで実現できます。 まとめ この投稿では、ウェブサイトパフォーマンスモニタリングにおける TTFB の重要性を探求し、リクエスト-レスポンスサイクルにおいて詳細なインサイトを提供する Server-Timing ヘッダーの活用方法を実証しました。レイテンシの測定とサーバーサイドメトリクス（ CloudFront の処理時間、オリジンサーバーのレスポンス時間など）の取得により、ウェブサイトの所有者はパフォーマンス問題の根本原因を特定し、ウェブサイトの最適化に向けた積極的な対策を講じることができます。 本記事は「 How to identify website performance bottlenecks by measuring time to first byte latency and using Server-Timing header 」と題された記事の翻訳となります。 翻訳はプロフェッショナルサービスの 鈴木（隆） が担当しました。

AI コーディングアシスタントに簡単なこと、例えば関数名の変更やファイルの移動を依頼すると、突然復旧作業に追われることがあります。インポートが壊れたり、参照が存在しないファイルを指したりします。5 分前にコンパイルできていたコードベースが、至る所でエラーを投げ始めます。20 秒で終わるはずのリファクタリングが、5 分間のデバッグとクリーンアップセッションに変わってしまうのです。 エージェントにとってリファクタリングが難しい理由 リファクタリングは単なる大規模な検索置換ではありません。コードベースのセマンティック構造全体にわたるグラフトラバーサル問題なのです。関数名を変更すると、変更は連鎖します。ワークスペース全体のすべての呼び出し箇所、それを参照する型定義とインターフェース、import/export 文、テスト、そして（オプションで）ドキュメントとコメント。ファイルの移動はさらに複雑な波及効果を引き起こし、すべての依存ファイルのインポートパス、バレルファイル（ index.ts ）と再エクスポート、 tsconfig パスやバンドラー設定に組み込まれたモジュール解決の前提、Webpack 設定のような散在する設定ファイルなどに影響します。ここに根本的なミスマッチがあります。LLM はパターンマッチングを通じてもっともらしいコードを生成することに優れていますが、リファクタリングは もっともらしさよりも精度 を要求します。これは創造的なタスクではなく、シンボルの関係、言語固有のセマンティクス、プロジェクトの依存関係グラフの正確な理解を必要とする制約充足問題なのです。「正しく見える」が、深くネストさ れたモジュールの 1 つのインポートを見逃したエージェントは、単に小さなエラーを犯しただけではありません。本番環境まで表面化しないランタイム障害を導入したのです。これが、どれほど洗練されていたとしても、テキスト生成が構造的なコード変換において信頼性に欠けるツールである理由です。 問題：エージェントが効率的ではなく、非効率に動作するとき 多くの AI エージェントがリファクタリングでつまずくのは、 構造的 な編集を テキスト 編集として扱うからです。開発者が直面し続けている失敗モードをいくつか紹介します。 依頼内容： 「このメソッドの名前を変更して」 従来の失敗： エージェントはメソッド定義を更新しましたが、プロジェクト全体の呼び出し箇所を見逃しました。プロンプトで参照を更新するよう明示的に依頼した場合でも、プロセスは遅くエラーが発生しやすいループになりました。古い名前を検索して置換するのです。このプロンプトを考えてみましょう。 expression.js の get_loose_identifier を、それが何をするかをよりよく反映するように名前変更してください。このシンボルの名前変更は 4 つのファイルに伝播し、8 つの参照と 3 つのインポートに影響します。次の図の左側（従来のアプローチ）は、専用のリファクタリングツールなしでこの操作がどのように展開されるかを示しています。最初のファイル（ expression.js ）でシンボルの名前を変更した後、エージェントはコードベースで get_loose_identifier を検索し、複数の LLM 呼び出しとツール呼び出しを通じて CallExpression.js と AssignmentExpression.js を更新します。努力したにもかかわらず、残りの参照を見逃しています。 Kiro の対処法： 開発者が IDE でこのタスクを手動で実行する方法を考えてみましょう。 get_loose_identifier で F2 を押し、新しい名前を入力して、Enter を押します。IDE は、コードベース全体の 8 つの参照と 3 つのインポートすべてを更新しながら、自動的に名前変更を実行します。これがまさにセマンティックリネームツールが行うことです。次の図の右側（新しいアプローチ）は、Kiro が単一のツール呼び出しで名前変更全体を適切に実行する方法を示しています。 依頼内容： 「このファイルの lint エラーを修正して」 従来の失敗： エージェントは linter の出力をテキスト編集の ToDo リストとして扱いました。1 つのファイルでシグネチャの関数名を camelCase から snake_case に変更しましたが、他のファイルで「参照が見つからない」や「インポートが見つからない」エラーを導入しました。すべての使用箇所への変更の伝播に失敗したのです。 Kiro の対処法： ユーザーが直接名前変更を依頼しなくても、エージェントがセマンティックリネームツールから恩恵を受ける例を示します。ユーザーはエージェントに「 text_helpers.py の lint エラーを修正して」と依頼します。lint エラーは、 utils/text_helpers.py 内の normalizeText と slugifyTitle を snake_case に変更する必要があることを示しています。コードベースの部分的なスナップショットを以下に示します。 これらの修正をテキスト編集として扱うエージェントは、関数定義の名前を変更し、ローカル参照を修正するかもしれませんが、他の場所のインポートや呼び出し箇所を見逃す可能性が高く、実行時に ImportError / NameError を引き起こします。セマンティックリネームツールを使用することで、Kiro は定義だけでなく、 api/routes.py と services/indexer.py のインポートと呼び出しも更新します。以下の画像の通りです。 依頼内容： 「コンポーネントを再編成して – Button.tsx を src/components/ から src/shared/ui/ に移動して」 従来の失敗： エージェントはタスクを単純なファイル操作として扱いました。ファイルの移動は成功しましたが、古い場所を指すすべてのインポート文が壊れています。エージェントはその後、検索置換操作でファイルごとにインポートを修正しようとしましたが、動的インポートを見逃しました。 import('../components/Button') 。 Kiro の対処法： Kiro がインポートパスを自動的に更新する具体的な例を示します。図は、プロジェクト構造の部分的なスナップショットと依存するコードスニペットの一部を示しています。 Button.tsx を src/components/ から src/shared/ui/ に移動した後、Kiro は移動したファイルに関連するすべてのインポート文を自動的に更新します。 主な利点： 組み込みの言語サーバーが編集を処理するため、手動の検索置換は不要です。 言語認識：TypeScript/JavaScript モジュール解決を理解します。 より安全：動作するコードを壊す可能性が低くなります。 エッジケースの処理：パスエイリアス、モノレポなどに対応します。 これは、VSCode のエクスプローラーでファイルをドラッグアンドドロップしたときに起こることとまったく同じです。セマンティックリネームツールはエージェントベースの同等機能です！ Kiro エージェントのリファクタリング方法 IDE は、エージェント AI の台頭以前にこの問題をすでに解決していました。VSCode でシンボルの名前を変更するために F2 を押すと、IDE は推測しません。コードの構造を理解する言語サーバーに相談し、ワークスペース全体の編集を計算し、安全に適用します。VSCode のワークスペース編集機能により、単なるテキストパターンではなく、コードの構造を理解するプログラマブルなセマンティック検索置換が可能になります。Kiro エージェントは、LLM 推論だけでリファクタリングをシミュレートしようとはしません。代わりに、エージェントは上記と同じメカニズムを使用して、これらの実証済みの IDE 機能をプログラム的に公開する 2 つの新しいリファクタリングツールを登録します。エージェントがシンボルの名前を変更したりファイルを移動したりする必要がある場合、意図をインテリジェントに認識し、適切なリファクタリングツールを選択して呼び出します。エージェントはリファクタリングワークフローを調整し、IDE の言語サーバーが正確性の検証を支援します。 これらのエージェント登録リファクタリングツールが内部でどのように機能するかを見てみましょう。 セマンティックリネームツール：正しいリネームを実現 このツールは、VSCode のシンボル名前変更 API に直接接続します。F2 を押したときに使用するのと同じものです。 vscode.prepareRename を使用してシンボルが名前変更可能かどうかを検証し（例：キーワードではない）、 vscode.executeDocumentRenameProvider を使用してワークスペース全体で必要なすべての変更を含むワークスペース編集を生成します。TypeScript、JavaScript、TSX、JSX の場合、組み込みの VSCode 名前変更プロバイダーがすべてを処理します。Python、Go、Java などの場合、ツールはインストールされた言語拡張機能とそれらが提供する言語サーバーに依存します。 スマートリロケートツール：すべてを壊さずにファイルを移動 このツールは、VSCode のファイル移動機能を使用して、すべての参照を自動的に更新しながらファイルを再配置します。VSCode のエクスプローラーでドラッグアンドドロップするのと同等のプログラム的な操作ですが、エージェントがあなたのために実行できます。 vscode.WorkspaceEdit.renameFile と vscode.workspace.applyEdit を使用して、ツールは複数のファイルにわたる包括的な変更を生成し、影響を受けるインポートを更新します。 これが重要な理由 創造性よりも精度： リファクタリングは、コードがどのように見えるべきかを LLM に想像させる必要はありません。コードが 実際に何であるか を理解し、外科的に変更できるツールが必要なのです。 実証済みのインフラストラクチャを通じた信頼： これらは実験的な LLM 機能ではなく、開発者が日常的にすでに依存しているリファクタリングインフラストラクチャとの直接統合です。F2 を押したときに機能すれば、エージェントが実行したときにも機能します。 言語に依存しない： 重い作業は言語サーバーによって行われるため、このアプローチは技術スタックと言語全体に一般化されます。 生産性の維持： 20 秒の手動リファクタリングが、5 分間の AI 生成リカバリーミッションになるべきではありません。適切なツールを使用すれば、操作は高速でアトミックなままです。 より大きな視点 構築による正確性という私たちの哲学に基づいて、 IDE 診断統合 を導いたのと同じ原則で、VSCode のリファクタリング機能の全範囲をカバーするようにこのアプローチを拡張しています。エラーが複合する前にキャッチするためにリアルタイム診断を統合したのと同様に、これらの実証済みの決定論的 IDE 機能を、新しい内部スマートリロケートおよびセマンティックリネームツールに拡張しました。 しかし、リファクタリング機能は名前変更と再配置で止まりません。VSCode の言語サーバーは、エージェントが活用すべき豊富な自動コード変換スイートを提供します。コードブロックを再利用可能な関数に抽出するメソッド/関数の抽出、コードを簡素化する変数/関数のインライン化、すべての呼び出し箇所でメソッドパラメータを更新するシグネチャの変更、アロー関数への変換やその他の言語固有の変換は有力な候補です。 このアプローチを取ることで、エージェントが実行される基盤に正確性、セキュリティ、信頼性を組み込むことができます。これらのツールで確立したパターンは、ツールキットへの新しい追加を導きます。LLM に脆弱なテキスト置換スクリプトを生成するよう依頼する代わりに、インテリジェントなコーディングエージェントは、開発者がすでに信頼しているこれらの実証済みの IDE 操作を活用し続けます。IDE が正しく実行する方法を知っているとき、私たちはそれに作業をさせます。エージェントがより有能になるにつれて、これはその出力をより信頼できるものにするための良いテクニックでもあります。 違いを体験する準備はできましたか？ Kiro を無料で始めて 、開発ワークフローをどのように変革できるかを確認してください。 Discord の成長するコミュニティに参加して、フィードバックを共有し、質問をし、AI 支援コーディングで構築している他の開発者とつながりましょう。 謝辞 エンジニアリングの洞察と貴重なフィードバックを提供してくれた Al Harris に感謝します。 本記事は 2026 年 2 月 5 日に公開された Pardis Pashakhanloo と Rajdeep Mukherjee による “ Refactoring made right: how program analysis makes AI agents safe and reliable ” を翻訳したものです。翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2025/11/24 に公開された “ Running NVIDIA Cosmos world foundation models on AWS” を翻訳したものです。 自律走行車、ロボティクス、スマートファクトリー向けのフィジカル AI システムの開発においては、高品質かつ十分なトレーニングデータを生成するということが非常に重要な課題となります。このブログでは、Amazon Web Services (AWS) 上で NVIDIA Cosmos TM ワールドファウンデーションモデル（WFM）をデプロイして、大規模に高品質の合成データを生成する方法を示します。また、異なるユースケースに最適化された 2 つの本番環境向けアーキテクチャを紹介します。 フィジカル AI により、システムは複雑かつ動的な環境で知覚、感知、推論、および自律的な行動ができます。しかし、これらのモデルの事前トレーニングと事後トレーニングには、膨大な量の高品質な実演例が必要です。ビデオからの既存の実演例や、人間が作成する新しい実演例は限られており、十分なデータを提供できません。合成データの生成は、このデータギャップの課題を克服し、フィジカル AI を進化させて、業界全体でビジネスを変革する高度な新しい行動を可能にするために重要です。 Cosmos オープン WFM はこのギャップを埋め、シナリオの合成、ドメインのランダム化、および空間推論を通じて、自律走行車、ヒューマノイドロボット、スマートファクトリー、およびビデオ分析 AI エージェント向けのフィジカル AI の開発を可能にします。Cosmos モデルを最大限に活用するには、慎重に設計され、構成された管理インフラストラクチャが必要です。このインフラストラクチャは、スケーラブルでコスト効率が高い必要があります。 このブログでは、AWS インフラストラクチャ上で Cosmos WFM をデプロイするためのシステムアーキテクチャと実装のベストプラクティスを紹介します。これにより、エンタープライズグレードのスケーラビリティ、セキュリティ、パフォーマンスを実現します。また、コスト効率性、簡単な管理、および再現可能なデプロイメントも提供します。 フィジカル AI データパイプラインの課題 大規模言語モデル（LLM）は、インターネット上の何十年にもわたるデジタル化されたテキスト、書籍、ウェブサイト、ビデオ、会話などの事実上無制限のトレーニングデータを利用しています。この膨大なコーパスにより、モデルはスケールで言語パターン、推論、および知識表現を学習できます。しかし、フィジカル AI システムは根本的に異なる課題に直面しています：「データ不足問題」です。 図 1: フィジカル AI のための合成データ生成の進化 インターネット上のテキストとは異なり、物理的相互作用のデータは不足しています。オブジェクトを操作したり、環境をナビゲートしたり、器用なタスクを実行したりするには、行動をクローンする模倣学習などの現在の技術が必要です。これには、実際の物理的相互作用で取得された現実のセンサーデータ（カメラ映像、力の測定、感覚フィードバックなど）が必要です。このデータを収集するにはコストや時間がかかり、しばしば危険です。 そこで合成データの生成が不可欠になります。Cosmos WFM は物理的に妥当性のあるシナリオを合成します。これには、写実的な光の変化、オブジェクトのテクスチャ、カメラアングル、および動きの軌跡が含まれます。これにより、開発サイクルが加速し、モデルの堅牢性が向上し、フィジカル AI が経済的に実行可能になります。 Cosmos WFM 概要 Cosmos は、WFM を活用してフィジカル AI を進化させるために設計されたプラットフォームです。その中核には、事前トレーニングされたマルチモーダルモデルである Cosmos オープン WFM があり、開発者が世界の状態をビデオとして生成し、フィジカル AI の推論や事後トレーニングを行い、特殊なフィジカル AI モデルを開発できます。Cosmos プラットフォームは 3 つのモデルで構成されています： Cosmos Predict 画像、深度マップ、センサーデータ、テキストプロンプトなどの初期条件から、物理的・時間的に正しい未来の状態を動画で生成するモデルです。 Cosmos Transfer テキストプロンプトと実世界のデータ、シミュレーションから得られた複数の空間制御入力を使用して、フィジカル AI 開発のための物理学を意識した世界状態の映像を生成します。Transfer は、照明、背景、天候、色、テクスチャなどの多様性を追加することで、与えられたデータセットを拡張および増殖させることができます。 Cosmos Reason Cosmos Reason は、物理 AI のためのオープンでカスタマイズ可能な推論ビジョン言語モデル（VLM）です。この VLM により、ロボットやビジョン AI エージェントは、事前知識、物理学、常識を使用して現実世界を理解し、行動できます。このモデルは 物理的 推論 リーダーボード でトップを獲得し、データアノテーションや批評、ロボット計画とトレーニング、業界全体でのビデオ分析 AI エージェントの作成など、さまざまなユースケースに適用できます。Cosmos Reason は、 NVIDIA Blueprint for Video Search and Summarization（VSS） でビデオ分析 AI エージェントの開発に使用されています。 これらのモデルを特定のドメイン向けに構築、カスタマイズ、デプロイするには、開発者は NVIDIA Cosmos Cookbook を活用できます。推論、事後トレーニング、ファインチューニングのためのステップバイステップのワークフロー、技術的なレシピ、具体的な例を提供します。 AWS 上で Cosmos WFM を実行するためのアーキテクチャ AWS は次の 2 つのデプロイメントオプションがあります： – リアルタイム推論： NVIDIA NIM マイクロサービスを Amazon Elastic Kubernetes Service (Amazon EKS) で低遅延のインタラクティブアプリケーション用に使用できます。NVIDIA NIM マイクロサービスは、組織が NVIDIA GPU 上で AI モデルを実行できる一連の高速化されたされた推論マイクロサービスです。 – バッチ推論： コンテナ化されたモデルを AWS Batch で高スループットのオフラインワークロード用に使用できます。 NIM-on-EKS パターンは、常時稼働する GPU 対応 Pods で応答遅延と可用性を優先します。一方、AWS Batch パターンは、ジョブの投入をトリガーとしたコンピューティングプロビジョニングを通じて、コスト効率と弾力的なスループットを最適化します。これらのアーキテクチャを選択する際は、レイテンシー要件、推論量パターン、コスト制約、および物理 AI 開発パイプラインの統合ポイントを考慮する必要があります。 オプション 1：ライブ推論の実行– Amazon EKS 上の Cosmos NIM マイクロサービス Amazon EKS 上の Cosmos NIM マイクロサービスオプションは、エンタープライズグレードのオーケストレーション、自動スケーリング、および簡素化された運用を提供します。これは、高可用性、動的スケーリング、およびクラウドネイティブな統合を必要とする本番環境のデプロイメントに推奨されるアプローチです。Cosmos NIM マイクロサービスは、最適化された推論エンジンを備えた Cosmos モデルをパッケージ化し、手動構成の複雑さを解消します。このパターンのデプロイメントのステップバイステップガイドについては、 “Deploying generative AI applications with NVIDIA NIMs on Amazon EKS” ブログ投稿 を参照してください。 アーキテクチャ図 図 2: Amazon EKS 上での Cosmos NIM マイクロサービスを使用したライブ推論の実行のアーキテクチャ 利点 – エンタープライズグレードのオーケストレーション : Kubernetes は宣言型構成、自動ロールアウトとロールバック、ポッド再起動による自己修復、および手動構成なしのサービスディスカバリーを提供します。 – 高可用性 : マルチポッドデプロイメントにより、単一障害点がなくなります。クロス AZ ノード配置により、アベイラビリティーゾーンの障害を回避できます。ローリングアップデートにより、デプロイメント中のサービス可用性が維持されます。 – 運用の簡素化 : マネージドコントロールプレーンにより、ノードのメンテナンスが不要になります。自動アップグレードにより、クラスターのコンポーネントが最新の状態に保たれます。AWS サービスとの統合により、統一されたモニタリングとセキュリティが提供されます。 オプション 2: バッチ推論の実行 – AWS Batch 上の Cosmos コンテナ AWS Batch は、大規模なバッチコンピューティングワークロードを実行するためのフルマネージドサービスを提供し、オフライン推論シナリオのための Cosmos WFM のデプロイメントに理想的なプラットフォームとなります。このアーキテクチャにより、軌跡データの合成、シーンバリエーション、または環境予測の生成など、大量の物理 AI データを処理できます。常時インフラストラクチャを維持する必要なく、AWS Batch によってオーケストレーションされるコンテナ化された Cosmos モデルを活用します。ジョブキューの需要に基づいて、自動的に最適なコンピュートリソース（GPU 対応 EC2 インスタンス）をプロビジョニングします。また、Amazon S3 または Amazon EFS からの入力データを元に、バッチジョブを開始することができます。これらのジョブは、ビデオ生成、シーン補完、または物理シミュレーションなどの推論タスクを実行します。この結果は、ロボットトレーニングパイプラインや自律システム開発ワークフローといった後段の処理のために EFS に書き戻されます。Amazon CloudWatch との統合は包括的なモニタリングを提供し、AWS IAM ポリシーはモデルアーティファクトとデータリポジトリへの安全な最小特権アクセスを保証します。このパターンのデプロイメントのステップバイステップガイドについては、この ワークショップ を参照してください。 アーキテクチャ図 図 3: AWS Batch で Cosmos コンテナを使用してバッチ推論を実行するためのリファレンスアーキテクチャ 利点 – コスト最適化 : 動的スケーリングにより、AWS Batch は推論ジョブが実行される時のみ GPU コンピュートリソースをプロビジョニングし、完了時にインスタンスを終了します。この従量課金モデルにより、アイドルインフラストラクチャに関連するコストが排除され、特にデータセット拡張や夜間の合成データ生成などの断続的なワークロードに有効です。さらに、スポットインスタンスの活用によってコンピュートコストを削減することも可能です。 – 運用管理の簡素化 : マネージドサービスにより、自動ジョブスケジューリング、リソースプロビジョニング、依存関係管理、再試行ロジックにより、インフラストラクチャの複雑さが軽減され、クラスターの操作ではなくモデルの最適化に集中できます。 – 大規模データ生成のための弾力的なスループット : AWS Batch は、単一ジョブから数千の並列推論タスクまで、フィジカル AI トレーニングのための大規模なデータセットを処理します。この弾力的な演算能力により、価値実現までの時間を加速し、ロボットポリシー開発と自律システム検証における繰り返しを高速化できます。 まとめ AWS で Cosmos WFM を実行すると、大規模な物理 AI 機能を利用できます。このブログでは、異なる組織のニーズと制約に最適化された 2 つの本番環境向けアーキテクチャを紹介しました。 AWS モデルマーケットプレイス上で提供されている Cosmos Reason 推論ビジョン言語モデル を導入し、高度な空間-時間的理解と物理的常識を活用して AI プロジェクトを強化し、よりスマートなロボット計画、ビデオ分析、および最先端の効率性と推論機能を備えた自動データ注釈を可能にするかをご確認ください。 著者注: この技術ガイドは、Cosmos プラットフォームの機能、AWS のベストプラクティス、および大規模モデルデプロイメントの一般原則に基づいています。具体的な実装の詳細は、お客様の要件、最新の NVIDIA NIM マイクロサービスリリース、AWS サービスの更新、および組織のポリシーと制約によって異なる場合があります。最新の情報については、常に NVIDIA と AWS の最新のドキュメントを参照してください。 翻訳は、ソリューションアーキテクトの山本が担当しました。 Abhishek Srivastav Abhishek Srivastav は Amazon Web Services のプリンシパルソリューションアーキテクトで、クラウド採用戦略の加速を通じて顧客の成功を推進しています。AI/ML 技術、ハイパフォーマンスコンピューティング、シミュレーション、物理 AI など、幅広い技術的専門知識を持ち、複雑な企業の課題に対するソリューションの設計を専門としています。現在の役割では、CIO、CTO、その他の技術幹部と協力して、デジタルトランスフォーメーションと生成 AI イニシアチブのロードマップを開発しています。 Brett Hamilton Brett Hamilton は NVIDIA の Developer Relations マネージャーで、フィジカル AI とワールドファウンデーションモデルに取り組んでいます。彼は ISV との協力、新技術の採用拡大、現実世界の課題解決に特化しています。Brett の AI との関わりは 2015 年に B2B チャットボットの開発から始まりました。その後、音声アシスタント、NLP と言語アプリケーション、そしてビジュアル AI にまで及びました。彼は Cisco、AWS、そして NVIDIA で製品リーダーシップ、ビジネス開発、そして開発者関係の役割を担ってきました。 Diego Garzon Diego Garzon は NVIDIA の AI/AV シニアソリューションアーキテクトで、フィジカル AI とシミュレーションに取り組んでいます。以前は Microsoft のプロシージャルコンテンツディレクターとして Xbox Game Studios のプロシージャルグラフィックスをリードしていました。キャリアの初期には、Blizzard Entertainment と Blue Sky Studios で働き、アニー賞にノミネートされました。また、ピクサーの WALL·E にも貢献しました。Diego は SIGGRAPH で流体シミュレーションと水の効果に関する研究を発表しました。また、GDC でグローバルイルミネーションとプロシージャルライティングプローブについて発表しました。さらに、ビジュアルエフェクトソサイエティの理事を務めたこともあります。 Jathavan Sriram Jathavan Sriram は NVIDIA のシニアソリューションアーキテクトで、AI とロボティクスソリューションを専門としています。彼の専門分野はクラウドインフラストラクチャ、Kubernetes、AI 技術で、ワールドファウンデーションモデルとフィジカル AI アプリケーションに注目しています。彼はクラウドネイティブプラットフォーム上で顧客が生成 AI を大規模に展開できるようにすることに情熱を注いでいます。 Shaun Kirby Shaun Kirby は AWS のプリンシパルエンタープライズアーキテクトで、自動車および製造業向けの Internet of Things (IoT) とロボティクスを専門としています。彼は顧客がクラウド技術で卓越するのを助け、ゲームチェンジングなソリューションを先駆けています。AWS に入る前は、Cisco でラピッドプロトタイピングと IoT ショーケースをリードし、大規模システム統合の経験がありました。

本記事は、2026 年 1 月 30 日に公開された BMW Group unlocks insights from petabytes of data with agentic search on AWS を翻訳したものです。 ドイツのミュンヘンに本社を置く BMW Group は、15 か国の 30 か所以上の生産・組立施設で 159,000 人の従業員を雇用しています。BMW Group は自動車イノベーションのリーダーとして、データと人工知能 (AI) を活用し、デジタルトランスフォーメーションの最前線に立ち続けています。2020 年、BMW Group は Cloud Data Hub (CDH) を立ち上げました。現在、これは Data Lakehouse として運用されており、クラウド上で全社的なデータとデータソリューションを管理するための BMW Group の中央プラットフォームとなっています。これにより、全社の従業員に対し、データ駆動型アプリケーションの実装とデータインサイト生成の中心的な基盤を提供しています。 現在、CDH は 20 PB のデータを保存し、1 日平均 110 TB のデータを取り込んでいます。この膨大なデータから洞察を抽出することは、特に技術的および分析的な専門知識を持たないユーザーにとっては困難な場合があります。関連するデータソースを特定し、複雑なクエリを構築し、表形式の出力を解釈する必要があるためです。 本記事では、BMW Group が AWS Professional Services と協力して、 Amazon S3 Vectors 、 Amazon Bedrock 、 Amazon Bedrock AgentCore の機能を組み合わせたエージェンティック検索ソリューションを開発した方法を説明します。このソリューションは、技術スキルに関係なく、BMW Group のユーザーが自然言語を使用して大規模なデータセットから実用的なデータインサイトを抽出できるように設計されています。 課題: データとインサイトのギャップの解消 従来のデータ分析ワークフローは複雑で時間がかかり、企業データから価値ある洞察を迅速に引き出すことを妨げる障壁となっています。プロセスはデータの発見から始まり、ユーザーは適切なデータソースを見つけるために、数十、数百、あるいは数千ものデータアセットを検索する必要があります。次に、ユーザーは SQL クエリを記述して実行する必要があり、複雑な結合や集計にはスキーマの知識が必要です。クエリ結果を生成した後、生の表形式の出力を実用的な洞察に変換するには、特定のドメイン専門知識が必要になることがよくあります。これらの課題は、特に構造化データと非構造化データを組み合わせる場合、組織がデータアセットを効果的に活用する能力を著しく制限する可能性があります。 ソリューション概要 BMW Group のエージェンティック検索ソリューションは、AI エージェントフレームワーク内で 3 つの補完的な検索アプローチを組み合わせることで、大規模なデータセットからインサイトを抽出するという課題に対処します。このソリューションにより、ユーザーは自然言語を使用してペタバイト規模の構造化データと非構造化データをクエリでき、クエリの特性に基づいて最適な検索戦略が自動的に選択されます。 本記事では、車両テストで報告された問題の詳細な記録を収集する製品品質システムのデータセットを使用してソリューションを紹介します。各レコードには、問題の説明、分類、技術的な詳細がドイツ語と英語の両方で含まれており、世界中の生産施設やサービスセンターから蓄積されたものです。このデータセットは、何年にもわたる品質エンジニアリングの知識を表しており、意味的に類似した問題がチームや言語によって異なる用語で記述されています。 このアーキテクチャは、それぞれ特定の検索パターン向けに設計された 3 つの専門ツールで構成されています。 ハイブリッド検索: セマンティック検索と SQL フィルタリングを組み合わせて、概念的に類似したデータを効率的に取得します。このツールは、まずベクトルベースのセマンティック検索を実行して関連するレコードを特定し、次に SQL フィルタを適用して正確に絞り込みます。「特定の車両モデルのブレーキシステムに関するフィードバックを検索する」など、概念的な理解と構造化されたフィルタリングの両方が必要なクエリに最適です。 網羅的検索: AI を活用した評価を使用して、セマンティック検索だけでは用語のバリエーションにより関連する結果を見逃す可能性がある場合に、一致するすべてのレコードを包括的に分析します。このツールは SQL クエリを実行して候補レコードを取得し、次に大規模言語モデル (LLM) を使用して各結果を評価し、詳細な推論で関連性を判断します。「ブレーキ関連の問題は何件発生しましたか？」など、完全なカバレッジが不可欠な質問に特に効果的です。 SQL クエリ: セマンティック分析が不要な場合に、正確なデータ取得のための直接的な構造化クエリ機能を提供します。このツールは、構造化されたデータフィールドに対する集計、カウント、統計分析などの純粋な分析クエリを処理します。 AI エージェントがこれらのツールを統制し、各ユーザークエリを分析して最も適切な検索戦略を決定します。エージェントは、概念的なクエリにはセマンティック検索、包括的な分析には網羅的検索、構造化された分析には直接 SQL を自動的に切り替えます。これらすべてが単一の会話型インターフェースを通じて実行されます。このインテリジェントなルーティングにより、ユーザーは基盤となる技術的な複雑さを理解したり、検索方法を手動で選択したりすることなく、関連する結果を受け取ることができます。 アーキテクチャの詳細 次のアーキテクチャ図は、これらのコンポーネントがどのように連携してエージェンティック検索体験を提供するかを示しています。 図 1. エージェンティック検索ソリューションのアーキテクチャ コアコンポーネント データストレージとベクトル検索 Amazon S3 Vectors (S3 Vectors) は、ベクトル埋め込みに対するセマンティック検索を可能にし、専用のベクトルデータベースインフラストラクチャを必要とせずに、数百万のデータポイントにわたる効率的な最近傍クエリをサポートします。S3 Vectors の構造化データに対しては、 Amazon Athena (Athena) がサーバーレス SQL クエリ実行を提供し、元のソースデータに対するアドホック分析と構造化フィルタリングを可能にします。 LLM とエージェントの実装 Amazon Bedrock (Bedrock) は、複数の LLM でソリューションを強化します。ベクトル埋め込みの生成には Amazon Titan Text Embeddings V2 (Titan Text Embeddings) を使用し、エージェントのオーケストレーションのための主要な推論モデルとして Anthropic の Claude Sonnet 4.5 を使用し、網羅的検索におけるコスト効率の高い分類タスクには Anthropic の Claude Haiku 4.5 を使用します。AWS のオープンソースフレームワークである Strands Agents は、ツールの選択、会話フロー、モデルとのインタラクションを管理しながら、本番環境レベルの信頼性を維持して AI エージェントをオーケストレーションします。 データ取り込みとベクトルインデックスの作成 エージェンティック検索ソリューションがクエリに回答する前に、ソースデータを処理し、セマンティック検索用にインデックス化する必要があります。ここでは、 AWS Lambda (Lambda) を使用してサーバーレスの取り込みパイプラインを実装し、タイトルや説明などの自由形式のテキスト属性を含む構造化データベースレコードを、検索可能なベクトル埋め込みに変換しました。 取り込みプロセスは、次のステップに従います。 データ抽出: Lambda 関数は Amazon Athena でソースデータベーステーブルをクエリし、ドイツ語と英語の両方で問題の説明、タイトル、分類を含む製品品質レコードを取得します。 テキスト準備: 各レコードに対して、パイプラインは意味的に関連するフィールド (クラスター名、問題タイトル、説明) を連結し、埋め込み生成に適した統一されたテキスト表現を作成します。 埋め込み生成: 準備されたテキストは Titan Text Embeddings に送信され、各レコードの意味的な意味を捉える 1,024 次元のベクトル埋め込みが生成されます。 ベクトルストレージ: 埋め込みは S3 Vectors インデックス形式を使用して Amazon S3 に保存され、各ベクトルには検索操作時の取得のために対応するレコード ID がタグ付けされます。 メタデータの永続化: 元の構造化データは S3 に残り、Athena 経由でクエリできるため、エージェンティック検索ツールは意味的類似性と SQL ベースのフィルタリングを組み合わせることができます。 このインジェストアーキテクチャはデータを増分処理するため、BMW Group は新しい製品品質問題が報告されるたびに、データセット全体を再処理することなく、ベクトルインデックスを継続的に更新できます。 ハイブリッド検索 ハイブリッド検索ツールは、セマンティック類似性と SQL フィルタリングを組み合わせることで、ユーザーが正確なビジネス制約を適用しながら、概念的に関連するレコードを見つけることを可能にします。例えば、「前四半期の F09 車両におけるブレーキシステムのフィードバックを見つける」というクエリは、セマンティックな理解 (何が「ブレーキシステムのフィードバック」に該当するか) と構造化されたフィルタリング (特定の車両モデルと時間範囲) の両方を必要とします。 仕組み: ユーザーがクエリを送信すると、エージェントは 3 つのパラメータを使用してハイブリッド検索ツールを呼び出します。 1) 検索する概念を説明するセマンティッククエリ (例:「ブレーキシステムのフィードバック」)、 2) 取得する類似レコードの数を指定する top_k 値 (例: 100)、 3) フィルタリング用のプレースホルダー {semantic_ids} を含む SQL クエリテンプレートです。その後、ツールは複数のステップからなるプロセスを実行して、関連性の高い結果を提供します。 ステップ 1 – セマンティック検索フェーズ: ツールはまず、セマンティッククエリを Titan Text Embeddings に送信してクエリベクトルを生成します。次に、このベクトルを使用して、コサイン類似度 (cosine similarity) に基づいて最も類似した top_k 件の製品品質レコードを S3 Vectors インデックスから検索します。S3 Vectors API は、クエリとのセマンティックな関連性によってランク付けされた ID のリストを返します。 入力例: 「ブレーキシステムのフィードバック」 出力例: 類似度でランク付けされた ID: [12847, 9203, 15634, 8821, … ] (ブレーキパッドの摩耗、ブレーキフルードのチェック、ブレーキ性能などに関する上位 100 件のレコード) ステップ 2 – SQL フィルタリングフェーズ: セマンティック ID が SQL クエリテンプレートに注入されます。その後、Athena がこの SQL クエリを実行します。このクエリには、追加の WHERE 句、JOIN、集計、またはその他の有効な SQL 操作を含めることができ、日付、重要度レベル、車両モデルなどの構造化データ属性に基づいて結果をさらに絞り込むことができます。 入力 SQL テンプレートの例: SELECT * FROM quality_records WHERE record_id IN ({semantic_ids}) AND vehicle_model = ‘F09’ AND report_date >= DATE ‘2025-10-01’ 実行されたクエリの例: SELECT * FROM quality_records WHERE record_id IN (12847, 9203, 15634, 8821, …) AND vehicle_model = ‘F09’ AND report_date >= DATE ‘2025-10-01’ 出力例: セマンティック類似性と構造化フィルタの両方に一致する 7 件のレコード ステップ 3 – 結果の統合: フィルタリングされた結果がエージェントに返され、エージェントは Anthropic の Claude Sonnet 4.5 を使用して自然言語の応答を合成し、関連する詳細と洞察を含むユーザーフレンドリーな形式で調査結果を提示します。 ユーザーへの出力例： 「2024 年第 4 四半期の F09 車両において、ブレーキ関連の記録が 7 件見つかりました。最も多かったのは、ブレーキパッド点検 (3 件)、ブレーキフルード交換 (2 件)、ブレーキ性能チェック (2 件) です。」 このハイブリッドアプローチにより、結果がセマンティックに関連性があり (「ブレーキシステムのフィードバック」にはブレーキパッドの摩耗、ブレーキフルードのサービスなどが含まれることを理解)、かつ正確にフィルタリングされる (F09 のみ、直近の四半期のみ) ことが保証されます。このアプローチは、自然言語理解の柔軟性と構造化クエリの精度を組み合わせることで、セマンティックに関連性があり、ビジネス要件に従って正確にフィルタリングされた結果をユーザーに提供するように設計されています。次のシーケンス図は、完全なワークフローを示しています。 図 2. ハイブリッド検索のシーケンス図 包括的な分析のための網羅的検索 ハイブリッド検索は意味的に類似したレコードを見つけることに優れていますが、一部のクエリでは完全なカバレッジを確保するために、一致するすべてのレコードの包括的な分析が必要です。「F00 モデルでブレーキ関連の問題は何件発生しましたか？」のような質問では、用語のバリエーション (例: 「ブレーキ」、「ブレーキシステム」、「ブレーキパッド」、「ABS」 ) によってセマンティック検索が関連するケースを見逃す可能性があるため、網羅的な評価が必要です。網羅的検索ツールは、SQL ベースの候補取得と AI による関連性分類を組み合わせることで、この課題に対処します。 網羅的検索ワークフローは、エージェントがクエリに対して類似性ベースの検索ではなく包括的なカバレッジが必要であると判断したときに開始されます。このツールは 2 つのパラメータを受け取ります。データベースから候補レコードを取得する SQL SELECT クエリと、関連性のある結果を構成するものを定義する検索問題の説明です。 候補の取得: エージェントは、用語の不一致を避けるため、セマンティックな概念ではなく構造化されたフィルタのみを使用して SQL クエリを生成します。たとえば、「ブレーキ関連の問題」のようなセマンティックな用語でフィルタリングする代わりに、クエリは正確なカラム値を使用します: SELECT * FROM quality_records WHERE vehicle_model = ‘F00’ これにより、LLM がデータセットから正しい用語を推測することに依存せずに、構造化された条件に一致するすべてのレコード (潜在的に数千の候補) を取得できます。このツールには再試行メカニズムが含まれています。Athena がエラー (無効なカラム名、構文エラー、またはその他の SQL エラー) を返した場合、エラーメッセージがエージェントに返され、修正されたクエリを再生成できます。これにより、ハルシネーションによる SQL が暗黙的に失敗するのを防ぎ、エージェントが実際のスキーマ情報に基づいて自己修正できるようサポートします。 バッチ処理による LLM 分類: すべての候補を一度に処理するのではなく、このツールは効率的な処理のために候補を 20 件のレコードのバッチに分割します。各バッチはマークダウンテーブルとしてフォーマットされ、Bedrock 経由で小型の LLM (Anthropic の Claude Haiku 4.5) に送信されます。モデルは各レコードを検索問題に照らして評価し、関連性があるかどうかを判断し、その判断に対する簡潔な根拠を提供します。20 という数は、モデル呼び出しの回数と コンテキストの劣化 (コンテキストウィンドウ内のトークン数が増加すると、そのコンテキストから情報を正確に想起するモデルの能力が低下する) の間の良いトレードオフであることがわかりました。バッチは並列処理され、総処理時間が大幅に短縮されます。この並列化により、分類タスクに小型で高速なモデルを使用してコスト効率を維持しながら、数千のレコードを数秒で評価できます。 結果の集約: すべてのバッチが完了した後、ツールは関連する結果を集約し、各レコードに LLM の判断根拠を含む _reason_for_match フィールドを追加して充実させます。この透明性により、ユーザーは特定のレコードが含まれた理由を理解でき、LLM を活用したフィルタリングへの信頼を構築できます。 網羅的検索アプローチは、関連するケースを見逃すとビジネス上の意思決定に影響を与える可能性がある重要なクエリに対して、完全なカバレッジを提供します。SQL の構造化されたフィルタリングと LLM のセマンティック理解を組み合わせることで、このツールはどちらのアプローチ単独では実現できない精度と再現率の両方を達成します。次のシーケンス図は、完全なワークフローを示しています。 図 3. 全探索のシーケンス図 主なメリットと成果 構造化データと非構造化データへの統一的なアプローチ ハイブリッド検索、網羅的検索、SQL クエリの組み合わせにより、このソリューションは単一の会話型インターフェース内で構造化データと非構造化データの両方をシームレスに処理できます。ユーザーは、概念的な理解を必要とする質問 (「類似のブレーキシステムのフィードバックを見つける」)、正確なフィルタリング ( 「前四半期のブレーキ問題の数を数える」 )、または包括的な分析 ( 「安全関連のすべてのインシデントを評価する」 ) を、ツールを切り替えたりクエリを再構成したりすることなく行うことができます。エージェントのインテリジェントなツール選択により、各クエリタイプが最も適切な方法で処理され、一貫した自然言語のユーザーエクスペリエンスを維持しながら正確な結果を提供します。 コスト効率の高いサーバーレスアーキテクチャ サーバーレス AWS サービス で完全に構築されているため、ソリューションコンポーネントは使用していないときはゼロにスケールし、コンピューティングリソースはオンデマンドで割り当てられ、実際の使用量に対してのみ料金が発生します。サーバーレスアーキテクチャにより、従来のインフラストラクチャの運用オーバーヘッドや固定コストなしに、AI を活用した高度なデータ分析プラットフォームを開発できます。 まとめ このエージェンティック検索ソリューションは、AWS の生成 AI サービスがユーザーとデータのインタラクション方法をどのように変革できるかを実証しています。ユーザーとインサイトの間の従来の障壁を軽減することで、このアプローチにより、エンタープライズアプリケーションに必要な精度とスケールを維持しながら、すべてのユーザーがデータインサイトを生成できるようになります。組織が生成するデータ量が増加し続ける中、このようなソリューションは、エンタープライズデータ資産の価値を最大限に引き出すために不可欠なものとなっています。 AWS で AI を活用したデータソリューションの構築について詳しく知りたい方は、 生成 AI リソース をご覧ください。 Ruben Simon Ruben Simon は、BMW 最大のデータプラットフォームである Cloud Data Hub のベテランプロダクトマネージャーです。データ、アナリティクス、AI分野におけるデジタルトランスフォーメーションの推進に情熱を注ぎ、国際的なチームとの協働を生き甲斐としています。仕事以外では家族との時間を大切にし、継続的な学びに強い関心を持っています。 Fabian Söllner Fabian Söllner は BMW Cloud Data Hub チームのソフトウェアエンジニアである。最先端のビジネスインテリジェンスと人工知能ソリューションを提供することで、組織全体の同僚を支援することに尽力している。仕事以外では、様々なスポーツ、特にロードサイクリングとトライアスロンへの情熱を巧みにキャリアと両立させ、個人と職業の両面での自己研鑽への意欲を示している。 Florian Seidel Florian Seidel は AWS のグローバルソリューションアーキテクトとして自動車分野を専門としています。戦略的顧客がクラウド技術の潜在能力を最大限に活用し、自動車産業の革新を推進するよう導いています。アナリティクス、機械学習、AI、耐障害性分散システムへの情熱を持ち、最先端の概念を実用的なソリューションへと変革する支援を行っています。クラウド戦略の設計以外の時間には、家族や友人のための料理や電子音楽制作の実験を楽しんでいます。 Khalid Al Khalili Khalid Al Khalili は、BMW グループのデータアーキテクトであり、BMW のデータイノベーションの中心的なプラットフォームである Cloud Data Hub のアーキテクチャを統括しています。彼は、シームレスなデータ体験の創出、複雑な要件を効率的でユーザーフレンドリーなソリューションへと変換することを強く提唱しています。新機能の開発に携わっていないときは、同僚や部門横断的なチームと協力して BMW のデータ戦略を推進・形成し、急速に進化する環境において BMW が常に先頭を走り続けることを確保することに喜びを感じています。 Martin Maritsch Martin Maritsch は、AWS ProServe のシニア生成型 AI アーキテクトであり、生成型 AI および MLOps を専門としています。AWS クラウド上の AI/ML サービスの可能性を最大限に引き出すことで、企業顧客がビジネス成果を達成できるよう支援しています。 Shukhrat Khodjaev Shukhrat Khodjaev は、AWS ProServe のシニア・エンゲージメント・マネージャーであり、AI を専門としています。顧客が AI 変革を加速し、イノベーションを推進し、AI アプリケーションの限界を押し広げて、具体的なビジネス成果を生み出すことを支援しています。 本記事は Senior Solutions Architect の 長谷川 仁志 が翻訳しました。

本記事は 2026 年 2 月 10 日 に公開された「 Set up LucidLink with service managed fleet scripts for AWS Deadline Cloud 」を翻訳したものです。 最新のクリエイティブワークフローでは、インフラストラクチャ管理の負荷なくオンデマンドでスケールできる高性能レンダリング機能が求められます。この課題に対して AWS Deadline Cloud のサービスマネージドフリート（SMF）を使うことで、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス管理や、OS アップデート、Virtual Private Cloud (VPC) 設定、ネットワーク設定などの複雑な管理をAWS Deadline Cloud が代行してくれるため、現場担当者はインフラストラクチャ運用ではなく、レンダリングワークロードに集中できます。 その上で、LucidLink のクラウドネイティブなハイブリッドファイルシステムを組み合わせると、クラウドとオンプレミスの両方でインフラストラクチャ管理を不要とする強力なソリューションになります。クリエイティブチームは最小限のインフラストラクチャで大規模なレンダリングを実行しつつ、どこからでもプロジェクトファイルにすぐにアクセスできます。 本記事では、AWS Deadline Cloud の SMF に LucidLink を統合する方法を紹介し、スケーラブルで高性能なレンダリングワークフローを構築するソリューションを解説します。 AWS Deadline Cloud は SMF のConfig スクリプトに対応し、LucidLink などのサードパーティストレージソリューションをレンダリングワークフローに統合しやすくなりました。Deadline Cloud 環境に LucidLink を組み合わせ、高性能でスケールアウト可能なクラウドベースのレンダリング環境をセットアップする手順をご紹介します。 前提条件 開始する前に、以下を準備ください。 以下の権限を持つ AWS アカウント : AWS Deadline Cloud のファームとフリートの作成・管理 AWS Secrets Manager シークレットの作成・読み取り AWS Identity and Access Management (IAM) ロールとポリシーの変更 認証情報を設定済みの AWS Command Line Interface ( AWS CLI ) pip がインストールされた Python 3 (Deadline Cloud CLI ツール用) 以下を満たす LucidLink アカウント : 有効な認証情報 (ユーザー名とパスワード) 作成済みの Filespace と Workspace Filespace 名と Workspace 名の把握 AWS Deadline Cloud の基本的な概念と用語の理解 この例では、ジョブ実行フローで以下を行います。 ① 管理者権限で LucidLink をインストール ② ジョブ実行前にレンダーノードに適切な LucidLink Filespace をマウント ③ ジョブ完了時に LucidLink Filespace をアンマウント ④ Filespace への接続を検証するカスタムジョブを作成/実行 レンダリングライフサイクルにおいて、この 4 つのタッチポイントを使用します。 図 1. AWS Deadline Cloud と LucidLink の統合ワークフロー 構築する内容 このチュートリアルを完了すると、以下の環境が構築されます。 LucidLink 対応フリートを備えた Deadline Cloud ファーム SMF Config スクリプトによる LucidLink クライアントの自動インストール ジョブごとにファイルシステムを動的にマウントする OpenJD ジョブテンプレート ステップ 1: LucidLink の認証情報を AWS Secrets Manager に保存する AWS Secrets Manager を使用して LucidLink の認証情報を安全に保存します。その認証情報は、レンダリングジョブが LucidLink ファイルシステムをマウントする際に取得されます。 AWS Secrets Manager コンソールを開く [新しいシークレットを保存する] をクリック [その他のシークレットのタイプ] を選択 以下のキーと値のペアを追加: {   "username": "your-lucidlink-username",   "password": "your-lucidlink-password" } シークレット名: lucidlink-credentials 作成プロセスを完了 ステップ 2: Deadline Cloud ファームをセットアップする レンダリングワークロードをホストする Deadline Cloud ファームを作成します。 AWS Deadline Cloud コンソールに移動 ファームを作成 をクリック ファーム設定を構成: ファーム名: lucidlink-render-farm ファームを作成 をクリック ステップ 3: LucidLink 対応のSMFを作成する ステップ 3a: LucidLink インストール設定スクリプトを作成する フリートインスタンスに LucidLink クライアントをインストールする設定スクリプトを作成します。このスクリプトはインストールとデーモンのセットアップのみを行います。フリートにデプロイする前に、スタンドアロンの EC2 インスタンスでスクリプトが正しく動作することをテストしてください。 <p>#!/bin/bash # LucidLink Client Installation Script # This script only installs the LucidLink client and sets up the daemon service # Filesystem mounting is handled separately via OpenJD job templates set -ex # -----------------------------Install tree utility----------------------------- # Install tree for directory visualization yum install tree -y # ----------------------Install and configure LucidLink 3----------------------- echo "Installing LucidLink client..." # Download latest stable LucidLink RPM package wget -q https://www.lucidlink.com/download/new-ll-latest/linux-rpm/stable/ -O lucidinstaller.rpm<br />ls -l lucidinstaller.rpm # Install the LucidLink client yum install -y lucidinstaller.rpm # Create systemd service for persistent daemon echo "Creating systemd service for LucidLink daemon..." cat << EOF > /etc/systemd/system/lucidlink.service [Unit] Description=LucidLink Filespace Daemon After=network-online.target Wants=network-online.target [Service] Type=simple ExecStart=/usr/local/bin/lucid3 daemon ExecStop=/usr/local/bin/lucid3 exit Restart=on-failure RestartSec=5 User=root Group=root [Install] WantedBy=multi-user.target EOF # Enable and start the LucidLink daemon service echo "Enabling and starting LucidLink daemon service..." systemctl daemon-reload systemctl enable lucidlink systemctl start lucidlink # Create base mount directory with proper permissions echo "Creating mount point..." mkdir -p /mnt/lucid <br />chmod a+rwx /mnt/lucid # Verify installation echo "LucidLink client installation complete" lucid3 status 次に、LucidLink 設定スクリプトを使用してフリートを作成します。 Deadline Cloud ファームページのフリートタブへ移動して フリートを作成 をクリック フリートの詳細を定義 セクション: フリート名: lucidlink-render-fleet フリートタイプ: サービスマネージド 次へ をクリック ワーカー機能 セクション: CPU または GPU インスタンスを選択 オペレーティングシステム: Linux 次へ  をクリック 追加の設定を行う – オプション セクション: ワーカー設定スクリプトを有効化 にチェック スクリプト内容: LucidLink 設定スクリプトを貼り付け ステップ 4: LucidLink マウント用のキュー環境（Queue Environment ）を作成する ステップ 4a: LucidLink ジョブキューを作成する Deadline Cloud ファームページのキュータブへ移動して キューを作成 をクリック 基本設定を構成: 名前: lucidlink-queue ジョブアタッチメントのバケット名 : lucidlink-attachments フリートを関連付ける – オプション: lucidlink-render-fleet キューを作成 をクリック ユーザーがレンダリングジョブを送信できるジョブキューが作成され、先ほど作成したレンダーフリートが使用されます。 ステップ 4b: キューの IAM ロール権限を更新する キューが使用している IAM ロールを確認し、Secrets Manager のシークレットへのアクセス権限を追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": "arn:aws:secretsmanager:*:*:secret:lucidlink-credentials*" } ] } Queue Environment を使用すると、特定のキューでジョブが開始されるたびに Deadline Cloud でカスタムスクリプトを実行できます。この例では、ジョブ実行中の 2 つのタイミングで Bash スクリプトを実行します。 ジョブ開始時 (Queue Environment - Enter) ジョブ完了後 (Queue Environment - Exit) Queue Environment では、parameterDefinitions を通じてユーザーにパラメータを公開できます。ここでは、以下の設定を変更可能にし、デフォルト値も設定しています。 Lucid Secret Name (Secrets Manager に保存したシークレット名) LucidLink の Workspace と Filespace Open Job Description YAML では次のようになります。 parameterDefinitions: - name: LucidSecretName type: STRING description: AWS Secrets Manager secret name containing LucidLink credentials default: lucidlink-credentials - name: LucidWorkspace type: STRING description: LucidLink workspace name to mount userInterface: control: LINE_EDIT label: Workspace Name default: lucid-workspace - name: LucidFilespace type: STRING description: LucidLink filespace name to mount userInterface: control: LINE_EDIT label: Filespace Name default: lucid-filespace Queue Environment Enter 時 #!/bin/bash # Exit on error, undefined vars, pipe failures set -euo pipefail echo "Mounting LucidLink filesystem..." # Create mount point directory MOUNTPOINT="/mnt/lucid/{{Param.LucidWorkspace}}/{{Param.LucidFilespace}}" mkdir –p ${{MOUNTPOINT}} # Get credentials from AWS Secrets Manager SECRET=$(aws secretsmanager get-secret-value \ --secret-id "{{Param.LucidSecretName}}" \ --query 'SecretString' --output text) # Parse credentials from JSON LUCID_USERNAME=$(echo "$SECRET" | jq -r '.username') LUCID_PASSWORD=$(echo "$SECRET" | jq -r '.password') # Mount filesystem echo "${LUCID_PASSWORD}" | lucid3 link \ --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" \ --user "${LUCID_USERNAME}" \ --mount-point "${MOUNTPOINT}" \ --fuse-allow-other # Verify mount is accessible if [ -d "${MOUNTPOINT}" ] && [ "$(ls -A ${MOUNTPOINT})" ]; then echo "Mount verification successful" else echo "Warning: Mount point appears empty or inaccessible" exit 1 fi Queue Environment Exit 時 echo "Unmounting LucidLink filesystem..." lucid3 unlink --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" || true echo "LucidLink filesystem unmounted" これらをまとめて 1 つの Open Job Description 環境にすると、Deadline キュー で使用できます。 specificationVersion: 'environment-2023-09' parameterDefinitions: - name: LucidSecretName type: STRING description: AWS Secrets Manager secret name containing LucidLink credentials default: lucidlink-credentials - name: LucidWorkspace type: STRING description: LucidLink workspace name to mount userInterface: control: LINE_EDIT label: Workspace Name default: lucid-workspace - name: LucidFilespace type: STRING description: LucidLink filespace name to mount userInterface: control: LINE_EDIT label: Filespace Name default: lucid-filespace environment: name: LucidLinkMount description: Environment for mounting LucidLink filesystem script: actions: onEnter: command: "{{Env.File.MountLucidLink}}" onExit: command: "{{Env.File.UnmountLucidLink}}" embeddedFiles: - name: MountLucidLink type: TEXT runnable: true data: | #!/bin/bash # Exit on error, undefined variables, and pipe failures set -euo pipefail   echo "Mounting LucidLink filesystem..." # Create mount point directory MOUNTPOINT="/mnt/lucid/{{Param.LucidWorkspace}}/{{Param.LucidFilespace}}" mkdir -p "${MOUNTPOINT}"   # Get credentials from AWS Secrets Manager SECRET=$(aws secretsmanager get-secret-value \ --secret-id "{{Param.LucidSecretName}}" \ --query 'SecretString' --output text)   # Parse credentials from JSON LUCID_USERNAME=$(echo "$SECRET" | jq -r '.username') LUCID_PASSWORD=$(echo "$SECRET" | jq -r '.password')   # Mount filesystem echo "${LUCID_PASSWORD}" | lucid3 link \ --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" \ --user "${LUCID_USERNAME}" \ --mount-point "${MOUNTPOINT}" \ --fuse-allow-other   # Verify mount is accessible if [ -d "${MOUNTPOINT}" ] && [ "$(ls -A ${MOUNTPOINT})" ]; then echo "Mount verification successful" else echo "Warning: Mount point appears empty or inaccessible" exit 1 fi - name: UnmountLucidLink type: TEXT runnable: true data: | echo "Unmounting LucidLink filesystem..." lucid3 unlink --fs "{{Param.LucidFilespace}}.{{Param.LucidWorkspace}}" || true echo "LucidLink filesystem unmounted" AWS Deadline Cloud にロードするには、対象のキューを選択し、「Queue Environments」タブに移動します。 図 2. AWS Deadline Cloud のQueue Environmentsテーブル Actions から Create New from YAML を選択し、Queue Environmentsスクリプトを貼り付けます。 図 3. AWS Deadline Cloud のQueue Environments編集ページ ステップ 5: セットアップをテストする 図 4. 完了した AWS Deadline Cloud タスクの実行 LucidLink の統合を検証するため、AWS Deadline Cloud CLI でテストジョブを作成して送信します。 Deadline Cloud CLI のインストール まず、Deadline Cloud CLI ツールをインストールします: pip install 'deadline[gui]' Deadline Cloud Monitor のインストール Deadline Cloud Monitor はジョブの認証とモニタリングに必要です。AWS Deadline Cloud コンソールからダウンロードしてインストールします。 AWS Deadline Cloud コンソールに移動 サービスページに移動 お使いのオペレーティングシステム用の Deadline Cloud Monitor をダウンロード 表示される手順に従ってインストール テストジョブテンプレートの作成 LucidLink ファイルシステムが正しくマウントされアクセス可能であることを確認する基本的な OpenJD ジョブテンプレートを作成します。以下の内容を新しいディレクトリに template.yaml として保存します。 specificationVersion: 'jobtemplate-2023-09' name: Test LucidLink Mount steps: - name: Print Tree of LucidLink Mount script: actions: onRun: command: '{{Task.File.runScript}}' embeddedFiles: - name: runScript type: TEXT runnable: true data: | #!/usr/bin/env bash set -ex tree --du -h -L 6 /mnt/lucid テストジョブを送信してモニタリングします。 以下のいずれかの方法でテストジョブを送信します。 コマンドラインでの送信: deadline bundle submit --farm-id <farm-id> --queue-id <queue-id> <bundle-directory> GUI での送信 (パラメータのカスタマイズが可能): deadline bundle gui-submit <directory-name> 統合の検証 ジョブが完了したら、LucidLink ファイルシステムが正常にマウントされたことを確認します。 Deadline Cloud Monitor アプリケーションを開く ジョブリストからテストジョブを見つける ログを表示 をクリックしてジョブ出力を確認 ログに LucidLink マウントポイント /mnt/lucid のディレクトリツリー構造が表示されていることを確認 テストが成功すると、LucidLink Filespace の完全なディレクトリ階層が表示され、ジョブ実行中にファイルシステムが正しくマウントされアクセス可能であることが確認できます。 考慮事項 このモジュラーアーキテクチャはインストールとマウントを分離しており、ジョブごとに異なるファイルシステム設定を使用できます。LucidLink デーモンは systemd サービスとして実行されジョブ実行間で永続化されます。マウントポイントには chmod 755 権限と --fuse-allow-other フラグが必要です。認証情報は AWS Secrets Manager から安全に取得され、OpenJD テンプレートがマウントとアンマウントを自動的に処理してリソースを適切に管理します。フリートにデプロイする前に、必ずスタンドアロンの EC2 インスタンスで設定スクリプトをテストしてください。 トラブルシューティング セットアップやジョブ実行で問題が発生した場合は、まず AWS Deadline Cloud コンソールでフリート設定スクリプトのログを確認し、LucidLink クライアントが正しくインストールされたことを検証します。マウントの問題については、失敗したタスクを右クリックして「View Worker Logs」を選択し、デーモンが実行中であることを確認してから、ジョブ固有のログでファイルシステムアクセスエラーを確認します。権限の問題は通常、フリートの IAM ロールに Secrets Manager シークレットへのアクセス権がないか、マウントポイントの権限調整が必要であることを示しています。テンプレート関連の問題は、本番ワークロードを送信する前に、OpenJD YAML構文の検証とDeadline Cloud CLIによるジョブテンプレートのテストによって特定できます。 クリーンアップ Deadline Cloud と LucidLink の使用を中止する場合は、AWS Deadline Cloud コンソールでフリートとキューを削除します。テスト用の EC2 インスタンスを作成した場合は、EC2 コンソールから終了します。不要になった場合は、LucidLink の認証情報を含む AWS Secrets Manager シークレットも削除してください。 まとめ LucidLink のインストールとファイルシステムのマウントを分離することで、柔軟でメンテナンスしやすい構成を実現できます。サービスマネージドフリートが 1 回限りのクライアントインストールを処理し、OpenJD ジョブテンプレートがジョブごとのファイルシステムマウントを管理することで、以下のメリットが得られます。 モジュール性: ジョブごとに異なるファイルシステムや設定をマウント可能 リソース効率: ファイルシステムは必要なときだけマウントされ、自動的にアンマウント セキュリティ: 認証情報はジョブ環境内で安全に処理 信頼性: インストールとマウントの両フェーズで適切なエラー処理とクリーンアップ このアーキテクチャは、セキュリティのベストプラクティスを維持しつつ運用を効率化し、レンダリングワークフローに高性能な共有ストレージを提供します。LucidLink のグローバルファイルシステムと AWS Deadline Cloud のスケーラブルなレンダリングインフラストラクチャを組み合わせることで、クリエイティブチームは地理的な境界を越えてシームレスにコラボレーションできます。 AWS の担当者 に問い合わせて、ビジネスの加速を支援する方法をご確認ください。 関連情報 AWS Deadline Cloud のサービスマネージドフリートと設定スクリプトの詳細は、 AWS Deadline Cloud ドキュメント を参照してください。Open Job Description (OpenJD) の詳細は、 OpenJD specifications GitHub ページ または OpenJD ドキュメントページ を参照してください。 LucidLink について LucidLink は、クリエイティブチームがどこからでも協力して作業できるストレージコラボレーションプラットフォームです。ゼロ知識暗号化で保護された単一の共有 Filespace で、あらゆる規模のプロジェクトに即座に安全にアクセス、編集、共有できます。詳しくは LucidLink on AWS をご覧ください。 著者について Zach Willner AWS のメディア & エンターテインメント担当シニアパートナーソリューションアーキテクトです。AWS 上のメディア & エンターテインメント向けパートナーエコシステムの構築に取り組んでいます。 DJ Rahming AWS のビジュアルコンピューティング担当シニアソリューションアーキテクトです。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語)  AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 最近はフィジカル AI の動向把握に注力しています。下記で触れている「 月刊 AWS 製造 2026年2月号 」にもいくつか記事が取り上げられていますので是非ご覧ください。 2 月 27 日 （金）に「 企業でつかうためのCoding Agent「Kiro」 オンライン勉強会 」が開催されます。AI エージェントを活用した開発プロセスの効率化に関心がある方はぜひ参加ください！ また 3 月 26 日（木）には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください！ それでは、2 月 9 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AWS Transform custom: AI 駆動 Java モダナイゼーションで技術的負債を削減」を公開 AWS Transform custom を使用して、Java アプリケーションのモダナイゼーションを AI で自動化する方法を紹介しています。Java 8 から Java 21 へのアップグレードを例に、AWS マネージド変換の適用手順や、組織固有のカスタム定義変換の作成方法をステップバイステップで解説しています。手動リファクタリングでは数週間かかる作業を数分で実現できるため、技術的負債の削減に取り組んでいる方はぜひご覧ください。 ブログ記事「Amazon、Nova モデル強化に向けプライベート AI バグバウンティプログラムを開始」を公開 Amazon が Amazon Nova 基盤モデルを対象としたプライベート AI バグバウンティプログラムを開始しました。セキュリティ研究者やパートナー大学の専門家と連携し、プロンプトインジェクション、モデルの脆弱性、CBRN 関連の脅威検出などの領域でテストを行い、有効な脆弱性の報告に対して 200 ドルから 25,000 ドルの報奨金が支払われます。 ブログ記事「エンタープライズにおける AI エージェント: Amazon Bedrock AgentCore を活用したベストプラクティス」を公開 Amazon Bedrock AgentCore を活用して本番環境で使えるエンタープライズ向け AI エージェントを構築するための 9 つのベストプラクティスを紹介しています。小さく始めてスコープを明確にすること、初めからオブザーバビリティを測定すること、計画的なツール戦略、評価の自動化、マルチエージェントアーキテクチャ、セキュリティ、継続的テストなど、初期のスコーピングから組織全体へのスケーリングまで幅広くカバーした実践的なガイドです。 ブログ記事「月刊 AWS 製造 2026年2月号」を公開 製造業向けの月次アップデートブログです。今月のピックアップトピックはフィジカル AI で、AWS Japan が提供するフィジカル AI 開発支援プログラムの紹介や、VLA/VLM モデル開発の技術支援に関する情報、NVIDIA GR00T や HuggingFace LeRobot を活用したエッジからクラウドまでのフィジカル AI 環境構築、AWS Batch でのロボット学習基盤の構築方法など、フィジカル AI 関連の翻訳ブログ 5 本が紹介されています。 サービスアップデート Amazon Bedrock が 6 つのフルマネージドオープンウェイトモデルを追加サポート Amazon Bedrock で 6 つの新しいオープンウェイトモデル (DeepSeek V3.2、MiniMax M2.1、GLM 4.7、GLM 4.7 Flash、Kimi K2.5、Qwen3 Coder Next) が利用可能になりました。これまで高コストだった高性能 AI モデルの推論が大幅に安くなり、企業でのコード生成や推論タスクが手軽に実現できます。これらのモデルは、高度なサービス品質提供を行うための新しい分散推論エンジン Project Mantle によって提供されます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が AWS PrivateLink のサポートを拡張 Amazon Bedrock が AWS PrivateLink のサポートを拡張し、新たに bedrock-mantle エンドポイントでもプライベートアクセスが可能になりました。従来は bedrock-runtime エンドポイントのみでしたが、今回 Project Mantle という新しい推論エンジンのエンドポイントも追加されました。これにより企業のプライベートネットワーク内から安全に AI モデルを利用でき、セキュリティを重視する企業での生成 AI アプリケーション開発が進めやすくなります。米国東部（バージニア北部）やアジアパシフィック（東京）リージョンなど 14 のリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore Browser でプロキシ設定をサポート Amazon Bedrock AgentCore Browser でプロキシ設定がサポートされました。これにより企業のプロキシインフラを通じてブラウザセッションを実行できるようになり、地域制限のあるコンテンツアクセスやコンプライアンス要件への対応が可能です。例えば医療や金融業界などの規制業界のお客様は、セキュリティポリシーに準拠しながら重要な業務プロセスを自動化することが可能になります。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod がコンソールからのノードアクションをサポート Amazon SageMaker HyperPod で、AWS コンソールから直接ノードを管理できるようになりました。従来は SSM 接続文字列の手動作成や CLI コマンドが必要でしたが、今回のアップデートでコンソール上でノードへの接続、再起動が可能になります。AI/ML ワークロード運用時のトラブルシューティングが大幅に効率化され、ダウンタイムを最小限に抑えられます。詳細は こちらのドキュメント をご覧ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本ブログは 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 の 中島 章博 が翻訳しました。