ZCodeは42,411個のファイルを、Zhipuだけが開けるアーカイブにまとめた

2026年9月18日、ferstarという名義で執筆する開発者が、ZCodeの分解調査を公開した。これは中国のモデル開発企業Zhipu AIが手がけるデスクトップAIコーディングエージェントを対象としたもので、同氏が自宅ディレクトリ内の隠しフォルダーが700 MBを超えて大きくなっていることに気づいた後に行われた。そのフォルダーの中には、345 MBのワークスペースから抽出された42,411個のファイル（うち86.6%がGit履歴）を収めた313 MBの暗号化アーカイブがあり、クライアントによってパッケージ化され、Alibaba Cloudのオブジェクトストレージへアップロードするためにステージングされていた。アーカイブはZhipuのサーバーだけが解錠できる鍵で封じられており、クライアントにはその作成を止めるスイッチはなかった。Zhipuは同日夕方に謝罪した。アーカイブ自体の信頼度グレードと被害状況を含む完全な記録は、Orca AI Incident Archiveにあり、文書化された各AIインシデントを引用元と照合して記録している。

ZCodeはZhipuのデスクトップ向けコーディングエージェントで、プロジェクトを読み取り、シェルコマンドを実行し、コードを書く。同社は香港でティッカー2513.HKとして取引され、国際部門をZ.aiとしてブランド化している。ferstarが調査したZCodeのサーバーに表示されていたのはこの名前だ。その後、彼と他の複数の開発者に取材した上海の報道機関「The Paper（澎湃新聞）」によると、彼の投稿のタイトルはおおよそ「ZCodeによるGit全履歴のひそかなアップロードの真相を暴く」というもので、公開から数時間のうちに中国の開発者グループの間で広まったという。

隠しフォルダの中には何が入っていましたか？

Ferstar自身の数字がこの件の骨格であり、The Next Web、InfoQ、中国国家ラジオの経済部によって一貫して同じ内容が再現されている。彼のZCodeチェックポイントディレクトリ内のアーカイブは313 MBだった。その隣のステータスファイルには、約345 MB、42,411ファイルのワークスペースが記録されていた。その.gitディレクトリがペイロードの86.6%を占めていた。内訳はGitの大容量ファイルストレージキャッシュが196.1 MB、完全なコミット履歴を保持するGitオブジェクトが102.2 MB、そしてreflogのごく一部だった。実際のソースコードとドキュメントはおよそ13.4%だった。

この区別が重要なのは、Git の履歴が、現在のツリーから削除された素材が残存しやすい場所だからだ。The Paper の説明はこの点を直接示している。この種のアーカイブは、プロジェクトの最初のコミットからの編集履歴、削除済みコンテンツ、未コミットの下書き、古い設定ファイルを保持し得る。これには、ずっと前にコードから取り除かれたものの、以前のコミットや大容量ファイルキャッシュに残っている認証情報も含まれる。

Ferstar自身の313MBのアーカイブは、彼のマシンから一度も出ることはなかった。そのステータスログには564回の失敗したアップロード試行が記録されており、サイズ上限を超えていたため保留状態で停止していた。パイプラインがそもそも機能するのかを検証するため、彼は538ファイルからなる小規模な公開リポジトリを試した。そのスナップショットは圧縮・暗号化されて約15KBになり、サーバーに受け入れられた。記録上、エンドツーエンドで完了したことが確認されている転送はこの1件であり、これによってこの発見はコードを読むだけの演習から、受信側が実証された外部送信へと変わる。

キャプチャは、ユーザーが「自分のリポジトリをアップロードする」と認識するような操作には結び付いていなかった。ferstar の再構成によると、モデルに送信される各プロンプトの前に一つのトリガーが発火し、別のトリガーは Repo Wiki の更新タスクとして実行されていた。保留中のアーカイブを削除しても止まらなかった。Tencent Cloud の開発者コミュニティの記事には、パッケージが30分以内に再構築され、失敗カウンターが564から565に進んだと記録されている。その著者が見つけた唯一の確実な停止方法は、チェックポイントディレクトリを書き込み不可にしてディスク書き込みの段階でキャプチャを失敗させることだったが、その代償としてチェックポイントのロールバックとタイムラインインターフェースを失うことになった。

ベンダーだけが使用できるキー

暗号化は教科書通りのエンベロープ暗号化であり、それがユーザーが回避できなかった部分だった。InfoQの再構成は、ferstarのリバースエンジニアリングに基づき、クライアントがスナップショットID、RSA公開鍵、Alibaba Cloud OSSのアップロード認証情報をzcode.z.aiから取得し、ワークスペースをローカルでパッケージ化して暗号化した後、暗号文を直接OSSへ送信する様子を描いている。コンテンツはAES-256-CTRで暗号化され、対称鍵はサーバーの公開鍵の下でRSA-OAEP-SHA256によりラップされ、その鍵ペアの秘密鍵側はZhipuのクラウド内に留まっていた。

ルーティングは暗号技術と同じくらい重要だ。クライアントはZhipu自身のアプリケーションサーバーを経由せずAlibaba Cloudへ直接アップロードしたため、通信はログ記録やフィルタリングを行い得るZhipuのサービスを通過せず、したがって送信データをログに記録したりフィルタリングしたりするZhipuのサービスは経路上に存在しなかった。また、秘密鍵はデバイス上に一切なかったため、ferstarは自身のアーカイブを開けなかった。The Next Webの報道によれば、彼は自分のマシン上のあらゆる秘密鍵を試したが、失敗した。彼は投稿でこの仕組みを、サーバーだけが使用できる鍵であり、用途は一つだけだと説明した。

クライアントの2つの設定は、これを止めるはずに見えたが、どちらも止めなかった。「エクスペリエンスを最適化」トグルは、データをモデル学習に使用できるかどうかを制御し、「リポジトリのスナップショットのインデックス作成」トグルは、サーバーがすでに到着したスナップショット上にインデックスを構築するかどうかを制御していた。どちらも取得の下流で作用する。Ferstarは、取得が無条件で実行されていることを突き止め、The Next Webは、彼のプライバシーポリシーの読み方では、会話テキストとファイルの収集については記載されているが、完全なGit履歴を運ぶ自動ワークスペーススナップショットについては何も書かれていないと報じている。

Zhipuが出した説明と、その後の4日間

Zhipuは同日、プレスリリースではなくZCodeの公式ユーザーグループを通じて回答した。Global Timesが報じ、Security Insideが転載した内容によると、同社はこの動作をcodebase indexingという機能に起因すると説明した。この機能はローカルインデックス作成、セッションのチェックポイント復元、バージョンロールバック、Repo Wiki生成をサポートしており、Repo Wikiの工程がリポジトリのクラウドへのアップロードを引き起こしたと述べた。この機能はリリース以来デフォルトで有効になっていた。Zhipuは、アップロードされたデータはRepo Wikiページの生成にのみ使用され、その後直ちに破棄されたこと、保存もトレーニングへの利用もされていないことを述べ、影響を受けたユーザーに謝罪した。ZCodeのコードベースをオープンソース化し、第三者によるレビューを招き、その結果を公開すると約束し、補償として全ZCodeユーザーに週次クォータのリセットを1回追加で提供した。

修正は翌日に届いた。The Paperは、ZCode 3.14.0が9月19日にリリースされ、変更履歴に「リポジトリWikiの異常なアップロード問題を修正」と記されていたこと、およびferstarが同日、アップロード経路とそのエンドポイントがなくなったことを確認したと報じている。9月20日、ZhipuのMaaSプラットフォームは、入力と出力が静的に保存されないゼロリテンションのオプションを近日提供すると発表した。The Paperによると、これはアプリケーション単位のオプトインで、Batch APIとFile APIは除外され、法律または不正利用調査で必要な場合には30日以上の保持が依然として認められる。9月21日には、クライアントのソースがApache 2.0ライセンスの下でGitHub上で公開され、デスクトップアプリ、Webクライアント、バックエンド、エージェントCLI、エージェントランタイムを対象としている。

2件の監査が委託され、その結論は要約として公表された。中国信息通信研究院は、zcode-prodというAlibaba Cloud OSSバケットが、Zhipuが「ゼロデータ状態」と呼ぶ状態にあることを確認した。セキュリティ企業のNSFOCUSは、すべてのデータオブジェクトとバケット自体が削除されており、ZCode 3.14.0にはローカルリポジトリのスナップショットをトリガーしたりファイルを外部へ送信したりし得る経路は残っていないと報告した。評価レポートの全文はまだ公表されておらず、The Next Webによれば、Zhipuはその公表時期を明示していない。

より多くを主張したが、その後それを撤回した顧客

実際の損失に関する最も深刻な主張は、ferstar から出たものではなかった。China National Radio によると、9月19日、Taiyuan Chengming Technology は Chengming [2026] Legal Letter No. 1 の番号が付された法的書簡を Zhipu に送付し、その内容は ChainCatcher によって詳細に再掲された。同社は、自社のコーディング用ワークスペースのうち6つが同意なくアップロードされたと述べ、34,500ファイル、約425MBの平文を挙げ、完全なソースコード、システムアーキテクチャ、バージョン履歴、データベースのパスワード、クラウド認証情報、従業員の個人情報が含まれていたと列挙した。さらに、7つ目のワークスペース（1,947ファイル、約144MB）はパッケージ化して暗号化されたものの、32回のアップロード再試行に失敗したと述べた。また、同社のクライアントは9月16日にバージョン3.12.3へ更新されていたにもかかわらず、Zhipu が謝罪した当日の朝である9月18日00:28にも依然としてアップロードが検知されたと指摘した。

書簡は、監査では答えが出ていない問いを投げかけた。データが国外に持ち出されたのかどうか、という点である。Chengmingは、ZCodeのネットワークリクエストはシンガポールの法人を指していた一方、そのサービス契約はBeijing Zhipu Huazhangと締結されていたと述べ、Zhipuに対し、どちらの当事者が責任を負うのか、また中国本土外で移転や保存が行われたかどうかを明らかにするよう求めた。書簡は12項目の要求を列挙した。アップロードされたすべてのデータとその派生物、キャッシュ、バックアップを削除し、書面による証明書を提出すること、データがどこへ行ったのか、第三者と共有されたか、訓練に使用されたかを説明すること、秘密鍵がどのように保持されているかを説明し、アクセスログを提出すること、「破壊された」という主張の正確な範囲を定義すること、二度とアップロードしないことを書面で約束することなどである。書簡はZhipuに対し、10月10日までに書面で回答するよう期限を設け、損害賠償を請求し、規制当局に苦情を申し立てる権利を留保した。Caixin Globalは、Zhipuがこれらの主張を事実ではないと述べたと報じている。

2日後、Chengmingはそれらを撤回した。China National Radioの経済部は、9月21日に同社が撤回声明を出し、先前の声明は誤った証拠、不正確な説明、誇張した表現に基づいていたこと、それがZhipuの評判を傷つけたこと、今後メディアへの発言を停止することを述べたと報じている。The Next Webによれば、Reutersもこの撤回を報じた。この件のアーカイブ項目の日付は9月18日で、発見当日である。書簡、その10月10日の期限、そして撤回はいずれもその日付より後に出てきた。10月下旬時点の公開記録上、自社の秘密が暴露されたとの主張を支持する実名の企業は存在しない。

履歴が消去されたオープンソースリリース

クライアントのオープンソース化は、Zhipu が最も強く頼った対策であり、そこには穴があった。The Paper の報道によると、公開されたリポジトリには2つのコミットしか含まれていない。空の最初のコミットと、約6,973ファイルおよび103万行を追加する単一のコミットで、プルリクエストはロックされ、イシューはクローズされた状態だ。出荷時にアップロードパイプラインがどのようなものだったにせよ、またそれを含んでいたリリースがどれだったにせよ、それは現在誰も読むことのできない履歴の中にはない。

Ferstar自身の続報は、その限界を明示している。同氏は、アップロードパイプラインがすでに消えていたこと、残っているチェックポイント機構はローカルGitの作業のみを行うことを確認したうえで、バケットの監査で示せることと示せないことを指摘した。バケットを空にして削除することは適切な被害拡大防止措置だが、9月20日以降に実施された第三者による確認では、その時点でバケットが空だったことしか立証できない。9月18日より前に何が通過したのか、何かが復号・コピー・バックアップされたのか、パイプラインがどれだけの期間稼働していたのかを再構成することはできない。削除されたという主張は、依然として相当程度、削除した当事者の言い分に依拠している。

InfoQの分析は、未解決のまま残る疑問を同じ用語で列挙している。リポジトリのスナップショットがいくつ正常にアップロードされ、何人のユーザーによってアップロードされたのか、オブジェクトがどれだけの期間保持されたのか、どのサーバー側システムまたはスタッフがそれらを復号できたのか、完全なアクセスログが存在するのか、削除がバックアップやその他のコピーにまで及んだのか、といった点である。また、修正後もZCodeがどういうものであるかにも言及している。プロジェクト自身のNOTICEは、共有エージェントランタイムがデフォルトでOSレベルのサンドボックスを提供しないこと、およびクライアントが、ユーザーのアカウント権限の範囲内でファイルを読み取り、プロセスを起動し、ネットワークに到達できるshell、terminal、Git、MCP、plugin、embedded-browserの各サーフェスを保持していることを警告している。

何が確立されており、何についてどの資料も答えていないのか

この仕組みについて争いはない。Zhipu自身の声明も、リポジトリのデータがアップロードされたこと、その機能がデフォルトで有効だったこと、データが同社が管理するクラウドバケットに送られたことを認めている。Ferstarの測定、ベンダーの謝罪、委託された2件の監査、そしてオープンソースとしての公開は、いずれも同じ連鎖を説明している。ワークスペースが有効なオプトアウト手段なしにマシンから離れたことを、記録の中で争うものは何もない。記録に残された害は仮説ではなく現実のものだ。転送は実際に行われ、その中にコードがあった人々は、それを防ぐことも検査することもできなかった。

争点となっているのは、あるいは単に不明なのは、規模と影響である。影響を受けたデフォルト設定を何人のユーザーが実行したのか、パイプラインが9月18日より前にどれだけの期間稼働していたのか、アップロードされたオブジェクトが一度でも復号されたのかについては、どの情報源も述べていない。wiki生成後にデータは破棄され、訓練には一切使用されなかったというZhipuの保証は、同社自身の声明である。CAICTとNSFOCUSの調査結果は、修正後のバケットの状態を述べており、バケットを通過した内容については述べていない。このアーカイブは文書化の面で記録をAと評価しているが、その文書は仕組みについては強く、範囲については薄い。

何が変わり、何が変わらなかったのか

商業的コストは即座に現れた。中央人民広播電台は、Zhipuの香港上場株が9月21日に1.79%、9月22日に6.55%、9月23日に12.4%下落し、3取引日間で累計16%超の下落となったこと、またZhipuが影響を受けたユーザー数や、過去のデータが復号されたか、あるいはバックアップされていたかについて言及しなかったことを報じた。

ZCodeユーザーが発見後の4日間で実際に受け取ったもの：

• 9月18日:コードベースのインデックス作成を原因として名指しした公開謝罪、クライアントのオープンソース化と第三者によるレビューの委託の約束、そしてユーザーごとに週次クォータのリセットを追加で1回行うこと。

• 9月19日： ZCode 3.14.0。Repo Wikiが削除され、ローカルスナップショットの生成とアップロードの経路が断たれた。Ferstarは翌日、アップロードチェーンが失われていることを確認した。

• 9月20日:ZhipuのMaaSプラットフォームにおけるゼロリテンションオプションの発表。オプトイン方式で、Batch APIとFile APIは除外され、依然として30日以上の法的保存の対象となる。

• 9月21日: ZCodeはインシデント前のコミット履歴なしでApache 2.0の下で公開された；CAICTとNSFOCUSの概要は、ストレージバケットが空であり、エグレス経路が存在しないと報告している。

そのどれも過去には遡らない。Chengmingが提起した具体的な問い——データはどこへ行ったのか、誰が復号できたのか、国外に出たのか、「破壊」が何を対象にしていたのか——は、10月10日を期限として書面にされ、その後、その問いを出した企業によって取り下げられた。Zhipuは期日を示さずに完全な第三者評価報告書を約束している。それが現れるまで、受け取ったデータをパイプラインがどう扱ったかについての唯一の公開された説明は、それを構築した企業による説明であり、独立に計測できる唯一の成果物は、ある開発者のノートPCから564回にわたって出ることに失敗した313 MBのファイルだ。