GitHubは2026年11月5日、エンタープライズと組織の管理者が使うCopilot使用状況メトリクスAPIに、コードレビューへの対応情報とデータ欠落の診断を追加した。コードやファイルを保管するリポジトリごとに開発者がレビュー意見をどう処理したかを確認し、ユーザー別にエディターのデータ欠落や最低サポートバージョン未満の環境を見つけ、事後対応を取れる。

1. リポジトリ別にコードレビューのフィードバックへの対応を確認

エンタープライズと組織のリポジトリ単位の日次レポートでは、各行にcopilot_code_reviewオブジェクトが付く。このオブジェクトには、Copilotの初回レビュー後、人が追加変更を要求せずにマージしたプルリクエスト、つまりマージ前の確認を求めるコード変更の数と、開発者が対応したレビューコメントの集計が含まれる。

total_comments_evaluatedは開発者の反応の有無を評価したコメント数で、total_comments_addressedはそのうち開発者が行動した数だ。提案の適用だけでなく、Copilotへの修正依頼、直接のコード修正、後で修正するという返信も対応として数える。対応数を評価数で割ると、リポジトリ別の対応率になる。

両集計は、重大度、レビュー等級、コメントの種類、カスタマイズの有無で分類される。例えば、バグの指摘とセキュリティ関連の意見のどちらに開発者がより多く反応するか、カスタム指示を使ったレビューで対応の傾向がどう変わるかを確認できる。

従来の提案適用数は、すぐに適用できる提案を誰かが適用した場合だけを数える。新しい集計は評価済みコメント全体を対象に、返信や直接の修正まで含め、開発者の対応をより広く示す。

コメントの評価はプルリクエストのマージ時に行われ、マージ日の実績として記録される。

2. テレメトリと最低バージョンの不足を診断

ユーザーレポートには、エディターが送信する使用記録であるテレメトリが、その日に届いたかを示すフィールドが追加された。client_telemetry_presentがfalseなら、Copilotはユーザーの活動を確認したものの、エディターから使用状況イベントを受信していない状態だ。

usage_metrics_requirementsは、ユーザーの統合開発環境（IDE）とCopilot拡張機能が最低サポートバージョンの基準を満たすかを示す。状態は、充足、未達、不明に分かれる。

エンタープライズ・組織の日次レポートには、テレメトリが欠落したユーザー数と最低バージョン未達のユーザー数も含まれる。28日間レポートでは日付別の集計を確認でき、ユーザー別の診断フィールドは日次・28日間の両ユーザーレポートで提供される。

GitHubは、古いエディター・拡張機能、エディターのテレメトリ無効化、イベントを遮断するプロキシ、通信を中継するサーバーやファイアウォールを、データ欠落のよくある原因として挙げた。管理者は影響を受けるユーザーを特定し、更新や送信設定の点検など、事後対応の対象を絞り込める。

3. レポートのリクエストとアクセス権

レポートはREST APIの既存エンドポイント、つまりAPIリクエストを受ける接続先から取得する。レスポンスには、有効期限付きの署名済みダウンロードリンクという、アクセスを検証する一時的なファイルアドレスと、レポートの日付が含まれる。特定日のリポジトリレポートは、日付を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/repos-1-day?day=DAY"

エンタープライズ所有者とエンタープライズの請求管理者、組織所有者、Copilotメトリクスの閲覧権限を付与されたユーザーにアクセス権がある。使用状況メトリクスのポリシーも有効である必要がある。アプリへの権限委任に使う認証手段であるOAuthアプリトークンと、従来型の個人用アクセストークンには、エンタープライズ・組織レポートの範囲に合った権限が必要だ。

4. 数値を読む際に知っておくべき集計基準

テレメトリが欠落したユーザーは、アクティブユーザーに含まれても、コード行数や機能・モデル別の詳細情報が欠ける。テレメトリ欠落とバージョン未達には同じユーザーが重複する可能性があり、日付別の集計でも重複が生じるため、両者の数や複数日の数を足してユニークユーザー数として使ってはならない。

5. 可視性の拡大と解釈の負担

管理者はサポートリクエストを出さずに、レビューへの対応とデータ欠落を直接確認できるようになる。その分、分析にはリポジトリ別のレビューレポートとユーザー別の診断レポートを併せて確認し、見つかった問題を該当ユーザーにつなぐ運用作業が加わる。

今回の拡張の価値は、Copilotの使用量を数えるだけでなく、レビューに対する開発者の対応とデータ収集環境を併せて点検できるようにする点にある。