Azure SDK for JavaScriptをNode.js 20.xで使っているなら、結論はシンプルです。2026年7月9日までに、少なくともNode.js 22.x、できればNode.js 24.xへ移行する前提で準備を始めるべきです。 Microsoftは2026年4月6日、Azure SDK for JavaScriptが2026年7月9日以降Node.js 20.xをサポートしないと案内しました。Node.js 20自体も2026年4月30日にEOLを迎えるため、「今は動いているから後回し」で済ませるほど余裕はありません。(Microsoft for Developers)
この記事では、Azure SDK for JavaScriptユーザーがサポート終了前に何を確認し、22.xと24.xのどちらを選び、どんな失敗を先回りして潰すべきかを、Azure FunctionsやApp Serviceの事情も含めて整理します。
まず押さえたい結論
Azure SDK for JavaScriptの最低ラインは、2026年7月9日以降はNode.js 22.xです。一方でMicrosoftはActive LTSへの更新を推奨しており、2026年4月時点ではNode.js 24がActive LTS、Node.js 22がMaintenance LTSです。実務では、Azure Functionsなどの制約が強くなければ24.x、制約がある場合でも22.xまでは上げる、という判断が最も現実的です。(Microsoft for Developers)
Azure SDK for JavaScript の Node.js 20.x サポート終了で何が変わるか
Microsoftが今回の対応を行う理由は明確です。Node.jsは偶数版がLTSとしてサポートされ、最終的にEOLへ進みます。EOL後のバージョンはバグ修正やセキュリティ更新の対象外になるため、Azure SDK for JavaScriptもそれに合わせてサポート対象を見直します。(Microsoft for Developers)
日付で見る影響
| 日付 | 何が起こるか | 実務上の意味 |
|---|---|---|
| 2026年4月6日 | Microsoftがサポート終了の告知を公開。(Microsoft for Developers) | 移行計画を開始する基準日 |
| 2026年4月30日 | Node.js 20がEOL。(GitHub) | Node 20自体の更新が止まる |
| 2026年7月9日 | Azure SDK for JavaScriptがNode.js 22.xを最小サポートに変更。Node.js 20.xではengine warningが出て、engine-strict=true ならnpmインストールエラーになります。(Microsoft for Developers) | Node 20のままでは新しいSDK更新を追いにくくなる |
この日付の並びで重要なのは、Node.js 20のEOLとAzure SDK側のサポート終了が別日であることです。4月30日以降も7月9日までは「移行準備の猶予」があるように見えますが、ここを先延ばし期間として使うと、本番切り替え前の検証時間が足りなくなりやすいです。(Microsoft for Developers)
見落としやすいのは「メジャー更新なしで影響が出る」こと
Azure SDK for JavaScriptでは、EOLになったNode.jsのサポート打ち切りをメジャーバージョンアップなしで行う場合があります。そのため、^ 指定のまま依存更新を自動化していたり、DependabotやRenovateを自動マージにしていたりすると、「SDKを大きく上げた覚えがないのに、ある日からNode 20のCIだけが警告やエラーになる」という事態が起こり得ます。(Microsoft for Developers)
さらにややこしいのは、古いライブラリがNode.js 20で動き続ける可能性はあっても、それはサポート継続を意味しない点です。動作確認が偶然通ることと、サポート対象として安全に運用できることは別に考える必要があります。(Microsoft for Developers)
Node.js 22.x と 24.x のどちらへ移行すべきか
22.x が向いているケース
Azure Functionsを本番で使っていて、GAのランタイムを優先したいなら22.xが現実的です。2026年4月時点でAzure FunctionsではNode.js 22がGA、Node.js 24はPreviewです。さらにLinux ConsumptionではNode.js 22が最後にサポートされるNode.jsバージョンと案内されているため、Functions中心の構成では22.xを先に選ぶほうが無理がありません。Node.js 22のサポート終了予定は2027年4月30日で、Azure SDK for JavaScriptの新しい最低要件も満たせます。(Microsoft Learn)
24.x が向いているケース
App Service、コンテナ、VM、AKSなど、ホスト側の自由度が高い環境なら24.xが本命です。Node.js 24はActive LTSで、サポート終了予定は2028年4月30日です。App ServiceのクイックスタートでもNode 24 LTSが推奨されているため、新規開発や、今回の移行でできるだけ長く次の更新を先送りしたい案件は24.xのほうが後戻りしにくいです。(Node.js)
迷ったときの判断基準
Microsoft Learnでは、複数のLTSが並ぶ時期は中間のLTSを狙う考え方も紹介しています。一方で、今回のAzure SDK for JavaScriptの告知そのものはActive LTSへの更新を勧めています。判断に迷ったら、Functionsの制約やPreview回避が必要なら22.x、それ以外は24.xという見方にすると決めやすいです。(Microsoft Learn)
サポート終了前に確認すべき場所
| 確認箇所 | 何を見るか | 見落としやすい点 |
|---|---|---|
| ローカル開発環境 | node -v、.nvmrc、Volta/asdf、package.json の engines | ターミナルやIDEだけ20.xのまま |
| CI/CD | GitHub Actions の setup-node、Azure Pipelines のNode設定、ビルドエージェント | ローカルは更新済みでもCIだけ20.x |
| コンテナ | Dockerfile の FROM node:20、ベースイメージのタグ | アプリ設定だけ変えてイメージが古い |
| Azureホスト | Functions / App Service のランタイム設定、プラン制約 | コードは更新したのにホスト側が古い |
| 依存更新ルール | ^ 指定、Dependabot / Renovate の自動マージ条件 | minor更新で突然 engines 条件に引っかかる |
Azureでは、ローカル開発環境とホスト環境のNode.jsバージョンをそろえることが推奨されており、不一致はビルド失敗やランタイムの互換性問題につながります。加えて、Azure SDK for JavaScriptはメジャー更新なしでサポート対象を切り替える可能性があるため、バージョン番号だけでなく更新ルールまで見直すのが安全です。(Microsoft Learn)
実務で進めやすい移行手順
20.x が残っている場所を棚卸しする
最初にやるべきことは、Node.js 20.xがどこに残っているかを洗い出すことです。アプリ本体より、CI/CD、Dockerfile、Azureホスト設定のほうが後回しになりやすく、ここに20.xが残ると切り替え後のトラブルが増えます。
最低限、次の3点はすぐ確認しておくと進めやすいです。
- ローカルで使っているNode.jsのバージョン
- 依存インストール時の
engine-strictの状態 - 現在使っている
@azure/系パッケージと重要な周辺依存
node -v
npm config get engine-strict
npm ls --depth=0バージョン宣言をそろえる
移行先を22.xにするか24.xにするかを決めたら、バージョン宣言を1か所だけでなく全部そろえるのが基本です。package.json だけ直しても、CIやDockerが古いままだと意味がありません。
package.json の例です。22.xと24.xの両方を許容するなら、将来の未検証バージョンまで広げすぎない書き方のほうが管理しやすいです。
{
"engines": {
"node": ">=22 <25"
}
}GitHub Actionsの例です。24.xを選ぶなら、CIも同じ系統に合わせます。
- uses: actions/setup-node@v4
with:
node-version: 24
cache: npmコンテナを使っているなら、ベースイメージも見直します。
FROM node:24移行後は、CIだけでも engine-strict=true を有効にしておくと、古いNode.jsで依存を入れようとした時点で止められます。Azure SDK for JavaScriptの新しいリリースはNode.js 20環境でengine warningを出し、engine-strict=true ならnpmエラーになります。(Microsoft for Developers)
ステージングで重点テストを回す
Node.jsの移行で本当に怖いのは、「アプリは起動したのに、一部の経路だけ後で壊れる」パターンです。ステージングでは、単なる起動確認ではなく、Azure SDKを使う実処理を重点的に通してください。
特に確認したいポイントは次のとおりです。
DefaultAzureCredential、マネージドID、サービスプリンシパルなどの認証- Blob、Queue、Service Bus、Key Vaultなど、実際に使っているAzure SDKの主要操作
- ESMでJSONを読み込む処理
- 社内CA、プロキシ、古いTLS設定が絡む通信
- ネイティブアドオンを含むビルド工程
Node.js 22では import assert を使ったJSON importが使えなくなり、with 属性への書き換えが必要です。Node.js 24ではOpenSSL 3.5が入り、鍵長や暗号設定の要件が厳しくなっています。さらにV8更新の影響で、C/C++アドオンは再検証が必要になる場合があります。(Node.js)
たとえば、ESMでJSONを読むコードは次の形に直す必要があります。
import settings from './settings.json' with { type: 'json' };本番切り替え後のドリフトを防ぐ
切り替え後に起きやすいのが、ローカルは24.x、CIは22.x、Azureホストは20.xのような再分裂です。Azureではローカルとホストのバージョン整合が重要とされているので、リリース単位でまとめてそろえるほうが安全です。(Microsoft Learn)
運用に入ったら、次の3点も固定しておくと事故が減ります。
.nvmrcやVolta設定をリポジトリに置く- CIで
node -vをログに出す - Dependabot / Renovate の自動マージ条件にNode要件の確認を入れる
先に潰したい落とし穴
SDKを大きく上げていないのに突然失敗する
これは今回もっとも起きやすい落とし穴です。Azure SDK for JavaScriptは、EOLになったNode.jsのサポートをメジャーバージョンアップなしで外すことがあります。package.json のバージョン範囲が広いと、「昨日まで通っていた npm install が今日から警告やエラーになる」という変化が起きても不思議ではありません。(Microsoft for Developers)
TLSと古い暗号設定を使っている
Node.js 24のLTSビルドはOpenSSL 3.5を使い、既定のセキュリティレベルも維持されます。2048ビット未満のRSA/DSA/DH鍵やRC4系の暗号に依存している接続は通らない可能性があるため、社内プロキシや古い接続先がある環境は先に疎通試験をしたほうが安全です。(Node.js)
ネイティブアドオンが混ざっている
Azure SDK自体より、周辺のネイティブアドオンのほうが移行で詰まりやすいことがあります。Node.js 24ではV8 13.6に伴う変更があり、V8 APIに直接依存するC/C++アドオンは更新や再ビルドが必要になる場合があります。(Node.js)
App Serviceでパッチ版まで固定したい
App ServiceはNodeのメジャーバージョンは選べても、プラットフォーム側がminor / patchを管理します。特定の24.x.xに固定したい場合は、App Service標準のランタイムではなくカスタムコンテナを使う設計にしておく必要があります。(Microsoft Learn)
Node.js 20.x を使い続けるとどうなるか
直ちに全てが止まるとは限りません。Azure SDK for JavaScriptの古いライブラリはNode.js 20.xで動き続ける可能性がありますし、App Serviceでもサポート終了後にアプリ自体がそのまま動くケースはあります。ですが、それはサポート継続を意味しません。Node.js 20は2026年4月30日でEOLになり、App Serviceでもその後は該当ランタイム向けのセキュリティパッチやサポートを提供できません。Azure SDK側も2026年7月9日以降はNode.js 20.xを前提にしなくなるため、「動く」ことと「安心して運用できる」ことは分けて考えるべきです。(Microsoft for Developers)
最後にやるべきこと
最優先は、Node.js 20.xが残っている場所を今日中に洗い出すことです。その上で22.xか24.xかを決め、package.json、CI/CD、Dockerfile、Azureホスト設定を同じタイミングでそろえてください。Azure Functionsの制約が強いなら22.x、ホストの自由度が高いなら24.xが第一候補です。2026年7月9日より前にステージング検証まで終えられれば、Azure SDK for JavaScriptの更新を止めずに運用を続けやすくなります。(Microsoft for Developers)
コメント