GitHub Copilotの利用状況をAPIで確認している管理者にとって、「AI credits consumed per user now in the Copilot usage metrics API」は、ユーザーごとのAIクレジット消費量を把握しやすくする更新です。結論から言うと、Copilot usage metrics APIのユーザー単位レポートにai_credits_usedという項目が追加され、日別または直近28日分のユーザー別AIクレジット使用量を確認できるようになりました。ただし、この値は請求金額そのものではなく、ユーザーごとの消費傾向を見るためのメトリックです。導入前に、権限、APIの対象範囲、レポートの種類、請求データとの違いを整理しておくことが重要です。(The GitHub Blog)
AI credits consumed per user now in the Copilot usage metrics APIとは
「AI credits consumed per user now in the Copilot usage metrics API」は、GitHub Copilotの利用状況を取得するCopilot usage metrics APIに、ユーザーごとのAIクレジット消費量を示すai_credits_usedフィールドが追加されたという更新です。
GitHub Changelogでは、Copilot usage metrics APIが、usage-based billing APIで使われるAIクレジット消費データと同じ元データをもとに、各ユーザーが1日ごとに消費したAIクレジット数をレポートできるようになったと説明されています。(The GitHub Blog)
この変更で分かるようになるのは、たとえば次のようなことです。
- Copilotをよく使っているユーザーが、どれくらいAIクレジットを消費しているか
- チームや組織内でAIクレジット消費が偏っていないか
- Copilotの活用度とAIクレジット消費量のバランスが取れているか
- 利用ベース課金を見据えて、日別の消費傾向を確認できるか
一方で、ai_credits_usedだけを見て「このユーザーにいくら請求される」と判断するのは避けるべきです。公式情報では、このフィールドはユーザー単位の全体的な消費量であり、機能別、モデル別、利用画面別には分解されず、請求額そのものではないとされています。(The GitHub Blog)
今回追加されたai_credits_usedで何が変わるのか
従来のCopilot usage metricsは、アクティブユーザー数、コード補完、チャット利用、IDEや言語ごとの利用傾向など、主に「どれくらい使われているか」を見るための情報が中心でした。GitHub Docsでも、Copilot usage metricsはダッシュボードとAPIで、採用状況、使用状況、コード生成アクティビティを表す共通フィールドを提供すると説明されています。(GitHub Docs)
今回の更新では、そこに「AIクレジットをどれくらい消費したか」というコスト管理に近い観点が加わりました。
| 確認したいこと | これまでの主な見方 | 今回の更新後に見やすくなること |
|---|---|---|
| Copilotが使われているか | アクティブユーザー数、利用機能、コード補完数 | 利用量に加えてAIクレジット消費量も確認できる |
| ユーザーごとの利用差 | user_login、used_chat、used_agentなど | ユーザーごとのai_credits_usedで消費量の偏りを見られる |
| 予算管理 | Billing画面、usage-based billing API | 利用メトリック側でも日別・ユーザー別の消費傾向を追いやすい |
| チーム別分析 | user-teams reportとユーザー別レポートを結合 | チーム別のAIクレジット消費傾向を推定しやすい |
ポイントは、利用実態とAIクレジット消費量を同じ分析軸で見やすくなることです。たとえば、あるユーザーのAIクレジット消費が多い場合でも、コード生成、チャット、エージェント利用などの活動量が高ければ、単なる「使いすぎ」ではなく「高度に活用している」と判断できる可能性があります。
対象になるレポートはユーザー単位の1日・28日レポート
ai_credits_usedが追加されるのは、Copilot usage metrics APIのユーザー単位レポートです。公式Changelogでは、enterpriseレベルとorganizationレベルの両方で、users-1-dayとusers-28-dayのユーザー単位レポートに対応すると説明されています。(The GitHub Blog)
整理すると、主に見るべきAPIは次の4種類です。
| スコープ | レポート | 用途 | 迷いやすいポイント |
|---|---|---|---|
| Enterprise | users-1-day | 指定日のユーザー別消費を見る | day=YYYY-MM-DDの指定が必要 |
| Enterprise | users-28-day | 直近28日分のユーザー別傾向を見る | 最新の28日レポートを取得する形式 |
| Organization | users-1-day | 組織単位で指定日のユーザー別消費を見る | org名の指定が必要 |
| Organization | users-28-day | 組織単位で直近28日分を見る | 組織単位の権限が必要 |
GitHub Docsでは、Copilot usage metrics APIのレポートはenterprise、organization、個別ユーザーレベルなどスコープや粒度によって返る形が異なり、ユーザー単位レポートにはuser_id、user_login、used_*系の指標などが含まれると説明されています。(GitHub Docs)
設定場所で迷いやすいポイント
この更新は、Copilotの画面に新しいボタンが増えるタイプの変更ではありません。主にAPIで取得できるレポート項目が増える変更です。
そのため、「どこで設定するのか」と迷った場合は、次のように切り分けると分かりやすくなります。
| やりたいこと | 見る場所・操作場所 | 補足 |
|---|---|---|
| APIでユーザー別AIクレジット消費を取得したい | Copilot usage metrics API | users-1-dayまたはusers-28-dayを使う |
| Copilot usage metrics API自体を使えるようにしたい | EnterpriseのCopilot usage metricsポリシー | API利用にはポリシーが有効になっている必要がある |
| 画面でAIクレジット消費を確認したい | Billing and licensing > AI usage | モデル別やコスト確認に向いている |
| 予算超過を防ぎたい | Billing and licensingのBudget関連設定 | APIのメトリック確認だけでは利用停止はできない |
| チーム別に分析したい | user-teams reportとユーザー別レポートを結合 | チーム別集計は自分で作る必要がある |
特に間違いやすいのは、Copilot usage metrics APIのai_credits_usedは、設定画面でオンにする新機能ではなく、既存APIのユーザー単位レポートに追加される項目という点です。
GitHub Docsでは、Copilot usage metrics APIを有効にするには、enterprise全体で「Copilot usage metrics」ポリシーをEnabledにする必要があると説明されています。(GitHub Docs)
導入前に確認したい前提条件
ai_credits_usedを使う前に、次の前提条件を確認しておきましょう。ここを飛ばすと、APIを実行しても403 Forbiddenや404 Resource not foundで止まりやすくなります。
| 確認項目 | 内容 | 失敗しやすい例 |
|---|---|---|
| 対象プラン | GitHub Copilot BusinessまたはGitHub Copilot Enterpriseの管理利用が前提 | 個人利用のCopilotだけで企業全体のAPI分析をしようとする |
| 権限 | Enterprise owner、Organization owner、Billing manager、または必要なCopilot Metrics権限 | 一般メンバーのトークンでAPIを叩く |
| ポリシー | Copilot usage metricsが有効になっていること | APIドキュメント通りに実行しても権限エラーになる |
| APIトークン | 必要なscopeまたはfine-grained permissionを付与 | read:orgやCopilot metrics権限が不足している |
| レポート種別 | 1日レポートか28日レポートかを選ぶ | 指定日が必要なAPIでdayを付け忘れる |
| データの使い方 | 請求額ではなく利用メトリックとして扱う | ai_credits_usedをそのまま請求明細として扱う |
Enterprise向けユーザー別レポートでは、Enterprise owners、billing managers、またはfine-grainedの「View Enterprise Copilot Metrics」権限を持つユーザーが取得でき、classic tokenではmanage_billing:copilotまたはread:enterpriseスコープが必要とされています。Organization向けユーザー別レポートでは、Organization ownersまたは「View Organization Copilot Metrics」権限を持つユーザーが対象で、classic tokenではread:orgスコープが必要です。(GitHub Docs)
Copilot usage metrics APIでの基本的な使い方
Copilot usage metrics APIは、直接レポート本文を返すというより、レポートファイルをダウンロードするためのリンクを返す形式です。GitHub Docsでは、レポートは日次で生成され、期限付きの署名付きURLとしてダウンロードリンクが返ると説明されています。(GitHub Docs)
Enterprise単位で指定日のユーザー別レポートを取得する
指定日1日分のユーザー別AIクレジット消費を見たい場合は、Enterpriseスコープのusers-1-dayを使います。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=2026-06-20"ENTERPRISEには、Enterprise名のslugを入れます。dayはYYYY-MM-DD形式です。GitHub Docsのサンプルでも、Enterpriseの指定日ユーザー別レポートは/enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=DAYの形式で示されています。(GitHub Docs)
レスポンスには、次のようなdownload_linksが返ります。
{
"download_links": [
"https://example.com/copilot-usage-report-1.ndjson"
],
"report_day": "2026-06-20"
}実際の分析では、このdownload_linksのURLからNDJSON形式のレポートをダウンロードし、各レコードのuser_loginやai_credits_usedを確認します。
Enterprise単位で直近28日分を見る
日別ではなく、直近28日分の傾向を見たい場合は、users-28-day/latestを使います。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest"GitHub Docsでは、Enterpriseの28日ユーザー別レポートは、直近28日分のユーザー別利用状況、エンゲージメント、機能利用パターンを確認するためのレポートと説明されています。(GitHub Docs)
Organization単位で指定日のユーザー別レポートを取得する
組織単位で見たい場合は、/orgs/{org}/...を使います。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/ORG/copilot/metrics/reports/users-1-day?day=2026-06-20"ORGにはOrganization名を入れます。Organization名は大文字・小文字を区別しないとされています。Organizationの指定日ユーザー別レポートも、dayパラメーターが必須です。(GitHub Docs)
Organization単位で直近28日分を見る
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/orgs/ORG/copilot/metrics/reports/users-28-day/latest"組織ごとにCopilotの利用傾向を見たい場合は、Enterprise全体よりもこちらの方が現場の分析に向いています。たとえば、開発部門、データ分析部門、プラットフォームチームなど、Organization単位でCopilotの使い方が分かれている企業では、Organization単位のレポートから始めると整理しやすくなります。
ai_credits_usedを見るときの判断基準
ai_credits_usedは、単に数値が大きいか小さいかだけで判断すると誤解しやすい項目です。見るべきポイントは、消費量と成果・活動量のバランスです。
| 見え方 | すぐに判断しない方がよい理由 | 確認したい追加情報 |
|---|---|---|
あるユーザーのai_credits_usedが高い | 高度なモデルやエージェント機能を使っている可能性がある | used_agent、チャット利用、コード生成量、担当業務 |
| 消費量が低い | Copilotを使えていない、または業務上使う機会が少ない可能性がある | アクティブ状況、ライセンス付与日、利用研修の有無 |
| チーム内で差が大きい | ロールや担当領域の違いが反映されている可能性がある | チーム構成、プロジェクト種別、モデル利用傾向 |
| 消費量が急増した | 短期の開発集中、PoC、エージェント利用増加が原因かもしれない | 日別推移、利用機能、予算設定 |
実務では、次のような基準で見ると判断しやすくなります。
まず、ai_credits_usedが高いユーザーを「問題」と決めつけないことです。Copilotを使って設計、コードレビュー、テスト生成、移行作業などを集中的に進めているユーザーは、AIクレジット消費が増えやすくなります。むしろ成果につながっている可能性があります。
次に、ai_credits_usedが低いユーザーも「節約できている」とは限りません。ライセンスを付与しているのに利用が少ない場合、オンボーディング不足、IDE拡張の未設定、社内ルールへの不安、使いどころが分からないといった課題が隠れていることがあります。
最後に、部署別・チーム別に見る場合は、user-teams reportとの結合が必要です。GitHub Docsでは、チームレベルのメトリックは事前集計されておらず、user-teams reportとユーザー単位の使用状況レポートを結合して作成すると説明されています。(GitHub Docs)
請求データとの違いに注意する
今回の更新で最も迷いやすいのが、ai_credits_usedと請求データの関係です。
ai_credits_usedは、ユーザーごとのCopilot利用メトリックに追加される項目です。請求額やインボイスを確定するための値として扱うものではありません。公式Changelogでも、ai_credits_usedは利用状況分析のためのメトリックであり、請求合計ではないため、請求確認にはBillingを参照するよう説明されています。(The GitHub Blog)
請求やコスト管理をしたい場合は、GitHub.comのBilling and licensing設定にあるAI usageやMetered usageを併せて確認します。GitHub Docsでは、AI usage画面でプランに含まれるクレジットの使用量、追加利用分、モデル別の消費クレジットやコスト内訳を確認できると説明されています。(GitHub Docs)
| 目的 | 見るべき場所 | 理由 |
|---|---|---|
| ユーザーごとの利用傾向を分析 | Copilot usage metrics APIのai_credits_used | ユーザー単位で利用状況と消費量を並べて見られる |
| 請求額を確認 | Billing and licensing、AI usage、請求関連API | 実際の課金・請求確認に向いている |
| 予算超過を防止 | Budgets、spending limits | 上限設定や通知・停止制御ができる |
| チーム別に活用状況を見る | user-teams reportとユーザー別レポートを結合 | チーム単位の独自集計が必要 |
予算管理で使う場合の注意点
ai_credits_usedは、予算管理の早期検知に役立ちます。ただし、これだけで利用を止めたり、課金を制御したりするものではありません。
GitHub Docsでは、CopilotライセンスにはAI creditsが含まれ、Enterprise内でプールされ、プールを使い切った後の追加利用は予算管理の対象になると説明されています。また、ユーザー、コストセンター、Enterpriseレベルで予算を設定でき、上限到達時に利用を止めるには「Stop usage when budget limit is reached」を有効にする必要があるとされています。(GitHub Docs)
実務では、次のような使い分けが有効です。
| シーン | APIで見ること | 設定で対応すること |
|---|---|---|
| 特定ユーザーの消費が急増 | ai_credits_usedの日別推移を確認 | 必要に応じてユーザー単位の予算を設定 |
| 部署ごとのコストを見たい | user-teams reportやOrganization単位で集計 | コストセンターを作成して予算管理 |
| 追加課金を防ぎたい | 消費傾向を定期的に監視 | spending limitで停止設定を有効化 |
| PoC期間中だけ制限したい | 対象ユーザーの消費を日別に見る | PoC用のコストセンターや予算を設定 |
よくある失敗と対処法
APIを実行しても403になる
403が返る場合は、まず権限不足を疑います。一般ユーザーのトークンでは、組織やEnterprise全体のCopilot利用メトリックは取得できません。
確認するポイントは次の通りです。
- Enterprise owner、Organization owner、Billing managerなど必要な権限があるか
- fine-grained tokenにCopilot Metricsのread権限があるか
- classic tokenに必要なscopeがあるか
- Copilot usage metricsポリシーが有効になっているか
特に、Organizationレベルではread:orgが必要になるケースがあります。Enterpriseレベルではmanage_billing:copilotまたはread:enterpriseが必要になるケースがあります。(GitHub Docs)
ai_credits_usedが機能別に分かれていると思ってしまう
ai_credits_usedは、ユーザーのCopilot活動全体に対する合計値です。公式Changelogでは、機能別、モデル別、surface別には現在分解されていないと説明されています。(The GitHub Blog)
そのため、次のような分析はai_credits_usedだけではできません。
- チャットだけで何AIクレジット使ったか
- 特定モデルだけで何AIクレジット使ったか
- VS CodeとJetBrainsで消費量を分ける
- agent modeだけのAIクレジット消費を出す
モデル別やコスト内訳を確認したい場合は、Billing and licensingのAI usageなど、請求・利用ベースの画面と併用する必要があります。
請求額と数値が合わないと判断してしまう
ai_credits_usedは請求確定値ではありません。請求確認にはBilling側の情報を使います。
Copilot usage metricsは利用状況の分析、Billingは請求・コスト確認、Budgetsは支出制御というように、目的別に見る場所を分けましょう。
1日レポートと28日レポートを混同する
指定日の状況を見たい場合はusers-1-day、傾向を見たい場合はusers-28-day/latestです。
たとえば「昨日、急にAIクレジット消費が増えた原因を見たい」ならusers-1-dayが向いています。一方で「今月の導入状況を大まかに見たい」「オンボーディング後に利用が増えているか確認したい」ならusers-28-day/latestの方が向いています。
チーム別に自動で出ると思ってしまう
チーム別メトリックは自動で完成した形では返りません。GitHub Docsでは、チームレベルの指標はuser-teams reportとユーザー別使用状況レポートを結合して作成すると説明されています。(GitHub Docs)
たとえば、次のような流れになります。
| 手順 | やること |
|---|---|
| 1 | users-1-dayまたはusers-28-dayでユーザー別レポートを取得 |
| 2 | user-teams-1-dayでユーザーとチームの対応表を取得 |
| 3 | user_idまたはuser_loginで結合 |
| 4 | チーム単位でai_credits_usedを合計または平均 |
| 5 | アクティブユーザー数や利用機能とあわせて分析 |
管理者が最初に作るべき確認レポート
導入直後は、複雑なダッシュボードを作るよりも、まずは次の項目を並べたシンプルな表を作るのがおすすめです。
| 項目 | 見る理由 |
|---|---|
user_login | 誰の利用かを確認する |
day | いつの利用かを確認する |
ai_credits_used | AIクレジット消費量を見る |
used_chat | チャット利用の有無を見る |
used_agent | エージェント利用の有無を見る |
used_cli | CLI利用の有無を見る |
| コード生成関連の指標 | 消費量と開発活動の関係を見る |
| 所属チーム | 部署・プロジェクト別に見る |
この表を作ると、次のような判断がしやすくなります。
「AIクレジット消費が多いが、エージェントを使って大量のコード修正をしている」
「ライセンスはあるが、used_chatもused_agentもfalseで利用が進んでいない」
「特定チームだけ消費が多く、PoCや移行作業の影響が出ている」
「消費量は増えているが、アクティブユーザーも増えているため、導入は進んでいる」
重要なのは、AIクレジット消費量だけを単独で評価しないことです。利用目的、担当業務、成果、ライセンス状況とセットで見ると、管理の質が上がります。
一般ユーザー向けにはどう説明すればよいか
管理者がai_credits_usedを使い始めると、ユーザー側から「自分の利用が監視されるのか」「使うと怒られるのか」と不安が出ることがあります。
社内向けには、次のように説明すると誤解を避けやすくなります。
Copilotの利用状況とAIクレジット消費量を、組織全体の予算管理と活用促進のために確認します。個人を責めるためではなく、利用が多い場面・少ない場面を把握し、必要な支援や予算設定を行うためのものです。
また、ユーザーに伝えるべきポイントは次の3つです。
- AIクレジット消費量が多いこと自体は悪いことではない
- 利用が少ない場合は、使い方の支援や設定確認の対象になることがある
- 予算や利用ルールがある場合は、事前に社内基準を明示する
こうした説明をせずに数値だけを共有すると、「Copilotを使わない方が安全」と受け取られ、導入効果が下がる可能性があります。
実務でおすすめの運用手順
最初から全社のAIクレジット消費を細かく管理しようとすると、運用が重くなります。まずは次の順序で進めると現実的です。
| フェーズ | やること | 判断ポイント |
|---|---|---|
| 初期確認 | Organization単位でusers-28-day/latestを取得 | 利用者と未利用者を把握 |
| 日次確認 | users-1-dayで急増日を確認 | 特定ユーザー・特定日だけ突出していないか |
| チーム分析 | user-teams reportと結合 | チーム別の消費傾向を見る |
| 予算設計 | Billing and licensing、Budgetsを確認 | 追加課金や上限設定の必要性を判断 |
| 定着支援 | 利用が少ないユーザーへ案内 | 研修、設定確認、ユースケース共有を行う |
特に導入初期は、「消費量を抑える」よりも「価値につながる使い方ができているか」を見る方が重要です。Copilotの活用が進むとAIクレジット消費は増える可能性がありますが、それが開発効率化、レビュー支援、テスト作成、移行作業の短縮につながっていれば、単純なコスト増とは言い切れません。
まとめ：ai_credits_usedは請求確認ではなく活用状況の見える化に使う
AI credits consumed per user now in the Copilot usage metrics APIは、GitHub Copilotの管理者にとって、ユーザーごとのAIクレジット消費を把握しやすくする重要な更新です。
使い方の要点は次の通りです。
- 追加された項目は
ai_credits_used - 対象はユーザー単位の
users-1-dayとusers-28-dayレポート - EnterpriseレベルとOrganizationレベルの両方で利用できる
- 値はユーザー全体のAIクレジット消費量であり、機能別・モデル別には分かれない
- 請求額そのものではないため、請求確認はBilling側を見る
- 予算管理にはBudgetsやspending limitの設定も併用する
- チーム別分析にはuser-teams reportとの結合が必要
次に行うべきことは、まず自社の権限とCopilot usage metricsポリシーを確認し、Organization単位のusers-28-day/latestから取得を試すことです。その後、user_login、day、ai_credits_used、used_chat、used_agentを並べた簡単な一覧を作ると、Copilotの利用状況とAIクレジット消費の関係を実務で判断しやすくなります。
コメント