Next.js 16.4と10月のセキュリティ更新──今月やるべきアップデート判断

2026年10月のNext.jsは、機能リリースとセキュリティ更新が同じ週に重なりました。10月6日にNext.js 16.4が公開され、Cache Componentsが「すべてのアプリで推奨」に変わっています。その8日後の10月14日には、Critical 2件を含むアウトオブバンドのセキュリティ更新（16.4.1 / 15.5.28）が配信されました。

機能を追うか、穴を塞ぐか。順番を間違えると、移行作業の途中で脆弱性を抱えたまま公開し続けることになります。この記事では、16.4で何が変わったのか、どの脆弱性がどの構成に当たるのか、今月のアップデートをどう順序立てるかを整理します。

30秒でわかる結論

• Next.js 16.4（2026年10月6日）でCache Componentsが全アプリ推奨になった。新規作成は既定で有効。
• 2026年10月14日に16.4.1 / 15.5.28の緊急更新。Critical 2件（リモートコード実行）を含む。最新パッチは10月15日公開の16.4.2。
• 該当条件は「App Router + Cache Componentsでuse cacheが複数のtyped arrayを返す」および「Image Optimization APIでSVGを扱う」。
• まず16.4.1へ上げる。Cache Componentsへの移行は、その後で計測しながら進める。
• next upgrade --agentとexperimental.agentUpgradeで、更新の見落としを仕組み化できる。

何が起きたのか：16.4と緊急更新

Next.js 16.4は、Cache Componentsを「すべてのNext.jsアプリにとって最良の選択」と位置づけたリリースです。同社の発表によると、create-next-appで作る新規アプリはCache Componentsが既定で有効になります。Next.js 17では既定になる予定で、16.4はその助走にあたります。

あわせてTurbopackのディスクキャッシュ削減、本番バンドルの縮小、React 19.3の同梱など、設定なしで効く改善も入っています。さらにnext upgrade --agentとexperimental.agentUpgradeという、コーディングエージェント前提の更新支援が追加されました。

セキュリティ面では、10月8日に「上流依存の遅延で9月から先送りしていた修正を含む、アウトオブバンド更新を出す」と予告され、10月14日に16.4.1と15.5.28が公開されました。Active LTSとMaintenance LTSの両方に修正が入っています。

何が変わるのか：16.3までとの比較

注目したいのはensureStaticです。「このページは必ず静的である」と宣言でき、動的コンテンツが紛れ込むとビルドが失敗します。ブログやマーケティングサイトのように「意図せずリクエスト時レンダリングになってコストが増える」ことを避けたい構成では、効果が分かりやすい機能です。

使い方・最小実装

まずセキュリティ修正を取り込みます。16.4系は16.4.1、15.5系は15.5.28が修正版です。

pnpm add next@16.4.1
pnpm run type-check
pnpm run build

次に、静的に保ちたいルートへensureStaticを置きます。レイアウトに書けば配下へまとめて適用され、動的コンテンツが必要なページだけ子のレイアウトで緩める、という運用ができます。

// app/layout.tsx
export const ensureStatic = "navigation";

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return <html lang="ja"><body>{children}</body></html>;
}

値は"shell"、"prefetch"、"navigation"の3種類で、"navigation"が最も厳しい指定です。ビルドが落ちる場所がそのまま「動的になっていた箇所」なので、CIで検出できます。

エージェントに更新を任せる場合は、通知ポリシーを設定しておきます。既定は"security"で、インストール済みバージョンに影響する脆弱性修正だけを通知します。

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  experimental: {
    agentUpgrade: "security",
  },
};

export default nextConfig;

"latest"にするとメジャー・マイナー更新も通知対象になります。まずは"security"で運用し、Cache Componentsへの移行が落ち着いてから広げると、通知に振り回されません。

セキュリティ更新の中身

10月14日の更新に含まれるのは3件です。いずれも公式アドバイザリで条件が明示されています。

1件目は「該当する関数がなければ安全」とは言い切れない点が厄介です。公式も、似た構成がなくても直ちに更新するよう案内しています。2件目はSVGを画像最適化に通していない場合でも、依存関係として古いsharpが残っていないか確認したいところです。3件目はPages RouterやServer Actions未使用なら対象外ですが、App Routerのアプリは一度確認が必要です。

15系を使っている場合は？→ 15.5.28が修正版です。16.4.1へ上げる前提がなくても、まずLTSの修正版を当ててください。

実務への影響

このブログ自身もNext.js 16のApp Routerで動いており、記事公開時点のパッケージは16.2.4でした。公開後に16.4.2へ更新し、実際の作業内容と結果は末尾の「追記」にまとめています。16.4.1は「機能追加」ではなく「今月入れるべき修正」として扱う対象です。ビルドと型チェックが通ることを確認してからデプロイする、という通常の手順で問題ありません。

影響を分けて考えると、次の3層になります。

• セキュリティ: 全アプリ。16.4.1 / 15.5.28へ上げる。判断の余地はない。
• 安定性・速度: Turbopackのキャッシュ削減やバンドル縮小。設定変更なしで恩恵がある。
• 設計: Cache Componentsへの移行。暗黙キャッシュを前提にしたコードの見直しが必要で、計画的に進める。

順序を誤ると、移行の検証中に脆弱性を残すことになります。セキュリティ更新を先に当て、その上で設計変更を進めるのが安全です。

注意点

• Cache Componentsは移行コストを伴う。16.4で推奨になったとはいえ、既存アプリはcacheComponents: trueとpartialPrefetching: trueを有効にした時点でレンダリングの前提が変わります。まず計測できるページから。
• ensureStaticはビルドを失敗させる。意図した失敗なら良いですが、CIが赤くなることをチームに共有してから導入する。
• experimentalフラグは本番投入しない。turbopackGc、遅延dynamic import、worker threadsなどは実験扱いです。worker threadsはNode.js 24.13.1以降で既知の不具合により子プロセスへフォールバックします。
• React 19.3の追随。16.4はReact 19.3を同梱します。View Transitionsやbrowser() APIなど、アプリ側の前提を確認する。
• sharpのバージョン確認。修正版へ上げても、ロックファイルが古いsharpを固定している場合は確認する。

セキュリティ更新と機能更新は、別のPR・別のデプロイに分けると切り分けが容易です。16.4.1へ上げるPRではnextのバージョンだけを変え、Cache Componentsの設定は次のPRに回します。

対応状況と使う判断

自分なら使うか：今すぐ使う。 ただし対象はセキュリティ更新とagentUpgradeの設定までです。Cache Componentsは、静的にできるページと動的にすべきページを洗い出してから、ensureStaticとセットで段階的に導入します。

追記：実際に16.4.2へ更新した結果

この記事の公開後、このブログを16.4.2へ更新しました。16.4.2は2026年10月15日公開の最新パッチで、10月14日の16.4.1に含まれるセキュリティ修正をすべて取り込んでいます。したがって適用先はnext@16.4.2が最短です。

pnpm add next@16.4.2 react@19.3.1 react-dom@19.3.1
pnpm add -D eslint-config-next@16.4.2
pnpm run lint
pnpm run type-check
pnpm run test
pnpm run build

Reactは16.4が同梱する19.3系に揃え、eslint-config-nextも同じバージョンへ上げます。ここまでは機械的な作業ですが、実際には2箇所で手当てが必要でした。

• experimental.viewTransitionが型から消えていた。next.config.tsに残っていると型チェックが落ちます。React 19.3でView Transitionsがstableになったため設定自体が不要になり、layout.tsxの<ViewTransition>はそのまま動作しました。
• lintの新ルールで警告が出た。@next/next/no-location-assign-relative-destinationが追加され、window.location.hrefでの内部遷移が指摘されます。useRouter().push()に置き換えると解消し、クライアント遷移になる分だけ挙動も良くなります。

所要時間は、依存関係の更新より「どこで型エラーとlint警告が出るか」の確認に寄りました。裏を返せば、tscとESLintが移行漏れを検出してくれるということです。CIが通れば、少なくとも設定レベルの破壊的変更は拾えています。

設定フラグの削除エラーは「機能が壊れた」ではなく「stableになって設定が不要になった」合図のことがあります。まずリリースノートで該当フラグの扱いを確認し、次にフラグを外して型チェックを通す順で切り分けると迷いません。

Cache Componentsも同時に有効にした？→ していません。セキュリティ更新と設計変更を同じデプロイに混ぜると、問題が出たときに原因を切り分けられません。移行は別ブランチで、ensureStaticとセットにして段階的に進める方針です。

まとめ

• 16.4（10月6日）でCache Componentsが全アプリ推奨になり、新規作成は既定で有効になった。
• 10月14日に16.4.1 / 15.5.28の緊急更新。Critical 2件を含むため優先度は最上位。
• 該当条件はuse cacheの戻り値と、SVGの画像最適化。公式アドバイザリで確認する。
• セキュリティ更新を先に当て、Cache Componentsへの移行は別PRで進める。
• agentUpgradeを"security"で有効にし、更新の見落としを仕組み化する。
• 実際の更新では、フラグ削除とlint警告の2箇所を直すだけで16.4.2へ移行できた。

参考リンク

• Next.js 16.4
• Next.js Security Update for Upstream Vulnerabilities
• Upcoming Next.js Security Update for Upstream Vulnerabilities
• GHSA-673q-mjm6-r5xr
• CVE-2026-96889