5.1Enterprise の利用とアクティビティの監視

管理者は、Enterprise が 安全に・効率よく・正しく 使われているかを継続的に 監視 します。GH-100 では、監査ログと API 利用 の分析、問題の切り分け（管理者 vs Support）、そして 利用パターンの評価（どれだけ採用され、どこが活発で、どの機能が使われていないか）が問われます。

5.1.1監査ログと API 利用の分析

監査ログ は「誰が・いつ・何を」したかの記録で、セキュリティ・コンプライアンス・トラブル調査の基礎です（第3章で既出）。必要に応じて SIEM へストリーミング して長期保管・相関分析します。API 利用 の分析では、どのトークン/アプリが どれだけ API を呼んでいるか、レート制限に近づいていないか を把握します——過剰な呼び出しや異常なパターンは、非効率や不正の兆候になり得ます。これらの可視化により、問題を早期に検知し対処します。

5.1.2責任の切り分けと診断

監視で見つけた問題は、管理者の設定/権限で解決できるもの と GitHub Support に依頼すべきもの を切り分けます（第2章で既出）。プラットフォーム障害や製品不具合は Support、GHES のシステム的トラブルは サポートバンドル/診断 を添えて Support に依頼します。管理者は「自分の管理範囲で対処→足りなければ Support」という流れを徹底し、無駄なエスカレーションと放置の両方を避けます。

5.1.3利用パターンの評価

管理者は、Enterprise の 利用パターン を評価して投資対効果を高めます——採用（adoption）（どの組織/チームがどれだけ使っているか）、アクティビティ（活発なリポ/ユーザー、停滞している領域）、使われていない機能（underutilized features）（有効化済みだが活用されていない GHAS や Actions など）です。未活用の発見は 教育・展開 の機会で、逆に過剰な利用はコスト/リスクの見直し対象になります。データに基づいて「どこを伸ばし、どこを締めるか」を判断します。

5.1.4この節のまとめ

• 監査ログ（誰が/いつ/何を）＋API 利用（量/レート制限）を分析、必要なら SIEM へストリーミング
• 問題は管理者で解決 vs Support 案件を切り分け、GHES はサポートバンドル/診断を添える
• 利用パターン（採用/アクティビティ/未活用機能）を評価し教育・展開やコスト見直しに活かす
• 監査ログは定期分析してこそ価値、監視データは機微なのでアクセス制限