GitHub Copilotの効果測定がリポジトリ単位に【作成数とマージ数の読み分け】

GitHub Copilotの利用状況を、組織全体だけでなくリポジトリ単位で確かめられるようになりました。どの開発場所でAIがプルリクエスト(PR)を作り、レビューし、マージまで進んだかを追いやすくなります。

ただし、数字の見方には落とし穴があります。
同じ日の「マージ数÷作成数」を、マージ率として扱ってはいけません。作成数とマージ数は、別の日に起きた別イベントを数えているためです。

GitHub Copilotの効果測定がリポジトリ単位に

GitHubは2026年7月17日、GitHub Copilot usage metrics REST APIのリポジトリ単位レポートを一般提供しました。
エンタープライズ用と組織用の2つの日次エンドポイントが追加されています。

取得単位	対象	確認できる活動
企業	Enterprise	リポジトリ別PR活動
組織	Organization	リポジトリ別PR活動

対象は、Copilot coding agentが作成・マージしたPRと、Copilot code reviewがレビューしたPRです。これまで組織全体の集計では埋もれやすかった「どのリポジトリでAI開発が動いたか」を切り分けられます。

出典: GitHub Changelog「Repository-level GitHub Copilot usage metrics generally available」(英語)

取得できるのは、Enterprise所有者や組織所有者など、Copilotメトリクスの表示権限を持つ利用者です。
Copilot usage metricsポリシーの有効化も必要なので、APIを試す前に組織設定と担当者の権限を確認してください。

出典: GitHub Docs「REST API endpoints for Copilot usage metrics」(英語)

AIが行った作業を後からたどる設計は、GitHub Copilotエージェントの作業履歴を確認する方法ともつながります。メトリクスだけでなく、PRやログを見られる状態を残すと、数字の背景を確認しやすくなります。

GitHub Copilotの作成数とマージ数は同じ母集団ではない

作成数とマージ数の違いは、いつ数えるかです。
GitHubのフィールド定義では、PRの作成は作成日に1回、マージはマージ日に1回数えます。
この定義は企業と組織の集計レポートについて公開されているため、リポジトリ別レポートの項目は実データで確認します。

たとえば月曜日にCopilotが作ったPRが、レビューを経て水曜日にマージされた場合、作成は月曜日、マージは水曜日へ記録されます。
水曜日のマージ数を水曜日の作成数で割っても、月曜日に作ったPRの採用率にはなりません。

出典: GitHub Docs「Copilot使用状況メトリックで使用可能なデータ」

見たいこと	使う見方	避ける見方
活動量	日次・週次推移	単日の順位
受入状況	同じPRを追跡	同日の割り算
流れ	期間と待ち時間	件数だけ

日次レポートだけでは、個別PRの作成日とマージ日を直接結びつけられません。
正確なコホート分析、つまり「同じ日に作られたPRが後日どうなったか」を知りたい場合は、GitHubのPRデータと突き合わせる設計が必要です。

GitHub Copilotの成果は3層KPIで測る

GitHub Copilotの成果測定は、作った、流れた、事業へ効いたの3層に分けると判断しやすくなります。どれか1つだけでは、利用の多さと成果を取り違えます。

層	指標例	判断できること
利用	作成・レビュー	AIが動いた場所
フロー	マージ・待ち	成果物が流れたか
品質	手戻り・障害	速さに無理がないか

第1層では、AIが実際に使われた場所を確認します。作成数が増えたリポジトリは、Copilot coding agentへ仕事を渡せている候補ですが、PRの大きさや難易度は件数から分かりません。

第2層では、レビュー待ちやマージまでの時間を見ます。作成数だけ増えてマージが動かないなら、AIの出力品質だけでなく、レビュー担当の不足や承認ルールも確認対象です。

第3層では、手戻り、障害、リリースまでの時間、削減できた作業時間を組み合わせます。
マージされたことと、品質や売上へ貢献したことは同じではありません。

利用回数だけでなく成果物と手戻りまで見る考え方は、AI導入KPIをGitHubレポートで測る方法で詳しく整理しています。コード品質の確認項目は、AIで作ったコードの納品前チェックも合わせて使えます。

出典: GitHub Docs「GitHub Copilot試用版の成功を測定する」

GitHub Copilotのリポジトリ利用状況を集める手順

GitHub Copilotのリポジトリ利用状況は、日次で保存し、週次で読み、月次で判断すると運用しやすくなります。日々の増減へ反応するより、開発サイクルに合わせて傾向を見ます。

• ポリシーと権限を確認し、まず1日分を取得する
• 署名付きURLの有効期限内にレポート本体を保存する
• 対象日、組織、リポジトリを保存データへ付ける
• 取得失敗と活動ゼロを別の状態として記録する
• 週次では作成・マージ・レビューを見て、月次で品質指標と合わせる

APIの応答には、レポート本体ではなく期限付きのダウンロードURLが含まれます。長期分析をするなら、URLだけを残さず、取得したレポートを権限管理された保存先へ置きます。

日次レポートは完全に処理された1日を対象とし、データの利用可能化に時間がかかる場合があります。
当日分が見えないだけで取得失敗と決めず、UTCの日付と反映待ちを確認してください。

出典: GitHub Docs「Copilot usage metrics」 / GitHub Docs「Reconciling usage metrics」(英語)

Copilot全体の利用量や費用も同時に管理する場合は、GitHub Copilotの使用量レポートを確認する方法へつなぐと、成果物と利用量を別々に追えます。

GitHub Copilotのリポジトリ比較で避ける失敗

リポジトリ別の数字が並ぶと、上位と下位を決めたくなります。
しかし、絶対数のランキングは効果測定より先に誤解を生みます。

• 活動のないリポジトリがレポートに現れない仕様をAPI障害と混同しない
• 同じ役割・同程度の規模を持つリポジトリだけを比較する
• 個人監視や人事評価の単独指標にしない
• 仕様記述と実データが違う場合に止まらない処理へする
• 数字が変わった理由をPRと現場ヒアリングで確かめる

2026年7月17日の公式発表はレビュー提案のコメント種類別内訳に触れていますが、同日時点のフィールド参照にはリポジトリレベルで利用できないと読める記述があります。
この項目を必須フィールドとして固定せず、実際のNDJSONを確認してから集計へ加えるのが安全です。

AIエージェントの処理が失敗した時も、数字だけで再実行を決めると二重処理につながります。GitHub操作失敗時に人へ戻す手順のように、ログと処理状態を確認してから運用を戻してください。

よくある質問

まとめ｜同日の割り算より開発フローの変化を見る

GitHub Copilotのリポジトリ効果測定では、作成数とマージ数を別イベントとして読むことが出発点です。
同日比をマージ率にせず、利用・開発フロー・品質事業の3層を期間推移で確認します。

AI開発を広げる前にKPIを整えたい場合は、利用回数だけに頼らないAI導入KPIから、自社の3層へ置き換えてみてください。