この記事はこんな方に向けています

Vitestを使っていて、テストやCIの待ち時間を短くしたいTypeScript開発者に向けた記事です。今回はimportの変更とは別に、同時に実行するワーカー数の上限を変えて、手元の環境で時間がどう変わるかを比較しました。

今回はワーカー上限を1 2 4で比較

VitestのmaxWorkersは、テスト実行に使うワーカー数の上限です。4にしても、常に4つが稼働するという意味ではありません。公式ドキュメントでも上限として説明されています。

独立したテストファイルが複数あり、CPUやメモリに余裕がある環境では、並列実行による短縮が期待できます。一方、短いテストではワーカーの準備費用が目立ち、リソースが限られた環境では競合によって遅くなる可能性があります。自分の環境で比較することが大切です。

Windowsで得られた結果

2026年10月11日14時40分（日本時間）に、Windows x64、Intel Core Ultra 7 258V（論理CPU 8）、メモリ約32 GiBの環境で計測しました。Node.js 24.21.0、npm 11.19.0、Vitest 5.0.1、Vite 8.3.0、TypeScript 5.9.2を使用しています。importは直接読み込むcandidate構成に固定し、ワーカー上限だけを変更しました。カバレッジ計測を含むVitestプロセスの経過時間を比較しています。CIジョブ全体の時間ではありません。

ワーカー上限	回数	中央値	最小	最大
1	5	3,073 ms	2,962 ms	3,494 ms
2	5	2,111 ms	1,838 ms	2,271 ms
4	5	1,531 ms	1,444 ms	1,725 ms

この実行では、上限1に対して上限2で約31.3%、上限4で約50.2%短くなりました。計算は(3073 - 1531) / 3073 × 100です。

ただし、サンプルの通常設定はすでに上限4です。この結果は「通常設定からさらに50%短縮した」という意味ではありません。上限1・2・4の違いを比較し、今回の環境では4が最も短かったという結果です。別のプロジェクトや環境で4が最適とは限りません。

一度の実行で15回を比較

上限1・2・4を各5回、固定した順番で交互に実行しました。順番は1,2,4,2,4,1,4,1,2,1,4,2,4,2,1です。各条件を時間的に分散させていますが、ランダム化や統計的な有意差の検定は行っていません。ウォームアップとして除外した回もありません。

各回は新しいVitestプロセスで実行し、Viteキャッシュを消去します。OSのキャッシュは消去しません。中央値に加えて最小・最大も見て、ばらつきを確認します。

無料サンプルを試す

Vitest CI Practice v0.2.0のReleaseからSource codeのZIPを取得し、展開したフォルダで実行してください。ZIPから入手する場合、Gitやgit checkoutは不要です。

npm ci
npm run verify:manifest
npm run measure:workers
npm run verify:manifest

npm ciは、記録された依存パッケージを導入します。Node.jsやnpm自体を導入するコマンドではありません。

Node.jsは22系の22.12.0以降、24系、または26.0.0以降が対象です。Windowsでは経過時間を比較し、CPU時間はnullになります。macOSでの実機確認はまだ行っていません。

npm run measure:workersは1回だけ実行します。内部で15回を計測します。先頭のverify:manifestは計測前の入力構成、末尾は計測後の入力構成を確認します。ほかの編集を加えていない作業用コピーで試してください。

出力を見る

{
  "experiment": "worker-count",
  "complete": true,
  "validCount": 15,
  "invalidCount": 0,
  "fatalReasons": [],
  "comparison": {
    "workers-1": { "samples": 5, "medianWallMs": 3073 },
    "workers-2": { "samples": 5, "medianWallMs": 2111 },
    "workers-4": { "samples": 5, "medianWallMs": 1531 }
  }
}

上記は共有された結果の抜粋です。実際の出力には保存先、警告、最小・最大、CPU時間なども含まれます。

complete: true、validCount: 15、invalidCount: 0、fatalReasons: []なら、15回すべてが比較の条件を満たしています。これは、本人のプロジェクトでも高速化することを保証するものではありません。

表示された保存先のsummary.jsonには集計結果が保存されます。各回のログや検証結果も確認できます。Windowsのcpu_timing_unavailableはCPU時間を取得しないという警告で、今回のように経過時間の比較が完了している場合もあります。

自分のプロジェクトに持ち込むなら

今回の専用スクリプトは、このサンプルの構成に合わせています。任意のプロジェクトにそのまま持ち込める汎用診断ツールではありません。

利用許可のある環境で、現在の設定を記録し、ワーカー上限だけを変え、同じテストとカバレッジ条件で複数回比較してください。異なるOSやcommitの時間を混ぜず、失敗した回を都合よく除外しないことが大切です。採用前には、共有状態や外部リソースを使うテストが並列実行で不安定になっていないかも確認します。

次に確かめたいこと

最初のサンプルではimportの読み込み先、今回はワーカー上限を比較しました。目指しているのは、遅いテストに対して改善候補を一つずつ選び、同じ条件で比較して、採用する変更を判断できるようにすることです。

今後は、第三者がどこで迷うか、本人の環境ではどの条件が役立つかを確認します。新しい改善例や自動診断・自動修正は、具体的な需要と保守負担を確認してから検討します。

手順とフィードバック

試した方は、共有できる範囲で環境、迷った箇所、役立った点を教えてください。会社コードや生ログ、秘密情報の共有は不要です。