Node.js 26が10月28日にLTSへ。24はメンテナンスに入り、27からは年1回のリリースに変わる

こんにちは、インフラエンジニアのryuです。

2026年の10月は、Node.jsのバージョンの区切りが重なる月です。

10月20日にNode.js 24がメンテナンスの段階に入り、10月28日にはNode.js 26がLTS（長期サポート）になります。同じ日に、次のNode.js 27のAlpha版の提供も始まる予定です。

そして27からは、リリースの出し方そのものが変わります。年に2回だったメジャーリリースが年1回になり、奇数・偶数の区別もなくなります。

アプリを書くのは開発チームでも、Node.jsを入れたサーバーやコンテナのイメージ、Lambdaの設定を持っているのはインフラエンジニアということも多いですよね。

この記事では、10月に何が変わるのかと、自分の環境で動いているNode.jsの調べ方、上げる順番の考え方を見ていきます。

2026年10月のNode.jsで何が変わる？¶

最初に、Node.jsのリリースの段階を確認しておきます。

Node.jsのメジャーバージョンは、出てすぐの「Current」から始まり、偶数のバージョンだけが「Active LTS」に上がります。そのあと「Maintenance」に移り、最後にサポート終了（EOL）を迎えます。

Active LTS と Maintenance の違い：Active LTS の期間はバグ修正や一部の機能追加も取り込まれます。Maintenance に入ると、重大なバグの修正とセキュリティ修正だけになります。

バージョンごとの日程¶

Node.jsのリリースチームが公開している schedule.json をもとに、いま現場で見かけそうなバージョンを表にまとめました。

この表を見ると、10月20日から27日までの1週間ほどは、Active LTSのバージョンが1つもない状態になることが分かります。10月28日に26がActive LTSに上がり、この空白が埋まります。

24は今日からMaintenanceに入りますが、セキュリティ修正は2028年4月まで続きます。すぐに使えなくなるわけではないので、慌てる必要はありません。

Node.js 20はすでにサポートが終わっている¶

見落としやすいのが、Node.js 20です。

Node.js 20は2026年4月30日でサポートが終わっていて、それ以降はセキュリティ修正が出ていません。Node.js 18も、2025年4月30日に終わっています。

2023年ごろに作ったサーバーやコンテナのイメージは、当時のLTSだった18や20のまま止まっていることがよくあります。今回の区切りをきっかけに、まずは20以前が残っていないかを確認しておくのがおすすめです。

Node.js 27からのリリース方式の変更とは？¶

今回いちばん大きな変化は、27からの新しいリリース方式です。

Node.jsのリリースチームは「Evolving the Node.js Release Schedule」という告知で、27からはメジャーリリースを年1回にすると発表しています。理由として挙げられているのは、4つも5つものリリースラインに並行してセキュリティ修正を出し続けるのが、ボランティア中心の体制では難しくなってきたことです。

告知の内容を、今までの方式と比べてみます。

新しい方式では、10月から翌年3月までがAlpha、4月から10月までがCurrent、そこから30か月がLTSという流れになります。

27の場合は、2026年10月にAlphaが始まり、2027年4月に27.0.0、2027年10月にLTS入り、2030年4月にサポート終了という予定です。告知には、この日程は確定ではなく変更される可能性があるとも書かれています。

Alpha版は本番で使うものではない¶

新しく加わるAlpha版は、ライブラリの作者やCIで、互換性のない変更を早めに試すためのものです。

告知でも、Alpha版は本番環境での利用を想定していないと書かれています。インフラエンジニアとしては、サーバーに入れるのはあくまでLTSのバージョン、という考え方は今までと変わりません。

奇数バージョンがなくなると何がうれしい？¶

今までは、25のような奇数バージョンは約8か月でサポートが終わりました。

最新に追従しようとして奇数版を本番に入れると、半年ほどで次に上げる必要があり、運用の手間が増えていました。27以降はすべてのバージョンがLTSになるので、「このバージョンはLTSになるのか」を気にする必要がなくなります。

バージョン番号がリリースの年と一致するのも、運用する側にはありがたい点です。たとえば28なら2028年に出たもの、と番号だけで古さの見当がつきます。

サーバーで動いているNode.jsの調べ方¶

ここからは、自分の環境にどのバージョンのNode.jsが入っているかを調べる方法です。

Node.jsは入れ方がいくつもあるので、1台のサーバーに複数のバージョンが入っていることも珍しくありません。まずはPATHの上で見えているものを確認します。

# いま使われるNode.jsのバージョン
node -v

# PATHのなかにある node をすべて表示する（複数入っていないか）
which -a node

# OSのパッケージとして入っているか（Ubuntu / Debian）
apt policy nodejs

# OSのパッケージとして入っているか（RHEL系 / Amazon Linux）
dnf list installed 'nodejs*'

# nvm で入れたバージョンの一覧
nvm ls

which -a node で複数のパスが出てきたら、OSのパッケージとnvmなどのバージョン管理ツールが混在しています。サービスとして動いているNode.jsは、systemdのユニットファイルに書かれたパスを見ないと分からないこともあります。

# サービスがどの node で起動しているかを、実行中のプロセスから確認する
ps -eo pid,args | grep [n]ode

# プロセスの実体のパスを確認する（PIDは上のコマンドの結果に置き換える）
readlink /proc/<PID>/exe

OSの標準パッケージのNode.jsに注意¶

OSのリポジトリから入れたNode.jsは、Node.jsの公式のサポート期限とは別の扱いになります。

たとえばUbuntu 24.04の標準リポジトリ（universe）に入っている nodejs パッケージは、18系の 18.19.1 です。Node.jsの公式サポートはすでに終わっているバージョンなので、apt install nodejs で入れただけの環境は一度見直したほうがよいでしょう。

新しいLTSを使いたい場合は、Node.jsの公式のバイナリやパッケージ、nvmのようなバージョン管理ツール、公式のコンテナイメージなどから入れる方法が一般的です。

コンテナとLambdaも確認する¶

サーバーだけでなく、コンテナのイメージとAWS Lambdaも見ておきましょう。

コンテナは、Dockerfileの FROM に書かれたイメージのタグを見るのが早いです。node:20 や node:20-alpine のように書かれていれば、サポートが終わったバージョンです。コンテナの基本は『Docker入門』でもまとめています。

# リポジトリ内のDockerfileで、nodeのイメージを使っている行を探す
grep -rn "^FROM node" --include=Dockerfile* .

# 動いているコンテナの中のNode.jsのバージョン
docker exec <コンテナ名> node -v

Lambdaは、関数ごとにランタイムが設定されています。AWSのドキュメントでは、nodejs20.x のランタイムは2026年4月30日に非推奨（deprecated）になったと案内されています。

# Node.js のランタイムを使っている関数の一覧を出す
aws lambda list-functions \
  --query "Functions[?starts_with(Runtime, 'nodejs')].[FunctionName,Runtime]" \
  --output table

非推奨になったランタイムには、セキュリティ修正が提供されなくなります。そのあとに関数の作成や更新ができなくなる日も決められていますが、この日付は変更されることがあるので、AWSのランタイムの一覧ページで最新の日付を確認してください。EC2とLambdaの使い分けについては『EC2とLambdaの違い』で整理しています。

調べた結果は一覧にしておく¶

調べた結果は、その場で一覧表にまとめておくと、あとで上げる順番を決めるときに役立ちます。

項目は多くなくて大丈夫です。たとえば次のような形で、どこで・どのバージョンが・どう入っているかが分かれば十分です。

担当の列を入れておくのがポイントです。Node.jsは、サーバーはインフラエンジニア、イメージやLambdaは開発チーム、というように持ち主が分かれやすいので、誰が上げるのかをはっきりさせておかないと作業が止まりがちです。

いつ、どのバージョンに上げればいい？¶

調べた結果をもとに、上げる順番を考えます。

基本の考え方は、サポートが終わったものから先に片付けて、LTSになって少したったバージョンに移す、というものです。状況ごとにまとめると、次のようになります。

新しく作るシステムなら、10月28日以降は26を選んでよいと思います。

一方で、いま20で動いているシステムを一気に26まで上げると、確認する範囲が広くなります。動作確認の手間を考えると、まず24に上げてから、落ち着いたところで26を検討する、という2段階の進め方も現実的です。

メジャーバージョンを上げるときの確認ポイント¶

Node.jsのメジャーバージョンを上げるときに、インフラ側で引っかかりやすい点がいくつかあります。

1つ目は、C++で書かれたネイティブアドオンを使っているパッケージです。ネイティブアドオンはNode.jsのメジャーバージョンごとにビルドし直す必要があるので、node_modules を古いバージョンでインストールしたまま使い回すと、起動時にエラーになります。

# Node.jsを上げたあとは、依存パッケージを入れ直す
rm -rf node_modules
npm ci

# 入れ直せない事情がある場合は、ネイティブアドオンを再ビルドする
npm rebuild

2つ目は、package.json の engines や .nvmrc にバージョンが固定されていないかです。ここが古いままだと、CIやデプロイのツールが古いバージョンを使い続けることがあります。

3つ目は、CIのテスト対象のバージョンです。GitHub Actionsなどで、テストを20と22だけで回しているなら、上げる先のバージョンを先に追加しておくと、問題に早めに気づけます。

上げる作業そのものより、どこにNode.jsが入っているかを洗い出す作業のほうが時間がかかることが多いです。サーバー・コンテナ・Lambda・CIの4か所を、一覧にしておくと次回が楽になります。

年1回のリリースに合わせた計画の立て方¶

27からは毎年4月に新しいバージョンが出て、10月にLTSになります。

サポートは36か月なので、毎年10月のLTS入りを目安に、2年に1回くらいのペースで上げていけば、サポートが切れた状態にならずにすみます。毎年同じ時期に予定が来るので、Pythonや.NETのように、年間の保守計画に組み込みやすくなるはずです。

同じように毎年サポート終了が来るソフトウェアとしては、『Python 3.10のサポート終了』や『PHP 8.2のサポート終了』の記事も参考にしてみてください。

まとめ¶

最後に、この記事の内容を振り返ります。

• 2026年10月20日にNode.js 24がMaintenanceに入り、10月28日にNode.js 26がLTSになる
• Node.js 20と25はすでにサポートが終わっていて、セキュリティ修正が出ていない
• 27からはメジャーリリースが年1回になり、すべてのバージョンがLTSになる
• サーバー・コンテナ・Lambda・CIのそれぞれで、使っているバージョンを確認する
• 古いバージョンから優先して、LTSのバージョンへ段階的に上げる

まず確認したいのは、20以前のNode.jsがどこかに残っていないかです。node -v を打つだけでも分かるので、手元のサーバーから見てみてください。

Node.jsのバージョン管理も、結局はLinuxのパッケージ管理やプロセスの調べ方といった基礎の上に成り立っています。InfraAcademyでは、Linuxの基本を順番に学べる『Linuxのロードマップ』と、Lambdaを含むAWSのサービスを学べる『AWSのロードマップ』を用意しているので、あわせて活用してみてください。

Node.jsの使い方そのものを勉強したい方は、『Node.jsのおすすめ参考書』も参考になると思います。

参考¶

• Evolving the Node.js Release Schedule（Node.js公式ブログ）
• nodejs/Release schedule.json（GitHub）
• Node.js Releases（Node.js公式）
• Lambda runtimes（AWS Lambda ドキュメント）
• nodejs（Ubuntu noble のパッケージ）