Claude Codeで自動テスト生成｜手動テストから脱却する実践ガイド【2026年版】

「テストを書く時間がない」のは副業フリーランスの永遠の課題だ。本業の合間に副業をやっていると、テストは後回しになりがちで、結局リファクタや機能追加のたびに動作確認に時間を取られる。

Claude Codeを4ヶ月使ってきて、テスト周りの作業時間が体感で半分以下になった。「テストを書かせる」という用途はLP制作や記事執筆ほど話題にならないが、副業の時給を上げるうえではこっちのほうが効いている気がする。

この記事では、既存コードからのテスト逆生成・テストファースト開発・E2Eの自動化までを、自分が実案件で使っている手順で整理する。

結論：Claude Codeで何がどこまでできるか

やりたいこと	できる度	補足
既存関数のユニットテスト逆生成	◎	Vitest/Jestどちらも自然に書ける
新規機能のテストファースト	◯	仕様を先に文章で渡す前提なら強い
E2Eテスト（Playwright）	◯	操作シナリオを口頭で渡すと骨組みを書いてくれる
既存テストのリファクタ	◎	アサーション粒度の調整が得意
flakyテストの原因特定	△	推測は鋭いが、最終的に人間判断が要る
完全自動でカバレッジ80%超	×	「重要なケース」の選別は人間がやるべき

ざっくり言うと、テストの「型」を作らせるのは速いが、「何をテストすべきか」の判断は人間側に残しておいたほうがいい。これは3ヶ月使ってブレずに感じる線引きだ。

既存コードからテストを逆生成する手順

副業の現場で一番頻度が高い使い方。レガシーコードに後付けでテストを足すとき、Claude Codeに「この関数のテストを書いて」とだけ言うと荒い結果が返ってくることがある。プロンプトに3つの要素を入れるだけで精度が一段上がる。

src/lib/price-calculator.ts のテストを書いてください。

- 使うフレームワーク: Vitest
- カバーしたいケース: 正常系2つ、境界値（0円・上限）、不正入力（負の数・null）
- 既存のテストスタイル: src/lib/discount.test.ts と同じ書き方に揃えて

「既存のテストファイルを参照させる」のがコツ。プロジェクトに1本でも先行サンプルがあれば、命名規則・アサーションの粒度・モックの作り方まで揃えてくれる。テストファイルがゼロのプロジェクトなら、最初の1本だけ自分で書く。

実案件（中小ECサイトの管理画面・TypeScript+Vitest）で計測した結果、1関数あたりのテスト記述時間は手書きで25〜40分→Claude Code経由で7〜12分に縮んだ。書き直す箇所は出るが、ゼロから書くより明らかに速い。

詳しいプロンプトの組み立て方はClaude Codeのプロンプト設計術も参考にしてほしい。

テストファーストで書かせるときのコツ

新規機能の実装で「先にテスト→後で実装」をやらせると、Claude Codeはかなり律儀にやってくれる。ただし仕様を文章で渡す密度で結果がはっきり変わる。

実際に使ったプロンプトの一例。

新しい関数 calculateShippingFee(items, region) を追加します。
仕様:
- items: 商品配列。各商品は { weight: number(g), price: number(円) }
- region: "domestic" | "okinawa" | "overseas"
- domestic: 5kg未満 800円 / 5kg以上 1500円
- okinawa: domestic + 800円
- overseas: 商品合計金額の15%（最低2000円）

まずVitestでテストを書いてください。実装は後で書きます。

仕様を箇条書きで渡すと、テストも仕様の項目ごとに分かれた読みやすい形で返ってくる。「最低2000円」のような境界条件まで自動でケース化されることが多い。

逆に「いい感じにテスト書いて」のような曖昧な指示だと、汎用的なテストになりカバレッジが甘くなる。テストファーストは設計と同義だと割り切って、仕様を言語化する手間は省かないほうがいい。

E2EテストをPlaywrightで自動化

このサイトでもCRITICALパス（トップ→Contact送信完了）にE2Eを1本だけ用意している。Playwrightは設定がやや重いが、Claude Codeに任せると初期セットアップから書いてくれる。

このNext.jsプロジェクトにPlaywrightを導入してください。
- 設定ファイルを作成
- e2e/contact-form.spec.ts を作成
- シナリオ: トップにアクセス → 「相談する」をクリック → フォームに名前・メール・本文を入力 → 送信 → 完了メッセージが出ることを確認
- baseURLは環境変数で切り替え可能に

これでセットアップから1ファイルのテストまで一気通貫で動く。所要時間は20分程度。手で書いていたら半日コースだ。

副業フリーランスにとってE2Eは贅沢品に見えるが、納品後の「動かない」連絡が1件減るだけで時給換算では確実にプラスになる。受注額10万円のLP案件で1時間の手戻りを防げれば、それだけでテスト工数は回収できる計算だ。

このサイトのE2E導入の経緯はAIでWebサイト運用を完全自動化した方法にも書いた。

自分がハマった3つの失敗パターン

ここからは正直な失敗談。同じ落とし穴は踏まないでほしい。

モック地獄

ユニットテストで外部APIや日付処理が絡むと、Claude Codeはモックを大量に生成してくる。最初は「速い！」と喜んでいたが、3週間後にモックの整合性が崩れてテストが本物のバグを検知できない状態になっていた。

対策として、モックは「自分で書いた共通モック1ファイル」を読み込ませる形に統一した。「mockServer.ts のスタイルを使ってください」と指定するだけで、無秩序な個別モックの増殖は止まる。

テストが通ったから安心問題

Claude Codeが書いたテストは、最初の段階で必ず緑になるよう調整して返ってくる。これは便利だが、「テストが通った=コードが正しい」とは限らない。実際、アサーションが甘くて何も検証していないテストが混じっていたことが2回あった。

expect(result).toBeTruthy() のような緩いアサーションが出てきたら警戒する。「期待値を具体値で書き直して」と指示すれば修正してくれる。

flakyテストの原因切り分け

たまに通ってたまに落ちるテスト（flakyテスト）が出ると、Claude Codeに「原因を調べて」と聞きたくなる。経験上、原因の推測はそこそこ当てるが、最終的な切り分けは人間がやらないと地雷を踏む。

非同期待ちが甘いケース、テスト同士の状態リーク、CIとローカルの環境差。このあたりは「テストコードに対する経験」が物を言うので、AIに任せきると逆に時間を食う。「容疑者を3つ挙げてもらってから自分で潰す」くらいの使い方がちょうどいい。

副業フリーランスがテスト自動化に投資すべき理由

副業はとにかく時間が足りない。だからこそテストを書かない方向に行きがちだが、これは長期的には時給を下げる選択だ。

自分の場合、テスト自動化を導入してから「納品後の動作確認問い合わせ」が体感で月3〜4件減った。1件あたり対応に30分〜1時間取られると考えると、月2時間以上の時間が浮く。本業終わりの2時間は副業の生命線なので、ここの差は大きい。

Claude Codeはテスト記述のハードルを実用範囲まで下げてくれる。「テスト書いてからリファクタしよう」と思える状態になるのが大きい。

Claude Code自体の導入手順はClaude Codeの始め方にまとめている。テストだけでなくブログ執筆・LP制作まで含めた使い方を見たい方はClaude Codeを副業で3ヶ月使った正直な評価も参考にしてほしい。

---

AI業務自動化や開発テスト導入の代行を検討している方はCoconalaのサービスページからご相談どうぞ。テスト導入だけのスポット相談も対応します。