GitHub Copilot metricsをAPIで取得し、BIダッシュボードや月次レポートに流しているチームは、2026年5月20日までにレポートダウンロードURLの許可設定を見直す必要があります。2026年4月22日の公式更新では、Copilot usage metrics report download URLsがAzure Front Door系のドメインから、GitHubが管理する安定したカスタムドメインへ移行することが告知されました。影響を受けやすいのは、ファイアウォール、プロキシ、DLP、CASB、社内ETLジョブでURLやホスト名を制限している環境です。(The GitHub Blog)
今回のポイントは、GitHub Copilot metricsの集計内容そのものではなく、Copilot Usage Metrics APIが返すレポートダウンロードリンクのドメインが変わることです。APIのレスポンスから取得したdownload_linksを使ってファイルを取りに行く2段階目の通信で失敗しないよう、ネットワーク許可リストと自動化スクリプトを早めに確認しましょう。
GitHub Copilot metricsの2026年4月更新で何が変わったか
2026年4月22日、GitHubは「Upcoming change to Copilot usage metrics report download URLs」として、Copilot usage metrics reportのダウンロードURLを変更する予定を発表しました。2026年5月20日以降、Copilot Usage Metrics APIが返すダウンロードリンクは、従来のcopilot-reports-*.b01.azurefd.netパターンではなく、新しいドメインを使うようになります。(The GitHub Blog)
変更前後の概要は次のとおりです。
| 対象環境 | 現行のURLパターン | 2026年5月20日以降のURLパターン | 対応の要点 |
|---|---|---|---|
| github.com / GitHub Enterprise Cloud | https://copilot-reports-*.b01.azurefd.net/... | https://copilot-reports.github.com/... | ファイアウォールやプロキシの許可リストに新ドメインを追加する |
| ghe.com | https://copilot-reports-*.b01.azurefd.net/... | https://copilot-reports.*.ghe.com/... | ghe.com向けのワイルドカード許可設定を確認する |
| フォールバック経路 | Azure Front DoorまたはAzure Blob Storage系URL | 障害時などにフォールバックURLが使われる可能性あり | 可用性を重視する環境ではフォールバックドメインも検討する |
GitHubは、従来のcopilot-reports-*.b01.azurefd.netパターンは移行期間中も動作するものの、最終的には非推奨になると説明しています。つまり「今すぐ旧URLが止まる」わけではありませんが、「旧URLだけを許可している構成」は将来的な障害要因になります。(The GitHub Blog)
影響を受けるチームと受けにくいチーム
今回の更新で最も影響を受けるのは、GitHub Copilot metricsを定期取得しているdevelopers、DevOps engineers、platform teamsです。特に、社内ネットワークから外部への通信を細かく制御している企業では、レポート取得ジョブだけが突然失敗する可能性があります。
| 利用状況 | 影響度 | 確認すべきポイント |
|---|---|---|
APIでdownload_linksを取得し、社内サーバーからレポートをダウンロードしている | 高 | 新ドメインへのHTTPS通信が許可されているか |
| CI/CDやスケジューラーで日次・月次の利用状況レポートを取得している | 高 | URLホスト名の固定チェックや正規表現が古くないか |
| プロキシ、DLP、CASB、SSL inspectionを通している | 高 | セキュリティ製品側の許可リスト・証明書検査・ログ分類 |
| 手動で必要なときだけ確認している | 中 | 手動操作環境でもプロキシ制限に引っかからないか |
| Copilot metricsをまだ使っていない | 低 | 将来導入時のネットワーク要件として把握しておく |
見落としやすいのは、GitHub APIへの通信ではなく、APIレスポンスに含まれるレポートファイルのダウンロード先です。Copilot Usage Metrics APIのドキュメントでは、エンタープライズや組織向けのエンドポイントがdownload_linksを返し、レポートは署名付きURLからダウンロードする形で提供されると説明されています。(GitHub Docs)
今回の変更で「変わらない」と考えてよいこと
今回の公式発表で中心になっているのは、レポートダウンロードURLのドメイン変更です。少なくとも発表内容では、メトリクスの定義、集計ロジック、APIレスポンスの基本構造、Copilotの利用可否そのものが変更されるとは説明されていません。(The GitHub Blog)
実務上は、次のように切り分けると判断しやすくなります。
| 項目 | 今回の主な影響 |
|---|---|
| GitHub Copilot metricsのデータ取得目的 | 変わらない |
APIが返すdownload_linksの利用 | 変わらないが、リンク先ドメインが変わる |
| 社内ネットワークの許可設定 | 見直しが必要 |
| URLホスト名の検証ロジック | 見直しが必要 |
| レポートを保存・集計するBI側の処理 | URLに依存していなければ影響は限定的 |
ただし、スクリプト内でazurefd.netを前提にしている場合は別です。たとえば「ダウンロードURLのホスト名が*.azurefd.netでなければ拒否する」「ログ分類でAzure Front Doorドメインだけを許可している」「プロキシ例外に旧ドメインだけを登録している」といった実装は、2026年5月20日以降に失敗する可能性があります。
2026年5月20日までにやるべき対応
最初にやるべきことは、旧ドメインを削除することではありません。安全な進め方は、新ドメインを追加し、既存ジョブが新旧どちらのURLでも動く状態にしてから、移行期間後の旧ドメイン整理を計画することです。
| 手順 | 作業内容 | 担当の目安 |
|---|---|---|
| 現状確認 | Copilot metrics取得ジョブ、BI連携、ETL、監視設定を洗い出す | DevOps / Platform |
| 文字列検索 | リポジトリ、IaC、プロキシ設定でcopilot-reports-やazurefd.netを検索する | 開発 / SRE |
| 許可リスト追加 | copilot-reports.github.comまたはcopilot-reports.*.ghe.comを追加する | ネットワーク / セキュリティ |
| フォールバック確認 | Azure Blob Storage系URLを許可する必要があるか判断する | セキュリティ / Platform |
| ジョブ検証 | ステージングまたは検証環境でレポート取得を実行する | DevOps |
| 監視追加 | ダウンロード失敗、HTTPステータス、取得件数を監視する | SRE / Platform |
| Runbook更新 | 障害時の確認項目に新旧ドメインを追記する | Platform |
GitHubは、ファイアウォールまたはプロキシの許可リストを使っている組織に対し、2026年5月20日より前にgithub.com環境ではhttps://copilot-reports.github.com、ghe.com環境ではhttps://copilot-reports.*.ghe.comを追加するよう案内しています。 (The GitHub Blog)
許可リストで注意したいフォールバックURL
可用性を重視する環境では、メインの新ドメインだけでなく、フォールバック経路も確認しておくべきです。GitHub Changelogでは、まれにAzure Front Doorが利用できない場合、レポートダウンロードがAzure Blob Storageの直接URLへフォールバックする可能性があると説明されています。(The GitHub Blog)
一方、GitHub DocsのCopilot allowlist referenceでは、Copilot usage metrics report downloads向けとしてhttps://copilot-reports.github.com、フォールバックとしてhttps://copilot-reports-*.b01.azurefd.netとhttps://usagereports*.blob.core.windows.netが掲載されています。 (GitHub Docs)
ここで重要なのは、セキュリティ部門に「*.blob.core.windows.netを全部許可してください」と雑に依頼しないことです。Azure Blob Storageは広い範囲のサービスで使われるため、組織のセキュリティポリシーによっては広すぎるワイルドカード許可が認められない場合があります。まずは公式allowlist referenceに載っているパターンを基準にし、必要に応じてセキュリティチームと範囲を調整しましょう。
自動化スクリプトで確認すべき実装ポイント
Copilot Usage Metrics APIを使う自動化では、URLを自前で組み立てるのではなく、APIレスポンスのdownload_linksをそのまま使う設計が基本です。レポートURLは署名付きで、有効期限があるため、古いURLを保存して何度も再利用する設計は避けるべきです。GitHub Docsでも、レポートは日次で生成され、期限付きの署名URLからダウンロードされると説明されています。(GitHub Docs)
確認すべきポイントは次のとおりです。
download_linksのURLを自前で生成していないか- ホスト名の検証で
azurefd.netだけを許可していないか - プロキシやcurlの失敗を「APIエラー」と誤分類していないか
- 署名付きURLをログに完全出力していないか
- URLの有効期限切れ時に、古いリンクを再試行し続けていないか
- 取得したレポート件数と保存件数を照合しているか
実装イメージは次のようになります。ポイントは、APIから返されたリンクを使い、許可するホスト名を新旧両方に対応させることです。
#!/usr/bin/env bash
set -euo pipefail
mkdir -p reports
api_url="https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest"
allowed_hosts_regex='^(copilot-reports\.github\.com|copilot-reports-[^.]+\.b01\.azurefd\.net|usagereports[^.]*\.blob\.core\.windows\.net)$'
curl -fsSL \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer ${GITHUB_TOKEN}" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"$api_url" |
jq -r '.download_links[]' |
while read -r report_url; do
host="$(python3 -c 'from urllib.parse import urlparse; import sys; print(urlparse(sys.argv[1]).hostname or "")' "$report_url")"
if ! printf '%s' "$host" | grep -Eq "$allowed_hosts_regex"; then
echo "unexpected report download host: $host" >&2
exit 1
fi
file_name="$(basename "${report_url%%\?*}")"
curl -fL --retry 3 --retry-delay 2 "$report_url" -o "reports/${file_name}"
doneghe.com環境では、上記の許可ホストにcopilot-reports.*.ghe.com相当の条件を追加してください。実際の正規表現やワイルドカード指定は、利用しているプロキシ、WAF、ゼロトラスト製品、IaCの表現方法に合わせる必要があります。
よくある失敗パターン
旧ドメインをすぐ削除してしまう
移行期間中は、新旧どちらのURLが使われても処理できる状態にしておくのが安全です。旧ドメインを早く削除しすぎると、GitHub側の移行期間中やフォールバック時にレポート取得が失敗する可能性があります。
API疎通だけを確認して完了扱いにする
api.github.comへのリクエストが成功しても、download_linksの先にあるレポートファイルを取得できなければ、metrics収集は完了しません。監視では「APIレスポンス取得」と「レポートファイルダウンロード」を分けて確認しましょう。
URLのホスト名をログや保存先設計に使っている
保存パスやデータ分類にazurefd.netを使っていると、新ドメイン移行後にファイル名や集計先が変わることがあります。保存先はホスト名ではなく、report_day、report_start_day、report_end_day、取得対象のenterpriseまたはorganizationを基準に設計するのがおすすめです。
署名付きURLを長期間保存する
レポートのダウンロードリンクは期限付きです。再取得が必要な場合は、過去の署名付きURLを再利用するのではなく、Copilot Usage Metrics APIを再実行して新しいdownload_linksを取得する運用にしましょう。
セキュリティチームに依頼するときの書き方
ネットワーク許可の申請では、単に「GitHub CopilotのURLを追加してください」と書くより、目的・期限・対象通信を具体的に伝えると承認が進みやすくなります。
申請文には、次の内容を含めると実務上の齟齬を減らせます。
| 項目 | 記載例 |
|---|---|
| 目的 | GitHub Copilot metricsの利用状況レポートを自動取得するため |
| 変更理由 | 2026年5月20日以降、レポートダウンロードURLのドメインが変更されるため |
| 追加対象 | https://copilot-reports.github.com |
| ghe.com利用時 | https://copilot-reports.*.ghe.com |
| フォールバック候補 | https://copilot-reports-*.b01.azurefd.net、必要に応じてhttps://usagereports*.blob.core.windows.net |
| 通信方式 | HTTPS |
| 利用元 | レポート取得ジョブを実行するCI、ETLサーバー、社内プロキシ経由端末 |
| 検証方法 | API取得後、download_linksの各URLからレポートファイルを取得できることを確認 |
グローバル企業では、リージョンごとにプロキシやファイアウォールの管理者が異なることがあります。日本拠点だけで許可しても、米国や欧州のETL基盤で同じジョブが動いている場合は失敗します。Platformチームは、実行場所ごとのアウトバウンド制御を棚卸ししておきましょう。
監視とトラブルシュートの判断基準
変更後にジョブが失敗した場合は、エラーの種類で原因を切り分けます。
| 症状 | 考えられる原因 | 初動対応 |
|---|---|---|
| APIレスポンスは200だがダウンロードに失敗 | 新ドメインがプロキシでブロックされている | プロキシログでcopilot-reports.github.comまたはghe.comドメインを確認 |
| 403または認証系エラー | トークン権限、期限、APIスコープの問題 | GitHub App、PAT、権限設定を確認 |
| 署名付きURLで403 | URLの有効期限切れ | APIを再実行して新しいdownload_linksを取得 |
| 特定拠点だけ失敗 | 拠点別プロキシやゼロトラスト設定の差分 | 地域別の許可リストを確認 |
| ファイル保存後の集計が失敗 | URLやファイル名に依存した後続処理 | 保存ルールを日付・レポート種別基準に変更 |
GitHub Copilot metricsは、利用状況の可視化、ライセンス活用度の確認、導入効果の分析、組織別の利用傾向把握に使われることが多い機能です。レポート取得が数日止まると、月次報告や利用促進施策の判断に影響します。単なるネットワーク設定変更として扱わず、データパイプラインの変更として検証するのが安全です。
まとめ：新ドメイン追加、ハードコード除去、取得監視をセットで進める
GitHub Copilot metricsの2026年4月更新で押さえるべき結論は明確です。2026年5月20日以降、Copilot usage metrics report download URLsは新しいGitHub管理ドメインへ移行します。ファイアウォールやプロキシの許可リストを使っている組織は、copilot-reports.github.comまたはcopilot-reports.*.ghe.comを事前に追加し、必要に応じてフォールバックURLも確認してください。
あわせて、取得ジョブやIaC内にazurefd.net前提のロジックがないかを検索し、APIが返すdownload_linksを柔軟に処理できる形へ直しましょう。最後に、API取得成功だけでなく、レポートファイルのダウンロード成功、保存件数、後続集計まで監視すれば、切り替え後のトラブルをかなり減らせます。
コメント