先に結論
Copilot usage metrics のレポート取得を止めたくないなら、新しい report domain を先に allowlist へ追加してください。
2026-05-20 から、GitHub Copilot usage metrics report の download URL は Azure Front Door ベースの copilot-reports-*.b01.azurefd.net ではなく、GitHub-owned domain を返すようになりました。
違いはシンプルです。
- GHEC は
copilot-reports.github.com - ghe.com は
copilot-reports.SUBDOMAIN.ghe.com - 移行期間中は legacy の Azure Front Door も残る
- まれに Azure Blob Storage へ fallback する場合もある
つまり今やるべきことは、モデル比較ではありません。firewall、proxy、取得バッチ、runbook の4点を一緒に更新することです。
何が変わったのか
GitHub は 2026-05-20 の changelog で、Copilot usage metrics report の download URL を GitHub-owned domain へ移したと案内しました。目的は URL の安定性を上げ、enterprise の allowlist 管理を簡単にするためです。
変更後の見方はこうです。
| 環境 | 新しい URL パターン | 以前の URL パターン |
|---|---|---|
| GitHub.com | https://copilot-reports.github.com/... | https://copilot-reports-*.b01.azurefd.net/... |
| ghe.com | https://copilot-reports.SUBDOMAIN.ghe.com/... | https://copilot-reports-*.b01.azurefd.net/... |
この変更は見た目より実務寄りです。Copilot usage metrics API は enterprise、organization の日次レポートと 28 日レポートの download link を返します。取得先ホストが変わるので、API 呼び出しが通っても、その先のレポート取得で落ちる 可能性があります。
まず誰が影響を受けるか
一番影響が大きいのは、次の3つです。
1. レポートを自動取得している platform、FinOps チーム
signed URL のホスト名を固定で見ているジョブは、更新していないと失敗しやすいです。日次取得や 28 日レポートを S3、BigQuery、社内 BI へ流しているなら、先に確認したほうが安全です。
2. firewall と proxy を厳しく管理している組織
GitHub の説明どおり、新しい report domain を通せないとレポート取得は詰まります。Copilot 導入時に github.com 本体だけ通して終わっている組織は、今回の変更を別件として扱う必要があります。
3. 社内 runbook を Azure Front Door 前提で書いている管理者
「この URL パターンが返る」という前提で監視、例外申請、障害切り分けを書いていると、現場の判断が古くなります。変更は small に見えても、運用文書は早めに直したほうが混乱しません。
allowlist はどこまで直すべきか
ここが一番迷いやすいところです。結論から言うと、必須と保険を分けて考える と整理しやすいです。
必須
GitHub の allowlist reference では、Copilot usage metrics report downloads 向けに次が案内されています。
- GHEC:
https://copilot-reports.github.com - ghe.com:
https://copilot-reports.SUBDOMAIN.ghe.com
この2つは、使っている環境に応じてまず追加候補です。
保険として残したいもの
GitHub は同じ allowlist reference と changelog で、次も案内しています。
https://copilot-reports-*.b01.azurefd.nethttps://usagereports*.blob.core.windows.net
前者は移行期間中の legacy download URL です。後者は、Azure Front Door が使えないまれなケースでの fallback 先です。
つまり、止めたくない運用なら新ドメインだけで終わらず、legacy と fallback をどこまで許可するかまで security と決める 必要があります。
既存自動化で見直したいポイント
変更後に詰まりやすいのは、単純な HTTP 通信より周辺の決め打ちです。
1. signed URL のホスト名チェック
ダウンロード先ホストを azurefd.net 前提で検証していると、新しい URL で落ちます。
2. 監視とアラートの文字列条件
ログ監視、失敗通知、WAF 例外の条件が旧 URL パターン前提なら、誤検知や見逃しが出ます。
3. runbook と障害一次切り分け
「レポート取得が失敗したら Azure Front Door を確認する」とだけ書いてある手順は古くなります。GHEC と ghe.com で見るべきホスト名も分けたほうが実務的です。
4. 許可範囲の説明
security 側に説明する時は、copilot-reports.github.com だけ追加して終わるのか、legacy と Azure Blob fallback も残すのかを分けて書いたほうが通りやすいです。
GHEC と ghe.com の違いはどう見るか
GHEC では、新しい安定先が copilot-reports.github.com です。
一方で ghe.com は、enterprise ごとの dedicated subdomain を含む copilot-reports.SUBDOMAIN.ghe.com を使います。
ここを曖昧にすると、GitHub.com 向けの説明をそのまま data residency 環境へ流用してしまい、allowlist が足りないまま残りやすいです。どの環境で Copilot usage metrics を取っているかを先に分ける のが安全です。
interaction data や enterprise 側の設定差分までまとめて見直したいなら、GitHub Copilotのinteraction data設定比較｜Pro / Business / Enterprise の違い もつながります。
いまの優先順位
優先順位はこの順で十分です。
- 新しい report domain を allowlist に追加する
- レポート取得バッチのホスト名前提を確認する
- legacy Azure Front Door と Azure Blob fallback をどこまで許可するか決める
- runbook、監視、社内説明を更新する
Copilot の管理全体を見直したい場合は、GitHub Copilot Business / Enterprise のモデル承認ガイド や GitHub Copilot Cloud Agent rollout guide｜custom properties で段階導入する方法 も合わせて読むと、統制まわりの設計がつながりやすいです。
まとめ
今回の変更は、URL 文字列の差し替えで終わる話ではありません。
Copilot usage metrics API を使っている組織では、新しい report domain を通すこと と 古い Azure Front Door 前提の運用を片づけること がセットです。
特に、レポート取得を自動化しているなら、API レスポンスの signed URL がどのホストを返しても止まりにくい形へ直しておく価値があります。GitHub は URL 安定化を狙って今回の変更を入れました。利用者側も、それに合わせて allowlist と自動化の前提を更新しておくのが自然です。