GitHub は2026年4月10日、GitHub Copilot の使用状況メトリクス API で、Copilot クラウド エージェントのアクティブ ユーザー数を enterprise / organization レポートに集約する更新を公開しました。結論からいうと、管理者はクラウド エージェントの利用人数を日次・週次・直近28日で把握しやすくなり、これまで必要だったユーザー単位データの手集計をかなり減らせます。ただし、この数値は IDE の agent mode 指標とは別物で、ダッシュボードと API も同じ条件では集計されません。 (The GitHub Blog)
この記事では、新しいフィールドの意味、Copilot 導入レポートで何が変わるのか、社内 BI や管理レポートをどう直すべきか、実務でつまずきやすい点までまとめて整理します。
2026年4月10日の更新内容
今回追加されたのは、daily_active_copilot_cloud_agent_users、weekly_active_copilot_cloud_agent_users、monthly_active_copilot_cloud_agent_users の3項目です。対象は enterprise / organization レベルの 1-day report と 28-day report で、クラウド エージェントを使ったユニーク ユーザー数をそのまま見られるようになりました。なお monthly という名前ですが、定義は「直近28日」です。 (The GitHub Blog)
| フィールド | 何を表すか | 実務での使いどころ |
|---|---|---|
daily_active_copilot_cloud_agent_users | その日にクラウド エージェントを使った人数 | 研修・周知・機能公開の直後に反応が出たかを見る |
weekly_active_copilot_cloud_agent_users | 直近7日で使った人数 | 単発利用ではなく、継続的に触られているかを見る |
monthly_active_copilot_cloud_agent_users | 直近28日で使った人数 | 月次の導入広がりを俯瞰する |
この整理は GitHub の 2026年4月10日付 changelog に基づきます。 (The GitHub Blog)
さらに重要なのが、GitHub が「Copilot coding agent」を「Copilot cloud agent」へ改称しており、既存の coding agent 系フィールドも今後数週間で名称更新される予定だという点です。新規フィールドはすでに cloud agent 名義ですが、既存の社内 SQL やダッシュボードで coding_agent を前提にしていると、追って見直しが必要になります。 (The GitHub Blog)
Copilot 導入レポートはどう変わるのか
今回の更新を理解するには、3月25日の変更とセットで見るのが分かりやすいです。3月25日時点では、ユーザー単位レポートに used_copilot_coding_agent が追加され、Issue に Copilot を割り当てた、あるいは pull request コメントで @copilot を使った、といったクラウド エージェント利用者を判別できるようになっていました。つまり「誰が使ったか」は追えましたが、「今月何人が使ったか」は自分で集計する必要がありました。4月10日の更新で、その人数集計が enterprise / organization レポート側に入った、というのが本質です。 (The GitHub Blog)
| 4月9日まで | 4月10日以降 |
|---|---|
ユーザー単位の used_copilot_coding_agent を見て、自前で人数集計する必要があった | enterprise / organization レポートに集約済み人数が入り、日次・週次・直近28日でそのまま見られる |
| 「誰が使ったか」は分かるが、「何人が使ったか」は BI 側の処理が必要だった | 「誰が使ったか」と「何人が使ったか」をレイヤー分けして見られる |
| レポートのたびにロジック確認が必要だった | 標準フィールドとして継続監視しやすくなった |
この整理は 3月25日と 4月10日の GitHub changelog に基づきます。 (The GitHub Blog)
しかも新しい人数指標は、既存の monthly_active_agent_users（IDE の agent mode 側）や、クラウド エージェント作成 PR の作成数・マージ数・マージまでの時間といった pull request ライフサイクル指標と並べて読めます。つまり、利用人数 と 成果物ベースの効果 を別々に追えるようになったわけです。 (The GitHub Blog)
クラウド エージェントと IDE の agent mode を混同しない
ここはレポート解釈で最も間違えやすいポイントです。Copilot クラウド エージェントは GitHub 上で自律的に動き、GitHub Actions ベースの一時的な開発環境でコード変更やテスト、Lint 実行まで進められる仕組みです。一方、IDE の agent mode はローカル開発環境の中で使う機能です。GitHub も 3月25日と 4月10日の告知で、used_agent や monthly_active_agent_users と、used_copilot_coding_agent / 新しい cloud agent 集計は別物として扱っています。 (GitHub Docs)
この違いを意識すると、レポートの読み方が変わります。たとえば IDE 側の agent mode 指標だけ伸びているなら、「開発者は IDE 内の高度機能を使い始めたが、Issue や PR ベースで仕事を委譲する運用までは広がっていない」と読めます。逆にクラウド エージェントの人数だけが伸びるなら、「GitHub 上でのタスク委譲は進んでいるが、IDE 側の agent mode 定着はこれから」と判断しやすくなります。
管理者がいま見るべき指標
GitHub Copilot のメトリクスは、API、usage dashboard、code generation dashboard、NDJSON export で使い分けられます。GitHub 自身も、新しい連携や分析には Copilot usage metrics API を強く推奨しています。今回のクラウド エージェント利用人数は API / レポート側の強化なので、社内 BI や定例レポートに組み込むなら API 起点で考えるのが自然です。 (GitHub Docs)
人数だけ見て終わると、「試しただけ」で止まっている状況を見逃します。新フィールドは、次のように置くとレポートが実務寄りになります。
| 追いたいこと | まず見る値 | 実務での見方 |
|---|---|---|
| 導入の広がり | monthly_active_copilot_cloud_agent_users | 直近28日で何人が一度でも使ったか。PoC や試験導入では、絶対値より増加傾向を見る |
| 定着 | weekly_active_copilot_cloud_agent_users と monthly_active_copilot_cloud_agent_users の関係 | 単発利用で終わっていないかを確認する |
| 短期施策の反応 | daily_active_copilot_cloud_agent_users | 研修、ガイド公開、サンプル Issue 配布の直後に変化が出たかを見る |
| 成果への接続 | pull_requests.total_created_by_copilot、pull_requests.total_merged_created_by_copilot、pull_requests.median_minutes_to_merge_copilot_authored | 利用人数が、実際の PR 成果やリードタイム改善につながっているかを見る |
フィールド名と PR 系メトリクスは GitHub の changelog / Docs に基づくもので、表の「どう見るか」は実務向けの運用例です。 (The GitHub Blog)
さらに、4月8日には Copilot code review が関与した pull request のマージ指標も usage metrics API に追加されています。クラウド エージェントの利用人数だけでなく、「Copilot が作る」「Copilot がレビューする」まで一連で見たいなら、この PR レビュー側メトリクスも一緒に見ると、導入レポートがかなり実態に近づきます。 (The GitHub Blog)
レポート運用で失敗しやすいポイント
クラウド エージェントの人数指標は便利ですが、そのまま貼るだけだと誤読が起きます。特に次の点は先にルール化しておくと安全です。
| よくある誤読 | 実際の意味 | 実務での対応 |
|---|---|---|
null と 0 を同じに扱う | 0 は「データがあり利用者ゼロ」、null は「その期間にクラウド エージェント データが存在しない」 | BI では別カテゴリで扱い、安易に 0 補完しない |
monthly を暦月だと思い込む | 今回の cloud agent の monthly は直近28日 | 月次比較では「カレンダー月」と「直近28日」を混ぜない |
monthly_active_agent_users を cloud agent 利用人数だと考える | それは IDE の agent mode 側 | cloud agent と IDE agent を別 KPI にする |
| ダッシュボードと API は同じ値のはずだと考える | ダッシュボードは 28日ローリング中心で、IDE テレメトリ前提。API / export は日次集計もあり、最近の日付は遅延差が出る | 直比較せず、比較するときは 28日窓にそろえる |
| organization 合計を足せば enterprise 合計になると思う | 組織指標は organization membership ベースで、同じユーザーが複数 organization に現れることがある | enterprise 総数と organization 総数は別物として扱う |
| 4月10日以降の totals 増加を cloud agent だけの影響だと思う | 同日、CLI 活動が top-level totals に統合され、既存 totals の意味も変わった | 4月10日を境に、既存 totals の定義変更も注記する |
このあたりは 4月10日の cloud agent / CLI 変更、usage dashboard と API の集計差、そして enterprise / organization の帰属ルールに関する GitHub Docs と changelog に明記されています。 (The GitHub Blog)
特に、同じ 4月10日に CLI 活動が top-level totals や totals_by_feature に統合されたのは見落としやすい点です。社内で「4月10日以降に利用が急増した」と見えたとき、それがクラウド エージェント人数の増加なのか、CLI を含む totals の定義変更なのかを分けて確認しないと、施策評価を誤ります。 (The GitHub Blog)
社内 BI と管理レポートを更新するときのチェックリスト
最低限やること
- semantic layer や ETL に
daily_active_copilot_cloud_agent_users、weekly_active_copilot_cloud_agent_users、monthly_active_copilot_cloud_agent_usersを追加し、既存のcoding_agent命名前提ロジックも棚卸しします。GitHub は既存 coding agent 系フィールドの名称更新を今後数週間で進める予定です。 (The GitHub Blog) nullを自動で 0 に変換しないようにします。今回の changelog では、0 は「値ありのゼロ」、nullは「その期間にクラウド エージェント データなし」と明記されています。 (The GitHub Blog)- 比較用の集計は、少なくとも UTC 基準で 2〜3日以上経過した日付を使います。GitHub Docs では API / dashboard のデータ反映に時差があり、dashboard は最大3日遅れうると案内されています。 (GitHub Docs)
- dashboard と API を並べるときは、日次値をそのまま見比べず、できるだけ 28日窓にそろえます。GitHub Docs でも dashboard は 28日ローリング、API / NDJSON は日次記録として説明されています。 (GitHub Docs)
- organization レポートの合計を enterprise 総数として流用しないようにします。GitHub Docs では、organization 指標は membership ベースで、1人の利用が複数 organization に現れる場合があると説明されています。 (GitHub Docs)
- 新しいダッシュボードや連携を作るなら、GitHub が推奨する Copilot usage metrics API を基準にします。Docs では、この API が最も完全で今後も発展する主要リソースと位置付けられています。 (GitHub Docs)
- UI で確認する場合は、enterprise なら
InsightsからCopilot usage、コード生成はCode generationに進みます。まず可視化で傾向を見て、詳細分析は API / export に寄せる運用が扱いやすいです。 (GitHub Docs) - メトリクスを見られない場合は、
Copilot usage metricsポリシーや、enterprise / organization の Copilot metrics 読み取り権限を確認します。API も enterprise / organization ごとの read 権限前提です。 (GitHub Docs)
まとめ
今回の 2026年4月10日の更新は、単なる項目追加ではありません。GitHub Copilot の導入レポートで、クラウド エージェント利用者数を enterprise / organization レベルでそのまま見られるようになったことで、これまでの「誰が使ったか」中心の分析から、「何人が使い、その結果 PR 成果までつながっているか」を追う運用へ進めやすくなりました。まずは新しい3フィールドを BI に追加し、null と 0 を分け、IDE の agent mode と cloud agent を別指標として扱い、4月10日同日の CLI totals 変更も注記しておくのが実務上の第一歩です。新規のレポート基盤を作るなら、GitHub が推奨する Copilot usage metrics API を中心に設計すると運用がぶれにくくなります。 (The GitHub Blog)
コメント