Chrome設定から消えた「データを送らない」の一文

Chrome設定から消えた「データを送らない」の一文

ChromeのオンデバイスAI設定にあった「Googleサーバーにデータを送ることなく」という保証文が静かに消えた。4GBモデル無断ダウンロード騒動と重なる削除に、ユーザーは身構えている。Googleは「処理は端末上」と説明するが、ならばなぜ消したのか。


消えた一文が持っていた重み

なぜこの一文の削除が問題視されているのか。Chromeのシステム設定にある「オンデバイスAI」のトグルは、以前こう説明されていた。

詐欺検出などの機能を動かすために、ChromeはGoogleサーバーにデータを送ることなく、お使いのデバイス上で直接動作するAIモデルを使用できます。これをオフにすると、これらの機能は動作しない場合があります。

問題の核心は強調した部分だ。「Googleサーバーにデータを送ることなく(without sending your data to Google servers)」。これがマーケティング用のキャッチコピーではなく、設定画面という公的な表示面に置かれたプライバシー上の表明であることが重要になる。

EUや英国をはじめとする多くの法域では、ベンダーが公開した処理内容の記述を、ユーザーは判断材料として信頼してよいことになっている。「データは外に出ない」と保証されているからデフォルト設定を変えなかった、というユーザーがいたなら、ベンダーはその保証に縛られる。

そして現在のChromeでは、この一文が消えている。

削除を最初に指摘したのは誰か

きっかけはReddit r/chromeへの投稿だった。RaufLegendというユーザーが旧バージョンと新バージョンのスクリーンショットを並べて変更を指摘し、これを長年プライバシー保護を専門としてきたアレクサンダー・ハンフ(Alexander Hanff)が拾った。

ハンフは「That Privacy Guy」のブログで、削除には3つのシナリオしかありえないと書いた。第一に、元の記述が不正確だった可能性。データはGoogleサーバーに送られていた、あるいは未開示の条件下で送信され得る状態だったという読みだ。第二に、アーキテクチャが変わる予定で、もはや旧テキストでは正確でなくなるという可能性。第三に、法的なヘッジ。Googleの法務がこれを「規制当局や民事訴訟で守りきれない表明」と判断し、削除を勧めたという読みだ。

どれが当たりであっても、ユーザーにとっては良くない結果だ、というのがハンフの整理である。1番なら過去にユーザーは虚偽の表示の下で処理されていたことになり、GDPR第6条に基づく違法な処理に該当しうる。2番なら最近の4GBモデル無断インストールが「プライバシー保証」を口実に正当化されていたことになり、性質はさらに悪い。3番ならGoogle自身がその保証の妥当性に確信を持てなかったという告白に等しい。

削除の理由として考えられる3つのシナリオ
シナリオ 内容 法的含意 ユーザーへの帰結
1
不正確
元の記述が事実と
違っていた可能性
GDPR第6条に基づく
違法処理に該当しうる
過去の処理が
虚偽表示の上で行われた
2
仕様変更
アーキテクチャが変わり
旧記述では正確でなくなる
4GBモデル無断配信が
偽の保証で正当化された形
プライバシー保証を
口実にした事前配置
3
法的回避
法務が「守りきれない
表明」と判断し削除を勧告
記述の妥当性を
Google自身が確信できず
保証もなく
検証手段も与えられない
※ アレクサンダー・ハンフ氏のブログ「That Privacy Guy」(2026年5月8日公開)に基づく。氏はEUの不公正商取引慣行指令、米国FTC法第5条、デジタル市場法(DMA)第13条第4項のいずれにも抵触する可能性を指摘している。

Googleの説明と英メディアの追加取材

The Registerはこの件でGoogleに直接問い合わせ、広報担当者から次の回答を得ている。

これはChromeでのオンデバイスAIの取り扱い方の変更を反映したものではない。モデルに渡されるデータは、デバイス上でのみ処理される。

ここで言葉を選ぶ必要がある。「変更を反映したものではない」という言い回しは、アーキテクチャは変わっていないという主張だ。一方で、なぜ文言を消したのかという根本的な疑問にはまだ答えていない。

The Registerは状況から逆算した分析を提示している。これは「悪意で説明できることでも、まず下手な間合いを疑え」というハンロンの剃刀の応用にあたる。要するに、文言変更とPrompt APIの展開タイミングが偶然重なったため、外野からは陰謀のように見えてしまっただけ、という見立てだ。

Prompt APIが変えたデータの流れ

Chrome 148の安定版が2026年5月5日にリリースされ、開発者向けの新機能としてPrompt APIが導入された。これは、ウェブサイト側のJavaScriptから直接、ブラウザに常駐しているGemini Nanoに問い合わせができる仕組みだ。

ここで起きることを整理しておきたい。ユーザーがあるウェブサイトを開き、そのサイトのスクリプトがPrompt API経由でNanoを呼び出す。Nanoはユーザーのデバイス上でプロンプトを処理し、結果を返す。プロンプトと応答はGoogleのサーバーには送信されない――ここまでは旧来の保証どおりだ。

問題は、そのやりとりにサイト側がアクセスできるということだ。当該サイトがGoogleの運営するサイト(たとえば検索やGmail)だった場合、ユーザーがNanoと交わした内容は、サイト側のサーバーログに乗りうる。これは「Googleサーバーにデータが行かない」という旧保証の文言と、解釈次第では衝突する。

「Googleサーバーにデータを送ることなく」というのは、クラウド上のGeminiにクエリを送るのではない、という意味では正しい。だが、Googleのサイトが自分のサーバーから自分のサイト経由でNanoのAPIを叩いた場合、その結果はGoogleのサイトのサーバーが受け取る。これを「Googleサーバーへのデータ送信ではない」と言い切れるかは、法務の好みの問題になる。

つまりGoogleの広報が言う「これはアーキテクチャの変更を反映したものではない」と、ハンフが疑う「3番(法的ヘッジ)」は、矛盾なく両立しうる。技術的にはNanoの動作は変わっていないが、Prompt APIの開放によって従来の文言が法的に守りにくくなった、という説明である。

Chrome オンデバイスAI 関連の主要な出来事
2024年
5月
Chrome 126で
オンデバイスAI導入
Gemini Nanoがプレビュー機能として組み込まれ、対応端末への配信が開始される。
2026年
2月
設定UIに
無効化オプション追加
Chrome設定画面からモデルの無効化と削除が可能になる。「データを送信しない」の保証文が同時に存在。
2026年
4月初旬
設定UIから
保証文が削除される
「Googleサーバーにデータを送ることなく」の一文が、ユーザーへの告知なくChromiumのコミットで除去される。
2026年
5月5日
Chrome 148
安定版リリース
Prompt APIが正式展開され、ウェブサイトから直接Gemini Nanoを呼び出せるようになる。
2026年
5月初旬
4GBモデル
無断配信が表面化
プライバシー専門家アレクサンダー・ハンフ氏が、約4GBのGemini Nanoモデルが同意なくダウンロードされていると指摘。
2026年
5月8日
設定UI削除が
第三者により発覚
Reddit投稿をきっかけにハンフ氏が分析を公開。同時期にGoogleはThe Registerの取材に「アーキテクチャに変更はない」と回答。
※ The Register「Google tweaks Chrome AI privacy wording, insists processing stays on-device」(2026年5月9日)、およびChromium Code Review、Chrome for Developers リリースノートから整理。

それでもなお残る疑問

仮にGoogleの説明が額面どおり正しいとしても、設定UIの透明性という観点では問題が残る。

第一に、変更の経緯がユーザーに何ら告知されていない。プライバシー上の表明文を消すという作業は、追加するときと同じくらい、いやそれ以上に説明責任が伴う。第二に、ハンフが指摘するように、トグル自体がシステム設定ブロックの中から専用セクションへと視覚的に切り離された形で移動している。これは「設定の整理」と説明することもできるが、結果として周囲のデバイス制御群と分離され、変更に気づきにくくなった。

第三に、4GBのGemini Nanoモデルが事前同意なしに自動ダウンロードされていた件と、文言削除のタイミングが完全に重なった。一方は「同意を取らずに容量を消費」、もう一方は「保証文を消去」。どちらも単独なら誤解で済む話かもしれないが、合わせると不信を招く順序になっている。


ユーザーが今できること

オンデバイスAIを使いたくない場合、Chromeのアドレスバーからchrome://flagsを開き、optimization-guide-on-device-modelの項目を「Disabled」に変更してChromeを再起動すればよい。weights.binファイルは削除される。Windowsの企業環境であれば、グループポリシーGenAILocalFoundationalModelSettingsを1に設定する方法もある。

設定UIの説明文がどう変わろうと、自分の端末上で何が起きているかを確認する手段は残っている。ベンダーの保証文は信頼の表明だが、そこに依存する代わりに、自分で蓋を開けて中を見る選択肢を取り戻すこと――それが、今回の一連の出来事から個人ができる唯一の対抗策かもしれない。

設定画面の文言は、ベンダーからの表明だった。それを消した行為が何を意味するのかは、ユーザー一人ひとりが読み解くことになる。


参照元

他参照

関連記事

この記事を共有する