Next.js 16でビルドが大幅に高速化。Webpack後継のTurbopackを解説
はじめまして、_minoです！
この記事では、10月22日にリリースされたNext.js v16のアップデート内容をまとめました。特に安定版となったTurbopackに焦点を当て、従来のデフォルトバンドラーだったWebpackとの比較も紹介しています。最後まで読んでいただけると嬉しいです！
🔥 Next.js 16の主要アップデート
Turbopackの安定化
全てのNext.jsアプリでデフォルトのバンドラーとなりました。Fast Refreshが最大10倍、本番ビルドが2〜5倍高速化され、開発体験が大幅に向上しています。
Cache Components - 新しいキャッシングモデルの導入
Partial Pre-Rendering (PPR)とuse cacheディレクティブを活用した新しいキャッシングモデル。明示的でopt-inなキャッシング方式により、開発者の期待に沿った動作を実現します。
React Compilerの正式サポート
コンポーネントの自動メモ化により、手動での最適化なしに不要な再レンダリングを削減。React Compiler 1.0のリリースに伴い、Next.jsでも正式サポートとなりました。
proxy.tsへの名称変更
middleware.tsからproxy.tsへ名称変更。アプリケーションのネットワーク境界を明確化し、Node.jsランタイムで動作します。
キャッシングAPIの改善
-
revalidateTag()(更新): 古いキャッシュを返しつつバックグラウンドで更新する動作のため、cacheLifeプロファイルの指定が必須に -
updateTag()(新規): 更新内容を即座に反映（Server Actions専用） -
refresh()(新規): キャッシュされていない動的データのみを再取得する新API（Server Actions専用）
ルーティングとナビゲーションの最適化
レイアウトの重複排除とインクリメンタルプリフェッチにより、ページ遷移が軽量・高速化。共有レイアウトは1度のみダウンロードされます。
React 19.2のサポート
View Transitions、useEffectEvent()、<Activity/>など、React 19.2の新機能に対応しています。
Next.js Devtools MCP - AIによるデバッグ支援
Model Context Protocol統合により、AIエージェントがルーティング、キャッシング、レンダリングの挙動を理解し、コンテキストに応じたデバッグが可能になりました。
（詳細: Next.js Devtools MCP）
他にも色々アップデートされているので、詳しくはこちらをご確認ください👇
📝 前提：Turbopack & Webpackとは？
Turbopack & Webpackとは
バンドラー（bundler） と呼ばれるツールで、開発時に書いた複数のファイルを、ブラウザが効率的に読み込める形式にまとめる役割を担います。
複数のJavaScriptファイルやCSS、画像などを最適な形式にまとめる役割をします
バンドラーの主な役割
バンドラーは主に以下の4つの役割を担います。
- ファイルを統合：複数のJavaScriptファイルやCSSファイルを、必要なものだけ選んで1つ（または数個）にまとめます。
- コード変換：TypeScriptやJSXなど、ブラウザが直接理解できない形式を、JavaScriptに変換します。
- 互換性確保：最新のJavaScript機能を使っていても、古いブラウザで動作するように変換します。
- 最適化：使われていないコードを自動で削除（Tree Shaking）し、ファイルサイズを削減します。
Next.jsにおけるバンドラーの役割
Next.jsでは、バンドラーが開発時と本番ビルド時でそれぞれ重要な役割を果たします。
開発時：コード変更を即座に反映（HMR）
ファイルを編集すると、変更を検知して必要な部分だけを再コンパイルし、ブラウザに即座に反映します。ページ全体をリロードする必要がないため、フォームの入力内容やスクロール位置を維持したまま開発を続けられます。
本番ビルド時：最適化されたファイルを生成
全ファイルを解析し、コードの圧縮、不要コードの削除、ページごとの最適な分割を実行します。ファイルサイズを削減し、初回読み込み速度を向上させることで、ユーザーに快適な体験を提供します。
要するに
バンドラーは「開発者が書きやすいコード」と「ブラウザが効率的に実行できるコード」の橋渡しをする存在です。 Turbopackは、この一連の処理を従来のバンドラーより遥かに高速に行えることが最大の特徴となります。
🚀 Turbopackの特徴と機能
主要な特徴
⭐ Rust製による高速化
Rust言語で開発されており、複数のCPUコアを効率的に活用できるため、JavaScriptベースのバンドラーと比較して大幅な高速化を実現しています。
⭐ 統合グラフによる環境管理
クライアントとサーバーなど、異なる実行環境のコードを単一の仕組みで管理します。Webpackでは複数のコンパイラを立ち上げて管理する必要がありましたが、Turbopackではその複雑さが解消されます。
⭐ インクリメンタルコンピューティング（増分計算）
一度処理した結果を関数レベルでキャッシュし、変更があった部分のみを再処理します。例えば、1つのファイルを修正した場合、そのファイルの変更部分だけを再計算するため、ビルド時間が大幅に短縮されます。
⭐ 遅延バンドル（Lazy Bundling）
開発サーバーで実際にアクセスされたコードだけをバンドルします。すべてを事前に処理しないため、起動時間とメモリ使用量が削減されます。
⭐ ゼロコンフィグレーション
TypeScript、JSX、CSS Modulesなどを標準でサポートし、設定なしですぐに使えます。Babel設定ファイルがあれば自動的に適用され、主要なWebpackローダーにも対応しています。
Webpackとの比較
TurbopackとWebpackは、どちらもモジュールバンドラーですが、実装言語（JavaScriptとRust）や設計思想が大きく異なります。
| 項目 | Webpack | Turbopack |
|---|---|---|
| 実装言語 | JavaScript | Rust |
| アーキテクチャ | クライアント・サーバーを別々のコンパイラで処理 | 単一の統合グラフで全環境を一括管理 |
| キャッシュ戦略 | ビルド結果単位でキャッシュ | 関数レベルで細かくキャッシュ |
| バンドル方式 | 開発時も全体を事前処理 | アクセスされた部分のみオンデマンドでバンドル |
| 再ビルド | 変更ファイルと依存関係を再処理 | 変更された関数のみ再計算 |
| 設定 | 柔軟だが複雑化しやすい | ゼロコンフィグで即利用可能 |
| プラグイン | 豊富なエコシステム | Webpackプラグイン非対応（独自システム開発中） |
| ローダー | 完全対応 | 主要なもの対応（@svgr/webpack等） |
| 対応範囲 | フレームワーク非依存 | Next.js向けに最適化（将来的に拡張予定） |
制約事項（サポート対象外、注意点）
Turbopackには現時点で以下のような制約があります。詳細は公式ドキュメントも参照してください。
⚠️ Webpackプラグイン非対応
Webpack独自のプラグインシステムには対応していません。プラグインに依存している場合は、代替手段を探すか、Webpackを継続利用する必要があります。
⚠️ Sassカスタム関数（sassOptions.functions）非対応
RustベースのアーキテクチャのためJavaScript関数を直接実行できません。カスタムSass関数を使用している場合はWebpackの利用が必要です。
⚠️ バンドルサイズ最適化の違い
WebpackのInner Graph Optimizationに相当する機能が開発中のため、大規模モジュールのTree Shakingが不十分な場合があります。Core Web Vitalsなどの実測値で評価することを推奨します。
⚠️ CSS Modulesの読み込み順序
JavaScriptのimport順に厳密に従うため、Webpackとスタイルの適用順が異なる場合があります。競合がある場合は@importで明示的に順序を指定するか、CSSルールを調整してください。
⚠️ レガシーCSS Modules記法の一部非対応
スタンドアロンの:local/:global、@valueルール、.cssファイルのcomposesなどは非対応です。CSS変数や.module.cssへの変更で対応できます。
📊 パフォーマンス比較（Webpack vs Turbopack）
Next.js 15（Webpack）とNext.js 16（Turbopack）でベンチマークを比較しました。
開発サーバー起動からデプロイまで、実際の開発フローに沿った6項目で検証しています。
1. 開発サーバー起動時間
初回の npm run dev 実行から起動完了までの時間
| 項目 | Webpack（v15） | Turbopack（v16） | 改善率 |
|---|---|---|---|
| 起動時間 | 4.41秒 | 2.28秒 | 48%高速 |
2. HMR（Hot Module Replacement）
コード変更からブラウザ反映までの時間
| 項目 | Webpack（v15） | Turbopack（v16） | 改善率 |
|---|---|---|---|
| HMR速度 | ~500ms | ~100ms | 80%高速 |
3. 本番ビルド時間
npm run build の実行時間
| 項目 | Webpack（v15） | Turbopack（v16） | 改善率 |
|---|---|---|---|
| ビルド時間 | 11秒 | 5秒 | 54%高速 |
4. メモリ使用量
開発サーバー実行中のメモリ消費量
| 項目 | Webpack（v15） | Turbopack（v16） | 改善率 |
|---|---|---|---|
| メモリ使用量 | 94 MB | 63 MB | 32%削減 |
5. ビルドサイズ
生成されたビルドファイルの合計サイズ
| 項目 | Webpack（v15） | Turbopack（v16） | 改善率 |
|---|---|---|---|
| ビルドサイズ | 142 MB | 11 MB | 92.3%削減 |
6. デプロイ時間（Vercel）
Vercelへのデプロイ完了までの時間
| 項目 | Webpack（v15） | Turbopack（v16） | 改善率 |
|---|---|---|---|
| デプロイ時間 | 67秒 | 43秒 | 35.8%高速 |
検証結果まとめ
全項目でTurbopackが圧倒的に優れていました。 今回は小規模プロジェクトでの検証でしたが、ファイル数が増えるほど、この差は顕著になりそうです。
個人的には、ビルドサイズが92.3%も削減されたのが一番の驚きでした。CI/CDの実行時間も短くなるので、開発体験だけでなくデプロイ周りの効率も上がりそうですね。
📌 まとめ
今回のNext.js v16のアップデートは、機能面はもちろんパフォーマンスがさらに最適化されている印象です。Turbopackが安定版となりデフォルトバンドラーになったことで、開発プロセスやビルドプロセスの体験が大幅に向上しました。
実際のプロジェクトでも早速導入してみたところ、GitHub Actionsのワークフロー時間が2分以上短縮されました。（すごい！）
破壊的変更（特にキャッシュ周り）が今回多いため移行コストはかかりますが、それに見合うリターンが見込めるので、早めに移行しておくのが良さそうです。
ただ、TurbopackがVercel製ということもあり、Next.jsとの強い結びつきがあるため、現時点では他のフレームワークへの展開は難しい状況です。
📗 番外編：Rspackとの違い
Webpack/Turbopack以外のバンドラーの選択肢として、Rspackというツールがあります。パフォーマンスと機能面で優れているため参考までに紹介します。
Rspackの概要
Rustで開発された高速なWebバンドラーで、Webpackの完全な代替ツールとして設計されています。パフォーマンスに優れており、ViteやWebpackと比べて数倍〜数十倍高速に動作します。
Next.jsとRspackの統合
実験的な機能ではありますが、next-rspack パッケージが公開されており、Next.jsプロジェクトでRspackをバンドラーとして使用できるコミュニティ主導のプラグインが提供されています。
Next.jsプロジェクトをTurbopackへスムーズに移行できない場合の代替手段として位置づけられています。
Turbopackとの比較
Next.js 16時点での比較データは公開されていませんが、Next.js 15.3時点では、App RouterでのパフォーマンスがTurbopackより劣る可能性があるとの報告があります。
ただし、一部のJavaScriptプラグインを実験的にRustに移植したところ、パフォーマンスが劇的に向上し、Turbopackとほぼ同等になったとの報告もあります。実際に導入する前には、自分のプロジェクトで十分な検証を行うことをおすすめします。
👀 おわり
最後まで読んでくださり、ありがとうございました！☺️
この記事を通して、少しでも開発のお役に立てば幸いです！
個人ブログでも「技術選定に関すること」や「最新技術の分析・深掘り」など学びや知見を発信しています。もしご興味のある方はこちらからご確認いただけますと幸いです！
過去の執筆記事
Discussion