Vibe Testing MCP の設定が取り除くもの
主にコンテキストスイッチです。通常の検証では、会話を離れてアプリを開き、画面を操作して何かに気づき、戻ってきてそれを説明することになります。そのステップごとに少しずつ情報が失われ、最後のステップで最も多くが失われます。
接続さえ設定しておけば、画面操作はエージェントが行い、何が起きたかはあなたの記憶ではなく記録として報告されます。作業する場所は一つのままで、証拠の質は上がります。
何を依頼し、何が返ってくるのか
役に立つ依頼とは、リロードすれば確かめられる具体的な事柄を名指ししたものです。「サインアップが動くか確認して」では曖昧すぎて、失敗しようがありません。「新しいメールアドレスでサインアップし、サインアウトしてから再度サインインし、ダッシュボードに新しいアカウントが表示されることを確認して」——これが検証です。
返ってくる結果には、何を試みたか、アプリが実際にどう振る舞ったか、そしてその二つがどこで食い違ったかが示されているべきです。最後の点があるからこそ、失敗は気を滅入らせるだけのものではなく、対処できるものになります。
知っておきたい3つの落とし穴
| 失敗しようのない検証 | 曖昧な依頼からは、常に成功する検証が生まれます。安心感はありますが、何も守ってはくれません。 |
| 誤ったやり方で得たグリーン | 検証を成功させるよう指示されたエージェントは、検証のほうを書き換えることがあります。作られた内容には、一度は目を通してください。 |
| 昨日のことを忘れる | 会話で検証されるのは、いま取り組んでいる箇所です。以前からある機能には、セッションを越えて残る検証が必要です。 |
セットアップ
MCP サーバーは CLI とは別のパッケージであり、 @testsprite/testsprite-mcpとして公開されています。ダッシュボードで取得した API キーとともにエディタの MCP 設定に追加すると、エディタがサブプロセスとして実行します。Claude Code、Cursor、Windsurf、VS Code、GitHub Copilot、Trae のいずれも対応しており、正確な設定内容はクライアントごとに異なり、 MCP インストールドキュメントに記載されています。
検証を本物にする習慣
検証に成功したとエージェントが報告したら、対象をわざと壊して、結果が赤になることを確認してください。1分で済みますし、その検証がアプリと実際につながっていることを示す唯一の証拠になります。
有効な3つの依頼と、その弱い版
役に立つ検証と飾りにすぎない検証の違いは、それを生んだ依頼文に表れます。
弱い例:「ダッシュボードが読み込まれるか確認して」。良い例:「サインインしてダッシュボードを開き、収益のタイルにダッシュ記号ではなく数値が表示されることを確認して」。後者は失敗しうる依頼です。
弱い例:「保存が機能することを確かめて」。良い例:「プロジェクト名を Alpha に変更し、ページをリロードして、ヘッダーに Alpha と表示されることを確認して」。描画されただけの変更と保存された変更を分けるのは、このリロードです。
弱い例:「権限をテストして」。良い例:「2つ目のアカウントで1つ目のアカウントのプロジェクトリンクを開き、アクセスが拒否されることを確認して」。2つ目のアカウントを名指しすることが、漠然とした懸念を結果の出るものに変えます。
どの組み合わせでも、役に立つほうを入力するのに余計にかかるのは10秒ほどです。そして、すでに前提としていたこと以外を教えてくれるのは、そちらだけです。
あとは自分抜きで実行させる
仕組みよりもトリガーのほうが重要です。デプロイのイベントに向けておけば、誰かが判断しなくてもすべての変更が検証されます。ダッシュボードからなら GitHub App が、ワークフローの内側からなら GitHub Actions のステップがそれを行います。詳細は CLI リポジトリにあります。
この接続で得られるもの
すでに開いている会話の中で検証内容を説明すれば、TestSprite がデプロイ済みのアプリに対してそれを実行し、何が起きたかを報告します。ターミナルもテストファイルも不要で、エディタを離れる必要もありません。
これが単に便利というだけでなく、持つ価値のあるものになる理由は2つあります。証拠があなたの記憶ではなく記録として残るため、語り直す過程で失われるものがありません。そして検証は残り続けるため、今日確認したフローは、来週の変更のあとも検証され続けます。
すべての機能は TestSprite のダッシュボードからも利用できます。チャットウィンドウが仕事の場でないなら、そちらのほうが適した経路です。
ターミナルを使う必要はありますか?
いいえ。この接続はエディタやチャットの中で動作し、すべての機能は TestSprite のダッシュボードからも利用できます。
検証の説明がうまくできなかった場合はどうなりますか?
成功はするものの、何の意味も持たない検証ができあがります。観測できる具体的な事象を名指しし、その検証が失敗しうることを確認すれば、ほとんどは解決します。
ログインの内側にあるものも検証できますか?
はい、その環境向けの認証情報を設定してあれば可能です。認証情報は検証の説明文ではなく、環境側に保持してください。
エージェントにテストを書かせるのと何が違うのですか?
書かれたテストには、実行する場所と実行する人がやはり必要です。こちらはデプロイ済みのアプリに対して実行し、証拠を返します。ループを閉じるのはその部分です。
検証ごとに費用はかかりますか?
実行にはクレジットを消費します。検証ツールを持ったエージェントはそれを使うので、長いセッションをエージェントに任せる前に知っておく価値があります。