---
title: "Vitestとは？Viteネイティブなテスト基盤の仕組みと採用判断を実装目線で解説"
url: "https://www.issoh.co.jp/tech/details/16023/"
published: 2026-08-01
updated: 2026-10-12
categories: ["テスト"]
publisher: "株式会社一創"
---

# Vitestとは？Viteネイティブなテスト基盤の仕組みと採用判断を実装目線で解説

Vitestは、Viteの設定と変換の仕組みをそのまま借りて動くJavaScript・TypeScript向けのテストフレームワークです。npm registryのdist-tagsを2026年8月1日に確認したところ、latestは4.1.10、次期メジャーの5.0.0-beta.7が並行して公開されていました。Jestと似たAPIを持ちながら、テスト専用のビルド設定を別に持たない点が設計上の分かれ目になります。この記事では、Vitestが何を担い何を担わないのか、Jestやnode:testとの違い、導入時の設定の置き場所、そして受託開発で採用してよい条件までを実装目線で扱います。

## まとめ：Vitestを採用してよい条件と見送る線引き

結論から置きます。プロジェクトがViteでビルドされていて、ソースがESモジュールとTypeScriptで書かれているなら、テストランナーはVitestで問題ありません。`vite.config.ts`に書いたエイリアスやプラグインがテスト実行時にもそのまま効くため、テスト専用のtransform設定を別に育てる作業が消えます。ウォッチ実行が既定で有効なので、開発中の反復もJest比で軽くなるでしょう。

見送る判断が要るのは3つの場面です。第一に、ビルドにViteを使っていないNode.js専用のバックエンドで、Jest向けの資産（カスタムreporter・独自transform・大量のsnapshot）が厚く積み上がっている構成。第二に、JavaScriptで書いたBabelプラグインに依存した変換をテスト時にも通す必要がある構成。第三に、実行環境のNode.jsが20系より古く、すぐには上げられない構成です。この3つに当たるなら、Jestを据え置くか、新規に書くテストだけVitestへ寄せる二段構えを検討してください。

## Vitestの定義｜Viteの変換パイプラインを共有するテスト基盤

まず、Vitestが何をどう共有しているのかを設計の側から押さえます。ここを曖昧にしたまま導入すると、Jestの置き換えという理解で止まり、設定を二重に持つ構成に戻ってしまいます。

### Viteの設定ファイルをそのまま読み込む設計が生む運用上の差分

公式ドキュメントは、Vitestが既定で`vite.config.*`を読み、既存のViteプラグインと設定がそのまま動くと明記しています。開発・ビルド・テストの3つの場面で共通の変換パイプラインを通す、という立て付けです。

実務での差はここに出ます。Jestを使う構成では、パスエイリアスを`tsconfig.json`・`vite.config.ts`・`jest.config.js`の3か所に書く羽目になり、どれか1つが古いまま残って「ローカルでは通るのにCIで解決できない」という事故が起きがちでした。Vitestはビルド側の解決結果を借りるため、この二重管理そのものが発生しません。CSS ModulesやSVGのインポート、環境変数の読み込みといったプラグイン任せの挙動も、テスト時に別実装で再現する必要がなくなります。

### ワーカースレッドで並列実行する仕組みとウォッチモードの既定挙動

実行モデルの側も見ておきます。公式は、可能な限り並列で動かすためにワーカースレッドを使うと説明しており、プロジェクトによっては一桁違う速度差が出ると述べています。テストファイル単位で隔離された環境を作り、それらを並べて走らせる構造です。

ウォッチモードは既定で有効になっています。`vitest`をそのまま叩くと監視状態に入り、変更したファイルと、そこに依存しているテストだけが再実行されます。CIで1回だけ流したい場合は`vitest run`を指定してください。ここはJestと既定が逆なので、CI設定を書き写すときに引っかかりやすい箇所でしょう。

### 4.1系という版番号とNodeやViteに求められる前提環境の条件

版番号は4系に入っています。npm registryのdist-tagsを2026年8月1日に確認した時点で、latestは4.1.10、V3タグに3.2.7、betaに5.0.0-beta.7が載っていました。`@vitest/browser`のようなサブパッケージも本体と同じ版で並びます。

前提環境として、公式のGetting Startedは Node.js v20.0.0 以上、Vite v6.0.0 以上を求めています。Node 18系のまま運用しているCIでは、まずランタイム側の更新が先に来る点に注意してください。3系から4系へ上げる際の変更点や移行手順は、[Vitest 4の新機能と移行ガイド｜ブラウザモード正式化・VRT・最新バージョン](https://www.issoh.co.jp/tech/details/9465/)に版差分としてまとめてあります。4系から5系への移行で変わる既定値と動作要件（Node.js 22.12.0以上・Vite 6.4.0以上）は、[Vitest 5移行ガイド｜4からの破壊的変更と落ちるテストの直し方](https://www.issoh.co.jp/tech/details/18278/)で扱っています。

## Vitestで何ができるか｜単体テストからブラウザ実行までの守備範囲

次に、担当する範囲を整理します。単体テストのランナーという理解だけだと、標準で持っている機能を別ツールで足してしまうことになります。

### 単体テストとコンポーネントテストで担当できる範囲の線引きを整理する

中心はやはり単体テストです。純粋な関数やクラス、APIクライアントのような部品を、Node.js上で高速に検証します。ここは追加設定なしで動く領域。

UIコンポーネントを扱う場合は、実行環境をjsdomなどのDOM実装へ切り替え、Testing Libraryと組み合わせる形になります。描画してユーザー操作を再現し、表示結果を検証する流れです。この組み合わせでの具体的な書き方や、`getBy`系と`findBy`系の使い分けといった実装の手順は、[Vitestの使い方｜React Testing Libraryでコンポーネントテストを書く実践ガイド](https://www.issoh.co.jp/tech/details/2867/)で手順として追えます。本記事では、どこまでを自分の担当と考えるかという境界の話に絞ります。

### ブラウザモードと視覚回帰テストが埋める実ブラウザ側の検証範囲

jsdomはDOMのJavaScript実装であって、本物のブラウザではありません。レイアウト計算や実際のスクロール、CSSの適用結果までは再現しないため、見た目に関わる不具合はすり抜けます。ここを埋めるのがブラウザモードです。

ブラウザモードでは、Playwright・WebdriverIO・Previewの3つのプロバイダから選び、実ブラウザ上でテストを走らせます。PlaywrightならChromium・Firefox・WebKit、WebdriverIOならChrome・Firefox・Edge・Safariが対象。Previewは手元での確認向けで、CIには推奨されていません。動作要件としてネイティブESモジュール・動的インポート・BroadcastChannel APIが必要で、公式はChrome 87以上、Firefox 78以上、Safari 15.4以上、Edge 88以上を下限として挙げています。視覚回帰テストも専用のガイドが用意されており、実ブラウザ側でスクリーンショットを比較する流れが標準の機能として組み込まれました。セットアップの具体手順は[Vitest Browser Modeの導入・セットアップ方法を徹底解説](https://www.issoh.co.jp/tech/details/7394/)に分けてあります。

### カバレッジや型テストなど周辺機能を標準で抱え込む構成が持つ意味

周辺機能も本体側に揃っています。公式が挙げている守備範囲を一覧にすると、次のようになります。

| 機能         | 担当する範囲         |
| ---------- | -------------- |
| 単体テスト      | Node上で関数を検証    |
| コンポーネントテスト | jsdom上でUIを検証   |
| ブラウザモード    | 実ブラウザで描画を検証    |
| カバレッジ      | v8とistanbulを選択 |
| 型テスト       | 型の期待値を検証       |
| ベンチマーク     | 実行速度を計測し比較     |
| インソーステスト   | 実装と同じファイルに記述   |
| テストプロジェクト  | 複数構成を1つに束ねる    |

型テストとインソーステストは、Jestに慣れた人ほど見落としやすい機能です。前者は型定義そのものの期待値を検証するもので、ユーティリティ型を配布するライブラリで効いてきます。後者は実装ファイルの中にテストを書いて本番ビルドから落とす方式。テストプロジェクトは、Nodeで動かす部分とブラウザで動かす部分を1つのコマンドから束ねて回すための仕組みで、モノレポや、単体とブラウザを混在させる構成で使います。

## JestとNode標準テストランナーとの違いから見る選択の判断軸

ここからは選び分けです。似たツールが3つ並ぶため、守備範囲と前提の違いを軸にして比べます。

### Jest互換のAPIがそのまま動く範囲と書き換えが必要になる箇所

公式は「ほとんどのプロジェクトでドロップイン置換として使えるJest互換API」と表現しています。`describe`・`it`・`expect`という骨格や、スナップショット、モックの考え方は共通。既存のテストコードの大半は、そのまま読み替えられます。既定の出力形式が違うため再生成が要る点は[スナップショットテストの実装と更新運用](https://www.issoh.co.jp/tech/details/16263/)で整理しています。

書き換えが要るのは主に2か所です。1つはグローバル変数の扱いで、Vitestは`describe`などを既定でグローバルに置かず、`vitest`からインポートする方式を取ります。Jestと同じ感覚で書きたい場合は設定で`globals`を有効にしてください。もう1つはモックの名前空間で、`jest.fn`や`jest.mock`が`vi.fn`・`vi.mock`に変わります。この2点を機械的に置換すれば、多くのテストは動き始めるはずです。

### Node標準のtestモジュールと比べたときの守備範囲の差分

Node.js本体にも`node:test`というテストランナーが入っており、依存を1つも足さずにテストを書けます。CLIツールやサーバーサイドの小さなパッケージなら、これで足りる場面も少なくありません。

差が出るのは変換とブラウザ環境です。`node:test`はTypeScriptやJSXの変換を自分では持たないため、別途トランスパイル手順を用意する必要があります。jsdomのようなDOM実装の組み込み、カバレッジのレポート形式、ブラウザでの実行も守備範囲の外。フロントエンドのコードを含むリポジトリでは、結局その周辺を自作することになるため、Vitestを入れたほうが早く着地します。

### 主要テストランナーを一覧で比較し選定時に見るべき評価軸を整理する

4つを並べると、選定の軸が見えてきます。

| ツール        | 変換の担当       | 実行環境       | 主な使いどころ      |
| ---------- | ----------- | ---------- | ------------ |
| Vitest     | Viteと共有     | Nodeと実ブラウザ | Vite構成の単体テスト |
| Jest       | babel-jest等 | Nodeとjsdom | 既存資産が厚い構成    |
| node:test  | 持たない        | Nodeのみ     | 依存を足さない構成    |
| Playwright | 持たない        | 実ブラウザ      | 画面をまたぐE2E    |

見るべき軸は3つです。1つ目は変換を誰が持つか。ビルド側と同じ変換を通したいならVitest、独立させたいならJestという整理になります。2つ目は実行環境で、DOMが要るかどうか、本物のブラウザが要るかどうかで層が分かれます。3つ目は既存資産の量。乗り換えコストは、テスト本数よりもカスタム設定の本数に比例すると考えたほうが実態に合います。なお[Playwrightとは｜仕組み・できること・Seleniumとの違いを解説](https://www.issoh.co.jp/tech/details/3167/)で扱ったE2Eは、Vitestと競合する関係ではなく上の層を担当する道具。どの層に何本置くかという設計は、[E2E（エンドツーエンド）テストのベストプラクティス｜結合テストとの違いとツール選定](https://www.issoh.co.jp/tech/details/5470/)を土台にしてください。

## Vitestの導入手順と設定ファイルを1枚に寄せるときの考え方

導入そのものは軽い作業です。詰まるとしたら設定の置き場所と実行環境の指定なので、その2点を中心に見ていきます。

### npmでの導入から1本目のテストが通るまでに踏む手順を順に追う

パッケージを1つ入れれば、その場で走ります。Viteが入っているプロジェクトなら、追加の設定なしで最初のテストが通るはずです。

```
npm install -D vitest
npx vitest run
```

テストファイルは`src/sum.test.ts`のような名前で置きます。既定ではグローバル変数を使わない方式なので、必要な関数を`vitest`からインポートしてください。

```
import { describe, it, expect } from 'vitest'
import { sum } from './sum'

describe('sum', function () {
  it('2つの数を足す', function () {
    expect(sum(1, 2)).toBe(3)
  })
})
```

`package.json`のscriptsには、ウォッチ用の`vitest`とCI用の`vitest run`を分けて登録しておくと運用が安定します。カバレッジを取るなら`vitest run --coverage`を足し、レポータの実装を別途入れる形。ここまでで1本目のテストが緑になります。

### vite.configとvitest.configのどちらに書くかの判断基準

テストの設定は`vite.config.ts`の中に`test`フィールドとして書けます。設定ファイルが1枚で済むため、まずはこちらを選んでください。型を効かせるには、インポート元を`vite`ではなく`vitest/config`に変えます。

```
import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: ['./src/setupTests.ts'],
  },
})
```

別ファイルの`vitest.config.ts`を用意するのは、ビルド設定とテスト設定で値を変えたい場合に限ります。両方が存在するときはテスト実行時に`vitest.config.ts`が優先され、ビルド側の設定は自動では引き継がれません。この挙動を知らずに2枚置くと、エイリアスがテストだけ解決されないという症状に化けます。分ける理由がないなら1枚に寄せる、が基本方針です。

### environment指定でjsdomとnodeを切り替えるときの基準

`test.environment`の既定値は`node`で、`window`も`document`も存在しません。UIコンポーネントを描画するテストでは`jsdom`か`happy-dom`を指定し、対応するパッケージを開発依存に入れる必要があります。

判断の基準は単純で、DOM APIに触るかどうかだけ。サーバーサイドのロジックまでjsdomで動かすと、起動のたびにDOM実装を組み立てる分だけ遅くなります。両方が混在するリポジトリでは、ファイル冒頭のdocblockコメントでファイル単位に指定するか、テストプロジェクト機能で2つの構成を束ねる方式を選んでください。実ブラウザでの検証が要る部分は、jsdomで粘らずブラウザモードへ寄せたほうが結果的に速く終わります。

## 受託開発でVitestを採用してよい条件と見送る場面の切り分け

最後に、案件で判断するときの基準を条件として言い切ります。速さだけを理由に選ぶと、移行コストの見積もりを外します。

### 既存プロジェクトの構成から採用の可否を切り分ける3つの判断条件

新規開発なら話は早く、Viteでビルドする構成を採るならテストもVitestで統一して問題ありません。設定が1枚に収まり、変換の食い違いという事故要因が最初から消えます。

既存プロジェクトへ入れる場合は、3つの条件で切り分けます。第一に、ビルドがViteであること。第二に、Node.jsが20系以上へ上げられること。第三に、Jest向けのカスタム設定（独自transform・カスタムreporter・moduleNameMapperの大量定義）が薄いこと。3つとも満たすなら、置き換えの作業量はテスト本数にほぼ比例した機械作業に収まります。1つでも欠けるなら、次で挙げる据え置きの判断を先に検討してください。

### Jestを据え置く判断が要る構成とテスト戦略全体での組み立て方

webpackでビルドしているレガシーなフロントエンドや、Babelプラグインに依存した変換をテスト時にも通している構成では、Jestを据え置く判断が現実的です。VitestはViteの変換を借りる設計なので、Vite以外のビルド基盤と組む場合はその利点の大半が消えます。

途中まで移行する手もあります。既存テストはJestのまま凍結し、新規に書くテストだけVitestで積む二本立て。CIのジョブが1本増える代わりに、大規模な書き換えを一度に抱え込まずに済みます。ビルド基盤そのものをViteへ寄せる計画があるなら、変換器の選定から順に整えるのが筋で、その前段の判断材料は[esbuildとは？Go製の高速バンドラの使い方と採用判断を実装目線で解説](https://www.issoh.co.jp/tech/details/16017/)にまとめてあります。

### E2Eテストとの役割分担と自動テストの内製化を進める体制の設計

Vitestを入れただけでは、テストの体制は整いません。単体とコンポーネントをVitest、画面をまたぐ操作をPlaywright、という層の分担を先に決めてから本数を配分してください。層の境界が曖昧なまま書き始めると、E2Eが肥大して実行時間が伸び、結局ウォッチもCIも回らなくなります。

体制の側で効くのは、テストを書く時間を見積もりへ最初から入れておくことです。実装が終わってから余った時間で書く運用にすると、真っ先に削られます。[業務用・Webアプリ開発](https://www.issoh.co.jp/service/apps/business/)では、テスト基盤の選定からCIの組み立て、内製化に向けた運用設計までを含めて相談を受けています。既存プロジェクトのテストが動いていない、あるいはCIの実行時間が伸びて手が止まっている場合は、まず層ごとのテスト本数と実行時間の内訳を洗い出すところから着手してください。

## よくある質問

### VitestはJestの完全な置き換えになりますか？

大半のプロジェクトでは置き換えとして機能しますが、完全な互換ではありません。`describe`を既定でグローバルに置かない点と、モックの名前空間が`vi`である点は書き換えが要ります。独自transformやカスタムreporterに依存している構成では、その部分の作り直しが必要になると考えてください。

### Viteを使っていないプロジェクトでもVitestは使えますか？

実行自体は可能です。ただし利点の中心が「ビルド設定をそのまま共有できること」にあるため、webpackなど別のビルド基盤を使っている構成では旨味が薄くなります。その場合はJestを据え置くか、ビルド基盤ごとViteへ寄せる計画とセットで検討するほうが筋が通ります。

### Vitestで実ブラウザのテストまでできますか？

ブラウザモードを使えば可能です。PlaywrightかWebdriverIOをプロバイダに指定して実ブラウザで走らせ、視覚回帰テストまで扱えます。ただし画面をまたぐ業務フローの検証はE2Eの層の仕事なので、コンポーネント単位の描画確認までをブラウザモードの担当と考えると整理しやすいでしょう。

### Node.jsのバックエンドコードのテストにも使えますか？

使えます。`test.environment`の既定値が`node`なので、そのままサーバーサイドのロジックを検証できます。フロントエンドと同じリポジトリなら設定を共有できる点が利点。バックエンド単独のパッケージで依存を増やしたくないなら、Node標準の`node:test`という選択肢も残ります。

### Vitestを導入するのに必要なNode.jsの版はどれですか？

公式のGetting Startedでは Node.js v20.0.0 以上、Vite v6.0.0 以上が前提として示されています。2026年8月1日時点のlatestは4.1.10で、次期メジャーの5.0.0-beta.7も公開されています。Node 18系のCIで動かしている場合は、ランタイムの更新を先に済ませてください。

## 関連記事

- [Vitestの使い方｜React Testing Libraryでコンポーネントテストを書く実践ガイド【2026年版】](https://www.issoh.co.jp/tech/details/2867/)
- [Vitest 4の新機能と移行ガイド｜ブラウザモード正式化・VRT・最新バージョン](https://www.issoh.co.jp/tech/details/9465/)
- [Vitest Browser Modeの導入・セットアップ方法を徹底解説](https://www.issoh.co.jp/tech/details/7394/)
- [Playwrightとは｜仕組み・できること・Seleniumとの違いを解説](https://www.issoh.co.jp/tech/details/3167/)
- [E2E（エンドツーエンド）テストのベストプラクティス｜結合テストとの違いとツール選定](https://www.issoh.co.jp/tech/details/5470/)
- [esbuildとは？Go製の高速バンドラの使い方と採用判断を実装目線で解説](https://www.issoh.co.jp/tech/details/16017/)

---

出典: [Vitestとは？Viteネイティブなテスト基盤の仕組みと採用判断を実装目線で解説](<https://www.issoh.co.jp/tech/details/16023/>)（株式会社一創）