Node.js Moves to One Major Release Per Year, Starting with Node 27（InfoQ） が話題になりました。これまで Node.js は半年ごとにメジャーバージョンを上げていましたが、Node 27 から年 1 回のメジャーリリースへと移行します。リリース頻度が下がることで 各バージョンの寿命とサポート期間が読みやすくなり、長期運用するシステムの バージョン計画が立てやすくなる変更です。
一方で受託開発の現場では、「納品時は最新だった Node.js が、数年後にはサポート切れになり、脆弱性が放置されたまま動き続ける」という事故が後を絶ちません。受託でシステム開発を支える立場では、これは 「最新を追うか」ではなく、「どの LTS を選び、いつ上げ、誰がサポート切れを監視して引き渡すか」を契約に組み込む課題だと捉えています。これまで AWS Lambda Web Adapter によるサーバーレス移行受託（GH Media） で扱った ランタイム移行、Postgres / SQLite の永続ワークフロー受託（GH Media） で扱った バックエンド信頼性、Azure Linux 4 による OS 標準化受託（GH Media） で扱った 基盤の標準化と接続して、本記事では 「ランタイム LTS 戦略・保守」を 受託パッケージとして整理します。
なぜ「いま」Node.js LTS 戦略なのか
| 観点 | 半年ごと（従来） | 年 1 回（Node 27〜） |
|---|---|---|
| メジャー頻度 | 年 2 回 | 年 1 回 |
| 寿命の見通し | 短く読みにくい | 長く読みやすい |
| LTS 計画 | 頻繁な更新判断 | 計画的に更新 |
| サポート期間 | 把握が煩雑 | 管理しやすい |
| 保守負荷 | アップ頻度高い | 計画的に分散 |
| 長期運用 | バージョン迷子になりがち | 戦略を立てやすい |
つまり リリース頻度が安定したことで、受託でも 「どの LTS で作り、いつ次へ上げるかを最初から設計し、サポート切れを監視して保守する」運用が立てやすくなりました。これにより 「サポート切れを放置しない安全な運用」を成果物として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「最新で作る」から「LTS で作る」へ
最新版は寿命が読みにくく本番に不向きな場合があります。受託では アクティブ LTS を基準に選定し、安定性とサポート期間を両立します。
構造 2: 「作って放置」から「サポート切れを監視」へ
EOL を過ぎても気づかず動かし続けるのは重大リスクです。受託では EOL カレンダーで監視し、計画的に更新する運用を提供します。
構造 3: 「行き当たりばったりの更新」から「計画的更新」へ
突然のメジャーアップは事故の元です。受託では 年次サイクルに合わせた更新計画を立て、段階的に検証して上げます。
受託で提供する「ランタイム LTS 戦略・保守」5 フェーズ
フェーズ 1: 現状診断（1 週間）
- 稼働中システムの Node.js バージョン棚卸し
- EOL / サポート状況の確認
- 依存パッケージの互換性確認
- 脆弱性スキャン（npm audit 等）
フェーズ 2: LTS 戦略設計（1 週間）
- 採用 LTS バージョンの決定
- 更新サイクル（年次）の計画
- 互換性リスクの洗い出し
- ロールバック / 検証方針の策定
フェーズ 3: 更新実装（1〜2 週間）
- 対象 LTS へのアップグレード
- 非互換 API / 依存の対応
- テスト・CI での回帰確認
- 段階的なデプロイ
フェーズ 4: 検証・安定化（1 週間）
- 本番相当環境での動作検証
- 性能 / メモリの確認
- 脆弱性の再スキャン
フェーズ 5: 継続保守（継続）
- EOL カレンダーによる監視
- 定期的な依存・セキュリティ更新
- 次期 LTS への計画的移行
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| ランタイム | Node.js アクティブ LTS | Bun / Deno（要件次第） |
| バージョン管理 | Volta / nvm / .nvmrc | asdf |
| 脆弱性監視 | npm audit / Dependabot | Renovate |
| CI | GitHub Actions（複数版検証） | GitLab CI |
| コンテナ | LTS ベースイメージ固定 | distroless |
| 監視 | EOL カレンダー | endoflife.date 参照 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| 長期運用する基幹 / 業務システム | 短命な検証用 |
| セキュリティ要件が厳しい | 外部公開しない実験 |
| 納品後も保守契約がある | 一度きりの納品で終わり |
| 複数システムを横断管理 | 単一の小さなスクリプト |
| EOL 放置のリスクを避けたい | 更新を自社で完結できる |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 採用バージョン | LTS と選定理由 | 寿命の合意 |
| 更新サイクル | 年次更新の方針 | 更新時の体制 |
| EOL 監視 | サポート切れの監視 | 監視範囲 |
| 互換性対応 | 非互換時の扱い | 追加開発の切り分け |
| 引き渡し | 手順 / Runbook | 自社運用の前提 |
| 継続保守 | 脆弱性 / 依存更新 | 運用費用 |
価格モデル — ランタイム LTS 戦略・保守パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| LTS 診断 | 25 万円〜 | 1 システム | 棚卸し + 戦略レポート |
| アップグレード | 80 万円〜 | 中規模 | 更新 + 検証 + 安定化 |
| 複数システム移行 | 200 万円〜 | 複数横断 | + 標準化 + CI 整備 |
| Lite 保守 | 6 万円〜 / 月 | 小規模 | EOL 監視 + 軽微更新 |
| Standard 保守 | 18 万円〜 / 月 | 中規模 | + 定期更新 + 脆弱性対応 |
顧客側 ROI 試算（業務システム / サポート切れ回避想定）
| 項目 | 既存（放置） | LTS 戦略・保守 | 差分 |
|---|---|---|---|
| 脆弱性リスク | サポート切れで露出 | 監視で予防 | 重大インシデント回避 |
| 緊急対応 | EOL 後に慌てて移行 | 計画的に更新 | 緊急工数の削減 |
| 依存の陳腐化 | 更新できず固定化 | 継続更新 | 技術的負債の抑制 |
| 監査対応 | バージョン説明できず | 戦略で説明可能 | コンプライアンス向上 |
| 年間効果 | — | — | 脆弱性インシデント回避 + 緊急移行コストの抑制 |
アップグレード（80 万円〜）でも、サポート切れ放置による 1 件の重大インシデント回避で十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 最新メジャーで本番を作る
寿命が読みにくく不安定です。アクティブ LTS を選ぶべきです。
落とし穴 2: EOL を監視しない
気づかず放置されます。EOL カレンダーで監視します。
落とし穴 3: 依存の互換性を確認しない
更新でアプリが壊れます。事前に互換性検証します。
落とし穴 4: 一気に何メジャーも上げる
リスクが集中します。段階的に更新します。
落とし穴 5: 更新を保守契約に含めない
放置の温床になります。継続保守を契約に明記します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | バージョン棚卸し + EOL 確認 |
| Week 2 | LTS 戦略 + 更新計画策定 |
| Week 3〜4 | アップグレード + 互換性対応 |
| Week 5〜6 | 検証 + 脆弱性再スキャン |
| Week 7〜13 | EOL 監視 + 定期保守運用開始 |
まとめ — 「最新で作って放置」から「LTS を選び保守して引き渡す」へ
Node.js が年 1 回のメジャーリリースに移行したことで、各バージョンの寿命が読みやすくなり、長期運用のバージョン計画が立てやすくなりました。受託でシステム開発を支える立場では、アクティブ LTS で作り、EOL を監視し、計画的に更新し、保守契約とともに引き渡す 「ランタイム LTS 戦略・保守」が、サポート切れを放置しない安全な運用を成果物として届ける新しい主力サービスです。
弊社では LTS 診断 / アップグレード / 複数システム移行 / Lite / Standard の各段階で本パッケージを提供しています。「Node.js がサポート切れのまま動いている」「いつ上げるべきか分からない」「脆弱性を継続的に監視してほしい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
