AWS Transform continuous modernizationを使ってみた

技術的負債の検出からコード修正までを自動化するAWS Transform continuous modernizationを使ってみました
2026.08.17
リテールアプリ共創部の末永です。
AWS Transformに、技術的負債の検出からコード修正までを自動化するcontinuous modernizationが追加されました。今回は、検証用にレガシーアプリケーションを用意して試してみました。
!continuous modernizationは、現在パブリックプレビューで提供されています。
 ざっくり流れを解説まずは全体像をつかむために、処理の流れをかなりざっくり説明します。見慣れない用語が出てきますが、この時点では読み流してもらって大丈夫です。実際の操作は後で順番に見ていきます。
continuous modernizationは、コードを登録 → 問題を発見 → 修正という流れで進みます。
まず、AWS Transformにコードの場所をSourceとして登録します。GitHubを使う場合はOrganization、ローカルで試す場合は複数のGitリポジトリを置いた親ディレクトリがSourceになります。
次にDiscoveryを実行し、Source内のGitリポジトリを探します。見つかったリポジトリはRepositoryとして登録され、分析対象に選べるようになります。
対象のRepositoryを選んだら、Analysisで問題を調査します。例えば「技術的負債（クイック）」では、package.jsonなどを確認し、古いNode.jsやAWS SDKといった更新候補を検出します。この時点では、コードは変更されません。
検出された問題は、Findingとして一件ずつ登録されます。Findingは「AWS SDK v2をv3へ移行できる」といった改善チケットのようなもので、問題の内容や対象Repository、利用できる修正方法を確認できます。
修正したいFindingを選び、Remediationを実行すると、定義済みの修正手順であるTransformationに沿ってコードが変更され、ビルドやテストも行われます。
GitHubの場合は修正用のブランチとPull Request、ローカルの場合はブランチとコミットが作成されます。内容をレビューして反映した後、再度Analysisを実行することで、問題が解消されたかを確認できます。
コードの場所を登録する

Source

↓

Gitリポジトリを探して登録する

Discovery → Repository

↓

問題を調査する

Analysis

↓

見つかった改善候補を確認する

Finding

↓

コードを修正・検証する

Remediation

↓

Pull Requestまたはローカルブランチをレビューする
 実際にやってみる Webアプリを開くcontinuous modernizationのWebアプリは、AWS TransformコンソールのSettingsにある「Access AWS Transform with IAM credentials」からIAM認証を有効にし、同じ画面に表示される「Web application URL (with IAM)」を開くと利用できます。Webアプリの左側のナビゲーションから「継続的モダナイズ」を選ぶと、ダッシュボード、Finding（検出結果）、Remediation（修復）、Analysis（分析）、Source（ソース）、設定の各画面を開けます。
現在のWebアプリでは、GitHub、GitLab、BitbucketのSource接続、標準Analysisの実行、Findingの確認、Remediation、定期分析の設定まで操作できます。一方、ローカルSourceの登録や独自のAnalysis、細かな実行オプションはCLIを使用します。
 検証用のレガシーアプリケーション検証用として、Node.js 18、TypeScript 4.9、AWS CDK v1、AWS SDK for JavaScript v2を使った小さなレガシーアプリケーションを用意しました。
ローカルSourceでは、指定したディレクトリ自体ではなく、その直下にあるGitリポジトリがDiscoveryの対象になります。そのため、ディレクトリは次のように配置しました。
aws-transform-local-source/       ← Sourceとして登録する親ディレクトリ
└── legacy-orders-api/            ← .gitを持つRepository
 Sourceを登録するまず、親ディレクトリをlegacy-localという名前でSourceへ登録します。
atx ct source add \
  --name legacy-local \
  --provider local \
  --path /path/to/aws-transform-local-source
登録結果は次のコマンドで確認できます。
atx ct source list
Name                 Provider   Identifier
───────────────────────────────────────────────────────
legacy-local         local      legacy-local
WebアプリではSource（ソース）タブの「新しいソースを接続する」からもSourceを追加できます。なお、local SourceはCLIからのみ登録できます。
 Repositoryを検出するSourceはコードの場所を登録しただけなので、続いてDiscoveryを実行します。
atx ct discovery scan --source legacy-local
今回は次のように一つのリポジトリが見つかりました。
Found 1 repos
  legacy-local/legacy-orders-api
検出されたRepositoryは次のコマンドで確認できます。
atx ct repository list --source legacy-local
AWS Transform内でRepositoryを一意に表す名前は、Source名とRepository名を::で連結したlegacy-local::legacy-orders-apiです。以降はこの名前を指定します。
 クイック分析を実行するcontinuous modernizationには、依存関係を短時間で確認する技術的負債のクイック分析、ソースコードまで読む包括的分析、セキュリティ分析、エージェントレディネス、モダナイゼーションレディネス、独自のTransformation Definitionを使用するカスタム分析があります。
今回はpackage.jsonなどのマニフェストから古いランタイムや依存関係を検出する、技術的負債のクイック分析を実行しました。Webアプリでは「技術的負債（クイック）」と表示され、CLIではrapid-techdebt-analysisを指定します。
atx ct analysis run \
  --type rapid-techdebt-analysis \
  --source legacy-local \
  --repo legacy-local::legacy-orders-api
Webアプリから実行する場合は、Analysis（分析）タブの「新しい分析を実行する」を選び、分析タイプ、Source、Repositoryを順番に指定します。
実行状況は次のコマンドで確認できます。
atx ct analysis list
今回のクイック分析では、二つのFindingが作成されました。


重要度
Finding
Remediationに使用するTransformation


高
Node.jsのバージョン更新
AWS/nodejs-version-upgrade

中
AWS SDK for JavaScript v2からv3への移行
AWS/nodejs-aws-sdk-v2-to-v3

FindingはCLIとWebアプリの両方で確認できます。
atx ct findings list --json
atx ct findings get --id <Finding ID>
 AWS SDK v2からv3へのRemediationを実行する今回は二つのFindingのうち、AWS SDK for JavaScript v2からv3へのRemediationを実行しました。
atx ct remediation create \
  --ids 01KZ69KBB3VYV6MK6VB2GMC3M0 \
  --name sdk-v3-local-test \
  --local
実行状況は、RemediationのIDを指定して確認できます。
atx ct remediation status \
  --id 01KZ69M66E4TPGAKWHF7P8QM6Y \
  --json
処理が完了すると、atx/nodejs-aws-sdk-v2-to-v3-20260804-205354というローカルブランチとコミットが作成されました。AWS SDK v2の依存パッケージがv3へ更新され、DynamoDBを操作するコードもv3の仕様に合わせて書き換えられていました。単なるバージョン番号の更新ではなく、SDKを利用する実装まで移行された形です。
変更後もTypeScriptのビルドは成功し、既存のJestテストも5件すべて成功しました。一方、今回選択していないNode.js 18やAWS CDK v1は変更されていません。
今回はローカルSourceを使ったため、AWS TransformがGitHub上にPull Requestを自動作成したわけではありません。GitHub Sourceに書き込み可能なトークンを設定してRemediationした場合は、生成ブランチとPull Requestまで自動作成されます。今回のローカル実行結果をPull Requestとして掲載する場合は、生成されたブランチを自分でGitHubへpushしてPull Requestを作成します。
 実際にかかった料金今回のRemediationでは44.3499 Agent minutesが記録されました。検証時点の料金は1 Agent minuteあたり0.035 USDなので、約1.55 USDです。
44.3499 Agent minutes × 0.035 USD = 約1.55 USD
Agent minuteは、エージェントがサーバー側で計画、推論、分析、コード変更を行っていた時間です。ローカルでのビルドやテストを待っている時間は含まれません。複数のエージェントが同時に動いた場合はそれぞれの時間が合算されるため、実際の経過時間とは必ずしも一致しません。
 実行リージョンについて今回はAWS Transformを東京リージョン（ap-northeast-1）で利用しました。ジョブのリージョンは東京ですが、生成AIの推論では、リクエストを複数のリージョンへ振り分けるクロスリージョン推論が使用されます。東京から送信された推論リクエストは、東京または大阪リージョン（ap-northeast-3）のいずれかで処理されます。なお、今回の--local実行では、リポジトリの操作やビルド、テストはローカルマシンで行われます。
大阪が使われるのは推論処理に限られ、データの保存先は東京から変わりません。詳しくはAWS Transformのクロスリージョン処理で確認できます。
 最後にアプリケーションを運用していると、ランタイムやSDK、フレームワークなどのバージョン変更に日々追われます。Dependabotはマイナーアップデートであればそのまま取り込めることも多く便利ですが、メジャーアップデートになると、APIや設定の変更が必要になり、作成されたPull Requestへ手を入れなければならないことがあります。対応を後回しにしているうちに、更新のPull Requestだけが溜まってしまうことも少なくありません。
continuous modernizationでは、依存パッケージを更新するだけでなく、それに合わせたコードの変更やテストまで行い、Pull Requestの作成まで進められます。もちろん最終的なレビューは必要ですが、手作業が必要になりやすいバージョン更新を、レビューできる状態まで自動で進めてくれるのは結構便利です。
複数のRepositoryに同じような更新が残っている場合は、一つずつ手で直すよりかなり楽になるかなと思います。
では👋