GitHub Copilot の費用対効果を PR ベースで測りたいなら、2026年4月8日の更新はかなり重要です。GitHub は Copilot 使用状況メトリクス API に、Copilot がレビューした PR のマージ件数と、そうした PR がマージされるまでの中央値時間を追加しました。これで「Copilot がレビューしたか」だけでなく、「そのレビューがマージにつながったか」「PR の着地を速めたか」まで追いやすくなります。 (The GitHub Blog)
特に大きいのは、2月に追加された Copilot 作成 PR 向けの throughput / cycle time 指標と組み合わせることで、作成・レビュー・マージの流れを API でかなり一貫して見られるようになった点です。ROI 分析を「利用回数」ではなく「開発フローへの実効性」で語りたい企業にとって、今回の追加はかなり実務的な前進です。 (The GitHub Blog)
2026年4月8日の更新で何が変わったか
今回追加されたのは、Copilot code review に焦点を当てた次の 2 指標です。GitHub の changelog によると、どちらも enterprise / organization の単日レポートと 28 日ローリングレポートで利用できます。 (The GitHub Blog)
pull_requests.total_merged_reviewed_by_copilot
Copilot code review を受け、かつ報告期間内にマージされた PR の総数です。 (The GitHub Blog)pull_requests.median_minutes_to_merge_copilot_reviewed
Copilot code review を受けた PR について、作成からマージまでにかかった時間の中央値（分）です。 (The GitHub Blog)
これまでの更新が「Copilot が PR を作る側でどれだけ寄与したか」を測る色合いが強かったのに対し、今回の追加は「Copilot がレビュー側でどれだけ成果に結びついたか」を測る指標です。GitHub 自身も、既存の Copilot 作成 PR メトリクスと合わせて、PR ライフサイクルを end-to-end で見られるようになると説明しています。 (The GitHub Blog)
なぜこの新指標が Copilot の ROI 分析で重要なのか
“使った回数”ではなく“結果まで進んだか”を見られる
従来でも pull_requests.total_reviewed_by_copilot や pull_requests.total_copilot_suggestions、pull_requests.total_copilot_applied_suggestions は取れました。ただ、それだけでは「レビューは付いたが、PR はマージに進まなかった」「コメントは多いが、実際の前進につながっていない」といった状態を切り分けにくい面がありました。今回の PR マージメトリクスは、その空白を埋める指標です。 (GitHub Docs)
レビュー工程の改善だけを切り出せる
GitHub Docs では、Copilot code review を体系的に使うことで review time を減らし、PR をより早くマージしやすくできると案内しています。一方で、Copilot code review は人のレビューの代替ではなく、最終的な承認やマージ判断は人間側に残ります。だからこそ、新しい指標は「レビュー工程の補助として Copilot が効いているか」を見るのに向いています。 (GitHub Docs)
自動アサインだけの“見かけの普及”を見抜きやすい
ここが見落とされがちです。GitHub は ruleset で Copilot を reviewer に自動追加する運用を案内していますが、使用状況メトリクスには used_copilot_code_review_active と used_copilot_code_review_passive もあり、手動でレビュー依頼したり提案を適用したりした能動利用と、自動割り当てだけの受動利用を区別できます。total_merged_reviewed_by_copilot を見るときにこの補助線を持っておくと、「自動で reviewer に付いただけ」の数を ROI と取り違えにくくなります。 (GitHub Docs)
実務では 4 つの数字を並べて見ると判断しやすい
新しい PR マージメトリクスは、単独で見るより既存の baseline 指標や suggestion 指標と並べて読む方が意味がはっきりします。元になる field definitions は GitHub Docs の pull request activity fields と今回の changelog に基づきます。 (GitHub Docs)
| まず見る数字 | どう比較するか | 何が分かるか |
|---|---|---|
| 全体の基準値 | total_merged と median_minutes_to_merge | 組織の通常のマージ速度 |
| Copilot レビュー関与率 | total_merged_reviewed_by_copilot ÷ total_merged | マージ済み PR のうち、Copilot review が結果まで届いた比率 |
| Copilot レビュー PR の速度差 | median_minutes_to_merge_copilot_reviewed を全体中央値と比較 | Copilot review を受けた PR の着地が速いか |
| コメント実効性 | total_copilot_applied_suggestions ÷ total_copilot_suggestions | Copilot の指摘が実際に採用されているか |
median_minutes_to_merge_copilot_reviewed が全体中央値より短ければ良い兆候です。ただし、それだけで因果関係を断定してはいけません。小さくて軽い PR にだけ Copilot review が付いていれば、数字は自然によく見えます。同じリポジトリ群、同じレビュー方針、同じ期間幅で before / after 比較するのが安全です。
また、ROI をマージ時間だけで判定するのも危険です。GitHub の rollout guidance でも、PR lead time だけでなく defect escape rate や developer satisfaction を合わせて見ることが勧められています。今回の新指標は“速度側”の強いシグナルですが、品質側の補助指標とセットで使う方が実務では失敗しにくいです。 (GitHub Docs)
API で確認する方法
運用上まず知っておきたいのは、Copilot 使用状況メトリクス API はメトリクス本体をそのまま返すのではなく、期限付きの download_links を返すことです。日次レポートと 28 日レポートがあり、レポート本体では pull_requests オブジェクト配下に今回の新旧フィールドが並びます。 (GitHub Docs)
イメージは次のようになります。
"pull_requests": {
"total_merged": ...,
"total_merged_reviewed_by_copilot": ...,
"median_minutes_to_merge": ...,
"median_minutes_to_merge_copilot_reviewed": ...
}代表的なエンドポイントは次のとおりです。
- 組織の単日レポート:
GET /orgs/{org}/copilot/metrics/reports/organization-1-day?day=YYYY-MM-DD(GitHub Docs) - 組織の最新 28 日レポート:
GET /orgs/{org}/copilot/metrics/reports/organization-28-day/latest(GitHub Docs) - Enterprise の単日レポート:
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day?day=YYYY-MM-DD(GitHub Docs) - Enterprise の最新 28 日レポート:
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest(GitHub Docs)
利用前には、enterprise 全体で「Copilot 使用状況メトリック」ポリシーが有効になっている必要があります。閲覧権限も、organization 側と enterprise 側で必要ロールが異なります。加えて、旧 copilot/metrics エンドポイントは 2026 年 4 月 2 日に終了しているため、今回の新しい PR マージメトリクスを見るなら usage metrics 側へ寄せる必要があります。 (GitHub Docs)
なお、organization の日次エンドポイントでは 204 No Content が返る場合もあります。レポートが空だからといってすぐに障害と決めつけず、対象日、権限、ポリシー設定を順に確認するのが実務的です。 (GitHub Docs)
見落としやすい注意点
total_reviewed_by_copilotとtotal_merged_reviewed_by_copilotを単純に割らないこと
既存のpull_requests.total_reviewed_by_copilotは、同じ PR が複数日にわたって Copilot にレビューされると日ごとに再計上され得ます。したがって、これと今回のtotal_merged_reviewed_by_copilotをそのまま割って “レビュー→マージ率” とみなすのは危険です。 (GitHub Docs)- organization 合計と enterprise 合計は一致しないことがある
enterprise レベルではユーザー重複が排除されますが、organization レベルではそうではありません。複数組織に所属するユーザーがいると、レポートの見え方はずれます。 (GitHub Docs) - PR メトリクスだけが出ても異常とは限らない
GitHub Docs では、PR lifecycle metrics は repository activity 由来のため、IDE usage metrics がなくても現れることがあると説明されています。 (GitHub Docs) - repo / org transfer で attribution が分かれる
PR の作成・レビュー・マージの間にリポジトリや組織の移管が入ると、イベントが別の組織や enterprise に分かれて計上される場合があります。 (GitHub Docs) - 個人査定の KPI には向かない
GitHub Docs の pull request activity fields は enterprise または organization スコープの指標として説明されています。したがって、この新しい PR マージメトリクスは個人ランキングより、チームや組織単位のフロー改善を見る用途に向いています。 (GitHub Docs) - Copilot review が入っても、人の承認・branch protection・CI は残る
GitHub は、Copilot code review は人間レビューの代替ではないと明記しており、Copilot cloud agent も PR を自分でマージできません。branch protection や CI もそのまま効きます。 (GitHub Docs)
まずやるべきこと
最初の一歩はシンプルです。まず 28 日レポートで total_merged と median_minutes_to_merge を baseline にし、そこへ total_merged_reviewed_by_copilot と median_minutes_to_merge_copilot_reviewed を重ねてください。次に、protected branch 向けの自動 reviewer 追加、IDE での事前レビュー、custom instructions を小さめの対象リポジトリで揃えます。最後に、used_copilot_code_review_active と suggestion 適用率も補助線にして、「自動で付いただけのレビュー」ではなく「実際にマージ速度へ効いたレビュー」に投資できているかを見ます。 (GitHub Docs)
今回の更新で、GitHub Copilot の評価軸は「使っているか」から「PR をどれだけ前に進めたか」へ一段進みました。Copilot の ROI を本気で判断するなら、これからは review suggestion 数だけでなく、Copilot がレビューした PR のマージ件数とマージ時間までセットで見るのが基本です。 (The GitHub Blog)
コメント