Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスは、従来、データベースファイルを格納するために単一の Amazon Elastic Block Store (Amazon EBS) ボリュームを使用していました。追加ストレージボリューム機能の導入により、Amazon RDS for SQL Server インスタンスに最大 3 つの追加ストレージボリュームをアタッチできるようになりました。この機能を使用することで、データファイルとログファイルを複数のボリュームに分散できます。この拡張機能により、ストレージ構成とパフォーマンス最適化に対するより細かい制御が可能になります。 この投稿では、追加ストレージボリューム機能を使用するためのさまざまなシナリオを紹介します。 ソリューション概要 以下のアーキテクチャ図は、追加ストレージボリューム構成を示しており、マルチアベイラビリティゾーン (マルチ AZ) 構成において、それぞれ 3 つのボリュームを持つプライマリホストとセカンダリホストの使用を表しています。 この投稿では、以下のシナリオについて学習します： 新しいストレージボリュームの追加 既存のストレージボリュームのスケーリング 追加のストレージボリュームでのデータベースの復元 ストレージボリュームの削除 このソリューションには、お客様のアカウントで費用が発生する新しい AWS リソースが必要です。詳細については、 AWS 料金表 をご確認ください。 前提条件 AWS Management Console の操作に慣れていることを前提としています。この投稿では、AWS アカウントで以下のリソースとサービスが有効になっている必要があります： RDS for SQL Server インスタンス。詳細な手順については、「 Amazon RDS で Microsoft SQL Server データベースを作成して接続する 」を参照してください。 注意 : 追加ストレージボリューム機能の最新の制限については、「 SQL Server でのストレージ動作 」を参照してください。 新しいストレージボリュームの追加 インスタンスの作成時またはインスタンスのデプロイ後に、最大 3 つの追加ストレージボリュームを追加できます。追加ストレージボリュームは、デフォルトのストレージボリュームを補完します。デフォルトボリュームは、ドライブレターとして D:\ を使用します。追加ストレージボリュームは、汎用 SSD(gp3) とプロビジョンド IOPS(io2) の 2 つのストレージタイプをサポートしているため、データベースワークロードに最適なストレージパフォーマンスを選択できます。ボリューム名は次のように Windows ドライブレターにマッピングされます： rdsdbdata2 – H:\ ドライブ rdsdbdata3 – I:\ ドライブ rdsdbdata4 – J:\ ドライブ インスタンス作成時にストレージボリュームを追加 インスタンス作成時に追加のストレージボリュームを追加するには、以下の手順を実行してください： Microsoft SQL Server データベースを Amazon RDS で作成して、接続する方法の詳細な手順については、「 Amazon RDS を使用した Microsoft SQL Server データベースの作成と接続 」を参照してください。 ストレージ については、適切なストレージタイプを選択してください。これがあなたの D:\ ボリュームになります。 追加のストレージボリューム – オプション については、 追加のストレージボリュームを追加 を選択してください。 ボリューム名 、 ストレージタイプ 、 割り当てストレージ 、 プロビジョンド IOPS 、および ストレージスループット に適切な値を入力または選択してください。 既存のインスタンスにストレージボリュームを追加 既存の RDS for SQL Server インスタンスにストレージボリュームを追加するには、以下の手順を完了してください： Amazon RDS コンソールで、 データベース を選択します。 DB 識別子 で、RDS for SQL Server インスタンスを選択します。この例では、 rds-asv-demo を選択しました。 設定タブ を選択します。 追加のストレージボリュームの追加 を選択します。 ボリューム名 、 ストレージタイプ 、 割り当てストレージ 、 プロビジョンド IOPS 、および ストレージスループット に適切な値を選択します。 スケジューリング で、 すぐに適用 を選択し、 送信 を選択します。 または、以下の AWS Command Line Interface (AWS CLI) を使用して、既存の Amazon RDS for SQL Server インスタンスに新しいストレージボリュームを追加します： <db-instance-name> 、 <region> 、 <volumename> 、 <storagetype> 、および <value> を適切な値で置き換えてください。 この例では、 <volumename> には rdsdbdata2 、 rdsdbdata3 、または rdsdbdata4 を使用してください。 <storagetype> には gp3 または io2 を使用してください。 aws rds-asv modify-db-instance \ --db-instance-identifier --region \ --additional-storage-volumes '[{"VolumeName":"","StorageType":"","AllocatedStorage":}]' \ --apply-immediately Code 追加ストレージボリュームのスケーリング 既存の RDS for SQL Server インスタンスで追加のストレージボリュームをスケールするには、以下の手順を実行してください。この操作は通常ダウンタイムなしで実行されますが、アクティビティが少ない時間帯に実行することをお勧めします。 Amazon RDS コンソールで、 データベース を選択します。 DB インスタンス識別子 で、データベースを選択します。 設定タブ を選択します。 追加のストレージボリューム で、スケールさせるストレージボリュームを選択し、 変更 を選択します。 ストレージボリュームの変更 で、 ストレージタイプ 、 割り当てストレージ 、 プロビジョンド IOPS 、 ストレージスループット に適切な値を選択します。 スケジューリング で、適切な値を選択し、 送信 を選択します 既存のストレージボリュームをスケールするには、AWS CLI を使用します： <db-instance-name> 、 <region> 、 <volumename> を適切な値に置き換えてください。 次の例では、rdsdbdata2 ボリュームの IOPS を 4000 にスケールします。 aws rds-asv modify-db-instance \ --db-instance-identifier --region \ --additional-storage-volumes '[{"VolumeName":"rdsdbdata2","IOPS": 4000}]' \ --apply-immediately Code 追加ストレージボリュームでのデータベースの復元 追加のストレージボリュームでデータベースを復元するには、以下の手順を実行してください。 SQL Server Management Studio で RDS for SQL Server インスタンスに接続します。 新しいクエリ を選択します。 以下のサンプルコマンドを使用して、追加のストレージボリューム上に AdventureWorks2019 という名前のデータベースを復元します。 AdventureWorks2019 からサンプルバックアップをダウンロードできます。 <bucket-name> を適切な値に置き換えてください。 「 ネイティブバックアップと復元を使用した SQL Server データベースのインポートとエクスポート 」を参照してください。このコマンドは、RDS for SQL Server インスタンス上に H と I という名前の追加ストレージボリュームが設定されていることを前提としています。 exec msdb . dbo . rds_restore_database @restore_db_name = 'AdventureWorks2019' , @s3_arn_to_restore_from = 'arn:aws:s3:::/AdventureWorks2019.bak' , @data_file_volume = 'H:' , @log_file_volume = 'I:' SQL 次のコマンドを使用してリストアのステータスを確認してください。 <task_id> を適切な値に置き換えてください。 exec msdb.dbo.rds_task_status @task_id=<task_id>; 復元が正常に完了するまで待機してください。物理ファイルの場所を確認するには、以下のコマンドを使用してください。 Use AdventureWorks2019 GO select * from sys . database_files SQL 追加ストレージボリュームの削除 インスタンスの追加ストレージボリュームは、使用されていない場合にのみ削除でき、 D:\ ドライブは削除できません。既存の RDS for SQL Server インスタンスの追加ストレージボリュームを削除するには、以下の手順を実行してください： Amazon RDS コンソールで、 データベース を選択します。 DB 識別子 で、データベースを選択します。 設定タブ を選択します。 追加のストレージボリューム で、削除するストレージボリュームを選択し、 削除 を選択します。 ストレージボリュームの削除 ポップアップウィンドウで、削除と入力し、 削除 を選択します。 または、以下の AWS CLI コマンドを使用して、RDS for SQL Server インスタンスの既存のストレージボリュームを削除します： <db-instance-name> 、 <region> 、 <volumename> を適切な値に置き換えてください。 aws rds-asv modify-db-instance \ --db-instance-identifier --region \ --additional-storage-volumes '[{"VolumeName":"", "SetForDelete": true}]' \ --apply-immediately Code クリーンアップ 不要なコストの発生を避けるため、作成した不要になったボリュームは、前のセクションの手順に従って削除してください。 結論 この投稿では、Amazon RDS for SQL Server インスタンス向けの追加ストレージボリューム機能を紹介し、実用的な実装シナリオを実演しました。追加ストレージボリュームのプロビジョニング、削除、管理のプロセスを説明し、ストレージアーキテクチャを最適化するためにこれらのボリュームにデータベースを復元する方法を示しました。追加ストレージボリュームは、ワークロードタイプ別にデータを整理する柔軟性を提供し、専用の IOPS 割り当てによってパフォーマンスを向上させ、高可用性と耐久性を維持しながらストレージを独立してスケールすることができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Minesh Chande Minesh は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。彼は様々な業界のお客様が SQL Server ワークロードを設計し、Amazon RDS や Amazon RDS Custom などのマネージドデータベースプラットフォームに移行し、最適化することを支援しています。

本記事は 2026 年 1 月 27 日 に公開された「 Strategies for upgrading Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL from version 13 」を翻訳したものです。 本記事では、2026 年 2 月 28 日にスタンダードサポートが終了する PostgreSQL バージョン 13 からのアップグレードを計画する方法をご紹介します。アップグレードの主なメリット、考慮すべき破壊的変更点、選択可能な複数のアップグレード戦略について説明します。 Amazon Aurora PostgreSQL 互換エディション と Amazon Relational Database Service (Amazon RDS) for PostgreSQL バージョン 13 の標準サポートは、2026 年 2 月 28 日に終了します。 これらの更新により、アプリケーションの互換性に影響する変更が導入される可能性があります。アップグレードには慎重な評価が必要ですが、最新のリリースにはより優れた機能、パフォーマンス、セキュリティが備わっています。最大の利点を得つつ、最小限の混乱で済むよう、メジャーバージョンを新しいものにアップグレードする前に、十分に計画と検証を行ってください。 詳細なアップグレード手順については、 Amazon Aurora PostgreSQL 互換 、および Amazon RDS for PostgreSQL の公式ドキュメントを参照してください。 Amazon Aurora PostgreSQL 13.x end of standard support is February 28, 2026 Amazon RDS for PostgreSQL 13.x end of standard support is February 28, 2026 PostgreSQL の新しいバージョンの主な利点 より新しい PostgreSQL バージョンにアップグレードすると、データベースのパフォーマンスが向上し、新しい機能が追加されます。このセクションでは、新しい PostgreSQL バージョンで導入された機能の一部を紹介します。 パフォーマンスの向上 新しいバージョンでは、次のようなパフォーマンス向上が提供されています: 緊急バキュームモード (v14+) – 古い行バージョンを積極的に管理することで、致命的なトランザクション ID の周回を防ぐのに役立ちます I/O パフォーマンスの向上 (v17) – 強化された WAL 処理により、 最大 2 倍の書き込みスループットを提供 します クエリ最適化 (v17+) – B ツリーインデックスを使用した IN 句や、並列 BRIN インデックスビルドの性能が向上しています メモリ効率 (v17) – 新しいバキュームのメモリ構造は、 最大 20 倍メモリを節約 できます 高度なモニタリングと診断 次の高度な監視および診断機能を活用できます: pg_stat_io (v16+) – I/O オペレーションの詳細な統計情報を提供します pg_wait_events (v17+) – 待機イベントのデータベース内リファレンスをサポートし、マニュアルの参照を不要にします 論理レプリケーションの改善 新しいバージョンでは、以下のような論理レプリケーションの改善が提供されています: フェイルオーバーのサポート (v17+) – プライマリからスタンバイサーバーへの論理レプリケーションスロットを自動的に同期できます スロットの移行 (v17+) – 論理レプリケーションスロットを pg_upgrade 経由で移行できるため、アップグレードが簡単になります パラレル適用 (v16+) – この機能では、複数のバックグラウンドワーカープロセスを使用してデータを直接ターゲットテーブルに書き込みます 行フィルタリング (v15+) – レプリケーションするデータを細かく制御できます 開発者エクスペリエンス 新しいバージョンでは、開発者エクスペリエンスが向上しています: JSONB の添字 (v14+) – JSONB データにアクセスおよび変更するための直感的な構文 SQL/JSON JSON_TABLE (v17+) – JSON データをリレーショナルテーブルに変換する機能 クエリパイプラインモード (v14+) – 高遅延接続の場合のネットワーク遅延の削減 セキュリティの強化 以下のセキュリティ強化機能にアクセスできます: pg_read_all_data および pg_write_all_data ロール (v14+) – 読み取り/書き込みアクセス制御の簡素化 pg_maintain ロール (v17+) – ユーザーがデータベースのメンテナンスタスクを実行できるようにする (v15+) – public スキーマに対する PUBLIC ロールの作成権限の削除 Amazon Aurora PostgreSQL 互換 – Aurora 最適化読み取り Amazon Aurora PostgreSQL 互換ユーザーの方は、v14.9+、v15.4+、v16.1+ およびそれ以降のバージョンにアップグレードすることで、より多くの パフォーマンス最適化 を活用できます。 Aurora Optimized Reads は、大規模データセットに対して最大 8 倍高速なクエリレイテンシと最大 30% のコスト削減を実現します。Aurora Optimized Reads は次の 2 つの機能をサポートしています: 階層型キャッシュ – Aurora I/O 最適化クラスターでは、DB インスタンスのキャッシュ容量を最大 5 倍まで拡張できます 一時オブジェクト – ローカル NVMe ストレージを使用すると、高度なクエリの待ち時間が最大 2 倍高速になります PostgreSQL v13 の非推奨: カタログビューの変更とアップグレードの利点 (v14-v17) PostgreSQL v13 から新しいバージョンにアップグレードすると、アプリケーションに影響を与える可能性のある変更が導入されることがあります。このセクションでは、システムカタログと設定パラメータに関連する変更点を説明します。 システムカタログビューの変更 以下の表は、PostgreSQL v17 の変更点をまとめたものです。 変更タイプ カラム名 アクション 備考 pg_stat_bgwriter から削除 buffers_backend 削除 – pg_stat_bgwriter から削除 buffers_backend_fsync 削除 – 新しいビュー pg_stat_checkpointer 作成 checkpointer の統計情報を background writer から分離 新しいビュー pg_wait_events 作成 待機イベントの情報 次の表は、pg_stat_progress_vacuum カラムの名称変更の概要をまとめたものです。 変更タイプ 旧名称 新名称 説明 名称変更 max_dead_tuples max_dead_tuple_bytes カラムの名称を変更 名称変更 num_dead_tuples dead_tuple_bytes カラムの名称を変更 新規カラム – indexes_total 新しいカラムを追加 新規カラム – indexes_processed 新しいカラムを追加 新規カラム – dead_tuple_bytes 新しいカラムを追加 次の表は、追加のカタログ変更の概要をまとめたものです。 ビュー/テーブル 変更タイプ 旧名称 新名称 説明 pg_database 新しいカラムの追加 – dathasloginevt 新しいカラムを追加 pg_database カラムの名称変更 daticulocale datlocale カラムの名称を変更 pg_collation カラムの名称変更 colliculocale colllocale カラムの名称を変更 次の表は、変更されたシステムビューの概要です。 ビュー名 追加された新しいカラム pg_replication_slots failover、synced、invalidation_reason、inactive_since pg_stat_progress_copy tuples_skipped pg_stat_subscription worker_type pg_stats range_length_histogram、range_empty_frac、range_bounds_histogram pg_subscription subfailover 次の表は、PostgreSQL v14 のシステムカタログの変更点をまとめたものです。 ビュー名 変更タイプ カラム名 備考 pg_stat_activity 新規カラム query_id compute_query_id パラメータが必要 pg_stat_statements 新規カラム toplevel 新しいカラムを追加 重要なパラメーター関連の変更点 PostgreSQL v14 におけるパラメータ関連の変更点を以下の表にまとめました。 変更タイプ パラメータ名 説明/注意事項 新規 compute_query_id クエリ識別子の計算を制御 新規 client_connection_check_interval クエリ実行中の切断チェック間隔を設定 新規 idle_session_timeout トランザクション中でない、指定時間以上アイドル状態のセッションを終了 新規 default_toast_compression 圧縮可能な値のデフォルトの圧縮方式を設定 新規 vacuum_failsafe_age 周回問題を回避するために VACUUM がフェイルセーフを起動する年代 新規 huge_page_size 要求する huge page のサイズ 削除 operator_precedence_warning 完全に削除 削除 vacuum_cleanup_index_scale_factor 削除 (v12 で非推奨化) 変更タイプ パラメータ名 旧値 新値 説明/備考 デフォルト値の変更 password_encryption md5 scram-sha-256 パスワード暗号化のデフォルト値を変更 PostgreSQL v15、v16、v17 におけるパラメータ関連の変更点を以下の表にまとめました。 バージョン 変更タイプ パラメータ名 説明/注意事項 PostgreSQL 15 拡張 wal_compression 新しいアルゴリズム: zstd、lz4 をサポート PostgreSQL 15 新規 wal_decode_buffer_size WAL デコーディングのバッファサイズ PostgreSQL 16 新規 vacuum_buffer_usage_limit バキューム中のバッファ使用量を制限 PostgreSQL 16 新規 logical_replication_mode 論理レプリケーションの動作を制御 PostgreSQL 17 新規 sync_replication_slots レプリケーションスロットの同期を有効化 アップグレード戦略のオプション Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL データベースをアップグレードする方法は複数あります: インプレースアップグレード – このアップグレード方法は、 AWS Command Line Interface (AWS CLI) または AWS Management Console を使用して実行できます。インプレースアップグレードには、データベースのサイズに比例したダウンタイムが必要です。まずスナップショットをアップグレードして、正確な所要時間をテストしてください。この方法は、ダウンタイムを許容でき、より簡単な管理を好むワークロードに適しています。 Amazon RDS ブルー/グリーンデプロイメント – Amazon RDS ブルー/グリーンデプロイメントは、PostgreSQL の論理レプリケーションを使用して 2 つの同期された環境を維持します。Amazon RDS のワンクリックアップグレードを使ってグリーン (ステージング) 環境をアップグレードし、アプリケーションをしっかりとテストしてから、ほとんどダウンタイムなしに本番トラフィックを切り替えることができます。このメソッドはコンソールまたは AWS CLI を使って簡単に実装できますが、DDL 変更はレプリケートされず、レプリケーションプロセスを中断する可能性があることに注意が必要です。 論理レプリケーション – Amazon Aurora PostgreSQL 互換および Amazon RDS for PostgreSQL は、pglogical を通じた論理レプリケーションをサポートしています。このプロセスには、パブリッシャーデータベースの初期スナップショットを作成し、それをサブスクライバーにコピーし、その後リアルタイムの変更を継続的にレプリケートすることが含まれます。この方法は、ダウンタイムを最小限に抑えつつ継続的なレプリケーションを提供しますが、初期設定が複雑で、大規模なデータベースの同期に時間がかかります。論理レプリケーションでは、DDL、シーケンス、ラージオブジェクトの操作をレプリケートできません。 AWS Database Migration Service (AWS DMS) – AWS DMS は、ソースおよびターゲットデータベースとして Amazon Aurora PostgreSQL 互換および Amazon RDS for PostgreSQL をサポートし、変更データキャプチャー (CDC) 機能も備えています。AWS DMS を使えば、ダウンタイムを最小限に抑えつつ継続的なレプリケーションが可能ですが、一部のデータ型 (timestamp with time zone など) をサポートしておらず、移行期間中に追加コストがかかります。 Amazon RDS for PostgreSQL データベースまたは Amazon Aurora PostgreSQL データベースのアップグレードに関する詳細情報については、 Upgrade your Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL database, Part 1: Comparing upgrade approaches を参照してください。各アプローチの長所と短所について説明しています。 アップグレードの準備 アップグレードする前に、以下の操作を行う必要があります: 現在のデータベース構成を確認する ステージング環境でアップグレードプロセスをテストする アプリケーションの互換性を検証する 包括的なバックアップ戦略を作成する すぐにアップグレードが実行できない場合、 Amazon RDS Extended Support では、最大 3 年間にわたるセキュリティパッチとバグ修正を提供しています。RDS Extended Support は、Amazon Aurora PostgreSQL 互換および Amazon RDS for PostgreSQL の主要バージョンについて、標準サポート終了日から最大 3 年間、重要なセキュリティ修正とバグ修正を提供するための有料サービスです。経過年数に応じて価格が上がります。RDS Extended Support の期間を賢明に活用して、データベースとアプリケーションの適切なアップグレードパスを見つけることができます。これにより、本番環境でのアップグレードプロセスを効率化できます。 結論 PostgreSQL v13 からアップグレードすると、大幅なパフォーマンス向上、より優れたセキュリティ機能、より効率的な運用が可能になります。 詳細な技術ガイダンスについては、公式の AWS ドキュメントを参照し、複雑な移行シナリオについては AWS サポートに相談することをお勧めします。 AWS エンタープライズサポート をご利用の場合、テクニカルアカウントマネージャー (TAM) が、アップグレードジャーニー全体にわたって専門的なガイダンスを提供できます。TAM は、AWS の専門家とつなぐことができ、スムーズなアップグレードプロセスをサポートするためのリソースを提供します。 著者について Sachin Murkar Sachin は、AWS のクラウドサポートデータベースエンジニアであり Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL に関する専門家です。太平洋岸北西部地域を拠点とし、Sachin は Amazon RDS と Aurora に関する専門知識を活かして、お客様の AWS データベースソリューションの最適化を支援することに注力しています。 Abhimanyu Tomar Abhimanyu は、AWS のシニアデータベーススペシャリストテクニカルアカウントマネージャーです。また、Amazon Aurora インフラストラクチャ、Amazon RDS for PostgreSQL、および Amazon Aurora PostgreSQL に関する専門家でもあります。ソリューションアーキテクトプロフェッショナルを含む 6 つの AWS 認定資格を保有しています。エンタープライズのお客様が AWS 上でデータベースを最適化できるよう支援し、クラウド移行や技術的改善に関する専門的なガイダンスを提供しています。 Niraj Jani Niraj は現在テクニカルアカウントマネージャーとして勤務しており、以前はクラウドサポートエンジニアを務めていました。Amazon RDS および Amazon Aurora PostgreSQL の専門家であり、太平洋岸北西部地域を拠点としています。Niraj は、お客様が RDS および Aurora クラスターのパフォーマンスを最適化できるよう支援し、幅広い技術的問題のトラブルシューティングをサポートしています。

この記事は Measuring the accuracy of rule or ML-based matching in AWS Entity Resolution (記事公開日 : 2025 年 9 月 29 日) を翻訳したものです。 エンティティマッチングのルールセットやモデルが実際に十分な精度を持っているかどうか、どのように判断すればよいでしょうか？複数のアイデンティティプロバイダーを評価する場合でも、独自のマッチングルールを構築する場合でも、企業は達成したい明確な精度レベルの基準と、異なるアプローチを客観的に測定・比較するためのフレームワークを確立する必要があります。アイデンティティプロセスを客観的に測定しない企業は、実装期間を数週間、場合によっては数ヶ月も延長してしまい、手順を繰り返したり、精度測定の手法に高コストな変更を加えたりすることになります。 本記事では、 AWS Entity Resolution の既存機能である独自の機械学習 (ML) アルゴリズムを使用してモデルの精度をテストするアプローチについて説明し、実演します。AWS Entity Resolution は、複数のアプリケーション、チャネル、データストア間に保存された関連する顧客、製品、ビジネス、またはヘルスケア記録のマッチング、リンク、拡張を支援します。また、独自のデータまたは合成オープンソースデータセットを使用して結果を再現するために必要なすべてを提供します。 このフレームワークを使用することで、マッチングの精度を迅速に評価する方法を提供します。このプロセスは、ベンチマークを試みているあらゆるエンティティマッチングプロセスに適用できます。 精度が重要な理由 まず、精度とは何を意味するのでしょうか？本記事での精度とは、同一人物に属する記録を正しく識別し、かつ異なる人物の記録を誤ってマッチングしない頻度を指します。つまり、完全に正確なソリューションは、同一人物に属するすべての重複記録をマッチングし、断片を見逃すことなく、他の人物に属する記録に余分なデータをマッチングすることもありません。 これは直感的な概念ですが、一貫した測定は困難です。多くの企業が顧客データの重複排除・統合プロジェクトに着手する際、真陰性と真陽性を正確に測定する一貫した方法論や指標を持っていません。また、多くの企業は、顧客データで発生する複雑なエッジケースを捉える信頼できる個人情報データセットも不足しています。 100% クリーンなデータ、または十分に小さなサンプルセットで精度指標 100% を達成することは可能です。しかし、実世界のデータやより大きなデータボリュームでは、真の曖昧性を持つ無数のエッジケースが存在するため、100% の精度でマッチングすることは現実的ではありません。したがって、企業は不可能な目標を追い求める無限の実装サイクルに陥らないよう、精度について、測定可能な閾値を設定する必要があります。 今日、企業はこれまで以上に多くの断片化したデータを受け取っています。モバイルアプリのタップ、オンラインクリック、認証セッションのすべてが、企業が消費者行動を理解し、体験をパーソナライズし、運用を最適化するのに役立つデータを生成します。このデータを顧客の統一ビューにまとめることができる企業は、これらの洞察を使用してより良いパーソナライズされた体験を提供できます。また、より情報に基づいた製品、マーケティング、販売の意思決定を行うこともできます。 データからより多くの価値を引き出すことに焦点を当てている企業には、選択できるエンティティマッチングツールやサービスが幅広くあります。しかし、企業はしばしばソリューションの評価と実装で数ヶ月、場合によっては数年間停滞してしまいます。 最初の障害の一つは、アイデンティティマッチングフレームワークとアプローチを評価するための堅牢で一貫したフレームワークが不足していることです。どのアイデンティティマッチング手法が自社データに最も適しているか、企業はどう判断すればよいのでしょうか？精度に関する利害関係はますます高くなっています。顧客は、頻繁に利用するブランドや企業によりパーソナライズされた体験を期待しています。精度のベンチマークも、業界やユースケースに基づいて企業ごとに異なります。 アイデンティティ解決プロセスが特定のニーズに対応していることを企業が信頼するためには、本番データで実際に見られるエッジケースを含む信頼できるデータのベンチマークを作成し、顧客データを収集するあらゆるシステムから受け取る記録の種類に基づいて精度を定義する必要があります。 正解データセット (グラウンドトゥルース) マッチングプロセスの精度を評価する最も広く受け入れられている方法は、プロセスの結果を手動で注釈付けされた正解データセット (真実セットとも呼ばれる) と比較することです。AI における正解データセットとは、事実として知られているデータを指し、モデル化されているシステムの期待されるユースケースの結果を表します。 このユースケースでは、正解データセットは、人間が手動でレビューし、マッチングすべきかどうかを注釈付けした記録ペアの小さなサブセットです。正解データセットは大きくある必要はありませんが、データで頻繁に発生するユースケースの代表的なセットを含むのに十分な大きさである必要があります。 ただし、正解データセットには個人識別情報 (PII) が必要であるため、企業は概念実証でそれらを共有または使用することについて慎重である必要があります。また、必要なすべてのセキュリティプロトコルが整っていることを確認する必要があります。正解データセットは、他のベンチマークデータセットと比較して、より良い再現可能な結果を得ることができます。 アイデンティティ解決精度測定の課題 顧客の単一ビューの価値は、そのデータが表現しようとしている現実世界をどれだけ忠実に反映しているかにほぼ依存しています。しかし、個々の記録のみを見ている場合、精度の評価基準が一定せず、変動してしまう可能性があります。企業は、アイデンティティマッチングのルールを構築したりアルゴリズムを使用したりする際に、明確な精度の閾値を持つ必要があります。そうでなければ、修正と変更の無限のプロセスに陥ってしまいます。これらの閾値は顧客によって異なります。 例えば、同じ業界の 2 つの企業が、データを収集する場所のコンテキストに基づいて異なる精度の閾値を設定する必要がある場合を見てみましょう。2 つの異なる小売業者、企業 A と B を考えてみます。 企業 A は、取引イベントとロイヤルティプログラムから顧客データを収集する実店舗の食料品小売業者です。これらの取引は、現金が使用された場合はデータがないか、世帯内で共有されたり企業によって使用されたりする可能性のあるクレジットカードトークンを使用します。さらに、カードベースのロイヤルティプログラムを通じてロイヤルティデータを収集する場合、空白、不完全なデータ、または複数の異なる人々に関連付けられた多くの共有住所と固定電話データを持つカードがある可能性があります。新しいカードや共有されたカードを提示することでロイヤルティ特典を受けることができるため、顧客が正確なデータを共有するインセンティブはありません。 企業 A は、不完全な名前データ、クレジットカードトークン、高い割合で共有されるデータを含む記録ペアでマッチングをテストする必要があります。さらに、顧客がデータを共有する方法に基づいて企業 A が可能な最も正確な解決レベルであるため、グループ化のための世帯レベルのマッチングにのみ関心があります。 これを、ウェブサイトですべての取引を行うオンライン小売業者である企業 B と対比してみましょう。ほぼすべての顧客がメールアドレスで認証し、閲覧行動に関連付けられたプロファイルを持っています。顧客は実際に購入した商品を受け取るために、正確な住所、名前、メールアドレスの値を共有する必要があります。同じ世帯内の個人でも、個人のアカウントやメールアドレスを通じて領収書を受け取り、返品を開始する方が迅速であるため、自分の名前とメールアドレスで購入する可能性が高くなります。 実店舗小売業者である企業 A とは異なり、企業 B は個人レベルでユーザーをマッチングできます。配送先住所と電話番号が共有される可能性があるため、マッチングする前により高い割合の共有属性を要求することができます。しかし、他の多くの信頼できるデータが世帯のメンバーや重複するデータを持つユーザーを区別することができます。 両方の小売業者は、自社のデータに存在するシナリオを反映し、許容可能なマッチングの独自の閾値を持つ独自の正解データセットを作成すれば、最良の結果を得られるでしょう。このセットには、まとめるべき記録の断片 (真陽性) と、多くの特徴を共有するが分離しておく必要がある記録 (真陰性) の両方のテストケースを含める必要があります。マッチングに使用するために、これらのテストケースは、記録がマッチングすべきかどうかを示す正解データセットとして注釈付けされる必要があります。 データサイエンスコミュニティでは、精度を測定する最も標準的な方法は、F1 スコアと呼ばれる指標です。 F1 スコア は、正解データセットに対するモデルパフォーマンスの 2 つの主要な側面である精密度と再現率を平均化した指標です。 エンティティマッチングモデルのコンテキストでは、精密度は、正解データセットでマッチングされていない 2 つの記録を誤ってまとめてしまう偽陽性マッチをモデルがどの程度防げるかを指します。この文脈での再現率は、正解データセットでグループ化されている記録をモデルがどの程度正しくまとめることができるかを指します。したがって、正解データセットには、まとめるべき記録ペアと、類似性を共有するが一緒に属さない記録ペアの両方が含まれている必要があります (図 1 参照) 。 図 1 – 再現率と精密度を定義する表 F1 スコアは、精密度と再現率の調和平均として定義され、次のように計算されます : F1 スコア = 2 × [(精密度 × 再現率) / (精密度 + 再現率)] 精密度は、真陽性 (正しいマッチ) を、真陽性と偽陽性 (不正なマッチ) の合計で割った比率です。再現率は、真陽性を、真陽性および偽陰性 (見逃されたマッチ) の合計で割った比率です。F1 スコアは 0 から 1 の範囲で、値が高いほど精密度と再現率のバランスが良いことを示します。このバランスは、異なる業界が精密度または再現率を異なって優先するため重要です。例えば、ヘルスケア業界はしばしば偽陽性を最小化することを目指し (精密度を重視) 、広告業界は真陽性を最大化することに焦点を当てます (再現率を重視) 。 データ評価のウォークスルー 精度をテストするために顧客が使用できる公開データセットはそれほど多くありません。これらの分析でよく使用されるデータセットの一つが、オハイオ州有権者ファイルです。 オハイオ州有権者ファイル は、人物マッチングのためのよく知られた公開データセットです。オハイオ州の有権者情報から名前、住所、生年月日を含む 105,000 件の記録が含まれています。 オハイオ州有権者ファイルは、実際のデータを含むため、開発者による多くのエンティティマッチングソリューションで最も一般的に使用される正解データセットです。しかし、実際の顧客データの代理としての有用性を制限するいくつかの欠点があります。電話番号とメールフィールドが不足しており、正規化されていない郵便住所などのよくあるデータ品質問題がなく、記録が非常に完全である傾向があります。 これらのより複雑でデータ品質の低い例に対応するため、AWS Entity Resolution Data Science チームは、こうした困難なエンティティ解決シナリオをより忠実に再現する新しい合成データセットを開発し、オープンソース化しました。これは、 BPID: A Benchmark for Personal Identity Deduplication と呼ばれています。BPID は、名前、メール、電話、住所、生年月日フィールドにわたる複雑なパターンを持つ 2 万件の合成記録を含む、はるかに困難なデータセットです。BPID は、世界有数の自然言語処理会議の一つである Empirical Methods in Natural Language Processing (EMNLP) 2024 で発表されました。 以下の例では、AWS Entity Resolution の機能である機械学習ベースのマッチングモデルの精度を測定する手順を実演します。BPID からのオープンソースの正解データセットを使用します。 前提条件 AWS アカウント データマッチング概念の基本的理解 分析実行のための Jupyter Notebook または類似環境 Python とデータ処理ライブラリの知識 1. データのダウンロード まず、テストで使用するデータをダウンロードする必要があります。BPID データセットをダウンロードして解凍します。精度評価には matching_dataset.jsonl を使用します。以下は、BPID データセットからのペアの例です： {"profile1": {"fullname": "corrie arreola", "email": ["c_orrie@bizdev.org", "c0rri3@gov.us"], "phone": ["03 1284418523"], "addr": [], "dob": "1953 11 09"}, "profile2": {"fullname": "arreola corrie", "email": ["arreola_2023@gmail.com"], "phone": [], "addr": ["45434 11478 jenny road tx 75155 0411 falconer", "100209 57 summer drive hollywood"], "dob": "09 nov 1953"}, "match": "True"} {"profile1": {"fullname": "elroy warner", "email": ["e.l.roy@private-domain.info"], "phone": [], "addr": ["21480 miser road seal cove tx 75109 0784 united states of america"], "dob": "2007 09 26"}, "profile2": {"fullname": "charlee warner", "email": ["charlee.smith@biz-tech.com"], "phone": [], "addr": ["21480 miser rd j646 seal cove tx 75109"], "dob": "09 2007"}, "match": "False"} 2. テストと正解データセットの前処理 テストデータから 2 つのデータセットを準備します。1 つは入力用、もう 1 つはマッチング後の精度測定用の正解データセットです。 matching_dataset.jsonl をプロセッサに必要なスキーマに変換する必要があります。AWS Entity Resolution で使用するためにこのデータを準備するには、まずローカルまたは仮想環境にデータを読み込む必要があります。 import json import pandas as pd #BPIDデータセットは zenodo.org/records/13932202 を通じて公開されています raw_data_path = "./data_release/matching_dataset.jsonl" raw_data = [json.loads(line) for line in open(raw_data_path).readlines()] 次に、入力レコードをフラット化・変換して、AWS Entity Resolution で読み込める形式にします。ラベルは以下に概説されているように別のファイルに保存されます： max_length_mapping = {"email": 0, "phone": 0, "addr": 0} for data_i in raw_data: for field in max_length_mapping: max_length_mapping [field] = max( max_length_mapping[field], len(data_i["profile1"][field]), len(data_i["profile2"][field]) ) print(f"max_email_length={ max_length_mapping['email']}") print(f"max_phone_length={ max_length_mapping ['phone']}") print(f"max_addr_length={ max_length_mapping['addr']}") profile_list = [] name_list = [] dob_list = [] email_list = {f"email_{i+1}": [] for i in range(max_length_mapping["email"])} phone_list = {f"phone_{i+1}": [] for i in range(max_length_mapping["phone"])} addr_list = {f"addr{i+1}": [] for i in range(max_length_mapping["addr"])} 次に、以下のスクリプトを実行し、精度スコア計算用にラベルを分離・準備します： label_list = [] for i, data_i in enumerate(raw_data): p1, p2 = data_i["profile1"], data_i["profile2"] #ペアのラベルを保存 label_list.append({"profile_id_1":f"pair{i}_0", "profile_id_2":f"pair{i}_1", "label": data_i["match"]}) #プロファイルを追加 for p in [p1, p2]: p_json = {"profileid":f"pair{i}_0", "fullname":p["fullname"], "dob":p["dob"]} for attr in ["email", "phone", "addr"]: for j in range(1, max_length_mapping[attr]+1): p_json[f"{attr}_{j}"] = p[attr][j] if j<len(p[attr]) else "" profile_list.append(p_json) 次に、以下を使用して処理されたプロファイルとラベルを json ファイルとして保存します： # プロファイルを json ファイルに保存 f_out = open("./data_release/BPID_matching_profiles_processed.jsonl", "w") for p in profile_list: f_out.write(json.dumps(p)+ "\n") f_out.close() # ラベルを json ファイルに保存 f_out = open("./data_release/BPID_matching_label.jsonl", "w") for label_pair in label_list: f_out.write(json.dumps(label_pair)+ "\n") f_out.close() この前処理を実行した後、プロファイルデータ ( BPID_matching_profiles_processed.jsonl ) は以下のようになります： {"profileid": "pair0_0", "fullname": "corrie arreola", "dob": "1953 11 09", "email_1": "c0rri3@gov.us", "email_2": "", "email_3": "", "phone_1": "", "phone_2": "", "phone_3": "", "addr_1": "", "addr_2": "", "addr_3": "", "addr_4": "", "addr_5": ""} {"profileid": "pair0_1", "fullname": "arreola corrie", "dob": "09 nov 1953", "email_1": "", "email_2": "", "email_3": "", "phone_1": "", "phone_2": "", "phone_3": "", "addr_1": "100209 57 summer drive hollywood", "addr_2": "", "addr_3": "", "addr_4": "", "addr_5": ""} 付随するラベルファイル ( BPID_matching_label.jsonl ) は以下のようになります： {"profile_id_1": "pair0_0", "profile_id_2": "pair0_1", "label": "True"} {"profile_id_1": "pair1_0", "profile_id_2": "pair1_1", "label": "False"} 3. マッチングワークフローの実行 テストデータが変換されたら、評価予定のワークフローに対して マッチングワークフロー を実行します。 目標は、入力データセット内の任意の 2 つの記録が同一人物に属するかどうかを肯定的または否定的にマッチングできるマッチング結果を取得することです。この手順はサービスによって異なります。 最後に、AWS Entity Resolution マッチングワークフローを実行します。以下は、AWS Entity Resolution からの出力例です： InputSourceARN,ConfidenceLevel,addr1,addr2,addr3,addr4,addr5,dob,email1,email2,email3,fullname,phone1,phone2,phone3,profileid,RecordId,MatchID arn:aws:glue:us-west-2: :table/yefan-bpid-benchmark/input,0.75296247,cookson tx 75110,,,,,2003 7,,,,,26806124715,3236000026,,pair1622_1,pair1622_1,6d08ce607181460584e2436e66660b2300003566935683247 arn:aws:glue:us-west-2::table/yefan-bpid-benchmark/input,0.75296247,cookson tx 75110,,,,,2003 07 10,yong123@business-domain.co.uk,,,yong stearns,6807159172,6806124715,,pair1622_0,pair1622_0,6d08ce607181460584e2436e66660b2300003566935683247 4. F1 スコアの計算 マッチング結果を取得した後、生データのラベル情報とマッチング結果を使用して F1 スコア指標を計算できます。データセット matching_dataset.jsonl 内の各ペアには、マッチまたは非マッチのラベルがあります。各ペアについて、マッチング結果でラベルと一致するかどうかを確認します。その後、このペアを 4 つのカテゴリのいずれかに割り当てます： 真陽性 (TP) ：ラベルとマッチング結果の両方がマッチを示唆 偽陽性 (FP) ：ラベルは「非マッチ」だがマッチング結果はマッチ 真陰性 (TN) ：ラベルとマッチング結果の両方が非マッチを示唆 偽陰性 (FN) ：ラベルは「マッチ」だがマッチング結果は非マッチ これら 4 つのタイプの数を取得した後、以下を計算できます： 精密度 = TP / (TP + FP) 再現率 = TP / (TP + FN) F1 スコア = 2 × [(精密度 × 再現率) / (精密度 + 再現率)] 独自のベンチマークテストの実行 ベンチマークプロセスを実行することで、これらの結果を再現できます。以下は、機械学習ベースマッチングのための AWS Entity Resolution でこのプロセスを実行するために必要な手順とノートブックの概要です。手順とデータは、ルールベースマッチングワークフローまたは他のプロバイダーからのマッチングプロセスの精度を評価するために再利用することもできます。BPID データには実際の顧客 PII が含まれていないため、基礎となる参照グラフを使用するプロバイダーを評価するために使用できます。 アイデンティティ解決プロセスの改善を目指すチームには、以下をお勧めします： 独自の評価のための BPID データセットのダウンロード AWS Entity Resolution の機械学習ベースマッチング機能の探索 ベンダー評価における主要指標としての F1 スコアの検討 結論 企業が顧客データを統合するために使用するルールやアルゴリズムの精度を測定することは非常に困難です。ほとんどの企業は、ベンチマークとなる注釈付き正解データセットを持たず、測定のための一貫した方法論を欠いている可能性があります。 AWS Entity Resolution を使用したアイデンティティ解決サービスの包括的な精度評価の実施方法を実演しました。ベンチマーク手法、オープンソースデータセット、そして読者が精度評価を再現できるステップバイステップガイドを提供しました。 AWS の担当者 に連絡して、お客様のビジネスの加速をどのように支援できるかをご確認ください。 参考資料 AWS Entity Resolution の高度なルールベースファジーマッチングを使用して不完全なデータを解決する 顧客の統一ビューを構築する方法 AWS でのエンティティ解決のためのルール推奨生成に関するガイダンス Travis Barnes Travis は、AWS Entity Resolution のシニアプロダクトマネージャー (テクニカル) として、高度なアイデンティティ解決技術を通じて顧客がデータ価値を最大化できるよう支援しています。アイデンティティとアドテック分野で革新的な製品を構築してきた 10 年以上の経験を持ち、実際のビジネス成果につながる複雑なデータ課題の解決に情熱を注いでいます。 Yefan Tao Yefan は、大規模なエンティティ解決と情報検索システムを専門とするシニア応用科学者です。自然言語処理 (NLP) および関連分野において、堅牢で効果的な機械学習アルゴリズムを開発しています。研究と実用化の橋渡しにおける長年の経験を持ち、効率性と精度の両面で限界に挑戦する複雑なデータガバナンスとアイデンティティの課題解決に注力しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

本記事は、2025 年 8 月 27 日に公開された Empowering educators: How Innovation Sandbox on AWS accelerates learning objectives through secure, cost-effective, and recyclable sandbox management を翻訳したものです。翻訳は Solutions Architect の 北川友稀 が担当しました。 生成 AI がテクノロジーの世界に大きな影響を与えるようになった今、大学や高等教育機関といった Amazon Web Services (AWS) のお客様は、学生にサンドボックス環境を提供し、業界が求める生成 AI の専門知識を身につけることに取り組んでいます。サンドボックスを通じたハンズオン学習により、学生のスキル習得効率が向上したり、新しいアイデアや AWS のサービスを簡単に検証することができます。 しかし、数千人の学生向けにサンドボックス環境の AWS アカウントを大規模に作成・管理することは困難です。本記事では、 Innovation Sandbox on AWS を使用して一時的なサンドボックス環境の管理を効率化し、イノベーションの推進、スキル構築、技術革新に集中できる方法を紹介します。Innovation Sandbox on AWS はすべての AWS のお客様 (教育機関やあらゆる規模の企業を含む) に適用できますが、本記事では教育機関の視点に焦点を当てます。 お客様の課題 教育機関で数百のサンドボックス環境を管理するクラウド管理者は、セキュリティ、運用効率、コスト管理、アカウントの再利用に関する教育機関の要件を満たすようにサンドボックスを設定する必要があります。お客様から寄せられる一般的な課題は次のとおりです。 設定の複雑さ: 大規模なサンドボックス環境の管理では、本番環境を正確に再現するために膨大な AWS サービスの利用とそれらの設定が必要となり、設定が複雑になります。 コスト管理: サンドボックス利用者が誤ってコストのかかるリソースをデプロイしたり、必要以上に長く実行したままにすると、予期しない費用が発生します。クラウド管理者はサンドボックスの使用を管理するために、継続的な監視とコスト管理措置を実装する必要があります。 セキュリティとガバナンス: サンドボックス利用者には実験の柔軟性が必要ですが、広範なアクセスを許可すると、設定ミス、データ漏洩、不正アクセスが発生する可能性があります。厳格な AWS Identity and Access Management (IAM) ユーザーアクセスの実装と、大規模なセキュリティポリシーの適用が必要です。 一時的な使用の管理負荷: サンドボックス環境は短期利用が多いですが、サンドボックスアカウントの作成、設定、削除には数週間かかり、戦略的な業務にかけられる時間が少なくなります。 Innovation Sandbox on AWS: サンドボックス環境管理における革新的ソリューション Innovation Sandbox on AWS は、AWS 上でのイノベーションの取り組みを加速させる AWS ソリューションです。安全でコスト効率に優れ、再利用可能な一時的なサンドボックス環境の管理を可能にします。これにより、技術的な負担を最小限に抑え、管理にかかる時間を大幅に削減しながら、学生、研究者、教員が AWS で自由に実験できる環境を提供します。 Innovation Sandbox on AWS は管理者がサンドボックス環境のライフサイクル全体をセットアップおよび管理する方法を効率化します。効率化はセキュリティポリシー、承認ワークフロー、支出管理メカニズム、アカウントリサイクル設定の実装により行われており、それらの機能は直感的なユーザーインターフェイス (UI) を通じて提供されます。Innovation Sandbox on AWS は AWS Organizations を利用するお客様向けに構築されており、既存の AWS Control Tower および Landing Zone セットアップと共に使用することもできます。 教育機関の一般的なユースケース Innovation Sandbox on AWS の一般的なユースケースは次のとおりです。 高等教育のトレーニングラボ: 大学の学部長、教授、教師などの教育者が、一時的なクラウド環境 (教室のラボ、試験など) を作成および管理して学生をトレーニングする 研究開発 (R&D): 大学、カレッジ、高校の教育者が、仮説検証のために管理された環境でクラウドおよび生成 AI の研究実験を実行する ハッカソン: 学部長が学生向けのハッカソンを行うために一時的なサンドボックス環境を必要とする スタッフの新人研修とトレーニング: 教育機関の IT リーダーが、キャンパスの IT および学術スタッフをアップスキリングするためのハンズオン学習と研修を提供する。開発環境や本番環境で構築を開始する前に、AWS サービスと新機能を試し、アプローチを検証できます。 ペルソナとユーザーワークフロー Innovation Sandbox on AWS は 3 つの主要なペルソナ向けに設計されています。 クラウド IT 管理者: サンドボックス環境の管理に関連する数週間の手動設定と運用負荷を排除します。すべてのサンドボックスアカウントでセキュリティポリシー、支出管理、リサイクルメカニズムの実装を自動化することで、クラウド管理者の負担を軽減します。管理者は、前提条件を確認し、AWS Organization にソリューションの AWS CloudFormation テンプレートをデプロイし、AWS IAM Identity Center を通じてユーザーアクセスを設定し、既存の AWS アカウントを登録してサンドボックスアカウントプールを作成することで開始できます。 学術スタッフ : 学術スタッフが学生にハンズオンのクラウド学習体験を提供しやすくします。直感的な UI により、学術スタッフは支出と時間の制限を持つリース（一時的な貸し出し）テンプレートを迅速に作成し、しきい値ベースのアクション (アラート、フリーズ、クリーンアップ) と承認設定を指定できます。学生がサンドボックスリースを受け取り、操作する方法を正確に制御でき、すべてのリースのコストとリース期間の使用状況を監視する機能を備えています。 学生 : 学生は事前定義されたリーステンプレートのコレクションから選択することで、セルフサービス方式で新しいサンドボックスリースを簡単にリクエストできます。リースリクエストが承認されると、学生は割り当てられた AWS アカウントにログインし、実験をすぐに開始できます。AWS サービスを使用したハンズオン体験により、学生が企業にアピールできるポートフォリオを作成することができるため、就職市場で非常に求められている実践的なクラウドスキルを実証できます。学生は、設定された制限に対する予算とリース期間の消費パターンを監視し、アラートを受け取ることができるため、サンドボックスを責任を持って使用できます。このリソース管理とクラウドコスト最適化の経験は、実際のビジネスシナリオを反映しており、就職活動で有利になり、クラウド対応組織での役割に備えることができます。サンドボックス実験を通じて得られた実践的なスキルは、学術的な学習と実務の架け橋となり、学生のキャリアに優位性を与えます。 図 1: Innovation Sandbox on AWS のユーザーワークフロー お客様事例 AWS のお客様が Innovation Sandbox on AWS を通じてイノベーションの取り組みを加速している事例を紹介します。 シェフィールド大学 背景 1905 年に設立されたシェフィールド大学は、英国イングランドに拠点を置く名門の研究重視の公立大学です。世界のトップ 100 大学に常にランクインしており、約 30,000 人の学生が在籍しています。エンジニアリング、科学、医学など、多くの分野で重要な貢献を続けています。 課題 シェフィールド大学は、AWS サンドボックス環境を大規模に管理する上で 2 つの課題に直面していました。既存のサンドボックスアカウントのライフサイクル管理が非効率なため、割り当て後に多くのアカウントが未使用のままとなっており、未使用アカウントのリソース状況の把握が困難で不必要なコストを招いていました。さらに、学術部門は教育と学習のために AWS 環境を必要としていましたが、セキュリティアクセスとコストを適切に制限したアカウントを管理するための技術的専門知識が不足していました。 ソリューション 大学は Innovation Sandbox on AWS をデプロイし、アカウント割り当ての権限を管理スタッフと学術スタッフに移譲しました。サンドボックス使用に伴うリソースの非効率性という最初の課題に対処するため、大学はコスト制限とコース期間に基づいたアカウントリサイクル設定を構成しました。管理スタッフと学術スタッフは UI を活用して、すべてのサンドボックスリースのコストと利用状況を把握し、大学へ報告しました。 Innovation Sandbox on AWS に備わるセキュリティポリシーとコスト管理機能を使用し、大学のニーズに合わせて設定しました。事前定義されたセキュリティポリシーとコスト管理機能を備えた、管理された AWS 学習環境を迅速にセットアップし、教育目標や学部の要件とシームレスに統合することができました。また、コーススケジュールとスタッフのプロジェクトタイムラインの両方に対応する、サンドボックスアカウントの割り当てと解除の自動スケジューリングシステムも開発しました。 成果 Innovation Sandbox on AWS のデプロイにより、IT 効率と部門の自律性が向上しました。 リソース使用率の最適化: 自動化されたアカウント管理を通じてサンドボックス環境の管理プロセスを合理化し、学部全体の使用パターンを明確に可視化しました。 分離されたサンドボックスの安全な使用: このプラットフォームは IT 運用負荷を抑えながらセキュリティ態勢を改善し、非技術スタッフや学術サービスが AWS 機能を独自に活用できるようになりました。 コストガバナンスの確立: 学部の予算を効果的に管理しながら、AWS ツールを教育および学習活動へ統合することを促進しました。 セルフサービスサンドボックス: セキュリティとガバナンス基準を維持しながら、自動化機能を通じて IT 部門の関与が削減されました。 お客様の声 「生成 AI を教え、学生に Amazon Bedrock の使用に慣れてもらうための新しいコースモジュールを構築しました。Innovation Sandbox on AWS を使用することで、セキュリティとコスト管理を備えた AWS アカウントを迅速に展開でき、学生が Amazon Bedrock を安全に利用できるようになりました。導入したモジュールにより、法学部の学生が法律相談クリニック向けに独自の生成 AI 法律エージェントを構築できるようになりました。私たちのビジョンは、生成 AI 法律エージェントを各学期に新しい学生によって改善し、最終的に大学内のすべての法学部の学生、さらには法律業界全体で使用できる新しいエージェント AI 製品を生み出すことです。」 — Ben Orza 氏、シェフィールド大学 IT サービス元リードテクノロジーアーキテクト イーストロンドン大学 背景 イーストロンドン大学 (UEL) は、英国ロンドンのトップランクの公立教育機関であり、160 以上の国籍からなる 40,000 人以上の学生が在籍しています。同大学は、高等教育を通じて社会に良い影響を与えることに焦点を当てています。学生が成功するキャリアを築き、企業が求めるスキルを身につけられるようにすることを使命としています。 課題 UEL の学術部門、特にエンジニアリング・コンピューティング学部は、当初 AWS Academy を活用して基礎的なクラウド教育を提供していました。AWS Academy は、学生にクラウドの基礎を紹介し、クラウドテクノロジーへの関心を喚起する上で効果的でした。しかし、UEL のカリキュラムがより高度なクラウドネイティブおよび AI スキルを重視するように進化するにつれて、大学はより充実した学習環境の必要性を認識しました。 学生は、学期を通じて長期プロジェクトを開発・維持するために、より分離された環境を必要としていました。また、教育者はクラウド技術を授業カリキュラムにより深く組み込むための柔軟な環境を求めていました。さらに、高度な AWS サービスの実践的な経験への需要が高まるにつれて、UEL は、セキュリティを損なうことなく、また中央 IT の運用負荷を増やすことなく、AWS サービスへのより広範なアクセスを提供できるソリューションを必要としていました。 UEL の目標は、AWS Academy が提供する強固な基盤の上に構築し、よりスケーラブルで柔軟な AWS 環境を作成することでした。この AWS 環境は、学生と教員の両方を効果的にサポートし、業界の実践や新しいテクノロジーと密接に連携した実世界の学習体験を可能にする必要がありました。 ソリューション さまざまなオプションを検討した後、UEL はクラウド教育の課題に対処するために Innovation Sandbox on AWS を採用しました。学生と学術チームに、期限付き AWS アカウントへのオンデマンドアクセスを提供しました。大学の IT サービスチームはソリューションをデプロイし、さまざまな分野の数百人の学生をサポートするために 330 を超えるサンドボックスアカウントを迅速にセットアップし、柔軟な学習環境を提供しました。 セルフサービスポータルにより、学生は数分で AWS アカウントのリースをリクエストでき、AWS アカウントの利用開始プロセスが合理化されました。事前定義されたリーステンプレートには、承認要否、リース期間、クリーンアップを設定するためのコントロールが含まれており、効率的なリソース管理ができるようになりました。学術スタッフと IT スタッフは、直感的な UI により技術的な負荷を管理することなく、アカウントとリースの一元的な監視が可能になりました。学術スタッフは、AWS IAM Identity Center との統合を活用して、モジュールの提供、課題、評価のための学生アクセスを管理できました。さらに、Amazon Bedrock などの高度なサービスをサポートし、生成 AI などの最先端テクノロジーのハンズオン実施を可能にしました。 Innovation Sandbox on AWS により、教育チームは単一のログインセッションをはるかに超える実世界の学習体験を設計できるようになりました。Innovation Sandbox on AWS は、UEL のクラウド教育へのアプローチを改善し、学生と教育者の両方により柔軟なプラットフォームを提供しました。 成果 Innovation Sandbox on AWS のデプロイにより、UEL の教育インフラストラクチャと学生体験が向上しました。 永続的な学習環境 : 学生はリースの全期間にわたって AWS 環境を保持し、長期プロジェクトと反復的な開発をサポートします。 教育者のより大きな柔軟性 : クラウドサービスを、選択科目や学際科目を含む、より幅広い授業カリキュラムに組み込むことができるようになりました。 高度なサービスのサポート : 学術スタッフは、IT サービスの介入なしに、Amazon Bedrock、Amazon SageMaker、AWS Lambda などのツールに学生を触れさせることができます。 学生エンゲージメントの向上 : 学生は主体的に取り組めるようになり、クラウド技術をコースワークや研究に実践的に活用できます。 スケーラブルで安全 : 自動クリーンアップ、アカウントリサイクル、ガードレールが実装されているため、リスクや手動の負荷なしに大規模な学生集団をサポートできます。 お客様の声 「Innovation Sandbox on AWS により、学生とスタッフが実験するためのサンドボックス環境の管理を合理化することで、AWS 環境管理者の運用負荷が軽減されました。330 を超えるサンドボックスアカウントを管理しており、サンドボックスのライフサイクル管理が簡素化され、学習要件に必要なさまざまな環境を作成するという学術目標により多くの時間を費やすことができるようになりました。」 — Jordan Richards 氏、イーストロンドン大学 IT サービス部門 AWS ソリューションアーキテクト 「Innovation Sandbox on AWS により、サーバーレスアプリケーション、AI エージェント、マイクロサービスなど、実際の業界のユースケースを反映した学習環境を作成できます。変更のたびに IT を関与させる必要はありません。学生は、コースワークを完了するためだけでなく、実験、イノベーション、研究、さらには起業のためのプラットフォームとして、クラウド環境にアプローチできるようになりました。」 — Gaurav Malik 氏、イーストロンドン大学エンジニアリング・コンピューティング学部教育・体験ディレクター ハノイ工科大学 背景 ハノイ工科大学 (HUST) は、1956 年に設立されたベトナム初の技術系総合大学です。研究、科学、エンジニアリングの卓越性で長年の評判を持つ HUST は、国の産業と技術の進歩を推進する最前線に立ってきました。現在、大学には約 40,000 人の学生がおり、国際化、イノベーション、デジタルトランスフォーメーション、「共有デジタル大学」としての地位確立に焦点を当てた先進的な開発戦略を実施しています。 課題 イノベーションアジェンダの一環として、HUST は銀行セクターのユーザーエクスペリエンスを向上させることを目的とした全国的なハッカソン、HACK TOGETHER 2025 を実施しました。イベントには、学生、開発者、データサイエンティスト、金融プロフェッショナルで構成される学際的なチームが集まりました。24 チームがわずか 2 週間で技術ソリューションを構築およびプロトタイプ化することが予想される中、HUST はいくつかの課題に直面しました。 インフラストラクチャのセットアップ : 各チームに、コアシステムへのリスクなしにソリューションを構築およびテストするための安全で分離された環境を提供する。 スケーラビリティとガバナンス : 適切なセキュリティガードレールと利用ポリシーを実装し、複数のクラウドアカウントを管理する。 コスト管理 : 予算の予測可能性を確保し、クラウドコストの急上昇を抑止する。 運用負荷 : インフラストラクチャの管理に費やす時間を削減し、HUST スタッフがメンタリングとイノベーション支援に集中できるようにする。 ソリューション 課題に対処するため、HUST は AWS と提携して Innovation Sandbox on AWS を実装しました。サンドボックス環境の作成、ガバナンス、自動リサイクルを簡素化するように設計されたソリューションで、次のような機能を備えています。 ユーザーが AWS アカウントをリクエストするための セルフサービスポータル 組み込みのセキュリティと使用管理を備えた 自動サンドボックスリース管理 コストの透明性を実現する コスト上限と監視 リース期限を超えた AWS アカウント内の不要なリソースをクリーンアップして無駄を削減する スケジューリング AWS と協力して、HUST IT チームは数日以内に 24 のハッカソンチームに独自の分離された AWS アカウントを利用させることができました。サンドボックス環境は、自動化されたガバナンスとガードレールで構成されており、参加者はインフラストラクチャの管理やセキュリティと予算の心配をすることなく、自由に実験できました。 成果 Innovation Sandbox on AWS のデプロイにより、HUST のハッカソン実行が効率化されました。 セットアップの高速化: 24 チームの AWS アカウントが数日でセットアップされ、手動プロビジョニングはゼロでした。 安全な実験 : チームは分離された環境で新しいソリューションを構築、テスト、デプロイしました。 イノベーションへの集中 : 参加者は、クラウドのセットアップや権限の処理ではなく、実際の銀行 UX の課題を解決することに時間を費やしました。 コストとリスクの軽減 : 自動化されたガードレールとコスト管理により、超過とポリシー違反が防止されました。 スケーラブルモデル : HUST は、AWS での将来のイノベーションイニシアチブをサポートするための再現可能なモデルを手に入れました。 お客様の声 「Innovation Sandbox on AWS は、HACK TOGETHER 2025 を大規模にホストし、わずか数日で 24 のハッカソンチームへ AWS アカウントを利用可能にする上で重要な役割を果たしました。安全で分離された環境を提供することで、ハッカソンチームが自由に実験でき、組み込みのガバナンスとコスト管理を通じて安心感を得られました。Innovation Sandbox on AWS は、当社のデジタルトランスフォーメーション戦略と完全に一致し、すべての参加者にとって真に革新的なハンズオンの体験を作成するのに役立ちました。」 — Nguyen Binh Minh 氏、ハノイ工科大学デジタル技術経済研究所准教授兼学部長 クラウドイノベーションジャーニーを加速する準備はできていますか? Innovation Sandbox on AWS は、AWS のお客様がセキュリティを維持し、コスト管理を改善し、AWS アカウントの再利用可能性を確保しながら、サンドボックス環境管理を合理化するための強力なソリューションを提供します。学生の学習体験を向上させたい教育機関、開発者の生産性に焦点を当てている企業、イノベーションイニシアチブを推進している組織のいずれであっても、開始は簡単です。 今すぐ AWS Solutions Library にアクセスして Innovation Sandbox をデプロイし、組織のクラウド実験を改善しましょう。詳細については、次をご覧ください。 ドキュメントの詳細な 実装ガイド を参照して、デプロイを開始してください ソリューションの GitHub リポジトリ をご覧ください AWS ソリューションアーキテクトに連絡して、お客様固有のニーズについて話し合ってください 複雑なサンドボックス管理がイノベーションを妨げることのないようにしてください。今すぐ Innovation Sandbox on AWS で、簡素化され、安全で、コスト効率に優れたクラウド実験への第一歩を踏み出しましょう。 Rakshana Balakrishnan Rakshana は AWS のシニアプロダクトマネージャーテクニカルであり、0-to-1 および 1-to-n のクラウドネイティブ製品の設計と提供に関する専門知識を持っています。世界中の数千のお客様がクラウド支出を最適化し、セキュリティ体制を改善し、AWS での生成 AI 価値創造を加速できるようにする製品ポートフォリオを担当しています。Innovation Sandbox on AWS のプロダクトリードとして、コンセプトから立ち上げまでの道のりを先導し、世界的な戦略的成長を推進しました。仕事以外では、ハイキング、ヨガ、アートを楽しんでいます。 Rakshana Balakrishnan Hannah は AWS のグローバル教育向け GTM ビジネスデベロッパーであり、市場投入戦略と実装に焦点を当て、高等教育、研究、EdTech セクターに新しいソリューションを提供しています。AWS での最初の 3 年間は、国際中央政府チームで、税務、福祉、国家安全保障と防衛、エネルギーセクターにわたるグローバルな公共セクターリーダー向けのプログラムを開発していました。世界中でよりアクセスしやすく公平な学習機会を創出するために、教育におけるデジタルトランスフォーメーションを推進することに情熱を注いでいます。 Rakshana Balakrishnan Todd は AWS のクラウド基盤スペシャリストです。お客様がビジネス目標を達成するために、クラウド環境の設計、デプロイ、最適化、スケーリングを支援することに情熱を注いでいます。Todd の情熱には、歴史、障害物レース、妻、3 人の子供、2 匹の犬との思い出作りが含まれます。 Rakshana Balakrishnan Wayne は AWS の EMEA 担当プリンシパルインダストリーソリューションマネージャーであり、金融、教育、製造、地方自治体セクターにわたる 20 年以上の経験を持っています。Wayne はこの経験を活かして、組織がコストを削減し、新しいテクノロジーを活用する最新のビジネスアプリケーションを実装するのを支援しています。

本稿は、JFE スチール株式会社による CPS 開発実行基盤の構築について、これを主導された JFE スチール株式会社 庄村 啓様、JFE システムズ株式会社 杉田 朋晃様、原 洋平様、髙山 翔伍様より寄稿いただきました。 はじめに JFE スチール株式会社は、グローバル鉄鋼サプライヤーとして、自ら学習し自律的に最適自動操業を行う「インテリジェント製鉄所」の実現を目指しています。その実現の鍵を握るのが、製造プロセスの CPS（Cyber Physical System）化です。 CPS は、製造現場(フィジカル)から収集したセンサーデータをもとに、デジタル空間上に高度な仮想プロセス(サイバー)を再現する技術です。この 2 つをリアルタイムに連携させることで、現実では見えない設備内部の状態把握や将来予測を実施し、仮想プロセスでの健全性監視・異常予測の結果を実際の操業にフィードバックします。JFE スチールでは統計モデルと物理モデルを融合した予測モデルを構築し、安定操業、生産性向上、品質安定化、GHG 排出削減などを実現します。 インテリジェント製鉄所のコアとなる全製造プロセスの CPS 化を推進するためには、機械学習モデルの開発から製鉄所エッジでの推論実行まで、一気通貫で対応できる「CPS 開発実行基盤」が不可欠です。しかし、従来の機械学習基盤ではユーザーが個人ごとに環境分離を行えないなど当社の要件と合致しない点が複数あり、CPS 開発実行基盤の構築が停滞していました。これを解決するため、JFE スチールは Amazon SageMaker AI を中核とした CPS 開発実行基盤の構築プロジェクトに着手しました。 プロジェクト体制 本プロジェクトは、JFE スチール、JFE システムズ、AWS の 3 社協業体制で推進されました。 JFE スチールは、事業会社として業務要件を熟知していることから、全体統括と要件定義を担当しました。JFE システムズは長年にわたり当社の IT システム構築・運用に携わり、当社 IT システムに関する環境を熟知しています。近年はクラウド事業に注力し、クラウド活用推進部（CCoE）を新設してクラウド活用の推進に取り組んでいます。本案件では AWS パートナーとしての高度な技術力を活かし、閉域接続環境と CPS 開発実行基盤の設計および運用を担当しました。AWS は、基盤に関する技術支援に加え、全国の製鉄所・研究所への普及活動を支援しました。この 3 社協業により、それぞれの強みを活かした効率的なプロジェクト推進が実現しました。 本プロジェクトにおいて AWS ソリューションアーキテクト (SA) の皆様には、基盤構築の初期段階から全国拠点への展開に至るまで、専門性と実務経験に基づく多面的なご支援をいただきました。これらの伴走的な支援は、CPS 開発実行基盤の高品質な構築とスムーズな利用定着を大きく後押しし、今回構築した基盤を利用する研究者・製鉄所エンジニアから高い評価を得る結果につながりました。 まず、 SageMaker AI 、 IAM 、ネットワーク、セキュリティなど多岐にわたる領域に対して体系的な AWS 技術勉強会をご提供いただき、プロジェクトメンバーの AWS に対する理解が深まりました。これにより、企画・設計フェーズを効率的に進めることができました。アーキテクチャ設計においては、今回の用途の特性を踏まえ、サービス選定から構成設計に至るまで AWS の最新ベストプラクティスに基づく具体的な助言をいただきました。特に、当社固有のセキュリティ要件への適合や権限分離に関する設計提案は、基盤品質の向上に大きく寄与しました。 加えて、基盤を利用する研究者や製鉄所エンジニアが迅速に開発に取り組めるよう、 SageMaker Studio を中心とした操作手順やワークフローを体系化したハンズオン教材の整備にご協力いただきました。このコンテンツにより、導入直後から利用が加速し、現場での活用が円滑に進みました。さらに、ハンズオンや個別相談会においても必要に応じて国内各拠点に足を運んでいただき、研究者・技術者に対するきめ細かな支援を実施いただきました。現場の課題に寄り添った対応により、利用者の理解が深まり、基盤の定着と活用拡大が加速しました。 これら AWS SA の皆様による専門的かつ丁寧なご支援により、本基盤は短期間で安定稼働へと移行し、全国の研究者・製鉄所エンジニアからの高い評価につながりました。AWS の技術力と伴走支援は、本プロジェクト成功の重要な推進力となりました。 既存基盤の課題 従来の機械学習環境には、いくつかの課題がありました。 最も大きな課題は、研究者ごとに独立した開発環境を提供できなかったことです。機密情報管理の観点からユーザーは個人ごとの環境分離を要望していましたが、従来検討していたサービスではこの要件を満たすために多額のコストが発生する可能性があり、CPS 開発実行基盤の構築が停滞していました。 さらに、環境構築の手間も大きな負担でした。新しい研究者が開発を始める際、PC のセキュリティ設定や必要なライブラリやツールのインストールを行う必要があり、セットアップが複雑でした。 加えて、キャパシティ不足により、必要な時に十分な計算リソースを確保できないという制約もありました。大規模な機械学習モデルの開発や、複数の研究者が同時に計算リソースを必要とする場合、リソース不足が開発のボトルネックとなっていました。また、キャパシティ不足を解決するために新たなサーバーを調達する際には、コスト負担も課題となっていました。 全プロセスの CPS 化を加速するためには、これらの要件を満たす機械学習基盤が必要でした。 Amazon SageMaker AI による解決策 JFE スチールは、これらの課題を解決するため、 Amazon SageMaker AI を中核とした以下のような CPS 開発実行基盤を構築しました。 図1: 全体アーキテクチャ Amazon SageMaker Studio を用いた独立した環境の提供 SageMaker Studio は、 SageMaker AI が提供する機械学習の各種機能にアクセスする ための Web ベースのプラットフォームです。 SageMaker Studio からアクセスできる IDE 機能である Code Editor は、従来から使用していた Visual Studio Code と同様の使用感を提供し、デフォルトで個人ごとに開発環境が分離されています。Code Editor は、一定時間使用されない場合に自動的にシャットダウンされる仕組みを備えており、個人ごとの環境分離を低コストで実現できます。さらに、 Amazon S3 上の学習データや SageMaker AI のリソース（学習ジョブ、モデル、エンドポイントなど）へのアクセス権限を AWS IAM で個人ごとにきめ細やかに制御しています。これにより SageMaker Studio 全体で作業環境とリソースの個人ごとの環境分離を実現しました。 環境構築の簡単化 従来の環境では、新しい研究者が開発を始める際に PC へのライブラリやツールのインストールなど、煩雑なセットアップ作業が必要でした。 SageMaker Studio の導入により、研究者は PC へのインストール作業から解放され、Web ブラウザからアクセスするだけで、すぐに開発を開始できるようになりました。 Code Editor には、データ解析や機械学習で利用される主要なライブラリが一式プリインストールされており、イメージの最新版が頻繁にアップデートされて提供されるため、研究者は常に最新のアルゴリズムやライブラリを容易に試すことができます。また、 Amazon Q Developer による生成 AI を活用したコーディング支援も利用できます。 コストを増加させないキャパシティ不足の解決 従来の環境では、キャパシティ不足により必要な時に十分な計算リソースを確保できないという課題がありました。SageMaker Training は、機械学習モデルの学習を実行するための機能で、学習ジョブを実行すると機械学習用インスタンスが自動起動し、学習終了後に自動でシャットダウンされる仕組みです。インスタンス起動時には、研究者が自由にインスタンスの種類や数を指定できます。これにより、必要な時に必要なだけ計算リソースを柔軟に拡張できるようになり、従来は困難だった大規模な機械学習モデルの開発も、複数のインスタンスを並列で稼働させることで対応可能になりました。また、従来環境では常時起動による時間課金が発生していましたが、SageMaker Training では起動した時間分のみの課金となるため、使用していない時間のコストを削減できます。 得られた成果 基盤の改善 従来の機械学習環境における課題であった、個人ごとの環境分離、環境構築の手間、キャパシティ不足を解決しました。 また、 Amazon SageMaker AI の導入により以下の副次的なメリットがありました。 SageMaker Studio や Code Editor では最新のイメージを利用者が自由に選択できるため、開発に必要なアプリケーションや OS レイヤーの維持管理作業が不要になりました。また、必要に応じて柔軟にリソースを拡張できるため、従来必要だったキャパシティの常時モニタリングからも解放されました。セキュリティ面では、 AWS IAM Identity Center により、個人ごとに分離された環境への認証を社内の既存の認証基盤と連携させることで、認証の利便性を向上させました。さらに、閉域構成など社内ネットワークポリシーに準拠した構成を維持しました。 利用の拡大と研究者からの評価 機械学習基盤は全国の製鉄所・研究所で展開され、勉強会やハンズオンを通じて利用者からの高い評価を得ています。利用者からは、「これまでできなかったことができるようになった」「自由に計算資源を立ち上げられて良い」というフィードバックが寄せられています。現在、品質改善、異常検知、基盤モデルのファインチューニングなど、多様なユースケースで利用されています。 利用者の間では SageMaker AI の様々な便利機能の利用が始まっています。例えば、SageMaker Training では、学習の実験記録が自動保存されるため、ハイパーパラメータやモデル格納場所、コードの紛失リスクが解消され、実験の再現性が向上しました。この実験管理機能は、社内で大規模な実験の管理に利用されています。 また、利用者自身が学習済みの機械学習モデルをより簡単にデプロイすることが可能となっただけでなく、本格的な業務利用が予定されるユースケースにおいては、JFE システムズの支援により SageMaker AI のバッチ変換ジョブと Amazon ECS を組み合わせた機械学習推論パイプラインを構築し運用しています。 今後の展望 JFE スチールの CPS 開発実行基盤は、 Amazon SageMaker AI の導入を第一歩として、さらなる進化を目指しています。 CPSはそのすべてがクラウド上で完結するものではなく、ユースケースによっては製鉄所のエッジにオンプレミスサーバを配置して運用する必要があります。これを見据え今後は AWS IoT Greengrass によるエッジ配信基盤を構築予定です。 SageMaker AI で開発した機械学習モデルを、製鉄所のエッジサーバに Greengrass で配信し、エッジでのリアルタイム推論を実現します。これにより、機械学習モデルの開発から製鉄所エッジでの推論実行まで、一気通貫のワークフローが完成します。 この CPS 開発実行基盤を活用し、主要ラインの CPS 化を加速させ、最終的には全プロセスを CPS 化して仮想空間に製鉄プロセス全体を再現する「インテリジェント製鉄所」の実現を目指します。 まとめ JFE スチール、JFE システムズ、AWS の 3 社協業により、 Amazon SageMaker AI を中核とした CPS 開発実行基盤の構築を行い、個人ごとの環境分離、環境構築の簡単化、キャパシティ不足の解決を実現し、研究者や製造現場のエンジニアから高い評価を獲得しました。 今後は、 AWS IoT Greengrass によるエッジ配信基盤の統合により、インテリジェント製鉄所の実現に向けて前進していきます。 執筆者 写真左から髙山様、庄村様、杉田様、原様 庄村 啓 JFE スチール株式会社　DX 戦略本部 DX 企画部 大学院卒業後、JFE スチール株式会社に入社。製鉄所のプラント制御システムを管轄する部署にて、設備制御・監視システムの開発および建設業務に従事。 2022 年よりデータサイエンスプロジェクト部（現 DX 企画部）にて、インテリジェント製鉄所の実現に向けた CPS（Cyber Physical System）基盤の構築、維持運用、活用促進活動を担当。 杉田 朋晃 JFE システムズ株式会社 基盤事業本部 基盤エンジニアリング部 カスタムエンジニアリンググループ 大学卒業後、インフラエンジニアとしてシステム開発、設計・構築を担当。 2025 年に JFE システムズに入社。 JFE スチール担当システムエンジニアとして、CPS 開発実行基盤のプロジェクトをリーダとして推進。 原 洋平 JFE システムズ株式会社 基盤事業本部 基盤エンジニアリング部 カスタムエンジニアリンググループ 大学卒業後、2008 年に JFE システムズ株式会社に入社。 以降、JFE スチール向け基盤構築担当として、サーバ基盤の設計、構築を担当。 2022 年から、CPS-PF 案件のモデル開発・実行 PF の基盤リーダーとして推進。 髙山 翔伍 JFE システムズ株式会社 デジタル製造事業本部 第1開発部 大学院卒業後、2017 年に JFE システムズ株式会社に入社。 以降、JFE スチール様担当のシステムエンジニアとして、統計・機械学習を用いた分析業務，システムの設計、構築を担当。 2023 年より、CPS（Cyber Physical System）プラットフォームを活用したシステム構築を推進。

本記事は 2026 年 1 月 15 日 に公開された「 Unlock granular resource control with queue-based QMR in Amazon Redshift Serverless 」を翻訳したものです。 Amazon Redshift Serverless は、データウェアハウス運用からインフラストラクチャ管理と手動スケーリングの要件を取り除きます。Amazon Redshift Serverless のキューベースクエリリソース管理は、クエリを専用キューに分離し、高負荷のクエリが他のユーザーに影響を与えることを防ぐ自動ルールを使用することで、重要なワークロードを保護し、コストを制御するのに役立ちます。さまざまなワークロードに対してカスタマイズされた監視ルールを持つ専用クエリキューを作成でき、リソース使用量をきめ細かく制御できます。キューを使用すると、メトリクスベースの述語と自動応答を定義でき、時間制限を超えたり過剰なリソースを消費したりするクエリを自動的に中止するなどの対応が可能です。 さまざまな分析ワークロードには、それぞれ異なる要件があります。マーケティングダッシュボードには、一貫した高速な応答時間が必要です。データサイエンスワークロードでは、複雑でリソース集約的なクエリを実行する場合があります。抽出、変換、ロード (ETL) プロセスでは、オフピーク時に長時間の変換を実行する場合があります。 組織がより多くのユーザー、チーム、ワークロードにわたって分析の使用を拡大するにつれて、共有環境で一貫したパフォーマンスとコスト管理を確保することがますます困難になっていきます。最適化が不十分な単一のクエリが過度のリソースを消費し、ビジネスクリティカルなダッシュボード、ETL ジョブ、経営層向けレポートのパフォーマンスを低下させる可能性があります。Amazon Redshift Serverless のキューベース Query Monitoring Rules (QMR) を使用すると、管理者はキューレベルでワークロードに応じたしきい値と自動アクションを定義できます。これは、以前のワークグループレベルの監視からの大幅な改善です。BI レポート、アドホック分析、データエンジニアリングなどの異なるワークロード用に専用キューを作成し、キュー固有のルールを適用して、実行時間またはリソース消費制限を超えるクエリを自動的に中止、ログ記録、または制限できます。ワークロードを分離し、ターゲットを絞った制御を実施することで、このアプローチはミッションクリティカルなクエリを保護し、パフォーマンスの予測可能性を向上させ、リソースの独占を防ぎます。これらすべてを、サーバーレスエクスペリエンスの柔軟性を維持しながら実現します。 この記事では、Redshift Serverless でクエリキューを使用してワークロードを実装する方法について説明します。 キューベース監視とワークグループレベル監視の比較 クエリキューが導入される前は、Redshift Serverless はワークグループレベルでのみクエリ監視ルール (QMR) を提供していました。これは、目的やユーザーに関係なく、すべてのクエリが同じ監視ルールの対象となることを意味していました。 キューベース監視は、大きな進化をしています。 きめ細かな制御 – さまざまなワークロードタイプ用に専用キューを作成できます ロールベースの割り当て – ユーザーロールとクエリグループに基づいて、クエリを特定のキューに振り向けることができます 独立した動作 – 各キューは独自の監視ルールを維持します ソリューション概要 以下のセクションでは、一般的な組織が Redshift Serverless でクエリキューを実装する方法を検討します。 アーキテクチャコンポーネント ワークグループ設定 クエリキューが定義される基本単位 キュー定義、ユーザーロールマッピング、監視ルールが含まれます キュー構造 単一のワークグループ内で動作する複数の独立したキュー 各キューには独自のリソース割り当てパラメータと監視ルールがあります ユーザー/ロールマッピング 以下に基づいて、クエリを適切なキューに振り向けます。 ユーザーロール (例: analyst、etl_role、admin) クエリグループ (例: reporting、group_etl_inbound) 柔軟なマッチングのためのクエリグループワイルドカード Query Monitoring Rules (QMR) 実行時間やリソース使用量などのメトリクスのしきい値を定義します しきい値を超えた場合の自動アクション (中止、ログ記録) を指定します 前提条件 Amazon Redshift Serverless でクエリキューを実装するには、以下の前提条件が必要です。 Redshift Serverless 環境 : アクティブな Amazon Redshift Serverless ワークグループ 関連付けられた名前空間 アクセス要件 : Redshift Serverless 権限を持つ AWS Management Console アクセス AWS CLI アクセス (コマンドライン実装の場合はオプション) ワークグループの管理データベース認証情報 必要な権限 : Redshift Serverless 操作の IAM 権限 (CreateWorkgroup、UpdateWorkgroup) データベースユーザーとロールを作成および管理する機能 ワークロードタイプの特定 まず、ワークロードを分類することから始めます。一般的なパターンには以下が含まれます。 インタラクティブ分析 – 高速な応答時間を必要とするダッシュボードとレポート データサイエンス – 複雑でリソース集約的な探索的分析 ETL/ELT – より長い実行時間を持つバッチ処理 管理 – 特別な権限を必要とするメンテナンス操作 キュー設定の定義 各ワークロードタイプに対して、適切なパラメータとルールを定義します。実用的な例として、3 つのキューを実装したいとします。 Dashboard キュー – analyst および viewer ユーザーロールによって使用され、60 秒を超えるクエリを停止する厳格なランタイム制限が設定されています ETL キュー – etl_role ユーザーロールによって使用され、データ処理操作中のリソース使用量を制御するために、ディスクスピル ( query_temp_blocks_to_disk ) に 100,000 ブロックの制限があります Admin キュー – admin ユーザーロールによって使用され、クエリ監視制限は適用されません AWS Management Console を使用してこれを実装するには、以下の手順を実行します。 Redshift Serverless コンソールで、ワークグループに移動します。 制限 タブの クエリキュー で、 キューを有効にする を選択します。 以下のスクリーンショットに示すように、適切なパラメータで各キューを設定します。 各キュー (dashboard、ETL、admin_queue) は特定のユーザーロールとクエリグループにマッピングされ、クエリルール間に明確な境界を作成します。クエリ監視ルールはリソース管理を自動化します。たとえば、dashboard キューは 60 秒を超えるクエリを自動的に停止し ( short_timeout )、ETL プロセスには異なるしきい値でより長い実行時間を許可します。この設定は、適切なガードレールを備えた個別の処理レーンを確立することでリソースの独占を防ぎ、重要なビジネスプロセスが必要な計算リソースを維持しながら、リソースを大量に消費する操作の影響を制限できるようにします。 または、 AWS Command Line Interface (AWS CLI) を使用してソリューションを実装することもできます。 以下の例では、 test-namespace という既存の名前空間内に test-workgroup という名前の 新しいワークグループを作成 します。これにより、以下のコマンドを使用して、キューを作成し、各キューに関連する監視ルールを確立できます。 aws redshift-serverless create-workgroup \ --workgroup-name test-workgroup \ --namespace-name test-namespace \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"etl_role\"],\"query_group\":[\"group_etl_inbound\",\"group_etl_outbound\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' また、以下のコマンドを使用して、 update-workgroup で既存のワークグループを変更することもできます。 aws redshift-serverless update-workgroup \ --workgroup-name test-workgroup \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"etl_role\"],\"query_group\":[\"group_etl_load\",\"group_etl_replication\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\">\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\">\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' キュー管理のベストプラクティス 以下のベストプラクティスを検討してください。 シンプルに始める – 最小限のキューとルールのセットから始めます ビジネスの優先順位に合わせる – 重要なビジネスプロセスを反映するようにキューを設定します 監視と調整 – キューのパフォーマンスを定期的に確認し、しきい値を調整します 本番環境の前にテスト – 本番環境に適用する前に、テスト環境でクエリメトリクスの動作を検証します クリーンアップ リソースをクリーンアップするには、Amazon Redshift Serverless ワークグループと名前空間を削除します。手順については、 ワークグループの削除 を参照してください。 まとめ Amazon Redshift Serverless のクエリキューは、さまざまな分析ワークロードに合わせたキュー固有の Query Monitoring Rules を有効にすることで、サーバーレスのシンプルさときめ細かなワークロード制御のギャップを埋めます。ワークロードを分離し、ターゲットを絞ったリソースしきい値を実施することで、ビジネスクリティカルなクエリを保護し、パフォーマンスの予測可能性を向上させ、高負荷のクエリを制限できます。これにより、予期しないリソース消費を最小限に抑え、コストをより適切に管理しながら、Redshift Serverless の自動スケーリングと運用のシンプルさの恩恵を受けることができます。 今すぐ Amazon Redshift Serverless を始めましょう 。 著者について Srini Ponnada Srini は、Amazon Web Services (AWS) のシニアデータアーキテクトです。20 年以上にわたり、お客様がスケーラブルなデータウェアハウスとビッグデータソリューションを構築するのを支援してきました。AWS で効率的なエンドツーエンドソリューションを設計および構築することを愛しています。 Niranjan Kulkarni Niranjan は、Amazon Redshift のソフトウェア開発エンジニアです。Amazon Redshift Serverless の採用と Amazon Redshift のセキュリティ関連機能に注力しています。仕事以外では、家族と時間を過ごし、質の高いテレビドラマを視聴することを楽しんでいます。 Ashish Agrawal Ashish は現在、Amazon Redshift のプリンシパルテクニカルプロダクトマネージャーであり、クラウドベースのデータウェアハウスと分析クラウドサービスソリューションを構築しています。Ashish は IT 分野で 24 年以上の経験があります。Ashish は、データウェアハウス、データレイク、Platform as a Service の専門知識を持っています。Ashish は世界中の技術カンファレンスで講演しています。 Davide Pagano Davide は、Amazon Redshift のソフトウェア開発マネージャーであり、自動ワークロード管理、多次元データレイアウト、Amazon Redshift Serverless の AI 駆動スケーリングと最適化などのスマートなクラウドベースのデータウェアハウスと分析クラウドサービスソリューションの構築を専門としています。データベースで 10 年以上の経験があり、そのうち 8 年は Amazon Redshift に特化しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Tatsuya Koyakumaru がレビューしました。

はじめに コンタクトセンター管理者は、本番環境を中断することなく、コンタクトフローを効率的にテストと検証するという課題に直面しています。従来のアプローチ、例えば手動でシステムに電話をかける、カスタム検証ツールを構築する、サードパーティソリューションに投資するような手段は、時間とコストがかかります。大企業では、年間予算の大部分が自動テストツールに割り当てられることも多く、一方で手動検証を用いる場合は変更ごとに数日から数週間の作業が必要になることがあります。Amazon Connect が高度な AI 機能で進化するにつれて、サービス品質と顧客満足度を維持するための効率的なテスト戦略がさらに重要になっています。 Amazon Connect はネイティブコールシミュレーション機能の一般提供を発表しました。組み込まれたこのテストソリューションは、検証時間と作業を大幅に削減しながら、コンタクトセンター設計への信頼性を高めます。外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、チームはイノベーションと優れた顧客体験の提供に集中できます。 本記事で学べること 本記事では、Amazon Connect の新しいテスト機能を活用してコンタクトセンターの検証を自動化する方法を説明します。次のことを学べます。 直感的なビジュアルデザイナーでテストケースを設定する 自然な顧客インタラクションを反映したテストシナリオを作成する 自動テストを実行し、結果を分析して継続的な改善を行う テストフレームワークの概要 Amazon Connect のテストとシミュレーションフレームワークは、直感的なビジュアルインターフェースでコンタクトセンター体験を検証できます。ステップバイステップのガイドと複雑な遷移による従来のテストアプローチとは異なり、顧客が実際にコンタクトセンターとやり取りする方法を反映した、自然でユーザーフレンドリーなものです。 イベント駆動型テストモデル フレームワークのコアにはイベント駆動型モデルを使用しています。コンタクトフロー実装の深い技術知識による記述ではなく、「X が発生したら Y を実行する」という観点でテストを記述します。例: 「IVR が『エージェントと話すには 1 を押すか、エージェントと言ってください』と再生したら、顧客は 1 を押すか、エージェントと言う必要があります。」 これには 3 つの直感的な概念を活用します。 Observations (監視): 期待されるシステムイベントと対応するアクションを含む完全なインタラクション Events (イベント): システムから期待される特定の動作 (プロンプト、ボットメッセージ、Lambda 関数呼び出し) Actions (アクション): テストフレームワークが応答としてシミュレートすべきこと (顧客入力、属性検証、リソースモック) イベント駆動型モデルは大きなメリットをもたらします。技術者以外のチームメンバーでもテストを簡単に理解して作成でき、QA チームにとっては最小限のトレーニングで済ませられ、フレームワークによってプロセスをアクセスしやすく保ちながら技術的な精度を維持できます。 ビジュアルテストデザイナーインターフェース デザイナーは、インタラクショングループを使用してテストシナリオを視覚的に構築できるインターフェースです。各インタラクショングループは、期待される動作とシミュレートされたアクションの完全なシーケンスを表し、テストフローを一目で把握できます。ビジュアルアプローチにより学習にかかる時間が短縮され、チームメンバーは基礎となる技術実装の詳細を理解することなくテストを作成できます。 テスト分析とダッシュボード Amazon Connect は、 分析と最適化 > ダッシュボードとレポート > テストおよびシミュレーションダッシュボード からアクセスできる専用のテストとシミュレーションダッシュボードを提供します。ダッシュボードでは以下のようなテスト実行履歴の詳細な洞察が得られます。 全体的なテスト成功率を示すサマリーメトリクス 一般的な問題を特定するための失敗タイプの内訳 パフォーマンス分析のための実行時間メトリクス 時間の経過に伴う改善を追跡するための日付範囲フィルタリング テストケースの作成 効果的なテストケースの構築には、3 つの主要なステップがあります。基本的なテスト設定の構成、インタラクショングループを使用したテストフローの設計、観察およびシミュレートする特定の動作の定義です。 テスト設定とパラメータの構成 テストケース管理ページ（ ルーティング > テスト ）で テストを作成 をクリックして、新しいテストケースを作成します。 設定 タブで次を構成します。 開始点 : 特定のフローまたは電話番号 チャンネル : 音声通話 着信電話番号 : シミュレートされる発信者の電話番号 属性 : プロファイル情報などのユーザー定義コンタクト属性 インタラクショングループの構築 デザイナー タブで、インタラクショングループのテストフローを構築します。各グループは、何かが発生することを期待し、そのイベントを検証または応答する必要がある瞬間を表します。 + 新しいインタラクション ボタンでインタラクショングループを追加し、それらを接続して完全なテストケースフローを定義します。 Observation、Check、Action ブロックの設定 各インタラクショングループには、最大 3 つのブロックタイプが含まれます。 Observe ブロック (必須) : 「Test started(テスト開始)」、「Message received(メッセージ受信)」、「Action triggered(アクション呼び出し)」などの期待されるシステムイベントを定義します。メッセージベースの観察の場合、メッセージの内容が一致するか確認するために次のいずれかを選択できます。 Contains : 実際のメッセージに指定されたテキストが含まれているかどうかをチェックします (部分一致) Similar : セマンティックな類似性のための高度な比較を使用します (意味的一致) ※訳注 ブログ翻訳時点では Observe ブロックは英語で受信されるメッセージをサポートしています。詳しくは ドキュメント をご覧ください。 Check (チェック)ブロック (オプション) : コンタクトジャーニーのその時点で、特定の属性に期待される値が含まれているか検証します。名前空間 (System、User defined、Segment Attributes など)、属性キー、期待値を指定して属性検証を構成します。 Action ブロック (オプション) : 観察されたイベントに応答してフレームワークがシミュレートすべきことを定義します。 Mock resource behavior : 連携している Lambda 関数からの応答や、 Hours of Operation (オペレーション時間)、Queue(キュー)、Lex bot などのリソースをテスト用の代替リソースに置き換えることができます Send instruction : 顧客入力をシミュレートします (DTMF トーン、テキスト発話、通話切断) Test commands : 属性のログ記録やテストの終了などのユーティリティです セルフサービスとキュー体験のテスト: 実践例 コンタクトセンターフローをテストすることで、顧客が一貫性のある信頼性の高い体験を受けられるようになります。このセクションでは、一般的なシナリオのテストについて説明します。既存の顧客が営業時間内に電話をかけてエージェントに到達するケースです。 顧客体験 フローは次のように動作します。 Lambda 関数が着信電話番号で顧客のタイプを確認します。 システムがウェルカムプロンプトを再生し、顧客にエージェントに到達するためには 1 を押すように求めます。 入力を受信した後、顧客は確認メッセージを聞きます。 システムは、エージェントが対応可能になるまで、保留音楽付きのキューに顧客を転送します。 テストケースの構築 体験を検証するために、3 つのインタラクショングループを持つテストケースを作成します。 テスト設定の構成 シミュレートするフローを選択し、顧客の識別情報として着信電話番号を入力します。 インタラクショングループ 1: テストの初期化 テストのセットアップと営業時間のオーバーライドを処理します。 Observe ブロック : イベントタイプとして「Test started」を選択します。テストが開始されるとすぐに実行されます。 Action ブロック : Hours of Operation リソースのオーバーライドを構成します。テストを実行するタイミングに関係なく、営業時間内であるかのようにテストが実行されます。フローの Hours of Operation リソースを選択し、フローで営業時間チェックが呼び出されたときに「営業時間内」になるように応答をモックするか、常に営業中の代替リソースを指定します。 インタラクショングループ 2: ウェルカムプロンプトの検証 ウェルカムプロンプトを検証し、顧客入力をシミュレートします。 Observe ブロック : Event の種類: 「Message received」 Actor: 「System」(デフォルト。プロンプトはコンタクトフローから発信されるため) Expected text: 「Press 1 to be connected to an agent(エージェントに接続するには、1 を押してください)」 Matching criteria: 「Similar」 Action ブロック : 顧客が 1 を押すことをシミュレートする「Send instruction」アクションを構成します。 Response type: 「DTMF Input」 Input value: 「1」 インタラクショングループ 3: キューの検証 キューへの配置を検証し、テストを終了します。 Observe ブロック : 期待される確認メッセージを指定します。「Thank you for calling. Your call is very important to us and will be answered in the order it was received.(お電話ありがとうございました。お客様からの声は重要です。順番におつなぎしますのでお待ちください。)」 Check ブロック : System 名前空間の「Queue Name」属性を期待値 (例: 「Agent Queue」) と照合して、正しいキューに転送されたかを検証します。 Action ブロック : 2 つの「Test commands」アクションを追加します。 Log data : テスト実行の詳細で分析するために関連する属性をキャプチャします End test : テストケースの実行を終了します テストの実行 すべてのインタラクショングループを構成した後、3 つのインタラクショングループが順番に接続されていることを確認します。その後、テストケースを保存して公開し、実行できる状態にします。 テストの実行と分析 テストケースの実行 テストデザイナーから テストを実行 ボタンで直接テストを実行するか、テストケース管理ページからバッチ実行できます。Amazon Connect は、インスタンスごとに最大 5 つの同時テスト実行をサポートし、追加のテストは自動的にキューに入れられます。主要な変更をテストして結果を取得してから、時間がかかる可能性のあるリグレッションテストを実行できます。 結果の監視とレビュー テスト実行 タブでテストの進行状況をリアルタイムで監視します。詳細な結果ページには、次のような詳細なビューを確認できます。 全体的なテストパフォーマンスを要約するセッションメトリクス インタラクショングループの完了率と合格/不合格の統計、および合計シミュレーション時間 初期セットアップ、テスト開始、インタラクション、テスト完了を含む詳細なテスト実行ステップ 各 observe ブロック、check ブロック、action ブロックの実行の詳細 失敗したテストのトラブルシューティング テストが失敗した場合、詳細な結果ページには、どの特定のインタラクションまたはブロックが失敗したかが示されます。次の情報を確認できます。 失敗した observe ブロックの期待されるイベントと実際のイベント 失敗した check ブロックの属性検証の詳細 アクション失敗の理由と試行された操作 完全な音声録音とトランスクリプション (有効な場合) 利用を始めるには ベストプラクティス 整理 : 「一般的な顧客 – 営業時間中 – エージェントへ転送」のように、明確でわかりやすいテスト名を使用します。タグを活用して、機能領域、顧客タイプ、優先度レベルごとにテストを分類します。 レジリエンス : 可能な限りプロンプトにセマンティックマッチングを使用して、わずかな文言の変更に対応できるようにします。時間依存のリソースをオーバーライドして、テストを実行するタイミングに関係なく一貫したテスト実行を定義します。 優先順位付け : 重要なカスタマージャーニーを最初に優先します。エージェント転送、一般的なセルフサービスシナリオ、営業時間外の体験です。最も重要な機能から常に検証していきます。 統合 : テストをデプロイメントプロセスに組み込みます。コンタクトフローの変更をデプロイする前に関連するテストケースを実行して、顧客に影響を与える前に問題を発見します。 その他のテストシナリオの例 営業時間外のテスト : 営業時間外に電話をかけることをシミュレートするテストを構成し、適切なクローズメッセージとコールバックオプションを検証します。 セルフサービスの検証 : 顧客が IVR メニューをナビゲートし、DTMF または音声でアカウント情報を提供し、期待される結果に到達することをシミュレートするテストを作成します。 認証された顧客体験 : 認証された顧客に対する差別化された処理をテストします。優先キュー配置や専門エージェントルーティングなどです。 コールバックシナリオ : 待ち時間が長い場合のコールバックオプションを検証します。番号の収集と確認プロセスを含みます。 まとめ Amazon Connect のネイティブなコールシミュレーション機能は、コンタクトセンター体験を検証および維持する方法を変革します。テストケースを迅速に作成し、オンデマンドに、あるいはデプロイメントプロセスの一部として実行し、継続的な改善を推進する洞察を得ることができます。 Amazon Connect インスタンスで今すぐこれらのテスト機能をお試しください。最も重要なカスタマージャーニーの重要なテストケースから始め、時間の経過とともにカバレッジを拡大し、テストダッシュボードを活用して進捗状況を追跡すれば、最適化の機会を特定できます。 詳細なドキュメントと実装のガイドは、 Amazon Connect 管理者ガイド および Amazon Connect API Reference をご覧ください。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

Amazon Connect は、より低いコストで優れた成果を実現する AI を活用したカスタマーエクスペリエンスソリューションです。2017 年のパブリックローンチ以来、Amazon Connect は AI の活用を推進し、あらゆる種類の組織が顧客とやり取りする方法を変革してきました。 先週の Q3 2025 年決算報告で、Amazon は重要なマイルストーンを発表しました。Amazon Connect は年間換算売上高 10 億ドルのペース(ランレート)を達成し、AI が前年に 120 億分を超える顧客とのやり取りを最適化しました。このような成功が続く中でも、Amazon Connect はミッションに基づいて行動し続け、サービスのスタート時と同様に、最終的な顧客の満足、エージェントの満足、そしてビジネスリーダーの喜びを通じて結果を測定しています。 ここで Amazon Connect のストーリーを探ってみましょう。Amazon の内部ソリューションから AI のパイオニアとなるまでの道のりです。 ストーリーの起源 Amazon Web Services (AWS) と同様に、Amazon Connect は Amazon が内部ソリューションを業界をリードするサービスに変革した事例です。ストーリーは 2007 年に始まりました。内部のカスタマーサービスチームが、3 つのコンタクトセンターベンダーを置き換えるため、ゼロから新しい統合ソリューションを構築する提案を採用したときです。従来の方法では、ハードウェアアップグレードのための 300 万ドルの前払い投資に加えて、継続的なライセンスとメンテナンス料金が見積もられていました。一方、提案された内部ソリューションは、より安価であるだけでなく、地球上で最もお客様を大切にする企業であるという Amazon の明文化されたミッションを体現していました。 「当時、他のすべての製品を調べました。しかし魅力的な選択肢はみつかりませんでした」カスタマーサービスチームを設立し、Connect の最も上級なエンジニアリングリーダーの一人であり続けている Jon Jay 氏は述べています。「いずれも要件を満たすキャパシティを持っていなかったため、これらのコンタクトセンターソリューションでは十数個のインスタンスを管理する必要があったでしょう。それらは非常に高価でしたし、顧客を喜ばせるために対処したいと考えていた問題を解決しませんでした。」 Amazon Worldwide Consumer の元 CEO である Jeff Wilke 氏からの承認を受けた後、チームは 2007 年に最初のパイロット展開に成功し、2008 年に完全に展開されました。内部効率化プロジェクトとして始まったこのプロジェクトは、カスタマーサービスから人事、輸送まで、Amazon のさまざまな部門に何年もサービスを提供し続け、競合ソリューションと比較して推定年間 6,000 万ドルの節約を実現しました。Audible や Zappos など新たに買収された企業も、このソリューションを熱心に採用し、カスタマーエクスペリエンスに対する Amazon 独自のアプローチが、市場での需要があることを証明しました。 「私たちが構築したものを他の Amazon チームに見せると、これは急速に広がりました。Zappos、Audible – 彼らはみな同じく、従来のコンタクトセンターで頭痛の種を抱えていました。私たちのソリューションを見せた時、彼らは『ちょっと待って – あなたたちは私たちの最大の問題をすべて解決したのですか』と言ったのです」と Jay 氏は述べています。 製品ローンチと初期の成功 Amazon Connect を一般に利用可能にする決定は 2015 年第 3 四半期に行われ、当時の AWS CEO である Andy Jassy 氏の承認を得て、Pasquale DeMaio 氏が主導しました。 「潜在的な外部顧客と話すと、お客様も Amazon と同じ課題に直面していることは明らかでした」と Jay 氏は付け加えました。「実装が簡単で、イノベーションの速度を提供し、最大規模の企業が必要とする信頼性とセキュリティ、拡張性を提供できるクラウドベースのソリューションであった可能性が分かりました。私たちは Amazon の問題だけを解決していたのではないことを知りました。業界全体が何十年もの間行き詰まっていた問題を解決していたのです。」 外部サービスとしての開発から 1 年強後、Amazon Connect は Enterprise Connect 2017 でパブリックデビューを果たし、重大なスケーリングの課題に直面している大企業の間で急速に注目を集めました。また AWS サービスとの深い統合により、シームレスなスケーリングと迅速な機能開発が可能になり、Amazon Lex を通じて Alexa AI テクノロジーを早期採用したことで、Amazon Connect を際立たせる自然言語対話型音声応答 (IVR) 機能が提供されました。 Capital One、Hilton、GE など Amazon Connect を早期に採用したお客様は、Amazon Connect の独自の価値提案に魅力を感じました。それは従来の電話インフラストラクチャの必要性を排除したクラウドネイティブなアーキテクチャです。この革新的なアプローチにより、従来は 1 年間の構築プロセスだったものが、多くの組織にとって週末のプロジェクトに変わり、市場投入時間と運用の複雑さの両方を劇的に削減しました。 「最初、私たちのイノベーションの速度を求める組織が、Amazon Connect とのパートナーシップで成功を収めました」と Amazon Connect の VP である Pasquale DeMaio 氏は述べています。「組織は、私たちが非常にユニークな方法でカスタマーエクスペリエンスを理解していることを知っています。お客様へのこだわり・お客様を起点に考えることもその一つです。Amazon では、私たちは毎日そのように過ごしています。」 COVID-19 のパンデミックが発生したときも、Amazon Connect のクラウドネイティブ設計のメリットが発揮されました。セルフサービスセットアップとネイティブな在宅勤務のエージェントサポートは、組織がリモートワークの従業員でカスタマーサービス業務を維持しようと奔走する中で、重要な利点となりました。標準的なインターネット接続とヘッドセットだけで機能し、専用の電話機器の必要性を排除できるため、突然のリモートワークへの移行に理想的なソリューションとなりました。パンデミックの終わりまでには、Amazon Connect は数万の顧客を抱えていました。 カスタマーエクスペリエンスにおける AI 革命 Amazon Connect の進化は、2019 年に AI を活用した会話分析、感情分析などのローンチにより更なる飛躍を遂げました。これらに一般的な複雑な技術要件はありません。他のソリューションでは数週間の展開が必要なのに対し、Amazon Connect ではお客様がこれらの AI 機能を有効にするためにチェックボックスを選択するだけで済みました。 2023 年、Amazon Connect は 2 つの主要な業界レポートで初めてリーダーシップポジションを達成しました。 Forrester Wave for Contact Center as a Service と Gartner’s Contact Center as a Service Magic Quadrant です。Amazon Connect は、現在まで後続のレポートでこれらのリーダーシップポジションを維持しています。 追加の AI 機能は、カスタマージャーニー全体に対して迅速に提供されました。生成 AI の出現で、チームはロードマップを転換し、大規模言語モデル (LLM) テクノロジーを採用し、自動でのエージェントのラップアップ、通話要約、LLM ベースのセルフサービスエクスペリエンスなどの機能を可能にしました。 2024 年 12 月、Amazon Connect は 60 億分の顧客とのやり取りが AI によって最適化されたと発表、顧客が実際のシナリオで AI を活用されている規模を示しました。Amazon Connect が 2025 年 3 月にカスタマージャーニー全体で AI が有効になった「次世代の Amazon Connect」を発表したときも、お客様の反応はとても肯定的でした。現在、Amazon Connect は AI で 120 億分の顧客とのやり取りを最適化しており、これは 1 年足らず前に発表された数値の 2 倍です。 Amazon Connect は、エンタープライズ規模の革新的で統合された AI ソリューションを提供しています。最近も、複数のグローバルブランドが他のプロバイダーや新興の AI ネイティブプレーヤーよりも Amazon Connect を選択しています。これらの評価において、Amazon Connect は、インテント検出精度、AI エージェントの安全性、人間と AI のコラボレーション機能などの重要な領域で優れたパフォーマンスを実証しました。これらの結果は、単なる優れたデモではなく、技術的メリットと信頼性に基づいてミッションクリティカルなユースケースを可能にし、Amazon Connect がクラス内で最高レベルの AI ソリューションを提供する能力を実証しています。 今後の展望 Amazon Connect は 10 億ドルの収益ランレートというマイルストーンの達成により、従量課金ベースのカスタマーエクスペリエンスソリューションとしてのこの規模に到達した存在になりました。この従量課金制アプローチは、AI とエージェンティックな未来に向けて Amazon Connect を特徴づけています。 「転機が次々と訪れました。Amazon Connect はまず最初に、クラウドベースのコンタクトセンターを新しい標準にする主要な推進力となり、次に COVID 中に需要の大幅な変動を管理しながらリモートワークをナビゲートするビジネスを可能にし、最終的に生成 AI で実世界の結果を提供しました」と DeMaio 氏は述べています。「今、私たちはさらに 2 つのテーマに直面しています。エンタープライズ規模で安全で倫理的なエージェンティック AI を提供すること、受動的な顧客エンゲージメントから積極的な顧客エンゲージメントに進化すること – これらをすべて顧客の問題を解決する新しい機会領域に拡大しながら解決していくのです。」 Amazon 自身のカスタマーサービスの課題を解決する内部プロジェクトから、Amazon Connect は 8 年間で数万の顧客に信頼されるグローバルサービスに進化しました。これは、まだ Day 1 です。この創造を促したときと変わらず、好奇心と顧客体験を変革する使命を持って、チームは問題を解決し顧客を喜ばせることを目的とした AI を活用したソリューションの開拓を続けています。 Amazon Connect の詳細については、 Amazon Connect ページ をご覧ください。 Amazon Connect でカスタマーサービスエクスペリエンスを変革する準備はできていますか？ お問い合わせください。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。原文は こちら です。

本記事では、Amazon Relational Database Service (Amazon RDS) for Db2 のトラブルシューティングで必要となる情報の収集方法をご紹介いたします。 2026 年 1 月 update : rdsadmin.db2support_command プロシージャの対応により、db2suppot の説明を追加 Linux、Unix、Windows 上で動作する IBM Db2 で収集していた情報を、Amazon RDS for Db2 ではどのように収集すれば良いか分からないという方もいらっしゃるのではないでしょうか。 あるいは、IBM サポートにお問い合わせいただいた際に「〜の情報を収集してください」と依頼され、どのように情報を収集すれば良いか分からないという方もいらっしゃるかもしれません。 今回は、IBM サポートから情報収集を求められた場合の情報の収集方法について、サンプルクエリ等を交えてご紹介していきます。 Amazon RDS for Db2 におけるサポート体制 はじめに、前提として Amazon RDS for Db2 のサポート体制についてご説明いたします。 Amazon RDS for Db2 では BYOL (Bring Your Own Licnece) モデルを採用しており、お困りの問題に応じて以下のサポートをご利用いただくことが可能です。 IBM サポート IBM Db2 LUW の動作に関するお問い合わせ(パフォーマンスの問題や、サービスリクエスト)は、 IBM サポート にお問い合わせください。 AWS サポート AWS サポートのアカウントをお持ちの場合、Amazon RDS 固有の問題については、 AWS サポート にお問い合わせください。 IBM サポートで必要となる情報 IBM サポートでトラブルシューティングを行う場合、主に以下の情報を求められる場合があります。 db2diag.log db2support コマンドにより取得されたファイル First Occurrence Data Capture(FODC) の情報 コアダンプファイル Amazon RDS for Db2 はマネージドサービスのため、Linux、Unix、Windows 上で動作する IBM Db2 では実行可能なコマンドや SQL クエリが一部制限されています。 これらの情報は マスターユーザーアカウント権限 を使用しても収集することができないため、代用手段を用いて情報を収集する必要があります。 以降、各項目の情報収集方法について説明します。 db2diag.log Amazon RDS for Db2 では、マネジメントコンソールから db2diag.log をダウンロードいただくことが可能です。 問題の発生状況が確認できるよう、問題が発生した日時の前後の記録を含む db2diag.log をダウンロードしてください。 db2diag.log はローテーションにより一定のサイズを超えると古いログが削除されてしまうため、過去の記録を遡って確認できるよう Amazon CloudWatch Logs へのエクスポートをお勧めします。 Amazon CloudWatch Logs にエクスポートされたログは、CloudWatch Logs Insights により検索条件の指定により必要なログのみを抽出できます。 抽出したログのみをファイルに保存することも可能です。 Amazon CloudWatch Logs、および CloudWatch Logs Insights の詳細については、 こちら をご覧ください。 db2support コマンドにより取得されたファイル RDS for Db2 でご利用いただけるユーザー権限では、 db2support コマンドを直接実行することができません。 db2support コマンドの実行、および db2support コマンドにより取得されたファイルを収集される場合は、 rdsadmin.db2support_command プロシージャ を実行してください。 なお、当該プロシージャを実行いただくと、Amazon Simple Storage Service (Amazon S3) にファイルが出力されます。 そのため、プロシージャ実行前に Amazon S3 統合を有効化いただく必要がございます。 Amazon S3 統合の有効化につきましては、 こちら をご覧ください。 First Occurrence Data Capture(FODC) の情報 db2support 同様、 First Occurrence Data Capture(FODC) の情報の収集についても、現時点ではお客様にて行えない操作となっています。 First Occurrence Data Capture(FODC) の情報が必要な場合は、AWS サポートまでお問い合わせください。 コアダンプファイル コアダンプファイルの取得は、現時点ではお客様にて行えない操作となっています。 コアダンプファイルの取得が必要な場合は、AWS サポート までお問い合わせください。 AWS サポートご利用時の Tips AWS サポート での情報収集をご依頼いただく場合のお問い合わせ IBM サポートへ既にお問い合わせ済みで、該当の情報の取得を依頼されている旨をご説明いただくことで、AWS サポート側でもスムーズなご案内が可能です。 例： ◯◯(発生している事象の概要) という問題が発生しており、原因を調査中です。 現在、IBM サポートへ問い合わせており、調査には ◯◯(コアダンプ 等)のデータを必要としております。 ◯◯のデータは、ユーザー側で取得ができない情報のため、AWS サポートにて取得、提供いただけますでしょうか。 適切な緊急度の選択 情報のご提供には、お時間が掛かってしまう場合があります。お急ぎの場合は、問題の影響度と発生しているビジネス影響を添えて、高い緊急度でのお問い合わせをご検討ください。 サポートケースの緊急度の考え方については、 こちら をご覧ください。 AWS サポートご利用時のガイドライン AWS サポートの基本的なガイドラインをご一読いただくことで、迅速なサポートが可能となります。 お問い合わせいただく際に、 こちら をご一読ください。 トラブルシューティングで必要となる情報、および情報収集の手段についてご紹介いたしました。 ご不明な点等ございましたら、お気軽に AWS サポート へお問い合わせください。 クラウドサポートエンジニア　松原 睦美

多くの企業は、保守と拡張が困難になった古いテクノロジーで構築されたレガシーシステムに悩まされています。 この投稿では、 Amazon Bedrock Converse APIと Amazon Nova Premier をagentic workflow内で使用して、レガシーCコードを最新のJava/Springフレームワークアプリケーションに体系的に移行する方法を紹介します。移行プロセスを複数の専門エージェントで分担し、堅牢なフィードバックループを実装することで、組織は以下を達成できます: 移行時間とコストの削減 – 自動化により反復的な変換タスクを処理し、人間のエンジニアは高付加価値作業に集中できます コード品質の向上 – 専門的な検証エージェントが、移行されたコードの最新のベストプラクティスへの準拠を保証します リスクの最小化 – 体系的なアプローチにより、移行中に重要なビジネスロジックの損失を防ぎます クラウド統合の実現 – 結果として得られるJava/SpringコードはAWSサービスとシームレスに統合できます 課題 レガシーシステムから最新のフレームワークへのコード移行には、AI機能と人間の専門知識を組み合わせたバランスの取れたアプローチを必要とするいくつかの重要な課題があります: 言語パラダイムの違い – CコードをJavaに変換するには、メモリ管理、エラー処理、プログラミングパラダイムの根本的な違いをナビゲートする必要があります。Cの手続き型の性質と直接的なメモリ操作は、Javaのオブジェクト指向アプローチと自動メモリ管理とは大きく対照的です。AIは多くの構文変換を自動的に処理できますが、開発者はこれらの変換の意味的正確性をレビューおよび検証する必要があります。 アーキテクチャの複雑性 – レガシーシステムには、人間の分析と計画を必要とするコンポーネント間の複雑な相互依存関係が含まれていることがよくあります。我々のケースでは、Cコードベースには、一部のTP(Transaction Program)が最大12の他のモジュールに接続されているなど、モジュール間の複雑な関係が含まれていました。人間の開発者は依存関係マッピングを作成し、移行順序を決定する必要があります。通常は依存関係が最小のリーフノードから移行を開始します。AIはこれらの関係を識別するのに役立ちますが、移行シーケンスに関する戦略的決定には人間の判断が必要です。 ビジネスロジックの維持 – 変換中に重要なビジネスロジックが正確に保持されることを確認するには、継続的な人間の監視が必要です。我々の分析では、自動移行はシンプルで構造化されたコードには非常に成功していますが、大きなファイル(700行以上)に埋め込まれた複雑なビジネスロジックには、エラーや欠落を防ぐために慎重な人間のレビューと手動での改良が必要であることが示されました。 一貫性のない命名と構造 – レガシーコードには、移行中に標準化する必要がある一貫性のない命名規則と構造が含まれていることがよくあります。AIは多くのルーチン変換(関数名の英数字IDの変換、C形式のエラーコードのJava例外への変換、C構造体のJavaクラスへの変換など)を処理できますが、人間の開発者は命名標準を確立し、自動変換が曖昧になる可能性のあるエッジケースをレビューする必要があります。 統合の複雑性 – 個々のファイルを変換した後、まとまりのあるアプリケーションを作成するには人間が主導する統合が不可欠です。元のCファイル全体で一貫していた変数名は、個々のファイル変換中に一貫性がなくなることが多く、開発者は調整作業を実行し、適切なモジュール間通信を促進する必要があります。 品質保証 – 変換されたコードが元のコードと機能的に同等であることを検証するには、自動テストと人間による検証の組み合わせが必要です。これは複雑なビジネスロジックにとって特に重要です。微妙な違いが重大な問題につながる可能性があります。開発者は包括的なテストスイートを設計し、徹底的なコードレビューを実行して移行の正確性を確保する必要があります。 これらの課題には、大規模言語モデル(LLM)のパターン認識機能と構造化ワークフローおよび重要な人間の監視を組み合わせて、成功した移行結果を生み出す体系的なアプローチが必要です。鍵となるのは、AIを使用してルーチン変換を処理しながら、戦略的決定、複雑なロジック検証、品質保証のために人間をループに留めることです。 ソリューション概要 このソリューションは、Amazon Bedrock Converse APIとAmazon Nova Premierを使用して、体系的なagentic workflowを通じてレガシーCコードを最新のJava/Springフレームワークコードに変換します。このアプローチは、複雑な移行プロセスを管理可能なステップに分割し、反復的な改良とトークン制限の処理を可能にします。 ソリューションアーキテクチャは、いくつかの主要なコンポーネントで構成されています: Code analysis agent – Cコードの構造と依存関係を分析します Conversion agent – CコードをJava/Springコードに変換します Security assessment agent – レガシーコードと移行されたコードの脆弱性を識別します Validation agent – 変換の完全性と正確性を検証します Refine agent – validation agentからのフィードバックに基づいてコードを書き直します Integration agent – 個別に変換されたファイルを結合します 我々のagentic workflowは、堅牢なエージェントオーケストレーションとLLM推論のためにAmazon Bedrock Converse APIと組み合わせたStrands Agentsフレームワークを使用して実装されています。アーキテクチャ(次の図に示すように)は、Strandsのセッション管理機能とトークン継続のためのカスタムBedrockInference処理を組み合わせたハイブリッドアプローチを使用しています。 このソリューションは、以下のコアテクノロジーを使用しています: Strands Agentsフレームワーク(v1.1.0+) – エージェントライフサイクル管理、セッション処理、構造化されたエージェント通信を提供します Amazon Bedrock Converse API – Amazon Nova PremierモデルでLLM推論を実行します カスタムBedrockInferenceクラス – テキスト事前入力とレスポンス継続によりトークン制限を処理します Asyncioベースのオーケストレーション – 並行処理とノンブロッキングエージェント実行を可能にします ワークフローは以下のステップで構成されています: 1. コード分析: Code analysis agent – 変換要件を理解するために入力コード分析を実行します。Cコードベース構造を調べ、依存関係を識別し、複雑性を評価します。 フレームワーク統合 – 分析にBedrockInferenceを使用しながら、セッション管理にStrandsを使用します。 出力 – 依存関係マッピングと変換推奨事項を含むJSON構造化分析。 2. ファイル分類とメタデータ作成: 実装 – 複雑性評価を含むFileMetadataデータクラス。 Categories – Simple(0-300行)、Medium(300-700行)、Complex(700行以上)。 File types – 標準Cファイル、ヘッダーファイル、データベースI/O(DBIO)ファイル。 3. コード変換: Conversion agent – code analysis agentからの情報に基づいて個々のファイルのコード移行を実行します。 Token handling – トークン制限を超える大きなファイルを処理するためにstitch_output()メソッドを使用します。 4. セキュリティ評価フェーズ: Security assessment agent – レガシーCコードと変換されたJavaコードの両方で包括的な脆弱性分析を実行します。 Risk categorization – セキュリティ問題を重大度(Critical、High、Medium、Low)で分類します。 Mitigation recommendations – 具体的なコード修正とセキュリティベストプラクティスを提供します。 Output – アクション可能な修復ステップを含む詳細なセキュリティレポート。 5. 検証とフィードバックループ: Validation agent – 変換の完全性と正確性を分析します。 Refine agent – 検証結果に基づいて反復的な改善を適用します。 Iteration control – 満足のいく結果が得られた場合の早期終了を伴う最大5回のフィードバック反復。 Session persistence – Strandsフレームワークは反復間で会話コンテキストを維持します。 6. 統合と最終化: Integration agent – 個別に変換されたファイルの結合を試みます。 Consistency resolution – 変数命名を標準化し、適切な依存関係を提供します。 Output generation – まとまりのあるJava/Springアプリケーション構造を作成します。 7. DBIO変換: Purpose – SQL DBIO CソースコードをMyBatis XMLマッパーファイルに変換します。 Framework – 一貫性のために同じStrandsとBedrockInferenceハイブリッドアプローチを使用します。 ソリューションは以下の主要なオーケストレーション機能で構成されています: Session persistence – 各変換はエージェント相互作用間でセッション状態を維持します Error recovery – グレースフルデグラデーションを伴う包括的なエラー処理 Performance tracking – 処理時間、反復回数、成功率の組み込みメトリクス Token continuation – レスポンススティッチングによる大きなファイルのシームレスな処理 このフレームワーク固有の実装により、多様なCコードベース構造と複雑性を処理する柔軟性を維持しながら、信頼性が高くスケーラブルなコード変換が促進されます。 前提条件 このコード変換ソリューションを実装する前に、以下のコンポーネントが設定されていることを確認してください: AWS環境: Amazon Nova Premierモデルへのアクセス権限を含む、適切なAmazon Bedrock権限を持つAWSアカウント 開発とテスト用の Amazon Elastic Compute Cloud (Amazon EC2)インスタンス(t3.medium以上)またはローカルマシン 開発セットアップ: Python 3.10以上(Boto3 SDK、Strands Agentsライブラリをインストール済み) AWS CLI (適切な認証情報とリージョン設定済み) Git(バージョン管理用) テキストエディタまたはIDE(CとJavaコード対応) ソースとターゲットコードベースの要件: 整理された構造のCソースコード Java 11以上とMaven/Gradleビルドツール Spring Framework 5.xまたはSpring Boot 2.x以上 この投稿で使用されているソースコードとプロンプトは、 GitHubリポジトリ にあります。 エージェントベースの変換プロセス このソリューションは、Strandsフレームワークを使用して実装された洗練されたマルチエージェントシステムを使用しており、各エージェントはコード変換プロセスの特定の側面を専門としています。この分業アプローチは、多様なコード構造と複雑性を処理する柔軟性を維持しながら、徹底的な分析、正確な変換、包括的な検証を可能にします。 Strandsフレームワーク統合 各エージェントはBaseStrandsConversionAgentクラスを拡張し、Strandsセッション管理とカスタムBedrockInference機能を組み合わせたハイブリッド構成で実装しています: class BaseStrandsConversionAgent(ABC): def __init__(self, name: str, bedrock_inference, system_prompt: str): self.name = name self.bedrock = bedrock_inference # トークン処理のためのカスタムBedrockInference self.system_prompt = system_prompt # セッション管理のためのstrands agentを作成 self.strands_agent = Agent(name=name, system_prompt=system_prompt) async def execute_async(self, context: ConversionContext) -> Dict[str, Any]: # 各専門エージェントによって実装される pass Code analysis agent Code analysis agentは、Cコードベースの構造を調べ、ファイル間の依存関係を識別し、最適な変換戦略を決定します。このエージェントは、最初に変換するファイルに優先順位を付け、潜在的な課題を識別するのに役立ちます。 以下は、code analysis agentのプロンプトテンプレートです: You are a Code Analysis Agent with expertise in legacy C codebases and modern Java/Spring architecture. <c_codebase> {c_code} </c_codebase> ## TASK Your task is to analyze the provided C code to prepare for migration. Perform a comprehensive analysis and provide the following: ## INSTRUCTIONS 1. DEPENDENCY ANALYSIS: - Identify all file dependencies (which files include or reference others) - Map function calls between files - Detect shared data structures and global variables 2. COMPLEXITY ASSESSMENT: - Categorize each file as Simple (0-300 lines), Medium (300-700 lines), or Complex (700+ lines) - Identify files with complex control flow, pointer manipulation, or memory management - Flag any platform-specific or hardware-dependent code 3. CONVERSION PLANNING: - Recommend a conversion sequence (which files to convert first) - Suggest logical splitting points for large files - Identify common patterns that can be standardized during conversion 4. RISK ASSESSMENT: - Highlight potential conversion challenges (e.g., pointer arithmetic, bitwise operations) - Identify business-critical sections requiring special attention - Note any undocumented assumptions or behaviors 5. ARCHITECTURE RECOMMENDATIONS: - Suggest appropriate Java/Spring components for each C module - Recommend DTO structure and service organization - Propose database access strategy using a persistence framework Format your response as a structured JSON document with these sections. Conversion agent Conversion agentは、CコードからJava/Springコードへの実際の変換を処理します。このエージェントには、CとJava/Springフレームワークの両方の専門知識を持つシニアソフトウェア開発者の役割が割り当てられています。 Conversion agentのプロンプトテンプレートは以下の通りです: You are a Senior Software Developer with 15+ years of experience in both C and Java Spring framework. <c_file> {c_code} </c_file> ## TASK Your task is to convert legacy C code to modern Java Spring code with precision and completeness. ## CONVERSION GUIDELINES: 1. CODE STRUCTURE: - Create appropriate Java classes (Service, DTO, Mapper interfaces) - Preserve original function and variable names unless they conflict with Java conventions - Use Spring annotations appropriately (@Service, @Repository, etc.) - Implement proper package structure based on functionality 2. JAVA BEST PRACTICES: - Use Lombok annotations (@Data, @Slf4j, @RequiredArgsConstructor) to reduce boilerplate - Implement proper exception handling instead of error codes - Replace pointer operations with appropriate Java constructs - Convert C-style arrays to Java collections where appropriate 3. SPRING FRAMEWORK INTEGRATION: - Use dependency injection instead of global variables - Implement a persistence framework mappers for database operations - Replace direct SQL calls with mapper interfaces - Use Spring's transaction management 4. SPECIFIC TRANSFORMATIONS: - Replace PFM_TRY/PFM_CATCH with Java try-catch blocks - Convert mpfmdbio calls to a persistence framework mapper method calls - Replace mpfm_dlcall with appropriate Service bean injections - Convert NGMHEADER references to input.getHeaderVo() calls - Replace PRINT_ and PFM_DBG macros with SLF4J logging - Convert ngmf_ methods to CommonAPI.ngmf method calls 5. DATA HANDLING: - Create separate DTO classes for input and output structures - Use proper Java data types (String instead of char arrays, etc.) - Implement proper null handling and validation - Remove manual memory management code ## OUTPUT FORMAT: - Include filename at the top of each Java file: #filename: [filename].java - Place executable Java code inside <java></java> tags - Organize multiple output files clearly with proper headers Generate complete, production-ready Java code that fully implements all functionality from the original C code. Security assessment agent Security assessment agentは、元のCコードと変換されたJavaコードの両方で包括的な脆弱性分析を実行し、潜在的なセキュリティリスクを識別し、具体的な緩和戦略を提供します。このエージェントは、移行中にセキュリティの脆弱性が持ち越されないようにし、新しいコードがセキュリティのベストプラクティスに従っていることを確認するために不可欠です。 以下は、security assessment agentのプロンプトテンプレートです: You are a Security Assessment Agent with expertise in identifying vulnerabilities in both C and Java codebases, specializing in secure code migration practices. ORIGINAL C CODE: <c_code> {c_code} </c_code> CONVERTED JAVA CODE: <java_code> {java_code} </java_code> ## TASK Your task is to perform comprehensive security analysis on both the legacy C code and converted Java code, identifying vulnerabilities and providing specific mitigation recommendations. ## SECURITY ANALYSIS FRAMEWORK 1. **LEGACY C CODE VULNERABILITIES:** - Buffer overflow risks (strcpy, strcat, sprintf usage) - Memory management issues (dangling pointers, memory leaks) - Integer overflow/underflow vulnerabilities - Format string vulnerabilities - Race conditions in multi-threaded code - Improper input validation and sanitization - SQL injection risks in database operations - Insecure cryptographic implementations 2. **JAVA CODE SECURITY ASSESSMENT:** - Input validation and sanitization gaps - SQL injection vulnerabilities in persistence framework queries - Improper exception handling that leaks sensitive information - Authentication and authorization bypass risks - Insecure deserialization vulnerabilities - Cross-site scripting (XSS) prevention in web endpoints - Logging of sensitive data - Dependency vulnerabilities in Spring framework usage 3. **MIGRATION-SPECIFIC RISKS:** - Security assumptions that don't translate between languages - Privilege escalation through improper Spring Security configuration - Data exposure through overly permissive REST endpoints - Session management vulnerabilities - Configuration security (hardcoded credentials, insecure defaults) 4. **COMPLIANCE AND BEST PRACTICES:** - OWASP Top 10 compliance assessment - Spring Security best practices implementation - Secure coding standards adherence - Data protection and privacy considerations ## OUTPUT FORMAT Provide your analysis as a structured JSON with these fields: - "critical_vulnerabilities": array of critical security issues requiring immediate attention - "security_risk_issues": array of security concerns - "secure_code_recommendations": specific code changes to implement security fixes - "spring_security_configurations": recommended Spring Security configurations - "compliance_gaps": areas where code doesn't meet security standards - "migration_security_notes": security considerations specific to the C-to-Java migration For each vulnerability, include: - Description of the security risk - Potential impact and attack vectors - Specific line numbers or code sections affected - Detailed remediation steps with code examples - Priority level and recommended timeline for fixes Be thorough in identifying both obvious and subtle security issues that could be exploited in production environments. Validation agent Validation agentは、変換されたコードをレビューして、欠落または不正に変換されたコンポーネントを識別します。このエージェントは、後続の変換反復で使用される詳細なフィードバックを提供します。 Validation agentのプロンプトテンプレートは以下の通りです: You are a Code Validation Agent specializing in verifying C to Java/Spring migrations. ORIGINAL C CODE: <c_code> {c_code} </c_code> CONVERTED JAVA CODE: <java_code> {java_code} </java_code> ## TASK Your task is to thoroughly analyze the conversion quality and identify any issues or omissions. Perform a comprehensive validation focusing on these aspects: ## INSTRUCTIONS 1. COMPLETENESS CHECK: - Verify all functions from C code are implemented in Java - Confirm all variables and data structures are properly converted - Check that all logical branches and conditions are preserved - Ensure all error handling paths are implemented 2. CORRECTNESS ASSESSMENT: - Identify any logical errors in the conversion - Verify proper transformation of C-specific constructs (pointers, structs, etc.) - Check for correct implementation of memory management patterns - Validate proper handling of string operations and byte manipulation 3. SPRING FRAMEWORK COMPLIANCE: - Verify appropriate use of Spring annotations and patterns - Check proper implementation of dependency injection - Validate correct use of persistence framework mappers - Ensure proper service structure and organization 4. CODE QUALITY EVALUATION: - Assess Java code quality and adherence to best practices - Check for proper exception handling - Verify appropriate logging implementation - Evaluate overall code organization and readability ## OUTPUT FORMAT Provide your analysis as a structured JSON with these fields: - "complete": boolean indicating if conversion is complete - "missing_elements": array of specific functions, variables, or logic blocks that are missing - "incorrect_transformations": array of elements that were incorrectly transformed - "spring_framework_issues": array of Spring-specific implementation issues - "quality_concerns": array of code quality issues - "recommendations": specific, actionable recommendations for improvement Be thorough and precise in your analysis, as your feedback will directly inform the next iteration of the conversion process. Refine agentによるフィードバックループの実装 フィードバックループは、変換されたコードの反復的な改良を可能にする重要なコンポーネントです。このプロセスには以下のステップが含まれます: Conversion agentによる初期変換。 Security assessment agentによるセキュリティ評価。 Validation agentによる検証。 Refine agentによるフィードバックの組み込み(検証とセキュリティの両方のフィードバックを組み込む)。 満足のいく結果が得られるまで繰り返す。 Refine agentは、機能的な改善とともにセキュリティの脆弱性修正を組み込み、セキュリティ評価結果は本番デプロイメント前の最終レビューと承認のために開発チームに提供されます。 以下は、コード改良のためのプロンプトテンプレートです: You are a Senior Software Developer specializing in C to Java/Spring migration with expertise in secure coding practices. ORIGINAL C CODE: <c_code> {c_code} </c_code> YOUR PREVIOUS JAVA CONVERSION: <previous_java> {previous_java_code} </previous_java> VALIDATION FEEDBACK: <validation_feedback> {validation_feedback} </validation_feedback> SECURITY ASSESSMENT: <security_feedback> {security_feedback} </security_feedback> ## TASK You've previously converted C code to Java, but validation and security assessment have identified issues that need to be addressed. Your task is to improve the conversion by addressing all identified functional and security issues while maintaining complete functionality. ## INSTRUCTIONS 1. ADDRESSING MISSING ELEMENTS: - Implement any functions, variables, or logic blocks identified as missing - Ensure all control flow paths from the original code are preserved - Add any missing error handling or edge cases 2. CORRECTING TRANSFORMATIONS: - Fix any incorrectly transformed code constructs - Correct any logical errors in the conversion - Properly implement C-specific patterns in Java 3. IMPLEMENTING SECURITY FIXES: - Address all critical and high-risk security vulnerabilities identified - Implement secure coding practices (input validation, parameterized queries, etc.) - Replace insecure patterns with secure Java/Spring alternatives - Add proper exception handling that does not leak sensitive information 4. IMPROVING SPRING IMPLEMENTATION: - Correct any issues with Spring annotations or patterns - Ensure proper dependency injection and service structure - Fix persistence framework mapper implementations if needed - Implement Spring Security configurations as recommended 5. MAINTAINING CONSISTENCY: - Ensure naming conventions are consistent throughout the code - Maintain consistent patterns for similar operations - Preserve the structure of the original code where appropriate ## OUTPUT FORMAT Output the improved Java code inside <java></java> tags, with appropriate file headers. Ensure all security vulnerabilities are addressed while maintaining complete functionality from the original C code. Integration agent Integration agentは、個別に変換されたJavaファイルをまとまりのあるアプリケーションに結合し、変数命名の不整合を解決し、適切な依存関係を提供します。 Integration agentのプロンプトテンプレートは以下の通りです: You are an Integration Agent specializing in combining individually converted Java files into a cohesive Spring application. CONVERTED JAVA FILES: <converted_files> {converted_java_files} </converted_files> ORIGINAL FILE RELATIONSHIPS: <relationships> {file_relationships} </relationships> ## TASK Your task is to integrate multiple Java files that were converted from C, ensuring they work together properly. Perform the following integration tasks: ## INSTRUCTIONS 1. DEPENDENCY RESOLUTION: - Identify and resolve dependencies between services and components - Ensure proper autowiring and dependency injection - Verify that service method signatures match their usage across files 2. NAMING CONSISTENCY: - Standardize variable and method names that should be consistent across files - Resolve any naming conflicts or inconsistencies - Ensure DTO field names match across related classes 3. PACKAGE ORGANIZATION: - Organize classes into appropriate package structure - Group related functionality together - Ensure proper import statements across all files 4. SERVICE COMPOSITION: - Implement proper service composition patterns - Ensure services interact correctly with each other - Verify that data flows correctly between components 5. COMMON COMPONENTS: - Extract and standardize common utility functions - Ensure consistent error handling across services - Standardize logging patterns 6. CONFIGURATION: - Create necessary Spring configuration classes - Set up appropriate bean definitions - Configure any required properties or settings Output the integrated Java code as a set of properly organized files, each with: - Appropriate package declarations - Correct import statements - Proper Spring annotations - Clear file headers (#filename: [filename].java) Place each file's code inside <java></java> tags. Ensure the integrated application maintains all functionality from the individual components while providing a cohesive structure. DBIO conversion agent この専門エージェントは、SQL DBIO CソースコードをJava Springフレームワークのpersistence framework互換のXMLファイルに変換する処理を行います。 以下は、DBIO conversion agentのプロンプトテンプレートです: You are a Database Integration Specialist with expertise in converting C-based SQL DBIO code to persistence framework XML mappings for Spring applications. SQL DBIO C SOURCE CODE: <sql_dbio> {sql_dbio_code} </sql_dbio> ## TASK Your task is to transform the provided SQL DBIO C code into properly structured persistence framework XML files. Perform the conversion following these guidelines: ## INSTRUCTIONS 1. XML STRUCTURE: - Create a properly formatted persistence framework mapper XML file - Include appropriate namespace matching the Java mapper interface - Set correct resultType or resultMap attributes for queries - Use proper persistence framework XML structure and syntax 2. SQL TRANSFORMATION: - Preserve the exact SQL logic from the original code - Convert any C-specific SQL parameter handling to persistence framework parameter markers - Maintain all WHERE clauses, JOIN conditions, and other SQL logic - Preserve any comments explaining SQL functionality 3. PARAMETER HANDLING: - Convert C variable bindings to persistence framework parameter references (#{param}) - Handle complex parameters using appropriate persistence framework techniques - Ensure parameter types match Java equivalents (String instead of char[], etc.) 4. RESULT MAPPING: - Create appropriate resultMap elements for complex result structures - Map column names to Java DTO property names - Handle any type conversions needed between database and Java types 5. DYNAMIC SQL: - Convert any conditional SQL generation to persistence framework dynamic SQL elements - Use <if>, <choose>, <where>, and other dynamic elements as appropriate - Maintain the same conditional logic as the original code 6. ORGANIZATION: - Group related queries together - Include clear comments explaining the purpose of each query - Follow persistence framework best practices for mapper organization ## OUTPUT FORMAT Output the converted persistence framework XML inside <xml></xml> tags. Include a filename comment at the top: #filename: [EntityName]Mapper.xml Ensure the XML is well-formed, properly indented, and follows persistence framework conventions for Spring applications. トークン制限の処理 Amazon Bedrock Converse APIのトークン制限に対処するために、モデルが中断したところからコード生成を続行できる継続生成機能を実装しました。このアプローチは、モデルのコンテキストウィンドウを超える大きなファイルにとって特に重要であり、Strandsベースの実装における重要な技術的工夫を表しています。 技術実装 以下のコードは、継続生成機能を持つBedrock Inferenceクラスを実装しています: class BedrockInference: def __init__(self, region_name: str = "us-east-1", model_id: str = "us.amazon.nova-premier-v1:0"): self.config = Config(read_timeout=300) self.client = boto3.client("bedrock-runtime", config=self.config, region_name=region_name) self.model_id = model_id self.continue_prompt = { "role": "user", "content": [{"text": "Continue the code conversion from where you left off."}] } def run_converse_inference_with_continuation(self, prompt: str, system_prompt: str) -> List[str]: """大きな出力の継続処理で推論を実行""" ans_list = [] messages = [{"role": "user", "content": [{"text": prompt}]}] response, stop = self.generate_conversation([{'text': system_prompt}], messages) ans = response['output']['message']['content'][0]['text'] ans_list.append(ans) while stop == "max_tokens": logger.info("Response truncated, continuing generation...") messages.append(response['output']['message']) messages.append(self.continue_prompt) # 継続コンテキストのために最後の数行を抽出 sec_last_line = '\n'.join(ans.rsplit('\n', 3)[1:-1]).strip() messages.append({"role": "assistant", "content": [{"text": sec_last_line}]}) response, stop = self.generate_conversation([{'text': system_prompt}], messages) ans = response['output']['message']['content'][0]['text'] del messages[-1] # 事前入力メッセージを削除 ans_list.append(ans) return ans_list 継続戦略の詳細 継続戦略は以下のステップで構成されています: 1. レスポンス監視: システムはAmazon BedrockレスポンスのstopReasonフィールドを監視します。 stopReasonがmax_tokensに等しい場合、継続が自動的にトリガーされます。これにより、トークン制限によるコード生成の損失を防ぎます。 2. コンテキストの保持: システムは生成されたコードの最後の数行を継続コンテキストとして抽出します。 テキスト事前入力を使用してコード構造とフォーマットを維持します。継続間で変数名、関数シグネチャ、コードパターンを保持します。 3. レスポンスのスティッチング: def stitch_output(self, prompt: str, system_prompt: str, tag: str = "java") -> str: """複数のレスポンスを結合し、指定されたタグ内のコンテンツを抽出""" ans_list = self.run_converse_inference_with_continuation(prompt, system_prompt) if len(ans_list) == 1: final_ans = ans_list[0] else: final_ans = ans_list[0] for i in range(1, len(ans_list)): # オーバーラップを削除してレスポンスをシームレスに結合 final_ans = final_ans.rsplit('\n', 1)[0] + ans_list[i] # 指定されたタグ(java、xmlなど)内のコンテンツを抽出 if f'<{tag}>' in final_ans and f'</{tag}>' in final_ans: final_ans = final_ans.split(f'<{tag}>')[-1].split(f'</{tag}>')[0].strip() return final_ans 変換品質の最適化 実験を通じて、変換品質に大きく影響するいくつかの要因を特定しました: ファイルサイズ管理 – 300行を超えるコードファイルは、変換前に小さな論理単位に分割することで効果が向上します。 集中変換 – 異なるファイルタイプ(C、ヘッダー、DBIO)を個別に変換すると、各ファイルタイプが異なる変換パターンを持つため、より良い結果が得られます。変換中、C関数はクラス内のJavaメソッドに変換され、C構造体はJavaクラスになります。ただし、ファイルはクロスファイルコンテキストなしで個別に変換されるため、最適なオブジェクト指向設計を達成するには、関連する機能の統合、適切なクラス階層の確立、変換されたコードベース全体での適切なカプセル化を促進するために人間の介入が必要になる場合があります。 反復的な改良 – 複数のフィードバックループ(4〜5回の反復)により、より包括的な変換が生成されます。 役割の割り当て – モデルに特定の役割(シニアソフトウェア開発者)を割り当てると、出力品質が向上します。 詳細な指示 – 一般的なパターンに対する具体的な変換ルールを提供すると、一貫性が向上します。 前提条件 この移行戦略は以下の主要な前提条件を設けています: コード品質 – レガシーCコードは、識別可能な構造を持つ合理的なコーディング慣行に従っています。難読化された、または構造が不十分なコードは、自動変換前に前処理が必要になる場合があります。 スコープの制限 – このアプローチは、低レベルのシステムコードではなく、ビジネスロジックの変換を対象としています。ハードウェアとの相互作用やプラットフォーム固有の機能を持つCコードには、手動介入が必要になる場合があります。 テストカバレッジ – 移行後の機能的同等性を検証するための包括的なテストケースがレガシーアプリケーションに存在します。十分なテストがない場合、追加の検証ステップが必要です。 ドメイン知識 – agentic workflowはCとJavaの両方の専門知識の必要性を軽減しますが、重要なビジネスロジックの保持を検証するためにビジネスドメインを理解する主題専門家へのアクセスが必要です。 段階的移行 – このアプローチは、コンポーネントを個別に変換および検証できる段階的な移行戦略が許容されることを前提としており、プロジェクト全体レベルの移行ではありません。 結果とパフォーマンス Amazon Nova Premierを活用した移行アプローチの有効性を評価するために、典型的な顧客シナリオを代表するエンタープライズグレードのコードベース全体でパフォーマンスを測定しました。評価は2つの成功要因に焦点を当てました:構造的完全性(すべてのビジネスロジックと機能の保持)とフレームワーク準拠(Spring Bootのベストプラクティスと規約への準拠)。 コードベースの複雑性による移行精度 agentic workflowは、ファイルの複雑性に基づいて異なる効果を示し、すべての結果は主題専門家によって検証されました。以下の表は結果をまとめたものです。 ファイルサイズカテゴリ 構造的完全性 フレームワーク準拠 平均処理時間 Small(0-300行) 93% 100% 30〜40秒 Medium(300-700行) 81%* 91%* 7分 Large(700行以上) 62%* 84%* 21分 *複数のフィードバックサイクル後 エンタープライズ導入のための主要な洞察 これらの結果は重要なパターンを明らかにしています:agenticアプローチは、移行作業の大部分(小〜中規模ファイル)の処理に優れており、人間の監視を必要とする複雑なファイルに対しても依然として大きな価値を提供します。これにより、AIがルーチン変換とセキュリティ評価を処理し、開発者が統合とアーキテクチャの決定に集中するハイブリッドアプローチが実現します。 結論 我々のソリューションは、agentic workflow内で実装されたAmazon Bedrock Converse APIとAmazon Nova Premierが、レガシーCコードを最新のJava/Springフレームワークコードに効果的に変換できることを実証しています。このアプローチは複雑なコード構造を処理し、トークン制限を管理し、最小限の人間の介入で高品質の変換を生成します。 このソリューションは、変換プロセスを専門のエージェントロールに分割し、堅牢なフィードバックループを実装し、継続技術によりトークン制限を処理します。このアプローチは移行プロセスを加速し、コード品質を向上させ、エラーの可能性を減らします。 独自のユースケースでソリューションを試し、コメントでフィードバックと質問を共有してください。 著者について 余 錦澤 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Applied Scientist 木田 悠歩 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Deep Learning Architect 劉 雪峰 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Senior Data Science Manager Aditya Prakash AWS Generative AI Innovation Center，Senior Data Scientist Yash Shah AWS Generative AI Innovation Center，Science Manager

本記事は 2026 年 1 月 19 日に Migration & Modernization Blog で公開された “ Accelerating VMware Cloud Migration with AWS Transform and PowerCLI ” を翻訳したものです。 長年にわたり、クラウドマイグレーションプロジェクトは、断片的で手動のプロセスによって遅延してきました。検出には、複数のツールのデプロイと長い承認プロセスが必要でした。アセスメントは、手動分析または多大な時間を要するツールに依存していました。マイグレーション自体は、ウェーブプランニング、ネットワーク変換、サーバーオーケストレーションのための手動スクリプトに依存していました。このエンドツーエンドのジャーニーは、多くの場合、数か月にわたり、クラウド導入とモダナイゼーションのメリットを遅らせていました。 AWS Transform はこのパターンを変えます。VMware ワークロード、Windows、メインフレーム、ソフトウェアコードとライブラリのエンタープライズモダナイゼーションを加速するために構築された初のエージェント機能を持つ AI サービスです。AWS の 19 年間のマイグレーション経験を活用し、アセスメントやコード分析からリファクタリングや変換計画まで、これまで手動で行っていた作業を自動化する専門的な AI エージェントをデプロイします。多くのタスクを並行して実行することで、数百のアプリケーションを同時にモダナイゼーションできます。自然言語の会話型インターフェースと協働ワークスペースにより、部門横断チームがリアルタイムで協力して作業でき、組織がモダナイゼーションコスト、継続的なメンテナンス費用、レガシーライセンス料金を削減できるよう支援します。 お客様の VMware ワークロードのマイグレーションを支援するため、AWS Transform は 2 つの異なるサービスを提供しています: AWS Transform Assessments – コスト分析や移行推奨事項を含む、VMware インフラストラクチャのデータに基づくビジネスケースを無償で提供します AWS Transform for VMware – AI を活用した移行推奨事項、ウェーブプランニング、ネットワーク変換、サーバー移行を通じて、マイグレーションプロセスを自動化します 両方のサービスには、正確なインフラストラクチャデータが必要です。 RVTools や AWS Migration Evaluator などの従来の検出ツールは、セキュリティ要件、長い承認プロセス、運用上の制約により、デプロイメントの課題に直面することがよくあります。さらに、一部のツールはポイントインタイムデータのみをキャプチャし、マイグレーション中のサイジングの不一致につながる可能性のある重要な履歴使用パターンを見逃しています。 ソリューション: PowerShell ベースの VMware インベントリコレクター これらの課題に対処するため、従来の検出ツールのデプロイメントの摩擦を排除しながら、AWS Transform のデータ収集を効率化する PowerShell ベースのコレクターを開発しました。このスクリプトは、既存の PowerCLI 機能を使用して VMware vCenter に直接接続し、エージェントのインストールや長い承認プロセスを必要としません。また、VMware によって事前に収集されたデータを使用することで検出を加速し、AWS Transform がサポートする他のメカニズムを使用してデータをデプロイおよび収集するために必要な時間を節約できます。 このアプローチが AWS Transform のお客様にとって特に価値があるのは、マイグレーションに不可欠なデータに焦点を当てていることです。このコレクターは、お客様の VMware インフラストラクチャ全体で SQL Server データベースを検出でき、これは正確な移行計画の要件です。また、P95 パーセンタイル分析を使用して履歴パフォーマンスデータ (最大 365 日) をキャプチャし、ポイントインタイムスナップショットではなく実際のワークロードパターンを反映した適切サイジングの推奨事項を提供します。 セキュリティとコンプライアンスは、コア設計に組み込まれています。このツールは、自動メモリクリーンアップと SSL/TLS 証明書検証を備えたエンタープライズグレードの認証情報保護を実装しています。機密データを扱う組織向けに、このツールは、すべての出力形式でサーバー名、ホスト名、IP アドレスを匿名化する組み込みの匿名化機能を提供し、必要に応じて非匿名化のための可逆マッピングファイルを維持します。高度なフィルタリング機能により、お客様は特定の仮想マシン、クラスター、データセンター、または環境に収集範囲を限定できます。インフラストラクチャのスコープ設定が自動化されているため、関連するインフラストラクチャデータのみが収集されます。 出力形式オプション このコレクターは、3 つの出力形式をサポートしています。デフォルトでは、最適なパフォーマンスのために AWS Migration Portfolio Assessment (MPA) 形式を生成します。お客様は -outputFormat パラメーターを使用して、異なる形式または組み合わせを指定できます: 1. Migration Portfolio Assessment (MPA) 形式 (デフォルト) AWS Transform Assessments と AWS MPA プラットフォーム用に最適化 データベース検出シート: 検出されたデータベースインスタンス、エディション、バージョンを含む個別のワークシート (有効な場合) 最速の収集オプション 2. Migration Evaluator (ME) 形式 ME データインポートテンプレート AWS Migration Evaluator と互換性あり MPA 形式と同様のパフォーマンス 3. RVTools 類似形式 すべてのインフラストラクチャコンポーネント (仮想マシン、ホスト、ネットワーク、ストレージ、クラスター) を含む 移行計画のための AWS Transform for VMware および/または移行アセスメントのための AWS Transform Assessments へのインポートに対応 包括的なインフラストラクチャの関係性と依存関係 27 個の詳細な CSV ファイルを生成 (低速な収集) 3 つの形式すべてが、可逆マッピングによるオプションの匿名化をサポートしています: 匿名化されたサーバー名、ホスト名、IP アドレス 非匿名化のための個別のマッピングファイル すべての形式でデータの関係性を維持 詳細なドキュメントと完全な機能セットについては、 AWS Samples GitHub リポジトリ をご覧ください。 開始方法 前提条件 サポートされているオペレーティングシステム上の PowerShell 5.1 以降 VMware PowerCLI モジュール ImportExcel PowerShell モジュール 読み取り専用アクセス権を持つ vCenter Server 6.7 以降 統計収集が有効 ( VMware vSphere ドキュメント を参照) インストール # 必要な PowerShell モジュールをインストールします Install-Module -Name VMware.PowerCLI -Force Install-Module -Name ImportExcel -Force # PowerCLI を設定します Set-PowerCLIConfiguration -InvalidCertificateAction Warn -Confirm:$false Set-PowerCLIConfiguration -ParticipateInCEIP $false -Confirm:$false GitHub リポジトリ からコレクターをダウンロードします (詳細は README を参照してください) 。 基本的な使用方法 # 標準収集 (7 日間のパフォーマンスデータ、MPA 形式) .\vmware-collector.ps1 ` -address "vcenter.company.com" ` -username "readonly-user" ` -password "password" このコマンドは、すべての電源オン状態の仮想マシンからデータを収集し、 VMware_Export_YYYYMMDD_HHMMSS/ フォルダーに MPA テンプレート出力ファイル (デフォルト形式) を生成します。 一般的な使用シナリオ 拡張パフォーマンス収集 (30 日間): .\vmware-collector.ps1 ` -address "vcenter.company.com" ` -username "readonly-user" ` -password "password" ` -collectionDays 30 複数の出力形式を生成: # MPA と ME の両方の形式を生成します .\vmware-collector.ps1 ` -address "vcenter.company.com" ` -username "readonly-user" ` -password "password" ` -outputFormat "MPA,ME" # 3 つの形式すべてを生成します (低速) .\vmware-collector.ps1 ` -address "vcenter.company.com" ` -username "admin" ` -password "password" ` -outputFormat "All" データの匿名化: .\vmware-collector.ps1 ` -address "vcenter.company.com" ` -username "readonly-user" ` -password "password" ` -anonymize 主要なパラメーター 必須パラメーター: パラメーター タイプ 説明 例 address string vCenter Server の IP アドレスまたは FQDN “vcenter.company.com” username string vCenter のユーザー名 “user” password string vCenter のパスワード “password123” コアオプションパラメーター: パラメーター タイプ 説明 デフォルト collectionDays int 収集するパフォーマンスデータの日数 (1-365) 7 filterVMs string 電源オンの仮想マシンのみの場合は ‘Y’、すべての仮想マシンの場合は ‘N’ “Y” outputFormat string 出力形式: ‘MPA’ (デフォルト)、’ME’、’RVTools’、’MPA,ME’、または ‘All’ “MPA” anonymize switch 出力の匿名化バージョンを作成 Disabled enableLogging switch ファイルへのデバッグログを有効化 Disabled disableSSL switch SSL 証明書の検証を無効化 (デフォルトで有効) Disabled fastMode switch 高速モードを有効化 (詳細分析をスキップ) Disabled skipPerformanceData switch 履歴パフォーマンス収集をスキップし、CPU とメモリ使用率をそれぞれ 25% と 60% にデフォルト設定 Disabled maxParallelThreads int 処理の並列スレッド数 (1-50) 20 追加の高度なパラメーターと使用例については、技術 README を参照してください。 実行されると、スクリプトは図 1 に示すように、プロビジョニングと使用率の検出を開始します。 図 1: VMware Collector PowerShell スクリプトの実行 出力ファイルと統合 このコレクターは、3 つの出力形式を生成し、それぞれが特定の AWS マイグレーションツール用に最適化されています: RVTools 形式 – AWS Transform for VMware 用の完全なインフラストラクチャデータ ( VMware_collector_export_{date}.zip をアップロード) MPA 形式 – AWS Transform Assessments と Migration Portfolio Assessment 用の拡張テンプレート ( MPA_Template_{date}.xlsx をアップロード) ME 形式 – AWS Migration Evaluator 用のデータインポート ( ME_ConsolidatedDataImport_{date}.xlsx をアップロード) AWS Transform 統合 AWS Transform Assessments の場合: MPA_Template_{date}.xlsx ファイルを使用します データベース検出を含むすべての必要なデータが含まれています AWS Transform Assessments にアップロードします AWS Transform for VMware の場合: VMware_collector_export_{date}.zip ファイルを使用します 完全なインフラストラクチャデータ (クラスター、スイッチ、ネットワーク) が含まれています AWS Transform for VMware にアップロードします まとめ この投稿では、AWS Transform と Migration Evaluator のアセスメント用に VMware データ収集を簡素化する拡張 PowerShell スクリプトを紹介しました。このスクリプトは、正確な履歴パフォーマンスデータと高度なデータベース検出機能を備えた AWS Transform 互換の出力を生成します。 VMware マイグレーションを加速する準備はできていますか？ AWS Samples GitHub リポジトリ からコレクターをダウンロードし、数分でお客様のインフラストラクチャデータを収集し、無料のビジネスケースのために AWS Transform Assessments を開始するか、 AWS Transform for VMware に直接進んで AI エージェントにマイグレーションジャーニーを自動化させましょう。 詳細な技術ドキュメントと高度な設定オプションについては、リポジトリの README ファイルを参照してください。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。 Benoit Lotfallah Benoit は、ドイツの Amazon Web Services のシニアソリューションアーキテクトです。過去 5 年間、彼の主な焦点は、お客様のインフラストラクチャと運用を Amazon Web Services に移行する包括的なプロセスをガイドすることであり、シームレスでコスト効率の高いマイグレーションを確実にするために、彼の経験と専門知識を活用しています。

2025 年 7 月 4 日（金）および 2025 年 12 月 17 日（水）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #7（2025 年 7 月 4 日開催） ABC キャッチアップ配信 CMS をサーバーレスで構築してみた 朝日放送グループホールディングス株式会社 DX・メディアデザイン局 サービス開発チーム チーフ 金谷 洋佑 氏 朝日放送グループホールディングス株式会社では TVer や ABEMA 向けに公開している放送素材の管理を行う CMS を2016年頃から AWS 上で稼働していましたが、メタデータの仕様に大きな変更があったことや、Amazon EC2 と Amazon RDS をベースに構築したシステムで運用保守の負荷やコストに課題があったことから、サーバーレスサービスを用いた構成に全面刷新を行いました。CMS のフロントエンドは Amazon Cognito を用いたシングルサインオンと、 Amazon S3 の 静的ウェブサイトホスティング 機能を利用、バックエンドについては Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB を中心に構成し、社外システムとの連携に関わる部分で AWS Secrets Manager や Amazon SES なども利用しています。 本システムに登録されている2万件を超える放送素材の中から、社内ユーザーは出演者などをキーに必要な素材の検索を行いますが、これらのメタデータの蓄積や検索を、これまで使っていた Amazon RDS ではなく Amazon DynamoDB を用いて実現したことが今回のシステム刷新の中での最大のチャレンジでした。放送素材は通常、シリーズ、シーズン、エピソードという3つの階層で管理されていますが、これを一つのパーティションキーで管理したり、配信先や入稿済みかどうかの情報も一つのソートキーで管理したりするなど、複数の情報を 複合キーで表現 することや、 グローバルセカンダリインデックス を活用することで、ランニングコストの低い Amazon DynamoDB 上で、複雑なクエリを高速に実行することを可能としました。 従来 Amazon EC2 上で動かしていたロジックは 90 近くの Lambda 関数に置き換え、 AWS Compute Optimizer による奨励事項を適用することで適切なメモリーサイズの指定とコストの低減を実現することができました。Amazon S3 上に保管する映像素材についても、 S3 Glacier Instant Retrieval ストレージクラス を利用することでコストの低減を実現しています。サーバーレスサービスの活用と上述のさまざまなコスト低減策によって、AWS の費用を従来の 1/3 まで削減できました。 ライブキリトリ・タテ型動画生成システム 『シン・キリトリ君』の開発 讀賣テレビ放送株式会社 DX推進局 放送DX部 但馬 晋二 氏 今回開発した『シン・キリトリ君』は、収録した映像素材を専用の編集機上で編集、別の PC に編集後の素材を転送して SNS へと投稿という、複雑な縦型動画の制作フローをもっと簡単に実現したいという社内のニーズから生まれた、動画の切り取りと縦型動画への変換を行うシステムです。SNS の流行りに合わせたシステム改修が今後も続くことが予想される一方で、生成 AI の登場や AWS のマネージドサービスの利用でコーディング量を大きく減らすことができることから、讀賣テレビ放送株式会社では外注ではなく社内メンバーでの内製を選択しました。このシステムは、ライブ配信中にイン点とアウト点を指定して必要な映像素材を切り出す「収録アプリ」と、横型の動画から縦型の動画を切り出したり、縦型フォーマットに合わせた背景画像を挿入したりすることが可能な「切り出しアプリ」から構成されています。切り出しアプリは、複数の動画クリップから1つの動画を作成することや同一素材を複数ユーザーで共有することなども可能です。 Web アプリとして構築したことにより場所を問わず作業が可能になったことと、サーバーレスアーキテクチャの採用によって作業への立ち合いなどの作業負荷や AWS の利用コストを低減できたことが本システムの大きな特徴です。映像素材の変換には AWS Elemental MediaConvert を、動画の合成処理には AWS Lambda を利用しており、MediaConvert 上の変換処理が終了すると Amazon EventBridge 経由でイベントが発火し、AWS Lambda を用いた後処理を自動で開始できるようにしています。 本システムは他社でも活用されており今後も機能追加を進める予定です。既に Amazon EC2 上で YOLO モデルを実行することで物体や顔のトラッキングデータが取得できる ことを確認していますが、これらを活用した縦型動画の切り抜きや特定のシーンのみを集めた動画の作成、字幕の自動付与などにも今後チャレンジする予定でいます。 資料のダウンロードは こちら LT枠: AWS で文字起こし検証してみた 関西テレビ放送株式会社 DX推進局DX戦略部 兼 総合技術局制作技術センター 渡邊 真也 氏 近年の AI の発展によって多くの文字起こしサービスが乱立していることから、各社の文字起こしサービスの精度を比較してみました。AWS では Amazon Transcribe という音声テキスト変換サービスがあり、 音声の合計時間に基づいて課金 されます。ファイルを Amazon S3 バケットにアップロード、もしくはストリーミング形式によってデータの入力が可能で、特定の言語を指定することも、言語を自動識別させることも可能です。 今回は社内の人間に関西弁で話をしてもらい、これを正しく文字起こしできるかを確認しました。1分程度の素材の場合、出力結果が出るまで20-30秒掛かりました。他の文字起こしツールと比べても Amazon Transcribe の出力結果の精度は良く、専門ツールと張り合うことが可能な精度であると感じています。ファイルを入力する場合、一般ユーザーが Amazon S3 にファイルをアップロードすることに障壁があると感じていて、ユーザーに使い勝手の良い Web アプリ等を作成して、その裏側で Amazon Transcribe を動かすような実装が必要になりそうだと考えています。 LT枠: Amazon Nova を使ってみて 株式会社ytvメディアデザイン ICT技術 藤本 駿 氏 Amazon Nova を含む複数の生成 AI が、静止画から動画を作成したり、画像の描写を行う能力をどの程度持つのかについて調べてみました。影が物体に追従するような違和感の無い動画を生成するモデルもあれば、途中から新たな物体が急に登場する動画を生成するモデルもあり、モデルによって得手不得手があるようでした。 次に食べ物が写っている静止画を入力して、レストランの口コミサイトにあるようなグルメリポートを Amazon Nova に作成してもらいました。ある程度の精度のグルメリポートを作成することは可能でしたが、他のモデルと同様、食べ物によってはそれを正しく識別できなかったり、文字数のカウントが正しく行われないなどの課題もありました。各モデルの進化に期待したいと考えています。 LT枠: ラジオ番組ショート動画生成システム『クリボー(CRIVO)』 株式会社毎日放送 放送運営センター 送出担当 萬谷 和樹 氏 社内ハッカソンをきっかけに生まれた『クリボー(CRIVO)』は、アップロードしたラジオ番組の音声ファイルと静止画ファイルからショート動画を生成することのできるシステムです。30分の素材をアップロードすると、8分ほどの処理時間の中で5本のショート動画を作成することができます。これまでこの作業は人の手で4-5時間掛かっていました。 AWS Lambda を経由して外部の文字起こしサービスを利用、 Amazon Bedrock を用いて生成 AI に面白い箇所を選んでもらい、出力された動画ファイルを社内のチャットツールを経由して社内メンバーに共有するというアーキテクチャとなっています。これまでアプリケーション開発の経験はほぼありませんでしたが、社内ハッカソンから AWS を触り始めて今は他の開発メンバーと本システムの追加機能を鋭意進めています。 資料のダウンロードは こちら LT枠: クラウドスイッチャーで配信してみた 名古屋テレビ放送株式会社 方便 剛 氏 ケーブルレスでの制作環境の構築やクラウド上のソフトウェアスイッチャーを用いたコンテンツ制作の知見を蓄積するために、 Amazon EC2 上でソフトウェアスイッチャーの vMix を動かし 、その映像を 動画配信サイト Locipo で配信するということにチャレンジしました。vMix の操作は Stream Deck と呼ばれる物理スイッチを使ってリモートから行っていますが操作性に問題はありませんでした。 クラウドであるか無いかに関わらず、局舎外に映像を伝送する場合には伝送や処理に掛かる遅延が気になるところですが、ともに AWS 上で構築している vMix と Locipo の配信基盤との間は、遅延を3秒以内に収めることができました。またこの配信の後に vMix 上の設定を見直したところより低遅延での配信も実現できたため、今後の配信でこれらの知見を活かせるのではないかと考えています。 資料のダウンロードは こちら AWS メディア業界向け勉強会 #8（2025 年 12 月 17 日開催） カンテレのクラウドセキュリティ第一歩 関西テレビ放送株式会社 DX推進局 DX戦略部 主事 石井 克典 氏 関西テレビ放送株式会社では AWS 上での会計システムの本格稼働を前に、AWS のアカウントチーム、株式会社 JSOL、Security-JAWS などに助言を求めながら、クラウド上で稼働するワークロードに対する、セキュリティ対策の標準化を行いました。一定レベルの安全性を全てのワークロードで担保すること、組織として対応にあたることでセキュリティ対策の継続性や作業負荷の軽減を実現することがこの取り組みの狙いです。 主な対策として AWS セキュリティ成熟度モデル に記載の優先度の高いアクションの実行 AWS Control Tower の有効化とその一機能である リージョン拒否コントロール の活用 ベストプラクティス に基づいたマルチアカウント環境の構築 在阪放送局セキュリティガイドライン に基づいた Amazon GuardDuty , AWS Security Hub CSPM , AWS IAM Access Analyzer 等の AWS のセキュリティ、アイデンティティ、ガバナンスサービスの有効化 などを行っています。当初はこれらのサービスを有効化することに対するコスト増を懸念していましたが、AWS 全体のコストに占めるこれらのサービスの利用料は想定範囲に収まっています。今後は立ち上げたばかりの AWS 活用・推進チームを人材育成などを通じてより強化するとともに、作業の自動化を推し進めることでより少ない負荷でのクラウドの運用や維持を実現を目指します。 資料のダウンロードは こちら 内製の著作権管理システムを AWS へ──移行を通して見えた「設計の真価」 株式会社毎日放送 コンテンツ戦略局 プラットフォームビジネス部 山下 遼河 氏 著作権管理システムをクラウドサービスから AWS へと移行する際に考慮した「調査性の向上」「同型性の実現」「複雑さの上限を設定」という3つの設計の考え方についてお話しをいただきました。調査性の向上、つまり内部状態の確認とデバッグをより容易に実現するために、これまで使用していたクラウドサービスでは実現が難しかったコンテナ内部へのアクセスを、 Amazon ECS およびその一機能である ECS exec を用いることで実現しました。また AWS Lambda と Amazon CloudWatch を組み合わせて、エラーの通知などをリアルタイムに Slack に送るなどの工夫も施しています。 同型性の実現、つまりローカル環境やステージング環境、本番環境を可能な限り同じ構造で動かすために行ったこととしては、非同期処理を従来のクラウドサービスベースのものから Rails で一般的な Sidekiq と Redis の構成へ変更したことや、それによってローカル環境でも本番時と同じ Sidekiq の処理フローを再現できるようになったことがあります。これによりローカルと本番の動作の差異が解消され、ローカル環境でのデバッグや検証作業の精度が大幅に向上しました。また、複雑さの上限を設定、つまり対応できる担当者が限られてしまうほどの複雑性をシステムに持たせたり、過剰にコストが掛かりすぎることを防ぐために、各コンポーネントが満たすべき可用性を個別に判断して、コンポーネントによってはあえてマネージドサービスを採用せずに Amazon EC2 上で機能構築するなどの判断も行っています。 人事異動等による開発メンバーの交代もありうる中で、低い負荷でシステムを育てそれを運用するためには、これら3つの設計原則は非常に重要です。またこれを実現するために、 AWS Cloud Development Kit (CDK) によるインフラストラクチャーの開発や CI/CD パイプラインの構築によるデプロイの自動化も行っています。 資料のダウンロードは こちら 内製ってたのしいよ 東海テレビ放送株式会社 総務局システム部 兼 デジタルビジネス局コンテンツ事業部 瀧 祐作 氏 東海テレビ放送株式会社の AWS の利用は古くは公式サイトの AWS 移行に始まり、視聴者投票システム、 プレゼント応募システム 、データ放送中間サーバ、 AI を用いた PR 文の作成 などのシステムについても、社内のメンバーで内製して AWS 上で稼働させています。内製する最も大きなメリットは、自分たちで決めた仕様に沿ってシステムをすぐに作ったり変更を加えたりできること。自由度の高さやオンプレ時と比べてコスト削減できる点も AWS を用いて内製する際の大きな魅力だと感じています。内製する中で新たな技術スタックを試すことは、自身のスキルアップにも貢献します。 内製の取り組みを進める中で最近開発したのは、電話や FAX 等を介して視聴者から寄せられるご意見を集約する「番審システム 」です。AI の手を借りた Vibe Coding へのチャレンジや AWS Cloud Development Kit (CDK) によるインフラストラクチャーの開発、CI/CD パイプラインを用いたデプロイもこのプロジェクトの中で実現しており、ベンダーに外注する場合と比べて数週間単位でスケジュールを短縮することができました。 DevSecOps の考え方にも注力しており、現在の CI/CD パイプラインをより強化していくことも今後予定しています。 資料のダウンロードは こちら LT枠: クラウドマスター実現に向けた機能拡充の研究 関西テレビ放送株式会社 総合技術局放送推進センター 主任 中道 尚宏 氏 関西テレビ放送株式会社では、 Inter BEE におけるクラウドを活用した各社のマスター展示 などを受けて、自社でもそれを検証する取り組みを進めています。2024年の夏頃から AWS メディアサービス を用いてマスター機能の実現に取り組み、すぐに環境を立ち上げたり落としたりできるクラウドのメリットを最大限享受すべく、最近では AWS CloudFormation を用いた Infrastructure as Code（IaC）の実現にもチャレンジしています。 現在は AWS メディアサービスを用いた映像ストリームの処理と、時刻制御などのロジック、またそれを外部から制御するための API 等を構築済みで、今後は Amazon CloudWatch のメトリクスをベースにしたモニタリングや、 Amazon SageMaker AI を用いて独自モデルを作成するなどして、異常が起こる前にそれに気づくための異常予知システムの実現を予定しています。 資料のダウンロードは こちら LT枠: 「AWS の呼吸 壱ノ型：Twelvelabs 動画分析!!」～全集中で”AI 柱”を目指す～ 九州朝日放送株式会社 谷本 亮輔 氏 九州朝日放送株式会社では、技術メンバーが各部署へ足を運び、現場のニーズをヒアリングして、内製によってこれらに応える取り組みを進めています。その活動により、280件ほどのニーズを収集し、現在は80件ほどが解決に至っています。こうした取り組みを継続する中で、未着手の課題を精査したところ、分析や切り出し等の放送素材に関する要望が複数部署から寄せられており、業務効率化への期待が非常に高いことが判明しました。そこで、動画理解が可能なマルチモーダル基盤モデル（FM）である TwelveLabs Pegasus を用いて、映像分析を行うアプリケーションを開発しました。 このアプリケーションに放送素材をアップロードすると、映像と音声を同時に分析し、この素材に含まれるコンテンツを時系列順に抽出・要約して表示します。これにより、番組や素材構成を一目で把握できます。また、解析結果として表示される各項目をクリックするだけで、該当箇所から即時に再生できる仕組みを取り入れました。あわせて、イン点とアウト点の指定（尺指定）、もしくは範囲を視覚的にドラッグすることで、任意部分だけを切り出してダウンロードすることができます。これにより、編成部署における「放送内容と視聴率データの照合による人気コーナーの特定や、番組改編に向けた検討材料の創出」、営業部署における「取引先が露出した箇所の抽出・切り出しおよび送付業務」といった、これまで複数名で多大な時間を要していた手作業が、低く見積もっても従来の10分の1程度の時間で完結できる見通しとなりました。また、1時間の素材をわずか5～10分ほどで解析完了できる処理スピードは、実運用への移行に向けた強力な足掛かりとなっています。 本アプリケーションは、フロントエンドに React を使用。 Amazon S3 に保存した放送素材に対して Amazon Bedrock 上の TwelveLabs Pegasus で分析を行い、その結果を Amazon DynamoDB に格納しています。 資料のダウンロードは こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。内容について詳しく知りたい方は、記事上部より資料のダウンロード及び動画を視聴いただけますのでご確認ください。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

こんにちは! 私にとって 2026 年最初の記事になるこの記事は、家の前の雪に埋まった車道が掘り起こされるのを見ながら書いています。皆さんがこれを読んでいる場所が安全で暖かく、データの流れが止まっていませんように! 2026 年 1 月 26 日週は、GPU 集約型のワークロードを実行するお客様にとってうれしいニュースをお届けします。NVIDIA 最新の Blackwell アーキテクチャを搭載した最新のグラフィックスおよび AI 推論インスタンスがリリースされました。いくつかのサービス強化やリージョン拡大に加えて、今週のアップデートは AWS のお客様が利用できる機能も拡大し続けています。 2026 年 1 月 19 日週のリリース こちらは、私が興味深いと感じたプロジェクト、ブログ記事、ニュースです。 Amazon EC2 G7e インスタンスの一般提供開始 – NVIDIA RTX PRO 6000 Blackwell Server Edition GPU によって高速化された新しい G7e インスタンスは、G6e インスタンスよりも最大 2.3 倍優れた推論パフォーマンスを提供します。2 倍の GPU メモリを搭載し、最大 8 個の GPU をサポートすることで合計 768 GB の GPU メモリを提供するこれらのインスタンスでは、単一の GPU を用いて最大 70B パラメータの中規模モデルを FP8 の精度で実行できます。G7e インスタンスは、生成 AI 推論、空間コンピューティング、および科学コンピューティングワークロードに最適です。現在は、米国東部 (バージニア北部) と米国東部 (オハイオ) でご利用いただけます。 Amazon Corretto の 2026 年 1 月付け四半期更新 – AWS は、OpenJDK の Amazon Corretto Long-Term Supported (LTS) バージョンに対する四半期ごとのセキュリティ更新と重要更新をリリースしました。Corretto 25.0.2、21.0.10、17.0.18、11.0.30、および 8u482 が利用可能になったため、Java 開発者は最新のセキュリティパッチとパフォーマンス改善にアクセスできます。 Amazon ECR がリポジトリ間でのレイヤー共有のサポートを開始 – Amazon Elastic Container Registry では、blob マウントを使用することで共通のイメージレイヤーをリポジトリ間で共有できるようになりました。この機能により、既存のレイヤーを再利用することでイメージプッシュをより迅速に実行するとともに、共通のレイヤーを一度だけ保存し、リポジトリ間でそれらを参照することでストレージコストを削減できます。 Amazon CloudWatch Database Insights がさらに 4 つのリージョンに拡大 – CloudWatch Database Insights のオンデマンド分析が、アジアパシフィック (ニュージーランド)、アジアパシフィック (台北)、アジアパシフィック (タイ)、メキシコ (中部) でも利用可能になりました。この機能は、機械学習を使用することでパフォーマンスボトルネックの特定を助け、具体的な修正アドバイスを提供します。 Amazon Connect がステップバイステップガイドに条件付きロジックとリアルタイム更新を追加 – マネージャーは、ユーザーのやり取りに応じて適応する動的なガイド付きエクスペリエンスを構築するために Amazon Connect のステップバイステップガイドを使用できるようになりました。また、フィールドを表示または非表示にする、デフォルト値を変更する、または以前の入力に基づいて必須フィールドを調整するドロップダウンメニューを備えた条件付きユーザーインターフェイスも設定できます。この機能は Connect リソースからの自動データ更新もサポートしているため、エージェントは常に最新の情報を用いて作業できます。 今後の AWS イベント 今後のイベントをチェックしてサインアップしましょう。 Best of AWS re:Invent (1 月 28～29 日、バーチャル) – AWS re:Invent からの最もインパクトのある発表と、一番人気のセッションをお届けする無料のバーチャルイベントにご参加ください。オープニングセッションでは、AWS VP 兼 Chief Evangelist である Jeff Barr がハイライトをご紹介します。セッションは、アメリカ大陸: 1 月 28 日午前 9 時 (太平洋標準時)、アジア太平洋/日本: 1 月 29 日午前 9 時 (シンガポール時間)、欧州/中東/アフリカ: 1 月 29 日午前 9 時 (中央ヨーロッパ標準時) に開催されます。セッションに登録して、厳選された技術的学習、AWS リーダーからの戦略的インサイト、AWS エキスパートとのライブ Q&A にアクセスしましょう。 AWS Community Day Ahmedabad (2026 年 2 月 28 日) – 第 11 回目のこのコミュニティ主導 AWS カンファレンスでは、エキスパート主導のテクニカルセッション、実在のユースケース、ライブデモを行う技術展示ブース、およびネットワーキング機会のためにクラウドプロフェッショナル、開発者、アーキテクト、学生が一堂に会します。この無料イベントでは、朝食、昼食、限定ノベルティグッズが提供されます。 AWS Builder Center に参加して、AWS コミュニティのビルダーと学び、構築し、交流しましょう。お住まいの地域で今後開催される対面イベントとデベロッパー向けのバーチャルイベントをご覧ください。 2026 年 1 月 26 日週のニュースは以上です。2026 年 2 月 2 日週の Weekly Roundup もお楽しみに! – Micah 原文は こちら です。

本記事はAWSとSAPが共同で執筆しました。成功したパートナーシップとこのブログ記事への貢献について、SAP Joule For Consultantチームの Sachin Kaura 氏に感謝いたします。 はじめに：コンサルタントが直面する課題 SAPコンサルタントが複雑なクラウドトランスフォーメーションプロジェクトに取り組む機会が増える中、重要な実装ガイダンスやベストプラクティスへのアクセスが課題となっています。コンサルタントは、特定のお客様のシナリオに適した情報を見つけるために、膨大なドキュメント、認定資料、SAP Knowledge Base記事を検索することに貴重な稼働時間を費やすことがよくあります。主要な実装手順、構成の詳細、トラブルシューティングガイダンスは複数のソースに分散しているため、コンサルタントはお客様に価値を提供することに集中すべき時間を技術ドキュメントの検索に費やしています。これにより、プロジェクトの提供が遅延し、チームが重要な実装フェーズで期限を守るのに苦労するため、手戻りのリスクが増加します。 これらの課題に対処するため、SAPチームはAWSと提携して SAP Joule for Consultants（J4C） を開発しました。 Amazon Bedrock を介した Anthropic の Claudeモデル を使用することで、J4CはSAPの最も権威があり包括的な知識への自然言語アクセスを提供します。このイノベーションにより、コンサルタントは権威あるSAPコンテンツとの会話型AI対話を通じて、技術的な実装要件を迅速にナビゲートし理解できます。J4Cは、コンサルタントがビジネス要件を具体的な実装に変換するのを支援します。 SAP Joule for Consultantsとは？ SAP Joule for Consultants は、 SAP Joule アシスタントの会話型AI機能であり、コンサルタントがSAPの最も独占的で最新のナレッジベースを使用して、専門家のガイダンスによりSAPプロジェクトを加速するのを支援します。Jouleアシスタントのこのコンサルティング機能は、独占的なSAPコンテンツに基づいた迅速で信頼性の高い回答を提供し、設計上の意思決定を支援し、ベストプラクティスとの整合性を確保することで、コンサルタントの生産性を向上させるように設計されています。 Joule for ConsultantsがSAPコンサルタントとパートナーを支援する方法 SAP Joule for Consultantsを使用すると、コンサルタントは特定のビジネスシナリオのソリューションを迅速に評価し、実装のベストプラクティスにアクセスできます。この機能は、長いドキュメントを会話形式でアクセス可能なガイダンスに変換し、広範な検索を必要としないため、プロジェクト提供中に費やす時間を大幅に削減します。ジュニアコンサルタントとエキスパートの両方を含むコンサルタントは、お客様とのエンゲージメントに取り組む際の効率が向上し、専門知識がリアルタイムのコンテキストでよりアクセスしやすくなります。その結果、情報やドキュメントの検索に費やす時間が減り、お客様や個人的な対話により多くの時間を費やすことができます。 基盤の構築：ビジョンから最初の展開まで Claudeモデルを特徴とする Amazon BedrockとSAPのGenerative AI Hubの統合 が発表された後、AWSはSAPのJouleチームと協力ワークショップを開始し、SAPの膨大な認定資料、ナレッジベース記事、コミュニティコンテンツのリポジトリを生成AI強化の主要候補として特定しました。 プロジェクトは、品質と精度を確保するための包括的な評価データセットの作成から始まりました。チームは、 learning.sap.com/certifications の広範な認定カタログを通じて、SAPの既存の資料を活用しました。このアプローチでは、既に存在する構造化された質問と回答のペアを利用し、包括的な評価データセットを作成できました。重要なブレークスルーは、質問と回答のペアを使用して完全に自動化されたデータ駆動型評価パイプラインを開発したことでした。このアプローチにより、チームは複数の候補モデルとRetrieval-Augmented Generation（RAG）実装を迅速かつ体系的にベンチマークできました。 チームは、モデルのパフォーマンスを最適化するために一連のプロンプトエンジニアリング実験を行いました。例えば、「あなたは専門のSAPテスト受験者です」のような権威ある言葉を使用すると、「あなたはSAPテスト受験者として行動しています」のような控えめな表現よりも大幅に良い結果が得られることを発見しました。認定データセットに対する継続的なテストによって導かれたこれらの改良は、コンサルタント向けの対話のベストプラクティスを確立するのに役立ちました。さらに、チームは、評価データセットに意図的にひっかけ問題を使用するよりも、実際のQ&Aの方が効果的であることを発見しました。 アーキテクチャの詳細：バックボーンとしてのRetrieval Augmented Generation 「Joule For Consultant」プロジェクトは、Retrieval-Augmented Generation（RAG）パターンを活用して、SAP認定学習資料、SAP KBA、SAP Notesから直接コンサルタントのクエリに正確な回答を提供することに焦点を当てています。認定資料はマルチモーダルであり、テキスト、画像、チャートが含まれており、Anthropic Claudeモデルはこれらの理解に優れています。 RAGシステムには、SAPの広範な認定ナレッジリポジトリに合わせたデータ取り込みおよび処理パイプラインが含まれていました。SAP認定資料の構造化および非構造化ドキュメントが体系的に収集、クレンジングされ、検索可能な形式にチャンク（小さな単位）に分割されました。主要なステップには、テキスト、メタデータ（SAP製品バージョン、適用性、実装フェーズなど）の抽出、およびドキュメント間の相互参照の解決が含まれます。セマンティックチャンキングなどの前処理技術が適用され、SAP固有の技術的なニュアンスを保持しながら、コンテンツを文脈的に意味のある単位にセグメント化しました。これらのチャンクは、RAG実装のために高次元ベクトル埋め込みにエンコードされました。処理されたデータは、高速類似性検索用に最適化されたHANAベクトルエンジンにインデックス化され、検索中にコンサルタントのクエリを最も関連性の高いSAPコンテンツに効率的にマッピングできるようにしました。 クエリフェーズでは、RAGサービスは検索と生成を組み合わせて、正確なコンサルティングガイダンスを提供します。コンサルタントがクエリを送信すると、システムはまずベクトルデータベースを活用して、クエリの意図と意味的に整合した上位のSAPナレッジスニペットを取得します。優先順位付けステップでは、関連性スコア、コンテンツの新しさ、または適用性基準に基づいて結果を優先順位付けし、最新で実用的なインサイトを確保します。取得されたコンテキストは、SAPのGenerative AI Hubを介してAmazon BedrockのClaudeモデルに供給され、コンサルティングシナリオに合わせた簡潔な自然言語応答を合成します。重要なことに、応答は取得されたソースに厳密に基づいており、透明性とさらなる探索のために元のSAPドキュメントへの組み込み引用が含まれています。このハイブリッドアプローチは、速度と精度のバランスを取り、コンサルタントがリアルタイムで実装の課題を解決できるようにし、ハルシネーション（AIによる誤った情報生成）を最小限に抑え、従来のサポートチャネルへの依存を減らし、プロジェクトの提供を加速します。 お客様の価値とメリット SAP Business AIおよびSAP Joule for Consultantsのチーフアーキテクトである、Sachin Kaura氏によると： 「SAP Joule for Consultantsは、SAPの権威あるナレッジベース（ 2,500万を超えるドキュメントと12テラバイトのSAP専門知識データ にわたる）で構築されており、数秒で明確で引用された回答を提供します。 Amazon Bedrock上のAnthropic Claudeモデルを活用することで 、SAPのグローバルコンサルティングエコシステムに対してこの機能を拡張し、あらゆるレベルのコンサルタントをサポートし、チームが お客様向けにSAPプロジェクトを最大14%高速化 して提供できるよう支援しています。」 追加のお客様の声とインサイトについては、 SAP Joule for Consultantsページ をご覧ください。 SAP J4Cを通じてコンサルティング体験を向上させるSAPの取り組みは、SAPパートナーエコシステム全体に大きなビジネス価値を提供します。ビジネスへの影響は、個々のコンサルタントの生産性を超えて広がります。SAPのパートナーエコシステムでは、コンサルタントの効率の向上は、大規模な経済的利益につながります。SAP J4Cは、信頼できるSAPナレッジへの即座のアクセスを通じて、コンサルタントが1日あたり最大1.5時間を節約し、SAPプロジェクトのタイムラインを大幅に短縮します。 結論 SAP Joule for Consultantsは、エンタープライズコンサルティングの課題に生成AIを思慮深く適用することの変革的な影響を示しています。SAPのGenerative AI Hubを通じたAmazon Bedrock上のAnthropicのClaudeモデルの統合を活用することで、チームは、SAPの膨大なコンサルティングナレッジリポジトリに対する会話型AI機能を実装することで、ナレッジアクセシビリティの根本的な問題に対処しました。このソリューションは、複雑な実装プロジェクト中に権威あるSAPガイダンスへの効率的なアクセスという重要なニーズに対応しています。 SAP Joule for Consultantsを探索し、生成AIがコンサルティングプラクティスとプロジェクト提供能力をどのように変革できるかを直接確認し、Amazon BedrockとAnthropic Claudeのページをレビューして、これらのテクノロジーをより深く理解することをお勧めします。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

SAPを運用する企業は、SAP S/4HANAの実装、技術的負債の削減、新しいビジネス機能の提供といった課題に直面しています。お客様からは、SAP S/4HANAへの移行時にアップグレードが必要なカスタムSAP ABAPプログラムが数千個あるという声を良く伺います。これらのSAP ABAPプログラムはドキュメントが不足していることが多く、トランスフォーメーションプロジェクトと日常的なサポートの両方をさらに複雑にしています。さらに、SAP開発者は、SAP CAP（cloud application programming）やSAP RAP（Restful ABAP Programming model）のようなクリーンコアプログラミングモデルとともに、最新のSAP ABAPプログラミングモデルを採用するために高い学習障壁に直面しています。 私たちは、お客様がソフトウェア開発ライフサイクル（SDLC）全体を支援するために、ABAP Acceleratorを提供開始します。ABAP AcceleratorはMCPサーバーで、お客様がより速く、より高いコード精度でコードを作成、テスト、ドキュメント化、変換することを支援します。ABAP Acceleratorは、SAP ABAP Test Cockpitに接続してコードを検証し、含まれるカスタムコードを取得することで、開発者がハルシネーションを削減するのに役立ちます。 Kiro CLI 内で、お客様はABAP Acceleratorをインストールした後、大量のコード分析と変換を実行できます。 ABAP AcceleratorがSAP開発ライフサイクルを最適化する6つの方法をご紹介します： 1. SAP ECCからSAP S/4HANAへの自動コード変換 ABAP Acceleratorは、レガシーECC ABAPコードをS/4HANA互換コードに自動的に変換し、移行プロジェクトごとに数百または数千の開発時間を節約できる可能性があります。SAPのABAP Test Cockpitと直接統合することで、ABAP Acceleratorは変換がSAPの品質基準を満たしながら、ビジネスロジックを保持することを保証します。 要点：S/4HANAマイグレーション中の手動変換作業の大幅な削減。 2. SAP ABAP Test Cockpitとの統合 ABAP Acceleratorは、SAP環境に直接接続することで、システムを認識したコード生成を実行します。構文チェックを実行し、カスタムバリアントでABAP Test Cockpit（ATC）検証を実行し、オブジェクトのアクティベーションを自動的に処理します。このアプローチにより、生成されたコードがSAPの要件とお客様のガイドラインの両方に準拠し、生成AIツールに共通する「ハルシネーション」を削減します。ATCがコードの問題（構文、セキュリティ、パフォーマンス、命名規則など）を特定した場合、ABAP Acceleratorはコードを修正し、解決されるまで複数のサイクルを繰り返します。 要点：初回コード品質の向上、デバッグサイクルの削減、本番環境への迅速なデプロイ。 3. トランスフォーメーションのリスクを軽減するテスト駆動開発（TDD） ABAP Acceleratorは、トランスフォーメーションリスクを削減するためのテスト駆動アプローチを実装します。既存のプログラムを分析し、現在の機能をドキュメント化する単体テストを生成することから始まり、プログラムの動作のベースラインを確立します。このベースラインを検証した後、ABAP Acceleratorは変更を実装します。 新しい機能が追加されると、システムはテストスイートを拡張して既存の機能と新しい機能の両方をカバーし、完全なスイートを実行して100%のカバレッジを確保します。このアプローチは、構文的に正しいコードでも、ビジネス機能を壊す可能性のある論理エラーが含まれている可能性があるため、非常に重要です。これらのテストスイートは、オブジェクトのライフサイクル全体を通じてリグレッションテストのための永続的な資産となり、システムメンテナンス、SAP S/4HANAマイグレーション、技術アップグレード中の意図しない結果から保護します。 要点：プロジェクトリスクの削減と、永続的なテスト資産による長期的なコード保守性の向上。 4. 合理化されたクリーンコア開発 RESTful ABAP Programming Model（RAP）を採用するチームのために、ABAP Acceleratorは開発プロセス全体をガイドします。CDSビュー、動作定義、サービス定義、サービスバインディングを含むRAPアーティファクトを生成し、各実装ステップの背後にある決定を説明します。たとえば、シンプルなQ Developerプロンプトで、フロントエンド、バックエンドCDSビュー、およびすべての相互依存オブジェクトを含む完全なFioriアプリケーションを構築できます。 このアプローチにより、開発者はRAPアーキテクチャを学びながらビジネスロジックに集中できます。ABAP Acceleratorは技術的なセットアップとアクティベーションプロセスを処理し、最新のSAP開発パターンに移行するチームの開発タイムラインと学習曲線を加速します。 要点：学習曲線を削減しながら、クリーンコアと最新のSAP開発プラクティスの迅速な採用。 5. 常に最新のドキュメント ABAP Acceleratorは、作成または変更するすべてのオブジェクトのドキュメントを、組織固有のテンプレートとスタイルに従って生成します。外部ドキュメントシステムとは異なり、この知識はSAPオブジェクト内に直接埋め込まれ、別のシステムを検索する必要がなくなり、ドキュメントがライフサイクル全体を通じてコードとともに保持されることを保証します。 システムは、ナレッジマネジメント統合のためにドキュメントをローカルにエクスポートすることもできます。このアプローチにより、ドキュメント化されていないコードの課題が解消され、レガシーシステムの標準化されたドキュメントが提供され、既存の機能を理解、変更、拡張するために必要な時間が短縮されます。 要点：属人的知識への依存の削減、新しいチームメンバーのオンボーディングの迅速化、コードと同期しないドキュメントの排除。 6. SAPサポートチーム向けのAI支援エラー解決 ABAP Acceleratorは、SAPエラーを分析することでサポート活動を強化します。サポートチームは、エラーメッセージ、スクリーンショット、デバッグ情報、ジョブログ、またはショートダンプ（ST22）を入力でき、ABAP Acceleratorは根本原因を特定しながら解決ガイダンスを提供します。この機能により、サポートは反応的なトラブルシューティングから積極的な問題解決に変わります。システムのSAPアーキテクチャとエラーパターンの理解により、実行パスをトレースして修正を提案でき、通常はシニア開発者へのエスカレーションが必要な問題を解決することがよくあります。 要点：インシデント解決の迅速化、エスカレーションの削減、AI駆動の診断機能。 ABAP Acceleratorの使用開始 ABAP Acceleratorは無料でダウンロード可能なDockerイメージです。インストール後、標準のMCPサーバーと同じように接続できます。セットアッププロセスは簡単です： Installation: 詳細なインストール手順とセットアップガイダンスについては、 ABAP Accelerator リポジトリをご覧ください。 README ファイルの手順に従って、環境でMCPサーバーを構成して使用してください。 Integration: 標準のADT（ABAP Development Tools）を使用して、ABAP AcceleratorをSAPシステムに接続します。 Configuration: ATCバリアントで開発設定と品質チェックをセットアップします。 Start Developing: 完全なシステムコンテキストでAI駆動のSAP開発の活用を開始します。 エンタープライズSAP開発のための専用ソリューション ABAP Acceleratorは、SAP開発における根本的な変化を表しており、成功は書かれたコードの量ではなく、それが提供するビジネス価値によって測定されます。オブジェクトの作成、構文チェック、ATC検証、アクティベーション、単体テスト、トランスポートリクエスト管理、ドキュメント化を統合することで、断片化されたプロセスを開発サイクルを加速する合理化されたワークフローに変換します。 ABAP Acceleratorは、より速く、より信頼性が高く、SAPプラクティスに準拠した開発エクスペリエンスを作成します。SAP S/4HANAマイグレーションの管理、レガシーアプリケーションのモダナイゼーション、または新しいクラウドネイティブソリューションの構築のいずれの場合でも、ABAP Acceleratorはチームに対してAI駆動の加速を提供します。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本記事は 2026 年 1 月 22 日 に公開された「 Power up your analytics with Amazon SageMaker Unified Studio integration with Tableau, Power BI, and more 」を翻訳したものです。 by Narendra Gupta, Durga Mishra, Nishchai JM, and Ramesh H Singhon 22 JAN 2026in Advanced (300) , Amazon SageMaker Unified Studio , Technical How-to Permalink Comments Share 複数のデータソースにまたがるガバナンスされたデータに、セキュリティとガバナンスを維持しながら、使い慣れたビジネスインテリジェンス (BI) や分析ツールでアクセスして分析する際、組織は新たな課題に直面します。Tableau、Power BI、Excel などの使い慣れたツールを Amazon SageMaker のデータアセットに、データガバナンスとセキュリティ機能を損なうことなくシームレスに接続する必要があります。Amazon SageMaker は Amazon Athena JDBC ドライバーによる認証をサポートしており、データユーザーは Tableau、Power BI、Excel、SQL Workbench、DBeaver などの一般的な BI および分析ツールを使い、サブスクライブしたデータレイクアセットにクエリできます。データユーザーは使い慣れたツールで Amazon SageMaker の管理化にあるデータにアクセスして分析でき、生産性と柔軟性が向上します。 Amazon SageMaker Unified Studio では、データユーザーが単一のプロジェクト内で複数のソースからデータを検索してサブスクライブでき、データアクセスとガバナンスが効率化されます。Amazon SageMaker Unified Studio は Amazon Athena 、 Amazon Redshift 、 Amazon SageMaker AI などの Amazon 固有のオプションとネイティブに統合されており、ユーザーはプロジェクトのガバナンスされたデータを分析できます。これらに加え、今回の JDBC 接続のリリースにより、Amazon SageMaker Unified Studio はアナリストやサイエンティストを含むデータユーザーへのサポートを拡大し、SQL Workbench、Domino、 Amazon Athena などの Amazon ネイティブソリューションなど、好みのツールで作業しながら、Amazon SageMaker Unified Studio 内で安全でガバナンスされたアクセスを確保できます。 はじめに まず、使用するツール向けの最新の Athena JDBC ドライバー をダウンロードしてインストールします。インストール後、Amazon SageMaker Unified Studio ポータルから JDBC 接続文字列をコピーして JDBC 接続設定に貼り付け、ツールからの接続を確立します。企業の認証情報を使ったシングルサインオン (SSO) で認証するよう指示されます。接続後、Amazon SageMaker Unified Studio でガバナンスされたデータを、既に使い慣れた信頼できるツール内でクエリ、可視化、共有できます。 本記事では、Athena JDBC ドライバーで各種分析ツールを Amazon SageMaker Unified Studio に接続し、Amazon SageMaker Unified Studio プロジェクト内でサブスクライブしたデータにシームレスにアクセスする手順を説明します。 ソリューション概要 マーケティングチーム(Marketing Team)が店舗別および営業担当者別の売上パターンを理解するために売上データを分析したいというユースケースで、これらの機能を実証します。マーケティングチームは営業チーム(Sales Team)が所有する sales_performance_by_store と sales_performance_by_rep のデータにアクセスする必要があります。データプロデューサーとして機能する営業チームは、 必要なデータアセットを公開 して Amazon SageMaker Unified Studio に登録し、コンシューマーであるマーケティングチームがこれらのアセットを 検索してサブスクライブ できるようにします。 サブスクリプションが承認されると、データアセットは Amazon SageMaker Unified Studio のマーケティングチームのプロジェクト環境内で利用可能になります。マーケティングチームは好みのツールでデータ探索を実行できます。DBeaver を使ったアーキテクチャ例を次の図に示します。 前提条件 本記事の手順を実行するには、次の前提条件が必要です。 AWS アカウント – アクティブな AWS アカウントをお持ちでない場合は、 新しい AWS アカウントを作成してアクティブ化する方法 を参照してください。 Amazon SageMaker リソース – Amazon SageMaker の ドメイン と 2 つの Amazon SageMaker プロジェクト が必要です。（訳注：マーケティングチームと、営業チームがそれぞれ別のプロジェクトに所属するため） データアセットの公開 – 営業チームのデータプロデューサーとして、個々のデータアセットを Amazon SageMaker Unified Studio に取り込めます。本ユースケースでは、 データソースを作成 し、 AWS Glue Data Catalog から sales_performance_by_store と sales_performance_by_rep という 2 つのデータアセットの技術メタデータをインポートします。データアセットにビジネス説明を追加してカタログに公開してください。 注: ここでは Glue カタログ内のテーブルを使用していますが、SageMaker Lakehouse では他のソースからアセットを取り込むオプションもあります。 データアセットのサブスクライブ – マーケティングチームのデータアナリストとして、データアセットを検索してサブスクライブできます。営業チームのデータプロデューサーがサブスクリプションをレビューして承認します。正常に完了すると、データアセットが SageMaker プロジェクトに追加されます。 公開とサブスクライブの詳細な手順については、 Amazon SageMaker Unified Studio ユーザーガイド を参照してください。 次の図は、マーケティングプロジェクトにあるカタログのサブスクライブ済みアセットセクションを示しています。 次のセクションでは、Amazon SageMaker Unified Studio からサブスクライブ済みアセットを利用するための DBeaver の設定手順を説明します。 サブスクライブ済みデータアセットにアクセスするための DBeaver の設定 本セクションでは、 Marketing プロジェクトからサブスクライブ済みアセットにアクセスするための DBeaver の設定を行います。 DBeaver を設定する方法: JDBC で接続: Amazon SageMaker Unified Studio で、(1) Marketing プロジェクトを開き、(2) Project overview 画面で、(3) JDBC connection details タブを選択します。 JDBC 接続 URL をテキストエディタにコピーします。URL には、DBeaver でデータベース接続を設定するために必要な次のパラメータが含まれています – Domain ID、Environment ID、Region、IDC Issuer URL。 最新の Athena ドライバーをダウンロードしてインストールします。 DBeaver に Athena ドライバーがプリインストールされている場合、古い (v2) バージョンの可能性があります。Amazon SageMaker Unified Studio との互換性を確保するには、必要な認証機能を含む最新のドライバー (v3) が必要です。 最新の JDBC ドライバー—バージョン 3.x をダウンロードします。 最新のドライバーをインストールするには: DBeaver で Database から Driver Manager に移動します。 Athena ドライバーを選択して Edit を選択します。 Libraries タブを開きます。 Download/Update を選択して最新のドライバーバージョンを取得します。 プロンプトが表示されたら、適切なバージョンを選択してダウンロードを確認します。 DBeaver SQL クライアントで、新しいデータベース接続を作成し、Athena ドライバーを選択します。 Driver Properties タブに切り替え、Amazon SageMaker Unified Studio からコピーした JDBC 接続 URL に含まれる次のプロパティの値を入力します。これらのプロパティがまだ存在しない場合は、追加してそれぞれの値を指定できます。 CredentialsProvider : AWS へのリクエストを認証するための認証情報プロバイダー DataZoneDomainId : Amazon DataZone ドメインの ID DataZoneDomainRegion : ドメインがホストされている AWS リージョン DataZoneEnvironmentId : DefaultDataLake 環境の ID IdentityCenterIssuerUrl : トークン発行のために AWS Identity and Access Management (IAM) Identity Center が使用する発行者 URL OutputLocation : クエリ結果を保存するための Amazon S3 パス Region : 環境が作成されたリージョン Workgroup : 環境の Amazon Athena ワークグループ ListenPort : 任意の 4 桁のポート番号を選択します。これは IAM Identity Center レスポンスをリッスンするポート番号です Test Connection… を選択します。 IAM Identity Center サインインポータルにリダイレクトされます。Marketing ユーザーの認証情報でサインインします。シングルサインオン (SSO) で既にサインインしている場合、この手順はスキップできます。 サインイン後、 DataZoneAuthPlugin の承認を求められた場合は、 Allow access を選択して DBeaver から Amazon DataZone へのアクセスを承認します。 サインインが完了すると、次のメッセージが表示されます。ウィンドウを閉じて DBeaver に戻ります。 接続が確立されると、次の成功メッセージが表示されます。 これで、DBeaver 内でサブスクライブ済みアセットをすべて表示してクエリできます。 これらの手順は、JDBC 接続をサポートする他の分析ツールやクライアントにも適用できます。別のツールを使用している場合は、Amazon SageMaker Unified Studio データアセットへの適切な設定とアクセスを確保するために、これらの手順を適宜調整して利用してください。 他のアプリケーションとの統合 標準的なデータベース接続をサポートする他の BI および分析ツールでも同様の手順を使用できます。 Tableau Desktop への接続 Athena JDBC ドライバーを使用して Tableau を Amazon SageMaker Unified Studio に接続し、サブスクライブ済みデータを可視化します。 Tableau Desktop に接続する方法: 最新の Athena JDBC 3.x ドライバー を使用していることを確認します。 JDBC ドライバーファイルをコピーして、オペレーティングシステムに応じた適切なフォルダに配置します。 Mac OS の場合: ~/Library/Tableau/Drivers Windows の場合: C:\Program Files\Tableau\Drivers Tableau Desktop を開きます。 To a Server 接続メニューから Other Databases (JDBC) を選択して Amazon SageMaker Unified Studio に接続します。 SageMaker Unified Studio ポータルからコピーした JDBC 接続 URL を URL に貼り付けます。 Dialect 、 Username 、 Password などの他のフィールドは空白のままにして、 Sign in を選択します。 ポートが占有されているというエラーが表示された場合は、URL に “;ListenPort=8055” を追加してポートを変更します。任意のポート番号を使用できます。 IAM Identity Center で認証するようリダイレクトされます。SageMaker Unified Studio ポータルへのサインインに使用した Identity Center ユーザーの認証情報を入力します。 DataZoneAuthPlugin が Tableau から Amazon DataZone にアクセスすることを承認します。接続が成功メッセージとともに確立されると、プロジェクトのサブスクライブ済みデータを Tableau 内で直接表示してダッシュボードを構築できます。 Microsoft Power BI への接続 次に、Windows 上で Amazon SageMaker Unified Studio を Microsoft Power BI に接続する方法を説明します。Amazon Athena は Microsoft Power BI などの ODBC 互換ツールに接続するためのネイティブ ODBC ドライバーを提供していますが、現在 Amazon SageMaker Unified Studio 認証をサポートしていません。そのため、本記事では ODBC-JDBC ブリッジを使用して、SageMaker Unified Studio 認証をサポートする Athena JDBC ドライバーで Amazon SageMaker Unified Studio を Microsoft Power BI に接続します。 本記事では、ODBC-JDBC ブリッジとして ZappySys ドライバーを使用しています。別途ライセンス料が必要なサードパーティソリューションであり、AWS ソリューションには含まれていません。ODBC-JDBC ブリッジには他のソリューションを選択することもできます。Power BI に接続するには: ODBC Data Source Administrator を実行するためには、管理者権限が必要です。 Windows のスタートメニューから、 管理者として実行 を使用して ODBC Data Source Administrator (64 ビット版) を実行します。 ZappySys JDBC Bridge Driver で 新しいデータソース を作成します。接続の詳細を入力するよう求められます。 SageMaker Unified Studio ポータルからコピーした JDBC URL を、ドライバークラスと JDBC ドライバーファイルとともに Connection String に貼り付けます。最新の Athena JDBC 3.x ドライバー を使用していることを確認します。 Test Connection を選択します。接続が成功すると、新しいダイアログウィンドウがポップアップ表示されます。 IAM Identity Center で認証するようリダイレクトされます。SageMaker Unified Studio ポータルへのサインインに使用した Identity Center ユーザーの認証情報を入力します。 DataZoneAuthPlugin を承認します。 ZappySys JDBC Bridge Driver ウィンドウで Preview タブを選択し、サブスクライブ済みテーブルの 1 つを選択してデータにアクセスします。 データソースの設定後、Power BI を起動します。空白のレポートを作成するか、既存のレポートを使用して新しいビジュアルを統合します。 Get Data を選択し、作成したデータソースの名前を選択します。新しいブラウザウィンドウが開き、認証情報を認証します。DataZone Auth プラグインを承認するためにアクセスを許可します。承認が完了すると、サブスクライブ済みデータアセットを使って Microsoft Power BI でレポートを作成できます。 SQL Workbench への接続 SQL インターフェイスで Amazon SageMaker Unified Studio のプロジェクトを通じてサブスクライブしたデータレイクテーブルとビューをクエリしたいユーザー向けに、SQL Workbench を Amazon SageMaker Unified Studio に接続する方法を説明します。 SQL Workbench に接続するには: 最新の Athena JDBC 3.x ドライバー を使用していることを確認します。 SQL Workbench/J を開き、 Manage Drivers を選択します。 新しいドライバーを追加するオプションを選択します。SMUSAthenaJDBC などの名前を入力し、前の手順でダウンロードしたドライバーをインポートします。 新しい接続プロファイルを作成し、smus-profile などの名前を付けます。 Driver ドロップダウンで、設定したドライバーを選択します。 URL には、jdbc:athena://region=us-east-1; という文字列を入力します (この例では、バージニアリージョンを使用しています)。 Extended Properties を選択します。 Extended Properties で、SageMaker Unified Studio ポータルからコピーした次のパラメータを追加します。これらのパラメータは JDBC (URL) 接続文字列に含めることもできます。 OK を選択します。 Workgroup OutputLocation DataZoneDomainId IdentityCenterIssuerURL CredentialsProvider DatazoneEnvironmentId DataZoneDomainRegain また、任意のポート番号で “ListenPort” を追加します。 IAM Identity Center で認証するようリダイレクトされます。SageMaker Unified Studio ポータルへのサインインに使用した Identity Center ユーザーの認証情報を入力します。 DataZoneAuthPlugin を承認します。 接続が成功したら、SQL Workbench/J の Database Explorer で、SageMaker unified studio のマーケティングプロジェクトからデータベースを選択します。サブスクライブ済みテーブルを選択します。 Data タブを選択して、テーブル内のデータを表示します。 クリーンアップ テスト後に追加料金が発生しないようにするには、Amazon SageMaker Unified Studio ドメインを削除してください。手順については、 ドメインの削除 を参照してください。 まとめ Amazon SageMaker Unified Studio は機能を増やし続けており、サブスクライブ済みデータへのアクセス、分析、可視化においてより高い柔軟性を提供します。Athena JDBC ドライバーのサポートにより、幅広い一般的な BI および分析ツールを使用できるようになり、Amazon SageMaker Unified Studio を通じてアクセスするデータがこれまで以上に利用しやすくなりました。Tableau、Power BI、その他の使い慣れたツールのいずれを使用する場合でも、Amazon SageMaker Unified Studio との統合により、データは安全に保たれ、承認されたユーザーがアクセスできます。 本機能は、Amazon SageMaker Unified Studio が現在利用可能な すべての AWS 商用リージョン でサポートされています。技術 ドキュメント の確認から始めましょう。 著者について Narendra Gupta Narendra は、AWS の Specialist Solutions Architect で、AWS 分析サービスに重点を置いてお客様のクラウドジャーニーを支援しています。仕事以外では、新しいテクノロジーの学習、映画鑑賞、新しい場所への訪問を楽しんでいます。 Durga Mishra Durga は、AWS の Solutions Architect です。仕事以外では、家族と過ごす時間を楽しみ、アパラチアントレイルでのハイキングや自然の中で過ごすことを愛しています。 Ramesh Singh Ramesh は、ワシントン州シアトルの AWS で Senior Product Manager Technical (External Services) を務めており、現在は Amazon SageMaker チームに所属しています。最先端テクノロジーを使用してエンタープライズのお客様が重要な目標を達成できるよう支援する、高性能な ML/AI および分析製品の構築に情熱を注いでいます。 Nishchai JM Nishchai は、Amazon Web Services の Analytics Specialist Solutions Architect です。ビッグデータアプリケーションの構築を専門とし、お客様のクラウド上でのアプリケーションモダナイゼーションを支援しています。データは新しい石油であると考えており、データから洞察を引き出すことに時間の大半を費やしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の 下佐粉 昭 (Akira Shimosako) がレビューしました。

本ブログは 2024 年 12 月 10 日に公開された AWS Blog “ AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation ” を翻訳したものです。 AWS-LC FIPS 3.0 が National Institute of Standards and Technology (NIST) の Cryptographic Module Validation Program (CMVP) の 審査中モジュール リストに追加されたことを発表いたします。AWS-LC のこの最新の検証では、ML-KEM (Module Lattice-Based Key Encapsulation Mechanism) のサポートが導入されています。ML-KEM は、FIPS で新たに標準化されたポスト量子暗号アルゴリズムです。これは、米国連邦政府の通信を含む、最も機密性の高いワークフローの長期的な機密性を強化するための重要なステップです。 この検証により、 AWS LibCrypto (AWS-LC) は、FIPS モジュール内でポスト量子アルゴリズムのサポートを提供する初のオープンソース暗号モジュールとなります。 FedRAMP 、 FISMA 、 HIPAA などの連邦コンプライアンスフレームワークに基づいて運用されている組織など、FIPS 検証済み暗号モジュールを必要とする組織は、AWS-LC 内でこれらのアルゴリズムを使用できるようになります。 今回の発表は、新しい FIPS 140-3 認証を継続的に取得するという AWS-LC の長期的なコミットメントの一環です。AWS-LC は 2023 年 10 月に AWS-LC-FIPS 1.0 で 最初の認証を取得 しました。その後のバージョンである AWS-LC-FIPS 2.0 は、2024 年 10 月に 認証を取得 しました。この記事では、ポスト量子暗号アルゴリズム ML-KEM の FIPS 検証、AWS-LC FIPS 2.0 および 3.0 における既存アルゴリズムのパフォーマンス改善、バージョン 3.0 で追加された新しいアルゴリズムのサポートについて説明します。また、新しいアルゴリズムを使用してハイブリッドポスト量子暗号スイートを実装する方法と、将来の脅威から保護するために今すぐ設定できる構成オプションについても説明します。 FIPS ポスト量子暗号 大規模な量子コンピュータは、現在公開鍵暗号で保護しているデータの長期的な機密性に対する脅威となります。今記録して後で復号する攻撃 (record-now, decrypt-later 攻撃) として知られる手法では、攻撃者は今日のインターネットトラフィックを記録し、鍵交換と暗号化された通信をキャプチャします。そして、十分に強力な量子コンピュータが利用可能になったときに、暗号の安全性を支える計算上の困難性を突破することで、過去に記録した通信の共有シークレットと暗号鍵を解読できます。 ML-KEM は、量子コンピュータの脅威から公開鍵暗号を守るために NIST が標準化を進めている新しい鍵カプセル化メカニズムの 1 つです。 RSA 、Diffie-Hellman (DH)、または楕円曲線 Diffie-Hellman (ECDH) 鍵交換と同様に、2 者間で共有シークレットを確立することで機能します。ただし、RSA や DH とは異なり、ML-KEM は量子コンピュータでも突破が困難と考えられている数学的問題に基づいて鍵交換を行います。 現時点では、このような大規模な量子コンピュータを実現する技術はまだ確立されていません。そのようなコンピュータの実現には、さらなる科学技術のブレークスルーが必要です。しかし、将来実現する可能性に備えて、ML-KEM などのポスト量子アルゴリズムを今日の鍵交換プロトコルに導入することで、record-now, decrypt-later 攻撃のリスクを軽減できます。AWS は、ECDH などの従来の鍵交換方式と ML-KEM を組み合わせたハイブリッド鍵交換アプローチを採用し、現在および将来の攻撃者に対するリスクを軽減することを推奨しています。この記事の後半では、将来の脅威から保護するために今すぐハイブリッドポスト量子暗号スイートを実装する方法を紹介します。 AWS-LC FIPS 3.0 では、ML-KEM アルゴリズムの 3 つのパラメータセット (ML-KEM-512、ML-KEM-768、ML-KEM-1024) をすべてサポートしています。3 つのパラメータセットは、NIST が指定する異なるレベルのセキュリティ強度を提供します ( FIPS 203 [9, Sect. 5.6] または ポスト量子セキュリティ評価基準 を参照)。ML-KEM-768 は汎用的なユースケースに推奨されます。ML-KEM-1024 は、より高いセキュリティレベルを必要とするアプリケーションや、国家安全保障システムの所有者およびオペレーター向けの Commercial National Security Algorithm Suite (CNSA) 2.0 などの明示的な指令への準拠が必要なアプリケーション向けに設計されています。 アルゴリズム NIST セキュリティカテゴリ 公開鍵 (B) 秘密鍵 (B) 暗号文 (B) ML-KEM-512 1 800 1632 768 ML-KEM-768 3 1184 2400 1088 ML-KEM-1024 5 1568 3168 1568 表 1. ML-KEM の 3 つのパラメータセットにおけるセキュリティ強度カテゴリ、公開鍵、秘密鍵、暗号文のサイズ (バイト単位) s2n-tls との統合 ML-KEM は、TLS 1.3 のハイブリッド鍵交換 (draft-ietf-tls-hybrid-design) を通じて、AWS のオープンソース TLS 実装である s2n-tls で利用可能になりました。また、TLS 1.3 のハイブリッド ECDHE-ML-KEM 鍵合意 (draft-kwiatkowski-tls-ecdhe-mlkem) のサポートと、Curve x25519 および ML-KEM-768 の新しい鍵共有識別子も追加しました。 FIPS 140 準拠モードでのハイブリッド鍵確立では、コンポーネントアルゴリズムの 1 つが NIST 承認メカニズムである必要があります ( NIST ポスト量子 FAQ で詳細を確認できます )。ML-KEM が NIST 承認アルゴリズムのリストに追加されたことで、Curve x25519 のような FIPS 標準化されていないアルゴリズムもハイブリッド暗号スイートに含めることができるようになりました。TLS 暗号スイートを ML-KEM-768 と x25519 を使用するように設定することで (draft-kwiatkowski-tls-ecdhe-mlkem)、FIPS 検証済み暗号モジュール内で初めて x25519 を使用できます。これにより、AWS-LC が提供する高度に最適化され機能検証された Curve x25519 実装を通じて、より効率的な鍵交換が可能になります。 新しいアルゴリズムと新しい実装 AWS-LC FIPS の継続的な検証に対する AWS のコミットメントにおいて重要な 2 つの要素は、承認された暗号サービスとして新しいアルゴリズムを含めることと、既存アルゴリズムについてパフォーマンスを改善し形式検証で正しさを証明した新しい実装を追加することです。 新しいアルゴリズム AWS は、開発者が FIPS 検証済みの暗号を採用できるよう、認定された暗号アルゴリズムの最新リビジョンと新しいプリミティブを継続的に検証することにコミットしています。最新の標準化リビジョンでアルゴリズムを検証することで、グローバル標準に準拠した高品質な実装を提供しています。 AWS-LC FIPS 3.0 では、SHA（Secure Hash Algorithm）標準の最新規格である SHA-3 を追加しました。SHA-3 ファミリーは、さまざまなアルゴリズムをサポートするために使用される暗号プリミティブです。AWS-LC FIPS 3.0 では、ECDSA と RSA の署名生成および検証を SHA-3 と統合し、ポスト量子アルゴリズム ML-KEM 内でも統合しました。AWS-LC では、ML-KEM が FIPS 検証済みの SHA-3 関数を呼び出し、SHA-3 と SHAKE ハッシュ手順の最適化された実装を提供します。つまり、AWS-LC の SHA-3 実装を継続的に改良・最適化することで、ML-KEM など SHA-3 を使用するアルゴリズム全体のパフォーマンスも向上していきます。 EdDSA は、曲線 Ed25519 を使用した楕円曲線に基づくデジタル署名アルゴリズムです。NIST の更新された Digital Signature Standard (DSS) である FIPS 186-5 に追加されました。この署名アルゴリズムは、AWS-LC 3.0 FIPS モジュールの一部として提供されるようになりました。鍵合意については、共有シークレットから鍵を導出するために使用される Single-step Key Derivation Function (SSKDF) ( SP 800-56Cr2 ) が、ダイジェストベースと HMAC ベースの両方の仕様で利用可能です。SSKDF は、例えば KMS で ECDH を使用 した際に生成される共有シークレットから鍵を導出するために使用できます。さらに、Key-based Key Derivation Function (KBKDF) である SP 800-108r1 を使用して、元の鍵からさらに鍵を導出できます。これは HMAC に基づくカウンターモードを使用して利用可能です。 パフォーマンス改善 AWS は、TLS プロトコルなどのトランスポートプロトコルで広く使用されている公開鍵暗号アルゴリズムのパフォーマンス向上に注力しました。例えば、 Graviton2 での RSA 署名 は、ビット長 2048 で 81%、3072 で 33%、4096 で 94% 高速化され、主要な演算が正しく動作することの形式検証も追加されました。第 3 世代 Intel Xeon 以降で利用可能な Intel の AVX512 Integer Fused Multiply Add (IFMA) 命令を使用して、 Intel の開発者がこれらの命令と幅広い AVX512 レジスタを使用する RSA 実装を AWS-LC にコントリビュート しました。これは既存の実装の 2 倍の速度です。 EdDSA 署名のスループットは平均 108% 向上し、検証は 37% 向上しました。この平均は、Graviton2、Graviton3、Intel Ice Lake (Intel Xeon Platinum 8375C CPU) の 3 つの環境で測定されています。 このパフォーマンス向上は 、 s2n-bignum ライブラリから各ターゲット向けのコア演算のアセンブリ実装を統合することで達成されています。さらに、コア演算は定数時間で実装されており、各演算が正しく動作することが形式検証で証明されています。 以下の図 1 では、AWS-LC FIPS 1.0 と比較したバージョン 2.0 および 3.0 でのパフォーマンス改善の割合を示しています。2.0 で達成された改善は 3.0 でも維持されており、グラフでは繰り返し表示していません。グラフには対称鍵の改善も含まれています。セッション確立後の通信を暗号化するために TLS で広く使用されている AES-256-GCM では、Intel Ice Lake と Graviton4 全体で 16 KB メッセージを暗号化する際に平均 115% の向上があります。ディスクストレージで使用される AES-256-XTS では、256 B の入力の暗号化が Intel Ice Lake で 360%、Graviton4 で 90% 高速化されています。 図 1: AWS-LC FIPS バージョン 2.0 および 3.0 でのパフォーマンス改善のグラフ 今すぐ ML-KEM を使用する方法 s2n-tls と AWS-LC の両方の TLS ライブラリを設定して、鍵交換に X25519MLKEM768 と SecP256r1MLKEM768 を有効にすることで、今すぐ ML-KEM によるハイブリッドポスト量子セキュリティを有効にできます。AWS は、各ライブラリの既存の TLS 設定 API を使用して、AWS-LC libssl と s2n-tls の両方でこれらのハイブリッドアルゴリズムのサポートを統合しました。TLS 接続をネゴシエートするには、以下のコマンドのいずれかを使用してください。 # AWS-LC クライアント CLI の例 ./aws-lc/build/tool/bssl s_client -curves X25519MLKEM768:SecP256r1MLKEM768:X25519 -connect <hostname> : <port> # S2N-tls クライアント CLI の例 ./s2n/build/bin/s2nc -c default_pq -i <hostname> <port> まとめ この記事では、オープンソース暗号ライブラリ AWS-LC を通じて提供している暗号技術の継続的な開発、最適化、検証について説明しました。 また、FIPS 検証済みポスト量子アルゴリズムの追加と、将来の脅威に備えて今すぐこれらのアルゴリズムを使用するための設定方法を紹介しました。 AWS-LC-FIPS 3.0 は、AWS-LC の新しいバージョンを継続的に FIPS 認証を取得していくという AWS のコミットメントの一環です。新しいアルゴリズムが標準化されるたびに認証対象に追加し、既存アルゴリズムのパフォーマンスと形式検証の水準も引き上げています。このコミットメントを通じて、 AWS Libcrypto for Rust (aws-lc-rs) や ACCP 2.0 ライブラリ への統合により、Rust、Java、Python 開発者のより広いコミュニティを引き続きサポートしています。また、 CPython への統合を促進 し、AWS-LC に対してビルドして Python 標準ライブラリのすべての暗号処理に使用できるようにしています。さらに、 rustls が FIPS サポートを提供できるようにしました 。 この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 Jake Massimo Jake は AWS Cryptography チームの応用科学者です。国際会議、学術文献、標準化団体への参加を通じて Amazon とグローバルな暗号コミュニティをつなぎ、ポスト量子クラウドスケール暗号技術の採用を促進することを目標としています。最近は、ポスト量子移行をサポートするための AWS 暗号ライブラリの開発に注力しています。 Nevine Ebeid Nevine は AWS Cryptography のシニア応用科学者で、AWS の暗号ライブラリである AWS-LC のアルゴリズム開発、マシンレベルの最適化、FIPS 140-3 要件に注力しています。AWS 入社前は、自動車およびモバイルセキュリティアプリケーションにおけるさまざまな暗号ライブラリとプロトコルの研究開発に従事していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 3 月 5 日に公開された Amazon Science Blog “ Latency from post-quantum cryptography shrinks as data increases ” を翻訳したものです。 ポスト量子暗号によりデータ量が増加した TLS 1.3 が実際の接続に与える影響を評価する際、最初のバイト到達時間 (TTFB: 最初のデータが届くまでの時間) ではなく最終バイト到達時間 (TTLB: データ転送が完了するまでの時間) を使用すると、より期待できる結果が得られます。 量子コンピュータが現在広く使用されている暗号標準を破る可能性があるというリスクは、ポスト量子暗号アルゴリズムの標準化と TLS 1.3 などのトランスポート暗号化プロトコルへの導入に向けた数多くの取り組みを促しています。ポスト量子アルゴリズムの選択は当然ながら TLS 1.3 のパフォーマンスに影響します。これまでの研究では、2 者間でポスト量子暗号接続を確立するために必要な「ハンドシェイク時間」、つまり 最初のバイト到達時間 (TTFB) に焦点が当てられてきました。 これらの研究はハンドシェイク時間の増加を定量化する上で重要でしたが、実際の TLS 1.3 接続に対するポスト量子暗号の影響の全体像を示すものではありませんでした。実際の接続では、多くの場合かなりの量のデータが転送されます。2024 年の Workshop on Measurements, Attacks, and Defenses for the Web (MADweb) で、私たちは ML-KEM (ML 鍵カプセル化メカニズム) や ML-DSA (ML 電子署名アルゴリズム) などのデータ量の多いポスト量子暗号アルゴリズムが実際の TLS 1.3 接続に与える総合的な影響を評価する指標として 最終バイト到達時間 (TTLB) を提唱する 論文 を発表しました。この論文では、新しいアルゴリズムがかなりの量のデータを転送する接続に与える実際の影響は、TLS 1.3 ハンドシェイク自体に与える影響よりもはるかに小さいことを示しています。 ポスト量子暗号 TLS 1.3 は、トランスポート層セキュリティプロトコルの最新バージョンであり、クライアントとサーバー間で転送されるデータを暗号化および認証するセキュアチャネルのネゴシエーションと確立に使用されます。TLS 1.3 は、オンラインバンクやストリーミングメディアなど、数多くの Web アプリケーションで使用されています。 TLS 1.3 で使用されているような非対称暗号アルゴリズムのセキュリティは、離散対数問題や素因数分解の困難さに依存していますが、暗号解読能力を持つ量子コンピュータが実現すれば、これらを効率的に解くことが可能になります。米国国立標準技術研究所 (NIST) はポスト量子暗号アルゴリズムの標準化に取り組んでおり、鍵交換用に ML-KEM を選定しました。また、署名 (暗号認証) 用に ML-DSA も選定しています。 これらのアルゴリズムが使用する公開鍵、暗号文、署名はキロバイト単位の大きさです。従来のアルゴリズムでは 50〜400 バイト程度だったため、TLS ハンドシェイクで交換されるデータ量が大幅に増加することになります。従来の TLS 1.3 鍵交換および認証とポスト量子鍵交換および認証を使用した場合のハンドシェイク時間を比較した研究が数多く行われてきました。 これらの比較は、各新アルゴリズムが 最初のバイト到達時間 (TTFB) 、つまりハンドシェイクプロトコルの完了に導入するオーバーヘッドを定量化するのに有用でした。しかし、ハンドシェイク時間とともにアプリケーションがデータ処理を開始するまでの総遅延を構成する、セキュア接続上のデータ転送時間は無視されていました。接続開始からデータ転送終了までの総時間が 最終バイト到達時間 (TTLB) です。TTLB の遅延がどの程度許容されるかは、アプリケーションによって大きく異なります。 実験 私たちはさまざまなネットワーク条件をシミュレートする実験を設計し、クライアントが小さなリクエストを送信しサーバーが数百キロバイト (KB) のデータで応答する TLS 1.3 接続において、従来のアルゴリズムとポスト量子アルゴリズムの TTLB を測定しました。Ubuntu 22.04 仮想マシンインスタンスで Linux 名前空間を使用しました。名前空間は仮想イーサネットインターフェースを使用して相互接続されました。名前空間間の「ネットワーク」をエミュレートするために、Linux カーネルの netem ユーティリティを使用しました。これにより、クライアントとサーバー間にネットワーク遅延の変動、帯域幅の変動、パケット損失を発生させることができます。 クライアントとサーバーの Linux 名前空間および netem でエミュレートされたネットワーク条件を使用した実験セットアップ。 実験では、以下のパラメータを変更することで、安定・不安定、高速・低速といったさまざまなネットワーク条件下でポスト量子アルゴリズムが TTLB に与える影響を比較しました。 TLS 鍵交換メカニズム (従来の ECDH または ECDH+ML-KEM ポスト量子ハイブリッド) 従来の RSA または ML-DSA 証明書に対応する TLS 証明書チェーンサイズ TCP 初期輻輳ウィンドウ (initcwnd) クライアントとサーバー間のネットワーク遅延、またはラウンドトリップ時間 (RTT) クライアントとサーバー間の帯域幅 パケットあたりの損失率 サーバーからクライアントに転送されるデータ量 結果 実験結果は論文で詳細に分析されています。基本的に、ポスト量子の公開鍵、暗号文、署名による TLS 1.3 ハンドシェイクでの数 KB の追加データは、数百 KB 以上を転送する接続では気にならないことを示しています。10〜20 KB 未満のデータを転送する接続は、新しいデータ量の多いハンドシェイクの影響をより受ける可能性があります。 図 1: 従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TLS 1.3 ハンドシェイク時間の増加率。帯域幅 = 1Mbps、損失率 = 0%、1%、3%、10%、RTT = 35ms および 200ms、TCP initcwnd=20。 Y 軸が「ハンドシェイク時間の増加率」、X 軸がパーセンタイル (50、75、90) の棒グラフ。各パーセンタイルには 2 本の棒があり、青が従来のハンドシェイクプロトコル、オレンジがポスト量子ハンドシェイクを表す。3 つのケースすべてで、オレンジの棒は青の棒の約 2 倍の高さ。 図 1 は、1Mbps 帯域幅、0%、1%、3%、10% の損失率、35 ミリ秒および 200 ミリ秒の RTT で収集された集計データセットの 50、75、90 パーセンタイルにおける TLS 1.3 ハンドシェイク時間の増加率を示しています。ML-DSA サイズ (16KB) の証明書チェーンは、8KB のチェーンのほぼ 2 倍の時間がかかることがわかります。つまり、ML-DSA 認証データの量を少なく抑えることができれば、低帯域幅接続でのポスト量子ハンドシェイクの速度が大幅に向上します。 図 2: 損失率 0% における従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。帯域幅 = 1Gbps、RTT = 35ms、TCP initcwnd = 20。 図 2 は、損失率 0%、帯域幅 1Gbps の条件下で、すべてのパーセンタイルと異なるデータサイズにおける、従来のアルゴリズムに対するポスト量子ハンドシェイクの所要時間の増加率を示しています。サーバーからのデータが 0 KiB (キビバイト、1,024 バイト) の場合 (ハンドシェイクのみに相当)、速度低下は約 3% と小さく、サーバーからのデータ転送が増加するにつれて約 1% までさらに小さくなることがわかります。90 パーセンタイルでは速度低下がわずかに小さくなっています。 図 3: 損失率 0% における従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。帯域幅 = 1Mbps、RTT = 200ms、TCP initcwnd = 20。 図 3 は、帯域幅 1Mbps、RTT 200ms、損失率 0% の条件下で、サーバーから 0〜200KiB のデータを転送する従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率を各パーセンタイルで示しています。3 つのパーセンタイルの増加率はほぼ同じです。サーバーからのデータが 0KiB の場合は高い値 (約 33%) から始まりますが、サーバーからのデータサイズが増加するにつれて約 6% まで低下します。これは、ハンドシェイクのデータサイズが接続全体で分散されるためです。 図 4: 従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。損失率 = 10%、帯域幅 = 1Mbps、RTT = 200ms、TCP initcwnd = 20。 図 4 は、帯域幅 1Mbps、RTT 200ms、損失率 10% の条件下で、サーバーから 0〜200 KiB のデータを転送する従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率を各パーセンタイルで示しています。損失率 10% では、TTLB の増加率はすべてのパーセンタイルで 20〜30% の範囲に収まります。RTT 35ms での同じ実験でも同様の結果が得られました。20〜30% の増加は高いように見えるかもしれませんが、シナリオ全体のネットワーク不安定性により、実験を再実行すると増加率が小さくなったり大きくなったりすることがあります。また、サーバーからのデータ 200KiB、RTT 200ms、損失率 10% の条件下での従来のアルゴリズムの TTLB は 4,644ms、7,093ms、10,178ms であったのに対し、ポスト量子接続の同等値は 6,010ms、8,883ms、12,378ms でした。損失率 0% では 2,364ms、2,364ms、2,364ms でした。つまり、ポスト量子接続の TTLB は従来の接続に比べて 20〜30% 増加しましたが、従来の接続はすでにネットワーク損失により (97〜331%) 劣化しています。すでに大幅に劣化した接続時間に対して、追加の 20〜30% はそれほど大きな違いにはならないでしょう。 図 5: 「不安定なネットワーク」条件下、損失率 0% における従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率。帯域幅 = 1Gbps、RTT = 35ms、TCP initcwnd = 20。 図 5 は、損失率 0%、サーバーから 0〜200KiB のデータを転送する条件下での、従来の TLS 1.3 接続とポスト量子 TLS 1.3 接続間の TTLB 増加率を示しています。非常に不安定な RTT をモデル化するために、平均 35ms、ジッター 35/4ms のパレート正規分布を使用しました。ポスト量子接続の TTLB 増加率は、サーバーデータ 0KiB で高い値から始まり、4〜5% まで低下します。以前の実験と同様に、損失率が高いほど増加率の変動は大きくなりましたが、全体として、「不安定なネットワーク条件」下でも転送データ量が増加するにつれて TTLB は許容可能なレベルまで低下することが結果から示されています。 図 6: ポスト量子 TLS 1.3 接続の TTLB 累積分布関数。サーバーから 200KiB、RTT = 35ms、TCP initcwnd = 20。 不安定なネットワーク条件下での変動を確認するために、サーバーから 200KiB を転送するポスト量子 TLS 1.3 接続の TTLB 累積分布関数 (CDF) を使用しました (図 6) 。あらゆる種類の不安定な条件 (1Gbps で損失率 5%、1Mbps で損失率 10%、パレート正規分布のネットワーク遅延) において、TTLB は実験測定サンプルの非常に早い段階で増加しており、総接続時間が非常に不安定であることを示しています。不安定なネットワーク条件下での TLS 1.3 ハンドシェイク時間でも同じ観察結果が得られました。 結論 この研究では、データ量の多いポスト量子アルゴリズムが TLS 1.3 接続に与える実際の影響は、ハンドシェイク自体に与える影響よりも小さいことを実証しました。損失率が低く、低帯域幅または高帯域幅の接続では、かなりの量のデータを転送する場合、ポスト量子ハンドシェイクの影響はほとんどありません。また、損失率が高い不安定な条件や遅延の変動が大きい条件下では、ポスト量子ハンドシェイクの影響は変動する可能性がありますが、一定の範囲内に収まり、転送データの総量が増加するにつれて低下することも示しました。さらに、不安定な接続ではそもそも接続完了までに長い時間がかかるため、ポスト量子ハンドシェイクによるわずかな遅延増加があっても、以前より使いにくくなることはありません。ただし、これはハンドシェイクデータ量の削減が不要という意味ではありません。アプリケーションデータの送信量がハンドシェイクメッセージのサイズに対して少ない場合は、ハンドシェイクデータの削減が特に重要になります。 詳細については、 論文 をご覧ください。 著者について Panos Kampanakis Panos Kampanakis は Amazon Web Services のプリンシパルセキュリティエンジニアです。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の経験があります。サイバーセキュリティに関する論文を共同執筆し、セキュリティ情報共有、暗号、公開鍵基盤のための共通の相互運用可能なプロトコルと言語を提供するため、さまざまなセキュリティ標準化団体に参加しています。現在は、エンジニアや業界標準パートナーと協力して、暗号学的に安全なツール、プロトコル、標準を提供しています。 Will Childs-Klein Will Childs-Klein は Amazon Web Services Cryptography のシニアソフトウェアエンジニアです。暗号ライブラリの開発、ソフトウェアパフォーマンスの最適化、ポスト量子暗号の導入に注力しています。以前は AWS で Storage Gateway、Elastic File System、DataSync などのデータストレージおよび転送サービスに携わっていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2022 年 7 月 5 日に公開された AWS Blog “ How to tune TLS for hybrid post-quantum cryptography with Kyber ” を翻訳したものです。 2024 年 1 月 30 日: このブログ記事の API は、AWS CRT Client の新しいバージョンで変更されました。 詳細についてはこちらのページを参照してください 。 2023 年 1 月 25 日: AWS KMS、ACM、Secrets Manager の TLS エンドポイントは、NIST のラウンド 3 で選定された KEM である Kyber のみをサポートするように更新されました。 s2n-tls と s2n-quic も Kyber のみをサポートするように更新されました。標準化の進行に伴い、BIKE やその他の KEM が追加される可能性があります。 2022 年 8 月 3 日: この記事は Secrets Manager の情報を含むように更新されました。 AWS は、 AWS Key Management Service (AWS KMS) 、 AWS Secrets Manager 、 AWS Certificate Manager (ACM) への接続に Kyber を使用したハイブリッドポスト量子 TLS を提供しています。このブログ記事では、ハイブリッドポスト量子 Kyber 実装のパフォーマンス特性を紹介し、Maven プロジェクトでの設定方法を説明し、Kyber ポスト量子暗号 (PQC) に向けた接続設定の準備について解説します。 学術機関、暗号コミュニティ、 米国国立標準技術研究所 (NIST) のパートナーによる 5 年間の集中的な研究と暗号解析を経て、NIST はポスト量子鍵カプセル化メカニズム (KEM) の標準化に Kyber を選定しました。これは次世代の公開鍵暗号の幕開けを意味します。やがて、RSA や楕円曲線暗号 (ECC) など現在使用されている従来の鍵確立アルゴリズムは、量子耐性のある代替手段に置き換えられることになります。AWS Cryptography チームは、NIST 選定プロセスの各ラウンドを通じて候補 KEM の研究と分析を行ってきました。AWS は ラウンド 2 から Kyber のサポートを開始し、現在もそのサポートを継続しています。 RSA や ECC を解読できる暗号解読能力を持つ量子コンピュータはまだ存在しません。しかし、AWS は現在 Kyber を使用したハイブリッドポスト量子 TLS を提供しています。これにより、お客様は PQC のパフォーマンスの違いがワークロードにどのような影響を与えるかを確認できます。また、PQC を使用することで、 AWS KMS 、 Secrets Manager 、 ACM への接続における既に高いセキュリティ基準がさらに向上するため、長期的な機密性を必要とするお客様にとって特に有効な機能となっています。 (訳注：本ブログ執筆時点では Kyber は標準化前でしたが、2024 年 8 月に NIST により ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203) として正式に標準化されました。AWS KMS、ACM、Secrets Manager は現在、標準化された ML-KEM をサポートしています。詳細は「 ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager 」を参照してください。) Kyber を使用したハイブリッドポスト量子 TLS のパフォーマンス ハイブリッドポスト量子 TLS は、従来の暗号のみと比較してレイテンシーと帯域幅のオーバーヘッドが発生します。このオーバーヘッドを定量化するために、 s2n-tls がハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立と ECDHE 単独のネゴシエーションにかかる時間を測定しました。テストは、米国東部 (バージニア北部) AWS リージョンの Amazon Elastic Compute Cloud (Amazon EC2) c6i.4xlarge インスタンス上で Linux perf サブシステムを使用して実施し、一般的なインターネットレイテンシーを含めるために米国西部 (オレゴン) リージョンで稼働するテストサーバーに 2,000 回の TLS 接続を開始しました。 図 1 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立を使用した TLS ハンドシェイクのレイテンシーを示しています。列は、クライアントとサーバーが消費した CPU 時間と、ネットワーク経由でのデータ送信に費やした時間を比較できるように分けて表示しています。 図 1: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクのレイテンシー比較 図 2 は、従来の ECDHE とハイブリッドポスト量子 (ECDHE + Kyber) 鍵確立の両方について、クライアント側で測定した TLS ハンドシェイク中の送受信バイト数を示しています。 図 2: 従来の TLS ハンドシェイクとハイブリッドポスト量子 TLS ハンドシェイクの帯域幅比較 このデータから、ハイブリッドポスト量子鍵確立を使用した場合のオーバーヘッドは、クライアント側で 0.25 ms、サーバー側で 0.23 ms、ネットワーク上で 2,356 バイトが追加されることがわかります。リージョン内テストではネットワークレイテンシーはより低くなります。レイテンシーは、ネットワーク状況、CPU パフォーマンス、サーバー負荷、その他の変数によっても異なる場合があります。 結果は、Kyber のパフォーマンスが優れていることを示しています。追加のレイテンシーは、 以前のブログ記事 で分析した NIST PQC 候補の中でトップクラスです。実際、これらの暗号のパフォーマンスは最新のテストで向上しています。これは、x86-64 アセンブリ最適化バージョンの暗号が利用可能になったためです。 Maven プロジェクトでハイブリッドポスト量子 TLS を設定する このセクションでは、Kyber を使用したアセンブリ最適化済みのハイブリッドポスト量子 TLS を設定するための Maven 設定とコード例を紹介します。 Maven プロジェクトでハイブリッドポスト量子 TLS を設定するには AWS SDK for Java 2.x 用 AWS Common Runtime HTTP クライアント のプレビューリリースを取得します。Maven の依存関係設定では、以下のコードサンプルに示すようにバージョン 2.17.69-PREVIEW 以降を指定する必要があります。 <dependency> <groupId>software.amazon.awssdk</groupId> aws-crt-client <version>[2.17.69-PREVIEW,]</version> </dependency> コードの初期化時に目的の暗号スイートを設定します。以下のコードサンプルは、最新のハイブリッドポスト量子暗号スイートを使用するように AWS KMS クライアントを設定する方法を示しています。 // Check platform support if(!TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05.isSupported()){ throw new RuntimeException("Hybrid post-quantum cipher suites are not supported."); } // Configure HTTP client SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder() .tlsCipherPreference(TLS_CIPHER_PREF_PQ_TLSv1_0_2021_05) .build(); // Create the AWS KMS async client KmsAsyncClient kmsAsync = KmsAsyncClient.builder() .httpClient(awsCrtHttpClient) .build(); これで、AWS KMS クライアントで行われるすべての呼び出しがハイブリッドポスト量子 TLS を使用するようになります。上記の例と同様に、 AcmAsyncClient または AWSSecretsManagerAsyncClient を使用することで、ACM や Secrets Manager でも最新のハイブリッドポスト量子暗号スイートを使用できます。 ハイブリッドポスト量子 TLS の接続設定をチューニングする ハイブリッドポスト量子 TLS は初回ハンドシェイク時にレイテンシーと帯域幅のオーバーヘッドが発生しますが、そのコストは TLS セッションの期間全体で分散でき、接続設定を微調整することでさらに削減できます。このセクションでは、ハイブリッド PQC が TLS 接続に与える影響を軽減する 3 つの方法として、接続プーリング、接続タイムアウト、TLS セッション再開について説明します。 接続プーリング 接続プールは、サーバーへのアクティブな接続数を管理します。接続を閉じて再度開くことなく再利用できるため、接続確立のコストを時間の経過とともに分散できます。接続セットアップ時間の一部は TLS ハンドシェイクであるため、接続プールを使用することでハンドシェイクレイテンシーの増加による影響を軽減できます。 これを説明するために、テストサーバーに対して毎秒約 200 トランザクションを生成するテストアプリケーションを作成しました。HTTP クライアントの最大同時接続数設定を変更し、テストリクエストのレイテンシーを測定しました。AWS CRT HTTP クライアントでは、これは maxConcurrency 設定です。接続プールにアイドル状態の接続がない場合、リクエストレイテンシーには新しい接続の確立時間が含まれます。Wireshark を使用してネットワークトラフィックをキャプチャし、アプリケーションの実行期間中に発生した TLS ハンドシェイクの数を観察しました。図 3 は、 maxConcurrency 設定を増加させた場合のリクエストレイテンシーと TLS ハンドシェイク数を示しています。 図 3: 同時接続プールサイズの増加に伴うリクエストレイテンシーの中央値と TLS ハンドシェイク数 最も大きなレイテンシー改善は、 maxConcurrency 値が 1 より大きい場合に発生しました。それ以上では、レイテンシーの改善効果は頭打ちになりました。 maxConcurrency 値が 10 以下のすべてのケースで、接続内で追加の TLS ハンドシェイクが発生しましたが、レイテンシーの中央値にはあまり影響しませんでした。これらの変曲点はアプリケーションのリクエスト量によって異なります。重要なポイントは、接続プーリングにより接続を再利用でき、TLS ネゴシエーション時間の増加コストを多くのリクエストに分散できるということです。 maxConcurrency オプションの使用方法の詳細については、 AWS SDK for Java API リファレンス を参照してください。 接続タイムアウト 接続タイムアウトは接続プーリングと連携して機能します。接続プールを使用していても、アイドル状態の接続がプールによって閉じられるまでの時間には制限があります。この時間制限を調整することで、接続確立のオーバーヘッドを削減できます。 この設定を視覚化する良い方法は、バースト的なトラフィックパターンを想像することです。接続プールの同時接続数をチューニングしても、バースト期間がアイドル時間制限より長いため、接続が閉じ続けてしまいます。最大アイドル時間を増やすことで、バースト的な動作にもかかわらず、これらの接続を再利用できます。 接続タイムアウトの影響をシミュレートするために、10 個のスレッドを起動し、それぞれが 1 分間にわたって 5 秒ごとの定期スケジュールで同時にアクティブになるテストアプリケーションを作成しました。各スレッドが独自の接続を持てるように maxConcurrency を 10 に設定しました。AWS CRT HTTP クライアントの connectionMaxIdleTime を最初のテストでは 1 秒に、2 番目のテストでは 10 秒に設定しました。 最大アイドル時間が 1 秒の場合、各バースト間の時間中に 10 個すべてのスレッドの接続が閉じられました。その結果、テスト期間中に合計 100 個の接続が形成され、リクエストレイテンシーの中央値は 20.3 ms になりました。最大アイドル時間を 10 秒に変更すると、最初の 10 個の接続が後続の各バーストで再利用され、リクエストレイテンシーの中央値は 5.9 ms に減少しました。 アプリケーションに適した connectionMaxIdleTime を設定することで、TLS ネゴシエーション時間を含む接続確立のオーバーヘッドを削減し、アプリケーションのライフサイクル全体で時間を節約できます。 connectionMaxIdleTime オプションの使用方法の詳細については、 AWS SDK for Java API リファレンス を参照してください。 TLS セッション再開 TLS セッション再開により、クライアントとサーバーは新しい共有シークレットを確立するために通常実行される鍵合意をバイパスできます。代わりに、以前にネゴシエートされた共有シークレット、または以前のシークレットから派生した共有シークレットを使用して通信を迅速に再開します (実装の詳細は使用している TLS のバージョンによって異なります)。この機能はクライアントとサーバーの両方がサポートしている必要がありますが、利用可能な場合、TLS セッション再開により、ハイブリッドポスト量子 TLS に関連するハンドシェイク時間と帯域幅の増加を複数の接続のライフサイクル全体で分散できます。 まとめ この記事で説明したように、Kyber を使用したハイブリッドポスト量子 TLS は AWS KMS、Secrets Manager、ACM で利用可能です。この新しい暗号スイートによりセキュリティ基準が向上し、ワークロードをポスト量子暗号に備えることができます。ハイブリッド鍵合意は従来の ECDHE と比較して追加のオーバーヘッドがありますが、接続プーリング、接続タイムアウト、TLS セッション再開などの接続設定をチューニングすることで、これらの増加を軽減できます。 AWS KMS 、 Secrets Manager 、 ACM で今すぐハイブリッド鍵合意の使用を開始しましょう。 Brian Jarvis Brian は AWS Cryptography のシニアソフトウェアエンジニアです。ポスト量子暗号と暗号ハードウェアに関心を持っています。以前は AWS Security で、社内全体で使用される内部サービスの開発に携わっていました。Brian は Vanderbilt University で学士号を、George Mason University でコンピュータエンジニアリングの修士号を取得しています。「いつか」博士号を取得する予定です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2022 年 7 月 26 日に公開された Amazon Science Blog “ Preparing today for a post-quantum cryptographic future ” を翻訳したものです。 Amazon はポスト量子暗号の標準策定を支援し、お客様が活用できる有望な技術を提供しています。 ポスト量子暗号は、量子コンピュータでも破られない公開鍵暗号の新しい標準を開発することを目指しています。 米国国立標準技術研究所 (NIST) は先日、ポスト量子暗号の標準化プロセスの 第 3 ラウンドを完了 しました (※訳注)。量子コンピューティングはまだ黎明期にありますが、基礎物理学のより深い理解や困難な計算問題のより高速な解決など、社会に大きな恩恵をもたらす可能性を秘めています。多くの強力な新技術と同様に意図しない結果を招く可能性もあります。将来十分に大規模な量子コンピュータが構築された場合、現在データを保護するために使用されている公開鍵暗号アルゴリズムが破られる可能性があるとの見方もあります。 （訳注：その後 2024 年 8 月に、本ブログで言及されている Crystals Kyber は ML-KEM (FIPS 203) として、SPHINCS+ は SLH-DSA (FIPS 205) として正式に標準化されました） NIST、Amazon、そして広範な科学コミュニティは、ポスト量子時代にも耐えられる新しい公開鍵アルゴリズムの開発に取り組んでいます。歴史的に見ると、広く普及している高信頼性暗号アルゴリズムの置き換えには約 20 年を要してきました。Amazon では長期的な視点を重視しており、世界の動向を見据えて、可用性とセキュリティに対する大規模な長期投資を継続しています。 例えば、数年前に私たちは多大なコストと労力をかけて独自のチップを設計するという決断をしました。これにより、AWS のお客様にはセキュリティとパフォーマンスの大幅な向上がもたらされ、Alexa ユーザーはより素早く応答を得られるようになりました。ポスト量子暗号は、お客様の将来のために投資している分野のもう一つの例です。 Amazon は、ハッシュ関数、ワンタイム署名 (OTS)、Few-time 署名 (FTS) を使用する暗号署名スキームである SPHINCS+ の提案に貢献しました。図は「 The SPHINCS+ signature framework 」より引用 第 3 ラウンドの結果、NIST は鍵確立アルゴリズムの最終候補 (Crystals Kyber) と、Amazon が貢献した SPHINCS+ を含むデジタル署名アルゴリズムの 3 つの最終候補を選定したことを発表しました。これにより、これらの技術の標準化への道が開かれました。 NIST はまた、第 4 ラウンドで鍵確立のための追加アルゴリズムを評価することを示しました。これには Amazon チームメンバーが貢献した SIKE と BIKE が含まれます。Amazon は、 ETSI QSC 技術委員会、 IETF 、 Open Quantum Safe イニシアチブ、 NIST NCCoE PQ Migration などのプロジェクトや標準化活動にも業界の仲間とともに参加しています。これらの取り組みは、ポスト量子暗号の幅広い普及に向けた重要なステップです。 AWS におけるポスト量子暗号 新しい暗号技術の標準化が進む中、Amazon は AWS 上でポスト量子アルゴリズムと従来のアルゴリズムを併用できる機能を提供し、パフォーマンスの最適化を進めています。AWS はすでにポスト量子ハイブリッドキー交換に関する ドラフト標準 に貢献し、その仕様をオープンソースの s2n-tls に実装しました。s2n-tls は AWS 全体で Transport Layer Security (TLS) プロトコルの実装に使用されています。 また、 AWS Key Management Service (KMS) と AWS Certificate Manager (ACM) 、および AWS Secrets Manager の TLS エンドポイントにポスト量子対応の s2n-tls を導入しました。これにより、AWS SDK でハイブリッドポスト量子 TLS を有効にしてこれらのサービスに接続するお客様に、ポスト量子暗号のメリットを提供しています。全体として、2024 年までに複数の AWS サービスでお客様にポスト量子技術を提供するという目標に向けて取り組んでいます。これにより、お客様はポスト量子時代に備えて実験を行うことができます。 お客様のデータのセキュリティは Amazon の最優先事項です。将来起こりうる変化を予測し、潜在的に破壊的な技術に対してお客様が備えられるよう取り組んでいます。量子コンピューティングは大きなブレークスルーをもたらす可能性を秘めています。お客様がその技術革新を活用しながらもデータを長期にわたって安全に保てるよう、AWS は準備を進めています。 Amazon の研究と標準化活動の詳細については、以下のリンクをご覧ください。 ETSI CYBER; Quantum-safe Hybrid Key Exchanges Hybrid key exchange in TLS 1.3 Use of Post-Quantum KEM in the Cryptographic Message Syntax (CMS) Algorithms and Identifiers for Post-Quantum Algorithms in the Internet X.509 Public Key Infrastructure Post-quantum Hybrid Key Exchange in SSH Suppressing CA Certificates in TLS 1.3 On constant-time QC-MDPC decoding with negligible failure rate QC-MDPC decoders with several shades of gray Fast polynomial inversion for post quantum QC-MDPC cryptography On the Applicability of the Fujisaki-Okamoto Transformation to the BIKE KEM Prototyping post-quantum and hybrid key exchange and authentication in TLS and SSH Security of hybrid key encapsulation Faster post-quantum TLS handshakes without intermediate CA certificates PQ-HPKE: Post-Quantum Hybrid Public Key Encryption 著者について Matthew Campagna Matthew Campagna は Amazon Web Services のシニアプリンシパルセキュリティエンジニアです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。