3年前、トロントのクライアントとの通話で、Next.jsのビルドが94秒かかる様子を眺めていて、二人ともそれで大丈夫なふりをしていた。Webpack。8000モジュール。2021年以来誰も監査していない共有UIコンポーネントを持つモノレポ。クライアントは「もっと速くできないか」と聞いてきた。私は2日間の作業を見積もった。実際には4日かかった。それでもビルド時間を61秒まで短縮したが、それは誰も参加したくないレースで勝つような感じだった。
Turbopackはその物語を変えた。ほぼ。しかし2026年現在も、開発者がTurbopackへの切り替えをゴールではなくスタート地点だと勘違いしているのを何度も見かける。フラグを切り替えて、開発サーバーの起動を40%短縮して、完了だと考える。実際のボトルネックは、ただ静かな場所に移動しただけだ。
では、実際の本番コードベースでTurbopackを実行する場合、ビルド時間が本当にどこへ行くのかを説明しよう。Todoアプリではない。Next.jsの例テンプレートでもない。200以上のルート、CMS統合、そして1秒ごとに気づくクライアントを持つ本当のサイトだ。
開発モードと本番ビルドのギャップ
ほとんどの人が見落としていることがある。Turbopackの最大のメリットは開発サーバーにある。インクリメンタルコンパイル、モジュールレベルキャッシング、Rust駆動グラフ全体。開発モードではそれは本当に変革的だ。Seahawk Mediaのあるクライアントプロジェクトで、Webpackでのコールドスタートが28秒だったのが、Turbopackで4秒以下になるまで計測した。それは丸め誤差ではない。
だがnext buildは別物だ。2026年初頭現在、Turbopackの本番ビルドサポートは安定しているが、パイプライン全体を書き直すわけではない。静的分析、ページ最適化、SWCコンパイラはすべてTurbopackのバンドラーと並んで重い処理をしている。本番出力で10倍の均一な向上は期待できない。
これが大切なのは、開発者が間違ったものを計測するからだ。next devが起動するのを見て、ビルドが速いと結論づける。その後CIが3分かかり、肩をすくめる。
Turbopackアーキテクチャが実際に何をするのか
Turbopackは需要駆動計算モデルで動作する。要求されたものだけを構築し、モジュールレベルでキャッシュし、広く無効化するのではなく正確に無効化する。これがVercelチームのアーキテクチャ説明が「関数レベルのメモ化」について話す理由だ。それはマーケティング用語ではない。1つのコンポーネントをいじっても完全な再バンドルが強制されない理由の本当のメカニズムだ。
その意味するところ: 最速の改善は、以前無効化が広すぎた場所で起こる。共有ユーティリティファイル、大型バレルエクスポート、深くネストされた再エクスポート。これらはWebpackがお前を静かに罰していた場所だ。
2026年に時間が実際に消える場所
先四半期、NEXT_TURBOPACK_TRACING=1を使って4つのコードベースを監査した。そう、その環境変数は存在する。そしてそれはChromeのパフォーマンスパネルに読み込める追跡ファイルを吐き出す。何かが原因だと仮定する前に強くお勧めする。
ここが私が見つけたもので、おおよそ出現頻度でランク付けしたものだ:
- バレルファイルの爆発。デザインシステムから60個のコンポーネントを再エクスポートする単一の
index.tsは、2つしか使わなくても、それらのモジュールすべてをグラフに引き込む。TurbopackはこれをWebpackより上手く扱うが、問題を消すわけではない。修正は粒度の細かいインポート。常にそうだ。 - バンドルから分離されていない型チェック。
tsc --noEmitをTurbopackが処理するのと同じビルドパイプライン内で実行すると、壁の時間を2倍にしている。それらを分ける。TypeScript型チェックとTurbopackバンドルはCIで並列ジョブであるべき、順序的なステップではない。 - サードパーティパッケージの不安定なモジュールID。一部のnpmパッケージはまだ動的requireを伴うCommonJSで出荷されている。Turbopackはこれらのために遅い分析パスにフォールバックしなければならない。先月PDFジェネレーションライブラリの古いバージョンでこれに当たった。アップグレードして、8秒節約した。
- ビルド時の画像最適化。
next/imageで数千の画像バリエーションを事前生成し、静的エクスポートを行う場合、それは同期的でCPUバウンドです。Turbopackではありません。しかし、ビルドトレースに表示され、人々はバンドラーを非難します。 - 大規模な`getStaticProps`データペイロード。ビルド中に1ページあたり4MBのCMSデータを取得し、300ページにわたって行う場合、それはネットワークとパージングの問題です。やはりTurbopackではありません。しかし、同じ180秒のビルド内に存在し、まとめて非難されます。
不都合な真実は、Turbopackがバンドリングフェーズを大幅に加速させたため、その周辺のすべてが相対的に遅く見えるようになったということです。自動で開くようにキッチンゴミ箱をアップグレードして、外のゴミ箱への移動が実際の不便さだと気づくようなものです。
バレルファイル問題は独自のセクションに値する
これは十分に強調できません。バレルファイルは、私が各エージェンシーで見かける最も一般的な自業自得のビルド問題です。
あるクライアントが2025年後半に、次のような構造を持つコンポーネントライブラリを持ってやってきました。
`` components/ index.ts (exports 140 named components) ``
1つのボタンをインポートするだけで、140コンポーネント全体のグラフがプルされました。Webpackでは、ツリーシェイキングがアウトプット時に部分的に役立ちました。Turbopackでは、何かを削除できる前に、モジュールグラフ全体をトラバースして理解する必要がありました。開発サーバーそのものは遅くありませんでしたが、コールドスタートは辛かったです。
パス固有のインポートに再構築しました。
`` import { Button } from '@company/ui/button' import { Modal } from '@company/ui/modal' ``
コールド開発スタートは11秒から3秒未満に短縮されました。本番ビルドは22秒短縮されました。誰もTurbopackの設定には手をつけていません。修正は単に...インポートについて怠け者にならないことです。
これを検出する適切なeslint-plugin-importルールが実は存在します：import/no-barrel-files。これをリント設定に追加し、違反をビルド負債として扱ってください。
CI内のキャッシング：あなたはおそらく40秒を失っている
Turbopackのローカルキャッシングは優秀です。CIキャッシングは別の問題であり、ほとんどのチームは一度セットアップして、二度と見直しません。
Turbopackキャッシュはデフォルトで.next/cache/turbopackに格納されます。CIパイプライン（GitHub Actions、CircleCI、その他）がそのディレクトリを実行間で保持していない場合、毎回完全なコールドビルドを実行しています。適切な規模のコードベースでは、それは実行あたり30～60秒の純粋な無駄です。
GitHub ActionsのNext.js + Turbopackセットアップ用の適切なキャッシュキーは次のようになります。
- キャッシュキー：package-lock.jsonのハッシュ + next.config.jsのハッシュ +
tsconfig.jsonのハッシュ - キャッシュパス：
.next/cache - リストアキー：同じブランチ上の前のキャッシュにフォールバック、次にメイン
以上です。ほとんどのチームはpackage-lock.jsonだけをハッシュします。しかし、next.config.jsがTurbopackの設定を変更する場合（実験的な機能、モジュールエイリアス、カスタムローダー）、それを無効化したいです。設定変更後、古いキャッシュが誤ったモジュール解決を提供していたバグを見かけました。夜11時にデバッグするのは厄介です。
Seahawkには、キャッシュキー構造の修正だけで平均CIビルドを4分20秒から2分50秒に短縮したフィンテックプロジェクトがありました。同じコード。同じハードウェア。ただよりスマートなキャッシュ無効化です。
カスタムローダーと、それがあなたの成果を殺す理由
Turbopackはカスタムローダーをサポートしていますが、コストがあります。すべてのカスタムローダーは、Turbopackのネイティブ高速パスから互換性レイヤーへと脱落させます。Vercelチームは、Next.js Turbopack設定ドキュメントでこれについてかなり正直です。
これを最も頻繁に見かけるのは：
- SVGローダー（SVGをビルド時にReactコンポーネントに変換する人々）
- 重いremark/rehypeプラグインチェーンを使用したMDX
- カスタムPostCSS設定とほとんど使用されないプラグインを含むCSS Modules
SVGに関しては、2026年の方針は、Next.jsビルド時ではなく、別の構築ステップとしてアイコンライブラリをReactコンポーネントに事前コンパイルすることです。SVGRはスタンドアロンスクリプトとして優れています。デザイントークンが変わるたびに実行し、出力をコミットし、Turbopackに通常の.tsxファイルとして扱わせます。
MDXはより複雑です。40個のremarkプラグインを実行していれば、その影響を感じるでしょう。実際に必要なものを監査してください。remark-gfm、remark-smartypants、カスタムフットノートプラグイン、その他2つを実行していたコードベースを見ましたが、目に見える出力差を生じさせていたのは2つだけでした。不要なものを削除してください。
誰も語らないモジュール解決税
パスエイリアス。みんな使っています。@/components、@/lib、~/utils。便利です。ただし、それは複合する小さな税でもあります。
Turbopackはインポートに遭遇するたびにエイリアスを解決します。4,000個のインポートと12個のエイリアスが設定された大規模コードベースでは、これはビルドあたり48,000個の解決操作です。破滅的ではありません。ただし無料でもありません。
修正はエイリアスを削除することではありません。それらで正確に対応することです。特定のパスで十分な場合はワイルドカードエイリアスパターンを避けてください。tsconfig.jsonのpathsをnext.config.jsのturbopack resolveAlias設定と同期させてください。この2つの間にズレが生じると、Turbopackは冗長な解決作業を行います。この整理だけで4～5秒の短縮を見たことがあります。
2026年のTurbopackができていないこと
正直に言うと、私はTurbopackが好きです。Seahawkのほとんどの新規プロジェクトで使用しています。ただし誠実さは重要です。
- バンドル分析はWebpackのエコシステムほど成熟していません。@next/bundle-analyzerは機能していますが、可視化はwebpack-bundle-analyzerから得られるほど細粒度ではありません。改善されていますが、まだそこに到達していません。
- プラグインエコシステムは小さいです。スタックが重度にカスタマイズされたWebpackプラグインに依存している場合（一部のレガシーエンタープライズセットアップはそうです）、移行は午後の作業ではなく実際のプロジェクトです。
- Windowsのパフォーマンスは歴史的にmacOSとLinuxに遅れをとっています。これはNext.jsのリリースごとに改善されていますが、チームがWindows中心の場合は、コミットする前にベンチマークしてください。
これらのどれも決定的な要因ではありません。ただし、既存プロジェクトの移行と新規開始のどちらを評価するかを判断する際の実際の検討事項です。
ビルドを実際にトレースする方法
推測を止めてください。以下を実行してください：
- 環境で
NEXT_TURBOPACK_TRACING=1を設定してください - next buildを実行してください（dev起動をプロファイリングしている場合はnext devの場合）
- .next/traceをPerfetto UIまたはChromeのchrome://tracingで開いてください
- 期間でフィルタリングしてください。単一モジュールで2秒を超えるものはすべて調査する価値があります。
これは、ビルド最適化の関与の前に使用するのと同じアプローチです。トレースは時間がどこに行くかを示します。その他すべては専門知識として装われた推測です。
---
FAQ
2026年のTurbopackは本番ビルド用に十分安定していますか？
はい、本番ビルドサポートは2024年後期に安定版として登場し、2025年を通じて大幅に成熟しました。新規開始するほとんどのNext.jsプロジェクトでは、躊躇なくTurbopackをデフォルトにします。Webpackの大規模なカスタマイズを含むレガシープロジェクトの場合は、最初にスパイクを実施して測定してください。
TurbopackはSWCに取って代わりますか？
いいえ。SWC は TypeScript と JSX のトランスパイラです。Turbopack はバンドラです。両者は連携して動作します。Turbopack は内部で SWC を変換に使用しています。どちらかを選ぶ必要はありません。
Turbopack の開発サーバーは高速なのに、CI ビルドはまだ遅いのはなぜですか？
ほぼ確実に次のいずれかです：型チェックがバンドル処理と直列で実行されている、CI キャッシュが .next/cache 用に設定されていない、またはイメージ最適化が静的生成フェーズを支配している。トレースを実行してください。どれが原因かが表示されます。
既存の Webpack プロジェクトを今すぐ Turbopack に切り替えるべきですか？
グリーンフィールドまたはカスタマイズが少ないプロジェクトなら、はい。カスタム Webpack プラグインが 15 個あり、複雑なローダー チェーンがあるなら、適切なマイグレーション スプリントを予算化してください。金曜日の午後に思いつきでやらないでください。（個人的な経験から言っています。金曜日のことは聞かないでください。）
Turbopack は Nx や Turborepo モノレポで機能しますか？
はい、実際かなり良好に機能します。Turborepo のキャッシング は Turbopack の内部キャッシング の上にうまく積み重なり、この 2 つのツールは同じチームからの系統を共有しています。この組み合わせは、PR ごとにパッケージのサブセットのみが変更される大規模モノレポには本当に良好です。
---
ビルド ツーリングは退屈です。それまでは CI の請求書が月 800 ドルで、開発チームがスタンドアップで コールド スタートについて文句を言うようになるまでは。Turbopack はボトルネックを移動させました。これは進捗です。しかし、時間がどこに使われるかについて明確に考える必要性は排除していません。まずトレースを実行してください。次に最適化してください。そして、何があってもバレル ファイルを修正してください。