AWS Transform Custom を使用して Java を 7 → 21 にバージョンアップさせてみる

はじめに

先日、AWS re:Invent 2025 にて AWS Transform Custom の発表がありました。

AWS Transform Custom は公式で「AIを活用したカスタムモダナイゼーションエージェント」という表現がされており、コードのモダナイゼーションを提供します。
Java、Node.js、Python のアップグレードなどの一般的なシナリオだけでなく、その他の言語におけるバージョンアップ、ランタイムの移行、複雑な言語翻訳やアーキテクチャの変更など、組織固有のカスタムトランスフォーメーションの実行が可能です。

この記事では、実際に Transform Custom を使用し Java のバージョンアップを試してみたいと思います。

AI 時代のモダナイゼーションについて

本題に入る前にAI時代におけるシステムのモダナイゼーションについて自分の考えを記載しておきたいと思います。

2018年に経済産業省のDXレポートにて「2025年の崖」というレガシーシステムが抱える問題についての言及があり、モダナイゼーションの重要性が広く認識されることとなりました。
奇しくも今年 2025 年は AI エージェント元年ともいわれ、AI エージェントの組織的な展開や PoC から本番環境への移行という段階にまで入っています。

システムの開発においても、様々な組織やチームが積極的に生成AIを用いた開発、いわゆるAI駆動開発の実用化が急務となっています。
しかしながら、現実では生成AIを導入したとしても期待する成果が出ない場合や個人的な利用にとどまるケースが少なくありません。その理由の1つに、システムそのものが生成AIを活用できる状態にないことがあげられます。

例えば、冗長的なコードやブラックボックス化されたコードでは扱うトークン数が膨大になる、影響範囲が大きくなるなど現状の生成AIにとっては精度を大きく落とす要因になります。また、テストの自動化や CI/CD が整備されていない場合、結局はリーダーやマネジメント層の作業がボトルネックとなりチーム全体としての生産性が低下することにつながります。

もはや、システムのモダナイゼーションはこれまで以上の意味を持ち、生成AI活用の鍵とも言えます。
そのため、今回の Transform Custom に限らず、AIエージェントを使用したモダナイゼーションの仕組みやナレッジは組織やチームにとってなくてはならない要素になるのではないかと思います。

上記が、今回記事を書こうと思ったきっかけです。

やってみる

それでは、本題です。

レガシーなアプリケーションの作成

まずは、バージョンアップさせるためのアプリケーションを作成します。
作るアプリケーションは、Minecraft 風のゲームです。
（といっても、前後に動いてブロックを置くだけの簡単なものです）

これを Kiro を使用して Java7 で実装してもらいます。

簡単なアプリケーションではありますが、上記のような雑な指示から要件定義・設計・タスクをすぐに作成して、どんどん実装してくれるのはあらためてすごいですね。

このレベルのアプリケーションであれば、30～60分ほどで実装してくれます。
できたアプリケーションは ↓ のような感じです。

W キーで進む、S キーで下がる、スペースでブロックを配置します。

トランスフォーメーションの実行

それでは下記AWS公式ドキュメントを参考にバージョンアップを実施したいと思います。

前提条件

AWS Transform Custom の CLI での実行にあたり、次の前提条件があるとのことです。
私の場合、Windows を使用していたので WSL 上に環境を移しました。

# 前提条件

## サポートされているプラットフォーム

AWS Transform カスタムは、次のオペレーティングシステムをサポートしています。

- **Linux** - すべての Linux ディストリビューションを完全サポート
- **macOS** - macOSシステムを完全サポート
- **Windows Subsystem for Linux (WSL)** - WSL で実行する場合サポートされます

## 必要なソフトウェア

- **Node.js 20 以降**- https://nodejs.org/en/download からダウンロードしてください
- **Git** - 変換を実行するには、Gitがインストールされており、作業ディレクトリが有効なGitリポジトリである必要があります。実行するgit init; git add .; git commit -m "Initial commit"と、作業ディレクトリにGitリポジトリが初期化されます。

## ネットワーク要件

次のエンドポイントにアクセスできるインターネット接続が必要です。

- `desktop-release.transform.us-east-1.api.aws`
- `transform-custom.us-east-1.api.aws`
- `*.s3.amazonaws.com`

インターネットが制限された環境で作業している場合は、ファイアウォール ルールを更新してこれらの URL を許可リストに追加します。

それでは、公式が推奨しているインストールスクリプトの実行から AWS Transform CLI をインストールします。

curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash

インストールが完了すると atx コマンドから AWS Transform エージェントと自然言語による会話ができます。

ちなみに、日本語も対応しているようでした。

トランスフォーメーションの実行は、変換定義 (Transformation Definitions) から行うことができます。
変換定義は、AWS が事前に作成・検証済みのものを使用する方法と、組織固有のニーズに合わせて自分で作成したカスタム変換を使用する方法があります。
作成したカスタム変換は、AWS アカウント内の変換レジストリ (Transformation Registry) にて管理が可能とのことです。

現時点で AWS が用意している変換定義は、以下の8つになります。
今回は Java のバージョンアップなので、AWS/java-version-upgrade 変換定義を使用します。

Transformation Name	Description
AWS/java-aws-sdk-v1-to-v2	Maven または Gradle を使用して、Java プロジェクトの AWS SDK を V1 から V2 にアップグレードします。
AWS/nodejs-aws-sdk-v2-to-v3	Node.js アプリケーションを AWS SDK for JavaScript v2 から v3 にアップグレードします。モジュラーアーキテクチャ、ファーストクラスの TypeScript サポート、ミドルウェアスタック、パフォーマンス向上を活用しながら、基盤となる Node.js バージョンを変更することなく、すべての AWS サービスとのやり取りが引き続き正しく機能することを保証します。
AWS/python-boto2-to-boto3	公式のAWS移行ドキュメントに基づいて、Pythonアプリケーションをboto2からboto3に移行します。
AWS/python-version-upgrade	Python プロジェクトを Python 3.8/3.9 から Python 3.11/3.12/3.13 に移行することで、最新の Python 機能、セキュリティ更新、ランタイムとの互換性を確保しながら、機能性とパフォーマンスを維持します。対象の Python バージョンは、エージェントとの対話型チャット、または additionalPlanContext 構成パラメータ (例: atx custom def exec --configuration) を渡すことで指定できます。また、構成ファイルで渡すこともできます (例: atx custom def exec --configuration 'file://config.json')。構成ファイルの例については、atx custom def exec -h を実行してください。
AWS/nodejs-version-upgrade	NodeJSアプリケーションを、任意のNodeJSバージョンから任意のターゲットNodeJSバージョンにアップグレードします。希望するNodeJSバージョンは、エージェントとの対話型チャット、またはadditionalPlanContext構成パラメータ（例：atx custom def exec --configuration）を渡すことで指定できます。また、構成ファイル（例：atx custom def exec --configuration 'file://config.json'）で渡すこともできます。構成ファイルの例については、atx custom def exec -h を実行してください。
AWS/early-access-comprehensive-codebase-analysis	この変革は、コードベースの詳細な静的分析を実行し、システムのあらゆる側面を網羅する階層的な相互参照ドキュメントを生成します。動作分析、アーキテクチャドキュメント、ビジネスインテリジェンス抽出を組み合わせることで、最大限の使いやすさとナビゲーションを実現するように整理された包括的なナレッジベースを構築します。この変革は技術的負債分析に特に重点を置いており、古くなったコンポーネント、セキュリティ上の脆弱性、そしてルートレベルのメンテナンス上の懸念事項に関する明確で実用的な洞察を提供します。
AWS/java-version-upgrade	あらゆるビルドシステムを使用して、あらゆるJDKバージョンからあらゆるターゲットJDKバージョンにJavaアプリケーションをアップグレードします。Jakarta EE移行、データベースドライバー、ORMフレームワーク、Springエコシステムのアップデートを含む包括的な依存関係の最新化が含まれます。希望するターゲットJDKバージョンは、エージェントとの対話型チャット、またはadditionalPlanContext構成パラメータ（例：atx custom def exec --configuration）を渡すことで指定できます。また、構成ファイル（例：atx custom def exec --configuration 'file://config.json'）で渡すこともできます。構成ファイルの例については、atx custom def exec -h を実行してください。
AWS/early-access-java-x86-to-graviton	AWS Graviton プロセッサ上で実行するための Java アプリケーションと Arm64 アーキテクチャの互換性を検証します。依存関係の更新、アーキテクチャ固有のコードパターンの検出、ソースコードが利用可能な場合のネイティブライブラリの再コンパイルにより、Arm64 の非互換性を特定して解決します。Arm64 サポートに必要なコード修正 (アーキテクチャ検出、ネイティブライブラリのロードなど) は行いますが、一般的なコードリファクタリングは実行しません。最新の Java バージョンと JDK ディストリビューションを維持し、ビルドとテストの実行を通じて互換性を検証します。最適な結果を得るには、Arm 64 ベースの環境で実行してください。注: 多くの最新の Java アプリケーションは既に Arm64 と互換性があります。

では実行します。
実行中に一時停止し承認や対話をしながら進める「対話型モード」と完全自動化の「非対話型」モードがあります。

• 対話型モード：atx custom def exec -n <transformation-name> -p <path>
• 非対話型モード：atx custom def exec -n <transformation-name> -p <path> -x -t

今回は、対話型モードで実行します。
追加の設定がないか確認されるのでバージョンだけ指定します。

Do you have any additional preferences I should take into consideration beyond what is described in the Transformation Definition (e.g. specific version requirements, build or validation commands, etc.)?

> version requuirements: java21

移行計画が作成されるので、指示に従い移行を開始します。
※下記は英語で出力されたものを日本語に翻訳しています

## Transformation Plan Summary

**Project Analysis:**
- Java 7とJava2Dで構築されたシンプルなMinecraftスタイルのゲーム
- 最小限の依存関係で Maven 3.9.8 を使用 (JUnit 4.12、JUnit-Quickcheck)
- Jakarta EE、Spring、またはデータベースに依存しない（グループ 2 ～ 5 は該当しません）
- javax.swing を使用（Java 21 と互換性があります）

**Plan Structure (10 Steps):**

1. **ベースラインの確立** - 現在の Java 7 ビルド状態をキャプチャ
2. **Maven コンパイラ プラグインの更新** - Java 21 をサポートするには 3.13.0 にアップグレード
3. **Maven Surefire プラグインのアップデート** - Java 21 でのテスト実行のために 3.2.5 にアップグレード
4. **Java バージョンの更新** - すべての POM 構成で Java 1.7 から 21 に変更します
5. **JUnit アップグレード** - 4.12 から 4.13.2 にアップデート (Java 21 をサポートする最新の JUnit 4.x)
6. **JUnit-Quickcheck アップグレード** - Java 21 互換性のために 0.8.1 から 1.0 にアップデート
7. **ラムダの近代化** - 匿名内部クラスをラムダ式に変換
8. **非推奨の修正** - Java 21 の非推奨と API の変更に対処
9. **テストスイートの検証** - 完全なテストスイートを実行して、すべてのテストが合格することを確認
10. **最終統合** - ビルド検証とドキュメントの完了

**Key Adaptations:**
- プロジェクトの複雑さが低いことに適した簡素化された計画（10ステップ）
- Jakartaへの移行は不要（グループ2～5は該当しないためスキップされます）
- ビルドシステムの近代化と言語機能の更新に重点を置く
- javax.swing のインポートが保持されます (Java 21 と互換性があります)

実行時は、ブランチが作成され、Step ごとに変更内容がコミットされました。
約1時間ほどでバージョンアップが完了しました。
アプリケーションも問題なく起動しています。

パフォーマンス改善の確認

バージョンアップさせたので Java7 と Java21 でパフォーマンスにどの程度の改善があったか測定をしてみます。
配置するブロック数を増やした場合に、フレームレートとメモリがどのように変化するかを測定しています。

以下結果ですが、わかりやすく改善してくれていたのでよかったです。

フレームレート (FPS) 分析

シナリオ	指標	Java 7	Java 21	改善値	改善率
0 blocks	平均 FPS	59.32	60.89	+1.57	+2.6%
	最小 FPS	12.80	60.58	+47.78	+373.3%
	最大 FPS	62.00	61.81	-0.19	-0.3%
	FPS 標準偏差	高	低	-	大幅改善
50 blocks	平均 FPS	59.56	61.05	+1.49	+2.5%
	最小 FPS	12.07	60.40	+48.33	+400.4%
	最大 FPS	62.62	61.94	-0.68	-1.1%
	FPS 標準偏差	高	低	-	大幅改善
100 blocks	平均 FPS	60.03	61.16	+1.13	+1.9%
	最小 FPS	15.40	60.94	+45.54	+295.7%
	最大 FPS	62.69	61.94	-0.75	-1.2%
	FPS 標準偏差	高	低	-	大幅改善
200 blocks	平均 FPS	59.88	61.30	+1.42	+2.4%
	最小 FPS	14.88	60.76	+45.88	+308.3%
	最大 FPS	62.25	62.31	+0.06	+0.1%
	FPS 標準偏差	高	低	-	大幅改善

📈 重要な知見

1. 平均FPSの向上: 全シナリオで約 1.9% ～ 2.6% の向上
2. 最小FPSの劇的改善: 全シナリオで 295% ～ 400% の大幅向上
   • Java 7 では 12～15 FPS まで低下していたが、Java 21 では常に 60 FPS 以上を維持
3. FPS安定性: Java 21 ではフレームレートが極めて安定
   • Java 7: 最小12.07 ～ 最大62.69（変動幅 50.62）
   • Java 21: 最小60.40 ～ 最大62.31（変動幅 1.91）
   • 変動幅 96.2% 削減

メモリ使用量分析

シナリオ	指標	Java 7	Java 21	削減値	削減率
0 blocks	平均メモリ (MB)	45.95	29.47	-16.48	-35.9%
	最大メモリ (MB)	73.91	33.02	-40.89	-55.3%
	メモリ効率	低	高	-	大幅改善
50 blocks	平均メモリ (MB)	520.70	46.06	-474.64	-91.2%
	最大メモリ (MB)	1091.19	54.79	-1036.40	-95.0%
	メモリ効率	非常に低	高	-	劇的改善
100 blocks	平均メモリ (MB)	659.82	43.50	-616.32	-93.4%
	最大メモリ (MB)	1279.71	67.93	-1211.78	-94.7%
	メモリ効率	非常に低	高	-	劇的改善
200 blocks	平均メモリ (MB)	684.07	46.41	-637.66	-93.2%
	最大メモリ (MB)	1309.67	67.14	-1242.53	-94.9%
	メモリ効率	非常に低	高	-	劇的改善

📊 重要な知見

1. メモリ使用量の劇的削減:

   • ブロック数が増えるほど削減効果が顕著
   • 50 blocks 以上で 91% ～ 93% の削減
   • 最大メモリで 95% の削減（1.3 GB → 67 MB）

2. メモリリーク解消の可能性:

   • Java 7 版: ブロック数に応じてメモリ使用量が急増（0→200 blocks で 14.9倍）
   • Java 21 版: ブロック数が増えてもメモリ使用量がほぼ一定（1.6倍程度）
   • メモリ管理の最適化が大幅に改善

3. GC効率の向上:

   • Java 21 の最新GC（G1GC、ZGC等）による効率的なメモリ回収
   • メモリ圧力の軽減によりGC停止時間が短縮 → FPS安定性向上

おまけ

せっかく Java21 にあげたので最後に Java OpenGL を使用して立体の画面にしてみました。
画質は粗いですが少しだけ本家に近づきました。

まとめ

今回は、AWS で用意されている変換定義を使用しましたが、どのような設定がされているかファイルの中身を確認することはできないようでした。
ただし、既存の変換定義を引き継いでカスタムすることもできるとのことでしたので、業務で使用する場合はその方がいいと思いました。

どちらにせよコードのバージョンアップや別言語へのトランスフォーメーションの工数は大幅に削減できることは間違いないのかなと思います。