Visual Studio 2026 March Update で、GitHub Copilot は「便利な補助」から「チーム専用の開発役」へ一歩進みました。3月31日付けの Visual Studio Blog では、.agent.md で定義する custom agent、再利用可能な agent skills、コード構造をたどれる find_symbol が紹介されています。結論から言うと、最初にやるべきは「共通ルールを instructions に寄せる」「繰り返し業務を1つだけ agent 化する」「横断変更は find_symbol を前提に任せる」の3つです。
この記事では、built-in agent と custom agent の違い、導入の第一歩、実務ワークフローへの当てはめ方を整理します。どこまで専用化できるのか、何から始めれば失敗しにくいのかが、Visual Studio の公式情報ベースで分かるようにまとめました。
Visual Studio 2026 March Updateのカスタムエージェント対応で何が変わったか
今回の更新で重要なのは、Copilot に「役割」「手順」「コード構造の理解」を与えられるようになったことです。custom agent は .github/agents/ に置く .agent.md で定義し、agent skills は .github/skills/ やユーザープロファイル配下から自動検出され、find_symbol は参照箇所や型情報、宣言、スコープを使ってコードをシンボル単位で追えます。単なるチャットの改善ではなく、チームのやり方に合わせて Copilot を専門化する土台が揃った、というのが今回の本質です。
公式情報をもとに整理すると、今回の3機能は次のように役割分担できます。
| 機能 | 何が増えたか | 実務で効く場面 |
|---|---|---|
| custom agents | .agent.md で役割別の Copilot を定義できる | コードレビュー、影響調査、設計相談 |
| agent skills | 再利用したい手順を skill として共有できる | build/test、PRチェック、定型生成 |
| find_symbol | 参照関係や型情報を見ながら変更できる | リファクタリング、名前変更、引数追加 |
この3つは別々に使うより、組み合わせて使った方が効果が出ます。agent が「誰として振る舞うか」を決め、skills が「どう進めるか」を固定し、find_symbol が「どこに影響するか」を支えるイメージです。
どこまで専用化できるのか
Visual Studio の custom agent が面白いのは、専用化できる範囲が広いことです。公式情報を見ると、少なくとも「リポジトリの文脈」「チームのルール」「外部の知識源」の3層まで持ち込めます。custom agent 自体は workspace awareness や code understanding、利用ツール、モデル、MCP 接続を持てますし、custom instructions は .github/copilot-instructions.md や *.instructions.md から自動で文脈として読み込まれます。skills は repo やユーザープロファイルから自動検出されるため、個人の裏技ではなく、チームの手順として再利用しやすいのもポイントです。
- リポジトリの文脈
既存の実装パターン、ソリューション構成、依存関係を前提に判断させる層です。 - チームのルール
命名規約、例外処理、テスト方針、レビュー観点のような「毎回言っていること」を固定する層です。 - 外部の知識源
社内 Wiki、設計資料、デザインシステム、API、データベースなど、repo の外にある正解を参照させる層です。
AI の専用化で効くのは、モデル名を増やすことより「何を参照し、どの順で判断し、何を出力させるか」を固定することです。MCP は特に強力ですが、Visual Studio 側では GitHub の allowlist ポリシーに従って接続先が制御されるため、最初は読み取り中心の社内ドキュメントから始める方が運用しやすいでしょう。
built-in agent と custom agent の違い
Microsoft Learn では、built-in agent を Visual Studio のネイティブ機能と深く統合された役割別エージェントとして説明しています。例として @debugger、@profiler、@test、.NET/C++ 向けの @modernize があり、デバッグ文脈やプロファイリング結果、テストフレームワーク、実際のプロジェクトグラフを前提に支援します。一方の custom agent は、同じ基盤の上にチーム独自の役割や知識源を載せる仕組みです。
| 観点 | built-in agent | custom agent |
|---|---|---|
| 主な目的 | Visual Studio が得意な既定ワークフローを深く支援する | チーム固有のワークフローを固定化する |
| 代表例 | @debugger、@profiler、@test、@modernize | Code Reviewer、Feature Planner、Design System など |
| 強み | IDE 機能との深い統合 | 役割、利用ツール、外部知識、出力形式まで決められる |
| 導入コスト | ほぼ不要 | .agent.md 設計が必要 |
| 向いている始め方 | まず Copilot の得意分野を試す | 成果が出た作業を専用化する |
迷ったら、最初は built-in agent から入るのが安全です。たとえば障害調査は @debugger、性能改善は @profiler、テスト生成は @test で十分成果が出ることがあります。そのうえで、社内規約や設計判断のように「製品標準では持てない文脈」が必要な部分だけ custom agent に切り出すと、過剰設計になりません。
instructions、skills、custom agent をどう使い分けるか
ここを混ぜると運用が崩れます。Visual Studio では、instructions は「常に添付する前提知識」、skills は「再利用する手順」、custom agent は「役割そのもの」と考えると整理しやすいです。custom instructions は .github/copilot-instructions.md や .github/instructions/*.instructions.md で管理でき、対象を applyTo で絞ることもできます。skills は .github/skills/ などから自動検出され、custom agent は .github/agents/*.agent.md に置く形です。
| 仕組み | 主な置き場所 | 何を固定するか | 向いている内容 |
|---|---|---|---|
| custom instructions | .github/copilot-instructions.md / .github/instructions/*.instructions.md | 全体ルールやファイル種別ごとのルール | 命名規約、コメント方針、C# だけの書き方 |
| agent skills | .github/skills/ など | 定型の手順 | build/test、レビュー手順、テンプレ生成 |
| custom agent | .github/agents/*.agent.md | 役割、利用ツール、対話のゴール | レビュー担当、設計担当、UI規約担当 |
迷ったら repo 側の構成は次の形にしておくと整理しやすいです。
.github/
copilot-instructions.md
instructions/
csharp.instructions.md
agents/
code-reviewer.agent.md
skills/
pr-review-checklist/
SKILL.md実務では、いきなり custom agent を増やすより、まず instructions で共通ルールを固定し、次に skills で繰り返し手順を共有し、最後に「役割が変わるもの」だけ agent 化する方が失敗しにくいです。AI を賢くするというより、迷わせない設計にするイメージです。
最初の custom agent は何を作るべきか
Microsoft Learn には、Code Reviewer、Feature Planner、Design System など、現場に直結しやすい custom agent の例が載っています。最初の1つは「毎回ほぼ同じ観点で使う」「良し悪しを測りやすい」「人によるばらつきが出やすい」仕事を選ぶのがコツです。
コードレビュー担当
レビューで毎回見る観点が決まっているなら、最初の custom agent はこれが最適です。公式例でも、命名規約、例外処理、テストカバレッジ、公開 API のドキュメントといった観点が code review agent の題材になっています。PR ごとに同じ指摘を繰り返しているチームほど効果が出やすく、「どの観点で見たのか」を言語化しやすいのも強みです。
設計・影響調査担当
実装前に「どのファイルに影響するか」「依存関係は何か」「どんなリスクがあるか」を毎回洗い出すチームなら、Feature Planner 系が向いています。公式例でも、要件の整理、影響ファイルの特定、タスク分解、依存関係やリスクの明示が planning agent の役割として示されています。
UI・デザインシステム担当
デザインシステムやアクセシビリティのルールがあるなら、Design System 系も有効です。標準コンポーネントの利用、spacing、レイアウト、ARIA などを観点に固定できるため、フロントエンドのレビュー負荷を下げやすくなります。MCP でコンポーネントライブラリや社内ガイドをつなげられると、repo の外の正解まで参照しやすくなります。
最初から「何でもできるフルスタック AI」を作ろうとしないことも大切です。custom agent の価値は万能化ではなく、守備範囲を狭くして再現性を上げることにあります。
Visual Studio で custom agent を作る最小手順
前提を確認する
custom agents は Microsoft Learn では Visual Studio 2026 version 18.4 以降が要件とされており、利用には GitHub Copilot の契約が必要です。agent mode 自体は Visual Studio 2022 17.14 以降で利用でき、Ask mode と違って計画、コード編集、コマンド実行、ツール呼び出しを繰り返します。MCP を使うなら agent mode を選ぶ必要があります。なお、現時点の Learn では agent picker は Visual Studio 2026 Insiders build で案内されており、呼び出しは @ 構文でも可能です。
.github/agents/ に .agent.md を置く
custom agent は、repo の .github/agents/ フォルダに .agent.md として定義します。ここがズレると認識されないので、まずは配置場所を正しく揃えることが第一歩です。
frontmatter は最小限から始める
公式テンプレートでは name、description、model、tools が使えます。model を省略すると model picker の選択が使われ、tools を省略すると利用可能なツールがすべて有効になります。最初は name、description、tools だけで十分です。
---
name: Code Reviewer
description: C# API の変更をチーム基準でレビューする
tools: ["code_search", "readfile", "find_references"]
---
あなたはこのリポジトリ専用のコードレビュー担当です。
必ず次の順で確認してください。
1. 命名規約が既存コードと一致しているか
2. 例外処理とログ出力が不足していないか
3. public メソッドに対するテストが追加されているか
4. 既存の実装パターンを壊していないか
出力は「問題点」「影響」「修正案」「追加で必要なテスト」に分けてください。ポイントは、人格設定を長く書くことではありません。見る観点、出力形式、やってはいけないことを短く固定する方が、チーム内でぶれにくくなります。
ツールは絞って許可する
公式ドキュメントでも、ツール名は GitHub Copilot のプラットフォームごとに異なるため、Visual Studio の Chat で Tools アイコンを開いて確認するよう案内されています。最初は code_search、readfile、find_references のような読み取り中心から始め、実績が出たら編集やターミナル実行を追加する方が安全です。
実案件で評価する
試すときは、サンプル repo ではなく実案件の小さなタスクで評価した方が向き不向きが見えます。レビュー agent なら「指摘の抜け漏れが減ったか」、planning agent なら「影響調査の時間が短くなったか」のように、開発フローの改善で見た方が判断しやすくなります。
agent skills と find_symbol をどう実務に当てはめるか
skills は、repo やユーザープロファイル配下に置いた SKILL.md を Visual Studio が自動検出して使う仕組みです。skill が有効になるとチャット上に表示されるため、どの手順が働いたかも追いやすくなります。find_symbol は、参照箇所の探索だけでなく型情報、宣言、スコープまで扱えるので、skills と組み合わせると「調べる → 直す → 検証する」の流れを安定させやすくなります。
横断リファクタリングで使う
メソッド名の変更、引数追加、呼び出し側の一括修正のような作業では、find_symbol が特に効きます。Microsoft Learn では find_symbol の対応言語として C++、C#、Razor、TypeScript などが案内されており、サポートされた LSP 拡張がある言語にも広がります。さらに、明確なプロンプトと tool-calling をサポートするモデルの利用が推奨されているため、「このシンボルの参照箇所を洗い出し、修正が必要な call site を提案して」のように、シンボル単位で依頼した方が精度を出しやすくなります。
PR前の確認を定型化する
たとえば .github/skills/pr-review-checklist/ にレビュー手順を置き、Code Reviewer agent からそれを使う構成にすると、毎回同じチェック観点を自然に再利用できます。そこに MCP で社内 style guide や ADR をつなげれば、「このチームでは何が正解か」を repo 外からも引けるようになります。公式の custom agent 例でも、レビュー観点やデザインルールを明示したエージェント設計が紹介されています。
実装前の影響調査を早くする
Feature Planner 系の custom agent に、影響ファイルの特定、依存関係の確認、リスク列挙、タスク分解を担当させると、実装前の会話が散らばりにくくなります。Visual Studio の agent mode 自体も、高レベルな要求から計画、コード編集、コマンド実行、ツール呼び出しを繰り返す設計なので、「設計役」と「実装役」を分けた方が会話ログの意味がはっきりします。
導入で失敗しやすいポイント
- 1つの agent に何でもやらせようとする
レビュー、設計、実装、調査を1体にまとめると、出力基準がぶれます。1 agent 1役割で切る方が再現性が出ます。 - 全社ルールまで agent 本体に書き込む
命名規約やコメント方針のような横断ルールは instructions に置き、agent には役割固有の判断だけを書いた方が保守しやすくなります。 - ターミナル実行を軽く見ない
agent mode では、terminal command は Visual Studio プロセスと同等の権限で動きます。提案されたコマンドは都度レビューし、最初は読み取り中心のツールだけで運用する方が安全です。 find_symbolなしで横断変更を任せる
単なるテキスト検索前提だと、オーバーロードや型文脈をまたぐ変更で抜けが出やすくなります。シンボル単位の変更はfind_symbolを前提にした方が安定します。- 戻し方を考えず一気に適用する
Visual Studio の agent mode では checkpoint 単位の Restore はありますが、現時点では stepwise undo/redo は未対応です。大きい変更は区切って Keep / Undo した方が安全です。 - MCP の接続先を広げすぎる
組織では GitHub の allowlist ポリシーで許可された MCP server だけが使える構成もあります。まずは読み取り専用の社内ドキュメントや設計資料から始め、必要性が見えたら接続先を増やす方が現実的です。
まず何から始めるか
- まずは custom instructions を使える状態にし、
.github/copilot-instructions.mdを作るか、/generateInstructionsで叩き台を作ります。Visual Studio では custom instructions や agent mode の利用を Options から有効化する手順も案内されているため、機能が見えない場合はそこを先に確認します。内容は命名規約、例外処理、テスト方針の3〜5項目だけで十分です。 - 次に
.github/agents/に review 用か planning 用の.agent.mdを1つだけ追加し、実案件で試します。評価は「レビュー差し戻しが減ったか」「影響調査が早くなったか」のように、業務の改善で見ます。最初から複数 agent を並行投入するより、1つに絞った方が改善点が見えやすくなります。 - その後で、横断変更の多いテーマに
find_symbolを合わせ、必要になったら skills や MCP を足します。最初から全部乗せにせず、rules → role → workflow の順で増やした方が運用が崩れません。
Visual Studio 2026 March Update の custom agent 対応は、Copilot を「質問に答える AI」から「チームのやり方を持つ AI」へ進める更新です。built-in agent で得意分野を見極め、instructions で共通ルールを固定し、skills で定型手順を再利用し、最後に custom agent で役割を分ける。この順番で入れると、開発現場で再現性のある AI 活用に育てやすくなります。次にやることは明確で、まずは review か planning のどちらか1役に絞って、1つの custom agent を実案件で回してみることです。
コメント