GitHub Copilot appの利用状況を管理側で追いたくても、これまでは企業全体の合計値しか見えず、『誰が使っているのか』『どのモデルや言語で成果が出ているのか』までは追いにくい状態でした。2026年7月28日のGitHub公式更新で、この弱点がかなり埋まりました。今回の変更は、Copilot appをPoCで終わらせず、本番運用に移す企業ほど効きます。
結論: Copilot appの利用実態をユーザー別に追えるようになった
今回の更新の要点は3つです。第一に、Copilot appの利用がenterprise-userとorganization-userのレポートで個人単位に帰属されるようになりました。第二に、Copilot appのコーディング活動がfeature、model、languageの各ロールアップに入るようになり、IDEやchat、code review、coding agentと同じ土俵で比較できます。第三に、daily_active_usersやコード生成・受け入れ・追加/削除行数の集計にもCopilot appが反映されるため、導入効果を『別物』扱いせずに追跡できます。
新しく見える主要フィールド
GitHub changelogと公式Docsで明示された追加項目の中でも、実務でまず見るべきなのは `used_copilot_app` と `totals_by_copilot_app` です。`used_copilot_app` は、その日に対象ユーザーがCopilot appを使ったかを真偽値で返します。`totals_by_copilot_app` では、session_count、request_count、prompt_countに加え、output_tokens_sum、prompt_tokens_sum、avg_tokens_per_requestまで取れます。つまり『ログインしただけ』ではなく、『何回使い、どれくらいのトークンを消費したか』まで追える設計です。
さらに `copilot_app` というfeature値が totals_by_feature、totals_by_model_feature、totals_by_language_feature、totals_by_language_model に入るため、『Copilot appではどのモデルが多いか』『どの言語タスクが多いか』を横並びで把握できます。管理会計の観点では、app経由の試行が増えているのに成果が出ていない部門を見つけやすくなる点が大きいです。
どのレポートで確認できるか
個人単位の `used_copilot_app` と `totals_by_copilot_app` は、enterprise-user / organization-user の1日レポートと28日レポートで利用できます。一方、`copilot_app` のfeature値や、コード生成・受け入れ・lines of code・daily_active_usersへの反映は、enterprise、organization、user の各レポートで1日・28日ウィンドウの両方に適用されます。『個人を見たいのか』『組織全体を見たいのか』で取るレポートが違うので、監査フローに組み込む前に用途を分けるのが安全です。
確認前に外せない前提条件
この指標は誰でも見られるわけではありません。GitHub Docsでは、enterprise owners、organization administrators、billing managers、または `View Enterprise Copilot Metrics` 権限を持つカスタムロールが対象です。さらに、enterprise全体で『Copilot usage metrics』ポリシーが有効化されていないとAPIは使えません。API側では enterpriseスコープ取得に `manage_billing:copilot` または `read:enterprise` が必要なケースもあるため、情シスと請求管理の担当が分かれている会社は権限棚卸しを先にやるべきです。
運用で最初に見るべき3つの観点
1つ目は採用状況です。daily_active_usersにCopilot app専用ユーザーも含まれるようになったので、IDE利用者だけを追っていた時より導入母数を正しく見積もれます。2つ目は深さです。session_countに対してprompt_countやrequest_countが薄い場合、触って終わるユーザーが多いと判断できます。3つ目はコスト密度です。avg_tokens_per_request が急増しているのに、コード受け入れやloc_added_sumが伸びていないなら、使い方や対象業務の見直し候補です。
導入判断にどう効くか
今回の拡張で、Copilot appを『面白い新機能』ではなく『比較可能な運用面』として扱いやすくなりました。たとえば、同じCopilotライセンスでも、IDE中心チームとCopilot app中心チームでモデル利用やコード増減の傾向を比較し、どちらが成果につながっているかを判断できます。PoC段階では利用者数、展開段階では部門差、本番段階ではトークン効率とコード受け入れ率を併せて見ると、次の投資判断がしやすくなります。
FAQ
Q. 既存の集計を壊さずに使えますか。A. GitHubは後方互換性を維持すると案内しており、Copilot app利用がないユーザーや組織では `totals_by_copilot_app` が省略され、既存フィールドの形は維持されます。Q. チーム単位で見られますか。A. チーム集計は事前集約されておらず、user-teamsレポートとper-user usage metricsレポートの結合が前提です。Q. ダッシュボードだけで足りますか。A. 継続監査まで行くなら、signed URLで取得する日次/28日レポートを保存して差分を追う運用が向いています。
こんな会社は今週中に確認したい
Copilot appを一部の先行チームで試している企業、利用実績を稟議材料にしたい情報システム部門、AI creditsや請求差分を追い始めた経理・IT管理者は、今回の更新を見逃しにくいテーマです。特に『誰が使ったか分からないので展開判断できない』という状態は、今回のユーザー帰属追加で解消しやすくなりました。まずは28日レポートを一度取得し、app利用者の分布とトークン密度を可視化するところから始めるのが現実的です。
Copilot運用の相談はこちら 。現状の利用データから、見るべき指標と運用ルールを一緒に設計できます。
