LASSIC Media らしくメディア
Java17サポート終了と21 LTS移行の外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Oracle JDK 17はPremier Supportの終了時期が定められており、以降は無償のセキュリティ更新提供が縮小していきます。
- 移行先には21 LTSへのアップグレードとOpenJDK（オープンソース版Java）ディストリビューションへの乗り換えという方向性があります。
- 移行には互換性検証・依存ライブラリ更新・性能回帰テストが伴うため、体制が整わない場合は外注の検討も現実的な選択肢になります。
目次
Java17サポート終了の時期とLTSの仕組み
Java17サポート終了とは、Oracle JDK 17のPremier Support（無償の更新提供期間）が2026年9月30日に終わることを指します*1。
以降はExtended Support（有償の追加サポート期間）に移行し、2029年9月30日まで延長提供される仕組みです*1。
LTS（Long Term Support、長期サポート）とは、Oracleが2年ごとに指定する長期サポート対象のJavaバージョンです*1。直近では17（2021年9月リリース）・21（2023年9月リリース）・25（2025年9月リリース）がLTSに位置づけられています*1。
Oracleの支援体系は、Premier Supportが公開から最低5年です。その後のExtended Supportが追加で3年という期間設計になっています*1。Java21のPremier Supportは2028年9月30日まで、Extended Supportは2031年9月30日までです*1。17より長い残存期間を持つ点が特徴です。
加えてOracle JDKには無償利用が可能なNFTC（No-Fee Terms and Conditions、条件付き無償ライセンス）という枠組みがあります。Oracle JDK 17は2024年9月以降のアップデートからOTN（Oracle Technology Network）ライセンスに切り替わります*2。商用の継続利用では有償契約の検討が必要になるでしょう。Java21は次期LTSであるJava25公開の1年後、2026年9月までNFTCの対象となる計画です*2。
Java17に留まるリスクとディストリごとの違い
Java17を使い続けることは技術的には可能ですが、サポート形態によって注意点が異なります。Oracle JDKか、OpenJDK（オープンソース版Javaの実装。無償で公開されているコードベース）ベースの各ディストリビューションかで、期限の考え方が変わってきます。
Oracle JDK継続時はライセンス費用の発生に留意
Oracle JDK 17をPremier Support終了後も商用利用し続ける場合、Extended Supportの有償契約を検討する必要が生じます*1。無償のNFTC期間が過ぎた後の更新版はOTNライセンスの対象となるため、ライセンス条件の見落としはコンプライアンス上のリスクにつながります。
特に本番環境で多数のサーバーにJavaをデプロイしている場合は注意が必要です。ライセンス形態の切り替えに気づかず旧バージョンの更新を継続すると、契約範囲を超えた利用になっている可能性があります。早期の棚卸しが欠かせません。
ディストリビューションによるサポート期間の違い
Eclipse Temurinは、Eclipse Foundationが提供するOpenJDKディストリビューションです。LTSを最低4年間ビルド提供する方針です*3。上流のOpenJDKソースが継続保守される限り、実際の提供期間はさらに延びる場合もあるとされています*3。
Amazon Correttoの場合、Corretto17は2029年10月、Corretto21は2030年10月を最終更新の目安として公表しています*4。ディストリごとに終了時期がずれるため、採用中のディストリを個別に確認する作業が必要になります。
複数のディストリを環境ごとに使い分けている企業では、どのシステムがどのビルドに依存しているかの管理が煩雑になりやすいでしょう。棚卸しを怠ると、一部のシステムだけサポート切れに気づかず稼働し続けるという事態が起こりえます。
21 LTS移行・ディストリ乗り換え・OTN継続の3択比較
Java17のサポート終了に対する選択肢は、大きく3つの方向性に整理できます。それぞれ移行コストとリスクの質が異なるため、比較したうえでの判断が求められます。
第一の選択肢は、21 LTSへのバージョンアップです。仮想スレッド（軽量スレッド機構、Project Loomの正式機能化）などのプレビュー機能が正式化されています*5。17より長いサポート残存期間も確保できます。
第二の選択肢は、17のままOpenJDKディストリビューションを乗り換える方法です。TemurinやCorrettoなど無償のビルドへ切り替えることで、当面のセキュリティ更新は継続できます。ただしバージョン自体は変わらないため、恒久対応にはなりません。
第三の選択肢は、Oracle JDKのOTNライセンスで有償継続する方法です。バージョンアップを急がずに済む一方、ライセンス費用が発生し、いずれ21やそれ以降のLTSへの移行検討が必要になる点は変わりません。
| 選択肢 | 概要 | 向いているケース | 留意点 |
|---|---|---|---|
| 21 LTSへ移行 | 仮想スレッド等が正式化された21 LTSへアップグレードします。 サポート残存期間が長くなります*5。 |
中長期的な保守性を優先したい場合に適します。 | 削除API・依存ライブラリの互換性検証が必要です。 性能回帰テストの工数も見込む必要があります。 |
| ディストリ乗り換え（17継続） | TemurinやCorrettoなど無償のOpenJDKビルドへ切り替えます*3*4。 | バージョンアップの検証時間を確保したい場合に適します。 | 恒久対応ではありません。 ディストリごとの終了時期を個別に管理する必要があります。 |
| Oracle JDK有償継続（OTN） | Extended SupportまたはOTNライセンスで有償利用を継続します*1。 | 移行の意思決定に時間を要する場合に適します。 | ライセンス費用が発生します。 将来的な移行検討自体は避けられません。 |
3つの選択肢はいずれも一長一短であり、恒久的な解決策になるのは21 LTSへの移行です。ディストリ乗り換えやOTN継続は時間を確保するための選択肢であり、その間に本格的な移行計画を進める必要があるでしょう。
17から21への互換性論点：削除API・GC・プレビュー機能
21への移行では、単純なバージョン番号の変更以上に確認すべき論点があります。ここでは主要な3つの観点を整理します。
削除・非推奨化されたAPIの洗い出し
21では拡張for文でのレコードパターンサポートなど一部の構文が削除され、括弧付きパターンも取り除かれています*6。finalizeメソッドは削除に向けた非推奨指定が進んでおり、リフレクション経由でJDK内部にアクセスする既存コードは動作しない可能性があります*6。
これらの変更は17から21への一足飛びのアップグレードで一度に表面化しやすい部分です。ライブラリのバージョンによっては21非対応のまま残っているケースもあるため、依存関係の棚卸しが移行初期の重要な工程になります。
GC（ガベージコレクション）・プレビュー機能の正式化
21では仮想スレッド（軽量スレッド機構）が正式機能となり、大量の同時接続処理をシンプルなコードで書けるようになりました*5。既存の非同期処理を仮想スレッドに置き換えるかどうかは、性能検証を踏まえて判断する必要があります。
GCの挙動も17と21で異なる場合があり、同じヒープサイズ設定でもレイテンシ特性が変化することがあります。本番相当の負荷で性能回帰テストを実施しなければ、切替後に想定外のレスポンス劣化が起きるおそれがあるでしょう。
ビルド・CI/CD（継続的インテグレーション／継続的デリバリー）の更新
ビルドツールやコンテナイメージのベースJavaバージョンを21に切り替える作業も避けられません。Dockerfileやビルドパイプラインの設定を洗い出し、CI/CD環境全体を新バージョンに揃える必要があります。
複数のマイクロサービスが稼働している環境では、サービスごとにビルド定義がばらついていることも少なくありません。移行対象の棚卸しを誤ると、一部のサービスだけ移行漏れが残ることになりかねません。
移行に必要な検証工程と外注で得られるメリット
ここまで見た通り、17から21への移行には複数の専門領域が絡み合います。依存関係の棚卸し・削除API対応・性能回帰テスト・CI/CD更新という一連の工程を、社内の限られた人員だけで同時に進めるのは容易ではありません。
内製で移行を行うには、Javaのバージョン差分に関する知識が求められます。加えて利用中の全ライブラリの21対応状況を調査するスキル、負荷テストで性能劣化を検出するノウハウも欠かせません。必要な体制の規模や検証期間は、対象システムの規模や依存ライブラリの数によって変わります。
移行を誤ると、本番切替後に依存ライブラリの非対応が判明し、切替作業が長期化するリスクがあります。性能回帰テストを省略した場合は、レイテンシ悪化に本番環境で初めて気づくことにもなるでしょう。
専門パートナーに依頼する場合と内製で進める場合では、リスクの質が異なります。内製の場合、依存関係調査の漏れや性能検証の甘さが本番切替後に判明するリスクを抱えるでしょう。一方、複数システムの移行経験を持つパートナーであれば、過去の移行パターンに基づいた事前のリスク洗い出しが期待できます。
外注を検討する際の判断軸は3点に集約されます。「自社に依存ライブラリの棚卸しを担える人員がいるか」「性能回帰テストを本番相当の負荷で回せる環境があるか」「CI/CD更新までを含めた移行経験があるか」です。お問い合わせフォームから現状のシステム構成を伝えれば、体制構築の提案を受けられます。
まとめ：Java17サポート終了への3つの判断軸
本稿では、Java17サポート終了に伴う移行の選択肢を整理しました。要点を3つに集約すると次の通りです。第一に、Oracle JDK 17のPremier Supportは2026年9月30日に終了し、以降はライセンス形態の見直しが必要になります。第二に、選択肢は21 LTS移行・ディストリ乗り換え・OTN有償継続の3方向があり、恒久対応となるのは21への移行です。第三に、移行には依存関係調査から性能回帰テストまでの専門工程が必要であり、体制が整わない場合は外注も含めた検討が現実的な選択となります。
よくある質問
Java17のサポートはいつ終了しますか。
Oracle JDK 17のPremier Supportは2026年9月30日に終了します*1。以降はExtended Supportへ移行し、2029年9月30日まで有償で延長提供される計画です*1。無償のNFTCライセンスは2024年9月以降のアップデートから対象外となっている点にも注意が必要です*2。
OpenJDKディストリビューションに乗り換えれば移行を先延ばしできますか。
TemurinやCorrettoなど無償のOpenJDKビルドへ乗り換えれば、当面のセキュリティ更新は継続できます*3*4。ただしバージョン自体は17のままのため恒久対応にはならず、いずれ21以降への移行検討が必要になります。
17から21への移行で特に注意すべき互換性の論点は何ですか。
拡張for文でのレコードパターン削除や括弧付きパターンの削除など、一部の構文変更が21で加えられています*6。加えて依存ライブラリの21対応状況の確認と、GC挙動の変化を踏まえた性能回帰テストが欠かせません。
Java21 LTSはいつまでサポートされますか。
Oracle JDK 21のPremier Supportは2028年9月30日まで、Extended Supportは2031年9月30日までです*1。17より長い残存期間を確保できるため、中長期的な保守性を重視する場合は21への移行が有力な選択肢になります。
移行を外注する場合、何を基準に依頼先を選べばよいですか。
依存ライブラリの棚卸し能力・性能回帰テストの実施体制・CI/CD更新を含めた移行経験を持つかどうかが基準になります。過去の移行実績と対応範囲を確認したうえで依頼先を選ぶことをお勧めします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Oracle「Oracle Java SE Support Roadmap」（Oracle公式）
- *2 出典：Oracle「JDK 17 approaches end-of-permissive license」（Oracle公式ブログ）
- *3 出典：Eclipse Foundation「Temurin Support」（Adoptium公式）
- *4 出典：Amazon Web Services「Amazon Corretto FAQs」（AWS公式）
- *5 出典：Oracle「JDK 21 Release Notes」（Oracle公式）
- *6 出典：Oracle「Significant Changes in JDK 21」（Oracle Java Documentation）
