LASSIC Media らしくメディア
Node.js 18サポート終了、20/22移行を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Node.js 18は2025年4月末、20は2026年4月末にサポートが終了しています。
- 現行のActive LTS（長期サポート版）は22であり、24への直接移行という選択肢もあります。
- 移行の難所は依存パッケージの更新・ネイティブアドオンの再ビルド・CI/コンテナ環境の更新です。
目次
Node.js 18と20、サポート終了の実際の日付
Node.js 18のサポート終了とは、Node.js公式のリリーススケジュールに基づき、バージョン18系へのセキュリティパッチ・バグ修正の提供が終了したことを指します*1。
Node.js公式のリリーススケジュールによると、18系（コードネームHydrogen）は2025年4月30日にEOL(End-of-Life、サポート終了)を迎えました*1。さらに20系（コードネームIron）も2026年4月30日にEOLとなっています*1。つまり本稿執筆時点（2026年7月）では、18だけでなく20もすでにサポート対象外です。
現在Active LTS（長期サポート版のうち積極的に機能更新を受ける段階）にあるのは22系（コードネームJod）です*1。22は2026年10月21日にMaintenance（保守専任）フェーズへ移行し、2027年4月30日にEOLを迎える計画になっています*1。2025年5月にリリースされた24系（コードネームKrypton）も並行してActive LTSの対象であり、EOLは2028年4月30日です*1。
Node.jsは偶数バージョンのみがLTS化される方式を採っており、リリース後6か月の「Current」期間を経てActive LTSに入り、その約12か月後にMaintenanceへ移行、さらに約18か月後にEOLとなる運用がとられています*1。この周期を把握しておくと、次のLTS移行の計画も立てやすくなります。
EOLを迎えたバージョンを使い続けるリスク
EOL後のバージョンには、新たに発見された脆弱性へのセキュリティパッチが提供されません*1。llhttp（HTTPパーサー）関連のCVEなど、18系や16系に影響する脆弱性が公表された事例があります*2。パッチが出ない状態が続くと、脆弱性を抱えたまま本番運用を継続する状態になりかねません。
Node.js公式は、サポート終了後もEOL版を使い続ける場合はサードパーティによる延長サポートの利用や、早期のアップグレードを推奨しています*1。延長サポートはあくまで一時的な緩和策であり、最終的にはActive LTS版への移行が必要になります。
20 LTS維持・22 LTS移行・24移行 — 3つの選択肢比較
Node.js 18からの移行を検討する際、選択肢は主に「20への移行」「22への移行」「24への移行」の3つに整理できます。20はすでにEOL済みのため、実質的には22か24を移行先として選ぶ判断になります。
| 選択肢 | サポート残存期間 | 特徴 | 留意点 |
|---|---|---|---|
| 20 LTSの延命利用 | 2026年4月末で終了済み。今後は延長サポートに依存 | 18からの移行差分が比較的小さい | 公式パッチが出ないため、セキュリティ運用上のリスクが残ります。 短期間で再度の移行が必要になります。 |
| 22 LTSへの移行 | 2027年4月末まで（Maintenance移行は2026年10月予定） | Active LTSの中でも実績が積み上がっている段階 | 18からの差分（ネイティブアドオンのABI・OpenSSL関連）を検証する必要があります。 |
| 24への移行 | 2028年4月末まで | サポート残存期間が最も長く、次回移行までの周期を延ばせます | 22よりリリースが新しく、依存パッケージの対応状況を個別に確認する必要があります。 |
20 LTSはすでにEOLを迎えているため、恒久的な移行先としては選びにくい状況です。実務上の判断軸になるのは、依存パッケージ・社内システムの対応実績が積み上がっている22を選ぶか、サポート残存期間の長さを優先して24を選ぶかという点になります*1。
依存ライブラリの対応状況を個別に確認したうえで、22で一度安定運用の実績を作り、次のサイクルで24以降へ移行するという段階的な考え方も選択肢の一つです。どちらを選ぶ場合も、移行前に依存パッケージの互換性検証が欠かせません。
互換性検証で押さえる4つのチェックポイント
Node.js 18から22・24への移行では、単なるバージョン番号の書き換えでは済まない互換性の論点がいくつか存在します。事前に検証すべき項目を整理します。
1. ネイティブアドオンのABI（バイナリ互換性）
Node.js 22ではNODE_MODULE_VERSIONが変更され、20以前のバージョン向けにビルドされたネイティブアドオン（C++で書かれた拡張モジュール）はABI(Application Binary Interface、実行時のバイナリ互換規約)非互換になります*3。プリビルドバイナリを配布しているパッケージの場合、対応版が存在しないとインストール時にビルドエラーになるか、誤ったバイナリが読み込まれて実行時にクラッシュする可能性があります*3。移行後は該当パッケージの再ビルドが必要です。
2. OpenSSLのバージョン変更
Node.jsが内部にバンドルするOpenSSL(暗号化・TLS通信を担うライブラリ)のバージョンが更新されており、22系はOpenSSL 3.5系を採用しています*3。暗号スイートやTLS設定に依存する既存コードがある場合は、通信エラーが起きないか事前の検証が必要です。
3. 非推奨APIの置き換え
url.parseは非推奨化されており、代替のnew URLクラスへの置き換えが案内されています*3。fs.rmdirのrecursiveオプションも削除され、fs.rmへの移行が必要です*3。これらは静かに動作を変えるため、テストで検出できないまま本番に出てしまうことがあります。
4. ESMのimport構文の変更
ECMAScript Modules(ES Modules、標準のモジュール読み込み方式)で使われていた旧来のimport assertions構文（assert構文）は22.0.0で廃止され、import attributes構文（with構文）に統一されています*3。旧構文を使うコードはこの変更でエラーになるため、該当箇所の洗い出しが必要です。
これらの検証には、Node.jsのAPIリファレンスとの照合、依存パッケージ側の対応バージョン確認、実行環境でのリグレッションテスト（既存機能が壊れていないかの回帰確認）が伴います。件数が多いプロジェクトでは、この検証工程自体が移行作業の中心になります。
内製移行で工数が膨らみやすい3つの理由
移行作業を内製で行う場合、想定より工数が膨らみやすい要因が複数あります。判断の材料として整理します。
依存パッケージの更新が連鎖する
package.jsonに記載された依存パッケージのうち、Node.js 22・24への対応が済んでいないものがあると、そのパッケージ自体の更新や代替パッケージへの切り替えが必要になります。1つのパッケージ更新が別のパッケージとの互換性問題を引き起こす連鎖も起こり得ます。この連鎖を洗い出すには、npmエコシステム全体の依存関係を理解した人材が必要です。
CI/CDとコンテナ環境の更新が漏れやすい
アプリケーションコードのバージョンを上げても、CI(継続的インテグレーション、コード変更を自動でビルド・テストする仕組み)のビルドイメージやDockerfileのベースイメージが古いNode.jsバージョンを指定したままになっている場合があります。本番デプロイ直前まで気づかれないケースもあり、環境定義ファイル一式の棚卸しが欠かせません。
回帰テストの範囲が読みにくい
非推奨APIの置き換えやネイティブアドオンの再ビルドは、見た目上は動くように見えても、特定の入力条件下でのみ挙動が変わることがあります。この作業を内製で行うには、Node.jsのランタイム仕様・依存パッケージの内部実装・既存システムのテスト範囲設計という複数領域の知識が必要です。テスト範囲を狭く見積もると、本番リリース後に不整合が表面化するリスクが残ります。
移行を誤ると、特定のAPIエンドポイントだけが本番環境で失敗する、決済処理など一部機能のみ不整合が起こるといった形で問題が現れることがあります。影響範囲の切り出しと修正に想定以上の時間を要する点が、内製移行のリスクとして挙げられます。
移行を外注する場合の進め方と確認事項
移行を外部パートナーに委託する場合は、以下の順序で進めるのが一般的です。第一に現行環境の依存パッケージ・ネイティブアドオンの棚卸しを行い、第二に移行先バージョン（22か24か）を確定させ、第三にステージング環境での検証とCI/コンテナ更新、第四に本番切り替えという流れです。
委託先を選定する際は、Node.jsのメジャーバージョン間移行の実績や、CI/CD・コンテナ環境まで含めた対応範囲を確認することが大切です。アプリケーションコードのみを見て、ビルド・デプロイ環境の更新を対象外にする委託先だと、移行後に環境起因の不整合が残る可能性があります。
まとめ：Node.js移行で押さえるべき3つの判断軸
本稿ではNode.js 18・20のサポート終了状況と、22・24への移行にあたっての互換性論点を整理しました。要点を3つに集約すると次の通りです。第一に、18は2025年4月、20は2026年4月にすでにEOLを迎えており、現実的な移行先はActive LTSの22か24です。第二に、移行にはネイティブアドオンのABI・OpenSSL・非推奨API・ESM構文という4つの互換性論点が伴います。第三に、依存パッケージの連鎖更新やCI/コンテナ環境の更新まで含めると、内製での工数は見積もりを超えやすい傾向があります。
よくある質問
Node.js 20はもうサポート終了しているのですか。
はい、Node.js 20（コードネームIron）は2026年4月30日にEOLを迎えています*1。現在Active LTSの対象となっているのは22と24です。20を継続利用する場合は、公式のセキュリティパッチが提供されない点に注意が必要です。
Node.js 22と24、どちらに移行すべきですか。
サポート残存期間を優先するなら24（EOLは2028年4月末）、実績・対応パッケージの成熟度を優先するなら22（EOLは2027年4月末）が判断軸になります*1。自社が利用する依存パッケージの対応状況を確認したうえで選ぶことをおすすめします。
移行時のネイティブアドオンの再ビルドはどのタイミングで必要ですか。
Node.jsのバージョンを切り替えた直後に必要です。NODE_MODULE_VERSIONの変更によりABIが非互換になるため、切り替え後にネイティブアドオンを再ビルドしないと、インストール時のエラーや実行時のクラッシュにつながることがあります*3。
移行作業にかかる期間はどれくらいですか。
依存パッケージの数・ネイティブアドオンの有無・CI/コンテナ環境の複雑さによって幅があります。一般的な目安が一次資料で示されていないため、まずは依存関係の棚卸しを行い、対応が必要な項目数から個別に見積もることをおすすめします。
移行を外注する場合、アプリケーションコード以外も対応してもらえますか。
委託先によって対応範囲は異なります。CI/CDのビルド設定やDockerfileのベースイメージ更新まで含めて対応できるかどうかを、契約前に確認しておくことが大切です。アプリケーションコードのみが対象範囲だと、環境起因の不整合が移行後に残る可能性があります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Node.js「Node.js Releases」「Release Schedule」（nodejs.org、https://nodejs.org/en/about/previous-releases）
- *2 出典：Node.js「Beware of End-of-Life Node.js Versions – Upgrade or Seek Post-EOL Support」（https://nodejs.org/en/blog/announcements/node-18-eol-support）
- *3 出典：nodejs/node GitHub Issues「OpenSSL breaking changes」・Node.js公式APIドキュメント記載の非推奨情報（https://github.com/nodejs/node/issues/56202）
