---
title: "Node.js 26の新機能と破壊的変更・LTS移行日｜24からの移行手順【26.11.1対応】"
url: "https://www.issoh.co.jp/tech/details/12014/"
published: 2026-05-07
updated: 2026-10-25
categories: ["Node.js"]
publisher: "株式会社一創"
---

# Node.js 26の新機能と破壊的変更・LTS移行日｜24からの移行手順【26.11.1対応】

Node.js 26は2026年5月5日にCurrentとしてリリースされ、2026年10月28日にLTS（長期サポート）へ移り、2029年4月30日にサポートが終わります。中身の目玉はTemporal APIの既定有効化、V8 14.6、Undici 8の3つで、Undici 8では組み込みの`fetch`がHTTP/2で通信するようになりました。本記事は2026年10月14日時点の26系最新リリース26.11.1を基準に、日程、24との違い、新機能、削除されたAPI、AWS LambdaやDockerでの対応状況、Node.js 24から上げるときの手順を、Node.js公式のリリースノートとスケジュール定義、公式配布バイナリでの実行結果から整理します。

## まとめ：Node.js 26のLTS日程と移行前に確認すること

- **日程**：2026年5月5日リリース、10月28日にActive LTS、2027年10月20日からMaintenance LTS、2029年4月30日にEOL。
- **位置づけ**：偶数版がLTSになる現行方式で出る最後の版。27以降は年1回リリースで全版がLTSになる。
- **新機能**：`Temporal`がフラグ無しで使える。`Map.prototype.getOrInsert()`と`Iterator.concat()`が追加。`fetch`はHTTP/2対応サーバーにHTTP/2で接続する。26.11.0で`node:sqlite`のクラス名が`Database`に変わり、テストの止まらない原因を表示する`--process-timeout`が入った。
- **壊れる箇所**：`response.writeHeader()`と`_stream_*`モジュールが削除、`--experimental-transform-types`が削除、`module.register()`は実行時警告。Node.js固有のABIに依存するネイティブアドオンは、147向けのビルドへの更新か再ビルドが要る（NODE\_MODULE\_VERSION 147）。
- **実行環境**：AWS Lambdaの`nodejs26.x`は2026年8月25日からのパブリックプレビューで、本番には使えない。Docker公式イメージには26.11.1のタグがある。
- **本番の移行時期**：Node.js 24は2028年4月30日までサポートされるので、本番はLTS入り後に上げれば十分です。ライブラリはCIに26を今すぐ加えます。

## Node.js 26のリリース日・LTS入り・EOLの日程

Node.jsのリリース日程は、公式リポジトリnodejs/Releaseの[schedule.json](https://github.com/nodejs/Release/blob/main/schedule.json)が正本です。2026年10月14日時点の各系列は次のとおりです。

| 系列              | 状態（10月14日時点）    | 初回リリース     | Active LTS開始 | Maintenance開始 | EOL        |
| --------------- | --------------- | ---------- | ------------ | ------------- | ---------- |
| 26.x（Lithium予定） | Current         | 2026-05-05 | 2026-10-28   | 2027-10-20    | 2029-04-30 |
| 24.x（Krypton）   | Active LTS      | 2025-05-06 | 2025-10-28   | 2026-10-20    | 2028-04-30 |
| 22.x（Jod）       | Maintenance LTS | 2024-04-24 | 2024-10-29   | 2025-10-21    | 2027-04-30 |
| 25.x            | EOL             | 2025-10-15 | なし           | 2026-04-01    | 2026-06-01 |

10月20日に24系がMaintenance LTSへ移り、8日後の28日に26系がActive LTSになります。LTS入りの時点でコードネームが付き、予定名の一覧（nodejs/ReleaseのCODENAMES.md）では26.xは「Lithium」です（`schedule.json`の`codename`は10月14日時点でまだ空欄）。バージョン管理ツールの`lts/*`は最新のLTSを指す可変の別名で、10月28日に26系がLTSになった後、ツールがリリース情報を取り直した時点で解決先が24系から26系へ変わります。nvmはnodejs.orgに接続したときにローカルのLTS別名を作り直す仕組みで、日付が来ただけでインストール済みのNode.jsが切り替わるわけではありません。LTSという区分そのものや`lts/*`の固定方法は[Node.js LTSの現行版確認とlts/\*の固定・移行時期](/tech/details/17906/)で扱っています。

### 偶数版LTS方式の最後の版と、27以降の年1回リリース

Node.jsのリリース担当チームは2026年3月10日の公式ブログ「[Evolving the Node.js Release Schedule](https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule)」で、27.xから年2回のメジャーリリースを年1回に減らすと発表しました。26はこの変更前の方式に従う最後の系列です。

- 毎年10月から翌3月まではAlpha（semver-majorの変更を含む検証版。バージョンは`27.0.0-alpha.1`形式）
- 4月にCurrentとして正式リリースし、10月にLTSへ昇格。LTS期間は30か月で、初回リリースからEOLまで36か月
- 奇数・偶数の区別をなくし、すべての版がLTSになる。版番号は初回リリースの西暦に合わせる（27.0.0は2027年、28.0.0は2028年）

`schedule.json`の27.xは、Alpha開始が2026年10月28日（26のLTS入りと同日）、Current開始が2027年4月22日、EOLが2030年4月30日です。27.xには`lts`のキーが無く、2027年10月20日から`maintenance`になります。変更の理由としてブログは、奇数版の利用が少ないこと、4〜5系列へのセキュリティ修正の移植がボランティア中心の体制で限界にきていることを挙げています。なお同ブログの表は26.0.0を「April 2026」としていますが、実際のリリースは5月5日でした。

## Node.js 24と26の違い（比較表）

両系列の最新版（24.21.0と26.11.1）をnodejs.orgの公式配布バイナリで起動し、`process.versions`などで取った値です。

| 項目                      | Node.js 24.21.0     | Node.js 26.11.1     |
| ----------------------- | ------------------- | ------------------- |
| V8（process.versions.v8） | 13.6.233.17-node.53 | 14.6.202.34-node.37 |
| Undici（fetchの実装）        | 7.29.1              | 8.11.2              |
| fetchが使うHTTP            | 1.1                 | 2.0（相手が対応していれば）     |
| Temporal                | 無し（`undefined`）     | 既定で有効               |
| NODE\_MODULE\_VERSION   | 137                 | 147                 |
| 同梱npm                   | 11.19.0             | 11.20.0             |
| `--process-timeout`     | bad option          | 使える                 |
| EOL                     | 2028-04-30          | 2029-04-30          |

サポート期間の差は1年です。22系（EOL 2027年4月30日）から上げる場合は、どちらへ移っても削除されたAPIとアドオンの再ビルドへの対応が要るので、移行作業を1回で済ませたいなら26を選ぶ方が得です。24から26への差分は以下の各章で順に扱います。

## Temporal APIの既定有効化と日付処理の変わり方

[26.0.0のリリースノート](https://nodejs.org/en/blog/release/v26.0.0)は最初の項目でTemporal APIの既定有効化を挙げています。24系ではV8のフラグ`--harmony-temporal`を付けたときだけ現れた`Temporal`が、フラグ無しでグローバルに存在します。`Date`との違いが最も出るのは、月末をまたぐ加算とタイムゾーンの扱いです。

```
// Date：1月31日に「1か月」を足すと2月31日が繰り越されて3月3日になる
const old = new Date(2026, 0, 31);
old.setMonth(1);
console.log(old.getMonth() + 1, old.getDate()); // 3 3

// Temporal：月末に丸められる
const d = Temporal.PlainDate.from('2026-01-31');
console.log(d.add({ months: 1 }).toString()); // 2026-02-28

// タイムゾーン付きの時刻はDST（夏時間）の切替も計算に入る
const z = Temporal.ZonedDateTime.from('2026-03-08T01:30[America/New_York]');
console.log(z.add({ hours: 1 }).toString());
// 2026-03-08T03:30:00-04:00[America/New_York]
```

上の出力は公式配布の26.11.1で実行した結果です。`Temporal.PlainDate`（日付だけ）、`Temporal.ZonedDateTime`（タイムゾーン付き）、`Temporal.Instant`（時点）と型が分かれており、いずれも不変オブジェクトなので`add()`は新しい値を返します。26.2.0では`fs.Stats`にも`Temporal.Instant`の時刻フィールドが加わりました。

date-fnsやDay.jsを今すぐ外す必要はありません。Temporalは24系では既定で無効（実験的フラグが必要）で、未対応のブラウザもあるため、同じコードを複数の実行環境で動かすなら、ライブラリのままにするかポリフィルを併用します。サーバー側だけで完結し、26以上に固定できるコードから置き換えるのが順当です。

### Homebrew版のTemporal非搭載とビルド設定

Temporalが「既定で有効」なのは公式ビルドの話です。V8のTemporal実装はRust製のライブラリに依存しており、ビルド時の設定`v8_enable_temporal_support`で有無が決まります。macOSのHomebrewで入れたnode 26.5.0ではこの値が`0`で、`typeof Temporal`は`"undefined"`でした。Homebrewのformulaにも「`--shared-temporal_capi`は`--v8-enable-temporal-support`付きでビルドする場合にだけ使う」との注記があり、同フラグは渡されていません。

```
node -p "process.config.variables.v8_enable_temporal_support + ' ' + typeof Temporal"
// 公式tarball 26.11.1  → 1 object
// Homebrew 26.5.0      → 0 undefined
```

手元で動いたのにCIで`Temporal is not defined`になる、あるいはその逆は、この差で起きます。Temporalを使うなら、開発機・CI・本番のNode.jsの入手元をnodejs.orgの配布物（nvmやVolta、公式Dockerイメージ等）にそろえ、上のコマンドで確認してください。

### TypeScriptでTemporalを型付けする設定

Temporalの型は`@types/node`ではなくTypeScript本体のlibで提供されます。`@types/node` 26.6.3の`fs.d.ts`には「TS 6.0未満のサポートを外したらTemporal組み込み型に置き換える」というTODOがあり、Node.js側では型を定義していません。TypeScript 7.0.2で確かめると、`"lib": ["es2025"]`では`Temporal`がTS2304（名前が見つからない）、`getOrInsert`がTS2550になり、`"lib": ["esnext"]`にすると両方通りました。

`@types/node`の26系は、Node.js 26のリリースから45日後の2026年6月19日に26.0.0が公開され、10月14日時点のlatestは26.6.5（10月9日公開）です。

## V8 14.6とUndici 8で変わるJavaScriptとHTTPの挙動

### V8 14.6で追加されたMapの値挿入とIteratorの連結

V8は26.0.0で14.6.202.33（Chromium 146相当）に上がり、26.11.1では14.6.202.34です。ES2026に入った2つの提案が使えるようになりました。

```
const cache = new Map();
// キーが無いときだけ値を入れて返す（has→set→getの3行が1行になる）
cache.getOrInsert('a', 1);            // 1
cache.getOrInsert('a', 2);            // 1（既存値のまま）
// 値の生成が重い場合は関数で渡す
cache.getOrInsertComputed('b', (k) => k.toUpperCase()); // 'B'

// 複数の反復可能オブジェクトを配列化せずに連結
[...Iterator.concat([1, 2], new Set([3]))]; // [1, 2, 3]
```

`WeakMap`にも同じ`getOrInsert`と`getOrInsertComputed`があります。ES2026に入った機能でも`Math.sumPrecise`は26.11.1で`undefined`のままで、V8のフラグ`--js-sum-precise`が要ります。`Error.isError`と`Uint8Array.fromBase64`は既定で使えます。ECMAScriptの版ごとの収録機能は[ECMAScriptとは](/column/details/7574/)で一覧にしています。

### fetchのHTTP/2既定有効化（Undici 8）

組み込みの`fetch`を実装するUndiciは、26.0.0で8.0.2に上がり、26.11.1では8.11.2です。Undici 8.0.0のリリースノートには「feat!: enable h2 by default」とあり、HTTP/2が既定で有効になりました。HTTP/1.1とHTTP/2の両方を受け付けるTLSサーバーに`fetch`で接続し、サーバー側で`req.httpVersion`を出すと、結果は次のように分かれます。

| Node.js | Undici | サーバーが受けたHTTPバージョン |
| ------- | ------ | ----------------- |
| 24.21.0 | 7.29.1 | 1.1               |
| 26.11.1 | 8.11.2 | 2.0               |

コードを変えなくても、ALPNでHTTP/2を提示する相手とはHTTP/2で話すようになります。影響が出やすいのは、HTTP/1.1前提で組まれた社内プロキシやAPIゲートウェイ、ヘッダー名の大文字小文字に依存した処理（HTTP/2ではヘッダー名が小文字になる）、1リクエスト1コネクションを前提にした接続数の監視です。26へ上げたら外部APIを叩く結合テストを必ず通し、問題が出た接続だけ、npmの`undici`パッケージから`Agent`を`allowH2: false`で作って`fetch`の`dispatcher`オプションに渡します。

```
import { Agent } from 'undici';

const dispatcher = new Agent({ allowH2: false });
const res = await fetch('https://api.example.com/', { dispatcher });
await res.body?.cancel();
await dispatcher.close();
```

本文を読まない通信は例のように`cancel()`で捨て、使い終わった`Agent`は`close()`で閉じます（Undiciは接続の解放をガベージコレクション任せにしないよう求めています）。26.11.1とundici 8.11.2の組み合わせで、上と同じサーバーが受けたバージョンが1.1に戻ることを確かめています。

## 削除・非推奨になったAPIと移行先

26.0.0で動かなくなるもの（削除）と、警告が出るようになったもの（実行時非推奨）を分けて並べます。削除されたAPIは、そのコードが実行された時点でエラーになります。テストで通らない分岐に残っていれば見逃すため、テストの成否だけでなくソースの検索でも確かめます。

| 対象                                          | 26での扱い  | 移行先                      |
| ------------------------------------------- | ------- | ------------------------ |
| `response.writeHeader()`                    | 削除      | `writeHead()`            |
| `_stream_wrap`等6モジュール                       | 削除      | `node:stream`            |
| `--experimental-transform-types`            | 削除      | tsc等でトランスパイル             |
| authTagLength未指定の短いGCM認証タグ（DEP0182）         | 削除      | `authTagLength`を明示       |
| `module.register()`（DEP0205）                | 実行時警告   | `module.registerHooks()` |
| crypto APIへの`CryptoKey`渡し（DEP0203）          | 実行時警告   | `KeyObject`              |
| 抽出不可`CryptoKey`の`KeyObject.from()`（DEP0204） | 実行時警告   | 抽出可能な鍵で生成                |
| `Duplex.toWeb()`の`type`（DEP0201）            | 実行時警告   | `readableType`           |
| `sqlite.DatabaseSync`（DEP0210・26.11.0）      | 文書上の非推奨 | `sqlite.Database`        |
| `sqlite.StatementSync`（DEP0211・26.11.0）     | 文書上の非推奨 | `sqlite.Statement`       |

削除された`_stream_*`は`_stream_wrap`、`_stream_readable`、`_stream_writable`、`_stream_duplex`、`_stream_transform`、`_stream_passthrough`の6つで、`require('_stream_wrap')`を実行すると`MODULE_NOT_FOUND`になります。自分のコードに無くても古い依存パッケージが読んでいることがあるので、`node_modules`を`grep -r "_stream_"`で一度確かめておくと安心です。

ほかに、`--localstorage-file`を指定しないと`localStorage`が`undefined`になる変更と、ML-KEM・ML-DSAの秘密鍵をPKCS#8で書き出すときの既定がシードのみの形式になる変更もsemver-majorとして入っています。

### `--experimental-transform-types`削除とTypeScriptのenum移行

Node.jsはTypeScriptの型注釈を取り除いて実行できますが（型除去）、`enum`や`namespace`のように実行時のコードを生成する構文は変換が必要で、26でその変換用フラグ`--experimental-transform-types`が消えました。

```
$ node --experimental-transform-types e.ts
node: bad option: --experimental-transform-types

$ node e.ts   # e.ts の中身: enum E {A}; console.log(E.A)
SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript enum is not supported in strip-only mode
```

型注釈だけのファイル（`const x: number = 1`等）はそのまま動きます。`enum`を使っている場合は、`as const`を付けたオブジェクトへ書き換えるか、tscなどでJavaScriptに変換してから実行します。TypeScript側の変更点は[TypeScript 6.0とは｜新機能・5から6への移行手順とGo製7.0対応まで総まとめ](/tech/details/11066/)にまとめています。

### module.register()の非推奨化とregisterHooks()への移行

`module.register()`は別スレッドで非同期に動くカスタマイズフックで、26では同じプロセスで最初に呼び出したときに`DEP0205`の警告が1回出ます。[公式ドキュメント（DEP0205）](https://nodejs.org/api/deprecations.html#DEP0205)は、非同期フックはワーカースレッドの調停が複雑で解決できない問題があるとして、同期・同一スレッドで全種類のモジュールに効く`module.registerHooks()`への移行を求めています。

```
import { registerHooks } from 'node:module';

registerHooks({
  resolve(specifier, context, nextResolve) {
    if (specifier === 'virtual:hello') {
      return { url: 'data:text/javascript,export default "hi"', shortCircuit: true };
    }
    return nextResolve(specifier, context);
  },
});

const m = await import('virtual:hello');
console.log(m.default); // hi
```

フックが同期になるため、`resolve`や`load`の中で`await`していたローダーは書き直しが要ります。ESMのモジュール解決の仕組みそのものは[Native ESMの基本仕組みとCommonJSとの根本的な違いの整理](/tech/details/12462/)を参照してください。

## 26.1.0〜26.11.0で追加された機能

Currentの期間中はマイナーリリースで機能が足されます。26.0.0の発表時点の記事には載っていない追加を、リリースノートの日付順に抜き出しました（セキュリティリリース以外の主なもの）。

| 版       | 日付         | 主な追加                                |
| ------- | ---------- | ----------------------------------- |
| 26.1.0  | 2026-05-07 | node:ffi（実験的）、crypto.randomUUIDv7() |
| 26.2.0  | 2026-05-20 | fs.StatsにTemporal.Instant、1xx送信     |
| 26.3.0  | 2026-06-01 | permission.drop()                   |
| 26.4.0  | 2026-06-24 | パッケージマップ、node:vfs（最小実装）             |
| 26.5.0  | 2026-07-08 | `--experimental-import-text`        |
| 26.8.0  | 2026-08-26 | zlibのZIP読み書き、AES-GCM-SIV            |
| 26.9.0  | 2026-09-16 | node:ffiのフラグ撤廃、node:bench           |
| 26.10.0 | 2026-09-22 | util.throttle()／debounce()          |
| 26.11.0 | 2026-10-07 | sqliteのクラス改名、`--process-timeout`    |

`node:ffi`はJavaScriptから共有ライブラリの関数を直接呼ぶモジュールです。26.1.0では`--experimental-ffi`が必要でしたが、26.9.0でフラグ無しで読み込めるようになりました（読み込むと実験的機能の警告が出ます）。パーミッションモデル有効時は`--allow-ffi`が要り、リリースノートは不正なポインタや型の誤りでプロセスがクラッシュしうる「本質的に安全でないAPI」と明記しています。`node:bench`は`--experimental-bench`の指定が必要です。

26.3.0のリリースノートには、AppleがIntel Macのサポートを縮小していることから、Apple SiliconとIntelの両方で動くmacOSユニバーサルバイナリを26のサポート期間の最後まで配布し続けられない可能性がある、という告知も入りました。Intel Macで26を長く使う予定なら、配布形態の変更を追っておく必要があります。

セキュリティリリースは10月14日時点で6月18日の26.3.1と7月29日の26.5.1の2回で、26.5.1ではHTTP/2とパーミッションモデルのHigh 2件を含む10件のCVEが修正されました。26.11.1は26.11.0と同じ10月7日に出た修正版で、中身はドキュメント生成の変更の差し戻しだけです。脆弱性情報の追い方は[Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順](/tech/details/10243/)で解説しています。

### node:sqliteのDatabaseSync→Database改名（26.11.0）

26.11.0で`node:sqlite`の`DatabaseSync`が`Database`に、`StatementSync`が`Statement`に改名されました。旧名は同じクラスを指す別名として残り、非推奨はドキュメント上だけ（DEP0210・DEP0211）なので、旧名のコードも警告なしで動きます。

```
import { Database, DatabaseSync } from 'node:sqlite';

console.log(DatabaseSync === Database); // true

const db = new Database(':memory:');
db.exec('CREATE TABLE t(id INTEGER PRIMARY KEY, name TEXT)');
db.prepare('INSERT INTO t(name) VALUES (?)').run('a');
console.log(db.prepare('SELECT count(*) AS n FROM t').get());
// [Object: null prototype] { n: 1 }
```

注意点は、新しい名前が24系に無いことです。24.21.0で`require('node:sqlite').Database`は`undefined`でした。24と26の両方で動かすライブラリは、24のサポートが続くあいだ旧名の`DatabaseSync`を使い続ける方が安全です。

### –process-timeoutによるCIの終了待ち原因の調査（26.11.0）

`--process-timeout`は、指定した時間が過ぎてもプロセスが終わらないときに終了コード124で終了させ、その時点でイベントループを生かしているリソースを標準エラーに出すオプションです。タイマーやソケットの閉じ忘れでテストが終わらず、CIのジョブがタイムアウトまで止まる場面で、原因の特定に使えます。

```
$ node --process-timeout=1s -e "setInterval(() => {}, 1000)"
(node:66137) Process timed out after 1s (--process-timeout). Exiting with code 124.
Main thread was not executing JavaScript.
Resources keeping the event loop alive:
    Timeout (next due in 941ms)
$ echo $?
124
```

時間は`ms`・`s`・`m`・`h`の単位付きで書きます。単位を省いた`--process-timeout=1`は「invalid value」で起動しません。[公式のCLIドキュメント](https://nodejs.org/api/cli.html#--process-timeoutduration)は安定度を1.1（活発に開発中）としており、`NODE_OPTIONS`には書けず、`--inspect`などデバッガを有効にするオプションとも併用できません。24.21.0では`bad option`になります。

同じ26.11.0では、`process.ref()`と`process.unref()`が安定版になり、文字列に変換したときの長さをデコードせずに返す`Buffer.stringLength()`、ヘッダー名と値を検査する`http.isValidHeaderName()`・`http.isValidHeaderValue()`も加わりました。`Buffer.stringLength()`が受け取るのはBufferやTypedArrayで、文字列を渡すと`ERR_INVALID_ARG_TYPE`になります。文字列のバイト数を測るのは従来どおり`Buffer.byteLength()`です。

## ネイティブアドオンとビルド環境の必須対応

ネイティブアドオンのうち、Node.jsやV8のC++ APIを直接使うものは、ABIの番号NODE\_MODULE\_VERSIONが合わないと読み込めません。Node-API（N-API）だけを使うアドオンは、この番号の変更だけを理由とする再ビルドは原則不要です。ただし、併用する外部ライブラリのABIや実行環境の互換性は別途確認が必要です。26は**147**で、24の137、25の141から変わっています。

- **アドオンの再ビルド**：Node.js固有APIに依存するアドオンは、147向けのプリビルドがある版へ更新するか、`npm rebuild`でソースからビルドし直す。
- **ソースからビルドする環境**：GCCを使う場合は13.2以上が必要で、Python 3.9は非対応、WindowsではWindows 11 SDK、AIX・IBM iではPower 9以上が前提になった。Temporalを有効にしてNode.js本体をビルドする場合は、rustc 1.86以上（LLVM 19以上）とcargo 1.86以上も要る（見つからなければ警告を出してTemporal無しでビルドされる）。
- **Corepackは同梱されない**：Node.jsの配布ドキュメントに「Node.js 25.0.0以降は配布しない」とあり、26.11.1の`bin/`には`node`・`npm`・`npx`しかない。pnpmやYarnをCorepackで管理していた環境は`npm install -g corepack`で別途入れる。

同梱のnpmは26.0.0の11.12.1から26.11.1では11.20.0になっています。Corepackの入れ方と`packageManager`の固定は[corepackでpnpmを管理する方法｜corepack enable・prepareの使い方とNode.js 25の変更](/tech/details/2765/)が詳しいです。

## AWS Lambda・Docker・GitHub ActionsでのNode.js 26の対応状況

### AWS Lambdaのnodejs26.xはパブリックプレビュー

AWSは2026年8月25日の[What’s New](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-lambda-node-js-python-public-preview/)で、Lambdaのマネージドランタイムに「パブリックプレビュー」の段階を設け、その最初としてNode.js 26とPython 3.15を公開しました。ランタイム識別子は`nodejs26.x`で、OSはAmazon Linux 2023です。

- プレビュー中は破壊的な変更が入りうるため、Lambda SLAとAWSのテクニカルサポートの対象外で、本番ワークロードには使わないよう案内されている。
- 一般提供（GA）になっても識別子は`nodejs26.x`のままで、プレビュー中に作った関数はそのままGAへ移る。
- [ランタイムの一覧](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)では、`nodejs26.x`の廃止日は未定、`nodejs24.x`は2028年4月30日に廃止（関数の新規作成は6月1日、更新は7月1日から不可）。

10月14日時点でGAの告知は出ていません。本番のLambdaは`nodejs24.x`のままにして、検証用の関数で`nodejs26.x`を試し、GAの告知を待って切り替えます。Lambdaの仕組みや料金の考え方は[AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](/tech/details/15407/)で扱っています。

### Docker公式イメージとAlpineのサポート区分

Docker Hubの公式イメージ`node`には、`26.11.1-trixie-slim`や`26.11.1-alpine3.23`などのタグが10月8〜9日に公開されています。`node:26`のように系列だけを書くと、パッチ版が出るたびに中身が変わります。

Alpineで使う場合は、26.11.0でx64のmusl環境（musl 1.2.5以上、カーネル6.12以上。例としてAlpine 3.22）がサポート区分のTier 2に上がったことを押さえておきます（26.11.1のBUILDING.md）。同ファイルの定義では、Tier 2もTier 1と同じくテストの失敗がリリースを止める区分ですが、利用者の少ない環境とされ、基盤の問題でバイナリの公開が遅れることがあると書かれています。musl向けのプリビルドを配っていないネイティブアドオンはAlpineではソースからのビルドになるので、アドオンを使うならglibcの`trixie-slim`や`bookworm-slim`を選ぶ方が手間がかかりません。

GitHub Actionsでは`actions/setup-node`の`node-version`に`26`を書けば入ります。入力項目やキャッシュの設定は[actions/setup-nodeとは｜v7の入力・キャッシュ設定とv5以降の既定変更](/tech/details/17919/)にまとめています。

## Node.js 24から26への移行手順

手順は「CIで26を並走 → 警告を例外にして洗い出し → アドオンと外部通信を確認 → 本番切替」の順です。

1. **CIのマトリクスに26を追加する**。本番の24を残したまま、26で同じテストを回します。
2. **非推奨警告をエラーにして走らせる**。`node --throw-deprecation`で起動すると、`DEP0205`などの警告が例外として投げられ、呼び出し元のスタックが残ります。
3. **ネイティブアドオンを更新・再ビルドする**。`node -p process.versions.modules`が147であることを確認し、Node.js固有APIに依存するアドオンは147対応版へ更新するか`npm rebuild`。
4. **外部API・プロキシ経由の通信を結合テストで通す**。`fetch`のHTTP/2化で差が出るのはここです。
5. **`package.json`の`engines`を更新する**。下限は実際に使うAPIとCIで検証した系列に合わせます。Temporalなど26の機能を使うなら`"node": ">=26"`、使わないライブラリなら`"node": ">=22"`のように範囲で書き、26を上限で切らないようにします。

```
# .github/workflows/test.yml
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [22, 24, 26]
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: node --throw-deprecation --test
```

複数の版を手元で切り替える方法は、[Volta（ヴォルタ）とは？Node.jsバージョン管理の使い方とメンテ終了・mise移行](/tech/details/7664/)や[Nodebrewとは？Node.jsのバージョン管理・インストール・切り替えを入門解説](/tech/details/3343/)を参照してください。業務システムでランタイムの更新と合わせて基盤ごと載せ替える場合は、[システムマイグレーション・リプレイス](/service/system/migration/)の支援も行っています。

### 本番を今すぐ26へ上げるべきでないケース

本番サービスをCurrentのうちに26へ上げる理由は、Temporalやfetchの挙動を先に取り込みたい場合を除けば、ほとんどありません。24は2026年10月20日にMaintenance LTSへ移った後も2028年4月30日までセキュリティ修正が出ます。Current期間はマイナー版ごとに機能が増え、26.9.0の`node:ffi`や26.11.0の`node:sqlite`のように、途中でフラグや名前が変わることもあります。本番の切替は10月28日のLTS入り後、少なくとも最初のLTSパッチを待ってからで十分です。Denoからの移行先としてNode.js 26とBunを比べた判断は[Deno・Bun・Node.jsの比較と移行コード](https://www.issoh.co.jp/tech/details/18897/)で扱っています。AWS Lambdaで動かすサービスは、それに加えて`nodejs26.x`のGAを待ちます。

急ぐべきなのは次の2つです。1つは、npmに公開しているライブラリの作者で、利用者が26を使い始める前にCIへ26を入れておく必要があります。もう1つは22系で動かしている本番で、22は2027年4月30日にEOLを迎えます。移行先はサポートが2029年4月30日まで続く26を第一候補とし、依存パッケージやネイティブアドオンが26に未対応なら、2028年4月30日までサポートされる24を選びます。

## よくある質問

### Node.js 26のリリース日はいつですか？

26.0.0は2026年5月5日にCurrentとしてリリースされました。2026年10月14日時点の26系最新リリースは10月7日の26.11.1です。

### Node.js 26はいつLTSになり、いつまでサポートされますか？

2026年10月28日にActive LTSへ移り、2027年10月20日からMaintenance LTS、2029年4月30日にEOLです。コードネームは予定名簿で「Lithium」です。

### 今のNode.jsのLTSはどれですか？

2026年10月14日時点のActive LTSは24.x（Krypton）、Maintenance LTSは22.x（Jod）です。24.xは10月20日にMaintenance LTSへ移り、10月28日に26.xがActive LTSになります。LTSの考え方と`lts/*`の扱いは[Node.js LTSの解説記事](/tech/details/17906/)を参照してください。

### @types/node 26はありますか？

あります。26.0.0は2026年6月19日に公開され、10月14日時点のlatestは26.6.5です。`npm install -D @types/node@26`で入ります。Temporalの型は`@types/node`ではなく、tsconfigの`lib`に`esnext`を指定すると有効になります。

### Node.js 26でCorepackは使えますか？

同梱されていないので、そのままでは`corepack`コマンドはありません。Node.js 25.0.0から配布物に含まれなくなりました。`npm install -g corepack`で入れれば、`corepack enable`などは従来どおり使えます。

## 関連記事

- [Node.js LTSとは？現行版の確認とlts/\*の固定・移行時期を実装目線で解説](/tech/details/17906/)
- [Node.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説](/tech/details/17433/)
- [Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順【2026年10月最新】](/tech/details/10243/)
- [corepackでpnpmを管理する方法｜corepack enable・prepareの使い方とNode.js 25の変更【2026年】](/tech/details/2765/)
- [actions/setup-nodeとは｜v7の入力・キャッシュ設定とv5以降の既定変更](/tech/details/17919/)

---

出典: [Node.js 26の新機能と破壊的変更・LTS移行日｜24からの移行手順【26.11.1対応】](<https://www.issoh.co.jp/tech/details/12014/>)（株式会社一創）