Turbopack: What's New in Next.js 16.3

ブログに戻る
2026年6月29日（月）
Turbopack：Next.js 16.3 の新機能
投稿者：Andrew Imm @ setimmediate

Next.js 16.3 Preview がパブリックテスト向けに利用可能になりました。今回のリリースは npm に @preview タグで公開されているため、今日から 16.3 を試すことができます。数週間以内に安定版を公開する予定です。プレビューに関するフィードバックは GitHub 上でお待ちしています。

Next.js 16.3 の安定化に向けて、内部の変更点を紹介する一連の投稿を行っています。以前の記事では Instant Navigation の新機能や最新の AI 改善について取り上げました。本稿は Next.js 内の Turbopack バンドラに関する最新改善点の第3回です。

Next.js 16.3 では、Turbopack の最新安定版が主にコンパイラ性能にフォーカスしています。最新の機能は多くが CPU とメモリ使用量の削減、ビルド時間の短縮、ランタイム体験の改善に集中しています。

主な改善点：

• 開発サーバのメモリ使用量を最大で約90%削減
• ビルドを高速化する永続的ファイルシステムキャッシュ
• 実験的な Rust React Compiler サポート
• import.meta.glob API サポート
• より速い HMR と開発起動

開発モードでのメモリ使用量の削減

Turbopack のコア設計はインクリメンタルコンパイルに重点を置いています。以前の作業をキャッシュすることで、変更されていないファイルの再コンパイルを避けます。大規模な Next.js アプリを開発するとき、コンパイル時間はルートの総サイズではなく、あなたが行った変更のサイズに比例します。

この設計を追求する中で、私たちはあるトレードオフを意図的に選びました：結果をより多くメモリにキャッシュすることで CPU 使用量を削減することです。しかし、Turbopack の初期リリース以降、メモリ使用量は問題となっていました。開発時にはコーディングエージェント、IDE、型チェック、リンターなどが同時に動作し、それぞれが多くのメモリを消費します。過去3か月、Turbopack チームはシステムメモリに与える影響を減らすことに注力してきました。16.3 へのアップグレードで、長時間稼働する開発セッションにおけるメモリ使用量が直ちに減少するはずです。

メモリ使用量（50ルートをコンパイル後）の例

サイト	削減目安	Before	After
vercel.com (dashboard)	約90%小さい	21.5 GB	2 GB
nextjs.org	約82%小さい	4,600 MB	840 MB

これらの改善は小さな積み上げの成果によるものが多く、データ構造の圧縮や不要なデータ保持の回避などを含みます。もっとも大きな改善は、インメモリキャッシュの多くをエビクト（追い出し）できる新機能から来ています。

Next.js 16.1 で最初に導入されたファイルシステム永続化機能を活用することで、Turbopack はメモリ上のキャッシュ結果をディスクに移し、メモリから取り除くことができます。これにより、開発セッション中のメモリの無制限な増加を防ぎ、訪れたすべてのルートがメモリに残ることを避けられます。

メモリエビクションは開発用のファイルシステムキャッシュが有効であることを要件とします。16.3 ではこれらのオプションはデフォルトでオンになっています。キャッシュや開発パフォーマンスを調査するときに無効化したい場合は、experimental の turbopackMemoryEviction 設定を使用できます：

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false, // disables memory eviction, default value is 'full'
  },
};

すべてのアプリケーションに当てはまる単一の削減割合は存在しません。個別の結果はルートグラフの大きさ、開発セッション中に触れられた範囲、セッションの継続時間に依存します。

ビルドのためのファイルシステムキャッシュ

Turbopack のインメモリキャッシュをディスクに永続化する機能は、16.1 リリース以降 next dev セッションの高速化に貢献してきました。Vercel のサイトで数か月にわたって本番運用で強化した後、同じ永続化キャッシュが next build にも使えるようになりました。

Turbopack の next build におけるコンパイル時間の例

サイト	効率	Cold	Cached
nextjs.org	約2.3×速い	21s	9.2s
vercel.com/home	約1.4×速い	66s	46s
vercel.com/geist	約5.5×速い	30s	5.5s

永続ディスクキャッシュにより、ビルドは以前に計算した作業結果を再利用して静的アセットのコンパイル時間を短縮できます。CI 環境では、生成された .next ディレクトリを前回の実行からコピーすることでこれを活用できます。ビルド開始時に Turbopack がキャッシュを検出すると、コンパイル前にディスクからエントリを読み込みます。

ビルド用の永続キャッシュは turbopackFileSystemCacheForBuild 設定で有効にできます：

const nextConfig = {
  experimental: {
    // Enable filesystem caching for `next build`
    turbopackFileSystemCacheForBuild: true,
  }
}

実験的な Rust React コンパイラ

Next.js は最初の 16.0 リリース以来、React Compiler を安定してサポートしてきました。これまでは React Compiler は Babel トランスフォームとしてのみ利用可能でしたが、大規模アプリでは JS 実行リソースを待つことでビルドが遅くなることが観察されていました。

最近 React チームがコンパイラのネイティブな Rust ポートを公開し、私たちはこれを Turbopack に迅速に統合しました。v0 のような大規模 React アプリでの初期テストでは 20～50% のコンパイル時間短縮が見られたため、ネイティブコンパイラ統合を実験的機能としてリリースし、採用促進を図ります。

Rust React Compiler を試すには、compiler を有効にして turbopackRustReactCompiler 実験フラグでネイティブ版を使うようにします：

const nextConfig = {
  // enable the compiler
  reactCompiler: true,
  experimental: {
    // use the Rust version, instead of the OG Babel one
    turbopackRustReactCompiler: true,
  }
}

React Compiler の設定方法は機能ごとにさまざまです。詳細は公式ドキュメントを参照してください。

import.meta.glob

Turbopack は Vite と互換性のある import.meta.glob API をサポートします：

const posts = import.meta.glob('./posts/*.mdx');

この API はパターンに一致するすべてのモジュールを、名前をハードコードせずにインポートできます。結果は一致したファイルパスをキーとするオブジェクトです。デフォルトでは各値はモジュールを読み込む非同期関数です：

for (const path in posts) {
  const post = await posts[path]();
}

eager: true を指定すると各マッチを即時にインポートします：

const posts = import.meta.glob('./posts/*.mdx', { eager: true })

実装は名前付きインポート、複数パターン、否定パターン、カスタム検索パス、ローダー用のクエリ文字列、生成される TypeScript 型もサポートします。この機能は Turbopack のファイルウォッチャによって支えられており、開発モードでファイルが追加または削除されると再コンパイルがトリガーされ、サイトは常に最新の変更を反映します。

この API は製品説明やブログ投稿のような類似ドキュメント集合の取得に最適です。ライブラリ開発者も JS エコシステム全体でこの API が使えることから恩恵を受けると期待しています。

import.meta.glob は Turbopack 機能として利用可能であり、--webpack オプションでビルドされた Next.js アプリでは動作しません。利用可能なオプションは import.meta.glob のリファレンスを参照してください。

HMR の改善

Vercel 上の大規模 Next.js アプリで Turbopack の性能を解析した結果、すべての Turbopack ユーザーに恩恵があるいくつかの性能改善が見つかりました。多くの調査は HMR のサブスクリプションをより効率化することに集中しました。

その中で重要な変更の一つは、ページでロードされるチャンクの追跡を簡素化した点です。複数のサブスクリプションを単一化することで、複雑なアプリの開発サーバ冷起動時間を15%以上短縮できました。これは HMR リソース調査の始まりに過ぎず、今後の Next.js リリースでもメモリやコールドスタートのさらなる改善を提供する予定です。

ランタイムサイズの縮小

Turbopack はモジュール解決と動的チャンクのフェッチを可能にするランタイムコードを各ルートに配布します。これには WebAssembly、Worker、トップレベル非同期モジュールのロード用コードも含まれます。しかし、すべての Next.js アプリがこれらの機能を使うわけではありません。今回から Turbopack は必要なときにのみそれらの機能を配布し、不要なランタイムコードの配布を回避します。

ローカル PostCSS 設定

モノレポではパッケージごとに異なる PostCSS トランスフォームが必要な場合があります。実験的オプション turbopackLocalPostcssConfig を有効にすると、Turbopack は各 CSS ファイルに最も近い設定を解決し、その後プロジェクトルートにフォールバックします：

// next.config.ts
const nextConfig = {
  experimental: {
    turbopackLocalPostcssConfig: true,
  },
};

これによりパッケージ単位の CSS はローカル設定を使用でき、アプリケーション全体の CSS はルート設定のままにできます。

互換性と信頼性

Next.js 16.3 は 16.2 のパッチラインでの修正をすべて取り込み、モジュール解決、トレーシング、HMR 周りのさらに多くの改善を加えています。主な修正点は以下の通りです：

• Windows 上での import.meta.url に対する正しいファイル URL
• チャンクフェッチの失敗時にリトライ
• createRequire(new URL(..., import.meta.url)) のサポート改善
• worker_threads の URL 解決の修正
• module-sync エクスポート条件のサポート
• webpack ローダーがクラッシュしたときのより良いエラー表示
• Safari における CSS HMR の修正

---

このページの内容：

• 開発モードでのメモリ使用量の削減
• ファイルシステムキャッシュ（ビルド向け）
• 実験的な Rust React コンパイラ
• import.meta.glob
• HMR の改善
• ランタイムサイズの縮小
• ローカル PostCSS 設定
• 互換性と信頼性