AIにテストを書かせるプロンプト3種｜品質チェックリストと失敗回避策

結論: AIはテストケースの列挙とコード化を高速にこなすが、仕様に沿った品質の担保は人間の仕事として残る。テスト設計ファイルとプロンプトテンプレートを用意し、生成後に3軸で品質を判定する仕組みを入れれば、量と質を両立できます。

この記事の要点:

• テスト自動生成は「量を増やす技術」であり、品質を保証する技術ではない（FIXIT「AIテスト自動化の実践」ほか複数ソース一致）
• 仕様は人間が決め、境界値・異常系の列挙とコード化をAIに任せる分担が、品質を落とさない基本設計
• テスト設計ファイル（test-design.md）をリポジトリに置くことで、AIの生成品質を底上げできる（Future Architect「テスト連載2026」の手法）

対象読者: AIコーディングツールを使っているが、テストの自動生成を実務に組み込めていないエンジニア。テストを書く時間を減らしたい一方で、AIが書いたテストの品質に不安がある方。

読了後にできること: テスト設計ファイルを自分のリポジトリに作り、3種のプロンプトでテストを生成し、品質チェックリストで合否を判定する一連の流れを回せるようになる。

この記事で扱うのは、AIにテストを書かせるときの設計原則、コピペで使えるプロンプトテンプレート、生成されたテストの品質を判定する基準、そしてよくある失敗パターンの回避策です。AIが書いたコードのレビュー方法は「AI生成コードの人間レビュー5観点」、Hooksの基本は「Claude Code Hooks入門」を参照してください。

テスト自動生成がいま使える段階に来た理由

AIコーディングツールの進化により、テスト生成のハードルは下がりました。Claude Code、GitHub Copilot、Codexのいずれも、対象のソースコードを渡せばユニットテストのひな形を数秒で出力します。

背景にあるのは3つの変化です。

コーディングエージェントがテスト生成に対応した

Claude CodeはHooks機能でコード変更後にテストを自動実行する仕組みを持ち、Codexはcodex "テストを書いて"のように自然言語でテスト生成を指示できます。GitHub CopilotもCopilot Chatの/testsでテスト生成を受け付けます。ツール側が「テストを書く」ユースケースを明確にサポートし始めた段階です。

テスト設計をファイルで渡せるようになった

Future Architectの「テスト連載2026」では、テスト設計の原則をtest-design.mdというMarkdownファイルにまとめ、AIの計画フェーズとレビューフェーズの両方で参照させる手法が紹介されています（参照日: 2026-09-02）。CLAUDE.mdやリポジトリのルートに置くことで、セッションをまたいでもAIが同じ基準でテストを書きます。

「量は出るが品質が不安」という共通の壁が見えてきた

FIXITの「AIテスト自動化の実践」は、テスト自動生成を**「量を増やす技術であって品質を保証する技術ではない」**と明確に位置づけています（参照日: 2026-09-02）。SHIFTが2026年2月に発表したAIテストエージェントは「テスト実行期間を最大80%短縮」と主張していますが、これはSHIFTのテストエンジニアのノウハウとドキュメント整備を前提にした数値です（SHIFT プレスリリース、参照日: 2026-09-02。なおプレスリリース本文は参照日時点で403のため、日経報道で裏取り）。

ツールが揃った今、何をAIに任せ、何を人間が判断するかの設計が問われています。

「仕様は人間、列挙はAI」— テスト設計の分担を決める

AIにテストを丸投げすると、何が起きるか。Future Architectの記事では、「振る舞いの説明を読んでも『結局このテストは何を保証したいのか』が頭に入ってこない」状態になると指摘されています。仕様の理解なしにコードを読んでテストを量産すると、実装の写し（写経テスト）が増えるだけです。

人間が決めること

• テスト対象の選定: ドメインロジック、アルゴリズム、外部連携の契約を優先する。getter/setterやフレームワーク標準の動作はテスト不要
• 正常系の期待値: 「この入力に対してこの出力が正しい」は仕様の話であり、AIに推測させない
• モック戦略: 何をモック化し何を実際に呼ぶかは、テストの目的（速度優先か結合確認か）に依存する

AIに任せること

• 境界値・異常系の列挙: 仕様で定めた正常系に対して、0、空文字、最大長、型違いなどのエッジケースをAIに洗い出させる
• テストコードの骨格: describe/it構造、Arrange-Act-Assertの配置、アサーションの記述
• 不足ケースの追加: 既存テストを読み込ませ、カバーされていないパスを提案させる

この分担を明文化したものがテスト設計ファイルです。

テスト設計ファイル（test-design.md）の構成

リポジトリのルートまたはCLAUDE.mdと同じ階層に置きます。

# テスト設計原則

## テスト対象の判断基準
- ドメインロジック、アルゴリズム、外部API連携はテストを書く
- フレームワークの標準動作、単純なデータ変換はテストしない

## テスト種別と使い分け
- ユニットテスト: 関数・メソッド単位。外部依存はモック
- 統合テスト: API層〜DB層の結合。テストDBを使い、モックは最小限
- E2Eテスト: ユーザーのクリティカルパスだけ。数を増やさない

## 書き方のルール
- テストフレームワーク: Jest + React Testing Library
- ファイル配置: `__tests__/<対象ファイル名>.test.ts`
- 構造: describe → it。1つのitで1つのアサーション
- 命名: 「〜のとき、〜になる」の日本語で書く
- 仕様の引用: 正常系テストには // 仕様: <根拠> をコメントで添える

## AIが守ること
- 正常系の期待値は仕様コメントなしに推測しない
- モック対象を勝手に増やさない（モック戦略は上記に従う）
- テスト名を英語にしない（日本語プロジェクトの場合）

このファイルがあるだけで、AIの生成品質は目に見えて変わります。「テストを書いて」という指示が、「このプロジェクトのルールに沿ったテストを書いて」に変わるためです。

テスト生成プロンプト3種 — コピペで使えるテンプレート

テスト設計ファイルをリポジトリに置いた前提で、実際にAIへ渡すプロンプトを以下に3種類示す。Claude Code、Codex、GitHub Copilot Chatのいずれでも使える形式です。

1. ユニットテスト生成プロンプト

src/utils/validator.ts のユニットテストを書いてください。

条件:
- test-design.md のルールに従う
- 正常系は以下の仕様に基づく:
  - メールアドレス: RFC 5322準拠。空文字はfalse
  - パスワード: 8文字以上、英大文字・小文字・数字を各1つ以上含む
- 異常系・境界値はAIが列挙する
- 1つのitで1つのアサーション
- テスト名は日本語で「〜のとき、〜になる」形式

ポイントは、正常系の期待値を人間が指定していること。「メールアドレスのバリデーション関数のテストを書いて」だけだと、AIが仕様を推測して誤った期待値を書く原因になります。

2. 統合テスト生成プロンプト

src/api/users.ts の統合テストを書いてください。

条件:
- test-design.md のルールに従う
- テストDBを使う（モックDBは使わない）
- テストごとにDB状態をリセットする
- 以下のエンドポイントを対象にする:
  - POST /users — 正常作成、重複メール、バリデーションエラー
  - GET /users/:id — 存在するID、存在しないID
- レスポンスのステータスコードとボディ構造をアサーションする
- 認証ヘッダーの有無によるアクセス制御もテストする

統合テストではモック戦略を明示してください。指定がないと、AIはデフォルトでDBをモック化し、実際のクエリが通るかどうかを検証しないテストを書くためです。

3. エッジケース網羅プロンプト

src/utils/validator.test.ts を読み、不足しているテストケースを追加して
ください。

確認の観点:
- 境界値（0、空文字、最大長、型の境界）
- 異常系（null、undefined、不正な型、特殊文字）
- 状態遷移（連続呼び出し、順序依存）
- 並行性（該当する場合のみ）

既存テストと重複するケースは追加しない。追加するケースごとに
「// 追加理由: <なぜこのケースが必要か>」をコメントで添える。

このプロンプトは、既存テストを入力として読ませる点が特徴です。ゼロから書かせるよりも、既存のテストコードとテスト設計ファイルの両方をコンテキストに入れることで、重複を避けつつ網羅性を高められます。

AIが書いたテストを3軸で判定する — 品質チェックリスト

テストが生成されたら、次の3軸でレビューします。カバレッジの数値だけでは品質は測れません。

軸1: 仕様準拠 — テストが正しいことを検証しているか

よくある不合格パターン: AIが実装の戻り値をそのまま期待値にしてしまうトートロジーテスト。実装が間違っていてもテストが通るため、バグを検出できません。

軸2: 網羅性 — 抜けているケースがないか

網羅性の評価にはミューテーションテストが有効です。テスト対象のコードに意図的な変異（条件式の反転、定数の変更など）を加え、テストがその変異を検出できるかを測ります。カバレッジ率が90%でも、ミューテーションスコアが60%なら、テストの「効き目」は6割しかありません。

軸3: 保守性 — 半年後のチームが読めるか

保守性が低いテストは、プロダクトコードのリファクタリングのたびに壊れます。「テストの修正コスト > テストの検出価値」になったテストは、維持する意味がありません。

ツール別のテスト自動実行設定 — 書いたテストを即座に回す

テストを生成したら、すぐに実行して結果を確認する仕組みがあると、フィードバックループが速くなります。

Claude Code Hooksでテスト自動実行する

Claude Code HooksのPostToolUseを使えば、コード変更のタイミングでテストをバックグラウンド実行できる仕組みです。.claude/settings.jsonへの設定例を以下に示す。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "npm test -- --bail --silent 2>&1 | tail -20",
        "timeout": 30000
      }
    ]
  }
}

この設定により、Claude CodeがファイルをWriteまたはEditするたびにテストが走ります。--bailは最初の失敗で停止し、--silentは成功時の出力を抑えます。失敗した場合、Claude Codeはその出力を読んで自動で修正を試みます。

ただし、テストの実行時間が長いリポジトリではtimeoutの調整が必要です。Hooksはタイムアウト超過時にプロセスを終了するため、大規模なテストスイートでは対象を限定するか、変更ファイルに関連するテストだけを実行するようcommandを工夫してください。テストが確実に完走する保証はなく、実行環境やテスト内容によって挙動が変わる点は留意が必要です。

GitHub CopilotとCodexのテスト生成設定

GitHub Copilot: VS CodeのCopilot Chatで/testsコマンドを実行すれば、選択中のコードに対するテストが生成される。.github/copilot-instructions.mdにテスト規約を書いておけば、生成時の参照対象になります。

Codex: codex "src/utils/validator.tsのユニットテストを書いて"のように自然言語で指示できる。AGENTS.mdにテスト設計の原則を書いておけば、セッション開始時に自動で読み込まれます。

いずれのツールでも、テスト設計ファイルを用意しておくと生成品質が上がる。ツール固有の機能に頼る前に、プロジェクトのテスト規約をファイルとして明文化するのが最も効果的です。

AIテストで踏みやすい4つの失敗と回避策

失敗1: トートロジーテスト — 実装を写しただけ

実装の戻り値をそのまま期待値にしてしまうパターンです。

// NG: 実装が間違っていてもテストが通る
it('計算結果が正しい', () => {
  const result = calculate(10, 20);
  expect(result).toBe(calculate(10, 20)); // 実装の出力 = 期待値
});

// OK: 仕様に基づく固定値
it('10と20を足すと30になる', () => {
  const result = calculate(10, 20);
  expect(result).toBe(30); // 仕様: 加算
});

回避策: 正常系テストには、プロンプトで仕様を明示する。AIに期待値を推測させない。

失敗2: モック過多 — 結合点を検証していない

外部依存をすべてモック化した結果、「モックが正しく呼ばれたか」だけを検証するテストになるケースです。モックの設定が複雑化し、テストが壊れやすくなります。

回避策: 統合テストでは実際のDB・APIを使い、モックはテスト対象の外側にある依存だけに限定する。プロンプトに「テストDBを使う。モックは外部APIのみ」と書く。

失敗3: 弱いアサーション — 実行しただけで検証していない

// NG: 例外が出ないことしか確認していない
it('ユーザーを作成する', async () => {
  await createUser({ name: 'test', email: 'test@example.com' });
  // アサーションなし
});

// OK: 結果を検証する
it('ユーザーを作成するとDBに保存される', async () => {
  const user = await createUser({ name: 'test', email: 'test@example.com' });
  expect(user.id).toBeDefined();
  expect(user.name).toBe('test');
});

回避策: プロンプトに「各itにexpectを含めること。呼び出しだけで終わるitは不可」と明記する。

失敗4: テスト腐敗 — 生成後に誰もメンテしない

AIが大量にテストを生成した後、プロダクトコードの変更に追従せず、テストが壊れたまま放置されるパターンです。CIで赤いテストを無視する習慣がつくと、テストスイート全体の信頼性が崩壊します。

回避策: CIで全テスト通過を必須にする。壊れたテストは「直すか消すか」を即日判断する。テストの追加と同時に、不要になったテストの削除もAIに提案させる。

どこまでAIに任せるか — 導入の判断基準

テスト自動化のコストは、ツール利用料よりもレビュー工数と維持工数で決まります。

AIに任せてよい範囲

• ユニットテストの骨格生成: 型チェック、バリデーション、データ変換など、入出力が明確な関数
• エッジケースの洗い出し: 人間が見落としがちな境界値や異常入力の列挙
• テストコードのリファクタリング: describe/itの整理、重複コードの共通化

人間が判断すべき範囲

• テスト対象の選定: 何をテストし、何をテストしないかの判断
• ビジネスロジックの正常系期待値: 仕様の解釈はAIに委ねない
• モック戦略の決定: テストの目的に合わせた結合度の設計
• テストの廃棄判断: 価値がなくなったテストを消す決断

SHIFTのAIテストエージェントのように、設計書・仕様書を起点にテストを自律生成するサービスもありますが、ドキュメントが整備されていないプロジェクトでは効果が限定的です（SHIFT プレスリリース、参照日: 2026-09-02）。まずは自分のリポジトリにテスト設計ファイルを置くところから始めるのが、最もコストが低く効果が出やすい方法です。

よくある質問

Q1: テスト設計ファイルはどのくらいの長さが適切ですか

50〜150行が目安です。長すぎるとAIのコンテキストを圧迫し、短すぎると規約として機能しません。「テスト対象の判断基準」「書き方のルール」「AIへの制約」の3セクションを簡潔に書くのがバランスが取りやすいです。

Q2: カバレッジ率は何%を目標にすべきですか

カバレッジ率だけを目標にすると、アサーションのないテストや意味の薄いテストで数値を稼ぐ問題が起きます。80%を目安にしつつ、ミューテーションテストでテストの「効き目」を併せて測ると、カバレッジの質も見えてきます。

Q3: AIが生成したテストをそのままCIに入れてよいですか

品質チェックリスト（仕様準拠・網羅性・保守性）で判定してから入れてください。特に正常系の期待値が仕様と一致しているかは、人間の目で確認が必要です。

Q4: Claude Code以外のツールでもテスト設計ファイルは使えますか

使えます。GitHub Copilotは.github/copilot-instructions.md、CodexはAGENTS.mdに同じ内容を書けば参照されます。テスト設計ファイルの内容はツール非依存なので、プロジェクトの標準ドキュメントとして1つ作れば複数ツールで使い回せます。

Q5: どのテストフレームワークが最もAIと相性がいいですか

Jest（JavaScript/TypeScript）、pytest（Python）、Go標準testingパッケージが、AIの学習データに多く含まれており生成品質が安定しています。マイナーなフレームワークを使う場合は、テスト設計ファイルにフレームワーク固有の記法を明記してください。

テスト設計ファイルを今日作り、来週からチームで回す

AIテスト自動化は、ツールを入れるだけでは回りません。テスト設計ファイルを作り、プロンプトで仕様を渡し、生成結果を品質チェックリストで判定する。この3点を揃えることで、AIの生成速度と人間の品質判断を組み合わせた持続可能なテスト運用になります。

今日やること:

1. リポジトリにtest-design.mdを作り、テスト対象の判断基準と書き方のルールを50行で書く
2. この記事のプロンプトテンプレートをコピーし、自分のプロジェクトの仕様に合わせて正常系の期待値を埋める
3. 1つの関数でテストを生成し、品質チェックリストの3軸で判定する

来週やること: チームにテスト設計ファイルを共有し、PRレビューで「AIが書いたテストの品質チェック」を1項目加える。

次に読むなら: AIが書いたテストだけでなく、AIが書いたコード全体のレビュー方法を知りたい方は「AI生成コードの人間レビュー5観点」が参考になります。

参考・出典

• Future Architect「テスト連載2026を開始します / AIがテストを書く中で、『あるべき仕様』を単体テストで担保するために工夫してみていること」（https://future-architect.github.io/articles/20260615a/）（参照日: 2026-09-02）
• FIXIT「AIテスト自動化の実践｜生成AIでテストを書く設計と注意点」（https://fixit.co.jp/insights/ai-test-automation-practices/）（参照日: 2026-09-02）
• Harmonic Society「Claude Codeでテストコードを自動生成｜単体・統合テストの効率的な書き方」（https://harmonic-society.co.jp/claude-code-test-writing-guide/）（参照日: 2026-09-02）
• アスピック「生成AIでテストを自動化！おすすめツール11選を紹介」（https://www.aspicjapan.org/asu/article/73749）（参照日: 2026-09-02）
• gihyo.jp「生成AIのソフトウェアテストへの活用 ―― "使えるテストコード"を生成するプロンプト文と出力の現在地」（https://gihyo.jp/article/2024/10/generative-ai-for-testing）（参照日: 2026-09-02）
• SHIFT「仕様書を起点にソフトウェアテストを自動化 AIテストエージェントの提供を開始」プレスリリース（https://www.shiftinc.jp/news/20260205_ai_testing_agent/）（参照日: 2026-09-02。プレスリリース本文は参照日時点で403、日経報道で内容確認）
• Qbook「実装は速くなった。テストは追いつくのか？～AI時代に求められるテスト自動化とは～」セミナー情報（https://www.qbook.jp/event/2526.html）（参照日: 2026-09-02）