フロントエンドの開発環境は、気付くとすぐ重くなります。
最初はHTMLとCSSだけだったのに、気付けばTypeScript、Sass、ESLint、Prettier、テスト、画像最適化、ビルド、HMR、SSRまで欲張りセット。 そして最後に残るのが、毎回の起動が遅い、更新が反映されない、設定が迷子、という三重苦。
そこで登場するのがViteです。 Viteは一言でいうと、フロントエンド開発のためのビルドツール兼開発サーバー。 そして実務的には、開発体験を速くして、ビルドを安定させて、設定の複雑さを必要以上に増やさないための現代的な選択肢です。
この記事は、忙しい社会人が流し読みしても要点が拾えるように、結論から先に書きます。 そのうえで、勉強中の人がつまずきがちな部分も、実務で差が出る部分も、まとめて面倒を見ます。
まず結論 Viteは何がうれしいのか
開発が速い 理由はシンプル
Viteの気持ち良さは、開発時にあります。 従来のバンドラー中心の開発では、起動時に全部まとめてビルドしがちでした。 Viteは開発中の動きを合理化して、必要な分だけを素早く扱う設計になっています。
結果として、起動が速い、更新が速い、HMRが速い。 この三つが揃うと、作業中のストレスが目に見えて減ります。
本番ビルドは堅い
開発が速いだけだと、現場では採用されません。 本番ビルドが安定していて、配布物が読みやすく、トラブル時に追えることが大事です。 Viteは本番向けのビルドも強く、設定やプラグインのエコシステムも成熟しています。
学習コストは低め ただし油断は禁物
初期導入は簡単です。 ただし、現場の要件は必ず増えます。 環境変数、モノレポ、別ドメインAPI、プロキシ、SSR、静的サイト、画像最適化、PWAなど。 そこまで含めて「困らない地図」を用意するのが、この記事の目的です。
Viteとは何か ざっくり理解してから細部へ
Viteの正体 開発サーバーとビルドの二刀流
Viteは、開発時は開発サーバーとして動き、本番時はビルドツールとして動きます。 この二つを別物として理解すると、迷子になりにくいです。
- 開発時: dev serverで高速に表示し、更新を即反映する
- 本番時: buildで最適化した成果物を出力する
よくある誤解 Viteはフレームワークではない
ViteはReactでもVueでもありません。 フレームワークの上に乗る道具です。
なので、Viteを入れた瞬間にアプリが完成するわけではありません。 逆に言うと、Vanilla、React、Vue、Svelteなど、構成に合わせて柔軟に使えます。
Viteで出来ること
開発サーバー HMR 高速更新
Viteの代表的な強みはHMRです。 変更したファイルだけを差し替えて、画面を極力崩さずに更新します。
地味に効くのが、フォーム入力中でも状態が保たれやすい点。 実務では、細かい調整を延々やるので、更新の速さはそのまま生産性になります。
TypeScript JSX Vue Svelteなどのテンプレート生成
Viteはプロジェクトのひな形作成が簡単です。 コマンド一つで、ReactやVueなどのテンプレートを選べます。
勉強中の人にとっては、最初の環境構築で止まらないのが大きい。 実務の人にとっては、試作や検証を素早く回せるのがうれしい。
本番ビルドの最適化
本番向けビルドでは、モジュールをまとめ、最適化し、成果物を出力します。
- JSやCSSのバンドルと最適化
- コード分割
- アセットの取り扱い
- キャッシュ運用しやすいファイル名付与
このあたりは「後で自作すると泥沼」になりやすいので、Viteに任せた方が早いです。
CSS周りが扱いやすい
実務で触る時間が長いのはCSSです。 ViteはCSSの取り回しが現代的で、素直に動きます。
- CSS Modules
- PostCSS
- Sassなどのプリプロセッサ
設定を盛りすぎなくても、必要なものが揃います。
プラグインで拡張出来る
Viteはプラグインのエコシステムが強いです。 PWA、SVGの扱い、画像最適化、テスト連携など、要件に応じて積み上げられます。
Viteで出来ないこと ここを勘違いするとハマる
バックエンドの代わりにはならない
Viteは開発サーバーを持っていますが、これは本番のアプリサーバーではありません。 ローカル開発のためのサーバーです。
本番では、ビルド済みの静的ファイルを配信するか、SSRの仕組みを別途構築します。
型チェックやLintは勝手に全部やってはくれない
ViteはTypeScriptを扱えますが、プロジェクトの方針によっては型チェックやLintの設定は別途必要です。
実務では、次の道具を組み合わせるのが一般的です。
- TypeScriptの型チェック
- ESLint
- Prettier
- テスト（後述）
Viteは万能な管理者ではなく、あくまで開発とビルドの中心にいる道具です。
レガシーブラウザ対応は追加設計が必要
対象ブラウザが古い場合、追加の設定やプラグインが必要になることがあります。 現代的なターゲットなら問題になりにくいですが、要件として古いブラウザが残っている現場は注意です。
既存の巨大なwebpack設定をそのまま移植は出来ない
移行は出来ますが、そのままコピペで移すのは無理があります。 思想が違う部分があるからです。
移行時は、まず必要最低限で動かし、差分を一つずつ埋めていくのが現実的です。
環境構築方法 ここだけ押さえれば最短で動く
前提 Node.jsが必要
ViteはNode.js環境で動きます。 Nodeのバージョン要件はViteのメジャーにより変わることがあるので、チーム内で揃えるのが大事です。
現場では、VoltaやnvmなどでNodeバージョンを固定する運用が多いです。 個人開発でも、後で泣かないために固定をおすすめします。
プロジェクト作成 基本コマンド
npm create vite@latestコマンドを叩くと、プロジェクト名やフレームワーク（Vanilla、React、Vueなど）を選ぶ流れになります。
インストールと起動
cd your-project
npm install
npm run devこれで開発サーバーが起動します。 URLにアクセスすると、テンプレートが表示されます。
本番ビルドとプレビュー
npm run build
npm run previewbuildで成果物を作り、previewで本番に近い形をローカルで確認します。
注意点として、previewは本番サーバー用途ではありません。 あくまでローカル確認用です。
実務でよく使う基本構成 ディレクトリと考え方
よく出てくるディレクトリ
- src: アプリのコード
- public: そのまま配信したい静的ファイル
- dist: buildの出力先
publicに置いたファイルは、ビルド時にそのままコピーされるイメージです。 一方でsrc配下の画像などは、import経由で扱うと最適化やパス解決が楽になります。
絶対パス風のimportを使いたい場合
実務では相対パスが深くなりがちです。 Vite側のalias設定で、importを整理できます。
例として、@をsrcに向けるパターンです。
// vite.config.js のイメージ
import { defineConfig } from 'vite'
import path from 'path'
export default defineConfig({
resolve: {
alias: {
'@': path.resolve(__dirname, 'src'),
},
},
})ReactやVueのテンプレートでも似た考え方で整理出来ます。
出来ることを増やす Viteの設定で触る場所
vite.config.js ここが司令塔
Viteの設定は、基本的にvite.config.js（またはts）に集まります。
- base（サブディレクトリ配信など）
- plugins
- resolve alias
- server（プロキシなど）
- build（ターゲットや出力）
APIサーバーを別で立てるときはproxyが便利
ローカル開発で一番多い構成が、フロントはVite、APIは別サーバーです。 その時にCORSで詰まりがちですが、Viteのproxyで解決できます。
// vite.config.js のイメージ
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'http://localhost:3000',
changeOrigin: true,
},
},
},
})これでフロント側は /api を叩くだけで済み、開発体験がスッキリします。
環境変数の扱い 実務で事故りやすいので丁寧に
import.meta.env を使う
Viteでは環境変数を import.meta.env から参照します。
ここでの基本ルールは、公開して良い値だけをフロントに渡すこと。 APIキーを入れてよいわけではありません。 フロントに埋め込まれた時点で、基本的に見られます。
モードごとに切り替える
開発、ステージング、本番で値を切り替えるのは実務の常識です。 Viteはモードという仕組みで切り替えられます。
運用設計としては、
- 開発時は安全に動く
- 本番は意図せずデバッグ設定が残らない
この二つが守れれば勝ちです。
Viteを選ぶべきケース 選ばない方が良いケース
Viteが向く
- 新規でSPAやフロント中心の開発を始める
- ReactやVueなどの開発を快適にしたい
- 試作を早く回したい
- 既存環境が重くて改善したい
慎重になった方が良い
- 古いブラウザ要件が強い
- 既存のビルドが巨大で、移行コストが高い
- バックエンド統合が強く、フロント単体のビルドでは足りない
とはいえ、慎重ケースでも使えないわけではありません。 要件を洗い出して、段階移行する計画があるなら、選択肢として十分ありです。
よくあるトラブルと解決の方向性
依存関係のエラーが出る
Nodeバージョン不一致、lockファイルのズレ、パッケージマネージャー混在が原因になりがちです。 チームでは、Nodeとパッケージマネージャーを固定し、CIでも同じ条件で動かすのが安定します。
パスが本番だけおかしい
base設定、静的配信のパス、ルーティング設定が原因になりがちです。 特にサブディレクトリ配信（例: /app/ 配下）では base が重要になります。
画像やフォントが見つからない
publicに置くべきか、srcでimportすべきかが混ざると起きます。 ルールを決めましょう。
- ビルドに任せたいものはsrcでimport
- そのまま配信したいものはpublic
最後に 読者に有益な関連情報 Viteと一緒に揃えると強い道具
テストならVitestを検討
Viteの流れでユニットテストを整えたいなら、Vitestは相性が良いです。 テスト導入は後回しにされがちですが、実務では不具合調査の時間を削ってくれます。
型チェックとLintはCIで必ず回す
ローカルだけで回していると、誰かの環境で通って、別の人で落ちます。 CIで型チェックとLintを固定して回すと、レビューが速くなります。
パフォーマンスの基本はビルドより先にコード
ビルドツールを強くしても、巨大な依存を入れすぎると遅くなります。 本当に必要なライブラリだけを選ぶ。 画像や動画を軽くする。 レンダリングコストを意識する。 結局ここが効きます。 Viteはその努力を邪魔しない、という意味で良い相棒です。
まとめ Viteは速さだけではなく 現場を前に進める道具
Viteは、ただ速いだけの流行りツールではありません。
開発の回転を上げ、本番ビルドを安定させ、必要な分だけ設定を積む。 この現実的な落としどころが、実務で強い理由です。
まずは npm create vite@latest で一度触って、devとbuildとpreviewの流れを体に入れる。 次に、proxyと環境変数とaliasを押さえる。 この順で進めると、Viteは味方になります。
そして最後に一言。
ビルドツールは宗教ではなく道具です。 あなたの案件が速く進んで、トラブルが減って、夜に眠れるなら、それが正解です。 Viteはその確率を上げてくれます。
