Enterprise-managed plugins in VS Codeは、Visual Studio Codeで使うAIエージェント関連のプラグインを、企業管理者が一元的に配布・制御できるようにする公開プレビュー機能です。結論から言うと、開発者が各自でプラグインを探して入れる運用から、管理者が標準プラグイン、マーケットプレイス、MCP設定、フックなどを定義し、VS CodeとCopilot CLIの両方へ展開する運用に近づきます。
特に影響が大きいのは、GitHub Copilot BusinessまたはGitHub Copilot Enterpriseを利用し、VS CodeやCopilot CLIでエージェント機能を活用している組織です。管理者は.github-privateリポジトリ内の設定ファイルを確認し、開発者はVS Codeのバージョン、認証先、インストール済みプラグインの挙動を確認する必要があります。
Enterprise-managed plugins in VS Codeとは
Enterprise-managed plugins in VS Codeは、企業がGitHub Copilot向けのプラグイン標準を管理するための仕組みです。GitHubは2026年6月5日付のGitHub Changelogで、VS Code 1.122がこのエンタープライズ管理機能に対応したと案内しています。公式情報の要点は、管理者が設定した企業標準が、Copilot CLIだけでなくVS Codeクライアントにも適用されるようになった点です。(The GitHub Blog)
ここでいうプラグインは、従来のVS Code拡張機能そのものではありません。VS CodeのAgent pluginsは、チャット内で使えるスラッシュコマンド、Agent Skills、Custom Agents、Hooks、MCP serversなどをまとめて配布できる、AIエージェント向けのカスタマイズ単位です。(Visual Studio Code)
たとえば、社内標準のテスト実行手順、レビュー観点、MCP経由で接続する社内ツール、コード生成前後に走らせる検証フックなどを、プラグインとしてチーム全体に配布するイメージです。
今回の変更点：VS Codeでも企業管理プラグインを受け取れる
今回の変更で押さえるべきポイントは、Copilot CLI向けに先行して提供されていた企業管理プラグインの仕組みが、VS Codeにも広がったことです。
| 項目 | これまで | 今回の公開プレビューでの変更 |
|---|---|---|
| 対象クライアント | 主にCopilot CLI | VS Code 1.122以降にも適用 |
| 管理単位 | 企業のCopilot利用者向け設定 | Copilot CLIとVS Codeの両方で共通化 |
| 配布対象 | プラグイン、マーケットプレイスなど | VS Code上のAgent pluginsにも反映 |
| 設定場所 | .github-private配下の設定ファイル | 同じ設定ファイルをVS Code側も取得・適用 |
| 主な効果 | CLI利用者の標準化 | IDE利用者を含む開発環境全体の標準化 |
管理者は、企業の.github-privateリポジトリにある.github/copilot/settings.jsonで、利用可能なプラグインマーケットプレイスや自動インストールするプラグインを定義できます。設定がコミットされると、対応クライアントでCopilotに認証したユーザーに対して反映されます。(GitHub Docs)
対象者と影響範囲
対象になる組織
影響を受ける可能性が高いのは、次の条件に当てはまる組織です。
- GitHub Copilot BusinessまたはGitHub Copilot Enterpriseを利用している
- VS CodeでGitHub Copilotやエージェント機能を使っている
- Copilot CLIをすでに試験導入している
- 社内標準のAIエージェント、MCPサーバー、フック、スキルを配布したい
- 開発者ごとの設定ばらつきを減らしたい
GitHub Docsでは、Enterprise-managed plugin standardsは企業のCopilotプラン上のユーザーに適用され、Copilot CLIとVS Code 1.122以降が対象とされています。対応クライアントへ更新していないユーザーには標準が適用されない点に注意が必要です。(GitHub Docs)
管理者への影響
管理者にとっての最大の変化は、VS Code上のAIエージェント拡張を「利用者任せ」ではなく「企業標準」として扱えることです。
たとえば、次のような運用が現実的になります。
- 新入社員や外部委託メンバーに、社内標準の開発支援プラグインを自動配布する
- 特定プロジェクトで使うMCPサーバーやAgent Skillを、手順書ではなく設定として展開する
- 危険なフックや未確認のマーケットプレイス利用を抑制する
- プラグイン設定をPull Requestでレビューし、変更履歴を残す
特に大規模組織では、「便利そうだから各自で入れる」状態が、セキュリティ・監査・再現性の面で問題になりがちです。今回の機能は、AIエージェントの利用を広げる前に、配布元と初期設定を管理下に置くための土台と考えると分かりやすいです。
開発者への影響
開発者側では、VS Codeにサインインしたときに、企業が指定したプラグインマーケットプレイスや自動インストール対象プラグインが反映される可能性があります。
便利になる一方で、次のような変化も起こり得ます。
- 自分で入れていないプラグインが利用可能になる
- チャット内に新しいスラッシュコマンド、スキル、エージェントが表示される
- プラグインに含まれるMCPサーバーやフックが有効になる
- 企業管理下の設定により、一部の設定を個人で変更できない場合がある
VS CodeのAgent pluginsは、フックやMCPサーバーを含められるため、単なる補助コマンド集ではありません。公式ドキュメントでも、プラグインにはローカルマシン上でコードを実行するフックやMCPサーバーが含まれる場合があるため、内容と発行元を確認するよう注意喚起されています。(Visual Studio Code)
管理者が確認すべき設定
.github-private/.github/copilot/settings.jsonの有無
Enterprise-managed pluginsの設定は、企業の.github-privateリポジトリ内にある.github/copilot/settings.jsonで管理します。GitHub Docsでは、設定できる主なトップレベルプロパティとしてextraKnownMarketplacesとenabledPluginsが示されています。(GitHub Docs)
基本形は次のような構造です。
{
"extraKnownMarketplaces": {
"company-tools": {
"source": {
"source": "github",
"repo": "your-org/plugin-marketplace"
}
}
},
"enabledPlugins": {
"code-reviewer@company-tools": true
}
}extraKnownMarketplacesでは、ユーザーが参照できる追加のプラグインマーケットプレイスを定義します。enabledPluginsでは、企業ユーザーに自動的に有効化するプラグインを指定します。
設定項目の意味
| 設定項目 | 役割 | 確認ポイント |
|---|---|---|
extraKnownMarketplaces | 追加のプラグインマーケットプレイスを定義 | リポジトリの所有者、公開範囲、保守責任者を確認する |
enabledPlugins | 自動インストールまたは自動有効化するプラグインを指定 | 対象プラグインが全社配布に適しているか確認する |
PLUGIN-NAME@MARKETPLACE-NAME | プラグイン名とマーケットプレイス名の組み合わせ | 名前の誤記、マーケットプレイス名との不一致に注意する |
.github-private | 企業標準設定を置くリポジトリ | 権限管理、レビュー必須化、変更履歴の監査を整える |
運用上は、いきなり全社標準として設定するより、検証用マーケットプレイスと少数の自動有効化プラグインから始める方が安全です。特にMCPサーバーやフックを含むプラグインは、ローカル環境・ネットワーク・認証情報への影響を事前に確認する必要があります。
展開前に確認したい実務チェックリスト
Enterprise-managed plugins in VS Codeを試す前に、管理者は次の観点で確認しておくと失敗を減らせます。
| 確認項目 | なぜ重要か | 推奨アクション |
|---|---|---|
| VS Codeのバージョン | VS Code 1.122以降が対象 | 対象ユーザーのVS Code更新状況を確認する |
| Copilotライセンス | 企業のCopilotプランに紐づくユーザーが対象 | ユーザーのライセンス付与元を確認する |
| 認証先 | 複数の課金元があると意図した企業設定が適用されない場合がある | Copilot設定の課金先選択を確認する |
| プラグイン内容 | フックやMCPサーバーは実行影響が大きい | ソース、コマンド、通信先、権限をレビューする |
| マーケットプレイス | 追加元が信頼できないとサプライチェーンリスクになる | 社内管理リポジトリまたは信頼済みリポジトリに限定する |
| ロールバック方法 | プレビュー機能は仕様変更の可能性がある | 設定変更をPull Request化し、戻せる状態にする |
| 開発者への周知 | 自動で機能が増えると混乱しやすい | 何が追加されるか、どこで確認するかを案内する |
GitHub Docsでは、この機能は公開プレビューであり、変更される可能性があると明記されています。正式運用前提で強く依存するより、検証・段階展開・変更追跡をセットにした導入が現実的です。(GitHub Docs)
開発者が確認すべきポイント
VS Code 1.122以降に更新されているか
Enterprise-managed plugin standardsは、VS Codeではバージョン1.122以降が対象です。GitHubの案内でも、VS Code 1.122がこの企業管理機能をサポートすると説明されています。(The GitHub Blog)
開発者は、まずVS Codeのバージョンを確認しましょう。古いバージョンを使っている場合、企業が設定したプラグイン標準が反映されず、「自分だけ表示されない」「チームメンバーと使えるコマンドが違う」といったトラブルにつながります。
Agent Pluginsビューで状態を確認する
VS Codeでは、Extensionsビューで@agentPluginsを検索すると、利用可能なAgent pluginsを確認できます。また、インストール済みプラグインはAgent PluginsのInstalledビューなどから確認できます。(Visual Studio Code)
確認すべき点は次の3つです。
- 見覚えのないプラグインが追加されていないか
- 企業標準として案内されたプラグインが表示されているか
- プラグインを無効化した場合、必要なスキルやMCPサーバーが使えなくならないか
なお、プラグインを無効化すると、そのプラグインが提供するスキル、エージェント、フック、MCPサーバー、スラッシュコマンドは利用できなくなります。(Visual Studio Code)
Copilot CLIとVS Codeで同じ前提になっているか
今回のポイントは、Copilot CLIとVS Codeの標準化です。CLIでは使えるのにVS Codeでは使えない、またはその逆が起きる場合は、次の点を確認します。
- VS Codeが1.122以降か
- Copilot CLI側のバージョンや認証状態が最新か
- GitHubアカウントが企業のCopilotプランに紐づいているか
- 複数のCopilot課金元がある場合、正しい企業が選ばれているか
- 企業管理者が
.github-privateに設定をコミット済みか
GitHub Docsでは、設定が見えない場合、対象ユーザーが企業またはその組織を通じてCopilotアクセスを受けているか、複数の課金元がある場合は個人のCopilot設定で正しい「Usage billed to」を選択しているか確認するよう案内されています。(GitHub Docs)
プラグインに含まれる機能とリスクを理解する
Enterprise-managed pluginsを安全に使うには、「何を配るのか」を管理者と開発者の両方が理解する必要があります。
VS CodeのAgent pluginsは、次のような要素をまとめられます。
| 要素 | できること | 注意点 |
|---|---|---|
| Slash commands | チャットで/から呼び出せるコマンドを追加 | コマンド名が増えすぎると利用者が迷う |
| Agent Skills | 特定作業向けの手順、スクリプト、資料をオンデマンドで読み込む | 古い手順が配布され続けないよう保守が必要 |
| Custom Agents | 特定ロールやツール構成を持つエージェントを追加 | 権限や利用ツールの範囲を明確にする |
| Hooks | エージェントのライフサイクルに合わせてシェルコマンドを実行 | ローカル実行・ファイル変更・外部通信に注意 |
| MCP servers | 外部ツールやデータソースをエージェントに接続 | 認証情報、通信先、データアクセス権限を確認 |
特に重要なのは、HooksとMCP serversです。これらは開発者のローカル環境や外部サービスと連携するため、便利さとリスクが表裏一体です。
たとえば、社内のテスト結果ダッシュボードへ接続するMCPサーバーは便利ですが、アクセス権限の設計が甘いと、本来見せるべきでないプロジェクト情報まで参照できる可能性があります。コード整形フックも便利ですが、意図しないタイミングでファイルを書き換えると、開発者が原因を追いにくくなります。
移行・展開時に失敗しやすいポイント
既存の個人設定と企業設定が混在する
開発者がすでに個人でAgent pluginsやCopilot CLIプラグインを入れている場合、企業管理で追加されたプラグインと並存します。その結果、似た名前のスキルやコマンドが重複し、「どれを使えばよいか分からない」状態になることがあります。
展開前に、社内標準プラグインの命名ルールを決めておきましょう。たとえば、社内向けはcompany-やプロジェクト略称を付けるなど、利用者が見分けやすい名前にするのが実務的です。
プラグイン名の形式ミスで読み込まれない
VS Codeのドキュメントでは、plugin.jsonのnameは小文字、数字、ハイフンのみのkebab-caseで、スラッシュやコロン、名前空間プレフィックスは使えないと説明されています。無効な名前は、プラグインが静かに読み込まれない原因になります。(Visual Studio Code)
たとえば、次のような名前は避けるべきです。
{
"name": "myorg/code-reviewer"
}代わりに、次のような形式にします。
{
"name": "myorg-code-reviewer"
}読み込まれない場合は、まずplugin.jsonの配置場所、nameの形式、スキル名のYAML frontmatter、マーケットプレイス側の定義を確認しましょう。
フックが想定より広く実行される
VS Codeのプラグインフックは、ワークスペースやユーザーレベルのフックと並行して動作します。複数のPreToolUseフックがある場合、最も制限の強い判断が優先されます。(Visual Studio Code)
そのため、企業標準プラグインで厳しいフックを追加すると、既存の開発ワークフローが突然止まる場合があります。導入時は、いきなりdenyを多用するのではなく、ログ取得や警告から始め、影響範囲を確認してから制限を強める方が安全です。
更新タイミングを管理していない
VS CodeのAgent pluginsは、拡張機能の更新確認やextensions.autoUpdateの状態に応じて更新確認されます。ただし、npmやPyPI由来のプラグインは自動更新されず、更新ボタンを明示的に押す必要があると説明されています。(Visual Studio Code)
企業標準として使う場合は、単に配布するだけでなく、次の運用を決めておく必要があります。
- プラグイン更新のレビュー担当者
- バージョン番号の付け方
- 検証環境での確認手順
- 旧バージョンへ戻す手順
- 更新内容を開発者へ知らせる方法
導入する場合のおすすめ手順
Enterprise-managed plugins in VS Codeを試すなら、次の順序で進めるとリスクを抑えられます。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 1 | 対象ユーザーとユースケースを決める | 「誰に何を配るか」が明確になっている |
| 2 | VS Code 1.122以降とCopilot CLIの利用状況を確認する | 対象者が対応クライアントを使える |
| 3 | 検証用プラグインとマーケットプレイスを用意する | 社内管理リポジトリで内容を確認できる |
| 4 | .github-private/.github/copilot/settings.jsonをPull Requestで追加する | レビューと承認の履歴が残る |
| 5 | 少人数で認証後の反映を確認する | VS CodeとCLIの両方で期待どおり表示される |
| 6 | フック、MCP、ネットワーク通信を確認する | セキュリティ上の懸念が整理されている |
| 7 | 開発者向けに使い方と問い合わせ先を案内する | 利用者が迷わず確認・報告できる |
| 8 | 全体展開後にログ・問い合わせ・利用状況を見直す | 不要なプラグインや問題設定を改善できる |
重要なのは、最初から「全社に便利なAIプラグインを一括配布する」ことを目標にしないことです。まずは、オンボーディング、テスト実行、レビュー補助、社内ドキュメント参照など、効果が分かりやすくリスクを管理しやすい用途から始めるのが現実的です。
どのような組織で特に有効か
Enterprise-managed plugins in VS Codeは、次のような組織ほど効果を感じやすい機能です。
開発標準を複数チームに展開している組織
複数の開発チームが同じ品質基準、レビュー観点、テスト手順を共有している場合、Agent SkillsやCustom Agentsとして標準化することで、手順書を読ませるだけの運用から一歩進めます。
たとえば、「Pull Request前に実行すべき確認」「セキュリティレビューで見る項目」「Reactコンポーネントのアクセシビリティ確認」などをスキル化しておけば、開発者がチャットから呼び出せます。
MCPサーバーを社内標準で使いたい組織
MCPサーバーを使うと、AIエージェントが外部ツールや社内データソースと連携しやすくなります。一方で、個人が自由に追加すると統制が難しくなります。
企業管理プラグインを使えば、管理者が確認済みのMCPサーバーを標準配布しやすくなります。たとえば、社内の仕様書検索、CI結果確認、チケット情報参照などを、承認済みの接続先に限定して提供できます。
AIエージェント利用をガバナンス下で広げたい組織
AIエージェント機能は、開発生産性を高める可能性がある一方、実行コマンド、ファイル変更、外部連携、認証情報の扱いなど、従来の補完機能より管理すべき範囲が広くなります。
Enterprise-managed pluginsは、便利な機能を止めるためではなく、安全に広げるための仕組みです。自由利用と全面禁止の中間として、「承認済みのプラグインを標準配布する」という選択肢が取りやすくなります。
すぐ確認すべきこと
管理者は、まず.github-private/.github/copilot/settings.jsonの有無、VS Code 1.122以降の利用状況、配布候補プラグインの中身を確認しましょう。特にフックとMCPサーバーを含むプラグインは、実行内容・通信先・権限をレビューしてから展開する必要があります。
開発者は、VS Codeのバージョン、GitHub Copilotの認証先、Agent Pluginsビューに表示されるプラグインを確認してください。企業標準のプラグインが見えない場合は、古いVS Codeを使っていないか、企業のCopilotライセンスで認証されているかを確認するのが最初の切り分けです。
Enterprise-managed plugins in VS Codeはまだ公開プレビュー段階ですが、AIエージェントを組織で安全に使うための重要な管理機能です。今すぐ全社展開しない場合でも、標準化したい開発作業、配布したいMCPサーバー、禁止・注意すべきフックを棚卸ししておくことで、正式展開時にスムーズに移行できます。
コメント