GitHub CLI が匿名化されたテレメトリの収集を開始
(cli.github.com/telemetry)- GitHub CLI は匿名化されたテレメトリを送信し、その目的は機能利用の可視性を確保し、製品改善を支援すること
- サブコマンドの採用状況や flags の使用パターンに基づいて作業の優先順位を決め、ユーザーの要求を満たしているかを評価し、discoverability と design の見直しに活用される
- オープンソース実装のため、
cli/cliリポジトリでテレメトリコードを直接確認でき、logging mode で実際に送信する前の JSON payload を確認可能 - オプトアウトは環境変数
GH_TELEMETRY=false、DO_NOT_TRACK=true、またはgh config set telemetry disabledで可能で、環境変数は config より優先される - テレメトリイベントはGitHub の内部分析インフラに送信され、このページは
ghのクライアント側データ収集のみを扱い、extensions と Copilot CLI は別対象
テレメトリ
- GitHub CLI は匿名化されたテレメトリを送信し、その目的は製品改善を支援すること
- どのデータが送信されるのかと、その理由をユーザーが理解できるよう情報を提供
テレメトリを収集する理由
- GitHub CLI 機能の利用可視性を確保する必要性に言及。特に agentic adoption の増加に伴い、実際の利用方法を把握することが目的
- チームはこのデータを使って作業の優先順位を決定
- 機能が実際にユーザー要求を満たしているかを評価
- 新しいサブコマンドのリリース後の採用状況を確認する目的を明示
- 利用者がほとんどいなければ、その機能の discoverability や design を再検討する必要がある
- 特定の flags とともに高い利用量が確認されれば、より良い体験に投資すべきポイントを把握できる
テレメトリの確認
- GitHub CLI はオープンソースであり、テレメトリ実装を
cli/cliリポジトリで直接確認可能 - 実際には送信せず、送信予定のデータを確認するにはlogging modeを使用可能
- 環境変数での設定に対応
export GH_TELEMETRY=log
- CLI 設定での指定にも対応
gh config set telemetry log
- 環境変数での設定に対応
- logging mode では、本来送信されるJSON payloadが stderr に出力される
- テレメトリを有効のままにするか決める前に、各フィールドを確認できる
- 例として
GH_TELEMETRY=log gh repo list --archivedを提示
- サンプル payload に含まれるイベント情報を明示
- イベントタイプ
command_invocation - dimensions 項目として
agent,architecture,command,device_id,flags,invocation_id,is_tty,os,timestamp,versionを含む - 例の値として
architecture: arm64,command: gh repo list,flags: archived,os: darwin,version: 2.91.0を表示
- イベントタイプ
- 該当コマンドでは、実行された正確なコマンドとコンテキストに関するテレメトリのみをログ出力できる
- 環境変数を変更すると、payload に含まれる events や event dimensions が変わる場合がある
- 認証済みアカウントを変更した場合も、含まれる項目が変わることがある
オプトアウト方法
- logging mode で確認したテレメトリについてオプトアウト可能
- 環境変数での設定に対応
export GH_TELEMETRY=false- falsy 値として
0,false,disabled, 空文字列を使用可能 DO_NOT_TRACKの慣例にも対応し、export DO_NOT_TRACK=trueの例を提示
- CLI 設定での指定にも対応
gh config set telemetry disabled
- 環境変数の優先順位は config 値より高い
データの送信先
- テレメトリイベントは GitHub の内部分析インフラに送信される
- データ処理方法に関する追加情報は GitHub General Privacy Statement を参照するよう案内
追加情報
- GitHub CLI は GitHub およびサードパーティ extensionsのインストールによる機能追加をサポートし、agents も含む
- これらの extensions は独自に利用データを収集する可能性がある
- オプトアウト設定では制御されない
- 各 extension のドキュメントで、テレメトリの報告方法と無効化可否を確認する必要がある
- このページは GitHub CLI
ghのクライアント側データ収集のみを扱う- GitHub Copilot および Copilot CLI には適用されない
- Copilot CLI は別途データ収集を行う
- 関連情報の場所として
Using GitHub Copilot CLI,Responsible Use of the GitHub Copilot CLIを案内
1件のコメント
Hacker Newsのコメント
なぜ企業の開発チームはいつもテレメトリでユーザーを見たがるのか疑問だ
良いエンジニアリングとデザインだけでは十分ではないのかと聞きたい
Gitは20年以上、誰がどの機能やコマンドを使っているかという詳細な分析なしでもうまく回ってきたのに、テレメトリがあったことで本当に良くなっていたのか、それとも単にノイズデータが増えただけなのか疑わしい
analyticsがないと目隠しして運転しているようなものだ
ユーザーが本当に何を重要視しているのか、どのフローを最適化すべきか分からないし、人が言うことと実際のソフトウェアの使い方の差は驚くほど大きい
人から良いフィードバックを得るのは難しいことも多く、みんなが機能Xのアイデアは良いと言っていても、実際にはまったく使われないことがある
また、声の大きいファン層がいるように見えても、売上や実利用につながらないこともある
Gitもテレメトリがあればもっと良くなっていた可能性が高いと思う
Gitは有名なくらいUIが悪い
初期にどれだけ多くの人がつまずいているかがデータではっきり見えていただろうし、たとえば
git checkout -- foo.txtのような直感的でないコマンドの代わりにgit restoreのような改善がずっと早く入っていたはずだツールを直接使わない人たちは実際の使われ方を理解できないので、開発ツール担当のPMが自分の仕事をするためにこうしたデータを求めることになる
ECのPMがフロントエンドに追跡スクリプトを大量に載せるのと似た構図に見える
エンジニアだけでも十分にユーザーとの相互作用を設計できたのに、VC以降、技術製品を深く非技術的な人が率いるパラダイムが定着したのが問題だと感じる
結局データは彼らの手に渡り、誰かがPMの給料を正当化することになるように見える
自分にはそれが明白ではない
エンジニアがエンジニアのためにインターフェースを作り、良いフィードバックループがなかった代表例のように見える
皮肉なことに、この例そのものが、開発者は自分の製品が実際にどう使われているかをもっと理解すべきだということを示していると感じる
開発者の頭の中の利用シナリオはたいてい現実とかなり違う
ghCLIのopt-out問題は思ったより複雑だと思うghはCI/CDパイプラインやサーバー環境でも動くが、そうした環境ではプライバシーのためではなくネットワーク制約のために、github.comへの外向き接続自体を望まないことがあるそのような場所ではテレメトリがデフォルトで有効だとCIが失敗したり、Bastion hostがGitHubにまったく到達できなくなる可能性がある
一方でGit自体は、ユーザーが明示的にpushするまでは完全にローカルで動作する
信頼モデルが違うということだ
Gitは設定しない限り絶対にphone homeしないが、
ghはGitHub APIを包むラッパーなので機能上呼び出しが必要な点は認めるただ、その事実とは別に、コマンドの使用パターンまで追加で収集してアップロードする必要があるのかは別途検討すべきだと思う
ghがGitHub.comに接続できなければ、実質的に役に立たないのか気になるそれともenterprise GitHubへの接続が主なユースケースなのだろうか
開発者3人がコードベースのある領域に時間の80%を使っているのに、実際には利用がなく、今後も現実的に増える見込みがないなら、その人員を別の場所に回すか、機能自体を再考した方がよいかもしれない
ただ、こうしたanalyticsの問題は、無害に使うこともできる一方で、固有識別子と行動パターンを結びつければ機械学習で個人を再特定できるという理解が前提にある点だ
タイムスタンプまで含まれるとさらに深刻になる
だから、いつどのテレメトリが送信されるのかを正確に示してほしいと思う
たとえば送信はしないが、verboseモードで何が送られるのかを表示するオプションを用意し、ユーザーがそれを確認してから有効にするか決められるようにすればよい
Steam Hardware Surveyのように、何が送られるのかを見せる方式が適切だと感じる
すべての
ghコマンドは結局GitHub APIラッパーにすぎないのに、この議論がそこでさらにややこしくなっていると感じるこういう短いPRは好きだ
https://github.com/cli/cli/pull/13254
内容も単純で、テレメトリを防いでいたenv varを削除し、これでデフォルト有効に変更するという意味に読める
enterpriseを除けば、実質的に強制的に有効になる構造のように見える
先月ホームラボにgiteaをデプロイしたが、本当に満足している
GitHubからの取り込み機能もあるし、正直GitHubより速く、稼働率も良いと感じる
Claudeも
teaCLIとGitで問題なく連携するし、ほとんどGitHubのクローンのようだが、今のところむしろこちらの方が良いと思う速度も速く、稼働率も良い
しかも机の横のキャビネットにあるPi 4で動いているので、インターネットが切れても動き続ける
バックアップはborgとsyncthingでオフサイトにも送っている
設定には少し手間がかかったが、その後のメンテナンス時間はほぼゼロに近い
2週間に一度くらいSSHで入り、SSDの空き容量、RAM使用量、
apt update、upgrade、メジャーバージョンアップだけ確認すれば済むGitHubはすでに自分のサーバーに入ってくるすべてのリクエストを収集・集計していると思わないのだろうか
結局
ghCLIの存在理由も、そのサーバーとやり取りすることにあるリクエストの追跡自体を望まないなら、この設定ひとつよりはるかに多くのものをopt-outしなければならないと思う
ただ今回はクライアント側メトリクスも加えて、GitHubだけでなくGitLab、Codebergのような他所へ向かう流れまで、よりよく追跡したいように見える
GitHubにとっては良いことかもしれないと思う
どの会社もこうしたデータを必要としていて、製品改善に使うところもあれば、あまり良くない目的に使うところもある
HNユーザーがテレメトリを嫌うのは分かるが、SaaSを自分で作ったことがあるならtelemetryが事実上必須だと分かるようになると感じる
結局対話がない点を問題にしたい
本質はディテールにあり、ユーザーと製品の作り手のあいだで、双方が納得できる中間地帯を作ってくれる信頼できる仲介サービスのようなものがあるのか考えている
Claudeの助けを借りて調べた内容をGistにまとめていると述べている
MicrosoftのEmbrace, extend, extinguishを思い出させる
最初の2段階はすでに進んでおり、5年以内にGH CLIがGitHubリポジトリとやり取りする唯一の方法になると予想する
そうなれば3つ目の段階も完成し、サイクルが終わると思う
どれだけ賭けるのか聞きたいくらい非現実的な見通しに感じる
人々はWSL、GPUサポート、WSLg、PowerShellにもずっとEEEの枠組みを当てはめてきたが、実際にはそうはならなかった
今もそうだし、そもそもそうした計画の痕跡すらあまり見えない
勘で解釈するのではなく、90年代のMicrosoftが実際に使っていた再現可能な手口が、今どこで再現されているのか証拠を示してほしいという立場だ
Microsoft Gitがオープンソース版より多機能で囲い込んでいるわけでもないし、Microsoft Linuxも同様だ
GitHubはGitの上のラッパーであり、HTTPとSSHの上で動くGitサーバーという中核設計がある
その基盤を壊してリポジトリアクセスを
ghのみに縛るのは大きすぎる変更で、現実味が薄いと思うghは単にAPI呼び出しを簡単にするツールにすぎず、大多数のGitHubユーザーはその存在すらよく知らないと感じるむしろGitHubを壊す可能性が高いのは悪意あるEEEではなく、無能な経営だと思う
ユーザーと製品を理解していない経営陣のせいで失速する可能性の方が大きいと感じる
すでに一部のリポジトリは
ghなしでは扱いづらく感じられ、強制的なフローが少しずつ生まれていると思うghが具体的に何を追加で提供するのかは使ったことがないので分からないが、自分には標準のGitコマンドで十分だここでいう
pseudonymous telemetryが仮名化テレメトリを意味するのか、それとも実際には匿名ではないテレメトリを意味するのか混乱するこの2つの表現はほとんど逆の意味なのに、今の文言だと識別可能なデータを収集すると言っているように見える
pseudoanonymousはHN投稿者が作った表現に見える各マシンにUUIDが付与され、それを基準にマシンを識別する構造のように見える