こんにちは。クラウドセントリック株式会社の kt です。普段は AWS 移行案件を担当しています。
先日、外部のイベントに参加した際に AWS Transform 継続的モダナイズ というサービスを初めて知り、面白そうだったので実際に試してみることにしました。
※ 本機能は執筆時点でプレビューです。画面や挙動は今後変わる可能性があります。
AWS Transform 継続的モダナイズって何？
継続的モダナイズ（continuous modernization）は、ソースコードリポジトリを接続して、その分析と修復を自動で行う AWS Transform の新機能です（2026年6月にプレビュー発表）。従来の「一度きりの移行プロジェクト」を、常に回り続けるプロセスに進化させたもの、とイメージすると分かりやすいです。
コードリポジトリとして接続できるのは GitHub 組織・GitLab グループ・Bitbucket ワークスペース・ローカルリポジトリ の 4 種類です（※1）。自動分析を走らせると、コードベース全体から次の 4 つを洗い出してくれます。
※1 ローカルリポジトリは Web アプリの画面からは接続できず、
atx ctなどの CLI コマンド経由でのみ利用できます（GitHub / GitLab / Bitbucket は Web アプリからも接続可）
- 技術的負債（EOL 依存・非推奨フレームワークなど）
- セキュリティの脆弱性
- モダナイゼーションの機会
- エージェントの準備状況（AI コーディングエージェントで扱いやすい状態になっているか）
主な機能
AWS Transform の公式ドキュメントでは、継続的モダナイズの主な機能として次の 4 つが挙げられています。
- 技術的負債の分析：古い依存・脆弱性・コード品質・モダナイズの機会がないかリポジトリをスキャンする。マニフェスト（
pom.xmlなど）を見るクイックスキャンと、コードの中身まで踏み込む包括分析があり、独自基準のカスタム分析も定義できる - 自律修復：検証済みの修正を大規模に生成する。各検出結果を変換定義で自動修正し、ブランチを作って GitHub / GitLab / Bitbucket に PR・MR を自動で開く
- レポート：重要度・リポジトリ・分析タイプ別に検出結果をまとめた HTML レポートを生成する。修復の進捗や検出結果の解消状況が時系列で分かるので、状況の把握に使える
- 継続的モニタリング：定期分析をスケジュール実行（毎日 / 毎週 / 毎月）して、新しい問題がないかポートフォリオを継続的に監視する。自律修復と組み合わせると、コードの状態を継続的に保ってくれる
依存パッケージのバージョン更新だけなら Dependabot などのツールでも行えますが、Lambda ランタイムのような AWS 固有の負債や、SDK v2 → v3 のように呼び出し側のコードまで書き換える必要がある変更を、複数リポジトリ横断でまとめて扱えるのがこの機能の特徴です。
分析タイプ
「分析（Analysis）」を実行するときは、目的に応じて分析タイプを選びます。公式ドキュメントでは次のタイプが用意されています。
| 分析タイプ（Web アプリの表示） | CLI の --type 値 |
内容 |
|---|---|---|
| 技術的負債 | rapid-techdebt-analysis |
package.json / pom.xml / requirements.txt などのメタデータだけを高速スキャンし、古い依存・バージョンを洗い出す（ソースコードは解析しない） |
| 技術負債 | tech-debt-comprehensive |
AWS Transform エージェントがソースコードの中身まで踏み込み、負債パターンやコード品質・改善の機会を分析する |
| セキュリティ | security |
AWS Security Agent による脆弱性・CVE 検出。既知の脆弱性や危険なコーディングを見つける（初回だけインフラの設定が必要） |
| エージェントレディネス | agentic-readiness |
AI／エージェント統合の準備状況を評価する |
| モダナイゼーションレディネス | modernization-readiness |
コンテナ化・サーバーレス移行など、クラウドモダナイズの機会を評価する |
| （Web アプリには無し） | custom |
任意の変換定義（TD）を分析として実行する |
Web アプリのドロップダウンでは セキュリティ がグレーアウトしていました。セキュリティ分析は初回に専用のインフラ設定が必要なためで、未設定だと選べません。また
customは Web アプリには出てこない CLI 専用のタイプです。
以下コンソールの画像になります。
まず全体の流れ
継続的モダナイズは、ざっくり 「コードを登録 → 探索 → 分析 → 修正」 の順に進みます。
Source（コードの場所を登録）
↓
Discovery（Source 内の Git リポジトリを探す）→ Repository
↓
Analysis（技術的負債を調査。ここではコードは変わらない）
↓
Finding（見つかった改善候補。改善チケットのようなもの）
↓
Remediation（Transformation に沿ってコードを修正・検証）
↓
Pull Request / Merge Request をレビュー
用語
| 用語 | 意味 |
|---|---|
| Source | コードの場所（GitHub 組織 / GitLab グループ / Bitbucket ワークスペース / ローカル）の登録 |
| Discovery | Source に接続して中の Git リポジトリを列挙し、Repository として登録する処理 |
| Repository | 分析対象の単位。<Source 名>::<リポジトリ名> が一意な識別子になる |
| Analysis | 指定した分析タイプでリポジトリをスキャンする処理 |
| Finding | 分析で見つかった改善候補 |
| Remediation | Finding を Transformation に沿って実際に修正する処理。GitLab なら MR（Merge Request。GitHub の PR に相当）が自動作成される |
| Transformation | 修正の手順書（変換定義）。AWS/nodejs-aws-sdk-v2-to-v3 のような既製のものと、独自に作るカスタムがある |
ポイントは Analysis と Remediation が分かれていることです。まず調査だけして結果を確認し、そのうえで直すものを選んで修正に進めます。
実際に試してみる（GitLab への自動 MR まで）
試した構成
今回は検証のためEC2上にGitlabを用意し、そこをソースとします。
また、分析はtech-debt-comprehensiveを実施します。
スキャン対象のリポジトリ（sample-helloworld）
検証用に以下リポジトリを用意しました。中身は CDK（TypeScript）製の小さな Hello World API で、API Gateway → Lambda というシンプルな構成です。
sample-helloworld/ ├── cdk.json ├── package.json # AWS CDK v1 / AWS SDK v2 / TypeScript 4.9.5 ├── tsconfig.json ├── lib/ │ └── app.ts # CDK スタック定義（API Gateway → Lambda）。@aws-cdk/* を個別 import └── src/ └── lambda/ └── index.ts # Lambda 本体。AWS SDK v2 で STS を呼ぶ
| 対象ファイル | 内容 | 狙った検出・変換 |
|---|---|---|
package.json |
AWS CDK v1（@aws-cdk/core ほか 1.193.0） |
CDK v1 → v2 移行 |
package.json |
AWS SDK for JavaScript v2（aws-sdk ^2.1690.0） |
SDK v2 → v3 移行 |
package.json |
TypeScript 4.9.5 |
古いバージョンの更新 |
lib/app.ts |
@aws-cdk/* を個別に import する v1 スタイル |
aws-cdk-lib への集約・constructs 化 |
lib/app.ts |
Lambda ランタイム nodejs18.x |
ランタイム更新の候補 |
src/lambda/index.ts |
AWS.STS() で getCallerIdentity() を呼ぶ v2 スタイルの実装 |
v3 の command パターンへの書き換え |
※今回用意した環境は Claude Code に作成してもらいました。Transformのセットアップ、EC2の起動、Gitlabのセットアップについては本検証内容から外れるため省略します。
試してみる
今回使ったコマンドは以下のとおりです。
構文はこちらです（<> はプレースホルダ）。
# Source を登録する atx ct source add \ --name <Source名> \ --provider gitlab \ --org <グループ/ユーザー> \ --token '<PAT>' \ --url <GitLabのURL> # 登録済み Source を確認する atx ct source list # Source 内の Git リポジトリを検出し Repository として登録 atx ct discovery scan --source <Source名> # 検出された Repository の一覧を表示 atx ct repository list --source <Source名> # 技術的負債を分析する atx ct analysis run \ --type <分析タイプ> \ --source <Source名> \ --repo <Source名>::<リポジトリ名> # 分析の状況・結果を確認する atx ct analysis list atx ct analysis get --id <Analysis ID> --json # 検出結果を確認する atx ct findings list --repo <Source名>::<リポジトリ名> --json atx ct findings get --id <Finding ID> # 是正を実行する atx ct remediation create \ --ids <Finding ID> \ --name <任意の名前> # 修復の進捗を確認する atx ct remediation status --id <Remediation ID> --json
そして、今回のプレースホルダに入れた値がこちらです。
筆者の検証環境での値なので、試す場合はご自身の環境の値に読み替えてください（ID は実行するたびに新しく発行されます）。
| 項目 | 今回の値 |
|---|---|
| Source 名 | gitlab-ec2 |
| プロバイダー | gitlab（セルフホストなので --url を指定） |
グループ/ユーザー（--org） |
root |
| GitLab の URL | https://<GitLabのIP>（EC2 のパブリック IP） |
| Repository | gitlab-ec2::sample-helloworld |
| 分析タイプ | tech-debt-comprehensive（技術負債・包括的） |
| Analysis ID | 01M1XAA7NEVX1V8K5JXZ3W8GJ7 |
| Finding ID（CDK v1） | 01M1XAQ57AVNMQ0KMTB3XMF0Y7 |
| Finding ID（SDK v2→v3） | 01M1XAQ79N43XZAGR04HXFS96P |
| Finding ID（Lambda ランタイム） | 01M1XAQ6JMEE6HTHNBSZ5CY20D |
Remediation 名（--name） |
sdk-v3-gitlab-test |
| Remediation ID | 01M1XCENSCWN58EG83F365PK8Y |
① Source 登録と Discovery
Sourceの登録は以下コマンドで実施します。
atx ct source add \ --name gitlab-ec2 \ --provider gitlab \ --org root \ --token 'glpat-****************' \ --url https://<GitLabのIP>
登録完了後は以下のコマンドで確認できます。
atx ct source list
Name Provider Identifier ──────────────────────────────── gitlab-ec2 gitlab root
Source はコードの場所を登録しただけなので、続けて Discovery を実行してリポジトリを検出します。
atx ct discovery scan --source gitlab-ec2
Found 1 repos root/sample-helloworld
検出された Repository は以下のコマンドで確認できます。AWS Transform 内では Source 名と Repository 名を :: で連結した gitlab-ec2::sample-helloworld が一意な名前になり、以降はこれを指定します。
atx ct repository list --source gitlab-ec2
Slug Full Name Language Workflow Labels ───────────────────────────── ─────────────── ────── ───── ─── gitlab-ec2::sample-helloworld root/sample-helloworld
コンソールを確認すると以下のようにソースに登録されているのが確認できます。
② Analysis（技術的負債の調査）
対象 Repository を指定して Analysis を実行します。今回は 技術負債（包括的） を選びました。
atx ct analysis run \ --type tech-debt-comprehensive \ --source gitlab-ec2 \ --repo gitlab-ec2::sample-helloworld
Preparing 1 repository... Cloning gitlab-ec2::sample-helloworld... Analyzing gitlab-ec2-sample-helloworld-356a81257de4d06a with AWS/comprehensive-codebase-analysis... Still analyzing gitlab-ec2-sample-helloworld-356a81257de4d06a... (2m elapsed) Still analyzing gitlab-ec2-sample-helloworld-356a81257de4d06a... (7m elapsed) ✓ gitlab-ec2::sample-helloworld complete Analysis 01M1XAA7NEVX1V8K5JXZ3W8GJ7 (tech-debt-comprehensive) started on 1 repo(s) Check: atx ct analysis list
実行状況は以下のコマンドで確認できます。
atx ct analysis list
01M1XAA7NEVX1V8K5JXZ3W8GJ7 tech-debt-comprehensive complete 1/1
ファイル 5 個ほどの小さなアプリ 1 リポジトリで、所要時間は約 7 分 44 秒、消費した Agent minutes は 40.69 でした。所用時間より Agent minutes が大きいのは、複数のエージェントが並行で動いた分が合算されるためです。
③ Finding（検出結果）の確認
分析結果は Finding として 1 件ずつ登録されます。
atx ct findings list --repo gitlab-ec2::sample-helloworld --json
検出されたのは 8 件でした。コマンドの出力が長かったので要点を表にまとめます。
| 重要度 | Finding | カテゴリ | Remediation に使える Transformation |
|---|---|---|---|
| high | AWS CDK v1 End of Life | dependency | なし |
| high | AWS SDK for JavaScript v2 in Maintenance Mode | dependency | AWS/nodejs-aws-sdk-v2-to-v3 |
| high | Node.js 18.x Lambda Runtime End of Life | dependency | AWS/lambda-nodejs-runtime-upgrade |
| medium | TypeScript 4.x Outdated | dependency | なし |
| low | Outdated @types/node Version | dependency | なし |
| low | Missing Package Lock File | maintainability | なし |
| low | No Test Coverage | code-quality | なし |
| low | No CI/CD Pipeline | infrastructure | なし |
個別の詳細は findings get で確認できます。
（抜粋）
{
“repo”: “gitlab-ec2::sample-helloworld”,
“category”: “dependency”,
“severity”: “high”,
“title”: “AWS CDK v1 End of Life”,
“description”: “All CDK packages (@aws-cdk/core, @aws-cdk/aws-lambda, @aws-cdk/aws-lambda-nodejs, @aws-cdk/aws-apigateway, aws-cdk CLI) are pinned at version 1.193.0. AWS CDK v1 reached End of Life on June 1, 2023 and no longer receives security patches, bug fixes, or new features.”,
“status”: “open”,
“recommendation”: “Migrate from CDK v1 to CDK v2 (aws-cdk-lib consolidated package). Replace all @aws-cdk/* imports with aws-cdk-lib equivalents.”,
“file_refs”: [“package.json”, “lib/app.ts”,
“cdk.json”],
“fix”: null
}
注目したいのが "fix": null です。本命として仕込んだ CDK v1 → v2 は high で検出されたものの、自動修復に使える Transformation が用意されていません。検出はしてくれるが、自動では直せないということです。8 件のうち自動修復できるのは SDK v2→v3 と Lambda ランタイム更新 の 2 件だけでした。
以下検出結果になります。
④ Remediation（是正）→ GitLab に自動 MR
自動修復できる Finding のうち、AWS SDK v2 → v3 を選んで Remediation を実行します。対象リポジトリは Finding から自動導出されるため --repo は指定しません。
atx ct remediation create \ --ids 01M1XAQ79N43XZAGR04HXFS96P \ --name sdk-v3-gitlab-test
Starting remediation 01M1XCENSCWN58EG83F365PK8Y... Remediating with 20 concurrent slot(s) (remote mode)... Analyzing gitlab-ec2-sample-helloworld-356a81257de4d06a with AWS/nodejs-aws-sdk-v2-to-v3... Still analyzing gitlab-ec2-sample-helloworld-356a81257de4d06a... (2m elapsed) Remediation started: 01M1XCENSCWN58EG83F365PK8Y Check: atx ct remediation list
進捗は Remediation ID を指定して確認します。
atx ct remediation status --id 01M1XCENSCWN58EG83F365PK8Y --json
（抜粋）
{
“id”: “01M1XCENSCWN58EG83F365PK8Y”,
“status”: “completed”,
“name”: “sdk-v3-gitlab-test”,
“transform_name”: “AWS/nodejs-aws-sdk-v2-to-v3”,
“repos”: {
“gitlab-ec2::sample-helloworld”: {
“status”: “pr_open”,
“transform_name”: “AWS/nodejs-aws-sdk-v2-to-v3”,
“execution_artifacts”: {
“transform_pr_url”: “https://<GitLabのIP>/root/sample-helloworld/-/merge_requests/1”,
“agentMinutes”: “27.35”
},
“error”: null
}
}
}
リポジトリのステータスが pr_open になり、transform_pr_url に GitLab の MR の URL が入りました。所要時間は 約 6 分 32 秒、消費した Agent minutes は 27.35 でした。
⑤ 生成された MR の中身
生成された MR を開いて中身を確認します。
| 項目 | 内容 |
|---|---|
| タイトル | Draft: [sample-helloworld] fix(dependency): AWS SDK for JavaScript v2 in Maintenance Mode |
| ブランチ | atx/nodejs-aws-sdk-v2-to-v3-20260907-163122 → main |
| 状態 | opened（Draft） |
| 変更 | 3 files changed, +2196 / −4 |
| 変更ファイル | package.json / src/lambda/index.ts / package-lock.json |
MR の説明文は自動生成されており、冒頭に警告が入っていました。
> ⚠️ High-risk change — manual review recommended (severity: high)
元になった Finding、適用した Transform、変更ファイル一覧も本文に記載され、末尾は Automated by ATX Continuous Modernization. Review carefully before merging. で締められています。Draft MR として作られ、人間のレビューを前提にしているのが分かります。
肝心の diff を見てみます。
まず package.jsonではモノリシックな aws-sdk（v2）が、必要なクライアントだけのモジュラーな @aws-sdk/client-sts（v3）に置き換わっています。そして src/lambda/index.tsでは依存パッケージのバージョンを書き換えただけでなく、それを使っている実装まで v3 の作法に移行されています。
import * as AWS from 'aws-sdk'→ 必要なクラスだけの named importnew AWS.STS()→new STSClient({})sts.getCallerIdentity().promise()→stsClient.send(new GetCallerIdentityCommand({}))（command パターン）
v2 の .promise() から v3 の send(new XxxCommand()) への書き換えは、依存パッケージのバージョンを更新するだけでは済まない部分です。ここまで自動でやってくれるのは素直に便利だと感じました。
かかった料金
継続的モダナイズは有料機能で、分析も修復も Agent minutes で課金されます（単価 $0.035 / agent minute、最小課金単位 1 分。参考：AWS Transform の料金）。検証では以下の結果となりました。
| 操作 | Agent minutes | 金額 |
|---|---|---|
| Analysis（技術負債・包括的） | 40.69 | 約 $1.42 |
| Remediation（SDK v2 → v3） | 27.35 | 約 $0.96 |
| 合計 | 68.04 | 約 $2.38 |
ファイル 5 個の小さなリポジトリで 約 2.4 USD（350 円ほど） でした。公式の料金例には「SDK upgrades (Node.js) / 約 3,000 行 / 約 20 agent minutes / $0.70」とあり、今回の修復（27.35 分 / 約 $0.96）は近い水準です。
意外だったのは 分析のほうが修復より高くついたことです（$1.42 対 $0.96）。包括的分析はコード全体を読むため、対象が小さくても相応にかかるようでした。
なお Agent minutes に含まれないものが公式に明記されています。
- ユーザーの待ち時間
- CLI 側の処理（ファイル読み込み、ビルド、テスト実行）
セキュリティ分析だけは別枠で、AWS Security Agent 側の課金になります。
触ってみた所感
先に正直なところを書いておくと、私は普段インフラ側を担当していて、アプリのコードを書く人間ではありません。そのため生成された diff が「そのまま本番に出せる品質か」を判断する力はありません。その前提で、自分の目で確認できたことと判断できなかったことを分けて書きます。
確認できたこと
- コマンド 4 つ（
source add→discovery scan→analysis run→remediation create）で、GitLab に MR が立つところまで通った。 - 分析は 1 リポジトリで約 7 分 45 秒。仕込んだ負債（SDK v2 / CDK v1 / Node.js 18 / TypeScript 4.9）はすべて検出された
- 仕込んでいない「テストが無い」「CI/CD が無い」「lock ファイルが無い」も指摘された。依存のバージョンだけでなくリポジトリの作り自体を見ている
- 修復は依存の書き換えだけでなく、
.promise()→send(new XxxCommand())のように呼び出し側のコードまで直っていた。ここは diff を目で追える範囲で明確だった
判断できなかったこと
- 生成されたコードが v3 の作法として適切か、見落としが無いかは、私の力では評価しきれません
- 今回のリポジトリにはテストが 1 つもありません（③ で「No Test Coverage」が挙がっていた通り）。つまり「壊れていない」ことを自動で担保する仕組みが無い状態でした。MR の Validation 欄も diff の統計だけで、ビルドやテストの結果は載っていませんでした
- 逆に言うと、自動修復を本気で使うならテストが前提だと分かりました。「テストが無い」という指摘は単なる減点項目ではなく、自動化の土台の話だったわけです
引っかかった点
- 本命として仕込んだ CDK v1 → v2 は high で検出されたのに
fix: null、つまり自動修復用の Transformation が用意されていませんでした。8 件のうち自動で直せたのは 2 件だけ。「検出できる範囲」と「自動で直せる範囲」は別物だと理解しておく必要があります - MR は Draft ＋
High-risk change — manual review recommended付きで作られます。現状は、全部を任せるものではなく、レビューできる状態まで持ってきてくれるツールという位置づけになりそうです
まとめ
- 継続的モダナイズとは：リポジトリを接続して、技術的負債・セキュリティの脆弱性・モダナイゼーションの機会・エージェントの準備状況を分析し、修正の PR・MR まで自動生成してくれる AWS Transform の新機能。
- 試してみて：EC2 に立てた GitLab を Source に、CDK v1 + SDK v2 の小さなアプリを分析 → 8 件検出 → SDK v2 → v3 の自動修復で GitLab に Draft MR が生成されるところまで通せた。依存の書き換えだけでなく、呼び出し側のコードまで v3 の作法に移行されていたのが収穫。
- ただし：本命として仕込んだ CDK v1 → v2 は検出されたものの自動修復の Transformation が無く、8 件中自動で直せたのは 2 件だけだった。「検出できる範囲」と「自動で直せる範囲」は分けて考える必要がある。
技術的負債は「分かっているけど手が回らない」の代表格ですが、棚卸しから修正案の作成までを数分〜十数分で、しかもレビューできる状態まで持ってきてくれるのは実用的だと感じました。一方で全部を任せられるわけではありません。自動では直せない負債もありますし、変更の妥当性を担保するテストは自分たちで用意しておく必要があります。プレビューのうちに自分のリポジトリで「何が検出できて、何が自動で直るのか」を確かめておくと、GA 後の判断がしやすくなると思います。
