中小企業のNext.jsフルスクラッチで、テストをどこまで書くか｜AI駆動開発時代の現実的なテスト戦略 (Vitest + Playwright)

中小企業向けの Next.js フルスクラッチ受託をやっていると、「テストはどこまで書くんですか」という質問をよく受けます。予算が限られる案件では、テストを全部書く余裕も、逆にゼロにする勇気もありません。私たちが現場で落ち着いている「ちょうどいいライン」を、2026 年時点の公式情報を踏まえて整理します。AI 駆動開発でテストを書く量が増えたいまだからこそ、改めて考え直す価値があるテーマだと思っています。

Next.js 16 時代のテストは Vitest と Playwright の2本立てが基本

まず前提として、テストのツール選定はかなり落ち着きました。Next.js 公式の「Testing」ガイドでは、ユニットテストに Vitest、E2E テストに Playwright を使う構成が標準的に紹介されています。

公式の Vitest ガイドには、見落としやすいけれど重要な注意書きがあります。「async Server Components は React エコシステムにとって新しいため、Vitest は現時点で対応していない。同期的な Server / Client Components のユニットテストは書けるが、async コンポーネントには E2E テストを推奨する」という趣旨の記述です（出典: Next.js 公式 Vitest ガイド、ドキュメントは Next.js 16.2.7 系、2026-06-01 時点）。

これは中小企業の業務システムでかなり効いてくる制約です。App Router の画面の多くは async な Server Component なので、「Vitest で全部ユニットテストする」という発想だと早々に行き詰まります。私たちは次のように割り切っています。

• Vitest: 同期コンポーネント、Server Actions の純粋なロジック、Zod スキーマの検証
• Playwright: ログインフロー、フォーム送信、async Server Component を含む画面の表示確認

Playwright も公式ガイドで「Chromium・Firefox・WebKit を1つの API で自動化できる E2E テストフレームワーク」と位置づけられており（出典: Next.js 公式 Playwright ガイド）、ブラウザの実挙動に依存する部分はこちらに寄せるのが素直です。

中小企業の予算で「何をテストしないか」を先に決める

テスト戦略というと「何をテストするか」を考えがちですが、私たちはまず「何をテストしないか」を決めます。受託の予算は有限なので、全部に同じ密度のテストを書くと、納期にも費用にも跳ね返ります。

私たちの目安はこうです。

• 必ずテストする: 金額計算、在庫数の増減、権限チェック、外部連携の境界
• E2E で薄く守る: 主要な業務フロー(受注 → 確定 → 通知 など)を1本ずつ通す
• あえて書かない: 見た目だけの静的ページ、管理画面の細かい表示分岐

権限チェックを必ずテストする理由は、認可ロジックの集約と地続きです。私たちが Server Actions のセキュリティを Data Access Layer で守る で書いた通り、DAL に認可を寄せておくと、テストの対象も「DAL の関数」に集約できて、テストコストそのものが下がります。設計とテスト戦略はセットで考えるのが結局いちばん安く済みます。

AI にテストを書かせる前に「テストケースの妥当性」は人間が決める

2026 年に入って、テストコードは AI 駆動開発でかなり速く書けるようになりました。Claude Code や Cursor に「この Server Action のユニットテストを書いて」と頼めば、それらしいテストが一気に出てきます。

ただ、ここに落とし穴があります。AI が書くのは「コードが現状どう動くかをなぞるテスト」になりがちで、「業務的に正しいか」を保証してはくれません。テストが全部グリーンでも、仕様の解釈がずれていれば意味がないわけです。

私たちは Cursor と Claude Code の使い分け でも書いたように、「テストコードは AI に書かせるが、テストケースの妥当性は人間がレビューする」というラインを守っています。具体的には、

1. 人間が「このケースを満たせば仕様 OK」というテストケースの一覧を日本語で先に書く
2. その一覧を AI に渡して、Vitest / Playwright のテストコードに落としてもらう
3. 生成されたテストを人間が読み、境界値や異常系の抜けを補う

この順番を守るだけで、「AI が書いたグリーンなのに本番で壊れる」事故がかなり減ります。テストを速く書けるようになったいまこそ、ケース設計という人間側の仕事が相対的に重くなった、というのが実感です。Claude Code 単体での進め方は Claude Code で Next.js を開発する 2026 年の進め方 にまとめています。

Next.js 16 のキャッシュとテストの関係に注意する

もう1つ、Next.js 16 特有の注意点があります。Next.js 16 では next lint コマンドが廃止され、Turbopack が標準のバンドラになり、"use cache" ディレクティブを中心とした Cache Components が導入されました(出典: Next.js 16 公式ブログ、2025-10-21 公開)。

キャッシュが絡む画面は、テストでも「キャッシュされた古い値を見ているのか、最新の値を見ているのか」が曖昧になりやすい領域です。E2E テストで「更新したのに反映されない」とハマったときは、テストのバグではなくキャッシュ設計の問題であることが多い、という肌感覚があります。use cache の使いどころそのものは Next.js 16 の use cache を中小企業のフルスクラッチでどう使い分けるか で詳しく書いているので、テストでキャッシュ周りにハマったら、まず設計側を疑うのがおすすめです。

過去に痛い目を見た話は Next.js 開発の失敗から学んだこと にもまとめています。テストは「失敗を未然に防ぐ仕組み」なので、過去の失敗パターンとセットで読むと腹落ちしやすいと思います。

まとめ

• Next.js 16 のテストは Vitest(ユニット) + Playwright(E2E)の2本立てが公式でも標準
• async Server Component は Vitest 非対応、E2E で守るのが公式の推奨
• 中小企業の予算では「何をテストしないか」を先に決め、金額・在庫・権限・外部連携に密度を寄せる
• テストコードは AI に書かせてよいが、テストケースの妥当性は人間が責任を持つ
• Next.js 16 のキャッシュ周りでハマったら、テストのバグではなく設計を疑う

「テストにどこまで予算をかけるべきか分からない」「AI 駆動開発でテストを増やしたいが品質が不安」という中小企業の方は、株式会社ゼットリンカーの無料相談フォーム からご相談ください。案件規模に合わせて、現実的なテスト戦略の引き方からお話しします。