VS CodeはMCPテストエージェントを使用できるか？
Zheshi Du
はい、使用できます。そしてその答えが「イエス」である理由を理解することで、ソフトウェアテストの今後の方向性が見えてきます。
VS Codeは、Microsoftが2025年初頭にGitHub CopilotのエージェントモードにMCPを追加して以来、Model Context Protocolをサポートしています。つまり、プロトコル上に構築されたテストエージェントを含むあらゆるMCPサーバーが、VS CodeのAI支援コーディング環境に直接プラグインできます。開発者はエディターを離れる必要がありません。テストパイプラインは、コードが書かれたのと同じインターフェース内で実行されます。
長年にわたりVS Codeと個別のテストダッシュボードを行き来してきたチームにとって、これはワークフローを大きく変える出来事です。また、正式なテストカバレッジをまったく構築してこなかったチームにとっては、テストが実施されなかった主な原因であった摩擦のほとんどを取り除くことができます。
実際にどのような意味を持つのか、そしてVS Codeに接続するテストエージェントが接続そのものと同じくらい重要である理由について説明します。
MCPとは何か、そしてテストにおいてなぜ重要なのか
MCPはModel Context Protocolの略称です。これはAnthropicが開発したオープン標準であり、AIモデルとAI IDEが外部ツールと通信する方法を定義しています。エディター内のコーディングアシスタントが専門サービスに呼び出しを行い、構造化されたレスポンスを受け取り、その結果を進行中の開発セッションに組み込むことを可能にする共通言語として機能します。
MCP以前は、IDEと外部ツール間の統合には、カスタムプラグイン、独自のAPI、およびツールの組み合わせごとに個別の実装が必要でした。MCPはそのレイヤーを標準化します。一度構築されたMCPサーバーは、プロトコルをサポートするあらゆるIDE——VS Code、Cursor、Claude Code、Windsurf、Trae、GitHub Copilotなど——に接続できます。
テストに関して言えば、MCPは統合モデルを「パネルにテスト結果を表示する」から「開発セッション内で動作するテストエージェント」へと変革します。これは見た目上の違いではありません。パネルは出力を表示するだけです。エージェントはワークフローに参加し、何が変更されたかについてのコンテキストを受け取り、ライブプロダクトに対して検証を実行し、コーディングアシスタントが対応できる構造化された結果を返します。
テストエージェントは開発環境の隣に置かれるのではなく、その中で実行されます。
VS Code内のテストエージェントに求められること
MCP経由でテストエージェントをVS Codeに接続すること自体は容易です。接続後にエージェントが何をするかが、そのエージェントが有用かどうかを決定します。
MCP接続をサポートするほとんどのテストツールは、IDEに表示されているソースファイルからテストコードを生成するか、既存のテストランナーを起動して結果を表示するかのいずれかを行います。どちらも別ツールへの切り替えよりは改善されていますが、プロダクトが実際に動作することを検証することとは異なります。
ソースファイルからテストを生成すると、そのコードが現時点で何をするかについてのアサーションが生成されます。コードにバグがある場合、生成されたテストはそのバグを正しい動作としてエンコードします。テストはパスします。バグは残ります。ツールは実行され、結果は問題なく見え、開発者は本来の動作をしないコードをマージします。
既存のテストランナーを起動することは、実行すべきテストがすでに存在する場合にのみ有用です。テストカバレッジのないチームにとって、起動するものは何もありません。
検証のギャップを実際に埋めるテストエージェントは、コードレイヤーではなくプロダクトレイヤーで動作するものです。テストすべき内容を理解するためにソースファイルを読み込まず、実際に動作しているアプリケーションを開き、実際のユーザーと同じように操作します。実装ではなく、動作を検証します。
これが、VS Code内の有用なMCPテストエージェントが満たすべき基準です。
TestSpriteがVS Codeに接続する方法
TestSpriteは、GitHub CopilotのエージェントモードによりVS Codeにネイティブに接続できる本番グレードのMCPサーバーを提供しています。また、Cursor、Claude Code、Windsurf、Trae、その他MCPをサポートするあらゆるAI IDEにも接続可能です。
セットアップは標準的なMCP設定プロセスに従います。TestSprite MCPサーバーが設定されると、テストパイプラインはVS CodeのエージェントインターフェースからThat利用可能になります。以下の一つの指示ですべてが開始されます：
"Help me test this project with TestSprite."
その後、発見 → 計画 → 生成 → 実行 → 分析 → 修復 → レポートという完全に自律的なループが展開されます。開発者はテストランナーの設定、テストファイルの作成、ローカルテスト環境のセットアップを一切行う必要がありません。エージェントがすべてを処理します。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
ループ内でエージェントが行うこと
その指示が実行されると、並列探索エージェントの群れが動作中のアプリケーションにアクセスします。ソースファイルではなく、ライブプロダクトです。
エージェントは実際のユーザーと同じようにアプリケーションをナビゲートします。インタラクティブな要素を見つけて操作します。ボタンをクリックし、実際の入力値でフォームを入力し、最初から最後までマルチステップフローをたどり、各ステップで何が起こるかを観察します。フローの最終的な結果がプロダクトが提供すべきものと一致しない場合に気づきます。
これは、関数呼び出しをトレースするパーサーではなく、初回ウォークスルーを行う経験豊富なQAエンジニアの検証動作です。エージェントはプロダクトを実際に使用しています。生成されるテストは、実装の詳細ではなく、ユーザーの操作と観察された結果を記述します。
GitHub Copilotを使用して新機能を構築したばかりのVS Code開発者にとって、これはその機能を実際に使用するエージェントによってテストされることを意味します。エージェントは機能のUIフローをクリックして操作します。ハッピーパスとエッジケースを試します。境界値の入力でフォームを入力します。マルチステップのプロセスを前後にナビゲートします。ユーザーが操作できる機能のすべての部分が正しい結果を生成するかを確認します。
機能がバックエンドAPIを含む場合、TestSpriteのBackend Testing 2.0が同じ方法でそのレイヤーをカバーします。APIテスト計画を生成する前に、エージェントはエンドポイントを呼び出して実際のレスポンスを観察します。実際のステータスコード、実際のフィールド名、実際のレスポンスの形状。すべてのアサーションはその観察に基づいています。CRUDライフサイクルテストは、実際のcreateレスポンスからの実際のIDを自動的に後続ステップに渡します。
VS Codeセッションへの結果の返却
テストループの出力は、構造化された形式でVS Codeエージェントインターフェースに返されます。ダッシュボードへのリンクでも、別途開く必要があるテストレポートファイルでもありません。指示が入力された同じチャットセッション内に構造化された失敗情報として表示されます。
テストがパスすると、プロダクトの動作が期待どおりであることが検証されます。テストが失敗すると、失敗の説明はエージェントが何をしていたか、何が起こると期待していたか、実際に何が起こったかを開発者に伝えます。エージェントは終始プロダクトレイヤーで動作していたため、フレーミングはユーザー視点で一貫しています。
ほとんどのVS CodeユーザーがAIコーディングアシスタントとして使用しているGitHub Copilotは、その構造化された失敗の説明を受け取り、同じセッション内で修正案を提案できます。コード変更からプロダクト検証、修正の適用までのサイクルが、開発者がVS Codeを離れることなく実行されます。
IDE内ループと並行してCIカバレッジを希望するチームには、TestSpriteのGitHub Actions統合が同じパイプラインをプルリクエストに組み込みます。すべてのPRが自動テストランをトリガーします。結果はPRコメントとして投稿されます。レビュアーはdiffと並んでプロダクトレイヤーの検証を確認できます。
最も恩恵を受けるチーム
VS Code内でMCPテストエージェントから最大の恩恵を受けるチームのタイプは3つあります。
AI支援開発にGitHub Copilotを使用しているチームが主要な対象です。CopilotはVS Code内でコード生成を加速します。Copilotが生み出す検証のギャップ——正しく見えるコードとユーザーに対して正しく動作するプロダクトの乖離——は、まさにTestSpriteのMCP統合が対処するものです。2つのツールは同じIDEセッション内で連携して動作します：Copilotが書き、TestSpriteが検証します。
専任QAのいないソロ開発者や初期段階のスタートアップが2番目です。ツールが重すぎると感じて正式なテストカバレッジを構築したことがない開発者にとって、一つの指示だけで設定不要のMCPテストエージェントは障壁を完全に取り除きます。TestSpriteはQA機能そのものとなります：テスト計画、テスト実行、分析、構造化された失敗レポートがすべてVS Codeの中から提供されます。
バックエンドおよびAPIファーストのチームが3番目です。VS Code内でAPIヘビーなプロダクトを開発するチームは、Backend Testing 2.0のエビデンスに基づくアプローチから特に恩恵を受けます。アサーション生成前の実際のAPI観察により、コードがどう動作すべきかではなく、APIが実際にどう動作するかを反映したテストが生成されます。リファクタリング後のコントラクト破損は、ダウンストリームの呼び出し元に到達する前にCIパイプラインで検出されます。
「MCPネイティブ」が長期的なワークフローに意味すること
MCPテストエージェントは一度限りの実行ツールではありません。継続的な開発ループの一部です。
VS Codeに重要な変更が加えられるたびに、指示が入力されエージェントがプロダクトを検証します。テストスイートはプロダクトの進化に合わせて更新されます。Auto-Heal Rerunは、UIの変更によってプロダクトの動作とは無関係な理由でテストが失敗するケースに対処します。エージェントは本物のリグレッションと、根本的なフローに影響しないレイアウト変更を区別します。スイートは手動メンテナンスなしに正確さを維持し続けます。
Auto-Authはすべての実行にわたって認証を処理します。パスワードエンドポイント、OAuthリフレッシュトークン、AWS Cognitoのフローは、すべてのテスト実行前に自動的に処理されます。認証済みフローをカバーするテストは、スケジュール実行時に古い認証情報が原因で失敗することがありません。
TestSprite Webポータルは、より広い視点を提供します。時系列での品質トレンド、プロジェクト横断的なテスト計画の管理、スケジュール済みリグレッションの履歴などを確認できます。MCP接続はリアルタイムの検証を担います。この2つの画面は、開発者が個別に管理することなく互いを補完します。
まとめ
VS CodeはMCPテストエージェントを使用でき、MCP標準によって接続が容易になります。その接続の価値を決めるのは、エージェントが開発セッション内に入った後に何を行うかです。
ソースファイルを読み込んでアサーションを生成するテストエージェントは、テスト作成を高速化します。ライブアプリケーションにアクセスし、実際のユーザーのようにナビゲートするテストエージェントは、プロダクトの動作を検証します。
TestSpriteは2番目のアプローチに基づいて構築されています。TestSpriteのMCPサーバーはVS Code、Cursor、Claude Code、Windsurf、およびその他のMCP対応IDEにネイティブに接続します。探索エージェントは実行中のアプリケーションをナビゲートし、複数ステップのフロー、ステートフルなインタラクション、バックエンドAPIコントラクトをカバーし、コーディングエージェントが直接対処できるよう、構造化された障害情報をIDEに返します。
フォルダ内のテストファイル以上のものを求めるVS Code開発者にとって、それこそがMCPテストエージェントが実際に行うべきことです。
TestSpriteをMCP経由でVS Codeに接続し、今日初めての自律テストセッションを実行してください。