Vite 8 × Rolldown 移行可否を3分で判定

TL;DR

• Vite 8 は 2026-03-12 に GA。Rolldown が 完全 default で同梱され、esbuild と Rollup は直接依存から外れた（公式 announcement）
• ビルドは Rollup 比で 10-30 倍速い（公式値）。Linear は 46s→6s、Beehiiv は 64% 削減の実例も公開ずみ
• ただし内蔵の Rolldown 自体は v1.0.0-rc.18（RC）。Vite 8 自体は GA でも、バンドラ層は「半 GA」状態
• 本記事は移行可否を Yes / No / Defer の3分岐で判定する。記事末尾に PR テンプレ＋ CI ガード GitHub Actions snippet を配布する

シリーズ記事一覧

本記事は「フロントエンドスタック2026（frontend-stack-2026）」シリーズの親記事です。スタック構成判断の各論は以下の子記事で解説しています。

1. Edge Functions採用の判断軸とアンチパターン
2. RSCとClient境界の引き方 ── 迷わない4軸判定
3. フロント性能改善の正しい順序: LCP→INP→CLS
4. WebGPU実用化の現在地と落とし穴
5. Next.js Cache Components移行設計

はじめに ── 「Vite 8 に上げるべきか」を3分で決める

こんにちは、みねです。

Vite 7 で本番運用しているチームから、ここ1ヶ月で同じ質問を何度も受けた。「Vite 8 はもう上げて大丈夫？」「Rolldown 一本化って、自社の独自プラグインは動く？」「CI 時間は本当に縮む？」。

率直に言うと、Vite 8 自体は GA 済みだが、内蔵の Rolldown はまだ RC である。この 「Vite 8 GA / Rolldown RC」の半 GA 状態 をどう読むかで、移行判断が割れる。

本記事は、リリース解説ではなく「移行可否の意思決定支援」として書く。読了後すぐに Yes（今すぐ移行）/ No（移行非推奨）/ Defer（様子見） の3分岐で自社プロジェクトを判定し、必要なら PoC PR を1日で出せる状態にして帰ってもらう。

数値断言はすべて公式公表値に出典 URL を付け、自社実測は条件 A の小規模 PoC 設計例として 「再現プロトコル」 を含めて開示する。読者が自プロジェクトで同条件を回せるよう、計測スクリプトと判定ラインも §6-2 で配布する。

なお、ビルド層の高速化は AI 駆動開発との相性が良い。試行回数が増えるエージェント運用では、ビルド時間がボトルネックを直接決める。詳しくは AIペアプロが失敗する理由 に書いたが、本記事は「ビルド層を Rolldown に統一すれば AI エージェントの試行コストも下がる」という上位レイヤーの意味づけまで含めて整理する。

1. 結論：3つのケースで判断する Vite 8 移行可否

1-1. 「今すぐ移行（Yes）」が正解になるチーム

以下のいずれかに当てはまるなら、Vite 8 への移行は 今すぐ着手して良い。

• CI のビルドステップが2分を超える（GitHub Actions の pnpm build が常時2分超）
• モノレポで vite build を5回以上並列実行している（apps/* / packages/* の数が多い）
• @vitejs/plugin-react / @vitejs/plugin-vue / @vitejs/plugin-svelte の標準セットしか使っていない
• Node.js 20.19+ または 22.12+ で動いている（Vite 7 と同条件）
• AI コーディングエージェント（Copilot / Claude Code 等）で1日10回以上の build/test ループを回している

理由はシンプルで、Rolldown 一本化の恩恵が ビルド時間として直接効く ケースだからだ。公式は Rollup 比で 10-30 倍速いと公表しており、Linear（46s→6s）/ Beehiiv（64% 削減）の実例もある（announcing-vite8）。

1-2. 「様子見（Defer）」が正解になるチーム

以下に当てはまるなら、2026 年 6〜7 月（Rolldown 1.0 GA 後）まで Defer が妥当。

• 独自 Vite プラグインが3本以上ある（特に CSS-in-JS / SVG 仮想モジュール / SSR 関連）
• mangleProps / reserveProps / mangleQuoted 等の esbuild 固有オプションを vite.config.ts で使っている（Oxc Minifier 未対応、追跡: oxc#15375）
• TypeScript の native decorator を使っている（Oxc 未対応、追跡: oxc#9170）
• esbuild.supported で意図的に古いブラウザにフォールバックさせている（Oxc 未対応、追跡: oxc#15373）
• 本番 SSR 構成を運用していて、ロールバック窓を確保しづらい

Defer 判定でも、後述の rolldown-vite パッケージ経由で Vite 7 のまま Rolldown だけ先行検証 する道は残る。これだけは今のうちにやっておく価値がある（migration guide の Gradual Migration 節）。

1-3. 「移行非推奨（No）」になるレアケース

数は少ないが、以下のケースは Vite 8 を現時点で採用しないほうが安全だ。

• Node.js 18 系で固定運用している（Vite 8 は 20.19+ / 22.12+ 必須、Vite 7 と同条件のため Vite 7 でも上げる必要あり）
• Rollup 古プラグイン（v3 以前）に強依存している（Rolldown は Rollup 互換 API を持つが、内部実装に踏み込んだプラグインは要再検証）
• Property mangling を本番ビルドの最適化として必須にしている（Oxc Minifier 未対応、Lightning CSS 移行も別途必要）

ただしこの「No」はほぼ全て 「Defer の上位互換」 で、根本対応（プラグイン書き換え / Node アップグレード）が済めば Yes に昇格できる。

1-4. 判断フローチャート

flowchart TD
    A[Vite 7 で本番運用中] --> B{Node.js 20.19+ or 22.12+?}
    B -- No --> N1[No: まず Node を上げる]
    B -- Yes --> C{独自 Vite plugin 3本以上?}
    C -- No --> D{CI build > 2分 or モノレポ?}
    C -- Yes --> E{native decorator / mangleProps 使用?}
    E -- Yes --> N2[No: Rolldown 1.0 GA 後に再検討]
    E -- No --> F[Defer: rolldown-vite で先行検証]
    D -- Yes --> Y1[Yes: 今すぐ移行 PoC]
    D -- No --> F

✅ チェックリスト §6-1 で自己診断する → §6

2. Vite 8 で何が変わったのか：Vite 7 からの差分整理

2-1. Rolldown 一本化（esbuild + Rollup → Rolldown）の意味

Vite 7 までは2つのバンドラを併用していた。dev 中の依存事前バンドル・TS/JSX 変換は esbuild、本番ビルドは Rollup。この二本立ては「DX とパフォーマンスの両立」として機能してきたが、欠点もあった ── プラグイン API が2系統あり、両者の挙動差を埋める glue code が増え続けたのだ（公式 announcement: The problem 節）。

Vite 8 では Rust 製の Rolldown が単一バンドラ として両方の役割を担う。esbuild は optionalDependencies として残置されており、build.minify: 'esbuild' 等の deprecated 互換オプションを使う場合に限り devDependency として追加インストールが必要になる。Rollup も npm 直接依存からは外れた。

// Vite 7 までの mental model
//   dev: esbuild
//   build: Rollup
//
// Vite 8 から
//   dev/build: Rolldown （単一）
//   minify(JS): Oxc Minifier
//   minify(CSS): Lightning CSS

2-2. プラグイン API / 環境 API の変更点

公式は 「Most existing Vite plugins work out of the box with Vite 8」「supports the same plugin API as Rollup and Vite」 と明言している（公式 announcement: Compatibility 節）。標準プラグイン群は基本そのまま動く。

ただし以下は deprecated → 自動変換層あり の挙動になる（migration guide）。

加えて、vite-tsconfig-paths プラグインを検知すると warning が出るようになった（CHANGELOG v8.0.0）。組み込みの resolve.tsconfigPaths: true への移行が公式推奨だ。

// vite.config.ts （Vite 8 推奨）
import { defineConfig } from 'vite'

export default defineConfig({
  resolve: {
    tsconfigPaths: true, // 組み込み、外部プラグイン不要
  },
})

Environment API（vite.environment 経由の SSR/Workers 統合 API）は引き続き experimental 段階だが、Vite 8 で安定化に向けて作業中とアナウンスされている（Looking Ahead 節）。本番運用では Stable 化まで様子見が無難。

2-3. Node.js 最低バージョン・対応ブラウザ

Node 要件は変わらない（v8.0.0 package.json: engines.node 確認）。require(esm) 無フラグ動作のための条件で、Vite 7 から続く制約だ。

ブラウザ target は 2026-01-01 時点の Baseline Widely Available に更新されており、概ね2年半前にリリースされたバージョン群となる。レガシーブラウザ対応が必要なら @vitejs/plugin-legacy の併用は引き続き必要。

2-4. 破壊的変更チェックリスト（一次ソース URL 付き）

執筆時点（2026-05-01、Vite 8.0.10 ベース）で 公式 migration guide が明示している主要 breaking を整理する。

• Rolldown 一本化 — esbuild/Rollup 直接依存除外（migration: Rolldown 節）
• optimizeDeps.esbuildOptions → rolldownOptions（自動変換、deprecated）
• esbuild top-level → oxc（自動変換、deprecated）
• JS minify が Oxc Minifier 化、mangleProps 系未対応（oxc#15375）
• esbuild.supported 未対応（Oxc 側、oxc#15373）
• native decorator lowering 未対応（Oxc 側、oxc#9170。Babel または SWC で workaround）
• CSS minify が Lightning CSS デフォルト化（build.cssMinify: 'esbuild' で旧挙動に戻せる）
• CommonJS interop ルール統一（default import の解釈が条件分岐から決定論的に）
• browser / module フィールドの heuristic 解決廃止（exports フィールド優先）
• transformWithEsbuild deprecated → transformWithOxc 推奨
• vite-tsconfig-paths 検知時 warning → 組み込み resolve.tsconfigPaths 推奨

✅ §6-1 のチェックリストでは、これら全項目を Issue テンプレ化済み。

3. Rolldown 一本化のメリット：何が「実際に」速くなるのか

3-1. dev / build / HMR それぞれの効き方

公式公表値（announcing-vite8 より）。

「○倍速い」系の数値は読者の期待と現実がズレやすい。dev サーバーの起動時間そのもの は Vite 7 でも esbuild ベースで十分速かったため、体感差は小さい場面もある。Rolldown 一本化の最大の恩恵は 本番ビルド と 増分ビルド/CI 連続実行時 だと理解しておくと判断を誤らない。

3-2. PoC 設計例：ベンチ測定プロトコル（条件 A）

リアル計測の値だけ並べても読者の自プロジェクトでは再現できない。代わりに PoC 設計例（条件 A） として、小規模1ケースの計測プロトコルを開示する。読者が同条件で自プロジェクトを回せば、自社の数値が出る雛形として使える。

条件 A（小規模 SPA 想定）

# 計測スクリプト（再現プロトコル）
#!/usr/bin/env bash
set -euo pipefail
rm -rf node_modules/.vite dist
for i in 1 2 3; do
  /usr/bin/time -f "run=$i wall=%e user=%U sys=%S" pnpm build 2>&1 | tail -1
done

⚠️ 上記はあくまで PoC 設計例 であり、自社全プロジェクトに一般化できる数値ではない。読者は同スクリプトを自プロジェクトで回し、規模・依存数・キャッシュ前提を research-notes.md 等に併記してから判断してほしい。一般化数値は §3-1 の公式公表値（10-30倍、Linear 46s→6s 等）を参照。

3-3. CI 時間への波及（GitHub Actions 実測例）

公式が公表している大規模プロジェクトの実例（announcing-vite8: Real-world performance より）。

CI 全体の所要時間は build 以外（test / lint / deploy）も含むため、build フェーズの 50-90% 削減が CI 全体に効くかは CI ジョブ構成次第。並列化されている場合は build がクリティカルパスから外れている可能性もある。詳しくは CI/CD 高速化の打ち手 で整理した。

3-4. バンドルサイズ・tree-shaking の差分

Rolldown は Oxc の semantic analysis を活用した tree-shaking を行う。公式は「より積極的な dead code elimination」を強調しているが、実プロジェクトでのサイズ差分は ±数 KB のオーダー に収まることが多い。

注意点として Lightning CSS デフォルト化により CSS バンドルサイズがやや増える ことがある（公式 migration guide「Lightning CSS supports better syntax lowering and your CSS bundle size might increase slightly」）。これは syntax lowering が広く効くトレードオフで、対応ブラウザを絞れば回避できる。

4. Rolldown 一本化のデメリット・温存される痛み

4-1. プラグイン互換：壊れがちなカテゴリ

「Most plugins work out of the box」とはいえ、壊れがちなカテゴリは存在する。執筆時点（2026-05-01）で報告例の多い順に整理する。

@vitejs/plugin-react は v6 同時リリース（announcement）で Babel 依存を除いた。React Compiler が必要な場合は v6 の reactCompilerPreset ヘルパー + @rolldown/plugin-babel で opt-in 可能。v5 のまま Vite 8 でも動くが、Babel の installation size を気にするチームは v6 への移行も検討対象。

4-2. minify / sourcemap の挙動差分

JS minify は Oxc Minifier、CSS minify は Lightning CSS がデフォルトだ。それぞれ esbuild とは前提が微妙に違うので、本番ビルド差分が出たら 以下の比較ドキュメントで確認 する習慣を付けたい。

• esbuild minify assumptions
• Oxc Minifier assumptions

sourcemap については Rolldown 側で改善が続いているが、source position が esbuild 出力と微妙にズレるケース があり、Sentry 等のエラートラッキング上で stack trace の解像度が変わる場合がある。本番投入前に Sentry 側の dSYM/sourcemap upload を再検証しておくと安全だ。

4-3. エコシステムの成熟度（Stable プラグイン vs preview 段階）

Vite 公式が運営する registry.vite.dev が 2026-03 と同時公開されており、Vite / Rolldown / Rollup 対応プラグインを横断検索できる。プラグイン互換 audit はここを起点にすると速い。

ただし「Vite 8 対応」のラベルは作者の自己申告ベースのため、実プロジェクトで動作確認するまで信用しすぎない こと。本記事 §5-3 の plugin compatibility matrix を作る運用がここで効いてくる。

4-4. 「Rolldown ならではのバグ」を踏んだときのデバッグ手順

Rolldown 起因と思われる挙動を踏んだら、以下の順で切り分ける。

1. build.minify: false で minify を切る ── 出力差分が消えれば Oxc Minifier が原因
2. vite.config.ts で oxc: false にする（→ JS transform を最小化）
3. npm:[email protected] に切り替えて Vite 7 ベースで再現させる ── Vite 8 自体の breaking と Rolldown の breaking を切り分けられる
4. 再現最小ケースを GitHub に push して vitejs/vite または rolldown/rolldown に Issue を立てる

特にステップ3は重要だ。「Vite 8 のアップグレードと Rolldown 起因の問題を分離できるかどうか」 が、debugging speed を1桁分けるからだ。

4-5. Rolldown 1.0 GA までの移行期リスク

Vite 8 自体は GA だが、内蔵の Rolldown は v1.0.0-rc.18（2026-04-29） とまだ RC である。Vite 8.0.10 は内部で [email protected] を pin している。

// [email protected] の package.json から抜粋
{
  "dependencies": {
    "rolldown": "1.0.0-rc.17"
  }
}

これは 「Vite 8 自体は安定版、しかし内蔵バンドラの Rolldown は依然として RC」 という二段構えの状態を意味する。Vite 側のパッチ更新で Rolldown も追従するが、Rolldown 側の breaking change が Vite minor バージョンで降ってくる可能性は残る。

production 採用は OK だが、以下を運用ルールにしておくと安全だ。

• package.json の vite バージョンを patch 含めて pin（"vite": "8.0.10" のように ^ を付けない期間を1ヶ月設ける）
• pnpm update vite の前に必ず Rolldown release notes を確認（rolldown/rolldown releases）
• Rolldown 1.0 GA（時期未定、2026 Q3 予想）後に pin を解除して通常更新運用に戻す

✅ チェックリスト §6-1 で自己診断する → §6

5. 移行手順：PoC PR から本番マージまでの実務フロー

5-1. ステップ1：rolldown-vite で feature flag PoC（既存 Vite 7 を残したまま）

公式が推奨する gradual migration path をベースにする（migration guide: Gradual Migration 節）。Vite 7 のまま Rolldown だけ先行検証すれば、Vite 8 自体の breaking と Rolldown の breaking を分離 できる。

// package.json（Vite 7 + Rolldown の中間ステップ）
{
  "devDependencies": {
    "vite": "npm:[email protected]"
  }
}

# feature branch で PoC PR を立てる
git switch -c feat/rolldown-poc
pnpm install
pnpm build
pnpm test

この段階の合格基準:

• ビルドが成功する
• 既存テストが全 PASS
• dist/ のサイズが ±10% 以内（後述 CI ガード参照）

5-2. ステップ2：CI ガード（バンドルサイズ diff / ビルド時間しきい値）

PoC PR と同じ branch で GitHub Actions に CI ガード を仕込む。バンドルサイズと build 時間の劣化を自動で検出させる。

# .github/workflows/build-perf-guard.yml
name: Build Performance Guard

on:
  pull_request:
    branches: [main]

jobs:
  guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
        with: { version: 10 }
      - uses: actions/setup-node@v4
        with: { node-version: 22.12, cache: pnpm }

      - name: Install
        run: pnpm install --frozen-lockfile

      - name: Build (timed)
        id: build
        run: |
          /usr/bin/time -f '%e' -o build.time pnpm build
          echo "wall=$(cat build.time)" >> "$GITHUB_OUTPUT"

      - name: Bundle size
        id: size
        run: |
          du -bs dist | awk '{print "bytes="$1}' >> "$GITHUB_OUTPUT"

      - name: Guard thresholds
        run: |
          WALL=${{ steps.build.outputs.wall }}
          BYTES=${{ steps.size.outputs.bytes }}
          # 例: build wall < 60s かつ bundle bytes < 5MB
          awk "BEGIN{exit !($WALL < 60 && $BYTES < 5242880)}"

      - name: Comment on PR
        uses: actions/github-script@v7
        with:
          script: |
            const wall = '${{ steps.build.outputs.wall }}';
            const bytes = '${{ steps.size.outputs.bytes }}';
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `Build wall: ${wall}s / dist bytes: ${bytes}`,
            });

判定ラインは自プロジェクトの基準値で書き換える。最初は 過去30日の中央値 ± 20% をしきい値に置くのが現実的だ。CI ガードの一般論は AI 時代の CI 品質ゲート設計 で詳述している。

5-3. ステップ3：プラグイン互換 audit

vite.config.ts の plugins 配列を全件レビューし、互換 matrix を作る。

| プラグイン | 現バージョン | Vite 8 対応版 | 検証日 | 結果 |
| --- | --- | --- | --- | --- |
| @vitejs/plugin-react | 4.3.x | v6.0.0 | 2026-05-01 | OK（Babel 不要化、bundle size -2MB） |
| vite-plugin-svgr | 4.2.x | 4.3.x | 2026-05-01 | OK |
| 自社製 X-plugin | 0.1.x | 自前更新待ち | 2026-05-01 | NG（Rollup 互換 API への準拠が不完全、要修正） |

互換 matrix は PR description に貼る運用 にすると、レビューアが互換状況を一目で把握できる。

5-4. ステップ4：本番ロールアウト＋ロールバック計画

PoC PR の合格後、本番マージは以下の順で行う。

1. stage 環境へ先行デプロイ → 24h 監視（Sentry エラー率・Web Vitals 推移）
2. 本番 5% カナリアリリース（feature flag or weighted routing）
3. 48h 安定確認後、100% ロールアウト
4. package.json の vite を patch 含め pin（§4-5 参照）

ロールバック条件は事前に文書化しておく（§6-3 で配布物として記載）。エラー率・Sentry のリリース別比較・Web Vitals（LCP/INP/CLS）の劣化が出たら即時 revert。

5-5. 落とし穴と回避策

実プロジェクトでよく踏むパターン。

• モノレポ: pnpm-workspace.yaml 配下の各 app で vite バージョンが揃っていないと、Vite 7/8 が同居してビルドが不安定になる。pnpm.overrides で root に固定するのが安全。
• SSR: vite build --ssr の出力が Vite 7 と微妙に違う場合がある。server.middlewareMode 構成のプロキシ前提が壊れていないかを必ず stage で検証。
• テスト環境: vitest は Vite に強く依存しているため、Vite 8 と vitest の互換マトリクスを必ず確認（vitest 3.x 系が Vite 8 対応の主軸）。

セキュリティ観点では、ビルド層が変わるとサプライチェーンの依存グラフが変わる。Rolldown の依存解析と Oxc の semantic analysis を本番に取り込む前に、依存監査を1回回しておくと安心だ。詳しくは AI コーディング時代のセキュリティ設計 で別途整理した。

6. Vite 8 移行チェックリスト（配布物）

6-1. リスト全文（コピペで Issue 化できる粒度）

GitHub Issue の本文に貼ってそのまま使える形で配布する。

## Vite 8 移行チェックリスト

### 前提確認
- [ ] Node.js が 20.19+ または 22.12+ で動いている
- [ ] 現行 Vite バージョン: `[email protected]`
- [ ] CI build 時間（中央値）を計測した: ___ 秒
- [ ] dist サイズ（中央値）を計測した: ___ bytes

### Yes / No / Defer 判定（§1-4 フローチャート参照）
- [ ] Yes / [ ] Defer / [ ] No のうち1つを選択
- [ ] 判定理由を1-2行で記述: ___

### 互換性チェック
- [ ] 独自 Vite plugin の数を数えた: ___ 本
- [ ] CSS-in-JS / SVG 仮想モジュール / SSR プラグインの有無を確認
- [ ] `mangleProps` 系オプション未使用を確認
- [ ] native decorator（`@deco`）未使用、または Babel/SWC で代替可能を確認
- [ ] `esbuild.supported` 未使用、または `oxc.target` で代替可能を確認

### gradual migration（推奨）
- [ ] feature branch を作成（`feat/rolldown-poc`）
- [ ] `package.json` を `"vite": "npm:[email protected]"` に変更
- [ ] `pnpm install && pnpm build && pnpm test` 全 PASS
- [ ] PR を立てて CI ガード（§6-2）を通過
- [ ] PR description に互換 matrix を貼った（§5-3）

### Vite 8 本マイグレーション
- [ ] `package.json` を `"vite": "8.0.10"` に更新（pin、`^` を付けない）
- [ ] `optimizeDeps.esbuildOptions` → `rolldownOptions` 書き換え（自動変換に頼らず）
- [ ] `esbuild` トップレベル → `oxc` 書き換え
- [ ] `transformWithEsbuild` → `transformWithOxc` 書き換え
- [ ] `vite-tsconfig-paths` 外部 plugin 削除 → `resolve.tsconfigPaths: true`

### 本番投入前
- [ ] stage 環境で 24h 監視（Sentry / Web Vitals）
- [ ] 本番 5% カナリアリリース 48h 監視
- [ ] ロールバック条件を文書化した（§6-3）
- [ ] Rolldown 1.0 GA までは `vite` バージョンを patch pin

6-2. CI ガード GitHub Actions スニペット

§5-2 のフルバージョンを .github/workflows/build-perf-guard.yml として配置。判定ラインは以下を初期値とし、過去30日の中央値が出揃った段階でチューニングする。

# 初期判定ライン（過去30日中央値が出るまで）
build_wall_seconds_max: 60       # 60秒
bundle_bytes_max: 5242880        # 5MB
bundle_diff_pct_max: 10          # 前 PR 比 +10% まで

差分ベースの判定は actions/cache で前ビルド結果を保持し、本ビルド結果と比較する形が筋が良い。

6-3. ロールバック条件と判定ライン

## Rollback 条件（いずれか1つを満たせば即時 revert）

- [ ] Sentry エラー率が前リリース比 +50% 以上で 30 分継続
- [ ] LCP（中央値）が前リリース比 +200ms 以上で 1h 継続
- [ ] INP（p75）が前リリース比 +100ms 以上で 1h 継続
- [ ] ビルド時間（CI 中央値）が前リリース比 +50% 以上で 24h 継続
- [ ] dist サイズが前リリース比 +20% 以上（緊急性は低いが要 revert 検討）

## Revert 手順
1. `git revert <Vite 8 マージコミット>`
2. `package.json` の `vite` バージョンを Vite 7 系に戻す
3. `pnpm install && pnpm build` 確認
4. PR タイトルに `[ROLLBACK]` を付与してマージ
5. Vite 7 系 stage で 24h 監視後、原因調査 Issue を立てる

✅ §6-1 のチェックリストでは、上記全項目を Issue テンプレ化済み。GitHub の .github/ISSUE_TEMPLATE/vite-8-migration.md に置けば、新規 Issue 作成時に自動で展開される。

7. よくある質問（FAQ）

7-1. Vite 8 にしないと何が困りますか？

短期的には困らない。Vite 7 もまだ active maintenance 中だ。ただし、Vite 8 系の minor 更新で入る新機能（Vite Devtools 統合、server.forwardConsole、native emitDecoratorMetadata 対応）は Vite 7 にバックポートされない。AI コーディングエージェント運用での forwardConsole（runtime client error を CLI に流す機能）は地味に効くため、エージェント駆動開発をしているチームは早めの移行価値が高い。

7-2. Rolldown は Rollup と完全互換ですか？

プラグイン API は同じ（公式: 「supports the same plugin API as Rollup and Vite」）。ただし、Rollup の内部実装に踏み込んだプラグイン（chunk graph 直接操作、内部 hook の私的呼び出し）は要再検証。標準的な transform / load / resolveId フックを使ったプラグインなら基本そのまま動く。

7-3. ビルドはどれくらい速くなりますか？

Rollup 比 10-30 倍速（公式公表値）。ただし、これは bundler 自体の処理速度であり、CI 全体の所要時間ではない。CI 全体への波及は test/lint/deploy の構成次第なので、build がクリティカルパスにあるかをまず確認するのが先。実例（公式公表）: Linear 46s→6s（87% 削減）、Beehiiv 64% 削減、Mercedes-Benz.io 最大 38% 削減。

7-4. Webpack / Rspack / Turbopack との比較は？

本記事の射程外。ざっくり: Rspack（Rust 製、Webpack 互換）と Turbopack（Rust 製、Next.js 専用）はそれぞれ独自エコシステムで、Vite 8 + Rolldown は Rollup プラグイン互換性 を最大の差別化ポイントにしている。Vue / React 系で既に Vite を運用しているなら、Rspack / Turbopack に乗り換える理由は薄い（別記事で詳細比較予定）。

7-5. AI 駆動開発との関係は？

ビルド時間は AI コーディングエージェントの試行回数を直接決める。1試行 60 秒のビルドが 6 秒になれば、1日のループ回数が10倍になる計算だ。Copilot / Claude Code 等で agentic な build/test loop を回しているチーム ほど、Rolldown 一本化の恩恵が大きい。背景は AIペアプロが失敗する理由 と AI 時代の CI 品質ゲート設計 で別途整理した。

8. まとめと次のアクション

8-1. 3行サマリ

• Vite 8 は GA、Rolldown は RC。Yes/No/Defer の3分岐で判定する
• 公式値で Rollup 比 10-30 倍速、Linear/Ramp/Beehiiv の実例も揃っている
• 本記事のチェックリスト + CI ガード + ロールバック条件をそのまま PR/Issue に貼って使える

8-2. 移行 PoC を1日で回すための最短手順

1. 午前 ── §1-4 フローチャートで自社判定（30分）+ §6-1 チェックリストを Issue 化（30分）+ feature branch で npm:[email protected] 適用（1h）
2. 午後 ── §5-2 の CI ガード GitHub Actions を導入（1h）+ §5-3 の互換 matrix を埋める（2h）+ stage デプロイ（1h）
3. 翌日 ── 24h 監視結果を見て Yes/Defer の最終判断（1h）

これで 「Vite 8 移行を1日で意思決定可能な状態」 に持ち込める。実プロジェクトのサイズ次第で多少前後するが、半日 PoC + 1日監視の合計1.5日が現実的な目安だ。

8-3. 支援が必要なら（CTA）

自社プロジェクトで Vite 8 移行 PoC を1日で回したい、CI ビルド時間の劣化を可視化したい、エージェント駆動開発のビルド層を見直したい ── いずれかに当てはまる方は、本記事のチェックリスト + 伴走支援の問い合わせを受け付けている。「自己診断 → 必要なら相談」の順で OK。

問い合わせフォームから「Vite 8 移行 PoC 支援」を希望と記入

関連: CI/CD 高速化の打ち手 / AI 時代の CI 品質ゲート設計 / Technology Radar の作り方｜30分会議テンプレ付（Vite 8 / Rolldown の Adopt / Trial 判定を月次運用に乗せるフレーム）

frontend-stack-2026 シリーズ

本記事は frontend-stack-2026 シリーズの parent として、フロントエンド技術選定の起点に位置づけられます。シリーズ child 記事:

• Edge Functions採用の判断軸とアンチパターン — エッジランタイム選定（044）
• RSCとClient境界の引き方 — RSC / Client Components 境界（050）
• フロント性能改善の正しい順序 — Core Web Vitals（031）
• WebGPU実用化の現在地と落とし穴 — GPU compute / ML inference（051）
• Next.js Cache Components移行設計 — Next.js 16 Cache Components（040）

技術選定の親記事 技術選定で後悔しないための判断基準 と運用フレーム Technology Radar の作り方 も併読推奨。

鮮度メンテ計画

• 公開日: 2026-05-01
• 最終更新: 2026-05-01
• ベンチ計測日: 2026-05-01（Vite 8.0.10、[email protected] 内蔵時点）
• 次回見直し: 2026-06-01（Vite/Rolldown ステータス再確認）+ Rolldown 1.0 GA 公表時に追記更新