GitHub Copilot 使用状況メトリクス

Copilot 使用状況メトリックは、エンゲージメント、アクティビティ、コード生成、プル要求ライフサイクルの傾向など、組織全体で Copilot がどのように採用され、使用されているかを可視化します。

この記事で

Copilot使用状況メトリックについて

Copilot 利用状況メトリックは、主要な利害関係者や意思決定者が、チームが Copilotをどのように導入して使用しているかを理解するのに役立ちます。 企業全体の使用パターンを追跡することで、エンゲージメントを測定し、価値を高める機会を特定し、AI 支援ワークフローがプル要求のスループットとマージ時間に与える影響を評価できます。

メトリックは、次の方法で使用できます。

  • Copilot使用状況メトリック API。エンタープライズ、組織、リポジトリ、およびユーザー レベルで詳細でエクスポート可能なデータを提供します。
  • Copilot使用状況メトリック ダッシュボード。企業と組織全体の 28 日間の使用状況の傾向が視覚化されます。
  • コード生成ダッシュボード。企業や組織全体のユーザーとエージェントによってコードがどのように生成されているかが分類されます。
  • Copilot影響ダッシュボードでは、ユーザーを導入コーホートにグループ化し、その導入をプル要求の出力に接続します。
  • Copilot使用状況メトリックのNDJSONエクスポートは、カスタムBIツールや長期ストレージ用の生データを提供します。

どの使用法が含まれていますか?

Copilot使用状況メトリックは、IDE や Copilot アクティビティなど、複数のCopilot CLI (コパイロット CLI) サーフェスにわたるテレメトリから派生します。 ほとんどのメトリックはクライアント側の IDE テレメトリから取得され、エンド ユーザーは、これらのメトリックの最も豊富なデータに対して IDE でテレメトリを有効にする必要 があります。

さらに、 Copilot 使用状況メトリックには 、サーバー側のテレメトリ が組み込まれており、クライアント側のテレメトリだけでは見逃す可能性があるアクティブなユーザーを特定します。 ネットワーク条件、プロキシ構成、およびクライアント設定により、クライアント テレメトリが GitHubに到達できなくなる可能性があるため、サーバー側のシグナルにより、それらのユーザーがレポートに引き続き表示されるようになります。

サーバー側のテレメトリを介して表示されたユーザーは、アクティブなユーザーの合計 (毎日のアクティブ ユーザー、 daily_active_users など) に完全にカウントされます。 使用可能な場合は、 totals_by_ide にも表示されることがあります (最近検出された IDE やユーザーごとのレポートの Copilot 拡張機能のバージョンを含む)。 ただし、他のディメンションの内訳 ( totals_by_feature やコード行のメトリックなど) は、豊富なテレメトリが利用できるようになるまで空のままです。 クライアント テレメトリによって既にキャプチャされたユーザーの最上位の合計と内訳は変更されません。

データには、次のような他の**** サーフェスからのアクティビティCopilot。

  • コパイロットチャット の GitHub.com
  • GitHub Mobile

ライセンスとシート管理のデータは、 Copilot 使用状況メトリック レポートには含まれません。 ライセンスの割り当てを表示または管理するには、ライセンスとシート情報の信頼できるソースである Copilot ユーザー管理 API を使用します。 「Copilotユーザー管理のためのREST APIエンドポイント」を参照してください。

使用状況メトリックが API リソース間で異なる理由

次の API リソースは Copilot関連データを公開しますが、互換性がないため、直接比較しないでください。 各 API リソースは、特定のユース ケースとデータ モデル用に設計されており、合計またはカバレッジの違いが予想されます。 次の表を使用して、レポートのニーズに最も適した API リソースを理解します。

メモ

Copilotの使用状況の最も完全で将来のビューが提供されるため、新しい統合と分析にはCopilot使用状況メトリック API を使用することを強くお勧めします。

API リソースScope主な機能
Copilot使用状況メトリックの REST API エンドポイントリポジトリとユーザー レベルのレポートを使用した高度なエンタープライズおよび組織スコープのイベント テレメトリオートコンプリート、チャット、およびエージェント モード全体で統合されたテレメトリを提供します。 すべての IDE モード、言語、モデルの使用状況とコード メトリックの行が含まれます。 機能、IDE、言語、モデル、ユーザー、リポジトリ レベルのプル要求アクティビティ レポートによる詳細な内訳をサポートし、アクティブに開発および保守されているプライマリ API リソースです。
Copilotユーザー管理のためのREST APIエンドポイントライセンスとシートの割り当て組織または企業に割り当てられたCopilotシートを一覧表示し、ライセンスの状態、ユーザーの関連付け、last_activity_atなどを含みます。 この API リソースは、ライセンスとシート情報の信頼のソースです。

メトリックは組織全体にどのように属性付けされますか?

メモ

エンタープライズ レベルのアクセスを提供することなく、**** の使用状況メトリックをCopilotできます。

これを行うには、"組織の Copilot メトリックの表示" アクセス許可を含む組織のカスタム ロールを作成し、そのロールを 1 つの組織のメトリックを表示する必要があるユーザーに割り当てます。 「カスタム組織ロールの権限」を参照してください。

組織レベルの Copilot 使用状況メトリックは、個々のアクションが発生する場所ではなく、組織のメンバーシップに基づいています。 企業のメトリックに表示されるには、その企業内でアクティブなCopilotシートが割り当てられていることが必要です（この企業に属する任意の組織で）。 その結果、1 人のユーザーの使用状況が複数の組織ダッシュボードに表示される一方で、同じユーザーはエンタープライズ レベルの合計で 1 回だけカウントされます。 組織レベルの分析は、組織内での導入と使用状況を可視化することを目的としており、エンタープライズ レベルの合計と直接比較するようには設計されていません。

組織レベルの Copilot 分析は、2025 年 12 月 12 日から利用できます。 これは、組織レベルのレポートが提供される最初の日付です。

ユーザーが企業にシートを持つ場合、シートが割り当てられている場所に関係なく、ユーザーの使用状況は 所属するすべての組織に起因します。

これは、以下のようなことを意味します。

  • エンタープライズ内の管理目的で専用の "シェル" 組織にライセンスが割り当てられている場合、ユーザーは、所属する企業内の他のすべての組織のメトリックに引き続き表示されます。
  • ユーザーがCopilotに**** シートを持っている場合、そのアクティビティは、企業内に少なくとも 1 つのシートがある限り、企業の組織レベルのメトリックに引き続き含まれます。

要するに、ユーザーがメトリックに表示されるようにするには、企業内のどこかでライセンスを取得する必要があります。 それが完了したら、メトリックは、職場(組織のメンバーシップ) を反映し、どの組織が Copilot シートを提供しているかや、アクティビティが発生した場所は反映しません。

サポートされている IDE

Copilot使用状況メトリックに含めるには、エンド ユーザーは次のいずれかの IDE とコパイロットチャット拡張機能バージョンを使用する必要があります。

IDE最小 IDE バージョン最小 コパイロットチャット 拡張機能バージョン
Eclipse4.310.9.3.202507240902
JetBrains / IntelliJ2024.2.61.5.52-241
Visual Studio17.14.1318.0.471.29466
VS Code1.107.10.35.3
Xcode13.2.10.40.0

データの鮮度

ダッシュボードと API レポートのデータは、定期的に更新されます。

データは 2 日以内に使用可能になると予想できます。 つまり、特定の日のデータは処理され、その日が閉じた後、完全な UTC 日の 2 日以内に使用できるようになります。

データは何を測定しますか?

Copilot 使用状況メトリックは、導入、エンゲージメント、受け入れ率、コード行 (LoC)、pull request ライフサイクル メトリックなど、いくつかの主要なカテゴリにグループ化できます。

導入 は、ライセンスを持つ開発者が Copilotを積極的に使用している数を測定します。 たとえば、毎日アクティブなユーザー (DAU) は、特定の日に Copilot を操作した一意のユーザーの数を示します。 ロールアウト中に、これらのメトリックに一貫した上昇傾向が表示されるのが理想的です。 Copilotコード レビュー 導入は個別に追跡され、アクティブユーザー数とパッシブ ユーザー数が異なります。 アクティブユーザーは手動でレビューを依頼したり、提案を適用しました。一方で、パッシブユーザーにはプルリクエストを確認する役割がCopilotコード レビューにより自動的に割り当てられました。 ユーザーが同じ期間内に両方のシグナルを持っている場合、それらはアクティブとしてのみカウントされます。 導入の深さをより深く見るためのユーザーも、導入コーホートにグループ化されます。 導入コーホートについてを参照してください。

エンゲージメント 対策では、開発者が Copilot を採用した後にどれだけ深く使用するかについて説明します。 主要なエンゲージメント メトリックは、使用頻度だけでなく、機能全体の幅も示します。 たとえば、アクティブなユーザーあたりの平均チャット要求数は、ユーザーが コパイロットチャットを開いて操作する頻度を測定します。 言語や IDE 間で定期的に増加するチャットの使用を確認する必要があります。

受け入れ率 は、開発者が Copilotの提案を受け入れる頻度を測定します。 これは、提案が関連性があり、信頼されているかどうかを理解するのに役立ちます。 たとえば、インライン提案の受け入れ率が高い場合は、提案が関連性があり、役に立つことを示します。

コード行 (LoC) メトリック は、エディターで提案、追加、または削除 Copilot 行数を測定し、 Copilotの具体的な出力の方向ビューを提供します。 たとえば、"行の追加" は、実際に受け入れられ、エディターに挿入されたコードの量を示します。

pull request ライフサイクル メトリックは 、 Copilot アクティビティが pull request の結果と配信フローにどのように関連しているかを測定します。 これらのメトリックには、プル要求の作成とマージの数、マージする時間の中央値、提案アクティビティの確認が含まれます。 全体的なプル要求アクティビティと、 Copilotによって作成されたプル要求を比較することで、AI 支援ワークフローが組織レベルまたはエンタープライズ レベルでのスループットとサイクル時間に与える影響を評価できます。

導入コーホートについて

Copilotは、1 人のアクティブ ユーザー数として導入を測定するのではなく、ユーザーが関与しているかどうかだけでなく、Copilotとの関わり方に基づいて、ユーザーを導入コーホートにグループ化します。 フラットアクティブユーザー数は、コード補完を時々受け入れるユーザーを、1 日を通して複数のエージェント駆動型ワークフローを調整するユーザーと同じように扱います。 コーホートによってこれら 2 人のユーザーが分離されるため、最初の試用ではなく、時間の経過と共に組織の使用状況が深まっていないかどうかを確認できます。

ユーザーは次のフェーズにグループ化されます。

Phaseそれが表すもの
パッシブ ユーザーユーザーは、期間中にフェーズのエンゲージメントしきい値を満たしていません。 基になるデータでは、このフェーズには No Cohortラベルが付けられます。
フェーズ 1: 最初にコードを記述するコード補完や IDE エージェント モードに関与しているユーザー。
フェーズ 2: エージェント優先ユーザーは、Copilot クラウドエージェント、Copilotコード レビュー、Copilot CLI (コパイロット CLI)など、1 つのGitHubベースのエージェント サーフェスに従事しました。 ここでは、 Copilotコード レビュー のアクティブなエンゲージメントのみがカウントされます。追加のエンゲージメントなしで pull request をレビューするために自動的に割り当てられることはありません。
フェーズ 3: マルチエージェントユーザは、2つ以上の GitHubベースのエージェント表面、または GitHub Copilot アプリに従事する。

フェーズにグループ化するには、ユーザーは、そのフェーズに関連付けられているサーフェスを使用して、後続の 28 日間のウィンドウから少なくとも 2 つのアクティブな日のエンゲージメントしきい値を満たす必要があります。 ユーザーは、そのフェーズに進むには、より高いフェーズのサーフェスで 2 つの条件を満たす日のみを必要とします。 エージェントの使用だけで、プレーンな完了の日数を切り離すことなく、ユーザーを修飾できます。

フェーズの割り当ては、後続の 28 日間のウィンドウから毎日再計算されるため、ユーザーのフェーズは、そのウィンドウ内のアクティビティが変化すると、ある日から次の日にシフトできます。 これは予期される動作であり、データ エラーではありません。

フェーズのしきい値を満たしていない ユーザーはパッシブ ユーザーにグループ化されます。これは非アクティブの尺度ではありませんが、ユーザーのエンゲージメントが、導入の深さを確実に分類するために必要なレベルにまだ達していないことを示しています。 たとえば、後続の 28 日間のウィンドウでアクティブな日数が 2 日未満のユーザーや、GitHub.comのコパイロットチャットのようなサーフェスのみを軽く使用するユーザーは、パッシブ ユーザーとして表示されます。

フェーズの割り当ては、ユーザーが実行するアクションの数だけでなく、ユーザーが 関与するサーフェスに基づいているため、完了量が多いがエージェントの使用量が多いユーザーはフェーズ 1 に留まりますが、エージェント サーフェス全体で使用量が少ないユーザーはフェーズ 2 またはフェーズ 3 に進みます。

基になるスキーマ フィールドについては、 AI 導入フェーズのフィールドを参照してください。

影響ダッシュボードの 導入乗数 は、関与しているユーザーに対してマージされたプル要求の平均量 (フェーズ 1、2、または 3 のプル要求) を、パッシブ ユーザーにマージされたプル要求の量で除算します。

これは、各フェーズに含まれるユーザーの数に関係なく、より深い導入の相対的な影響を示しています。 これは、より魅力的なユーザーになる可能性のあるリフトを理解するための測定値です。

たとえば、エンゲージされたコーホートのユーザーが 20 個のプル要求/ユーザー/月を平均し、パッシブ コホートが平均 10、式は 20 / 10 = 2x 乗数になります。

スコープ間でのプル要求ライフサイクル メトリックの解釈

プル要求ライフサイクル メトリックは、組織レベルとエンタープライズ レベルの両方で使用できます。 レポートを比較するときは、次の点に注意してください。

  • 重複除去: エンタープライズ レベルのレポートでは、組織全体のユーザーが重複除去されます。 組織レベルのレポートには含まれません。
  • Pull request-only data: pull request data is derived from repository activity. (プル要求データはリポジトリ アクティビティから派生するため)、IDE 使用状況メトリックがない場合でも、プル要求ライフサイクル メトリックが表示されることがあります。
  • 属性のタイミング: リポジトリまたは組織が所有者間で転送された場合、プル要求の作成、レビュー、マージ イベントは、各イベントが発生したタイミングに応じて異なるエンティティに起因する可能性があります。

これらのメトリックを使用するにはどうすればよいですか?

これらのメトリックを一緒に使用して、チームの Copilotの使用状況に関する重要な質問に回答できます。

Questionこれらのメトリックを使用する
チームは定期的に Copilot を使用していますか?毎日および毎週アクティブなユーザー
最も価値のある機能はどれですか?チャット モードごとの要求、エージェントの導入
開発者は Copilotの出力を信頼していますか?受け入れ率の傾向
有効化作業は機能していますか?トレーニングまたはコミュニケーション キャンペーン後の導入とエンゲージメントの増加
Copilot配信速度やプル要求のスループットに影響しますか?プルリクエストのマージ件数とマージまでの中央値の時間
Copilotコード レビューはどのように採用されていますか?アクティブコードレビューとパッシブコードレビューのユーザー数
組織の導入は時間の経過と同時に深まりますか?導入コーホートの分布とエンゲージメントの傾向
ダッシュボードからの分析情報に対してどのように対処すればよいですか?「GitHub Copilot の使用状況と導入メトリックの解釈」を参照してください

単一の数値に焦点を当てるのではなく、これらの信号全体のパターンを探します。 たとえば、受け入れ率の上昇と組み合わせて安定した DAU は、信頼と価値の増大を示しています。

次のステップ

各 Copilot メトリックが測定する内容とその使用方法を理解したら、ダッシュボードを調べて、これらのメトリックを実際に見ることができます。