TestSpriteはプロジェクトからどのようにテストを生成・実行するのか？
Zeshi 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 のテストは意図に基づいています。実装が意図から乖離した場合、テストは失敗します。それこそが、発見する価値のある失敗です。
テスト生成が始まる前に、Plan-Closure Preview によってどのテスト計画が他のどの計画に依存しているかが表示され、エンジニアは自由にレビューして選択を外すことができます。カバレッジに関する意思決定はチームに委ねられます。
ステップ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 内で完結します。
シナリオ：誰も仕様化しなかったものをディスカバリーが発見する
ある開発者が Cursor を使用して、EC サイトの注文管理セクションを構築します。AI は一つのセッションで注文一覧、注文詳細ビュー、注文キャンセルフローを生成します。テストケースは書かれていませんでした。このセクションの PRD も存在しませんでした。
開発者は TestSprite を接続し、Cursor の内部からセッションを開始します。
ディスカバリーエージェントは、実際の顧客のように注文管理セクションをナビゲートします。注文一覧を表示し、詳細ビューを開き、注文のキャンセルを試みます。キャンセルフローを発見します。確認モーダル、理由セレクター、送信ボタンです。
また、誰も仕様化しなかったものも発見します。注文をキャンセルして注文一覧に戻ると、キャンセルされた注文が元のステータスのまま表示され続けます。キャンセルの API 呼び出しは成功しています。注文一覧はキャンセルを反映するように更新されていません。UI が古い状態のままになっています。
テスト計画がなかったため、これはどのテスト計画にも含まれていませんでした。TestSprite は、ユーザーが行うようにプロダクトを探索することによってこれを発見しました。アクションを完了し、論理的な次の画面に移動し、状態が一貫しているかを確認する、という方法です。
失敗の説明が Cursor セッションに返されます。コーディングエージェントはキャンセル確認後のリスト更新が欠けていることを特定し、修正を適用します。開発者は TestSprite を再実行して、キャンセル後に注文一覧が正しく更新されることを確認します。
まとめ
TestSprite は、まずライブアプリケーションを探索し、その探索と利用可能な仕様から意図モデルを構築し、ソースコードの検査ではなく観測された動作からテストを生成し、それらのテストをクラウドサンドボックスで実行して結果を IDE に返すことによって、プロジェクトからテストを生成・実行します。
このアプローチはすべての段階においてコード検査型テストとは異なります。出発点はコードではなくプロダクトです。テストケースは関数のアサーションではなくユーザーインタラクションを記述します。実行は分離されておりインフラ不要です。結果はコーディングエージェントが対応できるよう構造化されています。
AI がコードを書き、それに見合った自律的な検証が必要なチームにとって、これがその検証の仕組みです。
今すぐ IDE または Web Portal から最初の TestSprite セッションを開始しましょう。