xAIがGrok Buildを84万行公開|無断送信問題で異例の全面OSS化

xAIが2026年7月15日、コーディングエージェントGrok Buildをオープンソース化。全ファイル無断送信問題の経緯、約84万行のRust公開の狙い、EC事業者が確認すべきAIエージェントのデータ設定まで解説します。

投稿日: カテゴリー AIニュース

xAIは2026年7月15日、コーディングエージェントGrok Buildをオープンソース化しました。

きっかけは、ユーザーのローカルファイルを無断でクラウドへ送信していた問題の発覚です。批判を受けたxAI(公式サイト表記はSpaceXAI)は、アップロード機能の無効化にとどまらず、約84万行に及ぶソースコード全体をGitHubで公開するという異例の対応に踏み切りました。AIエージェントを業務で使うすべての事業者にとって、「自分のデータがどこへ送られているのか」を考え直す機会になるニュースです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)が解説します。

何が起きたか:全ファイル送信の発覚から3日で全コード公開へ

xAIは7月15日、Grok Buildの全ソースコードをGitHubで公開し、問題となったアップロード機能を無効化しました。The Decoderによると、コード規模は約84万4,530行のRustで、ライセンスはApache 2.0です。

発端は、Grok Buildが作業ディレクトリ内の全ファイルをxAIのGoogle Cloudサーバへアップロードしていたことをユーザーが発見し、批判が広がったことでした。SSH鍵やパスワードデータベース、文書、写真まで転送されていたという報告もあります。Elon Muskはアップロード済みの全ユーザーデータを完全に削除すると表明し、xAIはアップロード機能を無効化しました。The Decoderによれば、7月12日以降はデータ保存がデフォルトでオフになっています。

そのうえでxAIは公式発表で、コンテキストの組み立てからツール呼び出しの実行まで「ソースを読めば正確に動作を確認できる」として、GitHubリポジトリを公開しました。公開範囲にはエージェントループ、コードの読み取り・編集・検索やコマンド実行を担うツール群、ターミナルUI、そしてスキル・プラグイン・フック・MCPサーバー・サブエージェントを扱う拡張システムまで含まれます。アップロード機能の痕跡はコード内に残っているものの、無効化された状態だと報じられています。

Grok Buildとは、ターミナルからgrokコマンドで呼び出すxAIのコーディングエージェントのことです。コードベースの読み取りと編集、シェルコマンドの実行、Web検索、長時間タスクの管理に対応し、対話型のほか、CI向けのヘッドレス実行、Agent Client Protocol(ACP)経由のエディタ組み込みでも動作します。

なぜ重要か:AIエージェントの「データはどこへ行くのか」問題

今回の一件が重要なのは、ローカル環境に広くアクセスするAIエージェントのデータの行き先という論点を、業界全体に突きつけたからです。

コーディングエージェントは、ファイルの読み書きやコマンド実行の権限を持つことで高い生産性を発揮します。その一方で、どのファイルが、いつ、どこへ送信されるのかは利用者から見えにくいのが実情です。今回のように鍵情報や個人ファイルまで送られていた事例は、利用規約や設定画面の説明だけでは実態を検証できないことを示しました。

xAIの対応が異例なのは、謝罪や設定変更にとどまらず、全コード公開によって検証可能性そのものを提供した点です。さらに今回のOSS化により、Grok Buildは自分でコンパイルしてローカル推論と組み合わせれば、クラウドへ一切データを出さずに完全ローカルで動かせるようになりました。機密性の高いコードや顧客データを扱う企業にとって、選択肢が1つ増えたことになります。

xAIは7月上旬にOpusクラスを称するGrok 4.5を公開し、Grok 4.5とGrok Buildの無料開放も進めるなど、開発ツール領域で攻勢を続けています。今回の全面公開は、信頼回復と同時に、開発者コミュニティを取り込む狙いも読み取れる動きです。

今後の動き:3つの注目ポイント

第一に、コミュニティによる検証です。約84万行のコードが公開されたことで、アップロード機能の残骸を含む実装の中身が第三者の目で検証されていきます。検証結果次第で、信頼回復が進むか、新たな火種になるかが分かれます。

第二に、競合への波及です。Claude CodeやOpenAIのCodexなど、同種のエージェントに対しても「データ送信の透明性」を求める圧力が強まる可能性があります。ツール選定の基準に、性能や価格だけでなく検証可能性が加わる流れです。

第三に、ローカルファースト需要の広がりです。ローカル推論と組み合わせて完全オフラインで使える構成は、セキュリティ要件の厳しい企業ほど魅力的に映ります。Grok Buildの自律開発機能のような使い方も、ローカル完結なら導入のハードルが下がります。

EC事業者にとっても他人事ではありません。顧客リストや受注データのCSVが置かれたフォルダでAIエージェントを動かすと、意図しない外部送信のリスクがあります。ツール導入時にはデータ送信や学習利用の設定を確認したうえで、顧客データを含むディレクトリとエージェントの作業ディレクトリを分ける運用が、現実的な防御策になります。

まとめ

xAIは無断ファイル送信問題への対応として、Grok Buildの約84万行のコードをApache 2.0で全面公開しました。AIエージェントの利便性とデータ管理リスクは表裏一体です。事業者は「何が送信されるか」を確認できるツールかどうかを、選定基準に加えるタイミングに来ています。

参考文献

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

引用元: The Decoder


【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)


投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

お問い合わせ