【ITニュース解説】Why I Stopped Letting Websites Download Gemini Nano Into Every Browser Profile
2026年10月02日に「Dev.to」が公開したITニュース「Why I Stopped Letting Websites Download Gemini Nano Into Every Browser Profile」について初心者にもわかりやすく解説しています。
ITニュース概要
ブラウザプロファイルがウェブページの要求でAIモデル(Gemini Nano等)を大量ダウンロードし、バックアップサイズが激増。特に複数プロファイル環境では通信費とディスク容量を浪費する。既存の対策は不十分で、ページにはダウンロード可能に見せつつ実際の転送は止める改修を行った。
ITニュース解説
ある日突然、ウェブブラウザのバックアップデータが異常に肥大化するという現象が発生した。通常56MB程度のバックアップファイルが、一夜にして2.74GBものサイズになっていたという。これは一体何が原因だったのだろうか。
詳しく調べてみると、その原因はGoogleが提供する「Gemini Nano」というAIモデルや、関連する多数のコンポーネントがブラウザのプロファイル内にダウンロードされていたことにあると判明した。ブラウザのプロファイルとは、私たちがウェブブラウザを使う際に、訪れたサイトの履歴、保存されたパスワード、お気に入りのサイト、ダウンロードファイルの情報、ウェブサイトが保存するクッキーやローカルストレージ、IndexedDBなどのデータが保存される場所のことだ。このプロファイルが大きくなると、バックアップにかかる時間や、別のパソコンで同じ環境を再現するために同期する際のダウンロード時間が大幅に増加してしまう。
具体的に肥大化の原因となっていたのは、以下のようなファイル群だった。最も大きいのは「Gemini Nano」というAIモデルで、約2.8GBもの容量を占めていた。これは、スマートデバイスなどで直接AI処理を行うための小型言語モデルだ。他にも、デバイス上での音声認識を行うための「SODA」関連ファイルが約244MB、画像内の文字を認識するOCR機能やアクセシビリティ関連の「screen_ai」が約122MB、オフラインで翻訳機能を提供する「TranslateKit」が約82MB、その他にも細かいAI関連コンポーネントが合計で約35MBを占めていた。これに対し、実際にユーザーが利用したウェブサイトのクッキーやローカルストレージなどのデータはわずか93MB程度しかなかった。つまり、増大したデータのほとんどがGoogleのAI関連コンポーネントによって占められていたわけだ。
この現象が引き起こす影響は非常に大きい。まず、バックアップの度に数ギガバイトものデータをアップロードすることになり、クラウドストレージの費用やネットワーク帯域を無駄に消費してしまう。また、別のパソコンで同じプロファイルを同期しようとすると、この巨大なデータをダウンロードし終えるまでブラウザが起動しないため、30分以上も待たされるといった事態も発生した。特に、複数の独立したブラウザプロファイルを大量に運用している場合(例えば、開発やテストで多数の仮想的なユーザー環境を再現するような場合)には、その影響は計り知れない。それぞれのプロファイルで個別に数ギガバイトのデータがダウンロードされ、プロキシサーバー経由の通信費も膨大になる可能性がある。
では、これらのAIモデルは一体どのようにしてダウンロードされたのだろうか。最初はChromeブラウザ自体がバックグラウンドで自動的にダウンロードしているのではないかと考えられたが、調査の結果、それは違った。実は、これらの大きなAIモデルは、ウェブページ側がJavaScriptコードを使って明示的にダウンロードを要求することで取得されていたのだ。例えば、特定のウェブサイトにアクセスし、わずかなクリック操作をした後、Translator.create()やLanguageModel.create()といったAPI(アプリケーションが他のソフトウェアと連携するためのインターフェース)が呼び出されると、ブラウザはそれらのAIモデルのダウンロードを開始する。
一般のChromeユーザーにとっては、これはむしろ便利な機能と言えるだろう。一度ダウンロードすれば、そのAIモデルはデバイス上で利用できるようになり、高速な翻訳や要約機能などを享受できる。しかし、前述のような大量の隔離されたプロファイルを運用し、それぞれのプロファイルが従量課金制のプロキシを経由してインターネットに接続しているような環境では、これは深刻な問題となる。ユーザーが意識しないうちに、たった一つのウェブページを開いただけで、各プロファイルにつき数ギガバイトものトラフィックとディスク容量が消費されてしまうのだ。
この問題に対して、いくつかの対策が検討されたが、いずれも完璧ではなかった。一つは、ブラウザを起動する際のコマンドラインオプションに--disable-component-updateというスイッチを追加する方法だ。これはコンポーネントの更新を停止させるためのオプションで、一見すると効果がありそうに思える。しかし、このオプションは望まないAIモデルのダウンロードを止めるどころか、実際にはウェブページからのAIモデルダウンロードはそのまま継続してしまう。さらに深刻なのは、このオプションを使うと、セキュリティ上非常に重要な他のコンポーネント(例えば、ウェブサイトの安全性を検証するための証明書失効リストや、悪意のあるウェブサイトから保護するためのサブソースフィルターなど)の更新も止めてしまうことだ。これはセキュリティホールを生み出すことにつながり、非常に危険な選択肢となる。
もう一つの対策として、「オンデバイスAIモデルの機能を無効にする」という方法も考えられた。これにより、ウェブページがAPIを呼び出した際に、AIモデルが利用できないと報告されるようになるため、ダウンロードは発生しない。しかし、この方法には「フィンガープリンティング」のリスクが伴う。フィンガープリンティングとは、ブラウザの設定や機能の差異を組み合わせて、特定のユーザーや環境を識別する技術のことだ。通常のChromeでは利用できるはずの機能が、こちらの環境では「利用できない」と報告されることで、ウェブサイト側から「このブラウザ環境は通常とは異なる」と特定されてしまう可能性がある。これは、プライバシー保護や匿名性を重視するブラウザ運用においては避けたい事態だ。
そこで、開発チームはより巧妙な解決策を考案した。その方針は、「ウェブページからは一切違いが分からないようにする」というものだ。つまり、ウェブサイトがAPIを呼び出した際に、AIモデルが「ダウンロード可能である」と報告されるのは以前と変わらない。しかし、実際にダウンロードが要求されたとしても、ブラウザの内部でGemini NanoやTranslateKit、SODA、screen AIといった主要なAIモデルのダウンロードだけを拒否するように変更したのだ。ウェブサイトがAIモデルの作成(create())を要求すると、その処理は「ダウンロードが開始されたが、まだ何も進行していない」という状態として振る舞う。つまり、ダウンロード完了を待つPromise(非同期処理の結果を表すオブジェクト)は保留状態のままとなり、進捗を示すイベントも発生しないが、エラーを返すわけでもない。これにより、ウェブサイトはダウンロードが進行中であると認識するものの、実際にはデータは一切ダウンロードされず、ディスクにも書き込まれない。
この方法であれば、ブラウザのセキュリティに関連する他の重要なコンポーネントの更新は正常に継続されるため、セキュリティリスクも発生しない。また、ウェブサイトからは通常のChromeと全く同じ応答が得られるため、フィンガープリンティングのリスクも排除できる。小型で容量の少ないAI関連コンポーネントについては、特に変更は加えず、通常のChromeと同じ挙動を維持している。これは、それらのコンポーネントを削除してもメリットが少なく、かえってブラウザの挙動に違いが生じてしまうためだ。
この修正が正しく機能しているかを確認するため、修正前のビルドと修正後のビルドを比較するテストが行われた。結果として、ウェブページがAPIから読み取れるすべての値(AIモデルがダウンロード可能かどうか、ダウンロードが進行中かどうかなど)は、修正前と後で完全に一致した。しかし、修正後のビルドでは、AIモデルのデータが実際にダウンロードされることはなく、ディスク使用量も増加しなかった。一方で、セキュリティ更新を含む通常のコンポーネントの更新は、どちらのビルドでも問題なく行われていた。
もしあなたが複数のブラウザプロファイルを運用しているなら、この問題がすでにあなたの環境で発生しているかもしれない。確認すべき点がいくつかある。まず、ブラウザのユーザーデータディレクトリのサイズを定期的に確認することだ。異常に大きなファイルやフォルダが見つかる場合、同様の問題が発生している可能性が高い。次に、プロファイルのバックアップや同期を行うツールを使っている場合、データを選択する際に「ホワイトリスト方式」を採用することを強くお勧めする。ブラックリスト方式(特定のファイルやフォルダを除外する方式)では、Chromeが新しいAIモデル用フォルダなどを追加するたびにブラックリストを更新する必要があり、常に後手に回ってしまう。新しい大きなフォルダが追加された場合、それを除外できずにバックアップされてしまうリスクがあるためだ。最後に、安易に--disable-component-updateのようなコマンドラインスイッチに頼るべきではない。それは一時的な解決策に見えるかもしれないが、実際には望まないダウンロードを止められず、かつブラウザのセキュリティを危険にさらしてしまうからだ。
この出来事が私たちに教えてくれるのは、表面的な問題解決策では不十分だということだ。問題を根本的に解決するためには、ウェブサイトやユーザーからその解決策が「見えない」ように、ブラウザのより深い層で対策を講じる必要がある。システムエンジニアとして、目に見える現象だけでなく、その背後にある技術的な仕組みや影響範囲を深く理解し、包括的な解決策を考えることが重要だという教訓だ。