要点
GitHub は Copilot の利用状況レポートを強化し、サーバー側のテレメトリーデータを追加することで、従来のクライアント信号だけでは見逃されていたアクティブユーザーも報告に含まれるようになった。これにより、エンタープライズ向けの利用状況をより包括的かつ一貫して把握できるようになった。
Copilot の利用状況レポートは、従来のクライアントからの信号に加え、サーバー側のテレメトリも活用するようになりました。これにより、より多くのアクティブな Copilot ユーザーがレポートに表示されるようになります。
Copilot 利用状況 API が返すエンタープライズ向け利用状況レポートでは、これまでクライアント側のテレメトリだけでは見逃されていたアクティブユーザーも明らかになり、誰が Copilot を利用しているのかについて、より包括的で一貫性のある全体像を把握できるようになります。
何が変わったか
Copilot の利用状況レポートは従来、IDE やその他のクライアントから発行されるクライアント側のテレメトリに基づいて作成されてきました。このテレメトリは私たちが持つ最も豊富な情報源ですが、必ずしもすべてが収集できるわけではありません。ネットワーク環境やプロキシ設定、クライアントの設定、あるいは双方の制御範囲外の他の要因により、クライアントからの活動報告が阻害されることがあります。そのような場合、実際に課金対象となるアクティブユーザーがレポートから抜け落ちてしまう可能性があります。
今回の更新では、アクティブユーザーを特定するために追加でサーバー側のテレメトリを取り込みました。これにより、サーバー側で確認できるアクティブユーザーのうち、クライアント側のテレメトリではまだ捕捉できていなかったユーザーも、エンタープライズ向けの 1 日および 28 日のレポートに含めるようになりました。その結果、デイリーアクティブユーザー(DAU)の網羅性が向上します。
これらの新たに表面化したユーザーは完全に特定され、アクティブユーザーの合計数にカウントされます。サーバーサイドのテレメトリがまだ提供していないのは、クライアントテレメトリが提供する豊かでインタラクションごとの詳細情報(具体的には IDE、機能、モデル、およびコード行数の活動)です。したがって、これらのユーザーについては、より豊富なテレメトリが利用可能になるまで、高レベルの集計数は増加しますが、詳細な内訳は空のままとなります。
一般的なレポートで確認できる内容
例えば、以前のエントプライズ向け単日レポートでは、クライアントテレメトリに由来する 1,000 人のデイリーアクティブユーザーが表示されていたとします。この変更により、同じレポートでは現在 1,050 人となる可能性があります。追加の 50 人は、サーバーサイドのテレメトリからアクティブであることが確認されたが、クライアントテレメトリを受信したことがなかったユーザーです。
実際には、アクティブユーザー数と DAU(デイリーアクティブユーザー)数は即座により完全なものになりますが、次元ごとの内訳(例:totals_by_ide や totals_by_feature など)はまだこれらのユーザーを反映しないため、活動のより大きな割合が未帰属として表示される可能性があります。既存ユーザーに関するトップレベルの合計値と内訳は変更されません。
これは、サーバーサイドのシグナルを Copilot のメトリクスに組み込むという広範な取り組みにおける最初のステップです。サーバーサイドテレメトリから表面化したユーザーは今後含まれるようになり、今後のリリースでは段階的に、より豊富な機能別および表面ごとの詳細情報がこれらのユーザーに帰属されるようになります。これにより、時間の経過とともに空の内訳が埋まっていきます。
これがなぜ重要なのか
データ全体での一貫性の向上:利用状況レポートは、アクティビティログや請求書で確認できる内容とより密接に整合するようになり、「ユーザーが欠落している」という理由によるサポートエスカレーションを引き起こすギャップを削減します。
設計上の耐障害性:サーバーサイドとクライアントサイドの両方のシグナルを組み合わせることで、単一のクライアントサイドでの一時的な不具合によって、レポートからユーザーが消去されることはもはやなくなります。
詳細については、API ドキュメントをご覧ください。
GitHub コミュニティ内のディスカッションに参加してください。
本記事「Copilot 利用状況メトリクスにアクティブユーザーがさらに含まれるようになりました」は、最初に The GitHub Blog で公開されました。