# GitHub Copilot 使用状況メトリクス Copilot 使用状況メトリックは、エンゲージメント、アクティビティ、コード生成、プル要求ライフサイクルの傾向など、組織全体で Copilot がどのように採用され、使用されているかを可視化します。 ## Copilot使用状況メトリックについて Copilot 利用状況メトリックは、主要な利害関係者や意思決定者が、チームが Copilotをどのように導入して使用しているかを理解するのに役立ちます。 企業全体の使用パターンを追跡することで、エンゲージメントを測定し、価値を高める機会を特定し、AI 支援ワークフローがプル要求のスループットとマージ時間に与える影響を評価できます。 メトリックは、次の方法で使用できます。 * Copilot使用状況メトリック API。エンタープライズ、組織、リポジトリ、およびユーザー レベルで詳細でエクスポート可能なデータを提供します。 * Copilot使用状況メトリック ダッシュボード。企業と組織全体の 28 日間の使用状況の傾向が視覚化されます。 * コード生成ダッシュボード。企業や組織全体のユーザーとエージェントによってコードがどのように生成されているかが分類されます。 * Copilot影響ダッシュボードでは、ユーザーを導入コーホートにグループ化し、その導入をプル要求の出力に接続します。 * Copilot使用状況メトリックのNDJSONエクスポートは、カスタムBIツールや長期ストレージ用の生データを提供します。 ## どの使用法が含まれていますか? Copilot使用状況メトリックは、IDE、Copilot、Copilot CLI アクティビティなど、複数のagent apps サーフェスにわたるテレメトリから派生します。 ほとんどのメトリックはクライアント側の IDE テレメトリから取得され、エンド ユーザーは、これらのメトリックの最も豊富なデータに対して **IDE でテレメトリを有効にする必要** があります。 さらに、 Copilot 使用状況メトリックには **、サーバー側のテレメトリ** が組み込まれており、クライアント側のテレメトリだけでは見逃す可能性があるアクティブなユーザーを特定します。 ネットワーク条件、プロキシ構成、およびクライアント設定により、クライアント テレメトリが GitHubに到達できなくなる可能性があるため、サーバー側のシグナルにより、それらのユーザーがレポートに引き続き表示されるようになります。 サーバー側のテレメトリを介して表示されたユーザーは、アクティブなユーザーの合計 (毎日のアクティブ ユーザー、 `daily_active_users` など) に完全にカウントされます。 使用可能な場合は、 `totals_by_ide` にも表示されることがあります (最近検出された IDE やユーザーごとのレポートの Copilot 拡張機能のバージョンを含む)。 ただし、他のディメンションの内訳 ( `totals_by_feature` やコード行のメトリックなど) は、豊富なテレメトリが利用できるようになるまで空のままです。 クライアント テレメトリによって既にキャプチャされたユーザーの最上位の合計と内訳は変更されません。 データには、次のような他の\*\*\*\* サーフェスからのアクティビティCopilot。 * Copilot Chat の GitHub.com * GitHub Mobile ライセンスとシート管理のデータは、 Copilot 使用状況メトリック レポートには含まれません。 ライセンスの割り当てを表示または管理するには、ライセンスとシート情報の信頼できるソースである Copilot ユーザー管理 API を使用します。 「[Copilotユーザー管理のためのREST APIエンドポイント](/ja/rest/copilot/copilot-user-management)」を参照してください。 ## 使用状況メトリックが API リソース間で異なる理由 次の API リソースは Copilot関連データを公開しますが、互換性がないため、直接比較しないでください。 各 API リソースは、特定のユース ケースとデータ モデル用に設計されており、合計またはカバレッジの違いが予想されます。 次の表を使用して、レポートのニーズに最も適した API リソースを理解します。 > \[!NOTE] > Copilotの使用状況の最も完全で将来のビューが提供されるため、新しい統合と分析にはCopilot使用状況メトリック API を使用することを強くお勧めします。 | API リソース | Scope | 主な機能 | | ---------------------------------------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Copilot使用状況メトリックの REST API エンドポイント](/ja/rest/copilot/copilot-usage-metrics) | リポジトリとユーザー レベルのレポートを使用した高度なエンタープライズおよび組織スコープのイベント テレメトリ | オートコンプリート、チャット、およびエージェント モード全体で統合されたテレメトリを提供します。 すべての IDE モード、言語、モデルの使用状況とコード メトリックの行が含まれます。 機能、IDE、言語、モデル、ユーザー、リポジトリ レベルのプル要求アクティビティ レポートによる詳細な内訳をサポートし、アクティブに開発および保守されているプライマリ API リソースです。 | | [Copilotユーザー管理のためのREST APIエンドポイント](/ja/rest/copilot/copilot-user-management) | ライセンスとシートの割り当て | 組織または企業に割り当てられたCopilotシートを一覧表示し、ライセンスの状態、ユーザーの関連付け、`last_activity_at`などを含みます。 この API リソースは、ライセンスとシート情報の信頼のソースです。 | ## メトリックは組織全体にどのように属性付けされますか? > \[!NOTE] > エンタープライズ レベルのアクセスを提供することなく、\*\*\*\* の使用状況メトリックをCopilotできます。 > > これを行うには、"組織の Copilot メトリックの表示" アクセス許可を含む組織のカスタム ロールを作成し、そのロールを 1 つの組織のメトリックを表示する必要があるユーザーに割り当てます。 「[カスタム組織ロールの権限](/ja/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles)」を参照してください。 組織レベルの Copilot 使用状況メトリックは、個々のアクションが発生する場所ではなく、組織のメンバーシップに基づいています。 企業のメトリックに表示されるには、その企業内でアクティブなCopilotシートが割り当てられていることが必要です（この企業に属する任意の組織で）。 その結果、1 人のユーザーの使用状況が複数の組織ダッシュボードに表示される一方で、同じユーザーはエンタープライズ レベルの合計で 1 回だけカウントされます。 組織レベルの分析は、組織内での導入と使用状況を可視化することを目的としており、エンタープライズ レベルの合計と直接比較するようには設計されていません。 組織レベルの Copilot 分析は、2025 年 12 月 12 日から利用できます。 これは、組織レベルのレポートが提供される最初の日付です。 ユーザーが企業にシートを持つ場合、シートが割り当てられている場所に関係なく、ユーザーの使用状況は **所属するすべての組織**に起因します。 これは、以下のようなことを意味します。 * エンタープライズ内の管理目的で専用の "シェル" 組織にライセンスが割り当てられている場合、ユーザーは、所属する企業内の他のすべての組織のメトリックに引き続き表示されます。 * ユーザーがCopilotに\*\*\*\* シートを持っている場合、そのアクティビティは、企業**内に少なくとも 1 つのシートがある限り、企業**の組織レベルのメトリックに引き続き含まれます。 要するに、ユーザーがメトリックに表示されるようにするには、企業内のどこかでライセンスを取得する必要があります。 それが完了したら、メトリックは、職場(組織のメンバーシップ) を反映し、どの組織が Copilot シートを提供しているかや、アクティビティが発生した場所は反映しません。 ## サポートされている IDE Copilot使用状況メトリックに含めるには、エンド ユーザーは次のいずれかの IDE とCopilot Chat拡張機能バージョンを使用する必要があります。 | IDE | 最小 IDE バージョン | 最小 Copilot Chat 拡張機能バージョン | | :------------------- | :----------- | :------------------------ | | Eclipse | 4.31 | 0.9.3.202507240902 | | JetBrains / IntelliJ | 2024.2.6 | 1.5.52-241 | | Visual Studio | 17.14.13 | 18.0.471.29466 | | VS Code | 1.107.1 | 0.35.3 | | Xcode | 13.2.1 | 0.40.0 | ## データの鮮度 ダッシュボードと API レポートのデータは、定期的に更新されます。 データは **2 日以内**に使用可能になると予想できます。 つまり、特定の日のデータは処理され、その日が閉じた後、完全な UTC 日の 2 日以内に使用できるようになります。 ## データは何を測定しますか? Copilot 使用状況メトリックは、導入、エンゲージメント、受け入れ率、コード行 (LoC)、pull request ライフサイクル メトリックなど、いくつかの主要なカテゴリにグループ化できます。 **導入** は、ライセンスを持つ開発者が Copilotを積極的に使用している数を測定します。 たとえば、毎日アクティブなユーザー (DAU) は、特定の日に Copilot を操作した一意のユーザーの数を示します。 ロールアウト中に、これらのメトリックに一貫した上昇傾向が表示されるのが理想的です。 Copilot code review 導入は個別に追跡され、アクティブユーザー数とパッシブ ユーザー数が異なります。 アクティブユーザーは手動でレビューを依頼したり、提案を適用しました。一方で、パッシブユーザーにはプルリクエストを確認する役割がCopilot code reviewにより自動的に割り当てられました。 ユーザーが同じ期間内に両方のシグナルを持っている場合、それらはアクティブとしてのみカウントされます。 導入の深さをより深く見るためのユーザーも、導入コーホートにグループ化されます。 [導入コーホートについて](#understanding-adoption-cohorts)を参照してください。 **エンゲージメント** 対策では、開発者が Copilot を採用した後にどれだけ深く使用するかについて説明します。 主要なエンゲージメント メトリックは、使用頻度だけでなく、機能全体の幅も示します。 たとえば、アクティブなユーザーあたりの平均チャット要求数は、ユーザーが Copilot Chatを開いて操作する頻度を測定します。 言語や IDE 間で定期的に増加するチャットの使用を確認する必要があります。 **受け入れ率** は、開発者が Copilotの提案を受け入れる頻度を測定します。 これは、提案が関連性があり、信頼されているかどうかを理解するのに役立ちます。 たとえば、インライン提案の受け入れ率が高い場合は、提案が関連性があり、役に立つことを示します。 **コード行 (LoC) メトリック** は、エディターで提案、追加、または削除 Copilot 行数を測定し、 Copilotの具体的な出力の方向ビューを提供します。 たとえば、"行の追加" は、実際に受け入れられ、エディターに挿入されたコードの量を示します。 **pull request ライフサイクル メトリックは** 、 Copilot アクティビティが pull request の結果と配信フローにどのように関連しているかを測定します。 これらのメトリックには、プル要求の作成とマージの数、マージする時間の中央値、提案アクティビティの確認が含まれます。 全体的なプル要求アクティビティと、 Copilotによって作成されたプル要求を比較することで、AI 支援ワークフローが組織レベルまたはエンタープライズ レベルでのスループットとサイクル時間に与える影響を評価できます。 ### 導入コーホートについて Copilotは、1 人のアクティブ ユーザー数として導入を測定するのではなく、ユーザーが関与しているかどうかだけでなく、\*\*\*\* との関わり方に基づいて、ユーザーをCopilotにグループ化します。 フラットアクティブユーザー数は、コード補完を時々受け入れるユーザーを、1 日を通して複数のエージェント駆動型ワークフローを調整するユーザーと同じように扱います。 コーホートによってこれら 2 人のユーザーが分離されるため、最初の試用ではなく、時間の経過と共に組織の使用状況が深まっていないかどうかを確認できます。 ユーザーは次のフェーズにグループ化されます。 | Phase | それが表すもの | | :----------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | パッシブ ユーザー | ユーザーは、期間中にフェーズのエンゲージメントしきい値を満たしていません。 パッシブ ユーザーは、コード編集を適用せずに Copilot Chat モードまたはエージェント モードで質問するなどして、Copilotを定期的に使用している可能性があります。 API では、このフェーズには `No Cohort`ラベルが付けられます。 | | フェーズ 1: 最初にコードを記述する | コード補完やエージェントの編集に従事したユーザー。ここで、 Copilot は変更を IDE 内のファイルに直接書き込みます。 コード補完やエージェント編集アクティビティを生成せずに Copilot Chat またはエージェント モードを使用しても、単独では修飾されません。 | | フェーズ 2: エージェント優先 | ユーザーは、GitHub、Copilot cloud agent、Copilot code reviewなど、1 つのCopilot CLIベースのエージェント サーフェスに従事しました。 | | Copilot code reviewとのアクティブなエンゲージメントと、プル要求数を同じサーフェスとして確認するために自動的に割り当てる両方。 | | | フェーズ 3: マルチエージェント | ユーザは、2つ以上の GitHubベースのエージェント表面、または GitHub Copilot appに従事する。 | フェーズにグループ化するには、ユーザーは、そのフェーズに関連付けられているサーフェスを使用して、後続の 28 日間のウィンドウから少なくとも 2 つのアクティブな日のエンゲージメントしきい値を満たす必要があります。 ユーザーは、そのフェーズに進むには、より高いフェーズのサーフェスで 2 つの条件を満たす日のみを必要とします。 エージェントの使用だけで、プレーンな完了の日数を切り離すことなく、ユーザーを修飾できます。 フェーズの割り当ては、後続の 28 日間のウィンドウから毎日再計算されるため、ユーザーのフェーズは、そのウィンドウ内のアクティビティが変化すると、ある日から次の日にシフトできます。 これは予期される動作であり、データ エラーではありません。 影響ダッシュボードでは、末尾の 28 日間にアクティブだったすべてのユーザーがカウントされ、現在のフェーズごとに各ユーザーがグループ化されます。 フェーズ分類ルールは同じですが、ダッシュボードの作成は API レポートと NDJSON レポートの `totals_by_ai_adoption_phase.total_engaged_users` フィールドよりも広く、特定の日にアクティブだったユーザーがカウントされます。 フェーズのしきい値を満たしていない **ユーザーはパッシブ ユーザー**にグループ化されます。これは非アクティブの尺度ではありませんが、ユーザーのエンゲージメントが、導入の深さを確実に分類するために必要なレベルにまだ達していないことを示しています。 たとえば、後続の 28 日間のウィンドウでアクティブな日数が 2 日未満のユーザーや、Copilot ChatのGitHub.comのようなサーフェスのみを軽く使用するユーザーは、パッシブ ユーザーとして表示されます。 フェーズの割り当ては、ユーザーが実行するアクションの数だけでなく、ユーザーが **関与するサーフェス**に基づいているため、完了量が多いがエージェントの使用量が多いユーザーはフェーズ 1 に留まりますが、エージェント サーフェス全体で使用量が少ないユーザーはフェーズ 2 またはフェーズ 3 に進みます。 基になるスキーマ フィールドについては、 [AI 導入フェーズのフィールド](/ja/copilot/reference/copilot-usage-metrics/copilot-usage-metrics#ai-adoption-phase-fields)を参照してください。 影響ダッシュボードの **導入乗数** は、関与しているユーザーに対してマージされたプル要求の平均量 (フェーズ 1、2、または 3 のプル要求) を、パッシブ ユーザーにマージされたプル要求の量で除算します。 これは、各フェーズに含まれるユーザーの数に関係なく、より深い導入の相対的な影響を示しています。 これは、より魅力的なユーザーになる可能性のあるリフトを理解するための測定値です。 たとえば、エンゲージされたコーホートのユーザーが 20 個のプル要求/ユーザー/月を平均し、パッシブ コホートが平均 10、式は 20 / 10 = 2x 乗数になります。 ### 潜在的な投資収益率の見積もり 影響ダッシュボードの **潜在的な投資収益率** セクションでは、 **フェーズ 0-1 パッシブ ユーザーとコード ファースト ユーザーとフェーズ 2-3\*\*\*\*エージェント ファースト ユーザー**の間のコストとプル要求の出力の比較が提供されます。 各フェーズ グループについて、ダッシュボードには、実際のAI credits消費量に基づいて、開発者ごとの毎月のCopilot コストと、そのコストが開発者報酬の割合として表示されます。 また、1 か月あたりの開発者ごとの平均プル要求数も表示されます。 補正バンドを選択して、開発者の報酬に依存する見積もりを更新できます。 これらの数値は正確な財務結果ではなく見積もりであるため、導入乗数のコード出荷およびマージまでの時間の比較と共に解釈します。 投資収益率の見積もりはダッシュボードでのみ使用でき、 Copilot 使用状況メトリック API または NDJSON エクスポートには含まれません。 ### スコープ間でのプル要求ライフサイクル メトリックの解釈 プル要求ライフサイクル メトリックは、組織レベルとエンタープライズ レベルの両方で使用できます。 レポートを比較するときは、次の点に注意してください。 * **重複除去**: エンタープライズ レベルのレポートでは、組織全体のユーザーが重複除去されます。 組織レベルのレポートには含まれません。 * **Pull request-only data**: pull request data is derived from repository activity. (プル要求データはリポジトリ アクティビティから派生するため)、IDE 使用状況メトリックがない場合でも、プル要求ライフサイクル メトリックが表示されることがあります。 * **属性のタイミング**: リポジトリまたは組織が所有者間で転送された場合、プル要求の作成、レビュー、マージ イベントは、各イベントが発生したタイミングに応じて異なるエンティティに起因する可能性があります。 ## これらのメトリックを使用するにはどうすればよいですか? これらのメトリックを一緒に使用して、チームの Copilotの使用状況に関する重要な質問に回答できます。 | Question | これらのメトリックを使用する | | :---------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------- | | チームは定期的に Copilot を使用していますか? | 毎日および毎週アクティブなユーザー | | 最も価値のある機能はどれですか? | チャット モードごとの要求、エージェントの導入 | | 開発者は Copilotの出力を信頼していますか? | 受け入れ率の傾向 | | 有効化作業は機能していますか? | トレーニングまたはコミュニケーション キャンペーン後の導入とエンゲージメントの増加 | | Copilot配信速度やプル要求のスループットに影響しますか? | プルリクエストのマージ件数とマージまでの中央値の時間 | | Copilot code reviewはどのように採用されていますか? | アクティブコードレビューとパッシブコードレビューのユーザー数 | | 組織の導入は時間の経過と同時に深まりますか? | 導入コーホートの分布とエンゲージメントの傾向 | | ダッシュボードからの分析情報に対してどのように対処すればよいですか? | 「[GitHub Copilot の使用状況と導入メトリックの解釈](/ja/copilot/reference/copilot-usage-metrics/interpret-copilot-metrics#reviewing-adoption-cohorts)」を参照してください | 単一の数値に焦点を当てるのではなく、これらの信号全体のパターンを探します。 たとえば、受け入れ率の上昇と組み合わせて安定した DAU は、信頼と価値の増大を示しています。