「テストカバレッジを上げたいけど、どこから手をつければいいかわからない」「AIにテストを生成させても、カバレッジが思うように上がらない」と感じたことはありませんか？
Claude CodeのSkills機能を正しく活用すれば、カバレッジ向上の作業を仕組み化できます。この記事では、私が実際に試して効果があったテストカバレッジを上げるアプローチ5選を紹介します。「なぜカバレッジが上がらないのか」という根本の疑問にも答えていくので、ぜひ最後まで読んでみてください。
結論：カバレッジが上がらない原因は「何をテストすべきか」をSkillsに伝えていないから
テストカバレッジがなかなか上がらなくて悩んでいませんか？
結論から言うと、カバレッジが伸び悩む原因のほとんどは「Claudeがプロジェクトのどこを重点的にテストすべきか知らないまま生成している」ことにあります。
| 観点 | 内容 |
|---|---|
| Point（結論） | カバレッジが上がらないのはSkillsへの優先度情報が不足しているから |
| Reason（理由） | 優先度なしだとClaudeは「書きやすいテスト」から生成してしまうため |
| Example（例） | ビジネスロジックより単純なutilsのテストを先に書いてしまう |
| Point（再結論） | 「どこを・どの順番で・どの深さで」をSkillsに定義すれば解決する |
なぜ「優先度の情報」がカバレッジ向上に直結するのか
テストカバレッジを上げる作業は、ただコードを書く量の問題ではありません。どこを埋めるかの戦略が重要です。
Claudeは優秀ですが、「このプロジェクトで最もバグが起きやすい層はどこか」「ビジネスロジックとユーティリティのどちらを優先すべきか」は教えてもらわないとわかりません。何も指定しなければ、生成しやすいシンプルな関数のテストから埋めていく傾向があります。結果として、カバレッジ数値は少し上がっても「重要な部分は相変わらず未テスト」という状態になりがちです。
カバレッジ80%を達成したのにリリース直後にビジネスロジック層でバグが出たときです。数値は正直で、でも数値だけでは品質は測れない。だからこそ、Skillsに「何を優先するか」を書くのが一番の近道だと思っています。
エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む
Claude CodeのSkillsを使ってテストカバレッジを上げるアプローチ5選
✅ アプローチ1：カバレッジの「優先レイヤー」をSkillsに定義する
まず最初にやるべきは、どの層から優先的にカバレッジを上げるかをSKILL.mdに書くことです。指定がなければClaudeは「生成しやすい場所」から埋めていきます。
## テストカバレッジの優先順位
以下の順番でカバレッジを上げること。
1. ◎ ビジネスロジック層（Service・UseCase）→ 最優先
2. ✅ データ変換・バリデーション層（Validator・Transformer）
3. ✅ ユーティリティ関数（utils/）
4. ❌ 単純なgetterやDTO → 原則不要
| 優先度 | 対象層 | 理由 |
|---|---|---|
| ◎ 最優先 | Service・UseCase | バグの影響範囲が最大 |
| ✅ 優先 | Validator・Transformer | 入出力の誤りが下流に波及する |
| ✅ 必要に応じて | utils/ | 再利用頻度が高く影響範囲が広い |
| ❌ 原則不要 | 単純なgetter・DTO | テストコストに対してリターンが小さい |
これを書いておくだけで、Claudeが「どこを埋めるべきか」を正しく判断できるようになります。
✅ アプローチ2：未カバー箇所の分析をSkillsのタスクとして組み込む
カバレッジを上げるには「どこが未テストか」を把握するところから始まります。この分析ステップ自体をSkillに組み込むと、毎回手動で確認する手間が省けます。
## カバレッジ分析の手順
1. `npx vitest run --coverage` を実行してカバレッジレポートを取得する
2. coverage/index.html または coverage-summary.json を参照する
3. カバレッジが低いファイルを以下の基準で分類する
- ❌ 50%未満 → 即対応
- ⚠️ 50〜80% → 優先度高
- ✅ 80%以上 → 維持でOK
4. 分類結果をもとに、優先レイヤー定義に沿ってテストを生成する
◎ 分析→生成の流れをSkillに書いておくと、「カバレッジ上げて」の一言でここまでやってくれるようになります。
✅ アプローチ3：境界値・異常系のパターン表をSKILL.mdに入れる
カバレッジが伸び悩む原因のひとつが、正常系しかテストされていないことです。Claudeに異常系を生成させるには、どんなパターンを期待するかを明示するのが一番確実です。
## 必須テストパターン一覧
| パターン種別 | 具体例 |
|-------------|--------|
| 正常系 | 正しい入力で期待通りの結果が返る |
| 異常系（入力不正） | null・undefined・空文字・型違い |
| 境界値 | 最小値・最大値・ちょうど上限・上限+1 |
| 副作用の検証 | DBへの書き込み・外部API呼び出し回数 |
| 例外ハンドリング | エラーが正しくthrowされるか |
上記5パターンを網羅しない場合、テスト生成は不完全とみなす。
私はこのパターン表を入れてから、「あ、境界値書いてないな」と後で気づくことがほぼなくなりました。Claudeが最初から5パターンを意識して生成してくれるようになるので、手直しの時間が大幅に減ります。
✅ アプローチ4：既存コードの「テスト追加しやすい切り口」をSkillsに教える
レガシーコードや複雑な依存関係があるコードは、そのままテストを書こうとしても難しいことがあります。Claudeに「どう切り込むか」の方針を渡すと、実用的なテストが生成されやすくなります。
## テストが書きにくいコードへのアプローチ方針
### 外部依存が多い場合
- 外部サービス・DBはすべてモック化してユニットテストを書く
- インターフェースが切れている場合はそこでモックを差し込む
### 副作用が混在している場合
- 副作用のある処理を切り出してから個別にテストする
- 切り出しが難しい場合はスパイを使って呼び出しだけ検証する
### テスト対象が巨大な場合
- 関数の責務を確認し、最も影響範囲が広いパスを優先する
- 全パスを一度に埋めようとせず、critical pathから順番に対応する
| コードの状態 | 推奨アプローチ |
|---|---|
| 外部依存が多い | モック化してユニットテストを書く |
| 副作用が混在 | 副作用を切り出してから個別テスト |
| 関数が巨大 | critical pathから優先的にカバー |
| レガシー・テストなし | 既存動作を「承認テスト」として記録してから改善 |
✅ アプローチ5：カバレッジ目標値と「上げすぎない基準」を定義する
カバレッジは高ければいいわけではありません。100%を目指してコストをかけすぎると、テストの保守負荷が上がるだけになることがあります。目標値と「ここは不要」という基準をSkillsに書いておくと、Claudeが過剰なテストを生成しなくなります。
## カバレッジ目標と除外基準
### 目標値
- ビジネスロジック層（Service・UseCase）: 90%以上
- バリデーション・変換層: 85%以上
- ユーティリティ: 80%以上
- 全体: 80%を基準とする
### テスト不要な対象（カバレッジ計測から除外）
- ❌ 設定ファイル（config/）
- ❌ 型定義のみのファイル（types/）
- ❌ 単純なindex.tsのre-export
- ❌ マイグレーションファイル
◎ 「何%を目指すか」だけでなく「どこは不要か」を定義することで、Claudeがコストパフォーマンスを意識したテスト生成をしてくれるようになります。
まとめ
| アプローチ | 効果 |
|---|---|
| ✅ 優先レイヤーを定義する | 重要な層から効率よくカバレッジが上がる |
| ✅ 分析手順をSkillに組み込む | 未テスト箇所の特定が自動化できる |
| ✅ テストパターン表を入れる | 正常系・異常系・境界値が最初から揃う |
| ✅ 切り込み方針を渡す | レガシーコードにも対応できる |
| ✅ 目標値と除外基準を定義する | 過剰テストを防いで保守コストを下げる |
カバレッジを上げる作業は「数値を埋める作業」ではなく「重要な部分を守る仕組みを作る作業」です。Skillsにプロジェクトの戦略を書いておくだけで、Claudeが毎回その戦略に沿ってテストを生成してくれます。ぜひ一度、SKILL.mdを見直してみてください。
エンジニアなら読むべき本を30冊以上紹介しています。
正直、私の仕事のやり方をガラッと変えた神本やSQLのチューニングに悩んだ時にめちゃくちゃ役に立ったもあります👇
→記事を読む