1. はじめに
技術本部 コーポレートシステム部 Corporate Architectureグループの吉山です。
最初に所属先のコーポレートシステム部門について簡単に紹介させてください。コーポレートシステム部は、情報システム部門（いわゆる情シス）にあたります。部のミッションとして「EXをシンプルにする」ということを掲げています。EXとはEmployee Experience（従業員体験）のことです。
今回は、当社で実施したGitHub TeamからGitHub Enterprise Cloud（EMU）への移行プロジェクトについてブログにまとめます。
2024年12月から始まった移行プロジェクトは、約9ヶ月を経て2025年夏に概ね完了しました。元々1000リポジトリ程度が存在していたOrganizationから、700リポジトリほどを新しいEnterprise環境へ移行しています。この移行により、デバイス認証によるアクセス制御の強化や、GHAS（GitHub Advanced Security）導入に向けた基盤整備が実現できました。
本記事では、なぜEnterprise化に踏み切ったのか、移行で直面した課題とその解決策、そして今後の展望について振り返ります。同じような移行を検討されている方の参考になれば幸いです。
- 1. はじめに
- 2. 背景と課題
- 3. 取り組みの全体像
- 4. 移行の実際：苦労した点と乗り越え方
- 5. 移行して良かったこと
- 6. プロジェクト全体を通しての振り返り
- 7. 今後の展開
- 8. おわりに
2. 背景と課題
前提：組織とリポジトリの規模感
当社ではGitHub Teamプランを利用しており、eightcardというOrganization配下に1000リポジトリ程度が存在していました。利用ユーザーは500アカウント以上にのぼり、複数の事業部・プロダクトが一つのOrganizationを共有している状態でした。
なぜこのタイミングでEnterprise化したのか
GitHub Teamでも日々の開発業務は回っていましたが、いくつかの課題が顕在化してきました。
課題1：セキュリティ要件の高まり
会社の成長とともに、社会的に求められる責任も変化してきました。
企業としての責任を果たすためには、当社が保有する情報資産を適切に保護し、万が一のインシデント発生時には調査・説明できる体制を整えることが必要です。ソースコードもその情報資産の一つであり、保護対象として例外ではありません。
また、近年はアカウントを起点とした侵害が増加しています。攻撃動向の分析や、当社で毎年実施しているペネトレーションテストの結果からも、アカウントが狙われやすいことが明らかになっていました。
こうした背景から、当社ではアカウントを守るための取り組みを全社的に進めています。Oktaを中心としたゼロトラスト環境の構築や端末認証（Device Trust）の導入、SIEM基盤の整備によるログの一元管理などがその一例です。詳しくは以下の記事をご覧ください。
Oktaを中心とした「セキュリティと利便性を両立させる」Sansanのゼロトラスト - Speaker Deck
GitHubも例外ではなく、この方針に沿った対応が求められていました。しかし、GitHub Teamプランでは貸与端末以外からのアクセス制御ができず、監査ログの一元管理も困難でした。
加えて、開発者サイドからもEnterprise機能への要望がありました。例えば、GitHub Actionsでの静的IPが利用可能になれば、IP制限のある外部サービスとの連携が容易になります。
課題2：アカウント管理の複雑化
アカウント管理のフローにも課題がありました。
入社時は、各自が個人でGitHubアカウントを作成し、Organizationへの招待を依頼するという流れでした。退職時は手動での削除依頼が必要です。全社のIdPであるOktaとの統合も実現できておらず、管理が属人化し、工数も増加していました。
決断：GitHub Enterprise Cloud（EMU）への移行
これらの課題を踏まえ、GitHub Enterprise Cloudへの移行を決断しました。
移行にあたっては、EMU（Enterprise Managed Users）を採用しています。EMUを選択した理由は、全社的なOkta統合方針との整合性、デバイス認証によるアクセス制御の実現、そしてアカウント管理運用の負荷軽減のためです。
3. 取り組みの全体像
移行の全体スケジュール
移行プロジェクトは、大きく3つのフェーズに分けて進めました。
以降、各フェーズで何を行ったかを説明します。
検討・計画フェーズ：EMUかnon-EMUか
最初の大きな意思決定は、EMU（Enterprise Managed Users）とnon-EMUのどちらを採用するかでした。
non-EMUとは、個人のGitHubアカウントをEnterprise Organizationに招待する従来型の運用方式です。一方、EMUはIdPで管理されたアカウントのみを使用する方式で、より厳密な統制が可能になります。
| 観点 | EMU | non-EMU |
|---|---|---|
| アカウント管理 | IdP（Okta）で一元管理。SCIMによる自動プロビジョニング | 個人アカウントベース。SAML SSO + OrganizationレベルでのSCIMも可能だが手動管理も併存 |
| SCIMの適用レベル | Enterpriseレベルで一元管理 | Organizationレベルのみ。複数Orgがある場合は各Orgごとに設定が必要 |
| Device Trust | IdP側のDevice Trustと連携可能 | SAML認証は可能だが、Device Trustの連携は限定的 |
| 既存Organization | 新規作成が必要。既存Orgは招待不可 | 既存OrgをそのままEnterprise配下に追加可能 |
| 移行コスト | 全リポジトリの移行が必要。CI/CD設定の再構築も発生 | Organizationがそのまま使えるため移行コストは低い |
| 外部コラボレーション | EMUアカウントでは外部Orgへの参加不可。OSS活動は別アカウントが必要 | 個人アカウントのため制約なし |
| アカウント棚卸し | 不要（IdP連携で自動管理） | OrganizationレベルでのSCIM利用時は自動化可能。手動管理の場合は定期的な棚卸し運用が必要 |
EMUは移行コストが高い一方で、セキュリティ面のメリットと運用負荷の低減が見込めます。non-EMUは移行が容易ですが、アカウント管理の課題が残り続けます。
なお、当社の場合は単一のOrganization（eightcard）を使用していたため、技術的にはnon-EMUでOrganizationレベルのSCIMを使うことも可能でした。しかし、将来的な複数Organizationへの拡張やEnterpriseレベルでの統一的な管理を考慮し、EMUを選択しています。
検証・準備フェーズ：移行基盤の整備
EMUへの移行を決定した後、検証環境でのテストと移行基盤の構築を進めました。
この時期に、移行プロジェクトに関わるメンバーがapplication-managementシステムを構築してくれました。これはTerraformでチーム・権限をIaC管理するための基盤で、移行後の運用を支える重要なコンポーネントとなっています。
また、GitHub Enterprise Importerを使った移行手順の検証や、移行前後のチェックリストの整備もこのフェーズで行いました。
移行フェーズ：段階的なリポジトリ移行
準備が整った後、実際のリポジトリ移行を開始しました。約1000リポジトリを一斉に移行することは現実的ではないため、プロダクト・チーム単位でグルーピングし、週次ペースで段階的に進めました。
4. 移行の実際：苦労した点と乗り越え方
4.1 EMU採用の意思決定
問題
セクション3で示したEMUとnon-EMUの比較において、どちらを採用するかはプロジェクト初期の大きな悩みどころでした。
セキュリティ的にはEMUが望ましい一方で、non-EMUと比べると制約が多く、既存Organizationを招待できないため移行のハードルも高くなります。さらに、この設定はEnterprise作成時に決める必要があり、作成後に変更することはできません。今後の運用まで見据えた上で判断する必要がありました。
解決策
判断のポイントは、目先の移行コストだけでなく、運用全体を見据えることでした。
non-EMUでもSAML認証の強制は可能なので、セキュリティ面のメリットはある程度得られます。しかし、アカウントの棚卸し運用は残り続けます。EMUであればOktaとのSCIM連携により、この運用負荷を恒久的に解消できます。
当社では、全社的なOkta統合方針との整合性、デバイス認証によるアクセス制御の実現、そして恒久的な運用負荷の低減を重視し、EMUを採用することを決定しました。
移行に伴うユーザー影響については、事前にドキュメントにまとめて全体に周知しました。当社には英語圏のメンバーもいるため、日本語と英語の両方でドキュメントを用意し、「何が変わるのか」「何に気をつける必要があるのか」を明確に伝えました。これにより、移行時の混乱を最小限に抑えることができました。
4.2 大量リポジトリの段階的移行
問題
旧Organizationには約1000リポジトリが存在しており、これらすべてが移行対象の候補でした。リポジトリのサイズによっては移行に数時間かかるものもあります。そのため、全リポジトリを一斉に移行することは現実的ではありませんでした。コードフリーズ期間が長期化し、影響範囲も大きくなってしまいます。
解決策
まず、移行に先立ってリポジトリの棚卸しを実施しました。長期間更新のないリポジトリや、すでに役目を終えたプロジェクトなどを精査し、結果的に移行対象は約700リポジトリに絞り込むことができました。
その上で、プロダクト・チーム単位でグルーピングし、週次ペースで段階的に移行を進めました。依存関係の少ないリポジトリから優先的に着手しています。
移行作業は金曜夜〜週末に実施しました。業務影響を最小化しつつ、万が一問題が発生しても週明けまでに解決する時間を確保するためです。進捗管理にはGoogleスプレッドシートを使用し、各リポジトリのステータスを可視化しました。移行状況のアナウンスや問い合わせ対応は、専用のSlackチャンネルで行っています。
具体的な移行手順：GitHub Enterprise Importer（GEI）の活用
リポジトリの移行にはGitHub公式の移行ツールであるGitHub Enterprise Importer（GEI）を使用しました。以下のような簡単なスクリプトを用意し、対象リポジトリをまとめて移行しています。
#!/bin/bash repos=( "<repository-name-1>" "<repository-name-2>" # 以下、対象リポジトリを追加 ) for i in "${repos[@]}"; do gh gei migrate-repo \ --queue-only \ --github-source-org "eightcard" \ --source-repo $i \ --github-target-org "sansaninc" \ --target-repo $i \ --target-repo-visibility internal done
移行の進捗確認は、gh gei wait-for-migrationコマンドの実行や移行先Organizationを時々チェックすることで行いました。Importer稼働中はリポジトリのVisibilityがPrivateになり、完了するとInternalに変わるため、これである程度判別できます。
GEI利用時の注意点
GEIを使う上での注意点もいくつかありました。
- リポジトリのサイズが大きいと失敗しやすい、または移行できない場合がある
- Importer自体の障害が発生することもあるため、GitHub Statusは要チェック（例：GitHub Enterprise Importer delays）
- Importerがエラーを出していないのに移行がうまくいっていないケースもあった（原因は特定できず）
移行がうまくいったかどうかは、移行後にテストPRを作成して確認するのがおすすめです。うまくいっていない場合、PRのマージができないなどの形で発覚します。失敗した場合は、リポジトリを削除して再度Importすれば問題ありません。
GEIの詳細な使い方や制約事項については、公式ドキュメントを参照してください。
4.3 外部サービス連携の再設定
問題
EMUへの移行に伴い、OrganizationのURLなどが変更になります。これにより、外部サービスとの連携設定をすべて見直す必要がありました。
https://github.com/eightcard/any-project-repo.git ↓ URLに含まれるOrganization名が変更 https://github.com/sansaninc/any-project-repo.git
特に厄介だったのは以下の点です。
- Secrets / Variablesの移行不可
- GitHub Enterprise ImporterではリポジトリのSecretsやVariablesは移行されません。手動での再設定が必要です
- CI/CDパイプラインの停止リスク
- CircleCIなど外部ツールとの連携は、Organization単位で設定されているものも多く、再インテグレーションが必要でした
- AWSなどOIDCでGitHubと繋げているツール群について、受け入れるsubクレームの変更などが必要でした
解決策
まず、移行前後のチェックリストを標準化しました。リポジトリごとに必要な作業を明確にし、各チームが自律的に対応できるようにしています。
外部サービスについては、事前にIntegrationの可否や契約面の確認を行いました。複数Organizationとの連携が可能なサービスは、移行担当側で事前に設定を済ませておくことで、切り替え時の作業を最小化しています。一方、1テナント1連携のサービスについては、別テナントの用意や契約調整など、地道な対応が必要でした。
4.4 チーム・権限設定の初期化
問題
GitHub Enterprise Importerでリポジトリを移行しても、チーム構成やメンバーシップは引き継がれません。移行直後は、誰もリポジトリへの権限を持っていない状態になります。
旧Organizationのチーム構成をそのまま再現するにしても、500人以上のユーザーと多数のチームを手動で設定するのは現実的ではありません。
解決策
この課題に対応するため、TerraformによるGitHubチーム管理の仕組みを構築しました。application-managementと呼ばれるシステムで、チームとリポジトリの権限マトリクスをコードとして一元管理しています。
メンバーシップについては、Okta Groupとの自動同期を実現しました。SCIMを活用したプロビジョニングにより、メンバーの追加・削除はOkta側で管理されます。入退社時の対応も自動化され、手動での招待・削除作業は不要になりました。
また、各部門へのオーナーシップ委譲も意識しました。CODEOWNERSを活用し、ディレクトリ単位で管理権限を分散しています。これにより、部門ごとに自律的な運用が可能になりました。
5. 移行して良かったこと
約9ヶ月にわたる移行プロジェクトでしたが、振り返ってみると多くのメリットがありました。ここでは、移行によって得られた成果を整理します。
5.1 セキュリティの向上
最も大きな成果は、セキュリティレベルの向上です。
EMUとOktaの連携により、Device TrustをGitHubへのアクセスに適用できるようになりました。これにより、貸与端末以外からのアクセスを完全に遮断し、私物端末からのコード持ち出しリスクを大幅に低減しています。
また、監査ログの一元管理も実現しました。Enterprise配下での統合ログにより、インシデント発生時の調査やコンプライアンス対応がしやすくなっています。
5.2 アカウント管理の自動化
OktaとのSCIM連携により、GitHubアカウントのライフサイクル管理が自動化されました。
入社時は、Oktaでアカウントが払い出されると、application-management用リポジトリへのPR作成を経てGitHubへ自動的にプロビジョニングされます。退職時は、Oktaアカウントの無効化と同時にGitHubアカウントも即時無効化されます。
これにより、手動での招待・削除作業が不要になり、運用工数が大幅に削減されました。アカウントの棚卸し運用も不要になり、管理の属人化という課題も解消しています。
5.3 IaCによる統制強化
TerraformによるGitHubリソース管理の仕組みを構築したことで、統制面でも大きな改善がありました。
チーム、リポジトリ、権限設定がすべてコード化されたことで、変更履歴の追跡が容易になりました。「誰が」「いつ」「何を」変更したかがPRの履歴として残るため、監査対応にも活用できます。
また、CODEOWNERSを活用した分散管理により、各部門が自律的に運用できる体制を整えました。リポジトリの設定変更のたびに特定のチームへ依頼する必要がなくなり、ボトルネックが解消されています。
これらのIaC基盤については、設計や運用の細かい工夫が多いため、本記事では概要の紹介に留めています。機会があれば、application-managementシステムにフォーカスした記事として、あらためて詳しく紹介できればと考えています。
5.4 今後の拡張性確保
Enterprise化により、今後のセキュリティ強化に向けた土台が整いました。
GHAS（GitHub Advanced Security）の導入がすでに決定しており、Secret ScanningやCode Scanningの全社展開に向けた準備を進めています。GitHub Teamプランでは実現できなかった施策が、ようやく着手できる状態になりました。
また、今回の移行を通じてアカウント管理の課題や理想像が明確になりました。現在は、Oktaを中心とした全社的なIdentity管理基盤を新たに構築することを検討しています。
6. プロジェクト全体を通しての振り返り
移行プロジェクトを振り返り、うまくいったことと、課題として残っていることを整理します。
うまくいったこと
段階的移行とコミュニケーション
週次バッチでの移行により、影響を局所化できたことが大きかったです。一度に全リポジトリを移行するのではなく、チーム単位で少しずつ進めたことで、問題が発生しても影響範囲を限定できました。
また、専用のSlackチャンネルでのリアルタイムな情報共有と、各チームの協力体制があったおかげで、移行作業自体は大きなトラブルなく進められました。
IaCによる管理基盤の確立
application-managementリポジトリによる一元管理の仕組みを構築できたことも、大きな成果でした。
Terraformでチーム・権限をコード管理することで、再現性の高い構成を実現しています。また、CODEOWNERSを活用して部門ごとにオーナーシップを分散させたことで、特定チームへの依存を減らすことができました。
組織横断での協力
今回の移行は、移行チームだけでなく、各プロダクトチームの協力があって成り立ったものです。
R&D部門では、移行に関する取り組みを別途ブログにまとめてくれています。
リポジトリの棚卸しや移行後の動作確認など、各チームにたくさん協力してもらいました。また、application-managementリポジトリの構築をはじめ、他のPJメンバーの協力にも支えられました。この場を借りて感謝を伝えたいと思います。
課題として残っていること
移行プロジェクトとしては完了しましたが、いくつかの課題が残っています。
一つは 運用組織の未確立 です。現在は移行プロジェクトに関わったメンバーで暫定的に対応していますが、継続的な改善を推進するための体制が必要です。
もう一つは GHAS導入 です。Enterprise化は完了しましたが、Secret ScanningやCode Scanningの全社展開はこれからです。
7. 今後の展開
移行プロジェクトは完了しましたが、これはゴールではなくスタートラインです。ここでは、今後取り組んでいく施策について紹介します。
7.1 GHAS（GitHub Advanced Security）の全社導入
Enterprise化により、GHASの導入が可能になりました。現在、全社展開に向けた準備を進めています。
特に注力しているのはCode Scanningの展開です。既存のコードベースに対してどのようにスキャンを適用していくか、検出された脆弱性にどう対応するかなど、全社的なポリシーの整備と合わせて進めていきます。
Secret Scanningについても、全リポジトリへの適用を計画しています。シークレットの漏洩は深刻なインシデントにつながるため、早期に検知できる体制を整えます。
7.2 開発者体験のさらなる向上
移行によって基盤は整いましたが、開発者にとっての使いやすさはまだ改善の余地があります。
今後はプラットフォームエンジニアリングの観点から、セルフサービス化を推進していきます。リポジトリの作成やチームの権限変更など、開発者が自律的に行える環境を整備することで、依頼ベースのボトルネックを解消していきたいと考えています。
また、コーポレートITとエンジニアリングの融合も意識しています。従来の情シス的な立ち位置から一歩踏み込み、より開発者に近い領域から支援できる体制を目指します。
7.3 新組織の組成
セクション6でも触れましたが、GitHub基盤の継続的な改善を推進するための組織体制が課題です。
そこで現在新たな組織の立ち上げを検討しています。GitHubに限らず、全社で利用しているツールのIdentity / Accountを一元管理するための基盤と組織を作っていく構想です。
ゼロベースで組織を作っていくフェーズだからこそ、一緒に挑戦してくれる仲間を募集しています。詳しくは次のセクションをご覧ください。
8. おわりに
今回のブログでは、GitHub TeamからGitHub Enterprise Cloud（EMU）への移行プロジェクトについて、その背景から実際の苦労、そして今後の展開までを振り返りました。
約9ヶ月、1000リポジトリを対象とした移行という大きなプロジェクトでしたが、多くのメンバーの協力のおかげで無事に完了することができました。改めて感謝します。
移行自体は完了しましたが、本当の意味での「GitHub Enterprise活用」はここからが本番です。GHASの全社展開、運用組織の構築、開発者体験のさらなる向上など、やるべきことはまだまだたくさんあります。
そして、これらを実現するには、一緒にこの基盤を育ててくれる仲間が必要です。
技術本部 コーポレートシステム部では、コーポレートエンジニア テックリードを募集しています。
このポジションでは、2000人を超える従業員の業務課題を解決する仕組みづくりに携わります。具体的には、現状の業務分析、SaaSの選定・改廃、新規システムやツールのアーキテクチャ設計・開発、システム間連携機能の実装などに取り組みます。
特に、この記事で紹介したような取り組みに興味をお持ちの方には、きっと楽しんでいただける環境だと思います。
- Oktaを中心としたIdentity / Account管理基盤の設計・運用
- Terraformなどを活用したIaCによる統制と自動化の推進
- GitHubなどを始めとする業務基盤となるSaaSの継続的な運用改善
- コーポレートITと開発組織の橋渡し役としてのプラットフォームづくり
もし興味を持って頂けたら、カジュアル面談でお話しできると嬉しいです。
