本記事はAIを利用して作成した技術解説・実装例です。掲載するコードや手順は一次情報を基に構成していますが、筆者による実機での動作確認は行っていません。環境やバージョンによって動作が異なる場合があります。
GitHubのUsage metrics APIにおいて、企業および組織のリポジトリレベルのCopilot利用状況レポートに、プルリクエストがレビューの各段階でどれだけの時間を費やしているかを詳細に把握するための機能が追加されました。本記事では、公式の変更履歴をもとに、新たに追加されたデータ構造や集計の仕組み、利用時の注意点を安全かつ実用的に整理して解説します。
変更の背景と目的
開発チームにおいて、プルリクエストがマージされるまでに長時間がかかっている状況を把握できても、「プロセスのどの段階で停滞しているのか」を特定することはこれまで難しかったという背景があります。一次情報によると、今回のアップデートではレビューにかかる待機時間を3つのステージに分割し、それぞれの期間における中央値（median）と90パーセンタイル（p90）を測定できるようになっています。
これにより、プルリクエストがレビューの開始を待っている状態なのか、レビュー担当者とのやり取り（バック・アンド・フォーース）に時間がかかっているのか、あるいは承認済みであるにもかかわらず未マージのまま放置されているのかを区別できるようになります。また、中央値だけでなく90パーセンタイルを併記することで、一部の例外的な遅延プルリクエストが全体に与えている影響を確認しやすくなると説明されています。
追加されたデータ構造の概要
エンタープライズおよび組織向けの repos-1-day レポートに、新しく pull_request_review_times 配列が追加されます。この配列に含まれる各エントリには、以下の要素が定義されています。
authored_byおよびreviewed_by: プルリクエストを開いた人物とレビューした人物を示します。今回のリリースでは、どちらも人間（human）が対象となります。total_merged: その日にリポジトリでマージされた、条件を満たすプルリクエストの数です。median_minutes_ready_to_first_reviewおよびp90_minutes_ready_to_first_review: プルリクエストがレビュー準備完了（ready for review）になってから最初のレビューが行われるまでの時間です。median_minutes_first_to_final_reviewおよびp90_minutes_first_to_final_review: 最初から最後のレビューまでの間隔です。median_minutes_final_review_to_mergeおよびp90_minutes_final_review_to_merge: 最後のレビューからマージされるまでの時間です。
これらの期間はすべて「分（minutes）」単位で計測され、プルリクエストがマージされた日に帰属して集計されます。なお、従来の pull_requests フィールドはそのまま変更されずに維持されます。
レビュー段階のデータ構造と集計の流れ
以下は、一次情報に記載されている pull_request_review_times 配列のデータ構造と、対象となるプルリクエストが計測されるまでの流れを概念的に示したものです。
flowchart TD
A[プルリクエスト作成・準備完了] --> B{人間によるレビュー実施?}
B -- Yes --> C[Stage 1: Ready to First Review]
C --> D[Stage 2: First to Final Review]
D --> E[Stage 3: Final Review to Merge]
E --> F[マージ完了日に集計・repos-1-dayへ出力]
B -- No / ボットのみ --> G[従来の pull_requests のみで集計]
この図が示す通り、計測対象となるのは人間によってレビューが行われたプルリクエストであり、レビューの各段階（ステージ1からステージ3）を経てマージされた日付のレポート行に集計されます。
計測対象とカウントの仕様
一次情報では、どのようなプルリクエストがカウントの対象となるかについて厳密な条件が明記されています。
人間のレビューが必須: 人間が開き、少なくとも他の1人の人間がレビューしたプルリクエストが対象です。Copilotによるコードレビュー、その他のボット、および作成者自身によるレビューは時間計測から除外されます。ただし、人間とCopilotの両方からレビューを受けたプルリクエストは、人間のレビューが含まれているため集計対象に含まれます。
total_mergedの差異: その結果として、pull_request_review_times[].total_mergedの数値は、レビューなしでマージされたプルリクエストも含めてカウントする既存のpulls_requests.total_mergedよりも通常は小さくなります。バックフィルの非対応: データはリリース日以降に前方に向かって蓄積されるため、初期段階のデータは少なくなります。2026年9月21日よりも前にレビュー準備が完了したプルリクエストはこのセクションから除外されますが、従来の
pull_requests.total_mergedには引き続きカウントされます。データがない日と単一レビューの扱い: 資格を満たすプルリクエストがマージされなかった日、配列は
0ではなく空の配列[]となります。また、プルリクエストが単一のレビューのみを受けた場合、最初から最後までのレビュー段階（first-to-final review stage）の時間は0として扱われます。
アクセス権限と利用時の前提条件
この新しいAPI機能を利用するためには、適切なロールとポリシーの設定が必要です。
アクセス権を持つロール: エンタープライズオーナー、請求管理者（billing managers）、組織オーナー、および「View Copilot Metrics」の権限を付与されたカスタム組織・エンタープライズロールを持つユーザーがアクセスできます。
ポリシーの有効化: Copilotの利用状況メトリクスに関するポリシーが有効に設定されている必要があります。
具体的なAPIの呼び出し方法やエンドポイントの詳細については、公式のCopilot usage metrics API documentationを参照してください。
まとめ
本記事で解説したUsage metrics APIにおけるプルリクエストレビュー段階の追加について、実行前・利用前に確認すべき点と制約を以下に回収します。
【実機確認前】本機能はエンタープライズおよび組織レベルの
repos-1-dayレポートで提供されるため、個人リポジトリや権限のない環境では確認できません。計測対象は人間によるレビューが行われたプルリクエストに限定されており、Copilotコードレビューやボットによるレビュー時間は除外されます。
データは2026年9月21日以降のリリース分から前向きに蓄積されるため、過去データのバックフィルは行われません。
対象機能を利用するには、エンタープライズまたは組織の適切なオーナー権限、および「View Copilot Metrics」権限とポリシーの有効化が必須となります。
