TestSpriteはプロジェクトからどのようにテストを生成・実行するのか？
Zheshi Du
TestSpriteを発見した開発者のほとんどは、同じような疑問を持ちます。「プロジェクトへのアクセスを付与した後、実際に何が起きるのか？」
その答えは詳しく理解する価値があります。なぜなら、ほとんどのテストツールとは動作が根本的に異なるからです。TestSpriteはコードベースを読んでテストスクリプトを作成するわけではありません。実際に動作しているアプリケーションを訪問し、探索し、観察した内容からテストを生成します。起点はコードではなく、プロダクトそのものです。
この違いが、何がテストされるか、何が検知されるか、そしてカバレッジを維持するためにチームがどれだけ手作業を行う必要があるかを決定します。
ステップ1：TestSpriteをプロジェクトに接続する
TestSpriteは2つの主要なインターフェースを通じてプロジェクトに接続します。
1つ目はTestSprite MCPサーバーです。Model Context Protocolをサポートする AIのIDE（Cursor、Claude Code、Windsurf、Trae、VS Codeなど）とネイティブに統合されます。設定が完了すれば、IDEのチャットインターフェースからテストパイプラインを直接利用できます。別途ツールを起動したり、ダッシュボードに移動したりする必要はありません。
2つ目はTestSprite Webポータルです。チームがプロジェクトの設定、テストプランの管理、認証の構成、リグレッションのスケジュール設定、品質トレンドの追跡を行うためのブラウザベースのダッシュボードです。
どちらの場合も、プロジェクトの設定は最小限です。TestSpriteが必要とするのは、稼働中のアプリケーション（ステージング環境またはプレビュー環境）のURLと、プロジェクトにログインが必要な場合の認証情報だけです。これが出発点です。
ステップ2：ディスカバリー — 他とは異なるプロセス
ここでTestSpriteのアプローチはコード検査型テストと分岐します。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
テストセッションが開始されると、並列探索エージェントの群がライブアプリケーションを訪問します。ソースファイルを開くのではなく、プロダクトを開きます。実際のユーザーと同じようにナビゲートし、インタラクティブな要素を見つけ、フローをクリックして進み、実際の入力でフォームを入力し、入口から完了まで複数ステップのジャーニーをたどります。
エージェントは並列に動作します。1つはメインユーザージャーニーをたどり、他のエージェントは代替パス、制限ロールのユーザー体験、エラー状態を探索します。各エージェントは発見した内容のログを構築します。どのフローが存在するか、どのアクションがどの結果をもたらすか、プロダクトが期待通りに動作している箇所と動作していない箇所を記録します。
ディスカバリーの出力は、テストすべき関数のリストではありません。実際のプロダクトインタラクションから構築された、実際のユーザージャーニーの構造化されたマップです。
エンジニアはこのプロセスを3カラムのインターフェースでリアルタイムに確認できます。左側にライブアプリケーションのプレビュー、中央にユースケースフローグラフ、右側にエージェントごとのインタラクション詳細が表示されます。セッションは再開可能で、ディスカバリーの実行が中断された場合、エージェントは停止した箇所から再開します。
ステップ3：実装ではなく意図からテストプランを構築する
ディスカバリーが完了すると、TestSpriteはテストプランを構築します。そのプランの源泉となる素材が重要です。
PRDや仕様書が存在する場合、TestSpriteはそれを解析し、テスト目標を記載されたプロダクトの意図に紐付けます。テストは、現在のコードが実際に生成する内容ではなく、プロダクトがユーザーに対して行うべきことに基づいて設計されます。
PRDが存在しない場合（AIネイティブで高速にリリースするチームでは一般的です）、MCPサーバーはコードベース自体から意図をリバースエンジニアリングします。ルート定義はプロダクトがサポートするユーザーアクションを明らかにします。APIコントラクトはプロダクトが管理するデータフローを示します。コンポーネント構造と命名規則はプロダクトがユーザーに提示する内容を示します。これらのシグナルは実装アサーションの設計図としてではなく、設計意図の証拠として扱われます。
この区別により、実装から派生したテストがバグを正しい動作としてエンコードしてしまう既知の失敗パターンを防ぎます。TestSpriteのテストは意図に基づいています。実装が意図から外れたとき、テストは失敗します。それこそが発見すべき失敗です。
テスト生成が始まる前に、「プランクロージャプレビュー」によってどのテストプランが他のプランに依存しているかが表示され、エンジニアは自由に確認・選択解除できます。カバレッジの意思決定はチームに委ねられています。
ステップ4：観察された動作に基づくテスト生成
テストケースは、ディスカバリーマップと意図モデルの組み合わせから生成されます。
フロントエンドフローの場合、各テストケースは実際のユーザーインタラクションのシーケンスと期待されるプロダクトアウトカムを記述します。関数アサーションでもコンポーネントのレンダリングチェックでもありません。ユーザーが行う操作と、そのシーケンスの最後にプロダクトが提供すべき内容の記述です。
バックエンドAPIの場合、TestSpriteのBackend Testing 2.0は単一のアサーションを記述する前に各エンドポイントを実際に呼び出し、実際のレスポンスを観察します。実際のステータスコード、実際のフィールド名、実際のレスポンス形式。結果として得られるアサーションは、ソースコード検査に基づく予測ではなく、APIの実際のコントラクトを反映しています。
実際のAPIレスポンスからキャプチャされた動的変数は、複数ステップのシーケンスを通じて自動的に渡されます。あるステップで作成されたリソースは、その実際のIDを後続のステップに引き渡します。CRUDライフサイクルテストは、開発者がデータを手動で結線することなく、初回の試行からエンドツーエンドで実行されます。
ステップ5：クラウドサンドボックスでの実行
すべてのテストはTestSpriteのセキュアなエフェメラルクラウドサンドボックスで実行されます。数秒で起動し、隔離された環境で実行され、実行完了後に自動的に終了します。
ローカル環境のセットアップは不要です。テスト用データベースのメンテナンスも不要です。インフラのプロビジョニングや管理も必要ありません。開発者はTestSpriteにステージングURLを指定するだけで、サンドボックスが残りを処理します。
スケジュールされたリグレッションも同様に実行されます。Auto-Authが認証レイヤーを処理します。パスワードエンドポイント、OAuthリフレッシュトークン、AWS Cognitoフローは、スケジュールされた実行の前に毎回自動的に処理されます。夜間の実行が期限切れの認証情報によって失敗することはありません。
実行後、テスト中に作成されたリソースは依存関係の順序でクリーンアップされます。次の実行のために環境はクリーンな状態に保たれます。
ステップ6：結果をIDEへ返す
テストが成功した場合、エージェントが探索したフローが実際に動作するプロダクトで正しく機能することが開発者に確認されます。
テストが失敗した場合、構造化された失敗の詳細がIDEに返されます。その内容には、エージェントが実行していた操作、期待していた動作、そしてプロダクトが実際に出力した結果が記述されます。記述はプロダクトレベルの観点で一貫しており、どのユーザー操作か、どのような期待結果か、そして実際の結果が何であったかが明示されます。
Claude Code、Cursor、またはWindsurfでは、AIコーディングエージェントがその失敗の詳細を受け取り、同一セッション内で修正案を提示できます。コードの変更からテストの失敗、そして修正の適用までのループが、IDE内で完結します。
シナリオ：誰も仕様として定義しなかったものをDiscoveryが発見する
ある開発者がCursorを使って、ECサイト製品の注文管理セクションを構築しています。AIが1つのセッションで注文一覧、注文詳細ビュー、注文キャンセルフローを生成しました。テストケースは一切書かれておらず、このセクションのPRDも存在しません。
開発者はTestSpriteを接続し、Cursor内からセッションを開始します。
Discoveryエージェントは、実際の顧客のように注文管理セクションをナビゲートします。注文一覧を閲覧し、詳細ビューを開き、注文のキャンセルを試みます。そして、確認モーダル、理由選択フォーム、送信ボタンから成るキャンセルフローを発見します。
さらに、誰も仕様として定義していなかった問題も発見します。注文をキャンセルして注文一覧に戻ると、キャンセルされた注文が元のステータスのまま表示され続けるのです。キャンセルのAPIコールは成功しています。しかし注文一覧がキャンセルを反映して更新されません。UIの状態が古いままになっています。
これはテスト計画に含まれていませんでした。テスト計画自体が存在しなかったからです。TestSpriteは、ユーザーと同じようにプロダクトを探索することでこの問題を発見しました。具体的には、操作を完了し、論理的な次の画面に遷移し、状態が一貫しているかどうかを確認するという方法です。
失敗の詳細がCursorセッションに返されます。コーディングエージェントは、キャンセル確認後のリスト更新処理が欠落していることを特定し、修正を適用します。開発者はTestSpriteを再度実行して、キャンセル後に注文一覧が正しく更新されることを確認します。
まとめ
TestSpriteは、まずライブアプリケーションを探索してプロジェクトのテストを生成・実行します。その探索と利用可能な仕様からインテントモデルを構築し、実装コードの検査ではなく観察された動作からテストを生成し、クラウドサンドボックスで実行して結果をIDEに返します。
このアプローチは、コード検査型テストとはあらゆる段階で異なります。出発点はコードではなくプロダクトです。テストケースは関数アサーションではなく、ユーザーの操作を記述します。実行は隔離されており、インフラの準備は不要です。そして結果は、コーディングエージェントがすぐに対応できる形式で構造化されています。
AIがコードを書き、それに対応した自律的な検証が必要なチームにとって、これがその検証の仕組みです。
今すぐIDEまたはWebポータルから、最初のTestSpriteセッションを開始しましょう。