こんにちは！日々のフロントエンド開発、本当にお疲れ様です。
巨大なWebアプリケーションを作っていると、こんなイライラを感じたことはありませんか？
「小さなテキストを1文字変えただけなのに、ブラウザのホットリロード（HMR）が終わるまでに数秒〜十数秒も待たされる……」
「保存してから画面が切り替わるまでのタイムラグのせいで、フロー状態（没頭状態）が途切れてしまう……」
モダンなフロントエンド開発において、Viteはその圧倒的なビルドスピードで私たちの開発体験を劇的に変えてくれました。しかし、数千、数万ファイルを超える巨大なモノリスリポや大規模なSPA（シングルページアプリケーション）になると、デフォルトの状態のままではViteのエンジンも悲鳴を上げ始めます。
今回は、Viteの裏側で何が起きているのかという本質的なメカニズムを紐解きながら、数千ファイルの巨大プロジェクトでも「0.1秒の世界」でHMRを爆速化させるためのチューニング手法を、優しく、そして徹底的に解説していきます。
これをマスターすれば、毎日のコーディングリズムが劇的に軽くなり、開発のストレスが嘘のように消え去りますよ。
—
1. なぜ巨大プロジェクトでHMRが遅くなるのか？（内部メカニズムの理解）
まず、「HMRが遅くなる原因」を正しく理解しましょう。ここを避けて通ると、闇雲に設定をいじるだけになってしまいます。
Viteの開発サーバー（`vite dev`）は、内部で `chokidar` というNode.jsのファイル監視ライブラリを使用しています。このchokidarが、あなたのPCのOS（macOS、Linux、Windows）のファイルシステムAPI（macOSなら`FSEvents`など）を叩き、プロジェクトディレクトリ内のあらゆるファイルの変更を常に監視しています。
数千〜数万ファイル規模のプロジェクトでHMRが遅延する主な原因は、主に以下の2点です。
1. 不要なファイルまで監視対象に入っている
`node_modules`、ビルド出力先（`dist`）、巨大な画像やJSON、ログファイル、テストカバレッジのレポートなど、「人間がコードを書いていないファイル・ディレクトリ」の変更までOSレベルで検知しようとし、CPUとメモリのリソースを無駄に消費しています。
2. 依存関係グラフ（Dependency Graph）の肥大化と伝播
1つのファイルを変更した際、Viteはそのファイルがどこからインポートされているかを逆引きします。監視対象が広すぎたり、モジュールグラフの構造が複雑すぎたりすると、HMRのバッチ処理やモジュール無効化の計算コストが跳ね上がります。
つまり、「人間が開発で触るソースコード以外のノイズをすべて監視から除外する」ことこそが、ViteのHMRを限界まで最適化する最短にして最善の道なのです。
—
2. これからViteを始める方へ：爆速環境の基本セットアップ
まだViteに触れたばかりの方や、これからプロジェクトを立ち上げる方に向けて、ベストプラクティスとなる基本のセットアップを確認しておきましょう。
まずは、プロジェクトのルートディレクトリにある `vite.config.js`（または `vite.config.ts`）を開いてください。ここにすべての魔術を書き込んでいきます。
以下は、今回解説する最適化をすべて盛り込んだ、実戦仕様の `vite.config.js` の完全版です。
import { defineConfig } from ‘vite’
import react from ‘@vitejs/plugin-react’ // 例としてReactを使用
export default defineConfig({
// プラグインの設定
plugins: [react()],
// 開発サーバー（HMR）のチューニング
server: {
// 開発サーバーの起動ポート
port: 3000,
// 立ち上がり時にブラウザを自動で開く
open: true,
// === 【ここが最重要】ファイルウォッチャーの最適化 ===
watch: {
// ポーリング（定期的なファイルスキャン）を有効にするか
// ※DockerやWSL2環境でファイル変更が検知されない場合は true にします
usePolling: false,
// 監視対象から完全に除外するパス（正規表現またはglobパターン）
// ここを絞り込むことで、CPU負荷とメモリ消費を劇的に削減できます
ignored: [
‘/node_modules/‘,
‘/dist/‘,
‘/.git/‘,
‘/public/‘, // 静的アセット（画像やフォント等）の変更はHMR不要
‘/coverage/‘, // テストカバレッジの出力先
‘/.log’,
],
},
},
})
—
3. 実務で効く！HMR遅延を防ぐ3つの実践テクニック
ここからが本題です。数千ファイルのプロジェクトで実際に使える、より高度で具体的なチューニング手法を3つに分けて伝授します。
テクニック①：`server.watch.ignored` で「監視のノイズ」を徹底排除する
先ほどのコードにも出てきた `server.watch.ignored` は、Vite高速化の最大の武器です。
巨大プロジェクトによくある失敗が、「`public`フォルダの中にある数万枚の画像が変更されただけで、ファイルウォッチャーが反応してしまう」という現象です。画像やフォント、PDFなどの静的ファイルは、フロントエンドのソースコード（`.js`, `.ts`, `.vue`, `.jsx`, `.tsx`, `.css`など）とは異なり、HMRによってリアルタイムにモジュールを書き換える必要がありません。
以下のように、「本当に開発で書き換えるファイル群以外は監視させない」という引き算の思想を持ちましょう。
server: {
watch: {
ignored: [
‘/node_modules/‘,
‘/dist/‘,
‘/.git/‘,
// 静的アセットやドキュメント、ビルド成果物は監視対象外へ
‘/public/assets/images/‘,
‘/docs/‘,
‘/.md’,
]
}
}
これを行うだけで、ファイル変更時にchokidarが発火するイベントの数が激減し、CPU使用率がスーッと下がっていくのが実感できます。
テクニック②：仮想環境（Docker / WSL2）特有の罠を回避する設定
もしあなたが、Windows上のWSL2や、Dockerコンテナ内でViteを動かしているなら、「ファイルを保存したのにHMRが全く反応しない」という絶望的な現象にぶつかったことがあるはずです。
これは、Linuxカーネルのファイル変更通知機能（inotify）が、ホストOS（WindowsやMac）のファイル変更をうまくキャッチできていないことが原因です。
これを解決するには、強制的に一定間隔でファイルをスキャンする「ポーリングモード」を有効にする必要があります。ただし、デフォルトのままポーリングを行うと、数千ファイルあるプロジェクトではCPUが常にフル稼働してしまいます。そのため、チェック間隔（interval）を少し広めに取るのがプロの技です。
server: {
watch: {
// WSL2やDocker環境では true に設定
usePolling: true,
// ポーリングの間隔（ミリ秒）。デフォルトより長めの 100ms 〜 300ms に設定してCPU負荷を軽減
interval: 200,
ignored: [‘/node_modules/‘, ‘/dist/‘],
},
}
テクニック③：巨大なサードパーティ製ライブラリを事前にプリバンドルする
Viteは初期起動時に、CommonJSやUMD形式のnpmパッケージをESM（ES Modules）に変換し、ブラウザへ効率よく配信するための「事前バンドル（Pre-bundling）」を行います。
数千ファイルのプロジェクトでは、`node_modules` 内の依存関係も膨大になりがちです。Viteがどのライブラリを最適化すべきか迷ってしまうと、起動やHMRのウォームアップに時間がかかります。
`optimizeDeps` を適切に設定し、Viteにあらかじめ「何を最優先で処理すべきか」を教えてあげましょう。
export default defineConfig({
// 依存関係の最適化設定
optimizeDeps: {
// 頻繁に使用する重いライブラリを強制的に事前バンドル対象に含める
include: [‘react’, ‘react-dom’, ‘lodash-es’, ‘@mui/material’],
// 逆に、動的インポートなどで初期ロードに関係のない重いライブラリは除外する
exclude: [‘some-heavy-client-only-lib’],
},
})
これにより、開発サーバー起動時の依存関係スキャンが迷いなく行われ、初回のモジュールロードが劇的にスムーズになります。
—
4. 動作確認：あなたのViteが爆速になったかを計測する方法
設定が終わったら、実際に開発サーバーを立ち上げて動作確認をしてみましょう。
ターミナルで以下のコマンドを実行します。
開発サーバーの起動
npm run dev
💡 プロフェッショナルな検証のコツ
Viteのログ出力に、サーバー起動時間がミリ秒単位で表示されます（例: `1250ms で起動しました`）。
チューニング前後の起動時間や、エディタでファイルを保存してからブラウザが更新されるまでの時間を、スマートフォンのストップウォッチなどで計測してみてください。
「保存」→「（無音）」→「即座にブラウザ反映」という、あの小気味よいテンポが戻ってくるはずです。
—
まとめ
今回は、Viteの『HMR最適化』をテーマに、数千ファイルの巨大プロジェクトでも遅延を防ぐための実践的なチューニング手法を解説しました。
- HMR遅延の正体は、ファイルウォッチャー（chokidar）による「余計な監視」である。
- `server.watch.ignored` を使いこなして、ソースコード以外のノイズを徹底的に除外する。
- WSL2やDocker環境では `usePolling` と `interval` を適切に調整して、CPU負荷と検知精度のバランスを取る。
開発ツールの裏側で何が起きているのかを理解し、適切に手綱を握ってあげることで、あなたの開発環境は世界最高峰の快適さを手に入れます。
毎日のコーディングが驚くほど軽快になり、あなたの素晴らしいアイディアを形にするスピードが加速することを、心から応援しています！