「どのリポジトリでGitHub Copilot coding agentやCopilot code reviewが使われたのか」を日次で確認したい場合は、GitHub Copilot usage metrics APIのrepos-1-dayエンドポイントを利用します。Enterprise全体は/enterprises/{enterprise}/...、Organization単位は/orgs/{org}/...を呼び出し、day=YYYY-MM-DDで対象日を指定します。
ただし、APIを呼び出すだけでは取得できません。GitHub Enterprise CloudでCopilot usage metrics policyを有効化し、適切な管理権限とトークン権限を用意する必要があります。また、レスポンスに集計結果が直接入るのではなく、期限付きURLからNDJSON形式のレポートをダウンロードする2段階構成です。2026年7月17日に一般提供されたリポジトリ別レポートでは、Copilot coding agentによるプルリクエスト活動や、Copilot code reviewによるレビュー活動をリポジトリ単位で確認できます。(The GitHub Blog)
GitHub Copilotのリポジトリ別利用状況はrepos-1-dayで取得する
利用するREST APIは、集計範囲によって次の2種類に分かれます。
| 集計範囲 | エンドポイント | 主な用途 |
|---|---|---|
| Enterprise | GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD | Enterprise全体のリポジトリを横断して確認する |
| Organization | GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD | 特定Organization内のリポジトリだけを確認する |
dayには、2026-07-15のようなYYYY-MM-DD形式の日付を指定します。1回の呼び出しで取得できるのは1日分です。Enterprise、Organizationのどちらも、その日に対象となる活動があったリポジトリだけがレポートに含まれ、原則として1リポジトリにつき1エントリが出力されます。(GitHub Docs)
APIの処理は、次の2段階です。
repos-1-dayを呼び出し、download_linksとreport_dayを取得するdownload_linksに含まれる期限付きURLからNDJSONファイルをダウンロードする
複数のdownload_linksが返る可能性があるため、最初のURLだけではなく、すべてのURLを処理する必要があります。URLには有効期限があるため、APIレスポンスを保存したまま後日ダウンロードする運用には向きません。(GitHub Docs)
このAPIで分かることと分からないこと
repos-1-dayは、GitHub Copilotのすべての利用状況をリポジトリへ割り当てるAPIではありません。対象は、主にGitHub上のプルリクエスト活動です。
| 確認したい内容 | 対応状況 |
|---|---|
| Copilot coding agentがPRを作成したリポジトリ | 確認できる |
| Copilot coding agentが作成したPRのマージ状況 | 確認できる |
| Copilot code reviewがPRをレビューしたリポジトリ | 確認できる |
| Copilot code reviewによる提案活動 | 確認できる。ただし実際のフィールド構成は初回取得時に要確認 |
| IDE上でコード補完を承認したリポジトリ | 確認できない |
| Copilot Chatを使用したリポジトリ | 確認できない |
| ユーザーが入力したプロンプトの内容 | 確認できない |
| Copilotライセンスの割り当て状況 | このAPIの対象外 |
つまり、このAPIが答えられるのは、主に次の問いです。
どのリポジトリで、Copilot coding agentやCopilot code reviewによるプルリクエスト活動が発生したか。
一方、「Visual Studio Codeでコード補完が使われたリポジトリ」や「Copilot Chatが多く使われたリポジトリ」を知るためのAPIではありません。リポジトリ別レポートは、プルリクエスト関連の利用状況として設計されています。(GitHub Docs)
REST APIを実行する前に確認する前提条件
GitHub Enterprise Cloudが対象
今回のリポジトリ別レポートは、GitHub Enterprise CloudでGitHub Copilot BusinessまたはGitHub Copilot Enterpriseを管理している環境を前提とします。
Organization単位で取得する場合でも、Enterprise側でポリシーが強制されていると、Organization管理者が設定を変更できないことがあります。
Copilot usage metrics policyを有効化する
リポジトリ別レポートを取得するには、対象範囲でCopilot usage metricsポリシーが有効になっている必要があります。ポリシーが無効なままでは、管理者権限やトークンスコープが正しくても、利用状況レポートへアクセスできません。(GitHub Docs)
Enterpriseで有効化する場合
Enterprise ownerとして、Enterpriseの設定画面を開きます。
- Enterpriseアカウントの設定を開く
AI controlsからCopilotを開く- Copilot関連ポリシーの一覧を確認する
Copilot usage metricsを有効化する- 適用対象のOrganizationを確認する
Enterprise側で適用を強制すると、配下のOrganizationでは独自に無効化できない場合があります。(GitHub Docs)
Organizationで有効化する場合
Organization ownerとして、対象Organizationの設定画面を開きます。
- GitHubのプロフィールメニューから
Organizationsを開く - 対象Organizationの
Settingsを開く Copilotの設定を開くPoliciesから利用状況メトリクスを有効化する
Enterpriseポリシーによって設定が固定されている場合は、Organization側では変更できません。その場合はEnterprise ownerに確認します。(GitHub Docs)
実行ユーザーとトークンに必要な権限
管理画面上の役割と、APIトークンの権限は別々に確認する必要があります。トークンにスコープがあっても、トークンを発行したユーザーに対象EnterpriseやOrganizationを参照する権限がなければ取得できません。
| 対象 | 実行ユーザーの代表的な権限 | トークンの代表的な条件 |
|---|---|---|
| Enterprise | Enterprise owner、billing manager、またはView Enterprise Copilot Metricsを持つカスタムロール | Classic PATではmanage_billing:copilotまたはread:enterprise |
| Organization | Organization owner、またはView Organization Copilot Metricsを持つカスタムロール | Classic PATではread:org |
| EnterpriseをGitHub Appで取得 | Enterpriseのメトリクスを参照できるGitHub App | Enterprise Copilot metricsのRead権限 |
| Organizationをfine-grained PATで取得 | Organizationのメトリクスを参照できるユーザー | Organization Copilot metricsのRead権限 |
Organizationエンドポイントではfine-grained personal access tokenが対応トークンとして案内されています。一方、Enterpriseエンドポイントの対応トークン一覧にはfine-grained PATが掲載されていないため、Enterprise取得でfine-grained PATが使えることを前提に実装しない方が安全です。EnterpriseではClassic PAT、または必要な権限を付与したGitHub Appの利用を検討します。(GitHub Docs)
cURLで1日分のリポジトリレポートを取得する手順
以下は、EnterpriseとOrganizationの両方に対応したBashスクリプトです。実行にはcurlとjqを使用します。
APIリクエストでは、GitHub REST APIのメディアタイプ、Bearerトークン、APIバージョンをヘッダーで指定します。2026年7月時点の公式リクエスト例では、X-GitHub-Api-Version: 2026-03-10が使用されています。(GitHub Docs)
#!/usr/bin/env bash
set -euo pipefail
scope="${1:?enterprise または org を指定してください}"
owner="${2:?EnterpriseのslugまたはOrganization名を指定してください}"
day="${3:?YYYY-MM-DD形式の日付を指定してください}"
: "${GITHUB_TOKEN:?環境変数 GITHUB_TOKEN を設定してください}"
if [[ ! "$day" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
echo "日付はYYYY-MM-DD形式で指定してください: ${day}" >&2
exit 2
fi
case "$scope" in
enterprise)
endpoint="https://api.github.com/enterprises/${owner}/copilot/metrics/reports/repos-1-day?day=${day}"
;;
org)
endpoint="https://api.github.com/orgs/${owner}/copilot/metrics/reports/repos-1-day?day=${day}"
;;
*)
echo "第1引数には enterprise または org を指定してください" >&2
exit 2
;;
esac
workdir="copilot-repo-metrics/${scope}-${owner}/${day}"
response="${workdir}/response.json"
report="${workdir}/repos-${day}.ndjson"
mkdir -p "$workdir"
http_status="$(
curl -sS -L \
-o "$response" \
-w '%{http_code}' \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer ${GITHUB_TOKEN}" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"$endpoint"
)"
case "$http_status" in
200)
;;
204)
echo "HTTP 204: レポート本文はありません。日付やデータ反映状況を確認してください。"
rm -f "$response"
exit 0
;;
*)
echo "API呼び出しに失敗しました。HTTPステータス: ${http_status}" >&2
if [[ -s "$response" ]]; then
jq . "$response" 2>/dev/null || cat "$response"
fi
exit 1
;;
esac
if ! jq -e '(.download_links | type) == "array"' "$response" >/dev/null; then
echo "レスポンスにdownload_links配列がありません" >&2
jq . "$response" >&2
exit 1
fi
reported_day="$(jq -r '.report_day // empty' "$response")"
if [[ -n "$reported_day" && "$reported_day" != "$day" ]]; then
echo "警告: 要求日${day}に対し、report_dayは${reported_day}です" >&2
fi
part=0
while IFS= read -r url; do
[[ -z "$url" ]] && continue
part=$((part + 1))
printf -v part_file '%s/part-%03d.ndjson' "$workdir" "$part"
curl --fail-with-body -sS -L \
"$url" \
-o "$part_file"
done < <(jq -r '.download_links[]' "$response")
if (( part == 0 )); then
echo "ダウンロード対象のURLがありません"
exit 0
fi
cat "$workdir"/part-*.ndjson > "$report"
echo "取得完了: ${report}"
echo "分割ファイル数: ${part}"
echo "レコード数: $(wc -l < "$report")"このスクリプトをfetch-copilot-repos.shとして保存し、実行権限を付与します。
chmod +x fetch-copilot-repos.shトークンはソースコードへ直接書かず、環境変数やシークレット管理機能から渡します。
export GITHUB_TOKEN="YOUR_TOKEN"Organizationの日次レポートを取得する場合は、次のように実行します。
./fetch-copilot-repos.sh org your-organization 2026-07-15Enterprise全体を取得する場合は、第1引数をenterpriseに変更します。
./fetch-copilot-repos.sh enterprise your-enterprise-slug 2026-07-15APIの認証ヘッダーは、最初のGitHub REST API呼び出しだけに使用しています。download_linksのURL自体が一時的なアクセス権を持つため、ダウンロード処理ではGitHubトークンを付与しません。
APIレスポンスとNDJSONの扱い方
最初のREST APIレスポンスには、集計データそのものではなく、次のような情報が返ります。
{
"download_links": [
"https://example.com/copilot-usage-report-part-1.ndjson"
],
"report_day": "2026-07-15"
}download_linksは1件とは限りません。データ量などによって複数ファイルに分割される可能性があるため、配列全体をループ処理します。
ダウンロードされるNDJSONは、1行ごとに独立したJSONオブジェクトが格納される形式です。通常のJSON配列とは異なるため、ファイル全体をそのまま1つのJSONオブジェクトとして解析しないようにします。
最初のレコードを確認するには、次のコマンドを使用します。
report="copilot-repo-metrics/org-your-organization/2026-07-15/repos-2026-07-15.ndjson"
head -n 1 "$report" | jq .実際に含まれるトップレベルのキーを確認する場合は、次のように実行します。
jq -r 'keys_unsorted[]' "$report" | sort -u最初のレコードに含まれるネストした項目のパスを確認する方法もあります。
head -n 1 "$report" |
jq -r 'paths(scalars) | map(tostring) | join(".")'通常のJSON配列として扱いたい場合は、jq -sで変換できます。
jq -s '.' "$report" > "${report%.ndjson}.json"大量データを処理する場合、JSON配列への変換はメモリ使用量が増えます。ETL処理やログ分析基盤へ取り込む場合は、NDJSONのまま1行ずつストリーミング処理する方が適しています。
公式資料間のフィールド表現の違いに注意する
2026年7月17日のGitHub Changelogでは、Copilot code reviewの提案数をコメント種別ごとに確認できると案内されています。一方、現行のメトリクスフィールドリファレンスには、pull_requests.copilot_suggestions_by_comment_typeについて、リポジトリレベルでは利用できないという注記が残っています。(The GitHub Blog)
資料更新のタイミングによる差である可能性はありますが、実装時には次の対応が安全です。
- 初回取得時に実際のNDJSONフィールドを確認する
- 特定フィールドが必ず存在すると仮定しない
- 未知のフィールドが追加されても処理を継続できるようにする
- 必須フィールドが欠けた場合は警告を記録する
- APIバージョンと取得日をログへ保存する
特に、BIツールやデータウェアハウスのテーブル定義を最初から固定すると、フィールドの追加や名称変更で取り込みが停止しやすくなります。まず生のNDJSONを保存し、その後に正規化テーブルへ変換する構成が実務向きです。
複数日を集計するときは日付ごとにAPIを呼び出す
repos-1-dayは、その名前のとおり1日単位のレポートです。1週間分や1か月分を一度に指定する開始日・終了日のパラメーターはありません。複数日を取得する場合は、日付ごとにエンドポイントを呼び出して集約します。(GitHub Docs)
例えば3日分を取得する場合は、次のように実行します。
for day in 2026-07-13 2026-07-14 2026-07-15; do
./fetch-copilot-repos.sh org your-organization "$day"
done運用では、次のようなディレクトリ構成にすると、再取得や監査が容易になります。
copilot-repo-metrics/
└── org-your-organization/
├── 2026-07-13/
│ ├── response.json
│ ├── part-001.ndjson
│ └── repos-2026-07-13.ndjson
├── 2026-07-14/
└── 2026-07-15/GitHubの利用状況レポートは、対象日が終わってすぐに確定するとは限りません。公式ドキュメントでは、APIレポートやダッシュボードのデータは、対象日が終了してから通常は最大2日分のUTC日を経て利用可能になると案内されています。安定した定期処理では、当日や前日ではなく、少なくともUTC基準で2日以上前の日付を取得対象にするのが安全です。(GitHub Docs)
集計結果を正しく読むための注意点
レポートにないリポジトリを「Copilot未使用」と断定しない
日次レポートには、その日に対象となる活動があったリポジトリだけが含まれます。
リポジトリがレポートに存在しない場合、分かるのは「その日のリポジトリ別PRレポートに記録される活動がなかった」ということです。次のような状態までは判別できません。
- Copilotが無効だった
- Copilotの利用者がいなかった
- IDEのコード補完だけが使われた
- Copilot Chatだけが使われた
- 単にその日にPR活動がなかった
未使用リポジトリも含む一覧が必要な場合は、別途取得したリポジトリマスターと日次レポートを結合し、レポートにないリポジトリをゼロ件として補完します。
日次の作成数とマージ数を単純に割らない
同じ日の「Copilotが作成したPR数」と「Copilotが作成したPRのマージ数」は、同じPR集団とは限りません。
例えば、7月15日に作成されたPRが7月18日にマージされる場合、作成イベントとマージイベントは別の日のレポートに記録されます。そのため、次の計算をそのままマージ率として扱うのは不適切です。
同日のマージ数 ÷ 同日の作成数正確なマージ率を求めるには、PR単位で作成日とマージ日を追跡するコホート分析が必要です。リポジトリ別の日次集計だけで算出する場合は、「当日の活動量」として扱い、転換率とは区別します。
レビュー数は期間内のユニークPR数とは限らない
同じPRが異なる日にレビューされた場合、各日のレビュー活動として記録される可能性があります。日次レポートを単純合算した値は「期間中のレビュー活動数」であり、「期間中にレビューされたユニークPR数」と一致しない場合があります。(GitHub Docs)
EnterpriseとOrganizationの結果を単純合算しない
EnterpriseレポートとOrganizationレポートを両方取得している場合、同じ活動を二重計上しないようにします。
また、EnterpriseとOrganizationでは、ユーザーやリポジトリの帰属、重複排除、集計タイミングなどにより、集計値が完全には一致しない場合があります。リポジトリの移管があった期間も、帰属先の解釈に注意が必要です。(GitHub Docs)
全社レポートを作る場合はEnterpriseエンドポイント、Organization管理者向けレポートを作る場合はOrganizationエンドポイントというように、用途ごとに基準となるデータソースを決めておくと混乱を防げます。
リポジトリ別レポートから作れる実用的なKPI
リポジトリ別データは、単に件数を一覧表示するだけでなく、開発プロセスの改善指標として利用できます。
| KPI | 算出の考え方 | 注意点 |
|---|---|---|
| Copilot利用リポジトリ数 | 日次レポートに登場したリポジトリ数 | PR関連の活動があったリポジトリだけを表す |
| Copilot利用リポジトリ率 | 利用リポジトリ数 ÷ 対象となるアクティブリポジトリ数 | 全リポジトリ数ではなく、アーカイブ済みなどを除いた分母を定義する |
| Copilot作成PR比率 | Copilotが作成したPR数 ÷ 同日の全PR作成数 | 全PR数は別のGitHub APIや分析基盤から取得する |
| Copilotレビュー利用率 | Copilot code reviewを利用したPR数 ÷ レビュー対象PR数 | レビュー対象の定義を組織内で統一する |
| 継続利用リポジトリ数 | 一定期間に複数日登場したリポジトリ数 | 単発検証と定常利用を区別できる |
| 導入後のPR処理時間 | 導入前後のマージ所要時間を比較する | リポジトリ規模や変更量などの条件差を考慮する |
利用リポジトリ数だけでは、Copilotが開発生産性へ与えた影響までは分かりません。PR全体の件数、マージまでの時間、変更規模、不具合率などと組み合わせて評価することが重要です。
エラーや想定外の結果が出たときの確認ポイント
Enterprise、Organizationの両エンドポイントでは、200、204、403、404、500などのHTTPステータスが定義されています。(GitHub Docs)
| 状況 | 主な確認ポイント |
|---|---|
204 No Content | レスポンス本文をjqで解析しない。対象日、データ反映待ち、レポート対象活動の有無を確認する |
403 Forbidden | Copilot usage metrics policy、管理ロール、PATスコープ、GitHub App権限を確認する |
404 Not Found | Enterpriseのslug、Organization名、エンドポイントのパス、トークンからの可視性を確認する |
500 Internal Server Error | 一時的なエラーとして、間隔を空けた再試行を行う |
200だが期待したリポジトリがない | その日に対象となるPR活動があったか確認する。行がないことをCopilot無効と解釈しない |
| ダウンロードURLでエラーになる | URLの有効期限切れを疑い、repos-1-dayを再実行する |
| 一部のデータしか取得できない | download_links[0]だけでなく、配列内のすべてのURLを処理しているか確認する |
| 日次バッチでデータが頻繁に欠ける | 対象日をUTC基準で2日以上前にずらす |
| JSONパーサーが失敗する | 通常のJSON配列ではなくNDJSONとして1行ずつ解析する |
| フィールド不足でETLが停止する | 任意フィールドを許容し、実際のNDJSONスキーマを検査する |
403や404の原因は一つとは限りません。特に、ポリシー、ユーザーロール、トークン権限の3点を個別に確認することが重要です。
本番運用で押さえるべきセキュリティと設計
最小権限のトークンを使用する
メトリクス取得専用のGitHub Appや管理用アカウントを用意し、不要な書き込み権限を与えないようにします。
Classic PATを利用する場合も、別用途の強い権限を持つトークンを流用せず、用途を限定します。トークンはCI/CDのシークレットストアやクラウドのシークレット管理サービスで保管します。
期限付きURLをログへ不用意に出力しない
download_linksは一時的とはいえ、URLを知る者がファイルへアクセスできる可能性があります。CI/CDの公開ログやチャット通知へURL全文を出力しないようにします。
response.jsonにも期限付きURLが保存されるため、保存先のアクセス権と保持期間を決めておきます。
生データと加工データを分ける
次の3層に分けると、仕様変更への対応が容易です。
- APIレスポンスを保存する層
- ダウンロードした生のNDJSONを保存する層
- BIツールやデータウェアハウス向けに整形する層
加工処理に不具合があっても、生のNDJSONが残っていれば再処理できます。
取得条件を記録する
少なくとも、次の情報をレポートと一緒に保存します。
- EnterpriseまたはOrganizationの識別子
- 指定した
day - レスポンスの
report_day - APIバージョン
- 取得日時
- HTTPステータス
- ダウンロードした分割ファイル数
- NDJSONのレコード数
- ETL処理のバージョン
これにより、後から数値が合わない場合でも、どの条件で取得したデータかを追跡できます。
まとめ：ポリシーを有効化して日次NDJSONを確実に回収する
GitHub Copilotのリポジトリ別利用状況を取得するには、EnterpriseまたはOrganization向けのrepos-1-dayエンドポイントを使用します。
実施手順は次のとおりです。
- GitHub Enterprise Cloudで
Copilot usage metricsポリシーを有効化する - EnterpriseまたはOrganizationの参照権限を持つユーザーを用意する
- エンドポイントに適したトークン権限を設定する
day=YYYY-MM-DDを指定して日次APIを呼び出す- 返された
download_linksをすべて処理する - NDJSONの実際のフィールドを確認してから集計処理を実装する
- 日次バッチはUTC基準で2日以上前を対象にする
- レポートにないリポジトリを自動的に「Copilot未使用」と判定しない
最初に行うべきことは、対象EnterpriseまたはOrganizationのCopilot usage metricsポリシーと、自分の管理ロールを確認することです。その後、まず1日分を手動取得し、NDJSONの実スキーマを確認してから定期実行へ移行すると、安全にリポジトリ別の利用状況を可視化できます。
コメント