GitHub Enterprise Cloud と Server の違いを、ユーザー管理・Copilot・周辺機能から整理する

この記事を書こうと思ったきっかけ

企業で GitHub を使うとき、GitHub Enterprise Cloud に Data Residency が登場したことで、コードやユーザーデータの保存先を選びやすくなりました。

それでも、「ソースコードを自社管理の環境から出したくない」「ネットワークも含めてオンプレミスに閉じたい」という要望は、まだまだ根強いと思います。その場合に候補になるのが、自己ホスト型の GitHub Enterprise Server（GHES） です。

一方で、私は Cloud を中心に支援する Cloud Solution Architect（CSA）なので、GHES の実際のユーザー管理や、GitHub Copilot と組み合わせたときの管理境界について、正直あまり詳しくありませんでした。

そこで今回は、次の疑問を GitHub 公式ドキュメントから整理してみます。

• GHES では、ユーザーをどう登録・管理するのか。Enterprise Managed Users（EMU）は使えるのか
• GitHub Copilot のライセンスやポリシーは、GHES と Cloud のどちらで管理するのか
• Organization ごとに Copilot ポリシーを分けられるのか
• GitHub Copilot cloud agent や IDE の Agent Mode は使えるのか
• Actions、Codespaces、Dependabot、Code Security などにどんな違いがあるのか

⚠️ この記事の検証範囲について
私は GHES の実機環境を持っていないため、この記事の内容は実機で検証できていません。2026 年 7 月 27 日時点の GitHub 公式ドキュメント（GHES は latest が参照する 3.21）をもとに、GitHub Copilot に調査・整理してもらった内容を、私自身の理解のためにまとめたものです。特に GHES はバージョン、ライセンス契約、ネットワーク構成によって利用可能な機能が変わります。実際の導入では、利用予定バージョンの公式ドキュメントと GitHub の営業・サポートへ必ず確認してください。

目次

• まず結論
• 1. Cloud と Server では、閉じられる範囲が違う
• 2. GHES のユーザー管理と EMU
• 3. GHES 利用者が Copilot を使うときの管理境界
• 4. Copilot ポリシーは Organization ごとに分けられるか
• 5. 設定しても効かない Copilot ポリシーがある
• 6. GHES で Copilot cloud agent は使えるのか
• 7. その他の GitHub 製品で出る主な制約
• 8. 導入前に確認したいこと
• まとめ
• 公式情報源

まず結論

先に、今回調べた内容をざっくりまとめます。

一番重要なのは、GHES を選んでも Copilot までオンプレミスに閉じるわけではないことです。

GHES はコード、Issue、Pull Request などの開発データを自社管理の環境に置けます。しかし Copilot の推論、ライセンス、ポリシーは GitHub の Cloud サービスです。したがって「リポジトリは GHES、AI は Cloud」という 2 つの管理面を組み合わせることになります。

1. Cloud と Server では、閉じられる範囲が違う

GitHub Enterprise には、GitHub が運用する GitHub Enterprise Cloud（GHEC） と、自社で運用する GitHub Enterprise Server（GHES） があります。

GitHub Enterprise Cloud

• GitHub がサービスを運用する
• 通常の github.com または Data Residency の SUBDOMAIN.ghe.com を利用する
• アップグレード、可用性、バックアップ、基盤の容量管理を GitHub に任せられる
• GitHub.com と一体になった最新の AI、Codespaces、Marketplace、GitHub-hosted runner を利用しやすい

GitHub Enterprise Server

• オンプレミス、または自社管理の AWS / Azure / Google Cloud / VMware などへアプライアンスを配置する
• リポジトリ、Issue、Pull Request、ユーザー情報を自社管理のインスタンスへ保存する
• インスタンスのアップグレード、バックアップ、HA、監視、証明書、DNS、容量、障害対応を自社で行う
• 機能は GHES のリリースに同梱されるため、GitHub.com の新機能と同時には提供されない

ただし GHES も、必ずしも完全な閉域で完結するわけではありません。

たとえば GitHub Connect を有効にすると、GHES と GitHub Enterprise Cloud の Enterprise アカウントを接続し、ライセンス同期、Dependabot、GitHub.com 上の Actions、統合検索などを利用できます。GitHub Connect 自体がリポジトリ、Issue、Pull Request を Cloud へ転送することはありません。ただし、接続情報や利用ライセンス数に加え、有効にした機能に応じてユーザー ID・メールアドレス、Action の名前と YAML、検索語句や検索結果などが送信されます。

ここには 2 つ注意点があります。

• GitHub Connect の自動ライセンス同期が重複排除するのは、GitHub Enterprise プランと GitHub Advanced Security 製品のライセンスです。Copilot ライセンスの割り当てを代替するものではありません
• GHES を GHE.com の Enterprise へ接続する場合、現時点では Server Statistics と GitHub.com Actions を GitHub Connect 経由で利用できません

つまり「GHES を選べば、すべての通信とデータが自動的にオンプレミスで完結する」わけではありません。利用する機能ごとに、何がどちら向きに送信されるかを確認する必要があります。

2. GHES のユーザー管理と EMU

GHES で選べる認証方式

GHES のユーザーは、GHES インスタンスの中に作成されるアカウントです。認証方式として、次の選択肢があります。

• Built-in authentication: GHES 自身でユーザー名とパスワードを管理する
• CAS: 外部の CAS サーバーで認証する
• LDAP: 外部ディレクトリで認証する
• SAML SSO: Entra ID、Okta などの IdP で認証する

Built-in authentication では、招待またはサインアップからユーザーがアカウントを作成します。CAS、LDAP、SAML では、認証を通過したユーザーが初回アクセスしたときに JIT（Just-in-Time）で GHES アカウントを作成できます。

SAML + SCIM なら、IdP から登録・停止できる

現在の GHES では、SAML SSO と SCIM を組み合わせることで、IdP から次のライフサイクルを管理できます。

• ユーザーまたはグループを IdP アプリへ割り当てると、GHES アカウントを作成する
• IdP 上の氏名やメールアドレスの更新を GHES へ反映する
• 割り当て解除や無効化で、GHES のセッションを失効し、アカウントを停止する
• 再割り当てでアカウントを復元する
• IdP グループから Team / Organization のメンバーシップを管理する

パートナー IdP として、公式ドキュメントには次が掲載されています。

• Microsoft Entra ID
• Okta
• PingFederate（Public Preview）

GitHub は、認証とプロビジョニングに同じパートナー IdP を使う構成を推奨しています。SCIM を使う場合、認証は SAML または SAML + built-in authentication が必要で、CAS / LDAP と SCIM は組み合わせられません。

既存の SAML 環境へ SCIM を追加するときは、移行手順にも注意が必要です。SCIM を有効にすると、既存の SAML ユーザーは SCIM で ID がプロビジョニングされるまでサインインできません。既存アカウントとの紐付けには、SCIM の userName と GHES のユーザー名が使われます。段階的な割り当て、ユーザー名の照合、built-in authentication を使う緊急用管理者アカウントを含めて、事前に移行計画を作る必要があります。

GHES で EMU は使えない

ここがいちばん混同しやすいところです。

Enterprise Managed Users（EMU）は GitHub Enterprise Cloud のアカウントモデルであり、GHES にはありません。

GHES の SAML + SCIM は、IdP から GHES 内のアカウントを作成・停止する仕組みです。見た目の運用は EMU に近い部分がありますが、次の点で別物です。

「IdP でユーザーを自動作成したい」という要件には GHES の SCIM が使えますが、「GitHub Cloud 上の管理ユーザーとして Copilot や Cloud 機能も同じ ID で統制したい」という要件では、Cloud 側の個人アカウントまたは EMU も別途設計する必要があります。

3. GHES 利用者が Copilot を使うときの管理境界

GitHub Copilot は GHES appliance の中で推論する機能ではありません。IDE の拡張機能や CLI から GitHub の Copilot サービスへ接続して利用します。

そのため GHES のリポジトリで Copilot を使う場合でも、利用者は次の 2 つの ID を持つ構成になります。

1. GHES へサインインし、リポジトリへアクセスするための GHES アカウント
2. Copilot ライセンスを受け取り、IDE から Copilot へ認証するための Cloud 側 GitHub アカウント

この 2 つは、同じ企業メールアドレスや同じ IdP を使っていても、GitHub 上では別のアカウントとして管理されます。

Copilot Business 専用 Enterprise という選択肢

GitHub 公式ドキュメントでは、Cloud 側の Organization や Enterprise でユーザーをまだ管理していない企業向けに、Copilot Business のライセンス管理専用 Enterpriseを作る方法が案内されています。これは GHES 利用企業に必須の構成ではなく、Copilot だけを集中管理するための選択肢です。

この専用 Enterprise では、次の 2 通りから ID 方式を選べます。

• 個人 GitHub アカウントを Enterprise へ招待する
• EMU を選び、IdP + SCIM で Copilot 用の管理ユーザーを払い出す

ユーザーを Organization へ所属させず、Enterprise へ直接追加し、ユーザーまたは Enterprise Team 単位で Copilot Business ライセンスを付与できます。この方式なら、Copilot のためだけに GitHub Enterprise ライセンスを各ユーザーへ付与する必要はありません。

開発者
  ├─ GHES アカウント ── 自社 GHES のリポジトリ・Issue・PR へアクセス
  └─ Cloud 側アカウント ── Copilot Business のライセンス・ポリシーを受け取る
                               └─ IDE / CLI から Copilot サービスへ接続

つまり、Copilot のライセンスとポリシーは GHES の Enterprise Settings ではなく、Cloud 側の Enterprise Settings にある AI Controls で管理すると考えるのが分かりやすいです。

なお、GitHub Enterprise プランでは GitHub Enterprise Cloud と GitHub Enterprise Server の両方を利用できます。すでに契約に紐づく Cloud 側 Enterprise がある場合、その Enterprise を Copilot 管理にも使うのか、Copilot 専用 Enterprise を分けるのかは、契約と ID 設計によって変わります。ここは GitHub の営業担当へ確認した方が安全です。

また、Copilot Business と Copilot Enterprise の差分には、GitHub.com 上のリポジトリや Pull Request を前提とする機能が含まれます。コードの正本を GHES にだけ置く場合、上位プランの機能をすべて利用できるとは限りません。プラン名だけで選ばず、利用したい機能が GHES リポジトリにも適用できるかを機能単位で確認する必要があります。

4. Copilot ポリシーは Organization ごとに分けられるか

結論から言うと、Cloud 側に Organization を作れば分けられます。ただし、必ず Organization が必要なわけではありません。

Organization を作らない場合

• Copilot Business ライセンスをユーザーまたは Enterprise Team へ直接割り当てる
• Enterprise ポリシーを一括適用する
• Enterprise ポリシーが「No policy」の項目は、Policies for enterprise-assigned usersの既定値で有効・無効を決める
• Copilot ライセンスだけを配る構成に向く

Organization を作る場合

• Enterprise owner が Enterprise 全体のポリシーを強制するか、No policyで Organization owner へ委譲する
• Organization ごとに Copilot Business / Enterprise の有効化やポリシーを変えられる
• Organization owner がメンバーへのライセンス付与を管理できる
• Organization にユーザーを所属させると、Copilot だけでなく GitHub Enterprise ライセンスも消費する

公式の Copilot Business 専用 Enterprise 手順では、初期構成時に「Organization を作らない」よう案内されています。Copilot ライセンスだけを管理したいなら、まず Enterprise 直下のユーザー / Team 割り当てから始めるのがシンプルです。

一方で、server-managed settings を .github-private リポジトリから配布するなど、リポジトリを使う集中設定には Organization が必要です。この場合は、その Organization を作成・管理するユーザーに GitHub Enterprise ライセンスが必要になります。MDM やファイル配布で managed settings を展開する方法もあります。

複数 Organization のポリシー競合に注意

同じユーザーが複数 Organization から Copilot ライセンスを受け取り、それぞれのポリシーが異なる場合、多くの機能は もっとも制限の弱いポリシー が適用されます。

一方、公開コードに一致する候補、GitHub 以外のリポジトリに対する semantic indexing、Copilot Metrics API、ライセンスを持たないメンバーへの Copilot code review など、一部のポリシーにはもっとも制限の強い設定が適用されます。

「厳しい Organization へ入れたから、そのユーザーの Copilot 全体も厳しくなる」とは限りません。厳格な統制が必要なら、Enterprise レベルで明示的に強制し、Organization へ安易に委譲しない方が安全です。

5. 設定しても効かない Copilot ポリシーがある

Copilot は IDE、CLI、GitHub.com、Copilot cloud agent、Copilot code review など複数の利用場面があります。同じポリシーでも、すべての機能に適用されるわけではありません。

代表的な例です。

特にコンテンツ除外（Content exclusion）は注意が必要です。

Cloud 側の Enterprise / Organization 設定では、GHES を含む任意の Git リモート URL を指定して、特定のファイルやパスを Copilot のコンテキストから除外できます。通常の inline suggestion や対応する Copilot Chat では適用されますが、Copilot Chat の Edit Mode / Agent Mode、Copilot CLI、Copilot cloud agent にはコンテンツ除外が適用されません。

「除外ポリシーを設定したから、すべての Copilot 機能からそのファイルが除外される」と考えるのは危険です。導入時は機能単位で許可し、利用する機能ごとにポリシーの対応表を確認する必要があります。

6. GHES で Copilot cloud agent は使えるのか

ここでは、次の 2 つを分けて考える必要があります。

IDEのAgent Mode

IDE の中でローカルファイルを読み、コマンドを実行し、コードを変更する機能です。GHES リポジトリをローカルへクローンしている場合でも、Cloud 側アカウントで Copilot へ認証できれば利用できます。

ただし前述のとおり、Agent Mode ではコンテンツ除外がサポートされません。ネットワーク、ターミナル実行、MCP、承認操作など、クライアント側の統制を別途設計する必要があります。

Copilot cloud agent

Copilot cloud agent は GitHub 上の Issue や Chat から作業を委譲し、GitHub Actions で動く一時的な開発環境の中でブランチ作成、変更、テスト、Pull Request 作成を行う機能です。

公式の管理手順は、GitHub.com 上の次のリソースを前提にしています。

• Cloud 側 Enterprise の AI Controls
• Cloud 側 Organization
• Organization が所有するリポジトリ
• GitHub Actionsによる実行環境

GitHub 公式ドキュメントでは、Copilot cloud agent は GitHub にホストされたリポジトリだけで動作すると説明されています。また、管理手順は GitHub.com 上の Enterprise、Organization、リポジトリを前提としており、GHES 3.21 のドキュメントには Copilot cloud agent の機能ページがありません。この記事では、GHES だけに存在するリポジトリは Copilot cloud agent の対象外として整理します。

そのため、現時点では次の整理が安全です。

• GHES リポジトリをローカルで扱う IDE の Agent Mode: 利用可能
• GHES だけに保存されたリポジトリへ Copilot cloud agent を直接割り当てる: 対象外として扱う
• Copilot cloud agent を使うため Cloud 側へリポジトリをミラー / 移行する: 技術的には別案だが、コードをオンプレミスに閉じる要件と衝突する

Copilot cloud agent を要件に含める場合は、リポジトリの正本をどこに置くか、Cloud へ何を複製してよいかを先に決め、GitHub の営業またはサポートへ最新の GHES 対応状況を確認する必要があります。

7. その他の GitHub 製品で出る主な制約

GitHub Actions

GHES でも GitHub Actions は利用できます。ただし Cloud 版と運用モデルが大きく異なります。

• GHES では GitHub Actions が既定で無効。Site administrator が有効化する
• GitHub-hosted runnerは利用できず、self-hosted runnerが必須
• workflow log、cache、artifact 用に外部オブジェクトストレージが必要
• runner の OS、patch、autoscaling、network、secret 保護を自社で運用する
• GitHub.com / Marketplace 上の Action は既定で利用不可
• GitHub Connect で public Action へ自動接続するか、actions-syncで必要な Action を GHES へ持ち込む

GHES には主要な公式 Action が同梱されていますが、リリース時点のスナップショットです。完全閉域では Action 本体だけでなく、setup-*が取得するツールキャッシュ、パッケージマネージャー、コンテナレジストリなども社内へミラーする必要があります。

GitHub Codespaces

Codespaces は GitHub が Cloud 上でホストする開発環境です。GHES 3.21 のドキュメントには Codespaces の機能ページがなく、GHES リポジトリから Codespaces を作る構成は確認できません。

GHES で同様の体験が必要なら、Dev Container を使ったローカル開発環境、社内 VDI、または別の自己ホスト型開発環境を検討することになります。

Dependabot

GHES でも Dependabot alerts / updates を利用できますが、構成要件があります。

• AlertsはGitHub ConnectでGitHub Advisory Databaseを同期する
• Advisory Database の脆弱性データは GHES へ同期され、コード自体は GitHub へアップロードされない
• UpdatesはGitHub Actionsと専用self-hosted runnerが必要
• package registry から更新版を取得する network 経路が必要
• 限定的またはインターネットなしの環境では private registry 向け構成を使える
• GHES 3.21 の公式ドキュメントでは、clustering を使う GHES で Dependabot updates はサポートされない

GitHub Code Security / Secret Protection

GHES でも、Code Security と Secret Protection の主要機能を利用できます。

• Code scanning / CodeQL CLI
• Dependency review
• Dependabotのカスタム自動トリアージルール
• Secret scanning
• Push protection
• Custom pattern
• Security overview

ただし GitHub.com で先に登場した AI 支援や新しい管理画面が、同じタイミングで GHES に入るとは限りません。導入時は「GitHub Enterprise」という製品名だけで判断せず、利用予定の GHES バージョンを選択した公式ドキュメントに、その機能ページが存在するかを確認するのが確実です。

GitHub Connectと完全閉域のトレードオフ

GHES を選ぶときは、単に「Cloud かオンプレミスか」ではなく、機能ごとに 完全閉域、限定的な outbound 接続、Cloud 併用 のどれを許可するかを整理する必要があります。

8. 導入前に確認したいこと

最後に、要件整理で使えそうな質問を並べます。

データとネットワーク

• コードだけを自社環境に置きたいのか、telemetry、ライセンス情報、AI prompt も外へ出せないのか
• GitHub.com への outbound HTTPS を許可できるか
• package registry、container registry、LLM endpoint への通信を許可できるか
• Cloud 側へリポジトリをミラーすることは許可されるか

IDとライセンス

• GHES は built-in / LDAP / SAML のどれで認証するか
• SAML + SCIM でユーザーとグループを IdP から管理するか
• Copilot 用 Cloud アカウントは個人アカウントか EMU か
• GHES ユーザーと Copilot ユーザーを email / employee ID などでどう対応付けるか
• GitHub Connect のライセンス重複排除に使うメールアドレスと verified domain をどう管理するか
• Copilot ライセンスを Enterprise 直下の Team へ配るか、Organization へ委譲するか

Copilot

• inline suggestion、Chat、Edit Mode、Agent Mode、CLI、Copilot cloud agent のどこまで許可するか
• コンテンツ除外が適用されない機能を許可できるか
• 利用 model、public code matching、MCP、web search をどのレベルで強制するか
• Copilot traffic の allowlist、proxy、TLS inspection をどう設計するか
• prompt、response、telemetry の data processing 条件を法務・security 部門が承認できるか

運用

• GHES のアップグレード、バックアップ、HA、DR、容量、証明書を誰が運用するか
• self-hosted runner を誰がパッチ適用・監視・廃棄するか
• Actions、ツールキャッシュ、パッケージ、コンテナイメージをどうミラーするか
• GHES の監査ログと Cloud 側の Copilot 監査ログ・利用メトリクスを、どの ID で突き合わせるか
• 既存の GitHub App、OAuth App、webhook、Marketplace 連携が GHES の hostname とネットワークで動作するか
• GitHub.com より遅れて提供される機能をどのように評価・展開するか

まとめ

今回調べてみて、GitHub Enterprise Cloud と GitHub Enterprise Server の違いは、「コードをどこに置くか」だけではないとあらためて感じました。

GHES では、リポジトリ、Issue、Pull Request、ユーザーを自社管理の環境へ置けます。SAML + SCIM を使えば、EMU ではないものの、IdP から GHES アカウントの作成・停止や Team membership も管理できます。

一方で Copilot は Cloud サービスです。GHES 利用者が Copilot を使う場合、GHES アカウントとは別に Cloud 側アカウントとライセンスが必要になり、ポリシーも Cloud 側 Enterprise / Organization で管理します。

Organization を使ったポリシー分離は可能ですが、Copilot 専用 Enterprise なら Organization なしで直接ライセンスを配る選択肢もあります。複数 Organization にまたがるポリシーは、多くの場合「もっとも制限の弱い設定」が適用されるため、強い統制が必要な項目は Enterprise レベルで固定した方がよさそうです。

また、IDE の Agent Mode と Copilot cloud agent は別物です。IDE の Agent Mode はローカルにクローンした GHES リポジトリでも利用できますが、Copilot cloud agent は Cloud 側 Organization、リポジトリ、GitHub Actions を前提とします。Copilot cloud agent を使うためにコードを Cloud へ複製するなら、そもそもの「オンプレミスへ閉じたい」という要件と衝突します。

GHES を選ぶときは、次の 3 段階で考えると整理しやすそうです。

1. 絶対に外へ出せないデータは何か
2. 限定的な outbound 接続を許可できる機能は何か
3. Cloud 併用を許可して得たい開発体験は何か

GHES を選ぶことは「Cloud を使わない」ことではなく、自社で所有する境界と、Cloud サービスへ委ねる境界を、機能ごとに明示的に決めることなのだと思います。

公式情報源

GitHub Enterprise ServerとID管理

• GitHub’s plans
• Identity and access management fundamentals
• About user provisioning with SCIM on GitHub Enterprise Server
• Configuring SCIM provisioning to manage users
• About GitHub Connect
• Enabling automatic user license sync for your enterprise

GitHub Copilot

• About enterprise accounts for Copilot Business
• Setting up a dedicated enterprise for GitHub Copilot Business
• Setting up GitHub Copilot for your enterprise
• GitHub Copilot policies for enterprises and organizations
• Feature availability when GitHub Copilot policies conflict in organizations
• Supported surfaces for GitHub Copilot policies
• Content exclusion for GitHub Copilot
• About GitHub Copilot cloud agent

ActionsとSecurity

• Getting started with GitHub Actions for GitHub Enterprise Server
• About using actions in your enterprise
• Manually syncing actions from GitHub.com
• Enabling Dependabot for your enterprise
• GitHub security features