Java 27は上げなくていい — 業務システムに効くのは月次パッチ

「うちの基幹システム、Javaのバージョンはいくつですか」と聞いて、その場で答えられる会社は多くありません。だいたいは保守ベンダーに確認して、数日後に「Java 17 でした」と返ってきます。動いているものを触らない判断は、それ自体は間違っていません。

ただ、2026年9月にJavaまわりで2つの動きがありました。ひとつはJava 27のリリース。もうひとつは、Oracleがセキュリティパッチの提供を月次に切り替えたことです。発注する側にとって重要なのは、後者だけです。 前者は、少なくとも今すぐの判断材料にはなりません。

Java 27 は、業務システムの移行先ではない

2026年9月15日（米国時間）にJava 27がリリースされました。ここで最初に確認すべきなのは、27がLTS（長期サポート）版ではないことです。

JDK 27は半年ごとのフィーチャーリリースの18回目にあたり、次のJDK 28が出る2027年3月まで更新されます。つまりサポート期間は約半年です。業務システムをこれに載せると、半年後にまた上げる話が始まります。

Javaの長期サポート版は2年おきに出ていて、直近のLTSはJava 25、その次は2027年に出るJava 29の予定です。業務システムの移行計画で基準にすべきなのは25であって、27ではありません。 保守ベンダーから「最新版が出ました」という連絡が来たとしても、それが27を指しているなら、急いで検討する必要はありません。

この「最新版と、載せてよい版は違う」という構造は、.NETでも同じです。サポート期限から逆算する考え方は.NET 8/9のサポート終了と業務システムの移行判断に整理しています。

本当に効くのは、パッチが月次になったこと

もうひとつの動きのほうが、運用に直接効きます。

Oracleはこれまで、3か月ごとの「Critical Patch Update（CPU）」でセキュリティ修正をまとめて提供してきました。ここに、四半期の合間を埋める月次の「Critical Security Patch Update（CSPU）」 が加わりました。CSPUは毎月第3火曜日に提供され、Javaについては2026年8月から実際の配布が始まっています。

Oracle側の説明では、この変更の背景にあるのはAIです。脆弱性の発見がAIの支援で速くなり、同時に修正も速くできるようになったため、四半期のサイクルでは間隔が空きすぎる、という理屈です。実際、Microsoftが1か月で1,000件超の脆弱性にパッチを当てたという事例も出ており、脆弱性の発見と修正の速度が、業界全体で上がっています。

問題は、受け取る側の体制です。

多くの業務システムの保守契約は、四半期のCPUを前提に組まれています。年4回、パッチを当てて、検証環境で回して、問題がなければ本番に反映する。この流れが年12回になると、検証に使える人数と時間が単純に3倍必要になります。

現実的には、こうなります。

• 全部は当てられないので、深刻度の高いものだけを選別する。選別する人が必要になる
• 選別を保守ベンダーに任せる場合、それは契約の範囲内かどうかを確認する必要がある
• 当てなかったパッチが溜まっていき、四半期のCPUでまとめて当てる形に戻る。このとき、一度に変わる量が増えて検証が重くなる

つまり、月次化は「こまめに当てられるようになった」という話であると同時に、当てない判断を毎月するようになったという話でもあります。この判断を誰がしているかが曖昧な会社では、実質的に誰もしていない状態になりがちです。

27で入った変更は、29の予行演習として見る

27を本番に載せないとしても、中身を知っておく価値はあります。ここで入った変更は、次のLTSであるJava 29にも引き継がれる可能性が高いためです。

実務で先に効きそうなのは上の2つです。GCの既定値が変わると、これまで積み上げたJVMのチューニングが前提から崩れることがあります。 検証環境にJava 27を入れて、現行と同じ負荷をかけたときの挙動を見ておくと、29に上げるときの見積りの精度が上がります。逆に言えば、27の使い道はそこまでです。

耐量子暗号については、いま慌てて対応する必要はありませんが、長期保存が必要なデータを扱う場合は別です。方針を決めておく時期には来ています。

保守契約で確認する3点

月次化を受けて、次の契約更新までに確認しておきたいのは次の3つです。

1. パッチの適用は誰が判断するのか。 「セキュリティパッチは適用する」とだけ書かれている契約は、月次前提だと解釈が割れます。深刻度の閾値と、当てない場合の報告方法まで決めておきます
2. 検証の範囲はどこまでか。 パッチ適用後の動作確認を、どのレベルでやるのか。全機能の回帰テストなのか、主要導線の確認なのか。月次で全機能を回すのは非現実的なので、線を引いておく必要があります
3. 費用が回数に連動するのか。 適用作業が回数課金になっていると、月次化でそのまま3倍になります。年額の枠に収める形か、判断込みの定額にするかを話しておいたほうが安全です

保守費用の相場観と内訳の考え方は業務システムの保守費用ガイドに整理しています。今回のような外部要因でコスト構造が変わるときは、値上げの交渉ではなく、範囲の再定義として話すほうが着地しやすくなります。

次にやること

まず、稼働中の業務システムで使っているJavaのバージョンと、そのサポート期限を一覧にしてください。保守ベンダーに聞けば出てきます。Java 17や21で動いているなら、当面の移行先は25です。27は関係ありません。

そのうえで、直近3か月にセキュリティパッチを何回当てたかを確認します。ゼロなら、月次化の前から適用が回っていないということなので、バージョンの話より先に手を付けるべきはそちらです。

業務システムのJavaバージョン移行計画、パッチ適用体制の見直し、保守契約の範囲の再定義については、グリームハブの開発・AI・自動化のご相談で承っています。現在の構成と運用体制によって進め方が変わるため、お問い合わせからご相談ください。

Sources

• 「Java 27」正式リリース。全環境でG1 GCがデフォルトに、TLS 1.3用に耐量子暗号のハイブリッドキー交換など新機能 — Publickey
• Java 27リリース――ヒープ使用効率向上と安全性の重視 — gihyo.jp
• オラクル、Javaのセキュリティパッチを毎月提供開始、AIが脆弱性の発見を加速しているとして — Publickey
• Transitioning Java to More Frequent Security Updates — Inside Java
• Oracle、「Java 27」を発表 ～TLS 1.3のポスト量子暗号対応や「G1」GCの既定化など — 窓の杜
• AI-Assisted Discovery Helps Microsoft Patch More Than 1,000 Vulnerabilities in a Month — InfoQ