Grok Build CLIの通信挙動を調査：開発者のコードはどこまで送信されているのか？

2026年7月15日 20:45

今回は、xAIが提供するコーディングツール「Grok Build CLI」の通信内容を詳しく解析した cereblab/grok-build-cli-wire-analysis.md というレポートを参考に、このツールがバックエンドでどのようなデータをやり取りしているのかを整理してみます。

をいをい、これは駄目でしょう。

AIを活用したコーディング支援ツールは非常に便利ですが、ローカルにあるコードがどのように扱われるのか、セキュリティやプライバシーの観点から気になる方も多いのではないでしょうか。こちらの解析結果からは、私たちが思っている以上に「広範囲なデータ」が送信されている可能性が見えてきました。

調査結果のサマリー

解析によって明らかになった、通常のログイン状態におけるGrok Build CLI（grok コマンド）の主な挙動は以下の3点です。

ファイル内容の加工なし送信: .env などの秘匿情報を含むファイルの内容が、そのままの状態で送信されている。
リポジトリ全体のアップロード: エージェントが読み取ったファイルだけでなく、リポジトリ全体（git履歴を含む）がアップロードされている。
送信先の詳細: データはGoogle Cloud Storage（GCS）の特定のバケットに保存されており、設定で「モデルの改善」をオフにしても送信自体は止まらない。

これらの処理の流れを図解すると、以下のようなイメージになります。

今回の解析で特に注目すべき点は、プロンプトで「ファイルを読み込まないで」と指示したとしても、リポジトリ全体がgitバンドルとしてアップロードされているという事実です。

実際に、12GBほどのサイズがある大規模なリポジトリでテストを行ったところ、モデルとの対話に使用されたデータ量はわずか192KBだったのに対し、ストレージへのアップロードには5.10GiBものデータ移動が確認されたそうです。これは、対話データの約27,800倍に相当する規模です。

このアップロードされたバンドルを検証すると、エージェントには「開かないように」と指示していたファイルも、その内容がそのまま含まれていたとのことです。つまり、CLIの操作対象として明示的に指定したかどうかに関わらず、ワークスペース全体が同期されていると考えたほうがよさそうです。

開発者にとって最も注意が必要なのは、.env ファイルなどのシークレット情報の扱いです。

Grok Build CLIは、これらのファイルを「未加工（Raw）」の状態で送信します。送信経路は、モデルへの入力として使われるチャネルと、セッション状態を保存するストレージ用チャネルの2つがあります。

たとえば、APIキーやパスワードが記述されたファイルがプロジェクト内にある場合、それらも「セッションの痕跡（trace）」として、xAIが管理するGoogle Cloud Storage上の grok-code-session-traces バケットへ送られる仕組みになっているようです。

「設定で『モデルの改善（Improve the model）』をオフにすれば、データの送信は止まるのではないか」と考えるのが一般的かと思います。

しかし、今回の解析結果によれば、/v1/settings においてモデル改善の設定をオフにした状態でも、trace_upload_enabled: true（トレースのアップロード有効）というレスポンスが返り、依然としてデータの送信は継続されていたようです。

これは、xAI側が「学習への利用」と「セッション維持のための保存」を区別しているためかもしれませんが、現時点では「設定をオフにしても、リポジトリ内容のアップロード自体を止めることはできない」可能性が高いと言えます。

この解析は、バイナリに含まれる文字列の調査（strings コマンド）や、実際のネットワークトラフィックのキャプチャによって裏付けられています。バイナリ内には、以下のようなGoogle Cloud Storageへのパスや、データ収集用のRustクレートの名前が残されていることが確認されています。

このように、ツールの内部実装レベルで、詳細なログやセッション情報を収集・保存する仕組みが組み込まれていることが伺えます。

Grok Build CLIは、非常に強力なコーディング支援を提供してくれる一方で、その通信挙動はかなりアグレッシブであるという印象を受けました。

特に、リポジトリ全体をgit履歴ごとアップロードする仕様や、シークレットファイルを除外せずに送信する挙動については、企業での利用や機密性の高いプロジェクトでの使用において、十分な検討が必要になるかと思います。

「AIエージェントが賢く振る舞うためには、コンテキストとしてリポジトリ全体を知る必要がある」という設計思想なのかもしれませんが、利用する側としては、「CLIを実行した時点で、そのワークスペースの内容はクラウド側に同期される」という前提で向き合うのが安全かもしれません。

今後、より詳細なドキュメントの整備や、プライバシー制御機能のアップデートが行われることを期待したいところです。

詳しくはこちらをご覧ください。