拾聞対談第十六回｜Java 27 リリース：AI がコードを書く時代、この古い言語は何をしているのか？

開場：一通の静かなメールと、三十歳に近づく言語が例通り提出した半年の宿題

9 月 15 日、OpenJDK チーフエンジニアの Mark Reinhold が announce メーリングリストで短いメッセージを送った：JDK 27 が正式に GA、build 35。8 月 20 日の RC2 から正式版まで、P1 レベルのバグは一つも現れなかった。GPLv2 ライセンスの OpenJDK ビルドは、当日に jdk.java.net/27 からダウンロードできた。AI プログラミングツールがほぼ週次で更新される 2026 年、この三十歳に近づく言語は例通り半年に一度宿題を提出する——今回は JEP が 9 個だけで、センセーショナルな新文法はなく、定期メンテナンスのように静かだ。

だが、細部は味わう価値がある。9 個の JEP のうち、ユーザーの財布に最も直接的な影響を与える 2 つは、たまたまどちらも文法ではない：G1 ガベージコレクターがすべての環境のデフォルトになり（JEP 523）、コンパクトオブジェクトヘッダーがデフォルトで有効化され（JEP 534）、どちらもメモリ節約だ。同時に、ポスト量子ハイブリッド鍵交換が TLS 1.3 に組み込まれ（JEP 527）、明らかに十年後を見据えた変更だ。その一方で、プリミティブ型パターンマッチングは第 5 回プレビュー、構造化並行性は第 7 回プレビュー、Vector API は第 12 回インキュベーターバージョンに到達した——これを厳密と呼ぶ人もいれば、遅いと呼ぶ人もいる。

拾聞：AI がコードを飛ぶように書く時代に、Java がこのようなバージョンを出したが、最初の反応は？

永亮：「Java はまだいけるか」ではなく、「この 2 つがついにデフォルトになった」だ。メモリを節約する変更は新文法よりも私の心を打つ——私は天津の病院グループで技術を管理しており、手元に数百の JVM サービスがある。ヒープが少し小さくなれば、請求書も少し細くなる。プレビューが何回回ったかについては、ゆっくり話そう。

拾聞：では、徹底的に話そう：AI プログラミング時代に Java を書くのは保守的か、プレビューマラソンは厳密か遅いか、なぜこのバージョンで最も重要なのは 2 つのデフォルト設定か、ポスト量子の布石を AI 企業がなぜ語らないのか、そして Java エコシステムに残る人々に 3 つの実用的なアドバイス。

Q1：AIプログラミング時代、まだJavaを書くのは保守的と言えるか？

永亮：保守的ではない、分業だ。AIが書くスピードが速くなればなるほど、そのコードを走らせるマシンはより疲弊する。Javaが三十年かけて蓄積してきたのは、まさに「コードを事故らせない」ための基盤だ。

AIツールはコードを書くという工程のスピードを一桁引き上げた。私のチームでもAIでコードを書いている人は半数を超えており、これを避ける必要はない。だが、見落とされがちな事実がある。AIが書くコードが増えれば増えるほど、そのコードを走らせるマシンはより疲弊する。生成されたコードは勝手には動かない。メモリを占有し、ガベージコレクションされ、深夜二時の定期タスクに耐えなければならない。私が所属しているのは天津のある医療グループで、受付、決済、検査といったシステムの大部分はJVM上で動いている。その中には、大半のAI企業の歴史よりも長く生き延びてきたものもある。Javaの価値は構文が新しいかどうかにはない——公平に言えば、その構文はずっと「使えるが美しくない」類のものだ——三十年かけて蓄積された実行の基盤にある：成熟したガベージコレクタ、行単位で分析できる観測ツール、問題が起きた時に検索すれば答えが出てくるコミュニティ。だから「AIプログラミング時代にまだJavaを書くのは保守的か」という問い自体が方向を間違えている。実際の分業はこうだ：AIがコードを書き出すことを担当し、JVMがコードを事故らせないことを担当する。コードを書くハードルは下がっているが、システムを事故らせないハードルは一度も下がっていない。十五年走り続けるシステムにとって、「保守的」であることは時に「頼りになる」の別名なのだ。

Q2：ある機能はプレビューを5回、ある並行処理は7ラウンド、ある API は12版孵化——これは厳格さか、それとも先延ばしか？

永亮：これは Java と AI 業界が異なる2つのことに賭けているからです。AI は「先にリリースしてから直す」に賭け、Java は「間違えて直すコストは、遅れることよりずっと大きい」に賭けている。両方の賭け方とも正しい——前提は、負けても耐えられるかどうかだ。

まず両者の賭けについて。AI 業界が賭けているのは「先にリリースしてから直す」：対話型プロダクトが間違えた時のコストはひどい回答1回分で、閉じて開き直せばそれで終わりだから、週次更新、さらには日次更新も合理的だ。Java が賭けているのは逆の方向だ：言語仕様は一度確定したら永久的で、ジェネリクスの型消去は20年以上前から指摘されているが今も戻っていないし、検査例外の論争は JDK 5 から今日まで続いている。一度取り消せない決定なら、何年もかけて磨くのは理性であって、先延ばしではない。しかも「プレビュー」という仕組み自体が先延ばしに対抗するものだ——数百万の本番環境ユーザーが機能確定前に実戦で試し、フィードバックが直接仕様を変える。構造化並行処理は第1版から第7版まで磨き、修正されたのはまさに実際のユーザーが踏んだ落とし穴だ。もちろん、代償は現実のものだ：今年欲しいプリミティブ型のパターンマッチングは、あと数バージョン待たないと正式版にならない。私の態度は率直だ：スタートアップなら、このペースは息詰まるから無理に合わせるな；15年生き残るシステムを保守しているなら、誰かが代わりにゆっくりしてくれたことに感謝するだろう——機能が3年遅れるのは、間違いが一生ついて回るよりマシだ。

Q3：なぜこのバージョンで最も重要なのは新構文ではなく、2つの「メモリ節約」のデフォルト設定なのか？

永亮：企業の本当の痛みは請求書にあり、構文にはないからだ。9つのJEPのうち、財布への影響が最も直接的な2つが、ちょうどどちらもメモリ節約に関するもの——これは決して偶然ではなく、この言語のユーザー層が決定づけるものだ。

まずバージョンの構造を見てみよう。Java 25は昨年9月のLTSバージョンで、27は非LTS、次のLTSはJDK 29になる予定だ。企業にとって、本当の大規模アップグレードはLTSでのみ発生する。だから27の新機能は、ほとんどの本番環境では29になってようやく実際に使われることになる。ではなぜ27が重要だと言えるのか？ 2つのメモリ節約の機能をデフォルトの挙動にしたからだ。第一に、G1がすべての環境のデフォルトのガベージコレクタになった——以前はGCの選択は論証が必要な技術的決定だったが、今は選ぶ必要がなくなった。大ヒープのサービスでそのまま使えるのは、この一時停止目標で最適化されたコレクタだ。第二に、コンパクトオブジェクトヘッダがデフォルトで有効になり、各Javaオブジェクトのヘッダのメモリ使用量が大幅に削減された。この2つの機能はどちらもセクシーではないが、直接変更するのは請求書だ：ある病院グループが数百のJVMサービスを稼働させていて、ヒープ使用量が1割縮小すれば（これは私個人の試算であり、公式な数字ではない）、節約できるのは実際のメモリ調達費とクラウド費用だ。構文糖は開発者を喜ばせ、小さなヒープは財務を喜ばせる。企業に長くいれば分かることだが、調達申請書に書ける理由は、発表会に書ける理由よりもずっと価値がある。

Q4：ポスト量子鍵交換が TLS 1.3 に導入された——老舗言語は10年後を見据えて布石を打つ、なぜ AI 企業はこれについてほとんど語らないのか？

永亮：両者の顧客は「10年後」の価格付けを全く異なる視点で捉えているからだ。病院のデータは何十年も保存され、「今保存しておき、後で解読する」という脅威は今日すでに発生している。一方、大部分の AI 製品のデータライフサイクルは2年にも満たない。鍵が錆びる前に、製品の方が先に終了してしまう。

JEP 527 が行っているのは、TLS 1.3 のハンドシェイクにおいて、従来のアルゴリズムと耐量子アルゴリズムでそれぞれ鍵を計算し、どちらか一方が破られても致命的にならないようにすることだ。なぜ今やるのか？「今保存しておき、量子コンピュータが成熟してから解読する」という攻撃が、今日すでに発生しているからだ。攻撃者は現在の暗号化トラフィックを傍受して保存し、10年後に鍵を開ける。医療データの保存期間は数十年単位で計算され、今日の受付システムでの一度のハンドシェイクの暗号文は、2040年代になっても法的意義を持つ可能性がある——だから病院にとっては、今すぐ支払うべきリスクであり、10年後の話ではない。一方、大部分の AI スタートアップ企業のデータライフサイクルは2年にも満たず、訓練セットは数ヶ月ごとに入れ替わり、製品の鍵が錆びる前に終了してしまう。当然、鍵の交換を急いで語る者はいない。これは優劣の問題ではなく、時間のスケールが違うのだ。老舗言語のユーザーは2040年の予算を組んでおり、AI 業界の顧客は6ヶ月後に自分がまだ存在しているかどうかを賭けている——それぞれ合理的であり、互いに嘲笑する必要はない。

Q5：Java エコシステムに残っている人への3つの実用的なアドバイス

永亮：3つ、順を追って。本番は LTS のみアップグレード、メモリ節約を正規の指標として扱う、AI にコードは書かせるがアーキテクチャの決定は AI に任せない。

1つ目、本番環境は LTS のみアップグレードし、最新版を追いかけない。Java 25 が現行の LTS であり、27 は試したり、読んだり、チームの技術レーダーとして使ったりするのに使えるが、本番には上げないこと。次の LTS は JDK 29 になる予定なので、その時に 27 と 29 の成熟したものを一緒に取り込めばよい。新バージョンへの不安症はこのエコシステムにおいては偽りの問題であり、本当のリスクは新しさを追いかけたことで起こる互換性の事故である。2つ目、メモリ節約を正規の指標として管理する。コンパクトオブジェクトヘッダーがデフォルトで有効になった後、1週間かけてコアサービスのヒープ使用量を比較・計測する（これは概算レベルの作業だが、方向性は間違っていない）。節約したメモリを金額に換算して四半期のまとめに書き込むこと——JVM チューニングの成果を上司に見せることは、技術記事を10本書くよりも役立つ。3つ目、AI にコードは書かせるが、AI にアーキテクチャの決定は任せない。AI が生成するコードはますます増えているが、依存先を誰にするか、サービスをどう分割するか、データをどう流すか、これらの決定の影響は年単位で及ぶため、人が責任を負わなければならない。構造化並行性が第7回のプレビューまで練られてもまだ確定していないことは、まさに並行性モデルのような決定がいかに困難であるかを示している——7回の公開された精査を経てようやく確定させる勇気を持てるほどに。私は17年ソフトウェアに携わり、70人のチームを率いたが、踏んできた中で最も高くついた落とし穴はすべて「とりあえずこうしておけばいいだろうと思った」当時のアーキテクチャの決定であり、文法の使い間違いは一つもなかった。

エピローグ

拾聞：最後に、一言で今回をまとめていただけますか？

永亮：AI がコードをどれだけ速く書くかを決め、JVM がシステムをどれだけ安定して動かすかを決める——より速く書く時代において、安定すること自体が競争力になる。

拾聞：この言葉を、皆さんへ。次回お会いしましょう。

【技術深掘】オブジェクトヘッダに潜む、あなたが書いたことのないオーバーヘッド——G1とコンパクトオブジェクトヘッダがどう連携して節約するのか

この号のメインテーマは「メモリ節約は新文法よりも企業の真のペインポイントに近い」です。もう一歩深く踏み込みたい読者のために、一層剥がしてみましょう：なぜ二つの目立たないデフォルト項目が、JDK 27の最も重要な二つのポジションを占めるに値するのか。

第一層：オブジェクトヘッダに何が格納されるのか。 Javaでは、あなたが書いたフィールドのほかに、各オブジェクトはヘッダを背負っています：mark wordがハッシュコード、ロック状態、GCマークを記録し、さらにクラスメタデータへのポインタが付加されます。これらの情報はあなたが一行もコードを書いていないのに、すべてのオブジェクトが背負っているのです。

第二層：なぜこのオーバーヘッドが無視できないのか。 64ビットマシンで圧縮ポインタがデフォルトで有効な場合、オブジェクトヘッダは通常12バイトを占めます——オブジェクトが小さいほど、ヘッダの割合が厳しくなります。二つの整数だけを格納するオブジェクトは、データが8バイト、ヘッダが12バイトで、メモリの過半数が「手荷物」に費やされます。アプリ内に数百万の小さなオブジェクトを持つサービス（キャッシュ、セッション、メッセージキューはいずれも被災地）では、ヒープの大部分はデータではなく手荷物なのです。

第三層：二つのJEPがどう連携して節約するのか。 コンパクトオブジェクトヘッダ（JEP 534、この版でデフォルト有効）はヘッダ情報を再エンコードし、この部分の占有を顕著に圧縮します；G1（JEP 523、すべての環境のデフォルトに）はヒープを一つ一つのRegionに切り分け、ポーズ目標に従って回収し、大ヒープサービスはもう回収器選びで悩む必要がありません。一方は各オブジェクトをよりスリムに、一方はヒープ全体の管理をよりスムーズに。

本号のメインテーマに戻りましょう：新文法が解決するのは「コードを書く心地よさ」、オブジェクトヘッダと回収器が解決するのは「請求書の痛み」です。企業にとって、痛いところは決してキーボード上にはありません。

本期情報源

OpenJDK announce メーリングリスト 2026-09-15：Mark Reinhold『JDK 27 General Availability』（build 35、9個のJEPリスト付き）
jdk.java.net/27（GPLv2ライセンスのOpenJDKビルドダウンロード）
OpenJDKの半年リリースサイクルとLTS命名慣例（2026-09-16時点の情報、次のLTSはJDK 29を予定）