3行まとめ
このテーマをもう少し広げて見るなら、VS CodeのGitHub Copilot 5月更新：Agents window、BYOK、ターミナル安全機能の確認ポイント と GitHub Copilot SDKが一般提供：6言語対応、MCP/BYOK、課金で自社アプリに組み込む確認ポイント も合わせて確認してください。VS Code側のCopilot更新と合わせると、企業管理の対象がどの開発体験に広がるのかを確認しやすい。
Copilot CLI向けに出ていた企業管理機能が、VS Codeにも広がった点を見る。
plugin marketplace、default-installed plugins、MCP、hooks、skillsを標準化する話として読む。
全社固定ではなく、対象範囲、権限、ログ、切り戻しを小さく確認する。
便利なプラグイン配布だけでなく、開発者環境の標準設定をどう管理するかが主題になる。
- GitHubは2026年6月5日、Enterprise-managed pluginsがVS Codeでpublic previewになったと発表した。5月にCopilot CLI向けに出た企業管理機能が、VS Code 1.122にも広がった形だ。
- 企業管理者は、
.github-private/.github/copilot/settings.jsonを使って、plugin marketplacesやdefault-installed pluginsを標準化できる。GitHub Changelogでは、MCP configurationsやhooksを常時有効にする統制にも触れている。 - 現時点ではpublic previewなので、全社一斉展開の前に、Copilot Business/Enterpriseの対象範囲、設定変更のレビュー、MCPやhooksの権限、失敗時の切り戻しを小さく確認したい。
GitHub CopilotのEnterprise-managed pluginsは、開発者に「便利なプラグインを配れる」だけの更新ではない。企業側から見ると、Copilot CLIとVS Codeの利用者に対して、同じplugin marketplace、同じ標準プラグイン、同じMCP構成、同じhooksやskillsを配るための入口になる。
この話題は、2026年6月のBuild後に続いたCopilot関連更新の一つとして読むと位置づけが見えやすい。Copilot CLIの操作体験は「GitHub Copilot CLIがBuild 2026で刷新：音声入力、スケジュール実行、Rubber Duckの確認ポイント」で、実行場所や権限は「GitHub Copilot sandboxesがpublic preview：ローカル/クラウド実行、権限、課金の確認ポイント」で扱った。今回の記事では、企業が開発者環境をどうそろえるかに絞る。
Enterprise-managed plugins in VS Codeで変わったこと
- Copilot CLI向けpreview
企業管理者がCopilot CLI users向けにpluginsをconfigure and distributeできる機能として案内された。
- VS Code 1.122対応
Enterprise-managed capabilityがVS Code release version 1.122にも対応した。
- baseline standards
企業で設定した標準が、Copilot CLIとVS Code clientsに適用される読み方になる。
- public preview
仕様固定とは読まず、候補選定、限定確認、権限確認、変更レビューの順で試す。
今回の変化は、CLIだけの管理機能から、日常作業で使うVS Codeも含めた標準化へ広がったことにある。
GitHub Changelogの2026年6月5日記事では、Enterprise-managed plugins in VS Codeがpublic previewとして案内された。ポイントは、5月にCopilot CLI向けに出た機能が、VS Code release version 1.122にも対応したことだ。GitHubは、企業で設定したbaseline standardsが、ユーザーのCopilot CLIとVS Code clientsに適用されると説明している。
Copilot CLIのpreviewからVS Code 1.122へ広がった
5月6日のGitHub Changelogでは、Enterprise administratorsがCopilot CLI users向けにpluginsをconfigure and distributeできるpublic previewが発表されていた。6月5日の更新では、VS Code 1.122がそのenterprise-managed capabilityをサポートしたと説明されている。
つまり、今回の変化は「CLIだけの管理機能」から「CLIとVS Codeの両方をまたぐ標準化機能」へ広がったことにある。多くの企業では、開発者がVS Codeで日常作業をし、必要に応じてCLIやエージェント機能を使う。管理対象がVS Codeにも広がると、標準化の効果はオンボーディング、社内ツール連携、セキュリティ確認に及びやすくなる。
baseline standardsは体験改善より運用設計の話
GitHub Changelogでは、pluginsが多くのextensibility typesをサポートし、自動インストールもできるため、開発者のオンボーディングやセットアップ時間を減らせると説明されている。ここだけ読むと、便利な配布機能に見える。
ただし企業導入で先に見るべきなのは、誰が標準を決めるか、どのpluginを全員に配るか、どのmarketplaceを信頼するか、変更履歴をどう残すかだ。MCP configurationsやhooksを常時有効にできるなら、開発者の作業に影響する制御も企業標準として扱うことになる。これは単なる拡張機能の配布ではなく、開発者体験と統制の境界を決める作業だ。
public previewなので仕様固定とは読まない
GitHub Docsの該当ページでは、この機能はpublic previewであり変更される可能性があると明記されている。したがって、現時点で「全社標準としてすぐ固定する」と読むのは早い。
現実的には、次のような段階で見るのがよい。
- まず、候補pluginと候補marketplaceを洗い出す。
- 次に、対象チームを限定して、VS CodeとCopilot CLIの両方で期待通りに適用されるか確認する。
- その後、MCPやhooksの権限、ログ、失敗時の表示を確認する。
- 最後に、標準の変更手順をPull Requestやレビューで残す。
preview段階で大事なのは、機能を使い切ることではなく、将来の正式提供に備えて管理モデルを試すことだ。
settings.jsonで企業が標準化できる範囲
- 1`.github-private`
企業標準を置く管理場所として扱い、repositoryの所有者と変更手順を決める。
- 2`.github/copilot/settings.json`
Enterprise plugin standardsを保存する設定ファイルとして配置する。
- 3`extraKnownMarketplaces`
ユーザーが閲覧・インストールできる追加plugin marketplaceを定義する。
- 4`enabledPlugins`
`PLUGIN-NAME@MARKETPLACE-NAME`の形で、自動インストール対象のpluginを指定する。
- 5VS Code / Copilot CLI
認証したユーザーのクライアントに、企業が決めた標準を届ける。
marketplaceを増やすほど選択肢は広がるが、承認済みpluginと個人の試用pluginの境界も明確にしたい。
GitHub Docsでは、Enterprise plugin standardsは企業の.github-private repositoryに保存されたconfiguration fileを使うと説明されている。設定ファイルのパスは.github/copilot/settings.jsonだ。GitHub Changelogでは、実際の配置場所として.github-private/.github/copilot/settings.jsonが示されている。
ここで混乱しやすいのは、リポジトリ名とファイル内パスの違いだ。企業の.github-privateリポジトリの中に、.github/copilot/settings.jsonを置く、と理解すると読みやすい。
extraKnownMarketplacesでplugin marketplaceを増やす
Docsの設定例では、extraKnownMarketplacesというトップレベルプロパティが示されている。これは、ユーザーが閲覧・インストールできる追加plugin marketplaceを定義するための項目だ。
管理者は、どのmarketplaceを信頼するかを決める必要がある。社内で作ったmarketplace、特定組織が管理するGitHub repository、特定業務向けのplugin群を扱う場合、次の観点を先に確認したい。
- marketplaceの所有者は誰か。
- pluginの更新頻度はどれくらいか。
- pluginがMCP serverや外部APIに接続するか。
- 個人情報、ソースコード、社内チケット、クラウド認証情報に触れる可能性があるか。
- 問題が出たとき、marketplaceごと無効化できるか。
便利なmarketplaceを増やすほど、開発者の選択肢は広がる。一方で、選択肢が増えすぎると「企業として承認したplugin」と「個人が試しているplugin」の境界があいまいになる。Enterprise-managed pluginsを使うなら、marketplaceの追加そのものをレビュー対象にしたい。
enabledPluginsでdefault-installed pluginsを指定する
Docsの設定例では、enabledPluginsも示されている。これは、特定のpluginを自動インストールの対象にするための項目で、PLUGIN-NAME@MARKETPLACE-NAMEのような形でpluginを指定する。
GitHub Changelogでは、VS CodeまたはCopilot CLIからユーザーがauthenticateしたとき、指定したpluginsを自動インストールできると説明されている。これは新入社員や異動者のオンボーディングには強い。社内標準のコードレビュー補助、セキュリティ確認、社内API参照、ドキュメント検索、チケット連携などを、最初から同じ状態で配れるからだ。
ただし、自動インストールは強い機能だ。全員に配る前に、pluginを次の3段階に分けると判断しやすい。
全員に必要なplugin
セキュリティポリシー、社内共通ドキュメント、標準レビュー、共通の開発規約など、ほぼ全開発者が使うpluginは標準化候補になる。更新頻度と権限が安定していることも条件にしたい。
特定チームだけに必要なplugin
特定クラウド、特定言語、特定プロダクト、特定顧客向けのpluginは、全員配布にしないほうがよい場合がある。全員に入れると、関係ない権限や不要な通知が増える。
試験導入に留めるplugin
新しいMCP連携、まだ監査が浅いhooks、実行環境に依存するskillsは、pilotチームだけで見るほうが安全だ。preview機能とpreview pluginを重ねると、問題の原因が切り分けにくくなる。
MCP、hooks、skillsを企業統制でどう読むか
接続先、認証情報、読み取りと書き込みの範囲、監査ログの扱いを確認する。
開発フローに常時入る制御として、実行タイミング、失敗時表示、切り戻しを決める。
社内の定型作業を配る場合、誰が更新し、どのチームへ適用するかを管理する。
GitHub、Azure、社内Wiki、チケット、顧客データのどこに触れるかを明確にする。
MCPやhooksを標準化すると開発者体験は良くなる一方、接続先と権限境界も企業標準として固定される。
GitHub Changelogは、governance strategyを強化する例として、hooks and MCP configurations that are always enabled across your enterpriseに触れている。ここは読み飛ばさないほうがいい。MCPやhooksは、単にCopilotに機能を足す部品ではなく、社内システム、コマンド実行、開発ワークフローに関わる入口になり得る。
MCP configurationsは接続先の標準化として読む
MCPは、AIエージェントやCopilotが外部ツール、データソース、開発環境に接続するための文脈で使われる。企業がMCP configurationを標準化する場合、開発者が個別に接続先を探す手間は減る。一方で、どの社内システムに接続してよいのか、どの認証情報を使うのか、ログをどこに残すのかを決める必要がある。
確認したいのは、次のような点だ。
- MCP serverの所有部門はどこか。
- 接続先がGitHub、Azure、社内Wiki、チケット、ソースコード検索、顧客データのどれにあたるか。
- Copilot側の操作で、読み取りだけか、書き込みや実行まで可能か。
- 認証情報は個人単位か、組織単位か。
- 監査ログや失敗ログを誰が見られるか。
MCPを標準化すると、開発者体験はかなり良くなる可能性がある。しかし、接続先の標準化は権限境界の標準化でもある。便利さと同じ重さで、データ境界を見たい。
hooksは開発フローに常時入る制御として読む
hooksは、特定のイベントや操作に合わせて処理を動かす仕組みとして読める。GitHub Changelogが「always enabled」と表現している以上、企業は開発者が意識しないタイミングで標準の処理が走る可能性を考える必要がある。
hooksで期待できることはある。社内ルールに沿ったチェック、危険な操作の警告、特定ツールの自動起動、レビュー前の整形、社内ドキュメント参照などだ。だが、常時有効な制御は、失敗時の説明がないと開発者の不信感につながる。
導入前に、少なくとも次を決めておきたい。
- hooksが失敗したとき、開発者には何が表示されるか。
- 一時的にスキップできる条件はあるか。
- hooksの実行結果は監査対象になるか。
- hooksが社外サービスや社内APIに通信するか。
- preview仕様変更でhooksが動かなくなった場合、誰が切り戻すか。
skillsとcustom agentsはオンボーディング資産として読む
GitHub Changelogでは、custom agents and skillsを広く共有することで、developer onboardingを改善できると説明されている。ここでいうskillsは、GitHub Copilotのplugin標準化文脈でのskillsとして読む。Codexや別製品のスキル機構と混ぜて考えないほうがよい。
企業にとっての利点は、属人化した手順を開発者のローカル環境だけに残さず、標準のagentやskillとして配れることだ。たとえば、新しい開発者がリポジトリに入ったとき、社内レビュー観点、ビルド手順、デプロイ前確認、障害調査の初動を同じ形式で受け取れる。
一方で、標準のagentやskillは「組織として推奨した手順」に見える。古い手順を配り続けると、誤った作業が広がる。pluginと同じく、所有者、更新日、レビュー者、対象チームを明確にしたい。
上振れと下振れ
上振れは、開発者体験の均一化だ。新しいメンバーが環境構築で止まりにくくなり、社内ツール連携やレビュー補助に早く乗れる。Platform EngineeringやDevEx担当者にとっては、個別サポートの負担を減らせる。
下振れは、標準化の過剰適用だ。不要なpluginが全員に入り、ローカル環境差分が増え、権限の説明が追いつかなくなる。特にpreview段階では、仕様変更の影響が全社に広がる可能性がある。だからこそ、最初は対象チームを小さくするほうがよい。
導入前に決める運用フロー
- 11. 所有者を決める
Enterprise owner、Platform Engineering、Security、開発チーム代表の役割を分ける。
- 22. 候補を洗い出す
plugin候補、marketplace、MCP接続先、hooks、外部API、ログを確認する。
- 33. Pull Requestで残す
plugin名、marketplace、権限、対象チーム、pilot期間、戻し方を変更履歴に残す。
- 44. 小さくpilotする
VS Code利用者とCopilot CLI利用者が混在するチームで、標準の適用を確認する。
- 55. 展開判断する
既存ユーザー、新規ユーザー、proxy、社内ネットワーク、失敗時表示まで見て判断する。
preview段階では機能を使い切ることより、将来の正式提供に備えて管理モデルを試すことが重要になる。
Enterprise-managed pluginsを使う前に、企業は設定そのものより運用を決めたい。設定ファイルは短くても、関係者は多い。Enterprise owner、Platform Engineering、Security、開発部門、場合によっては法務や監査担当も関わる。
.github-privateを誰が管理するか
Docsでは、設定は企業の.github-private repositoryに置かれる。ここは通常の公開リポジトリではなく、企業標準を置く管理場所として扱うべきだ。
管理者を一人だけに寄せると、変更が早い一方でレビューが弱くなる。逆に、承認者を増やしすぎるとpreviewの検証が遅くなる。おすすめは、次のような役割分担だ。
- Enterprise ownerは、設定の最終責任と権限管理を見る。
- Platform Engineeringは、plugin候補、marketplace、VS CodeとCLIの動作確認を見る。
- Securityは、MCP接続先、hooks、外部API、ログ、データ境界を見る。
- 開発チーム代表は、実際の作業で邪魔にならないかを確認する。
変更レビューをPull Requestで残す
GitHub Docsは、設定がGit repositoryに置かれることで、変更をversion-controlled policiesとして追跡、監査、レビューできる点を利点に挙げている。これは重要だ。
pluginを追加する変更は、単なる設定変更ではない。開発者の環境に入るもの、Copilotが使う接続先、hooksとして動く処理が変わる可能性がある。Pull Requestには、次の項目を残すと後から振り返りやすい。
- 追加または削除するplugin名。
- 対象marketplace。
- 権限や接続先の説明。
- 対象チームまたは対象ユーザー。
- pilot期間。
- 問題が出たときの戻し方。
小さなチームでpilotする
preview段階では、いきなり全社展開するより、VS Code利用者とCopilot CLI利用者が混在するチームでpilotするほうが現実的だ。両方のクライアントで同じ標準が適用されるかを見られるからだ。
pilotでは、次を確認したい。
- VS Code 1.122以上で、認証後に期待したpluginが入るか。
- Copilot CLIでも同じ標準が適用されるか。
- 既存ユーザーと新規ユーザーで挙動に差があるか。
- pluginを外したとき、既存環境ではどう見えるか。
- proxy、社内ネットワーク、端末管理下の環境で問題がないか。
- MCPやhooksの失敗が、開発者に分かる形で表示されるか。
全社展開の判断は、pilotで「便利だった」だけでは足りない。問題が出たときに止められるか、問い合わせ先が明確か、SecurityとDevExの双方が納得できるかまで見る。
既存のCopilot関連記事とどう読み分けるか
Enterprise-managed pluginsは、CLIやVS Codeに入るplugin、MCP、hooks、skillsを誰がどう配るかに集中して読む。
2026年6月前後のGitHub Copilot関連更新は多い。今回のEnterprise-managed pluginsは、同じCopilotでも、モデル追加やCLI操作体験とは読みどころが違う。
Copilot CLI刷新とは別テーマにする
Copilot CLIの音声入力、Rubber Duck、prompt schedulingは、開発者がCopilotをどう使うかの体験改善だ。Enterprise-managed pluginsは、企業がその体験の入口をどう標準化するかの話になる。
CLIを使う開発者にとっては、両方が関係する。CLIで何ができるかを知りたい場合は、Copilot CLI刷新の記事を読むとよい。今回の記事は、そのCLIやVS Codeに入るplugin、MCP、hooks、skillsを誰がどう配るかに集中する。
sandboxesやAI Creditsとは混ぜすぎない
GitHub Copilot sandboxesは、エージェントやコマンド実行の場所、権限、課金を考える話だ。Enterprise-managed pluginsは、その手前にある標準設定の話だ。MCPやhooksが実行や外部接続に関わる可能性はあるが、sandboxesそのものの挙動をこの記事で断定しない。
AI Creditsも同じだ。VS Code 1.122のリリースノートでは、Copilotのusage-based billingやAI creditsの消費、モデル選択時のcost informationにも触れている。ただし、Enterprise-managed pluginsそのものの主題は課金ではない。モデルやAI Creditsの文脈は「MAI-Code-1-FlashがGitHub Copilotに登場：VS Codeロールアウト、256Kコンテキスト、AI Creditsの確認ポイント」へ分けて読むのがよい。
月次トピックとして追う価値がある
Build 2026後のCopilot更新は、個別機能だけでなく、開発者環境全体の管理へ広がっている。6月の流れを追う場合は、固定ページの「Microsoft 2026年6月重要トピックまとめ」もあわせて見ると、GitHub Copilot、VS Code、Windows開発基盤、Microsoft 365 Copilotの更新を同じ月の文脈で整理しやすい。
導入前チェックリスト
現時点ではpublic previewなので、全社導入、限定pilot、見送りの3段階で判断を分けたい。
ここからは、Enterprise-managed pluginsを試す前の確認表として使えるように整理する。
管理者向けチェック
| 確認項目 | 見る人 | 確認すること | 未確認時のリスク |
|---|---|---|---|
| Copilot plan | Enterprise owner | 対象ユーザーが企業のCopilot planに含まれるか | 設定しても対象ユーザーに適用されない |
.github-private | Enterprise owner / Platform | repositoryの有無、管理者、変更レビュー手順 | 設定ファイルの所有者が不明になる |
settings.json | Platform | .github/copilot/settings.jsonの配置とスキーマ | 誤った場所に置いて反映されない |
| marketplace | Platform / Security | 所有者、更新頻度、接続先、権限 | 承認していないpluginが標準候補に入る |
| default-installed plugin | Platform / DevEx | 全員配布か、チーム限定か、pilotか | 不要なpluginが全員に入る |
| MCP configuration | Security / Platform | 接続先、認証、ログ、読み書き範囲 | 社内データ境界を説明できない |
| hooks | Security / DevEx | 実行タイミング、失敗時表示、切り戻し | 開発者が理由不明の制御を受ける |
| 変更レビュー | Platform / Security | Pull Requestで理由、対象、戻し方を残す | 変更履歴を監査できない |
開発者向けチェック
開発者側には、管理者向けの詳細をすべて説明する必要はない。ただし、自分の環境で何が標準として入るのか、問題が出たらどこへ言えばよいのかは明確にしたい。
- VS Code 1.122以降を使っているか。
- GitHub Copilotに企業アカウントで認証しているか。
- Copilot CLIも使う場合、同じ企業アカウントで認証しているか。
- 自動インストールされたpluginが何か分かるか。
- MCPやhooksが動いたとき、何が起きたか分かる表示があるか。
- pluginが不要または問題を起こした場合、問い合わせ先が分かるか。
判断は3段階で分ける
現時点ではpublic previewなので、判断は「今すぐ全社導入」ではなく、次の3段階で分けるのがよい。
今すぐpilot
VS CodeとCopilot CLIを両方使うチームがあり、標準化したいplugin候補が少数に絞れている場合。SecurityとPlatform Engineeringが一緒に見られることが条件になる。
仕様追跡のみ
興味はあるが、MCPやhooksの運用ルールがまだない場合。ChangelogとDocsを追い、正式提供やスキーマ変更を待ちながら、候補pluginだけ整理しておく。
見送り
企業のCopilot利用範囲がまだ小さい、.github-privateの管理体制がない、pluginの権限確認ができない場合。無理にpreviewを入れるより、Copilotの利用ポリシーを先に整えたほうがよい。
次に読むなら
Microsoft Watch JapanはMicrosoftおよびGitHubと非提携の独立ブログです。公式情報の確認を優先し、preview機能は確認日と未確定点を分けて追跡します。Copilot、VS Code、Microsoft 365 Copilot、Azure AIの更新をまとめて追う場合は、ニュースレターと資料・確認ログも活用してください。
更新履歴
- 2026年6月6日
GitHub Changelog、GitHub Docs、VS Code 1.122 release notesを確認し、初回版を作成。
Enterprise-managed pluginsはpublic previewとして記載し、今後の仕様変更に注意して追う。
| 日付 | 内容 |
|---|---|
| 2026年6月6日 | GitHub Changelog、GitHub Docs、VS Code 1.122 release notesを確認し、初回版を作成。Enterprise-managed pluginsはpublic previewとして記載。 |
次に読むなら
参照した主な情報源
- GitHub Changelog: Enterprise-managed plugins in VS Code in public preview（確認日: 2026年6月6日）
Enterprise-managed plugins in VS Code in public preview
- GitHub Docs: Configuring enterprise plugin standards for Copilot CLI（確認日: 2026年6月6日）
https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-plugin-standards
- GitHub Docs: About enterprise-managed plugin standards for Copilot CLI（確認日: 2026年6月6日）
https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-enterprise-plugin-standards
- Visual Studio Code 1.122 release notes（確認日: 2026年6月6日）
https://code.visualstudio.com/updates/v1_122