Grok Build CLIがxAIに送信しているもの、ワイヤーレベル分析が明かす意外な事実

ベンジャミン・フランクリンの言葉に「三人が秘密を守れるのは、そのうち二人が死んだときだけだ」というものがあります。

情報化社会では、秘密を守るのがますます難しくなっているのかもしれません、、、

さて、最近海外の技術者の間で、xAIの提供するGrok Build CLIが実際にどんなデータをサーバーへ送信しているのか、というワイヤーレベル(通信生データ)の分析が話題になっています。

GitHubに公開された詳細なレポートをもとに、私も興味深く読み解いてみました。

本稿ではその内容を、専門知識のない方にもわかりやすく、一緒に考えながらご紹介したいと思います。

Grok Build CLIの通信の実態

Grok Build CLIは、AIコーディングアシスタントとして、開発者のローカル環境で動作します。

利用者がプロンプトを送ると、CLIは必要なファイルを読み込み、その内容をxAIのサーバーに送信して応答を得る仕組みです。

問題は、どのファイルの内容が、どのように送られるかという点にあります。

レポートによると、CLIは読み込んだファイルの内容を、暗号化されていない平文のまま送信していました。

たとえ.envのような機密情報を含むファイルでも、マスキングされることなく、全文がそのまま送られてしまうのです。

さらに、セッションの状態を保存するアーカイブにも同じ内容が含まれ、こちらもサーバーにアップロードされます。

つまり、APIキーやパスワードといった秘密情報が、ユーザーの知らぬ間に外部へ流出している可能性があるということです。

リポジトリ全体がアップロードされる仕組み

もう一つの衝撃的な発見は、CLIが読み込んだファイルだけでなく、実質的にリポジトリ全体をアップロードしていることです。

分析では、「ファイルを読まずにOKと返答して」というプロンプトを与えても、CLIは.gitバンドルとして、リポジトリの全履歴を含むデータを送信していました。

このデータは、grok-code-session-tracesというGoogle Cloud Storageバケットに保存され、その宛先はバイナリ内にハードコードされているため、ユーザーが設定で止めることはできません。

12GBのリポジトリで試したところ、読み込まれていないファイルを含む約5GBものデータがアップロードされたというのですから、これは意図的な仕様と考えざるを得ません。

何が問題か

技術者として、利便性と引き換えに意図しないデータ流出が起きている点は、看過できません。

特に企業のコードベースで使う場合、秘密情報が第三者に渡るリスクがあります。

また、「モデル改善のためのデータ送信」をオフにしても、このアップロードは継続されるという報告があり、透明性に欠けると言わざるを得ません。

こうした分析は、オープンソースでない部分の動作を知る貴重な手がかりであり、開発者コミュニティが自主的に調査し議論を深めている姿勢には、私も刺激を受けます。

ツールを選ぶ際には、その裏側の動作をきちんと理解することが大切です。

データは宝であり、同時に責任でもあります。

技術の進歩は速く、便利なツールが次々と現れますが、時には立ち止まってその仕組みをのぞいてみるのも良いかもしれませんね。

記事一覧