Node.jsのLTSは、偶数番号の版がCurrentを6か月経たあとに入る本番向けの系列です。2026年9月27日時点でLTSにあるのはv24（Krypton）とv22（Jod）で、10月28日にはv26がActive LTSへ昇格する予定になっています。この記事では、いまのLTSを確かめるコマンド、nvmとpackage.jsonでの版固定、GitHub ActionsとDockerでの揃え方、EOL日を検知して次のLTSへ移る時期の決め方までを、コピーして動かせる設定例つきで整理します。
まとめ：2026年9月時点のNode.js LTSと版固定で先に決めること
本番で使ってよいのはActive LTSかMaintenance LTSの版だけです。2026年9月末の新規案件ならv24を選び、v22は2027年4月30日のEOLまでに移行計画を立てます。v20はすでに2026年4月30日でサポートが終わっています。
版の指定は「浮動」か「固定」かを先に決めてください。lts/*やnode:ltsは最新のActive LTSへ自動で追従するため、10月28日を境に指すメジャー版が24から26へ変わります。受託の納品物や本番のDockerイメージではメジャー番号を固定し、EOLまでの残り日数をCIで監視して計画的に上げる運用を勧めます。
Node.js LTSの3段階と2026年9月時点で本番に使える版の一覧
Current・Active LTS・Maintenance LTSの期間と修正対象
Node.jsの各メジャー版は、まずCurrentとして6か月公開されます。この6か月は、ライブラリ作者が各メジャー版に対応するための猶予期間です。公式のリリース一覧ページによると、Node.js 26までは奇数番号の版が6か月でサポート終了となり、偶数番号の版だけがActive LTSへ進みます。LTSは重大なバグ修正を合計30か月ほど受けられる系列で、公式は本番アプリケーションにActive LTSかMaintenance LTSだけを使うよう明記しています。
Active LTSの期間は機能のバックポートも入りますが、Maintenance LTSに入ると重大なバグとセキュリティ修正に絞られます。仕組みと版選びの基本はNode.jsとは？仕組み・版の選び方・標準機能で動かす手順で扱っているので、ここでは運用の日付に絞ります。
v22・v24・v26の開始日・LTS移行日・EOL日を並べた比較表
日付はNode.js Release Working Groupのリポジトリが公開しているschedule.jsonを2026年9月27日に取得した値です。最新パッチは公式配布のindex.jsonから取りました。
| 版（コードネーム） | Current開始 | Active LTS | Maintenance | EOL | 9月27日時点の最新 |
|---|---|---|---|---|---|
| v22（Jod） | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 | 22.23.3 |
| v24（Krypton） | 2025-05-06 | 2025-10-28 | 2026-10-20 | 2028-04-30 | 24.21.0 |
| v26（未命名） | 2026-05-05 | 2026-10-28 | 2027-10-20 | 2029-04-30 | 26.10.0 |
v26のコードネームはschedule.json上でまだ空欄です。コードネームが公表されるまでは、lts/<名前>形式で26を指定できません。
2026年10月に起きるv24のMaintenance入りとv26のLTS昇格
10月に予定されているのは、8日違いで続く2つの切り替えです。10月20日にv24がMaintenance LTSへ移り、10月28日にv26がActive LTSへ昇格します。この時点で「最新のLTS」は24から26へ変わります。
v24を使い続けること自体は問題ありません。EOLは2028年4月30日で、まだ1年半以上あります。注意が要るのは、版をlts/*のような浮動指定で書いているリポジトリです。次にCIやイメージのビルドが走った瞬間、メジャー版が上がります。26で入ったTemporal APIの既定有効化や削除APIの影響はNode.js 26の新機能・変更点とLTSスケジュール総まとめで詳しく扱っています。
もう1つの変化はNode.js 27以降です。previous-releasesページには、27から年1回のリリースになり、すべてのメジャー版がCurrentを経てLTSへ移ると書かれています。schedule.jsonでは27のAlphaが2026年10月28日、Currentが2027年4月22日、EOLが2030年4月30日と掲載されています。偶数だけを追う従来の選び方が当てはまるのは、26までのメジャー版です。
手元とサーバーで現行LTSを確認するコマンドとindex.jsonの読み方
process.release.ltsとnode -vで実行中の版がLTSか判定する手順
実行中のNode.jsがLTSかどうかは、版番号よりもprocess.release.ltsで見るほうが確実です。公式APIドキュメントのprocess.releaseによると、このプロパティはLTS版にだけ存在し、コードネームの文字列を返します。Current版ではundefinedになります。
$ node -v
v24.21.0
$ node -p "process.release.lts"
Krypton
# Current版（v26）で実行した場合
$ node -p "process.release.lts"
undefinedサーバーの棚卸しでは、この2行をSSH越しに流すだけで「LTSで動いているか」「どの系列か」がそろいます。v26は10月28日にLTSへ昇格すると、同じコマンドでコードネームが返るようになります。
nodejs.org/dist/index.jsonで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}`);
}
console.log([...latest.values()].slice(0, 2).join('\n'));2026年9月27日に実行すると、v24.21.0 Krypton 2026-09-07とv22.23.3 Jod 2026-09-23の2行が出ます。同じ一覧には同梱npmの版（24.21.0は11.19.0、22.23.3は10.9.9）も入っているので、npmの版差でロックファイルが割れる問題の調査にも使えます。
nvm・.nvmrc・package.jsonでLTSを固定するときの書き方と使い分け
nvm install –ltsとlts/jodのようなコードネーム指定の違い
nvmのREADMEのLong-term Supportの節では、LTSの指定方法が2系統用意されています。nvm install --ltsとlts/*は最新のLTSを、--lts=jodとlts/jodは特定の系列の最新パッチを指します。
# 最新のLTS（10月27日まではv24、28日以降はv26の見込み）
$ nvm install --lts
# 系列を固定して、その中の最新パッチだけ追う
$ nvm install lts/krypton
# 新しいLTSへ移るとき、グローバルに入れたパッケージとnpmも移す
$ nvm install --reinstall-packages-from=current --latest-npm 'lts/*'最後の行の--latest-npmには意味があります。READMEによると、パッケージの再インストールだけではnpm自体は更新されません。Node.jsだけ上がってnpmが古いまま残る状態を避けるなら、このフラグを付けます。
.nvmrcにlts/*を書くと版が自動で上がる落とし穴と固定の基準
.nvmrcには版番号のほかlts/*も書けます。READMEの例でも「最新のLTSを既定にする」書き方として紹介されていますが、チーム開発では勧めません。メンバーがnvm installを実行した日によって、24と26が混在するからです。
固定の基準は次のとおりです。アプリケーションのリポジトリでは24のようにメジャー番号だけを書き、パッチはnvmに最新を取らせます。ネイティブアドオンを含む案件やビルド結果の再現性を契約で求められる案件では24.21.0まで書き切ります。lts/*を置いてよいのは、個人の検証用リポジトリくらいです。
$ echo "24" > .nvmrc
$ nvm use
Found '/path/to/project/.nvmrc' with version <24>
Now using node v24.21.0 (npm v11.19.0)package.jsonのenginesとengine-strictによる版違いの検知
.nvmrcはnvmを使う人にしか効きません。版違いをnpm側でも止めるなら、package.jsonのenginesを書きます。npmのpackage.jsonドキュメントによると、engine-strictを設定していない限りenginesは助言扱いで、依存として入れられたときに警告を出すだけです。
// package.json（抜粋）
{
"engines": { "node": ">=24 <27" }
}
# .npmrc：条件外の版ではインストールを失敗させる
engine-strict=true上限を<27にしているのは、26のLTS昇格後も検証済みの範囲だけを許すためです。27を試す段階で上限を外せば、意図しない版での本番ビルドを止められます。enginesを含むpackage.jsonの項目はnpmとは？CLIとレジストリの役割・package.jsonとv12の変更点でも整理しています。
CIとDockerイメージでLTSを揃えるsetup-nodeとnode:ltsタグの設定
node-version-fileによる.nvmrc共有とCIの版指定を揃える構成
GitHub Actionsではactions/setup-nodeのv7がnode-version-fileを受け付けます。.nvmrcのほか、.node-version、.tool-versions、mise.toml、package.jsonを読めるので、ローカルとCIの版指定を1か所に寄せられます。
# .github/workflows/ci.yml（抜粋）
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node: ['lts/-1', 'lts/*'] # ライブラリなら直前と最新のLTSで回す
steps:
- uses: actions/setup-node@v7
with:
node-version: ${{ matrix.node }}
# アプリなら matrix を外し、次の1行で .nvmrc と揃える
# node-version-file: '.nvmrc'READMEによると、node-versionはnvmと同じlts/jodやlts/-nの書式に対応しています。check-latestの既定はfalseで、ランナーにキャッシュ済みの版が優先されます。パッチまで最新をそろえたい場合だけtrueにしてください。
node:ltsタグが指す版の切り替わりとメジャー番号を固定する理由
Docker公式イメージのdocker-nodeのREADMEには、node:ltsがActive LTSの版を指す浮動タグであること、Maintenance LTSの版を使うにはタグに版番号を直接書くことが明記されています。版を指定しないnode:slimのようなタグはCurrentを指します。
つまり10月28日以降、FROM node:ltsは26のイメージを返すようになり、24はMaintenance LTSなのでnode:24と書かない限り使えません。2026年9月27日時点のDocker Hubでは24-bookworm-slimと24.21.0-bookworm-slimの両タグが公開されています。
# 本番イメージはメジャー版とOSを固定する
FROM node:24-bookworm-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]Dockerfileの命令ごとの書き方はDockerfileとは｜書き方・主要命令・ベストプラクティスを参照してください。
EOL前に次のLTSへ移る時期の決め方と本番環境の移行作業を回す順序
Active LTS昇格から半年以内に上げるという移行時期の判断基準
移行の開始時期は「新しい版がActive LTSに昇格してから半年以内」と決めておくのが扱いやすい基準です。v26なら2026年10月28日の昇格から2027年4月末までに検証を始めます。この時期はちょうどv22のEOL（2027年4月30日）と重なるため、22で動いている案件は24を飛ばして26へ直接上げる判断もできます。
逆に、昇格直後の1〜2か月で本番を上げる必要はありません。LTS昇格直後はエコシステム側のネイティブアドオンや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;週1回のスケジュール実行ジョブに組み込むのが手軽です。v22の場合、残り180日を切るのは2026年11月上旬で、そこから半年をかけて移行を進める計算になります。
lts/*の自動追従を採用しない場面と固定版で運用すべき案件
自動追従を採用しない場面ははっきりしています。1つ目はネイティブアドオンに依存する案件です。メジャー版が変わるとABIの番号が変わり、再ビルドが要ります。2つ目は本番のDockerイメージで、ビルドした日によって中身のメジャー版が変わると障害時の切り分けができません。3つ目は受託開発の納品物で、検収した版と稼働中の版がずれることは避けるべきです。
反対に、社内ツールや検証用のリポジトリではlts/*で追従させ、壊れたら直すほうが保守コストは下がります。版の固定とEOL前の計画的な更新を自社で回し切れない場合は、保守運用・内製化支援として依存更新の運用設計から引き受けることもできます。
よくある質問
Node.js LTSについて検索されることの多い質問に、2026年9月27日時点の情報で答えます。
2026年9月時点のNode.jsの最新LTSはどれですか？
Active LTSはv24（Krypton）で、最新パッチは2026年9月7日の24.21.0です。v22（Jod）はMaintenance LTSで、9月23日に22.23.3が出ています。v26は現在Currentで、10月28日にActive LTSへ昇格する予定です。昇格後は最新のLTSが26になり、24は10月20日からMaintenance LTSとして2028年4月30日まで修正を受けます。
LTSとCurrentはどちらを使えばよいですか？
本番はLTSを使ってください。公式のリリース一覧ページは、本番アプリケーションにActive LTSかMaintenance LTSだけを使うよう書いています。Currentは新機能を先に試すための系列で、ライブラリ側の対応が追いつくまでの6か月間に位置づけられています。新機能の検証環境でCurrentを動かし、本番はLTSのまま運用する分け方が扱いやすいです。
Node.js 22のサポートはいつまでですか？
v22のEOLは2027年4月30日です。2025年10月21日からMaintenance LTSに入っており、現在は重大なバグとセキュリティの修正だけが出ています。2027年4月までにv24かv26へ移る計画を立ててください。v26は2029年4月30日までサポートされるので、22から26へ直接上げると次の移行までの間隔を長く取れます。
nvm以外にLTSを管理できるツールはありますか？
macOSやLinuxではNodebrew、Volta、miseなども使えます。Nodebrewの導入と切り替えはNodebrewとは？Node.jsのバージョン管理・インストール・切り替えで解説しています。どのツールを選んでも、CIと揃えるなら.nvmrcか.node-versionのような共通ファイルに版を書くのが確実です。setup-nodeはこの2つに加えて.tool-versionsとmise.tomlも読めます。
Node.js 27以降もLTSは偶数版だけですか？
いいえ、27から変わります。公式のリリース一覧ページでは、27以降は年1回のリリースになり、すべてのメジャー版がCurrentの6か月を経てLTSへ移ると説明されています。schedule.jsonでは27のCurrent開始が2027年4月22日、EOLが2030年4月30日です。奇数か偶数かで本番採用を判断する選び方は、26までの版に限った話になります。
関連記事
- Node.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説：実行モデルとインストール、版の選び方の基本を押さえられます
- Node.js 26の新機能・変更点とLTSスケジュール総まとめ：10月にLTSへ昇格するv26の変更点と24からの移行検証を確認できます
- npmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説：enginesを含むpackage.jsonの項目と同梱npmの版を整理できます
- npxとは？npm execとの違い・キャッシュ実行の仕組みとCIでの固定手順：CIでツールの版を固定する考え方を実行コマンドの側から補えます
- pnpmとは？共有ストアの仕組みとv12のRust実装・モノレポ運用を解説：Node.js 22以上を要件にするパッケージマネージャの版管理と合わせて読めます
