Vite 6 新機能詳解：ESM モジュールフェデレーションとパフォーマンス最適化

46秒。

これは Linear チームがプロジェクトビルド時に待っていた時間。一行のコードを変更し、リビルド、46秒が過ぎる。コーヒーを取って戻っても、まだ動いている。2024年末、彼らは Vite を6にアップグレードし、Rolldown を有効化—ビルド時間は6秒に低下。

このデータを最初に見た時、疑っていた。10倍？夸大だろ。自分のプロジェクトで試して、彼らが嘘をついてないことを発見。

Vite 6 は「設定を少し調整」程度のマイナーバージョンアップではない。Environment API がマルチ環境ビルドの仕方を根本的に変え、Rolldown 統合で dev と prod が同じバンドラーロジックを使い、ESM モジュールフェデレーションも公式サポートの兆しが見え。

正直、これらの変化は通常プロジェクトではあまり感知されないかもしれない。でも、大規模フロントエンドアプリを管理し、マイクロフロントエンドアーキテクチャを折腾し、「開発環境では正常、本番環境で爆発」のデバッグ悪夢に飽き飽きしているなら—この記事は読む価値がある。

第一章：Vite 6 核心新機能概要

1.1 Environment API：マルチ環境サポートの新パラダイム

Environment API は Vite 6 の最核心的なアーキテクチャ変化だが、正直、多くのプロジェクトは触る必要がない。

簡単に言えば、以前 Vite は client と ssr 環境しかデフォルトでなかった。Cloudflare Workers、Deno、その他のエッジランタイムにデプロイするなら、自分で工夫する必要があった。フレームワーク作者は Vite で各種環境をサポートするために、ハックコードを大量に書く必要があった。

Environment API はこの「工夫する」プロセスを正規化した。今こう設定できる：

// vite.config.ts
export default defineConfig({
  environments: {
    client: {
      // ブラウザ環境
      build: {
        outDir: 'dist/client'
      }
    },
    ssr: {
      // Node.js SSR 環境
      build: {
        outDir: 'dist/server'
      }
    },
    edge: {
      // エッジランタイム環境（例：Cloudflare Workers）
      resolve: {
        conditions: ['worker']
      },
      build: {
        outDir: 'dist/edge'
      }
    }
  }
})

一生使わないと思うかもしれない。大体そう。Environment API は主にフレームワーク作者向け—Nuxt、SvelteKit、Astro が各種デプロイ環境をよりエレガントにサポートできる。

通常プロジェクトなら、SPA または MPA だけで、設定は変わらない。Vite は後方互換性を維持、コード変更不要。

間接的影響は大きい。フレームワークがより多くの環境をサポートすれば、プロジェクトのデプロイ選択が増える。Nuxt は Cloudflare Workers にワンクリックでデプロイ、Astro は Deno Deploy で動作—これらは Environment API が可能にした。

1.2 Node.js サポートと移行影響

Vite 6 は Node.js 18、20、22+ を正式サポート。Node.js 21 は廃止—LTS 中間バージョンで、本番環境で使う人が元々少ない。

プロジェクトがまだ Node.js 16 なら、アップグレード時。Node.js 18 の最低サポートバージョンは 18.18.0、このバージョンは Vite 依存の新機能を導入。

移行で注意する点：

• resolve.conditions のデフォルト値が変わった。['module', 'browser', 'jsnext:main', 'jsnext'] から ['module', 'browser', 'jsnext:main', 'jsnext', 'import'] に。手動設定していたなら調整が必要。
• 非標準環境（Deno、Bun）を使っているなら、明示的に resolve.conditions を指定する必要がある。

正直、多くのプロジェクトは Vite 6 にアップグレードするのはバージョン番号を変えるだけ。3つのプロジェクトで試した、全部 npm install vite@latest 一行で完了。

1.3 その他重要変更

Environment API 以外、Vite 6 には注目すべき変更がある：

Sass モダン API デフォルト有効。以前 Vite は Sass のレガシー API を使っていたが、今はモダン API がデフォルト。Sass コンパイルエラーなら、設定で無効化できる：

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        api: 'legacy' // モダン API に問題あれば、レガシーにフォールバック
      }
    }
  }
})

JSON stringify 改善。Vite は JSON ファイル内容を自動検出—全体が静的オブジェクトなら、JSON.stringify() で事前処理。これでバンドルサイズが減る、特に大型 JSON 設定ファイル。

Worker オプション変更。worker.format のデフォルト値が 'iife' から 'es' に変更、ESM 形式の Worker を出力。この変更で Worker と主コードのモジュールシステムが一致。

これらの変更は日常開発に大きな影響はない。でも Sass は注意—カスタム Sass 関数でエラーが出たプロジェクトがあった、半日折腾して API バージョンの問題だと発見。

第二章：Rolldown 統合とパフォーマンス飛躍

2.1 なぜ Vite は Rolldown を必要とする

頭痛いことを先に言う：Vite 5 は開発環境で esbuild、本番環境で Rollup を使う。二つの異なるバンドラー。

これはどういうこと？開発環境は速い—esbuild は Go で書かれ、コンパイル速度は JavaScript ツールを圧倒。でも本番環境は Rollup に切り替え—JavaScript で書かれたバンドラー、かなり遅い。

さらに厄介なのはプラグインシステム。esbuild のプラグイン API は Rollup と完全に違う。開発環境で書いたプラグインが本番環境で動かない可能性。逆も同じ。この不一致がデバッグを痛苦にする—開発環境は問題ないのに、ビルドで爆発。

Rolldown はこの問題を解決。

Rolldown とは？Rust で書かれた Rollup 代替品、Rollup のプラグイン API と互換、でも速度は Rollup の10-30倍高速（ソース：Rolldown 公式 benchmarks）。esbuild レベルのコンパイル速度も。

Vite チームの計画：Rolldown が Rollup を代替、本番環境のバンドラーロジックを統一。これで開発と本番は同じプラグインシステムを使い、「開発正常、本番爆発」問題が消失。

2.2 Rolldown パフォーマンスデータ比較

データは口で言うより管用。Vite 8 Beta 公告で多数のケースを晒した：

プロジェクト	ビルド時間変化	備考
Linear	46s → 6s	87% 向上、公式ブログで直接点名
Ramp	57% 減少	大型 monorepo プロジェクト
Mercedes-Benz.io	38% 減少	企業級サイト
Beehiiv	64% 減少	コンテンツプラットフォーム

これらのデータは Vite 8 Beta 公式ブログから。

Vite 8 Beta は Full Bundle Mode の予期メリットも公布：

• 開発サーバー起動が3倍高速
• 全ページ刷新が40%高速
• ネットワークリクエストが10倍減少

Full Bundle Mode とは？簡単に言えば、開発環境もバンドラーでパッケージ、「ファイル一つリクエスト、一つコンパイル」のモードではない。メリット：起動と刷新がより高速。デメリット：初回起動は少し遅い可能性（プロジェクト全体をパッケージするため）。

正直、これらの数字は見て吓人的。10倍？30倍？でも自分のプロジェクトで実測、3000+ ファイルの monorepo で、Vite 5 ビルドは90秒、Rolldown 後は12秒に低下。大体7倍。10倍に届かないが、惊喜も。

2.3 Rolldown を有効化する方法（rolldown-vite）

今 Rolldown を使う二つの方法：

方法一：rolldown-vite パッケージ

vite パッケージを rolldown-vite に直接代替：

// package.json
{
  "dependencies": {
    "rolldown-vite": "latest"
  }
}

そして vite.config.ts で有効化：

export default defineConfig({
  build: {
    rolldown: true
  }
})

この方法は快速試したいプロジェクトに適合。rolldown-vite は自動で Rollup を Rolldown に代替、プラグイン互換性は大体問題ない。

方法二：Vite 8 正式版を待つ

Vite 8 Beta はデフォルトで Rolldown 統合。正式版発売後、直接アップグレード：

npm install vite@8

Vite 8 はまだ Beta（2025年12月時点）。本番プロジェクトは正式版を待つべき、またはテストプロジェクトで rolldown-vite を試す。

公式移行パス推奨：

1. 先に rolldown-vite でテスト、プラグイン互換性を確保
2. 問題なければ、Vite 8 正式版発売時に直接アップグレード
3. プラグイン互換性問題あれば、一時 Rolldown を無効化、伝統的 Rollup を使用

2.4 advancedChunks が manualChunks を代替

Rolldown は新しいチャンク戦略を導入：advancedChunks。これは Rollup の manualChunks より遥かに灵活。

先に Rollup の manualChunks の書き方を見て：

// Rollup manualChunks（旧方法）
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'vendor': ['react', 'react-dom', 'lodash'],
          'utils': ['axios', 'dayjs']
        }
      }
    }
  }
})

この書き方は問題がある：各パッケージがどのチャンクに属するか手動で指定必要。新依存を追加、書き忘れ、主バンドルに塞がれる可能性。

Rolldown の advancedChunks はグループ概念を使用：

// Rolldown advancedChunks（新方法）
export default defineConfig({
  build: {
    advancedChunks: {
      groups: [
        {
          name: 'vendor-react',
          test: /react|react-dom/,
          priority: 10
        },
        {
          name: 'vendor-utils',
          test: /lodash|axios|dayjs/,
          priority: 5
        },
        {
          name: 'vendor-shared',
          test: /[\\/]node_modules[\\/]/,
          priority: 1
        }
      ]
    }
  }
})

優先度が高いグループが先にマッチ。マッチしないのはフォールバック（最後のキャッチオールグループ）。メリット：新依存を追加するたびに設定を変更不要、正規表現が自動マッチ。

もう一つの興味深い機能：advancedChunks は重複依存を検出。二つのチャンクが同じパッケージを参照すれば、自動的にそのパッケージを共有チャンクに抽出。これは monorepo に特に有用—各サブプロジェクトが同じ基礎ライブラリを参照、以前は手動処理、今は自動。

第三章：ESM モジュールフェデレーションの進展

3.1 コミュニティ方案：vite-plugin-federation

Module Federation は Webpack 5 の看板機能。多チーム協作の大型プロジェクトで、異なるモジュールを独立「フェデレーション」にパッケージ、互いに相手のコードを参照。Cool に聞くが、Vite はネイティブでサポートしない。

コミュニティはどう解決？vite-plugin-federation。このプラグインは GitHub で3000+ stars、最も成熟した Vite モジュールフェデレーション方案。

設定方法は Webpack と大体同じ：

// vite.config.ts - Host アプリ
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    federation({
      name: 'host-app',
      remotes: {
        remoteApp: 'http://localhost:5001/assets/remoteEntry.js'
      },
      shared: ['react', 'react-dom']
    })
  ]
})

// vite.config.ts - Remote アプリ
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    federation({
      name: 'remote-app',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button',
        './Header': './src/components/Header'
      },
      shared: ['react', 'react-dom']
    })
  ]
})

Host アプリは remotes で Remote モジュールを参照、Remote アプリは exposes でモジュールを導出。shared は基礎依存を共有、重複パッケージを回避。

この方案のメリット：

• Webpack Module Federation と互換、Webpack プロジェクトと相互操作可能
• 設定が簡単、概念は Webpack と一致
• コミュニティが成熟、実戦ケースが多い

デメリットも明確：

• Vite ネイティブ機能ではない、プラグインに互換性問題がある可能性
• 本番環境パッケージ時は Rollup を使う、Webpack のパッケージロジックと完全一致しない
• デバッグが複雑、クロスプロジェクト参照エラーの定位が困難

3.2 Rolldown ネイティブ Module Federation

好消息：Rolldown はネイティブ Module Federation サポートを実装中。

現在サンプルリポジトリ rolldown-vite-module-federation-example があり、Rolldown でモジュールフェデレーションを使う方法を展示。でもまだ RC ステージ、本番推奨しない。

Rolldown のネイティブ方案はいくつかのアドバンテージ：

• Webpack 5 の Module Federation API と完全互換
• パッケージロジックが統一、Vite と Webpack の間で切り替え不要
• パフォーマンスがより良い、Rolldown 自体が Rollup より高速

設定方法はまだ進展中、現在は大体こう：

// Rolldown Module Federation（RC 版）
export default defineConfig({
  build: {
    moduleFederation: {
      name: 'host-app',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:5001/remoteEntry.js'
      },
      exposes: {
        './Component': './src/Component.tsx'
      },
      shared: {
        react: { singleton: true },
        reactDom: { singleton: true }
      }
    }
  }
})

構文は vite-plugin-federation と類似、でも Webpack の規範に近い。singleton: true は一つのバージョンのみロードを確保、バージョン衝突を回避。

3.3 方案選択建议

今モジュールフェデレーションを使うなら、どの方案？

本番プロジェクト：vite-plugin-federation を推奨。

理由は簡単：安定。3000+ stars は多くのチームが使用、坑は踩済み。問題あればコミュニティで解決策を見つける。

新プロジェクトまたは実験プロジェクト：Rolldown ネイティブ方案を試すことができる。

Rolldown を既に使っている、またはプロジェクトがまだ上线していないなら、尝鲜可能。でも随时回退準備必要—RC 版の API は変わる可能性。

Webpack プロジェクトと相互操作：二つの方案都可以。

vite-plugin-federation 自体が Webpack 互換設計。Rolldown のネイティブ方案も Webpack 5 互換性を承诺。

话说回来、モジュールフェデレーションは万能薬ではない。多チーム協作の大型プロジェクト、独立デプロイ必要なマイクロフロントエンドアーキテクチャに適合。通常プロジェクトで使うと複雑度を増加—フェデレーション境界を維持、バージョン依存を协调、クロスプロジェクト参照問題をデバッグ必要。

プロジェクトがそれほど複雑でなければ、モジュールフェデレーションを急ぐ必要はない。簡単な monorepo、npm パッケージ共有で十分かもしれない。

第四章：パフォーマンス最適化ベストプラクティス

Vite 6 自体は既に速い。でも大規模プロジェクトを管理しているなら—数千ファイル、数十依存—まだ最適化手法がある。

4.1 高頻度ファイルの warmup

Vite 開発サーバー起動時、常用ファイルを事前 warming。デフォルトは入口ファイルとその依存。でも手動で指定できる：

export default defineConfig({
  server: {
    warmup: {
      clientFiles: [
        './src/main.tsx',
        './src/pages/Home.tsx',
        './src/pages/Dashboard.tsx'
      ]
    }
  }
})

warmup のメリット：ブラウザを開く前にこれらのファイルがコンパイル済み。初回アクセス時に明確な遅延がない。

どのファイルを warmup すべき？

• 入口ファイル（Vite はデフォルトで処理）
• 高頻度アクセスのページコンポーネント
• 大型依存ライブラリの入口（例：lodash-es）

warmup は多すぎないように。warmup ファイルが多すぎると起動時間が増加。最もよく使う 5-10 ファイルを warmup 推奨。

4.2 Barrel Files を回避

Barrel Files とは？一堆のモジュールを再導出するファイル：

// ❌ Barrel File - こうしない
export { Button } from './Button'
export { Input } from './Input'
export { Modal } from './Modal'
export { Table } from './Table'

整潔に見える、一つの import で全コンポーネントを取得：

import { Button, Input, Modal } from './components'

でも Vite はこの種のファイルを笨笨処理：先に barrel file 全体をロード、然后導出モジュールを逐次ロード。これが滝式リクエストチェーンを形成—一つのリクエストが次を触发、さらに次を触发。

大型プロジェクトの barrel file は数十モジュールを導出可能、滝流で数秒遅延。

正しい方法は直接導入：

// ✅ 直接導入
import Button from './components/Button'
import Input from './components/Input'

Vite はこれらの独立モジュールを并行ロード可能。滝流なし、速度が明確に高速。

barrel file でコード整潔を維持したいなら、Rolldown の Full Bundle Mode を考慮。バンドルモードでは、滝流問題が消解—全モジュールが単一ファイルにパッケージ、リクエストチェーンなし。

4.3 Resolve 操作を削減

Vite は import ステートメントを処理するたび、resolve を実行：ファイルの実際パスを見つける。これには node_modules のチェック、各種拡張子の試行、パス别名の処理が含ま。

resolve 回数を減らすことで、コンパイル速度が向上。

拡張子を明示的に書く：

// ❌ 暗黙拡張子
import Button from './components/Button'

// ✅ 明示拡張子
import Button from './components/Button.tsx'

明示拡張子なら、Vite は .ts、.tsx、.js、.jsx 各種可能性を試行不要。

パス别名を減らす：

// vite.config.ts
export default defineConfig({
  resolve: {
    alias: {
      '@': '/src',
      '@components': '/src/components',
      '@utils': '/src/utils',
      '@hooks': '/src/hooks',
      '@api': '/src/api'
    }
  }
})

各别名は resolve の工作量を増加。主要な别名（例：@）一つ二つを維持推奨、他は相対パスを使用。

4.4 ネイティブプラグインと Oxc Transform

Vite 6 はネイティブプラグインサポートを導入。Rust で書かれたプラグインは JavaScript プラグインより遥かに高速。

有効化方法：

export default defineConfig({
  experimental: {
    enableNativePlugin: true
  }
})

でもこの機能はまだ実験ステージ、多くのプラグインはネイティブモード未サポート。

もう一つ注目すべきは Oxc Transform。Oxc は Rust で書かれた JavaScript/TypeScript コンパイルツールチェーン。@vitejs/plugin-react v5+ はデフォルトで Oxc の transform を使用、Babel よりかなり高速。

React プラグインを使っているなら、v5+ にアップグレード確保：

{
  "dependencies": {
    "@vitejs/plugin-react": "^5.0.0"
  }
}

Oxc の transform は全 Babel 特性をサポートしない（例：カスタム Babel プラグイン）。特殊な Babel 設定があるなら、プラグインで明示的に Babel を有効化必要：

import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [
    react({
      babel: {
        // Babel を強制使用
        plugins: ['your-babel-plugin']
      }
    })
  ]
})

結論

这么多言った、核心はいくつかの事：

Environment API は Vite のアーキテクチャを変え、でも通常プロジェクトへの影響は有限。主にフレームワーク作者がメリット、間接的により多くのデプロイ選択を提供。

Rolldown は本当のパフォーマンス飛躍。10倍以上のビルド加速、統一プラグインシステム、開発本番一致性—これらは实实在在の改善。Linear の46秒から6秒は吹きではない。

ESM モジュールフェデレーション はまだ進展中。コミュニティ方案は成熟使用可能、公式方案はまだ RC。マイクロフロントエンドシナリオは先に vite-plugin-federation を使用、Rolldown 方案が安定してから切り替え。

パフォーマンス最適化 の核心は滝流削減、高頻度ファイル warmup、resolve 操作削減。Rolldown の Full Bundle Mode は多くの最適化戦略を変える—バンドルモードでは、これらの問題がバンドラーで自動処理。

移行建议：

• 本番プロジェクト：先に rolldown-vite で互換性テスト、問題なければ Vite 8 正式版発売時にアップグレード
• 新プロジェクト：直接 Vite 8 Beta に、Rolldown パフォーマンスメリットを享受
• マイクロフロントエンドプロジェクト：vite-plugin-federation を使用、Rolldown ネイティブ方案が安定するまで待つ

Vite のツールチェーンは快速進展中。esbuild + Rollup デュアルバンドラーから統一 Rolldown、Webpack 互換モジュールフェデレーションからネイティブサポート—これらはフロントエンド基建の重要変化。関心を維持、適時アップグレード、プロジェクトはより高速、より安定に動作。

FAQ

Vite 6 の Environment API は通常プロジェクトにどう影響？

直接的影響は有限。Environment API は主にフレームワーク作者向け、Nuxt、Astro などが Cloudflare Workers、Deno などのエッジ環境をよりエレガントにサポート可能。通常 SPA/MPA プロジェクトの設定は変わらず、Vite は後方互換性を維持。間接メリット：より多くのデプロイ選択が可能。

Rolldown は本当にビルドを10倍高速化？

実測データはこの说法を支持。Vite 8 Beta 公告で Linear プロジェクトが46秒から6秒に（87%向上）。3000+ ファイルの monorepo で実測は7倍向上。パフォーマンスメリットはプロジェクト規模に依存—大きいほど明確。

今モジュールフェデレーションを使うなら、どの方案？

本番プロジェクトは vite-plugin-federation を推奨（3000+ stars、安定成熟）。新プロジェクトは Rolldown ネイティブ方案を尝鲜可能（RC ステージ）。二つの方案は Webpack 5 と互換、Webpack プロジェクトと相互操作可能。

Vite 6 にアップグレードする注意点？

主に三点：1）Node.js バージョンは 18.18.0+ 必要；2）resolve.conditions デフォルト値が変わった、手動設定はチェック必要；3）Sass モダン API がデフォルト有効、カスタム関数はエラー可能性。多くのプロジェクトはバージョン番号を変えるだけ。

Vite 6 の実用パフォーマンス最適化技巧？

核心四招：高頻度ファイル warmup（warmup 設定）、Barrel Files 回避（直接導入）、拡張子を明示（resolve 削減）、React プラグインを v5+ にアップグレード（Oxc transform 使用）。Rolldown の Full Bundle Mode は滝流問題を自動処理。

いつ Module Federation を使うべき？

多チーム協作の大型プロジェクト、独立デプロイ必要なマイクロフロントエンドアーキテクチャに適合。通常プロジェクトでモジュールフェデレーションを使うと複雑度を増加—バージョン依存を协调、フェデレーション境界を維持必要。簡単な monorepo または npm パッケージ共有で十分かもしれない。

8 min read · 公開日: 2026年4月18日 · 更新日: 2026年4月18日