プライバシー研究者Alexander Hanff氏（That Privacy Guy）が2026年5月4日、Google Chromeがユーザーへの通知や同意なしに、約4GBのオンデバイスAIモデル「Gemini Nano」の重みファイルを端末へ書き込んでいると報告した。削除しても再ダウンロードされる挙動が複数の環境で確認されており、本記事ではその事実関係と、報告者がどう検証したか、そして読者が取れる一般的な対策を整理する。
何が起きたのか
Hanff氏によれば、Chromeがインストールされている端末のユーザープロファイル内に OptGuideOnDeviceModel というディレクトリが作られ、その中に約4GBの weights.bin が置かれる。これはGoogleのオンデバイスLLM「Gemini Nano」の重みファイルであり、「Help me write」やオンデバイスの詐欺検知など、Chromeのマーケティングされている機能を動かすために使われるという。
The file appeared with no consent prompt. There is no checkbox in Chrome Settings labelled “download a 4 GB AI model”. The download triggers when Chrome’s AI features are active, and those features are active by default in recent Chrome versions.（同意プロンプトなしにファイルが出現した。「4GBのAIモデルをダウンロードする」というチェックボックスはChromeの設定に存在しない。ダウンロードはChromeのAI機能が有効なときに発火し、その機能は最近のChromeではデフォルトで有効になっている。）
報告では、削除と再ダウンロードのサイクルがWindows環境の複数の独立したレポートで記録されているとされる。ユーザーが消しても、Chromeが再びダウンロードする——という繰り返しだ。Hanff氏はこれを、2週間前に自身が報告したAnthropicの事例（Claude Desktop起動時に他のChromiumベースブラウザへNative Messaging bridgeを書き込む挙動）と同じパターンだと位置づけている。
なぜ「勝手に」書き込まれるのか
Hanff氏は、Windowsユーザーの既存報告だけでは「代表的でない構成での逸話」として片付けられかねないと考え、別プラットフォームでのクリーンな検証を行った。使ったのはmacOSのカーネルが保持するファイルシステムイベントログ .fseventsd だ。アプリのログとは独立してOSレベルでファイルの生成・変更・削除を記録するため、Chromeやリモートからは改変できないという。
氏は2026年4月23日に、自動監査（WebSentinelの100サイト・プライバシースイープ）用としてChromeのユーザーデータディレクトリを新規作成した。監査ドライバはChrome DevTools Protocolのみで動作し、ページを開いて5分間放置して閉じるだけ。人間のキーボード・マウス入力は一切なかったとされる。それでも4月29日までにプロファイルには4GBの重みが存在していた。.fseventsd を辿った結果、氏はバイト精度で時刻を特定したと述べている。
- 2026年4月24日 16:38:54 CEST — Chromeが監査プロファイル内に
OptGuideOnDeviceModelディレクトリを作成 - 16:47:22 CEST — 3つのunpacker子プロセスが起動。1つが
weights.bin等を展開し、残りはCRL（証明書失効リスト）更新とpreloadデータ更新を書き込み - 16:53:22 CEST — 展開された
weights.binが最終的な保存先OptGuideOnDeviceModel/2025.8.8.1141/weights.binへ移動
Hanff氏は、Chromeがセキュリティ更新・preload更新・4GBのAIモデルを同じアイドル時間帯にまとめて処理していた点を「あたかも等価であるかのように」バッチ化した、と指摘する。加えて氏は、これがePrivacy指令（2002/58/EC）第5条(3)、GDPR第5条(1)の適法性・公正性・透明性の原則、GDPR第25条のデータ保護バイデザインへの違反にあたり、さらに端末数次第で一度の配信あたり6,000〜60,000トンのCO2換算排出という環境負荷を伴うと、自身の専門的見解として述べている。これらはあくまで報告者の法的・環境的評価である点に留意したい。
読者がどう守るか
元記事に書かれている範囲で、削除を「定着」させる手段は限られる。macOSではファイルはユーザー所有のmode 600で消せるものの、Chromeがインストール状態を Local State に保持しており、variationsサーバーがそのプロファイルを対象と判定した時点で再ダウンロードが発火する、とされる。Windowsでも同様に消しても戻ってくる。
- Chromeの設定画面には該当のチェックボックスは無い——通常のGUIでは止められないと報告されている
- 削除を定着させる方法として挙げられているのは、
chrome://flagsでChromeのAI機能を無効化する、またはエンタープライズ向けのポリシーツール（一般の家庭ユーザーは通常持たない）を使う、あるいはChromeを完全にアンインストールする、の3つ - まずは
OptGuideOnDeviceModelディレクトリの有無と容量を確認し、自分の端末で実際に起きているかを把握するのが出発点になる
なお、chrome://flags のどのフラグを操作するか等の具体的な設定名は元記事に列挙されていないため、ここでは断定しない。
まとめ
- Chromeが同意なくGemini Nanoの約4GB重みファイル（
weights.bin）を端末へ書き込み、削除しても再DLされると研究者が報告した - 入力を一切与えていない自動化プロファイルでも配信が発火し、macOSカーネルのイベントログでバイト精度の時刻が裏取りされた
- 止める手段はAI機能の無効化・ポリシーツール・アンインストールに限られ、通常の設定画面では対処できないとされる
実装家視点で言うと、ここで一番効くのは「自動化プロファイルが人間の入力ゼロでも4GBを掴まされていた」という一点だ。CDPで回すクリーンプロファイルは本来、余計な状態を持たない前提で使う。そこにバックグラウンド配信が乗ってくると、CI環境やスクレイピング用の使い捨てプロファイルでディスクとネットワークが静かに食われる。自動監査を回している人は、Hanff氏がやったように容量チェック（du -sh 相当）を後処理に一行足しておくだけで、こうした「勝手に増える4GB」を早期に検知できる。原因究明はさておき、まず自分の端末に OptGuideOnDeviceModel が居るかを見るところから始めたい。
コメント