RTKのテレメトリは「デフォルトON」ではない：誤解の整理
日本語圏で「RTK（Rust Token Killer）はテレメトリがデフォルトONだ」という情報が流れている。結論から言うとこの情報は誤りだ。公式READMEは次のように明確に書いている。
Telemetry is disabled by default and requires explicit opt-in consent
RTKはClaude CodeやCursorのトークン消費を60〜90%削減するCLIプロキシで、RTK導入完全ガイドで紹介した通り、フック1行で透過的に動作する。便利なツールほど「ユーザーデータが外部に流れるのでは」という懸念が生まれやすいが、RTKは明示的opt-inを必須とし、同意なしに送信を開始しない設計になっている。
この記事ではRTK v0.35.0のREADMEを一次情報として、テレメトリの実挙動を検証する。送信されるデータ・送信されないデータ・操作コマンド・他CLIツールとのプライバシー比較を順に整理した。
RTKテレメトリの動作フロー：opt-inから送信まで
RTKのテレメトリは「ユーザーが明示的に有効化した場合のみ、1日1回、匿名の集計データを送信する」という流れで動く。
初期状態: テレメトリOFF"] --> B{"rtk telemetry enable
実行?"} B -->|実行しない| Z["送信なし
（デフォルト状態）"] B -->|実行する| C["対話プロンプトで
明示的同意確認"] C --> D["consent=true
ローカル設定保存"] D --> E["1日1回の送信処理
集計データのみ"] E --> F{"RTK_TELEMETRY_DISABLED=1
設定あり?"} F -->|あり| G["送信ブロック
同意有無を問わない"] F -->|なし| H["匿名エンドポイントへ
POST送信"] style A fill:#4A90D9,color:#fff style Z fill:#50C878,color:#fff style G fill:#E67E22,color:#fff style H fill:#9B59B6,color:#fff
テレメトリが実際に送信される状態に到達するには、以下2つの条件がいずれも必要だ。
- ユーザーが
rtk telemetry enableを実行し、対話プロンプトで同意している - 環境変数
RTK_TELEMETRY_DISABLED=1が設定されていない
どちらか一方が欠けた時点で送信は発生しない。この二重ガードの設計は、個人の同意と組織レベルのポリシー制御を両立させるためのものだ。
送信されるデータ：11カテゴリの内訳と匿名化設計
opt-inした場合に送信されるデータは、READMEに明記された11カテゴリに限定される。内訳は以下のとおり。
| カテゴリ | 送信内容 | 目的 |
|---|---|---|
| 識別子 | 塩付きSHA-256のdevice_hash（不可逆） | ユニークインストール数のカウント |
| 環境 | RTKバージョン・OS・アーキテクチャ・インストール方法 | 動作環境の統計 |
| 利用量 | 24h/30d/累計のコマンド数・節約トークン数 | 利用頻度と効果測定 |
| 品質 | Top5パススルーコマンド・パース失敗数・節約率<30%のコマンド | フィルタ改善の優先順位 |
| エコシステム | コマンドカテゴリ別の分布（％） | どのカテゴリが主要か |
| 定着度 | 初回利用からの日数・直近30日のアクティブ日数 | リテンション分析 |
| 連携 | AIエージェントのフック種別・カスタムフィルタ数 | どのAIツールで使われているか |
| 設定 | 設定ファイル有無・除外コマンド数・プロジェクト数 | 設定のバリエーション |
| メタコマンド | gain / discover / proxy / verify の利用回数 |
機能別の人気度 |
| 経済価値 | 推定USD節約額（APIトークン価格ベース） | 全体のコスト削減効果 |
| 頻度 | 送信は1日1回 | - |
device_hashはローカルランダム塩付きのSHA-256ハッシュで、元のホスト名やユーザー名を逆算することはできない。コマンド名を送信する場合もツール名のみ（git、cargo、docker など）で、引数・ファイルパス・フルコマンドラインは送信対象外だ。
特に注目すべきは「節約率<30%のコマンド」の送信ロジックだ。フィルタが十分に効いていないコマンドをツール名レベルで共有することで、RTK開発者が優先的に改善すべきコマンドを把握できる。ユーザー個別の失敗事例ではなく、全体の統計として集約される。
送信されないデータ：プライバシー保護の線引き
RTKが「送らない」と明記しているデータはかなり厳密だ。READMEの該当箇所を引用すると以下のとおり。
# RTK READMEに列挙された「送信されない」項目
- source code # ソースコード
- file paths # ファイルパス
- command arguments # コマンド引数（git commitメッセージ等）
- secrets # シークレット値
- environment variables # 環境変数の中身
- personal data # 個人情報
- repository contents # リポジトリの内容
コマンドプロキシという性質上、「git log や docker logs の実出力がサーバーに届くのでは」と懸念する人は多い。しかしRTKはコマンドの実行結果そのものは一切送信しない。送られるのは「git カテゴリが24時間で何回呼ばれた」「平均節約率は何%だった」といった集計値だけだ。
Claude Codeのベストプラクティスを考えるとき、この線引きはレビューする価値がある。業務用のリポジトリで使うかを判断する場面で、「何が送られうるか」を正確に把握しておけばリスク評価が現実的になる。少なくとも「プロプライエタリなコードが漏れる」という懸念は、公式仕様の範囲では当てはまらない。
有効化・無効化・消去の操作コマンド
RTKはテレメトリに関する操作を4つのサブコマンドで提供している。いずれもローカルで完結する。
# 現在の同意状態を表示
rtk telemetry status
# 有効化（対話プロンプトで明示的同意が必要）
rtk telemetry enable
# 無効化（同意撤回、以降の収集を即座に停止）
rtk telemetry disable
# 完全消去（同意撤回 + ローカル削除 + サーバー側削除リクエスト）
rtk telemetry forget
さらに環境変数による強制ブロックも用意されている。
# 同意の有無を問わず送信をブロック
export RTK_TELEMETRY_DISABLED=1
# ~/.zprofile や ~/.bashrc に記述して永続化
echo 'export RTK_TELEMETRY_DISABLED=1' >> ~/.zprofile
# Dockerfile の場合
# ENV RTK_TELEMETRY_DISABLED=1
# GitHub Actions の場合
# env:
# RTK_TELEMETRY_DISABLED: "1"
企業環境で全社的にテレメトリを無効化したい場合、組織のdotfiles管理リポジトリやベースイメージのDockerfileに RTK_TELEMETRY_DISABLED=1 を仕込めば、開発者が誤って rtk telemetry enable を実行しても送信は発生しない。監査可能な形で組織ポリシーを担保できる。
他のCLIツールと比較したRTKのプライバシー設計
CLIツールのテレメトリはデフォルトONでopt-out方式のものが多い。代表的なツールと比較するとRTKの位置づけが見える。
| ツール | デフォルト | 方式 | 送信内容の粒度 | 消去リクエスト |
|---|---|---|---|---|
| RTK | OFF | 明示的opt-in | 集計値・ツール名のみ | rtk telemetry forget |
| Homebrew (analytics) | ON | opt-out（HOMEBREW_NO_ANALYTICS=1） |
コマンド・インストールしたformula | 仕組みなし |
| npm | ON（一部） | opt-out（npm config set send-metrics false） |
バージョン情報等 | 仕組みなし |
| VS Code | ON | opt-out（telemetry.telemetryLevel） |
機能利用・エラー詳細 | サポート問合せ経由 |
| Next.js | ON | opt-out（npx next telemetry disable） |
ビルド時間・機能利用 | 仕組みなし |
RTKはopt-in ＋ 集計限定 ＋ CLI側で消去リクエスト可能の3点が揃っている。OSSツールで forget に相当するデータ消去コマンドをCLI側に用意している例は多くない。GDPR等の規制を意識した設計と推測できる。
ただし「opt-inだから無条件で有効化していい」という話でもない。rtk gain はローカルで同等の節約統計を確認でき、全ユーザーが送信しなくてもツール開発者が知りたい「削減効果」は各自で把握できる。送信の対価として個人が得る直接的なメリットは少ないため、業務用途なら無効化のまま運用しても問題ない。自律型AIエージェントを長時間稼働させる場面でも、RTK本体の機能はテレメトリ同意の有無とは無関係に動作する。
まとめ：opt-inだからこそ知っておきたい挙動
RTKのテレメトリについて日本語圏で流れている情報を整理すると次のようになる。
- デフォルトはOFF: インストール直後は送信されない。
rtk telemetry enableによる対話同意が必須 - 送られるのは集計値のみ: 11カテゴリの数値・バージョン情報・匿名ハッシュ。コード・パス・引数は対象外
- 二重の無効化手段: サブコマンドによる同意撤回と、環境変数による強制ブロックが両方使える
- 消去リクエスト可能:
rtk telemetry forgetでサーバー側の削除リクエストまでCLIから実行できる
Claude Codeの自律エージェント運用では削減効果が特に大きく、RTKの導入を検討する機会は増えている。「テレメトリがデフォルトON」という誤情報で判断を歪めず、一次情報の仕様に沿って評価すればいい。社内セキュリティレビューの場でも、動作フローと送信データのカテゴリを把握しておけば必要十分な説明ができる。
RTK本体の機能・導入手順・4つの圧縮戦略についてはRTK導入完全ガイドで詳しく解説しているので、テレメトリ設定と合わせて参照してほしい。
