バージョン16にアップグレードする方法

15から16へのアップグレード

Next.js DevTools MCPでのAIエージェントの使用

MCP（Model Context Protocol）をサポートするAIコーディングアシスタントを使用している場合、**Next.js DevTools MCP** を使用して、アップグレードプロセスと移行タスクを自動化できます。Model Context Protocol (MCP)

セットアップ

MCPクライアントに以下の設定を追加してください。例：

{
  "mcpServers": {
    "next-devtools": {
      "command": "npx",
      "args": ["-y", "next-devtools-mcp@latest"]
    }
  }
}

詳細については、npmのnext-devtools-mcpパッケージを参照して、MCPクライアントで設定してください。

注： next-devtools-mcp@latestを使用すると、MCPクライアントは常に最新バージョンのNext.js DevTools MCPサーバーを使用できます。

プロンプト例

設定が完了したら、自然言語のプロンプトを使用してNext.jsアプリをアップグレードできます。

Next.js 16にアップグレードするには

コーディングエージェントに接続してから、プロンプトを入力してください。

Next Devtools, help me upgrade my Next.js app to version 16

キャッシュコンポーネントへの移行（v16へのアップグレード後）

コーディングエージェントに接続してから、プロンプトを入力してください。

Next Devtools, migrate my Next.js app to cache components

Codemodの使用

Next.jsバージョン16に更新するには、upgrade codemodを使用できます。

npx @next/codemod@canary upgrade latest

このcodemodは以下のことができます。

• next.config.jsを更新して、新しいturbopack設定を使用する
• next lintからESLint CLIへの移行
• 非推奨のmiddleware規約からproxyへの移行
• 安定化されたAPIからunstable_プレフィックスを削除する
• experimental_ppr Route Segment Configをpagesおよびlayoutsから削除する

手動で実行したい場合は、最新のNext.jsおよびReactバージョンをインストールしてください。

npm install next@latest react@latest react-dom@latest

TypeScriptを使用している場合は、@types/reactおよび@types/react-domも最新バージョンにアップグレードしてください。

Node.jsランタイムとブラウザのサポート

デフォルトでTurbopack

Next.js 16以降、Turbopackは安定し、next devおよびnext buildでデフォルトで使用されます。

以前は--turbopackまたは--turboを使用してTurbopackを有効にする必要がありました。

{
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build --turbopack",
    "start": "next start"
  }
}

これは不要になりました。package.jsonスクリプトを更新してください。

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

プロジェクトにカスタムwebpack設定があり、next build（現在はデフォルトでTurbopackを使用）を実行した場合、設定ミスを防ぐためにビルドは**失敗**します。カスタムwebpack設定

これに対処するには、いくつかの方法があります。

• それでもTurbopackを使用する：next build --turbopackで実行し、Turbopackでビルドしてwebpack設定を無視します。
• Turbopackに完全に切り替える：webpack設定をTurbopack互換のオプションに移行します。
• Webpackを使い続ける：--webpackフラグを使用してTurbopackをオプトアウトし、Webpackでビルドします。

知っておくと良いこと：webpack設定が見つかったためにビルドが失敗し、自分で設定していない場合は、プラグインがwebpackオプションを追加している可能性があります。

Turbopackのオプトアウト

Webpackを引き続き使用する必要がある場合は、--webpackフラグでオプトアウトできます。たとえば、開発ではTurbopackを使用し、本番ビルドではWebpackを使用する場合。

{
  "scripts": {
    "dev": "next dev",
    "build": "next build --webpack",
    "start": "next start"
  }
}

開発と本番の両方でTurbopackを使用することを推奨します。Turbopackに切り替えられない場合は、このスレッドにコメントを送信してください。

Turbopackの設定場所

experimental.turbopack設定は実験的ではなくなりました。

import type { NextConfig } from 'next'
 
// Next.js 15 - experimental.turbopack
const nextConfig: NextConfig = {
  experimental: {
    turbopack: {
      // options
    },
  },
}
 
export default nextConfig

トップレベルのturbopackオプションとして使用できます。

import type { NextConfig } from 'next'
 
// Next.js 16 - turbopack at the top level of nextConfig
const nextConfig: NextConfig = {
  turbopack: {
    // options
  },
}
 
export default nextConfig

Turbopack設定のオプションを確認してください。Next.js 16では、さまざまな改善と新しいオプションが導入されています。たとえば：

• 高度なWebpackローダー条件
• debugIds

Resolve alias fallback

一部のプロジェクトでは、クライアントサイドコードがNode.jsネイティブモジュールを含むファイルをインポートする場合があります。これにより、Module not found: Can't resolve 'fs'のようなエラーが発生します。

この場合、クライアントサイドバンドルがこれらのNode.jsネイティブモジュールを参照しないようにコードをリファクタリングする必要があります。

ただし、場合によってはこれが不可能なこともあります。Webpackでは、resolve.fallbackオプションが通常、エラーを**サイレンス**するために使用されていました。Turbopackは同様のオプションを提供しており、turbopack.resolveAliasを使用します。この場合、ブラウザでfsが要求されたときに空のモジュールをロードするようにTurbopackに指示します。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  turbopack: {
    resolveAlias: {
      fs: {
        browser: './empty.ts', // We recommend to fix code imports before using this method
      },
    },
  },
}
 
export default nextConfig

クライアントコードがNode.jsネイティブモジュールを使用するモジュールからインポートしないようにモジュールをリファクタリングすることが推奨されます。

Sassのnode_modulesインポート

Turbopackはnode_modulesからのSassファイルのインポートを完全にサポートしています。Webpackはレガシーチルダ（~）プレフィックスを許可していましたが、Turbopackはこの構文をサポートしていません。

Webpackの場合

@import '~bootstrap/dist/css/bootstrap.min.css';

Turbopackの場合

@import 'bootstrap/dist/css/bootstrap.min.css';

インポートの変更が不可能な場合は、turbopack.resolveAliasを使用できます。たとえば、

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  turbopack: {
    resolveAlias: {
      '~*': '*',
    },
  },
}
 
export default nextConfig

Turbopackファイルシステムキャッシュ（ベータ版）

Turbopackは開発時にファイルシステムキャッシングをサポートするようになり、コンパイラ成果物をディスクに保存することで、再起動時のコンパイル時間を大幅に短縮できるようになりました。

設定でファイルシステムキャッシングを有効にする

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  experimental: {
    turbopackFileSystemCacheForDev: true,
  },
}
 
export default nextConfig

非同期リクエストAPI（破壊的変更）

バージョン15では、非同期リクエストAPIが破壊的変更として導入され、**一時的**な同期互換性が提供されていました。

Next.js 16以降、同期アクセスは完全に削除されました。これらのAPIは非同期でしかアクセスできません。

• cookies
• headers
• draftMode
• layout.js、page.js、route.js、default.js、opengraph-image、twitter-image、icon、およびapple-iconのparams。
• page.jsのsearchParams

非同期Dynamic APIへの移行には、codemodを使用してください。

非同期Dynamic APIの型変換

非同期paramsおよびsearchParamsへの移行を容易にするために、npx next typegenを実行して、これらのグローバルに利用可能な型ヘルパーを自動生成できます。

• PageProps
• LayoutProps
• RouteContext

知っておくと良いこと：typegenはNext.js 15.5で導入されました。

これにより、新しい非同期APIパターンへの型安全な移行が容易になり、コンポーネントを完全な型安全性で更新できるようになります。たとえば、

export default async function Page(props: PageProps<'/blog/[slug]'>) {
  const { slug } = await props.params
  const query = await props.searchParams
  return <h1>Blog Post: {slug}</h1>
}

このアプローチにより、ページ内でprops.params（slugを含む）およびsearchParamsに完全に型安全にアクセスできます。

icon および open-graph Image の非同期パラメータ（破壊的変更）

opengraph-image、twitter-image、icon、およびapple-iconの画像生成関数に渡されるプロップは、Promiseになりました。

以前のバージョンでは、Image（画像生成関数）とgenerateImageMetadataの両方がparamsオブジェクトを受け取っていました。generateImageMetadataから返されたidは、画像生成関数に文字列として渡されました。

// Next.js 15 - synchronous params access
export function generateImageMetadata({ params }) {
  const { slug } = params
  return [{ id: '1' }, { id: '2' }]
}
 
// Next.js 15 - synchronous params and id access
export default function Image({ params, id }) {
  const slug = params.slug
  const imageId = id // string
  // ...
}

Next.js 16以降、非同期リクエストAPIの変更に合わせて、これらも非同期になりました。

// Next.js 16 - asynchronous params access
export async function generateImageMetadata({ params }) {
  const { slug } = await params
  return [{ id: '1' }, { id: '2' }]
}
 
// Next.js 16 - asynchronous params and id access
export default async function Image({ params, id }) {
  const { slug } = await params // params now async
  const imageId = await id // id is now Promise<string> when using generateImageMetadata
  // ...
}

React 19.2

Next.js 16のApp Routerは、最新のReact Canaryリリースを使用しており、新しくリリースされたReact 19.2の機能や、段階的に安定化されているその他の機能が含まれています。主な機能は以下のとおりです。

• View Transitions: Transitionやナビゲーション内で更新される要素をアニメートします。
• useEffectEvent: Effectからリアクティブでないロジックを再利用可能なEffect Event関数に抽出します。
• Activity: UIをdisplay: noneで非表示にしながら、状態を維持しEffectをクリーンアップして「バックグラウンドアクティビティ」をレンダリングします。

詳細はReact 19.2の発表をご覧ください。

React Compiler サポート

React Compiler の組み込みサポートは、React Compiler の1.0リリースに伴い、Next.js 16で安定しました。React Compiler はコンポーネントを自動的にメモ化し、手動のコード変更なしで不要な再レンダリングを削減します。

reactCompiler設定オプションは、experimentalから安定版に昇格しました。さまざまなアプリケーションタイプでのビルドパフォーマンスデータを収集し続けているため、デフォルトでは有効になっていません。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  reactCompiler: true,
}
 
export default nextConfig

最新バージョンのReact Compilerプラグインをインストールする

npm install babel-plugin-react-compiler@latest

知っておくと良いこと：React CompilerはBabelに依存するため、このオプションを有効にすると、開発時およびビルド時のコンパイル時間が長くなることが予想されます。

キャッシングAPI

revalidateTag

revalidateTagに新しい関数シグネチャが追加されました。2番目の引数としてcacheLifeプロファイルを追加できます。

'use server'
 
import { revalidateTag } from 'next/cache'
 
export async function updateArticle(articleId: string) {
  // Mark article data as stale - article readers see stale data while it revalidates
  revalidateTag(`article-${articleId}`, 'max')
}

revalidateTagは、ブログ投稿、製品カタログ、ドキュメントなど、更新にわずかな遅延が許容されるコンテンツに使用してください。ユーザーは、バックグラウンドで新しいデータがロードされている間に、古いコンテンツを受信します。

updateTag

updateTagは、ユーザーが変更を行い、UIがすぐにその変更を表示する（古いデータではなく）**Read-your-writes**セマンティクスを提供する、新しいServer Actions専用APIです。

これは、同じリクエスト内でデータを期限切れにして即座にリフレッシュすることで実現します。

'use server'
 
import { updateTag } from 'next/cache'
 
export async function updateUserProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile)
 
  // Expire cache and refresh immediately - user sees their changes right away
  updateTag(`user-${userId}`)
}

これにより、インタラクティブな機能で変更が即座に反映されることが保証されます。フォーム、ユーザー設定、またはユーザーが変更を即座に表示することを期待するあらゆるワークフローに最適です。

updateTagまたはrevalidateTagの使用時期については、こちらで詳細をご覧ください。

refresh

refreshを使用すると、Server Action内からクライアントルーターをリフレッシュできます。

'use server'
 
import { refresh } from 'next/cache'
 
export async function markNotificationAsRead(notificationId: string) {
  // Update the notification in the database
  await db.notifications.markAsRead(notificationId)
 
  // Refresh the notification count displayed in the header
  refresh()
}

アクションを実行した後にクライアントルーターをリフレッシュする必要がある場合に使用してください。

cacheLife と cacheTag

cacheLifeとcacheTagが安定しました。unstable_プレフィックスは不要になりました。

エイリアスインポートを使用していた場合（例：

import {
  unstable_cacheLife as cacheLife,
  unstable_cacheTag as cacheTag,
} from 'next/cache'

インポートを以下のように更新できます。

import { cacheLife, cacheTag } from 'next/cache'

ルーティングとナビゲーションの強化

Next.js 16では、ルーティングとナビゲーションシステムが完全にオーバーホールされ、ページ遷移がより軽量で高速になりました。これにより、Next.jsがナビゲーションデータをプリフェッチおよびキャッシュする方法が最適化されます。

• レイアウトの重複排除: 共有レイアウトを持つ複数のURLをプリフェッチする場合、レイアウトは一度だけダウンロードされます。
• インクリメンタルプリフェッチ: Next.jsは、ページ全体ではなく、キャッシュされていない部分のみをプリフェッチします。

これらの変更には**コードの変更は不要**で、すべてのアプリのパフォーマンスを向上させるように設計されています。

ただし、リクエスト数は増えるかもしれませんが、総転送サイズは大幅に小さくなります。これはほとんどのアプリケーションにとって正しいトレードオフであると考えています。

リクエスト数の増加が問題を引き起こす場合は、issueまたはdiscussionにフィードバックをお寄せください。

部分プリレンダリング（PPR）

Next.js 16では、実験的な部分プリレンダリング（PPR）フラグと設定オプション（ルートレベルセグメントexperimental_pprを含む）が削除されました。

Next.js 16以降、PPRはcacheComponents設定を使用してオプトインできます。

/** @type {import('next').NextConfig} */
const nextConfig = {
  cacheComponents: true,
}
 
module.exports = nextConfig

Next.js 16のPPRは、Next.js 15のカナリア版とは異なる動作をします。現在PPRを使用している場合は、使用中のNext.js 15カナリア版のままにしてください。Cache Componentsへの移行ガイドは追って公開します。

/** @type {import('next').NextConfig} */
const nextConfig = {
  // If you are using PPR today
  // stay in the current Next.js 15 canary
  experimental: {
    ppr: true,
  },
}
 
module.exports = nextConfig

middlewareからproxyへ

middlewareファイル名は非推奨となり、ネットワーク境界とルーティングの焦点が明確になるようにproxyに改名されました。

edgeランタイムはproxyではサポートされていません。proxyランタイムはnodejsであり、設定できません。edgeランタイムを継続して使用したい場合は、middlewareを使用し続けてください。edgeランタイムに関するさらなる指示については、マイナーリリースで追って公開します。

# Rename your middleware file
mv middleware.ts proxy.ts
# or
mv middleware.js proxy.js

名前付きエクスポートmiddlewareも非推奨です。関数名をproxyに変更してください。

export function proxy(request: Request) {}

デフォルトエクスポートを使用している場合でも、関数名をproxyに変更することを推奨します。

middlewareという名前が含まれていた設定フラグも改名されました。たとえば、skipMiddlewareUrlNormalizeはskipProxyUrlNormalizeになりました。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  skipProxyUrlNormalize: true,
}
 
export default nextConfig

バージョン16のcodemodは、これらのフラグも更新できます。

next/image の変更点

クエリ文字列付きローカル画像（破壊的変更）

クエリ文字列付きのローカル画像ソースは、列挙攻撃を防ぐためにimages.localPatterns.search設定が必須になりました。

import Image from 'next/image'
 
export default function Page() {
  return <Image src="/assets/photo?v=1" alt="Photo" width="100" height="100" />
}

ローカル画像でクエリ文字列を使用する必要がある場合は、パターンを設定に追加してください。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    localPatterns: [
      {
        pathname: '/assets/**',
        search: '?v=1',
      },
    ],
  },
}
 
export default nextConfig

minimumCacheTTLのデフォルト値（破壊的変更）

images.minimumCacheTTLのデフォルト値が60秒から4時間（14400秒）に変更されました。これにより、キャッシュ制御ヘッダーがない画像の再検証コストが削減されます。

一部のNext.jsユーザーでは、ソース画像のアップストリームがcache-controlヘッダーを欠落していたため、画像再検証が頻繁に（通常60秒ごと）発生し、CPU使用率とコストが増加していました。

ほとんどの画像は頻繁には変更されないため、この短い間隔は理想的ではありません。デフォルト値を4時間に設定することで、デフォルトでより耐久性のあるキャッシュが提供され、必要に応じて1日に数回まで画像を更新できます。

以前の動作が必要な場合は、minimumCacheTTLをより低い値（たとえば、60秒）に変更してください。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    minimumCacheTTL: 60,
  },
}
 
export default nextConfig

imageSizesのデフォルト値（破壊的変更）

デフォルトのimages.imageSizes配列から値16が削除されました。

リクエスト分析を行った結果、16ピクセル幅の画像を配信するプロジェクトは非常に少ないことがわかりました。この設定を削除すると、next/imageによってブラウザに送信されるsrcset属性のサイズが削減されます。

16pxの画像をサポートする必要がある場合

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
  },
}
 
export default nextConfig

開発者の使用頻度が低いことの他に、devicePixelRatio: 2は実際には32pxの画像をフェッチしてRetinaディスプレイでのぼやけを防ぐため、16ピクセル幅の画像は一般的ではなくなったと考えています。

qualitiesのデフォルト値（破壊的変更）

images.qualitiesのデフォルト値が、すべての品質を許可する状態から[75]のみに設定されるように変更されました。

複数の品質レベルをサポートする必要がある場合

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    qualities: [50, 75, 100],
  },
}
 
export default nextConfig

image.qualities配列に含まれていないqualityプロップを指定した場合、品質はimages.qualities内の最も近い値に丸められます。たとえば、上記の構成では、qualityプロップが80の場合、75に丸められます。

ローカルIP制限（破壊的変更）

新しいセキュリティ制限により、ローカルIP最適化がデフォルトでブロックされます。プライベートネットワークでのみimages.dangerouslyAllowLocalIPをtrueに設定してください。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    dangerouslyAllowLocalIP: true, // Only for private networks
  },
}
 
export default nextConfig

最大リダイレクト数（破壊的変更）

images.maximumRedirectsのデフォルト値が無制限から最大3リダイレクトに変更されました。

import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    maximumRedirects: 0, // Disable redirects
    // or
    maximumRedirects: 5, // Increase for edge cases
  },
}
 
export default nextConfig

next/legacy/image コンポーネント（非推奨）

next/legacy/imageコンポーネントは非推奨になりました。代わりにnext/imageを使用してください。

// Before
import Image from 'next/legacy/image'
 
// After
import Image from 'next/image'

images.domains 設定（非推奨）

images.domains設定は非推奨です。

// image.domains is deprecated
module.exports = {
  images: {
    domains: ['example.com'],
  },
}

セキュリティ向上 quadratischimages.remotePatternsを使用してください。

// Use image.remotePatterns instead
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'example.com',
      },
    ],
  },
}

concurrent dev および build

next devとnext buildは別々の出力ディレクトリを使用するようになり、並列実行が可能になりました。next devコマンドは.next/devに出力します。これはisolatedDevBuildによって制御される新しいデフォルトの動作です。

さらに、ロックファイルメカニズムにより、同じプロジェクトで複数のnext devまたはnext buildインスタンスが実行されるのを防ぎます。

開発サーバーは.next/devに出力するため、Turbopack tracing コマンドは次のようになります。

npx next internal trace .next/dev/trace-turbopack

Parallel Routesのdefault.js要件

すべてのparallel routeスロットには、明示的なdefault.jsファイルが必要になりました。それがないとビルドが失敗します。

以前の動作を維持するには、notFound()を呼び出すかnullを返すdefault.jsファイルを作成してください。

import { notFound } from 'next/navigation'
 
export default function Default() {
  notFound()
}

またはnullを返す

export default function Default() {
  return null
}

ESLint Flat Config

@next/eslint-plugin-nextはデフォルトでESLint Flat Config形式になり、ESLint v10（レガシー設定サポートを削除）と互換性があります。

@next/eslint-plugin-nextプラグインのAPIリファレンスを確認してください。

レガシー.eslintrc形式を使用している場合は、flat config形式への移行を検討してください。詳細はESLint移行ガイドを参照してください。

スクロール動作のオーバーライド

以前のNext.jsバージョンでは、CSSで<html>要素にグローバルにscroll-behavior: smoothを設定していた場合、Next.jsはSPAルート遷移中にこれを次のようにオーバーライドしていました。

1. 一時的にscroll-behaviorをautoに設定する
2. ナビゲーションを実行する（すぐにトップにスクロールされる）
3. 元のscroll-behavior値を復元する

これにより、ページ内ナビゲーションでスムーズスクロールが有効になっている場合でも、ページナビゲーションが常に迅速かつ即座に感じられました。ただし、この操作は、特に各ナビゲーションの開始時にコストがかかる可能性がありました。

Next.js 16では、この動作が変更されました。デフォルトでは、Next.jsはナビゲーション中のscroll-behavior設定をオーバーライドしなくなりました。

Next.jsにこのオーバーライドを実行させたい場合（以前のデフォルト動作）、<html>要素にdata-scroll-behavior="smooth"属性を追加してください。

export default function RootLayout({ children }) {
  return (
    <html lang="en" data-scroll-behavior="smooth">
      <body>{children}</body>
    </html>
  )
}

パフォーマンスの改善

next devおよびnext startコマンドのパフォーマンスが大幅に最適化され、フォーマットがより明確になり、エラーメッセージが改善され、パフォーマンスメトリクスが向上したターミナル出力も改善されました。

Next.js 16では、next build出力からsizeおよびFirst Load JSメトリクスが削除されました。これらのメトリクスは、React Server Componentsを使用したサーバー駆動型アーキテクチャでは不正確であることが判明しました。TurbopackとWebpackの実装の両方に問題があり、クライアントコンポーネントペイロードの計上方法について一致しませんでした。

実際のルートパフォーマンスを測定する最も効果的な方法は、Core Web Vitalsとダウンロードされたリソースサイズに焦点を当てたChrome LighthouseまたはVercel Analyticsのようなツールを使用することです。

next dev config load

以前のバージョンでは、Next configファイルは開発中に2回ロードされていました。

• next devコマンドを実行する際
• next devコマンドがNext.jsサーバーを起動する際

これは非効率的でした。なぜならnext devコマンドはNext.jsサーバーの起動にconfigファイルは必要なかったからです。

この変更の結果、next devを実行する際に、Next.js configファイルでprocess.argvに'dev'が含まれているかどうかのチェックはfalseを返します。

知っておくと良いこと：typegenおよびbuildコマンドは、process.argvで引き続き表示されます。

これは、next devで副作用を引き起こすプラグインにとって特に重要です。その場合、NODE_ENVがdevelopmentに設定されているかを確認するだけで十分な場合があります。

import { startServer } from 'docs-lib/dev-server'
 
const isDev = process.env.NODE_ENV === 'development'
 
if (isDev) {
  startServer()
}
 
const nextConfig = {
  /* Your config options */
}
 
module.exports = nextConfig

または、設定がロードされるphaseを使用します。

Build Adapters API（アルファ版）

Build Adapters RFCに続き、Build Adapters APIの最初のアルファ版が利用可能になりました。

Build Adaptersを使用すると、ビルドプロセスにフックするカスタムアダプターを作成でき、デプロイメントプラットフォームやカスタムビルド統合がNext.js設定を変更したり、ビルド出力を処理したりできるようになります。

const nextConfig = {
  experimental: {
    adapterPath: require.resolve('./my-adapter.js'),
  },
}
 
module.exports = nextConfig

RFCディスカッションでフィードバックをお寄せください。

モダンSass API

sass-loaderはv16に更新され、モダンSass構文と新機能がサポートされています。

削除された機能

以前非推奨となり、今回削除された機能は以下の通りです。

AMPサポート

AMPの導入は大幅に減少し、この機能の維持はフレームワークに複雑さを加えています。すべてのAMP APIと設定が削除されました。

• Next configファイルからのamp設定
• next/ampフックのインポートと使用（useAmp）

// Removed
import { useAmp } from 'next/amp'
 
// Removed
export const config = { amp: true }

• pagesからのexport const config = { amp: true }

const nextConfig = {
  // Removed
  amp: {
    canonicalBase: 'https://example.com',
  },
}
 
export default nextConfig

AMPがユースケースにまだ必要かどうかを評価してください。ほとんどのパフォーマンス上の利点は、Next.jsの組み込み最適化と最新のWeb標準によって達成できます。

next lint コマンド

next lintコマンドは削除されました。BiomeまたはESLintを直接使用してください。next buildはもはやlintを実行しません。

移行を自動化するcodemodが利用可能です。

npx @next/codemod@canary next-lint-to-eslint-cli .

Next.js設定ファイル内のeslintオプションも削除されました。

/** @type {import('next').NextConfig} */
const nextConfig = {
  // No longer supported
  // eslint: {},
}
 
export default nextConfig

ランタイム設定

serverRuntimeConfigとpublicRuntimeConfigは削除されました。代わりに環境変数を使用してください。

以前（Next.js 15）

module.exports = {
  serverRuntimeConfig: {
    dbUrl: process.env.DATABASE_URL,
  },
  publicRuntimeConfig: {
    apiUrl: '/api',
  },
}

import getConfig from 'next/config'
 
export default function Page() {
  const { publicRuntimeConfig } = getConfig()
  return <p>API URL: {publicRuntimeConfig.apiUrl}</p>
}

以降（Next.js 16）

サーバー専用の値は、Server Componentsで直接環境変数にアクセスしてください。

async function fetchData() {
  const dbUrl = process.env.DATABASE_URL
  // Use for server-side operations only
  return await db.query(dbUrl, 'SELECT * FROM users')
}
 
export default async function Page() {
  const data = await fetchData()
  return <div>{/* render data */}</div>
}

知っておくと良いこと：機密性の高いサーバー値を誤ってClient Componentsに渡すのを防ぐには、taint APIを使用してください。

クライアントでアクセス可能な値は、NEXT_PUBLIC_プレフィックスを使用してください。

NEXT_PUBLIC_API_URL="/api"

'use client'
 
export default function ClientComponent() {
  const apiUrl = process.env.NEXT_PUBLIC_API_URL
  return <p>API URL: {apiUrl}</p>
}

環境変数がビルド時にバンドルされずにランタイムで読み込まれるようにするには、process.envから読み取る前にconnection()関数を使用してください。

import { connection } from 'next/server'
 
export default async function Page() {
  await connection()
  const config = process.env.RUNTIME_CONFIG
  return <p>{config}</p>
}

環境変数については、こちらで詳細をご覧ください。

devIndicators オプション

以下のオプションがdevIndicatorsから削除されました。

• appIsrStatus
• buildActivity
• buildActivityPosition

インジケーター自体は引き続き利用可能です。

experimental.dynamicIO

experimental.dynamicIOフラグはcacheComponentsに改名されました。

Next configファイルでdynamicIOフラグを削除して更新してください。

// Next.js 15 - experimental.dynamicIO is now removed
module.exports = {
  experimental: {
    dynamicIO: true,
  },
}

cacheComponentsフラグをtrueに設定して追加してください。

// Next.js 16 - use cacheComponents instead
module.exports = {
  cacheComponents: true,
}

unstable_rootParams

unstable_rootParams関数は削除されました。今後のマイナーリリースで提供する代替APIに取り組んでいます。