JAEN
tech#github#enterprise#data-residency#emu#copilot#governance

GitHub Enterprise の Data Residency・EMU・Organization 設計（2026年版）

公開 👁 —
GitHub Enterprise の Data Residency・EMU・Organization 設計（2026年版）

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

きっかけは、GitHub Copilot の使い方についてあらためて考えたことでした。

Copilot を GitHub Enterprise Cloud + Enterprise Managed Users（EMU） の環境で使ってもらうと、単なる生成 AI ツールとしてだけでなく、企業の中での生産活動を、よりガバナンスを効かせてセキュアに 行えるようになります。会社が管理するアカウントの上で、アクセス権・ポリシー・データの保存場所まで統制しながら AI を使える。これは、他の生成 AI ツールより一歩進んだ使い方だと感じています。

ところが、いざ「では GitHub Enterprise Cloud をどう構築するのが推奨なのか」を調べると、まとまった情報が意外と少ないのが実情でした。特に次のような論点です。

この記事では、GitHub Enterprise Cloud を軸に、これらの論点を公式ドキュメントの記述にもとづいてざっくり整理します。「Copilot をガバナンスの効いた環境で活かす」ための土台づくり、という視点で読んでもらえるとうれしいです。

💡 GitHub のプラン・価格・購入方法そのもの（Free / Team / Enterprise や、Copilot・Advanced Security の課金など）は、前回の記事「GitHub 製品・機能とライセンスの全体像（2026年版）」にまとめています。本記事はその続編として、選んだ Enterprise プランを「どう構築・運用するのが推奨か」に踏み込みます。

目次

まず全体像: Enterprise の「形」を分解する

「GitHub Enterprise」と一口に言っても、実際には次のように枝分かれします。まずこの地図を持っておくと、以降の話が整理しやすくなります。

そして、認証・アカウント管理の観点で Enterprise Managed Users（EMU） という選択肢が横断的に関わってきます。

観点選択肢ざっくり言うと
ホスティングServer / Cloud自社で持つか、GitHub に任せるか
データ保存場所既定（米国）/ Data Residency保存リージョンを選べるか
アカウント管理個人アカウント / Enterprise Managed Usersユーザーが自分の GitHub アカウントを使うか、会社が払い出すか

ポイントは、この 3 つが完全に独立ではなく、依存関係があることです。特に後述のとおり、Data Residency を使うなら EMU が必須になります。

1. Data Residency（データレジデンシー）とは

GitHub は既定では、GitHub.com のデータを 米国内 に保存します。これに対して GitHub Enterprise Cloud with data residency を採用すると、会社のコードやデータを 保存する地域を選べる ようになります。エンタープライズは GHE.com の専用サブドメイン上でホストされます。

対応リージョン

公式ドキュメント上、現時点で選べるリージョンは次のとおりです。

📌 補足: 「日本リージョンはまだ来ていない」という印象を持っている方もいるかもしれません。現在の公式ドキュメントでは 日本も対応リージョンとして掲載 されています。ただし後述する Copilot のリージョン内処理は、まだ日本に来ていない ので、そこは分けて考える必要があります。GitHub は今後さらに対応リージョンを拡大する予定としています。

「利用する／しない」で何が変わるか

Data Residency を 使わない（通常の GitHub.com Enterprise）場合、コードやデータは基本的に米国に保存されます。使う 場合は、選んだリージョン内に保存されるデータの範囲が明確になります。

項目Data Residency なし（既定）Data Residency あり（GHE.com）
アクセス URLgithub.comSUBDOMAIN.ghe.com（専用サブドメイン）
データ保存場所既定で米国選んだリージョン内
アカウント管理個人アカウント or EMU を選択可能EMU が必須
コミュニティGitHub.com 全体とつながるエンタープライズ内に隔離される

リージョン内に保存されるもの / 外に出る可能性があるもの

Data Residency を使っても「すべてのデータが 100% 域内に閉じる」わけではありません。ここは正確に理解しておくべき点です。

リージョン内に保存される（公式に明記）

リージョン外に保存される場合がある（公式に明記）

つまり Data Residency は「コードとユーザーデータを選んだ地域に置く」仕組みであり、テレメトリや課金管理情報などの一部は域外で扱われる前提です。コンプライアンス要件と突き合わせるときは、この線引きを必ず確認してください。

URL やエコシステムの違いにも注意

GHE.com は URL 体系が GitHub.com と異なるため、既存の自動化・連携をそのまま持ち込めない場合があります。代表例です。

移行時は「URL 依存の自動化」「Marketplace 前提のワークフロー」を洗い出しておくと安全です。

2. Enterprise Managed Users（EMU）とは

Enterprise Managed Users（EMU） は、ユーザーの アカウントのライフサイクルと認証を、会社の IdP（ID 管理システム）から一元管理 する仕組みです。

個人アカウント方式との違い

GitHub Enterprise Cloud では、エンタープライズ作成前に「個人アカウント方式」か「EMU 方式」かを選びます。両者の違いはおおむね次のとおりです。

観点個人アカウント方式EMU 方式
アカウントユーザー自身の GitHub.com 個人アカウント会社が IdP から払い出す管理アカウント
認証任意で SAML を追加（個人アカウントに紐付け）IdP（SAML / OIDC）必須の真の SSO
プロビジョニング不可（SCIM は「アクセス」付与のみ）SCIM でアカウントごと管理
ユーザー名・メール本人が変更可能IdP が制御（本人は変更不可）
公開リポジトリ / Gist作成可能作成不可
外部コラボレーション可能エンタープライズ内に限定

EMU の「強い制約」を理解する

EMU は情報漏えいを防ぐために、意図的に強い制約をかけています。

このため GitHub 自身も「EMU はすべての顧客にとって最適とは限らない」と明言しています。OSS への貢献や社外コラボが日常業務に組み込まれている組織では、個人アカウント方式のほうが合うこともあります。

パートナー IdP と「混在」の落とし穴

EMU は Entra ID・Okta・PingFederate などの パートナー IdP と「舗装された道（paved-path）」で統合できます。GitHub の推奨は明確です。

認証とプロビジョニングは、単一のパートナー IdP で揃える。

複数システムを混在させることもできますが、GitHub のサポート対象外になりやすく、注意が必要です。特に Okta と Entra ID の組み合わせ（SSO と SCIM をまたぐ構成）は明確に非対応で、プロビジョニング時にエラーになります。

Data Residency との関係（重要）

ここが混同されやすいポイントです。

つまり EMU は Data Residency の前提条件ですが、その逆は成り立ちません。

3. Organization 設計 — GitHub 社の推奨

エンタープライズの中で、リポジトリを どの単位で Organization に束ねるか は、後から変えにくい設計判断です。GitHub 社は公式ドキュメントでいくつかの原則を示しています。

原則 1: Organization は「仕事」か「ガバナンス」で束ねる

Organization の使い方には大きく 2 つのモデルがあります。

原則 2: Organization は「意図を持って」作る（少数から始める）

GitHub 社の言葉を借りると、「Organization は追加するより削除するほうが難しい」。むやみに数を増やすと弊害があります。

推奨は 少数から始めて、運用しながら必要に応じて増やす こと。エンタープライズアカウントの管理機能を使えば、複数 Organization にまたがってポリシー適用・アクセス管理・自動化ができるため、「無理に 1 つの巨大 Organization に詰め込む」必要も、「最初から細かく割る」必要もありません。レガシーな Organization の整理も定期的に見直すべき、とされています。

原則 3: 人は「Team」で束ね、できれば IdP と同期する

アクセスと権限をスケールさせる最良の方法は Team です。

原則 4: 個人所有ではなく Organization 所有リポジトリで協働する

GitHub 社は Organization 所有のリポジトリでの協働 を推奨しています。より高度なセキュリティ・管理機能が使え、メンバーの入れ替わりがあってもアクセスが維持されるためです。あわせて innersource（社内 OSS 的な再利用文化）を活用すると、チーム間の重複作業を減らせます。

4. 補足: Copilot を「リージョン内」で使う

ここが今回いちばん整理したかったところです。「AI は使いたいが、コードやプロンプトを国外に出したくない」という要件への回答が、GitHub Copilot with data residency です。

何ができるのか

GitHub Enterprise Cloud with data residency を使っている場合、「Restrict Copilot to data residency compliant models」ポリシー を有効にすると、Copilot の 推論処理と関連データを指定リージョン内に閉じ込められます。

前述のとおり、Copilot のデータは 既定ではリージョン外 に保存されます。このポリシーを有効化して初めて、推論・プロンプト・レスポンス・ログ・テレメトリが域内に留まる ようになります。

対応リージョンは US と EU のみ（← ここが Data Residency 全体とは別）

重要な注意点です。Copilot のリージョン内処理が対応しているのは、現時点で US と EU の 2 つだけ です。

GHE.com の Data Residency 自体は US / EU / Australia / Japan に対応していますが、Copilot の域内推論はまだ日本・オーストラリアには来ていない、というズレがあります。GitHub は近い将来の拡大を予定しているとしています。

機能対応リージョン
GHE.com（データ保存の域内化）US / EU / Australia / Japan
Copilot の域内推論（compliant models）US / EU のみ

そのほか押さえておく点

補足: 日本で「自国リージョンの LLM」を使いたいなら（BYOK / Custom models）

Copilot のリージョン内処理はまだ日本に来ていません。それでも「推論に使う LLM 自体は日本国内に置きたい」という要件には、BYOK（Bring Your Own Key） という別の道があります。たとえば Microsoft Foundry に日本リージョンで用意した LLM を Copilot につなぐ、といった使い方です。対応プロバイダーには Anthropic・AWS Bedrock・Google AI Studio・Microsoft Foundry・OpenAI・xAI などがあり、ファインチューニング済みモデルも利用できます（本機能はパブリックプレビュー）。

ただし、ここで データの流れが 2 通りに分かれる 点に注意が必要です。GitHub の BYOK は、名前は同じでも性質の異なる 2 つの仕組みに分かれています。

仕組み鍵の扱いGitHub の Copilot API（プロキシ）を主な使い方
Local BYOKクライアント側（ローカル保存）通らない（Copilot API 依存を外す）個人がクライアントに直接設定。エアギャップ環境など
Enterprise BYOK（Custom models）サーバー側（Enterprise / Org 設定）通る（Copilot API がモデルを配信）管理者が組織横断で集中管理

⚠️ 注意: これは Data Residency の正式機能ではありません。「推論に使うモデルを自分で選ぶ」仕組みであって、Copilot 全体（テレメトリなど）のデータ保存場所を域内に固定するものではありません。「モデルの所在」と「Copilot データの所在」は別問題として切り分けて判断してください。特に Enterprise BYOK は GitHub の Copilot API を経由するため、コンプライアンス要件によってはこの経路の有無が重要になります。

5. 補足: ネットワーク制限が厳しい環境向けの参照先

外部接続をファイアウォールや DNS フィルタリングで厳しく絞っている企業では、GitHub の各サービスが通信するドメイン・IP を許可リスト（allowlist）に登録する必要があります。具体的な許可先は環境やバージョンで変わるため本記事では列挙しませんが、GitHub は公式に参照先を用意しています。

allowlist が必要なのは Copilot だけではありません。GitHub 全体・製品ごとに参照ドキュメントがあり、その大元は Meta API です。

GitHub 全体・横断（大元）

製品・環境別

参照先の構造

Meta API (api.github.com/meta) ← 全ての元データ（IP レンジ）
   ├─ Copilot allowlist reference ← Copilot 向けに整形した派生ページ
   ├─ Actions runner IP ranges
   ├─ restricted network 向けのドメイン許可
   └─ GHE.com は別レンジ（Network details for GHE.com）

⚠️ どのページも「一覧は網羅的ではない / IP 直指定は非推奨、定期的に監視を」と明記しています。allowlist を組む場合も、可能なら IP 直書きではなく Meta API を定期取得して更新する運用 が推奨です。

6. 導入時の選び方

論点が多いので、要件から逆引きできる形に整理します。

要件選択の目安
コード・ユーザーデータを特定リージョンに保存したいGitHub Enterprise Cloud with data residency（GHE.com）
日本国内にデータを置きたいData Residency の Japan リージョン
Copilot の推論も国外に出したくないCopilot データレジデンシー（現状 US / EU のみ。日本は今後待ち）
日本国内の LLM を Copilot の推論に使いたいBYOK（Microsoft Foundry を日本リージョンで。Local BYOK なら Copilot API を経由しない）
社員に個人アカウントを使わせず、会社で払い出したいEnterprise Managed Users（EMU）
社外 OSS への貢献や外部コラボが日常的にある個人アカウント方式（EMU の制約が業務を妨げる可能性）
ポリシーや機密度でリポジトリを隔離したいガバナンス単位で Organization を分ける
まず小さく始めたい少数の Organization から始め、必要に応じて追加
アクセス管理をスケールさせたいTeam を中心に、IdP グループと同期
外部接続を FW / DNS で厳しく絞っている通信先を allowlist に登録（大元は Meta API。Copilot は Copilot allowlist reference、GHE.com は別レンジ）

Data Residency を採用するなら EMU が必須 で、EMU には公開リポジトリ・外部コラボの制約が伴います。「データを域内に置く」メリットと「開発体験の制約」はセットで評価するのがおすすめです。

まとめ

GitHub Enterprise の導入設計は、大きく次の 3 層で考えると整理しやすくなります。

  1. どこに置くか（Data Residency）: 既定は米国。GHE.com なら US / EU / Australia / Japan から選べる。ただしテレメトリや課金情報など一部は域外で扱われる
  2. 誰が管理するか（EMU）: 会社が IdP から払い出す EMU か、個人アカウント方式か。Data Residency を使うなら EMU 必須。EMU は公開・外部コラボに強い制約がある
  3. どう束ねるか（Organization）: 「仕事」か「ガバナンス」でまとめ、意図を持って少数から始め、人は Team と IdP 同期で管理する

そして AI については、Copilot のリージョン内処理（US / EU のみ） という別レイヤーがあり、GHE.com の対応リージョンとは範囲が異なる点に注意が必要です。日本にデータを置けても、Copilot の推論まで国内で完結させられるのは（現時点では）まだ、ということです。

要件（コンプライアンス・開発体験・AI 活用）を並べたうえで、この 3 層 + Copilot レイヤーを組み合わせて設計するのが、遠回りのようで確実だと感じました。

公式情報源