Next.js 16 Turbopack本番ビルド: 変更点と移行方法

2022年の発表以来、Turbopackの成熟を見守ってきました。Next.js 14以降、開発モードで実行し、CIの「turbo」フラグに注視してきました。2025年初頭にNext.js 16がTurbopackをデフォルトの本番バンドラーとして着陸したとき、移行を先送りできないことを知りました。Next.js 15を使用する3つのクライアントプロジェクトがアップグレードを必要とし、重大な変更、つまずいた落とし穴、そしてその先で見たパフォーマンス数値をすべてご説明します。

これはリリースノートの繰り返しではありません。実際の複雑性を持つ実際のコードベースでnext buildをTurbopackで実行したとき、実際に起こったことです。

目次

• なぜNext.js 16は大きな話題か
• 本番環境でのTurbopackの実際の変更点
• ビルドパフォーマンスベンチマーク
• 知っておくべき破壊的変更
• 移行プロセスのステップバイステップ
• Webpack設定の翻訳
• サードパーティパッケージの処理
• CSSとTailwindに関する考慮事項
• デプロイメントとCIパイプラインの更新
• まだ移行すべきではない場合
• FAQ

なぜNext.js 16は大きな話題か

Next.js 16は単なるバージョンアップではありません。フレームワークがPagesからApp Routerに移行した以降、ビルドインフラストラクチャで最も重大な変更を表しています。見出し機能は明らかです：Turbopackは開発ビルドと本番ビルドの両方のデフォルトバンドラーとしてwebpackに置き換わります。

しかし、もっと進行しています。Next.js 16はまた以下を搭載しています：

• React 19を最小サポートバージョンとして — React 18の互換性はもうありません
• ストリーミングと部分プリレンダリングの成熟度の向上
• 実際には正気の新しいキャッシュデフォルト（Next.js 15のキャッシュの反発から学習しました）
• 非同期リクエストAPIの完全な強制 — cookies()、headers()、およびparamsはすべてレガシーな同期サポートなしで今は非同期です
• Node.js 20の最小要件 — Node 18のサポートは終了しました

Next.js開発を行う私たちのような機関にとって、これはすべてに触れるタイプのリリースです。バージョン番号をバンプして完了と言うことはできません。

本番環境でのTurbopackの実際の変更点

具体的に説明します。Next.js 14および15では、Turbopackは--turboフラグでnext devに利用可能でした。本番ビルドはまだwebpackを使用していました。Next.js 15.3はnext buildの実験的な--turbopackフラグを導入し、16がリリースされるまでにデフォルトになりました。

webpackと比較してTurbopackが本番ビルドをどう基本的に扱うかは以下の通りです：

インクリメンタルコンパイルアーキテクチャ

Webpackはすべてのビルドで依存関係グラフ全体を処理します。Turbopackは、Turboエンジン（Rustで記述）上に構築された関数レベルのキャッシングシステムを使用します。実際には、後続のビルドは実際に変更されたものだけを再コンパイルします。最初のビルドは劇的に速くないかもしれませんが、2番目、3番目、10番目のビルドは速くなります。

ツリーシェイキングの改善

Turbopackのツリーシェイキングはwebpackより細かい粒度で動作します。コード変更なしに、3つのプロジェクト全体で平均して8～15％小さいクライアントバンドルを見ました。最大の利益は樽ファイルの処理から来ました — Turbopackはインデックスファイルからの未使用の再エクスポートを排除するのに本当に上手です。

モジュール解決

Turbopackはモジュールを異なる方法で解決します。より速いですが、より厳格です。webpackが暗黙的に解決していた雑なインポートパス（特定のエッジケースでの欠落ファイル拡張子、またはmacOSで壊れるケース非感度パス）がある場合、Turbopackはそれらをキャッチします。これは移行の問題の約30％を引き起こしました。

コード分割戦略

チャンク分割アルゴリズムは新しいです。Turbopackはデフォルトでより多くの、より小さなチャンクを作成します。これは一般的にHTTP/2を使用する最新ブラウザのロードパフォーマンスを改善しますが、総リクエスト数を増やすことができます。チャンク数が約40％増加し、総バンドルサイズは減少しました。

SWCは今必須です

Babel設定のいずれかにしがみついていた場合、それは消えています。Turbopackはトランスフォーメーションに専門的にSWCを使用します。これはすでに物事が向かっていた方向でしたが、Next.js 16はBabelへのフォールバックを完全に削除します。

ビルドパフォーマンスベンチマーク

3つの移行プロジェクトから実際の数値を示します。これらは合成ベンチマークではありません — GitHub Actions（Ubuntu、4 vCPU、16GB RAMランナー）のCI パイプラインで実行されている実際のクライアントアプリケーションからのものです。

メトリック	プロジェクトA（Eコマース）	プロジェクトB（SaaSダッシュボード）	プロジェクトC（コンテンツサイト）
ページ/ルート	847	124	2,340
webpackビルド（Next 15）	4m 32s	1m 48s	6m 15s
Turbopackビルド（Next 16、コールド）	3m 10s	1m 22s	4m 44s
Turbopackビルド（Next 16、ウォーム キャッシュ）	1m 05s	28s	1m 52s
バンドルサイズの変更	-12%	-8%	-14%
JS最初のロード（ホームページ）	-18KB	-7KB	-22KB
ビルドメモリピーク	3.8GB → 2.9GB	1.6GB → 1.2GB	4.2GB → 3.1GB

ウォーム キャッシュの数字は本当の話です。Turbopackが一度プロジェクトをビルドしたら、インクリメンタルリビルドは劇的に高速です。ヘッドレスCMSを使用して数千の静的に生成されたページを備えた、プロジェクトCの多くのコンテンツ（6分以上から2分未満にキャッシュされたビルド）は重要でした。これはCI分で実際のお金を節約します。

メモリ使用量の改善も意味がありました。プロジェクトAはときどき、webpackを使用してより小さなCIランナーのOOMエラーに達していました。その問題はTurbopackで消えました。

知っておくべき破壊的変更

移行中に実際に壊れたすべてのものの実行リストです。Next.js 16アップグレードガイドはこれらのいくつかをカバーしていますが、いくつかは私たちを驚かせました。

1. カスタムWebpack設定

これが大きいです。next.config.jsにwebpackキーがある場合、それはもう機能しません。Turbopackには、Next.js設定のturbopackの下に独自の設定APIがあります。すべてが1対1のマッピングを持っているわけではありません。

// next.config.js — 前（webpackのNext.js 15）
module.exports = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },
};

// next.config.js — 後（TurbopackのNext.js 16）
module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

2. 同期リクエストAPIが削除される

Next.js 15はcookies()、headers()、params、およびsearchParamsへの同期アクセスを廃止しました。Next.js 16はそれらを完全に削除します。これらの廃止警告を無視した場合、大変な目に遭うことになります。

// 前 — これはNext.js 16で動作停止します
export default function Page({ params }) {
  const { slug } = params;
  return <div>{slug}</div>;
}

// 後
export default async function Page({ params }) {
  const { slug } = await params;
  return <div>{slug}</div>;
}

これは些細に見えますが、プロジェクト全体で200個以上のコンポーネントに触れました。ほとんどを処理するコードモッドを書きました（以下のそれ以上に）。

3. React 18はサポートされなくなりました

Next.js 16はReact 19を必要とします。React 18にピンされた依存関係がある場合、それはアップデート必要があります。ほとんどのメンテナンスされたライブラリは2025年半ばまでにReact 19サポートを持っていましたが、私たちはいくつかの硬いものに遭遇しました。

4. Node.js 18がドロップされました

最小はNode.js 20です。Dockerイメージ、CI設定、および.nvmrcファイルを更新します。

5. next/imageの変更

onLoadingCompleteプロップは完全に削除されました（Next.js 14以降廃止）。代わりにonLoadを使用してください。画像最適化パイプラインはまた新しい基本的なライブラリを使用し、キャッシュされた最適化された画像は最初のリクエストで再生成されます。

移行プロセスのステップバイステップ

これが実行したプロセスです。プロジェクトB（最小）を最初にテスト実行として行い、次にAとCに取り組みました。

ステップ1：依存関係を監査する

Next.jsに触れる前に、React 19およびNode.js 20互換性のすべての依存関係を監査しました。単純なスクリプトを使用しました：

npx npm-check-updates --target latest --filter '/react|next/'

また、最も重大なパッケージを手動でチェックしました：ヘッドレスCMS SDK、認証ライブラリ、およびUIコンポーネントライブラリ。

ステップ2：Node.jsをアップデートする

.nvmrcを20.18.0（当時の最新LTS）に更新し、Dockerfilesを更新し、CIランナーを検証しました。シンプルですが、忘れやすいです。

ステップ3：最初にReactをアップグレードする

npm install react@19 react-dom@19 @types/react@19 @types/react-dom@19

進める前に完全なテストスイートをここで実行しました。React 19には独自の破壊的変更があります（forwardRefの必要性が削除され、refは通常のプロップです、use()フックは安定しています）。Reactとは別にこれらの問題を修正し、Next.jsの問題をデバッグしていませんでした。

ステップ4：Next.js Codemondを実行する

Next.jsは機械的な変更の多くを処理するアップグレードcodemondを提供します：

npx @next/codemod@latest upgrade

これは非同期API移行の約70％を自動的に処理しました。完璧ではありません — より複雑なサーバーコンポーネントパターンで苦労しました — しかし、それは私たちに時間を節約しました。

ステップ5：Next.jsをアップグレードする

npm install next@16

ステップ6：next.config.jsを移行する

これはプロジェクトAで最も時間がかかるステップでした。これは重大なwebpackカスタマイズを持っていました。次のセクションで特定の翻訳をカバーします。

ステップ7：ビルドエラーを反復的に修正する

next buildを実行し、エラーを1つずつ処理しました。Turbopackからのエラーメッセージは実際には多くの場合webpackのものより優れています — より具体的で、より明確なファイルパスと提案があります。

ステップ8：ビジュアル回帰テスト

E2EテストにはPlaywrightを使用し、ビジュアル回帰スイートを実行しました。2つの問題を見つけました：CSS順序の差（Turbopackはwebpackより若干異なる方法でCSS インポートを処理します）と、正しくコード分割していない動的インポート。

ステップ9：パフォーマンスの検証

変更前後のLighthouseスコアとCore Web Vitalsを比較しました。すべてのプロジェクトが改善または中立のままでした。回帰はありませんでした。

Webpack設定の翻訳

このセクションはカスタムwebpack設定を持つチーム向けです。一般的なパターンがTurbopackにどのように翻訳されるかは以下の通りです。

カスタムローダー

// カスタムローダーのTurbopack等価物
module.exports = {
  turbopack: {
    rules: {
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js',
      },
      '*.graphql': {
        loaders: ['graphql-tag/loader'],
        as: '*.js',
      },
    },
  },
};

モジュールエイリアス

// 解決エイリアスは同様に機能します
module.exports = {
  turbopack: {
    resolveAlias: {
      'old-package': 'new-package',
      // ローカルファイルを指すこともできます
      '@legacy/utils': './src/utils/legacy.ts',
    },
  },
};

翻訳されていないもの

いくつかのwebpackプラグインは単にTurbopack等価物がまだ存在しません：

• webpack.DefinePlugin — next.config.jsでenvを使用するか、環境変数を直接使用してください
• BundleAnalyzerPlugin — @next/bundle-analyzerパッケージはv16からTurbopackで動作しますが、出力形式が変わりました
• splitChunks経由のカスタムチャンク分割 — Turbopackはこれを自動的に処理し、同じレベルのコントロールを公開しません。正直なところ、デフォルトはほとんどのプロジェクトに十分です。
• webpack.IgnorePlugin — インポートを空のモジュールにポイントするためにresolveAliasを使用してください

サードパーティパッケージの処理

移行中にいくつかのパッケージが問題を引き起こしました：

@sentry/nextjs — Turbopack互換性のためにはv9+が必要です。以前のバージョンはwebpackの内部にフックしました。アップグレードは簡単でしたが、設定の変更が必要でした。

next-intl — 最新バージョンに更新した後、良好に機能しました。プラグインAPIは正常に適応しました。

@vanilla-extract/next-plugin — これはプロジェクトBで最大の頭痛でした。Vanilla ExtractのwebpackプラグインはTurbopack等価物まで持っていなかった2.0リリースです。待つか代替案を考えるしかありませんでした。待ちました。

樽ファイルパッケージ — 単一のインデックスファイルから数百のコンポーネントをエクスポートするパッケージ（あなたを見て、アイコンライブラリ）は、今非常にアグレッシブに樹形図削減されます。これは良いことですが、動的に参照されたアイコンが含まれていない場合を見ました。文字列ベースのアイコン検索から直接インポートに切り替えましたが、これとにかくより良い実践です。

CSSとTailwindに関する考慮事項

Tailwind CSS（そして私たちのほとんどのプロジェクト）を使用している場合、移行は主に無痛です。Tailwind v4はTurbopackで素晴らしく機能します。ただし、注意することがいくつかあります：

CSSインポート順序

Turbopackはwebpackとは決定的ですが異なる方法でCSSインポートを処理します。特異性についてインポート順序に依存している場合（そうすべきではありませんが、正直にいえば — 私たちは皆そこで終わります）、ビジュアル上の違いが見えるかもしれません。1つのプロジェクトでは、グローバルリセットがコンポーネントCSSモジュールによって上書きされていました。インポート順序がフリップしました。

修正は私たちのCSSで明示的な@layerの使用でしたが、それはとにかく行うべきでした。

CSSモジュール

CSSモジュールは同じように機能します。変更は不要です。生成されたクラス名は異なります（実際により短い）が、テストで生成されたクラス名をターゲットにするような奇妙なことをしていない限り、これは見た目です。

PostCSS

PostCSS設定ファイルはまだ尊重されます。postcss.config.jsは継続して機能します。ここで変更は不要です。

デプロイメントとCIパイプラインの更新

デプロイメントターゲットは主にVercelとAWS（SST/OpenNext経由）です。変わったことは以下の通りです：

Vercel: Next.js 16を自動的に検出してTurbopackを使用しました。ビルドキャッシュ統合はすぐに機能します。Vercelはローカルで機能するよりもローカルCI上でビルド時間が大幅に低下しました。VercelはTurbopackのキャッシングレイヤーとの深い統合を備えているため。プロジェクトCは8分から2.5分に移動しました。

AWS/OpenNext: OpenNext 4.xへの更新が必要でしたが、Turbopack出力サポートを追加しました。出力形式は少し変わりました — .nextディレクトリ構造は再編成されました — 特定のファイルパスを参照したビルド後スクリプトには更新が必要でした。

Dockerビルド: Dockerで Next.jsをビルドしている場合、ベースイメージをNode 20+に更新してください。Turbopackのキャッシュディレクトリ（.next/cache/turbopack）をDockerレイヤーキャッシング戦略に含める必要があります。このための特定のCOPYレイヤーを追加しました。

# Turbopack用にDockerレイヤーキャッシングを最適化
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# Turbopackのキャッシュマウント
RUN --mount=type=cache,target=/app/.next/cache \
    npm run build

まだ移行すべきではない場合

これはすべてバラが見えるように描きたくありません。今のところNext.js 15に留まる正当な理由があります：

• 重いwebpackプラグイン依存性: 3つ以上のカスタムwebpackプラグインにTurbopack等価物がない場合、移行コストは価値がないかもしれません。
• 共有webpack設定を持つモノレポ: Next.jsおよび非Next.jsプロジェクト全体でモノレポ内のwebpack設定を共有しているなら、その設定を分割することは追加の作業です。
• 安定性の要件: Next.js 16.0は安定していますが、16.1および16.2は実際のバグを修正しました。移行前に少なくとも16.2+を待機していることを容認できなかったものを許可します。
• React 18に固定されたレガシー依存関係: 重要な依存関係がReact 19サポートを追加していない場合、関係なく、ブロックされます。

ヘッドレスCMS開発を行うチームの場合、CMS駆動サイトはシンプルなビルド構成を持つ傾向があるため、移行は一般的により滑らかです。

FAQ

Next.js 16で本番環境で実行するのに十分安定していますか？

はい。Turbopackは3年以上開発されており、開発モードで数百万のNext.js プロジェクト全体でテストされ、Next.js 15.3-15.5の本番ビルド中に長期ベータを経ました。16.0リリース以降、複数のクライアントサイト全体で本番環境で実行しており、バンドラー関連の問題はありません。とはいえ、特に16.0の場合、16.2+にアップグレードしてください。いくつかのエッジケースバグが解決されました。

Next.js 16でまだwebpackを使用できますか？

いいえ、主なバンドラーとして。Turbopackは Next.js 16の唯一のサポートされたバンドラーです。絶対にwebpackが必要な場合は、Next.js 15に留まる必要があります。これは2026年初頭までセキュリティパッチを受け取ります。Vercelは、Next.jsのwebpackサポートが完了したことを明らかにしています。

本番ビルドのためにTurbopackはwebpackと比較してどのくらい速いですか？

コールドビルド（キャッシュなし）では、20～30％の改善を見ました。ウォーム/キャッシュされたビルドでは、改善は50～70％にジャンプします。正確な数値はプロジェクトサイズ、ルート数、および発生している静的生成の量に大きく依存します。メモリ使用量もプロジェクト全体で一貫して20～30％低下しました。

Turbopackのためにnext.config.jsを書き直す必要がありますか？

next.config.jsにカスタムwebpack設定がある場合、はい — これらのブロックはturbopack設定形式に翻訳される必要があります。標準のNext.js設定オプションのみを使用している場合（イメージ、リダイレクト、書き換え、環境変数）、すべて全く同じに機能します。移行の取り組みは、カスタムwebpack設定がある量に比例しています。

既存のCI/CDパイプラインはNext.js 16で動作しますか？

主にはい。更新する主な事柄：Node.jsバージョン（最小20）、webpack固有の出力ファイルを参照するスクリプト、.next/cache/webpackをターゲットとするキャッシング戦略。代わりに.next/cache/turbopackをキャッシュしたいでしょう。Vercelにデプロイしている場合、すべてが自動的に処理されます。

Turbopackはnext.jsで同じすべての機能をサポートしていますか？

Next.js固有の機能については、はい — App Router、Pages Router、APIルート、ミドルウェア、ISR、SSG、SSRはすべて機能します。カスタムwebpack設定については、約90％の機能パリティがあります。残りのギャップは主にニッチなwebpackプラグインと高度にカスタマイズされたチャンク分割戦略です。特定のユースケースについてはTurbopack互換性ドキュメントをチェックしてください。

Next.js 16に移行するか、Astroのような代替案を検討するべきですか？

それはあなたのユースケースに依存します。複雑な状態管理で高度にインタラクティブなアプリケーションを構築する場合、Next.js 16は強い選択肢で、Turbopackの改善はDXを大幅に改善します。ミニマルなインタラクティビティでコンテンツの多いサイトを構築している場合、Astroは部分的なハイドレーションモデルで優れた代替案のままです。私たちは両方で構築してており、プロジェクト要件に基づいて選択しています。確実でない場合は私たちに連絡してください。評価を支援します。

中程度のサイズのNext.js 15アプリをNext.js 16に移行するのに最小限の時間はどのくらい必要ですか？

典型的な中程度のアプリケーション（50～200ルート、標準依存関係、最小限のカスタムwebpack設定）について、開発者の時間の2～4日を予算してください。これには依存関係の更新、非同期API移行、テスト、およびデプロイメント検証が含まれます。広範なカスタムwebpack設定またはレガシー依存関係がある場合、1週間以上かかる可能性があります。Social Animalのチームはインフラストラクチャ作業でスプリントを燃やしたくない場合、移行サービスを提供しています。