2026年6月20時点で確認したいポイントは、「Copilot usage metrics APIで、ユーザーごとのAI credits消費量を見られるようになった」という変更です。具体的には、ユーザー単位のレポートにai_credits_usedというフィールドが追加され、EnterpriseまたはOrganizationの管理者が、ユーザー別のCopilot利用状況とAI credits消費量をあわせて分析しやすくなりました。ただし、この値は請求金額そのものではなく、機能別・モデル別・利用画面別の内訳でもありません。利用分析や予算見通しの材料として使うのが正しい理解です。(The GitHub Blog)
AI credits consumed per user now in the Copilot usage metrics API のよくある疑問を整理
GitHub Changelogで公開された「AI credits consumed per user now in the Copilot usage metrics API」は、Copilotを組織で管理している管理者向けの変更です。公式ソース上の分類は「Release」で、GitHub Changelog上では2026年6月19日公開として掲載されています。日本時間で情報を確認している場合、2026年6月20日前後の更新情報として目にするケースがあります。(The GitHub Blog)
この変更で重要なのは、Copilotの利用状況を「使った・使っていない」だけでなく、「どのユーザーがどの程度AI creditsを消費しているか」という観点で追えるようになった点です。開発部門、情報システム部門、Platform Engineeringチーム、FinOps担当者にとっては、Copilotの活用状況とコスト傾向を結びつけて確認しやすくなります。
今回追加されたものは何ですか？
追加されたのは、Copilot usage metrics APIのユーザー単位レポートに含まれるai_credits_usedフィールドです。
ai_credits_usedは、対象期間内に各ユーザーが消費したAI creditsの合計を示します。GitHubの説明では、同じAI credits消費データに基づく情報がCopilot usage metrics APIにも反映されるようになった、という位置づけです。(The GitHub Blog)
| 項目 | 内容 |
|---|---|
| 追加フィールド | ai_credits_used |
| 見られる単位 | ユーザーごと |
| 対象レポート | users-1-day、users-28-day |
| 対象スコープ | Enterprise、Organization |
| 主な用途 | 利用状況分析、採用状況の把握、予算見通し |
| 注意点 | 請求額そのものではなく、機能別・モデル別・画面別の内訳ではない |
たとえば、「AさんはCopilotをよく使っているが、AI creditsの消費も高い」「Bチームは利用者数は多いが、1人あたりの消費は安定している」といった見方がしやすくなります。
どのAPIレポートで確認できますか？
ai_credits_usedは、ユーザー単位のCopilot usage metricsレポートで確認します。GitHub Changelogでは、単日レポートのusers-1-dayと、28日間レポートのusers-28-dayの両方で利用できると説明されています。(The GitHub Blog)
GitHub Docs上でも、ユーザー単位レポートにはuser_id、user_login、ai_credits_used、used_*系の利用指標、ai_adoption_phaseなどが含まれると説明されています。(GitHub Docs)
| 確認したいこと | 使うレポートの考え方 |
|---|---|
| 特定日のユーザー別消費量を見たい | users-1-day |
| 直近28日間の傾向を見たい | users-28-day |
| Enterprise全体で見たい | Enterpriseスコープのユーザーレポート |
| Organization単位で見たい | Organizationスコープのユーザーレポート |
| チーム別に集計したい | ユーザー単位レポートとuser-teamsレポートを結合する |
実務では、まず28日間レポートで大きな傾向を見て、気になるユーザーやチームがあれば単日レポートで日別の増減を確認する流れが扱いやすいです。
誰が対象になりますか？
主な対象は、GitHub CopilotをEnterpriseまたはOrganizationで管理している人です。GitHub Docsでは、Copilot usage metricsを利用できる人として、Enterprise owners、organization administrators、billing managers、または「View Enterprise Copilot Metrics」権限を持つEnterprise custom roleのユーザーが挙げられています。(GitHub Docs)
| 立場 | 何に使えるか |
|---|---|
| Enterprise管理者 | 全体のCopilot利用とAI credits消費の傾向確認 |
| Organization管理者 | 自組織内のユーザー別利用状況の確認 |
| Billing manager | 予算見通し、利用増加の早期把握 |
| 開発組織のマネージャー | 利用定着、オンボーディング対象の発見 |
| Platform Engineering / DevEx担当 | Copilot導入効果と利用実態の分析 |
一方で、個人利用のCopilotユーザーが、自分のGitHub画面でこのフィールドを直接確認するための変更ではありません。管理者がAPIやエクスポートデータを使って、組織全体の利用状況を分析するための機能と考えると分かりやすいです。
ai_credits_usedは請求額ですか？
いいえ。ai_credits_usedは請求額そのものではありません。
GitHub Changelogでは、このフィールドは利用分析のためのメトリクスであり、請求書作成や実際の請求確認にはbilling側を参照するよう説明されています。また、GitHub Docsでもai_credits_usedは「consumption analysis」のための値であり、invoicing totalsではないと説明されています。(The GitHub Blog)
実務では、次のように使い分けるのが安全です。
| 用途 | 参照するもの |
|---|---|
| ユーザー別にどれくらいAI creditsを使っているか知りたい | Copilot usage metrics APIのai_credits_used |
| 実際に請求対象となる利用量を確認したい | Billing APIまたは請求画面 |
| モデル別・製品別・日付別の請求寄りの分析をしたい | Billing usage系のAPI |
| Copilotの定着度や利用パターンを見たい | Copilot usage metrics API |
Billing usage APIには、AI credit usage reportを取得するエンドポイントがあり、年・月・日、ユーザー、モデル、製品などの条件で絞り込める項目が用意されています。組織やEnterpriseで課金・請求の正確な確認をする場合は、usage metricsではなくbilling側のデータと照合するのが基本です。(GitHub Docs)
機能別・モデル別にAI creditsを分解できますか？
現時点の公式説明では、ai_credits_usedはユーザーごとの総量です。機能別、モデル別、surface別には分解されません。(The GitHub Blog)
ここは誤解しやすいポイントです。たとえば、あるユーザーのai_credits_usedが高かったとしても、それだけでは次のような内訳は分かりません。
| 分からない内訳 | 理由 |
|---|---|
| Chatで多く使ったのか | ai_credits_usedは機能別に分解されない |
| Agent利用が多かったのか | field単体では判断できない |
| どのモデルで消費したのか | モデル別内訳ではない |
| VS Code、JetBrains、GitHub.comなど、どの画面で使ったのか | surface別ではない |
ただし、Copilot usage metrics APIには、ユーザーの利用有無や機能別・言語別・IDE別のメトリクスも含まれます。ai_credits_usedだけを見るのではなく、used_agent、used_chat、used_cli、totals_by_feature、totals_by_ideなどの周辺指標とあわせて見ることで、「消費が増えた背景」を推測しやすくなります。(GitHub Docs)
使えない時、見えない時に最初に確認すること
ai_credits_usedが見えない、APIで期待したデータが返らない、ユーザーが欠けているように見える場合は、いきなり不具合と判断せず、権限・レポート種類・データ処理タイミングを順番に確認します。
| 症状 | 確認する観点 |
|---|---|
| APIが403になる | 管理者権限、Copilot metrics閲覧権限、トークンの権限不足 |
| APIが404になる | Enterprise名・Organization名・エンドポイントの指定ミス |
ai_credits_usedがない | ユーザー単位レポートではなく集約レポートを見ていないか |
| 最近の日付の値が低い | テレメトリ処理が完了していない可能性 |
| 特定ユーザーの詳細が出ない | IDEのテレメトリ設定や利用実績を確認 |
| 請求額と一致しない | usage metricsは請求額ではないためbilling側と照合 |
GitHub Docsでは、Copilot usage metricsのAPIを有効にするには、Enterprise全体で「Copilot usage metrics」ポリシーがEnabledになっている必要があると説明されています。また、Enterprise向けのユーザー単位レポートでは、Enterprise owners、billing managers、または適切な細かな権限を持つユーザーが取得でき、classic personal access tokenではmanage_billing:copilotまたはread:enterpriseスコープが必要とされています。(GitHub Docs)
Organization向けのユーザー単位レポートでは、Organization ownersまたは「View Organization Copilot Metrics」権限を持つユーザーが対象で、classic personal access tokenではread:orgスコープが必要です。(GitHub Docs)
「データが少ない」「昨日の値がおかしい」と感じる時の見方
Copilot usage metricsは、ダッシュボード、API、エクスポートで同じ基礎テレメトリを使いますが、集計方法や表示タイミングが異なるため、完全に同じ数字に見えないことがあります。GitHub Docsでも、ダッシュボード・API・レポート間では、時間窓、スコープ、データ鮮度の違いによって差異が出る場合があると説明されています。(GitHub Docs)
特に注意したいのは、直近日のデータです。GitHub Docsでは、IDEテレメトリは非同期で処理されるため、最近の日付のデータが不完全または欠落して見える場合があり、通常は3つの完全なUTC日以内に確定すると説明されています。(GitHub Docs)
そのため、社内レポートに使う場合は、次のような運用にすると安全です。
| レポート用途 | 推奨する集計タイミング |
|---|---|
| 日次の速報確認 | 直近値は暫定として扱う |
| 週次レポート | 3日以上前までのデータで集計する |
| 月次の管理会議 | Billingデータと照合してから使う |
| 異常検知 | 1日だけで判断せず、数日間の傾向を見る |
「昨日だけ急にAI creditsが減った」「特定の日だけDAUが落ちた」という場合は、障害や設定変更の前に、データ確定待ちの可能性を確認しましょう。
ユーザー単位のAI creditsをどう活用すべきですか？
ai_credits_usedは、単に「使いすぎユーザーを探す」ためだけに使うと、導入効果を見誤ります。Copilotは開発作業の文脈で使われるため、消費量の多さだけで良し悪しを判断するのではなく、成果や利用定着とセットで見ることが重要です。
おすすめは、次の3つの視点で見ることです。
| 視点 | 見るべきポイント | 次のアクション |
|---|---|---|
| 定着 | 継続的に利用しているユーザーが増えているか | 利用が少ないチームにオンボーディングを行う |
| 効率 | AI credits消費に対して、コード生成・受け入れ・Agent利用が伴っているか | 使い方のベストプラクティスを共有する |
| 予算 | 特定チームや期間で消費が急増していないか | 予算アラートや利用ルールを見直す |
たとえば、ai_credits_usedが高く、used_agentやused_chatも活発なユーザーは、Copilotを高度に使い込んでいる可能性があります。逆に、AI credits消費は増えているのに成果指標や受け入れ指標が伸びていない場合は、プロンプトの書き方、モデル選択、Agentの使いどころなどを見直す余地があります。
管理者が社内で説明する時の言い方
社内向けには、次のように説明すると誤解を減らせます。
| 誤解されやすい説明 | 適切な説明 |
|---|---|
| 「ユーザーごとの請求額が見えるようになった」 | 「ユーザーごとのAI credits消費量を利用分析用に見られるようになった」 |
| 「どの機能で消費したか分かる」 | 「総量は分かるが、機能別・モデル別の内訳ではない」 |
| 「昨日の数字で即判断できる」 | 「直近データは処理遅延の可能性があるため、確定を待って見る」 |
| 「消費が多い人は問題」 | 「消費量と利用成果をあわせて判断する」 |
特にFinOpsや経理部門へ共有する場合は、ai_credits_usedを請求明細の代替として扱わないように明記しておくと安全です。利用傾向を見るためのメトリクスと、請求確認のためのBillingデータは役割が違います。
確認手順の実務フロー
実際に確認する時は、次の順番で進めると抜け漏れを減らせます。
| 手順 | やること | 確認ポイント |
|---|---|---|
| 1 | Copilot usage metricsのポリシーを確認 | Enterprise全体でEnabledか |
| 2 | APIを呼び出す権限を確認 | EnterpriseまたはOrganizationの権限、token scope |
| 3 | レポート種類を選ぶ | users-1-dayかusers-28-day |
| 4 | ai_credits_usedを取得 | ユーザー単位レポートに含まれているか |
| 5 | 周辺指標と組み合わせる | used_chat、used_agent、コード生成・受け入れ指標など |
| 6 | Billingデータと役割を分ける | 請求確認にはbilling側を使う |
| 7 | 社内レポート化する | 直近データは確定待ちを考慮する |
APIのレスポンスはダウンロードリンクを返す形式のため、BIツールやデータ基盤に取り込む場合は、レポートファイルの取得、NDJSONのパース、ユーザー・チーム情報との結合、集計期間の統一までを一連の処理として設計すると運用しやすくなります。GitHub Docsでは、レポートが日次で生成され、期限付きの署名付きURLでダウンロードリンクが提供されると説明されています。(GitHub Docs)
よくある質問
個人のCopilot利用者もこの情報を見られますか？
基本的には、組織やEnterpriseでCopilotを管理する管理者向けの情報です。ユーザー本人が通常のGitHub画面でこのAPIフィールドを直接確認するための変更ではありません。
Copilot Freeや個人プランの利用量も対象ですか？
組織やEnterpriseで管理・課金されるCopilot利用を管理者が分析する文脈の機能です。個人で購入したCopilotの請求利用量を確認する場合は、個人向け・billing側の確認方法と切り分けて考える必要があります。GitHub Docsでも、個人アカウントに直接課金される利用と、OrganizationまたはEnterpriseで管理・課金される利用は参照するエンドポイントが異なると説明されています。(GitHub Docs)
チーム単位でAI creditsを集計できますか？
直接のチーム別集計フィールドが用意されているというより、ユーザー単位レポートとuser-teamsレポートを結合してチーム別の指標を作る考え方です。GitHub Docsでも、チームレベルのメトリクスは事前集計されず、user-teamsレポートとユーザー単位レポートを結合して構築すると説明されています。(GitHub Docs)
ai_credits_usedが0のユーザーはCopilotを使っていないという意味ですか？
必ずしも即断は避けるべきです。対象期間、レポートのスコープ、データ処理タイミング、IDEテレメトリ設定、利用したCopilot機能の種類を確認してください。特に直近日付では、テレメトリ処理の遅延で値が低く見える可能性があります。(GitHub Docs)
ダッシュボードの数値とAPIの数値が合わないのは不具合ですか？
必ずしも不具合ではありません。ダッシュボード、API、エクスポートは同じ基礎データを使いますが、集計の時間窓やスコープ、データ鮮度が異なるため差が出る場合があります。比較する時は、対象期間、UTC基準の日付、Organization/Enterpriseのスコープをそろえることが重要です。(GitHub Docs)
まとめ：ai_credits_usedはCopilot活用と予算管理をつなぐ指標
今回の変更で、Copilot usage metrics APIからユーザーごとのAI credits消費量を確認しやすくなりました。管理者は、ai_credits_usedを使うことで、Copilotの活用状況、チームごとの定着度、予算の見通しをより具体的に把握できます。
一方で、ai_credits_usedは請求額そのものではなく、機能別・モデル別・surface別の内訳でもありません。実務では、ユーザー単位の利用分析にはCopilot usage metrics API、請求や費用確定にはBillingデータ、チーム別分析にはuser-teamsレポートとの結合、というように役割を分けて使うのが安全です。
まずは、管理者権限とCopilot usage metricsポリシーを確認し、users-28-dayで全体傾向を把握しましょう。そのうえで、特定ユーザーやチームの急増・低利用をusers-1-dayで掘り下げると、Copilotの活用改善とコスト管理の両方に役立てられます。
コメント