変更要約: GH-100 第4章を新規作成（ガバナンスとランナー＝再利用可能コンポーネント配布・Actions 組織ポリシー[許可リスト/SHA 必須化/フォークPR承認]・ランナーグループ/ホスト型vsセルフホスト・IP 許可リスト/Azure プライベートネットワーキング・性能監視[ラベル不一致/自動スケール]、暗号化シークレット＝組織/リポジトリ/環境のスコープと優先順位・組織レベル一元管理・REST API 自動化・サードパーティ Vault 連携(OIDC で実行時取得)）
4.1Actions のガバナンスとランナー管理
Enterprise リポジトリへの再利用可能なアクション/ワークフローの構成、GitHub Actions の組織ポリシーの適用、ランナーグループと GitHub ホスト型/セルフホストランナーの管理、IP 許可リストとネットワーク（Azure プライベートネットワークを含む）、そしてランナーの性能監視とトラブルシュートを管理者視点で理解します。
GitHub Actions は強力ですが、無統制だと セキュリティ・コスト・サプライチェーン のリスクになります。管理者は、どのアクション/ワークフローを使えるか（ポリシー）、どこで実行するか（ランナー）、どう秘密を扱うか（次節）を組織横断で統制します。GH-100 では、これらの 大規模な管理 が問われます（ワークフロー作成の詳細は GH-200 が担い、ここは管理者視点の統制）。
4.1.1再利用可能コンポーネントとポリシー
管理者は、再利用可能ワークフロー・コンポジットアクション・スターターワークフロー（GH-200）を Enterprise/組織で配布 し、社内標準のパイプラインを展開します。Actions の組織ポリシー では、使えるアクションの範囲を すべて無効／すべて許可／GitHub 製のみ／GitHub 製＋検証済み／許可リスト から選び、外部アクションの SHA ピン留めの必須化 もできます。フォーク PR の実行承認 や GITHUB_TOKEN の既定権限を read に制限 することで、外部コードやサプライチェーンのリスクを抑えます。Enterprise の方針は配下の組織へ波及します。
4.1.2ランナーの管理
ジョブの実行環境＝ランナー には GitHub ホスト型（使い捨て・クリーン）と セルフホスト（社内ネットワーク/特殊環境）があります。セルフホストは ランナーグループ でまとめ、「どの組織/リポジトリが使えるか」を制御します（機密ランナーを特定リポに限定）。公開リポジトリでのセルフホスト利用は危険（外部 PR のコードが自前マシンで動く）。組織は IP 許可リスト で送信元を制限し、Azure 上では Azure プライベートネットワーク（プライベートネットワーキング） で GitHub ホスト型ランナーを自社の仮想ネットワークに接続して社内リソースへ安全にアクセスできます。
4.1.3ランナーの性能監視とトラブルシュート
管理者は、ランナーの 稼働状況と性能 を監視します——ジョブのキュー待ち、セルフホストランナーの オンライン/オフライン、リソース不足です。「ジョブが動かない」典型は ラベル不一致（runs-on と一致する空きランナーが無い）、ランナーアプリの停止、ネットワーク/認証の問題です。性能面では、同時実行枠、ランナーのサイズ（larger ランナー等）、キャッシュの活用、待機の削減を見ます。大規模では、需要に応じてセルフホストランナーを 自動スケール する構成も検討します。
頻出：
①管理者は再利用可能WF/コンポジット/スターターWFを配布、Actions 組織ポリシー（無効/全許可/GitHub製/検証済み/許可リスト・SHA 必須化・フォークPR承認）。
②ランナー＝GitHubホスト型/セルフホスト、セルフホストはランナーグループで統制、公開リポは危険。
③送信元制限＝IP 許可リスト、Azure はプライベートネットワーキングで社内リソース接続。
④ジョブ不動＝ラベル不一致/idle 無しを疑う。
混同・注意：
①セルフホストランナーは状態が残り、公開リポでは外部コード実行の危険——機密用途は GitHub ホスト型/使い捨て or ランナーグループで限定。
②Actions ポリシーの「GitHub 製のみ」と「GitHub 製＋検証済み」は別段階。
③Azure プライベートネットワーキングはホスト型ランナーを社内 NW に接続する仕組みで、セルフホストとは別アプローチ。
④「ジョブが動かない＝障害」と決めつけずラベル/可用性を確認。
4.1.4この節のまとめ
- 再利用可能コンポーネントを配布し、Actions 組織ポリシー（許可リスト/SHA 必須化/フォークPR承認）で統制
- ランナー＝ホスト型/セルフホスト、セルフホストはランナーグループで統制（公開リポは危険）
- 送信元は IP 許可リスト、Azure はプライベートネットワーキングで社内リソース接続
- 性能監視：ジョブ不動はラベル不一致/idle 無しを疑う、大規模は自動スケールも検討
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 組織で使えるアクションを「社内で承認した特定のものだけ」に制限したいです。Actions の組織ポリシーで選ぶべきは？
Q2. 本番デプロイ用のセルフホストランナーを、限られたリポジトリだけが使えるように制御したいです。使うものは？
Q3. Azure 上で、GitHub ホスト型ランナーを自社の仮想ネットワークに接続し社内リソースへ安全にアクセスさせたいです。使う仕組みは？
Q4. 公開（public）リポジトリでセルフホストランナーを使うことが一般に推奨されない理由は？
Q5. セルフホストランナーへ送ったジョブがキューに溜まったまま実行されません。まず疑う原因は？
Q6. 社内標準の CI/CD パイプラインを Enterprise/組織で配布したいです。管理者が使う仕組みは？