先に結論です。「暗号化済み」が示すのは、包んだあとのバイト列がワークスペースの平文ではないことまでです。自分に復号能力があること、クラウドが中身を読めないことは、ここからは出ません。エンベロープ暗号化では、対称鍵をサーバーが渡した公開鍵でもう一枚包み、秘密鍵はクラウドに残します。設計の向きは、クラウドが開けられることです。その場で照合できるのは三つです。この暗号文を自分で開けるか。Network にワークスペースの平文が出ているか。画面のスイッチを切ったあと、新しい送信待ちの包みがまだ出るか。「この端末で AES を呼んだ」を、「復号できるのは自分だけ」と読まないでください。
検索意図に一文で答える
転送時の暗号化と、「鍵を自分が持っている」は、別の層です。クライアントはこの端末で AES によりワークスペースを暗号文にし、その暗号文をオブジェクトストレージへ送れます。鍵を包む公開鍵がサーバーから来て、秘密鍵がこのパソコンへ一度も入っていないなら、そのファイルは自分で戻すためのバックアップではありません。クラウドだけが開けるエンベロープです。経路上の傍観者は平文を見ません。秘密鍵を持つサーバーは見ます。
この記事は、「クライアントがワークスペースを暗号化してアップロードした」という報道を見て、ディスク上の暗号文とゼロ知識を分けたい人、そしてリポジトリや鍵を同僚へ渡すとき復号の権利を事業者へ渡したくない開発者向けです。事業者の通報の代わりにはならず、特定のエディタのアンインストール手順にもしません。持ち帰るべきなのは、エンベロープ暗号化が鍵を誰の手元に置くか、平文の一覧がすでにどれだけの範囲を書いているか、「すぐに破棄」が証明しないこと、そして「この暗号文を自分で開けられるか」をこの端末でどう照合するかです。
分解で、どの層まで書けたか
2026年9月18日、ferstar は調査記録を公開しました。きっかけはパケットの競技ではなく、ディスク整理です。手元の ~/.zcode が 700 MB を超え、その中の v2/checkpoints/ に約 313 MB の .enc がありました。隣の状態ファイルには、ワークスペース約 345 MB、kind は baseline、failureCount は 564 と書いてありました。リポジトリ本体は約 10 GB です。依存を除いた残り 345 MB は、ほぼプロジェクトの中核ファイルです。
アップロードの流れは、二段に戻せます。第一に、クライアントは zcode.z.ai へ POST /api/v1/snapshot/upload-credential を出し、サーバーはスナップショット番号、オブジェクトストレージのフォーム署名、サイズ上限、そしてその回の RSA 公開鍵を返します。第二に、この端末が tar.gz を作り、一度きりの対称鍵で AES-256-CTR をかけ、その対称鍵を RSA-OAEP-SHA256 で包み、最後に tar.gz.enc をフォーム POST でアリババクラウド OSS へ直送します。ストレージのコールバックが、事業者のバックエンドへ受付を登録します。業務サーバーはこの暗号文ファイルを中継しません。受付の権利と秘密鍵は、クラウド側に残ります。
範囲は、いま見えている作業ツリーだけではありません。手元の平文一覧は 42,411 ファイルです。.git/lfs/ が約 196.1 MB（56.8%）、.git/objects/ が約 102.2 MB（29.6%）、.git/logs/ が約 0.6 MB、ソースと文書が約 46.2 MB（13.4%）。.git の合計は 86.6% です。アップロードが成功すれば、クラウドが受け取るのはコミット履歴、削除したあともオブジェクト庫に残る鍵、未 push のローカルブランチ名、そして .git/config の社内ホストです。ワークスペースをまたぐ別の一覧もあり、全体設定のハッシュを一緒に持ち出します。
9月18日 17:44、事業者はユーザーコミュニティで状況を説明し、アップロードは初期状態でオンのコード索引から来ると認め、用途はセッションのチェックポイント、版の巻き戻し、Repo Wiki だとしました。Wiki 生成後、データはすぐに破棄するとも書いています。9月21日の『毎日経済新聞』は、ZCode がオープンソース化を発表したと報じました。中国情報通信研究院の評価では zcode-prod のバケットはデータゼロ、NSFOCUS（緑盟科技）はバケットとオブジェクトの削除を確認、クライアント v3.14.0 はスナップショット生成とアップロード経路を外した、とあります。ferstar の補足はこうです。313 MB の商用プロジェクトはサイズ上限を超え、564 回再試行しても LAN の外へ出ていません。別の公開リポジトリのワークスペースは 538 ファイル、圧縮と暗号化のあと約 15 KB で、状態はサーバー受付済みです。「何かがこの機械を出たか」について、少なくともその小さい一份は、出ています。
エンベロープ暗号化が、自分の復号にならない理由
AES-256-CTR に RSA-OAEP を足す形は、教科書のエンベロープです。中身は短命の対称鍵で暗号化し、その対称鍵を公開鍵でもう一枚包みます。算法の名前は硬く見えます。「誰が読めるか」を決めるのは、公開鍵がどこから来て、秘密鍵がどこに落ちるかです。調査記録はこう書いています。公開鍵はアップロード資格を申請したときにサーバーが渡し、対応する秘密鍵はこのパソコンへ入りません。手元に既にある秘密鍵でこの包みを開けようとしても、成功しませんでした。クライアント自身も、ディスク上のその暗号文は開けません。
これは、「自分で戻せるバックアップを一通作る」の逆です。Time Machine、手元の Git オブジェクト、パスフレーズで暗号化してからコピーしたファイルでは、復号の材料は自分の側にあります。パスフレーズ、ローカルの鍵、あるいは自分で開けるキーチェーンです。サーバーが秘密鍵を独占するとき、設計の向きは変わります。転送の途中では第三者が見えず、着いたあとクラウドは開けます。調査記録の整理は、用途を狭く書いています。使えるのがサーバーだけの鍵であり、それが向いているのはサーバーがコードを読むことであり、自分で巻き戻すことではありません。
上海交通大学データ法律研究センターの何淵氏は、『毎日経済新聞』に対してさらに狭く言っています。暗号化は安全対策であり、匿名化と同じではなく、告知と最小限の代わりにもなりません。サービス提供者が復号能力をまだ持っているなら、暗号化したあとのデータも復元し、処理し得ます。「使ったあとすぐに削除」が下げるのは長期保存であり、最初の収集が必要だったかは答えません。二つを並べると、算法の強さは鍵の所在を証明せず、破棄の声明は収集範囲を証明しません。
本番のリポジトリ、生きたクラウド鍵、顧客のコードで「アップロードの再現」をしないでください。照合するのは、この端末に送信待ちの暗号文がすでに出ているか、状態ファイルのパスと失敗回数、そして自分でこのファイルを開けられるかです。生きたリポジトリをもう一度送っても、秘密鍵は手元へ戻りません。
平文の一覧が、範囲をすでに書いている
暗号文が開けないからといって、範囲は推測だけではありません。梱包時のファイル一覧は手元に残り、しかも平文です。42,411 件は、「いまのソース」と「リポジトリの一生」を分けています。いまのツリーはおよそ 13.4% だけで、残りは LFS のキャッシュ、オブジェクト庫全体、reflog です。いまの作業ツリーから消した API キーも、一度コミットしていれば .git/objects に残り得ます。未 push のブランチ名は、まだ出していない機能を見せます。社内 Git のホスト名は .git/config にあり、暗号文を開けなくても、一覧の側から「包みに入った」と分かります。
画面の二つのスイッチは、名前は総スイッチに見えて、コードではそうではありません。調査記録が対照したあとの結果はこうです。「优化体验」はモデル学習に使ってよいかだけを制御し、「仓库快照索引」はクラウドが索引を作るかだけを制御します。梱包と直送は、ログインの JWT が有効なあいだ続きます。捕獲点は、Prompt を出す直前と、タスク終了時の repo-wiki-update です。一度のアクティブなセッションで、捕獲は最大 62 回まで記録されています。送信待ちの包みを手で消してから約 30 分で、新しい 313 MB のファイルが作られ、失敗カウントは 564 から 565 になりました。ファイルを消すことは、スイッチを切ることではありません。
9月18日に保存されたプライバシーポリシーは、ページ上の最終更新が 2026-06-15 のままで、収集範囲は会話で送ったテキスト、ファイル、コードと書いていました。「ログイン後にワークスペース全体と Git 履歴を自動で梱包する」とは書いていません。ポリシーが支えられるのは、事業者がセッション送信を宣言したことまでです。全量スナップショットが、自分が同意を押したそのページに書いてあったことは支えられません。スイッチもプライバシーポリシーも、実際の産物と照合します。手元に新しい .enc があるか。状態ファイルの workspacePath が、いま書いている商用プロジェクトか。
「暗号化済み」と「すぐに破棄」が、それぞれ証明できること
報道の文を「支えられる / 支えられない」に分けると、形容詞に流されにくくなります。ディスク上の暗号文が支えられるのは、包んだあとのバイト列がディレクトリツリーの平文ではないことまでです。すぐに破棄が支えられるのは、事業者が Wiki 生成後そのオブジェクトを長く置かないと宣言したことまでです。オープンソース後のリポジトリで /api/v1/snapshot/upload-credential が見つからないことが支えられるのは、いま公開されているツリーからその経路が外れたことまでです。バケットの評価がデータゼロであることが支えられるのは、評価したその時点でそのバケットが空だったことまでです。
これらの文は、反対側を覆いません。暗号文は、自分でワークスペースを復元できることを支えません。すぐに破棄は、破棄の前に誰も秘密鍵を持っていなかったことを支えず、収集範囲が自分の入れた項目と同じであることも支えません。二回のコミットに平らにしたオープンソースのリポジトリは、旧版のサイドカーがどう書いていたかの対照にはなりません。あとから空にしたバケットは、9月18日より前に受付済みのオブジェクトを誰が復号し、誰が複製したかを遡れません。ferstar はこうも書いています。チェックポイントの巻き戻しが本当に全量のクラウド送信を必要とするなら、「生成後すぐに破棄」と時間の向きが合いません。オープンソースのツリーにあるチェックポイント実装は、この端末の Git diff であり、メタデータは ~/.zcode/checkpoints/ の JSON です。あのアップロード経路には依存していません。
| 見える言い方 | 支えられる結論 | 支えられない結論 |
|---|---|---|
| ディスク上は .enc、算法は AES-256 | 包んだあとのバイト列はワークスペースの平文ではない | 復号できるのは自分だけ。クラウドは中身を読めない |
| 資格申請のとき、RSA 公開鍵をサーバーが渡す | エンベロープを開ける秘密鍵は、このパソコンにない | 端末をまたいで自分で戻すためのバックアップである |
| 「体験の最適化」と「リポジトリ索引」を切った | 学習の許諾、またはクラウド索引は止まったかもしれない | 梱包と直送も必ず一緒に止まった |
| 公式は Wiki 生成後すぐに破棄すると言う | 事業者はそのオブジェクトを長く置かないと宣言した | 最初の梱包範囲は、自分の入れたスイッチと同じである |
| 評価ではバケットがデータゼロ | 評価したその時点で、そのバケットは空だった | それより前に受け取ったオブジェクトは、一度も復号も複製もされていない |
| 313 MB の一份は 564 回失敗した | この商用プロジェクトのスナップショットは出ていない | どの利用者の機械からも、ワークスペースは一度も出ていない |
その場で照合できる層
スローガンは証拠になりません。下で見るのは、自分で制御できる三層だけです。この端末に送信待ちの産物があるか。リクエストがワークスペースの平文を運んでいるか。この暗号文を自分で開けるか。本番リポジトリへ「テスト送信」をもう一度流さないでください。
- 宣伝ページより先に、この端末のデータディレクトリを見ます。AI コーディングクライアントのチェックポイントやキャッシュに、数百 MB の
.encと、workspacePath、encryptedSizeBytes、failureCountを書いた状態ファイルがあれば、梱包はすでに起きています。パスがいま書いているプロジェクトと一致する方が、「送るのは会話の文脈だけ」より硬いです。 - 開発者ツールかシステムの通信観察を開き、Preserve log を入れます。見るのはリクエスト行とホスト名です。アップロード資格を申請する API があるか。オブジェクトストレージへ直結するフォーム POST があるか。照合するのは「暗号文がこの機械を出たか」であり、リポジトリをもう一度送ることではありません。リクエスト本文にソース、パスフレーズ、
.pemの平文が出たら、この層はすでに失敗です。 - 地面に落とせる問いを一つ置きます。この手元の暗号文を、自分のパスフレーズか、この端末の秘密鍵で開けるか。開けず、事業者もクライアントは開けないと言うなら、鍵の所在は自分の側にありません。開けてから初めて、「これは自分のためのバックアップ」と言えます。
- 名前が「プライバシー / 索引 / 最適化」に見えるスイッチをすべて切り、セッション一周期待ち、チェックポイントのディレクトリに新しい送信待ちの包みが出るか、失敗カウントが増え続けるかを見ます。スイッチの文言は総スイッチを証明しません。新しいファイルが証明します。
- 自分でまだ開けられるファイルが要るときは、計算の境界が書いてある経路へ切り替えます。ファイル暗号化を開き、捨ててよいカナリアを選び、ファイル名は
canary-fp-20260922-vendor-key.txt、パスフレーズはこのパソコンだけに残します。Network を開き、Preserve log を入れて暗号化します。リクエスト行と本文に、ファイル内容、パスフレーズ、ファイル名そのものの業務欄が出てはいけません。出力は.lock/.enc、単ファイルは 5 GB までです。同じパスフレーズでこの端末から復号し、カナリアが戻ることを見ます。開けられるのは、パスフレーズが自分の手元にあるからです。算法の名前に AES と書いてあるからではありません。
第五項は、ファイル暗号化にコーディングクライアントの代わりをさせません。対照を一つ置くだけです。同じ「この端末で暗号化」でも、鍵の導出と AES-256-GCM は今開いているタブに残り、ファイルとパスフレーズは初期状態では業務データとしてアップロードしません。暗号文は持ち出せ、自分でも開けます。前のノートが書いた中継の問題は別の層です。HTTPS が守るのはプロキシまでの一ホップです。このノートが足す層は、暗号文が出たあと、エンベロープを開けるのは誰かです。
完全なパスフレーズと暗号文を、同じチャットへ流さないでください。ファイル暗号化の .lock はオンラインストレージへコピーでき、パスフレーズはすでに確認した経路か、短い文ならワンタイムリンクの # の後ろへ分けます。鍵と錠を同じメッセージへ貼ると、そのメッセージを見られる人に対して、エンベロープはすでにありません。
「ローカル暗号化」を読みすぎる三つの場合
第一は、「この端末で AES を呼んだ」を「復号できるのは自分だけ」と読むことです。呼び出しがこの端末で起きたことは、平文を包んだ時点ではまだこのパソコンにあった、までです。公開鍵がサーバーから来て、秘密鍵が落ちないなら、復号の権利はクラウドにあります。算法の一覧、鍵長、CTR か GCM かは、「秘密鍵が誰のプロセスにあるか」に答えません。
第二は、「オブジェクトストレージへ直送し、業務サーバーを通さない」を「事業者は見えない」と読むことです。ファイルはアプリケーションサーバーを通らなくても、受付のコールバックと秘密鍵は事業者の側に残ります。業務のマシンルームを飛ばすと減るのは、アプリケーションログの平文コピーです。復号の権利は減りません。中継のノートは、HTTPS がアプリケーション層のプロキシを止めないと書いています。ここで止まらないのは、「秘密鍵を持つ側」です。
第三は、「すぐに破棄 / オープンソース / バケットは空」を「一度も収集していない」と読むことです。破棄は保存期間を下げ、オープンソースはいまのツリーを照合させ、空のバケットは評価した時点にオブジェクトがなかったことを示します。どれも自動では、過去のオブジェクトが復号されていないこと、当時のスイッチが Git 全量を覆っていたことにはなりません。引き継ぎに書けるのは、この端末がまだ送信待ちの包みを作っているか、外へ出す暗号文を自分で開けられるかです。見出しの「是正済み」ではありません。
よくある質問
ディスク上がすでに暗号文なら、この端末のゼロ知識と同じですか？
同じではありません。暗号文が示すのは、包んだあとのバイト列が平文のワークスペースではないことまでです。対称鍵を包む RSA 公開鍵をサーバーがその場で渡しているなら、対応する秘密鍵は端末へ落ちません。自分もクライアントも、このファイルを開けません。これはクラウドが読むためのエンベロープであり、自分で復元するためのバックアップではありません。
公式がアップロード後すぐに破棄すると言うとき、まだ何を照合できますか？
「すぐに破棄」が下げるのは、長期保存です。最初の梱包範囲が、自分の入れたスイッチを超えていたかは答えません。破棄の前に誰が秘密鍵を持っていたかも答えません。あとからバケットを空にしても、9月18日より前に受け取ったオブジェクトを誰が復号し、誰が複製したかは遡れません。
画面の「体験の最適化」と「リポジトリ索引」を切れば、アップロードも止まりますか？
分解された旧クライアントでは、この二つはそれぞれ「学習に使ってよいか」と「クラウドが索引を作るか」を分けていました。梱包と直送は切りません。見るべきなのは、独立した「スナップショット生成を止める」スイッチがあるか、切ったあとも手元に新しい送信待ちの暗号文が出るかです。
自分でまだ開けられるファイルを同僚へ渡すには、どの経路ですか？
今開いているタブで AES-256-GCM により暗号化し、パスフレーズは身元を確認した受け手だけに伝えてください。ファイル暗号化を開けば足ります。単ファイルは 5 GB まで、出力は .lock / .enc、ファイルとパスフレーズは初期状態ではアップロードせず、開いてすぐ使え、アカウントは不要です。短い秘密は ワンタイムリンク へ切り替え、鍵はリンクの # の後ろに置きます。形は s.html?id={id}#{key} です。チケットやログに電話番号や身分証番号が重なっているときは、先に 個人情報マスク で規則に沿って伏せ、原文は業務データとしてアップロードしません。
自分で開けたいときは、開いてすぐ使える経路へ切り替える
「暗号文は自分で開け、パスフレーズは Network に入らない」を、計算の境界が書いてあるページで練習するなら、FastPwd の ファイル暗号化 を開けば足ります。登録は不要です。上のカナリアを選び、今開いているタブで AES-256-GCM をかけ、第五節どおり照合します。リクエストにファイル内容とパスフレーズは出ず、同じパスフレーズでこの端末から戻るはずです。出力の .lock / .enc はオンラインストレージへコピーできます。パスフレーズは同じチャットへ書かず、AI の入力欄へも書きません。
リポジトリの断片をクラウドのモデルへ渡すときは、受け手が貼った全文を見ると先に仮定してください。中継は HTTPS が終わる地点に平文の呼び出し包みを残します。前のノートがすでに書いています。このノートが足す問いは、クライアントが先に「暗号化」してから上げるとき、エンベロープを開ける秘密鍵が自分の側にあるかです。二層とも通らないなら、生きたクラウド鍵、SSH の秘密鍵、顧客データを、梱包するツールのワークスペースへ置かないでください。規則マスクが伏せられるのはよくある欄です。まとまった鍵はワンタイムリンクへ回すか、外へ出さないでください。
次に「ローカルで暗号化してからアップロードします」という説明を見たら、三つを覚えておいてください。第一に、算法の名前より先に、秘密鍵かパスフレーズが誰の手元にあるかを問います。第二に、一覧がいまのファイル以外の .git 履歴まで覆っているかを問います。第三に、破棄の声明ではなく、自分で開けられる暗号文を対照にします。引き継ぎに書けるのはこの三文までです。「ディスク上は暗号文だから、クラウドは見えない」は書けません。
関連記事
クラウドへ上げる前のパスワード付き ZIP はファイル名を止めず、この端末の AES-GCM でもありません。クラウドへ上げる前、パスワード付きZIPが止められる範囲と、それが本機のAES-256-GCMではない理由。HTTPS が守るのは中継までの一ホップであり、Prompt の中の SSH 鍵は止めません。LLM中継の6TB呼び出しダンプにSSH鍵が出る理由と、HTTPSが止められない層。画面の「ローカル暗号化」を Network で自分で照合する手順は、ブラウザのローカル暗号化で、平文が端末を出ていないことを確認する にあります。