前回は Agent Mode の基本的な起動方法と、.github/copilot-instructions.md（または AGENTS.md）といった指示ファイルでプロジェクト固有の指示を渡す仕組みについて紹介しました。今回はそこから一歩進んで、MCP（Model Context Protocol）との連携を中心に、ファイル横断リファクタリング・テスト自動生成・コードレビューへの活用まで、実際に試したことをまとめています。
ちなみに自分は Cursor でも MCP をちょくちょく使っていたので「どうせ似たようなもんだろ」と思っていたんですが、VS Code + GitHub Copilot の文脈では設定の書き方や挙動が微妙に異なるところがあって、最初ちょっとハマりました。
このセクションでわかること
- Agent Mode に MCP を連携させるメリット
- VS Code での MCP サーバー設定方法（nvm・HTTP サーバー対応）
- ファイル横断リファクタリングの実装例
- テスト自動生成の精度と運用方法
- GitHub MCP を使ったコードレビューの活用法
- 実運用での気になった点と対策
そもそも Agent Mode に MCP を繋ぐと何が変わるか
Agent Mode 単体でも、ワークスペース内のファイルは自律的に読み書きできます。では MCP を追加する意味は何かというと、「エディタの外にある情報をエージェントループに引き込める」点にあります。
具体的にはこういったことができます：
- GitHub の Issue・PR の本文や差分を直接取得してコードを実装・修正させる
- プロジェクト外のドキュメントや API スペックを参照させる
- Jira や Slack など社内ツールの情報をコーディング作業に組み込む
- データベースのスキーマ情報をリアルタイムに参照させる
いちいちコンテキストをコピペしなくていい、という体験は想像以上に快適です。
MCP サーバーの設定方法
VS Code では、MCP サーバー設定は基本的に .vscode/mcp.json（ワークスペース）に置いて管理します。ユーザー全体で使うならユーザープロファイル側の mcp.json に入れる形です。Cursor の mcp.json と書き方は似ていますが、置き場所や管理方法が異なるので注意が必要です。
// .vscode/mcp.json
{
"servers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxxxxxxxxxx"
}
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/yourname/projects"
]
}
}
}
保存すると VS Code から「MCP サーバーを起動しますか？」とポップアップが出ることがあるので Start を押します。コマンドパレット（Cmd+Shift+P）から MCP: List Servers を実行して Running になっていれば接続完了です。
nvm ユーザーはここに注意
Node.js のバージョン管理に nvm を使っている場合、VS Code 経由で起動すると npx のパスが解決できずにサーバーが起動しないことがあります。その場合は command にフルパスを指定するのが手っ取り早いです。
{
"command": "/Users/yourname/.nvm/versions/node/v22.0.0/bin/npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
...
}
自分はこれで解決しました。もっとスマートな方法がある気がするんですが、いったんこれで動いているのでよしとしています。
HTTP / SSE 形式のサーバーを使う場合
stdio ではなく HTTP で動く MCP サーバーを使うときは type を指定します。
{
"servers": {
"my-local-server": {
"type": "http",
"url": "http://localhost:3000/mcp"
}
}
}
自作の MCP サーバーを Python で立てて試す場合はこちらが楽です。Python なら pip install mcp で入りますし、用途によっては pip install "mcp[cli]" のように CLI 付きで入れるやり方もあります。
実践① ファイル横断リファクタリング
Agent Mode が最も真価を発揮するのがこれだと個人的には思っています。「このモジュールを分割して」「命名規則を統一して」といった指示を出すと、関連するファイルを自律的に読み込みながら一気に変更してくれます。
自分が試したのは、Python プロジェクトで utils.py に雑然と詰め込まれていた関数群をモジュール分割するリファクタリングです。こんな感じで指示しました：
utils.py に DB 操作・S3 操作・メール送信の関数が混在しています。
それぞれ db.py / storage.py / notification.py に分割してください。
既存の import を使っているファイルも合わせて修正して、
tests/ 配下のテストも対応してください。
結果として、ファイルの新規作成・既存ファイルの import 書き換え・テストファイルの修正まで全部やってくれました。ただ、2〜3箇所だけ古い from utils import ... が残っていたので、最後は自分で grep -r "from utils import" . して確認しました。完全にお任せはまだ怖いというのが正直なところです。
GitHub MCP を使うと「この Issue の要件に従ってリファクタリングして」という指示に対して Issue の本文を直接参照して実装してくれるので、コンテキストのコピペが不要になります。これが思った以上に便利でした。
大きめの変更の前に必ずやること
Agent Mode は、権限レベルや設定によってはツール実行（ファイル編集など）前に確認が入ることがありますが、設定次第で自動承認寄りにもできます。ファイル横断の変更は取り消しが大変なので、作業前に git commit しておくのは必須です。加えて .github/copilot-instructions.md に「変更前に影響範囲を先に説明してから実装してください」と書いておくと、いきなり変更が走らずに計画を先に提示してくれるので、少し安心できます。
実践② テスト自動生成
単純なユニットテスト生成なら以前から Copilot でもできていましたが、Agent Mode になってからは「実装を読んで適切なテストケースを考える」精度がかなり向上しています。
自分がよく使うプロンプトのパターン：
storage.py の S3Uploader クラスに対して pytest のテストを作成してください。
- 正常系・異常系・境界値をカバーすること
- boto3 は moto でモックすること
- tests/conftest.py の既存フィクスチャを流用してください
tests/conftest.py を明示的に参照させるのがポイントで、プロジェクト固有のフィクスチャ・モックパターンを把握した上でテストを生成してくれます。filesystem MCP を有効にしておくと、テスト対象以外の依存ファイルも勝手に参照してくれることがあって、精度が上がる反面「どこまで読んだ？」という気持ちになることも正直あります。
生成されたテストをそのままコミットできるかというと、体感では 7〜8 割くらいの精度です。エッジケースの扱いが甘かったり、モックの setup が微妙だったりすることはあります。それでも「ゼロから書く手間」に比べると圧倒的に速いので、叩き台として使うのが現実的な運用かなと思っています。
実践③ コードレビューへの応用
これは少し変わった使い方ですが、GitHub MCP 経由で PR の差分をそのまま読ませてレビューコメントを生成させるのが個人的にはまっている使い方です。
MCP の github ツールを使って PR #42 の変更差分を取得して、
以下の観点でレビューしてください：
- セキュリティ上の問題（SQL インジェクション、認証の抜けなど）
- パフォーマンス上の懸念
- 命名・可読性の改善点
レビューは Markdown 形式でまとめてください。
一人開発だとレビュアーがいないので、このセーフネットは地味にありがたいです。「AI が OK と言ったから大丈夫」という信頼の置き方はしていないですが、見落としを指摘してもらうだけで価値があります。
なお、レビュー結果を自動的に GitHub の PR コメントとして投稿する機能が「標準」で用意されているかどうかは状況が変わりやすい印象です。MCP サーバー側に「コメント投稿」系のツールが用意されているケースはありますが、実際に投稿までやらせるならプロンプトで明示的に指示する必要があります。完全自動化するなら GitHub Actions と組み合わせる形になるので、そこは別途検討が必要です。
使っていて気になった点・制限
実際に使い続けていて気になったポイントをいくつかメモしておきます。
- ツール呼び出しの確認ダイアログ：MCP ツールを実行するたびに「このツールを使っていいですか？」という確認が入ることがあります。VS Code 側には承認の扱い（セッションの権限レベルを変える／一度許可したものをワークスペース等のスコープで記憶する、など）があるので、都度許可がつらい場合はそこを見直すのが良さそうです。セキュリティの観点で承認が重要だという説明も公式ドキュメントにあります。
- コンテキストウィンドウの消費：MCP 経由で大量のデータを取得するとコンテキストがすぐ埋まります。filesystem MCP で大きいファイルを読ませると一発でいっぱいになることがあって、「先頭 100 行だけ取得して」「概要だけ教えて」のように制限を入れる方が安定します。
- VS Code 再起動時の注意：VS Code を再起動した後の MCP サーバーの状態は環境や設定次第で変わるようです。再起動後は
MCP: List Serversでステータスを確認して、止まっていたら手動で Start する、くらいの運用にしておくと事故りにくいです。自動起動・自動再起動まわりの設定もあるようですが、自分の環境ではまだうまく噛み合っていません。
ここらへんはまだよくわかっていない部分も多くて、もっとうまいやり方がありそうです。
まとめ
Agent Mode + MCP を組み合わせることで、「エディタ内のコードだけを見る AI」から「外部の情報も含めて文脈を持つエージェント」に変わります。ファイル横断リファクタリングやテスト生成は十分実用レベルで、コードレビューへの応用も一人開発では効果を感じています。
設定の手間はありますが、一度構築してしまえば「コンテキストのコピペ」という手作業から解放されます。GitHub に API トークンを預けることになるので、セキュリティ周りは慎重に、というところは忘れずに。
▶ 前回記事：GitHub Copilot Agent Mode 実践入門 — AGENTS.md と基本操作
📚 シリーズ「GitHub Copilot Agent Mode 実践入門」（第3回 / 全4回）
← 前回の記事: 前回の記事はこちら
→ 次回の記事: 公開後にリンクが追加されます
参考になったらクリックしてもらえると嬉しいです!
