2025年のJava：移行、セキュリティー、長期的リスクの指針

要約

2025年においても、Javaは引き続きエンタープライズシステムの基盤としての役割を果たし、銀行、政府機関、医療、電子商取引におけるミッションクリティカルなワークロードを支え続けています。この言語の構文は従来と変わりませんが、その周辺のエコシステムは劇的に変化しました。企業は今、移行、セキュリティ、ガバナンスへの取り組み方を再考する必要があります。

‍

オラクルの2年ごとの長期サポート（LTS）サイクルが、今や企業の計画期間を左右するようになっています。かつては10年に1度行われていた移行プロジェクトが、現在では4年から6年ごとに繰り返されるようになっています。新しいLTSリリースが発表されるたびに、JDKの内部構造における互換性を損なう変更、モジュールの削除、アーキテクチャの変更が導入されています。

‍

Log4ShellやSpring4Shellといったセキュリティインシデントは、たった1つのオープンソース依存関係が、わずか数時間で数千ものアプリケーションを不安定化させてしまうことを明らかにしました。2024年のSynopsysの調査によると、コードベースの74％に高リスクのオープンソース脆弱性が含まれており、これはわずか2年前の48％から増加しています。一方、Sonatypeは、悪意のあるオープンソースパッケージが前年比で156％急増したと報告しています。

CIO、CISO、およびエンジニアリング部門のリーダーたちにとっての課題は、もはやJavaに依存し続けるべきかどうかということではありません。重要なのは、LTSバージョン間で安全に移行する方法、レガシー環境におけるリスクを低減する方法、そして規制当局の精査に耐えうるガバナンスの枠組みを構築する方法です。

‍

本ホワイトペーパーでは、移行の現状、実際のセキュリティ侵害事例から得られた教訓、サプライチェーンリスク、そして2025年の企業の意思決定を左右する経済的・規制面・ベンダー側の動向について、詳細な分析を行っています。

‍

エンタープライズ分野におけるJavaの揺るぎない役割

GoやRustといったクラウドネイティブ言語の台頭にもかかわらず、Javaは依然としてエンタープライズITの分野に深く根付いています。Javaは世界中で最も使用されているプログラミング言語のトップ3に常にランクインしており、1,200万人以上のアクティブな開発者を擁しています。

‍

金融決済機関、電子カルテシステム、eコマースプラットフォーム、政府機関のアプリケーションといったミッションクリティカルなシステムは、JVMに依存しています。その長きにわたる存続は、恩恵であると同時に負担にもなっています。安定性は技術責任者にとって安心材料である一方、対応の先送りを助長する要因にもなっています。「壊れていないなら直すな」という考え方のせいで、数え切れないほどの組織がサポート対象外のランタイムを抱え、攻撃対象領域が拡大し、コンプライアンスリスクが雪だるま式に増大しています。

‍

Javaの新しいリリースおよびサポートのパラダイム

2018年以降、オラクルとOpenJDKコミュニティは、6か月ごとの機能リリースサイクルを採用し、2年ごとにLTSバージョンをリリースしています。現在のLTSリリースはJava 8、11、17、21であり、Java 25は2025年9月にリリースされる予定です。

‍

多くの企業では、「2回のリリースを飛ばす」というアプローチを採用しており、4年から6年ごとに移行を行うことを目標としています。これにより、アップグレードの回数は減りますが、そのたびに複雑さが増します。例えば：

• Java 8 から 11 への移行には、CORBA や Java EE などの非推奨モジュールを置き換える必要があります。
• バージョン11から17への移行により、内部APIの強力なカプセル化が徹底され、セキュリティマネージャーは非推奨となります。
• バージョン17から21への移行に伴い、新しいガベージコレクション戦略と仮想スレッドが導入され、これらは並行処理モデルに影響を及ぼします。
• Java 25 へ直接移行するには、長年にわたる非推奨機能への対応と、セキュリティマネージャの完全な無効化の両方を行う必要があるでしょう。

ライセンス制度の変更がさらなる混乱を招いている。オラクルが従業員1人あたりのサブスクリプション制に移行したことに加え、無償サポート期間が短縮されたことで、多くの組織がAdoptium、Amazon Corretto、Azulといった代替ソリューションの導入を余儀なくされている。

‍

移行の現実と落とし穴

移行によって、そのまま置き換えられることはめったにありません。LTSのバージョンアップのたびに、フレームワーク、ライブラリ、デプロイメントモデルに不具合が生じる可能性があります。内部リフレクション、SOAPバインディング、あるいはWARデプロイメントに依存しているレガシーシステムでは、多くの場合、大規模な書き換えが必要となります。新しいガベージコレクタの導入に伴い、パフォーマンスプロファイルが変化するため、徹底的なベンチマークテストが求められます。

‍

移行を先送りする企業は、リスクがさらに高まることになります。Java 8 や 11 から Java 25 へ直接移行する場合、多段階にわたるアップグレードが必要となり、コストが膨らみ、スケジュールも長期化する可能性が高いです。ITロードマップに移行計画を組み込んでいる組織は、緊急対応プログラムに伴う高額なコストを回避できます。

‍

実世界の脆弱性から得られる教訓

この10年間で、Javaエコシステムにおける脆弱性が、いかに迅速に壊滅的な結果をもたらしうるかが明らかになった。

• Equifax（2017年）：パッチが適用されていなかったApacheStruts 、1億4700万件の消費者情報が流出しました。パッチ適用に関するSLAは、数週間単位ではなく、数日単位で測定されなければなりません。
• Log4Shell（2021年）：情報公開から数時間以内に悪用が始まり、SBOMの可視化と依存関係ガバナンスが不可欠であることが証明された。
• Spring4Shell (2022)：展開トポロジーによって脆弱性の影響範囲が決まり、Tomcat 上でのWARファイルの展開は脆弱性が高かった。セキュリティ対策には、パッチの適用とアーキテクチャの健全性の両方が必要である。

こうした事例は、近代化を先送りすることがもはや現実的な選択肢ではないことを示している。脆弱性は急速に連鎖し、悪用キャンペーンは加速しており、規制当局は積極的なガバナンスを求めている。

‍

拡大するサプライチェーンへの脅威

現代のJavaにおけるリスクは、実行環境そのものにとどまらない。

• Synopsys OSSRA 2024：監査対象となったコードベースの74％に高リスクの脆弱性が確認され、2022年の48％から増加した。
• Sonatype 2024：1年間で50万件以上の悪意のあるオープンソースパッケージが確認され、前年比156％増となった。
• 2025年第2四半期：16,279件の悪意のあるパッケージが特定され、その多くは認証情報の窃取やデータの持ち出しを目的としていた。
• 標的型攻撃：ラザルス・グループは、タイポスクワッティングされたパッケージを悪用し、3万6,000人以上の開発者を標的にした。

その意味するところは明らかだ。たとえ最新のパッチが適用されたJVMであっても、脆弱性のあるフレームワーク、HTTPクライアント、あるいはロギングライブラリによって侵害される可能性がある。ガバナンスは依存関係チェーンにまで及ぶ必要があり、自動化されたSBOM、SCAスキャン、そしてタイポスクワッティングや悪意のあるインジェクションに対するリポジトリレベルの防御策が求められる。

‍

安全な移行の青写真

近代化に成功している企業は、移行を体系的なプログラムとして捉えています：

1. 在庫管理：SBOMを生成し、依存関係をマッピングする。
2. 是正措置：非推奨のAPIおよびサポート対象外のモジュールを置き換える。
3. テスト：機能、パフォーマンス、およびセキュリティのベースラインを検証する。
4. 展開：カナリアリリース方式で展開し、異常がないか監視する。
5. ガバナンス：パッチのSLAを徹底し、スキャンを自動化し、一時的な実行時の回避策を廃止する。

直ちに移行することが困難な場合、商用による長期サポートや、WAFルール、実行時モニタリング、送信トラフィック制限ポリシーなどの代替対策を活用することで、組織はコンプライアンスを維持しつつ、持続可能なアップグレードを計画することができます。

‍

業界事例

• 金融：ある大手銀行は、Java 8から11への移行を先送りしていたが、ベンダーのサポートが終了したことで緊急のプログラムの実施を余儀なくされ、数百万の損失を被った。
• 政府：Java 7 を実行しているある連邦政府機関は、段階的な移行を計画する一方で、FedRAMP および NIST のコンプライアンスを維持するために、延長サポートを活用していた。
• 医療：ある病院グループでは、パッチが適用されていないJavaアプリケーションがコンプライアンス監査に合格しなかったため、HIPAAに基づく罰則を科されました。Java 17への移行とバックポートによるパッチ適用を組み合わせることで、この問題は解決されました。

‍

移住の経済的側面と支援の比較

移住に伴う直接費用

移行には、そのたびに多額の直接コストが伴います。コードの書き換え、依存関係の更新、システムテストには、開発者の工数を割く必要があります。特に時間的制約のある状況での移行では、高額な報酬で外部のコンサルタントを起用することがよくあります。さらに、新しいディストリビューションのライセンス費用も、さらなる負担となります。

‍

隠れたコストと機会損失

移行には、目に見えないコストも発生します。エンジニアに対する新しい言語機能の再教育、イノベーションプロジェクトの一時停止、段階的な導入に伴うダウンタイムの管理などは、いずれも生産性の低下につながります。こうした間接コストは、予算に計上されていないことが多く、直接コストに匹敵するか、あるいはそれを上回ることもあります。

‍

財務戦略としての長期支援

商用長期サポートは安定性をもたらします。4年ごとに数百万ドル規模の移行コストを負担する代わりに、組織は予測可能な年間サブスクリプション料金にコストを分散させることができます。このモデルは、戦略的な俊敏性を損なうことなく、予算の安定化、緊急支出の回避、コンプライアンスの維持を目指すCFOやCIOにとって魅力的なものです。

‍

規制およびコンプライアンスの側面

コンプライアンスに関する期待事項

PCI DSS、HIPAA、GDPR、FedRAMP などのフレームワークでは、既知の脆弱性に対するタイムリーなパッチ適用が求められています。サポート対象外の Java ランタイムを使用することは、これらの要件に違反することになり、監査上の指摘や罰則の対象となる可能性があります。

‍

SBOMおよびサプライチェーンに関する規制

米国の大統領令第14028号、CISAの「既知の悪用済み脆弱性カタログ」、およびEUの「サイバーレジリエンス法」はいずれも、ソフトウェアのサプライチェーンにおける透明性の向上を求めています。現在、SBOMは規制対象組織にとって必須の成果物となっています。サポートが終了したランタイムは、これらの規制への準拠を妨げる要因となります。

‍

執行の動向

監査人は、パッチ適用に関するSLA、SBOM、および是正措置のプロセスの文書化を求めています。証拠を提示できない組織は、監査不合格、評判の低下、規制当局による罰則に直面することになります。医療や金融などの業界では、コンプライアンス違反により業務停止や数百万規模の罰金が科される可能性があります。

‍

JavaのセキュリティにおけるAIの役割

攻撃ツールとしてのAI

攻撃者はAIを活用して依存関係グラフをスキャンし、エクスプロイトの概念実証（PoC）を生成し、偵察活動を自動化している。国家主体の攻撃者は、すでに開発者エコシステムを標的とした攻撃キャンペーンにおいてAIを導入している。

‍

防御セキュリティにおけるAI

防御ツールはAIを活用して、SCAスキャンを高速化し、脆弱な推移的依存関係を特定し、悪用される可能性に基づいて是正措置の優先順位を決定します。これにより、可視性と対応時間が向上します。

‍

人間主導のガバナンス

AIには、いつ移行すべきか、いつバックポートすべきか、あるいはどのように補完的な統制措置を適用すべきかを判断することはできません。ガバナンスは依然として人間の責任であり、AIがスピードと規模をもたらす一方で、コンプライアンスの確保と戦略との整合性を維持するのは人間の役割です。

‍

Javaプログラムへのガバナンスの組み込み

ガバナンスは、一度きりの取り組みではなく、継続的なプロセスでなければならない。

• 企業のロードマップを、オラクルの2年ごとのLTSサイクルに合わせて調整する。
• KEVに掲載された脆弱性に対し、数日以内にパッチを適用するというSLAを徹底する。
• ビルドおよびリリースのたびに、SBOMの生成を自動化する。
• WARファイルよりも実行可能JARファイルを優先することで、デプロイ戦略を強化する。
• 次のような一時的な実行時例外を追跡し、対処する --add-opens.

ガバナンスをJavaプログラム自体に組み込むことで、リスクの露出を低減し、監査に対する耐性を強化し、長期的な運用安定性を確保することができます。

‍

結論

Javaの安定性は、その最大の強みであると同時に、最も危険な弱点でもありました。LTSのリリースサイクルに合わせて近代化を進められない組織は、規制上の罰則、技術的負債、そして壊滅的な情報漏洩に直面することになります。

‍

今後の道筋には、先を見据えた移行計画、包括的なサプライチェーン・ガバナンス、そして長期的な商業的サポートのバランスが求められます。HeroDevsは、企業がセキュリティ上のリスクを伴う移行や、急ごしらえの移行を強いられるべきではないと考えています。先を見据えた計画と「Never-Ending Support」により、組織は自社のJava環境のセキュリティとコンプライアンスを確保し、将来に備えた体制を整えることができます。

‍

参考文献

• Synopsys。オープンソースのセキュリティおよびリスク分析（OSSRA）2024。
• Sonatype. 『2024年ソフトウェア・サプライチェーンの現状に関するレポート』。
• Sonatype. 2025年第2四半期 悪意のあるパッケージに関する活動レポート。
• ITPro. 「北朝鮮のハッカーがオープンソースのマルウェアを通じて開発者を標的にしている」。2025年。