Enterprise Teamsは、Microsoft Teamsの会議・チャット機能ではなく、GitHub Enterprise Cloud向けのチーム管理機能です。2026年6月に一般提供（GA）となり、企業管理者はユーザーグループをエンタープライズ単位で一度定義し、複数Organizationの権限、レビュー依頼、Copilotライセンス、ルールセットのバイパス権限などに横断的に使えるようになりました。(The GitHub Blog)
結論から言うと、複数のGitHub Organizationを運用している企業ほど影響が大きい更新です。これまでOrganizationごとに同じチームを作成・同期・棚卸ししていた環境では、権限管理の重複を減らせます。一方で、Enterprise Teamsに組織アクセスやロールを付与すると、メンバー追加と同時に広い範囲へ権限が反映されるため、管理者は既存チームの移行設計、IdP連携、ライセンス消費、監査ログの確認をセットで見直す必要があります。
Enterprise Teamsとは何か
Enterprise Teamsは、GitHub Enterprise Cloudのエンタープライズアカウント上で作成するユーザーグループです。従来のGitHubチームは主にOrganization単位で管理しますが、Enterprise Teamsはエンタープライズ全体をまたいで使える点が大きく異なります。
たとえば、50個以上のOrganizationを持つ企業で「SRE」「Security」「Platform Admin」といった同じ役割のチームを各Organizationに作っている場合、メンバー変更のたびに複数箇所を更新する必要がありました。Enterprise Teamsでは、エンタープライズ側でチームを1つ定義し、そのチームを複数Organizationのロールや権限に割り当てられます。GitHubの公式発表でも、同じSREまたはSecurityチームを多数のOrganizationでレビュー担当に回す用途や、リポジトリルールセットのバイパス権限を一元付与する用途が例示されています。(The GitHub Blog)
注意したいのは、「Teams」という名称でもMicrosoft Teamsのチャネル、会議、Teamsアプリ、Teams管理センターの更新ではない点です。今回のEnterprise Teamsは、GitHub Enterprise CloudのID管理・権限管理・Copilotライセンス管理に関する更新として理解するのが正確です。
一般提供で変わった主なポイント
一般提供により、Enterprise Teamsは本番運用を前提に使いやすくなりました。特に管理者が確認すべき変更は、スケール上限、メンション、レビュー依頼、ルールセット、IdP連携、API、自動化、監査ログです。
| 項目 | 変更内容 | 実務上の意味 |
|---|---|---|
| チーム管理 | エンタープライズ単位でユーザーグループを定義可能 | 同じチームをOrganizationごとに重複作成する必要を減らせる |
| スケール上限 | 1エンタープライズあたり最大2,500チーム、1チームあたり最大5,000メンバー | 大規模企業でも部門・職能別チームを設計しやすい |
| Organization割り当て | 1チームを最大1,000 Organizationに割り当て可能 | 多数のOrganizationを持つ企業で横断管理しやすい |
| PR・Issue・Discussion | Enterprise Teamsを@メンション可能 | Organizationチームと同様に通知・レビュー依頼の導線を作れる |
| Pull Requestレビュー | 割り当て済みOrganization全体でEnterprise Teamsをレビュワー指定可能 | セキュリティレビュー、SREレビュー、基盤チームレビューに使いやすい |
| Repository rulesets | バイパスアクターとしてEnterprise Teamsを選択可能 | 緊急対応チームや管理チームへの例外権限を一元管理できる |
| IdP連携 | Enterprise Managed UsersではSCIM経由でIdPグループと同期可能 | Entra IDやOktaなどを起点にメンバー管理を自動化できる |
| API・自動化 | GitHub Appsやfine-grained PATでEnterprise Teamsを管理可能 | 個人管理者のPAT依存を減らし、運用スクリプトを標準化できる |
| 監査 | チーム作成・更新・削除、メンバー変更、ロール割り当て、ルールセットバイパスなどを監査ログで追跡可能 | 権限変更の証跡を残しやすい |
公式ドキュメントでは、Enterprise TeamsはCopilot Businessライセンスの直接割り当て、事前定義ロール・カスタムエンタープライズロールの割り当て、Organizationへの追加、ルールセットのバイパス権限、IssueやPull Requestでのメンション・割り当て・レビュー依頼に使えると説明されています。(GitHub Docs)
影響が大きい組織
Enterprise Teamsの導入効果が大きいのは、GitHub Enterprise Cloudを単一Organizationではなく、複数Organizationで運用している企業です。特に次のような環境では、早めに確認する価値があります。
複数Organizationに同じチームを作っている
「security-reviewers」「sre」「platform」「mobile-admins」のようなチームを各Organizationに個別作成している場合、メンバー追加・削除のたびに管理作業が重複します。人事異動や退職対応が多い企業では、あるOrganizationだけ古いメンバーが残る、レビュー依頼先がOrganizationごとに違う、棚卸し時に実態が分からないといった問題が起きがちです。
Enterprise Teamsに寄せることで、「同じ役割のチーム」をエンタープライズ単位で管理し、Organization側ではそのチームに必要な権限を割り当てる設計に近づけます。
Copilot Businessライセンスをチーム単位で管理したい
Enterprise TeamsにはGitHub Copilotライセンスを割り当てられます。チームにライセンスを付与しておくと、ユーザーがチームへ追加・削除されたタイミングでCopilotへのアクセスも増減します。(GitHub Docs)
開発部門、試験導入チーム、特定プロダクトチームなど、ライセンス付与対象が明確な場合は管理しやすくなります。ただし、チーム構成を変更するとCopilot利用権にも影響するため、ライセンス管理者とGitHub管理者の運用ルールをそろえておく必要があります。
Entra IDやOktaなどのIdPでメンバー管理したい
Enterprise Managed Usersを利用している環境では、Enterprise TeamsのメンバーシップをIdPグループとSCIM経由で同期できます。公式発表では、Entra IDやOktaなどのIdPを起点にEnterprise Teamメンバーシップを管理できることが示されています。(The GitHub Blog)
ただし、IdP連携は「つなげれば終わり」ではありません。GitHub Docsでは、Microsoft Entra IDをIdPとして使う場合、接続できるのはセキュリティグループであり、ネストされたグループメンバーシップやMicrosoft 365グループはサポートされないと説明されています。(GitHub Docs)
管理者が最初に確認すべき設定
Enterprise Teamsを本番導入する前に、管理者は現在のチーム・権限・ライセンスの状態を棚卸しする必要があります。いきなり既存チームを置き換えるより、影響範囲が小さく、権限の目的が明確なチームから試すのが安全です。
既存チームの重複を洗い出す
まず、Organizationごとに作成されているチームを確認します。名前が似ていても、実際の役割やメンバーが違うことがあります。
確認すべき観点は次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| チーム名 | 同じ役割のチームがOrganizationごとに存在していないか |
| メンバー | 現在も必要なユーザーだけが入っているか |
| 付与権限 | リポジトリアクセス、Organizationロール、Enterpriseロールが過剰でないか |
| 用途 | レビュー依頼用、管理者用、緊急対応用、Copilotライセンス用など目的が混在していないか |
| 自動化 | GitHub Actions、GitHub Apps、外部スクリプトがチーム名やIDに依存していないか |
特に注意すべきなのは、既存チームを単純にEnterprise Teamsへ統合しないことです。たとえば「security」という名前のチームが複数Organizationにあっても、あるOrganizationではコードレビュー担当、別のOrganizationでは管理者権限を持つチームとして使われている場合があります。この状態で1つのEnterprise Teamにまとめると、意図せず強い権限を広げる恐れがあります。
Enterprise Teamの命名ルールを決める
Enterprise Teamsはエンタープライズ全体で見られる管理単位になるため、名前の付け方が重要です。おすすめは「役割」と「範囲」が分かる命名です。
| 悪い例 | 問題点 | 改善例 |
|---|---|---|
| admin | 何の管理者か分からない | ent-platform-admins |
| security | レビュー用か管理用か不明 | ent-security-reviewers |
| copilot | ライセンス対象か管理者か不明 | ent-copilot-business-users |
| sre | 対象Organizationや職責が曖昧 | ent-sre-reviewers |
接頭辞に ent- のようなルールを付けると、Organizationチームと区別しやすくなります。レビュー依頼用チームと管理者権限用チームは、同じメンバーでも分けておく方が安全です。レビュー依頼用チームに強い管理権限を持たせる必要はありません。
Organizationアクセスを付与したときの影響を確認する
Enterprise TeamにOrganizationアクセスを付与すると、そのチームのメンバーは対象Organizationへ追加され、Organizationメンバーとしての基本権限を受けます。公式ドキュメントでは、Outside collaboratorsやunaffiliated usersがチーム経由でOrganizationにアクセスすると標準のエンタープライズメンバーになり、GitHub Enterpriseライセンスを消費することが説明されています。(GitHub Docs)
これは便利な一方、ライセンス数や内部リポジトリへのアクセス範囲に影響します。特に外部協力会社、期間限定メンバー、監査用アカウントを含むチームでは、Organizationアクセスを付与する前に対象者を確認してください。
開発者・Platformチームが確認すべき点
Enterprise Teamsは管理者だけでなく、開発ワークフローにも影響します。Pull Request、Issue、Discussion、レビュー依頼、自動化ツールでチームを参照している場合は、移行時に動作確認が必要です。
Pull Requestレビュー依頼の宛先
Enterprise Teamsは、割り当てられているOrganization全体でPull Requestレビュワーとしてリクエストできます。セキュリティレビューやSREレビューを横断チームに依頼できるため、複数Organizationにまたがるプロダクト開発では便利です。(The GitHub Blog)
ただし、レビュー依頼先を広げすぎると通知が増え、重要なレビュー依頼が埋もれます。Enterprise Teamを作る際は、次のように用途を分けると運用しやすくなります。
| 用途 | チーム例 | 設計のポイント |
|---|---|---|
| セキュリティレビュー | ent-security-reviewers | 脆弱性対応や機密性の高い変更を確認できるメンバーに絞る |
| SREレビュー | ent-sre-reviewers | インフラ、可用性、運用影響を判断できるメンバーにする |
| 緊急対応 | ent-break-glass-operators | 少人数に限定し、監査ログ確認を前提にする |
| Copilot利用者 | ent-copilot-business-users | 権限付与用ではなくライセンス管理用として分離する |
ルールセットのバイパス権限
Repository rulesetsのバイパスアクターとしてEnterprise Teamsを選べるようになった点は、セキュリティ運用上のインパクトが大きい変更です。緊急障害時に、特定のPlatformチームへ一時的にバイパス権限を持たせるような運用がしやすくなります。(The GitHub Blog)
一方で、バイパス権限は強い権限です。通常のレビュー担当チーム、開発チーム、Copilotライセンス用チームと兼用しない方が安全です。実務では、次の3点をルール化してください。
1つ目は、バイパス権限を持つEnterprise Teamのメンバーを最小限にすることです。2つ目は、権限付与・削除の変更理由を記録することです。3つ目は、監査ログでバイパスイベントを定期確認することです。
APIと自動化の見直し
GitHub Docsでは、REST APIを使ってEnterprise Teamsの作成、取得、更新、削除、メンバー管理、Organization割り当てを管理できることが示されています。(GitHub Docs)
既存の運用スクリプトがOrganizationチームだけを対象にしている場合、Enterprise Teamsを導入しても棚卸しや権限レポートに反映されない可能性があります。特に次のような仕組みは見直しが必要です。
- チーム一覧をOrganization APIだけで収集している棚卸しスクリプト
- Pull Requestレビュワーをチーム名で自動指定するBot
- GitHub Appでチーム権限を同期している内製ツール
- 監査・セキュリティ部門向けの権限レポート
- Terraformや社内IaCでGitHubチームを管理している構成
公式発表では、Enterprise TeamsとOrganization Teamsを統合的なAPIビューから発見できるようになり、自動化ツールが別々のエンドポイントを問い合わせて全体像を組み立てる必要を減らせると説明されています。(The GitHub Blog)
移行時に失敗しやすいポイント
Enterprise Teamsは便利ですが、移行の進め方を誤ると、権限過多、ライセンス不足、通知過多、IdP同期エラーが起きます。特に次のポイントは事前に確認してください。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 既存チームを名前だけで統合する | 役割の違うチームをまとめ、不要な権限を広げる | メンバー・権限・用途を確認してから統合する |
| レビュー用と管理用を兼用する | 通知対象が広がり、強い権限も増える | 用途別にEnterprise Teamを分ける |
| Organizationアクセスの影響を見落とす | メンバー追加やライセンス消費が想定外に発生する | 対象Organizationとメンバー種別を事前確認する |
| IdPグループの制約を確認しない | 同期できない、または同期対象がずれる | Entra ID、OktaなどIdP側のグループ設計を確認する |
| 手動メンバーとIdP同期を混在させる | どちらが正なのか分からなくなる | IdP同期チームはIdP側を正とする |
| API・Botの参照先を更新しない | レビュー依頼や棚卸しがEnterprise Teamsを認識しない | 自動化ツールの対象APIと権限を確認する |
| 監査ログを見ない | 誰がいつ権限を変更したか追えない | 初期展開後は監査ログを重点確認する |
GitHub Docsでは、Enterprise Teamにユーザーを追加するとチームに関連付いた権限が付与され、削除するとその権限は外れる一方、ユーザー自体はエンタープライズアカウントから削除されないと説明されています。(GitHub Docs) 退職・異動時は「チームから外したか」だけでなく、「OrganizationやEnterpriseにユーザーが残っていないか」まで確認する運用が必要です。
IdP連携で注意すべきこと
Enterprise Managed Usersを使う企業では、IdPグループとEnterprise Teamsを同期することで、GitHub側のメンバー管理を大幅に減らせます。しかし、IdP連携はライセンス、グループ構造、同期エラーの3点でつまずきやすい領域です。
GitHub Docsによると、Enterprise TeamをIdPグループと同期する場合、チームに手動追加されたユーザーがいない状態にする必要があります。また、IdPグループが1チームあたり5,000ユーザーの上限を超えると同期が停止します。(GitHub Docs)
さらに、IdP同期でライセンス不足が発生すると「Out of sync due to insufficient licenses」と表示され、対象チームやOrganizationでメンバーが欠ける可能性があります。公式ドキュメントでは、利用可能ライセンスを確認し、不要なユーザーの削除または追加ライセンス購入で解消する流れが示されています。(GitHub Docs)
実務では、IdP管理者、GitHub Enterprise owner、ライセンス管理者が別々の部門にいることが多いため、同期エラー時の連絡先を決めておくことが重要です。エラーをGitHub管理者だけで抱えると、IdP側のグループ変更やライセンス追加が遅れ、開発者が必要なリポジトリにアクセスできない時間が長くなります。
導入手順の目安
Enterprise Teamsの導入は、全Organizationを一気に置き換えるより、用途を限定した段階展開が安全です。次の順序で進めると、影響を確認しながら移行できます。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 現状把握 | Organizationチーム、権限、Copilotライセンス、自動化を棚卸し | 同じ役割のチームが複数Organizationに重複しているか |
| 設計 | Enterprise Teamの命名、用途、管理責任者を決める | レビュー用、管理用、ライセンス用を分離できているか |
| 小規模展開 | 影響が小さい1〜2チームで作成・割り当てを試す | PRレビュー、通知、権限、監査ログが想定通りか |
| IdP連携 | Enterprise Managed Users環境ではSCIM同期を検証 | グループ制約、同期タイミング、ライセンス不足時の対応が明確か |
| 自動化更新 | API、Bot、棚卸しスクリプトをEnterprise Teams対応にする | Organizationチームだけを前提にした処理が残っていないか |
| 本格移行 | 重複チームを段階的にEnterprise Teamsへ寄せる | 旧チームの削除前にアクセス権とレビュー依頼の動作を確認したか |
| 定期監査 | 監査ログ、メンバー、ライセンス、バイパス権限を確認 | 退職者、異動者、不要な例外権限が残っていないか |
Enterprise Teamsの作成自体は、エンタープライズアカウントのPeopleタブからEnterprise teamsを開き、Create enterprise teamを選ぶ流れです。公式ドキュメントでも、エンタープライズへ移動し、PeopleからEnterprise teamsを開いて作成する手順が示されています。(The GitHub Blog)
管理者向けチェックリスト
本番展開前に、少なくとも次の項目を確認してください。
- Enterprise Teamsの用途を「レビュー」「管理権限」「Copilotライセンス」「緊急対応」で分けている
- Organizationチームとの重複を洗い出している
- Enterprise Teamに付与するOrganizationアクセスの範囲を確認している
- Outside collaboratorsやunaffiliated usersが標準メンバー化し、ライセンスを消費する可能性を確認している
- Copilotライセンスをチーム経由で付与する場合、ライセンス管理者と運用ルールを共有している
- IdP同期を使う場合、手動メンバーを残していない
- Entra ID利用時は、対象がセキュリティグループであることを確認している
- GitHub Apps、Bot、棚卸しスクリプトがEnterprise Teamsを認識できる
- ルールセットのバイパス権限を持つチームを最小化している
- 監査ログでチーム変更、メンバー変更、ロール割り当て、バイパスイベントを確認する運用がある
Enterprise Teamsは「権限の一元化」と「権限の拡散」を同時に起こし得る
Enterprise Teamsの価値は、複数Organizationにまたがるユーザー管理を一元化できることです。SRE、Security、Platform、Copilot利用者など、企業横断の役割を持つチームでは、管理工数と設定漏れを減らせます。
一方で、Enterprise Teamsはエンタープライズ全体に影響する管理単位です。チームに人を追加するだけで、Organizationアクセス、ロール、Copilotライセンス、レビュー通知、場合によってはルールセットのバイパス権限まで変わります。小さな変更が広い範囲に反映されるため、従来のOrganization単位の感覚で運用すると、権限過多やライセンス不足を招きます。
まずは既存チームの棚卸しから始め、影響範囲の小さいレビュー用チームやCopilotライセンス用チームで検証するのが現実的です。そのうえで、IdP連携、自動化、監査ログ、オフボーディング手順まで含めて運用設計を固めると、Enterprise Teamsを安全に本番展開できます。
コメント