GitHub Copilot をコードレビューに入れているのに、「開発者が本当に使っているのか」「ルールで自動レビューが走っているだけなのか」が分からない。そんな悩みに、ようやく答えが出せるようになりました。GitHub は 2026年4月6日、Copilot usage metrics でコードレビューのアクティブユーザーとパッシブユーザーを区別できる更新を公開し、enterprise / organization の管理者が daily と 28-day の user-level reports で確認できるようにしています。(The GitHub Blog)
結論からいうと、この更新の価値は「導入されているか」と「使われているか」を分けて判断できることです。さらに 2026年4月8日には、Copilot にレビューされたプルリクエストのマージ件数とマージまでの時間を追える指標も usage metrics API に追加されました。active / passive の区別を、レビュー済みPRの成果指標と組み合わせて読むことで、設定の問題なのか、現場定着の問題なのかを切り分けやすくなります。(The GitHub Blog)
GitHub Copilot メトリクスで何が変わったのか
今回の更新で追加された見方は、Copilot code review の利用をユーザー単位で active と passive に分けることです。GitHub 公式の定義では、used_copilot_code_review_active はユーザーが意図的に Copilot レビューへ関与した場合、used_copilot_code_review_passive はリポジトリのポリシーで自動レビューが走ったものの、そのレビューにユーザーが関与しなかった場合を表します。(The GitHub Blog)
| 区分 | 公式の判定 | 実務での読み方 |
|---|---|---|
| アクティブ | Copilot を reviewer に割り当てた、再レビューを要求した、Copilot の提案を適用した | 開発者が Copilot レビューを受け身で終わらせず、実際に使っている |
| パッシブ | リポジトリレベルのポリシーで自動レビューが実行されたが、ユーザーはレビューに関与していない | カバレッジはあるが、現場で使いこなされているとはまだ言えない |
同じ日に active と passive の両方が発生した場合は、active が優先されます。つまり、最終的に見たいのは「レビューが走った人数」ではなく、「レビューに触れた人数」です。(The GitHub Blog)
Copilot レポートで active / passive が重要な理由
自動レビューの配備と、実利用を分けて見られる
これまで Copilot コードレビューを全社展開すると、数字の見た目だけは良くなりやすいのが難点でした。ruleset で自動レビューを有効にすれば、レビュー自体は多くのPRに付きます。しかし、それだけでは開発者がコメントを読み、再レビューを依頼し、提案を採用しているかは分かりません。GitHub 自身もこの更新の意義を「coverage ではなく real engagement を測れること」と説明しています。(The GitHub Blog)
設定不足なのか、定着不足なのかを切り分けやすい
active / passive が分かれると、改善すべき場所が見えてきます。passive が多く active が少ないなら、ruleset の設定は進んでいる一方で、開発者がレビューを価値あるものとして使えていない可能性があります。逆に active は出ているのに passive が少ないなら、一部のメンバーが手動で使っているだけで、組織としての自動レビュー配備が不十分かもしれません。Copilot の自動レビューは個人設定だけでなく、リポジトリや組織の ruleset で体系的に有効化できるため、この切り分けは運用改善に直結します。(The GitHub Blog)
PR成果とのつながりを追いやすい
2026年4月8日の更新で、Copilot にレビューされた PR の総マージ数と、レビュー済み PR の median time to merge が usage metrics API に追加されました。ここに active / passive の視点を重ねると、「自動レビューは広がったが活用は浅い」「活用まで進み、実際にレビュー済み PR のマージが早い」といった違いを見分けやすくなります。単にレビューが付いたかどうかだけでなく、レビュー運用が成果につながっているかまで追えるようになったわけです。(The GitHub Blog)
レポートはこう読むと実務で使いやすい
以下は、GitHub の公式定義と ruleset の設定項目、追加された PR 指標を踏まえた実務上の読み方です。正解が一つに決まる表ではありませんが、改善の当たりを付けるにはかなり使えます。(The GitHub Blog)
| レポートの見え方 | ありがちな状態 | 最初にやること |
|---|---|---|
| passive が多く active が少ない | 自動レビューは回っているが、コメントが読まれていない、信頼されていない、使い方が浸透していない | custom instructions の見直し、再レビュー依頼の周知、提案適用の使い方共有 |
| active が多く passive が少ない | 一部のメンバーは手動で活用しているが、組織的な配備が弱い | protected branch 向け ruleset で自動レビューを有効化 |
| active も passive も増えている | 配備と利用の両方が進んでいる | review 済みPRのマージ件数・time to merge と合わせて成果確認 |
| どちらも低い | 権限、ポリシー、設定、認知のどれかで詰まっている | metrics policy、閲覧権限、ruleset、有効化範囲を順に確認 |
たとえば 100人規模の組織で、passive 70・active 12 なのに Copilot レビュー済み PR のマージ時間がほとんど改善していないなら、「導入はしたが、まだ使われていない」可能性が高いです。逆に passive 70・active 50 まで伸び、Copilot review 済み PR の件数やマージ速度も改善しているなら、単なる自動化ではなく運用定着が進んでいると判断しやすくなります。(The GitHub Blog)
まず確認すべき場所と取り方
ダッシュボードは全体傾向、active / passive はユーザー単位で見る
Copilot usage metrics のダッシュボードは、enterprise / organization レベルの 28日トレンドを見るのに向いています。GitHub.com では enterprise もしくは organization の Insights > Copilot usage から開けます。閲覧できるのは enterprise owners、organization admins、billing managers などで、組織単位だけ見せたい場合は View organization Copilot metrics を含む custom role も使えます。(GitHub Docs)
ただし、今回の active / passive は user-level reports で意味を持つ指標です。全体の雰囲気はダッシュボードで見て、active / passive の内訳は API か NDJSON export で掘る、という使い分けが実務では分かりやすいです。GitHub 公式も、ダッシュボードは enterprise / organization レベル、API は enterprise / organization / user レベルの記録に対応すると案内しています。(GitHub Docs)
API または NDJSON export で daily / 28-day の user report を取る
enterprise と organization のどちらでも、daily と latest 28-day の user-level report を取得できます。エンドポイントは次の4つです。
GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /enterprises/{enterprise}/copilot/metrics/reports/users-28-day/latest
GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/users-28-day/latestこれらのレポートは、Copilot features の user-level usage data と engagement metrics を返し、daily と 28-day の両方で signed URL からダウンロードできます。ダッシュボード右上の Export から NDJSON を取り、Copilot Chat やBIに流す運用も公式に案内されています。(GitHub Docs)
既存の集計スクリプトを使っている場合は、旧 /copilot/metrics API をそのまま使わないように注意してください。GitHub 公式ドキュメントでは、この旧 metrics endpoint は 2026年4月2日に終了済みで、今後は Copilot usage metrics endpoints を使うよう明記されています。(GitHub Docs)
自動レビューの設定を整えて、passive を active に変える
自動レビューは、個人設定だけでなく、リポジトリや組織の ruleset で Automatically request Copilot code review を有効にして構成できます。さらに Review new pushes をオンにすると push ごとに再レビューでき、Review draft pull requests をオンにすると draft 段階でもレビューが走ります。protected branch を対象に広げると、チーム運用として安定しやすくなります。(GitHub Docs)
ただし、自動レビューを増やすだけでは active は伸びません。active 判定に入る行動は、Copilot を reviewer に追加する、再レビューを依頼する、提案を適用することです。チーム向けの短い使い方ガイドを用意し、「コメントを読んで終わり」にしない導線を作ると、passive 偏重から抜けやすくなります。(The GitHub Blog)
custom instructions を入れると、レビューのノイズを減らしやすい
passive が多いのに active が伸びないときは、Copilot のレビューコメントがチームの文脈に合っていないことがよくあります。GitHub 公式のチュートリアルでは、custom instructions に repository context、style and conventions、secure coding、error handling、review style などを入れる例が示されています。レビューコメントがプロジェクトの設計方針や品質基準に近づくほど、開発者は「読んでも役に立たない」と感じにくくなります。(GitHub Docs)
見落としやすい注意点
- 直近の数字を確定値として扱わないことです。GitHub 公式では、usage metrics のデータは通常 2日以内に利用可能になると説明する一方、ダッシュボードや export の比較では recent telemetry が完全に反映されるまで最大 3 full UTC days ほど遅れる場合があると案内しています。日次の落ち込みを見ても、まずは 2〜3日置いてから判断するのが安全です。(GitHub Docs)
- dashboard と API を同じ感覚で比べないことです。ダッシュボードは 28-day rolling window、API と NDJSON export は daily records が基本です。比較期間をそろえないと、「ダッシュボードでは増えているのに daily report では落ちている」という誤読が起きやすくなります。(GitHub Docs)
- organization と enterprise の数字を単純比較しないことです。GitHub 公式では、organization-level metrics は organization membership ベースで、enterprise-level totals は user を重複排除すると説明しています。同じユーザーが複数 organization に所属していると、organization 側では重複して見えても enterprise 側では一度しか数えられません。(GitHub Docs)
- Copilot レビューを人間レビューの代わりにしないことです。Copilot のレビューは comment review であり、Approve や Request changes にはなりません。required approvals にも数えられず、merge をブロックもしません。さらに GitHub は、Copilot code review は human reviews を置き換えるのではなく補完として使うべきで、見落としや false positives の可能性があると明記しています。(GitHub Docs)
- コスト感覚を忘れないことです。GitHub 公式では、Copilot が pull request をレビューするたびに premium request を1つ消費します。自動レビューなら PR 作成者の quota、手動で他人がレビューを依頼したならその依頼者の quota に計上されます。active を増やす施策を打つなら、利用促進とあわせて誰の利用枠に乗るかも把握しておくべきです。(GitHub Docs)
まとめ
GitHub Copilot メトリクスでコードレビューの active / passive を区別できるようになったことで、ようやく「自動レビューを配っただけ」なのか、「現場で本当に使われている」のかを分けて見られるようになりました。daily / 28-day の user-level reports で used_copilot_code_review_active と used_copilot_code_review_passive を取り、Copilot review 済み PR のマージ件数や time to merge と並べれば、導入の深さまで判断できます。(The GitHub Blog)
実務で最初にやるなら、最新 28-day の user-level report を取得し、active と passive の偏りを確認してください。passive 偏重なら ruleset だけで満足せず、custom instructions、再レビュー依頼、提案適用の運用に手を入れる。active が伸びてきたら、Copilot review 済み PR の成果指標とつなげて、レビュー時間短縮やマージ速度改善まで見ていく。この順番で進めると、GitHub Copilot のコードレビューを「入れた」から「効いている」へ進めやすくなります。(GitHub Docs)
コメント