智譜ZCodeのコード密送騒動を追う：Agentのデータ行為は誰が監査するのか？

著者 | 林克、鄭好

過去2年間、Agentのセキュリティをめぐる議論の重心は、主にモデルの暴走、プロンプトインジェクション、外部攻撃者に置かれてきた。それに比べ、Agentメーカー自身のデータ行為が第一級のリスクとして論じられることはほとんどなかった。

このほど明らかになった智譜ZCodeの事件は、問題をこれまで真剣に扱われてこなかった方向へと向けつつある。すなわち、Agentの製造者そのものがデータ外部流出の発生源になり得るのか、という問いだ。

9月18日、技術ブロガーのferstarが智譜ZCodeのリバースエンジニアリング解析を公開した。彼は、ユーザーがアカウントにログインしさえすれば、ZCodeがバックグラウンドで作業中のプロジェクト全体を、完全な変更履歴ごとパッケージ化して暗号化し、クラウドサーバーへアップロードすることを発見した。

ソフトウェアのインターフェースには実際に機能する無効化スイッチがなく、暗号化ファイルの復号鍵は智譜側にのみ保存されている。智譜はすぐに謝罪し、問題はある機能がデフォルトで有効になっていたことに起因し、データは使い終われば即座に破棄されると説明。近くコードベースをオープンソース化し、第三者による審査を導入すると約束した。

ZCodeが今回露呈した問題は、もはや業界の孤立した事例ではない。

少し前、独立系セキュリティ研究者のcereblabはパケットキャプチャ解析によって、xAIのプログラミングAgentツール「Grok Build」がユーザーのプロジェクト全体をGoogle Cloud Storageへアップロードしていることを証明した。それには、ユーザーがAIに「読むな」と明確に指示したファイルや、マスキングされていないパスワードも含まれていた。

さらに以前には、Claude Codeがユーザーの知らないうちに位置情報や身元情報を送り返していたことが発覚し、Anthropicのエンジニアは事後になって、それが意図的な実験だったと認めた。

より重要なのは、これらの問題が発覚したのが規制やセキュリティ監査によるものではなく、往々にしてコミュニティの個人によるものだという点だ。そして現在、業界がAgentのために構築したセキュリティフレームワークには、メーカー自身の行為を拘束するルールが今に至るまで1本も存在しない。

一. 起点はハードディスクの異常

9月18日、技術ブロガーのferstarはZCodeのローカルディレクトリを調査中、ハードディスクの使用容量が異常であることに気づいた。彼は約313MBの暗号化ファイルを見つけたが、そのサイズは日常的なものをはるかに超えていた。ファイルは開けなかったが、添付されていたファイルリストによると、このパッケージには約4万2000個のファイルが含まれ、そのうち8割以上がプロジェクトの履歴変更記録だった。

この記録にはプロジェクトファイルだけでなく、かつてダウンロードした大容量ファイルのキャッシュやローカル操作ログも含まれていた。パッケージ化されたのはプロジェクトそのものだけでなく、プロジェクトの「誕生以来の経歴」も含まれていたのだ。

その後のコード解析で、この履歴記録はパッケージ化のプロセスにおいて、すべての安全フィルタリングルールから免除されていることが判明した。

ZCodeのファイル選別ロジックは順番に判定される仕組みで、履歴記録ディレクトリの通過許可は、鍵ファイルのフィルタリングや容量制限よりも前に置かれている。つまり、pemやkeyなどのパスワードファイルを対象としたフィルタリングや1MBの容量上限は、履歴記録ディレクトリ配下のいかなるコンテンツにも効かないということだ。

これは、数百MB規模のパッケージファイルを丸ごと持ち出せることを意味し、かつて履歴記録にコミットされ、その後削除されたパスワードや鍵も、そのままの形でアップロードされることを意味する。

さらに厄介な操作がその先にある。復号鍵がユーザーのパソコンの中にないのだ。

ferstarはファイルのアップロード経路を分解・復元した。まずクライアントが智譜のサーバーにアップロード用の認証情報と暗号化用の公開鍵を要求し、その後ローカルで圧縮・暗号化を完了し、智譜自身の業務サーバーを迂回して、直接Alibaba Cloudのクラウドストレージサービスへアップロードし、さらにクラウドストレージが智譜のバックエンドへコールバックする、という流れだ。

ここで暗号化の方式を少し説明しておく。

公開鍵は錠前に相当し、誰でもそれを使って物を箱に閉じ込めることができる。秘密鍵は鍵に相当し、鍵を持つ者だけが箱を開けられる。ZCodeのやり方は、錠前はサーバーが一時的に発行し、鍵はサーバー側にのみ保存されるというものだ。Agentはユーザーのパソコン上で暗号化パッケージを生成するが、ユーザー自身は中に何が入っているのか確認することすらできない。

ferstarは、この仕組みが2つのタイミングで発動することを発見した。1つはユーザーがAIにリクエストを送る前、もう1つはタスク終了後だ。活発に使用している過程で、彼は最大62回のスナップショット記録を観測した。

インターフェース上でこれに関係するように見える2つのオプションについて、彼がコードロジックを逐一照合して確認したところ、1つは「体験の最適化」という名称で、実際にはデータをモデル訓練に使うかどうかだけを制御するもの。もう1つは「リポジトリスナップショットインデックス」という名称で、実際にはサーバー側がデータを受信した後に検索用ディレクトリを作るかどうかだけを制御するものだった。

両方をオフにしても、ローカルでのパッケージ化とアップロードは通常どおり実行される。スナップショットとアップロードを担当するコンポーネントは、ソフトウェア起動時に無条件でロードされ、唯一の前提条件はユーザーがログイン状態にあることだけだ。

プロジェクトファイルに加え、スナップショットは毎回ZCode自身のグローバル設定も一緒にパッケージ化し、プロジェクトをまたいで持ち出す。

ferstarは、その313MBの送信待ちファイルを手動で削除してみた。30分後、ZCodeは自動的に新しいパッケージファイルを再生成した。Agentはこっそりアップロードに失敗すると、何度も再試行するのだ。

削除してもまた作り直す。これは、あってもなくてもよい補助機能が持つべき執着の度合いではないだろう。

二. 明確に答えられなかったこと

この記事はその夜、コミュニティで急速に拡散し、智譜は素早く対応して謝罪した。

今回の問題は、ZCodeの「コードベースインデックス」機能に起因するものです。この機能は、ユーザーがローカルでリポジトリのインデックスを生成するのを支援し、履歴バージョンを含むセッションのチェックポイント復元、履歴バージョンへのロールバック、Repo Wikiなどの機能をサポートすることを目的としています。

Repo Wiki機能は、Wikiページを生成する際にリポジトリデータのアップロードをトリガーする可能性があります。Wikiページはクラウド上で生成された後、関連するアップロードデータは即座に破棄され、保存されることはありません。この機能はリリース初期にデフォルトで有効になっていたため、一部のユーザーに影響が及びました。この点について深くお詫び申し上げます。現在、関連する問題はすでに修正されています。

智譜はまた、近くZCodeのコードベースをオープンソース化し、第三者評価者を招いてシステムの稼働状況を審査してもらうこと、そして全ユーザーに週間クォータのリセットを1回分追加補償し、当日中に配布することを約束した。

ここでいう「コードベースインデックス」とは、プロジェクトファイルのディレクトリと検索システムを構築するもの。「Repo Wiki」とは、プロジェクトの説明ドキュメントを自動生成する機能。「セッションチェックポイント復元」と「履歴バージョンロールバック」は、ユーザーがAIとの対話過程で以前のステップに戻れるようにする機能だ。

これらの機能自体は合理的であり、対応も迅速だった。しかし肝心なのは次の点だ。

それは、説明していることとコミュニティが追及していることが同じ事柄ではない、ということだ。

智譜はこのインデックスについて「ユーザーがローカルで生成するのを支援することを目的としている」と述べた。ローカルで生成するのであれば、なぜプロジェクト全体をクラウドへ送る必要があるのか。ローカルでインデックスを作り、ローカルでスナップショットを取り、ローカルでロールバックすることは技術的に完全に可能であり、市場には実際にそうしているツールも存在する。

説明は「ローカルインデックス」と「クラウドへのアップロード」を一文にまとめ、あたかも後者が前者の自然な延長であるかのように見せているが、その間には重要な一環の説明が欠けている。

対応は問題をRepo Wikiに帰し、「Wikiページを生成する際にリポジトリデータのアップロードをトリガーする可能性がある」とした。しかしferstarのリバースエンジニアリング記録によれば、アップロードがトリガーされるタイミングの1つは、ユーザーが質問を送るたびの直前であり、説明ドキュメントの生成とは無関係だ。

ZCodeの現在の公式ドキュメントは、説明ドキュメント生成時にプロジェクトの履歴変更記録を読み取らず、選別されたコードコンテキストだけを必要に応じて読み取ると明記している。これは、この機能が技術的に履歴記録を必要としないことを示している。

では、これまでにアップロードされたパッケージのうち、なぜ86.6%が履歴記録だったのか。説明は、当初のアップロード範囲がなぜこれほど大きかったのか、設計どおりなのかプログラムの誤りなのか、どのバージョンから修正されたのかについても、何も答えていない。

説明で使われた表現は、この機能が「リリース初期にデフォルトで有効になっていた」というものだ。これはむしろ、メカニズムレベルのデータ外部流出を、ある機能のスイッチ設定の問題として表現したものに近い。

ferstarのコード解析によれば、インターフェース上の2つの関連オプションは、1つは訓練を、もう1つはインデックスを制御するもので、いずれもパッケージ化とアップロードという行為そのものを制御できない。

コミュニティの追及の核心は、ユーザーが見ているコントロール項目が実際に起きていることを制御できないという点にあり、これは「ある機能がデフォルトでオンになっていた」という問題とは桁違いの話だ。

すぐに、よりセンシティブな証拠もコミュニティによって掘り起こされた。それはZCode v3.12.2バージョンの更新ログで、日付は2026年9月16日、ferstarの投稿のわずか2日前だった。

そこには「リポジトリスナップショットアップロードのメモリ使用量を最適化」という記録がある。エンジニアリングチームが、偶発的な挙動に対してメモリを最適化することは考えにくい。これは「リポジトリスナップショットアップロード」が内部では継続的に反復開発されている正常な機能であることを示している。

この更新ログは事件が拡散した後に削除された。公開記録を削除すること自体が、元の行為とは独立した新たな問題だ。

「関連するアップロードデータは即座に破棄され、保存されることはない」という一文が答えているのは、データがどれだけ保持されるかという点だけだ。しかしユーザーが本当に知る必要があるのは、データがすでにパソコンを離れたのか、サーバーでの処理過程で誰がアクセス権限を持つのか、暗号化パッケージの復号能力が誰の手にあるのか、これまでにアップロードされたデータに対してどのような削除方針が実行されたのか、といった多くの問いだ。

暗号化方式から見ると、鍵はサーバー側にある。したがって「暗号化アップロード」が証明するのは、転送途中で第三者に傍受されないということであり、智譜自身が内容を解読できないということにはならない。

ZCodeのプライバシーポリシー英語版は、収集範囲について、ユーザーが「through conversation」（対話を通じて）提出したテキスト、ファイル、コードと表現している。しかしバックグラウンドのスナップショットは、ユーザーが対話を通じて提出したものではない。この行為はプライバシーポリシーが記述する範囲外だ。「対話の中で当社に提出する」ことと「バックグラウンドでプロジェクト全体を自動的にパッケージ化する」ことは別物である。

このプライバシーポリシーにはまた、新機能が元の目的と直接的または合理的な関連性のない情報収集を伴う場合、ページ上の通知やインタラクションフローなどの方法で別途告知し、ユーザーの同意を得るべきだと明記されている。

別の開発者である馮若航のコード解析では、クライアントが質問を送るたびに無条件でサーバーへアップロード用の認証情報を申請し、サーバーが認証情報を発行すれば収集し、発行しなければ収集しないことが判明した。

ferstarが見つけた313MBのファイルは当時送信待ち状態で、すでに564回失敗していた。馮若航は自分のMac上でferstarのフォレンジック手順を独自に再現し、4つのワークスペースのスナップショット記録のうち、少なくとも1つのスナップショットのステータスファイルに、サーバー側の受信確認マークが書き込まれていることを確認した。

コードロジック上、このマークはアップロードがサーバーに受信確認された後にのみ生成される。これは、少なくとも1台のマシン上のデータが確かにローカルを離れたことを意味する。智譜の謝罪、約束、補償は、論争が拡大してから数時間以内にすべて提示された。その反応速度は、長期にわたる隠蔽を準備していたようには見えない。

しかし「即座に破棄」であれ「保存しない」であれ、こうした約束は外部から検証できず、反証もできない。ユーザーが見られるのは、データが自分のパソコンを離れたという事実だけで、その後何が起きたかは完全にメーカーの自己規律に依存する。

智譜が約束したオープンソース化と第三者審査がこの点を変えられるかどうかは、オープンソース化されるのがどのバージョンなのか、審査がカバーするのがクライアントなのかサーバーなのかにかかっている。これらの問いには現時点で答えがない。

三. コードデータよりもセンシティブなもの

もし本当にユーザーデータを収集しようと意図しているメーカーがいるとすれば、欲しいのはおそらくユーザーのコードそのものではないだろう。

なぜなら、各コードホスティングプラットフォームの公開プロジェクトは、モデル訓練に十分なコーパスを提供しているからだ。プライベートコードにはもちろん営業秘密が含まれるが、モデル改善の観点から見れば、単にコードテキストを1バッチ多く入手するだけの限界的価値は高くない。

本当に希少なのは次の3つだ。

1つ目は、変更の因果連鎖だ。

プロジェクトの履歴変更記録に保存されているのは、1枚1枚のスナップショットではなく、「変更前はこうだった、こういう理由で、こう変わった」という完全なプロセスだ。このような前後の因果関係を持つシーケンスは、プログラミングモデルを訓練する上で最も理想的な学習材料である。プロジェクトの現状と1つの変更意図が与えられたとき、モデルはどのような変更を加えるべきか。

2つ目は、結果のラベル付きの使用軌跡だ。

ZCodeの発動メカニズムは、ユーザーが質問を送るたびに「全景写真」を1枚撮り、同時にロールバック機能も備えているため、ユーザーはAIが加えた変更を取り消すことができる。この2つの動作が組み合わさることで、「質問＋操作前の状態＋操作後の状態＋ユーザーが満足したか（取り消したかどうか）」という完全なループが自然に記録される。この種のデータはAI訓練において極めて高価で、通常は人を雇ってラベル付けする必要がある。ZCodeのスナップショットメカニズムは、ユーザーが通常の使用の中でこれらのラベルを無料で生成しているのに等しい。

3つ目は、どのモデルにも見られたことのないリアルなプロジェクトだ。

現在公開されているプログラミング評価問題は、ほぼすべて各社のモデルが訓練時に「一度解いた」ものであり、スコアは実力以上に高くなっている。リアルで、訓練セットに入ったことのないプライベートプロジェクトこそ、内部能力評価を行う上で最も価値のある原料だ。

この3つは確かにZCodeのアップロードパッケージの構成と高度に一致している。これこそが、コミュニティが「説明ドキュメントを生成するためだけだった」という説明を最後まで受け入れない理由だ。

しかし逆に言えば、もし目的が本当に訓練データの体系的な収集なら、より正確なやり方は質問内容とコード変更だけを抽出することであり、数百MBもの大容量ファイルキャッシュや完全な操作ログまで一緒にパッケージ化する必要はないはずだ。

この過剰収集の形態は、むしろエンジニアリングチームがスナップショット機能を開発する際に、汎用的なパッケージ化ロジックを再利用し、インデックスやロールバックに関連する全ファイルをまとめて放り込んだものに近い。加えて、クラウドストレージ自体にコストがかかり、大量の個人ユーザーの小規模プロジェクトや練習用コードはモデル訓練への実用的価値が限定的であり、有料顧客、特に企業顧客のデータに手を出すのは、リスクとリターンのバランスが極めて割に合わない。

認めなければならないのは、これらのデータを利用してモデルやツールを改善する動機は成立し、その経路も既に存在するということだ。しかしアップロードパッケージの粗雑さから見ると、過激なプロダクト判断とエンジニアリング面での手抜きが重なったという説明の方が、「智譜が故意に何かを企てた」という説明よりも、既存の証拠に合致している。

もちろん、智譜に主観的な故意がないからといって、この問題の深刻さを軽視してはならない。これは確かにユーザーにセキュリティ上のリスクをもたらす。

四. Agentメーカーたちの集団的な越境

ZCode事件と似た騒動は、今年すでに一度ならず起きている。

今年7月、独立系セキュリティ研究者のcereblabは、xAIのGrok Buildに対して完全なネットワークパケットキャプチャ解析を行い、すべての証拠と再現手順を公開した。

彼が発見した現象はZCodeよりもさらに過激だった。Grok Buildはユーザーのプロジェクト全体をコードパッケージにまとめてGoogleのクラウドストレージサービスへアップロードする。アップロード範囲はすべてのファイルをカバーし、ユーザーが対話の中でAIに「読むな」と明確に指示したファイルも含まれる。12GBのテストプロジェクトでは、パケットキャプチャを中断した時点で確認されたファイル容量は5GBを超えていた。

テストではまた、プロジェクト内のパスワードや鍵ファイルまでもがそのままアップロードされ、いかなるマスキング処理も施されていないことが判明した。ユーザーが設定で「モデル改善」オプションをオフにしても、アップロードは通常どおり続行された。オフにしたのは訓練の許可だけで、コードがパソコンを離れるかどうかには影響しない。

マスクは事件が暴露された後、アップロード済みの全データを削除すると公に約束し、xAIはサーバー側でアップロード機能を停止した。

さらに前の3月31日、Claude Codeはあるバージョンリリースの際、設定ファイルの不注意により、約60MBのソースマップファイルが誤って公開リリースのインストールパッケージに混入し、外部の開発者がこのツールのアーキテクチャを目にすることができた。

コミュニティは、Claude Codeが毎時Anthropicのサーバーへリモート設定を1回ポーリングしており、設定項目にはプログラムを強制終了させたり、ユーザーの権限プロンプトを迂回したりできる複数の制御スイッチが含まれ、すべてバックグラウンドで有効になり、ユーザーが自ら更新する必要はないことを発見した。

Claude Codeはかつて、ユーザーのプロキシ、ゲートウェイアドレス、中国タイムゾーンなどの環境シグナルを読み取り、システムプロンプト内の隠し文字を通じて分類結果をサーバー側へ持ち帰っていたことが発覚した。Anthropicのエンジニアはその後、これがアカウント悪用対策と蒸留対策のための能動的な実験だったと認めた。

主観的な故意の度合いで見ると、Claude Codeはメーカー自身が認めた意図的な実験であり、Grok Buildは今に至るまでアップロードメカニズムの存在を否定しておらず、ZCodeの意図はまだ結論が出ていない。

データ収集の範囲で見ると、Grok Buildはユーザーが明確に「読むな」と言ったファイルまで持ち出し、ZCodeはプロジェクト履歴の86.6%をパッケージ化した。Claude Codeが送ったのは行動メタデータで、量のレベルは異なるが、性質としては同じく知る権利に関わる。

3つの事故で警戒すべきなのは、いずれも発覚が偶然によるものだという点だ。1つは設定ミスによるソースコード漏洩、1つはセキュリティ研究者の能動的なパケットキャプチャ、1つはブロガーのハードディスク容量の異変への警戒心によるもので、メーカー自発のデバッグや業界監査、規制当局の巡回によるものは1つもなかった。

ZCodeが今年7月にリリースされたとき、智譜の宣伝はClaude Codeを直接ベンチマークしており、ちょうどClaude Codeのテレメトリ論争が過ぎ去ってから数週間後だった。ZCodeは自らを「メーカーによるリモート制御から脱却できる」代替オプションとして位置づけていた。そしてGrok Buildのアップロード事件も7月に発生しており、ZCodeのリリースとほぼ同じ月だった。

3か月後、同じ性質の問題がZCode自身の身に降りかかり、データ範囲はさらに大きかった。信頼を売りにした者が先に転んだ。これはおそらく今年のAIツール競争において最も警鐘的な一幕だろう。

五. 安全ルールは外側にしか向いていない

Agentがこの1年で手に入れた権限は、これまでパソコンにインストールされたどの種類のソフトウェアをも超えている。

Agentは現在のプロジェクトディレクトリ内の全ファイルを読み取れ、自律的にコマンドライン操作を実行でき、同時にメーカーのサーバーとの接続を常に維持し、バックグラウンドでリモート設定の更新を受け取ることもできる。

これ以前には、この4つの条件を同時に満たすコンシューマー向けソフトウェアはほとんど存在しなかった。これらの新しい権限をめぐる安全ルールは、確かにこの1年で急速に更新されてきた。

2025年末、国際的なアプリケーションセキュリティ組織OWASPは、自律型AI Agentを対象とした初の十大リスクリストを発表した。2026年1月、シンガポールは自律型AI Agentを対象とした初のガバナンスフレームワークを打ち出し、各Agentに検証可能なデジタルIDの搭載を求めた。2月、米国国立標準技術研究所（NIST）はAI Agent標準イニシアチブを開始した。8月2日、EU人工知能法の高リスク義務が正式に発効した。業界レベルでも、プログラミングAgentに特化した認証基準が登場している。

ルールの数は増えているが、それらが防いでいるのは、ツールが外部の攻撃者に悪用されることだ。たとえば、悪意ある命令にハイジャックされること、権限を超えて他のシステムを呼び出すよう誘導されることなどだ。

防衛線全体の設計前提は、メーカーがユーザーの側に立ち、脅威は外から来るというものだ。

ZCodeとGrok Buildの外部流出経路は、まさにこの前提の盲点に位置している。それらはAIツールの能力リストに載っておらず、権限承認プロセスの管轄下になく、ツールのループ全体の外側で動作し、AIアシスタント自身もその存在を感知できない。現存するどの安全フレームワークで1条ずつ審査しても、これらの行為は警報を発しない。

上場企業の財務諸表を監査するように、Agentのデータ行為を監査すべきだという意見がある。

この類推は部分的に成立する。定期的で、標準化され、独立した第三者によって作成され、買い手が読んで理解できる審査報告書という形式は正しい。

しかし財務監査が審査するのは、法律が企業に保持を義務付けた帳簿だ。「どのデータがユーザーのパソコンを離れたか」という記録には、メーカーに保持を義務付ける法規が一切存在せず、証拠そのものが不足している。

Agentクライアントは毎週更新される可能性があり、中には毎時リモート設定をポーリングして自身の挙動を変えるものもある。年次監査報告書は、発行されたその瞬間にすでに期限切れなのだ。

上場企業の監査の背後には、証券法と監査機関の連帯賠償責任がある。Agent監査の背後には、現時点で何もない。

オープンソース化は、広く議論されているもう1つの道だ。智譜は今回の事件後にZCodeのコードベースのオープンソース化を約束し、OpenAIのCodex CLIや以前のGemini CLIもオープンソースライセンスを採用している。

オープンソース化によって、コミュニティはクライアントに同様の外部流出メカニズムがないか検査できる。この透明性自体が拘束力を構成する。しかしオープンソース化にはいくつかの自然な限界がある。それはクライアントにしか光を当てられず、サーバーには当てられない。データがメーカーのサーバーに届いた後に何が起きるかは誰にも見えない。

修正後のバージョンだけをオープンソース化し、事件当時のコードを公開しなければ、過去の行為に対する証明力はゼロだ。しかもユーザーがアプリストアやインストーラーから入手するのはコンパイル済みの完成品であり、公開されたソースコードと同じものかどうかは、専用の再現性検証を行わない限り確認できない。

現時点でより現実的な道は、いくつかの方が実行可能性が高い。

1つ目は、メーカーに対し、Agentがどのサーバーアドレスに接続し、どのカテゴリのデータを送信するかを公に宣言するよう求めることだ。そうすれば、異常なトラフィックを独立したツールで照合できる。cereblabのGrok Build解析は、標準的なネットワークパケットキャプチャツールで行われた。メーカーが能動的に出口宣言を提供すれば、検証コストは大幅に下がる。

2つ目は、ユーザー自身のパソコン上に、読み取り可能でエクスポート可能な外部送信ログを残すことだ。毎回の送信容量、送信先、データカテゴリを明記し、「暗号化パッケージがあなたのマシン上で生成されるのに、中身が見えない」という最も目障りな設計を直接解消する。

3つ目は、責任保険メカニズムだ。認証機関ではなく保険引受側にメーカーのデータ行為を評価させ、前者は判断ミスに対して賠償する必要がある。これは現在、「真剣な審査」を経済的利益に変えられる唯一のメカニズムだ。

これらの方案は技術的にはいずれも難しくない。難しいのは動機だ。

現在、それらの実現を後押しする力は2種類しかない。企業顧客の調達審査と、偶発的なコミュニティの暴露だ。前者はエンタープライズ版しかカバーせず、後者は完全に運任せだ。

だから最終的に、この事故の潜在的な矛盾は、安全技術の方案よりも処理が難しいかもしれない。

ZCodeとGrok Buildのシナリオでは、「同意」ボタンを押すのは開発者個人であり、データ漏洩の結果を負うのはその雇用主と顧客だ。後者は最初から最後まで、どの同意プロセスにも登場せず、自分のコードがパッケージ化されてアップロードされたことを知る手段も一切ない。

リスクの負担者と権限付与者が同一人物ではない。個人レベルのインフォームドコンセントは、構造的にこの問題を解決できない。ポップアップにどれほど明確に書かれていても、スイッチがどれほど目立つ場所に置かれていてもだ。

現実の行方は、おそらく階層化だ。

大企業は調達契約にデータ行為条項と監査権を盛り込み、そのために支払うコストは最終的に価格に反映される。個人開発者が使うコンシューマー版は、誰も審査せず、誰も責任を負わない状態が続く。しかしそこは、まさに大多数の人が仕事の合間にコードを書き続ける場所であり、彼らが個人アカウントで会社のプロジェクトを開きやすい場所でもあるのだ。