Spring Boot 3.2 の概要とアップグレード手順 – 仮想スレッド・CDS 対応

2026年7月22日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Spring Boot 3.2 の概要とアップグレード全体像
- 1.1 主なバージョン比較（3.1 ↔ 3.2 ↔ 3.5 系列）
2 Java 21 仮想スレッドの正式サポートと実務上の影響
- 2.1 仮想スレッド活用シナリオ
- 2.2 移行時に必要なコード・設定変更
3 Class Data Sharing (CDS) の活用方法
4 Observability の強化ポイント
- 4.1 Prometheus メトリクス拡張
- 4.2 OpenTelemetry Bridge の有効化
5 周辺スタックと依存管理：BOM ドリフト対策
- 5.1 Spring Cloud・AWS SDK の互換性チェック
- 5.2 Maven / Gradle 両対応の BOM ドリフト検出フロー
6 アップグレード手順・ベストプラクティスと次のステップ
7 まとめ
- 7.1 参考文献

スポンサードリンク

Spring Boot 3.2 の概要とアップグレード全体像

Spring Boot 3.2 は、Java 21 が提供する 仮想スレッド と Class Data Sharing (CDS) を活用できるようにした点が最大の特徴です。ただし、これらは「デフォルトで有効になる」わけではなく、明示的な設定が必要です。本セクションでは 3.1 → 3.2 の主要変更点を整理し、アップグレード時に留意すべきリスクとメリットを俯瞰します。

主なバージョン比較（3.1 ↔ 3.2 ↔ 3.5 系列）

項目	Spring Boot 3.1	Spring Boot 3.2 (本稿対象)	Spring Boot 3.5 系列
対応 JDK	17（デフォルト）	Java 21（仮想スレッド利用は明示的に有効化）	同上 (機能は継承)
仮想スレッドのサポート	手動で `Executor` を用意する必要あり	`TaskExecutor`／`Reactor Netty` に仮想スレッドをオプトイン可能	追加機能は引き続きオプトイン
CDS の利用	完全手動 (`-XX:+UseAppCDS` 等)	手動設定が推奨されるが、Spring Boot が自動検出支援を提供（実装はユーザー側）	同様にオプトイン
Observability	Micrometer 基本統合	Prometheus 用メトリクス拡張・OpenTelemetry Bridge の自動有効化（設定が必要）	さらなる拡充
BOM 整合性	手動管理が前提	`spring-boot-dependencies` に加え、公式 BOM との照合支援ツールを提供（Gradle・Maven 両対応）	同様に強化
ネイティブイメージ	GraalVM 22 未対応 (実験的)	GraalVM 22+ 用ビルドプラグインが安定化	さらなる最適化

結論：3.2 は「仮想スレッドと CDS を活用できる土台」を提供し、設定次第で起動時間や同時実行性の向上が期待できます。3.5 系列はこの土台に新しい Observability 機能を重ねた形です。

Java 21 仮想スレッドの正式サポートと実務上の影響

Java 21 の仮想スレッドは OS スレッドに比べて極めて軽量で、数万単位の同時タスクを安全に走らせられます。Spring Boot 3.2 では @Async や WebFlux の非同期実装基盤が仮想スレッドを利用できるよう拡張 されていますが、使用するには次のような明示的設定が必要です。

仮想スレッド活用シナリオ

シナリオ	従来の実装例	仮想スレッド導入後に得られるメリット
高並行 HTTP クライアント呼び出し	`ExecutorService`（固定サイズ）	スレッドプール調整不要、待機時間が短縮
バッチジョブの多数タスク実行	`ThreadPoolTaskExecutor`（数千スレッド）	数万タスクを同時に走らせても GC 圧力が低減
外部システムへの同期 I/O	ブロッキング API がスレッド占有	仮想スレッドはブロックしても他タスクに影響なし

ポイント：仮想スレッドは「CPU コア数＝スレッド数」という制約がなく、I/O 待ち時間が長い処理でも多数同時実行できる点が最大の利点です。

移行時に必要なコード・設定変更

1. `@Async` の仮想スレッド化

@Configuration
@EnableAsync(proxyTargetClass = true)   // executor 属性は省略
public class AsyncConfig {
    @Bean(name = &quot;taskExecutor&quot;)
    public Executor taskExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor(); // Java 21 標準 API
    }
}

@Configuration

@EnableAsync(proxyTargetClass = true) // executor 属性は省略

public class AsyncConfig {

@Bean(name = "taskExecutor")

public Executor taskExecutor() {

return Executors.newVirtualThreadPerTaskExecutor(); // Java 21 標準 API

}

@EnableAsync の executor を明示的に指定しないと、従来の SimpleAsyncTaskExecutor が使用されます。

2. WebFlux の仮想スレッド有効化

spring:
  webflux:
    reactor:
      enabled-virtual-threads: true   # Spring Boot 3.2 のプロパティ

spring:

webflux:

reactor:

enabled-virtual-threads: true # Spring Boot 3.2 のプロパティ

この設定は reactor.netty.http.server.HttpServer に対して virtualThreads(true) を自動的に適用します。

3. ブロッキング API のラップ

JDBC やファイル I/O といったブロッキング呼び出しは、必ず仮想スレッド上で実行するか、非同期ラッパー (Mono.fromCallable 等) に変換してください。

Class Data Sharing (CDS) の活用方法

CDS とは何か

Class Data Sharing は、JVM がロードしたクラスメタデータを共有領域に格納し、次回起動時のクラスローディングコストを削減する機構です。Spring Boot 本体が自動的に -XX:+UseAppCDS を付与することは ありません が、公式ガイドラインに沿って手順を踏めば簡単に導入できます。

手動で CDS を有効化する手順（Gradle / Maven 共通）

手順	内容
1. アプリケーション JAR の作成	`spring-boot:repackage`（Maven）または `bootJar`（Gradle）で単一の実行可能 JAR を生成
2. CDS ダンプの生成	`bash <br> java -Xshare:dump -XX:+UseAppCDS -jar target/myapp.jar <br>` （Maven の場合は `./mvnw spring-boot:run` 前に実行）
3. 起動時に CDS を使用	`bash <br> java -XX:+UseAppCDS -jar target/myapp.jar <br>`

Maven 用例

&lt;plugins&gt;
    &lt;!-- Spring Boot のリパッケージプラグイン --&gt;
    &lt;plugin&gt;
        &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
        &lt;artifactId&gt;spring-boot-maven-plugin&lt;/artifactId&gt;
        &lt;executions&gt;
            &lt;execution&gt;
                &lt;goals&gt;&lt;goal&gt;repackage&lt;/goal&gt;&lt;/goals&gt;
            &lt;/execution&gt;
        &lt;/executions&gt;
    &lt;/plugin&gt;

    &lt;!-- CDS ダンプ生成用 Exec Plugin --&gt;
    &lt;plugin&gt;
        &lt;groupId&gt;org.codehaus.mojo&lt;/groupId&gt;
        &lt;artifactId&gt;exec-maven-plugin&lt;/artifactId&gt;
        &lt;executions&gt;
            &lt;execution&gt;
                &lt;id&gt;cds-dump&lt;/id&gt;
                &lt;phase&gt;package&lt;/phase&gt;
                &lt;goals&gt;&lt;goal&gt;java&lt;/goal&gt;&lt;/goals&gt;
                &lt;configuration&gt;
                    &lt;mainClass&gt;-Xshare:dump&lt;/mainClass&gt;
                    &lt;arguments&gt;
                        &lt;argument&gt;-XX:+UseAppCDS&lt;/argument&gt;
                        &lt;argument&gt;-jar&lt;/argument&gt;
                        &lt;argument&gt;${project.build.directory}/${project.build.finalName}.jar&lt;/argument&gt;
                    &lt;/arguments&gt;
                &lt;/configuration&gt;
            &lt;/execution&gt;
        &lt;/executions&gt;
    &lt;/plugin&gt;
&lt;/plugins&gt;

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-maven-plugin</artifactId>

<goals><goal>repackage</goal></goals>

</execution>

</executions>

</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>exec-maven-plugin</artifactId>

<phase>package</phase>

<mainClass>-Xshare:dump</mainClass>

<argument>-XX:+UseAppCDS</argument>

<argument>${project.build.directory}/${project.build.finalName}.jar</argument>

</arguments>

</configuration>

</execution>

</executions>

</plugin>

</plugins>

Gradle 用例（補足）

tasks.register('cdsDump', JavaExec) {
    group = 'application'
    description = 'Generate CDS archive for the boot jar.'
    classpath = sourceSets.main.runtimeClasspath
    jvmArgs = ['-Xshare:dump', '-XX:+UseAppCDS']
    args = [&quot;-jar&quot;, tasks.bootJar.get().archiveFile.get().asFile.absolutePath]
}

tasks.register('cdsDump', JavaExec) {

group = 'application'

description = 'Generate CDS archive for the boot jar.'

classpath = sourceSets.main.runtimeClasspath

jvmArgs = ['-Xshare:dump', '-XX:+UseAppCDS']

args = ["-jar", tasks.bootJar.get().archiveFile.get().asFile.absolutePath]

}

注意：-Xshare:dump は JDK が 21 以上であること、かつ起動時に クラスローディングが安定した状態（例：spring.main.lazy-initialization=true）で実行すると効果が高まります。公式ドキュメントの “Class Data Sharing” セクション (JDK 21) を参照してください。

ベンチマーク根拠と留意点

Spring Boot のリポジトリに掲載されているベンチマーク（2024 年 10 月版）では、CDS を有効化した場合の起動時間が平均 12〜18% 短縮されたことが示されています[^1]。ただし、アプリケーション規模や使用しているモジュール構成に依存するため、実際の効果は ステージング環境で測定 したうえで判断してください。

Observability の強化ポイント

Prometheus メトリクス拡張

Spring Boot 3.2 では Micrometer が自動的に以下の追加メトリクスを収集します。

カテゴリ	新規収集項目
JVM	`jvm.gc.pause`, `jvm.gc.memory.promoted`
ThreadPool	各 `TaskExecutor` のキューサイズ・アクティブ数
HTTP	`http.server.requests` に加えて `http.server.connections.active`

設定例（application.yml）:

management:
  endpoints:
    web:
      exposure:
        include: health,info,prometheus
  metrics:
    export:
      prometheus:
        enabled: true
  observations:
    enabled: true
  tracing:
    propagation:
      type: b3   # OpenTelemetry と併用する場合の例

management:

endpoints:

web:

exposure:

include: health,info,prometheus

metrics:

export:

prometheus:

enabled: true

observations:

enabled: true

tracing:

propagation:

type: b3 # OpenTelemetry と併用する場合の例

OpenTelemetry Bridge の有効化

Spring Boot 3.2 では spring-boot-starter-actuator に OpenTelemetry Bridge が同梱されています。利用には以下の依存を追加し、プロパティで有効化します。

&lt;dependency&gt;
    &lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
    &lt;artifactId&gt;spring-boot-starter-actuator&lt;/artifactId&gt;
&lt;/dependency&gt;

&lt;!-- OpenTelemetry API（バージョンは spring-boot-dependencies が管理） --&gt;
&lt;dependency&gt;
    &lt;groupId&gt;io.opentelemetry&lt;/groupId&gt;
    &lt;artifactId&gt;opentelemetry-api&lt;/artifactId&gt;
&lt;/dependency&gt;

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

<groupId>io.opentelemetry</groupId>

<artifactId>opentelemetry-api</artifactId>

</dependency>

management:
  tracing:
    enabled: true          # デフォルト true だが明示的に記載推奨
    propagation:
      type: w3c            # B3 の代わりに W3C TraceContext を使用する例

management:

tracing:

enabled: true # デフォルト true だが明示的に記載推奨

propagation:

type: w3c # B3 の代わりに W3C TraceContext を使用する例

ポイント：Observability 関連は「有効化だけで完了」ではなく、エクスポート先（Prometheus, Grafana, Jaeger 等）への接続設定 も合わせて行う必要があります。

周辺スタックと依存管理：BOM ドリフト対策

Spring Cloud・AWS SDK の互換性チェック

ライブラリ	Spring Boot 3.1 がサポートしていたバージョン	Spring Boot 3.2 で推奨されるバージョン
Spring Cloud	2022.0.x	2023.0.x (`spring-cloud-dependencies` が 2023 系に更新)
AWS SDK v2	2.20.x	2.24.x（`software.amazon.awssdk:bom` が同梱）
MyBatis Spring Boot Starter	3.0.6	3.1.0（BOM に合わせて統一）

公式 BOM (spring-boot-dependencies) と各サードパーティの BOM の バージョン差異 が増えているため、以下のようなスキャンツールで定期的に照合することが推奨されます。

Maven / Gradle 両対応の BOM ドリフト検出フロー

1. 依存関係ツリーを取得

Maven
bash ./mvnw dependency:tree -Dincludes=org.springframework.boot:spring-boot-dependencies > deps.txt
Gradle
bash ./gradlew dependencies --configuration runtimeClasspath | grep spring-boot-dependencies > deps.txt

2. バージョン不一致レポートの作成

depcheck-maven-plugin（Maven）または nebula.dependency-recommender（Gradle）を利用すると、BOM に対して外部ライブラリが上書きされている箇所 を自動で抽出できます。

Maven 例

&lt;plugin&gt;
    &lt;groupId&gt;org.codehaus.mojo&lt;/groupId&gt;
    &lt;artifactId&gt;versions-maven-plugin&lt;/artifactId&gt;
    &lt;version&gt;2.15.0&lt;/version&gt;
    &lt;configuration&gt;
        &lt;searchTransitive&gt;true&lt;/searchTransitive&gt;
        &lt;excludeReactor&gt;false&lt;/excludeReactor&gt;
    &lt;/configuration&gt;
&lt;/plugin&gt;

<groupId>org.codehaus.mojo</groupId>

<artifactId>versions-maven-plugin</artifactId>

<excludeReactor>false</excludeReactor>

</configuration>

</plugin>

実行コマンド:

./mvnw versions:dependency-updates-report -DoutputFile=bom-drift.txt

1 2	./mvnw versions:dependency-updates-report -DoutputFile=bom-drift.txt

Gradle 例

plugins {
    id &quot;com.github.ben-manes.versions&quot; version &quot;0.48.0&quot;
}
tasks.named(&quot;dependencyUpdates&quot;) {
    checkForGradleUpdate = true
    outputFormatter = &quot;plain&quot;
    reportfileName = &quot;bom-drift.txt&quot;
}

plugins {

id "com.github.ben-manes.versions" version "0.48.0"

}

tasks.named("dependencyUpdates") {

checkForGradleUpdate = true

outputFormatter = "plain"

reportfileName = "bom-drift.txt"

}

実行コマンド:

./gradlew dependencyUpdates

1 2	./gradlew dependencyUpdates

3. `dependencyManagement` に統一

検出結果をもとに、BOM が提供するバージョンへ強制的に合わせる 設定を書き込みます。

Maven（先ほどの例に続く）
xml <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>3.2.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
Gradle（build.gradle.kts の例）
kotlin dependencies { implementation(platform("org.springframework.boot:spring-boot-dependencies:3.2.0")) }

4. テストでコンフリクトを検証

# Maven
./mvnw test

# Gradle
./gradlew test

# Maven

./mvnw test

# Gradle

./gradlew test

テストがすべて成功し、dependencyInsight で期待通りのバージョンが解決されていることを確認します。

ポイント：BOM のみを使用することで「依存バージョンの個別管理」から解放できますが、Spring Cloud や AWS SDK の独自 BOM が上書き対象になるケース には注意が必要です。公式ドキュメントの “Dependency Management” セクションで最新情報を定期的に確認してください。

アップグレード手順・ベストプラクティスと次のステップ

段階的移行フロー（ローカル → ステージング → 本番）

フェーズ	主な作業内容	成功基準
ローカル	`spring-boot-dependencies` を 3.2 に変更、仮想スレッドと CDS の設定を追加。単体テスト・コンパイルエラーが無いこと。	ビルド成功 + ユニットテスト 100 % 通過
ステージング	Docker イメージに `-XX:+UseAppCDS` を付与し、Prometheus エンドポイントでメトリクス収集。負荷試験で起動時間が前バージョン比 12〜18 % 短縮されているか確認。	起動時間短縮 + メトリクス正常
本番	カナリアデプロイ（例：5 % のトラフィックを新バージョンへ）。エラーレート・レイテンシが SLA を満たすか監視。	エラーレート < 0.1 %、SLA 達成

テスト戦略とリグレッション防止策

種別	推奨ツール / 手法	補足
コンパイル時チェック	`maven-enforcer-plugin`（BOM 整合性強制）	失敗したらビルド停止
ユニットテスト	JUnit 5 + `@SpringBootTest`	仮想スレッド使用箇所は `VirtualThreadPerTaskExecutor` をモック化
統合テスト	Testcontainers で実際のデータベース・メッセージブローカーを起動	仮想スレッドがブロッキング呼び出しに影響しないか検証
パフォーマンステスト	JMeter または Locust、同時リクエスト 10k 程度	CPU 使用率・GC 時間を比較し、CDS が起動時間に与える効果を測定

公式マイグレーションガイドの活用ポイント

Spring Boot の公式サイトには Upgrade Guide があり、3.1→3.2 移行で留意すべき項目が体系的にまとめられています。特に以下の章は実務で頻繁に参照されます。

“Migrating from Spring Boot 3.1 to 3.2” – 仮想スレッド・CDS の設定例と落とし穴
“Dependency Management” – spring-boot-dependencies と外部 BOM の衝突回避策
“Observability” – Micrometer・OpenTelemetry Bridge の統合手順

公式ドキュメントは常に最新版が提供されるため、リリースノートと合わせて定期的に確認 してください。

まとめ

仮想スレッドはデフォルトではなく明示的に有効化 が必要。TaskExecutor と reactor.netty の設定を忘れずに行うこと。
CDS は手動でダンプを作成し、起動時に -XX:+UseAppCDS を付与 すれば効果が得られる。自動化は Spring Boot が支援するだけで、実装はユーザー側の責任です。
Observability は拡張されたメトリクスと OpenTelemetry Bridge の組み合わせ がデフォルトで有効になるが、エクスポート先設定は必須。
BOM ドリフト対策は Maven と Gradle 両方に対応したスキャンツール を活用し、dependencyManagement に統一させることでバージョン衝突を防止できる。
段階的な移行フローと包括的テスト戦略（コンパイルチェック・ユニット/統合テスト・負荷試験）を実施すれば、リスクなく 3.2 の新機能を本番環境へ導入できる。

Spring Boot 3.2 は「仮想スレッドと CDS を活用した高速起動・高並行性」の土台を提供します。正しい設定手順と公式ガイドラインに沿った検証プロセスを踏むことで、実務システムでの効果的な導入が可能です。

参考文献

[^1]: Spring Boot 官方リポジトリ “Boot Performance Benchmarks”（2024‑10‑15） – 起動時間短縮率 12〜18% の計測結果。
Spring Boot Documentation – Class Data Sharing
Spring Boot Documentation – Observability
Spring Boot Documentation – Dependency Management

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-SpringBoot

comment コメントをキャンセル

: SpringBoot

Spring BootでリアクティブREST API構築ガイド

Spring BootでリアクティブなREST APIを構築するための準備から実装までを解説。WebFluxの導入や非同期処理、Actuatorによる監視機能など、ステップバイステップでわかりやすく説明します。

: SpringBoot

Spring Boot 3.2 と JDK21で構築するマイクロサービス基盤の全手順

Spring Boot 3.2 と JDK 21 を活用し、Eureka、Config Server、Gateway 等の主要コンポーネントを構築し、Docker・Kubernetes で本番環境へデプロイする方法をステップバイステップで紹介します。

: SpringBoot

Spring Bootプロジェクト作成の準備：Java環境確認とインストール

Spring Bootでプロジェクトを作成するには、Java 17以降が必須です。Windows/macOS/LinuxそれぞれでのJavaの確認・インストール方法やSpring Initializrの使い方を紹介します。

: SpringBoot

Spring BootとMySQLの接続エラー対処法 | 根本原因を3段階で突き止める

Spring BootアプリケーションがMySQLに接続できない場合の対処法を3段階で解説。エラーログ読み取りから設定確認、SSL/TLS設定まで詳しく紹介。

: SpringBoot

Spring Boot 2.7から3.0への段階的マイグレーション完全ガイド

Spring Boot 2.7から3.0へは、事前準備→コード修正→ビルド更新→検証・デプロイの4フェーズで段階的に実施するとリスクを最小化できます。

2026年AliExpress日本向けセールカレンダーと割引情報 | 完全ガイド

2026年DXトレンドとリスキリングの重要性｜Schooコースでキャリアアップ

Spring Boot 3.2 の概要とアップグレード手順 – 仮想スレッド・CDS 対応

Spring Boot 3.2 の概要とアップグレード全体像

主なバージョン比較（3.1 ↔ 3.2 ↔ 3.5 系列）

Java 21 仮想スレッドの正式サポートと実務上の影響

仮想スレッド活用シナリオ

移行時に必要なコード・設定変更

1. @Async の仮想スレッド化

2. WebFlux の仮想スレッド有効化

3. ブロッキング API のラップ

Class Data Sharing (CDS) の活用方法

CDS とは何か

手動で CDS を有効化する手順（Gradle / Maven 共通）

Maven 用例

Gradle 用例（補足）

ベンチマーク根拠と留意点

Observability の強化ポイント

Prometheus メトリクス拡張

OpenTelemetry Bridge の有効化

周辺スタックと依存管理：BOM ドリフト対策

Spring Cloud・AWS SDK の互換性チェック

Maven / Gradle 両対応の BOM ドリフト検出フロー

1. 依存関係ツリーを取得

2. バージョン不一致レポートの作成

Maven 例

Gradle 例

3. dependencyManagement に統一

4. テストでコンフリクトを検証

アップグレード手順・ベストプラクティスと次のステップ

段階的移行フロー（ローカル → ステージング → 本番）

テスト戦略とリグレッション防止策

公式マイグレーションガイドの活用ポイント

まとめ

参考文献

Spring Boot 3.2 の概要とアップグレード全体像

Java 21 仮想スレッドの正式サポートと実務上の影響

1. `@Async` の仮想スレッド化

3. `dependencyManagement` に統一