変更要約: GH-200 第4章を新規作成（ガバナンス＝利用ポリシー無効/全許可/GitHub製/検証済み/許可リスト・SHA ピン留め必須化・再利用コンポーネントのアクセス設定・フォークPR承認・波及、ランナーの大規模管理＝GitHubホスト/セルフホスト・ランナーグループ・IP許可リスト・プリインストール/toolcache/setup-*・トラブルシュート、暗号化シークレットと変数＝組織/リポジトリ/環境のスコープと優先順位・secrets/vars・マスキング・REST API 管理）
4.3暗号化シークレットと変数
組織・リポジトリ・環境（environment）の各レベルでの暗号化シークレットと変数のスコープと優先順位、ワークフローやアクションでの参照とマスキング、そして REST API によるプログラム的な管理を理解します。
ワークフローで使う機密値（API トークン・パスワード等）は 暗号化シークレット として、機密でない設定値は 変数（variables） として保存します。どちらも 3 つのレベル にスコープを持てます——組織（organization）・リポジトリ（repository）・環境（environment）。組織レベルに置けば複数リポジトリで共有でき（アクセスできるリポジトリを限定可能）、環境レベルに置けばその環境（本番など）のデプロイ時だけ使えます。
4.3.1スコープと優先順位
同じ名前のシークレット/変数が複数レベルに存在する場合、より狭いスコープが優先 されます——一般に「環境 ＞ リポジトリ ＞ 組織」の順で、環境レベルの値が最優先です。これにより、組織で共通の既定値を置きつつ、特定の環境やリポジトリだけ上書きできます。環境シークレット は環境の保護ルール（必須レビュアー等）と組み合わさるため、「本番のシークレットは承認後にしか使われない」という制御も実現できます。
| レベル | 共有範囲 | 典型用途 |
|---|---|---|
| 組織 | 複数リポジトリで共有（許可リポジトリ限定可） | 共通のトークン/設定 |
| リポジトリ | そのリポジトリ全体 | リポジトリ固有の値 |
| 環境 | その環境のデプロイ時のみ | 本番/ステージング個別の機密 |
4.3.2参照とマスキング
シークレットは secrets.<名前> コンテキスト、変数は vars.<名前> コンテキストで参照します。シークレットは ログ上で自動的にマスク（* 表示）されますが、加工して出力すると漏れることがあるため、echo で直接出さない・式に埋め込まないのが原則です。アクション/再利用可能ワークフローへ渡す場合は with:（変数）や secrets:（シークレット、inherit も可）を使います。GITHUB_TOKEN は実行ごとに自動発行される特殊なシークレットで、明示登録は不要です。
4.3.3REST API によるプログラム的管理
シークレットと変数は UI だけでなく REST API（や gh CLI）から作成・更新・削除でき、棚卸しやローテーションを自動化できます。シークレットの書き込みは 公開鍵で暗号化 してから送る方式で、値が平文でログ/API に残らないよう設計されています。多数のリポジトリへ同じシークレットを配布する、定期的にトークンをローテーションする、退職者のアクセスを一括で外す、といった運用を API で自動化するのが大規模管理の定石です。
頻出：
①機密値＝シークレット（secrets.<名前>）、設定値＝変数（vars.<名前>）。
②スコープは組織/リポジトリ/環境で、同名は狭いスコープ優先（環境＞リポジトリ＞組織）。
③シークレットはログで自動マスクだが echo/式で漏らさない。
④環境シークレット＋保護ルールで承認後のみ利用。
⑤GITHUB_TOKEN は自動発行。
⑥REST API/gh CLIで作成・更新・削除（書き込みは公開鍵で暗号化）、ローテーション自動化。
混同・注意：
①シークレット（機密・マスク）と変数（非機密・vars）は別物——機密を変数に入れない。
②同名の優先順位＝狭いスコープ（環境）が勝つ。
③自動マスクは万能ではない——加工出力やエラーメッセージで漏れうる。
④フォーク PR では組織/リポジトリのシークレットは既定で渡らない（露出防止）。
⑤GITHUB_TOKEN は自前登録不要・実行ごとに失効。
4.3.4この節のまとめ
- 機密＝シークレット（secrets.<名前>）、設定＝変数（vars.<名前>）。3レベル（組織/リポジトリ/環境）でスコープ
- 同名は狭いスコープ優先（環境＞リポジトリ＞組織）、環境シークレットは保護ルールと併用で承認制
- シークレットは自動マスクだが echo/式で漏らさない、GITHUB_TOKEN は自動発行
- REST API/gh CLI で作成・更新・削除（公開鍵で暗号化）、配布・ローテーションを自動化
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 本番（production）環境へのデプロイ時だけ使う API トークンを保存し、承認後にのみ使われるようにしたいです。どこに置きますか？
Q2. 組織・リポジトリ・環境に同じ名前のシークレットが定義されています。実際に使われるのはどれですか？
Q3. 多数のリポジトリへ同じデプロイトークンを配布し、四半期ごとに自動でローテーションしたいです。最適な手段はどれですか？
Q4. シークレットの扱いに関する安全な実践として正しいものはどれですか？
Q5. 機密ではない設定値（ビルド対象のリージョン名など）を、複数リポジトリで共有しつつワークフローから参照したいです。適切なものはどれですか？
Q6. 外部コントリビューターのフォークからの PR で、組織やリポジトリのシークレットが既定でどう扱われるか正しいのはどれですか？