VSCodeのAgentでMCPを活用しよう

はじめに

今回は、VSCodeでCopilot Agentをより活用するために、MCPについて調べました。

VSCodeでのMCP Serverの設定

他のツールと同じように、 mcp.json で定義することで、Agentモード利用時にMCPを使うことができます。VSCodeでの設定方法を紹介します。

グローバルとワークスペース

VSCodeでは mcp.json を「グローバル用」と「ワークスペース用」と使い分けることができます。

• グローバルに配置する場合は ~/Library/Application Support/Code/User/mcp.json に書きます。
• ワークスペースに配置する場合は、ワークスペース配下の .vscode/mcp.json に書きます。

MCP Serverの追加

mcp.json を定義することでMCP Serverを追加することができますが、VSCodeでおすすめのMCPを紹介している「Discover and install MCP Servers in VSCode」というページでは、VSCodeで簡単にインストールできるMCPがまとめられています。
ここからインストールすると、 mcp.json に自動的に追加されます。
例えば、今回紹介する playwright と Context7 を追加すると、以下のようになります。

playwrightのargsに --isolated を渡すことで、cookieなどを永続しないようにしています。こうすることで、毎回まっさらなところからスタートできるので、ログイン処理などを毎回初めから実行できるようになります。

今回は、MUIのCRUDテンプレートプロジェクトをお題とし、MCP Serverを使ってみたいと思います。

ユースケース1: Playwright MCPでテストコード生成

Playwright MCPを使うと、自然言語によって Playwright を操作することができ、対話しながらさまざまなWebページを取得・操作することができます。
今回はローカルで立ち上げたReactアプリを実際に分析してもらい、Playwrightのテストコードを書いてもらいます。

まずは、プロンプトです。

これから Playwright MCP を使ってブラウザを操作します。
あなたは、Playwrightテストコードを作成するエージェントです。
以下のルールに従ってテストコードを生成してください。
– Playwright MCP を使うことは何があっても絶対に忘れないでください
– 必ず Playwright MCP を使用して、1ステップずつ処理し、その都度@playwright を利用して、TypeScript形式のテストコードを追記してください。
– Playwright MCPを使わず、シナリオを一括でコード化してはいけません。
– 生成するテストは tests/tmp/one.spec.ts の test("E2Eテスト", async ({ page, context }) => {}); の中に追記してください。

シナリオ
1. Playwright MCP を使って「http://localhost:5173」を表示する
2. 「Create」ボタンを押す
3. Nameに任意の文字を入力する
4. Ageに任意の数値を入力する
5. Join dateに任意の日付を入力する
6. Departmentに任意の部署を1つ選択する
7. 「Create」ボタンを押す
8. 新規作成した従業員が一覧に追加されていることを確認する

いろいろと試行錯誤してこのプロンプトになりました。GPT-4.1でうまく動いています。（GPT-5でも動くと思いますが、時間がかかります。）
ポイントをまとめます。

• 会話履歴の要約をオフにする
  コンテキストが膨れ上がってくると、Copilotが会話履歴の要約をします。しかし、要約後は最初の指示を忘れてしまい、うまくテストの作成ができなくなってしまいます。
  そこで、VSCodeの設定で github.copilot.chat.summarizeAgentConversationHistory.enabled をオフにすることで、会話の要約機能をオフにすることができます。
• プロンプトの冒頭で「これから Playwright MCP を使ってブラウザを操作します。」を書く
  これを書かないと、Playwright MCPを使用せず、推測でテストコードを書いてしまうことがあり、挙動が不安定になりました。
• プロンプトにテストケースを書く
  テストケースを書かないと、毎回違ったテストケースとなってしまい、安定しません。テストケースは明示したほうが精度よくテストケースが出てきます。

このプロンプトを実行すると、大まかに問題のないテストコードが生成されますが、実際に実行してみると動かない点がいくつか出てきますが、これをAgentに修正させるのは今のところ難しかったため、これは手作業で修正します。

ユースケース2: Context7 MCPで最新ドキュメントを参照

Context 7 MCPを使うと、さまざまな最新ドキュメントをRAGとして使用できるようになります。その数は膨大で、ReactやTailwind、FastAPIなどはもちろん、MUIやGolangなど、実にさまざまなドキュメントを参照できるようになります。
ドキュメントの対応状況は公式サイトにまとめられています。

使い方は、プロンプトに use context7 と足すと context 7が質問やソースコードをもとに適切なドキュメントを探し、それを参照しながら回答してくれます。
例えば、以下のようなプロンプトになります。

React 19に対応していない箇所がないか調べて use context7

そうすると、以下のような回答が得られます。

React 19の主な非互換・移行ポイント（context7公式情報より）：

– <Context.Provider>の代わりに<Context>を直接Providerとして使う新構文が導入され、旧構文は非推奨（ただし自動変換codemodあり）。
– レガシーContext API（contextTypes/getChildContext）は完全削除。React.createContext/ useContext/ contextType への移行必須。
– useContextは引き続き有効だが、React 19では新たにuse(…) APIが追加され、条件付きでContext値を取得できる（useContextは条件分岐内で使えない）。
– PropTypes, defaultProps（関数コンポーネント）は無視される。TypeScript型推奨。
– ReactDOM.render, ReactDOM.unmountComponentAtNode, createFactory, string ref などは削除。createRoot, root.unmount, JSX, ref callbackへ移行。
– ref callbackでreturn値を返すとTypeScriptエラーになる（returnせずブロックで書く）。
– useSyncExternalStore, useEffect, Suspense, Server Componentsなどは引き続き利用可能（APIの大きな破壊的変更なし）。

**workspace内のコード調査結果：**
– レガシーContext API（contextTypes/getChildContext）は未使用。
– <Context.Provider>構文は使われている可能性があるため、<Context>構文への移行を検討。
– useContext, useEffect, useSyncExternalStore, Suspenseは通常通り使われている。
– PropTypes, defaultProps, string ref, createFactory, レガシーライフサイクル（componentWillMount等）は見当たりません。
– ReactDOM.renderは使われておらず、createRootが使われている（index.tsx）。

**結論：**
– 重大なReact 19非対応箇所は現状見当たりません。
– <Context.Provider>→<Context>への書き換え（新構文）を検討するとよりReact 19らしいコードになります。
– 公式codemod（npx codemod@latest react/19/migration-recipe）で自動変換も可能です。

他に特定のファイルやAPIについて追加で調査したい場合は教えてください。

確かに、今回のプロジェクトでは useContext や Context.Provider が未だに使われていて、この指摘は正しいと言えます。
こちらは、GPT-4.1で問題なく使えました。

ちなみに、 use context7 せずに依頼すると、これらの指摘はされませんでしたので、最新情報を参照させたいときはかなり使えそうです。
また、ブラウザでドキュメントを探さなくても、IDE上で確認できるので、これは便利に使えそうです。

さいごに

今後は、複数のMCPを組み合わせて活用する方法についても調べてみたいと思います。

おすすめ書籍