Spring Boot 3.4の重要な変更点：構造化ログから仮想スレッドまで

サーバーアプリケーションを運用環境にデプロイする際、ログ収集とコンテナ環境の設定は常に手間のかかる作業です。Spring Boot 3.4では、外部ライブラリを追加せずとも基本設定ファイルのみでJSONベースの構造化ログを生成できるようになり、テストと設定プロパティの検証方法もより明確に整備されました。新規プロジェクトやバージョンアップを検討中の開発者が知っておくべき実務ポイントをまとめました。

設定1行で完了する構造化ロギング

クラウドやKubernetes環境では、通常のテキストログよりも検索や解析が容易なJSON形式のログが好まれます。以前はLogstash Logbackエンコーダーなどの外部依存関係をビルドファイルに追加し、複雑なXML設定を行う必要がありました。Spring Boot 3.4からは、組み込み機能として構造化ロギングが公式サポートされています。

Elastic Common Schema規格であるECSやLogstash、GELFフォーマットを設定ファイルから直接指定できます。コンソール出力とファイル保存でそれぞれ異なる形式を指定することも可能です。

以下はSpring Boot 3.4環境におけるapplication.propertiesの設定例です。

個別のライブラリ依存関係を管理しなくても、ログパイプラインの連携規格を統一できる点が最大のメリットです。

AssertJと自然に馴染むMockMvcTester

Web層のコントローラーを検証する際に使用していたMockMvcでは、jsonPathの文法とResultMatcherのチェーンを習得する必要がありました。Spring Boot 3.4では、馴染みのあるAssertJの表明（assertion）スタイルでAPIレスポンスを検証できるMockMvcTesterが導入されました。

テストコードでMockMvcインスタンスを注入した後にMockMvcTesterでラップするか、専用のビルダーを使用すれば、オートコンプリートを通じてHTTPステータスコード、ヘッダー、レスポンスボディを読みやすい文章形式で検証できます。ネストされたJSON構造やリストデータを検証する際の文法ミスを減らせます。

テストデータベースの自動検知と厳格化されたプロパティ検証

テスト環境と設定プロパティの動作に関しても、有用な改善点と注意すべき点が存在します。

統合テストでTestcontainersを使用する際に発生しがちだった煩雑さが軽減されました。以前はH2などのインメモリDBへの自動置き換えを防ぐために、アノテーションに個別の属性を宣言する必要がありました。Spring Boot 3.4のAutoConfigureTestDatabaseはコンテナベースのデータソースを自動的に検知するため、不要な設定コードを削除できます。

アップグレード時に注意すべき変更点もあります。ConfigurationPropertiesを使用する際、ネストされたオブジェクトフィールドの有効性検証方法が標準のBean Validation仕様に合わせて厳格化されました。サブオブジェクト内部のバリデーション制約を正常に動作させるには、ネストされたフィールドの上に必ず@Validアノテーションを付与しなければ検証が伝播されません。既存のコードで検証を省略していた場合は、アップグレード前に確認が必要です。

実務への適用ガイド

Java 21の仮想スレッドのサポート範囲が拡大し、デフォルトのコンテナビルダーもより軽量なJammy Tinyベースに変更されたため、デプロイイメージのサイズも削減されました。

新規プロジェクトを始める際は、迷わずSpring Boot 3.4をデフォルトの選択肢とすることをお勧めします。既存プロジェクトを3.4へ移行する場合は、設定クラスのネストされたバリデーションの漏れと、デプロイパイプラインのログ収集設定を先に点検すれば安全に移行できます。