本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

開発・技術

Node.js 24は10月20日に保守期へ — 26 LTS化で決める更新計画

鈴木 翔公開 参考情報・出典
目次 · 7項目

数年前にNode.js 18や20で作った社内システムやWebのバックエンドが、いまも問題なく動いている。保守ベンダーに版の更新を相談しても「動いているので急ぐ必要はない」と返ってくる。ところがNode.js 20は2026年4月30日でサポートを終えており、その後に出たセキュリティ修正は20には届いていません。

2026年10月には、さらに2つの切り替わりがあります。10月20日にNode.js 24が保守期（Maintenance）へ、10月28日に26がLTSへ移ります。公式のスケジュールと告知を照合し、どの版で運用し、いつ上げるかを決める材料を整理します。

「まだ動く」と「まだ直る」は別の話

Node.jsの公式ブログによると、2026年6月18日と7月29日のセキュリティリリースは、どちらも26.x・24.x・22.xの3系列が対象でした。7月の告知には、深刻度Highの3件を含む11件の脆弱性（CVE）が並んでいます。HTTP/2の処理でメモリを使い切らせる問題や、HTTPSのAgentが接続を使い回すときにホスト名の検証が抜ける問題などです。

公式の配布一覧（dist/index.json）では、20.xの最後の版は2026年3月24日の20.20.2です。3月のセキュリティリリースまでは20.xも対象でしたが、以降の修正は入っていません。7月の告知は「End-of-Life versions are always affected when a security release occurs.」（サポートが終わった版は、セキュリティリリースのたびに常に影響を受ける）と書いています。

もう1つ、メジャー版だけでなくパッチ版も見る必要があります。編集部の検証環境（Linux）のNodeは、執筆時点でv22.22.0でした。22.xの7月の修正版は22.23.2なので、この環境は修正前のままです。「22を使っている」だけでは足りず、node -v の値まで確かめます。2026年10月1日時点の最新は、24.xがv24.21.0、22.xがv22.23.3、26.xがv26.10.0です。

2026年10月に何が切り替わるか

Node.jsのリリースワーキンググループのリポジトリ（nodejs/Release）は、版の段階を3つに分けています。変更を広く取り込む「Current」、監査を経た新機能・修正が入る「Active LTS」、重大なバグ修正とセキュリティ修正に絞る「Maintenance」です。日付は同リポジトリの schedule.json にあります。

版初回リリースLTS入り保守期へサポート終了
20.x2023-04-182023-10-242024-10-222026-04-30（終了済み）
22.x2024-04-242024-10-292025-10-212027-04-30
24.x2025-05-062025-10-282026-10-202028-04-30
26.x2026-05-052026-10-282027-10-202029-04-30

Node.js 20・22・24・26の各版がCurrent、Active LTS、保守期を経てサポート終了に至る期間を2023年から2029年の時間軸に並べ、2026年10月1日の位置と、24の保守期入り（2026-10-20）・26のLTS入り（2026-10-28）・22の終了（2027-04-30）を示した図

図の縦線が2026年10月1日です。24.xは10月20日に保守期へ入りますが、終了は2028年4月30日のままで、使える期間は縮みません。26.xは10月28日にLTSへ移ります。5月の26.0.0の告知も、10月まではCurrentだと書いています。22.xはすでに保守期で、残りはおよそ7か月です。

READMEには「Dates are subject to change.」（日付は変わることがある）とあり、変更する場合は14日以上前に知らせるとしています。計画に使う日付は schedule.json を正とし、着手前にもう一度確かめてください。

26は旧方式の最後、27から毎年LTSに

2026年3月10日付の公式ブログの告知「Evolving the Node.js Release Schedule」で、27.xからメジャー版を年1回にすることが示されました。

  • 毎年4月にメジャー版、10月にLTSへ。 奇数・偶数の区別がなくなり、「Node.js 27 will become LTS」と明記されています
  • 2026年10月からAlphaチャネル。 互換性を壊す変更も入り、告知は「Not intended for production use.」（本番利用は想定していない）としています。schedule.json にも27.xのalphaが2026-10-28と載っています
  • LTSはおよそ30か月のまま。 最初のCurrentから終了までは36か月です。27は2027年10月にLTS、2030年4月に終了の予定です

告知の背景はNode.jsの年1回メジャーリリース化の記事でも取り上げました。ここからは編集部の整理です。27以降は毎年10月にLTSが1つ増えるため、運用側は「毎年上げる」か「2年に1回、終了の半年ほど前に上げる」かを選びやすくなります。ただし告知自身が「This schedule is not final and may be amended.」と書いており、27以降の日付は予定です。なお、nodejs/ReleaseのREADMEの「Release Plan」の節は、10月1日時点で旧方式の説明のままでした。

いま動いている版ごとの判断

10月1日時点の公式の日付をもとにした、編集部の提案です。

本番で動いている版状態（10月1日時点）編集部の提案
20.x以前終了済み。6月・7月の修正は対象外最優先で24か26へ。移行が長引くなら外部から届く経路を絞る暫定策も検討
22.x保守期。2027-04-30に終了24か26への移行を2027年の早い時期までに終える計画を立てる
24.x10月20日に保守期へ。2028-04-30に終了最新のパッチ版を追いつつ、26への移行を2027年中に検討
新規開発・大きな改修26.xは10月28日にLTS26を本命に。本番投入はLTS入りの後とし、それまでは検証環境で確認

20から上げる先は、サポートの残りで選ぶと分かりやすくなります。24の終了は2028年4月、26は2029年4月で1年の差があります。すぐ本番へ出したいなら24、移行作業がLTS入り以降にかかるなら26、という分け方ができます。

上げる前に確かめること（編集部の提案）

1. 版を固定している場所を洗い出す

Node.jsの版は、1つのシステムの中でも複数の場所に書かれています。編集部では、.nvmrc・package.json・Dockerfile・GitHub Actionsのワークフローに20を書いた検証用リポジトリを作り、次のコマンドで一覧にできることを確かめました（Linux、git 2.43.0）。

git grep -nE 'node-version|"node" *:|FROM +node:|^(nodejs|node) |^v?[0-9]+' \
  -- .nvmrc .node-version .tool-versions package.json 'Dockerfile*' '.github/workflows/*'
.github/workflows/ci.yml:10:          node-version: 20
.nvmrc:1:20
Dockerfile:1:FROM node:20-bookworm-slim
package.json:4:  "engines": { "node": ">=20" }

リポジトリの外にも、本番サーバーに直接入れたNodeや、ホスティング・サーバーレスのランタイム設定があります。各事業者がいつまで22や24を提供するかは本記事では確認していないため、利用中の事業者の案内で確かめてください。

2. engines は止めてくれない前提で扱う

npmのドキュメント（v10）は、engine-strict を設定しない限り engines は「advisory only」（参考情報）だと説明しています。編集部の検証環境（Linux、Node v22.22.0、npm 10.9.4）で "node": ">=99" と書いたプロジェクトを npm install すると、npm warn EBADENGINE の警告が出たうえで成功し、終了コードは0でした。--engine-strict を付けると npm error code EBADENGINE で止まり、終了コードは1でした。CIで版の食い違いを止めたいなら、この設定を入れた npm install を手順に加えます。

3. CIで移行先の版を先に通す

actions/setup-node は node-version-file で .nvmrc や package.json から版を読めます（同アクションのREADMEに記載）。版の記述を1か所に寄せると、上げるときの変更漏れを減らせます。

4. 互換性を壊す変更を読む

公式の移行ガイドは10月1日時点で「v22 to v24」まで掲載されています。24では、OpenSSL 3.5の既定のセキュリティレベル2により2048ビット未満のRSA鍵やRC4の暗号スイートが使えません。古い取引先や機器とTLSでつなぐ処理は先に試します。32ビットWindows向けのビルド済みバイナリは23.0.0から提供されていません。

24から26への移行ガイドは未掲載でした。26.0.0の告知には、http.Server.prototype.writeHeader() や _stream_readable などの古いモジュールの削除、Temporal APIの既定での有効化、Undici 8への更新、module.register() の非推奨化が並んでいます。依存パッケージも含めて使っていないかを検索し、テストで確かめます。

5. パッチ版を追う担当を決める

LTSでもパッチ版を上げなければ修正は入りません。セキュリティリリースの告知を受け取る担当と、本番へ出すまでの期限を決めておきます。修正の頻度が上がったときに詰まりやすい点はJavaの月次セキュリティパッチの記事でも整理しました。

落とし穴

  • 10月28日より前に26を本番に入れる。 その時点の26はまだCurrentです
  • 27のAlphaを本番で使う。 使うのはライブラリの互換性確認やCIまでです
  • engines だけ書き換えて終わる。 既定では警告だけで、DockerfileやCIの版は変わりません。FROM node:20 のまま再ビルドもしていないコンテナも同じです
  • 保守期を「サポート切れ」と読み違える。 24は2028年4月30日までセキュリティ修正の対象です。20以前や22からの移行を先にする判断もあります

2026年10月1日に、nodejs/Releaseのリポジトリ（commit 72fdab2）のREADMEと schedule.json、公式ブログの告知「Evolving the Node.js Release Schedule」、26.0.0・26.10.0・24.21.0・22.23.3のリリース告知、2026年3月・6月・7月のセキュリティリリースの告知、移行ガイド（v22 to v24）、配布一覧（dist/index.json）を直接開いて照合しました。engines の挙動と版の洗い出しは、編集部の検証環境（Linux、Node v22.22.0、npm 10.9.4）の検証用プロジェクトで1回ずつ確認したものです。実際の業務システムを24・26へ上げる作業、26での動作、ホスティング各社やコンテナイメージのサポート期間は確認していません。

Node.jsで動く業務システムの更新計画や、移行に向けた改修のご相談は、グリームハブへお問い合わせください。

Sources

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事から、もう一歩先の検討へ。

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る