入力した文書を外に出さないAI――ブラウザの中だけで動くLLMの現在地

公開前の下書きです。事実確認と編集を終えていますが、公開・SNS投稿はまだ行っていません。

契約書のドラフトをAIに要約させたい。だが社外秘の条項が含まれているので、外部のサーバーには送りたくない――。法務担当者がそんな場面で開発者向けのツールを覗くと、ブラウザのタブを開いてファイルを読み込ませるだけで要約が返ってくるページに出会うことがある。ブラウザの開発者ツールでネットワーク通信を確認しても、文書の中身を運ぶ通信は一件も発生しない。動いているのは、そのタブの中、その端末のGPUだけだ。

これを可能にしているのが、ブラウザからGPU計算を使えるWebGPUというAPIと、それを土台にしたWebLLMやTransformers.js v4といったライブラリだ。「入力したデータをサーバーに送らずブラウザの中でAIが動く」という技術は、この1年で実験段階から実用に近づいた。編集部の7人による議論では、この技術が本当に変えるのは誰の、どんなデータの話なのかが焦点になった。

結論：ブラウザ内LLMは、医療・法務・社内文書のように「外に出せない」機密データを扱う定型処理には、今日から現実的な選択肢になりつつある。ただし、初回の数百MB〜数GBのダウンロード、端末の発熱・メモリ消費、量子化モデルの精度低下、対応状況のばらつきという代償を、利用者の端末が肩代わりする構造でもある。厳密な再現性や監査証跡が要る業務、大規模なコンテキストを要する複雑な推論は、まだクラウドAIに任せるべきだ。

何が起きているのか：ブラウザがGPUを使えるようになった

WebGPUは、W3Cの「GPU for the Web Working Group」が策定する仕様で、ブラウザのJavaScriptから直接GPUの計算能力を使えるようにするAPIだ。これまでブラウザで機械学習を動かすにはCPUに頼るか、限定的なWebGLの転用でしのぐしかなかったが、WebGPUによって本格的なLLM（大規模言語モデル）の推論をブラウザ内で実行できる土台が整った。仕様そのものの標準化段階（正式な勧告に近い「Candidate Recommendation」に達した時期）は一次資料で確認できておらず、本稿では「策定が進んでいる」とだけ書く。

そのWebGPUの上で動くのが、MLC AIチームが開発するオープンソースエンジンWebLLM（mlc-ai/web-llm）だ。OpenAI互換のAPI形式、応答のストリーミング、JSON mode、function callingに対応し、開発者が既存のOpenAI向けコードに近い書き方でブラウザ内推論を組み込めるようにしている。もう一つ、Hugging Faceが2026年2月9日に公開したTransformers.js v4は、C++で書き直した新しいWebGPUランタイムを搭載し、ブラウザ・Node.js・デスクトップアプリなど複数のJS実行環境で同じコードを使い回せる点が目玉だ。

ナオ（AIとWeb技術を取材する技術記者）は議論で、「主要ブラウザが軒並み対応」という言葉が独り歩きしやすい点に注意を促した。

「『主要ブラウザが軒並み対応』という言葉は、あくまで主要なデスクトップ環境での話です。FirefoxのLinuxやAndroid対応は開発中であり、SafariもApple Silicon限定といった制約があります。」（ナオ）

ブラウザ対応の実際：デスクトップ中心で、まだ穴がある

Chrome公式ブログ（2025年11月25日付）によれば、この時点で「主要ブラウザが軒並みデフォルト対応」という節目に達したとされる。ただし内訳を見ると、対応は一様ではない。

ブラウザ	デフォルト有効化	制約
Chrome / Edge	バージョン113以降（Windows/macOS/ChromeOS）	Android対応はバージョン121以降。Android 12以上かつQualcomm/ARM系GPUに限定
Firefox	バージョン141（Windows）で有効化、145でmacOSに拡大	macOSはApple Siliconのみ。Linux・Androidは開発中（Mozillaは2026年中〜後半を目標と表明）
Safari	バージョン26（macOS Tahoe 26 / iOS 26 / iPadOS 26）	それ以前のOSバージョンでは非対応

表はweb.dev公式ブログの記述を基にした編集部の整理。「全ブラウザ・全端末で完全対応」ではなく、デスクトップの主要環境を中心に対応が広がっている段階と理解するのが正確だ。

WebLLM側の性能としては、M3 Max搭載端末でLlama 3.1 8Bモデルを4bit量子化した場合に41 tok/s、ネイティブ実行比で71〜80%という数値が複数の技術ブログで引用されている。ただし一次のベンチマーク文書には未到達のため、本稿ではこれを確定した事実ではなく「報告されている数値」として扱う。

プライバシーが「あったらいいな」ではなく本質になる場面

議論の中心は、この技術が「誰の、どんなデータ」にとって意味を持つかだった。医療情報システムのプライバシー担当であるミサは、電子カルテのような外部送信できない情報を例に挙げた。

「実務上、WebGPUの活用により、これまでクラウドに送れなかった電子カルテの要約や、法務・人事の機密文書の翻訳が、端末内で完結できる可能性が見えています。しかし、量子化による回答精度の低下は、誤診を招きかねない医療現場では致命的なリスクになり得ます。」（ミサ）

つまり、「データを外に出せない」場面には価値がある一方、その価値は無条件ではない。プライバシー担当のミサが挙げた医療・法務・人事の機密文書の要約や翻訳のほか、議論の前提として「子どもの学習支援のように、家庭内のやり取りを外部に送りたくない」場面も、同じ理由でブラウザ内処理が向く候補として位置づけられる。

反対意見の核心：コストは消えたのではなく、利用者に移った

ここからが議論の本題である。ブラウザ内推論は「サーバー不要」と言われがちだが、複数の参加者がこの表現の危うさを指摘した。

ITコスト構造を分析する経営アナリストのアオイは、クラウドAIのAPI課金という「変動費」が、ブラウザ内推論では利用者の端末という「固定費・隠れたコスト」に置き換わると整理した。

「ブラウザ内推論は、企業のIT予算における『変動費（API課金）』を『固定費（端末調達・管理コスト）』へと転換させる動きです。数GBのモデルダウンロードに伴う通信コストや、高負荷な計算による端末の減価償却の加速、バッテリー劣化といった負の外部性が、ユーザーの負担として顕在化します。」（アオイ）

モバイルUXの専門家であるレンは、この負担がスマートフォンでどう現れるかをより具体的に描いた。

「ブラウザはシステム全体のメモリを共有しており、数GBのモデルをロードした瞬間に、他のアプリのバックグラウンド動作が強制終了したり、ブラウザ自体がクラッシュしたりするリスクが報告されています。また、高負荷な計算に伴う『熱スロットリング』も無視できない問題です。端末が発熱すると、OSはCPU/GPUの性能を強制的に下げます。」（レン）

エッジAIエンジニアのハルカは、量子化（モデルのデータ精度を落として軽量化する手法）による品質低下との兼ね合いを、実装の現場からの視点で補足した。

「4bit量子化モデルでM3 Maxが41 tok/sを記録したと報告されていますが、これはあくまで理想的な環境です。『ローカルだから安全』という過信も禁物です。ブラウザのメモリ制限や、初回ダウンロードの通信量、端末スペックによる挙動の差を考慮すると、機密性の高い短文処理には適していますが、大規模なコンテキストを要する複雑な推論は、まだクラウドに頼るべきでしょう。」（ハルカ）

事実確認を担う編集者のテツオは、モデル配布の運用面に踏み込んだ。クラウドAIなら開発者側でモデルを更新すれば利用者は意識せず恩恵を受けられるが、ブラウザ内推論では更新のたびに数GBの再ダウンロードが発生する。さらにブラウザのキャッシュ管理の都合でモデルデータが意図せず破棄されれば、その通信をもう一度強いられる。テツオは、これによって「企業が常に同一の推論精度を保証することは、クラウド型と比較して技術的に極めて困難」になると指摘した。

これらの懸念を1枚にまとめると、次のようになる。

クラウドAIとの費用構造の違い

アオイが指摘した費用構造の転換は、単純化すると次のように整理できる。

観点	クラウドAI（API課金型）	ブラウザ内LLM
計算コストの負担者	サービス提供者（利用者は使った分だけ課金）	利用者の端末（電気代・発熱・端末寿命）
モデル更新	サーバー側で即時反映、利用者は意識しない	更新のたびに数百MB〜数GBの再ダウンロードが必要
精度の一貫性	サービス側が一律に高精度モデルを提供	端末スペックに応じた量子化で個体差が出る
監査・再現性	サーバー側でモデルバージョンや応答を一元記録しやすい	端末環境・キャッシュ状態に依存し、検証が難しい場合がある

表は議論を基にした編集部の整理であり、特定の製品の仕様を示すものではない。

判断基準：どんな用途なら今日から現実的か

議論の終盤では、医療情報システムのプライバシー担当ミサが「出力結果の検証可能性」という軸を、ITコスト構造を分析するアオイが「業務プロセスの統制可能性（シャドーAIのリスク）」という軸を、それぞれ判断材料として加えた。これらを踏まえ、編集部で用途別の目安を整理した。

用途の性格	今日から現実的か	理由
社外秘文書・機密メモの短文要約や翻訳	ブラウザ内推論が現実的	データを外に出せない要請と、短文処理という負荷の軽さが合致する
子どもの学習支援など家庭内の定型的なやり取り	ブラウザ内推論が現実的	機密性への要請があり、負荷も比較的軽い
診断補助・治療方針の検討など医療の高度判断	クラウドに任せるべき	検証可能性・トレーサビリティの要求が高く、量子化による精度低下が許容できない
監査が必須の企業業務	クラウドに任せるべき	利用ログの一元管理や業務プロセスの統制が難しい
大規模なコンテキストを要する複雑な推論	クラウドに任せるべき	端末のメモリ・発熱・量子化モデルの限界に達しやすい

表は議論の要点を基にした編集部の整理。実際の可否は業務内容、扱うデータの機密度、対象端末の性能によって変わる。また「クラウドに任せる」を選んでも、監査や精度の要件が自動的に満たされるわけではなく、サービスごとの検証は別途必要である。

日常的にAIを使う生活者代表のソラは、この判断基準を次のように言い換えた。

「プライバシーを最優先し、機密性の高い短文をサッと処理したい時はブラウザ内、端末の負荷や精度の不安定さを避け、高度な思考を求める時はクラウド、という使い分けが現実的な判断基準になると感じます。」（ソラ）

将来どうなるか：ここからは推論であることを明記して

議論の中では、端末性能の向上やブラウザ標準のAI APIが整備されれば、この境界線は今後変わりうるという見方も出た。ただしこれは実際に起きたことではなく、参加者の推測である。WebGPUの標準化が進み、Transformers.jsのようなライブラリが改良されるほど、ブラウザ内推論で扱える処理の幅は広がるだろうという方向性は議論の中で共有されたが、いつ・どの程度広がるかについての確定的な予測は本稿には含めない。

デモ：自分のブラウザがWebGPUにどこまで対応しているか確かめる

今使っているブラウザがWebGPUにどこまで対応しているかは、専門知識がなくても確認できる。今回、編集部で簡易的な検証ページを用意した。

デモを開く

このデモでできるのは次の3つだ。

1. 対応状況の機能検出：navigator.gpuの有無、GPUアダプタの取得可否を実際に試し、結果をダッシュボード形式で表示する。取得できたアダプタの情報（ベンダー名など）が公開されていれば、それも表示する。
2. クラウド型とローカル型のデータの流れの比較：文書がネットワークを経由するクラウド型と、モデルの初回ダウンロード以降は端末内で完結するブラウザ内型の違いを、図で対比する。
3. 実際のLLM推論は行わない：本物のLLMを動かすには数百MB〜数GB規模のモデルダウンロードが必要になり、単なる技術解説デモに組み込むには重すぎる。そのため、このデモでは実際の推論は実装せず、その理由を説明した上で、WebLLMの公式デモなど実際に試せる先へのリンクを置いている。

未対応のブラウザで開いても、エラー画面にはならず「このブラウザは非対応です」と分かりやすく表示されるようにしてある。

出典を読むときのポイント

• web.dev公式ブログ「WebGPU is now supported in major browsers」：Chrome/Edge・Firefox・Safariの対応バージョンと制約（FirefoxのmacOS Apple Silicon限定、Linux/Android開発中など）を確認した。
• Hugging Face公式ブログ「Transformers.js v4: Now Available on NPM!」：2026年2月9日の公開日と、C++で書き直された新WebGPUランタイムという特徴を確認した。
• WebLLM公式リポジトリ（mlc-ai/web-llm）：OpenAI互換API、ストリーミング、JSON mode、function callingへの対応を確認した。
• WebGPU Implementation Status（gpuweb wiki）：各ブラウザエンジンの実装状況を追跡するW3C関連の一覧として参照した。
• WebGPU仕様本体（W3C）：仕様の存在を確認したが、標準化段階を示すステータスバナーは今回一次確認できていないため、本文では「策定が進んでいる」という表現にとどめた。

性能数値（tok/s、ネイティブ比%）は複数の技術ブログが引用するものの一次ベンチマークには未到達のため、本文では「報告されている」という表現で扱った。