1. はじめに クライオ電子顕微鏡（Cryo-EM）技術は、2017年のノーベル化学賞を受賞し、構造生物学と創薬研究に革命をもたらしました。特に構造ベース創薬（Structure-Based Drug Design: SBDD）において、Cryo-EMは標的タンパク質の三次元構造を原子レベルで解明し、その構造情報を基に効果的な化合物をデザインする上で不可欠な技術となっています。 近年、製薬業界ではCryo-EMの導入が急速に進んでいます。従来の手法では困難だった膜タンパク質や柔軟な構造を持つ標的に対しても、Cryo-EMを活用した創薬研究が世界中で推進されています。この技術により、これまで「創薬困難」とされていた標的タンパク質に対する新薬開発の可能性が大きく広がっています。 しかし、Cryo-EMによって毎日生成される数テラバイトのデータを効率的に処理することは、科学者やITシステム管理者にとって大きな課題です。これらの処理パイプラインには、スケーラブルで多様なワークロードに対応できるコンピューティング環境と、高速かつコスト効率に優れたストレージが必要です。 以前のブログ記事 では、AWS Parallel Computing Service (PCS) 上で商用ソフトウェアであるCryoSPARCを使用したCryo-EM解析環境を紹介しました。本ブログでは、オープンソースの解析ソフトウェアであるRELIONに焦点を当てます。RELIONは世界中の研究者が自由にダウンロードして利用できるため、大学や研究機関はもちろん、解析環境を新たに立ち上げたい組織にとっても導入しやすいソフトウェアです。PCS上でRELIONを動かすことで、Slurmベースの既存ワークフローをそのままクラウドに持ち込み、オンデマンドでスケールする解析環境を実現できます。 本ブログでは、セットアップ手順からジョブ実行例、コスト最適化のポイントまでを解説します。 2. Cryo-EM解析ソフトウェア RELIONの紹介 2.1 RELIONとは何か RELION（REgularised LIkelihood OptimisatioN）は、Medical Research Council (MRC)で開発されたオープンソースのクライオ電子顕微鏡画像解析ソフトウェアです。世界中の研究機関で採用されており、以下の特徴があります： 完全オープンソース : 学術的透明性と細かいパラメータ制御が可能 GUI/CLI両対応 : 対話的な処理とバッチ処理の両方をサポート RELION 5.0の主要機能 : 最新の画像処理アルゴリズムと高速化機能 2.2 解析ワークフロー概要 RELIONの解析ワークフローは、以下の主要なステップで構成されます： Motion Correction（動き補正） : 電子顕微鏡で撮像された動画の動きを補正 CTF Estimation（コントラスト伝達関数推定） : 撮像結果のデフォーカス値と非点収差を測定 Particle Picking（粒子選択） : 解析対象となる粒子を選択 2D/3D Classification（分類） : 選択した粒子を分類 3D Refinement（精密化） : 三次元構造の精密化 2.3 RELIONの処理ステップごとのCPU/GPUリソース要求の傾向 RELIONの各処理ステップは、計算特性が異なります。適切なインスタンスタイプを選択するために、処理ステップごとの違いを理解しておくことが重要になります。 CPU中心の処理 は主に以下のとおりです。 Motion Correction : RELIONの自前実装（relion_run_motioncorr）はCPUベースで動作します。マルチスレッドで並列化されており、各スレッドが独立した動画フレームを処理します。ただし、外部ツールであるMotionCor2やMotionCor3等を呼び出す場合はGPU処理も可能になります。 CTF Estimation : CTFFIND-4.1を使用したCPU処理です。MPIによる並列化で複数のマイクログラフを同時に処理できます。 Particle Picking : LoGフィルタベースの自動ピッキングはCPU処理で実行されます。テンプレートベースのピッキングはGPUによる高速化が可能です。 Bayesian Polishing : 粒子ごとの動き補正 GPU中心の処理 は主に以下のとおりです。 RELION-2以降、最も計算負荷の高いステップにGPUによる高速化が導入されています（Kimanius et al., eLife, 2016）。GPUによる高速化対象は以下の通りです： 2D Classification : 画像分類のExpectation-Maximization（EM）アルゴリズムのE-stepをGPU上で実行。CPUのみと比較して10倍以上の高速化を実現 3D Classification : 複数の3Dクラスを同時に精密化する処理。クラス数が増えるほどGPU加速の効果が大きくなります 3D Auto-refine : 高解像度精密化。フーリエ空間での参照マップの投影、差分計算、逆投影をGPU上で並列実行 GPU加速により2D/3D Classificationと高解像度Refinementが高速化されました。これにより、従来は大規模クラスターが必要だった計算が、GPUを搭載したインスタンスで短時間に完了できるようになりました。 3. アーキテクチャ概要 3.1 全体構成 図1 – AWS上のRELION解析用PCSのアーキテクチャ概要。SlurmコントローラはAWSサービスアカウントに配置され、コンピュートとストレージリソースはユーザーAWSアカウントに配置されます。クラスタにはFSx for LustreとAmazon Elastic File Store (EFS)がマウントされています。 ユーザーアクセス経路としては以下の経路でアクセスします。 ユーザー → Amazon DCV（ブラウザ/クライアント）→ Login Node → RELION GUI操作・ジョブ投入（CUIでも投入可） 今回紹介するAWS PCS + RELIONのアーキテクチャは、以下のコンポーネントで構成されています。 Amazon DCV : Login Node上のリモートデスクトップ接続 PCS Cluster : マネージドSlurmコントローラー Login Node : ユーザーアクセスポイント、DCV接続先 Compute Nodes : CPU/GPUインスタンス、自動スケーリング Amazon FSx for Lustre : 高速共有ストレージ（/shared） Amazon EFS : ホームディレクトリ（/home） Amazon S3 : 長期保存、Data Repository Association（DRA）連携 3.2 Amazon DCV Amazon DCVは、高性能リモートディスプレイプロトコルです。クラウド上のLinuxデスクトップにブラウザやネイティブクライアントから低遅延で接続できます： 低遅延接続 : H.264ベースのエンコーディングとロスレス品質ビデオ圧縮 RELIONのGUI操作に最適 : リモート環境でもローカルと同等の操作感 追加料金なし : Amazon EC2上での使用は追加ライセンス費用不要 3.3 AWS Parallel Computing Service (PCS) AWS PCSは、クラウドでハイパフォーマンスコンピューティング（HPC）クラスタを展開・管理するためのマネージドサービスです。主な利点は以下の通りです： 運用負荷の削減 : Slurmコントローラー（slurmctld）の管理が不要 自動スケーリング : ジョブに応じた計算ノードの自動起動・停止 既存ワークフローの活用 : 既存のSlurmスクリプトをそのまま利用可能 迅速な環境構築 : 約30分で計算環境の準備が完了（株式会社 豊田中央研究所の AWS re:Invent 2025での発表事例 ） 3.4 RELIONワークロードにPCSが適している理由 RELIONのようなCryo-EM解析ワークロードには、以下の理由からPCSが適していると考えます。 Slurmとの親和性 : RELIONはGUIからSlurmのsbatchコマンドでジョブを投入する設計です。PCSはネイティブにSlurmをサポートしており、既存のSlurmスクリプトやワークフローをそのまま利用できます 運用負荷の最小化 : 研究者はインフラ管理ではなく解析に集中すべきです。PCSはSlurmコントローラーの管理をAWSに委任でき、ParallelClusterと比較して運用負荷を大幅に削減できます コンテナ化不要 : AWS Batchはコンテナベースのため、RELIONや依存ライブラリ（wxWidgets、CTFFIND等）のコンテナ化が必要です。PCSではAMIにソフトウェアを事前インストールするだけで済みます GUI操作との相性 : Amazon DCVと組み合わせたGUI操作は、PCSのログインノードから直接行えます AWS ParallelClusterとPCSの比較は、AWSブログ記事「 What’s the difference between AWS ParallelCluster and AWS Parallel Computing Service? 」も参考になります。 3.5 ストレージ戦略 効率的なデータ管理のため、以下のストレージ構成としています。 FSx for Lustre : RELION作業ディレクトリ、S3 DRA連携による高速アクセス Amazon EFS : ホームディレクトリ、ソフトウェアインストール Amazon S3 : 生データ保存、処理結果の長期保存、ライフサイクル管理 3.6 S3とFSx LustreのData Repository Association (DRA) Data Repository Association (DRA)は、Amazon S3とFSx for Lustreを連携させる強力な機能です。RELIONワークロードにおいて、コスト効率と性能を両立させる鍵となります。 DRAの仕組み： DRAは、S3バケットとFSx Lustreファイルシステム間に双方向のデータ同期を確立します。1つのFSx Lustreファイルシステムに最大8つのDRAを作成でき、それぞれ異なるS3バケットまたはプレフィックスにリンクできます。 自動インポート機能： 自動インポートは、S3バケット内のオブジェクトの変更を自動的にFSx Lustreに反映します： New : S3に新しいオブジェクトが追加されたときにメタデータをインポート Changed : 既存のS3オブジェクトが変更されたときにメタデータを更新 Deleted : S3オブジェクトが削除されたときにファイルシステムから削除 推奨設定は、New + Changed + Deletedの組み合わせです。これにより、S3とFSx Lustre間で完全な同期が維持されます。 自動エクスポート機能： 自動エクスポートは、FSx Lustre上のファイル変更を自動的にS3にエクスポートします： ファイルが作成、変更、削除されると自動的にS3に反映 ファイルコンテンツの変更は、ファイルを閉じた後にエクスポート Amazon CloudWatch Logsでエクスポート失敗を監視可能 DRAについてはこちらの ユーザガイド をご確認ください。 4. セットアップと構築手順 本手順では、DLAMI + EC2 ImageBuilder方式でPCS用カスタムAMIを作成し、RELION環境を構築します。この手順は AWS HPC Recipesで紹介されている手順 です。この方法により以下の効率化が図れます。 NVIDIAドライバー/CUDAがAMIに事前インストール済み DCVがLogin NodeのUserDataに含まれるため、再起動時にもDCV構成が維持される FFTWがLaunchTemplateでインスタンス起動時にインストールされる OS: Amazon Linux 2023（Amazon Linux2023は 2029年6月30日までサポートされます ） 全ノード（GPU Login、GPU Compute、CPU Compute）で同一AMIを使用できる 手順の実行に当たっては以下の前提条件を踏まえて実行してください。 PCSをデプロイできるAWSアカウントを持っていること（使うリージョンはus-east-2リージョンとする） EC2のSSHキーペアを作成済みであること（デプロイ対象となるリージョンのus-east-2に作成済みとする） ローカルのPCにAWS CLI v2 がインストール済みであること 4.1 DLAMI ImageBuilderでカスタムAMI作成 4.1.1 ImageBuilderスタックのデプロイ HPC Recipes for AWSの DLAMI for PCS レシピを使用して、ImageBuilderパイプラインをデプロイします。ここではAWS CloudFormationを使ってデプロイします。 aws cloudformation create-stack \ --region us-east-2 \ --capabilities CAPABILITY_IAM \ --stack-name dlami-for-pcs \ --template-url https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs/dlami_for_pcs_imagebuilder/assets/dlami-for-pcs.yaml \ --parameters \ ParameterKey=BuildSchedule,ParameterValue=Manual \ ParameterKey=PublishToSsm,ParameterValue=true \ ParameterKey=SsmParameterPrefix,ParameterValue=/dlami-for-pcs # 完了待機（約5-10分） aws cloudformation wait stack-create-complete --stack-name dlami-for-pcs --region us-east-2 4.1.2 AMIビルドの実行 AmazonLinux2023のイメージを作成可能なAL2023 x86_64パイプラインを実行します。 # パイプラインARNを取得 PIPELINE_ARN=$(aws cloudformation describe-stacks \ --region us-east-2 \ --stack-name dlami-for-pcs \ --query "Stacks[0].Outputs[?OutputKey=='PipelineAl2023X8664Arn'].OutputValue" \ --output text) # ビルド開始（約25分程度時間がかかります） aws imagebuilder start-image-pipeline-execution \ --image-pipeline-arn ${PIPELINE_ARN} \ --region us-east-2 4.1.3 ビルド済みAMI IDの取得 # ビルド完了後、AMI IDを取得 DLAMI_AMI_ID=$(aws ec2 describe-images \ --owners self \ --filters "Name=name,Values=dlami-for-pcs-base-al2023-x86_64*" \ --query 'reverse(sort_by(Images, &CreationDate))[0].ImageId' \ --output text --region us-east-2) echo "DLAMI AMI ID: ${DLAMI_AMI_ID}" このAMIには以下が事前インストールされています： NVIDIAドライバー + CUDA（DLAMIベース） AWS PCS Agent Slurm 24.11 + 25.05（PATHはSlurm 25.05を優先するようLaunchTemplateの設定箇所で指定） EFS Utils CloudWatch Agent AWS System Manager Agent（SSM Agent） 4.2 PCSクラスターの作成 HPC Recipes for AWSの Getting Started テンプレートを使用して、PCSクラスターの基盤をデプロイします。上記テンプレートは、VPC、サブネット、EFS、FSx for Lustre、PCS Cluster、IAM、Security Groupsなどの基盤リソースを一括作成します。デフォルト設定ではデモ用のLogin Node（c6i.xlarge）とCompute Node（c6i.xlarge、demoキュー）が作成されますが、今回作成するRELION環境ではGPU付きのLogin NodeとGPU/CPUコンピュートノードも作成します。次のステップで、RELION向けにノードグループとキューを追加で作成します。 AWS PCSはマネージドコンソールで「パラレルコンピューティングサービス」というサービス名で画面にアクセスできます。 4.2.1 コンソールからのデプロイする場合（ワンクリック） Launch Stack (us-east-2) パラメータ設定： SlurmVersion : 25.05 （最新のサポートバージョンを推奨。24.11は2026年5月31日にEOL。 サポートバージョン一覧 を参照） ManagedAccounting : enabled （Slurm Accountingを有効化。 sacct コマンドでジョブ履歴・リソース使用量を確認でき、トラブルシューティングやコスト分析に有用です） NodeArchitecture : x86 KeyName : 事前に作成したSSHキーペア名( my-keypair ) ClientIpCidr : ご利用されている環境下でのクライアント側のパブリックIP（ aa.bb.cc.dd/32 ） 機能と変換箇所で、チェックを入れて、「スタックの作成」をクリックするとCloudFormationがデプロイされます。 4.2.2 AWS CLIからデプロイする場合 YOUR_KEY_NAMEに事前に作成したSSHキーペア名を代入してください。YOUR_IPにはClientIpCidrと同じクライアント側のパブリックIPを指定してください。 export YOUR_KEY_NAME="my-keypair" export YOUR_IP="aa.bb.cc.dd" aws cloudformation create-stack \ --stack-name pcs-relion \ --template-url https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs/getting_started/assets/cluster.yaml \ --parameters \ ParameterKey=SlurmVersion,ParameterValue=25.05 \ ParameterKey=ManagedAccounting,ParameterValue=enabled \ ParameterKey=NodeArchitecture,ParameterValue=x86 \ ParameterKey=KeyName,ParameterValue=${YOUR_KEY_NAME} \ ParameterKey=ClientIpCidr,ParameterValue=${YOUR_IP}/32 \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \ --region us-east-2 # 完了待機（約25分） aws cloudformation wait stack-create-complete --stack-name pcs-relion --region us-east-2 4.2.3 CloudFormation出力値の取得（AWS CLIを使用） デプロイされたCloudFormationのスタックが作成完了した後、以降の手順で使用するリソースIDを取得します。CloudFormationコンソールの「出力」タブでも確認できますが、以下のAWS CLIで確認ができます。あとのコマンド実行のパラメータとしてもここで設定した変数を利用します。以降の処理を行う場合はAWS CLIでコマンドを実行してください。 # PCSクラスターID CLUSTER_ID=$(aws cloudformation describe-stacks --stack-name pcs-relion \ --query "Stacks[0].Outputs[?OutputKey=='ClusterId'].OutputValue" \ --output text --region us-east-2) # ネストスタックからリソースIDを取得するヘルパー関数 get_nested_output() { local nested_id=$(aws cloudformation describe-stack-resource \ --stack-name pcs-relion --logical-resource-id "$1" \ --query "StackResourceDetail.PhysicalResourceId" \ --output text --region us-east-2) aws cloudformation describe-stacks --stack-name "$nested_id" \ --query "Stacks[0].Outputs[?OutputKey=='$2'].OutputValue" \ --output text --region us-east-2 } # 各リソースID VPC_ID=$(get_nested_output "Networking" "VPC") PUBLIC_SUBNET_ID=$(get_nested_output "Networking" "DefaultPublicSubnet") PRIVATE_SUBNET_ID=$(get_nested_output "Networking" "DefaultPrivateSubnet") EFS_ID=$(get_nested_output "EfsStorage" "EFSFilesystemId") FSX_ID=$(get_nested_output "FSxLStorage" "FSxLustreFilesystemId") FSX_MOUNT_NAME=$(get_nested_output "FSxLStorage" "FSxLustreMountName") CLUSTER_SG_ID=$(get_nested_output "PCSSecurityGroup" "ClusterSecurityGroupId") SSH_SG_ID=$(get_nested_output "PCSSecurityGroup" "InboundSshSecurityGroupId") INSTANCE_PROFILE_ARN=$(get_nested_output "PCSInstanceProfile" "InstanceProfileArn") COMPUTE_LT_ID=$(get_nested_output "PCSLaunchTemplate" "ComputeLaunchTemplateId") LOGIN_LT_ID=$(get_nested_output "PCSLaunchTemplate" "LoginLaunchTemplateId") # VPCデフォルトSG VPC_DEFAULT_SG=$(aws ec2 describe-security-groups \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=group-name,Values=default" \ --query "SecurityGroups[0].GroupId" --output text --region us-east-2) # EFS/FSx SG（ネストスタックから取得） EFS_SG=$(get_nested_output "EfsStorage" "SecurityGroupId") FSX_SG=$(get_nested_output "FSxLStorage" "FSxLustreSecurityGroupId") echo "CLUSTER_ID=${CLUSTER_ID}" echo "PUBLIC_SUBNET_ID=${PUBLIC_SUBNET_ID}" echo "PRIVATE_SUBNET_ID=${PRIVATE_SUBNET_ID}" echo "EFS_ID=${EFS_ID}" echo "FSX_ID=${FSX_ID}" echo "FSX_MOUNT_NAME=${FSX_MOUNT_NAME}" 4.3 GPU Login Node + GPU/CPUコンピュートノードグループの追加 Getting Started テンプレートで作成されたデフォルトのLogin Node（c6i.xlarge）とCompute Node（c6i.xlarge、 demo キュー）とは別にRELIONの実行環境に適したGPUを搭載したLoginNodeやCPUとGPUのComputeNodeを作成します。 Login Node（GPU） : g6.xlarge（L4 GPU搭載。DCVをGPU対応で稼働 + RELION GPUビルドで用いる） GPU Compute Node : g6e.4xlarge（L40S GPU、 gpu-queue 。2D/3D Classification等のGPU処理用） CPU Compute Node : c7i.4xlarge（ cpu-queue 。Motion Correction、CTF Estimation等のCPU処理用） デフォルトの login 、 compute-1 ノードグループと demo キューは削除 Launch Templateの作成 Compute用UserData（GPU/CPU共通） DLAMIにはNVIDIAドライバー/CUDAが事前インストール済みのため、UserDataで設定するものはEFS/FSxのマウントとFFTWやlustre-clientのパッケージのインストールになります。 cat > compute-userdata.txt <<EOF MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 packages: - amazon-efs-utils - lustre-client - fftw - fftw-libs - fftw-devel - ghostscript runcmd: - mkdir -p /tmp/home - rsync -aA /home/ /tmp/home - echo "${EFS_ID}:/ /home efs tls,_netdev" >> /etc/fstab - mount -a -t efs defaults - rsync -aA --ignore-existing /tmp/home/ /home - rm -rf /tmp/home/ - mkdir -p /shared - chmod a+rwx /shared - mount -t lustre ${FSX_ID}.fsx.us-east-2.amazonaws.com@tcp:/${FSX_MOUNT_NAME} /shared - chmod 777 /shared - echo 'export PATH=/opt/aws/pcs/scheduler/slurm-25.05/bin:$PATH' > /etc/profile.d/slurm-version.sh --==MYBOUNDARY== EOF Login GPU用UserData（DCV含む） Login NodeのUserDataにはDCVインストールも含めます。これによりログインノード再起動時にもDCVが維持されます。 cat > login-gpu-userdata.txt <<EOF MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 packages: - amazon-efs-utils - lustre-client - fftw - fftw-libs - fftw-devel - cmake - git - wget - environment-modules - libtiff-devel - libpng-devel - gtk3-devel - mesa-libGL-devel - mesa-libGLU-devel - libXft-devel - libX11-devel - ghostscript runcmd: # Development Tools group install - dnf groupinstall -y "Development Tools" # EFS/FSx mount - mkdir -p /tmp/home - rsync -aA /home/ /tmp/home - echo "${EFS_ID}:/ /home efs tls,_netdev" >> /etc/fstab - mount -a -t efs defaults - rsync -aA --ignore-existing /tmp/home/ /home - rm -rf /tmp/home/ - mkdir -p /shared - chmod a+rwx /shared - mount -t lustre ${FSX_ID}.fsx.us-east-2.amazonaws.com@tcp:/${FSX_MOUNT_NAME} /shared - chmod 777 /shared # Slurm 25.05 PATH priority - echo 'export PATH=/opt/amazon/openmpi/bin:/opt/aws/pcs/scheduler/slurm-25.05/bin:$PATH' > /etc/profile.d/slurm-version.sh - echo 'export LD_LIBRARY_PATH=/opt/amazon/openmpi/lib64:${LD_LIBRARY_PATH:-}' >> /etc/profile.d/slurm-version.sh # Software directory setup - mkdir -p /home/software/apps /home/software/src /home/software/modulefiles - chown -R ec2-user:ec2-user /home/software # DCV installation (AL2023) - dnf groupinstall -y "Desktop" - dnf install -y glx-utils - systemctl set-default graphical.target # Wayland無効化（X11モードに強制） - sed -i '/\[daemon\]/a WaylandEnable=false' /etc/gdm/custom.conf # NVIDIA Xorg設定（GPUレンダリング有効化） - nvidia-xconfig --preserve-busid --enable-all-gpus # DCV パッケージインストール - rpm --import https://d1uj6qtbmh3dt5.cloudfront.net/NICE-GPG-KEY - cd /tmp && wget -q https://d1uj6qtbmh3dt5.cloudfront.net/nice-dcv-el9-x86_64.tgz && tar -xzf nice-dcv-el9-x86_64.tgz && cd nice-dcv-*-el9-x86_64 && dnf install -y nice-dcv-server-*.rpm nice-dcv-web-viewer-*.rpm nice-xdcv-*.rpm - | cat > /etc/dcv/dcv.conf << 'DCVCONF' [session-management] create-session = true [session-management/automatic-console-session] owner = "ec2-user" [display] target-fps = 30 [connectivity] enable-quic-frontend = true idle-timeout = 0 [security] authentication = "system" DCVCONF - echo "ec2-user:dcvpassword" | chpasswd # Skip Initial GNOME setup - mkdir -p /home/ec2-user/.config - echo 'yes' > /home/ec2-user/.config/gnome-initial-setup-done - chown -R ec2-user:ec2-user /home/ec2-user/.config - systemctl enable gdm && systemctl start gdm - systemctl enable dcvserver && systemctl restart dcvserver --==MYBOUNDARY== EOF ec2-userのパスワードは検証用に簡単なものを付けています。お使いになる環境条件を考慮頂き、必要に応じて強固なパスワードに変更してください。 Launch Template作成 # Compute用UserDataをファイルに保存してBase64エンコード COMPUTE_USERDATA_B64=$(cat compute-userdata.txt | base64) # Login GPU用UserDataをファイルに保存してBase64エンコード LOGIN_USERDATA_B64=$(cat login-gpu-userdata.txt | base64) # Compute Launch Template（GPU/CPU共通、Private Subnet用） COMPUTE_LT_ID=$(aws ec2 create-launch-template \ --launch-template-name "compute-dlami-pcs-relion" \ --launch-template-data "{ \"TagSpecifications\": [{\"ResourceType\": \"instance\", \"Tags\": [{\"Key\": \"HPCRecipes\", \"Value\": \"true\"}]}], \"MetadataOptions\": {\"HttpEndpoint\": \"enabled\", \"HttpPutResponseHopLimit\": 4, \"HttpTokens\": \"required\"}, \"SecurityGroupIds\": [\"${VPC_DEFAULT_SG}\", \"${CLUSTER_SG_ID}\", \"${EFS_SG}\", \"${FSX_SG}\"], \"UserData\": \"${COMPUTE_USERDATA_B64}\" }" \ --query "LaunchTemplate.LaunchTemplateId" \ --output text --region us-east-2) # Login GPU Launch Template（Public Subnet用、SSH SG + KeyName + DCV付き） LOGIN_LT_ID=$(aws ec2 create-launch-template \ --launch-template-name "login-gpu-dlami-pcs-relion" \ --launch-template-data "{ \"TagSpecifications\": [{\"ResourceType\": \"instance\", \"Tags\": [{\"Key\": \"HPCRecipes\", \"Value\": \"true\"}]}], \"MetadataOptions\": {\"HttpEndpoint\": \"enabled\", \"HttpPutResponseHopLimit\": 4, \"HttpTokens\": \"required\"}, \"KeyName\": \"${YOUR_KEY_NAME}\", \"SecurityGroupIds\": [\"${VPC_DEFAULT_SG}\", \"${CLUSTER_SG_ID}\", \"${SSH_SG_ID}\", \"${EFS_SG}\", \"${FSX_SG}\"], \"UserData\": \"${LOGIN_USERDATA_B64}\" }" \ --query "LaunchTemplate.LaunchTemplateId" \ --output text --region us-east-2) ${YOUR_KEY_NAME} は登録済みのキーペア名を指定してください。 NodeGroup + キュー作成 全ノードでDLAMI AMI（ ${DLAMI_AMI_ID} ）を使用します。 # GPU Login NodeGroup (g6.xlarge) aws pcs create-compute-node-group \ --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-name login-gpu \ --ami-id ${DLAMI_AMI_ID} \ --subnet-ids ${PUBLIC_SUBNET_ID} \ --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \ --scaling-configuration "minInstanceCount=1,maxInstanceCount=1" \ --instance-configs '[{"instanceType":"g6.xlarge"}]' \ --custom-launch-template "id=${LOGIN_LT_ID},version=1" \ --region us-east-2 # login-gpuのNodeGroupがACTIVEになるまで待機 # GPU Compute NodeGroup (g6e.4xlarge) aws pcs create-compute-node-group \ --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-name gpu-nodes \ --ami-id ${DLAMI_AMI_ID} \ --subnet-ids ${PRIVATE_SUBNET_ID} \ --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \ --scaling-configuration "minInstanceCount=0,maxInstanceCount=4" \ --instance-configs '[{"instanceType":"g6e.4xlarge"}]' \ --custom-launch-template "id=${COMPUTE_LT_ID},version=1" \ --region us-east-2 # CPU Compute NodeGroup (c7i.4xlarge) - 同じDLAMI AMI + 同じCompute LT aws pcs create-compute-node-group \ --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-name cpu-nodes \ --ami-id ${DLAMI_AMI_ID} \ --subnet-ids ${PRIVATE_SUBNET_ID} \ --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \ --scaling-configuration "minInstanceCount=0,maxInstanceCount=4" \ --instance-configs '[{"instanceType":"c7i.4xlarge"}]' \ --custom-launch-template "id=${COMPUTE_LT_ID},version=1" \ --region us-east-2 # gpu-nodesとcpu-nodesのNodeGroupがACTIVEになるまで待機 # 作成したNodeGroupのIDを取得 GPU_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='gpu-nodes'].id" --output text --region us-east-2) CPU_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='cpu-nodes'].id" --output text --region us-east-2) # キュー作成 aws pcs create-queue --cluster-identifier ${CLUSTER_ID} --queue-name gpu-queue \ --compute-node-group-configurations "[{\"computeNodeGroupId\":\"${GPU_NG_ID}\"}]" --region us-east-2 aws pcs create-queue --cluster-identifier ${CLUSTER_ID} --queue-name cpu-queue \ --compute-node-group-configurations "[{\"computeNodeGroupId\":\"${CPU_NG_ID}\"}]" --region us-east-2 gpu-queueとcpu-queueキューがアクティブになるまで少し待ちます。 （オプション）デフォルトリソースの削除 RELION実行用に新しいNodeGroupとキューが作成できたのちに、Getting Started Templateで作成されたデフォルトリソースは今回不要となるのでリソースを削除します。本手順の実行はオプションです。 # デフォルトリソースのID取得 DEMO_QUEUE_ID=$(aws pcs list-queues --cluster-identifier ${CLUSTER_ID} \ --query "queues[?name=='demo'].id" --output text --region us-east-2) COMPUTE1_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='compute-1'].id" --output text --region us-east-2) OLD_LOGIN_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='login'].id" --output text --region us-east-2) # demoキュー削除（キューを先に削除してからNodeGroupを削除します） aws pcs delete-queue --cluster-identifier ${CLUSTER_ID} \ --queue-identifier ${DEMO_QUEUE_ID} --region us-east-2 # demoキューが削除されるまで少し待ってから以下を実行してください。 # compute-1コンピュートノードグループ削除 aws pcs delete-compute-node-group --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-identifier ${COMPUTE1_NG_ID} --region us-east-2 # loginコンピュートノードグループ削除 aws pcs delete-compute-node-group --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-identifier ${OLD_LOGIN_NG_ID} --region us-east-2 # 削除確認（login-gpu, cpu-nodes, gpu-nodes の3つだけ残っていればOK） aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[].name" --output text --region us-east-2 4.4 Amazon DCVのセキュリティグループ設定 セキュリティグループにDCVポートを追加します（TCP + UDP。UDPはQUICプロトコルによる低遅延ストリーミングに使用します）。 ${YOUR_IP}/32 はクラスター作成時に指定したClientIpCidrと同じパブリックIPを使用してください： aws ec2 authorize-security-group-ingress --group-id ${SSH_SG_ID} \ --protocol tcp --port 8443 --cidr ${YOUR_IP}/32 --region us-east-2 aws ec2 authorize-security-group-ingress --group-id ${SSH_SG_ID} \ --protocol udp --port 8443 --cidr ${YOUR_IP}/32 --region us-east-2 DCVへのアクセス確認 ブラウザで https://<LOGIN_GPU_NODE_IP>（login-gpuで作成したインスタンスに付与されているグローバルアドレス）:8443 にアクセスし、 ec2-user / dcvpassword でDCVにログインができるか確認をしてください。ブラウザ上証明書の警告が表示されますが、確認をしながらアクセスを進めてください。 4.5 RELIONと依存ライブラリのインストール RELIONのビルドにはPCS AMIにプリインストールされたOpenMPI（/opt/amazon/openmpi/）を使用します。 # LOGIN NODEにSSHでログインします。 ssh -i "${YOUR_KEY_NAME}が置かれている絶対パス" ec2-user@${LOGIN_NODE_IP} # wxWidgets 3.2.5（CTFFIND用。ビルドに9分弱時間が掛かる） cd /home/software/src wget https://github.com/wxWidgets/wxWidgets/releases/download/v3.2.5/wxWidgets-3.2.5.tar.bz2 tar -xjf wxWidgets-3.2.5.tar.bz2 && cd wxWidgets-3.2.5 cd build ../configure --prefix=/home/software/apps/wxWidgets-3.2.5 --with-gtk=3 --enable-unicode --disable-shared make -j$(nproc) && make install # CTFFIND 4.1.14 cd /home/software/src wget https://grigoriefflab.umassmed.edu/sites/default/files/ctffind-4.1.14.tar.gz -O ctffind-4.1.14.tar.gz tar -xzf ctffind-4.1.14.tar.gz && cd ctffind-4.1.14 # CTFFIND 4.1.14ではソースの一部でbool型で宣言されているにもかかわらずreturn文がなく、 # C++の未定義動作によりSegmentation Faultが発生します。 # この問題はCTFFIND開発者フォーラムで報告され、開発版では修正済みであることが確認されています。 # 参照: https://grigoriefflab.umassmed.edu/forum/software/ctffind_ctftilt/ctffind_4114_segfault sed -i 's/^bool ComputeRotationalAverageOfPowerSpectrum/void ComputeRotationalAverageOfPowerSpectrum/' src/programs/ctffind/ctffind.cpp sed -i 's/^bool RescaleSpectrumAndRotationalAverage/void RescaleSpectrumAndRotationalAverage/' src/programs/ctffind/ctffind.cpp # ビルド（OpenMP有効化を指定、ビルドに1分弱時間が掛かる） mkdir build && cd build ../configure --prefix=/home/software/apps/ctffind-4.1.14 \ --with-wx-config=/home/software/apps/wxWidgets-3.2.5/bin/wx-config \ --enable-openmp --disable-debugmode \ CXXFLAGS="-O2 -fopenmp -Wall -pipe" \ LDFLAGS="-L/home/software/apps/wxWidgets-3.2.5/lib -lgomp" make -j$(nproc) && make install # RELION 5.0 GPUビルド（ビルドに9分弱時間が掛かる） cd /home/software/src && git clone https://github.com/3dem/relion.git cd relion && git checkout ver5.0 mkdir build-gpu && cd build-gpu cmake .. -DCMAKE_INSTALL_PREFIX=/home/software/apps/relion-gpu-5.0 \ -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DGUI=ON -DCUDA=ON \ -DCUDA_ARCH=89 \ -DFETCH_WEIGHTS=OFF \ -DMPI_C_COMPILER=/opt/amazon/openmpi/bin/mpicc \ -DMPI_CXX_COMPILER=/opt/amazon/openmpi/bin/mpicxx make -j$(nproc) && make install # RELION 5.0 CPUビルド（ビルドに6分弱時間が掛かる） cd /home/software/src/relion mkdir build-cpu && cd build-cpu cmake .. -DCMAKE_INSTALL_PREFIX=/home/software/apps/relion-cpu-5.0 \ -DGUI=ON -DCUDA=OFF \ -DFETCH_WEIGHTS=OFF \ -DMPI_C_COMPILER=/opt/amazon/openmpi/bin/mpicc \ -DMPI_CXX_COMPILER=/opt/amazon/openmpi/bin/mpicxx make -j$(nproc) && make install 4.5.1 Environment Modulesの設定 RELIONのGPU/CPUビルド版をEnvironment Modulesで切り替えるためのmodulefileを作成します。 # relion/gpu modulefile mkdir -p /home/software/modulefiles/relion cat > /home/software/modulefiles/relion/gpu <<'MODEOF' #%Module1.0 proc ModulesHelp { } { puts stderr "RELION 5.0 GPU build (CUDA enabled)" } module-whatis "RELION 5.0 GPU build" conflict relion set basedir /home/software/apps/relion-gpu-5.0 prepend-path PATH $basedir/bin prepend-path LD_LIBRARY_PATH $basedir/lib prepend-path PATH /home/software/apps/ctffind-4.1.14/bin prepend-path PATH /opt/amazon/openmpi/bin prepend-path LD_LIBRARY_PATH /opt/amazon/openmpi/lib64 prepend-path PATH /usr/local/cuda/bin prepend-path LD_LIBRARY_PATH /usr/local/cuda/lib64 setenv RELION_CTFFIND_EXECUTABLE /home/software/apps/ctffind-4.1.14/bin/ctffind MODEOF # relion/cpu modulefile cat > /home/software/modulefiles/relion/cpu <<'MODEOF' #%Module1.0 proc ModulesHelp { } { puts stderr "RELION 5.0 CPU build (no CUDA)" } module-whatis "RELION 5.0 CPU build" conflict relion set basedir /home/software/apps/relion-cpu-5.0 prepend-path PATH $basedir/bin prepend-path LD_LIBRARY_PATH $basedir/lib prepend-path PATH /home/software/apps/ctffind-4.1.14/bin prepend-path PATH /opt/amazon/openmpi/bin prepend-path LD_LIBRARY_PATH /opt/amazon/openmpi/lib64 setenv RELION_CTFFIND_EXECUTABLE /home/software/apps/ctffind-4.1.14/bin/ctffind MODEOF # MODULEPATHを~/.bashrcに追加 echo 'export MODULEPATH=/home/software/modulefiles:${MODULEPATH:-}' >> ~/.bashrc source ~/.bashrc これで以下のコマンドでGPU/CPUビルドを切り替えられます： module load relion/gpu # GPU処理（2D/3D Classification, Refinement） module load relion/cpu # CPU処理（Motion Correction, CTF Estimation） # EC2からログアウト exit 4.6 FSx for Lustreスループット調整とDRA作成（オプション） このセクションはオプションです。FSx for Lustreのスループット調整とS3 Data Repository Association（DRA）は、RELIONの実行自体には必須ではありません。Getting Started Templateで作成されたFSx for Lustre（デフォルト125 MB/s/TiB）のままでもRELIONジョブは正常に動作します。大規模データセットの処理やS3との双方向同期が必要な場合に設定が必要となるので、参考の手順として示します。 # スループット更新（125 → 250 MB/s/TiB、変更完了まで時間が掛かる） aws fsx update-file-system --file-system-id ${FSX_ID} \ --lustre-configuration PerUnitStorageThroughput=250 --region us-east-2 # FSxのコンソール画面で、Lustreの該当ファイルシステムのライフサイクルの状態が「更新中」になります。それが完了するまで待つこと。 # S3バケット作成 AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) aws s3 mb s3://pcs-relion-data-${AWS_ACCOUNT_ID} --region us-east-2 # DRA作成（双方向同期） aws fsx create-data-repository-association \ --file-system-id ${FSX_ID} \ --file-system-path /shared/data \ --data-repository-path s3://pcs-relion-data-${AWS_ACCOUNT_ID}/datasets/ \ --s3 '{"AutoImportPolicy":{"Events":["NEW","CHANGED","DELETED"]},"AutoExportPolicy":{"Events":["NEW","CHANGED","DELETED"]}}' \ --batch-import-meta-data-on-create --region us-east-2 4.7 CloudWatch監視設定（オプション） このセクションもオプションです。CloudWatch監視はRELIONの実行には必須ではありませんが、Slurmスケジューラーのログ確認やDRA同期状態の監視に有用です。 PCS Scheduler / Job Completion ログ HPC Recipesの CloudWatch Log Delivery テンプレートを使用して、PCSのScheduler LogsとJob Completion LogsをCloudWatchに送信します。これにより、Slurmスケジューラーの動作ログとジョブ完了ログをCloudWatchコンソールから確認できます。 aws cloudformation create-stack \ --stack-name pcs-relion-cloudwatch-logs \ --template-url https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs/cloudwatch/assets/cloudwatch_log_delivery.cfn.yaml \ --parameters ParameterKey=PCSClusterId,ParameterValue=${CLUSTER_ID} \ --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \ --region us-east-2 作成されるCloudWatch LogGroup： /aws/vendedlogs/pcs/cluster/PCS_SCHEDULER_LOGS/<CLUSTER_ID> /aws/vendedlogs/pcs/cluster/PCS_JOBCOMP_LOGS/<CLUSTER_ID> 5. ジョブ実行例 5.1 テストデータセットの準備 RELION 5.0公式チュートリアルのテストデータ（beta-galactosidase、EMPIAR-10204）を使用します。 # LOGIN NODEにSSHでログインします。 ssh -i "${YOUR_KEY_NAME}が置かれている絶対パス" ec2-user@${LOGIN_NODE_IP} mkdir -p /shared/relion-test && cd /shared/relion-test wget ftp://ftp.mrc-lmb.cam.ac.uk/pub/scheres/relion30_tutorial_data.tar tar -xf relion30_tutorial_data.tar rm -f relion30_tutorial_data.tar 展開後、 /shared/relion-test/relion30_tutorial/Movies/ にテストデータ（.tiffファイル）が配置されます。 5.2 Importジョブの実行 RELIONでは最初にImportジョブを実行して、動画ファイルのパスとoptics情報をSTARファイルに登録する必要があります。RELION 5.0ではopticsグループ（電圧、球面収差、ピクセルサイズ等）がSTARファイルに必須です。 module load relion/cpu cd /shared/relion-test mkdir -p Import/job001 relion_import --do_movies --optics_group_name opticsGroup1 \ --angpix 0.885 --kV 200 --Cs 1.4 --Q0 0.1 \ --beamtilt_x 0 --beamtilt_y 0 \ --i "relion30_tutorial/Movies/*.tiff" \ --odir Import/job001/ --ofile movies.star パラメータはRELION公式チュートリアルデータ（EMPIAR-10204、beta-galactosidase）の撮像条件に基づいています： --angpix 0.885 : ピクセルサイズ（Å/pixel） --kV 200 : 加速電圧（kV） --Cs 1.4 : 球面収差（mm） --Q0 0.1 : 振幅コントラスト比 Import/job001 以下にmovies.starファイルが作成されていれば処理は成功しています。 5.3 Motion Correctionの実行 5.3.1 RELION GUIからのジョブ投入 Amazon DCV経由でLoginNodeにログイン後、以下のコマンドでRELIONのGUI画面が表示されます。 # DCV経由でLogin Nodeに接続後 source ~/.bashrc module load relion/cpu cd /shared/relion-test relion & GUIでジョブを投入する場合、あらかじめSubmission.shを作成しておく必要があります。以下のコマンドでTemplateのシェルスクリプトを作成しておきます（CPU queueに投げる場合のsubmission.shです）。 cat > /home/software/apps/relion-submission.sh << 'EOF' #!/bin/bash #SBATCH --ntasks=XXXmpinodesXXX #SBATCH --cpus-per-task=XXXthreadsXXX #SBATCH --time=24:00:00 #SBATCH --partition=XXXqueueXXX #SBATCH --job-name=XXXnameXXX #SBATCH --output=XXXoutfileXXX #SBATCH --error=XXXerrfileXXX source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:${MODULEPATH:-} module purge module load relion/cpu export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK} export OMPI_MCA_rmaps_base_mapping_policy=slot:PE=${SLURM_CPUS_PER_TASK} export OMPI_MCA_hwloc_base_binding_policy=core if [ ${SLURM_NTASKS} -gt 1 ]; then mpirun -np ${SLURM_NTASKS} XXXcommandXXX else XXXcommandXXX fi EOF chmod +x /home/software/apps/relion-submission.sh RELION GUI経由でPCSにジョブを投入する場合は、各処理プロセスのRunningタブで以下を設定する必要があります。 Queue name : gpu-queue （GPU処理）または cpu-queue （CPU処理） Submit to queue? : Yesに変更する 参考例としてGUIによる実行例を示します。Motion correctionの処理をGUIから行う場合です。 Input movies STAR file:に「Import/job001/movies.star」を指定する Runningタブを選択し、以下の項目を変更します。 項目 設定値 Number of MPI procs 2 Number of threads 4 Submit to queue? Yes Queue name cpu-queue Queue submit command sbatch Standard submission script /home/software/apps/relion-submission.sh 変更後「Run!」でPCSにジョブが投入されます。 他の解析処理も同様のGUI操作でPCSにジョブが投入可能です。以降のRELIONのサンプル実行はCUIベースで説明しますが、同じ処理をGUIでも行うことができます。使いやすい方を選び処理を実行してください。 5.3.2 CUIによるMotion Correctionの実行例（CPUキューでの実行） Motion Correctionはデフォルトの状態ではCPUで行われる処理になっています。今回の場合は cpu-queue に投入してください。 sbatch --partition=cpu-queue --nodes=1 --ntasks=2 --cpus-per-task=4 \ --time=02:00:00 --job-name=relion_motioncorr \ --wrap=" source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:\${MODULEPATH:-} module load relion/cpu cd /shared/relion-test mkdir -p MotionCorr/job002 export OMP_NUM_THREADS=\$SLURM_CPUS_PER_TASK BIND_OPTS='--map-by slot:PE='\$SLURM_CPUS_PER_TASK' --bind-to core' mpirun \$BIND_OPTS -np \$SLURM_NTASKS \ relion_run_motioncorr_mpi \ --i Import/job001/movies.star \ --o MotionCorr/job002/ \ --use_own --j \$SLURM_CPUS_PER_TASK \ --patch_x 1 --patch_y 1 --bin_factor 1 \ --dose_per_frame 1.0 --angpix 0.885 " MotionCorr/job002 以下にstarファイルなどが作成されていれば処理は成功しています。24 micrographs処理は約2分程度かかります。 5.4 CTF Estimationの実行例（CPUキューでの実行） sbatch --partition=cpu-queue --nodes=1 --ntasks=8 --cpus-per-task=1 \ --time=02:00:00 --job-name=relion_ctf \ --wrap=" source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:\${MODULEPATH:-} module load relion/cpu cd /shared/relion-test mkdir -p CtfFind/job003 export OMP_NUM_THREADS=\$SLURM_CPUS_PER_TASK BIND_OPTS='--map-by slot:PE='\$SLURM_CPUS_PER_TASK' --bind-to core' mpirun \$BIND_OPTS -np \$SLURM_NTASKS \ relion_run_ctffind_mpi \ --i MotionCorr/job002/corrected_micrographs.star \ --o CtfFind/job003/ \ --ctffind_exe /home/software/apps/ctffind-4.1.14/bin/ctffind \ --is_ctffind4 --ctfWin 512 --Box 512 \ --ResMin 30 --ResMax 5 --dFMin 1000 --dFMax 50000 --FStep 500 --dAst 100 \ --j \$SLURM_CPUS_PER_TASK " CtfFind/job003 以下にepsやstarファイルが生成されていれば処理は成功しています。CTF推定の完了には約1分程度かかります。 5.5 Auto-picking と Particle Extraction（CPU処理） CTF Estimation後、2D Classificationに進むにはParticle Picking（粒子選択）とExtraction（粒子抽出）が必要です。ここではRELIONのLoG（Laplacian-of-Gaussian）フィルタによるテンプレートフリーのAuto-pickingを使用します。チュートリアルデータ（24 micrographs）であればLogin Node上で数十秒で完了するため、sbatchではなく直接実行します。 # Login NodeにSSH接続した状態で実行 module load relion/cpu cd /shared/relion-test # LoG Auto-picking（テンプレートフリー、CPU処理） mkdir -p AutoPick/job004 relion_autopick \ --i CtfFind/job003/micrographs_ctf.star \ --odir AutoPick/job004/ \ --LoG \ --LoG_diam_min 150 --LoG_diam_max 180 \ --shrink 0 --lowpass 20 \ --LoG_adjust_threshold 0 --LoG_upper_threshold 5 上記処理は30秒弱で終了します。 AutoPick/job004 の下にファイルが作成されていれば処理は成功しています。 今回指定しているパラメータの例を以下に示します。 LoG Auto-pickingのパラメータ： --LoG_diam_min 150 --LoG_diam_max 180 : 粒子の直径範囲（Å）。beta-galactosidaseの場合150-180Å --LoG_adjust_threshold 0 : ピッキング閾値の調整（正の値で少なく、負の値で多くピックします） --LoG_upper_threshold 5 : 高コントラスト汚染（氷滴等）を除外する上限閾値 # Particle Extraction（256px → 64pxにダウンスケール） mkdir -p Extract/job005 relion_preprocess \ --i CtfFind/job003/micrographs_ctf.star \ --coord_dir AutoPick/job004/ \ --coord_suffix _autopick.star \ --part_star Extract/job005/particles.star \ --part_dir Extract/job005/ \ --extract --extract_size 256 --scale 64 \ --norm --bg_radius 25 --white_dust -1 --black_dust -1 \ --invert_contrast --float16 上記処理は15秒程度で終了します。 Extract/job005 の下にparticles.starファイルが生成されていれば処理は成功しています。 Particle Extractionのパラメータ： --extract_size 256 : 抽出ボックスサイズ（ピクセル） --scale 64 : 64pxにダウンスケール（初期分類の高速化のため） --bg_radius 25 : 背景領域の半径（ピクセル、スケール後のサイズに対して指定します。64pxの約75%÷2で25） --invert_contrast : 黒い粒子を白に反転（RELION内部処理用） 5.6 2D Classification の実行例（GPUキューでの実行） 2D ClassificationはGPUによって処理が高速化される処理工程です。今回作成した gpu-queue にジョブを投入します。 5.5のAuto-picking + Particle Extractionで生成された Extract/job005/particles.star を入力として使用します。 GPU Compute Node（g6e.4xlarge、NVIDIA L40S）でRELIONのGPUビルドを使用します。初回のgpu-queueへのジョブ投入時は、ノード起動待機時間として5分程度インスタンス起動の待ち時間がかかります。 sbatch --partition=gpu-queue --nodes=1 --ntasks=4 --cpus-per-task=2 \ --gres=gpu:1 \ --time=08:00:00 --job-name=relion_class2d \ --wrap=" source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:\${MODULEPATH:-} module purge module load relion/gpu nvidia-smi cd /shared/relion-test mkdir -p Class2D/job006 export OMP_NUM_THREADS=\$SLURM_CPUS_PER_TASK BIND_OPTS='--map-by slot:PE='\$SLURM_CPUS_PER_TASK' --bind-to core' mpirun \$BIND_OPTS -np \$SLURM_NTASKS \ relion_refine_mpi \ --o Class2D/job006/run \ --i Extract/job005/particles.star \ --dont_combine_weights_via_disc \ --pool 30 --pad 2 \ --ctf --iter 25 \ --tau2_fudge 2 \ --particle_diameter 200 \ --K 50 \ --flatten_solvent \ --zero_mask \ --oversampling 1 \ --psi_step 12 --offset_range 5 --offset_step 2 \ --norm --scale \ --j \$SLURM_CPUS_PER_TASK \ --gpu 0 " Class2D/job006 以下に各種starファイルが生成されていれば処理は成功しています。GPU Compute Node（g6e.4xlarge）でNVIDIA L40S のGPUが検出されていることも確認しながら、relion_refine (GPU) 動作を確認する流れになっています。 なお、今回のRELIONの処理例はあくまでもサンプル実行例として示したものです。各処理工程のパラメータ等の設定は扱うデータにより異なります。RELIONのパラメータ設定はRELIONのマニュアルなどを参考し、正確に処理を行う際は適した設定を行う必要がありますので、その点はご承知おきください。 sacctによるジョブ履歴確認 ManagedAccounting=enabledでクラスターを作成しているので、sacctコマンドでジョブの実行履歴を確認できます： # 全ジョブ履歴 sacct --format=JobID,JobName,Partition,State,ExitCode,Elapsed,Start,End # 特定ジョブの詳細（メモリ使用量含む） sacct -j <JOB_ID> --format=JobID,State,ExitCode,NodeList,Elapsed,MaxRSS # SSHからのログアウト exit 6. クリーンアップ 検証が完了したら、以下の手順でリソースを削除します。PCSリソースは依存関係があるため、削除順序が重要です。 6.1 PCSキューの削除 # CLUSTER_IDの取得 CLUSTER_ID=$(aws cloudformation describe-stacks --stack-name pcs-relion \ --query "Stacks[0].Outputs[?OutputKey=='ClusterId'].OutputValue" \ --output text --region us-east-2) # キュー一覧を確認 aws pcs list-queues --cluster-identifier ${CLUSTER_ID} --region us-east-2 # 各キューのIDを取得 GPU_QUEUE_ID=$(aws pcs list-queues --cluster-identifier ${CLUSTER_ID} \ --query "queues[?name=='gpu-queue'].id" --output text --region us-east-2) CPU_QUEUE_ID=$(aws pcs list-queues --cluster-identifier ${CLUSTER_ID} \ --query "queues[?name=='cpu-queue'].id" --output text --region us-east-2) # 各キューを削除 aws pcs delete-queue --cluster-identifier ${CLUSTER_ID} --queue-identifier ${GPU_QUEUE_ID} --region us-east-2 aws pcs delete-queue --cluster-identifier ${CLUSTER_ID} --queue-identifier ${CPU_QUEUE_ID} --region us-east-2 6.2 PCS NodeGroupの削除 キュー削除後にNodeGroupを削除します。 # NodeGroup一覧を確認 aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[].[name,id]" --output table --region us-east-2 # 各NodeGroupを削除 for NG_NAME in login-gpu gpu-nodes cpu-nodes; do NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='${NG_NAME}'].id" --output text --region us-east-2) if [ -n "${NG_ID}" ] && [ "${NG_ID}" != "None" ]; then echo "Deleting NodeGroup: ${NG_NAME} (${NG_ID})" aws pcs delete-compute-node-group --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-identifier ${NG_ID} --region us-east-2 fi done 6.3 Launch Templateの削除 aws ec2 delete-launch-template --launch-template-name compute-dlami-pcs-relion --region us-east-2 aws ec2 delete-launch-template --launch-template-name login-gpu-dlami-pcs-relion --region us-east-2 6.4 PCSクラスター + 関連リソースの削除（CloudFormationスタック） # PCSクラスタースタックの削除（VPC、EFS、FSx Lustre、セキュリティグループ等すべて含む） aws cloudformation delete-stack --stack-name pcs-relion --region us-east-2 echo "Waiting for pcs-relion stack deletion (this may take 10-20 minutes)..." aws cloudformation wait stack-delete-complete --stack-name pcs-relion --region us-east-2 echo "pcs-relion stack deleted." # オプションで作成した場合のスタックの削除（CloudwatchのLogsを追加した場合に削除が必要) aws cloudformation delete-stack --stack-name pcs-relion-cloudwatch-logs --region us-east-2 # (オプション)　LustreとDRA設定をしたS3バケットの削除(格納されているファイルも含めて削除) AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) aws s3 rb s3://pcs-relion-data-${AWS_ACCOUNT_ID} --force --region us-east-2 6.5 ImageBuilderスタックの削除 aws cloudformation delete-stack --stack-name dlami-for-pcs --region us-east-2 aws cloudformation wait stack-delete-complete --stack-name dlami-for-pcs --region us-east-2 echo "dlami-for-pcs stack deleted." 6.6 カスタムAMIの登録解除（オプション） ImageBuilderで作成したAMIが不要な場合は登録解除します。 # AMI IDを取得 DLAMI_AMI_ID=$(aws ec2 describe-images \ --owners self \ --filters "Name=name,Values=dlami-for-pcs-base-al2023-x86_64*" \ --query 'Images[*].[ImageId,Name]' \ --output table --region us-east-2) echo "${DLAMI_AMI_ID}" # 各AMIを登録解除（複数ビルドした場合は複数存在する可能性あり） for AMI_ID in $(aws ec2 describe-images \ --owners self \ --filters "Name=name,Values=dlami-for-pcs-base-al2023-x86_64*" \ --query 'Images[*].ImageId' \ --output text --region us-east-2); do echo "Deregistering AMI: ${AMI_ID}" # 関連するスナップショットを取得 SNAP_IDS=$(aws ec2 describe-images --image-ids ${AMI_ID} \ --query 'Images[0].BlockDeviceMappings[*].Ebs.SnapshotId' \ --output text --region us-east-2) # AMI登録解除 aws ec2 deregister-image --image-id ${AMI_ID} --region us-east-2 # 関連スナップショットの削除 for SNAP_ID in ${SNAP_IDS}; do echo " Deleting snapshot: ${SNAP_ID}" aws ec2 delete-snapshot --snapshot-id ${SNAP_ID} --region us-east-2 done done 6.7 削除確認 # CloudFormationスタックが残っていないか確認 aws cloudformation list-stacks \ --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE \ --query "StackSummaries[?contains(StackName,'pcs-relion') || contains(StackName,'dlami-for-pcs')].StackName" \ --output text --region us-east-2 # カスタムAMIが残っていないか確認 aws ec2 describe-images --owners self \ --filters "Name=name,Values=dlami-for-pcs*" \ --query 'Images[*].[ImageId,Name]' \ --output table --region us-east-2 7. コスト最適化のポイント 7.1 処理ステップに応じたインスタンスタイプの選択 RELIONの解析工程ごとにCPU/GPU要求が異なるため、適切なインスタンスタイプを選択することでコスト最適化が可能です。 CPU中心の処理 : Motion Correction、CTF Estimation、Particle Picking → c7iインスタンスなどのCPUインスタンス GPU中心の処理 : 2D/3D Classification、3D Refinement → g6eインスタンスなどのGPUインスタンスを用いる 大学共同利用機関法人 高エネルギー加速器研究機構（KEK）による研究論文「 GoToCloud optimization of cloud computing environment for accelerating cryo-EM structure-based drug design（Moriya et al., Communications Biology, 2024） 」では、AWS ParallelCluster上でEC2インスタンスタイプの使い分けによるコストパフォーマンス最適化が実証され、報告されています。PCSにおいても同様のインスタンス選択の考え方が適用可能と考えます。 今回紹介したアーキテクチャや手順を参考にRELIONの処理ステップに応じてPCSで作成するcpu-queueとgpu-queueを使い分けることで、処理時間の短時間化とコスト最適化を図ることができます。 7.2 自動スケーリングの活用 本ブログの構成では、GPU/CPUコンピュートノードグループのminInstanceCountを0に設定しています。これにより、ジョブが投入されるとPCSが自動的にインスタンスを起動し、ジョブ完了後はアイドルタイムアウト（デフォルト10分）経過後に自動的にインスタンスを終了します。解析を行っていない時間帯のコンピュートノードのコストはゼロになります。 PCSの自動スケーリング機能を活用することで、アイドルコストを削減できます。 ジョブ完了後の自動停止 推奨設定: アイドルタイムアウト5〜10分（デフォルトは600秒で10分の設定です） 7.3 効率的なストレージコスト管理とS3ライフサイクル管理 効率的なストレージコスト管理のため、以下の戦略を採用することをおすすめします。 S3 + FSx Lustre DRA連携 : 必要なデータのみをFSx Lustreにキャッシュ S3ライフサイクルポリシー : Intelligent-Tiering、Glacierへの自動移行 FSx Lustreの使用後削除・再作成 : 長期間使用しない場合は削除してコスト削減 Cryo-EMデータは長期保存が必要ですが、すべてのデータを高速ストレージに保持し続ける必要はないものと考えます。S3のライフサイクル管理を活用して、コストを最適化できます。以下にストレージクラスの選択指針の例を示します。 ストレージクラスの選択指針： S3 Standard : アクティブな処理中のデータ（0-30日） S3 Intelligent-Tiering : アクセスパターンが不明なデータ（自動最適化） S3 Glacier Flexible Retrieval : 年に数回アクセスするデータ（90日以降） S3 Glacier Deep Archive : ほとんどアクセスしないアーカイブデータ（1年以降） 考え方の参考にしていただければ幸いです。 8. 結論 AWS Parallel Computing Serviceは、Cryo-EMをクラウドで実行するためのスケーラブルなソリューションを提供し、研究者が新しい科学的発見に集中できる環境を実現します。 本ブログでは、オープンソースのCryo-EM解析ソフトウェアであるRELIONをPCS上で動かす方法を紹介しました。RELIONは世界中の研究者が自由に利用できるソフトウェアです。PCSのマネージドSlurm環境と組み合わせることで、既存のSlurmベースのワークフローをそのままクラウドに持ち込み、オンデマンドでスケールする解析環境を構築できます。 Amazon DCVを使用することで、クラウド上のRELION GUIをローカル環境と同等の操作感で利用でき、粒子の選択や分類結果の確認といったインタラクティブな作業もリモートから快適に行えます。 AWS上のスケーラブルでオンデマンドなコンピューティングにより、科学者のアイデアや意欲の成長に合わせて要求に応えることができます。処理ステップに応じてCPUインスタンスとGPUインスタンスを使い分け、ジョブ完了後はインスタンスが自動的に停止するため、コスト効率の高い運用が可能です。Amazon S3とAmazon FSx for LustreのData Repository Association（DRA）を活用することで、高速な処理性能と低コストな長期保存を両立できます。 本ブログで紹介した手順に沿って、PCS上でのRELIONのサンプル解析環境を構築し、サンプルの処理実行が可能です。ぜひお手元のAWS環境でお試しいただき、PCSの有用性とRELIONの解析の流れをご確認ください。 詳細については、AWSアカウントチームにお問い合わせいただくか、 ask-hpc@amazon.com までご連絡ください。 著者について Tomoya Yamashita 山下 智也(Tomoya Yamashita)は Professional Services のコンサルタントです。大規模なマイグレーションやDBマイグレーションチームに所属しています。HPC、LifescienceやMediaなどをCutting-Edgeなマイグレーションの推進を楽しんでいます。 好きなものは犬です。年を取ったら犬のために働きたいと思って毎日を過ごしています。 Mahiro Tateda 館田麻寛(Mahiro Tateda)は Professional Services 所属コンサルタントとして、CI/CDパイプライン構築からHPCまで幅広い技術領域でお客様の変革を支援しています。 その中でも、HPC環境の構築・運用に注力しております。 TAGS: Cryo-EM , Research Computing , Storage , HPC

レガシーメインフレームアプリケーションは、企業全体の重要な事業運営のバックボーンの一部ですが、これらのシステムにはモダナイゼーションに関する重大な課題があります。メインフレームは何十年にもわたって信頼性が証明されてきましたが、多額の技術的負債を蓄積し、専門知識の需要はますます少なくなり、迅速なイノベーションと機能の導入を妨げています。AWS Mainframe Modernization with Rocket Software は、お客様が切望していたこれらのレガシーアプリケーションの知的財産を元のソースコードのまま維持するための戦略的ソリューションを組織に提供します。このソリューションにより、企業は貴重な既存のビジネスロジックを維持し、運用の継続性を維持しながら、運用コストを削減し、開発サイクルを加速し、最新の開発ツールと方法論を活用できます。AWS でモダナイズすることで、企業はレガシーインフラストラクチャを、将来の成長とイノベーションをサポートするアジャイルなクラウドネイティブシステムに変えることができます。このガイドでは、ビジネス目標、リスク評価、ROI タイムラインに基づいて、AWS で Rocket Software を使ったリプラットフォームの実装に焦点を当てています。ワークロードの計画、移行、検証を最初から最後まで成功させるための 7 つの具体的なベストプラクティスを紹介します。このブログ記事では、標準化された環境、Field-Developed Solutions (FDS) の特定、コード互換性の修正、データ移行戦略、AWS での包括的なテスト手順などのベストプラクティスを紹介します。 ベストプラクティス 1: 移行先アーキテクチャの定義 システム分析および設計文書（System Analysis and Design Document: SA&DD）は、スコープ漏れの管理、テスト作業の軽減、市場投入までの時間の短縮に役立つ重要なプロジェクト成果物です。SA&DD は、以下をマッピングして包括的なターゲットソリューションを定義します。 ハードウェアの仕様と要件 システムサービスと構成 プログラミング言語と開発ツール サードパーティーのアプリケーションおよび連携 (以下はその一例です) データベース管理システム (セルフマネージドシステムと Amazon RDS の両方: Db2 LUW、PostgreSQL) ジョブスケジューリングツール レポート生成ソフトウェア ファイル転送ユーティリティ (SFTP、FTP) メールシステム (SMTP) 開発サーバーとエンタープライズサーバー構成 データ移行戦略と計画 コンプライアンスおよび規制要件 セキュリティ管理と監視アプローチ ソースコードのインベントリと可用性の評価 外部システムとの連携ポイント パフォーマンス要件とサービスレベル契約 (SLA) SA&DD は移行プロジェクトの設計図の役割を果たすため、すべてのステークホルダーが移行先アーキテクチャと技術要件を明確に理解できます。プロジェクトライフサイクルの早い段階で潜在的なリスクと技術的ギャップを特定し、積極的な緩和戦略を立てるのに役立ちます。SA&DD の作成の一環として、完全な静的分析を行い、すべてのコンポーネントのインベントリを作成します。コンパイラおよびコンパイラ指令(ディレクティブ)の互換性を検証して文書化し、リスクがあれば文書化します。専任チームを割り当て、発見事項に対処し、コードベース全体に体系的に修正を適用します。これらのステップにより、コーディング標準への準拠が保証され、メンテナンスの必要性が軽減され、下流でのデプロイメントの問題が防止されます。 ベストプラクティス 2: 標準化された Development 環境と Enterprise Server 環境の構築 標準化された開発環境の目標は、すべての開発者に一貫したテンプレートを提供することです。標準化された環境では、ディレクトリ構造とコンパイラ指令を含むプロジェクトプロパティの両方が定義されるため、すべての開発者が同じ条件で作業し、コードが一貫してコンパイルされます。 Rocket Enterprise Developer (ED) と Rocket Enterprise Server (ES) の標準セットアップ AWS 上の Rocket Enterprise Developer (ED) と Enterprise Server (ES) 向けに、バージョン管理されたゴールデンセットアップを作成します。Amazon EC2 イメージで特定のバージョンを指定し、標準構成として環境を構築します。 ソースコントロールのコンパイラ指令 (例: DIALECT/ARITH/TRUNC、コードページ) や、リンクオプション、およびビルドステップはそのまま使用します。これにより、CI が構成のずれを検出しても、一貫したツールチェーン設定が可能になります。 マスター Enterprise Server (ES) リージョンの作成 Rocket Directory Server と Enterprise Server Common Web Administration 用の Infrastructure as Code を使用してマスター ES リージョンを作成し、すべての CICS/IMS/JES リソース、データセット、セキュリティ、ミドルウェアを定義します。環境固有の設定には AWS Systems Manager と AWS Secrets Manager を使用して、このテンプレートを QA (Quality Assurance) / UAT (User Acceptance Test) 環境に複製します。トラフィック管理用に Network Load Balancer を実装します。一貫性のある環境を確保し、更新を簡素化できるようにするため、メンテナンスに Amazon CloudWatch を AWS Systems Manager を使います。 ベストプラクティス 3: 要件を識別して Field Developed Solutions (FDS) を活用する FDS (Field Developed Solutions) は、Rocket Software Enterprise Server とサードパーティ製品間の技術ギャップを解消することで、他社製品とをつなぐ架け橋となるソリューションです。分析中、チームはこれらのプラットフォーム間の適切な統合を可能にするためにどの特定の FDS が必要かを特定します。特定すると、該当の FDS を購入し、インストールし、ターゲット環境で一通りテストし、正しく機能することを確認します。カスタムプリンタソリューションなど、標準の FDS が存在しない特別な状況では、Rocket Software のアーキテクトがデリバリーチームと直接協力して、独自の要件を満たす新しいカスタム FDS を開発するためのオプションを検討し、評価することがあります。 ディスカバリーフェーズで FDS を特定するメカニズム 棚卸しとディスカバリー (Enterprise Analyzer (EA) の標準レポートを使用) プログラムの量、使用されているテクノロジー、複雑さなど、全体的なポートフォリオを把握するには、Application Inventory や Application Summary などの Executive Reports から始めてください。特殊なテクノロジーや例外値の指標は、自社開発のコンポーネントを示している可能性があります。 Inventory Reports を確認すると、COBOL、PL/I、ジョブ制御言語 (JCL) などの言語間で検証済みのファイル数とコード行数 (LOC) を比較できます。JCL が参照している内容と EA が検証できる内容との間に相違がある場合、カスタムユーティリティやコピーブックがベースラインから除外されているケースがよく見られます。 Verification and Reference Reports、特に Missing Files と Unresolved References を使って、解決されないコピーブック、呼ばれているプログラムや JCL プロシージャ (PROC) を一覧表示します。頻繁に参照される未解決の項目は最優先項目として扱います。 JCL Support がプロシージャ、コントロールカード、ユーティリティエイリアスを解析できるようにします。レポートをスキャンして、非標準のユーティリティ名、カスタムプロシージャの命名パターン、データセット識別子に着目し、社内で開発された固有のジョブやライブラリを示す兆候が無いか調べます。 EA で Portability Assessment を実行して、プログラミング言語の方言特有の特徴や標準外の構成要素など、所見や注目ポイントを指摘します。これらの調査結果は、特別な処理を必要とするカスタムルーチンと相関している可能性があり、FDS の強力な指標となります。 Enterprise Analyzer の Code Search を使用したパターンベースの検索 Enterprise Analyzer の Code Search を使用すると、検証済みのソースファイルをすべてスキャンして FDS が必要なパターンがないかどうかを確認できます。あらかじめ定義されたカテゴリから始めて、カスタムクエリを追加します。 Analyzer ワークスペースから Code Search を実行するか、ポートフォリオ全体で繰り返し検出できるように複数のクエリをまとめた Custom Code Search Report を作成します。詳細については、 “Analyzing Programs – Staging Program Analysis with Code Search” を参照してください。たとえば、どの SORT パラメータが使用されているかを調べてください。これは、たとえば SORT パラメータに IFTHEN や JOINKEYS が含まれている場合に役立ちます。 ステークホルダーのインプット 社内ツールについて、開発者と運用チームにヒアリングします。 可能な場合は、社内ツールを補完する Rocket Enterprise Developer の同梱ツールや新機能を活用します。 社内で開発されたカスタムユーティリティについては、変更管理履歴を確認して参照します。 一般的な FDS の例: SORT : Rocket Software の外部 SORT を拡張して、追加の DFSORT オプションと Syncsort オプションをサポートできるようにします。 Simple Mail Transfer Protocol (SMTP) : JCL と SMTP を連携してメール送信機能を提供します。 Secure FTP (SFTP) : JCL にほとんどまたはまったく変更を加えずに、メインフレーム JCL FTP ステップを SFTP にマッピングするために必要なサポートを提供します。 Rocket Software には、SAS などのサードパーティ言語を統合した FDS がいくつか用意されています。Rocket Software の すべての FDS の一覧 をご覧ください。 ベストプラクティス 4: 移行を成功させるためのソースコードの準備 コードデプロイメントは、メインフレームからアプリケーションのソースコードを取り出し、ターゲットの Rocket Software ランタイム環境でビルド、デプロイ、テストするプロセスです。これには、COBOL コードの再コンパイルと、Enterprise Server でサポートされていない言語 (アセンブラなど) のコード変換が含まれます。再コンパイルする前にソースコードの完全性をチェックし、アプリケーションモジュール、コピーブック、JCL/PROC、マクロ、ユーティリティを含むすべてのソースコードが使用可能であることを確認します。 ソースに埋め込まれた 16 進数 チームは 16 進リテラルを使用してバイナリフラグとビットマスク (COMP、COMP-5、BINARY) の設定、パック 10 進数 / COMP-3 フィールドの初期化、レコード分離用の非表示制御文字の挿入、コードページ固有の表示値の表現を行います。移行の課題は、メインフレーム (EBCDIC) とターゲット環境 (ASCII) のコードページの違いから生じます。たとえば、数字の 0 は EBCDIC では X’F0’、ASCII では X’30’ なので、COBOL ステートメント MOVE X’F0F1′ TO ALPHA-FIELD はメインフレームに 01 と表示されますが、正しい ASCII 表示には読み替えが必要です。同様に、EBCDIC レコードセパレータ X’15’ は ASCII ラインフィード X’0A’ とは異なります。すべての環境のエンコーディング標準を SA&DD に文書化します。 ターゲットとなるエンコーディング戦略を決定して文書化します。EBCDIC をそのまま使用する場合は、データセットとリテラルを EBCDIC に保存し、ファイルハンドラーまたは CCSID を明示的に設定します。ASCII または Unicode を採用する場合は、明確に定義された I/O 境界でのみ変換し、表示テキストを表す 16 進数をポータブルリテラル (たとえば 01) または共有コピーブックのエンコーディング対応定数に書き換えます。 16 進数は真のバイナリデータおよびパック形式データ (フラグ、ビットマスク、COMP-3) に限定し、コードコメントや設計成果物にその意図を文書化します。Kiro CLI を使用して、バイナリの可能性があるフィールドを特定し、そのフィールドに関するユニットテストを生成または更新し、Rocket Enterprise Server ランタイムの数値動作がメインフレームのベースラインと一致することを検証します。 16 進数の検出と分類を自動化します。Kiro CLI によるリポジトリ全体にわたる検索を使用して X’.. ‘ などのパターンを特定し、エージェントに使用パターン (表示、パック形式、制御文字) ごとに出現箇所をグループ分けさせ、直接読み替え (テキスト用) または現行のまま維持 (バイナリ用) のいずれかを提案させます。正しい結果が得られるとわかっている小さな入力ファイルを使用して翻訳経路を end-to-end で検証します。表示フィールドが一度だけ翻訳されるのに対し、バイナリフィールドはプラットフォーム間でバイトが同一であることを確認します。 翻訳経路を反復可能なワークフローとしてテストします。データセットとコードページの設定、コピーユーティリティ、ミドルウェアを検証して、二重翻訳や翻訳スキップがないことを確認します。Kiro CLI エージェントは、コマンドラインから既存のユーティリティと比較ツールを呼び出し、ログや差分をキャプチャして、リグレッションやカットオーバーのリハーサル中に再実行できる反復可能なレシピにパッケージ化することで、これらのチェックを調整できます。 緩いコーディング基準で実装されたソースコード レガシーアプリケーションが寛容なメインフレームコンパイラの動作 (またはショップ固有の拡張機能) に依存していて、より厳しい Rocket コンパイラでは拒否されることがよくあります。コンパイル時によくある問題には、スコープターミネーターの欠落、固定形式の間違い、一貫性のない符号処理、非標準動詞、MOVE CORRESPONDING、未解決の COPY REPLACING、TRUNC/ARITH の違いなどがあります。 これらの問題を軽減するには、メインフレームの動作をエミュレートするようコンパイラーディレクティブの組み合わせをプロファイルとして確立し、コンパイル時に適用します。スコープ、フォーマット、PIC のチェック用の整形ルールと継続的インテグレーション (CI) ルールを追加します。非標準構成を移植可能な同等の構成に置き換えます。数値フィールドとパックフィールドのユニットテストを実装して、回帰事象を早期に検出します。 COBOL 標準の進化 COBOL 言語標準は時間の経過とともに進化し、新しい構文や予約語が次々と追加されてきました。たとえば、ANSI COBOL 85 が組み込み関数を導入したことで、「FUNCTION」は予約語になりました。場合によっては、コンパイルディレクティブを調整することでこれらの違いを緩和できることがあります。Rocket Software の「REMOVE」ディレクティブでは、予約語をデータ項目として使用できます。たとえば、「REMOVE (FUNCTION)」を使用すると、期待どおりの機能を維持しながらコンパイルできます。 コマンドライン (Kiro CLI) で Kiro を使用して作業を加速 Kiro CLI を活用して、自動化されたコード取得、変換、デプロイのワークフローをコマンドラインから直接調整することで、メインフレームのモダナイゼーションを加速します。Kiro CLI は、再コンパイル作業を効率化し、非互換性 (サポートされていないアセンブラ呼び出しなど) を早期に明らかにし、Rocket Softwareのランタイムを一貫してターゲットにすることで、移行の各スプリントをすぐにデプロイ可能なソースコードから開始できるようにします。追加情報については、Kiro CLI (旧 Amazon Q CLI) によるコンパイルの高速化に関する記事 Revolutionizing Mainframe Replatforming with Amazon Q CLI を参照してください。 ベストプラクティス 5: 広範囲にわたるテストが成功のカギ 包括的な統合テストとシステムテストを実行しながら、正確なトポロジ、セキュリティ構成、データエンコーディング、ミドルウェアコンポーネントの機能を再現することで、本番環境を反映した AWS 環境を開発します。 メインフレームのベースラインの確立 定常状態とピーク状態の両方を網羅した、現在のシステムの動作とパフォーマンス指標の包括的なベースライン測定値を確立します。すべてのコンポーネントのスループット、レイテンシー、ストレージの物理 I/O の正確な測定値を文書化します。このベースラインには、メインフレームシステムの詳細な指標を含める必要があります。具体的には、システム管理機能 (SMF) レコード、バッチ処理件数の合計値、クリティカルパスジョブのタイミング、I/O ボリューム、インターフェイスレイテンシーの収集などです。この情報は、AWS への移行が成功したかどうか検証するための決定的な基準となります。ベースラインテストでは、運用範囲全体をカバーする end-to-end の検証を実施します。すべてのジョブ制御言語（JCL）プロシージャを含むバッチスケジュール全体を実行し、すべてのオンライン画面とサービスをテストし、インバウンドとアウトバウンドの両方のインターフェイスを検証し、サードパーティコンポーネント連携（印刷サービス、電子メールシステム、メッセージキュー、スケジューラーを含む）を検証し、Enterprise Server (ES) のセキュリティコントロールを確認し、包括的なデータ移行を実行してタイミングベースラインを確立します。ピーク負荷状態やエッジケースを含め、すべての結果を統計的に有意な形で文書化して、AWS の実装と比較できるように完全なパフォーマンスプロファイルを確認します。自動テストフレームワークを使用して測定の一貫性と再現性を確保し、パフォーマンスメトリクスに影響を与える可能性のあるすべてのテスト条件と環境要因の詳細な記録を維持します。 統合テスト 共用の統合テスト用 Enterprise Server (ES) リージョンまたはローカルの開発用 ES 環境でテストを実行します。エンコーディング選択 (EBCDIC / ASCII)、データセットカタログ、接続設定など、本番環境の設定を正確に複製します。欠陥に対処する際は、可能な限り、標準化された COBOL コンパイラ指令プロファイルを通じて修正を実施してください。これにより、それ以降のビルドでは、数値セマンティクスや符合ルールなどの重要な要素にわたって一貫した動作が維持されます。標準化すべきその他の重要な要素には、想定される CCSID、ファイル編成、レコード区切り文字の処理などがあります。この標準化されたアプローチは、環境特有の問題を防ぎ、すべての環境で再現可能な動作を保証します。 一般的な課題の例 データ形式: メインフレームが別のメインフレームとの間でデータを送受信する場合、可変長ブロック化 (VB) ファイルを直接送信できます。メインフレームが VB ファイルを分散プラットフォームに送信しても、Rocket Software が処理できる VB 形式では届きません。これには、Rocket Field-Developed Solution (FDS) のレコード形式変換ソリューション、もしくは、ETL (Extract, Transform, Load) ツールのカスタム開発が必要です。 文字セットの変更: 分散プラットフォームがメインフレームにデータを送信すると、メインフレーム上の FTP サーバーによって文字セットが ASCII から EBCDIC に自動的に変換されます。同じファイルが ES 環境に送信されても、この文字セット変換機能はありません。Rocket FTP FDS は、組み込みの文字セット変換機能を使用してアウトバウンドデータ転送を処理します。ただし、外部プラットフォームからのインバウンド転送には、文字セット変換のための追加の処理ステップが必要です。 機能的同等性テスト システムテストでは、統合テストの完了後に機能的同等性を大規模に検証する必要があります。本番レベルのデータ量を使用して、AWS でそのままバッチポートフォリオを実行します。機能的に同等になり、SLA を満たすまで、すべてのアウトプットをベースラインのメトリックスと比較します。カレンダー、依存関係、タイムゾーンルールを明記した詳細な計画文書を作成しましょう。リスタートの手順、リランする際の作業順序、および文書化された移行手順を含めます。移行前後の違いに合わせた最適化を開始する前に現状のままテストを実行することで、環境の違い、エンコーディングの問題、I/O のばらつきを特定するのに役立ちます。スケジューラーの移行には早期に対処し、初期テストではレガシースケジューラーと連携するブリッジ機能またはプラグインを使用して AWS ワークロードを連携動作します。安全な接続経路や、カレンダー機能、リスタート機能がレガシープラットフォームにない場合は、早期の移行を検討します。シャドウ実行または並列実行により、スケジューラーの同等性を検証します。カットオーバー前にモニタリング、アラート、リカバリの手順を練習します。運用が安定したら、機能的な変更を実施せずプラットフォーム移行から切り離したままで、ジョブフローを合理化して重複を排除します。 パフォーマンステスト パフォーマンステストでは、移行したアプリケーションが移行元システムのベースラインメトリクスを満たしているか、上回っているかを検証する必要があります。テストは、スループット率、レスポンス遅延、リソース使用量という 3 つの主要分野に焦点を当てます。すべてのテストは、実稼働規模のデータ量とワークロードパターンを使用して実行し、正確なパフォーマンス比較を行います。 ベースライン指標 メインフレームの SMF/RMF レコードとジョブアカウンティング指標を使用してパフォーマンスベースラインを確立する クリティカルパスのタイミングと I/O 量を参考ベンチマークとして文書化する ピーク時のワークロードパフォーマンス特性とトランザクション応答時間を把握する ストレージパフォーマンス ワークロードパターンに基づいて Amazon EFS スループットモード (Elastic / Provisioned) を設定する Amazon EBS io2/io1 ボリュームを I/O 負荷の高いバッチ処理に活用する EFS メトリクスの監視: TotalIOBytes, PermittedThroughput, BurstCreditBalance EBS メトリクスのトラッキング: IOPS, Throughput, Queue Length, Volume Status 詳細については、「 AWS Mainframe Modernization のファイルシステム選択 」を参照してください。 コンピュートパフォーマンス EC2 メトリックス (CPU 使用率、ネットワーク I/O、メモリ使用量) の監視と取得 ワークロードの特性 (コンピューティング最適化 / メモリ最適化 / ストレージ最適化) に基づいてインスタンスタイプを最適化する ストレージを大量に消費する運用の場合は EBS 最適化インスタンスのパフォーマンスを追跡する 詳細については、 Scaling for performance with AWS Mainframe Modernization and Micro Focus をご覧ください。 検証プロセス 完全な JCL プロシージャを含む包括的なバッチスケジュールテストを実行する 確立された SLA に照らしてパフォーマンスを監視し、検証する ジョブの完了時間、リソース使用率、スループット率を追跡する 自動化されたパフォーマンス回帰テストを実施して、一貫した評価を行う 対象分野の専門家 (Subject Matter Expert: SME) による承認 SME は、重要なアウトプットと例外パスを検証する必要があります。さらに、承認が迅速に行われ、透明性があり、監査可能になるよう、照合結果のレポートや、そのタイミング、差分は自動的に提供されるべきです。 ベストプラクティス 6: 一般的なツールを活用して移行を加速 Mainframe Access ツール (MFA) Rocket Software の MFA は、ユーザーフレンドリーなドラッグアンドドロップインターフェイスと、メインフレームと他のシステム間で複数のデータセットをプルおよびプッシュできるバッチ処理システムの両方を提供します。これにより、FTP ジョブを実行してメインフレームから移行先プラットフォームにファイルをプッシュする必要がなくなります。たとえば、MFA を使用して区分データセット (PDS) ライブラリ、JCL、コントロールカードにアクセスし、インベントリを取得できます。さらに、テスト用のデータセットのダウンロードにも使用できます。 MFA は双方向で動作するため、テスト出力ファイルをメインフレームに送り返して、メインフレームが生成した出力と比較することができます。プロジェクトチームは使い慣れたメインフレームの SuperC ユーティリティを引き続き使用して、即時の検証を実施しつつ、移行先環境で新しいツールを徐々に習得できます。 Data File Converter (DFCONV) Rocket Software のバッチデータファイルコンバーターである DFCONV は、EBCDIC と ASCII 間の変換など、さまざまな形式間のファイル変換に使用されます ※ 。これにより、移行したデータセットを ES で使用できるようになります。ワークフローは MFA のバッチまたはコマンドラインインターフェイスを使用してメインフレームからソースデータセットをダウンロードし、DFCONV を使用して必要な形式に変換します。 (※) 訳注: IBM 日本語文字セット (コードページ 930, 939, 1390, 1399) は直接扱う場合に制約がある可能性あり 統合開発環境 (IDE) Eclipse は、特に Linux プロジェクトの開発とテストのための主要なプラットフォームです。社内標準によって、開発者はマイクロソフトの Visual Studio または VS Code を選択することもあります。Rocket Enterprise Developer と Visual COBOL はどちらも Eclipse や VS Code とシームレスに統合されています。これらの開発者ツールは、Windows 環境と Linux 環境での編集、コンパイル、デバッグをサポートします。 ベストプラクティス 7: 包括的なデータ移行戦略の策定 統合テストデータおよびシステムテストデータを特定する (テスト可能で反復テスト可能なものにする) 統合テストと end-to-end のシステムテストをサポートするために必要なすべてのデータは、できるだけ早く特定する必要があります。現新照合テストを容易にするためには、システムテスト環境をメインフレームと何度か同期させる場合が多いです。 EBCDIC もしくは ASCII いずれでデータを保持するか早い段階で判断する (そしてその方針を変えない) EBCDIC と ASCII のどちらを選択するかは、データ変換プロセス、アプリケーションの互換性、潜在的なパフォーマンスオーバーヘッドに影響します。EBCDIC を維持することで移行の複雑さを軽減し、正確なデータ表現を維持できますが、ASCII を採用することで最新のプラットフォームやツールとの統合が容易になります。この決定を下す際には、組織固有のアプリケーション要件、データ特性、長期的なモダナイゼーション目標を考慮して、これらの要因を慎重に検討する必要があります。 データレプリケーション計画とカットオーバータイムライン (「移行ウィンドウ」が意味するものを念頭に) この目標設定は変動が大きく、カットオーバーがいつ行われるかに大きく依存します。データが特定されたら、データの移行に必要な時間の見積もりを行う必要があります。その結果、カットオーバーで利用できる許容可能なダウンタイムを超える時間が発生する可能性があります。その場合は、データカットオーバーの開始日と実際の稼働日に基づいて、静的データと動的データを判断します。静的データは、メインフレーム上で変更されるリスクなしに、本番稼働までの数日または数週間で移行できます。動的データは、本番稼働日に移行する必要がある残りのデータです。end-to-end の移行リハーサルを 2 回以上実行し、移行ウィンドウに対して 20 ～ 30% のバッファーが得られるまで計画を調整します。 履歴データの保存とアクセス (事前移行と事後移行 — いずれにするか選ぶ方法) 多くのお客様が、長年にわたる履歴データを維持することが規制上または法律上の要件となっています。このような履歴データはターゲット環境に移行する必要があります。履歴データの量が多い場合は、運用開始の前または後に履歴データを移行することを検討します。 物理ファイルの移行 (フォーマット、ハンドラー、ツール) — 知っておくべきこと テキスト以外のデータを含むファイル (COMP や COMP-3 フィールドを含むファイルなど) には、構造ファイルと呼ばれるものが必要です。これはデータファイル内のデータを解釈して表示する方法を定義するもので、Rocket の構造ファイルエディタを使用して作成されます。構造ファイルはコピーブックとコンパイルされたプログラムに基づいて作成されますが、同じ物理ファイル内に複数のレイアウトを含むファイルでは構造が条件付きになるため、複雑さが増します。これらの構造は EBCDIC から ASCII への変換時に使用されます。 データベース移行 (カットオーバーのリスクを最小限に抑えるための戦略的な選択肢) 移行対象のデータベースエンジンを選択するときは、互換性の重要度、コストに関する考慮事項、チームスキル、および長期的な柔軟性のニーズに基づいて、選択肢を慎重に評価します。機能マッピング、データ型変換、コードページを漏れなく文書化し、移行の整合性を確保するために検証クエリを開発することが不可欠です。Db2 LUW (Linux, UNIX, and Windows) は、ベンダーへの依存と柔軟性の低下を伴いますが、メインフレーム Db2 に最も近い動作を実現し、コード変更が少なくて済み、移行リスクも軽減されます。一方、PostgreSQL には、ライセンス料ゼロ、強力な SQL 標準準拠、JSON サポートなどの最新機能、優れたクラウド柔軟性など、大きな利点があります。ただし、Db2 固有の機能のマッピング、潜在的なチームスキルの向上、動作が異なるアプリケーションの変更が必要になります。他に実行可能なマイグレーションパスとしては、Microsoft SQL Server 用や Oracle 用の Host Compatibility Option を使って Db2 スキーマ/データ移行とメインフレーム動作エミュレーションを実現する方法もあります。他に利用できるデータベースオプションについては、Rocket Software に確認してください。 検証とガバナンス 効果的な検証とガバナンスを行うには、エンコーディングを考慮したファイル比較、行単位の比較、コントロール全体の比較、対象を絞ったビジネスクエリ、タイミングデルタの注意深い分析など、移行プロセス全体にわたる統制チェックが必要です。組織は、包括的なマニフェスト、チェックサム、詳細なレポートを保存し、導入前に何度も移行リハーサルを行う必要があります。最も重要なのは、検証ゲートが満たされないまま本番稼働することが無いよう明確な基準を確立し、データの整合性とシステムの信頼性を確保することです。 結論 リプラットフォームしましょう。メインフレームから AWS へのリプラットフォームによる移行は、単なる技術的な移行ではなく、戦略的な進化を表しています。本ブログで紹介した 7 つのベストプラクティスに体系的に従うことで、組織はリスクを最小限に抑え、事業継続性を確保しつつ、メインフレームから AWS へのインフラストラクチャのトランスフォーメーションを成功させることができます。 著者 Mastan Shaik Mastan Shaik は、企業のクラウド移行と分散システムアーキテクチャを専門とする、AWS の Senior Solutions Architect です。アナリティクス、生成 AI の実装、クラウドネイティブソリューションの専門知識を活かし、金融サービス全体で Fortune 500 のクライアントに戦略的ガイダンスを提供しています。Mastan は、セキュリティとコンプライアンスの基準を維持しながら、組織がクラウドインフラストラクチャを最適化できるよう支援することに重点を置いています。経営幹部にクラウド変革戦略や生成 AI の導入フレームワークについて定期的に助言し、AWS のベストプラクティスに関する技術ワークショップをリードしています。 Cheryl du Preez Cheryl du Preez は、メインフレームとレガシーモダナイゼーションに関する AWS の World Wide Senior Specialist Solutions Architect です。Cheryl は、世界中のお客様を対象としたメインフレームのモダナイゼーションとトランスフォーメーションの取り組みにおいて、20 年以上にわたって技術的リーダーシップを発揮してきました。現在の役職では、AWS 独自の方法で生成 AI を活用したメインフレームのモダナイゼーションについて、お客様やパートナーに対して助言を提供しています。 Soham Tillu Soham Tillu は、金融サービスの AWS Senior Customer Solutions Manager です。Soham は主要なエンタープライズアカウントにおける戦略的技術イニシアチブを率いています。クラウドトランスフォーメーション戦略と AI のユースケースについて、上級エグゼクティブに対して定期的に助言しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

※ 本記事は 2026 年 2 月 19 日に公開された Jatin Arora　による  The bug fix paradox: why AI agents keep breaking working code を翻訳した記事となります。 過剰解決の問題 多くのチームが経験するパターンがあります。AI エージェントにバグ修正を依頼すると、3 つのヘルパー関数をリファクタリングし、防御的な null チェックを追加し、すでにパスしているエッジケースに対して何十もの新しいテストを書いてしまいます。さらに悪いことに、正常に動作していたアプリケーションの部分まで変更してしまいます。メスを求めたのに、スレッジハンマーが返ってきたようなものです。 エージェントは 人間の約 2 倍の確率 でガード節や防御的なエラーハンドリングを追加します。私たちなら「なぜ null なのか？」と問うところを、エージェントは if (x == null) を追加して先に進んでしまいます。適切な制約がなければ、 エージェントと対話を重ねるほど、元の意図からどんどん乖離していきます。 実際の修正は、不要な変更の山に埋もれてしまいます。問題の本質は、あなたとエージェントが「何を修正すべきか」と「何をそのままにすべきか」の境界を共有していないことにあります。Kiro のバグ修正ワークフローは、この境界を明示的にするために設計されています。私たちはこのアプローチを プロパティ指向コード進化 (property-aware code evolution) と呼んでいます。 プロパティ指向コード進化 すべてのバグ修正には 2つの目的があります。バグのある動作を修正することと、それ以外のすべての正常な機能を維持することです。この意図は入力空間を分割しますが、その分割は通常、暗黙的なままです。これを明示的かつテスト可能にすることができます。 バグ条件 バグ条件 C は、バグが発生するトリガーを特定します。入力空間を 2 つに分割します。 C を満たすシナリオ → バグが現れる場所。ここでは修正が必要です。 C を満たさないシナリオ → 動作が正しい場所。ここでは維持が必要です。 例えば、二分探索木（ BST ）からノードを削除する際、右の子に左の部分木がない場合にクラッシュするなら、C は「ノードが2つの子を持ち、かつ node.right.left がNone」となります。それ以外のすべての削除シナリオは C の範囲外であり、触れずにそのまま保つべきです。 経験豊富なエンジニアは誰もが C について考えていますが、多くの場合それは暗黙的です。しかし C が明示的で共有された成果物になっていない限り、エージェントの考える境界があなたの考える境界と一致している保証はありません。C が暗黙的なままだと、3 つの問題が起こり得ます。 エージェントが境界から逸脱する : バグレポートが正確であっても、エージェントには境界の永続的な記録がありません。各ステップで境界をゼロから再解釈するため、複数のステップを経るうちに元の意図から乖離していきます。 エージェントが境界を独自に作り上げる : バグレポートが曖昧な場合、エージェントはエンジニアと同様にギャップを自分の推測で埋めます。違いは、エージェントがその推測を明示しないことです。コードレビューで不一致に気づいた時には、パッチはすでにその推測を前提に構築されています。 エージェントが境界を守ったかどうかを確認できない : 明示的な C がなければ、他のすべてが正常に動作しているかを体系的に確認する方法がありません。エージェントは修正を確認できますが、境界内に留まったかどうかは確認できません。 C は境界を引きますが、それだけでは不十分です。C はバグが発生するタイミングを教えてくれますが、「修正された」とはどういう意味かは教えてくれません。 事後条件 (postcondition) P がそのギャップを埋めます。P は C が成立する入力に対してコードが何をすべきかを定義します。BST の削除がクラッシュする場合、P は「削除操作がクラッシュせず、ノードを削除し、BST の不変条件を保持する」となります。 P がなければ、エージェントは try/except でエラーを抑制して「修正済み」と判断してしまいます。P によって、「正しい」とはどういう意味かに沿った実装が強制されます。 修正プロパティと保持プロパティ プロパティ指向コード進化では、コードを書く前にプロパティを定義します。 プロパティ とはテスト可能な主張です。ある条件を満たすすべての入力に対して、ある保証が成立するというものです。バグ条件 C と事後条件 P を使って、2 つのプロパティを定義します。 修正プロパティ (C ⟹ P): C が成立する場合、パッチ適用後のコードは P を満たします。 例: 修正プロパティは「ノードが 2 つの子を持ち node.right.left が None であるツリーに対して、delete が P を満たす」と主張します。そのようなツリーで delete を実行することで確認できます。1 つでもクラッシュすれば、プロパティは失敗です。 保持プロパティ (not C ⟹ 変化なし): C が成立しない場合、パッチ適用後のコードは元のコードと同一の動作をします。 例: 保持プロパティは「他のすべてのツリーに対して delete が同一の動作をする」と主張します。修正前後で C の外側のツリーに対して delete を実行して確認します。動作が変わればプロパティは失敗です。 この 2 つのプロパティは入力空間全体をカバーし、エージェントが修正を書く際の制約になります。どのパッチも、保持プロパティを壊すことなく修正プロパティをパスしなければなりません。私たちはこの方法論を プロパティ指向コード進化 と呼んでいます。 Kiro のバグ修正ワークフローは、この方法論を内部で使用しています。Kiro はバグ条件、事後条件、修正プロパティと保持プロパティを提案します。あなたはそれらを一緒に洗練させ、Kiro が生成する仕様、テスト、修正はすべてそれらのプロパティから導き出されます。 Kiro のバグ修正ワークフローの実践: BST 削除バグ 以下は、古典的なデータ構造のバグを示す具体的なバグレポートです。 Fix the crash in BST delete. When deleting a node that has two children and the right child has no left subtree, it throws an AttributeError. For example, insert [5, 3, 7] and delete 5 — it crashes. # BST（二分探索木）の削除処理でクラッシュを修正してください。 # 2つの子を持つノードを削除する際、右の子に左部分木がない場合にAttributeError が発生します。 # 例えば、[5, 3, 7] を挿入してから 5を削除するとクラッシュします。 これを Kiro に貼り付けてバグ修正ワークフローを選択します。Kiro はすぐにパッチを書こうとはしません。1 行のコードも書く前に、バグのあるシナリオとそうでないシナリオを分割し、根本原因の仮説を立て、その仮説を検証します。 バグ修正ドキュメント Kiro はバグレポートを分析し、3 つの要件カテゴリを含むバグ修正ドキュメントを生成します。現在の欠陥のある動作（Defect）、期待される修正（Correct）、そして維持されなければならない変更前の動作（Regression Prevention）です。 これはバグ条件 C によって定義された分割を反映しています。欠陥と修正の要件はバグのある入力を対象とし、維持の要件は変更されてはならない特定の動作を特定します。 設計: バグ条件と根本原因の仮説 バグ修正ドキュメントは自然言語でシナリオを分割します。Kiro はここでそれを形式化し、バグが存在する理由を調査します。 分割の形式化 : Kiro は欠陥と修正の要件からバグ条件 C を抽出します。 C(node) = (node has two children) and (node.right.left == None) Kiro はまた、「修正された」とはどういう意味かを事後条件 P として形式化します。 P(node, tree) = (no AttributeError thrown) and (node removed) and (BST invariant preserved) 根本原因のトレース : C と P が確立されたところで、Kiro はコードベースを読み込み、根本原因の仮説を構築します。C が成立する入力に対して、なぜクラッシュして P を満たさないのかを調べます。C が成立する入力の実行フローをトレースします。 def _delete_recursive(self, node, value): ..... min_node = self._find_min(node.right.left) # ← trace enters here node.value = min_node.value node.right = self._delete_recursive(node.right, min_node.value) return node C が成立する入力、例えば [5, 3, 7] から 5 を削除する場合、トレースは次のように評価されます。 1. node = Node(5), two children → enters Case 3 2. node.right = Node(7), node.right.left = None 3. _find_min(None) called 4. _find_min attempts None.left → AttributeError 仮説: _find_min が node.right ではなく node.right.left を受け取っています。C が成立する場合、 node.right.left は定義上 None であるため、この呼び出しは常にクラッシュします。 チェックポイント : コードやテストを書く前に、Kiro は C、P、仮説をレビューのために提示します。この時点では何も生成されていません。C が狭すぎる、広すぎる、または間違ったシナリオを対象にしている場合、あなたはフィードバックして修正することが可能です。仮説が間違っている場合は、次のフェーズで検出されます。修正プロパティのテストは、修正前のコードで AttributeError で失敗するはずです。別の理由で失敗したり、まったく失敗しなかったりした場合、仮説は反証され、Kiro は修正を書く前に再分析します。 根本原因の仮説は設計フェーズをドキュメント以上のものにします。それは反証可能な予測です。この後のテスト戦略全体が、その仮説を確認または反証するために設計されています。 タスクプラン: 仮説の検証 Kiro は C を満たす入力がクラッシュするのは _find_min が None を受け取るためであると言う仮説を持っています。タスクプランは修正をする前にこの仮説を検証します。 Kiro はすべてのテストをまず修正前のコードに対して実行し、修正を適用してから再テストします。プランは 3 つのタスクに構成されます。 タスク 1 : Kiro は C の内側の入力に対するバグ条件テストを書き、期待される動作 (P) をエンコードします。修正前のコードに対して実行します。テストは失敗します。これにより、バグが C の予測通りの場所に存在することが確認されます。 タスク 2 : Kiro は C の外側の入力に対して修正前のコードを実行し、実際の動作を記録して、その動作を主張する保持テストを書きます。各テストは修正前のコードに対してパスするはずです。 タスク 3 : Kiro は根本原因の仮説に基づいてコードを修正し、バグ条件テストと保持テストを再実行します。失敗していたバグ条件テストがパスするようになっていれば修正は成功です。保持テストは引き続きパスします。なぜなら他に何も変わっていないはずだからです。もしバグ条件テストが失敗した場合、仮説が間違っていたことになり、Kiro はフラグを立てて別の修正を試みる前に再調査します。保持テストが反転した場合、修正に副作用があることになり、Kiro はパッチのスコープを絞り込みます。どちらの結果も次のアクションにつながります。 これはテスト駆動開発のレッド・グリーンサイクルと 差分テスト (differential testing) を組み合わせたものです。バグ条件テストは修正前はレッド、修正後はグリーンになります。保持テストは修正前のコードの動作を記録し、修正後のコードが同じ入力に対して同じ動作をすることを主張します。修正前のコードが仕様として機能します。 修正前のテスト 両方のテストスイートは Hypothesis を使ったプロパティベーステストを使用します。特定のツリーに対するテストを書く代わりに、Kiro は修正プロパティと保持プロパティを宣言し、Hypothesis を使って数百のランダムなツリーを生成してそれらを確認します。（Kiro におけるプロパティベーステストの詳細については、 Kiro : コードは仕様と一致していますか？ 〜プロパティベーステストで「正しさ」を測定する〜 をご覧ください）。 なぜプロパティベーステストなのか？バグ条件はツリーの構造、具体的には node.right.left が存在するかどうかに依存します。その構造は組み合わせ的に変化します。ユニットテストでは、それをカバーするために何十ものツリーを手動で構築する必要があります。プロパティベーステストはその空間を自動的に探索し、手書きのスイートではカバーしにくい構造的な組み合わせを含む数百のツリーを生成します。 バグ条件テストによる修正プロパティの確認 from hypothesis import given, strategies as st def matches_bug_condition(node): """C(node): two children, right child has no left subtree.""" return (node.left is not None and node.right is not None and node.right.left is None) @given( values=st.lists(st.integers(min_value=1, max_value=100), min_size=3, max_size=20, unique=True) ) def test_delete_two_children_no_left_subtree(values): """Property 1: Bug Condition — delete should succeed when node has two children and right child has no left subtree. """ bst = BinarySearchTree() for v in values: bst.insert(v) # Traverses tree, returns first node where matches_bug_condition is True target = find_node_matching_bug_condition(bst.root) if target is None: return # No node matches C in this tree, skip bst.delete(target.value) # Should not crash, value should be gone, BST invariant maintained assert not bst.search(target.value) traversal = bst.inorder_traversal() assert traversal == sorted(traversal) このテストは修正プロパティをエンコードします。C が成立するすべてのツリーに対して、delete は成功し、ノードを削除し、BST の不変条件を保持するはずです。修正前のコードでは、 _find_min(None) が None.left を試みるため AttributeError で失敗します。 保持テストによる保持プロパティの確認 @given( values=st.lists(st.integers(min_value=1, max_value=100), min_size=2, max_size=20, unique=True), delete_index=st.integers(min_value=0) ) def test_delete_preserves_non_buggy_cases(values, delete_index): """Property 2: Preservation — all delete cases outside C should behave identically before and after the fix. """ bst = BinarySearchTree() for v in values: bst.insert(v) target_value = values[delete_index % len(values)] # walks tree, returns the node which stores target_value target_node = find_node(bst.root, target_value) # Skip if this node matches the bug condition if target_node and matches_bug_condition(target_node): return before_values = set(bst.inorder_traversal()) bst.delete(target_value) after_values = set(bst.inorder_traversal()) # Value should be removed, all others preserved, BST invariant held assert target_value not in after_values assert after_values == before_values - {target_value} traversal = bst.inorder_traversal() assert traversal == sorted(traversal) このテストは保持プロパティをエンコードします。C が成立しないすべてのツリー（葉の削除、1 つの子を持つノードの削除、 node.right.left が存在する 2 つの子を持つノードの削除）に対して、動作は変化しません。修正前のコードではパスします。これがベースラインです。修正後も、このテストはパスし続けなければなりません。 修正 バグ条件テストが仮説を確認し、保持テストがベースラインを記録したところで、Kiro は 1 行の修正を書きます。   # Before: min_node = self._find_min(node.right.left) # BUG # After: min_node = self._find_min(node.right) # FIXED Kiro は両方のテストスイートを再実行します。バグ条件テストがパスするようになり、修正が機能していることが検証されます。保持テストは引き続きパスし、他に何も変わっていないことが検証されます。 大規模な適用: RocketMQ のメモリリーク Kiro は大規模なコードベースでも同じように機能します。実際の例として、Apache RocketMQ の HeartbeatSyncer におけるメモリリークを見てみましょう（元の PR 、 SWE-PolyBench ）。HeartbeatSyncer は接続されたコンシューマーを並行マップで追跡します。エントリは登録時に追加され、登録解除時に削除されます。しかし、削除は一度も成功しません。マップは際限なく増大します。 バグを特定して修正するために、Kiro は同じワークフローに従います。根本原因の仮説はキーの不一致です。 // Insertion key: data.getGroup() + "@" + clientChannelInfo.getChannel().id().asLongText() // Removal key: clientChannelInfo.getChannel().id().asLongText() // BUG 挿入キーはコンシューマーグループがプレフィックスとして付加されますが、削除時のキーには付加されません。そのため両者は絶対に一致しません。登録解除は全て何もしない操作になります。バグ条件 C は、args が null でなく ClientChannelInfo を含む、あらゆる有効な CLIENT_UNREGISTER イベントです。すべての登録解除イベントでメモリリークが発生します。 // Before: remoteChannelMap.remove(clientChannelInfo.getChannel().id().asLongText()); // After: update the removal key remoteChannelMap.remove(data.getGroup() + "@" + clientChannelInfo.getChannel().id().asLongText()); 修正はやはり 1 行ですが、保持の検証はより困難です。同じリスナーを通るコードパスは5つあります。args が null の場合、args が ClienetChannelInfo でない場合、マルチグループ登録、などです。挿入ロジックや他のイベントタイプも変更されてはなりません。C の外側の各シナリオには独自の保持テストがあり、Kiro が修正を適用する前に書かれてパスしています。 まとめ プロパティ指向コード進化により、あなたと Kiro は同じ契約のもとで作業します。Kiro が境界と仮説の草案を作成し、あなたはそれにフィードバックし、再定義し、スコープを絞り込み、または別のアプローチを求めることができます。コードが書かれる時点で、何を変え、何を変えないのかについて双方が合意しています。 契約が崩れた場合、ワークフローがそれを明確にします。バグレポートが曖昧すぎて C を導出できない場合、Kiro はコードが書かれる前にフラグを立てます。根本原因の仮説が間違っている場合、バグ条件テストがそれを検出します。修正に副作用がある場合、保持テストがそれを検出します。各失敗が次に何をすべきかを教えてくれます。 プロパティ指向コード進化は、期待される振る舞いを機能的でテスト可能なプロパティとして表現できる変更に対して最も効果を発揮します。例えばロジックエラー、エッジケース、ランタイム例外、データ処理のバグなどです。一方でパフォーマンスや競合状態のような非機能的な関心事については、非決定的であり時間的推論を必要とすることが多いため、プロパティの表現がより困難です。それらをテスト可能な主張として表現する最良の方法を見つけることは、未解決の課題です。 プロパティ指向コード進化はバグ修正だけに留まりません。機能追加やリファクタリングも同じ二重の意図を持っています。境界内で動作を変更し、それ以外のすべてを保持することです。その境界はテスト可能なプロパティで強制できます。バグ修正を超えてプロパティ指向コード進化を適用することは、私たちの研究の活発な領域です。 最後に覚えておいてください。次にバグを報告するとき、あなたは境界を引いているのです。Kiroと一緒にその境界を引けば、プロパティが修正を正しい方に留めてくれます。 参考文献 State of AI vs. Human Code Generation Report Drift No More? Context Equilibria in Multi-Turn LLM Interactions Does your code match your spec? The Hypothesis Property-Based Testing Library QuickCheck SWE-PolyBench Differential testing 謝辞 プロパティ指向コード進化の方法論と Kiro のバグ修正ワークフローへの貢献に対して、Aaron Eline、Anjali Joshi、Margarida Ferreira に感謝します。 翻訳は Solutions Architect の瀬高が担当しました。

2026 年 2 月 23 日週、私は AI-DLC (AI-Driven Lifecycle) ワークショップを通じてお客様がビジネスを変革するための支援に全力で取り組みました。2026 年になってから、数多くのお客様を対象としたこれらのセッションの進行役を務め、測定可能なビジネス価値をもたらす AI ユースケースを組織が特定、優先化、実装するために役立つ構造化されたフレームワークを通じてお客様を導くというすばらしい機会に恵まれてきました。 AI-DLC は、技術的能力とビジネス成果を一致させることによって、企業が AI 実験から本番環境対応のソリューションへと移行できるようにする手法です。AI-DLC に関心をお持ちの場合は、このフレームワークを詳しく説明する こちらのブログ記事 、または Riya Dani が私に AI-DLC の全貌を教える最新の GenAI Developer Hour ライブ配信 をご覧ください! それでは、2026 年 3 月 2 日週の AWS ニュースを見ていきましょう。 OpenAI と Amazon が複数年にわたる戦略的パートナーシップを発表しました 。これは、世界中の企業、スタートアップ、エンドコンシューマーのために AI イノベーションを加速させることを目的としたパートナーシップです。Amazon は OpenAI に 500 億 USD を投資する予定です。初期投資として 150 億 USD をまず投資し、特定の条件が満たされたらその後数か月間にわたって残りの 350 億 USD を投資します。AWS と OpenAI は、OpenAI モデルを活用する Stateful Runtime Environment を共同で開発しています。この環境は Amazon Bedrock 経由で利用でき、開発者がコンテキストを保持し、以前の作業を記憶するとともに、さまざまなソフトウェアツールとデータソースを使って作業し、コンピューティングを利用することを可能にします。 AWS は、 OpenAI Frontier の独占的なサードパーティクラウドディストリビューションプロバイダーとしての役割を務めることで、組織が AI エージェントのチームを構築、デプロイ、管理できるようにします。OpenAI と AWS は、今後 8 年にわたって現行の複数年契約額 380 億 USD を 1,000 億 USD 増額します。この契約で、OpenAI は Trainium3 チップと 次世代の Trainium4 チップ の両方で約 2 ギガワットの Trainium 容量を消費することを確約しています。 2026 年 2 月 23 日週のリリース 2026 年 2 月 23 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 厳選されたパートナーソリューションによるフルスタックエンタープライズセキュリティを提供する AWS Security Hub Extended – AWS が AWS Security Hub Extended の提供を開始しました。これは、7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk、Upwind、Zscaler などのフルスタックエンタープライズセキュリティソリューションの調達、デプロイ、統合を簡素化するプランです。AWS を登録販売者としているため、お客様は事前交渉済みの従量制料金、単一の請求書、長期契約不要、Security Hub 内での統合されたセキュリティ運用といったメリットを得ることができ、AWS エンタープライズサポートのお客様は統合されたレベル 1 サポートも利用できます。 AWS Elemental Inference でライブ動画をモバイル視聴者向けに変換 – AWS が Elemental Inference の提供を開始しました。このサービスは、ライブ動画とオンデマンド動画をモバイルプラットフォームおよびソーシャルプラットフォーム向けにリアルタイムで自動変換するフルマネージド AI サービスです。このサービスは、AI を活用したクロッピングを使用して、TikTok、Instagram リール、YouTube ショート向けに最適化された縦型形式を作成し、6〜10 秒のレイテンシーでハイライトクリップを自動抽出します。ベータテストでは、大規模なメディア企業が AI 駆動のライブ動画ワークフローで 34% 以上のコスト削減を達成したことが示されています。  Fox Sports による実装 で詳細をご覧ください。 MediaConvert が新しいビデオプローブ API を導入 – AWS Elemental MediaConvert に、メディアファイルのメタデータ分析をすばやく行うための無料の Probe API が導入されました。この API は、動画コンテンツを処理することなく、ヘッダーメタデータを読み取ってコーデック仕様、ピクセル形式、色空間の詳細を返します。 Amazon Bedrock の OpenAI 互換 Projects API – Projects API は、Amazon Bedrock の Mantle 推論エンジンで OpenAI 互換 API を使用する生成 AI ワークロードにアプリケーションレベルの分離を提供します。改善されたアクセス制御、コスト追跡、オブザーバビリティを組織全体で使用して、AI アプリケーションを整理し、管理することができます。 Amazon Location Service が LLM コンテキストを導入 – Amazon Location が、キュレーションされた AI エージェントコンテキストの Kiro Power、Claude Code プラグイン、オープン Agent Skills 形式としての提供を開始しました。このため、コードの精度が向上し、ロケーションベース機能の実装が迅速化します。 Amazon EKS ノードモニタリングエージェントがオープンソースになりました – Amazon EKS ノードモニタリングエージェントが GitHub で公開されるオープンソースとなり、実装、カスタマイズ、コミュニティコントリビューションを把握できるようになりました。 AWS AppConfig が New Relic と統合 – AWS AppConfig が、機能フラグのデプロイ中におけるインテリジェントな自動ロールバックのために New Relic Workflow Automation と統合されました。この統合により、検出から修復までの時間が数分から数秒に短縮されます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 以下は、皆さんが関心を持つと思われる追加の記事とリソースです。 Introducing Strands Labs – AWS では、実験的なエージェンティック AI プロジェクトをサポートし、エージェント開発における未知の分野を開拓するための別個の Git 組織として Strands Labs を設立しました。ローンチにあたり、Strands Labs は 3 つのプロジェクトで利用可能になります。1 つ目は Robots 、2 つ目は  Robots Sim 、3 つ目は  AI Functions です。 6,000 AWS accounts, three people, one platform: Lessons learned – 大規模なマルチアカウント環境の管理に関するアーキテクチャブログ記事です。ProGlove が AWS で大規模な account-per-tenant モデルを実装した方法と、このモデルがどのように複雑性をサービスコードからプラットフォーム運用に移行させるのかを学びましょう。 Building intelligent event agents using Amazon Bedrock AgentCore and Amazon Bedrock Knowledge Bases – イベント駆動のエージェントを構築するための実用ガイドです。Amazon Bedrock AgentCore コンポーネントを使用してイベントアシスタントをすばやく本番化し、プロトタイプからエンタープライズ対応の大規模なデプロイに移行させる方法をご覧ください。 AWS コミュニティからの記事 私が個人的に気に入っている AWS コミュニティの記事をご紹介します。 How to Run a Kiro AI Coding Workshop That Actually Works – 会社またはユーザーグループで Kiro ワークショップを実施していますか? もしそうならば、こちらにある完全なステップバイステップのファシリテーターガイド、リソース、参考資料をご利用ください。 RAG vs GraphRAG: When Agents Hallucinate Answers – このデモでは、Strands Agents を使用して旅行予約エージェントを構築するとともに、RAG (FAISS) と GraphRag (Neo4j) を比較して、どちらのアプローチがクエリ回答時のハルシネーションを低減させるか測定します。 AWS CLI v2 の新しい出力形式 – AWS コマンドラインインターフェイス (AWS CLI) v2 で、構造化エラー出力と「off」出力形式の 2 つの新機能を使用できるようになりました。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS at NVIDIA GTC 2026 – 2026 年 3 月 16～19 日に米国サンノゼで開催される NVIDIA GTC 2026 で、AWS のセッション、ブース、デモ、付帯イベントに参加しましょう。AWS 経由でイベントパスの 20% 割引を受け、GTC での 1 対 1 ミーティングをリクエストできます。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスです。今後のイベントには、 JAWS Days in Tokyo (3 月 7 日)、 チェンナイ (3 月 7 日)、 スロバキア (3 月 11 日)、 プネ (3 月 21 日) が含まれます。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026 年 3 月 2 日週のニュースは以上です。2026 年 3 月 9 日週の Weekly Roundup もお楽しみに! 原文は こちら です。

2025 年の re:Invent 2025 で、AWS は根本から刷新された AWS Security Hub を 紹介 しました。AWS Security Hub は、 Amazon GuardDuty や Amazon Inspector などの AWS セキュリティサービスを単一のエクスペリエンスにまとめます。サービスを組み合わせることでセキュリティ検出結果を自動的かつ継続的に分析するこの統合エクスペリエンスは、重大なセキュリティリスクを最優先し、対応するために役立ちます。 2025 年 2 月26 日、 AWS Security Hub Extended プランが発表されました。この Security Hub プランは、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティ運用のすべてを対象とするフルスタックエンタープライズセキュリティソリューションの調達、デプロイ、統合を簡素化します。Extended プランでは、セキュリティポートフォリオを AWS 外に拡大し、7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (Cisco 企業)、Upwind、Zscaler などの選び抜かれた AWS パートナーソリューションを通じて企業資産を保護することができます。 AWS を登録販売者としているため、事前交渉済みの従量制料金、単一の請求書、長期契約不要といったメリットを得られます。また、Security Hub 内で統合されたセキュリティ運用エクスペリエンスを得られるとともに、 AWS エンタープライズサポートのお客様 は統合されたレベル 1 サポートも利用できます。ユーザーからは、複数の調達サイクルとベンダー交渉の管理によって不必要な複雑性が生み出され、時間とリソースを無駄にしているというご意見をいただいています。これを受け、AWS は単一の簡素化されたエクスペリエンスを通じてテクノロジースタック全体でより包括的な保護を確立するためのパートナーサービスを厳選しました。 すべての加入ソリューションから得たセキュリティ検出結果は Open Cybersecurity Schema Framework (OCSF) スキーマで出力され、AWS Security Hub 内で自動集計されます。Extended プランを使用すると、AWS とパートナーのセキュリティソリューションを組み合わせて、複数の境界にまたがるリスクを迅速に特定して対応できます。 Security Hub Extended プランの仕組み パートナーソリューションは、 Security Hub コンソール の [管理] メニューにある [Extended プラン] を選択することで直接アクセスできます。その後、厳選されたパートナーサービスを確認し、それらを自由に組み合わせでデプロイできます。 各パートナーサービスについては、詳細を Security Hub コンソールで直接確認し、サブスクライブできます。サブスクライブすると、各パートナーによる自動オンボーディングエクスペリエンスに転送されます。オンボーディング完了後は、使用量ベースの計測が自動的に行われ、その料金が Security Hub 請求書の一部として毎月請求されます。 AWS Security Hub では、すべてのソリューションから得たセキュリティ検出結果が自動的に集約されます。そのため、正規化された OCSF スキーマでのすべてのセキュリティ検出結果にすぐさま直接アクセスできます。 AWS Security Hub のこれらの統合を使用してセキュリティ体制を強化する方法の詳細については、 AWS Security Hub ユーザーガイド をご覧ください。 今すぐご利用いただけます AWS Security Hub Extended プランは、Security Hub を利用できるすべての AWS 商用リージョンで一般提供されています。柔軟な従量制料金または定額制料金を使用でき、先行投資や長期契約は必要ありません。料金の詳細については、 AWS Security Hub の料金ページ をご覧ください。 Security Hub コンソール で Extended プランを今すぐお試しください。フィードバックについては、 AWS re:Post for Security Hub または通常の AWS サポート窓口を通じてお寄せください。 – Channy 原文は こちら です。

2025 年 12 月 15 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer & Kiro Meetup #5: AWS re:Invent アップデート速報 & お客様の活用事例紹介 」のイベントの様子をレポートします。 登壇資料は こちらからダウンロード (zip) していただけます。 このイベントは、AWS re:Invent 2025 でアップデートのあった Kiro の機能紹介と、お客様による Amazon Q Developer / Kiroの実践活用事例をテーマに実施しました。まずソリューションアーキテクトの稲田から Kiro の概要と AWS re:Invent 2025 前後で発表されたアップデートをご紹介しました。続いて、株式会社ゼンリンデータコム様、株式会社NTTドコモ様から Amazon Q Developer / Kiro の社内展開や活用方法の事例を共有していただきました。最後に株式会社リクルート様に AI-DLC の導入状況について発表していただきました。 参加者の方からは「各社の取り組み、AIに対する考えを知ることができ非常に有意義でした。」などのご感想をいただきました。現地参加の方のみ、ケータリングをご用意し、ネットワーキングのための懇親会を実施しました。 登壇者の方への質問や、参加者同士の意見交換、AWS メンバーへの相談が活発におこなわれていました。 イベント概要 開催日時: 2025年12月15日 19:00- 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 スピーカー 株式会社ゼンリンデータコム様「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」 株式会社 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」 株式会社リクルート様「AI-DLC を現場にインストールしてみた：プロトタイプ開発で分かったこと・やめたこと」 ソリューションアーキテクト 稲田 大陸 Amazon Web Services Japan G.K. 「Amazon Q Developer および Kiro のAWS re:Invent のアップデート」 乾杯の挨拶: 事業開発マネージャー　井形 健太郎 Amazon Q Developer および Kiro の AWS re:Invent のアップデート スピーカー: ソリューションアーキテクト 稲田 大陸, Amazon Web Services Japan G.K. はじめに、ソリューションアーキテクトの稲田より、AWS re:Invent 2025 前後の Amazon Q Developer / Kiro のアップデート情報をご紹介しました。 AWS Japan 独自の Blog 連載イベント「 Kiroweeeeeeek in Japan 」をご案内し、Kiro の概要や Kiro がガイドする仕様駆動開発 (Spec Driven Development) についてもご説明しました。Kiro のアップデート情報として、GA (一般提供開始) や Kiro for Enterprise の提供開始、チェックポイントやプロパティベーステストの導入、Kiro CLI の提供開始をご紹介しました。 さらに、AWS が提供する フロンティアエージェント の一つである Kiro Autonomous Agent が生まれた背景や特徴についてご説明しました。Kiro powers といった新機能や新しい料金体系についてもご紹介しました。 株式会社ゼンリンデータコム様「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」 株式会社ゼンリンデータコム様からは、「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」と題して AWS 環境の管理業務に対する Amazon Q Developer / Kiro の活用と、全社展開における取り組みについて発表していただきました。 社内展開にあたって実施した、AWS IAM Identity Center によるマルチアカウント環境でのユーザ管理や、役割ベースの権限セットへの集約といった工夫についてお話しいただきました。さらに、利用者ごとのスキル差や誤操作リスクの緩和のための、独自のルールファイルを作成によるプロンプト入力の簡素化や MCP サーバーの利用についてもご説明いただきました。 Kiro CLI のカスタムエージェント の活用による AWS 環境管理業務の効率化の取り組みについてもご紹介いただきました。 株式会社 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」 株式会社 NTT ドコモ様からは、「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」と題して、社内の主要 Web サービス提供基盤「POPLAR」開発における Amazon Q Developer の活用状況と利用上の工夫について発表していただきました。 まず Amazon Q Developer 採用に至る経緯についてお話しいただき、活用状況として設計・実装・テスト・運用各フェーズにおける利用状況や品質・効率面での成果についてご共有いただきました。また、POPLAR の開発における Amazon Q Developer の組織的な活用のための取り組みについて利用ガイドラインの策定・周知や利用状況の可視化といった具体例を挙げてご説明いただきました。最後に、Kiro の採用も含めた今後の展望についてご紹介いただきました。 POPLAR における Amazon Q Developer の活用状況の詳細については AWS ブログ 「 NTTドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用 」もぜひご覧ください。 株式会社リクルート様「AI-DLC を現場にインストールしてみた：プロトタイプ開発で分かったこと・やめたこと」 株式会社リクルート様からは、「AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと」と題して、AI を最大限ソフトウェア開発に活用する手法として提唱されている AI-DLC (AI-Driven Development Lifecycle, AI 駆動開発ライフサイクル) の活用状況について発表していただきました。 まずソフトウェア開発フェーズやタスクの計画を AI で作成する、検討内容は AI でドキュメント化する、AI の成果物は人間がレビューし、必要に応じて AI との質疑応答を取り入れる、などのテクニックについておさらいとしてご説明いただきました。 AI-DLC を実プロジェクトに取り入れる上での各フェーズでの流れやプロンプト、アウトプットの例をご紹介いただきました。最後に AI-DLC の採用に向いているプロジェクトの要素として、求められる品質やリードタイム、既存のインプット、チームの状況といった観点からそれぞれご説明いただきました。 株式会社リクルート様の登壇資料は「 AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと 」からご覧いただけます。 AI-DLC の詳細については過去の開催報告 「 [資料公開 & 開催報告] Amazon Q Developer Meetup #3 を開催しました 」 や、AWS ブログ 「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」 をご覧ください。 おわりに 今回の Amazon Q Developer & Kiro Meetup #5 では、AWS re:Invent 2025 でアップデートのあった Kiro の機能紹介と、お客様による Amazon Q Developer / Kiroの実践活用事例をテーマとして開催させていただきました。株式会社ゼンリンデータコム様、株式会社NTTドコモ様、株式会社リクルート様にご登壇いただき、各社での取り組みや工夫、得られた知見についてお話しいただきました。 今後も、開発者の皆様が生成 AI をより有効に活用していただくための AI-DLC をはじめとしたプラクティスや Amazon Q Developer や Kiro といったツールについて発信・アップデートをお届けします。 筆者 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用・AI エージェントの開発をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

本稿は株式会社タイミー様と AWS Japan の共同執筆により、AI 駆動開発ライフサイクル（AI-DLC）Unicorn Gym の実践を通じて得られた学びと今後の取り組みをお伝えするものです。 はじめに 株式会社タイミー様（以下同社）は、スキマバイトサービス「タイミー」を展開しているスタートアップ企業です。同社では個々のチーム/エンジニアが独自の方法で AI を活用し生産性を高めている一方で、次のステップとして組織全体でどう活用していくかが課題となっていました。 この課題に対して、同社と AWS は 2026 年 1 月 26 日から 28 日の 3 日間にわたり、AI-DLC Unicorn Gym を共同で実施しました。AI-DLC は、要件定義からリリースまでの開発プロセス全体に AI を深く組み込むことで、従来のアジャイル開発を大幅に加速する開発手法です。本記事では、その実践から得られた成果と学びを共有します。 AI-DLC の詳細については、 AI-DLC のホワイトペーパー と 日本語の解説ブログ をご覧ください。 これまでの課題 同社では、すでに多くのメンバーが AI ツールを活用していましたが、その活用は個人レベルにとどまっていました。各自が独自の方法論を編み出し、それぞれのやり方で生産性を高めていたものの、組織全体として最適化できているとは言えない状況でした。 特に以下のような課題が顕在化していました。 まず、チーム間での開発手法のばらつきです。個々人もしくは特定チーム個別でAI最適化をしているが、組織的な最適化ができていませんでした。 次に、既存コードベースへの AI 適用の難しさです。事業成長とともに大きくなったコードベースに対して、AI がどこまで有効に機能するのか、手探りの状態でした。 これらの課題を解決し、組織全体での AI 活用を加速させるため、同社は AI-DLC Unicorn Gym への参加を決定しました。 AI-DLC Unicorn Gym の実施内容 今回の AI-DLC Unicorn Gym では、同社から 11 チーム、約 69 名のメンバーが参加しました。参加者の構成は、エンジニア（Backend、Frontend、Mobile、データエンジニア）、PdM、デザイナー、QA、EM/GM と多岐にわたり、職種を超えた会社横断的な取り組みとなりました。各チームは実際にプロダクション環境に搭載予定の機能をテーマとして持ち込み、開発に取り組みました。 以下は各チームの取り組み内容と成果の一部です。 チーム名 取り組み内容 参加者構成 成果 A モバイルアプリ機能追加 Mobile、Backend、Design、PdM、その他（計 7 名） デモ環境へのデプロイ、Unicorn Gym 実施翌週にリリース B 自然言語での分析エージェント データエンジニア、EM/GM（計 4 名） ステージング環境での動作確認 C コスト算出パイプライン データエンジニア、PdM（計 5 名） ステージング環境での動作確認 D アップロード画像の OCR Backend、Frontend、QA、PdM、EM/GM（計 6 名） MVP 構築完了 E 新規画面追加 Backend、Mobile、Design、PdM、その他（計 7 名） デモ環境へのデプロイ F マッチングアシスト機能 Backend、Mobile、PdM（計 6 名） MVP 構築完了 G 既存機能のサブシステム化 Backend、QA、EM/GM、その他（計 6 名） MVP 構築完了 H アカウント管理機能 Backend、Frontend、QA、PdM（計 8 名） MVP 構築完了 I 既存機能の制約解除 Backend、QA、PdM（計 6 名） プロダクション環境へのデプロイ J 既存機能改修 Backend、Frontend、Design、PdM（計 9 名） デモ環境へのデプロイ K 既存システム改修 Backend、Mobile、Design、PdM、EM/GM（計 6 名） ステージング環境での動作確認 AI DLC を通した開発生産性向上に関して、参加者の 5 段階評価のアンケートから得られた同社における示唆は以下の通りです。従来の開発方法と比較して改善効果を感じた方は、Inception フェーズで平均 4.16 と高い値であった一方、Construction フェーズでは 3.30 という結果を得ました。 この結果は、Inception フェーズでモブワークや AI との対話によって要件を決める速度/精度が向上した一方、Construction フェーズではすでに個々人の AI Agent 活用の最適化が一定程度進んでいたため、Inception と比較して低いアンケート結果となったのではないかと考えています。また、今回は既存プロダクトへの追加をテーマとしていましたが、新規開発/既存機能への追加/リファクタリングなど、開発対象によっても Construction フェーズによる開発生産性への貢献度が変わると考えています。 AI-DLC Unicorn Gym からの学び 3 日間の実践を通じて、多くの貴重な学びを得ました。参加者のフィードバックから AI-DLC の知見を共有します。 モブワークの効果と課題 AI-DLC の特徴の一つは、複数人が同期的に作業を進める「モブワーク」です。今回の Unicorn Gym では、オフラインでの同期的作業の効果を強く実感しました。 参加者からは「モブワークが濃密で、チームの結束が上がった」「普段からやっていることと対して変わらなかったが、オフラインで集まることで議論が加速した」という声が上がっています。チーム間の結束力が向上し、組織全体の一体感が生まれました。 一方で、課題も明確になりました。最も多く挙がったのが、体力的な負荷の高さです。「常に脳をフル回転させ続ける必要があり、大きな疲労感を伴う」「めちゃくちゃ疲れた」という声が複数ありました。また、同社はフルリモート環境を基本としているため、「同時に一人しか話せないのでオンラインでのモブワークが難しそう」という指摘もありました。 今後は、オンライン環境に最適化したプロセスの構築や、疲労マネジメントへの対応が必要となります。 職種を超えたコラボレーション AI-DLC のもう一つの特徴は、PdM、デザイナー、エンジニアが同期的に作業を進めることです。従来の非同期なプロセスでは、PdM がビジネス要件を詰めて開発に調査を依頼し、フィードバックを待つ必要がありました。AI-DLC ではその場で技術的な実現可能性を確認しながら要件を詰められるため、リードタイムが大幅に削減されました。 特に Inception フェーズでの多職種参加の効果が顕著でした。参加者からは「普段なかなか開発レビューを見る機会が少なかったので、どんな風に開発を進めていくのかが大きな学びになった」「PdM として Inception の中の、特にユーザーストーリー作成の部分を参考に取り入れてみたい」という声が上がりました。 一方で、Construction フェーズでは役割分担の最適化が課題となりました。「作業が本格的なコーディングフェーズへ移行すると、エンジニア以外のメンバーがプロセスの詳細を追いきれず、議論から距離ができてしまう状況も発生した」という指摘がありました。フェーズごとに適切な参加メンバーを調整する必要があることが明確になりました。 参加者の声 ポジティブな声 AI を中心にすることで人間のファシリテーションを不要にできる兆しを感じました。Inception フェーズで AI が人間に問いを投げて『人間は意思決定に集中する』という経験ができたのが貴重でした モブワークが濃密で、チームの結束が上がった。全体的な話で、同期的に集まって開発することが組織としてもほぼ初めてだったが、概ね好評のように感じたし、組織・チームの結束が上がるのがわかった AI の並列性と、ユーザーストーリーに対する AI がフォローしてくれるやり方が素晴らしい 課題として挙げられた声 既存システムの仕様調査に時間がかかった。既存のコードがあまり綺麗じゃなく設計思想があまりない状態なので、その上で開発させるのが難しそう コンテキストの分散、属人化のリスク。PO のみが持っているコンテキストが多かった 体力的な負荷が高い。常に脳をフル回転させ続ける必要があり、大きな疲労感を伴う 今後の取り組み AI-DLC Unicorn Gym で得た知見を単なる体験に留めず、実務へ還元していくために、同社では以下の取り組みを検討しています。 組織への展開 各チームでの AI-DLC 適用を推進していきます。各チームが行った AI-DLC で良い取り組みがあれば、社内でナレッジシェアをしてより良い方法に洗練化していきます。実際に、参加チームのうち 7 チームが Unicorn Gym を実施した次の週から更なる精錬化/施策として AI-DLC を実践しています。 また、同社はフルリモート環境を基本としているため、オンライン環境に最適化したプロセスの構築が重要な課題となります。「オンラインでのモブワークが難しそう」という声を踏まえ、リモート環境でも効果的に AI-DLC を実践できる方法を模索していきます。 ナレッジの蓄積と共有 AI-DLC の効果を最大化するためには、AI が参照できる形でのナレッジ蓄積が不可欠です。Docs-as-Code の推進により、ドメイン知識をドキュメント化し、AI が常に最新の設計方針や規約を参照できる状態を整えていきます。 「コンテキストの分散、属人化のリスク」という課題に対応するため、AI が参照できる共通ガードレールの整備を進めます。これにより、チーム内/間でのナレッジ共有が促進され、組織全体の開発効率が向上することが期待されます。 まとめ 今回の AI-DLC Unicorn Gym を通じて、同社は個人レベルの AI 活用から組織レベルの活用へと大きく前進しました。3 日間で 全てのチームが MVP を実装しました。加えて、一部チームでは、ステージング環境やプロダクション環境へのデプロイ、リリース計画に取り入れました。 一方で、既存コードベースの複雑さ、オンライン環境での適用、疲労マネジメントなど、実務適用に向けた課題も明確になりました。これらの課題に対して、同社は継続的な改善と適応により、さらなる生産性向上を目指していきます。 AI-DLC は単なるツール導入ではなく、開発プロセスそのものを再設計する取り組みです。この学びを社内に展開し、より多くのプロジェクトで AI-DLC で得た経験や考え方を取り入れ、タイミー様の更なる開発文化の洗練化に貢献できることを願っています。 鈴木 大樹 (Daiki Suzuki) はAWS Japan のソリューションアーキテクト。データベース領域を得意としており、主に toC 向けのサービスを行っているお客様を支援している。

2025 年 12 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Linux Amazon Linux は、AWS 向けに最適化された汎用 Linux OS です。本セミナーでは Amazon Linux の概要と最新情報、Amazon Linux 2023 への移行に関する注意点などをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Linux の特徴を知りたい方 Amazon Linux 2 から Amazon Linux 2023 への移行を検討されている方 商用 Linux を利用中で Amazon Linux の利用を検討されている方 本 BlackBelt で学習できること Amazon Linux の特徴を理解し、最新 OS である Amazon Linux 2023 への移行方法を学ぶことができます。 スピーカー 阿部 純一郎 ソリューションアーキテクト Amazon EKS × AWS アカウント アーキテクチャパターン Amazon EKS x AWS アカウントという 2 つの側面から、AWS で構築するプラットフォームのアーキテクチャパターンを解説します。 資料（ PDF ） 対象者 Amazon EKS に関心がある方、またはご利用予定の方 AWS アカウント構成について検討している方 AWS および Amazon EKS を活用したプラットフォームのアーキテクチャについて学びたい方 本 BlackBelt で学習できること Amazon EKS x AWS アカウントという 2 つの側面から、AWS で構築するプラットフォームのアーキテクチャパターンを解説しています。どのような観点でアーキテクチャを検討し、実現のためにどのようなサービスを活用できるのか、コンテナ/アカウント管理/ネットワークなど、複数の技術領域にまたがる包括的なガイドを提供します。 スピーカー 後藤 健汰 / 桂井 俊朗 ソリューションアーキテクト / シニアソリューションアーキテクト AWS Advanced JDBC Wrapper Driver 概要 AWS Advanced JDBC Wrapper Driver は、ネイティブの PostgreSQL、MySQL、MariaDB の JDBC ドライバーをラップ”し、ドライバー機能を拡張したドライバーです。AWS Advanced JDBC Wrapper Driver を利用することで、Aurora などのクラスター化されたデータベース機能を最大限に活用することが可能です。本コンテンツでは AWS Advanced JDBC Wrapper Driver の概要を扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS で Amazon Aurora / RDS の利用を利用中、または今後検討予定の⽅ データベースアクセスに JDBC ドライバーを利用中、または利用予定であり、データベースの機能を最大限に活用する上でアプリケーション実装の手間を簡略化したい方 本 BlackBelt で学習できること AWS Advanced JDBC Wrapper Driver の概要および主要な機能について抑えることがきる スピーカー 永末 健太 データベーススペシャリストソリューションアーキテクト Amazon RDS Proxy 概要 Amazon RDS Proxy は、Amazon Aurora/RDS 向けの高可用性フルマネージド型のデータベースプロキシーで、データベースへの接続を効率的に管理し、アプリケーションのスケーラビリティやデータベース障害に対する回復力と安全性の向上を実現することが可能です。本コンテンツは Amazon RDS Proxy の概要を取り扱います。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS で Amazon Aurora / RDS の利用を検討中、または今後検討予定の⽅ 接続プーリングの実装やフェイルオーバーの高速化を実現したいが、アプリケーションは極力変更したくない方 本 BlackBelt で学習できること Amazon RDS Proxy の概要およびユースケースについて抑えることができる スピーカー 永末 健太 データベーススペシャリストソリューションアーキテクト AWS CodePipeline 基礎編 AWS CodePipeline は、ビルド、テスト、デプロイといったソフトウェアのリリースプロセスをモデル化・視覚化・自動化できるフルマネージドな継続的デリバリーサービスです。 本セミナーでは、CI/CD 導入によるメリットや AWS CodePipeline の概要について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 開発からリリースまでのプロセスを効率化したい方、特に自動化について関心をお持ちの方 リリースの自動化を支援する AWS サービスとして、どういったものがあるかに興味がある方 AWS CodePipeline の概要や機能を知りたい方 本 BlackBelt で学習できること CI/CD の導入がソフトウェア開発において重要となる背景 AWS 上での CI/CD 実装に活用できるサービスや機能について AWS CodePipeline の特徴や主要コンポーネント、機能 スピーカー Gereltod Sengun クラウドサポートエンジニア Two-Pizza Team Amazon が実践する「Two-Pizza Team」について解説します。5-10 人の小規模チームに明確な責任と権限を与えるこの組織アプローチについて、4つの特徴（シングルスレッド・リーダー、プロダクト中心の編成、ガードレール方式、信頼ベースの文化）と導入のポイントを紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 チームの意思決定スピードに課題を感じている方 チーム間の依存関係によって開発に影響が出ている方 メンバーの当事者意識を高めたいリーダー・マネージャー 新しいチーム編成を検討している組織 本 BlackBelt で学習できること Two-Pizza Team の全体像や導入のメリット、注意点などに関して学習いただけます。 スピーカー 仁科 みなみ カスタマーソリューションマネージャー

本記事は 2026 年 3 月 4 日 に公開された「 How Amplitude implemented natural language-powered analytics using Amazon OpenSearch Service as a vector database 」を翻訳したものです。 本記事は、Amplitude の共同創業者兼チーフアーキテクトである Jeffrey Wang 氏が AWS と共同で執筆したゲスト投稿です。 Amplitude は、プロダクトおよびカスタマージャーニー分析プラットフォームです。お客様はプロダクトの利用状況について深い質問をしたいと考えていました。Ask Amplitude は大規模言語モデル (LLM) を活用した AI アシスタントです。スキーマ検索とコンテンツ検索を組み合わせ、カスタマイズされた正確かつ低レイテンシーの自然言語ベースの可視化体験をエンドカスタマーに提供します。Ask Amplitude はユーザーのプロダクト、分類体系、言語を理解した上で分析のフレームを構築します。一連の LLM プロンプトを使ってユーザーの質問を JSON 定義に変換し、カスタムクエリエンジンに渡します。クエリエンジンが回答をチャートとしてレンダリングする仕組みを次の図に示します。 Amplitude の検索アーキテクチャは、 Amazon OpenSearch Service を活用したセマンティック検索と Retrieval Augmented Generation (RAG) を実装し、スケーラビリティの向上、アーキテクチャの簡素化、コスト最適化を実現しました。本記事では、Amplitude のアーキテクチャの反復的な進化と、スケーラブルなセマンティック検索・分析プラットフォームの構築における重要な課題への対処方法を紹介します。 主な目標は、セマンティック検索と自然言語によるチャート生成を大規模に実現しつつ、きめ細かなアクセス制御を備えたコスト効率の高いマルチテナントシステムを構築することでした。エンドツーエンドの検索レイテンシーの最適化と迅速な結果の提供も重要でした。また、エンドカスタマーが既存のチャートやコンテンツを安全に検索・活用し、より高度な分析を行えるようにすることも目指しました。さらに、大規模なリアルタイムデータ同期の課題にも対処し、常に流入するデータ更新を処理しつつ、システム全体で低い検索レイテンシーを維持するソリューションを開発しました。 Ask Amplitude における RAG とベクトル検索 Ask Amplitude が RAG を使用する理由を簡単に見てみましょう。Amplitude はオムニチャネルの顧客データを収集します。エンドカスタマーは自社プラットフォーム上でユーザーが行ったアクションのデータを送信します。これらのアクションはユーザー生成イベントとして記録されます。例えば、小売・EC のお客様の場合、ユーザーイベントには「商品検索」「カートに追加」「購入手続き」「配送オプション」「購入」などがあります。これらのイベントがお客様のデータベーススキーマ (テーブル、カラム、リレーションシップ) を定義します。「2 日配送を利用した人は何人ですか？」というユーザーの質問を考えてみましょう。LLM は、キャプチャされたユーザーイベントのどの要素がクエリへの正確な回答に関連するかを判断する必要があります。ユーザーが Ask Amplitude に質問すると、最初のステップとして OpenSearch Service から関連イベントをフィルタリングします。コストと精度の両面から、すべてのイベントデータを LLM に送るのではなく、選択的なアプローチを取ります。LLM の利用料金はトークン数に基づくため、完全なイベントデータを送信するのは不必要にコストがかかります。さらに重要なのは、コンテキストが多すぎると LLM のパフォーマンスが低下することです。数千のスキーマ要素を与えると、モデルは関連情報を確実に特定して集中することが難しくなります。情報過多は LLM を本来の質問から逸らし、ハルシネーションや不正確な回答につながる可能性があります。RAG が好まれるのはこのためです。プロダクト利用スキーマから最も関連性の高い項目を取得するために、ベクトル検索を実行します。お客様のスキーマに含まれる正確な単語を質問が参照していない場合でも効果的です。以降のセクションでは、Amplitude の検索の進化を順を追って説明します。 初期ソリューション: セマンティック検索なし プライマリデータベースとして Amazon Relational Database Service (Amazon RDS) for PostgreSQL を使用し、ユーザー、イベント、プロパティデータを保存していました。ただし、次の図のように、キーワード検索の実装にはサードパーティの別のストアを使用していました。PostgreSQL からこのサードパーティの検索インデックスにデータを取り込み、最新の状態に保つ必要がありました。 このアーキテクチャはシンプルでしたが、2 つの大きな課題がありました。検索インデックスに自然言語機能がないこと、そしてキーワード検索しかサポートしていないことです。 イテレーション 1: 総当たりコサイン類似度 検索機能を改善するため、いくつかのプロトタイプを検討しました。ほとんどのお客様のデータ量はそれほど大きくなかったため、PostgreSQL を使ったベクトル検索のプロトタイプを素早く構築できました。ユーザーインタラクションデータをベクトル埋め込みに変換し、 配列コサイン類似度 を使ってデータセット全体の類似度メトリクスを計算しました。カスタムの類似度計算は不要になりました。ベクトル埋め込みは、追加のインフラの負荷なしに PostgreSQL の機能を使って、ユーザー行動の微妙なパターンをキャプチャしました。これは一般に 総当たり法 と呼ばれ、受信クエリをすべての埋め込みと照合し、距離尺度 (この場合はコサイン類似度) によって上位 K 件の近傍を見つけます。アーキテクチャを次の図に示します。 セマンティック検索の導入は、同じ概念を異なる用語で表現するユーザー (「動画視聴時間」と「総再生時間」など) にとって、従来の検索から大きな改善でした。しかし、小規模なデータセットでは機能したものの、総当たり法はすべてのベクトルペアのコサイン類似度を計算する必要があるため低速でした。イベントスキーマの要素数、質問の複雑さ、品質への期待が高まるにつれ、この問題は増幅されました。さらに、Ask Amplitude の回答にはセマンティック検索とキーワード検索の両方を組み合わせる必要がありました。両方の検索を組み合わせるため、各検索クエリは複数のデータベースへの呼び出しを伴う 3 ステップのプロセスとして実装する必要がありました。 PostgreSQL からセマンティック検索結果を取得する。 検索インデックスからキーワード検索結果を取得する。 アプリケーション内で、セマンティック検索結果とキーワード検索結果を事前に割り当てた重みで結合し、Ask Amplitude の UI に出力する。 複数ステップの手動アプローチにより、検索プロセスは複雑になりました。 イテレーション 2: pgvector による ANN 検索 Amplitude の顧客基盤が拡大するにつれ、Ask Amplitude はより多くのお客様と大規模なスキーマに対応する必要がありました。目標は単に質問に答えるだけでなく、ユーザーを反復的にガイドしてエンドツーエンドの分析を構築する方法を教えることでした。そのため、埋め込みにはコンテキストが豊富なセマンティックコンテンツを保存しインデックス化する必要がありました。チームはより大きく高次元の埋め込みを試し、ベクトルの次元数が検索の有効性に影響するという経験的な観察を得ました。多言語埋め込みのサポートも要件でした。 よりスケーラブルな k-NN 検索をサポートするため、チームは高次元空間でのベクトル操作に強力な機能を提供する PostgreSQL 拡張機能の pgvector に切り替えました。アーキテクチャを次の図に示します。 pgvector は高次元ベクトルの k 最近傍 (k-NN) 類似度検索をサポートできました。ベクトル数が増加するにつれ、 HNSW や IVFFlat などの近似最近傍 (ANN) 検索を可能にするインデックスに切り替えました。 大規模なスキーマを持つお客様では、総当たりコサイン類似度の計算は低速でコストがかかりました。pgvector による ANN に移行したことでパフォーマンスの改善が見られました。しかし、PostgreSQL でのセマンティック検索、別の検索インデックスでのキーワード検索、そしてそれらを統合するという 3 ステップのプロセスの複雑さには依然として対処が必要でした。 イテレーション 3: OpenSearch Service によるキーワード検索とセマンティック検索のデュアル同期 お客様の数が増えるにつれ、スキーマの数も増加しました。データベースには数億のスキーマエントリがあったため、パフォーマンスが高くスケーラブルでコスト効率の良い k-NN 検索ソリューションを求めていました。OpenSearch Service と Pinecone を検討した結果、キーワード検索とベクトル検索の機能を統合できる OpenSearch Service を選択しました。選択の理由は 4 つあります。 シンプルなアーキテクチャ – OpenSearch Service のように、セマンティック検索を既存の検索ソリューションの機能として位置づけることで、専用サービスとして扱うよりもシンプルなアーキテクチャになります。 低レイテンシーの検索 – 検索データを効果的に整理・分類する機能は、回答生成の基盤でした。セマンティック検索を既存のパイプラインに追加し、両方を 1 つのクエリに統合することで、低レイテンシーのクエリを実現しました。 データ同期の削減 – データベースと検索インデックスの同期維持は、回答の精度と品質に不可欠でした。検討した他の選択肢では、キーワード検索インデックス用とセマンティック検索インデックス用の 2 つの同期パイプラインを維持する必要があり、アーキテクチャが複雑化し、キーワード検索とセマンティック検索の結果が不整合になるリスクが高まりました。1 か所に同期する方が、複数の場所に同期してクエリ時にシグナルを結合するよりも容易です。OpenSearch Service のキーワード検索とベクトル検索の統合機能により、PostgreSQL のプライマリデータベースと検索インデックスの同期が 1 つだけで済むようになりました。 ソースデータ更新へのパフォーマンス影響の最小化 – 別の検索インデックスへのデータ同期は、データセットが常に変化するため複雑な問題でした。新しいお客様が増えるたびに、毎秒数百の更新がありました。同期プロセスによってこれらの更新のレイテンシーが影響を受けないようにする必要がありました。検索データとベクトル埋め込みを同じ場所に配置することで、複数の同期プロセスが不要になりました。同期プロセスがデータベース更新トラフィックに干渉することによるプライマリデータベースの追加レイテンシーも回避できました。 以前のサードパーティ検索エンジンは高速な EC 検索に特化していましたが、Amplitude の特定のニーズには合致していませんでした。OpenSearch Service への移行により、2 つの同期プロセスを 1 つに削減してアーキテクチャを簡素化しました。既存の検索プラットフォームは段階的に廃止しました。つまり、次の図のように、既存プラットフォームへの同期と OpenSearch Service 上の統合キーワード・セマンティック検索インデックスへの同期の 2 つのプロセスが一時的に並行して存在しました。 前のイテレーションで特定した k-NN 検索の利点に加え、OpenSearch Service への移行で 3 つの主要なメリットを実現しました。 レイテンシーの削減 – 埋め込みをプライマリデータと同じ場所に配置する代わりに、検索インデックスと同じ場所に配置できました。検索インデックスは、質問に関連するユーザーイベントを抽出して LLM にコンテキストとして送信するためにクエリを実行する場所です。検索テキスト、メタデータ、埋め込みがすべて 1 か所にあるため、すべての検索要件に対して 1 回のホップで済み、レイテンシーが改善しました。 コンピューティングリソースの削減 – ユーザーイベントスキーマには 5,000〜20,000 の要素がありました。各ユーザークエリに必要なのは 20〜50 の関連要素だけなので、スキーマ全体を LLM に送る必要はありませんでした。OpenSearch Service の効率的なフィルタリング機能により、テナント固有のメタデータを使ってベクトル検索空間を絞り込み、マルチテナント環境全体のコンピューティング要件を大幅に削減できました。 スケーラビリティの向上 – OpenSearch Service では、 HNSW プロダクト量子化 (PQ) や バイト量子化 などの追加機能を活用できました。バイト量子化により、リコールの低下を最小限に抑えつつ、数百万のベクトルエントリを処理でき、コストとレイテンシーが改善しました。 ただし、この暫定ソリューションでは、データの OpenSearch Service への完全な移行はまだ完了していませんでした。旧パイプラインと新パイプラインが並行して存在し、デュアル同期が必要でした。旧検索インデックスを段階的に廃止する一時的な過程であり、旧パイプラインはパフォーマンスとリコールの比較基準として機能しました。 イテレーション 4: OpenSearch Service によるハイブリッド検索 最終アーキテクチャでは、次の図のように、すべてのデータを OpenSearch Service に移行し、ベクトルデータベースとしても機能させました。 PostgreSQL データベースから統合検索・ベクトルインデックスへのデータ同期が 1 つだけで済むようになり、データベースのリソースをトランザクショントラフィックに集中できるようになりました。OpenSearch Service は検索結果のマージ、重み付け、ランキングを同一クエリ内で提供します。アプリケーション内で別モジュールとして実装する必要がなくなり、単一のスケーラブルなハイブリッド検索 (キーワードベース (字句) 検索とベクトルベース (セマンティック) 検索の統合) を実現しました。OpenSearch Service では、 Amazon Personalize との新しい 統合 も試すことができました。 ユーザー生成コンテンツを活用した RAG の進化 お客様は、スキーマ (データカラムの構造と名前) だけでは答えられない、プロダクト利用状況に関するより深い質問をしたいと考えていました。データベースのカラム名を知っているだけでは、データの意味、値、適切な解釈が必ずしも明らかになりません。スキーマだけでは不完全な情報しか得られません。単純なアプローチとしては、スキーマだけでなくすべてのデータ値をインデックス化して検索する方法がありますが、Amplitude はスケーラビリティの理由からこれを避けています。イベントデータのカーディナリティとボリューム (潜在的に数兆のイベントレコード) を考えると、すべての値のインデックス化はコスト的に現実的ではありません。Amplitude は全お客様で約 2,000 万のチャートとダッシュボードをホストしています。ユーザー生成コンテンツは貴重で、他のユーザーが過去にデータをどのように可視化したかを分析することで、データの意味とコンテキストをより深く理解できることがわかりました。例えば、ユーザーが「2 日配送」について質問した場合、Amplitude はまずデータスキーマに「shipping」や「shipping method」のような関連するカラム名があるかを確認します。該当するカラムがあれば、そのカラムの潜在的な値を調べて 2 日配送に関連する値を見つけます。さらに、ユーザーが作成したコンテンツ (チャート、ダッシュボードなど) を検索し、社内の他のユーザーが 2 日配送に関連するデータを既に可視化しているかを確認します。該当する場合、その既存のチャートをデータのフィルタリングと分析方法のリファレンスとして活用できます。ユーザー生成コンテンツを効率的に検索するため、Amplitude はキーワード検索とベクトル類似度 (セマンティック) 検索を組み合わせたハイブリッドアプローチを採用しています。テナント分離とプルーニングには、メタデータを使ってまずお客様でフィルタリングし、その後ベクトル検索を行います。 まとめ 本記事では、Amplitude が OpenSearch Service をベクトルデータベースとして活用し、プロダクト分析データを自然言語でクエリできる AI アシスタント Ask Amplitude を構築した方法を紹介しました。4 回のイテレーションを経てシステムを進化させ、最終的にキーワード検索とセマンティック検索を OpenSearch Service に統合しました。これにより、複数の同期パイプラインを 1 つに簡素化し、検索オペレーションの統合でクエリレイテンシーを削減し、HNSW PQ やバイト量子化などの機能を活用して大規模なマルチテナントベクトル検索を効率的に実現しました。スキーマ検索を超えて 2,000 万のユーザー生成チャートとダッシュボードをインデックス化し、ハイブリッド検索を使ってプロダクト利用状況に関するお客様の質問に答えるためのより豊富なコンテキストを提供するようシステムを拡張しました。 自然言語インターフェースの普及が進む中、Amplitude の反復的な取り組みは、OpenSearch Service のようなベクトルデータベースを使った LLM と RAG の活用により、豊かな対話型カスタマーエクスペリエンスを実現する可能性を示しています。キーワード検索とセマンティックベクトル検索を統合した検索ソリューションへの段階的な移行により、Amplitude はアーキテクチャの複雑さを軽減しながらスケーラビリティとパフォーマンスの課題を克服しました。OpenSearch Service を使った最終アーキテクチャにより、効率的なマルチテナンシーときめ細かなアクセス制御を実現し、低レイテンシーのハイブリッド検索も可能になりました。Amplitude はより深いインサイトを生成しデータをコンテキスト化することで、お客様により自然で直感的な分析機能を提供しています。 Ask Amplitude が Amplitude 関連の概念や質問を自然言語で表現する方法について詳しくは、 Ask Amplitude を参照してください。OpenSearch Service をベクトルデータベースとして使い始めるには、 Amazon OpenSearch Service as a Vector Database を参照してください。 著者について Jeffrey Wang Jeffrey は、Amplitude の共同創業者兼元チーフアーキテクトです。Amplitude で毎秒数十億のイベントをスキャンするインフラストラクチャの基盤を構築しました。Stanford 大学でコンピュータサイエンスを学び、Palantir や Sumo Logic でのインフラストラクチャ構築の経験があります。 Preethi Kumaresan Preethi は、機械学習、生成 AI、エンドツーエンドのクラウドソリューションのテクノロジーリーダーです。現在 AWS のシニア生成 AI ソリューションアーキテクトとして、Google、Cisco、VMware、および急成長スタートアップで 15 年以上のチームおよびプロダクトリーダーシップの経験を活かしています。University of California, Santa Cruz で修士号を取得し、余暇には旅行やアウトドア、スノーボードを楽しんでいます。 Sekar Srinivasan Sekar は、AWS のシニアスペシャリストソリューションアーキテクトとして、ビッグデータと分析を担当しています。20 年以上のデータ関連の経験があり、お客様がアーキテクチャをモダナイズしてデータからインサイトを得るスケーラブルなソリューションの構築を支援することに情熱を注いでいます。余暇には非営利プロジェクト、特に恵まれない子どもたちの教育に関するプロジェクトに取り組んでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

  本ブログは 2026 年 2 月 26 日に公開された AWS Blog、” AWS Security Hub Extended offers full-stack enterprise security with curated partner solutions ” を翻訳したものです。 re:Invent 2025 で、 Amazon GuardDuty や Amazon Inspector を含む AWS セキュリティサービスを単一の利用体験に統合した、完全に再設計された AWS Security Hub を 発表しました 。この統合された利用体験は、セキュリティ検出結果を組み合わせて自動的かつ継続的に分析し、重要なセキュリティリスクの優先順位付けと対応を支援します。 本日、 AWS Security Hub Extended を発表します。 これは Security Hub のプランで、エンドポイント、ID、メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティ運用を含むフルスタックのエンタープライズセキュリティソリューションの調達、デプロイ、統合を簡素化します。 Extended プランでは、7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (a Cisco company)、Upwind、Zscaler を含む厳選された AWS パートナーソリューションを通じて、AWS を超えてセキュリティポートフォリオを拡張し、企業の IT 環境全体の保護を支援します。 AWS が販売者となることで、事前に交渉された従量課金制の料金、単一の請求書、長期契約なしというメリットを享受できます。 また、Security Hub 内で統合されたセキュリティオペレーション体験と、 AWS Enterprise Support のお客様 向けの統合されたレベル 1 サポートを利用できます。 複数の調達サイクルとベンダー交渉の管理が不必要な複雑さを生み出し、時間とリソースを費やしているというご意見をいただきました。 これに応えて、単一の簡素化された体験を通じて、テクノロジースタック全体にわたってより包括的な保護を確立できるよう、これらのパートナーソリューションをご提供しています。 参加しているすべてのソリューションからのセキュリティ検出結果は、 Open Cybersecurity Schema Framework (OCSF) スキーマで出力され、AWS Security Hub に自動的に集約されます。 Extended プランでは、AWS とパートナーのセキュリティソリューションを組み合わせて、複数の境界にまたがるリスクを迅速に特定し、対応できます。 Security Hub Extended プランの実際 Management メニューの下にある Extended plan を選択することで、 Security Hub コンソール 内でパートナーソリューションに直接アクセスできます。 そこから、厳選されたソリューションとパートナー提供のソリューションの任意の組み合わせを確認してデプロイできます。 各パートナーの提供内容の詳細は、Security Hub コンソールで直接確認でき、サブスクライブすることができます。 サブスクライブすると、各パートナーの自動オンボーディング体験に誘導されます。 オンボーディングが完了すると、従量課金が自動的に行われ、Security Hub の請求の一部として毎月請求されます。 すべてのソリューションからのセキュリティ検出結果は、AWS Security Hub に自動的に統合されます。 これにより、OCSF スキーマに正規化されたすべてのセキュリティ検出結果に即座に直接アクセスできます。 AWS Security Hub とのこれらの統合によってセキュリティ態勢を強化する方法の詳細については、 AWS Security Hub ユーザーガイド をご覧ください。 提供開始 AWS Security Hub Extended プランは、Security Hub が利用可能なすべての AWS 商用リージョンで一般提供が開始されました。 柔軟な従量課金制または定額料金制を利用でき、初期投資や長期契約は不要です。 料金の詳細については、 AWS Security Hub 料金ページ をご覧ください。 Security Hub コンソール で今すぐお試しいただき、 AWS re:Post for Security Hub または通常の AWS サポート窓口を通じてフィードバックをお送りください。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

本記事は「 Surgical precision with AST-based code editing in Kiro 」を翻訳したものです。 TL;DR: ここ数週間、私たちは新しい AST ベースのコードナビゲーション・編集エンジンをテストしてきました。このエンジンは、Kiro で最も頻繁なクエリタイプである機能リクエストの例を含むベンチマーク SWE-PolyBench において、トークン使用量を 20% 削減します。また、正確で耐障害性の高い、プロダクショングレードのコード変換を可能にします。脆弱な正規表現やファイル全体のダンプはもう不要です！ エージェントが 1 つの関数を見つけるために何千行も読み込み、わずかなフォーマットの違いのせいで更新に失敗することは AI コーディングアシスタントを使っているすべての開発者が経験したことがあるでしょう。現在のアプローチはファイル全体を読み込み、完全一致の文字列マッチングを行いますが、トークンを大量に消費し、簡単に壊れてしまいます。私たちはより良いものを構築しました。 本日、Kiro のコードベースでの作業に外科的精度を与える AST ベースのコードナビゲーション・編集システムを紹介します。任意の行範囲を探索したり脆弱な文字列マッチングを行う代わりに、このツールはコードを構造で捉えます。関数、クラス、インポートなどを対象とし、意味的な理解に基づいた型付き操作を適用します。 ＊AST（抽象構文木） : コードから言語の意味に関係ある情報のみを取り出し、木構造で表現したものです。 テキストベースのコードツールの問題点 これまで、Kiro IDE はコードの確認に readFile 、編集に strReplace という 2 つのテキストベースのツールに依存していました。シンプルではありますが、このアプローチには 2 つの根本的な問題があります。 1. 高いトークンコストとレイテンシ 特定の関数を探す際、エージェントはファイルの大部分、多くの場合ファイル全体を読み込む必要があります。これは、タスクに関係のないコンテキストに何千ものトークンが費やされることを意味します。 2. 脆弱な文字列マッチング 編集には完全一致の文字列マッチングが必要です。エージェントの期待と実際のコードの間にある空白、フォーマット、コメントのわずかな違いが、編集の失敗や意図しない複数マッチを引き起こします。その後、エージェントはミスを修正するために追加のイテレーションが必要になります。 これらの問題は複合的に作用します。エージェントがミスをし、診断のためにファイルを再度読み込み、別の編集を試み、このサイクルが繰り返されます。各イテレーションがより多くのトークンを消費し、レイテンシを増加させます。 AST ベースエンジンの仕組み このエンジンは、テキストベースの操作を AST パースに置き換えます。コードを文字列として扱う代わりに、関数、クラス、メソッド、インポート、およびそれらの関係性といった構造化されたエンティティとしてコードを理解します。 コード読み取り: ターゲットを絞った情報抽出 ファイルの内容全体をダンプする代わりに、エンジンのコード読み取りツールは必要なものだけを返します: シグネチャ : 実装の詳細を含まない関数やクラスの定義 構造 : 高レベルのコード構成と関係性 検索結果 : 条件に一致する特定の定義 Java クラスを調べる 2 つのアプローチを比較してみましょう: 従来のアプローチ （1,309 トークン）: Read entire AsyncRpcResult.java file including: - License header - All imports - Complete implementation of 25+ methods - Full method bodies with all logic AST ベースのアプローチ （545 トークン）: Class signatures in AsyncRpcResult.java: class: AsyncRpcResult (Line 41) method: AsyncRpcResult(Invocation invocation) (Line 53) method: getValue() (Line 70) method: getException() (Line 82) method: thenApplyWithContext(Function<Result, Result> fn) (Line 139) [additional signatures...] この例では、エンジンはナビゲーションと意思決定に必要な本質的な構造情報を提供しながら、トークンを 58% 削減しています。 コード書き込み: セマンティック編集 エンジンのコード書き込みツールは、セレクタを使用してコード要素を正確にターゲットします: ClassName.methodName で特定のメソッドをターゲット function:functionName で関数をターゲット field:fieldName でクラスフィールドをターゲット end でファイルの末尾に追加 4 つの型付き操作をサポートしています: insert_node : 特定の場所に新しいコードを追加 replace_node : 関数やクラス全体を置換 delete_node : コード要素をクリーンに削除 replace_in_node : コードブロック内で外科的な編集を実行 ベンチマークからの実例として、TypeScript ファイルに新しい関数を追加するケースを紹介します: 従来のアプローチ （361 トークン）: { "oldStr": "/**\n * Get a cached parsed configuration...\n */\nfunction getCachedParsedConfiguration(tsConfigPath: string): ParsedConfiguration {\n if (tsConfigCache.has(tsConfigPath)) {\n return tsConfigCache.get(tsConfigPath)!;\n }\n \n const parsedConfig = readConfiguration(tsConfigPath);\n tsConfigCache.set(tsConfigPath, parsedConfig);\n return parsedConfig;\n}", "newStr": "/**\n * Get a cached parsed configuration...\n */\nfunction getCachedParsedConfiguration(tsConfigPath: string): ParsedConfiguration {\n if (tsConfigCache.has(tsConfigPath)) {\n return tsConfigCache.get(tsConfigPath)!;\n }\n \n const parsedConfig = readConfiguration(tsConfigPath);\n tsConfigCache.set(tsConfigPath, parsedConfig);\n return parsedConfig;\n}\n\n/**\n * Clear the tsconfig cache...\n */\nexport function clearTsConfigCache(): void {\n tsConfigCache.clear();\n}" } AST ベースのアプローチ （96 トークン）: { "path": "packages/compiler-cli/ngcc/src/ngcc_options.ts", "selector": "end", "replacement": "/**\n * Clear the tsconfig cache...\n */\nexport function clearTsConfigCache(): void {\n tsConfigCache.clear();\n}", "operation": "insert_node" } この例では、完全一致の文字列マッチングに必要な周辺コンテキストの記述を省略することで、エンジンはトークンを 73% 削減しています。 実際の効果 私たちは AST ベースエンジンを従来のツールと比較して、2 つのベンチマークで評価しました。 PolyBench50 の結果 PolyBench50（ SWE-PolyBench のサブセット）で AST の読み取り・書き込み操作を実行したところ、一貫した改善が見られました: 指標 従来 AST ベースエンジン 改善率 タスクあたりの LLM 呼び出し数 40.88 26.86 34.30% 出力トークン 270,957 189,806 29.95% 入力トークン 680,684 541,346 20.47% 機能リクエストのデモンストレーション 現実的な機能リクエストで両方のアプローチをテストしました:「AWS Resource Explorer にサードパーティ統合を追加」（Slack/Teams 通知、Jira チケット、SIEM エクスポート、AWS Config 統合）。 指標 従来 AST ベースエンジン 改善率 実行時間 9 分 20 秒 4 分 44 秒 49.30% LLM 呼び出し数 29 22 24.10% 入力トークン 1,350 1,192 11.70% 出力トークン 761 654 14% ツールエラー 2 0 – AST がプロダクション開発に重要な理由 AST ベースのコード操作の利点は、トークン効率にとどまりません: 耐障害性 : フォーマットの変更が編集を壊しません。スペース 2 つでも 4 つでも、タブでもスペースでも、構造的な編集は成功します。 精度 : ファイル内の他の類似コードを気にすることなく、変更したい箇所を正確にターゲットできます。 保守性 : 今日機能する操作は、周囲のコードが進化しても明日も機能します。 理解力 : AST パースはエージェントにコード構造の真の理解を提供し、どこでどのように変更を行うかについてよりスマートな判断を可能にします。 これは特に機能リクエストにおいて重要です。機能リクエストは Kiro で最も頻繁なクエリタイプであり、Vibe モードのトラフィックの 45%、Spec モードのトラフィックの 67.6% を占めています。これらのリクエストはコードベース全体にわたる複数のファイル変更を伴うことが多く、脆弱な文字列マッチングの複合的な影響が大きな摩擦を生み出します。これらの初期結果に私たちは興奮しており、現在プロダクションで利用可能です。

ビデオホスティングはストレージを大量に必要とするビジネスです。フルHD 1080p 解像度の映画を約 100 万本扱う中程度の事業者でも、約 10 ペタバイト（PB）のストレージが必要になります。 Amazon Simple Storage Service  は、スケーラビリティ、パフォーマンス、そしてコスト効率の面で長年の実績があります。とはいえ、継続的な FinOps プラクティスを適用することで、コスト効率を高め、クラウドのコストモデルから得られるビジネス価値を最大化することができます。 このブログでは、ビデオホスティングのお客様が Amazon S3 のコストを 70% 削減するのに AWS がどのように役立ったかを説明しています。その成果は、AWS のネイティブツールを活用して何百万もの動画ファイルのライフサイクルを理解し、その後、Just-in-Timeの動画ホスティングプラットフォームのアーキテクチャを微調整することで達成されました。 AWS Cost and Usage Reports を使用して問題の規模を特定する ビジネスの成長に伴い、お客様は Amazon S3 のコストが着実に増加していることに気づきました。S3 コストはインフラ総コストの 40% を占めていました。コストの全体像を把握するには、通常、 AWS Cost Explorer から始めるのが最適です。ただし、Amazon S3 のコストは、ストレージクラスやアクセスパターンなど、さまざまな要因の影響を受ける可能性があるため、 AWS Cost and Usage Reports （CUR）を使用してより詳細な分析を行う必要があります。 AWS ブログ「 Analyze Amazon S3 storage costs using AWS Cost and Usage Reports, Amazon S3 Inventory, and Amazon Athena 」で説明されているアプローチに従い、AWS は Amazon S3 の総コストを次のグラフのように 4 つの主要な構成要素に詳しく分類しました。 図1: AWS Cost and Usage Reports のデータから生成されたS3のコスト内訳 お客様は、S3 Standard、S3 Standard Infrequent Access、S3 Glacier Instant Retrieval（GIR）の 3 つの Amazon S3 ストレージクラスを使用していました。一見したところ、S3 のコストの大部分（88％）は GIR によるものでした。具体的には、GET API（33.7％）と Retrieval（28.6％）のコストは、一般的な使用パターンと比較して異常に高いようです（注：Glacier Instant Retrieval クラスの場合、S3 GET と Retrieval のコストは S3 オブジェクトにアクセスするたびに発生します）。 S3 GIR は「ほとんどアクセスされないが、ミリ秒単位で取得する必要がある長期にわたるデータ」を対象としているため、大量の取得操作は、意図したアーキテクチャ設計とプラットフォームの実際のアクセスパターンとの間に不一致があることを示していました。 アーキテクチャと潜在的な問題を理解する お客様のワークロードは、世界中の企業顧客向けのセールスおよびマーケティングビデオをホストする SaaS プラットフォームです。ほとんどの動画は少人数の視聴者が視聴することを想定していたため、お客様は Just-in-Time Processing（JITP）アーキテクチャを採用しました。このアプローチにより、要求された場合にのみビデオセグメントを特定の形式にトランスコードし、同じビデオの複数のレンディション（訳注：同一のオリジナル動画を異なる解像度、ビットレート、フォーマット、コーデックなどに変換したバリエーションのこと）を保存する必要がなくなるため、ストレージコストを削減できます。 図2：Just-in-Time Processing（JITP）アーキテクチャ コストをさらに最適化するために、お客様は、動画ファイルが 30 日経過してアクセスされる可能性が少なくなった時点で、自動的に S3 GIR ストレージクラスに移行する Amazon S3 ライフサイクル設定 （これにはいくらかのコストがかかりますが、MB サイズのオブジェクトではごくわずかです）を実装しました。これらのファイルが休止状態のままである限り、S3 GIR は S3 Standard と比較してストレージコストを最大 80% 削減できるという考えでした。 ただし、GIR に保存されているファイルに予期せずアクセスされた場合、Retrieval と GET リクエストの追加料金が発生します（ Amazon S3 の料金ページ に詳述されています）。1TB のビデオデータを GIR に保存するには 1 か月あたり約 4 ドル（S3 Standard では 21 ドル）かかりますが、同じデータを GIR から一度取得した場合、Retrieval と GET のコストは合計で約 30 ドルになり、意図した節約額はすぐに相殺されます。 図3：S3 GIR 内のファイルを取得したときのコストへの影響 その結果、コスト最適化の取り組みは、次の 2 つの重要な問いに答えることに焦点を当てました。 GIR に保存されているビデオファイルの中に、依然として GET や Retrieval のアクティビティが高いものが多すぎないか？ もしそうであれば、それらを効果的に特定して対処するにはどうすればよいか？ S3 Access Logging は、膨大なデータの中から問題のファイルを特定するのに役立ちます GET リクエストと Retrieval リクエストの出所を定量化するために、お客様はバケットに対して行われたすべてのリクエストの詳細な記録を提供する Amazon S3 Access Logging に目を向けました。一度有効にすると、S3 は設定したターゲットバケットにログファイルを自動的に書き込みます。 S3 アクセスログを分析する最良の方法は、 Amazon Athena でクエリを実行することです。 Amazon S3 のドキュメントの手順 に従って、ログデータを表すデータベースとテーブルを作成できます。 たとえば、次の SQL クエリは、データベースとテーブルの名前が s3_access_logs_dbとmybucket_logs であると仮定して、最もアクセス数の多い S3 オブジェクトの上位 10 件を返します。 SELECT COUNT(*) AS access_count, key AS file_name FROM s3_access_logs_db.mybucket_logs WHERE operation = 'REST.GET.OBJECT' AND httpstatus = '200' GROUP BY key ORDER BY access_count DESC LIMIT 10; JSON その結果、ほんの数時間で、多くのビデオファイルに何千回もアクセスされたことがわかりました。これは予想をはるかに超える頻度です。 さらなる分析により、GIR 層のすべての GET および Retrieval アクティビティのほぼ半分を、全体のごく一部（約 0.1%）、主にサイズの大きいファイルが占めていることが確認されました。これらのファイルについては、S3 Glacier Instant Retrieval（GIR）に保存することは、コストの観点からは非効率的でした。チームはそれらを S3 Intelligent-Tiering に移行することを評価しました。コストモデリングでは、 Intelligent-Tiering  では取り出し料金がかからず、GET API のコストが GIR と比べて 25 分の 1 であるため、大幅な節約が可能であることが示されました。たとえば、次の上位 3 つのアクセスファイルでは、90% 以上の節約が可能です。 これらの洞察をもとに、チームは最もアクティブな 60,000 のオブジェクト（合計 1,000 万本の動画の約 0.6%）にフラグを付け、S3 Intelligent-Tiering に再分類しました。この変更は意図したとおりに機能し、GIR の Retrieval と GET のコストを 50% 削減しました。 頻繁にアクセスされるファイルを S3 Intelligent-Tiering に再分類するとすぐに節約できましたが、すべての動画が同じアクセスパターンに従うわけではないことも浮き彫りになりました。この洞察は、複数の S3 ストレージクラスを戦略的に使用することにより、より包括的な最適化への道を開きました。 複数のS3ストレージクラスを活用してアーキテクチャを最適化する Just-in-Time のパッケージ環境では、生涯にわたるストレージコストはアクセスパターン、つまり各ビデオがそのライフサイクル全体でどれくらいの頻度で視聴されるかに大きく依存します。 チームがこれらのロングテール（訳注：ここでの「ロングテール」とは、アクセス頻度の分布において、超高頻度アクセスのファイル群を除いた後も、依然として相対的に高いアクセスが続いているファイル群を指す）の「頻繁にアクセスされる」ファイルを分析したところ、これらは主に明確な特徴を持つマーケティングビデオであることがわかりました。 より高い解像度（1080p または 4K）とより長い尺のため、約 100 倍のサイズがある 視聴される可能性が約 100 倍高い 全オブジェクトの 10% だが、月間 31 億件の GET リクエストの約 99％ を占めている コストを最適化するには、これらのトラフィックの多い動画はアップロード時に S3 Intelligent-Tiering に保存し、残りの動画は引き続き S3 Standard を使用し、30 日間のライフサイクルポリシーで S3 Glacier Instant Retrieval（GIR） に移行する必要があります。 幸いなことに、この改善を実装するのに必要なのは数行のコードだけでした。デプロイされると、GET リクエストの量は GIR から Intelligent-Tiering に徐々にシフトし、S3 全体のコストは着実に下がりました。 図4：S3 Intelligent-Tiering を採用した後の GET リクエスト（GIRクラス）は減少傾向 ストレージクラスを最適化した後、次の問いは簡単でした。S3 GET リクエストの総数を減らして、さらにコストを削減できるでしょうか？ Just-in-Time pipeline の残りの部分をチューニングする それに答えるために、チームは Just-in-Time（JIT）ビデオ処理パイプラインの他の部分、特にコンテンツ配信レイヤー（ Amazon CloudFront ）と Nginxベースのパッケージングレイヤー を調べました。 指針となるアイデアは簡単でした： CDN レイヤー：CloudFront のキャッシュミスを減らし、Nginxベースのパッケージングレイヤーへフォールバックされるリクエストを減らす パッケージ層：各ビデオセグメントを構築するのに必要なフェッチの数を最小限に抑える 図5：GET リクエストコストの概算 CloudFront と Nginxのレイヤーを分析したところ、最適化の機会が実際に見つかりました。 CloudFront の最適化：Amazon CloudWatch のメトリクスを分析したところ、CloudFront のグローバルキャッシュヒット率はわずか 65％ で、特定の地域では 40％ に低下していました。 特にパフォーマンスの低い地域に焦点を当てて CloudFront ディストリビューション構成を調整したところ、ヒット率は約 90％ に増加しました。この改善だけでも、S3 GET と Retrieval リクエストを約 50% 削減しました。 Nginxベースのパッケージングレイヤーの最適化: CloudFront でキャッシュミスが発生するたびに、システムはマニフェストファイルと複数の 6 秒間のセグメントファイルを再生成しました。レイヤーはこれらのファイルをローカルにキャッシュしなかったため、必要なデータを取得するために複数の S3 GET 範囲リクエストを発行しました。 S3 GET リクエストのバイト範囲サイズ を 256 KB から 2 MB に増やすことで、チームは平均セグメントの構築に必要な GET の数を 7.05 から 1.04 に減らし、全体で 85% 削減しました。 これらのパイプラインの最適化により、S3 GET リクエストが 90％ 削減され、それに比例して取得とリクエストのコストが下がり、コスト最適化の最終段階が完了しました。 結果のまとめと重要なポイント チームは、AWS Cost and Usage Reports と Amazon S3 Access Logging から得た洞察をもとに、お客様が Amazon S3 の6 桁の年間請求額を約 70% 削減できるように支援しました。これらの節約は、CloudFront キャッシュのチューニング、ロングテールコンテンツへの S3 Intelligent-Tiering の活用、効率向上のための S3 GET 範囲サイズの調整など、ワークロードアーキテクチャを最適化することによって達成されました。 クラウドネイティブ（「クラウドで生まれた」）企業は、オンデマンドのクラウド価格設定と柔軟なスケーリングにより、並外れた俊敏性を享受しています。これらのビジネスが急速に成長するにつれて、持続可能な事業拡大にはコストの最適化が重要になります。AWS は、何百万ものお客様との協力から、最も効果的なコスト最適化は、多くの場合、アーキテクチャのチューニング、つまり効率的に拡張し、必要な場合にのみリソースを使用するシステムを設計することにあることを学びました。 自社のコスト要因を理解するには、まず AWS の ネイティブコスト管理ツール を使って可視化してください。より包括的なサポートが必要な場合は、 AWS Cloud Financial Management チームに依頼して、ワークロードに合わせたコスト最適化戦略を策定することもできます。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Cedric Hu シニア・ソリューション・アーキテクトとして、セドリック・フーは ISV と提携してクラウドの複雑さを乗り越えています。彼は、厳格なコスト管理を維持しながら、スケーラブルで革新的なソリューションを構築することを専門としています。これにより、お客様は技術的卓越性を損なうことなく最大の ROI を達成できます。

本記事は 2026 年 3 月 3 日 に公開された「 Building a modern lakehouse architecture: Yggdrasil Gaming’s journey from BigQuery to AWS 」を翻訳したものです。 本記事は、AWS パートナーである GOStack の CEO 兼創設者 Edijs Drezovs、データアーキテクト Viesturs Kols、シニアデータエンジニア Krisjanis Beitans によるゲスト投稿です。 Yggdrasil Gaming は、カジノゲームをグローバルに開発・配信しており、ゲームパフォーマンス分析、プレイヤー行動分析、業界インテリジェンスのために大量のリアルタイムゲームデータを処理しています。システムの成長に伴い、デュアルクラウド環境の管理が運用負荷を増大させ、高度な分析への取り組みを制約していました。マルチクラウド運用の課題は、データ量と複雑性の増加をもたらす Game in a Box ソリューションの AWS Marketplace でのローンチを控え、特に重要になりました。 Yggdrasil Gaming は Google BigQuery から AWS 分析サービスへ移行し、マルチクラウドの複雑性を解消してスケーラブルな分析基盤を構築しました。本記事では、Yggdrasil Gaming がビジネスの成長に対応するためにデータアーキテクチャをどのように変革したかを紹介します。ビジネス継続性を維持しながら、プロプライエタリなシステムから Apache Iceberg などのオープンテーブルフォーマットへ移行する実践的な戦略を学べます。 Yggdrasil は AWS パートナーの GOStack と連携し、Apache Iceberg ベースの レイクハウスアーキテクチャ へ移行しました。レイクハウスへの移行により運用の複雑性が軽減され、リアルタイムのゲーム分析と 機械学習 が可能になりました。 課題 Yggdrasil が AWS への移行を決断した背景には、いくつかの重要な課題がありました。 マルチクラウドの運用負荷 : AWS と Google Cloud にまたがるインフラ管理が大きな運用負荷を生み、俊敏性を低下させ、メンテナンスコストを増加させていました。データチームは両環境の専門知識を維持し、クラウド間のデータ移動を調整する必要がありました。 アーキテクチャの制約 : 既存の構成では高度な分析や AI の取り組みを効果的に支えられませんでした。さらに重要なのは、Yggdrasil の Game in a Box ソリューションのローンチに、データ量の増加に対応でき高度な分析を実現できる、近代的でスケーラブルなデータ環境が必要だったことです。 スケーラビリティの制約 : オープン標準と自動化を備えた統合データ基盤がなく、効率的なスケーリングが困難でした。データ量の増加に比例してコストも増加し、大規模な分析に対応できる環境が求められていました。 ソリューション概要 Yggdrasil は AWS APN パートナーの GOStack と連携し、新しいレイクハウスアーキテクチャを設計しました。以下の図はアーキテクチャの全体像を示しています。 Yggdrasil は Google BigQuery から、 Amazon Athena 、 Amazon EMR 、 Amazon Simple Storage Service (Amazon S3)、 AWS Glue Data Catalog 、 AWS Lake Formation 、 Amazon Elastic Kubernetes Service (Amazon EKS)、 AWS Lambda を活用したデータレイクハウスアーキテクチャへの移行に成功しました。マルチクラウドの複雑性を軽減しつつ、Game in a Box ソリューションや、パーソナライズされたゲームレコメンデーション、不正検知といった AI/ML に向けたスケーラブルな基盤の構築を目指した移行です。 Amazon S3、Apache Iceberg、Amazon Athena の組み合わせにより、Yggdrasil はプロビジョニング済みの常時稼働コンピューティングモデルから脱却できました。Amazon Athena のクエリ単位課金はスキャンしたデータ量のみに課金されるため、オフピーク時のアイドルコンピューティングコストがなくなります。評価フェーズで実施した内部コストモデリングでは、特にゲームローンチ、トーナメント、季節的なトラフィックによるバースト型ワークロードにおいて、コンピューティングベースのウェアハウス課金モデルと比較して分析システムコストを 30〜50% 削減できる見込みが示されました。AWS ネイティブの分析サービスを採用することで、 AWS Identity and Access Management (AWS IAM)、Amazon EKS、AWS Lambda とのネイティブ統合を通じて運用の複雑性が軽減され、分析システム全体のセキュリティ、ガバナンス、自動化が簡素化されました。 ソリューションの中心は、Amazon S3 上に構築されたレイクハウスアーキテクチャです。Amazon S3 は Iceberg テーブルを Apache Parquet 形式 で格納する耐久性とコスト効率に優れたストレージを提供します。Apache Iceberg テーブルフォーマットは、オープン標準を維持しながら ACID トランザクション、スキーマエボリューション、タイムトラベル機能を提供します。AWS Glue Data Catalog は技術メタデータの一元リポジトリとして機能し、Amazon Athena は dbt-athena やアドホックなデータ探索に使用されるサーバーレスクエリエンジンです。Amazon EMR は Yggdrasil のレガシー Apache Spark アプリケーションをフルマネージド環境で実行し、AWS Lake Formation はデータレイクの一元的なセキュリティとガバナンスを提供して、データベース、テーブル、列、行レベルでの きめ細かなアクセス制御 を実現します。 移行は段階的に進められました。 レイクハウス基盤の構築 – Amazon S3 と AWS Glue Data Catalog を使用した Apache Iceberg ベースのアーキテクチャをセットアップ リアルタイムデータ取り込みの実装 – EKS および Google Kubernetes Engine (GKE) クラスターからのリアルタイム変更データキャプチャ用に Debezium コネクタをデプロイ 処理パイプラインの移行 – AWS Lambda を使用した ETL パイプラインの再構築、レガシーデータアプリケーションの Amazon EMR への移行 変換レイヤーの近代化 – モジュール式で再利用可能なモデルのために dbt と Amazon Athena を導入 ガバナンスの有効化 – データガバナンス全体を AWS Lake Formation で管理 レイクハウス基盤の構築 移行の最初のフェーズでは、AWS 上の新しいデータレイクハウスアーキテクチャの基盤構築に注力しました。目標は、オープンデータフォーマットとサーバーレスクエリ機能を備えた、スケーラブルで安全かつコスト効率の高い環境を構築することでした。 GOStack は中央ストレージレイヤーとして Amazon S3 ベースのデータレイクをプロビジョニングし、高いスケーラビリティときめ細かなコスト管理を実現しました。ストレージとコンピューティングの分離により、取り込み、変換、分析の各プロセスを切り離し、それぞれが最適なコンピューティングエンジンを使用して独立にスケーリングできます。 データセットの相互運用性と発見性を確立するため、チームは AWS Glue Data Catalog を統合メタデータリポジトリとして採用しました。カタログは Iceberg テーブル定義を格納し、Amazon Athena や Amazon EMR 上の Apache Spark ワークロードなどのサービス間でスキーマにアクセスできるようにします。バッチとストリーミングの両方を含むほとんどのデータセットがここに登録され、レイクハウス全体で一貫したメタデータの可視性を実現しています。 データは Amazon S3 上の Apache Iceberg テーブルに格納されます。Iceberg はオープンテーブルフォーマット、ACID トランザクションサポート、柔軟なスキーマエボリューション機能を理由に選定されました。Yggdrasil は、一貫した財務レポートと不正検知のための ACID トランザクション、急速に変化するゲームデータモデルに対応するスキーマエボリューション、規制監査要件に沿ったタイムトラベルクエリを必要としていました。 GOStack はカスタムのスキーマ変換・テーブル登録サービスを構築しました。スキーマ変換・テーブル登録サービスはソースシステムの Avro スキーマを Iceberg テーブル定義に変換し、raw レイヤーテーブルの作成とエボリューションを管理します。スキーマ変換とテーブル登録を直接制御することで、メタデータがソースシステムと一貫性を保ち、取り込みニーズに沿った予測可能でバージョン管理されたスキーマエボリューションを実現しています。 初期セットアップでは以下のコンポーネントを構成しました。 Amazon S3 バケット構造の設計 : データライフサイクルのベストプラクティスに沿ったマルチレイヤーレイアウト (raw、curated、analytics ゾーン) を実装しました。 AWS Glue Data Catalog の統合 : Athena のパフォーマンスに最適化されたパーティショニング戦略でデータベースとテーブルスキーマを定義しました。 Iceberg の設定 : ストレージ効率とクエリの柔軟性のバランスを取るため、バージョニングとメタデータ保持ポリシーを有効化しました。 セキュリティとコンプライアンス : AWS Key Management Service (AWS KMS) による保存時の暗号化を設定し、AWS IAM と Lake Formation によるアクセス制御を適用し、最小権限の原則に従った Amazon S3 バケットポリシー を実装しました。 以前の GCP 構成の再設計により、コストパフォーマンスが向上しました。Yggdrasil は、より直接的なイベント駆動パイプラインへの移行を通じて、取り込みと処理のコストを約 60% 削減し、運用負荷も軽減しました。 リアルタイムデータ取り込みの実装 レイクハウスアーキテクチャの構築後、次のステップでは Yggdrasil のオペレーショナルデータベースからレイクハウスの raw データレイヤーへのリアルタイムデータ取り込みの実現に注力しました。目的は、トランザクションの変更を発生時にキャプチャして配信し、下流の分析やレポートに最新の情報を反映させることでした。 GOStack は Debezium Server Iceberg をデプロイしました。これは変更データキャプチャ (CDC) を Apache Iceberg テーブルに直接統合するオープンソースプロジェクトです。Amazon EKS 上に Argo CD アプリケーションとしてデプロイされ、Argo の GitOps ベースモデルにより再現性、スケーラビリティ、シームレスなロールアウトを実現しています。 Debezium Server Iceberg のアーキテクチャは効率的な取り込み経路を提供します。ソースシステムの アウトボックステーブル からデータ変更を直接ストリーミングし、AWS Glue Data Catalog に登録され Amazon S3 に物理的に格納された Apache Iceberg テーブルに書き込みます。中間ブローカーやステージングサービスが不要です。Iceberg テーブルフォーマットでデータを書き込むことで、取り込みレイヤーはトランザクション保証と Amazon Athena による即時クエリ可用性を維持しました。 Yggdrasil のソースシステムは Avro レコードを含むアウトボックスイベントを発行していたため、チームは Debezium 内にカスタムのアウトボックスから Avro への変換を実装しました。アウトボックステーブルには 2 つの主要コンポーネントが格納されていました。 Avro スキーマ定義 各レコードの JSON エンコードされたペイロード カスタム変換モジュールは Avro スキーマ定義とペイロードを有効な Avro レコードに結合してから、ターゲットの Iceberg テーブルに永続化しました。Avro からの変換によりスキーマの忠実性が保たれ、下流の処理ツールとの互換性が確保されました。 受信した変更イベントを動的にルーティングするため、チームは Debezium のイベントルーター 設定を活用しました。各レコードはトピックとメタデータルールに基づいて適切な Apache Iceberg テーブル (Amazon S3 上) にルーティングされ、テーブルスキーマとパーティショニングは AWS Glue 側で管理され、レイクハウスのデータ編成標準との安定性と整合性が維持されました。 Debezium と Iceberg の組み合わせにより、 低レイテンシーの取り込み と データベースアウトボックス から S3 ベースの Iceberg テーブルへのほぼリアルタイムの エンドツーエンドストリーミング が実現しました。チームは Amazon EKS 上で Helm チャートを使用し、 GitOps モデル で Argo CD 経由でデプロイすることで、完全に宣言的でバージョン管理された運用を実現しました。ACID 準拠の Iceberg 書き込みにより、部分的に書き込まれたデータが下流の分析を破損することはありません。モジュール式の変換ロジックにより、取り込みパイプラインを再設計することなく、将来的に新しいソースシステムやイベントフォーマットへの拡張が可能です。 Debezium Server による高速なリアルタイムデータ取り込みは、GOStack が暫定的なアーキテクチャと位置付けています。長期的には、取り込みパイプラインは Amazon Managed Streaming for Apache Kafka (Amazon MSK) を中央イベントバックボーンとして使用する形に進化する予定です。Debezium コネクタがプロデューサーとして変更イベントを Apache Kafka トピックに発行し、 Apache Flink アプリケーションがデータを消費、処理して Iceberg テーブルに書き込みます。 Kafka ベースのストリーミングアーキテクチャへの計画的な進化により、Yggdrasil のレイクハウスは現在スケーラブルでコスト効率が高いだけでなく、将来にも対応できます。組織の成長に伴い、より高度なストリーミング分析や幅広いデータ統合シナリオをサポートできる構成です。 処理パイプラインの移行 リアルタイムデータ取り込みの確立後、GOStack はデータ変換レイヤーの近代化に注力しました。目標は変換ロジックの簡素化、運用負荷の軽減、新しい AWS ベースのレイクハウス内での分析ワークロードのオーケストレーション統合でした。 GOStack は GCP からの迅速かつ低リスクな移行を支えるため、Yggdrasil の一部のデータパイプラインにリフトアンドシフトアプローチを採用しました。ファイル共有、SharePoint、Google Sheets、各種サードパーティ API からのデータ抽出を担っていた軽量な Cloud Run functions は、AWS Lambda で再実装されました。再実装した Lambda 関数は同じ外部システムと連携し、データを直接 Iceberg テーブルに書き込みます。 より複雑な処理については、 Dataproc 上で実行されていた Apache Spark アプリケーションを最小限のコード変更で Amazon EMR に移行しました。既存の変換ロジックを維持しながら、EMR のマネージドスケーリング機能と AWS でのコスト管理の向上を活用できるようになりました。 今後、移行したパイプラインは段階的にリファクタリングされ、EKS クラスター上のコンテナ化されたワークフローに統合され、 Argo Workflows で完全にオーケストレーションされる予定です。段階的な移行により、Yggdrasil はワークロードを迅速に AWS に移行して GCP リソースを早期に廃止しつつ、データシステムの継続的な改善と近代化の余地を残しています。 最後に、以前 BigQuery のストアドプロシージャやスケジュールクエリとして存在していた多くの分析変換は、dbt-athena で実行されるモジュール式の dbt モデルとして再構築されました。dbt への移行により変換ロジックの透明性、保守性、バージョン管理が向上し、開発者体験と長期的なガバナンスの両方が改善されました。 変換レイヤーの近代化 取り込みパイプラインの AWS への移行が完了し、GOStack は Yggdrasil の分析変換の簡素化と近代化に注力しました。以前のストアドプロシージャ駆動のアプローチを再現するのではなく、保守性、リネージの可視性、オーケストレーション、長期的なガバナンスの向上のために dbt を使用して変換レイヤーを再構築しました。再設計の一環として、いくつかのデータモデルは新しいレイクハウスアーキテクチャに合わせて再構成されました。最も大きな取り組みは、重要な Spark ベースの財務変換を SQL 駆動の dbt モデルセットに書き換えることでした。SQL 化によりロジックがレイクハウス設計に沿うだけでなく、長時間稼働する Spark クラスターが不要になり、運用とコストの削減につながりました。レガシーウェアハウスに代わるキュレーションデータレイヤーでは、GOStack は多数のスケジュールクエリとストアドプロシージャを構造化された dbt モデルに統合しました。分析スタック全体で標準化されバージョン管理された変換と明確なリネージが提供されます。 オーケストレーションも簡素化されました。以前は Spark ワークロード用の Apache Airflow と分析変換用の スケジュールクエリ に分かれており、運用上の摩擦と依存関係のリスクが生じていました。新しいアーキテクチャでは、Amazon EKS 上の Argo Workflows が dbt モデルを一元的にオーケストレーションし、変換ロジックを単一のワークフローエンジンに統合しています。現在ほとんどの変換はタイムベースのスケジュールで実行されていますが、 Argo Events によるイベント駆動実行もサポートしており、変換レイヤーの進化に合わせてトリガーベースのワークフローを段階的に採用できます。 統合オーケストレーションフレームワークのメリットは次のとおりです。 一貫性 : 取り込みと変換にまたがるデータワークフローを単一のオーケストレーションレイヤーで管理。 自動化 : イベント駆動の dbt 実行により手動スケジューリングが不要になり、運用負荷が軽減。 スケーラビリティ : Argo Workflows は EKS クラスターとともにスケーリングし、並行する dbt ジョブをシームレスに処理。 可観測性 : 一元化されたログとワークフローの可視化により、ジョブの依存関係とデータの鮮度の把握が向上。 dbt と Argo Workflows の導入を通じて、Yggdrasil はデータレイクとウェアハウスを、オープンデータフォーマット、サーバーレスクエリエンジン、モジュール式の変換ロジックを活用したレイクハウスアーキテクチャに統合しました。dbt と Athena への移行は運用を簡素化しただけでなく、データ環境全体でのイテレーションの高速化、ガバナンスの簡素化、開発者の生産性向上への道を開きました。 レイクハウスのパフォーマンス最適化 パフォーマンスチューニングは継続的な取り組みですが、変換の再設計の一環として、GOStack は Athena クエリの高速化とコスト効率の向上のためにいくつかのパフォーマンス調整を行いました。Apache Iceberg テーブルは ZSTD 圧縮 の Parquet で格納され、優れた読み取りパフォーマンスと Athena がスキャンするデータ量の削減を実現しています。 パーティショニング戦略も Iceberg のネイティブパーティショニング を使用して実際のアクセスパターンに合わせました。raw データゾーンは取り込みタイムスタンプでパーティショニングされ、効率的な増分処理を実現しています。キュレーションデータはプレイヤーやゲーム識別子、日付ディメンションなどのビジネス駆動のパーティションキーを使用し、分析クエリの最適化に役立てています。パーティショニング設計により、Athena は不要なデータを刈り込み、関連するパーティションのみを一貫してスキャンできます。 Iceberg のネイティブパーティショニング機能 (バケッティングやタイムスライスなどの変換を含む) は、従来の Hive パーティショニングパターンに代わるものです。Iceberg はメタデータレイヤーでパーティションを内部的に管理するため、Glue や Athena のパーティション構成がすべて適用されるわけではありません。Iceberg のネイティブパーティショニングに依存することで、レガシーな Hive の動作を導入することなく、レイクハウス全体で予測可能なプルーニングと一貫したパフォーマンスが得られます。 リアルタイム取り込みで生成される大量の小さなファイルに対処するため、GOStack は AWS Glue Iceberg コンパクション を有効化しました。小さな Parquet ファイルを自動的に大きなセグメントにマージし、手動介入なしでクエリパフォーマンスの向上とメタデータ負荷の削減を実現しています。 ガバナンスの有効化 チームはレイクハウスのキュレーションゾーンの主要なガバナンスレイヤーとして AWS Lake Formation を採用し、 Lake Formation ハイブリッドアクセスモード を活用して、既存の IAM ベースのアクセスパターンと並行してきめ細かな権限を管理しています。ハイブリッドアクセスモードは、レガシー権限や内部パイプラインロールの完全な移行を強制することなく Lake Formation を段階的かつ柔軟に採用できるため、Yggdrasil の段階的な近代化戦略に最適です。 Lake Formation は一元的な認可を提供し、データベース、テーブル、列、そして Yggdrasil にとって特に重要な行レベルの権限をサポートしています。行レベルの権限は、同社のマルチテナント運用モデルで特に重要です。 ゲーム開発パートナー は 自社のゲームに関するデータとレポートのみ にアクセスでき、パートナー契約に沿ったセキュリティとコンプライアンスを実現しています。 Yggdrasil のシステムと統合する iGaming オペレーター は、キュレーションされた Iceberg テーブルに基づくレポートツールを通じて、 自社データに限定した運用・財務インサイト を自動的に受け取ります。 Lake Formation ハイブリッドアクセスモードにより、テナント固有の行レベルアクセスポリシーが Amazon Athena、AWS Glue、Amazon EMR 全体で一貫して適用され、既存の IAM ベースのワークロードに破壊的な変更を加えることはありません。Yggdrasil は外部コンシューマーに対して適切なガバナンスを実装しつつ、内部運用の安定性と予測可能性を維持できました。 内部的には、Lake Formation は分析チームと BI ツールにキュレーションデータセットへの対象を絞ったアクセスを付与するためにも使用されています。シンプルですが一元管理されており、一貫性の維持と管理負荷の軽減に役立っています。 取り込みと変換のワークロードについては、チームは引き続き IAM ロールとポリシー を使用しています。Debezium、dbt、Argo Workflows などのサービスは raw および中間ストレージレイヤーへの広範だが制御されたアクセスを必要とし、IAM は内部パイプラインパスに Lake Formation を関与させることなく、最小権限で必要な権限を付与する簡潔なメカニズムを提供します。 Lake Formation をハイブリッドアクセスモードで採用し、内部サービスには IAM を組み合わせることで、Yggdrasil はセキュリティと運用の柔軟性を両立するガバナンスモデルを確立しました。ビジネスの成長に伴い、レイクハウスを安全にスケーリングできる構成です。 成果とビジネスへの影響 Amazon Athena、Amazon S3、AWS Glue Data Catalog 上に構築された新しいレイクハウスは、プレイヤー行動モデリング、予測的なゲームレコメンデーション、不正検知といった高度な分析や AI/ML のユースケースを支えています。 最適化されたレイクハウス設計により、Yggdrasil は新しい分析ワークロードやビジネスユースケースを迅速にオンボードでき、測定可能な成果を実現しています。 運用の複雑性の軽減 : AWS 分析サービスへの統合による簡素化 コスト最適化 : データ処理コストの 60% 削減 データ鮮度の向上 : 分析結果のレイテンシーが 75% 改善 (2 時間から 30 分に短縮) ガバナンスの強化 : AWS Lake Formation のきめ細かな制御の活用 将来に対応したアーキテクチャ : オープンフォーマットとサーバーレス分析の活用 まとめ Yggdrasil Gaming の移行事例は、プロプライエタリな分析システムからオープンで柔軟なレイクハウスアーキテクチャへの移行を成功させる方法を示しています。 AWS Well-Architected Framework の原則に基づいた段階的なアプローチにより、Yggdrasil はビジネス継続性を維持しながらデータニーズに対応する基盤を構築しました。 Yggdrasil の移行から、レイクハウス構築に役立つ教訓が得られました。 現状を評価する : 既存のデータアーキテクチャの課題を特定し、近代化の明確な目標を設定します。 小さく始める : AWS 分析サービスを使用したパイロットプロジェクトから始め、特定のユースケースでレイクハウスアプローチを検証します。 オープン性を重視した設計 : Apache Iceberg などのオープンテーブルフォーマットを活用し、柔軟性を維持してベンダーロックインを回避します。 段階的に実装する : Yggdrasil と同様の段階的な移行戦略に従い、価値の高いワークロードを優先します。 継続的に最適化する : Amazon Athena のパフォーマンスチューニング手法を活用し、効率の最大化とコストの最小化を図ります。 レイクハウスアーキテクチャ構築に関する詳細は、 Amazon SageMaker のレイクハウスアーキテクチャ を参照してください。 著者について Edijs Drezovs Edijs は、AWS パートナーの GOStack の CEO 兼創設者で、クラウドネイティブインフラストラクチャ、データシステム、分析アーキテクチャの近代化を専門としています。12 年以上にわたり、複雑なクラウド変革とデータエンジニアリングの取り組みを推進してきました。 Viesturs Kols Viesturs は、GOStack のデータアーキテクトで、レイクハウスアーキテクチャとリアルタイム分析に深い専門知識を持っています。Yggdrasil Gaming の AWS 分析サービスへの移行の技術実装をリードし、Apache Iceberg とストリーミングデータシステムを専門としています。 Krisjanis Beitans GOStack のシニアデータエンジニアで、レイクハウスアーキテクチャ、Apache Iceberg、Amazon Athena、dbt ベースの変換フレームワークを専門としています。Yggdrasil Gaming の AWS への移行では、Iceberg テーブル構造の設計、Athena パフォーマンスの最適化、dbt 駆動の変換パイプラインの実装を通じて分析レイヤーを再構築しました。 Alvaro Guerrero Alvaro は、AWS のソリューションアーキテクトで、AWS 分析サービスを専門とし、お客様のクラウドソリューション構築を支援しています。 Aleksandra Zgnilec Aleksandra は、AWS のアカウントエグゼクティブで、ベッティング＆ゲーミングのお客様のクラウドおよびビジネス変革を支援しています。 Zahi Njeim Zahi は、AWS のビジネスデベロップメントマネージャーで、ベッティング＆ゲーミング、メディア、エンターテインメント、ゲーム、スポーツを担当しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

本記事は 2026 年 3 月 3 日 に公開された「 Set up production-ready monitoring for Amazon MSK using CloudWatch alarms 」を翻訳したものです。 Apache Kafka をストリーミングプラットフォームとして運用する組織には、安定した運用を維持するための十分なモニタリングが欠かせません。ブローカーの健全性、リソース使用率、データフローのメトリクスを適切に把握できなければ、サービス中断、データ損失、パフォーマンス低下といったリスクが生じ、重要なビジネスオペレーションに影響しかねません。高いシステム負荷から接続の問題まで、異常を早期に検知し、本番ワークロードに影響が出る前に予防措置を講じるには、効果的なモニタリングとアラートが不可欠です。 Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、詳細なメトリクスを Amazon CloudWatch に発行することで、モニタリングの課題に対応します。プロビジョンド (Standard) クラスターでは 1 分間隔でメトリクスが出力され、粒度とコストを制御するための柔軟なモニタリングレベル (DEFAULT、PER_BROKER、PER_TOPIC_PER_BROKER、PER_TOPIC_PER_PARTITION) が用意されています。DEFAULT レベル (無料) ではクラスターレベルのメトリクスが利用でき、上位レベル (有料) ではブローカーレベル、トピック単位、パーティション単位のメトリクスが公開されます。 本記事では、Amazon CloudWatch を使用した MSK クラスターの効果的なモニタリング方法を紹介します。ブローカーの健全性、リソース使用率、コンシューマーラグなどの重要なメトリクスの追跡方法と、運用上の問題を未然に防ぐための自動アラートの設定方法を解説します。紹介するプラクティスは、ストリーミングオペレーションの信頼性向上、リソース使用の最適化、ミッションクリティカルなアプリケーションの高可用性確保に役立ちます。 モニタリングすべき主要メトリクス 本記事では、Amazon MSK の重要なメトリクスを論理的なカテゴリに分類しています。各カテゴリの主要メトリクスとその意味を説明します。 ブローカーの健全性とクラスターの可用性: ActiveControllerCount はクラスターレベルのメトリクスで、各ブローカーがアクティブコントローラーかどうか (1 または 0) を報告します。正常なクラスターでは、常に 1 つのブローカーだけがアクティブコントローラーとして機能します。 average 統計で表示すると、値は 1 をブローカー数で割った値になります。例えば、3 ブローカーのクラスターでは 0.33 (1/3) と表示されます。CloudWatch アラームのしきい値はこれに応じて設定してください。6 ブローカーの場合、average が 0.166 (1/6) を下回ったらアラートを発報します。 sum 統計では、クラスターサイズに関係なく値は常に 1 になり、アクティブコントローラーが 1 つ存在することを示します。sum が 1 以外の場合、コントローラー選出が進行中です。これは通常、メンテナンス作業、設定変更、ローリングリスタート時に発生します。 注意 : KRaft ベースのクラスター では、ActiveControllerCount は専用のコントローラーエンドポイントでのみ公開されるため、サンプル数は 3 で、コントローラーのみが 1 の値を報告します。そのため、クラスター内のブローカー数に関係なく average は常に 0.33 です。KRaft ベースのクラスターでブローカーの健全性を監視するには、LeaderCount メトリクスを確認してください。ブローカーがメトリクスを出力していない場合、そのブローカーに問題がある可能性を示す良い指標です。 OfflinePartitionsCount (クラスター): アクティブなリーダーがないパーティションの数です。0 以外の値は、データが一時的に利用不可または書き込み不可であることを意味します。0 を超えたらアラートを発報してください。 UnderReplicatedPartitions (ブローカー単位): すべてのレプリカが追いついていないパーティションの数です。通常は 0 のままであるべきです。スパイクはトラフィックが容量を超えているか、レプリケーションラグが発生していることを示します。持続的な値は設定や ACL の問題を示すことが多いです。 Amazon MSK クラスターのトラブルシューティング を参照してください。 UnderMinIsrPartitionCount (ブローカー単位): 最小 In-Sync Replica (ISR) 数を下回っているパーティションです。0 以外の値は、ブローカー障害時にデータ損失のリスクがあることを意味します。レプリケーションの健全性を確保するために監視してください。 カスタム設定 を参照してください。 GlobalPartitionCount (クラスター): すべてのトピックにわたるパーティションの合計数 (リーダーのみ) です。キャパシティプランニングや整合性チェックに役立ちます。 PartitionCount (ブローカー単位): ブローカーがホストするパーティション数 (レプリカを含む) です。急激な変化はリバランスが発生している可能性を示します ( ブローカーあたりのパーティション数が過剰になるとパフォーマンスが低下する可能性があります )。 リソース使用率: CPU: ブローカーの合計 CPU 使用率は CpuUser + CpuSystem で定義されます。ベストプラクティスとして、平均 CPU 使用率を 60% 未満 に維持してください。user + system の合計にアラームを設定して過負荷を検知します。 CPUCreditBalance / CPUCreditUsage (ブローカー単位): バースト可能なインスタンスタイプ (T3) の場合、獲得/消費した CPU クレジットを追跡します。クレジット残高の減少やクレジット使用量の増加は、インスタンスが CPU 不足になる可能性を警告します。 メモリ: MemoryUsed、MemoryFree (ブローカー単位) は RAM 使用量を示します。特に重要なのは HeapMemoryAfterGC (ブローカー単位) で、ガベージコレクション後の JVM ヒープ使用率 (%) を報告します。AWS は、メモリ不足を防ぐために HeapMemoryAfterGC が 60% を超えた場合にアラートを発報することを推奨しています。 ディスク: Kafka ブローカーはトピックデータにアタッチされた EBS ストレージを使用します。KafkaDataLogsDiskUsed (ブローカー単位) を監視してください。これはメッセージログが使用しているディスクの割合です。 ベストプラクティス : データログ使用率が 85% を超えたらアラームを設定してください。また、RootDiskUsed (ブローカーが使用するルートディスクの割合) も追跡してください。 EBS I/O: ボリュームメトリクス (ブローカー単位) として VolumeQueueLength、VolumeReadOps、VolumeWriteOps、VolumeReadBytes、VolumeWriteBytes があり、I/O レイテンシーとスループットを示します。キュー長の増加やレイテンシー (VolumeTotalReadTime など) の上昇は、ディスクの競合を示唆します。 ネットワーク: ブローカー単位の基本的なネットワーク統計には、NetworkRxPackets、NetworkTxPackets、エラー/ドロップ数 (NetworkRxErrors、NetworkTxErrors、NetworkRxDropped、NetworkTxDropped) があります。予期しないエラーやドロップはネットワークの問題を示す可能性があります。 トピックとパーティションのアクティビティ: スループット: BytesInPerSec と BytesOutPerSec は、ブローカー単位またはトピック単位の受信/送信データレートを測定します。持続的な低下はプロデューサー/コンシューマーの喪失を示す可能性があり、スパイクはスケーリングが必要な場合があります。 レプリケーショントラフィック: ReplicationBytesInPerSec / ReplicationBytesOutPerSec (トピック単位) は、ブローカー間のレプリケーション量を示します。 コンシューマーラグ: コンシューマーラグメトリクスは、トピックに書き込まれた最新データとアプリケーションが読み取ったデータの差を定量化します。Amazon MSK は、Amazon CloudWatch または Prometheus によるオープンモニタリングで取得できる以下のコンシューマーラグメトリクスを提供します: EstimatedMaxTimeLag、EstimatedTimeLag、MaxOffsetLag、OffsetLag、SumOffsetLag。これらのメトリクスの詳細は、 CloudWatch を使用した Standard ブローカーの Amazon MSK メトリクス を参照してください。 クライアント接続: ConnectionCount (ブローカー単位): アクティブな 接続 の合計数 (クライアント + ブローカー間) です。急激な減少や持続的な高い値 (上限に達している場合) は注意が必要です。 ClientConnectionCount (ブローカー単位、認証フィルター付き): アクティブな認証済みクライアント接続数です。 ConnectionCreationRate / ConnectionCloseRate (ブローカー単位): 1 秒あたりの新規接続数または切断数です。接続チャーンのスパイクはクライアント側の問題を示す可能性があります。 認証: IAMNumberOfConnectionRequests と IAMTooManyConnections (ブローカー単位) は、IAM 認証リクエストレートとスロットル違反 (同時接続数 100 の上限) を示します。 ネットワーク帯域幅メトリクス: TrafficShaping > 0 (スロットリング発生) メトリクスは、主要な警告シグナルです。この値が 0 を超えると、MSK クラスターで EC2 レイヤーのネットワークスロットリングが発生しており、割り当てを超過したためにパケットがドロップまたはキューイングされています。このスロットリングは、スループットの低下、レイテンシーの増加、ネットワークエラーとして現れ、プロデューサーとコンシューマー双方のパフォーマンスに影響します。TrafficShaping の問題は、BwInAllowanceExceeded と BwOutAllowanceExceeded の 2 つの帯域幅制限に起因します。 BwInAllowanceExceeded は、受信の合計帯域幅がブローカーの上限を超えた場合を追跡します。 BwOutAllowanceExceeded は、送信の合計帯域幅が上限を超えた場合を監視します。 BwInAllowanceExceeded と BwOutAllowanceExceeded の両メトリクスは、ネットワークスロットリングイベント全体に直接影響します。 その他の運用メトリクス: スレッドプール: RequestHandlerAvgIdlePercent、NetworkProcessorAvgIdlePercent (ブローカー単位) は、Kafka の内部スレッドプールのビジー状態を示します。アイドル率 (%) が常に低い場合、ボトルネックの可能性があります。 ZooKeeper: ZooKeeper ベースの MSK クラスターでは、ZooKeeperRequestLatencyMsMean と ZooKeeperSessionState が ZK のパフォーマンスを反映します (ZooKeeper を使用する古い Kafka バージョン向け)。ZooKeeperSessionState が 5〜10 分間 1 以外の場合、ブローカーに問題があるか、断続的なネットワークの問題で ZooKeeper がブローカーに接続できない可能性があるため、注意が必要です。 階層型ストレージ: 階層型ストレージが有効なクラスターでは、Amazon MSK は RemoteFetchBytesPerSec、RemoteCopyBytesPerSec、RemoteLogSizeBytes などのメトリクスと関連するエラー/キューメトリクスを提供します。リモートストレージへのオフロードを追跡するメトリクスです。 インテリジェントリバランスメトリクス: Express ブローカーを使用する MSK プロビジョンドクラスターでは、Amazon MSK はリバランス操作を監視するための 2 つの主要メトリクス (RebalanceInProgress と UnderProvisioned) を提供します。 インテリジェントリバランスメトリクスの監視 を参照してください。 メトリクスをカテゴリに分類することで、Amazon MSK の健全性とパフォーマンスを全体的にカバーする ダッシュボードとアラート を構築できます。Amazon CloudWatch は Amazon MSK 用の 自動ダッシュボード も提供しています。 CloudWatch の自動ダッシュボードへのアクセス方法を簡単に見てみましょう。AWS コンソールで CloudWatch サービスに移動します。CloudWatch コンソールで「ダッシュボード」を選択します。 自動ダッシュボード タブを開き、フィルターバーで MSK を検索します。 自動ダッシュボードには主要メトリクスのビジュアライゼーションが事前設定されており、MSK クラスターの健全性とパフォーマンスを素早く把握できます。 推奨される CloudWatch アラーム 主要メトリクスにアラームを設定することで、問題を早期に検知できます。ストリーミングアプリケーションでは 1 秒が重要であり、早期検知が欠かせません。1 つのブローカーの障害が連鎖反応を引き起こし、データ取り込みの停止、上流システムのバックアップ、下流アプリケーションの障害につながる可能性があります。注文処理の遅延から収益損失へと急速にエスカレートすることもあります。適切にモニタリングすることで、ビジネスオペレーションに影響が出る前に問題を検知して修正できます。 AWS のベストプラクティス と経験に基づき、以下のようなアラームを検討してください。 メトリクス (ディメンション) アラーム条件 根拠 ActiveControllerCount (クラスター) ≠ 1 (カウント) アクティブコントローラーは 1 つだけ存在すべきです。逸脱はクラスターの不安定性を示します。 CPU 使用率 (Sum(CPUUser+CPUSystem)、ブローカー単位) > 60% (平均) が 5 分以上 ブローカーの負荷やメンテナンスに備えた余裕を維持します。CPU が高いと処理が遅くなる可能性があります ( MSK ベストプラクティスドキュメント 参照)。 HeapMemoryAfterGC (ブローカー) > 60% (パーセンテージ) Kafka ヒープが逼迫していることを示します。OOM を防ぐために早期にアラートを発報します。 KafkaDataLogsDiskUsed (ブローカー) ≥ 85% (パーセント) ディスクがほぼ満杯であることを警告します。スケーリングやクリーンアップの時間を確保してデータ損失を防ぎます。 OfflinePartitionsCount (クラスター) > 0 (カウント) オフラインパーティションはデータが利用不可であることを意味します。即座に調査が必要です。 UnderReplicatedPartitions (ブローカー) > 0 (カウント) 正常な状態ではレプリカの遅延は発生しません。スパイクや持続的なラグは、過負荷や ACL の設定ミスを示す可能性があります。 UnderMinIsrPartitionCount (ブローカー) > 0 (カウント) min.insync.replicas 設定より少ない In-Sync Replica を持つパーティション、または RF=MinISR のトピックが存在するはずです。パーティションがアンダーレプリケートされているトピックを見つけるには、以下のコマンドを使用してください: <path-to-your-kafka-installation>/bin/kafka-topics.sh –bootstrap-server <bootstrap-server:port> —command-config client.properties –describe –under-min-isr-partitions ConnectionCount (ブローカー) 急激な低下 (例: ベースラインの 90% 未満) または高しきい値を超えるスパイク クライアントの接続問題や接続フラッドを検知します。予期しない低下はブローカーに到達できないことを意味する場合があります。 Amazon MSK Standard ブローカーのクォータ を参照してください。 CPUCreditBalance (T3 ブローカー向け) < 低しきい値 (例: 10 クレジット) バースト可能なインスタンスで、クレジットがほぼ枯渇した場合にアラートを発報し、パフォーマンス低下を防ぎます。 VolumeQueueLength (ブローカー) > 0 (持続的) または上昇傾向 I/O オペレーションがキューイングされていることを示し、ディスクのボトルネックの可能性があります。 NetworkRxErrors/TxErrors (ブローカー) > 0 (カウント) ネットワークエラーはパケットロスや切断を引き起こす可能性があります。 IAMTooManyConnections (ブローカー) > 0 (カウント) IAM 接続上限 (100) を超えると、新しい接続がブロックされます。 コンシューマーラグ (MaxOffsetLag または SumOffsetLag) (コンシューマーグループ/トピック単位) > しきい値 (SLA に依存、例: 想定を超えて増加) コンシューマーの遅延をアラートし、コンシューマーのスケーリングやバックログの調査を促します。 TrafficShaping > 0 (スロットリング発生) ブローカーが割り当てられたネットワーク帯域幅を超過していることを示します。 上記は例示的なしきい値です。ワークロードと SLA に合わせて調整してください。 Standard および Express ブローカーの CloudWatch メトリクスドキュメント に記載されている残りのメトリクスは、上記の主要メトリクスの異常による下流への影響を受けやすいものです。MSK フリート全体にカバレッジを拡大する前に、まず単一のテストクラスターで CloudWatch アラームを有効にしてしきい値を検証することを推奨します。 まとめ 本記事では、Amazon MSK クラスターを効果的にモニタリングするための重要な CloudWatch メトリクスとアラームについて解説しました。推奨アラームを実装すれば、Kafka ワークロードに影響が出る前に潜在的な問題を検知して対応できます。Amazon MSK のモニタリングの詳細については、 Amazon MSK モニタリングベストプラクティス ドキュメントを参照するか、 Amazon MSK ワークショップ でハンズオン体験をお試しください。 著者について Yashika Jain Yashika は、AWS のシニアクラウドアナリティクスエンジニアで、リアルタイム分析とイベント駆動アーキテクチャを専門としています。リアルタイムデータプラットフォーム全般のベストプラクティスの推進や、ストリーミングデータアーキテクチャに関する複雑な問題の解決を通じて、お客様を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

2026 年 1 月、三菱電機株式会社 電力システム製作所 電力 ICT センターで、 3 日間にわたる「AI-DLC Unicorn Gym」が開催されました。 AI 駆動開発ライフサイクル（AI-DLC）を組織的に体験する Unicorn Gym に、 33 名のエンジニアが参加。本記事では、運営を担当した電力 ICT センターの中村様が聞き手となり、実際に参加した増成様、相原様、小森様に体験を語っていただきました。 AI 駆動開発ライフサイクル（AI-DLC）とは 中村 : まず「AI-DLC って何？」と聞かれることが多いので、簡単に説明させてください。 AI-DLC（AI 駆動開発ライフサイクル）は、 AI をソフトウェア開発の中心的な協力者として位置づける新しい方法論です。「AI が実行し人間が監視する」「ダイナミックなチームコラボレーション」という 2 つの柱のもと、開始（Inception）・構築（Construction）・運用（Operation）の 3 フェーズでソフトウェア開発を進めます。 AI が要件定義から設計・実装・テストまでの成果物を迅速に生成し、人間がビジネス判断と品質の監視を行うことで、品質を維持しながら開発速度を大幅に向上させるアプローチです。詳しくは AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 をご覧ください。 私たちの紹介 中村 : 改めまして、今回の座談会メンバーを紹介します。私たちは三菱電機 電力システム製作所の電力 ICT センターに所属しています。電力 ICT センターは横浜に拠点を置き、電力の安定供給を支える制御・監視システムから、クラウドを活用した次世代の電力プラットフォームまで、幅広い領域でソフトウェア開発に取り組んでいる部門です。 増成 : 私はインフラ寄りの品質管理を担当しています。アプリ開発の経験はほとんどありません。 相原 : 私は当社パッケージのグローバル開発に向けた AWS 活用やアジャイル開発を推進しています。 Kiro は公開直後から使い込んでいて — 自分では「Kiro ちゃん」と呼んでるんですが（笑）。 小森 : 私は CI/CD 環境の構築や AI エージェントツールを活用した開発の仕組みづくりを担当しています。先日、 AWS Blog で Kiro と GitLab Duo を活用した開発ワークフローの標準化について記事 を執筆しました。 エンジニアコミュニティ「YOKOHAMA UNITED」から始まった 中村 : では、今回の AI-DLC Unicorn Gym が実現した背景からお話しします。私たちの部門ではプロジェクト運営改善委員会（PMON）が中心となって「YOKOHAMA UNITED」というエンジニアコミュニティを運営しています。毎週「You 勉強会」— You は YOKOHAMA UNITED の頭文字です — を開催していて、テーマは生成 AI やクラウドなど業務に関わる技術動向が中心です。現時点でコミュニティは 600 人規模、勉強会は 110 回を超え、毎回 30〜40 名が参加するところまで成長しました。 小森 : You 勉強会がきっかけで Kiro を知った方も多いですよね。 中村 : そうなんです。 2025 年 7 月に Kiro に触れたのがきっかけでした。 Vibe Coding や Spec 駆動開発での生産性の高さに驚き、 You 勉強会で AWS の方に説明いただく機会を得ました。その事前打ち合わせで「個人の生産性向上はわかったけど、組織やチームではどう活用すればいいのか？」と質問したところ、 AI-DLC を紹介していただきました。 開催までの道のり 中村 : 最初にコミュニティのチャネルで募集をかけたときは、反応が今ひとつでした。 3 日間のワークショップは個人の裁量で参加するにはハードルが高い。そこで方針を転換して、管理職に AWS から直接 AI-DLC の説明会を開催していただきました。 増成 : 管理職の合意が得られてから再募集したら、 20 名の枠に 40 名が応募したんですよね。 中村 : そうなんです。潜在的なニーズは想像以上でした。最終的に開発環境の制約もあり、 5 チーム 33 名での開催になりました。各チームが部門内の実際の業務課題を持ち寄ってテーマを決めています。既存業務システムの改良、 SaaS 上のダッシュボード構築、 IoT プラットフォームの改善など、どれもリアルな課題です。 3 日間の進め方 中村 : ワークショップは 2026 年 1 月 14 日〜16 日の 3 日間で開催しました。初日はセミナールームにチーム毎に分かれて着席し、オープニングセッションの後、 AWS から AI-DLC の概要説明を受け、まずは共通テーマ「EC サイト構築」でハンズオンを実施しました。 相原 : 最初に全員で同じテーマをやることで、進め方のイメージが掴めましたよね。 中村 : そうですね。進め方を理解したところで、各チームの実テーマに沿って最初のステップである開始（Inception）フェーズに着手。各チームのテーブルには AWS のメンバーが 1 名専任で付き、手厚くサポートいただく形で進めました。ユーザーストーリの構築が完了したチームから順次、構築（Construction）、運用（Operation）へと進みます。 AI のアウトプットの速さは関係者を一か所に集めた上でその場で意思決定のためのアウトプットを作成することを可能にするため、通常は数週間〜数カ月かかる開発も短期間で可能にします。 チーム毎のテーマと成果 中村 : 部門内の様々なビジネスユニットの課題をチーム毎に持ち寄り、テーマを決めました。 5 チームそれぞれが 3 日間でリアルな業務課題にチャレンジしています。 チーム テーマ 成果 チーム A 既存業務システム改良 フロントエンドは React, TypeScript、データベースはPostgreSQLの構成で、既存システム処理に必要な情報の設定画面を開発 チーム B 既存業務システムのマイクロサービス化 既存システムの機能を模擬したReactベースの画面を構築。ダッシュボードを用いて、一連の業務実行可能なことを確認 チーム C IoT プラットフォーム管理画面の使いやすさ向上 AI 駆動でドキュメント分類・コンテンツ生成を行い、RAG方式のチャットボットで回答する、IT に詳しくない一般ユーザでも使いやすい管理画面を開発し、効率的なオンボーディングのデモを実施 チーム D 業務状況確認ダッシュボード開発 SAP UI5を利用しダッシュボード画面・一覧画面・詳細画面・操作ガイドを実装し、 SAP クラウド環境上へデプロイ完了 チーム E 教育プラットフォーム構築 フロントエンドは React、バックエンドは Java で構築された既存アプリに対して、オンボーディング機能を追加開発。ドキュメント管理・コンテンツ生成・チャットボット・フィードバック分析を実装し、セキュリティを確保した環境へデプロイ完了 小森 : チーム D は SAP UI5 を利用しダッシュボード画面・一覧画面・詳細画面・操作ガイドを実装し、 SAP クラウド環境上へデプロイ完了しました。2 日目時点ですでに動くものが出来上がっていました。 増成 : チーム E は短期間でこれだけのシステム構築ができたことに驚きの声が上がっていました。 中村 : どのチームも「3 日間でここまでできるのか」という手応えを感じていたのが印象的でした。 やってみてどうだった？ 中村 : では、実際に参加してみた感想を聞かせてください。増成さんはチーム A でしたね。 増成 : はい。私たちのチームでは既存システムの設定画面を開発したんですが、正直、自分が参加して意味があるのかなと思っていました。アプリ開発の経験がないので。でも終わってみたら「これは実際の開発に適用すべき」と強く感じました。短時間で大きなアウトプットが出てくるので大幅な時短ができます。ただ、適切なタイミングで適切なインプットをさせてあげる、これが難しかった。 中村 : 具体的にはどういうことですか？ 増成 : 既存ドキュメントをまとめて読ませれば、よしなにやってくれるだろうと思ったんです。そうしたら目を通すのが大変な特大ドキュメントが生成されて。本来技術的な話が出てきてはいけないフェーズなのに技術的な内容が混ざっていたり。過剰なインプットはノイズになるし、少なすぎると的外れになる。このバランスが一番の学びでした。 中村 : なるほど。 AI への情報の渡し方が鍵になると。 増成 : そうですね。あと、今回のプロセスを通じて「そういえばこういうドキュメントなかったな」という気づきがありました。現状の開発プロセスやドキュメントを見直すきっかけにもなると思います。 中村 : 相原さんはどうでしたか？事前に Kiro を使いこなしていたと聞いていますが。 相原 : はい、 Spec 駆動開発モードも使いこなし、「簡単な要件をインプットすれば Mock 画面も簡単に作れるじゃん！ Kiro ちゃんスゲー」状態の私に死角は無い…と思ってました。 中村 : 思ってた、と（笑）。 相原 : 1 日目はまだ余裕だったんです。「Kiro ちゃんは Spec 駆動以外でも要件を残せて、モブセッションにも向いてるのか、イイネ」って。ところが、チームで要件を詰め始めたら「要件ふわっとしすぎじゃね？」と。 中村 : 2 日目はどうなりましたか？ 相原 : ふわっとした要件でも Kiro ちゃんはユーザーストーリーを作ってくれるんですが、範囲が広すぎる。 AWS の方に「ユーザーストーリーが出た段階で Mock 作れますよ」と言われて作ってみたら、「あれ？これって本当に私たちが検討したい内容なんだっけ」と。要件定義に戻る。同じフェーズを何度もループする状態になりました。 小森 : 他のチームから見ても「あのチーム、2 回 Inception 回してるな」って見えてましたよ（笑）。 相原 : 3 日目の午前中まだ Inception から抜け出せてなくて、午後にようやく構築フェーズに入って「皆の衆、作業にかかれ！」と。 中村 : そこからは順調に？ 相原 : いえ、終了 30 分前に各ユニットを結合したら上手く動かなくて焦りましたが、AI-DLC の中ではちゃんと開発の過程をドキュメントに残しながら、進めているので、動かない理由もすぐリカバリーすることができ、なんとか要件をカバーするダッシュボードができました。 中村 : 最終的にはできたんですね。 相原 : はい。昔はここまでに半年かかってたので。それに、 他のチームから「手戻りですよね」と言われたとき気づいたんです。これは手戻りじゃなくて「失敗を素早く試せた」だけだと。すぐに失敗できるのって最高です 。 中村 : 小森さんのチームはどうでしたか？ 小森 : 最初にプロンプトを流し込んで Kiro からの返事が返ってきたとき、質問の多さに圧倒されました。でも「あー、確かにここって検討しないといけないよな」という検討漏れに気づけたんです。「これって必要ですか？」「必要な理由は？」とチーム内で議論が活発になって、議論するたびに開発対象への理解が深まりました。 中村 : 関係者全員で議論する場が強制的に作られる、というのは面白いですね。 小森 : そうなんです。「この機能は今は不要だから削ろう」「これは後で必要になるから優先順位を下げて残そう」といった判断も、全員がその場にいるので納得感を持って進められました。一方で、 AI がドキュメントをどんどん生成するので、気がつくと大量のドキュメントが溜まっていて。 AI 用のドキュメントと人間が後で確認するドキュメントを分けるなど、環境整備が必要だなと感じました。 中村 : 成果物としてはどこまでできましたか？ 小森 : 我々のチームでは既存の Web アプリにヘルプツールを開発して埋め込みましたが、実働ほぼ 2 日で見せられるクオリティにまで持っていけたのは強力でした。しかも我々のフレームワークを理解した上で作られていたのには驚きました。 AI-DLC を体験したことによる変化 中村 : AI-DLC を体験したことで、どんなところが変わっていくと思いますか？ 増成 : 従来の開発では生成 AI を個人で利用することが中心でした。今回、AI-DLC Unicorn Gym を体験できたことで AI を中心に据えて上流の要件定義から行うことができたので、今までプログラム製作を行ってこなかったメンバーも簡単に UI のイメージを作れることがわかりました。これによりお客様への価値提供に直接関わるメンバーが増やすことができ、そのスピード、生産性も向上できることからより大きな力を得ることができそうです。 相原 : 今まで生成 AI を使っていなかったメンバーが使うようになったのが大きいです。それに、他の人がやってるプロンプトの書き方とか便利な利用方法も学ぶことができました。AI-DLC Unicorn Gym ではモブワークでメンバー間のディスカッションが活発になり、チームのコミュニケーションも変わったと感じています。また、モブワークによる技術継承の効果もありそうだと感じています。今までのドキュメント製作者、レビュー者というある意味対立する立場から、一緒の方向を向いて進んでいく仲間としてビジネスを推進できるようになるんじゃないかな。 ⼩森 : 確かに AI-DLC で上流設計の要件定義にみんなで参画したのも大きい。要件を決めるところに入ったことで、いわゆる意思決定に参画することになり、皆が自分事になって開発に取り組むことができていました。チーム、組織のマインドセットも変えていけそうな気がします。 ハピネスドアで見えた 3 日間の感情曲線 中村 : 連日の熱い議論を見て、この熱量を可視化したいと思い、アジャイルマネジメントシステム Management 3.0 のプラクティス「ハピネスドア」を導入しました。ドアや白板に 4 段階（Very happy, happy, unhappy, sad）の絵文字付箋を貼っておき、各メンバーが自分のコメントを書いた付箋をそこに貼っていくもので、リアルタイムの満足度を可視化する手法です。 相原 : チーム毎に付箋の色を変えてたのが良かったですよね。チーム単位の温度感が一目でわかりました。 中村 : 3 日間のエンゲージメントスコア（4 点満点）は 3.3 → 3.1 → 3.6 と推移しました。 1 日目：生成 AI のアウトプットの速さに驚いた。すごい！ — Surprised!! 2 日目：AI の返しが速すぎて、人間側の判断・仕様検討が追いつかない。ちょっと気分ダウン — Tired!! 3 日目：限られた時間の中でゴールを決めて進み、各チーム成果を出せた — Very happy!! 増成 : 2 日目のスコアが下がったのは、どのチームも「AI は速いけど人間が追いつかない」という壁にぶつかったタイミングでしたね。 アンケート結果 参加者全員に実施したアンケートでは、以下の結果が得られました。 働き方の変化 : 90% 以上が「AI-DLC は働き方を変える可能性が高い」と回答 生産性改善 : 従来の手作業中心の開発と比較して、参加者の体感値として「30〜40 倍の生産性がある」と回答 他の方への推薦 : 97% が「第二回開催を他の方に勧めたい」と回答 3 日間という短い期間でしたが、参加者が AI-DLC の本質的な価値を実感できたことが数字に表れています。 これからの挑戦 中村 : 最後に、今後の話をさせてください。今回参加した 33 名を起点に、まずは各チームが自分の組織に持ち帰って共有する場を設けます。すでに次のテーマ選定にも着手していますし、三菱電機グループの部門横断 AWS ユーザーコミュニティ「 MAWS-UG 」への発信や、社内の年次イベントである「Melco AWS Day」へ登壇も決まっています。 YOKOHAMA UNITED の 600 人のコミュニティ、さらには MAWS-UG を通じてグループ全体へと広げていきたいですね。 増成 : 「AI-DLC いいぞ、いいぞ！」と啓蒙活動にも力を入れていきます！ 相原 : 早速、AI-DLC を実プロダクトの検討フェーズに適用できないかトライしてみています。絶賛 Inception フェーズにいます。失敗を素早く試せるのが AI-DLC の良さなので、またループするかもしれませんが、チャレンジしてみようと思っています。 小森 : AI-DLC をきっかけに AI エージェントツールを初めて使った方も多かったので、ここからがスタートですね。どんどん進めていきたいです。 中村 : ユニコーンを創るジムでしたから。ここから先が本番です。 座談会メンバー 中村 信夫 電力デジタルエナジーシステム開発部 品質管理課。品質管理業務を担当する傍ら、プロジェクト運営改善委員会（PMON）を立ち上げ、ツール・環境を提供。コミュニティ「YOKOHAMA UNITED」も PMON が運営。 増成 謙汰郎 電力デジタルエナジーシステム開発部 品質管理課。品質管理の一環で生成 AI を中心とした様々な技術やツール・環境を活用し、業務適用設計や技術検証を担当。 小森 裕之 電力デジタルエナジーシステム開発部 システム基盤課。電力 ICT センター内の全ビジネスユニットの開発・運用に貢献するため、 ITIL4 に準拠した専用プラットフォームの開発に携わり、 CI/CD 環境の検討・構築・導入や AI エージェントツールを活用した開発の仕組みづくりを担当。 相原 祐太 Digital Energy 事業統括センター準備室 開発推進課。当社パッケージ BLEnDer のグローバル開発に向けた AWS 活用・アジャイル開発適応・プロダクト設計/開発/推進担当。 著者プロフィール 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。2022 年から三菱電機グループを支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今年の目標は Kiro にどんどん業務をオフロードしていくことです。今日ご紹介する AWS Observability の Kiro Power を使ってみたのですが、複数の監視/運用に関する MCP とその使い方がパッケージングされていて体感として想定している作業を実現するためのプロンプト入力作業が減ってトラブルシュートが加速しました。 先週は Amazon と OpenAI の Strategic partnership が発表されました。 Stateful Runtime Environment や OpenAI Frontier に関しても言及されているので、気になる人はぜひご一読をお勧めいたします。また、 3 月 26 日（木）には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください！ それでは、2 月 24 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ: 住信 SBI ネット銀行様、Amazon Bedrock AgentCore を活用した AI 銀行サービス「NEOBANK ai」で顧客体験を革新 住信 SBI ネット銀行様は、デジタル金融における新しい UI/UX の可能性を見据え、ユーザーが「やりたいこと」を伝えるだけで必要な手続きが立ち上がる体験の実現を目指していました。従来のメニュー階層をたどる UI では、ユーザーの意図に沿ったスムーズな体験を提供しにくい場面があったためです。そこで、Amazon Bedrock AgentCore を中核とした AI エージェント機能を活用し、AI 銀行サービス「NEOBANK ai」のベータ版を開発しました。テキスト入力に加え、音声・画像を含むマルチモーダルなインプットを受け取り、AI エージェントが意図を解釈したうえで、照会・分析・手続き案内に必要な“その場で立ち上がる UI”を生成します。AgentCore Runtime による自動スケーリングや、タスクごとに異なる AI モデルを使い分ける柔軟なアーキテクチャ、AgentCore Observability による実行プロセスの可視化も実現しています。今後は ITSM 連携の強化やさらなるサービス高度化を目指すとのことです。 AWS 生成 AI 国内事例ブログ: ミツイワ株式会社様、Amazon Bedrock と AWS CloudFormation を活用した次世代インフラ自動構築ソリューション ミツイワ株式会社様は、ICT ライフサイクル全体をサポートするワンストップソリューションを提供する中で、顧客からの問い合わせ内容の整理や要件定義、環境構築に多くの時間がかかり、リードタイムの長期化や品質のばらつき、属人化といった課題を抱えていました。そこで、Amazon Bedrock による問い合わせ内容の自動解析と、AWS CloudFormation によるインフラ構築の自動化を組み合わせた次世代ソリューションを開発しました。AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成により、問い合わせ受付から環境構築・初期設定・完了通知までを一気通貫で自動化し、従来数日から数週間かかっていたプロセスを大幅に短縮することに成功しています。 ブログ記事「 Amazon Q Developer 活用をプロジェクト全体へ拡げた取り組み 」を公開 株式会社 NTT ドコモ様の主要な Web サービス提供基盤「POPLAR」における Amazon Q Developer の組織展開事例です。 Software/Middleware のバージョンアップ案件で最大約 50% の効率化を達成し、その成功体験をもとに利用ガイドライン・環境設定マニュアル・プロンプト集などを体系化してプロジェクト全体へ展開しました。さらに生成 AI 開発ガイドラインの標準化や MCP Server 連携環境の整備、利用状況のダッシュボード可視化と個別フォローまで、段階的な取り組みの全体像が紹介されています。 ブログ記事「 Strands Labs の紹介: エージェント開発の最先端実験的アプローチを今すぐ体験 」を公開 エージェンティック AI 開発のための実験的なアプローチを試せる新しい Strands GitHub 組織「Strands Labs」が発表されました。ローンチ時には 3 つのプロジェクトが公開されています。Robots は AI エージェントが物理ロボットを制御するフィジカル AI、Robots Sim はシミュレーション環境での迅速なプロトタイピング、AI Functions はコードの代わりに自然言語仕様で関数を定義する実験的アプローチです。Strands Agents SDK を活用したエージェント開発に興味のある方はぜひチェックしてみてください。 ブログ記事「 AWS Elemental Inference でライブ動画をモバイルオーディエンス向けに変換 」を公開 新サービス AWS Elemental Inference が発表されました。ライブ動画やオンデマンド動画を AI で自動的に分析し、TikTok や Instagram Reels などのモバイルプラットフォーム向けに縦型形式へリアルタイム変換するフルマネージド AI サービスです。エージェンティック AI アプリケーションを使用しており、人間の介入なしにコンテンツを自律的に最適化します。ベータテストでは、複数のポイントソリューションを使用する場合と比較して 34% 以上のコスト削減を達成しています。 ブログ記事「 カスタム Amazon Nova モデル用の Amazon SageMaker Inference の発表 」を公開 Amazon SageMaker Inference でカスタム Nova モデルのサポートが一般提供開始されました。Nova Micro、Nova Lite、Nova 2 Lite のカスタマイズモデルを、G5 や G6 インスタンスを使用してコスト効率よくデプロイできます。SageMaker Training Jobs や HyperPod でトレーニングしたモデルをシームレスにデプロイする、エンドツーエンドのカスタマイズジャーニーが実現しています。 ブログ記事「 Agentic AI でサプライチェーン ロジスティクスを変革 」を公開 この記事では、AWS プロフェッショナルサービスがシンガポールの科学技術研究庁（A*STAR）と共同で開発した物流エージェントの事例を紹介しています。Amazon Bedrock を活用し、ERP・TMS・WMS などの複数データソースからリアルタイムにデータを集約・統合することで、自然言語での問い合わせに対して即時かつ正確な回答を提供します。手動での検索・照合作業を最大 50% 削減し、緊急配送コストを物流費用の 3〜5% 削減する効果が見込まれています。 ブログ記事「 AI コーディングに潜む非効率性とその発見方法 」を公開 AI コーディングエージェントは合格率やトークン数といったベンチマークで評価されることが一般的ですが、タスクが「合格」していても、エージェントが非効率な経路をたどっているケースがあります。この記事では、Kiro の AI エージェントが取った一連のアクション全体を軌跡ベースで分析し、ベンチマークでは見逃される非効率性を発見・改善する仕組み「CORAL」を紹介しています。具体例として、検索ツールの説明に 1 行追加するだけで誤った grep パターンを約 99% 削減した事例や、cd コマンドの誤用を検知して自動的に正しいパラメータに変換する仕組みが解説されています。 サービスアップデート Amazon Bedrock の Responses API にて AgentCore Gateway 連携によるサーバーサイドツール実行をサポート Amazon Bedrock の Responses API にて、Amazon Bedrock AgentCore Gateway を通じたサーバーサイドツール実行がサポートされました。AgentCore Gateway の ARN をツールコネクタとして指定すると、Amazon Bedrock がゲートウェイから利用可能なツールを自動検出し、モデルがツールを選択した際にサーバーサイドで実行します。これにより、クライアントサイドのツールオーケストレーションループを構築・維持する必要がなくなり、エージェンティックワークフローのアプリケーション複雑性とレイテンシーが削減されます。Responses API と AgentCore Gateway の両方が利用可能なすべてのリージョンで利用できます。 Amazon Bedrock バッチ推論にて Converse API フォーマットをサポート Amazon Bedrock のバッチ推論にて、モデル呼び出しタイプとして Converse API がサポートされました。従来はモデル固有のリクエストフォーマットが必要でしたが、リアルタイム推論とバッチ推論で同じ統一リクエストフォーマットを使用できるようになり、プロンプト管理の簡素化とモデル切り替えの手間が削減されます。Amazon Bedrock バッチ推論がサポートされているすべてのリージョンで利用可能です。 Amazon Bedrock にて OpenAI 互換 Projects API を発表 Amazon Bedrock の分散推論エンジン Mantle にて、OpenAI 互換の Projects API がサポートされました。複数のアプリケーション、環境、チームを持つお客様は、個別のプロジェクトを作成して分離を実現できます。各プロジェクトに異なる IAM ベースのアクセス制御を割り当てたり、タグを追加してコスト可視性を向上させることが可能です。追加料金なしで利用できます。 Amazon Bedrock Guardrails の Automated Reasoning ポリシーにてソースドキュメント参照を追加 Amazon Bedrock Guardrails の Automated Reasoning ポリシーにて、ソースドキュメント参照機能が追加されました。Automated Reasoning checks は形式検証技術を使用して、基盤モデルが生成したコンテンツがポリシーに準拠しているかを検証する機能で、AI ハルシネーション検出において最大 99% の精度を実現します。今回の更新により、生成されたポリシールールや変数を元のドキュメントの内容と照らし合わせてレビューできるようになり、ポリシーの確認・改善が容易になりました。 Amazon Q Developer にて生成 AI ベースのアーティファクト機能を一般提供開始 AWS マネジメントコンソールにて、Amazon Q Developer アーティファクト機能が一般提供開始されました。リソースデータをテーブル形式で、コストデータをチャート形式で可視化できる生成 AI ベースのユーザー体験です。例えば「タグ値が production の S3 バケットを一覧表示」と質問すると表形式で表示され、「過去 6 か月の RDS コストをインスタンスタイプ別に表示」と質問するとチャートで表示されます。Q アイコンがナビゲーションバーに移動し、コンソールのどこからでもアクセスしやすくなりました。 AWS Elemental Inference を一般提供開始 ライブ動画やオンデマンド動画を AI で自動的に変換するフルマネージドサービス AWS Elemental Inference が一般提供開始されました。エージェンティック AI を使用して、横型配信を TikTok や YouTube Shorts などのモバイルプラットフォーム向けの縦型形式にリアルタイムで変換する機能と、ライブコンテンツからハイライトクリップを自動生成する機能を提供します。米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ムンバイ）、欧州（アイルランド）で利用可能です。 AWS IAM Policy Autopilot が Kiro Power として利用可能に re:Invent 2025 で発表されたオープンソースの静的コード分析ツール AWS IAM Policy Autopilot が、Kiro Power として利用可能になりました。Kiro IDE からワンクリックでインストールでき、手動での MCP サーバー設定が不要です。AWS アプリケーションの迅速なプロトタイピングや新規プロジェクトのベースラインポリシー作成に活用できます。 AWS Observability が Kiro Power として利用可能に AWS Observability が Kiro Power として利用可能になりました。CloudWatch、Application Signals、CloudTrail、AWS Documentation の 4 つの MCP サーバーをパッケージ化し、アラーム対応、異常検知、分散トレーシング、SLO コンプライアンス監視、セキュリティ調査などの包括的なワークフローを IDE 上で実現します。自動ギャップ分析機能により、コード内の不足しているインストルメンテーションパターンの特定と改善提案も行います。 Amazon Location Service が Kiro Power として LLM コンテキストを提供 Amazon Location Service が、Kiro Power および Claude Code プラグインとして AI エージェントコンテキストを提供開始しました。住所入力フォーム、地図表示、最寄り店舗検索、ルート可視化などの一般的な位置情報ソリューション開発を加速する、事前検証済みの実装パターンとステップバイステップの手順が含まれています。東京リージョン含む複数のリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 先日、Developer Summit に AWS として出展をしてきたのですが、私は Physical AI デモとしてロボットの自然言語で動作するロボットの展示をしておりました。昨今やはり Physical AI というワードにはみなさん敏感で、デモについても面白いといって足を止めていただける人が非常に多く大変好評でした。普段 Web サービスの開発をされている方でロボット開発に縁がないという方も、Amazon Bedrock と AWS IoT Core 等を使って、クラウドとデバイスを連動させた仕組みに可能性を感じていただけました。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年2月23日週の主要なアップデート 2/23(月) Automated Reasoning ポリシーにソースドキュメントへの参照が含まれるようになりました Amazon Bedrock の Automated Reasoning policies に、元の文書への参照機能が追加されました。これまでは HR ポリシーや財務承認ガイドラインなどの文書をアップロードして形式論理ルールに変換する際、生成されたポリシーの内容を確認するのが困難でした。今回のアップデートにより、元の文書内容を参照しながらポリシールールをレビューできるようになり、AI の回答精度向上や幻覚 (hallucination) 検出に活用できます。バージニア北部リージョンなど 6 リージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Redshift Serverless が 3 年間のサーバーレス予約を導入 Amazon Redshift Serverless で、新しい 3 年間の Serverless Reservations が提供開始されました。従来の 1 年間のコミットメントから期間が延長され、最大 45% のコスト削減を実現できます。特定数の RPU (Redshift Processing Units) を 3 年間コミットし、前払いなしの支払いオプションを選択できます。AWS の支払いアカウントレベルで管理されるため、複数の AWS アカウント間で共有可能です。時間単位で請求され、秒単位で計測される柔軟な料金体系を維持しながら、長期的なコスト予測が可能になります。コミットした RPU を超過した使用量は、通常のオンデマンド料金で課金されます。Amazon Redshift コンソールまたは API 経由で購入でき、Redshift Serverless が利用可能な全リージョンで提供されています。 AWS IAM Policy Autopilot が Kiro Power として利用可能になりました AWS IAM Policy Autopilot が Kiro Power として利用可能になりました。このツールは開発者が手動で IAM ポリシーを作成する手間を省き、アプリケーションの進化に合わせて調整可能なベースラインポリシーを素早く生成できます。Kiro IDE からワンクリックでインストールでき、AI 支援開発環境にシームレスに統合されます。AWS アプリケーションのプロトタイピングや新プロジェクトでのベースラインポリシー作成に最適で、開発ワークフローを離れることなくポリシー生成が可能になります。 2/24(火) AWS WAF が AI アクティビティダッシュボードを発表、AI ボットとエージェントトラフィックの可視性を提供 AWS WAF が AI activity dashboard を発表し、AI ボットやエージェントのトラフィックを一元的に可視化できるようになりました。これまで見えなかった AI トラフィックのパターンや傾向を把握し、インフラコストの削減やアプリケーションパフォーマンスの改善が可能です。650 以上のユニークなボット検出に対応し、AI 検索クローラーやデータ収集ボットなどを識別してルール設定できます。 AWS AppConfig が New Relic と統合し、自動ロールバック機能を提供 AWS AppConfig が New Relic と連携し、フィーチャーフラグのデプロイ時に問題を自動検知してロールバックする機能を提供開始しました。従来は手動でロールバック作業が必要でしたが、エラー率上昇や遅延増加を検出すると数秒で自動的に前の状態に戻します。アプリケーションの段階的デプロイ中に障害が発生した場合の影響を最小限に抑えられるため、安全なリリース運用が実現できます。 AWS Observability が Kiro Powerとして利用可能に AWS が開発者向け AI ツール Kiro で AWS Observability power の提供を開始しました。CloudWatch や Application Signals などの観測機能を IDE 内で直接利用でき、アラーム対応や異常検知を AI エージェントが支援します。従来は複数のコンソールを行き来していたトラブルシューティングが、一つの環境で完結するため開発者の作業効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock が AgentCore Gateway によるサーバーサイドツール実行をサポート開始 Amazon Bedrock で AgentCore Gateway を使ったサーバーサイドツール実行機能が提供開始されました。これまでクライアント側で複雑なツールの実行管理が必要でしたが、今回のアップデートで Amazon Bedrock が自動でツールを発見し、モデルが選択したツールをサーバー側で実行してくれます。1 回の API 呼び出しで完結するため、アプリケーションの複雑さと遅延を大幅に削減できます。詳細は こちらのドキュメントをご参照ください。 2/25(水) Amazon WorkSpaces Applications が 4K 解像度のサポートを拡張 Amazon WorkSpaces Applications が 4K 解像度 (4096 x 2160) に対応しました。これまでは高解像度表示にはグラフィックス加速インスタンスが必要でしたが、今回のアップデートで通常のインスタンスでも 4K 表示が可能になりました。ウルトラワイドモニター (21:9) での作業や、高精細な画像・動画編集などで威力を発揮します。追加料金なしで利用でき、すべての接続モードに対応しています。詳細は こちらのドキュメントをご参照ください。 Amazon Location Service が AI パフォーマンス向上のため Kiro パワーおよび Claude Code プラグインとして LLM コンテキストを導入 Amazon Location Service で AI 開発支援コンテキストの提供が開始されました。Kiro や Claude Code などの AI ツールと組み合わせることで、地図機能の実装精度向上と開発時間短縮が可能になります。配送アプリの住所入力フォームや地図表示、最寄り店舗検索、ルート可視化といった位置情報を活用したアプリ開発が格段に効率化されます。詳細は こちらの GitHub リポジトリをご参照ください。 AWS Security Agent が AWS アカウント間での共有 VPC でのペネトレーションテストのサポートを追加 AWS Security Agent で、他の AWS アカウントから共有された VPC リソースに対してペネトレーションテストが実行できるようになりました。従来は各アカウント内でのテストに限定されていましたが、AWS Resource Access Manager (RAM) を活用することで、複数アカウントにまたがるセキュリティ評価が可能になります。例えば、サブアカウントの VPC リソースを中央アカウントに共有し、統合的にセキュリティテストを実施できます。詳細は こちらのドキュメントをご参照ください。 2/26(木) AWS Marketplace が SaaS およびプロフェッショナルサービス製品の複数購入をサポート AWS Marketplace で SaaS や Professional Services 製品の複数購入が可能になりました。以前は 1 つの AWS アカウントで同じ製品につき 1 つの契約しか結べませんでしたが、新しい Concurrent Agreements により複数の契約を同時に保持できます。これにより異なる部署が独立して調達したり、契約更新を待たずに拡張案件を進められるようになりました。Professional Services は自動有効で、SaaS は統合作業が必要です。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock が OpenAI 互換 Projects API を発表 Amazon Bedrock で OpenAI 互換の Projects API が利用可能になりました。この機能により、複数のアプリケーションやチーム、環境を管理する際に、プロジェクト単位で分離して管理できるようになります。各プロジェクトに異なる IAM アクセス制御を設定でき、タグ付けによるコスト可視化も実現します。従来は全体で一括管理していた AI アプリケーションを、組織やチーム別に整理して運用できるため、セキュリティとコスト管理が大幅に向上します。追加料金は不要で、モデル推論分のみ課金されます。詳細は こちらのドキュメントをご参照ください。 2/27(金) Amazon Bedrock バッチ推論が Converse API 形式をサポート Amazon Bedrock のバッチ推論で Converse API 形式がサポートされました。これまではモデルごとに異なるリクエスト形式が必要でしたが、今回のアップデートで統一された形式を使用できます。リアルタイム推論とバッチ推論で同じ Converse API 形式が利用でき、プロンプト管理が簡素化されモデル間の切り替えも容易になります。詳細は こちらのドキュメントをご参照ください。 Amazon Lightsail が新しい WordPress ブループリントでブループリント選択肢を拡張 Amazon Lightsail で新しい WordPress blueprint の提供が開始されました。数回のクリックで WordPress がプリインストールされた仮想プライベートサーバー (VPS) を作成でき、ガイド付きセットアップウィザードで数分でサイトを構築できます。カスタムドメインの接続、DNS 設定、静的 IP アドレスの割り当て、無料の Let’s Encrypt SSL/TLS 証明書による HTTPS 暗号化まで、すべて Lightsail コンソール内で完結します。WordPress サイトの立ち上げが格段に簡単になり、初心者でも本格的な Web サイトを素早く構築可能です。詳細は こちらのドキュメントをご参照ください。 今回のアップデートの中で、個人的に良いと感じたのは、AWS Marketplace が SaaS およびプロフェッショナルサービス製品の複数購入をサポートしはじめたところで、よりパートナーサービスが活発に使われるようになり、AWS を通じて世の中がよくなっていくような流れができそうだと思いました。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が実施する「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。お客様のニーズに合わせ、生成 AI による価値創出のため戦略策定に取り組む方向けの「戦略プランニングコース」、カスタムモデルによる課題解決に取り組む方向けの「モデルカスタマイズコース」、公開モデルによるビジネス課題解決を狙う方向けの「モデル活用コース」をご用意しております。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2026 年 2 月 17 日に開催されました。2024 年 11 月 の 第 1 回 、2025 年 2 月 の 第 2 回 、2025 年 4 月 の 第 3 回 、2025 年 8 月 の 第 4 回 、2025 年 11 月 の 第 5 回 に続き、今回が第 6 回となります。本記事では、イベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパン 事業開発統括本部 グロース事業開発本部長の塚本 陽子が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベントの冒頭では、AWS Japan サービス＆テクノロジー事業統括本部 AIソリューション部 部長の金杉 有見子がご挨拶をしました。 金杉 有見子はまず、AWS の生成 AI 活用支援の取り組みを紹介しました。直近では 2026 年 1 月末に「 フィジカル AI 開発支援プログラム 」を発表しており、募集開始から約 2 週間で数十社もの応募があったことを報告しました。 加えて、これまでの実績として「生成 AI 実用化推進プログラム」への参画企業は 2024 年の開始以来 270 社を超え、本イベントの参加者も延べ 1,000 人以上に達していると報告。コミュニティが着実に拡大している旨を共有しました。 続いて、2026 年の展望として「AI エージェント」と「フィジカル AI」の 2 つのキーワードを挙げました。 1 つ目の「AI エージェント」については、社内の情報検索やシステム運用、コーディング支援など、多岐にわたるユースケースで PoC（概念実証）から実運用への移行が進んでいる現状を説明。クラウド普及期がそうであったように、今後はレイテンシーやレジリエンス、セキュリティ、コストの最適化が重要な課題になってくると指摘しました。 2 つ目の「フィジカル AI」については、物理世界を認識して自律的にタスクを遂行する技術の重要性を語りました。Amazon では長年この領域に取り組んでおり、グローバルでの累計稼働台数が 100 万台に達しています。その 100 万台目が、日本のフルフィルメントセンターで稼働を開始した実績を紹介。労働力不足などの社会課題を解決しうる技術として、注目が集まっている分野であると述べました。 最後に金杉は「AI 技術の進歩は速いからこそ、その変化を楽しみながら業務変革に取り組んでいきたい」と語り、本イベントが「学び、楽しみ、つながる場」となることへの期待を込めてご挨拶を締めくくりました。 AWS セッション AWS セッションでは、PwC Japan コンサルティング合同会社 TDC-DAX所属 Director の木村 俊介氏（写真右）と、AWS ジャパン 生成 AI 推進マネージャーの梶原 貴志（写真左）によるディスカッションが行われました。 セッション序盤で議論の中心となったのは、PwC 社が経年で実施している「生成 AI 実態調査」に基づく分析です。2023 年春の時点では、生成 AI を「検討・推進中」とする日本企業は約 20% でしたが、2025 年には約 56% が「活用中」と回答するまでに普及しました。 続いて、日本、米国、中国、ドイツ、英国の 5 カ国比較調査の結果が示されました。日本は他国と比較し、「効果を創出できた企業の割合」で大きく遅れをとっている現実が浮き彫りになりました。 その要因として木村氏が強調したのが、トップダウンによる推進体制の欠如、特に CAIO（Chief AI Officer）の不在です。生成 AI の深い知見を持ち、全社的な推進を担うリーダーの存在が、成功の鍵であると語られました。また、他国の技術に依存しない「AI 自給率」を高めることが、今後の日本の競争力を高めるうえで重要であるという提言もなされました。 セッション終盤では、生成 AI の課題であるハルシネーションへの向き合い方について議論が交わされました。木村氏は、一意な正解が求められる「決定論的な処理」には不向きである一方、文章要約やシミュレーションといった「確率論的な処理」には極めて有効であるとし、業務への適性を見極めることが重要だと説きました。 最後に梶原は、AWS の「生成 AI 実用化推進プログラム」が、技術面だけでなく組織変革や人材育成も支援可能であることをアピール。木村氏は「AI の進歩の波は止められない。業務を楽にするパートナーとして、AI とうまく付き合っていくべき」と参加者にメッセージを送り、セッションを締めくくりました。 プログラム参加者によるライトニングトーク ここからは、生成 AI 実用化推進プログラムに参加する各社の代表者が登壇し、「カスタマー事例 モデル開発」「カスタマー事例 モデル利用」「モデル開発者紹介」の 3 部構成で取り組みを紹介しました。AWS ジャパン シニア フロンティア AI スタートアップ ソリューションアーキテクトの針原 佳貴（写真左）と、AI/ML Specialist SA の飯塚 将太（写真右）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社みずほフィナンシャルグループ デジタル戦略部 デジタル・AI推進室 テクノロジー開発チームヴァイスプレジデントの皆川 拓 氏は、同社が開発する LLM について紹介しました。「金融業界特有の知見や専門用語」「規制・法令」「行内の内部データ」を学習させ、高度な業務判断を可能にしています。新入行員が受験する実務テストを用いた評価では、最新の汎用モデルと同等の正答率を達成しました。今後は、パラメータサイズの拡大や強化学習などに取り組み、実業務で価値を発揮するエキスパートモデルの構築を目指しています。 ライオン株式会社 デジタル戦略部 DX推進チームの百合 祐樹 氏は、創業130年の歴史の中で蓄積してきた研究開発のナレッジを継承・活用するための自社特化型 LLM 開発の事例を紹介しました。従来の RAG だけでは網羅的な情報検索や文脈理解に限界があったため、Qwen 2.5-7B をベースとした独自モデルを構築。今後は非構造化データのクレンジング・加工による学習データ拡充や Post-Training の実施、ナレッジ検索アプリや AI エージェントへの活用などを進めていく方針です。 株式会社電通デジタル ディレクター 鈴木 初実氏は、AI エージェント型 IDE「 Kiro 」によるデモ開発プロジェクトの事例を紹介しました。タイトなスケジュールの中、「Kiro」を駆使して通常の 10 倍以上の速度での開発に成功。鈴木氏は、AI に指示を出す際は「文脈を徹底的に伝えること」「わからないことは指示せず、AI に聞くこと」「まずは動くものを作り、細かく改善を繰り返すこと」が重要であるとし、非エンジニアであっても適切なツールと対話手法を用いれば、大幅な効率化が可能であると語りました。 日本経済新聞社 技術戦略ユニット 大塚 恭平 氏と田邉 耕太 氏（写真は大塚 氏）は、組織全体のシステム開発・運用を効率化するための社内向けプラットフォームについて発表しました。本プラットフォームは、社内ドキュメントに基づき回答するチャットボット機能や開発・運用業務を自動化するワークフロー実行機能を提供しています。アーキテクチャとしては、 Amazon Bedrock AgentCore Runtime 上に MCP サーバーを配置し、Strands Agents を利用して AI エージェントをデプロイしています。 Sky株式会社 IT統括本部 Skyスタイル部 AI Innovation Lab 課長代理 神崎 真行 氏は、全社員が毎日提出する膨大な「日報」を AI エージェントで分析し、組織のリスク検知に活用した事例を紹介しました。導入にあたっては、役職や部署による閲覧権限の制御が課題でしたが、 Amazon Redshift の行レベルセキュリティを活用することで、AI 経由でのアクセスでも厳格な権限管理を実現。導入後、マネージャーの日報確認時間は 4 分の 1 に短縮され、メンバーの SOS 早期発見や 1on1 の質の向上など、組織運営において具体的な成果を上げています。 株式会社アクト・ノード 代表取締役 百津 正樹 氏は、人手不足が深刻な農業現場を支援するエージェント AI を紹介しました。農業生産者がチャットで「鶏が暑がっていないか見てほしい」といったリクエストを送ると、AI がカメラ映像を定期的に監視し、異常があれば通知します。百津氏は、AI を「生産者の能力を拡張するアイアンマンスーツ」のように機能させ、日本の一次産業を支えていきたいと展望を語りました。 開発者モデルご紹介 ここからは、基盤モデルを開発する各社の代表者が登壇しました。 ONESTRUCTION株式会社 AI Lead 日高 洸陽 氏は、建設業界の課題解決に向けた同社の取り組みと、自社開発の基盤モデルについて発表しました。同社の AI チームは「3 次元設計を AI によって自動化すること」を目指し、研究開発を続けています。約 30 億パラメーターという小型モデルでありながら、特定のタスクにおいてフロンティアモデルを凌ぐ性能を達成。今後はフィジカル AI や建設ロボットなどへの応用も見据えています。 Airion株式会社 CTO 大熊 拓海 氏は、製造業の Factory Automation 領域における「ラダープログラム生成用大規模言語モデル」の研究開発について紹介しました。工場の制御機器で使われるラダー言語は学習データが少なく、既存の汎用 LLM では実用的なコード生成が困難でしたが、同社は提携企業から提供された大量のデータを基に継続事前学習を実施。その結果、コンパイル成功率や評価スコアにおいてフロンティアモデルの 2 倍以上の性能を記録しました。 登壇者の皆様 クロージング クロージングの前半では、経済産業省 商務情報政策局 情報産業課 AI産業戦略室 総括補佐 秋元 裕太 氏が、同省が推進する GENIAC の最新動向について講演しました。 従来からの「領域特化モデルの研究開発」支援に加え、新たに「ロボット基盤モデルの研究開発」枠を設けるとし、自動運転車やドローン・無人航空機等の開発に必要な計算資源やハードウェア調達を支援することを発表しました。また、データ活用に関する支援として、「製造業データ等の AI-Ready 化に関する研究開発」と「データエコシステムの構築等に関する研究開発」を展開し、現場データを AI 開発に活かすための後押しをすると説明しました。 加えて、懸賞金活用型プログラム「GENIAC-PRIZE」の次期計画についても触れられました。R8 年度では、「個別産業の社会課題解決に資するAIエージェント開発」「開発者育成（学生）のための公開型の基盤モデル開発」をテーマに設定する予定であるとし、積極的な参加を呼びかけました。公募開始は 2026 年 5 月を予定しています。 クロージングの後半では、AWS ジャパン 事業開発統括本部 生成 AI 推進マネージャーの梶原 貴志が、次回の「生成 AI Frontier Meetup」は 2026 年 5 月 28 日に開催予定であると言及。加えて、近日開催予定の生成 AI 関連のイベントもご案内しました。 Amazon Quick Suite で変わる業務の現場 ～活用企業・AWS社員による事例紹介～ 企業のデジタル変革を推進するリーダー層および実務担当者の皆様に、 Amazon Quick Suite の統合 AI 機能を通じた業務効率化とデータに基づく意思決定の実現方法をご紹介。日時：2026 年 3 月 26 日（木）14:00～18:30 開催方式：ハイブリッド / 目黒セントラルスクエア 21F GENIAC 基盤モデル開発者向け Deep Dive セッション Amazon SageMaker HyperPod 等を活用した、スケーラビリティと堅牢性を備えたモデル学習環境構築についての学習 Amazon SageMaker HyperPod の利用経験があるパートナーによる活用事例紹介 Slurm・Kubernetes を活用した機械学習に関するベストプラクティスとナレッジの学習 AWS 独自チップ（ AWS Trainium 、 AWS Inferentia ）の活用シーンとベネフィットの学習 日時：2026 年 4 月 9 日（木）10:00～18:00 開催方式：対面 / 目黒セントラルスクエア 21F [Online] AWS サポート直伝！ Kiro CLI 実践ワークショップ AWS サポートの現役エンジニアによる、実践的な Kiro CLI トラブルシューティングハンズオン。生成AIを用いてAWSの運用を効率的に行いたいインフラエンジニア、Kiro の具体的な活用方法を知りたいエンジニア、開発者、デジタル変革・DX推進に携わる方に。 日時：2026 年 4 月 15 日（水）15:00～18:00 開催方式：オンライン 参加者交流会の様子 交流会では、各セッションで共有された事例を起点に、登壇者と参加者が自由に意見を交わす様子が目立ちました。AI エージェントの実運用における課題や、自社モデル開発の工夫など、各種のテーマをめぐって熱心な議論が行われました。業種や役割を超えたネットワーキングも進み、新たな連携や共創の芽が育まれる場となりました。 会場内には、全般的な質問に応じる「よろず相談」、技術的な相談に応じる「Ask an Expert」コーナーも設けられ、ご参加のお客様の質問に回答いたしました。 会場内には、技術的な相談に応じる「Ask an Expert」コーナーや、各種の疑問を気軽に相談できる「よろず相談」コーナーも設けられ、参加者の方々の質問に回答いたしました。 おわりに 第 6 回を迎えた本イベントでは、AI エージェントやフィジカル AI といった最新トレンドの解説に加え、多様な業界の実践事例が共有され、生成 AI の活用が着実に広がっていることを実感できる場となりました。AWS ジャパンは、今後も業界横断での交流や技術支援を通じて企業の生成 AI 活用を後押しし、その実用化と発展に貢献してまいります。

本記事は 2026 年 2 月 23 日に公開された “ Resilience testing on Amazon ElastiCache with AWS Fault Injection Service ” を翻訳したものです。 Amazon ElastiCache は、Valkey、Memcached、Redis OSS をサポートするフルマネージドのインメモリキャッシングサービスで、99.99% の可用性を提供しながら、コスト効率の良い価格でアプリケーションのパフォーマンスをリアルタイムに向上させます。 頻繁にアクセスされるデータに対してサブミリ秒のレスポンスタイムを提供するため、データベースクエリのキャッシング、Web セッション状態の管理、ゲームのリアルタイムリーダーボードの実現などに広く使用されています。 多くのアプリケーションは、キャッシュが常に利用可能であることを前提に構築されています。 耐障害性テストを行わないと、Amazon ElastiCache へのアクセスが失われた際にアプリケーションで問題が発生することがよくあります。 アプリケーションがデータベースへ適切にフォールバックせずにクラッシュすることに気づくかもしれませんが、それは本番環境でのインシデント発生時、つまり手遅れになってからのことです。 そのため、キャッシュが利用できなくなるイベントに備えて構築し、アプリケーションが期待どおりにそれらの障害ケースを処理することをテストする必要があります。 この投稿では、 AWS Fault Injection Service (AWS FIS) を使用して Amazon ElastiCache で耐障害性テストを実行する方法と、アプリケーションの耐障害戦略を強化するためにAWS FISをどのように活用できるかをご紹介します。 ソリューションの概要 このソリューションでは、AWS FIS を使用しています。 これは、AWS ワークロードに対して制御された障害注入実験を実施するためのフルマネージドな耐障害性テストサービスです。 メンテナンスや特権を必要とするカスタムスクリプトやサードパーティツールに頼る代わりに、AWS FIS はシステムの耐障害性をテストするための安全でスケーラブル、かつ高可用性のプラットフォームを提供します。 AWS FIS は、システムにストレスがかかった際の応答を観察するために、意図的に障害を発生させるという手法に基づいて動作します。 これらの実験により、弱点を特定し、システムの動作に関する仮定を検証し、実際の障害に耐えるアプリケーションの能力に対する信頼を高めることができます。 AWS FIS を使用すると、テスト環境または本番環境で耐障害性テストを実施できます。 例えば、ピークトラフィック時の Amazon ElastiCache ノード障害のような現実的なシナリオをテストし、最も重要な場面でフェイルオーバーの仕組みが機能することを確認できます。 この記事では、耐障害性テスト用の ElastiCache クラスターのセットアップ方法、AWS FIS 実験テンプレートの作成方法、制御されたフェイルオーバーテストの実行方法、および結果のモニタリングと解釈方法について説明します。 前提条件 このソリューションを実装する前に、以下を確認してください： アクティブな AWS アカウント テスト用の非本番環境 Amazon ElastiCache サービスの基本的な理解 このソリューションでは、新しい AWS リソースの作成と利用が必要です。 そのため、アカウントに費用が発生します。 詳細については、 AWS Pricing を参照してください。 本番環境に実装する前に、非本番環境でセットアップし、エンドツーエンドの検証を実行することを強くお勧めします。 方法論 この実験では、Amazon ElastiCache が自動フェイルオーバーを使用してノード障害時に高可用性を維持する方法を示します。 Multi-AZ が有効でクラスターモードが無効な Amazon ElastiCache for Valkey クラスターでノード障害を発生させ、アプリケーションが手動介入なしで復旧できることを確認します。 フェイルオーバー中は、以下のアクションが実行されます。 障害検出 : ElastiCache がプライマリノードの障害を検出します。 レプリカの昇格 : レプリケーションラグが最も小さいレプリカがプライマリに昇格します。 DNS 更新 : プライマリエンドポイントが自動的に新しいプライマリを指すようになるため、アプリケーションは同じ接続文字列を引き続き使用できます。 ノードの復旧 : 障害が発生したノードは、復旧後にリードレプリカとして再参加します。 クラスターモード無効の構成を使用しているのは、フェイルオーバープロセスをコンソールで観察しやすくするためです。個々のノードの役割がプライマリからレプリカに変わる様子を明確に確認できます。 ただし、これらのテスト原則はクラスターモード有効のデプロイメントにも適用されます。クラスターモード有効の場合、設定エンドポイントがすべてのシャード間のルーティングを自動的に管理します。 この実験は実は ElastiCache Serverless では意味がありません。ElastiCache Serverless はマネージドプロキシの背後で Multi-AZ フェイルオーバーを処理するため、アプリケーションは中断の影響を受けません。 ElastiCache Serverless の仕組みについては、 ドキュメント を参照してください。 耐障害性の高いアプリケーションでは、接続の中断は短時間にとどまり、自動的に再接続し、データベースに過負荷をかけることなく一時的にフォールバックできる必要があります。 ウォークスルー Valkey クラスターの作成 既存の Amazon ElastiCache for Valkey クラスターモード無効クラスターを使用するか、 Valkey (クラスターモードが無効) クラスターの作成 (コンソール) の手順に従って新しいクラスターを起動できます。 このテストでは、Amazon ElastiCache の汎用バースト可能な T4g または T3-Standard microキャッシュノードを使用することで、コストを抑えることができます。 次のスクリーンショットは、プライマリノードと 3 つのレプリカノードを持つクラスターを示しています： また、クラスターにキー名と値を持つタグを作成します。 以下のスクリーンショットでは、キーを fis-testing 、値を yes としています。 このタグは、AWS FIS 実験テンプレートでターゲットの詳細を編集する際に使用します。 AWS FIS テンプレートのセットアップ Amazon ElastiCache クラスターの準備が整い利用可能になったら、以下のような AWS FIS テンプレートを作成します。このテンプレートでは、注入する障害の種類と対象となるリソースを定義します。 AWS FIS を使用するには、AWS リソースで実験を実行して、障害条件下でアプリケーションやシステムがどのように動作するかという仮説をテストします。 実験を実行するには、まず実験テンプレートを作成します。 テンプレートの詳細については、 ドキュメント を参照してください。 AWS FIS コンソールを開きます。 ナビゲーションペインで、 Experiment templates を選択します。 Create experiment template を選択します。 最初のステップ Specify template details で、テンプレートの詳細に関連する説明と名前を入力し、 Account targeting はこのアカウントのままにしておきます。 Next を選択します。Actions と Targets コンポーネントを設定する前に、それらの用途を理解しておく必要があります。 アクションは、ターゲットに対して実行される障害注入アクティビティです。 AWS FIS は、さまざまな AWS サービス向けのアクションを提供しています。 実験テンプレートにアクションを追加すると、AWS FIS はそれを使用して実験を実行します。 ターゲットは、実験中に AWS FIS がアクションを実行する AWS リソースです。 実験テンプレートを作成するときにターゲットを定義し、複数のアクションで使用できます。 AWS FIS は、アクションを開始する前にターゲットを特定し、実験全体を通じてそれらを使用します。 Add Action を選択します。 Action Type で、 aws:elasticache:replicationgroup-interrupt-az-power を選択して、Multi-AZ が有効になっているターゲット ElastiCache レプリケーショングループの指定されたアベイラビリティーゾーン内のノードへの電源を中断します。レプリケーショングループごとに一度に影響を受けるアベイラビリティーゾーンは 1 つだけです。 プライマリノードがターゲットになると、レプリケーションラグが最も少ない対応するリードレプリカがプライマリに昇格します。 指定されたアベイラビリティーゾーン内のリードレプリカの置き換えは、このアクションの期間中ブロックされます。 つまり、ターゲットのレプリケーショングループは容量が減少した状態で動作します。 詳細については、 ドキュメント を参照してください。 必要に応じて関連する Name を入力します。 Target には、 Targets セクションで定義したターゲットを選択します。 このアクションのターゲットをまだ定義していない場合、AWS FIS が新しいターゲットを作成します。 Action parameters で、アクションのパラメータを指定します。 テスト要件に応じて duration を設定してください。 これは、ターゲットノードで障害アクションが継続する時間の長さです。 Save を選択します。 アクションを保存すると、次のスクリーンショットに示すようにターゲットが自動的に作成されます。 aws:elasticache:replicationgroup を選択して Edit Target ページを開きます。 Target method では、 Resource tags, filters and parameters ラジオボタンがすでに選択されています。 Amazon ElastiCache をターゲットにするには、 resourceTags 要素でタグのみを指定できます。 Add new tag ボタンを選択してリソースタグを追加します。 ここでは、キーを fis-testing 、値を yes として使用しています。 Availability Zone identifier ドロップダウンで、このテストで障害を発生させたいノードのアベイラビリティーゾーンを選択する必要があります。 プライマリノードを含むアベイラビリティーゾーンを選択すると、その AZ が影響を受けたときにフェイルオーバーがトリガーされます。 Selection mode では、識別されたすべてのターゲットで実行するデフォルトオプションの ALL を選択します。 Save を選択します。 Next を選択します。 Service access セクションで、デフォルトの選択である Create a new role for the experiment template のままにします。 コンソールに表示されているサービスロール名をコピーしてください。後で使用します。 このステップが完了すると、コンソールに表示されている名前で IAM ロールが作成されます。 Next を選択します。 Send to CloudWatch Logs チェックボックスを選択します。 ロギングは、実験のタイミングとアプリケーションの動作を関連付けるのに役立つため、Amazon CloudWatch 統合を設定しましょう。 そのためには、まず CloudWatch にロググループを作成する必要があります。 ロググループを作成するには、 CloudWatch ドキュメント の手順に従ってください。 テンプレート作成の AWS FIS タブで、Logs セクションの Browse オプションを選択し、右側の Refresh ボタンを使用します。 作成したロググループ名を検索します。 Log version として Version 2 を選択します。 次のスクリーンショットでは、ロググループ名として aws-fis-elasticache を使用しています。 View Permission details ボタンを選択し、Amazon CloudWatch ロギングに必要な権限ポリシーをコピーしてメモ帳に貼り付けます。 後のセクションで、ステップ 19 で作成されたロールを更新するために使用します。 Next を選択します。 テンプレートを確認し、 Create experiment template を選択します。 Amazon CloudWatch 用の AWS IAM ロールの編集 テンプレートが作成されたら、CloudWatch ロギングに必要な権限を持つように、作成した IAM ロールを編集する必要があります。 IAM コンソールを開き、IAM ロールを選択すると、このロールに 2 つのポリシーがアタッチされていることがわかります。 FIS-Console-CWLogging-XXXX という名前で作成されたポリシーを編集し、前述のポリシー JSON ドキュメントをコピーして、ポリシーを保存します。 AWS FIS 実験の実行 AWS FIS コンソールページで、ステップ 2 で作成したテンプレートの右上にある Start experiment を選択し、開始操作を続行します。 モニタリングとログの確認 実験の状態が Running 状態になることを確認できます。 CloudWatch ログの送信先リンクを選択して、先ほど作成したロググループ aws-fis-elasticache の CloudWatch ログを開きます。 ログイベントには、 log_type:action-start のログエントリが 1 つ表示されます。 これは、実験が実際にアクションを実行している、または有効になっている時刻を示しています。 Amazon ElastiCache コンソールに移動すると、クラスターのステータスとノードが以下のように Modifying 状態になっていることが確認できます: また、ノード elasticache-chaos-test-cluster-001 のロールが primary から replica に変更されていることにも気づくでしょう。 これは、以下に示すように Amazon ElastiCache で公開されたイベントからも確認できます: フェイルオーバーは、ロググループ aws-fis-elasticache の AWS FIS ログによると、アクション開始時刻から数秒以内に完了しました。 Amazon ElastiCache クラスターのログを有効にしている場合、他のノードがプライマリノードとの接続の問題を示すログも確認できます。 5 分間 (テンプレートの Action ページのデフォルト設定) が経過すると、AWS FIS ログに log_type:action-end が表示されます: Amazon ElastiCache コンソールでは、ノードとクラスターのステータスが Available と表示されます。 耐障害性の検証: 確認すべきポイントと対応方法 耐障害性テストの実行は最初のステップに過ぎません。 本当の価値は、フェイルオーバー中に何が起こったかを理解し、アプリケーションがそれを適切に処理できることを確認することにあります。 ElastiCache イベントの理解 ElastiCache イベントは、フェイルオーバー中のクラスターの健全性を可視化します。 確認すべき主要なイベントは以下の通りです: Recovering cache nodes は、影響を受けたノードが復元中であることを示します Finished recovery for cache nodes は、元のノードがレプリカとしてクラスターに再参加したことを確認します フェイルオーバープロセス全体は、Multi-AZ 構成の場合、通常数秒以内に完了します クラスターログの分析 ElastiCache クラスターでエンジンログを有効にしている場合、フェイルオーバー中の詳細な接続動作を確認できます: レプリカがプライマリノードの障害を検出した正確なタイミング 「Connecting to MASTER」や「Replica has started synchronizing with the primary」などのメッセージは、リカバリプロセスを示しています 同期成功のメッセージは、データの一貫性が維持されたことを確認しています アプリケーションの耐障害性テスト ElastiCache はフェイルオーバーを自動的に処理しますが、この期間中のアプリケーションの動作が重要です。 接続処理: 適切に設計されたアプリケーションでは、短時間の接続エラー (5 〜 15 秒) の後に自動的に再接続されるはずです。より長い停止時間は、接続プールの設定やリトライロジックに問題があることを示しています。 キャッシュミス時の動作: アプリケーションがデータベースに過負荷をかけることなく、適切にフォールバックすることを確認してください。データベースのクエリレートは一時的に増加しますが、管理可能な範囲に収まるべきです。 パフォーマンスの低下: フェイルオーバーの前、最中、後のレスポンスタイムを測定してください。耐障害性のあるアプリケーションでは、フェイルオーバー中にレイテンシーが 50ms から 200ms に増加し、その後正常に戻ることがあります。1 秒を超えるスパイクが発生した場合は、接続タイムアウトとリトライの設定を調査する必要があります。 Amazon ElastiCache でのアプリケーション動作の監視の詳細については、 Monitoring best practices with Amazon ElastiCache for Redis using Amazon CloudWatch を参照してください。 まとめ この記事では、AWS Fault Injection Service (AWS FIS) を使用して Amazon ElastiCache で耐障害性テストを実装する方法を学びました。 このテストにより、キャッシュ戦略の弱点を事前に特定し、フェイルオーバーメカニズムを検証し、実際のインシデントが発生する前に適切な縮退動作を確保できます。 これらの実験を実行することで、チームはインシデント対応手順を練習し、キャッシュ障害がシステムアーキテクチャ全体に与える連鎖的な影響を理解できるようになります。 Amazon ElastiCache 全般のベストプラクティスについては、 ElastiCache のベストプラクティスとキャッシュ戦略 を参照してください。 クリーンアップ このウォークスルーのために新しい Amazon ElastiCache クラスターを作成した場合は、 ElastiCache でのクラスターの削除 ドキュメントの手順に従ってクラスターを終了し、コストを最適化できます。 また、 実験テンプレートを削除する ドキュメントの手順に従って AWS FIS 実験テンプレートを削除することもできます。 IAM ロールの削除と CloudWatch ロググループの削除については、それぞれ IAM ロールの削除 (コンソール) と CloudWatch Logs の削除 のドキュメントを参照してください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Raunak Gupta Raunak は AWS のシニアデータベースソリューションアーキテクトです。AWS に 6 年以上在籍しており、Aurora と RDS オープンソースの専門家でもあります。17 年以上の実務経験を持ち、エンタープライズのお客様にデータベースの運用パフォーマンスとデータベースのベストプラクティスに関する技術支援を提供しています。

本記事は 2026 年 2 月 26 日 に公開された「 Optimize data management on S3 Tables with Intelligent-Tiering 」を翻訳したものです。 多くの組織が、ペタバイト規模の成長とパフォーマンスに対応でき、コストのかかるリライトなしにスキーマやパーティションを柔軟に変更できる Apache Iceberg をデータレイクに採用しています。タイムトラベルやインクリメンタル処理といった機能により、最新のデータレイク管理が可能になります。しかし、データが増大するにつれ、Iceberg データセットの効率的な管理は難しくなります。規制要件や長期的な分析ニーズから数か月〜数年にわたりデータを保持する組織も多く、パフォーマンスやアクセス性とコストのバランスに苦慮しています。テーブルのメンテナンス、ファイルレイアウトの最適化、コスト効率の高いリテンションポリシー（維持期間）の実装は、継続的にリソースを消費し、コスト増加につながります。 Amazon S3 Tables は、Iceberg テーブル向けに設計されたテーブルストレージと新しいバケットタイプを導入し、 Amazon S3 に構造化データを簡単に保存できるようにしました。S3 Tables はコンパクション、スナップショット管理、参照されていないファイルの削除といったメンテナンスタスクを自動的に処理します。さらに、 Intelligent-Tiering ストレージクラス のサポートが追加されました。アクセスパターンに基づいてデータをストレージ階層間で自動的に移動し、ストレージコストを最適化します。データレイクの規模が拡大しデータが古くなっても、パフォーマンスに影響を与えることなくコスト効率を継続的に最適化できます。 本記事では、Intelligent-Tiering をコンパクションやスナップショット管理などの メンテナンス機能 と組み合わせて、長期的な総所有コスト (TCO) を削減する方法を詳しく解説します。 S3 Tables でのデータ管理の最適化 S3 Tables にデータが到着した時点では、最適な状態ではない場合があります。たとえば、分析効率よりも取り込みスループットや柔軟性を優先してデータが取り込まれることがあります。ストリーミング更新で頻繁にテーブルへの変更がコミットされ小さなファイルが生成されるケースや、merge-on-read パターンでテーブル更新時にインクリメンタルな差分ファイル/deleteファイルが追加されるケースが典型的です。このような場合、クエリパフォーマンスの向上と長期的なストレージの最適化にメンテナンス操作が必要になります。S3 Tables は長期的なデータ最適化のために以下の手法をサポートしています。 スナップショット管理 – 必要な履歴データのみを保持し、冗長な情報を体系的に廃止・削除して、参照されていないファイルを完全に除去します コンパクション (Binpack、Sort、Z-order) – 小さなファイルを統合してより大きく効率的なファイルを作成します。Sort や Z-order を使ってデータを並べ替え、より高速でコスト効率の高いクエリを実現したり、delete ファイルをデータファイルにマージしたりできます ストレージ階層の最適化 – Intelligent-Tiering ストレージクラスを活用し、規制やビジネスニーズによる長期データ保持のストレージコストを削減します S3 Tables のスナップショット管理 Iceberg のスナップショットは、テーブルの完全な状態を記録した不変のポイントインタイムレコードです。既存のコンテンツを変更せずに、すべてのデータファイルとメタデータをキャプチャします。タイムトラベルクエリ、同時操作中の一貫した読み取り、運用復旧やリストアのための以前のテーブルバージョンへのロールバックといった機能を実現します。 S3 Tables は、リテンションポリシーの設定やライフサイクル管理の自動化のための コンソールコントロールと API 操作 でスナップショット管理を効率化します。 S3 Tables は、履歴データのニーズとストレージ最適化のバランスをとるための調整可能な有効期限ルールを提供し、ガバナンス要件に対応するスナップショットメトリクスと監査証跡も備えています。保持するスナップショットの最小数、スナップショットの最大保持期間、参照されていないファイルの削除などのプロパティが含まれます。スナップショット管理の詳細は こちらの動画 で解説しています。 nonCurrentDays 、 unreferencedDays 、 maximumSnapshotAge 、 minimumSnapshots などのチューニングパラメータについては、 考慮事項と制限 を慎重に評価することをお勧めします。リテンション要件に合わせて適切に値を調整してください。 S3 Tables のコンパクション Apache Iceberg のコンパクションは、複数の戦略でテーブルパフォーマンスを最適化します。小さなファイルを大きなファイルに統合してメタデータの負荷と I/O リクエスト料金を削減し、delete ファイルをマージし、ソート順でデータをリライトしてパーティション述語を高速化し、多次元クラスタリングで関連データを近接配置して複数カラムでのスキャン効率を向上させます。Amazon S3 Tables は適切なポリシーでコンパクションを自動化し、テーブルのファイルレイアウトを継続的に最適化し、クエリパフォーマンスの向上とコスト削減を実現します。コンパクションのスケジューリング、リソース割り当て、実行を自動的に処理するため、運用負荷がなくなります。S3 Tables は以下のコンパクション手法をサポートしています。 Binpack コンパクション – 多数の小さなデータファイルを少数の最適なサイズのファイルに統合し、メタデータの負荷を削減して、分散処理フレームワークでクエリパフォーマンスを低下させる「スモールファイル問題」を最小化します Sort コンパクション – 1 つ以上の指定カラムに従ってレコードを物理的に並べ替えるようにデータファイルをリライトし、メタデータベースのフィルタリングによる効率的なデータスキッピングを可能にして、ソートカラムに一致する述語でのクエリパフォーマンスを大幅に向上させます Z-order コンパクション – 空間充填曲線(space-filling curve)アルゴリズムで多次元データを 1 次元空間にマッピングし、複数カラムにわたって類似するレコードを近接配置して、Z-order 対象次元の任意のサブセットに対する述語を持つクエリを最適化します Auto (デフォルト) – Amazon S3 Tables がテーブルのソート順に基づいて最適なコンパクション戦略を選択します。すべてのテーブルのデフォルトのコンパクション戦略です。メタデータにソート順が定義されているテーブルには Sort コンパクションが自動的に適用されます。ソート順が定義されていないテーブルには Binpack コンパクションがデフォルトで使用されます 詳細は S3 Tables メンテナンスドキュメント と、AWS での Apache Iceberg 利用に関する規範的ガイダンスの コンパクションセクション をご覧ください。 適切なコンパクションの実施は、持続可能なデータレイク管理に不可欠です。最適化されていないテーブルは、時間の経過とともにパフォーマンスが低下しコストが増加します。定期的なコンパクションにより、小さなファイルの蓄積を防ぎ、最適なデータ構成を維持し、テーブルがペタバイト規模に成長してもクエリ効率を確保できます。パフォーマンス面の直接的なメリットに加え、適切に実行されたコンパクションは圧縮率とファイルレイアウトの改善によりストレージ効率を向上させます。より安定したクエリパフォーマンス、予測可能なコスト、そしてリアクティブなテーブルメンテナンスではなく価値を生み出す活動にエンジニアリングリソースを集中できるようになります。 S3 Tables の Intelligent-Tiering 前述のスナップショットとコンパクション機能に加え、S3 Tables は re:Invent 2025 で S3 Intelligent-Tiering によるストレージ最適化を提供開始しました。このストレージクラスは、アクセスパターンの変化に基づいてコスト効率の高いアクセス階層間でデータを自動的に移動します。データ取得にかかる費用、パフォーマンスへの影響、可用性の変化はありません。 S3 Intelligent-Tiering は個々のデータファイルレベルで動作するため、1 つのテーブル内のファイルが異なる階層に同時に存在できます。データは以下の 3 つのアクセス階層で自動的に管理されます。 高頻度アクセス (FA) – すべてのファイルのデフォルト階層。他の階層のファイルもアクセスされるとここに戻ります 低頻度アクセス (IA) – 30 日間連続してアクセスがないファイルがここに移動します アーカイブインスタントアクセス (AIA) – 90 日間連続してアクセスがないファイルがここに移動します すべての階層でミリ秒レイテンシー、高スループットパフォーマンス、99.9% の可用性、99.999999999% の耐久性が維持されます。オブジェクトは Get API 呼び出しでアクセスされると高頻度アクセス (FA) 階層に遷移します。テーブル内のデータファイルが読み取られるたびに、読み取りをトリガーした操作に関係なく発生します。データファイルの読み取り (FA 階層への遷移) をトリガーする操作は以下のとおりです。 テーブルへの直接アクセス – データファイルを読み取るクエリやスキャン テーブル管理操作 – 既存のデータファイルの読み取りを必要とする LoadTable や UpdateTable などの REST API 呼び出し レプリケーション – テーブルがレプリケートされる際、コンテンツを転送先に転送するためにソースデータファイルを読み取る必要があり、IA/AIA 階層のファイルに対して Get 呼び出しがトリガーされます 重要なポイントとして、階層の遷移はデータファイルが読み取られたときにファイルレベルで発生し、テーブルが参照されたときではありません。基盤となる S3 オブジェクトの読み取りを伴う操作はすべて、オブジェクトを IA/AIA から FA 階層に移動させます。なお、128 KB 未満のファイルは高頻度アクセス階層に留まりますが、コンパクションでより大きなファイルに統合されると階層移動の対象になります。 S3 Tables の Intelligent-Tiering とメンテナンスタスクの連携 スナップショット管理やファイルクリーンアップなどのテーブルメンテナンス操作は、すべての階層で引き続き実行されます。コンパクションについては、S3 Tables は独自のアプローチをとります。コンパクションタスクの開始時に、コンパクションの種類 (Binpack、Sort、Z-order) に関係なく、S3 Tables はコンパクション候補のデータファイルの階層を確認します。この確認自体は階層の変更に影響しません。S3 Tables は FA 階層にあるファイルのみにコンパクションを実行し、30 日以上アクセスしていないデータやファイルが昇格されないようにします。FA 階層のファイルのみを対象とすることで、頻繁にアクセスされるデータのパフォーマンスを最適化しつつ、コールドデータのメンテナンスコストを削減できます。低い階層のデータファイルがアクセスされると FA 階層に戻り、コンパクションの対象になります。 コンパクションは高頻度アクセス階層のファイルのみを処理するため、低コスト階層のデータに対する削除操作では、自動的にコンパクションされない delete ファイルが生成されます。関連するデータファイルがアクセスされて高頻度アクセス階層に戻ると、delete ファイルもコンパクションの対象になります。この動作の詳細は ドキュメント をご覧ください。 以下に、この動作を示す 2 つの例を紹介します。 Binpack コンパクションの例 シンプルな Binpack コンパクションのプロセスを見てみましょう。あるお客様が、当初有効にしていなかったコンパクションを有効にすることにしました。パーティション内の一部のデータファイルは頻繁にアクセスされていましたが、一部はアクセスされておらず、30 日後に自動的に IA 階層に遷移しています。 S3 Tables のコンパクションエンジンが起動すると、コンパクション候補のデータファイルの階層を検証します。FA 階層にあるデータファイルのみにコンパクションを実行し、アクセスされていないファイルはそのまま残します。IA や AIA 階層のファイルを確認しても、階層ステータスには影響しません。結果として、頻繁にアクセスされたデータはより効率的なファイルになり、アクセスされていないファイルのコスト削減は維持されます。2 週間後、残りの 2 つのファイルのデータにクエリがアクセスし、FA 階層に戻りました。 すべてのファイルが FA 階層にある状態で、次のコンパクションエンジンのイテレーションでは、S3 Tables のコンパクションエンジンが追加のコンパクションを実行し、2 つの小さなファイルを大きなファイルにマージします。 Delete ファイルの例 Apache Iceberg の equality delete、positional delete、 deletion vector (v3) などの delete ファイルタイプは、個別の delete 参照ファイルを生成します。これらのファイルは merge-on-read で使用されるか、メンテナンス操作中にデータファイルにマージされます。ここでは equality delete を使って、コンパクションエンジンと S3 Tables Intelligent-Tiering の連携を説明し、delete ファイル管理とデータファイルのストレージ階層のライフサイクルを示します。 Apache Iceberg の equality delete は、位置ベースのメタデータを必要とせずに特定のフィルター条件に一致するレコードを削除できるデータ変更操作で、大規模データセットでの効率的かつ正確なデータ削除を可能にします。テーブル更新の merge-on-read 方式です。 上の図の例では、クエリ時に Iceberg が delete ファイルの述語をデータファイルに動的に適用します。id=2、name=Brad の行はストレージに残りますが、クエリからは見えなくなります。Iceberg は元のデータファイルを変更せずに、読み取り操作中に削除情報を「マージ」します。この 2 つのファイルに対してコンパクションが実行されると、以下の処理が行われます。 データファイルと delete ファイルの両方を読み取る id=2、name=Brad に一致する行をデータから物理的に削除する 削除された行を含まない新しい統合データファイルを作成する 条件が適用済みのため、個別の delete ファイルを除去する テーブルデータへのアクセスを最適化し、読み取り操作中の処理負荷を削減するために一般的に有効な操作ですが、データファイルが IA や AIA 階層にある場合、S3 Tables はコンパクションを実行しません。ただし、ファイルが再度読み取られて高頻度アクセス階層に戻ると、コンパクションが新しいサイクルを開始する際にデータファイルの階層を評価し、FA 階層にあることを確認してメンテナンスタスクを実行します。不要な行を削除し、読み取りに最適化されたファイルを作成します。 S3 Tables でコンパクションを手動実行して delete ファイルの統合やレコードの完全削除を行うことも可能ですが、外部コンパクションジョブは Intelligent-Tiering ストレージクラスの認識とは独立して動作します。S3 Tables は外部コンパクションジョブの実行タイミングを予測できないため、Intelligent-Tiering の最適化はテーブルの自然なアクセスパターンのみに基づきます。手動コンパクションを実行すると、IA や AIA 階層に遷移したファイルを含むデータファイルが統合のために読み取られ、FA 階層に戻ります。その結果、ストレージコストが増加する可能性があります。 まとめ データ駆動型の環境において、効果的なテーブルメンテナンスは大規模データレイクを管理する組織にとって不可欠です。 S3 Tables は、スナップショット管理、コンパクション戦略、Intelligent-Tiering を統合したデータライフサイクル管理ソリューションを提供します。スナップショットで重要な履歴データを保持し、アクセスパターンを考慮したコンパクションでファイルレイアウトを最適化し、コールドデータをコスト効率の高いストレージ階層に自動的に移動します。 スナップショット管理、コンパクション、Intelligent-Tiering の連携により、日常的にアクセスされるデータも長期保存されるデータも、ライフサイクル全体を通じてパフォーマンスとコスト効率の両方が維持されます。組織は複雑なメンテナンスワークフローからデータからの価値ある洞察の抽出へと注力を移すことができ、安定したパフォーマンス、最適化されたストレージコスト、ビジネスニーズの変化に対応するスケーラブルなデータレイクの恩恵を受けられます。本ブログをお読みいただきありがとうございます。ご質問やコメントがありましたら、コメントセクションにお気軽にお寄せください。 著者について Ran Pergamin ストレージ担当のシニアスペシャリストソリューションアーキテクトです。大規模なストレージの課題解決に取り組んでいます。最近はコンテナ、オープンテーブルフォーマット、データレイク、ベクトルに注力しています。プライベートでは CrossFit を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。