GitHubの「New enterprise installation API now in public preview」は、GitHub Appが特定のEnterpriseにインストールされているか、またそのinstallation_idが何かを直接確認できる新しいREST APIです。結論として、EnterpriseレベルでGitHub Appsを開発・運用している管理者や開発者は、既存のインストール探索処理、トークン発行処理、権限設計を確認する価値があります。
特に影響があるのは、GitHub Appを使ってEnterprise管理、組織横断の自動化、SCIM連携、Organizationへのアプリ配布、管理系APIの呼び出しを行っているチームです。一方で、通常のリポジトリ利用者や、Organization／Repository単位でしかGitHub Appを使っていないチームは、すぐに設定変更が必要になるケースは多くありません。
GitHub BlogのChangelogでは、この更新は2026年5月13日付で掲載されています。日本時間では2026年5月14日前後に確認される公式更新として扱われる内容です。GitHubは、このAPIを「GitHub App開発者向けのAPIギャップを埋めるもの」と説明しており、既存のOrganization、Repository、User向けのインストール確認APIにEnterprise向けの確認手段が加わった形です。(The GitHub Blog)
New enterprise installation APIで何が変わるのか
今回追加されたEnterprise Installation APIの中心は、次のエンドポイントです。
GET /enterprises/{enterprise}/installationこのAPIを使うと、認証済みのGitHub Appが、指定したEnterpriseに自分自身がインストールされているかを確認し、該当するインストール情報を取得できます。公式ドキュメントでは、enterpriseパラメーターにEnterprise名のslug版を指定し、GitHub AppとしてJWTで認証する必要があると説明されています。(GitHub Docs)
従来、Enterpriseインストールを特定したい場合、GitHub App側で全インストール一覧を取得し、ページネーションしながら対象のEnterpriseを探すような実装になりがちでした。今回のAPIにより、対象Enterpriseが分かっている場合は直接問い合わせられるため、無駄なAPI呼び出しや探索ロジックを減らせます。GitHubも、すべてのインストール一覧をページングして対象を探す代わりに、より速くEnterprise用のインストールトークン取得につなげられると説明しています。(The GitHub Blog)
| 観点 | これまで起きやすかったこと | 新APIで改善されること |
|---|---|---|
| インストールIDの取得 | 全インストールを一覧取得し、対象を絞り込む必要があった | Enterprise slugから直接インストール情報を取得できる |
| 実装の複雑さ | Organization、Repository、User向けAPIと比べてEnterpriseだけ扱いが違った | 既存の対象別インストール確認APIと考え方をそろえやすい |
| API呼び出し回数 | インストール数が多いとページネーションが増える | 対象Enterpriseが分かっていれば単一エンドポイントで確認しやすい |
| トークン発行までの流れ | 対象インストールの特定に時間がかかる場合があった | installation_id取得後、インストールアクセストークン発行へ進めやすい |
このAPIは「権限を増やすAPI」ではない
重要なのは、Enterprise Installation APIはGitHub Appの権限を増やす機能ではないという点です。役割は、あくまで「そのGitHub Appが特定のEnterpriseにインストールされているか」「インストールIDは何か」を確認することです。
実際にEnterpriseレベルの操作を行うには、取得したinstallation_idを使ってインストールアクセストークンを作成し、そのトークンで対応するAPIを呼び出します。GitHub Docsでは、インストールアクセストークンはEnterprise、Organization、個人アカウントへのGitHub Appインストールに対して認証済みAPIリクエストを行うためのもので、有効期限は作成から1時間と説明されています。(GitHub Docs)
そのため、今回の変更を「Enterpriseに対して新しい操作権限が自動付与される」と理解すると危険です。実務上は、次のように分けて考えると混乱しにくくなります。
| 処理 | 目的 | 主な確認ポイント |
|---|---|---|
GET /enterprises/{enterprise}/installation | Enterpriseインストール情報を取得する | App JWTで認証しているか、Enterprise slugが正しいか |
POST /app/installations/{installation_id}/access_tokens | インストールアクセストークンを作成する | トークンの有効期限、必要な権限、対象インストール |
| Enterprise管理APIの呼び出し | 実際の管理操作を行う | GitHub Appに必要なEnterprise権限が付与されているか |
対象になる管理者・開発者
今回のAPIを優先的に確認すべきなのは、次のようなチームです。
EnterpriseレベルでGitHub Appsを使っている管理者
EnterpriseにGitHub Appsをインストールして、Enterpriseアカウントの管理や自動化を行っている場合は、今回のAPIが運用改善につながります。GitHub Docsでは、EnterpriseにインストールされたGitHub AppsはEnterpriseレベルのアクセス許可を要求し、Enterpriseアカウントに対する操作を実行できるアプリと説明されています。(GitHub Docs)
たとえば、次のような用途です。
- Enterprise内のOrganization作成や管理を自動化する
- Enterprise配下のGitHub Appインストールを管理する
- SCIMプロビジョニングなどの管理系処理を自動化する
- 社内開発基盤からGitHub Enterprise Cloudの管理APIを呼び出す
GitHub Appを開発しているSaaS・内製ツール担当者
GitHub Appを提供する開発者にとっては、インストール確認ロジックを見直すタイミングです。特に、現在のコードがList installations for the authenticated appのような一覧取得に依存し、対象Enterpriseをアプリ側で検索している場合は、新APIへの置き換えで処理を単純化できる可能性があります。
ただし、Public Preview段階のAPIであるため、いきなり本番の全処理を置き換えるより、まずはステージング環境や一部Enterpriseで検証するのが現実的です。GitHub Docsでも、Enterpriseにインストール済みのGitHub Appsはパブリックプレビュー段階で、変更される可能性があると明記されています。(GitHub Docs)
セキュリティ・ガバナンス担当者
セキュリティ担当者にとっては、「どのGitHub AppがEnterpriseにインストールされ、どの権限で動いているか」を整理するきっかけになります。
Enterpriseインストールは便利ですが、管理系APIを扱うため、権限の過不足が問題になりやすい領域です。GitHub Appが必要以上のEnterprise権限を持っていないか、不要になったアプリが残っていないか、運用担当者が変わっても秘密鍵やJWT生成処理が適切に管理されているかを確認しましょう。
管理者が確認すべき設定
Enterpriseにインストール済みのGitHub Appsを棚卸しする
まず確認すべきなのは、現在EnterpriseにどのGitHub Appsがインストールされているかです。Enterprise所有者はEnterpriseにGitHub Appsをインストールできますが、App managerはEnterpriseレベルでアプリをインストールできないとGitHub Docsに記載されています。(GitHub Docs)
管理者は、少なくとも次の情報を一覧化しておくと、今回のAPI導入時に判断しやすくなります。
| 確認項目 | 見るべきポイント |
|---|---|
| アプリ名 | 内製アプリか、Enterprise内のOrganizationが所有するアプリか |
| 所有者 | EnterpriseまたはEnterprise内のOrganizationが所有しているか |
| 利用目的 | Enterprise管理、Organization管理、SCIM、監査など |
| 付与権限 | Enterpriseレベルで必要最小限になっているか |
| 運用担当 | 秘密鍵、Webhook、トークン発行処理の管理者が明確か |
| 継続要否 | 使われていないアプリが残っていないか |
Enterpriseインストールの制限を理解する
EnterpriseにインストールしたGitHub Appは、OrganizationやRepositoryに自動でアクセスできるわけではありません。GitHub Docsでは、EnterpriseインストールはOrganizationインストールAPIを除き、Enterprise内のOrganizationやRepositoryへのアクセス権を付与しないと説明されています。OrganizationやRepositoryリソースにアクセスするには、必要なOrganizationごとにアプリを個別にインストールする必要があります。(GitHub Docs)
ここは実装ミスが起きやすいポイントです。たとえば、EnterpriseのインストールIDを取得できたからといって、リポジトリのIssue、Pull Request、Secret、Actionsワークフローなどにアクセスできるとは限りません。
次のように整理すると安全です。
| やりたいこと | 必要になりやすいインストール |
|---|---|
| Enterprise内の管理操作 | Enterpriseインストール |
| 特定Organizationのリポジトリ操作 | Organizationインストール |
| 個別Repositoryの操作 | OrganizationまたはRepositoryアクセス権を持つインストール |
| Enterpriseレベルのイベント受信 | 現時点では制限に注意 |
| RepositoryイベントのWebhook受信 | OrganizationまたはRepositoryへのインストール |
Webhook対応を過信しない
Enterpriseインストールで特に注意したいのがWebhookです。GitHub Docsでは、現在EnterpriseインストールではWebhookがサポートされておらず、EnterpriseレベルでインストールされたアプリはEnterpriseレベルのアクティビティのWebhookイベントを受け取れないと説明されています。OrganizationやRepositoryのイベントを受け取りたい場合は、それらのリソースに対してアプリをインストールする必要があります。(GitHub Docs)
つまり、今回のEnterprise Installation APIを使ってインストールIDを取得できても、「Enterprise全体のイベントをWebhookで受け取れるようになる」わけではありません。イベント駆動の自動化を設計している場合は、APIで取得する情報とWebhookで受け取る情報を分けて設計してください。
レート制限をインストール単位で考える
EnterpriseインストールとOrganizationインストールを併用している場合は、レート制限の見方も重要です。GitHub Docsでは、EnterpriseインストールトークンはGitHub Enterprise Cloud Organizationと同じレート制限を持ち、レート制限はインストールごとに適用されると説明されています。たとえば、アプリがEnterpriseと2つのOrganizationにインストールされている場合、それぞれに別のインストールトークンが必要になり、レート制限の予算も独立します。(GitHub Docs)
運用上は、Enterprise用トークンとOrganization用トークンを混同しないことが大切です。ログやメトリクスにも、installation_id、対象種別、Enterprise slug、Organization名を分けて記録しておくと、レート制限や権限エラーの調査がしやすくなります。
開発者向けの実装イメージ
新APIを使う基本的な流れは、次のようになります。
| 手順 | 内容 | 実装上の注意 |
|---|---|---|
| 1 | GitHub AppとしてJWTを生成する | 秘密鍵を安全に管理し、短命なJWTを使う |
| 2 | GET /enterprises/{enterprise}/installationを呼び出す | enterpriseには表示名ではなくslugを指定する |
| 3 | レスポンスからidを取得する | これが後続処理で使うinstallation_id |
| 4 | POST /app/installations/{installation_id}/access_tokensでトークンを作成する | トークンは1時間で期限切れになる |
| 5 | 必要なEnterprise APIを呼び出す | Enterpriseインストールで対応しているAPIか確認する |
サンプルとしては、次のようなリクエストになります。実際には<APP_JWT>をGitHub Appの秘密鍵から生成したJWTに置き換え、ENTERPRISEには対象Enterpriseのslugを指定します。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <APP_JWT>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/enterprises/ENTERPRISE/installation公式ドキュメントのコード例でも、Accept: application/vnd.github+json、Authorization: Bearer <YOUR-TOKEN>、X-GitHub-Api-Version: 2026-03-10を指定して、https://api.github.com/enterprises/ENTERPRISE/installationを呼び出す形が示されています。また、GHE.comを利用している場合は、api.github.comを専用サブドメインに置き換える必要があります。 (GitHub Docs)
移行時に見直したいコード
すでにGitHub Appを運用している場合、次のようなコードや設計があるか確認してください。
全インストール一覧からEnterpriseを探している処理
既存実装で、GitHub Appの全インストールを取得し、対象アカウントをループで探している場合は、新APIに置き換えられる可能性があります。
見直し前の典型例は、次のような処理です。
全インストール一覧を取得
↓
ページネーションしながら取得を継続
↓
accountやtarget情報を見てEnterpriseらしき対象を探す
↓
見つかったinstallation_idでトークンを作成新APIを使う場合は、対象Enterpriseのslugが分かっていれば、次のように単純化できます。
Enterprise slugを指定
↓
Enterprise installation APIでインストール情報を取得
↓
取得したinstallation_idでトークンを作成これにより、インストール数が多い環境ほど、API呼び出し回数や探索処理の複雑さを減らせます。
installation_idのキャッシュ処理
installation_idをキャッシュしている場合は、キャッシュの期限や再取得条件を見直しましょう。アプリがアンインストールされた後に再インストールされた場合、古いinstallation_idを前提にした処理は失敗する可能性があります。
実務では、次のような設計が安全です。
installation_idは永続的に固定と決めつけない- トークン作成に失敗したらEnterprise Installation APIで再取得する
- キャッシュにはEnterprise slug、App ID、取得日時を含める
- 古いIDでの失敗を異常終了だけでなく再同期のトリガーとして扱う
認証方式の混同
このエンドポイントはGitHub AppとしてのJWT認証が必要です。公式ドキュメントでは、GitHub App user access token、GitHub App installation access token、fine-grained personal access tokenでは動作しないと説明されています。(GitHub Docs)
よくある失敗は、すでに発行済みのインストールアクセストークンを使って、このAPIを呼び出してしまうことです。インストール情報を探す段階ではApp JWT、実際の操作ではインストールアクセストークン、という役割分担を明確にしてください。
導入判断の目安
Public PreviewのAPIは、便利だからといって全環境へ一気に展開するより、影響範囲を分けて導入するのが安全です。
| 現在の状況 | 推奨アクション |
|---|---|
| Enterpriseインストールをすでに使っている | ステージング環境で新APIを検証し、既存の探索処理と比較する |
| 全インストール一覧をページングしてEnterpriseを探している | 新APIへの置き換え候補として優先的に確認する |
| Organization／Repository単位のGitHub Appのみ使っている | すぐに移行する必要は低い。既存APIで問題ないか確認する |
| Enterprise管理の自動化を新規開発する | 最初からEnterprise Installation APIを前提に設計する |
| GitHub Enterprise Serverで利用したい | GitHub Enterprise Cloud向けドキュメントだけで判断せず、利用中バージョンの公式ドキュメントを確認する |
| 本番の基幹運用に組み込みたい | Public Previewであることを前提に、フォールバックと監視を用意する |
展開時のチェックリスト
本番環境へ展開する前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| Enterprise slug | 表示名ではなくAPIで使うslugを指定しているか |
| 認証 | App JWTで呼び出しているか |
| APIバージョン | X-GitHub-Api-Versionを明示しているか |
| 権限 | GitHub Appに必要なEnterprise権限があるか |
| トークン管理 | インストールアクセストークンを長期保存していないか |
| ログ | JWTやアクセストークンをログに出していないか |
| キャッシュ | installation_idの再取得ロジックがあるか |
| エラー処理 | 未インストール、権限不足、対象Enterprise誤りを区別できるか |
| 監視 | トークン発行失敗、API失敗率、レート制限を監視しているか |
| ロールバック | 既存のインストール探索処理へ戻せるか |
よくある誤解と注意点
Enterpriseに入れればRepositoryにもアクセスできる、は誤り
EnterpriseインストールはEnterprise管理のための仕組みです。OrganizationやRepositoryのデータにアクセスしたい場合は、対象のOrganizationやRepositoryに対するインストールが必要です。EnterpriseのインストールIDだけで、すべてのリポジトリ操作が可能になるわけではありません。(GitHub Docs)
インストールアクセストークンを使って新APIを呼べる、は誤り
Enterprise Installation APIは、GitHub AppとしてJWTで呼び出すエンドポイントです。インストールアクセストークンは、インストールIDを取得した後に作成し、実際の操作APIで使うものです。認証方式を混同すると、権限エラーや認証エラーの原因になります。(GitHub Docs)
Public Previewを安定版と同じように扱うのは危険
Public Previewは、利用できるものの、仕様や制限が変わる可能性があります。特に、EnterpriseインストールGitHub Apps自体もパブリックプレビュー段階で変更される可能性があると説明されています。重要な本番処理に組み込む場合は、エラー監視、再試行、フォールバック、公式Changelogの定期確認を前提にしてください。(GitHub Docs)
まず何をすべきか
今回の「New enterprise installation API now in public preview」は、EnterpriseレベルのGitHub App運用を大きく変える派手な機能というより、これまで不足していた確認手段を補う実務的な改善です。対象Enterpriseが分かっている場合に、GitHub Appのインストール情報とinstallation_idを直接取得できるため、トークン発行前の探索処理をシンプルにできます。
まずは、次の順で進めるのがおすすめです。
- Enterpriseにインストール済みのGitHub Appsを棚卸しする
- 既存コードで全インストール一覧をページングしている箇所を探す
- ステージング環境で
GET /enterprises/{enterprise}/installationを試す - 取得した
installation_idからトークン発行までの流れを確認する - Public Previewであることを前提に、監視とフォールバックを用意して段階的に展開する
Enterprise管理の自動化を進めている組織ほど、このAPIの価値は大きくなります。単に新APIを追加するのではなく、GitHub Appの権限、インストール単位、トークン管理、Webhook制限まで合わせて見直すことで、より安全で保守しやすいEnterprise運用につながります。
コメント