何が起きたか
xAIのコーディングエージェント「Grok Build」を巡り、付属のgrok CLIツールがユーザーのディレクトリ全体をxAIのGoogle Cloud Storage（GCS）バケットにアップロードしていたことが発覚し、コミュニティから強い反発が起きました。あるユーザーはホームディレクトリで実行したところ、「SSH鍵、パスワードマネージャのデータベース、書類、写真、動画、すべて」がアップロードされたと報告しています。
この挙動について公式な理由の説明はありませんでしたが、xAIはフィードバックを受けて機能を無効化。さらに信頼回復のためとみられる形で、Grok Buildのコードベース全体をxai-org/grok-buildとしてApache 2.0ライセンスで公開しました。
データ保持を巡る対応
xAIは、早期ベータではZDR（ゼロデータ保持）対象外ユーザーに対してデータ保持がデフォルトで有効だったと認め、これをフィードバックに基づき変更したと説明しています。7月12日以降は全ユーザーでデフォルト保持を無効化し、「これまでにアップロードされた全ユーザーデータは完全かつ徹底的に削除する」と表明。ユーザーは自前の推論環境でGrok Buildを完全にオープンソース・ローカルファーストで動かせるとしています。
公開されたコードの中身
公開されたコードはSLOCCount計測（空白・コメント除く）で844,530行のRustで、うちベンダリング（外部取り込み）は約3%程度。比較対象のopenai/codexは950,933行です。リポジトリはコードを公開する単一コミットのみで、開発の履歴はうかがえません。
技術的には示唆に富みます。xai-grok-markdown/src/mermaid.rsはUnicode罫線でMermaid図を描く自己完結型のターミナルレンダラで、WebAssembly版も動作。ツール実装（xai-grok-tools）はCodexのapply_patch・grep_files等や、OpenCodeのbash・edit・skill等を移植したもので、THIRD_PARTY_NOTICES.mdは「ported from」と明記しApache/MITライセンスに準拠する形になっています。
問題の名残も残ります。xai-grok-shell/src/upload/gcs.rsにはGCSバケットへのアップロードコードが、upload/trace.rsのupload_session_state()にはハードコードされたエラーを返す痕跡が残るものの、いずれも無効化されているようです。なお、サブエージェント用プロンプト（subagent_prompt.md）はシステムプロンプトの内容を明かすなと指示する一方、メインのprompt.mdにはその指示がありません。
💼 事業会社視点：これは自社にどう効くか
AIコーディングエージェントの導入を検討する日本企業、とりわけSaaSや受託開発の現場に、これは「ツール選定基準にデータ経路を含めよ」という警告です。無害に見えるCLIが、実行ディレクトリのSSH鍵や認証情報ごとベンダのクラウドに送る設計はあり得る、という前提で評価すべきです。役員・事業責任者が今すべきは三点。第一に、開発チームが使うエージェントのデフォルト設定（保持・アップロード）を棚卸しし、ZDR相当のオプションが有効かを確認すること。第二に、機微情報を扱うリポジトリでは、Grok Buildのように「オープンソース・ローカルファーストで自前推論」できる構成を選択肢に入れ、外部送信を遮断できるかを技術評価軸に加えること。第三に、受託開発では顧客コードの外部送信が契約・秘密保持義務に抵触しかねないため、利用ツールのデータ処理条件を顧客に説明できる状態にしておくこと。信頼回復のためのコード公開は歓迎すべきですが、単一コミットで履歴が追えない点を踏まえ、宣伝ではなく実挙動で判断する姿勢が求められます。