トップ > AWS Transform > AWS Transform continuous modernization プレビュー公開！ ── Lambda ランタイム EOL 対応はどこまで自動化できるのか試してみました

AWS Transform continuous modernization プレビュー公開！ ── Lambda ランタイム EOL 対応はどこまで自動化できるのか試してみました

AWS Transform
記事タイトルとURLをコピーする

忙しい人向け3行まとめ

  • AWS Transform continuous modernization は、複数リポジトリの技術的負債を検出し、修正案作成まで支援する Preview 機能です
  • 今回の検証では、Python 3.10 の Lambda ランタイム更新とaws-sdk v2 から v3 への移行で実用的な差分が生成されました
  • 全部を任せるというより、棚卸しと修正案づくりを手伝ってもらう感覚で使うのがよさそうでした（検出結果の偏りや、local provider での通知・進捗確認の弱さがまだある）

はじめに

こんにちは。アプリケーションサービス本部 ディベロップメントサービス4課の大橋です。

AWS Transform continuous modernization は、複数リポジトリの技術的負債を継続的に検出し、修正案の作成まで支援する Preview 機能です。2026年6月17日に発表され、AWS Summit 2026 の Keynote でも取り上げられていました。

この機能で気になったのは、Lambda ランタイムの EOL 対応や SDK 移行のような、地味だけど定期的に発生する保守作業に使えそうだった点です。

たとえば Python 3.10 は 2026年10月末に EOL を迎えます。関数が1つ2つなら手で追えますが、複数リポジトリに小さな Lambda 関数が散らばっていると、棚卸し、影響確認、修正、テスト、レビューの負荷は無視できなくなります。

依存ライブラリの更新だけなら Dependabot 等 でも対応できます。一方で、Lambda ランタイムのような AWS 固有の負債や、SDK 移行のようにコードの中身まで踏み込む変更を、複数リポジトリ横断で扱えるなら便利そうです。

今回は AWS Transform continuous modernization を実際にサンプルリポジトリで試し、どこまで使えるのかを検証しました。

AWS Transform continuous modernization とは

概要

AWS Transform は、レガシーコードの移行や最新化を支援するサービスです。Windows/.NET 移行やメインフレーム移行など複数の機能を持つサービスですが、2026年6月、その中の新機能として continuous modernization capability が Preview 公開されました。本記事では、前回の記事で扱った custom と対比しながら、今回の continuous modernization を中心に扱います。

従来の Transform は「このリポジトリをこのルールで変換する」という単発の変換実行が中心でした。continuous modernization は、それを一歩進めて、複数リポジトリの技術的負債を継続的に検出・優先順位付け・修復するための機能です。

基本の流れ

大まかには、次の3つの流れで使います。

層 機能
検出（Analysis） コードベースを分析し、技術的負債を検出する
優先順位付け（Findings） 検出した問題を severity（HIGH / MEDIUM / LOW）で整理する
修復（Remediation） 変換定義（Transformation Definition）を実行して自動修正する

名前にある continuous（継続的）という部分は、Amazon EventBridge Scheduler と連携して分析を定期的に自動実行できる点にあります。日次・週次・カスタムの cron スケジュールで分析を繰り返し、新たに発生した技術的負債を検出し続けることで「継続的なモダナイゼーション」になります。

ただ、触る前に持っていた「全部まとめて自動で直してくれる」というイメージは、実際には少し違いました。後述するとおり、検出された問題に対して、修復に使える変換定義（Transformation Definition）が紐づいていないと、そのままでは自動修復できない場面があります。完全自動の保守担当というより、複数リポジトリの問題を見つけて修正候補を作り、人間がレビューする流れを支援する機能という捉え方が適切かもしれません。

前回の AWS Transform custom との違い

前回の記事「AWS Transform custom でカスタム変換定義を作ってみた ─ Serverless Framework v3 から CDK v2 への移行を試しました」では、AWS Transform custom を使って Serverless Framework v3 から CDK v2 への変換定義を作り、単発の変換を試しました。

なお、どちらも AWS Transform を操作する CLI atx のサブコマンドで、前回が atx custom、今回が atx ct（continuous の略）です。実行基盤となるエージェントは共通で、課金も同じ Agent Minutes 単位になります。

continuous modernization は、その「単発の変換」を繰り返し・複数リポジトリで実行できるように管理する仕組みと理解するとわかりやすいです。

Transform custom Continuous modernization
使い方 特定の変換を定義して1回実行する 継続的に検出・優先順位付け・修復を管理する
対象 単一リポジトリ 複数リポジトリを横断
変換定義 自分で作る（カスタム） AWS マネージド変換定義を中心に、検出結果や対象リポジトリに対して変換定義を適用する
向いているケース 大規模な1回きりの移行 EOL 対応・ライブラリ更新などの継続的な保守

今回の検証範囲

AWS Transform には analyses、findings、remediations を確認できる Web アプリケーションも用意されています。ただ、今回は細かい挙動や生成される差分を追いたかったため、atx CLI を使って手動で検証しました。定期実行までは扱わず、手動実行で検出・修復の品質を確認するところまでを対象としています。

Analysis には複数の種類があります。今回試した tech-debt-quick（メタデータのみのスキャン）と tech-debt-comprehensive（AI によるコードレベルの分析）のほか、security、agentic-readiness、modernization-readiness、custom があります。各 analysis type の詳細は 公式ドキュメント を参照してください。

対応ソースは GitHub / GitLab 等のほか、ローカルパス（local provider）も使用できます。分析・修復ジョブの実行基盤（compute）は、ローカル（デフォルト）のほか、Amazon EC2 や AWS Batch（Fargate）も選べます。

リージョンについては、Preview 時点では東京リージョン（ap-northeast-1）が未対応のため、利用時は注意が必要です（対応リージョンは 公式ドキュメント で最新の状況を確認してください）。

検証したいこと

今回の検証で確認したかったことは次の4点です。

  1. Lambda ランタイムの古さ（python3.10 の EOL 接近）を検出できるか
  2. 依存ライブラリの古さ・脆弱性（CVE）を検出できるか
  3. 修復の差分はどこまで実用的か（手直しなしで使えるか）
  4. local provider での運用感はどうか（通知、進捗の可視性など）

検証環境

サンプルリポジトリ

今回は、古い構成を意図的に含んだサンプル SAM（Serverless Application Model）アプリを用意しました。

sample-legacy-app/
├── template.yaml                 # SAM テンプレート（Python 3.10 / Node.js 20.x）
├── lambda/python-fn/
│   ├── handler.py                # DynamoDB 読み書き
│   └── requirements.txt          # 古い boto3 / urllib3 など
└── lambda/nodejs-fn/
    ├── index.js                  # SNS 発行（aws-sdk v2 使用）
    └── package.json              # aws-sdk v2 / axios（CVE あり）/ moment など
項目 設定値 状況
Python Lambda ランタイム python3.10 2026年10月末 EOL
Node.js Lambda ランタイム nodejs20.x 2026年4月30日 deprecated 済み
boto3 1.20.0 最新から大幅遅れ
aws-sdk (JS) v2.1000.0 deprecated
axios 0.21.1 CVE あり
urllib3 1.26.5 CVE あり

使用ツール・環境

  • 実行環境: macOS（Apple Silicon）
  • atx CLI: 3.3.0（インストール手順は公式ドキュメント参照）
  • Compute: local（リモート実行なし）
  • Source: local provider（GitHub 連携なし）
  • リージョン: us-east-1

実際に試してみた

ソースを追加する

まずサーバーを起動します。

atx ct server &

次に、ローカルディレクトリをソースとして追加します。

atx ct source add \
  --name local-sample \
  --provider local \
  --path /path/to/parent-directory

local provider のオプションは --path で、git リポジトリを含む親ディレクトリを指定します。GitHub / GitLab / Bitbucket は --org を使うので、provider によって異なる点に注意してください（各 provider の接続手順）。

リポジトリを探索する

atx ct discovery scan --source local-sample

--path で指定した親ディレクトリ配下の git リポジトリが探索され、sample-legacy-app が1件検出されました。.git を持つディレクトリだけが対象になります。

検出（Analysis）

tech-debt-quick（メタデータのみのスキャン）

atx ct analysis run --type tech-debt-quick --source local-sample --wait

結果は 0件 でした。tech-debt-quick は requirements.txt や package.json などのパッケージマニフェストのメタデータのみをスキャンするタイプで、SAM テンプレートの Runtime: python3.10 などは今回検出できませんでした。

tech-debt-comprehensive（AI による分析）

atx ct analysis run --type tech-debt-comprehensive --source local-sample --wait

結果は 12件 でした。Lambda ランタイム、依存ライブラリ、CVE、コード品質まで幅広く検出されました。AI が実際にコードを読んで判断するため、quick では拾えなかった項目まで検出されています。

また、分析完了後に、AWS Transform が ATXDocumentation というフォルダを自動生成し、技術的負債レポートが Markdown でリポジトリにコミットされました。予期していなかった動作でしたが、後述する remediation の後にこのレポートが自動更新される仕組みになっていました。

優先順位付け（Findings）

atx ct findings list
HIGH   tech-debt-comprehensive  local-sample::sample-legacy-app  ...  AWS SDK v2 for JavaScript (deprecated)
HIGH   tech-debt-comprehensive  local-sample::sample-legacy-app  ...  Python 3.10 runtime approaching EOL
HIGH   tech-debt-comprehensive  local-sample::sample-legacy-app  ...  axios 0.21.1 — known CVEs
HIGH   tech-debt-comprehensive  local-sample::sample-legacy-app  ...  urllib3 1.26.5 — known vulnerabilities
MEDIUM tech-debt-comprehensive  local-sample::sample-legacy-app  ...  moment.js in maintenance mode
MEDIUM tech-debt-comprehensive  local-sample::sample-legacy-app  ...  boto3 / botocore severely outdated
...（計 12 件）
severity 件数 内容
HIGH 4件 aws-sdk v2 / Python 3.10 EOL / axios CVE / urllib3 脆弱性
MEDIUM 5件 moment.js / boto3 古い / requests 古い / lodash 古い / certifi 古い
LOW 3件 テストなし / リージョンハードコード / axios 未使用

気になった点として、axios が HIGH（CVE あり）と LOW（未使用）の2件で別々に登場しました。脆弱性と未使用は別の軸で評価しているようです。

今回のサンプルでは、Lambda ランタイムの検出に偏りがありました。Python 3.10（EOL は 2026年10月末）は Python 3.10 runtime approaching EOL として HIGH で検出されましたが、すでに deprecated 済み（2026年4月30日）の nodejs20.x はランタイムとしての finding に出てきませんでした。Node.js 側で検出されたのは aws-sdk v2 の deprecated です。

気になったので分析ログを確認したところ、Transform は template.yaml の Runtime: nodejs20.x 自体は読んでいました。同じ template.yaml の python3.10 は finding 化されているため、SAM テンプレートを読めていなかったわけではなさそうです。

つまり、今回の検証では「ランタイム指定を読めるか」と「EOL / deprecated として finding に出せるか」は別でした。少なくとも今回の構成では、ランタイム EOL / deprecation の検出はまだ網羅的ではないと感じました。

JSON で詳細を確認すると、全12件の "fix" フィールドが null でした。つまり、finding に紐づいた自動修復手順はそのままでは用意されていません。

一方で、HIGH のうち2件には "recommendation" フィールドがあり、修復に使えそうな AWS managed TD（マネージド変換定義）の名前が入っていました。

  • aws-sdk v2: "recommendation": "AWS/nodejs-aws-sdk-v2-to-v3"
  • Python 3.10: "recommendation": "AWS/python-version-upgrade"

修復（Remediation）

remediation の実行方法は、大きく3つあります。

モード 何をするか
findings-based finding に紐づいた fix をそのまま使う
TD override finding を指定しつつ、実行する変換定義をこちらで指定する
direct TD finding を使わず、リポジトリに対して変換定義を直接実行する

今回の findings は fix: null だったため、findings-based で実行すると non_remediable エラーになりました。そこで、finding の ID と AWS managed TD を組み合わせる TD override モードを使います。詳細は 公式ドキュメント を参照してください。

atx ct remediation create \
  --ids <finding-id> \
  --transformation-name AWS/python-version-upgrade \
  --name "fix-python310-eol"

<finding-id> には atx ct findings list で確認した ID を使います。

約3分で完了し、atx/python-version-upgrade-20260624-165433 ブランチが生成されました。

Python の結果：実際の差分（抜粋）

template.yaml:

-      Runtime: python3.10
+      Runtime: python3.13

requirements.txt:

-boto3==1.20.0
-botocore==1.23.0
-requests==2.25.0
-urllib3==1.26.5
-certifi==2021.5.30
+boto3==1.38.0
+botocore==1.38.0
+requests==2.32.3
+urllib3==2.4.0
+certifi==2025.1.31

python3.10 → python3.13 への書き換えと、Python 依存ライブラリの一括更新が自動で行われました。

また、分析時に生成された ATXDocumentation の技術的負債レポートも自動更新されました。解決済みの項目には取り消し線が引かれ、未解決の項目が残る形になっていました。

Node.js の結果：前提条件でエラー、その後成功

続いて aws-sdk v2 → v3 の remediation も試しました。

atx ct remediation create \
  --ids <finding-id> \
  --transformation-name AWS/nodejs-aws-sdk-v2-to-v3 \
  --name "fix-awssdk-v2"

こちらは最初 failed になりました。エラーメッセージは次の通りです。

Local repository has uncommitted changes. Commit or stash them before running remediation.

「ローカルリポジトリに未コミットの変更があります。remediation を実行する前に commit するか stash してください」という意味です。Python の remediation で生成されたブランチに未コミットの変更（__pycache__ など）が残っていたのが原因でした。remediation を実行する前に、リポジトリをクリーンな状態にしておく必要があります。

__pycache__ を .gitignore に追加して解消後に再実行したところ、今度は成功しました。差分は次の通りです。

index.js（aws-sdk v2 → v3 へのコード書き換え）:

-const AWS = require('aws-sdk');
+const { SNSClient, PublishCommand } = require('@aws-sdk/client-sns');

-const sns = new AWS.SNS({ region: 'ap-northeast-1' });
+const snsClient = new SNSClient({ region: 'ap-northeast-1' });

-    await sns.publish({
+    await snsClient.send(new PublishCommand({
         TopicArn: topicArn,
         Message: message,
-    }).promise();
+    }));

package.json:

-    "aws-sdk": "^2.1000.0",
+    "@aws-sdk/client-sns": "^3.821.0",

require('aws-sdk') の削除、SNSClient の初期化、send(new PublishCommand(...)) への書き換えまで、コードの中身まで正しく変換されていました。package-lock.json も自動生成されました。

試してみて手応えがあった点

検出結果から実行できる変換定義を確認できた

tech-debt-comprehensive では、ランタイム、依存ライブラリ、CVE、コード品質のような問題が findings としてまとまりました。今回の検証は1リポジトリだけですが、severity や category が付くので、まず何を見るべきかを整理する入口にはなると感じました。

また、HIGH の一部には remediation に使えそうな マネージド変換定義 の recommendation も出ていました。検出して終わりではなく、どの変換定義を使って修正案を作れそうかまで確認できる点は、AWS Transform らしいところだと思いました。

依存更新だけでなくコード変換まで進む

Python 3.10 → 3.13 の remediation では、SAM テンプレートだけでなく requirements.txt も更新されました。Node.js の aws-sdk v2 → v3 でも、依存パッケージの差し替えだけでなく、SNSClient と PublishCommand を使うコードに書き換えられていました。

他サービスであれば依存関係の更新が中心になりますが、AWS Transform continuous modernization は移行後のコードの形まで作ろうとする点が違うと感じました。（もちろん、そのまま取り込めるかは別で、差分の確認やテストは必要です）

ブランチと検証結果を見てから判断できる

remediation は変更をブランチとして生成します。生成された変更がいきなり本番に入るわけではなく、人間が差分を確認してから取り込める流れです。

今回の生成物には変換結果の検証サマリ（validation summary）も残っていて、どの観点を確認したのかも追えました。AI が作った差分を前提にしつつ、最後は人間がレビューして判断する形になるので、現時点ではこのくらいの距離感がちょうどいいと感じました。

気になった点・注意点

ランタイム EOL の検出に抜けがある

前述のとおり、今回のサンプルでは nodejs20.x がランタイム EOL / deprecation の finding として出てきませんでした。

Lambda の公式ランタイム表では nodejs20.x は 2026年4月30日に deprecated 済みです。ランタイムの棚卸しは Transform の findings だけに任せず、Lambda 公式のランタイム表や Trusted Advisor などと併用した方が安全だと思いました。

完了通知がない（local provider の場合）

remediation の完了を知る手段は atx ct remediation status のポーリングのみです。push 通知も webhook もありません。GitHub 連携であれば PR が立つため通知で気づけますが、local provider だけで運用する場合は自分で状態を確認しに行く必要があります。検証中、ふとリポジトリを見たらファイルが生成されていて「え、終わってたの？」となることが多く、ちょっと不便でした。

進捗が見えない

running から completed に変わるまでの間、進捗率や現在の処理内容は表示されません。今ちゃんとやってるのかな？と思う場面が多く、UX の改善余地が大きいと感じました。

fix: null の制約

findings-based の remediation は、fix フィールドに変換定義が紐づいていないと動きません。今回の検証では多くの findings が fix: null であり、自動修復できるのは managed TD が存在する一部のケースに限られました。

ATXDocumentation の自動コミット（英語のみ）

tech-debt-comprehensive を実行すると、分析結果を Markdown にまとめたドキュメントが自動生成され、リポジトリにコミットされます。生成されるドキュメントはすべて英語です。findings の説明やレポート本文も英語で書かれるため、かなり読みづらいと感じました。

料金（Preview 時点）

Public Preview 時点では continuous modernization 専用の料金体系は未発表です。料金やリージョンの最新情報は、本番導入前に 公式ドキュメント で確認することをおすすめします。

GitHub 連携では org 全体の discovery に時間がかかる

ここまでは local provider を中心に試していましたが、実運用を考えると GitHub 連携も気になります。そこで GitHub source も追加して discovery を試しました。

atx ct discovery scan は、source に登録した GitHub org の全リポジトリを取得しようとします。リポジトリ数が多い org では完了まで非常に時間がかかります（今回は大規模な org に試したところ、タイムアウトになってしまいました）。また、discovery の段階でリポジトリを絞るオプションは、CLI にも公式ドキュメントにも見当たりませんでした。設計としては「org 全体を取り込んでから、ラベルや言語でフィルタして個別に分析する」流れになっています。そのため、現時点では検証用の専用 org や対象リポジトリを絞った環境で試すのが現実的かなと思います。

なお、GitHub 連携が成立すると remediation 完了時に PR が自動生成されます。公式ドキュメント によると、token は classic PAT の repo スコープが必要です。

まとめ

今回の検証では、AWS Transform continuous modernization が AWS Lambda ランタイムの EOL 対応や SDK 移行の修正案作成にどこまで使えるかを確認しました。

Python 3.10 → 3.13 では SAM テンプレートと依存ライブラリが更新され、Node.js の aws-sdk v2 → v3 ではコードの中身まで変換されました。単に検出結果を出すだけでなく、移行後の差分まで作ろうとする点が印象に残りました。

一方で、ランタイム EOL の検出には抜けがあり、自動修復できるのもマネージド変換定義が使えるケースに限られます。EOL 対応を完全に任せるというより、棚卸しと修正案作成を支援する機能として捉えるのが、現時点ではちょうどいい距離感だと感じました。

今回は単発の検出・修復までの検証だったので、名前にある continuous の部分、つまり EventBridge Scheduler 連携による定期実行はまだ試せていません。今後はその点に加え、GitHub 連携で PR として出てくる差分の扱いやすさはどうなのか等も確認したいと思います。

オオハシ (記事一覧)

25年新卒入社
アプリケーションサービス本部 ディベロップメントサービス4課
家とヌオーが好きです