導入
「テストは大事だと頭ではわかっているけれど、書くのが面倒で結局後回しになる」――エンジニアでもそうなのですから、非エンジニアの方ならなおさらです。しかし、ClaudeCodeを使えば、テストコードの作成は劇的に楽になります。関数の中身を読んで、想定されるケースを洗い出し、Jestのテストコードとして書き出すまでを自動でこなしてくれるからです。本記事では、JavaScriptのテスティングフレームワーク「Jest」とClaudeCodeを組み合わせて、テスト自動化を実現する方法を、導入から実践まで丁寧に解説していきます。8,000字を超えるボリュームでお届けしますので、この記事を一通り読めば、自分のプロジェクトにテスト文化を導入できるようになります。
結論
まず結論からお伝えします。ClaudeCodeとJestを組み合わせると、テストコードの作成・実行・カバレッジ取得が短時間で完了します。具体的には、対象のファイルをClaudeCodeに読み込ませて「このファイルのユニットテストをJestで書いて」と指示するだけで、Arrange-Act-Assertの構造に沿った質の高いテストコードが出力されます。さらに、npm testコマンドの実行、失敗ケースの修正、--coverageオプションでのカバレッジ計測、CIへの組み込みまで、ClaudeCodeに自然言語で依頼して進めることができます。ポイントは三つあります。第一に、テスト対象のコードを必ずClaudeCodeに読ませること。第二に、正常系・異常系・境界値を明示的に依頼すること。第三に、生成されたテストを実行して、失敗があれば原因をClaudeCodeにそのまま投げて修正させること。この三つを守れば、テスト初心者でも数時間でカバレッジ80%以上のプロジェクトに到達できます。なお、Cloudflare Workers環境でのテストはJestではなくVitestやMiniflareを使うケースが多いため、本記事の知識を応用してそちらに展開してください。
Jestとは何か？基礎をやさしく解説
Jestは、Meta（旧Facebook）が開発したJavaScript/TypeScript用のテスティングフレームワークです。Reactアプリ、Next.jsアプリ、Node.jsのバックエンドなど、JavaScript系のあらゆるプロジェクトで使われています。Jestの特徴は、テストランナー（テストを実行する仕組み）、アサーション（期待値を検証する仕組み）、モック（外部依存を差し替える仕組み）、カバレッジ計測がすべて一つに統合されていることです。他のツールと組み合わせる必要がなく、npm install jest一発で始められる手軽さが、初心者にも優しいポイントです。
テストには大きく分けて三種類あります。一つ目が「ユニットテスト」で、関数やクラス単体の動作を検証します。二つ目が「インテグレーションテスト」で、複数のモジュールを組み合わせた挙動を検証します。三つ目が「E2Eテスト（End-to-End）」で、ユーザーが実際にアプリを操作する流れを再現して検証します。Jestは主にユニットテストとインテグレーションテストで力を発揮し、E2EテストにはPlaywrightやCypressと組み合わせて使うのが一般的です。
なぜテストを書くのかというと、コードを変更したときに「以前正しく動いていた部分が壊れていないか」を機械的に確認できるからです。テストがあると、リファクタリング（コードの整理整頓）に踏み切る勇気が湧きますし、新機能を追加するときも自信を持って進められます。逆にテストがないと、変更のたびに手で全機能を確認することになり、いずれ破綻します。
ClaudeCodeでJestをセットアップする手順
それではClaudeCodeを使って、Jestをプロジェクトに導入してみましょう。前提として、Node.jsとnpm（あるいはpnpm、yarn）がインストールされていて、package.jsonが存在するプロジェクトを想定します。
ClaudeCodeのターミナルで以下のように依頼します。
このプロジェクトにJestを導入してください。TypeScriptに対応させ、ts-jestを使ってください。package.jsonのscriptsに"test"と"test:coverage"を追加してください。
ClaudeCodeは次のような流れで作業を進めます。
package.jsonを読み込んでプロジェクト構成を把握するnpm install --save-dev jest ts-jest @types/jestを提案・実行するjest.config.jsまたはjest.config.tsを生成するpackage.jsonのscriptsに"test": "jest"、"test:coverage": "jest --coverage"を追加する
生成されるjest.config.tsの例は以下のとおりです。
import type { Config } from 'jest';
const config: Config = {
preset: 'ts-jest',
testEnvironment: 'node',
roots: ['<rootDir>/src', '<rootDir>/tests'],
testMatch: ['**/*.test.ts'],
collectCoverageFrom: [
'src/**/*.ts',
'!src/**/*.d.ts',
'!src/**/index.ts',
],
coverageThreshold: {
global: {
branches: 70,
functions: 80,
lines: 80,
statements: 80,
},
},
};
export default config;
coverageThresholdを設定しておくと、カバレッジが基準を下回ったときにテストが失敗扱いになるため、品質を維持しやすくなります。
ユニットテストをClaudeCodeで生成する
セットアップが終わったら、実際のテスト生成に進みましょう。例えば次のようなsrc/utils/calculator.tsがあったとします。
export function add(a: number, b: number): number {
return a + b;
}
export function divide(a: number, b: number): number {
if (b === 0) {
throw new Error('Cannot divide by zero');
}
return a / b;
}
export function isEven(n: number): boolean {
return n % 2 === 0;
}
ClaudeCodeに以下のように依頼します。
src/utils/calculator.tsを読んで、Jestのユニットテストを生成してください。正常系、異常系、境界値の三観点で網羅してください。出力先はtests/utils/calculator.test.tsです。
生成されるテストコードは次のようなものになります。
import { add, divide, isEven } from '../../src/utils/calculator';
describe('calculator', () => {
describe('add', () => {
it('正の数同士を加算できる', () => {
expect(add(2, 3)).toBe(5);
});
it('負の数を含む加算ができる', () => {
expect(add(-2, 5)).toBe(3);
});
it('ゼロを加算しても値が変わらない', () => {
expect(add(7, 0)).toBe(7);
});
});
describe('divide', () => {
it('整数同士を割り算できる', () => {
expect(divide(10, 2)).toBe(5);
});
it('小数を返すケースを処理できる', () => {
expect(divide(7, 2)).toBe(3.5);
});
it('ゼロで割るとエラーを投げる', () => {
expect(() => divide(5, 0)).toThrow('Cannot divide by zero');
});
});
describe('isEven', () => {
it('偶数はtrueを返す', () => {
expect(isEven(4)).toBe(true);
});
it('奇数はfalseを返す', () => {
expect(isEven(7)).toBe(false);
});
it('ゼロは偶数として扱う', () => {
expect(isEven(0)).toBe(true);
});
});
});
実行はnpm testです。すべて緑色の「PASS」が並べば成功です。一つでも赤い「FAIL」が出たら、その出力をそのままClaudeCodeに貼り付けて「このテストが失敗しています。原因を調査して修正してください」と依頼すれば、コードかテストのどちらが間違っているかを判断して直してくれます。
非同期処理・APIコールのテスト
実務では、fetchやaxiosを使ったAPI呼び出しを含む関数をテストする場面が多くあります。Jestにはjest.mockという機能があり、外部依存を差し替えられます。ClaudeCodeに以下のように依頼してみましょう。
src/services/userApi.tsのfetchUser関数のテストを書いてください。fetch APIをモックして、成功時と失敗時の両方をカバーしてください。
生成例は次のとおりです。
import { fetchUser } from '../../src/services/userApi';
global.fetch = jest.fn();
describe('fetchUser', () => {
beforeEach(() => {
(global.fetch as jest.Mock).mockReset();
});
it('200レスポンスでユーザー情報を返す', async () => {
(global.fetch as jest.Mock).mockResolvedValueOnce({
ok: true,
json: async () => ({ id: 1, name: 'Taro' }),
});
const user = await fetchUser(1);
expect(user).toEqual({ id: 1, name: 'Taro' });
expect(global.fetch).toHaveBeenCalledWith('/api/users/1');
});
it('404レスポンスでエラーを投げる', async () => {
(global.fetch as jest.Mock).mockResolvedValueOnce({
ok: false,
status: 404,
});
await expect(fetchUser(999)).rejects.toThrow('User not found');
});
});
このように、外部APIを実際に叩かなくても、レスポンスを偽装してロジック部分だけをテストできます。ClaudeCodeはモックの書き方を熟知しているので、依頼すれば即座に適切なコードを返してくれます。
E2EテストとPlaywrightの組み合わせ
JestはE2Eテストにはあまり向かないので、ブラウザを実際に動かして検証するE2EテストにはPlaywrightを使うのが2026年現在の主流です。ClaudeCodeに以下のように依頼します。
PlaywrightをこのNext.jsプロジェクトに導入し、ログインフローのE2Eテストを書いてください。テストはe2e/login.spec.tsに保存してください。
生成されるテストの例です。
import { test, expect } from '@playwright/test';
test('ログイン後にダッシュボードに遷移する', async ({ page }) => {
await page.goto('http://localhost:3000/login');
await page.fill('input[name="email"]', 'test@example.com');
await page.fill('input[name="password"]', 'password123');
await page.click('button[type="submit"]');
await expect(page).toHaveURL(/\/dashboard/);
await expect(page.getByRole('heading', { name: 'ダッシュボード' })).toBeVisible();
});
E2Eテストは実行に時間がかかるため、CIではプルリクエスト時のみに限定して動かす、といった工夫もClaudeCodeに依頼できます。
カバレッジの取得と改善
テストの量を客観的に測る指標が「カバレッジ」です。Jestではnpm run test:coverageで計測できます。実行すると、coverage/フォルダにHTMLレポートが出力され、どの行がテストされていないかが赤色でハイライトされます。
カバレッジレポートをHTMLで開きたいです。手順を教えてください。また、カバーされていない行を一覧化して、優先的にテストすべき箇所を提案してください。
このように依頼すると、ClaudeCodeはcoverage/lcov-report/index.htmlを開く手順を教え、さらに重要度の高い未カバー部分（条件分岐、エラーハンドリング、外部API呼び出しなど）を優先順位付けして示してくれます。
カバレッジ100%を目指すのは現実的ではありませんが、ビジネスロジックの中核部分は90%以上、UI部分は60-70%程度を目標にすると、テストのROI（投資対効果）が高くなります。
CI/CDへのテスト組み込み
最後に、GitHub Actionsを使ったCI上でのテスト実行も自動化しましょう。
GitHub Actionsで、プルリクエスト時に自動でJestのテストを実行するワークフローを作成してください。Node.js 20を使い、カバレッジが基準を下回ったら失敗扱いにしてください。
生成例は次のとおりです。
name: Test
on:
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'npm'
- run: npm ci
- run: npm run test:coverage
- uses: actions/upload-artifact@v4
if: always()
with:
name: coverage-report
path: coverage/
これでプルリクエストごとに自動でテストが走り、カバレッジレポートも保存されるようになります。
実践チュートリアル：実プロンプト例集
ここまで紹介してきたものも含めて、実務で使えるプロンプト例を整理しておきます。
プロンプト例1：プロジェクト全体のテスト生成
src/フォルダ内のすべての.tsファイルを読んで、それぞれに対応するJestのテストファイルをtests/以下に生成してください。ディレクトリ構造はsrc/と同じに揃えてください。
プロンプト例2：失敗テストの修正
以下のテスト結果を見て、失敗している原因を調査して修正してください。テストコードが間違っているのか、実装コードが間違っているのかを判断したうえで、適切な方を修正してください。
（ここにnpm testの出力を貼り付け）
プロンプト例3：スナップショットテストの追加
src/components/UserCard.tsxにJestのスナップショットテストを追加してください。React Testing Libraryを併用してください。
プロンプト例4：パラメタライズドテストへの書き換え
tests/utils/validator.test.tsの似たようなテストケースを、it.eachを使ったパラメタライズドテストに書き換えてください。
プロンプト例5：モックの差し替え
tests/services/paymentService.test.tsでaxiosの代わりにmswを使ったモックに切り替えてください。理由は、HTTPレベルでのテストの方が実装の差し替えに強いからです。
プロンプト例6：テスト実行速度の改善
現在のJestテストが30秒以上かかっています。並列実行の設定、testPathIgnorePatternsの見直し、setupFilesの最適化など、速度改善の提案をしてください。
これらを叩き台にして、自分のプロジェクトに合わせて調整してください。
FAQ
Q1. ClaudeCodeが生成したテストはそのまま信用していい？ 基本的には品質は高いですが、必ず一度実行して通ることを確認してください。また、テストが「常に通る」内容になっていないか（例：トートロジー的な検証になっていないか）も目視で確認しましょう。テストの数だけでなく、検証している中身が意味を持つかを意識することが大切です。
Q2. Jestのテストが遅いのですが、改善方法は？
--maxWorkersオプションでワーカー数を調整する、testPathIgnorePatternsで不要なパスを除外する、重いセットアップをglobalSetupに移動する、などが定番です。ClaudeCodeに現状の設定を見せて「速度改善案を出して」と依頼すると的確なアドバイスがもらえます。
Q3. ReactコンポーネントのテストもJestでできる？ できます。React Testing Libraryを併用するのが2026年現在の標準です。ClaudeCodeに「React Testing LibraryでこのコンポーネントのテストをJestで書いて」と依頼すれば、render、screen、userEventを使った現代的なテストコードを生成してくれます。
Q4. カバレッジは何%を目標にすべき？ ビジネスロジックは80-90%、UI周辺は60-70%が現実的な目標です。100%を目指すと逆にテストのためのテストが増え、保守コストが高くなります。重要なのは「カバレッジが高いこと」ではなく「重要な分岐が網羅されていること」です。
Q5. テストファイルはどこに置くのが良い？
プロジェクトの好みによります。__tests__/フォルダにまとめる流派、src/の隣に同名で置く流派、tests/に集約する流派があります。チームの方針に従い、jest.configのtestMatchを合わせるのがおすすめです。
Q6. Cloudflare Workers環境でもJestは使える？
Workers環境では、@cloudflare/vitest-pool-workersを使ったVitestが推奨されています。Jestを無理に使うよりVitestに切り替える方が楽です。ClaudeCodeに「このWorkersプロジェクトのテスト基盤をVitestで構築して」と依頼すれば、移行も自動化できます。
Q7. テストを書く時間がないのですが、どこから始めればいい？ バグが起きたら、まずそのバグを再現するテストを一つ書き、そのテストが通るように修正する、という「リグレッションテスト」から始めるのがおすすめです。これだけで同じバグの再発を防げます。
まとめ
ClaudeCodeとJestを組み合わせると、テストの自動化は驚くほどスムーズに進みます。本記事のポイントを振り返ります。第一に、Jestのセットアップからjest.config.tsの生成まで、ClaudeCodeに依頼すれば数分で完了します。第二に、関数やコンポーネント単位のユニットテストは「正常系・異常系・境界値」を意識した依頼で網羅性の高いコードが手に入ります。第三に、E2EテストはPlaywrightと組み合わせ、CIにはGitHub Actionsを使うのが2026年現在の王道です。第四に、カバレッジは数値だけでなく中身の意味を確認することが本質的です。テストは「未来の自分とチームへの保険」です。ClaudeCodeという強力な味方がいる今こそ、テスト文化を取り入れる絶好のタイミングです。今日から少しずつ、自分のプロジェクトにテストを書き始めてみてください。