GitHub Copilotの「AI credits consumed per user now in the Copilot usage metrics API」は、Copilotの終了やAPI廃止ではありません。2026年6月20日時点で押さえるべき結論は、Copilot usage metrics APIにユーザー別のai_credits_usedが追加され、管理者が「誰がどれだけAI creditsを消費しているか」を使用状況レポート内で確認しやすくなった、という点です。
ただし、単なる項目追加として見過ごすのは危険です。GitHub Copilotは2026年6月1日からAI creditsベースの従量課金へ移行しており、今回のAPI更新は、予算管理・利用分析・請求照合の実務に直結します。GitHub Changelog上の分類は「Release」であり、明示的な廃止期限や非推奨期限の告知ではありませんが、API連携やダッシュボードを運用している企業は早めに取り込みロジックを確認すべき変更です。(The GitHub Blog)
なお、この記事で扱うCopilotは、GitHub Copilotを指します。
AI credits consumed per user now in the Copilot usage metrics API の期限・移行対応で見落としやすい点
今回の変更で最も重要なのは、「課金額そのものがAPIでユーザー別に確定表示されるようになった」と誤解しないことです。
ai_credits_usedは、ユーザー別のCopilot利用状況を分析するためのメトリックです。GitHub Changelogでは、同フィールドはユーザー別レポートに追加され、ユーザーが消費したAI creditsの合計を示すものと説明されています。一方で、機能別・モデル別・利用画面別には分解されず、請求額そのものではないため、請求確認にはBilling側のデータを参照する必要があります。(The GitHub Blog)
| 確認ポイント | 重要度 | 実務で必要な対応 |
|---|---|---|
| API廃止・非推奨か | 高 | 今回はRelease扱い。廃止期限ではなく、利用状況メトリックの拡張として扱う |
| 追加された項目 | 高 | ユーザー別レポートにai_credits_usedを取り込めるよう、ETLやBIのスキーマを確認する |
| 課金への影響 | 高 | 利用傾向の把握には使えるが、請求額の確定値としては扱わない |
| 期限対応 | 中 | 明示的なAPI移行期限は示されていないが、従量課金移行後の月次運用に合わせて早めに反映する |
| 見落としやすい点 | 高 | ユーザー別合計であり、モデル別・機能別の内訳ではない |
何が変わったのか
GitHub Copilot usage metrics APIのユーザー別レポートに、ai_credits_usedという新しいフィールドが追加されました。
このフィールドは、各ユーザーがその期間に消費したAI creditsの合計を示します。対象になるのは、EnterpriseレベルとOrganizationレベルのユーザー別レポートで、1日単位のusers-1-dayと、直近28日単位のusers-28-dayの両方です。GitHub Changelogでは、このデータはusage-based billing APIで使われるAI credits消費データと同じ系統のデータから算出されると説明されています。(The GitHub Blog)
対象になる主なレポート
Copilot usage metrics APIでは、レポートそのものを直接JSONで返すのではなく、レポートファイルへのダウンロードリンクを返す形式です。GitHub Docsでは、レポートは日次で生成され、有効期限付きの署名付きURLとして提供されると説明されています。(GitHub Docs)
| 対象 | 1日単位のレポート | 28日単位のレポート | 主な用途 |
|---|---|---|---|
| Enterprise | GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD | GET /enterprises/{enterprise}/copilot/metrics/reports/users-28-day/latest | 全社横断でユーザー別の消費傾向を確認 |
| Organization | GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD | GET /orgs/{org}/copilot/metrics/reports/users-28-day/latest | 組織単位でチームや部門の利用状況を確認 |
既にCopilot usage metrics APIを使って、Power BI、Looker、Tableau、BigQuery、Snowflake、社内ダッシュボードなどにデータを取り込んでいる場合は、ai_credits_usedを無視してもシステムが止まらないか、逆に未知の列として取り込みエラーにならないかを確認してください。
廃止・非推奨ではないが、移行対応が必要な理由
今回のChangelog自体は「Release」です。つまり、Copilotの廃止や既存APIの即時停止を知らせるものではありません。
それでも移行対応が必要なのは、GitHub Copilotの課金モデルがすでにAI creditsベースへ移っているためです。GitHubは2026年6月1日から、Copilotの利用をGitHub AI Creditsで測定する従量課金モデルへ移行すると発表しています。従来のPremium Request Units中心の見方では、今後のコスト管理や利用分析がずれやすくなります。(The GitHub Blog)
組織・企業向けのGitHub Copilotでは、AIモデルを使うやり取りが入力トークン、出力トークン、キャッシュされたトークンなどに基づいてAI creditsへ変換されます。GitHub Docsでは、1 AI credit = 0.01米ドルとして説明されています。また、Copilot Businessは標準でユーザーあたり月1,900 AI credits、Copilot Enterpriseは月3,900 AI creditsが含まれ、既存顧客には2026年6月1日から9月1日までプロモーション枠としてBusinessは3,000、Enterpriseは7,000 AI creditsが提供されます。(GitHub Docs)
このため、2026年9月1日前後は特に注意が必要です。プロモーション期間の利用量を前提に予算を組んでいると、標準枠に戻った後に「急に上限に近づく」「一部ユーザーだけ予算切れになる」「追加利用を許可していて想定外の請求が発生する」といった問題が起きやすくなります。
ai_credits_usedで分かること、分からないこと
ai_credits_usedを正しく使うには、分かることと分からないことを分けて考える必要があります。
| 項目 | 分かるか | 説明 |
|---|---|---|
| ユーザーごとのAI credits消費量 | 分かる | ユーザー別レポートで合計値として確認できる |
| 日別の消費傾向 | 分かる | users-1-dayを継続取得すれば日次推移を見られる |
| 直近28日の傾向 | 分かる | users-28-dayで大まかな利用傾向を把握できる |
| どの機能で消費したか | 分からない | 現時点では機能別に分解されない |
| どのモデルで消費したか | 分からない | モデル別の内訳としては提供されない |
| 請求書上の確定金額 | 分からない | 請求確認にはBilling APIや請求画面を使う |
特に注意したいのは、「利用量が多いユーザー＝無駄遣いしているユーザー」と単純に判断しないことです。Copilot cloud agentや長いコーディングセッション、複数ファイルをまたぐ調査、コードレビュー支援などは、短いチャットよりもAI creditsを多く使いやすくなります。GitHub Docsでも、やり取りのコストは利用モデルと消費トークン数に左右され、長いエージェントセッションは高くなりやすいと説明されています。(GitHub Docs)
影響を受ける管理者・チーム
この変更は、GitHub Copilotを個人で使っているだけならすぐに作業が必要とは限りません。一方で、企業利用では複数の担当者に影響します。
| 立場 | 影響 | 確認すべきこと |
|---|---|---|
| GitHub Enterprise管理者 | Enterprise全体の使用量把握に影響 | Copilot usage metricsポリシー、API権限、データ取得ジョブ |
| Organization owner | 組織単位のユーザー別分析に影響 | 組織別レポートの取得可否、権限、ダッシュボード |
| 経理・FinOps担当 | 予算超過や部門別配賦に影響 | Billing APIとの照合、月次集計、コストセンター |
| 開発組織の責任者 | 導入効果と使い方の改善に影響 | 利用が少ないチーム、多すぎるチーム、教育対象 |
| データ基盤・BI担当 | スキーマ変更に影響 | 取り込みエラー、型定義、集計ロジック、保存期間 |
GitHub Docsでは、EnterpriseのCopilot usage metrics APIを有効にするには「Copilot usage metrics」ポリシーがEnterprise全体で有効になっている必要があると説明されています。また、Enterpriseレベルのレポート取得にはEnterprise owner、billing manager、または必要な権限を持つユーザーが関係します。(GitHub Docs)
今から確認すべき移行対応
API連携のスキーマを確認する
最初に確認すべきなのは、APIレスポンスやレポートファイルを取り込む処理です。
既存のデータ取り込みが「想定した列だけを受け付ける」設計になっている場合、新しいai_credits_usedが追加されたことでエラーになる可能性があります。逆に、未知の列をすべて捨てる設計になっている場合は、せっかく追加された重要な課金関連メトリックを取得できません。
確認すべきポイントは次のとおりです。
| 確認項目 | 推奨対応 |
|---|---|
| JSONスキーマやテーブル定義 | ai_credits_usedを数値項目として追加できるか確認 |
| 既存のSELECT句 | SELECT *に依存して表示列が崩れないか確認 |
| BIダッシュボード | ユーザー別、組織別、日別のAI credits推移を表示できるようにする |
| 取り込みタイミング | 日次レポートを取得後、署名付きURLの有効期限切れ前に保存する |
| 過去データ | 追加前の期間では値がない可能性を考慮し、NULLや欠損に耐える設計にする |
実務では、いきなり本番ダッシュボードに追加するのではなく、まず検証用テーブルに1日分と28日分の両方を取り込み、ユーザー数、日付、合計値、欠損値を確認するのが安全です。
請求データと混同しない
ai_credits_usedは、利用状況を分析するためのシグナルです。請求金額の確定値として扱うと、月次締めや部門配賦でずれが出る可能性があります。
請求確認には、Billing usage API側のAI credit usage reportを使います。Enterprise向けのBilling APIでは、AI credit usage reportを取得でき、年・月・日、Organization、User、Model、Product、Cost center IDなどで絞り込めます。GitHub Docsでは、このエンドポイントはEnterpriseのadministratorまたはbilling manager向けで、過去24か月分のデータにアクセスできると説明されています。(GitHub Docs)
| 用途 | 見るべきデータ |
|---|---|
| ユーザー別の利用傾向 | Copilot usage metrics APIのai_credits_used |
| 月次請求の確認 | Billing AI credit usage report |
| モデル別・プロダクト別の金額確認 | Billing APIのmodel、productなどの絞り込み |
| 部門・コストセンター別の配賦 | Billing APIやコストセンター設定 |
| 利用促進・教育対象の把握 | usage metrics APIとチーム情報の組み合わせ |
おすすめは、「usage metrics APIで日々の異常や傾向を早期検知し、月次の確定処理ではBilling APIで照合する」運用です。
予算アラートをユーザー別に見直す
AI creditsがユーザー別に見えるようになると、予算アラートの精度を上げられます。
ただし、組織・企業向けのAI creditsはユーザーごとに完全に独立した枠ではなく、課金エンティティ単位でプールされます。GitHub Docsでは、たとえばCopilot Businessユーザー100人の場合、100人それぞれの個別バケットではなく、190,000 AI creditsの共有プールとして扱われる例が示されています。(GitHub Docs)
そのため、単純に「1人あたり月1,900 AI creditsを超えたら即問題」と見るのではなく、次のような基準で監視するのが現実的です。
| 監視ルール例 | 目的 |
|---|---|
| 1日の消費量が過去7日平均の3倍を超えたユーザーを検知 | エージェントの暴走、誤操作、集中的な作業を確認 |
| 上位5％のユーザーが全体の50％以上を消費していないか確認 | 一部ユーザーへの偏りを把握 |
| 月の20日時点で共有プールの80％相当を超えていないか確認 | 月末前の予算超過を予防 |
| ユーザー別予算に近づいた人を通知 | 突然Copilotが使えなくなる事態を防ぐ |
| 低利用ユーザーと高消費ユーザーを分けて見る | ライセンス配分や教育内容を見直す |
予算を使い切った場合の挙動にも注意が必要です。追加利用を許可していれば使用は続き、追加支出が発生します。許可していなければ、次の請求サイクルまで使用がブロックされます。また、ユーザー別予算を使い切ったユーザーは、組織全体のプールに余裕があってもCopilotへのアクセスが止まる場合があります。GitHub Docsでは、予算が尽きた際に低コストモデルへ自動フォールバックする仕組みはないと説明されています。(GitHub Docs)
開発者向けの使い方ガイドを更新する
管理者側のAPI対応だけでなく、開発者向けの説明も更新しておくと混乱を減らせます。
特に、次のような使い方はAI creditsの消費が増えやすいため、社内ガイドラインに明記すると効果的です。
| 利用シーン | 消費が増えやすい理由 | 推奨する使い方 |
|---|---|---|
| 大量ファイルを対象にしたチャット | 入力コンテキストが大きくなる | 対象ファイルや範囲を絞って質問する |
| 長時間のエージェント作業 | 複数ステップでトークンを消費する | 目的、制約、完了条件を明確にして開始する |
| 高性能モデルの常用 | モデルによって単価が変わる | 作業の難易度に応じてモデルを選ぶ |
| コードレビュー支援の多用 | レビュー対象が大きいほど処理が増える | PRサイズを小さくし、レビュー範囲を明確にする |
| 同じ質問の繰り返し | 不要な出力トークンが増える | 途中結果を保存し、追加質問で進める |
GitHub Docsでは、Copilot Chat、Copilot CLI、Copilot cloud agent、Copilot Spaces、Spark、サードパーティのコーディングエージェントなど、AIモデルを使う機能がAI creditsを消費すると説明されています。一方で、有料プランではコード補完とNext Edit suggestionsはAI credits課金対象ではなく、無制限とされています。(GitHub Docs)
失敗しやすいポイント
ai_credits_usedを請求額として扱ってしまう
最も多い失敗は、ai_credits_usedをそのまま請求書の金額として扱うことです。
この値はユーザー別の利用状況分析には有用ですが、請求確認にはBilling APIや請求画面が必要です。特に、割引、プロモーション、コストセンター、組織横断の配賦、追加利用の扱いが絡む場合は、usage metrics APIだけで会計処理を完結させない方が安全です。
機能別・モデル別の内訳が取れると思い込む
ai_credits_usedはユーザー別の合計値です。現時点では、どのモデルで何credits、どの機能で何creditsという形には分かれません。
そのため、「あるユーザーの消費が多い理由」を調べるには、利用日、チーム、担当プロジェクト、エージェント利用の有無、コードレビューの実施状況など、別の情報と組み合わせて見る必要があります。
プロモーション期間の利用量を通常運用の基準にしてしまう
2026年6月1日から9月1日までの既存Business/Enterprise顧客向けプロモーション枠は、移行期の特別な条件です。9月以降も同じ使い方を続けると、標準枠に戻った際に予算超過や利用停止が発生しやすくなります。
実務では、6月から8月の利用量をそのまま基準にするのではなく、標準枠に換算した場合の消費率を別途計算しておくべきです。
ダウンロードリンクを後で取りに行く設計にする
Copilot usage metrics APIのレポートは、ダウンロードリンク経由で取得します。署名付きURLには有効期限があるため、APIでリンクだけ保存しておき、後日ファイルを取りに行く設計は避けた方が安全です。
日次バッチでは、リンク取得、ファイル取得、永続保存、取り込み検証までを同じ処理の中で完了させる設計にしましょう。
実務で使えるダッシュボード例
ai_credits_usedを追加したら、単に「消費量ランキング」を作るだけでは不十分です。コスト削減だけに寄せると、開発者がCopilotを使いにくくなり、導入効果を下げてしまいます。
おすすめは、次の3種類のビューを用意することです。
| ビュー | 見る指標 | 目的 |
|---|---|---|
| FinOpsビュー | 日別AI credits、上位ユーザー、組織別合計、予算消化率 | 予算超過の早期検知 |
| Adoptionビュー | アクティブユーザー、低利用ユーザー、チーム別利用傾向 | ライセンス活用と教育対象の把握 |
| Anomalyビュー | 急増ユーザー、連続高消費、週次平均との差分 | 誤操作やエージェントの過剰実行の検知 |
特に重要なのは、消費量と成果をセットで見ることです。たとえば、AI creditsの消費が多いチームでも、PR作成、レビュー効率、テスト追加、障害対応の短縮などに効果が出ているなら、単純に制限すべきではありません。逆に、消費量が少ないチームは、ライセンスが不要なのではなく、使い方を知らないだけの可能性もあります。
管理者が次に取るべき行動
今回の変更は、緊急の廃止対応ではありません。しかし、GitHub Copilotの課金管理がAI credits中心になった今、usage metrics APIのai_credits_usedを取り込まないまま運用を続けると、利用状況の把握が遅れます。
まずは次の順番で確認してください。
| 優先度 | 対応 | 目安 |
|---|---|---|
| 高 | Copilot usage metrics APIの取得処理が動作しているか確認 | すぐ |
| 高 | ai_credits_usedをスキーマに追加し、欠損値に耐える設計にする | 次回バッチ改修時 |
| 高 | Billing APIのAI credit usage reportと月次で照合する | 次回請求締め前 |
| 中 | ユーザー別・組織別のAI creditsダッシュボードを作る | 1〜2サイクル以内 |
| 中 | 2026年9月1日以降の標準枠を前提に予算を再計算する | プロモーション終了前 |
| 中 | 開発者向けにAI creditsを消費しやすい使い方を周知する | 利用拡大前 |
今回のAPI更新は、Copilotの廃止や非推奨を知らせるものではなく、従量課金時代の利用状況をより細かく把握するための変更です。管理者は「追加フィールドだから後でよい」と考えるのではなく、月次の予算管理、ユーザー別の利用傾向、請求データとの照合に組み込むことが重要です。
コメント