LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Spring Boot 2系サポート終了とは、無償更新が途絶える状態

Spring Boot 2系のサポート終了とは、Spring公式が定める無償のOSSサポート期間が満了し、脆弱性修正パッチが提供されなくなる状態を指します。2系最後のマイナーバージョンである2.7系は、この期間をすでに終えています^*1。

公式のサポートポリシーでは、メジャーリリースはリリース日から最低3年間のサポートが定められています^*2。マイナーリリースは無償ダウンロードの場合で最低13ヶ月、商用サブスクリプションの場合で最低25ヶ月です^*2。加えて各メジャーバージョンの最後のマイナーバージョンには、通常の期間に5年間の商用エンタープライズサポートが上乗せされる仕組みです^*2。2.7系はこの「最後のマイナーバージョン」に該当します^*2。

Spring Enterprise公式ページには具体例が示されています。2022年5月19日にリリースされた2.7.0の場合、OSS無償サポートは2023年6月30日までとされています^*5。この期間をすでに過ぎているため、通常のセキュリティ更新は届かない状態が続いています。

無償サポートが終了した状態でSpring Boot 2系のアプリケーションを稼働させ続けると、新たに公表された脆弱性への修正パッチが提供されません。CVE（共通脆弱性識別子）が公開されても対応版が配布されないため、脆弱な状態のまま外部公開のシステムを運用し続けることになりかねません。

取引先とAPI連携するシステムやECサイトのバックエンドでSpring Boot 2系を稼働させている場合、自社だけの問題にとどまりません。連携先のシステムやクレジットカード情報を扱う決済基盤にまで影響が及ぶ可能性があるため、対応の先送りは取引上の信用問題に発展するおそれがあります。

2.7系は2系最後のマイナーバージョン、商用サポートも2026年末が期限

2.7系が2系最後のマイナーバージョンにあたるため、通常のOSS期間に加えて5年間の商用エンタープライズサポート期間が用意されています^*2。この商用サポートはTanzu Spring（旧VMware Tanzu）を通じて提供されます。対象はOpenJDK・Spring Framework・Apache Tomcatで、トラブルシューティングとバグ修正の両方をカバーする仕組みです^*2。

2024年9月には、この商用サポートについてさらなる延長が公式発表されました。発表によると、Spring Boot 2.7系および同時期のポートフォリオ全体の商用サポートを2026年末まで延長するとしています^*3。これにより従来の期間から16ヶ月が上乗せされ、2系全体では8年以上のサポート期間が確保される計算です^*3。

延長の狙いは、Spring Boot 3への移行に時間を要する企業に猶予を与える点にあります^*3。ただし2026年末という期限そのものが動くわけではありません。商用契約を結んでいない企業では、この猶予期間の恩恵をすでに受けられていない点にも注意が必要です。

商用サポートが切れたあとにSpring Boot 2系を使い続けると、脆弱性が見つかっても修正パッチを入手する手段そのものがなくなります。移行を先送りするほど、後から着手する際の検証範囲も広がりやすくなるでしょう。早期にロードマップを固めておくことが、結果的に移行工数を抑える近道になります。

3系移行に必須のJava 17とJakarta EE名前空間移行

Spring Boot 3系への移行では、避けて通れない技術要件が2つあります。Javaランタイムのバージョンと、パッケージの名前空間です。

1つ目は、Java 17（Javaの長期サポート版）への切替です。公式の移行ガイドでは、Spring Boot 3.0はJava 17以上を必須とし、従来のJava 8はサポート対象外になったと明記されています^*4。あわせてSpring Framework 6.0が必須となるため、Spring Framework側の移行ガイドも事前に確認しておく必要があります^*4。

2つ目は、Jakarta EE（旧Java EEの後継仕様。Eclipse Foundationが管理する企業向けJava標準）への対応です。Spring Boot 3.0はJakarta EE 10に対応しており、Servlet 6.0・JPA 3.1など最新仕様への追随が求められます^*4。

この対応にあたって最も影響が大きいのが、パッケージ名の変更です。公式ガイドでは、javaxパッケージからjakartaパッケージへの移行が必須とされています^*4。例として「jakarta.servlet:jakarta.servlet-api」への置き換えが挙げられています^*4。従来の「javax.servlet:javax.servlet-api」はそのままでは動作しません^*4。

公式ガイドでは移行前の準備手順も案内されています^*4。まず稼働中のSpring Boot 2.7.xを最新パッチまで上げ、その上で依存関係の互換性を確認する流れです^*4。いきなり3系へ飛び移るのではなく、2.7系内で足場を固めてから移行に着手する進め方が推奨されています。

javax→jakarta変換で見直す依存関係とサードパーティ資産

javax.servlet・javax.persistenceなど主要パッケージの置き換え

Servlet・JPA（Javaのデータベース操作仕様）・JMS（Java Message Service）が代表例です。これらJava EE系の主要パッケージは、軒並みjavaxからjakartaへ改名されています^*4。自社アプリケーションのimport文だけでなく、web.xmlやアノテーションで参照しているクラス名も洗い出しの対象です。

公式ガイドではOpenRewrite（コードの自動変換を行うリファクタリングツール）のレシピが変換作業の選択肢として紹介されています^*4。ほかにもSpring Boot MigratorプロジェクトやIntelliJ IDEAの移行支援機能が挙げられています^*4。機械的な置き換えである程度自動化できる一方、自動変換の結果を人手で検証する工程は省けません。

サードパーティライブラリのSpring Boot 3対応状況を洗い出す

自社コードの変換だけでは移行は完結しません。利用しているサードパーティライブラリがjakarta名前空間に対応したバージョンを提供しているかどうかも、事前に確認が必要な項目です。

認証・帳票出力・監視エージェントなど、javaxパッケージに依存する外部ライブラリを組み込んでいる場合は注意が必要です。ライブラリ側のバージョンアップが追いついていないと、移行そのものが止まってしまいます。社内で使用しているライブラリの棚卸しは、Java 17化と並行して早い段階で着手すべき作業です。

この棚卸しを誤ると、移行作業の終盤になって「特定のライブラリだけjakarta対応版が存在しない」という事態に直面しかねません。代替ライブラリへの置き換えや自前でのラッパー実装が必要になり、当初の計画より工数が膨らむおそれがあります。

内製移行・移行ツール活用・外注委託、3つの選択肢とコスト構造の違い

Spring Boot 2系から3系への移行は、大きく3つの進め方に分かれます。「内製での手動移行」「OpenRewrite等の移行ツールを活用した半自動移行」「外部パートナーへの委託」です。それぞれ前提条件とコスト構造が異なるため、自社のシステム規模と体制に応じた選定が求められます。

いずれの選択肢を選んでも、検証を省いて進めると本番環境で障害が発生するリスクが残ります。名前空間の変換漏れがあるとアプリケーションが起動しない状態になりかねません。依存ライブラリの非互換が残っていると、特定のAPI呼び出しだけが失敗するといった不具合につながるでしょう。移行ツールで機械的に変換した箇所ほど、実際の挙動を人手で確かめる工程を省略しないことが求められます。

移行を内製で進める場合に必要な工数とリスク

Spring Boot 3系への移行を内製で進める場合、開発チームには複数の専門知識が求められます。第一に、Java 17への切替に伴う言語仕様・実行環境の変更点を把握する知識です。第二に、javaxからjakartaへの名前空間変換を、自社コードと依存ライブラリの両面で洗い出す調査力です。

そして第三に、変換後のアプリケーションが本番相当の環境で正しく動作するかを保証するテスト設計の知識も欠かせません。

この作業を誤ると発生するリスクも軽視できません。検証を省いたまま本番環境へ反映すると、起動時エラーで業務システムが停止する、特定の画面だけAPI呼び出しが失敗するといった障害につながります。

結果として、サービス停止や取引先への影響という形で顕在化するおそれがあります。ロールバック手順を用意せずに切替を進めた場合、障害発生時に旧環境へ戻す手段自体が失われる点にも注意が必要です。

対象アプリケーションが複数にまたがる企業ほど、依存関係の棚卸し・変換・テストを、通常の開発業務と並行してこなす必要があります。開発チームの人数が限られる企業ほど、負荷が特定の担当者に集中しやすくなるでしょう。既存の開発・保守業務を止められない以上、移行作業に割ける時間そのものが制約になります。

外注に委託する場合の進め方と委託先選定のポイント

専門パートナーに委託した場合、内製との違いは主に「変換作業の型化」と「複数アプリケーションへの並行対応力」にあります。委託先は依存ライブラリの互換性確認やOpenRewriteによる変換、変換後の動作検証をチェックリスト化して横展開する仕組みです。そのため開発チームは、既存機能の開発や利用部門からの問い合わせに専念できます。

委託先を選定する際は、次の点を確認することが欠かせません。まず、Spring Bootのメジャーバージョンアップ実績があるかどうかです。次に、依存関係の棚卸しから検証環境での動作確認まで、段階的な移行計画を提示できるかどうかも判断材料になります。

さらに、移行後の障害対応や監視体制を保守契約として引き継げるかどうかも、移行後の運用を見据えると確認しておきたい事項です。

委託範囲の決め方も検討事項の一つです。棚卸しから本番切替まで一括で委託する方式があります。名前空間の変換だけを委託し、テストと本番切替は自社で行う方式もあり、費用感と社内の関与度合いが変わります。

自社の開発チームがどこまで関わりたいか、通常業務にどれだけ余力があるかを踏まえて委託範囲を決めると、費用対効果を見極めやすくなります。外注のメリットは、業務を止められない状況で頼るという消極的な理由だけではないでしょう。商用サポートが切れる前に計画どおり3系への移行を終わらせる点にこそ意味があります。2026年末という期限を待たずに着手するほど選べる進め方の幅は広く残るため、早い段階での相談が有効です。

まとめ：Spring Boot 3系移行で押さえる3つの判断軸

本稿ではSpring Boot 2系のサポート終了と、3系への移行について、期限・技術要件・進め方を整理しました。要点を3つに集約すると次の通りです。第一に、2.7系は2系最後のマイナーバージョンとして無償のOSSサポート期間をすでに終えており、商用サポートも2026年末までの延長にとどまります^*3。第二に、3系移行にはJava 17への切替とjavaxからjakartaへの名前空間変換が必須であり、依存ライブラリ側の対応状況も確認する必要があります^*4。第三に、内製・移行ツール活用・外注委託のいずれを選ぶ場合も、検証工程を省かない体制づくりが移行後の安定稼働を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Spring「Spring Boot」プロジェクトページ（spring.io）
2. *2　出典：Spring「Support Policy」（spring.io）
3. *3　出典：Spring「Spring Boot 2.7 Support Period Extended」（spring.io）（2024年）
4. *4　出典：Spring Boot「Spring Boot 3.0 Migration Guide」（github.com）
5. *5　出典：Spring Enterprise「LTS releases and support」（enterprise.spring.io）

Tweet