GitHub Enterprise Cloud オンボーディングガイド：エンタープライズ開発基盤の構築

GitHub Enterprise Cloudは、大規模組織の開発チームに強力な協働環境を提供します。本記事では、トライアルの開始から本格運用まで、体系的なオンボーディングプロセスを解説します。技術的な詳細を押さえながら、実践的なアプローチで進めていきましょう。

目次

エンタープライズの開始
組織とチームの構築
サポート体制の確立
ガバナンスとセキュリティ
GitHub Appsによる自動化
GitHub Actionsによるci/cd構築

1. エンタープライズの開始

1.1 エンタープライズタイプの選択

GitHub Enterprise Cloudには2つのエンタープライズタイプがあります。適切な選択が、その後の運用を大きく左右します。

Enterprise Managed Users（管理ユーザー）を選ぶべきケース:

ユーザー名やメールアドレスを含む、完全なアカウント管理が必要
SAML/OIDCによる真のSSO体験を提供したい
データ保存場所の選択が必要（データレジデンシー要件）
IdPとの「paved-path」統合を活用したい

Personal Accounts（個人アカウント）を選ぶべきケース:

ユーザーが既存のGitHubアカウントを使用できる柔軟性が必要
エンタープライズ外でのコラボレーションが頻繁に発生する
パブリックリポジトリ、Gists、GitHub Pagesサイトが必要
IdPの統合が複雑すぎる、または確立されたプロセスがない

重要な考慮事項:

Enterprise Managed Usersでは、パブリックコンテンツの作成やエンタープライズ外でのコラボレーションに制限があります
既存のエンタープライズからEnterprise Managed Usersへの移行には、新しいエンタープライズアカウントが必要です
データレジデンシーが必要な場合、Enterprise Managed Usersが必須となります

1.2 トライアルの設定

30日間のトライアル期間で、主要な機能を実際に検証できます。

トライアルに含まれる機能:

GitHub Enterprise Cloudのほとんどの機能
GitHub Copilot Business
GitHub Secret Protection and Code Security
エンタープライズアカウント（複数組織の管理）
最大50ライセンス

トライアルに含まれない機能:

GitHub Codespaces
GitHub Copilot Enterprise
GitHub Sponsors
有料Marketplaceアプリ
GitHub Connect
Git Large File Storage
GitHub Actionsの増加した分数、ジョブ同時実行数、大型ランナー

支払い方法について:

トライアル開始に支払い方法は不要です
Copilot Businessを試用する場合のみクレジットカードが必要ですが、トライアル期間中は課金されません

トライアル中の組織管理:

最大3つの新規組織を作成可能
既存組織を無制限に転送可能（ただし、無料または有料のMarketplaceアプリがない組織に限る）
転送された組織の請求はトライアル中一時停止されます

1.3 ユーザーの追加

エンタープライズタイプによって、ユーザー追加の方法が異なります。

Personal Accountsの場合:

Enterprise Managed Usersの場合:

SAML または OIDC で認証を設定
SCIM プロビジョニングを設定
IdPからユーザーをプロビジョニング

IdPがユーザーライフサイクル全体を管理します：

新規ユーザーアカウントのプロビジョニング
ユーザー名、プロファイルデータの管理
組織メンバーシップとリポジトリアクセスの制御
IdPでの認証が必須

1.4 請求の理解

GitHub Enterprise Cloudの新しい請求プラットフォームは、柔軟な管理を提供します。

月次請求に含まれるもの:

ライセンス数: エンタープライズ内のユニークユーザー数で決定
使用量課金: GitHub ActionsやCodespacesのプラン許容量を超えた分
追加機能: Copilot、Advanced Securityなどの追加ライセンス

支払い方法の選択肢:

クレジットカード
PayPal
Microsoft Azureサブスクリプション
インボイス払い（Salesチーム経由の契約の場合）

新しい請求プラットフォームの機能:

支出の見積もり
コストセンター作成による事業部門ごとの経費追跡
必要なライセンス分の柔軟な支払い

1.5 移行の計画

既存のDevOpsソリューションから移行する場合、計画的なアプローチが重要です。

移行の主要ステップ:

移行元の例:

GitHub Enterprise Server
Bitbucket Server
GitLab
その他のコードホスティングプラットフォーム

重要な推奨事項:

GitHub Actionsへの移行は、リポジトリ移行と同時に行わないでください。CI/CD移行は別のステップとして後日実行することで、移行プロセスがより管理しやすくなります。

2. 組織とチームの構築

2.1 組織構造のベストプラクティス

組織の構造は、開発者体験に直接影響します。

組織を使用する2つの主要モデル:

関連する作業プロジェクトでグループ化
- 特定のアプリケーションと関連サービスのリポジトリをまとめる
- チームが効果的にコミュニケーションし、異なるリポジトリ間で貢献できる
類似したガバナンス要件でグループ化
- 同様のポリシー、セキュリティ設定、アクセス制限が必要なリポジトリをまとめる
- 組織レベルで必要な設定を大規模に適用

組織作成の原則:

組織作成時の注意点:

追加は簡単ですが、削除は困難です
多数の組織に分割することのトレードオフを理解する
組織間では@メンション機能が使えません
複数組織にまたがる検索は複雑になります

2.2 組織の設定

トライアル中に組織を追加する方法は2つあります。

方法1: 新しい組織を作成

Enterprise Managed Usersを選択している場合、この方法のみ使用できます。

# 組織作成の手順
手順:
  1. プロフィール写真 → Enterprise
  2. Organizationsタブをクリック
  3. "New organization"をクリック
  4: 
    - 組織名を入力
    - オプション: organization ownerを招待
  5. "Create organization"で完了

制限:
  - トライアル中: 最大3つの新規組織
  - Enterprise owner が自動的に organization owner になる

方法2: 既存組織を招待

Personal Accountsを使用している場合に利用可能です。

他のエンタープライズに所属していない組織のみ招待可能
Organization ownersがメールで招待を受け取る
承認前であれば、招待のキャンセルまたは再送信が可能

2.3 ロールの理解と設計

ロールは、エンタープライズのあらゆるレベルでアクセスと権限を安全に管理します。

ロールの階層構造:

事前定義ロールとカスタムロールの比較:

特徴	事前定義ロール	カスタムロール
利用可能性	すべてのアカウント	作成が必要
権限範囲	事前定義された権限セット	選択可能なきめ細かい権限
柔軟性	固定	必要な権限のみを付与可能
例	Enterprise Owner, Billing Manager	監査ログ閲覧のみのロール

ロール設計の6ステップ:

利用可能なロールと権限を確認
- 事前定義のエンタープライズロール
- 事前定義の組織ロール
- カスタムエンタープライズロール（現在は限定的、今後拡張予定）
- カスタム組織ロール
アカウントごとに2人のオーナーを特定
- Enterprise ownersとOrganization ownersを決定
- 最低2人を推奨（1人だけだとアクセス不能のリスク）

管理業務のためのロールを特定

実践例：

タスク	ロールの例	目的
監査	カスタムロール	監査ログへのアクセスのみ、設定変更不可
認証	カスタムロール	IdP管理者がSSO設定を独立して管理
セキュリティ	Enterprise Security Manager	エンタープライズ全体のアラートとデータへアクセス

管理者以外の基本権限を特定

全メンバーに役立つ権限の例：
- 他のエンタープライズメンバーと管理者の閲覧
- 監査ログの閲覧（透明性向上のため）
アプリに作業を委任

GitHub Appsは、人間のロールと同様に機能します：
- 特定のタスク用のきめ細かい権限
- 特定のリポジトリとアカウントへのスコープアクセス
- 監査ログで追跡可能な独自のID
エージェントにタスクを割り当て

Copilot coding agentで頻繁なタスクを自動化：
- Markdownファイル（エージェントプロファイル）で定義
- 例：README作成、ユニットテスト生成

2.4 カスタムロールの作成

カスタムロールにより、企業のニーズに合わせた権限管理が可能になります。

エンタープライズカスタムロールの作成:

# エンタープライズカスタムロールの作成手順
権限の範囲:
  - 監査ログの閲覧
  - 組織の作成
  - その他のエンタープライズ設定のサブセット
  
注意事項: "GitHubは今後、利用可能な権限のリストを拡張予定"

作成手順:
  1. Enterprise → People → Enterprise roles
  2. Role management → Create custom role
  3: 
    name: "ロール名を入力"
    description: "説明を入力"
    type: "タイプを選択"
  4. Create role

組織カスタムロールの作成:

# 組織カスタムロールの作成手順
作成者: Enterprise owners
割り当て者: Organization owners
制限: エンタープライズあたり最大20個（各組織も別途20個作成可能）

作成手順:
  1. Enterprise → People → Organization roles
  2. Create custom role
  3:
    name: "ロール名を入力"
    description: "説明を入力"
    base_role: "ベースロールを選択"
    permissions: "追加権限を選択"
  4. Create role

2.5 エンタープライズチームの活用

エンタープライズチーム（パブリックプレビュー中）は、大規模なアクセスと権限管理を革新します。

チームの種類と特徴:

エンタープライズチームができること:

エンタープライズから直接Copilot Businessライセンスを受け取る
事前定義およびカスタムエンタープライズロールを割り当て
組織に追加され、組織管理者が追加のアクセスと権限を付与
ルールセットでバイパスアクセスを受け取る

現在サポートされていない機能:

組織内でのチーム名の@メンション
プルリクエストでのチームへのレビューリクエスト
プロジェクトボードへのチーム追加
Personal accountsでのTeam sync
CODEOWNERステータス
シークレットチーム、ネストされたチーム、チームメンテナー

制限:

1エンタープライズあたり最大2,500チーム
各チームに最大5,000ユーザー
各チームは最大1,000組織に割り当て可能

チーム作成の実践:

# エンタープライズチーム作成の手順
前提条件:
  - Enterprise owner または Organization owner 権限

手順:
  1. Enterprise → People → Enterprise teams
  2. Create Enterprise team
  3:
    name: "チーム名"
    description: "説明"
    organization_access: "組織へのアクセスを選択"
  4. Create Enterprise team

ユーザー追加の方法:
  手動追加:
    - Add members → ユーザー検索 → Add
  
  IdP同期: # Enterprise Managed Users のみ
    前提: "チームに手動割り当てユーザーがいないこと"
    手順:
      - Edit → Manage members → Identity provider group
      - Select group → Update team
    注意: "IdPグループが5,000ユーザーを超えると同期停止"
  
  API使用:
    - REST API endpoints for enterprise team memberships

IdP統合による自動管理:

Enterprise Managed Usersの場合、IdPグループとチームを同期できます：

2.6 ロールとチームの割り当て

効率的な権限管理のため、チームにロールを割り当てます。

割り当て可能なロールの種類:

1. App managers, Security managers, Custom rolesの割り当て:

# これらのロールはチームまたはユーザーに割り当て可能
注意: "Enterprise Security Managerロールはチームのみに割り当て可能"

手順:
  1. Enterprise → People → Enterprise roles
  2. Role assignments → Assign role
  3:
    target: "ユーザーまたはチームを選択"
    role: "ロールを選択"
  4. Assign role

権限変更の動作:
  Enterprise ownerが変更:
    - エンタープライズ内の組織によって自動承認
  
  App managerが変更:
    - App managerがOrganization ownerでもある組織で承認
    - 他の組織ではOrganization ownerが承認必要

2. Enterprise owners, Billing managers, Guest collaboratorsの割り当て:

これらは招待時またはIdPからのプロビジョニング時に設定されます。

3. 組織レベルのロール割り当て:

Enterprise ownersはエンタープライズ設定から組織レベルのロールを割り当てできません。Organization administratorが実施する必要があります。

2.7 インナーソースの実践

インナーソースは、オープンソース手法を内部開発に適用する実践です。

インナーソースの実装:

1. リポジトリを発見可能にする:

Internal visibility の設定:
  利点:
    - エンタープライズ内の任意の組織メンバーが閲覧可能
    - リポジトリ所有組織のメンバーである必要なし
  
  推奨: "機密情報を含まない限り、すべての従業員に見えるようにする"

ベース権限の設定:
  推奨: "最低でも Read ベース権限"
  効果:
    - すべての組織メンバーが任意のリポジトリを閲覧可能
    - 組織オーナーはチームで特定リポジトリの高いアクセスを付与

機密リポジトリの扱い:
  方法: "制限的なベース権限を持つ専用組織を設定"
  対象: "特定の少数のユーザーのみアクセス"

2. プロジェクトを文書化する:

文書化手段	用途	メリット
リポジトリREADME	プロジェクト説明	コードのように検索可能
組織README	組織レベルの概要	プロジェクトの場所を示す
エンタープライズREADME	全体像の提供	高レベルの概要
GitHub Pagesサイト	正式な文書	包括的なドキュメント
Wiki	協働文書作成	簡単に編集可能
リポジトリトピック	グループ化	検索性向上

3. 共有文化を構築する:

実践方法:
  Discussions:
    用途: "作業を他のチームに見えるようにする"
    効果: "チーム間のコミュニケーション促進"
  
  内部リポジトリ:
    共有内容:
      - Actions
      - 再利用可能なワークフロー
    参照方法: "エンタープライズ内の誰でも参照可能"
  
  GitHub Packages:
    用途: "再利用可能なコードの共有"
    利点: "セキュリティ機能の強化"
  
  テンプレートリポジトリ:
    用途: "共通テンプレートとフレームワーク"
    効果: "プロジェクトの素早い開始"

サポートモデル:
  推奨: "オープンソースプロジェクトと同様"
  要件:
    - 明確に定義されたメンテナーチーム
    - 異なるチームからの代表者を含む

4. 外部コラボレーターからコンテンツを保護する:

3. サポート体制の確立

3.1 サポートオプションの理解

GitHub Enterprise Cloudには、標準サポートとプレミアムサポートがあります。

Standard GitHub Support:

GitHub Enterpriseサブスクリプションに含まれる
大企業やチーム向けにカスタマイズされた包括的なサポートと管理機能

GitHub Premium Support:

有料の補足サポートサービスで、以下の特徴があります：

2つのプレミアムプラン:

機能	Premium plan	Premium Plus / Mission Critical Services plan
優先チケット処理	✓	✓
プレミアムコンテンツ	✓	✓
専任CRE	-	✓
四半期ヘルスチェック	-	✓
テクニカルアドバイザリー	-	✓
アップグレード支援	-	✓

3.2 サポートポータルの使用

GitHub Support portalは、エンタープライズサポートの中心です。

開始手順:

前提条件:
  1. Enterprise ownerの特定:
     role: "GitHub.com上のエンタープライズアカウントオーナー"
  
  2. 検証済みドメインの設定:
     目的: "エンタープライズの真正性を確認"
     手順: "ドメインの検証または承認"
  
  3. サポート権限を持つユーザーの追加:
     roles:
       - Enterprise owners (自動付与)
       - Billing managers (自動付与)
       - Support-entitled members (手動追加)

機能:
  - シングルサインオン(SSO): "GitHubアカウントに接続"
  - チケット管理: "閲覧、作成、コメント"

3.3 サポート権限の管理

サポート権限により、誰がサポートチケットを作成できるかを制御します。

サポート権限の追加:

前提条件:
  - ユーザーがエンタープライズ所有の組織のメンバーであること

制限:
  Premium plan: "最大20メンバー"
  Premium Plus plan: "最大40メンバー"

手順:
  1. Enterprise → Settings → Support
  2: 
    action: "検索バーで名前またはユーザー名を入力"
    result: "マッチリストから選択"
  3. "Add support entitlement"をクリック

注意: "権限追加後、GitHub Support portalからサインアウトして再度サインインが必要な場合がある"

権限削除:
  対象: "Enterprise ownerまたはBilling managerでないメンバー"
  方法: "手動削除"

4. ガバナンスとセキュリティ

4.1 エンタープライズポリシーの理解

ポリシーは、ビジネスルールと規制コンプライアンスを実施する単一管理ポイントです。

ポリシーの仕組み:

ポリシー例：Base permissions

設定オプション:
  option1:
    name: "ポリシーを強制しない"
    効果: "Organization ownersが組織のベース権限を設定可能"
  
  option2:
    name: "特定のレベルを強制"
    例: "Read を強制"
    効果: "すべての組織に Read ベース権限が適用される"

4.2 カスタムプロパティによるリポジトリ分類

カスタムプロパティは、リポジトリに情報を付加して管理を容易にします。

カスタムプロパティの特徴:

エンタープライズあたり最大100個のプロパティ定義
許可値リストは最大200項目
プライベート（リポジトリへの読み取り権限を持つ人のみ閲覧可能）

使用例:

プロパティ名	用途	例
compliance_framework	コンプライアンス分類	SOC2, HIPAA, PCI-DSS
data_sensitivity	データ機密性	public, internal, confidential, restricted
project_status	プロジェクト状態	active, maintenance, deprecated
team_owner	所有チーム	platform-team, security-team

カスタムプロパティの作成:

許可される文字:
  名前: "a-z, A-Z, 0-9, _, -, $, #"
  値: '「"」を除くすべての印刷可能なASCII文字'

作成手順:
  1. Enterprise → Policies → Custom properties
  2. New property
  3:
    name: "プロパティ名（最大75文字、スペース不可）"
    description: "説明"
    type: "タイプを選択"
    options:
      allow_repository_actors: "リポジトリアクターが設定可能"
      require_for_all: "すべてのリポジトリに必須"
      default_value: "デフォルト値"
  4. Save property

値の設定権限:
  Enterprise owners:
    - 必須プロパティのデフォルト値を設定
  
  Organization owners:
    - 組織内で、リポジトリ全体または個別に値を設定
    - カスタムプロパティ値でリポジトリを検索可能
  
  リポジトリアクセス権を持つユーザー:
    条件: "allow_repository_actorsが有効な場合"
    権限: "自分のリポジトリのプロパティ値を設定・更新"

4.3 リポジトリポリシーの定義

リポジトリポリシー（パブリックプレビュー中）は、リポジトリライフサイクルを管理します。

制限できる内容:

実用例:

例1_命名規則の強制:
  目的: "すべての新しいリポジトリでkebab-caseを使用"
  pattern: "^([a-z][a-z0-9]*)(-[a-z0-9]+)*$"
  効果: "my-repo-name は許可、MyRepoName は拒否"

例2_削除の制限:
  目的: "組織管理者以外によるリポジトリ削除を防止"
  設定:
    policy: "Restrict deletions"
    allow_list: ["Organization Admin"]

例3_パブリックリポジトリの制限:
  目的: "open source組織でのみパブリックリポジトリ作成を許可"
  設定:
    policy: "Restrict visibility"
    target_organizations: ["open-source"]
    allowed_visibilities: ["public"]

例4_可視性変更の防止:
  目的: "メタデータ損失を避けるため、パブリックからプライベートへの変更を防止"
  設定:
    policy: "Prevent visibility changes"
    from: "public"
    to: "private"

リポジトリポリシーの作成:

制限: "組織ごと、エンタープライズごとに最大75個のポリシーとルールセット"

作成手順:
  1. Enterprise → Policies → Repository
  2. New policy
  3:
    policy_name: "説明的な名前（例: Prevent public repos on production）"
    enforcement_status:
      - Disabled: "作成時に適用しない"
      - Active: "作成時に適用"
    allow_list: "このポリシーをバイパスできるロール"
    targets:
      organizations:
        - "すべての組織"
        - "既存組織の選択"
        - "動的リスト（fnmatch構文）"
      repositories:
        - "すべてのリポジトリ"
        - "カスタムプロパティによる動的リスト"
    policies: "含める制限を選択"
  4. Create

命名制限の設定:
  pattern_syntax: "正規表現（RE2構文）"
  validation: "Test pattern で検証可能"

委任バイパスの設定:

機能: "リポジトリポリシーの委任バイパス（パブリックプレビュー中）"

用途:
  - リポジトリの削除
  - 可視性の変更

仕組み:
  1:
    actor: "リポジトリ管理者"
    action: "変更リクエストを送信"
  2:
    actor: "指定されたレビュアーグループ"
    action: "承認または拒否"
  3:
    承認された場合: "変更が即座に完了"
    拒否された場合: "変更は行われないが、再リクエスト可能"

設定:
  1: "Enterprise ownersまたはOrganization ownersがバイパスリストを作成"
  2: "特定のロールとチーム（チームまたはリポジトリ管理者など）を含める"

4.4 ルールセットによるブランチ保護

ルールセットは、コードガバナンスポリシーをエンタープライズ全体に適用します。

ルールセットの種類:

適用状態の活用:

状態	動作	用途
Active	ルールセットが適用される	本番環境での使用
Evaluate	適用されないが、違反を監視	テストとモニタリング
Disabled	適用も評価もされない	一時的な無効化

Evaluateモードの活用:

推奨される使用方法:
  1. ルールセットをEvaluateモードで作成
  2. Rule Insightsページで影響を確認:
     - どのアクションがルールに違反するか
     - どのユーザー/チームが影響を受けるか
  3. 必要に応じてルールを調整
  4. Activeモードに切り替え

メリット:
  - 本番環境への影響なくテスト可能
  - チームへの事前通知と準備時間を提供
  - ルールの妥当性を検証

ルールセットの作成:

作成手順:
  1. Enterprise → Policies → Code
  2. New ruleset
  3:
    type:
      - "New branch ruleset: ブランチをターゲット"
      - "New tag ruleset: タグをターゲット"
  4:
    ruleset_name: "ルールセット名"
    enforcement_status: "Disabled/Evaluate/Active"
    targets: "対象組織とリポジトリ"
    rules: "適用するルール"
  5. Create

4.5 監査ログの活用

監査ログは、エンタープライズのアクティビティを追跡する強力なツールです。

監査ログの特徴:

過去180日間のイベントを保持
Gitイベントは7日間保持
デフォルトでは過去3か月のイベントを表示

監査ログエントリに含まれる情報:

基本情報:
  - エンタープライズまたは組織
  - アクションを実行したユーザー（アクター）
  - アクションの影響を受けたユーザー
  - 対象リポジトリ
  - 実行されたアクション
  - 発生国
  - 日時

認証情報:
  - SAML SSOとSCIM ID
  - Web UI外のアクションの認証方法
  - ソースIPアドレス（オプション）

エントリ形式:
  pattern: "カテゴリ.操作タイプ"
  例: "repo.create = repoカテゴリのcreate操作"

監査ログの使用方法:

代替手段：Webhooks:

Webhooksの利点:
  用途: "特定のイベントが発生したときの通知"
  効率: "APIポーリングより効率的"
  
  適切なユースケース:
    - リアルタイムのイベント通知が必要
    - 特定のイベントタイプのみ監視
    - 外部システムとの統合

監査ログの利点:
  用途: "包括的な履歴とコンプライアンス"
  
  適切なユースケース:
    - 過去のアクティビティの調査
    - コンプライアンスレポート
    - 詳細な分析

4.6 エンタープライズセキュリティ

GitHubは、コードの品質を向上・維持する多くのセキュリティ機能を提供します。

セキュリティ機能の階層:

セキュリティ機能の概要:

機能	説明	プラン
Dependency graph	依存関係の可視化	すべて
Dependabot alerts	脆弱性の通知	すべて
Code scanning	コードの脆弱性検出	Advanced Security
Secret scanning	認証情報の検出	Advanced Security
Dependency review	プルリクエストでの依存関係レビュー	Advanced Security

5. GitHub Appsによる自動化

5.1 エンタープライズアプリの作成

GitHub Appsは、エンタープライズレベルのリソースにアクセスし、ワークフローを自動化します。

エンタープライズアプリの特徴:

エンタープライズアカウント配下で作成
エンタープライズまたはエンタープライズ内の組織にのみインストール可能
エンタープライズメンバーのみが承認可能
ユーザーアカウントにはインストール不可

作成プロセス:

Step 1: GitHub Appの登録

登録方法:
  1. アプリの新規登録
  2. メンバーまたは組織からの移転

権限の管理:
  Enterprise owners:
    - アプリの権限をいつでも変更可能
  
  App managers:
    - アプリの設定と認証情報を管理
    - アプリのインストールは不可
  
  権限変更の承認:
    Enterprise ownerが変更:
      - エンタープライズ内の組織で自動承認
    
    App managerが変更:
      - App managerがOrganization ownerの組織でのみ承認
      - 他の組織ではOrganization ownerが承認必要

Step 2: コードの記述

実装例:
  quickstart: "GitHub Appsのクイックスタート"
  webhook_response: "Webhookイベントへの応答"
  login_button: "Login with GitHub ボタンの構築"
  cli_tool: "CLIツールの構築"
  github_actions: "GitHub Actionsワークフローでの認証済みAPIリクエスト"

ベストプラクティス:
  - 最小権限の原則に従う
  - エラーハンドリングを適切に実装
  - レート制限を考慮
  - セキュリティを最優先

Step 3: 承認またはインストール

承認が必要なアプリ:
  例: "Copilot extensions"
  動作:
    - エンタープライズ内のユーザーが承認
    - 組織内のリソースへのアクセスが可能
    - インストールされている場所のみアクセス可能

インストールが必要なアプリ:
  方法: "インストールリンクを提供"
  効果:
    - アプリがインストールされると組織のリソースにアクセス
    - Organization ownersがインストール

5.2 エンタープライズアプリのインストール

Enterprise-installed GitHub Apps（パブリックプレビュー中）は、エンタープライズアカウント自体を管理します。

Enterprise-installed GitHub Appsの特徴:

インストール要件:

必須条件:
  1: "GitHub Appがエンタープライズレベルの権限をリクエスト"
  2: "アプリはエンタープライズまたはエンタープライズ内の組織が所有"

制限:
  - "エンタープライズ外のアカウントが所有するアプリはインストール不可"

Enterprise-installed appsができること:

現在サポートされているAPI:
  - エンタープライズ内の組織のリスト表示と作成
  - エンタープライズ内のユーザー管理
  - 組織内のGitHub Appインストールの作成と管理
  - エンタープライズカスタムリポジトリプロパティの管理
  - エンタープライズSCIM APIの呼び出し

レート制限:
  基準: "GitHub Enterprise Cloud組織と同じ"
  適用: "インストールごと"
  例: "エンタープライズと2つの組織にインストール = 3つの独立したレート制限"

現在の制限事項:

項目	現状	今後の予定
APIサポート	限定的	拡張予定
Webhookサポート	未対応	組織/リポジトリレベルで使用
組織アクセス	付与されない	各組織に個別インストール必要

6. GitHub ActionsによるCI/CD構築

6.1 GitHub Actionsの基礎

GitHub Actionsは、ソフトウェア開発ワークフローのすべてのフェーズを自動化します。

主要コンポーネント:

1. イベント (Events):

リポジトリ内の特定のアクティビティでワークフロー実行をトリガー

イベント例:
  - pull_request: "プルリクエストの作成"
  - push: "リポジトリへのプッシュ"
  - issues: "イシューのオープン"
  - schedule: "定期実行"
  - workflow_dispatch: "手動実行"
  - repository_dispatch: "REST API経由"

2. ワークフロー (Workflows):

1つ以上のジョブを実行する設定可能な自動化プロセス

# .github/workflows/example.yml
name: "CI/CDパイプライン"

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: "依存関係のインストール"
        run: npm install
      - name: "テスト実行"
        run: npm test

3. ジョブ (Jobs):

同じランナー上で実行されるステップのセット

ジョブの特徴:
  - デフォルトで並列実行
  - 依存関係を設定可能（needs キーワード）
  - 同じランナー上でデータ共有が可能

例_並列ビルド:
  jobs:
    build-linux:
      runs-on: ubuntu-latest
    build-windows:
      runs-on: windows-latest
    build-macos:
      runs-on: macos-latest
    
    package:
      needs: [build-linux, build-windows, build-macos]
      runs-on: ubuntu-latest

4. アクション (Actions):

複雑だが頻繁に繰り返されるタスクを実行するカスタムアプリケーション

アクションの用途:
  - Gitリポジトリのプル
  - ビルド環境のセットアップ
  - クラウドプロバイダーへの認証

アクションの入手先:
  - GitHub Marketplace: "10,000以上のアクション"
  - 独自開発: "組織固有のニーズに対応"
  - 内部共有: "エンタープライズ内で再利用"

例_アクションの使用:
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: '20'
    - uses: actions/cache@v4
      with:
        path: ~/.npm
        key: npm-${{ hashFiles('**/package-lock.json') }}

5. ランナー (Runners):

ワークフローがトリガーされたときに実行するサーバー

GitHub-hosted runners:
  OS:
    - Ubuntu Linux
    - Microsoft Windows
    - macOS
  特徴:
    - GitHubが維持・アップグレード
    - 新しくプロビジョニングされた仮想マシン
    - larger runners も利用可能
  課金: "プランの許容量超過分"

Self-hosted runners:
  設定可能項目:
    - オペレーティングシステム
    - ハードウェア構成
    - ネットワーク設定
  追加レベル:
    - リポジトリレベル
    - 組織レベル
    - エンタープライズレベル
  課金: "無料"

6.2 GitHub Actionsのロールアウト計画

体系的なアプローチで、GitHub Actionsを段階的に導入します。

1. ガバナンスとコンプライアンス:

許可するアクションの決定:
  選択肢:
    - GitHub作成のアクションのみ
    - 検証済みクリエイターのアクション
    - 特定のアクションリスト
  
  設定レベル:
    - リポジトリレベル
    - 組織レベル
    - エンタープライズレベル

OIDC + 再利用可能なワークフロー:
  利点: "クラウドロールに基づいて信頼条件を定義"
  効果: "一貫したデプロイメントの強制"

監査ログ:
  保持期間: "180日間"
  延長が必要な場合: "GitHub外へのエクスポートとストレージを計画"

カスタム組織ロール:
  用途: "CI/CDパイプラインの設定へのアクセス管理"
  原則: "最小権限"

2. セキュリティ:

ワークフローとリポジトリのセキュリティ強化:
  計画: "優良なセキュリティプラクティスを実施"
  推奨: "セキュリティ評価済みのワークフローの再利用"

シークレット管理:
  保存場所:
    - GitHub: "リポジトリまたは組織レベル"
    - クラウドプロバイダー
  
  制限:
    environment: "本番、テストなど特定の環境"
    approval: "機密性の高い環境には手動承認保護"

サードパーティアクション:
  リスク: "大きなリスクが存在"
  対策:
    - 内部ガイドラインの作成
    - アクションを完全なコミットSHAにピン留め
    - セキュリティレビュー

プライベートネットワーキング:
  方法: "Azure VNETでGitHub-hosted runnersを使用"
  利点:
    - GitHub管理のインフラストラクチャ
    - ランナーのネットワーキングポリシーを完全制御

3. インナーソーシング:

エンタープライズ全体でのアクション共有:
  方法:
    - 内部リポジトリにアクションを保存
    - 他のリポジトリのワークフローへのアクセスを許可
  範囲: "同じ組織またはエンタープライズ内の任意の組織"

再利用可能なワークフロー:
  利点:
    - 正確な重複を回避
    - よく設計され、テスト済みのワークフローを使用
    - ベストプラクティスの促進

ワークフローテンプレート:
  用途: "新しいワークフローの出発点"
  効果:
    - 開発者の時間を節約
    - エンタープライズ全体の一貫性

4. リソース管理:

Self-hosted runnersの決定事項:

マシンタイプ:
  物理マシン:
    注意: "前のジョブの残骸が残る"
  
  仮想マシン:
    推奨: "各ジョブで新しいイメージを使用、またはジョブ後にクリーンアップ"
  
  コンテナ:
    注意: "ランナーの自動更新でコンテナがシャットダウン"
    対策: "自動更新を防止、またはコンテナ終了コマンドをスキップ"

追加場所:
  個別リポジトリ: "特定のリポジトリ専用"
  組織全体: "ランナーの共有"
  エンタープライズ全体: "最大限の共有"
  
  利点: "組織またはエンタープライズレベルでの追加により、インフラストラクチャサイズを削減"

アクセス制御:
  方法: "ポリシーを使用してランナーグループを特定のリポジトリや組織に割り当て"

自動スケーリング:
  推奨: "利用可能なself-hosted runnersの数を自動的に増減"

セキュリティ強化:
  重要性: "Self-hosted runnersのセキュリティ強化を検討"

ストレージ:

Artifacts:
  用途:
    - ワークフロー内のジョブ間でデータを共有
    - ワークフロー完了後にデータを保存

キャッシング:
  用途: "依存関係をキャッシュしてワークフロー実行を高速化"
  
  例:
    - npm パッケージ
    - Maven 依存関係
    - Docker レイヤー

ポリシー設定:
  カスタマイズ可能:
    - ワークフローアーティファクトのストレージ
    - キャッシュ
    - ログ保持

コスト:
  含まれる: "サブスクリプションに一部含まれる"
  追加: "追加ストレージは請求に影響"
  計画: "このコストを事前に計画"

5. 使用状況の追跡:

追跡すべき項目:
  - ワークフローの実行頻度
  - 成功・失敗した実行の数
  - どのリポジトリがどのワークフローを使用しているか

基本的な使用状況:
  場所: "請求設定"
  内容: "各組織のストレージとデータ転送使用量"

詳細な使用データ:
  方法: "Webhooksを使用"
  購読内容:
    - ワークフロージョブ
    - ワークフロー実行
  
  データアーカイブ:
    推奨: "WebhookからデータアーカイブシステムへのGitHub情報の渡し方を計画"
    ツール: "CEDAR.GitHub.Collector（オープンソース）の使用を検討"
  
  チームアクセス:
    計画: "チームがアーカイブシステムから必要なデータを取得できる方法"

6.3 GitHub Actionsへの移行

既存CI/CDシステムからGitHub Actionsへの移行を計画的に実施します。

移行計画の策定:

1. 移行専門家の活用:

サポート:
  - GitHubが移行を支援
  - GitHub Professional Servicesの購入を検討
  
連絡先: "専任担当者またはGitHubのSalesチーム"

2. 移行ターゲットの特定とインベントリ作成:

手順:
  1. 既存のビルドおよびリリースワークフローのインベントリを作成
  2:
    収集情報:
      - どのワークフローがアクティブに使用されているか
      - 移行が必要なワークフロー
      - 放置できるワークフロー
  
  3. 現在のプロバイダーとGitHub Actionsの違いを学習
  4:
    評価項目:
      - 各ワークフローの移行における困難さ
      - 機能の違い
  
  5. 移行できる、移行したいワークフローを判断

3. チームへの影響判断:

考慮事項:
  開発者の日常業務:
    - ワークフローの移行が開発者の作業にどう影響するか
  
  プロセスと統合:
    - 影響を受けるプロセス、統合、サードパーティツールを特定
    - 必要な更新の計画を立てる
  
  コンプライアンス:
    - 既存の認証情報スキャンとセキュリティ分析ツールの互換性
    - 新しいツールの必要性
  
  ゲートとチェック:
    - 既存システムのゲートとチェックを特定
    - GitHub Actionsでの実装可能性を検証

4. 移行ツールの特定と検証:

GitHub Actions Importer:
  機能:
    - 各種サービスからGitHub Actionsへの移行を計画、スコープ、実行
    - サポートされる各種サービスからのCIパイプライン移行
  
  検証方法:
    1. テストワークフローでツールを実行
    2. 結果が期待通りか確認
    3. 手動作業量を見積もる
  
  注意: "自動ツールは大部分を移行できるが、少なくとも小さな割合は手動で書き直す必要がある"

5. 移行アプローチの決定:

小規模チーム:
  アプローチ: "Rip-and-replace"
  方法: "すべてのワークフローを一度に移行"

大規模エンタープライズ:
  アプローチ: "反復的アプローチ"
  方法: "段階的に移行"

推奨アプローチ_反復的:
  1_早期採用者:
    - 小規模グループから開始
    - 内部チャンピオンとして機能
  
  2_包括的なワークフロー選択:
    - ビジネスの幅を表すワークフローを特定
  
  3_協力して移行:
    - 早期採用者と協力してワークフローを移行
    - 必要に応じて反復
    - 他のチームに確信を与える
  
  4_大規模展開:
    - GitHub Actionsを大規模組織に利用可能に
    - チームが独自のワークフローを移行するためのリソース提供
    - 既存システムの廃止を通知
  
  5_完全移行:
    - 旧システムを使用しているチームに特定期間内の移行を通知
    - 他のチームの成功例を指摘

6. 移行スケジュールの定義:

手順:
  1. 移行完了希望日を決定:
     例: "現在のプロバイダーとの契約終了時"
  
  2. チームと協力してスケジュールを作成:
     考慮事項:
       - 期限を満たす
       - チーム目標を犠牲にしない
  
  3. ビジネスのペースを確認:
     - 各チームのワークロード
     - 配信スケジュール
  
  4. 調整:
     - チームの配信能力に影響を与えない時期を選択

移行実行:

実行内容:
  - 自動ツールと手動書き直しで既存ワークフローを変換
  - 既存システムからの古いビルドアーティファクトの維持を検討

並行運用:
  推奨: "両システムを一定期間並行運用"
  目的: "GitHub Actions設定が安定していることを確認"
  確認項目: "開発者体験の劣化がないこと"

最終廃止:
  - 古いシステムを廃止してシャットダウン
  - エンタープライズ内の誰も古いシステムを再起動できないようにする

6.4 GitHub Actions for Enterprise Cloudの開始

GitHub ActionsはGitHub Enterprise Cloudでデフォルトで有効です。

初期設定の3ステップ:

1_ポリシー管理:
  制御内容:
    - エンタープライズメンバーのGitHub Actions使用方法
    - 許可されるアクション
    - アーティファクトとログ保持
  
2_ランナーの追加:
  選択肢:
    GitHub-hosted:
      課金: "プランの分数使い果たし後、消費量ベース"
    
    Self-hosted:
      課金: "無料"
      追加レベル: "エンタープライズ、組織、リポジトリ"

3_きめ細かい権限のプロビジョニング:
  対象: "組織内のユーザーとチーム"
  原則: "最小権限でCI/CDパイプラインの設定を保護"

GitHub Actions用の権限:

権限名	アクセス内容
Manage organization Actions policies	Actions General設定ページのすべての設定（self-hosted runners設定を除く）
Manage organization runners and runner groups	GitHub-hosted runners、self-hosted runners、runnerグループの作成と管理
Manage organization Actions secrets	Actions組織シークレットの作成と管理
Manage organization Actions variables	Actions組織変数の作成と管理

まとめ

GitHub Enterprise Cloudのオンボーディングは、体系的なアプローチによって確実に成功させることができます。本記事で解説した6つのステージ（エンタープライズの開始、組織とチームの構築、サポート体制の確立、ガバナンスとセキュリティ、GitHub Appsによる自動化、GitHub ActionsによるCI/CD構築）を順に進めることで、エンタープライズレベルの開発基盤を構築できます。

重要なのは、各組織の要件に合わせて柔軟にアプローチを調整することです。トライアル期間を活用して実際の運用を検証し、段階的に本格導入を進めてください。技術的な詳細と実践的なベストプラクティスを理解することで、GitHub Enterprise Cloudの機能を最大限に活用した開発環境を実現できます。

オンボーディングの要点:

各ステージを着実に進めることで、セキュアで効率的な開発環境を構築し、チームの生産性を最大化することができます。