本投稿は、Anil Malakar と Mahesh Kansara と Prabodh Pawar による記事 「 AWS DMS validation: A custom serverless architecture 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) は、ダウンタイムを最小限に抑えて AWS へのデータベース移行をサポートするマネージドサービスです。移行プロセス中にソースデータベースを完全に稼働したまま、同種の移行 (Oracle から Oracle など) と異種の移行 (Oracle から PostgreSQL など) の両方をサポートしています。この投稿では、 AWS サーバーレス サービスを使用して AWS DMS データ検証ソリューションをカスタムに構築する方法を説明します。 データ検証の課題 AWS DMS のお客様は、AWS DMS サービスが提供する データ検証機能 の使用を選択しないかもしれません。ビジネスの要件としてターゲット環境でデータを迅速に利用できるようにする必要がある場合、ロード、大規模なデータセットの転送、またはデータのリロード後、検証が完了するまでに時間がかかってしまうためです。その結果、手動で検証を実行するか、1 回限りのフルロードのみの検証を使用することを選択する可能性がありますが、これには追加の労力と時間が必要になります。 この問題は、ある企業のお客様が毎月手動で検証を行っていることが原因で判明しました。顧客がデータの不一致を発見して報告した時点で、関連する DMS ログはすでに期限切れになっていました。これにより、2つの問題が発生しました。１つは、お客様のビジネスに影響を与える可能性がある正確なデータ検証の機会を逃したこと、もう一つは、根本原因のトラブルシューティングにおいて重大な課題に直面したことです。 この課題に対処するため、カスタマイズされたソリューションアーキテクチャを構築しました。このアーキテクチャは、AWS DMS タスクの完了かエラーが発生したとき (フルロード移行の場合)、あるいは変更データキャプチャ (CDC) 中のソースにアクティブな書き込み/変更がないときに、データ検証プロセスを自動的に実行することを目的としています。 この投稿では、AWS DMS にイベント駆動型データ検証を実装する方法を紹介します。この投稿はアーキテクチャのガイダンスのみです。いくつかのコードスニペットが含まれていますが、それらは参照用であり、特定の実装ニーズに合わせて調整する必要がある場合があります。 当社のカスタムアーキテクチャアプローチでは、移行パフォーマンスを損なうことなく、自動データ検証の恩恵を受けることができます。ソースデータベースとターゲットデータベース間の単純なレコード数の比較から、ビジネス固有のデータポイントを対象とした複雑なマルチテーブルクエリまで、データ検証に柔軟性があります。このアーキテクチャは、検証結果をメールなどの選択した通信チャネルを通じて自動的に配信するので、AWS DMS コンソールにログインする必要がなくなります。これは、通知を通じてデータ品質を監視するのに役立ちます。 このカスタム検証アプローチは、DMS のネイティブな検証機能の代替手段ではなく並行して機能します。特定のデータ品質要件に基づいて検証チェックを自動化する柔軟性があります。 ソリューションの概要 このアーキテクチャは、 AWS サーバーレスコンピューティング とイベント駆動型のメカニズムを使用して、2 つの方法でデータを検証します： AWS DMS タスクのステータスが変更されたときに自動的に (例えば、 REPLICATION_TASK_STOPPED がトリガーされたとき) Amazon EventBridge で定義されたスケジュールに基づいて どちらの場合も、 AWS Lambda 関数がデータ検証を実行し、結果は Amazon Simple Notification Service (Amazon SNS) のメール通知を使用して自動的に送信されます。 次の図は、ソリューションアーキテクチャを示しています。 前提条件 始める前に、次の前提条件を満たす必要があります: AWS DMS レプリケーションインスタンスを作成します。 AWS DMS のソースエンドポイントとターゲットエンドポイントを作成し、それぞれソースデータベースとターゲットデータベースに接続します。 AWS DMS タスクを作成し、タスクにエンドポイントを関連付け、 Amazon CloudWatch ログを有効にします。 AWS Identity and Access Management （ IAM ）ロールを使用して、必要な AWS サービスにアクセスするための適切な権限があることを確認します。 このソリューションを実装するには、 AWS Lambda 関数を記述およびカスタマイズするための Python プログラミング言語 の知識が必要です。 Lambda 関数の作成 カスタムデータ検証を実装するには、まず Lambda 関数を作成し、特定のジョブを実行するためのファイルを追加します。これは、ソリューションをモジュール化し続けるためです。次のスクリーンショットは、さまざまなカスタムモジュールを示しています。 アーキテクチャは、以下のような構造であるべきです。これは必要に応じて拡張できます： dms_task_details – AWS DMS タスク情報を管理し、AWS DMS タスクのソースとターゲットエンドポイントを取得します。 dms_task_event – AWS DMS フルロードタスクから発生したイベントから AWS DMS タスクの詳細を取得します。 dms_task_latency – AWS DMS タスクのレイテンシーメトリクスを処理します: Amazon CloudWatch から AWS DMS レイテンシーメトリクスを取得します。 CDC のソースレイテンシーとターゲットレイテンシーの両方を監視します。 lambda_function – AWS DMS レプリケーションタスクの自動検証システムとして機能します。次の機能を実行します: AWS DMS イベントのモニタリング: AWS DMS タスクイベントをキャプチャして処理します。特に REPLICATION_TASK_STOPPED イベントを監視します タスクが停止すると、dms_task_event_details モジュールの dms_task_event_details メソッドを介して詳細なイベント処理がトリガーされます。 レプリケーションデータの検証: ソースとターゲットの両方の AWS DMS レプリケーションレイテンシーメトリックスを監視します。 並列処理を実装して、ソースとターゲットのデータ数を効率的に比較します。 検証を行う前のレイテンシー閾値チェック （5 秒未満） を含みます。 パラレルデータ検証: 並行実行には ThreadPoolExecutor を使用します。これは、ソースデータベースとターゲットデータベースで同時にクエリを実行するのに役立ちます。 ソースクエリとターゲットクエリを並行して実行することでパフォーマンスを最適化します。 notification – Amazon SNS を使用してアラート通知を実行します: 検証結果の自動通知を実装しています。 ソースとターゲットのデータ数の不一致を報告します。 トラブルシューティングに役立つ詳細なエラーメッセージを提供します。 requirements.txt – アプリケーションに必要なすべての依存関係を一覧表示します。この場合、Lambda 関数が MySQL データベースと通信できるようにするライブラリである PyMySQL バージョン 1.0.2 を指定しています。Lambda 関数を MySQL に接続するには、関数に PyMySQL パッケージを含む レイヤーを追加 する必要があります。 source_db – ソースデータベースの操作を管理します。AWS Secrets Manager に保存されている認証情報を使用して AWS DMS ソースデータベースに接続し、source.sql で定義されたクエリを実行するコードを実装します。 source.sql – ソースデータベースからデータを取得し、レプリケーションが成功したことを確認するためにターゲットデータベースと比較する SQL クエリが含まれています。 target_details – ターゲットデータベースの操作を処理します。AWS Secrets Manager に保存されている認証情報を使用して AWS DMS ターゲットデータベースに接続し、 target.sql ファイルに定義されているクエリを実行するコードを実装します。 target.sql – レプリケーションが成功したことを確認するために、ソースデータベースに対応するターゲットデータベースからデータを取得する SQL クエリが含まれています。 フルロードの場合 AWS DMS のステータス変更イベント REPLICATION_TASK_STOPPED が、Lambda 検証関数の lambda_handler 関数イベントパラメータで受信されます。 REPLICATION_TASK_STOPPEDイベントのイベントパラメータからイベントタイプを取得して、イベントリソースからタスクを取得します。次のコードを参照してください: event_type = event['detail']['eventType']    if(event_type == 'REPLICATION_TASK_STOPPED'): dms_event.dms_task_event_details(event) task_arn = event['resources'][0] Boto3 ライブラリを使用して AWS DMS クライアントを作成し、 describe_replication_tasks メソッドのレスポンスからソースとターゲットの詳細を取得します: dms_client = boto3.client('dms',region_name=os.environ.get('AWS_REGION', 'us-east-1')) response = dms_client.describe_replication_tasks(              Filters=[                 {                     'Name': 'replication-task-arn',                     'Values': [task_arn]                 }              ]         ) task = response['ReplicationTasks'][0]   # Get the source and target endpoint ARNs          source_endpoint_arn = task['SourceEndpointArn']          target_endpoint_arn = task['TargetEndpointArn'] クエリの実行と結果送信の自動化 次のステップは、Lambda 検証関数が各データベースで実行して結果を比較するためのソースおよびターゲット固有のクエリを作成することです。Amazon SNS を使用して、結果をユーザーにメールで送信できます。 以下のコードスニペットを参照して、ソースとターゲットからデータを取得し、結果を比較することができます。以下のコードでは、source.sql と target.sql で単純な count クエリを使用してソースとターゲットのデータを比較していますが、クエリを複数のテーブルに拡張したり、成功または失敗を定義するロジックをカスタマイズしたりすることができます。 # get_source_data_details method retrieves DMS task source data by connecting to the source # MySql database, reading the source.sql file, and executing its defined query source_data = sourcedb.get_source_data_details(task_details['Source']) # get_redshift_table_details method retrieves DMS task target data by connecting to the target # Redshift database, reading the target.sql file, and executing its defined query target_data = dmstarget.get_redshift_table_details(task_details['Target']) if source_data==target_data: notify.send_notification('DMS custom data validation succeeded') CDCの場合 Lambda 検証関数は、EventBridge で定義されたスケジュールに従ってトリガーされます。AWS DMS タスクのレイテンシーメトリクスである CDCLatencySource と CDCLatencyTarget を取得する必要があります。 Boto3 を使用して CloudWatch クライアントを作成します： cloudwatch = boto3.client('cloudwatch', region_name=region_name) 以下のコードを使用して CloudWatch からメトリクスを取得します： metrics = ['CDCLatencySource', 'CDCLatencyTarget'] ソースとターゲットのレイテンシーメトリクスを取得するには、CloudWatch クライアントを使用して以下のコードを参照してください： response = cloudwatch.get_metric_statistics( Namespace='AWS/DMS', MetricName=metric, Dimensions=[ {'Name': 'ReplicationTaskIdentifier', 'Value': taskIdentifier}, {'Name': 'ReplicationInstanceIdentifier', 'Value': instance_id} ], StartTime=start_time, EndTime=end_time, Period=6000, # 5-minute intervals Statistics=['Average'] ) source_latency_value = metric['metric'][0]['Average'] target_latency_value = metric['metric'][0]['Average'] レイテンシーが 5 秒未満として指定して下さい（要件に応じて変更可能）。Lambda 検証関数はソースとターゲットの両方のデータベースで並列クエリを実行します。以下のコードでは、source.sql と target.sql で単純な count クエリを使用してソースとターゲットのデータを比較していますが、複数のテーブルにクエリを拡張したり、成功または失敗を定義するロジックをカスタマイズしたりすることができます。 # get_data_parallel メソッドは 2 つのタスクを同時に実行します： # 1. DMS タスクのソースデータを取得：# ソースの MySQL データベースに接続し、source.sql のクエリを読み取って実行 # 2. DMS タスクのターゲットデータを取得：# ターゲットの Redshift データベースに接続し、target.sql のクエリを読み取って実行 if source_latency_value < 5 and target_latency_value < 5: # Lambda ハンドラーでの使用 source_data, target_data = get_data_parallel(sourcedb, dmstarget) Lambda 検証関数は両方のクエリ結果を受け取ると、それらを比較し、Amazon SNSを使用して通知を送信します。以下は、メールで受信した通知の例です: This is a notification from DMS Lambda validation for replication task dms-cdc-task and relication Instance dms-validation-demo-ri has source_data count – 1000000 and target_data count - 1000000! EventBridge のルールを作成してください また、AWS DMS イベントをキャプチャするように EventBridge ルールを設定し、スケジューラーを実行して Lambda 検証機能を呼び出す必要があります。 EventBridge コンソールで、次の JSON に示されている構成を使用してルールを作成します。このルールはフルロードのシナリオで使用されます。 { "source": ["aws.dms"], "detail-type": ["DMS Replication Task State Change"], "detail": { "eventType": ["REPLICATION_TASK_STOPPED"], "type": ["REPLICATION_TASK"], "category": ["StateChange"] } } 次のスクリーンショットに示すように、Lambda 関数にルールのターゲットを設定します。 CDC の場合は、特定のスケジュールで実行するスケジューラーを作成し、ターゲットに Lambda 検証機能を設定します。 技術的範囲と制限事項 このソリューションを実装する前に、その技術的な境界と制約を理解することが重要です。 このセクションでは、このアーキテクチャが達成できることとその制限について概説し、特定のユースケースの要件を満たすかどうかを判断するのに役立ちます。 データベースサポート : 本ソリューションでは MySQL から Redshift への移行シナリオを示していますが、他のデータベースにも対応できるように拡張できます。ただし、照合順序の違いを検証し、文字セットの互換性を確認し、お客様の環境で十分にテストすることを忘れないでください。 LOB の取り扱い : このソリューションは Large Object (LOB) の検証をサポートしていません。これらのカラムを検証の対象から除外することを検討してください。 クエリ : クエリの実行に 15 分以上かかる場合は、Lambda の代わりに Amazon Elastic Container Service (Amazon ECS) または AWS Fargate を使用してください。 コストに関する考慮事項 このソリューションは自動化された検証機能を提供しますが、検証チェックの頻度を調整し、CloudWatch で適切なログ保持期間を設定し、Lambda 関数の実行時間を最適化することで、コストを効果的に管理できます。 不要なコストの発生を防ぐため、このアーキテクチャの実装後はすべてのリソースを削除することを忘れないでください。 まとめ この投稿では、AWS DMS のデータ検証プロセスを自動化し、手動の作業を削減するアーキテクチャをご紹介しました。 このアーキテクチャは、サーバーレスコンピューティングとイベント駆動型アーキテクチャを使用して、データ検証ルーチンを動的にトリガーし、レイテンシーに関する懸念に対処し、データ移行のパフォーマンスへの影響を最小限に抑えます。 ご自身のユースケースでこのアプローチを試してみてください。 著者について Anil Malakar Anil はアマゾンウェブサービスのシニア・テクニカル・アカウント・マネージャーで、アプリケーションのモダナイゼーションやアーキテクチャ、ソリューション設計を専門としています。 Mahesh Kansara Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWSを使用する際のソリューションの価値向上を支援しています。 Prabodh Pawar Prabodh は、Amazon Web Services のDatabase Migration Service チームのシニアデータベースエンジニアです。彼はデータベース移行の自動化に役立つサービスとツールを開発しています。Prabodh は、お客様と一緒に、お客様のマイグレーションジャーニーを効率化することに情熱を注いでいます。

本投稿は、 Nelly Susanto による記事 「 Assess and migrate your database using AWS DMS Schema Conversion CLI 」を翻訳したものです。 DMS Schema Conversion は、 AWS Database Migration Service (AWS DMS) の機能で、AWS DMS コンソールと AWS Command Line Interface (AWS CLI) からアクセスできます。これは AWS DMS のフルマネージドな機能で、データベースの評価と変換が可能です。このマルチパートシリーズの 2 回目の投稿では、DMS Schema Conversion コンポーネントの作成と、評価や変換などの移行アクティビティの実行を自動化する方法を紹介します。このシリーズの 最初の投稿 では、DMS Schema Conversion の設定における前提条件の準備、DMS Schema Conversion の設定、AWS DMS コンソールを通じた移行アクティビティの実行についてのガイダンスを提供しています。 AWS CLI を使用する主な利点の 1 つは、特に大規模なデータベース移行において移行プロセスを自動化および合理化できることです。 この投稿では、DMS Schema Conversion を使用して Amazon Relational Database Service (Amazon RDS) for SQL Server データベースを評価し、 Amazon Aurora PostgreSQL-Compatible Edition に変換する方法を記載します。DMS Schema Conversion コンポーネントのセットアップと構成の自動化、評価レポートの生成、データベースストレージとコードオブジェクトの変換、変換されたコードの Amazon Simple Storage Service (Amazon S3) へのエクスポート、そして変換されたコードをターゲットデータベースに適用する方法について、順を追って説明します。 ソリューションの概要 DMS Schema Conversion CLI は AWS CLI Version 2 で利用可能です。現在インストールされているバージョンを確認するには、コマンドプロンプトで次のコマンドを使用してください： aws --version aws-cli/2.17.38 Python/3.11.9 Darwin/24.3.0 exe/x86_64 AWS CLI Version 2 のインストール方法については、 AWS CLI の使用開始 をご覧ください。 DMS Schema Conversionの主要コンポーネントは以下の通りです： インスタンスプロファイル – インスタンスプロファイルは、DMS Schema Conversion が使用するネットワークとセキュリティを定義します。また、内部の DMS Schema Conversion リソースが起動される場所も決定します。 データプロバイダー – データプロバイダーは、DMS Schema Conversion が接続するためのデータベースタイプ、ソースおよびターゲットの接続詳細に関する情報を保存します。 移行プロジェクト – 移行プロジェクトは、すべての DMS Schema Conversion 移行アクティビティの基盤です。ここでは、インスタンスプロファイル、ソースおよびターゲットのデータプロバイダー、移行ルールなどの移行エンティティを定義します。 まず、AWS CLI を使用して主要な DMS Schema Conversion コンポーネントを作成する方法を説明します。 次に、データベースオブジェクトの評価や変換など、移行作業を実行するためのコマンドについて説明します。 このポストでは、AWS リージョンとして us-east-1 を使用し、デフォルトの AWS プロファイルを使用します。 export AWS_DEFAULT_REGION='us-east-1' export AWS_PROFILE=default AWS CLI の環境変数の設定方法については、 AWS CLI の環境変数の設定 をご覧ください。 インスタンスプロファイルの作成 インスタンスプロファイル は、DMS Schema Conversion が使用するネットワークとセキュリティの設定を指定し、内部の DMS Schema Conversion リソースがどこにデプロイされるかを決定します。インスタンスプロファイルの作成プロセスの一部として、DMS Schema Conversion が使用すべきインスタンスプロファイル名、ネットワークタイプ、サブネットグループ、セキュリティグループを指定します。 aws dms create-instance-profile \ --publicly-accessible \ --network-type IPV4 \ --instance-profile-name "ip-demo" \ --description "Instance profile sql to Aurora PG" \ --subnet-group-identifier "sc2" \ --vpc-security-groups sg-052b3xxx \ --query 'InstanceProfile.InstanceProfileArn' \ --output text #Output return Instance Profile arn arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI データプロバイダーの作成 データプロバイダー は、DMS Schema Conversion で使用されるデータベースの種類と、ソースデータベースとターゲットデータベースに関する接続情報に関するメタデータを定義します。このステップでは、データプロバイダーの名前、データベースエンジンの種類、データベースサーバー名、ポート、データベースに接続するための DMS Schema Conversion の SSL モードなどのデータベース設定を指定して、データプロバイダーを作成します。 #Create Source (SQL Server) Data Provider aws dms create-data-provider \ --data-provider-name "demo-sql" \ --description "sql server" \ --engine sqlserver \ --settings "{\"MicrosoftSqlServerSettings\": {\"ServerName\": \"tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com\", \"Port\": 1433, \"DatabaseName\": \"tsw\"}}" \ --query 'DataProvider.DataProviderArn' \ --output text #Return of source data provide arn arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA #Create Target (Aurora PostgreSQL) Data Provider aws dms create-data-provider \ --data-provider-name "demo-pg" \ --description "Aurora PostgreSQL" \ --engine "aurora-postgresql" \ --settings "{\"PostgreSqlSettings\": {\"ServerName\": \"apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com\", \"Port\": 1234, \"DatabaseName\": \"postgres\", \"SslMode\": \"none\"}}" \ --query 'DataProvider.DataProviderArn' \ --output text #Output return of target data provider arn arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4 移行プロジェクトの作成 DMS Schema Conversion の 移行プロジェクト は、インスタンスプロファイル、ソースとターゲットのデータプロバイダー、移行ルールなどの主要コンポーネントの統合を調整します。AWS CLI コマンドを使用して移行プロジェクトを作成するには、まずプロジェクト名を指定します。次に、プロジェクトが使用するインスタンスプロファイルを関連付けます。次に、ソースとターゲットのデータプロバイダーとそのシークレット、および AWS Secrets Manager の AWS ID および AWS Identity and Access Management （IAM）の役割を指定します。最後に、評価レポートとエクスポートされた変換コードの Amazon S3 パスを設定し、Amazon S3 バケットの IAM ロールを指定します。 aws dms create-migration-project \ --migration-project-name "demo-sql-apg" \ --instance-profile-identifier "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI" \ --source-data-provider-descriptors "{\"DataProviderIdentifier\": \"arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA\", \"SecretsManagerSecretId\": \"arn:aws:secretsmanager:us-east-1:123456789012:secret:sql-aiml-9Wmj68\", \"SecretsManagerAccessRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --target-data-provider-descriptors "{\"DataProviderIdentifier\": \"arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4\", \"SecretsManagerSecretId\": \"arn:aws:secretsmanager:us-east-1:123456789012:secret:apg1-Lzc3TT\", \"SecretsManagerAccessRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --description description \ --schema-conversion-application-attributes "{\"S3BucketPath\": \"s3://amzn-s3-demo-bucket\", \"S3BucketRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --query 'MigrationProject.MigrationProjectArn' \ --output text #Output project arn arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II ソース選択ルールの作成 DMS Schema Conversion のコンポーネントを作成する AWS CLI コマンドについて説明してきました。それでは、移行アクティビティを実行するコマンドを見てみましょう。最初のステップは、DMS Schema Conversion で移行プロセスに含めたいデータベースオブジェクトを定義するソースの選択ルールを作成することです。以下は、ユースケースに合わせて必要に応じて変更できる選択ルールの例です。 cat > source_rules.json << EOF { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "server-name": "tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "database-name": 'tsw', "schema-name": 'dbo' }, "rule-action": "explicit" ]} EOF このルールを設定したら、次のステップであるデータベースオブジェクトの評価と変換に進むことができます。 アセスメントレポートの作成 アセスメントを開始するには、start-metadata-model-assessment コマンドを使用します。移行プロジェクトの Amazon Resouce Name (ARN) と、前のセクションで作成したソースの選択ルールを指定してください。 aws dms start-metadata-model-assessment \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://source_rules.json #Response { "RequestIdentifier": "44fc9838-146f-41d8-b13c-923b3cc704c2" } 評価の進捗状況を確認するには、describe-metadata-model-assessments コマンドを使用してください。 aws dms describe-metadata-model-assessments \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS This is the full list of operation statuses: IN_PROGRESS, SUCCESS, FAILED, DUPLICATE, RETRY, CANCELING, CANCELLED. 評価レポートのエクスポート 評価レポートを作成したら、export-metadata-model-assessment コマンドを使用してレポートを Amazon S3 にエクスポートします。PDF 形式のサマリレポートには、移行の複雑さの推定値が記載されています。DMS Schema Conversion には、手動でのアクションが必要なオブジェクトや推奨事項を含む詳細なレポートを CSV 形式で生成するオプションもあります。 以下のコードは、サマリレポートを PDF 形式でエクスポートする方法を示しています。サマリではなく詳細なレポートが必要な場合は、assessment-report-type を csv に設定してください。 aws dms export-metadata-model-assessment \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --selection-rules file://source_rules.json\ --file-name "assessment report" \ --assessment-report-types "pdf" #Assessment reports are available in S3 Exporting metadata model assessment... { "PdfReport": { "S3ObjectKey": "demo-sql-apg/report.pdf", "ObjectURL": "https://sc-123456789.s3.amazonaws.com/demo-sql-apg/report.pdf" } } { "CsvReport": { "S3ObjectKey": "demo-sql-apg/report.zip", "ObjectURL": "https://sc-123456789.s3.amazonaws.com/demo-sql-apg/report.zip" } } 変換を実行 変換を実行する準備ができたら、 start-metadata-model-conversion を使用します。以前に作成したマイグレーションプロジェクトの ARN とソースの選択ルールを指定してください： aws dms start-metadata-model-conversion \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://source_rules.json describe-metadata-model-conversions コマンドを使用して、変換の進捗状況を確認できます： aws dms describe-metadata-model-conversions \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 変換したコードをSQLとしてエクスポート 変換が完了すると、変換されたコードは移行プロジェクト内で利用可能になります。SQL としてエクスポートするか、ターゲットデータベースに直接適用することができます（適用方法については次のセクションを参照してください）。エクスポートまたは適用する前に、まずターゲットの選択ルールでデータベースオブジェクトを定義する必要があります。以下のコードは、ターゲット選択ルールの例です。必要に応じて、ユースケースに合わせて修正することができます。 cat > target_rules.json << EOF { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "server-name": " apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "schema-name": 'tsw_dbo' }, "rule-action": "explicit" } ] } EOF これで、 start-metadata-model-export-as-script コマンドを使用して、変換されたコードを SQL としてエクスポートできます。移行プロジェクト、ターゲット選択ルール、Origin には対象として Target を指定、ファイル名を記載してください： aws dms start-metadata-model-export-as-script \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://target_rules.json \ --origin TARGET \ --file-name "SaveAsSQL" エクスポートの進行状況を確認するには、describe-metadata-model-export-as-script コマンドを使用してください: aws dms describe-metadata-model-exports-as-script \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 変換されたコードのターゲットデータベースへの適用 変換されたコードをターゲットデータベースに適用するには、start-metadata-model-export-to-target コマンドを使用します。以前に作成した移行プロジェクトの ARN とターゲットの選択ルールを指定してください： aws dms start-metadata-model-export-to-target \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://target_rules.json \ --overwrite-extension-pack 適用の進行状況を確認するには、describe-metadata-model-exports-to-target を使用します： aws dms describe-metadata-model-exports-to-target \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 移行後のクリーンアップ 移行が完了したら、DMS Schema Conversion リソースをクリーンアップできます。 #Cleanup # Delete migration project aws dms delete-migration-project \ > --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II #Response { "MigrationProject": { "MigrationProjectName": "demo-sql-apg", "MigrationProjectArn": "arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II", "MigrationProjectCreationTime": "2024-08-01T17:29:05.681257 + 00:00", "SourceDataProviderDescriptors": [ { "SecretsManagerSecretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:sql-aiml-9Wmj68", "SecretsManagerAccessRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp", "DataProviderName": "demo-sql", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA" } ], "TargetDataProviderDescriptors": [ { "SecretsManagerSecretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:apg1-Lzc3TT", "SecretsManagerAccessRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp", "DataProviderName": "demo-pg", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4" } ], "InstanceProfileArn": "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI", "InstanceProfileName": "ip-demo", "TransformationRules": "{\"rules\":[]}", "SchemaConversionApplicationAttributes": { "S3BucketPath": "s3://amzn-s3-demo-bucket", "S3BucketRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp" } } } #Delete source data provider aws dms delete-data-provider --data-provider-identifier arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA #Response { "DataProvider": { "DataProviderName": "demo-sql", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA", "DataProviderCreationTime": "2024-08-01T17:27:12.902435 + 00:00", "Engine": "sqlserver", "Settings": { "MicrosoftSqlServerSettings": { "ServerName": "tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "Port": 1433, "DatabaseName": "tsw", "SslMode": "none" } } } } #Delete Target data provider aws dms delete-data-provider --data-provider-identifier arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4 #Response { "DataProvider": { "DataProviderName": "demo-pg", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4", "DataProviderCreationTime": "2024-08-01T17:27:12.902435 + 00:00", "Engine": "aurora-postgresql", "Settings": { "MicrosoftSqlServerSettings": { "ServerName": "apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "Port": 1234, "DatabaseName": "postgres", "SslMode": "none" } } } } #Delete Instance Profile aws dms delete-instance-profile --instance-profile-identifier arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI #Response { "InstanceProfile": { "InstanceProfileArn": "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI", "KmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/e26404b5-853a-4a33-95b9-99ef043cd207", "PubliclyAccessible": true, "NetworkType": "IPV4", "InstanceProfileName": "ip-demo", "InstanceProfileCreationTime": "2024-08-01T17:25:33.128750 + 00:00", "SubnetGroupIdentifier": "sc2", "VpcSecurityGroups": [ "sg-052b3xxx" ] } } まとめ 特に大規模なデータベース移行の場合で、AWS CLI による DMS Schema Conversion を使用する主な利点は、移行プロセスを自動化および合理化できることです。この投稿では、AWS CLI を使用して、インスタンスプロファイル、データプロバイダー、移行プロジェクトなど、主要な DMS Schema Conversion のコンポーネントを設定する方法を示しました。選択ルールの作成、評価レポートの生成、変換の実行、変換されたコードのエクスポート、変換されたコードのターゲットデータベースへの適用という移行ワークフローを順を追って説明しました。このソリューションは、移行プロセスの自動化と標準化に役立ち、手作業を減らし、リスクを最小限に抑えます。チームが複数のワークロードを同時に移行する必要がある場合に最適です。大規模な移行を計画している場合は、このソリューションを活用して作業を合理化し、移行を加速することをお勧めします。 DMS SC CLI を使用してデータベースオブジェクトを評価および変換する方法の詳細については、 AWS DMS CLI リファレンスガイド をご覧ください。 著者について Nelly Susanto Nelly は、AWS Database Migration Accelerator の主任データベース移行スペシャリストです。彼女はデータベースとデータウェアハウスのワークロードの移行と複製に焦点を当てた技術経験が 10 年以上あります。彼女はお客様のクラウドジャーニーを支援することに情熱を注いでいます。

本投稿は、 Caius Brindescu と Mahesh Kansara による記事 「 Real-time Iceberg ingestion with AWS DMS 」を翻訳したものです。 これは、AWS とのパートナーシップに基づいた、Etleap の主任エンジニアである Caius Brindescu によるゲスト投稿です。 タイムリーな意思決定には、低レイテンシーで最新のデータにアクセスすることが不可欠です。しかし、多くのチームにとって、データレイクへのレイテンシーを削減することは、更新の処理、パイプラインの複雑さ、ウェアハウスとの統合と格闘することを意味します。 Apache Iceberg は、リアルタイムの取り込みとマルチエンジンアクセスを実用的かつ効率的にすることで、この方程式を変えます。 Etleap は、AWS データ＆アナリティクスコンピテンシーと Amazon Redshift サービスレディの認定を受けた AWS アドバンストテクノロジーパートナー です。この投稿では、Etleap が、 AWS Database Migration Service（AWS DMS） を使用して、オペレーション中の SQL データベースからIceberg テーブルにデータをストリーミングする、スケーラブルでほぼリアルタイムのパイプラインの構築にどのように役立つかを示します。AWS DMS は、 すべての主要なデータベース から AWS への変更データキャプチャ（CDC）のための堅牢で構成可能なソリューションとして使用できます。 実際のユースケースを参考に、一貫性、耐障害性、クラウドデータウェアハウスとの統合をどのように提供しているかをご紹介します。これにより、最も重要な時にデータがアクションを促す原動力となります。 AWS DMS の概要 AWS DMS は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、その他のタイプのデータストアの移行を簡単に実現するクラウドサービスです。 AWS DMS を使用して、データを AWS クラウドに移行したり、クラウドとオンプレミス環境の組み合わせ間で移行したりすることができます。 AWS DMS を使用すると、1 回限りの移行を実行できるほか、継続的な変更を複製して、ソースとターゲットを様々な要件に応じてほぼリアルタイムで同期させることができます。ソースで変更が行われてからターゲットに複製されるまでに、わずかな遅延が生じる可能性があります。この遅延、つまり レイテンシー は、AWS DMS の設定、ネットワーク帯域幅、ソースおよびターゲットデータベースの負荷など、さまざまな要因の影響を受ける可能性があります。 次の図は、AWS DMS のレプリケーションプロセスを示しています。 Iceberg の概要 Iceberg は、データレイク上の大規模分析用に設計されたオープンテーブルフォーマットです。 コストの高いテーブルの書き換えやダウンタイムを必要とせずに、ACID トランザクションの完全サポート、隠しパーティショニング、スキーマ進化、タイムトラベルを提供します。 Iceberg は、Hive のような古い形式とは異なり、メタデータとデータファイルを別々に追跡し、スナップショットの高速読み取りと効率的なファイルレベルの更新を可能にします。データファイルはイミュータブルで、新しいスナップショットを作成することで変更が適用されるため、upserts や delete などの操作が安全で効率的になります。次の図は、Iceberg テーブルのファイルレイアウトを示しています。 Iceberg は、エンジンに依存しないデータストレージフォーマットであり、Spark、Apache Flink、Trino （ Amazon Athena などのサービスを含む）、および Hive と統合されています。 これは、複数のダウンストリームシステムに確実にサービスを提供できる、本番環境グレードの低レイテンシーデータレイクアーキテクチャを構築するための強固な基盤となります。 カタログをクエリすることで、各エンジンは格納されているデータの一貫したビューを持つことができます。 Etleap の顧客が Iceberg を必要とする理由 Etleap のお客様にとって、低レイテンシーは最優先事項です。 ここでいうレイテンシーとは、ソースデータとターゲットデータの間の時間差として定義しています。 例えば、ターゲットがソースより 5 分遅れている場合、レイテンシーは 5 分となります。 従来のデータウェアハウスやデータレイクでは、レイテンシーをどこまで低く抑えられるかに制限があります。 ウェアハウスでは、新しいデータがステージング領域にロードされ、その後、ターゲットテーブルの大部分をスキャンしてから書き換えるようなマージが実行されます。 データに 2 回アクセスする (1 回は読み取り、1 回は書き換え) ことが、遅延の大部分を引き起こしています。 一方、データレイクは通常追加専用で、更新を効率的に処理しません。すべての行バージョンを保存してクエリ時に最新のバージョンを解決する（クエリのパフォーマンスを犠牲にする）か、ロード時に最新の状態を事前に計算することができます。ロード時にコストの高いテーブルの書き換えが必要になり、待ち時間が長くなります。 Iceberg は、Etleap ユーザーにとってこれらの両方の課題を解決します。ある事例では、ヨーロッパの自転車シェアリング企業が、自転車ラックの空き状況を監視し、ラックが空の状態で放置される時間を制限する規制を遵守するために運用ダッシュボードを使用しています。Iceberg は、パイプラインのレイテンシーを 5 ～ 10 分から数秒に短縮することで、より リアルタイムなデータを可能にし、オペレーターがラックのバランスを取り直し、ペナルティを回避するための重要な追加時間を提供します。 別のケースでは、チームは 1 つのデータセットを複数のデータウェアハウスで利用できるようにする必要がありました。以前は、移行先ごとに別々のパイプラインを構築して維持する必要がありました。Icebergを使用すると、データを一度ロードして複数のエンジンからのクエリがサポートされるため、複雑さが軽減され、ツール間の一貫性が保たれます。 ソリューションの概要 最初のステップは、ソースデータベースからできるだけ迅速に更新を抽出することです。このために、高スループットのデータキャプチャ (CDC) に確実にスケールする AWS DMS を使用します。AWS DMS は変更を Amazon Kinesis Data Streams に書き込みます。Etleap はこのデータストリームを読み取り、 Amazon EMR 上の Flink を使用して変更を処理します。 そこから、データは Amazon S3 に保存された Iceberg テーブルに書き込まれ、 AWS Glue がデータカタログとして使用されます。これにより、複数のクエリエンジンからデータをクエリできるようになります。 以下の図は、パイプラインのアーキテクチャを示しています。 完全に一度だけの処理 低遅延のパイプラインでデータの整合性を維持するには、データを迅速に移動するだけでは不十分です。また、データを一度だけ処理する必要もあります。レコードが重複または欠落していると、特に更新が多いワークロードでは、誤った結果になる可能性があります。変更が AWS DMS によってキャプチャされ、Kinesis Data Streams にストリーミングされた後、Etleap は Flink の2フェーズコミットプロトコルを使用して1回だけ処理します。 フェーズ 1 では、Flink が各並列データストリームにチェックポイントバリアを挿入します（次の図を参照）。 バリアがパイプラインを流れる際、各オペレーターは一時停止し、同期的に状態を保存してから、バリアをダウンストリームに転送します。その後、状態のスナップショットを耐久性のあるストレージ（この場合は Amazon S3 ）に非同期で永続化します。 この分離により、I/O 待ちの間も重要な処理がブロックされないことが保証されます。オペレーターが状態の保存に成功すると、チェックポイントが完了したことを Flink Job Manager に通知します。 フェーズ 2 では、パイプラインのすべての部分でチェックポイントを完了したことをジョブマネージャーが確認し、その後グローバルなコミット信号をブロードキャストします (次の図を参照)。 この時点で、オペレーターは外部システムへのデータ書き込みなどの副作用を安全に実行できます。 Etleap の場合、これには Iceberg テーブルへの新しいスナップショットのコミットや、モニタリング用のメトリクスの記録が含まれます。 耐障害性をサポートするため、コミット操作は冪等性を備えるように実装されています。これは、Iceberg テーブルに新しいスナップショットを書き込む場合と、パイプラインのメトリクスとログを記録する場合の両方に適用されます。 この段階でパイプラインが失敗し、再起動が必要になった場合、Flink は安全にコミットを再試行します。 各操作は、重複や不整合を生じることなく複数回実行できるため、障害が発生した場合でもデータの正確性を維持できます。 パズルの最後のピースは、チェックポイントの頻度、つまりパイプラインがどのくらいの頻度でデータを Iceberg にコミットするかです。 この設定は、パイプライン全体のレイテンシーを決定する上で重要な役割を果たします。 ユースケースを評価した結果、3 秒のチェックポイント間隔を選択しました。 これは効果的なバランスを取っています。エンドツーエンドのレイテンシーを 5 秒未満に抑えつつ、頻繁なコミットによるパフォーマンスのオーバーヘッドを最小限に抑えています。 この間隔は、次のセクションで説明するように、ウェアハウスのメタデータ更新サイクルともうまく一致しています。 テーブルのメンテナンスとデータウェアハウスの統合 Iceberg テーブルは時間の経過とともに、メタデータ、スナップショット、最適でないファイルレイアウトを蓄積し、パフォーマンスが低下する可能性があります。 クエリのパフォーマンスを高く保ち、ストレージを効率的に使用するためには、定期的なメンテナンスが不可欠です。 これには、データファイルの圧縮、スナップショットの有効期限切れ、メタデータのクリーンアップなどのタスクが含まれます。 Etleap は、取り込みを中断することなく、これらのメンテナンスタスクを自動的に処理します。 メンテナンスジョブはデータパイプラインと並行して実行され、ファイルサイズの分布やスナップショット数などの発見的手法に基づいてトリガーされます。 次のスクリーンショットは、データフローを中断することなく、並行してメンテナンス作業を実行している Etleap パイプラインの例を示しています。 最後の要素はウェアハウスの統合です。Iceberg の主な利点の1つは相互運用性です。Athena、 Amazon Redshift 、Snowflake、Databricks などのエンジンから同じテーブルをクエリできます。 手動でのセットアップも可能ですが、Etleap はパイプラインの作成時にこれらの統合を自動的に設定できます。 例えば、Iceberg テーブルを Snowflake でクエリ可能にするために、AWS Glue とのカタログ統合を作成し、テーブルの Amazon S3 ロケーションを指す外部ボリュームを定義します： CREATE CATALOG INTEGRATION ETLEAP_ICEBERG_CATALOG CATALOG_SOURCE = GLUE GLUE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/etleap-streaming-ingestion-snowflake' GLUE_CATALOG_ID = '123456789012' CATALOG_NAMESPACE = 'iceberg_lake' GLUE_REGION = 'us-east-1' TABLE_FORMAT = ICEBERG ENABLED = TRUE ; CREATE EXTERNAL VOLUME ETLEAP_ICEBERG_EXTERNAL_VOLUME STORAGE_LOCATIONS = (( NAME = 'etleap_iceberg_bucket' STORAGE_PROVIDER = 'S3' STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/etleap-streaming-ingestion-snowflake' STORAGE_BASE_URL = 's3://<bucket\_name>/iceberg' )) ALLOW_WRITES = FALSE ; その後、Snowflake で Iceberg テーブルを指す新しいテーブルを作成できます： CREATE OR REPLACE ICEBERG TABLE "product_order" EXTERNAL_VOLUME = ETLEAP_ICEBERG_EXTERNAL_VOLUME CATALOG = ETLEAP_ICEBERG_CATALOG CATALOG_NAMESPACE = 'iceberg_lake' CATALOG_TABLE_NAME = 'product_order'; Snowflake を最新の Iceberg スナップショットと同期させるために、Etleap は各コミット後に REFRESH 操作をトリガーします。 これにより、ユーザーは最新のデータを確認でき、Snowflake のビューが大きく遅れることを防ぎます。 リフレッシュの同期的な性質は、自然なレート制限メカニズムも提供し、スナップショットの可視性をウェアハウスのクエリパフォーマンスと整合させます。 まとめ AWS DMS、Kinesis Data Streams、Amazon EMR などの AWS ツールと、Iceberg の更新、スキーマ進化、マルチエンジンアクセスのサポートを組み合わせることで、低レイテンシーで信頼性の高いデータパイプラインを Iceberg に構築することが可能です。 このポストでは、運用データベースからの変更を Iceberg にストリーミングし、エンドツーエンドのレイテンシーを 5 秒未満に抑えながら、データの整合性を維持し、Snowflake のようなツールでのダウンストリーム分析をサポートする方法を紹介しました。 このアーキテクチャは、データレイクの最新化、エンジン間のアクセス統合、リアルタイムの運用要件の達成を目指すチームにとって、強力な基盤となります。 Etleap がどのようにして自動パイプライン作成、耐障害性がある処理、Iceberg のメンテナンスを含め、これらをすぐに実現可能にするかを確認するには、 サインアップ して、パーソナライズされたデモをご覧ください。 著者について Caius Brindescu Caius は Etleap のプリンシパルエンジニアで、ソフトウェア開発で 20 年以上の経験があります。彼は、Hadoop、Spark、Flink などのシステムでの作業を含む、Java バックエンド開発とビッグデータテクノロジーを専門としています。彼はオレゴン州立大学で博士号と AWS certification Big Data – Specialty certification を取得しています。 Mahesh Kansara Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWSを使用する際のソリューションの価値向上を支援しています。

本ブログは、東京大学松尾・岩澤研究室が主催する AI エンジニアリング実践講座において、AWS を活用した講座の取り組みをご紹介する、AWS との共同寄稿です。 はじめに 本ブログシリーズでは、2025 年 4 月から 7 月にかけて実施した東京大学 松尾・岩澤研究室の AI エンジニアリング実践講座において、 AWS クラウドを活用した実践的な学習環境を用意し、1400 名を超える受講申し込み者に対して、個別のAWSアカウントを提供する大規模なオンライン講義を開講した取り組みを全 3 回に分けてまとめたものです。 [準備、構築編] 講義に参加する受講生に AWS アカウントを準備し、受講者情報と紐づける [演習、運用編] それぞれの AWS アカウントに適切な権限を配布し、提供期間中管理/運用する [後片づけ編] 講義終了後に、適切にアカウントをクリーンアップする（本ブログ） 最初の [準備、構築編] では、講義で利用する AWS アカウントを作成し、申し込みがあった受講者のメールアドレスと紐づけるところを解説しました。 前回の [演習、運用編] では、受講生の使う AWS アカウントに対して権限の適用と管理方法について説明しました。今回は、環境の後片付けの実施方法とそこで得た知見について共有します。 環境の後片付け 講義終了後、環境の後片付けを実施しました。 まずは受講者の権限を外すために、IAM Identity Center にて、ユーザーの削除を aws identitystore delete-user コマンドにて行いました。これにより受講者は環境へのログインができなくなりました。 次に、演習用アカウントの後片付けを行います。後片付けとしては、提供したAWSアカウントを閉鎖するのがもっとも確実な方法ですが、AWS Organizations の制限として、「 30 日以内に閉鎖できるアカウントの数」が「組織内のメンバーアカウントの 10% 」となっており、すべてのアカウントを閉鎖するには何ヶ月もの時間が必要で現実的ではありません。加えて、今回の講座は今後も実施する予定があるため、再利用のためにアカウントは残しつつ、費用がかからないようにアカウント内の全てのリソースを削除する方式をとりました。リソースの全削除にはソリューションアーキテクトにご紹介頂いた aws-nuke という OSS を利用しました。aws-nuke はコマンド一つで対象のAWSアカウントに存在するリソースを全て削除することができる非常に強力なツールです。今回はこちらを利用して演習で利用したすべての子アカウントのリソースを全て削除し、次回以降も再利用可能な状態で保持しています。 aws-nuke実行の具体的手順 以降は aws-nuke を利用するために具体的に実施した手順となります。 作業ユーザーに各アカウントの Administrator 権限を付与する 全アカウントにアクセスするための .aws/config を作成する すべての削除対象のアカウントにアカウントエイリアスを設定する aws-nuke で使用する nuke-config.yaml を作成する SCP を修正し ec2:DescribeRegions を実行できるようにする aws-nuke を実行し、全ての演習アカウントの全てのリソースを削除する それぞれの手順についてより詳細に説明していきます。 1. 作業ユーザーに各アカウントの Administrator 権限を付与する 各アカウントで削除を行える権限として Administrator 権限を付与しました。IAM Identity Center のユーザーに対して、Administrator 権限を設定した許可セットを作成し、 aws sso-admin create-account-assignment コマンドにてすべての演習アカウントへの権限付与を実施しました。このとき、セッション時間も 12 時間などに長めに設定しておくと aws-nuke 実行時にセッションが切れず安心なので設定しておきましょう。 2. 全アカウントにアクセスするための .aws/config を作成する aws-nuke を利用するためには AWS Profile の指定が必要です。各アカウントの Profile をそれぞれ下記のように作成し、aws sso login を実施するのみで全アカウントにアクセスできるように設定しました。 [profile lecture-practical-ai-engineering-weblab-XXXX-admin] sso_session = lecture-ai-engineering-weblab sso_account_id = xxxxxxxxxxxx sso_role_name = AdministratorAccess region = us-east-1 output = json 3. すべての削除対象のアカウントにアカウントエイリアスを設定する aws-nuke を利用するためには対象のアカウントにアカウントエイリアスが設定されていることが必須要件となっていました。そこで、先ほど作成した Profileと aws iam create-account-alias コマンドを利用して、すべてのアカウントにエイリアスを設定しました。 4. aws-nuke で使用する nuke-config.yaml を作成する aws-nuke は実行時に config ファイルを必ず指定し、対象のアカウントが削除許可のものかどうか、削除対象のリソースは何かなどを確認した上で実行する仕組みになっています。今回は下記のように config を作成しています。 regions: - all blocklist: - "XXXXXXXXXXXX" # lecture-practical-ai-engineering-weblab presets: common: filters: IAMRole: - "OrganizationAccountAccessRole" IAMRolePolicyAttachment: - "OrganizationAccountAccessRole → AdministratorAccess" resource-types: includes: - APIGatewayAPIKeyLister - APIGatewayAPIKey ... accounts: XXXXXXXXXXXX: # 0000 presets: - common XXXXXXXXXXXX: # 0001 presets: - common ... bypass-alias-check-accounts: - XXXXXXXXXXX - XXXXXXXXXXX ... それぞれについてポイントを説明すると、 regions については今回 SCP 側で特に制限を設定しなかったので all を指定しています。削除の作業時間を考えると、次回以降は SCP にて region を制限し、対象を限定する形に改善を検討しています。 presets として、IAM Identity Center で作成される OrganizationAccountAccessRole と OrganizationAccountAccessRole → AdministratorAccess の PolicyAttachment を除外する設定を作成しています。これを除外しないと、IAM Identity Center 経由でのログイン等ができなくなってしまうので必ず filters で除外するようにしましょう。各アカウントの filters の設定を適用するために presets として定義し、各アカウント全てに反映されるように accounts の指定で presets: [common] を設定しています。 resource-types については数が多いので省略しますが、今回 SCP で除外したサービス以外の全てを含むように記載しました。 bypass-alias-check-accounts に全ての対象のアカウントを記載しています。これは aws-nuke の実行時に確認プロンプトを skip するための設定で、今回はスクリプトにて大量のアカウントに対する自動実行を行うために設定をしています。 5. SCP を修正し ec2:DescribeRegions を実行できるようにする aws-nuke 実行時に、 ec2:DescribeRegions の権限が必要なため ec2:* を全て拒否していた SCP を修正する必要がありました。 6. aws-nuke を実行し、全ての演習アカウントの全てのリソースを削除する いよいよ削除の実行ですが、単体のアカウントに対して実行する場合は下記のようになります。 $ ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-XXXX-admin --no-alias-check --no-prompt --no-dry-run ここで --no-alias-check --no-prompt --no-dry-run は確認なしで削除を実行するオプションとなるため、利用の際には十分に注意して実行する必要があります。aws-nuke には事故を起こさないためのいくつもの機能が備わっていますが、さらなる安全のため実行時の端末側の aws config は削除対象のアカウントのみしか設定されていない状態にして作業を実施しました。 実行時間ですが、削除リソースがない場合は大体 1 ~ 2 分、削除リソースがある場合は 5 ~ 7 分程度の時間が実績としてかかりました。 大規模並列実行 今回は大量のアカウントに対して aws-nuke を実行する必要があるため、ローカル環境内で並列実行することにしました。aws-nuke 自体は大きくリソースを使用するものではないので、筆者の MacBook Pro では 12 並列にしても大きな問題なく実行できました。もし大量に実施する際はご参考いただければと思います。 実際に使用したスクリプトはこちらになります。 #!/bin/bash START=0 END=1424 N_PARALLEL=12 # 並列数をここで指定 TOTAL=$((END - START + 1)) CHUNK_SIZE=$((TOTAL / N_PARALLEL)) for i in $(seq 0 $((N_PARALLEL - 1))); do RANGE_START=$((START + i * CHUNK_SIZE)) if [ "$i" -eq $((N_PARALLEL - 1)) ]; then RANGE_END=$END else RANGE_END=$((RANGE_START + CHUNK_SIZE - 1)) fi echo "並列処理 $((i+1)): ${RANGE_START} ~ ${RANGE_END}" ( for ACCOUNT_NO in $(seq $RANGE_START $RANGE_END); do ACCOUNT_NAME=$(printf "%04d\n" ${ACCOUNT_NO}) echo ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-${ACCOUNT_NAME}-admin --no-alias-check --no-prompt --no-dry-run # ▼処理を実行し、失敗したらログに記録 if ! time ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-${ACCOUNT_NAME}-admin --no-alias-check --no-prompt --no-dry-run; then echo "FAILED: ${ACCOUNT_NO}" >> "error_${i}.log" fi done ) > "output_${i}.log" 2>&1 & done wait echo "全ての並列処理が終了しました" 失敗パターンと対処法 上記実行後、2 つのパターンで削除が失敗したものがあるため、その対処についても記載しておきます。 AWS CloudFormation (Cfn) 実行用 Role が先に削除されてしまって Stack が削除できなくなりエラーとなる (ValidationError: Role arn:aws:iam::xxxxx:role/cdk-xxxxxxxxx-cfn-exec-role-xxxxxxxxxx-us-east-1 is invalid or cannot be assumed) → 手動で Role 作成して Stack を削除する必要がある 削除保護が有効なリソースがありエラーとなる (deletion protection is activated) → ユーザーが最終課題で作成したリソースに Amazon Cognito が設定されており、手動で解除する必要があった 以上の手順を踏むことで、全ての演習用アカウントから全てのリソースを削除することができました。削除後はコストエクスプローラにて、対象のアカウントで費用が発生していないことを持って最終確認としました。 次回以降の実施に向けて 今回は初回かつ短期間での準備であったため、コストやセキュリティ、構築時のリスクを低減できるようにシンプルかつ不確実性の低い構成を選択しました。結果として大きな問題なく短期間かつ低コストで環境を提供することができましたが、利用できるサービスを一部制限するなどの安全に倒した形での運用となりました。次回以降では、管理側の仕組み(コストアラート/自動停止等のガードレールの構築など)をより充実させることでサービス制限の緩和などに取り組みたいと考えています。 なお、本対応を実施後に AWS から Innovation Sandbox on AWS という一時的に利用するAWSアカウントを発行する仕組みのテンプレートが AWS solutions で公開されました。用意されたテンプレートを展開することで、AWSのサービスを組み合わせたソリューションを展開して特定の機能が利用ができる仕組みです。 Innovation Sandbox on AWS では、AWS アカウント管理者が一時利用 AWS アカウントの利用期間や金額条件等を設定し、利用者が申請して設定された条件の範囲ならばセルフサービスで AWS アカウントを一時利用できる仕組みを簡単に提供できるとのことです。このソリューションが我々の要件にマッチするかはまだ確認できていませんが、アカウントごとのコスト制限を設けられる点がとても魅力的なので、次回の実施の際はぜひ追加で検証してみたいと考えています。 まとめ 今回の東京大学松尾研究室でのデータサイエンス講座における AWS 環境を活用した大規模演習は、以下の点で大きな成果を上げました。 大規模クラウド環境の教育活用 1400 名もの参加者に対し、個別の AWS アカウントを提供することで、実践的なクラウド環境での学習機会を創出しました。従来の小規模・単発の講義とは異なり、多数の受講者が同時にクラウドリソースにアクセスできる環境を構築したことは、教育におけるクラウド活用の新たなモデルケースとなりました。 最新技術の実践的学習 サーバレスアーキテクチャを中心とした最新のクラウド技術と生成AIの組み合わせにより、次世代のアプリケーション開発手法を体験的に学習する機会を提供しました。特に、Amazon Bedrock を活用したチャットボット開発は、AI とクラウドの融合を実践的に理解する貴重な経験となりました。 大規模ユーザー管理の実践 IAM Identity Center と AWS Organizations を活用した大規模ユーザー管理の実践例を確立しました。この知見は、今後の同様の教育プログラムや大規模クラウド環境の管理に応用可能です。 セキュリティとコスト管理の両立 適切な権限設定とサーバレスアーキテクチャの採用により、セキュリティリスクとコスト管理を両立させることができました。特に、不要なサービスへのアクセス制限などの工夫は、教育環境におけるクラウド利用の重要なノウハウとなりました。 理論と実践の融合 講義と演習を組み合わせることで、クラウドとAIの理論的理解と実践的スキルの両方を習得できる学習体験を提供しました。リアルタイムとオンデマンドの両方の受講形態を用意したことで、多様な学習スタイルに対応できました。 今回の取り組みでは、従来の教室内での限定的な演習環境から脱却し、実際のクラウド環境で最新技術に触れる機会を提供することができました。このような理論と実践を融合させた学習体験が、受講者のスキル習得に大きく貢献し、将来の IT 人材育成に向けた重要なステップとなることを期待します。 今後の課題は、さらに多様なクラウドサービスを取り入れたカリキュラムの開発や、より効率的な環境構築・管理手法の確立が挙げられます。このような大規模クラウド環境を活用した教育プログラムは、次世代のAIエンジニア育成において重要な役割を果たせると考えられます。 松尾・岩澤研究室では、今回ご紹介したAIエンジニアリング実践講座だけでなく、様々な先進的な講座を開講しています。年間を通じて受講生を募集しており、2014 年から提供するAI講座の累計受講者数が 75,000 人を突破しました（2025年6月時点）。各講座はオンライン講義が中心なので、全国どこからでも参加可能です。大学生・大学院生だけでなく、中学生・高校生・高専生・専門学校生・短大生でも無料で参加できます。また、社会人の方が募集できる講座も用意しております。現在募集中の講座一覧は こちら となりますので、ぜひご確認ください。 執筆者 Hideaki Masuda 増田 英晃 東京大学大学院 工学系研究科 松尾・岩澤研究室 Saori Yagyu 柳生 さおり アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター教育事業本部 アカウントエグゼクティブ Naoya Funazashi 篙 直矢 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 ソリューションアーキテクト Kei Sasaki 佐々木 啓 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 シニアソリューションアーキテクト

2025 年 5 月 23 日に開催された「第20回情報危機管理コンテスト」決勝戦にて AWS 賞を受賞したチーム C01UMBA（コルンバ）の皆様にインタビューを行いました。 今回の情報危機管理コンテストでは、AWS 上に構築されたシステムを舞台として実践的なセキュリティインシデント対応が行われました。C01UMBA は名古屋工業大学の学生 4 名で構成された新人中心のチームでありながら、Amazon S3 や Amazon Athena を駆使し、優れたチームワークと的確な対応で AWS 賞を受賞しました。 C01UMBA の皆様から情報危機管理コンテストへの参加の経緯、研究室を選択したきっかけやコンテストへの準備など、これまでの活動についてお聞きすることができました。インタビュー記事を通してコンテストで得た学び、これからのクラウドやご自身のキャリアイメージなどをお伝え出来ればと思います。 (写真左から) C01UMBA 名古屋工業大学 情報工学科 齋藤・掛井研究室 情報工学科 学部 4 年 滝本 那奈 氏 情報工学科 学部 4 年 平山 洪 氏 情報工学科 学部 4 年 奥井 真二郎 氏 情報工学科 修士 1 年 東 政澄 氏（リーダー） コンテストに参加したきっかけ AWS : 今回の危機管理コンテストに参加するきっかけをお聞かせいただけますか。 滝本 : 研究室で代々参加しているコンテストだったので、その流れでというのと、自分自身もネットワークの知識が弱かったりしたので、勉強したいなという意識があったので参加しました。 平山 : 私も同じく、勉強の糧にしたかったというのと、実務経験もほとんどない状態でしたので、監視とか、ログの異常とか、どうやって見分けられるようになりたいかということも考えつつ参加しました。 奥井 : 研究室で出るっていうのもあって、それがきっかけではあるんですけど、学部 3 年の時に少しだけ就職活動したのですが「挑戦したこと」を聞かれた際、自分にはそのような経験が少ないことに気づきました。この気づきをきっかけに、技術的なことも含めていろいろ挑戦したいと考え、コンテストに参加しました。 東 : 昨年参加し、このコンテストから得られる学びとして大きいものがいろいろありました。もう一度参加する機会があったので、それなら最後に参加して、知識を深めたいなと思い参加しました。 研究室選びのきっかけ AWS : 所属している研究室がコンテスト参加の一つのきっかけとのことですが。研究室をどのように選んだかお聞きできますでしょうか。 滝本 : 研究室配属の時期が 10 月で、色んな研究室に行ったり悩んでたんですけど、ちょうどその時期に選んだ研究室の教授がやっているセキュリティ系の授業があって、それが面白かったので、ここにしようと思いました。 平山 : 研究室としてセキュリティをメインにやっているところっていうのがここの研究室しかなくて、講義で学ぶ上でいろいろなことを実務的にやれると感じたのと、侵入検知や、ブロックチェーンを含めた様々なセキュリティのことを経験することが他の研究室にはない特徴だったので、この研究室に入ろうとしました。 奥井 : 名古屋工業大学のセキュリティやってる研究室がここしかなくて、学部時代に応用情報とか資格試験に力を入れていて、応用情報は問題が選択出来るのですが、セキュリティだけは必須だったことから、セキュリティは重要だと思う様になり、それから興味を持ちました。 東 : 中学高校とセキュリティに興味があり、大学の学部を選んだ理由も、情報工学に行けばセキュリティを学べるからでした。ずっとセキュリティがやりたくて、ここに来たという感じです。セキュリティをやっていったら、社会に携われる、貢献できると思って選びました。 コンテストへの取り組み AWS : 研究室でのコンテストに対する取り組みを教えていただけますでしょうか。 東 : チーム編成の話からすると、去年私は同学年の他のメンバーと参加して、今回は後輩 3 人と参加という形です。このチームは、新人がどれだけの高みを目指せるかという、挑戦のチームという感じです。 平山 : もともと 4 人の学部 4 年生の人がいて、それを 2 人ずつで分けるか、それとも 3 と 1 で分けるかで考えていて。優勝を狙う為に、3 と 1 に分けて、上手いこと育成も含めて兼ねて、次に入った 学部 4 年生の育成がやりやすくなると考えて、結果的に今のチームの編成になりました。 AWS : コンテストでは「電話対応」というリーダーシップと技術的な判断をマルチタスクに求められる役割があると伺っています。今回、電話対応は東さんが担当されていましたが、役割分担は他のメンバーから見てどうでしたか。 平山 : 結構適切だったと思います。というのも二次予選で私が電話対応をしていましたが、結構パンクしてしまったので、それよりも規模が大きい決勝の状況になると、テンパっちゃって、何もできなくなってしまう可能性が高かったので、やはり、任せて正解だったと思います。 滝本 : 予選や二次予選の段階でもコマンドラインを覚えても使いきれない状況で、悩むことが多くあった。東さんに適切にポジション振り分けてもらい感謝しています。 東 : 今回のメンバーは文書作成、技術担当でそれぞれ強みがあることが分かったため、シングルタスクに持ち込めばいけると判断したため、決勝戦では僕が司令塔という立ち回りで進めました。 技術的な準備 AWS : 研究室のコンテストに対する取り組み、テクニカルな部分での対策したというエピソードはありますでしょうか。 滝本 : 研究室に代々受け継がれてるコマンドライン操作やコマンドをまとめたシートがあったり、あとは実際に攻撃して、それに対応するっていう環境が整えられてたりしていました。先輩方もその環境を使って、学部 4 年生の練習するのに結構な時間付き合ってくださっていました。 東 : 1 週間に 2 回やれればいいかもぐらいですね。合計で 4 回程度練習して本番に挑みました。 奥井 : 個人的に練習した後に課題と思ったのが、原因の特定です。絶対的な証拠を見つけることさえできれば、後は調べたりなんなりできる。チートシートに書いてあるコマンドの意味を理解することや、複数あるオプションの意味を調べたり、状況によってどんなコマンドを使うのかを調べて、勉強していました。 クラウドへの所感 AWS : 今回初参加の方は、初めてクラウドに触られたということでしたが。クラウドに感じる可能性があれば教えていただけないでしょうか。 平山 : S3 が今回題材に出されたというのもありますが、クラウドには様々なログが集積されて、データも大量に保存されているところが沢山あり、可能性という意味では、そういったログを全て確認できれば、インシデントが起きた時には楽になるとは感じました。 東 : 僕の中で S3 は倉庫のイメージがあって。S3 がログのストレージとして使われていますが、ログの中身を可視化して欲しい際に、他の AWS のサービスを利用することを考えて、これは良いと思い採用を検討したのが、Athena でした。 例えば、S3 が何でも出来るというのは良くないと思っていて。可視化をしようとした時に S3 を使った範囲内でちゃんと使いやすくしてる工夫が個人的には印象に残っていました。 奥井 : コンテストでは、(課題解決をする為に)その何かの機能を追加してくださいという問題だったんで、普通にオンプレミスでやってたら、簡単に機能を追加することは難しいのですが、クラウドでは気軽に機能を追加出来る。これはすごいと思っていました。ただ種類が多すぎて、時間内で自分たちだけで調べてというのには時間が掛かりました。 将来のキャリアイメージ AWS : 将来のキャリアイメージとして、将来やりたいことについて、お話をお聞きしたいと思います。 滝本 : 学部 3 年生の時に、学部で卒業しようと思っていました。本格的に就活をやってきたつもりだったんですけど、いろいろな企業を見ても、自分が何をやりたいか一番大事なところが全然見えてこなかった。そのような経験から大学院に進んで、もっといろいろなことを学んだり、今回のコンテストや大会に積極的に出て、視野を広げたい。専門性を磨きたいです。 平山 : 今はキャリアイメージは明確にないが、現在の研究室に配属になり、いろんなことをやりながら、まだ自分には経験というものが足りないという風に感じた。大学院に進んで、その後も資格を受けながら、色んな経験をこなしていくことによって、キャリアプランを探しています。 奥井 : 明確な目標としては、プロフェッショナルというか一つのことに誰にも負けない、自信を持って、自分にしか出来ないことを出来る人になりたいというのが、目標ではあります。 東 : いろいろな経験の中で二つ決まっていて、一つがセキュリティに関する仕事に携われること、もう一つが、人に携われること。今回の教える立場に立った中で、楽しいと思えたのが一つ、セキュリティに携わることも面白い。近い業種でいうと CSIRT かもしれない、顧客対応ができるキャリアを歩んでいけたら良いと思っている。技術的なところは大学の研究を通して学んでいければと考えている。人に携わるところはコミュニケーションを通じて伸ばしていければと考えています。 おわりに チーム C01UMBA の皆様、お忙しい中インタビューに快く対応いただきありがとうございました。 このブログは、2025 年 11 月時点の情報に基づいて ソリューションアーキテクト 深井 宣之 が執筆しました。

第 29 回サイバー犯罪に関する白浜シンポジウムにて開催された第 20 回情報危機管理コンテストに技術協賛として参加しました。   情報危機管理コンテストとは 情報危機管理コンテストは、2005 年から継続開催され、2025 年で 20 回を迎える歴史あるセキュリティコンテストです。 このコンテストでは、単なる技術力だけでなく、電話や電子メールによるリアルタイムな顧客対応の適切さが求められます。詳細な記載は省きますが、サーバへの外部侵入を含む多様な内容が含まれます。競技終了時に複数のトラブルへの対応状況を総合的に判断する仕組みとなっており、実際の対応を想定したシナリオが用意されています。限られた時間内での迅速かつ適切な判断力が要求され、個人の技術力だけでなく、チーム全体での連携と役割分担が重要な要素となっています。 参加チームが情報システム担当として、次々と発生するトラブル（システム障害や顧客・外部からの苦情など）に対して適切な対処を行い、問題解決能力を競うコンテストです。主に大学生・大学院生のチームが参加し、実践的なサイバーセキュリティ人材育成の場として業界から高く評価されています。 技術協賛 この度、AWS は技術協賛として参加し、シナリオ作成協力や参加者へのハンズオンの提供を行いました。また、決勝戦当日は AWS の問い合わせ窓口役として、現役のソリューションアーキテクト 2 名が現地で対応を行いました。   決勝戦 1 次・2 次予選を勝ち抜いた 8 チームが白浜シンポジウムの会場で決勝戦を行いました。 決勝戦の結果は公式サイトの 決勝戦について を参照ください。   AWS賞の授与 特に印象的なチームに対し AWS から AWS 賞を授与しています。本コンテストでは 名古屋工業大学 C01UMBA に授与しました。同チームは優れた技術力とチームワークを発揮し、決勝戦参加チームの中でも、特に実際の運用に近い発想を持っていました。   さいごに 第 20 回情報危機管理コンテストへの技術協賛参加を通じて、次世代のサイバーセキュリティ人材の成長を間近で見ることができました。参加チームの皆さんの真剣な取り組みと成長ぶりは非常に印象的で、日本の情報セキュリティ分野の未来に大きな希望を感じました。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター ソリューションアーキテクト 深井宣之 が執筆しました。

※ この投稿はお客様に寄稿いただいた記事です。 ANA システムズ 株式会社について ANA システムズ 株式会社は、エアライン分野に精通した「IT のスペシャリスト集団」として、エアラインビジネスを中心としたシステム企画・開発、空港施設・インフラ展開から稼働後のシステム運用、ANA グループ各社の DX 推進支援、地域創生への取り組みなど、幅広く品質の高いトータルサービスを提供しています。 1. はじめに プロジェクトチームには、様々な経験や背景を持つメンバーが集まります。当然、個々人のスキルセットは様々です。一方で、入社時の研修で学ぶ内容が、現場で求められる技術のすべてをカバーしているわけではありません。配属されて初めて触れるプログラミング言語やフレームワークに直面することも多いでしょう。加えて、プロジェクトには必ず「納期」が存在し、事前に十分な準備を行うための時間を確保することは難しいです。 本ブログでは、プログラミング経験の浅い担当者がある開発プロジェクトを「どのようにして短期間でやり遂げたのか」に焦点を当ててご紹介します。 2. 機能実装における課題 本システムのアーキテクチャは以下の通りとなっています。 図 1：アプリケーションのアーキテクチャ 機能実装にあたり、AWS Lambda における利用率が高く、各種ライブラリを扱うことから、開発言語として Python を選択しました。しかし、この選択には以下の 2 つの課題がありました。 担当者のスキルセット 実装の担当者は Python での開発経験がなく、コーディング経験自体も新人研修で Java に触れたのみという状況でした。そのため、扱う技術に対するスキルセットとの間に大きなギャップがありました。 素早い本番稼働が求めらている プロジェクトは、1 スプリントを 1 週間とするアジャイル形式で進められました。ユーザーから早期導入の大きな期待もあり、開発初期のわずかな遅れが、全体のスケジュール遅延やスコープ変更に影響する状況であったため、Python 未経験の担当者にとっては、期待に応えるために大きなプレッシャーもありました。 限られた開発期間の中で、スキルセットのギャップを埋める時間を確保するのは困難です。この状況を打開するため、不足する知識と技術を補う手段として、生成 AI をコーディングに活用することにしました。 3. 生成 AI を活用したコーディング手法 本開発におけるコーディングには、基盤モデルとして Anthropic の「Claude3 Haiku」を採用しました。実際に活用した内容を 2 つご紹介します。 対話形式のコーディング まず開発の起点となるコードの土台を得るために、システムのアーキテクチャと実現したい機能要件をプロンプトとして AI に入力しました。 図 2 : 生成 AI へのインプット 図 3 : 生成 AI からのアウトプット (抜粋) そして生成されたコードを基に、細部の実装を進めました。具体的には、「このコードをもっとシンプルに記述できますか？」といった改善点を AI に質問し、得られた回答を元に修正を重ねるという対話形式で、コード全体の完成度を高めていきました。 エラー内容の解析 エラー発生時の原因特定も、生成AIを活用して大幅に効率化しました。対象コードとエラーメッセージをAIに入力するだけで、問題の根本原因を特定することができました。実際に「AWS IAMの権限不足」のエラーが発生した際も、どこのどのような処理でエラーとなっているのかを解説してくれるため、必要な権限と設定箇所を早急に特定でき、迅速な問題解決につながりました。 4. 効果・利点 実際に生成 AI と共にコーディングを行う中で得られた、効果と利点をお伝えします。 未経験者の開発を強力にサポート まず最大の利点は、プログラミング経験の浅い担当者でも、短期間で実装を完遂できたことです。通常、未経験者が新しい言語で開発する際は「何から手をつければよいか」という最初のステップでつまずきがちです。しかし、生成 AI が開発の土台となるコードの雛形を提示してくれるため、この初動のハードルを大きく下げることができました。 また、従来はエラー内容の分析と調査に多くの時間が掛かっていました。このプロセスを AI に任せることで、問題解決の効率を大幅に向上させることができました。 それにより、未経験者でも 1 週間のスプリントでコーディングを行うことができました。 仕様変更やアーキテクチャ変更への柔軟な対応力 開発途中で発生した、アーキテクチャの変更を伴う緊急の改修作業においても、生成 AI の能力を感じられました。新しいアーキテクチャの構想を伝えるだけで、AI が変更に沿ったロジックを即座に提案してくれるため、急な仕様変更にも迅速かつ柔軟に対応することができました。 5. AI とのコーディングを通した自己成長 開発が始まったばかりの頃は、Python に関する知識や経験が全くなかったため、コーディングからデバッグに至るまで、開発プロセスのほぼすべてを AI に頼ってしまっていました。AI にコードの生成を依頼し、エラー発生時にはその解決策を AI に求めるという方法でしか開発を進めることができなかったのです。 しかし開発を進めていく中で、AI に何度も繰り返しコードレビューを依頼し、問題箇所の特定を繰り返すうちに、Python コードを読み解く能力が徐々に身につきました。徐々に AI との関わり方に変化が生じてきたのです。AI に全てを任せるのではなく、自身で問題の原因を検討したり、細かな修正を施したりするなど、プログラミングスキルを向上させることができました。それと同時に AI にはより具体的で詳細な指示ができるようになったことで、協働して解決策を見つけ出せるようになりました。AI がプログラミングの先生からパートナーへと変化したのです。 AI との連携はさらに効率的になり、コーディング速度だけでなく、エラー解決の効率も向上させることができました。結果として、緊急の改修作業が必要となった際にも、わずか 2 日半で Lambda コードのコーディングとテストを含めたシステムの改修を完了することができ、プロジェクトスケジュールへの影響を最小限に抑えられました。AI との関わり方、プログラミングスキル向上という2つの側面から自身の成長へとつなげることができました。 6. 成功のポイントと教訓 今回の開発を通じて、生成 AI を活用する上での重要なポイントと、今後の課題となる教訓が見えてきました。 やってみて分かった AI の能力を最大限に引き出す「対話力」の重要性 生成 AI は優れたコードを生成するものの、その回答を鵜呑みにするだけでは問題解決に至らない場面がありました。例えば、AI の回答から原因を絞り込めず、同じエラーについて何度も質問を繰り返すことがありました。また 1 機能としてコード自体は正しくても、他の機能と連携するための設定など、コード以外に起因する問題には気づくことができません。 この経験から、以下の2つの能力が重要だと分かりました。 読解・分析能力： AI の回答を元に、根本原因を自ら推測し、検証する力。 背景説明能力： 開発の背景やシステム構成、制約条件といった「コンテキスト」を正確に AI へ伝え、問題解決の精度を高める力。 改めて実感した AI 開発における「プロンプト設計」の重要性 本番リリース後、想定していたパフォーマンスが出ず、緊急の改修作業が発生するという事態がありました。原因は、開発環境と本番環境におけるデータ量の差異を考慮した設計・コーディングができていなかったことです。 このことから、AI はあくまで指示された範囲内で最適なコードを生成するものであり、実データ量のような非機能要件や環境特有の事情までは考慮できないという限界を学びました。 逆説的に言えば、もしプロンプトの段階で「本番環境では毎分〇〇件のデータが流れる」といった具体的な条件を細かく指定していれば、AI はより堅牢な設計を提案してくれたかもしれません。AI に「何を」「どこまで」考慮させるか、といった設計も開発者の重要なスキルであることが分かりました。 7. 結論 今回、私たちは「Python 未経験」「限られた開発期間」という状況の中で、生成 AI を活用することで、無事にスプリント内に機能をリリースすることができました。スキルや時間がない状況でも、新しい技術を駆使して「動くもの」を創り上げられたことは、大きな自信と学びにつながりました。 振り返ると、仕様書などのドキュメント作成や単体テストコードの自動生成など、AI を活用できそうな領域はコーディング以外にもあります。そういった作業は AI に任せ、エンジニアは顧客との要件調整といった創造性が必要な業務に注力することで、開発プロセスのさらなる効率化が図れるはずです。 また今回はプロジェクトの時期の都合上、Amazon Q Developer の利用が出来ませんでした。今年から日本語にも対応し始めたので、導入のハードルも大きく下がりました。今後のプロジェクトでは、より開発ライフサイクルに統合された AI アシスタントとして、その能力を検証していきたいと考えています。 執筆者 ANA システムズ株式会社 CXマネジメント部 カスタマーコミュニケーションチーム 中山 紗椰果 アジャイル開発エンジニア ANA システムズ株式会社 CXマネジメント部 カスタマーコミュニケーションチーム 都留 昌彦 アジャイル開発エンジニア、PMI PMP(R) 会社情報 会社名 : ANA システムズ 株式会社 URL : https://www.anasystems.co.jp/

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 ついに 12 月 1 日から 5 日で re:Invent 2025 が開催されます。私もデモ展示員として、現地ラスベガスに行く予定なので、ぜひ現地に行かれる方は Builders Fair で展示している私のブースにお越しください。そのブースでは、生成 AI を活用したロボットの自動走行デモを今絶賛開発中で、間に合わせるために必死に頑張っています。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年11月10日週の主要なアップデート 11/10(月) Amazon SageMaker Unified Studio がカタログ通知のサポートを追加 Amazon SageMaker Unified Studio でデータカタログの通知機能が利用できるようになりました。データセットの公開や更新、アクセス承認などの重要な変更をリアルタイムで受け取れます。プロジェクトホームページの「ベル」アイコンから通知を確認でき、通知センターでは全ての通知を一覧表示して必要に応じてフィルタリングも可能です。データチーム間のコラボレーションがスムーズになり、重要な更新を見逃すリスクが大幅に減ります。詳細は こちらのドキュメントをご参照ください。 AWS Control Tower がアカウントの自動登録をサポート AWS Control Tower で、アカウントを組織単位 (OU) に移動するだけで自動的にガバナンス管理下に登録できる機能が追加されました。従来は手動でのアカウント更新や OU の再登録が必要でしたが、この機能により大幅に簡素化されます。アカウント作成後に適切な OU に移動するだけで、ベストプラクティス設定やコントロールが自動適用されるため、管理者の運用負荷が軽減されます。 MSK Express ブローカーが追加コストなしでインテリジェントリバランシングをサポート、アクション不要 Amazon MSK の Express brokers で インテリジェントリバランシング が無料提供開始しました。Kafka クラスターのスケーリング時に自動でパーティションバランシングを実行し、Standard brokers と比較して最大 180 倍高速に処理できます。これまで手動や外部ツールで管理していたパーティション操作が不要になり、クラスター性能を最大化できます。新規 MSK Provisioned clusters では追加設定なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 11/11(火) Amazon EC2 M8a インスタンスが追加リージョンで利用可能に Amazon EC2 M8a インスタンスがバージニア北部と東京リージョンで利用開始されました。AMD の第 5 世代 EPYC プロセッサを搭載し、従来の M7a と比較して最大 30 % のパフォーマンス向上と 19 % の価格性能比改善を実現しています。メモリ帯域幅も 45 % 向上したため、レイテンシが重要なアプリケーションでも快適に動作します。金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバーなどの高性能を必要とするワークロードに最適で、12 種類のサイズから選択可能です。 Mountpoint for Amazon S3 が Amazon Linux 2023 に含まれるようになりました Amazon Linux 2023 で Mountpoint for Amazon S3 が標準提供開始されました。これまで GitHub からパッケージをダウンロードして手動インストールする必要がありましたが、今後は1つのコマンドで簡単にインストール・アップデートが可能です。S3 バケットをローカルファイルシステムのようにマウントできるため、既存のアプリケーションを変更せずに S3 のデータにアクセスできます。サーバー上でのデータ処理やバックアップ作業が大幅に効率化されるでしょう。 Amazon CloudWatch Composite Alarms にしきい値ベースのアラート機能を追加 Amazon CloudWatch Composite Alarms で、しきい値ベースのアラート機能が追加されました。従来は個々のアラームごとに通知を受け取っていましたが、今回のアップデートで複数のリソースのうち一定数に問題が発生した場合にのみ通知を受け取れるようになりました。例えば 4 つのストレージボリュームのうち最低 2 つで容量不足が発生した場合や、クラスター内の 50 % のホストで CPU 使用率が高くなった場合に通知するといった柔軟な設定が可能です。これにより軽微な問題による不要なアラートを削減し、本当に重要な問題に集中できます。詳細は こちらのドキュメントをご参照ください。 11/12(水) Amazon EC2 F2 インスタンスが 4 つの追加 AWS リージョンで一般提供開始 Amazon EC2 F2 インスタンスが新たにフランクフルト、東京、ソウル、カナダ中部の 4 リージョンで利用開始となりました。F2 インスタンスは FPGA 搭載の第二世代で、従来の F1 インスタンスと比較して 3 倍の vCPU、2 倍のメモリを提供します。遺伝学研究やマルチメディア処理、ビッグデータ解析などの高速計算処理が必要な用途で威力を発揮します。これにより計 8 リージョンでの利用が可能となり、より多くの地域で FPGA の高性能を活用できるようになりました。 AWS Builder Center で Spaces が利用可能になりました AWS Builder Center に Spaces という新しいコミュニティ機能が登場しました。AWS に関する特定のトピックやユースケースについて、他のエンジニアとグループを作成して情報交換できるツールです。Public、Private、招待制の 3 つのスペースタイプから選択でき、投稿やコメント、検索機能を通じて知識共有や課題解決の議論が可能になります。AWS の学習で困った時に仲間を見つけたり、ベストプラクティスを共有したりする場として活用できそうです。 セキュリティインシデント対応のコミュニケーション設定の発表 AWS Security Incident Response で通知設定のカスタマイズ機能が追加されました。これまでは全メンバーが全ての通知を受信していましたが、今回のアップデートで役割に応じて必要な通知のみを選択できるようになりました。例えば管理者はケース変更通知を、一般メンバーは組織のお知らせのみを受け取るといった設定が可能です。不要な通知が減ることで重要な情報に集中でき、作業効率が向上します。追加費用なしで Security Incident Response コンソールから簡単に設定できます。 11/13(木) Amazon Kinesis Video Streams WebRTC マルチビューワー が一般提供開始 Amazon Kinesis Video Streams で WebRTC Multi-Viewer 機能が提供開始されました。これまで 1 対 1 だったリアルタイム動画配信が、最大 3 人の同時視聴者に対応しました。デバイスの負荷を増やすことなく、セキュリティカメラや IoT デバイスからの映像を複数人で共有でき、音声会話も可能です。家庭のセキュリティシステムでの家族間共有や、リモート監視システムでの複数オペレーター対応など、幅広い用途で活用できます。詳細は こちらのガイドをご参照ください。 Amazon Connect がマネージャーによるエージェントパフォーマンス評価の完了に関するメトリクスを提供開始 Amazon Connect でエージェントのパフォーマンス評価完了状況を測定するメトリクスが新たに提供開始されました。マネージャーは「月 5 回の評価」などの社内ポリシーや規制要件への準拠状況をリアルタイムで監視できるようになります。さらに、異なるマネージャー間の評価スコアパターンを分析することで、評価の一貫性と精度の向上も図れます。詳細は こちらのドキュメントをご参照ください。 AWS IoT Core が Amazon Sidewalk 対応デバイス向けの位置解決機能を追加 AWS IoT Core Device Location が Amazon Sidewalk デバイスの位置解決機能を追加しました。従来は GPS ハードウェアが必要でしたが、WiFi アクセスポイントや Bluetooth Low Energy データを活用して低電力デバイスの位置を特定できるようになります。これによりアセット追跡やジオフェンシングアプリケーションをより効率的に構築可能です。Amazon Sidewalk は Echo や Ring デバイスを通じた安全なコミュニティネットワークで、IoT デバイスにクラウド接続を提供します。バージニア北部リージョンで利用開始され、米国内でのみ Amazon Sidewalk ネットワークが使用できます。詳細は こちらのドキュメントをご参照ください。 11/14(金) AWS Lambda が Rust のサポートを追加 AWS Lambda で Rust が正式サポートされました。これまで実験的な扱いだった Rust が、本格的な本番環境での利用が可能になります。Rust は高性能でメモリ効率が良く、コンパイル時の安全性チェックが特徴的な言語です。パフォーマンスを重視するサーバーレスアプリケーションの開発に最適で、従来の言語では難しかった高速処理が求められるワークロードでも安心して利用できます。詳細は こちらの Blog 記事をご参照ください。 Amazon SageMaker Catalog が Amazon S3 への読み取りおよび書き込みアクセスをサポート Amazon SageMaker Catalog が Amazon S3 への読み書きアクセスに対応しました。これまでデータの検索や共有に制限がありましたが、今回のアップデートでデータサイエンティストが非構造化データを簡単に検索し、構造化データと組み合わせて処理できるようになりました。処理結果を S3 に保存して他チームと自動共有することも可能です。データ提供者は読み取り専用または読み書き両方のアクセス権限を選択でき、セキュリティを保ちながら効率的なデータ分析が実現できます。詳細は こちらのドキュメントをご参照ください。 AWS IoT サービスが VPC エンドポイントと IPv6 接続のサポートを拡張 AWS IoT Core、AWS IoT Device Management、AWS IoT Device Defender で VPC エンドポイントと IPv6 サポートが拡張されました。AWS PrivateLink を使って VPC エンドポイントを設定することで、IoT デバイスからの通信がパブリックインターネットを経由せずプライベートネットワーク内で完結できるようになり、セキュリティが大幅に向上します。また IPv6 サポートにより既存の IPv4 環境と併用しながら最新のネットワーク要件にも対応可能です。詳細は こちらのドキュメントをご参照ください。 実は今週末、趣味でやっているパデルのシニア日本代表を決める試合があり、出場予定です。reInvent の準備も忙しいのですが、体づくりもしっかりして万全の状態で今月乗り切りたいです。よい結果になることを期待してください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料業界やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本投稿は、2025年 9 月 30 日に公開された Building your operations management with AI-Powered Operations at re:Invent 2025 を翻訳したものです。 組織がクラウド環境を拡大し進化させ続ける中、効果的な運用管理はこれまで以上に重要になっています。AWS re:Invent 2025 の Cloud Operations トラックにおける運用管理セッションは、AWS 環境全体で回復力があり、セキュアで効率的な運用プラクティスを構築するのに役立つ包括的なラインナップを提供します。複雑なマルチクラウド環境の管理、AI を活用した自動化の実装、災害復旧戦略の強化など、このトラックはあらゆる方々にコンテンツを提供します。 このブログでは、運用管理における主要テーマを紹介し、クラウド運用戦略を変革するのに役立つセッションを紹介します。 運用管理トラックの参加を計画しよう re:Invent 2025 の Cloud Operations トラックにおける運用管理は、インテリジェントな自動化によってクラウド運用を簡素化するという AWS の取り組みを示しています。シングルクラウド環境を管理する場合でも複雑なマルチクラウドインフラを管理する場合でも、これらのセッションは運用効率、セキュリティ、信頼性を向上させるための実践的な戦略を提供します。 5 つの主要テーマにわたる 12 のセッションがあり、ハンズオンワークショップから専門家レベルのディスカッションまで、あらゆる人にコンテンツを提供します。re:Invent での体験を最高のものにするために、以下をおすすめします： 優先事項に焦点を当てる：組織が直面している運用上の課題に合ったセッションを選択する 形式を組み合わせる：講義形式のセッションとインタラクティブなワークショップやビルダーズセッションを組み合わせる スキル向上を図る：現在のスキルレベルに合ったセッションと、能力を伸ばすセッションを選択する 早めに予約する：人気のあるセッションはすぐに埋まるため、登録が開始されたらすぐに予約する re:Invent における運用管理の主要テーマ 運用管理セッションは、いま最も差し迫った運用上の課題に対応する 5 つの中核テーマを中心に構成されています： 1. AI を活用した運用 クラウド運用に生成 AI と機械学習を統合することは、組織のインフラ管理における最も変革的な変化の一つです。このテーマのセッションでは、Amazon Bedrock、Amazon Q、AWS Systems Manager などのサービスを活用して、自動監視から予知保全まで、インテリジェントな運用ワークフローの作成方法を紹介します。 2. 回復力と災害復旧 障害に耐えられる回復力のあるシステムを構築すること、ビジネスの継続に欠かせません。運用管理トラックでは、AWS Resilience Hub と生成 AI を組み合わせて、高度な災害復旧プレイブックを作成し、回復力テストを実施し、自動化された復旧手順を実装する方法を紹介します。 3. マルチクラウド管理 組織が複数のクラウドプロバイダーを採用するにつれて、多様な環境を管理する複雑さが指数関数的に増加します。AWS、オンプレミス、または他のクラウドプロバイダーにかかわらず、クラウド全体の一元的な可視化と制御を可能にするツールやサービスを AWS がどのように提供しているかを学びましょう。 4. 大規模な自動化 手動の運用では現代のクラウド環境の規模と複雑さに追いつくことができません。運用管理トラックでは、パッチ管理からセキュリティインシデント対応まで、クラウド運用全体に自動化を実装するための実践的なガイダンスを提供します。 5. コンプライアンスとセキュリティ セキュリティとコンプライアンスは、あらゆる規模の組織にとって最優先事項です。自動化されたセキュリティコントロールを実装し、コンプライアンスプロセスを合理化し、ビジネスとともに拡張するガバナンスフレームワークを構築する方法を見つけましょう。 あなたの学習スタイルに合わせたセッション形式 re:Invent では、さまざまな学習スタイルに対応するセッション形式を提供しています。テーマ別に必見のセッションをいくつか紹介します： AI を活用した運用 COP322 | Building AI-Powered operational insights and automated remediation | Builders’ session (AI を活用した運用インサイトと自動修復の構築 | ビルダーズセッション) 場所： 12 月 3 日（水）午後 1:30 ～ 2:30 PST | Mandalay Bay このセッションでは、Amazon Q、Amazon OpenSearch Service、AWS Systems Manager を組み合わせて、高度な運用インサイトと自動修復を提供する AI 駆動のソリューションを構築します。MCP Server を介して Amazon Q を操作し、クエリを構築し、運用データと AI 統合を実装します。OpenSearch が効率的にデータを取り込めるよう ETL と AmazonS3 を用いて構築し、ニアリアルタイムの異常検出を可能にする方法を学びます。 COP314 | Scale & automate patching with AI-powered visualization | Workshop (AI を活用した可視化によるパッチ適用のスケールと自動化 | ワークショップ) 場所： 12 月 4 日（木）午後 12:30 ～ 2:30 PST | MGM このハンズオンワークショップでは、AWS Systems Manager と Amazon Q を使用してパッチ管理を合理化する方法を理解します。自動化されたパッチ適用ソリューションの展開、コンプライアンスレポートの構成、Amazon Q を使用した自然言語クエリによる動的な可視化を簡単に作成する方法を学びます。 COP407 | Building custom agents for intelligent AWS patch automation | Code Talk (インテリジェントな AWS パッチ自動化のためのカスタムエージェントの構築 | コードトーク) 場所： 12 月 3 日（水）午前 11:30 ～ 午後 12:30 PST | Wynn この専門家レベルのコードトークでは、Strands Agents SDK と AWS サービスを使用してエージェントソリューションを構築し、パッチ管理を変革します。パッチを承認する前にコンプライアンス要件を検証するポリシーエンジンを実装し、手動作業を削減するスケーラブルなガバナンスフレームワークを作成する方法をご紹介します。運用要件をインタラクティブで本番環境対応のエージェントワークフローに変換し、自動修復と迅速な脆弱性チェックを推進する方法を説明します。 回復力と災害復旧 COP303 | Automate disaster recovery playbooks using generative AI | Builders’ Session (生成 AI を使用した災害復旧プレイブックの自動化 | ビルダーズセッション) 場所： 12 月 4 日（木）午前 11:00 ～ 午後 12:00 PST | Wynn Amazon Q Developer、AWS Resilience Hub、AWS Systems Manager を使用した自動化された災害復旧計画により、ミッションクリティカルなワークロードを強化する方法を理解します。このセッションでは、復旧ランブックを生成して検証するための実践的なテクニックを紹介します。包括的なテスト機能を備えた、アーキテクチャを意識した復旧計画を生成する効果的なプロンプトの作成方法を学びます。自動化による災害復旧戦略のモダナイズに関するインサイトを得て、リスクを軽減し、運用の回復力を向上させるのに役立ちます。 COP420 | AI-powered resilience testing and disaster recovery | Breakout Session (AI を活用した回復力テストと災害復旧 | ブレイクアウトセッション) 場所： 12 月 2 日（火）午後 1:30 ～ 2:30 PST | Wynn この専門家レベルのブレイクアウトセッションでは、AI を活用した AWS での回復力と災害復旧を強化する方法を理解します。このアプローチはインフラについての洞察とアプリケーションレベルのテストを橋渡しし、より効果的な災害復旧準備を可能にします。大規模言語モデル (LLM) を AWS Resilience Hub、AWS Systems Manager と組み合わせてテストをモダナイズし、インフラを分析し、ターゲットを絞った AWS Fault Injection Service の実験と復旧ランブックを生成する方法を学びます。 マルチクラウド管理 COP313 | Multicloud & hybrid node operation at scale is easier than you think | Chalk Talk (マルチクラウドとハイブリッドノードの大規模運用は思ったより簡単 | チョークトーク) 場所： 12 月 1 日（月）午前 10:30 ～ 11:30 PST | Mandalay Bay このチョークトークでは、大規模な運用を効率化する実践的なソリューションをご紹介します。AWS Systems Manager、Amazon CloudWatch、その他のサービスが、パッチ適用、アプリケーションデプロイ、インシデント解決、アクセス制御管理など、フリート全体の運用をいかに効率的に処理できるかを探ります。これらのサービスは、分散コンピューティング環境全体で数千の顧客が数百万のリソースを運用するのを支援し、セキュリティとコンプライアンスを維持しながら運用のオーバーヘッドを削減します。 COP342 | Centralize Multicloud Management using AWS | Breakout Session (AWS を使用したマルチクラウド管理の一元化 | ブレイクアウトセッション) 場所： 12 月 4 日（木）午前 11:30 ～ 午後 12:30 PST | MGM このブレイクアウトセッションでは、マルチクラウド環境での運用が運用の複雑さをもたらす可能性があることを解説します。このセッションでは、すべての環境でのインスタンス管理を容易にする AWS Systems Manager を使用して運用を合理化する方法を学びます。Amazon CloudWatch と Amazon Managed Grafana を使用したパフォーマンスの洞察を得て、あらゆるデータソースからのメトリクスとログの統合ダッシュボードを提供します。これらのサービスを使用することで、ワークロードが AWS、オンプレミス、または複数のクラウドにまたがっていても、日常的なタスクを簡素化し、制御を維持し、リソースを最適化できます。マルチクラウドの複雑さを排除し、本当に重要なことである「ビジネスの運営」に集中しましょう。 大規模な自動化 COP340 | Building reliable operations, feat. Fannie Mae | Breakout Session (信頼性の高い運用の構築、Fannie Mae の事例 | ブレイクアウトセッション) 場所： 12 月 2 日（火）午後 5:30 ～ 午後 6:30 PST | Caesars Forum このブレイクアウトセッションでは、Fannie Mae の実際のケーススタディを紹介します。Fannie Mae が AWS 上にクロスリージョンの可観測性プラットフォームを構築して運用を変革し、ハイブリッド環境全体でインシデント対応を自動化し、信頼性を向上させた方法を紹介します。自動化されたインシデント管理の実装、効果的なオンコールプロセスの確立、および組織内の運用信頼性を向上させるための AWS サービスの活用に関する実践的な戦略を持ち帰りましょう。 COP344 | Implementing Automated Security Controls for Zero-Day Defense | Chalk Talk (ゼロデイ防御のための自動化されたセキュリティ統制の実装 | チョークトーク) 場所： 12 月 3 日（水）午後 1:30 ～ 午後 2:30 PST | MGM このチョークトークでは、Amazon Inspector、AWS Systems Manager、および AWS Security Hub を使用して、脆弱性管理と自動化されたリスク統制を組み合わせてセキュリティ体制を強化する方法を紹介します。インフラストラクチャとポリシーのコード化によってコンプライアンス監視と継続的な統制の検証の実装を自動化し、 Amazon EC2 インスタンスと AWS リージョン全体でゼロデイ脆弱性に対する効果的な対応戦略を実証します。 COP343 | Streamline operations with automated health monitoring and response | Chalk Talk (自動化された健全性監視と対応による運用の合理化 | チョークトーク) 場所： 12 月 3 日（水）正午 ～ 午後 1:00 PST | Mandalay Bay このチョークトークでは、AWS Health、Amazon CloudWatch、および AWS CloudTrail を使用して、包括的な健全性監視と自動化されたインシデント対応を実装する方法を紹介します。効果的な監視パターンの作成、メトリクスをアクションに変換する方法、および自動修復ワークフローの実装方法を学びます。 コンプライアンスとセキュリティ COP310 | Automating compliance and auditing at scale | Workshop (大規模なコンプライアンスと監査の自動化 | ワークショップ) 場所： 12 月 3 日（水）午前 9:00 ～ 午前 11:00 PST | Mandalay Bay このワークショップでは、AWS Config、Systems Manager、および Audit Manager を使用して自動化されたコンプライアンス統制を構築する方法を紹介します。インテリジェントな調査のために Amazon Q CLI と CloudTrail Lake を活用して自動化されたセキュリティ評価と修復ワークフローを実装する方法を学びます。 COP341 | Implement secure automated workflows with AWS Systems Manager | Chalk Talk (AWS Systems Manager による安全な自動化ワークフローの実装 | チョークトーク) 場所： 12 月 1 日（月）午前 11:30 ～ 午後 12:30 PST | MGM このチョークトークでは、AWS Health、Amazon CloudWatch、および AWS CloudTrail を使用して包括的な健全性監視と自動化されたインシデント対応を構築する方法を学びます。修復のための Systems Manager Automation の実装、効果的な監視パターンの作成、およびメトリクスをアクションに変換するハンズオンを体験しましょう。 将来を見据えて AWS re:Invent 2025 の Cloud Operations トラックにおける運用管理セッションでは、最新の AWS サービスとベストプラクティスを使用して組織が運用プラクティスを変革する方法について包括的に見ることができます。AI を活用した自動化からマルチクラウド管理まで、このトラックのセッションは、回復力があり安全で効率的なクラウド運用を実現するために必要な知識とスキルを提供します。 re:Invent 2025 でお会いできることを楽しみにします。Venetian の AWS Cloud Operations ブースにもお立ち寄りください！ まだ登録していませんか？　まだ間に合います！　 re:Invent ポータルから登録してください。 Samir Behara Samir Behara は AWS プロフェッショナルサービス部門のシニアクラウドインフラストラクチャアーキテクトです。クラウド導入戦略を通じて顧客の IT 近代化を加速させることに情熱を注いでいます。豊富なソフトウェアエンジニアリングの経験を持ち、アプリケーションアーキテクチャや開発プロセスに深く掘り下げ、パフォーマンス向上、運用効率化、イノベーションの加速を推進することを得意としています。 翻訳はソリューションアーキテクトの吉田幸泰が担当しました。原文は こちら です。

こんにちは、ソリューションアーキテクトのいなりくです。 ついに来ました、 Kiro 一般提供開始 ！ このタイミングに合わせて、日本のお客様に向けた特別企画として、11 月 18 日（火）から 11 月 28 日（金）まで、AWS JP Blog 連載イベント「Kiroweeeeeeek in Japan」を開催します！Week と言いながら 1 週間限定じゃないんか！というツッコミは禁止です。その代わり、e は一週間にちなんで 7 つにしています。 AWS Japan 社員が、日本の開発現場の皆さまに、生成 AI／エージェント時代における “仕様駆動から実装・運用までの道筋” を、日本語で丁寧にお届けします。 Kiro が一般提供開始！＆ Kiro CLI 公開のご案内 7 月に Kiro がプレビュー版としてローンチ してから約 4 ヶ月が経ちました。日本のお客様からは「まだプレビューなのですか？」と何回も質問をいただいていました。そして晴れて、 11 月 18 日より、Kiro が一般提供開始されます 。同時に、 Kiro CLI が公開され 、CLI ベースでのワークフロー支援もスタートします。 この 2 つを契機に、Kiro は “エージェント支援開発” を次のフェーズへと押し上げるツールとなります。AWS Japan チームとして、日本のお客様がいち早くこの新しい開発パラダイムを活用できるよう、実践的な情報をお届けいたします。 イベント概要 期間： 2025 年 11 月 18 日（火）〜11 月 28 日（金）平日のみ（8 回） 連載の特徴：この連載は、日本のお客様から実際にいただいたご質問やご相談を中心に構成いたします。Kiro の導入背景から CLI を含む新ワークフローの解説、仕様駆動開発とエージェント設計の実践、プロパティベーステストによる品質保証、カスタムエージェントを活用した専門特化開発、チーム開発での Kiro 戦略、そして日本のお客様の様々な業界・現場での活用事例まで、実際のニーズに基づいた内容で幅広くカバーします。基本は 1 日1 本の公開を予定しておりますが、日本のお客様から質問が多い場合は、記事の本数が増えるかもしれません。いわゆる元気玉方式 (?) です。また、X（旧Twitter）で #kiroweeeeeeek を付けて投稿された読者の質問・悩みを可能な限り記事で取りあげさせていただきます。また、連載記事をこのブログから一覧できるよう、各回リンク・目次機能を設けます。 今すぐできること 事前に Kiro の公式サイト をご覧になり、概要を掴んでおいてください。”自分たちならこう使う” という視点で、Kiro の可能性を少しだけでも考えてみてください。X で #kiroweeeeeeek をつけて様々な角度からの投稿をお待ちしています！ Kiro に関する質問・悩み・感想 現在の開発フローでの課題や成功事例 AI 開発支援ツールへの期待や懸念点 チーム開発での AI 活用アイデア 業界固有の開発課題 連載で取り上げてほしい具体的なトピック Kiro を試してみた感想やレビュー どんな業界・規模・開発スタイルのお客様からの投稿も大歓迎です。 それでは、11 月 18 日（火）からの連載を通じて、日本のお客様の実際のご質問にお答えしながら、Kiro を使った仕様駆動開発の知見を日本のお客様とともに深めていきましょう！ 皆さまのご参加・ご反響を心よりお待ちしています！ 著者 稲田 大陸 – いなりく AWS Japan で働く筋トレが趣味のソリューションアーキテクト。2022 年から三菱電機グループをご支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

深夜 2 時、本番サーバーに接続してバグをデバッグしています。この一週間、IDEでAIエージェントを使って効率よく開発を進めてきたあなたなら、こんな時こそAIの力を借りたいと思うでしょう。しかし、コンテキストを切り替えるとすると、ターミナルセッションが切れ、SSH 接続も失われ、作業の流れが途切れてしまいます。結局、手動でログを確認し、構文を検索して、一人で格闘することになります。AI が使える IDE で作業するか、実用的だけれど AI サポートのないターミナルで作業するか。本来なら、こんな選択を迫られる必要はないはずです。 今回、私たちはそのギャップを解決しました。Kiro CLI なら、AI エージェントを直接ターミナルで使えます。同じエージェント、同じ機能を、どこでコーディングしていても利用できます。 Kiro CLIとは？ Kiro CLI は Amazon Q Developer CLI の高度なエージェント機能（エージェントモード、MCP、ステアリング、カスタムエージェントを含む）をベースに、ソーシャルログイン、Haiku 4.5、そしてパフォーマンス、効率性、出力品質のバランスを自動調整する Auto エージェントを追加したツールです。プロジェクトの構築、本番環境の問題のデバッグ、インフラコードの作成など、すべてシェルを離れることなく行えます。必要なことを自然言語で説明するだけです。 この強力さの秘密は専門化にあります。あなたのコードベースに合わせたカスタムエージェントを作成できます。API パターンを熟知するバックエンドスペシャリスト、コンポーネントに精通したフロントエンドエキスパート、インフラを理解する DevOps エージェントなどです。各エージェントは、担当するワークフローに関連する情報にコンテキストウィンドウを集中させます。 すでに Kiro IDE を使用していますか？あなたの .kiro フォルダ設定は両方の環境で動作します。Kiro CLI は同じステアリングファイル（プロジェクト全体で AI の動作を制御するルール）と同じ MCP サーバーを利用できます。一度設定すれば、どこでも使えます。 なぜ Kiro CLI？ ターミナルから離れる必要がありません – コンテキストを切り替えたり構文を調べたりする手間が省けます AI ワークフローを体系化 – カスタムエージェントで異なるタスクに最適化された環境を瞬時に切り替えられます 一度の設定で両環境に対応 – MCP サーバーや設定ルール、プロジェクトドキュメントがKiro IDEとKiro CLI両方で使えます 実際の作業スタイルに対応 – インフラ管理、コードレビュー、デバッグなど、特定のワークフロー用エージェントを作成・共有できます 高速な自動化を実現 – コードフォーマット、テスト実行、ログ管理などを自動化されたシェルコマンドで処理できます 始め方 インストール Kiro CLI は macOS と Linux で利用可能です。 インストール は簡単です。 curl -fsSL https://cli.kiro.dev/install | bash 最初のステップ 1. 認証：あなたの資格情報でサインイン kiro-cli 2. コマンドを探索：いつでもヘルプを取得 /help 主要機能 1. カスタムエージェント：ターミナルでのAIコーディングの構造化 カスタムエージェントは、AI が異なるタスクに対してどのように動作すべきかを正確に定義できるようにすることで、AIを活用したターミナルワークフローに構造をもたらします。 事前承認されたツール – 毎回許可を求めることなく、信頼できるツールを自動実行できます 永続的なコンテキスト – プロジェクトファイルやドキュメント、標準設定を自動的に読み込みます アクセス制御 – 利用可能なツールを制限して、焦点を絞り、安全を確保します ワークフロー固有の設定 – 用途に応じた異なるエージェント：AWS オペレーション用、コードレビュー用、デバッグセッション用など エージェント設定の例： { "name": "backend-specialist", "description": "Expert in building Express.js APIs with MongoDB", "prompt": "You are a backend developer specializing in Node.js and Express. You write secure, well-tested APIs with proper error handling, input validation, and RESTful design.", "tools": ["fs_read", "fs_write", "execute_bash"], "toolsSettings": { "fs_write": { "allowedPaths": ["src/api/**", "tests/api/**", "server.js", "package.json"] } }, "resources": [ "file://.kiro/steering/backend-standards.md“ ] } この構造化されたアプローチにより、プロジェクト設定を常にコンテキスト切り替えしたり再説明したりする必要がなくなります。AI は必要なことを把握しており、あなたは作業の流れを維持できます。 この例のエージェントは、バックエンド開発に特化したスペシャリストです。フロントエンドや DevOps など無関係なトピックに時間や精神的エネルギーを費やすことがありません。ファイルパスの制限により、バックエンドファイル（ src/api/** や server.js など）のみを扱うことができ、フロントエンドや設定ファイルを誤って破損することを防ぎます。バックエンド標準の md ファイルを自動的に読み込むため、async/await、エラー処理、API 設計に関するチームのルールを毎回思い出させる必要がありません。結果として、エージェントが無関係な情報に惑わされることがないため、より速く、より正確で、一貫して標準に従った回答が得られます。 個々のツール制限を超えて、Kiro CLI はさらに柔軟性を高めるための幅広い許可パターンもサポートしています。 @builtin ネームスペースを使用することで、すべての組み込みツールを一度に事前承認するか、正確な制御のために個々のツールを指定するなどきめ細かいツール許可を行うことができます。 { "allowedTools": ["@builtin", "my_custom_tool"] } 2. ビジュアルインジケータによるスマートなコンテキスト管理 Kiro CLI は 3 つの柔軟なアプローチでコンテキストを提供します。 エージェントリソース ：重要なプロジェクトファイル用のセッション間で永続的なコンテキスト セッションコンテキスト ：クイック実験用の一時ファイル ナレッジベース ：コンテキストウィンドウのスペースを消費せずに大規模なコードベース（PDF もサポート！）のセマンティック検索 コンテキスト使用率 ：kiro-cli chat を開いた状態で、 /context と入力するとビジュアルインジケータが表示されます。これにより、コンテキスト消費を意識し、長い会話中にそれを積極的に管理するのに役立ちます。 3. 柔軟な認証オプション Kiro CLI はあなたのワークフローに合わせて複数の認証方法をサポートしています。 GitHub ：GitHub アカウントとのシームレスな統合 Google ：Google の資格情報でサインイン AWS Builder ID ：AWSデベロッパー向けの迅速なセットアップ AWS IAM Identity Center ：集中管理による企業グレードの認証 IAM Identity Center を使用しているチームでは、管理者は AWS マネジメントコンソールからすべてを管理できます。例えば、サブスクリプション層の割り当て、MCP サーバーの設定、支出の追跡、組織全体の請求の統合などです。追加のアイデンティティプロバイダーのサポートはまもなく提供される予定です。 4. Kiro IDE との統合 すでに Kiro IDE を使用していますか？既存の設定はそのまま機能します。すべてを最初から再設定する必要はありません。Kiro IDE の設定は Kiro CLI にシームレスに適用されます。 MCP サーバー： .kiro/settings/mcp.json をコピーすれば、MCP ツールの準備が整います ステアリングルール： .kiro/steering/*.md ファイルは Kiro CLI で同じプロジェクト標準、同じコンテキストで機能します プロジェクトドキュメント：すべての .kiro ドキュメントと設定が引き継がれます つまり、コンテキストを失ったり AI アシスタントを再設定したりすることなく、IDE とターミナルの間を行き来できます。同じ Kiro の使い心地が、異なる環境で利用できるのです。 5. 最新のエージェント CLI 体験に期待されるその他の機能 ターミナルでのインタラクティブAIチャット コマンドラインから直接 Kiro との会話を開始できます。 kiro-cli 新しいプロジェクトをゼロから構築し、インフラストラクチャーをコードとして記述し、既存のコードベースに機能を追加できます。これらすべてをターミナルを離れることなく行えます。Kiro はプロジェクトのコンテキストを理解し、複数のファイルにわたって意味のある変更を加えることができます。 > PostgreSQL、Redis キャッシング、Docker セットアップを備えた新しい FastAPI プロジェクトを作成 > JWT を使用して私の Express アプリに認証ミドルウェアを追加 > RDS と ElastiCache を使用した 3 層の AWS アーキテクチャ用の Terraform 設定を作成 より長く詳細なプロンプトを作成する必要がありますか？ /editor を使用して好みのテキストエディタを開き、複数行で詳細な指示を書くことができます。 マルチモーダル入力：画像を直接参照 スクリーンショット、図、またはエラーメッセージを共有する必要がありますか？ Kiro CLI は自動的に処理します。UIの問題のデバッグ、アーキテクチャ図の共有、視覚的なコンテンツの助けを得るために画像を渡すことができます。 Model Context Protocol （MCP）のサポート Kiro CLI は Model Context Protocol （MCP） をサポートしており、外部ツールやサービスでその機能を拡張できます。最も良い点は？既に Kiro IDE で MCP サーバーを使用している場合、それらは Kiro CLI でもシームレスに動作します。MCP の詳細については、「 Kiro : リモート MCP サーバーの紹介 」をご覧ください。 クレジット使用量 IDE と同様に、Kiro は使用に応じて使用したクレジット数を表示するので、追跡することができます。 Autoエージェント Kiro CLI には、Kiro IDE を強化するのと同じインテリジェントな Auto エージェントが含まれています。Auto は各タスクに最適なモデルを動的に選択し、速度、コスト、品質のバランスを取ります。その結果、優れた効率性—Autoモードで使用するとXクレジットかかるタスクが、手動で Sonnet 4 または Sonnet 4.5 を選択すると 1.3X クレジットかかるでしょう。どのモデルを使用するか考えることなく、より良い価格でより良い結果を得るために Auto に任せましょう。 Auto はデフォルトで有効になっており、Kiro CLI で /model コマンドを使用してモデルを選択することもできます。 実世界のユースケース 上記の backend-specialist の例を思い出してください？以下は Kiro でそれを活用する方法です。エージェントの設定を実装した後、それを使う準備ができています。以下の例は、このエージェントを呼び出す方法と、実世界でそれを活用するためのサンプルプロンプトを示しています。 kiro-cli chat --agent backend-specialist > 認証されたユーザーがプロフィール情報を更新できる新しい /api/users/profile エンドポイントを追加してください。メールフォーマットとパスワード強度の検証、データベース障害に対する適切なエラー処理、そして単体テストを含めてください。 > メッセージ、既読ステータス、タイムスタンプのフィールドを持つユーザー通知用の新しい MongoDB スキーマを作成してください。RESTful の規約に従って CRUD エンドポイントを追加し、パフォーマンスのための適切なインデックスを含めてください。 > /api/orders エンドポイントで断続的に 500 エラーが発生しています。より良いエラーログを追加し、注文処理ロジックの潜在的な競合状態を特定するのを手伝ってください。 あらゆるワークフローに特化したエージェントを作成できます。例えばリントツールとチームのスタイルガイドを備えたコードレビューエージェント、インフラアクセスとデプロイメントスクリプトを持つ DevOps エージェント、またはログユーティリティと一般的なトラブルシューティング手順が事前ロードされたデバッギングエージェントなどです。各エージェントはそれぞれの特定のタスクに関連することにコンテキストを集中させ、AI とのやり取りをより速く、より関連性の高いものにします。 Kiro コミュニティに参加しよう ぜひあなたのご意見をお聞かせください！フィードバックの共有、エージェント設定の交換、そして他の Kiro ユーザーとの交流をお待ちしています。 Kiro Discord コミュニティ に参加して、チームメンバーや他の開発者と交流しましょう。 今すぐ始めよう Kiro をあなたのターミナルにインストールする準備はできましたか？ Kiro CLI をインストール して、実際に使いやすい AI を活用したコマンドラインワークフローを体験しましょう。 curl -fsSL https://cli.kiro.dev/install | bash 既存の Kiro IDE ユーザーであれ、Kiro を初めて使用する方であれ、AI のサポートを受けながらターミナルで作業することができます。

本記事は米国時間 11 月 17 日に公開された「 Kiro is generally available: Build with your team in the IDE and terminal 」の日本語抄訳版です。Kiro の最新情報は、 https://kiro.dev/ をご覧ください。 7 月に Kiro プレビュー版としてローンチして以来、AI を使った構造化された開発手法として仕様（Specs）駆動開発が広く採用されてきました。私たちは、仕様駆動開発を AI コーディングツールに初めて導入し、業界全体がその価値を認識しています。計画こそが AI エージェントと共に作業する正しい方法です。 この数か月間、リモート MCP（Model Context Protocol）、グローバルステアリングファイル、開発サーバーサポート、Auto エージェントなどの機能を追加し、仕様駆動開発をより柔軟にしてきました。 本日、Kiro の一般提供を開始するにあたり、新しい機能の提供を開始します。これには、1/ 仕様の正確性を検証するプロパティベーステスト、2/ Kiro での開発の進捗を検証する新しい方法、3/ カスタムエージェントを備えたターミナル用の新しい Kiro CLI、そして 4/ 集中管理機能を持つチームプランが含まれます。 Kiro IDE Kiro IDE は 3 つの新機能を導入します。 プロパティベーステストによる「仕様の正確性」の測定 AI コード生成には根本的な問題があります。コードが実際に仕様通りに動作しているかをどうやって知るのでしょうか？従来のユニットテストは特定の例のみをチェックします。さらに悪いことに、テストを書く人（人間でも AI でも）は自身のバイアスに制限されます。コードをテストするためには、様々な具体的なシナリオをすべて考慮しなければなりませんが実装とテストを同じ存在が書いた場合、思いつかなかったエッジケースを見逃します。AI モデルはしばしば表面的な解決策に走ったり、テストを修正するために無限ループに陥ったりします。 プロパティベーステスト (PBT) は、コードが Spec で定義した動作と一致するかを測定することで、この問題に対処します。特定の例をテストする代わりに、PBT はプロパティ（要件から抽出された一般的なルール）をチェックします。 プロパティとは？ ：プロパティは普遍的な記述です。任意の入力セットに対して、特定の前提条件が成立する場合、ある述語（期待される動作）が真であるということです。例えば、「任意の認証済みユーザーと任意のアクティブなリストに対して、ユーザーはそのリストを閲覧できる」などです。 どのような仕組みなのか？ ： Kiro は EARS（Easy Approach to Requirements Syntax）形式を使用した仕様の記述を支援します（例：システムは認証済みユーザーが有効な車のリストを閲覧できるようにしなければならない）。Kiro はこれらの要件からプロパティを抽出し、論理的にテスト可能なものを判断し、数百から数千のランダムなテストケースを生成してコードをチェックします。 例えば、車の販売アプリを開発する場合を考えてみましょう。 従来の単体テスト：「ユーザーが車#5をお気に入りに追加したら、お気に入りリストに車#5が表示される」 プロパティベーステスト：「どのユーザーでも、どの車でも、お気に入りに追加した車は必ずお気に入りリストに表示されるべき」という性質を定義します。すると、PBT が自動的に様々なパターンでテストを実行します。例えば、ユーザー A が車#1を追加するケース、ユーザー B が車#500を追加するケース、ユーザー C が複数台まとめて追加するケース、特殊文字を含むユーザー名のケース、新車・中古車・認定中古車など異なるステータスの車のケースなど、数百通りもの組み合わせを自動生成してテストします。これにより、想定外のエッジケースも発見でき、実装が設計意図通りに動作することを確認できます。 このプロセス全体を通じて、PBT は「縮小」を通じて反例を見つけるために探索し、失敗の境界を特定します。—あたかもあなたのコードを壊そうとするレッドチームのようにです。違反や反例を見つけると、Kiro は自動的に実装を更新するか、Spec、実装、または PBT 自体を修正するオプションを提示します。 重要性 ： PBT は検証や証明ではありませんが、手動では決して書かないようなシナリオ全体で正確性の証拠を提供し、実装が定義した通りに動作するかを示します。 プロパティベーステストの技術的詳細を読む → チェックポイント エージェント実行フロー内の以前の変更に戻ることができます。Kiro は、エージェントが変更を加えたりアクションを実行したりするたびにチェックポイントを生成します。進捗を失うことなく、任意のステップをロールバックできます。これは、タスクの実装が進んでいて、進捗を失いたくない場合や、クレジットを使って作業をやり直したくない場合に便利です。 チェックポイントの詳細を読む → マルチルートワークスペースサポート Kiro は、複数のプロジェクトルートを同時に扱えるようになりました。複数の git サブモジュールや単一プロジェクト内の複数のパッケージを持つチームは、AI エージェントを使ってそれらすべてを横断して作業できます。典型的な Kiro ワークスペースには、単一の「ルート」フォルダ（例： /users/bob/my-project） が含まれます。マルチワークスペースサポートにより、単一の kiro ワークスペースが複数のルートを持つことができます。例えば、 /users/bob/my-project と /shared/utils/auth の両方をトップレベルフォルダとして含む単一のワークスペースです。 マルチルートワークスペースの詳細を読む → Kiro CLI の導入 Kiro エージェントがターミナルで利用可能になりました。CLI を使用して、機能の構築、ワークフローの自動化、エラーの分析、バグの追跡、修正の提案を、選択したターミナルで数秒で実行できます。フローを維持する高度にインタラクティブなループで作業できます。 何が含まれるのか？ ： CLI は、Kiro の全機能をターミナルにもたらします。Claude Sonnet 4.5、Claude Haiku 4.5、Auto、ステアリングファイル、高度なコンテキスト管理、ローカルでファイルを読み書きし、API を呼び出し、bash コマンドを実行する MCP ツールが含まれます。Spec 作成サポートは間もなく提供されますが、CLI で既存の spec を使って作業することもできます。 CLI はまた、特定のタスク用にカスタマイズされた専門的な AI アシスタントであるカスタムエージェントもサポートしています。事前承認されたツール権限、コンテキストファイル、カスタムプロンプトで最適化されています。例えばバックエンドスペシャリストは API パターンとスキーマのみに焦点を当てます。フロントエンドエージェントはコンポーネントのみを知っています。各エージェントは、重要なことだけにコンテキストウィンドウを使用します。カスタムエージェントは、繰り返しやコンテキストの劣化のリスクなしに、Kiro がその分野の専門家として機能するように、専門知識を非常に正確にパッケージ化する方法と考えてください。 過去数週間 CLI を使用しているユーザーからは、そのスピードとインタラクティブ性を気に入っているとの声をいただいています。IDE で使用しているのと同じ Kiro サブスクリプションとログインで CLI を使用でき、クレジット制限と超過分は両方のツールで共有されます。 以下のコマンドで macOS または Linux にインストールしてください。 curl -fsSL https://cli.kiro.dev/install | bash Kiro CLI とカスタムエージェントの詳細を読む → チーム向け Kiro チームは、AWS にログインするのと同じ方法で、AWS IAM Identity Center 経由で Kiro にサインアップできるようになりました。管理者は AWS Management Console からアクセスを管理でき、Pro、Pro+、または Power サブスクリプションを割り当てることができます。また、超過分をオンにし、コストを監視し、MCP をセットアップおよび制御し、組織全体で単一の請求書を管理できます。新しい管理ダッシュボードは、チーム、スタートアップ、またはエンタープライズ向けに Kiro を管理するために必要なすべてのツールを 1 か所で提供します。ユーザーとしては、「組織の ID でサインイン」をクリックしてプロセスに従うだけです。 スタートアップ向け Kiro Pro+ 本日から、スタートアップ向けオファーも提供します。 世界のほとんどの地域で 1 年間の Pro+ ティアアクセスを提供します 。シリーズ B までの適格なスタートアップに提供され、2025 年 12 月 31 日まで、クレジットの在庫がある限り利用可能です。既存の AWS Activate クレジットは Kiro に使用でき、両方のオファーは重複適用できます。 こちらから申し込む → チーム、ツール、テスト全体で、Kiro は、AI 駆動型開発に適切なレベルのコンテキストと構造をもたらすことで、あなたが望む働き方をより良くサポートします。これは始まりに過ぎません。 IDE を始める | CLI を始める

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。　だんだんとAWS re:invent 2025 が近づいてきました。そして毎年おなじみ怒濤の1時間。「AWS Black Belt Online Seminar 2025 年 AWS re:Invent 速報」を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いします。 最近AWSのトレーニングサイトのAWS Skill builderで面白いトレーニングを発見しました。 Meeting Simulator という、実際の会議や現場を模した仮想シナリオ上でコミュニケーションスキルや説明力を実践的に鍛えるトレーニングコースです。経営層・ビジネスリーダー・技術担当者など現実に近い複数の立場や性格を持つAIキャラと会議をシミュレーションして、現実的なビジネス課題に対してディスカッションします。AI英語学習のAWS版みたいなものです。会話がまだ英語しか対応していないようですが、面白いので興味がある方は覗いてみてください。 そして、AWS認定全冠ホルダーの皆様、もうすぐ AWS Certified Generative AI Developer – Professional のベータが開始されるようです。最新情報をチェックしてみてください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に引き続き募集中ですのでよろしくお願いします。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「[対談記事] 「その AI の精度が 1% 上がったとき、顧客価値は？」 freee が語る、価値創出論と AI ネイティブ組織への変革」を公開 フリー株式会社は創業時から「AI CFO」というビジョンを掲げ、LLMの登場を機にAIネイティブ組織への本格的な変革を開始しました。同社は「AIラボ」という横串組織を設立し、機械学習の専門家が各プロダクトチームと協働してAI機能を実装する体制を構築しています。「成功基準」という独自フレームワークの確立で、AI投資のROIを適切に評価し、真の顧客価値創出に繋げる実践的な方法論を示しています。特に「確認コスト」と「修正コスト」を分離した業務フロー設計により、AI導入後の総コストを正しく把握し、業務効率化の実効性を高める手法は皆様にとって参考になります。技術的な精度向上だけでなく、それがどれだけの顧客価値を生み出すかを定量化する「成功基準」フレームワークと、AI専門組織による全社支援体制の構築方法は、AI活用をPoCレベルから実際のビジネス価値創出へと発展させるための具体的な組織運営手法として大変有益な知見となります。 AWS生成AI国内事例ブログ「株式会社 Berry 様の AWS 生成 AI 活用事例「Amazon Bedrockで医療機器のQMS業務を効率化」」を公開 医療機器メーカーである株式会社Berry様が、Amazon Bedrockを活用してクラウド型eQMS「QMSmart」に3つのAI機能を導入した事例を紹介しています。医療機器業界では、QMS省令やISO 13485などの厳格な規制要件への対応、膨大な文書管理、品質イベント処理が大きな負担となっていましたが、Amazon BedrockのGuardrails機能により高いセキュリティレベルを確保しながら、AI文章チェック機能（規制適合性の自動判定）、AI根本原因分析支援機能（なぜなぜ分析支援）、AIテスト生成機能（文書から理解度測定問題を自動生成）を実装しました。当初はRAGやファインチューニングが必要と考えていましたが、システムプロンプトの工夫だけで専門性の高い回答を生成できることを検証で確認し、開発期間を約1か月から約1週間に短縮できました。 ブログ記事「Kiro : リモート MCP サーバーの紹介」を公開 Model Context Protocol（MCP）は、AIエージェントがツールや外部システムに接続するための標準プロトコルとして、AIコーディングアシスタントで広く活用されています。これまではローカル環境で動作するMCPサーバーが主流でしたが、Kiroは新たにリモートMCPサーバーサポートとワンクリックMCPインストール機能を発表しました。リモートMCPサーバーを利用することで、エージェントの機能をローカル環境の枠を超えて拡張でき、データソースやインターネット上のツール、各種サービスにより簡単に接続できるようになります。従来のローカル環境に限定されていたAIアシスタントの機能が、インターネット上の豊富なリソースやサービスと連携できるようになることで、より柔軟で強力な開発支援環境の構築が可能となり、AIを活用したソフトウェア開発の可能性が大きく拡がることになります。 ブログ記事「繰り返すのをやめよう：あなたが見逃していた AI コンテキストレイヤー、グローバルステアリングとは」を公開 Kiroの新機能「グローバルステアリング」は、AIアシスタントに毎回同じプロンプトや設定を繰り返し説明する必要性を解決するAIコンテキストレイヤーです。開発者はグローバルステアリング機能により新しいプロジェクトを開始するたびに発生していた設定の繰り返し作業が不要になり、時間節約と一貫性のあるコード品質の維持が実現できます。特に複数のプロジェクトやチームで作業する開発者は、個人の好み、チームの規約、組織の基準を階層的に適用できるため、効率性と標準化の両立が可能になります。AIアシスタントが初回から開発者の意図やチームの基準を完全に理解した状態で作業を開始できるため、より高品質で一貫性のあるコード生成と、プロジェクト間での技術的負債の削減が実現され、AI支援開発の生産性が向上することになります。 ブログ記事「【開催報告】セキュリティと生成AI について学ぶ GameDay with AWS Partners」を公開 2025年10月14日に「セキュリティと生成AIについて学ぶGameDay with AWS Partners」を開催し、24社70名が参加してセキュリティインシデント疑似体験に取り組みました。AWS GameDayは実際のAWS環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチーム単位で不正アクセスの検知やデータ漏洩調査、マルウェア感染対処など現実世界の技術課題に取り組む実践的なトレーニングプログラムです。参加者はAWS SecurityHubなどの実際のAWSセキュリティサービスを駆使しながら、制限時間2時間でインシデント対応を体験し、ゲーミフィケーション要素により競い合いながら学習を進めました。イベント後半では、Palo Alto Networks、CyberArk、Weights&Biases、KnowBe4の4社パートナーによるAgentic AIの時代におけるセキュリティソリューションの紹介があり、AWS Well-Architected Frameworkを活用したセキュリティ強化の重要性も説明されました。 ブログ記事「re:Invent 2025 における AI 駆動のオペレーションとオブザーバビリティの活用」を公開 2025年12月1日から開催されるAWS re:Invent 2025のクラウドオペレーショントラックでは、5つの主要テーマにわたる30のセッションを通じて、監視とオブザーバビリティのモダナイゼーションに関する知見を提供します。特に注目されるのは生成AIとインテリジェントな運用分野で、Amazon CloudWatchの自動分析によるインシデント対応の加速化、Amazon Bedrock Agentsを活用したクラウドオペレーション自動化、AI エージェントによるテレメトリーデータの実用的情報変換など、従来の手動トラブルシューティングを数分で解決する効率的なAI駆動ソリューションを紹介します。 ブログ記事「AgentCore Gateway の MCP サーバー統合による MCP アーキテクチャの変革」を公開 このブログでは、Amazon Bedrock AgentCore GatewayにMCPサーバーをターゲットタイプとして直接サポートする新機能を紹介しています。この機能により、複数のドメイン特化MCPサーバーを単一のゲートウェイインターフェースの背後に統合することが可能になり、従来の課題であった組織全体でのツール発見・共有の困難さ、複数MCPサーバー間での認証管理の複雑さ、個別ゲートウェイ維持の管理工数を中央集約型アプローチで解決する方法が説明されています。具体的には、ショッピングカート、製品カタログ、プロモーションといった異なるチームが運用する特化MCPサーバーを、ルーティング、認証、ツール管理のための単一制御ポイントとして統合し、REST APIやAWS Lambda関数と同等に扱う実装手順が詳しく紹介されています。 ブログ記事「金融機関向け生成 AI 活用のリファレンスアーキテクチャとユースケースを公開（金融リファレンスアーキテクチャ日本版 2025）」を公開 このブログでは、AWS金融リファレンスアーキテクチャ日本版に新たに追加された生成AI関連コンテンツとして、金融機関のセキュリティ要件に対応した生成AIワークロードのリファレンスアーキテクチャと、実践的な活用例を紹介しています。リファレンスアーキテクチャでは、オープンソースの「Generative AI Use Cases（GenU）」の閉域版をベースに、金融機関向けの閉域ネットワーク構成、AWS KMSカスタマーマネージドキーによる暗号化強化、Amazon Bedrock Guardrailsの設定強化、監視・ガバナンス機能を実装したサンプルが提供されています。また、具体的なユースケースとして、文書・コンテンツ審査（AIと人間の協働による膨大な文書審査業務の効率化）、AI活用営業・窓口対応トレーニング（ロールプレイ）、契約書業務アシスタント（複数の専門AIエージェントによる包括的支援）、ATM不正検知（マルチモーダルモデルによる特殊詐欺防止）の4つの実装例が詳しく解説されており、一部についてはAWS CDKによるデプロイ手順も紹介されています。 ブログ記事「【開催報告 & 資料公開】AWS 秋のオブザーバビリティ祭り 2025」を公開 このブログでは、2025年11月6日に開催された「AWS秋のオブザーバビリティ祭り2025〜最新アップデートと生成AI×オブザーバビリティ〜」のイベント報告として、オブザーバビリティ分野における生成AI技術の活用事例を中心に紹介しています。特に注目される内容として、「生成AIで進化するAWSオブザーバビリティ」セッションでは、運用課題の解決手段としてのAIOpsアプローチが解説され、Amazon CloudWatchに組み込まれたAI機能（CloudWatch Investigations、Query Generator、CloudWatch Logs Anomaly Detection、CloudWatch Anomaly Detection）によるインシデント調査・対応の効率化手法が紹介されました。また、Amazon CloudWatch MCP ServerやAmazon CloudWatch Application Signals MCP Serverを活用し、Amazon Q Developer CLIを通じてインシデント調査からレポーティングまでを自動化するデモも披露されています。さらに、「Amazon Bedrock AgentCoreで実現！お手軽AIエージェントオブザーバビリティ」セッションでは、2025年10月13日にGA となったAmazon Bedrock AgentCoreを活用したAIエージェント開発・運用における CloudWatch GenAI Observability機能の詳細な活用方法が紹介されています。 ブログ記事「SAP アプリケーション開発を Amazon Q Developer でより速く」を公開 このブログでは、SAPアプリケーション開発におけるAmazon Q Developerの活用方法を紹介しています。Amazon Q Developerを活用し、ABAP コードの生成、BTPとFioriアプリケーションの生成、単体テストケースの作成、レガシーABAPコードのドキュメント化という4つの主要な使用例を紹介しています。自然言語のプロンプトから機能的なABAPコードや完全なFioriアプリケーションを生成でき、SAPのプログラミングフレームワーク全体において生産性向上を実現出来ます。 ブログ記事「SAP Cloud Application Programming を加速する Amazon Q Developer」を公開 このブログでは、SAP Cloud Application Programming Model（CAP）開発を加速するAmazon Q Developerの活用方法を紹介しています。CAPは、Python、Node.js、Core Data Servicesを使用してエンタープライズクラウドサービスとアプリケーションを開発するためのSAPのフレームワークで、コアシステムを変更せずにカスタムアプリケーションを作成できるサイドバイサイド拡張をサポートしています。このツールにより、SAP開発者は複雑なCAPフレームワークの技術的詳細から解放され、従来手動で行っていたプロジェクト構造設定、依存関係構成、ボイラープレートコード作成の時間を大幅に短縮できます。 サービスアップデート Anthropic社のClaude Sonnet 4.5が AWS GovCloud (米国) のAmazon Bedrockで利用可能に Anthropic社のClaude Sonnet 4.5が、AWS GovCloud (米国東部および米国西部)でAmazon Bedrockを通じて利用できるようになりました。Claude Sonnet 4.5はAnthropicの最も高性能なモデルで、複雑なエージェントの構築、高度なコーディング、長期間にわたるタスクの実行において卓越した性能を発揮します。AWS GovCloud (米国)での提供により、政府機関や規制の厳しい業界でも、セキュリティとコンプライアンス要件を満たしながら最新のAI技術を活用できるようになりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

本記事は 2025 年 10 月 15 日に公開された “ Guide to AWS Cloud Resilience sessions at re:Invent 2025 ” を翻訳したものです。 組織に損失をもたらすダウンタイムを防ぐ方法を学ぶために AWS re:Invent に参加される方は、重要なアプリケーションのレジリエンスを向上させるのに役立つ、150 以上のブレイクアウトセッション、ワークショップ、チョークトーク、ビルダーセッション、コードトークに参加できます。セッションを確認するには、 re:Invent 2025 イベントカタログ を開き Area of Interest で Resilience にチェックを入れフィルタリングします。この投稿では、これらの必見のセッションをいくつか紹介します。ビジネスに最も関連性の高いセッションを選択できるよう、推奨事項を 3 つのトピックに分けています。1/ AWS のイノベーションとベストプラクティス、2/ レジリエントなアプリケーションの構築と運用、3/ レジリエンス文化の醸成です。受付が開始されています。お早めにご予約ください。 AWS のイノベーションとベストプラクティス お客様のアプリケーションに最も信頼性の高いクラウドインフラストラクチャを提供するため、AWS にて行っている最先端のイノベーションをご紹介します。アベイラビリティーゾーン (AZ) やリージョンなどの AWS の 障害分離境界について学び、それらを活用してアプリケーションのレジリエンスを向上させる方法を習得できます。また、20 年以上にわたって大規模な高可用性サービスを運用してきた経験から得られた、実証済みの運用プラクティスと重要な教訓を共有します。 ブレイクアウトセッション From ideas to impact: Architecting with cloud best practices ( ARC204 ) 2025 年は、AWS Well-Architected Framework、Cloud Adoption Framework、AWS Cloud Operating Modelの 10 周年を迎えます。これらの基礎的なフレームワークが、お客様のフィードバック、数千の組織から得られた実践的な知見を通じてどのように進化してきたかを学びます。体系的なガイダンスとして始まったものが、クラウド環境を最適化するための常に進化する知見へと成熟しました。この継続的なフィードバックが、アーキテクチャレビュー、運用、改善活動全体にわたるイノベーションをどのように推進しているかをご覧ください。これらの統合されたベストプラクティスを活用してクラウド変革を加速させるための実践的な戦略を学びます。 Building on AWS resilience: Innovations for critical success ( ARC207 ) 世界経済と重要なインフラストラクチャを支える基幹サービスには、極めて高いレジリエンスが求められます。約 20 年にわたる集中的なイノベーションを通じて AWS は、世界中の重要なワークロードを支える中核的なエンジニアリング手法と運用手法を開発してきました。AWS のアーキテクチャイノベーションと組織的プラクティスが、深刻な障害発生時でもレジリエンスを維持する堅牢なサービスの構築をどのように支援しているかをご紹介します。また、AWS がレジリエンスへの継続的な投資を通じて、政府、経済、重要インフラ全体にわたる基幹サービス提供の基盤をどのように提供しているかを学びます。 チョークトークとコードトーク Building resilient clients: Architecture patterns from Amazon.com ( ARC331 ) Amazon.com の大規模な本番環境での経験から得られた、レジリエントなフロントエンドアプリケーションを構築するためのアーキテクチャパターンをご紹介します。Amazon.com が、障害注入テスト、キャッシング戦略、グレースフルデグラデーションパターンを通じて、ピークイベント時の信頼性を維持するためにフロントエンドシステムをどのようにアーキテクチャ設計しているかを学びます。サーキットブレーカー、デプロイメントの安全性、運用上の優秀性のための包括的なモニタリングの実装を探ります。この技術セッションでは、AWS Well-Architected Framework の原則に沿った、スケールする堅牢なクライアントアプリケーションをアーキテクチャ設計するための実践的なパターンを提供します。 Defend against downtime using fault isolation boundaries ( COP305 ) AWS の障害分離境界に合わせた一般的な障害モードから回復するアプリケーションを構築することで、可用性目標を達成できます。このチョークトークでは、Application Recovery Controller (ARC) を使用して、AWS アベイラビリティーゾーンおよび AWS リージョン内の障害からアプリケーションを回復する方法を共有します。ARC の仕組みと、アーキテクチャに組み込むべき重要なポイントを習得できます。 Resilience testing and AWS Lambda actions under the hood ( COP414 ) サーバーレステクノロジーの使用が増えるにつれて、レジリエンステスト (カオスエンジニアリング) は、信頼性と可用性の高いアプリケーションを確保するためにますます重要になっています。AWS Lambda ベースのワークロードのレジリエンスをテストするための新機能をデモし、これらの障害がどのように構築され、内部で実行されるかを解説します。また、モダンなサーバーレスアプリケーションに関する顧客経験から得られた貴重な知見も提供いたします。 レジリエントなアプリケーションの構築と運用 シングル AZ、マルチ AZ、マルチリージョンアーキテクチャ全体でアプリケーションのレジリエンスを最大化するための戦略を探ります。自動復旧メカニズムを活用してダウンタイムを最小限に抑える効果的な手法や、障害から迅速に復旧するための戦略をご紹介します。また、アプリケーションが業界標準や規制に準拠するための実践的なガイダンスも提供します。 ブレイクアウトセッション Building resilient multi-Region applications with Capital One ( ARC404 ) 組織は、大規模なマルチリージョンアプリケーションで予測可能な回復時間を達成し、一貫性を維持することに大きな課題を抱えています。Application Recovery Controller (ARC)、Aurora DSQL、Dynamo DB Multi-Region Strong Consistency を使用して、明確な復旧目標を持つレジリエントなアーキテクチャを作成する方法を学びます。実世界の実装パターンを通じて、ARC Region switchとAWS Fault Injection Service がメンテナンスとテストのアプローチをどのように変革するかをご紹介します。このエキスパートレベルのセッションでは、予測可能な回復と一貫した運用を提供するマルチリージョンアプリケーションを設計するための実践的な戦略を提供します。 Multi-Region disaster recovery & resilience testing (feat. Fidelity) ( COP358 ) AWS のイノベーションが、エンタープライズ規模の組織のディザスタリカバリ (DR) 戦略をどのように革新しているかをご紹介します。AWS リージョン全体で数千のアプリケーションを管理するには、高度な DR 機能が必要ですが、従来は複雑でリソース集約的なカスタム開発が求められていました。Fidelity が、Amazon Application Recovery Controller の Region switch 機能によるマルチリージョン復旧オーケストレーション、ライブダッシュボード、レポート機能を活用して、8,500 のミッションクリティカルなアプリケーションの DR をどのように変革したかを学びます。さらに、AWS Fault Injection Service と組み合わせることで、Fidelity は現実的な条件下で復旧手順を検証し、DR プランへの信頼性を高めています。AWS が企業のインフラ運用のモダナイゼーション、コンプライアンスの向上、ミッションクリティカルなアプリケーションの事業継続性の強化をどのように実現しているかをご覧ください。 Architecting resilient multicloud operations, feat. Monzo Bank ( HMC201 ) 組織がレジリエンスのニーズに対応するためにマルチクラウド戦略を選択する際、データの一貫性、サービスの分離、長期的なテストと保守といった領域で課題に直面することがよくあります。このセッションでは、運用レジリエンスに対する実用的で効率的なアプローチを提供する戦略的マルチクラウドアーキテクチャを実装した、Monzo Bank のレジリエンスへの取り組みについて学びます。主要な AWS インフラストラクチャと並行して、別のクラウドプロバイダー上で重要な銀行サービスを実行する Monzo の Stand-in Platform について詳しく掘り下げます。サービスの可用性を維持し、データ整合性のトレードオフを管理し、レジリエントなマルチクラウドアーキテクチャを実装するための実践的なパターンを学べます。 Cyber resilience on AWS, designing security and recovery strategies ( GBL204 ) サイバーレジリエンスとは、サイバー攻撃などの有害なイベントが発生しても、組織が意図した成果を継続的に提供できる能力のことです。サイバーレジリエンスとディザスタリカバリは、インシデント発生後に通常の運用を復旧するための計画と対応を含むという点で共通しています。サイバーレジリエンスは、より広範な戦略の一部としてディザスタリカバリを含んでいます。サイバーレジリエンスを設計する際には、下記の複数の重要なテーマがあります。 保護：システム、ネットワーク、データを保護するために講じる予防的措置 準備：サイバーインシデントに効果的に対応し、復旧できるよう組織を準備する活動 復旧：サイバーインシデント発生後、システム、ネットワーク、データを通常の状態に復元するための対応 チョークトークとビルダーズセッション Architecting multi-Region expansion for mission-critical workloads ( ARC322 ) ミッションクリティカルなアプリケーションを複数の AWS リージョンに拡張する際は、特に厳格な SLA 要件がある場合、綿密なアーキテクチャ計画が必要です。このチョークトークでは、マルチリージョン拡張における主要な設計上の考慮事項を探ります：サービスの可用性評価、安全なリージョン間接続の実装、信頼性の高い運用の確保。シナリオベースの共同演習を通じて、評価方法、ネットワークパターン、運用手順をマッピングする方法を学びます。ミッションクリティカルなワークロードの高可用性とパフォーマンスを維持するリージョン拡張プロジェクトのための、実践的なアーキテクチャ手法を習得できます。 Cell-based architectures: From connected vehicles to enterprise systems ( ARC327 ) コネクテッドビークルプラットフォームは、セルベースアーキテクチャが大量のデバイスアクセス、データ急増、レイテンシーに敏感なワークロードの課題をどのように解決するかを示しています。このアーキテクチャパターンが自動車分野を超えて、スマートカメラ、監視システム、ソーラー管理、SaaSプラットフォームをどのように変革するかを学びます。AWS IoT Core、Amazon MSK、Amazon EKS with Graviton、Amazon Aurora、Amazon Memory DB for Redis を使用した実践的な例を通じて、障害分離、スケーラブルなデプロイ、ローカライズされたエッジサービスの実装方法をご紹介します。このセッションでは、多様な業界にわたって大規模なパフォーマンスを維持するレジリエントなコネクテッドシステムを構築するためのアーキテクチャパターンを提供します。 A practical guide for meeting regulatory resilience requirements ( COP210 ) 世界中の組織は、DORA、NIS2、RegSCI などの規制要件を満たすために、運用レジリエンスを実証する必要があります。これらの規制は、組織が中断を防ぎ事業継続性を維持するためのインシデント検知とディザスタリカバリ計画を備えていることを保証することを目的としています。このチョークトークでは、金融サービスやヘルスケアなどの規制業界において、AWS サービスを使用してコンプライアンスを評価し証明する方法を学びます。D-CAT ツール、AWS Fault Injection Service の実験レポート、AWS Resilience Hub のレジリエンス評価、Amazon Application Recovery Controller のライブダッシュボードの実践的な活用方法を探り、規制への準備状況を評価し文書化する方法をご紹介します。 AWS disaster recovery strategies ( COP302 ) このディザスタリカバリ (DR) ビルダーズセッションで、予期せぬ事態に備えましょう。ビジネスの復旧目標に沿った DR 戦略を実装するアプリケーションに取り組みます。バックアップと復元、パイロットライト、ウォームスタンバイ、または AWS Elastic Disaster Recovery (AWS DRS)、Amazon Aurora、Amazon S3、Amazon EC2、AWS CloudFront、AWS DRS、AWS Fault Injection Service、AWS Backup などのアプローチ、サービスを取り上げます。また、選択したアプローチをテストし検証する方法も探ります。ビジネスに適した DR 戦略を構築するための実践的な知見を習得できます。 Financial services multi-Region design patterns and best practices ( IND317 ) AWS 上で金融サービス向けのレジリエントなマルチリージョンデプロイメントを構築するための実証済みのアーキテクチャパターンと設計原則をご紹介します。Amazon Application Recovery Controller、Amazon Aurora DSQL、Amazon Dynamo DB Multi-Region 強整合性などの専門的な AWS サービスを活用して、堅牢なグローバルソリューションを構築するための実践的な知見を得られます。マルチリージョンデプロイメントに伴うトレードオフを包括的に理解し、組織固有の要件に対して信頼性、パフォーマンス、コストのバランスを取った、情報に基づいたアーキテクチャ上の意思決定を行う能力を習得できます。 ワークショップ Building and testing resilient multi-AZ applications ( ARC304 ) レジリエントなマルチ AZ アプリケーションの構築とテストの実践的な経験を獲得できます。包括的なヘルスモニタリングのために、Amazon CloudWatch ダッシュボード、インサイトルール、複合アラームの使用方法を学びます。AWS Fault Injection Service を使用してランダムな障害を注入し、さまざまなシングル AZ 障害をシミュレートする練習を行います。AWS CodeDeploy を使用したゾーンデプロイメントを習得し、現実的な障害シナリオを体験します。Amazon Application Recovery Controller のゾーンシフト機能を活用して、障害から復旧し顧客体験を維持する方法を探ります。このワークショップでは、AWS 上で高可用性システムを設計し運用するための実践的なスキルを提供します。 From downtime to uptime: Mastering application recovery on AWS ( ARC307 ) AWS 上でアプリケーションのレジリエンスを強化するための、Amazon Application Recovery Controller (ARC) の最新機能を習得します。ハンズオン演習を通じて、自動復旧ワークフローの実装、復旧計画のテスト、大規模な復旧オペレーションの監視方法を学びます。エンタープライズのレジリエンス要件に沿った復旧ソリューションの設計と管理における実践的なスキルを構築します。このワークショップでは、高度な復旧アーキテクチャを通じて事業継続性を確保するための実証済みのパターンを、クラウドアーキテクトと DevOps エンジニアに提供します。 Building resilient architectures with observability ( COP408 ) 重要なシステムに障害が発生すると、ダウンタイム1分毎に金銭的損失と信頼の喪失が発生します。このハンズオンワークショップで、アプリケーションをレジリエントで可観測性の高いシステムに変革しましょう。カオスエンジニアリングを通じてレジリエンスを強化し、AWS Fault Injection Service で障害を注入してアベイラビリティーゾーンの障害、ネットワークの問題、デプロイメントの問題をシミュレートします。Amazon CloudWatch と Amazon Application Recovery Controller を活用して、障害を検知、診断し、自動的に復旧する方法を学びます。実際の条件下でも可観測性とレジリエンスを維持するアプリケーションを構築する実践的な経験を習得できます。 レジリエンス文化の醸成 運用準備レビュー (Operational Readiness Reviews (ORR) )、レジリエンステスト、根本原因分析 (Root Cause Analysis (RCA) ) 、ゲームデイシナリオを通じて、開発サイクルの早い段階でレジリエンスを統合する方法を学びます。金銭的損失を伴うダウンタイムを防ぐのに役立つ、効果的で安全なデプロイメントプラクティスと堅牢なオブザーバビリティ戦略を構築するための技術を探ります。 ブレイクアウトセッション Mastering Root Cause Analysis: Rebuilding trust after outages ( ARC211 ) 障害の調査は困難ですが、それを顧客に効果的に説明することはさらに大きな課題です。根本原因分析 (Root Cause Analysis (RCA) ) ドキュメントは、理解を示し、責任を明確にし、不足点に対処する計画を提示することで信頼を再構築する唯一の機会となることがよくあります。10 年以上にわたる効果的な RCA 作成の経験から、透明性を保ちながら複雑性、カスタムソフトウェア、社内用語を乗り越えるための実践的な戦略を学びます。ISV や SaaS プロバイダーの方は、何が起こったのか、なぜ起こったのかを説明し、確実な改善計画を示す洞察に富んだ RCA を作成する手法をご紹介します。 The incident is over: Now what? ( COP216 ) 最適な運用プラクティスは、避けられないインシデントへの対処方法と迅速な復旧方法を定義します。では、その後はどうでしょうか？真の根本原因を突き止め、効果的な予防措置の実施を計画するにはどうすればよいでしょうか？すべてのインシデントを組織全体の学習機会に変えるにはどうすればよいでしょうか？責任共有モデルやサードパーティソフトウェアベンダーはどのように関わってくるのでしょうか？ 根本原因分析 (Root Cause Analysis) と Correction of Error (COE) に関する私たちの思考モデルと数十年にわたる経験を共有しますので、皆様の組織で効果的なプラクティスを推進できるようになります。 チョークトーク、コードトーク、ビルダーズセッション Operational excellence: Building resilient systems ( ARC316 ) このチョークトークでは、運用プラクティスとシステムレジリエンスの重要な関係を探ります。ロギング、ヘルスチェック、デプロイメント戦略などの基本的な要素が、AWS 上のアプリケーションの信頼性にどのように影響するかを検証します。実際のシナリオを通じて、システムの可用性を損なう一般的な運用上の落とし穴を発見し、Well-Architected の原則に沿った実践的な解決策を学びます。アーキテクチャのレジリエンスを強化し、運用上の優秀性を高めるための実証済みのアプローチを学びます。このインタラクティブなセッションでは、堅牢なクラウドシステムを構築し維持するための実践的なパターンを、アーキテクトとオペレーターに提供します。 Agent down! Building unbreakable AI workflows ( COP321 ) このチョークトークで、カオスエンジニアリング (レジリエンステスト) の原則が自律型 AI エージェントワークフローにどのように適用されるかをご紹介します。AWS Fault Injection Service を使用して、複雑なマルチステップタスクを処理するエージェントベースのシステムをストレステストする方法を学びます。意思決定ループ、タスクの引き継ぎ失敗、リソース調整の崩壊など、エージェント AI 特有の障害モードを特定および軽減する方法をご紹介します。オーケストレーション層、メモリシステム、ツールの相互作用全体でエージェントのレジリエンスを検証する実験を設計する練習をします。自律型 AI ワークフローを構築または維持しているチームに最適なこのチョークトークは、エージェント駆動型アーキテクチャのレジリエンスを向上させるための実践的な技術を提供します。 Streamline operations with automated health monitoring and response ( COP343 ) AWS 環境が複雑化するにつれて、組織は健全なインフラストラクチャの可視性を維持し、インシデントに対応することに課題を抱えています。このチョークトークでは、AWS Health と Amazon CloudWatch を使用して、包括的なヘルスモニタリングと自動化されたインシデント対応を構築する方法を学びます。Systems Manager Automation を使用した修復の実装、効果的なモニタリングパターンの作成、メトリクスをアクションに変換する実践的な内容を体験できます。クロスアカウントヘルスダッシュボード、インテリジェントなアラート、自動対応ランブックの実践的なアプローチを習得できます。 Downtime prevention with the Resilience Lifecycle Framework ( COP357 ) ほとんどのシステム障害は人的エラー、コードデプロイメントの問題、システムの設定ミスに起因するため、リスクを事前に軽減し、レジリエンス計画を実践し、運用インシデントの再発を防ぐためのフレームワークを整備することが重要です。このチョークトークでは、長年にわたるお客様や社内チームとの協働に基づき、レジリエンスのベストプラクティスを集約した包括的なアプローチである AWS レジリエンライフサイクルフレームワーク の適用方法を学びます。目標設定、レジリエンスを考慮した設計、レジリエンステスト、運用準備レビュー (Operational Readiness Reviews (ORR) ) の実施、インシデント分析レポートの作成など、重要なワークロードのレジリエンス態勢を強化するための実践的な戦略を習得できます。 Build resilient SaaS: Multi-account resilience testing patterns ( ISV404 ) エンタープライズ SaaS プロバイダーは、テナント境界を越えて障害が拡散するのを防ぎながら、高可用性を維持するという課題に直面しています。主要な ISV が、AWS Fault Injection Service を使用して、制御されたレジリエンステスト実験を通じてマルチテナントアーキテクチャのレジリエンスを検証する方法を学びます。厳格なテナント分離を維持しながらクロスアカウント障害シナリオをテストする、セキュリティおよび HR テクノロジープロバイダーの実例をご紹介します。顧客の可用性を損なうことなく、SaaS アーキテクチャを強化するレジリエンステストを実装するためのパターンをご紹介します。 ワークショップ Chaos engineering workshop ( COP304 ) このワークショップでは、カオスエンジニアリングとも呼ばれるレジリエンス実験を実行するための AWS Fault Injection Service (FIS) を紹介します。障害を注入し、電源中断やリージョン間接続の問題などのテストシナリオを適用して、Amazon EKS、Amazon ECS、AWS Fargate、Amazon EC2、Amazon S3、Amazon RDS などのサービスの動作にどのような影響を与えるかを確認する方法を学びます。また、規制業界でのコンプライアンスに必要な実験レポートの作成方法も学びます。さらに、Amazon CloudWatch、AWS X-Ray、Amazon CloudWatch RUM を使用して、実験から重要なインサイトを得る方法も学びます。 本ブログは Partner Solutions Architect の 石倉 徹が翻訳しました。原文は こちら です。 Vanessa Au Vanessa Auは、AWS のシニアプロダクトマーケティングマネージャーです。Amazon での 8 年以上の経験とワシントン大学でのコミュニケーション学博士号を持ち、インパクトの高いプロダクトローンチの実行と、データとストーリーテリングを活用してお客様が AWS を使用してレジリエントなアプリケーションを構築する方法を紹介することを専門としています。

2025 年 10 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Aurora 機能編 – Aurora Global Database の詳細 Amazon Aurora Global Database では、複数の AWS リージョンにまたがり複数の Amazon Aurora Database クラスターを構成できます。大規模障害におけるデータベースの地理的冗長性や、ユーザーのアクセス元の地域近くにクラスターを配置し各地域から低いレイテンシーでのデータ読み取りを実現します。 こちらの動画では Amazon Aurora Global Database ついて紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されており、データベースの地理的冗長性に関心のある方 Amazon Aurora 及び Amazon Aurora Global Database の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora Global Database の概要、他のレプリケーションソリューションとの違いを理解したい方 本 BlackBelt で学習できること Aurora Global Database に関する概要や切り替え動作など、主要機能や制限事項について学習いただけます。 スピーカー 石渡 嘉之 テクニカルアカウントマネージャー Amazon Aurora 運用実践編 – チューニングアプローチ AWS が提供するデータベースのマネージドサービスである Amazon Aurora のチューニングアプローチについてご紹介します。 データベースチューニングのための検知・分析に活用できるツールとして CloudWatch Database Insights ではデータベース全体の健全性を管理する包括的な機能を提供しています。 その他にも「CloudWatch」「拡張モニタリング」があります。 こちらの動画では、これらのモニタリングツールを使ってどのように分析していくかを待機イベントやデータベースロードについて説明しつつ、ご紹介させて頂きます。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の方 Amazon Aurora をご利用中で、チューニングを検討中の方 本 BlackBelt で学習できること Amazon Aurora においてチューニングを実施する際に活用できるツールについて学習できます。 スピーカー 河合 智彦 テクニカルアカウントマネージャー Amazon RDS 概要編 – RDS for DB2 概要 AWS が提供するデータベースのマネージドサービスである Amazon RDS 上で提供する RDS for Db2 の概要を説明します。RDS for Db2 での運用や高可用性構成の機能を紹介し、オンプレミス環境の Db2 から AWS 環境の RDS for Db2 へ移行した際の差異を運用面やデータベース環境面に沿って解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスや EC2 などで IBM Db2 Database を運用中の方 AWS で RDS for Db2 の利用を検討中、または今後検討予定の⽅ Amazon RDS for Db2 の概要、機能を押さえたい方 本 BlackBelt で学習できること RDS for Db2 の概要について学習いただけます。 スピーカー 野間 愛一郎 シニアソリューションアーキテクト Amazon RDS 概要編 – RDS for MariaDB 概要 AWS が提供するデータベースのマネージドサービスである Amazon RDS 上で、MariaDB の運用に際し発生する、高可用性の実現、バックアップ、レプリケーション構成などのセットアップ方法をはじめ、日々のデータベース運用を効率化する手法について、実務に即した具体的なソリューションをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスや Amazon EC2 上などで MariaDB を運用中の方 Amazon RDS for MariaDB のご利用を検討されている方 Amazon RDS for MariaDB におけるデータベース運用の効率化に興味がある方 本 BlackBelt で学習できること RDS for MariaDB の概要について学習いただけます。 スピーカー 野沢 充彦 クラウドサポートエンジニア Amazon RDS 概要編 – RDS for Oracle 概要 Amazon RDS for Oracle は、Oracle Database を AWS 環境で利用できるマネージドサービスです。Multi-AZ の構成やバックアップ・リカバリ、パフォーマンス管理といった煩雑な DBA 作業を RDS の機能で担保できるため、DBA はアプリケーションの開発やデータモデリングに専念できるようになります。こちらの動画では Amazon RDS for Oracle の概要について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスや EC2 などで Oracle Database を運用中の方 AWS で RDS for Oracle の利用を検討中、または今後検討予定の⽅ Amazon RDS for Oracle の概要、機能を押さえたい方 本 BlackBelt で学習できること RDS for Oracle の概要について学習いただけます。 スピーカー 松尾 亮 パートナーソリューション アーキテクト AWS Backup で考える DR 戦略 #2 PITR 編 AWS Backup で考える DR 戦略 #2 PITR 編 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Backup 基礎編を視聴いただいた方 AWS Backup の導入・運用において、以下の課題をお持ちの方： 頻繁に更新されるリソースの人為的ミス対策を強化したい より細かい精度でのバックアップ・復元が必要 厳格な RPO 要件でデータ損失を最小限に抑えたい AWS Backup でバックアップ・復元を実行されたことがある方 本 BlackBelt で学習できること AWS Backup における継続的バックアップとポイントインタイムリカバリについて紹介いたします。 スピーカー チャンクォックフォン クラウドサポートエンジニア 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-12 Amazon EKS x AWS アカウント アーキテクチャパターン ソリューションアーキテクト 後藤 健汰

みなさん、こんにちは。カスタマーソリューションマネージャーの西口です。2025 年 11 月 5 日に、AWS Japan が主催のコスト最適化関連イベントとなる、「AWS 秋の Cost Optimization 祭り 2025 〜最新アップデート＆メソッドと生成 AI × コスト最適化〜」を開催いたしました。ご参加いただきました皆様には、改めて御礼申し上げます。AWS Cost Optimization 祭りは去年に続き、2 回目のイベントとなります。去年の開催ブログはこちらです ( 2024秋 )。 本ブログでは、イベント内容概要の紹介とイベントの中で各登壇者が発表した資料を公開いたします。 イベント概要 「AWS 秋の Cost Optimization 祭り 2025」は、コスト最適化の最新アップデートやメソッド、生成 AI ×コスト最適化を学ぶイベントです。約70名のお客様にご参加いただき、約2時間にわたるイベントとなりました。 前半セッションでは、AWS の FinOps 最新情報セッションとしてコスト最適化フレームワークや CFM Tips 、生成 AI とコスト最適化の最新傾向をご紹介しました。続く生成 AI ×コスト最適化に関するセッションでは、具体的な例として、 Amazon Q Developer の活用方法や Well-Architected Framework Review と生成 AI を組み合わせたアプローチを解説しました。 後半セッションでは、実際のシステム開発や運用ノウハウとして、 Amazon ECS と Amazon Aurora のコスト最適化に向けたポイントや技術的アプローチについて、実践的な知見を共有しました。 各セッションの概要と発表資料は以下をご覧ください。 セッション紹介 AWS の FinOps、およびコスト最適化に関する今年のアップデート 発表資料： AWS_秋のCostOptimization祭り2025_1_AWSFinOpsコスト最適化アップデート まず、テクニカルアカウントマネージャーの堀沢から、AWS の FinOps およびコスト最適化に関する最新動向を紹介しました。FinOps とは、クラウドから得られる価値を最大化するために、組織全体が協力してデータに基づいたコスト最適化を行う取り組みです。AWS では Cloud Financial Management (CFM) というフレームワークを通じて、「可視化」「最適化」「計画・予測」「FinOps の実践」という4つの柱に沿った活動を推進しています。　2025年には、コスト最適化のための実践的なベストプラクティス集である CFM Tips の日本語対応や、自然言語でのコスト分析を可能にする MCP Server の導入、 AWS Cost Explorer での任意の2か月間のコスト比較機能など、AI 技術を活用した新機能が追加され、より効率的なコスト最適化が可能になっていることをお伝えしました。 Accelerating your FinOps with Amazon Q Developer 発表資料： AWS_秋のCostOptimization祭り2025_2_FinOpswithAmazonQDeveloper 次のセッションでは、テクニカルアカウントマネージャーの加須屋より、Amazon Q Developer を活用した FinOps の効率化と加速について解説しました。近年、FinOps の適用範囲が拡大し、AI 関連のコスト管理 (FinOps for AI) や AI を活用したコスト管理 (AI for FinOps) の重要性が高まっています。Amazon Q Developer は、コスト分析作業の効率を大幅に向上させるだけでなく、CFM フレームワークの「可視化」「最適化」「計画・予測」「FinOps の実践」の各領域で活用可能です。具体例として、AI を活用したダッシュボードの自動生成、FinOps の知識ベース構築、コスト最適化ドキュメントの分析などが紹介され、これらを通じて FinOps 全体の加速が実現できることを示しました。また、実際のデモンストレーションも実施したため、会場でご参加の皆様は具体的イメージが湧きやすかったのではないかと思います。 Context-aware cost optimization〜Gen AI x Well-Architected Framework Review〜 発表資料： AWS_秋のCostOptimization祭り2025_3_Context-awarecostoptimization 前半最後のセッションでは、テクニカルアカウントマネージャーの三田より、Well-Architected Framework Review (WAFR) を生成 AI で効率化する手法を紹介しました。コスト最適化において、明示的なコストだけでなく暗黙的なコスト (可用性不足、技術的負債など) も含めたトレードオフを考慮することが重要です。従来の WAFR は時間がかかり、範囲が限定的で一時点の評価になりがちという課題がありましたが、 Well-Architected IaC Analyzer を使用することで、数時間かかっていたレビューを数分に短縮できます。さらに、Amazon Q Developer などを活用してコンテキスト (背景情報) を生成・追加することで、より適切にトレードオフの判断が可能になり、効果的なコスト最適化を実現できることを示しました。 コンテナに移行したらコストが増えた！？ ECS のコスト最適化に向けて改めて確認したいポイント 発表資料： AWS_秋のCostOptimization祭り2025_4_ECSコスト最適化 後半の最初のセッションでは、ソリューションアーキテクトの東より、Amazon ECS のコスト最適化に関するポイントを示しました。ECS ではいくつかのコスト最適化のポイントがありますが、本セッションでは特に ①スケーリングポリシーの最適化 (カスタムメトリクスや Metrics Math の活用)、②イメージサイズの最適化 (マルチステージビルドを含む Dockerfile 記述の Tips)、③ロギング戦略の見直し ( FireLens を用いたログの振り分け)、④Capacity Provider の見直し (Spot インスタンスのフォールバックを含んだ活用例)、⑤継続的なタスクサイズの見直し ( Container Insights の活用) を取り上げています。また、新たに登場した ECS Managed Instance という選択肢についても触れ、 AWS Fargate と Amazon EC2 のメリットを両立できる新しいオプションとして紹介しました。上記に添付した資料内には当日の時間の関係上、触れられなかった内容も記載してあります。是非ダウンロードしてご覧ください。 Aurora のコスト構造を理解して最適化 〜技術的アプローチと実践〜 発表資料： AWS_秋のCostOptimization祭り2025_5_Auroraコスト最適化 最後のセッションでは、シニアテクニカルアカウントマネージャーの西原より、Amazon Aurora のコスト最適化を説明しました。Aurora のコスト最適化では Aurora のコスト構造を踏まえて Cost Explorer でコストの内訳を把握し、ワークロードに応じた最適な構成を選択することが重要です。コスト最適化の主な方法として、インスタンスのダウンサイジングやタイプの変更、リザーブドインスタンスの購入、未使用クラスタの停止などのインスタンス最適化があります。また、I/O コストが全体の 25% を超える場合は I/O 最適化インスタンスへの移行を検討することや、変動の大きいワークロードや開発環境向けには Aurora Serverless v2 の活用が効果的であり、リーダーインスタンスやセカンダリリージョンに Serverless v2 を採用する混在環境での利用も可能であることを紹介しました。 まとめ 本イベントでは、AWS FinOps の最新情報や生成 AI を使ったコスト最適化のアプローチ、ECS と Aurora のコスト最適化方法を紹介しました。本イベントにより、クラウドサービスをムダなく使いこなして、スマートに費用を抑えるコツを身につけて頂けますと幸いです。クラウドではコスト最適化に終わりはなく継続して実施することが重要です。今後もこのようなイベントを通じて、AWS からコスト最適化の情報発信を継続していきます。 本ブログは、シニアカスタマーソリューションマネージャーの西口、シニアテクニカルアカウントマネージャーの石王により執筆いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 近年、生成 AI 技術は急速な進化を遂げ、ビジネスや社会のあらゆる領域に変革をもたらしています。テキスト生成から画像作成、音声合成、コード開発支援まで、その応用範囲は日々拡大しており、多くの産業で業務効率化や新たな価値創造が実現されています。特に注目すべきは、専門性の高い領域や業界においても、生成 AI が人間の専門家を支援し、これまで解決が困難だった課題に新たなアプローチをもたらしている点です。 そのような中で、医療機器業界では、品質管理システム（QMS）の運用に関わる業務負担が大きく、人手不足が深刻な課題となっています。特に厳格な規制要件への対応や膨大な文書管理、品質イベント処理などは、多くの医療機器メーカーにとって大きな負担となっています。 今回は、この課題に着目し、AWS の生成 AI 技術である Amazon Bedrock を活用して革新的なソリューションを開発された 株式会社 Berry 様の事例をご紹介します。 Berry 様の状況と経緯 医療機器メーカーの株式会社 Berry 様は、自社での経験をもとに、品質管理業務を効率化するクラウド型 eQMS（電子品質管理システム）「 QMSmart 」を提供しています。QMSmart は、QMS 活動に必須とされる文書管理、品質イベント管理、教育訓練の機能を一気通貫で提供し、医療機器メーカーの品質管理業務を支援しています。 医療機器業界では、QMS 省令や ISO 13485 などの厳格な規制要件に準拠した品質管理が求められます。しかしながら、従来の QMS 運用では、以下の課題が存在していました。 ・医療機器特有の規制要件や品質管理手法の習得に時間がかかり、新人教育が困難 ・文書管理における不正確な情報や属人的な原因分析、進捗管理の不透明さ ・紙ベースの文書管理や Excel を使った進捗管理による業務の非効率性 これらの課題を解決するため、Berry 様は医療機器メーカーとしての経験に加え、様々なケースに対応できるよう 50 社以上の医療機器メーカーへヒアリングを行いながら AI 技術を活用したより付加価値の高い機能を開発しました。 しかし、AI 技術の導入にあたっては、いくつかの技術的な懸念がありました。医療機器という専門性の高い分野では、RAG（Retrieval-Augmented Generation）や基盤モデルのファインチューニングが必要ではないか、といった技術的ハードルを感じていらっしゃいました。また、医療機器業界の機密性の高い情報を AI で処理することへの安全性に対する懸念もありました。 このような状況の中で、Berry 様が AWS を選択された理由は次の通りです。まず、長期間にわたり AWS の各種サービスを活用してきた実績があり、その信頼性と安定性を評価されていました。既存の AWS 環境との親和性が高く、統一されたプラットフォームで開発・運用できることは、学習コストや運用コストの面で大きなメリットとなります。 また、AWS のサービスはデータ連携の親和性が高く、既存のデータベースやストレージサービスとの統合が容易です。さらに重要だったのが、セキュリティ面での信頼性です。Amazon Bedrock では、医療機器業界で求められる高いセキュリティレベルを満たしながら、安全に AI を活用できる環境を構築できます。特に Amazon Bedrock の Guardrails 機能により、プロンプトインジェクションなどの新たな攻撃手法に対しても、デフォルトの設定で十分な防御効果が得られることが後の検証で確認しました。 これらの要素が揃っていたことで、Berry 様は AWS 上で生成 AI を活用した QMS ソリューションの開発を進めることを決定しました。 ソリューション／構成内容 QMSmart の AI 機能は、インフラストラクチャの管理・運用負荷の少ないマネージドサービスで構成されています。システム構成は、QMSmart から Amazon Bedrock の基盤モデルを呼び出してレスポンスを受け取る形で実現されています。 QMSmart は、上述の課題に対し、Amazon Bedrock を活用して 3 つの AI 機能を実装しました。苦情発生から分析、CAPA（是正・予防措置）、改訂、教育まで一気通貫したプロセスの全てに AI サービスを組み込んでいます。 / ・AI 文章チェック機能 QMS 省令、ISO 13485 などの規制要件に対する文書の適合性を自動で判定し、不足している項目や改善箇所を具体的に指摘します。経験の浅い担当者でも規制対応が可能になります。 ・AI 根本原因分析支援機能 苦情報告や不適合事象が発生した際、AI によりユーザーがこれまでに登録した事例データベースから関連する事例を抽出し、パターン分析を行います。さらに「なぜなぜ分析」を支援することで根本原因まで効率的に深堀りします。実効性の高い是正措置・予防措置（CAPA）を提案し、品質問題の再発防止を実現します。 ・AI テスト生成機能 FDA 通知などの任意の文書から理解度測定のためのテスト問題を自動生成します。英文の規制文書から日本語のテスト問題を生成することも可能で、教育資料の作成時間を半日から 15 分に短縮します。 これらの機能は全て Amazon Bedrock の高度な言語理解能力と、医療機器業界特有の知識を組み合わせることで実現しています。また、当初、Berry 様では医療機器という専門性の高い分野での AI 活用には、RAG やファインチューニングが必要だと考え、検証を進めていました。しかし、Amazon Bedrock での検証を通じて、InvokeModel 実行時のシステムプロンプトの工夫により、医療機器に関して的を絞った回答を生成できることを検証で確認したことから、現行の構成に至りました。 導入効果 Amazon Bedrock を導入することで以下の2つの効果が得られました。 Berry 様側の効果 医療機器の品質管理、製造管理に関する専門的視点を組み込んだプロンプトテンプレートを実装することで、効率的なリクエスト作成と高品質な回答の取得を実現しています。これにより、RAG を使った検証に約 1 か月を要していたところを、システムプロンプトの工夫に切り替えることで、以降の開発期間を約一週間に短縮できました。 QMSmart の導入によるBerry 様の顧客企業での効果 属人的だった QMS 業務の標準化と透明性が向上し、AI 支援による意思決定の質と一貫性が高まることで、規制対応の確実性と監査対応の容易さが実現されました。 ・規制適合性の自動チェックにより業務効率を 50% 向上 ・教育資料の作成時間を半日から 15 分に短縮 ・AI による根本原因分析支援で迅速かつ的確な処置案を導出 なお、現存の AI 機能の他にも、Amazon Bedrock を活用した新機能の開発も進められており、今後もユーザーの利便性向上のために生成 AI の活用の加速が見込まれます。 お客様の声 株式会社 Berry 様からは、以下のようなコメントをいただいています。 「Amazon Bedrock を活用した AI 機能の導入により、これまで専門性が高すぎて AI では対応できないと思っていた医療機器の QMS 業務が、プロンプトエンジニアリングだけで実現できることがわかりました。特に Guardrails 機能により、医療機器業界で求められる高いセキュリティレベルを確保しながら、安心して AI を活用できるようになりました。複数のモデルを比較検証できることや、モデルの切り替え検証ができることの重要性を実感しています。変化に追随しやすいという点が、Amazon Bedrock の大きなメリットです。 開発者が体験している AI による恩恵を QMS 業務をしている人たちにも感じてもらえるようになり、業界全体の生産性向上に貢献できることを嬉しく思っています。今後は、このシステムをベースにさらなる機能拡張を計画しており、医療機器業界全体の品質管理業務の効率化に貢献していきます。」 まとめ 今回は AWS の生成 AI サービスである Amazon Bedrock を活用し、医療機器業界の QMS 業務を効率化するBerry 様の取り組みについてご紹介しました。本事例は、生成 AI の高度な言語理解能力と専門知識を組み合わせることで、規制産業における複雑な業務プロセスを改善した例です。 「AI で医療機器メーカーの人手不足を解消し、安全で高品質な医療機器の開発・製造を支援する」というビジョンのもと、Berry 様は医療機器業界の品質管理に革新をもたらしています。QMSmart は、AWS の生成 AI 技術を活用することで、医療機器業界における QMS 業務の効率化と品質向上を同時に実現しています。 人手不足が深刻化する中、AI による業務支援は今後ますます重要になるでしょう。Berry 様の取り組みは、規制産業における生成 AI 活用の先進的な事例として、多くの企業に参考になるものと考えられます。Amazon Bedrock を利用した生成 AI の活用にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください 。 ソリューションアーキテクト　古屋　楓　　 アカウントマネージャー 　ク　シイ

急速に進化するエンタープライズソフトウェアの世界において、SAP の Cloud Application Programming Model (CAP) は、Python、Node.js、Core Data Services (CDS) を使用してエンタープライズクラウドサービスとアプリケーションを開発するためのベストプラクティスを提供します。CAP は、カスタム開発の柔軟性を維持しながら SAP の広範なエコシステムと簡単に統合できる、アジャイルでマイクロサービスベースのアーキテクチャの需要の高まりに対応するフレームワークを提供します。このブログでは、Amazon Q Developer が CAP 開発をどのように加速するかを探り、ABAP コードベースのモダナイゼーションに関する 前回のブログ に基づいて説明します。SAP 開発における根本的な課題の一つは、進化するビジネス要件を満たしながらクリーンなコアシステムを維持することです。CAP は、コアを変更することなく SAP システムと統合するカスタムアプリケーションを開発できるサイドバイサイド拡張を通じてこの課題に対処します。このアプローチにより、システムの安定性が確保され、アップグレードが簡素化され、技術的負債が削減される一方で、迅速なイノベーションが可能になります。開発の合理化と統合の簡素化における CAP の利点にもかかわらず、多くの開発者、特に従来の SAP 開発パラダイムに慣れ親しんだ開発者にとって、移行は困難です。ここで Amazon Q Developer が CAP 開発体験を変革するのに役立ちます。Amazon Q Developer は、CAP の複雑さを理解するだけでなく、コンセプトから本番対応アプリケーションまでの開発プロセス全体をガイドできる AI コンパニオンです。これこそが Amazon Q Developer が SAP CAP 開発の領域で行うことです。この知的アシスタントがクラウドアプリケーションの構築方法をどのように可能にし、CAP 開発をあらゆるスキルレベルの開発者にとってアクセスしやすく、効率的で、さらには楽しいものにするかを探ってみましょう。Amazon Q Developer は、SAP Business Application Studio (BAS) の Web バージョンで拡張機能として利用できます。Visual Studio Code ユーザーの場合は、BAS 拡張機能がインストールされ、リモート SAP BTP アカウントに接続されていることを確認してください。AWS Builder ID を使用して Amazon Q Developer の無料ティアにサインインするには、この ユーザーガイド の VS Code セクションに従ってください。 AI を活用した開発ジャーニー CAP を使用してベンダー管理システムを作成するタスクを担当するシナリオを考えてみましょう。プロジェクト構造の設定、依存関係の構成、ボイラープレートコードの記述に時間を費やす代わりに、次のような会話型プロンプトを通じて Amazon Q Developer とビジョンを共有するだけです： 「私は『vendor details app』というプロジェクトを持っています。すべての指示に従ってください。サンプル CSV データを使用してベンダー（ベンダーモデル）を表示するデモ SAP CAP アプリケーションを作成したいと思います。アノテーションとサービス定義も作成してください。データ永続化のために SQLite にデプロイし、テーブルが作成され、ダミーデータが正常に作成されたことを確認してください。完了したら、モデル、データ、サービスを確認できるように私の指示を待ってください。作成したアノテーションを使用してベンダーを表示する Fiori リストページを使用して UI を作成する予定なので、UI は作成しないでください。」 Amazon Q Developer の主要な機能は、単一の自由な会話で多層的で複雑な指示を処理する方法です。このプロンプトは、アプリケーションのセットアップ、サービス定義、データモデリング、アノテーション作成、さらにはサンプルデータ生成を同時に要求しながら、UI 開発など行わないことについて明確な境界を設定する方法を示しています。フルスタック開発ワークフローのこの包括的な理解により、開発者は段階的な指示ではなく戦略的目標に集中できます。 Amazon Q Developer を際立たせるのは、そのエージェント的な性質です。コマンドに応答するだけでなく、開発プロセスに積極的に参加します。コンテキストを理解し、改善を提案したり潜在的な問題を特定したりするイニシアチブを取ることができます。このプロアクティブなアプローチと、コマンドを実行するためのターミナルへの直接アクセスにより、真の開発パートナーとなります。 プロセスが展開されるにつれて、Amazon Q Developer は、明示的なフィールドごとの仕様を必要とせずに、最も関連性の高いフィールドを自律的に決定し、データベースモデルを自律的に設計することで、ビジネスコンテキストの知的理解を実証します。サービス層の確立にシームレスに移行し、UI と RESTful エンドポイントの適切なアノテーションを作成します。 上記のプロンプトに基づいて、Amazon Q Developer の動作を見てみましょう。このデモンストレーションでは、プロジェクトの初期化から機能するアプリケーションまでの開発ジャーニー全体を目撃します。 主要なアノテーション： プロジェクト構造の初期化 ベンダーフィールドを使用した自動モデル生成 データフォルダーと CSV 作成 アノテーション付きサービス定義 データベースデプロイメントとデータ挿入 検索機能付きアプリケーションプレビュー このデモンストレーションの詳細な表示については、GIF を右クリックして新しいタブで開いてください コード生成を超える機能 Amazon Q Developer の機能は、コードの信頼性と保守性を確保するソフトウェア開発の重要な側面であるテストにまで及びます。単体テストは、統合前に各コンポーネントが分離して正しく機能することを確保し、信頼性の高いソフトウェア開発の基盤を形成します。 Amazon Q Developer は、シンプルなプロンプトを包括的なテスト戦略に変換します。 「jest を使用してテストケースを作成し、それらも実行できますか」 明示的な指示なしに、すべてのアーキテクチャ層でアプリケーションを検証する必要性を本質的に理解します： データモデルテスト：基盤レベルでのデータ整合性の確保 サービス層テスト：ビジネスロジックと操作の検証 API 統合テスト：エンドツーエンド機能の確認 テスト失敗時にエラーを報告するだけでなく、Amazon Q Developer は分析、適応、ソリューションの実装を行います。自律的な自己修復機能とコマンド実行のための統合ターミナルアクセスを通じて、従来のデバッグをインタラクティブでガイド付きのプロセスに変換します。新しいテストケースを生成するだけでなく、既存のコードのテストをリバースエンジニアリングし、レガシー（現状）と新しいコンポーネント（将来）の両方で包括的なカバレッジを確保できます。包括的なテストパートナーとして、Amazon Q Developer は詳細なカバレッジレポートとインテリジェントなエラー分析を提供し、根本原因を自動的に特定し、修正を実装します。 Amazon Q Developer がテストプロセスをどのように合理化し、複雑なテストシナリオを自律的に処理する能力を実証するかをご覧ください。 主要なアノテーション： ベンダーモデル用の異なるテストケース生成 自動エラー検出と修正 包括的なテスト実行 結果分析とレポート このデモンストレーションの詳細な表示については、GIF を右クリックして新しいタブで開いてください 開発の最も軽視されがちな側面であるドキュメンテーションが、Amazon Q Developer によって開発プロセスの不可欠な部分になります。印象的なのは、シンプルなプロンプトが包括的なドキュメンテーション戦略をトリガーする方法です。現代のアプリケーションには基本的なセットアップ指示以上のものが必要であることを本質的に理解しています。 「README ファイルを作成してください」 Amazon Q Developer がドキュメンテーションプロセスを、別の遅延したタスクではなく、開発ワークフローの不可欠な部分に変換する方法をご覧ください。 主要なアノテーション： README ファイル生成 – プロジェクトセットアップ、前提条件、構成手順 UI アノテーションガイド – Fiori レンダリング API ドキュメンテーション – サービスエンドポイント、メソッド、統合詳細 開発拡張ガイド – 機能のカスタマイズと拡張のガイドライン テスト強化ガイドライン – テストカバレッジ要件と強化アプローチ このデモンストレーションの詳細な表示については、GIF を右クリックして新しいタブで開いてください SAP クラウド開発の未来を支援 開発者がビジネス要件と革新的な機能に集中している間、Amazon Q Developer は CAP 実装の詳細の重い作業を処理します。新しい機能を追加したり、構築したばかりのベンダーアプリケーションを Cloud Foundry にデプロイしたりする必要がありますか？会話形式で説明するだけで、Amazon Q Developer がコンテキストを理解し、必要なコマンドを実行し、デプロイメント構成を作成し、SAP システム接続を確立し、Cloud Connector、Cloud Foundry 組織とスペースなどの必要な詳細を求めて、すべてのステップで手を取ってガイドしてくれます。 ブログをお読みいただき、ありがとうございました。Amazon Q Developer を CAP 開発ワークフローに組み込んでモダナイゼーションジャーニーを開始し、即座の利益を体験してください。詳細については、 ドキュメンテーション をご覧いただき、今すぐ Amazon Q Developer の無料ティアをお試しください。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに すべての企業は、開発者の生産性向上、アプリケーションのより高速な構築、レガシーコードの保守負担の軽減を支援する方法を模索しています。Amazon Q Developer は、企業が高度にカスタマイズされた SAP 環境に関連する技術的負債を解消し、新機能をより迅速に提供するのに役立つ生成 AI ツールです。このブログでは、Amazon Q Developer を使用して SAP 開発者の生産性向上とより迅速なイノベーションを支援する方法について説明します。SAP は、世界中の数千の企業のビジネス運営を支えるミッションクリティカルなアプリケーションです。長年（そして数十年）にわたって、多くのお客様は自社固有の要件を満たすために SAP をカスタマイズしてきました。これらのカスタマイゼーションを作成するために、お客様は SAP の ABAP プログラミング言語を利用して、必要なビジネス機能を提供する専用プログラムを作成してきました。ABAP プログラムは企業が SAP をビジネスに適合させるのに役立ちましたが、これにより運用とアップグレードが困難な高度にカスタマイズされた SAP 環境が生まれました。私たちは、ドキュメンテーションが不足している、または元の開発者が退職している「数十年前」に書かれた複雑な ABAP コードについてよく耳にします。現在、これらの企業がクラウドへの移行、S/4HANA を含む SAP の最新オファリングの実装、SAP が推奨する「クリーンコア」戦略（お客様がコア SAP アプリケーションを変更することなく固有の要件を満たすために SAP を拡張する）の採用を検討する中で、レガシーコードは多くの課題を提示しています。 Amazon Q Developer による SAP モダナイゼーションの簡素化 Amazon Q Developer は、企業がレガシーコードの課題を克服し、より高速で低コストの SAP アップグレードを可能にするのに役立ちます。これにより、規制遵守、セキュリティパッチ適用、新しいソフトウェア機能からの恩恵が簡素化されます。Amazon Q Developer は、レガシー ABAP コードの機能仕様と技術仕様の両方のドキュメンテーションを生成する能力があり、貴重な時間を節約できます。Amazon Q Developer は、従来の SAP ABAP、SAP ABAP RESTful Application Programming Model (RAP)、SAP Cloud Application Programming Model (CAP) を含む SAP プログラミングフレームワーク全体で動作します。Q Developer は、VS Code、Eclipse、その他複数の IDE 内で IDE 拡張機能として利用できます。Amazon Q Developer の Eclipse バージョンは、近い将来、すべての異なる ABAP オブジェクトタイプで完全に機能するようになります。他のプログラミング言語（Java、Python）で Q Developer を使用しているお客様は、開発者の生産性が最大 40% 向上し、さまざまな開発タスクが最大 80% 加速されたと報告しています。私たちは既に、ABAP 開発で同様の利益を実現している SAP のお客様（およびパートナー）からの声を聞き始めています。 Zappos.com のエンタープライズシステム担当シニアディレクターである Saul Dave 氏は次のように述べています： Amazon Q Developer は、私たちの ABAP 開発とアプリケーションサポートチームにとってゲームチェンジャーになるでしょう。 それでは、Q Developer が SAP 開発者の生産性をどのように向上させるかを示す 4 つの使用例を詳しく見てみましょう： ABAP コードの生成 BTP と Fiori アプリケーションの生成 テストケースの生成 レガシー ABAP コードのドキュメント化 使用例 #1: ABAP コードの生成 Amazon Q Developer は、自然言語プロンプトを解釈して機能的なコードを作成できます。この例では、オーダー番号とお客様番号でフィルタリングする機能を含む、オープンな販売オーダーを表示する ABAP コードが生成されます。開発者は、Q Developer に次のプロンプトを入力してコードを作成します： 「zhprp_sales_order_overview という名前の ABAP レポートを生成し、オープンな販売オーダーのリストを表示し、オーダー番号またはお客様番号（sold-to-party）でフィルタリングします。含める項目：販売オーダー番号、Sold-to-party、オーダー作成日、明細番号、材料番号、注文数量、確認数量。レコードを販売オーダー番号で並べ替えます。出力を ALV 形式で表示します。」 次の短いビデオは、プロンプトの入力と生成されたコードの出力を示しています。Q Developer チャットウィンドウは画面の右側にあります。ビデオでは、コードが SAP 内で正常に実行されていることも示されています。 使用例 #2: Fiori と BTP のコード生成 次の例は、Q Developer を使用して完全な Fiori アプリケーションを開発する方法を示しています。この例では、CDS ビュー、OData インターフェース、UI を含むフロントエンドとバックエンドコンポーネントを作成するプロセスを段階的に進める単一のプロンプトを使用します。使用されるプロンプトは次のとおりです： 「販売オーダー（作成、更新、削除）用の Fiori アプリケーションを作成するために必要なすべてのことを教えてください。そして、各ステップを作成している間、私を手助けしてください。さらに、ダミーデータを挿入するクラスと、TDD 用の CDS ビューのテストクラスも必要です。」 Amazon Q は階層化されたアプローチに従い、必要なテーブル構造が作成されるデータベース層から始まります。その後、プロセスは CDS 層に移り、基盤となるデータベーステーブルを抽象化しながらデータのビジネス指向ビューを提供するルート CDS ビューが確立されます。ビジネス層では、Amazon Q は動作実装とテストクラスを含む CDS ビューの動作定義の生成を支援します。サービス層では、OData V2 公開のためのサービス定義とバインディングの作成が含まれ、Fiori アプリケーションとバックエンド間の通信が可能になります。UI 層では、Amazon Q はメタデータ拡張を使用した UI アノテーションを支援します。開発は、manifest.json の作成、サービスバインディング、アクティベーション、パブリッシングを含むロードマップに従って続行されます。最終ステップでは、完全な Fiori アプリケーションを生成するためのカスタムコントローラーアクションと HTML UI5 コンポーネントの作成が含まれます。 使用例 #3: 単体テストケースの生成 Amazon Q Developer は、ドキュメンテーションと元の開発者が利用できない場合に、既存のコードのテストクラスの作成を支援します。ユーザーは単純にコードを Q のインラインチャットに貼り付けるだけで、包括的なテストシナリオを自動的に分析して生成します。生成されたコードの構文エラーは、ワンクリック実装で Q のインラインチャット機能を通じて迅速に修正できます。生成されたテストクラスは SAP システムですぐに利用でき、必要に応じて微調整できます。 「パブリックメソッド用の単体テストクラスを生成してください “ここにクラスロジック/詳細を提供してください”」 この機能により、開発者は複数の反復後でもビジネスロジックを簡単にテストでき、手動テストの膨大な労力を節約できます。 使用例 #4: レガシー ABAP コードのドキュメント化 次の例は、Amazon Q Developer が ABAP コードを分析し、チャットウィンドウのカスタムテンプレートに基づいて既存のコードベースと新しく作成されたコードの両方に適応してドキュメンテーションを自動生成する方法を示しています。ドキュメンテーションを PDF または Word ドキュメントに簡単に変換できます。Amazon Q Developer は、主要な情報を抽出し、一貫したフォーマット標準を維持することで、ドキュメンテーションプロセスを合理化します。この例では、次のプロンプトが使用されました： 「上記の ABAP コードの技術ドキュメンテーションを生成してください。次のポインターをテンプレートとして使用して、各コンポーネントが実行するアクションを明確に説明する非常に詳細なドキュメンテーションを提供してください： 1. クラス/プログラム名 2. クラス/プログラム概要 3. 技術仕様 3.1 データ構造 3.2 選択画面（提供されている場合） 4. 主要コンポーネント 4.1 サブルーチン/メソッド 5. テスト実装（提供されている場合） 5.1 テストメソッド 5.2 テストセットアップ 6. 技術的依存関係 7. エラーハンドリング 8. パフォーマンスの考慮事項 この機能により、組織は関連するカスタムオブジェクトによって影響を受けるビジネスプロセスを簡単に理解し、ドキュメント化でき、移行と知識移転の際に役立ちます。 上記の例からわかるように、Amazon Q Developer は SAP 開発者の手作業を削減する強力な機能を提供し、お客様がビジネスプロセスをより迅速にモダナイゼーションするのに役立ちます。お客様がこれらの機能を継続的に活用する方法を見ることを楽しみにしています。 価格モデル： Amazon Q Developer の無料ティアから始めることができます。これは、月に 50 回のチャットインタラクション、月に 5 回のソフトウェア開発支援、月に最大 1,000 行のコード変換を提供します。Pro ティアは、無料ティアのすべての機能に加えて、ユーザーとポリシーを管理するエンタープライズアクセス制御機能、提案を改善するためにコードベースに Q Developer をカスタマイズする機能、高度な機能のより高い使用制限を提供します。 詳細な価格プランを探索するにはこちらをクリック してください。 今すぐレガシー SAP コードをモダナイゼーションしましょう。 Amazon Q Developer のセットアップに関する段階的な指示については、この ワークショップ にアクセスしてください。SAP の使用例を実演し、これらやその他のシナリオの詳細な解説を提供する今後の YouTube ビデオにご注目ください。Amazon Q Developer の詳細については、 ドキュメンテーション をご覧いただくか、レガシー SAP コードのモダナイゼーションをどのように支援できるかについて話し合うために私たちのチームにお問い合わせください。 本ブログは Amazon Q Developer CLI による機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

AWS re:Invent の開催が間近に迫る中、さまざまな道のりと知識共有へのコミットメントを通じて世界中のビルダーを後押しし続けている 3 人のすばらしい AWS ヒーローをご紹介したいと思います。テクノロジー業界や地方コミュニティの女性の地位向上から、学問的専門知識と業界専門知識の橋渡し、そしてエンタープライズ AI ソリューションの開拓まで、これらのリーダーたちはコミュニティを前進させる革新的精神を実証しています。ヒーローたちのストーリーは、熱意あふれるアドボカシーやメンターシップと卓越した技術の組み合わせが、AWS のグローバルコミュニティをどのように強化するのかを浮き彫りにしています。 Dimple Vaghela 氏 – アフマダーバード、インド コミュニティヒーローである Dimple Vaghela 氏は、彼女が地域全体でのクラウド教育と技術的成長を推進する AWS User Group Ahmedabad と AWS User Group Vadodara の両方を先導しています。彼女の影響は、何千人もの学習者がクラウドキャリアを進める手助けとなってきた多数の AWS ミートアップ、ワークショップ、AWS Community Days の開催など多岐にわたります。Vaghela 氏は、地方出身の少女たちのテクノロジーキャリアを支援する「Cloud for Her」プロジェクトを立ち上げるとともに、Women in Tech India User Group の共催者も務めています。AWS re:Invent 2024 では、彼女の並外れたリーダーシップとコミュニティ貢献が認められ、オーナーシップ部門で AWS ユーザーグループリーダー賞を受賞しました。Vaghela 氏は現在も、講演、メンタリング、影響力のあるテクニカルイベントの企画を通じて、よりインクルーシブなクラウドコミュニティを構築し続けています。 Rola Dali 氏 – モントリオール、カナダ コミュニティヒーローである Rola Dali 氏は、AWS クラウドを専門とするデータ、機械学習、AI のシニアエキスパートで、神経科学とバイオインフォマティクスの博士号、およびヒトゲノムに関する専門知識に基づくユニークな視点をもたらしています。AWS Montreal User Group の共催者、そして以前の AWS コミュニティビルダーとしてのクラウドコミュニティに対するコミットメントが認められた Dali 氏は、2024 年に名誉あるゴールデンジャケット賞を受賞しました。Dali 氏は、AWS ソリューションの設計、ブログや講義を通じた知識の共有に加えて、テクノロジー業界に参入する女性、産業界へ転身する学術関係者、キャリアをスタートさせる学生のメンタリングを行うことで、テクノロジーコミュニティを積極的に形成しています。 Vivek Velso 氏 – トロント、カナダ 機械学習ヒーローである Vivek Velso 氏は、27 年を超える IT 業界経験を持つ熟練のテクノロジーリーダーであり、組織がそのクラウドインフラストラクチャを生成 AI ワークロード向けにモダナイズするための支援を専門としています。AWS に関する深い専門知識が認められ、すべての AWS 認定を修了した人のための名誉あるゴールデンジャケット賞を受賞した Velso 氏は、複数の認定試験の AWS Subject Matter Expert (SME) プログラムに積極的に貢献しています。これまで AWS コミュニティビルダーや AWS アンバサダーを務めてきた Velso 氏は、100 件を超える技術ブログ、記事、カンファレンス講演、AWS ライブストリームを通じて知識を共有し続けることで、コミュニティが自信を持ってクラウドイノベーションを取り入れるための支援を提供しています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。