Menu

バージョン16へのアップグレード方法

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

Next.js DevTools MCPでAIエージェントを使用する

Model Context Protocol（MCP）をサポートするAIコーディングアシスタントを使用している場合、Next.js DevTools 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

詳細については、こちらのドキュメントをご覧ください。

コードモッドを使用する

Next.jsバージョン16にアップグレードするには、upgradeコードモッドを使用できます：

Terminal
npx @next/codemod@canary upgrade latest

コードモッドは以下のことができます：

  • next.config.jsを新しいturbopack設定を使用するように更新する
  • next lintから ESLint CLIへ移行する
  • 非推奨のmiddleware規約からproxyへ移行する
  • 安定化されたAPIからunstable_プレフィックスを削除する
  • ページとレイアウトからexperimental_pprルートセグメント設定を削除する

手動で行う場合は、最新のNext.jsおよびReactバージョンをインストールします：

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

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

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

要件変更・詳細
Node.js 20.9+最小バージョンが20.9.0（LTS）になりました。Node.js 18はサポートされなくなりました
TypeScript 5+最小バージョンが5.1.0になりました
ブラウザChrome 111+、Edge 111+、Firefox 111+、Safari 16.4+

デフォルトでTurbopack

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

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

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

これは不要になりました。package.jsonスクリプトを更新できます：

package.json
{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

プロジェクトにカスタムwebpack設定がある場合、next buildを実行すると（デフォルトでTurbopackが使用されます）、ビルドは失敗し、設定の誤りを防ぎます。

これに対応するにはいくつかの方法があります：

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

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

Turbopackをオプトアウトする

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

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

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

Turbopack設定の場所

experimental.turbopack設定は実験的段階を卒業しました。

next.config.ts
import type { NextConfig } from 'next'
 
// Next.js 15 - experimental.turbopack
const nextConfig: NextConfig = {
  experimental: {
    turbopack: {
      // オプション
    },
  },
}
 
export default nextConfig

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

next.config.ts
import type { NextConfig } from 'next'
 
// Next.js 16 - nextConfigのトップレベルのturbopack
const nextConfig: NextConfig = {
  turbopack: {
    // オプション
  },
}
 
export default nextConfig

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

Resolveエイリアスフォールバック

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

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

ただし、場合によってはこれが不可能な場合があります。Webpackでは、resolve.fallbackオプションを使用してエラーを抑制するのが一般的でした。Turbopackはturbopack.resolveAliasを使用して同様のオプションを提供しています。この場合、ブラウザにfsがリクエストされた場合、Turbopackに空のモジュールをロードするよう指示します。

next.config.ts
import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  turbopack: {
    resolveAlias: {
      fs: {
        browser: './empty.ts', // このメソッドを使用する前にコードインポートを修正することをお勧めします
      },
    },
  },
}
 
export default nextConfig

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

Sassのnode_modulesインポート

TurbopackはNode.jsネイティブモジュールからのSassファイルのインポートを完全にサポートしています。Webpackは従来のチルダ（~）プレフィックスを許可していましたが、Turbopackはこの構文をサポートしていません。

Webpackの場合：

styles/globals.scss
@import '~bootstrap/dist/css/bootstrap.min.css';

Turbopackの場合：

styles/globals.scss
@import 'bootstrap/dist/css/bootstrap.min.css';

インポートの変更ができない場合は、turbopack.resolveAliasを使用できます。例えば：

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

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

Turbopackは開発時のファイルシステムキャッシング機能をサポートしており、実行間でコンパイラーのアーティファクトをディスク上に保存することで、再起動時のコンパイル時間を大幅に短縮できます。

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

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

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

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

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

非同期ダイナミックAPIへの移行にコードモッドを使用してください。

非同期ダイナミックAPIの型を移行する

非同期paramsとsearchParamsへの移行を支援するため、npx next typegenを実行して、グローバルに利用可能な以下の型ヘルパーを自動生成できます：

補足： typegenはNext.js 15.5で導入されました。

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

/app/blog/[slug]/page.tsx
export default async function Page(props: PageProps<'/blog/[slug]'>) {
  const { slug } = await props.params
  const query = await props.searchParams
  return <h1>ブログ記事：{slug}</h1>
}

このアプローチにより、slugを含むprops.paramsとsearchParamsへのアクセスが完全に型安全になり、ページ内で直接実行できます。

アイコンとOGイメージの非同期パラメーター（破壊的変更）

opengraph-image、twitter-image、icon、apple-iconのイメージ生成関数に渡されるプロップは、プロミスになりました。

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

app/shop/[slug]/opengraph-image.js
// Next.js 15 - 同期paramsアクセス
export function generateImageMetadata({ params }) {
  const { slug } = params
  return [{ id: '1' }, { id: '2' }]
}
 
// Next.js 15 - 同期paramsとidアクセス
export default function Image({ params, id }) {
  const slug = params.slug
  const imageId = id // 文字列
  // ...
}

Next.js 16から、非同期リクエストAPIの変更に合わせるため、これらも非同期になります。

app/shop/[slug]/opengraph-image.js
// Next.js 16 - 非同期paramsアクセス
export async function generateImageMetadata({ params }) {
  const { slug } = await params
  return [{ id: '1' }, { id: '2' }]
}
 
// Next.js 16 - 非同期paramsとidアクセス
export default async function Image({ params, id }) {
  const { slug } = await params // paramsは非同期になりました
  const imageId = await id // generateImageMetadataを使用している場合、idはPromise<string>になります
  // ...
}

React 19.2

Next.js 16のアプリケーションルーターは最新のReactカナリアリリースを使用し、新しくリリースされたReact 19.2の機能とその他の段階的に安定化される機能が含まれています。ハイライトは以下の通りです：

  • ビューの遷移： トランジション内またはナビゲーション内でアップデートされる要素をアニメーション化します。
  • useEffectEvent： エフェクト内の非リアクティブロジックを抽出して、再利用可能なエフェクトイベント関数にします。
  • アクティビティ： display: noneを使用してUIを非表示にすることで「バックグラウンドアクティビティ」をレンダーし、状態を保持してエフェクトをクリーンアップします。

詳細はReact 19.2アナウンスをご覧ください。

Reactコンパイラーサポート

Reactコンパイラーの1.0リリースに続き、Next.js 16でReactコンパイラーのサポートが安定化されました。Reactコンパイラーは自動的にコンポーネントをメモ化し、手動コード変更なしで不要な再レンダリングを削減します。

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

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

Reactコンパイラープラグインの最新バージョンをインストールします：

Terminal
npm install -D babel-plugin-react-compiler

補足： このオプションを有効にすると、開発時とビルド時のコンパイル時間が長くなることが予想されます。Reactコンパイラーはバベルに依存するためです。

キャッシングAPI

revalidateTag

revalidateTagに新しい関数シグネチャーがあります。第2引数としてcacheLifeプロファイルを渡せます。

app/actions.ts
TypeScript
'use server'
 
import { revalidateTag } from 'next/cache'
 
export async function updateArticle(articleId: string) {
  // 記事データを陳腐化した状態にマーク - 記事リーダーは再検証中に陳腐化したデータを表示します
  revalidateTag(`article-${articleId}`, 'max')
}

ブログ記事、製品カタログ、ドキュメントなど、わずかな更新遅延が許容できるコンテンツに対してrevalidateTagを使用します。バックグラウンドで新しいデータが読み込まれている間に、ユーザーは陳腐化したコンテンツを受け取ります。

updateTag

updateTagは、新しいサーバーアクション専用のAPIで、ユーザーが変更を加えると、陳腐化したデータではなくUIが即座に変更を表示する読み書き一貫性を提供します。

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

app/actions.ts
TypeScript
'use server'
 
import { updateTag } from 'next/cache'
 
export async function updateUserProfile(userId: string, profile: Profile) {
  await db.users.update(userId, profile)
 
  // キャッシュを期限切れにして即座に更新 - ユーザーは変更をすぐに表示できます
  updateTag(`user-${userId}`)
}

これにより、インタラクティブな機能がすぐに変更を反映させることが保証されます。フォーム、ユーザー設定、ユーザーが更新をすぐに見ることを期待する任意のワークフローに最適です。

updateTagまたはrevalidateTagをいつ使用するかについては、詳細はこちらをご覧ください。

refresh

refreshを使用すると、サーバーアクション内からクライアントルーターを更新できます。

app/actions.ts
TypeScript
'use server'
 
import { refresh } from 'next/cache'
 
export async function markNotificationAsRead(notificationId: string) {
  // データベースの通知を更新します
  await db.notifications.markAsRead(notificationId)
 
  // ヘッダーに表示される通知カウントを更新します
  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をプリフェッチする場合、レイアウトは1回だけダウンロードされます。
  • 段階的なプリフェッチ： Next.jsはページ全体ではなく、キャッシュにない部分のみをプリフェッチします。

これらの変更はコード変更を必要とせず、すべてのアプリケーションにおいてパフォーマンスを向上させるように設計されています。

ただし、プリフェッチリクエストの数が増加し、転送サイズが大幅に低下する可能性があります。これはほぼすべてのアプリケーションにとって正しいトレードオフであると考えています。

増加したリクエスト数が問題を引き起こす場合は、issueまたはdiscussionを作成して報告してください。

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

Next.js 16は実験的な**部分的プリレンダリング（PPR）**フラグおよび設定オプション（ルートレベルセグメントexperimental_pprを含む）を削除します。

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

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

Next.js 16のPPRはNext.js 15カナリアとは異なる動作をします。現在PPRを使用している場合は、使用している現在のNext.js 15カナリアにとどまってください。キャッシュコンポーネントへの移行ガイドを今後提供します。

next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  // 現在PPRを使用している場合
  // 使用しているNext.js 15カナリアにとどまる
  experimental: {
    ppr: true,
  },
}
 
module.exports = nextConfig

middlewareからproxyへ

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

edgeランタイムはproxyでサポートされていません。proxyランタイムはnodejsで、設定はできません。edgeランタイムの使用を続ける場合は、middlewareを使用してください。マイナーリリースで追加のedgeランタイム指示を提供する予定です。

Terminal
# middlewareファイルをリネームします
mv middleware.ts proxy.ts
# または
mv middleware.js proxy.js

名前付きエクスポートmiddlewareも非推奨になりました。関数をproxyにリネームします。

proxy.ts
TypeScript
export function proxy(request: Request) {}

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

middlewareという名前を含む設定フラグもリネームされます。例えば、skipMiddlewareUrlNormalizeはskipProxyUrlNormalizeになります。

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

バージョン16のコードモッドはこれらのフラグも更新できます。

next/imageの変更

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

クエリ文字列のあるローカル画像ソースは、images.localPatterns.search設定を必要とするようになり、列挙型攻撃を防ぎます。

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

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

next.config.ts
TypeScript
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秒に戻します：

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

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

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

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

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

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

開発者の使用は不足していませんが、devicePixelRatio: 2が実際には32pxの画像を取得してレティナディスプレイのぼやけを防ぐため、16ピクセル幅の画像はより一般的でなくなっていると考えています。

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

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

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

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

image.qualities配列に含まれていないqualityプロップを指定する場合、品質はimages.qualitiesの最も近い値に強制されます。例えば、上記の設定では、品質プロップ80は75に強制されます。

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

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

next.config.ts
TypeScript
import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    dangerouslyAllowLocalIP: true、 // プライベートネットワーク用のみ
  },
}
 
export default nextConfig

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

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

next.config.ts
TypeScript
import type { NextConfig } from 'next'
 
const nextConfig: NextConfig = {
  images: {
    maximumRedirects: 0、 // リダイレクトを無効にします
    // または
    maximumRedirects: 5、 // エッジケースのために増加させます
  },
}
 
export default nextConfig

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

next/legacy/imageコンポーネントは非推奨になりました。next/imageを使用します：

// 前
import Image from 'next/legacy/image'
 
// 後
import Image from 'next/image'

images.domains設定（非推奨）

images.domains設定は非推奨になりました。

next.config.js
// image.domainsは非推奨です
module.exports = {
  images: {
    domains: ['example.com'],
  },
}

セキュリティの向上のためにimages.remotePatternsを使用してください：

next.config.js
// 代わりにimage.remotePatternを使用します
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'example.com',
      },
    ],
  },
}

同時devとbuild

next devとnext buildは出力ディレクトリを分離して使用し、同時実行を有効にします。next devコマンドは.next/devに出力します。これは新しいデフォルト動作で、isolatedDevBuildで制御されます。

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

開発サーバーが.next/devに出力するため、Turbopackトレーシングコマンドは以下のようにしてください：

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

並列ルートdefault.jsの要件

すべての並列ルートスロットに明示的なdefault.jsファイルが必要になりました。これらなしではビルドに失敗します。

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

app/@modal/default.tsx
import { notFound } from 'next/navigation'
 
export default function Default() {
  notFound()
}

またはnullを返します：

app/@modal/default.tsx
export default function Default() {
  return null
}

ESLintフラットコンフィグ

@next/eslint-plugin-nextはESLintフラットコンフィグ形式をデフォルトに設定し、ESLint v10（従来の設定サポートが削除される）に準拠します。

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

従来の.eslintrc形式を使用している場合は、フラットコンフィグ形式への移行を検討してください。詳細は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"属性を追加します：

app/layout.tsx
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実装の両方に問題があり、クライアントコンポーネントペイロードの説明方法について意見が異なっていました。

実際のルートパフォーマンスを測定する最も効果的な方法は、Chrome LighthouseやVercel Analyticsなどのツールを使用し、コアウェブバイタルとダウンロードされたリソースサイズに焦点を合わせることです。

next dev設定読み込み

以前のバージョンでは、開発中にNext設定ファイルは2回読み込まれていました：

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

これは非効率でした。next devコマンドはNext.jsサーバーを起動するために設定ファイルを必要としないためです。

この変更の結果として、Next.jsの設定ファイルでprocess.argvに'dev'が含まれているかどうかを確認すると、falseが返されます。

補足： typegenおよびbuildコマンドは、process.argvで引き続き表示されます。

これは特にnext devでサイドエフェクトをトリガーするプラグインに重要です。その場合、NODE_ENVがdevelopmentに設定されているかどうかを確認すれば十分かもしれません。

next.config.js
import { startServer } from 'docs-lib/dev-server'
 
const isDev = process.env.NODE_ENV === 'development'
 
if (isDev) {
  startServer()
}
 
const nextConfig = {
  /* 設定オプション */
}
 
module.exports = nextConfig

別の方法として、構成が読み込まれるphaseを使用します。

ビルドアダプターAPI（アルファ版）

ビルドアダプターRFCに続き、ビルドアダプターAPIの最初のアルファバージョンが利用可能になりました。

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

next.config.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設定ファイルからamp設定
  • next/ampフック指定のインポートと使用（useAmp）
// 削除されました
import { useAmp } from 'next/amp'
 
// 削除されました
export const config = { amp: true }
  • ページからexport const config = { amp: true }
next.config.js
const nextConfig = {
  // 削除されました
  amp: {
    canonicalBase: 'https://example.com',
  },
}
 
export default nextConfig

AMPがまだユースケースに必要かどうかを評価します。ほとんどのパフォーマンス利点は、Next.jsの組み込み最適化とモダンウェブ標準を通じて達成できるようになりました。

next lintコマンド

next lintコマンドは削除されました。BiomeまたはESLintを直接使用してください。next buildはリンティングを実行しなくなります。

移行を自動化するためにコードモッドが利用可能です：

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

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

next.config.mjs
/** @type {import('next').NextConfig} */
const nextConfig = {
  // サポートされなくなりました
  // eslint: {},
}
 
export default nextConfig

ランタイム設定

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

前（Next.js 15）：

next.config.js
module.exports = {
  serverRuntimeConfig: {
    dbUrl: process.env.DATABASE_URL,
  },
  publicRuntimeConfig: {
    apiUrl: '/api',
  },
}
pages/index.tsx
import getConfig from 'next/config'
 
export default function Page() {
  const { publicRuntimeConfig } = getConfig()
  return <p>APIオブジェクト：{publicRuntimeConfig.apiUrl}</p>
}

後（Next.js 16）：

サーバーのみの値については、サーバーコンポーネント内で環境変数に直接アクセスします：

app/page.tsx
async function fetchData() {
  const dbUrl = process.env.DATABASE_URL
  // サーバー側の操作のみに使用します
  return await db.query(dbUrl, 'SELECT * FROM users')
}
 
export default async function Page() {
  const data = await fetchData()
  return <div>{/* データをレンダーします */}</div>
}

補足： taint APIを使用して、機密性の高いサーバー値をクライアントコンポーネントに誤って渡さないようにします。

クライアントアクセス可能な値については、NEXT_PUBLIC_プレフィックスを使用します：

.env.local
NEXT_PUBLIC_API_URL="/api"
app/components/client-component.tsx
'use client'
 
export default function ClientComponent() {
  const apiUrl = process.env.NEXT_PUBLIC_API_URL
  return <p>APIオブジェクト：{apiUrl}</p>
}

環境変数がランタイムで読み込まれることを保証するため（ビルド時にバンドルされない）、process.envから読み込む前にconnection()関数を使用します：

app/page.tsx
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設定ファイルを更新し、dynamicIOフラグを削除します。

next.config.js
// Next.js 15 - experimental.dynamicIOは削除されました
module.exports = {
  experimental: {
    dynamicIO: true,
  },
}

cacheComponentsフラグをtrueに設定して追加します。

next.config.js
// Next.js 16 - 代わりにcacheComponentsを使用します
module.exports = {
  cacheComponents: true,
}

unstable_rootParams

unstable_rootParams関数は削除されました。近い将来のマイナーリリースで配信予定の代替APIに取り組んでいます。