【AWS re:Invent 2025】Amazon Q Developer GameDay と AWS Transform Customで学ぶ Java モダナイゼーション

はじめに
Amazon Q Developer とは
ワークショップ概要
Amazon Q Developer を活用したJava 8 → 21 へのアップグレード
AWS Transform Customとは
AWS Transform Customを活用したJava 8 → 21 へのアップグレード
Amazon Q Developer と比較して
今後のモダナイゼーションについて
さいごに

はじめに

こんにちは!入社2年目の清水です。
この度、ラスベガスで開催された AWS re:Invent 2025 に参加してきました!
本記事では、現地で参加した 「Amazon Q Developerを用いたJavaアプリケーションのモダナイゼーションを体験するGameDay」 について共有します! また、 AWS Transform Custom との比較を通じて、今後のモダナイゼーションの在り方についても考察しています。
既存システムの保守・運用を担当しているエンジニアや、生成AIの具体的な業務活用に興味がある方の参考になれば嬉しいです!

Amazon Q Developer とは

AWS が提供する 開発者向けの生成 AI アシスタント です。IDE（VS Code など）に統合して利用でき、以下のような支援を行ってくれます。

コードの解析・理解
リファクタリングや変換の提案
Java バージョンアップなどのアップグレード支援

特に Java のモダナイゼーションにおいては、既存コードを解析し、非推奨 API や依存関係の問題点を洗い出したうえで、ガイド付きでアップグレードを進められる点が特徴です。

ワークショップ概要

今回参加したワークショップは、Java Modernization and Performance Optimization GameDay（CMP326）です。
このワークショップでは、Amazon Q Developer を活用して Java アプリケーションのモダナイゼーションを効率的に進める方法を学びました。主な内容は、

Java 8 から Java 21 へのアップグレード
テスト環境へのデプロイ
異なるインスタンス間でのパフォーマンス比較

といった一連の作業をハンズオン形式で体験するというものです。

本記事では、ワークショップで実施した内容のうち、 Java 8 から Java 21 へのアップグレードについて紹介します。

Amazon Q Developer を活用したJava 8 → 21 へのアップグレード

今回は、Amazon Q Developer を使って Java 8 から Java 21 へのアップグレードを実施します。

① Java 8 のサンプルコードを用意します。

② 次に、Q Developer の拡張機能から「/transform」と入力、または選択して実行します。

③ チャット上で以下の内容を聞かれるので、それぞれ指定します。

変換対象のプロジェクト
現在の Java バージョン（8）
アップグレード先のバージョン（21）

④ Unit テストの実行可否を確認されますが、今回はスキップしました。

⑤ 最後に、JDK 8 と JDK 21 のパスを入力すると、変換処理が開始されます。

⑥ 変換開始時に、おおよその処理時間が表示されます。今回は 10〜30分程度とのことでした。処理中の進捗は Transformation Hub から確認できます。

⑦変換が完了すると、Summary.md に結果が出力され、以下の内容を確認できます。

ビルドログの概要
置き換えられた依存関係
非推奨コードの対応状況
変更されたすべてのファイル一覧

以上が、今回の GameDay で実施した Java バージョンアップのデモになります。

AWS Transform Customとは

続いて、re:Invent 2025 にて一般提供開始が発表された AWS Transform Customを紹介します。

AWS Transform Customは、エージェンティック AI を活用してカスタムコード変換を自動化し、組織全体のモダナイゼーションを加速するサービスです。Java などの言語アップグレードに加え、組織固有の変換ルールやアーキテクチャ変更にも対応します。さらに、変換結果を継続的に学習することで、高品質かつ再現性の高い変換を実現します。

AWS Transform Customを活用したJava 8 → 21 へのアップグレード

先ほどのワークショップと同じ内容を AWS Transform Customで実施した場合、どのような違いがあるのかを検証しました。
AWS Transform Customは AWS マネジメントコンソールからも利用可能ですが、今回は CLI（AWS Transform CLI）を使用します。

①公式サイトの手順に従って、AWS Transform CLI をインストールします。
　参考 : Getting Started - AWS Transform

②インストールが完了したら、atxでAWS Transform CLI を起動します。

③起動後、以下のプロンプトを実行し、エージェントに対して変換の実行を依頼します。
　今回は、サンプルプロジェクトを対象に Java のバージョンアップを行います。

Execute the AWS/java-version-upgrade transformation on the codebase at ./javaee8-sample

④ターゲットの Java バージョンを聞かれるため、Java 21 を指定します。
　その後、ソースコードの自動解析が開始され、解析完了後に 移行計画 が作成されます。

### プロジェクト分析サマリー

**現在の状態:**
- 37個のPOMファイルを含むマルチモジュールMavenプロジェクト
- Java 8 (バージョン 1.8)
- javax.* 名前空間を使用したJava EE 8 API
- Mavenコンパイラプラグイン 3.8.0
- Payara 5.183 を使用したArquillianベースのテスト
- CDI、サーブレット、JAX-RS、JPA、JSON-P、JSON-B、検証、セキュリティの各モジュールにわたる複数のjavax.*インポート

**目標状態:**
- Java 21
- jakarta.* 名前空間を使用したJakarta EE 10 API
- 更新されたMavenプラグインとビルドツール
- Jakarta EE 10互換のテストインフラストラクチャ

### 変革計画の概要 (12ステップ)

この計画は、変革定義で指定された**グループベースのアプローチ**に従っています。

**グループ1: ビルドシステムの準備 (手順1-3)**
1. Java 8 でビルドのベースラインを確立する
2. Maven コンパイラプラグインおよびその他のビルドプラグインを更新する
3. すべての POM で Java バージョンを 21 に更新する

**グループ 2: Jakarta EE への移行 (手順 4～6)**
4. すべての Jakarta EE 依存関係をアトミックに更新する
5. コードベース全体ですべての javax.* から jakarta.* へのインポート文を更新する
6. XML 構成ファイルのスキーマ (web.xml、persistence.xml、beans.xml) を更新する

**グループ 3: テストおよびサポートライブラリ (手順 7～9)**
7. テストフレームワークの依存関係 (Arquillian、Payara、H2) を更新する
8. Jersey および JAX-RS クライアントの依存関係を更新する
9. JAXB ランタイムの依存関係を更新する

**グループ 4: 最終的な統合 (手順 10～12)**
10. Jakarta への移行の完全性を検証し、エッジケースを修正する
11. Java 21 の言語機能と API の互換性を更新する
12.完全なテストスイートを実行し、結果を文書化します。

### このプランの主な特徴

✅ **コンポーネントごとのアプローチ** - 各ステップは独立して検証可能です。
✅ **アトミックな Jakarta 移行** - すべての Jakarta の変更はステップ 4～6 で調整されます。
✅ **マルチモジュール対応** - 37 個の POM ファイルすべてを体系的に処理します。
✅ **包括的なスコープ** - 依存関係、インポート、および構成ファイルをカバーします。
✅ **ビルド検証** - 各ステップにコンパイル検証が含まれます。
✅ **保守的なアプローチ** - 変更を加える前にベースラインを確立します。

### 重要な依存関係の更新

- **Jakarta プラットフォーム**: javaee-api 8.0 → jakarta.jakartaee-api 10.0.0
- **Jakarta XML バインディング**: 2.3.2 → 4.0.0
- **Jakarta サーブレット**: 6.0.0 を追加しました。
- **Jakartaパーシスタンス**: 3.1.0 を追加
- **Jakarta アノテーション**: 1.3.1 → 2.1.1
- **Jakarta バリデーション**: 3.0.2 を追加
- **Arquillian**: 1.4.1.Final → 1.7.0.Final
- **Payara**: 5.183 → 6.2024.1+
- **H2 データベース**: 1.4.197 → 2.2.224
- **Jersey クライアント**: 2.x → 3.1.5

---

⑤作成された移行計画に問題がなかったため、そのまま変換を実行します。
　変換中は、コンソール上で進捗を随時確認できます。

⑥今回の変換は 約 1 時間 で完了しました。
　変換完了後、変換レポートとデバッグサマリーが自動生成されます。

変換レポートの詳細はこちら

## 概要

javaee8-samples プロジェクトの 11 の変換ステップすべてが正常に完了しました。

✅ **ステップ 1:** Java 8 でビルドのベースラインを確立
✅ **ステップ 2:** Maven コンパイラプラグインを更新し、Java 21 との互換性を確保
✅ **ステップ 3:** すべての Jakarta EE 依存関係を更新 (Payara 6.2023.12、GlassFish 7.0.0、Jakarta EE API 10.0.0)
✅ **ステップ 4:** すべてのインポート文を移行 (103 個の Java ファイルを javax.* から jakarta.* へ)
✅ **ステップ 5:** XML 構成ファイルを更新 (Jakarta EE を含む 31 個のファイル)名前空間)
✅ **ステップ 6:** Jakarta 移行の完全性を検証 (javax インポート残り 0 件)
✅ **ステップ 7:** テストフレームワークの依存関係を更新 (xmlunit、jsonassert、awaitility、json)
✅ **ステップ 8:** Java 21 言語互換性を検証 (警告や非推奨 API なし)
✅ **ステップ 9:** Maven ビルドプラグインを更新 (war、surefire、enforcer、dependency、resources)
✅ **ステップ 10:** 完全なビルド検証を完了
✅ **ステップ 11:** 包括的なドキュメントを作成 (MIGRATION.md、README.md を更新)

## 最終検証結果

Java バージョン: 21.0.9 (Amazon Corretto LTS)
Maven バージョン: 3.8.4
ビルドステータス: 成功 ✅
javax.* インポート残り (Java SE を除く): 0
XML 内の Jakarta 名前空間: 31
モジュールのコンパイル数: 31/31 成功
ブランチ: atx-result-staging-20260124_045858_c3d417e1
コミット合計数: 11

## 主な成果

- **名前空間の完全な移行:** すべての Java EE (javax.*) コードを Jakarta EE (jakarta.*) に移行
- **Java 21 互換性:** Java 21.0.9 での完全なコンパイル成功
- **依存関係の最新化:** すべての依存関係を Java 21 および Jakarta EE 10 互換バージョンに更新
- **ビルドシステムのアップグレード:** Maven プラグインと設定を Java 21 用に更新
- **ドキュメント:** 包括的な移行ガイド (MIGRATION.md) を作成
- **コードの整合性:** すべての元のライセンスとコメントを保持
- **ガードレール準拠:**すべての変換は、セキュリティ、API互換性、およびコード品質のガイドラインに準拠しています。

## 変換の詳細

- **変更されたJavaファイル:** 103
- **変更されたXMLファイル:** 31
- **更新されたルートPOM:** 1
- **変換されたモジュール:** 10 (test-utils、servlet、jaxrs、security、jsf、cdi、jpa、jsonb、validation、json-p)
- **合計変換時間:** 約60分
- **ビルド検証:** すべてのモジュールでコンパイル成功

デバッグサマリーの詳細はこちら

### デバッグサマリー

**変換:** Java EE 8 から Jakarta EE 10 への Java 21 アップグレード
**コードリポジトリ:** ./javaee8-samples
**ビルドコマンド:** mvn clean install

---

### 特定および解決された問題: 4

#### 問題 #1: HTMLUnit の依存関係バージョンが正しくありません
- **エラー:** HTMLUnit バージョン 3.11.0 が Maven Central に見つかりません
- **根本原因:** HTMLUnit は Jakarta EE サポートのために org.htmlunit グループに移動されました。バージョン 3.11.0 が存在しません
- **修正:** `org.htmlunit:htmlunit:4.0.0` に更新しました (Jakarta EE 10 互換)
- **変更されたファイル:** pom.xml (213～215行目)
- **検証:** ✓ 成功 - 依存関係が正しく解決されています

#### 問題 #2: Payara クライアントの依存関係が正しくありません
- **エラー:** payara-client-ee10:1.0.Beta3 アーティファクトが見つかりません
- **根本原因:** payara-client-ee10 はリリースされていませんでした。正しいアーティファクトは payara-client-ee9 です。
- **修正:** `fish.payara.arquillian:payara-client-ee9:3.1` に変更しました。
- **変更されたファイル:** pom.xml (dependencyManagement と 5 つのプロファイル参照)
- **検証:** ✓ 成功 - Payara 6 で依存関係が正しく解決されました。

#### 問題 #3: Jakarta XML Bind API のバージョンが正しくありません。
- **エラー:** jakarta.xml.bind-api:3.11.0 が見つかりません。
- **根本原因:** sed 操作中に誤ってバージョンが変更されました。変換定義ごとに 4.0.0 である必要があります。
- **修正:** `jakarta.xml.bind:jakarta.xml.bind-api:4.0.0` に修正しました。
- **変更されたファイル:** pom.xml (239行目)
- **検証:** ✓ 成功 - Jakarta EE 10 の要件に準拠しています。

#### 問題 #4: Maven コンパイラプラグインのバージョンが正しくありません。
- **エラー:** maven-compiler-plugin:4.0.0 が見つかりません。
- **根本原因:** sed 操作中に誤ってバージョンが変更されました。バージョン 4.0.0 が存在しません
- **修正:** `maven-compiler-plugin:3.11.0` に修正しました (Java 21 互換)
- **変更されたファイル:** pom.xml (262-263 行目)
- **検証:** ✓ 成功 - Java 21 でコンパイル成功

---

### 最終ビルドステータス

**コンパイル:** ✓ **ビルド成功**
- 31 個のモジュールすべてが Java 21 でコンパイル成功
- Java バージョン: OpenJDK 21.0.9 (Corretto)
- Maven バージョン: 3.8.4
- 合計時間: 6.048 秒

**テストステータス:**
- Servlet-http2 モジュールのテスト失敗 (Arquillian 設定の問題)
- ベースラインビルドでも同じエラーが発生していました (作業ログに記録済み)
- 変換による回帰ではありません

---

### 必須の依存関係バージョン検証

すべての変換定義要件を満たしています:
- ✓ maven-compiler-plugin: 3.11.0 (Java 21 互換)
- ✓ jakarta.annotation-api: 2.1.1
- ✓ jakarta.jakartaee-api: 10.0.0
- ✓ jakarta.xml.bind-api: 4.0.0
- ✓ htmlunit: 4.0.0 (org.htmlunit グループ)
- ✓ payara-client-ee9: 3.1
- ✓ jaxb-runtime: 4.0.2

---

### ガードレール準拠

すべての修正はガードレールルールに準拠しています:
- ✓ **テストの整合性:** すべてのテストが保持され、削除または無効化されたテストはありません
- ✓ **セキュリティ:** なしセキュリティ制御が弱体化され、ハードコードされたシークレットは追加されていません。
- ✓ **API 互換性:** パブリック API 名の変更はありません。すべての変更は依存関係の更新です。
- ✓ **法的:** すべてのライセンスヘッダーは変更されずに保持されます。

---

### 変換検証

✓ **完了:** Jakarta EE 10 への移行が成功しました。
✓ **Java 21:** すべてのコードが Java 21 でコンパイルされます。
✓ **依存関係:** すべての Jakarta EE 10 依存関係が正しく構成されています。
✓ **リグレッションなし:** 新たなテスト失敗は発生していません。

Java 21 へのアップグレードを含む Java EE 8 から Jakarta EE 10 への移行は **完了し、成功しました**。

---

＜備考＞
作業中に接続が切れてしまう場面が数回ありましたが、その際は atx --resume コマンドを実行することで、直近の会話状態から作業を再開できました。
なお、AWS Transform Customは エージェントの利用時間（分単位）で課金されます。
今回の検証にかかった利用料金は、約 18 ドル（約 2,790 円）でした。

Amazon Q Developer と比較して

Amazon Q Developer の transform 機能と AWS Transform Customは一見すると似ていますが、実際に利用してみると、対応範囲や進め方にいくつか明確な違いがありました。

対応対象・範囲の拡大
Q Developer でJava と .NET のみがサポート対象でしたが、
AWS Transform Customでは Java、Node.js、Python のアップデートをサポートしています。
（※ .NET は AWS Transform for .NET が対象）
また、単なる言語アップグレードにとどまらず、
- フレームワークのアップグレード
- 言語間の移行
- プロジェクト固有の構成や仕様の理解
といった点まで考慮したうえで対応してくれます!
移行計画の提示とテスト実施
Amazon Q Developer と比較すると、AWS Transform Customでは 変換を実行する前に移行計画が提示される 点が大きな特長です。これにより、事前に「どのような作業が行われるのか」「どこが変更対象になるのか」を把握したうえで、安心して変換を進めることができます。
さらに、コード変換だけでなく テストコードの作成やデバッグまで自動で対応 してくれるため、単なる開発フェーズにとどまらず、 単体テストまで含めた一連の移行作業をカバーできる 点もメリットだと感じました。

これまでは「言語のアップグレードのみを担当するメンバー」という位置づけでしたが、AWS Transform Customは
システム全体への理解を深めたうえで、一貫したアップグレード作業を進めてくれる存在へ と進化したと言えそうです。

今後のモダナイゼーションについて

ここまで、AWSが提供するモダナイゼーション支援ツールについて紹介してきました。最後に、これらのツールを今後どのように活用していけそうかをまとめます。

実際に使ってみて、最も大きいメリットだと感じたのは 作業工数を大幅に削減できる 点です。
直近のプロジェクトで影響調査を行った際には、現行バージョンからターゲットバージョンまでのリリースノートを確認する必要があり、それだけで約 1 週間を要していました。しかし、Amazon Q Developer や AWS Transform Custom といったモダナイゼーション支援ツールを活用することで、この作業を約 1 時間まで短縮することができました!

一方で、即時に本番環境へ導入するのは難しいとも感じました。
本番コードを投入することへの セキュリティ面の不安 は残りますし、 人による丁寧なレビュー は欠かせません。あわせて、「なぜその変更を提案したのか」を理解できるような、AIの高い説明可能性も重要なポイントだと感じました。

これらを踏まえると、 AI による高速な調査・実装 を土台とし、 人のレビューによって品質を担保する ことで、安心して活用できるモダナイゼーションが実現できると実感しました。