Cursor は MCP サーバーを通じて E2E テストを実行できるか？
Zeshi Du
できます。そして一度その仕組みを理解すれば、別のテストツールに戻ることは不要に感じられるでしょう。
Cursor が MCP サポートを追加したのは、IDE 内の AI エージェントがコンテキストを切り替えることなく外部ツールにネイティブ接続できるようにするためです。多くのツールにとってそれは、データを取得したりアクションをトリガーしてチャットに結果を返したりすることを意味します。MCP 上に構築されたテストエージェントにとっては、さらに重要な意味を持ちます。コードを書いた Cursor セッションの中で、E2E テストパイプライン全体が実行されるのです。
開発者はターミナルを開いたり、ダッシュボードに切り替えたり、CI の実行を待ったりすることなく、作ったものが実際に動くかどうかを確認できます。指示を出すだけで、エージェントがライブアプリケーションに対して E2E テストを実行し、同じチャットウィンドウに結果が返ってきます。
それが簡潔な答えです。より実用的な問いは、それらの E2E テストが実際に何をするのかということです。なぜなら、MCP 経由で接続されているすべてのテストエージェントが同じことをしているわけではないからです。
MCP を通じた E2E テストが本来意味すべきこと
MCP はプロトコルであり、品質の基準ではありません。MCP を通じてテストツールを Cursor に接続することは、そのツールが IDE 内で指示を受け取り結果を返せることを意味します。それは、その結果が実際の E2E の動作を反映しているかどうかについては何も保証しません。
MCP 経由で動作するツールの多くは、Cursor から参照できるソースファイルを読み込むことでテストを生成します。コンポーネントツリーを検査し、関数呼び出しをトレースし、コードが何をすると記述されているかに基づいてアサーションを生成します。インテグレーションはネイティブです。しかしそのテストはエンドツーエンドではありません。
真の E2E テストには、実行中のアプリケーションが必要です。ナビゲーションが必要です。ステップをまたいで持続する状態が必要です。最初のアクションから最終的な結果まで、スタックのあらゆる層にわたって、実際のユーザーと同じように製品とインタラクションするエージェントが必要です。
Cursor での AI コーディングセッションが新しい機能を生み出したとき、E2E の問いは「関数は期待される値を返すか？」ではありません。「実際のユーザーがこの機能を最初から最後まで正常に使えるか？」です。この問いに答えるには、それを記述したコードを読むのではなく、実際にフローを実行する必要があります。
TestSprite が Cursor 内で E2E テストを実行する仕組み
TestSprite は、Cursor はもちろん、Claude Code、Windsurf、Trae、VS Code、その他 MCP をサポートするあらゆる AI IDE にネイティブ接続できる本番グレードの MCP サーバーを提供しています。設定が完了すると、Cursor のチャットインターフェースから完全な E2E テストパイプラインが利用可能になります。
すべては、たった一つの指示から始まります：
"Help me test this project with 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テストの実行がどうあるべきかの姿です。
MCPを通じてTestSpriteをCursorに接続し、今日初めてのE2Eセッションを実行してみましょう。