Visual StudioでGitHub Copilotを利用する組織では、開発者ごとに共通ルールを設定する手間が課題になりがちです。Visual Studio 2026 July Updateでは、GitHub Copilot BusinessまたはEnterpriseの組織単位のカスタム指示に対応しました。
対象のGitHub組織が所有するリポジトリをVisual Studioで開くと、組織のカスタム指示がCopilotに自動適用されます。適用された指示はCopilot Chatの参照一覧から確認でき、必要な場合はVisual Studioの設定でローカルに無効化できます。(The GitHub Blog)
Visual Studio 2026 July Updateで何が変わったのか
GitHubは2026年7月30日、Visual Studio向けGitHub CopilotのJuly Updateとして、organization-level custom instructionsへの対応を発表しました。Microsoft Learnのリリースノートでは、この機能がVisual Studio 2026 July Update 18.8.0に含まれることが案内されています。18.8.0は2026年7月14日にリリースされました。(The GitHub Blog)
主な変更点は次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象製品 | Visual Studio 2026 July Update |
| 対象プラン | GitHub Copilot Business、GitHub Copilot Enterprise |
| 設定者 | GitHub Organizationのオーナー |
| 適用対象 | 対象組織が所有するリポジトリ |
| 適用方法 | Visual Studioで対象リポジトリを開くと自動適用 |
| 確認方法 | Copilot Chatの参照一覧に表示 |
| ローカル無効化 | Visual StudioのCopilot Chat設定から変更可能 |
これまでもリポジトリ内の.github/copilot-instructions.mdなどを使ってプロジェクト単位の指示を共有できました。しかし、全社共通の回答言語やセキュリティ上の基本方針を多数のリポジトリへ個別に設定すると、内容の重複や更新漏れが発生します。
組織単位のカスタム指示を使えば、全リポジトリに共通する方針をGitHub Organization側で一元管理できます。
Visual Studioで組織のCopilotカスタム指示が自動適用される条件
組織のカスタム指示は、すべてのVisual Studio利用環境へ無条件に適用されるわけではありません。少なくとも次の条件を確認する必要があります。(The GitHub Blog)
| 条件 | 確認するポイント |
|---|---|
| Visual Studioが対応バージョンである | Visual Studio 2026 July Update 18.8.0以降へ更新する |
| 対象プランを契約している | Copilot BusinessまたはCopilot Enterpriseである |
| 組織側に指示が登録されている | OrganizationオーナーがGitHubの設定画面で保存している |
| リポジトリが組織所有である | 個人アカウントではなく対象Organizationが所有している |
| Copilotを利用できる状態である | Visual Studioで適切なGitHubアカウントへサインインしている |
| ローカル設定が無効になっていない | 組織レベルのカスタム指示を有効にしている |
最も重要なのはリポジトリの所有者
公式リリースノートでは、リポジトリがGitHub Organizationに属していることが利用条件として明記されています。単にOrganizationのメンバーであるだけではなく、Visual Studioで作業しているリポジトリ自体が対象組織に属している必要があります。(Microsoft Learn)
例えば、次のリポジトリでは挙動が異なる可能性があります。
| 開いているリポジトリ | 組織指示の扱い |
|---|---|
company/example-api | companyが対象組織なら自動適用の対象 |
user/example-api | 個人所有のため原則として対象外 |
| 組織リポジトリを個人アカウントへforkしたもの | 個人所有になるため、参照一覧での確認が必要 |
| GitHub以外にのみ存在するリポジトリ | GitHub Organizationの所有条件を満たさない |
個人forkで開発している場合は、元のupstreamリポジトリが組織所有であっても、自動適用されると決めつけないほうが安全です。Copilot Chatの参照一覧を開き、実際に組織の指示が読み込まれているか確認してください。
GitHub Organizationにカスタム指示を設定する手順
組織単位のカスタム指示は、Visual Studio側ではなくGitHub Organizationの設定画面で登録します。設定できるのはOrganizationオーナーです。(GitHub Docs)
- GitHubにサインインします。
- 画面右上のプロフィール画像を選択します。
Organizationsを開きます。- 対象のOrganizationを選択します。
- Organizationの
Settingsを開きます。 - 左側メニューから
Copilotを選択します。 Custom instructionsを開きます。Preferences and instructionsへ指示を入力します。Save changesを選択します。
保存した指示は、変更または削除するまで有効です。指示は自然言語で記述でき、1行ずつ分ける方法、段落でまとめる方法のいずれも利用できます。(GitHub Docs)
組織レベルに適したカスタム指示の例
組織単位では、特定リポジトリだけに依存しない共通ルールを設定します。
- 原則として日本語で回答する。
- 既存コードで使用されている設計パターンとライブラリを優先する。
- 新しい依存関係を提案する場合は、追加する理由と影響を説明する。
- セキュリティに関係する変更では、認証、認可、入力検証、ログへの影響を確認する。
- 不明な社内APIや仕様を推測で補完せず、不明な前提を明示する。
- コード変更を提案するときは、関連するビルド方法とテスト方法も示す。「安全なコードを書く」「品質を高くする」のような抽象的な表現だけでは、回答が安定しません。Copilotが判断できる行動として、短く具体的に記述することが重要です。
また、APIキー、アクセストークン、パスワード、個人情報などはカスタム指示に記載しないでください。カスタム指示はCopilotへのリクエストに追加される情報として扱われます。(GitHub Docs)
Visual Studioでカスタム指示の適用を確認する方法
組織側で保存しただけでは、開発者が「本当にVisual Studioで適用されているか」を判断できません。次の手順で確認します。
- Visual Studioを対応バージョンへ更新します。
- 対象Organizationが所有するリポジトリを開きます。
- GitHub Copilot Chatを開きます。
- リポジトリに関係する質問を送信します。
- 回答に表示される参照一覧を展開します。
- Organizationのカスタム指示が含まれているか確認します。
- 表示されたリンクを選択し、指示の全文を確認します。
Visual Studioでは、適用された組織指示がCopilotの参照一覧に表示され、リンクから全文を確認できます。回答内容だけで適用有無を推測するのではなく、参照一覧を見る方法が確実です。(The GitHub Blog)
動作確認に使える質問例
次のような質問を送ると、組織指示が回答へ反映されているか確認しやすくなります。
このリポジトリに新しいAPIエンドポイントを追加するときの
実装方針、セキュリティ上の確認事項、テスト手順を整理してください。組織指示で「日本語で回答する」「セキュリティへの影響を確認する」「テスト方法を示す」と設定していれば、回答にも反映される可能性があります。
ただし、生成AIの出力には非決定性があり、カスタム指示が毎回まったく同じ形で守られるとは限りません。回答内容によるテストだけでなく、参照一覧での読み込み確認も併用してください。(GitHub Docs)
Visual Studioで組織のカスタム指示を無効化する方法
組織のカスタム指示を一時的に使いたくない場合は、Visual Studio側でローカルに無効化できます。
- Visual Studioの
Toolsを開きます。 Optionsを選択します。GitHubを開きます。Copilotを選択します。Copilot Chatを開きます。Enable organization-level custom instructionsのチェックを外します。
設定場所は次のとおりです。
Tools
└─ Options
└─ GitHub
└─ Copilot
└─ Copilot Chat
└─ Enable organization-level custom instructionsこの操作は、そのVisual Studio環境で組織指示を使用しないための設定です。GitHub Organizationに保存されている指示自体を削除するものではありません。(The GitHub Blog)
無効化を検討する場面
組織のカスタム指示は、通常は有効にしたまま利用するのが基本です。ただし、次のような場面では一時的な無効化が役立ちます。
- ユーザー単位やリポジトリ単位の指示と矛盾している
- Copilotの回答が組織指示によって変化しているか切り分けたい
- カスタム指示を適用しない状態との比較テストを行いたい
- 組織指示の変更前後で回答品質を検証したい
無効化した場合は、検証後に設定を戻し忘れないようにします。組織で運用する場合は、無効化の目的と検証期間を記録しておくと管理しやすくなります。
組織・リポジトリ・ユーザーの指示を使い分ける
カスタム指示を有効活用するには、すべてのルールを組織単位へ集約しないことが重要です。適用範囲に応じて役割を分けます。
| 指示の範囲 | 適している内容 | 避けたい内容 |
|---|---|---|
| 組織単位 | 共通言語、セキュリティ確認、依存関係の基本方針、社内窓口 | 特定プロジェクトだけのフレームワークやフォルダ構成 |
| リポジトリ単位 | 使用技術、ビルドコマンド、テスト方法、命名規則、アーキテクチャ | 他のリポジトリでは成立しない内容の全社適用 |
| ユーザー・ローカル単位 | 説明の詳しさ、個人の回答形式、作業時の一時的な設定 | チーム全員が守る必要のある開発ルール |
例えば、「回答は原則として日本語にする」は組織単位に向いています。一方、「このリポジトリでは.NET 10とxUnitを使用し、テストはdotnet testで実行する」はリポジトリ単位に配置するのが適切です。
GitHub Docsでは、一般的なカスタム指示の優先順位として、個人、リポジトリ、組織の順が示されています。ただし、関係する複数の指示はCopilotへ渡されるため、優先順位だけを頼りに矛盾した内容を放置するべきではありません。Visual Studioのリリースノートでも、ユーザーレベルの指示との競合を避けるため、組織指示を無効化できることが案内されています。(GitHub Docs)
カスタム指示はポリシーを強制する仕組みではない
組織単位で設定できるため、カスタム指示をセキュリティポリシーやコーディング規約の強制機能として扱いたくなります。しかし、Microsoftのリリースノートでは、カスタム指示は設定や好みを伝えるためのものであり、ポリシーの強制には適さないと説明されています。(Microsoft Learn)
例えば、次の指示を登録しても、必ず守られるとは限りません。
外部入力を受け取るコードでは、必ず入力値を検証する。これはCopilotの回答品質を高めるためには有効ですが、入力検証の実装を保証する仕組みではありません。
確実な遵守が必要なルールは、次のような仕組みで別途担保します。
- コンパイラやリンターによる検査
- 単体テストや統合テスト
- CIでの自動チェック
- 静的解析やセキュリティスキャン
- コードレビュー
- リポジトリルールやマージ条件
- 必須レビュアーや承認フロー
カスタム指示は「Copilotへ最初から期待する方向を伝える仕組み」、CIやレビューは「生成された結果を検証する仕組み」と考えると整理しやすくなります。
組織単位のカスタム指示で失敗しやすいポイント
特定リポジトリの情報を組織指示へ書きすぎる
「すべてのプロジェクトでReactを使う」「必ずSQL Serverへ保存する」など、実際には一部のリポジトリにしか当てはまらない指示を組織単位へ登録すると、他のプロジェクトで不適切な回答が増えます。
組織レベルには、どのリポジトリでも成立する原則だけを置きます。
指示が長すぎて重要点が埋もれる
GitHub Docsでは、短く自己完結した指示が効果的とされています。長い社内規程をそのまま貼り付けるのではなく、Copilotが判断に利用できる内容へ分解してください。(GitHub Docs)
悪い例は次のような指示です。
高品質で、安全で、分かりやすく、保守性が高く、
会社のあらゆるルールに準拠したコードを作成する。改善例は次のとおりです。
- 新しい外部依存関係を追加する場合は、追加理由を説明する。
- 外部入力を扱うコードでは、入力検証の方法を示す。
- 認証処理を変更する場合は、認可への影響も確認する。
- コード変更時は、関連するテスト方法を示す。適用されたと思い込んで参照一覧を確認しない
回答が日本語だった、コードスタイルが似ていたというだけでは、組織指示が適用された証拠にはなりません。モデルが偶然同じ形式で回答した可能性があります。
導入時や設定変更後は、Copilot Chatの参照一覧を必ず確認します。
リポジトリ所有者を確認していない
Organizationのメンバーが作業していても、リポジトリが個人所有なら組織指示の適用条件を満たしません。Git remoteのURLやGitHub上の所有者を確認してください。
GitHub Docsの記載だけで対応状況を判断する
2026年8月時点では、GitHub Docsの一部ページに、組織指示の対応先をGitHub.com上の機能に限定する古い注記が残っています。一方、Visual Studio 2026 July Updateのリリースノートと2026年7月30日のGitHub Changelogでは、Visual Studioでの対応が明記されています。対応状況を確認するときは、Visual Studioの最新リリースノートとGitHub Changelogも併せて確認する必要があります。(GitHub Docs)
導入前に確認したいチェックリスト
- [ ] GitHub Copilot BusinessまたはEnterpriseを利用している
- [ ] 設定担当者がGitHub Organizationのオーナーである
- [ ] Visual StudioをJuly Update 18.8.0以降へ更新した
- [ ] 対象リポジトリがOrganization所有である
- [ ] 組織指示を短く具体的な内容に整理した
- [ ] リポジトリ固有のルールを組織指示へ混在させていない
- [ ] Copilot Chatの参照一覧で適用を確認した
- [ ] ユーザー単位やリポジトリ単位の指示と矛盾していない
- [ ] 強制が必要なルールをCIやレビューでも検査している
- [ ] ローカルで無効化する設定場所をチームへ共有した
Visual Studioで組織のCopilotカスタム指示を活用するポイント
Visual Studio 2026 July Updateでは、GitHub Copilot BusinessまたはEnterpriseを利用するOrganizationが設定したカスタム指示を、組織所有リポジトリで自動適用できるようになりました。
管理者はGitHubのSettingsから組織共通の指示を登録し、開発者はVisual StudioのCopilot Chatに表示される参照一覧から適用状況を確認します。競合や動作確認のために無効化する場合は、Tools > Options > GitHub > Copilot > Copilot Chatを使用します。
導入時は、まず回答言語、セキュリティ確認、既存設計の優先、テスト提示といった少数の共通ルールから始めるのが現実的です。対象リポジトリで参照一覧と回答内容を検証し、リポジトリ固有の情報は.github/copilot-instructions.mdへ分離したうえで、適用範囲を段階的に広げてください。
コメント