GitHub Copilot in Visual Studio の3月更新は、単に補完やチャットが少し便利になった話ではありません。4月2日に公開された GitHub changelog では、Visual Studio 向け Copilot の3月更新として、カスタムエージェント、agent skills、MCP 連携、MCP の許可リスト統制、さらに find_symbol やプロファイリング連携などがまとめて案内されました。結論から言うと、今回の更新で Copilot は「個人向けの補助AI」から「チームのルールと外部知識を持つ IDE 内エージェント」へ一歩進んだと見てよいです。 (The GitHub Blog)
その一方で、実務投入のハードルが完全になくなったわけではありません。機能ごとに必要な Visual Studio のビルドが異なり、MCP は便利な反面、許可するサーバー、使わせるツール、除外するデータ、承認フローを先に決めないと「便利なだけの無秩序な自動化」になりやすいからです。ここでは、GitHub Copilot in Visual Studio の3月更新で何が変わったのかを整理しつつ、開発現場と企業ITの両方の視点で、どこから試すべきかまで具体的に解説します。 (Microsoft Learn)
GitHub Copilot in Visual Studio の3月更新で変わったこと
4月2日の changelog は、Visual Studio 2026 の18.4系で段階的に入った内容を「3月更新」として総括したものです。ポイントは、AI の回答品質そのものよりも、役割を分ける仕組み、外部知識をつなぐ仕組み、それを企業で統制する仕組みがまとまってきたことにあります。 (The GitHub Blog)
| 追加要素 | 何が変わったか | 実務での意味 |
|---|---|---|
| カスタムエージェント | リポジトリの .github/agents/ に .agent.md を置いて、チーム専用の Copilot エージェントを定義できるようになりました。MCP で外部知識にも接続できます。 (Microsoft Learn) | コードレビュー、移行計画、設計確認などを「毎回説明する」のではなく「役割として呼び出す」運用に変えやすくなります。 |
| agent skills | .github/skills/ や ~/.copilot/skills/ の SKILL.md をもとに、関連タスクでスキルを自動適用できるようになりました。Visual Studio 2026 18.4.1 では agent skills サポート追加も記録されています。 (Microsoft for Developers) | 手順書やノウハウを「必要なときだけ効く補助知識」として共有しやすくなります。 |
| MCP ガバナンス | Visual Studio での MCP サーバー利用が GitHub の許可リストポリシーを尊重し、未承認サーバーはブロックされます。 (Microsoft for Developers) | 外部ツール連携を広げつつ、企業側で「どのサーバーまで許可するか」を管理できます。 |
find_symbol | シンボル参照、型情報、宣言、スコープを理解する言語対応ナビゲーションが入り、複数ファイルにまたがる変更の精度が上がりました。 (Microsoft for Developers) | テキスト検索頼みの雑な修正ではなく、構造を見たうえでのリファクタや追従修正に向きます。 |
| デバッグ・性能・脆弱性対応 | Test Explorer の Profile with Copilot、PerfTips と Profiler Agent の連携、NuGet 脆弱性の Fix with Copilot が追加されました。 (Microsoft Learn) | 問題発見から修正までを IDE 内で閉じやすくなり、AI が「相談相手」ではなく「実作業の相棒」に近づきます。 |
大事なのは、今回の追加要素がそれぞれ独立していないことです。カスタムエージェントで役割を切り、agent skills で手順を再利用し、MCP で外部知識を呼び込み、allowlist で統制する。ここまでそろうと、Copilot は「その場の会話相手」ではなく、チーム運用の構成要素になります。 (Microsoft for Developers)
IDE での AI 活用の現在地は「聞く」から「任せる」へ
Visual Studio 側のドキュメントでも、GitHub Copilot はデバッグ、プロファイリング、テスト、モダン化と深く結びついた組み込みエージェントを持ち、agent mode では自然言語で高レベルな依頼を与えると、計画作成、コード編集、ツール呼び出し、ターミナル実行、結果の再評価まで反復できると説明されています。つまり、今回の文脈は「チャットが強化された」ではなく、「IDE の作業フロー自体がエージェント化している」です。 (Microsoft Learn)
たとえば、@debugger は呼び出し履歴や変数状態を見ながら例外原因を追えますし、@profiler はプロファイリング基盤に接続してボトルネックを提案します。そこにカスタムエージェントを重ねると、「社内規約に沿って PR をレビューする」「移行計画を先に切る」「設計レビューの観点だけで見る」といった、チームごとの役割を IDE 内に持ち込めます。 (Microsoft Learn)
さらに、3月更新で入った find_symbol は、単なる文字列検索ではなく、参照箇所、型情報、宣言、スコープを理解した上で複数ファイルの変更を支援します。リネームやシグネチャ変更、呼び出し側の追従修正のような「人間でも雑にやると事故りやすい作業」で効くのはここです。 (Microsoft Learn)
何をどこに置くべきか
3月更新を活かすうえで迷いやすいのが、「ルールは instructions に書くのか」「agent に持たせるのか」「skills に切るのか」という設計です。実務では、この切り分けを先に決めるだけで運用がかなり楽になります。 (GitHub Docs)
| 仕組み | 向いている用途 | 置き場所・使い方 |
|---|---|---|
| 組織／リポジトリの custom instructions | 全員に常時守らせたいルール | リポジトリ全体の標準、レビュー観点、アクセシビリティ基準など。GitHub Docs では broad context に自動適用される仕組みとされ、4月2日には organization custom instructions が GA になりました。 (GitHub Docs) |
| custom agents | 呼び出して使う役割別エージェント | .github/agents/*.agent.md に定義し、agent picker や @agent名 で使います。コードレビュー担当、移行計画担当、フルスタック実装担当などが向きます。 (Microsoft Learn) |
| agent skills | 関連すると自動で読み込まれる手順・資産 | .github/skills/<skill>/SKILL.md や ~/.copilot/skills/<skill>/SKILL.md に置く方式で、手順・スクリプト・リソースの束を必要時だけ効かせます。 (Microsoft for Developers) |
迷ったら、いつも守らせたいなら instructions、役割で呼び分けたいなら custom agents、特定タスクだけ自動で補助したいなら agent skills、で考えると整理しやすいです。これは GitHub が示す各カスタマイズ機能の定義とも整合します。 (GitHub Docs)
最初の一体は、たとえば次のような「役割限定」のエージェントが無難です。
---
name: Architecture Reviewer
description: ADR と設計規約に沿って変更案を確認する
tools: ["code_search", "readfile", "find_references"]
---
あなたはアーキテクチャレビュー担当です。
レビュー時は次を必ず確認します。
- レイヤーをまたぐ不適切な依存関係がないか
- 例外処理とログ規約に反していないか
- 公開 API に破壊的変更が入っていないか
- 関連テストが追加・更新されているかポイントは、最初から何でもできる万能エージェントを作らないことです。ドキュメント上、tools を指定しなければ利用可能なすべてのツールが有効になり、しかもツール名はプラットフォームごとに異なります。まずは必要最小限から始め、Visual Studio の Tools アイコンで実際のツール名を確認してからチーム展開するのが安全です。 (Microsoft Learn)
MCP は便利さより先に「統制の設計」が要る
MCP は、AI が外部ツールやサービスと統一インターフェイスでやり取りするためのオープン標準です。Visual Studio ではローカル・リモート両方の MCP サーバーに対応し、ツールだけでなく、プロンプト、リソース、サンプリングも扱えます。内部ドキュメント、設計システム、API、データベース、ADR などを agent mode に接続できるため、Copilot がリポジトリ外の文脈を持てるようになります。 (Microsoft Learn)
ここで重要なのは、「MCP が使える」こと自体より、「どこまで使わせるか」を先に決めることです。便利さの伸び幅が大きいぶん、設計を怠ると統制不能になりやすいからです。 (GitHub Docs)
許可するサーバーを先に決める
GitHub Copilot の管理側では、MCP の使用可否やレジストリ URL、allowlist を設定できます。Registry only にすると、レジストリ掲載サーバー以外は使えません。しかも、この制御はローカル MCP サーバーにも及びます。Business / Enterprise では MCP ポリシー自体が既定で無効なので、まずは意図して有効化し、どのサーバーを許可するかを決めるのが出発点です。 (GitHub Docs)
構成をどこに置くか決める
.mcp.json を %USERPROFILE% に置けば個人用のグローバル設定、<SOLUTIONDIR>\.mcp.json に置けばリポジトリで共有しやすい設定になります。実務では、最初は個人プロファイルで試し、再現性が取れたらリポジトリ管理へ移す流れが扱いやすいです。これなら「個人の実験」と「チーム標準」が混ざりにくくなります。 (Microsoft Learn)
承認フローを省略しない
Visual Studio では、MCP で追加したツールは既定でオフで、使うときは明示的に有効化します。さらに Copilot は、組み込みでないツールやターミナルコマンドの実行前に確認を求め、セッション単位・ソリューション単位・今後すべてで許可する設定も選べます。PoC 段階でここを緩めすぎると、「いつの間にか強いツールが常時有効」という状態になりやすいので、最初は手堅く運用したいところです。 (Microsoft Learn)
機密データ対策は allowlist だけでは足りない
agent mode が直接操作できるのは原則として開いているソリューション配下のローカルファイルですが、ターミナルコマンドは Visual Studio プロセスと同じ権限で実行されます。また、管理者はコンテンツの除外で特定ファイルを Copilot の補完やチャットから外せます。つまり、MCP allowlist だけで安心せず、「使わせないファイル」と「走らせないコマンド」も一緒に設計する必要があります。 (Microsoft Learn)
なお GitHub Docs では、MCP servers in Copilot ポリシーは MCP が GA の Copilot surfaces を制御する一方、GitHub MCP Server を第三者ホストアプリで使う場合の権限までは管理しないと明記されています。Visual Studio で統制が効くことと、全社の AI クライアント統制が終わることは別物です。 (GitHub Docs)
実務投入するなら、まずはこの3パターンが試しやすい
社内規約ベースのコードレビューを標準化する
一番始めやすいのは、レビュー専用の custom agent を1つ作り、スタイルガイドや ADR を MCP 経由で参照させる形です。公式ドキュメントでも、コードレビュー agent がスタイルガイドに接続して実際の規則に照らして PR を確認する例が示されています。レビュー観点を毎回プロンプトで言い直さなくて済むので、属人化しやすいレビュー品質を揃えやすくなります。 (Microsoft Learn)
遅い .NET テストの原因を絞る
パフォーマンス改善系なら、Test Explorer の Profile with Copilot と、デバッグ時 PerfTips の Profiler Agent 連携が相性抜群です。18.4 以降では特定テストを1クリックでプロファイルでき、PerfTip から CPU やメモリの文脈付きで最適化提案を受けられます。「遅い理由は分かるが、直し方が定まらない」チームに向いています。なお、Profile with Copilot は現時点で .NET サポートです。 (Microsoft Learn)
NuGet 脆弱性対応を後回しにしない
依存関係管理では、Solution Explorer から NuGet パッケージ脆弱性を Copilot で修正できる導線が増えました。脆弱性を検出したら、その場で適切な依存関係更新を提案・適用できるため、別タスク化して放置されがちな「後で直す」を減らしやすいです。セキュリティ運用と開発フローを分断しにくいのが強みです。 (Microsoft Learn)
先に知っておきたい注意点
よくある失敗は、「VS Code で見たサンプルをそのまま持ってくる」「agent に全権限を与える」「MCP ポリシーがあれば全部統制できた気になる」の3つです。今回の更新は強力ですが、強力だからこそ、運用を雑にすると逆に扱いづらくなります。 (Microsoft Learn)
| つまずきやすい点 | なぜ起きるか | 実務での対策 |
|---|---|---|
| VS Code 向けサンプルをそのまま流用する | ツール名は GitHub Copilot のプラットフォームごとに異なります。 (Microsoft Learn) | Visual Studio の Tools アイコンで使えるツール名を確認してから agent を共有します。 |
tools を書かずに agent を配る | ドキュメント上、tools 未指定だと使用可能なすべてのツールが有効になります。 (Microsoft Learn) | 最初は最小権限で列挙し、役割に必要なものだけ許可します。 |
| MCP allowlist を設定したので安心だと思う | Registry only は有効ですが、第三者ホストアプリの GitHub MCP Server 利用まで一律統制するものではありません。 (GitHub Docs) | Visual Studio の統制と、全社の AI クライアント統制を分けて設計します。 |
| ファイルアクセス制限があるから安全だと思う | agent mode のターミナルコマンドは Visual Studio プロセスと同じ権限で走ります。 (Microsoft Learn) | コマンド承認を残し、PoC では自動許可を広げすぎないようにします。 |
| allowlist があれば機密コード対策も十分だと思う | 機密ファイルの扱いは content exclusion の設計が別途必要です。 (Microsoft Learn) | 除外対象ファイルやフォルダを先に整理してから展開します。 |
まず確認したい対応ビルドと見え方
今回の「3月更新」は単一の一発配信ではなく、Visual Studio 2026 18.4.0 で custom agents や find_symbol、MCP governance などが入り、18.4.1 では agent skills のサポート追加が記録されています。GitHub が4月2日に changelog で総括したため、環境によって「聞いた機能が見えない」が起きやすい点には注意したいところです。 (Microsoft Learn)
| 確認項目 | 目安 |
|---|---|
| Agent mode | Visual Studio 2022 バージョン 17.14 以降。 (Microsoft Learn) |
| MCP サーバー利用 | Visual Studio 2026 または Visual Studio 2022 17.14。最新の MCP 機能には最新サービスリリース推奨。GitHub MCP サーバーの構成例は 17.14.9 以降。 (Microsoft Learn) |
| custom agents | Visual Studio 2026 バージョン 18.4 以降。 (Microsoft Learn) |
| custom agents の UI | agent picker は執筆時点のドキュメントで Visual Studio 2026 Insiders build で利用可。環境によっては @agent名 前提です。 (Microsoft Learn) |
| agent skills | Visual Studio 2026 18.4.1 でサポート追加。 (Microsoft Learn) |
Profile with Copilot | Visual Studio 2026 バージョン 18.4 以降。現時点では .NET テスト対応。 (Microsoft Learn) |
| PerfTips と Profiler Agent | Visual Studio 2026 バージョン 18.4 以降。 (Microsoft Learn) |
「Visual Studio 2022 17.14 を使っているから全部使える」とも、「Visual Studio 2026 に上げたから自動で全部見える」とも限りません。特に custom agents、agent skills、Profile with Copilot はビルド差や UI 差の影響を受けやすいので、更新前に対象チームの環境を棚卸ししておくと導入時の摩擦が減ります。 (Microsoft Learn)
Enterprise 導入の現実味は、IDE 外の運用面でも増している
今回のニュースを Visual Studio だけの話で終わらせない方がよい理由もあります。4月2日の GitHub changelog では、Visual Studio 向け更新と別に、Business / Enterprise 管理者が全リポジトリ共通の既定指示を入れられる organization custom instructions の GA と、組織レポートでの CLI 活動のユーザー別可視化も案内されました。IDE の拡張、ポリシー、利用可視化が同時に進んでいるため、Copilot を「個人任せ」で使う段階から脱しやすくなっています。 (The GitHub Blog)
GitHub Copilot in Visual Studio の3月更新を一言で言えば、AI を IDE に「追加した」のではなく、IDE の中で運用できる形に「整え始めた」更新です。次にやるべきことは明確です。まず自社の Visual Studio ビルドを確認すること。次に、役割を絞った custom agent と read-only の MCP サーバーを1つずつ小さく試すこと。そして最後に、allowlist、tool approvals、content exclusion を決めてから広げることです。ここまでやれば、Copilot は便利なデモではなく、実務の道具としてかなり評価しやすくなります。 (Microsoft Learn)
コメント