2.2デプロイ形態とライセンス

企業が GitHub を導入する形態は 1 つではありません。GH-100 では、要件（データ所在地・ID 管理・運用負荷）に応じた デプロイ形態の選択 と、ライセンス/課金 の理解が問われます。大きくは、GitHub がホストする GitHub Enterprise Cloud（GHEC） と、自社環境に置く GitHub Enterprise Server（GHES） に分かれます。

2.2.1主なデプロイ形態

代表的な形態は次の通りです。
①GHEC with EMU——クラウドで、ユーザーを企業 IdP が完全管理（EMU）。ID を厳密に統制したい企業向け。
②GHEC with Data Residency + EMU——EMU に加え、データを特定リージョンに保持（データ所在地の要件に対応）。
③個人アカウントの GHEC——メンバーが個人アカウントで参加する従来型（SAML SSO で統制）。
④GHES——自社環境（オンプレ/自社クラウド）に置くセルフホスト版で、データを完全に自社管理。要件に応じて選びます——「ID を完全管理＝EMU」「データ所在地＝Data Residency」「完全自社管理＝GHES」。

2.2.2ライセンスと課金

GitHub Enterprise は基本的に ユーザー（シート）単位 のライセンスで課金されます。これに加え、従量課金（metered） の製品があります——GitHub Actions の 実行時間 とストレージ、GitHub Packages のストレージ、Copilot や GHAS の シート/利用 などです。管理者は どの製品が固定（シート）か従量か を理解し、コストを見積もります。ライセンスは Enterprise/組織の請求設定で管理し、支払い方法（クレジット/請求書/Azure サブスクリプション課金など）を設定します。

2.2.3ライセンス使用状況の監視

コストとコンプライアンスのため、ライセンスの消費状況 を監視します——割り当て済みシート数、空きシート、アクティブ/非アクティブなユーザー、従量製品の使用量です。管理者は 使用状況レポート を確認して、未使用シートの回収や、従量コストが膨らむ前の対策（第5章の最適化）に活かします。EMU や SCIM（第1章）と組み合わせると、退職者のシートが自動で空くため、棚卸しが楽になります。

2.2.4この節のまとめ

• デプロイ形態：GHEC with EMU / Data Residency + EMU / 個人アカウントの GHEC / GHES を要件で選ぶ
• 課金はユーザー（シート）単位＋従量（Actions 分/ストレージ/Copilot/GHAS）
• ライセンス使用状況を監視し未使用シートを回収、SCIM/EMU で退職者シートが自動で空く
• EMU（ID 管理）と Data Residency（データ所在地）は別要件、GHEC と GHES は別運用