変更要約: GH-100 第2章を新規作成（ユーザー支援と標準＝管理者 vs GitHub Support の切り分け・サポートバンドル/診断・開発プロセス標準[ブランチ/レビュー/リリース/ワークフロー]とルールセット裏打ち、デプロイとライセンス＝GHEC with EMU / Data Residency + EMU / 個人アカウントの GHEC / GHES・シート課金＋従量課金・ライセンス使用状況の監視と未使用シート回収・SCIM/EMU 連動）
2.1ユーザー支援と開発プロセスの標準
管理者が解決できる問題と GitHub Support に依頼すべき問題の切り分け、サポートバンドルと診断の生成、そしてワークフロー・ブランチ戦略・レビュー・リリースに関する開発プロセスの標準を定める方法を理解します。
Enterprise 管理者は、日々の運用支援と、開発チームが効率よく安全に働ける 標準づくり を担います。GH-100 では、問題の 切り分け（管理者で解決できるか、GitHub Support か） と、組織で守るべき 開発プロセスの標準 を定める力が問われます。
2.1.1管理者と GitHub Support の切り分け
すべての問題を Support に投げるのではなく、管理者の設定・権限で解決できるもの は自分で対応します——アクセス権の調整、ポリシー/ルールセットの設定、ユーザー/チーム管理、機能の有効化などです。一方、プラットフォーム障害、製品の不具合、アカウントの深い問題、GHES のシステム的なトラブルなどは GitHub Support に依頼します。GHES では サポートバンドル（support bundle） や 診断情報 を生成して Support に提供すると、調査が早まります。「自分の管理範囲か、ベンダー対応か」を見極めるのが要点です。
2.1.2開発プロセスの標準
管理者は、チームが一貫して働けるよう プロセスの標準 を推奨・整備します——ブランチ戦略（trunk-based / GitHub Flow など）、プルリクエストのレビュー基準（必須レビュアー・必須チェック）、リリースの方法（タグ/リリース/環境）、そして ワークフロー（CI/CD）の共通化です。これらは ルールセットやブランチ保護（第1章）、組織テンプレート、スターターワークフロー（GH-200）で技術的に裏打ちします。標準化により、品質のばらつきとオンボーディングのコストを下げます。
頻出：
①問題は管理者で解決できるもの（権限/ポリシー/ユーザー管理）とGitHub Support 案件（障害/不具合/GHES のシステム障害）を切り分ける。
②GHES はサポートバンドル/診断を生成して Support に提供。
③管理者は開発プロセスの標準（ブランチ戦略・レビュー基準・リリース・共通ワークフロー）を定め、ルールセット/ブランチ保護/スターターワークフローで裏打ち。
混同・注意：
①権限やポリシーで直せる問題を Support に投げると遅くなる——まず管理範囲を確認。
②サポートバンドルには機微情報が含まれ得る——取り扱いに注意。
③標準は「推奨」だけでは守られない——ルールセット等で強制と組み合わせる。
④開発プロセス標準（人/運用）と技術的強制（ルールセット）は別だが補完関係。
2.1.3この節のまとめ
- 問題は管理者で解決（権限/ポリシー/ユーザー管理）か GitHub Support 案件（障害/不具合/GHES）かを切り分け
- GHES はサポートバンドル/診断を生成して Support に提供
- 開発プロセスの標準（ブランチ/レビュー/リリース/ワークフロー）を定める
- 標準はルールセット/ブランチ保護/スターターワークフローで技術的に裏打ち
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. メンバーが「特定リポにアクセスできない」と報告しました。管理者としてまず取るべき対応は？
Q2. GHES のシステム的なトラブルで GitHub Support に調査を依頼します。提供すると調査が早まるものは？
Q3. 管理者が定める「開発プロセスの標準」に含まれるものとして適切なものは？
Q4. 「標準を推奨として周知したが守られない」状況への最も適切な対応は？
Q5. GitHub Support に依頼すべき典型的な問題はどれですか？
Q6. サポートバンドルを扱う際の注意点として正しいものは？