はじめに
担当しているプロジェクトでは、既存システムに対する追加開発を行っており、今回対応した主な機能は次のとおりです。
- 申請管理機能
- 通知機能
- ファイル出力機能
- 既存画面の改修
これらの機能について、リリース前に結合テスト仕様書を作成する必要がありました。
ゼロから作成すると、対象機能や関連処理の調査だけでも時間がかかります。
そこで今回は、普段の業務で行っている Claude Code と Claude（チャット）を使ったテスト仕様書の作成方法を紹介します。
全体の流れ
AIを使う工程を2つに分け、その間に人のレビューを挟みます。Claude Codeでテストケースを洗い出し、人がレビューした後、チャットでテスト仕様書の形式に整えます。
なぜ2ステップに分けるのか
Claude Codeに提出用の仕様書まで作らせることもできます。スクリプトを作成すればExcelへの出力も可能です。
それでも分けているのは、途中に人がレビューする工程を入れたいからです。
Markdownの段階で一度確認することで、「何をテストするか」と「どう見せるか」を分けて考えられます。
仕様書の形式まで一気に作らせると、内容の誤りに気づいたときに作り直しになりますが、Markdownの段階であればテキストのまま直せます。
後工程にチャットを使う理由
ここで重要なのは工程を分けること自体で、後工程のツールは必ずしもチャットである必要はありません。レビュー後にそのままClaude Codeへ整形を指示しても、目的は達成できます。
そのうえでチャットを使っているのは、次の理由です。
- 整形の作業にリポジトリを読ませる必要がない
- 列の並びや表現を対話しながら調整しやすい
- コードやリポジトリに余計な変更を加えさせずに済む
- Excelファイルをそのまま出力してもらえるため、転記の手間が発生しない
役割としては次のように使い分けています。
- Claude Code — Issueとソースコードを確認して、テストケースを洗い出す
- Claude（チャット） — レビュー済みの内容をテスト仕様書の形式に整える
作成手順
以下の3ステップで進めます。
Step 1：Claude Codeでテストケースを作る
対象プロジェクトでClaude Codeを起動し、次のような指示を出します。実際にはリポジトリ名やIssue番号を具体的に指定しています。
今回のリリース分のIssue（#XX〜）を確認し、実装済みのコードを読んだうえで
結合テストケースをMarkdownで作成してください。
■ 方針
- 正常系 / 異常系（入力エラー、権限エラー、排他制御、同時操作の競合）に分ける
- 各ケースに 画面 / API / DB / 通知 の期待結果を分けて記載
- ケースID、関連Issue番号、前提条件、操作手順を含める
■ 注意（共通）
- Issueの記述と実装が食い違う場合は実装を正とし、その差分を注記する
- 実装を読まずに一般論でケースを書かない
（Laravelの場合は Controller / Service / FormRequest / Rules を追い、
実際のバリデーションルールとエラーメッセージを引用する）
■ 注意（本プロジェクト固有）
- 認証エラーを「HTTP 200 + body内のcode」で返す箇所があるため、
HTTPステータスとbody内codeを混同しない
- 権限（admin / user / partner）で結果が変わるエンドポイントは権限別に分ける
■ 横断シナリオを別章にまとめる
- 申請の処理中に、申請者が退会・退職した場合
- 設定変更が、別機能の判定に与える影響
「注意（本プロジェクト固有）」の部分は、自分の環境のエラー応答の形式や権限区分に読み替えてください。
効果があった指示
実際に使ってみて、特に効果があったのは次の3点です。
1. Issueと実装の差分を扱わせる
Issueの記述と最終的な実装に差分が生じる場合もあります。その場合は実装を正としたうえで差分を注記させることで、テストケースの作成がIssueと実装の突き合わせも兼ねます。
2. 確認してほしい処理を具体的に指定する
参照するレイヤーを指定しないと、どのプロジェクトにも当てはまる一般的なケースが並びます。追ってほしい箇所を挙げることで、実際のバリデーションルールやエラーメッセージが反映された内容になります。
3. 横断シナリオを別章にする
機能単位で書かせると、機能をまたぐケースが出てきません。既存機能や別機能との連携は章を分けて明示的に依頼します。
Step 2：内容をレビューする
AIが作った内容をそのまま使うことはありません。実装と照らし合わせて確認します。
特に抜けやすいのが、今回のリリース分のIssueだけでは見えない、既存機能との連携部分です。追加した機能は既存機能の上で動く一方、その連携部分はIssueに書かれていないことも多いため、足りないテストケースは実装者が追加・修正します。
Step 3：チャットで仕様書にする
レビューしたMarkdownをClaudeに渡して、テスト仕様書の形式に整えてもらいます。
最終的な提出物はExcelです。チャットにはMarkdownを渡したうえで「この内容でExcelのテスト仕様書を作成してください」と依頼し、ファイルとして出力してもらいます。
内容はStep 2で確認済みなので、ここでは主に体裁を確認します。
使ってみて
一番大きいのは、ゼロから書き始めなくて良いことです。最初から「何が足りないか」を探す作業に入れます。
一方で、AIの出力がそのまま使えるわけではありません。
特に既存機能との連携など、Issueだけでは分からない部分は人による確認が必要です。
AIにたたき台を作ってもらい、最後の品質は人のレビューで担保するようにしています。
今後試したいこと
現在はチャットで毎回仕様書の形式に整えています。
今後は、決まったテンプレートに出力するスクリプトをClaude Codeで作成し、この工程もさらに短縮できないか試してみたいと思います。整形の手順が固まってきたので、対話で調整する必要が少なくなってきたためです。
まとめ
- Claude Codeで洗い出す → 人がレビューする → チャットで整える
- Markdownを挟むのは、内容を確定させてから体裁に進むため
- Issueだけでは既存機能との結合部分が抜ける。そこは実装者が補う
