GitHub CLIがテレメトリ収集を開始、デフォルト有効

GitHub CLIがコマンド実行ごとのメタデータ送信を開始した。バージョン2.91.0からの仕様で、デフォルトで有効。独立したブログ発表はなく、ドキュメント更新と短いプルリクエストだけで、gh利用者はオプトアウトを迫られる状態になった。

GitHub CLIがテレメトリ収集を開始、デフォルト有効

GitHub CLIがコマンド実行ごとのメタデータ送信を開始した。バージョン2.91.0からの仕様で、デフォルトで有効。独立したブログ発表はなく、ドキュメント更新と短いプルリクエストだけで、gh利用者はオプトアウトを迫られる状態になった。


誰にも気づかれずに有効化された

GitHubが、コマンドラインツール「gh」こと GitHub CLI で、匿名化された使用状況テレメトリの収集を始めている。対象は2026年4月22日リリースのv2.91.0以降。デフォルトで有効、オプトアウト方式だ。

目立つ発表はなかった。Changelogに一本の記事、テレメトリ説明ページの追加、リリースノートの短い一文、そして数件のプルリクエスト。これだけで、CI/CDパイプラインや自動化スクリプトで無意識にghを呼んでいる世界中の開発者全員が、Microsoft傘下のGitHubにコマンド実行メタデータを送る側に回った。

GitHubの説明はシンプルだ。機能の使われ方を把握して開発優先度を決めたい、使われていない機能があればUIや発見性を見直したい、というもの。ここまでは一般的な理屈だが、理由の主役に据えられているのは別のものだった。

「AIエージェントのため」に収集する

テレメトリページは、理由の筆頭にエージェント利用を挙げている。

GitHub CLIのエージェント的な利用が拡大するなかで、私たちのチームは機能が実際にどう使われているかを把握する必要があります。このデータは作業の優先順位づけと、機能が実際のニーズに応えているかの評価に使います。

人間のユーザーではなく、AIエージェントがghをどう使うかを見たい。これが前面に出てきたのは興味深い変化だ。ChatGPTClaudeCopilotなどが開発者の代わりにターミナルを叩く時代が前提になっている。ツールを「誰が」使うかの定義が、ここで静かに拡張されている。

実際に収集されるデータは、送信前にローカルで確認できる。GH_TELEMETRY=log を設定してコマンドを叩けば、送信予定のJSONがstderrに出力される。

ログモードでは、通常送信されるJSONペイロードが代わりにstderrに出力される。これにより、テレメトリを有効のままにするかどうか決める前に、すべてのフィールドを確認できる。
{
  "events": [{
    "type": "command_invocation",
    "dimensions": {
      "agent": "",
      "architecture": "arm64",
      "command": "gh repo list",
      "device_id": "1e9a73a6-c8bd-4e1e-be02-78f4b11de4e1",
      "flags": "archived",
      "invocation_id": "eda780f5-27f9-433c-a7ae-7a033361e572",
      "is_tty": "true",
      "os": "darwin",
      "timestamp": "2026-04-16T14:55:13.418Z",
      "version": "2.91.0"
    }
  }]
}

サブコマンド名、使用したフラグ名、OS、アーキテクチャ、インストールごとに生成されるdevice_id、起動ごとのinvocation_id、そして呼び出し元のエージェント識別子。位置引数(リポジトリ名など)やフラグの値、認証トークンは送られない、とGitHubは明記している。

静かな切り替えを実現した1行のプルリクエスト

今回の切り替えは、技術的には極めて小さな変更だ。williammartinというGitHubエンジニアが出した プルリクエスト #13254 のタイトルは「Enable telemetry without env var」(環境変数なしでテレメトリを有効化)。

説明文はたった1行。「テレメトリのゲートとなっていた環境変数を削除し、デフォルトで有効になるようにする」、それだけだ。内部のテスト用フラグ GH_PRIVATE_ENABLE_TELEMETRY を取り外すコミット1本で、世界中のghユーザーが送信者側に回った。

プルリクエストの反応は👎が53件、困惑の😕が8件。承認コメントと混在するなかに、辛辣な言葉が並ぶ。

the enshittification continues.(劣化の継続だ)

PR作者のwilliammartin自身がアムステルダム在住のGitHubスタッフエンジニアで、そこに別のEUユーザーからの抗議コメントも残っている。どうしてオランダ在住で、しかもリーダー職にあるあなたが、EUの仲間を裏切れるのか──オプトアウト方式をGDPRの同意原則に照らして疑う声だ。

Hacker Newsのスレッドでも同様の空気が漂う。「pseudoanonymous(疑似匿名)って、つまり匿名じゃないってことだろ」「テレメトリが入る前のバージョンはどれだ、そこにピン留めしたい」──答えは2.90.0だ。

「匿名」という言葉の曖昧さ

GitHubが使った表現は「pseudonymous(匿名化された)」であり、完全匿名(anonymous)ではない。違いは設計上きわめて重要だ。

device_idはインストール単位で生成されるUUIDで、GitHubアカウントとは紐づかないとされる。ただし、同じマシンからの複数のコマンド実行は同一device_idで束ねられる。invocation_idで個別の起動を識別でき、OSやアーキテクチャで絞り込める。

これは個人特定情報ではないが、個人の行動パターンは追跡できる。プライバシー工学の文脈では、疑似匿名化されたデータが他のソースと組み合わされて再識別されるリスクが繰り返し指摘されてきた。GitHubの内部分析基盤にデータが留まっているうちは問題になりにくいが、「留まる」保証は運用ポリシーに依存する。

そしてPR #13254のコメントでも指摘されているとおり、オプトアウト方式はGDPRの同意原則と整合しにくい。同意は「自由に、具体的に、明確に」与えられるべき、というのが欧州の原則論で、デフォルト有効のメタデータ収集がここにきれいに収まるかは議論の余地がある。


オプトアウトは3通り、どれか1つで足りる

オプトアウト方法は3種類、どれか1つで効く。

環境変数で切るなら export GH_TELEMETRY=false0disabled、空文字などのfalsy値ならすべて有効だ。DO_NOT_TRACK=true という一般的な慣習も受け付ける。

永続設定で切るなら gh config set telemetry disabled。これで ~/.config/gh/config.ymltelemetry: disabled が書き込まれる。環境変数の設定は設定ファイルより優先される。

ひとつ注意点がある。Hacker Newsで指摘されたとおり、v2.90.0で gh config set telemetry disabled を叩くと「'telemetry' is not a known configuration key(認識されない設定キー)」と警告が出る。ただし値はファイルに書き込まれるので、v2.91.0にアップグレードした時点で即座に有効になる。先回りして設定しておいて損はない。

GHESユーザーは対象外だ。認証先がGitHub Enterprise Serverと判定されたアカウントでは、テレメトリは自動的に無効化される。企業の自前GitHubサーバーに繋いでいる開発者は気にする必要がない。一方、GitHub.comに繋いでいる個人開発者、OSSメンテナ、自動化エンジニアは全員が対象になる。

拡張機能には効かない

もう一つ見落とされがちな点がある。テレメトリページが小さく注記しているとおり、gh 本体のオプトアウトはサードパーティの拡張機能には及ばない。gh extensionで入れたツール、スキル、エージェントは各自のテレメトリポリシーを持っており、それぞれのドキュメントで個別に無効化する必要がある。

GitHub Copilot本体やCopilot CLIについても別扱いで、それらのデータ収集は別のポリシーに従う。gh本体を止めても、Copilotを使っていれば別のルートでデータが流れていると考えたほうが現実に近い。


「デフォルト有効」が何度目かの常態化

GitHubはここ数か月、似たパターンを繰り返してきた。ユーザーデータのAI学習利用をいったん取り下げたかと思えば戻し、Copilotでプルリクエストに広告を挿入し、反発を受けて撤回し、今度はCLIのテレメトリ。毎回、最初はデフォルト有効で出す。反発が大きければ調整し、小さければそのまま通す。

悪意のある設計ではないかもしれないが、ユーザー側の信頼を少しずつ削る動き方ではある。コマンドラインツールを選ぶ開発者はGUIを避け、透明性と制御を重視する層だ。そこにデフォルト有効のメタデータ収集を置けば、反発は予測できたはずで、おそらく予測したうえで通している。

オープンソースだから実装は確認できる、送信内容はログモードで見られる、オプトアウトは3通りある──すべて事実だ。ただし、それらが存在することと、ユーザーが事前に知らされずデフォルトで有効化されることは別の問題だ。GitHubが選んだのは後者を許容する設計で、コミュニティの👎53件はそれへの回答だった。


参照元

他参照

関連記事

Read more

英GCHQが初の市販デバイスSilentGlass発表

英GCHQが初の市販デバイスSilentGlass発表

GCHQ傘下NCSCが、HDMIとDisplayPort経由の悪意ある信号を遮断するデバイスSilentGlassを公開した。政府施設で数年前から稼働中という触れ込みだが、何から守るのかをNCSCは答えない。 GCHQが売り始めた「モニター防御装置」 英国の信号諜報機関GCHQが、史上初めて自ブランドの市販ハードウェアを世に出す。国家サイバーセキュリティセンター(National Cyber Security Centre、以下NCSC)が22日、グラスゴーで開催中のCYBERUK 2026で発表したSilentGlassというプラグアンドプレイ型のデバイスだ。 HDMI用とDisplayPort用それぞれに専用機種があり、コンピュータとモニターの間に挟むだけで「予期しない、または悪意ある通信」を遮断するという。NCSCが知的財産を保有し、英国のサイバーセキュリティ企業Goldilock Labsが製造・販売の独占ライセンスを受けた。製造はラズベリーパイ(Raspberry Pi)も受託製造する南ウェールズのSony UK Technology Centreが担う。 NCSC