GitHub Copilotの利用状況を、組織全体の合計だけでなく、リポジトリごとのプルリクエスト活動まで追えるようになりました。Copilotアプリの利用状況も、企業と組織向けの利用指標APIに加わっています。
測定の粒度が細かくなると、どの開発現場で機能が使われているかを確認しやすくなります。ただし、利用回数が増えたことだけでは、生産性や品質が上がったとは判断できません。採用状況、開発フロー、品質、コストを分けて測り、同じリポジトリと期間の中で関係を確認する必要があります。
導入前の権限設計やレビュー基準は、GitHub Copilotをチームに導入する際の実務も参照してください。本稿では、導入後の測定に範囲を絞ります。
利用指標で変わった測定の粒度
GitHubは、Copilot利用指標REST APIでリポジトリ単位の活動を取得できる二つのエンドポイントを一般提供しました。企業向けと組織向けに、それぞれ一日分のリポジトリ別レポートを取得できます。
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DDGET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD
レポートには、Copilot coding agentが作成またはマージしたプルリクエストと、Copilot code reviewがレビューしたプルリクエストの活動が含まれます。レビューの提案数はコメント種別でも分かれます。組織全体の利用者数だけでは見えなかった「どのリポジトリで開発フローに入っているか」を確認できる点が変化です。
同時に、企業と組織の一日および28日レポートには、Copilotアプリの利用状況が加わりました。主な追加項目は、日別のアクティブ利用者数を示すdaily_active_copilot_app_usersと、セッション数、リクエスト数、プロンプト数、トークン使用量をまとめたtotals_by_copilot_appです。
| 測定対象 | 把握できること | 単独では判断できないこと |
|---|---|---|
| リポジトリ別レポート | coding agentとcode reviewが関与したプルリクエスト活動 | 変更の難易度、顧客価値、障害を防いだ効果 |
| Copilotアプリ指標 | 利用者、セッション、リクエスト、プロンプト、トークン使用量 | 回答の正確さ、作業時間の短縮、成果物の品質 |
| 組織と企業の利用指標 | 機能、IDE、言語、モデルなどに分けた採用と活動 | ライセンス割り当ての正確な状態と個別案件の成果 |
利用量と開発成果を分けて読む
新しい指標が直接答えるのは、Copilotがどこで、どの程度使われたかという問いです。リポジトリ別の活動が増えれば、特定のコードベースでcoding agentやcode reviewの採用が進んだ可能性を確認できます。Copilotアプリのアクティブ利用者やセッションが増えれば、アプリが業務に浸透している兆候になります。
その理由だけで「開発が速くなった」と結論づけることはできません。プルリクエスト数は、チーム人数、リリース時期、変更の分割方法、障害対応でも変わります。リクエスト数やトークン使用量も、複雑な相談が増えた場合と、回答を得るまでのやり直しが増えた場合を区別しません。
したがって、利用指標は成果指標の代わりではなく、成果が変わった理由を調べる説明変数として扱います。採用状況を入口にし、マージまでの時間、手戻り、変更失敗、レビュー負荷などを同じ単位で並べると、判断に使える形になります。
集計で誤読しやすい三つの境界
対象となる利用経路
GitHubのドキュメントによると、Copilot利用指標はIDEやCopilot CLIなど複数の利用経路から得たテレメトリーを使います。クライアント側の信号が届かない利用者を補うため、アクティブ利用者の把握にはサーバー側の信号も使われます。
一方、GitHub.com上のCopilot ChatとGitHub Mobileの活動は、現在の利用指標に含まれないと説明されています。ライセンスとシートの管理情報も別のAPIが正とされています。アクティブ利用者をライセンス数で割る場合は、利用指標APIとユーザー管理APIを混ぜず、分母の取得元と基準時点を記録します。
レポートごとの集計範囲
ダッシュボード、API、エクスポートは、期間と集計範囲が同じとは限りません。GitHubも、用途とデータモデルが異なるAPIリソースを直接比較しないよう案内しています。Copilotアプリの項目は、一般的な機能別、モデル別、言語別の合計やコード行数の指標とは別の区画に置かれます。
Copilotアプリの活動がない企業や組織では、二つの追加項目がnullになります。集計処理で機械的にゼロへ置き換えると、「対象外」「未取得」「活動なし」の区別を失うため、欠損値の意味をデータ辞書に残します。
相関と因果
利用量と成果が同じ時期に増えても、利用が成果を生んだとは限りません。新しい案件の開始、経験者の参加、テスト自動化、レビュー方針の変更が同時に起きれば、どの要因が効いたかを分けられないからです。
導入効果を調べるなら、導入前後の比較だけでなく、規模と保守段階が近いリポジトリを比較対象にします。段階導入ができる組織では、開始時期をずらし、各リポジトリの平常時との差を比べると、季節要因や全社的な変化の影響を抑えやすくなります。
開発組織向けの指標設計
指標は一枚の総合点にまとめず、問いごとに分けます。異なる現象を合算すると、改善すべき場所が分からなくなるためです。
| 問い | 中心となる指標 | 一緒に見る指標 |
|---|---|---|
| 採用は進んでいるか | アクティブ利用者、利用リポジトリ数 | 対象シート数、職種、利用経路、導入時期 |
| coding agentは開発フローに入ったか | 作成またはマージされた対象プルリクエスト | マージまでの時間、再オープン、差し戻し、変更規模 |
| code reviewはレビューを補助したか | レビュー対象プルリクエストと提案数 | 人のレビュー時間、採用された指摘、見逃し、重複指摘 |
| 品質は保たれたか | 変更失敗、ロールバック、不具合流出 | テスト範囲、変更の難易度、障害の重大度 |
| 費用に見合うか | シート費用と対象機能の消費量 | 削減できた作業時間、追加レビュー、再作業 |
たとえば、coding agentが作成したプルリクエストのマージ率が高くても、変更が小さいリポジトリへ集中しているなら、他のリポジトリに同じ効果を期待できません。リポジトリの種類、変更規模、保守段階で層を分けてから比較します。
測定を始める五つの手順
- 判断する問いを一つ決める。「導入は成功したか」では広すぎます。「code reviewを有効にしたリポジトリで、人の初回レビューまでの待ち時間が変わったか」のように対象を限定します。
- 単位と期間を固定する。リポジトリと日を最小単位にし、短期の変動をならす分析期間を別に設けます。集計期間を変更した場合は、変更前の系列と分けます。
- 基準値を先に保存する。導入前のマージ時間、差し戻し、障害、レビュー時間を残します。基準値がなければ、利用開始後の変化を評価できません。
- 運用変更を記録する。ポリシー、対象者、モデル、IDE拡張、レビュー規則、リリース計画の変更日を台帳に残します。指標が動いた理由を後から確認するためです。
- 月次で仮説を見直す。利用が少ない場合は研修不足だけでなく、対象業務に合わない可能性も調べます。利用が多い場合も、品質と手戻りを確認してから拡大を判断します。
ユーザー単位のデータを個人の順位付けへ直結させると、測定範囲の欠落と業務の違いを無視することになります。権限を必要な担当者に限定し、個人の査定よりも、支援が必要なチームやリポジトリを見つける用途を優先します。
権限、認証情報、レビュー規則を含む運用全体は、GitHub Copilotのセキュリティ統制と一緒に見直すと、測定と管理を分断せずに済みます。
よくある質問
利用指標だけで開発者の生産性を測れますか
測れません。利用指標は採用と活動を示します。成果を評価するには、変更の難易度、マージまでの時間、品質、手戻り、顧客への提供価値を別に確認する必要があります。
リポジトリ別レポートで何が分かりますか
coding agentが作成またはマージしたプルリクエストと、code reviewがレビューしたプルリクエストの活動を日別に確認できます。リポジトリの事業価値や変更品質を直接示すレポートではありません。
ダッシュボードとAPIの数値が合わない場合はどうしますか
対象期間、タイムゾーン、企業と組織の範囲、利用経路、テレメトリー、欠損値の扱いを順に確認します。比較するリソースの用途が同じかも確認してください。
Copilotアプリの項目がnullになるのは異常ですか
GitHubは、対象期間にアプリの活動がない場合、アクティブ利用者と利用内訳の項目をnullで返すと説明しています。異常と決めず、対象組織と期間を確認します。