目次
GitHubは2026年11月5日、Copilot usage metrics の別日次レポートに、コードレビューのコメント対応状況を示す項目を追加しました。これまでは、提案を適用するボタンの利用などを追えました。今回の項目では、開発者が自分でコードを直した場合や、Copilotに修正を依頼した場合なども捉えます。対象はEnterpriseまたはOrganizationのリポジトリ別レポートです。管理者は、まず少数のリポジトリで評価件数と対応件数を並べ、コメントを減らすべき箇所や人のレビューを残す箇所を見極められます。
ただし対応率は、不具合が解消された割合ではありません。後続のプルリクエスト（PR）で直すと返信した場合も対応として数えられます。また、集計日はコメントが出た日ではなくPRの日です。本稿ではGitHub Changelog：コードレビュー指標の追加と資料に基づき、集計の実装と、数字をどう判断につなげるかを説明します。以下の数値は計算方法を示す仮例です。
スポンサーリンク
コメント対応率と提案の適用数は別の指標
追加されたcopilot_code_reviewオブジェクトのうち、total_comments_evaluatedは、開発者が対処したかを評価したコメントの件数です。total_comments_addressedは、その中で対処したと判定された件数です。対応率は後者を前者で割ります。提案をボタンで適用した場合だけでなく、自分で編集した場合、Copilotに修正を頼んだ場合、後続PRでの修正を返信で示した場合も含みます。たとえばコードを直さず返信だけをした場合でも、定義上は対応に含まれることがあります。
一方、従来のpull_requests.total_copilot_applied_suggestionsは、適用可能な提案が実際に適用された数です。二つの件数の差を「手動で修正した件数」として計算することはできません。対象となるコメントや計上の条件が異なり、新指標には修正予定の返信も入るためです。既存ダッシュボードに列を追加する場合は、指標名に対象が分かる説明を付け、以前の提案適用率の時系列へそのままつなげないようにします。
導入時に使えるのは、コメントが対応につながったかを調べる入口としてです。たとえば、同じチームで高い重要度の指摘があまり対応されていなければ、抜き取ったPRで、根拠が足りない指摘、既知の制約を見落とした指摘、修正の必要がない指摘を分けます。逆に対応率が高い場合も、後続PRに送っただけの指摘が多いなら、当初のPRの品質改善を示す数字とは言えません。後続作業が実際に完了したかは、課題や後続PRで追う必要があります。
repos-1-dayを取得しレポートの日付で保存する
GitHub Docs：Copilot usage metrics REST APIでは、OrganizationとEnterpriseに別々のリポジトリ用を案内しています。既存のユーザー別レポートや組織全体の集計から今回の項目を探すと、同名のオブジェクトが見つからないことがあります。組織単位で運用するなら、次のパスに組織名と対象日を渡します。例のORGとDAYは置き換えてください。実行者には対象範囲の閲覧権限が必要で、Copilot usage metricsポリシーも有効にしておく必要があります。
GET /orgs/ORG/copilot/metrics/reports/repos-1-day?day=DAY
GET /enterprises/ENTERPRISE/copilot/metrics/reports/repos-1-day?day=DAYAPIから直接、集計行が返るわけではありません。応答に含まれるdownload_linksを取得し、ダウンロードしたNDJSONを一行ずつ読みます。複数のリンクが返った場合はすべてを処理します。日付は処理した日の時計ではなく、応答が示すレポート日と照合して保存します。定期処理で同じ日を再取得した場合は、同じ範囲の日次集計を二重に足さず、保管した日次結果を更新するようにします。EnterpriseとOrganizationの両方で同じ範囲を集計する場合も、同じリポジトリを二重に計上しない集計単位を先に決めます。
ダウンロードリンクの取得に成功しても、ファイルの取得と解釈まで終わったとは限りません。運用上は、APIの応答、ファイルの取得、NDJSONの解釈、日次データの保存を別々に記録します。一部ファイルの取得に失敗した日は、取得できた分だけで全体の対応率を出さない方がよいでしょう。前回と比べて急に数字が下がったときに、実際に対応が減ったのか、一部のデータだけを読んだのかを切り分けられるようにするためです。
スポンサーリンク
週次の対応率は件数を合計してから割る
仮に、月曜に評価2件のうち2件へ対応し、火曜に評価18件のうち9件へ対応したとします。日別の対応率を平均すると75％ですが、この2日間のコメントをまとめると11件を20件で割った55％です。コメント一件あたりの対応割合を出したい場合、先に件数を合計します。リポジトリを横断する場合も同様です。小さなリポジトリの率と大きなリポジトリの率を等しく重み付けしたい場合は、別の指標として、何を平均した値かを明記します。
次は、取得済みの日次行を一つのリポジトリに絞り、重複を除いた後の集計例です。検証用の例で、APIから実測した値ではありません。評価件数がゼロなら、対応率は計算せず、グラフでは欠測とは区別して「評価対象なし」と表示します。
def addressed_rate(rows):
evaluated = addressed = 0
for row in rows:
review = row["copilot_code_review"]
evaluated += review["total_comments_evaluated"]
addressed += review["total_comments_addressed"]
return {
"evaluated": evaluated,
"addressed": addressed,
"rate": addressed / evaluated if evaluated else None,
}GitHubによると、レビュー活動がなかったリポジトリの日は、オブジェクト内の件数はゼロで内訳配列は空です。ファイルが取得できず行がない場合や、保存済みの古いデータにオブジェクトがない場合とは意味が異なります。集計処理では、オブジェクトがない行を無条件にゼロへ置き換えず、取得経路、レポートの種類、対象日を確認します。古い期間も集計するときは、フィールドが確認できた最初の日付を記録し、前の期間を新しい指標のゼロ件として表示しないようにします。
マージ日とボットPRの扱いを比較条件に入れる
コメントはPRがマージされたときに評価され、投稿された日には計上されません。たとえば金曜にレビューされた大きなPRが翌週にマージされた場合、そのコメントは翌週の数字に入ります。ルールやレビュー設定を切り替えた直後は、旧設定でレビューしたPRと新設定でレビューしたPRのマージが同じ日に混ざることがあります。変更日の前後で効果を比較するなら、移行直後を別扱いにするか、サンプルのPRで初回レビュー日とマージ日を照合します。
ボットが開いたPRでは、Copilotが通常コメントの対応を評価しないとGitHubは説明しています。一方、Copilotの初回レビュー後に人から変更要求を受けずマージされたPRを数えるtotal_merged_no_human_change_request_after_reviewには、ボットのPRも含まれます。この二つの指標を同じ母集団の結果として扱うと、自動更新PRが多いリポジトリの傾向を誤って読み取ります。人による変更要求がなかった件数も、人の確認が不要だった件数や、不具合がなかった件数には置き換えられません。人が実際にどこまで見たかを調べるには、PRの記録を別に確認します。
運用上は、実装を見直すための比較対象を絞ると数字を読みやすくできます。たとえば依存更新が主体のリポジトリと、機能開発の変更が集中するリポジトリでは、レビューの内容もマージのタイミングも違います。全組織で一つの目標値を決める前に、同じリポジトリの近い期間を比較し、対象となったPRの種類に大きな偏りがないかを調べます。未マージのPRの指摘を調べたい場合は、この対応率ではなく、レビュー待ちのPRやコメントの履歴を直接確認します。
スポンサーリンク
内訳から改善対象を選び実際のPRで確かめる
新しいオブジェクトには、重要度、レビューの段階、コメントの種類、カスタマイズ別の内訳もあります。同じコメントを異なる観点から集計するため、四つの内訳を横に足して総件数にしません。たとえばリポジトリ固有の規約を伝える指示を変更する場合は、その設定を変えたリポジトリを絞り、規約関連の指摘と対応の中身を確認します。内訳に差が出ても、変更後にマージしたPRの内容が違えば、設定だけが原因とは言えません。集計はレビュー対象を選ぶために使い、因果関係は別の比較で確かめます。
最初のダッシュボードには、対応率だけでなく、評価件数、対応件数、マージ日、対象範囲を並べます。たとえば対応率が前週と同じでも、評価件数が半分なら、指摘が届いた範囲は変わっています。反対に、件数が少ない週に率が跳ねても、一つのPRにコメントが集中した可能性があります。定期レビューでは、少数のPRを抽出し、指摘の正しさ、修正の有無、修正を先送りした理由を人が確認します。
チームの次の判断につなげるには、コメント対応率を達成目標にするより、率が低い種類から改善候補を選ぶ方が使いやすくなります。たとえば誤った指摘が多いなら、規約の書き方を直して比較します。正しい指摘が先送りされがちなら、レビューの設定ではなく、後続対応を追う手順を見直します。今回の追加項目で分かるのは、評価されたコメントにどの程度反応があったかです。品質を判断する際は、マージ後の修正や不具合報告など、別の記録と組み合わせます。
