AWS Transform Custom による Spring Boot 2.xから4.xへのVerUp

Transcript

1. AWS Transform Custom による Spring Boot 2.xから4.xへのVerUp 2026/08/08 Satoshi Kaneyasu
2. Speaker Introduction 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス本部 在住：広島 担当： PM、SM、DevOps、仕様駆動開発 SNS(X)：@satoshi256kbyte • • • • • • 2026 Japan AWS Ambassadors 2024-26 Japan AWS Top Engineers 2024-26 Japan AWS All Certifications Engineers 2025-26 AWS Community Builders 認定スクラムマスター PMP 2
3. このLTの題材 ⚫ フレームワークに破壊的な変更が入っているアプリを、AWS Transform Custom で自動バージョンアップできるのか？を検証してみました。 ⚫ LTでは小さいサンプルコードを用いた検証を紹介していますが、 実際に移行案件を行なった経験をもとにしています ⚫ サンプルはSpring Boot 2.xです。これを4.xにします ⚫ サンプルは社員のデータを扱うWebアプリケーションで、SPA ⚫ 写真のアップロード機能を有します クライアント Appサーバー Spring Boot 2.7 DBサーバー MySQL5.7 3
4. 現環境（As-Is）の技術スタック 項目 内容 言語 Java 11 フレームワーク Spring Boot 2.7系、Spring Data JPA(Hibernate)、Thymeleaf データベース MySQL 5.7 APサーバー Embedded Tomcat（Spring Boot標準） 認証方式 フォーム認証＋インメモリ管理 ログ出力方式 Logback(Spring Boot標準) ファイルストレージ ローカルストレージ 4
5. 目指す姿（To-Be）の技術スタック 項目 内容 言語 Java 25 フレームワーク Spring Boot 4.x系、Spring Data JPA(Hibernate 7)、Thymeleaf 5
6. AWS Transform CustomでVerUp自体はやり切れる ⚫ 結論から先に述べるとAWS Transform CustomでVerUp自体はやり切れました ⚫ ただし、プロンプト＞Verup＞検証＞プロンプト見直してやり直しを３回やっています ⚫ サンプルコードは約1,800行で、３回のループで費用は$15、時間は約半日でした ⚫ このコスト・所要時間から考えると、いきなり実案件で回すのは危険と思います ⚫ 小規模の検証コードでプロンプトを磨いてから実際のリポジトリに適用するといいと思います 6
7. AWS Transform Custom の設定ファイル(config.yaml) codeRepositoryPath: ./step1-legacy transformationName: AWS/spring-boot-version-upgrade buildCommand: mvn clean install validationCommands: | mvn checkstyle:check mvn verify additionalPlanContext: | 途中省略 ## 実施してほしい変更（優先度順） 1. pom.xml の spring-boot-starter-parent のバージョンを 4.1.x に更新し、 java.version プロパティを 25 に変更する 2. ソースコード全体で javax.* パッケージを jakarta.* に置換する （persistence, validation, servlet の各名前空間） 3. WebSecurityConfigurerAdapter を継承するクラスを廃止し、 SecurityFilterChain を返す @Bean メソッドへ書き換える 4. antMatchers() を requestMatchers() に、authorizeRequests() を authorizeHttpRequests() に置換し、and() チェーンをラムダDSLへ書き換える 5. Jackson の ObjectMapper 利用箇所（本体コードおよびテストコード）の import を tools.jackson.databind.ObjectMapper に更新する （アノテーションの import は変更しない） 6. MySQL Connectorの依存関係を mysql:mysql-connector-java から com.mysql:mysql-connector-j へ切り替える 7. thymeleaf-extras-springsecurity5 の依存関係を thymeleaf-extras-springsecurity6 へ 切り替え、Thymeleafテンプレート内のnamespace宣言も合わせて更新する 8. Flyway の依存関係を、flyway-core の直接依存のままにせず spring-boot-starter-flyway 経由に切り替える。 Spring Boot 4.1では flyway-core を直接依存させるだけではFlyway自体が起動せず、 アプリ起動時にテーブルが1つも作成されない（Schema validation: missing table エラーになる）ため、これは必須の変更です 9. Dockerfile のビルドステージ・実行ステージのベースイメージを、pom.xmlの java.version（25）に合わせて更新する （maven:3.9-eclipse-temurin-25 / eclipse-temurin:25-jre）。 pom.xmlだけJava 25にしてDockerfileをJava 11のまま放置すると、 コンテナビルド時に「release version 25 not supported」で失敗します 右側に続く 途中省略 ## 検証について - buildCommand・validationCommands（mvn checkstyle:check, mvn verify）を 実際に実行し、全て成功する状態まで修正を繰り返してから完了としてください。 ビルド・テストを一度も実行せずに「完了」と報告することは禁止します - checkstyle違反を消すためだけに、使っていないimport文を追加したまま 残す、あるいはテストコードを無効化・削除・skipすることで検証を 通すことは禁止します。原因そのものを修正してください （パス・リクエスト/レスポンス形式） validationCommandsと テキストで検証方法を 定めているのがポイントです 7
8. AWS Transform Custom の変換結果の例 @Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { 変換前 @Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers("/css/**", "/js/**").permitAll() .anyRequest().authenticated() .and() .formLogin() .loginPage("/login") .defaultSuccessUrl("/employees", true) .permitAll() .and() .httpBasic() .and() .logout() .logoutSuccessUrl("/login?logout") .permitAll() .and() .csrf() .ignoringAntMatchers("/api/**"); } } 変換後 @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authorize -> authorize .requestMatchers("/css/**", "/js/**").permitAll() .anyRequest().authenticated() ) .formLogin(form -> form .loginPage("/login") .defaultSuccessUrl("/employees", true) .permitAll() ) .httpBasic(httpBasic -> { }) .logout(logout -> logout .logoutSuccessUrl("/login?logout") .permitAll() ) .csrf(csrf -> csrf .ignoringRequestMatchers("/api/**") ); return http.build(); } @Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { PasswordEncoder encoder = PasswordEncoderFactories .createDelegatingPasswordEncoder(); auth.inMemoryAuthentication() .withUser("admin") .password(encoder.encode("admin123")) .roles("ADMIN"); } } @Bean public UserDetailsService userDetailsService() { PasswordEncoder encoder = PasswordEncoderFactories .createDelegatingPasswordEncoder(); var user = User.withUsername("admin") .password(encoder.encode("admin123")) .roles("ADMIN") .build(); return new InMemoryUserDetailsManager(user); } 非推奨となった WebSecurityConfigurerAdapterの 移行もできています 8
9. AWS TransformCustom で対応しきれなかったもの 項目 内容 指示見直し後再実行 で解消 Dockerfile Dockerfile のベースイメージが Java 11 のままで、pom.xml の java.version: 25 と矛盾し、コンテナビルドが失敗する ◦ 未使用のインポート SecurityConfig.java に未使用の import が残り、Checkstyleが失敗す る ◦ flyway-core の直接依存 flyway-core の直接依存のままで spring-boot-starter-flyway に切り 替わっておらず、Flyway自体が起動せずテーブルが作成されない ◦ プラグインのバージョン maven-checkstyle-pluginが3.3.1のままで、includeTestSourceRoots パラメータが認識されず警告が出ていた （テストソースがCheckstyle対象から漏れる可能性があった） ⚫ 対応できなかったものは指示を具体化して再実行かけることで成功するパターンもあります ⚫ とはいえ、細かい部分でカバーしきれないものは存在するので100％にはなり得ません ⚫ Transform customで綺麗に移行することに拘るのも効率的ではないので、 初回で対応できなかったものについて指示を具体化するか、 直接修正かけるかはコスト・スケジュールとの相談となります 9
10. AWS Transform Customでデグレ検証はできる？ ⚫ AWS Transform Customに限らず、AIにデグレ検証させるのはかなり怖いですね・・・ ⚫ 仮に移行前が自動テストがなかったとしたら、自動テストを入れるということはテストできるよ うに少なからずコードの方を寄せることになるので既存ロジックを壊す可能性が高いはず ⚫ AWS Transform Customで浮いた工数をテスト工数に当てるのが妥当ではないでしょうか？ 10
11. まとめ ⚫ AWS Transform CustomはSpring Boot 2.xから4.xのような破壊的変更を含んだVerUpも やり切れます ⚫ ただしコストと時間もそれなりにかかるので、 まずは小さめの検証コードでプロンプト磨いてから実際のリポジトリに適用するのがお勧め ⚫ AIにデグレ検証させるのは無理があるのでは・・・。現状AWS Transform Customで浮いた工 数をテスト工数に充てるぐらいがベターかと ⚫ 次のページからはおまけです 11
12. 目指す姿（To-Be）の技術スタック（全容） ⚫ 実際にはアーキテクチャ・インフラ構成の見直しも同時進行することも多いでしょうから、 それらも考えてみます 項目 内容 言語 Java ２5 フレームワーク Spring Boot 4.x系、Spring Data JPA(Hibernate 7)、Thymeleaf データベース Amazon Aurora MySQL 8.x系 APサーバー Embedded Tomcat（Spring Boot標準） 認証方式 フォーム認証＋Spring Session + Redis(Amazon ElastiCache) ログ出力方式 Logback(Spring Boot標準)＋Amazon CloudWatch Logs ファイルストレージ Amazon S3 12
13. 目指す姿（To-Be）の構成図 13
14. AWS Transform CustomとSDDを使い分ける ⚫ バージョンアップそのものではなくアーキテクチャ見直しの方は、 SDD（仕様駆動開発）を用いた方がいいと思います（バイブコーディングもあり） ⚫ AWS Transform Customでもプロンプト次第でできなくはないとは思いますが、 いかんせんアーキテクチャ見直しの方がやり取りが多いので不向きでしょう 14
15. AWS Transform customとSDDを組み合わせたWBS WBS 開発手法・アプローチ 役割分担 SDD（仕様駆動開発） • • • 人間が既存情報を収集 AIがコード生成 人間がレビュー ローカル実行基盤の作成 （Docker Compose等） SDD（仕様駆動開発） • • • 人間が既存情報を収集 AIがコード生成 人間がレビュー Java 11→25 アップグレード AWS Transform Custom • • AIが自動変換 人間がレビュー Spring Boot 2.x→4.x アップグレード AWS Transform Custom • • AIが自動変換 人間がレビュー Transform customで変換しきれない 箇所の修正 SDD（仕様駆動開発） • • AIがコード生成 人間がレビュー 新アーキテクチャのIaC作成 （ユニットテスト込み） SDD（仕様駆動開発） • • AIがコード生成 人間がレビュー ファイルストレージのS3化 SDD（仕様駆動開発） • • AIがコード生成 人間がレビュー セッション・キャッシュの外部化 SDD（仕様駆動開発） • • AIがコード生成 人間がレビュー DB接続情報の取得方法の変更 SDD（仕様駆動開発） • • AIがコード生成 人間がレビュー 画面側のファイルパス・画像パス生成の変更 SDD（仕様駆動開発） • • AIがコード生成 人間がレビュー 既存アプリのコンテナ化 15