LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

Node.jsの版をいつ上げればよいのか分からない。前回の移行は期限の直前に慌てて行い、次も同じことになりそうだ——。Node.jsで動くシステムを抱える情報システムの現場では、こうした悩みが起こりがちです。Node.jsのバージョンアップとは、システムを動かしているNode.jsの版を、修正が提供されている新しい版に入れ替える作業のことです。

Node.jsは各版のサポート終了日が前もって公開されているため、計画を立てて進められます。ただし万能ではなく、使っているライブラリの対応や試験の範囲は、システムごとに確かめる必要があります。本記事では、システムの保守を担当する方に向けて、LTSの周期と各版の期限、Node.js 27からの周期の違い、定期の版上げを回すポイント、そして外部に頼むときに確認したい点を整理します。

Node.jsのバージョンアップとは

Node.jsの版は「22」「24」のようなメジャー番号のまとまり（リリースライン）ごとに管理されています。同じリリースラインの中で数字の後ろの部分が上がる更新は、主に不具合と脆弱性（セキュリティ上の弱点）の修正です。一方、22から24へ移る更新は、動かなくなる変更を含むことがあり、事前の確認が欠かせません。バージョンアップというときは、この2種類を分けて考えます。

• 同じリリースラインの中の更新：修正を取り込むために、こまめに当てる
• リリースラインをまたぐ更新：期限から逆算して、計画を立てて進める
• LTS（長期サポート版）：修正が長く提供される版で、業務のシステムはこれを使う
• Current（最新版）：新しい機能を先に試す版で、半年ほどでLTSに移るか終了する

Node.jsの公式サイトは、本番のアプリケーションではActive LTSかMaintenance LTSの版だけを使うよう求めています。^*2 LTSの中でも、新しい機能と修正が入る時期（Active）と、重要な修正だけが入る時期（Maintenance）があります。業務のシステムは、この2つの時期にある版を選び、期限が来る前に次のLTSへ移ることになります。

LTSの周期と各版の期限

Node.jsは期限があらかじめ公開されているため、バージョンアップの時期を前もって決められます。公式のリリース表では、各リリースラインがLTSになる日とサポートが終わる日が並んでいます。^*1 2026年10月の時点で修正が提供されているLTSは、次の3つです。

Node.js 26まではLTSの期間が30か月で、はじめの12か月がActive、残りの18か月がMaintenanceです。^*1 サポートが終わった版には、脆弱性の修正も含めて更新が出なくなります。公式サイトは、多くの業界の監査で保守されていない実行環境が認められないことにも触れています。^*3 Node.js 20は2026年4月30日に終了しています。期限を過ぎた版の移行についてはNode.js 18サポート終了の記事でも扱っています。

Node.js 27からの周期の違い

Node.jsは、2026年10月から版の出し方を変えました。これまでは年に2回メジャー版が出て、偶数の版だけがLTSになっていました。Node.js 27からは年に1回になり、すべての版がLTSになります。^*4

公式の発表は、すでにLTSの版にだけ上げている利用者にとって、版の番号の付け方のほかはあまり変わらないとしています。^*4 版の番号は、最初に出る年に合わせて27は2027年、28は2028年になります。毎年10月に新しいLTSが加わるので、社内の予定に組み込みやすくなります。

定期の版上げを回す4つのポイント

期限が来るたびに慌てて移行するのではなく、毎年同じ手順で版を上げる体制を作っておくと、作業の重さを毎回そろえられます。次の4つのポイントを順に整えると、担当者が替わっても続けられます。

• ポイント1：使っている版を一覧にする。本番のサーバー、テストの環境、クラウドの実行環境ごとに、どの版で動いているかとサポート終了日を書き出す
• ポイント2：上げる時期を年間の予定に入れる。新しいLTSが出る10月と、古い版が終わる4月30日を基準にする
• ポイント3：確かめる範囲を決める。使っている部品（ライブラリ）が新しい版に対応しているか、どの試験を流せば動作を確かめたと言えるかを決める
• ポイント4：手順と担当を文書にする。本番への切り替えと戻し方、同じリリースラインの修正を当てる頻度まで書き、終わったら見直す

ポイント3が手薄になりやすい点です。公式サイトは、サポートが終わった版を使い続けると、多くのライブラリがその版への対応をやめていき、古い部品から離れられなくなると説明しています。^*3 版を上げるときは、Node.js本体とあわせて、使っている部品の版も見直す必要があります。

外部に頼むときに確認しておきたい点

Node.jsのバージョンアップを毎年社内だけで続けるのは、担当者の手が空かない会社には負担です。保守を外部に頼むときは、1回の移行作業だけでなく、毎年の版上げを続ける体制まで含めて確かめておきます。

• どこまで頼むか：版の一覧づくり、ライブラリの対応確認、試験、本番の切り替えのうち、どれを任せるか
• 年間の予定：LTSの切り替わりに合わせて、いつ調査し、いつ本番を上げるかを示してもらえるか
• 動作の確かめ方：どの試験を流して合格とするか。試験が足りない部分をどう補うか
• 戻し方：切り替え後に不具合が出たとき、前の版に戻す手順と判断する人が決まっているか
• 見直しの場：作業の後に、手順書と版の一覧を更新して報告してもらえるか

クラウドの実行環境では、クラウド側の都合でNode.jsの古い版が使えなくなることもあります。サーバーを持たない仕組みの版の期限についてはAWS Lambdaのランタイム終了への対応にまとめています。

まとめ：版上げで確かめておきたい3つの点

Node.jsのバージョンアップを続けていくうえで、確かめておきたい点は3つに整理できます。第一に、本番で使う版をLTSに限り、各版のサポート終了日を公式のリリース表で確かめておくこと。第二に、新しいLTSが出る10月と、古い版が終わる4月30日を基準に、毎年の予定に版上げを組み込むこと。第三に、ライブラリの対応確認と試験の範囲、戻し方を文書にして、担当者が替わっても同じ手順で進められるようにすることです。この3点を踏まえておけば、「期限の直前になって、また慌てて移行することになった」という事態を避けやすくなります。版上げの体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Node.js Release Working Group「Release schedule」（nodejs/Release、GitHub）（https://github.com/nodejs/Release）。出典：各リリースラインのLTS開始日・Maintenance開始日・サポート終了日、LTSの期間（Active 12か月・Maintenance 18か月）、日付が変わることがある旨の記述を参照（2026年11月確認）
2. *2　参考：OpenJS Foundation「Node.js Releases」（nodejs.org）（https://nodejs.org/en/about/previous-releases）。出典：本番ではActive LTSかMaintenance LTSの版だけを使うこと、奇数の版のサポート期間、サポート終了後の有償支援の案内を参照（2026年11月確認）
3. *3　参考：OpenJS Foundation「End-Of-Life (EOL)」（nodejs.org）（https://nodejs.org/en/about/eol）。出典：サポート終了後は脆弱性の修正も出ないこと、ライブラリの対応終了、監査で保守されていない実行環境が認められないことの記述を参照（2026年11月確認）
4. *4　参考：Node.js Releasers「Evolving the Node.js Release Schedule」（nodejs.org）（https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule）。出典：Node.js 27から年1回のリリース・すべての版がLTS・Alpha版・版の番号と年の対応の記述を参照（2026年11月確認）

Tweet