この記事は、HeroDevsのブログ記事『Node.js v20 EOL is Here: What actually happens to your apps on May 1』の翻訳記事です。
デッドラインは木曜日です。5月1日以降、Node.js v20アプリケーションに何が変わるのかを、運用レベルで具体的に解説します。
あと2日──運用面の実態
4月30日は木曜日です。チームがNode.js v20を本番環境で稼働させていて、v22へのアップグレードが完了していない場合、5月1日を迎えたときに何が変わるのかを正確に説明します。抽象的なリスクの話ではなく、チームが依存するシステムやサービスへの具体的な変化として捉えてください。
まず前提を整理します。サポート終了（EOL）は、Node.js v20アプリケーションが動かなくなることを意味しません。ランタイムが落ちるわけでも、サービスが停止するわけでもありません。変わるのは、アプリケーションを支えるセキュリティ基盤です。誰がパッチを適用するのか、誰が脆弱性を監視するのか、次のCVEが公開されたときに何が起きるのか――そこが変わります。
アップストリームで何が変わるか：Node.jsプロジェクト
5月1日以降、Node.js セキュリティワーキンググループはv20の脆弱性受付プロセスを終了します。Node.js v20に脆弱性を責任ある開示（responsible disclosure）で報告したセキュリティ研究者には、定型の返答が届きます。「このバージョンはEOLであり、パッチは提供しない」というものです。CVEはEOLバージョンに影響するものとして記録され、プロジェクトからの修正手段はないとされます。
Node.jsリリースチームはv20ブランチへの新規コミットを停止します。パッチ・ホットフィックス・バックポート・依存関係の更新、いずれもv20にはマージされません。ブランチは静的な成果物として凍結されます。
これが実際に何を意味するかは、2026年3月のNode.jsセキュリティリリースを見ればわかります。そのリリースでは、現役のv20・v22・v24にまたがる9件のCVEにパッチが当てられました。うち2件――CVE-2026-21637とCVE-2026-21710――はCVSSスコア7.5の高深刻度で、それぞれTLSとHTTPリクエスト処理に影響するものでした。4月30日以降、同等の深刻度の脆弱性がNode.js v20で発見されても、パッチは提供されません。セキュリティリリースはEOLバージョンへの影響と記録し、先に進みます。
これは推測のリスクではありません。v20より前にEOLを迎えたすべてのNode.jsリリースで記録された、実証済みの動作です。Node.js v16は2023年9月にEOLとなり、それ以来セキュリティパッチを受けていません。Node.js v18は2025年4月にEOLとなり、それ以来パッチを受けていません。v20も同じ道をたどります。
AWS Lambdaで何が変わるか
AWS LambdaはNode.jsランタイムをLambda実行環境のサービスコンポーネントとして管理しています。有効なランタイムに対しては、AWSがOSレベル・ランタイムレベル・Lambdaサービスレベルの脆弱性にセキュリティパッチを適用します。この作業はユーザーが意識することなく透過的に行われます。
Node.jsランタイムが非推奨（deprecated）ステータスに移行すると、この管理パッチ適用は停止します。2026年4月30日以降、Node.js 20 Lambdaランタイムは静的な環境となります。関数コードは引き続き実行されますが、その下のランタイムはAWSからのアップデートを受け取らなくなります。
より直接的な運用上のインパクトはデプロイに及びます。AWSは非推奨後に段階的なブロックスケジュールを適用します。2026年6月1日以降はNode.js 20を指定した新規関数の作成がブロックされ、2026年7月1日以降は既存関数の更新がブロックされます。新しいLambda関数のデプロイ、既存関数の設定変更、あるいは関数設定に書き込む自動処理が、これらの日程以降に実行されると失敗します。CI/CDパイプライン、IaCデプロイ、Lambda関数設定を変更するあらゆる自動化に影響します。
Azure App Serviceで何が変わるか
Azure App Serviceはランタイムのライフサイクルにコミュニティサポートのタイムラインを採用しています。有効なランタイムに対しては、プラットフォームが管理するNode.js環境に自動でセキュリティパッチを適用します。
Node.jsランタイムがEOLを迎えると、この管理パッチ適用は停止します。コミュニティサポートが終了した後、App Serviceはそのランタイムに対してセキュリティパッチや関連するカスタマーサポートを提供できません。アプリケーション自体は稼働し続けますが、その下のランタイムはMicrosoftからのアップデートを受け取らなくなります。
サポートへの影響は即座に、そして運用レベルで現れます。Azure App ServiceのMicrosoftサポートポリシーは、非推奨のNode.jsバージョンにおけるランタイムの問題を明示的に対象外としています。非推奨日以降にNode.js 20のランタイム動作に起因する本番インシデントでサポートケースを開いても、サポートチームはランタイムが非推奨であることを指摘し、ランタイムレベルの問題調査を断ります。Azureプラットフォームレベルのサポートは引き続き受けられますが、ランタイム自体はサポート対象外となります。
インシデント対応プロセスの一部としてAzureサポートに依存しているチーム――特にサポートSLAがベンダー評価の要件となっている規制対象業種――にとって、これはサポートカバレッジモデルの実質的な変更です。
GCP Cloud RunおよびCloud Functionsで何が変わるか
GCPはCloud RunおよびCloud Functionsの管理ランタイムに対して公開されたライフサイクルポリシーを適用しています。Node.js 20は2026年4月30日に非推奨ステータスに入り、Cloud Consoleに非推奨警告が表示されるようになります。デコミッション日――新規デプロイと新リビジョンがハードブロックされ、既存ワークロードが無効化対象となる日――は2026年10月30日です。
AWSと同様に、GCPは有効なランタイムに対して管理セキュリティパッチを提供し、マネージド実行環境内のNode.js環境を更新しています。非推奨ランタイムに対しては、このパッチ適用はGCPの自動ベースイメージ更新ポリシーに基づいて非推奨期間中も継続されますが、デコミッション時点で完全に終了します。ランタイムレベルの問題に対するカスタマーサポートは非推奨時点で終了します――つまり2026年4月30日以降、ランタイムサポートはすでに受けられません。
タイムラインは明確です。チームは2026年10月30日までにワークロードをNode.js 20から移行する必要があります。これ以降は新規デプロイがブロックされ、既存ワークロードは無効化の対象となります。これは無期限の猶予期間ではありません。
複合的な影響
4月30日・5月1日の組み合わせが通常のアップストリームEOLと本質的に異なる点は、複数のセキュリティレイヤーが同時に失われることにあります。アップストリームEOLだけであれば、プロジェクトレベルのパッチが失われるだけです。それに加えてクラウドプロバイダーの非推奨が重なると、クラウドプロバイダーが管理するランタイムレベルのパッチも失われます。この両方が同時に失われると、アップグレードまたは延長サポートの取得以外に、単一の対策では埋めきれないセキュリティのギャップが生じます。
AWS Lambdaチームにとっては、これが同時に起きます。管理パッチ適用は4月30日に停止し、それはアップストリームEOLと同じ日です。GCP Cloud Runチームにとっては、非推奨は4月30日から始まりますが、管理パッチ適用は10月30日のデコミッションまで非推奨期間中は継続されます――AWSが提供しない6ヶ月の猶予があります。Azure App Serviceはコミュニティサポートのタイムラインに従い、EOL日にパッチ適用を停止します。
AWSまたはAzureで稼働しており、アップストリームEOLへの部分的な補完対策としてクラウドプロバイダーの管理パッチ適用に依存してきたチームは、4月30日にその補完対策を失います。GCPチームには猶予がありますが、10月30日のデコミッションのハードストップは、状況にかかわらず揺るぎない期限です。
次の48時間でやるべきこと
木曜日までにv22へのアップグレードが届く範囲にある場合――つまりアップグレードを完了し、検証プロセスを通過させ、4月30日までに本番環境へデプロイできる場合――は今すぐ実行してください。v20からv22への移行はほとんどのアプリケーションで直線的です。AWS・Azure・GCPはいずれもNode.js v22を有効なランタイムとしてサポートしています。アップグレードにより、EOLの問題は完全に解消されます。
木曜日までにアップグレードが完了できない場合――エンタープライズチームの多くにとってタイムライン上それが現実でしょう――の代替手段は、EOL日以降もv20への継続セキュリティサポートを提供するNES for Node.jsです。NESはv22へのアップグレードの代わりにはなりませんが、移行期間中のセキュリティギャップを埋め、不十分なテストを伴う急ぎのアップグレードへの焦りを取り除きます。
計画とは呼べないもの：5月1日を、何も決定せずに迎えることです。クラウドプロバイダーの非推奨が進行する中でv20を無パッチのまま動かし続けることは、時間の経過とともに改善されることなく悪化する複合的なセキュリティポジションです。
FAQ
Node.js v20アプリケーションは4月30日以降に動かなくなりますか？
なりません。Node.js v20アプリケーションは4月30日以降も稼働し続けます。EOLとはアップストリームのプロジェクトとクラウドプロバイダーがランタイムへのパッチ適用とサポートを停止することを意味し、アプリケーションの停止を引き起こすものではありません。運用リスクは未修正の脆弱性が放置されるにつれ、時間をかけて蓄積されます。
AWS LambdaはEOL後にNode.js 20をどう扱いますか？
AWSはNode.js 20 Lambdaランタイムを非推奨ステータスに移行します。ランタイムへの管理セキュリティパッチ適用は停止します。Node.js 20ランタイムを指定した新規関数デプロイと設定更新は、AWSが公表する非推奨タイムラインに応じて非推奨警告を受け取り、最終的にはハードブロックとなります。
非推奨後もAzureはNode.js 20上のアプリケーションをサポートしますか？
Azure App ServiceはNode.js 20アプリケーションの稼働を継続しますが、Microsoftは非推奨バージョンにおけるNode.js 20ランタイムの動作に関連する問題の調査・サポートを行いません。Azureプラットフォームレベルのサポートは引き続き利用可能ですが、Node.jsランタイム固有の問題は非推奨バージョンのサポート対象外となります。
アップストリームEOLとクラウドプロバイダーの非推奨の違いは何ですか？
アップストリームEOLとはNode.jsプロジェクトがv20へのパッチ適用を停止することです。クラウドプロバイダーの非推奨とはクラウドプロバイダーが管理するNode.js 20ランタイムへのパッチ適用を停止し、最終的にそのランタイム上の新規デプロイをブロックすることです。この両方が4月30日・5月1日の期間に発生します――プロジェクトレベルとクラウドプロバイダーレベルのセキュリティパッチを同時に失う状況です。
NES for Node.jsはEOL日以降に何を提供しますか？
NES for Node.jsは、4月30日のEOL日以降もNode.js v20に対してCVE監視・セキュリティパッチのバックポート・脆弱性の修正を提供します。NESにより、チームはNode.js v22 LTSへのアップグレードを計画・実行しながら、移行期間中もセキュアな状態を維持できます。
Node.js v20からv22への移行にどれくらいかかりますか？
大きな非互換性がないアプリケーションであれば、比較的短期間で完了できます――v20とv22のAPI差分は管理しやすい範囲です。ただし、エンタープライズ環境では、コードの複雑さとは別に、検証サイクル・変更管理の承認・段階的デプロイメントが時間を要します。4月30日までに移行を完了できないチームは、ギャップを空けたままにするのではなく、NESのカバレッジを確保すべきです。
HeroDevsのソリューションについては以下の記事もご参考ください！
はじめまして、HeroDevsです！