GitHub Copilot Enterprise: przewodnik po Spaces i Usage Metrics API

Czym jest GitHub Copilot Enterprise?

GitHub Copilot Enterprise znajduje się na szczycie hierarchii planów Copilota w GitHub.

W porównaniu z GitHub Copilot Business lub Pro+, Enterprise mocno koncentruje się na nadzorze, kontekście organizacyjnym i możliwościach pomiaru. Jest zaprojektowany dla firm działających w dużych środowiskach inżynieryjnych, a nie dla pojedynczych deweloperów czy małych zespołów.

Dwie najważniejsze w praktyce możliwości:

1. Spersonalizowany kontekst organizacyjny dzięki Spaces
2. Telemetria w skali organizacji dzięki Usage Metrics API

Te dwie funkcje przesuwają Copilota z poziomu „sprytnego autouzupełniania” w stronę wewnętrznej platformy AI dla inżynierii.

Firmy, które czerpią największą wartość z GitHub Copilot Enterprise, traktują go jak kluczowy element wewnętrznej infrastruktury. Starannie konfigurują kontekst organizacyjny, stale mierzą adopcję i dostosowują polityki na podstawie danych o użyciu, a nie założeń.

Aby szerzej spojrzeć na ekosystem GitHuba, polecam nasz przewodnik Introduction to GitHub Products.

Czym Enterprise różni się od Business i Pro+

GitHub Copilot Enterprise rozwija subskrypcję Business o dodatkowe funkcje, takie jak:

• Metryki użycia na poziomie organizacji
• Rozszerzone mechanizmy nadzoru
• Dziedziczenie polityk w całym przedsiębiorstwie
• Większe pule żądań premium (1000 vs 300 w planie Business)
• Dostęp do dodatkowych modeli i ich zarządzanie

Enterprise wymaga GitHub Enterprise Cloud oprócz samej subskrypcji Copilot Enterprise. To zwiększa koszt na użytkownika, więc upewnij się, że twoja organizacja faktycznie potrzebuje nadzoru, telemetrii i administracji na poziomie enterprise.

Uwaga: Abonenci planu Business mają dostęp do Usage Metrics API na poziomie organizacji (/orgs/{org}/…). Abonenci Enterprise mają dodatkowo dostęp do zagregowanych raportów na poziomie całego przedsiębiorstwa (/enterprises/{enterprise}/…), obejmujących wszystkie organizacje w jednym widoku.

Dla kogo jest GitHub Copilot Enterprise

GitHub Copilot Enterprise jest skierowany do organizacji, które już działają w dojrzałych środowiskach GitHuba.

Typowi klienci Enterprise to:

• Duże organizacje inżynieryjne
• Branże regulowane
• Wielozespołowe grupy platform engineering
• Firmy z wewnętrznymi standardami rozwoju
• Organizacje wymagające scentralizowanego nadzoru

Zauważ, że to samo w sobie nie poprawia wydajności Copilota. Moim zdaniem to ważne rozróżnienie, ponieważ wiele zespołów na początku kupuje zbyt rozbudowane plany. Zakładają, że Enterprise oznacza „lepszego Copilota”, podczas gdy w rzeczywistości Enterprise dodaje głównie narzędzia do nadzoru i pomiaru.

Copilot Spaces: niestandardowy kontekst dla twojej organizacji

Copilot Spaces rozwiązują jedną z największych słabości ogólnych asystentów AI do kodowania.

Po wyjęciu z pudełka Copilot całkiem dobrze rozumie publiczną wiedzę programistyczną. Nie rozumie jednak automatycznie twoich wewnętrznych API, decyzji architektonicznych, konwencji kodowania, procesów wdrażania ani dokumentacji onboardingowej.

Spaces zapewniają wyselekcjonowany kontekst organizacyjny, do którego Copilot może się odwoływać podczas rozmów i asysty przy kodowaniu.

W praktyce Spaces pomagają Copilotowi odpowiadać na pytania typu:

• „Jak wewnętrznie strukturyzujemy handlery API?”
• „Jaką bibliotekę uwierzytelniania poleca nasz zespół platformowy?”
• „Którego workflow wdrożeniowego powinien użyć ten mikrousługa?”
• „Jakie konwencje nazewnicze stosuje nasz zespół backendowy?”

Co obsługują Spaces

Spaces obsługują szerszy zakres treści organizacyjnych niż starszy system Knowledge Bases.

Obsługiwane typy treści obejmują:

• Pliki z kodem
• Dokumentację w Markdown
• Pliki JSON
• Przesłane pliki
• Obrazy
• GitHub Issues
• Pull requesty

Każdy typ treści wnosi coś innego.

Pliki z kodem pomagają Copilotowi zrozumieć wzorce implementacji. Pliki Markdown dostarczają wyjaśnień architektury i wskazówek onboardingowych. Pull requesty odsłaniają dyskusje z review i historyczne decyzje inżynieryjne. To połączenie daje Copilotowi lepszą świadomość praktyk rozwoju w twojej organizacji.

Subtelny, ale ważny punkt: Spaces to nie tylko bazy wektorowe podpięte do GitHuba. Zawierają one kontrolę udostępniania i mechanizmy nadzoru organizacyjnego zaprojektowane dla środowisk enterprise.

Zmierzch Knowledge Bases

GitHub wygasił starszą funkcję Copilot Knowledge Bases 1 listopada 2025 r.

Spaces zastąpiły Knowledge Bases dzięki:

• Szerszemu wsparciu treści
• Lepszym kontrolom udostępniania
• Usprawnionej administracji
• Bardziej elastycznemu zarządzaniu na poziomie organizacji

Wciąż możesz trafić na nieaktualną dokumentację i wpisy na blogach odwołujące się do Knowledge Bases. Zachowaj ostrożność, śledząc starsze tutoriale, ponieważ wiele endpointów i workflow zmieniło się w okresie przejściowym 2025–2026.

Tworzenie i konfigurowanie Copilot Spaces

Z perspektywy administracyjnej tworzenie Copilot Spaces jest dość proste. Wyzwanie pojawia się przy zarządzaniu dziesiątkami lub setkami przestrzeni w różnych zespołach.

Struktura wybrana na początku zwykle zostaje na dłużej. Widziałem organizacje, które przypadkiem tworzyły „rozrost dokumentacji” w Spaces, bo nikt nie ustalił zasad właścicielstwa na starcie.

Każdy może utworzyć Copilot Space, więc przetestujmy stworzenie jednej w naszym osobistym repo. Kroki są podobne na poziomie Enterprise, choć z kilkoma innymi stronami.

Konfigurowanie Space

Tworzenie Space zazwyczaj przebiega tak:

1. Przejdź do strony Copilot Spaces w obszarze administracji Enterprise
2. Utwórz nową Space

3. Wybierz repozytoria i źródła treści, w tym MCP i inne przydatne narzędzia

4. Dodawanie źródeł możliwe jest po kliknięciu przycisku „+ Add sources” po prawej stronie

5. Na tym etapie możesz wybrać udostępnianie przestrzeni lub skonfigurować ustawienia udostępniania

6. Sprawdź, czy Copilot może odwoływać się do treści podczas interakcji na czacie

Uwaga dla użytkowników enterprise: administrator może wyłączyć udostępnianie osobistych Spaces. Jeśli korzystasz z własnego konta, może to wpływać na możliwość udostępniania Copilot Space, która nie używa repozytoriów przedsiębiorstwa.

Po konfiguracji administratorzy powinni przetestować Space przy użyciu praktycznych promptów.

Na przykład:

How does our authentication middleware handle token refresh logic?

Albo:

Show me an example of how our backend services structure database migrations.

Jeśli Copilot nie potrafi odpowiedzieć precyzyjnie, zwykle problemem jest jedno z poniższych:

• Brakujące repozytoria
• Słaba jakość dokumentacji
• Nieprawidłowe uprawnienia
• Niewystarczający czas indeksowania

Udostępnianie i kontrola dostępu

Spaces obsługują dwa główne modele widoczności:

• Spaces indywidualne
• Spaces organizacyjne

Członkowie przedsiębiorstwa mogą mieć swoje indywidualne spaces zarządzane przez szersze ustawienia enterprise. Administratorzy enterprise mogą też centralnie zarządzać zasadami dostępu do wersji preview i dostępnością funkcji. 

Prywatne Spaces sprawdzają się dla zespołów eksperymentalnych lub wrażliwych inicjatyw wewnętrznych. Spaces organizacyjne mają sens dla standardów inżynieryjnych, dokumentacji onboardingowej lub firmowych frameworków.

Częsty błąd, który widzę, to nadmierna centralizacja. Jedna, gigantyczna przestrzeń firmowa może stać się hałaśliwa i trudna do efektywnego wykorzystania przez Copilota.

Organizowanie Spaces według zespołu lub domeny

Nie istnieje uniwersalnie poprawna struktura organizacyjna.

Popularne wzorce to jedna przestrzeń na zespół, jedna przestrzeń na obszar produktowy lub współdzielone przestrzenie standardów. Każdy z nich ma inny zakres i w zasadzie wykorzystuje te same ustawienia nieco inaczej.

Jedna Space na zespół

Przydatne, gdy grupy inżynieryjne działają względnie niezależnie.

Przykłady:

• Platform engineering
• Data engineering
• Rozwój mobilny

Jedna Space na obszar produktowy

Przydatne w organizacjach zbudowanych wokół produktów, a nie działów.

Przykłady:

• Płatności
• Analityka
• Infrastruktura
• Platforma klienta

Współdzielona Space standardów

Wiele organizacji utrzymuje oddzielną współdzieloną Space dla:

• Wytycznych bezpieczeństwa
• Konwencji kodowania
• Workflow wdrożeniowych
• Standardów architektury

W praktyce najlepiej działa podejście hybrydowe. Każdy zespół może mieć własną przestrzeń, a większe przestrzenie standardów są współdzielone między zespołami.

Copilot Usage Metrics API

Spaces rozwiązują problem kontekstu. Usage Metrics API rozwiązuje problem pomiaru. Zastąpiło kilka starszych systemów telemetrii, które GitHub wycofał podczas konsolidacji API w 2026 r. 

Bez przejrzystych pomiarów organizacje szybko tracą wgląd w to, czy adopcja Copilota się udaje. Kierownictwo oczekuje dowodów, że inwestycja usprawnia przepływy pracy deweloperów, a nie tylko dodaje kolejny koszt subskrypcji.

Dashboard osiągnął dostępność ogólną w lutym 2026 r. i jest dostępny przez twoje konto enterprise → AI Controls → Copilot → Metrics → Copilot usage metrics w zakładce Insights.

Przykładowy Copilot Usage Metrics Dashboard z github.blog

Co mierzy API

Usage Metrics API udostępnia kilka kategorii operacyjnej telemetrii.

Typowe metryki obejmują:

• Aktywnych użytkowników
• Proponowane linie kodu vs zaakceptowane linie kodu
• Wzorce użycia IDE
• Wykorzystanie modeli
• Interakcje z agentami
• Podziały według języków

Daje to organizacjom o wiele bardziej zniuansowany obraz niż proste liczenie licencji.

Zespół ze 100 przydzielonymi licencjami, ale tylko 15 aktywnymi użytkownikami, ma zupełnie inny profil adopcji niż zespół z konsekwentnym codziennym użyciem i wysokimi wskaźnikami akceptacji.

Przejście na API w 2026 r.

GitHub wycofał wiele wcześniejszych API telemetrii (User-level Feature Engagement Metrics API, Direct Data Access API, Copilot Metrics API) w okresie 2025–2026, całkowicie wygaszając je w kwietniu 2026 r.

Obejmowało to:

• Przestarzałe Metrics API
• Feature Engagement APIs
• Direct Data Access APIs

Nowsze endpointy Usage Metrics, dostępne od lutego 2026 r., skonsolidowały te systemy raportowania w bardziej ujednolicony model, w tym wersjonowanie API na wypadek zmian niezgodnych wstecz.

To ważne, ponieważ wiele starszych wpisów na blogach i przykładów GitHuba nadal odwołuje się do przestarzałych endpointów. Zawsze weryfikuj dokumentację w najnowszych referencjach API GitHuba, zanim zbudujesz wokół niej automatyzację.

Odpytywanie Usage Metrics API

Skoro rozumiemy cel usage metrics API, porozmawiajmy o tym, jak używać go w praktyce.

Uwierzytelnianie i uprawnienia

Endpointy GitHub Copilot Usage Metrics zazwyczaj wymagają ustawienia kilku uprawnień dla twojego Personal Access Token (PAT). Można to zrobić zarówno przez klasyczny PAT, jak i fine-grained PAT.

• Dla klasycznych PAT administrator enterprise musi nadać ci następujące uprawnienia: manage_billing:copilot oraz read:org. 

• Dla fine-grained tokenów musisz upewnić się, że używasz tokena dostępu użytkownika aplikacji GitHub lub tokena dostępu instalacji z uprawnieniem Enterprise Copilot metrics enterprise permissions (read).

Zazwyczaj preferowane są fine-grained tokeny, ponieważ ograniczają niepotrzebną ekspozycję uprawnień.

Endpointy na poziomie organizacji

Dwa najczęstsze raporty na poziomie organizacji to:

• organization-1-day

• organization-28-day

Jednodniowy raport na poziomie organizacji

Raport jednodniowy dobrze sprawdza się do monitorowania operacyjnego i analizy krótkoterminowych trendów. Dane historyczne są dostępne od 10 października 2025 r. i można je pobierać do roku wstecz od bieżącej daty.

Poniższa komenda curl wywoła API metryki raportu jednodniowego i zwróci odpowiedź JSON z linkami do pobrania raportów użycia. Musisz uwzględnić YOUR_TOKEN dla autoryzacji bearer i wybrać DAY dla konkretnego dnia raportu w formacie YYYY-MM-DD.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

Adresy URL w download_links są podpisane i czasowo ograniczone, co oznacza, że wygasają wkrótce po ich pobraniu. Twój workflow musi pobrać URL i od razu ściągnąć plik w tym samym przebiegu; nie możesz przechowywać tych URL-i do późniejszego użycia.

Odpowiedź, którą otrzymasz, może zawierać tylko download_links i report_day, ale pełny, możliwy schemat wygląda tak:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28-dniowy raport na poziomie organizacji

Raport 28-dniowy pomaga identyfikować szersze wzorce adopcji i długoterminowe zmiany w użyciu. Polecenia są bardzo podobne, z drobną zmianą na API 28-dniowe.

Przykładowe żądanie:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Otrzymasz podobną odpowiedź, z tą różnicą, że pojawią się response_start_day i response_end_day.

Struktura raportów na poziomie organizacji

Raporty JSON dla zarówno jednodniowych, jak i 28-dniowych raportów organizacyjnych mogą wyglądać mniej więcej tak:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Jak widać, daje to przegląd użytkowników w danej organizacji, ich zespołów i tagów zespołowych. 

Endpointy na poziomie użytkownika

Raporty na poziomie użytkownika zapewniają bardziej szczegółową widoczność adopcji. Oznacza to, że możesz zrozumieć, jak poszczególne osoby korzystają z Copilota na bardzo wysokim poziomie.

Typowe endpointy obejmują:

• users-1-day

• users-28-day

• user-teams-1-day

Te raporty pomagają administratorom identyfikować:

• Bardzo aktywnych użytkowników
• Zespoły o niskiej adopcji
• Możliwości szkoleniowe
• Trendy użycia na poziomie działów

Żądania są bardzo podobne do raportów jednodniowych i 28-dniowych na poziomie organizacji; wskazują jedynie na inne API.

Jednodniowy raport na poziomie użytkownika

Przykładowe wywołanie API users-1-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28-dniowy raport na poziomie użytkownika

Przykładowe wywołanie API users-28-day:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Jednodniowy raport user-teams-level

Istnieje też endpoint user-teams-1-day, który mapuje każdego użytkownika na przynależności zespołowe. Sam nie zawiera metryk użycia; jego celem jest posłużenie jako klucz do łączenia, gdy chcesz agregować dane per-user według zespołu.

Struktura raportów na poziomie użytkownika

Poziom szczegółowości tych raportów jest dużo wyższy, ponieważ odnoszą się do danych użycia konkretnego użytkownika:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Te metryki są najcenniejsze jako sygnały adopcji na poziomie zespołu. Wskaźniki akceptacji i liczby użyć to sygnały operacyjne, a nie miary jakości dewelopera.

Pełny zestaw potencjalnych metryk znajdziesz w dokumentacji danych dotyczących metryk użycia GitHuba, która jest na bieżąco aktualizowana.

Raporty na poziomie użytkownika obejmują dane o interakcjach przez CLI. Jeśli twoje zespoły używają Copilota z wiersza poleceń, nasz GitHub Copilot CLI Tutorial omawia konfigurację i typowe workflow.

Budowanie workflow raportowania dla Copilota

Ręczne wywoływanie API jest przydatne do eksperymentów i zrozumienia schematu. Aby było to użyteczne operacyjnie, lepiej stworzyć zautomatyzowany workflow.

Zespoły, które wyciągają najwięcej z Copilot Enterprise, zwykle budują lekkie potoki raportowania łączące telemetrię użycia z wewnętrznymi metrykami inżynieryjnymi.

Kluczowe metryki do udowodnienia ROI

Nie każda metryka Copilota ma takie samo znaczenie. Najbardziej przydatne zwykle obejmują:

• Wzrost liczby aktywnych użytkowników
• Trendy wskaźników akceptacji
• Proponowany kod vs utrzymany kod
• Skrócenie czasu cyklu PR
• Częstotliwość korzystania z IDE

GitHub opublikował m.in. takie benchmarki:

• 55% szybsza realizacja zadań
• 88% wskaźnik utrzymania kodu

Te liczby pokazują znaczące wzrosty produktywności. Twoje wyniki będą się różnić w zależności od zespołu i workflow, co dokładnie uzasadnia istnienie Usage Metrics API. Zespół backendowej infrastruktury może korzystać z Copilota inaczej niż zespół od prototypowania frontendu.

Od surowych danych do dashboardu zespołowego

Lekki workflow raportowania często wygląda tak:

1. Zaplanowane wywołanie API
2. Przechowywanie odpowiedzi w bazie danych lub arkuszu
3. Transformacja danych do tabel raportowych
4. Wizualizacja metryk w istniejącej platformie BI

Sam stos technologiczny ma mniejsze znaczenie niż konsekwencja.

Nawet prosty workflow z zaplanowanymi skryptami Pythona i eksportami CSV może zapewnić użyteczną widoczność operacyjną.

Przykładowa architektura:

GitHub API

  ↓

Zaplanowany skrypt w Pythonie

  ↓

PostgreSQL / CSV / Arkusz kalkulacyjny

 ↓

Power BI / Tableau / Looker

Na zakończenie

GitHub Copilot Enterprise tak naprawdę służy do budowania infrastruktury pod kod gotowy na AI. Spaces dostarcza kontekst organizacyjny, który sprawia, że Copilot jest bardziej użyteczny w prawdziwych środowiskach inżynieryjnych. Usage Metrics API zapewnia telemetrię potrzebną do zrozumienia, czy adopcja przynosi efekty.

Organizacje uzyskujące najsilniejsze rezultaty z Copilot Enterprise zwykle mają wspólny wzorzec:

• Starannie kurują wewnętrzny kontekst
• Nieustannie monitorują adopcję
• Poważnie traktują nadzór nad Copilotem
• Mierzą wyniki zamiast zakładać wzrost produktywności

To podejście ma o wiele większe znaczenie niż samo przydzielanie licencji.

Jeśli chcesz pogłębić swoje umiejętności Copilot i AI, polecam kurs Software Development with GitHub Copilot lub pełną ścieżkę AI for Software Engineering.