はじめに

テストコードの追加は、Claude Codeに任せやすい作業のひとつです。
既存のテスト規約を読み、似たパターンを増やし、境界値や異常系を補う作業は、AIエージェントと相性がよい場面があります。

一方で、テストコードの「量産」は危険でもあります。
意味の薄いテスト、壊れやすいモック、実装詳細に依存したアサーション、似たようなケースの重複が増えると、保守コストだけが上がります。

この記事では、Claude Codeの /loop を使ってテストコードを増やすときに、量ではなくレビュー可能な品質を保つ方法を整理します。

テスト量産で先に決めるべきこと

/loop でテストを増やす前に、次の3つを決めます。

  • 対象範囲
  • 増やしたいテストの種類
  • 採用しないテストの条件

たとえば、次のように指定します。

/loop 20m Add tests for src/billing.

Rules:

- Add at most 3 meaningful test cases per iteration.
- Prefer behavior-based tests over implementation-detail tests.
- Run the related test command after edits.
- Do not change production code unless a test exposes a real bug and asks for confirmation.
- Stop when no high-value missing cases remain.

「たくさん追加して」ではなく、「1回のループで最大3件」と制限するのがポイントです。
テストは量が増えるほどレビューが難しくなるため、小さなバッチで増やします。

量産すべきテストと、増やしてはいけないテスト

AIにテスト追加を任せると、書きやすいテストから増えがちです。
しかし、レビューアーが見たいのは、行数ではなくリスクを下げるテストです。

増やす価値が高いテスト 増やすべきでないテスト
境界値 実装の private 関数だけを固定するテスト
異常系 同じ正常系を名前だけ変えたテスト
権限や入力検証 モックの呼び出し回数だけを確認するテスト
回帰バグの再現 スナップショットだけが増えるテスト
外部I/Oの失敗時 仕様を説明しない巨大なfixture依存テスト

/loop に任せるなら、増やしてよいテストだけでなく、増やしてはいけないテストも明記します。

テスト追加用コマンドを作る

チーム運用では、テスト追加のルールをコマンド化しておくと安定します。

---
description: Add focused tests for a target area
argument-hint: [target path or feature]
---

Add tests for: $ARGUMENTS

Rules:

- Inspect existing tests near the target first.
- Follow existing naming, fixture, and assertion style.
- Add a small batch only: up to 3 test cases.
- Prefer behavior and contract tests.
- Avoid tests that only mirror implementation details.
- Run the narrowest relevant test command.
- Report added cases, verification result, and remaining gaps.

このコマンドは、テストの「生成」ではなく、テスト追加のレビュー基準を固定するためにあります。

CLAUDE.mdにテスト方針を書く

テスト量産を安定させるには、プロジェクトの CLAUDE.md にテスト方針を書いておきます。

## Testing Policy

- Prefer behavior-based tests that describe user-visible or API-visible outcomes.
- Keep tests deterministic; avoid real network, clock, and filesystem dependencies unless explicitly required.
- Reuse existing fixture patterns.
- Do not add broad snapshots unless the reviewed area already uses snapshot testing.
- When changing behavior, add tests for normal, boundary, and failure cases.

この方針がないと、AIは近くのテストを真似るだけになります。
近くのテストが良いとは限らないため、チームとしての判断基準を先に与えます。

ループごとの成果物を固定する

テスト追加の /loop では、毎回の成果物を次の形式にします。

## Added Tests

- Case:
- Risk covered:
- File:

## Verification

- Command:
- Result:

## Remaining Gaps

- High-value cases not yet covered:
- Cases intentionally skipped:

## Review Notes

- Possible brittleness:
- Production code changes:

レビューアーにとって重要なのは、「何件増えたか」ではありません。
どのリスクを減らしたかが分かることです。

/loopでテストを増やす実務フロー

実務では、次の順番で回すと安全です。

  1. 対象ディレクトリとテスト方針を指定する
  2. 既存テストを読ませる
  3. 1回のループで少数のテストだけ追加する
  4. 狭いテストコマンドを実行する
  5. 追加したテストの価値を報告させる
  6. 重複や壊れやすさを人間がレビューする
  7. 必要なら次のループを続ける

特に、5番目の「価値の報告」が重要です。
テストの価値を説明できないケースは、量産しても保守負債になりやすいからです。

レビューで見るべき観点

AIが追加したテストコードをレビューするときは、次を確認します。

  • 仕様ではなく実装詳細を固定していないか
  • 既存テストと重複していないか
  • fixtureが過剰に大きくなっていないか
  • モックが実際の契約から離れていないか
  • テスト名から意図が読めるか
  • 失敗したときに原因が分かるアサーションになっているか
  • テスト実行時間が不必要に伸びていないか

/loop で増えたテストは、AIが書いたから危険なのではありません。
短時間で増えるため、人間が意図を確認しないまま残りやすいことが危険です。

PRコメントに変換する例

Comment 
@Reviewer: テストケースは増えていますが、現在の追加分は内部メソッドの呼び出し順序を固定しているため、仕様変更がなくてもリファクタで壊れやすく見えます。
この機能で保証したいのは請求金額の丸め結果なので、外部から見える戻り値ベースのテストに寄せたほうが保守しやすそうです。

このように、テストの数ではなく、テストが固定している責務をレビューします。

まとめ

/loop を使うと、テストコードは簡単に増やせます。
しかし、価値の低いテストを大量に増やすと、品質ではなく保守コストが上がります。

  • 1回のループで追加するテスト数を制限する
  • 増やしてよいテストと避けるべきテストを明記する
  • CLAUDE.md にチームのテスト方針を書く
  • 毎回、どのリスクを減らしたか報告させる
  • 人間はテストの数ではなく、固定している仕様をレビューする

テストコード量産で目指すべきなのは、カバレッジの見た目を増やすことではありません。
変更時に壊れてほしい場所で、正しく壊れるテストを増やすことです。

参考