GitHubのCopilot利用状況メトリクスAPIがBYOKと企業カスタムモデルを別集計:ローカルBYOKは下限値でモデル別内訳なし、過去のレポート日にはis_custom_enterprise_modelフラグが遡及されない
2026年11月3日、GitHubの更新ログは、Copilot利用状況メトリクスAPIがBYOKを別集計にしたと伝えました。開発者のクライアントで設定するローカルBYOK(used_local_byok、totals_by_local_byok)と、管理者が構成するエンタープライズのカスタムモデル(is_custom_enterprise_model)で、エンタープライズと組織、ユーザー単位と集計単位、1日と28日のレポートが対象です。ローカルBYOKはクライアントのテレメトリに依存して下限値で、トークン数も少なくなりうるうえ、モデル別の内訳はなく、リリース前の日にはis_custom_enterprise_modelがなく、フィールドは金額ではなく件数です。RESTドキュメントはフィールドを定義せず、権限名も更新ログと完全には一致しません。
2026年11月3日、GitHubの更新ログは、Copilot利用状況メトリクスAPIがBYOK(自分のキーを持ち込む方式)の利用を別集計で表示するようになったと発表しました。管理者はCopilotが提供するモデルの利用と区別できます。これまではローカルモデルやカスタムモデルの名前がCopilotのモデルと同じことが多く、BYOKの利用はホスト型の合計に埋もれていました。今回の更新はBYOKを2種類に分けます。開発者が自分のクライアントで設定する「ローカルBYOK」と、管理者がGitHubの設定で構成する「エンタープライズのカスタムモデル」です。どちらもエンタープライズと組織のレポートに、ユーザー単位と集計単位で、1日分と28日分の両方に現れます。
ローカルBYOKは、開発者自身のプロバイダーキーや、Ollama、Foundry Local、LM Studio、llama-serverなどで動かすローカルモデルを指します。リクエストはCopilot CLIまたはGitHub Copilotアプリから、GitHubを経由せず開発者のプロバイダーやローカルモデルへ直接送られます。フィールドは、ユーザー単位のレポートにあるused_local_byok(その日にCopilot CLIまたはCopilotアプリでローカルBYOKのリクエストを1回以上行ったか)、byok_kind(local_managed、local_user、local_auto、remote_user)とsurface(copilot_cli、copilot_app)別にセッション、リクエスト、プロンプト、トークンの数を示すtotals_by_local_byok、集計レポートの日次・週次・月次のアクティブなローカルBYOKユーザー数です。
エンタープライズのカスタムモデルは管理者がGitHubの設定で構成し、リクエストはGitHubを経由してプロバイダーに届きます。新しいis_custom_enterprise_modelは、totals_by_clientの各モデルエントリにある真偽値で、エンタープライズまたは組織向けに構成したカスタムモデルを使ったリクエストでtrueになります。GitHubがサーバー側で観測するため、IDEを含むすべてのクライアントをカバーします。同じモデル名がCopilotのホスト型とカスタムの両方で使われた場合は2つのエントリになり、数は混ざりません。カスタムモデルのエントリには実際のリクエスト数とトークン数が入ります。
ガバナンスとコスト分析に役立ちます。管理者は、誰が自分のプロバイダーキー、ローカルモデル、エンタープライズのカスタムモデルにリクエストを送っているかを、BYOKポリシーと照らして確認できます。Copilotが提供する利用と、自社のプロバイダーが課金する利用や無料のローカルモデルでの利用を分けて、ユーザーあたりのコストがCopilotの実際の提供分だけを反映するようにできます。ツールをまたいだ利用を1つの画面で見て、BYOKやカスタムモデルを使うユーザーを既存のCopilotメトリクスと比べることもできます。ただしこれらのフィールドはセッション、リクエスト、プロンプト、トークンの数で、記事には金額のフィールドの説明がないため、請求額ではありません。
「重要な注意」にはいくつかの制約があります。第一に、既存の合計は変わりません。BYOKの利用はもともと計上されており、ローカルBYOKはtotals_by_cliとtotals_by_copilot_appの一部、カスタムモデルの利用はtotals_by_clientにすでに含まれます。第二に、ローカルBYOKは下限値です。これらのフィールドはクライアントのテレメトリに依存し、無効だと少なく記録され、トークン数もプロバイダーによっては報告されないため少なくなることがあります。エンタープライズのカスタムモデルはサーバー側で観測するため、この制限はありません。第三に、モデル名は既存の正規化に従い、認識できない名前はunknownになり、ローカルBYOKはモデル名で分解されません。第四に、過去への反映はなく、リリース前の日のレポートにis_custom_enterprise_modelはなく、それ以前の日にローカルBYOKのフィールドがあるかは記事に書かれていません。第五に、利用できるのはエンタープライズオーナー、エンタープライズの請求管理者、組織オーナー、およびView Copilot Metrics権限を持つカスタムロールの保持者で、Copilot利用状況メトリクスのポリシーを有効にする必要があります。
「一部である」という規則には実務上の帰結があり、二重計上です。ローカルBYOKはすでにtotals_by_cliとtotals_by_copilot_appに含まれ、カスタムモデルの利用はすでにtotals_by_clientに含まれているため、新しいフィールドを古い合計に足すダッシュボードは同じリクエストを2回数えてしまいます。新しいフィールドは引くか絞り込むための断面で、足すための追加行ではありません。2種類は信頼性も違います。カスタムモデルの数はGitHubがサーバー側で観測し、ローカルBYOKの数は開発者やポリシーが無効にできるクライアントのテレメトリから来るため、ローカルBYOKの線が下がったとき、利用が減ったのかテレメトリが減ったのかはレポートだけでは判別できません。
裏づけとなるRESTドキュメントはエンドポイントについてより具体的です。レポートは有効期限つきの署名付きリンクで取得するNDJSONファイルです。エンタープライズ向けエンドポイントには、エンタープライズ全体で「Copilot usage metrics」ポリシーを「Enabled everywhere」にする必要があります。細かい権限は、エンタープライズ用が「View Enterprise Copilot Metrics」、組織用が「View Organization Copilot Metrics」で、履歴は2025年10月10日から最大1年さかのぼれます。このRESTのページ自体は今回追加されたBYOKフィールドを定義しておらず、取得した資料の中で説明しているのは更新ログだけで、そこにある権限名「View Copilot Metrics」はドキュメントの2つの名前と完全には一致しません。対応関係は示されていないので、アクセスを設定する前に自分のGitHubの設定で確認してください。
Sources
FAQ
新しいフィールドからBYOKの利用にいくらかかったか分かりますか?
直接は分かりません。記事が説明しているのはセッション、リクエスト、プロンプト、トークンの数で、金額のフィールドには触れていません。ホスト型の利用と自社プロバイダーが課金する利用を分けるのには役立ちますが、費用はそのプロバイダーの請求書で確認します。ローカルBYOKはモデル名別ではなく、トークン数も少なくなりえます。
ローカルBYOKの数字は完全ですか?
完全ではなく、下限値として扱ってください。これらのフィールドはクライアントのテレメトリに依存し、無効にすると少なく記録され、ローカルプロバイダーによってはトークン使用量を報告しないためトークン数も少なくなりえます。エンタープライズのカスタムモデルはGitHubがサーバー側で観測し、この制限はありません。
以前の日付のレポートにもこのデータは出ますか?
記事が明言しているのは、リリース前の日のレポートにis_custom_enterprise_modelがなく、過去への反映もないということだけです。それ以前の日にローカルBYOKのフィールドがあるかは書かれていません。傾向を見るなら新しいフィールドが現れた日から数え、履歴に頼る前に実際のレポートを抜き取って確認してください。