Node.js LTSの最新は24、10月28日に26へ昇格｜v22・v24のEOLと確認・固定・移行の手順

2026年10月27日時点のNode.jsの最新LTSはv24です。v24（Krypton）は10月20日にMaintenance LTSへ移っており、10月28日にv26がActive LTSへ昇格する予定です。昇格後の最新LTSは26になります。v22（Jod）のサポートは2027年4月30日まで、v24は2028年4月30日までです。この記事では、各版のEOL日、実行中の版がLTSかを確かめるコマンド、nvmとpackage.jsonでの版固定、GitHub ActionsとDockerでの揃え方、次のLTSへ移る時期の決め方を、実行結果つきで説明します。

まとめ：Node.js LTSの最新版とEOL、版固定で先に決めること

本番で使ってよいのはActive LTSかMaintenance LTSの版だけです。新規案件は、v26の昇格（10月28日予定）を確かめてからv26を選びます。既存のv24案件はそのままv24を使い続けて構いません。v22は2027年4月30日のEOLまでに移行を終えてください。v20は2026年4月30日にサポートが終わっており、10月21日のセキュリティリリースでも修正版は出ていません。

次に、版の指定を「追従」にするか「固定」にするかを決めます。lts/*やnode:ltsは最新のLTSに追従するので、v26のLTS版が公開される（10月28日予定）と、指すメジャー版が24から26へ変わります。本番のDockerイメージや納品物ではメジャー番号を固定し、EOLまでの残り日数をCIで監視して計画的に上げる運用を勧めます。Dockerのnode:lts-jodタグは22.21.0のまま1年間更新されていないので、系列を固定するときはnode:22のような版番号のタグを使ってください。

Node.js LTSの3段階とv20〜v27のリリース・EOL一覧

Current・Active LTS・Maintenance LTSの期間と修正対象

Node.jsの各メジャー版は、まずCurrentとして6か月公開されます。公式のリリース一覧ページによると、Node.js 26までは奇数番号の版が6か月でサポート終了となり、偶数番号の版だけがActive LTSへ進みます。LTSは重大なバグ修正を合計30か月ほど受けられる系列で、同じページは本番アプリケーションにActive LTSかMaintenance LTSだけを使うよう書いています。

Active LTSの期間はCurrentから機能のバックポートも入りますが、Maintenance LTSに入ると重大なバグ修正とセキュリティ修正に絞られます。Node.js自体の仕組みとインストールの基本はNode.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説で扱っているので、ここでは運用の日付に絞ります。

v20・v22・v24・v26・v27の開始日・LTS移行日・EOL日の比較表

日付はNode.js Release Working Groupが公開しているschedule.jsonを2026年10月27日に取得した値です。最新パッチは公式配布のindex.jsonから取りました。

v26のコードネームは、10月27日時点のschedule.jsonではまだ空欄です。公表されるまで、lts/<名前>形式で26を指定することはできません。

10月28日に予定されるv26のLTS昇格と最新版の切り替え

10月には2つの切り替えが8日違いで続きます。10月20日にv24がMaintenance LTSへ移り、10月28日にv26がActive LTSへ昇格する予定です。昇格した時点で「最新のLTS」は24から26に変わります。

v24を使い続けること自体は問題ありません。EOLは2028年4月30日で、残りは1年半あります。影響を受けるのは、版をlts/*のような追従指定で書いているリポジトリです。昇格後に最初に走るCIやイメージのビルドで、メジャー版が26に上がります。26で入ったTemporal APIの既定有効化や削除されたAPIはNode.js 26の新機能と破壊的変更・LTS移行日で扱っています。

Node.js 27以降の年次リリースと全メジャー版のLTS移行

Node.js 27からはリリースの周期が変わります。previous-releasesページによると、27以降は年1回のリリースになり、すべてのメジャー版が6か月のAlphaと6か月のCurrentを経てLTSへ移ります。schedule.jsonでは、27のAlphaが2026年10月28日、Currentが2027年4月22日、LTS移行が2027年10月20日です。「偶数版だけがLTS」という選び方が当てはまるのは26までです。

2026年10月21日のセキュリティリリースと系列ごとの修正版

2026年10月21日、Node.jsはv26・v24・v22の3系列にセキュリティリリースを出しました。修正された脆弱性は10件で、深刻度はHigh 4件・Medium 3件・Low 3件です。全10件の内容と影響の判定方法はNode.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順で扱っています。LTSのメジャー版を固定している案件でも、同じメジャー版の中でパッチ版は上げる必要があります。

版と同梱npmの値はindex.jsonで確かめたもので、3つの版にはいずれもsecurityフラグが付いています。High 4件のうちCVE-2026-111497は、同梱のBrotliデコーダーの範囲外書き込みでリモートからのコード実行につながりうる問題です。node:zlibでBrotliの圧縮データを展開するサーバーは、最初に更新してください。useSnapshotを有効にしたSEA（単一実行ファイル）ではcrypto.randomUUID()の値がプロセス間で重複しうる問題（CVE-2026-106074）も直っており、SEAは再ビルドしないと修正が入りません。

公式は、サポートが終わった版はセキュリティリリースのたびに影響を受けると書いています。v20にはNode.jsプロジェクトから修正版が提供されないため、原則としてサポート中のLTSへ移行してください。移行までのつなぎとして、公式のEOLページはHeroDevs・NodeSource・TuxCareによる商用のセキュリティ修正サービスを案内しています。

手元やサーバーの版が修正版に届いているかは、次の1行で判定できます。2026年10月27日に実行すると、v26.5.0では「要更新」、v24.22.1では「修正済み」と出ました。v20など表に無い系列も「要更新」になります。

$ node -e "const [a,b,c]=process.versions.node.split('.').map(Number);const fix={22:[23,4],24:[22,1],26:[12,1]}[a];console.log(fix&&(b>fix[0]||(b===fix[0]&&c>=fix[1]))?'修正済み':'要更新')"
要更新

実行中のNode.jsがLTSかを確認するコマンドとindex.jsonの読み方

process.release.ltsとnode -vによるLTSビルドの判定

実行中のNode.jsがLTSかどうかは、版番号よりprocess.release.ltsで見るほうが確実です。公式APIドキュメントのprocess.releaseによると、このプロパティはLTS版にだけあり、コードネームの文字列を返します。Current版ではundefinedです。公式配布のv24.22.1と手元のv26.5.0で実行した結果が次のとおりです。

$ node -v
v24.22.1
$ node -p "process.release.lts"
Krypton

# Current版（v26.5.0）で実行した場合
$ node -p "process.release.lts"
undefined

サーバーの棚卸しでは、この2行でSSHセッションが参照するNode.jsの版とLTSビルドかどうかを確認できます。稼働サービスが別のPATHやコンテナを使う場合は、その実行環境でも確認してください。LTS名が返っても、サポート期間内とは限りません。v26は10月28日の昇格後に出るパッチ版から、同じコマンドでコードネームを返すようになります。昇格前にビルドされた26.12.1以前は、昇格後もundefinedのままです。

index.jsonによる直近2つのLTS系列の最新リリース取得

index.jsonは公式が配布している全リリースの一覧で、各要素のltsはfalseかコードネームの文字列です。配列は新しい版から並んでいるので、メジャー番号ごとに最初に出てきた要素がその系列の最新パッチになります。Node.js 18以降はfetchが標準で使えるため、外部パッケージは要りません。

// lts-latest.mjs：LTS系列ごとの最新パッチを表示する
const res = await fetch('https://nodejs.org/dist/index.json');
const releases = await res.json();
const latest = new Map();
for (const r of releases) {
  if (!r.lts) continue;                      // Current版と非LTSを除外
  const major = r.version.split('.')[0];
  if (!latest.has(major)) latest.set(major, `${r.version} ${r.lts} ${r.date} npm ${r.npm}`);
}
console.log([...latest.values()].slice(0, 2).join('\n'));

2026年10月27日に実行すると、v24.22.1 Krypton 2026-10-20 npm 11.19.1とv22.23.4 Jod 2026-10-20 npm 10.9.9の2行が出ました。index.jsonのdateはビルド日で、公開日（10月21日）とは1日ずれます。同梱npmの版も同じ要素から取れるので、npmの版の違いでロックファイルが割れる問題を調べるときにも使えます。

nvm・.nvmrc・package.jsonでLTSを固定する書き方

nvm install –ltsとlts/kryptonのようなコードネーム指定の違い

nvmのREADMEのLong-term Supportの節には、LTSの指定方法が2通り書かれています。nvm install --ltsとlts/*は最新のLTSを、--lts=kryptonとlts/kryptonは特定の系列の最新パッチを指します。2026年10月27日時点のnvmの最新版はv0.40.8です。

# 最新のLTS（v26のLTS版が出るまではv24、出た後はv26）
$ nvm install --lts

# 系列を固定して、その中の最新パッチだけ追う
$ nvm install lts/krypton

# 新しいLTSへ移るとき、グローバルに入れたパッケージとnpmも移す
$ nvm install --reinstall-packages-from=current --latest-npm 'lts/*'

最後の行の--latest-npmは、移行先のNode.jsに対応する最新npmも導入したい場合に付けます。READMEによると、パッケージを入れ直すだけではnpm自体は更新されません。Node.jsだけ上がってnpmが古いまま残る状態を避けるために付けます。nvmを使わない環境なら、miseとは？mise.tomlでツール・環境変数・タスクを束ねる導入手順のmiseか、Nodebrewとは？Node.jsのインストール・切り替え手順と1.2.0の注意点のNodebrewでも版を切り替えられます。Voltaは保守が終わっているので、新しく入れるならVolta（ヴォルタ）とは？Node.jsバージョン管理の使い方と保守終了後の不具合・mise移行を読んでからにしてください。

.nvmrcにlts/*を書くと版が自動で上がる落とし穴と固定の基準

.nvmrcには版番号のほかlts/*も書けます。READMEでも「最新のLTSを既定にする」例として出てきますが、チーム開発には向きません。メンバーがnvm installを実行した日によって、24と26が混在するからです。

固定の基準は次のとおりです。アプリケーションのリポジトリでは24のようにメジャー番号だけを書き、パッチはnvmに最新を取らせます。ネイティブアドオンを含む案件や、ビルド結果の再現性を契約で求められる案件では24.22.1のようにパッチまで書き、セキュリティリリースのたびに書き換えます。lts/*は、個人の検証用リポジトリや、更新時の不具合を許容して随時修正できる社内ツールに限定します。

$ echo "24" > .nvmrc
$ nvm install
$ nvm use
Found '/path/to/project/.nvmrc' with version <24>
Now using node v24.22.1 (npm v11.19.1)

package.jsonのenginesとengine-strictによる版違いの検出

.nvmrcはnvmを使う人にしか効きません。npm側でも版違いを止めるなら、package.jsonにenginesを書きます。npmのpackage.jsonドキュメントによると、engine-strictを設定していない限りenginesは助言の扱いです。

// package.json（抜粋）
{
  "engines": { "node": "^24.22.1 || ^26.12.1" }
}

# .npmrc：条件外の版ではインストールを失敗させる
engine-strict=true

この範囲は、10月21日の修正版以降の24系と26系だけを許します。EOL済みのv25や、修正前の24.21.0・26.5.0は通りません。Node.js 26.5.0（npm 11.17.0）のプロジェクト直下でnpm installを実行して確かめると、engine-strictが無いときはnpm warn EBADENGINEの警告だけでインストールが成功しました。.npmrcにengine-strict=trueを書くとnpm error code EBADENGINEで止まり、Required: {"node":"^24.22.1 || ^26.12.1"}と表示されます。同じ設定でもNode.js 24.22.1ではインストールが通りました。

27を試すときは検証用ブランチで許可範囲を変更し、互換性を確認してから本番側にも27の系列を明示的に追加します。enginesを含むpackage.jsonの項目はnpmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説でも整理しています。

GitHub ActionsとDockerイメージでLTSの版を揃える設定

setup-nodeのnode-version-fileによる.nvmrcとCIの版指定の共通化

GitHub Actionsのactions/setup-nodeはv7（最新はv7.1.0）でnode-version-fileを受け付けます。.nvmrcのほか、.node-version、.tool-versions、mise.toml、package.jsonを読めるので、ローカルとCIの版指定を1つのファイルにまとめられます。入力の既定値やv5以降のキャッシュの既定の変更はactions/setup-nodeとは｜v7の入力・キャッシュ設定とv5以降の既定変更で扱っています。

# .github/workflows/ci.yml（抜粋）
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: ['lts/-1', 'lts/*']   # ライブラリなら直前と最新のLTSで回す
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
          # アプリでは strategy 全体と上の node-version 行を削除し、次の行を有効にする
          # node-version-file: '.nvmrc'

READMEによると、node-versionはnvmと同じlts/jodやlts/-nの書き方に対応しています。check-latestの既定はfalseで、ランナーにキャッシュ済みの版が優先されます。10月21日のような修正版をすぐ使いたいときだけtrueにしてください。

v26のLTS昇格後のnode:ltsタグの切り替え

Docker公式イメージのdocker-nodeのREADMEには、node:ltsがActive LTSの版を指す追従タグであること、Maintenance LTSの版を使うときはタグに版番号を直接書くことが書かれています。node:slimのように版を書かないタグはCurrentを指します。

2026年10月27日にDocker Hubのダイジェストを照合すると、node:ltsはnode:24と同じイメージで、中身は24.22.1でした。v26の昇格後に新しいイメージがビルドされるとnode:ltsは26に変わり、24を使い続けるにはnode:24と書く必要があります。なお、node:24-slimは現在node:24-bookworm-slim（Debian 12）と同じで、Debian 13のtrixie系は別タグです。OSの切り替えを自分で決めるため、タグにはOS名まで書きます。

# 本番イメージはメジャー版とOSを固定する
FROM node:24-bookworm-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]

Dockerfileの命令ごとの書き方はDockerfileとは｜書き方・主要命令・ベストプラクティスを解説を参照してください。

node:lts-jodタグの更新停止と、版番号タグによる系列の固定

Docker Hubにはnode:lts-kryptonやnode:lts-jodのように、lts-にコードネームを付けたタグもあります。名前からは系列を固定したまま最新パッチを追えそうに見えますが、更新が止まっているものがあります。2026年10月27日にレジストリからイメージの設定を読み、中のNODE_VERSIONを確かめた結果が次のとおりです。

node:lts-jodの最終更新は、v22がMaintenance LTSに入った翌日の2025年10月22日です。中身は10月21日のセキュリティ修正が入っていない22.21.0のままで、FROM node:lts-jodのDockerfileは再ビルドしても修正版になりません。node:lts-ironも同じように20.18.0で止まっています。一方、lts-を付けないnode:jodはnode:22と同じイメージで、修正版の22.23.4に更新されていました。node:lts-kryptonが今後どうなるかは公式に書かれていませんが、2つの前例があるので頼らないほうが安全です。系列を固定するなら、node:22やnode:24-bookworm-slimのように版番号のタグを使ってください。

EOL前に次のLTSへ移る時期の決め方と移行の進め方

Active LTS昇格後の検証開始時期と旧系列の移行期限

移行の時期は「新しい版がActive LTSに昇格してから半年以内に検証を始める」と決めておくと迷いません。v26なら2026年10月28日の昇格から2027年4月末までを検証開始の目安とします。ただし、v22から移る案件は2027年4月30日までに本番移行を完了する必要があるため、検証・修正・切り戻し準備に必要な期間を逆算して早めに着手してください。22で動いている案件は、24を飛ばして26へ直接上げる選択もできます。26のEOLは2029年4月30日なので、次の移行まで2年取れます。

逆に、昇格直後の1〜2か月で本番を上げる必要はありません。昇格直後はネイティブアドオンやCIイメージの対応がそろっていないことがあり、Current期間の6か月はもともとライブラリ作者のための猶予です。

EOLまでの残り日数をCIで検知するスクリプト

EOLを人の記憶に頼ると、v20のように期限を過ぎてから気づくことになります。schedule.jsonを読み、実行中の版のEOLまでの残り日数がしきい値を切ったらCIを失敗させるスクリプトを置いておけば、移行の起票を忘れません。

// eol-check.mjs：EOLまで180日を切ったら exit code 1
const url = 'https://raw.githubusercontent.com/nodejs/Release/main/schedule.json';
const schedule = await (await fetch(url)).json();
const major = `v${process.versions.node.split('.')[0]}`;
const end = schedule[major]?.end;
if (!end) throw new Error(`${major} が schedule.json にありません`);
const days = Math.floor((new Date(end) - Date.now()) / 86_400_000);
console.log(`${major} EOL ${end}（残り ${days} 日）`);
if (days < 180) process.exitCode = 1;

2026年10月27日に実行すると、v24ではv24 EOL 2028-04-30（残り 551 日）、v26ではv26 EOL 2029-04-30（残り 916 日）と出て、どちらも終了コード0でした。この計算では、v22は2026年11月1日09:00（日本時間）を過ぎると残り179日となり、CIが失敗します。週1回のスケジュール実行ジョブに入れておくのが手軽です。

lts/*の自動追従を使わない場面と固定版で運用すべき案件

自動追従を使わない場面ははっきりしています。1つ目はV8やNode.jsのC++ APIに直接依存するネイティブアドオンを使う案件で、メジャー更新時に再ビルドが必要になり得ます。Node-APIだけを使い、外部ライブラリのABIも互換であれば、メジャー版をまたいで再利用できる場合があります。2つ目は本番のDockerイメージで、ビルド日によってメジャー版が変わると、障害調査時に実行版と変更差分を確認する手間が増えます。3つ目は受託開発の納品物で、検収した版と稼働中の版がずれることになります。

反対に、社内ツールや検証用のリポジトリならlts/*で追従させ、壊れたときに直すほうが手間は少なく済みます。版の固定とEOL前の計画的な更新を自社で回し切れない場合は、保守運用・内製化支援で依存更新の運用設計から引き受けることもできます。

よくある質問

Node.jsの最新のLTSはどれですか？

2026年10月27日時点ではv24（Krypton）です。v26は10月28日にActive LTSへ昇格する予定です。v24の最新パッチは10月21日のセキュリティリリースで出た24.22.1です。v24は10月20日からMaintenance LTSで、2028年4月30日まで修正を受けます。

Node.js 22のLTSはいつまでですか？

v22（Jod）のEOLは2027年4月30日です。2025年10月21日からMaintenance LTSに入っており、重大なバグとセキュリティの修正だけが出ています。最新パッチは22.23.4です。2027年4月までにv24かv26へ移ってください。26へ直接上げると、次の移行まで2029年4月30日の26のEOLまで間を空けられます。

Node.js 24のLTSはいつからいつまでですか？

v24（Krypton）は2025年10月28日にActive LTSになり、2026年10月20日にMaintenance LTSへ移りました。EOLは2028年4月30日です。新機能のバックポートはもう入らず、重大なバグとセキュリティの修正だけが続きます。

LTSとCurrentはどちらを使えばよいですか？

本番はLTSを使ってください。公式のリリース一覧ページは、本番アプリケーションにActive LTSかMaintenance LTSだけを使うよう書いています。Currentは新機能を先に試すための系列で、ライブラリ側の対応が追いつくまでの6か月間にあたります。新機能の検証環境でCurrentを動かし、本番はLTSのまま運用する分け方が扱いやすいです。

Node.js 27以降もLTSは偶数版だけですか？

いいえ、27から変わります。公式のリリース一覧ページでは、27以降は年1回のリリースになり、すべてのメジャー版がAlphaとCurrentを経てLTSへ移ると説明されています。schedule.jsonでは27のCurrent開始が2027年4月22日、LTS移行が2027年10月20日、EOLが2030年4月30日です。奇数か偶数かで本番に使うかを決めるのは、26までの版に限られます。

関連記事

• Node.js 26の新機能と破壊的変更・LTS移行日｜24からの移行手順【26.11.1対応】
• Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順【2026年10月最新】
• Node.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説
• actions/setup-nodeとは｜v7の入力・キャッシュ設定とv5以降の既定変更
• npmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説