こんにちは。無限に寝ている愛猫を椅子で組んだ脚の上に乗せ、尿意を我慢しながら仕事をしていたら膀胱炎になったフロントエンドチームの出戸です。
さて、2026年3月にVoidZeroからVite+ Alphaが公開されました。
今回は、ドキュメントをなぞって機能を紹介するというより、タイムリーなうちに実際に触ってみて感じたことをベースに、Viteの良さや、Vite+で少しずつ変わっていきそうだなと思ったことを言語化していこうと思います。
Vite+は、ViteやVitest、Rolldownなどをまとめて扱うunified toolchainとして紹介されています。
ランタイムやパッケージマネージャーも含めて、Web開発の入口をひとつにまとめようとしている、というのが大きな特徴です。
これを見たときに最初に思ったのは、「Vite+便利そうだな」よりも、これってViteがカバーしようとしている範囲も少しずつ広がってきてない？ということでした。
これまでのViteって、「開発サーバが速い」「HMRが軽い」「導入しやすい」みたいな文脈で語られることが多かったと思います。実際、それは本当にそうです。
Viteは以前からdev serverとbuildの中心にいる存在で、開発の土台っぽさはすでにかなりありました。
ただ、最近の動きを見ていると、その土台としての役割が、開発とビルドの中心にとどまらず、開発フロー全体も少しずつ視野に入れ始めているようにも見えます。
今回は、よくあるViteプロジェクトのコードを見ながら、次の3つを開発者目線で整理してみます。
・これまでのViteの何が良かったのか
・Vite 8で何が変わったのか
・Vite+でその変化がどこまで広がりそうか
まず、いつもの Viteプロジェクトを見てみる
たとえば、Vite + React + TypeScriptのプロジェクトって、だいたいこんなpackage.jsonから始まることが多いと思います。
{
"name": "mtmk-vite-app",
"private": true,
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview",
"lint": "eslint .",
"test": "vitest",
"typecheck": "tsc --noEmit"
}
}これを見るとわかりやすいんですが、Viteは開発とビルドの中心にはいるけど、開発全部をまとめているわけではないということです。
・開発サーバーはvite
・本番ビルドはvite build
・lintはESLint
・testはvitest
・型チェックはTypeScript
みたいに、実際の現場ではいくつかのツールをscriptでつないで使ってることが多いはずです。
これはこれで自由度も高いし、必要なものを必要なだけ足していけるのでやりやすくはあります。
ただそのぶん、プロジェクトが大きくなってくると、
・どのコマンドをどの順で回すのか
・Node.js のバージョンはどう揃えるのか
・package managerは何を使うのか
・CIでどこまでやるのか
みたいな話がじわじわ増えてきます。
vite.config.tsを見ると、Viteの良さがかなり出る
Viteの良さって、設定ファイルを見るとけっこうわかりやすいです。
最小構成なら Reactでもこれくらいで始められます。
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [react()],
})かなり薄いですよね。
この「とりあえず開発を始められる」感が、Viteの良さの１つだと思っています。
必要になったら、たとえば aliasやproxyを足していく。
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'node:path'
export default defineConfig({
plugins: [react()],
resolve: {
alias: {
'@': path.resolve(__dirname, './src'),
},
},
server: {
proxy: {
'/api': {
target: 'http://localhost:8080',
changeOrigin: true,
},
},
},
})このくらいの設定って、かなりよく見る形だと思います。
最初は軽く始めて、必要になったところだけ広げていく。
このバランスの良さが、Viteの使いやすさにつながっていたんじゃないかなと思います。
これまでのViteの良さって、結局なんだったのか
Viteの良さって雑に「速い」だけでまとめられがちなですが、もう少し具体的に話すと
フィードバックループが短いことかと思います。
UIを少し直して、すぐ画面で確認できる。
状態管理やフォームの挙動を何度も試しやすい。
ちょっと依存関係を足しても、そこまで重くない。
フロントエンドの開発は小さい修正と確認を何回も繰り返すことが多いので、このテンポの良さはかなり効きます。
だからViteが広く使われるようになった理由も、単純な速さというより、毎日の開発のリズムを崩しにくかったことが大きかったんじゃないかなと思っています。
中身の話をすると、「開発」と「本番」の分担がうまかった
もう少し技術的な話をすると、これまでのViteは「開発中の軽さ」と「本番ビルドの安定感」のバランスがかなり良いツールでした。
ざっくり言うと、
・開発時はesbuildベースで軽快に動かす
・本番ビルドはRollupでちゃんと最適化する
という分担です。
これ、かなりうまいやり方だったと思います。
開発中はとにかくテンポよく進めたい。
でも本番はちゃんと最適化したい。
Viteはそこをうまく両立していたから、「気持ちよく使えるけど現場でもちゃんと使える」ツールとして広がったんだと思います。
ただ、当然ながらこの構成にはトレードオフもあります。
開発時と本番時で別の基盤をまたぐので、内部的には少し複雑さが残るんですよね。
Vite 8では、開発時と本番時の土台を揃えにきた
上の流れを踏まえて出てきたのが Vite 8の流れです。
ここでの変化をざっくり言うと、開発中と本番ビルドで少し分かれていた土台を、Rolldownベースに揃えにきたという見方ができそうです。
これまでの Viteは、開発中はesbuild、本番ビルドはRollupという分担でした。
それに対してVite 8では、バンドラの中心をRolldownに寄せる方向に進んでいます。
変化が見えやすいところでいうと、依存関係の最適化もRolldownベースに寄っています。
さらにplugin APIも、devとbuildの両方でより一貫して扱いやすい方向に進んでいます。
なのでVite 8の変化は、単にbuildが速くなったというより、Vite全体の基盤をより一貫して扱いやすくする方向の変化として見るとわかりやすい気がします。
Vite 8がやっているのは、まずVite自体の基盤を揃えることです。
そのうえでVite+は、その整理を開発フロー全体にも広げようとしているように見えます。
そこにVite+が何を足してきたのか
上記の流れを踏まえると、Vite+ Alphaは、Viteを単純に“強化したもの”というより、Viteを中心にしながら開発全体の入口をまとめようとする試みとして見るとしっくりきます。
たとえば、今のViteプロジェクトだと package.jsonのscriptsはこんな感じで増えていきます。
{
"scripts": {
"dev": "vite",
"build": "vite build",
"lint": "eslint .",
"test": "vitest",
"typecheck": "tsc --noEmit"
}
}これに対して、Vite+が見せている方向はかなりシンプルです。
vp dev
vp check
vp test
vp build
vp runもちろん、既存プロジェクトをそのまま一瞬で置き換えられる、みたいな話ではないです。
でも方向性としてはすごくわかりやすいです。
今まで分散していた、開発・静的解析・テスト・ビルド・タスク実行みたいな入口を、少しずつまとめようとしている。
Vite+の良さは、たぶんそこにあるんだと思います。
少し触ってみると、思ったより「Viteの延長線上」だった
ここは実際に少し触ってみた印象としてかなりViteの延長線上でした。
devやbuildまわりは、「今までの Viteの体験をベースにしながら、周辺の作業もまとめていく」という見え方が強いです。
完全に新しい考え方を持ち込むというより、今あるViteの使いやすさをそのまま広げていく感覚に近いです。
これは個人的にかなり好印象でした。
まったく別物になると、そのぶん学習コストも上がるので、既存のViteユーザーが入りやすそうなのはいいなと感じました。
特にわかりやすかったのはcheck 系です。
今のプロジェクトって、静的解析まわりがlint、typecheck、場合によってはformat:checkみたいに増えがちだと思います。
そこを「まずこれを回せばいい」と寄せていく方向には、かなり納得感がありました。
ただ、今の段階ではまだ “すぐ全部置き換える” というより、あくまでAlphaという印象もあります。
既存のプロジェクトはすでにNode.js の管理方法/package manager/ESLint,Prettier/CIフロー/monorepoのtask runnerみたいなものが固まっていることも多いので、すぐ全面移行というより、まず流れを見る段階かなと思いました。
正直、今の時点で「これだけで全部いけそう」とまではまだ言えません。
ただ、少し触っただけでも、Vite がこれから何をまとめようとしているのか はかなり見えやすくなった気がします。
これから Viteはどう見られていきそうか
Vite+がこのまま育っていくと、Viteの評価軸も少し変わっていきそうです。
今までは、
・Viteは速い
・webpackより軽い
・導入しやすい
みたいな話が中心だったと思います。
でも、Vite 8やVite+ Alphaの流れを見ていると、これからは
・開発時と本番時でどれだけ基盤が揃っているか
・lint / test / build まで含めてどれだけ流れを揃えられるか
・チーム開発やモノレポ運用でどれだけ再現性を持たせられるか
みたいな観点のほうが、だんだん大事になっていくのかもしれません。
コードや設定ファイルを見ながら考えると、この変化はかなり自然です。
今まではpackage.json scriptsが複数ツールの接着点でした。
これからは、その接着を入口側がもう少し引き受ける方向に進んでいくのかもしれません。
そう考えると、Viteはこれから 「速いビルドツール」から「開発全体を滑らかにする基盤」として見られていく可能性があります。
おわりに
Vite+ Alphaが面白いのは、新しいCLIが増えたことそのものではないと思っています。
それよりも、Vite の役割がどこまで広がろうとしているのか がかなり見えやすくなったことに意味があるように感じました。
実際のpackage.jsonやvite.config.tsを見ると、これまでのViteは「開発とビルドの中心」でありつつ、周辺ツールは別々に持つ構成でした。
そこにVite 8の統一基盤化が重なって、さらにVite+がdev/check/test/build/runまでまとめようとしている。
この流れを見ると、Viteの役割が少しずつ広がりつつあるように見えるのも自然だと思います。
少し触ってみた範囲では、まだAlphaらしい様子見の部分はあります。
ただ、それでも「Viteがこれから何を整理しようとしているのか」は、かなり見えやすくなったと感じました。
Vite+ Alphaは、新機能の追加というより、Viteの今後の方向性を考えるきっかけとして面白い発表だったのかもしれません。
