Grok Buildを使っていました。何をすればいいですか？

まず認証情報のローテーション（作り直し）を最優先で行ってください。.envファイルのAPIキー、DBパスワード、トークン類が対象です。過去のコミット履歴に混入したシークレットも送信対象だったため、履歴に残っている古いキーも作り直す必要があります。xAIは/privacyコマンドでの保持設定オフを案内しています。

「モデルの改善に協力する」をオフにしていれば安全でしたか？

いいえ。今回の問題の中心はまさにそこで、このトグルをオフにしてもサーバー側は trace_upload_enabled を true のまま返し続け、アップロードは止まりませんでした。設定画面上の表示と実際の挙動が一致していなかったことになります。

xAIは修正しましたか？

2026年7月13日に、サーバー側の設定でリポジトリのアップロードが停止したことが確認されています。イーロン・マスク氏は、すでにアップロードされたデータを削除すると表明しました。ただし削除の完了は執筆時点で外部から検証できていません。

Grok Buildが全リポジトリを無断アップロード｜AIコーディング6事件の共通点

xAIのGrok Build CLIが、AIが読んでいないファイルまで含めたGitリポジトリ全体をクラウドに送信していた問題。「収集オフ」の設定は効いていませんでした。手口・影響範囲・いま打つべき対策を、過去の類似事件と並べて整理します。

自分のパソコンにあるはずのソースコードが、気づかないうちに丸ごとクラウドへ送られていた——しかも、「データ収集はオフ」にしていたのに。

xAIのAIコーディングツール「Grok Build」で、この状態が起きていたことが判明しました。送られていたのはAIが実際に読んだファイルだけではありません。Gitの全履歴を含むリポジトリ丸ごとでした。

ニュース元: Grok Build Uploaded Entire Git Repositories to xAI Storage, Not Just Files It Read（The Hacker News）

まず結論

xAIの「Grok Build」CLI（v0.2.93で検証）が、Gitリポジトリ全体を grok-code-session-traces という名前のGoogle Cloud Storageバケットへ送信していた
送られていたのはAIが開いてすらいないファイルも含む。コミット履歴も丸ごと
.env に置かれた検証用の偽APIキー・DBパスワードが、マスクされないまま送信データの中で見つかった
「モデルの改善に協力する」トグルをオフにしてもアップロードは止まらなかった
12GBのリポジトリで、AIの処理に必要だった通信が約192KB、一方ストレージへの送信は5.10GiB。約27,800倍の開き
2026年7月13日にサーバー側設定で送信は停止。マスク氏はアップロード済みデータの削除を表明
使っていた人がいま最優先でやるべきは、認証情報の作り直し

何が起きていたのか

発見したのは、cereblab という名前で活動するセキュリティ研究者です。Grok Build のバージョン0.2.93を対象に、ツールが実際に何をネットワークへ送っているかを通信レベルで記録し、その結果をGitHub上に公開しました。

見つかったのは、2本の通信経路です。

通信先	用途	12GBリポジトリでの送信量
`/v1/responses`	AIモデルとのやりとり（本来必要な通信）	約 192 KB
`/v1/storage`	`grok-code-session-traces` バケットへの送信	約 5.10 GiB（75MB × 73チャンク）

コーディング作業に必要だったデータの、約27,800倍が別経路で外へ出ていた計算になります。

決定的だったのは、研究者が仕込んだ「カナリア」です。src/_probe/never_read_canary.txt という、AIには一度も読ませていないファイルを置いておいたところ、それが送信データの中から見つかりました。つまり送信対象は「AIが作業で参照したファイル」ではなく、リポジトリそのものだったわけです。

同じ手口で .env ファイルに置いた偽の API_KEY と DB_PASSWORD も確認されました。伏せ字にもされず、そのままの文字列で送信データに含まれていました。

⚠️ ここがいちばん重い ファイルが送られたこと自体より、シークレットが素通しだったことのほうが深刻です。APIキーやDBパスワードは、漏れた瞬間に「他人がそのまま使える鍵」になります。しかもGitのコミット履歴ごと送られているので、「昔うっかりコミットして、あとで消したキー」まで対象に入ります。

「収集オフ」が効かなかった、という部分

Grok Build には「Improve the model（モデルの改善に協力する）」というトグルがあります。多くの開発者はこれを「データ収集のオン・オフ」と読みます。

ところが、これをオフにしても、サーバーからの応答は trace_upload_enabled: true を返し続けていました。研究者の分析によれば、内部には複数のフラグがあり、そのうちユーザーに見えていたのは1つだけだったとされています。

ここは、技術的なバグと、設計上の問題の区別が必要です。トグルが単に壊れていた（バグ）のか、そもそもトグルと送信機能が別系統だった（設計）のか。外部からは断定できません。ただ利用者から見れば結果は同じで、設定画面を信じて操作した結果、期待した保護が得られなかったことになります。

過去のAIコーディング事件と並べると何が見えるか

この手の話は、今回が初めてではありません。AIコーディングツールをめぐる情報流出・混入の事件を並べてみます。

事件	何が起きたか	構造的な原因
Grok Build（2026年7月）	リポジトリ全体＋Git履歴＋シークレットをクラウドへ送信。オフ設定が無効	送信範囲がユーザーの認識と乖離。設定と挙動の不一致
M365 Copilot「SearchLeak」（2026年）	権限のない社内文書がCopilot経由で読めてしまう脆弱性	AIが「見える範囲」の設計ミス
Samsung社員のChatGPT入力（2023年）	半導体の社内ソースコードをChatGPTに貼り付け、社外へ流出	利用者側の運用ミス。ツールは仕様どおり動いていた
バイブコーディングの設定ファイル流出	AIに生成させたコードに認証情報が平文で残る	生成物のレビュー不足
プロンプトインジェクション経由のコード窃取	外部から読ませたファイルに指示を仕込まれ、AIが機密を送信	AIが「データ」と「命令」を区別できない
AIエージェント経由のパッケージ汚染	存在しないパッケージ名をAIが提案し、攻撃者が同名で登録	AIの出力を無検証で実行

（各事件の詳細は本記事末尾の関連記事を参照）

並べると、原因が3種類に腑分けできます。

利用者の運用ミス（Samsung型）— 貼ってはいけないものを貼った。ツールは正しく動いていた
AIの仕組み上の弱点（プロンプトインジェクション型）— AIが命令とデータを区別できないことに由来する
ツール提供者の設計・実装（Grok Build型、SearchLeak型）— 利用者が正しく操作しても防げない

今回のGrok Buildは3番目です。ここが厄介な理由は明確で、利用者側の注意では防げないからです。「機密を貼らない」「生成物をレビューする」といった一般的な心がけは、リポジトリを丸ごと送られてしまう挙動には無力です。ツールをインストールして、普通に使っただけで対象になります。

だから対策も、心がけではなく構造で打つ必要があります。

いま何をすべきか

Grok Build を使ったことがある人

優先度順に3つです。

✅ 認証情報を作り直す（最優先）— .env にあったAPIキー、DBパスワード、各種トークン。過去のコミット履歴に混入していた古いキーも対象です。履歴ごと送信されているため、「消したつもり」は通用しません
✅ /privacy コマンドで保持設定をオフにする — xAIが案内している手順です
✅ 業務コードで使った場合は、社内のセキュリティ担当に報告する — 判断を個人で抱え込まない

xAIは2026年7月13日にサーバー側でアップロードを停止し、イーロン・マスク氏はアップロード済みデータを削除すると表明しました。ただし削除が完了したかどうかを、外部から検証する手段は執筆時点でありません。「削除されたはず」を前提に動くのは避けたほうが安全です。

AIコーディングツール全般を使う人

今回の件は、xAI固有の問題として片づけないほうがいい。同じ構造のリスクは、どのCLI型AIツールにもあります。

✅ シークレットをリポジトリに置かない — 環境変数や専用のシークレット管理（1Password、AWS Secrets Manager等）に逃がす。これは今回のようにツールがリポジトリを丸ごと送っても、鍵が入っていなければ被害が出ない、という構造的な守り方です
✅ 業務コードで使うツールは、通信仕様を公開しているものを選ぶ — 「何を送るか」を明文化していないツールは、業務では使わない
✅ プライバシー設定を信じきらない — 今回のように、表示と挙動が食い違うことがある

💡 正直な本音 「AIツールは便利だから、多少のデータ送信は仕方ない」——正直、わたしもそう思っていた側です。でも今回のケースは「多少」ではありませんでした。必要量の27,800倍を、オフにしたはずの設定を無視して送っていた。これは対価として受け入れる話ではなく、期待と実装がずれていた話です。

一方で、xAIを叩いて終わりにするのも違うと思っています。CLI型のAIツールは、原理上こちらのファイルシステムを読める場所にいます。「何を読むか」ではなく「何を送るか」を検証した人がいて初めてわかった——それが今回の教訓です。