GitHub Copilotの利用状況を「組織全体」ではなく「チーム単位」で見たい管理者にとって、今回の Team-level Copilot usage metrics now available via API は重要な更新です。結論から言うと、Copilot usage metrics APIに新しい user-teams レポートが追加され、Copilotライセンスを持つユーザーと所属チームの対応関係をAPI経由で取得できるようになりました。これにより、既存のユーザー別利用レポートと結合して、チームごとのアクティブユーザー数、コード生成、チャット利用、言語別・IDE別・機能別・モデル別の利用状況を集計できます。(The GitHub Blog)
ただし、この機能は「チーム別の完成済みダッシュボード」が追加されたわけではありません。REST APIで日次レポートを取得し、user_id、day、組織またはEnterpriseのIDで結合して集計する仕組みです。小規模チームの除外、複数チーム所属ユーザーの二重カウント、28日レポートとの誤った結合など、運用前に押さえるべき注意点があります。この記事では、GitHubの公式情報をもとに、変更点、影響範囲、管理者・開発者が確認すべき設定と展開時の落とし穴を整理します。
GitHubのAI/Copilot更新で何が変わるのか
今回の更新では、Copilot usage metrics APIに user-teams-1-day レポート が追加されました。これは、ある日付において「どのCopilotライセンスユーザーが、どのチームに所属していたか」を表す日次レポートです。GitHub Changelogでは2026年5月14日付のReleaseとして掲載されています。(The GitHub Blog)
従来、Copilotの利用状況をAPIで確認する場合、組織単位・Enterprise単位・ユーザー単位の集計が中心でした。今回の追加により、ユーザー別利用レポートとチーム所属レポートを突き合わせることで、次のような問いに答えやすくなります。
- どの開発チームがCopilotをよく使っているか
- 導入したが利用が伸びていないチームはどこか
- IDE補完、チャット、Copilot CLI、コードレビュー、クラウドエージェントなどの利用傾向がチームごとに違うか
- 言語別、IDE別、機能別、モデル別に見たとき、支援すべきチームはどこか
特に大規模なEnterprise環境では、全社平均だけを見ても改善アクションにつながりにくいことがあります。チーム別のCopilot利用メトリクスを作れるようになると、「全社でCopilot利用率を上げる」ではなく、「バックエンドチームはチャット利用が少ないためユースケース共有会を行う」「モバイルチームは特定IDEで利用が偏っているため設定確認を行う」といった具体的な施策に落とし込めます。
追加されたAPIエンドポイント
今回追加された中心的なエンドポイントは、Organization向けとEnterprise向けの2種類です。どちらも、指定した1日分の user-teams レポートを取得するために使います。
| 対象 | エンドポイント | 主な用途 |
|---|---|---|
| Organization | GET /orgs/{org}/copilot/metrics/reports/user-teams-1-day?day=YYYY-MM-DD | 組織内チームごとのCopilot利用状況を作る |
| Enterprise | GET /enterprises/{enterprise}/copilot/metrics/reports/user-teams-1-day?day=YYYY-MM-DD | Enterpriseチーム、business teamを含むチーム単位の利用状況を作る |
GitHub Docsでは、これらのエンドポイントは指定日のレポートファイルへのダウンロードリンクを返すと説明されています。レスポンス本文にユーザー行やチーム行が直接入るのではなく、download_links に含まれる署名付きURLからレポートファイルを取得する流れです。(GitHub Docs)
実務では、API呼び出しとファイル取得を分けて考える必要があります。監査やBI連携のためにバッチ処理を組む場合は、次のような処理になります。
| 手順 | 作業 | 注意点 |
|---|---|---|
| 1 | 対象日を決める | day=YYYY-MM-DD 形式で指定する |
| 2 | user-teams-1-day エンドポイントを呼ぶ | OrganizationかEnterpriseかを間違えない |
| 3 | 返ってきた download_links からファイルを取得する | リンクは期限付きのため、後回しにしない |
| 4 | 同じ日のユーザー別利用レポートを取得する | users-1-day と組み合わせる |
| 5 | user_id、day、organization_id または enterprise_id で結合する | 28日レポートと混ぜない |
| 6 | team_id、slug 単位で集計する | 複数チーム所属ユーザーの扱いに注意する |
チーム別メトリクスは「取得する」ものではなく「作る」もの
ここで最も重要なのは、GitHubがチーム別に集計済みの単一レポートを提供しているわけではない点です。公式ドキュメントでも、チームレベルのメトリクスは、日次の user-teams レポートと日次のユーザー別利用レポートを結合して作るものと説明されています。(GitHub Docs)
具体的には、次の2つのレポートを使います。
| 作りたいメトリクス | チーム所属レポート | 利用状況レポート | 結合キー |
|---|---|---|---|
| Organizationチーム別 | organization_user_teams_1_day | organization_users_1_day | user_id, day, organization_id |
| Enterprise / business team別 | enterprise_user_teams_1_day | users_1_day | user_id, day, enterprise_id |
集計時は、team_id と slug でグループ化します。アクティブユーザー数のような人数系の指標は COUNT(DISTINCT user_id)、コード生成回数や追加行数などの量的指標は SUM(...) で集計します。(GitHub Docs)
たとえば、組織内の frontend チームと backend チームに同じユーザーが所属している場合、そのユーザーのCopilot利用実績は両方のチームに反映されます。これは「そのチームのメンバーがどれだけCopilotを使っているか」を見る目的には合っています。一方で、チーム別の合計を足し合わせて組織全体の利用数を再現しようとすると、複数チーム所属ユーザーの分だけ二重カウントが発生します。組織全体やEnterprise全体の総数を見たい場合は、チーム結合後の結果ではなく、ユーザー別または組織・Enterprise単位のレポートを使うべきです。
管理者が得られる実務上のメリット
今回の更新は、単にAPI項目が増えたというより、Copilot導入後の「可視化」と「定着支援」の精度を上げる変更です。
チームごとの導入状況を比較できる
全社平均では、利用が進んでいるチームと停滞しているチームが混ざって見えます。チーム別に見ることで、管理者は次のような判断ができます。
| 見える指標 | 判断できること | 次のアクション例 |
|---|---|---|
| アクティブユーザー数 | ライセンス付与後に実際に使われているか | 未利用者へのオンボーディング |
| コード生成・受け入れ関連の指標 | IDE補完や生成支援が定着しているか | IDE設定、拡張機能、利用ガイドの確認 |
| チャット利用 | 調査・設計・レビュー補助に使われているか | チャット活用例の共有 |
| 言語別利用 | チームの技術スタックに合った使われ方か | 言語別プロンプト例の整備 |
| IDE別利用 | 特定IDEで利用が偏っていないか | 開発環境ごとの設定確認 |
| モデル・機能別利用 | 高度な機能が活用されているか | Copilot Chat、Code review、CLIなどの研修 |
Copilotの費用対効果を説明する場合も、組織全体の数値だけでは「何を改善すればよいか」が見えにくいものです。チーム単位で可視化できれば、ライセンス配布、トレーニング、活用事例の共有をより現場に合わせて実施できます。
利用が進んでいるチームを「社内チャンピオン」にできる
Copilotの展開では、利用率の低いチームだけを見るのではなく、うまく使っているチームを見つけることも重要です。チーム別メトリクスを使うと、利用が進んでいるチームの開発プロセスやプロンプトの使い方を社内展開できます。
たとえば、次のような施策が考えられます。
frontendチームでチャット利用が多い場合、UI実装時の質問例を社内WikiにまとめるplatformチームでCopilot CLIの利用が多い場合、運用自動化の具体例を共有するbackendチームでコードレビュー機能の利用が増えている場合、Pull Requestレビュー手順に組み込む
メトリクスは評価や監視のためだけに使うと反発を招きやすくなります。導入推進では、「うまく使っているチームの知見を横展開する」目的を明確にした方が、現場の納得感を得やすいです。
利用できる権限とトークンを確認する
このAPIを使うには、対象がOrganizationかEnterpriseかによって必要な権限が異なります。
| 対象 | 利用できる主なロール・権限 | トークンで確認すべき点 |
|---|---|---|
| Enterprise | Enterprise owner、billing manager、View Enterprise Copilot Metrics 権限を持つユーザーなど | Fine-grained tokenでは Enterprise Copilot metrics のread権限。OAuth app tokenやclassic PATでは manage_billing:copilot または read:enterprise が必要 |
| Organization | Organization owner、View Organization Copilot Metrics 権限を持つユーザーなど | Fine-grained tokenでは Organization Copilot metrics のread権限。OAuth app tokenやclassic PATでは read:org が必要 |
GitHub Docsでは、Enterprise向けエンドポイントとOrganization向けエンドポイントで、それぞれ利用できるトークン種別と必要な権限が示されています。Organization向けではGitHub App user access token、GitHub App installation access token、fine-grained personal access tokenが対象に含まれます。(GitHub Docs)
展開前に確認したいのは、単に「管理者アカウントでAPIが呼べるか」ではありません。継続的にレポートを取得するなら、個人のPATに依存しない設計が望ましいです。可能であれば、GitHub Appや専用の運用アカウントを使い、最小権限で定期取得できるようにしておくと、退職・異動・権限変更による停止リスクを減らせます。
開発者・データ担当者が設計時に注意すべきポイント
28日レポートと日次のuser-teamsレポートを結合しない
最も失敗しやすいのは、既存の28日ユーザー別レポートと、ある1日の user-teams レポートを結合してしまうケースです。
user-teams レポートは、指定した1日のチーム所属を表します。もし28日分の利用実績を1日の所属情報に結合すると、期間中にチーム異動したユーザーの利用実績が誤ったチームに割り当てられます。公式ドキュメントでも、28日ユーザー別レポートと日次 user-teams レポートを結合しないよう警告されています。複数日集計を作る場合は、日ごとに日次利用レポートと日次チーム所属レポートを結合し、その後で集計する必要があります。(GitHub Docs)
正しい28日集計の考え方
| NG | OK |
|---|---|
users_28_day と、ある日の user-teams-1-day を結合する | 28日分それぞれで users-1-day と user-teams-1-day を結合し、最後に集計する |
| 日次アクティブユーザー数を28日分足す | 全期間の結合結果に対して COUNT(DISTINCT user_id) を計算する |
| チーム異動を考慮しない | 各日の所属チームにその日の利用実績を割り当てる |
量的指標、たとえばコード生成回数や追加行数は日次合計を足し上げられます。一方、ユニークユーザー数は日別の数値を単純合算すると同じユーザーを複数回数えるため、期間全体で重複排除する必要があります。(GitHub Docs)
5席未満のCopilotユーザーがいるチームは除外される
user-teams レポートでは、Copilotのシートを持つユーザーが5人未満のチームは除外されます。該当チームのメンバーにCopilot利用実績があっても、チーム所属レポート側に行が存在しないため、チーム別集計には現れません。(The GitHub Blog)
これは小規模チームや兼務チームが多い組織では特に重要です。たとえば、3人のSREチームが活発にCopilotを使っていても、user-teams レポート上はチームとして見えない可能性があります。そのため、チーム別メトリクスを経営報告や部門比較に使う場合は、「5席未満のチームは集計対象外になる可能性がある」と明記した方が誤解を防げます。
複数チーム所属ユーザーは各チームにカウントされる
1人のユーザーが複数チームに所属している場合、そのユーザーの活動は所属する各チームの集計に反映されます。これはチームごとの利用実態を見るには自然ですが、チーム別集計を合算して組織全体の数値として扱うと、重複カウントになります。(The GitHub Blog)
実務上は、ダッシュボードに次のような注記を入れるとよいでしょう。
チーム別の値は、所属メンバーの利用実績をチームごとに集計したものです。複数チームに所属するユーザーは各チームに反映されるため、チーム別合計は組織全体の合計と一致しません。
この注記がないと、管理者会議で「チーム別合計が組織全体の合計より大きい、または小さいのはなぜか」という不要な混乱が起きやすくなります。
どの指標をチーム別に見るべきか
チーム別Copilot利用メトリクスを作ると、多くの指標を見たくなります。しかし、最初からすべての指標をダッシュボード化すると、見る側が何を判断すべきか分からなくなります。最初は、導入・定着・活用の3段階に分けて設計するのがおすすめです。
| 観点 | 見る指標の例 | 判断基準 |
|---|---|---|
| 導入 | Copilotライセンス保有者数、アクティブユーザー数 | ライセンスを配っただけで終わっていないか |
| 定着 | 継続的な日次・週次利用、チャット利用、IDE利用 | 日常業務に組み込まれているか |
| 活用 | コード生成、受け入れ、機能別・言語別・モデル別の利用 | チームの開発プロセスに合った使い方になっているか |
初期展開では、アクティブユーザー数と主要機能の利用傾向を見るだけでも十分です。高度な分析は、データ取得が安定してから段階的に追加すると運用しやすくなります。
展開前に確認すべき設定・移行チェックリスト
今回のAPIを使って社内レポートやBIダッシュボードを作る場合、管理者・開発者は次の項目を確認しておきましょう。
| 確認項目 | 確認する理由 | 推奨対応 |
|---|---|---|
| Copilotライセンスの付与状況 | user-teams はCopilotライセンスユーザーを前提にするため | チーム別のシート数を確認する |
| チーム構成とslug | 集計単位が team_id や slug になるため | チーム命名ルールを整理する |
| API実行権限 | 権限不足では403や404に見えることがあるため | Organization / Enterprise別に権限を確認する |
| 日次データ取得のスケジュール | 署名付きURLには有効期限があるため | API呼び出し後すぐにファイルを保存する |
| 28日集計の作り方 | チーム異動による誤集計を防ぐため | 日次結合後に期間集計する |
| 小規模チームの扱い | 5席未満のチームが除外されるため | レポート注記に反映する |
| 複数チーム所属の扱い | チーム別合計が全体合計と一致しないため | 全体値は別レポートで出す |
| 既存レポートとの比較 | 新しい指標は従来の見え方と異なる可能性があるため | 切り替え時に再ベースラインする |
特に「既存の社内Copilotレポートを移行する」場合は、単純に新APIの値へ差し替えるのではなく、集計定義を明文化してから切り替えるべきです。GitHub Docsでは、コード生成や受け入れ、行数関連のカウンターが複数のCopilotサーフェスをまたいで集計されること、従来のインラインIDE補完だけを数えていた面と比べると値が高く見える場合があることにも触れています。(GitHub Docs)
API連携の実装イメージ
以下は、Organization単位で1日分のチーム別Copilot利用メトリクスを作る際の考え方です。実際のスクリプトでは、認証トークン、エラーハンドリング、ページングや複数ファイル対応、保存先の設計を追加してください。
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/orgs/ORG/copilot/metrics/reports/user-teams-1-day?day=YYYY-MM-DD"この呼び出しで返る download_links から、指定日の user-teams レポートを取得します。同じ日付でユーザー別利用レポートも取得し、アプリケーションやデータ基盤側で結合します。
集計ロジックの疑似コードは次のようになります。
1. organization_user_teams_1_day を取得
2. organization_users_1_day を取得
3. user_id + day + organization_id で内部結合
4. team_id + slug でグループ化
5. active_users = COUNT(DISTINCT user_id)
6. code_generation_activity_count などの数値項目を SUM
7. 必要に応じて language、IDE、feature、model の配列を展開して再集計チーム別の「利用があるチームだけ」を見たい場合は内部結合で足ります。一方、利用がゼロのチームも含めてダッシュボードに出したい場合は、user-teams 側を起点にleft joinし、利用カウンターがnullの場合は0として扱います。公式ドキュメントでも、活動がないチームを表示するにはleft joinを使う考え方が示されています。(GitHub Docs)
ダッシュボード化するときのおすすめ構成
チーム別CopilotメトリクスをBIツールや社内ポータルで見せる場合、最初から細かすぎる分析画面を作るより、管理者が意思決定しやすい順に配置すると効果的です。
最初の画面に置くべき指標
- チーム別アクティブユーザー数
- チーム別アクティブ率
- 主要機能別の利用状況
- 前週または前月との比較
- 5席未満で除外される可能性がある旨の注記
詳細画面に置くべき指標
- 言語別の利用状況
- IDE別の利用状況
- Copilot Chat、CLI、Code review、cloud agentなど機能別の内訳
- モデル別、機能別の傾向
- チーム異動が多い期間の注意表示
管理者向けダッシュボードでは、「利用が低いチームを責める」見え方にしないことも大切です。たとえば、単純なランキングだけを出すと、業務特性や開発フェーズの違いが無視されます。新規開発中のチームと保守中心のチームでは、Copilotの使い方も数字の出方も異なります。メトリクスは、チームの状況を聞きに行くための材料として扱うのが現実的です。
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 28日レポートと1日分のチーム所属を結合する | チーム異動者の実績が誤ったチームに割り当てられる | 日次で結合してから期間集計する |
| チーム別合計を全社合計として報告する | 複数チーム所属ユーザーにより数値がずれる | 全社合計は組織・Enterprise単位のレポートを使う |
| 5席未満チームの除外を説明しない | 小規模チームの利用が見えず、未利用と誤解される | ダッシュボードと報告資料に注記を入れる |
| 個人PATで本番バッチを動かす | 権限変更や退職で処理が止まる | GitHub Appなど継続運用に向いた認証を使う |
| 指標を多く出しすぎる | 管理者が次のアクションを判断できない | 導入・定着・活用の3段階に分ける |
| 数値だけで評価する | チームの開発内容やフェーズを無視した判断になる | メトリクスとヒアリングを組み合わせる |
今回の更新で対応が必要な人
今回の変更は、すべての開発者がすぐに作業しなければならないものではありません。影響が大きいのは、Copilotの利用状況を管理・分析している担当者です。
| 立場 | 対応の優先度 | やるべきこと |
|---|---|---|
| GitHub Enterprise管理者 | 高 | 権限、トークン、Enterprise単位の取得可否を確認する |
| Organization owner | 高 | 組織単位のAPI利用権限とチーム構成を確認する |
| 情シス・開発生産性チーム | 高 | 既存のCopilotレポートにチーム別分析を追加できるか検討する |
| データエンジニア | 中〜高 | 日次取得、結合、集計、BI連携のパイプラインを設計する |
| チームリーダー | 中 | 自チームの利用傾向をオンボーディングや改善施策に使う |
| 一般開発者 | 低 | 直接対応は少ないが、チーム単位で利用状況が分析される可能性を理解する |
まず取るべきアクション
この更新に対応するなら、最初にやるべきことはAPIをいきなり本番連携することではありません。まず、1つのOrganizationまたはEnterpriseで1日分の user-teams-1-day と users-1-day を取得し、結合結果が期待どおりになるかを検証しましょう。
確認すべき順番は次のとおりです。
- OrganizationまたはEnterpriseのどちらで集計するか決める
- APIを呼び出す権限とトークンを確認する
- 1日分の
user-teams-1-dayとusers-1-dayを取得する user_id、day、organization_idまたはenterprise_idで結合する- 既知のチーム所属と照合し、集計結果に違和感がないか確認する
- 5席未満チーム、複数チーム所属、チーム異動の扱いをレポート仕様に明記する
- 問題がなければ、日次取得と期間集計のパイプラインを作る
今回の Team-level Copilot usage metrics now available via API は、Copilotの利用実態を「誰が使ったか」から「どのチームでどう使われているか」へ一段深く見るための更新です。管理者は、API権限と集計ロジックを確認し、開発者やデータ担当者は日次結合を前提にしたパイプラインを設計しましょう。特に、28日レポートとの誤結合、5席未満チームの除外、複数チーム所属ユーザーの二重カウントは、展開前に必ず仕様として整理しておくべきポイントです。
コメント