스크립트
00:00:00Grokが私のユーザーディレクトリ全体をxAIのサーバーにアップロードしていました。SSHキーやパスワード、
00:00:05データベース、ドキュメント、写真、動画などすべてが含まれています。GrokのコーディングCLIがあなたの
00:00:10リポジトリ全体とGit履歴をアップロードしたのです。開かないように指示されていたファイルや、履歴から削除した
00:00:16シークレット情報まで含まれていました。これはGrokチームによる深刻で大規模なミスです。何が起こったのか、
00:00:20自分のコードがアップロードされたか確認する方法、そしてxAIがこの件にどう対処したかを解説します。
00:00:29この問題は、あるツイートで知りました。Grokのログを確認するために特定のgrepコマンドを実行するよう
00:00:33促す内容で、ログにはリポジトリのアップロードを待機している様子が画像で示されていました。
00:00:38そのツイートには数百件のリプライや引用があり、同じコマンドを実行した人たちが同様の結果を報告していました。
00:00:42ホームディレクトリでGrokを実行したあるユーザーは、すべてアップロードされたと報告しています。
00:00:47調査をさらに進めると、Grokにはマルウェアのようなバックグラウンドでのコード収集機能があることが分かりました。
00:00:52具体的に何が行われていたのか、研究者のcereblabによるレポートを見てみましょう。
00:00:56mitmproxyを使ってGrok CLIの通信を解析したところ、彼らはGrokをリポジトリで開き、
00:01:02「OKと返答して。ファイルは一切開かないで」というプロンプトだけを送りました。ところが、
00:01:07そんな指示は無視され、Grokは構わずリポジトリ全体をアップロードしたのです。送信されたPOSTリクエストには、
00:01:12リポジトリのバンドル全体が含まれていました。このバンドルには、すべてのGit履歴や
00:01:16環境変数まで含まれていたのです。これが私が最も問題だと感じている点です。リモートモデルを使う際、
00:01:21コードがサーバーに送られることは周知の事実ですが、普通は読み取る必要があるコードだけが送られるものだと
00:01:26想定します。プロンプトに関係のない部分まで含め、コードベース全体を送信するなんてことはあり得ません。
00:01:30リポジトリが12ギガバイトあっても、すべてアップロードしてしまいます。Claude Code、
00:01:35Cursor、Geminiといった他のツールで検証したところ、これらは読み取るファイルのみを送信していました。
00:01:40これはGrok CLI特有の問題です。さらに「モデルの改善に協力する」設定をオフにしても、
00:01:45やはりアップロードされることが分かりました。
00:01:51「trace_upload_enable」というフラグが常にTrueに設定されていたのです。これらのツイートや
00:01:55投稿が拡散されると、xAIはどう反応したでしょうか。まず、彼らは密かに修正を行いました。
00:02:01騒動の翌日に再び確認すると、件のtraceフラグは無効化されており、
00:02:05新たに「disable_codebase_upload」というフラグが追加され、Trueになっていました。
00:02:10全アカウントに対してサーバー側で強制的にアップロードを止めるキルスイッチを入れたようです。
00:02:14その後、彼らはTwitterで公式に声明を出しました。「我々はユーザーのプライバシーを深く尊重しており、
00:02:19顧客の選択を重視している。データ保持を行わないチームや、トレースデータを保持しない設定の場合、
00:02:24コードデータは一切保持されない。GrokのAPI利用も同様のポリシーに従う」といった内容です。
00:02:30データ保持設定を無効化するには、CLIで「/privacy」コマンドを実行してください。
00:02:36このコマンドを実行すると、以前同期されたデータも削除されます。設定の確認や変更は、
00:02:40いつでもそのコマンドで行えます。イーロン・マスクも、「予防措置として、これまでにxAIへ
00:02:45アップロードされたすべてのユーザーデータは完全に削除する。一つ残らず破棄される」とツイートしました。
00:02:51ただ、別のツイートでは、「問題のデバッグに役立つので、設定をオンのままにしてほしい」とも求めていました。
00:02:55トレース情報の保持自体は一般的なプラクティスかもしれませんが、
00:03:00リポジトリ全体をサーバーにアップロードする点には一切触れていません。
00:03:05新しいアップデートでプライバシーコマンドが追加されましたが、
00:03:10リポジトリ全体をアップロードするコード自体は削除されていません。
00:03:14バイナリを解析すれば今もそのコードを見つけることができます。これが再び有効にならない唯一の理由は、
00:03:18xAIが制御するサーバー側のフラグがあるからに過ぎません。他のツールでは使われていない機能ですし、
00:03:23なぜこのようなコードが存在するのか理解できません。さらに、そのプライバシーコマンドについても検証すると、
00:03:28単にトレースを無効にし、サーバー側の「データ保持を拒否する」というフラグを切り替えるだけです。
00:03:33同じ研究者がこのコマンドを解析したところ、ローカル側では何も動作していないことが判明しました。
00:03:38セッションのトレースは、オンかオフかに関わらず、すべてxAIに送信されています。
00:03:43違いはサーバー側のレスポンスだけで、オフなら保存されたことを示す200が返り、
00:03:48プライバシーモードがオンなら、データを破棄したことを示す204が返るという仕組みです。
00:03:53つまり、これはクライアント側でブロックするものではなく、サーバー側のデータ保持スイッチに過ぎません。
00:03:58結局すべて送信されるわけで、xAIがデータを保存せずに破棄すると信じるしかないのです。
00:04:02さらに悪いことに、このコマンドはセッションごとの切り替えが必要かもしれません。
00:04:07データを安全に保つために、毎回このコマンドを打つ必要があるのです。
00:04:12非常に非効率で納得しがたい仕様です。もし過去にGrok CLIを使用していて、
00:04:17何が漏洩したか確認したい場合は、ログを調べてみてください。
00:04:21このgrepコマンドで、どのセッションでアップロードが行われたかが正確に分かります。
00:04:26セキュリティを真剣に考えるなら、xAIが完全に削除したと確信できない限り、すべてのキーを回転させるべきでしょう。
00:04:30データが送信された可能性があるからです。最後に、Grok CLIを使いつつ少しでもプライバシーを守りたい場合、
00:04:35（あまり推奨はしませんが）Grok CLIをハードニングする方法についての詳細なガイドがあります。
00:04:40設定ファイルでコードベースのアップロードを無効にする方法などが解説されており、
00:04:44これを行えばアップロードパイプラインを完全に停止できるはずです。
00:04:49これが今回の一連の出来事です。なぜかGrokは不要な時までリポジトリ全体をアップロードしており、
00:04:53現在はデータを削除し、機能を撤回したようです。しかし、皆さんは彼らを信頼できますか？
00:04:58今後もGrok CLIを使いますか？ぜひ下のコメント欄で教えてください。
00:05:02チャンネル登録もお願いします。それでは、また次回の動画でお会いしましょう。