変更要約: GH-100 第4章を新規作成（ガバナンスとランナー＝再利用可能コンポーネント配布・Actions 組織ポリシー[許可リスト/SHA 必須化/フォークPR承認]・ランナーグループ/ホスト型vsセルフホスト・IP 許可リスト/Azure プライベートネットワーキング・性能監視[ラベル不一致/自動スケール]、暗号化シークレット＝組織/リポジトリ/環境のスコープと優先順位・組織レベル一元管理・REST API 自動化・サードパーティ Vault 連携(OIDC で実行時取得)）
4.2暗号化シークレットと外部 Vault 連携
シークレットのスコープとアクセスの定義、組織レベルとリポジトリレベルでのシークレットの構成、そしてサードパーティの Vault（シークレット管理基盤）との連携を、管理者の視点で理解します。
ワークフローはデプロイや外部サービス連携のために シークレット（API トークン・接続情報）を使います。管理者は、これらの秘密が 最小限の範囲 でのみアクセスされ、漏洩しないように統制します。GH-100 では、シークレットの スコープとアクセス、組織/リポジトリレベルの構成、そして 外部 Vault との連携 が問われます。
4.2.1シークレットのスコープとアクセス
GitHub Actions のシークレットは 組織・リポジトリ・環境（environment） の 3 レベルにスコープでき、同名は 狭いスコープが優先（環境 ＞ リポジトリ ＞ 組織）です（GH-200 と共通）。組織レベル のシークレットは複数リポで共有でき、アクセスできるリポジトリを限定 できます。環境シークレット は環境の保護ルール（必須レビュアー等）と組み合わせ、本番デプロイのみで使う、といった統制が可能です。管理者は「必要なワークフローにだけ最小限の秘密を見せる」設計をします。
4.2.2組織/リポジトリレベルの構成
共通の認証情報（例：社内レジストリのトークン）は 組織レベル に置き、許可したリポジトリだけがアクセスできるようにします——リポごとに重複登録せず、ローテーション時も一箇所で更新できます。リポジトリ固有の値は リポジトリレベル に置きます。シークレットはログ上で自動マスクされますが、echo や式に出さない など漏えい防止の運用が前提です。シークレットは REST API からも作成・更新でき（書き込みは公開鍵で暗号化）、多数リポへの配布やローテーションを自動化できます（GH-200 と共通）。