GitHub Copilot Enterprise: przewodnik po Spaces i Usage Metrics API

Czym jest GitHub Copilot Enterprise?

GitHub Copilot Enterprise zajmuje najwyższe miejsce w hierarchii planów Copilota GitHuba.

W porównaniu z GitHub Copilot Business lub Pro+ plan Enterprise mocno stawia na nadzór, kontekst organizacyjny i możliwości pomiarowe. Został 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 to:

1. Własny kontekst organizacyjny dzięki Spaces
2. Telemetria w skali organizacji przez Usage Metrics API

Te dwie funkcje przesuwają Copilota od „sprytnego autouzupełniania” w stronę czegoś bliższego wewnętrznej platformie AI dla inżynierii.

Firmy, które czerpią najwięcej wartości 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 skali całego przedsiębiorstwa
• Większe pule premium requestów (1000 vs 300 w planie Business)
• Dodatkowy dostęp do modeli i ich zarządzania

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

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

Dla kogo jest GitHub Copilot Enterprise

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

Typowi klienci Enterprise to:

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

Zwróć uwagę, że to samo w sobie nie poprawia wydajności Copilota. Uważam, że to rozróżnienie ma znaczenie, bo wiele zespołów początkowo kupuje na wyrost. Zakładają, że Enterprise oznacza „lepszego Copilota”, podczas gdy w rzeczywistości Enterprise dodaje głównie narzędzia do nadzoru i pomiarów.

Copilot Spaces: niestandardowy kontekst dla twojej organizacji

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

Domyślnie Copilot całkiem dobrze rozumie publiczną wiedzę programistyczną. Nie rozumie jednak automatycznie twoich wewnętrznych API, decyzji architektonicznych, konwencji kodowania, przepływów wdrożeń ani dokumentacji onboardingowej.

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

W praktyce Spaces pomagają Copilotowi odpowiadać na pytania takie jak:

• „Jak wewnętrznie strukturyzujemy handlery API?”
• „Jakiej biblioteki uwierzytelniania rekomenduje nasz zespół platformowy?”
• „Którego workflowu wdrożeniowego powinien użyć ten mikroserwis?”
• „Jakie konwencje nazewnictwa 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 w review i historyczne decyzje inżynieryjne. To połączenie daje Copilotowi lepszą świadomość praktyk rozwojowych twojej organizacji.

Subtelny, ale ważny punkt: Spaces to nie tylko wektorowe bazy danych podłączone do GitHuba. Obejmują też mechanizmy udostępniania i przepływy nadzoru organizacyjnego zaprojektowane dla środowisk enterprise.

Zmierzch Knowledge Bases

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

Spaces zastąpiły Knowledge Bases, oferując:

• Szerszą obsługę treści
• Lepsze mechanizmy udostępniania
• Ulepszoną administrację
• Bardziej elastyczne zarządzanie na poziomie organizacji

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

Tworzenie i konfigurowanie Copilot Spaces

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

Struktura wybrana na początku ma tendencję do utrwalania się. Widziałem organizacje, które przypadkowo doprowadziły do „rozrostu dokumentacji” w Spaces, bo nikt z góry nie ustalił zasad własności.

Każdy może utworzyć Copilot Space, więc przetestujmy to w naszym osobistym repozytorium. Te kroki są podobne na poziomie Enterprise, z kilkoma innymi stronami.

Zakładanie Space

Tworzenie Space zwykle wygląda 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ł odbywa się przez kliknięcie przycisku „+ Add sources” po prawej stronie

5. Na tym etapie możesz udostępnić space lub skonfigurować ustawienia udostępniania

6. Zweryfikuj, że Copilot może odwoływać się do treści podczas rozmów

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

Po konfiguracji administratorzy powinni przetestować Space praktycznymi promptami.

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ć trafnie, problem zwykle leży w:

• Brakujących repozytoriach
• Niskiej jakości dokumentacji
• Nieprawidłowych uprawnieniach
• Niewystarczającym czasie na indeksację

Udostępnianie i kontrola dostępu

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

• Spaces indywidualne
• Spaces organizacyjne

Członkowie enterprise mogą mieć swoje indywidualne spaces zarządzane przez nadrzędne ustawienia enterprise. Administratorzy enterprise mogą też centralnie zarządzać politykami dostępu do funkcji i wersji preview. 

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

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

Organizowanie Spaces według zespołu lub domeny

Nie ma jednej uniwersalnie poprawnej struktury organizacyjnej.

Popularne wzorce to jedna space na zespół, jedna space na obszar produktu lub współdzielone spaces ze standardami. Każda ma inny zakres i zasadniczo używa tych samych ustawień w inny sposób.

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 produktu

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

Przykłady:

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

Współdzielona Space ze standardami

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

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

W praktyce najlepiej zwykle sprawdzają się podejścia hybrydowe. Każdy zespół może mieć własną space, a większe spaces ze standardami 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 ono kilka starszych systemów telemetrii, które GitHub wycofał podczas konsolidacji API w 2026 r. 

Bez klarownych pomiarów organizacje szybko tracą wgląd w to, czy adopcja Copilota się udaje. Kierownictwo chce dowodów, że inwestycja usprawnia workflowy deweloperów, a nie jedynie dodaje kolejny abonament do kosztów.

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

Przykład pulpitu Copilot Usage Metrics z github.blog

Co mierzy API

Usage Metrics API udostępnia kilka kategorii telemetrii operacyjnej.

Typowe metryki to:

• Aktywni użytkownicy
• Proponowane linie kodu vs zaakceptowane linie kodu
• Wzorce użycia IDE
• Użycie modeli
• Interakcje z agentem
• Podziały według języków

To daje organizacjom znacznie bardziej zniuansowany obraz niż zwykłe liczenie licencji.

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

Przejście API w 2026 r.

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

Obejmowały one:

• Legacy 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, który obejmuje wersjonowanie API na wypadek zmian niezgodnych wstecz.

To istotne, bo wiele starszych wpisów na blogach i przykładów GitHuba wciąż odwołuje się do przestarzałych endpointów. Pracując z Usage Metrics API, zawsze weryfikuj dokumentację względem najnowszych referencji API GitHuba, zanim zbudujesz na tym automatyzację.

Odpytywanie Usage Metrics API

Skoro rozumiemy cel Usage Metrics API, porozmawiajmy o praktycznym użyciu.

Uwierzytelnianie i uprawnienia

Endpointy GitHub Copilot Usage Metrics zazwyczaj wymagają skonfigurowania kilku uprawnień dla twojego Personal Access Token (PAT). Można to zrobić przez klasyczny PAT albo fine-grained PAT.

• Dla klasycznych PAT potrzebujesz, by administrator enterprise przyznał ci uprawnienia: manage_billing:copilot i read:org. 

• Dla fine-grained access tokens musisz upewnić się, że używasz tokena dostępu użytkownika aplikacji GitHub lub tokena instalacji z zestawem uprawnień Enterprise Copilot metrics enterprise permissions (read).

Zwykle preferowane są tokeny fine-grained, 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 monitoringu operacyjnego i krótkoterminowej analizy 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ższe polecenie curl wywoła API raportu jednodniowego i zwróci odpowiedź JSON z linkami do pobrania raportów użycia. Musisz uwzględnić YOUR_TOKEN dla uwierzytelniania bearer oraz 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 ograniczone czasowo, co oznacza, że wygasają wkrótce po ich pobraniu. Twój workflow musi pobrać adres URL i natychmiast ściągnąć plik w tym samym przebiegu; nie możesz przechowywać tych adresów do późniejszego użycia.

Odpowiedź może zawierać jedynie download_links i report_day, ale to pełny możliwy schemat:

{
  "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 użycia. Polecenia są bardzo podobne, z drobną zmianą na endpoint 28-dniowy.

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 jednodniowego i 28-dniowego raportu organizacyjnego mogą wyglądać 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 ogólny wgląd w użytkowników w danej organizacji, ich zespół i tagi zespołowe. 

Endpointy na poziomie użytkownika

Raporty na poziomie użytkownika dają bardziej szczegółowy wgląd w adopcję. Oznacza to, że możesz zrozumieć, jak poszczególne osoby używają 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

Te żądania są bardzo podobne do raportów jednodniowych i 28-dniowych na poziomie organizacji; wskazują po prostu na inny 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

Istnieje też endpoint user-teams-1-day, który mapuje każdego użytkownika na jego członkostwa w zespołach. Sam nie zawiera metryk użycia; jego celem jest służyć jako klucz łączenia, gdy chcesz agregować dane per użytkownik według zespołu.

Struktura raportów na poziomie użytkownika

Poziom szczegółowości w tych raportach jest znacznie wyższy, ponieważ dotyczą 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łów. Wskaźniki akceptacji i liczniki użycia to sygnały operacyjne, a nie miary jakości deweloperów.

Aby zobaczyć pełny zakres potencjalnych metryk, odwiedź najnowszą dokumentację danych metryk użycia GitHuba.

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

Budowanie workflowu raportowania 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 czerpią największą wartość 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 jednakowe znaczenie. Najbardziej użyteczne to zwykle:

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

GitHub opublikował benchmarki, takie jak:

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

Te liczby pokazują znaczące wzrosty produktywności. Twoje wyniki będą się różnić w zależności od zespołu i workflowu, co dokładnie uzasadnia istnienie Usage Metrics API. Zespół backendu 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 stack jest mniej istotny niż konsekwencja.

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

Przykładowa architektura:

GitHub API

  ↓

Zaplanowany skrypt w Pythonie

  ↓

PostgreSQL / CSV / Arkusz kalkulacyjny

  ↓

Power BI / Tableau / Looker

Na koniec

GitHub Copilot Enterprise to przede wszystkim budowanie infrastruktury pod kod gotowy na AI. Spaces dostarczają kontekstu organizacyjnego, który sprawia, że Copilot jest bardziej użyteczny w realnych środowiskach inżynieryjnych. Usage Metrics API zapewnia telemetrię potrzebną do zrozumienia, czy adopcja się powodzi.

Organizacje osiągające najsilniejsze rezultaty z Copilot Enterprise zwykle wykazują wspólny wzorzec:

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

Takie podejście ma znacznie większe znaczenie niż samo przydzielanie licencji.

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