はじめに
私のチーム現在、cc-sdd（Claude Code Spec-Driven Development）を活用して開発を進めています。
cc-sddについて詳しく知りたい方は、上記リポジトリを参照してください。
簡単に説明すると、cc-sddは Claude Code 上で「要件定義 → 設計 → タスク分解 → 実装」の仕様駆動フローを回す手法です。
私のチームでは以前からストーリーテストによる動作確認を行っていましたが、作成は手動で行っていました。
ただ、cc-sddで生成される requirements.md や design.md には、ストーリーテスト作成に必要な情報が揃っています。であれば、ストーリーテストの作成もcc-sddのフローに組み込んで自動化できるのでは？ と考え、実際にやってみたところうまくいったので、その方法と効果を共有します。
ストーリーテストとは
ストーリーテストとは、ユーザーの操作シナリオに沿って、機能が正しく動作するかを検証するテストです。単体テストやインテグレーションテストとは異なり、「ユーザーがこの画面でこの操作をしたら、こうなる」というストーリーベースで記述します。
ストーリーテストの雛形
私のチームでは、以下のような雛形でストーリーテストを作成しています。
# タイトル
# 事前準備
| 操作システム | 操作画面・操作ディレクトリ | 手順 | 入力データ |
| ------------ | -------------------------- | ---- | ---------- |
# テスト
| 内容 | 操作画面 | 手順 | 入力データ | 期待値 | 結果 |
| ---- | -------- | ---- | ---------- | ------ | ---- |
このフォーマットのポイントは以下の通りです。
- 事前準備：テスト実行前に必要な環境やデータの準備手順を明確にする
- テスト：具体的な操作手順・入力データ・期待値をセットで記述し、結果を記録する
なぜストーリーテストが必要なのか
cc-sddのフローへの組み込みの話に入る前に、ストーリーテストの重要性について触れておきます。
cc-sddで要件定義・設計・実装まで進めても、最終的に「本当に動くのか」を確認するフェーズが欠かせません。
- 仕様との整合性を保証する：requirements.md や design.md に書かれた要件が、実際の動作として満たされているかを確認できる
- 手動テストの属人化を防ぐ：「何を確認すればよいか」がドキュメントとして残るため、誰でも同じ観点でテストできる
- AIが生成したコードの品質担保：AIが生成したコードは、仕様を満たしているように見えても意図と異なる動作をすることがある。ストーリーテストはその最終防衛線になる
- レビューの効率化：レビュアーがストーリーテストを見れば、どのシナリオが検証済みかが一目でわかる
cc-sddへの組み込み方
全体フロー
cc-sddの標準フローにストーリーテストを追加した全体像は以下の通りです。
Phase 1: 仕様作成
├─ spec-init（初期化）
├─ spec-requirements（要件定義）
└─ spec-design（設計）
Phase 2: ストーリーテスト作成 ← ★ここを追加
├─ requirements.md + design.md を読み込ませる
└─ ストーリーテストを自動生成
Phase 3: 実装
├─ spec-tasks（タスク分解）
└─ タスクに沿って実装
Phase 4: テスト実施・完了
└─ ストーリーテストに沿って動作確認・結果記録
組み込みのタイミング
ストーリーテストの作成タイミングは、requirements.md と design.md が完成した後、実装に入る前です。
この2つのドキュメントには、以下の情報が含まれています。
- requirements.md：機能が満たすべき要件、ユーザーストーリー、受け入れ条件
- design.md：画面構成、API設計、データフロー、エッジケースの考慮
これらをAIに読み込ませることで、要件と設計に沿ったストーリーテストを自動生成できます。
設計後・実装前にストーリーテストを作成するメリットは以下の通りです。
- 実装の指針になる：「何を満たせば完了か」が実装前に明確になるため、開発者が迷わない
- 設計のレビュー効果：ストーリーテストを書く過程で、設計の抜け漏れに気づけることがある
- テスト駆動的な開発：先に検証シナリオを用意してから実装に入ることで、品質を作り込める
実際の運用：カスタムプロンプトによる自動化
私のチームでは GitHub Copilot を使っており、以下のようなカスタムプロンプトを作成してストーリーテストの生成を自動化しています。
カスタムプロンプトについて詳しく知りたい方は、GitHub Copilot のドキュメントを参照してください。
私のチームでは元々ストーリーテストのページを Confluence（Atlassian）上で管理していたため、プロンプトでも Atlassian MCP を使って Confluence に直接配置する構成にしています。
プロンプトの概要
このプロンプトは .github/prompts/create-story-test.prompt.md に配置しています。
コマンド: /create-story-test <feature>
このコマンドを実行すると、以下のステップが自動で走ります。
- ストーリーテストの雛形を把握する
-
.kiro/specs/<feature>/requirements.mdとdesign.mdを読み込み、要件・設計を理解する - 雛形・要件・設計をもとに、主要なユーザーフローを検証できるストーリーテストを生成する
- 作成したストーリーテストを Confluence に配置する
カスタムプロンプトの全文
参考として、実際に使用しているプロンプトを掲載します。
# ストーリーテスト作成プロンプト
<background_information>
- **目的**: Atlassian MCP を使って、対象機能のストーリーテストを Confluence に作成する。
- **完了条件**: 指定ディレクトリに、要件・設計に沿ったストーリーテストページが作成されていること。
</background_information>
<instructions>
## 実行タスク
Atlassian MCP を使用し、指定された機能のストーリーテストを作成して Confluence に配置する。
## 入力
- コマンド: `/create-story-test <feature>`
- `feature`: 機能名
## 手順
1. Atlassian MCP のドキュメントを確認し、ストーリーテストの雛形を把握する。
2. `.kiro/specs/<feature>/requirements.md` と `.kiro/specs/<feature>/design.md` を読み、
要件と設計を理解する。
3. 雛形・要件・設計をもとに、主要なユーザーフローを検証できるストーリーテストを作成する。
4. 作成したストーリーテストを、指定の Confluence ディレクトリに配置する。
## 作成ルール
- テストケースは、細かすぎる単位ではなく「機能の成立を確認できる主要シナリオ」を中心にする。
- ケース内容は、要件と設計の記述に対応していること。
- ページ名は `XXXX-<feature> <チケットタイトル>` とする。
</instructions>
ポイント
- MCP（Model Context Protocol）の活用：Atlassian MCP を使うことで、Confluence への配置まで自動化している
- 仕様ドキュメントとの連動：requirements.md と design.md を入力にすることで、仕様とテストの乖離を防ぐ
- 主要シナリオに絞る：細かすぎるケースは避け、「機能の成立を確認できる主要シナリオ」に集中する
まとめ
cc-sddは仕様駆動で開発を進める優れた手法ですが、設計から実装へ進む前に検証シナリオを用意し、実装後に確実に検証するところまで含めて初めて開発フローとして完結します。
ストーリーテストを組み込むことで得られる効果をまとめると：
- 仕様 → テスト設計 → 実装 → 検証の一気通貫したフローが実現できる
- requirements.md / design.md からストーリーテストを自動生成することで、仕様とテストの整合性が保たれる
- テスト作成の工数が削減される
- チーム全体でテスト結果を共有できる
cc-sddで開発をした後の動作確認として、ストーリーテストの実施は必要不可欠だと考えています。仕様に基づいたテストがあることで、AIが生成したコードに対しても安心してリリースを進められます。
ぜひ、皆さんの開発フローにも取り入れてみてください。