Google CloudのCloud Runで、Node.js 20ランタイム（ランタイムID nodejs20）が2026年10月30日に廃止される[1]。廃止日を過ぎると、このランタイムでは新しいワークロードの作成も既存ワークロードの更新もできなくなり、動き続けているワークロードも無効化されることがある[2]。Node.js 22と24の廃止日はそれぞれ2027年と2028年の10月31日で、20だけが30日になっている[1]。
期限がかかるのは、ソースからデプロイしたサービスやCloud Run functionsのように、Googleが提供するnodejs20のベースイメージの上で動くワークロードである[1][2]。Node.js 20を含むイメージを自前のDockerfileでビルドし、--base-imageを付けずにデプロイしている場合、この期限は適用されない。ただし上流のNode.js 20自体が2026年4月30日にEOL（サポート終了）を迎えているので[3]、そちらも更新は要る。期限の有無を分けるのはコードの中身ではなく、Googleのベースイメージの上で動いているかどうかである。
予備知識
- Cloud Run: コンテナ化したアプリケーションをサーバー管理なしで動かせるGoogle Cloudのサーバーレス実行環境。関数単位でコードを動かす形態をCloud Run functionsと呼ぶ
- ベースイメージ（base image）: OSとNode.jsなどの言語ランタイムをまとめたコンテナイメージ。Cloud Runでは
nodejs24のようなランタイムIDで指定する[1] - 非推奨化（deprecation）と廃止（decommission）: Cloud Runのランタイムのライフサイクル上の2つの日付。非推奨化の後も作成と再デプロイはでき、廃止日以降はできなくなる[2]
- EOL（End-of-Life）: Node.jsプロジェクト自身が、そのリリース系列への修正の提供を終える日。Node.js 20は2026年4月30日だった[3]
モジュールの書き方からテスト、Dockerでのデプロイまで、Node.jsの実行と運用の基礎を押さえ直したい担当者に。
10月30日に止まるものと、期限がかかる範囲
Cloud RunとCloud Run functionsのNode.js 20は、2026年4月30日に非推奨化され、2026年10月30日に廃止される[1]。Googleは非推奨化の90日前からGoogle Cloudコンソールで通知を出すと定めており[2]、定めどおりならNode.js 20の通知は2026年1月末に始まっている。
非推奨化と廃止で変わることを、Googleのライフサイクル表から抜き出すと次のようになる[2]。
| 項目 | 非推奨の期間（2026/4/30〜） | 廃止後（2026/10/30〜） |
|---|---|---|
| 作成と再デプロイ | できる | できない |
| 既存ワークロードの実行 | 続く | 無効化されることがある |
| 言語・システムパッケージ・OSのパッチ | GA期間と同じ（As per policy） | 更新なし |
| カスタマーサポート | ランタイムのサポートなし | ランタイムのサポートなし |
ライフサイクル表の上では、非推奨の期間もパッチの欄はGA期間と同じで、変わるのはサポートの欄である。一方、Node.js 20本体の修正は、上流のNode.jsプロジェクトが同じ4月30日にEOLとしたため出ていない[3]。Cloud Runの非推奨化の日付は、22と24でも上流のEOLと一致している[1][3]。
| ランタイム | 上流のEOL | Cloud Runの非推奨化 | Cloud Runの廃止 |
|---|---|---|---|
| Node.js 20 | 2026-04-30 | 2026-04-30 | 2026-10-30 |
| Node.js 22 | 2027-04-30 | 2027-04-30 | 2027-10-31 |
| Node.js 24 | 2028-04-30 | 2028-04-30 | 2028-10-31 |
22と24も同じ間隔で続くので、同じ判断は2027年と2028年にも回ってくる。
期限がかかる範囲には条件がある。Googleは、Cloud Runに直接デプロイしたコンテナイメージはこのポリシーの対象ではなく、適用されるのはGoogleマネージドのベースイメージを使うワークロードだけだとしている[2]。構成ごとに分けると次のようになる。
| 構成 | 使われるNode.js | 10月30日の期限 |
|---|---|---|
| ソースからデプロイ（Dockerfileなし） | ビルドパックがGoogleのベースイメージでビルド[4] | 対象 |
Cloud Run functions、--base-imageを付けたサービス | 指定したGoogleのベースイメージ[5][6] | 対象 |
| Node.js入りのイメージを自前のDockerfileでビルド | FROM行で指定したイメージ | 対象外（Node.js 20は上流で2026-04-30にEOL[3]） |
Dockerfileを使っていても、アプリだけを載せたscratchイメージに--base-imageでGoogleのベースイメージを重ねる構成（自動ベースイメージ更新）は対象に入る[1][2][5]。「Dockerfileがあるから対象外」とは限らず、見るべきはGoogleのベースイメージを指定しているかどうかである。
毎年回ってくるランタイム更新の確認を、GitHub Actionsのマトリックスや環境ごとのデプロイとして仕組みに組み込みたい人に。
何を確認し、どう移行するか
最初の作業は、Node.js 20で動くサービスと関数の洗い出しである。--base-imageを付けたサービスなら、gcloud run services describe SERVICE --format exportで書き出したYAMLのrun.googleapis.com/base-imagesアノテーション、Terraformならgoogle_cloud_run_v2_serviceのbase_image_uriに、ベースイメージの指定が入る[5]。nodejs20、google-22-full/nodejs20のようにスタック名を付けた形、または末尾がruntimes/nodejs20のURLなら対象である[1]。gcloud run deployで関数をデプロイする場合も、--base-imageでランタイムを指定する[6]。gcloud functions deployで作った関数はgcloud functions describeで表示されるランタイムを確かめる。1st genの関数も、Node.js 20の非推奨化と廃止の日付は同じである[7]。
Dockerfileなしのソースデプロイでは、Node.jsのバージョンをビルドパックが決める。環境変数GOOGLE_NODEJS_VERSIONがあればpackage.jsonのengines.nodeより優先され、どちらも無ければ最新のLTS版が使われる[8]。package.jsonだけを見ても、実際に動いているバージョンは確定しない。
移行先は22か24になる。廃止日が最も遅いのは24（2028年10月31日）で、公式ドキュメントのデプロイ例も--base-image nodejs24を使っている[5][6]。22を選ぶと、1年後の2027年10月31日に同じ作業が回ってくる[1]。26はプレビューの段階で、非推奨化と廃止の日付はまだ決まっていない[2]。
数百のWebアプリをAzure App Serviceで運用し、年次のセキュリティ監査を受ける企業のプラットフォーム担当者は、2026年後半に複数のランタイムが立て続けにサポート終了を迎える事態に向き合うことになる。対象はAzure Ap[…]
移行を先送りするとどうなるか
10月30日を過ぎると、nodejs20のままでは新しいリビジョンを出せない[2]。障害の修正や設定変更のためのデプロイも、ランタイムを上げない限り通らず、ランタイムの更新と障害対応を同時に抱えることになる。
パッチの面では、廃止後は言語・システムパッケージ・OSのいずれも更新されなくなる[2]。自動ベースイメージ更新を使わず、デプロイ時にだけ更新を取り込む設定のサービスは、非推奨の期間中でも再デプロイしなければOSのパッチが入らない[5]。
20から24へ一度に上げると、22で入った変更と、23・24で入った変更をまとめて受ける。Node.jsの公式移行ガイドは、22でJSONの読み込みに使うimport ... assert { type: 'json' }の構文が削除されてwithが必須になったこと、crypto.createCipher()が削除されたことを挙げている[9]。Node.js 24の公式バイナリはOpenSSL 3.5を含み、既定のセキュリティレベル2で2048ビット未満のRSA鍵やRC4の暗号スイートを受け付けない[10]。古い証明書や暗号設定の接続先を持つバッチは、ベースイメージの差し替えだけでは動かないことがある。
Kubernetesクラスタを本番環境で運用する情報システム部門・SREチームが、2026年8月26日リリース予定のKubernetes 1.37で向き合うことになる変更がある[1]。長年使われてきたkube-proxyのIPVSモードが[…]
委託開発のサービスは、納品の形で期限の有無が分かれる
開発を外部に委託したCloud Runのサービスでは、最初に納品の形を確かめる。日本語版のドキュメントも「Cloud Run ライフサイクル ポリシーは、Cloud Run の外部でビルドされたコンテナには適用されません。」と明記している[11]。SIerが自社のCIでNode.jsを含むイメージをビルドし、--base-imageを付けずに発注側のプロジェクトへデプロイしている構成なら、10月30日の期限は直接かからない。論点は、そのDockerfileのFROM行に残るNode.js 20を、上流のEOL[3]を踏まえていつ更新するかに移る。
ソースコードを受け取ってgcloud run deploy --sourceでデプロイしている構成は事情が違う。ソースディレクトリにDockerfileが無ければ、ビルドパックがGoogleのベースイメージでビルドし、期限の対象になる。Dockerfileがあれば、そのDockerfileでビルドされる[4]。同じソースデプロイでも、リポジトリにDockerfileがあるかどうかで結論が変わる。
保守契約の論点は、この区別の上に置く。日本語版は、サポートが終了する前にサービスを新しい言語ランタイムにアップグレードするのは「デベロッパーの責任です」と書く[11]。委託開発では、このデベロッパーが発注側とSIerのどちらに当たるかを契約で決めておく。SIerの自社CIでビルドする構成ならDockerfileとビルド手順の更新が、ソースデプロイの構成なら発注側のプロジェクトでの再デプロイと動作確認が、その中身になる。
日付は日本語版だけで確かめないほうがよい。9月15日時点で、日本語版の「Cloud Run ランタイムのライフサイクル」（最終更新2025年11月12日）はNode.js 24を「プレビュー版」とし、非推奨・廃止日を空欄のまま載せている[12]。「サポートされている言語ランタイムとベースイメージ」の日本語版（同2025年12月18日）には日付の列がない[11]。英語版はどちらも2026年9月9日に更新され、Node.js 24の日付を載せている[1][2]。
まとめ
Cloud Run上のNode.js 20は2026年10月30日に廃止され、nodejs20のままでは作成も更新もできなくなる[2]。対象はGoogleのベースイメージで動くワークロードで、非推奨化の日付は上流のEOLと同じ4月30日だった。22と24も同じ周期で続く。
10月30日までの作業は3つに絞れる。--base-image、base_image_uri、GOOGLE_NODEJS_VERSIONとengines.nodeを見て、Node.js 20で動くものを洗い出す。移行先は廃止日の遅い24を基本にし、import ... assertや古い暗号設定のような22〜24の変更点を非本番で確かめる。自前のDockerfileでビルドしているイメージも、FROM node:20が残っていれば同じ時期に上げる。
よくある質問（FAQ）
Q. Node.js 20のCloud Runサービスは10月30日を過ぎたら即座に止まるのか。
A. 公式の記述は、廃止されたランタイムを使い続けるワークロードは無効化されることがある、というもので、止める日付は示していない[2]。確実なのは、10月30日以降はnodejs20のまま新規作成も更新もできなくなることである[2]。
Q. 自前のDockerfileでビルドしたイメージも期限の対象になるか。
A. Node.jsを含むイメージをCloud Runの外でビルドしているなら対象外である[1][2]。ただしNode.js 20は上流で2026年4月30日にEOLを迎えている[3]。scratchイメージに--base-imageでGoogleのベースイメージを重ねる構成は対象になる[5]。
Q. Node.js 22と24のどちらに移行すべきか。
A. 廃止日が最も遅いのは24（2028年10月31日）で、公式ドキュメントのデプロイ例もnodejs24を使っている[5][6]。22なら2027年10月31日に次の期限が来る[1]。24ではOpenSSL 3.5の既定設定で短い鍵が拒否されるなど22に無い変更もあるため[10]、非本番での確認は24で行う。
Q. package.jsonのengines.nodeを書き換えれば移行は終わるか。
A. 終わらない場合がある。ビルドパックでは環境変数GOOGLE_NODEJS_VERSIONがengines.nodeより優先される[8]。--base-imageでランタイムを指定する構成では、その指定をnodejs22かnodejs24に変える必要がある[5][6]。Cloud Run functionsでは、engines.nodeをデプロイに使うランタイムと両立する値にするよう、ビルドパックのドキュメントが求めている[8]。
出典
[1] Supported language runtimes and base images（Cloud Run, Google Cloud Documentation）[2] Cloud Run runtime lifecycle（Google Cloud Documentation）
[3] nodejs/Release: Node.js Release Working Group（GitHub）
[4] Deploy services from source code（Cloud Run, Google Cloud Documentation）
[5] Configure automatic base image updates（Cloud Run, Google Cloud Documentation）
[6] The Node.js runtime（Cloud Run, Google Cloud Documentation）
[7] Runtime support（Cloud Run functions, Google Cloud Documentation）
[8] Building a Node.js application（Buildpacks, Google Cloud Documentation）
[9] Node.js v20 to v22（Node.js）
[10] Node.js v22 to v24（Node.js）
[11] サポートされている言語ランタイムとベースイメージ（Cloud Run, Google Cloud Documentation 日本語版）
[12] Cloud Run ランタイムのライフサイクル（Google Cloud Documentation 日本語版）
