Claude Codeでテストシナリオ作成からCI組み込みまで自動化する方法

〜小規模チームが「テストの負担を減らしながら品質を上げる」現実解〜

「テストは全部通った。リリースしよう」——その数時間後

ユーザーから問い合わせが入る。

本番でしか起きない不具合。

慌てて調べると、テストでは想定していなかった機能の組み合わせで障害がでていた。

こんな経験、ありませんか?

• リリースを優先するあまり、テストが不十分

• テスト担当者は要件に沿ったテストしか手が回らない

• 単体テストはCIで自動実行できているのに、本番でバグが出る

• そもそも「何をテストすべきか」を考える時間が足りない

テストの負担を減らしながら品質を上げたい。

でも、そのための時間もリソースもない。このジレンマを抱えているチームは、決して少なくないはずです。

なぜテストが通るのに本番で障害が起きるのか

原因はシンプルです。

本番で起きる問題の多くは、単体では正しい処理が組み合わさったときや時系列で動いたときに発生します。

テストを3層で整理するとどこが手薄か見える

小規模開発体制の場合、下記のような状態になりがち。

テストの3層

単体テストはCI/CDで回せている。
次に手を打つべきは、その上の2層です。

解決策:AIに「シナリオを作る負担」を任せる

シナリオを考えてテストを書く作業は、本来重たい。だからこそAIに任せます。

単体テストの上の2層が手薄になる最大の理由は、「シナリオを考えてテストを書く」作業がそもそも重いからです。

• 何をテストすべきか考え、

• 組み合わせを洗い出し、

• コードに落とす。

この一連の作業を毎リリースこなすのは、小規模チームには現実的ではありません。

ここにAIを使います。

シナリオの発想・組み合わせの網羅・テストコードの生成をAIに任せることで、エンジニアの作業は「判断する」だけに絞れます。

PdM(プロダクトマネージャー)への依頼も「業務的に合っているかの確認」の1回だけ。

シナリオテストの作成から実行までの手順

シナリオ作成などの重たい作業はAIが担当し、人がやるのは判断と確認だけです。
開発が終わった段階で、リリース前に下記作業を実施して、品質を強化する

1. 対話プロンプトを実行（シナリオ自動作成）

2. 業務観点で確認する

3. テストコードを自動生成する

4. テストコードのレビューしてマージ&CIに乗せる

シナリオ作成で重要なポイントは２つ

• クリティカル経路・組み合わせ観点（テスト観点）は対話プロンプトの中でエンジニアが確定する。
  ・AIが候補を提示
  ・エンジニアは確定する

• シナリオの展開はAIが自動生成
  １の経路と２観点を組み合わせで、AIが20件のシナリオが自動展開する

①対話プロンプトを実行(担当:AI + エンジニア)

リリース対象のブランチで、指定のプロンプトを貼り付けて実行する。
5つのフェーズが対話形式で順番に進んでいくので、AI質問から候補を選んでいくだけでで

• クリティカルな経路

• 組み合わせ観点（テスト観点）

• テストシナリオ

が自然と揃っていきます。

対話フェーズ一覧

プロンプト指示文

プロンプト長いです。

開発済みのブランチで流すと、上記の画像のような対話形式で進めて、シナリオ作成します

あなたは統合テストの観点設計を支援するエンジニアです。
これから 5 つのフェーズで対話的に作業します。

【重要なルール】
- フェーズ B/D の確定をユーザーから受け取るまで、次のフェーズには進まない
- 各フェーズの出力後は必ず一度停止し、ユーザーの返信を待つ
- コードから読み取れないことは推測せず「要確認:〇〇」と明記する

# 前提情報の取得

最初に `git diff main...HEAD` を実行し、差分を読み取ってください。

---

# フェーズ A: 修正概要とクリティカル経路の候補(AI 出力)

## 1. 修正概要
- 新規追加・変更された機能の一覧
- 変更はないが、呼び出し関係で影響を受けそうな既存機能
- コードだけでは判断できない業務ルールや仕様の曖昧な箇所
  →「要確認:〇〇」の形式でリストアップ

## 2. クリティカル経路の候補
壊れたら即障害になりそうなユーザーフローを **3〜4 本**(AskUserQuestion
の選択肢上限に収めるため)、下記の表形式で出力する。

| No | クリティカル経路 | なぜ(壊れると致命的になる理由) |
|---|---|---|
| 1 | <経路の説明> | <理由> |
| 2 | <経路の説明> | <理由> |
| 3 | <経路の説明> | <理由> |

## 3. 対象外の候補
- 今回の変更に直接関係しない機能
- 既存の単体テストでカバー済みと思われる範囲
- 対象外と判断した理由も簡潔に書く

## 確定依頼(必ず停止)
フェーズ A を出力したら、AskUserQuestion ツールを使って候補を提示する。

- question: 「採用するクリティカル経路を選んでください(複数選択可)」
- header: 「クリティカル経路」
- multiSelect: true
- options: 上の表の各候補を 1 つずつ option にする
  - label: 「No.X <経路の説明(短く)>」
  - description: 「なぜ: <理由>」
- 追加候補は AskUserQuestion の「Other」欄でユーザーが自由記述できる

AskUserQuestion の応答を受け取るまでフェーズ C には進まないこと。

---

# フェーズ B: クリティカル経路の確定(ユーザー応答)

AskUserQuestion でユーザーが選択した option と「Other」欄に記入された
追加候補をまとめて「確定済みクリティカル経路」として保持する。
選択されなかった候補は採用しない。

---

# フェーズ C: 組み合わせ観点の候補(AI 出力)

確定済みクリティカル経路をもとに、テストで押さえるべき組み合わせ観点を
下記の表形式で出力する。

## ① 検討メモ(箇条書き 3〜5 行)
- どのコード差分から、どの観点を着想したか
- 採用を見送った観点とその理由(過剰・関係薄など)

## ② 観点候補(表)
下記の表形式で出力する。観点数は **3〜4 個に絞る**(AskUserQuestion の
選択肢上限に収めるため)。

| No | 観点名 | 取りうる値 | 紐づくクリティカル経路 | 注目理由 | 優先度 |
|---|---|---|---|---|---|
| 1 | <観点名> | <値 1> / <値 2> / ... | <経路番号> | <なぜこの観点を見たいか> | 高 / 中 / 低 |
| 2 | <観点名> | ... | ... | ... | ... |
| 3 | <観点名> | ... | ... | ... | ... |

# 観点の参考カテゴリ(これに縛られず網羅すること)
- ユーザーの状態・権限(ゲスト / 会員種別 / 権限レベル)
- データの状態(空 / 1 件 / 複数 / 境界値 / 異常値)
- タイミング(有効期限の境界 / 同時実行 / 順序の違い)
- 外部連携(正常応答 / タイムアウト / エラー応答)

# 観点として採用する基準
- 取りうる値が 2 つ以上あり、値によって挙動が変わりうる
- 今回の変更コードまたは影響を受ける既存コードと関連する
- 確定済みのクリティカル経路のいずれかに紐づく

# 制約
- 「要確認」業務ルールに依存する観点は注目理由の末尾に
  「※要確認:〇〇」と明記する
- コードから読み取れない事項は推測せず、要確認として残す

## 確定依頼(必ず停止)
フェーズ C を出力したら、AskUserQuestion ツールを使って候補を提示する。

- question: 「採用する組み合わせ観点を選んでください(複数選択可)」
- header: 「観点」
- multiSelect: true
- options: 上の表の各候補を 1 つずつ option にする
  - label: 「No.X <観点名>」
  - description: 「取りうる値: <値> / 紐づく経路: <経路番号> / 優先度: <高/中/低>」
- 追加候補は AskUserQuestion の「Other」欄でユーザーが自由記述できる

AskUserQuestion の応答を受け取るまでフェーズ E には進まないこと。

---

# フェーズ D: 組み合わせ観点の確定(ユーザー応答)

AskUserQuestion でユーザーが選択した option と「Other」欄に記入された
追加候補をまとめて「確定済み観点」として保持する。
選択されなかった候補は採用しない。

---

# フェーズ E: シナリオ生成(AI 出力)

確定済みクリティカル経路と確定済み観点を組み合わせて、統合テストのシナリオ
を 20 個生成する。

## 条件
- 観点を 2 つ以上組み合わせたシナリオに限定する(単一機能の動作確認は除外)
- フェーズ A の「対象外の候補」に挙がっている範囲は除外する
- 確定済みクリティカル経路のいずれかに紐づくこと

## 出力形式(表)
| No | シナリオ概要 | 組み合わせる観点 | 前提条件 | 期待結果 | 重要度 | 想定される失敗モード |

- 重要度欄: 高 / 中 / 低
- 「要確認」業務ルールに関わるシナリオは、重要度の欄に
  「要確認:〇〇が確定後に実装」と明記する
- 期待結果は業務的に意味のある値(金額・ステータス・通知の有無など)で書く

出力結果イメージ

クリティカル経路内でテスト観点を検証する、シナリオを自動作成する。
（表に収まらず、表形式で出力されないことが多い）

②業務観点で確認する(担当:PdM) 

PdMが関わるのはここだけ。10〜15分の確認1回で済みます。

Claude Codeが生成した「フェーズEのシナリオ一覧」をPdMに渡します。

③テストコードを自動生成する(担当:AI)

確認が取れたシナリオを、そのままテストコードに落とします。

プロンプト指示

④テストコードのレビューしてマージ&CIに乗せる(担当:エンジニア)

ここが効果を一番感じる工程。
マージしたテストは毎リリース自動で動きます。

レビューで見るポイント3つ

AI生成のテストコードも、通常のPRと同じレビューフローを通します。
特に見るのはこの3つ

• 想定結果が業務的に意味のある値を検証しているか

• 「ないことの検証」が含まれているか

• TODOコメントが残っている箇所に、未解決の業務ルールが残っていないか

CIに組み込むことで得られる3つの効果

マージしたテストは、そのままCIに乗せて以降のリリースでも毎回自動実行します。これがこのフローの最も大きな効果です。

①クリティカル経路の劣化を自動検知できる

新機能のリリースが既存のクリティカル経路を壊していないか、人が確認しなくても自動で気づけます。

②テスト資産がリリースのたびに積み上がる

毎回のリリースで新しいシナリオが追加されていくので、回数を重ねるほどカバーされる範囲が広がります。

③「テストが通っている」共通認識が生まれる

エンジニアもPdMも「今回のリリースはクリティカル経路が確認済み」という共通の安心感を持てます。

このフローで、誰がどう楽になるか

役割ごとに、何が減って何が残るかを整理します。

エンジニア

• テスト設計の準備作業がほぼなくなる

• 「何をテストすべきか」を0から考える時間が不要

• AIの候補から選ぶ作業なので負担は最小

PdM(プロダクトマネージャ)

• 関わるのは「業務的に合っているかの確認」1回だけ

• コードや技術的な内容を理解する必要はない

• テスト設計や実装に巻き込まれることなく、リリース品質に貢献できる

テスト担当者

• 要件に沿ったテストに集中できる

• エッジケースの見落としをAIがカバーする

• クリティカル経路をリリースのたびに同じ確認を繰り返す手間がなくなる

まとめ:小規模チームの現実的なテスト戦略

「テストが通るのに本番で障害が発生する」問題の正体は、単体テストが守れない領域。
機能間のデータフローと時系列で動く業務フローにあります。

ここを人手で網羅するのは、小規模チームには現実的ではありません。

だからこそ、シナリオを考えてテストを書く重たい作業はすべてClaude Codeに任せるのがこのフローの核心です。

• エンジニアは「判断する」だけ。

• PdMは「業務的に合っているか確認する」だけ。

• 残りはClaude Codeが自動で生成・実行します。

「AIが候補を出す → 人が判断する → AIが展開する」のサイクルを、クリティカル経路と組み合わせ観点の2か所で回すことで、人の負担を最小に抑えながら手戻りも防げます。

完璧なカバレッジを最初から狙わない。

クリティカル経路を優先的に守りながら、本番で出た問題からシナリオを増やしていく。
回数を重ねるほど、テストに守られた状態でコードを変えられるようになります。