Webアプリテスト用の MCP 接続がコードを読むよりも優れている理由
Web アプリケーションを静的に読めば、コードが何を意図しているのかはわかります。しかし、ブラウザがそれをどう扱うのかはわかりません。ユーザーから見える不具合の大半はこの両者のギャップに潜んでおり、アプリの描画を一度も見たことのないエージェントが書くコードの割合が増えるほど、そのギャップは広がります。
レビューでは見つからないもの
残り続ける状態
モーダルがスクロールロックを残したり、フィルターが意味をなさない文脈にまで引き継がれたりします。
2回目の操作でしか現れず、差分には決して表れません。
データ到着前のレンダリング
ページが描画され、その後にデータ取得が完了しても、何も再描画されません。
アプリを実際に操作すれば確実に再現しますが、それ以外の方法ではほぼ見つかりません。
2つ目のアカウント
開発者自身のセッションでのみ成り立つ、所有権や表示範囲の前提です。
ローカル開発
Web アプリの開発は、何かがデプロイされるずっと前から localhost 上で進みます。公開 URL にしか到達できないチェックでは、作っているものを変えるには遅すぎます。ローカルのターゲットに対応しているため、デプロイ後だけでなく、作業中にもチェックを実行できます。現時点の仕組みについては、以下をご覧ください: ドキュメント。
セットアップ
MCP サーバーは CLI とは別のパッケージで、公開名は @testsprite/testsprite-mcp。ダッシュボードで発行した API キーを添えて、お使いのエディタの MCP 設定に追加すると、エディタがサブプロセスとして実行します。Claude Code、Cursor、Windsurf、VS Code、GitHub Copilot、Trae はいずれも対応しています。設定方法はクライアントごとに異なり、詳細は以下をご覧ください: MCP インストールドキュメント。
まずカバーすべきもの
サインアップ、サインアウト、サインイン。 生成された Web アプリで最もよく見られる、完全な機能不全です。
何かを作成してリロードします。 「画面が更新された」ことと「レコードが存在する」ことを切り分けられます。
2つ目のアカウントでメインのフローをたどります。 開発者自身のセッションに埋め込まれた権限の前提を検出できます。
3つの状態という罠
Web アプリが特殊なのは、同じ機能が一度に3つの矛盾した状態を取りうる点です。実行時のバグの多くは、その状態どうしの食い違いから生まれます。
サーバーにはレコードがあります。ブラウザにはメモリ上のコピーがあります。そしてユーザーには、少し前に目にした内容から作られたメンタルモデルがあります。レコードとメモリ上のコピーは削除したものの、画面上の行が残ってしまう削除処理は、削除が失敗したと確信するユーザーを生みます。画面だけを更新してサーバーを更新しない保存処理では、その逆が起こります。
実務上の帰結として、3つのうち1つしか見ないチェックではほとんど何も証明できません。操作の直後に画面を検証すれば、ブラウザ側のコピーを確認できます。リロード後に検証すれば、サーバー側を確認できます。同じ操作を2回行えば、1回目が何かを残していないかを確認できます。この3つを組み合わせれば、実際にユーザーへ届く問題の大半をカバーできます。しかも、いずれもコードを読む必要はありません。
次に、セッション後も残るようにする
MCP 接続がカバーするのは、変更したその瞬間です。リグレッションを防ぐには、誰かがキーボードの前にいるかどうかに関係なく、同じチェックが動き続ける必要があります。
GitHub App は TestSprite のダッシュボードで設定する Webhook です。パイプラインがすでに発行しているデプロイイベントを待ち受けるため、リポジトリ側には何の変更も必要ありません。
GitHub Actions は このステップを自分のワークフローの中に組み込む方法で、設定はターミナルから行います。現在利用できるコマンドについては、以下をご覧ください: CLI リポジトリ。
差分では確認できないことを TestSprite が確認する
実行中のアプリケーションを開いて実際に操作します。上記の3つの不具合を見つけるには、これしか方法はありません。操作の後に残ってしまう状態、データに追いつかないままのレンダリング、2つ目のアカウントでは変わる挙動は、いずれもソースコード上では見えず、実際に使えば明らかになります。
この接続はエージェントのループの内側にあるため、チェックは変更の後ではなく、変更を行う作業の一部として実行されます。エージェントがテストケースを作成し、実行し、差異を読み取って繰り返すので、目にするのはやり取りの往復ではなく結果です。
最終的に手に入るのは、変更ごとに再検証されるフローの集まりです。これにより、権限の前提や古いフィルターの問題が、それを見つけたセッションの終了後にひそかに再発することはなくなります。
ソースコードは必要ですか?
いいえ。実行中のアプリケーションをそのインターフェース経由で操作し、挙動を報告します。コードはすでにエージェントが持っています。
ローカルの開発サーバーもテストできますか?
フロントエンドの実行であれば、お使いのマシンからのトンネル経由で可能です。バックエンドのみのローカルターゲットには、到達可能な URL が必要です。
実際のメール送信や決済が必要なフローはどうなりますか?
テストモードと専用のアカウントを使ってください。実際の外部サービスへの副作用が避けられないものは、意図的に手動で確認するほうが適しています。
Web アプリにはいくつチェックを用意すべきですか?
まずは上記の3つから始め、実際に遭遇したバグごとに1つ追加していきます。割合を目標に据えたカバレッジよりも、実際の不具合に沿って広げたカバレッジのほうが効果的です。
これは CLI と同じものですか?
機能は同じで、入口が違います。MCP はエディタ内での作業に、CLI はスクリプトやパイプラインに向いています。