「今後1年以内に、Spring をサポート対象バージョンへアップグレードできる見通しが立たない」
これは、あるヘルスケアテクノロジーのリードエンジニアの言葉です。この状況は彼だけの話ではありません。多くのエンジニアリングリーダーと話してきた中で、同じパターンが繰り返し浮かび上がってきます。Spring の移行は、サポート期間が許す以上の時間を要しているのです。そして、そのタイムリミットは急速に迫っています。
Spring Boot 3.5 は、2026年6月30日にオープンソースのサポートが終了（EOL）します。
HeroDevs の NES（Never-Ending Support）顧客環境のテレメトリーデータによると、観測された Spring Boot のアクティビティのうち約 93% が、すでに EOL になっているか、数ヶ月以内に EOL を迎えるバージョンに該当します。そのうち約 26% が Spring Boot 3.5 に集中しており、データセットの中で最も割合の大きい単一バージョンとなっています。
「AI ツールなら Spring Boot を1スプリントで移行できる」と言われたことがある方は、ぜひこの記事を読んでください。
サポート済みバージョンに移行できていない Spring Boot の現状
HeroDevs NES 顧客環境の6ヶ月分の依存関係テレメトリーデータから言えることは明確です。多くの企業は、次のサポート対象バージョンへ安全に移行できていません。
- Spring Boot 3.5 は最も広く使われているバージョンであり、オープンソースのサポートは6月30日に終了します
- Spring Boot 4.0（最も自然な移行先）は、その6ヶ月後の2026年12月に EOL を迎えます
- Boot 4.1 以降のロードマップは存在しますが、現時点で多くの企業にとっての課題は 4.0 へのクリーンな移行であり、時間が足りていません
なお、このデータは移行に遅れを抱えた企業が多い HeroDevs の NES 顧客ベースを元にしており、業界の中でも難しい側のケースを反映している可能性があります。それでも、エンジニアリングリーダーたちから聞く話と一致したパターンです。
Spring Boot の移行は一度やって終わりではなく、アプリケーションインベントリ、依存関係レビュー、テスト修正、回帰テスト、セキュリティ検証、本番リリースという工程が繰り返し必要になる継続的な作業です。
顧客のタイムラインは現実のカレンダーと一致していない
あるフィンテック企業のエンジニアリングリーダーは、Spring Boot 2.7 → 3.4 の移行を「ヘラクレス並みの偉業」と表現しました。では 3.5 → 4.0 はどうでしょうか？
- ヘルスケアテクノロジーのリードエンジニアは「1年以内のアップグレードは見通しが立たない」と率直に述べています
- 大手旅行プラットフォームのシニアプラットフォームエンジニアは、すでに 3.5 → 4.0 の移行を進めていますが、それでも最低6ヶ月というのが現実的な見積もりです
HeroDevs の Spring NES 顧客ベース（約75組織）のデータでも同様の傾向が見られました。
- 2026年4月時点でパッケージが最新だったのは 全体の約10% のみ
- 1つの組織も Spring スタック全体を完全に最新の状態に保てていない
- 約68%の組織は、消費している全 Spring パッケージが EOL 済みまたは EOL 直前という状態
Spring の移行はポートフォリオ規模の作業です。アプリケーションインベントリ、依存関係レビュー、テスト修正、リリース調整、セキュリティ検証、そして監査担当者や顧客に提示できるエビデンスの整備まで、多岐にわたる工程が必要です。
AI が役立つ場面
Spring Boot 3.5 → 4.x の移行において、AI は確かに貢献できます。ただし、計画の代替ではなく、加速ツールとして位置づけるのが正しいアプローチです。
具体的に役立つ場面は以下のとおりです。
- 繰り返し発生するクリーンアップ作業の洗い出し
- テストの雛形コードの初版生成
- deprecation 警告のサマリー
- ビルド・設定エラーの説明
特に Spring Boot 4 では、新しいモジュール型オートコンフィギュレーションモデルへの変更を理解する上で AI が有効です。以前のオートコンフィギュレーション構造が細かいモジュールに分割されたことで、依存関係の前提が変わり、ビルド時・実行時に新たな設定エラーが発生するケースがあります。AI はそういったエラーの解読や移行ガイダンスへのマッピングに役立ちます。
ただし、AI による効果はベンダーが主張するほど移行期間を短縮しないという点は認識しておく必要があります。
AI が通用しない場面
AI は、移行作業が機械的な処理ではなくアーキテクチャの判断を要する段階になると限界を迎えます。
依存関係グラフの問題
Spring Boot は Tomcat、Netty、Jetty、Thymeleaf、Hibernate、pgjdbc、Liquibase など多数の依存関係を一括管理するキュレーションされた依存グラフを持っています。Boot が EOL になると、このグラフ全体が凍結されます。しかし CVE（脆弱性）は止まりません。
2026年4月、HeroDevs は Tomcat・Netty・Thymeleaf・Jetty・pgjdbc に対して、Spring Boot BOM が管理する依存関係に起因する 24件の CVE の修正済みパッケージを提供しました。これらは Spring Framework 本体のコードではなく、Spring チームが抱える依存関係サーフェスの問題です。
AI は脆弱な依存関係を指摘したり、バージョンアップを提案したりできます。しかし、修正済みバージョンが BOM 全体と互換性があるか、内部のセキュリティ例外がまだ有効か、変更がテストカバレッジの薄い統合パスを壊さないかを信頼性を持って判断することはできません。
Boot 4 のプラットフォーム大変革
Spring Boot 4 では以下の変更が行われています。
- Jakarta EE 11
- Servlet 6.1
- Spring Security 7
- Jackson 3
- JUnit 6
- 新モジュール型オートコンフィギュレーションモデル
Spring チームは非推奨 API の一掃、パッケージ名前空間の再編成、コンポーネントモデルの厳格化を実施しました。その結果、83件のドキュメント化されたブレーキングチェンジがあり、コードベースに応じて 200〜500時間の移行工数が見込まれています。
変更の中にはビルド時に検出できるものもありますが、実行時の動作変更、テスト失敗、シリアライゼーションの差異、認証フローの変化、設定の前提崩れとして初めて顕在化するものもあります。コードがビルドでき、テストがパスしても、本番環境では実トラフィック・実データ・実際のダウンストリーム依存関係のもとで異なる挙動を示す可能性があります。
Spring AI の問題
Spring Boot 3.5 上で Spring AI を採用したチームは、4.x への移行パスがクリーンかどうかを事前に確認する必要があります。AI 機能の採用が、移行タイムラインを短縮するどころか依存関係の制約を追加するケースがあります。
判断のギャップ
Spring Boot 3.5 → 4.x の移行は、本番リスクを伴うリアルなプラットフォーム移行です。アプリケーション内部のコードだけでなく、アプリを取り巻くフレームワークと依存関係の全体像が変わります。
考慮すべき変更点は、モジュール構造、オートコンフィギュレーション変更、Jackson 3、Spring Security 7、Jakarta EE 11 / Servlet 6.1 対応、JUnit 6、管理対象依存関係の更新、そして自社のスターター・統合ライブラリ・内部ライブラリの挙動と多岐にわたります。
AI が生成した移行計画にこれらがきれいに反映されることはありません。ツールはパターンを見つけて編集候補を提示する。専門家は、どの変更が表層的で、どれが実行時の動作に影響し、どの依存関係を安全に動かせるか、どのパスが本番前にさらなる検証を必要とするかを知っている。
変更は3つの段階に分けて考える必要があります。ビルドを即座に止めるもの、ビルドは通るが起動・実行時にクラッシュするもの、そして最も危険なサイレントな動作変更（本番環境で何ヶ月も検出されないケース）です。
Spring I/O 2026 では、約100人の開発者が Boot 4 に関する15問の移行クイズに挑戦し、平均スコアは 66% でした。つまり、平均的な Spring 開発者はこの移行に臨むにあたって、すでに約50時間の未計画作業を抱えていることになります。
Spring のコミッター兼 Apache Tomcat のコミッター、現 HeroDevs の Scott Frederick はこう述べています。
「Spring Boot バージョンが EOL になると、依存関係の更新も止まります。しかし依存関係の CVE は止まりません。EOL の Spring Boot を使い続けるなら、依存関係を自分でウォッチして、Boot が管理するバージョンを新しいものに手動でオーバーライドし続けるしかありません。」
AI は編集を速めるだけです。互換性の確認、セキュリティ証拠の整備、リリースリスクの評価、本番挙動の検証は、人間の判断が必要です。
CVE のプレッシャーは移行完了を待ってくれない
| 期間 | CVE 件数 |
|---|---|
| 2025年（通年） | 17件 |
| 2026年1〜4月 | 37件（うち4月だけで26件） |
2026年3〜4月の深刻度内訳：Critical 4件 / High 12件 / Medium 17件 / Low 4件
EOL 後も CVE の開示は続きます。2026年の開示パターンは、サポート切れの Spring Boot が急速な脆弱性プレッシャーにさらされることを示唆しています。特に、Boot のバージョンに関わらず上流で修正され続けるマネージド依存関係を通じたリスクが顕著です。
移行タイムラインとセキュリティタイムラインは、同じ速度では動きません。 エンジニアリングチームが安全な移行に数ヶ月かかる一方で、セキュリティ・コンプライアンスチームはずっと早い段階で証拠を求めます。
6月30日までの選択肢
| パス1：Spring Boot 4.x への移行 | パス2：HeroDevs NES ＋ 自分のペースで移行 | |
|---|---|---|
| タイムライン | 2026年6月30日までに移行完了 | 移行を続けながらカバレッジを確保 |
| 検証対象 | モジュール型オートコンフィギュレーション、Security 7、Jackson 3、Jakarta EE 11/Servlet 6.1、JUnit 6、管理対象依存関係、内部スターター | 同じ内容を自社スケジュールで実施 |
| CVE カバレッジ | Spring プロジェクトがサポート対象バージョンで提供 | HeroDevs が Boot 本体と管理対象依存関係全体をカバー |
| セキュリティ証跡 | 標準の Spring リリースノート | CVE 分析、署名済みアーティファクト、リリースドキュメント |
| 向いているケース | 明確な移行パスと余裕のあるチーム | EOL 日までに移行タイムラインが間に合わないチーム |
パス1 は最もクリーンな解決策です。ただし多くの企業にとって、1四半期以内に Spring スタック全体を安全に移行しながら他のロードマップも維持するのは現実的ではありません。
パス2（HeroDevs NES） は、現在使っている Maven 座標のままで修正済み Spring Boot 3.5 パッケージを提供します。ほとんどの環境でコード変更なしのドロップインとして機能し、Tomcat・Netty・Jetty・Jackson・Hibernate などの管理対象依存関係グラフも含めてカバーします。セキュリティ・コンプライアンスチームが使える CVE 分析、署名済みアーティファクト、リリースドキュメントも提供されます。
まとめ
Spring Boot 3.5 の EOL は 2026年6月30日です。移行は本物の作業であり、AI マーケティングが示唆するよりもはるかに重たいものです。
AI はチームの作業スピードを上げる手助けはできますが、依存関係の検証、実行時の挙動評価、セキュリティリスクの管理、本番準備の証明に必要な判断を代替することはできません。
この移行をうまく乗り越えられるチームは、プラットフォーム・依存関係・検証作業の全体像を正直に把握した上で計画を立てたチームです。
Spring Boot 3.5 → 4.x の移行を検討しているなら、まず Spring Boot 4.0 Migration Guide で全変更サーフェスを3段階に分けて確認し、Spring Migration Calculator で工数を見積もることをお勧めします。
出典: HeroDevs Blog / 著者: Mark Szymanski（Java テクニカルプロダクトマネージャー）