ChromeとGemini Nanoをめぐる議論では、「4GB」という数字が目を引きます。しかしプライバシーの観点で本当に重要なのは、ファイルサイズそのものではありません。ブラウザーに新しいAI層が入るなら、何が入るのか、何に使われるのか、どのデータに触れるのか、そして利用者や管理者が止められるのか――そこが焦点です。

まず「公式に確認できること」と「報告されていること」を分ける

公式に確認できるのは、ChromeがBuilt-in AI、つまりブラウザー内蔵AIの基盤として整備されていることです。Googleは、WebサイトやWebアプリがブラウザー管理のAIモデルとAPIを使ってAIタスクを実行できると説明しており、その文脈でGemini Nanoを明記しています ^[17][18]。ChromeのBuilt-in AI文書は、アプリの起動を速めるためにモデルを端末上にキャッシュすることにも触れています ^[18]。またGoogle Developers Blogは、LiteRT-LMがChromeなどの製品でオンデバイスGemini Nanoを可能にしていると説明しています ^[20]。

一方で、今回の騒動の中心にある具体的な主張――Chromeが約4GBのモデルファイル weights.bin を OptGuideOnDeviceModel フォルダーに置いた、明確な通知がなかった、手動削除後に再ダウンロードされた――は、複数の第三者メディアやブログが報じているものです ^{[2][3][7][10][14]}。公式のChrome開発者向け文書は、Built-in AIと端末上のキャッシュを説明していますが、ここで問題になっている正確な容量、ファイル名、削除後の再取得までは明確に確認できません ^[17][18]。

つまり、この件は「完全に立証済みのプライバシースキャンダル」と断定するにも、「単なる普通のアップデート」と片づけるにも早い段階です。見るべきは、ChromeのローカルAIに対して利用者と管理者がどこまで実効的なコントロールを持てるかです。

4GBより重いのは、説明責任の不足

大きなローカルAIモデルが端末にあること自体は、直ちにプライバシー侵害を意味しません。むしろ処理が本当に端末内で完結するなら、クラウドに文章やページ内容を送らずに済む可能性があります。

ただし問題は、利用者が理解できる形で告知されないまま、新しいAIコンポーネントが入り、いつ、どの機能で、どのデータを扱うのか分からない場合です。Chrome Built-in AIは単なる内部最適化ではありません。Googleは、Webアプリがブラウザー管理のモデルとAPIを使ってAIタスクを実行できる仕組みとして説明しています ^[17][18]。Google I/Oの資料では、翻訳、要約、文章作成、書き換えといった用途も示されています ^[28]。

だからこそ、必要なのは「ディスクを4GB使います」という説明だけではありません。ブラウザー内でAIが動くなら、利用者が納得して選べる設計が必要です。

Gemini NanoはChromeで何に使われるのか

プライバシー上の評価は、用途によって大きく変わります。ローカルAIは、文章作成支援、翻訳、要約、書き換え、あるいはセキュリティ機能に使われる可能性があります。GoogleのChrome Built-in AI関連文書やGoogle I/O資料は、翻訳、要約、文章作成、書き換えなどのタスクを説明しています ^[17][18][28]。

さらにInfosecurity Magazineは、GoogleがChrome 137で、Safe BrowsingのEnhanced Protectionモードにおけるスパム、詐欺、フィッシング対策の追加レイヤーとしてGemini Nanoを試していると報じています ^[25]。

こうした用途は、利用者にとって役立つ場面があります。ただし、便利機能、セキュリティ機能、開発者向けAPIを一括で扱うのではなく、分けて設定できることが重要です。文章作成支援は使いたいが、WebアプリからのAI API利用は制限したい。あるいはセキュリティ機能だけ許可したい。そうした粒度のある選択肢がなければ、ブラウザー更新が静かな機能拡張に見えてしまいます。

オンデバイスAIは「自動的に安全」ではない

GoogleのGemini Nanoに関するオンデバイスAI文書は、ネットワーク接続やクラウドへのデータ送信なしに生成AI体験を提供できると説明しています ^[19]。これはローカルAIの大きな利点です。入力や処理対象が本当に端末内に残るなら、クラウドに送られるデータを減らせます。

しかし、「オンデバイス」と「透明」は同じ意味ではありません。少なくとも、次の点は明確である必要があります。

• どのページ内容、フォーム入力、選択テキストがローカルモデルに渡されるのか
• どのChrome機能やWebアプリがモデルを呼び出せるのか
• プロンプト、出力、エラー、利用状況、テレメトリーが保存または送信されるのか
• モデル更新はどのように配布されるのか
• 削除または無効化したモデルが、後から自動的に戻るのか

Chromeの文書は、WebアプリがBuilt-in AI APIを通じてブラウザー管理のモデルを使えることを示しています ^[17][18]。だから問題はモデルファイルそのものだけではありません。周囲にある権限、アクセス制御、表示、ログの仕組みまで含めて見なければなりません。

ブラウザーが扱う情報は、思った以上に敏感だ

ブラウザーは、日常的にかなり敏感な情報に触れます。フォーム入力、社内文書、メール、チャット、問い合わせ対応、顧客情報などです。AI機能が翻訳、要約、文章作成、書き換えを行うなら、そうした内容に接触する可能性があります ^[28]。

処理が本当にローカルに閉じるなら、自動的にクラウドへ送る仕組みよりはプライバシーに配慮しやすいと言えます ^[19]。それでも、AIがいつ動いているのか、どの情報が対象なのか、利用者に見えることが欠かせません。

理想的には、Chromeの機能やWebサイトがローカルモデルを使うときに、分かりやすい表示があるべきです。また、その処理が完全に端末内で完結するのか、それともGoogleや他のサービスへの通信を伴うのかも説明される必要があります。公式のChrome AI関連ページはBuilt-in AI APIの存在を説明していますが、こうした具体的な制御やテレメトリーの疑問すべてに答えているわけではありません ^[17][18]。

削除できるか、止められるかが実用上の試金石

最も強い懸念は、モデルがダウンロードされたかどうかだけではありません。その後に利用者がどう扱えるかです。複数の報告は、ファイルを手動削除しても再びダウンロードされる、通常のChrome設定には分かりやすいオプトアウトがない、と主張しています ^{[3][7][10][14]}。

これが事実なら、利用者の自律性に関わる問題です。削除が実質的な削除にならず、「使わない」という意思表示も明確に尊重されないからです。

個人利用者にとっては、ストレージ、通信量、そして信頼の問題です。企業や組織にとっては、それに加えてソフトウェア棚卸し、導入承認、ブラウザーポリシー、規制環境でのAI部品の扱いが問題になります。この件をベンダーリスクやコンプライアンスの観点から論じる報告もあります ^[1][12]。

GDPRとePrivacy：リスクはあるが、違反断定には情報が足りない

現時点で利用できる情報だけでは、法令違反を断定することはできません。実際の配布方法、利用者への通知、設定画面、機能の有効化条件、データの流れが十分に確認できないためです。

ただし、一部のプライバシー関連記事は、EUのGDPR（一般データ保護規則）における透明性やデータ保護設計の原則、さらに端末への保存やアクセスを扱うePrivacyルールとの関係を指摘しています ^[12][13]。

ここでも区別が必要です。モデルファイルが大きいから問題なのではありません。利用者の内容を処理し得るコンポーネントが、十分な説明なしに導入される場合、あるいはテレメトリー、起動情報、利用データの扱いが十分に説明されない場合に、プライバシー上の緊張が高まります。

プライバシーに配慮したChrome内蔵AIに必要な条件

ブラウザーにローカルAIを組み込むなら、最低限、次のような設計が求められます。

• 大きなAIコンポーネントを入れる前に、分かりやすい更新通知を出す
• モデルの有効化、無効化、削除を通常の設定画面から操作できるようにする
• 削除したモデルが再ダウンロードされる条件を明示する
• 便利機能、セキュリティ機能、開発者向けAPIを別々にオン・オフできるようにする
• ローカル処理、クラウド呼び出し、テレメトリーの有無を文書化する
• 企業、教育機関、行政機関向けに管理ポリシーを用意する
• WebサイトやChrome機能がローカルモデルを使うとき、利用者に分かる表示を出す

これらは単なる法務上の形式ではありません。オンデバイスAIが「プライバシーを守る技術」と受け止められるのか、それとも「よく分からない新しいブラウザー層」と見られるのかを分ける条件です。

結論

Chrome Built-in AIとGemini Nanoの組み合わせは、Googleの公式文書で確認できます ^[17][18]。一方で、weights.bin という約4GBのファイルが静かに置かれ、削除後に再ダウンロードされるという具体的な主張は複数の報告にありますが、公式のChrome開発者向け文書では明確に確認できません ^{[2][3][7][10][14][17][18]}。

冷静に見るなら、問題の核心はローカルAIの存在そのものではありません。オンデバイスAIは、内容が本当に端末内に残るならプライバシーを改善し得ます ^[19]。決定的なのは、ChromeがどのAIコンポーネントを入れ、何に使い、どのデータフローを生み、利用者や管理者がどのように確実に止められるのかを、十分に透明に示すかどうかです。