GitHub Enterprise入門：エンタープライズアカウントで実現する組織運営の最適化

1. はじめに

GitHubを使った開発は今や多くの企業で標準となっていますが、組織が成長するにつれて、アクセス管理やポリシーの統制、コスト配分などの課題が顕在化してきます。本記事では、GitHub Enterpriseのエンタープライズアカウントを活用することで、これらの課題をどのように解決できるのかを、実践的な観点から解説します。

2. エンタープライズアカウントとは

エンタープライズアカウントは、GitHub上での企業管理の中心点となる機能です。複数の組織を一元的に管理し、アクセス制御、ポリシー設定、請求管理などを統合的に行えます。

従来の組織単位での管理と異なり、エンタープライズアカウントでは「トップダウン」のアプローチで、企業全体のガバナンスを効率的に実現できます。

3. エンタープライズアカウントの構成要素

3.1. ユーザー管理

エンタープライズアカウントでは、ユーザーを以下の2つの方法で管理できます。

既存のGitHubアカウントでの招待（Personal accounts）

ユーザーが持っている個人アカウントを利用
複数の個人アカウントを持っている場合は統合を推奨
GitHub FreeまたはGitHub Proを使用
無制限の公開・非公開リポジトリを所有可能

管理対象ユーザーアカウント（Managed user accounts）

IdP（Identity Provider）から専用アカウントをプロビジョニング
アカウントの詳細と設定の一部がエンタープライズによって管理される
プライベートリポジトリは作成できるが、パブリックコンテンツの作成や企業外のリポジトリへの貢献はできない
エンタープライズが所有する組織やリポジトリにアクセスするには、管理対象アカウントでサインインが必要

デフォルトでは、ほとんどのユーザーはエンタープライズで非管理者ロールを持ちますが、エンタープライズロールを付与することで、特定の設定へのアクセスを提供できます。

3.2. 組織構造

エンタープライズアカウントは1つ以上の組織を含むことができます。組織には上限があり、最大100,000個のリポジトリを所有できます。それ以上のリポジトリが必要な場合は、追加の組織を作成できます。

組織は実際の開発作業が行われる場所で、以下の要素を持ちます。

リポジトリ、ディスカッション、プロジェクト
独自の監査ログ、ポリシー、チーム
組織レベルでの管理機能

エンタープライズアカウントから組織を一貫して管理できる一方で、ポリシー設定などの一部の決定は組織管理者に委任することも可能です。これにより、全体的なガバナンスを保ちながら、各組織の特性に応じた柔軟な運用が実現できます。

3.3. チーム管理

チームはユーザーをグループ化し、組織、ロール、ライセンスへのアクセスを大規模に管理するための仕組みです。チームは組織のメンバーのみで構成され、外部コラボレーターはチームに参加できません。

3.3.1. チームの種類

可視チーム（Visible teams）

すべての組織メンバーが閲覧・@メンション可能

秘密チーム（Secret teams）

チームメンバーとオーナー権限を持つ人のみ閲覧可能
外部パートナーやクライアント関連など、機密性の高いチームに最適
ネストできない（親チームや子チームを持てない）

3.3.2. ネスト構造による階層管理

チームは階層構造（ネスト）を持つことができます。これにより、企業やグループの組織構造をGitHub上で表現できます。

重要な特性として、子チームは親チームのアクセス権限を継承します。例えば、エンジニアリングチームにあるリポジトリへの書き込み権限を付与すると、その配下のすべての子チーム（アプリケーション開発、認証基盤チームなど）も自動的に同じ権限を取得します。

親チームを@メンションすると、その親チームのメンバーと全子チームのメンバーに通知が送られます。一方、階層の下位のチームを@メンションした場合は、そのチームのみが通知を受け取ります。

また、チームはIdPグループと同期できるため、企業の中央アイデンティティ管理システムからチームメンバーシップを直接管理できます。

3.3.3. ネスト構造を導入する際の準備

既存の組織にネスト構造を導入する場合、以下の手順を推奨します。

既存チームのリポジトリアクセス権限を監査
各チームのリポジトリアクセス権限を調整し、親チームを設定
必要な新チームを作成し、親チームを選択してリポジトリアクセスを付与
メンバーを各チームに直接追加

階層の上位では、親チームとすべての子チームのメンバーにとって安全なリポジトリアクセス権限を付与します。階層の下位に移動するにつれて、より機密性の高いリポジトリへの細かいアクセス権限を子チームに付与できます。

3.4. リポジトリ管理

リポジトリは組織が所有し、ソースコードや社内ドキュメントなどをホストします。開発者が通常作業を行う場所で、GitHub Actionsワークフローなどのコードに近い機能や管理オプションを含んでいます。

エンタープライズアカウントから直接アクセスはできませんが、カスタムプロパティを使用することで、共通の特性を持つすべてのリポジトリに同じガバナンスモデルを適用できます。

例えば、本番コードを含むリポジトリを誰も削除できないようにする、といったルールをエンタープライズレベルで設定可能です。

3.5. コストセンター

コストセンターは、GitHub機能への支出を特定のビジネスユニットに割り当てるための機能です。

主な利点：

請求構造を組織アカウントとは独立して定義可能
ビジネスユニットごとに支出を追跡・管理
Azure経由の請求の場合、複数のAzureサブスクリプションに使用量を配分可能

これにより、組織アカウントは関連する作業やガバナンス要件でグループ化し、コスト管理は別の軸で行うことができます。

3.6. ポリシー管理

エンタープライズ管理者は、企業全体での作業方法を統制するポリシーを設定できます。

3.6.1. 主要なポリシー

IPアローリスト

アクセス元のIPアドレスを制限
セキュリティ要件の高い企業での利用に適している

Copilotポリシー

利用可能な機能やモデルを管理
チームごとに異なる設定を適用可能

リポジトリポリシー

リポジトリの削除、名前変更、転送などの操作を制御
重要なリポジトリの保護に有効

ルールセット

重要なブランチとのやり取り方法を定義
プルリクエストとレビューの必須化
ブランチ保護ルールの統一

3.7. GitHub Apps

GitHub Appsは、エンタープライズ全体で自動化を安全に管理する仕組みです。専用のアイデンティティとスコープ付きトークンを提供し、外部スクリプトやワークフローの実行を可能にします。

エンタープライズアカウントでは以下が可能です。

アプリ登録を定義し、組織間で一貫したプロセスを自動化
エンタープライズアカウント自体にアクションを実行するアプリのインストール（組織の作成など）
ユーザーによるGitHub Appsの認証管理（IDEへのサインイン、CIプロバイダーとの連携など）

4. 認証とアクセス管理

4.1. シングルサインオン（SSO）

エンタープライズでSSOを有効にすると、以下の動作となります。

SSO保護されたリソースにアクセスしようとすると、GitHubが組織のIdPにリダイレクト
IdPで認証後、GitHubに戻り組織のリソースにアクセス可能
認証セッションは通常24時間（IdPの設定による）

エンタープライズ内のSSO保護された内部リソース（リポジトリ、プロジェクト、パッケージなど）へのアクセスには、エンタープライズ内のどの組織に対してもSSOセッションが必要です。これにより、ユーザーが各組織に個別に参加することなく、エンタープライズ全体でコードと作業を共有できます。

4.1.1. 外部アイデンティティのリンク

IdPアカウントで認証してGitHubに戻ると、GitHubはあなたのGitHub個人アカウントと外部アイデンティティの間にリンクを記録します。このリンクされたアイデンティティは以下の目的で使用されます。

組織のメンバーシップの検証
組織とエンタープライズの設定に応じた、所属する組織やチームの判定

各GitHubアカウントは、1つの組織につき1つの外部アイデンティティにのみリンクできます。同様に、各外部アイデンティティは組織内の1つのGitHubアカウントにのみリンクできます。

すでに別のGitHubアカウントにリンクされている外部アイデンティティでサインインしようとすると、エラーメッセージが表示されます。この状況は、組織内で作業するために新しいGitHubアカウントを使用しようとしている場合に発生する可能性があります。

4.1.2. パブリックリポジトリへのアクセス

パブリックリポジトリについては、特定の方法でのアクセスにはIdP認証が不要です。

リポジトリの概要ページとファイル内容の閲覧
リポジトリのフォーク
Gitによる読み取り操作（リポジトリのクローンなど）

ただし、Issue、プルリクエスト、プロジェクト、リリースの閲覧など、パブリックリポジトリへのその他のアクセスには認証が必要です。

外部コラボレーターには、SSO認証は不要です。

4.2. 二要素認証（2FA）

組織のセキュリティを強化するため、2FAの管理機能が提供されています。

組織内のユーザーが2FAを有効にしているか確認
組織で2FAを必須にする設定
ボットやサービスアカウントでの2FA管理

2FAを必須化することで、不正アクセスのリスクを大幅に低減できます。

4.3. APIとコマンドラインでのアクセス

APIやGitをコマンドラインで使用して保護されたコンテンツにアクセスする場合、以下が必要です。

認証済みの個人アクセストークン（PAT）をHTTPS経由で使用
認証済みのSSHキーを使用

個人アクセストークンやSSHキーがない場合は、作成する必要があります。

新規または既存のトークン、SSHキーをSSOを使用または強制する組織で使用するには、そのトークンまたはSSHキーを組織用に認証する必要があります。

4.4. OAuth/GitHub Appsとの連携

SSOを使用または強制する組織にアクセスするには、OAuth appまたはGitHub Appを認証するたびにアクティブなSSOセッションが必要です。

エンタープライズまたは組織のオーナーがSSOを有効化または強制した後、初めてSSOで認証した後は、組織へのアクセスを許可していた既存のOAuth appやGitHub Appを再認証する必要があります。

5. 組織内の役割（ロール）

5.1. 役割の概要

GitHubでアクション（リポジトリでのプルリクエスト作成や組織の請求設定の変更など）を実行するには、関連するアカウントまたはリソースへの十分なアクセス権が必要です。このアクセスは権限によって制御されます。

権限は特定のアクションを実行する能力です。例えば、Issueを削除する能力は権限です。役割は、個人やチームに割り当てることができる権限のセットです。

GitHubには以下の3つのレベルの役割があります。

リポジトリレベルの役割: 組織メンバー、外部コラボレーター、チームにリポジトリへのさまざまなレベルのアクセスを付与
チームレベルの役割: チームを管理する権限を付与（チームメンテナ役割など）
組織レベルの役割: 組織とその設定を管理するための権限セット

5.2. 主要な組織レベルの役割

5.2.1. Organization Owners（組織オーナー）

組織の完全な管理者権限を持つ
所有権の継続性のため、最低2人は必要
すべての設定とリソースを管理可能
組織アカウントの削除を含むすべての操作が可能

5.2.2. Organization Members（組織メンバー）

デフォルトの非管理者役割
リポジトリやプロジェクトの作成が可能（設定により制限可能）
日常的な開発作業を行う
デフォルトで多くの権限を持つ

5.2.3. Organization Moderators（組織モデレーター）

メンバー権限に加え、以下が可能
- 非メンバーコントリビューターのブロック/ブロック解除
- インタラクション制限の設定
- パブリックリポジトリでのコメント非表示化
- すべてのコミット、プルリクエスト、Issueでのコメント非表示化

5.2.4. Billing Managers（請求マネージャー）

支払い情報などの請求設定を管理
通常のメンバーに請求リソースへのアクセスを与えずに管理できる
財務チームとの連携に有用
アカウントのスポンサーシップ管理も可能

5.2.5. Security Managers（セキュリティマネージャー）

セキュリティマネージャーは、組織オーナーが組織内の任意のメンバーまたはチームに割り当てることができる組織レベルの役割です。適用されると、以下の権限が付与されます。

セキュリティアラートの表示と設定管理
全リポジトリへの読み取り権限
セキュリティ機能の組織全体での管理
Dependabotアラートとセキュリティアップデートの管理
セキュリティ概要の表示
Secret scanningのバイパスリクエストと却下リクエストのレビュー・管理
Code scanningの却下リクエストのレビュー・管理

組織にセキュリティチームがある場合、セキュリティマネージャー役割を使用して、チームメンバーに組織への最小限のアクセス権を付与できます。

5.2.6. GitHub App Managers（アプリマネージャー）

デフォルトでは、組織オーナーのみが組織が所有するGitHub App登録の設定を管理できます。組織が所有するGitHub App登録を管理できる追加のユーザーまたはチームを許可するため、オーナーはGitHub Appマネージャー権限を付与できます。

組織内のユーザーまたはチームをGitHub Appマネージャーとして指定すると、組織が所有する一部またはすべてのGitHub App登録の設定を管理するアクセス権を付与できます。ただし、GitHub Appマネージャー役割では、ユーザーに組織へのGitHub Appのインストール/アンインストールのアクセス権は付与されません。

5.2.7. Outside Collaborators（外部コラボレーター）

組織のデータを保護しながらリポジトリへのアクセスを許可するため、外部コラボレーターを追加できます。外部コラボレーターは、1つ以上の組織リポジトリへのアクセス権を持つが、組織のメンバーではない人（コンサルタントや一時的な従業員など）です。

エンタープライズで管理対象ユーザーアカウントを使用している場合、外部コラボレーター役割は「リポジトリコラボレーター」と呼ばれます。リポジトリコラボレーターは、IdPからプロビジョニングされた管理対象ユーザーアカウントを持つエンタープライズの一部である必要があります。

一般的に、外部コラボレーターとリポジトリコラボレーターの役割は同等ですが、以下の違いがあります。

リポジトリコラボレーターに対して2FA（二要素認証）を強制できない（Enterprise Managed Usersでは利用不可）
リポジトリコラボレーターはSSO要件をバイパスできない（エンタープライズレベルで管理）
リポジトリコラボレーターは、エンタープライズのIPアローリストポリシーとIdPの条件付きアクセスポリシーの対象となるが、組織のIPアローリストポリシーの対象にはならない

5.3. 事前定義された組織役割

事前定義された組織役割は、すべての組織でデフォルトで利用可能な役割です。自分で作成する必要はありません。これらは、組織を管理できる組織権限と、組織内のすべてのリポジトリに適用されるリポジトリ権限の両方を含むことができます。

現在の事前定義役割のセット：

All-repository read: 全リポジトリへの読み取りアクセス
All-repository write: 全リポジトリへの書き込みアクセス
All-repository triage: 全リポジトリへのトリアージアクセス
All-repository maintain: 全リポジトリへのメンテナンスアクセス
All-repository admin: 全リポジトリへの管理者アクセス
CI/CD admin: Actionsポリシー、ランナー、ランナーグループ、ホステッドコンピュートネットワーク設定、シークレット、変数、使用量メトリクスの管理権限
Security manager: セキュリティポリシー、セキュリティアラート、セキュリティ設定の管理権限
App Manager: 組織内のすべてのGitHub Appの作成、編集、削除権限

これらの役割により、細かい権限設定を個別に行うことなく、一般的なユースケースに対応できます。

より細かい制御が必要な場合は、カスタム組織役割を作成することも可能です。

5.4. 主要な役割の権限比較

以下は、各役割が持つ主要な権限の一覧です（一部抜粋）。

権限	オーナー	メンバー	モデレーター	請求マネージャー	セキュリティマネージャー
リポジトリの作成	✓	✓	✓	✗	✓
請求情報の表示・編集	✓	✗	✗	✓	✗
組織への招待	✓	✗	✗	✗	✗
メンバーの削除	✓	✗	✗	✗	✗
監査ログへのアクセス	✓	✗	✗	✗	✗
チームの作成	✓	✓	✓	✗	✓
全コメントの非表示化	✓	✗	✓	✗	✗
非メンバーのブロック	✓	✗	✓	✗	✗
セキュリティ設定の管理	✓	✗	✗	✗	✓
セキュリティ概要の表示	✓	✗	✗	✗	✓
SAML SSOの有効化	✓	✗	✗	✗	✗
リポジトリの転送	✓	✗	✗	✗	✗
全リポジトリの読み取り	✓	✗	✗	✗	✓
Dependabotアラートの受信	✓	✗	✗	✗	✓

6. セキュリティとコンプライアンス

6.1. 監査ログ

組織内のアクティビティを継続的に監視するため、詳細な監査ログが提供されます。

組織内のすべてのアクションを記録
アクセストークンによって実行されたイベントの特定
IPアドレスの表示
特定のイベントタイプの詳細記録
コンプライアンスレポートへのアクセス

監査ログは、セキュリティインシデントの調査や、コンプライアンス要件の充足に不可欠です。

6.2. セキュリティ設定

組織全体で以下のセキュリティ機能を管理できます。

セキュリティと分析の設定

組織全体のセキュリティ機能の有効化・無効化
脆弱性のあるdependencyに関するDependabotアラート
Dependabotセキュリティアップデート

アクセス制御

許可されたIPアドレスの管理
メール通知の制限（検証済みドメインのみに制限）

認証とアイデンティティ

SAML SSOの有効化と強制
SSHアクセスの証明書管理
ユーザーのSAMLアクセス管理

7. アカウント統合のベストプラクティス

複数の個人アカウントを持っている場合（仕事用と個人用など）、統合することを推奨します。多くの人は、オープンソースプロジェクトと有給の仕事の両方を含め、すべての作業に1つの個人アカウントを使用しています。

Enterprise Managed Usersを使用すると、エンタープライズがIdPを通じてメンバーに固有の個人アカウントをプロビジョニングできます。その他のユースケースでは、個人用と仕事用の両方のリポジトリを管理するために、1つの個人アカウントのみを使用することを推奨します。

7.1. 統合手順

リポジトリの転送
- 削除予定のアカウントから、残したいアカウントへすべてのリポジトリを転送
- Issue、プルリクエスト、Wikiも一緒に転送される
- 転送後、リポジトリが保持するアカウントに存在することを確認

ローカルのリモートURL更新

# リモートURLの確認
git remote -v

# リモートURLの変更
git remote set-url origin https://github.com/新アカウント名/リポジトリ名.git

不要なアカウントの削除
- 使わなくなったアカウントを削除
過去のコミットの紐付け
- 新しいアカウントに、コミット時に使用していたメールアドレスを追加
- これにより過去のコミットが新アカウントに紐付けられ、コントリビューションとしてカウントされる

SAML SSOを使用する組織のメンバーであっても、個人アカウントでサインインし、そのアカウントが組織のIdPのアイデンティティにリンクされます。

8. まとめ

8.1. エンタープライズアカウントの主な利点

一元管理

複数の組織を一箇所から管理
ポリシーの統一的な適用
請求とコストの可視化
100,000リポジトリまでの組織を複数管理可能

スケーラビリティ

組織の成長に合わせた柔軟な構造
チームの階層管理とアクセス権限の継承
リポジトリへのガバナンスの自動適用
IdPとの同期による自動メンバー管理

セキュリティ

SSO/2FAによる強固な認証
詳細な監査ログとコンプライアンスレポート
IPアドレス制限とアクセス制御
Secret scanningとCode scanningの一元管理

委任と自律性のバランス

エンタープライズレベルでの統制
組織管理者への適切な権限委任
チームごとの柔軟な運用
事前定義された役割によるシンプルな権限管理

8.2. 導入時の考慮事項

エンタープライズアカウントは、単なる管理機能の集合ではありません。企業全体のソフトウェア開発を効率化し、セキュリティを強化しながら、各チームの自律性を保つための基盤です。

組織の規模が大きくなるにつれて、これらの機能の価値はより明確になります。適切に設計されたエンタープライズアカウントの構造は、技術的な負債を減らし、開発チームが本来の仕事に集中できる環境を提供します。

特に以下の点に注意することで、効果的な運用が可能になります。

チームの階層構造を事前に設計し、アクセス権限の継承を計画的に利用する
秘密チームとネスト構造は併用できないため、機密性の高いチームの管理方法を検討する
外部コラボレーターとリポジトリコラボレーターの違いを理解し、適切に使い分ける
監査ログとセキュリティアラートを定期的にレビューする体制を整える
コストセンターを活用し、ビジネスユニットごとの支出を可視化する