GitHubは2026年8月18日、GitHub Copilot for JetBrainsでenterprise managed settingsを正式に拡張し、plugin管理、MCP serverの許可制御、OpenTelemetry、権限モードをIDE側まで一気に揃えました。8月11日のJetBrains更新ではMemoryやOllama BYOKが中心でしたが、今回の更新は情シスや開発基盤チーム向けの統制レイヤーが主役です。JetBrains利用者が増えている企業ほど、「便利になった」より「どこまで中央管理できるか」が導入可否を左右するため、影響は小さくありません。
GitHub Copilot for JetBrainsで何が変わったのか
今回のポイントは、JetBrains IDEsでも他クライアントと同じようにenterprise managed settingsを適用できるようになったことです。GitHub公式のchangelogでは、管理者がCopilot plan全体に対して一貫した制御を配布できると明記されています。つまり、VS Codeだけ厳しくしてJetBrainsだけ各自設定、というズレを減らせます。Java、Kotlin、PythonなどJetBrains利用比率が高い組織では、ここが埋まることで初めて全社標準化しやすくなります。
実務目線では、8月11日のJetBrainsアップデートで追加されたMemoryやOllama BYOKを、8月18日の管理設定で企業ポリシーに載せやすくなった流れと見るのが自然です。先に機能が増え、次に統制が追いついた形なので、PoCから本番展開へ移るタイミングの企業に特に刺さります。
管理者が押さえるべき4つの統制ポイント
1つ目はplugin governanceです。`enabledPlugins`で必須または禁止のpluginを指定し、`extraKnownMarketplaces`で承認済みの配布元を増やし、`strictKnownMarketplaces`でそれ以外のmarketplaceを閉じる設計が取れます。Agent Pluginsや社内配布pluginを使いたい一方で、野良pluginは避けたい企業にはかなり実用的です。
2つ目はMCP server allowlistです。GitHub Docsでは`allowedMcpServers`を設定すると一致しないserverは遮断され、`deniedMcpServers`はallowlistより優先されると整理されています。特にJetBrainsに外部MCPをつなぐ運用では、業務で必要なremote server URLだけ許可し、検証用や私的serverを止めるだけでも、情報持ち出しや不正接続のリスクをかなり減らせます。
3つ目はOpenTelemetryです。changelogではcollector endpoint、protocol、service name、resource attributes、content capture policyまで中央管理できるとされています。監査や可観測性を重視する企業なら、どのIDEからどのCopilot利用が発生したかを追える基盤を先に整えたいはずです。逆に、プロンプト本文まで送るかは慎重に決める必要があり、captureContentを有効にする場合は個人情報や機密コードの扱いを社内規程で明確化した方が安全です。
4つ目はpermission modeです。`permissions.disableBypassPermissionsMode`を`disable`にすると、GitHub公式ではBypass ApprovalsやYOLO型の許可を止められると説明されています。JetBrainsのagent利用を広げたいが、自動でコマンドやURLアクセスを通すのはまだ怖い、という企業にとっては最初の安全弁になります。
展開方法は3通り、まずはserver-managedが本命
GitHub Docsによると、enterprise managed settingsの展開方法はserver-managed、MDM-managed、file-basedの3種類です。標準は`.github-private`リポジトリに`copilot/managed-settings.json`を置くserver-managed方式で、約1時間以内に反映され、再サインインや再起動で即時反映も狙えます。監査履歴や全クライアントへの一貫適用を考えると、まずここから検討するのが順当です。
一方で、端末単位の制御を急ぎたい場合はMDM-managedが向いています。Windowsではレジストリ、macOSではmanaged preferencesとして配布でき、サインイン前でも効かせやすいのが強みです。GitHub Enterpriseライセンスや`.github-private`の整備がまだなら、file-basedで先に最低限の制御を入れ、後からserver-managedへ寄せる段階導入も現実的です。
導入判断ポイントは「全部解放」から卒業できるか
この更新で一番大きいのは、JetBrains利用者にもVS Code利用者と近い統制モデルを適用しやすくなった点です。導入判断では、1) 許可するplugin配布元を絞る、2) 接続を許すMCP serverを明示する、3) telemetry送信先とcontent取得方針を決める、4) Bypass Approvalsを封じた状態で現場運用を回せるか、の4点を先に決めると迷いにくくなります。特に金融、SIer、受託開発では、この4点が稟議の通りやすさを左右します。
逆に、個人裁量を最大化したい研究開発組織では、enterprise全体の厳格ロックではなく、team mappingで一部キーだけoverride可能にする設計が向いています。GitHub Docsでも`model`、`disableBypassPermissionsMode`、`allowedMcpServers`、`deniedMcpServers`はteamごとの上書き対象にできます。共通ガードレールを置きつつ、先行チームだけ少し広く試す形にしやすいのは実務上かなり便利です。
よくある質問
Q. JetBrainsだけ別管理でもよいですか。A. 短期的には可能ですが、pluginやMCPの許可体系がIDEごとにずれると、監査とサポートの負荷が跳ね上がります。Q. まず何から設定すべきですか。A. 迷ったら`strictKnownMarketplaces`ではなく、`allowedMcpServers`と`disableBypassPermissionsMode`から始めるのが無難です。接続先と自動承認だけでも先に締めると、現場体験を壊しすぎずにリスクを下げられます。
JetBrainsを含むGitHub Copilotの社内標準化、MCP接続ポリシー設計、plugin配布統制までまとめて整理したい場合は、 HelloCraftAIへご相談ください 。PoC段階のルール作りから、本番導入向けの運用設計まで支援できます。
