BrowserAI: WebGPUでブラウザ内にLLMを載せるTypeScript SDKの実力と境界
Run local LLMs like llama, deepseek-distill, kokoro and more inside your browser
ひと目でわかる
- これは何？
- BrowserAIはMLC、Transformers、Flare、Demucsの4エンジンを1つのAPIにまとめ、テキスト生成から音声認識、TTS、音源分離までブラウザ内で完結させる。サーバーレス推論の現実的な使いどころと、モデルサイズという越えにくい壁を整理する。
- 誰に向いている？
- 採用を検討すべきなのは、入力データをサーバーに送れない制約があり、かつ1Bから8Bクラスのモデルで要件を満たせるチームだ。逆に、70B級の推論やGPUのない端末を対象にするプロダクトには向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 57 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
サーバーに送れないデータをブラウザ内で推論する
BrowserAIが解こうとしているのは、推論そのものの高速化ではなく配置の問題である。READMEは「100% Private: All processing happens locally in your browser」と述べており、入力テキストや音声が外部のAPIに渡らない構成を前提にしている。対象としてREADMEが挙げるのは、Web開発者、プライバシーを重視する企業、ブラウザベースAIを試す研究者、インフラを持たずに試したい個人、ノーコード基盤の作者である。共通するのは、推論サーバーを立てる予算や運用体制を持たずに、それでもモデルを動かしたいという状況だ。クラウドAPIの代替というより、送信できないデータを扱うための選択肢と読むほうが正確である。
4つのエンジンを1つのgenerateTextに束ねる設計
SDKの中心はBrowserAIクラスで、loadModelとgenerateTextの2つが基本操作になる。READMEの例ではloadModelにモデル名とquantization、onProgressを渡し、読み込み進捗をパーセントで受け取る。generateTextは文字列でもメッセージ配列でも受け付け、temperature、max_tokens、system_promptをオプションで指定できる。ここが設計上の要点で、MLC、Transformers、Flare、Demucsという性質の異なるランタイムを、同じgenerateTextの呼び出しに揃えている。エンジンごとに別のAPIを覚える必要はない代わりに、どのエンジンがどのモデルを担当するかはモデル名で決まる。READMEの対応表ではMLCがLlama-3.2やQwen3、DeepSeek-R1-Distill、Snowflake-Arctic-Embedを、TransformersがWhisper系とKokoro-TTSを、FlareがGGUF形式のSmolLM2やQwen2.5を、DemucsがHTDemucsを担当する。Web Worker対応が挙げられているため、推論をUIスレッドから外す構成も想定されている。
インストールと最小の動作コード
導入はnpm install @browserai/browserai、またはyarn add @browserai/browseraiで行う。READMEのBasic Usageはこうなっている。BrowserAIをnewで生成し、loadModelに'llama-3.2-1b-instruct'とquantization: 'q4f16_1'、onProgressコールバックを渡す。生成結果はresponse.choices[0].message.contentで取り出す。OpenAIのレスポンス形式に寄せた形なので、既存コードからの移植はしやすい。構造化出力を使う場合はgenerateTextの第2引数にjson_schemaとresponse_format: { type: 'json_object' }を渡す。音声認識はloadModel('whisper-tiny-en')の後、startRecording、stopRecording、transcribeAudioという順で呼び、return_timestampsと言語を指定できる。TTSはloadModel('kokoro-tts')の後、textToSpeechにvoice: 'af_bella'とspeedを渡し、返ったAudioBufferをWeb Audio APIのdecodeAudioDataで再生する。Demucsだけはimport { DemucsEngine } from '@browserai/browserai/demucs'という別経路で読み込み、separateにshiftsとoverlapを渡す。shiftsは品質と処理時間のトレードオフだとREADMEが明記している。
モデルサイズという動かせない制約
最大の制約は対応モデルの一覧そのものに表れている。MLC側で最大なのはQwen3-8BとDeepSeek-R1-Distill-Llama-8Bで、大半は1Bから4Bの帯に収まる。Flare側のGGUFはさらに小さく、SmolLM2-135MからLlama-3.2-1Bまでで、量子化はQ8_0とQ4_K_Mが中心だ。つまり8Bを超えるモデルをブラウザで動かす道は、このREADMEの範囲では示されていない。加えて、WebGPUが使えない環境でのフォールバックは記載がない。READMEは「Offline Capable: Works without internet after initial download」とうたうが、その初回ダウンロードは数GBに達しうる。モバイル回線の利用者や、ストレージに余裕のない端末では、この初回ロード自体が離脱要因になる。エッジ推論の利点は往復レイテンシの削減にあるが、モデルが小さくなるほど生成品質は落ちる。この2つは同時には手に入らない。
Transformers.jsやWebLLMとの住み分け
同じ領域にはTransformers.jsやWebLLMがある。Transformers.jsはONNX Runtime Webを基盤にHugging Faceのモデル群をブラウザへ持ち込むもので、パイプライン単位でタスクを扱う。WebLLMはMLCのコンパイラ成果物をWebGPUで動かす点でBrowserAIのMLC経路と重なる。BrowserAIの差分は、エンジン選択を利用者に意識させず、テキスト生成、音声認識、TTS、音源分離を1つのSDKに同梱していることにある。Demucsによる4ステム分離（drums、bass、other、vocals）までブラウザ内で完結させる構成は、Transformers.jsの標準パイプラインには含まれない。逆に、対応モデルの網羅性やコミュニティの蓄積という点ではTransformers.jsに分がある。単一タスクを動かしたいだけなら、より枯れた経路を選ぶ理由は十分にある。
MITライセンスとメンテナンスの見通し
ライセンスはMITで、商用利用を含めて制約は緩い。ただしモデルの重みは別のライセンスで配布される。Llama系やGemma、Qwen、DeepSeekの各モデルにはそれぞれ利用条件があり、SDKのMITはそれらを覆わない。法務判断はここでは扱わないが、配布物に同梱するモデルを選ぶ際は個別に確認が必要になる。メンテナンス面では、リリースがv2.0.2、v2.0.4、v2.2.0と続き、最終pushは2026年7月である。ただしREADMEのRoadmapはPhase 2の途中で切れており、Enhanced RAG capabilities以降の記述が本文に残っていない。ロードマップの残りがどこまで実装済みかは、この資料からは判断できない。
どのモデルを選ぶかで決まる実用性
エンジン選択は性能ではなくモデル形式で決まる。MLCはコンパイル済みの成果物をWebGPUで動かす経路で、量子化はq4f16_1のような指定になる。FlareはGGUFをWASM経由で読むため、既にGGUF資産を持っている場合やLoRAを重ねたい場合に向く。READMEにはloadAdapterでsafetensors形式のアダプタをURLから読む例がある。Transformers経路はWhisperとKokoroに限定される。つまり「どのモデルを使いたいか」を先に決め、そこからエンジンが決まる順序で考えるべきで、逆ではない。Chat、Voice Chat、TTSの3つのデモが公開されているので、自前の環境を組む前にそこで挙動を確認できる。
編集部の結論
採用を検討すべきなのは、入力データをサーバーに送れない制約があり、かつ1Bから8Bクラスのモデルで要件を満たせるチームだ。逆に、70B級の推論やGPUのない端末を対象にするプロダクトには向かない。導入前に確認すべきは3点ある。第一に、対象ブラウザでWebGPUが有効かどうか。第二に、初回ロードするモデルのファイルサイズと、それがオフライン要件と両立するか。第三に、@browserai/browseraiのバージョンとエンジン選択の対応関係だ。READMEのFlareエンジン節にあるloadAdapterでLoRAを重ねる構成を採るなら、GGUF側の量子化形式とアダプタの互換性を実機で確かめてから本番に進むのが妥当である。
コミュニティノート