「テストコードを書くのが面倒くさい」「AIに任せてみたけど的外れなテストが生成される」と感じたことはありませんか？
Claude CodeのSkills機能を使いこなせば、テスト自動生成の精度と速度が劇的に変わります。この記事では、私が実際に試行錯誤して見つけたテスト自動生成を効率化するテクニック5選を紹介します。読み終わる頃には「Skillsってこう使えばよかったのか」と納得できるはずです。
結論：テスト自動生成の質は「Skillsへの文脈の渡し方」で決まる
テスト自動生成でうまくいかないと悩んでいませんか？
結論から言うと、生成されるテストの品質は「ClaudeにどれだけプロジェクトのコンテキストをSkills経由で渡せているか」でほぼ決まります。
| 観点 | 内容 |
|---|---|
| Point（結論） | テスト品質はSkillsの文脈設計で決まる |
| Reason（理由） | Claudeは都度コードを読むのではなくSkillsの情報を優先的に参照するため |
| Example（例） | テストフレームワークや命名規則を明示すると生成物が一気に揃う |
| Point（再結論） | Skillsに「プロジェクト固有の前提」を書くだけで精度が跳ね上がる |
なぜ「文脈の渡し方」がそこまで重要なのか
Claudeは優秀ですが、「このプロジェクトがどんなテスト戦略を採用しているか」「どのフレームワークを使っているか」「どんな命名規則があるか」は、指定しなければ推測するしかありません。
推測で生成されたテストは、動くこともあれば全く的外れなこともある。私はこれを何度も経験しました。毎回「このプロジェクトでは〇〇を使っています」と伝えるのは非効率ですし、忘れたら即アウトです。
Skillsに一度プロジェクトの前提を書いてしまえば、その後はClaudeが毎回「このプロジェクトのルール」を参照しながらテストを生成してくれます。つまり、Skillsはチームの暗黙知を明文化する場所でもあるわけです。
エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む
Claude CodeのSkillsでテスト自動生成を効率化するテクニック5選
✅ テクニック1：テストフレームワークと命名規則をSKILL.mdに明記する
最初にやるべきはこれです。Claudeがテストを生成するとき、フレームワークの指定がなければJestで書いたりVitestで書いたり、毎回バラバラになります。
## 使用テストフレームワーク
- Unit Test: Vitest
- E2E Test: Playwright
- APIテスト: supertest
## 命名規則
- テストファイル: `{対象ファイル名}.test.ts`
- describe: 対象クラス・関数名（例: `describe('UserService')`）
- it/test: 「〜のとき、〜である」形式（例: `it('入力が空のとき、エラーを返す')`）
◎ これだけで生成されるテストの「見た目」が一気に揃います。コードレビューの負荷も下がるので、チームで使う場合は特に効果的です。
| 設定前 | 設定後 |
|---|---|
| ❌ フレームワークが毎回バラバラ | ✅ 常にVitestで統一される |
| ❌ describe名が不統一 | ✅ 命名規則に沿った構造になる |
| ❌ レビューで毎回指摘が発生 | ✅ 初回から基準を満たした状態で生成 |
✅ テクニック2：テストの「カバレッジ方針」をSkillsに定義する
「どこまでテストを書くか」の方針がないと、Claudeは過剰にテストを生成したり、逆に重要なケースを見落としたりします。
## カバレッジ方針
- 正常系・異常系・境界値の3パターンを必ずカバーすること
- privateメソッドは直接テストせず、publicメソッド経由で検証する
- 外部APIコール・DBアクセスは必ずモック化する
- スナップショットテストは原則使用しない
私はこれを書く前、「なんかテストが薄いな」と感じながら毎回手動で異常系を追加していました。方針を明示してからは、最初から3パターンが揃った状態で生成されるようになりました。
✅ テクニック3：モック・スタブのパターンをサンプルとして載せる
「モック化してください」と伝えても、プロジェクトで使っているモックの書き方と違うコードが生成されることがあります。これはClaudeがプロジェクト固有のモックパターンを知らないのが原因です。
## モックの書き方（サンプル）
### 外部APIのモック例
typescript
vi.mock('@/lib/apiClient', () => ({
fetchUser: vi.fn().mockResolvedValue({ id: 1, name: 'テストユーザー' })
}))
### Repositoryのモック例
typescript
const mockUserRepository = {
findById: vi.fn(),
save: vi.fn(),
} satisfies UserRepository
◎ サンプルコードをSKILL.mdに入れておくと、Claudeが「このプロジェクトのモックはこう書く」と学習した状態でテストを生成してくれます。数行のサンプルが、生成品質を大きく底上げします。
✅ テクニック4：テスト生成のトリガー条件を明確にする
Skillsのdescriptionが曖昧だと、テスト生成Skillが意図しない場面で発火したり、逆に使われなかったりします。
# ✅ descriptionの書き方例
description: |
TypeScript・Reactプロジェクトのユニットテストを自動生成するSkill。
ユーザーが「テストを書いて」「テストを生成して」「〜のテストを追加して」
と言ったときに使用する。
E2Eテスト・統合テストの生成にはe2e-test-skillを使うこと。
既存テストのデバッグや修正には使用しない。
| 条件の種類 | 書くべき内容 |
|---|---|
| ✅ 発火させたい場面 | 「テストを書いて」「〜のテストを生成して」 |
| ❌ 発火させたくない場面 | E2E・統合テスト・既存テストの修正 |
| ◎ 他Skillへの誘導 | 「E2EはPlaywright-skillを使うこと」 |
✅ テクニック5：テスト生成後の「セルフチェックリスト」をSKILL.mdに入れる
生成されたテストをそのまま使うと、assertionが甘かったり、エラーメッセージが雑だったりすることがあります。Claudeに「生成後に自分でチェックする項目」を定義しておくと、品質がさらに上がります。
## テスト生成後のセルフチェックリスト
Claudeは以下を必ず確認してからテストコードを出力すること。
- [ ] 正常系・異常系・境界値がすべて含まれているか
- [ ] assertionが「何を確認しているか」明確になっているか
- [ ] エラーメッセージが具体的で、失敗時に原因がわかるか
- [ ] 外部依存がすべてモック化されているか
- [ ] テスト同士が独立しており、実行順序に依存していないか
◎ このチェックリストを入れてから、「生成されたテストが通らない」「assertionがtoBeTruthy()だけになっている」といった問題がほぼなくなりました。
まとめ
| テクニック | 効果 |
|---|---|
| ✅ フレームワーク・命名規則を明記 | 生成物の見た目が統一される |
| ✅ カバレッジ方針を定義 | 正常系・異常系・境界値が揃う |
| ✅ モックのサンプルを載せる | プロジェクト固有の書き方に合う |
| ✅ トリガー条件を明確にする | 意図しない発火・未使用を防ぐ |
| ✅ セルフチェックリストを入れる | 生成品質の底上げができる |
Skillsにプロジェクトの前提をしっかり書いておくだけで、テスト自動生成の体験は大きく変わります。最初の設定に30分かけると、その後の時間を何倍も節約できます。ぜひ試してみてください。
エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む