GitHubは2026年7月30日、GitHub Copilot remote control向けの企業管理設定として、新たにremoteControlを追加しました。管理者は、Copilotセッションを実行する端末ごとに、リモート操作をSSO認証済み環境だけに限定したり、完全に禁止したりできます。設定できるモードはrequireSSO、disabled、enabledの3種類です。(The GitHub Blog)
企業で導入する際に最も重要なのは、remoteControlがリモート操作機能そのものを有効化する設定ではない点です。全体の利用可否は、既存の「Store local sessions in the Cloud」ポリシーが引き続き管理します。remoteControlは、その上に端末単位の制限を追加する仕組みです。
管理対象端末だけでCopilot remote controlを許可したい場合は、サーバー管理設定で既定値をdisabledにし、許可する端末へMDMでrequireSSOを配布する構成が実用的です。MDMだけを設定しても、MDMの対象外となる端末には制限が届かないため、未管理端末を確実に除外できない場合があります。
GitHub Copilot remote controlに追加されたremoteControlとは
GitHub Copilot remote controlは、PC上で動作しているCopilot CLIセッションを、GitHub.comやGitHub Mobileから監視・操作できる機能です。
リモート側からは、次のような操作を行えます。
- Copilotの処理状況を確認する
- アクセス許可要求を承認または拒否する
- Copilotからの質問に回答する
- 新しいプロンプトを送信する
- 実行中の処理を中止する
- プランモードの承認や却下を行う
ただし、処理そのものがスマートフォンやGitHub上へ移動するわけではありません。シェルコマンド、ファイル操作、ツールの実行は、セッションを開始したPC上で継続します。一般的なリモートデスクトップではなく、Copilotセッションだけを遠隔操作する機能です。(GitHub Docs)
これまでは、企業・組織ポリシーによってユーザー全体の利用可否を制御するのが中心でした。今回追加されたremoteControlにより、管理者は「どの端末でホストされたセッションなら遠隔操作を許可するか」まで制御できるようになりました。
remoteControlで指定できる3つのモード
remoteControlでは、modeに次の3種類の値を指定します。(GitHub Docs)
| modeの値 | 動作 | 適した利用場面 |
|---|---|---|
requireSSO | 指定したGitHub Organizationに対して、操作側クライアントがSSO認可されている場合だけ許可する | 一般的な企業端末、社給PC |
disabled | その端末でホストされたセッションのリモート操作を禁止する | 特権端末、機密情報を扱う端末、共有端末 |
enabled | remoteControlによる追加制限を設けずに許可する | 検証環境、制限の少ない開発環境 |
requireSSOで企業のOrganizationに限定する
企業利用では、基本的にrequireSSOが第一候補です。
{
"remoteControl": {
"mode": "requireSSO",
"githubDotComOrganizations": [
"contoso"
]
}
}githubDotComOrganizationsには、Organizationの表示名ではなくログイン名を指定します。たとえばOrganizationのURLがgithub.com/contosoなら、指定する値はcontosoです。
複数のOrganizationを指定することもできます。
{
"remoteControl": {
"mode": "requireSSO",
"githubDotComOrganizations": [
"contoso",
"contoso-research",
"contoso-security"
]
}
}現在のGitHub公式ドキュメントでは、操作側クライアントが、一覧に含まれるOrganizationのうち少なくとも1つに対してSSO認可されていれば条件を満たします。すべてのOrganizationに対するSSO認可が必要なわけではありません。(GitHub Docs)
disabledで端末上のリモート操作を禁止する
{
"remoteControl": {
"mode": "disabled"
}
}disabledを設定すると、その端末で実行されるCopilotセッションを別の端末から操作できなくなります。
ただし、この制限は設定を受け取った端末に対して適用されます。同じユーザーが別のPCで開始したセッションまで一括で無効化するものではありません。
enabledは「全体ポリシーを上書きする」設定ではない
{
"remoteControl": {
"mode": "enabled"
}
}enabledは、remoteControlによる追加の端末制限を設けない設定です。
ここで注意したいのは、enabledにしても、上位の企業・組織ポリシーが無効ならremote controlを利用できないことです。また、セッションを開始したGitHubアカウントと同じアカウントでサインインしていることなど、既存の要件も引き続き適用されます。(GitHub Docs)
既存ポリシーとremoteControlは二層構造で動作する
Copilot remote controlの企業管理は、次の二層構造で考えると分かりやすくなります。
| 管理レイヤー | 主な役割 | 適用範囲 |
|---|---|---|
| 「Store local sessions in the Cloud」ポリシー | remote control機能そのものを利用できるか決める | EnterpriseまたはOrganization |
remoteControl | セッションをホストする端末で追加条件を適用する | アカウントまたは端末 |
「Store local sessions in the Cloud」ポリシーには、主に次の状態があります。
- 未構成または無効：セッション同期もremote controlも利用不可
- View from cloud：クラウドからの閲覧のみ
- View and control：閲覧とリモート操作を許可
remote controlを利用するには、適用されるポリシーが「View and control」でなければなりません。remoteControlは、この条件を緩和したり、無効なポリシーを有効化したりできません。(GitHub Docs)
組み合わせごとの結果は次のとおりです。
| 上位ポリシー | remoteControl | 結果 |
|---|---|---|
| View and control | enabled | remote controlを利用可能 |
| View and control | requireSSO | 指定OrganizationへのSSO認可がある場合だけ利用可能 |
| View and control | disabled | 利用不可 |
| View from cloud | いずれの値でも同じ | 閲覧のみで、リモート操作は不可 |
| 無効または未構成 | いずれの値でも同じ | 利用不可 |
つまり、remoteControlは「許可を広げる設定」ではなく、原則として既存ポリシーの範囲内で制限を細かくする設定です。
Copilot remote controlをSSO・MDM・managed-settings.jsonで制限する
remoteControlは、次の3つの方法で配布できます。
| 配布方法 | 主な適用単位 | 適した用途 |
|---|---|---|
| サーバー管理 | Enterpriseのユーザーアカウント | 全社共通の基準、変更履歴、プルリクエストによるレビュー |
| MDM管理 | WindowsまたはmacOSの端末グループ | 社給PC、部署別端末、機密端末 |
| ファイルベース | ファイルを配布した個別端末 | Linux、コンテナー、MDMを使えない環境 |
GitHubは、広範囲へ展開する前に、小規模な端末グループでパイロット運用することを推奨しています。(GitHub Docs)
サーバー管理は.github-privateに設定する
サーバー管理では、Enterpriseのガバナンス元として設定したOrganizationの.github-privateリポジトリを使用します。
ファイルの配置場所は次のとおりです。
.github-private
└─ copilot
└─ managed-settings.json設定例は次のとおりです。
{
"remoteControl": {
"mode": "requireSSO",
"githubDotComOrganizations": [
"contoso"
]
}
}基本的な設定手順は次のとおりです。
- ガバナンス元となるOrganizationに
.github-privateリポジトリを作成します。 copilot/managed-settings.jsonを作成します。remoteControlのキーと値を追加します。- 変更内容をレビューして既定ブランチへ反映します。
- 対象ユーザーがサポート対象のクライアントを利用していることを確認します。
設定は通常、約1時間以内に取得されます。クライアントの再起動や再サインインによって、より早く反映できる場合があります。(GitHub Docs)
copilot-settings.jsonとmanaged-settings.jsonの表記に注意する
2026年7月30日のGitHub Changelogには、remoteControlをcopilot-settings.jsonへ追加できるという記述があります。一方、現在のGitHub公式構成ドキュメントでは、企業管理用のファイル名としてmanaged-settings.jsonが案内されています。
実際に新しく構成する場合は、現行ドキュメントに従い、サーバー管理では次のパスを使用するのが安全です。
copilot/managed-settings.jsonMDMまたはファイルベースで配布する場合も、現在の公式リファレンスではmanaged-settings.jsonが使用されています。(The GitHub Blog)
MDMで端末グループへ配布する
MDM管理では、サーバー管理と同じJSONスキーマを使用し、WindowsまたはmacOSの対象デバイスグループへ配布します。
主な配布先は次のとおりです。
| OS | MDMの管理先 |
|---|---|
| Windows | HKLM\SOFTWARE\Policies\GitHubCopilot |
| macOS | com.github.copilotの管理対象Preference |
Microsoft IntuneやJamfなど、既存の端末管理基盤を利用できます。MDMは端末単位で制御できるため、社給PCだけ許可する場合や、特権端末だけdisabledにする場合に適しています。(GitHub Docs)
managed-settings.jsonを端末へ直接配布する
ファイルベースで配布する場合は、OSごとに決められた場所へmanaged-settings.jsonを配置します。
| OS | 配置場所 |
|---|---|
| Windows | %ProgramFiles%\GitHubCopilot\managed-settings.json |
| macOS | /Library/Application Support/GitHubCopilot/managed-settings.json |
| Linux | /etc/github-copilot/managed-settings.json |
ファイルを受け取っていない端末には、ファイルベースの制限は適用されません。そのため、「ファイルを置いた端末だけを許可する」のではなく、「ファイルを置いた端末だけに追加制限をかける」方式として理解する必要があります。(GitHub Docs)
LinuxやmacOSなどのPOSIX環境では、設定ファイルがシンボリックリンクになっている、root所有ではない、誰でも書き込める状態になっていると、Copilot CLIが設定を拒否します。構成管理ツールで配布するときは、ファイル内容だけでなく所有者とアクセス権も確認してください。(GitHub Docs)
設定の優先順位を理解する
複数の配布元に同じ設定が存在する場合、GitHubの企業管理設定では、原則として次の順序で優先されます。
- MDM管理設定
- サーバー管理設定
- ファイルベース設定
- ユーザー設定
たとえば、サーバー管理でrequireSSOを設定し、特定の端末だけMDMでdisabledにすると、その端末ではMDMのdisabledが優先されます。(GitHub Docs)
一方、VS Code 1.128以降では、最も優先順位の高い配布チャネルが1つでも管理設定を提供すると、そのチャネル全体が権威ある設定元となり、下位チャネルが無視される仕様が案内されています。
そのため、VS Codeを含む環境でMDMとサーバー管理を併用する場合は、remoteControlだけでなく、モデル、プラグイン、テレメトリなど、維持したい他の管理設定もMDM側へ含める必要があります。(Visual Studio Code)
また、現行リファレンスでチーム別オーバーライドの対象として明記されているのは、permissions.modelとpermissions.disableBypassPermissionsModeです。remoteControlは、Enterprise全体または端末グループ単位で設計するのが適切です。(GitHub Docs)
管理対象端末だけremote controlを許可する推奨構成
「社給PCでは利用できるが、私物PCや未管理端末では利用させたくない」という要件では、サーバー管理とMDMを組み合わせます。
サーバー管理で既定値をdisabledにする
Enterpriseの.github-privateリポジトリに、次の設定を配置します。
{
"remoteControl": {
"mode": "disabled"
}
}これにより、Enterpriseの設定を受け取るユーザーに対して、remote controlを原則禁止できます。
管理対象端末だけMDMでrequireSSOにする
許可する社給PCには、MDMで次の設定を配布します。
{
"remoteControl": {
"mode": "requireSSO",
"githubDotComOrganizations": [
"contoso"
]
}
}MDMはサーバー管理より優先されるため、管理対象端末ではrequireSSOが適用されます。未管理端末ではサーバー側のdisabledが残ります。
実務上の結果は次のようになります。
| 端末 | サーバー設定 | MDM設定 | 有効になる設定 |
|---|---|---|---|
| 社給PC | disabled | requireSSO | requireSSO |
| 特権管理PC | disabled | disabled | disabled |
| 未管理端末 | disabled | 配布なし | disabled |
この構成により、「管理対象端末かつ指定OrganizationへのSSO認可済み」という二つの条件を満たした環境だけでremote controlを利用できます。これは、MDMの端末スコープと、サーバー管理設定のアカウントスコープを組み合わせた運用例です。(The GitHub Blog)
MDMだけでは未管理端末を禁止できないことがある
MDMで管理対象PCにrequireSSOを配布しただけでは、MDMに登録されていない端末へ設定は届きません。
上位の「Store local sessions in the Cloud」ポリシーが「View and control」で、サーバー側にも制限がない場合、未管理端末ではremote controlを利用できる状態が残る可能性があります。
したがって、管理対象端末だけを許可する要件では、次の二つをセットで設計します。
- サーバー側で未管理端末にも届く禁止ベースラインを作る
- MDM側で許可する端末だけ設定を緩和する
要件別の設定パターン
| 企業の要件 | 推奨構成 |
|---|---|
| 全社でremote controlを禁止したい | 上位ポリシーを無効化、またはサーバー管理でdisabled |
| 全社員に許可するが企業SSOを必須にしたい | サーバー管理でrequireSSO |
| 管理対象端末だけ許可したい | サーバー管理でdisabled、MDMでrequireSSO |
| 一部の機密端末だけ禁止したい | サーバー管理でrequireSSO、機密端末へMDMでdisabled |
| 小規模な検証グループだけ許可したい | サーバー管理でdisabled、検証端末へMDMでenabledまたはrequireSSO |
| Linux端末へ制限を配布したい | /etc/github-copilot/managed-settings.jsonを構成管理ツールで配布 |
企業環境でenabledを全社既定値にする場合は、SSOによる追加確認がなくてもよいかを事前に評価してください。通常はrequireSSOを既定とし、例外的にenabledを使うほうが管理しやすくなります。
導入時に確認するテスト項目
設定を全社展開する前に、少なくとも次のパターンを確認します。
| テスト内容 | 期待する結果 |
|---|---|
| 管理対象端末、同一GitHubアカウント、SSO認可済み | remote controlに接続できる |
| 管理対象端末、SSO未認可 | 接続できない |
| 未管理端末 | 接続できない |
remoteControlがdisabledの端末 | 接続できない |
| 上位ポリシーがView from cloud | セッションは閲覧できても操作できない |
| 上位ポリシーが無効または未構成 | セッション同期とremote controlを利用できない |
| 別のGitHubアカウントから接続 | セッションを操作できない |
| PCがオフラインまたはスリープ状態 | 接続できない |
remote controlは、セッションを開始したGitHubアカウントと同じアカウントだけが利用できます。また、ホスト側のPCがオンラインであり、対話型のCopilot CLIセッションが実行されている必要があります。(GitHub Docs)
remoteControlが反映されないときの確認ポイント
上位ポリシーがView and controlになっているか
remoteControl.modeをenabledやrequireSSOにしても、上位ポリシーがView from cloud、無効、未構成ならリモート操作はできません。
ファイル名と配置場所が正しいか
サーバー管理では、現在の公式ドキュメントに従って次のファイルを確認します。
.github-private/copilot/managed-settings.json端末へのファイル配布では、OSごとに定められた場所へmanaged-settings.jsonを配置します。
Organizationのログイン名を指定しているか
githubDotComOrganizationsには、Organizationの表示名ではなくログイン名を指定します。大文字・小文字や余分なURL文字列が混在していないかも確認してください。
操作側でSSO認可が完了しているか
同じGitHubアカウントでサインインしていても、指定OrganizationへのSSO認可が完了していなければ、requireSSOの条件を満たしません。
設定の反映待ちになっていないか
サーバー管理設定は、反映まで約1時間かかる場合があります。テスト時はクライアントの再起動や再サインインも試します。VS Codeでは、Developer: Sync Account Policyコマンドでポリシー取得を促せます。(GitHub Docs)
Copilotライセンスの請求先が別のEnterpriseになっていないか
ユーザーが複数のEnterpriseなどからCopilotライセンスを受け取っている場合、個人のCopilot設定にある「Usage billed to」で、管理設定を配布しているEnterpriseが選択されているか確認します。(GitHub Docs)
remoteControl導入前にデータの流れも確認する
remote controlを有効にすると、会話メッセージ、ツール実行イベント、アクセス許可要求などのセッションイベントが、ローカルPCからGitHubへ送信されます。
一方、シェルコマンドやファイル操作は引き続きローカルPC上で実行されます。remote controlがPC全体への直接アクセス権を与えるわけではありませんが、遠隔地からアクセス許可要求やプロンプトへ応答できるため、企業では次の点を事前に整理しておく必要があります。
- どの種類の端末でremote controlを許可するか
- 機密リポジトリや本番環境を扱う端末を対象外にするか
- SSO認可を必須にするOrganizationはどこか
- 私物端末や未管理端末をどのように除外するか
- 設定変更をプルリクエストでレビューするか
- 緊急時に
disabledへ切り替える手順を用意するか
セキュリティを優先する場合は、まずサーバー管理でdisabledまたはrequireSSOを設定し、小規模な管理対象端末へMDMで展開してください。その後、SSO未認可端末や未管理端末から接続できないことを確認してから対象を広げるのが安全です。(GitHub Docs)
GitHub Copilot remote controlのremoteControl設定により、企業はユーザー単位の利用可否だけでなく、セッションを実行する端末単位で制御できるようになりました。
導入時は、最初に「Store local sessions in the Cloud」ポリシーの状態を確認し、その上でrequireSSO、disabled、enabledを選びます。管理対象端末だけに許可する場合は、サーバー管理のdisabledをベースラインにし、MDMで許可端末へrequireSSOを配布する構成が有効です。
また、2026年7月30日のChangelogにあるcopilot-settings.jsonという表記だけで判断せず、現行ドキュメントが案内するmanaged-settings.jsonとcopilot/managed-settings.jsonのパスを基準に構成してください。
コメント