「ITニュース」｜AIコーディングCLIに「.envも渡していた」——xAI「Grok Build」通信解析が示した数字
はじめに
2026年7月13日、セキュリティ調査を行う組織 cereblab が、xAIのAIコーディングCLI「Grok Build」の通信内容を解析した結果をGitHub上で公開しました。GIGAZINEをはじめとする複数の海外メディアがこれを報じています。
この記事では、（1）実際にどれだけのデータが「モデルに読ませた分」を超えて外部に送られていたのか、（2）xAI側が翌日に出した公式説明が、指摘された問題にどこまで答えているのか、という2点を中心に整理します。
※ 本記事は2026年7月13〜14日時点の報道と公式Xポストをもとにした整理であり、xAIによる正式な公開声明（プレスリリース等）は執筆時点で確認できていません。
この記事での用語
1. 何が起きたのか（結論）
cereblabは、mitmproxy（通信を中継して内容を確認するツール）を使い、約12GBのリポジトリを対象にGrok Build（バージョン0.2.93）の通信をキャプチャして解析しました。
実際のモデル推論（`POST /v1/responses`）に必要だったデータは約192KiBだった一方、別のストレージ用エンドポイント（`POST /v1/storage`）経由で約5.10GiBがGoogle Cloud Storageの`grok-code-session-traces`バケットへ送信されていました。約27,800倍の差です。
送信データには、ユーザーがモデルに明示的に読ませていない未読ファイル、`.env`などの認証情報ファイルの内容がそのまま、そしてコミット履歴を復元できるGit bundleが含まれていたと報告されています。
CLI内には`disable_codebase_upload=true`というopt-out設定がありますが、サーバー側でこの設定が必ずしも反映されていなかったことが確認されました。
2026年7月14日午前0時37分（日本時間）、公式X（旧Twitter）アカウント「SpaceXAI」が本件について声明を投稿し、「ZDR利用時は痕跡もコードデータも一切保持されない」「`/privacy`コマンドでデータ保持を無効化でき、過去に同期されたデータの削除もできる」と説明しました。
忙しい方向けに一言でいうと、
「AIにコードを読ませたつもりが、リポジトリ全体・未読ファイル・.envまで別経路で5GB超送られていた」——実測データ量の桁違いの差と、opt-out設定がサーバー側で効いていなかった点が今回の核心です。
2. 何が「問題」とされているのか
指摘されているポイントは大きく2つに分かれます。
データ量の乖離: モデルが実際の応答生成に使ったデータ（約192KiB）と、裏側で別エンドポイントに送られていたデータ（約5.10GiB）の差が大きすぎるという点。ユーザーが「モデルに見せた範囲」と「実際に外部へ送られた範囲」が一致していなかったことになります。
opt-out設定の実効性: クライアント側の設定画面で無効化しても、サーバー側の挙動には反映されていなかった疑いがある点。設定を切ったつもりが切れていない、という状態です。
なお、報道時点でxAIからの正式な公開声明（技術的な原因調査結果や修正計画を含むもの）は確認されていません。IBTimes UKの報道によれば、xAIはサーバー側の遠隔操作で`disable_codebase_upload: true`フラグを有効化する対応を取ったとされ、エンタープライズ向けにはZDRオプションの利用も案内しているとのことです。
3. 公式声明は指摘にどこまで答えているか
SpaceXAIの2026年7月14日の投稿は、「ZDRを利用しているチームでは、痕跡もコードデータも一切保持されない」「Grok BuildのAPIキー利用もZDRを尊重する」「ZDRが無効な場合は`/privacy`コマンドでデータ保持を無効化でき、過去に同期されたデータの削除も行える」という運用面の説明にとどまっています。
一方で、cereblabが指摘した「opt-out設定がサーバー側で必ずしも尊重されていなかった」という技術的な欠陥そのものについて、原因や修正の有無・時期を具体的に示すログや検証結果は、この声明の中では確認できませんでした。つまり、「保持しない仕組みがある」という説明と、「設定した通りに動いていなかった」という指摘は、別のレイヤーの話である可能性があります。
4. 短期・中期・長期の整理
時間軸定義:
短期: 0〜3か月
中期: 3か月〜1年
長期: 1年以上
4-1. 短期（0〜3か月）
予想される動き: xAIによる個別の技術的パッチ（opt-outフラグの実効性確保など）や、エンタープライズ向けZDRオプションの訴求強化が進む可能性があります。
不確実性: xAIが正式な公開声明やインシデントレポートを出すかどうかは、本記事の時点では未確定です。規制当局や監査機関の反応の有無も分かっていません。
効果が出にくい条件: xAIが「仕様の範囲内」として大きな方針転換をしない場合、同様の懸念が他のAIコーディングツールでも指摘され続ける可能性があります。
4-2. 中期（3か月〜1年）
予想される動き: 企業の情報システム部門が、AIコーディングツールの選定基準に「通信内容の透明性」や「データ保持ポリシー」を明示的に組み込む動きが広がる可能性があります。競合ベンダーが通信透明性や監査可能性を差別化として訴求する可能性もあります。
不確実性: 企業側の対応速度は業種・規模によりばらつきが大きく、一律の傾向は予測しにくい状況です。
効果が出にくい条件: 開発者個人の利便性がセキュリティ懸念より優先され、実質的なツールの切り替えが進まない場合、変化は限定的にとどまります。
4-3. 長期（1年以上）
予想される動き: AIコーディングエージェントに対する規制や業界標準（データ最小化原則の明文化、監査ログの義務化など）の議論が進む可能性があります。技術が成熟すれば、必要最小限のコンテキストのみを送信する設計がデフォルト化する可能性もあります。
不確実性: AI関連の規制動向は法域によって大きく異なり、本件単独が規制の直接的な契機になるかどうかは分かりません。
効果が出ない条件: 業界全体でインシデントが散発的にとどまり、統一的な対応枠組みが形成されない場合は、目立った変化は起きにくくなります。
5. 混同しやすい点
まとめ
AIコーディングCLIを業務利用する場合、送信データの範囲を「モデルへの入力」と「バックグラウンド送信」に分けて確認する視点が重要です。
`.env`などの認証情報ファイルは、AIツールの利用可否に関わらずリポジトリに平置きしないことが基本的な備えになります。
社内で許可しているAIコーディングツールについて、送信データの範囲・保存先・保持期間を契約面・技術面の両方で確認しておくと安心です。
ベンダーの公式説明が「運用上のオプション（ZDR等）の説明」なのか「指摘された不具合そのものへの回答」なのかを見分ける癖をつけておくと、今後同種の報道が出た際にも役立ちます。
主な参照
関連記事
免責
本記事は2026年7月13〜14日時点の報道および公式Xポストをもとにした整理であり、xAI公式の見解が確定する前の情報である点にご留意ください。SpaceXAI公式Xポストの内容は、WebFetchでの直接取得ができなかったため、提供された情報をもとにした要約・意訳です。本記事は投資判断や特定製品の利用可否を推奨するものではありません。自社での利用にあたっては、各ツールの最新の公式情報・契約条件をご確認ください。
【PR】
私も転職エージェントを利用して転職しました。
