Copilot利用状況APIでMCP・エージェント名を把握【2026年10月】

発表で変わったのは「自社名が見える」こと

GitHubは2026年10月22日、Copilot usage metrics APIのカスタマイズ関連データを更新しました。これまで自社で作った項目は、主にotherまたはcustomへまとめられていました。更新後は、企業や組織が設定した名前を5種類の配列で確認できます。

前提になったのは、GitHubが2026年9月17日に公開したAgentic CLI customizations now in the usage metrics APIです。この時点で利用イベントを表す配列と、異なる項目数を表すフィールドが追加されました。ただし、自社定義の項目名は伏せられ、各配列で見える上位項目も5件まででした。10月22日の更新は、計測方法を変えるのではなく、名前の識別と表示件数を広げたものです。

確認点	2026年9月の状態	2026年10月22日以降
自社定義の名前	otherまたはcustomに集約	設定名を表示
名前付き項目	1レコードの各配列で上位5件	1レコードの各配列で上位25件
上位件数を超える活動	配列は上位5件まで。上位外の項目は配列に出ず、distinct値にだけ数える	上位25件の後ろに、残りをまとめたotherが付く
計測の意味	interaction_countとdistinct_*_use_countで集計	数え方は変更なし
過去レポート	otherまたはcustom	自動で名前を補完しない

「最大25件」は、名前付き項目に対する上限です。公式ドキュメントでは、25件の名前付き項目に加えて、残りをまとめた末尾のotherが現れる場合があると説明されています。したがって、「配列全体が必ず25要素以内」とは限りません。また、スラッシュコマンドで上位25件から外れた活動を表すotherと、設定名を取得できないスラッシュコマンドを表すcustomは別です。

名前が入る対象は、企業と組織のユーザー別1日・ユーザー別28日・集計1日の各レポート、および集計28日レポート内の各day_totalsです。ダッシュボードではなくAPIとエクスポートで扱う項目なので、管理者はREST APIからレポートを取得して確認します。仕様の詳細はData available in Copilot usage metricsにまとまっています。

なお、設定名が出るのは今回の対応が展開された後に処理されたレポート日からです。更新前の日付を取り直しても、過去のotherやcustomが設定名へ置き換わるわけではありません。導入前後を比較するときは、名前表示に対応したレポート日かどうかを先にそろえてください。

名前が出る道具と版の条件

同じカスタムエージェントを使っていても、どのクライアントから実行したかで設定名の有無が変わります。特に、JetBrainsなどのACP連携と、IDEに組み込まれたCopilot Chatを同じものとして扱わないことが重要です。

利用経路	名前の報告	版の条件と注意点
Copilot CLIの対話セッション	対象	公式は対象として明記。対話セッション自体に1.0.97の条件を一律には付けていない
Copilot CLIのprompt mode（-p）	対象	Copilot CLI 1.0.97以降
GitHub Copilotアプリ	対象	Copilot CLI 1.0.97以降
Agent Client Protocol（ACP）連携	対象	Copilot CLI 1.0.97以降。公式例はJetBrains AI Assistant内のCopilot
Copilot SDK	対象	v1.0.21以降。SDK同梱CLIを上書きする場合は使用するCLIも1.0.97以降
SDKで動くIDEのエージェント体験	条件付きで対象	Copilot SDK v1.0.21以降で動作するとき
IDE組み込みのCopilot Chat	対象外	組み込みチャットのテレメトリからカスタマイズ名は報告されない

管理者が「使われているはずなのに名前がない」と感じたら、最初に確認するのは機能の有効・無効だけではありません。利用経路、Copilot CLIまたはSDKの版、テレメトリの到達状況を切り分けます。IDE内蔵チャットだけで使われた項目は、今回の名前表示の対象外です。ACP連携で使った場合とは結果が異なります。

設定名はそのまま社外へ出せるとは限らない

名前は設定どおりに報告されますが、前後の空白は除かれ、長さは128文字までです。ファイルパスのように見える名前や、名前を取得できない項目は、引き続きotherまたはcustomへまとめられます。

GitHubは、レポートを社外へ共有する前に設定名を確認するよう明記しています。社名、案件名、顧客名、内部リポジトリ名、環境名などをカスタマイズ名へ入れていると、その文字列がレポートに現れる可能性があります。公開用のグラフを作る前に、元のNDJSONだけでなく、集計後のラベルも見直してください。

運用面では、用途が伝わる短い名称と、組織内で重複しにくい命名規則を決めると追跡しやすくなります。ただし、利用状況APIを完全な構成管理台帳として使うことはできません。パス風名称は集約され、上位25件の外側もotherへ入るためです。

管理者が最初にそろえる4項目

1. Copilot usage metricsポリシーを有効にする

REST APIを使うには、Copilot usage metricsポリシーを有効にします。企業向けRESTドキュメントでは、企業全体でEnabled everywhereに設定することがエンドポイントの有効化条件として示されています。企業側で強制されたポリシーは、組織側で上書きできません。設定を変える前に、企業スコープと組織スコープのどちらで管理しているかを確認してください。

2. 閲覧者とトークンの権限を分けて確認する

範囲	閲覧できる役割	fine-grained権限	OAuth／classic PAT
Enterprise	Enterprise owner、billing manager、許可されたカスタムロール	Enterprise Copilot metricsのread	manage_billing:copilotまたはread:enterprise
Organization	Organization owner、許可されたカスタムロール	Organization Copilot metricsのread	read:org

2026年10月22日の発表では、カスタムロール向け権限を総称してView Copilot Metricsと表現しています。一方、RESTドキュメントでは範囲別にView Enterprise Copilot MetricsとView Organization Copilot Metricsが使われています。ロール設定や申請文には、対象スコープに合う名称を使うと行き違いを防げます。

モデル選択の管理もAPI化しているため、利用状況と許可モデルを一緒に整理したい場合は、既刊のCopilotモデルポリシーAPIでの一括管理も参照してください。利用状況APIとは別のAPIなので、権限や目的を混ぜないことが大切です。

3. 欲しい粒度に合わせてレポートを選ぶ

範囲	粒度	RESTエンドポイント
Enterprise	集計・1日	GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day?day=YYYY-MM-DD
Enterprise	集計・最新28日	GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest
Enterprise	ユーザー別・1日	GET /enterprises/{enterprise}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
Enterprise	ユーザー別・最新28日	GET /enterprises/{enterprise}/copilot/metrics/reports/users-28-day/latest
Organization	集計・1日	GET /orgs/{org}/copilot/metrics/reports/organization-1-day?day=YYYY-MM-DD
Organization	集計・最新28日	GET /orgs/{org}/copilot/metrics/reports/organization-28-day/latest
Organization	ユーザー別・1日	GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
Organization	ユーザー別・最新28日	GET /orgs/{org}/copilot/metrics/reports/users-28-day/latest

1日レポートはdayをYYYY-MM-DD形式で指定します。28日レポートはlatestから最新期間を取得します。集計28日レポートで日ごとの変化を見る場合は、各day_totalsにある配列を確認します。

4. APIの応答からレポートファイルを取得する

APIの最初の応答に、利用状況の全レコードが直接入るわけではありません。1日レポートでは署名付きのdownload_linksとreport_day、28日レポートではdownload_linksとreport_start_day、report_end_dayが返ります。管理者はダウンロード先からNDJSONレポートを取得し、対象配列を読みます。署名付きURLの有効時間は限定されていますが、具体的な時間は対象ドキュメントに記載されていません。

実行例: Organizationの集計1日レポート用URLを取得する公式形式です。ORGと日付を自組織の値へ置き換え、トークンは環境変数で渡します。

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer ${GITHUB_TOKEN}" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-1-day?day=YYYY-MM-DD"

注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。トークンをコードや共有資料へ直接書かず、必要最小限のread権限にします。最新のパラメータと認証方式はREST API endpoints for Copilot usage metricsで確認してください。

5つの配列は同じ「利用回数」ではない

5つの配列にはいずれもinteraction_countがありますが、数えているイベントは種類ごとに違います。数字を横並びにして「最も使われた仕組み」を決める前に、単位を確認する必要があります。

配列	名前フィールド	interaction_countが数えるもの	異なる項目数
totals_by_skill[]	skill	スキルの呼び出し	distinct_skill_use_count
totals_by_custom_agent[]	custom_agent	カスタムエージェントの開始	distinct_custom_agent_use_count
totals_by_mcp[]	mcp	MCPサーバーへの接続・再接続試行。成功と失敗の両方	distinct_mcp_use_count
totals_by_slash_cmd[]	slash_cmd	スラッシュコマンドの呼び出し	distinct_slash_cmd_use_count
totals_by_plugin[]	plugin	プラグインに関連付いたスキルの呼び出し	distinct_plugin_use_count

MCPの値はツール実行回数ではない

totals_by_mcp[].interaction_countは、MCPサーバーへの接続または再接続を試みた回数です。成功した接続だけでなく、失敗した試行も含まれます。一度つながったサーバーから複数のツールを呼び出しても、そのツール呼び出しはこの値を増やしません。

そのため、MCPの数値が多いときに「業務で多くのツールが使われた」と断定することはできません。再接続が多い、失敗が続いている、利用者へ設定が広がったなど、複数の可能性があります。接続ログや利用者への聞き取りなど、別の情報と組み合わせて判断します。

pluginとskillを足すと二重計上になる

プラグインのinteraction_countは、そのプラグインに関連付いたスキル呼び出しです。すべてのplugin interactionはskill interactionにも含まれます。一方、プラグインに属さないスキル呼び出しはskill側だけに現れます。したがって、totals_by_pluginとtotals_by_skillを合算して総利用回数を作ってはいけません。

distinctは利用者数でも合計利用回数でもない

distinct_*_use_countが数えるのは、活動が記録された異なる項目識別子です。ユーザー別レコードでは、その人が使った異なる識別子をそれぞれ1件として数えます。企業または組織の集計レコードでは、範囲内の誰かが使った識別子を、利用人数に関係なく1件として数えます。

集計レコードのdistinct値は、ユーザー別レコードのdistinct値を足したものではありません。さらに、上位25件から外れてotherへ入った識別子もdistinctには個別に寄与します。名前付き配列とdistinct値が一致しないことは、直ちに不具合を意味しません。

フィールドが存在する状態で空配列またはdistinct値が0なら、該当する活動は記録されていません。一方、フィールド自体がnullまたは欠けている場合は、展開途中などでデータを利用できない可能性があります。「0」と「データなし」を分けて扱ってください。

普及を見るなら、順位より「同じ条件での変化」を追う

このAPIが役立つのは、社内で共有したスキルやカスタムエージェント、MCPサーバーについて、「どれが使われ始めたか」「利用が一部の人に偏っていないか」「案内後に活動の傾向が変わったか」を確認するときです。正確な請求集計や、許可外カスタマイズを完全に洗い出す監査には向きません。

管理者の問い	見る場所	次に確かめること
どの社内MCPが活動しているか	集計レポートのtotals_by_mcp	接続成功率、再接続の原因、実際のツール利用
誰にカスタムエージェントが広がったか	ユーザー別のtotals_by_custom_agent	対象部署、業務フロー、利用者のフィードバック
使われる種類が増えたか	distinct_*_use_countの推移	命名の重複、otherの比率、廃止候補
周知後に変化があったか	同じ粒度・同じ曜日条件のレポート	クライアント版、テレメトリ、対象人数の変化
名前が出ない理由は何か	利用経路と名前付き配列	IDE組み込みチャット、最低版、パス風名称、上位25件外

まず名前と版をそろえ、同じ粒度で比較する

社内共有前に、スキルやエージェントの設定名と最低クライアント版をそろえます。社内共有後は、企業集計と組織集計、1日と28日、集計とユーザー別を混ぜず、同じ粒度で変化を見ます。名前を途中で変えるとラベルの連続性が分かりにくくなるため、表示名の変更履歴も別に残しておくと安全です。

集計値で活動の広がりを見つけたら、ユーザー別レポートで偏りを確認します。ただし、ユーザー別データは目的を決めて必要な範囲だけ扱います。社外向け資料へ転用する場合は、個人名だけでなく、カスタマイズ名に含まれる内部情報も確認します。

少なく見える前提で、複数期間の傾向を読む

公式ドキュメントは、これらのデータがクライアントテレメトリに依存し、古いクライアントや遮断されたテレメトリなどによって実際より少なく出る可能性を明記しています。名前が配列にない場合も、利用がゼロとは限りません。上位25件の外側、名前を取得できない状態、対象外クライアント、欠けたテレメトリを疑います。

また、IDEテレメトリは非同期で処理され、直近の日は不完全に見える場合があります。GitHubの説明では、データは通常、完全なUTC日で3日以内に確定します。直近日だけが急に下がったときは、すぐに利用低下と判断せず、処理後に再取得してください。詳しくはReconciling Copilot usage metrics across dashboards, APIs, and reportsで確認できます。

利用量と成果を分けて考える

名前別の活動が増えたことは、社内展開が進んだ可能性を示します。しかし、作業時間、品質、レビュー負荷、障害件数などの成果を直接証明する指標ではありません。利用状況の変化を見つけたあと、対象チームの業務指標や振り返り、利用者の声と照合します。

この順序なら、利用が少ない項目をすぐ廃止するのではなく、「対象クライアントが古い」「導線が知られていない」「権限が不足している」「用途が合っていない」といった原因を切り分けられます。反対に活動が多い項目も、MCPの再接続やpluginとskillの重複を除いてから評価できます。

つまずきやすい4つの読み違い

MCPの値をツール呼び出し回数として扱う

❌ totals_by_mcpが多いので、MCPツールがその回数だけ実行されたと判断する。

⭕ 成功・失敗を含む接続と再接続の試行数として読み、ツール利用は別のログや利用者の確認で補います。

pluginとskillを合計して総利用量にする

❌ totals_by_pluginとtotals_by_skillを足し、社内カスタマイズの総利用回数として報告する。

⭕ plugin側はskill側の部分集合なので合算せず、カテゴリごとの傾向として別々に示します。

名前がない項目を未使用と判定する

❌ 名前付き配列に見つからないため、そのエージェントやMCPは誰も使っていないと結論づける。

⭕ 上位25件外、otherまたはcustomへの集約、クライアント版、IDE組み込みチャット、テレメトリ欠落を確認します。

設定名を確認せずレポートを社外共有する

❌ 集計値だけを見て、内部の設定名が含まれた表やグラフをそのまま公開する。

⭕ 顧客名、案件名、内部パス、環境名などが残っていないかを確認し、共有目的に必要なラベルだけへ整理します。

関連する既刊で周辺設定を固める

• CopilotモデルポリシーAPIで一括管理 — 利用状況とは別に、企業・組織・チームのモデル許可をAPIで管理する方法を確認できます。
• CopilotのAgent SkillsとMCPのGA — 今回のAPIで名前が見えるスキル、MCP、Copilot SDKの位置づけを整理できます。
• MCPサーバーの仕組みと接続手順 — 接続、ツール、サーバーの違いを押さえ、利用状況の数字を読み違えないための基礎です。

今回の利用状況APIは「何を許可するか」「何を共有するか」「何が使われたか」のうち、最後の可視化を担います。ポリシー管理やMCPの設計と組み合わせると、管理者が次に確認すべき対象を絞れます。

よくある質問

カスタムエージェントとMCPの名前は何件まで見えますか？

公式Changelogでは、各totals_by_*リストに名前付き項目が1レコード当たり最大25件表示されます。25件を超える活動は末尾のotherへまとめられるため、25件以外が利用ゼロという意味ではありません。末尾のotherは25件とは別に現れる場合があります。

VS CodeやJetBrainsの組み込みチャットでも名前が出ますか？

IDE組み込みのCopilot Chatテレメトリからは、カスタマイズ名は報告されません。一方、ACP連携は対象で、公式はJetBrains AI Assistant内のCopilotを例示しています。IDEで使ったという情報だけで判断せず、組み込みチャット、ACP連携、SDK上のエージェント体験のどれかを確認してください。

誰がCopilot usage metrics APIを見られますか？

Enterprise owner、enterpriseのbilling manager、Organization owner、および対象のカスタムロールを持つ利用者です。REST APIでは、企業向けのView Enterprise Copilot Metrics、組織向けのView Organization Copilot Metricsという範囲別の権限名を確認してください。加えて、Copilot usage metricsポリシーの有効化が必要です。

この更新に追加料金はかかりますか？

2026年10月時点で、この更新または対象APIに固有の追加料金は、今回確認したGitHub公式Changelogと利用状況APIドキュメントでは確認できていません。「追加料金なし」とは断定せず、契約プランと最新のGitHub公式情報を確認してください。

このAPI固有の呼び出し上限はいくつですか？

2026年10月時点で、このエンドポイント固有の呼び出し上限値は対象の公式ドキュメントで確認できていません。一般的なGitHub REST APIの上限値を、この機能固有の値として書き換えないでください。

レポートの保存期間はどのくらいですか？

2026年10月時点で、企業・組織と全レポート形式に共通する保存期間は公式に確認できていません。企業の一部の1日レポートについては最大1年の履歴に関する記載がありますが、すべての範囲へ一般化できません。また、署名付きダウンロードURLの具体的な有効時間も公式ページでは確認できていません。

名前別の数字を許可外MCPの完全監査に使えますか？

使えません。クライアントテレメトリの欠落、対象外クライアント、上位25件の上限、パス風名称の集約などがあるためです。GitHubも、傾向と普及の把握に使い、正確な会計や完全な利用監査には使わないよう説明しています。許可状況は構成管理、アクセス制御、接続ログなど別の管理手段で確認してください。

ここまでの要点

• 2026年10月22日の更新で、自社のスキル、カスタムエージェント、MCP、スラッシュコマンド、プラグインを設定名で確認できるようになりました。
• 名前付き項目は各配列で最大25件です。残りは末尾のotherへ入り、過去レポートは自動で名前表示へ変わりません。
• prompt mode、Copilotアプリ、ACP連携はCopilot CLI 1.0.97以降、SDKはv1.0.21以降が条件です。IDE組み込みチャットから名前は出ません。
• 閲覧には対象ロールとCopilot usage metricsポリシーが必要です。APIは署名付きdownload_linksを返します。
• MCPは接続試行、agentは開始、skillは呼び出しを数えます。pluginとskillは合算せず、distinctをユーザー数として扱いません。
• テレメトリの欠落を前提に、同じ粒度の複数期間で傾向を追い、業務成果や利用者の声と組み合わせて判断します。

管理者が最初に行う作業は、設定名とクライアント版を確認し、ポリシーと閲覧権限をそろえ、集計1日レポートを1件取得することです。そこで5つの配列が出るかを確認してから、ユーザー別や28日のレポートへ広げると、権限不足と計測不足を分けて調べられます。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• Custom skills, agents, and MCP servers in usage metrics API — GitHub Changelog、2026年10月22日公開（参照日: 2026年10月24日）
• Agentic CLI customizations now in the usage metrics API — GitHub Changelog、2026年9月17日公開（参照日: 2026年10月24日）
• REST API endpoints for Copilot usage metrics — GitHub Docs（参照日: 2026年10月24日）
• Data available in Copilot usage metrics — GitHub Docs（参照日: 2026年10月24日）
• Interpreting usage and adoption metrics for GitHub Copilot — GitHub Docs（参照日: 2026年10月24日）
• Reconciling Copilot usage metrics across dashboards, APIs, and reports — GitHub Docs（参照日: 2026年10月24日）
• Managing policies and features for GitHub Copilot in your enterprise — GitHub Docs（参照日: 2026年10月24日）
• Managing policies and features for GitHub Copilot in your organization — GitHub Docs（参照日: 2026年10月24日）

この記事はAIgent Lab編集部がお届けしました。

このテーマの関連記事

• ▸ Copilot Fusionとは｜正式版の料金・使い方・設定【2026年10月】
• ▸ 【速報】ChatGPT API無料クレジット月最大500ドル
• ▸ ConoHa AI Canvasの料金・使い方｜申し込める？【2026年10月】
• ▸ GPT-6.1 Terra API｜移行手順・画面操作・料金【2026年10月】
• ▸ LiteLLM 1.107.0改ざん｜確かめ方と取り替える鍵【2026年10月】