スペック駆動テスト：なぜ要件ファーストのQAがスクリプトファーストのテストより優れているのか
Yunhao Jiao
自動テストには、根本的に異なる2つの考え方があります。1つ目は「コードが実際に行っていることを確認するスクリプトを書く」というアプローチです。2つ目は「コードが本来すべきことの仕様を書き、その仕様に対してコードを検証する」というアプローチです。
テスト自動化の多くは前者に該当します。仕様駆動テストは後者です。この違いは必要になるまで些細に見えますが、いざ必要となったとき、その差は決定的なものになります。
スクリプト優先テストの問題点
スクリプト優先テストは、自動テストにおいて主流のアプローチです。エンジニアはコードを確認し、その動作を観察し、その振る舞いを確認するテストを書きます。テストは書かれた瞬間からパスします。なぜなら、テストが検証する動作は現在存在する動作そのものだからです。
これがまさに問題の本質です。スクリプト優先テストは実装を確認するものです。リグレッション（動作していたものが動かなくなること）は検出できますが、インテントギャップ（動作はしているが意図と異なることをしている状態）は検出できません。
シンプルな例を考えてみましょう。チェックアウトフォームには請求先住所の入力が必須であるとします。開発者が誤ってバリデーションを省略し、請求先住所なしでフォームが送信できてしまいます。この実装に対して書かれたスクリプト優先テストは、請求先住所なしでフォームが送信されることを正しい動作として確認します。テストはパスし、バグはそのまま本番環境に出荷されます。
「チェックアウトを完了するには請求先住所が必須」という要件から書かれた仕様駆動テストは、住所なしでフォームが送信された時点で失敗します。バグは出荷前に検出されます。
この違いは理論上の話にとどまりません。コードが内部的には一貫しているにもかかわらず要件と一致しないインテントギャップは、AIコーディングツールが最も頻繁に引き起こす障害モードです。スクリプト優先テストは、構造上その検出が不可能です。
仕様駆動テストとは何か
仕様駆動テスト（要件駆動テストまたは仕様ベーステストとも呼ばれます）は、既存の実装を検査するのではなく、ユーザーストーリー、受け入れ基準、機能仕様といったプロダクト要件から直接テストを導き出すアプローチです。
テストは要件に基づいて、コードが存在する前に作成（または生成）されます。エージェント型テストの場合は、要件からテストが生成され、AIコーディングツールによって生成された実装と照合されます。いずれの場合も、正しさの根拠となるのは実装ではなく要件です。
仕様駆動テストが問う問いは「コードは本来すべきことをしているか？」です。スクリプト優先テストが問う問いは「コードは現在行っていることを引き続き行っているか？」です。これらは根本的に異なる問いです。
仕様駆動テストがAIコーディングツールに適している理由
AIコーディングエージェントはプロンプトに基づいてコードを生成します。プロンプトは非公式な仕様です。仕様が明確であるほど、出力の品質が高まり、検証の精度も向上します。
TestSpriteは、仕様駆動テストをコアのアーキテクチャ原則として構築されています。エージェント型テストエンジンはPRD、ユーザーストーリー、または要件ドキュメントを読み込み、ソフトウェアが何をすべきかについての内部構造モデルを構築し、そのモデルに対して実装を検証するテストを生成します。
これは、コードを解析してその動作に基づいたテストを生成するテストツールとは異なります。コード解析はスクリプト優先テストを生成します。要件解析は仕様駆動テストを生成します。
AIネイティブなチームにとって、これが重要な理由は明確です。最も検出すべきバグは、AIがもっともらしいが誤ったコードを生成した場合に発生するものです。こうしたバグは仕様と実装のギャップにのみ現れます。そのギャップを可視化するには、両方が揃っている必要があります。
仕様駆動テストの実際の進め方
ステップ1：仕様が唯一の正しさの根拠となる
仕様駆動テストは、明確な要件アーティファクトから始まります。TestSpriteでは以下を使用できます。
- 正式なPRD（プロダクト要件ドキュメント）
- 受け入れ基準を含むユーザーストーリー
- アプリケーションの意図された動作を説明するREADME
- エンドポイントの期待される動作を説明するAPIドキュメント
- または、シンプルなプロジェクトの場合はコードベース自体 — 正式な仕様が存在しない場合、TestSpriteはコード構造から意図を推測できます
テストの品質は仕様の明確さに直接比例します。曖昧な要件からは曖昧なテストしか生まれません。「未認証ユーザーが/dashboardへアクセスしようとした場合は/loginにリダイレクトされる」といった具体的な受け入れ基準からは、具体的で意味のあるテストが生まれます。
ステップ2：要件からテストを生成する
TestSpriteのエージェント型テストエンジンは仕様を解析し、テスト計画を生成します。この計画には以下が含まれます。
- テスト可能なシナリオとしての各ユーザーストーリーまたは受け入れ基準
- ポジティブケース（機能が説明通りに動作する）
- ネガティブケース（機能が無効な入力や不正アクセスを正しく処理する）
- 仕様から導き出されたエッジケース（境界値、空の状態、同時操作）
このテスト計画は実行前に確認・調整可能です。エンジニアはテストケースを追加、削除、または変更できます。
ステップ3：実装に対する実行
テストはモックやシミュレーションではなく、実際のアプリケーションに対して、隔離されたクラウドサンドボックス上で実行されます。実際のアプリケーションの動作が、仕様から導き出された期待される動作と照合されます。
失敗は仕様違反を意味します。コードが仕様の要求と異なる動作をしているということです。これは常に意味のある失敗です。なぜなら、指定された内容と実際に構築されたもののギャップを示しているからです。
ステップ4：失敗の分類と修正ループ
仕様駆動テストの失敗は、3つのカテゴリに分類されます。
仕様違反 — 実装が要件と一致していません。これは本物のバグです。修正の推奨事項が生成され、MCPを通じてコーディングエージェントに送信されます。
仕様の曖昧さ — テストの期待値が曖昧な要件から導き出されています。これは仕様の品質上の問題を表面化させ、コードの修正ではなく要件の明確化を促します。
テストの脆弱性 — アプリケーションではなく、テストの仕組み自体が失敗した（ロケーターのズレ、タイミングの問題など）ケースです。セルフヒーリングによって、この問題は透過的に解決されます。
仕様駆動テスト vs. テスト駆動開発
仕様駆動テストとTDDは共通の原則を持っています — 実装の前、または実装とは独立して、望ましい動作を定義するという考え方です。実践上の違いは、誰が書くかという点にあります。
TDDでは、エンジニアがコードを書く前にテストを手動で作成します。これには多大な時間投資と規律が必要であり、AIコード生成のスピードには対応できません。
仕様駆動型エージェンティックテストでは、要件からテストが自動生成されます。エンジニアは仕様を記述するだけでよく（コーディングエージェントへのプロンプトとして書くものと同じです）、エージェンティックテストエンジンがテストを生成します。TDDのメリット — 要件ファーストの検証 — が、手動でテストを作成するオーバーヘッドなしに実現されます。
AIネイティブなチームにとって、仕様駆動型エージェンティックテストは、AI開発のスピードでTDDの原則を実践的に実現する手段です。
仕様の品質への投資
仕様駆動テストでは、仕様の品質がテストカバレッジに直接反映されます。これはバグではなく、意図した特性です。
コーディングセッションの前により明確な要件の定義に投資しているチームは、二つの効果を実感しています。AIが生成するコードの品質向上（コーディングエージェントにより多くのコンテキストが与えられるため）と、テストカバレッジの向上（エージェンティックテストエンジンがテストを導出するための情報が増えるため）です。仕様の品質への投資は、両方向で成果をもたらします。
意味のある仕様駆動テストに必要な最低限の仕様：
- 機能の説明：何を構築するのか？
- 受け入れ基準：成功とはどのような状態か？
- エッジケース：問題を引き起こす可能性のある入力や状態は何か？
- 不変条件：常に真でなければならないことは何か？
コーディングセッションの前に15分で書いた1ページの要件ドキュメントがあれば、包括的な仕様駆動テストカバレッジを生成するには十分です。代替手段 — AIが生成したコードに後からテストを追加する方法 — はより多くの時間がかかり、重要なギャップを見落とすスクリプトファーストのテストしか生み出しません。
はじめに
TestSpriteを使った仕様駆動テストは、あなたの要件ドキュメントから始まります。MCPを通じてTestSpriteをリポジトリに接続し、PRDまたはユーザーストーリーを指定するだけで、仕様から導出されたテストカバレッジが自動生成されます。
こちらから始める →