プライバシー on KnightLiブログ

Chrome が 4GB の Gemini Nano を静かにダウンロード：確認、無効化、削除の方法

Sat, 09 May 2026 21:37:18 +0800

Google Chrome が、ユーザーの明示的な許可なしに約 4GB のローカル AI モデルファイルをバックグラウンドでダウンロードしていると報じられ、プライバシー、ストレージ使用量、環境負荷をめぐる議論が起きています。

このファイル群は Gemini Nano に関連しており、主に Chrome のローカル AI 機能で使われます。論点は、ブラウザがローカル AI をサポートすること自体ではなく、ダウンロードの過程が十分に透明か、ユーザーが事前に知るべきか、そしてシステムリソースの使い方が妥当かどうかです。

何が起きたのか

問題になっているモデルファイルは weights.bin という名前で、Chrome の OptGuideOnDeviceModel ディレクトリにあります。Gemini Nano のローカル版とみられ、デバイス上で一部の AI 推論を行うために使われます。

Chrome はデバイスのハードウェア性能に応じて、バックグラウンドでダウンロードするかどうかを判断します。特に RAM や VRAM などの条件が参照されます。ユーザーが自分でダウンロードを開始する必要はなく、事前に明確な通知が表示されない場合もあります。

さらに厄介なのは、モデルファイルを手動で削除しても、完全には再ダウンロードを止められないことです。関連機能が有効なままだと、Chrome の再起動後や更新後に再びダウンロードされる可能性があります。

現在の議論で名前が挙がっている対象プラットフォームは、Windows 11、macOS、Ubuntu などのデスクトップ OS です。Chrome のデスクトップ版の利用規模を考えると、潜在的に影響を受けるデバイスは数億台に達する可能性があります。

Google の説明

Google は、これらのファイルは「Help me write」や詐欺検出などのローカル AI 機能を支えるためのものだと説明しています。モデルをローカルで実行することで、一部のデータ送信を減らし、プライバシー保護を改善できるという主張です。

また Google によると、デバイスの空き容量が不足した場合、Chrome は関連モデルを自動的に削除して容量を確保します。つまり、モデルが必ず永続的にディスクを占有するわけではありません。

同時に Google は、2024 年 2 月以降、ユーザーは Chrome の設定から関連機能を無効化できるとしています。無効化後は、モデルのダウンロードや更新は続かないとのことです。

確認と無効化の方法

Chrome に Gemini Nano モデルをローカルに保持してほしくない場合は、次の場所を確認できます。

まず Chrome の設定を開き、「オンデバイス AI」、ローカル AI、文章作成支援、最適化の提案に関連する項目を探し、不要な機能をオフにします。

次に、アドレスバーに次を入力します。

`1`	`chrome://flags`

その後、次の項目を検索して無効化します。

`1`	`Enables optimization guide on device`

最後に、Chrome のユーザーデータディレクトリで OptGuideOnDeviceModel フォルダを探し、その中のモデルファイルを削除します。ただし、ファイルを削除するだけでは通常不十分です。先に関連する flag や設定を無効化しておかないと、Chrome が後で再びダウンロードする可能性があります。

OS ごとの主な保存場所

OptGuideOnDeviceModel は通常、Chrome のユーザーデータディレクトリ配下にあります。OS やインストール方法によって異なりますが、まずは次の場所を確認するとよいでしょう。

Windows: %LOCALAPPDATA%\Google\Chrome\User Data\
macOS: ~/Library/Application Support/Google/Chrome/
Linux: ~/.config/google-chrome/
Chromium: ~/.config/chromium/

該当するディレクトリに入ったら、OptGuideOnDeviceModel または weights.bin を検索します。Chrome Beta、Dev、Canary を使っている場合は、ディレクトリ名に対応するチャンネル名が含まれることがあります。

weights.bin がダウンロード済みか確認する方法

もっとも直接的な方法は、Chrome のユーザーデータディレクトリで次を検索することです。

`1`	`weights.bin`

ダウンロード済みであれば、通常は OptGuideOnDeviceModel の中にあり、ファイルサイズは数 GB 近くになる可能性があります。更新日時を見れば、Chrome が最近バックグラウンドで作成または更新したものかどうかも判断できます。

weights.bin が見つからない場合でも、そのデバイスが今後まったくダウンロードしないとは限りません。Chrome はハードウェア条件、地域、バージョン、機能フラグ、実験設定に基づいて、モデルを取得するかどうかを決める場合があります。

無効化すると影響を受ける可能性がある Chrome AI 機能

関連するローカル AI 機能や最適化機能を無効化すると、Gemini Nano に依存するオンデバイス機能に影響が出る可能性があります。たとえば「Help me write」、ローカルの詐欺検出、今後追加されるクラウドを経由しないブラウザ AI 機能などです。

これらの機能を使っていないユーザーであれば、日常的なブラウジングへの影響は通常大きくありません。一方で、Chrome 組み込みの文章作成支援、ページ理解、安全検出の実験機能をよく使うユーザーは、クラウド処理へ戻る、機能が使えなくなる、または別の代替方式が使われる可能性があります。

どこが争点なのか

この件の中心的な争点は、ブラウザがユーザーの明確な同意なしに、AI 機能のために数 GB のモデルファイルを事前にダウンロードしてよいのかという点です。

支持する側は、ローカル AI によってクラウド処理を減らし、プライバシー保護や応答速度の向上につながると考えます。反対する側は、特にファイルサイズが 4GB 近くあり、ストレージや通信量に影響し得る場合、少なくとも事前に明確な通知が必要だと主張します。

プライバシー専門家は、このような十分な告知を伴わないバックグラウンドダウンロードが、EU の ePrivacy 指令や GDPR 上の論点になり得るとも指摘しています。違反に当たるかどうかは、Google の告知方法、デフォルト設定、データ処理の経路、ユーザー制御の仕組みによって変わります。

まとめ

Chrome に Gemini Nano が入ることは、ブラウザがより多くの AI 機能をローカル実行へ移していることを示しています。一方で、ローカルモデルもディスク容量と帯域を消費し、ユーザーが自分のデバイスをどれだけ制御できているかという感覚に影響します。

一般ユーザーにとって最も直接的な対処は、Chrome のローカル AI と最適化機能の設定を確認することです。不要であれば関連オプションをオフにし、その後 OptGuideOnDeviceModel ディレクトリ内のモデルファイルを削除します。

Canonical の Ubuntu AI ロードマップ：ローカル推論を優先し、強制統合はしない

Fri, 08 May 2026 22:23:46 +0800

Canonical が最近示した Ubuntu の AI ロードマップで重要なのは、「Ubuntu が AI を無理にシステムへ押し込む」という話ではない。むしろ、AI 機能を段階的に提供し、既定では無効にし、ユーザーが明示的に選んだときだけ有効化し、推論はできるだけローカルで行うという慎重な方針だ。

これは、Windows や macOS のシステムレベル AI をめぐる議論とは対照的だ。Ubuntu が目指しているのは、避けられない全体 AI レイヤーでも、OS 全体を一括で止める「AI 総スイッチ」でもない。AI 機能を比較的独立したツールとして分け、インストールするか、使うか、どのモデルにつなぐか、データを外へ出すかをユーザーが決められるようにする方向である。

まず時期を確認する：Ubuntu 26.04 LTS ではない

今回のロードマップが主に向いているのは Ubuntu 26.10 “Questing Quokka” で、2026 年 10 月 9 日にリリース予定とされている。Canonical の計画は、一部の AI ツールを実験的な preview として導入することであり、Ubuntu 26.04 LTS に既定機能として入れることではない。

ここは重要だ。LTS は長期安定、企業導入、セキュリティ保守を担うリリースであり、探索段階のデスクトップ AI 機能を既定体験として入れる可能性は高くない。まず 26.10 のような通常リリースで試し、開発者や早期ユーザーの反応を見て、どの機能を後続の長期サポート版に入れるか判断するのが自然だ。

ローカル推論を優先し、クラウドは既定にしない

Canonical が強調している原則の一つは local inference first、つまり既定ではユーザーのマシン上で推論することだ。クラウドプロバイダー、自前サーバー、企業向けモデルサービスをユーザーが明示的に設定した場合だけ、リクエストが外へ出る。

理由は現実的だ。システムレベルの AI は、コマンド出力、ログ、ファイルパス、エラー、システム設定などの機密性が高い情報に触れやすい。たとえ「エラーを説明する」ためであっても、こうした情報を自動でクラウドへ送るのは、プライバシーとコンプライアンス上のリスクになる。

したがって Ubuntu の AI 路線は、クラウド AI の入口を OS に作るというより、差し替え可能な推論レイヤーに近い。ユーザーはローカルモデル、社内推論サービス、必要に応じて Canonical 管理のサービスを選べる。重要なのは、特定のモデルベンダーに固定しないことだ。

AI CLI：まずは端末支援から

最初に現実的に入ってきそうな機能の一つが、端末ユーザー向けの AI Command Line Helper、いわゆる ai-cli だ。

これは shell を置き換えるものでも、危険なコマンドを自動実行するものでもない。目的は、コマンド、ログ、systemd unit、エラー出力、システム状態を理解する手助けである。複雑なサービス起動失敗ログの原因を説明したり、コマンドオプションの意味をわかりやすく示したりする用途が想定される。

この入口は Ubuntu のユーザー層に合っている。Ubuntu のデスクトップユーザーやサーバーユーザーには、もともと端末で作業する人が多い。派手なチャット画面から始めるより、エラー調査、コマンド解説、運用支援といった高頻度の場面に AI を置くほうが実用的だ。

ただし、安全境界は明確でなければならない。ログには token、社内アドレス、ユーザー名、パス、鍵の断片、業務情報が含まれることがある。既定がローカル推論でも、ツールは秘匿情報の削除を促すべきだ。ユーザーがクラウドバックエンドを選ぶなら、何が送信されるかを明示する必要がある。

Settings Agent：自然言語でシステム設定を扱う

もう一つの方向が Settings Agent で、自然言語でシステム設定を問い合わせたり変更したりする機能である。

一見簡単そうだが、実装は難しい。成熟した Settings Agent は、画面を読み取り、ボタンを推測し、クリックを模倣するような方法で設定を操作すべきではない。読み取れる設定、変更できる設定、変更前に確認が必要な操作、失敗時のロールバックなどを、制御された内部 API で扱う必要がある。

そのため、これは 26.10 で完成して提供される機能というより、その後も継続して進む方向と見るべきだ。うまく作れば、一般ユーザーがデスクトップ Linux を設定するハードルを大きく下げられる。攻めすぎると、新しいセキュリティリスクにもなる。

なぜ「AI 総スイッチ」が最優先ではないのか

OS ベンダーが AI を入れると、「どこにでも AI があり、完全に止めにくい」体験になるのではないかと不安に思うユーザーは多い。そこで、Ubuntu に全体の AI kill switch が必要なのでは、という疑問が出てくる。

Canonical の考え方は、AI 機能がそもそも opt-in で、層ごとに分かれ、個別にインストールと設定ができるなら、全体スイッチは最優先ではないというものだ。つまり、「既定で有効、深く統合、あとからユーザーが無効化する」という構造を設計段階で避けようとしている。

それで十分かどうかは実装次第だ。AI ツールが既定で有効にならず、既定でネットワークに接続せず、既定でデータを収集せず、各機能に明確な設定入口があるなら、ユーザーは AI を止めるために隠れた項目を探し回る必要はない。

開発者と企業ユーザーへの意味

開発者にとって、AI CLI のようなツールの実用的な価値は、ドキュメント調査、ログ読解、システム問題の切り分け時間を減らすことだ。これはエンジニアの判断を置き換えるものではなく、「この出力をまず説明する」作業を自動化するものに近い。

企業ユーザーにとっては、ローカル推論と差し替え可能なバックエンドのほうが重要だ。多くの企業は、ソースコード、ログ、顧客データ、インフラ情報を公開モデルサービスへ送れない。Ubuntu がシステムレベル AI をローカルモデル、私有推論サービス、企業の権限体系と結び付けられれば、コンプライアンス環境でも制御可能な支援を提供できる。

これは Linux デスクトップとワークステーションにとっても機会だ。Windows や macOS は AI をベンダーエコシステムの一部にしやすい。一方 Ubuntu の強みは、オープンで、監査可能で、置き換え可能で、自前運用できることにある。Canonical がこの原則を保てるなら、AI はプロ向け Linux 体験を補強する可能性がある。

過度に読み取らない

現時点で、このロードマップを「Ubuntu が特定の小型モデルをプリインストールする」「Ubuntu 26.04 に AI 監査モードが入る」「固定の ubuntu-ai コマンドが用意される」と解釈するのは早い。公開情報でより確かなのは方向性であり、完成した製品形態ではない。

より安全な理解は、Canonical が Ubuntu にシステムレベル AI ツールの枠組みを入れようとしており、まずコマンドライン支援、設定支援、ローカル推論、バックエンド選択から始める、というものだ。既定の姿勢は、システムが選ぶのではなくユーザーが選ぶことである。

まとめ

Ubuntu の AI ロードマップで本当に注目すべきなのは、Ubuntu も「AI の波に乗る」ということではない。オープンソース OS における、より抑制された AI 統合の形を定義しようとしている点だ。知能はインフラになり得るが、プライバシー、制御性、ユーザーの選択権が先に来るべきだ。

26.10 の実験的機能がこの原則を守れるなら、Ubuntu は一般消費者向け OS とは異なる道を取れるかもしれない。避けられないシステム広告枠としての AI ではなく、選択可能で、置き換え可能で、監査可能な生産性ツールとしての AI である。

参考リンク：

Claude の本人確認：なぜ必要か、何を準備するか、データはどう扱われるか

Thu, 16 Apr 2026 09:20:00 +0800

Anthropic は Claude 上で本人確認を段階的に導入しています。公式説明によると、これは単に利用のハードルを上げるためではなく、プラットフォームの完全性、安全性、コンプライアンス、不正利用防止の一部です。

簡単に言うと、Claude の本人確認は主に 3 つの問題に対応します。

強力な AI ツールを使っている人が誰かを確認する。
利用ポリシーの執行を助け、不正利用リスクを下げる。
必要な法的・コンプライアンス上の義務を満たす。

Claude の一部機能にアクセスするときに本人確認の案内が表示された場合、通常はプラットフォームの安全性とコンプライアンス確認の一環と考えられます。Anthropic は、確認データは本人確認のためだけに使い、他の目的には使わないとも説明しています。

01 いつ本人確認が求められるか

公式ドキュメントは、すべての発動条件を完全な一覧として示しているわけではありません。本人確認は一部のユースケースに向けて展開中であり、特定機能へのアクセス時に表示される可能性がある、と説明しています。

つまり、確認画面が出たからといって必ずアカウントに問題があるわけではありません。よくあるのは次のようなケースです。

より高い信頼レベルが必要な機能を使っている。
プラットフォームが整合性チェックを行っている。
アカウントや利用状況が安全性・コンプライアンスのフローに入った。

ユーザー側で重要なのは、確認に何が必要かを事前に把握し、途中で止まらないようにすることです。

02 誰が確認を処理するか

Claude の本人確認は、Anthropic と第三者確認サービス Persona Identities が連携して行います。

Anthropic が Persona を選んだ理由として、公式文書では次が挙げられています。

技術力
プライバシー管理
セキュリティ保護

つまり、Anthropic は確認データの利用と保存ルールを定め、Persona は Anthropic の指示に従って具体的な確認フローを処理します。

03 何を準備するか

確認を始める前に、次の 3 つを準備しておくとよいです。

必要なもの	説明
有効な政府発行の顔写真付き身分証	物理的な原本が手元に必要
カメラ付きのスマートフォンまたは PC	ライブ自撮り、または Web カメラが必要になる場合がある
数分の時間	公式説明では通常 5 分未満

身分証が手元になかったり、カメラが使えなかったりすると、確認フローが中断される可能性があります。

04 受け付けられる身分証

Anthropic は、多くの国の原本・物理的・政府発行の顔写真付き身分証を受け付けます。一般的な例は次の通りです。

パスポート
運転免許証
州、省、地域の ID
国民 ID カード

身分証は次の条件を満たす必要があります。

政府発行である
本人写真が含まれている
はっきり読める
破損していない
コピーやスクリーンショットではない

05 受け付けられないもの

次のものは、Claude の本人確認には通常使えません。

コピー
スクリーンショット
スキャン画像
身分証写真をさらに撮影した画像
モバイル運転免許証などのデジタル身分証
学生証、社員証、図書館カード、銀行カードなどの非政府 ID
一時的な紙の身分証

ここは間違えやすいポイントです。「読めればよい」のではなく、原本・物理的・政府発行の身分証が必要です。

06 データはどう保護されるか

この部分は、公式文書の中でも特に重要です。

Anthropic の説明は次のように要約できます。

Anthropic は確認データのデータ管理者であり、利用と保存のルールを定めます。
Persona は処理者として、Anthropic の代理で確認を行います。
身分証と自撮り写真は Persona が収集・保存し、Anthropic のシステムには直接保存されません。
Anthropic は必要な場合、たとえば異議申し立ての審査時に、Persona のプラットフォームを通じて確認記録にアクセスできます。
Persona がデータを使える範囲は契約で制限されており、主に確認の提供・支援と不正防止能力の改善に限られます。
Persona に送信されるデータは、転送中も保存中も暗号化されます。

つまり、提出した身分証や自撮り写真は、通常のアカウント情報として自由に使われるのではなく、本人確認とコンプライアンスのフローに限定されます。

07 Anthropic がしないこと

公式文書では、Anthropic がしないことも明示されています。

本人確認データをモデル訓練に使わない。
本人確認に必要な範囲を超えて情報を収集しない。
身分データをマーケティング、広告、確認と無関係な目的に使わない。
有効な法的手続きへの対応が必要な場合を除き、無関係な第三者と確認データを共有しない。

これはユーザーにとって重要です。本人確認で敏感なのは、身分証の写真を撮ること自体だけでなく、その後データがどう使われるかです。この文書での Anthropic の立場は、確認データは本人確認、法的義務、安全性・コンプライアンスのために限定して使う、というものです。

08 確認に失敗した場合

確認失敗は必ずしもアカウント異常を意味しません。よくある原因は次の通りです。

写真がぼやけている
光量が足りない
身分証の情報が読み取れない
身分証が期限切れ
技術的な問題

公式は次の順序を勧めています。

再試行する。確認フローでは通常、複数回の試行が可能です。
より明るい環境で撮り直す。
身分証が鮮明で、完全で、期限切れでないことを確認する。
他の政府発行の顔写真付き身分証があれば、それを試す。
試行回数を使い切っても確認できない場合は、公式フォームからサポートに連絡する。

実際には、光の良い場所に移動し、カメラのピントを合わせ直すだけで解決することがよくあります。

09 確認後もアカウントが停止される理由

本人確認に通ったからといって、アカウントが絶対に制限されないわけではありません。Anthropic は、安全プロセス上の他の理由でアカウントが停止される可能性があると説明しています。

利用ポリシーへの反復違反
サポート対象外の場所からアカウントを作成した
利用規約違反
18 歳未満の利用

誤って停止されたと思う場合は、公式の異議申し立てフォームにアカウント情報を記入し、安全チームによる調査を依頼できます。

10 ユーザーが準備すべきこと

Claude を継続して使う予定があるなら、特に高い信頼レベルが必要な機能を使う場合、次を準備しておくとよいです。

有効で期限切れではない、物理的な政府発行の顔写真付き身分証を用意する。
カメラが使えることを確認する。スマートフォンと PC の両方で確認ページを開けると安心。
明るい環境で確認する。
スクリーンショット、スキャン画像、身分証写真の再撮影画像をアップロードしない。
確認に失敗したら、まず身分証の鮮明さと光量を確認し、それでもだめならサポートに連絡する。

多くのユーザーにとって、Claude の本人確認は複雑な手続きではありません。ただし、提出物の真正性には厳格です。正しい種類の身分証を使い、写真が鮮明であれば、通常は数分で完了します。