Node.js 26.0.0が出た、Temporal標準有効化と10月LTS待ちの現実

Node.js 26.0.0が2026年5月5日に出た。
派手な新機能ラッシュというより、Temporalを標準で使えるようにし、V8とUndiciを更新し、古いAPIを削るメジャーリリースだった。
本番環境の移行先としてはまだCurrentで、LTS入りは2026年10月予定だ。

Node.js 20は2026年4月30日にEOLになっている。
古いNodeを残しているなら、26へ飛ぶより先に24 LTSか22 LTSへ寄せる判断のほうが現実的だ。
このブログでも以前、Node.jsのセキュリティリリース延期と対象バージョンを見たが、EOL後のラインはセキュリティ修正から外れる。

Temporalがフラグなしになった

いちばん分かりやすい変更はTemporal APIの標準有効化だ。
Dateの代替として設計された日時APIで、日付、時刻、タイムゾーン、期間を別々の型として扱える。

Dateは便利だが、ローカルタイムゾーン、UTC、文字列パース、月末計算が混ざるとすぐ読みにくくなる。
Temporalでは、カレンダー上の日付だけならTemporal.PlainDate、タイムゾーン込みの日時ならTemporal.ZonedDateTimeのように、値の意味を型で分ける。

const releaseDate = Temporal.PlainDate.from("2026-05-05");
const ltsDate = releaseDate.add({ months: 5 });

console.log(releaseDate.toString());
console.log(ltsDate.toString());

これはブラウザ互換を考えずNode.js上だけで動くバッチ、CLI、サーバ側の予約・請求・ログ処理ではかなり使いやすい。
逆に、フロントエンドと同じコードを共有する場合は、対象ブラウザ側のTemporal対応を別に見る必要がある。

ブラウザでTemporalは使えるのか

Node.js 26でフラグなしになったが、フロントエンドでも同じコードを動かしたいなら話は別だ。
2026年5月時点で、Chrome 144+、Edge 144+、Firefox 139+がTemporal対応済み。
Can I Useの集計で全体カバー率は約69%、残りの大半はSafariだ。

SafariはTechnology Previewでもデフォルト無効のままで、安定版には入っていない。
iOSのブラウザは内部的にすべてWebKitなので、iOS Safari非対応＝iPhone・iPad全滅になる。
日本のモバイルシェアを考えると、Safariを切れるプロジェクトはまずない。

TC39ではStage 4（最終段階）に達していて、ECMA-262への統合作業中だ。
仕様は確定しているのでSafari側の実装が追いつけば使えるが、時期はAppleのリリース次第で読めない。

ポリフィルは2つある。
TC39チャンピオンズ公式の@js-temporal/polyfillはフルスペック準拠だが、minify+gzipで約56KB。
FullCalendarのtemporal-polyfillは主要APIに絞って約20KB。
date-fnsが関数単位でtree-shakeすれば数KBで済むのと比べると、どちらも重い部類だ。

globalThis.Temporalの存在チェックで条件付きロードすれば、Chrome・Firefox・Edgeのユーザーにはポリフィルを読ませずに済む。
ただしSafariユーザーには常にバンドルコストが乗る。
フロントで使うなら、ポリフィルサイズとSafariの対応時期を天秤にかけて判断することになる。

V8 14.6とUndici 8はランタイムの地味な差になる

Node.js 26はV8 14.6.202.33を積む。
公式リリースでは、Map.prototype.getOrInsert()系のUpsert提案と、Iterator.concat()のIterator sequencingが挙げられている。

このへんはアプリコードをすぐ書き換える話ではない。
新しい構文・組み込みAPIが使える範囲、V8の最適化、ネイティブアドオンの互換性に出る差だ。
Node.js 24がV8 13.6、npm 11、URLPatternグローバル化を前に出していたのと比べると、26は「実装基盤の更新」感が強い。

HTTPクライアント側ではUndici 8.0.2に上がった。
Node.jsのfetchはUndiciの上に載っているので、外向きHTTP、ストリーミング、接続管理の細かい挙動に影響する。
fetchを多用するAPIサーバやクローラーでは、CIだけでなくステージングの通信パターンでも確認したほうがいい。

消えたAPIと警告が移行コストになる

メジャーリリースなので、古いAPIの削除も入っている。
http.Server.prototype.writeHeader()は削除され、writeHead()へ寄せる必要がある。
_stream_readable、_stream_writable、_stream_duplexなどのレガシーな_stream_*モジュールも削除された。

アプリ本体で直接触っていなくても、古いライブラリが内部で使っている場合がある。
Node.js 26を試すなら、まずテストログの警告と失敗を拾うほうが早い。

nvm install 26
nvm use 26
npm test

nvm（Node Version Manager）はNode.jsのバージョンをユーザー単位で切り替えるCLIツールだ。
~/.nvm/ 以下にバージョンごとのバイナリを持ち、nvm use でシェルセッション内のNodeを即座に切り替える。
未導入ならnvm公式リポジトリのインストールスクリプトを実行し、.bashrcか.zshrcにセットアップ行を足せばすぐ使える。

Voltaを使っている環境では、Node本体の切り替えとグローバルCLIの実体がずれることがある。
以前書いたVoltaのメンテナンス終了と移行メモの通り、shimがPATHを横取りする構造なので、Node 26検証時はwhich nodeとnode -vを先に見る。

26は最後の旧スケジュール世代

Node.js 26はCurrentとして出て、2026年10月にLTSへ入る予定だ。
公式のリリーススケジュール変更告知では、Node.js 27以降は年2回のメジャーリリースから年1回へ変わる。
奇数版はLTSにならない、という古い見方もNode.js 27から崩れる。

今すぐ26へ移る理由があるのは、TemporalやV8 14.6を早めに検証したいライブラリ作者、Node.jsランタイム差分をCIで先に踏みたいチーム、Current追従の開発環境を持っている人あたりだ。
普通のWebアプリ本番なら、24 LTSを使いながら26をCIに足し、10月のLTS化後に移行判断でよい。

かつてはIEを切れるかどうかがWeb技術採用のラインだったが、今はSafariがその位置にいる気がする。
Nodeはブラウザで直接動かすものではないが、周辺技術が対応してないからポリフィル当てておけ、という構図はかつてのIEとjQueryそのものだ。