ZCodeがGit履歴を無断送信？設定で防げない理由と実態の解説

オープンウェイトモデル「GLM」の公式開発ツールとして提供されているAIコーディングアプリ「ZCode」において、作業フォルダ内のGit履歴全体が外部サーバーへ無断送信されていたとする解析結果が公表されました。アプリ内の設定を無効化しても送信処理が停止しない仕組みが明らかになっています。公開された技術検証データをもとに、確認された挙動と背景を整理します。

ZCodeは何をサーバーへ無断送信していた？

2026年9月18日、セキュリティ研究者のferstar氏が、北京に本社を置くZ.ai社のデスクトップ向けAIコーディング環境「ZCode」をリバースエンジニアリングした解析レポートを公開しました。Z.ai社はオープンウェイトモデルとして知られる「GLM」シリーズを手がける企業です。

公表された解析結果によると、ZCodeにアカウントログインしている状態では、作業中のワークスペース全体がバックグラウンドで自動的にアーカイブ化され、Alibaba Cloud（Aliyun OSS）のオブジェクトストレージへ暗号化された状態で送信されていました。

ferstar氏が自身の商用プロジェクト環境（合計345MB、42,411ファイル）で確認したところ、313MBの暗号化アーカイブが生成されていました。さらに通信状況の調査中だけでも、サーバーへのアップロード試行の失敗ログが564回記録されていたことが報告されています。

送信データの86%以上をGit履歴が占めている

この挙動において特に注目されたのが、送信されるデータの内容です。アーカイブを生成する際のマニフェスト（構成目録）ファイルはローカルディスク上に平文で保存されており、具体的な内訳を解析することが可能でした。

42,411ファイルを対象としたスナップショットの内訳は以下の通りです。

表が示すように、現在編集しているソースコードやドキュメント本体は全体の13.4%に過ぎず、残りの86.6%はすべて「.git」ディレクトリ配下のデータで占められていました。

Gitのリポジトリ管理領域には、現在画面に開いているファイルだけでなく、過去に行われたすべてのコミット履歴が保存されています。過去のコミットで誤って含めてしまい、その後の修正コミットで削除したはずのAPIキーや認証情報、まだ外部に公開していない新機能のブランチ名、設定ファイル（.git/config）に記録された組織内のホスト名や内部リポジトリのパスなどもすべて含まれます。開いているコード断片ではなく、プロジェクトの過去の開発経緯全体がそのまま送信対象になっていました。

生成された暗号化データはユーザー自身で復号できない

外部ストレージへ送信されるアーカイブファイルには暗号化が施されていますが、その鍵の管理構造にも特徴が確認されました。ZCodeでは「エンベロープ暗号化」と呼ばれる二重構造の暗号化方式が採用されています。

エンベロープ暗号化とは、データ本体を共通鍵で暗号化し、その共通鍵をさらに別の公開鍵で暗号化してひとまとめにする仕組みです。解析によると、データ本体はAES-256-CTR方式で暗号化され、その鍵がRSA-OAEP方式の公開鍵で保護されていました。

クライアントアプリはアップロードを行う際、まず管理サーバー（zcode.z.ai）と通信して一時的な認証情報と暗号化用のRSA公開鍵を受け取ります。しかし、暗号化された共通鍵を復号するための「RSA秘密鍵」はZ.ai社のクラウド環境内にのみ保持されています。

検証を行ったferstar氏は、ローカル端末内に存在するあらゆる秘密鍵を用いてアーカイブの復号を試みましたが、解除することはできませんでした。手元のディスクに生成された313MBの暗号化ファイルであっても、ユーザー自身やZCodeアプリ単体では復号できず、Z.ai社のサーバー側だけがいつでも中身を取り出せる設計になっています。

アプリ内の設定オフでもアップロード処理は継続する？

不審な通信に気づいた場合、通常は設定画面から関連機能を無効化することが考えられます。ZCodeの画面上にも、データ送信に関連しそうな2つの設定項目が存在します。

1つは「Optimize Experience（体験の最適化）」、もう1つは「Repo Snapshot Indexing（リポジトリスナップショットのインデックス作成）」です。ferstar氏がこれらのUI設定に対応する内部コードを照合したところ、設定を変更してもアップロード自体は停止しないことが判明しました。

「Optimize Experience」の切り替えは、送信されたデータをAIモデルの学習に利用することを許可するかどうかを制御する項目です。また「Repo Snapshot Indexing」は、サーバー側でアップロード済みデータに対する検索インデックスを作成するかどうかを決める項目であり、ローカルでのアーカイブ生成とクラウドへの送信処理そのものはどちらをオフにしても継続して実行されます。

送信処理を担当するプログラムは、アプリの起動時に無条件で常駐プロセス（サイドカー）として立ち上がります。送信が実行される条件は、ユーザーの認証機能が有効なトークン（JWT）を発行できる状態にあることだけであり、設定画面の選択状態による停止処理は組み込まれていませんでした。実際のセッションログでは、プロンプトを入力する前やタスクが完了したタイミングなどで、1セッションあたり62回ものキャプチャ処理が記録されていました。

この仕組みは、公開プロンプト収集リポジトリのOrcaPromptVaultに流出したZCodeのシステムプロンプト（131KB）と31種類のツール定義からも裏付けられています。システムプロンプト内には、作業履歴を巻き戻すチェックポイント機能のテンプレートが複数含まれていました。一方、AIエージェントが利用できる31個のツール定義の中には、スナップショットの取得やアップロードを行うツールは存在しませんでした。

送信処理はエージェントのツール呼び出しループの外側にあるホストレベルで実行されているため、エージェント側に対する権限設定では検知も停止もできません。さらに、セッションIDを指定して過去の対話履歴を読み出す「ReadSessionContext」というツールの存在も確認されており、作業内容はローカルに保存されると同時にクラウドへも送られる多重構造になっていました。

オープンなGLMモデルとクローズドなZCodeの構造的な違い

今回の問題がコミュニティで議論を呼んだ背景には、AIモデル自体の公開形態とクライアントアプリの形態に関する誤認がありました。

Z.ai社が提供するGLMシリーズ（GLM-5.3-Flashなど）は、モデルの重み（パラメータ）が一般に公開されたオープンウェイトモデルとして知られています。ローカル環境のマシン上でモデルを直接実行できるため、プライバシーを重視する開発者層からも注目されていました。

しかし、モデルの重みがオープンであることと、そのモデルを利用するためのアプリケーションがオープンソースであることは異なります。ZCodeはZ.ai社独自のエージェント実行環境ですが、ソースコードは公開されていないプロプライエタリなソフトウェアです。GLMがオープンであることからZCodeもオープンソースであると誤解し、導入したユーザーが一定数存在しました。

ZCodeは2026年7月にリリースされました。当時、他社のコーディング支援ツールでテレメトリ送信に関する議論が巻き起こった直後であり、ZCodeはオープンなモデルを活用できる安心感を前面に出して訴求されていました。SNS上で同社幹部がスパイウェアのような機能が含まれるか問われた際にも、Webサイトに記載された内容以上のものは実装しないと回答していました。

しかし、ワークスペース全体やGit履歴をアーカイブして送信する機能は、ZCodeのWebサイトには記載されていません。プライバシーポリシーに記載されているのも「対話中に送信されたテキスト、ファイル、コード」という推論処理に関する説明だけであり、リポジトリ履歴全体のアップロードについては言及がありませんでした。

解析結果が公表された後、Z.ai社の公式アカウントは沈黙を保っていましたが、ZCode開発チーム関係者とみられるアカウントが「見つかってしまって申し訳ない」という趣旨のメッセージを投稿しました。これは仕組みの存在を否定するものではなく、事実上の追認と受け止められています。

OSレベルの書き込み禁止で一時的に送信を遮断できる

ZCodeの環境が手元にあり、安全が確認されるまでの間に対処を行いたい場合、通常のファイル削除では防ぐことができません。生成された送信待ちアーカイブファイルをディスクから削除しても、アプリは30分以内に再び同じ313MBのアーカイブを生成し、送信を試行し続けます。

解析レポートによると、現時点で送信処理を物理的に阻止できる手段は、OSのファイルシステム権限を利用してチェックポイント用フォルダを書き込み禁止（イミュータブル属性）に設定することです。

具体的な設定手順はOSごとに異なります。

Linux環境での設定：

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

macOS環境での設定：

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

この設定を施すと、ディレクトリへの書き込みがOSのカーネルレベルで拒否されるため、アーカイブファイルの生成とアップロードが遮断されます。その代償として、ZCodeの機能である作業巻き戻し（チェックポイントロールバック）は動作しなくなります。ただし、チャットによる対話、コード補完、通常のツール実行といった基本機能はそのまま動作することが確認されています。設定を元に戻す場合は、Linuxなら「sudo chattr -i」、macOSなら「chflags nouchg」を実行します。

利用環境の選定で今後何を確認すべきか？

今回の事例は、ローカル環境でAIモデルを実行している場合であっても、それを包む実行環境（ハーネスやデスクトップアプリ）が安全とは限らない現実を示しています。

オープンウェイトのモデルをローカルで動かす目的は、クラウド側にデータを預けず、自前のハードウェアで推論を行うことにあります。しかし、モデルを呼び出す周辺ソフトウェアが密かにクラウドと通信し、作業フォルダを外部送信していれば、データ保護は達成できません。

今回の詳細な解析手順や通信フローの検証結果は、Tokensteadが公開した解説資料で確認できます。

開発ツールを選定する際は、AIモデル自体のライセンスや公開状況だけでなく、操作を行うクライアントアプリがどのような通信を行っているか、暗号化されたデータの復号鍵を誰が保持しているかという点まで目を向ける必要があります。