
QA フェーズを起点に、Next.js のテスト基盤をゼロから設計した話 — Playwright × Vitest × Sentry
QAフェーズへの移行を機に、後回しにしていたテスト基盤を一気に整備した記録です。 同じドメインで連携する3つのNext.jsサイト(利用者向け/提供者向け/社内管理画面)を並行開発し、リリース前のQAに突入したものの、モンキーテストで予想を超えるバグが多発しました。 修正のたびに3サイト全画面を手動で再確認することになり、1サイクルあたり30分〜1時間かかりました。本来テストシナリオ作成に充てるはずだった1週間がバグ修正で埋まりました。 そこでE2Eテスト(Playwright)・コンポーネントテスト(Vitest)・本番エラー監視(Sentry)を 半日で一気に導入 しました。 この記事では、Next.js App Router + TanStack Query + MSW という構成で、ツール選定から実装・CI統合までの過程を解説します。あわせて、SSR / Turbopack固有のハマりポイントと、AIでテストを量産する際の落とし穴も共有します。 この記事で得られること Next.js App Routerで Playwright + MSW を動かすためのSSR対応パターン MSW ハンドラーを E2E と Vitest で共有する設計(モックの二重管理を防ぐ) E2E / Vitest / 手動テストの 仕分け基準(テストピラミッドの設計) Sentryを Next.js 16 + Turbopack で動かす際のハマりポイントと解決策 Sentryの 3層防御マスキング設計(SDKフック / Server-side Scrubber / Generative AI機能停止) ソースマップを Sentry にアップロードしない という運用選択肢とそのトレードオフ AIでテストを量産する際の「成功するテストしか作らない」問題と対策 動作確認環境 種別 バージョン OS macOS 15.x Node.js 24.x パッケージマネージャー pnpm 10.x Next.js 16.x(Turbopack) React 19.x @playwright/test 1.58.x vitest 4.x msw 2.x @sentry/nextjs 10.x @tanstack/react-query 5.x 1. 背景: 手動テストだけでは回らなくなった瞬間 3つのNext.jsサイト(利用者向けサイト/提供者向けサイト/社内管理画面)を約10名のチームで半年かけて並行開発しました。 ...