Next.js 15のサポート期限は2026年10月21日｜EOLで何が起きるか・16への移行で決めること

「うちのシステム、Next.jsの何番で動いているか分かりますか」——この質問に即答できない場合、2026年10月21日という日付を一度確認しておく価値があります。Next.js 15系のサポートが、この日で終わる見込みです。

サポート終了（EOL）は「動かなくなる日」ではありません。動きはします。変わるのは、新しい脆弱性が見つかっても公式の修正パッチが出なくなるという一点です。そしてこれは想像上のリスクではありません。現に2026年9月22日、Next.jsに深刻度「Critical」（CVSS 9.5）のリモートコード実行の脆弱性が公表され、緊急パッチが出たばかりです。

本記事では、保守・発注を判断する立場の方に向けて、①自社のバージョンをどう確認するか、②EOLまでに何を決めるべきか、③移行の実作業は何にどれだけかかるのかを整理します。

先に結論を3つにまとめます。

• Next.js 15.xのMaintenance LTSは2026年10月21日で終了する見込み（公式は「初回リリースから2年」と定めており、15.xのリリース日2024年10月21日から算出した日付。公式ページに期日そのものの記載はない）。16.xがActive LTSで、14.x以前はすでにサポート外
• 期限に間に合わなくてもシステムは止まらない。ただし「パッチが出ない状態で運用している」という事実は、経営判断として把握しておく必要がある
• 移行コストの大半はバージョン番号を上げる作業ではなく、その後の動作確認。ここを見積もらずに着手すると想定が外れる

Next.jsのサポート期限はどう決まっているのか？

Next.jsはメジャーバージョンごとにLTS（長期サポート）の期間が決まっており、リリースから2年でサポートが終わります。

公式のサポートポリシーでは、フェーズが2つに分かれています。

この2年ルールを現在のバージョンに当てはめると、次のようになります。なお公式のサポートポリシーはリリース日と「2年」という期間を示しており、終了日そのものは掲載されていません。下表のEOL日はそこから算出した日付です。

（出典：Next.js Support Policy。2026年9月23日確認）

16.xは現時点でActive LTSのため、サポート終了日はまだ確定していません。次のメジャーバージョンが公開された時点でMaintenance LTSに移行し、そこから「初回リリースから2年」のルールが適用されます。

注意点として、Maintenance LTS期間中の修正は、破壊的変更を含んでいてもマイナーバージョンとして配信されます。 「マイナーアップデートだから安全」という前提が成り立たないため、15系に留まる場合もパッチ適用時の動作確認は必要です。

EOLを過ぎると、具体的に何が起きるのか？

システムは今日と同じように動き続けます。変わるのは、新しく見つかった脆弱性が修正されないまま残る点です。

この違いが実務でどう効くかは、直近の事例が分かりやすいので挙げます。

2026年9月22日、Next.jsは緊急のセキュリティリリースを公開しました。内容は next/og の画像生成機能（ImageResponse）におけるリモートコード実行の脆弱性です。

• 識別子：GHSA-vcvr-r3jv-pc5j / CVE-2026-94545
• 深刻度：Critical（CVSS 9.5）
• 影響範囲：Next.js 16.2.0以上 16.3.6未満
• 修正版：16.3.6（15系には関連する堅牢化のみが 15.5.26 で提供。15.xはこのRCEの影響を受けない）
• 原因：SVG生成に使っている上流ライブラリ（Satori）のエスケープ処理の不備
• 条件：画像生成のSVGの内容・属性・スタイルに、攻撃者が操作できる値を渡している場合に成立する
• 回避策：アップグレードできるまでの間、next/og のNode.js実装に信頼できない入力を渡さない。Edge実装を使っている場合は影響を受けない

（出典：Next.js公式のセキュリティ告知）

この事例が示しているのは、サポート対象のバージョンにいたからこそ、公表と同時に修正版を適用できたということです。EOLを過ぎたバージョンで同種の問題が出た場合、選択肢は「自力でパッチを当てる」「有償の延長サポートを買う」「該当機能を止める」のいずれかになり、どれも当日に判断できるものではありません。

なお、この脆弱性は「Next.jsを使っていれば全員が危険」という性質のものではない点も押さえてください。成立条件はnext/ogのNode.js実装にユーザー由来の値を渡していることです。OG画像を静的に生成している、そもそもnext/ogを使っていない、Edge実装で動かしている、といった構成であれば、このCVEについては直接の影響はありません。まず「使っているか」を確認し、その上でバージョンを上げる、という順番が現実的です。

自社のバージョンはどう確認すればいいのか？

開発会社に聞くのが一番早いですが、手元でも確認できます。

社内に開発環境がある場合は、プロジェクトのフォルダで次のコマンドを実行します。

# インストールされている実際のバージョンを表示する
npx next --version

ソースコードだけ手元にある場合は、package.json というファイルを開き、"next" の行を探してください。

{
  "dependencies": {
    "next": "^16.3.3"
  }
}

ここで注意したいのが、package.json の表記と実際に動いているバージョンは一致しないことがある点です。^16.3.3 は「16.3.3以上、17未満」という範囲指定で、実際にインストールされるのはその時点の最新版になります。逆に言えば、この表記のままでも、依存関係を再インストールした環境では16.3.6が入っている可能性があります。

正確に知りたい場合は、範囲指定ではなく実際の値を確認します。

# 実際に入っているバージョンを確認する
npm ls next

開発会社に確認を依頼する場合は、「Next.jsのバージョンを教えてください」だけだとpackage.jsonの表記が返ってくることがあります。「本番環境で実際に動いているNext.jsのバージョン」 と伝えると認識がずれにくくなります。

移行の判断：いま15系なら、何を決めるべきか？

残り約1ヶ月で移行を完了させることにこだわるより、現状把握と計画の合意を先に済ませるほうが実務的です。

判断の材料として、状況別に整理します。

「間に合わない場合の暫定策」とは、たとえば次のようなものです。移行そのものを急がせる代わりに、EOL後に脆弱性が出た場合の対応方針を先に決めておく、という考え方です。

• 脆弱性情報の監視担当を決めておく（誰が気づくのかを明確にする）
• 該当した場合に一時的に止められる機能を洗い出しておく
• 外部公開している範囲を減らせないか検討する（社内からのみアクセス可能にする等）

EOLを「絶対に間に合わせなければならない締切」と捉えて無理な短期移行を行うと、検証不足のまま本番に反映してしまうリスクのほうが大きくなります。 期限は判断のきっかけであって、品質を落としてよい理由にはなりません。

15から16への移行では、何にコストがかかるのか？

バージョンを上げるコマンド自体は数分で終わります。コストの大半は、その後の動作確認です。

Next.jsには移行を補助する自動変換ツール（codemod）が用意されています。

# 公式の移行支援ツール。変更が必要な箇所を自動で書き換える
npx @next/codemod@latest upgrade latest

ただし、これで全部が終わるわけではありません。実際に工数がかかるのは次の領域です。

• React 19への追従：Next.js 16はReact 19系を前提とします。UIライブラリがReact 19に対応していない場合、その差し替えや代替検討が必要になります
• Pages RouterからApp Routerへの移行：これは15→16の必須要件ではありませんが、古い構成のまま残している場合、このタイミングで判断を求められることがあります。規模によっては移行本体より大きな工数になります
• 全画面の動作確認：自動テストが整備されていない場合、ここが最大の工数です。画面数と業務パターンの数に比例します
• 外部連携の再確認：決済・認証・外部APIとの連携部分は、フレームワーク更新の影響を受けることがあり、個別の確認が必要です

つまり 見積もりの精度を左右するのは「テストがどれだけ自動化されているか」 です。自動テストがある環境では移行後の確認が短時間で済み、ない環境では人手で全画面を触ることになります。AI駆動開発でテストを書く現実的な範囲については、中小企業のNext.jsフルスクラッチで、テストをどこまで書くかで整理しています。

バージョンアップ対応を保守契約の中でどう扱うか（月額に含めるのか、都度見積もりなのか）は、契約形態によって変わります。確認すべき項目はNext.js保守運用の費用と契約にまとめました。

脆弱性が公表されたとき、誰が動くのか？

バージョン管理を継続的に回すには、「気づく人」と「判断する人」を事前に決めておく必要があります。

EOL対応は一度きりのイベントですが、セキュリティパッチへの追従は毎回発生します。2026年だけでも、Next.jsは5月・7月・8月・9月にセキュリティリリースを行っています。

必要な役割は3つです。

1. 検知：脆弱性情報が公開されたことに気づく。GitHubのセキュリティアラートや公式ブログの購読で自動化できます
2. 影響判定：自社の構成が該当するかを判断する。前述のCVEのように「特定の機能を特定の方法で使っている場合のみ」という条件付きのものが多く、ここに技術的な判断が要ります
3. 適用：検証環境で確認してから本番に反映する

このうち2と3は技術的な判断を伴うため、社内に担当がいない場合は保守の委託範囲に含まれているかを確認しておくべき項目です。検知・判定・適用の分担をどう決めるかは、Next.jsのCVE対応は誰がやるのかで実際のパッチ事例に沿って整理しています。

まとめ

• Next.js 15.xのサポートは2026年10月21日で終了。16.xがActive LTS、14.x以前はサポート外（出典：公式サポートポリシー、2026年9月23日確認）
• EOLはシステムが止まる日ではなく、新しい脆弱性が修正されなくなる日。2026年9月22日公表のCritical RCE（CVE-2026-94545、CVSS 9.5）のような事例に、公式パッチで対応できなくなる
• 確認は npx next --version または npm ls next。package.json の ^ 付き表記は実際のバージョンと一致しないことがある
• 移行コストの中心はバージョン変更ではなく移行後の動作確認。自動テストの有無で見積もりが大きく変わる
• 期限に間に合わない場合も、無理な短期移行より現状把握と暫定策の合意を優先する

私たちは、Next.jsのバージョン移行とその後の保守運用を、現状調査から移行計画・実装・検証まで一貫してお手伝いしています。「今のバージョンが分からない」「移行にどれくらいかかるのか知りたい」という段階からのご相談を歓迎します。Next.jsの調査・保守について、15分のカジュアルな相談も受け付けています（要件が固まっていなくても大丈夫です／営業はしません）。

※本記事に記載したバージョン・サポート期限・脆弱性情報は、2026年9月23日時点の公開情報（Next.js Support Policy・2026年9月22日のセキュリティ告知）に基づく整理です。サポート方針や脆弱性の状況は変わることがあるため、実際の判断にあたっては必ず公式情報で最新の内容をご確認ください。