Vercel で Node.js 20 を使っているプロジェクトは今すぐ確認を
Node.js 20 は 2026年4月30日付で公式 EOL（End of Life）を迎えます。これに合わせて Vercel は、Builds および Functions における Node.js 20 を 2026年10月1日付で非推奨化すると発表しました。
ここで押さえておきたいポイントは、**「既存デプロイは影響を受けず、新規デプロイのみブロックされる」**という点です。すでに稼働中の Serverless Functions は通常通り呼び出せますが、10月1日以降に新規デプロイを行うと、Project Settings で Node 20 が無効化されエラーが発生します。
実務でよくある落とし穴は、**「自分のプロジェクトがどの Node バージョンを使っているか把握していない」**というケースです。Vercel プロジェクトが複数あると、いつどのバージョンで作成したか記憶に残っていないことも多いでしょう。まずは 影響を受けるプロジェクトを洗い出すことから始めるのが定石です。
本記事の根拠資料は Vercel 公式 Changelog です。日本国内で Vercel を利用している個人開発・スタートアップ・受託開発のいずれにおいても該当する内容ですので、最後までご確認ください。
影響範囲の特定とアップグレード手順
ステップ1: 影響を受けるプロジェクトの一覧を取得
Vercel CLI を最新版に更新したうえで、以下のコマンドを実行すると、非推奨 Node バージョンを使用しているプロジェクトのみが抽出されます。
# Vercel CLI を最新版に更新
npm i -g vercel@latest
# 非推奨の Node.js バージョンを使用しているプロジェクトを一覧表示
vercel project ls --update-required
この 1 コマンドで「どこから手を付けるべきか」のリストが即座に得られます。チーム単位でアカウントを運用している場合は、必ず一度実行しておきましょう。
ステップ2: Node バージョンのアップグレード（手動）
最も確実な方法は、package.json の engines フィールドを修正することです。Project Settings のバージョンよりも engines フィールドが優先されます。
{
"engines": {
"node": "24.x"
}
}
あわせて、以下のファイルに Node 20 が固定されていないかも確認し、整理しておきましょう。
.nvmrc.node-version- CI 設定ファイル（GitHub Actions、CircleCI など）
ローカルランタイムも Node 24 に切り替え、node_modules を再インストールしたうえで、ビルドとテストを実行し、破壊的変更を洗い出します。
ステップ3: コーディングエージェントへの委任
近年は、この作業自体を AI コーディングエージェントに委任できます。以下のプロンプトをそのまま貼り付ければ OK です。
Upgrade this Vercel project from Node.js 20 to 24.
Set the engines field in package.json to { "node": "24.x" },
which overrides the Project Settings version on the next deployment.
Update any Node 20 pins in .nvmrc, .node-version, or CI configs.
Switch the local runtime to Node 24, reinstall dependencies,
run the build and tests, and fix any breaking changes.
After deploying, confirm the version by logging process.version.
デプロイ後は console.log(process.version) を出力し、実際に Node 24 で動作しているかを必ず検証してください。Project Settings を変更しただけで満足してしまい、実は反映されていなかった、というケースは少なくありません。
10月1日までに間に合わない場合 — コンテナデプロイによる回避策
現実的に、レガシープロジェクトを 1 か月で Node 24 に引き上げるのは容易ではありません。特に依存関係が複雑なプロジェクトではなおさらです。そのような場合に Vercel が提示している回避策が、コンテナイメージとしてのデプロイです。
プロジェクトルートに Dockerfile.vercel を追加すると、コミットごとにイメージがビルドされデプロイされます。
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
# サーバーは必ず $PORT をリッスンする必要があります
CMD ["node", "server.js"]
重要なのは、コンテナデプロイには Project Settings の Node バージョンが適用されないという点です。そのため Node 20 の非推奨化ポリシーの対象外となります。
比較: どちらの方式を選ぶべきか
| 項目 | engines フィールド更新 | Dockerfile.vercel コンテナデプロイ |
|---|---|---|
| 難易度 | 低（設定変更のみ） | 中（Dockerfile の管理が必要） |
| Node 20 の維持 | ❌（強制アップグレード） | ✅（ベースイメージで固定） |
| セキュリティパッチ | Vercel が管理 | 自身で管理が必要 |
| ビルド時間 | 高速 | イメージビルドのためやや遅い |
| 推奨ケース | 新規プロジェクト、依存整理が可能 | レガシー、移行リスクが大きい |
⚠️ この手法の限界と注意点
- コンテナは「回避」であり「解決」ではありません。 Node 20 自体が EOL であるため、セキュリティ脆弱性へのパッチは自身で対応する必要があります。
- イメージサイズの管理を怠るとコールドスタートが遅くなります。
alpineベースであっても、不要な devDependencies が含まれないようnpm ci --omit=devの利用を検討してください。 $PORTのリッスン漏れは最も多い失敗例です。Vercel コンテナは動的にポートを注入するため、ハードコードしてはいけません。- 日本の受託開発では、クライアント側が Node 20 固定を要求するケースがあります。その場合、コンテナデプロイが唯一の現実的な選択肢となり得ます。
まとめ: 10月1日は「締切」ではなく「チェックポイント」
整理すると以下のとおりです。
- 2026年10月1日より、Vercel における Node.js 20 の新規デプロイがブロックされます。
- 既存デプロイは継続稼働しますが、いずれ必ずアップグレードが必要です。
vercel project ls --update-requiredで影響範囲を先に把握しましょう。enginesフィールドの修正が最もクリーンで、難しい場合はDockerfile.vercelで時間を稼げます。- デプロイ後は
process.versionのログで必ず検証してください。
次のステップ学習の方向性
- Node 24 の新機能を事前に確認しておきましょう。
require(esm)のサポートやAsyncLocalStorageの改善など、移行のついでに活用できる要素が多くあります。 - Vercel のコンテナデプロイに慣れておくと、他のランタイム（Python、Go など）も柔軟に扱えるようになります。
- チーム単位で運用している場合は、Node バージョンポリシーを文書化し、CI で
enginesフィールドを検証するスクリプトを組み込むことを推奨します。
あわせて読みたい記事
今回の非推奨化は、「いつかやろう」と先送りにしてきた技術的負債を清算するサインです。今すぐプロジェクト一覧を取得するだけでも、対応の半分は終わったも同然です。