GitHub Copilot usage metrics APIの今回の更新は、単に「誰がCopilotを使っているか」を数えるだけでなく、「どの段階までAI活用が進んでいるか」を把握できるようにする変更です。管理者にとっては、Copilotの導入率、エージェント活用、チーム別の定着状況を説明しやすくなります。一方で、既存のBI連携やETL処理では、新しいフィールドを取り込めるようにスキーマや集計ロジックの確認が必要です。
結論から言うと、GitHub Copilotを使う開発者側にすぐ必要な操作は多くありません。ただし、Enterprise管理者、Organization owner、Copilot利用状況をDWHやBIに取り込んでいる担当者は、ai_adoption_phaseとtotals_by_ai_adoption_phaseを前提に、レポート設計を見直す価値があります。GitHub公式Changelogでは、ユーザー単位レポートにai_adoption_phase、Enterprise/Organization単位レポートにtotals_by_ai_adoption_phaseが追加されたと説明されています。(The GitHub Blog)
GitHubのAI/Copilot更新で何が変わるのか
今回の「Copilot usage metrics API adds cohorts for AI adoption」は、GitHub Copilotの利用メトリクスにAI adoption cohort、つまりAI活用段階ごとの分類を追加する更新です。
従来のCopilot利用分析では、アクティブユーザー数、コード補完の提案数・受け入れ数、チャット利用、IDEや言語別の利用状況などを見るのが中心でした。これだけでも導入状況は分かりますが、「補完だけを使っているのか」「Copilot CLIやcode reviewなどのエージェント系機能まで使っているのか」は、別途集計しないと説明しにくい状態でした。
今回の更新により、Copilot usage metrics APIは、直近28日間のCopilot製品利用をもとに、各エンゲージ済みユーザーをAI活用フェーズに分類します。判定には「過去28日間で少なくとも2日利用したCopilotの利用面」が使われます。1回だけ試したユーザーをすぐ高度な活用者として扱わない点が、実務上は重要です。(The GitHub Blog)
追加されたAI adoption phaseの意味
AI adoption phaseは、Copilotの使い方を4段階に分けて見るための分類です。GitHubの説明では、各ユーザーは以下のいずれかのフェーズに割り当てられます。(The GitHub Blog)
| フェーズ | 名称 | 判定の概要 | 実務での見方 |
|---|---|---|---|
| Phase 0 | No cohort | どのフェーズのエンゲージメント条件も満たしていない | ライセンス付与済みでも、利用が定着していない可能性がある |
| Phase 1 | Code first | コード補完、またはIDE agent modeを利用 | IDE内の開発支援としてCopilotを使い始めている段階 |
| Phase 2 | Agent first | Copilot cloud agent、Copilot code review、Copilot CLIなど、GitHubベースのエージェント系機能を1種類利用 | 補完中心から、タスク実行・レビュー・CLI支援へ広がり始めている段階 |
| Phase 3 | Multi-agent | GitHubベースのエージェント系機能を2種類以上利用、または新しいGitHub Copilot appを利用 | 複数のCopilot機能を組み合わせ、開発フロー全体でAIを使い始めている段階 |
ここで注意したいのは、Phase 3が必ず「優秀な開発者」や「最も生産性が高い状態」を意味するわけではないことです。これはあくまでCopilotの利用面の広がりを示す分類です。
たとえば、基幹システムの保守チームではコード補完とチャットだけで十分な場合があります。一方、新規開発や移行プロジェクトでは、Copilot CLI、code review、cloud agentを組み合わせるほうが効果を出しやすいことがあります。フェーズは順位ではなく、活用パターンとして読むべきです。
APIレスポンスで増える主な項目
今回の更新で重要なのは、ユーザー単位と集計単位の両方に新しい情報が追加される点です。
ユーザー単位レポートには、各ユーザーのAI活用段階を示すai_adoption_phaseが追加されます。また、EnterpriseまたはOrganization単位のレポートでは、フェーズ別に集計したtotals_by_ai_adoption_phaseが追加されます。GitHubは、ai_adoption_phaseにversionフィールドを持たせ、Copilotの機能面が増えても分類ロジックを進化させられるようにすると説明しています。(The GitHub Blog)
Enterprise/Organization単位のtotals_by_ai_adoption_phaseでは、フェーズごとに次のような指標を見られます。
| 指標の種類 | 何を見るためのものか |
|---|---|
| Total engaged users | フェーズごとにエンゲージしているユーザー数を見る |
| User-initiated interaction average | ユーザーが明示的にCopilotへ送った操作やプロンプトの平均を見る |
| Code generation / acceptance activity averages | 生成されたコードと受け入れられたコードの活動量を見る |
| Lines of code added / deleted averages | Copilotを通じた追加・削除行数の傾向を見る |
| Pull requests created / merged / reviewed averages | PR作成、マージ、レビューへの関与を見る |
| Median time-to-merge average | PRがマージされるまでの時間の傾向を見る |
特に間違えやすいのは、集計値が「フェーズ内の合計」ではなく、フェーズ内ユーザーあたりの平均として扱われる点です。たとえば、Phase 1のユーザー数が多いからといって、単純にPhase 1の総コード生成量が最大とは限りません。GitHubも、集計メトリクスは各フェーズ内のユーザーあたり平均であり、合計ではないと明記しています。(The GitHub Blog)
影響を受ける範囲
今回の更新で影響を受けるのは、主にCopilot利用状況を管理・分析する立場のユーザーです。
Enterprise管理者とOrganization owner
EnterpriseやOrganization全体でCopilotの導入状況を見ている管理者は、これまでよりも説明力のあるレポートを作れるようになります。
たとえば、単に「今月のアクティブユーザーは増えた」と報告するのではなく、次のように説明できます。
「アクティブユーザーは増えているが、ほとんどがPhase 1に集中している。次はcode reviewやCopilot CLIを使った実務研修を行う」
「Phase 2のユーザーは増えているが、median time-to-mergeが改善していない。AI活用よりもレビュー待ちや承認フローがボトルネックになっている可能性がある」
「Phase 3のユーザーは少ないが、PR作成・レビュー活動が高い。該当チームの使い方を横展開する」
このように、導入率だけでなく、Copilotが開発プロセスのどこまで入り込んでいるかを説明しやすくなります。
BI・データ基盤担当者
Copilot usage metrics APIをDWH、データレイク、BIツールに取り込んでいる場合は、新しいフィールドに対応する必要があります。
既存のJSONパーサーやETL処理が未知のフィールドを無視できる設計なら、大きな問題は起きにくいでしょう。一方、固定スキーマで厳密にバリデーションしている場合、ai_adoption_phaseやtotals_by_ai_adoption_phaseの追加により、取り込みエラーや列不足が起きる可能性があります。
対応としては、まずRawデータをそのまま保存し、その後に集計用テーブルへ展開する二段構えが安全です。特にversionを保持しておけば、今後フェーズ分類のロジックが変わった場合でも、過去データとの比較条件を明示できます。
一般の開発者
通常の開発者は、今回のAPI更新によって日々のCopilot操作を変える必要は基本的にありません。
ただし、組織がCopilot活用度を可視化するようになると、「自分がどの機能を使っているか」がレポート上の傾向として見られる可能性があります。これは個人評価のためではなく、導入支援やトレーニング設計に使うべき情報です。管理者は、メトリクスを個人の監視やランキングに使うのではなく、チーム単位の改善材料として扱う方針を明確にしておくべきです。
確認すべき設定・権限
Copilot usage metrics APIを利用するには、前提となるポリシーと権限を確認する必要があります。GitHub Docsでは、Enterpriseでこのエンドポイントを有効にするには「Copilot usage metrics」ポリシーをEnterprise全体でEnabledにする必要があると説明されています。(GitHub Docs)
| 確認項目 | 管理者が見るべきポイント | 放置した場合の症状 |
|---|---|---|
| Copilot usage metricsポリシー | Enterprise全体で有効になっているか | APIを呼び出しても権限エラーやデータ不足になる |
| APIアクセス権限 | Enterprise Copilot metrics、Organization Copilot metricsのread権限を持っているか | 403 Forbiddenになる |
| APIバージョン | X-GitHub-Api-Versionヘッダーを明示しているか | 将来の挙動差分を追いにくくなる |
| レポート取得方式 | APIレスポンスのdownload_linksからNDJSONを取得する処理になっているか | レスポンス本体に明細データがある前提の実装で失敗する |
| ETLスキーマ | 新しいフィールドをnullableまたはJSONとして受けられるか | スキーマ不一致で取り込みに失敗する |
| IDEテレメトリ | IDEベースのメトリクス取得に必要な設定が無効化されていないか | 実際より利用が少なく見える |
| チーム別集計 | user-teams reportとper-user usage reportを正しく結合しているか | チーム単位の数字が過大・過小になる |
GitHub Docsでは、Copilot usage metrics APIのレポートは、REST API呼び出しで直接全データを返すのではなく、期限付きの署名付きURLを返し、そこからNDJSONファイルをダウンロードする流れが説明されています。(GitHub Docs)
API連携で確認したいエンドポイント
組織単位で最新28日間のCopilot利用状況を確認する場合は、OrganizationまたはEnterprise向けの28日間レポートを使います。GitHub Docsでは、Organization向けの最新28日間レポートとして次のようなエンドポイントが示されています。(GitHub Docs)
GET /orgs/{org}/copilot/metrics/reports/organization-28-day/latestユーザー単位の28日間レポートをEnterpriseで取得する場合は、次のようなエンドポイントを確認します。(GitHub Docs)
GET /enterprises/{enterprise}/copilot/metrics/reports/users-28-day/latest実装時は、次のようなポイントを押さえておくと安全です。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-28-day/latestこの呼び出しで返るのは、主にダウンロードリンクとレポート期間です。実際の行データは、そのリンク先のNDJSONファイルから取得します。したがって、バッチ処理では「API呼び出し」「リンク先ファイルの即時ダウンロード」「Raw保存」「集計テーブルへの展開」を分けて設計すると、再処理や障害調査がしやすくなります。
移行・展開時の実務手順
既にCopilot usage metrics APIを利用している組織は、次の順で確認すると安全です。
既存パイプラインが新フィールドを受け入れられるか確認する
まず、検証用のOrganizationまたはEnterpriseで最新レポートを取得し、Raw NDJSONを保存します。そのうえで、既存のパーサーが未知のフィールドを無視するのか、エラーにするのかを確認します。
固定列のテーブルに直接ロードしている場合は、次のどちらかを選びます。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
ai_adoption_phaseを専用列として展開 | BIでフェーズ別に頻繁に集計する | versionも保持し、将来の分類変更に備える |
| JSON列として保存し、必要に応じて展開 | スキーマ変更に強くしたい | BI側での扱いやすさは専用列に劣る |
| Raw NDJSONと集計テーブルを併用 | 監査性と分析しやすさを両立したい | ストレージと処理設計がやや増える |
おすすめは、Raw NDJSONを保持しつつ、分析用テーブルには「フェーズ名または値」「version」「レポート期間」「ユーザーまたは組織ID」を展開する方法です。
既存レポートの定義を変えすぎない
今回の更新は、既存メトリクスの置き換えではなく、活用段階を説明する追加情報として扱うのが現実的です。
たとえば、これまで月次報告で「アクティブユーザー数」「コード補完受け入れ率」「言語別利用状況」を出していたなら、いきなり全指標を差し替える必要はありません。まずは追加ページとして、次の3つを出すと読み手に伝わりやすくなります。
- AI adoption phase別のユーザー比率
- フェーズ別のコード生成・受け入れ平均
- フェーズ別のPR作成、レビュー、マージ傾向
経営層や部門責任者向けには、細かいAPI項目名よりも「補完中心」「単一エージェント活用」「複数エージェント活用」という言葉に置き換えると理解されやすくなります。
チーム別に見る場合は重複カウントに注意する
2026年5月には、user-teams reportをper-user usage reportと結合してチームレベルのCopilot利用メトリクスを作れる更新も公開されています。チーム別にAI adoption phaseを見たい場合、この仕組みと組み合わせることで、部門・チーム単位の活用段階を分析しやすくなります。(The GitHub Blog)
ただし、チーム別集計には注意点があります。GitHubのChangelogでは、5人未満のCopilotシートユーザーしかいないチームはuser-teams reportから除外されること、複数チームに所属するユーザーの活動は各チームの集計に含まれるため、チーム合計を足してOrganizationやEnterprise全体の合計にはできないことが説明されています。(The GitHub Blog)
つまり、チーム別のAI adoption phaseは「どのチームに支援が必要か」を見るには有効ですが、「全社合計を再計算するための完全な内訳」として扱うと誤解が生じます。
メトリクスの読み方：見るべきポイント
AI adoption phaseは、単体で見るよりも、ほかの指標と組み合わせて読むことで価値が出ます。
Phase 0が多い場合
Phase 0が多い場合は、ライセンスを付与していても利用が定着していない可能性があります。
確認すべきことは、アクセス権限、IDE拡張機能の導入状況、社内ネットワークやプロキシ設定、利用開始時のオンボーディングです。いきなりライセンス回収を考えるより、まずは「使える状態になっているか」「利用シーンが伝わっているか」を確認したほうがよいでしょう。
Phase 1が多い場合
Phase 1が多い組織は、コード補完やIDE内の基本機能は定着しつつあります。
次の一手は、Copilot Chat、IDE agent mode、Copilot code review、Copilot CLIなど、開発フローに近い機能へ自然に広げることです。たとえば、次のような社内サンプルを作ると定着しやすくなります。
- 既存関数のテストケースを生成する
- 小さなリファクタリングをIDE agent modeで実行する
- Pull Requestのレビュー観点をCopilot code reviewで確認する
- CLIでエラー調査やコマンド生成を補助させる
Phase 2が増えている場合
Phase 2が増えている場合は、単なるコード補完から、エージェント系の活用へ移り始めています。
この段階では、利用拡大そのものよりも、開発プロセスへの影響を見るべきです。PR作成数が増えても、レビュー待ちが増えてマージまでの時間が延びるなら、ボトルネックはAI活用ではなくレビュー体制かもしれません。
また、Copilotが生成した変更をレビューしやすくするため、PRサイズを小さく保つ、テストを必ず追加する、リポジトリごとのコーディング規約を整えるといった運用ルールも重要になります。
Phase 3が増えている場合
Phase 3が増えているチームは、複数のCopilot機能を組み合わせた活用が進んでいる可能性があります。
ただし、全員をPhase 3に引き上げることを目標にする必要はありません。むしろ、Phase 3のユーザーやチームから、再利用しやすい実践例を抽出するほうが効果的です。
たとえば、次のような形で横展開できます。
- 「Issueから実装方針を作る」プロンプト例
- Copilot code reviewで見つけやすい不具合パターン
- Copilot CLIを使った調査手順
- cloud agentに任せやすい小さなタスクの条件
- レビューしやすいAI生成PRの粒度
ダッシュボードやAPIの数字が合わないときの見直しポイント
Copilot利用メトリクスを社内報告に使う場合、「ダッシュボードとAPIの数字が合わない」という相談が起きがちです。
GitHub Docsでは、ダッシュボード、API、エクスポートレポートは同じ基礎テレメトリから派生するものの、集計方法や表示方法が異なると説明されています。また、IDEベースのCopilot利用メトリクスはIDEのテレメトリに依存し、開発者がIDE側のテレメトリを無効にしている場合、該当するIDEベースの活動はダッシュボードやAPIレポートに現れないとされています。(GitHub Docs)
確認すべきポイントは次の通りです。
| 症状 | よくある原因 | 対応 |
|---|---|---|
| APIとダッシュボードの値がずれる | 期間、集計粒度、データ鮮度が違う | 28日間ローリングなのか日次なのかを揃える |
| IDE利用が少なく見える | IDEテレメトリが無効 | 開発者環境の設定を確認する |
| CLI利用とIDE利用が合わない | CLIメトリクスは別系統で扱われる | IDE指標とCLI指標を分けて説明する |
| チーム別合計が全体合計と一致しない | 複数チーム所属ユーザーの重複 | チーム別は内訳ではなく切り口として扱う |
| 新フィールドでETLが落ちる | 固定スキーマで未知フィールドを拒否 | Raw保存、nullable列、JSON列で受ける |
特に、AI adoption phaseは直近28日間の利用に基づくため、1日だけの施策効果をすぐ評価する用途には向きません。研修や展開施策の効果を見るなら、少なくとも数週間単位で比率の変化を追うほうが現実的です。
管理者が作るべきレポート例
今回の更新を活かすなら、月次レポートに次の3つを追加すると実用性が高まります。
| レポート | 目的 | 読み取れること |
|---|---|---|
| AI adoption phase構成比 | Copilot活用の成熟度を見る | 補完中心なのか、エージェント活用まで進んでいるのか |
| チーム別Phase分布 | 支援が必要なチームを見つける | 研修対象、成功事例の横展開先 |
| Phase別PR・コード生成指標 | 開発プロセスへの影響を見る | PR作成、レビュー、マージまでの流れに変化があるか |
| Phase遷移トレンド | 導入施策の効果を見る | Phase 1からPhase 2、Phase 3へ進むユーザーが増えているか |
| 非活用ユーザーの割合 | ライセンス活用状況を見る | オンボーディング不足、設定不備、不要ライセンスの可能性 |
このとき、レポートの目的を「個人の利用量を競わせること」にしないことが重要です。Copilotの使い方は職種、担当リポジトリ、開発フェーズによって大きく変わります。運用保守、セキュリティレビュー、SRE、新規開発では、適切な使い方が異なります。
指標は、個人を評価するものではなく、チームがより安全かつ効果的にAIを使うための改善材料として扱うべきです。
展開時に失敗しやすいポイント
Copilot usage metrics APIの新しいcohortを活用する際は、次の失敗を避ける必要があります。
| 失敗しやすい考え方 | なぜ問題か | 正しい見方 |
|---|---|---|
| Phase 3が多いほど必ず良い | 業務内容によって必要なCopilot機能は違う | チームの目的に合った使い方かを見る |
| アクティブユーザー数だけで成功判断する | 利用の深さや開発プロセスへの影響が分からない | Phase、PR指標、レビュー状況を合わせて見る |
| フェーズ別平均を合計値として扱う | totals_by_ai_adoption_phaseは平均指標を含む | 合計と平均を明確に分ける |
| チーム別数字を足して全体値にする | 複数チーム所属で重複する | 全体値はOrganization/Enterpriseレポートで見る |
| 1週間で施策効果を判断する | 28日間のローリング判定と相性が悪い | 数週間から月次で傾向を見る |
versionを保存しない | 分類ロジック変更時に過去比較が難しくなる | フェーズ値とversionをセットで保存する |
| 個人監視のように扱う | 開発者の信頼を損ない、利用が萎縮する | チーム改善と支援施策に使う |
開発者が意識すべきこと
開発者は、今回のAPI更新のために特別な設定変更をする必要は基本的にありません。ただし、組織がCopilotの活用段階を見始めることで、チームのAI活用方針はより具体的になる可能性があります。
実務では、次のように使い分けると効果が出やすくなります。
| 作業シーン | 向いているCopilot活用 |
|---|---|
| 定型的な実装、補完、サンプル生成 | コード補完、チャット |
| 既存コードの小さな修正 | IDE agent mode、edit mode |
| コマンド調査、ログ確認、操作補助 | Copilot CLI |
| PRの見落とし確認 | Copilot code review |
| Issueから実装作業へ進める | Copilot cloud agent、GitHub Copilot app |
ただし、AIが生成したコードは必ずレビューが必要です。特に、権限、認証、課金、個人情報、セキュリティに関わる変更では、Copilotの出力をそのまま採用しないことが大切です。
Copilotを「速く書く道具」としてだけ使うのではなく、「調査、設計、レビュー、検証の負担を減らす道具」として使えるようになると、Phaseの上昇以上に実務上の価値が出ます。
まず取るべき次のアクション
今回の更新に対応するなら、最初にやるべきことは大きく3つです。
1つ目は、Copilot usage metrics APIを利用できる権限とポリシーを確認することです。Enterprise全体のポリシー、Organization権限、APIトークンのスコープを見直します。
2つ目は、既存のデータ取り込み処理がai_adoption_phaseとtotals_by_ai_adoption_phaseを受けられるか検証することです。固定スキーマで壊れる可能性がある場合は、Raw NDJSON保存とnullable列の追加を先に行います。
3つ目は、レポートの読み方を決めることです。Phase 0をオンボーディング課題、Phase 1を基本定着、Phase 2をエージェント活用の入口、Phase 3を横展開候補として扱うと、管理者も開発チームも次の行動を決めやすくなります。
Copilot usage metrics APIのcohort追加は、単なるAPI項目の追加ではありません。GitHub Copilotの導入を「人数」から「使い方の成熟度」へ進めるための更新です。まずは既存レポートにAI adoption phaseの構成比を追加し、チームごとの支援策、成功事例の横展開、データ基盤のスキーマ対応を進めるのが現実的な第一歩です。
コメント