Visual Studioの「Customize chat responses」は、Copilot Chatの回答をチームのコーディング規約、アーキテクチャ方針、よく使う作業手順に合わせるための仕組みです。結論から言うと、2026年4月時点で注目すべきポイントは「毎回長いプロンプトを書く」のではなく、カスタム指示・プロンプトファイル・スラッシュコマンドをリポジトリに組み込み、Copilot Chatの回答品質をチームで標準化することです。
Microsoft Learnでは、Visual StudioのCopilot Chatに適切なコンテキストを与えることで、コーディングプラクティスやプロジェクト要件に合った回答やコード生成がしやすくなると説明されています。さらに、そのコンテキストをファイルとして保存し、各チャット要求に自動的に含められる点が重要です。(Microsoft Learn)
Visual Studioの最新動向: Customize chat responsesで何が変わったか
2026年4月24日のMicrosoftDocs公式リポジトリ履歴では、copilot-chat-context.mdに対するコミットが記録されています。一方で、Microsoft Learnの公開ページ上では「Last updated」が2026年2月27日として表示されているため、4月24日の更新は「新機能が大きく追加された日」と断定するより、公式ソース側の更新履歴として扱うのが安全です。(GitHub)
実務で見るべき本質は、日付そのものよりも、Visual StudioのCopilot Chatが「その場限りの質問ツール」から「チームの開発標準を反映する作業基盤」に近づいている点です。特にdevelopers、DevOps engineers、platform teamsにとっては、個人のプロンプト力に依存せず、再利用可能な指示とプロンプトを整備する価値が高まっています。
| 見るべきポイント | 実務への影響 | 対象者 |
|---|---|---|
| カスタム指示 | コーディング規約、命名規則、レビュー観点をCopilot Chatに反映しやすくなる | 開発者、テックリード |
| プロンプトファイル | よく使う依頼をリポジトリで共有できる | 開発チーム、DevOps |
| スラッシュコマンド | /fix、/tests、/savePromptなどで作業意図を素早く伝えられる | 全開発者 |
| ユーザー設定とリポジトリ設定 | 個人の好みとチーム標準を分けて管理できる | platform teams |
| Copilot利用条件の確認 | サブスクリプションや試用版の状況がオンボーディングに影響する | 管理者、情シス、DevOps |
カスタム指示は「チームの暗黙知」をCopilot Chatに渡す仕組み
カスタム指示は、Copilot Chatへの質問にあらかじめ決めたコンテキストを自動的に追加する機能です。たとえば「C#ではpublicメンバーはPascalCaseにする」「テストはxUnitで書く」「非同期メソッド名はAsyncで終える」といったチームルールを、毎回プロンプトに書かなくても反映しやすくなります。(Microsoft Learn)
Visual Studioでは、リポジトリルートに .github/copilot-instructions.md を置くことで、チーム共通の指示を管理できます。さらに、個人用の設定は %USERPROFILE%/copilot-instructions.md に保存でき、リポジトリレベルの指示と併用できます。(Microsoft Learn)
実務では、まずリポジトリ共通の指示を短く作るのがおすすめです。最初から大量のルールを書き込むと、Copilotの回答が硬直化したり、矛盾する指示が混ざったりします。
# Repository coding guidance
- Use C# 12 style where it is already used in the project.
- Prefer dependency injection over static service access.
- Generate unit tests with xUnit.
- Keep comments concise and only add them when they clarify intent.
- Do not suggest changes that expose secrets, tokens, or connection strings.このように、指示は「してほしいこと」だけでなく「してほしくないこと」も書くと効果的です。特にDevOpsやplatform teamsでは、シークレット、接続文字列、環境依存の設定値をコード例に含めないよう明記しておくと、レビュー時の手戻りを減らせます。
.instructions.mdで言語別・領域別にルールを分ける
単一の .github/copilot-instructions.md だけでは、プロジェクトが大きくなるほど指示が肥大化します。そこで重要になるのが、.github/instructions/*.instructions.md です。
この形式では、applyTo を使って適用対象のファイルやフォルダーを指定できます。Microsoft Learnでも、言語、フレームワーク、プロジェクト種別ごとに複数の *.instructions.md ファイルを作成できると説明されています。(Microsoft Learn)
---
description: "Rules for C# application services"
applyTo: "src/Application/**/*.cs"
---
- Keep application services free from infrastructure-specific code.
- Validate input before calling domain services.
- Return clear error results instead of throwing for expected validation failures.
- Add unit tests for both successful and failure paths.判断基準はシンプルです。全員・全ファイルに適用するルールは copilot-instructions.md、特定の言語や層だけに適用するルールは *.instructions.md に分けます。
| ファイル | 向いている用途 | 例 |
|---|---|---|
.github/copilot-instructions.md | リポジトリ全体の共通方針 | 命名規則、セキュリティ方針、コメント方針 |
.github/instructions/*.instructions.md | 特定領域の詳細ルール | C#、React、API、テスト、インフラコード |
%USERPROFILE%/copilot-instructions.md | 個人の作業スタイル | 好みの説明粒度、個人のワークフロー |
注意点は、個人設定にチームルールと矛盾する内容を書かないことです。たとえばリポジトリ側で「テストはxUnit」と定めているのに、個人設定で「NUnitで生成」と書くと、回答の一貫性が落ちます。個人設定は「回答は日本語で簡潔に」「変更理由も併記する」など、チーム標準を邪魔しない内容に寄せると使いやすくなります。
プロンプトファイルは「よく使う依頼」をチーム資産にする
プロンプトファイルは、頻繁に使うプロンプトを .github/prompts フォルダーに .prompt.md として保存し、再利用できる仕組みです。Microsoft Learnでは、#参照でメソッド、クラス、ファイルなどを含めたプロンプトを作成し、.github/prompts 配下に保存して利用できると説明されています。(Microsoft Learn)
たとえば、プルリクエスト前の自己レビュー用に次のようなプロンプトを作れます。
# Review service implementation
Review the selected service implementation.
Check the following points:
- Business rules are not mixed with infrastructure concerns.
- Error handling is explicit.
- Async methods are awaited correctly.
- Unit tests cover success, failure, and boundary cases.
- No secrets or environment-specific values are included.
Return:
1. Risk summary
2. Suggested fixes
3. Test cases to addこのプロンプトを review-service.prompt.md として保存しておけば、チームメンバーは同じ観点でレビューを依頼できます。属人的な「レビューのうまい人の聞き方」をファイル化できるため、新しく参加した開発者にも展開しやすくなります。
特にグローバルチームでは、プロンプトファイルは英語で統一し、ドメイン用語だけをプロジェクトに合わせて補足するのが現実的です。日本語の業務用語が多いシステムでは、用語集を別のプロンプトや指示ファイルに分けておくと、翻訳揺れを抑えられます。
/generateInstructionsと/savePromptで初期整備が速くなる
Visual StudioのCopilot Chatでは、カスタムプロンプトを / から呼び出せます。カスタムプロンプトはIntelliSenseリスト上部に表示され、/help や /savePrompt などのシステムコマンドと区別されます。(Microsoft Learn)
特に実務で使いやすいのが、/generateInstructions と /savePrompt です。/generateInstructions はプロジェクト構造やコーディングパターンを分析し、リポジトリレベルの copilot-instructions.md を生成するコマンドです。/savePrompt は現在の会話から再利用可能なプロンプトを抽出し、.github/prompts/[name].prompt.md に保存します。(Microsoft Learn)
ただし、生成された指示をそのまま採用するのは避けるべきです。最初のドラフトとしては便利ですが、以下の観点で必ず人が確認します。
| 確認項目 | 見るべき理由 |
|---|---|
| 実際の規約と一致しているか | 既存コードの偶然の書き方を「ルール」と誤認する可能性がある |
| 古い実装パターンを推奨していないか | レガシーコードが多い場合、望ましくない慣習を学習しやすい |
| セキュリティ上危険な例がないか | 認証情報、接続文字列、内部URLを含めない |
| 指示が長すぎないか | 長文すぎると重要なルールが埋もれる |
| チーム全員に適用してよいか | 個人の好みをチーム標準に混ぜない |
スラッシュコマンドは「作業意図」を短く正確に伝える
スラッシュコマンドは、Copilot Chatに作業の意図を素早く伝えるためのショートカットです。Microsoft Learnでは、スラッシュコマンドを使うことで、長い質問を書かなくても一般的な開発タスクの文脈を設定できると説明されています。(Microsoft Learn)
| コマンド | 主な用途 | 使いどころ |
|---|---|---|
/explain | コード説明 | 初見のメソッド、複雑な条件分岐の理解 |
/fix | 問題修正の提案 | コンパイルエラー、例外、ロジック不備の調査 |
/tests | 単体テスト生成 | 既存メソッドのテスト追加、境界値テストの洗い出し |
/doc | コメント追加 | 公開API、複雑な処理の説明補助 |
/optimize | パフォーマンス改善 | ループ、LINQ、メモリ使用量、非同期処理の見直し |
/generateInstructions | 指示ファイル生成 | リポジトリ導入時の初期ドラフト作成 |
/savePrompt | プロンプト保存 | よく使う依頼のテンプレート化 |
Visual Studio 2022 バージョン17.13では、スラッシュコマンドを入力すると、コマンドが自然言語のプロンプトとして展開され、コマンドのコンテキストが表示されるとされています。これにより、コマンドがCopilotに何を依頼しているのかを確認しながら使いやすくなります。(Microsoft Learn)
Copilot Actionsは右クリックから使える実務向けショートカット
Copilot Actionsは、コンテキストメニューから事前構成されたプロンプトやスラッシュコマンドにアクセスする機能です。コードを選択している場合と選択していない場合で動作が変わり、たとえば「Explain」は選択コードまたはカーソル付近のコードを説明し、「Generate Tests」は選択コードまたはカーソル付近のコードに対するテスト生成に使えます。(Microsoft Learn)
実務で特に便利なのは「Optimize Selection」です。ファイル全体ではなく特定のコード片だけを対象にできるため、余計な変更を避けやすくなります。Microsoft Learnでは、Optimize Selectionがパフォーマンス、保守性、信頼性、アーキテクチャの観点で提案を行い、チャットパネルではなくインライン差分として確認・承認・拒否できると説明されています。(Microsoft Learn)
使い方のコツは、対象範囲を狭く選ぶことです。クラス全体を選ぶより、問題のあるメソッド、重いループ、例外処理が曖昧なブロックだけを選択した方が、レビューしやすい提案になりやすいです。
導入手順: まずは1リポジトリで小さく始める
Visual StudioでGitHub Copilot Chatを使うには、Visual Studio 2022 version 17.10以降と、Copilot accessを持つGitHubアカウントでのサインインが前提として示されています。また、2026年4月20日時点でGitHub Copilot Proの試用版や一部個人向け有料プランの新規サインアップに関する注意書きも掲載されているため、組織導入ではライセンス状況を事前に確認しておく必要があります。(Microsoft Learn)
導入は次の順序で進めると失敗しにくくなります。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | 対象リポジトリを1つ選ぶ | 検証範囲を限定 |
| 2 | /generateInstructionsで初期案を作る | .github/copilot-instructions.mdのドラフト |
| 3 | チームでレビューして短く整える | 承認済みの共通指示 |
| 4 | 言語別・層別に .instructions.md を分ける | 適用範囲つきの詳細指示 |
| 5 | 頻出作業を .prompt.md に保存する | レビュー、テスト、障害調査用プロンプト |
| 6 | 実際のPRや修正タスクで検証する | 改善点と不要な指示を洗い出す |
最初から全リポジトリへ横展開しないことが重要です。特に大規模組織では、プロジェクトごとに言語、アーキテクチャ、テスト方針が異なります。共通テンプレートを作る場合でも、「全社共通」「部門共通」「リポジトリ固有」の3層に分けると運用しやすくなります。
DevOps engineersとplatform teamsが決めておきたい運用ルール
Copilot Chatの応答カスタマイズは、単なる個人の生産性向上策ではありません。リポジトリに指示ファイルやプロンプトファイルを置く場合、それらは開発プロセスに影響する「軽量なポリシー」として扱うべきです。
Platform teamsは、少なくとも次のルールを決めておくと運用が安定します。
| ルール | 理由 |
|---|---|
| 指示ファイルはコードレビュー対象にする | 誤った規約や危険な指示の混入を防ぐ |
| セキュリティ禁止事項を明記する | 秘密情報や内部設定の出力を避ける |
| プロンプトファイルの命名規則を決める | /入力時に選びやすくする |
| 個人設定とチーム設定の役割を分ける | 矛盾した指示を減らす |
| 定期的に不要な指示を削除する | 古い設計方針を残さない |
たとえば、.github/prompts/security-review.prompt.md、.github/prompts/add-unit-tests.prompt.md、.github/prompts/ci-failure-triage.prompt.md のように用途が分かる名前にしておくと、開発者が迷わず使えます。
失敗しやすいポイントと対策
Customize chat responsesを導入しても、指示の書き方が悪いと期待した効果は出ません。特に多い失敗は、指示を増やしすぎることです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 指示ファイルに長文の設計資料を貼る | 重要なルールが埋もれる | 10〜20行程度の要点から始める |
applyTo が広すぎる | 関係ないファイルにも指示が効く | src/**/*.csより具体的に絞る |
| 個人設定でチーム標準を上書きする | 回答が人によって変わる | 個人設定は説明粒度や言語設定に限定 |
| 生成された指示を未レビューで採用する | 古い実装パターンが標準化される | テックリードがレビューする |
| プロンプトファイルが増えすぎる | 選びにくくなる | 月1回など定期的に棚卸しする |
| Copilotの提案をそのまま反映する | 仕様漏れやテスト不足が残る | 差分確認、テスト、レビューを必須にする |
特にセキュリティ関連では、「Copilotが提案したから安全」と考えないことが大切です。認証、認可、暗号化、ログ出力、個人情報の扱いは、必ず人間のレビューと既存のセキュリティ基準に照らして確認します。
どのチームが今すぐ使うべきか
すぐに効果が出やすいのは、次のようなチームです。
| チームの状況 | 期待できる効果 |
|---|---|
| コーディング規約があるが守られにくい | Copilotの提案段階で規約に寄せやすい |
| レビュー観点が人によってばらつく | 共通プロンプトでレビュー観点をそろえられる |
| 新人や外部メンバーのオンボーディングが多い | 暗黙知を指示ファイルに落とし込める |
| テスト追加やリファクタリングが後回しになりがち | /testsや/optimizeを作業導線に組み込める |
| グローバル開発で説明の粒度が揺れる | 英語の共通プロンプトで依頼内容を標準化できる |
一方で、まだコーディング規約やレビュー方針が固まっていないチームは、先に最低限の基準を作る必要があります。曖昧なルールをCopilotに渡しても、曖昧な回答が返りやすくなるだけです。
まず何から始めるべきか
最初の一歩は、.github/copilot-instructions.md にリポジトリ共通のルールを5〜10個だけ書くことです。次に、レビュー、単体テスト生成、CI失敗調査など、頻繁に使う作業を .github/prompts/*.prompt.md として保存します。最後に、C#、フロントエンド、インフラコードなど、領域ごとの細かいルールを .github/instructions/*.instructions.md に分けていきます。
Visual StudioのCustomize chat responsesは、Copilot Chatを「便利な質問相手」から「チーム標準に沿って動く開発支援ツール」へ近づける機能です。2026年4月時点では、更新日だけを追うよりも、カスタム指示、プロンプトファイル、スラッシュコマンドをどのように開発プロセスへ組み込むかが重要です。まずは1リポジトリで小さく試し、効果が確認できた指示とプロンプトだけをチーム標準として横展開しましょう。
コメント