ニュース 深掘り Opinion 研究 データ リソース イベント 概要
English 中文 日本語

Grok BuildとZCodeの無断アップロード事件｜ソース公開だけでは信頼は戻らない

Grok BuildとZCodeがユーザーのリポジトリを無断でクラウドへアップロードしていた2事件を整理する。両社ともオープンソース化で応じたが、百万行規模のコードを誰が監査するのか。公開版と配布版の乖離まで含めて信頼回復の条件を考える。

2026年7月から9月にかけて、AIコーディングツールの2製品が、ユーザーのリポジトリを無断でクラウドへアップロードしていたことが相次いで発覚した。SpaceXAI（旧xAI）の Grok Build と、智譜（Z.ai）の ZCode である。どちらも画面のスイッチを切っても転送は止まらなかった。そして両社とも、発覚後の対応としてソースコードの公開を選んだ。

だが公開されたコードを検証するほど、疑問はむしろ増える。クローズドな状態では検証手段すらなかったこと。公開されても百万行を読み切る人間はいないこと。公開版は配布版と同じものとは限らないことだ。

二つの事件の経緯

まず時系列を整理する。

日付出来事
2026年7月12日SpaceXAI がサーバー側でデフォルトのデータ保持を無効化。Musk は既アップロード分を「1バイトも残さず」削除すると約束1
2026年7月13日セキュリティ研究者 Cereblab が mitmproxy で Grok Build CLI の 5.1 GiB アップロードを実証2
2026年7月15日SpaceXAI が Grok Build を Apache 2.0 でオープンソース化3
2026年9月18日開発者 ferstar が ZCode のフォレンジック分析を公開4。同日、智譜が謝罪5
2026年9月19日ZCode 3.14.0 をリリース。変更履歴は「Repo Wiki の異常アップロードを修正」6
2026年9月21日ZCode を GitHub でオープンソース化。1日で約 5,000 star78

クローズドソースでは疑惑すら検証できない

Grok Build 事件の発端は、Cereblab による実証だった。mitmproxy での観測で、Grok Build CLI は 5.1 GiB を SpaceXAI の Google Cloud Storage バケット grok-code-session-traces へ静的にアップロードしていたことがわかった。モデルのコンテキストが実際に必要としたのは約 192 KB である。送られたのは完全な git リポジトリ、コミット履歴、.env の認証情報ファイルで、アプリ内のプライバシースイッチは機能せず、明示的な disable_codebase_upload 指定でも止まらなかった2。

ホームディレクトリで実行したユーザーは、「SSH鍵、パスワード管理データベース、書類、写真、ビデオ、全部」がアップロードされたと報告している1。

ZCode の構図も同じだ。ferstar のフォレンジック分析によれば、デスクトップクライアントはログイン中にワークスペース全体をパックし、アリババクラウド（阿里云）の OSS へ暗号化してアップロードしていた。中身は完全な .git 履歴、LFS キャッシュ、reflog、一部のグローバル開発設定。UI に有効なオフスイッチは存在しなかった4。暗号化パッケージは 313MB で、ワークスペース約 345MB の 86.6% が .git 履歴、マニフェストは 2,411 ファイル。ある全量アップロードは 564 回連続で失敗していた69。

アップロード経路は入念だ。クライアントは GET /api/v1/snapshot/upload-credential で資格情報を取得し、AES-256-CTR で暗号化したデータを OSS へ直接 POST する。対称鍵は RSA-OAEP-SHA256 で包まれ、復号の秘密鍵はクラウド側だけが持つ。ユーザー側に復元手段は一切ない9。Hacker News のコメントはこう指摘した（UpXuu の転述による）。「封筒暗号化とサーバー側の秘密鍵保有の組み合わせで、ローカルバックアップがリモート資産の強奪装置になる」9。

プライバシーポリシー（2026年6月15日更新）には「会話で提出したテキスト・ファイル・コード」の収集としかなく、スナップショットや git 履歴への言及は皆無9。UI のスイッチは「モデル学習に使うか」「スナップショットを索引化するか」の2つだけで、バージョン 3.12.3 では両方をオフにしてもアップロードが発生した6。

ここにクローズドソースの構造的な問題がある。鍵はサーバー側にあり、ポリシーには記載がなく、スイッチは機能しない。発覚は Cereblab と ferstar という個人のリバースエンジニアリングに頼った。クローズドな状態では、告発の材料さえ偶然に左右される。ここで述べたアップロード行為は、公開された第三者フォレンジック報告と、各社が公開チャネルで示した説明・謝罪に基づく。動機についての未確認の推測は含めていない。

公開されても、誰が百万行を読むのか

では、公開で疑惑は解けるのか。Grok Build のリポジトリは、AgentScout の集計によると Rust 約132万行、77 crates にのぼり、26,332 stars、4,948 forks を数える1011。ZCode には 6,973 ファイル・約103万行が投入され、公開初日に約 5,000 star を集めた78。

star は読了を意味しない。百万行の通読はフルタイムの研究者でも不可能で、実際に点検したのは NxCode や ferstar など数えられるほどだった。

NxCode の独立監査が見つけた事実は重い。公開コミットは1件だけで、release tag から配布バイナリへの出所チェーンはない。GCS/S3 アップロードスタックは upload/gcs.rs などとしてツリーに残るが、trace アップロードは session_state_upload_unavailable を返すスタブ化済みだ。AuthManager::is_data_collection_disabled() は fail-open、allows_data_collection() は fail-closed と判定の向きが異なり、各パスがどちらを使うかは監査義務として残る12。

機関による監査もある。中国信息通信研究院（CAICT）は zcode-prod の OSS バケットを「クラウド内データゼロ」と確認し、緑盟科技（NSFOCUS）はバケットと全データオブジェクトの削除を確認した。ただし両機関とも監査報告書は公開していない（封面新聞の発稿時点）56。「監査済み」という事実だけが伝わり、中身はまたクローズドな箱の中にある。

コミュニティが提示した監査可能性の3要件は、完全なコミット履歴、再現可能ビルド、公開イシュートラッカーだ7。オープンソース化は「監査できる可能性」を与えた。しかし監査そのものを発生させたわけではない。

オープン版とクローズド版は別物だ

三つ目の問題が最も根深い。公開されたコードと、配布される製品が同じとは限らない。

ZCode のリポジトリにあるコミットは2つだけだ。空の Initial commit と、「feat: open source」の巨大コミット1発で 6,973 ファイル・約103万行が投入された。社内の開発履歴は圧平され、アップロード機能がいつ書かれ、どう消されたかは追跡できない。ユーザーの全 .git 履歴をパックして炎上した製品自身の git 履歴がゼロとは、皮肉が効きすぎている7。

CodingPlanStatusActions.tsx には「オープンソース版はクーポン特典の対象外」というコメントが残り、サーバー側で両者が別扱いされていることがうかがえる7。Computer Use はプレースホルダーのみで、コアロジックの多くはソース非同梱のネイティブアドオン build/Release/ax_native.node にある。公開された103万行の多くは外側のバインディングと UI レイヤに過ぎず、issues と PR の作成も無効化されている713。

Grok Build 側も構造は似ている。CONTRIBUTING.md は外部 PR を受け付けないと明記し、ソースは社内 monorepo からの定期同期で、GitHub issues は無効（2026年7月26日時点）。脆弱性報告は HackerOne、一般フィードバックは Discord への誘導だ14。公開が「開発の現場」そのものでない以上、公開版と配布バイナリの一致を検証する術は利用者側にない。

何が証明できて、何が証明できないのか。ferstar の再確認では、アップロードチェーンは完全に削除され、チェックポイントは純ローカル git の増分比較だった。公式の当初説明「ロールバックにアップロードが必要」の否定でもある。結論の構造は非対称だ。「今のバージョンはもうアップロードしない」は証明できる。「過去のバージョンが何をいつから送っていたか」は証明できない67。

UpXuu が記録した第三者チームの再現もこの非対称を補強する。謝罪後の 3.12.3 でもアップロードパイプラインのコードは1行も削除されておらず、captureBeforePrompt、RepoWikiGenerator、封筒暗号化がすべて残存していた。「修正」の実体はデフォルト false 化と旧設定の強制移行、Repo Wiki のサーバー側停止で、能力の除去ではなく設定層の変更だ。サーバー設定次第で再有効化は理論上可能である9。

二つの「公開」を並べる

項目Grok BuildZCode
公開形式社内 monorepo からの定期スナップショット14履歴を圧平した単一ダンプ7
公開コミット1件122件（実質1件の巨大コミット）7
外部 PR受け付けないと明記14作成を無効化13
GitHub issues無効14無効13
リリース管理tag からバイナリへの出所チェーンなし12GitHub リリースなし、タグなし7
コード規模Rust 約132万行・77 crates106,973 ファイル・約103万行7
監査可能性3要件すべて欠く12すべて欠く7

展望

智譜は謝罪で、原因はチェックポイント復元・履歴ロールバック・Repo Wiki に使う「コードリポジトリ索引」機能で、Repo Wiki がページ生成時にアップロードをトリガーしていたと説明した。生成後にデータは破棄され、当初はデフォルト ON だったという5。同社は「オープンソース化はユーザーの懸念に応じ、製品の透明性を高める重要な第一歩だ」と述べ6、「データ内容不留存」機能と深刻度に応じた報酬付きの脆弱性対応機構を発表した。指摘されたコードデータは保持しておらず学習にも未使用としている5。

SpaceXAI の立場は発表文に集約される。「コードを公開することが、堅牢で信頼性の高いハーネスを作るための最も直接的な方法だ」3。オープンソース化後は完全に local-first で、自前の推論スタックに向けられるという3。

方向は正しい。だがスナップショット公開と PR 不受、issues 閉鎖の組み合わせは、コミュニティに「読む権利」は与えても「問う権利」を与えていない。次に必要なのは「点検可能な公開」、つまり完全な履歴と再現可能ビルドと公開のイシュートラッカーだ。

参考文献

まとめ

二つの事件は、AIコーディングツールの信頼構造をあらわにした。クローズドな状態では、ユーザーは疑惑を検証する手段すら持たない。オープンソース化は検証の可能性を開くが、百万行を実際に読む人間はごく少数で、機関監査の報告書まで非公開では「監査済み」の言葉も空転する。公開版と配布版が別物なら、過去に何が送られていたかという問いにはソースを読んでも答えられない。

それでも、オープンソースは両の危機で唯一前に進んだ一歩だった。公開されたからこそ「今のバージョンはもうアップロードしない」を証明する人間が現れた。信頼は公開で得られるのではない。点検可能な公開と、それを実際に点検する営みの積み重ねでしか得られない。

Footnotes

  1. Simon Willison’s Weblog — Grok Build のアップロード問題、ユーザー被害報告と保持無効化・削除約束の経緯 https://simonwillison.net/2026/Jul/15/grok-build/ ↩ ↩2

  2. 智柴網 — Cereblab による Grok Build の 5.1 GiB アップロード実証の報道 https://zhichai.net/topic/178395179 ↩ ↩2

  3. x.ai 公式発表 — Grok Build オープンソース化のお知らせ https://x.ai/news/grok-build-open-source ↩ ↩2 ↩3

  4. 界面新聞 — ferstar による ZCode フォレンジック分析の報道 https://www.jiemian.com/article/15121635.html ↩ ↩2

  5. 毎経網（毎日経済新聞） — 智譜の謝罪と「コードリポジトリ索引」機能の説明 https://www.nbd.com.cn/articles/2026-09-21/4587856.html ↩ ↩2 ↩3 ↩4

  6. 封面新聞（網易転載） — ZCode アップロード問題の詳報、暗号化パッケージの規模と 3.14.0 修正の経緯 https://www.163.com/dy/article/L7GIH3FN0514D3UH.html ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. 技術棧 — ZCode オープンソース版の分析：圧平された履歴、オープン版とクローズド版の差異 https://jishuzhan.net/article/2102320027056394242 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  8. 七牛雲 — ZCode オープンソース化当日の反響報道 https://news.qiniu.com/archives/1789970579947 ↩ ↩2

  9. UpXuu — ZCode 無断 git アップロードのフォレンジック記録と第三者チームの独立再現 https://upxuu.com/posts/zcode-silent-git-upload-forensics/ ↩ ↩2 ↩3 ↩4 ↩5

  10. AgentScout — Grok Build オープンソース化とプライバシー問題の報道（コード規模の集計） https://agentscout.live/zh/tech/dev-tools/news/20260723-xai-grok-build-open-source-privacy-scandal/ ↩ ↩2

  11. GitHub — xai-org/grok-build リポジトリ（stars / forks 数） https://github.com/xai-org/grok-build ↩

  12. NxCode — Grok Build オープンソース版のデータプレーン独立監査 https://www.nxcode.io/zh/resources/news/grok-build-open-source-data-plane-audit-2026 ↩ ↩2 ↩3 ↩4

  13. 蚁工厂（新浪転載） — ZCode リポジトリの issues / PR 無効化と履歴欠落の指摘 https://www.sina.cn/news/detail/5345520728147920.html ↩ ↩2 ↩3

  14. Slow Signals（vocus） — Grok Build のガバナンス体制と第三者コードの内訳分析 https://vocus.cc/article/6a6571e5fd89780001880eb3 ↩ ↩2 ↩3 ↩4