変更要約: GH-100 第5章を新規作成（利用とアクティビティの監視＝監査ログ/API 利用の分析・SIEM ストリーミング・管理者 vs Support の切り分けと診断・利用パターン[採用/アクティビティ/未活用機能]、コストとパフォーマンス最適化＝従量製品[Actions 分/ストレージ/Packages/Copilot/GHAS]の使用レポート・Actions コスト最適化[フィルター/concurrency/キャッシュ/matrix/ランナー]・未使用シート回収・品質を落とさず無駄を削る原則）
5.1Enterprise の利用とアクティビティの監視
監査ログと API 利用の分析、管理者と GitHub Support の責任の切り分けと診断の生成、そして利用パターンの評価（採用・アクティビティ・使われていない機能の特定）を理解します。
管理者は、Enterprise が 安全に・効率よく・正しく 使われているかを継続的に 監視 します。GH-100 では、監査ログと API 利用 の分析、問題の切り分け（管理者 vs Support）、そして 利用パターンの評価（どれだけ採用され、どこが活発で、どの機能が使われていないか）が問われます。
5.1.1監査ログと API 利用の分析
監査ログ は「誰が・いつ・何を」したかの記録で、セキュリティ・コンプライアンス・トラブル調査の基礎です（第3章で既出）。必要に応じて SIEM へストリーミング して長期保管・相関分析します。API 利用 の分析では、どのトークン/アプリが どれだけ API を呼んでいるか、レート制限に近づいていないか を把握します——過剰な呼び出しや異常なパターンは、非効率や不正の兆候になり得ます。これらの可視化により、問題を早期に検知し対処します。
5.1.2責任の切り分けと診断
監視で見つけた問題は、管理者の設定/権限で解決できるもの と GitHub Support に依頼すべきもの を切り分けます（第2章で既出）。プラットフォーム障害や製品不具合は Support、GHES のシステム的トラブルは サポートバンドル/診断 を添えて Support に依頼します。管理者は「自分の管理範囲で対処→足りなければ Support」という流れを徹底し、無駄なエスカレーションと放置の両方を避けます。