本記事は、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 の 中島 章博 が翻訳しました。

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

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

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

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

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