大規模JavaアプリケーションのアップデートにAmazon Q Developerを適用してみた（transform編）

はじめに

こんにちは、サウナ出た途端に次行きたいサウナを探し始めてしまう、ぬまです。最近とあるプロジェクトでAmazon Q Developer transformを使用してアプリケーションのアップデートを行いました。今回はそのAmazon Q Developer transformを実務に適用して学びがたくさんありましたので、皆さんに紹介したいと思い、この記事を書きました。

Amazon Q Developer transformとは

Amazon Q Developer transformとは、Amazon Q Developerと呼ばれる生成人工知能 (AI) を活用した会話アシスタントサービスの一つであり、 アプリケーションの言語の自動アップグレードを実行できる機能の一つです。
2025年5月現在、transformでサポートされている言語としましては、

• Java
• SQL
• C#/.NET アプリケーション

となります。（ユーザーガイドより）

Amazon Q Developer の他の機能についても知りたい方はこちらの記事をご覧ください。

【re:Invent 2024 現地レポート】Amazon Q Developerの新機能紹介

今回のプロジェクトの概要

Amazon Q Developer transform適用対象のプロジェクトについて技術スタックを簡単にご説明いたします。

• ECS
  • コンテナ化されたSpring FrameworkのJavaアプリケーション
  • Java 7 → Java 17へのアップデートを予定
  • APIやBatchなど多数存在
• ElasticSearch
  • JavaアプリケーションからCRUD処理が行われる
  • Javaのアップデートに合わせ1系から8系のアップデートを予定
• RDS
  • JavaアプリケーションからCRUD処理が行われる
  • MySQLバージョンは現行の8系を採用（変更なし）

transform適用時の気をつけなければいけない点

上記でご説明したプロジェクトで適用に至った訳ですが、いくつかの注意事項があります。
今回、我々が遭遇した点について順を追って説明していきます。

transformがサポートされているJavaのバージョン

まずは、 transformによってJavaを任意のバージョンに変換できるというわけではないという点です。

2025年5月現在、サポートされているJavaのバージョンが次のようになっています。（ユーザーガイドより）

つまりここに書かれていない（選択できない）バージョン間のtransformは現在サポート外です。
変換前後のバージョンを決められているため、Java 8 →Java11といったアップグレードも不可となります。

また、これらは統合開発環境（IDE）でサポートされているリストになっています。
直近リリースされたAmazon Q Developer in GitHubにもtransform機能が備わっていますが、こちらは（変換前）Java 8, Java11 → （変換後）Java 17のアップデートのみがサポートされています。
リンクにも掲載されている通り、今後サポートバージョンが更新される可能性はありますが、現在のサポートバージョンがご自身のワークロードに適しているか判断が必要です。

今回のプロジェクトでは、IDE上でJava 7をJava 17にアップデートを考えていましたので、変換前のバージョンがサポートされていなかったため、

1. 手動でJava 7からJava 8にアップデート
2. transform機能でJava 8からJava 17にアップデート

の方法を採用しました。

transform適用開始時の画面

このように、変換前後のバージョンをプルダウンから選択していきます。

プロジェクトのソースコードに対応した JDK がローカルにインストールされている必要がある

例えば、Java 8 コードを変換する場合だとローカルの JDK インストールは JDK 8 である必要があります。
以下の画像のようにプロジェクトのtransform設定をチャットに従って選択しておくと、JDK Pathの入力を求められます。

これは、Amazon Qがtransformのプロセスでビルドを行うためです。
担当開発者であれば、インストールが事前にお済みの場合がほとんどとは思いますが、Amazon Q Developerのセットアップだけでなく、Javaのセットアップも必要になる点に注意が必要です。

また、それに付随して変換前のソースコードが正常にビルドできるというのも前提条件になります。正常にビルドが通らないうちはDev機能を活用して開発するのが良いと思います。

今回のプロジェクトでは、アサインされたばかりで、まだJavaのセットアップが済んでいないメンバーもいました。

そのためVSCodeの拡張機能のDevContainerを利用しました。JDK8のDockerfileを配布し、DevContainer内でAmazon Q transformを実行することで、こちらの問題をクリアしました。（DevContainer内でもAmazonQの拡張機能は機能します）

プロジェクトサイズに2GBの上限がある

前提としてtransform機能は、プロジェクト全体に動作します。プロジェクトのディレクトリ配下にある全てのファイル（ソースファイル以外も含む）がサイズとしてカウントされます。

今回transform適用プロジェクトは2GBを超えてしまっていたため、transformする前にサイズを小さくする必要がありました。

コードを変換するために、Amazon Q はソースコード、プロジェクトの依存関係、ビルドログを含むプロジェクトアーティファクトを生成します。変換ジョブのプロジェクトアーティファクトサイズの上限は 2 GB です。プロジェクトアーティファクトのサイズに関連するエラーが発生した場合は、プロジェクトのサイズを小さくするか、より小さなプロジェクトを変換する必要があります。プロジェクトアーティファクトファイルのサイズは、コード変換ログで確認できます。詳細については、コード変換ログにアクセスするにはどうすればよいですか?を参照してください。

Amazon Q Developer　ユーザーガイドより

今回のプロジェクトでは、「プロジェクトサイズを小さくする」かつ「ビルド時間を短縮する」ために、次のようにプロジェクトを切り出してtransformを適用しました。

• API モジュール + 共通のビジネスロジック + POM.xml(ライブラリ依存ファイル) → 一つのプロジェクトとしてtransformを適用
• Batchモジュール + 共通のビジネスロジック + POM.xml(ライブラリ依存ファイル) → 一つのプロジェクトとしてtransformを適用

共通のビジネスロジックを2度transformしているので冗長にも感じるかもしれませんが、変換前のソースコードが正常にビルドできるという条件をクリアする最も手軽な最小構成がこれでした。

また、「ビルド時間を短縮する」という理由については考察の章で後述します。

変換中にIDEから離れると再スタートが必要になる

これは補足的な注意点ですが、変換中にIDEを閉じてしまったりクラッシュすると再度初めからtransformを実行する必要があります。
transformには最大55分要しますので、意図的に閉じたりしてしまわぬようご注意ください。

私もtransform開始から50分経過がした段階で、誤って閉じてしまいその時の作業が水の泡になってしまいました・・・。

もしもGitHubでプロジェクト運用しているのでしたら、IDE上ではなく、Amazon Q Developer in GitHubのtransformを利用してみるのも良いと思います。 GitHubのWebUI上でtransformが実行でき、PullRequestまで作成してくれます。
IDEの状態（閉じてしまった等）に影響されず、さらにはローカルへのJDKインストールも不要です。IDEより手軽にtransformできるのではないかと思います。

変換結果(コード付き)

今回、transformを実行した結果、適切に変換されたケースとそうでなかったケースがございましたので、ご紹介いたします。機密情報の観点からサンプルコードに置き換えます。

上手くいったケース1

1// Java 8 
2public EntityNew getEntity(String id) {
3    return entityNewRepository.getOne(id);
4}
5
6// Java 17 
7public EntityNew getEntity(String id) {
8    return entityNewRepository.getReferenceById(id);
9}

変更点解説

getOne()はJPA 2.0 以前で一般的に使われていましたが、現在は非推奨（Deprecated）になっています。
getReferenceById() は JPA 2.1 以降での推奨されるメソッドで、遅延読み込み（lazy loading）に対応しています。

Java17へのアップグレードによって、使用ライブラリのバージョンも上がったため、今回のようなtransformが行われました。

上手くいったケース2

1//Java 8
2import javax.validation.Validator;
3
4// Java 17
5import jakarta.validation.Validator;

変更点解説

javax から jakarta へパッケージ名が変更されたため、それに伴って、import文も変換されました。

上手くいかなかったケース

1// Java 7
2public Page<T> search(SearchQuery searchQuery) {
3       return elasticsearchTemplate.queryForPage(searchQuery, SampleIndex.class, new SearchResultMapper());
4}
5   
6// Java 17
7public SearchHits<T> search(NativeQuery nativeQuery) {
8   return elasticsearchOperations.search(nativeQuery, SampleIndex.class);
9}

変更点解説

Spring Data Elasticsearch のバージョンアップに伴うAPI変更への対応です。
Spring Data Elasticsearch 4.x以降、ElasticsearchTemplate は 非推奨または削除され、ElasticsearchOperations を使うように変更されました。

考察

Spring Frameworkのtaransformがされないまま出力されてしまいましたが、こちらのユーザーガイドにも対象フレームワークと記されているため、変換されると思います。

ではなぜ今回うまく変換されなかったのかと言いますと、

• ビルド時間が長すぎる
• １つのプロジェクトのコード量が多すぎる

ことだと思います。

transform実行サイクルをユーザーガイドや、実行時のログから確認すると以下のようになっていることがわかります。

このように55分という制限時間の中で、ビルドとエラー修正を繰り返しtransformを完成させます。仮に途中で制限時間が来てしまうと、その時のアーティファクトが出力されます。今回はこのケースに遭遇してしまったのだと思います。

そのため、以下のように何度もビルドとエラー修正のサイクルが回るようにビルド時間の調整とコード量の調整 が必要になってくると利用して感じました。

まとめ

今回、Amazon Q Developer transformを実際のアプリケーションに適用することで、ツールの特性や限界、そして実運用で気をつけるべき点を多く学ぶことができました。
特に、変換対象のバージョンやプロジェクトサイズの制限、ビルド時間の考慮など、導入前に確認しておくべきポイントが多く存在することが分かりました。

この半年の間にもAmazon Q Developerは着実に進化しており、今後のアップデートによってさらに実用的で柔軟なツールへと進化していくことが期待されます。

とはいえ、AIを導入すればすべてが自動化・解決されるわけではありません。
AIの特性や挙動を理解し、人間側がうまく設計・調整していくことで、初めてその効果を最大限に発揮できます。
AIの力を引き出してうまく活用する開発スタイルを目指していきたいと思います。

numa