// JAVA / SPRING BOOT / MIGRATION

Spring Boot 2.x → 3.x / Java 21 移行完全技術ガイド——金融系システムの本番適用に向けた詳細手順と落とし穴

📅 2025年4月24日 ⏱ 読了約14分 ✍ DataOne Tech 編集部
Spring Boot 2.x → 3.x / Java 21 移行完全技術ガイド——金融系システムの本番適用に向けた詳細手順と落とし穴

Spring Boot 2.7のEOL(End of Life)は2023年11月に到達した。セキュリティパッチを受けられない状態でエンタープライズシステムを稼働させることは、金融庁・ISMAP等の規制要件に照らして受け入れられないリスクだ。しかしSpring Boot 2.x→3.xは「バージョンアップ」ではなく「移行」だ。本稿では、DataOneが複数の金融系Java案件で実施した移行プロジェクトの詳細技術知見を公開する。

移行の前提条件:Java 17以上が必須

Spring Boot 3.xはJava 17以上を要求する(LTS版推奨:Java 17・21)。Java 11からJava 17への移行も並行して実施する必要があり、これが移行工数を増大させる要因の一つだ。

推奨移行パス:
1. Java 11 + Spring Boot 2.5.x → Java 11 + Spring Boot 2.7.x(まず2.7に上げて非推奨APIを全てなくす)
2. Java 11 + Spring Boot 2.7.x → Java 17 + Spring Boot 2.7.x(JVMのみ更新)
3. Java 17 + Spring Boot 2.7.x → Java 17 + Spring Boot 3.x(フレームワーク移行)
4. Java 17 + Spring Boot 3.x → Java 21 + Spring Boot 3.2+(Virtual Threads活用)
一気に飛ばすと問題の切り分けが困難になる。段階的に実施すること。

破壊的変更1:javax.* → jakarta.* 名前空間(最大の工数)

Java EE APIがjakarta.* に移行したことに伴い、全てのimport文の更新が必要だ。IntelliJ IDEA / Eclipse の「Replace in Files」で機械的に置換できるが、依存ライブラリ側の対応確認が最も重要だ。

// 主な変換パターン javax.persistence.* → jakarta.persistence.* javax.validation.* → jakarta.validation.* javax.servlet.* → jakarta.servlet.* javax.annotation.* → jakarta.annotation.* (一部は変更不要) javax.transaction.* → jakarta.transaction.* // 注意: javax.sql.* は変更不要(java.sql.* の下位API)

依存ライブラリの対応確認マトリクス

Spring Boot 3.x 対応が必要な主要依存:
· Hibernate ORM: 6.x 以上(4.x・5.x は jakarta 非対応)
· QueryDSL: 5.0.0 以上(jpa-apt を querydsl-jpa の jakarta 版に変更)
· MapStruct: 1.5.3 以上
· Swagger/SpringDoc: springdoc-openapi 2.x に移行(springfox は Jakarta 非対応のため廃止)
· MyBatis: 3.5.11 以上
· Thymeleaf: 3.1.x 以上(バンドル版は自動更新される)

破壊的変更2:SecurityConfig の完全書き直し

WebSecurityConfigurerAdapterが廃止された。SecurityFilterChain の Bean 定義スタイルに移行する必要がある。

// 旧 Spring Boot 2.x スタイル(動かない) @Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.authorizeRequests().antMatchers("/public/**").permitAll() .anyRequest().authenticated(); } } // 新 Spring Boot 3.x スタイル @Configuration @EnableWebSecurity public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.authorizeHttpRequests(auth -> auth .requestMatchers("/public/**").permitAll() .anyRequest().authenticated()) .csrf(csrf -> csrf.csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())); return http.build(); } }
金融系システムの注意点:Security設定の変更は認証・認可・CSRF・セッション管理に直接影響します。移行後は必ずペネトレーションテスト相当のセキュリティ検証を実施してください。特にantMatchers()からrequestMatchers()への変更は、マッチングルールが微妙に異なるため、意図しない権限付与が発生するリスクがあります。

破壊的変更3〜8(重要度順)

3. Spring Data JPA のデフォルト変更:LazyLoading の挙動が変わりN+1問題が顕在化するケースあり。全Entity のFetch戦略を明示的に指定すること。

4. Spring MVC のパスマッチング戦略変更:AntPathMatcherからPathPatternParserへ。末尾スラッシュのマッチングが変わる。/api/users/ と /api/users が別扱いになる。

5. Actuator のデフォルト設定変更:/actuator/health 等が認証なしでアクセスできなくなった。監視ツールの設定確認が必要。

6. Logging変更:Logback 1.4.x に更新。一部のlog4j互換性APIが変更。

7. Circular Bean References のデフォルト無効化:Spring Boot 3.0 から循環依存がデフォルトでエラーになった。設計上の問題として改修推奨。

8. Spring Batch 5の破壊的変更:バッチ処理を使っている場合、JobParametersの型が変わるため移行工数が増大する。

Java 21 Virtual Threads:ATMシステムでの実測値

Spring Boot 3.2以降で利用可能なspring.threads.virtual.enabled=trueを、DataOneがATM照会APIに適用した実測値を公開する。

3.2×
スループット向上
(1000並行リクエスト)
-68%
メモリ使用量
(同一スレッド数比)
+0ms
p95レイテンシ
への影響
Pinning問題:synchronized ブロック内でブロッキングI/Oを行うとVirtual Threadsの恩恵が失われます(Pinning)。-Djdk.tracePinnedThreads=full でスタックトレースを確認し、synchronizedをReentrantLockに置き換えること。Spring Framework本体は6.1以降でPinningを解消済みですが、サードパーティライブラリは個別確認が必要です。
⚠ 免責事項:本記事は情報提供を目的としており、特定のシステム・製品・サービスの導入を保証・推奨するものではありません。技術情報は執筆時点のものであり、ソフトウェアのバージョンアップや規制変更により内容が変わる場合があります。実際の導入・設計判断は、貴社の要件・環境・リスク許容度に基づき、専門家の助言を得た上で行ってください。
DataOneにご相談ください
技術的な課題・採用・システム開発の相談を承ります。