2026年4月2日の GitHub Changelog で、GitHub Copilot CLI の活動が organization reports の per-user metrics に入り、組織管理者は 1-day / 28-day レポートで各ユーザーの CLI 利用有無、セッション数、リクエスト数、トークン使用量、平均トークン数、さらに最後に使われた CLI バージョンまで追えるようになりました。これで「CLI は使われていそうだが、誰がどこまで使っているのか分からない」という状態はかなり解消されます。 (The GitHub Blog)
管理の観点でいちばん重要なのは、今回の見える化が ダッシュボードではなくレポート/API 側で進んだ ことです。GitHub Docs では Copilot usage dashboard のチャートは CLI usage を含まないと明記されているため、GitHub Enterprise で定着管理やコスト可視化をしたいなら、ダッシュボードだけ見ても判断を誤ります。 (GitHub Docs)
GitHub Copilot CLI の利用状況はどこまで見えるようになったか
今回の変更は、GitHub が 2026年2月末以降に段階的に追加してきた CLI メトリクスの流れの中で、組織レポートにおけるユーザー単位の内訳 を埋めるものです。4月2日の changelog では、organization admins が 1-day と 28-day の両レポートで、どのユーザーが CLI を使っているかと、その詳細を確認できるようになったと案内されています。 (The GitHub Blog)
| 確認場所 | CLI の個人別可視化 | 向いている用途 |
|---|---|---|
| Copilot usage dashboard | できない | IDE 中心の全体傾向を見る |
users-1-day レポート | できる | 施策後の短期変化を見る |
users-28-day/latest レポート | できる | 定着度、偏在、バージョン分布を見る |
今回の per-user CLI metrics で見える主な項目は、used_cli、session_count、request_count、token_usage、avg_tokens_per_request、last_known_cli_version です。個人別レポートと組織全体の aggregate report を分けて見ることで、「誰が使っているか」と「組織全体でどれだけ使われているか」を混同せずに運用できます。 (The GitHub Blog)
GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/users-28-day/latestorganization users usage metrics の API は、ユーザー単位の詳細データを返すのではなく、期限付きの署名付き download link を返します。運用では「リンクを保存する」のではなく、「取得したらすぐファイルを保存する」前提で考えるのが安全です。 (GitHub Docs)
per-user metrics は管理をどう変える？
使っている人と、まだ使えていない人を分けて打てる
GitHub 自身も、今回の変更の価値を「CLI を実際に使っている開発者を特定し、enablement が必要な場所を見つけること」に置いています。運用上は used_cli と session_count を見るだけでも、IDE では Copilot を使っているのに CLI までは入っていない人を切り分けやすくなります。 (The GitHub Blog)
| パターン | どう読むか | 次の打ち手 |
|---|---|---|
used_cli = false | CLI 入口まで届いていない | CLI 用の導入手順、ユースケース集、ハンズオンを出す |
session_count が少ない | 触り始めた段階 | よく使うコマンド例や社内テンプレを渡す |
request_count と token 使用量が高い | 実務に乗っている | 使い方を横展開し、成功例として共有する |
last_known_cli_version が古い | 更新が止まっている | バージョンアップ案内を出す |
ポイントは、全員に同じ施策を打たなくてよくなる ことです。これまでは「CLI を広めたい」と言っても対象者が曖昧になりがちでしたが、per-user metrics があれば、未着手・試用・定着・更新遅れを分けて動けます。これは管理の効率だけでなく、現場側の摩擦も減らします。 (The GitHub Blog)
コスト可視化は「消費量」だけでなく「広がり」とセットで見る
今回の changelog では、トークン使用量や平均トークン数が cost allocation や rollout planning に役立つと明示されています。ただし、実務では token 使用量だけで評価しない方が安全です。GitHub Docs も、メトリクスは単独の数字ではなく、複数のシグナルを組み合わせて読むべきだと説明しています。 (The GitHub Blog)
たとえば、token 使用量が高いユーザーがいても、それが「少数の先行ユーザーが深く使っている」のか、「広いチームで毎日軽く使われている」のかでは、打つべき施策が変わります。前者ならベストプラクティスの標準化、後者なら利用ルールやプロンプト例の整備が効きやすい、という読み方です。28-day レポートはこの見極めに向いています。 (GitHub Docs)
なお、usage metrics はライセンス割り当ての source of truth ではありません。GitHub Docs でも、seat 情報は Copilot user management API 側が正とされ、activity report では last_activity_at や last_surface_used を確認できます。ライセンス回収や再配分を決めるなら、usage metrics だけでなく、seat 情報と activity report を合わせるのが実務的です。 (GitHub Docs)
CLI のバージョン統制まで回しやすくなる
見落としがちですが、last_known_cli_version が per-user で見えるのはかなり大きい変化です。GitHub も、この項目は upgrade rollout の計画に役立つと説明しています。CLI は「とりあえず入れたが更新は各自任せ」という状態になりやすいため、古いバージョン利用者をまとめて抽出できるだけでも、サポート負荷は下げやすくなります。 (The GitHub Blog)
導入効果をどう測る？
GitHub Docs では、Copilot のメトリクスは「継続利用されているか」「どの機能が価値を出しているか」「enablement が効いているか」といった問いに答えるために組み合わせて使うものだと説明しています。Trial の測定ガイドでも、採用・活用・満足度を分けて見る考え方が示されています。 (GitHub Docs)
| 知りたいこと | 主に見るレポート | 主指標 | 判断のコツ |
|---|---|---|---|
| 研修後に使い始めたか | users-1-day | used_cli, session_count | 対象者数に対する利用者の増加を見る |
| 使い続けているか | users-28-day/latest | session_count, request_count | 一部の人だけでなく分布を見る |
| コストが偏っていないか | users-28-day/latest | token 使用量, 平均 tokens/request | ヘビーユーザー依存かどうかを見る |
| 更新が進んでいるか | users-28-day/latest | last_known_cli_version | 古い版の人数推移で見る |
1-day と 28-day は役割が違います。GitHub Docs では、ダッシュボードは 28日ローリング、API は 日次単位、レポートは日ごとに生成され、データはその日が UTC で締まってから 2 full days 以内 に利用可能になると案内されています。つまり、勉強会の翌朝に見て判断するのではなく、翌々日以降に 1-day を確認し、月次判断は 28-day で行う のが基本です。 (GitHub Docs)
定量だけで終わらせないのも大事です。GitHub の trial ガイドでも、usage metrics に加えて team survey や internal feedback を組み合わせるよう勧めています。CLI では特に「どの作業で時短になったか」「どこでハマったか」を一言でも集めると、単なる利用数よりも横展開しやすい運用知見が残ります。 (GitHub Docs)
レポート運用の実際
継続運用するなら、レポート取得は手作業より API ベースに寄せた方が安定します。GitHub Docs でも、新しい連携や分析には Copilot usage metrics API を使うことを強く勧めています。また、enterprise 全体の権限を渡さなくても、organization custom role に View organization Copilot metrics を含めれば、単一組織だけの可視性を与えられます。AI 推進担当や開発生産性チームに最小権限で見せたいときに有効です。 (GitHub Docs)
GET /orgs/{org}/copilot/metrics/reports/organization-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/organization-28-day/latest
GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=YYYY-MM-DD
GET /orgs/{org}/copilot/metrics/reports/users-28-day/latest実運用では、組織全体の aggregate report と個人別 report を同じタイミングで取得し、社内 BI やスプレッドシート側で突合すると使いやすくなります。前者で「総量」を見て、後者で「偏在」を見れば、CLI が定着しているのか、一部の上級者に寄っているのかを短時間で判断できます。API が返すリンクは期限付きなので、スケジュールジョブで即ダウンロードして保管する設計にしておくのが無難です。 (GitHub Docs)
レポート運用で外しやすいポイント
- ダッシュボードに CLI が出ないから未利用だと決めつける
Copilot usage dashboard のチャートは CLI usage を含みません。CLI の浸透度を見たいなら、users report を見る前提に切り替える必要があります。 (GitHub Docs) - 組織レポートと enterprise 合計を単純比較する
organization-level metrics は「どこで使ったか」ではなく「どの organization に所属しているか」で帰属します。そのため、同じユーザーが複数 organization に現れる一方、enterprise total では重複排除されます。直接比較用の数字ではありません。 (GitHub Docs) - 施策の翌日に数字が出ると思う
usage metrics は日次処理で、対象日の終了後 2 full UTC days 以内に利用可能になります。短期施策の効果を見るときほど、この遅延を前提に観測日を設計した方が失敗しません。 (GitHub Docs) - usage metrics だけで seat 回収を決める
usage metrics は使用状況を見るデータで、seat 割り当ての正本ではありません。ライセンスの見直しは user management や activity report のlast_activity_atと併用した方が安全です。 (GitHub Docs) - 長期比較がそのままできると思う
GitHub Docs では、organization-level analytics の提供開始日は 2025年12月12日とされています。現時点で長期比較を設計するなら、期間不足で折れ線が短くなる前提を置いておくべきです。 (GitHub Docs)
まず何をやるべきか
- まず
users-28-day/latestを取得し、利用者分布・ token 偏在・ CLI バージョン分布 のベースラインを作ります。これがないと、施策後に「増えたのか、もともと一部が使っていただけなのか」を判定できません。 (GitHub Docs) - 次に、勉強会や runbook 配布のあとに
users-1-dayを定点取得し、使い始めた人 と まだ入口にいない人 を分けます。短期反応は 1-day、定着は 28-day と役割を分けると、施策評価がぶれにくくなります。 (GitHub Docs) - 最後に、activity report と seat 情報を突合し、enablement 対象・ upgrade 対象・ seat 見直し候補 の3群に分けて運用します。ここまでやると、per-user metrics は単なる可視化ではなく、実際にアクションにつながる管理データになります。 (GitHub Docs)
GitHub Copilot CLI の per-user metrics が本当に価値を持つのは、「見えた」こと自体ではなく、誰に何を打つべきかを個人単位で決められる ようになった点です。GitHub Enterprise で Copilot の定着管理を進めるなら、ダッシュボードを見るだけで終わらせず、users report と activity report を運用フローに組み込むところから始めるのが最短です。 (The GitHub Blog)
コメント