GitHub Copilotのremote controlは、2026年5月にGitHub Mobile・GitHub.com・VS Code・JetBrainsをまたいで一般提供され、7月30日に「managed devicesだけで許可する」制御が追加されました。これで企業は「全員に開けるか、閉じるか」の二択ではなく、管理端末だけを許可しつつ、必要に応じてSSO認証も求める運用ができます。本記事では、情シスや開発部門の管理者向けに、今回の変更点と導入判断のポイントを整理します。
結論: remote controlは“管理端末限定”で始めるのが安全
結論から言うと、Copilot CLIのremote controlは、まず管理対象PCだけで有効化し、未管理端末は無効のまま始めるのが現実的です。GitHubは7月30日、remoteControlというenterprise managed settingを追加し、端末単位で「enabled」「disabled」「requireSSO」を選べるようにしました。これにより、長時間ジョブの監視や外出先承認の利便性を取り込みながら、私物端末や検証用端末を経由した運用漏れを抑えやすくなっています。
何が変わった？ 7月30日の追加ポイント
今回の追加点は、remote controlそのものの提供開始ではなく、「どの端末がremote controlのホストになれるか」を細かく制御できるようになったことです。既存の「Store local sessions in the Cloud」ポリシーは、そもそもremote controlを使わせるかどうかを決める大枠の設定でした。一方で新しいremoteControl設定は、その上に重ねて、特定デバイスでは完全無効、別のデバイスではSSO必須、といったレイヤー制御を実現します。
前提条件: まずはCloud保存ポリシーが必要
remote controlを使うには、enterpriseまたはorganizationの「Store local sessions in the Cloud」ポリシーが「View and control」になっている必要があります。未設定または無効のままでは、今回のmanaged devices制限を追加してもremote control自体は使えません。つまり運用設計は二段階です。1つ目でクラウド保存と遠隔操作を許可し、2つ目でremoteControl設定により「どの端末で許可するか」を絞り込みます。
社内のCopilot運用ポリシーを急いで整えたい場合は、 AI導入・権限制御の相談はこちら 。既存のSSOやMDM前提に合わせて、最小権限での配布設計を一緒に整理できます。
設定値は3つ: enabled / disabled / requireSSO
GitHubが案内している設定値は3つです。enabledは制限なしで許可、disabledはその端末でホストされるsessionのremote controlを無効、requireSSOは指定したorganizationへのSSO認証を通ったクライアントだけに遠隔操作を許可します。特にrequireSSOは、外出先のスマホや自宅端末から承認したいが、企業SSOの境界は維持したい企業に向いています。機密リポジトリを触る自動化タスクでは、まずrequireSSOから始めるのが無難です。
配布方法は3通り: server-managed / MDM-managed / file-based
enterprise managed settingsの配布方法は3つあります。.github-private配下で一元管理するserver-managedは監査履歴を残しやすく、全社標準に向きます。IntuneやJamfなどを使うMDM-managedは、開発端末群だけ先に適用するような段階導入に向いています。file-basedはコンテナや個別検証端末にも配りやすい一方、配布漏れがそのまま統制漏れになるため、本番運用では補助策として考えるのが安全です。
どの企業に向く？ 判断基準は“長時間ジョブ”と“承認頻度”
この機能が特に効くのは、Copilot CLIで長時間の修正、レビュー、検証を回していて、途中で承認待ちが発生しやすいチームです。たとえば夜間のテスト修正、複数repoをまたぐリファクタ、外出中でも進捗確認したい障害対応では価値が出やすいです。逆に、CLIをほとんど使わない組織や、私物端末中心でMDMが入っていない組織では、利便性より統制コストが勝つ可能性があります。
導入前チェックリスト
導入前は4点を先に確認してください。1つ目は、対象ユーザーのCopilotライセンスがenterpriseまたはorganization配下で発行されているか。2つ目は、Store local sessions in the Cloudをどの階層で強制するか。3つ目は、remoteControlをrequireSSOにする対象organizationを明確にできるか。4つ目は、MDMまたは.github-privateでmanaged-settings.jsonを配布・検証する運用があるかです。この4点が曖昧だと、設定は入っても実際の運用がぶれます。
FAQ: よくある疑問
Q. remote controlを有効にすると、GitHubが端末を直接操作できるのでしょうか。A. いいえ。実行自体はあくまでローカル端末上で続き、GitHub.comやGitHub Mobileはsessionに対する入力・承認・監視の窓口になります。Q. script実行でも使えますか。A. いいえ。GitHub docsではinteractive session限定で、--promptを使うプログラム的な利用では使えないとされています。Q. 未管理端末から他端末のsessionを覗けますか。A. 同一GitHubアカウント前提ですが、ホスト端末側にかかったremoteControl設定が遠隔操作可否を左右します。
HelloCraftAIの見立て: 導入は“部署単位の限定解放”が現実解
今回の更新は派手な新機能というより、Copilot CLIを本番運用へ近づけるガバナンス強化です。全社一斉解放よりも、まずはSREや開発基盤チームの管理端末だけを対象にし、requireSSOで開始し、承認ログや運用負荷を見てから広げるほうが失敗しにくいでしょう。GitHubはserver-managed、MDM-managed、file-basedを同じJSONスキーマで配布できるとしているため、PoCから本番まで段階的に育てやすいのも利点です。
Copilotの権限制御や社内展開ルールを整備したい企業は、 /contact/からご相談ください 。remote control、model policy、課金統制まで含めて、実務に落ちる形で整理します。
