変更要約: GH-100 第3章を新規作成（ポリシーとルールセット＝メンバー権限の統制 vs コード変更の強制・Enterprise 波及・監査ログ/SIEM ストリーミング・多層防御、リポジトリのセキュリティ機能＝脆弱性アラート/secret scanning/CodeQL の有効化・デフォルト構成・Dependabot/アドバイザリ・対応計画/SECURITY.md、API と連携＝fine-grained PAT/最小権限/失効・GitHub App vs OAuth App・レート制限・アプリの承認/拒否）
3.3API アクセスと連携アプリの管理
パーソナルアクセストークン（PAT）の構成、PAT と GitHub App のレート制限、GitHub Apps と OAuth Apps の違い、そしてポリシーに基づくアプリの承認/拒否を理解します。
GitHub は API と連携アプリで広く自動化・統合されます。管理者は、誰が・どんな認可で API/アプリを使えるか を統制します。GH-100 では、PAT・GitHub Apps / OAuth Apps・レート制限・アプリの承認/拒否 が問われます。中心は「最小権限の認可」と「組織ポリシーによる統制」です。
3.3.1パーソナルアクセストークン（PAT）
PAT は個人が発行する API トークンです。従来の クラシック PAT は広い権限になりがちなので、fine-grained PAT（細粒度 PAT） を使い、対象リポジトリと権限を 最小限 に絞り、有効期限 を設定するのが推奨です。組織は、PAT のポリシー で fine-grained PAT のアクセスを承認制にしたり、クラシック PAT の利用を制限したりできます。PAT はシークレット同様に扱い、漏洩時は 失効（取り消し） します。
3.3.2GitHub Apps と OAuth Apps
連携アプリには GitHub App と OAuth App があります。GitHub App は、アプリ自身の ID を持ち、きめ細かい権限 を インストール先のリポジトリ/組織に限定 して付与でき、短命のトークンで動くため 最小権限・セキュア です（推奨）。OAuth App は ユーザーの権限を借りて 動作し、ユーザーが持つ範囲全体にアクセスし得るため、粒度が粗くなりがちです。組織は OAuth App アクセスポリシー でどのアプリを許可するか制御します。新規の連携は GitHub App を推奨 し、必要に応じて承認制にします。
3.3.3レート制限とアプリの承認/拒否
API には レート制限（rate limit） があり、一定時間あたりのリクエスト数が制限されます。GitHub App（インストールトークン） は PAT より高いレート上限 を持つことが多く、規模の大きな自動化に向きます——大量 API 呼び出しで PAT が制限に当たる場合、GitHub App への移行が定石です。アプリの導入は、組織ポリシーで 承認/拒否 を制御します——メンバーが要求したアプリを管理者が 審査して許可 し、不要・不審なアプリは拒否します。これにより、サプライチェーン的な アプリ経由のリスク を抑えます。
頻出：
①PAT は fine-grained（細粒度）＋最小権限＋有効期限、漏洩時は失効。組織ポリシーで承認制/制限。
②GitHub App＝独自 ID・きめ細かい権限・インストール先限定・短命トークン（推奨）、OAuth App＝ユーザー権限を借りる（粗い）。
③GitHub App は PAT より高いレート上限＝大規模自動化に向く。
④アプリは組織ポリシーで承認/拒否して app 経由リスクを抑える。
混同・注意：
①クラシック PAT は広権限になりがち——fine-grained PAT で最小権限に。
②GitHub App（独自 ID・最小権限）と OAuth App（ユーザー権限を借用）を取り違えない——新規は GitHub App 推奨。
③レート制限に当たる大規模自動化は PAT より GitHub App。
④アプリを無審査で許可すると、過剰な権限のアプリがリスクになる——承認制で統制。
3.3.4この節のまとめ
- PAT は fine-grained＋最小権限＋有効期限、漏洩時は失効、組織ポリシーで承認制/制限
- GitHub App＝独自 ID/きめ細かい権限/インストール先限定/短命トークン（推奨）、OAuth App＝ユーザー権限を借用（粗い）
- GitHub App は PAT より高いレート上限＝大規模自動化に向く
- アプリは組織ポリシーで承認/拒否して app 経由のリスクを抑える
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 個人が API アクセスに使うトークンで、対象リポジトリと権限を最小限に絞り有効期限を設定できる推奨形式は？
Q2. 新規の連携で、独自の ID を持ち、きめ細かい権限をインストール先に限定し、短命トークンで動く推奨のアプリ形式は？
Q3. OAuth App の権限の特徴として正しいものはどれですか？
Q4. 大量の API 呼び出しを行う自動化が PAT のレート制限に当たります。定石の対応は？
Q5. メンバーが要求したサードパーティアプリの導入を、組織として統制したいです。適切な方法は？
Q6. PAT の安全な運用として正しいものはどれですか？