CursorはMCPサーバーを通じてE2Eテストを実行できるか？
Zeshi Du
はい、できます。そしてその仕組みを一度理解すれば、別のテストツールに戻ることが不要に感じられるでしょう。
CursorがMCPサポートを追加したのは、IDE内のAIエージェントがコンテキストの切り替えなしに外部ツールへネイティブ接続できるようにするためです。ほとんどのツールでは、データの取得やアクションのトリガー、そしてチャットへの結果返却を意味します。MCP上に構築されたテストエージェントにとっては、さらに重要な意味を持ちます。つまり、E2Eテストパイプライン全体が、コードを書いたCursorセッション内で実行されるのです。
開発者はターミナルを開く必要も、ダッシュボードに切り替える必要も、CIの実行を待つ必要もありません。指示を出せば、エージェントがライブアプリケーションに対してE2Eテストを実行し、結果が同じチャットウィンドウに返ってきます。
これが簡潔な答えです。より実用的な疑問は、それらのE2Eテストが実際に何をするかです。MCPを通じて接続されたテストエージェントがすべて同じことをしているわけではないからです。
MCPを通じたE2Eテストが本当に意味すること
MCPはプロトコルであり、品質基準ではありません。MCP経由でテストツールをCursorに接続するということは、そのツールがIDEで指示を受け取り結果を返せることを意味します。それは、その結果が本物のE2E動作を反映しているかどうかとは無関係です。
MCP経由で動作するツールの多くは、Cursorから参照できるソースファイルを読み取ることでテストを生成します。コンポーネントツリーを検査し、関数呼び出しをトレースし、コードが「すること」に基づいてアサーションを生成します。統合はネイティブですが、テストはエンドツーエンドではありません。
本物のE2Eテストには実行中のアプリケーションが必要です。ナビゲーションが必要です。ステップをまたいで持続する状態が必要です。最初のアクションから最終的な結果まで、スタックのすべての層を通じて、実際のユーザーと同じようにプロダクトと対話するエージェントが必要です。
CursorでのAIコーディングセッションが新機能を生み出したとき、E2Eの問いは「関数は期待値を返すか？」ではありません。「実際のユーザーがこの機能を最初から最後まで正常に使えるか？」です。その問いに答えるには、フローを実際に実行する必要があり、それを説明するコードを読むだけでは不十分です。
TestSpriteがCursor内でE2Eテストを実行する仕組み
TestSpriteはプロダクショングレードのMCPサーバーを提供しており、Cursorだけでなく、Claude Code、Windsurf、Trae、VS Code、その他MCPをサポートするあらゆるAI IDEにネイティブ接続できます。設定が完了すれば、CursorのチャットインターフェースからE2Eテストパイプライン全体を利用できます。
1つの指示ですべてが始まります：
「TestSpriteでこのプロジェクトをテストしてください。」
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
次に行われるのはコード解析ではありません。並列探索エージェントの群れが実行中のアプリケーションを訪れ、実際のユーザーと同じようにナビゲートします。UIフローをクリックし、実際の入力でフォームに入力し、エントリーポイントから完了まで多段階のジャーニーを進み、各ステップで状態を引き継ぎます。それらのジャーニーのあらゆる時点で何が起きているかを観察し、結果がプロダクトの期待する動作と一致しない場合を検知します。
エージェントは並列で実行し、さまざまなパスを同時に探索します。それはまるで、異なる目的を持つユーザーのグループが同時にプロダクトを使用するようなものです。結果は、仕様やソースファイルを読むのではなく、実際のインタラクションから構築された実ユーザージャーニーの構造化マップです。
Cursorワークフロー：コード変更から動作検証まで
Cursorを主要な開発環境として使用するチームにとって、実際のワークフローがどのようなものかを説明します。
開発者はCursorのAIと協力して機能を構築または修正します。セッションは複数のファイルにわたることがあります。新しいAPIエンドポイント、更新されたフロントエンドコンポーネント、多段階フロー全体の状態管理の変更など。コードは正しく見えます。Cursorのインライン提案も確認済みです。差分もきれいです。
マージ前に、開発者はチャットで一つの指示を送ります。TestSpriteのMCPサーバーがそれを受け取り、ステージングまたはプレビュー環境のURLに対してE2Eパイプラインを起動します。
探索エージェントがアプリケーションをナビゲートし、影響を受けるフローを発見して実行します。機能が新しいユーザージャーニーを追加した場合、エージェントはそれを探索してテストします。機能が既存のフローを変更した場合、エージェントは現在の動作に対してそのフローを再実行します。AIコーディングによる変更が開発者が直接作業していない部分で静かに何かを壊した場合、エージェントはそれを検知します。変更されたファイルだけでなく、プロダクト全体のサーフェスを探索するからです。
失敗情報は構造化された形式でCursorのチャットに返されます。スタックトレースではありません。エージェントが何をしていたか、何が起こると期待していたか、そして実際に何が起きたかの説明です。Cursorのコーディングエージェントはその説明を受け取り、同じセッション内で修正を提案できます。開発者が確認して適用し、別のE2E実行をトリガーして修正が正しく適用されたことを確認できます。
コード変更からE2E検証、修正適用までの全ループが、ツールを切り替えることなくCursor内で完結します。
多段階フローこそE2Eテストが真価を発揮する場所
単一アクションのテストにも意味はあります。しかし、ユーザーに届き信頼を損なう障害は、ほぼ常に多段階のものです。
ユーザーはカートに商品を追加し、チェックアウトへ進み、割引コードを適用し、配送方法を選択し、支払い情報を入力して購入を完了します。それぞれのステップは個別に成功しながらも、シーケンス全体として失敗することがあります。割引コードは税金計算前に適用されます。ユーザーが決済プロバイダーにリダイレクトされるとカートの状態が持続しません。確認ページは表示されますが、合計金額が間違っています。
コード層のテストは各ステップを個別に検証します。E2Eテストはシーケンスを実行します。
TestSpriteの探索エージェントは、実際のユーザーのブラウザセッションと同じようにステップをまたいで状態を引き継ぎます。ステップ3で適用された割引コードは、ステップ4でエージェントが目にするものに影響します。ログイン時に確立されたセッション状態はチェックアウトフロー全体を通じて持続します。支払い情報入力後に配送方法を更新するために戻るなど、フロー中の変更も探索の一部です。
CursorセッションによってステートマネジメントやAPIの動作が変わった後に多段階フローが壊れた場合、結果が期待値から乖離した正確なシーケンスの時点で障害が表面化します。開発者は、どのステップが失敗し、エージェントが何に遭遇し、何を期待していたかの正確な説明を受け取ります。
この精度はCursorのコーディングエージェントにとって重要です。エージェントは失敗の説明を使って問題を特定して修正するからです。曖昧なテスト失敗は調査を生み出します。構造化されたE2E失敗の説明は修正を生み出します。
追加設定不要のバックエンドE2Eカバレッジ
E2Eフローはフロントエンドで終わりません。重要なバックエンドロジックを持つアプリケーションでは、完全なE2EテストがAPIレイヤーも通じて実行される必要があります。
TestSpriteのBackend Testing 2.0は、同じ探索優先のアプローチをAPIに適用します。バックエンドのテスト計画を生成する前に、エージェントはエンドポイントを実際に呼び出し、どのように応答するかを観察します。実際のステータスコード、実際のフィールド名、実際のレスポンス形式です。アサーションはその観察に基づいています。
多段階バックエンドフローでは、実際のレスポンスから取得した動的変数（作成されたリソースのID、返されたトークンなど）が自動的に後続ステップに引き継がれます。完全なCRUDライフサイクルが初回から最後まで実行されます。2つのエンドポイントを順番に呼び出した場合にのみ壊れるサービス間の相互作用は、フロントエンドの多段階フローと同じ探索ロジックによってカバーされます。
Cursorセッションがバックエンドロジックをリファクタリングしてエンドポイントが返す内容を静かに変更した場合、次のE2E実行がその乖離を検知します。曖昧なアサーションエラーとしてではなく、具体的な発見として：このエンドポイントは以前このレスポンス形式を返していたが、現在は異なるものを返しており、その結果としてE2Eフローがここで壊れた、というように。
認証の自動処理で常に新鮮なクレデンシャル
認証済みフローをカバーするE2Eテストには、毎回の実行で有効なクレデンシャルが必要です。クレデンシャルは期限切れになります。トークンは古くなります。昨日まで動いていたテストスイートが、セッションの期限切れで今日は失敗し、チームはその失敗がクレデンシャルの問題なのか本物のリグレッションなのか判断できません。
TestSpriteのAuto-Authは認証を自動的に処理します。パスワードエンドポイント、OAuthリフレッシュトークン、AWS Cognitoフローが毎回のテスト実行前に実行されます。エージェントは認証レイヤーをバイパスするショートカットではなく、実際のログインフローを通じて認証済み状態に到達します。スケジュールされたE2Eリグレッション実行が期限切れのJWTで失敗することはありません。
認証の依存関係が欠落していたり壊れていてテストが実行できない場合、TestSpriteはわかりやすい英語（日本語）の説明とともにBlockedステータスを表示します。Cursorの開発者は、その失敗がE2Eリグレッションを反映しているのか、認証設定の問題なのかをすぐに把握できます。
Cursor内ループと並行したCIカバレッジ
MCPインテグレーションは、Cursor内でのE2E検証ループをリアルタイムで処理します。GitHub Actionsインテグレーションは、同じカバレッジをCIまで拡張します。
すべてのプルリクエストが、実際のアプリケーションに対して自動E2E実行をトリガーします。結果はレビュー開始前にPRコメントとして投稿されます。レビュアーはdiffと並べてE2Eカバレッジを確認できます。ユーザーフローを壊す変更、バックエンドのコントラクト違反、または認証済みパスの失敗は、コードがマージされる前に検出されます。
テストはTestSpriteのセキュアなエフェメラルクラウドサンドボックスで実行されます。数秒で起動し、隔離された環境で実行され、自動的にクリーンアップされます。テスト環境の設定も、インフラの管理も、ローカルセットアップも不要です。
Auto-Heal Rerunは、プロダクトの進化に合わせてE2Eスイートを最新の状態に保ちます。UIの変更によってプロダクトの動作とは無関係な理由でテストが失敗した場合、エージェントは誤検知として報告するのではなく、テストを適応させます。真のリグレッションは明確に検出されます。外観上の変更がノイズを生み出すことはありません。
まとめ
CursorはMCPサーバーを通じてE2Eテストを実行でき、その体験は別のテストツールに切り替えるのとは大きく異なります。テスト結果は、コードが書かれたのと同じチャットインターフェースに届きます。コーディングエージェントは失敗情報に直接対処できます。コードの変更から動作の検証までのループが、開発セッション内で完結します。
そのループの価値を決めるのは、E2Eテストが実際に何を検証するかです。TestSpriteのMCPサーバーは、Cursorが変更したばかりのソースファイルに対するアサーションではなく、ライブアプリケーションに対して実際のユーザーフローを実行します。エクスプロレーションエージェントは実際のユーザーと同様にプロダクトをナビゲートします。失敗レポートは、コーディングエージェントが対処できる動作上の乖離を説明します。Auto-Authは認証済みフローのカバレッジを維持します。GitHub Actionsインテグレーションは、すべてのプルリクエストにE2Eカバレッジを拡張します。
AIを活用した開発のスピードに見合った検証を求めるCursorチームにとって、MCPサーバーを通じたE2Eテストの実行はこのような形であるべきです。
TestSpriteをMCP経由でCursorに接続し、今日最初のE2Eセッションを実行してみましょう。