フロントエンドのテスト戦略を設計する：開発段階と実行スピードで考えるツール選定
なにこれ
Next.js のようなモダンフロントエンド開発では，UI が頻繁に変化し，バックエンドやビルド構成も複雑になりがちである．つらい．筆者はフロントエンドのテストに関する知見が少ないため，どのようなテスト戦略を採用すればよいのか悩んでいた．
「どこまでテストを書くか」「どのツールを使うか」の判断を誤ると，すぐに開発速度と保守性がトレードオフになる．テストを頻繁に書き直すのはつらいし，テスト自体が遅くてもつらい．
最近は MCP を用いたテストも登場しているが，結局どれを使えばよいのかよくわからないという場合も多い．筆者もよくわからない．
この記事では，
Vitest・Playwright・MCP（Model Context Protocol）・Chrome DevTools
といった主要ツールを軸に，開発段階と実行スピードの観点からテスト戦略を整理する．
結局フロントエンドで何をテストすべきなのか 3 選
| レイヤー | 主な目的 | 例 | 主に使うツール |
|---|---|---|---|
| ロジック層（ユニット） | 純粋な処理・状態遷移が正しいか | バリデーション関数，カスタムフック | Vitest |
| UI 層（コンポーネント） | イベント操作 → 状態変化の確認 | フォーム入力，モーダル動作 | Vitest / Playwright(CT) |
| 統合層（E2E） | ユーザー操作全体の流れが成立するか | ログイン，購入，登録など | Playwright（コード／MCP） |
ここに Chrome DevTools MCP を加えると，テスト後の パフォーマンス診断や自動トレース解析 まで行える．
テストが遅いとモームリ状態
フロントエンドのテスト戦略を設計するうえで，実務に最も影響するのが「実行スピード」である．
テストの速度は，開発ループの回転率に直結する．
| テスト手法 | 対象 | 平均実行時間（1 ケース） | 並列実行 | 備考 |
|---|---|---|---|---|
| Vitest | 関数・Hooks・軽量 UI | ⏱️ 0.01〜0.5 秒 | ✅ 高 | Node 上で完結．ホットリロード同等の速さ． |
| Playwright（コード実行） | ページ遷移を含む E2E | ⏱️ 2〜15 秒 | ✅ 中〜高 | ブラウザ操作を並列化できる． |
| Playwright（MCP 経由） | 仕様(Markdown)→ 自動実行 | ⏱️ 10〜60 秒 | ⚠️ 低 | 生成＋実行の 2 段階．自動生成・可読性重視． |
| Chrome DevTools（MCP） | パフォーマンス・診断 | ⏱️ 30〜180 秒 | ⚠️ 低 | トレース/Lighthouse 計測に時間がかかる． |
実行速度の序列：
Vitest ≪ Playwright（コード） ＜ Playwright（MCP） ≪ DevTools（MCP）
とくに Playwright（コード実行）と Playwright（MCP 経由）の速度差は大きく．前者は数秒で完了するのに対し後者は数十秒から 1 分程度かかることが多く，この速度差は重要だった（後述）．
開発段階別のツール選定指針
🧩 開発初期（UI が頻繁に変わる時期）
- 目的：スピード重視．変更に耐えるロジックテスト中心．
-
ツール構成
- 🟢 Vitest：関数やフックをしっかり守る．
- 🟡 Playwright（コード）：最小限の E2E（ログインなど）だけ．
- ⚪ MCP（Markdown 仕様）：仕様ドラフトの自動検証に利用．
-
考え方
- DOM 構造や文言に依存しない．
- E2E は「壊れない導線」に絞る．
- 実装よりも動作理解とリファクタ頻度を優先．
🚀 開発中盤（機能が増え始める時期）
- 目的：E2E で主要フローを守り，チームで共通理解を作る．
-
ツール構成
- 🟢 Vitest：変わらず全関数・ロジックを担保．
- 🟡 Playwright（コード）：5〜10 本の主要導線を E2E 化．
- 🟠 Playwright（MCP）：仕様書（Markdown）で QA や PM と合意形成．
-
考え方
- 「重要な導線のみコード化」し，その他は仕様ベースで守る．
- UI 変更が激しい画面はまず MCP で回す → 安定後コード化．
- CI では並列ワーカーで Playwright を高速化．
🧱 開発終盤（リリース前）
- 目的：品質保証とパフォーマンス測定．
-
ツール構成
- 🟡 Playwright（コード）：CI の品質ゲートに設定．
- 🟠 Chrome DevTools（MCP）：Lighthouse やトレースを自動取得．
- ⚪ Playwright（MCP）：仕様書を QA 報告書として再利用．
-
考え方
- スピードより 確実性 を重視．
- Playwright のトレース・スクリーンショットを残して再現性確保．
- DevTools MCP で CLS/LCP/JS エラーを自動診断．
🔧 運用・保守期
- 目的：品質の維持と継続的なモニタリング．
-
ツール構成
- 🟡 Playwright（コード）：回帰テストを定期実行．
- 🟠 Chrome DevTools（MCP）：週次パフォ監視（本番環境の退行検知）．
- 🟢 Vitest：内部ロジックの保守に継続利用．
-
考え方
- UI 変更が入る新機能はまず MCP でカバー．
- 成熟したフローは Playwright へ昇格．
- テストの目的を「守る → 見張る」にシフト．
Playwright（コード実行）と Playwright（MCP）の選び方
Playwright にはコードを書いて実行するパターンと，MCP 経由で仕様から自動生成・実行するパターンがある．筆者もこれをどう使い分けるかがよくわからなかったので，両者の特徴を以下にまとめた．
指標となるのは実行スピードと保守コストのバランスである．
| 観点 | コード実行 | MCP 経由 |
|---|---|---|
| 実行速度 | 数秒〜十数秒 | 数十秒〜1 分 |
| 安定性 | 高い（ブラウザ自動待機） | 中（生成＋実行で変動） |
| 保守コスト | 手動でコード修正 | 自動生成・自己修復が可能 |
| 理解しやすさ | 開発者向け | 非エンジニア（QA, PM）も読める |
| CI 適性 | ◎（高速・再現性高） | △（遅い・AI 層経由） |
| 向いている用途 | 重要な導線・回帰テスト | 仕様確認・AI による自動補助 |
| 理想的な関係 | 「守るコード」 | 「仕様の種」 |
まとめると：
コード実行＝堅牢なテストの完成形
MCP ＝仕様からコードを生み出す助走路
Chrome DevTools（MCP）で実現する「可観測なテスト」
Chrome DevTools の MCP インターフェースを用いると，E2E テストの結果から以下を自動的に取得できる．
- Performance トレース（LCP・CLS・FID・JS Long Task）
- Console エラー／Network ログ
- スクリーンショット・DOM Snapshot
- Lighthouse レポートの JSON 出力
これにより，テストが「動くか」だけでなく，「なぜ落ちたのか」まで可視化できる．
Playwright の失敗時に DevTools MCP で自動解析を行えば，デバッグ時間を数分の 1 に短縮** することも可能となる．
テスト速度と品質のバランスを取る考え方
| 軸 | 速さを取るなら | 品質を取るなら | 現実的な折衷 |
|---|---|---|---|
| 実行時間 | Vitest 中心 | Playwright フル | Vitest ＋ Playwright スモーク |
| カバレッジ | 単体中心 | E2E 厚め | 中心導線＋ロジック厚め |
| メンテコスト | 低 | 高 | MCP 仕様で緩衝 |
| 調査力 | 低 | 高（DevTools MCP） | 定期診断ジョブ導入 |
テスト設計の思考プロセス
-
何を守りたいか？
- ロジック → Vitest
- 導線 → Playwright（コード）
- 仕様 → Playwright（MCP）
-
どのくらい速さを求めるか？
- 開発期：即結果が必要 → Vitest 中心
- 安定期：多少遅くても品質重視 → Playwright 中心
-
保守コストをどう抑えるか？
- UI 変化が激しい部分はまず MCP で自動生成．
- 安定してからコード化．
-
品質を“測る”段階に入ったら
- DevTools MCP で性能とエラーを自動収集．
- テストの合否＋診断レポートまで自動化．
まとめ
- ロジックは全部 Vitest で守る．ユニットテストの徹底は基本．
- 重要な動線は Playwright（コード実行）で堅牢にし，壊れないことを確認する．
- ドラフト仕様や変化の激しい UI は Playwright（MCP）でカバーし，保守コストを抑える．自然言語で書けるので細かい仕様の調整を吸収できる．
Discussion