こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。
GitHubは2026年11月3日、Copilot usage metrics APIでBYOKと企業独自モデルの利用量を分けて確認できるようにしました。BYOKは「Bring Your Own Key」の略で、自分や会社が用意したAPIキー、ローカルモデル、独自の接続先をCopilotから使う仕組みです。これまでは同じモデル名がCopilot提供モデルと混ざりやすく、誰がどの経路を使ったのかを管理画面の合計だけで判断しにくい問題がありました。
今回の追加で、Local BYOKは利用の有無、セッション、リクエスト、プロンプト、トークンなどを専用項目で確認できます。企業管理者が設定した独自モデルには判定用の項目が付きます。ただし、Local BYOKはクライアント側のテレメトリーに依存するため、計測されない利用があり得ます。過去データの補完もありません。この記事では、見える数字と見えない数字を分け、管理者が誤解せず集計する手順を解説します。
- Local BYOKと企業独自モデルの違い
- 追加されたAPI項目と集計単位
- テレメトリー無効時の過少計測
- 費用や利用状況を読む時の注意点
Copilot BYOK利用量APIで見える情報
最初に、二つのBYOKを分けましょう。GitHubの発表では、開発者が自分のクライアントへ設定するLocal BYOKと、企業や組織の管理者がGitHub設定へ登録するenterprise custom modelsを別に扱います。同じ「自前モデル」でも、通信経路と計測方法が違います。
Local BYOKは利用者側で設定する
Local BYOKは、開発者がCopilot CLIまたはGitHub Copilot appへ自分の接続先を設定する方式です。OpenAI互換の接続先だけでなく、Ollama、Foundry Local、LM Studio、llama-serverなど、手元や社内で動かすモデルも対象になり得ます。リクエストはCopilotのクライアントから、利用者が指定したプロバイダーキーやローカルモデルへ送られます。
利用者単位のレポートでは、少なくとも1回Local BYOKを使ったかを示すused_local_byokが追加されました。さらにtotals_by_local_byokで、セッション、リクエスト、プロンプト、トークンの数を確認できます。内訳にはbyok_kindとsurfaceがあり、どの種類の接続をCopilot CLIとCopilot appのどちらで使ったかを分けられます。
集計レポートには、日次、週次、月次のアクティブなLocal BYOK利用者数も用意されます。単にリクエスト数が多いかだけでなく、何人が利用したかを見られるため、社内展開の範囲を確かめる時に役立ちます。ただし、これらの人数を契約席数や費用と同じ意味で扱わないようにしてください。
企業独自モデルは判定項目で分ける
enterprise custom modelsは、管理者がGitHubの設定で組織や企業向けに登録するモデルです。リクエストはGitHubを経由してプロバイダーへ送られます。そのためGitHubはサーバー側で利用を観測でき、IDEを含むすべてのクライアントが対象になります。
APIではtotals_by_client[].totals_by_model[]の各項目へis_custom_enterprise_modelという真偽値が追加されました。値がtrueなら、その集計は企業や組織が設定した独自モデルの利用です。同じモデル名がCopilot提供モデルと独自モデルの両方で使われた場合も、別の行として返されるため、数字を混ぜずに比較できます。
企業独自モデルの項目には実際のリクエスト数とトークン数が含まれます。Local BYOKと違ってGitHub側で観測されるため、クライアントのテレメトリー無効による同じ制限はありません。ただし、モデル名は既存の正規化処理を通り、認識されない名称はunknownになる可能性があります。
既存の合計値は変わらない
新しい項目が増えると、前日までの合計が急に変わるのでは、と心配になりますよね。GitHubは、BYOK利用が以前から既存の合計へ含まれており、今回の追加で既存合計は変わらないと説明しています。Local BYOKはtotals_by_cliとtotals_by_copilot_appの一部で、企業独自モデルはtotals_by_clientにすでに含まれていました。
つまり、新項目を既存合計へ足すと二重計上になります。今回の変更は、新しい利用が合計へ加わったのではなく、既存合計の内訳を見分けられるようになったものです。ダッシュボードを作る時は「総利用量」と「そのうちBYOK」を親子関係で表し、別々の独立した合計として足さないでください。
誰がAPIを閲覧できるか
GitHubの案内では、企業所有者、企業の請求管理者、組織所有者、またはView Copilot Metrics権限を与えられたカスタムロールの利用者が対象です。さらにCopilot usage metricsのポリシーが有効である必要があります。権限がない利用者の画面に項目が出ないことを、機能障害と決めつけないようにしましょう。
レポートは企業と組織の両方で、利用者単位と集計単位、1日と28日の期間に対応します。まず一つの組織と短い期間で応答形式を確認し、その後に企業全体へ広げると安全です。項目の存在だけでなく、null、0、空配列の違いも保存し、取得失敗を利用なしへ置き換えないようにしてください。
Copilot BYOK利用量を正しく読む方法
数字が取れるようになっても、数字の意味を誤ると判断を誤ります。特にLocal BYOKでは、テレメトリーとトークン報告の制限を理解することが欠かせません。費用管理、利用者支援、ポリシー確認の目的ごとに、見る項目を分けましょう。
Local BYOKは下限値として扱う
Local BYOKの項目はクライアントのテレメトリーへ依存します。利用者や組織の設定でテレメトリーが無効なら、実際に使っていてもレポートへ現れない場合があります。そのため、Local BYOKの人数やリクエスト数は、確認できた利用の下限と考えるのが適切です。
トークン数にも同じ注意が必要です。一部のローカルプロバイダーはトークン数を返さないため、リクエストは存在してもトークンが少なく見えることがあります。トークンが0だからモデルを使っていない、と即断してはいけません。利用の有無、セッション、リクエスト、トークンを並べ、値の欠落を別の状態として扱いましょう。
大切な注意
今回のAPIは監査ログそのものではありません。機密データが送られたか、どのプロンプト本文が使われたか、出力が正しかったかを示す機能ではありません。アクセス制御やデータ保護の確認は、別の管理手段と合わせて行ってください。
過去の日付は補完されない
is_custom_enterprise_modelは今回のリリースより前の日付へ遡って追加されません。発表前と発表後を同じ列で比較すると、古い期間がゼロに見えることがあります。しかし、それは利用がなかった証拠ではなく、当時は判定項目が存在しなかっただけかもしれません。
分析表には、項目が利用可能になった日を境界として記録してください。過去分を0で埋めず「未取得」「項目なし」と区別します。28日レポートへ新旧期間が混ざる場合は、内訳が比較可能な日数を注記すると誤解が減ります。
費用と利用量を混同しない
Local BYOKのリクエストは、利用者自身のプロバイダー契約で課金される場合も、ローカルPCで費用を追加せず動く場合もあります。企業独自モデルも、プロバイダーとの契約や単価によって費用が異なります。Copilot usage metrics APIのトークン数だけから請求額を断定することはできません。
費用を見るなら、Copilot側の利用量と、各プロバイダー側の請求データを別々に取得し、期間、タイムゾーン、モデル名、組織をそろえて突き合わせます。GitHub側でunknownになったモデルを推測で特定せず、接続設定とプロバイダー記録を確認してください。
管理者向けの確認手順
| 順番 | 確認内容 | 理由 |
|---|---|---|
| 1 | 閲覧権限とmetricsポリシー | 項目が出ない原因を切り分ける |
| 2 | 1日レポートの応答形式 | nullと0と空配列を区別する |
| 3 | Local BYOKの利用有無と内訳 | CLIとapp、接続種類を分ける |
| 4 | 企業独自モデルの真偽値 | 同名の提供モデルと混同しない |
| 5 | プロバイダー請求との照合 | 利用量を費用と断定しない |
最初から全社ダッシュボードを作るより、一つの組織、一つの日付、一人の既知利用者で検証するのがおすすめです。意図的にLocal BYOKを使ったケースと企業独自モデルを使ったケースを用意し、どの項目へ現れるかを確認します。ただし、本番のAPIキーや機密リポジトリを検証へ持ち込まないでください。
BYOKポリシー確認に使う
新しい内訳は、BYOKを禁止または許可する社内ポリシーの確認にも使えます。たとえばLocal BYOKを許可していない組織でused_local_byokが見つかったら、すぐに不正と断定するのではなく、対象利用者、端末、設定、例外申請の順に確認します。テレメトリーには限界があるため、数字がないことも完全な遵守証明にはなりません。
反対にBYOKを許可している組織では、利用者の支援材料になります。Local BYOKのアクティブ人数が増えたのに問い合わせも増えたなら、接続手順やモデル選択の説明が不足しているかもしれません。数字を取り締まりだけでなく、ドキュメント改善や教育へ使うと価値が上がります。
日次と28日レポートの使い分け
1日レポートは、設定変更や障害の直後を確認するのに向いています。たとえば、管理者が企業独自モデルを有効にした翌日に、既知のテスト利用がis_custom_enterprise_model=trueとして現れるかを見ます。短い期間なら、利用者、時刻、接続先の変更と数字を結び付けやすく、取得項目の理解にも役立ちます。
28日レポートは、日々のばらつきをならして利用傾向を見るのに向いています。ただし、新項目の提供開始直後は、28日間すべてが同じ条件ではありません。今回のように過去補完がない項目では、古い日付が混ざるほど数字が小さく見えます。比較するなら、新項目が存在する完了日だけを同じ日数でそろえるか、比較可能日数を注記してください。
日次の合計を自前で足した値と、APIが返す28日集計が一致しない場合も、すぐ不具合と決めつけないこと。週次・月次のアクティブ利用者は期間内の重複を除いた人数なので、日ごとの人数を単純に足した値とは意味が違います。タイムゾーンやデータ確定時刻もそろえて確認します。
ダッシュボードの表示例
管理画面では、最上段にCopilot全体の利用量、その下にLocal BYOKと企業独自モデルの内訳を置くと関係が伝わりやすくなります。Local BYOKのカードには、確認できた利用者数、セッション、リクエスト、トークンを表示し、「テレメトリーにより下限値」と注記します。企業独自モデルのカードには、モデル別のリクエストとトークン、unknownの件数を示します。
0、未取得、項目なしは色と文言を分けます。0はAPIが取得でき、対象利用が0だった状態。未取得は権限、通信、処理などの理由で値を確認できなかった状態。項目なしは、その日付や応答形式に新しい項目が存在しない状態です。この三つを同じ0として描くと、ポリシー違反の見落としや、利用が急減したという誤った報告につながります。
グラフには、モデル設定を変えた日、社内案内を出した日、API項目が追加された日を注記すると、数字の変化を読みやすくなります。ただし、注記した出来事と利用量の変化が同じ日に起きても、原因だと断定はできません。利用者への聞き取り、接続設定、プロバイダー側の記録を合わせて確認します。
API応答を保存する時の注意
利用量APIの応答には、利用者や組織の運用状況を推測できる情報が含まれることがあります。分析用ファイルを公開リポジトリへ置かず、閲覧権限を必要な担当者に限定してください。生データ、集計データ、外部へ共有できる報告を分け、利用者名や識別子が不要な報告では匿名化します。
また、APIキーや認証情報を集計スクリプトへ直接書かないこと。既存の秘密管理を使い、ログへ認証ヘッダーを出さないようにします。エラー調査のため応答を保存する場合も、秘密情報や個人情報が混ざっていないか確認しましょう。数字を取得する権限と、社内へ共有する権限は別です。
集計プログラムを更新した時は、過去の同じ応答を入力して結果が変わらないかを試します。項目追加に対応したつもりで、既存合計へ内訳を足してしまう二重計上は起こりやすいミスです。テストでは、Local BYOKあり、企業独自モデルあり、両方なし、項目なし、値欠落の例を用意すると安心です。
利用者へ伝える説明文
管理者がBYOK利用を可視化する時は、利用者へ目的を説明してください。「監視を強める」だけでは不安を招きます。費用の把握、許可された接続先の確認、困っている利用者への支援、社内ドキュメントの改善といった目的を明確にし、取得する項目と取得しない内容を分けて伝えます。
今回のusage metrics APIは、プロンプト本文や生成コードの品質を評価する機能ではありません。利用者の成果や能力を、リクエスト数やトークン数だけで判断しないでください。少ないリクエストで価値の高い作業を終える人もいれば、学習や試行で多く使う人もいます。数字は対話の入口であり、人事評価の結論ではありません。
移行前後の比較方法
Copilot提供モデルからBYOKへ切り替える効果を見たい場合は、切り替え前後で同じ条件をそろえます。期間の日数、対象利用者、作業の種類、休日、社内イベントが違うと、利用量の差をモデル経路の効果だけに結び付けられません。まずは完了した7日間を、その直前の同じ長さの期間と比べ、データ末日を明記します。
見る指標も一つに絞らないでください。アクティブ利用者、セッション、リクエスト、トークンに加え、作業完了数、レビュー差し戻し、問い合わせなどを目的に応じて選びます。usage metrics APIだけでは作業品質を確認できないため、コードレビューや利用者の報告を合わせます。費用はプロバイダー請求で別に確認します。
切り替え後にリクエストが減っても、利用者が離れたとは限りません。一回のセッションが長くなった、ローカルモデルがトークンを報告しない、テレメトリーが無効になったなど複数の説明があります。逆に増加しても、生産性が上がったと即断できません。失敗の再試行が増えた可能性もあります。
取得失敗を安全に扱う
API取得が失敗した時は、前日の値を当日の値として再利用しないでください。ダッシュボードには最終成功日時とデータ末日を表示し、失敗した日は未取得として残します。自動処理が再試行する場合も、同じ期間を重複保存しないように一意のキーを使います。
権限不足のエラー、ポリシー無効、通信エラー、応答形式の変更は、対処方法が異なります。認証を迂回したり、権限を必要以上に広げたりせず、まず読み取り権限とポリシーを確認します。応答項目が増えた時に処理が停止しないよう、未知の項目を無視しつつ原本応答を安全な場所へ保存する設計も役立ちます。
数字が取れない時間があっても、利用者の作業そのものを止める必要があるとは限りません。計測、費用確認、ポリシー違反の疑いを別々の状態で管理し、影響する工程だけを保留します。計測が戻った後に再取得できる期間と、過去補完されない項目も分けて記録しましょう。
最後に、集計方法そのものへ版番号を付けると後から説明しやすくなります。API項目、除外条件、タイムゾーン、重複排除の方法を短い仕様書へ残し、変更日を記録します。同じグラフ名でも計算方法が変われば、前後の値はそのまま比較できません。仕様変更の日をグラフへ注記し、アクセスできる担当者が再計算できる状態を保ってください。
この記録があれば、担当者が替わっても「なぜこの数字になったか」を追えます。値そのものだけでなく、取得条件と確認日時を成果物の一部として残しましょう。
監視を続ける場合は、同じ条件の完了期間を比べ、未取得を0へ置き換えないことが基本です。
Copilot BYOK利用量のFAQ
Q1. BYOKの利用量は以前の合計へ追加されますか？
A. いいえ。BYOKは以前から既存合計へ含まれており、今回の項目は内訳を分けるためのものです。足し合わせると二重計上になります。
Q2. Local BYOKの数字は完全ですか？
A. 完全とは限りません。クライアントのテレメトリーが無効な場合や、ローカルプロバイダーがトークン数を返さない場合は過少計測になり得ます。
Q3. 過去28日分を同じ条件で比較できますか？
A. 新しい企業独自モデル判定は過去へ補完されません。リリース前の日を0にせず、項目なしとして区別してください。
Q4. APIの利用量からBYOK料金が分かりますか？
A. 利用量だけで請求額は確定できません。各プロバイダーの契約、単価、請求期間と照合する必要があります。
Q5. 誰でもレポートを閲覧できますか？
A. 所有者や請求管理者、View Copilot Metrics権限を持つロールが対象で、usage metricsポリシーも有効である必要があります。
Copilot BYOK利用量APIまとめ
GitHub Copilot usage metrics APIの更新により、Local BYOKと企業独自モデルをCopilot提供モデルから分けて確認しやすくなりました。Local BYOKでは利用有無、セッション、リクエスト、プロンプト、トークン、アクティブ利用者を確認でき、企業独自モデルではis_custom_enterprise_modelで判定できます。
一方、Local BYOKはテレメトリー次第で過少計測になり、トークン数が欠ける場合があります。過去分の補完もありません。数字を0へ丸めず、未取得や項目なしを分け、既存合計へ内訳を足さないことが大切です。利用状況、ポリシー、費用は一つの数字で断定せず、プロバイダー記録や管理設定と合わせて確認しましょう。
公式情報
GitHub Changelog：BYOK and enterprise custom models in the Copilot usage API
