GitHub App の enterprise インストールが GA、classic PAT から移せる管理 API
GitHub App の enterprise インストールが GA。2FA・IP 許可リスト・ruleset の管理 API を classic PAT から移しやすくなった。必要な権限と GHES 3.24 の対応条件を整理する。
GitHub App の
GitHub は2026年10月23日の changelog で、GitHub App を enterprise にインストールする機能を一般提供（GA）にした。今回、App から呼べる enterprise 管理系の API が増えた。2FA 要件の更新、IP 許可リストの編集、enterprise レベルの ruleset 管理などで、これまで classic PAT で回していた自動化を GitHub App の権限 に置き換えやすくなる。changelog 自身も「classic PAT を GitHub App に置き換えられる範囲が広がった」と書いている。
関係するのは、enterprise オーナーの classic PAT で管理スクリプトや社内ツールを動かしているチームだ。GHES については、これらの更新は GHES 3.24 で利用可能になると書かれている。changelog は App 側で使える API が増えたことを述べているだけで、classic PAT に期限や廃止を設ける記述はない。移行するかどうか、いつ移すかは各チームが決めることになる。
App の権限で新たに扱える操作
changelog は追加分を、ガバナンス（リポジトリポリシーと ruleset、bypass リクエストの読み取り）、セキュリティ（2FA、ドメイン検証、IP 許可リスト、アクセス制限）、管理（enterprise プロフィール、メンバー権限、リポジトリアクセス設定）の 3 つに分けている。権限ごとに並べると次のとおりだ。
| 権限 | アクセス | 新たに App から扱えるもの |
|---|---|---|
| Enterprise organization and repository policies | Read/write | EnterpriseOwnerInfo のポリシー項目の読み取り。private リポジトリの fork、既定のリポジトリ権限、可視性の変更、リポジトリの作成・削除、issue 削除、コラボレーター招待、deploy key、保護ブランチの更新、dependency insights、organization / repository projects の設定更新 |
| Enterprise bypass requests | Read | push rule とリポジトリポリシーの bypass リクエストの読み取り |
| Enterprise settings | Read/write | EnterpriseOwnerInfo 経由の enterprise データ（server installations、organization invitations を含む）の読み取り、enterprise プロフィールの更新 |
| Enterprise two-factor authentication | Read/write | 2FA 項目の読み取り、2FA 要件と禁止する認証方式の更新 |
| Enterprise / organization verifiable domains | Write | VerifiableDomain へのアクセス |
| Enterprise / organization IP allowlist | Read/write | IpAllowListEntry の作成・更新・削除、許可リストの強制、GitHub App の信頼、Enterprise Managed Users のユーザー単位の強制の切り替え |
| Enterprise access restrictions | Write | enterprise のアクセス制限の有効化・無効化 |
| Enterprise repository rulesets | Write | enterprise rules REST API と GraphQL の RepositoryRuleset による ruleset 管理 |
出典：GitHub Changelog「Enterprise installations for GitHub Apps generally available」（2026年10月23日）
表の大半は enterprise 単位の権限だ。ドメイン検証と IP 許可リストの 2 行だけは organization 単位の権限も並んでいる。changelog の「organization レベルの 2 つの穴も塞いだ」という一文は、この 2 行を指していると読める。ただし本文はそれ以上明示していない。
権限を選ぶときに見落としやすい点
ポリシー系の自動化を移すとき、Enterprise organization and repository policies だけを付けても足りない。changelog には、ポリシーへのアクセスに Enterprise settings の Read が必要だと書かれている。PAT のスコープを 1 対 1 で App の権限に写すと、ここで呼び出しが通らない形になりやすい。
IP 許可リストの権限も慎重に扱いたい。この権限ではエントリの追加・削除に加えて、許可リストの強制そのものや「GitHub App を信頼するか」の切り替えまで操作できる。許可リストを管理する App が、自分が通るための条件を書き換えられるということだ。Enterprise access restrictions の Write も、アクセス制限の有効・無効を切り替える権限だ。どちらも読み取りだけで済むジョブなら付けないほうがいい。changelog も、ワークフローに必要な権限を App の設定で選ぶよう案内している。
既存の権限で埋まった穴
新しい権限のほかに、既にある権限で App から扱えなかった API も対象になった。changelog は「より多くの自動化のシナリオで詰まりが解消するはず」と説明している。
- Enterprise people（Read/write）では
EnterpriseRepositoryInfoを読める。EnterpriseOwnerInfo.outsideCollaborators経由でリポジトリの詳細も取れる。organization に owner または member として自分を追加する操作もこの権限に入った。 - Enterprise billing（Write）では Marketplace のメンバー購入設定を更新できる。
外部コラボレーターの棚卸しを PAT で回していた場合、こちらの変更のほうが効く可能性がある。
移行を進める順番
changelog が示す手順は、移したいワークフローに合わせて App の権限を選ぶことだけだ。実務では次の順に進めると、取りこぼしが少ない。
- enterprise で使われている classic PAT を洗い出す。資格情報の棚卸しには GitHub Enterprise の CSV・API エクスポート が使える。
- PAT ごとに、呼んでいる API と GraphQL のオブジェクトを上の表の権限に対応させる。ポリシー系なら Enterprise settings の Read も足す。
- IP 許可リストとアクセス制限の Write は、本当に書き込むジョブだけに付ける。
- GHES を使っている環境は、3.24 に上げるまで App への切り替えを待つ。
enterprise レベルの ruleset を App で管理する予定なら、OSS ライセンス検査を ruleset で全社に適用する話 のような ruleset 前提の機能と組み合わせて考えるとよい。