Copilot code review metricsでAIレビューの価値を測る：security/bug_risk別KPI設計¶

対象 / ポイント

対象: GitHub Copilot code reviewを導入したものの、効果測定で詰まっているエンジニアリングマネージャ、SRE、プラットフォームチーム。

ポイント:

2026-05-08の更新で、Copilot code reviewの提案数と採用数をcomment_type別に追えるようになった。
securityやbug_riskはCopilotが付けた分類ラベルであり、重大度そのものではない。KPIでは「種別別の反応量」として扱う。
リポジトリ単位の分解は未対応のため、まずEnterprise/Organization単位で4〜12週間のベースラインを取る。

何が変わったか¶

GitHubは2026年5月8日、Copilot usage metrics APIにcopilot_suggestions_by_comment_typeを追加した¹。これにより、Copilot code reviewが投稿した提案をcomment_type別に集計できる。

各行で見るべき値は3つである。

comment_type: Copilotが付けた種別ラベル
total_copilot_suggestions: その種別で投稿されたCopilot提案数
total_copilot_applied_suggestions: 開発者が適用したCopilot提案数

今回の変化は「APIを1回呼べば全て分かる」という話ではない。正確には、Copilot usage metricsのレポートデータに、提案種別ごとの内訳フィールドが増えたという話である。

重要なのは、securityやbug_riskを重大度として読まないことだ。これはCopilot側が提案に付けた分類であり、人間のセキュリティ評価や組織のリスク等級とは一致しない。KPIではまず「Copilotがどの種類の指摘を出し、それを開発者がどれだけ採用したか」として読む。

なぜこのKPIが効くのか¶

AIレビューの効果測定で詰まりやすい理由は、総量だけでは良し悪しが分からないからである。提案数が増えても、それが有用な指摘なのか、誤検知が増えただけなのかは分からない。

comment_type別に分かれると、問いが具体化する。

securityの提案数は増えているが、採用率が落ちていないか
bug_riskの採用率は高いが、提案数が少なすぎないか
ある月から特定種別だけ急に増えていないか
チームのルール変更後に、採用される提案の構成が変わったか

ここで中心に置く指標は、種別別applied率である。

種別別applied率 = total_copilot_applied_suggestions / total_copilot_suggestions

これは「開発者がその指摘を正しい、または少なくとも取り込む価値があると判断した割合」に近い。ただし、採用は価値の完全な代理指標ではない。軽微な修正を受け入れただけのケースもあるため、レビュー時間、追加コメント数、差し戻し率と組み合わせて読む必要がある。

comment_type別KPI設計の枠組み¶

最初から複雑なスコアを作る必要はない。実用的には、Enterprise/Organization単位でcomment_typeごとに4つの数字を並べればよい。

指標	計算	使いどころ
提案密度	種別別提案数 ÷ レビュー対象PR数	Copilotがどの領域に反応しているか
種別別applied率	採用数 ÷ 提案数	指摘が取り込まれやすいか
種別構成比	種別別提案数 ÷ 全提案数	レビュー提案の分布を見る
採用構成比	種別別採用数 ÷ 全採用数	実際に価値が出た領域を見る

特に有効なのは、提案密度とapplied率の4象限である。

状態	読み方	次の行動
提案が多く、applied率も高い	主力カテゴリ	自動レビューの標準KPIに入れる
提案が多く、applied率が低い	誤検知の疑い	対象パス、ルール、レビュー条件を見直す
提案が少なく、applied率が高い	稀だが効く指摘	検出条件や対象リポジトリを広げる
提案が少なく、applied率も低い	優先度が低い	まず観測だけに留める

ただし、今回のリリース時点ではリポジトリ単位の分解は提供されていない。しきい値を急いで置くより、4〜12週間はEnterprise/Organization単位でベースラインを集める方が現実的である。

取得から可視化までの最小実装¶

GitHubのCopilot usage metrics REST APIは、メトリクス本文を直接返すのではなく、レポートファイルのdownload_linksを返す²。したがって最小実装は、28日レポートのリンク取得、レポート本文の読み込み、pull_requests.copilot_suggestions_by_comment_typeの集計という流れになる。

import json
import os
from collections import defaultdict

import requests

enterprise = os.environ["GITHUB_ENTERPRISE"]
token = os.environ["GITHUB_TOKEN"]
base = "https://api.github.com"
endpoint = f"{base}/enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest"
headers = {
    "Authorization": f"Bearer {token}",
    "Accept": "application/vnd.github+json",
    "X-GitHub-Api-Version": "2026-03-10",
}
links = requests.get(endpoint, headers=headers, timeout=30).json()["download_links"]

def load_records(text):
    try:
        data = json.loads(text)
        return data if isinstance(data, list) else data.get("records", [data])
    except json.JSONDecodeError:
        return [json.loads(line) for line in text.splitlines() if line.strip()]

totals = defaultdict(lambda: {"posted": 0, "applied": 0})
for link in links:
    for row in load_records(requests.get(link, timeout=30).text):
        prs = row.get("pull_requests", {})
        for item in prs.get("copilot_suggestions_by_comment_type", []):
            key = item["comment_type"]
            totals[key]["posted"] += item["total_copilot_suggestions"]
            totals[key]["applied"] += item["total_copilot_applied_suggestions"]

for key, value in sorted(totals.items()):
    rate = value["applied"] / value["posted"] if value["posted"] else 0
    print(f"{key:15} posted={value['posted']:5d} applied={value['applied']:5d} rate={rate:.1%}")

このサンプルは、レポートファイルがJSON配列でもNDJSONでも読めるようにしている。実運用では、結果を日次でJSONLに保存し、Grafana、Looker、Datadog、BigQueryなどに流せばよい。

権限面では、Enterprise所有者、billing manager、またはView Enterprise Copilot Metrics相当の権限を持つユーザーが対象になる²。Organization単位で見る場合は、対応するOrganization metrics endpointを使う。

設計時の落とし穴¶

数字が動いたとしても、それだけで改善とは言えない。最低限、3つの制約を明示しておく必要がある。

1つ目は、comment_typeがCopilot側の分類であることだ。securityラベルが付いた提案は、セキュリティに関係する可能性を示すが、重大度や脆弱性確定を意味しない。

2つ目は、applied率のバイアスである。開発者が「コメントを閉じるため」に軽微な変更を採用することはある。逆に、正しい指摘でも設計判断として採用しないこともある。

3つ目は、対象範囲の限定である。このメトリクスはCopilot code reviewの提案を測るもので、人間レビュアの議論、Copilot Chatでの相談、外部SASTの指摘までは含まない。

そのため、KPIは単一数値にしない方がよい。提案密度、applied率、レビュー時間、PR throughput、time to mergeを組み合わせ、ダッシュボードではなく意思決定の材料として扱う。

まとめ¶

Copilot code reviewの提案をcomment_type別に追えるようになったことで、AIレビューの効果測定は「導入したか」から「どの種類の指摘が採用されているか」へ進められる。

最初に見るべきは、securityやbug_riskの絶対評価ではない。種別別の提案密度とapplied率を並べ、自社の過去データと比較することである。

公開直後の今は、KPIしきい値を作る段階ではない。まず4〜12週間のベースラインを取り、誤検知が多いカテゴリと実際に効いているカテゴリを分ける。その後で、Copilot code reviewを「便利なAIレビュー」から「測定可能なレビュー基盤」へ育てる方がよい。