TestSpriteで初めての自動テストを実行する方法
Zeshi Du
MCPサーバーをインストールすれば、初めてのテストの実行はIDEのチャットに一文を入力するだけです。入力後に何が起こるかをステップごとに詳しく説明します。表示される各画面が実際に何をしているかを事前に把握しておきましょう。
開始する前に
次の2点を確認してください。TestSprite MCPサーバーがIDEにインストールおよび設定されていること（まだの場合は、別途セットアップが必要です）、そしてアプリケーションがローカル、ステージング、またはプレビューデプロイメント上で実際に稼働していること。TestSpriteはソースファイルではなく、実際に動作しているアプリをテストするため、開いて操作できる対象が必要です。
# フロントエンド
npm run dev # 通常はポート 3000、5173、または 8080
# バックエンド
node index.js # 通常はポート 8000、3001、または 4000
ステップ1：新しいチャットを開き、指示を入力する
IDEのAIアシスタントパネルで新しいチャットを開き、次のように入力してください：
このプロジェクトをTestSpriteでテストしてください。
これが最初の汎用テストとしての完全な指示です。より具体的にターゲットを絞りたい場合は、「このプロジェクトのチェックアウトフローをTestSpriteでテストしてください」や「ユーザー認証エンドポイントをTestSpriteでテストしてください」のように指定することもできます。どちらも有効ですが、初回は汎用的な指示の方がより良い出発点です。TestSpriteがプロジェクトの構造を自力で把握する余地が生まれるためです。
ステップ2：ブートストラップと設定
最初に行われるのはブートストラップ呼び出しで、プロジェクトの種類を検出し、アプリが動作しているポートを特定します。ブラウザにテスト設定ページが自動的に開き、プロジェクトの種類、ローカルポート、テスト範囲、ログインの要否などの詳細を確認・調整できます。テストしたいフローにアクセスするためにアプリの認証が必要な場合は、ここでテスト用の認証情報を提供します：
{
"projectType": "frontend",
"localPort": 5173,
"testScope": "codebase",
"needLogin": true,
"credentials": {
"username": "test@example.com",
"password": "testpassword123"
}
}
QAの担当者に個人のログイン情報を渡さないのと同じ理由で、ここには実際のユーザーの認証情報ではなく、専用のテストアカウントを使用してください。
ステップ3：PRD生成とコードベース分析
設定が確定すると、TestSpriteはアップロードされたPRDを読み込んでプロダクトの意図を把握します。PRDがアップロードされていない場合は、コードベースを直接分析し、プロジェクト構造、コンポーネント階層、APIルート、実装パターンをスキャンして、正規化された内部PRDを代わりに構築します。いずれの場合も目的は同じです。UIの記録やコードスキャンが偶然気づいたことではなく、プロダクトが本来行うべきことにテスト内容を紐付けることです。
このステップではフレームワーク（React、Vue、Angular、Node.jsなど）も自動的に検出されるため、使用しているスタックを手動で指定する必要はありません。
ステップ4：テスト計画とテストケースの生成
内部PRDが整うと、TestSpriteは正常系、エッジケース、エラー状態を網羅するテストケースを設計し、実際に実行可能なテストスクリプトを作成します。プロジェクトの種類に応じて、UIフローにはPlaywrightまたはCypressスクリプト、バックエンドルートにはAPIテストスクリプトが使用されます。このコードを1行ずつ記述・レビューする必要はありません。自動的に生成され、実行キューに追加されます。
ステップ5：クラウドサンドボックスでの実行
テストはお使いのマシン上ではなく、セキュアで一時的なクラウドサンドボックス上で実行されます。そのため、ローカルブラウザへの依存がなく、他の作業とのポート競合も発生せず、実行完了後は自動的にクリーンアップされます。実行開始後はブラウザにテスト進捗ダッシュボードが開くため、ターミナルログを眺めるのではなく、ほぼリアルタイムでテストの進行を確認できます。
ステップ6：結果の確認、分析、修正
実行が完了すると、合否ステータス、エラーログ、スクリーンショット、および失敗したテストの動画録画を含むレポートが生成されます。新たに生成されたテストが修正可能な理由で失敗した場合、TestSpriteは修正したコードで再試行してから結果を表示します。これにより、実際に確認する価値のある実行結果だけをレビューできます。まったく実行できない場合（期限切れの認証情報、欠落している上流の値など）は、誤解を招く「Failed」ではなく、平易な言葉で説明された「Blocked」ステータスが表示されます。
IDEのAIエージェントが自動的に修正を適用するよう設定されている場合、失敗した内容は構造化されたフォーマットにパッケージ化されてエージェントが直接対応できるようになり、「何かが壊れている」から「修正方法はこちら」までのループが、手動で診断する必要なく完結します。
最初のレポートで実際に確認すべきこと
合否のサマリーだけを確認して次に進みたくなるかもしれませんが、特に初回の実行では、些細なものであっても少なくとも1件の失敗を詳細に開いてみることが、より有益な習慣です。スクリーンショット付きで根本原因まで分析された失敗レポートが実際にどのようなものか確認するためです。その経験があると、以降の実行で得られるレポートを信頼する（または適切に疑問視する）ことがずっと容易になります。特定の結果の背後にどれほどの詳細が含まれているかを、自分の目で確認しているからです。
また、初回の実行では、テスト結果だけでなく生成された内部PRD自体にも目を通す価値があります。正式なPRDをアップロードしていない場合、エージェントがプロダクトの目的についてどのように推論したかを確認できる唯一の明確な機会です。そして、誤解があればここで修正するのが最もコストが低いタイミングです。そのまま見過ごすと、以降生成されるすべてのテストに静かに影響し続けることになります。
2回目の実行で行うこと
バグ修正や新機能の追加など変更を加えた後は、状況に応じて異なる指示を使用します。大きな機能を追加したりアプリのアーキテクチャを大幅に変更した場合は「Regenerate」、バグを修正して既存のテストで再検証したい場合や、テスト用の認証情報を変更した場合は「Rerun」を使用します。Rerunは既存のテストを再実行してリグレッションを確認し、Regenerateは変更内容が大きく既存のテストが適用できなくなった場合に、新しいテスト計画をゼロから構築します。
最初の実行から身につけるべき習慣
最初のテスト実行を一度きりのセットアップ作業として扱い、その後は元の習慣に戻りがちです。より有益なとらえ方は、最初の実行を継続的なリズムの始まりとして位置づけることです。リスクを感じるときだけでなく、意味のある変更を加えるたびにテストを実行するようにしましょう。テスト実行の手間は十分に低く、一文を入力して数分待つだけです。継続して行う上での主な障壁は努力ではなく習慣です。その習慣を最初のテストから構築する方が、テストなしでリリースすることに慣れてしまった後から後付けしようとするよりもはるかに簡単です。
まとめ
TestSpriteによる最初の自動テストは、一文の指示と数分の設定だけで完了します。そして結果として得られるのは、アプリが正常に動作しているかどうかの推測ではなく、実際のスクリーンショットと根本原因を含むレポートです。まだMCPサーバーをセットアップしていない場合は、それだけが自分のプロジェクトでこのワークフローを実行するための唯一の前提条件です。