何が起きたか
The Register経由で報じられたCereblabの調査によれば、Grok Build CLIはユーザーのリポジトリ全体をまとめてGoogle Cloudにアップロードしていました。問題なのは範囲です。Cereblabは、ツールに「開かないよう指示したファイル」や「履歴から削除したはずのシークレット」まで含まれていたと指摘しています。同種のツール、たとえばClaude Codeと比べてもデータ保持の量が著しく多いと評されました。
研究者らによると、月曜時点のテストではSpaceXAIのサーバーが disable_codebase_upload: true というフラグを返すようになり、コードベースのアップロードはもう発火しない（“no longer fires”）状態です。イーロン・マスク氏はXへの投稿で、Grok Buildがこれまでにアップロードしたデータはすべて削除する（“completely and utterly deleted”）と述べました。別の投稿では「プライバシー設定は常に尊重される」としつつ、デバッグに役立つのでデータ保持を許可してほしいとユーザーに呼びかけています。
なぜ重要か
これは「うっかりログが多かった」という話ではありません。King’s College Londonの独立セキュリティ研究者Lukasz Olejnik博士はThe Vergeに対し、この量のデータ保持は過剰（“excessive”）だと述べ、リスクにさらされうる対象として自社の独自ソースコード、脆弱性に関する情報、個人データ、インフラ構成、そして認証情報を挙げました。
つまり、流出しうるのは「コード」ではなく「攻撃の設計図」です。脆弱性情報とインフラ詳細とクレデンシャルが一式で外部に置かれる状態は、単体のコード漏洩よりはるかに悪い。しかも「開くな」と指示したファイルが含まれていたという点が本質で、開発者が敷いた除外設定が信頼できないなら、ツールの設定画面はセキュリティ境界として機能しません。
「対処法」をめぐる食い違い
初期対応として、SpaceXAI側はCLIの /privacy コマンドでデータ保持を無効化でき、同時に過去に同期されたデータも削除されると案内しました。これに対しCereblabは、/privacy はセッション単位の保持トグルであって今回の問題を修正したスイッチではない、だからそれを「対策」として案内すべきではない、と反論しています。
この応酬は、AIコーディングツール全般の弱点を可視化しています。ユーザーに見えているプライバシー設定と、実際にデータ送信を止めているサーバー側フラグ（disable_codebase_upload）が別物だった、ということだからです。ユーザーはUI上の設定を信じるしかないのに、その設定は挙動を保証していなかった。
💼 事業会社視点：これは自社にどう効くか
日本企業にとって最も切実なのは、受託開発とSaaSです。受託開発会社は顧客のソースコードを預かる立場であり、NDAで「第三者へ開示しない」と約束しています。エンジニアが個人判断でAIコーディングCLIを入れ、リポジトリ全体が外部クラウドへ送られていたとすれば、それはNDA違反の説明責任が会社に降りかかる事案です。「知らなかった」は通用しません。
経営者・事業責任者が今週やるべきことは3つです。第一に、開発現場でどのAIコーディングツールが実際に動いているかの棚卸し。許可制にしているつもりでも、CLIは個人が勝手に入れられます。第二に、.gitignore や除外設定を信頼した運用の見直し。今回、除外指示が守られていなかったのですから、そもそもリポジトリにクレデンシャルを置かない・Secret Managerへ寄せる、という設計側の対策しか効きません。第三に、SaaS事業者であれば、自社の顧客に対して「当社の開発でどのAIツールをどう使っているか」を説明できる状態にしておくこと。エンタープライズ商談のセキュリティチェックシートに、この項目が入ってくるのは時間の問題です。
AI開発ツールは生産性の武器ですが、導入判断は「便利かどうか」ではなく「データがどこへ行くか」で行う時期に入りました。