VS CodeとGitHub Copilotの組み合わせは、すでに多くの開発者にとって「標準装備」と言ってもよい存在になりました。

そこに近年、新しいキーワードが加わりつつあります。

MCP（Model Context Protocol）です。

「MCP対応のCopilot」「VS CodeでMCPサーバーを使う」といった話を耳にしても、

  • 実際のところ何ができるようになるのか
  • どこまで自分の開発に関係があるのか

がイメージしづらい方も多いのではないでしょうか。

本記事では、VS CodeにMCPを導入したときの変化を、Copilotとの関係も含めて整理して紹介します。

VS Code × Copilot × MCP の関係をざっくり整理する

まずは役割分担をシンプルに整理してみます。

  • VS Code：開発者が使う「作業デスク」
  • GitHub Copilot：自然言語とコードをつなぐ「アシスタント」
  • MCP：Copilotから使えるツール・データソースをまとめた「道具箱」

イメージとしては、

  • VS Codeが作業部屋
  • Copilotが部屋の中にいる優秀な後輩エンジニア
  • MCPが、部屋の外にある倉庫や資料室への鍵

のような関係です。

Copilotだけでも、VS Code内のコードやファイルをかなり賢く扱ってくれます。

そこにMCPが加わると、

  • 「今開いているリポジトリの外側」の情報
  • 外部サービスや社内システムのデータ

にも、Copilot経由でアクセスできるようになります。

VS CodeにMCPを入れると増えるユースケース

では、具体的にどのようなことができるようになるのでしょうか。

1. エディタから離れずに外部システムの状態を確認できる

例えば、MCP経由で次のようなツールを用意したとします。

  • 自社APIの読み取り専用クライアント
  • モニタリングサービス（エラー率やレスポンスタイム）の参照ツール

すると、VS Code内のCopilot Chatに対して、

  • 「本番環境のエラー率、直近1時間の推移を教えて」
  • 「このエンドポイント（コードで開いているファイル）の実際のレスポンス時間はどのくらい？」

といった質問ができるようになります。

これまでは、

  • ブラウザを開いて
  • 管理画面にログインして
  • 対象のページを探して

といったステップが必要でしたが、会話ベースで必要な情報を引き出せるようになるイメージです。

2. Issueやドキュメントとコードをまたいだ「横断的な会話」

GitHub Issuesやプロジェクト管理ツール、NotionやConfluenceなどのドキュメントをMCPでつなぐと、

  • 「このブランチに対応するIssueの内容を要約して」
  • 「今開いているコンポーネントに関連しそうな仕様書を探して説明して」

といった会話が可能になります。

これにより、

  • 「仕様書を読むためだけにブラウザでタブを増やす」
  • 「IssueのURLを毎回探して貼る」

といった細かいコンテキストスイッチを減らせます。

3. プロジェクト横断の情報を、VS Codeから一元的に扱える

モノレポや複数リポジトリで運用しているプロジェクトでは、

  • 設定リポジトリ
  • APIリポジトリ
  • フロントエンドリポジトリ

などが分かれていることがよくあります。

MCPを使えば、

  • 今VS Codeで開いているリポジトリとは別のリポジトリの情報

にも、Copilot経由でアクセスできます。

  • 「このAPIエンドポイントの実装は別リポジトリにあるけれど、仕様を簡単に教えて」

といった問い合わせも、エディタを切り替えずに行えるようになります。

CopilotとMCPの役割分担

ここで改めて、CopilotとMCPの役割を整理しておきます。

  • Copilot：
    • 自然言語とコードの変換が得意
    • 説明・要約・リファクタリングなど「テキスト変換系」の処理を担当
  • MCP：
    • 外部システムへの入り口
    • データ取得や操作の「実行部分」を担当

ユーザーから見ると、Copilotに話しかけるだけで、裏側では必要に応じてMCPツールが呼ばれている、という構図になります。

個人開発・小規模チームでの現実的な導入ステップ

「面白そうだけれど、自分の規模感で使いこなせるのか不安」という方向けに、段階的な導入案をまとめます。

ステップ1：既製のMCPツールを試してみる

まずは、自分でサーバーを実装するのではなく、

  • ファイルシステム参照
  • HTTPクライアント

など、汎用的なMCPツールを提供しているOSSやサービスを試すところから始めます。

  • 「MCPを介してツールを呼ぶ」という体験に慣れる
  • エディタ内での動き方や、権限の感覚を掴む

ことが目的です。

ステップ2：自分たちのワークフロー用に、小さなツールを1つ作る

慣れてきたら、

  • 自作APIの読み取り専用クライアント
  • 自分のタスク管理ツールの参照API

など、一番よく使う情報源をMCPツールとして実装してみます。

  • 「今日やるべきタスクをざっくり整理して」
  • 「この機能に関係しそうなタスクやメモを一覧にして」

といった会話がVS Code上で完結するようになると、体験の変化を実感しやすくなります。

ステップ3：チームで使う際のガイドラインを軽く作る

小規模チームで使う場合は、

  • どのMCPツールを使ってよいか
  • 本番環境に対する操作のルール
  • ログや監査の方針

などを、簡単にでも文章化しておくと安心です。

セキュリティと安全性のポイント

MCPは強力な仕組みだからこそ、セキュリティ面の設計が重要です。

  • 認証：APIキーやトークンの扱い
  • 認可：どのユーザー・クライアントにどの操作を許可するか
  • ログ：どのツールがどのように使われたかを記録する

特に、書き込み系の操作（デプロイ、本番設定変更など）をMCP経由で行う場合は、

  • 追加の確認ステップ
  • 操作対象の環境制限（ステージングのみ許可など）

を入れておくことが重要です。

まとめ：VS Codeの中に「もう一つのコンソール」を持つ感覚

VS CodeにMCPを導入し、Copilotと組み合わせると、

  • エディタから離れずに、外部システムやドキュメントにアクセスできる
  • コード・Issue・仕様書・モニタリング情報をまたいだ「横断的な会話」ができる

という、新しい開発体験が手に入ります。

それは、あたかもVS Codeの中に、

  • コマンドライン
  • ダッシュボード
  • ナレッジベース

が一体化した「もう一つのコンソール」を持つような感覚に近いかもしれません。

いきなり大規模な仕組みを入れる必要はありません。

まずは、

  • 既製のMCPツールを少し試してみる
  • 自分のワークフローに直結する、小さな読み取り専用ツールを1つ作ってみる

といったところから、VS Code × Copilot × MCPの世界に触れてみてください。