こんにちは。テックリードの丸山 @maruyamaworks です。
みなさん、GitHub は使っていますか？ GitHub は企業向けに 複数のプラン を提供していますが、ある程度の規模の会社であれば GitHub Enterprise を利用しているというケースも多いのではないかと思います。弊社もこれまで、GitHub Enterprise を利用していました。
GitHub Enterprise では、通常のクラウド環境 github.com だけではなく、自社で用意したサーバー（EC2 等）に GitHub をインストールして使う方式も選択することができます。これらを区別して、前者の方式を GitHub Enterprise Cloud、後者の方式を GitHub Enterprise Server と呼びます（本稿では、前者を GHEC、後者を GHES と表記します）。弊社はこれまで GHES 方式で利用してきましたが、このたび GHEC 方式への移行を行いました。この記事では、移行の経緯や移行方法、そして GHEC において重要なセキュリティ機能である Enterprise Managed Users (EMU) についてご紹介します。
なぜ GHEC へ移行したのか
弊社はこれまで、主にセキュリティ的な理由で GHES 方式を採用していました。GHES 方式では、サーバを自社で用意します（弊社では自前で EC2 を建てて運用していました）。そのため、通常のクラウド環境 github.com とはネットワーク的に完全に分離された環境になります（当然、ドメイン名も異なります）。また、アカウントの管理が github.com とは完全に分離されているため、外部の人間を意図せずチームに招待してしまうなどの事故が起こりにくいというメリットもあります。
ところが、GHES 方式にもいくつかの問題がありました。最も大きな問題は、GitHub Copilot が使えない ということです。GitHub Copilot を利用するには、GHEC 環境にアカウントを作成し、そのアカウントに対して Copilot シートを割り当てる必要があります。また、2025 年 10 月現在、GitHub Copilot code review や GitHub Copilot coding agent といった機能も、GHEC 環境でのみ利用可能です。
GitHub は Generative AI を活用したさまざまな開発支援機能を業界に先駆けてリリースしていますが、こういった機能を使うことができないのは非常にもったいないですし、我々も AI を活用して開発効率の改善や品質改善に取り組まなければ、あっという間に時代に取り残されてしまいます。また、EC2 を自分たちでメンテナンスしなければならない点も、少なからず負担となっていました。こうした背景から、GHEC への移行検討を開始しました。
Enterprise Managed Users (EMU) とは
これまでは主にセキュリティ的な理由で GHES 方式を採用していたため、GHEC 方式に移行することでセキュリティレベルが低下しないかという点が議論の焦点になりました。今回、弊社は GitHub が提供するセキュリティ機能である Enterprise Managed Users (EMU) を採用しました。
EMU とは、簡単に言えば「アカウントの管理体系を github.com から分離する機能」です。つまり、EMU が有効化された組織の配下にあるリポジトリには、その組織の IdP によって認証された組織内専用のアカウントでなければアクセスができません。組織内専用のアカウントは、逆に組織外のリポジトリに対しては操作ができません（読み取り専用アクセスになる）。通常の github.com のユーザーは、EMU が有効化された組織の配下にあるリポジトリに決してアクセスすることはできません。
EMU を採用するメリット
EMU を採用することで以下のメリットがあります。
1. GitHub アカウントを会社が管理できる
通常、github.com では個人が各自でアカウントを取得します。ユーザー名の命名規則などを強制できない場合、どのアカウントが誰なのかなど、管理上の問題が発生する恐れがあります。これに対し EMU では、会社側がアカウントを発行する形となるため、ガバナンスを効かせやすいメリットがあります。
2. GitHub 利用規約の問題をクリアできる
GitHub の 利用規約 では、個人が無料の GitHub アカウントを複数保持することは禁止されています。実はこの規約の解釈については情報が錯綜しており、私用と仕事用で使い分けている場合は問題ないとの報告 *1 もある一方、有償の Organization に参加していてもアカウント自体が無料であれば規約違反になるとの報告 *2 もあります。いずれにしても、EMU を有効化した場合、会社が発行するアカウントについてはこの規約の適用外となるため、利用規約に関する懸念を回避できます。
3. パブリックリポジトリを作成できない
EMU が有効化された組織では、パブリックリポジトリを作成することができないため、誤ってソースコードが公開、流出してしまうといった事故も起こりません。
4. 意図せず社外のユーザーを招待してしまうことがない
EMU が有効化された組織の配下にあるリポジトリにアクセスできるのは、その組織の IdP で認証されたアカウントだけです。つまり、リポジトリにユーザーを招待する場合、招待されるユーザーも組織の IdP で認証されている必要があります。この仕組みにより、意図せず外部の一般人を招待してしまうというリスクを回避できます。
EMU における考慮事項
EMU は非常に強力なセキュリティ機能であるため、導入にあたって考慮すべき点もあります。
例えば、前述した通り、EMU が有効化された組織の配下にあるリポジトリにアクセスするには、会社の IdP による認証が必須です。逆に言えば、協力会社など社外の開発者と共同で開発する場合、その協力会社の開発者用のアカウントを会社の IdP に作成する必要があることには注意が必要です。
その他の制限事項については、下記のドキュメントをご参照ください。
移行作業
移行作業は以下の流れで進めました。
EMU を有効化した Enterprise の作成
EMU の有効化は、Enterprise の作成時にしか設定できず、作成後に変更することはできません。そのため、まずは EMU が無効な既存の GHEC 環境（ほぼ全く使われていませんでした）とは別に EMU が有効な Enterprise を新たに作成し、契約の紐付け直しや GHES 環境との GitHub Connect を紐付け直す作業を行いました。
会社の IdP との SAML SSO 連携
EMU を使用する場合、外部 IdP との SAML SSO 連携が必須となります。弊社ではすでに利用している ID 基盤があったため、そちらと SAML SSO 連携の設定を行いました。
GitHub アカウントのプロビジョニング
EMU が有効化された環境では、GitHub アカウントを作成するために IdP 側から SCIM (System for Cross-domain Identity Management) プロトコルによりプロビジョニングを行う必要があります。つまり、GitHub の UI 上ではアカウントの発行等はできず、IdP 側での操作が必要になります。Okta や Microsoft Entra ID（旧 Azure AD）、AWS IAM Identity Center などが SCIM プロトコルをサポートしています。
会社の IdP が SCIM をサポートしていない場合は、SAML 認証用と SCIM プロビジョニング用でそれぞれ別の IdP を使うということも可能です（弊社はこの方式で運用しています）。
移行ツールによるデータの移行
GHES から GHEC へのデータ移行は、公式の移行ツールである GitHub Enterprise Importer（通称 GEI）を使用して実施しました。
今回は、Organization ごとに移行を実施しました。移行の具体的な手順としては、
- GHEC 側に移行先となる Organization を作成する
gh gei generate-scriptコマンドを実行して移行用のスクリプトを生成する- 上記コマンドで生成された PowerShell スクリプトを実行する
ただし、移行ツールにもいくつかの制限があり、以下のような制約があります。
- 40 GB を超えるリポジトリは移行できない（過去の履歴情報も含めた全体の合計）*3
- 400 MB を超えるファイルが含まれる（含まれていた）リポジトリは移行できない
これらの制約に引っかかったリポジトリについては、個別に対応を行いました。
マネキンの回収
突然「マネキン」という言葉が登場して驚かれるかもしれません。GHES と GHEC はそれぞれアカウントの管理体系が分離されているため、GHES から GHEC に issue や PR を移行すると、移行先の GHEC 側では、その issue や PR の作成者がどのアカウントとも紐づいていない状態（これを GitHub では「マネキン」の状態と呼びます）が発生します。マネキンの回収を行うことで、マネキンの ID を GHEC 側に実在するアカウントにマッピングすることができます。
マネキンの回収は GEI を使って行うことができます。手順は以下をご参照ください。
手作業での修正
移行ツールで移行できないデータの移行や、リポジトリの管理場所が変わることに起因して必要となるさまざまな切り替え作業については、手作業で行わざるを得ませんでした。
例えば…
- AWS CodePipeline や AWS CodeBuild の設定を変更
- GitHub Actions の YAML ファイルの書き換え（今回、GitHub Actions の runner も self-hosted runner から GitHub-hosted runner に移行したため、この作業が必要でした）
- GitHub Actions の Secrets や Variables の値は GEI では移行されないため手作業で移行
- GitHub Pages は GEI では移行されないので再度 publish が必要
- GitHub Packages は GEI では移行されないので再度 publish が必要
- （リポジトリではなく）Organization に紐づく Wiki は手動で移行が必要
実際の移行作業においては、このステップに最も時間を要しました。特に、リポジトリの数が多い Organization については、切り替えが完了するまでに 1〜2 ヶ月程度を要しました。
GitHub Copilot の活用
GHEC 方式に移行したことで、社内の開発者が GitHub Copilot を使用できる状態になりました。現在では、ほとんどの開発者が GitHub Copilot を日々の業務で活用しています。
GitHub Copilot の活用事例については、随時このブログでも発信していければと思っています。以前に公開したこちらの記事も GitHub Copilot の事例のひとつです。
まとめ
今回は、社内で使用していた GitHub をクラウドに移行した経緯と EMU について紹介しました。GHES から GHEC への移行は、事前調査や社内調整、移行ツールの制約や手作業での地道な移行など、決して簡単な道のりではありませんでしたが、EMU によるセキュリティの確保と GitHub Copilot をはじめとする最新の AI 機能の活用を両立できたことは、今後の開発生産性の向上において大きな一歩となったことは間違いありません。
PLAY では、GitHub Copilot に限らず、Claude Code や Gemini Code Assist などさまざまな開発支援系 AI を業務で活用できる体制が整っています。これからも、最新技術を積極的に取り入れながら、より良いプロダクト開発に挑戦し続けていきます。
最後になりますが、こういった技術的な取り組みに関心を持っていただけた方は、弊社の 採用サイト も是非ご覧ください。お待ちしております。
元の記事を確認する
