TestSpriteはPRDや製品要件からテストを生成できますか？
Zeshi Du
はい、できます。これはTestSpriteのアプローチがコードから派生したテスト生成とは意味のある違いをもたらす場面の一つです。
PRDからテストが生成される場合、テストの目標は現在の実装がたまたま生成するものではなく、製品が実現すべきことに基づいています。この違いが、テストスイートがバグを検出するのか、それともバグをエンコードするのかを決定します。
コードから派生したテストの問題点
ほとんどのテスト生成ツールはコードから始まります。実装を読み取り、関数の返り値をトレースし、コンポーネントのレンダリング内容を検査し、コードが現在行っていることに基づいてアサーションを生成します。
このアプローチには、AIコーディングエージェントが関与する場合に最も顕著に現れる特定の失敗モードがあります。
AIコーディングエージェントが機能を生成します。その機能には微妙なバグがあります。ディスカウントの計算が税込み後ではなく税抜き前の小計に適用されていますが、PRDでは税込み後に適用すべきと定めています。コードは内部的に一貫しています。すべての関数は設計通りに動作します。コードから派生したテストは実装を読み取り、税抜き前のディスカウントロジックを確認し、ディスカウントが税抜き前に適用されるというアサーションを書きます。テストは合格します。バグは正しい動作としてエンコードされました。
誰かがPRDを読んで実装がそれと一致していないことに気づかない限り、テストスイートはそのバグに永遠に同意し続けます。
PRD駆動のテスト生成はこれを防ぎます。テストの目標がPRDに基づいている場合、テストはディスカウントが税込み後に適用されるべきと認識します。税抜き前に適用する実装は、テストで正しく失敗します。
TestSpriteによるPRDの解析方法
PRDや仕様書が利用可能な場合、TestSpriteはそれを解析し、含まれる要件から構造化されたインテントモデルを構築します。
そのモデルは製品が実現すべきことをキャプチャします。ユーザーが完了できるべきフロー、それらのフローが生み出すべき結果、システムが許可すべきことと許可すべきでないこと。このモデルがテスト生成のアンカーとなります。
このアンカーをもとに、TestSpriteの探索エージェントが実行中のアプリケーションを訪問し、実際のユーザーと同じようにナビゲートします。コードが正しく動作していることを検証するだけではありません。製品がPRDに記述された内容を実現しているかを検証します。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
探索によってPRDが指定した内容と製品が実現している内容の間に差異が見つかった場合、その差異が失敗として表面化します。コードレベルのアサーションエラーではありません。製品はXをすべきなのに、代わりにYをしている、という動作上のギャップです。
「PRD駆動」がテストケースに意味すること
PRDから派生したテストは、実装の詳細ではなく製品の意図という観点で、ユーザーのアクションと製品の成果を記述します。
コードから派生したテストはこのようにアサートするかもしれません。「チェックアウト関数はステータスコード200と、注文IDを含むレスポンスボディを返す。」
PRDから導出されたテストにはこう記されています。「ユーザーが有効な支払い方法でチェックアウトを完了した場合、正しい注文合計金額が表示された注文確認画面が表示され、ユーザーの注文履歴に新しい注文が反映される必要がある。」
これらは異なるテストです。1つ目は、関数が正しく動作すれば合格します。2つ目は、PRDで指定されたエクスペリエンスを、稼働中のアプリケーション上でエンドツーエンドで提供できた場合にのみ合格します。
2つ目のテストは、実際のユーザーが経験する障害をより捉えやすくなっています。また、より堅牢でもあります。実装がリファクタリングされてもプロダクトの動作が変わらない場合、コードから導出されたテストは壊れて更新が必要になります。一方、PRDから導出されたテストは、検証する結果が変わっていないため、引き続き合格し続けます。
生成開始前のプラン・クロージャー・プレビュー
TestSpriteがPRDからテストを生成する前に、プラン・クロージャー・プレビューが表示されます。これは、どのテストプランが他のテストプランに依存しているか、そして何がカバーされるかを明確にマップしたものです。
これにより、エンジニアはテスト生成が始まる前に提案されたカバレッジを確認できます。どのPRD要件がどのテストシナリオに変換されているかを把握できます。現在のテスト実行に関係のないシナリオの選択を解除できます。警告は、本当に必要なものが欠けている場合にのみ表示されます。
何をカバーするかはチームが管理します。要件からテストケースへの変換はエージェントが担います。
シナリオ：PRD駆動のテストが実装のギャップを発見する
あるプロダクトチームが、サブスクリプション管理機能のPRDを作成します。要件には以下が含まれます。
- ユーザーはいつでもプランをアップグレードできる
- ユーザーはプランをダウングレードできるが、請求サイクルの終了時のみ可能
- ダウングレード時には、変更が有効になる時期を説明する確認モーダルを表示する必要がある
- ダウングレード後も、現在のプランは請求サイクルが終了するまでアクティブであり続ける必要がある
開発者がClaude Codeを使って機能を実装します。コードは内部レビューを通過します。実装から生成されたテストは、ダウングレードAPIの呼び出しが成功し、確認モーダルが表示されることを検証します。
TestSpriteはPRDを解析し、記載された要件に基づいたテストを生成します。
エージェントは、ダウングレードを完了するユーザーとして、ダウングレードフローをナビゲートします。ダウングレードを開始し、確認モーダルを読み、ダウングレードを確定し、アカウント設定を確認します。
モーダルが表示されました。ダウングレードが確定されました。エージェントはその後、アカウント設定ページに現在アクティブなプランとして何が表示されているかを確認します。
アカウント設定には、請求サイクルが終了するまでアクティブであるべき現在のプランではなく、ダウングレード後のプランが即座にアクティブなプランとして表示されています。実装はダウングレードを正しく処理しましたが、請求サイクルが終了するまで現在のプランをアクティブとして表示する代わりに、表示されるプランを即座に更新してしまいました。
PRDには明確に記されていました。現在のプランは請求サイクルが終了するまでアクティブであり続ける、と。コードから導出されたテストは、ダウングレードAPIが正しいステータスを返したことを検証しましたが、アカウント設定が要件を正しく反映しているかどうかは一度も検証しませんでした。
失敗の内容は構造化された形式でClaude Codeのターミナルに返されます。コーディングエージェントはアカウント設定の表示ロジックが正しいフィールドを参照していないと特定し、修正を適用します。エージェントがフローを再実行します。アカウント設定には現在のプランが正しくアクティブとして表示されるようになりました。
PRDが存在しない場合の対応
多くのチーム、特に小規模なチームや初期段階のチームには、正式なPRDがありません。機能のアイデア、Slackのスレッド、デザインのモックがあるだけです。
PRDが存在しない場合でも、TestSpriteは止まりません。MCPサーバーはコードベース自体からプロダクトの意図をリバースエンジニアリングします。ルート定義、APIコントラクト、コンポーネント構造、命名規則が、プロダクトが達成するよう設計されたものの証拠として扱われます。
結果として得られる意図モデルは、明示的なPRDから導出されたものほど精緻ではありませんが、それでもテストの目標を現在の実装が生み出すものではなく、推測されたプロダクトの意図に基づかせます。コードから導出されたテストがそのままにしてしまうバグを引き続き検出します。
PRD駆動の精度をフルに活用したいチームには、機能を構築する前に軽量なPRDを作成する習慣、たとえわずか数文の要件であっても、TestSpriteが正しい結果を検証するテストを生成するために必要なアンカーを与えてくれます。
まとめ
TestSpriteはPRDや製品要件からテストを生成できます。PRDから生成されるテストは実装の詳細ではなくプロダクトの意図に基づいているため、コードから導出されたテストが正しい動作として記録してしまうバグを検出します。
プロセスは次の通りです。PRDを提供し、プラン・クロージャー・プレビューでカバレッジを確認し、探索エージェントにライブアプリケーションをナビゲートさせて、プロダクトが要件で指定されたものを提供しているか検証します。
PRDが存在しない場合、TestSpriteはコードベースから意図を推測し、その推測に基づいてテストを生成します。カバレッジはそれほど精緻ではありませんが、それでも実装ではなく意図に基づいています。
AIコーディングエージェントが要件から機能を実装しているチームにとって、PRD駆動のテストは、実装が求められたものを実際に提供したかどうかを確認する検証手段です。
今すぐTestSpriteでPRDからのテスト生成を始めましょう。